AMD GPU on 10.14 with no iGPU: many issues

[TheBloke]

Hi all

I have two Hacks:

One: X58, Xeon X5670, legacy boot (Clover R4945), AMD RX Vega 64 8GB GPU (Gigabyte OC model). No iGPU. MacPro 5.1 SMBIOS.

Two: H77, i5-3550, UEFI boot (Clover R4945), AMD 7970Ghz / R9 280X 3GB GPU. No active iGPU (it's Intel 2500, not supported). iMac 14.2 SMBIOS.

Both are running macOS 10.14.6.

On both these systems I have problems with AMD graphics:

 

2. On both systems: from boot, I get black screen on most or all GPU ports. Console log is full of errors, in particular "CRITICAL ERROR : VBLANK interrupt has not been generated in time!", and Activity Monitor shows 100% CPU on kernel. To resolve these issues, I must sleep & wake. After first sleep, I get a picture on all monitors.
   
   • On RX Vega 64 on X58, this problem is even worse: I get black screen on all monitors, and trying to sleep the system will cause it to hang. The only way I can sleep is by booting with no monitors connected to any GPU port. With this done, there are no Console errors, and I can put the system to sleep, then wake it, then I will have a picture on all monitors.

[*]On both systems: I have no HW h264/h265 encode/decode. This is shown by apps such as Video Converter Pro and MacX Video Converter Pro. Also, playing a 4K video in eg VLC will show very high CPU usage (300-500%)

[*]On X58 with RX Vega 64 only: my 4K monitor sometimes won't connect at 4K@60hz. I am using Displayport 1.2 cable, and in Windows 10 it's fine, and also was fine on my older R9 280X GPU. But with Vega 64 in macOS, sometimes it connects at 4K@60, sometimes it's 4K@30, and sometimes it's 2840x1080 @ 60. I don't yet know what causes it to sometimes work, sometimes not. Today it took me literally 2 hours of rebooting to get it to come up in 4K@60hz.

 

On the X58 system I am using WEG 1.3.2 and have InjectATI set in Clover; I need both of these, otherwise I did not get full performance from the Vega 64 in Geekbench (without WEG+InjectATI: 148k Geekbench 4 Compute score; with WEG+InjectATI: 205k GB4 Compute.) I run WEG with -raddvi and -rad24 settings.

On H77 system I am also using WEG 1.3.2, but i don't know if this is changing anything; I get same issues with and without WEG.

I have tested with every possible combination of graphical settings I know about - WEG on/off; InjectATI on/off; every possible WEG option; Clover Framebuffer patching; and more. Nothing I have ever tried can resolve any of these issues.

I am sorry for posting so many issues here, but I have spent literally many days trying to solve these problems, and have got nowhere. I have posted many times on InsanelyMac forum, but no-one seems able to help.

Right now I have a workaround for problem #1, ie I can sleep & wake to get all monitors working. It is quite annoying and slow on the X58/Vega 64 system, because I must boot without any monitors connected, but it does work. And problem #3 (4K@60) only happens sometimes, and once I have it fixed I can simply not turn off the PC to avoid it happening again.

So the one problem I have no workaround/solution for is #2 - missing HW encode/decode. I know other AMD users have working HW encode/decode, but I don't know why it doesn't work for me.

If anyone has any ideas for any of these issues, I would be so grateful. I have spent so much time testing/debugging/researching, with no luck.

Thanks in advance.

[MaLd0n]

[ref]TheBloke[/ref], without IGPU u need use iMacPro1,1 smbios

[duece]

@Mald0n

Why would iMac Pro be the best choice here for x58 hardware without IGPU?

the x58 is essentialy identical to a Mac Pro 4,1/5,1 and I have used the Mac Pro 5,1 definition in a very stable 10.11.6 albeit with a gtx660

I too am having issues moving this install to a mojave install with a vega 56

same black screen issues and what seems to be universally reported amongst both windows users and real Mac Pro 5,1 users of black screens at various times?

I have also read that people are having issues with Vega and get resolution by disabling CSM mode.. however the DX58so has UEFI boot, it has no bios options for it other than turning UEFI boot on and off... and I believe its booting in a CSM since this was a very early board with UEFI booting and needed to be kept compatible for Windows use obviously ..

I have full speedstep, sleep, wake, and very stable with 10.11 and mac pro 5,1 .. would love to have the same with mojave

I assume you are suggesting iMac pro due to the Vega? but how will it handle the chipset, LPC, non usb3, ICH10 etc of the X58 platform as its nowhere near a nehlam/westmere architecture ?

thanks!!!

Added in 2 minutes 40 seconds:

[ref]MaLd0n[/ref],

sorry didn't do this right in the first post.. just to get your attention Mald0n .. thanks

[TheBloke]

@Mald0n THANK YOU! I have searched for days for help on this and in one sentence you move me so much further forward!

My X58 system is now a lot better. Not perfect, but much more workable than before.

So, this is what has changed on my X58 system as a result of setting iMacPro 1.1:

 

2. HW encode/decode works, both h264 and h265. Playing a 4K video in VLC now uses 15% CPU instead of 500%!
4. If I boot with only one monitor connected, to port DP1, then that monitor gets a picture, and the system works perfectly. No errors, no slowdown, perfect.
   
6. However I need to use multiple monitors (I have 5 in total: 3 DP, 2 HDMI->DVI). I still cannot boot with these other monitors connected. If any other monitor is plugged in when I boot, then I will have same issue as before: black screen on all monitors, many errors in Console (including GPU hang), and cannot sleep. In this situation, only option is to reboot.
   
8. So, to get my system working I must follow this procedure:
   
   • Boot with only one monitor connected
   • When system has booted, put it to Sleep
     
   • When it shuts down, then connect the other 4 monitor cables, and wake
     
   • Now I get a picture on all 5 monitors, and everything works fine
     

[*]This isn't ideal, but it's still a lot better than before. Before I could not get a picture on any screen, so I was going in blind - I had to do the sleep by SSHing from another computer. Now I can see what I am doing, and eg it is much easier to apply upgrades because as long as only one monitor is connected, everything is perfect without the need to sleep & wake

 

So thank you again, already this is way better - especially having HW encode/decode!

Unfortunately, going to iMacPro 1.1 has made no difference on my second system: H77 with AMD R9 280X. I still need to sleep & wake to get a picture on all monitors, and there is no HW h264 encode/decode. It seems that switching to iMacPro 1.1 has made no difference in this second system (before it was on iMac 14,2)

If you have any further ideas I could try, either to get HW encode/decode on the H77, or further ideas for resolving the need to sleep & wake on both X58 and H77 systems, I would be super grateful.

But thanks already for your great help, I am so much happier now than I was before! Donation sent

[TheBloke]

@Mald0n

Why would iMac Pro be the best choice here for x58 hardware without IGPU?

the x58 is essentialy identical to a Mac Pro 4,1/5,1 and I have used the Mac Pro 5,1 definition in a very stable 10.11.6 albeit with a gtx660

 

I thought the same. It never occurred to me to try iMacPro 1.1 on this old system. In fact I had already tried some other SMBIOS a while ago, when trying to resolve issues with my R9 280X which was the GPU I had in this system until I bought the Vega 64 the other day. I tried MP 6.1, some Mac Minis, and some early iMacs. But it just did not occur to me to try a system as late as iMac Pro 1.1.

I am not an expert like Mald0n, but the impression I get is that the SMBIOS does not matter in the way we think it might. Certain functions will be controlled/manipulated by the SMBIOS, but it does not have a major effect like altering which drivers are loaded. It seems like any the OS will always load the appropriate kexts for the hardware found. However there may be certain kexts that behave differently depending on SMBIOS.

Anyway I can confirm that iMacPro 1.1 definitely improved this for me significantly on my X58. It's not perfect, but I am very happy to have HW encode/decode, and being able to see a picture on one monitor at boot is a lot better than going in completely blind, even though I still need to sleep & wake before I can use all the screens.

I would definitely recommend trying it and seeing how it goes. What I do with these sort of tests is boot from a USB stick on which I setup the new config. Then if anything goes wrong, I can just remove the stick and boot from SSD to revert the config.

Also be aware, if you didn't already know, that changing the SMBIOS may change your MAC address, and thus reset any static IP config you have and/or cause you to get a new IP from DHCP. At least it did for me. Though it's possible I could have avoided this by preserving the MAC address. I just used Clover Configurator to generate a new SMBIOS config, which I think changes the MAC address at the same time. This confused me a lot the first time I tried changing SMBIOS, at a time when I was getting no pictures on any monitor - I was trying to access the system by SSH to remotely put it to sleep (sudo pmset sleepnow), and when I first booted with MP 6.1 SMBIOS, I couldn't SSH in, so I thought changing the SMBIOS had caused the system to crash. Later I realised the system was up the whole time, just my statically assigned IP was no longer in use.

Secondly, if you are signed in to iCloud with an Apple account, you will get signed out and be asked to sign in again, and it will think you're on a new Mac. When I logged in to my normal user account on iMacPro 1.1 I needed to re-sign in to iCloud, which required sending a security code to another logged-in account.

If you're worried by all this, then another thing I can recommend is getting some back up software and backing up to a second drive. I have a spare SSD of roughly the same size as my main one. I use the backup app Superduper! to do backups now and then from main to second. This means that at any time I can choose to boot from the other drive (eg using a Clover USB stick), and then I can try changes like this firstly on the second drive. I often do that when I'm about to install a macOS update, so I can check if it breaks anything before I apply it to my main drive.

Good luck!

Apart from that, I have noticed no differences at all so far from changing SMBIOS - well, except for things working better on the X58!

[duece]

[ref]TheBloke[/ref],

yeah.. things are always changing in the hack community and I am far from an expert .. I have been hackintoshing since the day apple went to intel though.. again.. don't necessarily understand everything and hence I only like to do it every couple years when I am forced to

that said

it is my understanding that for a fully functional hack.. it all starts with the SMBIOS .. everything.. and I mean everything starts off with the apple model identifier ..and that coupled with smc starts threading and matching all of the required kernel and kernel extensions together..

the first rule of thumb in hackintoshing use to be ensuring to start with an smbios definition and a chipset/cpu combination that closely represents an actual mac model .. and that everything builds from that

now what clover is capable of doing under the hood.. and what its capable of translating between what the smbios says and how the hardware is connected to the kernel I can't answer.. but perhaps today its more important to get the GPU squared away than the cpu and chipset architecture but that makes no sense to me

anyhow.. if a real mac pro can plug a vega in and apple says its a supported configuration , and the x58 chipset is a dead ringer for mac pro 4.1 5.1. I have to think that getting that square peg into a round hole sounds far more doable ..

personally since the real macs that have vega and specifically the mac pro crowd having issues now to.. I suspect its a problem with apples driver more than our clover configurations... whatevergreen also is not tailored to our chipsets as much as the IGPU architectures of more modern macs which means we have likely got to do more in the custom SSDT / DSDT in order to get the VEGA dialed in.. but to have the rest of the system stable is a priority and can't see how a system definition for what 8th generation intel CPUs is going to reign in our HASWELL or GULFTOWN

oh .. and watch out for clover configurator.. it use to be a good deal.. but lately its a pain in the ass..

I am finding that its hiding and or not showing me what is really going on in the plist for starters

and when it builds the smbios its filling in WAY too many fields... for instance .. its hard coding your preferences for bios version.. well.. if that gets updated and you update clover.. and forget to go in an manually update your bios version ... clover will not over-ride it with the correct value and best case it wont let you update, worst case, as happened to me.. the apple code will RUN the firmware update.. and it semi-bricked my DX58 by somehow setting values in nvram that I can't get at and wipe our or reset..

sure it looks pretty when clover configurator fills in all those boxes but my understanding is best practices is now to just define model, serial, UUID, ROM, etc .. the things that serialize your iMessage.. and leave the rest to clover

Added in 24 minutes 45 seconds:

[ref]TheBloke[/ref],

I am of the opinion after much reading that similar issues that are plaguing the windows crowd are what we are seeing here too

I think that people that seem to be making progress here are embracing the deinit value to help fix up the handshake issues.. and signal sync

additionally when things were working better under 10.14.5 .. I was noticing that both my displays were identified as 30bit color.. thats a laugh.. I am using a 15yo gateway fdh2400 1980x1200 and a dp 1.2 to HDMI to a cheap sieki 4k tv that again I know is not 30bit.. both are 24 at BEST.

this further reinforces speculation in the windows community that the card fails to handshake EDID properly ..

now with the less mature and more generic drivers and WEG letting these loose value float.. perhaps they were really negotiation finally at 24bit after some back and forth but if apple has tightened up driver control and the report is 30bit it might be forcing 30bit.. hell the iMac pro panel IS 30bit.. so it would make sense for apple to put more weight to that value .. but pushing a 30bit color depth signal at a 24bit panel and disregarding the panels response of 'I CANT HANDLE THIS' results in what we are seeing

many are suggesting that using native NVRAM with some of the latest aptiomemoryfix debacles are resulting in erroneous nvram and possibly corrupted memory values.. I was using UEFI boot on the DX58so BUT emulated nvram and it has been flawless for 3 years.. no issues pushing 4k, wake, sleep, etc more stable than my macbook .. so I might try a fresh install with UEFI boot, but emulated NVRAM and setting boot args for SHIKI and -rad24 with some additional edits to the GPU0 ssdt / dsdt and see if that doesn't clear up some of the video issues

Added in 5 minutes 11 seconds:

[ref]MaLd0n[/ref],

MaldOn

back several years ago.. it was all about custom DSDT .. and I have a pretty good one that while isn't probably 100% clean.. has been rock solid for years

now it seems clover is pusing for using NATIVE DSDT to the greatest extent possible, hot patch, hot rename and SSDT to drop offending DSDT devices and re-add them through SSDT ...

so what are your thoughts.. on this older generation DX58so .. with a modern VEGA GPU ... still hardcode a good DSDT or go the new 'modern' route?

clover has changed so much in the last couple years.. hell..my chipset being from 2008 ... clover should be smart enough by now to run it without any user intervention or customization but that sadly doesn't seem to be the case

[MaLd0n]

[ref]duece[/ref], iMacPro1,1 generate hardware accel for processors wiithout IGPU, is not best for u, but without IGOU we live with dilema

Added in 37 seconds:

[ref]duece[/ref], [ref]TheBloke[/ref], extract files, ill check

--Run_Me

RunMe.app

[TheBloke]

To answer one of my own questions: I have done further research and discovered that HW encode/decode is impossible on my 7970 Ghz / R9 280X.

I found a long Macrumours thread where real Mac Pro users are getting h264/h265 encode/decode working (using Lilu and WhateverGreen haha!), and they have tried multiple 79XX cards and cannot get the HW h264 to work with them. They believe that Apple simply haven't written support for it into the drivers for these older cards.

It appears the earliest card that can support h264 is the Polaris line, eg RX 400 series and above.

I will probably just have to boot my second system into Windows when I need to do video work on it. Or maybe I will buy a cheap, used RX 560 or something.

The last issue I have remaining is whether there is any way to boot my X58 with Vega 64 with more than one monitor connected.

dueca you are right that real Mac Pros can do this without all these issues. There are even people using Clover on a real MP to boot into MP's legacy CSM mode so as to be able to see boot screens. Which makes me think that maybe there is a solution out there that can work even on my legacy boot X58 system. But what that solution is, I have no idea, and literally tens of hours of testing and research has got me nowhere.

In the meantime I am very happy with using iMacPro 1.1, the first positive change I've had in my setup in a long time. Having HW encode/decode is awesome, and getting a picture on one monitor from boot is a lot better than the zero monitors that I got with the 'proper' MP 5.1 SMBIOS. Worst case if I can't progress beyond this point, at least now I have a usable system with a boot-up procedure that only takes a couple of minutes.

[TheBloke]

Thanks a lot @mald0n. I am trying to run RunMe now. Unfortunately it seems to be getting stuck:

Generating system info, this may take a while.
Saving IOReg...
IOREG dump failed. Retrying
Increased delay x2 for IOREG dump. This will take a while...(33 sec)
IOREG dump failed. Retrying
Increased delay x2 for IOREG dump. This will take a while...(33 sec)
IOREG dump failed. Retrying
Increased delay x2 for IOREG dump. This will take a while...(33 sec)
IOREG dump failed. Retrying
Increased delay x2 for IOREG dump. This will take a while...(33 sec)
IOREG dump failed. Retrying
Increased delay x2 for IOREG dump. This will take a while...(33 sec)
IOREG dump failed. Retrying
Increased delay x2 for IOREG dump. This will take a while...(33 sec)

 

It is repeating that over and over, in an endless loop.

I can see IOReg appearing on screen then disappearing 30 seconds later. I also got a prompt about "RunMe wants permission to control System Events", and I said Yes to that. Screenshot of Security & Privacy for RunMe

What should I do?

I need to go to bed in a minute but I will try and get the logs to you when I am up in ~8 hours. Thanks again for all your help so far.

[duece]

[ref]MaLd0n[/ref],

thanks Mald0n .. next time I yank the gtx660 out and put the vega back in and do a fresh install I will dump the lot

would you like to see my current dsdt for the DX58so that is running the 10.11.6 install? that I can get you quicker..

this is a boot arg I tried with clover 5070, 10.14.5 or possible 6 before suppclimentarys I forget... but before things went really sideways..

boot-args="shikigva=96 shiki-id=Mac-7BA5B2D9E42DDD94"

Using a HDR 4k test video in HEVC my processor W3680 hex core went from 99% and lots of dropped frames and artifacting to butter smooth, no dropped frames and less than 5% CPU... i.e. GPU decode ... I fired up either handbrake or quicktime.. can't recall, and it was offloading tasks to the GPU to speed up encode as well.. I think it was handbrake using the video toolbox encoder .. had some issues with artifacts on the 4k video after wake though..

Added in 2 minutes 3 seconds:

another thing and again.. could be cosmetic could be an issue as what WEG is doing under the hood is not well documented but in addition to getting the color bit depth of my monitors wrong .. WEG also shows my video card as negotiating the PCI-e at 8Gb/s thats a neat trick on a pci-e 2.0 interface run by the x58 that caps at 5Gb/s

another issue.. my brain is getting soft from age and 3+ years ago on this current hack is a long time to remember specifics.. but I recall doing some edits, possibly in apple kexts, possibly in fakesmc.. but I was doing something to fine tune interrupts if I recall, I had also a LPC injector kext as the dx58so LPC device ID was not compatible with the apple kext and not patched by clover

I think LPC might be fixed but I am still putting the LPC injector kext in L/E but I can't recall where or if other edits were made on controlling the interrupts.. but I am almost certain I did

[MaLd0n]

[ref]TheBloke[/ref], if use mojave need a extra permission

Added in 11 minutes 25 seconds:

[ref]duece[/ref], post ur dsdt here, ill put lpc

[TheBloke]

[ref]MaLd0n[/ref], OK thanks a lot.

I have attached my RunMe ZIP.

Note: I have added one extra log file to the ZIP: KernelLog.BootWithMultiMonitorConnected.txt. This log file shows kernel log messages when I boot the system with more than one monitor connected. It shows many errors about GPU hanging/crashing.

Reminder of my remaining issue:

X58 system with Gigabyte RX Vega 64 GPU, using iMacPro 1.1 SMBIOS: If I boot with only one monitor connected to DP1 port, everything is fine. No errors, systems runs perfect. But if I boot with any other monitor cable connected, I get no picture on any monitor, many errors in Console logs (shown in KernelLog.BootWithMultiMonitorConnected.txt), and I cannot put the system to sleep. System has to be rebooted at this point.

If I boot with just one monitor connected, then put system to sleep, then wake, then other GPU ports work and I can connect the rest of my monitors.

So question/issue is: any fix I can make that lets me boot with all monitors connected, and does not need sleep & wake to get GPU to work fully?

Thanks very much again for all your help.

 

Send me Marvin.tom.tj.zip

[duece]

[ref]TheBloke[/ref], [ref]MaLd0n[/ref],

gents...

bloke.. I assume you are running 5600 bios on the DX58 right? I have to update my bios to 5600 (was running 5599 forever with el cap install) ... the VEGA would show nothing without it...

5600 release notes

PRODUCTS: DX58SO (Standard BIOS)

About This Release:

• Date: July 31, 2013

• SATA RAID Option ROM: 11.1.0.1413

• LAN Option ROM: Intel® Boot Agent PXE GE v1.3.65

• LAN Option ROM: Intel® Boot Agent PXE Base Code (PXE-2.1 build

089)

New Fixes/Features:

• Updated processor support.

• Improved compatibility with the latest video cards.

Additionally , bloke, I was thinking about your multi monitor issues.. and Mine too.. especially no/corrupted video at all on HDMI port single monitor, or when plugging one into HDMI and one into DP, that black screens the lot...

perhaps the iMac pro frame buffer is being pushed, and I doubt that the port id, signal type, etc.. the port identities are likly nowhere near a vega reverence board.. and since the latest update as focused on improving the vega / iMac pro combination again perhaps apple has optimized the AGDP and other vega drivers / port specificity that introduce issues for reference boards?

adding the shiki board-id for the iMac pro may also introduce the same incorrect frame buffer post 10.14.6? perhaps disabling AGDP completely is the way to go? I notice that on Mac Pro 5,1 when I look at the AGDP heuristic values in ioreg it shows 2, and they are both nvidia part IDs ... so while ADGP is loaded, its not matched.. and likely shouldn't be... but if we force AGDP to load and match with the imac pro and its latest VEGA drivers have the wrong frame buffer and port ids that no longer match our configuration... well it breaks the chain

the only way we get this working is to masquerade how apple is providing support for desktops that don't have INTEL IGPU CPUs running the VEGA as internal (not external PCI-e boxes) on the approved list... and that pretty much is ONLY the mac pro 5,1 that is the ONLY platform that

1> has our chipset

2> has our processor families

3> has PCI-e expansion

4> has vega as an approved internal dGPU option

now seeing that real mac pro users, windows users are having similar issues, this my not be solved until ATI/AMD possibly push a firmware update for the Reference card, and apple addressed the real mac pro crowds issues.. the latest install issues .. many are caused my improper metal/opencl calls in the post install setup windows that crash out the graphics card so you can't complete the upgrade without using an older native graphics card (also issues with their firmware updater windows that don't effect us)

