From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Widawsky Subject: Re: [PATCH] i965: use nonblocking maps MapRangeBuffer Date: Fri, 23 Sep 2011 12:21:43 -0700 Message-ID: <20110923122143.4248cba1@bwidawsk.net> References: <1316734033-17228-1-git-send-email-ben@bwidawsk.net> <1316734033-17228-4-git-send-email-ben@bwidawsk.net> <87hb43tc2x.fsf@eliezer.anholt.net> <20110923114641.3ba6c361@bwidawsk.net> <20110923115659.2aa3feae@bwidawsk.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20110923115659.2aa3feae@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: Mesa Devs , intel-gfx@lists.freedesktop.org, Daniel Vetter List-Id: intel-gfx@lists.freedesktop.org On Fri, 23 Sep 2011 11:56:59 -0700 Ben Widawsky wrote: > On Fri, 23 Sep 2011 11:46:41 -0700 > Ben Widawsky wrote: > > > On Fri, 23 Sep 2011 10:15:02 -0700 > > Eric Anholt wrote: > > > > > On Thu, 22 Sep 2011 16:27:12 -0700, Ben Widawsky > > > wrote: > > > > This makes the code a lot cleaner, and theoretically faster (not > > > > many real world tests use this GL extension). > > > > > > > > Cc: Eric Anholt > > > > Cc: Daniel Vetter > > > > Cc: Mesa Devs > > > > Signed-off-by: Ben Widawsky > > > > --- > > > > src/mesa/drivers/dri/intel/intel_buffer_objects.c | 48 > > > > ++------------------ 1 files changed, 5 insertions(+), 43 > > > > deletions(-) > > > > > > > > diff --git a/src/mesa/drivers/dri/intel/intel_buffer_objects.c > > > > b/src/mesa/drivers/dri/intel/intel_buffer_objects.c index > > > > d35a50e..91dddce 100644 --- > > > > a/src/mesa/drivers/dri/intel/intel_buffer_objects.c +++ > > > > b/src/mesa/drivers/dri/intel/intel_buffer_objects.c @@ -296,8 > > > > +296,6 @@ intel_bufferobj_get_subdata(struct gl_context * ctx, } > > > > } > > > > > > > > - > > > > - > > > > /** > > > > * Called via glMapBufferRange and glMapBuffer > > > > * > > > > @@ -363,50 +361,14 @@ intel_bufferobj_map_range(struct > > > > gl_context > > > > * ctx, return NULL; > > > > } > > > > > > > > - /* If the user doesn't care about existing buffer contents > > > > and mapping > > > > - * would cause us to block, then throw out the old buffer. > > > > - */ > > > > - if (!(access & GL_MAP_UNSYNCHRONIZED_BIT) && > > > > - (access & GL_MAP_INVALIDATE_BUFFER_BIT) && > > > > - drm_intel_bo_busy(intel_obj->buffer)) { > > > > - drm_intel_bo_unreference(intel_obj->buffer); > > > > - intel_bufferobj_alloc_buffer(intel, intel_obj); > > > > - } > > > > > > Why did you delete this code? Applications rely on this > > > happening. > > > > Maybe I got confused by the order of operations, but I thought this > > should be, > > If synchronized and invalidate and busy, just create a new buffer. > > This *should* be handled correctly by the nonblocking call below. > > Maybe I'm mistaken. > > Sorry, want to clarify this some more: > > So we no longer ever create a new buffer to try to speed things up. I > was hoping the nonblocking stuff would fix this. Actually this patch > was sort of my attempt to remove as much as possible and see what > you'd say. If you already know which cases REALLY need the new > buffeobj, I'll add those back. > > Ben Forget this, let me resubmit.