AMD GPU on 10.14 with no iGPU: many issues

[TheBloke]

[ref]TheBloke[/ref],

if you are intent on using the imacpro1,1 smbios then perhaps you need to continue investigating whether shikiGVA values are even needed... since the vega is natively supported in that SMBIOS you probably should run without WEG at all.. should not need it to turn on functionality

 

I'm not using shikivga with iMacPro 1.1. My two tested methods are:

1. iMacPro 1.1, with boot arguments: dart=0 kext-dev-mode=1

2. iMacPro 14.2, with boot arguments: dart=0 kext-dev-mode=1 shikigva=96 shiki-id=Mac-7BA5B2D9E42DDD94

But yes, I haven't tested iMacPro 1.1 without WEG entirely. Or rather, I haven't since I set CSM to disable. In the past when I've tried no WEG it's failed hard, but that was before I got the card working natively on the H77. You are right that's worth a test, and I will try that now.

The other thing I'm going to test - with no hope of any change - is Catalina. I'm in the process of making a backup of my install to another SSD which I can safely try Catalina on without impacting any of my main installs.

 

in the Mac the fruit company uses many different video handling frameworks... and in systems with shared dGPU and intel, quick sync takes the load in the iMacpro, where they could simply throw it at the ATI, the T2 chip gets involved ..

 

Yeah there are certainly plenty of possible problem areas. However, the genuine Mac Pro crowd are using shikivga=96 with h264 encode with seemingly no problems at all, including some using Vega 64s. So it should be possible in theory. I suppose there must be some other difference between real Mac HW and simulated Hack HW that's causing these problems. Maybe even some other EFI-related issue.

I know other Hack users are using Vega 64 with HW accel with no iGPU, eg there's Pavo on InsanelyMac who uses 2 x E5-2670 v2 which have no iGPU, and is the same generation as my H77 (Ivy Bridge), with a RX Vega 64, and he says he has everything fully working, including HW accel. Although whether he's tried hitting the H264 encode as hard as I am, I don't know. And of course he has a much more powerful system than mine.

That could even be another factor: performance. Maybe the GVA framework expects a certain level of performance, and my crappy 4-core i5 system simply isn't keeping up? And once it fails to do so once, the card never recovers. It could be something along those lines anyway - some timing issue. The fact that the failures are not predictable with regard to timing - it could be 1 minute, it could be 6 minutes before the first failure - does point to something variable rather than concrete. Though I did get the same kinds of crashes on the X58, which is quite a bit more powerful: 6 x cores at up to 4Ghz.

I hope to be getting a new workstation fairly soon. Still can't decide what to get exactly, but a HP Z840 is definitely looking possible. That would put me on Haswell, with 16+ CPU cores, and a much more recent UEFI BIOS. I'm pretty confident things should work OK in that, based on what I read of other people with similar systems. But I don't have the time to do all the necessary research right now, so it'll probably have to wait a few more weeks before I can buy anything.

In the meantime, assuming neither -wegoff nor Catalina performs any miracle, I'll likely be running the H77 in Windows to do encoding there. That is if I don't just return the Vega 64 entirely, ready to get a different GPU when I do finally get a new workstation.

At least I can say I've advanced my Hack knowledge and experience somewhat in the last week, even if I've not so far achieved any config I'm happy with, and spent a vast amount of time in the process

[duece]

[ref]TheBloke[/ref],

I think that perhaps the easiest fix would be if someone could figure out a dsdt patch to mimic our onboard PEG slot and make it look like the GPU is connected via TB3 (which is just pcie) and mimic and external GPU box

we just can't find a combination that allows us to load and match the right kexts and frameworks to both run our chipsets with powermangement while matching and loading the correct graphics driver and video processing apple frameworks ... so until we either find the right combination of SMBIOS, patches, and board-id combo (provided one even exists) or clover gets smarter we are stuck.. since nobody is really programming toward this older hardware .. we a screwed...

its funny .. hackintoshing started because we wanted hardware that was more future proof.. yet the community abandons older hardware almost faster than apple these days...

[TheBloke]

I think that perhaps the easiest fix would be if someone could figure out a dsdt patch to mimic our onboard PEG slot and make it look like the GPU is connected via TB3 (which is just pcie) and mimic and external GPU box

 

For some definition of 'easiest' It certainly might work.. whether it's easy sounds like a whole different question. Certainly sounds complex to me. But yeah, for an expert maybe not.

Trouble is, as you say, none of the experts are bothering with this old hardware any more. If I had money I'd be tempted to offer $100 to someone like vit9696 to try and investigate a solution. But of course, if I had money to throw around, I could just buy HW that didn't have the problem to begin with

With regards to Clover, there is now an alternative: OpenCore. I know nothing about it besides that it exists and that some developers are moving towards it. I don't even know if it supports legacy. But it might be interesting to try for a UEFI system at least; seems like maybe it has more new development going into it.

I tried your suggestion of WEG disabled and long story short, HW accel eventually crashed the GPU in the same way.

