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

[Marek Olšák]

On Tue, Oct 13, 2015 at 2:19 AM, Marek Olšák <maraeo at gmail.com> wrote:
> On Mon, Oct 12, 2015 at 5:05 PM, Bas Nieuwenhuizen
> <bas at basnieuwenhuizen.nl> 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.
>
> I meant not using fast clear for shared textures, so flush_resource
> would be a no-op. We can't use fast clear for shared textures, because
> we can't communicate clear color changes between processes.
>
>>
>> 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.
>
> Image stores are the only big problem preventing DCC sharing. If we
> share textures with DCC enabled, we can't disable it, which means we
> have to decompress before image stores are used, which can result in
> performance that is worse than without DCC.

I've been thinking about this and I propose the following solution:
1) If a texture isn't shared, decompress and disable DCC permanently
for that texture when we get a shader with an image store.
2) If a texture is shared, decompress before it's used by image
stores, but don't disable DCC. This case shouldn't occur and we should
avoid using image stores for 2D acceleration.

A side note: DCC and SDMA are mutually exclusive, so we must choose
carefully which one we're going to use for 2D acceleration. I'll leave
that decision to Michel. If we decide to use DCC for 2D accel, SDMA
image blit support will be pretty useless on VI.

Marek