Re: [Mesa-dev] [PATCH 8/9] radeonsi: don't emit partial flushes at the end of IBs

2017-06-19 Thread Nicolai Hähnle

On 19.06.2017 15:56, Marek Olšák wrote:

On Mon, Jun 19, 2017 at 2:48 PM, Nicolai Hähnle  wrote:

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

2017-06-19 Thread Marek Olšák
On Mon, Jun 19, 2017 at 2:48 PM, Nicolai Hähnle  wrote:
> 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

2017-06-19 Thread Nicolai Hähnle

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.


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

2017-06-16 Thread Marek Olšák
From: Marek Olšák 

The 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