Does Apple load microcode for the IGPU?

Someone asked me if I knew if Apple loads Graphics micro code (Guc) for the IGPU and I can confirm that. Yes it does. Take a look at the following log data from my Apple MacBookPro13,3:

kernel: (AppleIntelSKLGraphics) [IGPU] Will fallback to host-side scheduling if graphics firmware fails to load
kernel: (AppleIntelSKLGraphics) [IGPU] Chose to use graphics firmware based on platform
kernel: (AppleIntelSKLGraphics) [IGPU] Graphics accelerator is using scheduler interface revision 3: Apple Firmware
kernel: (AppleIntelSKLGraphics) [IGPU] Scheduler: Multiple channel indexes per command streamer
kernel: (AppleIntelSKLGraphics) [IGPU] Scheduler: Process CSB using HWS.
kernel: (AppleIntelSKLGraphics) [IGPU] Scheduler: PM notify enabled
kernel: (AppleIntelSKLGraphics) [IGPU] Graphics Address: PPGTT, Separate Address Space
kernel: (AppleIntelSKLGraphics) [IGPU] MultiForceWake Enabled: Using 3D Driver
kernel: (AppleIntelSKLGraphics) [IGPU] Begin GuC load process
kernel: (AppleIntelSKLGraphics) [IGPU] Begin GuC load process
kernel: (AppleIntelSKLGraphics) [IGPU] ForceWake Multithread = 0x20002
kernel: (AppleIntelSKLGraphics) [IGPU] ForceWake Multithread = 0x20002
kernel: (AppleIntelSKLGraphics) [IGPU] CONFIG0 (0xD00) = 0x80000000
kernel: (AppleIntelSKLGraphics) [IGPU] CONFIG0 (0xD00) = 0x80000000
kernel: (AppleIntelSKLGraphics) [IGPU] GT_THREAD_STATUS = 0x400b0000
kernel: (AppleIntelSKLGraphics) [IGPU] GT_THREAD_STATUS = 0x400b0000
kernel: (AppleIntelSKLGraphics) [IGPU] Doing retry #0
kernel: (AppleIntelSKLGraphics) [IGPU] Doing retry #0

Debugging sleep issues…

A lot of people are still facing sleep/wake related issues and I like to figure out why so please check:

IOService:/AppleACPIPlatformExpert/IOPMrootDomain/PMStatusCode

1.) Is that number a zero or some other value?
2.) Do you have a property with the name: IOPMDeepIdleSupported?
3.) Do you have a property with the name: IOPMSystemSleepType?

If the answer for the first question is zero, then I would like to know if you are using a dGPU or IGPU only.

The second question can be solved by adding the following code to your ACPI tables:

Scope (\_SB)
{
    Method (LPS0, 0, NotSerialized)
    {
        Store ("Method \\_SB._LPS0 Called", Debug)
        Return (One)
    }
}

Scope (\_GPE)
{
    Method (LXEN, 0, NotSerialized)
    {
        Store ("Method \\_GPE.LXEN Called", Debug)
        Return (One)
    }
}

If the answer for the last question is yes, then what value is it, and what SMBIOS are you using? Please note that this specific property is not part of Yosemite. The value represents the lowest possible sleep state and is checked by the following kexts:

AppleACPIPlatform.kext
AppleIntelBDWGraphicsFramebuffer.kext
AppleIntelFramebufferAzul.kext
AppleIntelSKLGraphicsFramebuffer.kext
AppleSDXC.kext
AppleStorageDrivers.kext
IO80211Family.kext
IOBluetoothFamily.kext
IONVMeFamily.kext
IOUSBAttachedSCSI.kext
IOUSBMassStorageDriver.kext

That should be enough reasons for you to want that property.

I also added the following code to my ACPI tables:

Scope (\)
{
   Name (SLTP, Zero)

   Method (_TTS, 1, NotSerialized)
   {
       Store ("Method \\__TTS Called", Debug)
       Store (Arg0, SLTP)
   }
}

This, with additional checks, is used by Apple to skip parts for the NVMe SSD (RP01/IOPP/SSD0@0), AirPort (RP09/IOPP/ARP@0) and camera (RP10@1D,1/IOPP/CMRA) devices

NVRAM

There are two interesting NVRAM properties:

#define kIOSleepWakeDebugKey        "Persistent-memory-note"
#define kIOEFIBootRomFailureKey     "wake-failure"

That has to be it for now. Maybe later more…

AppleIntelSKLGraphicsFramebuffer.kext

Here is the first data from the AppleIntelSKLGraphicsFramebuffer.kext binary that I like to share with you:

06 00 1B 19 00 00 00 00 91 09 08 00 00 00 00 00
01 01 01 01 00 00 60 02 00 00 00 00 00 00 00 60
6C 05 00 00 6C 05 00 00 00 00 00 00 00 00 00 00
00 00 08 00 02 00 00 00 98 04 00 00 FF 00 00 00
01 00 00 00 20 00 00 00 FF 00 00 00 01 00 00 00
20 00 00 00 FF 00 00 00 01 00 00 00 20 00 00 00
02 13 13 00 00 00 06 00 03 00 00 00 04 00 00 00
80 DF 17 10 00 00 00 00 78 05 00 00 D2 05 00 00
40 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00
10 23 1B 00 00 00 00 00 60 24 1B 00 00 00 00 00
60 24 1B 00 00 00 00 00 01 00 00 00 08 00 00 00
00 00 00 00 00 00 00 00

The above example will activate/support only one display, and some of the data is well known by now so I am going to skip stuff like the black value, which is (still) the platformID.

Unused/disabled frame buffer data (see orange values) have also changed.

New are the red values, all represent a different kinds of version information.

New is the blue value, representing the number of Slices (Slice Count).

New is the green value, representing the number of Execution Unit (EU Count).

The purple data is used for the TCON configuration.

See also:

AppleIntelFramebufferAzul.kext (Part I)
AppleIntelFramebufferAzul.kext (Part II)
AppleIntelFramebufferAzul.kext (Part III)