Re: [Dri-devel] Mach64 dma fixes

[Keith P. <ke...@ke...>]

Around 18 o'clock on May 27, Keith Whitwell wrote:

> I think the multiplayer aspects of the game are a separate issue.  Talking 
> about the difference between a big display list with the whole quake level in 
> it and the visibility/bsp-tree/whatever-new-technique coding that quake & 
> other games use to squeeze as much as possible out of the hardware.

We had a big display-list vs immediate-mode war around 1990 and immediate
mode won.  It's just a lot easier to send the whole frame worth of 
polygons each time than to try an edit display lists.  Of course, this 
particular battle was framed by the "scientific visualization" trend of 
that era where each frame was generated from a completely new set of data.
In that context, stored mode graphics lose pretty badly.

However, given our experience with shared memory transport for images, and
given the tremendous differential between CPU and bus speeds these days, it
might make some sense to revisit the current 3D architecture.  A system
where the shared memory commands are validated by a user-level X server and
passed to the graphics engine with only a small kernel level helper for DMA
would allow for a greater possible level of security than the current DRI
model does today.

This would also provide for accelerated 3D graphics for remote
applications, something that DRI doesn't support today, and which would
take some significant work to enable.  I would hope that it could also 
provide a significantly easier configuration environment; getting 3D 
running with the DRI is still a significant feat for the average Linux 
user.

The question is whether this would impact performance at all; we're 
talking a process<->process context switch instead of process<->kernel
for each chunk of data.  However, we'd eliminate the current DRI overhead 
when running multiple 3D applications, and we'd be able to take better
advantage of SMP systems.  One trick would be to have the X server avoid 
reading much of the command buffer; much of that would make SMP 
performance significantly worse.

Keith Packard        XFree86 Core Team        HP Cambridge Research Lab