One further note: It's possible to provoke the same bad behavior in the equivalent ABO path, by declaring an atomic counter but never binding any buffer object to the binding point, so this isn't a real fix.
-- Chris On Tue, Sep 23, 2014 at 10:16 PM, Chris Forbes <chr...@ijw.co.nz> wrote: > This shouldn't actually happen in a sensible app (the easiest way to > force it is to use a UBO in a shader without binding anything to the > binding point). When it *does* happen though, it makes a loop in the > dirty state, which causes an assertion failure in the state validator if > any debug flag is enabled. > > [This is almost certainly not the right way to fix it, but maybe the > patch will get a discussion going about excessive flagging...] > > Signed-off-by: Chris Forbes <chr...@ijw.co.nz> > --- > src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c > b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c > index 5f75c31..d583729 100644 > --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c > +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c > @@ -857,6 +857,13 @@ brw_upload_ubo_surfaces(struct brw_context *brw, > intel_bufferobj_buffer(brw, intel_bo, > binding->Offset, > binding->BufferObject->Size - > binding->Offset); > + /* It's possible that intel_bufferobj_buffer ended up setting > + * BRW_NEW_UNIFORM_BUFFER here. Unflag it again, since this atom > + * is run in response to that flag, and this upsets the state atom > + * validator. > + */ > + brw->state.dirty.brw &= ~BRW_NEW_UNIFORM_BUFFER; > + > > /* Because behavior for referencing outside of the binding's size in > the > * glBindBufferRange case is undefined, we can just bind the whole > buffer > -- > 2.1.0 > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
