AMD GPU: UnfairGVA, DRM, SideCar, FeatureUnlock and GB5 compute [Help]

[rafale77]

I am tempted to post these questions and information on github but wanted to first see if I could get some response here.

The hack at play is the Lenovo P340 in my sig which has both an iGPU and AMD dGPU supported, enabled and working in MacOS.

 

Goal: achieve all of the criteria below

1. AppleTV/iTunes DRM
2. SideCar running on the iGPU
3. Power management on the dGPU
4. Geekbench Compute scores matching Windows

 

I have posted questions about the values of unfairGVA which are undocumented. I eventually found this in the WEG source code on Github.

	enum : uint32_t {
 		UnfairAllowHardwareDrmStreamDecoderOnOldCpuid = 1,
 		UnfairRelaxHdcpRequirements = 2,
 		UnfairCustomAppleGvaBoardId = 4,
 		UnfairDyldSharedCache = UnfairRelaxHdcpRequirements | UnfairCustomAppleGvaBoardId,
 	};

unfairgva:

Only the first value of unfairGVA=1 is documented in the WEG readme. The values of 2 and 4 are not. This entry can be used as as a boot-arg or a device property for the AMD GPU.

I came to realize then that unfairgva=4 is an equivalent of what shikiGVA used to do and explains why using values 4, 5, 6 or 7 enables AppleTV/iTunes DRM on my machine.

The value add up:

unfairgva = 1 -> enables DRM on old CPUID

unfairgva = 2 ->Relax HDCP requirements

unfairgva = 1+2 = 3 -> enables the two options above

unfairgva = 4 -> Inject the iMacPro1,1 board ID

unfairgva = 4+1 = 5 -> enables the options 4 and 1

unfairgva = 4+2 = 6 -> enables the options 4 and 2

unfairgva = 4+2+1 = 7 -> enables all

 

Conclusion: In order to enable HW DRM on the AMD GPU, I am using unfairgva=6 as my CPU doesn't belong in the old category and I enabled relaxHDCP requirements for good measure though I am not sure it does anything. This is apparently a replacement of the old Shikigva.

 

Sidecar:

I have done extensive testing of Sidecar which uses video encoding and therefore is very closely related with DRM. What I discovered is that with the unfairgva injection above, Sidecar encoding goes through the dGPU. As a result it is very unstable/unreliable as I am guessing that the AMD encoder is not as good as the intel one and/or Apple relies on the T2 chip to accelerate this encoding which my hack doesn't have. I have also discovered that adding the FeatureUnlock.kext switches this encoding back to the iGPU and makes Sidecar work smoothly again. This is also completely undocumented.   Edit: Upon further testing, this was wrong. It appears to run a little smoother for some reason but in in reliable fashion. When, on, it increases the dGPU temperature by >10C.

 

Geekbench Compute and Power Management:

Being a new build and working out of the box, I was not paying too much attention to the GPU power consumption, temperature and GB5 performance. I had run an initial benchmark but today just realized that the temperature was a bit on the high side so I ran a GB test to find out that the scores dropped by ~40%. Monitoring the GPU and Memory clock, all appear to be normal. I then read about radeonboost.kext. I am suspecting that I am having the same memory bandwidth problem. What is strange is that removing the unfairgva boot-arg recovers the GB5 performance back to normal. I have therefore tried to tinker with radeonboost and adapt it for my specific GPU (polaris 11, similar to the RX560 and removed the AGPM content) and managed to address the power consumption/temperature issues (dropped by 10C at idle) but the GB5 scores are still ~40% lower than what they should be. radeonboost doesn't appear to work but I am not sure it is the problem.

 

Summary table below:

 

Injecting the iMacPro1,1 boardID to enable DRM, switching the video decoder to the dGPU appears to break quite a few things similar to the force command below

defaults write com.apple.AppleGVA gvaForceAMDKE -boolean yes

Is there a better way to do this? Is there something I missed?

 

To date, I can't seem to find a fully working solution...

 

 

 

 

 

Edited May 22, 2022 by rafale77

[rafale77]

It seems like I am not the only one having the low GB5 score on a Polaris GPU with the iMacPro1,1 Board injection: 

 

I decided to run another test and I got some pretty fascinating results:

 

1. Start from a no patch state with the iMac20,2 SMBIOS. I would speculate that any config with iGPU/dGPU and any iMac SMBIOS on Monterey would be the same. GB5 scores are 24K

2. I then I applied the command below:

defaults write com.apple.AppleGVA gvaForceAMDKE -boolean yes

GB5 scores still at 24K and SideCar still runs on the iGPU.

3. I launch a video on the AppleTV App. Without the command in (2) it would fail for DRM but now it works. (Side note, after the video is played, somehow AppleTV Plus kicks me out of my appleTV account forcing me to log out and back in)

GB5 score drop to ~14K and Sidecar becomes very unstable as it has switched to run on the dGPU.

4. I try to revert what I did using 

defaults write com.apple.AppleGVA gvaForceAMDKE -boolean no

