I am writing a small GUI system using openGL and Qt. I use the Qt TextWidget as the backend for my text rendering by updating a ARGB texture (600x100) with the content of the widget using glTexSubImage. Then the texture is displayed using a GL_QUAD.
This works fine with my nvidia card (GF8600) but freezes a colleagues ati (very recent card) machine for 5 to 8 seconds. During the freeze the cpu goes 100% until the texture is displayed.
Anyone having an idea what the cause of this behaviour is?
Well one good thing about GL is that when you have it working the way u expect then it’s working and nothing wrong with your code. Unlike D3D which behaves differently using the same correct code, this means you have two correct versions of code to achieve the same results. Let me simplify it this way:
GL code working on device X ==> this code is 100% correct
This statement is not true for D3D however. The point is ATI drivers sucks, so if you code working on one machine then it does not necessarily mean it’s working on ATI, and not working on ATI does not mean you have something wrong in you code.
With D3D because there are varying minor behaviour depending on the drivers and hardware, you may have 1 piece of code, which is 100% accurate, but it behaves differently on ATI and NV.
This is not true. There are situations when the specification states that the behavior is undefined (e.g. sampling from texture bound as render target, mismatch between depth compare mode on texture and sampler, not writing to gl_FragColor inside some path within the shader). If your program by mistake uses one from those states, it is not correct even if it might appear to work on one hw. Or the driver might be not as strict with the error checking as it should be (e.g. Nvidia GLSL compiler) so incorrect code will go unnoticed.
Well, the problem is that I claimed that my stuff will work without problem on all current OpenGL 2.0 hardware. Concerning the shader related functions this is true, but the simple texture update and rendering is creating this weird problem on the Ati card. Its just an operation with a small texture and causing an entire cpu core to go 100% for 5 to 8 seconds.
I have to get this working somehow … by workaround or whatever.
However, I can confirm that the Nvidia GLSL compiler is lazy since my shader coder compiled and worked without problem on the Nvidia card but failed to compile on the Ati card (respective the driver).
Is the time consumed during upload or during render? (i.e. if you draw the texture more than once before next upload, are the additional renders fast or slow?) If all renders are slow, check if you are using mipmaps or nonclamping texture wrapp modes (the default mode for textures is the GL_REPEAT). They are not supported in hw for NPOT textures on ATI hw before the HD 2x00 series.
The texture clamping was the culprit. When I changed it to GL_CLAMP it worked without problem. GL_REPEAT caused the freeze. The ATi card used is a Radeon X1950. I would have never thought of that modern graphics cards can’t do all texture wrapping modes.
Radeon X1x00 hardware does not support REPEAT with NPOT textures. So your 600x100 texture will fall back to software rendering, if you are using the TEXTURE_2D target. If you use TEXTURE_RECTANGLE_[NV, EXT, ARB] it will run in hardware (and default to CLAMP_TO_EDGE.)
This behavior is required, if the driver wants to claim to support OpenGL 2.0. The spec says it has to work-- it doesn’t say it has to be fast. But, software fallback is not necessarily unusable-- Apple’s NPOT fallback can render that 600x100 quad at 60 fps. 5 spf just means that the Windows driver isn’t optimized.
