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

[Mario Kleiner]

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.

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
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