but I can't. The GB5 scores remain low and SideCar remains unstable. I need to reboot the system or run a sleep/wake to get back to the initial state.

 

See the data below.

 

 

My conclusion: Somehow the AMD driver behaves differently when the AMD decoder/encoder is enabled. The iMacPro1,1 and MacPro7,1 not having an iGPU force that feature to be permanently enabled but so does spoofing the boardID though unfairGVA patch. Looks to me like a buggy AMD driver for MacOS.

 

The gvaForceAMDKE is not a viable long term solution since it causes changes in behavior after video playback which cannot be reverted without a reboot.

Looking into the WEG code, the shikiGVA functionality has been completely disabled starting from Big Sur due to lilu's functionality of being able to detect and trigger behaviors depending on programs run having been broken. Hope this gets fixed soon.

It was replaced by unfairgva which, for my configuration, only the permanent board ID spoofing is able to enable DRM. I am not sure what other side effect this spoofing my have and the GB5 lower compute score is pretty benign so I will live with it. Base on the root cause of these low scores, I would not be surprised if real iMacPro1,1 and MacPro7,1 were not suffering from this problem.

 

 

 

Edited May 27, 2022 by rafale77

[rafale77]

I have been testing various things with the terminal command force the AppleGVA to AMD and found some interesting things:

1. I can toggle the option back and forth: With the iGPU, I can start Sidecar, send the terminal command to switch to the dGPU and start an AppleTV movie with DRM and Sidecar will remain on the iGPU. This reproduces how my real macbook pro behaves albeit with the added trouble of having to execute the terminal command.

2. More interesting is the finding that if I toggle to the dGPU and start Apple TV first, pause it and then start Sidecar, strangely, the Sidecar connectivity and stability is much improved in spite of running on the AMD GPU. Not quite sure why that is but it could be a trick to make SIdecar much more reliable on dGPU only setups. The quality of the encoding is not as good as on the iGPU as I am seeing some flickering as usual but the connection never drops and I connect success rate is 100% Vs <20% without Apple TV started.

3. The AMD GPU benchmark performance drop appears to be permanent if one boots with a GPU only SMBIOS or uses unfairGVA to spoof the board-id to a GPU only Mac (iMacPro or MacPro) but if one boots with the iGPU as the video processor (iMac SMBIOS and the force AMDKE to off) then a sleep/wake cycle recovers the performance loss. The video processors with which macOS boots appears to matter.

4. The sidecar rendering seems to be a complex blend between the iGPU, dGPU and CPU in the absence of a T2 chip. The AppleGVA engine seem to be easily get confused as to what runs where which makes the whole thing not very robust. I am also seeing a lot of reports of issues on real macs.

Edited May 29, 2022 by rafale77

[rafale77]

It is sometimes better to be lucky than good.

I have been flipping switches without understanding everything they do and have finally gotten to a stable/reliable setup for Sidecar and DRM. Still have not figured out why the AMD GPU performance drops after starting a GVA encoding/decoding on it.

 

I have noticed that while the deprecated shikigva was injecting a hwdrm-id replacing the board-id dynamically by application, unfairgva appears to inject hwgva-id variable all the time to the gva framework.

So I went to investigate what the different hwgva-id have in /System/Library/PrivateFrameworks/AppleGVA.framework/Versions/A/Resources/Info.plist. By default, unfairgva injects an iMacPro1,1 board:

		<key>Mac-7BA5B2D9E42DDD94</key>
		<dict>
			<key>allowFrameReordering</key>
			<false/>
			<key>hwe</key>
			<true/>
			<key>hwe420</key>
			<true/>
			<key>interlacedOff</key>
			<true/>
			<key>ke1</key>
			<true/>
		</dict>

 

That is instead of the iMac20,1 below:

		<key>Mac-CFF7D910A743CAAF</key>
		<dict>
			<key>facetimeDecode</key>
			<true/>
			<key>forceOfflineRenderer</key>
			<true/>
			<key>hwe</key>
			<true/>
			<key>hweBGRA</key>
			<true/>
			<key>ke1</key>
			<true/>
			<key>pp</key>
			<integer>1</integer>
		</dict>

 

After looking at all the different options I decided to try to remove the "forceOfflineRenderer" option only to reproduce one of the shikigva options and found the MacMini8,1:

		<key>Mac-7BA5B2DFE22DDD8C</key>
		<dict>
			<key>facetimeDecode</key>
			<true/>
			<key>hwe</key>
			<true/>
			<key>hweBGRA</key>
			<true/>
			<key>ke1</key>
			<true/>
			<key>pp</key>
			<integer>2</integer>
		</dict>

I modified the WEG source code and recompiled it and strangely with the combination of enable-metal injected to the iGPU, Sidecar is now very stable running on the dGPU. (using the forceAMDKE command). It already was stable on the iGPU. I still see minor artifacts/flickers on the iPad but it is now useable. It no longer crash and disconnects. If the enable-metal option is removed, then appleGVA crashes and fails when it tries to run on the iGPU (with the forceAMDKE command off).

 

