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/ . -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
