GLSL vs ASM

Look at the forum faq. The extensions ARB_verex_program and ARB_fragment_program are both outdated, and will no longer be updated. All future methods of shading should be done with GLSL. Its part of the 2.0 standard, and its not disappearing anytime soon.

On Non-Nvidia hardware, Cg compiles into the ASM for the outdated extensions.

Quote:

Original post by WilyCoder On Non-Nvidia hardware, Cg compiles into the ASM for the outdated extensions.

Wait, so your saying ATI doesn't support GLSL? So it'd be slower?

Short answer: GLSL (or HLSL, any high level language really) is "better" simply because it allows for faster development, is easier to read, and has the potential to compile into more optimal machine code.

Long answer: First off, FarCry is a DirectX game, not OpenGL. Because of that, it probably uses HLSL (though I wouldn't be surprised if it could use ASM shaders if it really wanted to.) This is one area where DirectX does have a distinct advantage over OpenGL. HLSL can be used on any hardware that has shader abilities by carefully restricting the functions you use on older hardware. Pretty much anywhere you can use DirectX ASM you can also use HLSL.

OpenGL doesn't have that luxury due to the (rather silly, IMHO) ARB decision to make GLSL only compatible with PS 2.0 hardware and above. As far as I can see, the only reasoning behind it is because they don't want to directly acknoledge Microsoft's Pixel Shader classifications, and thus left out the ability to specify a target hardware level all together. >_< In any case, what it means is that us OpenGL-ers are stuck developing with two very different languages. Sucks, but what can you do?

[EDIT]

Quote:

Wait, so your saying ATI doesn't support GLSL? So it'd be slower?

No, ATI now fully supports GLSL. They were slower than Nvidia at picking it up, but they do support it. What Wily was referring to is the fact that on Nvidia hardware all shaders compile into CG, which is Nvidia's native shader language. On ATI hardware, if you compile a CG program, it will compile into ASM for older hardware (< PS 1.4) and GLSL on newer hardware (PS 2.0 and up)
[/EDIT]

It wasnt so much an ARB decision as a case of 'lets make a forward looking shading language'. There is no real restriction on what hardware levels its implimented on, its upto the IHVs to sort that out and they have decided it seems that yes, GLSL is only going to be viable on PS2.0 hardware and up.

Quote:

Original post by Toji No, ATI now fully supports GLSL. They were slower than Nvidia at picking it up, but they do support it. What Wily was referring to is the fact that on Nvidia hardware all shaders compile into CG, which is Nvidia's native shader language. On ATI hardware, if you compile a CG program, it will compile into ASM for older hardware (< PS 1.4) and GLSL on newer hardware (PS 2.0 and up)

Hmmm I'm not so sure about the 'slower to pick it up' bit, however their implimention was more complient when it appeared in the drivers (WHQL lag time between it being introduced and being avaible to the public).

And does Cg compile to GLSL? No one has ever been able to confirm this for me (its more or less idle wondering as I've no intrest in use Cg, say what you like about it some of its syntax is just... ewww...)

So would it be a good idea to perhaps use HLSL? Even though DirectX is doing the exact same thing as OpenGL with DX10... Perhaps I should just stick with GLSL.

Phantom: here is an post I made on the message board for my graphics course:

Well I think I have the definitive answer regarding GLSL and how it
compiles, versus how Cg compiles.

From the Orange Book (summarized from page 211):

When GLSL is compiled, it goes through three stages: lexical analysis,
syntactic analysis, and then semantic analysis (much like ordinary
code). The result of compilation is a high level representation of the
original source code. This output is dubbed a "high level intermediate"
language (HIL), and is a binary representation of the original source
code. The HIL is then further processed by a target-specific back end in
order to provide machine code for a particular type of graphics hardware.

"It is anticipated that individual hardware vendors will implement the
back end needed for their particular hardware. The compiler back end
will typically include intellectual property and hardware-specific
information that is proprietary to the graphics hardware vendor"

---------

Regarding GLSL and Cg (summarized from page 417):
All 3 languages (Cg,GLSL, and HLSL) are very similar in terms of syntax
and capability. The single biggest technical difference is that Cg and
HLSL were designed to sit on top of standard interfaces such as DirectX
and OpenGL and perform high level source code to assembly translation
outside of those APIs. GLSL, on the other hand, was designed to perform
high level source code to machine code translation withing the OpenGL
driver.

---------

So there we have it. I guess one's preference of shading language is as
religious an issue as Emacs versus vi, or KDE versus gnome :)

I would say that if at all possible use the High Level Language for your API of choice. (GLSL for OpenGL, HLSL for DirectX, or CG for either if you feel so inclined) Just be aware that if you're developing using OpenGL and you need to support pre-2.0 hardware, then you'll need to look at ASM shaders unless you want to go the CG route.

Quote:

And does Cg compile to GLSL?

Sorry, can't confirm. This is just what I've heard. Actually, one would think that it would be more effecient to go straight from CG to their own native code, but that would require them to write two completely different compilers... Hm....

I would like to know the answer to this too, if anyone knows for certain!

Quote:

It's up to the IHVs to sort that out and they have decided it seems that yes, GLSL is only going to be viable on PS2.0 hardware and up.

My mistake. Thanks Phantom!

1) Don't use assembly, because it's simply deprecated. It's not like DX where assembly standards are provided for every hardware level. GLSL is the only way to use newer features. (NV provides a few extensions, but ATI has no equivalents.)
2) Why is HLSL relevant? Obviously if you are in D3D, you will need to use HLSL, while if you are in OpenGL, you will need to use GLSL.
3) Forget Cg. Since it can't "compile" to a GLSL profile, it's basically useless on the OpenGL side. And since HLSL is Cg, but more closely tied to D3D and more elegantly written and documented, there's no reason to use Cg.

Quote:

Don't use assembly, because it's simply deprecated.

This is the only point I would disagree with you on. Sure, you obviously want to use GLSL where it's avalible, but if you need to support older hardware you're screwed. I wish we all COULD only target PS 2.0 hardware and up, but there's still way too many GeForce 4's out there to just ignore them. For the next few years, at least, ASM shaders are still something of a nessicary evil.

Is GLSL really not able to compile to a 1.1/1.4 spec?

Nope, sadly it's not. This is what I was lamenting about earlier, thinking it was the ARB's fault. Apparently it was actually a choice made by the IHV's, but the fact still remains that it sucks hard. >_<

Mmmmmmmmmmmmhmmmmmmmmmmm COOKIE! Sorry, snacking on a chocolate chip cookie... I'm planning for this game to finish in around 2 years, is that enough time for GLSL to become standard?

You can still write GLSL on GF4Ti's if you would like.

http://delphi3d.net/hardware/extsupport.php?extension=GL_ARB_shading_language_100

The extension is exported. What will (read: should) happen if you write a GLSL program that exceeds the limits of the hardware, is that the program should instead be emulated on the CPU, producing slow but correct results.

With a bit of care, you should have no problem taking advantage of GLSL, while still running natively on this older hardware.

Rough points:
Don't branch or loop
Limit indirect texture lookups
Try to keep the instruction count down
Don't do any recursive function calls

The GLSL extensions also export a function which allow you to determine if the program is 'within native limits' or not.

For the GF4Ti's specifically, only vertex programability is exposed via GLSL. If you want fragment programming for anything before the 9600 or GFFX, you'll need to go back to ARB assembly/ATI_text_fragment_shader/register combiners.

Really? I thought I read somewhere that both GLSL Fragment and Vertex shaders needed to be avalible or both of them ran in emulated software mode. Interesting...

Of course, without fragment shaders it's still not a viable solution. :P

Quote:

If you want fragment programming for anything before the 9600 or GFFX, you'll need to go back to ARB assembly/ATI_text_fragment_shader/register combiners

That's odd... I tested one of my GLSL based programs on my brothers 9550 just yesterday. Ran like a charm! Are you sure it's only 9600 and up? (I know for a fact that it only works on the FX line and up for Nvidia hardware)

Quote:

Original post by Toji Really? I thought I read somewhere that both GLSL Fragment and Vertex shaders needed to be avalible or both of them ran in emulated software mode. Interesting... Of course, without fragment shaders it's still not a viable solution. :P

Well a GF4 Ti has pixel shaders. It's the GF3 we need to find out about. (I assume other cards will get CPU emulated VS and no PS.)

Depending on what you are doing with your VS, you could end up with CPU emulated shaders on both the GF3 and GF4, however this code is so damned fast anyways its not really worth worrying about unless you are REALLY tight on CPU time.

If memory serves the lowest number PS2.0 card ATI did was the 9500, however not many of them ever really appeared as they were basically 9700s with a couple of pipes turned off, after a while ATI stopped producing them once the true 9500 yields improved and things got renamed to the 9600 along the way. The 9550 is basically an under-powered 9600 solution ("poor" memory interface and lower clock speed iirc)

@RichardS
"Don't do any recursive function calls"

The GLSL infact outlaws recursive function calls completely, so you shouldnt even be trying todo them on PS2.0 hardware.

@Toji
to be honest, the lack of GF4 support really depends on your target market and time for shipping. If you arent looking to shove anything out of the door for a couple of years then I'd argue you can forget about the GF4 line and refocus your efforts, we've had the 9700 series for example since late-2002, thats 3 years ago, which makes the gf4 around 4 years old, thats practically dead by hardware standards.
If however you plan on a much shorter time frame then the GF4 is probably worth considering, yes.
(personally, I took the choice a while ago to forget about pre-PS2.0 hardware, I find shaders sooo much easier to work with and I hate all that FFP balls..)

Quote:

Original post by phantom its not really worth worrying about unless you are REALLY tight on CPU time.

What, you mean like most games today? *cough*

OK, I have another question. If it's emulated, why wouldn't it let me run my program when I had 1.5.0 dirvers but not 1.5.1 drivers. You're all saying it's emulated, but obviousely it wouldn't emulate there...

I don't know for certain if this is the case, but it's entirely possible that the extension simply wasn't exposed in the 1.5.0 drivers. (Although I have to ask, of what? That number doesn't seem to mesh with either Nvidias or ATIs current version numbers.) GLSL access is a fairly recent thing in WHQL drivers, so it wouldn't be too surprising if it suddenly appeared in an update.