Bug 92759 - Visuals without alpha bits are not sRGB-capable
Summary: Visuals without alpha bits are not sRGB-capable
Status: NEW
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Intel 3D Bugs Mailing List
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords: bisected, regression
: 91817 (view as bug list)
Depends on:
Blocks: 93185
  Show dependency treegraph
 
Reported: 2015-10-31 21:10 UTC by Deve
Modified: 2016-11-03 21:51 UTC (History)
6 users (show)

See Also:
i915 platform:
i915 features:


Attachments
intel_mesa_10_3.png (837.92 KB, image/png)
2015-10-31 21:10 UTC, Deve
Details
intel_mesa_current-git.png (511.89 KB, image/png)
2015-10-31 21:11 UTC, Deve
Details
Possible fix (1.90 KB, patch)
2015-11-01 15:58 UTC, Deve
Details | Splinter Review
full backtrace (1.70 KB, text/plain)
2015-12-15 16:18 UTC, Christoph Haag
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Deve 2015-10-31 21:10:11 UTC
Created attachment 119319 [details]
intel_mesa_10_3.png

Look at the screenshots.
- intel_mesa_10_3.png file shows what is expected. It is working with intel using mesa 10.3.2 and also with proprietary nvidia/amd graphics drivers.
- intel_mesa_current-git.png shows how it looks now with intel in current mesa git 0ef8c5cb96f6b1fea7c18c25fbff2adb6d7d0736

It looks like a regression in mesa. I can bisect it if I'll find a time.

My system information:
Intel HD4000 (Ivybridge)
Ubuntu 15.10 + Gnome 3.16
mesa 11.0.2
libdrm 2.4.64
xserver 1.17.2
xserver-xorg-video-intel 2.99.917~git20150808
supertuxkart 0.9.1

Note that you need at least SuperTuxKart 0.9 to reproduce this issue because we are using new OpenGL 3.x based renderer since this version.
Comment 1 Deve 2015-10-31 21:11:19 UTC
Created attachment 119320 [details]
intel_mesa_current-git.png
Comment 2 Deve 2015-11-01 14:56:33 UTC
28090b30dd6b5977de085f48c620574214b6b4ba is the first bad commit
commit 28090b30dd6b5977de085f48c620574214b6b4ba
Author: Boyan Ding <boyan.j.ding@gmail.com>
Date:   Wed Mar 25 19:36:54 2015 +0800

    i965: Add XRGB8888 format to intel_screen_make_configs
    
    Some application, such as drm backend of weston, uses XRGB8888 config as
    default. i965 doesn't provide this format, but before commit 65c8965d,
    the drm platform of EGL takes ARGB8888 as XRGB8888. Now that commit
    65c8965d makes EGL recognize format correctly so weston won't start
    because it can't find XRGB8888. Add XRGB8888 format to i965 just as
    other drivers do.
    
    Cc: mesa-stable@lists.freedesktop.org
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89689
    Signed-off-by: Boyan Ding <boyan.j.ding@gmail.com>
    Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>

:040000 040000 41945dd2e2e4047be7417025d77b3354298a195f f52a53e65e46a5867a34b37884ab505f61a0410d M	src
Comment 3 Deve 2015-11-01 15:58:16 UTC
Created attachment 119324 [details] [review]
Possible fix
Comment 4 Deve 2015-11-01 16:03:44 UTC
I'm not an mesa exprert, but this patch solves the issue.
Comment 5 Emil Velikov 2015-12-07 20:14:12 UTC
Deve the patch looks great imho. Can you please set your full name in git, add a couple of tags in the commit message and git send-email it to the mailing list mesa-dev@lists.freedesktop.org

Thanks

The tags

Cc: Boyan Ding <boyan.j.ding@gmail.com>
Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org>
Fixes: 28090b30dd6 "i965: Add XRGB8888 format to intel_screen_make_configs"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92759
Comment 6 Deve 2015-12-08 10:35:47 UTC
Already sent to mesa-dev@lists.freedesktop.org. It should be waiting for moderator approval now.
Comment 7 Deve 2015-12-09 22:27:30 UTC
I was digging around this bug a bit. Thanks to Ilia Mirkin for the help. Here is what I noticed:

1. This patch doesn't have a sense.

2. During looking at Supertuxkart code, I noticed that we need srgb-capable visual for proper working. 

3. The difference in intel code, which causes this issue is in intel_screen.c in intelCreateBuffer() function:

   if (mesaVis->redBits == 5)
      rgbFormat = MESA_FORMAT_B5G6R5_UNORM;
   else if (mesaVis->sRGBCapable)
      rgbFormat = MESA_FORMAT_B8G8R8A8_SRGB;
   else if (mesaVis->alphaBits == 0)
      rgbFormat = MESA_FORMAT_B8G8R8X8_UNORM;
   else {
      rgbFormat = MESA_FORMAT_B8G8R8A8_SRGB;
      fb->Visual.sRGBCapable = true;
   }

Before commit 28090b30dd6b5977de085f48c620574214b6b4ba the format MESA_FORMAT_B8G8R8X8_UNORM was not available, and thus it was using MESA_FORMAT_B8G8R8A8_SRGB format (which is srgb-capable). Now it is using MESA_FORMAT_B8G8R8X8_UNORM format, and thus function

    glEnable(GL_FRAMEBUFFER_SRGB) 

doesn't take effect anymore.

4. I tried to force to use srgb-capable visual by setting GLX_FRAMEBUFFER_SRGB_CAPABLE_ARB in supertuxkart code with glxChooseFBConfig function, but it doesn't take any effect.

5. The ugly workaround for this issue in supertuxkart code, is to request GLX_ALPHA_SIZE > 0. It will fallback to last case in intel code, which I mentioned upwards:

      rgbFormat = MESA_FORMAT_B8G8R8A8_SRGB;
      fb->Visual.sRGBCapable = true;

6. The bug 91817 (https://bugs.freedesktop.org/show_bug.cgi?id=91817) seems to be related to this bug.


Is there a proper way to force using srgb-capable visual?
Comment 8 Neil Roberts 2015-12-11 12:49:39 UTC
Many thanks for the detailed bug report and all the research into the problem.

I think this is a problem with Mesa in that we should be using an sRGB-capable visual even if no alpha bits are requested. It's not possible to force Mesa to give you an sRGB-capable visual because apparently we don't advertise any, but then we use sRGB formats internally anyway. I've posted a patch which should fix this here:

http://patchwork.freedesktop.org/patch/67844/

Arguably there is a bug in supertuxkart too because perhaps it shouldn't assume it always gets an sRGB visual and it should fall back if one isn't available. However in practice if we fix this bug in Mesa then there's probably no cases where that would happen except for the broken Mesa versions.
Comment 9 Neil Roberts 2015-12-11 14:49:06 UTC
*** Bug 91817 has been marked as a duplicate of this bug. ***
Comment 10 Neil Roberts 2015-12-13 14:33:25 UTC
I've pushed the patches to master.

http://cgit.freedesktop.org/mesa/mesa/commit/?id=839793680f99b8387bee9489733d5
Comment 11 Andreas Reis 2015-12-15 13:16:37 UTC
On my Haswell 4770, that commit (8397936) causes mpv to crash on playing a h.264 file (opengl-hq vo driver), and Steam to crash on start, both with a segfault in i965_dri.so.

Tested by reverting it from current mesa-git (10b7a7c).
Comment 12 Andreas Reis 2015-12-15 13:28:29 UTC
From mpv. Should add that I'm on drm-intel-nightly.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffce7fc700 (LWP 14818)]
0x00007fffcd39f36a in brw_meta_fast_clear (brw=brw@entry=0x7fffbc34a0a8, fb=fb@entry=0x7fffbc349170, buffers=buffers@entry=2, partial_clear=partial_clear@entry=false) at brw_meta_fast_clear.c:587
warning: Source file is more recent than executable.
587           clear_type = FAST_CLEAR;
(gdb) bt
#0  0x00007fffcd39f36a in brw_meta_fast_clear (brw=brw@entry=0x7fffbc34a0a8, fb=fb@entry=0x7fffbc349170, buffers=buffers@entry=2, partial_clear=partial_clear@entry=false) at brw_meta_fast_clear.c:587
#1  0x00007fffcd385ef0 in brw_clear (ctx=0x7fffbc34a0a8, mask=2) at brw_clear.c:244
#2  0x00000000004c3df5 in gl_video_render_frame (p=0x7fffbd3379d0, frame=frame@entry=0x7fffbd776a00, fbo=fbo@entry=0) at ../video/out/opengl/video.c:2157
#3  0x00000000004cd054 in draw_frame (vo=<optimized out>, frame=0x7fffbd776a00) at ../video/out/vo_opengl.c:138
#4  0x00000000004c9e3a in render_frame (vo=0x813b80) at ../video/out/vo.c:808
#5  vo_thread (ptr=0x813b80) at ../video/out/vo.c:905
#6  0x00007ffff7bc54a4 in start_thread () from /lib/libpthread.so.0
#7  0x00007fffef20f13d in clone () from /usr/lib/libc.so.6
Comment 13 Christoph Haag 2015-12-15 16:18:24 UTC
Created attachment 120529 [details]
full backtrace

On ivy bridge everything from glxgears to kwin segfaults with this commit for me. Here's a backtrace for glxgears.
Comment 14 Deve 2015-12-15 16:33:28 UTC
I didn't check it on other applications, but now STK is not able to compile some shaders. The problem is in this line:

uniform layout(r16f) volatile restrict writeonly image2D dest;

The "r16f" format is not recognized.

Log from console:

[warn   ] GLWrap: OpenGL debug callback - SHADER_COMPILER
[warn   ] GLWrap:     Error type : ERROR
[warn   ] GLWrap:     Severity : HIGH
[warn   ] GLWrap:     Message : 0:78(16): error: unrecognized layout identifier `r16f'
[error  ] GLWrap: Error in shader bilateralH.comp
[error  ] GLWrap: 0:78(16): error: unrecognized layout identifier `r16f'


But this is sepearate issue. Perhaps MESA_FORMAT_B8G8R8X8_SRGB is not handled properly somewhere (it has been added recently).
Comment 15 Neil Roberts 2015-12-16 17:41:54 UTC
I've reverted the last patch because it caused bug 93388 and a complete fix wouldn't be trivial. To fix this properly we probably need to add some new constants to the DRI interface.

I'm assuming the thing about not being able to compile some shaders is a separate issue.


bug/show.html.tmpl processed on Feb 24, 2017 at 01:42:11.
(provided by the Example extension).