On Wed, 2 Feb 2005 17:22:26 +0100, Nicolai Haehnle <[EMAIL PROTECTED]> wrote: > On Tuesday 01 February 2005 23:06, Timothy Miller wrote: > > To all: > > > > Ok, here are the kinds of DMA transactions that I want to support: > > > > (1) Direct command buffer. Using a ring buffer with "read pointer" > > (controlled by GPU) and "write pointer" (controlled by CPU), the host > > can fill an empty portion of the buffer, starting at the write > > pointer, with command packets. The GPU fetches words in blocks and > > feeds them into the GPU fifo. > > > > (2) Indirect command buffer. Using PIO or a ring buffer, arbitrary > > host address ranges are specified. The GPU fetches them in blocks, in > > order. This is useful for multitasking, where there is a central > > server and individual packets from different processes are thrown into > > the one ring buffer. > > I have one wishlist item here, based on the following two points: > a) The kernel must ensure that 3D clients cannot program arbitrary hardware > addresses. > b) 3D clients will push *a lot* of data via DMA, especially for rasterizer > setup. > There should be some way for 3D clients to send this data to the card > without the kernel having to look at it. For example, if you decide that > rasterizer setup data is sent via command buffers (either direct or > indirect) you should implement a "secured" indirect command buffer mode > that works exactly like normal command buffer mode, but ignores any writes > to registers that can affect DMA transfers.
Here's the idea I'm kinda going after: DMA commands to the rasterizer will go in structured packets. There will be a packet header that contains a command number and a bunch of bitflags that indicate which registers are actually being modified. The two major kinds of packets are: (1) State packets which specify parameters for units past the vert and horiz rasterizer units (enables this, set that, etc.), and (2) Render packets which specify parameters to the vert and horiz rasterizer stages. When a set of packets are submitted, the kernel can specify which kinds of commands are accepted and which are rejected. This way, a user app can't make anything other than rendering calls. > > Of course, if you decide that rasterizer setup data will be passed through a > different, specialised channel, then this wishlist item becomes less > important. > > > (3) Direct data move. Data to be written to graphic memory is loaded > > directly into the ring buffer. In this case, the graphics memory, > > rather than the GPU engine is the target. Moves from card to host are > > not possible this way. > > > > (3) Indirect data move. Using either PIO or a ring buffer, arbitrary > > host address ranges are specified. The source/target is graphics > > memory, and either reads or writes can be specified. > > > > For indirect DMA, an interrupt can be asserted for the completion of > > each unit. For direct DMA, two interrupts are available: ring empty; > > ring has reached low water-mark. > > For indirect DMA, consider the following scenario: > Let's say we have a command buffer that is very long (possibly because there > are many indirect command buffers queued by the direct command buffer). Now > there may be more than one indirect DMA command in this buffer. How can the > interrupt handler be certain which of these commands triggered the IRQ? How about a "tag" command. All this one does is stick a number into a register and assert an interrupt. If more than one tag command gets through, you just have to make sure the numbers are sequential. > I'm > especially thinking of corner cases where IRQs may get lost. I think some > kind of "age" or "timestamp" counter in the card could easily solve this. I think this is analogous to what I suggested. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
