GL_ARB_texture_env_crossbar & GL_ARB_texture_env_dot3

Originally posted by paddy:
Let’s evaluate texture_env_route…
Is it bad too ?
Is another way to do things.
Best is to be able to get e.g. the result of the fog rendering as an input.

It does essentially the same thing as the crossbar … plus some extra goodies. AFAICS the specification doesn’t specify the behaviour with disabled texture units but it should be the same as the crossbar since both are supported on Radeons.

Originally posted by ET3D:
My understanding of why the crossbar disables units is that it should be possible to perform this in drivers on any hardware. For (1,1,1,1) there’s need for an actual hardware feed of this value, that might not be available. combine4 provides a zero input, probably because NVIDIA hardware provides this, so using (1,1,1,1) makes sense. But this isn’t guaranteed to exist on all hardware. Also, I’ve yet to understand what “Also, this behavior is more easily forward compatible to an extension which separates the texture lookup and texture blend units” means, but I’ll give it some thought.

I can hardly think it’s an issue on any vendors hardware. (1,1,1,1) would be normal behaviour, since if you enable a texture unit but have bound any texture or the texture upload has failed for some reason you’d get white.

Why it’s easier forward compatible with separate texture lookup and combine units is that for instance glDisable(GL_TEXTURE_2D) for a certain texture unit would only disable the texture lookup engine, but not neccesarily the combine unit. Say for instance that you want to do (tex0 dot3 constant color) * primary_color, you’d setup the the first texture to do dot3 with constant color and the second to modulate with primary color. Now you need to utilize two combine units but only one texture lookup units. With the functionality as defined in crossbar extension you’d need to enable and bind a texture for the second texture unit even though it’s unused, while with the combine4 spec you wouldn’t need to do this in the case we had separated the combine and texture lookup. This may not cause problems but it’s not “clean” IMO to have enabled a texture unit that doesn’t output any useful data and possibly wastes resources on fetching unused texels. If now the texture lookup and combine were separated you’d only need to enable the combine but not the texture. But the crossbar extension would require that any texture unit that depends on the disabled texture unit to be disabled too, which would cause problems if you want to add a few extra texture layers on top of my example here.

Originally posted by Humus:
I can hardly think it’s an issue on any vendors hardware. (1,1,1,1) would be normal behaviour, since if you enable a texture unit but have bound any texture or the texture upload has failed for some reason you’d get white.

That may be because texturing was disabled completely. If you could show that different multitexture operations (multiply, add, subtract) all act consistently with a (1,1,1,1) texture on those chips then they definitely should implement this. But if this is not the case, and such a source isn’t available, then adding a (1,1,1,1) behaviour could be much more involved than handling the disabling.

BTW, Cass, I tried to download again, and got the new version of the extension spec.

re:
Just come to think … those Kyro cards are supposed to support DOT3 too, anyone know if any of those extensions are available on Kyro cards?

Not usable via OpenGL as yet. I got the following reply from their developer program: “It could be a while on the DOT3 OpenGL. Its not been a focus, as no developers are using it - you are the first to bring it up.”

Anyone who wants to use it, please write them a note! Doesn’t have Cube Env support, by the way, but otherwise all AlteredWorlds stuff works well.

Actually, i wrote and received a response from the DevRel for Kyro back in April on the Dot3 issue. D3D is there priority, not GL, but if there are enough ‘quality apps’ that are using Dot3, i’m sure they’ll update their drivers.

BTW, the Kryo card has great potential with its Tile-Based overdraw handling (although i don’t understand how come this doesn’t thrash frequent texture loading horribly). The DevRel guy said that the ‘8’ layer multi-texture could actually be N-layer because of the architecture. Pretty cool to consider…