On Fri, Sep 04, 2015 at 02:40:54PM -0700, Jason Ekstrand wrote: > On Fri, Sep 4, 2015 at 1:22 PM, Chris Wilson <ch...@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.
Every time we complete a primitive we mark all the render targets (color, depth, stencil) as dirty, then on a subsequent intel_update_state() we emit a flush if any of the bound textures are dirty. ARB_shader_image_load_store introduces new language that moves the onus of tracking dirty state from the driver onto the user (under the guise that now any shader can write to any texture on any unit that tracking the dependencies becomes hard - or rather it removes the burden of iterating over the image units looking for flushes). One of the steps I took was looping over for_each_ImageUnit and doing the flush if Valid && TexObj->dirty. The other option I considered was adding a _mesa_MemoryBarrier() call into meta_blit(), then realised that only certain calls to meta_blit, specifically meta_pbo_TexSubImage, interacted badly with the extension and that inserting a flush after each TexImage was not a huge deal (as we expect to have to flush as the next operation is likely to use a dirty texture, but a series of TexImages is also likely). And there is the precedent that we already do a big hammer flush after using meta when touching random state. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
