deeveedee Posted June 25 Author Share Posted June 25 (edited) The attached SSDT-GFX0 is replaced here ========================================= In addition to looking at revising my connectors definition to comply with the 24-byte format, I am looking at fixing the multi-display issues. This guide suggests the use of property connector-priority. I suspect that the connector-priority works only when there are multiple Radeon connectors (different from the mixed-mode dGPU / iGPU configuration of this hack), but I'm willing to experiment. A sample Radeon SSDT is provided here. Note that the sample provides example 16-byte connectors patches, so it is not helpful for our ModernConnector patch. EDIT: I am now using the attached SSDT-GFX0 with properties borrowed from Dortania's sample Radeon SSDT here. I'm not certain that I'm going to keep all of the new properties - just testing. Note that the properties in SSDT-GFX0 are combined with the config.plist DeviceProperties for PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0). SSDT-GFX0.aml.zip EDIT2: I believe that I am observing improved multi-display behavior with the attached SSDT-GFX0. I will continue to test and operate with this kext. EDIT3: I don't think that property CAIL_DisableDrmdmaPowerGating is helpful or relevant to our RX560x. I only included it because it was in the sample SSDT. Edited June 26 by deeveedee 1 Link to comment Share on other sites More sharing options...
deeveedee Posted June 26 Author Share Posted June 26 (edited) The attached SSDT-GFX0 is replaced here ========================================= The attached SSDT-GFX0 has resolved the multi-display issues that I was experiencing. I now boot Sonoma and Sequoia with multiple displays (Main Display connected to the dGPU DP port and Extended Displays connected to iGPU DP ports) with no issues. The difference between the attached SSDT-GFX0 and my the attached SSDT-GFX0 in my previous post is that my latest SSDT-GFX0 eliminates the CAIL_DisableDrmdmaPowerGating property. I don't yet know which of my SSDT-GFX0 changes fixed the multi-display issues. EDIT: Note that in Sequoia, with this SSDT-GFX0, the dock is visible in both the Main and Extended displays when my dock is set to auto-hide (I can drag the cursor to the bottom of any display in Sequoia and the dock appears in that display). This is still not the case for me in Sonoma. EDIT2: I am continuing to experiment with different connectors patches in my SSDT-GFX0. I have noticed that when I test a patch that doesn't work (resulting in boot to black screen), I must reset NVRAM (sometimes multiple times) and then boot with a single-display connected to dGPU with a working connectors patch. For some reason, application of a bad patch sends the RX560x and/or macOS into a tizzy. SSDT-GFX0.aml.zip Edited June 26 by deeveedee Link to comment Share on other sites More sharing options...
hardcorehenry Posted June 26 Share Posted June 26 15 hours ago, deeveedee said: I suspect that the connector-priority works only when there are multiple Radeon connectors Seems like Whatevergreen doesn't fix connector-priority on "newer" MacOS, see issue. 1 Link to comment Share on other sites More sharing options...
deeveedee Posted June 26 Author Share Posted June 26 (edited) EDIT: There is still something strange about this connectors patch. I'm leaving the post below, but this patch still requires more work. It turns out that the attached patch "works" because I forgot to change the connectors Buffer length to 16 (it is still defined as a 20-byte buffer from my original patch). When the Buffer length is changed to 16-bytes, this patch no longer works. joevt believes that when the patch is defined as 20-bytes, WEG is not applying the patch. I'm inclined to agree with him, but this hack does not work without the patch (and WEG boot-arg -raddvi does not auto-patch the connector). There's something else going on which leads me to believe that I got much luckier with this RX560x patch than I initially believed here. ========================================== Many thanks to @joevt who showed me why my 16-byte patch attempt here did not work. I was forgetting to convert the pri and feat byte sequences to little endian (reverse byte order). With properly formatted feat byte sequence, the 16-byte patch now works. We still can't explain why my 20-byte patch works, too. The revised SSDT-GFX0 (with 16-byte connectors patch) is attached. @hardcorehenry Thanks! If that's the case, then it must be the addition of the "AAPL,slot-name" property that improved multi-display performance? Not sure. Some of this still seems like black magic to me. SSDT-GFX0.aml.zip Edited June 26 by deeveedee 3 Link to comment Share on other sites More sharing options...
deeveedee Posted June 26 Author Share Posted June 26 (edited) I am going to stop spamming this thread with every minor issue that I discover. I will record issues (and hopefully their solution) in Known Issues. The latest issue that I discovered at the time of this post (Firefox browser) is recorded in Known Issues. Edited June 26 by deeveedee Link to comment Share on other sites More sharing options...
deeveedee Posted June 27 Author Share Posted June 27 (edited) ************************************************************************************************************************ *** Tests below are performed in macOS Sequoia Beta 2 With WhateverGreen.kext (DEBUG) version 1.6.7 (Commit 21c7ffb) *** *** and Lilu.kext (DEBUG) version 1.6.8 (Commit 4256f43). *** *** *** *** NOTE: When generating Lilu/WEG debug logs, pay attention to the time stamp. I found that after some reboots to test *** *** a new EFI, the /var/log/Lilu* debug log was not updated. I am now in the habit of checking the log time stamp *** ***. and if I don't see that the log has a new time stamp, I reboot and check again. *** *** *** *** NOTE2: My test results below are collected with SMBIOS MM8,1 and the UHD630 displays enabled. This simplifies log *** *** collection when the RX560x display boots to black-screen (can still operate with UHD630-connected displays. *** ***. I have confirmed that the display behavior remains the same when using SMBIOS iMac19,2 and a headless *** ***. UHD630. With iMac19,2, working RX560x display still requires 20-byte connectors patch. *** *** *** *** NOTE3: I have tested without WhateverGreen.kext and SMBIOS models MM8,1, iMac19,1 & iMac19,2 and display does *** *** not work at all. *** ************************************************************************************************************************ When I first published my working EFI for this hack, I stated here that there was some luck involved in my discoveries. The fact that I am only able to avoid the RX560x black-screen problem with a 20-byte connectors patch (and not the WEG-required 16 or 24-byte connectors patch) has been part of my Known Issues since I first published my working EFI. I've been confused by my test results (especially this one here which I am no longer able to reproduce) as I've attempted to figure out why my connectors patch appears to work only when it is a 20-byte patch. I am now realizing that I was much luckier than I suspected. Attached are WhateverGreen logs for the following configurations WEG-20-working-4.log: Working display. Connectors patch declared in SSDT-GFX0 as an empty, 20-byte Buffer. WEG-16-nonworking-1.log: Black screen. Connectors patch declared in SSDT-GFX0 as 16-byte Buffer and initialized such that the patch makes no change to WEG's detected RX560x connector. WEG-none-nonworking-1.log: Black screen. No connectors Buffer defined in SSDT-GFX0. WEG-none-nonworking-2.log: Black screen. No connectors Buffer and connector-count not defined in SSDT-GFX0 (connector-count was defined as 1 for the other tests). WEG-24-nonworking-3.log: Black screen. Connectors patch declared in SSDT-GFX0 as 24-byte Buffer and initialized such that the patch makes no change to WEG's detected RX560x connector. WEG-raddvi-nonworking-1.log: Black screen. SSDT-GFX0 does not define connectors or connector-count. Added -raddvi to boot-args based on this comment in previous WEG logs: rad: @ (DBG) autocorrectConnector use -raddvi to enable connector autocorrection WEG-16-raddvi-nonworking-1.log: Black screen. Connectors patch declared in SSDT-GFX0 as 16-byte Buffer and initialized such that the patch makes no change to WEG's detected RX560x connector. Addition of -raddvi boot-arg to enable connector autocorrection. WEG-20-raddvi-working-1.log: Working display. Connectors patch declared in SSDT-GFX0 as an empty, 20-byte Buffer. Addition of -raddvi boot-arg to enable connector autocorrection. The connectors patch definitions associated with WEG-20-working-4.log, WEG-16-nonworking-1.log, WEG-24-nonworking-3.log, WEG-16-raddvi-nonworking-1.log and WEG-20-raddvi-working-1.log are listed at the beginning of each log file. I have reviewed the attached logs and am unable to determine why the different connectors patching strategies produce the results that they do. Pinging @joevt and asking for help from others reviewing this. This WEG connector patching is still black magic for me and I'm not sure what WEG is doing differently for the working and non-working configurations. The only thing I know at this time is that, as long as I declare connectors (in SSDT-GFX0) as a 20-byte Buffer, the RX560x in this hack works (does not boot to black screen). When I don't declare a connectors patch or I define the connectors patch as a 16-byte value, this hack's RX560x boots to black screen. The RX560x in this hack has a single DP connector. This hack has two DP connectors driven by Intel UHD630. EDIT: I have attached the EFI that I'm using when generating the Lilu/WEG debug log. The attached EFI is working (no black screen) with an empty, 20-byte connectors Buffer defined in SSDT-GFX0. EDIT2: I have attached WEG-24-nonworking-3.log to show that the nonworking results are the same when using 16 and 24-byte connectors Buffer. EDIT3: I have attached WEG-raddvi-nonworking-1.log generated after adding boot-arg -raddvi to enable WEG connector auto-correct. While boot still results in black screen, the log includes the statement: rad: @ (DBG) autocorrectConnector found unsupported connector type 13. Not sure if this log offers any clues. EDIT4: I have attached WEG-16-raddvi-nonworking-1.log and WEG-20-raddvi-working-1.log to repeat earlier tests, but with the addition of the -raddvi boot-arg to enable WEG connector auto-correct. WEG-20-working-4.log WEG-16-nonworking-1.log WEG-none-nonworking-1.log WEG-none-nonworking-2.log EFI-MM81-RX560x-OC100-16-DEBUG.zip WEG-24-nonworking-3.log WEG-raddvi-nonworking-1.log WEG-16-raddvi-nonworking-1.log WEG-20-raddvi-working-1.log Edited June 27 by deeveedee Added debug logs with boot-arg -raddvi 1 Link to comment Share on other sites More sharing options...
joevt Posted June 28 Share Posted June 28 Seems kind of random. 1,2,5,7,8 don't seem to change the connector info at all. The logs show the before and after are identical. 3,4,6 only change the priority from 0 to 1. Is 0 a valid priority? -raddvi doesn't do anything because you have "unsupported connector type 13" which is CONNECTOR_OBJECT_ID_DISPLAYPORT. -raddvi is applicable to these connector types: CONNECTOR_OBJECT_ID_DUAL_LINK_DVI_I CONNECTOR_OBJECT_ID_DUAL_LINK_DVI_D CONNECTOR_OBJECT_ID_LVDS Patches that are not 16 or 24 appear to be ignored in the WEG code, so I don't see how a 20 byte patch would affect anything. The size override works in any case, but if the size before is 1 then it's not really changing. The following two lines: *sz = consCount; DBGLOG("rad", "getConnectorsInfo got size override to %u", *sz); should be changed to this (for better logging): DBGLOG("rad", "getConnectorsInfo got size override to %u from %u", consCount, *sz); *sz = consCount; I see one interesting thing. "setting fb limit to 1" occurs in 2,3,4,5,6,7, but not 1,8. This sets a property "CFG_FB_LIMIT" in ioreg. The reason it doesn't get set for #1 and #8 is because "getConnectorsInfo conoverrides have invalid size 20". I would add some more debugging like this: void RAD::applyPropertyFixes(IOService *service, uint32_t connectorNum) { if (service && getKernelVersion() >= KernelVersion::HighSierra) { // Starting with 10.13.2 this is important to fix sleep issues due to enforced 6 screens OSObject *theProperty = service->getProperty("CFG,CFG_FB_LIMIT"); if (!theProperty) { DBGLOG("rad", "setting CFG_FB_LIMIT to %u", connectorNum); service->setProperty("CFG_FB_LIMIT", connectorNum, 32); } else { OSNumber *theNumber = OSDynamicCast(OSNumber, theProperty); if (!theNumber) { DBGLOG("rad", "CFG_FB_LIMIT is not a number!"); } else { UInt32 theVal = theNumber->unsigned32BitValue(); if (theVal == connectorNum) DBGLOG("rad", "CFG_FB_LIMIT is already set to %u", theVal); else DBGLOG("rad", "CFG_FB_LIMIT is set to %u instead of %u", theVal, connectorNum); } } // In the past we set CFG_USE_AGDC to false, which caused visual glitches and broken multimonitor support. // A better workaround is to disable AGDP just like we do globally. } } I would also maybe add a flag to disable setting `CFG_FB_LIMIT` which might allow 16 and 24 byte patches to work? But maybe research the info contained in the comments of RAD::applyPropertyFixes 1 1 Link to comment Share on other sites More sharing options...
hardcorehenry Posted June 28 Share Posted June 28 On 6/26/2024 at 1:10 PM, hardcorehenry said: Seems like Whatevergreen doesn't fix connector-priority on "newer" MacOS, see issue. Big apologies for link to the issue which seems to be invalid. I struggled with forcing DVI to be as first in ioreg(otherwise PP_BootupDisplayState, PP_VBlankTime and PP_RefreshRate properties are not initialized) and I managed to achieve it with "connectors"(24-byte) and "connector-priority" properties. I have no idea why it didn't work earlier so again sorry if I misled. Spoiler Link to comment Share on other sites More sharing options...
deeveedee Posted June 28 Author Share Posted June 28 (edited) @joevt Thank you for your thorough reply. Setting CFG,CFG_FB_LIMIT=0 allows the 16-byte connectors patch to work. Attached is the WEG debug log with a 16-byte connectors patch and CFG,CFG_FB_LIMIT=0. EDIT: Also attached is my updated SSDT-GFX0. Thank you for your time and careful review. Now I just need to learn why setting CFG,CFG_FB_LIMIT=0 "fixes" this. I'm going to run a test with only CFG,CFG_FB_LIMIT=0 (no connectors patch) to see if that also works. WEG-16-working-1.log SSDT-GFX0.aml.zip Edited June 28 by deeveedee 1 Link to comment Share on other sites More sharing options...
deeveedee Posted June 28 Author Share Posted June 28 (edited) @joevt My luck in finding a working solution for this hack is laughable. It turns out that the only reason my 20-byte connectors patch works is because it caused WEG to throw an error that prevented WEG from setting CFG_FB_LIMIT. This hack boots macOS Sequoia Beta 2 without the RX560x black-screen issue with the simple addition of property CFG,CFG_FB_LIMIT=0. My updated SSDT-GFX0 and the associated WEG debug log are attached. See more details here. Thank you again for your help. EDIT: In my next published EFI, I am going to eliminate SSDT-GFX0 and simply add the CFG,CFG_FB_LIMIT property to DeviceProperties in the OC config.plist. EDIT2: I now have a working EFI that eliminates SSDT-GFX0 and incorporates CFG,CFG_FB_LIMIT=0 and other GFX0 properties into the OC config.plist DeviceProperties. I'm going to test and review a bit more and will post my updated EFI after my review and further testing. I hope this journey is as entertaining and enlightening for you as it is for me. EDIT3: WEG debug log with my revised DeviceProperties is attached (WEG-none-working-2.log). My revised GFX0 DeviceProperties are listed at the top of the log. With these DeviceProperties, SSDT-GFX0 is no longer needed. WEG-none-working-1.log SSDT-GFX0.aml.zip WEG-none-working-2.log Edited July 27 by deeveedee 1 Link to comment Share on other sites More sharing options...
deeveedee Posted June 28 Author Share Posted June 28 (edited) I read the following in the WhateverGreen Radeon FAQ My framebuffer amount exceeds connector amount in IOReg (starting with 10.13.2)? This is a bug Apple added by fixing another bug of incorrect connector detection from VBIOS. In certain kexts (e.g. AMD9500Controller) they hardcoded 6 connectors as a total connector amount regardless of the number read from VBIOS. The consequences are black screen after wake and/or failure to sleep. To fix this issue you should specify CFG,CFG_FB_LIMIT with a correct number, via SSDT for example. Starting with version 1.1.4 this problem is fixed automatically. It appears that the automatic behavior of WhateverGreen is to attempt to fix an incorrect CFG_FB_LIMIT. For this hack's RX560x, WhateverGreen seems to have the incorrect automatic behavior, which explains why we need to manually define CFG_FB_LIMIT. EDIT: Now that we know the culprit is CFG_FB_LIMIT, search for it and you will find many mentions in various forums. See here, for example, where vit9696 is participating in a discussion on MacRumors. EDIT2: When I said that WEG is incorrectly changing CFG_FB_LIMIT, I didn't mean to imply that there is a bug in WEG. Instead, I think that the CFG_FB_LIMIT is likely to be set differently for this RX560x than other Radeon graphics cards tested by Acidanthera. I never found a posted working solution for this HP EliteDesk 800 RX560x graphics card, so it appears that this black-screen problem has stumped everyone since the card's release in 2018. It's not very satisfying to learn that I just got lucky with my 20-byte connectors patch, but I'll take the luck this time. EDIT3: WEG's automatically handling of CFG_FB_LIMIT was discussed and addressed way back here. Edited June 29 by deeveedee 1 Link to comment Share on other sites More sharing options...
joevt Posted June 28 Share Posted June 28 With your original 20 byte patch, did CFG_FB_LIMIT exist in ioreg? Is there a difference in behaviour with CFG_FB_LIMIT not existing, and CFG_FB_LIMIT=0? Link to comment Share on other sites More sharing options...
deeveedee Posted June 28 Author Share Posted June 28 (edited) @joevt yes, with the 20-byte connectors patch, CFG_FB_LIMIT=0 exists in ioreg. That's the first thing I looked at after you interpretted the debug logs. Thank you again for your help! EDIT: Not sure about difference in behaviour between CFG_FB_LIMIT not existing and CFG_FB_LIMIT=0, but I didn't need to test that. EDIT2: @joevt Here's the IOReg after booting Sequoia Beta 2 with an empty, 20-byte connectors patch: Spoiler EDIT3: Here's the IOReg after booting Sequoia Beta2 with no connectors patch and CFG,CFG_FB_LIMIT=0. Note that in my DeviceProperties, CFG,CFG_FB_LIMIT=0 (number) but in IOReg, CFG,CFG_FB_LIMIT=<00 00 00 00> (data). Not sure why, but it doesn't seem to matter. Spoiler DeviceProperties: CFG,CFG_FB_LIMIT=0 Spoiler EDIT4: Here's the IOReg after booting Sequoia Beta 2 without defining CFG,CFG_FB_LIMIT=0. WEG is automatically and incorrectly changing the already defined CFG_FB_LIMIT to 1 which results in booting RX560x-connected display on this hack to black-screen. Spoiler EDIT5: Maybe a pri=0000 is correct for this RX560x (so I shouldn't be overriding Priority to 1). EDIT6: @joevt In EDIT4, I said that WEG is incorrectly changing CFG_FB_LIMIT. I didn't mean to imply that there was a bug in WEG. Instead, I think that the CFG_FB_LIMIT is likely to be set differently for this RX560x than other Radeon graphics cards tested by Acidanthera. I never found a posted working solution for this HP EliteDesk 800 RX560x graphics card, so it appears that this black-screen problem has stumped everyone since the card's release in 2018. It's not very satisfying to learn that I just got lucky with my 20-byte connectors patch, but I'll take the luck this time. Edited June 29 by deeveedee Link to comment Share on other sites More sharing options...
joevt Posted June 29 Share Posted June 29 Oh, I didn't notice that CFG,CFG_FB_LIMIT and CFG_FB_LIMIT are two different things. The following describes the purpose of the "CFG," prefix: https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.Radeon.en.md Any property with a "CFG," prefix is then used to override the same property without the "CFG," prefix. This is handled by RAD::wrapGetProperty which calls RAD::mergeProperties. So your setting of CFG,CFG_FB_LIMIT doesn't change the original setting of CFG_FB_LIMIT because it is already zero. Having CFG,CFG_FB_LIMIT just stops RAD::applyPropertyFixes from changing CFG_FB_LIMIT to 1 (the number of connectors in the connectors list). 1 1 Link to comment Share on other sites More sharing options...
deeveedee Posted June 29 Author Share Posted June 29 (edited) 11 minutes ago, joevt said: So your setting of CFG,CFG_FB_LIMIT doesn't change the original setting of CFG_FB_LIMIT because it is already zero. Having CFG,CFG_FB_LIMIT just stops RAD::applyPropertyFixes from changing CFG_FB_LIMIT to 1 (the number of connectors in the connectors list). That was the only way I could think to stop WEG from changing CFG_FB_LIMIT (after I confirmed that it was 0 with a 20-byte connector). I'm open to your suggestion if you think there is a better way. EDIT: I removed my connector-priority=1 property (allowing pri=0000 to remain unchanged). I don't think it makes a difference with the single DP connector on this RX560x, but I'll continue to test. Edited June 29 by deeveedee Link to comment Share on other sites More sharing options...
deeveedee Posted June 29 Author Share Posted June 29 (edited) For those who are following this thread and who may be confused by the current solution baseline, the unchanged EFI attached to Post #1 still works fine, but not for the reasons that I initially thought it worked. I won't be attaching a new EFI to Post #1 until after the next Open Core release, so if you want to create your own EFI with the latest working solution, use the EFI attached to Post #1 and replace EFI/OC/ACPI/SSDT-GFX0.aml with the SSDT-GFX0 attached here. The next EFI that I post will remove SSDT-GFX0 and insert the required GFX0 property assignment CFG,CFG_FB_LIMIT=0 into the Open Core config.plist DeviceProperties. The connectors patch is not required for this hack's RX560x. EDIT: Continue to monitor Known Issues here. Edited June 29 by deeveedee 2 Link to comment Share on other sites More sharing options...
deeveedee Posted June 30 Author Share Posted June 30 (edited) See candidate multi-display solution in next post. ========================================== If you would like to help with testing multiple displays (or you're just curious about multi-display testing), this post is for you. I would greatly appreciate test help, so if you are able to test and experiment with multiple displays, please report your test configuration and results in this thread. Thank you. Now that the black-screen issue is fully understood, I'd like to focus on the continuing multi-display issues that I am seeing. I am still finding occasional anomalies when using multiple displays (with one display connected to the RX560x (dGPU) DP port and one or two displays connected to one or both of the UHD630 (iGPU) DP ports). If you are interested in helping to test, here's what I am finding so far: Whenever I Reset NVRAM (from Open Core boot menu), I must first boot macOS with only the dGPU display powered on. After macOS boots and I login, I can turn on the other display(s). After one successful boot cycle (single display at boot followed by turning on additional displays after login), I can leave all displays on during subsequent boot / login cycles (until the next NVRAM Reset). When I first started creating the macOS solution for the HP EliteDesk 800 G4 Mini in May 2020, I needed to disable iGFX AGDC to enable multi-display operation (initially using a kext patch and then ultimately using WhateverGreen boot-arg igfxagdc=0) (Thanks @shuhung for his AppleGraphicsDevicePolicy tip here). I tried disabling AGDC for the RX560x (using DeviceProperty CFG,CFG_USE_AGDC=false), but this results in RX560x black-screen I am not sure if setting the connector priority for the RX560x matters (using DeviceProperty connector-priority=<01>). I am experimenting with and without this DeviceProperty and am not sure I see a difference. Spoiler I am not sure if setting a mask for boot-arg igfxonln=1 matters (using boot-arg igfxonlnfbs=0x0102 to restrict igfx force-online to only UHD630 framebuffer connector indices 1 and 2). I am experimenting with and without boot-arg igfxonlnfbs=0x0102 and am not sure I see a difference. The only reason I thought to test igfxonlnfbs=0x0102 is that our UHD630 has only two connectors now that the RX560x is the 3rd connector. I have not yet tested a configuration where a UHD630-connected display is Main and the RX560x display is an Extended display. Maybe this resolves the multi-display issues? I have not yet thoroughly tested with SMBIOS models iMac19,1 and iMac19,2, so I'm not sure if somehow these SMBIOS models would have better multi-display behavior. Note that iMac19,2 offers an optional RX560x. I have not yet experimented with injection of EDID for the displays. My configuration for my multi-display testing is as follows: SMBIOS: macMini8,1 (using EFI attached to Post #1 with SSDT-GFX0 here). BIOS: boot display set to RX560x macOS: Main display set to RX560x-connected display macOS: Extended display(s) set to UHD630-connected display(s) DP->DVI adapters on all displays (my displays have DVI ports, so I must use the DP->DVI converters). The EFI attached to Post #1 includes the UHD630 DeviceProperties required for my DP->DVI adapters. The RX560x DeviceProperties do not appear to change regardless of whether a converter is used (e.g., same RX560x DeviceProperties for DP->DP, DP->HDMI and DP->DVI). If you are not using DP->DVI converter on your UHD630-connected displays (e.g., you are using DP->DP), you should use different UHD630 DeviceProperties as defined here. Edited July 1 by deeveedee 2 Link to comment Share on other sites More sharing options...
deeveedee Posted June 30 Author Share Posted June 30 (edited) EDIT: It appears that the only configuration item that needs to be changed to resolve the multi-display issues is to set Integrated GPU as boot display in BIOS. I don't know if this is an HP BIOS issue, an Open Core issue or a macOS issue. With the following configuration, my hack appears to be trouble-free with multiple displays. Leaving the post below for history. I still welcome multi-display test results from others. Working configuration for two displays with HP EliteDesk 800 RX560x dGPU BIOS: boot display set to Integrated GPU (UHD630) - this appears to be the most important factor in resolving multi-display issues with the RX560x-equipped EliteDesk 800 Mini. SMBIOS: macMini8,1 (EFI attached to Post #1 with SSDT-GFX0 from here) DeviceProperties > dGPU ( PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0) ) : connector-priority is NOT specified (this leaves pri=0000 in framebuffer connector) DeviceProperties > dGPU ( PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0) ) : @0,AAPL,boot-display (cosmetic - sets Apple logo to appear on RX560x-connected display during second boot-stage before login). With iGPU set as boot display in BIOS, Apple logo will appear on iGPU-connected display during boot-stage 1 and then Apple logo will move to dGPU-connected display during boot-stage 2. Additional boot-args: igfxonlnfbs=0x0102 (not sure this is necessary, but it doesn't hurt) macOS: Main display set to the display on RX560x macOS: Extended display set to display on UHD630 connector index 1 With the configuration above (boot display set to Integrated GPU in BIOS), there is no need to power-off / power-on displays during boot / login and Firefox hardware acceleration can be enabled. About This Mac reports display as RX560x. EDIT2: Note that after setting dGPU DeviceProperty @0,AAPL,boot-display=<01000000>, the Apple Logo behavior during boot-stage 2 is as I described, but IORegistry still shows AAPL,boot-display=True for iGPU (and AAPL,boot-display=<01000000> for dGPU). This doesn't seem to matter. I tried forcing iGPU @0,AAPL,boot-display=False with a DeviceProperty, but it wouldn't change. Spoiler ============================================== Multi-display test results (in progress): I am currently testing two displays with the following configuration with initial observations suggesting that observed problems have been resolved: SMBIOS: macMini8,1 DeviceProperties > iGPU ( PciRoot(0x0)/Pci(0x2,0x0) : @0,AAPL,boot-display DeviceProperties > dGPU ( PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0) ) : connector-priority is NOT specified BIOS: boot display set to UHD630 (Integrated GPU) macOS: Main display set to the display on UHD630 connector index 1 macOS: Extended display set to display on RX560x Additional boot-args: igfxonlnfbs=0x0102 Problems that are resolved with this configuration: No need to power off and on any displays for booting / login No need to disable hardware acceleration in Firefox browser Observations: GeekBench 6 metal benchmarks appear unchanged for RX560x Spoiler About This Mac reports graphics as UHD630 Spoiler Specifying property "@0,AAPL,boot-display" for the iGPU or dGPU does nothing more than determine where the second boot-stage Apple logo appears before login. No other observations / behaviors appear to change. Changing only the boot display in BIOS to Radeon dGPU without changing any other configuration settings results in multi-display anomalies. In other words, whenever boot display is set to RX560x in BIOS, previously mentioned multi-display anomalies are observed. Changing only the Main display in macOS System Settings > Displays to RX560x-connected display (leaving BIOS boot display as Integrated GPU) appears to allow macOS to boot without the previously mentioned multi-display issues and About This Mac reports the graphics as RX560x. It appears to me that all multi-display issues are resolved as long as the Integrated GPU is set to boot display in BIOS. Spoiler With dGPU DeviceProperty @0,AAPL,boot-display=<01000000>, the Apple logo appears on the dGPU-connected display during boot-stage 2 as I described earlier. What's interesting is that IORegistry Explorer shows that AAPL,boot-display=True for the iGPU Spoiler This doesn't seem to matter. I tried forcing iGPU @0,AAPL,boot-display=False in DeviceProperties, but AAPL,boot-display remains True for the iGPU in IORegistry. Edited July 1 by deeveedee Added multi-display solution as EDIT to beginning of post 2 Link to comment Share on other sites More sharing options...
deeveedee Posted July 1 Author Share Posted July 1 (edited) Sequoia Beta 2 is now my main driver on this hack and it is performing perfectly. I especially like the fact that, with multiple displays, the macOS dock appears on each separate display (with dock auto-hide enabled) and app menus for the active app appear at the top of each display. With Sonoma, the dock and app menus appear only on my main display. So far, all issues with this hack appear to be resolved. I am extremely pleased with the results. I think this hack is one of the better deals available for macOS. My current baseline hardware configuration is as follows: HP EliteDesk 800 G4 Mini 35W Radeon RX 560x dGPU 32 GB DDR4 Memory (2 x 16GB) 500 GB WD Black SN750 m.2 NVMe SSD Intel i5-8600 CPU (TDP 65W) Copper CPU heatsink 230W PSU EDIT: Below is my itemized cost for this hack. I suspect that demand for these components may increase slightly now that a working macOS solution is available, but this should give you an idea of your purchase price. HP EliteDesk 800 G4 Mini 35W (i5-8500T, 1x16GB DDR4 SODIMM, RX 560x dGPU, 150W PSU, 500 GB Hynix m.2 NVMe SSD): $100 USD 16GB DDR4 SODIMM $28 USD 500 GB WD Black SN750 m.2 SSD: $70 USD i5-8600 CPU (upgrade from i5-8500T): price unknown, I swapped this from a 65W Mini that I already had Copper CPU heatsink (replace standard aluminum): price unknown, I swapped this from a 65W Mini that I already had 230W PSU (upgrade from 150W): $18 USD I could have implemented this solution without adding memory, upgrading the CPU and upgrading the PSU. The original SSD may have worked, but I prefer the WD SSD. Edited July 2 by deeveedee 4 Link to comment Share on other sites More sharing options...
deeveedee Posted July 2 Author Share Posted July 2 (edited) This is the first hack that I have configured with dual GPUs (both Radeon and Intel) where BOTH GPUs are driving graphics display ports (iGPU not configured as headless), so forgive me for what may be remedial observations. I am finding that macOS Sequoia is perfectly capable of handling the dual-GPU configuration without any issues. My current dual-GPU observations are as follows (to be updated as my observations change): Dragging application windows between displays is seamless. I can drag Safari, Firefox, Microsoft Remote Desktop, VNC Viewer and other applications from an Intel-connected display to a Radeon-connected display and vice versa. Starting applications on an Intel-connected display or a Radeon-connected display does not affect app behavior. From an application perspective, the displays are completely interchangeable and interoperable. Geekbench 6 metal benchmarks with the GB6 display on an Intel-connected display or a Radeon-connected display appear to be identical (roughly 23000) with no degradation of performance. This is not a surprise - just reporting my observation. Both dGPU-connected and iGPU-connected DP ports are driving DP->DVI graphics adapters without any problems. The Unigine Valley graphics benchmark performance is identical on Radeon-connected and Intel-connected displays. The Unigine Valley benchmark benefits from Radeon acceleration on all displays, regardless of whether they are Intel-connected or Radeon-connected. I can drag the actively running Unigine Valley benchmark from one display to another seamlessly. EDIT: The Unigine Valley benchmark output always starts on the dGPU-connected display, regardless of where I place the Unigine Valley control panel and regardless of where the output display was located when I last closed Unigine Valley. It does appear that Unigine Valley is detecting the dGPU-connected display when it launches. However, after the benchmark starts and output is displayed on the dGPU-connected display, I can drag the output display to the iGPU-connected display without issues and without changes in Radeon graphics acceleration. For basic operations and multiple apps running, CPU and dGPU fans are quiet. After my dual-GPU tests, I don't believe there is any advantage to configuring the iGPU as headless. I have not tested DRM, so I can't comment on whether headless iGPU operation affects DRM. I don't have much experience with DRM. My DRM tests (below) all failed, but I think that is expected on Hackintosh. EDIT: This hack is awesome. What a fun hack! EDIT2: VideoProc Hardware Info (with non-headless Intel iGPU) Spoiler EDIT3: Video Codec Test Results (with non-headless iGPU) Mac model: Macmini8,1 macOS version: 15.0 CPU description: Intel(R) Core(TM) i5-8600 CPU @ 3.10GHz CPU type: Intel CPU nominal frequency: 3.1 GHz CPU physical core count: 6 CPU logical core count: 6 GPU description: AMD Radeon RX 560x Available codecs: H.264, H.265, JPEG, ProRes 422 Proxy, ProRes 422 LT, ProRes 422, ProRes 422 HQ, ProRes 4444 RUN 1: H.264 2K Decode Software processing Throughput: 405 fps, Frames: 5599, CPU: 96 % RUN 2: H.264 2K Decode Internal hardware processing Throughput: 808 fps, Frames: 11128, CPU: 18 % RUN 3: H.264 2K Decode Software and internal hardware processing Throughput: 660 fps, Frames: 9103, CPU: 100 % RUN 4: H.264 4K Decode Software processing Throughput: 153 fps, Frames: 2135, CPU: 100 % RUN 5: H.264 4K Decode Internal hardware processing Throughput: 246 fps, Frames: 3419, CPU: 18 % RUN 6: H.264 4K Decode Software and internal hardware processing Throughput: 191 fps, Frames: 2589, CPU: 86 % RUN 7: H.264 2K Encode Software processing Throughput: 98 fps, Frames: 1228, CPU: 95 % RUN 8: H.264 2K Encode Internal hardware processing Throughput: 107 fps, Frames: 1514, CPU: 12 % RUN 9: H.264 2K Encode Software and internal hardware processing Throughput: 184 fps, Frames: 2473, CPU: 91 % RUN 10: H.264 4K Encode Software processing Throughput: 28 fps, Frames: 370, CPU: 100 % RUN 11: H.264 4K Encode Internal hardware processing Throughput: 27 fps, Frames: 418, CPU: 5 % RUN 12: H.264 4K Encode Software and internal hardware processing Throughput: 49 fps, Frames: 668, CPU: 100 % RUN 13: H.265 2K Decode Software processing Throughput: 493 fps, Frames: 6846, CPU: 85 % RUN 14: H.265 2K Decode Internal hardware processing Throughput: 619 fps, Frames: 8504, CPU: 22 % RUN 15: H.265 2K Decode Software and internal hardware processing Throughput: 848 fps, Frames: 11696, CPU: 99 % RUN 16: H.265 4K Decode Software processing Throughput: 200 fps, Frames: 2725, CPU: 85 % RUN 17: H.265 4K Decode Internal hardware processing Throughput: 290 fps, Frames: 4049, CPU: 11 % RUN 18: H.265 4K Decode Software and internal hardware processing Throughput: 286 fps, Frames: 3937, CPU: 89 % RUN 19: H.265 2K Encode Software processing Throughput: 13 fps, Frames: 130, CPU: 99 % RUN 20: H.265 2K Encode Internal hardware processing Throughput: 140 fps, Frames: 1943, CPU: 8 % RUN 21: H.265 2K Encode Software and internal hardware processing Throughput: 45 fps, Frames: 552, CPU: 99 % RUN 22: H.265 4K Encode Software processing Throughput: 1 fps, Frames: 17, CPU: 99 % RUN 23: H.265 4K Encode Internal hardware processing Throughput: 35 fps, Frames: 533, CPU: 9 % RUN 24: H.265 4K Encode Software and internal hardware processing Throughput: 8 fps, Frames: 96, CPU: 99 % EDIT4: I don't have an AppleTV subscription and I have not experimented with DRM on hacks, so accept my observations with a few grains of salt. I tried to play a free episode on AppleTV and it did not play. I assume this means that DRM is not working. Based on my limited knowledge of macOS / DRM on hacks, this is not a surprise. EDIT5: DRM Tests VDADecoderChecker results Downloads % ./VDADecoderChecker Hardware acceleration is fully supported Movie: FairPlay 1.x test: plays audio only Movie: Spider-Man Far From Home test: Don't have an Amazon subscription to test I am aware that I am violating the Dortania device renaming recommendations (e.g., I have an ACPI patch that renames PEGP->GFX0) and I am using MacMini8,1 for a desktop. I will retest with iMac19,2 without ACPI renames (with non-headless iGPU). EDIT6: After removing the ACPI > Patches GFX0->IGPU & PEGP->GFX0 and changing SMBIOS to iMac19,2, I do not see any difference in DRM behavior. DRM test results for iMac19,2 are the same as for MM8,1 on this hack. I will remove the ACPI Patches that rename GFX0->IGPU and PEGP->GFX0, but I will keep MM8,1 as my primary SMBIOS for use and testing. EDIT7: The GFXMetal Benchmark is a great test for measuring Metal performance of our graphics card and for proving that all displays (dGPU-connected and iGPU-connected) are Metal-accelerated by the RX 560x. The GFXMetal benchmark displays on the full-screen (not windowed) where the GFXMetal dashboard is located. I experimented with launching the benchmarks with the dashboard located on the dGPU-connected display and with the dashboard located on the iGPU-connected display. The benchmark sees both Metal-capable GPUs as shown here Spoiler but uses the RX 560x as the graphics accelerator as shown here: Spoiler regardless of which display (iGPU-connected or dGPU-connected) is hosting the app. For me, this is proof that iGPU-connected graphics ports can be used to extend the available ports on Radeon dGPUs without sacrificing any performance. Edited July 5 by deeveedee Added EDIT7: GFXMetal benchmark multi-monitor tests 2 Link to comment Share on other sites More sharing options...
deeveedee Posted July 4 Author Share Posted July 4 (edited) When I first created my EFI for testing the RX 560x, I was testing with and without WhateverGreen.kext. As described here, WhateverGreen.kext automatically performs ACPI renames (e.g., GFX0->IGPU and PEGP->GFX0), so ACPI > Patches for these renames are unnecessary in the Open Core config.plist. However, since I was initially testing with and without WhateverGreen.kext, I needed the ACPI patches. My testing in my previous post (with WhateverGreen.kext) suggests that my ACPI > Patches did not affect macOS behavior (including DRM, which does not work), but I will be removing the unnecessary ACPI patches in my next posted EFI. For those who want to eliminate the unnecessary ACPI renames before I post my next EFI, here are the changes you should make: In EFI/OC/ACPI/SSDT-GFX0-Off.aml, replace all instances of GFX0 with PEGP. *** Rename EFI/OC/ACPI/SSDT-GFX0-Off.aml to SSDT-PEGP-Off.aml (not necessary, but it keeps the file name consistent with its contents). The new SSDT is attached. In EFI/OC/config.plist, delete ACPI > Patch > GFX0->IGPU and delete ACPI > Patch > PEGP->GFX0. These renames are automatically performed by WhateverGreen.kext. In EFI//OC/config.plist, change ACPI > Add > SSDT-GFX0-Off to SSDT-PEGP-Off (to be consistent with the new SSDT name). The new config.plist for SMBIOS MacMini8,1 is attached. See EDIT below for possible additional changes *** Note that with the unnecessary ACPI > Patches that included renaming PEGP -> GFX0, SSDT-GFX0-Off referenced GFX0 and not PEGP. This is because Open Core performs the ACPI > Patches BEFORE it applies ACPI > Adds. Whenever testing a revised EFI, it's best to do the following: After making any changes to your Open Core config.plist, check your new config.plist with Open Core's ocvalidate (in Open Core package Utilities/ocvalidate folder). Always validate your config.plist with the ocvalidate Utility corresponding to the OpenCore version you used for your EFI. Test your new EFI by first installing it on a USB thumb drive and booting with the thumb drive After confirming that your hack boots with the thumb drive EFI, copy the revised EFI to your primary boot drive. Remove the thumb drive and reboot to test. Keep a working bootable USB thumb drive (with your currently working EFI) so that you can easily recover if something happens to the EFI on your pimary boot drive. Note that you could use an Open Core configurator to make your changes. I do not use configurators - just my preference. When I'm testing new EFIs, I don't want a possible configurator bug as another variable I need to consider. I use Xcode to edit my config.plist. The new SSDT-PEGP-Off.aml and config.plist (for SMBIOS MacMini 8,1) are attached. EDIT: Thanks to feedback from @ird, I realized that I forgot to include necessary changes for SSDT-GFX0. If you are still using SSDT-GFX0 in your EFI, you will need to replace OC/ACPI/SSDT-GFX0.aml with the attached SSDT-PEGP.aml and change ACPI > Add > SSDT-GFX0 to SSDT-PEGP in your OC config.plist. Thanks, @ird ! In my next posted EFI, SSDT-GFX0 will be eliminated (and is already eliminated in my attached config.plist). SSDT-PEGP-Off.aml.zip config.plist.zip SSDT-PEGP.aml.zip Edited July 5 by deeveedee Added SSDT-GFX0 change, fixed typo 2 Link to comment Share on other sites More sharing options...
deeveedee Posted July 5 Author Share Posted July 5 (edited) I have finished my multi-monitor testing and posted my test results here. Based on my test results, both the dGPU-connected display and iGPU-connected displays fully benefit from the acceleration of the RX 560x, giving this hack a total possible of three fully-accelerated displays. It does not appear to matter that the displays are or are not connected directly to the dGPU to have the full benefit of dGPU acceleration. I think that the "headless" iGPU frame buffer that is recommended in hackintosh guides is a paradigm that is not necessary. Edited July 5 by deeveedee 1 Link to comment Share on other sites More sharing options...
deeveedee Posted July 6 Author Share Posted July 6 (edited) For a low-budget macMini, this little hack offers decent Metal performance. It's still worth comparing it to the Metal benchmarks for the least-powerful Apple Silicon Macs: GeekBench 6 Metal benchmarks for M1 Macs Spoiler The "lowly" M1 Mac mini (Late 2020) handily beats the Metal performance of this budget hack. If you're looking for a new Mini that runs macOS, I wouldn't suggest that anyone spend more than $200 USD on a hack before looking at the used pricing of a real Apple Silicon Mac. Edited July 6 by deeveedee 3 Link to comment Share on other sites More sharing options...
ird Posted July 6 Share Posted July 6 3 hours ago, deeveedee said: For a low-budget macMini, this little hack offers decent Metal performance. It's still worth comparing it to the Metal benchmarks for the least-powerful Apple Silicon Macs: GeekBench 6 Metal benchmarks for M1 Macs Hide contents The "lowly" M1 Mac mini (Late 2020) handily beats the Metal performance of this budget hack. If you're looking for a new Mini that runs macOS, I wouldn't suggest that anyone spend more than $200 USD on a hack before looking at the used pricing of a real Apple Silicon Mac. deeveedee, All credit to you to make these machines worthy entry-level mac alternatives. It takes a lot of time and energy to get these machines up and stable enough to be daily drivers. Thank you! There's one issue I observe. I find that if I don't power up the monitor in time (i.e., at or before turning on the machine), then there is no display at all during or after the machine boots up completely. Unplugging and replugging the display cable doesn't seem to help either. Is anyone else facing the same issue (or put another way, is this a known issue)? Not sure if it has to do something with DP-DP connection. Sleep-wake works perfectly for me, though. Link to comment Share on other sites More sharing options...
deeveedee Posted July 6 Author Share Posted July 6 (edited) @ird Glad you're enjoying your hack. By 'the monitor,' you mean the dGPU-connected monitor, correct? I haven't tested or tried to resolve that. Look for the Radeon framebuffer patching options that might fix that: either a WhateverGreen boot-arg/DeviceProperty or a framebuffer connector flag. I'll learn from you when you post the fix.😄 EDIT: @ird My hack dGPU-connected display works just fine if I power it on after booting. I've taken careful notes about my configuration in this thread, so you should be able to figure out the difference between your config and mine. Edited July 7 by deeveedee fix typo Link to comment Share on other sites More sharing options...
Recommended Posts