On Sat, 19 Mar 2005 12:09:41 +0100, Lourens Veen <[EMAIL PROTECTED]> wrote:
> > If I understand correctly, the plan (or at least one plan) is to only have DMA > commands in the ring buffer. If you want to draw something, you make a list > of drawing commands, and put it in DMAable memory somewhere. Then you add a > command to the ring buffer that will make the card DMA that list of commands > to its local drawing FIFO (or wherever it needs to go to get them executed). > The drawing command set itself is limited: it does not contain any privileged > commands. This way, an (unprivileged) 3D client can draw things, but not > change any important settings, simply because it can not express such a > request. This is what Timothy and Daniel call "indirect DMA", because the > card first gets a command from the ring buffer (via DMA), and then uses that > command to do a second DMA transfer which transfers the actual commands > issued by the 3D program. Yes. On the structure of rendering commands: The first word contains a command number and a set of bits that indicate the presence of an optional parameter. For instance, you'll have some state commands that contain things like base addresses, pitches, and other things distributed through the pipeline; for any one that you don't want to load, set its flag bit to zero and shorten the packet where the word would have gone in sequence. Also, you'll have rendering commands that include common parameters needed for rendering triangles (texture coordinates, colors, etc.), and they'll have the same basic format, but they'll also tell the VerticalRasterize stage to "go". There won't be any "draw line" commands just yet. Too complicated, and we don't have space for a microcontroller to do the necessary math. Our rendering commands are little more than PIO register writes with implied addresses, so they use less bandwidth. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
