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

[DearthnVader]

I don't want to derail the thread too much, however, I can't seem to get HWacell working on my virtual Mac Pro.

Booting with OC v0.5.2
Lilu v1.3.9
WEG v1.3.4

macOS 10.15.2 (19C57)

My graphics card is GFX0 in the IOReg. RX580

CPU is a Ryzen7 1700 spoofing a Penryn class Intel.

Boot-args=shikigva=144 -v debug=0x144 -wegtree

Attached is my OC config.plist

Anyone have a clue what I am doing wrong?

 

[startergo]

I can't seem to get HWacell working on my virtual Mac Pro

Virtual Mac Pro? Can you elaborate? Is this a KVM machine? Did you passthrough the AMD? What kind of AMD card is it? Also on a KVM why are you running 3.1 Mac? We spoof imacpro smbios to get HW acceleration (HEVC encode).
[automerge]1578836362[/automerge]
Plus your WEG and Lilu are old you need to update them. Also OC had a fresh update yesterday.

 

[DearthnVader]

Virtual Mac Pro? Can you elaborate? Is this a KVM machine? Did you passthrough the AMD? What kind of AMD card is it? Also on a KVM why are you running 3.1 Mac? We spoof imacpro smbios to get HW acceleration (HEVC encode).
[automerge]1578836362[/automerge]
Plus your WEG and Lilu are old you need to update them. Also OC had a fresh update yesterday.

Yes, it's a KVM machine( Qemu Q35 with OVMF ) running on a Linux host, I'm spoofing the MP7,1 as you should be able to see from my config.plist.

I'm passing an RX580.

I have a real 3,1, but I'm not using that right now with the RX580, at some point I'll test HWAcell with the 3,1, but that's not what I'm trying to do right now, one thing at a time.

 

[startergo]

I'm spoofing the MP7,1

Try spoofing the iMacPro instead of MP7,1. Also update LILU, WEG and OC to the latest releases.

 

[DearthnVader]

Try spoofing the iMacPro instead of MP7,1. Also update LILU, WEG and OC to the latest releases.

I think I also tried the iMacPro too, didn't work, but I'll test it again.....

Isn't the Mac Pro 7,1 board-id also included in the driver that controls HWAcell?

As I understand it, what is needed is a supported board-id, a supported graphics card that has the GFX0 property in the device-tree. Then whatever magic Lilu and WEG does?

But there is just something I'm missing?

I should be able to do this with Clover, the boot loader I prefer, but that doesn't seem to work either, and a quick goole search just returns this thread.

What do the boot-args I'm using do, I know what the debug boot-arg does, what about the other two?

 

[h9826790]

I don't want to derail the thread too much, however, I can't seem to get HWacell working on my virtual Mac Pro.

Booting with OC v0.5.2
Lilu v1.3.9
WEG v1.3.4

macOS 10.15.2 (19C57)

My graphics card is GFX0 in the IOReg. RX580

CPU is a Ryzen7 1700 spoofing a Penryn class Intel.

Boot-args=shikigva=144 -v debug=0x144 -wegtree

Attached is my OC config.plist

Anyone have a clue what I am doing wrong?

Try self build WEG and Lilu by using the latest master source files. For 10.15.2 and RX580, that can make huge difference.

 

[startergo]

Isn't the Mac Pro 7,1 board-id also included in the driver that controls HWAcell?

It is, but nobody tested it successfully yet even the OC developers recommend iMacPro spoofing.

Then whatever magic Lilu and WEG does?

Lilu is just the wrapper for WEG and other plugins which do the actual job.
WEG is a Lilu plugin providing patches to select GPUs on macOS. Requires Lilu 1.4.0 or newer.
[automerge]1578841571[/automerge]
I can't find anymore SHIKI boot arguments options. There use to be a web page with all the decimal numbers, which when converted to binary give you the switches used.
Never mind I found it:

WhateverGreen/WhateverGreen/kern_shiki.hpp at master · acidanthera/WhateverGreen

Various patches necessary for certain ATI/AMD/Intel/Nvidia GPUs - acidanthera/WhateverGreen

github.com

 

[startergo]

So shikigva=128 actually gives us:

useLegacyHwDrmDecoder = info->firmwareVendor == DeviceInfo::FirmwareVendor::Apple;

And shikigva=16 sets the board Id to imacpro:

