On Tue, Oct 13, 2015 at 2:19 AM, Marek Olšák wrote:
> On Mon, Oct 12, 2015 at 5:05 PM, 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 elimin
On Mon, Oct 12, 2015 at 10:27 PM, Axel Davy wrote:
> 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
>>
On Mon, Oct 12, 2015 at 5:05 PM, 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 simi
On 13/10/2015 00:42, Bas Nieuwenhuizen wrote:
Hi Axel,
Using DCC for scanout surfaces is problematic because as far as I
understand the display hardware does not support it. We could solve
that partially by decompressing when displaying.
However, the X server can also use these surfaces as a fr
Hi Axel,
Using DCC for scanout surfaces is problematic because as far as I
understand the display hardware does not support it. We could solve
that partially by decompressing when displaying.
However, the X server can also use these surfaces as a front buffer
and for that case we cannot just use
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
cle
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 modifyin
On Sun, Oct 11, 2015 at 5:38 PM, Bas Nieuwenhuizen
wrote:
> This is currently not needed but will be necessary when we have
> features that do not work with DCC enabled, such as image stores
> and sharing non-scanout surfaces.
For shared non-scanout surfaces, the plan is:
- allocate DCC as part o
This is currently not needed but will be necessary when we have
features that do not work with DCC enabled, such as image stores
and sharing non-scanout surfaces.
Signed-off-by: Bas Nieuwenhuizen
---
src/gallium/drivers/radeonsi/si_blit.c | 31 +--
src/gallium/driver
