<div dir="ltr">Kenneth<div><br></div><div>Thank you for the commit info. Please consider this patch abandoned.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 22, 2016 at 11:50 AM, Kenneth Graunke <span dir="ltr"><<a href="mailto:kenneth@whitecape.org" target="_blank">kenneth@whitecape.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thursday, December 22, 2016 10:47:46 AM PST Haixia Shi wrote:<br>
> Hello Mesa-Dev:<br>
><br>
> To give you some background, we are observing that mask values getting<br>
> converted to -1 when running multiple dEQP-GLES31 tests in sequence.<br>
><br>
> There's already a previous commit<br>
> (<wbr>b8b1d83c71fd148d2fd84afdc20c0a<wbr>a367114f92) that attempted to address the<br>
> test failures by initializing all stencil values to 0xFF.<br>
><br>
> However, the test still fails when running all<br>
> dEQP-GLES3.functional.state_<wbr>query.integers#stencil_*_<wbr>getfloat tests<br>
> sequentially.<br>
><br>
> Apparently the test sets mask values to 0xffffffffU using glStencilFunc()<br>
> API, and this overwrites the 0xFF initial value. Therefore I would propose<br>
> that we sanitize all input stencil mask values.<br>
><br>
> Thanks,<br>
> Haixia<br>
<br>
</span>Hi Haixia,<br>
<br>
I believe I already fixed these a couple days ago in commit<br>
37d63b50b196afe61b4d7c33b1118a<wbr>49a5e1e13f.<br>
<br>
--Ken<br>
</blockquote></div><br></div>