if (useHwDrmDecoder) {
                DBGLOG("shiki", "setting hwdrm-id to iMacPro1,1");
                entry->setProperty("hwdrm-id", const_cast<char *>("Mac-7BA5B2D9E42DDD94"), static_cast<uint32_t>(sizeof("Mac-7BA5B2D9E42DDD94")));

shikigva=80 is:

if (useHwDrmStreaming && useHwDrmDecoder) {
        auto hwDrmPatch = getPatchSection(SectionHWDRMID);
        if (hwDrmPatch) {
            hwDrmPatch->find = iMacProBoardId;
            hwDrmPatch->replace = selfBoardId;
            hwDrmPatch->size = sizeof(selfBoardId);
            DBGLOG("shiki", "using partial hwdrm-id patch from %s to %s", reinterpret_cast<char *>(iMacProBoardId), reinterpret_cast<char *>(selfBoardId));

shikigva=32 is:

// Custom board-id may be overridden by a boot-arg
    if (replaceBoardID) {
        if (getBootArgument(info, "shiki-id", customBoardID, sizeof(customBoardID)))
            customBoardID[sizeof(customBoardID)-1] = '\0';

If shikigva=64 is NOT used:

if (!useHwDrmStreaming)
        disableSection(SectionNSTREAM);

I can't get the purpose above, but that is the only standalone usage, but note!:

// Note, AMD Polaris Ellesmere is broken in 10.15 (e.g. RX 590), whereas AMD Polaris Baffin (e.g. RX 460) is fine.

And the combination/addition of those numbers will give us something else.

 

[startergo]

We have to test -radcodec without smbios spoofing as :

// Fix codec PID to be spoofed PID if requested 
forceCodecInfo = checkKernelArgument("-radcodec");
............................................................................
// Patch AppleGVA support for non-supported models
    if (forceCodecInfo && getHWInfoProcNames[hwIndex] != nullptr) {
        KernelPatcher::RouteRequest request(getHWInfoProcNames[hwIndex], wrapGetHWInfo[hwIndex], orgGetHWInfo[hwIndex]);
        patcher.routeMultiple(hardware.loadIndex, &request, 1, address, size);

 

[startergo]

So if shikigva=144+ smbios spoofing of imacpro gave us everything working, we can try
shikigva=208 without smbios spoofing and

-radcodec

on/off can be tested as well with this combination

 

[DearthnVader]

What boot args are people using with success?

 

[startergo]

What boot args are people using with success?

on cMP5,1 with RX-580 (ellesmere) I use:

nvram boot-args="-v agdpmod=pikera keepsyms=1 -liludbgall liludump=10 debug=0x144 -no_compat_check -wegtree shikigva=144"

These are the necessary arguments:

nvram boot-args="agdpmod=pikera -no_compat_check -wegtree shikigva=144"

+ iMacPro Smbios spoofing (for HEVC encoding)

 

[DearthnVader]

agdpmod=pikera

What does this one do?

 

[h9826790]

What does this one do?

Rename board-id to board-ix.

When boot with iMac Pro SMBIOS, only one port on the graphic card will work. Perform this rename will allow all ports able to display properly again.

Same effect as the following entries in config.plist under Kernel -> Patch

            <dict>
                <key>Base</key>
                <string></string>
                <key>Comment</key>
                <string>Patch AppleGraphicsDevicePolicy board-id to board-ix</string>
                <key>Count</key>
                <integer>0</integer>
                <key>Enabled</key>
                <true/>
                <key>Find</key>
                <data>Ym9hcmQtaWQ=</data>
                <key>Identifier</key>
                <string>com.apple.driver.AppleGraphicsDevicePolicy</string>
                <key>Limit</key>
                <integer>0</integer>
                <key>Mask</key>
                <data></data>
                <key>MaxKernel</key>
                <string></string>
                <key>MinKernel</key>
                <string></string>
                <key>Replace</key>
                <data>Ym9hcmQtaXg=</data>
                <key>ReplaceMask</key>
                <data></data>
                <key>Skip</key>
                <integer>0</integer>
            </dict>

 

[h9826790]

So if shikigva=144+ smbios spoofing of imacpro gave us everything working, we can try
shikigva=208 without smbios spoofing and

-radcodec

on/off can be tested as well with this combination

1) Latest self build WEG 1.3.6 and Lilu 1.4.1

2) Boot argument

sudo nvram boot-args="-wegtree shikigva=208 -radcodec"

3) No OpenCore or SMBIOS spoofing.

4) 10.14.6, kext loaded

5) Outcome, nothing works

6) If manually assign iMac Pro board-id by adding 32 (shikigva=240) will cause KP at boot

*** Panic Report ***
panic(cpu 4 caller 0xffffff7f82c8e8c6): WhateverGreen     shiki: @ Hardware DRM decoder cannot be used with custom board or whitelist

 

[h9826790]

shikigva=80 + SMBIOS spoofing also working with latest Lilu and WEG now. All DRM streaming can play flawlessly. So, 64bit FairPlay 2.0 should be working now

 

[startergo]

If manually assign iMac Pro board-id by adding 32 (shikigva=240) will cause KP at boot

you can't use 32 and 16 or 16 and 8 or 256 and 16 together there is an intended KP from WEG. 16 implies board Id spoofing to imacpro already.
144=128+16

you can try 64+16=80 -radcodec
or
128+64 with -radcodec
or
128 with -radcodec
or
128+32 + board ID Imacpro -radcodec
or
128+32 + 8 board ID Imacpro -radcodec
or
128+16 -radcodec
or
128+64+32 + board ID Imacpro -radcodec
or
128+64+32+8 + board ID Imacpro -radcodec

if (useHwDrmDecoder && (replaceBoardID || addExecutableWhitelist))
            PANIC("shiki", "Hardware DRM decoder cannot be used with custom board or whitelist");
        if (useSwDrmDecoder && useHwDrmDecoder)
            PANIC("shiki", "Hardware and software DRM decoders cannot be used at the same time");

 

