[Piglit] [PATCH] Revert "fs-discard-exit-3: New test for another bug in handling 1.30's discard rule."

[Eric Anholt]

Francisco Jerez <currojerez at riseup.net> writes:

> Eric Anholt <eric at anholt.net> writes:
>
>> Francisco Jerez <currojerez at riseup.net> writes:
>>
>>> This reverts commit 3fad0868f023f1d726e230968a4df3327de38823.
>>>
>>> This test doesn't make any sense to me, it begins quoting the GLSL
>>> 1.30 spec on the interaction of the discard keyword with control flow:
>>>
>>>  "[...] Control flow exits the shader, and subsequent implicit or
>>>   explicit derivatives are undefined when this control flow is
>>>   non-uniform (meaning different fragments within the primitive take
>>>   different control paths)."
>>>
>>> IOW the discard keyword is a control flow statement that can
>>> potentially make subsequent derivatives undefined if only some subset
>>> of the fragments execute it.  The test then goes on and does the exact
>>> opposite: It samples a texture after a non-uniform discard expecting
>>> that implicit derivatives will be calculated correctly, while
>>> according to the spec quotation they have undefined results.
>>>
>>> If the quoted text doesn't seem clear enough, see section 6.4 "Jumps"
>>> of the same specification:
>>>
>>>  "These are the jumps:
>>>     jump_statement:
>>>     [...]
>>>        discard; // in the fragment shader language only"
>>>
>>> and section 8.7 "Texture Lookup Functions":
>>>
>>>  "Implicit derivatives are undefined within non-uniform control flow
>>>   and for vertex shader texture fetches."
>>>
>>> More recent spec versions have made the meaning of non-uniform control
>>> clearer.  From the GLSL spec version 4.4, section 3.8.2 "Uniform and
>>> Non-Uniform Control Flow":
>>>
>>>  "Control flow becomes non-uniform when different fragments take
>>>   different paths through control-flow statements (selection,
>>>   iteration, and jumps). [...] Other examples of non-uniform flow
>>>   control can occur within switch statements and after conditional
>>>   breaks, continues, early returns, and after fragment discards, when
>>>   the condition is true for some fragments but not others."
>>>
>>> There was some discussion about this topic in Khronos bug 5449, which
>>> motivated the inclusion of the first sentence quoted above in the GLSL
>>> 1.30 spec.  The rationale was that continuing the execution of
>>> discarded fragments after a non-uniform discard would be ill-defined
>>> because it could easily lead to infinite loops and break invariants of
>>> the program.
>>
>> Yeah, on the other hand, we found that not continuing the execution of
>> discarded fragments within a subspan that contained still-enabled
>> fragments caused incorrect rendering.
>>
>> See 9e9ae280e215988287b0f875c81bc2e146b9f5dd.
>
> How about a drirc option to (partially) support derivatives after
> non-uniform discard for applications that rely on this non-compliant
> behaviour?  Do you remember any other applications that relied on this
> other than Tropics?  [which BTW has been broken for half a year for
> other reasons].
>
> It's unfortunate that we end up emitting extra code (for keeping track
> of the enabled-but-discarded channel mask and for terminating loops
> early) and that we run more channels than necessary on *all*
> applications with the only purpose of enabling this non-compliant
> behaviour probably very few applications rely on.
>
> [Cross-posting to mesa-dev because this is more of an implementation
> issue.]

I think we ended up fixing GLB2.7 with the revert, as well?  This is a
long time ago.  f you want to experiment with following the spec
behavior (even though apparently other implementations didn't), you're
going to want to test a *lot* of apps.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/piglit/attachments/20150202/36541c89/attachment.sig>