PDA

View Full Version : NV register combiners



xeropunk63
06-26-2003, 06:33 AM
Hey, I use an ATI 8500LE card and for whatever reason the NV Register Combiners won't work on my card, or maybe it's just my computer. Is there anything I need to install or download to get the combiners to work? I have all the glext.h and other header files nvidia gives out, but any program with the combiners won't run on my comp. Anyone have any ideas?

brute
06-26-2003, 06:44 AM
Maybe because you have an ATI card and you are tring to access propietry features on an NVIDIA card.

vincoof
06-26-2003, 10:01 AM
brute's right. Most of NVIDIA extension are not supported by ATI cards, as well as most ATI extensions are not supported by NVIDIA cards.
If you want to deal with extensions that are supported by everyone, you should stick to ARB extensions (and EXT extensions for the older ones).
By the way, just in case you don't know, the "NV" in "NV_register_combiners" stands for "NVidia".

[This message has been edited by vincoof (edited 06-26-2003).]

xeropunk63
06-26-2003, 12:54 PM
alright, i knew the NV stood for nvidida, i just figured they would be compatible with each other. I guess not, thanks for the info.

SirKnight
06-26-2003, 01:15 PM
ATI has an extension that will let you do the same things. I'm not sure what it's called since I have never used it. I don't have an ATI card at the moment.

-SirKnight

Klaus
06-26-2003, 01:25 PM
The equivalent on the ATI 8500 to NV texture shaders and register combiners is called GL_ATI_fragment_shader.
http://oss.sgi.com/projects/ogl-sample/registry/ATI/fragment_shader.txt

Klaus

zeckensack
06-26-2003, 07:36 PM
Have a look at Delphi 3D (http://www.delphi3d.net/) 's hardware info.

Csiki
06-26-2003, 09:29 PM
Originally posted by Klaus:
The equivalent on the ATI 8500 to NV texture shaders and register combiners is called GL_ATI_fragment_shader.
http://oss.sgi.com/projects/ogl-sample/registry/ATI/fragment_shader.txt
Klaus

Why don't able to sit down this two corporation and make an ARB extension together???
It's too hard to speak???
Ahhh.

Mazy
06-26-2003, 10:34 PM
ARB is more than 2 corporations.

And yes, for cards that not can handle ARB_fragement_programs you dont have a really good extension, but ARB_env_combiners + arb_env_dot3 ( or what the exact names is) can handle most situations..

zeckensack
06-26-2003, 11:49 PM
Originally posted by Csiki:
Why don't able to sit down this two corporation and make an ARB extension together???
It's too hard to speak???
Ahhh.

Because their hardware architectures are completely different, and their respective extensions expose these different architectures almost completely. If you want to make an interface that fits both, you end up underusing both chips because you need to ignore capabilities where there's no overlap.
That's what happens in the DX Graphics realm. Compare 'pixel shader 1.1' with NV_register_combiners (assume Geforce 3 level; 8 general combiners). You lose so much functionality.

sqrt[-1]
06-27-2003, 01:01 AM
Also keep in mind that in the DX realm the "standard" is not followed exactly by each hardware vendor. Ie. It is possible to write shaders that are perfect ps1.1 code that will not work. The reasons for it not working become obvious when you read the OpenGL specs.
For example on GeForce3/4:
mad r0.rgb, r0, c0, c1;
+ mul r0.a, r0.a, c2.a
(This accesses three constants in 1 instrction)

On a ATI Radeon 8500/9000:
tex3x3vspec ....
(This instruction is just not possible when you read the ATI OpenGL spec -w component gets erased when passing tex coords through)

(there are many other instances where this has occured, ie dp3 r0.rgba ... produces weird results)

Also from DX8-DX9 the spec has changed (modifiers on constants not allowed) so old shader code may have to be updated to run in the DX9 profile.

So you see that even when there is a "standard" the hardware in that generation was not flexable enough to cater for a real standard.

Csiki
06-27-2003, 01:12 AM
Originally posted by zeckensack:
Because their hardware architectures are completely different, and their respective extensions expose these different architectures almost completely. If you want to make an interface that fits both, you end up underusing both chips because you need to ignore capabilities where there's no overlap.
[/B]
It is better, then using none of them.
Most of us (me too) don't use vendor specific extensions...