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@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
