<div dir="ltr"><div>"Works on an app" is not and never has been an acceptable testing plan for landing a new feature in Mesa.  There need to be tests in piglit, dEQP, or one of the conformance suites.</div><div><br></div><div>--Jason<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Aug 28, 2018 at 11:15 AM Rogovin, Kevin <<a href="mailto:kevin.rogovin@intel.com">kevin.rogovin@intel.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
 On the questions of tests: If people want, I can adapt the test in piglit for ARB_fragment_shader_interlock to this INTEL one. In general, I have an app/library that uses the extension and testing of that does definitely work on i965 (which should be utterly unsurprising since the produced assembly is identical). Indeed the current implementation in Mesa of ARB_fragment_shader_interlock is as flexible as the INTEL one since the compiler accepts code with the begin/end interlock anywhere since the only backend that supports it, i965, can easily accept it. I view the INTEL_fragment_shader_ordering implementation in a similar light as the NV_fragment_shader_interlock where it actually does not really do anything new, but signals to an application that the Mesa/i965 implementation allows more (and does it correctly) than the ARB/NV extensions restrict to.<br>
<br>
-Kevin<br>
</blockquote></div>