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: glGenLists argumnet

Hybrid View

  1. #1
    Junior Member Newbie
    Join Date
    Aug 2012
    Posts
    12

    glGenLists argumnet

    The argument specifies the number of contiguos display list blocks but i have no idea how this is of any practical information to me.

    In all the examples they simply put 1 in the argument.

    In what scenarios would i have a number other than 1?

  2. #2
    Senior Member OpenGL Pro
    Join Date
    Jan 2012
    Location
    Australia
    Posts
    1,098
    display lists are deprecated - I wouldn't worry too much about them useless you are maintain old code

  3. #3
    Junior Member Newbie
    Join Date
    Aug 2012
    Posts
    12
    Are you serious? What has replaced them then?

  4. #4
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,099
    Quote Originally Posted by darkdave
    The argument specifies the number of contiguos display list blocks but i have no idea how this is of any practical information to me.

    In all the examples they simply put 1 in the argument.

    In what scenarios would i have a number other than 1?
    Well, as the term range suggests, the return value + the range supplied by the developer lends itself perfect for iteration, as this contrived example shows:

    Code :
    GLsizei range    = 10;
    GLuint  baseIdx  = glGenLists(range);
    GLsizei rangeMax = 0;
     
    // check if lists could all be generated
    if(baseIdx > 0)
    {
       rangeMax = baseIdx + range;
     
      // setup lists
      for(GLsizei idx = baseIdx; idx < rangeMax; ++idx)
      {
           glNewList(idx, GL_COMPILE);
             // .. setup code for specific idx
           glEndList();
      }  
    }
     
    // assuming all went well we could something like
    // rendering only lists with even index
    if(rangeMax)
    {
      for(GLsizei idx = baseIdx; idx < rangeMax; ++idx)
      {
        if(!(idx % 2))
        {
          glCallList(idx);
        }
      }
    }  
     
    // clean-up
    glDeleteLists(baseIdx, range)


    DISCLAIMER
    : The above example is untested and may not be error free!

    glCallLists() works a little differently as it takes a void pointer to a list of names (i.e. values returned by glGenLists()). However, the API is inconsistent since you don't get back an array and have to build that array yourself, if I'm not mistaken. In contrast, current APIs like glGenTextures(GLsizei n, GLuint * textures), let's you specify a pointer to a contiguous block of memory directly and the parameter list of glDeleteTextures(GLsizei n, GLuint* textures) matches the generation API. BTW, display lists are fast but also completely static once set up so they don't lend themselves to any streaming whatsoever. Also, since any state changes you compile into the list are static as well, you can't, for instance, change a texture you want to use on the same unit used in the list since the list will simply override it.

    Quote Originally Posted by tonyo_a
    Display lists are deprecated - I wouldn't worry too much about them useless you are maintain old code
    Display lists aren't deprecated. They have long been removed from core - with GL 3.1 to be exact.

    Quote Originally Posted by darkdav
    Are you serious? What has replaced them then?
    There is no direct correlate. The way to go today is using vertex buffer objects if you want to be portable (core GL only) or use the NV bindless stuff if you've got an NVIDIA GPU. The latter I haven't used myself but fellow board member Dark Photon suggested the following:

    Quote Originally Posted by Dark Photon
    It gives you the absolute fastest possible batch launch I've ever seen. It ties NVidia display lists in performance, which is really stellar. If you have a lot of varied content (a lot of batches, and potentially a lot of buffers), batch launch speed is critical for maximum GPU utilization.

    As I recall based on my testing a while back, in order of fastest-to-slowest performance, you have:



    1. Bindless VBOs (no bind!) -- Ties NVidia display lists for the crown
    2. Streaming VBO (bound)
    3. Client arrays
    4. Static VBOs (bound)



    Note that VAOs help accelerate bound VBOs some, but bindless VBOs surpasses that.

    As I recall a streaming VBO surpasses static bound VBOs in perf, which is surprising because of all the CPU->GPU streaming. But this streaming pipelines very well, and you get rid of nearly all the buffer binding that you have with static bound VBOs.

    Of course, how this all shakes out in practice depends on things like batch size, batches per buffer, number of batches and buffers, CPU and CPU memory speed, etc. The nice thing about bindless is that with it, batch/buffer sizes and number of batches/buffers matters a whole lot less. It's just a lot faster.
    Before the end of the world finally hits us, you might want to check that stuff out.

  5. #5
    Junior Member Regular Contributor
    Join Date
    Dec 2007
    Posts
    249
    you can continue to use display lists forever if you are just using opengl 1-2

  6. #6
    Senior Member OpenGL Pro
    Join Date
    Jan 2012
    Location
    Australia
    Posts
    1,098
    They have long been removed from core
    I stand corrected

Posting Permissions

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