Why doesn’t NVidia support this extension ? Is there an issue regarding compatibility with register combiners ?
Julien.
If I remember correctly what Matt said about this the crossbar brakes the NV_texture_env_combine4 functionality.
-Lev
I would be interested by more details, if possible…
ATI supports both ARB_texture_env_crossbar and ATIX_texture_env_combine3 which is quite similar to NV_texture_env_combine4. Wouldn’t it be better to forget texture_env_combine4 (as it’s NV specific and superseded by register combiners/texture_shader IMO) and support these, making ATIX_texture_env_combine3 an EXT_ ?
Julien.
- For a better world, with only ARB and EXT extensions…
This has been discussed before, and I was complaining about nVidia not wanting to support that extension until I got the whole picture. The problem is that the GL_ARB_texture_env_crossbar extension has functionality that explicitely contradicts functionality in GL_NV_texture_env_combine4, which means nVidia will have to drop one of them since it’s impossible for the driver to know what functionality the app is actually wanting. Since GL_NV_texture_env_combine4 was already shipping and in use they dropped the crossbar extension quite naturally. The way the crossbar extension was set up is a mistake though, the ARB voted for an extension that contradicts a shipping extension, which is bad, especially in this case where the way things work in the combine4 extension makes much more sense too and should be used in the crossbar extension too IMO.
Anyway, for most apps that want s crossbar functionality it suffices to check for support for either of the crossbar and combine4 extensions. That’s how I do it at least.
Humus is correct; we pointed out to the ARB the problems with the extension, but no one seemed to catch on, and in the end we were the only ones to vote against it. Very unfortunate.
As a result, we may never be able to support this extension.
- Matt
There is a light… OpenGL 2! Church background song
It’s more than unfortunate that extensions shoot each others.
I don’t see what OpenGL 2.0 has to do with this – if it’s backwards compatible, this situation will remain.
There seems to be a rather strange attitude on this board that OpenGL 2.0 will magically cure everything wrong with OpenGL. Geez, the ARB has enough trouble ratifying even trivial extensions…
- Matt
In the long run OpenGL 2.0 may solve it, and many other problems with OpenGL. The release of OpenGL 2.0 plus cards and drivers supporting it will not suddenly make every problem solved, true, but once apps using the older model gets either discontinued, obsolete and unsupported or updated to OpenGL 2.0 those problems will dissappear. 5 years from now noone will care about crossbar vs. combine4, those extension will probably no longer exist in the drivers either.
The biggest problem right now is that there are no ARB/EXT approved way of dealing with fragment/texture shaders. OpenGL 2.0 with it’s shader model will render the crossbar/combine4 extensions obsolete, along with many of the extensions today including register combiners and fragment shaders.
Well I might be wrong but aren’t those two extensions meant to be replaced by programmable shaders in OpenGL 2.0 (and thus disappear in OGL 2.0 or “Pure” OGL 2.0)?
OpenGL 2.0 is a good chance to solve such problems.
There seems to be a rather strange attitude on this board that OpenGL 2.0 will magically cure everything wrong with OpenGL.
Well, I think we all naively expect OGL 2.0 to solve every problem OpenGL 1.xx got, but it’s 'cause that’s what OpenGL 2.0 is meant for.
I don’t worry however, I’m impatient to finally program using OGL 2.0 and discover all the new problems that have been created!