[Mesa-dev] [PATCH v2 6/7] radeonsi: Add DCC decompress.

[Bas Nieuwenhuizen]

Hi Axel,

Using DCC for scanout surfaces is problematic because as far as I
understand the display hardware does not support it. We could solve
that partially by decompressing when displaying.

However, the X server can also use these surfaces as a front buffer
and for that case we cannot just use decompression without performance
regressions for decompressing often.

Furthermore, when using such a surface as back buffer, we would still
need a single decompression before displaying it. It really depends on
the application whether that improves performances or regresses it.
For example, Xonotic regresses for me if I enable DCC for scanout
surfaces.

Yours sincerely,
Bas Nieuwenhuizen

On Mon, Oct 12, 2015 at 10:27 PM, Axel Davy <axel.davy at ens.fr> wrote:
> On 12/10/2015 17:05, Bas Nieuwenhuizen wrote:
>>
>> Hi Marek,
>>
>> Thanks for the quick review.
>>
>> I do not think I understand the sharing semantics. We currently have
>> fast clear for scanout surfaces with the CMASK and eliminate it on
>> flush resource. I would think we could do that similarly with DCC fast
>> clear. Both require a flush_resource after modifying the resource
>> before other applications can use it.
>>
>> Furthermore, if we disable DCC for image stores, we also need to
>> communicate that. We could leave DCC enabled for sampling as long as
>> the DCC buffer stays in decompressed state. But we would need to
>> communicate that DCC should not be used anymore for rendering.
>>
>> Do we still want patch 6 and 7 or should I drop them until we have an
>> actual user?
>>
>> Yours sincerely,
>> Bas Nieuwenhuizen
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
> Hi,
>
> I think it would be better perf wise to not disable DCC for the backbuffer
> (which
> is both shared and scanout currently). Decompressing anything that needs to
> be decompressed
> in flush_resource seems to me a good idea.
>
> For dx9 apps, it seems the applications do render a lot of draw calls to the
> backbuffer directly.
> Likely having the backbuffer compressed with DCC (after it's been cleared),
> and then decompressing
> before sending it should - I guess - be faster than keeping it uncompressed.
> I don't know for gl apps, but I guess it's the same than dx9.
>
> I tested the current serie, and it seems to boost some apps.
>
> Yours,
>
> Axel