ThinkPad P50 UHD Graphical Acceleration Issues

[RehabMan]

Use of the word "or" in your FAQ doesn't create any sense of specificity it simply sounds like a option rather than a requirement. Don't blame the reader for what could equally be the fault of the writer. I appreciate the help, but there's still a person on this side, attacking my reading skills isn't why I came here for. I'm not typing broken English, giving incomplete datasets, begging, or any non-sense.

The /L/E example is shown *first* as it applies to current versions of macOS/OS X. The word "Or" is followed by "with older OS X (10.10.x and prior)". Seems crystal clear that kexts to go /L/E for anything 10.11.x and newer, /S/L/E for older than that. I don't know how you could read it any differently.

It is easy to install kexts with Terminal:

sudo cp -R KextToInstall.kext /Library/Extensions

Or with older OS X (10.10.x and prior):

sudo cp -R KextToInstall.kext /System/Library/Extensions

Regardless, no change. New data set included.

The ioreg you attached shows the internal display is detected (framebuffer@0)
(so you might want to clarify the problem you're seeing)

But you haven't implemented backlight control.
See guide:
https://www.tonymacx86.com/threads/...rol-using-applebacklightinjector-kext.218222/

You should also make sure you enabled legacy boot/CSM in BIOS.

You may need to use a different ig-platform-id. There are many... to discover all:
Install Hex Fiend.
In Terminal:

open -a "Hex Fiend" /System/Library/Extensions/AppleIntelSKLGraphicsFramebuffer.kext/Contents/MacOS/AppleIntelSKLGraphicsFramebuffer

In Hex Fiend, search for a known ig-platform-id, for example, 0x19120000 is hex search for '00 00 12 19'
Each ig-platform-id is 184 bytes (in this kext and KBL).
It helps to expand the Hex Fiend window to 23 columns (need a big screen, 184/4/2=23), because then you can see each ig-platform-id lined up vertically (every other row).
You will find the table starts with 0x191e0000 and the last is 0x19260007. The 0xFFFFFFFF signifies the end of table.

You're currently using 0x19160000, but certainly 0x191b0000 is an obvious choice for IGPU device-id 0x191b.

Also, your post #1 seems to imply your DVMT-prealloc is 64mb. If true, you should remove the 32MB DVMT-prealloc patch.

Your drivers64UEFI is not per guide. The guide reccomends AptioMemoryFix.efi (without EmuVaraibleUefi-64.efi) or OsxAptioFixDrv-64.efi (not OsxAptioFix2Drv-64.efi) with EmuVariableUefi-64.efi.

You should also check that you have the latest CoreDisplayFixup.kext.

Changing the resolution of the internal display might also help (use RDM from the menubar via remote desktop connection).

 

[MarieKirya]

The ioreg you attached shows the internal display is detected (framebuffer@0)
(so you might want to clarify the problem you're seeing)

Sure thing, the machine looks like this when I report that the screen does not update when it should. Artifacting appears after using the computer over VNC for a bit.

But you haven't implemented backlight control.
See guide:
https://www.tonymacx86.com/threads/...rol-using-applebacklightinjector-kext.218222/

Should I worry about my backlight before the display is working? I'll surely follow that guide after. I can do so now if you think it's a useful debugging step.

You should also make sure you enabled legacy boot/CSM in BIOS.

Ok, all tests in this posts were performed with CSM enabled. Legacy boot available. Clover booted still via UEFI, let me know if I misinterpreted that.

Also, your post #1 seems to imply your DVMT-prealloc is 64mb. If true, you should remove the 32MB DVMT-prealloc patch.

Tackling this a bit out of order, but system doesn't boot without this patch, so the UEFI disassembly may have been misleading, or some other setting in the UEFI directly affects this setting and it's no longer in it's default value. I wish Lenovo didn't lock down the UEFI of a flagship tier workstation laptop.

You may need to use a different ig-platform-id. There are many... to discover all:

Wew, this part took a while, but I did go through all the device IDs in _gPlatformInformationList that you mentioned.

191E0000 - Checked - Internal Screen Doesn't Update
19160000 - Checked - Internal Screen Doesn't Update
19260000 - Checked - Internal Screen Doesn't Update
19270000 - Checked - Internal Screen Doesn't Update
191B0000 - Checked - Internal Screen Doesn't Update
193B0000 - Checked - Internal Screen Doesn't Update
19120000 - Checked - Internal Screen Goes Black
19020001 - Checked - Kernel Panics
19170001 - Checked - Kernel Panics with a 95% of the screen consumed by glitching/artifacting
19160002 - Checked - Kernel Panics
19260002 - Checked - Kernel Panics
191E0003 - Checked - Kernel Panics
19260004 - Checked - Kernel Panics
19270004 - Checked - Kernel Panics
193B0005 - Checked - Kernel Panics
191B0006 - Checked - Kernel Panics
19260007 - Checked - Kernel Panics

Internal Screen Doesn't Update looks like the picture attached above. The kernel panics were no surprise so I went ahead and created more patches for _gPlatformInformationList. The patches simply are a extension of one already in use for the 32MB DVMT-prealloc patch, but modified to work with 19160002 and onwards. 19020001 and 19170001 were strange because they had 0's where the patched data usually go, I guess I could have patched those too. Possibly may try that tomorrow. Regardless after apply the new patches I got different results from 19160002 and onwards.

19160002 - Checked - Internal Screen Doesn't Update
19260002 - Checked - Internal Screen Doesn't Update
191E0003 - Checked - Internal Screen Goes Black however when VNCed into the Display is actually detected as attached unlike before when it would show up as Virtual Display in SwitchResX. Changing the resolution does not bring display, but it did dim the screen as though it was actually doing something. RDM did the same.
19260004 - Checked - Internal Screen Doesn't Update
19270004 - Checked - Internal Screen Doesn't Update
193B0005 - Checked - Internal Screen Doesn't Update
191B0006 - Checked - Internal Screen Doesn't Update
19260007 - Checked - Internal Screen Doesn't Update

191E0003 looks pretty hopeful, I've been trying to figure out the pattern to this table to try and see if there are any other modifications I can make to it that would either make others act more like 191E0003 to experiment more.

Your drivers64UEFI is not per guide. The guide reccomends AptioMemoryFix.efi (without EmuVaraibleUefi-64.efi) or OsxAptioFixDrv-64.efi (not OsxAptioFix2Drv-64.efi) with EmuVariableUefi-64.efi.

Updated with no change.

You should also check that you have the latest CoreDisplayFixup.kext.

I have version 1.3.7, the latest as per the GitHub releases page for that project.

Changing the resolution of the internal display might also help (use RDM from the menubar via remote desktop connection).

No luck with this. Tried a couple of resolutions, and tried a whole lot in 191E0003.

As usual files attached, will continue with experimentation on framebuffer tomorrow.

 

[RehabMan]

Sure thing, the machine looks like this when I report that the screen does not update when it should. Artifacting appears after using the computer over VNC for a bit.
View attachment 342052



Should I worry about my backlight before the display is working? I'll surely follow that guide after. I can do so now if you think it's a useful debugging step.



Ok, all tests in this posts were performed with CSM enabled. Legacy boot available. Clover booted still via UEFI, let me know if I misinterpreted that.



Tackling this a bit out of order, but system doesn't boot without this patch, so the UEFI disassembly may have been misleading, or some other setting in the UEFI directly affects this setting and it's no longer in it's default value. I wish Lenovo didn't lock down the UEFI of a flagship tier workstation laptop.



Wew, this part took a while, but I did go through all the device IDs in _gPlatformInformationList that you mentioned.

191E0000 - Checked - Internal Screen Doesn't Update
19160000 - Checked - Internal Screen Doesn't Update
19260000 - Checked - Internal Screen Doesn't Update
19270000 - Checked - Internal Screen Doesn't Update
191B0000 - Checked - Internal Screen Doesn't Update
193B0000 - Checked - Internal Screen Doesn't Update
19120000 - Checked - Internal Screen Goes Black
19020001 - Checked - Kernel Panics
19170001 - Checked - Kernel Panics with a 95% of the screen consumed by glitching/artifacting
19160002 - Checked - Kernel Panics
19260002 - Checked - Kernel Panics
191E0003 - Checked - Kernel Panics
19260004 - Checked - Kernel Panics
19270004 - Checked - Kernel Panics
193B0005 - Checked - Kernel Panics
191B0006 - Checked - Kernel Panics
19260007 - Checked - Kernel Panics

Internal Screen Doesn't Update looks like the picture attached above. The kernel panics were no surprise so I went ahead and created more patches for _gPlatformInformationList. The patches simply are a extension of one already in use for the 32MB DVMT-prealloc patch, but modified to work with 19160002 and onwards. 19020001 and 19170001 were strange because they had 0's where the patched data usually go, I guess I could have patched those too. Possibly may try that tomorrow. Regardless after apply the new patches I got different results from 19160002 and onwards.

19160002 - Checked - Internal Screen Doesn't Update
19260002 - Checked - Internal Screen Doesn't Update
191E0003 - Checked - Internal Screen Goes Black however when VNCed into the Display is actually detected as attached unlike before when it would show up as Virtual Display in SwitchResX. Changing the resolution does not bring display, but it did dim the screen as though it was actually doing something. RDM did the same.
19260004 - Checked - Internal Screen Doesn't Update
19270004 - Checked - Internal Screen Doesn't Update
193B0005 - Checked - Internal Screen Doesn't Update
191B0006 - Checked - Internal Screen Doesn't Update
19260007 - Checked - Internal Screen Doesn't Update

191E0003 looks pretty hopeful, I've been trying to figure out the pattern to this table to try and see if there are any other modifications I can make to it that would either make others act more like 191E0003 to experiment more.



Updated with no change.


I have version 1.3.7, the latest as per the GitHub releases page for that project.



No luck with this. Tried a couple of resolutions, and tried a whole lot in 191E0003.

As usual files attached, will continue with experimentation on framebuffer tomorrow.

It is not uncommon for HiDPI displays to need more DVMT-prealloc than 32MB (clearly, your DVMT-prealloc is not 64MB).
You should look into setting DVMT-prealloc to 64MB or even 128MB.
Or you could try the minStolenSize patch.

 

[guitengyue]

Hardware

• ThinkPad P50
• Intel i7 6700HQ
• 32GB RAM
• NVIDIA M1000M
• UHD(3840*2160) change it from 1920*1080 by myself
• BIOS: 1.44 and 1.56

QUESTION:
When I want to change the dmvt through setup_var 0xD9 0x3 or 0x4，but it appears error
GUID does not match expected GUID, taking it neverthless....

error: can't set variable using efi (error: 0x 00000000000008)