Races are very dark

[ghost]

With 0.9, tracks have become very dark. See screenshot.

[auriamg]

This is not normal, so I suspect there is a compatibility/driver issue somewhere. Maybe you can give more info : OS, GPU, logging output, does changing graphics level matter?

[ghost]

Hi, thanks for looking into the issue. Here is the info:

OS: Archlinux
GPU: Not sure what info you need. This is what glxinfo tells me

OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile

Graphics level: 1
Logging output: how do I get that?

I have played around with the graphics level and the lighting improves on graphic level 3+. However, the game is for me unplayable with those settings.

[hiker]

Can you post the content of: $HOME/.config/supertuxkart/0.8.2/stdout.log?
Does it make a difference if you play fullscreen or in a window?
Does the amount of light change during 'ready, set, go' (I know that on intel hd3000 on windows the image gets brighter the moment 'ready' is shown).

[ghost]

The lighting does not change whether I run windowed or fullscreen. Also, the lighting does not change after the "ready, set, go" sequence. I have taken screenshot after the sequence.

The stdout.log file is here: https://www.dropbox.com/s/q7fagvt8op0rotb/stdout.log?dl=0

[hiker]

Sorry for the delay in answering, but your stdout file is not there anymore. Could you re-upload it?

[deveee]

I see something similar on intel HD4000 with mesa 11. I think this is a bug in mesa because it works for me with mesa 10.3.2.

I reported it to them:
https://bugs.freedesktop.org/show_bug.cgi?id=92759

@scrzbble you can check if older version of mesa driver solves this issue for you.

[deveee]

Someone has similar issues with current mesa:
https://bugs.freedesktop.org/show_bug.cgi?id=91817
which is caused by using SRGB format. Maybe we could solve it on our side.

As I see we even have "FramebufferSRGBWorking" in graphics restrictions. I will check if it works.

[imirkin]

Disclaimer: I know very little about stk/irrlicht, so just a drive-by comment, feel free to ignore.

Sometimes such issues result from picking an incorrect visual. Different drivers will return these in different orders, so perhaps you were relying on one order and it changed. Make sure that you're filtering on the srgb attribute of the visual to get the one you expected.

[deveee]

I was digging a bit around this bug (@imirkin I already sent it to mesa mailing list, it's waiting for moderator approval now. Generally I agree that this patch doesn't have a sense).

Here is how it works in Supertuxkart:
We create rtt with following parameters:

DepthStencilTexture = generateRTT(res, GL_DEPTH24_STENCIL8, GL_DEPTH_STENCIL, GL_UNSIGNED_INT_24_8);

Then, during rendering scene, we do:

    glEnable(GL_FRAMEBUFFER_SRGB);
    glBindFramebuffer(GL_FRAMEBUFFER, 0);
    (...)
    render();
    (...)
    glDisable(GL_FRAMEBUFFER_SRGB);

It looks that glEnable(GL_FRAMEBUFFER_SRGB) doesn't work anymore. It's because of following lines 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;
   }

Previously MESA_FORMAT_B8G8R8X8_UNORM was not available, and thus MESA_FORMAT_B8G8R8A8_UNORM was handled as last case (using MESA_FORMAT_B8G8R8A8_SRGB format). Now it uses MESA_FORMAT_B8G8R8X8_UNORM format.

Atm. I'm not sure how to workaround it.

[imirkin]

In CIrrDeviceLinux.cpp you appear to have:

//#ifdef GL_ARB_framebuffer_sRGB
//                  GLX_FRAMEBUFFER_SRGB_CAPABLE_ARB, CreationParams.HandleSRGB,
//#elif defined(GL_EXT_framebuffer_sRGB)
//                  GLX_FRAMEBUFFER_SRGB_CAPABLE_EXT, CreationParams.HandleSRGB,
//#endif

Any idea why this is commented out? The ifdefs are wrong... need to check for GLX_ARB_framebuffer_sRGB and GLX_EXT_framebuffer_sRGB, not GL_*, but it probably wouldn't matter either way. But this should be the right way to ensure you have a sRGB visual. If you can't find one with sRGB, then you should disable your expectations that you're rendering to a sRGB winsys fb.

[imirkin]

