[Mesa-dev] [PATCH 0/2] Implement INTEL_fragment_shader_ordering

[Jason Ekstrand]

On Tue, Aug 28, 2018 at 2:10 PM Rogovin, Kevin <kevin.rogovin at intel.com>
wrote:

> Hi,
>
> > Is that tested?
>
> 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.
>

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.

--Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180828/42906d8e/attachment.html>