Apple Drops “Late” for 2016 MacBook Pro Models…

I checked for new Mac model serials and found that Apple dropped the “Late” part for the MacBook Pro models. Here is the new data:

GY25 – MacBook Pro (13-inch, 2016, Two Thunderbolt 3 ports)
GY6N – MacBook Pro (13-inch, 2016, Two Thunderbolt 3 ports)
GYFH – MacBook Pro (13-inch, 2016, Four Thunderbolt 3 Ports)
GYGR – MacBook Pro (13-inch, 2016, Four Thunderbolt 3 Ports)

H03M – MacBook Pro (15-inch, 2016)
H03Q – MacBook Pro (15-inch, 2016)
H03Y – MacBook Pro (15-inch, 2016)
H040 – MacBook Pro (15-inch, 2016)
H03T – MacBook Pro (15-inch, 2016)
HF1R – MacBook Pro (13-inch, 2016, Four Thunderbolt 3 Ports)
HF1P – MacBook Pro (13-inch, 2016, Four Thunderbolt 3 Ports)
HF1Q – MacBook Pro (13-inch, 2016, Four Thunderbolt 3 Ports)
HF1T – MacBook Pro (13-inch, 2016, Four Thunderbolt 3 Ports)
HP49 – MacBook Pro (13-inch, 2016, Four Thunderbolt 3 Ports)
HP4D – MacBook Pro (13-inch, 2016, Four Thunderbolt 3 Ports)
HV5M – MacBook Pro (13-inch, 2016, Two Thunderbolt 3 ports)
HV5H – MacBook Pro (13-inch, 2016, Two Thunderbolt 3 ports)
HV5J – MacBook Pro (13-inch, 2016, Two Thunderbolt 3 ports)
HV5K – MacBook Pro (13-inch, 2016, Two Thunderbolt 3 ports)
HV5L – MacBook Pro (13-inch, 2016, Two Thunderbolt 3 ports)
HV5G – MacBook Pro (13-inch, 2016, Two Thunderbolt 3 ports)
HV5D – MacBook Pro (13-inch, 2016, Two Thunderbolt 3 ports)
HV5N – MacBook Pro (13-inch, 2016, Two Thunderbolt 3 ports)
HWCH – MacBook Pro (13-inch, 2016, Two Thunderbolt 3 ports)
HWH2 – MacBook Pro (13-inch, 2016, Four Thunderbolt 3 Ports)
HXD5 – MacBook Pro (13-inch, 2016, Four Thunderbolt 3 Ports)
HXF8 – MacBook Pro (15-inch, 2016)
HYP5 – MacBook Pro (13-inch, 2016, Two Thunderbolt 3 ports)

I have no idea why, and Apple may change it back at any time, but this is a first.

Edit:

The data for About This Mac is cached after it is pulled from the Apple server. You can find it here:

~/Library/Preferences/com.apple.SystemProfiler.plist

See also this screenshot:

late_removed_fromname

New Kaby Lake Based Mac Models…

Mac-B4831CEBD52A0C4C – two models with a maximum Turbo Boost of 3400 and 4000 MHz. This one uses the exact same processor power management data as the new MacBookPro13,1.

Mac-CAD6701F7CEA0921 – three models with a maximum Turbo Boost of 3500/3700 and 4000 MHz. This one uses the exact same processor power management data as the new MacBookPro13,2.

Mac-551B86E5744E2388 – three models with a maximum Turbo Boost of 3800/3900 and 4100 MHz. This one uses the exact same processor power management data as the new MacBookPro13,3.

I checked the perf-bias setting (5) and that suggests that the data is not for Mac desktop models. On desktop models like the iMac perf-bias is set to 1 (highest performance).

Here are the Intel processors that could be used. Some are already known. For the rest of them we have to wait for additional data (scroll down to the update).

3400 MHz

i5-7260U with Intel® Iris™ Plus Graphics 640 (15W)
i5-7287U with Intel® Iris™ Plus Graphics 650 (28W)

3500 MHz

i7-7500U with Intel® HD Graphics 620 (15W)
i5-7267U with Intel® Iris™ Plus Graphics 650 (28W)
i5-7300U withIntel® HD Graphics 620 (15W)
i5-7300HQ with Intel® HD Graphics 630 (45W)

3700 MHz

i5-7287U with Intel® Iris™ Plus Graphics 650 (28W)

3800 MHz

i7-7700HQ with Intel® HD Graphics 630 (45W)
i7-7560U with Intel® Iris™ Plus Graphics 640 (15W)
i5-7440HQ with Intel® HD Graphics 630 (45W)

3900 MHz

i7-7820HQ with Intel® HD Graphics 630 (45W)

4000 MHz

i7-7567U with Intel® Iris™ Plus Graphics 650 (28W)
i7-7660U with Intel® Iris™ Plus Graphics 640 (15W)

4100 MHz

i7-7920HQ with Intel® HD Graphics 630 (45W)

The one with board-id Mac-551B86E5744E2388 is already being checked in ApplePlatformEnabler::probe(IOService*, int*)

There is no GPU data defined as of yet, but this may change at a later date.

Ok. I’m now convinced that the board-id’s that I found are for a series of updated MacBook (Pro) models. One note. The data pointing to faster Intel graphics may also be used for a new Mac mini. Just a wild idea of course 😉 Nope. It was too good to be true. Sorry folks.

Hey. I might be wrong, but when was the last time that I completely missed the boat?

Update: Ok. I figured it out. Let’s start with the MacBookPro13,1

Intel Core i5-6360U 2.0 GHz (max Turbo Boost 3.1 GHz) with Intel® Iris™ Graphics 540 (15W)
Will be replaced by the:
Intel Core i5-7260U 2.2GHz (max Turbo Boost 3.4 GHz) with Intel® Iris™ Plus Graphics 640 (15W)

Intel Core i7-6660U 2.4 GHz (max Turbo Boost 3.4 GHz) with Intel® Iris™ Graphics 540 (15W)
Will be replaced by the:
Intel Core i7-7660U 2.5 GHz (max Turbo Boost 4.0 GHz) with Intel® Iris™ Plus Graphics 640 (15W)

MacBookPro13,2

Intel Core i5-6267U 2.9 GHz (max Turbo Boost 3.3 GHz) with Intel® Iris™ Graphics 550 (28W)
Will be replaced by the:
Intel Core i5-7267U 3.1 GHz (max Turbo Boost 3.5 GHz) with Intel® Iris™ Plus Graphics 650 (28W)

Intel Core i5-6287U 3.1 GHz (max Turbo Boost 3.5 GHz) with Intel® Iris™ Graphics 550 (28W)
Will be replaced by the:
Intel Core i5-7287U 3.3 GHz (max Turbo Boost 3.7 GHz) with Intel® Iris™ Plus Graphics 650 (28W)

Intel Core i7-6567U 3.3 GHz (max Turbo Boost 3.6 GHz) with Intel® Iris™ Graphics 550 (28W)
Will be replaced by the:
Intel Core i7-7567U 3.5 GHz (max Turbo Boost 4.0 GHz) with Intel® Iris™ Plus Graphics 650 (28W)

MacBookPro13,3:

Intel Core i7-6700HQ 2.6 GHz (max Turbo Boost 3.5 GHz) with Intel® HD Graphics 530 (45W)
Will be replaced by the:
Intel Core i7-7700HQ 2.8 GHz (max Turbo Boost 3.8 GHz) with Intel® HD Graphics 630 (45W)

Intel Core i7-6820HQ 2.7 GHz (max Turbo Boost 3.6 GHz) with Intel® HD Graphics 530 (45W)
Will be replaced by the:
Intel Core i7-7820HQ 2.9 GHz (max Turbo Boost 3.9 GHz) with Intel® HD Graphics 630 (45W)

Intel Core i7-6920HQ 2.9 GHz (max Turbo Boost 3.8 GHz) with Intel® HD Graphics 530 (45W)
Will be replaced by the:
Intel Core i7-7920HQ 3.1 GHz (max Turbo Boost 4.1 GHz) with Intel® HD Graphics 630 (45W)

The upgrades will be available some time after the official release of macOS Sierra 10.12.4 at the soonest but I’d like to stress that I have no idea when exactly the new hardware will be released. It may even be in the summer. Who knows. Seriously. You should not wait for the new hardware. It can take months.

Edit: We already have two late 2016 models. One 13-inch MacBook Pro and a 15-inch MacBook Pro, and we will buy a second 13-inch MacBook Pro this weekend. We’re not going to wait for a Kaby Lake model. We need an extra one now. Not whenever Apple decides to upgrade the current models.

Update: I visited the AppleStore today and bought another 13-inch MacBook Pro (with function keys) like I said that I would do. Here is a picture of it on top of the box:

NVMe boot args and Dummy kext…

I totally forgot to blog about the nvme boot argument that I found in the 10.12 Beta kext seven months ago:

bit-0: (0x01) enable debug output (calls _kprintf)
bit-1: (0x02) enable self refresh
bit-2: (0x04) enable LBA extend
bit-3: (0x08) enable LPSR support during S3/S4
bit-4: (0x10) PCI only mode
bit-5: (0x20) ignore initialisation errors
bit-6: (0x40) enable enctryption support

Notes:

You may want to run debugMachKernel.sh for bit-0.
For bit-1 seting the “nvme-self-refresh” Number property is required.
For bit-3 seting the “nvme-LPSR-during-S3-S4” Number property is required.
For bit-4 this appears to be the default.

Apple hardware also support: enable-IO-log=1 but that won’t work on other hardware.

Next. I also found a NVRAM variable:

“4d1ede05-38c7-4a6a-9cc6-4bcca8b38c14:PRTCCounter”

Dummy Kext

I received a couple of questions about this and never got to answer it so let’s do that here. In short. Yes. I am using a dummy kext right now. Here’s what I did:

1.) I copied IONVMEfamily.kext to /S*/L*/E*/AppleNVMeFamily.kext
2.) I patched the binary with my patches only
3.) I changed the version info in the Info.plist from 2.1.0 to 9.9.9

The original vanilla IONVMeFamily.kext is still there in /System/Library/Extensions and all is fine. No issues whatsoever. With 1546 power cycles I can call this a rock solid proven method.

Apple NVMe SMART Monitor Under Control…

Apple isn’t sharing any information about their SMART API’s so I had to dig a little and this is the first result (spoiler alert) from my hack:


-----------------------------------------
Smart Log for NVME device...............: disk0
NamespaceID.............................: 1
Critical Warning........................: 0
Temperature.............................: 37 °Celsius
Available Spare.........................: 100%
Available Spare Threshold...............: 10%
Percentage Used.........................: 1%
Data Units Read.........................: 4,292,043,776,000 [4.29 TB]
Data Units Written......................: 2,145,884,672,000 [2.14 TB]
Host Read Commands......................: 151780827
Host Write Commands.....................: 50512740
Controller Busy Time....................: 248 minutes
Power Cycles............................: 1541
Power On Hours..........................: 1156 hours
Unsafe Shutdowns........................: 784
Media and Data Integrity Errors.........: 0
Number of Error Information Log Entries.: 34

Here is an older one from my MacBook Pro:

-----------------------------------------
Smart Log for NVME device...............: disk0
NamespaceID.............................: 1
Critical Warning........................: 0
Temperature.............................: 22 °Celsius
Available Spare.........................: 100%
Available Spare Threshold...............: 10%
Percentage Used.........................: 0%
Data Units Read.........................: 7086678
Data Units Written......................: 4943651
Host Read Commands......................: 11389069
Host Write Commands.....................: 7246825
Controller Busy Time....................: 44 minutes
Power Cycles............................: 431
Power On Hours..........................: 9 hours
Unsafe Shutdowns........................: 15
Media and Data Integrity Errors.........: 0
Number of Error Information Log Entries.: 0

The temperature on my MacBook Pro is lower. Only 22 °Celsius. I was also unpleasantly surprised by the fifteen ‘Unsafe Shutdowns’ on it. This has to be a driver issue. Never had a single freeze, lockdown or sudden reboot.

The high number of ‘Unsafe Shutdowns’ on the hack is easily explainable. As you know, I do a lot of testing and then things can go wrong. And they do go wrong with a couple of beta kernel drivers.

More to come…

Supported Mac models for Night Shift in Sierra 10.12.4

Night Shift was introduced in macOS Sierra 10.12.4 (Build 16E144f and Public Beta-1) and is controlled by the CoreBrightness.framework and you’ll need at least one of the following – or later – Mac models:

MacBookPro9,x
iMac13,x
Macmini6,x
MacBookAir5,x
MacPro6,x
MacBook8,x

Apple did not release any information about this. Not just yet, but I know this because I located the checks for it in said framework, and there it checks for matching Mac model names:

MacBookPro
iMac
Macmini
MacBookAir
MacPro
MacBook

Night Shift is however not supported – by Apple – on older Mac models. No. There are checks for minimum requirements, which I looked up with help of:

nm /S*/L*/PrivateFrameworks/CoreBrightness.framework/CoreBrightness|grep _ModelMinVersion

000000000001d490 S _ModelMinVersion

Ok. Now we know the offset. Time to dump the data with help of:

xxd -s 0x1D490 -l 24 /S*/L*/PrivateFrameworks/CoreBrightness.framework/CoreBrightness

0001d490: 0900 0000 0d00 0000 0600 0000 0500 0000
0001d4a0: 0600 0000 0800 0000

MacBookPro9,x
iMac13,x
Macmini6,x
MacBookAir5,x
MacPro6,x
MacBook8,x

Now you know how I did it, and in case you happen to own a Mac model that isn’t supported, yet, then you could try to patch the matching value in CoreBrightness.framework as some readers confirmed that it is working for them with older/unsupported hardware. The colors that I used should help you to find the byte that you need to change.

Anyway. This my friends is how it is done. Have fun now.

Edit: The order of the MacBook Pro and iMac was wrong – see comments. Fixed thanks to the heads up from Thomas and Nicolinux.

Update: You need to re-sign the patched framework binary with:
sudo codesign -f -s - /S*/L*/PrivateFrameworks/CoreBrightness.framework/Versions/Current/CoreBrightness

Note: You may only use this patch in your script/software/app if the source code is available, preferable on Github, you are not asking for donations, and clearly state that this is my work. Thank you.

Apple IGPU saved-config data

I own two new Mac Book Pro’s. One IGPU only (MacBookPro13,1) and one with a Radeon Pro 460 with 4GB (MacBookPro13,3). Both of them use device-properties to inject saved-config. The injected data is related to the display hardware and I like to find out what that data is and where that it is used. Let’s start with a grep:

grep -r saved-config /System/Library/Extensions

Here is the output:

AMDFramebuffer.kext
AMDSupport.kext
AppleIntelBDWGraphicsFramebuffer.kext
AppleIntelFramebufferAzul.kext
AppleIntelFramebufferCapri.kext
AppleIntelHDGraphicsFB.kext
AppleIntelSKLGraphicsFramebuffer.kext
AppleIntelSNBGraphicsFB.kext
NVDAResman.kext
NVDAResmanTesla.kext
NVDAResmanWeb.kext

This basically tells us the names of the kexts that are using the data, but now we have to find out what the data is. Here is the data that gets injected on the MacBookPro13,3:

47 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 00 06 00 1b 19 00 6c 05
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 01 01 01 00 06 10 30 a0 02
03 40 00 00 00 00 00 00 00 00 02 c0 eb 9a 13 40 0b 08 07 50 00 00 00 34 00 00 00
08 00 20 00 26 00 08 00 20 0d 34 08 69 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00

And here the data that is injected on the MacBookPro13,1

47 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 00 02 00 26 19 00 6c 05
69 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 01 01 01 00 06 10 34 a0 02
03 40 00 00 00 00 00 00 00 00 02 90 6c 8a 0f 00 0a 40 06 50 00 00 00 2e 00 00 00
08 00 20 00 20 00 08 00 40 0b 08 07 5a 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00

I could not find anything, not a single Apple document nor source code/header file that explains it, but I may have missed it. In which case I would love to hear from you.

Ok. So assuming that there is no documentation, we have to dig into other resources to get an idea what it may be. And this is what I figured out so far:

47 00 00 00 (unknown)

00 00 00 00 (_reservedA[10])
00 00 00 00
00 00 00 00

00 00 03 00 (version?)

06 00 1b 19 (AAPL,ig-platform-id)

00 (unknown)

6c 05 (BCL frequency/maximum?)

00 00 (BCL frequency/minimum)

00 00 (unknown)

00 00 00 00 (_reservedB[10])
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00

01 01 01 01 (standard timing related info?)

00 (unknown)

06 10 (DisplayVendor)

30 a0 (DisplayProductID)

02 03 40 00 00 00 00 00 00 00 00 02 (unknown)

c0 eb 9a 13 (IOFBCurrentPixelClock)

40 0b (horizontalActive = 2880 pixels)

08 07 (verticalActive = 1800 pixels)

50 00 (horizontalBlanking in pixels)

00 (horizontalBorderLeft in pixels)

00 (horizontalBorderRight in pixels)

34 00 (verticalBlanking in pixels)

00 (verticalBorderTop in pixels)

00 (verticalBorderBottom in pixels)

08 00 (horizontalSyncOffset in pixels)

