OpenGL 3 announced

The OpenGL ARB officially announced OpenGL 3 on August 8th 2007 at the Siggraph Birds of a Feather (BOF) in San Diego, CA. OpenGL 3 is the official name for what has previously been called OpenGL Longs Peak. OpenGL 3 is a great increase in efficiency in an already excellent API. It provides a solid, consistent and well thought out basis for the future. OpenGL 3 is a true industry effort with broad support from all vendors in the ARB. The OpenGL 3 specification is on track to be finalized at the next face-to-face meeting of the OpenGL ARB, at the end of August. This means the specification can be publicly available as soon as the end of September, after the mandatory 30 day Khronos approval period has passed. Also presented today were the changes to the OpenGL Shading Language that will accompany OpenGL 3.

We look forward to your discussions in this thread.

While it’s nice to finally have a version number (I always suspected it would be 3.0, major changes and all that) until such time as the SIGGRAPH slides with GL3 and GLSL details appear online there isn’t a great deal to discuss.

Roll on the release of the spec however :slight_smile:

Woohoo :cool:

End of September though :frowning:

Regards
elFarto

Very nice! Keep on the good work!

Most of the slides are now online here . My apologies for the delay on making those available. Two more slides coming later this morning.

Nice :slight_smile:

I wonder when working implementations of GL3 are expected in Nvidia/ATI drivers? End of september already, or will it take some months more?

I wonder when working implementations of GL3 are expected in Nvidia/ATI drivers? End of september already, or will it take some months more?
I’m interested in this too. Is there any chance we can get someone to give us a “rough and guestimated” time frame? =)

It is very good to know all this, but i was really hoping for more at this point. But hey we waited this long, two more months is not that bad.

What i really hope for is that the new promises on OpenGL 3 reloaded and Mount Evans (3-5 months) can be held.

Really looking forward to seeing more of this OpenGL 3 :wink:

-chris

Nice work everyone!!!

I immediately read all of the PDFs and boy am I excited. Can’t wait for the new object model!

-HexCat

The final 2 PDF’s are now uploaded. They are:
siggraph-2007-bof-shading-language.pdf
siggraph-2007-bof-SPECviewperf.pdf

Enjoy!

From the GL3 presentation:

Program Environment object
• Immutable reference to program object

Program Object
• Fully immutable

Great :smiley:

Ok, it’s good that OpenGL will be improved!
However, what about existing applications? What does it mean in practice, when glBegin/glEnd will no longer exist in OpenGL3? Will there be 2 different versions of OpenGL that come with a vendor’s driver (e.g. libGL.so & libGL3.so).
To be honest, I’m afraid that at some point in the future new drivers will only support OpenGL3, which means old applications will not work anymore! I think that this is not a good development for OpenGL…

Originally posted by Khronos_webmaster:
The final 2 PDF’s are now uploaded.
Thanks,

Good things:
in/out/inout, much clearer than attribute/varying
#include, although I don’t see how this will work
switch statement

Iffy things:
common blocks not being able to take bools/ints and samplers…?

Not sure:
What does the multiple in’s/out’s mean in the last diagram slide?
“No state tracking” for built-in uniforms? Does that mean they are going away?

Regards
elFarto

Originally posted by Rolf Schneider:
To be honest, I’m afraid that at some point in the future new drivers will only support OpenGL3, which means old applications will not work anymore!
I don’t see vendors dropping support for GL2.x anytime soon, if ever. However there will come a time when it is no longer enhanced (i.e. no new versions or extensions) and primary development will focus on the new version.

Hmm. The GL3 overview was too… overviewish. We’ve had this same overview for the past year. I wanted to see something more in-depth.

The two significant new concepts added are the Program Environment objects and the Push/PopAttrib stuff.

First, the last. This is a great feature, and I’m glad to see it in 3.0.

As for Program Environment objects… I’ve been saying since day 1 (go ahead. Do a search on the forums and check) that Program objects needed to be instanced. That the Program was just the data and the attachments to it needed to come from an external object that referenced the program. I’m glad to see that the ARB finally saw the light. Now we won’t have to have innumerable copies of program objects running around just because we use them with different buffers and such.

Originally posted by Overmind:
[b] From the GL3 presentation:

void DrawElements( enum mode, const sizei *count, const
          sizeiptr *indices, sizei primCount, sizei
          instanceCount );

Why is the index array in client memory? When we get rid of client side vertex arrays, why not get rid of client side index arrays as well?[/b]
Prehaps you can optionallly pass an array, and NULL to use the indicies in the VAO?

Regards
elFarto

And there’s still certain questions I’d like answered.

Format Objects. Probably the most elusive objects in the whole thing, because we know practically nothing about them.

Are format object specifications sufficient to be able to tell whether a floating-point texture will be able to be bilinearly filtered? That is, if we request a format object for floating-point, can we say that it needs bilinear, and if the implementation can’t handle it, it will simply fail to create the format object?

Because that’s what I’ve been hoping for from these objects, and there’s never been any confirmation one way or the other on it.

“No state tracking” for built-in uniforms?
Well, there’s no state for them to track, since all that FF-pipeline stuff is gone in 3.0. And good riddance.

Originally posted by elFarto:

“No state tracking” for built-in uniforms? Does that mean they are going away?

weren’t they supposed to ‘be’ away in gl3? i thought all this was supposed to be cut from the ‘core’ functionality and be brought back by the compatibility layer?

Originally posted by Korval:
Are format object specifications sufficient to be able to tell whether a floating-point texture will be able to be bilinearly filtered? That is, if we request a format object for floating-point, can we say that it needs bilinear, and if the implementation can’t handle it, it will simply fail to create the format object?
Yes, that is exactly the intent. Its unfortunate we have such non-orthogonalities but this is probably better than pretending it all works and then falling back to software.

Format objects describe internal formats and the corresponding capabilities, including dimensional limits, allowable usage (e.g. texture, render buffer) and other caps such as filtering and blending. They are also used to enforce compatibility of FBO attachments, so there is no need to query completeness - a FBO is always complete if its attachments are populated, and you cannot attach an image with a different format than expected.

Originally posted by Chris Lux:
[b] [quote]Originally posted by elFarto:

“No state tracking” for built-in uniforms? Does that mean they are going away?

weren’t they supposed to ‘be’ away in gl3? i thought all this was supposed to be cut from the ‘core’ functionality and be brought back by the compatibility layer? [/b][/QUOTE]Built-in uniforms are gone, and they are not. In order to support existing shaders, built-in uniforms are “pre-declared” but have no value except that which you set. In other words, they work just like user-defined uniforms.