[Mesa-dev] [RFC v2] etnaviv: flush color cache and depth cache together before resolves

[Lucas Stach]

Am Freitag, den 23.06.2017, 11:17 +0200 schrieb Philipp Zabel:
> Before resolving a rendertarget or a depth/stencil resource into a
> texture, flush both the color cache and the depth cache together.
> 
> It is unclear whether this is necessary for the following stall to
> work properly, or whether the depth flush just adds enough time
> for the color cache flush to finish before the resolver is started,
> but this change removes artifacts that otherwise appear if a texture
> is sampled directly after rendering into it.
> 
> The test case is a simple QML scene graph with a QtWebEngine based
> WebView rendered on top of a blue background:
> 
> 	import QtQuick 2.0
> 	import QtQuick.Window 2.2
> 	import QtWebView 1.1
> 
> 	Window {
> 		Rectangle {
> 			id: background
> 			anchors.fill: parent
> 			color: "blue"
> 		}
> 
> 		WebView {
> 			id: webView
> 			anchors.fill: parent
> 		}
> 
> 		Component.onCompleted: {
> 			webView.url = "<some animated website>"
> 		}
> 	}
> 
> If the website is animated, the WebView renders the site contents into
> texture tiles and immediately afterwards samples from them to draw the
> tiles into the Qt renderbuffer. Without this patch, a small irregular
> triangle in the lower right of each browser tile appears solid blue, as
> if the texture sampler samples zeroes instead of the website contents,
> and the previously rendered blue Rectangle shows through.
> 
> Other attempts such as adding a pipeline stall before the color flush or
> a TS cache flush afterwards or flushing multiple times, with stalls
> before and after each flush, have shown no effect.
> 
> Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
> ---
> Changes since v1:
>  - Add a comment explaining why we flush color and depth cache together.

If there are no objections, I'm going to push this change before the
17.2 branchpoint, as it fixes a real bug, even though we don't fully
understand why this is needed.

Regards,
Lucas
> ---
>  src/gallium/drivers/etnaviv/etnaviv_clear_blit.c | 22 +++++++++++++---------
>  1 file changed, 13 insertions(+), 9 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c b/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
> index e4620a3015..d9538907fe 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
> @@ -465,15 +465,19 @@ etna_try_rs_blit(struct pipe_context *pctx,
>        ts_mem_config |= VIVS_TS_MEM_CONFIG_MSAA | msaa_format;
>     }
>  
> -   uint32_t to_flush = 0;
> -
> -   if (src->base.bind & PIPE_BIND_RENDER_TARGET)
> -      to_flush |= VIVS_GL_FLUSH_CACHE_COLOR;
> -   if (src->base.bind & PIPE_BIND_DEPTH_STENCIL)
> -      to_flush |= VIVS_GL_FLUSH_CACHE_DEPTH;
> -
> -   if (to_flush) {
> -      etna_set_state(ctx->stream, VIVS_GL_FLUSH_CACHE, to_flush);
> +   /* Always flush color and depth cache together before resolving. This works
> +    * around artifacts that appear in some cases when scanning out a texture
> +    * directly after it has been rendered to, such as rendering an animated web
> +    * page in a QtWebEngine based WebView on GC2000. The artifacts look like
> +    * the texture sampler samples zeroes instead of texture data in a small,
> +    * irregular triangle in the lower right of each browser tile quad. Other
> +    * attempts to avoid these artifacts, including a pipeline stall before the
> +    * color flush or a TS cache flush afterwards, or flushing multiple times,
> +    * with stalls before and after each flush, have shown no effect. */
> +   if (src->base.bind & PIPE_BIND_RENDER_TARGET ||
> +       src->base.bind & PIPE_BIND_DEPTH_STENCIL) {
> +      etna_set_state(ctx->stream, VIVS_GL_FLUSH_CACHE,
> +		     VIVS_GL_FLUSH_CACHE_COLOR | VIVS_GL_FLUSH_CACHE_DEPTH);
>        etna_stall(ctx->stream, SYNC_RECIPIENT_RA, SYNC_RECIPIENT_PE);
>     }
>