Contribute
Register

iMac Pro X299 - Live the Future now with macOS 10.14 Mojave [Successful Build/Extended Guide]

Status
Not open for further replies.
the idea was that only in 14.5 beta radeon 7 works as though, but with disappointing performance ... in this sense I opened the discussion about beta ...

and my tests are similar in value to those of yours, but I'm under the vega 56 ... in fcpx bruce test is about 18-20 seconds ...

that's why I'm going to exchange more information on this topic

Why are you disappointed with Radeon VII? :think:

Bruce X 5k Test is about 10-11 seconds for me. It wasn't this good in Vega FE (which is better than the Vega 56, same as Vega 64 but with more VRAM).

See linked video capture with Radeon VII and FCPX 10.4.6

Remove about 3 seconds from the front of the timer if you want to be exact since I hit the timer too early. But you get the idea...

This is already a really good score for Bruce X and it will get better once they tweak macOS and FCPX. Wouldn't be surprised if Bruce X test nets 8-9 seconds once all things are refined.

The real iMac Pro with Vega 64 is 15 seconds I believe for Bruce X 5k.
 
Last edited:
Why are you disappointed with Radeon VII? :think:

Bruce X 5k Test is about 10-11 seconds for me. It wasn't this good in Vega FE (which is better than the Vega 56, same as Vega 64 but with more VRAM).

See linked video capture with Radeon VII and FCPX 10.4.6

Remove about 3 seconds from the front of the timer if you want to be exact since I hit the timer too early. But you get the idea...

This is already a really good score for Bruce X and it will get better once they tweak macOS and FCPX. Wouldn't be surprised if Bruce X test nets 8-9 seconds once all things are refined.

The real iMac Pro with Vega 64 is 15 seconds I believe for Bruce X 5k.

we do not have the same hardware configuration, but if I please you can send me your efi folder ?... as inspiration
 
the idea was that only in 14.5 beta radeon 7 works as though, but with disappointing performance ... in this sense I opened the discussion about beta ...

and my tests are similar in value to those of yours, but I'm under the vega 56 ... in fcpx bruce test is about 18-20 seconds ...

that's why I'm going to exchange more information on this topic

Give time to Apple to implement everything properly. Remember that we are talking about early betas!

As I am using a dedicated Radeon VII SSDT with a particular although likely not yet fully optimised Radeon VII load table, my Cinebench, Geekbench, Heaven and Valley Scores are better than those presented many times elsewhere, although admittedly they are still far below those I obtained with a Vega 64 within a similar system configuration. See post #671. At present, only Luxmark reveals a significant performance boost (>50.000) with the VII over the Vega 64 (30.000) under macOS. Within 10.14.5 public beta 2, also H264 and HEVC will be fully supported by the VII.

In my personal opinion it is also too early to conclude anything about the thermal performance of the VII at present under macOS. Such conclusions will reach significance, once the VII reached its full performance also under macOS.

I am returning the air flow VII, I employed for testing purposes so far, today to its owner. Everything seems set and implemented at my side. The rest seems related with a yet missing optimisation of Apple's VII drivers and 3rd party software. The reason of my VII testing was to provide to the community a similar optimised Radeon VII implementation like in case of the Vegas, without recommending ever to opt for a VII at the current state. Respective SSDTs are now available in my Github SSDT repositories and I also once more locally modified the Kozlek/Interferenc FakeSMC/HWSensor distribution to also show VII GPU temps under iStatMenus. The respective FakeSMC and HWSensor kexts are part of my recent 10.14.5 EFI-Folder distributions. Everything also fully considered, implemented and outlined in my guidelines in the originating post of this thread.

Myself I will change to the VII once it reached its full performance also under macOS, but more importantly, once I have the necessary funds and economical resources to opt for a water blocked VII myself.

Until then, all the best in the meanwhile,

KGP
 
we do not have the same hardware configuration, but if I please you can send me your efi folder?... as inspiration

Did you follow the good guide on page one of this thread? Even though its specifically for X299 I can’t comment on your config since I’ve never tried the iMac Pro 1,1 SMBIOS on the Z line motherboards. The 9900k is a solid cpu with better single core performance than even overclocked X299 chips so it’s no slouch. Even in multi core.

