HP EliteDesk 800 G4 / G5 Mini with RX560x dGPU (hackintosh)

[ird]

3 hours ago, deeveedee said:

@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.😄

 

I tried to inject Acre framebuffer (named) but it would not apply via config.plist. I also tried your SSDT-GFX0.aml (after renaming it to SSDT-PEGP.aml as I removed the renames from config.plist), however the .aml did not apply Acre FB either and IOregistryexplorer kept showing it's still the standard RadeonFrameBuffer with 6 connectors. Anything that I might be obviously missing based on your experience?

[deeveedee]

@ird I didn't see any benefit from injecting Acre FB name/compatible properties in Sequoia. I thought I did see a slight performance increase when I tested Acre name/compatible properties with Sonoma, but I didn't test enough to be certain and it wasn't a priority for me to test further.  I don't think Acre FB injection would have anything to do with the dGPU-connected monitor behavior that you observed (if that's what you're thinking).

 

Use the Lilu and WhateverGreen boot-args and kexts (see my EFI attached here) and examine the Lilu debug log to see if your properties are being applied.

 

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

[ird]

4 hours ago, deeveedee said:

@ird I didn't see any benefit from injecting Acre FB name/compatible properties in Sequoia. I thought I did see a slight performance increase when I tested Acre name/compatible properties with Sonoma, but I didn't test enough to be certain and it wasn't a priority for me to test further.  I don't think Acre FB injection would have anything to do with the dGPU-connected monitor behavior that you observed (if that's what you're thinking).

 

Use the Lilu and WhateverGreen boot-args and kexts (see my EFI attached here) and examine the Lilu debug log to see if your properties are being applied.

 

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.

Thank you for confirming. This helps. I’ll compare configs and try to debug.

[deeveedee]

I added two dGPU DeviceProperties to my OC config.plist in an attempt to squeeze more performance out of the RX560x.  

 

 

I don't know if either of these properties is applicable to our RX560x, but after adding the properties, I observed the highest GB6 Metal benchmark that I've seen on this hack so far:

Spoiler

 

This new GB6 score may be a slight improvement, but the change is too small to be conclusive.  Maybe others can test.  I ignored warnings that I read about enabling PP_DisablePowerContainment, so proceed with testing at your own risk.

 

EDIT: I re-ran GFXMetal benchmark with the added DeviceProperties.  Some benchmarks were better and some worse.  Again, inconclusive.

 

EDIT2: I re-ran GB6 benchmark after setting PP_WorkLoadPolicy_Mask = <20> instead of <40> (I misread this guide).  No noticeable difference.

Edited July 8 by deeveedee

[ird]

On 7/7/2024 at 5:34 PM, deeveedee said:

I added two dGPU DeviceProperties to my OC config.plist in an attempt to squeeze more performance out of the RX560x.  

 

 

I don't know if either of these properties is applicable to our RX560x, but after adding the properties, I observed the highest GB6 Metal benchmark that I've seen on this hack so far:

  Reveal hidden contents

 

This new GB6 score may be a slight improvement, but the change is too small to be conclusive.  Maybe others can test.  I ignored warnings that I read about enabling PP_DisablePowerContainment, so proceed with testing at your own risk.

 

EDIT: I re-ran GFXMetal benchmark with the added DeviceProperties.  Some benchmarks were better and some worse.  Again, inconclusive.

 

EDIT2: I re-ran GB6 benchmark after setting PP_WorkLoadPolicy_Mask = <20> instead of <40> (I misread this guide).  No noticeable difference.

 

I'd doubt 0x20 vs 0x40 for WorkLoadPolicy_Mask would make a difference as both VR and Compute will likely put the GPU in "high perf" mode. You'd want to try 0x4 instead (Power saving). I used that and GB6 Metal score on Sonoma dropped to ~18K down from ~23K. However, after a few days for some strange reason it's back up to 23K. So, I myself, am confused if this is just snake oil... inconclusive so far.

 

Re: my displayport issues and turning on of the dGPU connected monitor - I've made no meaningful progress so far in fixing it. I've been reading quite a bit about displayport though. It does seem that DP as a whole is quite finicky when it comes to synchronization and some combinations of GPU DP connectors and monitors might have an issue negotiating the sync. Need more debugging...

[deeveedee]

@ird I'm trying to increase performance, but I understand why you would want to test PP_WorkLoadPolicyMask = 0x04 for reduced power consumption.

 

