Re: [Mesa-dev] [PATCH 20/22] nv50, nvc0: Support BGRX1010102 format for visuals.

2017-12-01 Thread Ilia Mirkin 
On Fri, Dec 1, 2017 at 12:54 AM, Mario Kleiner
 wrote:
> On 11/29/2017 04:38 PM, Ilia Mirkin wrote:
>>
>> Why is this required? Can't you just use the BGR10_A2 format directly?
>>
>
> If i don't define this PIPE_FORMAT_B10G10R10X2_UNORM as "TD" = displayable,
> then it doesn't get exposed by the state tracker as a visual/fbconfig with
> RGBA = 10 10 10 0 under nouveau.
>
> Wayland's Weston doesn't like that at all and gives a screen with pixel
> trash instead of a proper desktop, probably because it falls back to a
> BGRA1010102 format with alpha channel, that might indeed be zero.
>
> On X11, all redirected/composited rendering only gives a black window client
> area, e.g., glxgears ends up as a black rectangle.
>
> With the patch i get proper Weston display, and proper composited X11.
> "Proper" within the limitations imposed by my hacks + tbd work on the ddx
> and kms driver.
>
>> The problem with exposing these sorts of formats is that blending with
>> DST_ALPHA would be incorrect -- it should get read in as 1.0, but will
>> end up with bogus values.
>
>
> Hm. My own application uses DST_ALPHA and ONE_MINUS_DST_ALPHA blending on
> the window system backbuffer in some demos and it seems to work fine on
> nouveau in depth 30 from what i can see. Not sure if this is due to the way
> my demos handle this though and there might be other cases that misbehave
> like you describe.
>
> Unfortunately nv50/g80_defs.xml.h doesn't define a BGR10 surface format
> without alpha channel.

Right. There is no such format - it's not supported. Normally the
state tracker works around hardware limitations like that rather than
the driver exposing things it can't do. OTOH we could have a fixup for
blending in nv50 and nvc0 to support this (we probably should anyways
for RGB10 support, which suffers from a similar issue, and is not
worked around by st/mesa's blending logic... this presents various
difficulties for hardware that can't do independent blend but can do
MRTs like the first half of the tesla generation).

My guess is that your application will run into trouble if you start
outputting non-1.0 alpha values from your shader - instead of just
blending, it'll get stored, and then on the next blend it'll come out
as that value rather than 1.0.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 20/22] nv50, nvc0: Support BGRX1010102 format for visuals.

2017-11-30 Thread Mario Kleiner 

On 11/29/2017 04:38 PM, Ilia Mirkin wrote:

Why is this required? Can't you just use the BGR10_A2 format directly?



If i don't define this PIPE_FORMAT_B10G10R10X2_UNORM as "TD" = 
displayable, then it doesn't get exposed by the state tracker as a 
visual/fbconfig with RGBA = 10 10 10 0 under nouveau.


Wayland's Weston doesn't like that at all and gives a screen with pixel 
trash instead of a proper desktop, probably because it falls back to a 
BGRA1010102 format with alpha channel, that might indeed be zero.


On X11, all redirected/composited rendering only gives a black window 
client area, e.g., glxgears ends up as a black rectangle.


With the patch i get proper Weston display, and proper composited X11. 
"Proper" within the limitations imposed by my hacks + tbd work on the 
ddx and kms driver.



The problem with exposing these sorts of formats is that blending with
DST_ALPHA would be incorrect -- it should get read in as 1.0, but will
end up with bogus values.


Hm. My own application uses DST_ALPHA and ONE_MINUS_DST_ALPHA blending 
on the window system backbuffer in some demos and it seems to work fine 
on nouveau in depth 30 from what i can see. Not sure if this is due to 
the way my demos handle this though and there might be other cases that 
misbehave like you describe.


Unfortunately nv50/g80_defs.xml.h doesn't define a BGR10 surface format 
without alpha channel.


-mario



Cheers,

   -ilia

On Tue, Nov 28, 2017 at 11:21 PM, Mario Kleiner
 wrote:

Add it as displayable/scanout capable, so it can be
exposed as valid visual/fbconfig.

Signed-off-by: Mario Kleiner 
---
  src/gallium/drivers/nouveau/nv50/nv50_formats.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/nouveau/nv50/nv50_formats.c 
