[chao-]

The thing is, as referenced in the article I linked, there is a blurred line in functionality between what the GPU can do, via what the driver exposes, and what the GPU can do, if only they would write something for you to help massage it a bit and enable in the way you need.

Without access to the engineer's knowledge of the GPU's hardware, it's hard for the open source developers to even know what they ought to be able to implement. It follows that game studios (and consumers) would be crazy to rely on the coin-flip-odds that an open source implementation will figure out the right thing to do for a particular optimization of the GPU's internals

I am also an outsider, but have had a few friends work on various graphics projects (game engines, CAD software, one of them use to have a map of the OpenGL state machine above his bed). To hear them tell it, trying to maintain absolute "best practices" and only use truly cross-platform, cross-vendor code in your libraries while still hitting deadlines for games is like the mythical web startup that somehow ships despite also investing time in 100% unit test coverage, 100% integration tests, with a little bit of mutation testing and generative testing on top to help test-drive the test suite. That is: it's more of an ideal to strive for than a reality to be lived.

As a Linux user I weep at this state of affairs, but given the way GPUs are made, I don't know what could change.