If you are using the guide on page one, you should try disabling iGPU completely in the BIOS so your dGPU is used with the iMac Pro SMBIOS. However like I said I have not much experience with your setup and the iMac Pro 1,1 SMBIOS. I would be using iMac 19,3 or whatever the newest iMac SMBIOS is with your config since you have a consumer cpu with iGPU. :thumbup:
 
@corint1,

It was never meant that you have to follow all guidelines in the first post of this thread, although you also could theoretically do so after disabling your iGPU, but you should at least read the guidelines anyway.

Considering and properly adapting SSDT-X299-Radeon-VII.aml and SSDT-X299-HDEF.aml for your motherboard and GPU PCIe slot population, in line with SSDT-DTPG.aml, a correct Audio ID injection in your config.plist and Lilu.kext, AppleALC.kext and Whatevergreen.kext in your EFI-Folder, might be more than sufficient for optimizing your actual VII system implementation. In this case, you could also write an additional SSDT for your iGPU, if you feel like. To also show VII temps with iStatMenus, you should also copy & paste the FakeSMC and HWSensor distribution, implemented in my recent 10.14.5 X299 EFI-Folder distribution.

All this of course only, if you are interested at all.

Good luck my friend,

KGP
 
@corint1,

It was never meant that you have to follow all guidelines in the first post of this thread, although you also could theoretically do so after disabling your iGPU, but you should at least read the guidelines anyway.

Considering and properly adapting SSDT-X299-Radeon-VII.aml and SSDT-X299-HDEF.aml for your motherboard and GPU PCIe slot population, in line with SSDT-DTPG.aml, a correct Audio ID injection in your config.plist and Lilu.kext, AppleALC.kext and Whatevergreen.kext in your EFI-Folder, might be more than sufficient for optimizing your actual VII system implementation. In this case, you could also write an additional SSDT for your iGPU, if you feel like. To also show VII temps with iStatMenus, you should also copy & paste the FakeSMC and HWSensor distribution, implemented in my recent 10.14.5 X299 EFI-Folder distribution.

All this of course only, if you are interested at all.

Good luck my friend,

KGP

thank you... butI have small observations :
I'm afraid WEG is not compatible with radeon 7 .... and ioreg saw that radeon 7 uses framebuffer from vega10 and not from vega20 ... why?
 
Hi there KGP,

I would like to thank you for the excellent work you've done with this guide. I am an experienced IT person but I haven't touched a Mac computer for almost 30 years. Your guide is amazing, including the referenced mini guides as you call them. I have never imagined building a Hackintosh would be such a tedious and lengthy procedure - it took me almost two weeks - but it was an interesting learning experience. Thank you !

Also making my own choices as far as hardware is concerned gave me the chance to learn and understand the whole procedure much better.

To the point now...

Everything works as expected, including TB3 hotplug functionality! I am stuck at implementing the TB3 SSDT changes that will give me a correct PCI system information view. As you can see from the attached files my system (Asrock TB3 AIC?) differs in the way TB USB-C is implemented. In my system it lies with PCI0\RP05\UPSB\DSB1 instead of ...\DBS2.
I've modified the attached SSDT-X299-TB3HP.aml, to the best of my abilities but still I can not get to work properly. TB USB-C Controller is not recognized!

I have attached the registry before and after the use of the SSDT along with the respective PCI System Information details.

