ACPI GPUC device on iMac20,x

[rafale77]

I was reviewing the ioreg of a real iMac and comparing it to me setup and found a GPUC device with "APP000B" name.

Some research on this device name prompted that it shows up as GMUX on MBP and GCON on MP and is a GPU multiplexer/GPU controller used to switch between GPUs. As I am struggling to get DRM working without compromising Sidecar/Facetime on Monterey this became of great interest.

Thinking it may just be cosmetic however, I tested various injections of a dummy device and also using a modified version of this DSDT (So that it goes under ./SB instead of /LPCB or /PCI0) but every time the GPUC, Monterey fails to boot. It crashes and reboot at the time of re-loading of the GPU driver.

 

Any body tried this? Some people have used this DSDT on laptops so it must have worked at some point. It also doesn't appear to be purely cosmetic since it causes a crash...

 

[Guest 5T33Z0]

@rafale77 It's a SSDT, not a DSDT – big difference! And it's from 2018. By th time 10th gen Intel CPUs weren't even out. Did you check if the "External" items referenced in this SSDT even exist in your DSDT?

 

And how is it supposed to work? By letting th iGPU handle the DRM stuff or what's the idea behind it?

[rafale77]

6 hours ago, Hervé said:

Afaik, iMac20,1 do not have dual GPU, only AMD Radeon dGPUs, so I'd be surprised if such a recent Comet Lake platform was fitted with that old GMUX device Apple previously used in MacBookPro computers.

You probably are well aware that there was/is no support for dual GPU on Hackintosh or I should say for switching between dual GPU (i.e Optimus-like operation). What's usually supported on some laptops is built-in LCD off the iGPU and external screens off the dGPU (due to physical wiring of the output ports). Not what most people understand as "dual GPU support"...

What's the likely link with DRM on your Hackintosh here?

 

Thank you for the quick answer. From my research, it appears that indeed iMacs get a GPUC device, while laptops get a GMUX one under the same ioreg name. All iMacs actually leverage both the intel iGPU and a dGPU. As evidenced by how for example sidecar works: While the main screen is being driven by the dGPU, the iMac encodes using HEVC on the iGPU to send the image to the sidecar device while processing the cursor framebuffer still on the dGPU. Both GPUs are being used at the same time with the iGPU used really as a coprocessor. This is the reason why forcing applegva to use only the dGPU causes a lot of functionality loss or instabilities for these specific features. Newer devices without a iGPU (MacPro and IiMacPro) have the T2 chip to do that work. I am not really looking for an Optimus-like operation. I am however very curious as to what it does and what we are we missing from not having it.

What does it have to do with DRM? I don't know, I am just exploring. The main problem at the moment is that DRM runs fine video decoding is run on the dGPU but then Sidecar and Facetime become very glitchy and unreliable. I am trying to get both working without needing to run a terminal command to force running one or the other depending on the application I run.

 

 

5 hours ago, 5T33Z0 said:

@rafale77 It's a SSDT, not a DSDT – big difference! And it's from 2018. By th time 10th gen Intel CPUs weren't even out. Did you check if the "External" items referenced in this SSDT even exist in your DSDT?

 

And how is it supposed to work? By letting th iGPU handle the DRM stuff or what's the idea behind it?

 

You are correct. It was a typo on my part and it seems I repeated it. I did check all the external items in my DSDT and they exist. I even tried simplifying it to the point of creating just a dummy with read only values with no external calls and the result is the same. The simple presence of a ./_SB/GPUC device in ioreg causes macOS to crash. This entry is in the iMac20,1 ioreg. I am just wondering if it's presence would make switching GPUs or appleGVA device easier or if maybe it could be one of the reasons why DRM doesn't work with a non Apple version of the intel GPU.

[theroadw]

I did a lot of research on this a while back, and if the GPUC/GMUX devices exist in an ssdt, the entire display manager uses it (or tries to) and when the fake device doesn't work as it should, you get a hard crash.

On my Zbook G5 I  have a working dual GPU configuration that I can switch at will using a similar acpi call just like macbooks do, the zbook has 2 mux chips that can be switched so I can run the lcd or external displays using either gpu. 

