Something thats been bugging me for quite a while now.
What is with the discrepancy between texture stages, and actual texture units?
I have a Halo/Bungi/Nvidia advert mpeg on my machine that states a Geforce 2 GTS has support for 8 textures at full speed.
At work today, someone on the opengl mailing list was mentioning why some people say Geforce 3’s have support for 8 texture stages, yet only 4 of them can be actual textures.
When people say 8 texture stages, are they basically talking about the General Combiner Stages?. I thought the GF2 only had 2 of those, Not 8?
It’s my understanding that a texture stage is what you are accessing with the texture shader code. Sortof slightly programmable area for transforming interpolated texture coordinates into RGBA fragments. Right now GF3 has four of those that can operate in parallel (i.e. 4 2d textures) or in sequence(bump-reflect).
A texture unit, I think, is an area where a bound texture goes. Since the GF3 can access 4 textures per pass, it is said to have 4 texture units.
I think the statement you are referring to had to do with D3D’s concept of a texture stage. Texture stages don’t necessarily have a texture attached to them, but they allow a simple math op like add, dp3, etc. Most HW would report more than the physical stages, because the operations were simpler than what the HW could do in a simple stage and stuff would collapse. Naturally, with D3D’s ValidateDevice semantics, not all combinations of 8 ops needed to be allowed.
I always thought that what they meant was the number of pixel pipelines multiplied by the number of texture units. For example, GF2 = 2 texture units X 4 parallel pixel pipelines = 8 texels at once.
If you look at the way multitexture works with the register combiners this becomes clearer.
The 8 texture stages I assume are the register combiners including the final combiner each of which can do things like take 4 independent color registers in and combine them in fancy ways, like dot products, addition, modulation etc.
Now the colors available to feed into the register combiners include 4 texture units generated from independent texture coordinates filters and images. You can also use fragment color from lighting, separate specular color constant color, fog etc. in the stages.
Looking at the system this way you can apply 4 textures and combine them in interesting ways using 8 stages. Think of it as having 4 textures but 8 really fancy texenvs, one of which is a bit more specialized than the other seven.
Using this nomanclature you can for example feed 4 textures into a single stage and combine them in interesting ways, so don’t take the texenv analogy too literally.
OK, I think this is slowly becoming mired in terminology.
First of all, what a texture stage is is basically undefined, because nobody can quite agree on what it means. Therefore, let’s use OpenGL terminology.
Un-extended Multitextured OpenGL has things called Texture Environment Stages. For every texture unit, there is a Texture Env stage (parameters for which are set with glTexEnv commands). These TexEnv parameters control how texture colors are combined with the incoming color.
Each TexEnv stage is associated with a texture map. A TexEnv stage has 2 inputs: the color from the previous TexEnv stage (or the interpolated per-vertex color if this is the first TexEnv stage), and the texture color. Since each TexEnv stage is associated with a texture, there are only as many TexEnv stages as there are texture maps. The number of texture units denotes the number of texture maps, so the number of texture units and TexEnv stages are equal.
All of this is assuming basic OpenGL 1.2 multitextured functionality. If you move on from there, you get even looser restrictions on TexEnv’s. For example, ARB_Crossbar allows any TexEnv to use the texture color from any texture unit. If I understand the spec correctly, it even allows one TexEnv to use the texture color from 2 texture units.
The most powerful forms of “texture stages” comes from extensions like NV_Register_Combiner or ATI_fragment_shader. In the case of register combiners, they completely uncouple texture access from color combination. In a GeForce3, there are 4 texture units, but there are 8 actual color combination stages (each of which can perform 2 of most operations), plus a final computation stage.
Fragment shaders are a little different, conceptually, as they completely shatter the entire TexEnv/Texture unit idea. Texture addressing and color combination happen in an arbituary program.
All you’ve said is that a register cobminer is not a texenv. This is already clear, but it does help, if you aren’t clear on what a register combiner is, to think of a register combiner as a more powerful texenv.
The 8 stages vs 4 textures is a result of having more stages to combine texture fragments than you have units to generate available texture fragments. This isn’t the case with texture and texture environments, where each texture environment is closely tied to a single texture unit.