[Mesa-dev] RGB10 bit rendering support for OpenGL + Intel i965

[Tapani Pälli]

Hi;

On 09/05/2017 08:01 AM, Mario Kleiner wrote:
> Hi,
> 
> this patch series adds support to the i965 classic Mesa driver for
> ARGB2101010 and XRGB2101010 fbconfigs/visuals for X11/GLX, X11/EGL
> and Wayland/EGL, and for rendering into those winsys framebuffers
> with 10 bpc precision.

FYI I believe dEQP has some wide_color tests like:
dEQP-EGL.functional.wide_color.window_1010102_colorspace_default

> Tested hw/sw configs on top of Ubuntu 16.04.3 LTS, on top of mesa master:
> 
> Tested on Intel Ironlake (gen5), Ivybridge (gen7), Haswell (gen7.5).
> Lightly tested on Skylake (visual correctness, no time for piglit runs).
> 
> Tested with the intel ddx (X-Server 1.18.4 and 1.19.3) with
> sna and uxa backends, DRI2 and DRI3/Present, with and without
> compositing (when a choice was possible, e.g., under KDE-5),
> for default X-Screen depth of 24 bit and then DefaultDepth 30 bit.
> 
> Also tested with the modesetting ddx under depth 24 -- modesetting
> doesn't support depth 30 yet.
> 
> Tested with KDE Plasma-5, Compiz based UI's and Gnome flashback
> (Metacity), and with Gnome Shell X11 and Wayland.
> 
> Mesa "make check" passes.
> 
> "piglit run gpu" results:
> 
> Mesa vs. Mesa with these patches: No regressions under depth 24,
> except for glx-visuals-depth and glx-visuals-stencil. Both turned
> out to be problems in the piglit tests, for which i'll send out a
> patch.
> 
> Mesa with 10 bit patches under X-Screen depth 24 vs. 30 shows another
> fail in egl-configless-context due to limitations of that test,
> for which i'll send a patch. Other than that, a couple of skipped tests.
> 
> If i make those tests not skip, i get some failures due to various tests
> assuming the alpha channel is at least 8 bits deep, when here it is only
> 2 bits. Also some glean tests fail due to slightly insufficient precision.
> 
> glxgears, es2gears, glmark work. My own application works I also have
> some kernel patches for intel-kms in preparation to get XRGB2101010
> framebuffers displayed with 10 bpc, and measurements with a photometer
> and my own application confirm we get 10 bpc from OpenGL rendering to the
> display on X11 with/without compositing, windowed or unredirected
> page-flipped.
> 
> I also tested Wayland + Weston master, with gbm-format=xrgb2101010 for
> 10 bit framebuffer. First "as is" with the experimental dmabuf+modifiers
> path, and then hacked to use the old WL_BUFFER import path. Both works
> and photometer measurement shows 10 bpc from rendering to display.
> 
> Visually all tested desktop UI's seem to render correctly in X-Screen
> depth 30 (save for some minor funky colors in window decorations with
> some toolkits if desktop compositing is disabled under KDE-5), also
> under Wayland + Weston.
> 
> The exception is Gnome-Shell. Gnome-Shell Wayland shows funky false
> colors. This is due to limitations in Mutters/COGL drm/kms backend,
> which assumes any content is argb8888 / xrgb8888 and doesn't check
> for mismatch. Gnome-Shell X11 displays all content visually correct.
> 
> Both Gnome-Shell Wayland and X11 though don't respond to mouse clicks
> on desktop icons, elements in the menu bar or dock, on window decorations,
> or right-click context menus on the desktop, although the mouse works
> just fine inside the client area of X11 windows. It's as if somehow
> hit-testing doesn't work when RGBA1010102 configs are exposed? The same

IIRC some years back clutter used to do hit-testing so that it rendered 
each object to offscreen buffer as a color rectangle (each object having 
unique color) and then determining which object got hit by reading color 
value from the mouse cursor position. If this is still the technique in 
use, it might be that it's expecting particular type when assigning and 
reading those colors.

> problem also happens under X-Screen color depth 30 with NVidia's proprietary
> graphics drivers, and under AMD's amdgpu-pro hybrid driver, so it doesn't
> seem to be a bug specific to this patch series or X11 vs. Wayland, but
> some Gnome-Shell problem? I didn't manage to track it down, but this series
> includes a new driconf option to prevent exposing 10 bpc configs to clients
> and a default driconf black-list entry for gnome-shell for the moment.
> 
> All in all the patch series seems to work well. If this looks about right
> to you, i'd also give the gallium drivers a try for 10 bit enablement.
> 
> Thanks,
> -mario
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>