While reading about ARB_vertex_program yesterday I got thinking. I was looking at a ppt presentation layout by nvidia who was talking about the new stuff with the NV30. They had ARB_vertex_program on a small and bare slide and they said 2 things, that it was an ARB improved cross-platform extensions, and that NV_vertex_program2 was more powerful. Well this sorta defeats the purpose of ARB approved extensions and it seems that this will always happen. Yes I know that Nvidia wants money and such, but I’m just wondering, if the ARB extensions prove to be useless in relation to other extensions out there, whta’s hte point of OGL 2.0? I know it gives us a shader language but anything else?
i dont know about gl2 ( even if a HL language can be more flexible it cant introduce functions that are impossible to achieve on this generations of HW, so t has to be upgraded for each new card generation as well)
but the ARB_V_P introduced some very nice stuff… the upload and handling of program objects… the difference between AarbVP adn the nvidia one is only the textstring at this moment, and i hope, and guess that it will be the same with NV_V_P_2 also…
Nope, NV_v_p and ARB_v_p not only have a different syntax for the assembly language but also totally different entry points for uploading programs and setting program parameters.
As for OGL 2.0, it will clean up the API, finally include a couple of WGL/GLX/AGL stuff into the core API, clean up the render-to-texture design, give OGL a more object-oriented design, introduce a sync/fence model, …
So all in all, I can’t wait for OGL 2.0.
Actually, the APIs are much more interoperable than that. You can use the “OPTION NV_vertex_program2” in an ARB program to get access to all the VP2 feature set. And it’s always been OK to load an ARB program with glLoadProgramNV, or an NV program with glProgramStringARB.
I don’t see these low-level APIs ever going away; there’s a level of control that you can’t get out of the HLL. For example, there are 3 or 4 ways to implement an “if” statement in NV_vp2, and in certain cases, certain ones will be better. You can use condition codes; you can use branching; you can use the SGE, etc. instructions; etc. On a CPU, this is comparable to the question of whether to use a conditional move or a branch. Conditional moves may lead to wasted computation, but ill-predicted branches are even worse. If the compiler picks the wrong one for your app’s data, then tweaking the assembly is your only choice.
ARB extensions are free for everyone to implement and reasonably scalable in scope.
NV extensions tend to be tailored specifically to NVIDIA’s hardware which is neither good or bad, it’s just natural.
If your shaders fit what the ARB version can offer: go for it. Gives you better portability. If you need that extra special instruction, go for the NV version, but be aware of the consequences.
Now that was easy, wasn’t it?
Just as an extra precaution (you never know …):
You are aware, that not every graphics card in the world is based on NVIDIA chips and supports NV extensions?