View Full Version : why ARB remove display list in in OpenGL Version 3.1?
05-01-2012, 07:04 PM
In OpenGL Version 3.1, display list was removed through deprecation.
I'm a beginner,who can give me reasons?
05-02-2012, 01:50 AM
Performance. Also, displaylists are mixing data and state changes but you might want to sort your rendering order to minimize state changes and draw as much data as possible with one draw call. Displaylists don't help you with that.
Displaylists are useful to get some more performance out of glBegin/glEnd style immediate mode - but that is also deprecated, slow and far from how GPUs work (don't waste your time learning that).
05-03-2012, 04:49 AM
Um.. err.. checkout Mark Kilgard's post here: http://www.opengl.org/discussion_boards/showthread.php/167162-Display-lists-in-3-1
The sad thing is that display lists remain THE fastest way to send static geometry and state changes despite their "deprecation".
On recent NVIDIA drivers, the driver is capable of running your display list execution on another thread. This means all the overhead from state changes can be done on your "other core" thereby giving valuable CPU cycles back to your application thread. Display lists are more valuable today than they've ever been--making their "deprecation" rather ironic.
* For dual-core driver operation to work, you need a) more than one core in your system, and b) to not do an excessive number of glGet* queries and such. If the driver detects your API usage is unfriendly to the dual-core optimization, the optimization automatically disables itself.
Going further take a look at slide 182 and on at: http://www.slideshare.net/Mark_Kilgard/sigraph-asia-2008-modern-opengl-presentation [a presentation of Kilgard]. That presentation clearly states that display lists are a performance win... which likely should be read as display lists are a performance win on GL implementation that do it well (read in this context as NVIDIA).
My main complaint about display lists is that I have trouble remembering what commands running become part of display list state and what does not.
I can always dream up of a cleaned up display list for GL... dream
05-03-2012, 05:08 AM
Whenever I see displaylists in real world code, I also see lots of glBegin/glEnd with small batches of geometry and lots of unsorted state changes. Oranizing your data in large batches and pushing those to the GPU memory is more like the gpu actually works.
However, it is true that without DL we don't have the option anymore to collect sequences of static draw/state change commands to be later re-run as one command. Such a mechanism you still be useful if those commands would reside in GPU memory and be executed directly by the command processor of the GPU without any CPU cycles at all. Think of MultiDrawIndirect with a draw buffer on steroids (but that would be a quite complex addition I guess).
05-03-2012, 07:50 AM
The concept of display lists has some advantages if it's implemented properly. Yeah? Well this applies to any API feature, it has to work. So giving the excuse that display lists were removed because some implementations are not good enough at it is unrealistic :)
I think the main reason they are deprecated is to make driver implementation easier and hence bug free.
If you think how OpenGL is evolving, you will find it's driven by how to make life easier for IHVs rather than the hardware and API clients demands. :)
05-03-2012, 09:27 AM
Display lists haven't been deprecated because there were some slow implementations. In certain cases display lists can be faster than your own code on both AMD and NVIDIA. However, if you properly use the hardware, you most probably get the same performance without them anyway (maybe even better, but this varies case by case).
Display lists have been removed because it was ill-specified.
Just some examples: if you had a VBO and vertex arrays set up using it, and then issued a draw command inside a display list, the spec says the driver should read the data from the VBO and compile it into the display list, thus replicating the whole data. Besides that, state changes affect display lists which is nuts.
There are actually hundreds of issues like that with display lists. The concept of being able to pre-compile commands is good and hopefully at some point we will have something like that again, but display lists were designed with GL 1.0 in mind and thus were simply incapable to handle properly the new features added later on.
Powered by vBulletin® Version 4.2.3 Copyright © 2017 vBulletin Solutions, Inc. All rights reserved.