http://bugs.freedesktop.org/show_bug.cgi?id=13080
------- Comment #11 from [EMAIL PROTECTED] 2007-11-08 10:07 PST ------- (In reply to comment #10) > OK, I'll check this when I next get access to the PC with the Radeon 7000. And > so the reason that the R300 works is because it doesn't implement HyperZ? Not sure exactly what R300 implements - early Z for sure which doesn't interfere with direct reading/writing of the buffer. > Does this mean that HyperZ support for the R200/R100 is incomplete? Yes, which is why it's disabled... Apart from the problem of two windows very close together (so they have overlapping z tiles (16 pixels or so, don't know off-hand)) which could lead to some errors at their borders, any direct read/write of z buffer is completely broken. I had some ideas how to fix this, but it's not that easy. For z buffer writes, definitely the most easy thing to do would be to turn every pixel write into a point render (so all hyperz issues get handled automatically by the gpu). Reading is a mess, first you'd need to calculate the z tile address, then look the z tags up in the gpu to see if the z tile is compressed or cleared. If it's cleared, the value is the last used clear value, otherwise the tile must be read back as usual from the z buffer. If it's uncompressed, fine, no problem, but otherwise you have to software-decompress the tile to figure out the z value, which means you have to reverse-engeneer the compression algorithm... It is possible reading compressed tiles could be simpler, by forcing the chip to load the tile and decompress it, and accessing the decompressed tile data directly from the on-chip z buffer cache. I've got no idea though if that's even possible and if so, how to do it... There might be other solutions (like doing some render which forces the chip to update the tile you're interested in, reading it using hyperz and forcing it to store unchanged but uncompressed back), dunno. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