Are you still using SMBIOS iMac19,2 with headless iGPU frame buffer?  If so, have you tested with SMBIOS macMini8,1 and "headed" frame buffer (the EFI that I attached to Post #1).  As I mentioned, I don't experience any issues when powering on the dGPU-connected display after boot/login and I am using SMBIOS macMini8,1, headed iGPU frame buffer, boot-display set to iGPU in BIOS.  Also, I am using DP->DVI port adapters.  In my experience, the DP->DVI adapters have been much more problematic than DP->DP (or DP->HDMI), but for this hack, they are working perfectly.

 

EDIT: Even if your ultimate goal is to run with SMBiOS iMac19,2, if SMBIOS macMini8,1 (with headed iGPU frame buffer and BIOS settings) works for you, you have a starting point for debugging.

Edited July 9 by deeveedee

[ird]

9 hours ago, deeveedee said:

@ird I'm trying to increase performance, but I understand why you would want to test PP_WorkLoadPolicyMask = 0x04 for reduced power consumption.

 

Are you still using SMBIOS iMac19,2 with headless iGPU frame buffer?  If so, have you tested with SMBIOS macMini8,1 and "headed" frame buffer (the EFI that I attached to Post #1).  As I mentioned, I don't experience any issues when powering on the dGPU-connected display after boot/login and I am using SMBIOS macMini8,1, headed iGPU frame buffer, boot-display set to iGPU in BIOS.  Also, I am using DP->DVI port adapters.  In my experience, the DP->DVI adapters have been much more problematic than DP->DP (or DP->HDMI), but for this hack, they are working perfectly.

 

EDIT: Even if your ultimate goal is to run with SMBiOS iMac19,2, if SMBIOS macMini8,1 (with headed iGPU frame buffer and BIOS settings) works for you, you have a starting point for debugging.

 

Sorry for the confusion. I didn't do a particularly good job of translating my thoughts to words. I didn't mean to suggest you use power saving policy, rather my suggestion was for you to use bookend policies that are expected to show results on either end. This will allegedly help confirm if PP_WorkLoadPolicy_Mask was indeed effective. Picking policies that might yield close results might result in inconclusive results within the margin of error.

 

Re: SMBIOS - yes, I did test with MacMini8,1 as well (and other iMac variants). The results seem to be the same. I wouldn't rule out DP-DP, 4K, single dGPU-connected monitor scenario, specific monitor model etc. all as potential culprits. I will try to do more testing by changing more variables if possible. Unfortunately, I cannot use iGFX for display as it struggles badly to drive 4k60 display and I don't have a second monitor at hand to test. 

 

I also agree that it would seem DP-DVI scenarios might be more prone to issues than native connections. This one beat me...

 

Re: MacMini8,1 and non-iGFX headless. The only reason (apart from testing), I would not use this as a daily driver is because for some reason it forces Video encode/decode on the dGPU. I've found that to be inferior to Intel's HW both in performance (quality) as well as power consumption. Setting iGFX to headless is the only way I was able to force macOS to use Intel's video codec for low power, good quality and low noise experience. I might be completely missing or overlooking something here to use iGFX-non-headless and yet force macOS to use Intel instead of dGPU. If someone has any advice on that front, I'd greatly appreciate.

[deeveedee]

14 hours ago, ird said:

Setting iGFX to headless is the only way I was able to force macOS to use Intel's video codec for low power, good quality and low noise experience. I might be completely missing or overlooking something here to use iGFX-non-headless and yet force macOS to use Intel instead of dGPU. If someone has any advice on that front, I'd greatly appreciate.

 

Please describe your testing methodology so that I and others can attempt to duplicate.

 

See EDIT3 and EDIT4 below. EDIT: I wasn't suggesting that you use iGPU ports - just configure them with "headed" frame buffer, but leave them unused to see if that affects the powered-off monitor behavior that you are observing with the dGPU-connected display.

 

EDIT2: When you describe your testing methodology, include

• Apps (hopefully some that are free and easy to download) that you use to confirm that video encoding / decoding is being performed by AMD and not Intel iGPU
• Apps that you use to measure video encoder power consumption
• Techniques you used to try to force Intel encoding (e.g., defaults write com.apple.AppleGVA forceIntel -boolean yes)
• References that you might suggest to learn more about this (e.g., this, this, this).  I'm not a Video encoder / decoder expert, so I'll be learning.
• Configuration for each test (SMBIOS, headed/headless iGPU frame buffer, BIOS settings for iGPU/dGPU), video-connected iGPU/dGPU ports, boot-args, DeviceProperties)

 

Since this will potentially be a lot of info, you can create a post and then continue to add to / edit the original post as you have more info.

 

EDIT3: @ird I re-tested with SMBIOS iMac19,2 and headless iGPU framebuffer.  Sleep / Wake works perfectly with or without my DAGPM.kext.  I have edited my Known Issues to remove the wake issue with iMac19,x / headless iGPU.

 

EDIT4: @ird I tested my hack booting with SMBIOS iMac19,2 and headless iGPU frame buffer (0x3e920003).  I am able to completely boot macOS Sequoia Beta 2 with the dGPU-connected monitor powered off.  After waiting for macOS to boot, I can power-on the dGPU-connected display with no issues (no black screen).  The login window appears normally on the display and I login.  Please post your EFI if you want further help to diagnose this issue with your hack.  Also, please post your EFI with each new request for help.

Edited July 10 by deeveedee

[deeveedee]

Upgrade from Sequoia Beta 2 to Sequoia Beta 3 proceeded without issues.  My baseline configuration remains SMBIOS macMini8,1 with both dGPU and iGPU ports fully enabled for multi-display operation.

 

About This Hack: Sequoia Beta 3

Spoiler

 

Important for this upgrade:

• Latest Acidanthera kexts from here or -lilubetaall boot arg
• RestrictEvents.kext 1.1.3 with -revbeta or -lilubetaall boot-arg and revpatch=sbvmm NVRAM property.  Alternatively, use RestrictEvents.kext 1.1.4 from lorys89.  RE and sbvmm not needed if using SMBIOS iMac19,x (which does not have T2 chip).
• Misc > Security > SecureBootModel = Disabled when applying upgrade.  Can be enabled after upgrade is finished

 

EDIT: The EFI attached to Post #1 satisfies the requirements for installing / upgrading Sequoia.  If you used one of my iMac19,x sample EFIs, you may need to upgrade one or more kexts, since I did not focus on posting a final EFI version for iMac19,x.

 

EDIT2: I re-ran GeekBench6 Metal benchmark after upgrading from Sequoia Beta 2 -> Beta 3.  My Metal benchmark dropped to 18K (from 23K in Sequoia Beta 2). After a reboot and NVRAM Reset (not sure which did the trick), GB6 Metal benchmarks are consistently at 23K as expected.

Edited July 11 by deeveedee
Added RE sbvmm note for iMac19,x

[deeveedee]

@miliuco Why the sad face on my previous post? 😀

[miliuco]

52 minutes ago, deeveedee said:

Why the sad face on my previous post? 😀

Because I did it quickly without stopping to look at what I had done, I wanted to like but I have to pay more attention to what I am doing 😞

[ird]

On 7/10/2024 at 4:11 AM, deeveedee said:

 

Please describe your testing methodology so that I and others can attempt to duplicate.

 

See EDIT3 and EDIT4 below. EDIT: I wasn't suggesting that you use iGPU ports - just configure them with "headed" frame buffer, but leave them unused to see if that affects the powered-off monitor behavior that you are observing with the dGPU-connected display.

 

EDIT2: When you describe your testing methodology, include

• Apps (hopefully some that are free and easy to download) that you use to confirm that video encoding / decoding is being performed by AMD and not Intel iGPU
• Apps that you use to measure video encoder power consumption
• Techniques you used to try to force Intel encoding (e.g., defaults write com.apple.AppleGVA forceIntel -boolean yes)
• References that you might suggest to learn more about this (e.g., this, this, this).  I'm not a Video encoder / decoder expert, so I'll be learning.
• Configuration for each test (SMBIOS, headed/headless iGPU frame buffer, BIOS settings for iGPU/dGPU), video-connected iGPU/dGPU ports, boot-args, DeviceProperties)

 

