> I don't know why AMDGPU (the Linux driver) is somehow better than the Windows drivers
Open source Linux drivers are developed by another team inside AMD. They can't talk with the other driver team either. When you remove the incentive to add game specific hacks, multi platform support and other stuff, and add community support at the back, you get a straightforward and superior driver at the end.
Also, the driver wasn't forked or derived from FGLRX or any driver for that matter. It's just written from scratch. I remember OpenSuSE had a dedicated AMDGPU driver team too.
Out of curiosity, are there any writeups on how the game specific hacks work? Like, how do they detect the game being run and what kind of optimization are they doing?
I don't have any links handy, but this is what I remember as I read these things over the years:
- Drivers match the binary name (and CRC32 of said binary sometimes if the name checks out) to trigger game, and game version specific "hacks" or optimizations in the driver.
- These can be small bug fixes for Z flicker or performance enhancements like fill dithering or other more advanced hacks. nVidia once "Optimized" 3DMark to errm... render the benchmark more fluidly I may say (They got caught, BTW).
- There are more advanced "behavioral changes" which alters internal behavior of the driver to improve game performance (a version of the Crysis engine called something expensive too often, and it had no visual impact, so nVidia's driver ignored most of them intelligently and game ran significantly faster for that, IIRC) or use a more optimal memory copy/access strategy than the game declares. Sometimes nVidia's driver takes its own initiative and does the things as it pleases, again if I recall this correctly. It's not impossible that a driver version uses optimized shaders or other hidden hacks to increase performance of a certain game (or contain optimized routines which work better for a particular game).
- Other than that, sometimes drivers allow some games to access more information than an ordinary application to allow higher performance via hacky or dangerous code paths, but they're almost considered as trade secrets. Sometimes game engines abuse the driver behavior too, but it's again "secret sauce" and nobody talks about them in the open much.
I remember reading such things for Need For Speed III, Quake III, A Crysis franchise game. Again, Doom III is criticized for being developed too nVidia specific (Carmack openly likes nVidia more IIRC).
This information is collated from my readings, past memory, some chats with a close friend who develops a game engine, and some other channels I had access in the past.
At least on the AMDGPU side, I've seen mentions on Phoronix of various game (detected based on binary name usually) specific compatibility hacks that force on/off various behaviors and other minor tweaks.
Given the size of the "driver" files on Windows these days, my GUESS is that they might ship literal patches that replace portions of the GPU code in some (popular) games.
There's also the issue of games developed with explicit support for the architecture of a given GPU (usually Nvidia), where algorithmic approaches bias towards the strengths of one type of product.
Open source Linux drivers are developed by another team inside AMD. They can't talk with the other driver team either. When you remove the incentive to add game specific hacks, multi platform support and other stuff, and add community support at the back, you get a straightforward and superior driver at the end.
Also, the driver wasn't forked or derived from FGLRX or any driver for that matter. It's just written from scratch. I remember OpenSuSE had a dedicated AMDGPU driver team too.
This is why.