Contribute
Register

Cannot get UHD 630 acceleration to work

Status
Not open for further replies.
Reproducible.

.kext list:
Code:
ACPIBatteryManager.kext     FakeSMC.kext
AppleALC.kext             Lilu.kext
BrcmFirmwareRepo.kext        USBInjectAll.kext
BrcmPatchRAM2.kext        VoodooPS2Controller.kext
FakePCIID.kext            WhateverGreen.kext
FakePCIID_Broadcom_WiFi.kext

-igfxdump doesn't produce output when an invalid ig-platform-id is used, and produces garbage output (unreadable by FBPatcher) when a non-functional one is used, but I've attached the framebuffer dump just in case.

For the record, I've tried these ig-platform-ids:
Code:
0x3E920009
0x3E9B0009
0x3E920000
0x3E9B0000 (from config repo)
0x3E9B0006
0x3E9B0007

0x3E9B0007 was notable in that all the others caused an instant restart after gIOScreenLockState while it managed to initialize something, dumping me at a black screen.

edit: DVMT is set to default 32MB preallocated, no BIOS option
 

Attachments

  • gen_debug.zip
    1.8 MB · Views: 65
  • AppleIntelFramebuffer_10_18.0.zip
    831.2 KB · Views: 64
Last edited:
Reproducible.

.kext list:
Code:
ACPIBatteryManager.kext     FakeSMC.kext
AppleALC.kext             Lilu.kext
BrcmFirmwareRepo.kext        USBInjectAll.kext
BrcmPatchRAM2.kext        VoodooPS2Controller.kext
FakePCIID.kext            WhateverGreen.kext
FakePCIID_Broadcom_WiFi.kext

-igfxdump doesn't produce output when an invalid ig-platform-id is used, and produces garbage output (unreadable by FBPatcher) when a non-functional one is used, but I've attached the framebuffer dump just in case.

For the record, I've tried these ig-platform-ids:
Code:
0x3E920009
0x3E9B0009
0x3E920000
0x3E9B0000 (from config repo)
0x3E9B0006
0x3E9B0007

0x3E9B0007 was notable in that all the others caused an instant restart after gIOScreenLockState while it managed to initialize something, dumping me at a black screen.
I think you will be better off using WhateverGreen.kext (requires removal of IntelGraphicsFixup.kext, CoreDisplayFixup.kext, IntelDMVTFixup.kext).
And then use rehabMan’s beta config.plist, follow this guide till the point you've cloned both the branches and change to beta branches for both.
Then copy config_UHD630.plist from guide.git to your EFI/CLOVER and make sure you have the latest whatevergreen+lilu (both debug versions).
This fixed acceleration for me.
 
I think you will be better off using WhateverGreen.kext (requires removal of IntelGraphicsFixup.kext, CoreDisplayFixup.kext, IntelDMVTFixup.kext).
And then use rehabMan’s beta config.plist, follow this guide till the point you've cloned both the branches and change to beta branches for both.
Then copy config_UHD630.plist from guide.git to your EFI/CLOVER and make sure you have the latest whatevergreen+lilu (both debug versions).
This fixed acceleration for me.
I'm using the latest debug versions of both Lilu (1.2.7) and WhateverGreen (1.2.3) and I'm using the latest commit on config_UHD630.plist (beta branch was merged into master).
 
Reproducible.

.kext list:
Code:
ACPIBatteryManager.kext     FakeSMC.kext
AppleALC.kext             Lilu.kext
BrcmFirmwareRepo.kext        USBInjectAll.kext
BrcmPatchRAM2.kext        VoodooPS2Controller.kext
FakePCIID.kext            WhateverGreen.kext
FakePCIID_Broadcom_WiFi.kext

-igfxdump doesn't produce output when an invalid ig-platform-id is used, and produces garbage output (unreadable by FBPatcher) when a non-functional one is used, but I've attached the framebuffer dump just in case.

For the record, I've tried these ig-platform-ids:
Code:
0x3E920009
0x3E9B0009
0x3E920000
0x3E9B0000 (from config repo)
0x3E9B0006
0x3E9B0007

0x3E9B0007 was notable in that all the others caused an instant restart after gIOScreenLockState while it managed to initialize something, dumping me at a black screen.

edit: DVMT is set to default 32MB preallocated, no BIOS option

