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