Mald0n

Notice the release date... 2013

this is about the same date as heart bleed... do you think that the microcode was patched for it here?

If not.. the real mac pros have had several microcode updates since 2013.. some of the firmware updates were APFS related but it also clearly was pushing microcode updates.. and even MORE specifically several of those firmware boot rom updates screwed up xeon Wxxxx implementation ...

so another QUESTION... lest assume that the latest boot rom for Mac Pro ...144 .. has different microcode than my current DX58so since apple has pushed at least 2 updates specifically targeting Wxxx xeon.. so with clover reporting that I am on 144 .. would the kernel have microcode optimizations and calls that if used with the DX58so / W3680 ... without those microcodes ... cause issues... ? or is clover injecting the current apple bootrom and related microcode at boot after identifying my processor (which it does correctly identify)?

apple Mac Pro boot rom/firmware summary

BootROM Version Released with: Type: Note:

MP51.007F.B03 Mac Pro EFI Firmware Update 1.5 General release First public released Mac Pro 5,1 firmware update

MP51.0083.B00 10.13 DP5 Beta Beta APFS support

MP51.0084.B00 10.13 DP6 and 10.13.0 General release Initial APFS support

MP51.0085.B00 10.13.4 and Mojave DP1 to DP3 General release APFS support

MP51.0087.B00 10.13.5 General release Missing microcodes

