[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
copy).

Cheers,
Jerome


More information about the mesa-dev mailing list