[Piglit] [PATCH] Revert "fs-discard-exit-3: New test for another bug in handling 1.30's discard rule."
currojerez at riseup.net
Mon Feb 2 11:38:45 PST 2015
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:
>> 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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 212 bytes
Desc: not available
More information about the Piglit