Re: IGP320M HyperZ Texture bugs

[Roland S. <rsc...@hi...>]

Dieter N=FCtzel wrote:
>>>Actually, Roland had a suggestion regarding seting the tileoffset from
>>>*16 to *32. This helps a bit in my case. I suggest you also try this
>>>one. Maybe it will help for you too. It doesn't fix the entire problem=
,
>>>but it does make it better. Note that I also tried *24, *40, *48, *64
>>>and *128. *32 gives the most stable and also in picture the best resul=
t.
>>>The others definetly don't improve things...
>>
>>I'm playing with it, but all other then 16 (as far as i am ;-) give you=
r
>>described results.
>>
>>Could you try this (from Roland, too) in the meantime.
>>I running my r200 with it since drm-15 came out.
>>
>>--- radeon_state.c.orig 2004-11-11 22:08:37.000000000 +0100
>>+++ radeon_state.c.aktuell      2004-11-13 14:08:32.000000000 +0100
>>@@ -894,7 +894,8 @@
>>                }
>>                else {
>>                        /* FIXME : reverse engineer that for Rx00 cards=
 */
>>-                       clearmask =3D (0xff<<22)|(0xff<<6)| 0x003f003f;
>>+                       /* clearmask =3D (0xff<<22)|(0xff<<6)| 0x003f00=
3f; */
>>+                       clearmask =3D 0x0;
>=20
>=20
> Now,
>=20
> I've tested with the above and
>=20
>                                OUT_RING( tileoffset * 16 );
>=20
> 8-17 (all steps), even 32 do NOT work.
>=20
> ONLY 16 works.
That's not surprising. hyperz on r100, rv100, r200, rv250 REALLY works a=20
bit differently.
That said, I'll try to update the patch with a version which will work=20
on r100, rv250, and hopefully I get rv100 and r200 right. I'll ditch=20
hierarchical-z for now completely (even though it _mostly_ worked right=20
on the r100, there are too many unsolved issues about it).

Roland