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

[Jason Ekstrand]

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

> Hi,
>
> > 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.
>
> 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.
>
> 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.
>

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.


> 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.
>
> 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).
>

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.

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