AMD Polaris IDs on Sierra / High Sierra

[truemac]

9 minutes ago, telepati said:

Thank you so much. And I deleted it.  Can I ask you one thing could you please check my config.plist; Many people saying RX560 working OOB without any kext and injections but when I remove kexts I cant boot just got black screen;

 

 

config.plist

is the boot problem solved?

yes I can look at it

which kext you are using?

do you can boot if you disable KernelPM patch?

Edited April 13, 2018 by truemac

[telepati]

9 minutes ago, truemac said:

is the boot problem solved?

yes I can look at it

I think yes boots now in 14 sec after clover boot screen.

FakeSMC and Ethernet kexts inside of Clover/Others

L/E

USBInjectAll.kext and LiluFriend.kext

Inside of LiluFriend;

 

Another question;

With this code HEVC video will work; Or this just for Airplay; 'cause when I try HEVC video with Quicktime I am getting this error;

			<dict>
				<key>IOGVAHEVCDecode</key>
				<string>1</string>
				<key>IOGVAHEVCEncode</key>
				<string>1</string>
			</dict>

 

Edited April 13, 2018 by telepati

[truemac]

please test this config.plist and delete shiki intelgraphicsfixup and Whatevergreen and Lilufriend and Put Usbinjectall Lilu and appleALC to clover repair permissions and rebuild kernel cache then reboot make sure you have a backup USB to boot from it if this don't work

config.plist.zip

Edited April 13, 2018 by truemac

[truemac]

18 minutes ago, telepati said:

Another question;

With this code HEVC video will work; Or this just for Airplay; 'cause when I try HEVC video with Quicktime I am getting this error;

			<dict>
				<key>IOGVAHEVCDecode</key>
				<string>1</string>
				<key>IOGVAHEVCEncode</key>
				<string>1</string>
			</dict>

 

no Quicktime don't support mkv files use other player like IINA

Edited April 13, 2018 by truemac

[telepati]

16 minutes ago, truemac said:

please test this config.plist and delete shiki intelgraphicsfixup and Whatevergreen and Lilufriend and Put Usbinjectall Lilu and appleALC to clover repair permissions and rebuild kernel cache then reboot make sure you have a backup USB to boot from it if this don't work

config.plist.zip

Ok I test it. I try the boot with verbose mode. When verbose mode finished its turned black screen.

[truemac]

maybe because AGDC is enabled and Whatevergreen disable it 

check with this fakesmc please

FakeSMC.kext.zip

[telepati]

21 minutes ago, truemac said:

maybe because AGDC is enabled and Whatevergreen disable it 

check with this fakesmc please

FakeSMC.kext.zip

Thank you so much. With this FakeSMC it worked. But Boot time now increased 20 sec and also Restart about the same time.

[truemac]

Ok Nice now we know that the ADGC cause the Black screen

Maybe repair permission and rebuild cashe help

i look Later on it i'm not home right now.

Edited April 13, 2018 by truemac

[telepati]

20 minutes ago, truemac said:

Ok Nice now we know that the ADGC cause the Black screen

Maybe repair permission and rebuild cashe help

i look Later on it i'm not home right now.

Thank you. I rebuild cache on single user mode in Clover Boot screen with this code; but it doesn't help;

mount -uw /

kextcache -i /

reboot.

I will wait for you. Thank you again for all help. 

[truemac]

here check this FakeSMC Put all your kext to clover no L/E and use this https://www.firewolf.science/download/756/ to repair permissions and cache rebuilding. and check with your old Config.plist and the new one.

good hack

FakeSMC.kext.zip

[Cyberdevs]

8 hours ago, truemac said:

RX560 use AMDBaffinGraphicsAccelerator

this one should work

FakeSMC.kext.zip

It's really funny and interesting, the FakeSMC I posted is working with my R9 270X and it's not even using the Ellesmere or Baffin Framebuffer, the framebuffer Futomaki but on my rig it's using the RadeonFrameBuffer because I don't use InjectATI, WEG or RadeonDeInit.

The working FrameBuffer for RX560 is Acre which has the following Ports:

Acre (3) @ 0x622e0
DP, HDMI, DVI-D
000400000403000000010101000000001102020100000000
000800000402000000010200000000002103050400000000
040000000402000000010300000000000000030500000000

I created my SSDT for the RX 560 based on this info and it worked.

[truemac]

yes because R9 270X use AMDPitcairnGraphicsAccelerator

<key>IOProviderClass</key>
<string>AMDPitcairnGraphicsAccelerator</string>

and the one for Rx560 use the AMDBaffinGraphicsAccelerator

<key>IOProviderClass</key>
<string>AMDRadeonX4000_AMDBaffinGraphicsAccelerator</string>

you just need to change the IOProviderClass to inject it correctly 

its not depend on the Framebuffer that you use but on the Accelerator

Edited April 14, 2018 by truemac

[telepati]

17 hours ago, truemac said:

here check this FakeSMC Put all your kext to clover no L/E and use this https://www.firewolf.science/download/756/ to repair permissions and cache rebuilding. and check with your old Config.plist and the new one.

