On Fri, 23 Sep 2011 11:56:59 -0700
Ben Widawsky <b...@bwidawsk.net> wrote:
> On Fri, 23 Sep 2011 11:46:41 -0700
> Ben Widawsky <b...@bwidawsk.net> wrote:
>
> > On Fri, 23 Sep 2011 10:15:02 -0700
> > Eric Anholt <e...@anholt.net> wrote:
> >
> > > On Thu, 22 Sep 2011 16:27:12 -0700, Ben Widawsky
> > > <b...@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 <e...@anholt.net>
> > > > Cc: Daniel Vetter <daniel.vet...@ffwll.ch>
> > > > Cc: Mesa Devs <mesa-dev@lists.freedesktop.org>
> > > > Signed-off-by: Ben Widawsky <b...@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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
