MP 1,1-5,1 Activate AMD hardware acceleration

[w1z]

I've been following this thread closely but have not been able to employ any of the tricks/workarounds as I had a Nvidia GPU.

However, the situation has changed as I now have a 5700XT Anniversary Edition installed in my cMP and have noticed the following:

- All ports are functional under Catalina 10.15.1 - lilu/whatevergreen/pikera is not needed
- AppleGVA plist hack works but I am having the same issue @sirbryan reported in Safari
- Tried some of the values used in AppleGVA for the MacbookPro16,1 less facetime and other non-related variables and I did not notice any difference.

Seeing that the 5700 is not a Polaris card, I don't think I will be impacted by the changes introduced in Catalina that were reported by @CMMChris

Happy to run tests to further this awesome effort =)

 

[h9826790]

I've been following this thread closely but have not been able to employ any of the tricks/workarounds as I had a Nvidia GPU.

However, the situation has changed as I now have a 5700XT Anniversary Edition installed in my cMP and have noticed the following:

- All ports are functional under Catalina 10.15.1 - lilu/whatevergreen/pikera is not needed
- AppleGVA plist hack works but I am having the same issue @sirbryan reported in Safari
- Tried some of the values used in AppleGVA for the MacbookPro16,1 less facetime and other non-related variables and I did not notice any difference.

Seeing that the 5700 is not a Polaris card, I don't think I will be impacted by the changes introduced in Catalina that were reported by @CMMChris

Happy to run tests to further this awesome effort =)

Only use the 7,1 parameters or iMac Pro parameters. The MacBook Pro use Intel Quick Sync. Do NOT try to use that, such hardware simply not exist on the cMP.

Pikera only required when spoofing at iMac Pro. Edit the AppleGVA plist won’t affect the ports availability.

Anyway, it’s good to know that Navi card’s HWAccel also work. If possible please try to watch 8K 60FPS YouTube videos (e.g. in Brave, Firefox, Chrome…) and report back if VP9 decode is fully functional now. Thanks in advance.

 

[w1z]

Only use the 7,1 parameters or iMac Pro parameters. The MacBook Pro use Intel Quick Sync. Do NOT try to use that, such hardware simply not exist on the cMP.

Pikera only required when spoofing at iMac Pro. Edit the AppleGVA plist won’t affect the ports availability.

Anyway, it’s good to know that Navi card’s HWAccel also work. If possible please try to watch 8K 60FPS YouTube videos (e.g. in Brave, Firefox, Chrome…) and report back if VP9 decode is fully functional now. Thanks in advance.

I made sure to remove the intel variable from the MBP's values. Retesting using the iMac Pro's and I can watch 8K/60FPS on youtube on chrome and firefox but the CPU usage was high and GPU was 50% causing buffering like effects. Safari was a failure.

I downloaded 4K/6K/7K/8K small samples, like 60MB, from some test site and can play them through VLC. CPU usage was low and GPU between 10~20%

Any particular videos you want me to try?

Edit: btw - video quality is AMAZING at anything over 6K.

 

[MIKX]

krakman

Should SIP be disabled prior to doing the HEX mod ?

 

[kohlson]

(deleted)

 

[maccan]

I think there is no need to modify any system files at all.

What I did:
After a clean install of Mojave 10.14.6, I just executed the 4 defaults write.com.apple.AppleGVA commands from a terminal in my ordinary user account:

defaults write com.apple.AppleGVA gvaForceAMDKE -bool YES
defaults write com.apple.AppleGVA gvaForceAMDAVCEncode -bool YES
defaults write com.apple.AppleGVA gvaForceAMDAVCDecode -bool YES
defaults write com.apple.AppleGVA gvaForceAMDHEVCDecode -bool YES

This was enough in order to get smooth GPU accelerated Video playback (SwordSmith, jellyfish (400Mbs),.. ) on my MacPro 5.1 2010, Vega56.

So there is no need to disable SIP in order to tweak any system-files.

 

[h9826790]

I think there is no need to modify any system files at all.

What I did:
After a clean install of Mojave 10.14.6, I just executed the 4 defaults write.com.apple.AppleGVA commands from a terminal in my ordinary user account:

defaults write com.apple.AppleGVA gvaForceAMDKE -bool YES
defaults write com.apple.AppleGVA gvaForceAMDAVCEncode -bool YES
defaults write com.apple.AppleGVA gvaForceAMDAVCDecode -bool YES
defaults write com.apple.AppleGVA gvaForceAMDHEVCDecode -bool YES

This was enough in order to get smooth GPU accelerated Video playback (SwordSmith, jellyfish (400Mbs),.. ) on my MacPro 5.1 2010, Vega56.

So there is no need to disable SIP in order to tweak any system-files.

Tested, the HEVC hardware decode can be activated by this method. However, the same bug as 10.14.0. Only the first video playback is smooth. After that, must completely quit the player, then re-open again to play another video correctly.

You may try to play the SwordSmith video in QuickTime Player, then close the player window but do NOT quit QuickTime Player. Then try to play the same SwordSmith video again. Most likely you can see the bug.

Besides, no hardware encode can be activated by this method.

 

[MIKX]

I think there is no need to modify any system files at all.

What I did:
After a clean install of Mojave 10.14.6, I just executed the 4 defaults write.com.apple.AppleGVA commands from a terminal in my ordinary user account:

defaults write com.apple.AppleGVA gvaForceAMDKE -bool YES
defaults write com.apple.AppleGVA gvaForceAMDAVCEncode -bool YES
defaults write com.apple.AppleGVA gvaForceAMDAVCDecode -bool YES
defaults write com.apple.AppleGVA gvaForceAMDHEVCDecode -bool YES

This was enough in order to get smooth GPU accelerated Video playback (SwordSmith, jellyfish (400Mbs),.. ) on my MacPro 5.1 2010, Vega56.

So there is no need to disable SIP in order to tweak any system-files.

Tried this for my MSI Armor RX 580, VideoProc still doesn't show anything available. Is that a cosmetic bug ? - I let my Videoproc free registration lapse . . . is registration required to show if H264 or HEVC are enabled ?

 

[Ludacrisvp]

Registration is *not* needed.

 

[maccan]

Tested, the HEVC hardware decode can be activated by this method. However, the same bug as 10.14.0. Only the first video playback is smooth. After that, must completely quit the player, then re-open again to play another video correctly.

You may try to play the SwordSmith video in QuickTime Player, then close the player window but do NOT quit QuickTime Player. Then try to play the same SwordSmith video again. Most likely you can see the bug.

Besides, no hardware encode can be activated by this method.

You are right!
I have exactly the same behaviour. Without quitting Quicktime player, the second video playback is not GPU accelerated any more. Iina behaves the same way!. However I can live with that. Quitting Quicktime and restarting it for the next movie isn't that much an overhead if you watch videos occasionally like I do. At least you are able to play high resolution videos without modifying any system files and risking system instabilities in some conditions.

Furthermore, maybe it is better to disable GPU encoding anyway if you have one graphics card installed only.
(defaults write com.apple.AppleGVA gvaForceAMDAVCEncode -bool NO)
It might be that the user interface becomes sluggish if the single GPU is fully absorbed by the encoding process. By encoding on the CPU, you can control the amount of resources used for the encoding process by specifying the number of threads in the encoding software.

 

[quattro4ever]

hi,
I did everything with #1 and I have doubts whether everything is ok,
handbrake uses more than 1600% of CPU, GPU is idle,

VideoProc shows H264 Available, HEVEC Unavailable,
when I start converting the video file the program shows up Hardware Intel CPU Nvidia and AMD are greyed,

when i played video 2160p HEVC with IINA its smooth, no skips,

my config:
Vega64
12Core 3,06 GHz
Mid 2012
Mojave 10.14.6
112 GB RAM 1333 MHz

 

[h9826790]

You are right!
I have exactly the same behaviour. Without quitting Quicktime player, the second video playback is not GPU accelerated any more. Iina behaves the same way!. However I can live with that. Quitting Quicktime and restarting it for the next movie isn't that much an overhead if you watch videos occasionally like I do. At least you are able to play high resolution videos without modifying any system files and risking system instabilities in some conditions.

Furthermore, maybe it is better to disable GPU encoding anyway if you have one graphics card installed only.
(defaults write com.apple.AppleGVA gvaForceAMDAVCEncode -bool NO)
It might be that the user interface becomes sluggish if the single GPU is fully absorbed by the encoding process. By encoding on the CPU, you can control the amount of resources used for the encoding process by specifying the number of threads in the encoding software.

The video engine is a separated hardware in the GPU. It won't quite affect other process in general. At least, usually much less impact than using CPU. Of course, the video engine still demand VRAM, that may cause the biggest impact if other software also looking for more VRAM.

Of course, this is your own choice. If you need full GPU power for something else, then yes, you should use CPU encoding.

Fully quite a player is simple. But for video editing, which may means need to fully quite the editor, that's another story. Also, you can't just fully Quicklook preview like other players (highlight the video file in finder, and press space bar to watch it), that can also be a bit annoying.

Anyway, it's always good to have one more option. We can pick the best option we need.
[automerge]1574956732[/automerge]

hi,
I did everything with #1 and I have doubts whether everything is ok,
handbrake uses more than 1600% of CPU, GPU is idle,

VideoProc shows H264 Available, HEVEC Unavailable,
when I start converting the video file the program shows up Hardware Intel CPU Nvidia and AMD are greyed,

when i played video 2160p HEVC with IINA its smooth, no skips,

my config:
Vega64
12Core 3,06 GHz
Mid 2012
Mojave 10.14.6
112 GB RAM 1333 MHz

Which version of Handbrake?

What's the encoding setting? Did you choose H.264 (VideoToolbox)?

Anyway, VCE was working in your case. HW encoding should be working. The high CPU usage may because of the source video. Is that a HEVC video? Or some very high bitrate H264 video? Handbrake seems won't use UVD to decode the video source. That can become a huge bottleneck.

 

[quattro4ever]

Handbrake
Version 1.3.0 (2019110900)

the settings don't change anything, it's always the same,
the CPU works like a horse and the GPU is lazy

I tried different video files, GoPro4, HEVC from the internet, always the same

Compressor
HandBrake
VideoProc
each app gives the same results

 

[h9826790]

Handbrake
Version 1.3.0 (2019110900)

the settings don't change anything, it's always the same,
the CPU works like a horse and the GPU is lazy

I tried different video files, GoPro4, HEVC from the internet, always the same

Compressor
HandBrake
VideoProc
each app gives the same results

Please use the terminal command to determine if HWAccel is working properly (e.g. in your case, VCE was working, which means the encoding was handling by the GPU. And UVD was not working, so, the decoding part was handled by the CPU). I don't know if the video engine's loading can be accurately reflected in Activity Monitor's GPU usage.

From my own observation, in the latest Mojave, even my Radeon VII is working very hard to convert a video from HEVC to H264, the GPU usage in Activity Monitor may still below 10%. I won't be too surprised for that. The compute engine and 3D engine still doing nothing. The overall GPU usage can be considered very low indeed.

In order to know HWAccel performance. You can compare the converting performance. This will give you a better idea.

e.g. In handbrake, use VideoToolbox to perform GPU encode, 142 FPS, about 700% CPU usage.

Switch to X264 (CPU encode), same default setting, 33FPS, 1200% CPU usage.

So it's about 4x faster by using GPU with lower CPU usage.

If you want the whole decoding and encoding handle by the GPU, my recommendation is to use FFMpeg

e.g. From HEVC to H264.

FFmpeg -hwaccel videotoolbox -i HEVC.mkv -vcodec h264_videotoolbox -b:v 12000k -c:a copy H264.mp4

This will ensure that both decode and encode will be handled by the GPU. In this case, you should see a very low CPU usage, but still very fast encoding. However, this may not give you the best result. In some case, let the CPU do the decoding part, and let GPU handle the encoding part may be faster.

e.g.

FFmpeg -i HEVC.mp4 -vcodec h264_videotoolbox -b:v 18000k -c:a copy H264.mp4

 

[h9826790]

Anyway, the performance gain really depends on the source videos codec or setting.

e.g. By using Handbrake to convert the Swordsmith HEVC video into H264. Use the 4K Youtube preset (CPU encoding), that's about 12FPS, 1200% CPU usage.

If I select VideoToolbox but leave everything else as per the Youtube 4K default. Then GPU will handle the encoding, 27FPS, 800% CPU usage.

In this particular case, my video converting performance was limited by the CPU decoding performance.

So, if I let FFMpeg to do the job, force the GPU to decode the HEVC video as well, to output a 18000kbps 4K video, it becomes 54FPS, 20% CPU usage.

So, in this case, using full HWAccel give me ~4x better performance, and much much lower CPU usage.

If only use GPU encode, about 2x performance, and noticeably lower CPU usage.

 

[quattro4ever]

Please use the terminal command to determine if HWAccel is working properly (e.g. in your case, VCE was working, which means the encoding was handling by the GPU. And UVD was not working, so, the decoding part was handled by the CPU). I don't know if the video engine's loading can be accurately reflected in Activity Monitor's GPU usage.

From my own observation, in the latest Mojave, even my Radeon VII is working very hard to convert a video from HEVC to H264, the GPU usage in Activity Monitor may still below 10%. I won't be too surprised for that. The compute engine and 3D engine still doing nothing. The overall GPU usage can be considered very low indeed.

In order to know HWAccel performance. You can compare the converting performance. This will give you a better idea.

e.g. In handbrake, use VideoToolbox to perform GPU encode, 142 FPS, about 700% CPU usage.
View attachment 879721

Switch to X264 (CPU encode), same default setting, 33FPS, 1200% CPU usage.
View attachment 879722

So it's about 4x faster by using GPU with lower CPU usage.

If you want the whole decoding and encoding handle by the GPU, my recommendation is to use FFMpeg

e.g. From HEVC to H264.

FFmpeg -hwaccel videotoolbox -i HEVC.mkv -vcodec h264_videotoolbox -b:v 12000k -c:a copy H264.mp4

This will ensure that both decode and encode will be handled by the GPU. In this case, you should see a very low CPU usage, but still very fast encoding. However, this may not give you the best result. In some case, let the CPU do the decoding part, and let GPU handle the encoding part may be faster.

e.g.

FFmpeg -i HEVC.mp4 -vcodec h264_videotoolbox -b:v 18000k -c:a copy H264.mp4

ok
my video settings:

Handbrake VideoToolbox avg 18 fps 1700-2000% CPU usage
Handbrake X264 avg 15 fps and again 1700-2000% CPU usage


same situation with "Sony Swordsmith HDR UHD 4K Demo.mp4"
it doesn't matter what kind of encoding I choose, the CPU does all the work

 

[h9826790]

ok
my video settings:
View attachment 879740

Handbrake VideoToolbox avg 18 fps 1700-2000% CPU usage
Handbrake X264 avg 15 fps and again 1700-2000% CPU usage


same situation with "Sony Swordsmith HDR UHD 4K Demo.mp4"
it doesn't matter what kind of encoding I choose, the CPU does all the work

That's the source video parameters, not the Handbrake encoding setting. Anyway, doesn't matter.

It seems you tried FFMpeg already. How's the CPU loading on that one?

To me, it looks like your HWAccel is working as expected.

Despite I own a dual processors tray before, I never really used it. So, not that familiar with the 24 cores CPU usage in Handbrake.

However, your performance comparison looks like the expected result to me.

Anyway, I downloaded the identical source video as yours and run the test.

A) CPU only in Handbrake

B) CPU decode, GPU encode in Handbrake

C) GPU only in FFMpeg

So, let start to analysis.

1) In your case, 18FPS vs 15FPS is 20% improvement, not "within error margin"

2) My comparison was done with single W3690 vs Radeon. In your case, dual X5675 vs Vega 64.