Since this will potentially be a lot of info, you can create a post and then continue to add to / edit the original post as you have more info.

 

EDIT3: @ird I re-tested with SMBIOS iMac19,2 and headless iGPU framebuffer.  Sleep / Wake works perfectly with or without my DAGPM.kext.  I have edited my Known Issues to remove the wake issue with iMac19,x / headless iGPU.

 

EDIT4: @ird I tested my hack booting with SMBIOS iMac19,2 and headless iGPU frame buffer (0x3e920003).  I am able to completely boot macOS Sequoia Beta 2 with the dGPU-connected monitor powered off.  After waiting for macOS to boot, I can power-on the dGPU-connected display with no issues (no black screen).  The login window appears normally on the display and I login.  Please post your EFI if you want further help to diagnose this issue with your hack.  Also, please post your EFI with each new request for help.

 

Sorry for the delay. After much fighting with this issue, I was able get it resolved. Turns out it was an issue with my monitor firmware! I updated it and everything seems good now. Pro-tip: if you are having any such issues don't forget to get firmware updates for your monitor! I know most of us will seldom suspect this to be the culprit.

[deeveedee]

@ird Glad that solved your display issues.  I'd still like to know how to duplicate your observed iGPU/dGPU CODEC issues.  If you want others to test, provide testing details and your current EFI as stated here.

 

 

On a separate note, my multi-display experience with Sequoia Beta 3 is outstanding.  For those who want multiple displays to behave as one large, continuous display (including allowing windows to span displays), you'll need to disable System Settings > Desktop & Dock > Mission Control > Displays have separate spaces.

 

Spoiler

 

EDIT: Note that if "Displays have separate Spaces" is disabled, the auto-hidden dock appears only on the main display.  If you want the auto-hidden dock to appear on all displays, enable "Displays have separate Spaces."

 

EDIT2: This "Displays have separate Spaces" setting (Enabled) is why I wasn't seeing the auto-hidden Dock on each display in Sonoma.  Enabling "Displays have separate Spaces" in Sonoma also shows the auto-hidden Dock on each display.

Edited July 12 by deeveedee

[ird]

23 minutes ago, deeveedee said:

@ird Glad that solved your display issues.  I'd still like to know how to duplicate your observed iGPU/dGPU CODEC issues.  If you want others to test, provide testing details and your current EFI as stated here.

 

Aah, yes. Sorry for missing that. I got so excited with this problem solved that I overlooked that question

 

VideoProc is one of the tools and the other are simply using HW sensors to look at d- and iGPU utilizations and clock speed (and of course the fan noise and power at the wall with kill-a-watt meter). Not the most scientific but seems to work.

 

Full disclosure: So far, I tried only 2 intel FBs: one for coffee lake and one headless. I haven't experimented with the various ones available for coffee lake/coffee lake-R to see if the issue gets resolved. I'll try to find time to do this later.

 

[deeveedee]

@ird As @jaymonkey states here (if I understand them correctly), iGPU / dGPU encode/decode may depend on the app and on the automatic handling by macOS.   I'll be curious to learn more about your encode/decode testing so that I can learn (I have little knowledge about it since this hack is my first real experience with dGPUs in macOS).  We will likely have different experiences since our goals are different (I'm not trying to minimize power consumption and instead am trying to maximize performance) and my displays are old 1680x1050 DVI, so they don't tax my dGPU the same as your hi-res display.  The extent of my graphics performance testing (so far) is documented here.

 

My system configuration is as follows:

• BIOS: Boot VGA Display = Integrated GPU (Intel UHD630) (BIOS Boot VGA Display must be Radeon GPU when dGPU-connected display is the only display)
• SMBIOS: macMini8,1
• iGPU framebuffer: 0x3e920000 (required for my DP->DVI adapters and should be different for DP->DP displays)

My current EFI is attached.

 

EDIT: Items to pay attention to in my EFI are:

• DeviceProperties (note that I have eliminated SSDT-GFX0 and am placing all required dGPU properties in PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0))
• NVRAM > Add > 7C436110-AB2A-4BBB-A880-FE41995C9F82 > boot-args

EFI-MM81-RX560x-OC100-22.zip

Edited July 12 by deeveedee

[ird]

On 7/12/2024 at 9:12 AM, deeveedee said:

@ird As @jaymonkey states here (if I understand them correctly), iGPU / dGPU encode/decode may depend on the app and on the automatic handling by macOS.   I'll be curious to learn more about your encode/decode testing so that I can learn (I have little knowledge about it since this hack is my first real experience with dGPUs in macOS).  We will likely have different experiences since our goals are different (I'm not trying to minimize power consumption and instead am trying to maximize performance) and my displays are old 1680x1050 DVI, so they don't tax my dGPU the same as your hi-res display.  The extent of my graphics performance testing (so far) is documented here.

 

My system configuration is as follows:

• BIOS: Boot VGA Display = Integrated GPU (Intel UHD630) (BIOS Boot VGA Display must be Radeon GPU when dGPU-connected display is the only display)
• SMBIOS: macMini8,1
• iGPU framebuffer: 0x3e920000 (required for my DP->DVI adapters and should be different for DP->DP displays)

My current EFI is attached.

 

EDIT: Items to pay attention to in my EFI are:

• DeviceProperties (note that I have eliminated SSDT-GFX0 and am placing all required dGPU properties in PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0))
• NVRAM > Add > 7C436110-AB2A-4BBB-A880-FE41995C9F82 > boot-args

EFI-MM81-RX560x-OC100-22.zip 2.86 MB · 3 downloads

 

Sorry for my sporadic responses. Been juggling with a few things of late 😕

 

I'm attaching my iMac19,2 EFI for perusal. Thank you for the links. I did try forcing GVA to Intel but somehow neither for iMac nor MacMini, websites like Youtube seem to invoke iGFX QS (quicksync) for codecs. I even tried to force H264/5/VP9 through extensions (H265ify, Enhanced-H264ify and confirm no AV1 being delivered on Youtube, the decode for which needs to happen on CPU) but to no avail. It still seems to go to dGFX. To be fair, I can't sure but dGFX clocks are bumped to the highest possible 1.07Ghz and it's power consumptions shoots up to 60W). This seems to need a lot of deeper investigation.

 

One observation is that for me if I use MacMini8,1 EFI with both dGFX and iGFX enabled (with 3DP and intel igfx FB 0x3E9B0007 and rest from your EFI), my boot is much slower in both stage1 and 2. iMac19,2 with headless zips through the boot.

iMac19p2_OC100_iGFX_HL_dGFX_SMU.zip

[deeveedee]

@ird I'll try to duplicate your CODEC test results if you provide your test steps and measurement tools. At this time, I'm not sure how to duplicate your CODEC tests.  Also, to the extent possible, it would help if we communicate with quantifiable metrics (e.g., numbers like. 3.5s vs. "much slower"), so that we're able to compare and duplicate results.

 

I tested boot times for iMac19,2 (headless iGPU, one display) and macMini8,1 (headed iGPU, multiple displays) and observed that the multi-monitor boot time with both iGPU and dGPU-connected displays is ~3.5s slower than the single-monitor dGPU-only boot time.  In what is essentially a 20-second boot time (from OC boot menu to login prompt), that doesn't feel "much slower."  The time difference seems perfectly acceptable for initializing additional displays and switching the boot animation from the BIOS boot display to the macOS Main display.

 

BIOS Boot VGA	SMBIOS	iGPU FB	Connected Displays	macOS Boot Time
iGPU (Intel)	macMini8,1	0x3e920000	2	20.57s
dGPU (AMD)	iMac19,2	0x3e920003	1	17.02s

 

My system configuration for this boot test is listed below.  My macOS Boot Time measurement is taken from the OC boot menu to the macOS Sonoma login prompt.  Before capturing boot times, I deleted and reconfigured PowerManagement settings for each SMBIOS (delete PowerManagement plists, boot with new SMBIOS, disable PowerNap, disable Wake for network, hibernatemode=0, proximitywake=0), reset NVRAM once, boot macOS several times.  Multiple boots before capturing measurements allowed macOS to achieve a steady state before I captured my measurements.  I captured 3 boot times for each SMBIOS and recorded the best time (they did not vary much).

 

Based on my boot-time measurements, the 3.5s additional configuration time for multiple-displays in essentially a 20-second boot-time is hardly noticeable.

 

My system configuration for this boot-time test

• CPU: i5-8600 65W TDP
• Power Supply: 230W
• Memory: 32GB DDR4-2666 (2 x 16GB)
• SSD: m.2 NVMe Western Digital SN750
• macOS: Sonoma 14.5
• Open Core: version 1.0.0
• No Wi-Fi, No Bluetooth (Ethernet only)

 

EDIT: I reviewed your posted config.plist.  I observed the following differences between our test configs:

• You are using iGPU headless FB: 0x3e910003 and I am using iGPU headless FB 0x3e920003
• You are enabling kexts SMCSuperIO.kext and SMCRadeonSensors.kext for your tests
• You are using both igfxfw=2 and igfxrpsc=1 boot-args.  My testing with hacks showed that igfxrpsc=1 should not be set when using igfxfw=2, but I haven't tested this for a while.
• You are adding DeviceProperties Force_Load_FalconSMUFW and PowerPlay configs.  I am not adding these.

 

EDIT2: @ird Here is where I concluded that EliteDesk 800 G4/G5 Mini owners shouldn't be using both boot args.

 

EDIT3: @ird Here is where Andrey1970 (part of Acidanthera team that developed OpenCore) told me not to use igfxrpsc=1.  Note that I changed my username.

Edited July 14 by deeveedee

[ird]

3 hours ago, deeveedee said:

@ird I'll try to duplicate your CODEC test results if you provide your test steps and measurement tools. At this time, I'm not sure how to duplicate your CODEC tests.  Also, to the extent possible, it would help if we communicate with quantifiable metrics (e.g., numbers like. 3.5s vs. "much slower"), so that we're able to compare and duplicate results.

 

I tested boot times for iMac19,2 (headless iGPU, one display) and macMini8,1 (headed iGPU, multiple displays) and observed that the multi-monitor boot time with both iGPU and dGPU-connected displays is ~3.5s slower than the single-monitor dGPU-only boot time.  In what is essentially a 20-second boot time (from OC boot menu to login prompt), that doesn't feel "much slower."  The time difference seems perfectly acceptable for initializing additional displays and switching the boot animation from the BIOS boot display to the macOS Main display.

 

BIOS Boot VGA	SMBIOS	iGPU FB	Connected Displays	macOS Boot Time
iGPU (Intel)	macMini8,1	0x3e920000	2	20.57s
dGPU (AMD)	iMac19,2	0x3e920003	1	17.02s

 

My system configuration for this boot test is listed below.  My macOS Boot Time measurement is taken from the OC boot menu to the macOS Sonoma login prompt.  Before capturing boot times, I deleted and reconfigured PowerManagement settings for each SMBIOS (delete PowerManagement plists, boot with new SMBIOS, disable PowerNap, disable Wake for network, hibernatemode=0, proximitywake=0), reset NVRAM once, boot macOS several times.  Multiple boots before capturing measurements allowed macOS to achieve a steady state before I captured my measurements.  I captured 3 boot times for each SMBIOS and recorded the best time (they did not vary much).

 

