On Die, 2002-11-05 at 09:41, Keith Whitwell wrote: > 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
[...] > > 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. > > 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. 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). -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ------------------------------------------------------- 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
