my little program implements multitexturing. One ordinary texture and one cubemap.
The shaders compile and link fine but in validation i get the following error:
“Validation failed! - Different sampler types for same sample texture unit in fragment shader.”
Again: the error appears at validation, so long before any rendering, so the actual renderingcode is not important (Fun fact: everything renders as expected on my machine. I nevertheless want to understand the error)
Now, when i change the sampler declarations into the following
layout(binding=7) uniform sampler2D colorMap;
layout(binding=4) uniform samplerCube cubeMap;
the error disappears. The numbers 7 and 4 are entirely arbitrary and i don’t understand what’s going on. If both numbers are the same, the error comes back; if they are different, the error is solved.
Even after googleing i don’t understand what ‘binding’ does. It is, as far as i see, not related to uniform-locations. My locations later in rendering code are setup correct (afair):
From looking at the code to bind the textures and set the samplers, I think that at validation time both samplers do indeed point to the same texture unit. You should make these GL.Uniform calls right after linking.
Indeed i was calling glValidate right after linking of my shaders. That’s what i “learnt” from my textbook but now after reading the official documentation and your hint i refactored the code into:
and the validation succeeds now. It makes sense because the Uniform-Values for the two samplers are correctly bound to two different textureunits now.
So thank you very much for you help.
But i’m wondering whats the best practice when vadidating shaders.
This function is typically useful only during application development. The informational string stored in the information log is completely implementation dependent; therefore, an application should not expect different OpenGL implementations to produce identical information strings.
Why only during development? Especially when the outcome is implementation defined it could happen that validation fails on other machines and gives valueable feedback, right?
So maybe something like this:
if(first)
{
shader.Validate();
first = false;
}
drawcall();
That means at validate the shaders right before the very first drawcall. Any recommendations?
[QUOTE=Betrayal;1262170]Why only during development? Especially when the outcome is implementation defined it could happen that validation fails on other machines and gives valueable feedback, right?
[/QUOTE]
That’s what beta testers and assert builds are for. After you’ve resolved all failures, turn off validate/geterror/etc in your release builds.
[QUOTE=Betrayal;1262170]Why only during development? Especially when the outcome is implementation defined it could happen that validation fails on other machines and gives valueable feedback, right?
So maybe something like this:
if(first)
{
shader.Validate();
first = false;
}
drawcall();
That means at validate the shaders right before the very first drawcall. Any recommendations?[/QUOTE]
Well the problem with this is that it only tests with one set of input data (e.g. uniforms). But the input normally would change dynamically over the runtime of the application. Most likely you use a shader several times in the same frame with different uniform values.