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

Wed Sep 6 10:46:04 UTC 2017


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

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