The Industry's Foundation for High Performance Graphics

You understandably want to know where the OpenGL 3 specification is. I have good news and some bad news. First the bad news. Obviously, the specification isn't out yet. The OpenGL ARB found, after careful review, some unresolved issues that we want addressed before we feel comfortable releasing a specification. The good news is that we've greatly improved the specification since Siggraph 2007, added some functionality, and flushed out a whole lot of details. None of these issues we found are of earth-shocking nature, but we did want them discussed and resolved to make absolutely sure we are on the right path, and we are. Rest assured we are working as hard as we can on getting the specification done. The ARB meets 5 times a week, and has done so for the last two months, to get this out to you as soon as possible. Getting a solid specification put together will also help us with the follow-ons to OpenGL 3: OpenGL Longs Peak Reloaded and Mount Evans. We don't want to spend time fixing mistakes made in haste.

Here's a list of OpenGL 3 features and changes that we decided on since Siggraph 2007:

• State objects can be partially mutable, depending on the type of the state object. These state objects can still be shared across contexts. This helps in reducing the number of state objects needed in order to control your rendering pipeline. For example, the alpha test reference value is a candidate to be mutable.
• We set a *minimum* bar required for texturing and rendering. This includes:
• - 16 bit floating point support is now a requirement for textures and renderbuffers. Supporting texture filtering and blending is still optional for these formats.
• - S3TC is a required texture compression format
• - Interleaved depth/stencil is a required format for FBO rendering
• - At least one GL3-capable visual or pixel format must be exported which supports front-buffered rendering.
• OpenGL 3 will not have support for the GL_DOUBLE token. This means it will not be possible to send double precision vertex data to OpenGL.
• A format object has to be specified per texture attachment when a Program Environment Object is created. This helps minimize the shader re-compiles the driver might have to do when it discovers that the combination of shader and texture formats isn't natively supported by the hardware.
• GL 3 will only cache one error, and that is the oldest error that occurred.
• The OpenGL pipeline will be in a valid state once a context is created. Various default objects, created as part of the context creation, will have reasonable default values. These values are such that a simple polygon will be drawn into the window system provided drawable without having to provide a Vertex array object, vertex shader or fragment shader.
• GLSL related changes:
• - GLSL 1.30 will support a #include mechanism. The actual shader source for the #include is stored in a new type of object, A "Text Buffer" object. A text buffer object also has a name property, which matches the string name specified in a #include directive.
• - Legacy gl_* GLSL state variables are accessible through a common block.

More details will follow soon in an upcoming OpenGL Pipeline newsletter.

Barthold Lichtenbelt
OpenGL ARB Working Group chair

To make it short, we shoudln't expect the spec untill about new year and first implementations even later... Still, it is good that they are trying to make a solid product. I guess I can wait.

Hey its better late than never! And if it takes abit longer to get something that is done correct, then yes lets wait.

Why no double vertex data? Is this for speed reasons only? I see with DX10.1 precision of float data will have to be tighter on that hardware... Will this be good enough for everyone? From games to scientific purposes? I am not clear on the #include directive, is this a header file where you have your shaders coded at?

e.g.
#include "lightingVS.xxx"
#include "lightingFS.xxx"
#include "lightingGS.xxx"

thanks for the update!!!

Double data never made sence as there are no implementations that actually use it. Something like this should be an extension. So IHMO it is a good move.

As far as I understood, the include works just like in C (copy-pastes a text from another file), only that is works with named buffers instead of files. A very elegant solution!

Remember, OpenGL 3 will be implementable on currently shipping hardware. The fast majority of that HW does not natively support double precision vertex data. In GL 2, where you can send double vertex data to the GL, that will likely get converted to floats by the driver or HW. Future hardware might fully support double vertex data, and then support for it can be added back into a future OpenGL 3.x version.

Barthold

I'm sure you're doing the best you can and surely these things require time. We'll keep using the already great feature set exposed by gl 2.1(plus extensions of course).
Everyone is on their toes to use the new api so make it as good as you can!

Thanks for the update, it's good to know what is going on with it

Remind me of something. Do R300 (Radeon 9xxx) and NV30 (GeForce FX's) support 16-bit float textures/renderbuffers? I was hoping that these cards would be the minimum GL 3.0 compatible hardware.

The #include mechanism is intended to make partitioning of shader sources easier, but in GL3 is not going to provide a means to do either a callback or a real access to the file system.

What it does let you do is submit individual buffers of text and attach names to them separately, and then make reference to those named text buffers from another section of text using the #include statement. However at compile time you must be able to provide all of the buffers to GL3 that can be referenced for that compile job, this allows for more than one buffer to have the same name but still let the application disambiguate everything at compile time.

edit: why do it this way? It keeps all the work to do #include resolution on the server side. It is potentially not as flexible as a callback mechanism, but as we know callbacks do not translate well to a client/server model.

I'm 99% sure that R300 supports 16-bit float textures, but without filtering or blending. I never had a NV30, so I don't know about that.