On Friday 18 March 2005 08:13, Daniel Phillips wrote: > On Thursday 17 March 2005 22:51, Timothy Miller wrote: > > 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?
As long as the two ways don't cut into the hardware budget, why not have them? Nobody forces the driver to use both methods at the same time. > > 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. I'm not so sure about that. There may be cases where the *kernel* wants to move data around via the GPU. Think memory management, for example. Also, some existing DRM drivers use the GPU engine to display (primitive) debugging info. Forcing the kernel to create an indirect buffer and keep track of it, instead of just writing a few more dwords to the ring buffer sounds silly. > > 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. But having the same command set for both ring buffer and indirect DMA is both simpler and more flexible than arbitrarily splitting the command set. cu, Nicolai
pgp6n9H3n1cMF.pgp
Description: PGP signature
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
