Why TNTs dont support ARB_texture_env_combine

It is just not logical for me. TNT supports EXT_texture_env_combine and NV_texture_env_combine4. If the hw supports these functions (including cross texture references), there is no problem to support ARB_texture_env_combine and even ARB_texture_cross_bar present on GFFX. EXT_texture_env_combine and the ARB one seems to differ only in one thing - this is pointed in the Issues section, but the Errors sections says nothing about it.

Secondly, this extension can be treated as a functional superset of statndard GL env functions (MODULATE, REPLACE, BLEND, DECAL). But I cannot achieve one of these functions with RGB texture (cant remember which). The forgotten function takes as an alpha the color of the incoming fragment, while the combine function takes 1.0.

Any thougts?

Michalek

Doesn’t the driver version report opengl 1.4 on your card? in that case you have already the functionallity of both ARB_texture_env_combine and ARB_texture_cross_bar in the core…

TNT supports 1.4?!!

I know the ATI Rage 128, which is a similar generation, couldn’t do ARB_texture_env_combine because of lack of SUBTRACT_ARB support. (EXT_texture_env_combine doesn’t require subtraction, and NV_texture_env_combine4 only affects flexibility of inputs and outputs, not combine functions).

Perhaps the TNT2 is in a similar boat?

Im not sure about tnt, but tnt2 reports 1.4, it doenst mean that the card itself can handle it, but that all functions exists and are working ( even if they are in SW) but for this case, the combiners, i bet that it can be handled in hardware, only a speedtest will tell.

And thats why this all ext hell is so hard to understand by me. Geforces dont export EXT_texture3D but the ext is there waiting for use. BUT without hw accel ARB_vp is supported in software for GF2, so why there is no support for TNTs?
I would like to support ARB_vp on boards, where VPs are in hw, and on others use old TnL, to gain the highest performance available.
Is it always true, that if given extension is exported, it is supported in hardware, else if the gl version is appropiate for this ext, it is supported but it is in sw, else - there is no support. Is it true on all boards or only on nvidia ones?

Michalek

Actually it isnt the EXT_texture3d thats waiting for you ,its the Core function Texture3D, its a difference… since nVidia want its drivers to be 1.4 compliant on most (all?) their cards they have implemented all missing functions in software, but ARB_vp isnt in the core, its an extension, and not needed in the core, and therefor not all drivers have it.

If the driver reports an version that includes a function that previously was an extension, and that extension isnt in the extensionlist, then you might guess thats its only in SW, but it dont have to be that way.

[This message has been edited by Mazy (edited 07-15-2003).]

Originally posted by Mazy:
If the driver reports an version that includes a function that previously was an extension, and that extension isnt in the extensionlist, then you might guess thats its only in SW, but it dont have to be that way.

So why They are hiding it? Cheeseus, Im going to check ARB_texture_env_crossbar and combine on my old TNT tonight, and if it doesnt support it I will have to stick to nasty NV_texture_env_combine4!

Michalek

as OneSadCookie said, it can be that tnt lacks the subtract in hardware, then you should be able to use everything else in the combine spec without speed penalty, but if you try subtract it can fallback to a software path and be very slow…

OK. So to detect those extensions the best would be this code?

while(glGetError);
glGet (GL_TEXTURE_ENV_MODE);
glTexEnv (GL_TEXTURE_ENV_MODE, GL_COMBINE_ARB);
if (glGetError ())
	;// not supported
else
	;// lipa - not supported
glTexEnv (GL_TEXTURE_ENV_MODE, saved_mode);

Or should I always trust the version number?

Michalek

You should be able to trust the version number… Any implementation that states a certain version number MUST implement all features that the core of that version specifies, else its not an Opengl-compilant implementation, and you can contact the manufacturer and complain

But its never a bad idea to include some error checking.

ARB_texture_env_combine and EXT_texture_env_combine share the same tokens. That is, there’s no difference between calling :
glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_COMBINE_ARB)
and calling :
glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_COMBINE_EXT)

You just have to take care of the few tokens that are exclusively supported by one of the extensions and not the other, for instance GL_SUBTRACT_EXT and GL_RGB_SCALE_ARB do NOT exist.

nVidia does only provide software support for GeForce cards because they can not afford developing such drivers for all their cards. I tend to say that GeForce1/2 owners are lucky men, not that TNT1/2 owners are unlucky.

The ARB_texture_env_crossbar functionality is almost entirely suported by the NV_texture_env_combine4 extension. The only problem resides in the special case of the invalid texture bindings. Unless you want to treat with invalid textures (which I doubt) you can use the ARB_texture_env_crossbar functionalities as long as the NV_texture_env_combine4 extension is supported, even if the ARB_texture_env_crossbar extension is NOT supported.