Vega Frontier Edition on High Sierra

[nefilim]

Just to follow up - the same thing is happening with a Radeon VII (ASRock) - looks like Apple screwed up their driver in version ~10.14.6?

Edited October 7, 2019 by nefilim

[nefilim]

cautiously optimistic with Catalina, both Vega 64 and VII appears to be stable ... so far 

[TheBloke]

1 hour ago, nefilim said:

cautiously optimistic with Catalina, both Vega 64 and VII appears to be stable ... so far 

Thanks for the update.  I tested Catalina b6 and had the same issue, but there were 5 further betas before it released this week, so finger's crossed they fixed something in those.

 

I've been meaning to try Catalina on a spare drive but haven't had time - hopefully tomorrow.  Once I get a chance to upgrade I'll do my concentrated stress test again, where I run Uniengine Heaven at full screen,  simultaneously screen recording it with h264 HW encoding, while also on another monitor playing a 4K h265 video with HW decoding.

[nefilim]

23 hours ago, TheBloke said:

Thanks for the update.  I tested Catalina b6 and had the same issue, but there were 5 further betas before it released this week, so finger's crossed they fixed something in those.

 

I've been meaning to try Catalina on a spare drive but haven't had time - hopefully tomorrow.  Once I get a chance to upgrade I'll do my concentrated stress test again, where I run Uniengine Heaven at full screen,  simultaneously screen recording it with h264 HW encoding, while also on another monitor playing a 4K h265 video with HW decoding.

 

After no incidents for more than a day... had 6+ crashes in 30 minutes ... just crashes a minute or two after logging and it's restoring apps, something is triggering it. Super frustrating. It's under fairly minimal load for GPU, I've never been able to trigger it with heavy load. I captured a nice dump with GPU state on 10.14.6 .... was tempted to create a bug report for Apple with that (someone did it before, from a hackintosh and they actually looked into it). Maybe I'll try to capture the same 10.15. 

 

Back to my RX580... need to get actual work done....

Edited October 10, 2019 by nefilim

[TheBloke]

Damn.  Got the notification of your message just as I started a backup of my 10.14.6 install to a new blank SSD in preparation for upgrading it to Catalina!

 

I will do it anyway and try my luck, but expecting nothing of course.

 

I could understand issues with the Vega, but I'm amazed that the VII has the same problems, as that's an officially provided Apple GPU.  Or at least it will be, I suppose the Mac Pro isn't actually out yet.   So maybe it is a Hack-specific thing and not just bad GPU drivers.

 

Certainly the guys over on MacRumours seem to be getting working HW h264 encode/decode, and h265 decode OK, on their original Mac Pros and various recent AMD GPUs including the Vega.  They either use Lilu + WEG to set shikivga=96, or else they hex edit the driver kext to add their MacPro Mac-Id to the list of systems that it will enable AMD HW accel on.

 

I will do some testing of my own and report back.

[nefilim]

On 10/10/2019 at 11:55 AM, TheBloke said:

Damn.  Got the notification of your message just as I started a backup of my 10.14.6 install to a new blank SSD in preparation for upgrading it to Catalina!

 

I will do it anyway and try my luck, but expecting nothing of course.

 

I could understand issues with the Vega, but I'm amazed that the VII has the same problems, as that's an officially provided Apple GPU.  Or at least it will be, I suppose the Mac Pro isn't actually out yet.   So maybe it is a Hack-specific thing and not just bad GPU drivers.

 

Certainly the guys over on MacRumours seem to be getting working HW h264 encode/decode, and h265 decode OK, on their original Mac Pros and various recent AMD GPUs including the Vega.  They either use Lilu + WEG to set shikivga=96, or else they hex edit the driver kext to add their MacPro Mac-Id to the list of systems that it will enable AMD HW accel on.

 

I will do some testing of my own and report back.

 

