[Mesa-dev] [PATCH] i965: Perform an explicit flush after doing _mesa_meta_pbo_TexSubImage

[Jason Ekstrand]

On Fri, Sep 4, 2015 at 1:22 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> With the introduction of ARB_shader_image_load_store, shaders
> are able to perform random memory accesses to texture that
> are not easily tracked by the driver. Rather than see if this
> texture is bound to an ImageUnit when we perform a TexImage command
> via the GPU, and so its dirty state untracked by the normal implicit
> flush mechanism, insert an explicit flush before the next access.

This doesn't seem quite right to me.  What's to prevent a regular
render target from having the same problem?  We already do flushes
whenever we have a rendertarget -> texture transition, I think the
better thing to do would be to add them when we do a rendertarget ->
image transition.
--Jason

> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> Cc: Jason Ekstrand <jason.ekstrand at intel.com>
> Cc: Kenneth Graunke <kenneth at whitecape.org>
> Cc: Neil Roberts <neil at linux.intel.com>
> Cc: Francisco Jerez <currojerez at riseup.net>
> ---
>  src/mesa/drivers/dri/i965/intel_tex_image.c    | 10 +++++++++-
>  src/mesa/drivers/dri/i965/intel_tex_subimage.c | 10 +++++++++-
>  2 files changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_tex_image.c b/src/mesa/drivers/dri/i965/intel_tex_image.c
> index 93a8cde..cdd4450 100644
> --- a/src/mesa/drivers/dri/i965/intel_tex_image.c
> +++ b/src/mesa/drivers/dri/i965/intel_tex_image.c
> @@ -115,8 +115,16 @@ intelTexImage(struct gl_context * ctx,
>                                     format, type, pixels,
>                                     false /*allocate_storage*/,
>                                     tex_busy, unpack);
> -   if (ok)
> +   if (ok) {
> +      /* With the introduction of ARB_shader_image_load_store, shaders
> +       * are able to perform random memory accesses to texture that
> +       * are not easily tracked by the driver. Rather than see if this
> +       * texture is bound to an ImageUnit and so its dirty state untracked
> +       * insert an explicit flush before the next access.
> +       */
> +      brw_emit_mi_flush(brw_context(ctx));
>        return;
> +   }
>
>     ok = intel_texsubimage_tiled_memcpy(ctx, dims, texImage,
>                                         0, 0, 0, /*x,y,z offsets*/
> diff --git a/src/mesa/drivers/dri/i965/intel_tex_subimage.c b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
> index 44921e5..aeb710a 100644
> --- a/src/mesa/drivers/dri/i965/intel_tex_subimage.c
> +++ b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
> @@ -218,8 +218,16 @@ intelTexSubImage(struct gl_context * ctx,
>                                     xoffset, yoffset, zoffset,
>                                     width, height, depth, format, type,
>                                     pixels, false, tex_busy, packing);
> -   if (ok)
> +   if (ok) {
> +      /* With the introduction of ARB_shader_image_load_store, shaders
> +       * are able to perform random memory accesses to texture that
> +       * are not easily tracked by the driver. Rather than see if this
> +       * texture is bound to an ImageUnit and so its dirty state untracked
> +       * insert an explicit flush before the next access.
> +       */
> +      brw_emit_mi_flush(brw_context(ctx));
>        return;
> +   }
>
>     ok = intel_texsubimage_tiled_memcpy(ctx, dims, texImage,
>                                         xoffset, yoffset, zoffset,
> --
> 2.5.1
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev