Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 9 of 9

Thread: shaders for imaging workaround problem

  1. #1
    Intern Newbie
    Join Date
    Apr 2004
    Posts
    45

    shaders for imaging workaround problem

    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???

  2. #2
    Member Regular Contributor
    Join Date
    Apr 2002
    Location
    Austria
    Posts
    328

    Re: shaders for imaging workaround problem

    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;
    There is a theory which states that if ever anybody discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable.

    There is another theory which states that this has already happened...

  3. #3
    Junior Member Regular Contributor
    Join Date
    Jun 2003
    Posts
    177

    Re: shaders for imaging workaround problem

    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).

  4. #4
    Intern Newbie
    Join Date
    Apr 2004
    Posts
    45

    Re: shaders for imaging workaround problem

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

  5. #5
    Super Moderator OpenGL Guru
    Join Date
    Feb 2000
    Location
    Montreal, Canada
    Posts
    4,264

    Re: shaders for imaging workaround problem

    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.
    ------------------------------
    Sig: http://glhlib.sourceforge.net
    an open source GLU replacement library. Much more modern than GLU.
    float matrix[16], inverse_matrix[16];
    glhLoadIdentityf2(matrix);
    glhTranslatef2(matrix, 0.0, 0.0, 5.0);
    glhRotateAboutXf2(matrix, angleInRadians);
    glhScalef2(matrix, 1.0, 1.0, -1.0);
    glhQuickInvertMatrixf2(matrix, inverse_matrix);
    glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
    glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);

  6. #6
    Intern Newbie
    Join Date
    Apr 2004
    Posts
    45

    Re: shaders for imaging workaround problem

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

    Code :
    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

    Code :
    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 ..

  7. #7
    Super Moderator OpenGL Guru
    Join Date
    Feb 2000
    Location
    Montreal, Canada
    Posts
    4,264

    Re: shaders for imaging workaround problem

    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.
    ------------------------------
    Sig: http://glhlib.sourceforge.net
    an open source GLU replacement library. Much more modern than GLU.
    float matrix[16], inverse_matrix[16];
    glhLoadIdentityf2(matrix);
    glhTranslatef2(matrix, 0.0, 0.0, 5.0);
    glhRotateAboutXf2(matrix, angleInRadians);
    glhScalef2(matrix, 1.0, 1.0, -1.0);
    glhQuickInvertMatrixf2(matrix, inverse_matrix);
    glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
    glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);

  8. #8
    Junior Member Regular Contributor
    Join Date
    May 2003
    Location
    Germany
    Posts
    229

    Re: shaders for imaging workaround problem

    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.

  9. #9
    Junior Member Newbie
    Join Date
    Apr 2001
    Location
    Sunnyvale
    Posts
    26

    Re: shaders for imaging workaround problem

    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •