Re: [Mesa-dev] nouveau 30bpp / deep color status

[Daniel Stone]

Hi,

On 8 March 2018 at 17:08, Ilia Mirkin  wrote:
> On Thu, Mar 8, 2018 at 11:57 AM, Mario Kleiner
>  wrote:
>> Under EGL there is matching of channel masks, so only X11+GLX is
>> problematic. Not sure if anything special would need to be done for
>> XWayland, haven't looked at that at all so far. Or the modesetting ddx,
>> which currently assumes xrgb ordering for 10 bit.
>
> For the modesetting ddx, it has to switch to drmAddFB2 so that it
> knows the exact format. No other way around that, unfortunately. But
> that'll require work, and I'm happy enough that xf86-video-nouveau
> works (as that is what I recommend to anyone who'll listen).

modesetting now uses AddFB2, as of relatively recently.

>> There are some from Daniel which unify the handling of formats inside egl,
>> not with any abgr2101010 definitions though. Indeed on master compositing
>> doesn't work for depth 30 windows. I have some patches that fix this, and
>> some hack for EGL/x11 compositing that seems to work. Will send them out
>> soon.
>
> D'oh! Those patches were definitely there. I guess they got dropped at
> some point. Daniel, can you resend those?

Oops. Is this X11 or Wayland compositing? I'll resend those two, but
it would probably be better to hold off merging them until you can
verify I haven't done anything stupid.

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

Re: [Mesa-dev] nouveau 30bpp / deep color status

[Ilia Mirkin]

On Thu, Mar 8, 2018 at 11:57 AM, Mario Kleiner
 wrote:
> Cc'ing mesa-dev, which was left out.
>
>
> On 03/05/2018 01:40 PM, Ilia Mirkin wrote:
>>
>> On Mon, Mar 5, 2018 at 2:25 AM, Mario Kleiner
>>  wrote:
>>> Afaics EGL does the right thing wrt. channelmask matching of EGLConfigs
>>> to
>>> DRIconfigs, so we could probably implement dri_loader_get_cap(screen,
>>> DRI_LOADER_CAP_RGBA_ORDERING) == TRUE for the EGL loaders.
>>>
>>> But for GLX it is not so easy or quick. I looked if i could make the
>>> servers
>>> GLX send proper channelmask attributes and Mesa parsing them, but there
>>> aren't any GLX tags defined for channel masks, and all other tags come
>>> from
>>> official GLX extension headers. I'm not sure what the proper procedure
>>> for
>>> defining new tags is? Do we have to define a new GLX extension for that
>>> and
>>> get it in the Khronos registry and then back into the server/mesa
>>> code-base?
>>
>>
>> Can all of this be solved by a healthy dose of "don't do that"? i.e.
>> make sure that the DDX only ever exposes one of these at a time? And
>> also make the mesa driver only expose one as a DISPLAY_TARGET?
>>
>
> Yes, if "don't do that" is consistently possible on all future drivers.

I don't think it'd be undue burden for a driver to have to decide on
one ordering which is The Way To Do It (tm) for that hw, even if the
hw supports both. Could also drop some logic into the glx thing to
always pick a specific one in case both are supported, and hopefully
the DDX would have identical logic.

> Under EGL there is matching of channel masks, so only X11+GLX is
> problematic. Not sure if anything special would need to be done for
> XWayland, haven't looked at that at all so far. Or the modesetting ddx,
> which currently assumes xrgb ordering for 10 bit.

For the modesetting ddx, it has to switch to drmAddFB2 so that it
knows the exact format. No other way around that, unfortunately. But
that'll require work, and I'm happy enough that xf86-video-nouveau
works (as that is what I recommend to anyone who'll listen).

>
>>>
>>> The current patches in mesa for XBGR also lack enablement pieces for EGL,
>>> Wayland and X11 compositing, but that's a different problem.
>>
>>
>> EGL/drm and EGL/wayland should be enabled (look at Daniel Stone's
>> patches from a short while back, also upstream now). kmscube (with
>> some patches that are upstream now) and weston both run OK for me. I
>> think EGL/x11 is iffy though - haven't played with it.
>>
>>-ilia
>>
>
> There are some from Daniel which unify the handling of formats inside egl,
> not with any abgr2101010 definitions though. Indeed on master compositing
> doesn't work for depth 30 windows. I have some patches that fix this, and
> some hack for EGL/x11 compositing that seems to work. Will send them out
> soon.

D'oh! Those patches were definitely there. I guess they got dropped at
some point. Daniel, can you resend those?

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

Re: [Mesa-dev] nouveau 30bpp / deep color status

[Mario Kleiner]

Cc'ing mesa-dev, which was left out.

On 03/05/2018 01:40 PM, Ilia Mirkin wrote:

On Mon, Mar 5, 2018 at 2:25 AM, Mario Kleiner
 wrote:

On 02/05/2018 12:50 AM, Ilia Mirkin wrote:


In case anyone's curious about 30bpp framebuffer support, here's the
current status:

Kernel:

Ben and I have switched the code to using a 256-based LUT for Kepler+,
and I've also written a patch to cause the addfb ioctl to use the
proper format. You can pick this up at:

https://github.com/skeggsb/linux/commits/linux-4.16 (note the branch!)
https://patchwork.freedesktop.org/patch/202322/

With these two, you should be able to use "X -depth 30" again on any
G80+ GPU to bring up a screen (as you could in kernel 4.9 and
earlier). However this still has some deficiencies, some of which I've
addressed:

xf86-video-nouveau:

DRI3 was broken, and Xv was broken. Patches available at:

https://github.com/imirkin/xf86-video-nouveau/commits/master

mesa:

The NVIDIA hardware (pre-Kepler) can only do XBGR scanout. Further the
nouveau KMS doesn't add XRGB scanout for Kepler+ (although it could).
Mesa was only enabled for XRGB, so I've piped XBGR through all the
same places:

https://github.com/imirkin/mesa/commits/30bpp



Wrt. mesa, those patches are now in master and i think we have a bit of a
problem under X11+GLX:

https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/dri/dri_screen.c#n108

dri_fill_in_modes() defines MESA_FORMAT_R10G10B10A2_UNORM,
MESA_FORMAT_R10G10B10X2_UNORM at the top inbetween the BGRX/A formats
ignoring the instructions that
"/* The 32-bit RGBA format must not precede the 32-bit BGRA format.
   * Likewise for RGBX and BGRX.  Otherwise, the GLX client and the GLX
   * server may disagree on which format the GLXFBConfig represents,
   * resulting in swapped color channels."

RGBA/X formats should only be exposed
if (dri_loader_get_cap(screen, DRI_LOADER_CAP_RGBA_ORDERING))

and that is only the case for the Android loader.

The GLX code doesn't use the red/green/blueChannelMasks for proper matching
of formats, and the server doesn't even transmit those masks to the client
in the case of GLX. So whatever 10 bit format comes first will win when
building the assignment to GLXFBConfigs.

I looked at the code and how it behaves. In practice Intel gfx works because
it's a classic DRI driver with its own method of building the DRIconfig's,
and it only exposes the BGR101010 formats, so no danger of mixups. AMD's
gallium drivers expose both BGR and RGB ordered 10 bit formats, but due to
the ordering, the matching ends up only assigning the desired BGR formats
that are good for AMD hw, discarding the RGB formats. nouveau works because
it only exposes the desired RGB format for the hw. But with other gallium
drivers for some SoC's or future gallium drivers it is not so clear if the
right thing will happen. E.g., freedreno seems to support both BGR and RGB
10 bit formats as PIPE_BIND_DISPLAY_TARGET afaics, so i don't know if by
luck the right thing would happen?


FWIW freedreno does not presently support 10bpc scanout.



Afaics EGL does the right thing wrt. channelmask matching of EGLConfigs to
DRIconfigs, so we could probably implement dri_loader_get_cap(screen,
DRI_LOADER_CAP_RGBA_ORDERING) == TRUE for the EGL loaders.

But for GLX it is not so easy or quick. I looked if i could make the servers
GLX send proper channelmask attributes and Mesa parsing them, but there
aren't any GLX tags defined for channel masks, and all other tags come from
official GLX extension headers. I'm not sure what the proper procedure for
defining new tags is? Do we have to define a new GLX extension for that and
get it in the Khronos registry and then back into the server/mesa code-base?


Can all of this be solved by a healthy dose of "don't do that"? i.e.
make sure that the DDX only ever exposes one of these at a time? And
also make the mesa driver only expose one as a DISPLAY_TARGET?



Yes, if "don't do that" is consistently possible on all future drivers. 
Under EGL there is matching of channel masks, so only X11+GLX is 
problematic. Not sure if anything special would need to be done for 
XWayland, haven't looked at that at all so far. Or the modesetting ddx, 
which currently assumes xrgb ordering for 10 bit.




The current patches in mesa for XBGR also lack enablement pieces for EGL,
Wayland and X11 compositing, but that's a different problem.


EGL/drm and EGL/wayland should be enabled (look at Daniel Stone's
patches from a short while back, also upstream now). kmscube (with
some patches that are upstream now) and weston both run OK for me. I
think EGL/x11 is iffy though - haven't played with it.

   -ilia



There are some from Daniel which unify the handling of formats inside 
egl, not with any abgr2101010 definitions though. Indeed on master 
compositing doesn't work for depth 30 windows. I have some patches that 
fix this, and some hack for EGL/x11 compositing that seems to work. Will