On Thu, Oct 4, 2012 at 4:06 PM, Jerome Glisse <[email protected]> wrote: > On Wed, Oct 3, 2012 at 5:50 PM, Marek Olšák <[email protected]> wrote: >> The decompression is done in-place and only the compressed tiles are >> decompressed. Note: R6xx-R7xx can do that only with Z16 and Z32F. >> >> The texture unit is programmed to use non-displayable tiling and depth >> ordering of samples, so that it can fetch the texture in the native DB >> format. >> >> The latest version of the libdrm surface allocator is required for stencil >> texturing to work. The old one didn't create the mipmap tree correctly. >> We need a separate mipmap tree for stencil, because the stencil mipmap >> offsets are not really depth offsets/4. >> >> The DB->CB copy is still used for transfers. >> --- >> >> I sent the libdrm patches a few minutes ago. I guess I will have to make >> another libdrm release. >> >> What's good about this is that it improves performance by 4-5% with the >> 1024x768 resolution in Lightsmark on Evergreen. However, the larger the >> resolution, the smaller the improvement is (something else becomes the >> bottleneck). It also reduces the memory requirements for depth textures by >> 50%, because the "flushed depth texture" isn't needed anymore. >> >> The catch is fetching the 4th stencil mipmap level gives wrong pixels in one >> not-yet-committed test. What's weird is that all the other mipmaps (both >> smaller and larger) are fetched correctly. That bug has yet to be fixed, but >> who is using a stencil buffer with mipmaps anyway? :) > > This 4th level might be the usual switching point btw 2d tiled and 1d > tiled ... ie we think the hw is still using 2d while it switched to 1d > (or the other way around) > > Otherwise reviewed
Thanks. The 2D->1D switch takes place between the 1st and the 2nd mipmap, so the issue cannot be caused by that. It must be something else. Marek _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
