What are dependant texuture reads?

Hello everyone, I asked this question in the begnners forum, but no luck. Can this be easily explained or can I find out about this somewhere? Thanks.

It’s when you read from one texture and use the result to address into the next texture.
For instance the texel fetched from texture0 may be (0.3, 0.5, 0.2) which will then cause a texel to be read from texture coords (0.3, 0.5) from texture1. This is just a simple example, but there are more advanced ways of doing it. With dependent texture reads you can use a texture as a lookup table, but this functionality is only available in Radeon 8500.

You might also want to read the very similar response I gave to your identical question in the beginner’s forum.


Actually Dependent texture reads can be done on the geforce 3. I just read a presentation thing from nvidia about pixel shaders (im sure it applies to the opengl extensions too) and they say that its possible now. Now on the older geforce cards it wasn’t possible but unless this thing i read from nvidia was wrong, it now can be done.


Yes, the GF3 is entirely capable of dependent texture reads. Most of the operations in NV_texture_shader are a dependent texture read of some sort or another.

I’m not sure what Humus meant by “With dependent texture reads you can use a texture as a lookup table”, since all textures are lookup tables, but if you want a post-filter lookup table, you can have one up to 12 bits pretty easily on GF3. Just use a 4096x1 texture and a DOT_PRODUCT_TEXTURE_2D operation.

  • Matt

Sure, GF3 is capable of dependent texture reads, but then so is Radeon classic, Kyro and even good ol’ G400. EMBM is a form of dependent texture reads. But when people are talking about dependent texture reads they often refer to more general ways of doing things than plain old EMBM, otherwise they would just say EMBM, unless of course they are talking about dependent texture reads in general with EMBM included. Whatever …

Anyway, the way GF3 does dependent reads aren’t all that much different than what EMBM does, I’d call it an extension to EMBM to support bumping of cubemaps plus some extra ways of looking up texture. But it’s still only a fixed number of ways of getting texels depending on previous stages. GF3 can do my example above, directly map a texel into a texture address of the next stage. But it cannot fetch a texel, do some math on it and then use the result to address into the next texture. That’s what I call fully general dependent texture read, and is currently only available in Radeon 8500. It’s not 100% perfect there too though, since you still cannot use the result from this second texture to lookup into yet another texture. But I’m not sure if there are many applications for such functionality though.

What I meant with using a texture as a lookup table is that if you want to get the value for an arbitrary function of two or three variables for instance sin(cos(A)-B) or whatever, you can just put these values into a texture and look these up from A and B from a fragment shader. A may be the result from some kind of math, B from something else. Then from the resulting A and B we can directly find the value in the texture. This cannot be done on a GF3. That was also the major disappointments John Carmack expressed over GF3 when it was released. He has also stated that it only got worked out right on Radeon 8500. Not that I really know anything about this, but this may be one of the reasons why Radeon 8500 is supposed to be able to render Doom3’s lighting in a single pass while a GF3 will need 2 to 3 passes.

EMBM is a much more restricted thing. It involves extremely minimal per-pixel math, and pays for it in quality and generality (e.g., it only really works on flat surfaces). It’s really not comparable.

The architecture of texture shaders plus register combiners can’t do everything (no 3D architecture can do everything). However, it can do a surprisingly large number of things. Remember that register combiners run really fast – GF3 can run 2 stages at full speed and 8 stages at just 1/4 speed; and those stages are significantly more flexible than standard texenv stages. That’s a lot of math per clock. Texture shaders are somewhat restrictive, but they do math in full floating-point and can do a fair amount of computation. The equation for reflective bumpmapping with a local viewer is not exactly a simple one, when you actually write it all out…

Also, keep in mind that since a texture is a lookup table (an arbitrary function of 1, 2, or 3 variables, or of a direction vector), you can implement a lot more in the way of arbitrary mathematical equations than you might think at first glance. In addition, some functions can be computed at the vertex level with reasonable quality, if you need to do a lot of heavy lifting mathematically.

