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

[Ilia Mirkin]

On Fri, Dec 1, 2017 at 12:54 AM, Mario Kleiner
<mario.kleiner.de at gmail.com> 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.