<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Memory corruption when uploading DXT5 cubemap faces" href="https://bugs.freedesktop.org/show_bug.cgi?id=97473#c1">Comment # 1</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Memory corruption when uploading DXT5 cubemap faces" href="https://bugs.freedesktop.org/show_bug.cgi?id=97473">bug 97473</a> from <a class="email" href="mailto:kenneth@whitecape.org" title="Kenneth Graunke <kenneth@whitecape.org>"> Kenneth Graunke</a> <pre>I looked into this a bit earlier today: The texture in question is 4096x4096x6, Y-tiled, and DXT5. With a 4x4 block size and 16 bytes per block, this gives us a pitch of 16384. The size of a single layer is 67108864. This is larger than brw->max_gtt_map_object_size, so we think we can't map it in the GTT (using a fence for detiling). This makes intel_map_texture_image select the BLT based option, even though we normally wouldn't (for several reasons). However, our blitter code can't handle compressed data at all. It doesn't realize there are blocks involved, and assumes that it's a 4096x4096 image with a pitch of 16384, and so the buffer must be woefully undersized, and asserts. (Without asserts it probably reads/writes wildly out of bounds data.)</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>