Bug 60633 - EXT_texture_sRGB does not work in game The Cave on IvyBridge
EXT_texture_sRGB does not work in game The Cave on IvyBridge
Status: RESOLVED DUPLICATE of bug 55783
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965
git
x86-64 (AMD64) Linux (All)
: high normal
Assigned To: Eric Anholt
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-02-11 08:28 UTC by David Gow
Modified: 2013-03-01 20:29 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Gow 2013-02-11 08:28:38 UTC
We're having problems with sRGB conversion in the (upcoming) Linux release of Double Fine's game "The Cave". The game is appearing much darker than it should. Setting MESA_EXTENSION_OVERRIDE="-GL_EXT_texture_sRGB" makes the game do the sRGB conversion itself, bypassing the issue. It's probably worth noting that the textures in question are compressed.

Screenshots:
Without texture_sRGB: http://davidgow.net/stuff/cave_good_srgb.png 
With texture_sRGB: http://davidgow.net/stuff/cave_bad_srgb.png

apitrace:
Working: http://davidgow.net/stuff/Cave-intel-bad-srgb.trace
Not working: http://davidgow.net/stuff/Cave-intel-no-srgb.trace

This is occuring both with Mesa 9.0 as found in Ubuntu 12.10 and with the latest git mesa (990bd49fba7d539e950bdda6eb9819a9abf14850) on a Lenovo Thinkpad X1 Carbon, w/ KDE (glxinfo for Mesa 9: http://davidgow.net/glxinfo-vorticon.log).

The game looks fine (w/ EXT_texture_sRGB enabled) on both nVidia's blob and on Mesa with swrast (although swrast doesn't seem to support framebuffer_sRGB, so the issue might actually exist there as well).

Let me know if there's any other info you need!

-- David
Comment 1 Eric Anholt 2013-02-14 22:28:33 UTC
From the apitrace dump:

47729 glBindFramebufferEXT(target = GL_FRAMEBUFFER, framebuffer = 0)
47730 glEnable(cap = GL_FRAMEBUFFER_SRGB)

That should be the issue.  None of our window-system framebuffers support sRGB encode (mostly because we needed to fix the GLX side of things, which may have just recently landed), so despite glEnable(GL_FRAMEBUFFER_SRGB), the encode doesn't happen because glGetInteger(FRAMEBUFFER_SRGB_CAPABLE) is 0.

For compatibility you should check that field and deal with it however's appropriate (sounds like you have srgb encode as an option on your side), but on our end we really should get this feature implemented since we're the odd ones out.

As a side note, in your GLX fbconfig/visual choosing, are you asking for an srgb-capable visual first?
Comment 2 Edward Rudd 2013-02-15 17:18:40 UTC
Eric, thanks for the detailed reply..  I'm the guy who did the porting work on The Cave for OS X and Linux.  Which we actually have issues with the HD 4000 chips on Apple land related to sRGB (drivers crashing out with an assert).

Anyways..  Basically the OpenGL renderer in the game simply checks if the EXT_framebufer_sRGB and EXT_texture_sRGB extensions are supported.. If they are it loads the textures with the sRGB types that need to be, and enabled the SRGB flag on the "0" framebuffer.   That is pretty much it..  

If there are other things we should be doing, by all means please enlighten.

I'll adjust the SRGB check for linux to check glGetInteger(FRAMEBUFFER_SRGB_CAPABLE)
Comment 3 Edward Rudd 2013-02-15 18:00:44 UTC
Oh, and as for our glXChoosVisual, we are not specifically requesting for an sRGB visual. (SDL 2 doesn't currently expose that..  I guess I'll have to patch that up first)
Comment 4 Eric Anholt 2013-02-16 00:21:27 UTC
Yeah, you'll want to check for EXT_framebuffer_sRGB, then if present check SRGB_CAPABLE, and only then can you trust that encode will happen for you (otherwise you get to roll your own encode, sorry).

I've got a patch that is almost ready to set SRGB_CAPABLE on our window system buffers, but there's a nasty interaction with GLES3 I need to think about some more.
Comment 5 Edward Rudd 2013-02-16 03:17:26 UTC
Thanks.. that is how I modified the code.. so *IF* the extensions are available, I check if the framebuffer is capable.. However that doesn't help w/ the Apple side of things.. as the HD 4000 claims it's capable, but then crashes with a 

Application Specific Information:
Assertion failed: (srgbValue >= 0.0f && srgbValue <= 1.0f), function LinearToSRGB, file 
/SourceCache/GraphicsDrivers/GraphicsDrivers-8.6.22/Common/GLRenderer/Intel/intel_types_util.h, line 866.


When I do a glClear..   Ahh.... oh well.
Comment 6 Eric Anholt 2013-02-16 07:21:03 UTC
OK, since it looks like we've got this figured out, I'm marking it as a dupe of a previous report of this missing functionality.

*** This bug has been marked as a duplicate of bug 55783 ***
Comment 7 Eric Anholt 2013-03-01 20:29:43 UTC
commit e15c21a957b62ab856ab286e8253dd1151a3386e
Author: Eric Anholt <eric@anholt.net>
Date:   Fri Feb 15 07:41:42 2013 -0800

    i965: Make sRGB-capable framebuffers by default.
    
    The GLX extension lets you expose visuals that explicitly guarantee you
    that the GL_FRAMEBUFFER_SRGB_CAPABLE flag will be set, but we can set
    the flag even while the visual doesn't provide the guarantee.  This
    appears to be consistent with other implementations, as we've seen
    several apps now that don't require an srgb visual and assume sRGB will
    work without checking the GL_FRAMEBUFFER_SRGB_CAPABLE flag.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55783
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60633
    Reviewed-and-tested-by: Ian Romanick <ian.d.romanick@intel.com>