On Tue, Aug 28, 2018 at 2:10 PM Rogovin, Kevin <kevin.rogo...@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
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
