AlexIndustrial/mesa
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

i915: Remove GLES 3.0 sRGB workaround.

Browse Source 
Gen3 doesn't support GLES 3.0, so there's no need for it.

Acked-by: Eric Anholt <eric@anholt.net>
This commit is contained in:
Kenneth Graunke
2013-06-21 15:55:32 -07:00
parent dc8796506e
commit 03600660a1
1 changed files with 0 additions and 52 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/mesa/drivers/dri/i915/intel_context.c
-52
View File
@@ -646,55 +646,6 @@ intelUnbindContext(__DRIcontext * driContextPriv)
return true;
}
/**
* Fixes up the context for GLES23 with our default-to-sRGB-capable behavior
* on window system framebuffers.
*
* Desktop GL is fairly reasonable in its handling of sRGB: You can ask if
* your renderbuffer can do sRGB encode, and you can flip a switch that does
* sRGB encode if the renderbuffer can handle it. You can ask specifically
* for a visual where you're guaranteed to be capable, but it turns out that
* everyone just makes all their ARGB8888 visuals capable and doesn't offer
* incapable ones, becuase there's no difference between the two in resources
* used. Applications thus get built that accidentally rely on the default
* visual choice being sRGB, so we make ours sRGB capable. Everything sounds
* great...
*
* But for GLES2/3, they decided that it was silly to not turn on sRGB encode
* for sRGB renderbuffers you made with the GL_EXT_texture_sRGB equivalent.
* So they removed the enable knob and made it "if the renderbuffer is sRGB
* capable, do sRGB encode". Then, for your window system renderbuffers, you
* can ask for sRGB visuals and get sRGB encode, or not ask for sRGB visuals
* and get no sRGB encode (assuming that both kinds of visual are available).
* Thus our choice to support sRGB by default on our visuals for desktop would
* result in broken rendering of GLES apps that aren't expecting sRGB encode.
*
* Unfortunately, renderbuffer setup happens before a context is created. So
* in intel_screen.c we always set up sRGB, and here, if you're a GLES2/3
* context (without an sRGB visual, though we don't have sRGB visuals exposed
* yet), we go turn that back off before anyone finds out.
*/
static void
intel_gles3_srgb_workaround(struct intel_context *intel,
struct gl_framebuffer *fb)
{
struct gl_context *ctx = &intel->ctx;
if (_mesa_is_desktop_gl(ctx) || !fb->Visual.sRGBCapable)
return;
/* Some day when we support the sRGB capable bit on visuals available for
* GLES, we'll need to respect that and not disable things here.
*/
fb->Visual.sRGBCapable = false;
for (int i = 0; i < BUFFER_COUNT; i++) {
if (fb->Attachment[i].Renderbuffer &&
fb->Attachment[i].Renderbuffer->Format == MESA_FORMAT_SARGB8) {
fb->Attachment[i].Renderbuffer->Format = MESA_FORMAT_ARGB8888;
}
}
}
GLboolean
intelMakeCurrent(__DRIcontext * driContextPriv,
__DRIdrawable * driDrawPriv,
@@ -733,9 +684,6 @@ intelMakeCurrent(__DRIcontext * driContextPriv,
intel_prepare_render(intel);
_mesa_make_current(ctx, fb, readFb);
intel_gles3_srgb_workaround(intel, ctx->WinSysDrawBuffer);
intel_gles3_srgb_workaround(intel, ctx->WinSysReadBuffer);
/* We do this in intel_prepare_render() too, but intel->ctx.DrawBuffer
* is NULL at that point. We can't call _mesa_makecurrent()
* first, since we need the buffer size for the initial