From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Widawsky Subject: Re: [Intel-gfx] [PATCH] i965: use nonblocking maps MapRangeBuffer Date: Fri, 23 Sep 2011 11:56:59 -0700 Message-ID: <20110923115659.2aa3feae@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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20110923114641.3ba6c361@bwidawsk.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mesa-dev-bounces+gcvmd-mesa3d-493=gmane.org@lists.freedesktop.org Errors-To: mesa-dev-bounces+gcvmd-mesa3d-493=gmane.org@lists.freedesktop.org To: Ben Widawsky Cc: intel-gfx@lists.freedesktop.org, Mesa Devs , Daniel Vetter List-Id: intel-gfx@lists.freedesktop.org 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