Based on my boot-time measurements, the 3.5s additional configuration time for multiple-displays in essentially a 20-second boot-time is hardly noticeable.

 

My system configuration for this boot-time test

• CPU: i5-8600 65W TDP
• Power Supply: 230W
• Memory: 32GB DDR4-2666 (2 x 16GB)
• SSD: m.2 NVMe Western Digital SN750
• macOS: Sonoma 14.5
• Open Core: version 1.0.0
• No Wi-Fi, No Bluetooth (Ethernet only)

 

EDIT: I reviewed your posted config.plist.  I observed the following differences between our test configs:

• You are using iGPU headless FB: 0x3e910003 and I am using iGPU headless FB 0x3e920003
• You are enabling kexts SMCSuperIO.kext and SMCRadeonSensors.kext for your tests
• You are using both igfxfw=2 and igfxrpsc=1 boot-args.  My testing with hacks showed that igfxrpsc=1 should not be set when using igfxfw=2, but I haven't tested this for a while.
• You are adding DeviceProperties Force_Load_FalconSMUFW and PowerPlay configs.  I am not adding these.

 

EDIT2: @ird Here is where I concluded that EliteDesk 800 G4/G5 Mini owners shouldn't be using both boot args.

 

EDIT3: @ird Here is where Andrey1970 (part of Acidanthera team that developed OpenCore) told me not to use igfxrpsc=1.  Note that I changed my username.

 

Thank you for the detailed response deeveedee.

 

Codec tests - here's what I do.

 

1) Run Intel Power Gadget to monitor iGPU frequencies and total package power

2) Run HWMonitorSMC2 and add dGPU frequency, power and temperature to the menubar for realtime info

3) Install h265ify and enhanced-h264ify extensions for edge/chrome and make sure GPU HW acceleration in chrome/edge settings is enabled

4) Under enhanced-h264ify extension settings, disable (block) AV1 code but leave everything else as-is. Under h265ify extension settings, enable h265 (the reason is because both RX560 and UHD630 support h264, h265, vp8 and vp9 codecs in HW but not AV1)

5) Use any video website like Youtube and play videos. Right click on the video and select "Stats for nerds" to confirm that one of the HW supported codecs is what is used for the video stream (avc1/h264, h265, vp8/vp9 show up as-is)

6) Monitor GPU utilization/frequencies/power etc. to "guess" which of the two GPUs are being used

 

Thank you for confirming the boot time differences on your side as well. I don't mind the extra 3-5 seconds but my main concern was if that was indicative of something being broken. My differences are more in the 5 second range (to first view of desktop). My setup:

 

1) Core i5-8500T

2) 230W PSU

3) Hynix DDR-2666 2x16GB

4) Teamgroup TM8FPW002T (MP44) NVMe

5) Intel 9260 Wifi+BT

6) OC 1.0.0 and Sonoma 14.5

7) Attached extension list

 

I shall remove igfxrpsc=1 and test for iMac19,2. For MacMini8,1 I don't use that. Thanks for the pointers, as I was not aware of this quirk. I shall read through the pages and experiment.

 

I'm attaching the MacMini8,1 EFI that has some added changes over your EFI like force loading SMU firmware for dGPU for DVFS (clock scaling/power management). I also added back DAGPM.kext just for testing yesterday but the behavior was same otherwise. Of course, iGFX FB is different from yours (3xDP with audio enabled).

 

EDIT1: One possibility that I hadn't thought about before is that I run a 4K display with 2x supersampling (i.e., "looks like 3008x1692" resolution). That's a bit over 20 million pixels (or like running 2 4K displays) and UHD630 might simply be running out of steam and falling back to dGPU. One of these days, I need to test this theory.

 

MacMini8p1_OC1000_iGFX_Sonoma14p5_dGPU_SMU-2024-7-19.zip

Edited July 14 by ird

[deeveedee]

@ird I will review your testing methodology and try to duplicate it over the next week.

 

