From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: [PATCH 1/6] RFCish: write only mappings (aka non-blocking) Date: Tue, 20 Sep 2011 22:16:39 +0100 Message-ID: References: <1316492706-31081-1-git-send-email-ben@bwidawsk.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTP id 4D4419E8C4 for ; Tue, 20 Sep 2011 14:16:53 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: Daniel Vetter , Ben Widawsky Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Tue, 20 Sep 2011 13:06:43 +0200, Daniel Vetter 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. -Chris -- Chris Wilson, Intel Open Source Technology Centre