<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Aug 28, 2018 at 4:13 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>
> You are completely missing the point.  Any test which tests the<br>
> GL_ARB_fragment_shader_interlock extension with a<br>
> beginInvocationInterlockARB() call inside of control-flow would be an<br>
> invalid test for GL_ARB_fragment_shader_interlock since that behavior is<br>
> undefined.  Therefore, any such test would be a bad test.  Unless we have<br>
> tests which test beginFragmentShaderOrderingINTEL() inside non-uniform<br>
> control-flow, it is insufficiently tested.  Therefore, any tests we may<br>
> have for GL_ARB_fragment_shader_interlock are either invalid use of the ARB<br>
> extension or they are insufficient to test the INTEL extension.<br>
<br>
My apologies, I misunderstood your question "is that tested?"; I thought the question was about if the assentation that the current implementation of beginFragmentShaderOrderingINTEL() and beginInvocationInterlockARB() were functionally interchangeable has been verified/tested.<br>
<br>
FWIW, a test where beginInvocationInterlockARB() is called within any control flow or for that matter not called from main(), the shader is supposed to be rejected according the spec. In a negative way, it is another test. Though, while acknowledging Ian's point that "works for vendor X" has caused a great deal of GLSL fragmentation, I still personally prefer to implementation to try to take what applications throw at them as much as reasonable possible. However, that is not my decision to make and whatever the community chooses is what it shall be.<br></blockquote><div><br></div><div>If the spec says to reject it, then we should reject it and we should have tests that ensure that we do so.  That's not really a matter of "take what applications throw at them as much as reasonable possible", it's a matter of implementing a spec.  The moment people start straying from the spec because they think their implementation is more reasonable than what's spec'd, it's no longer a spec.  In this case, that's exactly why the INTEL extension exists.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I agree with you that taking the current ARB test and then adding some non-uniform flow control (along with removing the layout() qualifiers) to it is the best way to go and I *think* Plamena has offered to do so.<br>
<br>
At this point, I can just let for it all to sort out and bow out of the discussion at this point as the series seems to have brought additional issues up that are out-of-scope for what I had in mind with the series (namely something small-simple to expose the extension and not enforcing the limitation of the ARB extension).<br></blockquote><div><br></div>One of my fears here is whether or not the compiler will actually treat the instruction as a barrier like it's supposed to.  We don't do a lot with respect to optimization around barriers right now so it's probably ok.  However, the two extensions are sufficiently different from an API surface perspective (even if the implementation is identical!) that we need to be careful about making sure they're both tested.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">--Jason<br></div></div>