arb_fragment_program + ATI = slow

I am implementing a shadow map algorithm with fragment programs and my program works fine on Nvidia cards, but when I test it on ATI cards the alg. doesn’t work. The 1st problem that I noticed was that ATI does NOT support ARB_fragment_program_shadow. Does anyone know why that is? But I found a work around for this problem. The 2nd problem that I noticed was that my alg. runs extrememly slow on ATI cards and I have narrowed it down to one line of code that is slowing the whole program down.

ATTRIB pos = fragment.position;
MOV outColor, pos; # causes program to be slow

My question is: Does anyone know if there is an issue with ATI and fragment.position? Or does anyone have an idea of how to get the fragment position into the fragment program through a “backdoor”?

Thx in advance.

ARB_fragment_program_shadow is not support on current shipped ATI hardware because it requires GL_DEPTH_COMPONENT texture which are not really well supported.

For the slow down, are you using GL_POLYGON_OFFSET ?
If yes, disable it. It’s a known problem on ATI. When using GL_POLYGON_OFFSET and accessing to fragment.position, the hardware acceleration is disabled.

Thanks a bunch that fixed the problem!!!

For future reference: How did you figure that out? Or where did you read/hear that that was a problem?

Originally posted by execom_rt:
ARB_fragment_program_shadow is not support on current shipped ATI hardware because it requires GL_DEPTH_COMPONENT texture which are not really well supported.
ARB_fragment_program_shadow has been supported since Catalyst Version 4.5 (that’s just over a year ago).

ARB_fragment_program_shadow itself was approved December 16, 2003.

-mr. bill

For the slow down, are you using GL_POLYGON_OFFSET ?
If yes, disable it. It’s a known problem on ATI. When using GL_POLYGON_OFFSET and accessing to fragment.position, the hardware acceleration is disabled.

Are there any other openGL calls that could cause hardware acceleration to be disabled?

Are there any other openGL calls that could cause hardware acceleration to be disabled?
Oh, I’m sure there are plenty of others that could do it. But there’s no way to know which ones will except by finding (obscure) documentation and running into them by accident.

Originally posted by burnettryan:
[b] [quote] For the slow down, are you using GL_POLYGON_OFFSET ?
If yes, disable it. It’s a known problem on ATI. When using GL_POLYGON_OFFSET and accessing to fragment.position, the hardware acceleration is disabled.

Are there any other openGL calls that could cause hardware acceleration to be disabled?[/b][/QUOTE]i ran into a similar problem when accessing fragment.position in an arb_fp when drawing simple points that werent one pixel in diameter… seems ati hardware cant handle those either :slight_smile: (worked fine on nv3x hw)

Yes, there is more situations like that. If happens, just pop the question and I will give you the answer

Here is a list of problems I had with ATI:

  1. When rendering fat points and accessing gl_Fragcoord in the fragment program, slow

  2. If there is too many varying variables, fragment program slow down

  3. Some internal derived states are not set such as gl_ProjectionMatrixInverseTranspose

  4. Compiler log some time show “unknow error E0004”, but the linking is ok.

  5. If there are too many varying variables, the linker complains about not enough registers and the vertex shader will run in software

  6. If there is “unsupported internal format” encountered in the fragment program, the linker complains and the fragment shader will run in software. I guess gl_FragCoord is one of the unsupported format, at least for fat points.

  1. If there are too many varying variables, the linker complains about not enough registers and the vertex shader will run in software
    thats cool, software emulation. in this situation with nvidia it just doesnt run at all
  • There is also fog with GLSL in some situations (still reproduced in Cat 5.3)

  • When mixing ARB fragment program, PBuffer and GLSL, rendering got corrupted (slow down and vertex jumps across the screen). Also something shader is simply not executed.

  • Playing Doom 3 during 15minutes (I had to use the atioglx.dll from Cat 4.12 copied into the Doom 3 directory, in order to play, else I need to exit and relaunch the game after 15-20 mins, the game run too slow (like so slow that getting back to the game menu takes 10-20 seconds).

Originally posted by zed:
[quote]5. If there are too many varying variables, the linker complains about not enough registers and the vertex shader will run in software
thats cool, software emulation. in this situation with nvidia it just doesnt run at all
[/QUOTE]yes, but sometime it falls back to the software rendering AFTER the shader linking.

It turns out the the problem was when I was setting a GL_POINT to a size larger than one pixel (e.g. glPointSize(2.0)). Once I changed the size to 1.0 the arb_fp runs fine on both ATI and Nvidia.

Thx to all of those how responded so quickly.