On Thu, Mar 10, 2016 at 4:43 AM, Michel Dänzer <[email protected]> wrote: > On 09.03.2016 20:29, Marek Olšák wrote: >> On Wed, Mar 9, 2016 at 7:19 AM, Nicolai Hähnle <[email protected]> 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 _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
