On Thursday 17 March 2005 22:51, Timothy Miller wrote: > On Thu, 17 Mar 2005 19:51:42 -0500, Daniel Phillips <[EMAIL PROTECTED]> wrote: > > That's it: three PIO registers, two command/status bits and a > > four-bit command/status field. We press the cursor upload > > mechanism into double duty, a nicety I'm rather fond of. > > You keep mentioning the cursor.
Like I said, that's because I fixated on it ;) Seriously, if you have one PIO gizmo capable of uploading N words of data, why not use that for every different vector that needs uploading via PIO? Instead of calling this the "cursor upload register" I should really just call it what it is, the data register. > The cursor is only one of numerous things that will be accessible via > PIO. Right. So I would like to suggest a two register interface that handles uploading any vector. You write the number of the thing you want to upload and how many words it is into one register, then you write the words into the other (the data register). This is economical, robust and extensible. > All engine registers (for > reading), the engine write fifo, debug, status, interrupt control, > etc., etc. will be accessible via PIO. Basically, via PIO, you'll be > able to access all priveleged and unpriveleged registers. I see why you'd want to read engine registers by PIO (since there is no other way) but not why you would want to write them, except for debugging. Doing 2D graphics via PIO makes zero sense to me. > The only > reason DMA can't get at priveleged registers is because the command > packets will always refer to registers implicitly. Of course. But that should be enough. If you think that having a PIO interface to write the internal registers will speed up debugging, great then, it's worth it. But this interface should not be exposed as a drawing interface. There is no proper synchronization for one thing. We already have a way to draw for another, so what is the advantage of having two ways to draw, that race with each other? > BTW, you'll also be able to put rendering command packets into the > ring buffer. Yes, I remember that from way back. We can get by without it, obviously. Maybe the X server would use this feature to avoid some indirect DMA setup commands, which might matter for some loads (I have my doubts). But then you introduce the need for userspace locking around the DMA write register, which isn't needed if only the kernel touches that register. I'd suggest leaving this feature out of the spec, but maybe implementing it just to see if it actually does anything useful, which I doubt. 3D applications will always use indirect DMA, first because it is more capable and, and second because they aren't allowed to use direct DMA. > What protects against applications initiating DMA is > that an indirect DMA request from an indirect DMA buffer is invalid, > because the "stack" only goes one level deep (read: such commands > will be silently dropped). Understood. (Waaaaay back there!) I see what you're thinking: you have one command decoder and it doesn't care what the source is, however you selectively suppress a few command types depending on the source. But that sounds like a solution looking for a problem. You can easily separate the two command sets cleanly. Nobody has shown a command that needs to be available in both direct and indirect DMA mode, except for your direct DMA drawing. As you may have noticed, I am not wild about that feature. I am wild about keeping interfaces as simple as possible, and of course, no simpler. 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)
