Once again: glsl/pbuffer issues

using 5 RGBA 32 bit floating pbuffers, all with own render context and wglSharedList with main rendering context.

//in fragment shader
uniform sampler2D	LightingPointPosition;
varying vec2		TextureCoord;
void main(void) {
    gl_FragColor = texture2D(LightingPointPosition, TextureCoord);
}

I bind a floating texture to a unit and set the uniform. Then I render the same thing in a for-loop to the different buffers and read the result back to check the result, and:

for the first pbuffer the first several thousands values are incorrect, some strange values, no idea where there are from, but after that there are the correct/same values like in my floating point texture. I checked the texture corrdinates and they are correct and should correspond for all pixels to the values from the original texture.

for the other pbuffer I only get (0,0,0,1) which afaik means no texture is bound? But I have, and I do for every pbuffer exactly the same thing, so how can the results differ?

Any ideas why the first several thousand values are not from the original texture, and why after the first pbuffer the others don’t work at all? If I loop the loop several times always the first buffer works half correctly, in the others I get the (0,0,0,1) values.

mhh, with some tests while writing this post I got several runnings with the several first pixels with strange values, and now without changing anything at the vertex-, texture coordinates, debug output log routine or the texture data got several runnings with the first pbuffer rendering completely correct values
I have the strange feeling there are some non-deterministic effects… Has anybody else already seen non-determinstic buggy behaviour with pbuffers/glsl on ATI? This is at least the third time where there is a really strange behaviour using glsl/pbuffer on ATI. Could this be a hardware issue? On the other hand, haven’t noticed any strange problems with games and so on, so either its a very strange driver bug or just some complex error reasons I don’t understand…
But indendent from this, the first buffer works(somehow) the others not is a quite reproducible problem till now…

using: Radeon 9800 + catalyst 4.11

Ok, I’ve found a workaround. If I link the glsl program in every pbuffer before rendering I get the correct results. Only unbind/bind the program doesn’t work, I have to glLinkProgramARB after every pbuffer switch, before rendering. Otherwise only the first pbuffer works correct.

Is that yet another ATI driver bug not handling multiple render contexts with glsl correct? Or are you supposed to always relink shared programs in different render contexts after switching contexts?

My idea was to create the shaders and textures in the main render context. Create the 5 pbuffers, wglShareLists, and then set in every pbuffer render states like bind shader, textures and buffers and then in a for-loop make pbuffer current, update some uniforms and execute draw command. Is there something in the pbuffer/glsl specs which would prevent such an algorithm?

btw: the relink is only necessary if I access textures, when I just write a constant value in the shader it works without relinking…

:mad: :mad: :mad: ok, now it get really weird:

The workaround don’t really work always. I just wanted to go back to my non-trivial shader, and there were again strange results. I then tried the trivial “only texture to FragColor shader” and despite the relinking it didn’t worked correctly . But instead of (0,0,0,1) for undefined texture it only rendered (0,0,0,0). (I always double checked, original texture read back and rendered result) Very strange. I then rebooted my system and run my programm again without changing the trivial shader or recompiling of the programm and I got the correct results. I then removed the shader relink workaround, recompiled and there again was the (0,0,0,1) error.

So now my question: Is this more likely a hardware defect? Or is the ATI driver totally ****ed up when confronted with several pbuffers/render contexts and glsl (and floating point textures?)?

It’s completely weird and really piss me off :mad: But is it hardware or driver related? For a driver bug it is really weird, but I haven’t other problems with my graphics card with games or graphic demos. I only had problems with the use of non-trivial glsl/pbuffers combinations. Could it be that pbuffers are not only tricky to use but also on driver side completely broken with glsl in this case resulting in such strange results? Are there any working examples of non trivial render algorithms using glsl, pbuffers/render contexts with shared shaders and floating point pbuffers/texture extensively on ATI hardware?

For me, Catalyst 4.8 to 4.11 (and 4.12 beta) are not working properly with glsl and some shaders, and I’m not using pbuffers. 4.7 worked better for me.
There are more people with this kinds of problems.
http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=11;t=000492

Hope this helps.

haven’t tried 4.7 yet but with the today released official catalyst 4.12 the bug is still present, and the workaround still works. But relinking the shader for every rendering after a pbuffer switch isn’t that nice…

It’s really a shame that over one year after the first specs and first beta support there still are no reliable glsl drivers

This is a known driver bug that got introduced in Cat 4.11 IIRC. Previous drivers worked fine.

really? Are you sure?

I have now tested 4.12, 4.11, 4.10 and 4.7 (puhh, driver installing and rebooting suck) and no one worked correct.

With 4.7 I didn’t had to relink the shader but had to unbind/bind the shader as workaround. And I again had the strange effects that with 4.10 after trying without the relink workaround the relink workaround only worked again after a reboot. And sometimes with the workaround the first several 1000 pixel were (0,0,0,0) and the rest correct.

Had glsl/pbuffer really worked for non-trivial pbuffer use before? Till now I only had trouble with them. Simple render scene to pbuffer works without problems but other things not. Perhaps it also has to do with floating point textures/buffers?

Altogether glsl/pbuffers seem not to be seriously useable on ATI

btw just for the record: the corruption of the first several thousand pixels appeared also on another ATI card. So additional to the not correct sharing of glsl shaders across render contexts there seem to be a bug with shared float texturing or glsl pbuffer rendering itself.
I’ve tested it also with local/unshared shaders with reading from shared floating point texture. Sometimes the first thousand pixels consist of data trash, sometimes they are correct. And no, it couldn’t be that the first thousand pixels didn’t got rendered, because I’m rendering a screen aligned quad and double tested with clearing the pbuffer before rendering. The resulting pixel are some data trash (sometimes 0,0,0,0 sometimes random values)… I’ve tried it with catalyst 4.7 - 4.12 and have seen the problem with all versions, so this is another bug, and I have seen the bug now on two different cards, so this is not an issue caused by defect hardware.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.