I’m considering a game engine with shader support, but I can’t decide whether to use GL_ARB_vertex_program and GL_ARB_fragment_program or GLSL, which path is faster? Or other advantages?
I don’t know if that’s what you want:
I am lazy and not really into hw, so for me the choice is rather simple >> GLSL
It’s C-like language, so it’s easy to learn and apply. There are also programs like Shader Designer which facilitate the shader creation process.
The drawbacks are:
*you need at least FX 5200 or Radeon9500 to run it(please correct me if this info isn’t correct)
*the compilers are stupid/buggy and they sometimes don’t compile valid programs.
But generally GLSL is great:)
The fp/vp are assembler like:( and they are supported on earlier machines.
I don’t know much about the performace, but I heard that fp/vp are faster. However, the GLSL is compiled in runtime, so there is possibility that the driver can optimize them for specific card - hawever, the drivers (at least in my case - ATI Catalyst)are stupid.
I hope I helped a bit…
If you want to use a fragment shader, you
will at least have to work with a Gefore FX,
independent if you are using this functionality via FP or GLSL.
GLSL is easier to code, but ARB_vp/ARB_fp is easier to debug and to optimize. because you have more control about what are you doing than with GLSL.
I have integrated both into my testbed app, and only the low-level shaders into our shipping app. I think the high-level languages (HLSL and GLSL) are much nicer to work with. For the low-level shaders, I ended up writing the shaders in Cg and compiling to machine code anyway…
For performance, the problem with GLSL and HLSL is that it’s so easy to add all kinds of embellishments, so you’re tempted to write longer shaders – the actualy code generated is almost always equivalent performance, or near enough, to what you’d write by hand.
ARB VP/FP is the past, and is neve going to be updated anymore.
I’ve integrated the ARB extensions, Cg, and GLSL into my current project. I’m pretty proficient at programming the ARB assembly extensions and I’ve found writing Cg/GLSL to be actually slower if you are interested in optimized shaders.
Cg/GLSL compile well with simpler vertex/fragment programs that are common in game development, but once your shader gets longer (I’m talking 30-100ish instructions here) or it includes branching, I’ve found the output assembly code can be anywhere from 1 to 10 times longer than my hand optimized assembly version. Sometimes the Cg compiler nails things right on, sometimes I have to fool around with it to get things right.
My typical usage pattern, is to compile the high level program and look at its ARB output, then make changes to the high level language (adding swizzle hints, write masks, packing things differently) as hints to the compiler so that it can evenually produce a semi optimized version of the shader. Since I have to look through the name mangled ARB version anyways when compiling my high level code, I don’t really see any point in using high level code at the moment, at least not until the compilers become better.
About 20% of the time, Cg/GLSL actually makes things faster/nicer for me, the rest of the time, I find myself wanting to go back to ARB.
I don’t see the ARB assembly extensions going away anytime soon. The high level shader compilers need to get better at:
-
compiling & optimizing branching code (if … elseif… endif)
-
figuring out which components of a vector need to be carried through and which ones don’t have to be, without me having to give mask/swizzle hints (i’ve seen these compilers stick in lots of extra mov operations to carry unused components of vectors around)
Thats my experience with high level shading programming. I typically use shaders that are quite a bit more complex than in traditional game development though, so gamedevs may find HLSLs to be more useful than I.