Ok, I’ve been having a recurrent problem with the X800 chip and running extremely simple GLSL vertex/shader program pairs.
Essentially what Ive got is a very simple multitexure blend demo which just passes through the position and a pair of tex coords. Sample both textures and mul the color…simple right?
Well apparently on the X800 the jist im getting is that some render state is defaulting the device back to software, so we’re getting about 2FPS on the X800, and all nVidia cards are running 95FPS+ Problem is right now what Im doing is so minimalistic that I cant really pin down whats causing it to do this. We’ve forced off any hw FSAA and Aniso.
This is with the current released catalyst drivers. So is there something really simple that Im just not getting about ATI/GLSL or, might it be a driver bug??
Well, the code that manages the GL state is pretty deeply embedded in the render mgmt code. The setup code is all very simple, there is one vertex buffer, and one index buffer allocated w/ STATIC_DRAW. Add the shader program object at init time as well.
I apologize if the code is very generic, but thats about whats going on there. Assured the code works for nVidia cards wonderfully. If there’s anything more specific needed I’d certainly be glad to post that.
Actually, when retrieving the link info log on the program object, the ATI card does return that the VP and FP would run on hardware. The nVidia card doesnt return a link log at all.
The slow down you’ve noticed is that the ATI renderer is reverting to a software rendering method that strictly follows the OpenGL specification instead of rendering incorrect results.
The Win32 OpenGL implementation doesn’t have a ‘pure’ mode (in DirectX language), or ’ AGL_NO_RECOVERY’ on MacOSX, that forbid software fallback.
Having the the software fallback happens for various reasons which are not (well) documented : it could be some various render states enabled even after the shader has been linked succesfully in hardware.
Such render states (i’ve noticed) that produces software fallback: line or point smoothing, enabling fog - under some specific circumstances -, rendering into a texture using an unsupported texture adress mode, or enabling transparency when rendering into a floating point texture, using the polygon offset (when access gl_FragCoord).
In your code, try to using the gl_TexCoord instead of using varying vec2, or using varying vec4 and pack your two varying vec2 into 1 vec4.
Call glUseProgramObjectARB(currentProgramObject); just before the glDrawElements, not before setting your vertex data.
Finally, try a simpler shader (gl_Position = ftransform(); / gl_FragColor = vec4(1.0,1.0,1.0,1.0)), and check if the software fallback is seen or not.
If all is not working, using ARB_vertex_program and ARB_fragment_program extensions, which are less prone to software rendering fallback on ATI (and generally better performer when correctly written).