Display lists in 3.1

[Brolingstanz]

Nvidia has a spec sheet on their webstie detailing the differences between the Geforce and Quadro if you're interested...

www.nvidia.com/object/quadro_geforce.html

[ZbuffeR]

This document is only 7 years old

[peterfilm]

To be honest, I'm prone to exaggeration. It certainly outperforms my desktop!
All the best.

[aronsatie]

Well, my not knowing the difference comes from suspicions based on what friends of mine with a lot of experience with Quadros and Open GL told me.

Even though they work with Quadros all the time, they are still unsure about if they are any faster then their Geforce counterparts. They consider them better built and more reliable, and they told me that reading back data from Quadros is faster because it is hardware accelerated. For me, the latter would be a huge advantage because I work with broadcast video, so if anyone could confirm it I would certainly start to think about buying a Quadro instead of waiting for Fermi.

[Ragnemalm]

For my personal projects, I have moved to core-GL3.2. I did not regret it yet.
What I like most of it is that it somehow "frees your mind":
1.) You no longer need to decide "do I use fixed function for this, or do I write a shader?". Now everything is done in shaders. And writing a just small shader is most times easier than to configure the FFP to achieve a certain effect.
2.) Which version of an extension do I use (EXT/ARB/Core)? Things like geometry shaders and FBOs are "just there".
3.) In your program, you no longer need to care about mixing various fixed function states and their modern counterparts. No longer you need to care about glEnable(GL_TEXTURE_2D) and the like. I never need to use glUseProgram(0). Shaders are always active, etc...
4.) No more wondering "do I use built-in GL state in my shaders or do I use my own? Which one is faster?". Since most built-in stuff is gone, the answer is clear now :-)

There are some downsides, though. Currently, there is no measurable performance improvement between the core-profile and the compatibility profile. But there's hope, that one day, the drivers will make a distinction and reward my efforts :-)
I used immediate mode for drawing debugging stuff. I needed to implement a small "Immediate Mode Emulation" for that purpose now. Since all matrix-stack stuff is gone, I needed to implement it by myself, using UBOs. Once done, I don't miss it anymore.
What I really miss a bit is glPushAttrib/glPopAttrib... I used it often to temporarily change state and then restore it when done. I have now resorted to some kind of "fixed default state". I just assume some "default state" that must be set is always set this way. Whenever I need to desert from this state, I restore it by hand afterwards.

