Re: about mmap dma-buf and sync

[Thomas Hellstrom <thellstrom@vmware.com>]

Hi, Tiago!

On 08/20/2015 12:33 AM, Tiago Vignatti wrote:
> Hey Thomas, you haven't answered my email about making SYNC_* mandatory:
>
> http://lists.freedesktop.org/archives/dri-devel/2015-August/088376.html

Hmm, for some reason it doesn't show up in my mail app, but I found it
in the archives. An attempt to explain the situation from the vmwgfx
perspective.

The fact that the interface is generic means that people will start
using it for the zero-copy case. There has been a couple of more or less
hackish attempts to do this before, and if it's a _driver_ interface we
don't need to be that careful but if it is a _generic_ interface we need
to be very careful to make it fit *all* the hardware out there and that
we make all potential users use the interface in a way that conforms
with the interface specification.

What will happen otherwise is that apps written for coherent fast
hardware might, for example, ignore calling the SYNC api, just because
the app writer only cared about his own hardware on which the app works
fine. That would fail miserably if the same app was run on incoherent
hardware, or the incoherent hardware driver maintainers would be forced
to base an implementation on page-faults which would be very slow.

So assume the following use case: An app updates a 10x10 area using the
CPU on a 1600x1200 dma-buf, and it will then use the dma-buf for
texturing. On some hardware the dma-buf might be tiled in a very
specific way, on vmwgfx the dma-buf is a GPU buffer on the host, only
accessible using DMA. On vmwgfx the SYNC operation must carry out a
10x10 DMA from the host GPU buffer to a guest CPU buffer before the CPU
write and a DMA back again after the write, before GPU usage. On the
tiled architecture the SYNC operation must untile before CPU access and
probably tile again before GPU access.

If we now have a one-dimensional SYNC api, in this particular case we'd
either need to sync a far too large area (1600x10) or call SYNC 10 times
before writing, and then again after writing. If the app forgot to call
SYNC we must error.

So to summarize, the fact that the interface is generic IMO means:

1) Any user must be able to make valid assumptions about the internal
format of the dma-buf. (untiled, color format, stride etc.)
2) Any user *must* call SYNC before and after CPU access. On coherent
architectures, the SYNC is a NULL operation anyway, and that should be
documented somewhere so that maintainers of drivers of uncoherent
architectures have somewhere to point their fingers.
3) Driver-specific implementations must be allowed to error (segfault)
if SYNC has not been used.
4) The use-case stated above clearly shows the benefit of a
2-dimensional sync interface (we want to sync the 10x10 region), but
what if someone in the future wants to use this interface for a 3D
texture? Will a 2D sync suffice? Can we make the SYNC interface
extendable in a way that an enum sync_type member defines the layout of
the argument, and initially we implement only 1d, 2d sync, leaving 3d
for the future?

Also, I agree there is probably no good way to generically implement an
error if SYNC has not been called. That needs to be left as an option to
drivers.

Thanks,
Thomas


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel