Re: [Mesa-dev] [PATCH] gallium: Add PIPE_BARRIER_UPDATE_BUFFER and UPDATE_TEXTURE bits.
On Wednesday, March 20, 2019 6:37:07 AM PDT Ilia Mirkin wrote: > On Wed, Mar 6, 2019 at 3:32 AM Kenneth Graunke wrote: > > There are no nouveau changes in this patch, but that's only because none > > appeared to be necessary. Most drivers performed some kind of flush on > > any memory_barrier() call, regardless of the bits - but nouveau's hooks > > don't. So the newly added case would already be a no-op. > > I didn't go back to check the code earlier, but just saw the pushed > patch, forgot this comment, and decided to check. Looks like > > https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nvc0_context.c#n90 > > would get executed, no? > > -ilia Yikes...apparently failed at reading. I pushed a quick fix with the same code to bail that I put in all the other drivers: https://cgit.freedesktop.org/mesa/mesa/commit/?id=3c3f250456623d9892042a6d296e77d359702add I also re-checked nv50 and it seemed fine. Thanks! --Ken signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: Add PIPE_BARRIER_UPDATE_BUFFER and UPDATE_TEXTURE bits.
On Wed, Mar 6, 2019 at 3:32 AM Kenneth Graunke wrote: > > 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. > --- > .../drivers/freedreno/freedreno_context.c | 3 ++ > src/gallium/drivers/r600/r600_state_common.c | 4 +++ > src/gallium/drivers/radeonsi/si_state.c | 3 ++ > src/gallium/drivers/softpipe/sp_flush.c | 3 ++ > src/gallium/drivers/tegra/tegra_context.c | 3 ++ > src/gallium/drivers/v3d/v3d_context.c | 3 ++ > src/gallium/include/pipe/p_defines.h | 7 +++- > src/mesa/state_tracker/st_cb_texturebarrier.c | 34 +++ > 8 files changed, 44 insertions(+), 16 deletions(-) > > I am curious to hear people's thoughts on this. It seems useful for the > driver to receive a memory_barrier() call...and adding a few bits seemed > to be the cleanest way to make that happen. But I'm open to ideas. > > There are no nouveau changes in this patch, but that's only because none > appeared to be necessary. Most drivers performed some kind of flush on > any memory_barrier() call, regardless of the bits - but nouveau's hooks > don't. So the newly added case would already be a no-op. I didn't go back to check the code earlier, but just saw the pushed patch, forgot this comment, and decided to check. Looks like https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nvc0_context.c#n90 would get executed, no? -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: Add PIPE_BARRIER_UPDATE_BUFFER and UPDATE_TEXTURE bits.
Forgot Marek is on vacation. Nicolai, do you have an opinion?
It looks like you added the original comments that it isn't
necessary to handle these cases, too...
--Ken
On Thursday, March 7, 2019 3:48:04 PM PST Kenneth Graunke wrote:
> Hey Ilia, Marek,
>
> Do you have an opinion about this? I've got a R-b from Eric Anholt
> and what sounds like an Ack from Roland, but I wanted to make sure
> everyone was OK with this before landing it.
>
> --Ken
>
> On Wednesday, March 6, 2019 12:32:23 AM PST Kenneth Graunke wrote:
> > 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.
> > ---
> > .../drivers/freedreno/freedreno_context.c | 3 ++
> > src/gallium/drivers/r600/r600_state_common.c | 4 +++
> > src/gallium/drivers/radeonsi/si_state.c | 3 ++
> > src/gallium/drivers/softpipe/sp_flush.c | 3 ++
> > src/gallium/drivers/tegra/tegra_context.c | 3 ++
> > src/gallium/drivers/v3d/v3d_context.c | 3 ++
> > src/gallium/include/pipe/p_defines.h | 7 +++-
> > src/mesa/state_tracker/st_cb_texturebarrier.c | 34 +++
> > 8 files changed, 44 insertions(+), 16 deletions(-)
> >
> > I am curious to hear people's thoughts on this. It seems useful for the
> > driver to receive a memory_barrier() call...and adding a few bits seemed
> > to be the cleanest way to make that happen. But I'm open to ideas.
> >
> > There are no nouveau changes in this patch, but that's only because none
> > appeared to be necessary. Most drivers performed some kind of flush on
> > any memory_barrier() call, regardless of the bits - but nouveau's hooks
> > don't. So the newly added case would already be a no-op.
> >
> > diff --git a/src/gallium/drivers/freedreno/freedreno_context.c
> > b/src/gallium/drivers/freedreno/freedreno_context.c
> > index 6c01c15bb32..4e86d099974 100644
> > --- a/src/gallium/drivers/freedreno/freedreno_context.c
> > +++ b/src/gallium/drivers/freedreno/freedreno_context.c
> > @@ -99,6 +99,9 @@ fd_texture_barrier(struct pipe_context *pctx, unsigned
> > flags)
> > static void
> > fd_memory_barrier(struct pipe_context *pctx, unsigned flags)
> > {
> > + if (!(flags & ~PIPE_BARRIER_UPDATE))
> > + return;
> > +
> > fd_context_flush(pctx, NULL, 0);
> > /* TODO do we need to check for persistently mapped buffers and
> > fd_bo_cpu_prep()?? */
> > }
> > diff --git a/src/gallium/drivers/r600/r600_state_common.c
> > b/src/gallium/drivers/r600/r600_state_common.c
> > index f886a27170d..c7c606f131b 100644
> > --- a/src/gallium/drivers/r600/r600_state_common.c
> > +++ b/src/gallium/drivers/r600/r600_state_common.c
> > @@ -94,6 +94,10 @@ void r600_emit_alphatest_state(struct r600_context
> > *rctx, struct r600_atom *atom
> > static void r600_memory_barrier(struct pipe_context *ctx, unsigned flags)
> > {
> > struct r600_context *rctx = (struct r600_context *)ctx;
> > +
> > + if (!(flags & ~PIPE_BARRIER_UPDATE))
> > + return;
> > +
> > if (flags & PIPE_BARRIER_CONSTANT_BUFFER)
> > rctx->b.flags |= R600_CONTEXT_INV_CONST_CACHE;
> >
> > diff --git a/src/gallium/drivers/radeonsi/si_state.c
> > b/src/gallium/drivers/radeonsi/si_state.c
> > index 458b108a7e3..3c29b4c92ed 100644
> > --- a/src/gallium/drivers/radeonsi/si_state.c
> > +++ b/src/gallium/drivers/radeonsi/si_state.c
> > @@ -4710,6 +4710,9 @@ void si_memory_barrier(struct pipe_context *ctx,
> > unsigned flags)
> > {
> > struct si_context *sctx = (struct si_context *)ctx;
> >
> > + if (!(flags & ~PIPE_BARRIER_UPDATE))
> > + return;
> > +
> > /* Subsequent commands must wait for all shader invocations to
> > * complete. */
> > sctx->flags |= SI_CONTEXT_PS_PARTIAL_FLUSH |
> > diff --git
Re: [Mesa-dev] [PATCH] gallium: Add PIPE_BARRIER_UPDATE_BUFFER and UPDATE_TEXTURE bits.
Hey Ilia, Marek,
Do you have an opinion about this? I've got a R-b from Eric Anholt
and what sounds like an Ack from Roland, but I wanted to make sure
everyone was OK with this before landing it.
--Ken
On Wednesday, March 6, 2019 12:32:23 AM PST Kenneth Graunke wrote:
> 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.
> ---
> .../drivers/freedreno/freedreno_context.c | 3 ++
> src/gallium/drivers/r600/r600_state_common.c | 4 +++
> src/gallium/drivers/radeonsi/si_state.c | 3 ++
> src/gallium/drivers/softpipe/sp_flush.c | 3 ++
> src/gallium/drivers/tegra/tegra_context.c | 3 ++
> src/gallium/drivers/v3d/v3d_context.c | 3 ++
> src/gallium/include/pipe/p_defines.h | 7 +++-
> src/mesa/state_tracker/st_cb_texturebarrier.c | 34 +++
> 8 files changed, 44 insertions(+), 16 deletions(-)
>
> I am curious to hear people's thoughts on this. It seems useful for the
> driver to receive a memory_barrier() call...and adding a few bits seemed
> to be the cleanest way to make that happen. But I'm open to ideas.
>
> There are no nouveau changes in this patch, but that's only because none
> appeared to be necessary. Most drivers performed some kind of flush on
> any memory_barrier() call, regardless of the bits - but nouveau's hooks
> don't. So the newly added case would already be a no-op.
>
> diff --git a/src/gallium/drivers/freedreno/freedreno_context.c
> b/src/gallium/drivers/freedreno/freedreno_context.c
> index 6c01c15bb32..4e86d099974 100644
> --- a/src/gallium/drivers/freedreno/freedreno_context.c
> +++ b/src/gallium/drivers/freedreno/freedreno_context.c
> @@ -99,6 +99,9 @@ fd_texture_barrier(struct pipe_context *pctx, unsigned
> flags)
> static void
> fd_memory_barrier(struct pipe_context *pctx, unsigned flags)
> {
> + if (!(flags & ~PIPE_BARRIER_UPDATE))
> + return;
> +
> fd_context_flush(pctx, NULL, 0);
> /* TODO do we need to check for persistently mapped buffers and
> fd_bo_cpu_prep()?? */
> }
> diff --git a/src/gallium/drivers/r600/r600_state_common.c
> b/src/gallium/drivers/r600/r600_state_common.c
> index f886a27170d..c7c606f131b 100644
> --- a/src/gallium/drivers/r600/r600_state_common.c
> +++ b/src/gallium/drivers/r600/r600_state_common.c
> @@ -94,6 +94,10 @@ void r600_emit_alphatest_state(struct r600_context *rctx,
> struct r600_atom *atom
> static void r600_memory_barrier(struct pipe_context *ctx, unsigned flags)
> {
> struct r600_context *rctx = (struct r600_context *)ctx;
> +
> + if (!(flags & ~PIPE_BARRIER_UPDATE))
> + return;
> +
> if (flags & PIPE_BARRIER_CONSTANT_BUFFER)
> rctx->b.flags |= R600_CONTEXT_INV_CONST_CACHE;
>
> diff --git a/src/gallium/drivers/radeonsi/si_state.c
> b/src/gallium/drivers/radeonsi/si_state.c
> index 458b108a7e3..3c29b4c92ed 100644
> --- a/src/gallium/drivers/radeonsi/si_state.c
> +++ b/src/gallium/drivers/radeonsi/si_state.c
> @@ -4710,6 +4710,9 @@ void si_memory_barrier(struct pipe_context *ctx,
> unsigned flags)
> {
> struct si_context *sctx = (struct si_context *)ctx;
>
> + if (!(flags & ~PIPE_BARRIER_UPDATE))
> + return;
> +
> /* Subsequent commands must wait for all shader invocations to
>* complete. */
> sctx->flags |= SI_CONTEXT_PS_PARTIAL_FLUSH |
> diff --git a/src/gallium/drivers/softpipe/sp_flush.c
> b/src/gallium/drivers/softpipe/sp_flush.c
> index 3bf8c499218..5eccbe34d46 100644
> --- a/src/gallium/drivers/softpipe/sp_flush.c
> +++ b/src/gallium/drivers/softpipe/sp_flush.c
> @@ -192,5 +192,8 @@ void softpipe_texture_barrier(struct pipe_context *pipe,
> unsigned flags)
>
> void softpipe_memory_barrier(struct pipe_context *pipe, unsigned flags)
> {
> + if (!(flags &
Re: [Mesa-dev] [PATCH] gallium: Add PIPE_BARRIER_UPDATE_BUFFER and UPDATE_TEXTURE bits.
Kenneth Graunke 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 signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: Add PIPE_BARRIER_UPDATE_BUFFER and UPDATE_TEXTURE bits.
The idea seems reasonable to me (albeit I think having so many different
barrier bits in the API in the first place is likely to cause apps to
slightly misuse them...). Drivers which don't need to care can always
ignore it.
Roland
Am 06.03.19 um 09:32 schrieb Kenneth Graunke:
> 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.
> ---
> .../drivers/freedreno/freedreno_context.c | 3 ++
> src/gallium/drivers/r600/r600_state_common.c | 4 +++
> src/gallium/drivers/radeonsi/si_state.c | 3 ++
> src/gallium/drivers/softpipe/sp_flush.c | 3 ++
> src/gallium/drivers/tegra/tegra_context.c | 3 ++
> src/gallium/drivers/v3d/v3d_context.c | 3 ++
> src/gallium/include/pipe/p_defines.h | 7 +++-
> src/mesa/state_tracker/st_cb_texturebarrier.c | 34 +++
> 8 files changed, 44 insertions(+), 16 deletions(-)
>
> I am curious to hear people's thoughts on this. It seems useful for the
> driver to receive a memory_barrier() call...and adding a few bits seemed
> to be the cleanest way to make that happen. But I'm open to ideas.
>
> There are no nouveau changes in this patch, but that's only because none
> appeared to be necessary. Most drivers performed some kind of flush on
> any memory_barrier() call, regardless of the bits - but nouveau's hooks
> don't. So the newly added case would already be a no-op.
>
> diff --git a/src/gallium/drivers/freedreno/freedreno_context.c
> b/src/gallium/drivers/freedreno/freedreno_context.c
> index 6c01c15bb32..4e86d099974 100644
> --- a/src/gallium/drivers/freedreno/freedreno_context.c
> +++ b/src/gallium/drivers/freedreno/freedreno_context.c
> @@ -99,6 +99,9 @@ fd_texture_barrier(struct pipe_context *pctx, unsigned
> flags)
> static void
> fd_memory_barrier(struct pipe_context *pctx, unsigned flags)
> {
> + if (!(flags & ~PIPE_BARRIER_UPDATE))
> + return;
> +
> fd_context_flush(pctx, NULL, 0);
> /* TODO do we need to check for persistently mapped buffers and
> fd_bo_cpu_prep()?? */
> }
> diff --git a/src/gallium/drivers/r600/r600_state_common.c
> b/src/gallium/drivers/r600/r600_state_common.c
> index f886a27170d..c7c606f131b 100644
> --- a/src/gallium/drivers/r600/r600_state_common.c
> +++ b/src/gallium/drivers/r600/r600_state_common.c
> @@ -94,6 +94,10 @@ void r600_emit_alphatest_state(struct r600_context *rctx,
> struct r600_atom *atom
> static void r600_memory_barrier(struct pipe_context *ctx, unsigned flags)
> {
> struct r600_context *rctx = (struct r600_context *)ctx;
> +
> + if (!(flags & ~PIPE_BARRIER_UPDATE))
> + return;
> +
> if (flags & PIPE_BARRIER_CONSTANT_BUFFER)
> rctx->b.flags |= R600_CONTEXT_INV_CONST_CACHE;
>
> diff --git a/src/gallium/drivers/radeonsi/si_state.c
> b/src/gallium/drivers/radeonsi/si_state.c
> index 458b108a7e3..3c29b4c92ed 100644
> --- a/src/gallium/drivers/radeonsi/si_state.c
> +++ b/src/gallium/drivers/radeonsi/si_state.c
> @@ -4710,6 +4710,9 @@ void si_memory_barrier(struct pipe_context *ctx,
> unsigned flags)
> {
> struct si_context *sctx = (struct si_context *)ctx;
>
> + if (!(flags & ~PIPE_BARRIER_UPDATE))
> + return;
> +
> /* Subsequent commands must wait for all shader invocations to
>* complete. */
> sctx->flags |= SI_CONTEXT_PS_PARTIAL_FLUSH |
> diff --git a/src/gallium/drivers/softpipe/sp_flush.c
> b/src/gallium/drivers/softpipe/sp_flush.c
> index 3bf8c499218..5eccbe34d46 100644
> --- a/src/gallium/drivers/softpipe/sp_flush.c
> +++ b/src/gallium/drivers/softpipe/sp_flush.c
> @@ -192,5 +192,8 @@ void softpipe_texture_barrier(struct pipe_context *pipe,
> unsigned flags)
>
> void softpipe_memory_barrier(struct pipe_context *pipe, unsigned flags)
> {
> + if (!(flags &
[Mesa-dev] [PATCH] gallium: Add PIPE_BARRIER_UPDATE_BUFFER and UPDATE_TEXTURE bits.
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.
---
.../drivers/freedreno/freedreno_context.c | 3 ++
src/gallium/drivers/r600/r600_state_common.c | 4 +++
src/gallium/drivers/radeonsi/si_state.c | 3 ++
src/gallium/drivers/softpipe/sp_flush.c | 3 ++
src/gallium/drivers/tegra/tegra_context.c | 3 ++
src/gallium/drivers/v3d/v3d_context.c | 3 ++
src/gallium/include/pipe/p_defines.h | 7 +++-
src/mesa/state_tracker/st_cb_texturebarrier.c | 34 +++
8 files changed, 44 insertions(+), 16 deletions(-)
I am curious to hear people's thoughts on this. It seems useful for the
driver to receive a memory_barrier() call...and adding a few bits seemed
to be the cleanest way to make that happen. But I'm open to ideas.
There are no nouveau changes in this patch, but that's only because none
appeared to be necessary. Most drivers performed some kind of flush on
any memory_barrier() call, regardless of the bits - but nouveau's hooks
don't. So the newly added case would already be a no-op.
diff --git a/src/gallium/drivers/freedreno/freedreno_context.c
b/src/gallium/drivers/freedreno/freedreno_context.c
index 6c01c15bb32..4e86d099974 100644
--- a/src/gallium/drivers/freedreno/freedreno_context.c
+++ b/src/gallium/drivers/freedreno/freedreno_context.c
@@ -99,6 +99,9 @@ fd_texture_barrier(struct pipe_context *pctx, unsigned flags)
static void
fd_memory_barrier(struct pipe_context *pctx, unsigned flags)
{
+ if (!(flags & ~PIPE_BARRIER_UPDATE))
+ return;
+
fd_context_flush(pctx, NULL, 0);
/* TODO do we need to check for persistently mapped buffers and
fd_bo_cpu_prep()?? */
}
diff --git a/src/gallium/drivers/r600/r600_state_common.c
b/src/gallium/drivers/r600/r600_state_common.c
index f886a27170d..c7c606f131b 100644
--- a/src/gallium/drivers/r600/r600_state_common.c
+++ b/src/gallium/drivers/r600/r600_state_common.c
@@ -94,6 +94,10 @@ void r600_emit_alphatest_state(struct r600_context *rctx,
struct r600_atom *atom
static void r600_memory_barrier(struct pipe_context *ctx, unsigned flags)
{
struct r600_context *rctx = (struct r600_context *)ctx;
+
+ if (!(flags & ~PIPE_BARRIER_UPDATE))
+ return;
+
if (flags & PIPE_BARRIER_CONSTANT_BUFFER)
rctx->b.flags |= R600_CONTEXT_INV_CONST_CACHE;
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index 458b108a7e3..3c29b4c92ed 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -4710,6 +4710,9 @@ void si_memory_barrier(struct pipe_context *ctx, unsigned
flags)
{
struct si_context *sctx = (struct si_context *)ctx;
+ if (!(flags & ~PIPE_BARRIER_UPDATE))
+ return;
+
/* Subsequent commands must wait for all shader invocations to
* complete. */
sctx->flags |= SI_CONTEXT_PS_PARTIAL_FLUSH |
diff --git a/src/gallium/drivers/softpipe/sp_flush.c
b/src/gallium/drivers/softpipe/sp_flush.c
index 3bf8c499218..5eccbe34d46 100644
--- a/src/gallium/drivers/softpipe/sp_flush.c
+++ b/src/gallium/drivers/softpipe/sp_flush.c
@@ -192,5 +192,8 @@ void softpipe_texture_barrier(struct pipe_context *pipe,
unsigned flags)
void softpipe_memory_barrier(struct pipe_context *pipe, unsigned flags)
{
+ if (!(flags & ~PIPE_BARRIER_UPDATE))
+ return;
+
softpipe_texture_barrier(pipe, 0);
}
diff --git a/src/gallium/drivers/tegra/tegra_context.c
b/src/gallium/drivers/tegra/tegra_context.c
index bbc03628336..e9e51656921 100644
--- a/src/gallium/drivers/tegra/tegra_context.c
+++ b/src/gallium/drivers/tegra/tegra_context.c
@@ -974,6 +974,9 @@ tegra_memory_barrier(struct pipe_context *pcontext,
unsigned int flags)
{
struct tegra_context *context =
