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
Nothing special, I have more elaborate configs for debug SMBIOS and spoofing, but this one works already:
Your entry is NOT the same as my suggestion (from your attached config.plist file), e.g. you set Enabled = false.
That's why I recommend you replace that whole section by my code.
I use OC configurator and the check mark is not visible until you scroll to the right. Now I have enabled it and waiting for it to boot (I do screen sharing remotely). MFC sees the fans but the sensors are only from the board Id you inject not the cMP. Hopefully it will not overheat.
Good evening guys, first of all I wanted to congratulate many of you for the skills you have in the software field and that you share with us all. I did not have all this familiarity and knowledge I have to limit myself to read you and hope for simple tutorials in order to get what you discover ... and therefore to thank you publicly is the least I can do.
I would also be interested in obtaining from the configuration I have in signature the coding and decoding of h264 and hevc through OpenCore with settings that are stable for my Macpro 5.1
Do I need to follow the first post to the "OpenCore on the Mac Pro" discussion step by step?
I would also be interested in obtaining from the configuration I have in signature the coding and decoding of h264 and hevc through OpenCore with settings that are stable for my Macpro 5.1
Do I need to follow the first post to the "OpenCore on the Mac Pro" discussion step by step?
Even if we proved that hardware encoding can be enable with MP5,1, it's a convoluted process with various questions of safety in the long run and it's easy to make a mess now.
We are actively talking with OpenCore developers to facilitate the configuration and trying to remove the need of SMBIOS spoofing, they seem open to our needs but they didn't get it yet. For now, it's better to just wait and see.
At this point you have to have a contingency plan for firmware recovery (either by desoldering and reflashing the firmware or install a MATT card) in case the firmware bricks. Or you can use non OC methods which should be safe for your firmware.
You may use Hardware Monitor to monitor the temperatures.
Also, avoid MacsFanControl now. It's not safe to use in this case. You can't set it to base on any temperature sensors. And if you manually spin up the fan. You will completely override the safety protection.
Therefore, I suggest you switch to smcFanControl. And use it to set a higher minimum fan speed. So that, the cMP will still able to run cooler than the stock fan profile, but the fans will also spin up when something warming up.
Of course, you can invest TG-Pro as well. It can see more sensors, and build fan profile according to those readings. However, it can be quite time consuming to build the fan profile properly in TG-Pro. Also, from my own test. TG-Pro can always see the sensors (after activate Hackintosh support), but not always allow users to build fan profile base on those sensors (may still stuck with the sensors that only available in non Hackintosh mode).
I thank you and since things are evolving, I will wait for news in this regard. I have no urgent haste, I prefer to try when the settings show a certain reliability. Thanks again for the work you are doing.
[automerge]1573158992[/automerge]
Thanks also to you, but I should perhaps wait when and if there will be a simplified procedure without so many twisted things.
Like @startergo said, you can enable h264 hardware encoding and HEVC decoding with AppleGVA edit or Lilu/WTG methods safely, just wait on OpenCore if you don't have a MATT card or a replacement backplane on hand. Something a long the way is messing with the NVRAM area and this can cause booting problems or even bricking if you already have binary blobs inside the 1st and 2nd stores of the NVRAM volume, like the ones saved by NVIDIA drivers when using TITAN GPUs, for example.
Btw, the credits for this are all @h9826790, I just helping with things that I'm more familiar when I can.
Last edited:
ok for now i stay with h264 hardware encoding and HEVC decoding with AppleGVA edit.
Maybe when you think that everything is easier to use let us understand clearly .... maybe with a special topic.
So if the merit is of @h9826790 I also give many thanks and good work.
We are trying to use WTG to do the PSX* rename and enable encoding without SMBIOS spoofing, that's why we need WTG developers help.
Deleting imacpro1.1 identifier and adding :
to the boot argument of the OC:
Code:
-no_compat_check agdpmode=pikera shikigva=96 shiki-id=Mac-7BA5B2D9E42DDD94
Code:
-----------------------------------------------------------------------
System Info
-----------------------------------------------------------------------
Host G5.lan
OS macOS Catalina Version 10.15.1 (Build 19B88)
Kernel Darwin 19.0.0 x86_64
RAM 128.00 GB
Model Identifier MacPro5,1
CPU Intel(R) Xeon(R) CPU X5690 @ 3.47GHz
Intel Generation ???
Platform ID 0x00000000
Board ID Mac-F221BEC8
FW Version 144.0.0.0.0
Serial Number
Hardware UUID
System ID
ROM
Board Serial Number
VDA Decoder Fully Supported
-----------------------------------------------------------------------
Serial Info
-----------------------------------------------------------------------
Country Unknown
Year 2011
Week 12.17.2011-12.23.2011
Line 707 (copy 1)
Model MacPro5,1
Valid Possibly
-----------------------------------------------------------------------
GFX0
-----------------------------------------------------------------------
GPU Name Ellesmere [Radeon RX 470/480/570/570X/580/580X/590]
GPU Device ID 0x67DF1002
Quartz Extreme (QE/CI) Yes
Metal Supported Yes
Metal Device Name AMD Radeon RX 480
Metal Default Device Yes
Metal Low Power No
Metal Headless NoPlaying SwordSmith 4K video is smooth:
Code:
g5@G5 ~ % ioreg -l |grep \"PerformanceStatistics\" | cut -d '{' -f 2 | tr '|' ',' | tr -d '}' | tr ',' '\n'|grep 'HW\|Command'
"HWChannel KIQ
Commands Submitted"=0
"HWChannel VCE
Commands Submitted"=0
"HWChannel sDMA0
Commands Completed"=5035
"HWChannel VCELLQ
Commands Completed"=0
"HWChannel VCELLQ
Commands Submitted"=0
"HWChannel SAMU GPCOM
Commands Submitted"=0
"HWChannel SAMU RBI
Commands Completed"=0
"HWChannel GFX
Commands Completed"=2530
"HWChannel Compute1
Commands Completed"=2229
"HWChannel Compute1
Commands Submitted"=2229
"HWChannel UVDEnc
Commands Completed"=0
"HWChannel UVDEnc
Commands Submitted"=0
"HWChannel SAMU RBI
Commands Submitted"=0
"HWChannel SAMU GPCOM
Commands Completed"=0
"HWChannel UVDDec
Commands Completed"=2236
"HWChannel KIQ
Commands Completed"=0
"HWChannel GFX
Commands Submitted"=2530
"HWChannel Compute0
Commands Completed"=0
"HWChannel sDMA1
Commands Submitted"=5368
"HWChannel UVDDec
Commands Submitted"=2236
"HWChannel Compute0
Commands Submitted"=0
"HWChannel UVDEncLLQ
Commands Submitted"=0
"HWChannel Compute2
Commands Completed"=0
"HWChannel VCE
Commands Completed"=0
"HWChannel sDMA0
Commands Submitted"=5035
"HWChannel Compute2
Commands Submitted"=0
"HWChannel UVDEncLLQ
Commands Completed"=0
"HWChannel sDMA1
Commands Completed"=10135
g5@G5 ~ %Same result as my own tests. Anyway, you can remove boot argument agdpmode=pikera when boot as 5,1 or 7,1.
Can we not spoof AVX2 in the CPUID field together with the VMM flag? That may unlock HEVC?
Spoof something that we don't have?
HEVC encoding don't even run X86 code for the non-QuickSync Macs, encoding is run by the GPU with RISC SIMD.
Catalina don't requires AVX/AVX2, at least not yet. AFAIK, all supported Catalina Macs can run AVX, Apple can require it at will.
Last edited:
I think it would be good to suggest using newer versions of WEG and Lilu.
Was reading commits from WEG and noted for the 1.3.1 release about a fix that looks very useful to have.
I have noted that typically every other boot on my 3,1 results in Kernel Panic and some odd visual elements before the stage 2 loading before the desktop.
Apparently this is due to there being a VRAM test that writes into the framebuffer (beyond the VRAM) and causes the panic.
I updated WEG and Lilu to latest versions (1.3.4 / 1.3.9 respectively) and rebooted and had no FB corruption and no panic.
github.com
Was reading commits from WEG and noted for the 1.3.1 release about a fix that looks very useful to have.
I have noted that typically every other boot on my 3,1 results in Kernel Panic and some odd visual elements before the stage 2 loading before the desktop.
Apparently this is due to there being a VRAM test that writes into the framebuffer (beyond the VRAM) and causes the panic.
I updated WEG and Lilu to latest versions (1.3.4 / 1.3.9 respectively) and rebooted and had no FB corruption and no panic.
Disable VRAM testing on AMD GPUs on 10.14.4+ (based on vladie's patch) · acidanthera/WhateverGreen@bcd3f2e
Various patches necessary for certain ATI/AMD/Intel/Nvidia GPUs - Disable VRAM testing on AMD GPUs on 10.14.4+ (based on vladie's patch) · acidanthera/WhateverGreen@bcd3f2e
github.com
Code:
bool RAD::doNotTestVram(IOService *ctrl, uint32_t reg, bool retryOnFail) {
// Based on vladie's patch description:
// TestVRAM fills memory with 0xaa55aa55 bytes (it's magenta pixels visible onscreen),
// and it tries to test too much of address space, writing this bytes to framebuffer memory.
// If you have verbose mode enabled (as i have), there is a possibility that framebuffer
// will scroll during this test, and TestVRAM will write 0xaa55aa55, but read 0x00000000
// (because magenta-colored pixels are scrolled up) causing kernel panic.
//
// Here we just do not do video memory testing for simplicity.
return true;
}