Created attachment 119320 [details]
intel_mesa_current-git.png

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

Created attachment 119324 [details] [review]
Possible fix

I'm not an mesa exprert, but this patch solves the issue.

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

Already sent to mesa-dev@lists.freedesktop.org. It should be waiting for moderator approval now.

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?

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.

*** Bug 91817 has been marked as a duplicate of this bug. ***

I've pushed the patches to master.

http://cgit.freedesktop.org/mesa/mesa/commit/?id=839793680f99b8387bee9489733d5

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

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

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.

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

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.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1501.