Since dual X5675 is about 1.85x faster than single W3690, and Radeon VII is about 19% faster than Vega64 (average, I have no idea if Radeon VII's video engine is faster than Vega64).

Therefore, if my GPU encoding was 2.12x faster than CPU in Handbrake. In your case, that should be about 2.12 x 0.54 x 0.84 = 96%. Which means "may not able to see the gain", or even "CPU only is faster."

Of course, this is just the prediction, and doesn't account for any possible bottleneck change in different cases. In reality, GPU encoding still 20% faster in your case.

3) As I said before, CPU still need to handle the decoding. So, expect high CPU usage in Handbrake regardless use GPU encoding or not. However, almost identical CPU usage in both cases are really weird.

As I show you in my screen captures, the CPU loading difference is quite obvious.

4) When you use FFMpeg to force GPU decode, you get 23FPS, which is 53% faster than pure CPU encode in Handbrake. And if you have similar CPU / GPU usage as my case "C" screen capture, then your HWAccel is definitely working.

 

[maccan]

The video engine is a separated hardware in the GPU. It won't quite affect other process in general. At least, usually much less impact than using CPU. Of course, the video engine still demand VRAM, that may cause the biggest impact if other software also looking for more VRAM.

Of course, this is your own choice. If you need full GPU power for something else, then yes, you should use CPU encoding.

Fully quite a player is simple. But for video editing, which may means need to fully quite the editor, that's another story. Also, you can't just fully Quicklook preview like other players (highlight the video file in finder, and press space bar to watch it), that can also be a bit annoying.

Anyway, it's always good to have one more option. We can pick the best option we need.
[automerge]1574956732[/automerge]


Which version of Handbrake?

What's the encoding setting? Did you choose H.264 (VideoToolbox)?
View attachment 879684

Anyway, VCE was working in your case. HW encoding should be working. The high CPU usage may because of the source video. Is that a HEVC video? Or some very high bitrate H264 video? Handbrake seems won't use UVD to decode the video source. That can become a huge bottleneck.

Thanks for the hints!

I first tried the full Info.plist method (modifying the
/System/Library/PrivateFrameworks/AppleGVA.framework/Resources/Info.plist
and applying the 4 defaults write commands)

However, by doing so, I got several system crashes in various situations. Most of the crashes I got when transcoding VP9 encoded videos to HEVC using ffmpeg. In one situation I got a system crash when I was putting the system to sleep. I absolutely NEVER had system crashes under 10.14.6 before. Since video isn't my business, I decided to get back stability and reinstalled a clean 10.14.6 (I can do this quite easily since my user account folder resides on another disk). So I get stability back again! Then I tried to get at least HEVC decoding without touching the system. And so I came up with the 4 default write commands without anything else. And in fact it turned out that

defaults write com.apple.AppleGVA gvaForceAMDKE -bool YES

is all you have to do if you just want to play demanding HEVC videos like 'SwordSmith' smoothly.
The command creates the file '~/Library/Preferences/com.apple.AppleGVA.plist' in your user-account.
I did not detect any other changes. You can undo the whole procedure by simply executing
'defaults delete com.apple.AppleGVA gvaForceAMDKE' or deleting the file '~/Library/Preferences/com.apple.AppleGVA.plist' in your home folder.
No log-out/in or even reboot is required. So if your goal is just HEVC smooth playback, the single 'defaults write com.apple.AppleGVA gvaForceAMDKE -bool YES' instruction is all what needs to be done, keeping your system stable (I hope so, but I did not get any system-crash since then).

What's about your system-stability?

 

[h9826790]

Thanks for the hints!

I first tried the full Info.plist method (modifying the
/System/Library/PrivateFrameworks/AppleGVA.framework/Resources/Info.plist
and applying the 4 defaults write commands)

However, by doing so, I got several system crashes in various situations. Most of the crashes I got when transcoding VP9 encoded videos to HEVC using ffmpeg. In one situation I got a system crash when I was putting the system to sleep. I absolutely NEVER had system crashes under 10.14.6 before. Since video isn't my business, I decided to get back stability and reinstalled a clean 10.14.6 (I can do this quite easily since my user account folder resides on another disk). So I get stability back again! Then I tried to get at least HEVC decoding without touching the system. And so I came up with the 4 default write commands without anything else. And in fact it turned out that

defaults write com.apple.AppleGVA gvaForceAMDKE -bool YES

