Siggraph Asia 2008 slides suggestions for OpenGL

Has anybody seen the Siggraph 2008 slides presented on the frontpage? (http://www.opengl.org/news/permalink/mod…08_course_slide)

I’ve been scrolling a bit through these slides and saw a section describing the future of OpenGL (slides 170 to 204). When reading this it looks like nVidia doesn’t really agree with the current direction of OpenGL, a quote:

Part of OpenGL 3.0 is a marking of features for deprecation[ul][li]LOTS of functionality is marked for deprecation[]I contend no real application today uses the non-deprecated subset of OpenGL—all apps would have to change due to deprecation[/ul]Some vendors believe getting rid of features will make OpenGL better in some way[ul][]NVIDIA does not believe in abandoning API compatibility this way[/ul]OpenGL is part of a large ecosystem so removing features this way undermines the substantial investment partners have made in OpenGL over years[ul][*]API compatibility and stability is one of OpenGL’s great strengths[/ul][/li]
What do they suggest instead? Improved display lists: using multiple cpu cores to build display lists in parallel (letting a single thread execute the display lists). According to nVidia we really need display lists now and improve them, making them more flexible (instead of depricating them). They want the driver to optimize the executing order of frequently used display lists.

Other things mentioned: let OpenGL have more Direct3D capabilities to make conversion easier (like removing the need to link shaders into a program, so that shaders can be used more flexible).

These are only some points from the slides. Some things (like the slide about the deprecation model) made me frown upon, other things make sense and some other I don’t know yet what to think about. What do you think about the suggestions made in the slides? What could be useful, what isn’t useful at all?

To me it looks like nVidia doesn’t like the current path OpenGL is taking… maybe I misunderstood this from the slides… but I wonder how large the differences in opinions are between different Khronos members.

Nvidia always had very good performance with display list, so I believe they invested a lot of time and efforts on this. Marking DL as deprecated can only benefit their competitors.

I think the deprecation model doesn’t model doesn’t matter and causes confusion.
It would have been better to just release long peaks as was planned.

It’s funny - when OGL deprecates display lists, Direct3D11 introduces them (ID3D11CommandList).
I agree with Nvidia on this - when multithreaded programs are getting more and more important to get more speed out of cpu, then display lists could be an answer from OpenGL for multithreaded rendering (in similar way how D3D does it with device contexts and command lists). But now it seems that OGL 3.1 will really deprecated them.

Display list is a good concept, the way there are specified in OpenGL … I’m not sure … It’s just so complicated and we can be really creative in weirdness with them.

Display lists with a cleaned OpenGL spec … I agree that is could be great!

Its completely irrational to say that DL’s are gone because they are deprecated. Remember: “deprecated” just means “might go away in future”. And even if the official 3.1 specs actually remove the old display lists, there is no reason why they can’t survive as extension (remember those fancy slides explaining the deprecation model?!). Even better then that! DL’s (or a new concept) might get re-introduced by a completely new extension that doesn’t need to worry about the former DL’s existing in parallel.
Sigh all these discussions about that deprecation model would be non-existent if Longs Peak have had seen the light.

there is no reason why they can’t survive as extension (remember those fancy slides explaining the deprecation model?

It would be better not to have display lists as extensions or any other alternate way of rendering as extensions.
How about creating a single path that will work on everything?

I know of a number of commercial apps that rely on display lists completely. A fair bit of rework would be required if they were removed - in fact their render traversal would have to be rewritten, and any plugins their customers have written would also have to be rewritten (to fill vbo’s instead of calling immediate mode).
glNewList()
drawscenegraph()
glEndList()
But so long as they remain as a legacy profile, it shouldn’t be a problem - as something that uses immediate mode is not likely to have any use for shaders or any more modern features.

I guess that’s the final irony of the deprecation model: on the one hand it allows for deprecation, on the other are folks that don’t want functionality removed.

If I’m Nvidia, I wouldn’t want to remove functionality either - I’ve already got the best GL drivers in town.

Really enjoyed the presentation, btw.

Yes I liked it as well, lots of slides with some interesting information.

I’m not sure about the display lists, I’ve never used them tbh (doesn’t say much, I’m an amateur graphics programmer who hopes to learn ;)). But being able to use multithreading in some way would be welcome I’d say (and as far as I understood DirectX 11 has multicore support, not sure how they implemented it exactly).

In any case having display lists as extensions (to keep programs that rely on them running) isn’t a great solution. Maintaining a legacy path is a far better solution in that case.

DX11 has MT support by having some functionality as free threaded. This means that certain operations can be called from any thread (resource creation and updating iirc).

The display list like functionality requires a context in a thread to call it on, however it’s very simple to just create one and use it. Most of all this already works on DX10 hardware as demostrated by the beta sdk.

In an organization the size of NVIDIA, there will be different ideas about the right way forward for OpenGL.

I agree with Mark that display lists should be improved, not eliminated. In a world where GPUs are getting smarter and smarter, the API’s inability to express higher-level scene construction hurts it. Serializing and flattening the information makes many optimizations and rendering models much more difficult - if not impossible.

Maybe OpenGL has an identity crisis: Is is a low level API, conforming to what’s available in the hardware? Or is an a “higher-level scene construction” API? Would there be any benefit to separating these concerns? OpenCL makes compute programming more expressive but yet still closely related to OpenGL when needed. Wouldn’t optimizing scene construction be even more easy/powerful if there were a language dedicated to it?

I guess it’s not that much different from moving display lists into an extension. It would be interesting to see how one weighs the benefits of DLs to the benefits of their removal and why it continues to skew towards keeping them (especially when deprecated).

There is no identity crisis; OpenGL is the former (a low level API).

In my opinion improving display lists is not the way to go. DLs are much too complicated, you will never get that to work right.

Instead deprecate them, remove DLs completely from the API. Then, as an (ARB) extension add something that might be similar to the DLs as we know them, but has been clearly designed for the task to efficiently pass data to the driver thread. That means, many features that current DLs can do, should not be included, because they make DLs too complicated AND will not benefit us in terms of performance.

Jan.

I agree completely.

I don’t object to that approach, Jan, as long as it’s carefully thought through, and not just a philosophy based on vague platitudes. So what functionality would you explicitly remove from DLs to make them less complicated and more performant?

Well, i am not an export on DLs, i have never used them much, so i cannot tell you all the things that i would remove. I would actually do it the other way round: what things should be included in a DL-like approach to speed up rendering?

I can only speculate here, because i don’t know what things could be sped up, if the driver got them “in a package”.

Something that would be nice to have is a “geometry list”, where i give the driver a batch of triangles (NO other primitives allowed) and it stores them internally in whatever way for fast rendering. Such that i can render those with a “drawcall” and i know the internal layout is as optimized as possible. However for every batch (texture change, shader change, whatever) i would still need to build and execute different lists.

I think it would be exactly all the commands that are allowed in between glBegin and glEnd. However, it should be built on the generic vertex attributes. A bit of a difficulty here is how OpenGL handles generic vertex attributes, because one needs to ask shaders at what bind-point a given attribute is attached. This is a pain (already now), because it makes it impossible to always put texture-coordinates into attribute 1, because with different shaders a named attribute “texcoord” could be bound to any generic attribute bind point. Right now this is cumbersome, because everytime i bind a VBO i must ask the current shader, where it wants the arrays to be bound. With a display list approach this is basically impossible, because i cannot have “dynamic” decisions included. So there would need to be some better way (which i would love to have anyway!).

Another nice thing would be a “state list”, where i could put state-changes in. Upon creation the driver could remove redundant states and upon execution it could prevent unnecessary state-change (like shader or texture bindings that are already set). Note that this list should not act like a script, where states and other rendering commands are done in sequence, but merely like one big state-blob that would be set. Each hardware/driver could implement this in the most efficient manner possible, and since it boils down to one big state-change this should be easy to implement for EVERY vendor. Additionally, since those lists should be easy to execute in the driver-thread all prevention of unnecessary state-changes could be implemented by the driver, not the engine which would significantly reduce implementation-overhead in the engine AND would allow for sub-systems to simply set ALL states to their needed values, not only the states that are “most likely” wrong.

This would be great to make state-management easier. I could simply execute a state-list for every “material” that i use to render, which would set all render-states, bound textures, shaders and maybe even shader-uniforms in a single call. And the driver would know “this list binds shader A with uniform-values xy, so i can hardcode those values into the shader”.

The question is of course, whether there are states, that should be left out of those lists. Even after removing deprecated states, there might still be some states left, that make no sense to include.

I don’t think that there is need for a “command list”, which could call other lists, like “call state-list A, render geometry-list B, call state-list C, render geometry-list D, …”, because such things can be queued easily and the driver could always ignore executing a state-list A, if for example it detects that no geometry is to be rendered, because B’s bounding-sphere is outside the view-frustum (well, it should set those states that will affect subsequent rendering operations, of course).

I’d like to emphasize, that in my opinion it is absolutely necessary not to merge these two concepts, because than you actually end up with a display-list, as we know them, and as we all know, they might be nice on nVidia, but what we need is something that will work really WELL everywhere.

That’s what i can come up with, at the moment.
Jan.

I know one thing. The ability to do the following:

glNewList(42, GL_COMPILE);
glVertex3f(0,1,0);
glColor3f(1,0,0);
glVertex3f(1,1,1);
glEnd();
glEndList();

glBegin();
glColor3f(0,1,0);
glVertex3f(0,0,0);
glColor3f(0,0,1);
glCallList(42);
// note the lack of glEnd() - it’s in the display list!
// also note that I named the list 42 - the driver has to keep track of that and provide a lookup internally, instead of giving me an id that would be convenient for the driver.

Yes, drivers must support the above usage today. Yes, that must be a royal freaking pain, with lots of state keeping overhead.

Afaik it is already like that. Same for texture images and vbo objects.