From: Kenneth Graunke <kenneth@whitecape.org>
Date: Fri, 21 Jun 2013 22:55:32 +0000 (-0700)
Subject: i915: Remove GLES 3.0 sRGB workaround.
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=03600660a18072cac0ca5a717e2e053faba0d04d;p=mesa.git

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 <eric@anholt.net>
---

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