ABRfp 1.0 texture lookups

Anyone know how many texture lookups I can do in a fragment probram profile ARBfp 1.0?

it chokes after six on my ATI FireGL X2 for some reason… normal?

Call glGetProgramivARB(GL_FRAGMENT_PROGRAM_ARB, GL_MAX_PROGRAM_TEX_INSTRUCTIONS_ARB, &numTexInstructions) to query the number of texture instructions allowed by your GPU.

= 32
not sure why it fails…

Most likely texture indirections, try calling glGetString(GL_PROGRAM_ERROR_STRING_ARB) to get a more detailed error message from your GL implementation.

thanks for your help. I managed to figure out that it was indeed texture indirections.

I’m doing a sort of blur and need to mess around with the texture coordinates before every fetch. I’m am right when I say that the minute you screw around with texture coordinates inside a fp, you get an indirection when you fetch?

Originally posted by flamz:
[b]thanks for your help. I managed to figure out that it was indeed texture indirections.

I’m doing a sort of blur and need to mess around with the texture coordinates before every fetch. I’m am right when I say that the minute you screw around with texture coordinates inside a fp, you get an indirection when you fetch?[/b]
Not quite. You can use fragment.texcoord[n] as an input to calculations without creating an extra level of dependency. Eg you can “safely” do this:

!!ARBfp1.0
MUL result.color,fragment.texcoord[0],fragment.color;
END

An indirection refers to using a computed result as a texture coordinate (ie as an input) for a texture lookup instruction (TEX or TXP) … as opposed to a straight interpolated fragment.texcoord[n], which does not constitute an extra indirection.

I hope this made sense :slight_smile:

Perhaps also do a get for GL_MAX_PROGRAM_TEX_INDIRECTIONS_ARB
to see what your card supports.

Then do a get of
GL_PROGRAM_TEX_INDIRECTIONS_ARB
after you load the program to see how many indirections you make in the program.

It also helps to group as many tex load instructions together as you can. For ATI hardware, even using some temporaries can help (although NVIDIA hates temporaries).

Assuming you have a bunch of deltas off a center point, with attached weights, to implement a blur filter, you might do something like this (I forget the exact syntax – been in HLSL land for too long):

ADD temp1.xy, texcoord[0], deltas[0];
ADD temp2.xy, texcoord[0], deltas[1];
ADD temp3.xy, texcoord[0], deltas[2];
ADD temp4.xy, texcoord[0], deltas[3];
TEX temp1, sampler1, temp1;
TEX temp2, sampler1, temp2;
TEX temp3, sampler1, temp3;
TEX temp4, sampler1, temp4;
MUL temp1, temp1, deltas[0].w;
MAD temp1, temp1, temp2, deltas[1].w;
MAD temp1, temp1, temp3, deltas[1].w;
MAD temp1, temp1, temp4, deltas[1].w;

This will make it very clear that you’re using one indirection before the tex instructions, and there’s no dependency between tex instructions. Otherwise, the driver may believe there are dependencies even when there aren’t. For example, if you texture into a temporary, and then re-use that temporary for some other value, and then use that other value for the next texturing, the drivers may believe it’s an indirection. Use separately named temporaries instead (the drivers can often do coloring/merging to optimize these out).

Also make sure you have the latest ATI drivers. The drivers ability to recognise what actually is an indirection and what can be optimised away varies pretty wildly between versions.