OpenGL 3 Updates

[Jan]

Asm languages might in fact be of some use, though i would be much happier, if in the future GLSL will be capable of every feature. Ie. if nvidia and ATI (also) add their features to GLSL, instead of (only) exposing a complete different language.

However, many other extensions have been added to OpenGL that became obsolete pretty quickly. I hope this won't be the case with OpenGL 3.0 too quickly. Even if the API might be future-proof, this counts for nothing, if vendors impatiently add their features. I have nothing against experimental extensions, that are clearly not for use in commercial apps and thus can be removed later. I simply don't like to have an extension, that is for a few months the de facto standard and then is hard to get rid off, since people already use it frequently.

The NV/EXT/ARB_texture_rectangle is a good example for a mess, that could have been prevented, if the vendors and the ARB had worked a bit more in conjunction.

Jan.

[Xmas]

As for the compilers not generating optimal code, I've seen plenty of complaints on this forum about the quality of the compilers. Exposing the code as asm could allow hand optimization but in this case it doesn't get to the root of the problem: non-optimal compilers.

Hand optimizing only works well if the assembly language is close to the hardware. An ARB-defined language can't fit that bill because the architectures are too different.

The reality is that assembly shaders go through pretty much the same optimization steps in the compiler as high level shaders.

[Timothy Farrar]

As for the compilers not generating optimal code, I've seen plenty of complaints on this forum about the quality of the compilers. Exposing the code as asm could allow hand optimization but in this case it doesn't get to the root of the problem: non-optimal compilers.

Actually the root of the problem is that compilers will never (in my life time) always generate optimal code (not on GPUs or CPUs). You are mapping a general C like language to hardware which exposes some very un-C like functionality. And for some of us, the performance advantage of hand optimization is very important. For example, just an hour ago I hand optimized an originally 32 instruction fragment shader (compiled GLSL code) into a 14 instruction fragment shader (hand assembly).

[Timothy Farrar]

Let's hope so! I fear that shortly after GL3's finalization nVidia starts littering the extension-registry again!

Of course, nVidia has defined many good extensions, but it also introduced some useless ones and sometimes they could just have worked a bit more with the ARB to release it directly as an EXT or ARB extension.

Jan.

Actually, NVidia's "extension littering" is crucial, without this GL would be way behind from the driver support provided by DirectX. At least this way some of us GL developers can hope to compete with DirectX at least with NVidia's GPUs!

IMHO, the fundamental problem facing GL is that the GPUs are changing way to fast for proper driver support to be written by other vendors (ATI and Apple). The hope of being future proof is a pipe-dream. Think about what is going to change when AMD, Intel and hopefully NVidia release hybrid CPU/GPU architectures.

What GL really needs is quick approval for common vendor functionality exposed through the API, and drivers to back up this support. Without this GL developers which have real-world market constraints (ie have to compete with DirectX based programs currently making use of the full caps of the hardware) are going to be at a severe dis-advantage. Not to mention, up-to date GL drivers would do tremendous things for GL in general: more developers, more interest, and more products shipping with GL support, which will ultimately allow vendors to allocate enough resources to keep the GL drivers competitive with DirectX!

I think GL3 will be great if it improves batch performance and simplifies things such that vendors can easily keep drivers up-to date (ie removing old fixed functionality, depreciated features, etc).

