im getting very wierd behaviour with uniforms not updating
in the following code when i say it doesnt work, it means the mesh is drawn without the updated uniform value
A/ // doesnt work
glUniform1f( location, val );
render_mesh();
B/ // works!! but in effect ive done nothing since im setting the program to what it already is
int active_programID;
glGetIntegerv( GL_CURRENT_PROGRAM, &active_programID );
glUseProgram( active_programID );
glUniform1f( location, val );
render_mesh();
C/ // doesnt work
int active_programID;
glGetIntegerv( GL_CURRENT_PROGRAM, &active_programID );
glUniform1f( location, val );
render_mesh();
sticking in the following with versions A,B or C gives the same answer, ie the same program is current in all 3 versions
int active_programID;
glGetIntegerv( GL_CURRENT_PROGRAM, &active_programID );
ive tried sticking a finish in as well as casting but no go.
// this is on a gffx5900 with latest official drivers 77.72
not sure where exactly is your problem but are you sure that your unfirom location is correct?
i would try something like this:
int location = glGetUniformLocationARB(shaderObjectID,unformName);
if(location>=0) {
glUniform1iARB(location, value);
}
I have never had problems with uniforms but Im checking for their location each time I update them which isnt probably effective if you update them often …I still have some uniform location cache in my TODO list
Download and run GLIntercept (http://glintercept.nutty.org/) on the app with the Full_Debug profile. Then check the gliLog.txt for any errors.
If the above is ok, run GLIntercept with the XML_Frame profile except goto the line in the config file with:
UniformLogPreRender = False;
and change that to:
UniformLogPreRender = True;
Then run your app. When the scene with the problem is visable, press CTRL-SHIFT-F. Open the resulting .xml file. Then on each render call using the shader, you should see a link to the shader with all the current uniforms.
Download and run GLIntercept (http://glintercept.nutty.org/) on the app with the Full_Debug profile. Then check the gliLog.txt for any errors.
no errors + oddly the app works 100% ok (no unifrom bug) with the Full_Debug profile
If the above is ok, run GLIntercept with the XML_Frame profile except goto the line in the config file with:
UniformLogPreRender = False;
and change that to:
UniformLogPreRender = True;
Then run your app. When the scene with the problem is visable, press CTRL-SHIFT-F. Open the resulting .xml file. Then on each render call using the shader, you should see a link to the shader with all the current uniforms.
the uniform bug is back again when i use the XML_Frame profile, anyways pushing CTRL-SHIFT-F froze for about 4minutes (and then i pressed quit), i assumed its writing heaps to a log or something
though i dont think the info will help anyways since the particular uniform was controlling the speed of a texture flashing thus a single frame wont tell much (ill right another more basic shader which should give a more conclusive result)
anyways after i broke the app the glilog.txt file has heaps of lines like this with various shader IDs , what does this mean, perhaps helpful?
InterceptShaderGLSL::GetShaderFileName - Unknown or invalid shader? ID = 48
yeah ive converted all my shader stuff over to the opengl2.0 interface over the last week, hence my close look at all things to do with shaders + the discovery of this bug, and i cant see how it can be anything other than a bug.
its not to important though as im planning on only using the unifroms for static variables + will use another (quicker) interface for changable data eg gl_Color etc ala quasi instancing…
im more concerned with the driver bug on the gffx with occlusion, hours ive spent trying to track it down
oh well ta anyway NAN. its beautiful day not a breath of wind not a cloud in the sky, i may go off to the snow
In your example A, where do you set the shader (i.e. via glUseProgram)? Do you do it once per frame, or just once after context initialization?
i set it multiple times a frame (cause im using different shaders).
I have the same card and driver version, and I’ve had similar problems in the past. It’s almost as though there are some GL commands which upset the currently installed shader.
have u been able to replicate the program in a simple test app?, ive tried but it works 100% correct there, its only in my more complicated program where it falls apart (similar to my experiences with the occlusion query).
i believe im doing something in the app that is triggering something else unrelated (eg enabling lighting which is buggering up the shaders)
or just the stress of my app is pushing the card is causing errors.
very difficult to trap the culprit
In my case, it was a glCopyTexSubImage that caused this problem. I never tried to reproduce it in a test program, mainly because the nature of this function requires that the rendering pipeline be flushed first, so I didn’t consider it unreasonable to have to reset the shader afterwards.
However, the code did work without the extra glUseProgram on a 6800 card with the 6629 driver.
