heyhey,
I’m currently writing a shade tree (Cook) and unfortunately it’s difficult to retrieve the output variables of a (previous) shader stage. I know they might be removed by the linker finally but it would be great to have such an extension.
Example: I want to write a geometry shader with a shade tree and I “know” which vertex shader is comming. the VS might be provided by somewhere else but there is no way for retrieving which output variables (old: varyings) it has… Or am I missing something
lets’ say I’ve got a vertex shader outputting:
out vec3 vSomeParam;
Now I have a fragment shader getting (obviously) as input:
in vec3 vSomeParam;
Trouble starts now when I want to add dynamically (via my shader graphs) a geometry-shader that should only perform vSomeParam*=2.0 or whatever.
look like this (geometry shader):
in vec3 vSomeParam[];
out vec3 geoout_vSomeParam;
I need to adapt dynamically the fragment shader to:
in vec3 geoout_vSomeParam
as the input comes now from the geometry shader.
in other words: imagine the in/outs you have to adapt in a program just because you added a tessellation stage on the fly.
Again: Am I missing some valuable point in glsl here?
That’s what interface blocks are for. I haven’t done a writeup for them on the Wiki, but the GLSL spec explains how they work. You can group multiple outputs into a block. Names within different interface blocks can be the same. So your vertex shader has an output block, your geometry shader has an input block that matches the VS’s output (as an array, of course), as well as an output block. And the fragment shader has an input block that matches the GS/VS’s output block.
Ahh OK. Sorry for posting here then, all my fault and please remove/move this thread.
Hope I can retrieve the interface (output) block of the vertex shader from the CPU side of a compiled shader (not program) then or is this impossible? something like glGetActiveAttrib but also for (possibly) non-active variables?
thanks
Hope I can retrieve the interface (output) block of the vertex shader from the CPU side of a compiled shader (not program) then or is this impossible?
Why would you need to? You should know whether a given geometry shader is compatible with the interface from a vertex shader. Unless you’re writing some kind of tool for others to use, you generally know what should go with what.
For debugging purposes, to get errors as soon as possible if by mistake we write an incompatible shader and the shader interface mismatch. With seperate program this approach even allow to detected shader interface error that the implementation won’t be able to detect.
This is a great debug mode practice in my opinion.