From 03600660a18072cac0ca5a717e2e053faba0d04d Mon Sep 17 00:00:00 2001 From: Kenneth Graunke Date: Fri, 21 Jun 2013 15:55:32 -0700 Subject: [PATCH] i915: Remove GLES 3.0 sRGB workaround. Gen3 doesn't support GLES 3.0, so there's no need for it. Acked-by: Eric Anholt --- src/mesa/drivers/dri/i915/intel_context.c | 52 ----------------------- 1 file changed, 52 deletions(-) diff --git a/src/mesa/drivers/dri/i915/intel_context.c b/src/mesa/drivers/dri/i915/intel_context.c index 3c052f8acc2..48a155f9eae 100644 --- a/src/mesa/drivers/dri/i915/intel_context.c +++ b/src/mesa/drivers/dri/i915/intel_context.c @@ -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 -- 2.30.2