On Friday 18 March 2005 05:02, Attila Kinali wrote: > On Thu, 17 Mar 2005 18:50:50 -0500 I wrote: > > Just for reference, how about describing the mga approach here? > > It uses always indirect DMA for all commands. > > a DMA transfere looks like this: > (Disclaimer: i do not fully understand how the matrox DMA > system works. I'm quite sure i missed quite a lot of it) > > * Set up secondary DMA transfere buffer. > * Set up primary DMA buffer to read from the secondary buffer(s). > * Write PRIMEND (end of primary buffer) to start transfere. > > The data written in the primary DMA buffer are > register + value pairs which will be loaded into the GPU > and then trigger further processing (eg running a 2 stage > DMA).
OK, the two level DMA structure is not unlike our current proposal. (Hmm, I ask myself is this where Timothy got his model or did he arrive at it from first principles as I did...) The register model however is an obsolete throwback that I would like to eradicate from our design. We have a command stream, commands have command fields, there may be no simple mapping between command fields and registers. We certainly do not need register numbers in the command fields. In fact, we don't need registers at all, except for DMA control and similar. We don't even need registers for reading GL state: the driver knows the GL state, and as a bonus, it knows the current values, not state as of some time in the past, which is what the rendering pipeline knows. Getting rid of the requirement for reading GL state from the card gets rid of a whole class of messy pipeline synchronization issues. The only plausible argument for having registers I've seen so far is for debugging, and then it's unimportant to have any formal definition. Let's just get rid of the idea of drawing registers, it's obsolete. > The thing that makes it ugly for me is, that every transefer > is based either on whole lines or whole pixel. This has the > disadvantage that if my user space program has a picture to > draw, that i needs to be split at line ends and that the > lines are may not cross page boundaries under any circumstances > unless the pages are continous. We haven't even gotten to that part yet, so it can't possibly be misdesigned ;) I'm working on the assumption that when a command deals with a rectangle, the engine is smart enough to process the whole rectangle. Raster lines don't come into it at all, at the command level. > For more information, please have a look at > http://attila.kinali.ch/mga_dma-Ville_Syrjala.tar.bz2 > which is a kernel module written by Ville SyrjÃlà ([EMAIL PROTECTED]) > to test the DMA capabilities of matrox cards. Thanks muchly. Regards, Daniel _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
