How did you do this ? I installed 12.5 here with Opencore 0.49. Everything is fine except for the hardware acceleration of my Radeon 580RX . Jessi from the YouTube consultants' forum has now recommended that I simply have to exchange the OC folder with that from Martin Lo. So I downloaded his latest package 0.80 and simply replaced it on the EFI partition. With the result:Hardware acceleration is on. WOW ! Super . But now i have no Bluetooth anymore. I followed Martin's tips from his Youtube video regarding Bluetooth and made changes to his Config.plist. With the result: Bluetooth still doesn't work. How did you do that ? I would be very grateful if BOTH would work for me. With one OC group, one thing works, with the other group, the other. Why don't people can work together ;-)
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
MP 1,1-5,1 Activate AMD hardware acceleration
- Thread starter h9826790
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
h9826790's version works only on a stock Mac Pro 5,1 up to Big Surf. It has no bluetooth and wifi drivers for 12.4. It is not about the Opencore but the drivers in the Monterey. You must use the OpenCore Legacy Patcher that it can support to both Opencore and drivers at once in Monterey on a stock Mac Pro 5,1
No ! not on my Stock Mac Pro 5.1 !! All the time I have used the OC Legacy Patcher (also Vers. 0.49) there is no HWAcc but Bluetooth support and everything else - that's fine, except just hardware support for the graphics card. That´s right. With the Package (OC 0.80) from h9826790, I have HWAcc on my Radeon RX580. But no Bluetooth and WIFI. Until now I always have to swap the two OC folders, depending on the need. That's superfluous and actually unnecessary. I hoped to get a solution from you that both works. If you want to test it... As a photographer, a always use the DXO Software and export a RAW file with Noise reduction DEEP PRIME. And there is a very very very huge difference with or without the HWAcc with the GraphicCard. I tried the tips from h9826790, th change some settings in the config, plist to activate Bluetooth , but it is not working. And the other fraction with the OCLP 0.49. doesn't seem to have the right settings in their patcher for the Radeon RX580 so I can use the card's hardware support.
Perhaps you can run a diff on the two configuration files though I'm afraid you will still have to sort though a lot of differences between Martin's OC and OCLP, to find what they are doing in OCLP to make things work for you. That said I have basically the same machine as Martin (Mac Pro 5.1) where some time ago I replaced the Bluetooth / WiFi module to avoid having to deal with this issue as well as others. Perhaps in the end that could be your best solution, getting more recent hardware in your machine.
ok, ok, but i just wanted to avoid that. theoretically, the other faction can do this without any problems! with the OCLP 0.49. everything goes smoothly. Just not the hardware acceleration. MArtin apparently solved and managed this wonderfully. Thanks for that great!! but why shouldn't it also be able to implement Bluetooth support! ? Or the other way around. Maybe I'm a bit naive as a common professional photographer, but why can't you have both in one patcher? i have first OCLP 0.47. had and 12.4. then I installed the OCLP 0.49 and then 12.5. and then I just swapped out Martin's 0.80 patcher pack to determine these things... I agree with you, but I shy away from spending money on an old device and don't necessarily have to fiddle around with it.... ;-) But it's probably the best solution
developers of projects like this thread's OC package (and other alternatives you mentioned) end up having to make compromises with what works "plug-and-play" and what needs further user tweaking. the compromises they make are reasonable, inevitable, and always evolving. in order to explain to you why BT is not working in your particular system would require a rather long reply with lots technical explanations. but most of that info can be found and read in existing threads in this same MacPro sub-forum. first suggested step would be for you to become more informed as to why BT has been having issues with the latest 1-2 macOS versions, search keywords "BT issues Monterey" and the similar -- you will end up with many results to review. anyway, the simple answer you have already gotten: the easiest and cleanest way to fix the BT issue is to upgrade your BT/Wifi card, the following thread gives all the info you need to do that:
802.11ac, BT 4.0, Continuity, and Handoff Working on Mac Pro 2010
-------------------------------------------------------------------------------------------------------------------------------------- -------------------------------------------------------------------------------------------------------------------------------------- News&Updates: (I will...
forums.macrumors.com
I see. The GPU hardware acceleration (if your graphic card model is supported) can be enabled thru enabling all these options in the SIP setting of the Opencore Legacy Patcher. You need to check them all like in the photo before proceeding to install the Build and Install Opencore button. Also, be remember to run the Post Install Root Patch button after a reboot.
*** Updated. Just upgraded to 12.5 with Opencore Legacy Patch v0.49.
Both Wifi/Bluetooth + Vega 56 GPU Hardware Acceleration working fine on a stock Mac Pro 5,1 (2010).
Last edited:
Has anyone tried editing 8K HVEC video in Final Cut Pro X with a video accelerated GPU?
I tried and everything stutters a lot. I was hoping the RX6800 allows the timeline to be smooth but it seems to be using CPU instead of GPU for timeline.
I checked videoproc and it's green for both H264 and HVEC.
On my iMac Pro same video is stuttering as well but that has a Vega 56 with no HVEC support so makes sense.
On my M1 MBP its smooth, but I was hoping to make full use of the RX6800.
I tried and everything stutters a lot. I was hoping the RX6800 allows the timeline to be smooth but it seems to be using CPU instead of GPU for timeline.
I checked videoproc and it's green for both H264 and HVEC.
On my iMac Pro same video is stuttering as well but that has a Vega 56 with no HVEC support so makes sense.
On my M1 MBP its smooth, but I was hoping to make full use of the RX6800.
Attachments
Last edited:
Interesting you mention this. On videoproc, it also shows 4K for me as well. However, everywhere I look online, it says the Navi 2x GPUs should do 8K HVEC support. So I wonder if it's a macos thing or something else.
Attachments
Unfortunately, it wouldn't do 8K smooth well. It is because the Mac Pro 5,1 comes with PCI-e 2.0. Which can provide up to around 8GBps only in a 16x lane/slot. Which is far less than the 8K video editing requirement no matter how powerful your GPU is. It's the bottleneck of PCI-e 2.0. Editing a 4K video is barely ok.
8K HEVC is a piece of cake for PCIe 2.0 x16. We are talking about ~1500MB/s of throughput in real world. That means can handle up 12000Mbps bitrate's video.
So far, I haven't see a HEVC video has higher than 1000Mbps. In general, 100Mbps is quite high already. For streaming, 40Mbps usually is good enough for nice picture quality even at 8K.
Which means PCIe 2.0 x16 is good enough to send three hundred 40Mbps 8K HEVC videos to the video card to decode at the same time. And now, we only need to do one.
So, PCIe 2.0 x16 can't be the issue here.
Even ProRes, only the 8K 60FPS 4444 XQ need more than 12000Mbps. If we use ProRes 422, then even 8K 60FPS only need 5028Mbps. Way below PCIe 2.0 x16 can provide.
I really don't know this problem until you raise it. At this moment, I tend to believe that's macOS driver / API related. If VideoToolBox don't send any 8K HEVC video to the AMD GPU, then there is nothing the VCN can do.
If you have Windows, highly likely you can play the same 8K HEVC video smoothly in DV timeline (Since no FCP in Windows, therefore, I suggest DV as a free alternative for testing purpose)
That's not truth about how a real world does. It's not the way it works. In a FCP editing timeline. Multiple clips are being loaded concurrently which means more than 1 clips are loaded and multiple effects are also loaded too. Therefore, when editing to a 8k video. The performance could be significantly impacted by:
- The no. of 8k clips concurrently loaded in a timeline.
- Whether the applied FCPX effects are GPU hardware acceleration supported. If not. The 8k effect is processed by CPU only that could be 10 times slower than the processing speed of a GPU.
- The size of a 8k footage is very large comparing to 4k and 1080p footage. The SSD must be a MLC SSD (such as Samsung 970 Pro, SM961..etc). Not a TLC or QLC (Samsung 970 EVO, 980 Pro...etc). Otherwise, the SSD's cache could be filled up very fast within the first 45 seconds by just 1 single clip. Therefore, only a MLC SSD can process multiple very large or 8K files at the same time without a stalling performance issue. If the Mac doesn't have a MLC SSD. That could also be a key factor for slower the performance of editing multiple large 8k video files.
Therefore, the bandwidth of PCI-2.0 is not enough for processing a 8K video in real life under a practical editing circumstance anyway. If it just to playback a 8K video only without any effect applied. It is barely ok.
Apart from the GPU performance. It is also highly depended on whether the Mac comes a MLC SSD or not. That's why the price of a NvME MLC SSD is twice of NvME TLC/QLD SSD. The TLC/QLD SSD is ok for office work or gaming but not really ok for the professional video editing. It would just keep lagging.
Last edited:
The numbers doesn't support your theory.
As I said, PCIe 2.0 x16 can handle 12000Mbps per second. Even the video has 1000Mbps bitrate (which is ridiculously high for HEVC video). The timeline can still hold 10 of those 8K video, but still hasn't saturate the PCIe bandwidth yet.
For ProRes, that may be an issue if there are multiple 8K videos in the timeline. But for HEVC, that doesn't make any sense. In general, HEVC video won't have bitrate higher than 200Mbps. 12000Mbps means the timeline can hold 60 of those videos (in a single frame). Which is way beyond normal video editing.
Even a SATA 2 connected SSD can play 8K HEVC smoothly without any problem. As I said, 200Mbps is already very high bitrate for HEVC, but that still just means 25MB/s. A 250MB/s connection can play 10 at the same time already.
Again, for ProRes, that can be the issue, but not HEVC.
What you say about running out of cache, that's for writing into the SSD. When playing the timeline, that's reading from the SSD, QLC or not shouldn't be an issue, unless that SSD has very low reading performance.
I fully respect your theory / experience, but that seems more true for ProRes, not for normal HEVC videos.
In OP's case, I tends to believe his 8K HEVC video can't be decoded by the GPU due to macOS limitation. And the cMP's CPU almost sure impossible to decode that in real time as well. Therefore, the timeline can't be played smoothly. Which has nothing about TLC / QLC or PCIe 2.0
Of course, no matter PCIe 2.0 or CPU, that still can't be fixed on the cMP anyway.
But if it's the macOS limitation. Then OP most likely can do that in Windows without any problem.
May be you even don't have experience for professional editing. The HEVC doesn't work well even in a FCPX 4K timeline with the hardware acceleration enabled for GPU. Conversely, The ProRes does. Because ProRes is an uncompressed format. All FCPX tutorials would advise you first to decompress your footage to ProRes before further processing if you don't want to encounter performance issue. That's why when you import a footage to FCPX. By default, it would prompt for whether you want to import as ProRes or not no matter whatsoever video format your footage in.
Due to the footage is decompressed in ProRes, The GPU doesn't have to do a on-the-fly decompression along with the effects anymore during the timeline editing. So it would only end up with a faster and smoother editing performance. The HEVC not.
Therefore, your theory is really just a guessing the way you want it how to work. Without a practical experience. And your GPU hacking-share in this thread even doesn't work on Monterey 12.4 afterward with bluetooth and wifi supported.... These are the facts about your shares... "Not working!, depressive failed!! and pretend it's working!!!"
Last edited:
Sure I am not as professional as you do in video editing.
Yes, I know HEVC is highly compressed, won't work as good as ProRes in the timeline. However, that won't change the fact that HEVC need way less bandwidth and throughput. And PCIe 2.0 x16 should't be an issue (this is what our debating topic so far).
You may suggest him use ProRes rather than HEVC.
However, once he use ProRes, then PCIe 2.0 x16 / storage speed really can be the bottleneck. ProRes is easy to decode, but the down side of uncompressed video is that extremely high bitrate. PCIe 2.0 x16 can only handle up to three 8K 60FPS ProRes 422 videos at the same time. If he need more than 3 in the timeline, then ProRes is also a dead end for him, no matter how good it is for video editing.
Of course, he can use ProRes Proxy, then problem fixed. But I don't know if that fit his workflow's requirement.
No, it is relevant. In this part, you also have no experience. If you try the same GPU card model (e.g Vega 56) on a more recent Mac model (e.g iMac 2018) comparing the same GPU model on a Mac Pro 5,1. Even the HEVC footage with effect applied in a timeline would experience less lagging on the iMac. It's due to the PCI-e on the iMac is a PCI-e 3.0. You just didn't try out the result before telling false information which is de-railed from the fact and the actual result.
I tried this comparison in Apple store myself. So I can tell.
Your comparison is valid, however, the conclusion is not.
How can you tell the difference isn't coming from other hardware (e.g. higher single CPU thread performance, faster RAM, etc)?
It's not your test result not valid. But you said "PCIe 2.0 x16 is the bottleneck for 8K HEVC video)", and the number just doesn't match this theory.
We may conclude that the cMP is a dead end for 8K HEVC video editing. However, we cannot conclude that's due to PCIe 2.0 x16. Please stay objective.
I am not telling false information. All me argument has numbers to backup.
I must emphasis that I am also not saying your test result / observation isn't valid. It's just the "PCIe 2.0 x16" cannot be the reason in his case because he is talking about HEVC video which only need very little bandwidth. His problem can be the CPU is too old etc. I cannot argue that. However, if you conclude that must be because of PCIe 2.0 x16, then please provide further explanation.
e.g. For ProRes, we can easily work that out.
Apple provide a table for the target bandwidth here (P.22)
If he said he can never play a 8K 60FPS ProRes 4444 XQ video smoothly on the cMP. Then we can know straight away because the required bandwidth is at least 16970Mbps, but PCIe 2.0 x16 can only provide ~12000Mbps in real world.
But since he said HEVC video, there is no such issue.
If you insist that must because of PCIe 2.0 x16, but not from any other hardware difference. Then please provide your explanation. I am completely happy to learn from your analysis.
Anyway, I assume you were talking about the Vega 56 in a iMac Pro 2017. There is no iMac 2018 has Vega 56 inside. And since you mentioned that you ran the tests in Apple store, then it shouldn't be any self created eGPU with any iMac. Therefore, I assume that's a iMac Pro.
So apart from the better CPU and better RAM in the iMac Pro. There is one more unknown factor, which is the T2. So far, we still cannot rule out the iMac Pro may use T2 to decode / encode HEVC video. Therefore, the performance difference you mentioned may also because T2 was the decoder, and there is no such equivalent hardware can be installed onto the cMP.
I am completely happy to conclude that the iMac Pro kill the cMP in HEVC video editing. However, I just cannot conclude that PCIe 2.0 x16 is the limitation, because the number's doesn't match.
A proper test of PCIe bandwidth affects would be to use the same GPU in the same computer and adjust the PCIe bandwidth. For this you probably need a hackintosh that can change the bandwidth of the PCIe slot. For example, my Gigabyte GA-Z170X-Gaming 7 motherboard has two PCIe 3.0 x16 slots that can be converted to PCIe 3.0 x8 when they are both occupied. PCIe 3.0 x8 is similar to PCIe 2.0 x16.
I suspect the difference between 11 GB/s and 5 GB/s will have little affect since 5 GB/s should be plenty. Perhaps the issue is software or hardware or software that differs because the hardware differs.
Your point that PCIe 2.0 compared to PCIe 3.0 doesn't affect some tasks is true. The question is whether editing 8K HVEC video in Final Cut Pro X is one of those tasks.
In the case of the classic Mac Pro, you can't add PCIe 3.0 x16 to see if the problem goes away. However, you can compare with PCIe 2.0 x4 to see if the problem gets worse.
In the case of a Mac that supports Thunderbolt, you can put the GPU in a Thunderbolt enclosure (usually PCIe 3.0 x4).
With any PCIe slot, you can compare x16, x8, x4, or x2 with x8, x4, x2, or x1 by taping off some pins or using a riser that has fewer lanes than the slot.
https://www.amazon.com/dp/B0039XPS5W
https://www.amazon.com/PCI-Express-1X-16X-Electronics/s?k=PCI+Express+1X+to+16X&rh=n:172282
As an Amazon Associate, MacRumors earns a commission from qualifying purchases made through links in this post.
That's correct, but for this particular scenario, I think we better run the test on a PICe 3.0 x16 computer that's known can play / edit 8K HEVC video smoothly. Then we limited it's bandwidth to PCIe 3.0 x8.
This can rule out everything, but solely check if PCIe 2.0 x16 (which very close to PCIe 3.0 x8 in real world) is enough for that particular job.
Even PCIe 2.0 x4 make thing worst, but still can't clear the question if PCIe 2.0 x16 is the limitation in that case.
As an Amazon Associate, MacRumors earns a commission from qualifying purchases made through links in this post.
I have a MacMini 2018 with 5700 EGPU and the performance I worst than on a MacBook Pro 2018 with internal 580 GPU.