On Tuesday 15 March 2005 20:15, Daniel Phillips wrote: > The Vepstas proposal is overkill, which is proved by example as you say. > > There is certain functionality that is essential though. I'm working > myself up to submit what I hope is a comprehensive proposal on security > and the DMA/interrupt model. Security and DMA are inseparable if we > want unprivileged tasks to be able to submit command lists. > > The problem is easy if we: a) require unprivileged tasks to submit > commands via a software interface that translates them to hardware > commands, or b) parse each command list before submitting it. But in > the interest of efficiency, I think we should at least try to come up > with a model that avoids these bottlenecks. > > I think the following rules cover what we really need: > > * Only privileged tasks (or kernel) can directly initiate DMA, an > unprivileged task must go through DRI. This is enforced by > only allowing an unprivileged task to submit indirect DMA. (DMA > obviously can't be initiated from an indirect DMA command list.) > Direct DMA, i.e., the command ringbuffer, may only be submitted > by DRM/DRI. > > * Only privileged tasks can directly define or position the hardware > cursor. > > * An unprivileged task cannot draw outside its own window, which is > enforced by the ownership test in cooperation with the X server
Amen to that. > * All drawing commands are submitted as DMA commands, PIO is used > only for DMA setup, soft reset, interrupt control and similar. PIO > is only available to privileged tasks. (Timothy stated earlier that > defining the hardware cursor should be done by PIO, though I don't > really understand why that is better than submitting it through the > ring buffer) I agree. I don't know Timothy's precise reasoning, but I could imagine that using PIO for the cursor is better for latency. > Did I leave any holes? If we enforce window boundaries (which is btw not enforced by any graphics driver on Linux that I know of), we would also have to think about how mmap()'ing the framebuffer could (or couldn't) work. > In the "future" category, I think we need to plan now how asynchronous > background DMA will work, even if it isn't implemented in the initial > release. This capability really isn't optional. We just can't afford > to have all drawing grind to a halt every time a texture loads. Basically, I agree. On the other hand, there may be limitations on the memory controller (especially in the first release) that make background uploads unfeasible. Considering that this card will have a *huge* amount of RAM compared to its rendering performance, my educated guess is that texture uploads won't be a limiting factor for 3D. Things may be different for video playback, though... > I'd have already posted a full proposal, except that I don't yet have a > clear picture of how buffer low/empty events will be fielded by normal > tasks. This requires delving into the innards of DRM and other things, > deeper than I've had time for so far. If anybody has already looked at > this, please shout. The current DRMs actually seem dumb. The DRM only enters commands into the ring buffer as a response to ioctls from userspace, and if the buffer is full, it will busy-wait for space to become available. I haven't checked all drivers out there, but all that I've looked at so far work like this. cu, Nicolai > Regards, > > Daniel
pgpu2e4AEbRcw.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)
