On Tuesday 01 March 2005 14:17, Daniel Phillips wrote: [...] > Well, to be precise, multiple processes will issue commands via two > modules: the X server's 2D DDX driver and libGL's 3D DRI driver. Both > will want to place commands into a DMA buffer and hand them off to the > card. The normal way is via an ioctl to the DRM, which pokes the DMA > registers. But I think we have in mind to avoid ioctls if we can, so > we would like to map a mmio register instead, which sets the tail of > the ring buffer. I'm not completely clear on the details of how this > would work. One big question is how the buffer low/empty interrupt > would be fielded.
mmio a single register to userspace? > 2D commands will be issued with the X server's privilege, that is, root. > 3D commands can be issued by any process, normally with no special > privilege. We can't allow user processes to submit DMA commands > directly to the command buffer for three reasons: 1) the user process > doesn't know the physical address to DMA from/to; 2) the region hasn't > necessarily been locked into memory; and 3) there is no way to be sure > that the process is allowed to access that memory. So, sigh, it is > back to submitting texture loads and bitblt commands through kernel > ioctls. Not only that, but we need to be able to enforce an ordering > on these DRM-handled DMA transfers and other commands. So it is back > to handing all our command buffers to the kernel via IOCTLs. > > Because of this, I'm almost convinced that indirect DMA needs to be > supported just the way Timothy described it, because that fits well > with the the DRM and will probably work for any any OS. But if there > is some way around the problems with submitting DMA commands directly > from unprivileged processes, we might end up sending all commands > through the main ring buffer and not using the indirect command feature > at all. I agree with using indirect DMA to try to send commands directly (ie: without copying buffers). But I also think that problems 1), 2) and 3) should be hidden by the kernel as much as possible so that the userspace application can work with its display lists/command buffers most conveniently. (IMO, the most important difficulty is to encompass virtual addressing transparently and totally and if possible efficiently [without parsing the whole command buffer].) On occasion, I'll go back to DRM/DRI design documents; but I guess these are the same as the original ones (~2000)? Rodolphe _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