(I actually have 2 setups I ended up with, dgpu (amd wx4170) for all displays and igpu in the background for quicksync and jpeg quickview, etc... I also get full DRM in this configuration since the amd gpu draws the screens and the igpu helps with h264 encoding, etc...

My other setup is dgpu off and flip both mux switches to igpu only. In this case DRM is broken, but I have about 2 extra hours of battery life. 

 

If I remember correctly the switch on macbooks is performed by method SGII, while in my zbook it is done by SGOV.

By searching for this method you will see there's a logic switch in device GPUC that enables or disables gpu outputs and switches the MUX chip, but this seems to be handled by the GMUX or GPUC device driver.

 

 

I tried faking the device using the same switch logic and changing the calls to my mux addresses but the crash still happened, so the driver actually expects to talk to a GMUX physical device chip or you get a crash.

 

In Zbook the mux chip switch call comes from Method HGGW, where Arg2 is the Mux chip address and Arg4 is 1 or Zero to flip the switch output

 

Edited June 2, 2022 by theroadw
added images

[rafale77]

Thank you @theroadw! You answered before I could tag you. It seemed indeed that you had played with this.

 

When looking at my DSDT I see the following two similar methods:

     Method (SGOV, 2, Serialized)
        {
            Local0 = GGRP (Arg0)
            Local1 = GNMB (Arg0)
            Local2 = (GADR (Local0, 0x02) + (Local1 * 0x10))
            OperationRegion (PDW0, SystemMemory, Local2, 0x04)
            Field (PDW0, AnyAcc, NoLock, Preserve)
            {
                TEMP,   1, 
                Offset (0x04)
            }

            TEMP = Arg1
        }

        Method (SGII, 2, Serialized)
        {
            Local0 = GGRP (Arg0)
            Local1 = GNMB (Arg0)
            Local2 = (GADR (Local0, 0x02) + (Local1 * 0x10))
            OperationRegion (PDW0, SystemMemory, Local2, 0x04)
            Field (PDW0, AnyAcc, NoLock, Preserve)
            {
                    ,   23, 
                TEMP,   1, 
                Offset (0x04)
            }

            TEMP = Arg1
        }

 The GPUC injection I found appears to be using SGII and GGIV.

 

I am also suspecting that while GMUX is a physical device, that GPUC could be a piece of firmware since the iMac technically don't have multiplexing of the GPUs. This is also supported by the use of different injections I have found for the two devices.

With your dGPU setup, are you able to get reliable Sidecar: My indicator is to move my mouse cursor to the ipad device and frantically move it back and forth on screen, when run on the dGPU, the ipad screen freezes within seconds. On the intel GPU, it doesn't. Since you are thus running applegva decoding on the dGPU, I wonder if Sidecar encoding is running on the iGPU. If so, how did you do it?

 

 

[theroadw]

SGOV, GGOV, SGII GGII are similar generic calls, they (Set or Get) the value of some memory address based on preset offsets that are unique to each machine. 

So GGOV will return the bit status (1 or 0) and SGOV will change it to what we tell it to. 

They both need an address as input and other methods call them. In zbooks the call comes from HGGW (Hybrid Graphics something something) and in macbooks the call is made by Method _L15 under scope \_GPE. 

 

I unfortunately can't test sidecar since I don't have a compatible iPad, but when I do screen sharing for example I see load in the igpu meters in activity monitor, so the igpu is handling some related tasks. 

 

I am sure lot of this behavior is smbios dependent. On early tests using different smbios, sometimes both gpus wouldn't be used, or no jpeg preview if igpu wasn't present, etc...

So if you have multiple gpus and they both work, my suggestion is to try different smbios and find which one does what you need, then if needed adjust for cpu performance using cpufriend. 

 

Keep in mind that DRM is usually handled by the gpu that draws the screen, so if your monitor is plugged to the amd card, you should be fine,  but if you're using the igpu to draw your display,  you have to use the GVA hack you mentioned do the dgpu will handle DRM and then other things may break.

Edited June 2, 2022 by theroadw

[rafale77]

@Hervé, Indeed that's how the iMac SMBIOS are setup. That's what I meant by dual GPU setup. Sorry for not being clear. The Dortania guide and whatevergreen document this very well.

@theroadw, I found interesting indeed that this GPUC device doesn't exist on the iMac19, it only shows up on the iMac20 so it may not be that important after all. I also noticed that HDEF have been dropped out of the iMac20 ioreg. This makes me wonder if it would be safer for me to go to an iMac19 SMBIOS in spite of running a comet lake setup... Also, on the iMac, DRM is setup to be handled by the iGPU by default and to draw with the dGPU. It may be different from the macbook pros. If that's the case, I may want to switch to a macbook pro smbios which may involve other complications for my desktop...

Edited June 2, 2022 by rafale77

[theroadw]

I remember reading about GPUC as a chip that performs the switch from dgpu to igpu or viceversa, but it does this at the exact moment the screen blanks so the user doesn't notice the switch. My guess is that it would be controlled by skylight or display manager directly and this GPUC device then sends the command to switch directly to the mux chips.

I believe I tried adding GMUX device to my zbook and there was no change, but GPUC always crashes.

 

If your only option is for igpu to handle DRM, then without knowing what Apple's secret sauce is inside their custom chips, or a T2 for that matter, then it may never work.

 

Also I just remembered that for my dual gpu setup in zbook I need to inject a device id with framebuffers to the igpu or it doesn't boot. Dortania guide suggests an empty framebuffer for this configuration, but for macbook pro smbios it only works if the igpu can draw a screen, even if the mux switch is never in the position where that screen would work. (If that makes any sense) probably the display manager has the main screen buffered to igpu constantly so it can do the switch at any time like in real dual gpu macbooks. 

Very different from imac with no mux capability 

Edited June 2, 2022 by theroadw

[rafale77]

5 hours ago, theroadw said:

I remember reading about GPUC as a chip that performs the switch from dgpu to igpu or viceversa, but it does this at the exact moment the screen blanks so the user doesn't notice the switch. My guess is that it would be controlled by skylight or display manager directly and this GPUC device then sends the command to switch directly to the mux chips.

I believe I tried adding GMUX device to my zbook and there was no change, but GPUC always crashes.

 

If your only option is for igpu to handle DRM, then without knowing what Apple's secret sauce is inside their custom chips, or a T2 for that matter, then it may never work.

 

Also I just remembered that for my dual gpu setup in zbook I need to inject a device id with framebuffers to the igpu or it doesn't boot. Dortania guide suggests an empty framebuffer for this configuration, but for macbook pro smbios it only works if the igpu can draw a screen, even if the mux switch is never in the position where that screen would work. (If that makes any sense) probably the display manager has the main screen buffered to igpu constantly so it can do the switch at any time like in real dual gpu macbooks. 

Very different from imac with no mux capability 

 

That's why I am so reluctant to switch to a mbp smbios... I don't know what else will break. I actually need the dGPU to handle DRM but for it to switch back to iGPU H.264/HEVC processing when DRM is not needed.

I tested injecting various board IDs to AppleGVA using unfairGVA command by rebuilding my custom whatevergreen. All iMac process videos through the iGPU by default even the drawing is with the dGPU. Only the iMacPro and MacPro go to the dGPU (of course since they don't have an iGPU). I also tested injecting MBP board id and it stills process videos through the iGPU but it then breaks SideCar altogether with a IGPU codec failure. I am checking which GPU is being used using this tool.

 

In any case, I would be interested to know what MacOS does with the GPUC device on the iMac20 which it didn't get to do with the iMac19.

 

[rafale77]

Found what I think is a working solution to my problems... Seems like GPUC is not all that critical even though MacOS does look for it.

Edited June 3, 2022 by rafale77

[Guest 5T33Z0]

@rafale77 MacPro7,1 doesn't use gpuc. Neither in ioreg nor in DSDT. But feel free to check for yourself: https://github.com/khronokernel/DarwinDumped