[Intel-gfx] [PATCH] i965: use nonblocking maps MapRangeBuffer

[Ben Widawsky]

On Fri, 23 Sep 2011 11:56:59 -0700
Ben Widawsky <ben at bwidawsk.net> wrote:

> On Fri, 23 Sep 2011 11:46:41 -0700
> Ben Widawsky <ben at bwidawsk.net> wrote:
> 
> > On Fri, 23 Sep 2011 10:15:02 -0700
> > Eric Anholt <eric at anholt.net> wrote:
> > 
> > > On Thu, 22 Sep 2011 16:27:12 -0700, Ben Widawsky
> > > <ben at bwidawsk.net> wrote:
> > > > This makes the code a lot cleaner, and theoretically faster (not
> > > > many real world tests use this GL extension).
> > > > 
> > > > Cc: Eric Anholt <eric at anholt.net>
> > > > Cc: Daniel Vetter <daniel.vetter at ffwll.ch>
> > > > Cc: Mesa Devs <mesa-dev at lists.freedesktop.org>
> > > > Signed-off-by: Ben Widawsky <ben at bwidawsk.net>
> > > > ---
> > > >  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.