[Mesa-dev] [PATCH 20/26] radeonsi: disable DCC on handle export if expecting write access

[Marek Olšák]

On Thu, Mar 10, 2016 at 4:43 AM, Michel Dänzer <michel at daenzer.net> wrote:
> On 09.03.2016 20:29, Marek Olšák wrote:
>> On Wed, Mar 9, 2016 at 7:19 AM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
>>> On 02.03.2016 11:36, Marek Olšák wrote:
>>>>
>>>> @@ -318,6 +343,13 @@ static boolean r600_texture_get_handle(struct
>>>> pipe_screen* screen,
>>>>                 res->external_usage = usage;
>>>>
>>>>                 if (resource->target != PIPE_BUFFER) {
>>>> +                       /* Since shader image stores don't support DCC on
>>>> VI,
>>>> +                        * disable it for external clients that want write
>>>> +                        * access.
>>>> +                        */
>>>> +                       if (usage & PIPE_HANDLE_USAGE_WRITE)
>>>> +                               r600_texture_disable_dcc(rscreen, rtex);
>>>
>>>
>>> Have you considered keeping DCC enabled when the user sets the explicit
>>> flush flag and having flush_resource decompress for writably-shared
>>> resources?
>>
>> DCC decompression is a very costly operation and it's better to avoid
>> it if possible. Currently, DCC is only supported with non-displayable
>> surfaces, but all users of flush_resource (DRI2/3) only get
>> displayable surfaces. Thus, the driver doesn't have to worry about
>> flush_resource with DCC.
>
> I'm afraid it's not that simple. st/dri is used on Wayland as well, in
> which case buffers passed to flush_resource aren't generally
> displayable. See https://patchwork.freedesktop.org/patch/71713/ .

Yeah, I didn't take Wayland into account. I think it's broken, because
flush_resource doesn't decompress DCC, but we don't have to decompress
it if we set up DCC according to amdgpu metadata on handle import.

Marek