Hi,
On Saturday, April 30, 2011 15:41:45 Fredrik Höglund wrote:
> > So, I know that this patch is not applicable, since it does not account
> > for sufficient cs space for this additional flush. Also it is probably
> > too croase in face of the finegrained bo flush logic.
>
> Actually I think it should be fine, since this event type is about the
> destination and smx caches if I'm reading the documentation right.
>
> There's also a small margin in the dwords reserved for context_flush;
> it only uses 10 of the 16 dwords reserved for it.
Ok, so there is sufficient space ...
> > May be this does ring some bell which flush is missing?
> > If not, does somebody have any clue which chips do suffer from this
> > prolem?
>
> I think it's rv6xx that's a bit special. There is a also a bug report about
> random GPU lockups with those chipsets since the cache flush changes:
>
> https://bugs.freedesktop.org/show_bug.cgi?id=36525
>
> I thought adding this event write might fix that, but apparently it didn't.
> My patch wrote the packet before flushing the buffers though.
I have again spent some more tries with different kinds of flushes on the rv635.
What helps for the mipmap problem here is emitting a texture_barrier as well
as flushing anything that covers the whole memory range and more than two
arbitrary color buffers. !?!
Given your comment I have implemented a two alternative flush paths one for the
rv6xx chips which does just the brutal cache flush invalidate and one for the
rest which still uses the selective bo flushes.
For my rv635 this works.
Does this also fix 35312?
Greetings
Mathias
From 64a43b00b5ad7c57b4d9dab15a3464feaaafaf5c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mathias=20Fr=C3=B6hlich?= <mathias.froehl...@web.de>
Date: Sun, 24 Apr 2011 08:55:34 +0200
Subject: [PATCH] r600g: Emit a cache flush invalidate on a dest cache flush
on rv6xx.
This fixes a problem with building mipmaps on a rv635.
Selectively flushing just the buffer objects ranges seem to be
insufficient on these chips. So, do a brute cache flush
invalidate on these chips.
---
src/gallium/winsys/r600/drm/r600_hw_context.c | 35 ++++++++++++++++++++-----
1 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/src/gallium/winsys/r600/drm/r600_hw_context.c b/src/gallium/winsys/r600/drm/r600_hw_context.c
index e28ef1f..364c9c1 100644
--- a/src/gallium/winsys/r600/drm/r600_hw_context.c
+++ b/src/gallium/winsys/r600/drm/r600_hw_context.c
@@ -1171,17 +1171,38 @@ void r600_context_flush_dest_caches(struct r600_context *ctx)
cb[7] = r600_context_reg_bo(ctx, R_02805C_CB_COLOR7_BASE);
/* flush the color buffers */
- for (int i = 0; i < 8; i++) {
- if (!cb[i])
- continue;
+ if ((ctx->radeon->family > CHIP_R600) &&
+ (ctx->radeon->family < CHIP_RV770)) {
+ /* selectively flushing buffer objects does not seem to work on these chips */
+ bool need_flush = false;
+
+ for (int i = 0; i < 8; i++) {
+ if (!cb[i])
+ continue;
- r600_context_bo_flush(ctx,
+ need_flush = true;
+ break;
+ }
+ if (db) {
+ need_flush = true;
+ }
+ if (need_flush) {
+ ctx->pm4[ctx->pm4_cdwords++] = PKT3(PKT3_EVENT_WRITE, 0, ctx->predicate_drawing);
+ ctx->pm4[ctx->pm4_cdwords++] = EVENT_TYPE(EVENT_TYPE_CACHE_FLUSH_AND_INV_EVENT) | EVENT_INDEX(0);
+ }
+ } else {
+ for (int i = 0; i < 8; i++) {
+ if (!cb[i])
+ continue;
+
+ r600_context_bo_flush(ctx,
(S_0085F0_CB0_DEST_BASE_ENA(1) << i) |
S_0085F0_CB_ACTION_ENA(1),
0, cb[i]);
- }
- if (db) {
- r600_context_bo_flush(ctx, S_0085F0_DB_ACTION_ENA(1), 0, db);
+ }
+ if (db) {
+ r600_context_bo_flush(ctx, S_0085F0_DB_ACTION_ENA(1), 0, db);
+ }
}
ctx->flags &= ~R600_CONTEXT_DST_CACHES_DIRTY;
--
1.7.4.4
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