The Vega 56 & 64 are supported products as eGPUs (https://support.apple.com/en-us/HT208544) - my Sapphire Vega 64 is specifically named there even. 

 

What baffles me is that some people have none of these problems at all? What makes me wonder even more is that both my cards (Sapphire Vega 64 and ASRock Radeon VII) show these problems, what a coincidence? Is it something else? I know pastrychef at tonymac has the same mobo as me, had an MSI Vega 56, not sure which VII he has but apparently no problems, very little differences in EFI folders... 

[TheBloke]

I finally got my H77 onto Catalina and, unsurprisingly, I've eventually hit the issues while encoding in Premiere Pro.

 

At first things looked a little more hopeful.  I re-ran my stress test, of running Heaven full screen at 1920x1080 while recording it with macOS built-in screen recorder using h264 accelerated encoding, while also using ffmpeg to encode h264 -> h265, and watching a 4K h265 movie in VLC.     That ran for 75 minutes without problems, longer than it ever has before, and I ended it myself.   Then I left ffmpeg encoding h265->h264 in a loop for 2+ hours while I was out.

 

But then as soon as I tried a Premiere Pro export, it went down within 10 minutes.  Usual set of errors in Console (as seen through SSH).

 

I'm thinking I'll try restoring the AMD kexts from a 10.14.5 backup and putting them into a 10.14.6 install.   Might fail immediately due to changes elsewhere, but you never know.

 

As for why it doesn't work for us.  Wish I knew.  One possibility is that the people who aren't having problems aren't making heavy use of HW accelerated encode/decode?    Maybe if all you do is watch the occasional video, it's fine.  Certainly when I ran ffmpeg in a loop for 3+ hours today it was OK.    The problems come when I do stuff like screen recording and, in particular, Premiere Pro export.

 

If not that then I don't know.  I suppose it could be something subtle, like related to the number of monitors connected, what resolution they are at, etc.  My H77 has three screens connected right now, though I've also had the problem occur when two were connected.  Don't think I've ever tested with only one connected, but a lot of people do only use one monitor. 

 

Actually speaking of that, I noticed an error I'd not seen before when I woke the H77 from display sleep this evening, an HDCP error:

2019-10-12 20:47:24.180002+0100  localhost kernel[0]: (AMDRadeonX5000HWLibs) [3:0:0] AMD Error:
2019-10-12 20:47:24.180009+0100  localhost kernel[0]: (AMDRadeonX5000HWLibs) Failed HDCP: status 4

It repeated a couple of times while the monitor was waking up, then went away.  The monitor got a picture just fine, and I would never have even known there was the error if I hadn't had the logs streaming via SSH.  It might be completely unrelated.  I mention it just as another example of some small detail that could be different between people who have and don't have problems.

 

I might try the 10.14.5 kext test later and will report back on that.

[TheBloke]

2 hours ago, TheBloke said:

I'm thinking I'll try restoring the AMD kexts from a 10.14.5 backup and putting them into a 10.14.6 install.   Might fail immediately due to changes elsewhere, but you never know.

 

Interim update: no luck so far.

 

I mounted a backup I took in June when I was on 10.14.5  I used About This Mac -> System Report -> Extensions to see all the extensions I had loaded, and browsed through the list to see which might be graphic related.   Then I copied all these from the backup to a temporary directory.

 

So far I have done two tests.

 

Test 1:  I copied AMD*.kext from 10.14.5, which in practice meant I reverted to 10.14.5 on:

• AMD10000Controller
• AMDFrameBuffer
• AMDSupport
• AMDRadeonX5000
• AMDRadeonX5000HWLibs
• AMDRadeonX5000Services

 

Test 2: After that failed in the usual way, I also reverted to 10.14.5 on:

 

• IOAcceleratorFamily2

 

I had a good feeling about that one, because it's the kext that appears in 95% of the Console error messages I get,  eg "(IOAcceleratorFamily2) void IOAccelFenceMachine::fence_timeout(IOTimerEventSource *): AMDRadeonAccelerator prodding blockFenceInterrupt".

 

But no dice there either.  Still failed within 5 minutes of starting a Premiere Pro export.

 

There's a couple more kexts I've not yet copied over, like IOGraphicsFamily and AppleGraphicsControl.  Tomorrow I'll put those over as well.  But of course I'm not hopeful.

 

If this doesn't work, then it could be it's something in another kext, one that's not obviously GPU related.  Or something in the kernel itself.  Or it could just be that I would have had the issue on 10.14.5 as well - I never actually ran 10.14.5 with a GPU capable of HW accel, so I don't know if it would work, I'm just trying this based on hearing from others that things were better in .5.    And certainly I know some things are definitely worse on .6, like on my X58 legacy hack where I am getting a lot more weird issues since I upgraded to .6, including periods of time where I have to reboot five or six times in a row due to repeated screen freezes, with the same sort of errors we are seeing with the Vega.  Even though the X58 is using a 7970Ghz / R9 280X which has no HW encode/decode available.

 

Very frustrating.

Edited October 12, 2019 by TheBloke

[TheBloke]

I think I'm pretty much done with testing now.  No progress.

 

I carried on the 10.14.5 kext restoration until I'd copied over all kexts seemingly related to GPU stuff into 10.14.6.

 

Then I went the full hog, and wiped that SSD and restored the entire 10.14.5 backup.

 

I get the same freezes in 10.14.5 as I do in 10.14.6 and Catalina 10.15.0, so, at least on this system with this GPU, I can say that 10.14.6 has made no difference at all.  As far as I can see, the same problems exist for me prior to .6 as well.  

 

I can't easily test 10.14.4 even if I wanted to, as I went straight from 10.14.1 to .5, so I'd have to do a fresh install.  But anyway, the MacRumours guys say 10.14.5 is the first version that supports AMD encode/decode.

 

I tried a couple more things.  Firstly I tried going back to WEG 1.2.8, the version that the MacRumours guys are using with their real Mac Pros to enable HW encode/decode.   But that won't work on 10.14.5 because of the purple lines on boot, causing it to never reach the login screen.  The first version that fixes that is 1.3.1, and I didn't bother re-testing with that as I already know 1.3.2 the same issues, so I can't believe it suddenly got broken by 1.3.2.

 

I also tried reverting my SMBIOS to iMac 14.2, and enabling HW encode/decode with shikigva=96 shiki-id=Mac-7BA5B2D9E42DDD94.   This gives H264 encode/decode and H265 decode, but no h265 encode.  It fails on a Premiere Pro h264 export almost immediately, just like with using iMacPro 1.1.

 

So I'm out of stuff to test really.   I guess all I can do is cross my fingers that when I eventually get a new PC - hopefully in the next month - it will magically not have these issues.  Maybe it works better with other SMBIOS or something.   I really don't know.

 

I had been thinking I might need to splash out and replace my Vega 64 with a VII, but now even that is in doubt based on your results, @nefilim, so I don't know what to think.

 

I might try posting on Reddit and other forums, just on the offchance anyone has got further.  You mentioned a user on Tony's, so I take it you've already posted on there without any joy?

Edited October 13, 2019 by TheBloke

[nefilim]

Thanks for the update @thebloke - what a bummer. I just find it so strange that there are so few others and that it is happening with both my cards. Did you read this saga? https://www.tonymacx86.com/threads/success-screen-freezes-using-sapphire-radeon-vega-64-nitro-in-macos-mojave-10-14.262778/page-15

 

I don't think bent CPU pins are my issue But maybe a few more small things to try. 

 

[nefilim]

some updates: Vega 64 has been running nicely after a few small tweaks, I think the most important one was changing from iMac18,3 to iMac19,2 ... to more closely mimic my CPU, the CPU power management is working more better, throttles down much more when appropriate. no go with VII ... i should probably try macpro1,1 

 

upgraded motherboard to Z390 (needed more slots anyways) ... the same story, Vega 64 still appears stable but VII freezes almost instantly every time

 

[TheBloke]

Glad to hear things are working better for you, at least with the Vega.

 

When you say it's all working well: are you doing any extended HW encode/decode work, especially anything like HW accelerated Premiere Pro or Davinci Resolve export?  Ie stuff that is 5-20+ minutes of continuous HW encode, alongside reasonably high CPU usage, and probably decode and other GPU activity in parallel.

 

That's what kills it for me every time.  In other general usage, I think it's pretty solid, although I haven't done a huge amount of general purpose testing on that system with the Vega.

[TheBloke]

Hey @nefilim I have today made a key discovery:  this problem affects me much more when I use DisplayPort.

 

I've spent the last days doing a lot more further testing.  This led me to replace Clover with OpenCore, to upgrade to Catalina 10.15.1 beta1, beta2 and beta3, to play around with various UEFI options, and a lot more.  Nothing helped, until I stumbled upon a forum post from 2018 where someone was having similar problems in High Sierra, but said they only had the issue when using DisplayPort.

 

My H77 system has three monitors connected.  Initially, this was two HDMI plus one DisplayPort.   The DP monitor also supports HDMI, so I changed the cable and.. boom.  Or rather, no boom.  Now my Premier Pro and Resolve exports work just fine.

 

When using DP, Premiere Pro would trigger the GPU freezes within 2-3 minutes.  I've now done over 90 minutes of Premiere exporting without a single hitch, plus about 30 minutes in Resolve.

 

EDIT: Removed the rest of what I wrote here.  In summary, I wrote a bunch of stuff about being confident it was all good now, as long as I only used HDMI, then came back 2 hours later to say "it's frozen again".

 

I am trying a new test, with a config change based on a hunch, and it's currently looking a little promising.  Not going to say any more until I've got more confidence, because I don't want it to be another case of "It's working! Oh no it's not." 

 

So all I'll say for now is I have two DP + 1 HDMI monitors connected, and I've been encoding to H264, alternating between Premiere Pro and Resolve, plus also with an ffmpeg H264->H265 going on in the background, for the last 1 hour 45 minutes, without freeze or problem.

 

I'll update again as and when I have firm news, good or bad..

Edited October 26, 2019 by TheBloke

[TheBloke]

After five weeks, I think I finally solved it.

 

Behold, the magic that allowed me to leave Premiere Pro running overnight encoding a 7 hour video, resulting in a 55GB H264 file, with ffmpeg in the background encoding H264->H265 on a loop:

<dict>
	<key>Comment</key>
	<string>Disable AppleGFXHDA</string>
	<key>Enabled</key>
	<true/>
	<key>Identifier</key>
	<string>com.apple.driver.AppleGFXHDA</string>
	<key>MaxKernel</key>
	<string></string>
	<key>MinKernel</key>
	<string></string>
</dict>

That is OpenCore config.  I thought it was possible to stop kexts loading in Clover as well, but having researched it and checked Clover Configurator, I think maybe it is not.  So for Clover, you could either move /System/Library/Extensions/AppleGFXHDA.kext, or probably a Plist patch could be made to stop it loading.  I haven't investigated any of that yet.

 

With that done, you will get no HDMI or DP audio.  For me, that's no problem, because both my systems have USB sound cards.  I literally never used the HDMI/DP sound, but it was always connected.  And somehow this was causing all my problems - and maybe yours, too, @nefilim.  And I've confirmed that it doesn't matter whether the DP/HDMI audio outputs are actually selected in Sound Preferences; just the fact that they exist is enough to trigger the problem.

 

Today I have rebooted to toggle AppleGFXHDA back on and off about 6 times, and every time I boot with it disabled, everything is fine, and everytime I boot with it enabled, I will get the errors and GPU freeze within 3 - 8 minutes, 100% reproducible. 

 

I don't know why HDMI/DP sound causes a problem, nor why it's a problem for me and seemingly not many other people.  Could be something specific to the GPU, or something specific to my Hacks.  I'm going to post in the WEG thread and ask them about it.  It's quite possible there's some other solution, better than just removing AppleGFXHDA completely.   Like maybe an SSDT injection that changes the HDA property/properties for the GPU, or just removes it, which might be a more elegant solution than disabling AppleGFXHDA.

 

I only tested this on a whim  I noticed that recently, since I've not been using my USB soundcard in recent tests (I don't have all USB ports working with my OpenCore config yet), sometimes when the system froze and I got the usual flood of Console error messages, there would be IOAudioFamily messages spamming at the same time, and even more of those. Like this:

