Contribute
Register

[SUCCESS] Gigabyte Designare Z390 (Thunderbolt 3) + i7-9700K + AMD RX 580

Yes no DP-in is unfortunate, for a while I thought about getting a designare board but when I found out that one of the ports had to be driven from the IGPU it made me reconsider and since firmware patching has began I have even less reason now. I am really happy with how this system is running, and how the Thunderbolt 3 AIC is working with my devices.

But you have to admit: native TB is something else (meaning waaay better than AIC)
 
Good point -- from the running system we can see that _E23 is the right one. The hot plug event handler is generally surrounded by other Thunderbolt methods under Scope GPE.

@losinka, there is nothing scary about this. You cannot damage the system if you pick the wrong event handler. The only thing that will happen is ... nothing. Specifically, no hot plug.

For total clarity: the RUNNING system's method is XTBT, so would that mean renaming it... XXTB? :)
 
I don't wanna ruin everyone's RadeonBoost party, but so far in my testing, I only found my system to be slower with the kext. Let me explain:

I'm running a VEGA 64 8GB and 9900KS on Clover with iMacPro1,1 with iGPU disabled (in hindsight, the 9900KS doesn't make any sense whatsoever). I tried various setups: iMac19,1 instead of iMacPro, enabled and disabling iGPU, with and without the SSDT. Even though I do sometimes see a significant increase in GB5 scores, I have never experienced an increase in render times in DaVinci Resovle 16. Futhermore, all tested setups and combinations resulted in significantly lower performance. I tested the same video with each setup (a combination of multiple camera's and formats including H264, H265, retiming, LUTs and titles). For instance, using the setup as described above, without RadeonBoost, gets me about 55 fps when rendering 4K H264 clip. Using RB, this drops to around 30-35. As video rendering and video editing is the main reason I built this setup, this kext unfortunately doesn't make sense to me.

I think it's important to talk about this. Better GB scores are nice and all, but translation to real-world performance is way more important to me.
In my testing SMBIOS 18,3 is faster than 19,1. Not sure why.
 
For total clarity: the RUNNING system's method is XTBT, so would that mean renaming it... XXTB? :)

what would be interesting would be to use MaciASL to edit your "original" dsdt, changing the .GPE._E23 method to XE23. put the edited dsdt.aml into clover/acpi/patched and reboot. see if whatever gremlin renamed _E23 to XTBT is able to rename XE23 to XTBT.


if the running dsdt preserves the renamed XE23 then I would proceed with the rest of the guide.
 
what would be interesting would be to use MaciASL to edit your "original" dsdt, changing the .GPE._E23 method to XE23. put the edited dsdt.aml into clover/acpi/patched and reboot. see if whatever gremlin renamed _E23 to XTBT is able to rename XE23 to XTBT.


if the running dsdt preserves the renamed XE23 then I would proceed with the rest of the guide.

I think that would be a lot of hassle for me on OC as I think I'd have to drop my DSDT and ALL subsequent SSDTs then re-add them in ACPI, and wouldn't this be functionally identical?
Code:
    External (_GPE.XXTB, MethodObj)
    //
    Scope (\_GPE)
    {
        Method (XTBT, 0, NotSerialized)  // _Exx: Edge-Triggered GPE, xx=0x00-0xFF
        {
            If (_OSI ("Darwin"))
            {
                \_SB.PCI0.RP05.UPSB.AMPE ()
                \_SB.PCI0.RP05.UPSB.UMPE ()
            }
            Else
            {
                XXTB ()
            }
        }
    }
 
** Micro-Guide: Significantly Speed Up Intel UHD630 iGPU **
I tried this on an Asus Rog Strix Z370-I Gaming, Intel i7 8700, SMBIOS 19,1, latest Lilu and WhateverGreen BUT the system doesn't boot. I get a long boot bar...
The system works fine without it.
 
Correct -- DarkWake is when the computer wakes up, but keeps the monitor turned off. Hence "dark" wake. This mode is used to perform background tasks, process scheduled events and notifications, etc. The important thing to check is whether monitor is indeed off during a DarkWake event.

DarkWakes are both normal and desirable.
What if you don't want them?
For exAmple you have a PC in your bedroom and don't want the clicks and liquid cooling starting up...?
Is there a way to disable completely the function?
Thanks!
 
  • MSR 0xE2 must be unlocked for native NVRAM. See procedure here.
    • VarOffset is 0x5C1 for BIOS F6, F7, F8, and F9b. If you're on an earlier version, please go through the full procedure to determine the VarOffset
I unlocked my MSR 0xE2 a while back. I'm still on F6 and haven't updated to F9b yet. Does the process for unlocking MSR 0xE2 have to be repeated once the Firmware is updated to F9b? Also, are there benefits to updating to F9b?
 
What if you don't want them?
For exAmple you have a PC in your bedroom and don't want the clicks and liquid cooling starting up...?
Is there a way to disable completely the function?
Thanks!
Try using various values of darkwake, such as darkwake=No. This can be added to Boot Arguments in Clover Configurator.
 
I unlocked my MSR 0xE2 a while back. I'm still on F6 and haven't updated to F9b yet. Does the process for unlocking MSR 0xE2 have to be repeated once the Firmware is updated to F9b? Also, are there benefits to updating to F9b?
MSR 0xE2 will have to be unlocked once again, but it's still at the same VarOffset address of 0x5C1. Firmware F8 introduced a new GUI. Other information is found on Gigabyte's website:

Screen Shot 2020-05-12 at 11.13.10 AM.png


From a Hackintosh point of view, there's no need to update the firmware. You may do so at your choosing.
 
Back
Top