So when OpenGL 2.0 finally comes out along with the Shading Language, are current cards out on the market going to support this? Meaning, if I buy a geforce fx card right now, will it support all features in OpenGL 2.0, such as all the pixel shader stuff and extensions?
The shading language is already out, but not yet supported by any public drivers.
The current generation of cards should support it, but not fully (it’ll be awhile before any chips support the full GL2 shading spec).
As for the core GL2, I don’t know. Is there even a draft spec for that yet?
I think there’s a draft for it at 3d labs web site. I’d just hate to go out and buy a geforce fx card only to find out 6 months down the road I can’t use all the features of OpenGL 2.0.
There is no GL2.0. There won’t be a GL2.0.
It was all a pipedream invented by 3DLabs to make them look “progressive” and “forward-looking”. The only thing that will come out of GL2.0 is glslang. The rest of it may eventually be adopted as extensions, but there will not be anything soon on it.
We’ve got VBO now, so we don’t need their new vertex interface. We’re getting superbuffers, so we don’t need the 2.0 version of that if there even was one. Everything else from 2.0 is superfluous and unneeded.
There is no GL2.0. There won’t be a GL2.0.
Not for a while anyway. We’re already at 1.5 and we gain a .1 version every year or two I think. Eventually OpenGL will be at 2.0 but that may be as much as 5 years from now. And even then, it probably won’t be the 3D Labs 2.0 that we know about now.
I hope the shading language will be fully supported on the NV30+ and R300+ and not require next years part. Maybe the final Det 50’s will have it? Doubt it but it would be nice.
-SirKnight
Just curious, anyone know if the NV30 will support SuperBuffers (Überbuffers)?
-SirKnight
Originally posted by SirKnight:
[b]Just curious, anyone know if the NV30 will support SuperBuffers (Überbuffers)?
-SirKnight[/b]
They kind of can right now, with the pixel data range extension.
Just curious, anyone know if the NV30 will support SuperBuffers (Überbuffers)?
It’s just a memory management scheme. The TNT2 probably can support it if they make appropriate drivers for it.
So should one wait and use the OpenGL Shading Language for pixel shading or just use Nvidia’s CG?
CG is written by NV, so it creates NV-optimized code of course. It uses some GFFX-specific hacks (low amount of registers). If you want really cleaned up shader code wait for glslang or write in arb_vp and arb_fp.
cu
Tom
Originally posted by Tom78:
[b]CG is written by NV, so it creates NV-optimized code of course. It uses some GFFX-specific hacks (low amount of registers). If you want really cleaned up shader code wait for glslang or write in arb_vp and arb_fp.
cu
Tom[/b]
Ok a few points I want to make on this. Cg does not compile to NV extensions only. It can if you specify the correct profile but it also supports ARB_v_p and ARB_f_p. So this way you can use Cg that will work on an NV and ATI card. Second thing is using a small amount of registers is not a “hack.” It’s optimal programming…why use 10 registers when you can use 4 for example? If it can mean the difference between a low fps or a high fps, then it’s a good thing. Some hardware designs have to be like this in order to be able to do other things, it’s just a tradeoff.
-SirKnight
Thanks for the heads-up on the SuperBuffers. I just added the init code for pixel data range extension in a demo i’m working on and will mess with it later when the time is right.
-SirKnight
Second thing is using a small amount of registers is not a “hack.” It’s optimal programming…why use 10 registers when you can use 4 for example?
Because using 10 registers cuts down on the number of ALU or texture instructions? Which happens to be the determining factor for ATi fragment program performance.
The point he was making is that the Cg compiler produces ARB_fp code that works less than optimially on ATi cards, and more optimially on nVidia ones.
[This message has been edited by Korval (edited 10-06-2003).]
Check out the NoDependentReadLimit profile option for arbfp1. It allows you to switch between optimizing for fewest dependencies or fewest registers.
Cass
Just curious, but are my 3dnow optimisations considered a ‘hack’ now?
Originally posted by knackered:
Just curious, but are my 3dnow optimisations considered a ‘hack’ now?
Yes, if there is no patch for the regular and simple Pentium4. 
OK, i called it wrong. It’s not a hack, but it’s an optimisation, that makes the shadercode harder to read/debug/optimize. Today i think it is easier to make shadercode in shader asm (or how you want to call it).
cu
Tom
Because using 10 registers cuts down on the number of ALU or texture instructions?
Not necessarily. It largely depends on what you’re doing. I can see using a few more registers to cut down in texture instructions if you are doing something that has to sample from a texture many many times, but I doubt most of the time you’ll be doing this. But what I was trying to get at was not counting registers for holding your fetched texture data, but the registers used in your main calculations. It wouldn’t make sence to use 3x as many registers at that time when you can use much less.
BTW Korval, reading my sentance after the 10 and 4 register thing should have made it obvious that I was talking about what I just said in this post. If using a smaller number of registers makes your program faster, then by all means do it!
-SirKnight
[This message has been edited by SirKnight (edited 10-07-2003).]
BTW Korval, reading my sentance after the 10 and 4 register thing should have made it obvious that I was talking about what I just said in this post. If using a smaller number of registers makes your program faster, then by all means do it!
What if it makes your program slower on ATi cards because the difference in register count increases the number of ALU instructions? On an nVidia card, it is better to trade registers for ALU instructions, but on an ATi card, registers aren’t even a performance consideration.
The point is that the ARB_fp code that is optimal for one platform isn’t necessarily optimal for another. And unless you’re compiling Cg shaders at runtime, you can’t know which platform you’re going to be running.