Texture Filtering and Indirections

[Paul Sernine]

I use many indirections in my fragment programs.
Most of the time, I use textures as Look-Up-Tables and I simply use bilinear interpolation.
But, sometimes, I use the contents of a first texture to offset/rescale the coordinates of a second texture.
In such a case, I need to use Mipmap and/or anisotropic filtering to avoid texture-fragment-program-aliasing.
I just cannot figure out how the Mipmap levels are calculated by the GPUs in such cases.
The link between the "tex coordinate generator" and the "tex sampler" is indirect. And so, their link is no more explicit.
So, how the compiler/GPU links the MipMap level (or more precisely, the texture coord gradient, calculated by the "tex coord unit" along with tex coords afaik) to the "tex sampler" ?
Is there an implicit mechanism ?
I read somewhere that DX PS3.0 allowed to access gradient information...
Maybe it is possible to use TXB in some way, but how ?

Arrrg, I have got an headache.

I tried to find documents or part of documents about this topic but I did not find any.

So I will be gratefull if anybody had a clue on this topic.

Paul

[endash]

I'm a little confused. Do you want to know how mipmap level is calculated in general, which is discussed in the red book, or just how it is handled in a fragment program (which I couldn't tell you off the top of my head).

[jwatte]

Here's one of many ways it could be done in hardware:

Suppose there are 4 fragment pipes. These all rasterize the same primitive (and some of them may be thrown away if it's at the edge). Suppose they are arranged in a 2x2 pattern.

Then you can calculate dx and dy as finite differences across the rows and columns for each of the fragments. This means that the dx and dy is the same for every cell of 2x2 fragments, but it's probably likely to look good enough. All you need (in hardware) is tight forwarding inbetween all these fragments; ie you can't issue texture read until you've calculated the texture coordinate for all four fragments, and they've made it across to their neighbors.

I'm sure there's a number of other ways this could be done, but this model hasn't given me anything drastically wrong out yet, so I'm sticking to it :-)

[Paul Sernine]

Excuse me, my question was not as clear as it can be.

Well, my question is not about how the gradient is calculated by the rasteriser (or texture coord unit). Typically there is simplified formulas to calculate the gradient along with the texture coordinates very efficiently.

So, I assume that the gradient information is implicitely associated with the texture coordinates.

Now, if you do not tweek your tex coordinates, the associated gradients can be easily and implicitely linked to the texture sampler.

But, if the tex coordinates are tweeked, I cannot figure how the link is done.

For example, you can mix two tex coordinates to access a texture :

LRP tex_coord,mix_coeff,tex_coord1,tex_coord0;
TEX color,texcoord...

In such a case, are gradients conveniently combined to obtain a mixture of the two ?

And you can imagine more complicated situations, including non-linear combinations and texture indirections.

By the way, I read that DX PS3.0 includes a new gradient instruction set. I hope that OpenGL would have an equivalent extension.

Paul

[Paul Sernine]

Excuse me, I was not very explicit in my previous post.

You do not need to have neighbour pixels to calculate the texture coord gradient. Tex coord gradients can be calculated analytically.

Here are documents including formulas for calculating gradient/partial derivatives along with tex coordinates.
http://www.hpl.hp.com/techreports/98/HPL-98-113.pdf
<a href="http://www.unc.edu/courses/2003spring/comp/236/001/Lecture18.pdf" target="_blank">http://www.unc.edu/courses/2003sprin.../Lecture18.pdf
</a>

Paul

[This message has been edited by Sernine (edited 03-04-2004).]

[This message has been edited by Sernine (edited 03-04-2004).]

[jwatte]

I suggested one way that hardware could implement texture coordinate gradient estimation in the case of dependent reads. That seems like it should answer your question.

[Paul Sernine]

Yes. That's a good idea but I am not sure it is the way they do it.
And it would be quite nice if it was done like that : there would be no problem with indirections.
The problem is that finite differences can be quite different from derivatives, especially with non linear texturing (for example environment-bump-maps).

Anyway, I did not find any doc on that topic.
I even browsed many ATi and NVidia Patents unscuccessfully http://www.uspto.gov .
I will let you know if I find any.

Paul

[Paul Sernine]

Just a partial info about this.

( But I admit that I still do not understand how partial derivatives are implicitely linked when indirections are used.)

- DX PS3 will allow the access to partial derivatives. NVidia will expose this in ARBfp1 with a specific extension (NV_fragment_programX (2 or 3))

- Within this extension, a new texture instruction will allow direct MipMap level selection (and not bias).

These facilities are cited in NVidia's GDC 2004 slides but their use is not described. From my point of view they are very important to avoid "shader aliasing".

Regards,

Paul

[Luis Perenna]

Originally posted by Sernine:
Just a partial info about this.

- DX PS3 will allow the access to partial derivatives. NVidia will expose this in ARBfp1 with a specific extension (NV_fragment_programX (2 or 3))

- Within this extension, a new texture instruction will allow direct MipMap level selection (and not bias).

These facilities are cited in NVidia's GDC 2004 slides but their use is not described. From my point of view they are very important to avoid "shader aliasing".

Regards,

Paul

Hi,

It is GL_NV_fragment_program2, it is described as a superset of PS 3.0.
The instructions listed in the GDC slide that may be of interest are
DDX Partial derivative relative to X
DDY Partial derivative relative to Y
I can't figure how they are calculated... by finite deifferences as suggested before or analytically (so they only can be applied to texture coordinates)?

and there is two new texture instructions
TXD texture sample w/partials
TXL texture sample w/explicit LOD

I have no idea how to combine these instructions to control MipMapping , but it really looks as if it is possible to do intricate things ,

whishes

[Paul Sernine]

Jwatte was right from the very begining : no analytic derivative calculations, just differences.

Here is an exerpt from slide from ATi GDC 2004 Direct X presentation :

Shader Antialiasing
- Computing derivatives (actually differences) of shader quantities with respect to screen x, y
coordinates is fundamental to procedural shading
- LOD is calculated automatically based on a 2×2 pixel quad, so you don't generally have to
think about it, even for dependent texture fetches
- The HLSL dsx(), dsy() derivative intrinsic functions, available when compiling for ps_2_a
and ps_3_0, can compute these derivatives

But it does not explicit the way it is done implicitely when you do not use these and you perform an indirection.

regards,

Paul