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, 0x16260006:
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 (in WhateverGreen, these are referred to as framebuffer-stolenmem, and framebuffer-fbmem).
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 0x00600000 (6MB) for cursor bytes. Of course we usually patch the 6MB to 9MB, otherwise there are glitches.
The above KextsToPatch 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.
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.
These patches are much easier and more reliable (and less likely to stop working) using WhateverGreen.kext:
framebuffer-patch-enable=1
framebuffer-stolenmem=<00003001>
framebuffer-fbmem=<00009000>
Or, as it would look in Xcode (this example taken from guide plist config_HD615_620_630_640_650.plist):
32mb DVMT whatevergreen.png
Read here for more information on WhateverGreen.kext: https://www.tonymacx86.com/threads/guide-intel-framebuffer-patching-using-whatevergreen.256490/
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.
楼主: linliufang