The strange (?) thing is that with or without the SSDT everything works - even TB3 hotplug. I have a USB-C hub attached to the back of my monitor (LG Ultrafine 5k 27"). My monitor is attached to Asrock TB3 AIC with a single TB2 cable using the Apple TB2->TB3 adapters. My Vega 64 is connected to the TB3 PCIe card with a single DP cable. Testing USB 2.0 and USB 3.0 sticks with the USB-C hub works with OR without the use of the SSDT.

The only thing I can not get to work, no matter what I try, is the second TB3 port at the back of the Asrock AIC and the Brightness sensor of the monitor.

I guess the problem lies with some device id inside the SSDT but I do not have the knowledge to debug it...

Can you please help me ?

Thanks for you attention
 

Attachments

  • Without_TB3_SSDT.ioreg
    16.4 MB · Views: 57
  • Without_TB3_SSDT.png
    Without_TB3_SSDT.png
    1.1 MB · Views: 57
  • With_TB3_SSDT.ioreg
    16.6 MB · Views: 59
  • With_TB3_SSDT.png
    With_TB3_SSDT.png
    1.2 MB · Views: 52
  • SSDT-X299-TB3HP.aml
    5.7 KB · Views: 71
thank you... butI have small observations :
I'm afraid WEG is not compatible with radeon 7 .... and ioreg saw that radeon 7 uses framebuffer from vega10 and not from vega20 ... why?

Can you show me where in Apple's vanilla AMD GPU kexts you do find up to now a AMDFramebufferVega20 definition?

Else macOS does use the correct AMDVega20GraphicsAccelerator for the VII, defined in AMDRadeonX5000.kext.

Not only up to my knowledge, WEG does support the VII and my entire current system configuration also works without major issues such, apart from the yet not perfect overall VII performance .
 
Hi there KGP,

I would like to thank you for the excellent work you've done with this guide. I am an experienced IT person but I haven't touched a Mac computer for almost 30 years. Your guide is amazing, including the referenced mini guides as you call them. I have never imagined building a Hackintosh would be such a tedious and lengthy procedure - it took me almost two weeks - but it was an interesting learning experience. Thank you !

Also making my own choices as far as hardware is concerned gave me the chance to learn and understand the whole procedure much better.

To the point now...

Everything works as expected, including TB3 hotplug functionality! I am stuck at implementing the TB3 SSDT changes that will give me a correct PCI system information view. As you can see from the attached files my system (Asrock TB3 AIC?) differs in the way TB USB-C is implemented. In my system it lies with PCI0\RP05\UPSB\DSB1 instead of ...\DBS2.
I've modified the attached SSDT-X299-TB3HP.aml, to the best of my abilities but still I can not get to work properly. TB USB-C Controller is not recognized!

I have attached the registry before and after the use of the SSDT along with the respective PCI System Information details.

The strange (?) thing is that with or without the SSDT everything works - even TB3 hotplug. I have a USB-C hub attached to the back of my monitor (LG Ultrafine 5k 27"). My monitor is attached to Asrock TB3 AIC with a single TB2 cable using the Apple TB2->TB3 adapters. My Vega 64 is connected to the TB3 PCIe card with a single DP cable. Testing USB 2.0 and USB 3.0 sticks with the USB-C hub works with OR without the use of the SSDT.

The only thing I can not get to work, no matter what I try, is the second TB3 port at the back of the Asrock AIC and the Brightness sensor of the monitor.

I guess the problem lies with some device id inside the SSDT but I do not have the knowledge to debug it...

Can you please help me ?

Thanks for you attention

Hi @VassilisA,

well.. I have no personal experience with the Asrock TB3 AIC at all, but I guess it should just behave like all other TB3 PCIe adapters and anyway there seems to exist a basic misunderstanding at your side.

I use an LG5K2K, and its USB ports also appear under DSB1, when connecting the monitor via TB3, as in this case these are USB ports of a TB device and such ACPI implementation is therefore also completely correct.

What should appear under DSB2 are USB-C devices (like USB-C Flash Drives) connected to your TB3 ports, which in the same way can naturally act as USB-C ports.

Following the ACPI table in your original IOREG.sav without any TB SSDT, there are no DSB2 sub-entities (DSB2 is unpopulated) without any USB-C devices connected at boot and such, USB-C also won't work when connecting any USB-C device subsequently.

You have to investigate whether there would be XHC USB sub-entities under DSB2 (DSB2 populated) without any TB SSDT, in case of booting your system with some external USB-C device (USB-C Flash Drive) connected to the Asrock TB3 AIC at boot.

In case that DSB2 gets populated without any TB-SSDT but with USB-C devices connected at boot, also the respective SSDT device definition should successfully apply during boot and provide subsequent USB-C HotPlug capability in consequence.

In conclusion and based on your above results, your two USB-C ports might only work such under macOS, when connecting at least one USB-C device at boot.

I am even more surprised that you state that TB HP works in your case even without any TB SSDT implementation, although your DSB0 device obviously misses the PCIHotPlugCapable property with value 0x1 when inspecting your IOREG.save without any TB SSDT implementation. If your primer statement would be really true and the case, you could anyway also skip the entire TB SSDT implementation. The same states btw also for your DSB2 implementation. ;)

What you did in the SSDT attached to your post above is totally wrong in any case. There is absolutely nothing one should account for in a respective TB SSDT device implementation that would change the anyway correct DSB1 USB ACPI implementation of your TB Monitor's USB2.0 and USB3.0 ports!

Attached below a TB SSDT, which should work OoB as soon your Asrock TB3 AIC behaves as expected and as described above.

Cheers,

KGP
 

Attachments

  • SSDT-X299-TB3HP.aml.zip
    1.6 KB · Views: 78
Last edited:
Hi @VassilisA,

well.. I have no personal experience with the Asrock TB3 AIC at all, but I guess it should just behave like all other TB3 PCIe adapters and anyway there seems to exist a basic misunderstanding at your side.

I use an LG5K2K, and its USB ports also appear under DSB1, when connecting the monitor via TB3, as in this case these are USB ports of a TB device and such ACPI implementation is therefore also completely correct.

What should appear under DSB2 are USB-C devices (like USB-C Flash Drives) connected to your TB3 ports, which in the same way can naturally act as USB-C ports.

Following the ACPI table in your original IOREG.sav without any TB SSDT, there are no DSB2 sub-entities (DSB2 is unpopulated) without any USB-C devices connected at boot and such, USB-C also won't work when connecting any USB-C device subsequently.

You have to investigate whether there would be XHC USB sub-entities under DSB2 (DSB2 populated) without any TB SSDT, in case of booting your system with some external USB-C device (USB-C Flash Drive) connected to the Asrock TB3 AIC at boot.

In case that DSB2 gets populated without any TB-SSDT but with USB-C devices connected at boot, also the respective SSDT device definition should successfully apply during boot and provide subsequent USB-C HotPlug capability in consequence.

In conclusion and based on your above results, your two USB-C ports might only work such under macOS, when connecting at least one USB-C device at boot.

I am even more surprised that you state that TB HP works in your case even without any TB SSDT implementation, although your DSB0 device obviously misses the PCIHotPlugCapable property with value 0x1 when inspecting your IOREG.save without any TB SSDT implementation. If your primer statement would be really true and the case, you could anyway also skip the entire TB SSDT implementation. The same states btw also for your DSB2 implementation. ;)

