3D Acceleration and HDMI/DP output on Intel Corporation CometLake-H GT2 [UHD Graphics] (rev 05) iGPU

[rforberger]

Hi,

 

I got my MacOS installed using my configuration: https://github.com/rforberger/EFI-OpenCore-Thinkpad-P15/tree/master/OC.experimental

 

But I can't get 3D acceleration and HDMI output running. MacOS recognizes my monitor as an Unknown Display and my iGPU is only recognized with 7MB VRAM.

 

I tried to follow this guide: https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md 

But the WhateverGreen Platform ID seems not right. The only one that works though is 3EA50009, but this is for an Intel Iris Graphics card. I can't use 00009B3E, which seems to be for Intel UHD Graphics?

 

I get a black screen when booting MacOS with this Platform ID or the computer reboots, depending on some framebuffer options.

 

Here is my DeviceProperties Config:

 

			<key>PciRoot(0x0)/Pci(0x2,0x0)</key>
			<dict>
				<key>AAPL,ig-platform-id</key>
				<data>PqUACQ==</data>
				<key>device-id</key>
				<data>mz6Ahg==</data>
                                <key>AAPL,slot-name</key>
                                <string>Internal@0,2,0</string>
                                <key>AAPL,GfxYTile</key>
                                <data>
                                AQAAAA==
                                </data>
                                <key>enable-hdmi-dividers-fix</key>
                                <data>
                                AQAAAA==
                                </data>
				<key>dpcd-max-link-rate</key>
				<data>FAAAAA==</data>
				<key>enable-dpcd-max-link-rate-fix</key>
				<data>AQAAAA==</data>
				<key>enable-lspcon-support</key>
				<data>AQAAAA==</data>
				<key>enable-max-pixel-clock-override</key>
				<data>AQAAAA==</data>
                                <key>enable-hdmi20</key>
                                <data>
                                AQAAAA==
                                </data>
				<key>framebuffer-patch-enable</key>
				<data>AQAAAA==</data>
				<key>framebuffer-fbmem</key>
				<data>AACQAA==</data>
				<key>framebuffer-stolenmem</key>
				<data>AAAwAQ==</data>
				<key>framebuffer-unifiedmem</key>
				<data>AAAAgA==</data>
				<key>framebuffer-con1-enable</key>
				<data>AQAAAA==</data>
				<key>framebuffer-con0-enable</key>
				<data>AQAAAA==</data>
				<key>framebuffer-con0-has-lspcon</key>
				<data>AQAAAA==</data>
				<key>framebuffer-con0-preferred-lspcon-mode</key>
				<data>AAAAAA==</data>
				<key>framebuffer-con2-enable</key>
				<data>AQAAAA==</data>
				<key>framebuffer-con2-has-lspcon</key>
				<data>AQAAAA==</data>
				<key>framebuffer-con2-preferred-lspcon-mode</key>
				<data>AAAAAA==</data>
                                <key>hda-gfx</key>
                                <string>onboard-1</string>
			</dict>
		</dict>

Any advise how to get 3D accelaration and HDMI to work?

[rforberger]

OK.

 

CPU: Intel(R) Core(TM) i7-10850H CPU @ 2.70GHz (Comet Lake 10th Gen)

Motherboard: Lenovo 20ST000SIX

Laptop: Lenovo ThinkPad P15 Gen 1
dGPU: NVIDIA Corporation TU117GLM [Quadro T2000 Mobile / Max-Q] (rev a1)
Memory: 16GB DDR4 SODIMM

SSD: 2x Samsung Electronics Co Ltd NVMe SSD 980

[deeveedee]

@rforberger It may be that the only problem is that you are incorrectly specifying your DeviceProperties.  See below...

 

Agree with @eSaF. Your GitHub repo indicates Thinkpad P15, but it would help to know the CPU and if there is a dGPU (since Thinkpad specs indicate a P15 with Nvidia).

 

Looks like you've spent quite a bit of time on your ACPI patches.  If your Thinkpad P15 is CometLake, you'll want to try all CometLake mobile frame buffers in the IntelHD doc you referenced (test all CometLake mobile framebuffers with 3 connectors).  Some things I noticed in your config.plist that you might want to check:

• You incorrectly specify your frame buffer: 3EA50009.  In your config.plist, the frame buffer and all DeviceProperties data attributes must be specified in Little endian (reverse byte order): 3EA50009 -> <0900A53E>.  This fix may fix your problem.
• You may not need to specify a device-id (should be detected automatically), but if you do, same byte order applies.  Try without device-id.
• Try without framebuffer-fbmem, framebuffer-stolenmem, framebuffer-unifiedmem.  These properties hurt performance on my rigs and I found are not needed in most cases (for me).
• If you do have an Nvidia dGpu, you may need WEG boot-arg -wegnoegpu (disable all external GPUs)

 

Good luck with your hack!

 

EDIT: @rforberger See my notes about byte order here when I was first learning to patch Intel UHD iGPU.

 

@rforberger One other thing: If you do need to spoof a device-id in your DeviceProperties (first try without it as I indicated above), it must be Little Endian data format (reverse byte order) and I'm fairly certain that it should be without 8086 in the device-id.

Edited February 9, 2023 by deeveedee

[rforberger]

Hi,

 

@deeveedee

Thanks, I followed your instructions, but I still can't get the graphics work.

 

Now 

 

- I changed my Platform ID to little endian

- Now I get no graphics output anymore at all

- No one of the Platform IDs 09009B3E, 06009B3E, 00009B3E, 0000923E, 0000003E, 0000A53E, 0400A53E, 0500A53E, 0900A53E, 0500A63E from https://github.com/dortania/oc-laptop-guide-legacy/blob/master/prepare-install-macos/display-configuration.md work

- Dev ID seems to be 9BC4 (Big endian) for my iGPU, Linux lspci and Hackintool for Mac show the same, tried both with and without device-id C49B (Little endian)

- I removed framebuffer-fbmem, framebuffer-stolenmem, framebuffer-unifiedmem

- I disabled the dGPU by boot-arg -wegnoegpu

 

That must be something else with my configuration. No graphics output.

 

https://raw.githubusercontent.com/rforberger/EFI-OpenCore-Thinkpad-P15/master/OC.experimental/config.plist

 

Any ideas?

 

Best regards,

rforberger

 

[deeveedee]

@rforberger You may want to search for others who have solved the P15 hack, since you're not the first.  I did a quick search and found this by someone who claims success.  The hacker does spoof the device-id, so maybe that is necessary for CometLake.

 

Note that the hacker specifies framebuffer-fbmem, framebuffer-stolenmem, framebuffer-unifiedmem device properties.  I've observed that too many people use these DeviceProperties automatically because they've seen them in a guide.  I still recommend against them unless your testing confirms that you need them, since they are probably unnecessarily limiting.

 

Also note that the hacker specifies SMBIOS MacModel MBP16,1.

Edited February 9, 2023 by deeveedee

[rforberger]

Hmm, the Platform ID and device ID https://github.com/ivan19871002/Thinkpad-P15V-Gen1-Hackintosh is using, doesn't work for me. I have tried his config, but I get a black screen when MacOS tries to start graphics. I seem to have another iGPU than he. Tried all possible Platform IDs.

[deeveedee]

@rforberger You may want to compare your config.plist to the other to look for differences.  I see a boot-arg (-igfxonln=1) that does affect graphics behavior, so you may want to try it.  

 

After you get your graphics working, you shouldn't need to disable SIP.  csr-active-config = <00000000> should work for your hack.

 

@rforberger The other hacker has the same CPU that you do, thus the same iGPU. You are correct - he has a different CPU. You'd have to compare data sheets to see if the iGPU is different.

 

@rforberger I compared data sheets and to me, it looks like you have the same iGPU.  You should be able to model your DeviceProperties after this (assuming that the other hacker was successful).

Edited February 9, 2023 by deeveedee

[rforberger]

Hi deeveedee,

 

If I use his DeviceProperties, I get a black screen.

 

But I partly solved it.

 

I think I have the right platform (and device id) now. I had been entering the platform id wrong into ProperTree (a plist editor), but ProperTree automatically converts Big Endian to Little Endian.

 

So I didn't need to convert it. But I wrote myself a little tool, that automatically converts it correctly using Linux:

 

import plistlib
fileName = "new.plist"
pl = dict(
    igplatformid = b"\xA5\x3E\x00\x09",
    deviceid = b"\xC4\x9B\x00\x00",
    activeconfig = b"\x00\x00\x00\x00",
)
with open(fileName, 'wb') as fp:
    plistlib.dump(pl, fp)

With these values encoded into property list format, I get the graphics up and it's relatively fast. But Hackintool still says, VDADecoding failed.

 

Meaning I have no Hardware-Accelaration, right?

 

I also don't get the HDMI port running. I have configured the framebuffer-conX-type values with 0008000 (Little Endian) for HDMI, but no effect.

 

Any help is appreciated.

 

Here is my current EFI: https://github.com/rforberger/EFI-OpenCore-Thinkpad-P15

[deeveedee]

@rforberger Glad to see you haven't given up!  I inspected the config.plist posted in your GitHub repo and see that you have specified your frame buffer (AAPL,ig-platform-id) as <A53E0009>.  This is not a valid framebuffer.  I think you meant to enter <0900A53E>.

 

As you observed in my thread, I needed to experiment with multiple frame buffers to find ones that worked.  For another hack that I haven't documented in this forum, finding a framebuffer that worked for my HDMI port took a bit of patience.  Patiently test each frame buffer (being certain to enter it correctly in your config.plist).  I use Xcode to edit my plists.  Others use the OCAT configurator.   Each person has their own preferred tool for editing the config.plist - just be sure you know how data is represented in your chosen tool.

 