MP51.0089.B00 10.13.6 General release Spectre/Meltdown mitigated microcodes on the April 2 Microcode Update Guidance.

138.0.0.0.0 10.14 DP7 and 10.14.0 General release 5GT/s support for every PCIe 2.0 card

139.0.0.0.0 10.14.1 DP1 Beta minor updates and corrections

140.0.0.0.0 10.14.1 DP3 and 10.14.1 to 10.14.4 General release NVMe boot, minor updates and corrections

141.0.0.0.0 10.14.4 DP2 Beta minor updates and corrections

142.0.0.0.0 10.14.4 DP4 and 10.14.5 DP1 Beta Updated APFSJumpStart EFI module - W3xxx Xeon bricker

144.0.0.0.0 10.14.5 DP4 and 10.14.5 General release lot's of corrections, booting improvements. This is the current BootROM release

[TheBloke]

[ref]duece[/ref], I do not have that motherboard. I have a Gigabyte GA-X58A-UD3R. The BIOS will be from 2010 or so, the last time it was officially updated.

There are some third-party BIOS updates for the Gigabyte X58 motherboard line, which update SATA firmware and also provide the latest CPU microcode, with Spectre/Meltdown mitigation. I've not installed one, because TBH I don't really want my system to get even slower with the spectre fixes.

