Redesign subshader API
Right now, the "workflow" to merge shaders is to spawn a second pl_shader
from the pl_dispatch
with pl_dispatch_begin_ex
and a unique namespace (to prevent ID conflicts). But actually, this API drags with it a number of awkward limitations - such as the need to decide up-front whether a shader will be merged, the need to create unique namespaces, and requiring the pl_dispatch
to spawn a sub-shader to begin with.
Re-thinking this design, I think it would be vastly better to instead spawn sub-shaders directly as children of shaders, basically something like a pl_shader_sub()
API that takes an existing pl_shader
and gives you a new pl_shader
that's conceptually a child of the original shader. This refactor would allow:
- Creating sub-shaders without requiring a
pl_dispatch
, e.g. to sample from a sub-pass inside an existing shader - Solving once and for all the namespace conflict issue (#106 (closed)) - indeed, we could even make sub-shaders use the exact same namespace ID as the parent shader, since they can literally inherit/share the ID counter
- Possibly making resource accounting much simpler since we no longer need to memdup etc. parent shaders. Indeed, the lifetime of subshader resources can be directly tied to the parent shader
But also some possible downsides:
- The most immediate benefits can only be leveraged if we completely disallow running subshaders independently of the main shader, which may make some fallback paths harder/impossible to realize
- Subshader handles can easily be "leaked" if the main shader is dispatched/destroyed
- It would make #163 completely impossible