From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 1/6] RFCish: write only mappings (aka non-blocking) Date: Wed, 21 Sep 2011 09:07:03 +0200 Message-ID: <20110921070703.GB2822@phenom.ffwll.local> References: <1316492706-31081-1-git-send-email-ben@bwidawsk.net> <20110920151953.03e57954@bwidawsk.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-wy0-f181.google.com (mail-wy0-f181.google.com [74.125.82.181]) by gabe.freedesktop.org (Postfix) with ESMTP id 1D4A79E86C for ; Wed, 21 Sep 2011 00:06:32 -0700 (PDT) Received: by wyf19 with SMTP id 19so1665858wyf.26 for ; Wed, 21 Sep 2011 00:06:32 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20110920151953.03e57954@bwidawsk.net> 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: Ben Widawsky Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Tue, Sep 20, 2011 at 03:19:53PM -0700, Ben Widawsky wrote: > On Tue, 20 Sep 2011 13:06:43 +0200 > Daniel Vetter wrote: > > - I'm sorry having suggested to implement the clflush ioctl, I think > > it's a foolish idea, now. Non-blocking mmaps is a performance > > optimization, needing to sync caches with clflush is very much the > > opposite. So I think we can dustbin this. > > I disagree. I think it's nice function to add for people too lazy to do > micro-optimizations. The flushing of the full object is almost > guaranteed to make performance worse though, that should really only be > for testing purposes. Let me whip up a simple patch for libdrm to show why I think we don't need this. > > 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. > > I'd need to research this a bit more, let me defer response on this > part. By the way, which set_cache_level ioctl are you referring to? The set_cache_level ioctl that doesn't exist yet ;-) Essentially something to set/get obj->cache_level, so that Chris can use snoopable bos on !llc machines. But as I've said, that's probably something for the extend non-blocking mmap support and not something we need right away. Cheers, Daniel -- Daniel Vetter Mail: daniel@ffwll.ch Mobile: +41 (0)79 365 57 48