Well with how modern GPU's, their driver and API's work you write code to do something then the driver "decides" on the "best" way of doing it.
Display drivers can replace entire shaders and modify pretty much any instruction and they often do so if nothing than for the code to actually work because game developer not only have shifted allot of the "performance" optimization burden to the GPU vendors but also quite often ship completely non complaint (and nonfunctional) graphics code, there have been plenty of gem posts on gamedev.net including multiple AAA studio's that botched their code so poorly on multiple titles that if it there wasn't a generic fix in the driver already it would not display anything at by not calling D3D::Create, D3D::EndFrame/Begin frame properly or at all in many cases.
Overall the majority of the driver codebase today is abstraction and fixes, only about a 3rd of it is actual API implementation.
So this is one reason why GPU driver code is necessarily closed :( to save face.
There are some software-based graphics cores out there, and one or two VHDL/FPGA efforts, but the performance/watt ratio between those and mainstream GPUs is laughable without a second thought.
Here's hoping AMD's vision to try and be more open in the future really works out. Also that Vulkan is at least mildly sane with open-ness.
Because the current state of things reinforces ideas like "the GPU is opaque" - architecturally, graphics processing is not a magic box, and while it would take a long time to fully understand it's not technically insurmountable; but the current status quo with drivers makes it so.
How much performance would a pure and thus leaner driver gain, I wonder.
Also a fair bit of backwards compatibility will be involved, like with x86 cpus. And even then, the same fixup is required to run opengl on directX cards, I believe.
Considering that even with API's that have some what good internal compliance testing like DirectX developers still ship utterly broken and un-optimized code - none.
This is also why Vulcan will probably not succeed (at least now how people think it will).
The last thing that say Nvidia wants is to maintain a code base of 3-4M LOC's which 50-60% of it is intended to allow for games to run anywhere from running at all to running well.
With how the current market works the driver is the "secret" sauce that GPU makers use to compete in the market and is just as important (or even more in some cases) as the hardware it self.
Display drivers can replace entire shaders and modify pretty much any instruction and they often do so if nothing than for the code to actually work because game developer not only have shifted allot of the "performance" optimization burden to the GPU vendors but also quite often ship completely non complaint (and nonfunctional) graphics code, there have been plenty of gem posts on gamedev.net including multiple AAA studio's that botched their code so poorly on multiple titles that if it there wasn't a generic fix in the driver already it would not display anything at by not calling D3D::Create, D3D::EndFrame/Begin frame properly or at all in many cases.
Overall the majority of the driver codebase today is abstraction and fixes, only about a 3rd of it is actual API implementation.