On Monday 28 February 2005 16:39, Rodolphe Ortalo wrote: > On Monday 28 February 2005 06:24, Daniel Phillips wrote: > [...] > > > I do not recall that there was any compelling argument raised to > > prove that more than one process (the X server) needs to issue > > commands directly to the card. > > [...] > > s/X server/linux kernel/ > > IMNSHO
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. 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. For anybody who hasn't feasted their eyes on it yet, the overall structure of DRI is described here: http://dri.sourceforge.net/doc/DRIintro.html The DRM is described here: http://dri.sourceforge.net/doc/drm_low_level.html 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)
