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

Wed Sep 6 08:40:17 UTC 2017

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

Thanks 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_default
wants 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?

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

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.

-mario

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