Uniform names

[lambage]

I've searched around and can't seem to find an answer about this. I have a shader and in the shader I have a uniform variable. I have seen an issue where renaming a uniform can mean the difference between the shader working and not working.

I had the following and it did not work

struct BoundaryStruct
{
    float upper_bound;
    float lower_bound;
    int mask;
};
 
uniform BoundaryStruct b_kComp;

I renamed my variable (and updated where the code uses said variable) to

uniform BoundaryStruct t_kComp;

and magically everything works now.

There were no compile errors or warnings, but when the application runs glGetError returns GL_INVALID_OPERATION after a call to glUniformMatrix4fv when I set my modelview matrix.

I've seen this issue several times now in developing my current code base where things weren't working, so I renamed some uniforms and update the application code accordingly and then everything works. While I do have a means to get around this it is a really annoying issue.

Does anyone have any ideas about this? Have I missed some important naming advisory memo?

Thanks,

Kris

[Alfonse Reinheart]

It's more likely that your code had some bugs in it, and when you went through and renamed things, you fixed them.

[lambage]

Sadly I wish that were true that I made a simple mistake, but by renaming t_kComp back to b_kComp it will break again (just verified it). Also unfortunately due to the nature of what I'm working on I can not disclose the source code. It appears this is the case on 2 systems, 1 being a Ubuntu 12.04 64-bit with a AMD FirePro 3D V9800 the other being a Ubuntu 12.04 64-bit nVidia Quadro 600. I could try on some other platforms too but it's probably not necessary. Given that the error exists in both amd and nvidia driver sets you're probably right that it's something in my code, I just can't figure it out.

[Alfonse Reinheart]

So, it happens on both NVIDIA and AMD. Naming them one way breaks it (in some notably unspecified way) and naming them another fixes it. And you can't show us the source code.

The likelihood of both NVIDIA and AMD drivers having the same bug is... let's just say it's pretty low. So odds are good it's in your code, whether you think it's there or not. So... how exactly do you expect us to help?

[lambage]

I was just wondering if anyone else had come across similar issues and discovered the root cause. I'd have to speak with my managers if I can post anything due to the confidential nature of the algorithms I'm implementing.

I completely agree that the issue lies somewhere within my code, I'm not debating that. It's just such an odd situation. If I do ever figure it out I'll be sure to document it so others can avoid the same pitfall.

[thokra]

After renaming the variable inside your shader, did you update your application code to query the uniform locations of the struct members? Plus, why does setting the model-view matrix spit out an INVALID_OPERATION and why do you suspect the problems to be connected? Setting the model-view matrix and stuff regarding the naming of your struct sound pretty disconnected to me. Without the responsible shader and application code it's impossible for us to draw any conclusions.

Anyway, I'm sure many people stumbled across what you experience - I certainly did. But it's like Alfonse said, the chances that implementations of both vendors screw up such an insanely common thing are as low as Alfonse suggested. So, it's most likely a programming error on your part.

[Dark Photon]

It appears this is the case on 2 systems, ...AMD FirePro 3D V9800 the other being a ...nVidia Quadro 600....probably right that it's something in my code, I just can't figure it out.

Might install the latest Cg distribution on your Linux box with the NVidia card, and use this to get some clues:

cgc -oglsl -strict -glslWerror -nocode -profile gpu_vp vert.glsl
cgc -oglsl -strict -glslWerror -nocode -profile gpu_fp frag.glsl

Remove the "-nocode" to actually see the generated assembly, which you can diff for clues.

Also, after compiling a shader and linking the program, you are checking the COMPILE_STATUS and LINK_STATUS, and if failure querying and printing the info log, aren't you? (glGetShaderInfoLog/glGetProgramInfoLog or old way glGetInfoLogARB)

Also, right before rendering with your shader after you've got your uniforms set up, see if you're calling glValidateProgram, are checking VALIDATE_STATUS, and querying/printing the log there as well.

[lambage]

Plus, why does setting the model-view matrix spit out an INVALID_OPERATION and why do you suspect the problems to be connected? Setting the model-view matrix and stuff regarding the naming of your struct sound pretty disconnected to me. Without the responsible shader and application code it's impossible for us to draw any conclusions.

I'm as baffled as you to be honest. I'll try what Dark Photon has suggested and I'm working on trying to put together an example that won't make my entire companies IP public domain

I appreciate the responses!

[lambage]

And I found out the problem...

glUniformMatrix4fv(m_finalOutputShader("MVP"), 1, GL_FALSE, glm::value_ptr(MVP));

should have been

glUniformMatrix4fv(m_finalOutputShader("mvpMatrix"), 1, GL_FALSE, glm::value_ptr(MVP));

based on the uniform name in the shader.

I still don't understand how that relates to the name of my other uniforms. But it seems to be working now and I can name them anything I want and it still works


Thanks for listening guys!