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
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?
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)
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)
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.
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.
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 ***
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>
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.