[SOLVED] Simple GLSL shader program fails validation

Started by
8 comments, last by Zouflain 11 years, 7 months ago
I am at a total loss trying to write a very simple shader to output information on a voronoi diagram algorithm I've been toying with. It's supposed to take 2 values (a biom and an elevation), colorize the fragment as determined by the biom# and brighten it by 1/10th the elevation. VERY simple shader, and I could easily have done it in older GLSL versions but I've just migrated to openGL 4.0 and am having a hard time relearning GLSL.

Working with my other shader programs taught me a lot about validation and error checking, but that isn't helping here. The program log for both of the following vertex and fragment shaders is empty and OpenGL is reporting GL_NO_ERROR. The program, however, still returns GL_FALSE when attempting to validate. I've tested the validation code and it works fine (for instance, a syntax error is clearly reported and other simple shaders are NOT returning GL_FALSE).

In short, my question is: What illegal thing am I doing to make the program fail to validate?
Thanks for any help on the matter. This has me completely baffled.

voronoi.vert
#version 420

uniform mat4 mat_ModelViewProjection;
uniform float scale;

layout(location = 0) in vec3 in_Position;
layout(location = 1) in float in_Elevation;
layout(location = 2) in int in_Biom;

flat out float ex_Elevation;
flat out int ex_Biom;

void main(void)
{
gl_Position = mat_ModelViewProjection*vec4(in_Position*scale, 1.0);
ex_Elevation = in_Elevation;
ex_Biom = in_Biom;
}


voronoi.frag
#version 420

in float ex_Elevation;
in int ex_Biom;

out vec4 frag_Color;

void main()
{
vec3 color = vec3(1.0f);
switch(ex_Biom){
case 0:
color = vec3(0.0f,0.0f,1.0f);
break;
default:
color = vec3(0.0f,1.0f,0.0f);
break;
}
color = color*ex_Elevation/10.0f + 0.1;
frag_Color = vec4(color,1.0f);
}
Advertisement
Whenever I get something like this it is something stupid like attaching the wrong shader object, reading from the wrong file, some copy-paste mistake not editing the file i'm testing etc. Every... single... time... biggrin.png
Well... what is the error message?

Edit: At what stage does this error occur?

Well... what is the error message?

Edit: At what stage does this error occur?
This is why I am so frustrated. There is not an associated error message. I immediatly check for OpenGL errors after compiling and linking, and OpenGL reports GL_NO_ERRORS. The program does not validate however (that is, glGetProgramiv passing GL_VALIDATE_STATUS outputs GL_FALSE). The log (glGetShaderInfoLog and glGetProgramInfoLog) is blank. It validates just fine if the fragment shader does not refer to its input variables (for instance, if I comment out everything between color = vec3(ect) ... frag_Color = vec4(ect)) and as I said, the log is correctly formulated when it's a syntax error. The program also successfully links. It simply does not validate.

Very depressing... but, thank you for your responses.
have you tried not checking the log message unless it fails?

[quote name='GeneralQuery' timestamp='1347185207' post='4978234']
Well... what is the error message?

Edit: At what stage does this error occur?
This is why I am so frustrated. There is not an associated error message. I immediatly check for OpenGL errors after compiling and linking, and OpenGL reports GL_NO_ERRORS. The program does not validate however (that is, glGetProgramiv passing GL_VALIDATE_STATUS outputs GL_FALSE). The log (glGetShaderInfoLog and glGetProgramInfoLog) is blank. It validates just fine if the fragment shader does not refer to its input variables (for instance, if I comment out everything between color = vec3(ect) ... frag_Color = vec4(ect)) and as I said, the log is correctly formulated when it's a syntax error. The program also successfully links. It simply does not validate.

Very depressing... but, thank you for your responses.
[/quote]
So it compiles and links correctly with no errors? Have you tried changing your vert and frag shaders to basic pass through shaders that output a white fragment or something? From there you can add the original shader code incrementally until the problem is caught. Failing that, can you post up the relevant code you use to load your shader resources?
there may be other factors involved, now that i read about it =)
glValidateProgram takes into account factors such as if the appropriate settings are correct
i just read this: http://www.gamedev.net/topic/372356-very-peculiar-glsl-bug/
@GeneralQuery yes, it compiles and links correctly with no errors. I have turned this into a pass through shader, and it does not fail to validate. It only fails to validate if the fragment shader makes direct reference to ex_Biom or ex_Elevation. In general, the method you describe is my default goto method for solving things like this (I am a very awful GLSL coder). Any other legitimate GLSL seems to work, but it must not use either input variable. OTHER shaders that work just fine use input and output variables without issue.

I can post the shader loading code if you honestly believe that will help, but it's a very basic read to buffer, pass to OpenGL, compile, link, and validate. It works fine for other shaders, so it seems very doubtful to be the loading code. Again, the problem ONLY occurs when voronoi.frag refers to ex_Biom or ex_Elevation.

(Given that the GPU will optimize out any variables it establishes have no impact on the output, I suspect voronoi.vert's use of in_/ex_<Val> is simply being optimized out, which explains why it does not matter what happens there and the program validates without changing the vertex shader. Since other shaders only pass varying (as opposed to flat) vecNs, I suspect something about the format of the variables is at issue.)

@Kaptein thank you for the link, but it didn't exactly help. Other shaders are validated before and after this one without issue, and there is no change in OpenGL's state between them.
I'm not really a pro with shaders, but shouldn't those input parameters also get that flat keyword, or is it allowed to mix them so that the input parameters differ from output parameters?

Derp

I looked at that... and then concluded in a rather silly fashion that it need only be specified in the vertex shader, as the fragment shader wouldn't need to know (it would just happily take whatever the vertex shader gave it). Well, assuming things is an easy way to give yourself a headache. Thank you for resolving the issue, leaving off flat was exactly why OpenGL didn't like it.

This topic is closed to new replies.

Advertisement