[aappleby]

"In my case, I want to construct and call any shader I want at run-time. Arbitrary composition is the entire point. This implies that when I want to go make a GPU call, I need to generate and link a new program, based on the specific types and access patterns of values being passed in."

For toy apps, sure. For professional apps or games, abso-frickin-lutely not. Shader compilation jank is still an annoying issue in even recent games, and even having the ability_ to define arbitrary shaders at any point is such a huge footgun that I'd never let it past code review.

[raphlinus]

I agree with you that dynamically instantiating shader permutations is bad news. That said, I think the author is probably onto something regarding linking and closures. The existing "binding model" for shaders is incredibly tedious and low-level (not to mention frustratingly not-quite-portable), and I think it's likely that there's a better way to do it.

[greggman3]

Seems like you'd just compute combinations at compile time. The point of the article is not that things should be done at runtime, the point of the article is that the entire system can be made easier to use by putting more smarts in front. Those smarts can happen at runtime or compile time.

[gugagore]

So what does one do in professional apps? Make sure all the shaders are compiled ahead of time? How does that help?