What you did in the SSDT attached to your post above is totally wrong in any case. There is absolutely nothing one should account for in a respective TB SSDT device implementation that would change the anyway correct DSB1 USB ACPI implementation of your TB Monitor's USB2.0 and USB3.0 ports!

Attached below a TB SSDT, which should work OoB as soon your Asrock TB3 AIC behaves as expected and as described above.

Cheers,

KGP

Wow ! That was my last weekend down the drain ....
Thank you !

In your guide you mentioned that we should boot with a USB-C device in order to populate the PCIe card, but I thought I had it covered by the TB3 connection to the monitor and the various USB flash drives I had under the monitor's USB-C hub. You were correct ! As soon as I booted with a USB-C stick in one of the TB3/USB-C ports of the PCIe card and the monitor connected to the other one everything worked great, as you can see from the attached screenshot.Also hotplug functions as intended.

BTW, after making some cosmetic changes in your SSDT, I performed some tests and I noticed that even if you use a small USB-C hub with nothing attached to it, the card WILL populate the USB-C port and hotplug WILL work thereafter.

I have one last request, which will satisfy my OCD ... Is is possible to modify the existing SSDT, or create a new one, that will fix the entry highlighted in the attached screenshot (XHCI from the LG monitor) for cosmetic purpose ? I am attaching the current registry status - if that helps.

Thanks again, especially for your very fast response.
Regards,

Vassilis
 

Attachments

  • Screen Shot 2019-04-09 at 21.02.57.png
    Screen Shot 2019-04-09 at 21.02.57.png
    1.2 MB · Views: 71
  • Working!.ioreg
    16.8 MB · Views: 58
Status
Not open for further replies.
Back
Top