There's no mention of any GPU-related fixes in these unofficial BIOS', and I'm not really sure how the BIOS could affect a dedicated GPU anyway in a legacy boot system? The GPU works fine in Windows of course, so it's not a general issue. Only with macOS.

By the way, earlier today I tried the shikigva=96 line you mentioned - booting with an MP 5.1 SMBIOS - and that I saw for the first time yesterday in the MacRumours thread. That does indeed enable some HW accel. Specifically, it enables h264 encode and decode, but not h265. That's according to VideoProc, the software I use to check the encoding status (it's just a GUI wrapper to ffmpeg I think).

This does make me wonder if there's another shiki-id value that could be used to enable h265 as well.

I don't know if I will necessarily need h265 any time soon, but it's nice to have it anyway. So for now I will stick with iMacPro 1.1, as this gives me h264 plus h265 encode without needing the shikivga line, and it also seems to solve my 4K@60 issue; when I booted with MP5.1 to test shikivga, my 4K monitor went back to 2048x1080 as I was experiencing before. However this boot did tell me one more thing: that even with MP 5.1, it seems that I can boot with 1 monitor connected and get a working picture. I thought that iMacPro 1.1 enabled that, but it seems like I never tested booting in MP 5.1 with only a monitor connected to DP1. It was just luck that the first time I tried iMacPro 1.1 I happened to use only that port, for the first time!