You may still need to experiment with other frame buffers (those mobile frame buffers valid for CoffeeLake/CometLake with 3 connectors from here).  Your CPU has DeviceID 0x9bc4, so you do not need to specify it in your DeviceProperties (but it doesn't hurt).  If you are curious, remove your device-id property and see that it is automatically detected (and is a natively supported CometLake device-id according to this).

 

EDIT: @rforberger  I just noticed that I had incorrectly entered my corrected framebuffer.  Should be "I think you meant to enter <0900A53E>"

 

Also I noticed that you have a kernel patch in your config.plist (Kernel > Patch > Item0).  This kernel patch is the same as WhateverGreen boot-arg igfxagdc=0 and DeviceProperty disable-agdc.  You don't need to change this - I'm just pointing it out to you in case you copied this and didn't know what it was for.  In some cases, it fixes black screen issues, in other cases it allows multiple, simultaneous displays and in other cases, it allows VGA output.  I use igfxagdc=0 on my hack here to enable multiple, simultaneous displays.

 

 

Edited February 10, 2023 by deeveedee
Corrected typo in <9000A53E>

[rforberger]

OK, well, thanks. I think I got VDADecoding working and I am using the right Platform ID now (0500A53E). It was still a little endian encoding problem.

 

But I don't get the HDMI output working.

 

I tried the following alldata Setting:

 

Connection	Index	Pipe	Bus ID	Flags	alldata
con0	0	18 (Decimal?)	0x00	0x00000098	00001200 20000000 98000000
con1	1	18 (Decimal?)	0x05	0x000001C7	01051200 00040000 C7010000
con2	2	18 (Decimal?)	0x04	0x000001C7	02041200 00080000 C7010000

 

I tried all possible permutations, but no success. 

 

Anyone who knows about this? I read the docs, but when I follow them, I only get black screens.

[deeveedee]

@rforberger Glad you figured out the data formatting issue.  I personally don't like the "all data" format because I found it harder to read and harder to share with others (because I was requiring them to decode the data).  While I was experimenting with graphics patching, I found it much easier to keep all properties separate in their own property and not combined into the all data property.

 

I'm sorry I couldn't help you to get further.  I would suggest that you spend some time figuring out how the known working solution here is different from yours.

 

Also, you may need to change your connector flags.  From my post here, I made the following change for working graphics in my hack:

• Change all connector flags to 0x03C7.  Without the change in flag values, displays remained black after sleep/wake and I could not remotely connect after sleep/wake.

 

EDIT: If you haven't already, make sure that you are confident in your mapping of the logical connectors in your DeviceProperties to the physical ports.  This is important so that you know which logical connector property changes are affecting which physical ports.  For example, make sure you are certain that connectorX is associated with your HDMI port.

Edited February 10, 2023 by deeveedee

[rforberger]

OK, well, It's totally unclear to me, how to model the connector patches.

 

• For the conX number, should I use con0,con1,con2 or con1,con2,con3? The working solution uses con1,con2,con3 here.
• For the index of the connector, should I use 0,1,2 or 1,2,3 here? The working solution uses 1,2,3 here, but Hackintool on my PC says the connectors have indexes 0,1,2!
• For the busid, Hackintool shows me 0x00 (LVDS), 0x05 (DP) and 0x04 (DP). The working solution though uses 0x05,0x06,0x04!
• For the pipe, Hackintool shows 18 on all connectors on my PC, so I used 0x1200. The working solution uses 0x0900 here!
• For the connector type I don't know if I should use 20 00 00 00 for the LVDS and 00 04 00 00 for the two DP or if I should 00 08 00 00 for one DP. The working solutions uses 00 04 00 00, 00 04 00 00, 00 08 00 00 here!
• As the flags I am using 0xC7030000 as suggested by you

So any ideas how I should patch my connectors? I have tried a couple of permutations, but always black screen!

[deeveedee]

@rforberger Take a look at my posts here, here and here - not necessarily to copy my settings, but to see the effort required to find working patches.  It was the hardest part for me, because I didn't have another working EliteDesk 800 G4/G5 EFI mini to review.  I spent many hours of tedious trial and error.

 

The reason that the other solution is patching connectors 1, 2 and 3 is because they are not patching con0 (which I assume is for the built-in display) and they are patching con1-3 (note that he sets port-count=4).  

 

I don't have your laptop to patch, but if I were you, I'd spend more time studying the other working solution and attempting to duplicate it.  This is hard stuff.  I spent many hours trying different permutations and combinations as you have done.  Don't give up.

 

IMPORTANT: Don't rely on Hackintool for graphics patching.  I found that I needed to apply my patches manually and that hackintool did not reliably display my patches.  Sorry to have to say that, because it is a great tool.

Edited February 10, 2023 by deeveedee

[rforberger]

OK, looks like I'll have to spend many hours of trial and error.

 

Tried already alot of permutations, but the external monitor never turns on.

 

That makes me a bit thoughtful, as I think something else besides connector patching must be done to enable it.

 

But I think the working solution was made for a slightly different model of Thinkpad (P15V), I have a P15. So connector busids etc might not be the same. 

 

And I don't understand why specifying the busids and pipes at all, I think MacOS should know them via the index. So would just need to patch index and type. But I have tried that, even that without success.

 

I'll try further.

 

 

[rforberger]

Hi,

 

I found out, that on the "working solution" the device id must be wrong and therefore possibly also the ig-platform-id. There is no such PCI ID 8086:9B3E. PCI ID 8086 is Intel Corporation.

 

I think he also has an 8086:C49B or similar. I think I have the right driver then, because I get 3D acceleration. Just HDMI doesn't get enabled..

[deeveedee]

@rforberger He is "spoofing" CoffeeLake device-id 0x3e9b (little endian <9B3E0000>) - a perfectly valid device-id.  I doubt he needs to, but it probably doesn't hurt.  He is using framebuffer (AAPL,ig-platform-id) 0x3e9b0000 (little endian <00009B3E>)  - a perfectly valid CoffeeLake framebuffer. 

 

Read this again.

[rforberger]

Aha, ok.

 

Well, I am a bit out of ideas, I tried almost all combinations now and don't know if I am on the right path. I don't see any change in the graphics output. I need some point where to look at.

 

I even flashed the BIOS with no change in result.

 

Also, when changing to Discrete graphics in the BIOS, I get no graphics output anymore in MacOS, this might be related to the -wegnoegpu boot-arg. When using Hybrid Graphics Mode in the BIOS, Windows connects HDMI using the NVidia dGPU it reports.

So I tested Discrete graphics, but graphics won't start in MacOS then.

 

Currently, out of ideas.

 

[deeveedee]

MacOS doesn't support your Nvidia dGPU.  Your EFI includes SSDT-DGPU (look in EFI/OC/ACPI) that turns off the dGPU.  The -wegnoegpu boot-arg that I suggested probably isn't needed (doesn't hurt) since the SSDT turns off the Nvidia graphics.  Maybe you should try contacting the owner of this to see if they can confirm what is working (and what is not).

 

It seems strange to me that your P15 HDMI port would be driven only by the Nvidia dGPU when the owner of this claims that their P15's HDMI output works in MacOS.  As you indicated, your laptop is different.  If in fact your HDMI is driven only by Nvidia graphics, then it will not have any video output in MacOS.  I'm remaining optimistic that if HDMI works here, you should be able to get it working on your P15.

 

As you develop a better understanding of this solution, you may want to try it again (including his DeviceProperties and BIOS settings) with minimal changes.

Edited February 11, 2023 by deeveedee

[rforberger]

I am a bit afraid that HDMI might not work due to the reason, that the HDMI output is connected to the NVidia GPU when selecting Hybrid Graphics in the BIOS. Hybrid means it can use both GPUs, including the Nvidia. But in discrete mode, no graphics output is shown. I  think it will use the Nvidia dedicated then. I would like to test how to tell OpenCore that it anyway puts the connector of the HDMI to the iGPU, if that is the case. Not sure how this is wired.

[deeveedee]

@rforberger I just noticed that in your posted EFI here, your SSDT-DGPU is disabled (I hadn't noticed that before) while in the supposedly working EFI posted here, SSDT-DGPU is enabled:

 

Your config.plist

Spoiler

 

ivan19871002's config.plist

Spoiler

 

 

Are you currently operating with SSDT-DGPU disabled in your config.plist?  Have you tested ivan19871002's posted solution without making any changes to it?  I may be guessing, but it appears to me that you copied a large part of your solution from ivan19871002.  Have you tried contacting them?

Edited February 11, 2023 by deeveedee

[rforberger]

I have tried both with SSDT-DGPU.aml activated and deactivated, same result.

 

I have also tested ivan19871002's solution without making any changes, same result, computer reboots.

I have contacted them via GitHub and he said I should follow the documentation.

But anyway, I think I will start over and set it up again following the official docs hoping it will work. 

[rforberger]

Got the solution respectively anti-solution.

 

According to the Hackintosh Discord Chat room, my HDMI and DP ports are wired with the dGPU.

 

I could verify that in Windows.

 

So I think it's not possible to get HDMI output on my Thinkpad P15 on the iGPU.

[deeveedee]

@rforberger I'm sorry to hear that.  It's a risk with laptops that have a dGPU and iGPU.  On the bright side, you have a much better understanding of OC DeviceProperties, you'll never forget Little Endian data format again and it simplifies your graphics patching.  You can focus on a framebuffer that enables your internal display and ignore patching of the HDMI and DP ports.

 

I'm still very surprised that Ivan claims success here, since it means that Lenovo has gone to the trouble of "wiring" graphics differently in their P15 series laptops.  That seems like a waste of design time.

[rforberger]

Well, don't know what Lenovo does. But I should have seen some progress if it would be possible to use the iGPU with HDMI.

 

Ivan's solution is for the Thinkpad P15V, maybe wiring there is different...

 

But I am considering to buy a docking station with an own GPU, so I can bypass the problem.

 

On the long run, with Apple's Silicon strategy, I am not sure if Hackintosh on x86 will have a bright future.

[deeveedee]

1 hour ago, rforberger said:

On the long run, with Apple's Silicon strategy, I am not sure if Hackintosh on x86 will have a bright future.

 

We're certainly nearer to the end of Intel hackintoshing than the beginning.  I don't believe there are many who are buying the latest Intel-based hardware with the primary purpose of a hackintosh.  It's still fun to hack old PCs (see my 2010 laptop here) to see if it's possible to run the latest MacOS on them and if you purchase a new PC for Windows, it's still fun to hack it.  I find that there is a lot of utility in being able to dual-boot (Windows and MacOS) a PC.