Eric Anholt <e...@anholt.net> writes: > Francisco Jerez <curroje...@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.]
pgpUPHAB98CNR.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
