<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 22, 2015 at 12:15 PM, Chad Versace <span dir="ltr"><<a href="mailto:chad.versace@intel.com" target="_blank">chad.versace@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On Mon 19 Oct 2015, Nanley Chery wrote:<br>
> From: Nanley Chery <<a href="mailto:nanley.g.chery@intel.com">nanley.g.chery@intel.com</a>><br>
><br>
> Stop leaks into the following contexts:<br>
>    * GLES in _mesa_base_tex_format() and lookup_view_class().<br>
>    * Pre-1.1 GL legacy contexts in all uses.<br>
><br>
> Stop allowing compressed sRGB formats as valid formats in GLES3<br>
> contexts. I realized this was happening when CTS failures occured after<br>
> fixing the extension functionality leak with the helper function.<br>
<br>
</span>Do you mean that this patch *fixes* CTS failures? If so, which CTS for<br>
which GLES version?  There are so many CTS's in the world :(<br>
</blockquote></div><br></div><div class="gmail_extra">I meant that when I first modified _mesa_base_tex_format() to use the helper<br></div><div class="gmail_extra">function, I had failures in piglit, dEQP, and the Khronos CTS. "failures in every<br>test-suite" probably would've been better than "CTS failures" here. It was <br>because of those failures, that I realized that we were incorrectly allowing<br>formats like GL_COMPRESSED_SRGB_EXT in GLES contexts. This motivated<br>the split of the switch statement you see in the diff of _mesa_base_tex_format().<br></div></div>