This isn’t true; there is absolutely no penalty to leaving unused shader inputs in a shader. The shader compiler knows which inputs you don’t use, and automatically removes them from the compiled code. Panda also notices that the input isn’t used and doesn’t bother passing the data to the GPU.
For Panda-provided uniforms like texpad, in fact, there is not a significant reason to leave them out of a shader (except readability of the generated shader) if doing otherwise makes things more complicated. And in fact, I would suggest that we do that if it means we can remove more code. (Remember the old saying: perfection in design is attained not when there is nothing more to add, but when there is nothing more to take away.)
For custom inputs, there is some overhead associated with having the shader inputs cycle down the scene graph and in the setShaderInput call itself, though not very much.
OK. (Though this is one case where I’d suggest that if it becomes more complex to support this case, I’d say we have to just change the SSAO shader rather than bend over backward to support it).
In this case, though, it doesn’t seem to be a problem since the make method calls setShaderInput anyway - or we just both call setShaderInput and markDirty() in the appropriate setter.
I think the filter’s setter should mark the flag wherever it is most appropriate: if it requires a pipeline-level recompile, it should mark it on the pipeline, if it requires a filter-level recompile, it should mark it on the filter. It seems you are already doing something like that in your _set() method, anyway.
No, it should run in the same thread (the app thread), because of an existing problem in Panda where we can’t create buffers in any other thread. There is no risk of data races; we just make sure the task sorts right before the igLoop task (which has a sort of 50) to avoid a one-frame lag.
Yes, I understand - I was pretending there was only one parameter for the sake of simplicity. 