Not having WEG did change a few things, for example DP1 had no signal, but HDMI1 did, and so did DP3. But DP3 would flicker and sometimes go blank (without any accompanying errors in Console). Felt like maybe it was choosing the wrong Framebuffer or something, which possibly could have been fixed with a Clover FB patch. But given it had the same HW accel crashes, I didn't test any further.

I also tried Catalina, on a separate drive. I was impressed that Catalina installed very painlessly. I didn't even have to upgrade Clover to get as far as the update completing (I forgot to update Clover before starting). I then installed Clover 5070 on a new USB stick to boot into Catalina for the first time, and it was all there and working pretty smoothly. A few third party app issues; the Screenflick screen recording app won't work at all, just throws a numbered error as soon as I try to start recording. ffmpeg compiled with Homebrew segmentation faults immediately, even after having been recompiled from source using XCode 11.0. But downloading a snapshot from the ffmpeg website worked.

Of course, I get the same GPU hangs on HW encode in Catalina as well. I expected nothing else at this stage.

But I now appear to be in a situation where the errors/crash take somewhat longer to come. It took about 45 minutes of constant HW accel encode/decode in Catalina - combined with constant running of the Heaven benchmark to load up the GPU - before it crashed. Then the next time it was about 30 minutes.

That's not new in Catalina though. Before running Catalina I had a similar result in 10.14.6. On a whim I tried adding back in -rad24 and -raddvi, which I used to use but had removed on account of them not seeing to change anything, besides the colour depth info listed in System Information.

The first time I changed that I really thought I had it fixed: whereas the crashes had come after 2-6 minutes before, I ran for 40+ minutes of running Screenflick to record at 60 FPS, plus ffmpeg to encode h264 to h265, before finally it went down.

Oh, one minor difference in Catalina is that after the errors came and the displays froze, a shutdown -r via SSH did actually reboot the system, eventually. To be precise, on the next boot I got one of those "Your computer was restarted because of a problem" messages, talking about "watchdog timeout: no checkins from watchdog in 95 seconds". So it might have been that shutdown killed the watchdogd which caused the kernel to auto reboot. The next time it went down I tried issuing a sleep, which did shut down the displays and eventually resulted in the system not responding on ping, but it never actually powered down. Not surprising.

Another useful and pertinent Catalina change: Activity Monitor now has a % GPU and GPU Time column, as well as a GPU History graph:

https://i.imgur.com/kgBczmd.png' alt='IMGUR>'>

Somewhat useful.

Anyway, no light at the end of the HW accelerated tunnel for me. Starting tomorrow I actually need to get some damn work done, so I'll probably just go back to the config I had before this week's frustrating testing: main X58 system using the R9 280X, H77 in Windows 10. I suppose I'll get some small benefit from the H77 now having the Vega 64 8GB instead of its previous NVidia 760 2GB, but if I can't do HW accelerated Premiere Pro exports, it's going to be a marginal benefit at best.

Ho hum!

[TheBloke]

[ref]duece[/ref], you may be right about things getting worse with 10.14.6.

My X58 is back to the config it had been in for the past year, with the 7970Ghz/R9 280X connected to 5 monitors. This requires a sleep on boot to get a picture on all monitors (or in fact, on any monitor, since 10.14.5), but after that it is pretty solid.

But in the last week I've had several occasions of the GPU hanging, just like I saw with the Vega 64. Same set of Console errors related to IOAcceleratorFamilyv2, especially the fence_timeout error, and mentions of GPURestart.

The first time it happened was on Sunday, when I was still testing HW encode/decode in my other machine, the H77. Suddenly out of the blue the X58 hung. I rebooted it, and it got into a situation where it was hanging minutes after boot, every time.

My first thought was that the major thing I'd changed recently was my config.plist and DSDT.aml, using the updated files that mald0n provided. So I reverted to my previous config, that I'd been using for the past year or more. But it kept freezing shortly after boot.

So I went back to the mald0n config/DSDT, and also made some tweask to my OC, thinking that might have been different. And the issues went away.

Since Sunday it had been stable again, until this morning. I usually leave the PC on all night, but with the monitors turned off at the mains. I turned them on this morning, all got a picture, but nothing in the GUI would respond. SSHing in revealed the usual set of errors, and I had to reboot.

Since I rebooted it hasn't gone down again, although there was a brief GUI freeze of 1-2 seconds, during which another load of errors appeared in Console. But this time - and I think for the first time ever - it actually recovered and now seems OK.

At this point the only thing that I can see that is different is that I'm now on 10.14.6.

What I don't get is the randomness of it all. Running for days then freezing out of the blue, when the system isn't even being used. And last week, running for 24 hours without a hitch after I put the R9 280X back in, then after it froze once, it then kept freezing within minutes of every single subsequent restart. Then after I tried various combos of old and new configs, and ended up back on the config I was already using, it just started working again.

God knows what's going on. But the sooner I get some new, UEFI HW the better I think.

It does make me wonder if I should test the H77 with Vega on 10.14.5, to see if it makes any difference to the HW encode/decode freezes I could not get rid of. No time to do that at the moment, but maybe when I've finished my current project, I will. Though it will be depressing if that works, because that would leave me in the rut of needing an old version, not able to update.