On 11/30/2018 01:36 PM, Bas Nieuwenhuizen wrote: > On Fri, Nov 30, 2018 at 10:29 PM Jason Ekstrand <[email protected]> wrote: >> >> On Fri, Nov 30, 2018 at 3:18 PM Ian Romanick <[email protected]> wrote: >>> >>> On 11/29/2018 07:47 AM, Connor Abbott wrote: >>>> On Thu, Nov 29, 2018 at 4:22 PM Jason Ekstrand <[email protected]> >>>> 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. > > What do you mean an extension? AFAIU the concern is that Vulkan SPIR-V > is more restrictive than GLSL here, and disallows these optimization > right? That makes a strong case that we should remove these rules for > at least Vulkan. If that means writing a CTS test, maybe we should do > just that?
Given the existence of mobile GPUs, it seems unlikely to me that Vulkan SPIR-V is more strict about NaNs or denorms than GLSL or GLSL ES. The mobile vendors didn't have the extra DX requirements, so, for a variety of valid reasons, they pushed back on making much of anything more strict. _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