You might want to experiment with different values in the 32mb DVMT-patch (eg. different stolenmem, cursormem).
There is some reports of success with 0x3e9b0000, so maybe stick with that but different stolen/cursor (still to fit in 32mb). I think most of the success with 0x3e9b0000 is with systems that can set DVMT-prealloc=64mb. And that's another thing to check into (changing your DVMT-prealloc).
You could also try with the minStolenSize patch (although not likely stable, it is worth a try to help isolate the issue).
 
@mateoeh @OrionDB5 I noticed you guys also have 9570s. Have you been able to a shell with setup_var to see/change DVMT-prealloc?
It seems I'm not alone in only getting a single underscore (not even blinking) when trying to boot to the GRUB shell.
 
You might want to experiment with different values in the 32mb DVMT-patch (eg. different stolenmem, cursormem).
There is some reports of success with 0x3e9b0000, so maybe stick with that but different stolen/cursor (still to fit in 32mb). I think most of the success with 0x3e9b0000 is with systems that can set DVMT-prealloc=64mb. And that's another thing to check into (changing your DVMT-prealloc).
You could also try with the minStolenSize patch (although not likely stable, it is worth a try to help isolate the issue).

As it turns out, according to the system information in my BIOS settings, DVMT is actually set to 64MB by default. I tried various values for stolen/cursormem, including disabling framebuffer patching altogether, and they all produced the same result, a crash after `gIOScreenLockState` (except for very low values <16MB-ish which just panicked).


IMG_0356.JPG

@mateoeh @OrionDB5 I noticed you guys also have 9570s. Have you been able to a shell with setup_var to see/change DVMT-prealloc?
It seems I'm not alone in only getting a single underscore (not even blinking) when trying to boot to the GRUB shell.

I think tianocore's EDK shell + this binary (AmiSetupWriter.efi) or editing the `Setup` var with efivar in Linux would work, but if the BIOS system information is accurate there's no point.
 
As it turns out, according to the system information in my BIOS settings, DVMT is actually set to 64MB by default. I tried various values for stolen/cursormem, including disabling framebuffer patching altogether, and they all produced the same result, a crash after `gIOScreenLockState` (except for very low values <16MB-ish which just panicked).

You might try without WhateverGreen.kext. There are few reports of WhateverGreen causing problems with CFL, and to some extent with 64mb DVMT-prealloc, you don't need it (maybe even WhateverGreen is patching things that don't need patching with CFL).

Also, I've been looking at WhateverGreen code... trying to implement a new feature, and here's a few things I found out:
- the -igfxdump attempts to dump the entire framebuffer kext from memory (after init), not just the platform table
- if you use an invalid ig-platform-id, although the framebuffer will load, the -igfxdump has no effect
- no patching of the platform table is performed with an invalid ig-platform-id
- it makes it a bit of a challenge to get a list of ig-platform-id values if you can't boot the system with a valid ig-platform-id
- even with a valid ig-platform-id (such as the system I'm writing this message on, my u430), -igfxdump creates just a zero byte file in the root (useless)
- clearly, -igfxdump is bugged
- WhateverGreen has very limited support for patching when spoofing is in play (only CFL as KBL)
- if you spoof anything else (eg. CFL as KBL, KBL as SKL), WhateverGreen-based patching properties have no effect
- it does not hook all the graphics kexts/all framebuffers... it hooks only certain kexts based on CPU architecture

I have a version locally here that can dump the platform data to ioreg. It dumps both before and after patching, and can dump when an invalid ig-platform-id is used, so it is relatively useful for getting platform id dumps. By using a (valid) fake device-id and invalid ig-platform-id, you can get platform list dumps for any framebuffer, no matter the hardware you have.

I will be submitting a pull request on github for that one for sure.
 
@mateoeh @OrionDB5 I noticed you guys also have 9570s. Have you been able to a shell with setup_var to see/change DVMT-prealloc?
It seems I'm not alone in only getting a single underscore (not even blinking) when trying to boot to the GRUB shell.
I haven't tried changing DVMT as the BIOS says it is already set at 64MB and I have a 1080p screen so I don't think it is necessary for me to have 128MB DVMT (and I don't think it is possible anyway on the 9570)
 
Status
Not open for further replies.
Back
Top