I can now enable DRM by switching the gva to the dGPU and move back to the iGPU if I want a flicker free Sidecar experience. In either mode, I no longer have connection drop/breakage/freeze of Sidecar.

I even wrote a little script in order to switch appleGVA between dgpu and igpu from the desktop.

gvaswitch

Edited June 3, 2022 by rafale77

[miliuco]

@rafale77

 

Excellent work!!! I am one of those not understanding very well the different unfairgva values. I have learned useful things in your posts. Now I have unfairgva=6 on iMac19,1 (Monterey) with iGPU headless mode and TV app works very well. Thanks!!!

 

Edited July 13, 2022 by miliuco

[rafale77]

Glad this helped. It's a steep learning curve and could use some better documentation. After a bit more testing I have decided to go back to mimicking a real iMac...

1. I am keeping my iGPU offline by removing the enable-metal from my boot-arg. I discovered that metal is actually enabled to the OS, not to the user but bringing the iGPU online can actually confuse MacOS as it would have 2 "online GPUs"

2. I reverted my mods of WEG and am now running UnfairGVA=2 so as not to spoof the AppleGVA to an iGPU less board-id as I found it to be too restrictive and made use cases when DRM is not required to be highly power inefficient. (it forces use of the AMD decoder)

3. I am using that little script I posted above to switch GVA whenever I need DRM decoding.

 

I also discovered a Sidecar bug on Monterey: SideCar starts freezing an iPad within seconds of enabling the feature if the iPad has not been rebooted for more than ~24hrs. I validated the phenomenon on two iPads and a real Mac... I am not the only one experiencing it apparently. This problem has interfered with a lot of my previous test results...

[theroadw]

Hi @rafale77 I stumbled on this post while playing around with this:

And I remember going through the same DRM low performance, etc... and I believe I figured out a way, I documented it in another forum I probably can't link to, but here's the text:

 

For h264 encoding and decoding , follow this guide: https://forums.macrumors.com/threads/activate-amd-hardware-acceleration.2180095/page-9#post-27442938

I changed the hex values from the guide to match my SMBIOS platform Mac-827FB448E656EC26 - (38 32 37 46 42 34 34 38 45 36 35 36 45 43 32 36 - using ascii to hex calculator)
And also merged some items on the Resources info.plist
 

I also added the following commands:

defaults write com.apple.AppleGVA gvaForceAMDHEVCDecode -bool YES
defaults write com.apple.AppleGVA gvaForceAMDKE -bool YES
defaults write com.apple.AppleGVA forceATI -bool YES

And now hardware encoding and decoding work really smooth, way faster than with shikigva. Removed that opencore boot flag and it seems to be better overall.

 

What this does is create the file com.apple.AppleGVA.plist in user/library/preferences
and together with the shikigva flag in opencore, forces some things on the 4170 GPU.
To test you can open Quicktime and do a screen recording and monitor using activity monitor and you should see the Radeon Polaris being used for recording and also if you export resizing, the polaris GPU is used.
This didn't work for Handbrake though. I can now use polaris DGPU for harware encoding using apps that use the VideoToolbox. Also have zero glitches on playback or export with Davinci Resolve and a big improvement in performance. Finalcut Pro works like a dream, it uses the Polaris GPU for a lot of stuff and I see it also uses the IGPU for other stuff, and overall it is silky smooth.
Guess shikigva could have been the one causing some performance glitches.

Also tested using external monitor and swaping the main display to the external to run some benchmarks and openGL apps and they work, but not at 100% the speed/performance I saw when using DGPU only.
So it looks like the combo actually slows down the 4170...

Hybrid without shiki:

Much better (85.77 fps) as you can see from previous result (61.65fps) and the UHD can only do (29.86fps), so a big improvement!

GPU only:

This benchmark was with a different VBIOS that was not very stable, but I show it as an example that Dedicated mode is faster, and it is the closest to windows performance and I guess the max the WX-4170 can do.

DRM works on external displays but not on internal.
And I doubt DRM will ever work on internal display, since the one doing the drawing is the IGPU, even if the decoding is being done by the polaris card, and because the IGPU doesn't have the Apple special sauce, it's most likely never going to happen.

It looks like to force all metal or opengl on the polaris card, I need to somehow convince gfxCardStatus app that this is a dual GPU Macbook Pro. (possible solution found on following posts)

 

---

 

I have since managed to create an SSDT to flip the LCD MUX switch on boot and get the WX-4170 to draw the LCD and therefore get full DRM.
Maybe these settings will help you.

edit

For some weird reason I can't explain, by using iMac20,2 and unfairGVA=4 I get DRM on the LCD using the IGPU and also get full DRM on all external displays using DGPU. it never worked like this before, but it does now. Only thing is I get the same crappy DGPU performance after TV app does it's thing. Dropping from ~2000fps to ~800 in GLView. IGPU performance is not affected, and all quicksync features work correctly.

 

Edited April 12, 2023 by theroadw

[miliuco]

@theroadw

Great explanation.

Please add a signature to your user profile.