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