[Mesa-dev] [PATCH 4/4] i965: Suppress re-flagging of BRW_NEW_UNIFORM_BUFFER while emitting UBO state.

[Chris Forbes]

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 <chrisf at 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 <chrisf at 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
>