On 09/06/2017 11:40 AM, Mario Kleiner wrote:
On 09/05/2017 10:10 AM, Tapani Pälli wrote: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_defaultThanks for the hint. I've tried that test case now on Ivybridge. It passes for screen color depth 30 bit, but only if i apply the following additional patch to Mesa:diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c index 039762a..a3b617d 100644 --- a/src/mesa/main/framebuffer.c +++ b/src/mesa/main/framebuffer.c @@ -889,6 +889,9 @@ _mesa_get_color_read_type(struct gl_context *ctx, if (format == MESA_FORMAT_B5G6R5_UNORM) return GL_UNSIGNED_SHORT_5_6_5; + if (format == MESA_FORMAT_B10G10R10A2_UNORM) + return GL_UNSIGNED_INT_2_10_10_10_REV; + switch (data_type) { case GL_SIGNED_NORMALIZED: return GL_BYTE;This exposes GL_RGBA + GL_UNSIGNED_INT_2_10_10_10_REV as additional valid glReadPixels() format+type combo under GLES-3 via the GL_IMPLEMENTATION_COLOR_READ_TYPE_OES query.dEQP-EGL.functional.wide_color.window_1010102_colorspace_defaultwants that combo. Otherwise glReadPixels would fail with invalid_operation error.Desktop GL glReadPixels() supports that combo, as does the GLES < 3.0 path for glReadPixels(). For GLES-3.x it would support internalFormat GL_RGB10_A2 + GL_UNSIGNED_INT_2_10_10_10_REV, but internalFormat GL_RGB10_A2 isn't supported anywhere for winsys renderbuffers afaics. The i965 intel_create_winsys_renderbuffer() function always sets internalFormat = base format for the drawable, ie. == GL_RGBA and the comments in the code suggest this is done for a good reason.Probably makes sense to add above patch to the series?
Yes, this makes sense and is per spec ("Additionally, when the internal format of the rendering surface is RGB10_A2 , a third combination of format RGBA and type UNSIGNED_INT_2_10_10_10_REV is accepted.")
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 only2 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 photometerand my own application confirm we get 10 bpc from OpenGL rendering to thedisplay 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 clickson 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 sameIIRC 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.That would totally explain it, thank you! I also found bug reports from early 2015 in Debians bug tracker (#775030), and iirc older ones in other distros bug tracker, describing the same symptoms for depth 30, so probably this is still implemented that way.-marioproblem 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'tseem to be a bug specific to this patch series or X11 vs. Wayland, butsome 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 clientsand 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 rightto 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
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
