<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Aug 28, 2018 at 2:10 PM 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>
> Is that tested?<br>
<br>
I have tested it in a simple shader test I made (i.e. not in a dedicated test suite such as dEQP, piglit or something else). The created assembly is identical. The specific example is a shader where I replace calls of beginFragmentShaderOrderingINTEL() with beginInvocationInterlockARB() and the created assembly is the same. Running with INTEL_DEBUG=fs produced identical output except the SSA NIR had the different opcode. AFAIK, the current Mesa implementation of the ARB extension does not in any way shape or form enforce any of "no control flow", "only once and only in main" requirements. Indeed, Mesa happily accepts code even without the endInvocationInterlockARB() call as well.  Personally, I am happy that it is more accepting rather than rejecting the code.<br></blockquote><div><br></div><div>You are completely missing the point.  Any test which tests the GL_ARB_fragment_shader_interlock extension with a beginInvocationInterlockARB() call inside of control-flow would be an invalid test for GL_ARB_fragment_shader_interlock since that behavior is undefined.  Therefore, any such test would be a bad test.  Unless we have tests which test beginFragmentShaderOrderingINTEL() inside non-uniform control-flow, it is insufficiently tested.  Therefore, any tests we may have for GL_ARB_fragment_shader_interlock are either invalid use of the ARB extension or they are insufficient to test the INTEL extension.</div><div><br></div><div>--Jason<br></div></div></div>