[Mesa-dev] [PATCH] r600g: add in-place DB decompression and texturing with DB tiling

[Marek Olšák]

On Thu, Oct 4, 2012 at 4:06 PM, Jerome Glisse <j.glisse at gmail.com> wrote:
> On Wed, Oct 3, 2012 at 5:50 PM, Marek Olšák <maraeo at gmail.com> 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