I moved to 3.2 recently, and most of the time it is just fine. Transformations are straight math, geometry are always arrays. No problem there. (But your point 2 doesn't make sense. EXT and ARB will always be there for new features and that is something good, not a problem. That is how OpenGL stays modern between major releases.)

I do miss immediate mode a little bit (for quick and safe tests as well as first examples for beginners) but I can make a layer for that any day. It isn't hard.

But display lists is what really disturbs me. There is no way to replace them. I have written a layer between a 2D API and OpenGL (Apple's QuickDraw, really nice API but the original library is old), and with OpenGL 2 that is no problem, I can do pretty much everything. But OpenGL 3.2, no. No display lists, no metafiles (in QuickDraw, Pictures/PICT, in Win32 in-memory EMF, in Core Graphics PDFs).

OpenGL lost its ability to handle metafiles and there is no simple (portable and safe) way to create that on top! Or did I miss something?

[thokra]

I do miss immediate mode a little bit (for quick and safe tests as well as first examples for beginners) but I can make a layer for that any day.

You don't save that much time using immediate mode and if you want to prototype anything using shader, well, you'll have to use shaders anyway so that already puts you half-way to complying to GL 3.1 rules. Plus, if you start prototyping something in immediate mode and later decide to rewrite the whole thing to use, say, 3.3 core, you'll do extra work. You should simply get used to going directly for the new stuff. For beginners it's not advisable to use the FFP at all! Everyone new to OpenGL since 3.1 got ratified should at least start there.

EXT and ARB will always be there for new features and that is something good, not a problem. That is how OpenGL stays modern between major releases.

No, vendor specific extensions are there for new features, like GL_NV_bindless_texture. EXT extensions, if ever introduced, usually take enough time to call a feature pretty much standard on current hardware. ARB extensions and promotion to core usually take even longer.

But display lists is what really disturbs me. There is no way to replace them.

Although I can't refer to the concrete post, I think aqnuep already established that VBOs may perform as fast as display lists if properly implemented. Unless you profile the difference between using a VBO and a display list on your hardware and current driver, there is no way to tell if and how VBOs are inferior to using a display list.

OpenGL lost its ability to handle metafiles and there is no simple (portable and safe) way to create that on top! Or did I miss something?

Please correct me, but I never ever read anything about direct support for graphics file formats in OpenGL in any way.

[Dark Photon]

But display lists is what really disturbs me. There is no way to replace them.

To clarify that, there's no "core" way to replace them with equivalent or better performance (AFAIK).

That said, I can get NVidia display list performance with non-display list batches using their bindless extension (specifically GL_NV_vertex_buffer_unified_memory), but that is not EXT or ARB yet, much less core. Because of this, I consider the removal of display lists from core completely premature.

Display lists are yet another reason to just use the compatibility profile. They're easy, and the performance benefit can be significant.

[Dark Photon]

I moved to 3.2 recently, and most of the time it is just fine...

By the way, why did we have to go back and resurrect a 2 year old thread here.

Wonder if the new forums would let us put a lock on threads after 3 months or so of inactivity...

[Ragnemalm]

You don't save that much time using immediate mode and if you want to prototype anything using shader, well, you'll have to use shaders anyway so that already puts you half-way to complying to GL 3.1 rules. Plus, if you start prototyping something in immediate mode and later decide to rewrite the whole thing to use, say, 3.3 core, you'll do extra work. You should simply get used to going directly for the new stuff. For beginners it's not advisable to use the FFP at all! Everyone new to OpenGL since 3.1 got ratified should at least start there.

Immediate mode and shaders are unrelated in this context. Sure, one big change in 3.2 is that you must use shaders, but Immediate Mode is glBegin/glEnd and may include shaders as much as we like/need. What I see in the student labs is that the increased use of buffers give students a lot of trouble. Many are Java-damaged and don't understand concepts like addresses and pointers.

And we do start at 3.2 exactly for that reason, but the start is slower and more complex. Of course that is a concern! I may lose students from the course at the first lab because it is too hard!

Please correct me, but I never ever read anything about direct support for graphics file formats in OpenGL in any way.

Display list support is metafile support! Not in a way that can easily be saved or loaded, but in the same way that QuickDraw, GDI and CG supports in-memory metafiles.

What OpenGL would have needed to have good metafile support is a convenient way to read out the contents of a metafile in a way that can be converted to PDF or whatever - not to remove them. (And yes I know that they are not totally gone, but it disturbs me to write new code with deprecated calls.)

By the way, why did we have to go back and resurrect a 2 year old thread here.

Wonder if the new forums would let us put a lock on threads after 3 months or so of inactivity...

In many other fora, it is considered highly impolite to start a new thread about a subject that has already been discussed, so I have made it a habit to search for related discussions. You can often find past conclusions to build on.

This particular discussion has grown much more current the past year, since it is right now that 3.2 has become universally available, and that is why I have moved my CG course to 3.2 now.

[thokra]

Immediate mode and shaders are unrelated in this context. Sure, one big change in 3.2 is that you must use shaders, but Immediate Mode is glBegin/glEnd. What I see in the student labs is that the increased use of buffers give students a lot of trouble. Many are Java-damaged and don't understand concepts like addresses and pointers.

And we do start at 3.2 exactly for that reason, but the start is slower and more complex. Of course that is a concern! I may lose students from the course at the first lab because it is too hard!

All I said is that there's nothing to miss about immediate mode and that you fare much better starting at 3.1+ right off the bat. And no, immediate mode and shaders aren't unrelated since an active shader program determines what happens with vertex attributes submitted with immediate mode commands. Using buffers maybe confusing to the beginner at first but that isn't due to Java or any other language. If one doesn't know how computer memory is organized and what addressing means then that's a general shortcoming that will prove to be an obstacle with a lot of other stuff as well, not only OpenGL. Aside from that, there are much more complex things out there than pointers. If you loose students after the first course because using buffers is too hard ... that's not OpenGL's fault.

Display list support is metafile support! Not in a way that can easily be saved or loaded, but in the same way that QuickDraw, GDI and CG supports in-memory metafiles.

What OpenGL would have needed to have good metafile support is a convenient way to read out the contents of a metafile in a way that can be converted to PDF or whatever - not to remove them. (And yes I know that they are not totally gone, but it disturbs me to write new code with deprecated calls.)

Please, please explain to me how supporting display lists, which is basically a collection of GL commands that can be executed together at an arbitrary point of run-time, is equal to supporting a totally unrelated, platform dependent graphics file format. I really don't get it.