On Fri, 18 Mar 2005 14:24:22 -0500, Daniel Phillips <[EMAIL PROTECTED]> wrote: > 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...)
I got it from experience with a different chip, plus some of my own ideas. As for interrupts, I've never seen another chip have "fifo/buffer almost empty", or even "fifo/buffer completely empty." I've only seen them have "engine completely idle". > > 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. Perhaps I'm thinking in terms of an archaic design philosophy, although I have designed a GPU before, and it seemed most logical to do it this way. Here's how the pipeline works: Each pipeline stage that you see in the model is really composed of many substages. One of the early substages is responsible for extracting register writes. See, we want writes to occur in pipeline order, and we don't want to stall the pipeline when writing to registers, so we just carry them down the pipeline just like fragments. To extract the register writes, they're identified by number. If the register doesn't belong to this stage, it's passed along; if it does belong to this stage, it's stored and dropped; and if it partially belongs to this stage, it's stored and passed along. Given this architecture, the registers need to be numbered, and there's little reason not to number them as a subset of all of the rest of the registers in the chip and give access to them the same way. Really, as it turns out, the biggest negative is that the logic to translate the DMA packets into the appropriate register writes is non-trivial. This is why some chips use a microcontroller for this purpose. If I have to develop anything programmable for that, it'll be documented. Smile. :) > 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. You have to store the state information SOMEWHERE. Those where's are registers, and they have to be numbered. > > > 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. Our DMA will be linear data. There are no rectangles, and the scanline granularity is to the pixel. None of the things you're talking about are going to be a problem. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
