Hi!
I’m looking for a somewhat complete summary (e.g. a table) of which kind of vertex/fragment program extensions (NV_, ATI_, ARB_*, GLSL, etc) are supported on which cards (NVIDIA, ATI, Intel, etc). I’m interested in all generations here (back to GeForce1/2/4MX - i believe most of them do at least vertex programs on the CPU).
Does anybody know about such a summary or any other pointers to where I can collect this kind of information?
I’m sure you can easily get the data from here:
http://www.delphi3d.net/hardware/index.php
view by either by card or extension.
Thanks! Not really what I was looking for though (I knew about those). Wanted to know about HW vs. SW rendering too…
Anyway. I’m quite new to GPU programming (I’ve got the vague theory, but I have not done anuthing in practice). Three things:
What is the GeForce 3/4 fragment shader option (neither NV_fragment_program nor ARB_fragment_program are supported)??
Can I live with ARB_fragment/vertex_program alone, or do I need ARB_fragment/vertex_shader too?
GeForce 4 supports both ARB_vertex_program and ARB_vertex_shader. Are those implemented in HW or SW?
I’m not really sure geforce 1/2 support shaders. They are T&L that’s all what I know about them.
For shader support, I guess GLSL should be best for all OpenGL based cards.
Vertex/fragment programs are the ‘assembly’ version of the shaders whereas vertex/fragment shaders are the ‘C’ version. A card that supports shaders also supports programs. I think the reverse is not true.
Hope that helps.
- What is the GeForce 3/4 fragment shader option (neither NV_fragment_program nor ARB_fragment_program are supported)??
A combination of the NV_register_combiner and NV_texture_shader extensions. These are useful (you can get bumpmapping and a few other effects out of them), but not terribly much so.
- Can I live with ARB_fragment/vertex_program alone, or do I need ARB_fragment/vertex_shader too?
That’s up to you. The ARB_*_program extensions aren’t going to be updated (the ARB has glslang and they don’t care about lower-level languages), so new features will only be present in glslang. Unless you’re willing to use NV-specific extensions (not recommended).
- GeForce 4 supports both ARB_vertex_program and ARB_vertex_shader. Are those implemented in HW or SW?
The GeForce 3/4 has vertex program hardware, but it is the equivalent of D3D 8.0 vertex program functionality (no looping, relatively low opcode limits, etc). It can run ARB_vertex_program natively (within the hardware limits), but it can also run some glslang shaders. The glslang compiler will determine if a particular glslang vertex shader will run in software or hardware.
In general, I would not suggest supporting, in terms of shaders, anything below NV30/R300 class hardware. This hardware has the bare minimum functionality that can really start benifitting from shaders.
That’s not to say that you can’t have a no-shader codepath. However, it’s just not worthwhile to support multiple different kinds of shaders for each specific piece of hardware. Either someone’s computer can handle shaders, or it can’t.
It depends on whether you’re trying to provide a flexible API for a user of your renderer or not - if you are, then certainly limit it like Korval says, but if you’re not, and you have full control over your lighting model and rendering methods then it’s not that much extra effort to support all chipsets with specific code paths. If the design is rigid and unextensible support is easy, any flexibility makes support a nightmare.
Thanks you all!
Actually, I’m not trying to put together some nifty lighting model or the likes. I’m currently picking up an old project of mine: a Glide 3.x wrapper (yes, kill me if you like)! I know it’s fairly useless, but I think of it as a project to learn OpenGL (designing a complete API emulator, you have to deal with things that you can normally ignore).
I thought it’d be a good excercise to put the Glide fragment calculation (which is somewhat upside-down compared to fixed function OpenGL) in a fragment program, since I have not done any “shader” programming before. Also the Glide coordinate systems, which require one or two divides per vertex for going to OpenGL coordinates, might be better to handle in a vertex program than on the CPU.
As it is, I have an NVIDIA Ti4200 card, so I have to use GF 3/4 capabilities for development, and I might turn on SW emulation of higher level shaders later on to test & learn ARB_* and/or GLSL too.
I was hoping to avoid register combiners, but I assume I have to go that path. :rolleyes:
Again, thanks!
BTW, am I right in assuming that NV_fragment_program is fairly similar to ARB_fragment_program, in terms of features (i.e. they are designed for the same generation of hardware)?
Originally posted by Korval:
[QUOTE]
The GeForce 3/4 has vertex program hardware, but it is the equivalent of D3D 8.0 vertex program functionality (no looping, relatively low opcode limits, etc). It can run ARB_vertex_program natively (within the hardware limits), but it can also run some glslang shaders. The glslang compiler will determine if a particular glslang vertex shader will run in software or hardware.
I was wrongly thinking that a shader obligatory runs over the cpu.
So, that means that current GPU’s programmable pipelines are not able to perform all the requested operations, doesn’t it ?
Is there anything we can do in order to know if a shader is running on hardware or software side ? Because I guess that there can have a big performance issue regarding on which side it is running.
Originally posted by jide:
Is there anything we can do in order to know if a shader is running on hardware or software side ? Because I guess that there can have a big performance issue regarding on which side it is running.
Personally, I wouldn’t care that much about vertex shader emulation. If I have to implement some functionality that can’t be done in HW, i would have to do it myself (at least partly) in software. I suppose the vertex shader emulation is fairly well optimized in the drivers (SSE machine code generation?)?
As far as I can see, fragment shaders will not appear in the extension list unless the user turns emulation on (NVIDIA), in which case the user should not be expecting stellar performance anyway.
Edit: I was missing your point (I think)… Yes, shaders may switch to SW rendering if necessary (lacking feature, too long program, etc). See: NVIDIA - OpenGL 2.0 support .
This seems to be the good old question: “Is it in HW or in SW?”. And the good old answer is “Is it fast enough?” (i.e. time your algo on the user system, and decide which one to use, at run time).
Personally, I wouldn’t care that much about vertex shader emulation.
Using VBO’s and software vertex programs is a sure-fire way to murder your performance. Regular vertex arrays will beat you easily.
The fact that glslang does not have a cross-platform method for determining if a shader is native or not (even at runtime) is one of the problems with using the language and API. On ATi cards, you can search the compile string for certain keywords or key phrases, but nVidia or 3DLabs cards will almost certainly not use the same phrases.
just on a sidenote, marcus, Cg can compile to fp20 which is register combiners/texture shaders. so you can go around it a bit 
however just very basic stuff will compile, enough to get some simple effects done so.
Korval, I realize that CPU vertex programs will kill performance - at least when you’re close to being vertex bound. What I meant was my specific application: Glide emulation. Under Glide there is no such thing as VBO or even GL 1.1 vertex arrays. Glide doesn’t even have a modelview or projection matrix. My two options are: do it myself on the CPU (e.g. compute the reciprocal of 1/z) or write a vertex program. I’m sure the vertex program will be on par with my C-language CPU-driven code, even if it’s done in SW.
Also, Glide applications are very seldom vertex bound, and almost every piece of HW out today beats any old Voodoo chip + a sub-GHz CPU (which is what most Glide-apps were designed for). So I’m not focusing much on performance - more on functionality (e.g. in vanilla OpenGL the primary color is modulated with the first texture unit, but under Glide the primary color is modulated with the result of the last texture unit - I need to use fragment shading in order to “emulate” this behaviour - I don’t care if it takes 1 or 10 GPU cycles).
I’m aware of Cg. Just hoping to avoid it… I’d much rather learn the underlying techniques, and eventually jump straight to GLSL. 
Originally posted by marcus256:
Korval, I realize that CPU vertex programs will kill performance - at least when you’re close to being vertex bound.
[…]
I’m sure the vertex program will be on par with my C-language CPU-driven code, even if it’s done in SW.
That’s not what he meant. He meant that the driver will have to access vbo memory, that is memory on the graphic card, through the very slow agp bus (very slow in reading speed).
you dont even need shaders to emulate this, tex_env_combine extension which is quite wide spread allows you to do this “modulate with primary color last”
one can do quite a lot with this extension, paired with arb_crossbar/nv_combine4 it gives you quite some options on relative simple color operations
Originally posted by tfpsly:
That’s not what he meant. He meant that the driver will have to access vbo memory, that is memory on the graphic card, through the very slow agp bus (very slow in reading speed).
Well, I won’t be using VBO (I use straight GL 1.0 glBegin/glEnd), so I hardly think that the driver would first send the vertices to the card and THEN run the vertex program from the CPU, right?
Originally posted by CrazyButcher:
you dont even need shaders to emulate this, tex_env_combine extension which is quite wide spread allows you to do this “modulate with primary color last”
one can do quite a lot with this extension, paired with arb_crossbar/nv_combine4 it gives you quite some options on relative simple color operations
Thanks for the tip. I actually tried using tex_env_combine + nv_combine4 a couple of years ago when I first tried doing a Glide 2 emulator (I like them because they go all the way back to TNT2 (1?)). However, I seem to recall that those extensions would not do all of the glide color/texture combine functions. Anyway, it’s certainly possible to use them for a less-than-100% version of the emulation library (I actually got an old motorcycle game running through my old emulation library), if there is ever a demand for it.