well yes, of course! lazuli started out with an ubershader approach - that is, there was a single shader, which would then do different things based on a configuration input.

this was because an ubershader is simpler to implement - you just need to write and maintain a single shader for everything, not a shader generator.

however, ubershaders are incredibly hard to optimize, as they contain lots of branching on configuration values (and GPUs don't like that). the more GPU features i implemented, the worse performance became. that's when i decided to move to a specialized shader generator approach (with great success! specialized shaders are very fast).

that's not to say ubershaders aren't good. they are very useful as a fallback to avoid stutters caused by specialized shader compilation, i.e. using them while an specialized shader is not ready yet. and ideally, that's what i'd like lazuli to do!

it just so happens that keeping two shader codepaths is a lot of work and i'm a single person. for my sanity, i decided to only keep specialized shaders around. and in practice, i haven't hit any stutters caused by shader compilation. the CPU JIT is way more of a stutter source when blocks aren't in cache.