I don't have any industry experience with large projects, so I can't really provide an informed take on this. I can however try to give a little bit of historical and theoretical background on the issue. One big problem of legacy APIs (especially OpenGL) was the unpredictable performance of state changes. OpenGL programming model is a state machine — you set up certain parameters (e.g. texturing mode, color blend mode, shading mode, active textures, or data buffers), and then execute drawing operations that make use of these parameters. Complex apps and games would obviously need quite a bit of those state changes to draw complex scenes. Now, the problem is that on some hardware some state changes are quite expensive. Maybe on hardware A changing texture filtering mode is as simple as setting a bit in the shader memory, and for hardware B it requires a complete reconfiguration of the vertex submission process with a new variant of the vertex and the pixel shader. What would happen in practice is that you do something that would seemingly be trivial (like enabling alpha testing), and your app would suffer a multiple ms of delay because a whole new shader combination needs to be compiled and linked. And you had no way of knowing where to expect these slowdowns because the API wasn't designed with this concern in mind. So what one ended up doing is testing the behaviour on various hardware and driver versions, identifying problems and trying to shuffle the code and state changes around to minimise the slowdowns (which sometimes required device-specific code!)
Pipelines were introduced to solve all these issues. The idea was that your API makes guarantees which state changes are fast and which state changes are slow. You get pre-configured immutable state objects (pipelines), which might be slow to create, but should be fast to change. Obviously, to accommodate as much hardware as possible under the same API, these state objects need to be fat enough to include all things that might be slow on different types of hardware. The rendering pipeline state object in major APIs for example includes things like vertex and fragment shaders, blend state, accepted types of render targets and some others. This doesn't mean that changing these parameters separately is slow on all GPUs: some for example can allow for efficient blend state change, but others do not, which is why you put all these things together.
So what you end up with is a neat API that gives you predictable performance by allowing you to bake the necessary state configurations beforehand and then just then those in your rendering loop with low overhead. Everybody happy, right? Well, for a brief while anyway. The problem is that every combination of different shader programs plus associated parameters is a new state object to be baked. And the number of shader stages keep growing: mesh shading, tessellation, ray tracing... that's quote some combinatorial potential! Plus, recent APIs introduced the concept called shader specialisation, where you can optimise the shader using some application-supplied values. And since this requires to compile a new shader variant, you need a new pipeline state object.
For modern games and applications this can very quickly become a burden. The usual idea of baking the pipelines at application startup stops being feasible as the number of combination explodes (ever wondered why newer games take ages to start?) and if you add specialisation to the mix it gets even worse... and what's the worst, much of these state objects are almost entirely redundant, as they contain copies of the same programs, just combined in a slightly different way, for many hardware platforms.
So the idea of EXT_shader_object is basically to break down the pipeline state into smaller pieces of immutable state which could be handled by the application more efficiently. And as I wrote, this is a good initiative. I am just worried that the way how it's formulated it might hurt certain platforms that simply do things differently from the big two. But then again, I see people from IMG, Qualcomm, and ARM as contributors to the extension, so it would seem that mobile vendors see no problem with this approach.
I wonder whether we will see some changes in this area from Apple at WWDC this year. They did actually introduce some tools for managing these issues (at least to a certain degree). Recent Metal versions support function pointers as well feature a fairly involved system of composing functions from basic building blocks (keyword: function stitching). But I never used those and don't really know how they work. The basic idea is that you can have your shaders call some utility function to handle certain operations, and those function can be bound at runtime (you are literally passing a function pointer to the shader, and that pointer can be set by the client code). You still use pre-backed pipeline state objects, but hopefully you need less of those since you can cover a lot of cases with these pluggable functions. Still, all that stuff seems awkward to use and has a large API surface, which is kind of uncommon with usually elegant and straight to the point Metal. It might be a good idea to just radically overhauls the entire thing and just use function pointers though the entire API. The big question is whether Apple hardware can do it efficiently or whether they rely on some state being pre-baked.
github.com
