On Thu, Dec 20, 2018, 4:05 AM Bas Nieuwenhuizen On Thu, Dec 20, 2018 at 9:00 AM Marek Olšák wrote:
> >
> > I prefer Nicolai's patch because it's shorter and doesn't need driver
> changes.
> >
> > Reviewed-by: Marek Olšák
>
> This patch still needs driver changes because radv will render to a
>
On Thu, Dec 20, 2018 at 9:00 AM Marek Olšák wrote:
>
> I prefer Nicolai's patch because it's shorter and doesn't need driver changes.
>
> Reviewed-by: Marek Olšák
This patch still needs driver changes because radv will render to a
compressed surface as r32g32b32a32, so allocating a
I prefer Nicolai's patch because it's shorter and doesn't need driver
changes.
Reviewed-by: Marek Olšák
Marek
On Tue, Dec 18, 2018 at 12:50 PM Haehnle, Nicolai
wrote:
> On 18.12.18 18:36, Bas Nieuwenhuizen wrote:
> > Hi Nicolai,
> >
> > I happened to be writing something similar which also
On 18.12.18 18:36, Bas Nieuwenhuizen wrote:
> Hi Nicolai,
>
> I happened to be writing something similar which also fixes up radv to
> never render to those surfaces as r32g32b32a32:
> https://patchwork.freedesktop.org/series/54172/ I can split out the
> radv specific stuff and this one is r-b
Hi Nicolai,
I happened to be writing something similar which also fixes up radv to
never render to those surfaces as r32g32b32a32:
https://patchwork.freedesktop.org/series/54172/ I can split out the
radv specific stuff and this one is r-b after than.
Thanks,
Bas
On Tue, Dec 18, 2018 at 5:37 PM
From: Nicolai Hähnle
In the gfx9 addrlib, this bit has been clarified as meaning that
the surface can be used as a color buffer (render target).
Setting this for compressed surfaces triggers a workaround that
is only required for surfaces that can be render targets, and ends
up breaking the
