I have recently (today) upgraded my drivers from Catalyst 5.2 to 5.9 and experienced unfortunate behaviour with a shader that previously worked fine under 5.2. The application now slows to a virtual halt (presumably because the shader is now in software).
I’ve isolated and simplified the offending line to a rather innocuous :
vec4 a = texture3D( TextureMap, vec3(0.0,0.0,0.0));
so it’s not an indirection issue or anything similar.
Without this line, the shader works fine. With Catalyst 5.2 and with this line, the shader works fine. With this line with Catalyst 5.6 or 5.9, I seem to drop back to software.
3DLabs’ GLSL Validate is completely happy with the shader. Card is a X800.
What’s changed since 5.2 which might be upsetting this? Any ideas appreciated!
The fragment shader has been stripped down to just this texture3D instruction and a gl_FragColor = vec4(1.0,1.0,1.0,1.0), so isn’t terribly enlightening.
Posting the full app will be tricky (large, lots of dependencies, etc.); however, I’ll try to generate a test app that falls over in the same way and post that. I guess it might be some peculiarity of the texture map; I’ll get the test app to load up the same map. Although of course, knowing my luck, I’ll never be able to reproduce the error in anything except for the full application…
The texture is 128x128x(doh!)6. In the same order, the wraps are _MIRROR, _MIRROR, _CLAMP_TO_EDGE.
I’ll retry with 128x128x8, and see if I get the same problem. I shouldn’t be using NPOT anyway - this fell through from the application (overly permissive user config parameters).
Thanks very much for spotting this anyway! Curiosity : Why the 5.2/5.9 difference?
I think Cat 5.3 was the first driver to support GL2.0, so on earlier drivers you most likely would just get an GL error when you tried to create a NPOT texture.