So to summarise:

With MP51 + shikigva=96 line, I can get boot with 1 monitor connected, then sleep & wake to get all. I get h264 HW accel, but not h265. But my 4K monitor won't reliably connect at 4K@60hz

With iMacPro 1.1, the boot + sleep/wake is the same. I get both h264 and h265 HW accel. And the 4K monitor is reliable at 4K@60.

But I have found a new problem: it seems like my h264 HW encode is not reliable I was trying a media export in Premiere Pro, using HW accel on h264. It ran fine for about 5 minutes, then suddenly the screen froze. I could still move the mouse pointer, but nothing was updating. Logging in with SSH showed errors like this:

2019-09-18 12:33:05.543 F  kernel[0:9bc2] (IOAcceleratorFamily2) void IOAccelFenceMachine::fence_timeout(IOTimerEventSource *): AMDRadeonAccelerator prodding blockFenceInterrupt
2019-09-18 12:33:05.558 F  kernel[0:8f66] (IOAcceleratorFamily2) virtual IOReturn IOAccelEventMachine2::waitForStamp(int32_t, stamp_t, stamp_t *): a graphics error occurred, exitting..

 

I rebooted and tried again, with the same result.

I am currently booted into Windows to try the same encode in Premiere Pro, to rule out it being a problem with my GPU itself (which I bought used). If it works fine there, then the next thing I will try is MP51 + shikivga, just in case that makes any difference.

