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

[Ben Widawsky <ben@bwidawsk.net>]

On Fri, 23 Sep 2011 11:46:41 -0700
Ben Widawsky <ben@bwidawsk.net> wrote:

> On Fri, 23 Sep 2011 10:15:02 -0700
> Eric Anholt <eric@anholt.net> wrote:
> 
> > On Thu, 22 Sep 2011 16:27:12 -0700, Ben Widawsky <ben@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@anholt.net>
> > > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > Cc: Mesa Devs <mesa-dev@lists.freedesktop.org>
> > > Signed-off-by: Ben Widawsky <ben@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