Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 6 of 6

Thread: why ARB remove display list in in OpenGL Version 3.1?

  1. #1
    Junior Member Newbie
    Join Date
    Apr 2012
    Location
    -- Please Select --
    Posts
    8

    why ARB remove display list in in OpenGL Version 3.1?

    In OpenGL Version 3.1, display list was removed through deprecation.
    I'm a beginner,who can give me reasons?
    thanks

  2. #2
    Member Regular Contributor
    Join Date
    Jan 2012
    Location
    Germany
    Posts
    325
    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).

  3. #3
    Advanced Member Frequent Contributor
    Join Date
    Apr 2009
    Posts
    578
    Um.. err.. checkout Mark Kilgard's post here: http://www.opengl.org/discussion_boa...y-lists-in-3-1

    Quote Originally Posted by Mark Kilgard
    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_Kilga...l-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
    Last edited by kRogue; 05-03-2012 at 05:38 AM.

  4. #4
    Member Regular Contributor
    Join Date
    Jan 2012
    Location
    Germany
    Posts
    325
    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).

  5. #5
    Junior Member Regular Contributor
    Join Date
    May 2012
    Posts
    100
    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.

  6. #6
    Advanced Member Frequent Contributor
    Join Date
    Dec 2007
    Location
    Hungary
    Posts
    985
    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.
    Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
    Technical Blog: http://www.rastergrid.com/blog/

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •