trx40 [Discussion] - TRX40 Bare Metal - Vanilla Patches

[23d1]

11 hours ago, fabiosun said:

Have you tried with this config to boot with all cores enabled?

if it is not working as I think you can try to use an Xcode app (instruments) and limit there cpu core to 32

it could be possible also to try a boot arg (cpu or cpus =32) and see

 

but no illusion about it because also some important lib should be capped to work

 

only some tries to do!

 

Yes, it crashes when multithreading is enabled in bios (SMT Mode = Auto).

Testing boot args now, will report back.

 

Is there a kext that can make it work without turning off SMT?

 

Another note; Adobe and everything seems to be working so far, but for some reason Autodesk Maya crashes when launching. Very very odd.

 

Edit; cpu=32 boot arg didn't fix the issue.

Edited October 10, 2021 by 23d1

[fabiosun]

11 minutes ago, 23d1 said:

Is there a kext that can make it work without turning

No I don’t think so

it should be a driver efi but it does not exist 

[23d1]

7 hours ago, fabiosun said:

No I don’t think so

it should be a driver efi but it does not exist 

 

Makes sense as not a lot of people are running the 3990x in general, and specifically macOS...

[fabiosun]

11 hours ago, 23d1 said:

Autodesk Maya crashes when launching. Very very odd.

could you post crash log?  found it

If it is a MKLproblem maybe a solution could be possible

 

Edited October 11, 2021 by fabiosun
found it

[fabiosun]

@23d1I am trying an old version in trial mode

   

[iGPU]

This post is a heads up for what's coming in OC v075 (I test the daily mods).

 

The post is not a tutorial, I've not yet tested the functionality under our TRX40 system. (I'll work on later tonight.) What the latest commit adds is support for Resizable BAR technology. Apparently, macOS does support this feature up to 1 GB (which is the value of "10" for the entries as shown below). The value of "-1" is the default value, turning this feature off.

 

There are 2 Quirks for this feature. What is not yet clear to me is if both are used simultaneously, or, only one or the other.

 

I should also add that when Resizable Bar is enabled in BIOS, my mobo also turns on Above 4G. If you continue with these both enabled, you will also have to re-do your MmioWhite list; otherwise you will not be able to boot into macOS on our TRX40 mobos.

 

 

 

As for documentation, in the Spoiler below are excerpts from the latest Docs:

 

Spoiler

Quirk #1:

 

Booter/Quirks/ResizeAppleGpuBars

Type: plist integer

Failsafe: -1

 

Description: Reduce GPU PCI BAR sizes for compatibility with macOS.

This quirk reduces GPU PCI BAR sizes for Apple macOS up to the specified value or lower if it is unsupported.

 

The specified value follows PCI Resizable BAR spec. Use 0 for 1 MB, 1 for 2 MB, 2 for 4 MB, and so on up to

19 for 512 GB. Apple macOS supports 1 GB maximum, which is 10. Use -1 to disable this quirk.

Note: See ResizeGpuBars quirk for general GPU PCI BAR size configuration and more details about the technology.

 

 

 

Quirk #2:

 

UEFI/Quirks/ResizeGpuBars

Type: plist integer

Failsafe: -1

 

Description: Configure GPU PCI BAR sizes.

This quirk sets GPU PCI BAR sizes as specified or chooses the largest available below the ResizeGpuBars value.

The specified value follows PCI Resizable BAR spec. Use 0 for 1 MB, 1 for 2 MB, 2 for 4 MB, and so on up to 19 for 512 GB.

Resizable BAR technology allows to ease PCI device programming by mapping a configurable memory region,

 

BAR, into CPU address space (e.g. VRAM to RAM) as opposed to a fixed memory region. This technology

is necessary, because one cannot map the largest memory region by default, for the reasons of backwards

compatibility with older hardware not supporting 64-bit BARs. Consequentially devices of the last decade

use BARs up to 256 MB by default (4 remaining bits are used by other data) but generally allow resizing them

to both smaller and larger powers of two (e.g. from 1 MB up to VRAM size).

 

Operating systems targeting x86 platforms generally do not control PCI address space, letting UEFI firmware

decide on the BAR addresses and sizes. This illicit practice resulted in Resizable BAR technology being unused

up until 2020 despite being standardized in 2008 and becoming widely available in the hardware soon after.

Modern UEFI firmware allow the use of Resizable BAR technology but generally restrict the configurable options

to failsafe default (OFF) and maximum available (ON). This quirk allows to fine-tune this value for testing and

development purposes.

 

Note 1: This quirk shall not be used to workaround macOS limitation to address BARs over 1 GB. ResizeAppleGpuBars

should be used instead.

 

Note 2: While this quirk can increase GPU PCI BAR sizes, this will not work on most firmware as is, because

the quirk does not relocate BARs in memory, and they will likely overlap. Contributions to improve this feature

are welcome.

 

As I've posted on this thread several times, head over here for the latest commits.

 

But a parting editorial. I've previously given instructions on how to use "ocvalidate" in the Utilities folder to correct your config.plist file to eliminate errors. (ocvalidate shows you the items needing removal and those needing to be added; and comes with a README file if you don't wish to search for my earlier posts.) Everyone who is running a Hackintosh should know how to check their own config files with this tool and not depend on others to fix their files due to being too lazy to use this tool.

 

 

 

 

Edited October 12, 2021 by iGPU
MmioWhite comment added.

[fabiosun]

compiled now from opencore master :

OpenCore-0.7.5-RELEASE.zipOpenCore-0.7.5-DEBUG.zip

[fabiosun]

ok, now I will try to enable resize bar in bios and in config.plist

 

[fabiosun]

wow

Resize bar now works 🙂

 

[Driftwood]

Nice! Have you done the FPS tests in Davinci with Resizable Base Address Register adjustments and is 1Gb all good?

 

 

 

23 minutes ago, fabiosun said:

wow

Resize bar now works 🙂

 

 

[fabiosun]

@Driftwoodno improvement 

[fabiosun]

@23d1

thanks @tomnic for patched library 🙂

 

Edited October 11, 2021 by fabiosun

[Driftwood]

1 hour ago, fabiosun said:

@Driftwoodno improvement 

Ive just loaded mine up to see. Seems stable enough with 10 in ResizeGpuBars for both. Asrock users will note when upgrading firmware BIOS to 1.73 beta that Above 4G and Resizable BAR is now found in the Advanced menu. 

 

 

[23d1]

2 hours ago, fabiosun said:

 

@23d1

thanks @tomnic for patched library 🙂

 

Did you run into the same crash at first (I can share the report if not), and how on earth did you solve it? 🙂

Edited October 11, 2021 by 23d1

[fabiosun]

@tomniccould explain better

it is an old method he patched two libs

[tomnic]

14 minutes ago, 23d1 said:

Did you run into the same crash at first (I can share the report if not), and how on earth did you solve it? 🙂

 

Patched the offending libraries, libtbb.dylib and libtbbmalloc.dylib, they call intel.fastmemset.A and intel.fastmemcpy.A, specific for true intel cpus... pointed to intel.fastmemset.V and intel.fastmemcpy.V, for generic AVX enabled cpus, like our glorious AMD... boom, it worked

maya mod.zip

[fabiosun]

075 and resize bar feature break Sleep/wake cycle here

System does not wake anymore after sleep

 

I cannot see any improvement in my graphic benchmark for now.

 

[23d1]

3 hours ago, tomnic said:

 

Patched the offending libraries, libtbb.dylib and libtbbmalloc.dylib, they call intel.fastmemset.A and intel.fastmemcpy.A, specific for true intel cpus... pointed to intel.fastmemset.V and intel.fastmemcpy.V, for generic AVX enabled cpus, like our glorious AMD... boom, it worked

maya mod.zip 333.13 kB · 1 download

Oh, gotcha—that's awesome. Will check later, but pretty sure those are the exact libs/issues I remember from fine combing the error report. Would also explain why it works under proxmox when using Penryn (haven't tried beyond 2020 version in KVM yet though).

 

Thanks!

 

As a side note; I noticed I get about 20k less points in Cinebench compared to fully threaded 64 core in Windows, and about 10-13k less compared to KVM. Anyone have any insights I to the accuracy of that? Feels like a pretty steep loss of performance.

Edited October 11, 2021 by 23d1

[fabiosun]

KVM should be a bit less fast than Bare Metal or, in an ideal condition, kvm has similar values

 

 

[fabiosun]

Enabling resize bar on bios and in config with a value of 10 could cause a sleep/wake problem during wake stage (black screen or reboot)

A solution was proposed on Hackintosh-forum.de from hackmac004

setting quirk value to 8 solves wake problem

 

[Arrakis]

Hello

One question, do you know if this graphics card is supported by Big Sur and Monterey ?

https://www.amd.com/en/products/professional-graphics/amd-radeon-pro-w6800

 

[iGPU]

10 hours ago, fabiosun said:

Enabling resize bar on bios and in config with a value of 10 could cause a sleep/wake problem during wake stage (black screen or reboot)

A solution was proposed on Hackintosh-forum.de from hackmac004

setting quirk value to 8 solves wake problem

 

 

I have both ResizeBar values in OC set to 10, and had no problems with sleep/wake in Monterey and I left computer running over night.

 

Since I had to do a reformat and fresh install of Monterey (thanks MS!), initially sleep/wake was not working. (BTW, I did finally get Win 11 to install but it took many hours of fiddling with regedit, and other things like DISM, inside Win 10 to get the update to 11 to properly install.)

 

But after the re-install, I had to re-set Energy settings as shown in Spoiler below in order to get the sleep/wake cycle working once more. I did not change these settings for OC's ResizeBar when I left running over night.

 

Spoiler

 

As for testing, I only did some limited tests last night. I saw about a 20% improvement for GB5 with OpenCL but a 20% decrease with Metal. Strange.

 

GB5 Tests:

Spoiler

GB5 without ResizeBar:

 

OpenCL:

 

Metal:

 

 

GB5 with ResizeBar:

 

OpenCL:

 

Metal:

 

 

 

 

For GB4, both OpenCL (385723) and Metal (374494) were better. LuxMark values were unchanged when using ResizeBar. I've not yet test DaVinci.

 

 

 

[fabiosun]

@iGPUI am using same energy saver options you have but if I use 10 as value in new quirk I have a bad wake (black screen), I have to use 8

 

performance with geek bench 5.4.1 is the same in my case

Spoiler

 

 

 

 

[Driftwood]

7 hours ago, iGPU said:

 

I have both ResizeBar values in OC set to 10, and had no problems with sleep/wake in Monterey and I left computer running over night.

 

Since I had to do a reformat and fresh install of Monterey (thanks MS!), initially sleep/wake was not working. (BTW, I did finally get Win 11 to install but it took many hours of fiddling with regedit, and other things like DISM, inside Win 10 to get the update to 11 to properly install.)

 

But after the re-install, I had to re-set Energy settings as shown in Spoiler below in order to get the sleep/wake cycle working once more. I did not change these settings for OC's ResizeBar when I left running over night.

 

  Hide contents

 

As for testing, I only did some limited tests last night. I saw about a 20% improvement for GB5 with OpenCL but a 20% decrease with Metal. Strange.

 

GB5 Tests:

  Reveal hidden contents

GB5 without ResizeBar:

 

OpenCL:

 

Metal:

 

 

GB5 with ResizeBar:

 

OpenCL:

 

Metal:

 

 

 

 

For GB4, both OpenCL (385723) and Metal (374494) were better. LuxMark values were unchanged when using ResizeBar. I've not yet test DaVinci.

 

 

 

@iGPU In terms of M2 and SATAs, plus other PCIe cards inc GPUs, BT/Wifi what is your current I/o PCIe population? Also, are you booting off USB Stick every time, is your boot for Big Sur and / or Monterey on M2 or SATA SSD? Plus, can you video your BIOS settings. Im intrigued as to how you have all those Power Options in Energy Saver too (I may have switched off a few trying out variables for Sleep) so I may need to reset.

 

Its a lot to ask but I need to strike off a few things in my mind. Thanks. 

Edited October 12, 2021 by Driftwood

[iGPU]

4 hours ago, Driftwood said:

@iGPU In terms of M2 and SATAs, plus other PCIe cards inc GPUs, BT/Wifi what is your current I/o PCIe population? Also, are you booting off USB Stick every time, is your boot for Big Sur and / or Monterey on M2 or SATA SSD? Plus, can you video your BIOS settings. Im intrigued as to how you have all those Power Options in Energy Saver too (I may have switched off a few trying out variables for Sleep) so I may need to reset.

 

Its a lot to ask but I need to strike off a few things in my mind. Thanks. 

 

PCIe: GPU in slot 1 (which covers slot 2), BT/Wifi card in Slot 3 and TB card in slot 4.

 

All three .M2 slots on my MSI Creator mobo are populated with MVMe drives: one for Windows and 2 for macOS (M/BS). I boot off either of these two internal macOS EFI partitions on NVMe drives. There are also 3 SATA drives which are used for storage (these too have EFI partitions which have bootable OC EFI folders). I keep one of the SATA drives's EFI with MmioWhitelist for Above 4G enabled and another with for when Above 4G is disabled, using an older, stable versions of OC. These are for 'backdoor' booting should either of the EFIs on the main NVMe drives get corrupted or I change a BIOS setting.

 

Should something really get wonky, I have USB devices containing other NVMe drives that have their EFI partitions loaded with macOS EFIs with other boot options. I can edit these from a Mac laptop to further ensure a proper boot.

 

Also, all of my macOS drives contain a folder with many versions of OC EFI folders for Intel (Z390 various mobos, X299) and AMD (X570 and TRX40): backups of backups.

 

***

 

@fabiosun 

 

I changed both of my settings to "8" and re-ran the GB5 tests. Both OpenCL and Metal results were reduced by about 5%... I'll re-test another time disabling both Quirks. The results all seem a bit odd to me.