Re: nouveau 30bpp / deep color status

[Ilia Mirkin <imirkin-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>]

On Mon, Mar 5, 2018 at 2:25 AM, Mario Kleiner
<mario.kleiner.de@gmail.com> 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?

>
> 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
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau