RehabMan
Moderator
- Joined
- May 2, 2012
- Messages
- 181,058
- Motherboard
- Intel DH67BL
- CPU
- i7-2600K
- Graphics
- HD 3000
- Mac
- Mobile Phone
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, 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.
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 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):
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.
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, 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.
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 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):
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.
Last edited:
