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

[Ben Widawsky]

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