Project - AMD Radeon Performance Enhanced SSDT

Bansaku

Member
AMD OS X Member
May 3, 2020
95
1
40
18
Hello everyone! After reading many of the great success stories here at AMD OS X I started to see a repeating pattern plaguing essentially all of us. No, not USB and sleep (some day!) rather poor OpenCL and Metal performance, especially with Catalina. Well, I think I have found an answer and possible solution. Following the thread over at TonymacX86 (here) it was discovered that Apple has (yet again) pulled some Tom-Foolery on the the way things are done in Mac OS. After some testing on my old (now sold) i7 3770K system with my Gigabyte RX Vega 64 OC Gaming I determined that the SSDT fix does indeed work! The only issue is we all are on AMD and changes have to be made due to the PCI address that differ on Intel boards. After my posts were deleted in the original thread after it was obvious I needed help on a non-Intel system (f-ing hypocrites) I decided to take matters into my own hand and bring the topic here. This is where I need the POWER OF THE COMMUNITY to pull together and make this a reality! I suggest one head over to the link above and get familiar with the insanest and outs of the process.

Here is my thinking. The TL;DR of it is that the PCI address as appears in I/O Reg under GFX needs to be properly patched into the SSDT.

Screen Shot 2020-05-27 at 5.59.57 PM.png

Take note of the path: IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/GPP8@3,1/IOPP/pci-bridge@0/IOPP/pci-bridge@0/IOPP/GFX0@0

Now look at the snippet from the SSDT for Vega 64:

Screen Shot 2020-05-27 at 6.03.35 PM.png

See what I am thinking? What I need help is for someone who is more experienced than I at editing SSDT; It's been 8 years since I had to manually edit a DSDT and I am rusty and am not sure what is needed to edit into the path in the SSDT. Schiit, I am not ever sure if my line of thinking is correct! What is great if we can get this working is the fact that we will no longer need Whatevergreen to inject a generic frame buffer and instead have the ability to inject our own (if desired because what's in the specific SSDTs are the optimum frame buffers).

@Shaneee, I am unsure if this is the right place to post this thread and feel free to move it if you feel it would be better elsewhere. Regardless, we need to get this rolling! I have attached the files from the TMX86 thread. Please note that as they are now they won't do a darn thing! We can do this team!
 

Attachments

Yes this would be the correct place to post this. This is beyond my knowledge though. Maybe @NoOne would have an idea.
 

Attachments

From reading the original thread you could just use device property injection? Or just use the RadeonBoost.kext for Polaris/Vega20.

Anyway, the SMU firmware for Navi 10/14 is broken in 10.15.5 and loading it (which this method does) results in a kernel panic.
 
Last edited:
From reading the original thread you could just use device property injection? Or just use the RadeonBoost.kext for Polaris/Vega20.

Anyway, the SMU firmware for Navi 10/14 is broken in 10.15.5 and loading it (which this method does) results in a kernel panic.

I read from the creator of the Kext in the threads OP that all Vega support was dropped due to it messing with the fan spin; The SSDT method (from both what I have read and witnessed on my old system) does not have this issue. Have there been new developments?
 
Much easier with device properties, no rename/ACPI patching necessary.

On my 5500 XT
Before:
before.png
After:
after.png
 
@Aluveitie I checked out the EFI folder on Github. I threw in SSDR-X570-Vega64-slot1.aml and now pci-bridge has been renamed! This is great as entering "pci-bridge" is not allowed in the DSDT/SSDT without compile errors due to bad syntax. Performance has gone up slightly (like 3000pts in GB for oCL and Metal). It's a start. Now, I just need to figure out a way to incorporate the 2 SSDTs into something that works.

Screen Shot 2020-06-09 at 10.48.54 PM.png

@iamso78 I assume the "inject under device properties" method you and Aluveitie suggest is only applicable for OpenCore only eh?
 

Attachments

You can just copy over the properties. Don't forget to update the element count of the array here:
Code:
                        Local0 = Package (0x18) # number of elements needs to be adapted
 
You can just copy over the properties. Don't forget to update the element count of the array here:
Code:
                        Local0 = Package (0x18) # number of elements needs to be adapted

Thanks for the tip, and I know I know. It's been far too long since I have had to edit by hand (let alone AMD) and my mind is turning to mush trying to figure out how to mash things together.
 
Really hope this project goes far. I have vega 56 and the performance is terrible on MacOS.
 
I just bought an RX 580. Should i use RadeonBoost.kext or this SSDT/DeviceProperty Injection? RadeonBoost has different properties (Except for the integrated AGPM Injector) so i would know what is better to get true performance.
 
RadeonBoost does mostly restore what Apple disabled to fix Vega 10 fan control bugs.

Those other methods are (at least for the Navi cards) very hacky at best.
 
So do you suggest to use this SSDT instead of RadeonBoost for RX 580 (Polaris)?
 
Last edited:
Opposite, you should use RadeonBoost for Polaris and Vega 20
 
Opposite, you should use RadeonBoost for Polaris and Vega 20
Oh ok sorry, i misunderstood your words.
Anyway, i made some tests and i tried every method to see if there were any differences.

With all the methods (also without ssdt or kext) i have the same results, OpenCL at 30000 and Metal at 38000, so there isn't any improvement.
The strange thing is that if i put mac to sleep, after wake (i tried that only with radeonboost.kext) i got OpenCL at 40000 and Metal at 57000.
What could be the cause?
 
Last edited:
Just for trying, i made some other tests with some device properties/SSDT found on original thread.
The result is always the same:
Before Sleep: OPENCL 29999 - METAL 33820
After Sleep: OPENCL 36336 - METAL 51144

I also tested OpenCL on Windows and the result is very different: OpenCL 48126.

Why there is so much difference?
 
  AdBlock Detected
Sure, ad-blocking software does a great job at blocking ads, but it also blocks some useful and important features of our website. For the best possible site experience please take a moment to disable your AdBlocker.