Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
iM 4,1-14,4 EnableGop: Pre-OpenCore GOP support for EFI-era iMacs and Mac Pros
- Thread starter Bmju
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
armdn
macrumors member
h9826790
macrumors P6
I only tested Radeon VII, but AFAIK, this can bring performance improvement to all GPU.
32x sounds a lot, but that's the absolute max from my own test. In other situation, may be "only" 16x improvement, or may be even less on other setup.
In reality, that may means the transition from one screen to another, speed up from 0.5s to 0.016s. Noted that the original time is still just 0.5s. For most poeple, it isn't that "unacceptable slow". So, most people may not feel that much difference. But if you pay attention to the screen, you may realise the transition finish almost instanuously after this update.
*** EnableGop 1.2 with GopBurstMode is now in pre-release ***
See the first few posts in this thread for how to obtain it before the OpenCore 0.9.1 release date.
A corresponding GopBurstMode quirk is new in OpenCore. It turns out Apple missed a trick - Intel processors of this era include a burst-mode cache setting which makes graphics operations noticeably faster, but Apple never turned it on in pre-boot EFI GOP.
Enabling this feature provides considerably faster GOP rendering on all EnableGopDirect (and OpenCore DirectGopRendering) systems; and should provide rendering speeds at least the same as before, and on some systems noticeably faster, on other supported systems. The GopBurstMode quirk itself is safe to use on newer systems - it detects whether burst-mode caching is already enabled, and if so does nothing - and on older systems - it recognises that it is not supported and does nothing - but it seems to be supported but not enabled by the BIOS on all EFI-era Mac Pros and iMacs.
The compressed driver for version 1.2 is slightly (1KB, 0x400 bytes) larger than version 1.1, so for AMD vBIOSes which are tight on space version 1.1 may be used instead to avoid the need to do VGA stripping to free up additional space.
See the first few posts in this thread for how to obtain it before the OpenCore 0.9.1 release date.
A corresponding GopBurstMode quirk is new in OpenCore. It turns out Apple missed a trick - Intel processors of this era include a burst-mode cache setting which makes graphics operations noticeably faster, but Apple never turned it on in pre-boot EFI GOP.
Enabling this feature provides considerably faster GOP rendering on all EnableGopDirect (and OpenCore DirectGopRendering) systems; and should provide rendering speeds at least the same as before, and on some systems noticeably faster, on other supported systems. The GopBurstMode quirk itself is safe to use on newer systems - it detects whether burst-mode caching is already enabled, and if so does nothing - and on older systems - it recognises that it is not supported and does nothing - but it seems to be supported but not enabled by the BIOS on all EFI-era Mac Pros and iMacs.
The compressed driver for version 1.2 is slightly (1KB, 0x400 bytes) larger than version 1.1, so for AMD vBIOSes which are tight on space version 1.1 may be used instead to avoid the need to do VGA stripping to free up additional space.
Last edited:
Great work on a good find.
Is this performance increase only effect EnableGopDirect or also EnableGop ?
I.e. Will it help GPU's other than AMD VII ?
EnableGop as well, and any cards potentially... I've already had back a report that EnableGop (usual, not Direct, variant) is noticeably faster with an M5100 in an iMac10,1.
So I could expect performance improvements on Sapphire Radeon RX 580 with EnableGop 1.2 injected to my Mac Pro (Mid 2012) ROM when OpenCore 0.9.1 is released next week? Thank you for the fantastic great work done 🙂
If you can see visible tearing or a visible movement of the screen clear down the screen now, I think you could expect improvements. If not, not so much! Thanks. 🙂
Btw if you want to try it before release, and report back, that would be helpful! Sign in to GitHub, go here https://github.com/acidanthera/OpenCorePkg/actions/runs/4539920542 , wait for a couple of seconds (because build artefacts take a little while to load onto that page), scroll to the bottom of the screen, download the 'macOS XCODE5 Artifacts' - install DEBUG or RELEASE version to your EFI folder, add UEFI->Output->GopBurstMode to your config.plist and set it to true (can double check that config.plist is correct using /Utilities/ocvalidate/ocvalidate from the same download). Profit - hopefully.
Very cool, @Bmju - thanks for your hard work making this even better!
General question. I already flashed your 1.1 version directly to my Vega 56. If I choose to mod my cMP 5,1's bootrom with this version 1.2 (leaving version 1.1 in my Vega 56's BIOS), which version will be used?
Does the Mac always default to the version installed in its own BootROM before going with a version on the card? Or is it the other way around? Or is there some other logic involved?
Just curious. I will probably end up flashing 1.2 to my card like I did 1.1, but I was thinking about instances where there isn't enough space for 1.2 (and would require stripping out VGA stuff). If the card has 1.1 and the cMP/iMac bootrom has 1.2, which version gets used?
General question. I already flashed your 1.1 version directly to my Vega 56. If I choose to mod my cMP 5,1's bootrom with this version 1.2 (leaving version 1.1 in my Vega 56's BIOS), which version will be used?
Does the Mac always default to the version installed in its own BootROM before going with a version on the card? Or is it the other way around? Or is there some other logic involved?
Just curious. I will probably end up flashing 1.2 to my card like I did 1.1, but I was thinking about instances where there isn't enough space for 1.2 (and would require stripping out VGA stuff). If the card has 1.1 and the cMP/iMac bootrom has 1.2, which version gets used?
I'd probably recommend flashing back the gfx card if you're going to flash to main firmware, though it should be harmless to have both (and you do mention a possible reason to want to do so). Because of the hooking strategy, the version loaded last (which will be the vBIOS version) will be run first. But both will run and you should get the GopBurstMode from the firmware version anyway.
I prepared and injected EnableGop 1.2 to my cMP Rom and added GopBurstMode to my .plist.
Should I put ProvideConsoleGop to false to test if my cMP load EnableGop from firmware, and leave the DirectGopRendering false since I have a RX 580?
I will flash tomorrow, getting late here. Thank you!
If you are flashing to firmware and you have not already flashed your RX580 then you can easily tell if EnableGop is present just by whether you can get the Apple native boot picker (before OpenCore starts) by holding ALT during boot.
If you are flashing EnableGop to firmware or vBIOS, you do not need ProvideConsoleGop or DirectGopRendering or GopBurstMode in config.plist; though they won't do any harm (and you might prefer to leave settings which work if you are ever planning to flash back again). If your card doesn't need DirectGopRendering - i.e. displays graphics fine without it - then don't set it, since it will very probably slow EFI graphics down.
BTW You can test whether GopBurstMode speeds up your graphics without flashing EnableGop, by just by setting the new quirk in OpenCore (regardless of whether you already have an earlier version of EnableGop installed; although of course if it's only in OpenCore, it will in that case only make a difference once OpenCore has started).
Last edited:
That has two EFI ROMs in already. They may well both be needed (idk!). You need to track down whoever made it and/or track down a VGA stripped version of the ROM for that card on the iMac forums (&/or gird your loins and follow @Ausdauersportler's instructions and strip VGA yourself!).
Hello, I am using iMac 11.3 Mid2010 AMD M6100 Bigsur 11.7.4 OpenCorePkg 0.8.7, I have previously installed M6100_iMacGOP_BFR.rom vbios from the forum and it works fine. When I install the vbios in the link for the boot screen problem, will EnableGOP be active? Do I need to update the iMac bios? Thank you in advance for your answer.(sorry if I have spelling mistakes) https://github.com/Ausdauersportler...blob/main/EG/M6100-HynixBFR-EnableGop.rom.zip
You should not need to update the iMac BIOS; if you have a very old one, perhaps EnableGop won't work - and if that is the case you should rule that out by updating to the latest available firmware before reporting a problem. Just by the name of the firmware file, it appears to have EnableGop in it! There is no other step to making EnableGop work other than installing it (to vBIOS or firmware).
You cannot cut the VGA in most recent AMD versions, all Navi and later vBIOS (legacy) versions are protected using a signature (needing keys AMD does not provide to the public, possibly because they were told to keep a private key in private 🙂).
Assuming there are two GOP parts following the signature protected legacy part and we need only one (the first, which has been patched by the Syncretic script) I would simply set the last image bit in the first GOP and let your script run over it. It will ignore the now trailing and still existing 2nd. GOP and happily insert the EnableGop driver.
startergo
macrumors 603
There is an ARM part in that ROM which I don’t see the need for. Is eliminating that part going to help?
Oh, so the legacy part is protected, but not the EFI drivers? Weird. If useful for us!
Actually, @startergo will need to set the last image bit in the first EFI driver, and then also patch out the unused driver with 0xFFFFFFFF, otherwise my script sees that non-empty data runs right to the end of the 128k area and assumes that the ROM is out of space. (Can also patch with 0x00000000, but 0xFFFFFFFF is preferred since it's less wear on the NVRAM to write that.)
Btw, what would the other (non-needed?) EFI part be - the original GOP which was just left in there? Or something else?
If there is an unused part, eliminating it will help. The error message isn't itself an error, it's real: AMD ROMs have a strict limit of 128k for the part of the entire NVRAM contents which can be used for (U)EFI drivers. ROM memory beyond that is not mapped to CPU memory space, and so drivers which read beyond that limit read junk, and crash. So there literally needs to be enough space for the new driver, and there literally isn't. If you can free up space by removing anything unused (and ofc patching up correctly, e.g. last image marker bytes, so that the modified ROM remains valid) it should just work.
You can use
-t test with the script to leave around the temporary directory with the intermediate files, including the compressed driver which it is trying to insert. Then you can see exactly how large that is and so how much space you need to free up.I flashed the vbios, the boot screen menu is working, thank you to everyone who contributed