Display lists, etc., comments from Dair

[James W. W. <ja...@fr...>]

"Mikey" recently asked why Quesa does not use display lists.  This 
led me to ask Dair Grant a couple of questions, and (with his 
permission) here are the responses.

>1.  Why doesn't the interactive renderer use OpenGL display lists?

The history of "fast drawing" in OpenGL has changed over time - display
lists were really the only option originally, however these were fairly
quickly replaced with glDrawElements.

The modern approach is to use VARs/VOBs, which are basically a way to
allocate geometry in VRAM and synchronise the CPU with the GPU when it
comes to manipulating that data.

This lets the CPU lock the data when it needs to update, unlock when
done, and then get on with other work while the GPU is pulling the data
across for processing.

The mantra nowadays is that you get the best performance by minimising
contention between the CPU and GPU - in the best case, they should be
running entirely in parallel so that one is never blocked on the other.

That was the kind of direction I was hoping to go in eventually; the
TriMesh has a lock/unlock API now which would make that quite feasible,
as all that would need to happen would be the renderer provide the
ability to allocate/lock/unlock a "geometry object" (== VOB or whatever,
but exposed as an opaque type to the rest of the system so the core lib
didn't have to know it was sitting on top of VOBs/VARs/Apple_fence, etc)
and then the higher level API uses that to copy changes in as necessary.


I didn't really do much investigation into the benefits of using display
lists to capture rendering state (which is the other thing they're handy
for), as from what I've seen when porting games over to the Mac they're
rarely used in those circumstances.

Typically people will have their own little state buffer to avoid
pushing redundant changes down, and then a geometry manager that looks
after a circular list of vertex buffers - as data comes down for
rendering, it gets copied into buffers and submitted with glDrawElements
(although there's normally a lock/unlock model on top of this, so I
assume most people are moving to the VBO approach too).


>2.  Why does the IR do its own backface culling instead of letting
>OpenGL do it?
>
>These are related because we'd have to lose the backface culling in
>order to use display lists effectively.  We wouldn't want to have to
>flush cached display lists every time the camera moves.

The IR does its own backface culling because unfortunately GL's culling
is less expressive than the options QD3D provides.

I forget the exact details (I think there's plenty of comments
hopefully; I have a feeling I posted a big summary to the list for
posterity at some point), but it's to do with the orientation style.

IIRC, GL does its culling based on the screen projection of the vertices
or something - while in QD3D it's more complicated, and the various
permutations of culling styles (including flip) and orientation styles
means you can't implement QD3D's model on top of GL.

Bit fuzzy, I know, but I think this was a long-standing problem for
Interstudio which we finally fixed by handling all culling ourselves
rather than trying to let GL handle it in some cases (if you grep for
everywhere orientation and culling styles are mentioned, you might find
the comments).


In terms of if switching to display lists will be the best solution, I'm
not sure it would be. It's definitely the right idea (the more you let
GL manage data the better, as it gives it a chance to live in faster
memory), but it's not the "modern" approach.

I would look at VBOs/VARs before making any big decisions, and see how
basing something on top of them would fit (or even APPLE_fence: the key
idea which takes them beyond display lists is that they give you more
opportunities to avoid contention between CPU and GPU, which is the key
to getting good performance nowadays).

What might be worth doing is breaking the IR down into an "interactive
renderer" and a "rendering engine". I.e., build a couple of objects
which provide:

   - Texture management
   - State management
   - Geometry (vertex and index) management

And move all the GL code inside them. They should expose the bare
minimum, and then all the more QD3D-related code can live in the IR as
an intermediate between the scene graph (the QD3D library) and the
actual rendering API (GL/D3D/etc).

That would mean the IR would really just handle state buffering,
geometry decomposition, view state stack, etc - and means you can have
some lower level services which are effectively QD3D-independent means
to talk to a modern graphics card and deal with the four key things
they're based around (textures, state, geometry, and shaders).

Kind of like resurrecting RAVE I suppose, but designed with a "you need
to lock if you want acess to data, and unlock when you're done" model
that would allow you to dump data into VARs/VBOs - or even record
snapshots into display lists which you then play back, if that did turn
out to be faster (but I'm not sure it will be: I've only see one game
that used display lists, and they had it #if'd off for the PC version so
we never bothered turning it on for the Mac).

I think that's something the IR suffered from a bit - in retrospect, it
would have been better to write a "simple 3D engine based on modern GL
which doesn't expose GL types/APIs" engine first, and then write a
"translate from QD3D world to our engine" second to form the IR.


-dair (one other reason for VBO/etc is that it's quite suitable for
hooking up to vertex shaders for animation/etc - display lists really
predate programmability, so I don't think they would turn out to be very
useful if you also wanted to explore shaders one day)

(i.e., once you've recorded a display list the data is locked away
inside: but for shaders you need to be able to tell the shader where to
read data from via (effectively) a pointer to the geometry data - the
pointer may be on the card and so unmapped to you, but you can still
pass the value around even if you're not allowed to read from it (the
shader can read from it since it'll be on the card too))

-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>