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...

[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 again.. in windows .. the drives just point all encodode/decode at ATIs drivers .. simple 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 .. I doubt that ATI will bite the hand that feeds it, so I don't expect to see ATI release purpose drivers ... the only open architecture machine that apple officially/ unofficially support is the macpro5,1 .. that that special relationship is over now that the new machine is due for release... apple realized with the trashcan the professionals used pci-e cards and wanted/needed open hardware architecture .. so as to no loose the entire professional user base, many of which didn't upgrade to the trashcan.. they gave them just enough to drag them to this point but they are intentionally not providing hardware encoding for 265 which the card is more than capable of in hope of pushing new hardware .. plain and simple.. and I doubt that will change.. at the start of Catalina beta.. the 5,1 was going to be an approved machine, but when the new pro was announced and marketing starts making the calls, 5,1 is now dropped ... until someone hacks the video processing framework or writes a program that goes around the framework calls and deals with the card directly ... perhaps we will see something in the future but most devs don't deviate from apple frameworks...

[ref]MaLd0n[/ref], yeah. Intel shitty UEFI on this board. No CSM disable and I have to assume there is one since this board was mainstream what more than 6 years ago it would need it for windows. Only thing left would be a complete legacy boot to see if that improves. Or perhaps figure out how to dump the cards bios and have clover load it On the fresh test install that was put on a intel sata drive can’t get it to sleep period. Same OS X version same dsdt same config file etc as the one from last month and that one is sleeping. Mojave want me to tear my hair out.

[ref]MaLd0n[/ref], i agree... intel quick sync would be an answer.. if I had a motherboard chipset or CPU that supported it I am on a x58 platform (socket 1366) and a Westmere W3680 processor .. hence .. no intel quick sync due to no CPU embedded GPU .. hence all my questions as to why your DSDT has multiple GFX0 > PEGP > GFX0 etc conversions... only have one dGPU at PEG3 ... I define it as GFXO to give WEG the place to latch on have not tested your third DSDT yet but the previous 2 have no sleep and make no improvements over my already edited DSDT as far as VEGA booting multiple monitors perhaps you ran the wrong autopach against it thinking I had sandy bridge or something

[ref]MaLd0n[/ref], here are some of the gpu.restart dumps VEGA gpu.restart.zip

I noticed I think in your files you sent up that you have other cards installed in this machine .. not just the vega.. I found while testing that my machine didn't like some cards... without a specific edit in DSDT .. most times installing supported card would break sleep.. but for example.. now that mojave completely breaks support for SIL3132 based sata cards.. I went out an bought a support card that uses Marvel and ASM controllers... I can't boot fine with it installed into el capitan with the gtx660 installed .. but the same machine, same DSDT and config.. wont boot mojave.. black screen... BUT the system is running .. BIGGER BUT.. the card is working and the 3 drive apple raid hanging on it is WORKING.. the files are there but had to ssh in to see that .. no video... the VEGA is a very strange cat.. and SLICE was saying that there are known issues with later AMD cards and older chipsets.. likely no UEFI for you and a poor and old UEFI implementation for me.. because the same card installed in a $90 HP6300sff running mojave that took 15minutes to install mojave on .. .works just fine and doesn't block video from the installed gx710 .. I can even BOOT mojave off the $40 sata add in card.. it has 6 ports and its the only time I have ever seen an add in sata card boot OS X ... so the card is very compatible .. but on these old boards.. I think that most modern hardware is looking for UEFI support I know that with the DX58.. when I added the vega I was running bios 5599 from a long time ago.. like say 2012.. no video.. at all not even post if I recall.. updated to 5600 which was intel last bios from say 2013.. so still very old .. but obviously they updated the UEFI option rom for graphics cards because now I have video at post... in the old days apples hardware and COTS hardware were more similar and the OS X codebase was a bit more generically written.. today with the advent of allot of apple only tech like biometrics, T2, customized chipsets and integrated video and custom drivers and frameworks that arent used on the PC side.. hackintoshing has thinner margins for working hardware.. and 'working' is different .. lots of tradeoffs.. for example your woes with imacpro .. some of the hardware encoding that is done with that model lean HEAVILY on that T2 according to bearfeat, .. I think a lot of hardware offloading in macs is very difficult to get right in the hack because the frameworks send the work to chips we don't have .. on a pc the hardware encode would be VEGA only and the driver would send it all to the VCE stack.. in apple its drivers definitely don't work that way .. something else to consider.. since out bioses are years behind.. is that intel has been constantly releasing updated patches for their CPUs last few years as part of the security patches ongoing from heart bleed, and others that have not even been publicly released.. well apple pushes out these firmware updates with the releases and say for macpro5,1 which hadn't had many new firmwares has had like 4 in the last year... so if apples kernel is optimized for these new microcodes and we are not getting these microcode patches in firmware . the instruction sets don't match up... BOOM Added in 39 minutes 2 seconds: [ref]TheBloke[/ref], update my machine not liking the INJECT ATI with deinit when booted same way single monitor.. GPU fan full up, power bar on the card pulsates and I am using 200W at the wall instead of 120~ so clearly with macpro5,1 SMBIOS .. injecting is messing with GPU power management AND my luxmark scores are LOWER.. which makes no sense

[ref]TheBloke[/ref], in the 13-14 years I have been building these things I have never found one that gives me more than basic info on my intel boards.. gluten for punishment .. I have a badaxe 1 775, a badaxe2 775, and DX58so and they were all more difficult to hack than their gigabyte brethren .. I have a EP45 board and that one had pretty good sensor support.. if and when I do this again and abandon the DX58 which I really don't want to do because the W3680 is good enough for me... it will be a much more mainstream board with better support .. I am getting too old spending a month working 6 hours a night trying to get this ironed out [ref]MaLd0n[/ref], I have not been able to get sleep working on the fresh install, but went back to my previous attempt which was a fresh install to .5 or .6, used migration assistant to pull in my el cap drive, and was upgraded to .6u2 .. went back to just my basic DSDT from my old install, my old config.plist that has almost nothing turned on.. and I am back to having sleep. if I use the same procedures as the bloke.. I can boot the 4k60 TV at DP1 > HDMI adapter and pretty reliable, sleep wake, etc if I try and boot just the HDMI monitor, black screen with the system running behind it logging GPU.restarts in the console panic/spindump section if I boot with 4k60 and plug HDMI in , crash to black screen, system running.. can ssh in ect.. but sudo shutdown -h now just sits there.. wont turn off although drive activity ceases so I give it a minute and hard reset if I boot 4k60 with the other HDMI monitor plugged in but OFF, not sleeping, OFF, and get to the login screen, sleep the system THEN turn on the HDMI monitor and wake, I have both monitors and can continue to sleep and wake them as a pair.. testing short term only right now.. sleept it all night last night will update later not using darkwake in boot args which is strange since it only worked in the past with no or =0 .. using dart (even though VT-d disabled), SHIKI-96 SHIKI with imac boardid -rad24 (fix 30 bit color) been experimenting with ATI deinit in clover but inconclusive right now.. the epic fail on the reinstall and the old install might be clover above 5000.. I have read more than 1 thread now where some folks are having issues with it. I went back to 4932 and using aptiomemoryfix and booting UEFI, native nvram not using EMU and RC scripts, and for the moment it looks more promising but the VEGA monitor init issues are plaguing .. latest LILU/WEG/ALC although with my DSDT I get the VEGA video and HDMI audio without WEG. but can't turn on hardware encode decode with boot args without it.. would need to hex edit AGDP to get hardware support if I drop WEG if I use the iMacpro SMBIOS I loose speedstep and my multipliers are locked at 12 instead of stepping to 26-27 under load I will send you some of the GPU.restart dumps later.. and will send you a .dsl of what maciasl dumps from my running system.. perhaps you can dif merge with your patches and figure out where the sleep error lies.. at first I thought it was the USB method for _DSM .. mine uses store and yours uses return .. tried editing yours to store, didn't make a difference .. could be just the clover version.. doing more testing today if I can find the time thanks again for the help!!

[ref]MaLd0n[/ref], [ref]MaLd0n[/ref], I understand where you are going with it, but for example on PEG3 you had GFX0 and HDAU devices, then added PEGP in the same path also with GFX0 and HDAU and I think WEG latched on to the first instance. Graphics card was not showing up in you FABULOUS !! system profiler PCI listing man that is really nice!! So I was thinking that perhaps having multiple devices with the same name was throwing things off I am not at the computer at the moment but will test out later. Looking at the DSDT though, did you do the edits and patches of the NEW raw DSDT that was in the run.me zip or add/remove patches from my already patched DSDT? Only reason I ask is that I see old Toleda method HDEF patches that are likely no longer required using LILU/ALC and that probably should have stayed AZAL? and you added / or kept APRT in at PEX, and I really don't have that installed now. I also can't remember if I deleted more devices but see PS2K/M and perhaps the big one, serial port .. and that one has a NOIRQ that is like 1,2,3,4,5,6,7,8,9,..... basically taking every irq.. Also, the my old patched DSDT was one bios revision down... I had to update bios for the new graphics card. from 5599 to 5600 IIRC. the el cap install still seems to run fine with my old DSDT and clover config. also, I think I had some lengthly edits in the USB devices... I might have to have them in there for sleep... again can't remember. I notice at least one rename TMR to TIMR but left LCP instead of LCPB.. just wondering what kind of patching flags this DSDT is designed to run with ? should I be selecting Drop Unused for example? And do some renames on the fly? also there is a warning for and external value \UMAP at the start of the DSDT.. is that a SSDT table or some other external I need to have in my ACPI folder? muchas gracias senior ... really... sorry for the dumb questions.. trying to learn something as I go since you are far more skilled than I !! Added in 3 minutes 24 seconds: [ref]TheBloke[/ref], Man I am jealous of you guys that run the gigabyte boards... I get very little sensor data from the intel boards because of my chipset... not mainstream enough for the community to include my values!!! what does the clover boot.log say about your processor? it should recognize it.. and the x5670 was in real macs IIRC? perhaps you have selected something in clover configurator that is patching your processor and loosing native speed stepping ?

[ref]MaLd0n[/ref], 10.14.6 made no changes to the generic config.plist of the fresh install.. not my config.plist from my previous el cap no sleep either one your GFX0 implementation at PEG3 is a bit unusual ... perhaps not what you intended? I don't think that the EGPU device is even being picked up being overshadowed or GFX0 being grabbed by whatever green.. as it was able to do with no DSDT edits at all... Screen Shot.jpg.zip

[ref]MaLd0n[/ref], here you go Madl0n.. I have prided myself in getting by hackintoshing over the year, reading, trying but I have been banging my head on this for over a month... and getting nowhere. I would prefer to try the MP5,1 route first, since I have many expensive software packages tied to my MP serial number. but if we have to go the iMac Pro route .. well I will figure something out clover must have made great strides over the last couple years.. as I commented above.. this is a very vanilla install using multishit, and its generic 5,1 def. I only added ethernet kext and fakesmc and got 4k60 on DP, HDMI audio on that DP, and it looks like my cpu was being power and step managed. adding lilu,WEG,ALC got me line out on the alc889 without having a single line in the DSDT or patches in clover.. sleep obviously doesn't work.. and in both 5,1 and iMac pro , I only have 1 monitor, if I try to plug in or boot with the second monitor at HDMI, black screen, no signal , green screen ..etc I have included my previous DSDT for you to look at .. I don't use that airport card right now so it doesn't need to be in the final product.. this dsdt give me full sleep, wake with usb, graphics on gtx660, HDMI audio, alc889, it just works great.... with almost no patches in clover enabled.. I would like to get this 6 port sata card working though, I don't have it plugged in for this right now.. but it attaches at PEX1@1c1 and funny it took the ARPT label in ioreg when I booted into el cap with it installed. it has kept me from booting 10.14 though on this motherboard.. I can boot it on a different machine running Mojave just fine. .can even boot osx from it.,. so I know its compatible.. perhaps with a fully functioning DSDT and good interrupt handling it will be plug and play thanks again for your assistance!!! Added in 4 minutes 54 seconds: [ref]TheBloke[/ref], sounds like this might be un-fixable with current drivers post 10.14.5 I think perhaps we might want to consider either rolling back to that point release or figure out which kexts are offending and try and bring those forward into 10.14.6 ... I doubt we will see apple release any new meaningful updates to Mojave if history repeats.. this is now EOL for major updates... security fixes only probably Send me localagentsiMac.lab.zip DSDT mod.aml.zip

[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..

[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

[ref]MaLd0n[/ref], following!!!

[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

[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

[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

[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

[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 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