On Monday 28 February 2005 14:28, Nicolai Haehnle wrote: > On Monday 28 February 2005 06:24, Daniel Phillips wrote: > > On Sunday 27 February 2005 09:37, Nicolai Haehnle wrote: [...] > > One fifo should do, the command ring buffer. Per-process command lists > > sound nice, but I don't see what they would be used for. > > Some means of indirect buffers are necessary for performance: > User space writes all non-protection-critical stuff into a DMAable memory > area that is supplied by the kernel. User space then instructs the kernel > to issue an "indirect buffer" command using this memory area, and the > graphics card will simply read the commands via DMA. > This way, we can transfer all the rasterizer setup data in the most > efficient way possible: User space can write directly into a DMA buffer > that will then be read directly by the graphics card. We don't have to do > intermediate copies or validation passes in the kernel.
Another interesting side effect is the ability to reuse command lists in one process once they have been executed by the graphics hardware. Apparently, this sounds very appealing to 3D speed freaks (even if, personally, I wonder if this is not too complex to manage). Without some for of per-process command lists (whatever the mechanisms involved, either hw based or kernel based), this is somehow difficult without copying in a multi-processes situation. > And no, I don't think the hardware needs explicit support for per-process > command lists. I agree. [1] But I won't miss the opportunity to underline that IMO, the hardware needs explicitly *not* prevent per-process command lists. Rodolphe [1] Though, once possible, one will quickly figure the "interest" of a dual-headed Quake computer; or in a single headed config starting Planeshift on VT1, Quake on VT2, top in text mode on VT3 and a regular X environment on VT7... Of course, this is not for a "production" system (except maybe in some cockpits...;-). _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
