[Mesa-dev] [PATCH 0/2] Implement INTEL_fragment_shader_ordering
Ian Romanick
idr at freedesktop.org
Tue Aug 28 22:20:45 UTC 2018
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 at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
More information about the mesa-dev
mailing list