By the way, the reason that I chose headless framebuffer 0x3e920003 (and not Dortania's recommend 0x3e910003) is because 0x3e920003 is what is used in a real iMac19,x.

 

Real iMac19 IOReg dump (from AppleLife):

 

I don't think it should make a difference, but that might be something else you want to change and test.

[deeveedee]

Apple release a revised Sequoia Beta 3.  The revised Beta 3 installed without issues on my HackMini8,1 via OTA.  Note that the OTA installer is the full 14+ GB installer.

[deeveedee]

@ird I installed Chrome and the plugins.  When I play YouTube videos, Intel Power Gadget reports an increase in GFX activity.  GFX AVG jumps from 0.00 without YouTube playing to .35 with YouTube playing.  There is clearly Intel GFX activity, although I'm not sure how to interpret it or why it is significant.  All I can say is that the Intel GFX is being utilized with my MacMini8,1 configuration (iGPU Framebuffer 0x3e920000) and Radeon RX 560x. The GFX activity is consistent regardless of which display (dGPU-connected or iGPU-connected) I use to play the YouTube video.  I have confirmed in Chrome that a hardware CODEC (avc1) is being used to play the video.

 

I'll leave interpretation of these results to you.

 

EDIT: My test results were collected with the following configuration:

• macOS Sonoma 14.5
• SMBIOS MacMini8,1
• iGPU Framebuffer 0x3e920000 (multiple iGPU displays) (my EFI is attached here)
• Chrome Version 126.0.6478.127 (Official Build) (x86_64)
• Chrome Extension enhanced-h264ify v2.2.1
• Chrome Extension H264ify With Auto 1080 v 1.1.0
• Intel Power Gadget v3.7.0
• dGPU-connected and iGPU-connected displays: 1680x1050 DP->DVI

 

EDIT2: I was curious about Intel Power Gadget readings when benchmarking with Unigine Valley.  With the UV benchmark running, Intel Power Gadget reports GFX AVG 0.00.  I am typing this post as the UV benchmark is running (UV benchmark on one display and Safari on another display) and there is NO lag (not surprising, since Intel Power Gadget reports about 10W CPU power consumption while the UV benchmark is running.  This is exactly what I would expect.  It continues to look to me as though my multi-display configuration with combined dGPU-connected and iGPU-connected displays is working perfectly with the optimal balance of dGPU and iGPU acceleration.  

 

EDIT3: The packaging of the EliteDesk Mini with RX 560x is very well done.  The RX 560x vents out of the top (through the vented EliteDesk cover).  This means that the dGPU does not heat the small enclosure.  While I'm running the Unigine Valley benchmark on one display and typing this on the other display, the Intel CPU temp is 45-50C while the RX 560x fan is at max.

Edited July 16 by deeveedee

[ird]

2 hours ago, deeveedee said:

@ird I installed Chrome and the plugins.  When I play YouTube videos, Intel Power Gadget reports an increase in GFX activity.  GFX AVG jumps from 0.00 without YouTube playing to .35 with YouTube playing.  There is clearly Intel GFX activity, although I'm not sure how to interpret it or why it is significant.  All I can say is that the Intel GFX is being utilized with my MacMini8,1 configuration (iGPU Framebuffer 0x3e920000) and Radeon RX 560x. The GFX activity is consistent regardless of which display (dGPU-connected or iGPU-connected) I use to play the YouTube video.  I have confirmed in Chrome that a hardware CODEC (avc1) is being used to play the video.

 

I'll leave interpretation of these results to you.

 

EDIT: My test results were collected with the following configuration:

• macOS Sonoma 14.5
• SMBIOS MacMini8,1
• iGPU Framebuffer 0x3e920000 (multiple iGPU displays) (my EFI is attached here)
• Chrome Version 126.0.6478.127 (Official Build) (x86_64)
• Chrome Extension enhanced-h264ify v2.2.1
• Chrome Extension H264ify With Auto 1080 v 1.1.0
• Intel Power Gadget v3.7.0
• dGPU-connected and iGPU-connected displays: 1680x1050 DP->DVI

 

EDIT2: I was curious about Intel Power Gadget readings when benchmarking with Unigine Valley.  With the UV benchmark running, Intel Power Gadget reports GFX AVG 0.00.  I am typing this post as the UV benchmark is running (UV benchmark on one display and Safari on another display) and there is NO lag (not surprising, since Intel Power Gadget reports about 10W CPU power consumption while the UV benchmark is running.  This is exactly what I would expect.  It continues to look to me as though my multi-display configuration with combined dGPU-connected and iGPU-connected displays is working perfectly with the optimal balance of dGPU and iGPU acceleration.  

 

EDIT3: The packaging of the EliteDesk Mini with RX 560x is very well done.  The RX 560x vents out of the top (through the vented EliteDesk cover).  This means that the dGPU does not heat the small enclosure.  While I'm running the Unigine Valley benchmark on one display and typing this on the other display, the Intel CPU temp is 45-50C while the RX 560x fan is at max.

 

Thank you for confirming and being thorough in reporting the details, deeveedee. Highly appreciated! Your results are very encouraging and point to everything working as expected/most optimal way for this system with igfx doing the video duties. I still suspect my "almost two 4K displays" situation to be the culprit. I shall continue my testing.

 

I agree with you on how well this system has been put together. I don't have experiences with G6 and beyond but considering the attention-to-detail in this machine and the price, it's a steal for what it can do.

 

EDIT1: I've stuck to keeping both the chrome extensions - h264/h265ify as I find them quite useful. When I stream from my Plex media server, I observe that most of the content no longer needs to be transcoded and Youtube serves content in a HW accelerated codec, keeping the CPU very lightly loaded.

 

Edited July 16 by ird

[deeveedee]

@ird You're welcome. I'm glad to have someone else who's testing this. We make a good team. 

 

If you're up for an experiment, I am curious about something. The iGPU framebuffer I use (0x3e920000) is classified in WhateverGreen docs as a 'Mobile Framebuffer'.  Framebuffer 0x3e9b0007 is a desktop Framebuffer, not a Mobile Framebuffer. Through trial and error, I found that only  a Mobile Framebuffer supports my DP->DVI adapters (a Desktop Framebuffer boots to blackscreen with my DP->DVI adapters), so there is clearly something different about Mobile Framebuffers.

 

If you use FB 0x3e920000 with your DP->DP (using the correct framebuffer connector type in your DeviceProperties instead of the HDMI connector type that I use), do you observe a difference in your iGPU behavior?

Edited July 16 by deeveedee

[ird]

7 hours ago, deeveedee said:

@ird You're welcome. I'm glad to have someone else who's testing this. We make a good team. 

 

If you're up for an experiment, I am curious about something. The iGPU framebuffer I use (0x3e920000) is classified in WhateverGreen docs as a 'Mobile Framebuffer'.  Framebuffer 0x3e9b0007 is a desktop Framebuffer, not a Mobile Framebuffer. Through trial and error, I found that only  a Mobile Framebuffer supports my DP->DVI adapters (a Desktop Framebuffer boots to blackscreen with my DP->DVI adapters), so there is clearly something different about Mobile Framebuffers.

 

If you use FB 0x3e920000 with your DP->DP (using the correct framebuffer connector type in your DeviceProperties instead of the HDMI connector type that I use), do you observe a difference in your iGPU behavior?

 

I tried 0x3e920000 FB with connector patches but the results were the same - tried both MacMini8,1 as well as iMac19,2. I've always been curious what's with the Mobile vs Desktop FB. I haven't found a good source to read up in depth technical information. If you find some literature let me know as well.

 

I have some interesting results to report though. Today I received Core i5-8600 (65W CPU) that I'd ordered a few days ago. It replaced the OG i5-8500T (35W) and got augmented with a 230W PSU. With this HW change, I made few other changes

 

1) Under iGPU Device Properties in config.plist:

  1a) Changed FB to 0x3e920003 as per your earlier suggestion (headless)

  1b) Added device-id = 9B3E000 (I understand this to be purely cosmetic but I could be wrong)

 

