Kenneth Graunke <kenn...@whitecape.org> writes: > The glMemoryBarrier() function makes shader memory stores ordered with > respect to things specified by the given bits. Until now, st/mesa has > ignored GL_TEXTURE_UPDATE_BARRIER_BIT and GL_BUFFER_UPDATE_BARRIER_BIT, > saying that drivers should implicitly perform the needed flushing. > > This seems like a pretty big assumption to make. Instead, this commit > opts to translate them to new PIPE_BARRIER bits, and adjusts existing > drivers to continue ignoring them (preserving the current behavior). > > The i965 driver performs actions on these memory barriers. Shader > memory stores go through a "data cache" which is separate from the > render cache and other read caches (like the texture cache). All > memory barriers need to flush the data cache (to ensure shader memory > stores are visible), and possibly invalidate read caches (to ensure > stale data is no longer visible). The driver implicitly flushes for > most caches, but not for data cache, since ARB_shader_image_load_store > introduced MemoryBarrier() precisely to order these explicitly. > > I would like to follow i965's approach in iris, flushing the data cache > on any MemoryBarrier() call, so I need st/mesa to actually call the > pipe->memory_barrier() callback.
Reviewed-by: Eric Anholt <e...@anholt.net>
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