Or conversely if you don't really care about whether you have a sRGB visual or not, and just need to know, you could query the fb's state with glGetFramebufferAttachmentParameteriv(GL_DRAW_FRAMEBUFFER, GL_BACK_LEFT (??? i can never remember the right one), GL_FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING, &issrgb)

[deveee]

@imirkin Unfortunately setting GLX_FRAMEBUFFER_SRGB_CAPABLE_ARB doesn't help. It makes things even worse because in this case irrlicht uses different internal texture format. In COpenGLTexture.cpp:

    if (Driver->Params.HandleSRGB)
    {
        if (internalformat==GL_RGBA)
            internalformat=GL_SRGB_ALPHA_EXT;
        else if (internalformat==GL_RGB)
            internalformat=GL_SRGB_EXT;
    }

But intel still doesn't handle it. And it causes the user interface to be dark too.

Anyway, thanks a lot for your hints!

[imirkin]

Well, that's the right fix. However I just noticed something funny... on a haswell / mesa 11.0.6:

20 GLX Visuals
    visual  x   bf lv rg d st  colorbuffer  sr ax dp st accumbuffer  ms  cav
  id dep cl sp  sz l  ci b ro  r  g  b  a F gb bf th cl  r  g  b  a ns b eat
----------------------------------------------------------------------------
0x020 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x021 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x0b8 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
0x0b9 24 tc  0  32  0 r  . .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
0x0ba 24 tc  0  32  0 r  . .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x0bb 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8 16 16 16 16  0 0 Slow
0x0bc 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  4 1 None
0x0bd 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  8 1 None
0x0be 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  4 1 None
0x0bf 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  8 1 None
0x0c0 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
0x0c1 24 dc  0  32  0 r  . .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
0x0c2 24 dc  0  32  0 r  . .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x0c3 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x0c4 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8 16 16 16 16  0 0 Slow
0x0c5 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  4 1 None
0x0c6 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  8 1 None
0x0c7 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  4 1 None
0x0c8 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  8 1 None
0x08b 32 tc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None

And also no srgb-enabled GLXFBConfigs. So I think that's the core of the problem...

(a) You need to fix your engine to support situations with the selected visual is not srgb-enabled
(b) The Intel driver needs to start exposing srgb-capable visuals

I'm not exactly an expert on this stuff, so I'll reply on-list and see if people who actually understand GLX, sRGB, visuals, etc can provide feedback.

[imirkin]

Is CreationParams.WithAlphaChannel true? I bet it's not... forcing alpha in your visual would also "solve" your problem. But that will also be through luck (and knowledge of intel driver internals) -- the core issues are outlined above.

[deveee]

Nice hack with CreationParams.WithAlphaChannel which is set to true :) Indeed it forces to use MESA_FORMAT_B8G8R8A8_SRGB format.

About glxinfo, I see exactly the same. SRGB is not reported anywhere.

Ok, then I will try to handle the situation that srgb-capable visual is not available. We at least know the reason of this bug now.

[imirkin]

The is really odd, and will probably require careful reading of some specs, but it seems like the intel driver will optionally make a config be srgb-enabled even if the reported visual says no. Since the intel guys aren't dummies, I'm guessing it's allowed. You need to determine the srgb-ness of things by querying the winsys framebuffer as I mentioned earlier (with glGetFramebufferAttachmentParameter).

[deveee]

Okay, I made some changes on our side:

• We now request srgb-capable visual during creating opengl context. Drivers seem to ignore this request, but we need it for proper working anyway, so request it doesn't hurt
• I disabled srgb textures on irrlicht side to avoid modification our user interface. Though it actually could help us. For example it solves the issue that the karts in kart selection screen are too dark.
• I added the ugly hack with setting WithAlphaChannel param to true for intel drivers on mesa.

It also should be fixed soon on mesa side by this patch:
http://patchwork.freedesktop.org/patch/67844/

It's actually hard to handle it properly on our side, because we can't really trust glGetFramebufferAttachmentParameteriv function. It for example returns GL_LINEAR on nvidia drivers and glEnable(GL_FRAMEBUFFER_SRGB) works fine there. It should be relatively easy to write a shader for gamma correction, but still we have a problem when to use it.

And still there is no similar issues with other drivers, so I'm not sure if we should really care about it.

I'm closing this ticket because workaround for intel on linux is already applied.