Michel Dänzer wrote:
On Die, 2002-11-05 at 09:41, Keith Whitwell wrote:Looks good. Can you also cast an eye over the r200_span.c equivalents to make sure 16 is the number for r200 as well?
Michel Dänzer wrote:On Mon, 2002-11-04 at 21:11, Ian Romanick wrote:On Sun, Nov 03, 2002 at 04:58:23PM +0100, Michel Dänzer wrote:http://penguinppc.org/~daenzer/DRI/bzflag.png http://penguinppc.org/~daenzer/DRI/tuxracer.png[...]Access to the depth buffer is tiled, which means that pixel (x,y) isn't necessarily at (x,y), but could be some distance up or down from there. It may be that the region we're allocating for the depth buffer which would be large enough if it were all layed out linearly, but isn't large enough for the tiles. It's worth investigating as we've seen similar problems elsewhere.It's definitely the depth buffer running amok. If I move the texture region about 10 scanlines further away from it, no corruption occurs. Any ideas as to why this could happen appreciated, and why it doesn't happen on the x86 box at work, where the texture region is adjacent to the depth buffer.
Ah, tiling. I couldn't find any juicy info about it in the docs, but reading the depth buffer access functions in radeon_span.c, it seems that it basically partitions the buffer into blocks of 16 lines, which are scrambled somehow? Correct me if I'm wrong, otherwise I'll commit http://penguinppc.org/~daenzer/DRI/radeon-depth-size.diff , which Works For Me (TM).
Keith
-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
