From: Thomas Hellstrom <thomas@shipmail.org>
To: dri-devel@lists.freedesktop.org
Subject: Re: about mmap dma-buf and sync
Date: Thu, 20 Aug 2015 21:27:08 +0200 [thread overview]
Message-ID: <55D62A0C.10202@shipmail.org> (raw)
In-Reply-To: <CAF6AEGv1HxUEW0naZ0W=fsUkfRAuErekczXOV-ra9WP1+Q6DWg@mail.gmail.com>
On 08/20/2015 04:33 PM, Rob Clark wrote:
> On Thu, Aug 20, 2015 at 2:48 AM, Thomas Hellstrom <thellstrom@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?
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.
/Thomas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2015-08-20 19:27 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <55D50442.5080102@intel.com>
2015-08-20 6:48 ` about mmap dma-buf and sync Thomas Hellstrom
2015-08-20 14:33 ` Rob Clark
2015-08-20 19:27 ` Thomas Hellstrom [this message]
2015-08-20 19:32 ` Thomas Hellstrom
2015-08-21 16:42 ` Rob Clark
2015-08-20 14:53 ` Jerome Glisse
2015-08-20 19:39 ` Thomas Hellstrom
2015-08-20 20:34 ` Jerome Glisse
2015-08-21 5:25 ` Thomas Hellstrom
2015-08-21 10:28 ` Lucas Stach
2015-08-21 10:51 ` Thomas Hellstrom
2015-08-21 13:32 ` Jerome Glisse
2015-08-21 14:15 ` Thomas Hellstrom
2015-08-21 16:00 ` Jerome Glisse
2015-08-21 22:00 ` Thomas Hellstrom
2015-08-24 1:41 ` Jerome Glisse
2015-08-24 9:59 ` Thomas Hellstrom
2015-08-21 23:06 ` Tiago Vignatti
2015-08-24 9:50 ` Thomas Hellstrom
2015-08-24 15:52 ` Daniel Stone
2015-08-24 16:56 ` Thomas Hellstrom
2015-08-24 17:04 ` Daniel Stone
2015-08-24 17:10 ` Thomas Hellstrom
2015-08-24 17:12 ` Daniel Stone
2015-08-24 17:42 ` Thomas Hellstrom
2015-08-24 17:56 ` Michael Spang
2015-08-25 5:25 ` Thomas Hellstrom
2015-08-24 18:01 ` Tiago Vignatti
2015-08-24 23:03 ` Tiago Vignatti
2015-08-25 9:02 ` Daniel Vetter
2015-08-25 9:30 ` Thomas Hellstrom
2015-08-25 16:14 ` Tiago Vignatti
2015-08-26 0:02 ` [PATCH v4] dma-buf: Add ioctls to allow userspace to flush Tiago Vignatti
2015-08-26 6:49 ` Thomas Hellstrom
2015-08-26 12:10 ` Daniel Vetter
2015-08-26 12:28 ` Thomas Hellstrom
2015-08-26 12:58 ` Daniel Vetter
2015-08-26 14:32 ` Tiago Vignatti
2015-08-26 14:50 ` Thomas Hellstrom
2015-08-26 14:51 ` Daniel Vetter
2015-08-26 14:58 ` Tiago Vignatti
2015-08-26 15:37 ` Thomas Hellstrom
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55D62A0C.10202@shipmail.org \
--to=thomas@shipmail.org \
--cc=dri-devel@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.