From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [Intel-gfx] [PATCH] drm/i915: Unconditionally flush writes before execbuffer Date: Thu, 21 May 2015 17:30:32 +0200 Message-ID: <20150521153032.GI15256@phenom.ffwll.local> References: <1431330696-15379-1-git-send-email-chris@chris-wilson.co.uk> <20150511103437.GA15256@phenom.ffwll.local> <20150511152552.GD19022@nuc-i3427.alporthouse.com> <20150519144148.GA13637@nuc-i3427.alporthouse.com> <20150521130034.GN17761@nuc-i3427.alporthouse.com> <20150521130754.GD15256@phenom.ffwll.local> <20150521131301.GQ17761@nuc-i3427.alporthouse.com> <20150521142146.GF15256@phenom.ffwll.local> <20150521152255.GS17761@nuc-i3427.alporthouse.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20150521152255.GS17761@nuc-i3427.alporthouse.com> Sender: stable-owner@vger.kernel.org To: Chris Wilson , Daniel Vetter , intel-gfx@lists.freedesktop.org, Akash Goel , stable@vger.kernel.org Cc: Jani Nikula List-Id: intel-gfx@lists.freedesktop.org On Thu, May 21, 2015 at 04:22:55PM +0100, Chris Wilson wrote: > On Thu, May 21, 2015 at 04:21:46PM +0200, Daniel Vetter wrote: > > Hm right. What about emphasising this a bit more in the comment: > > > > /* > > * Empirical evidence indicates that we need a write barrier to > > * make sure write-combined writes (both to the gtt, but also to > > * the cpu mmaps). But userspace also uses wc mmaps as > > * unsynchronized upload paths where it inform the kernel about > > * domain changes (to avoid the stalls). Hence we must do this > > * barrier unconditinally. > > */ > > For reference the wording in the commit is: > > /* Unconditionally flush out writes to memory as the user may be > * doing asynchronous streaming writes to active buffers (i.e. > * lazy domain management to avoid serialisation) directly into > * the physical pages and so not naturally serialised by the GTT. > */ > > > Mostly just rewording, unsing unsynchronized as used by gl/libdrm and > > clarification why we need to have the barrier unconditionally. With that > > Hmm, glMapBufferRange does use unsynchronized, but async is almost > universally preferred when talking about io and runqueues. > > /* Unconditionally flush out writes to memory as the user may be > * doing asynchronous streaming writes to active buffers in this > * batch (i.e. lazy domain management to avoid serialisation, for > * example with glMapBufferRange(GL_MAP_UNSYNCHRONIZED_BIT)) directly > * into the physical pages and so not naturally serialised by the GTT. > */ > > > Reviewed-by: Daniel Vetter Yeah, r-b: me also with this one. Jani, can you please exchange the comment and apply to -fixes? -Daniel > > > > And I guess also > > > > Cc: stable@vger.kernel.org > > It already was ;-) > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch