Why abolish display lists on OGL2?

I don’t understand, why display lists are going to be aboilshed in OGL2. Ok, the new memory management provides a far more flexible and powerfull way. But display lists are just perfect for state management. Setting up a new state can be easyly done in OGL1. I think, in OGL2 should be something similair, not for rendering but state management.

My opinion:

While display lists can be used for some tweaks today, they are not required for good performance anymore. DL came in 1.0, and with 1.0 they were the only possibility to do “fast” texture switching, or fast rendering (no texture objects, no vertex arrays). Today we have texture objects and vertex arrays and other things, so basically the original purpose of display lists is obsolete. Another point is that today we have very few applications where OpenGL’s client-server architecture is used over the network(the case where DL are faster than vertex arrays because DL are server-side and vertex-arrays client-side), so the performance of these apps isn’t important.

So, DLs aren’t that important anymore, and it would be a simplification for the driver developers do drop DL, because they would have less work to write a complete OpenGL driver.

-Lev

Hello!

We’ve never stated that we are abandoning display lists in OGL 2.0. We’ve brought it up as a discussion point. Should we keep them around, or not? Lev makes some good points, showing that there are alternatives to display lists now. Implementing display lists is a good chunk of driver code for IHVs.

However, some folks use display lists for state management as you pointed out. For client-server models it is important as well(depending on your customers this might or might not be a big deal). Display lists are very useful in many situation, and perform well.

All in all, pros and cons to keeping them around. Maybe there should be a pure OpenGL 2.x version without them, while keeping them around for the full OpenGL 2.x version (for backwards compatibility).

Barthold
3Dlabs

Just because games don’t use the client/server nature of OpenGL - and most probably most PC software - doesn’t mean you should get rid of them.

Don’t SGI still use the client/server mechanisms of OpenGL for their huge server based rendering hardware? If they still require it and DL’s are used to speed this up, then it should be kept.

Don’t you think?

Luke.

I’ll argue strongly for keeping display lists in OpenGL 2.0.

  1. Display lists are already very popular and expecting people to abandom them in order to move to OpenGL 2.0 is unreasonable.

  2. The performance advantages of display lists when remote rendering are significant and some people really depend upon it. The PC-oriented people tend to forget about the client/server issues which more prominent in GLX-land.

  3. Alternative OpenGL implementations, like Chromium, can benefit a great deal from server-oriented display lists. Too bad we don’t have a good client/server vertex array mechanism yet.

-Brian

Originally posted by Brian Paul:
[b]I’ll argue strongly for keeping display lists in OpenGL 2.0.

  1. Display lists are already very popular and expecting people to abandom them in order to move to OpenGL 2.0 is unreasonable.
  1. The performance advantages of display lists when remote rendering are significant and some people really depend upon it. The PC-oriented people tend to forget about the client/server issues which more prominent in GLX-land.
  1. Alternative OpenGL implementations, like Chromium, can benefit a great deal from server-oriented display lists. Too bad we don’t have a good client/server vertex array mechanism yet.

-Brian[/b]

One thing I’d like to see - don’t know if it really is possible - is a kind of DL with texturing.

DL’s really a good for drawing simple objects fast that have only one (set of) texture(s) on it, but it’d be cool to have a sort of compiled DL’s with multiple textures.

Luke.

I just agree with Brain Paul and Lucretia, and have to ask Lev, if he was writing a 3D Engine in the last time. I’m doing so, and many of my graphical effects use DLs to speed up state switching. Of course need DLs a lot of work by the people who implement the drivers, but for gods sake: Thats their job!!! I’m just anxiuos to programm the first true OGL2 3D accelerator on my machine. But I’m a lazy guy and don’t want to recode state management procedures again and again. If somebody’d say to me: “Ok you’ve to implement a fast, easy to use and powerfull OGL command compiler, as DLs are, to make life of thousands of programmers out there easier”, then I’d sit down on my butt and solve the problem.

Get ride of them! IMO Display Lists are a thing of the past. Remove them. It will make the drivers cleaner, faster (since the developpers can concentrate on other problems), and more stable, i hope. I can clearly see the advantage of their use for client/server, but i’d then prefer a general mechanism like a glHint to tell if the textures or geometry should be stored client or server-sided.

Y.

Here’s the solution: make Display lists an ARB extension. That way, if an implementation want to implement them (for those who need them), then it has an ARB-approved way of doing so. If an implementation doesn’t want to, then they don’t have to.

hm, making DLs an ARB extension indeed seems to be a good idea, we already have something which is in the specs but isn’t required: the imaging subset, I could imagine DLs as optional GL_ARB_display_lists. Very cool idea, but what do ISV and IHV think? hm…

-Lev

Do display lists really help with state switching? The main reason I can see they do is that multiple state calls in one display list take one function call to execute them. Compare that to multiple calls in immediate mode to achieve the same. In other words, it saves you calling overhead. Is that a big deal compared to the geometry you are rendering?

Barthold
3Dlabs

It think so, since a DL could be compiled or something else, and stored in the GPU’s memory and so executed a lot of faster than by calling the state functions step by step.
For this reason they were implemented originally due to the network client/server model. Since I’m working with Linux and X11 I rely on the client server model.
But the ARB extension model is a good idea.

I think many people overestimate the grade of optimization DLs provide. Actually if you think that glGet* is valid in DLs then there is not as much room for optimization as many think. I don’t think drivers check if glGet* or other “slow” functions are used and if not they compile the whole thing in the DL into very optimized form. Another point is that DLs are not guaranteed to be stored in video memory or in AGP memory. AFAIK there are no drivers that store DL in video memory. IMO its really only a reduction of a call overhead, as Barthold said.

-Lev

[This message has been edited by Lev (edited 01-29-2002).]

It used to be way back when CPUs were slow :slight_smile: that storing say matrix multiplications in a display list could get you some benefit. The driver could precompute the result once and store that in the display list. On todays CPUs that is not a big deal anymore. For most other state setting the driver has to do real work, like internal state validation, change state on the hardware, maybe sync the data stream going down to the hardware, drain the rendering pipe, etc. That costs time, irregardless of if you do that in immediate mode or display list mode. Hence my statement that really the only thing you save is calling overhead.

Now, that can be a big deal on a client/server architecture, I understand that.

By the way, our Wildcat cards can store display lists either in video memory, or host memory.

Thus, if you believe that everything you can do with a display list you can do with vertex arrays (that is still debatable!) as far as geometry data is concerned, then the only difference is the fact that display lists can have state in them as well.

Barthold

Display Lists must Stay,
or OpenGL in VB becomes incredibly slow, as compiling the list once then using one command to display it takes much of the rendering away from the vb interpriter and speeds it up a great deal, couldnt they just add some amazingly cool features to display lists such as ones which are edited every frame by a modifcation list or something so you can build an animatioon in them?

If the main use for display lists is state changes, then a simpler mechanism for that effect could be created.

OTOH, I do like the idea of vertex arrays with state changes – some form of instruction stream, that is not opaque like DLs, but can be created and modified by the programmer.

in case of DL rmoval :
do you have though that people can use DL sharing hability of GLX to speed up drawing? one exemple i use evaluator and nurbs to render Freetype fonts, for memory optimisation i use GLX facilities to share DL of my glyphs.
anyway there must be a way to speed up networking rendering… windows user don’t see this since they can’t use X facilies but Unix user use it…