On Fri, 18 Mar 2005 02:13:56 -0500, Daniel Phillips <[EMAIL PROTECTED]> wrote: > 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.
There are some things, like perhaps the cursor glyph, which will done via indirect access. One register (address in the memory-mapped engine space) is an index into the cursor, and the other is where you write the data, and it auto-increments the index. But most things won't be like that. To write to, say, dX1dY is a simple pointer dereference, having a different address from dX2dY. Some addresses, like ones which target the rendering pipeline, dump into a FIFO. Some, like updating the cursor position, go direct. > > > 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. We can really make the engine aperture as large as we want. There's no reason to do everything indirect like that. > > 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 first X11 driver prototype will use all PIO to control the engine. Why? Because it's quickest and easiest to do it that way. We need to ramp up quickly so that we can start looking for hardware bugs. Plus, when the BIOS and kernel driver talk to the engine, they're not performance critical, so the best thing to do is just do everything by PIO. Only when you are doing something performance-critical does DMA become any kind of help. > > 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? The PIO interface to the drawing engine will have all the synchronization you need. TROZ is all PIO, and it's optimized to be efficient that way. Of course, it's also 2D only, but you get the point. Oh, and you'd never use the DMA and PIO interfaces at the same time for drawing, although you could conceivably switch back and forth. I've noticed in some X.org drivers that some XAA functions will do PIO, and others will use the ring buffer. Like for instance, a line segment will be started by PIO, but they'll use DMA for putimage. For our chip, I would suggest always using DMA after X11 starts, but I bet fbconsole will be done using PIO. > > > 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. These are all problems that can be solved in software; all the possibilities will be available in hardware, and people can experiment with them. > 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. I'm not leaving anything out of the spec. :) Seriously, I'm going to give the community enough rope to hang themselves with and them some. If they don't do things right, I'll flame them into submission. But really, what I want is for people to have the opportunity to innovate in ways that I cannot anticipate. > 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. Indirect DMA isn't more capable. It's just easier to schedule. > > 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 see your point, and remember, things are subject to change. > I am wild about keeping interfaces as simple as possible, and of course, > no simpler. Me too. :) _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
