<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#c12">Comment # 12</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:sroland@vmware.com" title="Roland Scheidegger <sroland@vmware.com>"> Roland Scheidegger</a> <pre>(In reply to Marek Olšák from <a href="show_bug.cgi?id=93594#c10">comment #10</a>) > The GLSL shader is using discard followed by fwidth. This is undefined > behavior. > > Therefore, it's an application bug. I wasn't aware of this difference, but seeing this bug made me suspicious, and indeed d3d10 is saying for discard: <a href="https://msdn.microsoft.com/en-us/library/windows/desktop/hh446968%28v=vs.85%29.aspx">https://msdn.microsoft.com/en-us/library/windows/desktop/hh446968%28v=vs.85%29.aspx</a> "This instruction flags the current pixel as terminated, while continuing execution, so that other pixels executing in parallel may obtain derivatives if necessary. Even though execution continues, all Pixel Shader output writes before or after the discard instruction are discarded." That's very interesting... gallium docs don't actually say anything about this neither naturally. (I think it should work in llvmpipe, because indeed we only update the pixel alive mask.) Due to d3d10 being different there, I wouldn't be surprised if other apps make the same mistake.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>