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-sta...@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.pohjolai...@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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
