[Mesa-dev] [PATCH] r600g: improve flushed depth texture handling v2

Jerome Glisse j.glisse at gmail.com
Tue Jul 10 18:02:04 PDT 2012

On Tue, Jul 10, 2012 at 5:16 PM, Marek Olšák <maraeo at gmail.com> wrote:
> On Tue, Jul 10, 2012 at 10:00 PM, Jerome Glisse <j.glisse at gmail.com> wrote:
>> On Tue, Jul 10, 2012 at 2:10 PM, Marek Olšák <maraeo at gmail.com> wrote:
>>> On Tue, Jul 10, 2012 at 6:40 AM, Vadim Girlin <vadimgirlin at gmail.com> wrote:
>>>> On Sat, 2012-07-07 at 01:48 +0200, Marek Olšák wrote:
>>>>> On Wed, Jun 27, 2012 at 1:34 AM, Vadim Girlin <vadimgirlin at gmail.com> wrote:
>>>>> > Use r600_resource_texture::flished_depth_texture for GPU access, and
>>>>> > allocate it in the VRAM. For transfers we'll allocate untiled texture in the
>>>>> > GTT and store it in the r600_transfer::staging.
>>>>> >
>>>>> > Improves performance when flushed depth texture is frequently used by the
>>>>> > GPU (about 30% for Lightsmark).
>>>>> >
>>>>> > Signed-off-by: Vadim Girlin <vadimgirlin at gmail.com>
>>>>> > ---
>>>>> >
>>>>> > Fixes fbo-clear-formats, fbo-generatemipmap-formats, no regressions on
>>>>> > evergreen
>>>>> Hi,
>>>>> is there any reason this patch hasn't been committed yet?
>>>> Hi,
>>>> I have some doubts because it was benchmarked by phoronix and there were
>>>> regressions, though I suspect that something is wrong with the results:
>>>> http://www.phoronix.com/scan.php?page=article&item=amd_r600g_texdepth&num=4
>>>> I was going to look into it but had no time yet. I'd like to be sure
>>>> that there are no regressions before committing.
>>> Well, there's nothing wrong with your patch. I wouldn't trust
>>> benchmarks run with the Unity desktop so much. I myself had to switch
>>> from Unity 2D to Xfce just to get consistent results when testing
>>> performance.
>>> Now that your patch separates flushing for texturing and transfers, I
>>> think we could make it a little bit faster by imlementing an in-place
>>> flush for texturing (that is without having to allocate another
>>> resource).
>>> Marek
>> In place flush are useful for the case where you know you wont reuse
>> the depth buffer as a depth buffer, or if you know next operation will
>> be a gClear on the depth buffer. What i am worried about is that
>> recompression might not work in place, for it to work you need to have
>> db decompressed into db tiling format and not cb tiling format.
> The case where the depth is not reused is the most common one. It
> might even be the only one in practice. Depth textures are most
> commonly used for shadow mapping, which is the not-reusing case. They
> can also be used to implement deferred rendering (though that's not
> very common), which means the same as shadow mapping for us. Actually,
> no graphics algorithm comes to mind that would do write-texture-write
> with the same depth buffer.
> Marek

I am not saying it's not the most common one, i am saying that
recompressing might be more complex (recompress to different buffer
then copy back to original buffer, or copy buffer and uncompress from


More information about the mesa-dev mailing list