Of course it was too good to be true to think that everything might just be working OK now...

[duece]

[ref]TheBloke[/ref],

the boot args I was using with the Mac Pro smbios included the board id for iMac boot-args="shikigva=96 shiki-id=Mac-7BA5B2D9E42DDD94"

so this does 2 things, it enables those shiki options but also masquerades the GPU board id of the iMac pro.. theoretically getting the best of both worlds.. the system control of a 5,1 with the GPU calls of a imacpro

the one arg I need to add is likely the -rad24 .. how are your monitors listed in the system profiler under graphics 30 bit color or 24? in my case again .. WEG is not assigning the correct color depth to either monitor .. I think when I was booting with WEG removed, the VEGA was still being correctly recognized, displays worked and color depth was 24 but sleep was less reliable.. I think I did those tests during the initial install at 10.14.5 ..

I am convinced with the right DSDT/SSDT for the VEGA, the correct boot args.. I can and should remove WEG which is really being optimized for CPU generations sandy and higher to deal with CPU based IGPU issues.. not our case of PCI-E dGPU .... and using 5,1 smbios will the the winner eventually

Added in 9 minutes 57 seconds:

[ref]TheBloke[/ref],

another thing I might try since the graphics were much more stable for me under 10.14.5 before I updated way to early to 10.14.6+

