On 11/01/2013 11:17 AM, Daniel Vetter wrote:
On Fri, Nov 1, 2013 at 11:03 AM, Lucas Stach <l.stach@xxxxxxxxxxxxxx> 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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