2019-10-26 20:29:50.818255+0000  localhost kernel[0]: (IOAudioFamily) + IOAudioEngineUserClient[<private>]::performWatchdogOutput(<private>, 53364) - (8b0,17dc)
2019-10-26 20:29:50.818278+0000  localhost kernel[0]: (IOAudioFamily) - IOAudioEngineUserClient[<private>]::performWatchdogOutput(<private>, 53364) - (8b0,19dc)
2019-10-26 20:29:50.823501+0000  localhost kernel[0]: (IOAcceleratorFamily2) void IOAccelFenceMachine::fence_timeout(IOTimerEventSource *): AMDRadeonAccelerator prodding blockFenceInterrupt
2019-10-26 20:29:50.823637+0000  localhost kernel[0]: (IOAudioFamily)   performClientOutput(8b0,1ad4) - missed samples (8b0,19dc). fCurrentLoopCount=8a6
2019-10-26 20:29:50.828858+0000  localhost kernel[0]: (IOAudioFamily) + IOAudioEngineUserClient[<private>]::performWatchdogOutput(<private>, 53365) - (8b0,19dc)

I figured that was probably to be expected and a symptom, not a cause - after all, if the GPU is dead, then GPU sound outputs would also timeout.   But then as part of my extended Google trawls, I found an old post where someone was describing GPU freezes, and claimed that using the WEG command line argument igfxnohdmi helped them.   That's an iGPU flag that "disables DisplayPort to HDMI conversion for digital sound", or something like that.  It wouldn't do anything for my AMD GPU, but reading that, combined with my recent learning that my problem was much worse with DP ports connected, made me think to disabling GPU sound completely.  And that was it.

 

Sorry, you didn't really need to know the creative process I'm just stoked that after 5 weeks I've finally beaten this thing.

 

I've tested this in both 10.14.6 and 10.15.1b3 and the result appears to be the same, so I've done all further testing on Catalina.  I now have an accumulative total of about 12 hours of Premiere Pro and Resolve encoding without errors since I disabled GFXHDA, and that's with 2 DP monitors connected.

 

My next step is to put the Vega in my X58 and see if the results carry over to that.  I'm still going to face the annoyance of having to unplug all but one monitor whenever I boot it, but I'm crossing my fingers that if I put up with that, then after that it will be smooth with no freezes, as long as GFXHDA is gone.  

 

I hope some of this can help you out too

[nefilim]

@TheBloke what a rockstar!!  thank you for your persistence and follow up!! 

I just read a thread on reddit a few days ago mentioning disabling audio for Vega but haven't had a chance to look into it .. wrestling a disabled Messages currently after changing SMBios a few too many times I guess, may have to try my luck with Apple Support  Good motivation to switch to OpenCore and very keen to try this on my Radeon VII which has total no go. I also use USB audio exclusively and 2 x 4k DP monitors 

 

ps. not ready to fully switch to Resolve?

pps. a 7 hour encode?? sounds like a whole season of episodes  

