On 08/28/2018 12:40 PM, Ian Romanick wrote: > On 08/28/2018 12:09 PM, Rogovin, Kevin 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. > > That's actually terrible and needs to be fixed ASAP. That's how we end > up with the "it works on <some vendor>" rubbish that has basically > ruined GLSL.
Test cases sent to the piglit list. >> -Kevin >> _______________________________________________ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev >> > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
