Francisco Jerez <[email protected]> writes: > Eric Anholt <[email protected]> writes: > >> Francisco Jerez <[email protected]> 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.
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
