Jump to content

fabiosun

Recommended Posts

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 by 23d1
Link to comment
Share on other sites

  • Supervisor
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 by fabiosun
found it
Link to comment
Share on other sites

  • Moderators

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.

 

OC-ResizableBarQuirks.thumb.png.9f310b965cbf32e8fabdf04b03cfb23f.png

 

 

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 by iGPU
MmioWhite comment added.
  • Like 4
Link to comment
Share on other sites

  • Moderators
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

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

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 by 23d1
Link to comment
Share on other sites

  • Supervisor

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

 

Link to comment
Share on other sites

  • Moderators
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

331992543_ScreenShot2021-10-12at9_41_20AM.thumb.png.d95f4e63c3f4c3903e89dcc4c6c13dc4.png

 

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:

312742947_Geekbench-6900XT-silentmode-OpenCL.thumb.png.63433baa5de49154fdcb49b37faafab1.png

 

Metal:

324574860_Geekbench-6900XT-silentmode-Metal.thumb.png.b9a77e264ea08d93ffc73e2e3511fa3a.png

 

 

GB5 with ResizeBar:

 

OpenCL:

GB5-OpenCL-3970X-6900XT-ResizerBar-10.thumb.png.78b2b3eb76313e34038639bb312857a5.png

 

Metal:

GB5-metal-3970X-6900XT-ResizerBar-10.thumb.png.f7e2fe82ce426ceeac5b000225d68178.png

 

 

 

 

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

 

 

 

  • Like 2
Link to comment
Share on other sites

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

331992543_ScreenShot2021-10-12at9_41_20AM.thumb.png.d95f4e63c3f4c3903e89dcc4c6c13dc4.png

 

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:

312742947_Geekbench-6900XT-silentmode-OpenCL.thumb.png.63433baa5de49154fdcb49b37faafab1.png

 

Metal:

324574860_Geekbench-6900XT-silentmode-Metal.thumb.png.b9a77e264ea08d93ffc73e2e3511fa3a.png

 

 

GB5 with ResizeBar:

 

OpenCL:

GB5-OpenCL-3970X-6900XT-ResizerBar-10.thumb.png.78b2b3eb76313e34038639bb312857a5.png

 

Metal:

GB5-metal-3970X-6900XT-ResizerBar-10.thumb.png.f7e2fe82ce426ceeac5b000225d68178.png

 

 

 

 

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 by Driftwood
Link to comment
Share on other sites

  • Moderators
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.

 

  • Like 1
Link to comment
Share on other sites

  • fabiosun changed the title to [Discussion] - TRX40 Bare Metal - Vanilla Patches

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • There are no registered users currently online
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.