On Sep 5, 2015 4:45 AM, "Francisco Jerez" <<a href="mailto:currojerez@riseup.net">currojerez@riseup.net</a>> wrote: > > Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>> writes: > > > On Fri, Sep 04, 2015 at 02:40:54PM -0700, Jason Ekstrand wrote: > >> On Fri, Sep 4, 2015 at 1:22 PM, Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>> 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. > > > Coincidentally I sent a patch to Jordan yesterday doing exactly that. > It should fix a superset of what this patch fixes and also handle the > case in which a buffer bound as image was fast-cleared and a resolve is > needed. I didn't have time to do enough testing so I may not send it > for review until I'm back from vacation in three weeks. In the meantime > I don't have any objection to this patch going in as temporary > workaround if this problem annoys you. Could you at least send it to the list as an RFC? --Jason > > 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. > > Not really, ARB_shader_image_load_store does guarantee implicit > synchronization of image access done after any other GL command that > already guarantees implicit synchronization in unextended GL. > glMemoryBarrier is only required to order shader image memory access > with *subsequent* GL commands of the kind given by the bitset argument. > > So an implicit flush is definitely needed at some point between > rendering and image access, either as in your or as in my patch. > > > -Chris > > > > -- > > Chris Wilson, Intel Open Source Technology Centre > > _______________________________________________ > > mesa-dev mailing list > > <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a> > > <a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a>