good hack

FakeSMC.kext.zip

Thank you. With old config.plist now 13 sec. to boot. But when I make restart I am waiting 30sec+.

[truemac]

check this option in clover maybe help 

key>HaltEnabler</key>

<true/>
 

good hack

Edited April 16, 2018 by truemac

[Mieze]

As the prices for Radeon cards have been dropping during the last weeks I finally decided to buy a Sapphire Radeon Nitro+ RX570 8GB and received the card this afternoon. With 10.13.4 Apple added a number of new framebuffer personalities to the AMD9500Controller.kext and as the framebuffer personality "Orinoco" matches the connector layout of my card (DP, DP, HDMI, HDMI, DVI) I decided to give it a try and got an instantly working system. No framebuffer patch is needed anymore. See for yourself:

 

 

Mieze

[Cyberdevs]

6 hours ago, Mieze said:

As the prices for Radeon cards have been dropping during the last weeks I finally decided to buy a Sapphire Radeon Nitro+ RX570 8GB and received the card this afternoon. With 10.13.4 Apple added a number of new framebuffer personalities to the AMD9500Controller.kext and as the framebuffer personality "Orinoco" matches the connector layout of my card (DP, DP, HDMI, HDMI, DVI) I decided to give it a try and got an instantly working system. No framebuffer patch is needed anymore. See for yourself:

 

As you can see the macOS is detected your GPU as RX 480 instead of RX 570 because those GPUs have the same device id which is not a big deal and it won't affect the performance but in my experience if I don't select the framebuffer and if I select InjectATI, the card will be detected correctly, the down side is that I lose the DP connectivity (Black Screen) only the HDMI ports work without a problem, however with the Board-ID patch all ports work ok, no more black screen on none of the ports.

I don't use WhateverGreen in this scenario.

 

Spoiler

Kernel and Kext Patches:
Name: com.apple.driver.AppleGraphicsDevicePolicy
Find: BA050000 00
Replace: BA000000 00
Comment: Disable board-id check to prevent no signal © lvs1974, Pike R. Alpha, vit9696

 

I just thought you might be interested in this. 

[Mieze]

@Cyberdevs: Personally I don't care for the device name but the advantage to have a card which:

1. is working out OOB
2. has all ports working
3. doesn't need any patches which may break  after the next update

is obvious and can't be overestimated.

 

By the way, why do you have this ridiculous copyright notice in the comment of the patch? Looks like some of these so called "creators" haven't noticed yet, that you can't claim any copyright on a patch.

Edited April 25, 2018 by Mieze

[Cyberdevs]

@Mieze

Well about the copyright claim on the comment of the patch you need to ask them, I just posted the patch as I found it.

Ever since macOS 10.13.4 came out the black screen issue was fixed on so many AMD GPUs, Apple might just have used your discovery to resolve the boot to black issue I don't know for sure, but certainly we can use AMD GPUs easier and more efficient.

Thanks to you and the clover team.

[Mieze]

3 minutes ago, Cyberdevs said:

@Mieze

Well about the copyright claim on the comment of the patch you need to ask them, I just posted the patch as I found it.

Ever since macOS 10.13.4 came out the black screen issue was fixed on so many AMD GPUs, Apple might just have used your discovery to resolve the boot to black issue I don't know for sure, but certainly we can use AMD GPUs easier and more efficient.

Thanks to you and the clover team.

As Apple added support for eGPUs with 10.13.4 and recommends Sapphire's Pulse RX570 and RX580 series cards for use in external cases you don't need to be an expert in order to conclude that there must be native support for these cards.

 

Mieze

[Mieze]

@Cyberdevs: Unfortunately 10.13.4 isn't as comfortable as expected, at least not for users with 4k displays using DP. Although the board-id check is now obsolete, which is the good news, there is also bad news, as the wakeup issue has returned, at least with displays connected via DP. Now AGDC is enabled by default and with it MST support is active too which means that both DPs are combined in order to drive a 5k display. This is also the reason why my 4k display is recognized as a 5k display (see screenshot above). This change might be welcome for users with 5k display but effectively kills wakeup from sleep in my case because the framebuffer controller waits for the second link of the display to become active on it's second DP connector but as there is nothing connected, it times out in most cases leaving you with a black screen after wakeup. There are two ways to resolve the issue, use Whatevergreen or patch AMDSupport.kext to disable AGDC, which is what I did. So still no 100% RX5x0 support without patches. 

 

Mieze

[Cyberdevs]

13 hours ago, Mieze said:

@Cyberdevs: Unfortunately 10.13.4 isn't as comfortable as expected, at least not for users with 4k displays using DP. Although the board-id check is now obsolete, which is the good news, there is also bad news, as the wakeup issue has returned, at least with displays connected via DP. Now AGDC is enabled by default and with it MST support is active too which means that both DPs are combined in order to drive a 5k display. This is also the reason why my 4k display is recognized as a 5k display (see screenshot above). This change might be welcome for users with 5k display but effectively kills wakeup from sleep in my case because the framebuffer controller waits for the second link of the display to become active on it's second DP connector but as there is nothing connected, it times out in most cases leaving you with a black screen after wakeup. There are two ways to resolve the issue, use Whatevergreen or patch AMDSupport.kext to disable AGDC, which is what I did. So still no 100% RX5x0 support without patches. 

 

Mieze

Dear Mieze,

Thanks for the updates.

The board-id check is still necessary for me, I'm using the iMac17,1 SMBIOS which will end up in a black screen if I don't use the board-id patch unless I use InjectATI=True without selecting a framebuffer. About the 4K and 5K display I have no idea because I don't have a 4K or a 5K display but sleep works fine on my rig with the exception of the sound after sleep which is totally a different story. I'm using the DP to HDMI cable (an actual cable not a converter or an adapter) for one of my displays and the second one is connected via HDMI.

The thing is (as I mentioned before) if I select the Orinoco framebuffer it detects the GPU as an RX 480 and the LuxMark benchmark shows a slightly lower score when I choose that setting.

If I remember correctly I tried the iMac18,1 SMBIOS once and with that setting the board-id wasn't necessary, although I didn't test the sleep. I'll conduct another test with the iMac18,1 SMBIOS and see if the sleep works or not.

I have an Asus ROG Strix GPU which isn't included in the eGPU support list in Apple's website and that must be cause for the GPU to require the extra settings and flags.

I have been consulting with apianti a while back on the matter and he also suggested using the whatevergreen kext to resolve the issue on correcting the framebuffer selection, the card being detected correctly and for the correct naming of the GPU in macOS however the LuxMark results are still lower compare to the settings I posted earlier.

I'll be doing some more tests with changing the SMBIOS to iMac18,3 and using your DSDT patch (in a form of a SSDT) to see if that changes the black screen issue on the display connected to a DP port and the state of that display after sleep and report back.

Edited April 27, 2018 by Cyberdevs

[Cyberdevs]

Update:

 

iMac18,1 detects my GPU correctly without any patching or injection or DSDT/SSDT patches, wake from sleep works normally with the exception of the sound. I assume the reason is that the iMac18,1 only has Intel Iris Plus Graphics 640. 

Edited April 27, 2018 by Cyberdevs

[Mieze]

10 hours ago, Cyberdevs said:

Update:

 

iMac18,1 detects my GPU correctly without any patching or injection or DSDT/SSDT patches, wake from sleep works normally with the exception of the sound. I assume the reason is that the iMac18,1 only has Intel Iris Plus Graphics 640. 

This suggests that MST activation mainly depends on the system definition because the 21.5" iMacs all have SST displays and only the 27" iMacs with their 5K display need MST. In case this theory is correct my machine should wakeup with iMac18,2 without having AGDC disabled as these machines also use SST displays. Well that makes sense and would explain the behavior. I'll run some tests as soon as possible.

 

Mieze

Edited April 27, 2018 by Mieze

[Cyberdevs]

On 4/28/2018 at 1:33 AM, Mieze said:

This suggests that MST activation mainly depends on the system definition because the 21.5" iMacs all have SST displays and only the 27" iMacs with their 5K display need MST. In case this theory is correct my machine should wakeup with iMac18,2 without having AGDC disabled as these machines also use SST displays. Well that makes sense and would explain the behavior. I'll run some tests as soon as possible.

 

Mieze

Well my assumption is that in my case the iMac18,1 works with no boot to black screen issue because of the single GPU profile in that system definition and the other SMBIOSes fail to work OOB because they have dual GPU profiles (if I'm not mistaking) and since I don't use a patched DSDT at the moment I still need to apply the GPU related patches. but  in your case you are not facing the same issue, just out of curiosity what happens if you set the iGPU to active in BIOS/UEFI and set the primary display adapter to PCIe slot rather than the IGPU? Does it still fail to wake from sleep?

[Mieze]

5 minutes ago, Cyberdevs said:

Well my assumption is that in my case the iMac18,1 works with no boot to black screen issue because of the single GPU profile in that system definition and the other SMBIOSes fail to work OOB because they have dual GPU profiles (if I'm not mistaking) and since I don't use a patched DSDT at the moment I still need to apply the GPU related patches. but  in your case you are not facing the same issue, just out of curiosity what happens if you set the iGPU to active in BIOS/UEFI and set the primary display adapter to PCIe slot rather than the IGPU? Does it still fail to wake from sleep?

Maybe my post was a little bit misleading because the new wakeup issue differs from the old one in a way that it's not the framebuffer controller which fails to wakeup but the detection of the display fails so that the screen stays black. Technically speaking the machine is fully functional after wakeup and you can even use it via screensharing, which wasn't the case with the old wakeup issue, but now the display is gone after wakeup as if it has been disconnected during sleep.

 

Unfortunately I haven't been able to create a valid iMac18,2 serial number to try this system definition and I'm quite busy at the moment because I have to finish some Powerpoint slides I need for a lecture on Wednesday.

 

Mieze