b/src/gallium/drivers/nouveau/nv50/nv50_formats.c
index 706c34f..f2f9a4f 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_formats.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_formats.c
@@ -154,6 +154,7 @@ const struct nv50_format 
nv50_format_table[PIPE_FORMAT_COUNT] =

 C4(A, R10G10B10A2_UNORM, RGB10_A2_UNORM, R, G, B, A, UNORM, A2B10G10R10, 
IB),
 C4(A, B10G10R10A2_UNORM, BGR10_A2_UNORM, B, G, R, A, UNORM, A2B10G10R10, 
TD),
+   F3(A, B10G10R10X2_UNORM, BGR10_A2_UNORM, B, G, R, xx, UNORM, A2B10G10R10, 
TD),
 C4(A, R10G10B10A2_SNORM, NONE, R, G, B, A, SNORM, A2B10G10R10, T),
 C4(A, B10G10R10A2_SNORM, NONE, B, G, R, A, SNORM, A2B10G10R10, T),
 C4(A, R10G10B10A2_UINT, RGB10_A2_UINT, R, G, B, A, UINT, A2B10G10R10, TR),
--
2.7.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 20/22] nv50, nvc0: Support BGRX1010102 format for visuals.

2017-11-29 Thread Ilia Mirkin 
Why is this required? Can't you just use the BGR10_A2 format directly?

The problem with exposing these sorts of formats is that blending with
DST_ALPHA would be incorrect -- it should get read in as 1.0, but will
end up with bogus values.

Cheers,

  -ilia

On Tue, Nov 28, 2017 at 11:21 PM, Mario Kleiner
 wrote:
> Add it as displayable/scanout capable, so it can be
> exposed as valid visual/fbconfig.
>
> Signed-off-by: Mario Kleiner 
> ---
>  src/gallium/drivers/nouveau/nv50/nv50_formats.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/gallium/drivers/nouveau/nv50/nv50_formats.c 
> b/src/gallium/drivers/nouveau/nv50/nv50_formats.c
> index 706c34f..f2f9a4f 100644
> --- a/src/gallium/drivers/nouveau/nv50/nv50_formats.c
> +++ b/src/gallium/drivers/nouveau/nv50/nv50_formats.c
> @@ -154,6 +154,7 @@ const struct nv50_format 
> nv50_format_table[PIPE_FORMAT_COUNT] =
>
> C4(A, R10G10B10A2_UNORM, RGB10_A2_UNORM, R, G, B, A, UNORM, A2B10G10R10, 
> IB),
> C4(A, B10G10R10A2_UNORM, BGR10_A2_UNORM, B, G, R, A, UNORM, A2B10G10R10, 
> TD),
> +   F3(A, B10G10R10X2_UNORM, BGR10_A2_UNORM, B, G, R, xx, UNORM, A2B10G10R10, 
> TD),
> C4(A, R10G10B10A2_SNORM, NONE, R, G, B, A, SNORM, A2B10G10R10, T),
> C4(A, B10G10R10A2_SNORM, NONE, B, G, R, A, SNORM, A2B10G10R10, T),
> C4(A, R10G10B10A2_UINT, RGB10_A2_UINT, R, G, B, A, UINT, A2B10G10R10, TR),
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 20/22] nv50, nvc0: Support BGRX1010102 format for visuals.

2017-11-28 Thread Mario Kleiner 
Add it as displayable/scanout capable, so it can be
exposed as valid visual/fbconfig.

Signed-off-by: Mario Kleiner 
---
 src/gallium/drivers/nouveau/nv50/nv50_formats.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/nouveau/nv50/nv50_formats.c 
b/src/gallium/drivers/nouveau/nv50/nv50_formats.c
index 706c34f..f2f9a4f 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_formats.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_formats.c
@@ -154,6 +154,7 @@ const struct nv50_format 
nv50_format_table[PIPE_FORMAT_COUNT] =
 
C4(A, R10G10B10A2_UNORM, RGB10_A2_UNORM, R, G, B, A, UNORM, A2B10G10R10, 
IB),
C4(A, B10G10R10A2_UNORM, BGR10_A2_UNORM, B, G, R, A, UNORM, A2B10G10R10, 
TD),
+   F3(A, B10G10R10X2_UNORM, BGR10_A2_UNORM, B, G, R, xx, UNORM, A2B10G10R10, 
TD),
C4(A, R10G10B10A2_SNORM, NONE, R, G, B, A, SNORM, A2B10G10R10, T),
C4(A, B10G10R10A2_SNORM, NONE, B, G, R, A, SNORM, A2B10G10R10, T),
C4(A, R10G10B10A2_UINT, RGB10_A2_UINT, R, G, B, A, UINT, A2B10G10R10, TR),
-- 
2.7.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev