Whatever suits you. But I hope there will be continued support for lower level languages.
For the use we make of shaders in our engine, the “assembly” languages are absolutely essential, crucial, fundamental, vital. If we were stuck with GLSL our engine would run at half the speed and do half the things it does. In our case, the asm stuff is vastly superior but due to the structure of the language and not how it compiles. Sorry that I can’t disclose more.
how do you know your engine would run at half the speed?
I can well believe it though, I still can’t write a GLSL shader that’s as fast as the ‘fixed function’ path (which is apparently a shader as well). But I really can’t be bothered going back to vp/fp asm.
I assume you generate your shaders procedurally and maybe do your own optimizations? If so, i think it could be done with GLSL just as good. Whether GLSL compilers are good enough to make it equally fast is another question.
Well, I am of course exaggerating, for dramatic effect and to satisfy my lousy sense of humour.
It’s the particular use of procedurally generated shaders that gives us the performance boost. It could be done in GLSL but I wouldn’t want to use it because it’s more cumbersome, slower at compiling (done on the fly, on demand) and structurally not at all as well suited at least to my implementation.
We still have preloaded shaders (I would get rid of them) that could just as well be GLSL but I personally find vp/fp more intuititve because I find them better aimed at the purpose. From my experience, I would say high level language features should stay the hell away from shaders until GFX hardware is about a hundred times as fast as it is today, then they would either allow us to do whatever we will be doing then or else simply still waste performance.
The language you use affects what optimisations you can make. I have written the same functions in 3 considerably different languages and found that I completely restructure everything depending on the instructions/operators I have available. I still occasionally write multi-page blocks of CPU asm!
Cass said above that fixed function is very well optimised and I assume that is beyond our means as developers. Annoying as sometimes I would change only so little…
I’m hoping OGL3 will be much more adequate than these languages but I haven’t taken the time to really get informed.
Of course madoc, you are going to be missing out on any structural optimisations made in future hardware. It’s much easier for an optimiser to figure out what you’re trying to do with a higher level language.
But for the here and now, you probably don’t care a great deal.
My experience is that no IHV has ever had the faintest clue what I want to do, damn it. They seem know what Carmack wants to do, but I want to do something else 
.
The thing is, HLSLs will just give you some high level function, you use that and hope that someone hideously smart implemented some compiler magic that makes that your best choice.
With a low level language, as you are implementing, you notice things like: Hmm… what if I use this instruction instead, and by using these components of this register there, and keeping that result here… Hey! I just saved 4 instructions!
You do that by clever use of language features that go beyond it’s intended purpose, high level languages are all purpose and no features.
Of course, if the language you are using has nothing to do with what’s going on at the hardware level then you achieve nothing more than deluding yourself but until this day my profiling of vp/fp has shown this is obviously not the case (at least not yet). Given the future as I forsee it, I don’t see vp/fp becoming quite so obsolete in terms of alikeness to hardware, in fact, GLSL would be just as absolete in those terms.
Oh, I do realise the at least potential advantages of HLSLs, don’t mistake me. But so far I have always had better luck optimising myself and vp/fp fulfill my needs and have other qualities that suit me well.