[Mesa-dev] [PATCH] anv: Stall before fast-clear operations

[Pohjolainen, Topi]

On Fri, Mar 10, 2017 at 11:04:41PM -0800, Jason Ekstrand wrote:
> During initial CCS bring-up, I discovered that you have to do a full CS
> stall prior to doing a CCS resolve as well as afterwards.  It appears
> that the same is needed for fast-clears as well.  This fixes rendering
> corruptions on The Talos Principal on Sky Lake GT4.  The issue hasn't
> been demonstrated on any other hardware however, given that this appears
> to be a "too many things in the pipe" problem, having it be easier to
> reproduce on a system with more EUs makes sense.  The issues with
> resolves is demonstrable on a GT3 or GT2 so this is probably also a
> problem on all GTs.
> 
> Cc: "13.0 17.0" <mesa-stable at lists.freedesktop.org>
> ---
>  src/intel/vulkan/anv_blorp.c | 25 +++++++++++++++++++------
>  1 file changed, 19 insertions(+), 6 deletions(-)
> 
> diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
> index 049b38d..41966d6 100644
> --- a/src/intel/vulkan/anv_blorp.c
> +++ b/src/intel/vulkan/anv_blorp.c
> @@ -1132,6 +1132,25 @@ anv_cmd_buffer_clear_subpass(struct anv_cmd_buffer *cmd_buffer)
>        if (att_state->fast_clear) {
>           surf.clear_color = vk_to_isl_color(att_state->clear_value.color);
>  
> +         /* From the Sky Lake PRM Vol. 7, "Render Target Fast Clear":
> +          *
> +          *    "After Render target fast clear, pipe-control with color cache
> +          *    write-flush must be issued before sending any DRAW commands on
> +          *    that render target."
> +          *
> +          * This comment is a bit cryptic and doesn't really tell you what's
> +          * going or what's really needed.  It appears that fast clear ops are
> +          * not properly synchronized with other drawing.  This means that we
> +          * cannot have a fast clear operation in the pipe at the same time as
> +          * other regular drawing operations.  We need to use a PIPE_CONTROL
> +          * to ensure that the contents of the previous draw hit the render
> +          * target before we resolve and then use a second PIPE_CONTROL after
> +          * the resolve to ensure that it is completed before any additional
> +          * drawing occurs.

Yeah, I think we are still a little in the dark what hardware real does and
needs. There are those bits in the spec discussing the need of end-of-pipe sync
after resolves.

Anyway, what you have here is in line with the current logic we have in i965:

Reviewed-by: Topi Pohjolainen <topi.pohjolainen at intel.com>

> +          */
> +         cmd_buffer->state.pending_pipe_bits |=
> +            ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT | ANV_PIPE_CS_STALL_BIT;
> +
>           blorp_fast_clear(&batch, &surf, iview->isl.format,
>                            iview->isl.base_level,
>                            iview->isl.base_array_layer, fb->layers,
> @@ -1139,12 +1158,6 @@ anv_cmd_buffer_clear_subpass(struct anv_cmd_buffer *cmd_buffer)
>                            render_area.offset.x + render_area.extent.width,
>                            render_area.offset.y + render_area.extent.height);
>  
> -         /* From the Sky Lake PRM Vol. 7, "Render Target Fast Clear":
> -          *
> -          *    "After Render target fast clear, pipe-control with color cache
> -          *    write-flush must be issued before sending any DRAW commands on
> -          *    that render target."
> -          */
>           cmd_buffer->state.pending_pipe_bits |=
>              ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT | ANV_PIPE_CS_STALL_BIT;
>        } else {
> -- 
> 2.5.0.400.gff86faf
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev