<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Flickering Shadows in The Talos Principle" href="https://bugs.freedesktop.org/show_bug.cgi?id=93594#c18">Comment # 18</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Flickering Shadows in The Talos Principle" href="https://bugs.freedesktop.org/show_bug.cgi?id=93594">bug 93594</a> from <a class="email" href="mailto:kai@dev.carbon-project.org" title="Kai <kai@dev.carbon-project.org>"> Kai</a> <pre>(In reply to Marek Olšák from <a href="show_bug.cgi?id=93594#c10">comment #10</a>) > (In reply to Michel Dänzer from <a href="show_bug.cgi?id=93594#c9">comment #9</a>) > > Note that AFAIK using things like derivatives in non-uniform control flow > > isn't supported by GLSL. What's the original GLSL shader? > > True. > > The GLSL shader is using discard followed by fwidth. This is undefined > behavior. > > Therefore, it's an application bug. > > The easy workaround would be to disable register allocation in st/mesa to > get a quasi-SSA form and trivially move KILL_IF to the end of the shader if > the app is detected to be Talos Principle. I forwarded this information to Croteam and Dean Sekulic answered: > Oh, just found out that discard instruction is treated as dynamic flow control > for some reason... :/ > > Will fix this! > > > On 19-02-16 8:21, Dean Sekulic wrote: >> I can't find any reference anywhere that doing fwidth() (or ddx/ddy for >> that matter) after discard should be undefined behavior... :/ >> >> GPUs should handle that case completely fine. >> >> Can you elaborate, please? Looks like there might be an update for The Talos Principle which will address this.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>