20 00 (horizontalSyncPulseWidth/Sync Width)

26 00 (verticalSyncOffset in pixels)

08 00 (verticalSyncPulseWidth/Sync Width)

20 0d (horizontalScaled = 3360)

34 08 (verticalScaled = 2100)

69 00 (bytes per row == ( (horizontalActive * depth) >> 3) )

00 00 00 00 (_reservedC[25])
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00

Mostly basic stuff. Things that you could have come up yourself, but since I like to document things, and let other people confirm my findings.

Edit: I changed the border info. It’s now broken up into two horizontal and vertical border settings. I also figured out the unknown value at the bottom (row bytes).

The red unknown values are my next targets and I think that one of them is used for screen rotation. This is something I will test later today on my MacBook Pro.

Ok. Let me add the EDID data that gets injected:

00 ff ff ff ff ff ff 00 06 10 30 a0 00 00 00 00 26 19 01 04 b5 21 15 78 02 0f 55
ae 52 43 b0 26 0d 4f 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
7c 80 40 50 b0 08 34 70 08 20 68 08 4b cf 10 00 00 1a 00 00 00 10 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 fc 00 43 6f 6c 6f 72 20 4c 43 44 0a 20 20 20
00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fe

And here the EDID data from the MacBookPro13,1

00 ff ff ff ff ff ff 00 06 10 34 a0 00 00 00 00 25 19 01 04 b5 1d 12 78 02 0f 41
ae 52 43 b0 26 0e 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
d9 65 00 50 a0 40 2e 60 08 20 08 08 1e b3 10 00 00 1a 7c 80 40 50 b0 08 34 70 08
20 68 08 1e b3 10 00 00 1a 00 00 00 fc 00 43 6f 6c 6f 72 20 4c 43 44 0a 20 20 20
00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3e

I also used SwitchResX to dump the EDID and one particular part of that output is this:

EDID Detailed mode

Clock 328.920 MHz, 331 mm x 207 mm
2880 2888 2920 2960 hborder 0
1800 1838 1846 1852 vborder 0
+hsync -vsync

I also used DarwinDumper and this is what I got:

Mode = 2880 x 1800 @ 60.001Hz
Pixel Clock............. 328.92 MHz Non-Interlaced

Horizontal Vertical
Active.................. 2880 pixels 1800 lines
Front Porch............. 8 pixels 38 lines
Sync Width.............. 32 pixels 8 lines
Back Porch.............. 40 pixels 6 lines
Blanking................ 80 pixels 52 lines
Total................... 2960 pixels 1852 lines
Scan Rate............... 111.122 kHz 60.001 Hz

Image Size.............. 331 mm 207 mm
Border.................. 0 pixels 0 lines

Sync: Digital separate with
* Negative vertical polarity
* Positive horizontal polarity

The above data is the technical description of the 15-inch display panel. And I used it, along with the saved-config data, to get this:

First column

2880 = horizontalActive
1800 = verticalActive

Second column

2880 = 2880 (horizontalActive) + 8 (horizontalSyncOffset)
1838 = 1800 (verticalActive) + 0x26/38 (verticalSyncOffset)

Third column

2920 = 2880 (horizontalActive) + 8 (horizontalSyncOffset) + 0x20/32 (horizontalSyncPulseWidth)
1846 = 1800 (verticalActive) + 0x26/38 (verticalSyncOffset) + 8 (verticalSyncPulseWidth)

Fourth column

2960 = 2880 (horizontalActive) + 0x50/80 (horizontalBlanking)
1852 = 1800 (verticalActive) + 0x34/52 (verticalBlanking)

Most of it can be extracted from IODisplayEDID, but I like to see it confirmed by others first. There is also unknown data. I have no idea, yet, what it may be. For example: 69 00 is 5a 00 on my MacBookPro13,1 and I have no idea what it is or how to get this value for my external monitor.

Injecting the wrong data is not what we want. I tried that and it failed to boot. The monitor of my hack went nuts, so the data obviously did something.

In short. We need a script or app that does most, if not all, of the work for us. We can use struct IODetailedTimingInformationV2 from IOGraphicsTypes.h to get (most of the) data. After that we can try to figure out what it does or if it helps us. Now the question is; who here is interested in this, and who can write that script and/or app?

Note: Some people may say that we don’t need it. Sure. We have been booting OS X for many years without this data. True. But now answer this question: Why does Apple inject the device-properties, when they don’t need it?

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