[h9826790]

you can't use 32 and 16 or 16 and 8 or 256 and 16 together there is an intended KP from WEG. 16 implies board Id spoofing to imacpro already.
144=128+16

you can try 64+16=80 -radcodec
or
128+64 with -radcodec
or
128 with -radcodec
or
128+32 + board ID Imacpro -radcodec
or
128+32 + 8 board ID Imacpro -radcodec
or
128+16 -radcodec
or
128+64+32 + board ID Imacpro -radcodec
or
128+64+32+8 + board ID Imacpro -radcodec

if (useHwDrmDecoder && (replaceBoardID || addExecutableWhitelist))
            PANIC("shiki", "Hardware DRM decoder cannot be used with custom board or whitelist");
        if (useSwDrmDecoder && useHwDrmDecoder)
            PANIC("shiki", "Hardware and software DRM decoders cannot be used at the same time");

I understand that, but so far, seems if not use 32 and manual board-id injection, nothing will happen.

16 + other options seems no effect at all.

 

[startergo]

I understand that, but so far, seems if not use 32 and manual board-id injection, nothing will happen.

16 + other options seems no effect at all.

Have you tested 128+32+8 board-id change -radcodec?
if not I will test it when I can.

 

[h9826790]

Have you tested 128+32+8 board-id change -radcodec?
if not I will test it when I can.

Not yet. Doing some other test in Catalina now.

Anyway, 80 works well in both 10.14.6 and 10.15.2 with OC SMBIOS Spoofing.

Not sure if anything that only FairPlay 2.0 can do but not 1.0. But we have 2.0 now.

 

[cdf]

DRM freezing is still present with SMBIOS spoofing and the new options. In fact, the Shiki header file mentions it:

// Note, AMD Polaris Ellesmere is broken in 10.15 (e.g. RX 590), whereas AMD Polaris Baffin (e.g. RX 460) is fine.
// Easiest check is to run WebKitMediaKeys.isTypeSupported("com.apple.fps.2_1", "video/mp4") in Safari Web Console.
// Broken GPU driver will just freeze the system with .gpuRestart crash.

 

[startergo]

DRM freezing is still present with SMBIOS spoofing and the new options. In fact, the Shiki header file mentions it:

// Note, AMD Polaris Ellesmere is broken in 10.15 (e.g. RX 590), whereas AMD Polaris Baffin (e.g. RX 460) is fine.
// Easiest check is to run WebKitMediaKeys.isTypeSupported("com.apple.fps.2_1", "video/mp4") in Safari Web Console.
// Broken GPU driver will just freeze the system with .gpuRestart crash.

That should be only with 64.
128+16 shouldn't do it. Is it with Netflix or with everything? Did you apply default writes?

 

[cdf]

128+16 shouldn't do it. Is it with Netflix or with everything? Did you apply default writes?

Both 144 and 80 do it, but only with SMBIOS spoofing. Freezing occurs in general (can be checked with the console in Safari). Default writes on and off.

 

[startergo]

In fact, the Shiki header file mentions it

That is supposed to be fixed:

Added HEVC capabilities to AMD6 decoders for all GPUs · acidanthera/WhateverGreen@3c19c56

closes acidanthera/bugtracker#613

github.com

After which someone tested it:

"Here is my test, i can confirm that there is NO FREEZE or PANIC so far:

1. add boot-args: shikigva=32 shiki-id=Mac-7BA5B2D9E42DDD94 on top of my iMac19,2 SMBIOS, make sure everything is using AMD GPU. (i use these boot-args just for testing AMD GPU, so that the iGPU is not used during my test)
2. use QuickTime to record my 4k screen, i did a 4m47s recording
3. use QuickTime to save as 1080p in HEVC format, it takes less than 4mins to finish the encoding.
4. during recording and encoding, the CPU usage is around 3%, it is pretty amazing.
5. play back the recoded 4k video and encoded 1080p HEVC video using QuickTime and mpv (installed via brew install --HEAD mpv), again only 3% CPU usage.
6. play back jellyfish-120-mbps-4k-uhd-hevc-10bit.mkv using mpv multiple times during screen recording, only 3% CPU usage.

my spec: i5-8400, RX 470, macOS 10.15.2, opencore-version REL-054-2019-12-13


Thank you vit for the integration."

 

[aacemyan]

Has anyone successfuly been able to get a dual socket Mac Pro work with smbios spoof under Catalina using method on Post 594? Mine worked under Mojave but can get the computer to even boot up properly when using this method on Catalina. Standard OpenCore install works fine, but when i download latest Lilu 1.4.0, WEG 1.3.5, and config.plist from post 594, everything just breaks when spoofing SMBIOS at iMac Pro.

When i turn on the machine, i get no boot screen and 2 minutes later the computer just turns off (is this a kernel panic?). Only way to recover is PRAM reset and boot into a backup Mojave drive.

Any feedback regarding what others did to make this work? FYI I’m running dual X5690 CPUs, 96GB Ram, NVME PCIE ssd, and Vega 56 (Pixlas Mod).