I might try using AppleGVA.framework from the 10.14.5 after updating to 10.14.6 if the next fresh install of 10.14.6+ shows no improvements..

the real Mac Pro crowd confirms that framework did change and any of them that were using a hex patch to get encode/decode working had to re-do the patch and might have had to find the new hex addresses to make it work.. I think that hex patch just does the same thing as the boot args.. not sure

[TheBloke]

[ref]TheBloke[/ref],

the boot args I was using with the Mac Pro smbios included the board id for iMac boot-args="shikigva=96 shiki-id=Mac-7BA5B2D9E42DDD94"

so this does 2 things, it enables those shiki options but also masquerades the GPU board id of the iMac pro.. theoretically getting the best of both worlds.. the system control of a 5,1 with the GPU calls of a imacpro

 

Yeah, this is the same shiki-id that the Mac Pro users are using over on the MacRumours thread. That's the line that gives me h264 but not h265, so for whatever reason it appears it's not quite equivalent to booting with iMacPro 1.1.

 

the one arg I need to add is likely the -rad24 .. how are your monitors listed in the system profiler under graphics 30 bit color or 24? in my case again .. WEG is not assigning the correct color depth to either monitor .. I think when I was booting with WEG removed, the VEGA was still being correctly recognized, displays worked and color depth was 24 but sleep was less reliable.. I think I did those tests during the initial install at 10.14.5 ..

 

Yes, I have this issue as well, and have been using -rad24 for a long time. Well, I say 'issue' - I have never 100% confirmed that it causes any problems, besides listing the displays as 30bit in System Report. I have tested with and without it, and the only thing that appears to change is the info in System Report. But I leave it in in case it's doing some good that I can't immediately see; it certainly doesn't seem to be doing any harm.

 

another thing I might try since the graphics were much more stable for me under 10.14.5 before I updated way to early to 10.14.6+

I might try using AppleGVA.framework from the 10.14.5 after updating to 10.14.6 if the next fresh install of 10.14.6+ shows no improvements..

the real Mac Pro crowd confirms that framework did change and any of them that were using a hex patch to get encode/decode working had to re-do the patch and might have had to find the new hex addresses to make it work.. I think that hex patch just does the same thing as the boot args.. not sure

 

I started all my Vega 64 testing on 10.14.5, and at one point was dual booting between a 10.14.5 and .6 install to check for differences. I couldn't find any, so I eventually upgraded my main install to .6 yesterday.

I have a backup from a couple of months ago that would still be on 10.14.5 so I theoretically have the ability to test stuff on 10.14.5 again if it proves necessary. But all my testing so far has shown no difference for me between those two versions - everything that worked on 10.14.5 also worked on .6, and likewise everything that was broken on one was also broken identically on the other. Although I only tried the shikigva line today, so I haven't tested that method on .5.

[duece]

[ref]TheBloke[/ref],

when you say 10.14.6 are you talking what build g97.. the latest with both supplementary updates or the base 10.14.6.. there have been at lease 2 supplementary updates since 10.14.6

I have read multiple threads where with WEG, you can either have DRM or encode, but not both at the same time.. seems nobody has broken the code to figure that one out yet with whatevergreen

[MaLd0n]

[ref]TheBloke[/ref], Arquivo Comprimido.zip

extract new send_me after reboot

old bios missing many devices, we need create all

[TheBloke]

[ref]MaLd0n[/ref],

OK, I rebooted with the DSDT.aml and config.plist you provided, and here are the new RunMe files. Thanks very much for looking at this!

 

Send me Marvin.tom.tj.zip

[duece]

[ref]MaLd0n[/ref],

following!!!

[TheBloke]

[ref]TheBloke[/ref],

when you say 10.14.6 are you talking what build g97.. the latest with both supplementary updates or the base 10.14.6.. there have been at lease 2 supplementary updates since 10.14.6

 

I am on 18G95 - I assumed that that was the latest, given I only applied the update yesterday, and no further updates are shown as available? (Besides macOS 10.15 beta)

EDIT: Yes, found confirmation that 18G95 is supplemental 2, the latest version.

 

I have read multiple threads where with WEG, you can either have DRM or encode, but not both at the same time.. seems nobody has broken the code to figure that one out yet with whatevergreen

 