I don’t want to get dragged into further discussion of this, but I just want the record clear. You suggested that the GF3 was not capable of dependent texturing, which is certainly not true.

If I may quote you:

“it cannot fetch a texel, do some math on it and then use the result to address into the next texture”

Surely, what DOT_PRODUCT_REFLECT_CUBE_MAP (among others) does meets this description to the letter.

Enough. I probably won’t reply to this thread again.

  • Matt

It wasn’t my intention to bring up a discussion about capabilities of what different cards has. I simply tried to answer djbuzzkill’s question and gave an example of a way to use it. I never suggested GF3 wasn’t capable to doing dependent texture reads, I just said that Radeon 8500 is the only card that is able to use a texture as a lookup table. How true that is depends on your definition of a lookup table. In my definition of what it means to use a texture as a lookup table a GF3 cannot do it, except for certain situations where the actual math your planning to do matches something from the palette of fixed functions to do lookups. Selecting from this palette isn’t anything I would call “doing some math”, but that’s just another matter of definition.


I mostly agree, I just want things to be crystal clear.

I still stand by my point that any texture is a lookup table, dependent texturing or not.

EMBM is a form of dependent texturing. So Matrox G400 was the first (consumer-range) card to support dependent texturing. (SGI has supported various forms of dependent texturing for some time.)

  • Matt

I think Humus needs some support here. The dependent texture reads as a lookup table is one of their more useful properties. Sure an ordinary texture is a lookup, but the lookup is of a linear (or hyperbolic) interpolation across a surface based only on a few supplied texture coordinates at the vertices. There are some things you just can’t do. Often being able to look up a texturing result is key to some operations, and more importantly key to being able to perform a series of operations some of which rely on the result of an earlier operation.

This was the reason the SGI shader work required pixel-texture as a prereqisite to support Renderman on vanilla OpenGL implementations + floating point framebuffer. The post texture lookup IS a key feature of dependent texture, which is in many ways analogous to pixel-texture where the framebuffer RGB addresses a texture coordinate.

Here’s the paper from the folks who concluded that this type of rgb lookup is essential for their shader work and a key property of functionality like dependent texture. Mainly because of the ability to apply a series of dependent lookup operations, not just one.

P.S. it looks like I was reading this thread & composing this while Matt was making his post.

[This message has been edited by dorbie (edited 01-10-2002).]

oki… letz explain it like this:

the ati radeon 8500 can do as first a perpixel dependend texture lookup with complretely variable input-values to implement any arbitary function wich is 1,2 or even 3d. this is not possible on gf3 because there the lookups are in front of the pixelshading. final point.

you can’t do perpixel specular on a gf3 matt you can’t.

The very first application I wrote at NVIDIA was a per-pixel specular program that ran on the original GeForce. So that’s not true.

Or, just look at Mark Kilgard’s md2shader demo. That’s per-pixel specular with shadows and arbitrary polygonal models.

  • Matt

The per pixel lighting demo by Ronald Frazier also does per pixel specular. And it was written for the geforce 256. His lighting model also does a lot of other stuff in additon. Its pretty cool. As is the md2shader demo. Didnt the geforce 3 come before the radeon 8500? Im sure it did and since it does support dependent textures, i dont see how people can say the 8500 was the first. :-/ Of course other cards even before the gf3 had it too, i think one from matrox or whatever.


[This message has been edited by SirKnight (edited 01-11-2002).]

Oh i almost forgot. Matt, did you ever release that demo you talk of? I dont remember ever seeing it.


I’ve done per-pixel specular on Geforce3 using a texture lookup. Could you explain more what you mean, Dave? Perhaps my method is not as general as you mean somehow?

– Zeno

this is suddenly confusing again

No, the only application I’ve written that was ever released on our web site was a simple demo for how to use EXT_vertex_weighting.

  • Matt