Comme=
nt # 36
on bug 11089=
7
from =
Richard Thier
Okay it seems pipes=3D1 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_propertie=
s(struct r300_screen
*screen,
pipes =3D screen->info.r300_num_z_pipes;
} else {
pipes =3D screen->info.r300_num_gb_pipes;
+ /* FIXME: Quickfix only for Mobility Radeon Xpress 200M in asus
laptop! */
+ pipes =3D 2; // Half the screen is bad for me
+ pipes =3D 1; // Whole screen is ok for me
}
for (i =3D 0; i <=3D tex->b.b.last_level; i++) {
I do not even dare uploading this patch as it likely only works on my speci=
fic
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 pr=
oper
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] =3D {4, 8, 12, 8};
327 static unsigned zmask_blocks_y_per_dw[4] =3D {4, 4, 4, 8};
I should have thought that pipes=3D1 is for me. As you can see here, there =
are
hardcoded values for X and Y block counts. Originally drm reports pipes=3D3=
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=3D2" would not work still, because 4*8 =
=3D 32 is still much
more than 6*2=3D12 I provided. Of course 4*4=3D16 so now I see my earlier h=
ack was
a bit miscalculated.
Also now I see exactly why 1/3 of the screen was only "working": =
because 12/4 =3D
3 and 4/4=3D1. You can clearly see this from the table!!! Wow!
I see that "r300_num_gb_pipes" is used at some of the other place=
s:
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 migh=
t go and
change code so that winsys returns gb_pipes=3D1 itself without hacks at oth=
er
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 re=
ally
used and the value was bad before!
Then if I see that I really only have one pipeline, then maybe I should loo=
k at
the other side of this drm call to see why it returns this value and not el=
se.
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 actual=
ly
make more to be properly rendered on screen! Because if there are two or th=
ree
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 sim=
ple
maths to see the smaller values are better here then.