about mmap dma-buf and sync
robdclark at gmail.com
Fri Aug 21 09:42:56 PDT 2015
On Thu, Aug 20, 2015 at 3:27 PM, Thomas Hellstrom <thomas at shipmail.org> wrote:
> On 08/20/2015 04:33 PM, Rob Clark wrote:
>> 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:
>>> 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
>>> 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?
> Yes that would work up to the first CPU access. Subsequent syncs would
> need to be carried out immediately or all ptes would need to be unmapped
> to detect the next CPU access. Write only syncs could probably be
> batched unconditionally.
hmm, maybe another cpu barrier ioctl?
I mean if we had a 2d sync API, then needed to update layers in a 3d
or cubemap texture, then you need to do multiple 2d updates..
but what about instead having something like:
... cpu access
(or something roughly like that)
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
More information about the dri-devel