I thought that Vulkan and DX12 being modern APIs supposably only requiring a thin driver would make the GPU Manufacturer driver-game babysitting a thing of the past!
But no it doesn't look like it that's completely the case. The down-to-the-metal optimizations should ALL be handled by the game developers just like the newer APIs said they would give more access and responsibility, but it looks like it wasn't fully it, hence it's still abstraction, just "better at it".
It's so weird when there's fixes in these GPU drivers about some edge-case in some game, "corruption is seen in XYZ game when opening a menu" ... why on earth would that ever be a driver problem, if it is then that is a wrong approach, but if it's not then it shuldn't be driver trying to fix it but rather the most sensible appropriate component where the root cause is coming from, the game is doing something wrong most likely, but with this current system it feels like they always look at it as if "the driver isn't doing enough", missing the point and forgetting to ask if the driver should be doing this at all, even if it's known to everyone that it is a game fault but we just choose it to fix it in the driver, bah, it just feels like a cheap way to get over the problem and then the devs also become less motivated because they expect the GPU manufacturer to fix it, but the system is made so that many things the only way to fix it is in the driver, just weird on so many levels, the driver shouldn't have this kind of extra wide ranging responsibilities, there is no rules in the industry what can and cannot go in a driver to keep things simple, GPU drivers are one of the biggest one, just look at how many Megabytes, that's MEGABYTES are the size of the .DLLs ... 20-40 MB, what a freakshow compared to everything else.
What kind of API calls or whatever is the game sending or doing something else somewhere that causes this bug effect. GAMES ARE THE BIG BULK, games are the CARGO of weight and complexity, it should always be the game looking for it's compatability with the OS/API/DRIVER/HW, not the other way around, is the cargo strapped in the airplane correctly, if not, fix the cargo, not add another engine or extend the wing or add counter-weight to keep balance of the imbalanced cargo, pffft, if it is compatible it JUST WORKS, the GPU freezes or crashes, guess what, it should never be the API/OS/DRIVER fault because those things should have to be DESIGNED to be as reliable as smooth as simple as possible and the only room should be in the game where the game is the place where those nitty-gritty down-to-the-metal optimizations happen and not anywhere else.
obviously you can't have 1 company serving 1000x games out there to their fullest potential, this is whole driver babysitting is a fundamentally not optimal approach for practical end-user usage.
The industry keeps chugging this terrible method of so much driver responsibility and babysitting each and every game and having to "support" a new game, give me a break, the game supports the API, the game supports the OS, the game supports the GPU, the GPU supports the API, and the driver translates the games instructions through the API into GPU instructions, it ought to JUST WORK, right?!?!? Why not? Why so much fiddling and diddling with the freaking driver, with the mystery middle-man. Why so much drama with the transporter. This from an outside practical point of view makes no sense, but sometimes it takes that kind of approach to view something from afar rather than being an expert at it's details, the various individual experts may not see/realize the and just go along with it as if that's just how it suppose to be. The transport/conversion always should be as smooth, fast, reliable, but simple.
It could also be GPU HW problem, if some game or two is coincidentially using some kind of a pattern of commands than causes the GPU to produce corrupted output ... guess what, IT'S THE GPUs FAULT, not the driver, leave the driver alone and fix your broken HW you cheap's cakes. In the practical economic world ofcourse they would want to poke the driver to fix it, the users would also not want to replace the GPU if they bought it recently, but this is just the reality.
If such things were to happen ... it would have been a failure at Quality Assurance and testing, not testing for all possible combinations of commands feeded into the GPU, with todays AI and supercomputer automation that's like a non-issue to test for, so such fixes would be very rare.
Continuing: Nothing else requires such insane amount of driver maintenance than the graphics department, this has been plaguing field and I think this is why there's so much drama around benchmarks and performance.
The only thing a GPU manufacturer thin driver would do is general things such as HW/OS/API compatability so that fullscreen modes, super resolution, scaling, support for newer API version and other insfrastructural things to work properly as OS and HW is developed, you would need to update it much less frequently versus now, and you would update it to support a new API version and that's it, not each new GAME!!! :/, and that update should be fine for all the new games using an updated API version!
If done properly and tested right there wouldn't really be so much room for bugs anyway and if there would be bugs they wouldn't affect specific games in such specific manner, these general and larger bugs would also be very noticable and affect a lot of people so they would be traced down and fixed relatively fast. The driver shouldn't ever go into nitty-gritty extremely-game-specific details which pretty much makes this world not a GPU war but a DRIVER WAR!!!
Do you have to update the mouse driver to make the mouse "support" a game that runs over 300 FPS?
Do you have to optimize the mouse driver when you choose a new mouse pointer style?
Do you have to optimize the keyboard driver when so you can press 10x more keys in a highly competitive FPS game?
Do you have to upgrade the CPU driver when you load a new program that uses modern instructions?
Do you have to update the network driver to support a new Cat.7 Ethernet cable?
Do you have to
No you don't! Everywhere else, IT JUST WORKS for what it is designed for, unless the driver is just bad made by low paid devs, usually cheap pheriperals from Asia.