Re: dma-buf non-coherent mmap

[Thomas Hellstrom <thellstrom@vmware.com>]

On 11/01/2013 11:17 AM, Daniel Vetter wrote:
> On Fri, Nov 1, 2013 at 11:03 AM, Lucas Stach <l.stach@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