Bug 60633

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>