PDA

View Full Version : crazy uniform behaviour



zed
07-06-2005, 09:01 PM
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

ta zed

Trahern
07-07-2005, 01:41 AM
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 :)

sqrt[-1]
07-07-2005, 10:54 PM
Just as an insane test:

1) Download and run GLIntercept (http://glintercept.nutty.org/) on the app with the Full_Debug profile. Then check the gliLog.txt for any errors.

2) 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.

See:
http://glintercept.nutty.org/Demo03/gliInterceptLog.xml
for an example of what I am talking about. Scroll down to a render call and click on the "GLSL1" shader link.

Hopefully this should reveal if it is a problem with your code or a driver bug.

zed
07-08-2005, 12:01 AM
Originally posted by sqrt[-1]:
1) 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


2) 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

thanks for the feedback anyways
zed

sqrt[-1]
07-08-2005, 12:53 AM
arr, you are probably using the OpenGL 2.0 interfaces, correct?

The current released version of GLIntercept does not have support for shader logging through the new interfaces. (hence all the unknown messages)

(Perhaps there is an idea, try just using the ARB extension interfaces and see if there is a difference?)

Sorry I could not be more help. (I willing to bet a driver bug at this stage)

zed
07-08-2005, 12:58 PM
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

Peter_dup1
07-12-2005, 01:55 PM
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?

Peter

zed
07-13-2005, 11:03 AM
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).

Peter_dup1
07-13-2005, 03:20 PM
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.

Peter

zed
07-13-2005, 05:26 PM
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

Peter_dup1
07-14-2005, 09:19 AM
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.

Peter