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

Chris Wilson chris at chris-wilson.co.uk
Fri Sep 4 15:41:15 PDT 2015


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.

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


More information about the mesa-dev mailing list