chromium-dev

[Chromium-dev] Display list management

[Andres L. C. <and...@cs...>]

Hi,
I'm trying to understand what is the functionality of the dlm module in 
Chromium.
Scanning the cr tree I found there are rather limited uses of it, 
actually three SPUs: replicate, tilesort and expando

The first two fan-out one gl stream to several renderers, so I infer 
that dlm is used to keep track of the display lists in these one-to-many 
environments.

What about expando? The description indicates it "unfolds" a display 
list. This will impact performance...in which scenario is this SPU 
useful? debugging? does it have to do with correctness/conformance?

Thanks a lot to anyone who can shed some light on this :)
Andres

Re: [Chromium-dev] Display list management

[James S. <arr...@gm...>]

My understanding is that a display list is basically a sequence of
OpenGL commands that are sent to their server and from that point
onward may be invoked by a single command. In this way, we avoid
having to send the whole sequence to the server every time we use it
(it saves bandwidth).

The replicate has something to do with the VNC SPU, which I am not
familiar with yet.

The tilesort SPU performs a number of "optimizations" using display
lists. For example, I think it can compute which tiles the DL (Display
List) effects and send it to only the Render SPUs that are on that
tile (in theory, with the right configuration).
For example the option "auto_dlist_bbox" tells the tilesort SPU to
compute a bounding box for the dlist and only send CallList commands
to tiles that will be effected by that dlist.
The "lazy_send_dlists" sends DLs only to the tiles that need them, and
only when they need them. ig. if a DL is only needed on one tile, it
is only sent to that tile. If it later is needed on another tile it is
then sent to the second tile. It optimizes performance.

In general, the Expando SPU would hurt performance, but there is a lot
of things to account for (in a few rare cases it might make things
faster?). My guess is that it is for debugging.

Thank you for your time,
James Steven Supancic III

Re: [Chromium-dev] Display list management

[Robert E. <pa...@tu...>]

> I'm trying to understand what is the functionality of the dlm module in 
> Chromium.

"DLM" is the Display List Manager.  It provides for display list state roughly 
similar capabilities to what the state tracker provides for simple state, and 
can be used for similar purposes.

It is typically used to record the contents of all display lists in memory, for 
replay when necessary or for debugging issues involving display list contents. 
It can also be used to track state changes due to display list use (i.e., 
glCallList() can cause graphics state changes that are difficult to track any 
other way).

> Scanning the cr tree I found there are rather limited uses of it, 
> actually three SPUs: replicate, tilesort and expando
> 
> The first two fan-out one gl stream to several renderers, so I infer 
> that dlm is used to keep track of the display lists in these one-to-many 
> environments.

Right.  "tilesort" has options that allow it to send display lists "lazily", 
i.e. only to those hosts that need it.  In this case the display lists are 
cached on the host, and replayed as necessary.  "tilesort" also has an option to 
enable display list state tracking, which fixes some applications that rely on 
the use of state changes in display lists.

"replicate" is used for a specialized type of state replication for a particular 
VNC implementation.  This implementation uses an encoder module working beside 
the normal VNC stream in which the OpenGL command stream is encoded; the 
commands are then rendered on the remote viewer (instead of having the commands 
rendered locally and transmitted as pixmaps; this is a performance improvement 
for some applications).

The problem is that a new VNC viewer can attach at any time; and any new VNC 
viewer needs the entire OpenGL state (including display lists) sent to it so it 
can "pick up" already-started instances of OpenGL programs.  That's what the DLM 
is doing there.

> What about expando? The description indicates it "unfolds" a display 
> list. This will impact performance...in which scenario is this SPU 
> useful? debugging? does it have to do with correctness/conformance?

"expando" is something of a "toy" SPU, sort of like the "wet" SPU.  It provides 
an example implementation of how an SPU might use a particular feature, in a 
nominally valid but not terribly useful sort of way.  (It's certainly the case 
that the "wet" SPU is more fun than the "expando" SPU, though. :-)

Bob Ellison
Tungsten Graphics, Inc.