From mboxrd@z Thu Jan  1 00:00:00 1970
From: Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [PATCH 1/6] RFCish: write only mappings (aka
 non-blocking)
Date: Wed, 21 Sep 2011 09:02:24 +0200
Message-ID: <20110921070151.GA2822@phenom.ffwll.local>
References: <1316492706-31081-1-git-send-email-ben@bwidawsk.net>
	<CAKMK7uEwdmydNPc42GoD0-GbEGuTv3iGva5ghAHHfDO_2tRt2g@mail.gmail.com>
	<e0d58a$1gf87i@orsmga002.jf.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org>
Received: from mail-wy0-f181.google.com (mail-wy0-f181.google.com
	[74.125.82.181])
	by gabe.freedesktop.org (Postfix) with ESMTP id 5076D9E86C
	for <intel-gfx@lists.freedesktop.org>;
	Wed, 21 Sep 2011 00:01:57 -0700 (PDT)
Received: by wyf19 with SMTP id 19so1659695wyf.26
	for <intel-gfx@lists.freedesktop.org>;
	Wed, 21 Sep 2011 00:01:56 -0700 (PDT)
Content-Disposition: inline
In-Reply-To: <e0d58a$1gf87i@orsmga002.jf.intel.com>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=subscribe>
Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org
Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Widawsky <ben@bwidawsk.net>, intel-gfx@lists.freedesktop.org
List-Id: intel-gfx@lists.freedesktop.org

On Tue, Sep 20, 2011 at 10:16:39PM +0100, Chris Wilson wrote:
> On Tue, 20 Sep 2011 13:06:43 +0200, Daniel Vetter <daniel@ffwll.ch> wrote:
> >   Now non-blocking cpu mmaps make very much sense on llc/snooped buffer
> >   objects. So I think we actually need an ioctl to get obj->cache_level so
> >   userspace can decide whether it should use non-blocking gtt mmaps or cpu
> >   (non-blocking) cpu mmaps. We might as well go full-circle, make Chris
> >   happy and merge the corresponding set_cache_level ioclt to enable
> >   snooped buffers on machines with ilk-like coherency (i.e. that atom
> >   thing I'm hearing about ...). But imo that's material for non-blocking
> >   mmaps, step 2.
> 
> That's not enough to make me completely happy. I also have the use-case
> of wanting to efficiently handle compositing with client allocated
> memory i.e. persistent ShmPixmaps, where coherency either needs to be
> transparent to the client or (worse) synchronicity imposed by the server.

I know, just snoopable bo support only makes you half-happy and you need
fancy stuff in addition ;-) But if your sna branch can halfway easily
profit from simle snoopable bo support on !llc machines, I think that'll
give us an easy way to check api sanity for the new ioctl.
-Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48