[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=110897

--- Comment #36 from Richard Thier <u9vata at gmail.com> ---
Okay it seems pipes=1 is working on my machine.

diff --git a/src/gallium/drivers/r300/r300_texture_desc.c
b/src/gallium/drivers/r300/r300_texture_desc.c
index 77d272bfb6b..029b28570d7 100644
--- a/src/gallium/drivers/r300/r300_texture_desc.c
+++ b/src/gallium/drivers/r300/r300_texture_desc.c
@@ -358,6 +358,9 @@ static void r300_setup_hyperz_properties(struct r300_screen
*screen,
             pipes = screen->info.r300_num_z_pipes;
         } else {
             pipes = screen->info.r300_num_gb_pipes;
+           /* FIXME: Quickfix only for Mobility Radeon Xpress 200M in asus
laptop! */
+            pipes = 2; // Half the screen is bad for me
+            pipes = 1; // Whole screen is ok for me
         }

         for (i = 0; i <= tex->b.b.last_level; i++) {

I do not even dare uploading this patch as it likely only works on my specific
machine! The know-how seems to be worthy of knowing though so in case anyone
see something like this, they can try something similar until there is a proper
fix.

317     /* The tile size of 1 DWORD in ZMASK RAM is:
318      *
319      * GPU    Pipes    4x4 mode   8x8 mode
320      * ------------------------------------------
321      * R580   4P/1Z    32x32      64x64
322      * RV570  3P/1Z    48x16      96x32
323      * RV530  1P/2Z    32x16      64x32
324      *        1P/1Z    16x16      32x32
325      */
326     static unsigned zmask_blocks_x_per_dw[4] = {4, 8, 12, 8};
327     static unsigned zmask_blocks_y_per_dw[4] = {4, 4,  4, 8};

I should have thought that pipes=1 is for me. As you can see here, there are
hardcoded values for X and Y block counts. Originally drm reports pipes=3 for
my card so I end up using the third column in this table: 12*4 blocks.

Now remembering I had to half both of them earlier using the hacky patch (6*2)
it was sure that "pipes=2" would not work still, because 4*8 = 32 is still much
more than 6*2=12 I provided. Of course 4*4=16 so now I see my earlier hack was
a bit miscalculated.

Also now I see exactly why 1/3 of the screen was only "working": because 12/4 =
3 and 4/4=1. You can clearly see this from the table!!! Wow!

I see that "r300_num_gb_pipes" is used at some of the other places:

src/gallium/drivers/r300/r300_query.c
src/gallium/drivers/r300/r300_emit.c (also for some queries)
src/gallium/drivers/r300/r300_context.c (only fprintf-ing for debugging)
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c (this where the drm query is)

I do not really know what kind of "queries" are these, but I might go and
change code so that winsys returns gb_pipes=1 itself without hacks at other
places and see if there are other glitches (a bit prolonged testing).

Who knows, maybe things actually get less glitchy if this query stuff is really
used and the value was bad before!

Then if I see that I really only have one pipeline, then maybe I should look at
the other side of this drm call to see why it returns this value and not else.

PS.: One other thing that I do not know is if pipes can exist maybe but can be
turned off or something? But I really have no idea about that.

PS.: I also grow to understand the logic why the smaller values here actually
make more to be properly rendered on screen! Because if there are two or three
pipes for example, you clear things similarly to this pattern:

01012323.... etc (I saw them in docs or source comments). So if there would be
two pipes, you can z-delete two blocks at the same time etc. it is only simple
maths to see the smaller values are better here then.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20190614/f53f3edc/attachment.html>