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

[Chris Wilson]

On Fri, Sep 04, 2015 at 02:40:54PM -0700, Jason Ekstrand wrote:
> 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.

Another argument is that it is a client bug not to call
glMemoryBarrier() between setting up a texture and using it for the
first time.

The nearest discussion of this I could find was

Issue (11) What amount of automatic synchronization is provided for image loads
         and stores?  In particular, is the use of MemoryBarrier() required
         to ensure consistent ordering relative to other GL operations?  Or is
         some other mechanism (e.g., unbinding a texture from an image unit
         and then binding it to a texture image unit) sufficient?

      RESOLVED:  Use of MemoryBarrier is required, and there is no
      automatic synchronization when images are bound or unbound.

      Implicit synchronization is difficult, as it might require some
      combination of:

        - tracking which images might be written (randomly) in the shader
          itself;

        - assuming that if a shader that performs writes is executed, all
          texels of all bound images could be modified and thus must be
          treated as dirty;

        - idling at the end of each primitive or draw call, so that the
          results of all previous commands are complete.

      Since normal OpenGL operation is pipelined, idling would result in a
      significant performance impact since pipelining would otherwise allow
      fragment shader execution for draw call N while simultaneously
      performing vertex shader execution for draw call N+1.


>From that language, I understand it to mean that the client is
responsible for ensuring that the texture is coherent on binding after a
glTexImage*D.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre