On 11/01/2013 11:17 AM, Daniel Vetter wrote: > On Fri, Nov 1, 2013 at 11:03 AM, Lucas Stach <l.stach at pengutronix.de> > wrote: >> GStreamer needs _some_ way of accessing the buffer contents with the >> CPU, this doesn't necessarily have to be the dumb mmap we have right >> now. >> DMA-BUF support in GSt is not really finished (I know we have a lot of >> patches internally to make it actually work with anything, which are >> trickling upstream right now), so this might be a good time to hammer >> out how it should be done, so we can adapt GSt before people start to >> rely on the dma-buf fallback mmap. >> >> I would think the bracketed mmap idea that was thrown around by Rob some >> time ago when the mmap topic first surfaced is simple enough that we >> don't need additional userspace helpers and should be enough to make the >> coherency issue disappear. > Yeah, if we add a BEGIN_MMAP/END_MMAP ioctl or so to the dma-buf mmap > stuff and simply demand that userspace calls that we'd have something > half-sane at least. Since we currently don't really have any real > users we could still do this abi change I think. > > One open issue is whether the BEGIN_MMAP ioctl should also synchronize > with any outstanding gpu access. Imo it should, since that's pretty > much how all the current drm drivers work, but maybe we should reserve > space for a few flags so that this can be extended later on - Android > seems to be pretty insistent on using explicit syncpoints everywhere > instead of implicit synchronization. Or maybe we should have the flag > already, but reject implicit syncing until Maarten's dma_fence stuff > is in and enabled, dunno. Adding him to cc. > > The clear thing otoh is that these two ioctls should only serve as > barriers, not as locks as has been proposed in some other RFCs > floating around (iirc the one from exynos was borked in this fashion). > -Daniel I think one of the worst use-cases we could imagine would be a client doing something like the old kde screen saver that drew hundreds of thousands of small squares and in addition would flush for each square. Here begin/mmap end/mmap would not suffice, and _mandatory_ syncing would also be a bad idea.
We'd need to have a region supplied. Something like gallium texture transfers would work reasonably well, but they allow direct mappings of the underlying surface / buffer, which means that a lazy client might allocate texture transfers covering the whole buffer if coherent drivers made that a reasonably fast operation. access using something like texsubimage (or region-type pwrites / preads) would at least involve a memcpy / kernel copy and would have the client think twice before accessing the dma-buf in this way, but I understand that this might sound frustrating for writers of coherent drivers. (I would have opposed it :)) But I'd like to stress that a single BEGIN_MMAP / END_MMAP wouldn't help us much, and that we need a read/ write/bidirectional indication. Thanks, /Thomas
