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