is all you have to do if you just want to play demanding HEVC videos like 'SwordSmith' smoothly.
The command creates the file '~/Library/Preferences/com.apple.AppleGVA.plist' in your user-account.
I did not detect any other changes. You can undo the whole procedure by simply executing
'defaults delete com.apple.AppleGVA gvaForceAMDKE' or deleting the file '~/Library/Preferences/com.apple.AppleGVA.plist' in your home folder.
No log-out/in or even reboot is required. So if your goal is just HEVC smooth playback, the single 'defaults write com.apple.AppleGVA gvaForceAMDKE -bool YES' instruction is all what needs to be done, keeping your system stable (I hope so, but I did not get any system-crash since then).

What's about your system-stability?

My system has perfectly stability in 10.14.6 with HWAccel.

Anyway, I must remind you that my original method not just mod the plist file, and no need to be used with those default write command.

If you don’t want to mod any system file, the Lilu + WEG method works very well. Of course, if you don’t want any 3rd party next as well, then not much you can do.

As I said before, those default wire command can allow you to decode HEVC via HWAccel, but obviously buggy (need fully quit the software every single time after you play a HEVC video). And I don’t know how much this affect the system stability.

I tried to get HWAccel work in MacOS On cMP for years. And achieve almost nothing until 10.14.0 beta. And from memory, perfect stability since 10.14.5 beta.

I’ve tried those default write command many times under different situations. End up didn’t use them at all in my guide, because they have little to no effect. At least not to the level that I want.

At this moment, my recommended method is Lilu + WEG (if don’t need HEVC encoding). The most stable way.

Modding the AppleGVA can also work stably (not just the associated plist). However, I suspect that may cause memory leak in lsd (not 100% confirm yet, in fact, that’s just my own observation, no one report that so far).

OpenCore of course is the most powerful way, which gives us full HWAccel. However, side effect to the BootROM still under investigation. On my cMP, it works, didn’t brick anything yet. But the protential risk is there.

 

[maccan]

My system has perfectly stability in 10.14.6 with HWAccel.

Anyway, I must remind you that my original method not just mod the plist file, and no need to be used with those default write command.

If you don’t want to mod any system file, the Lilu + WEG method works very well. Of course, if you don’t want any 3rd party next as well, then not much you can do.

As I said before, those default wire command can allow you to decode HEVC via HWAccel, but obviously buggy (need fully quit the software every single time after you play a HEVC video). And I don’t know how much this affect the system stability.

I tried to get HWAccel work in MacOS On cMP for years. And achieve almost nothing until 10.14.0 beta. And from memory, perfect stability since 10.14.5 beta.

I’ve tried those default write command many times under different situations. End up didn’t use them at all in my guide, because they have little to no effect. At least not to the level that I want.

At this moment, my recommended method is Lilu + WEG (if don’t need HEVC encoding). The most stable way.

Modding the AppleGVA can also work stably (not just the associated plist). However, I suspect that may cause memory leak in lsd (not 100% confirm yet, in fact, that’s just my own observation, no one report that so far).

OpenCore of course is the most powerful way, which gives us full HWAccel. However, side effect to the BootROM still under investigation. On my cMP, it works, didn’t brick anything yet. But the protential risk is there.

'..., the Lilu + WEG method works very well.'
But it requires to turn of SIP right?

 

[h9826790]

'..., the Lilu + WEG method works very well.'
But it requires to turn of SIP right?

I always keep SIP off, but you can turn it on after kext installation by using the following command in recovery partition.

csrutil enable --without kext

 

[MIKX]

My poor old eyes can't find the the terminal command to determine if HWAccel is working properly.

Can someone post it again please?

 

[h9826790]

Post #1 Q22

https://forums.macrumors.com/thread...re-acceleration.2180095/page-11#post-27484973

 

[kohlson]

if HWAccel is working properly

I just keep a local copy of the jellyfish file. If it plays, HWAccel is working.

 

[MIKX]

Post #1 Q22

https://forums.macrumors.com/thread...re-acceleration.2180095/page-11#post-27484973

Thanks, got it.