Edited October 27, 2019 by nefilim

[TheBloke]

You're very welcome - hope it solves the problem for you as well.

 

Seems there's some hope it might.  Today I put the Vega in my X58 legacy hack, and as this machine is still on Clover I disabled AppleGFXHDA by simply moving it out of /System/Library/Extensions, then ran Kext Utility.

 

So far, so good with regards to stability to HW encoding.  I've done various Premiere Pro and Resolve tests, including leaving Premiere encoding for over an hour.  No errors, no freezes.

 

EDIT: It's now past midnight, the card has been in for at least 12 hours, and still going strong.  I've been doing a bunch of H264 accelerated screen recording using OBS, and no problems at all.  I'm confident in calling this problem resolved for me.

 

I do still have the bevy of problems that seems to inevitably come with using a modern GPU on a legacy system, and which are noticeably worse with the Vega than they were with the R9 280X I was using before.   Even with the R9 280X I got no picture on any monitor from boot and had to SSH to issue a sleep command, then wake it up to get all monitors working.  With the Vega, I additionally have to unplug all but one monitor when booting, otherwise the system will fail to sleep, and will eventually crash and have to be restarted.   With only one monitor connected I can sleep & wake the system and then all monitors work. 

 

Or rather, they all work except for the 4K DP, which has further problems.  macOS always detects it OK, but the monitor itself usually reports no signal.  I have to unplug and replug it, sometimes three or four times, before the picture appears.  Once it does appear it's then fine, unless display sleep kicks in, so I've had to disable that.

 

I leave this system on 24/7, so reboots are rare, so all of that is not too much of a problem.   I do turn all my monitors off at the mains when I go to bed, so I expect to find that each morning I will have to do the unplug/replug a few times to get a picture back on the 4K.

 

So that's all quite a bit of hassle, but worth it to have a fully working system with decent GPU and HW acceleration.  It hopefully won't be an issue for too long, as I'll will finally be getting a new PC sometime in the next month.  And at least now I can be pretty sure that I can put the Vega in it and have it work right.

 

On 10/27/2019 at 8:55 PM, nefilim said:

ps. not ready to fully switch to Resolve?

pps. a 7 hour encode?? sounds like a whole season of episodes   

 

I'm likely going to try Resolve for my next video project.  I only started making videos a couple of months ago, and started off using Premiere + After Effects.  But now I've learnt a bit and researched quite a lot, I see why people are talking a lot about Resolve.   I'm definitely going to try it out, although I do remain concerned about how inflexible the UI is.  I have 5 monitors and I make use of three of them in my standard Premiere setup, which is just not possible in Resolve - unless of course I buy a special BlackMagic PCIe card that would allow using an entire monitor as a timeline display.   I love the flexibility of Adobe UIs, so going to something quite as rigid and limited as Resolve appears to be is my main concern about switching.  However the speed and reliability benefits would of course be welcome.

 

Although, I'm not sure reliability is actually there right now with Resolve - at least not in the latest code.  I was browsing the Resolve forum last night and read a three page thread of people complaining about all the terrible bugs in the newly released 16.1, calling it a disaster.  Which I have to say somewhat matches my early experiences.  I keep getting rendering failures on trivially simple projects, like just throwing three H264 files into a timeline and rendering it without any effects, transitions or anything else.  This seems to be happen far more when either the source or destination file are on a network drive.  It mostly works when all files are on the local SSD, though it's still happened once in that config.    There's no explanation for the error, it will be running fine then it suddenly stops with a message that says little more than "Rendering failed".   Rerunning the exact same render may work fine, or may fail earlier, or later. 

 

I also had a fun issue back when the H77 was still freezing regularly with the Vega;  it froze while Resolve was open, so I rebooted, and when I next opened Resolve, I couldn't see its UI.  The Load Project window appeared fine, and after selecting a project I would see the main Resolve window flash on for a split second, then it would vanish.  I could still see and interact with the menu bar, so I tried stuff like Reset UI, and toggling Dual Display on or off, but that did nothing.  Eventually I solved it by unplugging all but one monitor while Resolve was open, which obvioulsy forced it to redisplay the main UI window, and it was visible after that.

 

So perhaps I should roll back to 16.0 before I get stuck into Resolve too much, as learning new software while that software isn't working reliably is not a good experience.  But even through all that I can see some of the appeal - it's cool to be able to quickly flick back and forth between Cut, Edit, Fusion and Fairlight, and have it all integrated.

 

EDIT: Actually it's possible that one or both of these issues is specific to Catalina.  I've now tested rendering to/from my network drive on the X58, running 10.14.6, and I've so far not had the rendering failure at all.  Also I saw today someone who is also on Catalina 10.15.1 posted both issues on the Resolve forum, and a responder indicated it might be Catalina specific.  So I take back some of my condemnation for 16.1's stability, at least from my own experience

 

As for the 7 hour encode - that was purely a test My longest project is about 10 minutes at the moment.   After I first tried the GFXHDA disable, I wanted to leave a long encode running overnight to further test stability, so I made a new sequence and added all my existing sequences to it, and then did Select-All+Paste, Select-All+Paste, over and over until it got to 7 hours  

 

Actually this process of testing has shown me how slow Premiere is.  On my H77, using H264 source clips and encoding with H264 hardware accel, it was rendering at about 70 FPS; which is barely faster than real-time for my 60 FPS footage.  Both Resolve and Final Cut Pro, rendering an identical sequence with identical (or as close as possible) encoder settings, rendered at an average of 175 FPS.   Coming over to the X58 which is older but has more cores, a higher clock speed and double the RAM of the H77, Resolve was still at 175 FPS (which may well be the limit of the H264 encoder itself), but Premiere improved to ~90 FPS.  Still way down on Resolve though.

Edited October 30, 2019 by TheBloke

[nefilim]

@TheBloke just to report back, looked promising for a few hours on my VII, rebooted and it froze again, rebooted and immediately froze again

 

At least I migrated to OpenCore and my Z390 is much happier than with Clover. Vega64 is still really solid. 

 

oh also I switched to iMacPro1,1 - no iGPU anymore ... everything seems to work ok, including h264 & h265 appears to be using the GPU for encoding rather