2) Under dGPU Device Properties in config.plist:

  2a) Removed WorkLoad_Policy

  2b) Removed all SMU force load firmware

 

3) Removed DAGPM.kext

 

The result is that Intel Power Gadget shows that iGPU frequency while playing a VP9 Youtube video is pegged at 1.15Ghz (which should logically mean that iGPU is being used - which is great news!). I also, however, see that dGPU is stuck at 1.07Ghz (the highest clock), and this is true as long as Chrome or Edge are open. I am inclined to believe that iGPU is now being used for all video decode/encode tasks and Chrome/Edge somehow are using dGPU for something else? It's possible something on Youtube website uses 3D acceleration (webGL?) and hence this behavior. Outside of Chrome/Edge, I see that dGPU throttles down to 233Mhz so that confirms power management is working properly. 

 

I will continue testing iGPU decode on more websites/HW supported codecs to confirm this wasn't a one off. If this behavior is consistent, I might freeze my EFI for now, stop tinkering and mark it as stable.

 

Meanwhile, if anyone is interested in my iMac19,2 EFI I'm attaching it (I've stripped out Intel Wifi+BT kexts to reduce overall size, config.plist is updated accordingly as well).

 

EDIT1: Unrelated but, to your point about this machine being designed very well - the only thing I wish HP did was to make the second M.2 NVMe slot useful with dGPU on. Without dGPU and HDD Caddy, you could still cut a hole through it but with RX560X module, at least I didn't find a way to make it work. Has anyone else?

 

iMac19p2_OC1000_2024-07-17.zip

Edited July 17 by ird

[deeveedee]

@ird Thanks for testing.  Overriding the default device-id should be unnecessary and seems rather arbitrary - what is your reasoning for changing device-id?

 

You can inspect IOReg with and without DAGPM.kext to see if it is needed (make sure AGPM is properly loaded for both iGPU and dGPU).  iMac19,2 offers a RX 560x option, so native iGPU and dGPU power mgmt may be fully supported for SMBIOS iMac19,2 without DAGPM.kext, but you can test if you want to.  After my initial testing where I was still refining my proposed EFI, I didn't see any behavioral differences with/without DAGPM.kext when I tested iMac19,2 SMBIOS.  Note that the DAGPM.kext that I provided for SMBIOS iMac19,2 is different from the DAGPM.kext that I provided for MacMini,8,1.  I know you know this, but just stating for others who may want to test.

Edited July 17 by deeveedee