Are the following extensions supported on GF/GF2/GF3 cards?
GL_ARB_texture_env_crossbar
GL_ARB_texture_env_dot3
This may be a stupid suggestion but …
why not download the latest GF/GF2/GF3 drivers and search for the strings in the driver files ? This could help ya.
Just an idea …
Well, haven’t thought about that.
Anyway, this way if I find the string it doesn’t neccesarily mean it’s supported, and it doesn’t tell on which of the nVidia cards it is supported, GF3 can do more than TNT 
If the string is missing though it should mean it’s completely unsupported though … too bad though I couldn’t find the GL_ARB_texture_env_crossbar at all in the 12.40 drivers. Isn’t at least the GF3 capable of taking input from arbitrary texture units in the combine?
Guess I’ll have to resort to dualpass then.
Off topic, but I found this in the driver at the end of the extension strings which was kinda fun: “… GL_ARB_multisample GL_ARB_imaging botched! busted! broken! …”
There’s a document at NVIDIA’s site that shows which extensions exist and are supported by which cards. I might look it up for you when I’m for more than several minutes on the net.
Sorry 
I assumed you had a GF/GF2/GF3.
Originally posted by Humus:
GL_ARB_texture_env_crossbar
not supported
GL_ARB_texture_env_dot3
no ARB extensions, its called GL_EXT_texture_env_dot3
supported by GF2 and GF3
Chris
Well, it’s an ARB extension identical to the older EXT. When I looked in the 12.40 driver with the hexeditor I found both the ARB and the EXT.
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?
Yes, we do support the ARB dot3 extension, and no, we do not support the ARB crossbar extension, and we have no plans to support the ARB crossbar extension.
For one, the ARB crossbar extension is broken – it explicitly contradicts behavior we defined in our NV_texture_env_combine4 extension (which has been shipping for a long time now, and already offered similar or better functionality). You’ll notice that we voted against the adoption of this extension; this is one reason for doing so.
The crossbar extension is also broken in the long run; it will not scale appropriately with increases in numbers of texture units.
In short, it’s a bad extension.
Use register combiners.
- Matt
Humus, the NVIDIA OpenGL specs, which lists all the extensions and on which chip families they work, are at http://www.nvidia.com/marketing/Developer/DevRel.nsf/pages/A86B9D846E815D628825681E007AA680 . Good thing you asked about them, because NVIDIA just released a new version. Downloading it now.
For one, the ARB crossbar extension is broken – it explicitly contradicts behavior we defined in our NV_texture_env_combine4 extension
What a NVIDIA-centric way to look at things. It may be true that the crossbar extension is inferior, and maybe even “broken”, as you say, but such a sentence still smells badly.
I’d like to see NVIDIA implement even ARB extensions that it doesn’t agree with. You can say in the specs “this extension sucks, and I’m sulking because nobody on the ARB agrees with me” for all I care. I was hoping that ARB level extensions would at least be something that all companies will try to implement. What’s the use of ARB extensions otherwise?
BTW, the “new” nvOpenGLSpecs is actually a very old copy. Glad I decided not to overwrite the version I had.
If others notice the problem mentioned in the above post please let me know. I see the correct file, but it’s probably because I’m “on the inside”.
Thanks -
Cass
On RadeONs you can use :
ATIX_texture_env_route
http://www.ati.com/na/pages/resource_cen…e_env_route.txt
So it should be :
combiners on NV
route on ATI
Different names, same games …
What a waste of time…
Originally posted by mcraighead:
[b]Yes, we do support the ARB dot3 extension, and no, we do not support the ARB crossbar extension, and we have no plans to support the ARB crossbar extension.
For one, the ARB crossbar extension is broken – it explicitly contradicts behavior we defined in our NV_texture_env_combine4 extension (which has been shipping for a long time now, and already offered similar or better functionality). You’ll notice that we voted against the adoption of this extension; this is one reason for doing so.
The crossbar extension is also broken in the long run; it will not scale appropriately with increases in numbers of texture units.
In short, it’s a bad extension.
Use register combiners.
- Matt[/b]
Well IMHO GL_ARB_texture_env_crossbar rox. It really added lots of flexibility and I’m happy my Radeon card supports it. I don’t see in what way GL_NV_texture_combine4 similar of better functionality. A quick look into the spec reveiled that is has the following functions:
ADD Arg0 * Arg1 + Arg2 * Arg3
ADD_SIGNED_EXT Arg0 * Arg1 + Arg2 * Arg3 - 0.5
This is just two fixed functions (which may though be useful) but is far from the functionality you can get by GL_ARB_texture_env_combine + GL_ARB_texture_env_crossbar and the other extensions that are based on the combine such as GL_ARB_texture_env_dot3 etc. Depending on how hardwired your hardware is it would seam that there would be possible to implement the crossbar extension since the combine4 extension already can take any texture unit as an input. I don’t see in what way the crossbar extension would contradict behaviour defined in combine4. You have a completely different TEXTURE_ENV_MODE, namely COMBINE4_NV, while the crossbar extension only affects the COMBINE_ARB.
I don’t really think the scaling is such a big issue. Not being a hardware guy but as I see it it’s just a set of muxes, should scale without much problem to 8 or beyond texture units.
I’d gladly use the GL_NV_texture_env_combine4 extension if it
[ul][li]were solving my problem[*]were multivendor[/ul][/li]I find it annoying that nVidia keep adding a lot of proprietary extensions while not supporting the ARB. Are you trying to force the gaming market to support only your extensions?
In the end it’s only hurting yourself. Nobody is going to release a game only supporting your extensions, but it’s not uncommon that games gets release mainly or only based on ARB extensions.
Originally posted by cass:
[b]
If others notice the problem mentioned in the above post please let me know. I see the correct file, but it’s probably because I’m “on the inside”.
Thanks -
Cass[/b]
Don’t know what version is should be but the file I got down from the link was dated Nov 2000.
Yes, that’s what I got, too - dated November 1, 2000.
I agree with Humus…
Originally posted by Humus:
I don’t really think the scaling is such a big issue. Not being a hardware guy but as I see it it’s just a set of muxes, should scale without much problem to 8 or beyond texture units.
This is definitely a big issue, especially with 8 or more texture units. It’s a big chunk of HW (a whole lot more than you’re thinking) and it grows with order N^2. That’s area that can be used in a whole lot of better ways.
- Matt
Update:
I’ve changed my mind on this issue. Just got a lengthy mail from Mark Kilgard from nVidia that explained the issue more in detail. What I didn’t realize was that the NV_combine4 extension did affect the COMBINE_ARB TEXTURE_ENV_MODE too. The NV_combine4 already has the functionality of the crossbar extension plus those two functions but with the small difference of how it handles disabled or inconsistent texture units, the crossbar extension says that in such cases any texture unit that is reading from this texture will also get disabled while the combine4 extension simply says that input from a disabled texture unit will be white (1,1,1,1). I’d like to know the reasons why the ARB went this way with it since the combine4 way of handling it make more sense IMO and is also slightly faster for the driver. So this means nVidia cannot support both the crossbar and combine4 … and for this reason they dropped the crossbar.
About the scalability of the crossbar extension, I don’t how it’s less scalable than the combine4 extension.
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.
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.
[This message has been edited by ET3D (edited 05-23-2001).]