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

[Marek Olšák]

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