about mmap dma-buf and sync

[Rob Clark]

On Thu, Aug 20, 2015 at 2:48 AM, Thomas Hellstrom <thellstrom at vmware.com> wrote:
> 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.

just curious, but couldn't you batch up the 10 10x1 sync's?

BR,
-R

>
> 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel