Contribute
Register

[Guide] Alternative to the minStolenSize patch with 32mb DVMT-prealloc

Good evening mr Rehabman!

I installed 12.6 and I'm trying to get rid of the FakeID values. Tried booting with GFX=0x59168086 and ig-platform-id 0x59160000. I'm on 620 hardware.

I also disabled the SKL Framebuffer patch, since I'd be running KBLFramebuffer and not SKL.. and had my doubts it would boot. It didn't.

Which means I need a new patch targeting the KBLFramebuffer am I right? Or have I specified the wrong values? The guide in Graphics section mentions 5912 and not 5916 but since I'm on 620 and not 630 I thought these values were correct..

I tried simply renaming the patch to target AppleIntelKBLFramebuffer. Hoping the values from SKL would be consistent.. seems they aren't. I can boot with invalid platform-id but whenever I try 0x59160000 after rebuilt kextcache I get a KP.

I will publish a new patch for KBL later.

Ok. The problem:

AppleIntelKBLGraphicsFramebuffer:

00001659 00000000 5E900800 00000000 01030303 00002002 00000000 00000060


Edit: I applied modified patch
com.apple.driver.AppleIntelKBLGraphicsFramebuffer

Find:
01030303 00002002 00000000
Replace:
01030303 00003001 00009000

Booting with full acceleration on 7200U HD Graphics 620 on macOS 10.12.6! IntelGFX = 0x59168086, ig-platform-id 0x59160000.

My hack now has the highest MacBook Air score on Geekbench and is almost on par with the 13 inch MacBook Pro (Late 2016) :mrgreen: Single core score 4000+, multi core 8000+ vs generally 4200/8200. The only downside is OpenCL score 19000+, where the real 2016 Macs score around 30000 with their HD Graphics 550. Oh well...

Interesting... the zeros could have been a fixup, which would have made it difficult to patch.
In that case, the 00000000 must mean "automatic", and we can force it as required.

I'll need to confirm before adding any info to post #1.

Note that I wrote about KBL DVMT "patchability" here: http://www.insanelymac.com/forum/topic/324194-pre-release-macos-high-sierra/page-48#entry2447504
 
I will publish a new patch for KBL later.



Interesting... the zeros could have been a fixup, which would have made it difficult to patch.
In that case, the 00000000 must mean "automatic", and we can force it as required.

I'll need to confirm before adding any info to post #1.

Note that I wrote about KBL DVMT "patchability" here: http://www.insanelymac.com/forum/topic/324194-pre-release-macos-high-sierra/page-48#entry2447504

I saw what you wrote about similar values with zeros for SKL platform-ids and that they were "probably not patchable".
But I thought Let's try and see..
For this platform-id it seems it paid off, but I cannot really tell if it's unstable or fully working. I know it's booting and About this mac and System report looks fine. I tried QE/CI by running a screen saver.

Im glad if I contributed with something small at least, after all the help I got from you.
 
I just tried something out, I saw what you wrote about similar values with zeroes for SKL and that they were "probably not patchable". but I thought Lets try it out.
For this platform-id it seems it paid off, but I cannot really tell if it's unstable or fully working. I know it's booting and About this mac and system report looks fine but thats it.

Im glad if I contributed with something small at least, after all the help I got from you.

Yeah... the zeros could be real or a placeholder for fixup. I don't understand enough about the binaries/loader to tell the difference.

You would probably know if the patch was not successfully applied.
And you can check if the patch is applied by turning on Debug=true in KernelAndKextPatches.
 
Yeah... the zeros could be real or a placeholder for fixup. I don't understand enough about the binaries/loader to tell the difference.

You would probably know if the patch was not successfully applied.
And you can check if the patch is applied by turning on Debug=true in KernelAndKextPatches.
Would it not be weird if they were real, since some of the SKL platform ids were made up of zeros only? How can that work?

Maybe zeros are placeholders, but it doesn't mean they _have to_ be placeholders...

Hey do you think that has got anything to do with theAMD black screen issue when disabling iGPU? The amd framebuffer consists of zeros and in native macs they get replaced properly but in hacks they dont.. or something similar. Maybe they have to be manually patched like here.
 
I will publish a new patch for KBL later.



Interesting... the zeros could have been a fixup, which would have made it difficult to patch.
In that case, the 00000000 must mean "automatic", and we can force it as required.

I'll need to confirm before adding any info to post #1.

Note that I wrote about KBL DVMT "patchability" here: http://www.insanelymac.com/forum/topic/324194-pre-release-macos-high-sierra/page-48#entry2447504
I have a ACL3236 sound card and no external display device. DVMT for me, there is no need to drive
 
Would it not be weird if they were real, since some of the SKL platform ids were made up of zeros only? How can that work?

Maybe zeros are placeholders, but it doesn't mean they _have to_ be placeholders...

Without source code we can only test and then make conclusions.

Hey do you think that has got anything to do with theAMD black screen issue when disabling iGPU? The amd framebuffer consists of zeros and in native macs they get replaced properly but in hacks they dont.. or something similar. Maybe they have to be manually patched like here.

Off-topic.
This topic is for Intel graphics only.
 
Without source code we can only test and then make conclusions.



Off-topic.
This topic is for Intel graphics only.

I have DVMT - prealloc 32 mb. Trying to patch AppleIntelSKLGraphicsFrameBuffer kext. El Capitan 10.11.6 Data:

0x19260004: FACTORY_PLATFORM_INFO="0:
0400 2619 0000 0000 8049 0500 0000 0000
0103 0303 0000 0004 0000 2002 0000 0000
0000 0060 6c05 0000 6c05 0000 0000 0000
0000 0000 0000 0000 0000 0800 0200 0000
9800 0000 0105 0900 0004 0000 c701 0000
Can you tell me what bytes I should patch and how 'Find' and 'Replace' should be?
Thanks
 
I have DVMT - prealloc 32 mb. Trying to patch AppleIntelSKLGraphicsFrameBuffer kext. El Capitan 10.11.6 Data:

0x19260004: FACTORY_PLATFORM_INFO="0:
0400 2619 0000 0000 8049 0500 0000 0000
0103 0303 0000 0004 0000 2002 0000 0000
0000 0060 6c05 0000 6c05 0000 0000 0000
0000 0000 0000 0000 0000 0800 0200 0000
9800 0000 0105 0900 0004 0000 c701 0000
Can you tell me what bytes I should patch and how 'Find' and 'Replace' should be?
Thanks

0x19260004 is probably not a good choice.
But you can see the DVMT-prealloc size/framebuffer size/cursor bytes size:

0000 0004 0000 2002 0000 0000

Note that cursor bytes is zero, so it is either automatically determined or a fixup.
 
If cursor bytes is zero mb, should I consider framebuffer memory size to be <= 32 mb?
 
Back
Top