Re: [Mesa-dev] [PATCH 8/9] radeonsi: don't emit partial flushes at the end of IBs
On 19.06.2017 15:56, Marek Olšák wrote: On Mon, Jun 19, 2017 at 2:48 PM, Nicolai Hähnlewrote: On 16.06.2017 14:58, Marek Olšák wrote: From: Marek Olšák The kernel sort of does the same thing with fences. The kernel sends an EVENT_WRITE_EOP with various TC flags. Is that guaranteed to wait for shaders to finish and flush their data? I'm mostly thinking about synchronizing with CPU reads here. Yes, EOP events first wait and then they flush caches. Okay. While reading, I noticed that si_emit_cache_flush has a path where L1 is invalidated _after_ L2 writeback. What's up with that? Couldn't it happen that there's data in L1 which is not yet written to L2? Seems odd. I have a vague memory that all stores go to L2 either immediately or at the end of waves, but I'm not sure. I think you're right. v2 of patch 7 & patch 8 are Reviewed-by: Nicolai Hähnle Marek -- Lerne, wie die Welt wirklich ist, Aber vergiss niemals, wie sie sein sollte. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 8/9] radeonsi: don't emit partial flushes at the end of IBs
On Mon, Jun 19, 2017 at 2:48 PM, Nicolai Hähnlewrote: > On 16.06.2017 14:58, Marek Olšák wrote: >> >> From: Marek Olšák >> >> The kernel sort of does the same thing with fences. > > > The kernel sends an EVENT_WRITE_EOP with various TC flags. Is that > guaranteed to wait for shaders to finish and flush their data? I'm mostly > thinking about synchronizing with CPU reads here. Yes, EOP events first wait and then they flush caches. > > While reading, I noticed that si_emit_cache_flush has a path where L1 is > invalidated _after_ L2 writeback. What's up with that? Couldn't it happen > that there's data in L1 which is not yet written to L2? Seems odd. I have a vague memory that all stores go to L2 either immediately or at the end of waves, but I'm not sure. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 8/9] radeonsi: don't emit partial flushes at the end of IBs
On 16.06.2017 14:58, Marek Olšák wrote: From: Marek OlšákThe kernel sort of does the same thing with fences. The kernel sends an EVENT_WRITE_EOP with various TC flags. Is that guaranteed to wait for shaders to finish and flush their data? I'm mostly thinking about synchronizing with CPU reads here. While reading, I noticed that si_emit_cache_flush has a path where L1 is invalidated _after_ L2 writeback. What's up with that? Couldn't it happen that there's data in L1 which is not yet written to L2? Seems odd. Cheers, Nicolai --- src/gallium/drivers/radeonsi/si_hw_context.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/gallium/drivers/radeonsi/si_hw_context.c b/src/gallium/drivers/radeonsi/si_hw_context.c index 345825a..5d930a6 100644 --- a/src/gallium/drivers/radeonsi/si_hw_context.c +++ b/src/gallium/drivers/radeonsi/si_hw_context.c @@ -122,27 +122,27 @@ void si_context_gfx_flush(void *context, unsigned flags, } ctx->gfx_flush_in_progress = true; /* This CE dump should be done in parallel with the last draw. */ if (ctx->ce_ib) si_ce_save_all_descriptors_at_ib_end(ctx); r600_preflush_suspend_features(>b); - ctx->b.flags |= SI_CONTEXT_CS_PARTIAL_FLUSH | - SI_CONTEXT_PS_PARTIAL_FLUSH; - /* DRM 3.1.0 doesn't flush TC for VI correctly. */ - if (ctx->b.chip_class == VI && ctx->b.screen->info.drm_minor <= 1) - ctx->b.flags |= SI_CONTEXT_INV_GLOBAL_L2 | + if (ctx->b.chip_class == VI && ctx->b.screen->info.drm_minor <= 1) { + ctx->b.flags |= SI_CONTEXT_PS_PARTIAL_FLUSH | + SI_CONTEXT_CS_PARTIAL_FLUSH | + SI_CONTEXT_INV_GLOBAL_L2 | SI_CONTEXT_INV_VMEM_L1; + } si_emit_cache_flush(ctx); if (ctx->trace_buf) si_trace_emit(ctx); if (ctx->is_debug) { /* Save the IB for debug contexts. */ radeon_clear_saved_cs(>last_gfx); radeon_save_cs(ws, cs, >last_gfx); -- Lerne, wie die Welt wirklich ist, Aber vergiss niemals, wie sie sein sollte. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 8/9] radeonsi: don't emit partial flushes at the end of IBs
From: Marek OlšákThe kernel sort of does the same thing with fences. --- src/gallium/drivers/radeonsi/si_hw_context.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/gallium/drivers/radeonsi/si_hw_context.c b/src/gallium/drivers/radeonsi/si_hw_context.c index 345825a..5d930a6 100644 --- a/src/gallium/drivers/radeonsi/si_hw_context.c +++ b/src/gallium/drivers/radeonsi/si_hw_context.c @@ -122,27 +122,27 @@ void si_context_gfx_flush(void *context, unsigned flags, } ctx->gfx_flush_in_progress = true; /* This CE dump should be done in parallel with the last draw. */ if (ctx->ce_ib) si_ce_save_all_descriptors_at_ib_end(ctx); r600_preflush_suspend_features(>b); - ctx->b.flags |= SI_CONTEXT_CS_PARTIAL_FLUSH | - SI_CONTEXT_PS_PARTIAL_FLUSH; - /* DRM 3.1.0 doesn't flush TC for VI correctly. */ - if (ctx->b.chip_class == VI && ctx->b.screen->info.drm_minor <= 1) - ctx->b.flags |= SI_CONTEXT_INV_GLOBAL_L2 | + if (ctx->b.chip_class == VI && ctx->b.screen->info.drm_minor <= 1) { + ctx->b.flags |= SI_CONTEXT_PS_PARTIAL_FLUSH | + SI_CONTEXT_CS_PARTIAL_FLUSH | + SI_CONTEXT_INV_GLOBAL_L2 | SI_CONTEXT_INV_VMEM_L1; + } si_emit_cache_flush(ctx); if (ctx->trace_buf) si_trace_emit(ctx); if (ctx->is_debug) { /* Save the IB for debug contexts. */ radeon_clear_saved_cs(>last_gfx); radeon_save_cs(ws, cs, >last_gfx); -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev