<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Nov 30, 2018 at 4:34 PM Ian Romanick <<a href="mailto:idr@freedesktop.org">idr@freedesktop.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 11/30/2018 01:29 PM, Jason Ekstrand wrote:<br>
> On Fri, Nov 30, 2018 at 3:18 PM Ian Romanick <<a href="mailto:idr@freedesktop.org" target="_blank">idr@freedesktop.org</a><br>
> <mailto:<a href="mailto:idr@freedesktop.org" target="_blank">idr@freedesktop.org</a>>> wrote:<br>
> <br>
>     On 11/29/2018 07:47 AM, Connor Abbott wrote:<br>
>     > On Thu, Nov 29, 2018 at 4:22 PM Jason Ekstrand<br>
>     <<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a> <mailto:<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>>> wrote:<br>
>     >><br>
>     >> Can you provide some context for this?  Those rules are already<br>
>     flagged "inexact" (that's what the ~ means) so they won't apply to<br>
>     anything that's "precise" or "invariant".<br>
>     ><br>
>     > I think the concern is that this isn't allowed in SPIR-V, even without<br>
>     > exact or invariant. We even go out of our way to do the correct thing<br>
>     > in the frontend by inserting an "&& a == a" or "|| a != a", but then<br>
> <br>
>     If you're that paranoid about it, why not just mark the operations are<br>
>     precise?  That's literally why it exists.<br>
> <br>
>     > opt_algebraic removes it with another rule and then this rule can flip<br>
>     > it from ordered to unordered. The spec says that operations don't have<br>
>     > to produce NaN, but it doesn't say anything on comparisons other than<br>
>     > the generic "everything must follow IEEE rules" and an entry in the<br>
>     > table that says "produces correct results." Then again, I can't find<br>
>     > anything in GLSL allowing these transforms either, so maybe we just<br>
>     > need to get rid of them.<br>
> <br>
>     What I hear you saying is, "The behavior isn't defined."  Unless you can<br>
>     point to a CTS test or an application that has incorrect behavior, I'm<br>
>     going to oppose removing this pretty strongly.  *Every* GLSL compiler<br>
>     does this.<br>
> <br>
> <br>
> The test case came from VKD3D which does D3D12 on Vulkan.  Someone<br>
> (Samuel, maybe?) was going to ask around and see if we can figure out<br>
> what D3D12's rules are.  It's possible that it requires IEEE or<br>
> something close.  If that's the case, as I said to Samuel on IRC, we're<br>
> probably looking at an extension.  I don't think we want a flag like<br>
> this that's set per-API.<br>
<br>
Why isn't it sufficient to mark the operation as precise?  Was that on<br>
IRC, and I missed it?<br>
<br>
It is also possible that we could improve the handling of 'if<br>
(!condition)' in the backend to make these transformations less<br>
important.  I have some patches for that somewhere.  They didn't really<br>
help with these transformations in place, and I never measured the<br>
result without these transformations.<br></blockquote><div><br></div><div>I think we can and that would be better than this flag.</div><div><br></div><div>--Jason<br></div></div></div>