GLSL problems with catalyst >= 4.8 , shader designer , and pbuffers?


I have this very strange problem with GLSL on a radeon 9600 128Mo board, running catalysts drivers 4.8 and upwards :

I use shader designer as GLSL IDE, and many of the shaders that use multitexturing do not work.

For instance, running the bumpmap shader yields a teapot textured with the actual bump map texture as diffuse color, the environment map shader will just produce a green teapot,

Even more strange is that the brick shader will just give me a red teapot with a single green brick, the gooch shader does not work either…

And I have other porblems with pbuffers like being unable to write into the back buffer of a double buffered pBuffer, and unable to use the back buffer as a texture.

I had to switch back to catalyst 4.7 to get the shaders of shader designer work again, but I still have this problem with render-to-texture, pbuffers and back buffer rendering and texturing. I know that the pbuffer extensions are wgl* extensions, so that they’re windows API related, but I thought they were exposed to the GL programmer through the catalyst driver?

The strangest aspect of this “bug” is that the render monkey 1.5 GLSL examples seem to work (except for a few of them, like the bounce shaders which gives me three white spots on the screen)

My own shaders work, but they’re very simple stuff.

I already notified this problem to typhoonlabs, which could not help me.

If someone could try this to see if it is reproductible? or could give me some hints with multi surface pbuffers and back buffer rendering…

Btw I’m running a P4 2.5 with XP SP2, radeon 9600 128Mo with catalyst 4.7 (4.8, 4.9, 4.10 do not work at all for me)at the present time.
And the problem was reproduced on a Radeon 9600 mobility laptop.

Thank you…


I’m from TyphoonLabs. If anyone could reproduce this bug, I would open a bugreport to ATI, and we could work together to fix this issue.


This sounds like a bug I reported months ago. I suffered from single-coloured objects, too. The bug got “introduced” with Catalyst 4.6(!!!) and is still present in 4.10. ATI could reproduce it. We found out that the odd texture matrices (gl_TextureMatrix[x]) don´t work in GLSL as expected. Instead they don´t get filled properly (using glLoadMatrix). Some of those flawed matrices are filled with zeroes, so using them results in a single texel being stretched over the whole object. Is this the same that happens to you?

It also happens in the program I’m writting. It worked with Catalyst 4.7 (and with non-ATI hw) and when I updated to 4.10 my bumpmap shaders didn’t work properly wiht the same problem described here.

I’ve been testing and it is very strange. It is like some uniforms don’t have the value that should have and have the value of other uniforms…

Hope this helps.

to SKYNET : would you have a simple glut app that demonstrates the problem you had back then? I want to run it here to see if it gives the same symptoms.

to clarify my first post :
-under shader designer : some shaders do not work, and show the symptoms described above, but they do not use pbuffers.

-the shaders in my application run fine, the app does not use the texture matrix. My problem is with pbuffers, I can’t draw to the back buffer of a double buffered pbuffer, nor use it as a texture (same with aux buffers).

so there are two distinct problems here.

I have no sample app, sorry. But it should be easy for you to try out. Humus was my contact person at ATI in this case. He should know best about the bug.
So: HUMUS would you please inform us about the state of it? When will it (and the others :slight_smile: be fixed?

The gl_TextureMatrix bug I’m afraid hasn’t been fixed yet. I don’t remember getting any status change notification about that bug, but I’m at home now so I can’t check.

The gl_TextureMatrix[] bug just got fixed.

Originally posted by Humus:
The gl_TextureMatrix[] bug just got fixed.
I think that the bug exposed by ‘relmas’ at the beginning of this thread is not related with gl_TextureMatrix[].
It happens from Catalyst 4.8 (not 4.6 as the gl_TextureMatrix problem) and you can test it in ShaderDesigner

This particular problem seems to be fixed in Catalyst 4.11

confirmed, the bug is fixed with catalysts 4.11

on the other hand, my HW accellerated raycaster (uses GLSL vertex/fragment shaders) does not work anymore… it gives me rubbish on the screen, as if it was reading random numbers instead of textures.

This needs more investigation.

To humus : when will ATI start to “communicate” on the GLSL support status? nVidia seems to have taken a leap forward with respect to GLSL… sad.

What kind of communication do you find lacking? If you need any info you can always email me and I’ll see what I can dig up. The same goes with bug reports.

The release notes of the catalyst drivers never hold any information on GLGL support status. From a driver version to another so things get broken, others still work… Would be nice to have a GLSL bug fixes/pending bugs list with each new release of the drivers. Would save some time in trial and error.

Sad but true. As developer you never get any feedback from ATI about the status of reported bugs, if you don´t explictely ask for it. The only thing you can do is to download new drivers, see if the bug is still present or not. I many cases the bugs are in the drivers for months (see gl_TextureMatrix bug, introduced in pre 4.6 betas in MAY!). I don´t like writing letters to ATI over and over again, describing the same thing over and over again, asking for the status of certain bugs over and over again. Once, I got a bug-number back, which was quite handy because I could refer to it. But it was the only time I got such thing :frowning:
Even as registered developer you only get a login where you can download some betas. There´s absolutely NO information on how these drivers differ from the latest official ones, NO information what got better/fixed and which issues are still open. Always trial and error. Sometimes these betas are even older than the latest official drivers. What sense does that make?
As developer I´m not interested if game XY got 0.5% faster or game ABC doesn´t show flickering textures anymore. I want to know if for instance gl_SecondaryColor is finally working in GLSL and so on. If ATI would have a public (at least to registered developers) accessable list of known bugs (along with their status), nobody would be urged to start long threads at in order to see if any other has experienced the same problem. Instead he would look at the list, see if his problem is already known and if yes, just wait until its status switches from “being worked on” to “fixed”.

Ok, enough ranting for today :slight_smile:

Skynet, couldn’t have expressed it better :wink:
So, Humus, Xmas is coming soon, nice period to start setting up a GLSL info page over at ATI-dot-com :smiley:

Well it’s not really true.

I had problems with GLSL few months ago - when they used to have that ‘GLSL Beta program’. ATI dev support was very kind and send me updates and fixed many problems in their drivers. I remember also once they gave me drivers with new extensions to test few years ago. So don’t blame ATI dev support. They are quite good.

But, this year I was feeling that things got worst .
It’s true that since the Catalyst 4.8 things went terribly wrong with GLSL implementation (OpenGL implementation in Catalyst 4.12 is a catastrophe, although they are still beta, they broke more things that they fixed. I intend to report the problem soon, although having a bugzilla should be very handy).

I suspect Doom 3 to be the cause of that. They probably had to rewrite a lot of OpenGL code, breaking many things that were fixed in the past, focusing on the game’s performances rather than compatibility. (I hope I’m wrong about that :frowning: )

The only good thing is their Direct3D 9.0 support. It just terrific : very stable, never ever had any problem with that, very performant.

Talking about drivers and GLSL, it would be good some linux drivers with proper GLSL support could come out quickly, because more and more people rely on linux for clustered computing and HW accelerated rendering.

For instance we have a clustered computing project maturing right now here in Toulouse, France, it’s gonna be a linux based, 120 dual-opteron-machines cluster, dedicated to, among other things, CFD Adaptive Mesh Refinment computation, and distributed CPU/GPU raytracing. My role in the project is to plug an interactive volume renderer on top of that to be able to monitor the computation as it runs.

I’m prototyping the app under winows right now because the cluster isn’t ready yet, but there is a lot of hesitation concerning the graphics hardware that is to be fitted on a few of the 120 nodes. I was pushing for ATI hardware because of the GLX_ATI_render_texture extension and the fragment shading power, but then we figured out the GFX boards had to be PCI-X, but the choice will be made on the GLSL support and floating point blending.

On the other hand, the newly bred SGI PRISM machine runs linux (or IRIX) and uses ATI FireGLs… The machines relies on openGL + shaders. But maybe they’re still coding their shaders using ARB ASM instead of GLSL.


If you plan to use a Linux cluster, choose nVidia instead:

Read thoses articles:

It’s a better solution. Unlike the current ATI drivers (which barely runs Doom 3, although it was recently fixed), there is 64-bit OpenGL, OpenGL Shading Language available right now.

However, if you still want ATI, and want information on the GLX_ATI_render_texture, get GLEW. Apparently they’ve got this GLX extensions supported

And it is in glxew.h
I don’t know where they’ve got the specifications.

I’ve found this as well for you:

thank you execom_rt for those links, I think the choice has settled on GF6800 boards. We still have to wait for PCI-X boards, so I think we’ll go for a pair of 6600 to keep us busy while waiting for the bigger sisters.

Originally posted by relmas:
The release notes of the catalyst drivers never hold any information on GLGL support status. From a driver version to another so things get broken, others still work… Would be nice to have a GLSL bug fixes/pending bugs list with each new release of the drivers. Would save some time in trial and error.
The release notes aren’t intended for developers, they are intended for the end users. They never contain any detailed technical info. This isn’t specific for GLSL or OpenGL. It doesn’t contain any API level info on the D3D side either. As for list of bugs, assembling such a list would either require quite a lot of manual labor or be too verbose to be all that useful. In a company of ATI’s size, many engineering problems are reported every day.