Overview
A common problem with Broadwell/Skylake/KabyLake is relatively small DVMT-prealloc setting by PC OEMs. The Apple framebuffer kexts generally assume 64mb or larger, and most PC OEMs use only 32mb. And often, there is no way to change it easily due to limited BIOS, locked down BIOS, etc.
Note: For more information regarding changing DVMT-prealloc, see FAQ.
https://www.tonymacx86.com/threads/faq-read-first-laptop-frequent-questions.164990/
And some of the techniques to change DVMT-prealloc, even if possible, can be dangerous and you may not want to risk it.
There is the minStolenSize patch, which can disable the check for adequate DVMT-prealloc, but that patch is likely to cause instability, glitches, or other strange behavior. There is likely good reason for the assertion in the framebuffer code.
Fortunately, it is possible to patch the framebuffer to fit within the 32mb DVMT-prealloc.
Details, Broadwell example
Of course, patching the framebuffer for an alternate DVMT-prealloc is a bit more involved than using the minStolenSize patch because the patch is specific both to the ig-platform-id you're using.
Let's take a look at the framebuffer data for a commonly used ig-platform-id on Broadwell, 0x19260006:
06002616 01030303
00002002 00005001
The 06002616 is just 0x19260006 byte reversed.
The 01030303 has to do with port and pipe counts.
The next two 32-bit items are the framebuffer memory size and the cursor bytes size.
The sum of those two items must be less (or equal) than the DVMT-prealloc setting.
So, 0x02200000 is 34MB, and 0x01500000 is 21MB. The sum is 55MB. So, clearly it is not going to work with a DVMT-prealloc of 32MB.
We can change these values so only 32MB (actually a bit less) is required. For example, we know that on Haswell AppleIntelFramebufferAzul and ig-platform-id 0x0a260006 only require 32MB.
The AppleIntelFramebufferAzul kext has this in the header for 0xa260006:
0600260A 01030303 00000002
00003001 00006000
Byte reversing the values, we get 0x02000000 (32MB) for DVMT-prealloc requirement, 0x01300000 (19MB) for framebuffer size, and 0x00060000 (6MB) for cursor bytes. Of course we usually patch the 6MB to 9MB, otherwise there are glitches.
So... a patch for Broadwell 0x16260006:
Comment: 0x16260006, 32MB BIOS, 19MB framebuffer, 9MB cursor bytes (credit RehabMan)
Name: AppleIntelBDWGraphicsFramebuffer
Find: 06002616 01030303 00002002 00005001
Replace: 06002616 01030303 00003001 00009000
The above patch results in ig-platform data that requires only 28MB.
You could also shorten the Find/Replace data such that it applies to more ig-platform-id values (see discussion regarding Skylake below for more infomation).
For example, this patch:
Comment: 0x16260006/etc, 32MB BIOS, 19MB framebuffer, 9MB cursor bytes (credit RehabMan)
Name: AppleIntelBDWGraphicsFramebuffer
Find: 01030303 00002002 00005001
Replace: 01030303 00003001 00009000
... would apply to the following: 0x19160002, 0x16160002, 0x16260002, 0x16220002, 0x162b0002, 0x16260005, 0x16260006.
Details, Skylake example
Let's take a look at another common ig-platform-id used on Skylake, 0x19160000
Note: I'm only looking at 10.12.4 here, 10.11.6 is slightly different... similar to Broadwell (as the kext has a DVMT-prealloc specification in the framebuffer).
The header data for 0x19160000:
00001619 00000000 54880800 00000000 01030303
00002002 00005001
Again, we have the same 34+21=55MB as on the Broadwell example. We need to trim it down to fit into 32MB.
And again, we can use the known good Haswell data:
Comment: 0x19160000/etc, 19MB framebuffer 9MB cursor bytes (credit RehabMan)
Name: AppleIntelSKLGraphicsFramebuffer
Find: 01030303 00002002 00005001
Replace: 01030303 00003001 00009000
Note that the Find/Replace does not include the ig-platform-id itself (and the other bytes that follow it). It cannot be used since the zeros in the data are actually placeholders (fixups), which will change when the kext is linked into kernel cache. But using the data starting with the 01030303 (port/pipe count data) is unique enough.
A result of not being able to specify the ig-platform-id in the patch data is that the patch applies to more than 0x19160000. For example, the patch above applies to ig-platform-id values 0x191e0000, 0x19160000, 0x19260000, 0x19270000, 0x191b0000, 0x193b0000, 0x19120000. Other ig-platform-ids would require different patch data that matches the data found in the kext.
Activating the patch
Just like with the minStolenSize patch, Clover can only patch a kext that is in kernel cache.
So... the activation procedure remains the same:
- make sure the correct patch is entered in your config.plist
- make sure the patch matches your ig-platform-id
- boot with invalid ig-platform-id
- rebuild cache
- boot with intended/valid ig-platform-id
Applicable ig-platform-id values
Below is a list of patchable ig-platform-id values and their memory data.
In AppleIntelBDWGraphicsFramebuffer:
00000616 00030303 00000001 0000f000
00000e16 00030303 00000001 0000f000
00001616 00030303 00000001 0000f000
00001e16 00030303 00000001 0000f000
00002616 00030303 00000001 0000f000
00002b16 00030303 00000001 0000f000
00002216 00030303 00000001 0000f000
01000e16 01030303 00006002 00005001
01001e16 01030303 00006002 00005001
02000616 01030303 00002002 00005001
02001616 01030303 00002002 00005001
02002616 01030303 00002002 00005001
02002216 01030303 00002002 00005001
02002b16 01030303 00002002 00005001
03001216 01030403 00002002 00005001
04002b16 00030303 00002002 00005001
04002616 00030303 00002002 00005001
07002216 00030303 00006002 00006002
05002616 01030303 00002002 00005001
06002616 01030303 00002002 00005001
08002b16 00020202 00002002 00002002
08002616 00020202 00002002 00002002
Not all ig-platform-id data can be patched this way. There are certain ig-platform data that uses fixups or dynamically adjusted memory values, but that is the case currently only in the AppleIntelSKLGraphicsFramebuffer code (all ig-platform-id values are patchable in AppleIntelBDWGraphicsFramebuffer).
In AppleIntelSKLGraphicsFramebuffer:
00001e19 ... 01030303 00002002 00005001
00001619 ... 01030303 00002002 00005001
00002619 ... 01030303 00002002 00005001
00002719 ... 01030303 00002002 00005001
00001b19 ... 01030303 00002002 00005001
00003b19 ... 01030303 00002002 00005001
00001219 ... 01030303 00002002 00005001
01000219 ... 00000000 00000000 00000000 (not patchable)
01001719 ... 00000000 00000000 00000000 (not patchable)
01001219 ... 00000000 00000000 00000000 (not patchable)
01003219 ... 00000000 00000000 00000000 (not patchable)
02001619 ... 01030303 00009003 00000000 (probably not patchable)
02002619 ... 01030303 00009003 00000000 (probably not patchable)
03001e19 ... 01030303 00008002 00000000 (probably not patchable)
04002619 ... 01030303 00002002 00000000 (probably not patchable)
04002719 ... 01030303 00009003 00000000 (probably not patchable)
05003b19 ... 01030404 00002002 00000000 (probably not patchable)
06001b19 ... 01010101 00006002 00000000 (probably not patchable)
07002619 ... 01030303 00002002 00000000 (probably not patchable)
Conclusion
There is no need to use the minStolenSize patch or change DVMT-prealloc... Instead, you can patch the framebuffer to match your BIOS configuration for DVMT-prealloc.
Patching the framebuffer to match your BIOS setting for DVMT-prealloc is likely to be more stable than the minStolenSize patch and with limited BIOS options, comes with less risk than changing DVMT-prealloc.