For me, I think both are working. Certainly h264 and h265 encoding are OK, I tested today via Handbrake. I do have the issue I mentioned earlier where h264 encoding in Premiere Pro caused a GPU freeze, which is not yet diagnosed or resolved. But in general, both HW encoding and decoding appear to work.

As for DRM, I've tested Netflix in all of Google Chrome, Firefox and Safari. In Safari I hear sound but I just see a red screen. But it works fine in Chrome and Firefox. I also tested Amazon Prime streaming in Chrome, which also worked OK. Both with Netflix and Prime, I checked ACtivity Monitor while playing a video, and CPU usage was low, which I believe indicates the decoding was being accelerated. Also in Chrome I see a process called "Google Chrome Helper(renderer)" and another "Google Chrome Helper (GPU)" using small amounts of CPU while playing videos.

I think that shows DRM is working fine? It's not something I really use much, as I have another computer for watching streaming/movies etc.

EDIT: After doing some more Googling, I'm not sure my Netflix test prove that DRM works. The fact that it doesn't in Safari seems like a common issue, which obviously I haven't solved. And the fact that it does work in Chrome/Firefox possibly doesn't prove anything, given that I've read that on these browsers, it defaults to 720p rather than 1080p. There's a browser extension for Chrome that is meant to remove this restriction, but it's no longer on Play store and I can't be bothered to try installing it manually from Github.

I have now also tried some iTunes movie trailers, which played fine at full screen, with minimal CPU usage. I don't know if this proves anything or not, given they're only trailers? I'm not going to buy anything to see if that works

[duece]

[ref]TheBloke[/ref],

yeah. sorry g95 latest. end of aug supplemental .. slip of the keyboard fingers..

I just did a fresh instal of 10.14.6 g95 with unbeast clover 4930 I think

pretty much no options selected in config.plist and no DSDT .. just plain vanilla and just fakesmc and internet kexts

the system will boot and get graphics on my dp>HDMI to 4k TV... no hardware accel obviously and sleep no go.. but surprisingly IOREG has most things loaded so clover has improved a ton over the years

the standard aptiofix for tonycrap on this installer is plain aptiomemoryfix-64 I think and I get native nvram (whether its fully complete and working who knows)

once I plug in the HDMI to my regular monitor I get no video on the DP and the hdmi monitor is solid green

trying out WEG just for giggles if I can get it to force load from the ESP kexts folder otherwise I am going to run.me and sent this in to Madl0n to take a look at

macpro5,1 smbios

[TheBloke]

once I plug in the HDMI to my regular monitor I get no video on the DP and the hdmi monitor is solid green

 

Sounds similar to what I see, except I've not seen any solid green. If I boot with only DP1 connected, everything is fine, but if any more monitors are connected before a sleep is done, then all monitors are black, and sleep fails.

If your situation is like mine, then sleep & wake is going to be your only solution for the time being (pending any magic from mald0n), and I doubt WEG is the difference between being able to sleep or not. You're very likely going to need a proper DSDT to get the ability to sleep.

Certainly I've needed a DSDT for a long time. I could get away without one in 10.11 and 10.12, but the first time I tried to upgrade to Sierra my system went haywire - not only wouldn't it boot, but every time I tried to boot, it changed all my BIOS settings to random values Which given I had a finely tuned and complex OC, was quite a big annoyance

Admittedly my HW is even older than yours, and not even UEFI. But still; being unable to sleep is a very common situation of not having a proper DSDT, from what I've read.

I eventually came back about 6 months later, and went straight to High Sierra, and this time learnt about doing things from scratch. I got a proper DSDT, thanks to a lengthy thread on InsanelyMac regarding the Gigabyte X58 series of motherboards, and that fixed sleep/wake, power management/speedstep, onboard audio, and a whole bunch more things.

Not sure why you'd need to force load WEG? Just put it into EFI/CLOVER/kexts/Other? Along with Lilu of course.

[MaLd0n]

[ref]TheBloke[/ref], check if sleep work, use power button for wake

DSDT._PRW.zip

[duece]

[ref]TheBloke[/ref],

I think part of the problem with this DX58so.. which has to be older than yours because it was Intels reverence board for x58 is that when they addd UEFI via a firmware update, its really no a full UEFI implementation

there are no settings for it in bios, no CSM on/off, no UEFI boot menu maintenance. hence one of my issues right now where clover put something into the rom of the board for a UEFI volume that doesn't exist and I can't get rid of it.. so I can't just let the motherboard boot to disk, I have to F10 to the boot menu on EVERY boot and choose the drive.. the one and only installed, otherwise it goes nowhere

I still think that this issue with the ports in 10.14.6 is solvable but likely instead of putting GFX in DSDT, likely a VEGA specific SSDT with proper port definitions, signal, etc from the RADION compatibility guide on how to figure all that out.. requires getting VBIOS dumps etc..