OpenGL 3 Updates

[Carl Jokl]

One think which OpenGL is going to benefit from under these curcumstances is that on non Microsoft platform there is no real alternative but to use OpenGL so no matter how much they alienate their developer base they have little choice but to wait until ARB come out with the new release.

Don't make me form a sharp implement out of a GL Triangle Fan and start poking ARB members with it mercylessly. *poke* *poke* *poke* Still won't talk? I can keep this up all day muhahahahar *poke* *poke* *poke*

Another thing which was hinted of as regards potential to remove the GLDOUBLE type as part of some changes designed to simplify driver development. I would be a bit concerned about the long term consequences of removing the use of double precision primitives in OpenGL. Certanly today and for a long time the hardware implementations of the vertex creation and geometric operations and such are implemented as 32bit precision (usually corresponding to a float). The world is going 64bit though and it is not inconceivable that 3D graphics geometry migrates to 64bit precision too. Looking down the line then having the double precision based functions still around in the future would provide a migration path if that happens.

[Ilian Dinev]

Ok back on track, and OpenGL should stay a graphics library IMO, and if they want GPGPU stuff make a add on library that integrates to GL, and call it OpenGPGPU or something. That way they can be used separately or together.

The old-style GPGPU is staying in its original form, available in GL - render to texture, use that data to draw graphics; meanwhile there's CUDA for the more GP uses.
GPGPU is useful both for the increasing number of streaming-processors (and core clock), and the fact that it keeps data in VRAM, so you only pull via PCIe the data of the final pass. Plus some things like bilinear filtering are free.

In games, we use "gpgpu" to dynamically transform vertices and generate geometry - it's a nice scalable optimization in the short and long term.

[Zengar]

Another thing which was hinted of as regards potential to remove the GLDOUBLE type as part of some changes designed to simplify driver development. I would be a bit concerned about the long term consequences of removing the use of double precision primitives in OpenGL. Certanly today and for a long time the hardware implementations of the vertex creation and geometric operations and such are implemented as 32bit precision (usually corresponding to a float). The world is going 64bit though and it is not inconceivable that 3D graphics geometry migrates to 64bit precision too. Looking down the line then having the double precision based functions still around in the future would provide a migration path if that happens.

If you remove the immediate mode stuff, there are not many functions left that could use double precision. And if the hardware doesn not support it, there is no real point of double precision to be present in the API. It can be easily added as an extension in the future. And it does not complicate driver developement, really. All the driver has to do is convert doubles to floats – a trivial task.

[bobvodka]

The removal of 'double' was because it doesn't hit any fast paths and part of the point of GL3.0 was to make it easier to hit the fast path on current and future cards.

"Double" support is partly here; the GT200 has support for double processing HOWEVER at a cost as it has a limited number of double registers (working from memory, check AnandTech's GT200 tech for deails).

The plan seemed to be to remove all the cruft which makes finding the fast path hard for ISVs and to simplify the drivers for the IHVs. Then, as hardware supports things (such as 'double') to add them back in; probably via extensions first then a minor version update (with hopefully then extensions being removed instead of left laying around as now).

[knackered]

And if the hardware doesn not support it, there is no real point of double precision to be present in the API. It can be easily added as an extension in the future.

I find it hard to believe you missed the launch of the GT200 series.
At the end of the day it's just a type enum when submitting data.

[bobvodka]

Now I've had time to dig it up;

(source)
Double the Precision, 1/8th the Performance

Another major feature of the GT200 GPU and cards based on it is support for hardware double precision floating point operations. Double precision FP operations are 64-bits wide vs. 32-bit for single precision FP operations.

Now the 240 SPs in GT200 are single-precision only, they simply can't accept 64-bit operations at all. In order to add hardware level double precision NVIDIA actually includes one double precision unit per shading multiprocessor, for a total of 30 double precision units across the entire chip.

The ratio of double precision to single precision hardware in GT200 is ridiculously low, to the point that it's mostly useless for graphics rasterization. It is however, useful for scientific computing and other GPGPU applications.

It's unlikely that 3D games will make use of double precision FP extensively, especially given that 8-bit integer and 16-bit floating point are still used in many shader programs today. If anything, we'll see the use of DP FP operations in geometry and vertex operations first, before we ever need that sort of precision for color - much like how the transition to single precision FP started first in vertex shaders before eventually gaining support throughout the 3D pipeline.

So, I'd argue against including it now as it's still not a 'fast path'.. although I now expect all the GPGPU people to start crying about it..

[Jan]

For graphics itself, i don't see any need for more than 32 Bit precision. The only thing, that would be nice to have higher precision, is the depth-buffer, at least when using shadow-mapping. But that requirement came up many years ago and IHVs didn't do anything about it, so i am sure, they won't do much about it any time soon, either. I assume the problem is, that adding support for 32 (or more) Bits for depth is quite costly to get fast, and since it is the central unit on the chip to actually get rasterization graphics, they haven't done it.

With double-values elsewhere it was "easy" of course. Drop it in, with real bad performance, tell everyone it's their fault, if they use it. And few (very few) people might actually be able to use it for something useful, but hey, reviewers will write how great the shiny new card is, because it has a new feature!

Jan.

[Zengar]

And if the hardware doesn not support it, there is no real point of double precision to be present in the API. It can be easily added as an extension in the future.

I find it hard to believe you missed the launch of the GT200 series.
At the end of the day it's just a type enum when submitting data.

You missanderstood my post... I was trying to say that presence of double types does not make much difference to the API once the immediate mode stuff is removed. Still, I believe it is a better idea to add them as an extension (as you say, it is just a type enum) on hardware that supports them. With other words: the API should expose the abilities of the hardware, not more!

[Xmas]

I assume the problem is, that adding support for 32 (or more) Bits for depth is quite costly to get fast, and since it is the central unit on the chip to actually get rasterization graphics, they haven't done it.

Actually, all recent GPUs support 32 bit floating point depth buffers (though some effectively only use 30 bits).

[ScottManDeath]

DX 11 is going to have some kind of GPGPU shader btw.

http://speakers.nvision2008.com/agen...m?sessionid=39

The more I can do with a graphics API, the better it is. And I would suspect that in the future, it will be more convenient and possibly more performant to use GPGPU kind of shaders in certain parts to break up the pipeline. I mean, we got geometry shaders, we are going to get more shaders for tesselation.

So what is next. What can you add to the pipeline to enable more flexibility? So then the question arises why not just have the user write generic C++ code with a few intrinsics, say texture fetch and tri-setup.

Sure, it makes sense to have some kind of graphics libary, so those who just want to draw triangles don't have to do all the grunt work. We already have things like this today, say the C runtimes which wrap and standardize OS specific features, such as file access etc.