Edited October 30, 2019 by nefilim

[TheBloke]

Oh I'm sorry to hear that So you confirmed that AppleGFXHDA was not loaded, and that you had no HDMI or DP sound outputs shown in Sound Preferences / Audio MIDI Setup?   Given it happened after a reboot, just wondering if something accidentally changed on the reboot, that re-enabled sound or something. 

 

If not that, then maybe there's yet some other issue with the VII, or a different trigger at least.  Weird

[nefilim]

24 minutes ago, TheBloke said:

Oh I'm sorry to hear that So you confirmed that AppleGFXHDA was not loaded, and that you had no HDMI or DP sound outputs shown in Sound Preferences / Audio MIDI Setup?   Given it happened after a reboot, just wondering if something accidentally changed on the reboot, that re-enabled sound or something. 

 

If not that, then maybe there's yet some other issue with the VII, or a different trigger at least.  Weird

 I did verify (kextstat) that the AppleGFXHDA kext was NOT loaded (blocked by OpenCore) .... though to be honest did not check Sound Preferences. I may try again with another SMBios ... that seems to have been the main thing for my Vega64. 

[TheBloke]

17 hours ago, nefilim said:

 I did verify (kextstat) that the AppleGFXHDA kext was NOT loaded (blocked by OpenCore) .... though to be honest did not check Sound Preferences. I may try again with another SMBios ... that seems to have been the main thing for my Vega64. 

 

So which SMBIOS were you using when you got the freezes?  iMacPro 1,1?  I've had no problems with that SMBIOS on either my H77 or X58, and I've seen posts from quite a few other people using it on various HW, but I suppose this could well vary with the exact HW in use.

 

When these freezes occur, are you SSHing and confirming they're exactly the same as before, eg a flood of IOAccelerator messages starting with IOAccelFenceMachine::fence_timeout?   Just wondering if it could be some other issue, related to switching to OpenCore.  I've actually put my H77 back onto Clover for now, because I have a couple of issues that I can't currently be bothered to fix.  USB ports issues for one, which are a common problem and I believe are easy to fix, but also a problem with the Realtek gigabit NIC, which keeps disconnecting randomly and throws up PCI errors in Console logs, which I assume is related to missing DSDT/SSDT stuff.    I will likely try to fix those at some point, but for now I've reverted the H77 to Clover.  The X58 I haven't even attempted to put on OpenCore yet, because I know it requires a lot of DSDT patches else it will mess up the BIOS, and I don't yet know how to make those in OC (I'm pretty sure I can't just use the same DSDT.aml from Clover in OpenCore).

 

Anyway my point is that if you haven't already, I'd advise to confirm that the issue is definitely identical, from checking the Console logs, and also confirm it occurs also in Clover - you can simply remove /System/Library/Extensions/AppleGFXHDA.kext (move it to some other folder) then run Kext Utility, to achieve the same result of disabling that kext in Clover.  Just to rule out the possibility of new OpenCore-specific issues.

 

If all that doesn't help, then yeah maybe try an SMBIOS closer to your HW, then use the boot arg "shikigva=96 shiki-id=Mac-7BA5B2D9E42DDD94" to enable HW H264 encode/decode and HEVC decode (on 10.15 you won't get HEVC decode.)

 

Another thing that might be worth mentioning:  on my R9 280X GPU I found that remove AppleGFXHDA had no effect on whether I had HDMI/DP sound outputs.  I additionally needed to stop injecting AppleALC.kext.  Presumably therefore AppleGFXHDA only provides HDMI/DP on certain GPUs, probably newer ones.   I would be quite surprised if the VII didn't use GFXHDA, given it's even newer than the Vega 64, but I mention this just in case. In other words, if you definitely don't have AppleGFXHDA loaded, but you do still have HDMI/DP sound outputs visible in Sound Preferences/Audio MIDI Setup, then try removing AppleALC.kext as well, then re-test.

 

Good luck!

[nefilim]

@TheBloke No luck yet, been making sure my XCPM and AGPM are set up correctly. I did notice this though:

 

 

I made sure by moving the kext out of the way in /S/L/E and rebuilding the cache, checked again with kextstat after rebooting and sound preferences too. Still no luck but just thought I'd mention it to you.