On Mon, Mar 5, 2018 at 2:25 AM, Mario Kleiner <mario.kleiner.de@xxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
