shaders for imaging workaround problem

[andreasMank]

i wrote a little smoothing fragment shader ..

int i;
vec4 sum = vec4(0.0);


for(i = 0; i kernelSize; i++)
sum += texture2D(baseImage, gl_TexCoord[0].st + offset[i]);
gl_FragColor = sum * scaleFactor;

.. because of the not yet implemented loop constucts i started a little workaround .. with some explicit function calls so i don't need the for loop ..

sum += texture2D(baseImage, gl_TexCoord[0].st + 1.0);
sum += texture2D(baseImage, gl_TexCoord[0].st + 1.0);
sum += texture2D(baseImage, gl_TexCoord[0].st + 1.0);
sum += texture2D(baseImage, gl_TexCoord[0].st + 1.0);

.. now i get the message "fragment shader will run in software avaiable number of texture indirections exceeded." .. what the hell?????? is it an compiler problem for ati cards like the loop constructs??? is there any card .. supporting all stuff discribed in the glsl spec???

[Corrail]

Hello!

Try the following:

vec4 sum;
vec4 tex = gl_TexCoord[0].st + 1.0;
vec4 tex_sample = texture2D(baseImage, tex);
sum += tex_sample;
tex_sample = texture2D(baseImage, tex);
sum += tex_sample;
tex_sample = texture2D(baseImage, tex);
sum += tex_sample;
tex_sample = texture2D(baseImage, tex);
sum += tex_sample;

[al_bob]

is it an compiler problem for ati cards like the loop constructs???

It's a hardware limitation. Instead, compute the offsetted texture coordinates in a vertex program, then use this directly in the fragment shader.

ATI cards currently only support 4 dependent texture reads (ie: when the texture coordinate is computed in a fragment program).

[andreasMank]

what does a texture indirection mean ?? is it the gl_texCoord call or the texture2D call ???

[V-man]

Indirection means there is a dependency on something, but it should really be called a indirection island or set.

For example, I could rewrite your original code like this :

vec2 a=gl_TexCoord[0].st + 1.0;
vec2 b=gl_TexCoord[0].st + 1.0;
vec2 c=gl_TexCoord[0].st + 1.0;
vec2 d=gl_TexCoord[0].st + 1.0;

sum += texture2D(baseImage, a);
sum += texture2D(baseImage, b);
sum += texture2D(baseImage, c);
sum += texture2D(baseImage, d);

and it should work.

On R3xx, you can have at most 4 such islands.
On NV3x, I think it's always 7.
In each island, you can do many texture sampling (limited by Max TEX instructions).

Islands of tex instructions are separated by ALU instructions.

Even if you have 0 TEX instructions, it counts as 1 indirection.

If your first instruction is a ALU instruction, you lose 1 indirection.

Something to do with how the GPU works, so you should group your TEX instructions.

[andreasMank]

i used your example code in my shader and it doesn't work .. so i change it like this ..

vec2 e=gl_TexCoord[0].st; 
vec2 a=e + 1.0;
vec2 b=e + 1.0;
vec2 c=e + 1.0;
vec2 d=e + 1.0;
 
sum += texture2D(baseImage, a);
sum += texture2D(baseImage, b);
sum += texture2D(baseImage, c);
sum += texture2D(baseImage, d);

ok this works .. but if i add one vec2 f=e + 1.0; my shader will run in software mode .. because of number of texture indirections .. can see why there is now one more texture indirection .. but i'll try to believe .. now i can start to change the code .. perhaps it will work with one more texture2D call .. the problem is to write a gaussian blur with variing kernel size .. the kernel size should depend on a blur map .. the varring kernel size i can implement using

if (kernelSize == 3);
  ..
if (kernelSize == 4);
  ..

like this i don't have problems with the not yet implementet loop constructs .. b ut my kernel should vary between a 3x3 and 5x5 matrix .. which means between 9 and 25 texture2D calls ..

.. is there anybody who succeeded in implementing a blur imaging shader with this limitations of indirections ???

.. i read some coments to do the texture calcaulations in vertex shader .. i have no idea how it should work, because the values depents on the fragments not on the vertices ..

[V-man]

ok this works .. but if i add one vec2 f=e + 1.0; my shader will run in software mode .. because of number of texture indirections .. can see why there is now one more texture indirection .. but i'll try to believe .. now i can start to change the code ..

Neither form should cause a problem and the tex indirection would be the same. The driver must be trying to optimizing or something and messing up the instruction order. ATI was suppose to fix this by now.

I have done what you are attempting, but with arbfp.
I was even gone try a 7x7 kernel but couldn't.

Also, it's not a good idea to have "if else" on ps2.0
Write separate shaders for each case.

[PanzerSchreck]

The problem mentioned here has been discussed many times here (including a thread started by me) and it's a problem with ATI's current glsl-implementation I guess. This problem was present in ARB_FP and they fixed it, so there are chances that they'll fix that in their glsl-implementation too.

[glitch]

Hi all,

i resurect this topic to spot that the newest radeon driver (4.6) seems to resolve the texture indirection problem
Now only waiting for sample2DRect support

cheers