All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcus Lorentzon <marcus.xm.lorentzon@stericsson.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Tom Cooksey <tom.cooksey@arm.com>,
	"patches@linaro.org" <patches@linaro.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	'Rob Clark' <rob.clark@linaro.org>,
	"linaro-mm-sig@lists.linaro.org" <linaro-mm-sig@lists.linaro.org>,
	"rschultz@google.com" <rschultz@google.com>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: Re: [Linaro-mm-sig] [PATCH] RFC: dma-buf: userspace mmap support
Date: Mon, 19 Mar 2012 18:10:48 +0100	[thread overview]
Message-ID: <4F676898.9010503@stericsson.com> (raw)
In-Reply-To: <20120319165644.3e4ce4ad@pyx>

On 03/19/2012 05:56 PM, Alan Cox wrote:
>> display controller will be reading the front buffer, but the GPU
>> >  might also need to read that front buffer. So perhaps adding
>> >  "read-only"&  "read-write" access flags to prepare could also be
>> >  interpreted as shared&  exclusive accesses, if we went down this
>> >  route for synchronization that is.:-)
> mmap includes read/write info so probably using that works out. It also
> means that you have the stuff mapped in a way that will bus error or
> segfault anyone who goofs rather than give them the usual 'deep
> weirdness' behaviour you get with mishandling of caching bits.
>
> Alan
mmap only give you this info at time of mmap call. prepare/finish would 
give you this info for each CPU access to the buffer (assuming mmap 
lasts multiple frames). Which means that you can optimize and have zero 
cache syncs for frames where CPU doesn't touch the buffer at all. If you 
use mmap info, then you would be forced to sync cache before each GPU 
access to the buffer. For example sub texture updates in glyph caches. 
They will only rarely change, so you don't want to sync CPU cache each 
time buffer is used in GPU, just because mmap says CPU has write access.

/Marcus

  reply	other threads:[~2012-03-19 17:10 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-15  1:32 [PATCH] RFC: dma-buf: userspace mmap support Rob Clark
2012-03-15  7:16 ` [Linaro-mm-sig] " Abhinav Kochhar
2012-03-15 12:27   ` Rob Clark
2012-03-15 20:30     ` Rebecca Schultz Zavin
2012-03-15 20:49     ` Rebecca Schultz Zavin
2012-03-16 10:50 ` Marcus Lorentzon
2012-03-16 14:19   ` Rob Clark
2012-03-16 14:19     ` Rob Clark
2012-03-16 17:24 ` Tom Cooksey
     [not found] ` <4f637907.8511440a.7941.ffff9067SMTPIN_ADDED@mx.google.com>
2012-03-16 18:55   ` Rob Clark
     [not found] ` <000001cd0399$9e57db90$db0792b0$@cooksey@arm.com>
2012-03-17 20:17   ` Alan Cox
2012-03-17 20:17     ` Alan Cox
2012-03-17 22:12     ` Rob Clark
2012-03-19 16:42     ` Tom Cooksey
     [not found]     ` <000101cd05ef$3eab78c0$bc026a40$@cooksey@arm.com>
2012-03-19 16:56       ` Alan Cox
2012-03-19 16:56         ` Alan Cox
2012-03-19 17:10         ` Marcus Lorentzon [this message]
2012-03-19 18:44         ` Tom Cooksey

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=4F676898.9010503@stericsson.com \
    --to=marcus.xm.lorentzon@stericsson.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-media@vger.kernel.org \
    --cc=patches@linaro.org \
    --cc=rob.clark@linaro.org \
    --cc=rschultz@google.com \
    --cc=tom.cooksey@arm.com \
    /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.