I am most concerned with is the possibility that GL3 is going to put vendors farther behind in supporting the hardware. What I would rather see is GL2.1/SM4.0 support working now through current extensions! Take ATI/AMD for example. From all that I can gather their GL drivers for the new R600 chip don't even expose hardware texture fetch to complete a basic SM3.0 pipeline, let alone the SM4.0 pipeline. Please correct me if this is wrong (as I don't have the card to test). Just guessing here, that with them "open sourcing" the Linux/GL driver responsibility, there is going to be a tremendous lag between when GL3 gets finished and the drivers get some ability to use simple SM4.0 features (and that SM4.0 support isn't going to happen in GL2). And as for Apple, they made a huge step with Leopard, but still only have very basic SM4.0 support, same story there.

Well looks like 2008 is going to be an interesting year!

[Korval]

What GL really needs is quick approval for common vendor functionality exposed through the API, and drivers to back up this support.

No, what OpenGL 3.0 needs (after a spec) is just better drivers. That's going to drive adoption far better than anything else.

improves batch performance

Batch performance is already equal to if not faster than D3D.

From all that I can gather their GL drivers for the new R600 chip don't even expose hardware texture fetch to complete a basic SM3.0 pipeline, let alone the SM4.0 pipeline.

I'm certainly not aware of it. As far as I know, vertex texturing on ATi hardware has been available since they started making vertex texturing work. Which was the X1xxx line, I believe.

[pudman]

For example, just an hour ago I hand optimized an originally 32 instruction fragment shader (compiled GLSL code) into a 14 instruction fragment shader (hand assembly).

I've followed your blog so I know how capable you are in the asm arena (well, it is just a blog so I have to take your word (and screenshots) at face value).

In the case you just optimized, in your opinion, would it have been something the compiler could have optimized for? I'd be interested in knowing the details.

[Cgor_Cyrosly]

However, many other extensions have been added to OpenGL that became obsolete pretty quickly. I hope this won't be the case with OpenGL 3.0 too quickly. Even if the API might be future-proof, this counts for nothing, if vendors impatiently add their features. I have nothing against experimental extensions, that are clearly not for use in commercial apps and thus can be removed later. I simply don't like to have an extension, that is for a few months the de facto standard and then is hard to get rid off, since people already use it frequently.

It seems that best to development of a standard of assemebly language of GPU shader programming for GLSL or all GPU language (except the virtual assemebly "PTX" of CUDA).Somtimes ,we hope as good as optimized our shaders and understanding of the underlying.The programmers sometimes need to return to source but at that time cannot too rely on the compiler.
The biggest benefit of assemebly lanuage is that we know what we are doing and it will get faster for our programs.
Even if for some unknown reason or merely is the hobby of personal or the intuition art.

[Timothy Farrar]

In the case you just optimized, in your opinion, would it have been something the compiler could have optimized for? I'd be interested in knowing the details.

Yes and no.

First off I'm not talking about trivial cases here. For complex stuff, until you see the assembly, you don't exactly know what is and isn't efficient in terms of the GLSL language (other than benchmarking many different versions of an algorithm). What seems like simple and elegant GLSL can compile to a nightmare of GPU assembly. You can easily gain an advantage by knowing how many and what assembly opcodes get produced by the compiler. A stupid example of this is assuming something like atan() would have the same or similar performance as sin() and cos(). Had atan() been fast, like sin() (4 op cycles in G8x), then perhaps sin(atan(x)) would make sence instead of using x/sqrt(1+x^2). Another example would be to see what the compiler generates for the sign() function (lots of code including conversion to integer on the G8x). So seemingly simple GLSL functions can have hidden performance impact.

Another issue (at least on the G8x) is register usage. At some point using too many registers limits the ability of the hardware to thread the shader. Using feedback from the assembly output can be a good way to optimize even GLSL code and rework the code to insure register usage doesn't limit threading. Or just simply write in assembly with the knowledge of exactly the register limit (in some cases changing an algorithm to fit the machine).

Another limitation of the compiler (for the G8x) right now is simply making use of predicated (conditional) execution. In my experience it seems as if the compiler tends to do a lot of "set on" opcodes and "if" branching when much easier setting conditionals as the result of a previous alu op, then conditional alu destination mask would work (with no branching). Generating code which mixes conditional code update, clamping and saturation is not quite done well by the compiler (does not match up with C like languages well). Branch optimization is critical for GPU performance.

In my case the optimizations were primary a result of changing the algorithm to better match the hardware (as a result of seeing elegant GLSL code compile in to a mess of assembly), branch removal/recoding, and smart predicated execution.

Of course after doing the assembly optimization I could probably go back and write a much better GLSL version of the algorithm! So my 50% is only the result of the first optimization (which required knowledge of the output assembly to get to quickly).

We all know that in many cases the compiler is going to write code which performs just about the same as hand written assembly (and the compilers are only going to get better!), and in some cases hand assembly is going to beat the compiler.

However, having an exposed assembly layer (such as gcc -S for CPU programming, and a GLSL or Cg to GPU assembly conversion tool) is essential in quickly working out the best path to the hardware, even if you don't program in assembly. The assembly extension specs alone give tremendous insight into the hardware which with only high-level languages would be a black box.

It is the mix of having the high level GLSL for quick prototyping as well as production code for non-speed critical stuff, and assembly to fine tune the critical code which provides the optimal solution.

[Korval]

GPU assembly

There's one problem: there's no such thing.

[Cgor_Cyrosly]

GPU assembly

There's one problem: there's no such thing.

Ha-ha,yes.The assemebly shader language is only part of GPU functions and the assemebly language PTX of CUDA are not true assemebly ,but hope it can be developmented and truly should have the GPU instruction collection