That is interesting, but could be a driver cache in windows, you would have to completely remove the drivers using:
Here you can Download Display Driver Uninstaller, this Display Driver Uninstaller is a driver removal utility that can help you completely uninstall AMD/NVIDIA graphics card drivers and packages from your system, with...
www.guru3d.com
This is also very possible
Another vision. Could you send the stable mojave vbios and two or three fake which is working on Catalina.
Possibly you will need to make screen shots in gpuz of first and second tab and generate hwinfo64 report for stable rom and fake roms.
Explain why:
1. When I flash wx4150 g5 vbios with native vram parameters, the bios won’t work, because the vram was not responsible and actually the gpu processor get freeze. But when I patch my vram section, the gpu chip was succed with timing, but the core instructions was optimized to work with non Samsung vram, so there was no connection between gpu core and vram. The ram bridge fails to initialize. But what is important is the bios boot get same symptoms as I have in Catalina, also as you.
2. So when your fake vbios working on Catalina it wouldn’t be work on Windows. Comparing data from gpuz and hwinfo64 will help to understand which instructions was or wasn’t initialized.
3. Every vbios build with (my understending):
-
preboot: hardware components initializing (vram, vrm, mossfet configs)
-
preboot: operation bus instructions: Gpu core hub, vram Bridge, pci bridge, l2c, jtag, SMBus
-
Boot: gop, connectors, port transmitters basic efi drivers
-
Boot: Instructions supported(like intels sse, and other could be found in pc bios): this instructions making components to operate, core operate and actually starting the whole gpu system work, comunicate with motherboard and chipset, cpu (some kind of microcodes)
-
Boot: final stage diagnostics, and send message “all is ok, ready to operate” to chipset) and now post is complete.
-
OS (instructions via pci bridge to non based driver(amd or other preinstalled)) so OS is getting boot with basic efi driver and switch to extended, user installed. Windows and Ubuntu flashing screen few short times and enhanced graphics are working now.
- The
os based driver is now operating with instructions like OpenGL, cuda, Vulcan and other.
So theoretically:
We have different parts of vbios stages (non os dependency):
- early components communication
- hardware communication
- Basic operating instructions
- Basic video driver
O
s based dependency:
- acceleration instructions
- Video drivers
- Port mappings
That’s why when inject vbios, it only affects to os part of vbios, because the other part is already working and is not responsible to high level operations (my friend has r9 270x gpu with a small hole in gpu chip. This happens because of overheating, the transistors became bigger and as the distance between them decreased, a breakdown of the current occurred. So part of gpu related to accelerating just blow up. But gpu is still working on base driver). So low level and high vbios stages have no dependency.
So with low level initializing, the hardware components are unstable and doing wrong communications with high level. So that’s why hardware part of vbios is fake, but acceleration is the same as in other amd gpu. And that’s why Mac OS driver is working, because it can’t operate with hardware components but good with high level.
If you are using the stable vbios, macOS will operate fully with hardware which already initialized on early stage of boot.
If you want to know is Catalina or any other OS X communicate with mxm rom, you will be supraised if you will inject 64 or 65 kB vbios with clover or OpenCore. So if you will replace gpu ascii name in rom, correct checksum, and after injection will dump with any way, you will dump injected rom)))
Any rom 64 or 65 (I can’t remember)is injected by efi bootloader! so that’s all))
Problem is in driver, because even without Whatevergreen and lilu. The os wont start final stage.
Waiting for your gpuz an hwinfo64 reports for comparison.
UPD1. Why we see HP vendor in GPUZ?
How GPU-Z Recognize Subvendor if rom is not reading? Where this info can be stored?
I think if vbios cant be read, pci still can read GPU core. And gpu core have integrated DeviceID, and as you see, OpenGL is supported even without vbios. The driver trying to start by identification of device and vendor IDs. But why we see HP subvendor? this subvendor can be even found if I replace stable vbios with apple 13,3 rom. But GPU core can`t be flashed by firmware...
UPD2.
Just for fun. I found Intel Vbios in mine bios rom
The file with name
LegacyVideoRom_00D3
Attached file (Skylake HD530 mobile)
UPD3.
I deleted different AMD kexts related to ioregistry associations with GFX0 and get gpu working without acceleration. So something in one of this kexts have some ask or search command related to preloaded video rom, and if it returns with wrong value it will stop windowsserver. The Windowsserver are related to Appledevicepolicy.kext. So fake rom possibly prevent return of some unknown value. So to find out this dependency we need to look on your reports. Then find what kext is actually related to this action, reverse engineering this path, make patch kext with return success. Or it’s simple whitelist.