The slides from the OpenGL BOF at SIGGRAPH 2006 are avalible to download from http://www.khronos.org/developers/library/siggraph2006/OpenGL_BOF/. They are abbreviated but give some nice details about the latest OpenGL news and what the future could hold [smile] Also, a bit late but for those who haven't seen it there is a new letter called Pipeline which also includes some details. Enjoy [smile]

That's some excellent info, thanks phantom. I don't think there's anyone here who isn't looking forward to some of the proposals made (particularly spicy stuff in the "New Object Model" and "OpenGL 3 directions" slides).

I was at first a bit apprehensive of the heavyweight SDK idea (thinking of the huge DirectX SDK downloads), but the "Ecosystem" slide clears all that up as well. If I'm not wrong it's going to be based online, constantly updated whenever new changes are finalised.

Anyway, there's a lot there to keep us satisfied for a while. Once again, thanks phantom.

I'm encouraged by the positive feedback so far - this tells me we're going in the right direction. If you're curious, there's a thread on opengl.org where we go into more detail on the object model.

-- Michael

That was certainly interesting, thank you for the link (and the great talk [smile]) gold!

It appears that you decision-makers are really undecided on whether to retain a display list functionality and I'm curious as to how it turns out. Uptil now, there are just about 2 things people do with display lists:

1) Put geometry data in high performance memory (now obsolete due to existence of VBO)
2) Set a lot of Render states with 1 call.

Now, (2) is reduced as an issue due to the increased use of shaders but I for one would like the option of caching render states into a structure (which may be akin to the old display lists).

Anyway, great job. I think some people will love the steps forward you're taking (me included) and some others may think the change could be implemented differently. The fact that you are taking an initiative to improve OpenGL as a graphics API and make it more competitive and make it easier for developers (case in point: the proposed error checking functionality, redundant slower code paths removed, development tools) should be applauded.

Display lists for state changes haven't proven efficient in practice. Unless all pieces of relevent state for a particular machine unit are included, it must be treated as a state transition which kills potential optimizations. Even if all relevent state is included when the application is written, what happens when that machine unit is extended?

State objects are more interesting, as they included all relevent state by definition, and extensions automagically extend the state object with default state. State objects are dangerous, however. If we partition state incorrectly, it becomes a maintenance nightmare in the long run. Hence you are unlikely to see any generic objects which encapsulate arbitrary state changes, as a display list does today.

Display lists for geometry are still interesting. VBOs encapsulate vertex data only; they do not encapsulate the primitive type or connectivity information, which allows for further optimization. In OpenGL 2.x, changing VBO and vertex array state involves many function calls and incurs a lot of overhead, effectively killing small batch performance. Display lists win hands down for small batch sizes. We are looking to fix this in 3.0 with vertex array objects, but we still see room for display lists as well, including some new uses which I am not prepared to discuss at this time. :)

Well, we will be looking forward to more announcements, that's for sure [smile]!

OMG, FP depthbuffers! I am assuming this should allow for a nicer looking shadowmap? NO? with a new internal texture format 32bit also. After reading the new slides BRING on the GL3.0v. WOOT can't wait now. [grin]

Nobody said draw functions will take a large number of parameters - this is pure speculation and is definitely not my vision.

We are removing bind-to-edit, not all forms of binding.