WGSL 2022-08-30 Minutes

DS: Roughly Apple thinks we should define domains of things and all results get defined
MM: More subtle then that, but yes
DN: We’ve defined some of them but not all.
MM: First thing interesting to discuss is historically viewed as portability vs performance trade off. If that is acceptable then would be reasonable to talk about classes of distinct functions. 1 might be inverse trig as they have particular perf profile which is different from others. One way to nibble away is to first scope to just those functions and say is it reasonable to make well defined for -inf to inf just for these because it’s cheap. One option is make them well defined and pick some value they should be equal too or, don’t pick a number because it’s wrong and programs which produce should be ill-defined and produce …. Something. What do people think?
JB: Not in favour of leaving things as undefined as a way to punish authors. What I do want to discourage is people using specified behaviour as a way to do tricks. The reason nan is first choice is that it is the most useless value that maximally discourages folks from doing tricks. By this argument, maybe having arcsin(2) == inf would be a feasible way forward because it’s a difficult to work with value that is kind of infectious and probably messes with things. Would be a way to give fully spec’d behaviour and discourage tricks. Looking ahead to compile-time case and my goal is to discourage from mis-using and help catch errors would like to do something that graduates well to making pipeline and shader module creation errors. Nan is appealing as it’s the cleanest graduation to the errors I want at static points. Inf is an annoying value so, arguably cleaner transition. Making zero is well specified which is better then just being anything. Having it being any impl chosen value is least favourite choice.
AB: What is punishment. Say we had nans, if i had 2 nans does nan== nan? Or is comparison unordered? What is the value of picking one value if, when we switch to nan the value isn’t comparable.
MM: When opting into extension you opt into different flavor of math
AB: JBs philosophy is to get as close to nan as possible. Undefined value is the closest we can get with how comparison works. If nan != nan then having undefined value where don’t know where comparison will go is similar. In my mind, is the punishment you get with an undefined value the same as nan?
MM: Little different, on dev machine will probably get consistent result but on my machine it won’t
JB: Regret introducing idea of punishment. Want to be helpful and help authors catch errors and part of that is declaring things off limits. Claim is rather than Javascript approach of giving everything a value and users use in weird ways we should do what we can to help folks discover mistakes. Nan is one way and think that was the intention. Undef value doesn’t help.
DN: This is why I like talking about compile-time constexpr rule first. More capability to provide feedback early that something ahas been done wrong. Having distinct runtime vs compiletime behaviour is a feature as these are faulty programs. Like framing to be as helpful as we practically can be. In compile time side make it a static error (however we want to say) . We should be as close to that at runtime as we can while restricting practical limits. So, would advocate a number like -716.3 is better then 0 as you won’t index array with that. 0 is worst answer as it slides past too easy. Nan is best, inf is good, large transcendental number is better then zero
MM: Think reasonable compromise. The reason arguing is because of portability and if we make compile errors for places we know the compiler can report an error then that is portable. The second order goal was to enable the slippery behaviour but group is rejecting that so think it’s reasonable. So restating. For runtime behaviour, pick a value, inf or -713.7 and for compile time we make it a compile error.
DN: Like that better, so will take it.
JB: Nice thing about inf is it’s infectious so work to warn of problems.
BC: Don’t know how to do inf without broken compilers being an issue. If have to guard arith with polyfills to produce portable behaviour and start injecting inf or nan into program and those backends cannot cope then might end up back in situation where we have compiler bugs coming out.
MM: Question for vulkan folks. Is inf support greater than nans? If same then no use of one over the other.
AB: They are the same.
BC: Not tied specifically to vulkan.
JB: That’s disappointing.
DS: Could it be inf or -713.24 or is that just worse?
MM: FOr portability it’s worse
BC: Know DN said 0 is worst but have high confidence 0 would work.
DN: Have not’ consulted on what’s the worst possible worse
MM: No opinions on which value, maybe take week to pick a value
BC: Float max would be as good as zero
DN: Negative float max.
MM: Folllowup, was talking about breaking into equivalence classes and talked about trig functions. Is this path forward for all or just trig? Which functions should it apply too. Could for float division and denominator zero.
DN: Was going to raise division. Vulkan is only defined for normal number denominator. So other cases were not important and not tested (inf ULP error). The domain is not so crisp.
MM: Zero is non-normal?
DN: Yes. And don’t want rule for x = 0 blah and then for things that are close to 0 do foo
MM: Right so what we do for 0 is what we have to do for close to zero
DN: It’s a fuzzy boundary.
JB: Distracted by division, original question is which functions. In my mind, compromise for unusual value was all functions with limited domains
MM: Try to enumerate
- Lot that are totally defined
- Another set defined except by 1 value (division for example)
- Bunch defined for half of domain (log)
- Only defined for narrow band (acos)
JB: Think we should treat all of them with restricted domain the same, so log, acos, sqrt should all …
AB: Expect sqrt and log to be fast
JB: sqrt is tricky as it’s heavily used.
MM: Because of colour space transformations
JB: And distance calculations.
DN: Reminded that OpenCL has handful of functions which are cos and native_cos where native is fast and has larger error bounds. That kind of escape hatch is explicit opt in without an enable. Not advocating but pointing out exists.
MM: Have opinions, should talk about when we get to non-fast path proposal. So, proposal made, similar to JB proposal is, we have behaviour for all functions which are not defined for around half the domain or more. So function defined for everywhere except for sentinel values it’s fine. But for things like sqrt would be defined.
DN: Why pay for complexity of authors having to remember which functions have half-infinite domain and others which have a finite size gap in their domain. What’s the motivation for making some special?
MM: What’s the counter argument?
DN: Have a rule which says when you try to compute function outside domain have domain error which results in x. Rather than saying half the domain on the real line is one category vs an interval size 2 which is different. Seems like weird corner to get tripped on.
MM: Concrete function, normalize, defined everywhere but 0, 0, 0. Should normalize(0, 0, 0) be a range error?
DN: Normalize is funny case where epsilon close you have gigantic errors anywhere. Haven’t thought deeply about that. In some sense, if length is less than x you get some category and this discontinuity to compute category. Argument for I have well defined interval of size 2 vs half line. A single point is nuanced.
MM: Happy to treat half the range and a single band as the same. No problem.
DS: Summarize, all happy with compile time errors when we can detect. For runtime, for error bands we define the value return. For single value we …?
MM: No real opinions, treat as zero division case.
DN: Division case, closer to zero the closer answer to inf so you blow off to infinity and hit overflow handling. Normalize is always some vector.
BC: From usability have had to put in normalize(0, 0, 0) = 0
MM: Surprising expected normalize(0, 0, 0) = (1, 0, 0)
BC: From graphics that usually produces speckling with things crossing zero boundary.
MM: That’s fair.
DS: Spec to write for compile time. Spec to write for half or narrow band domains. Table for next time single item ones discussion next time. Discuss sqrt or ones expected to be fast.
JB: Agree
MM: Had decision for division by 0 should decide if we want to be consistent or not with normalize(0, 0, 0)
DN: ...
JB: Thought was defined in IEEE but sounds like inifnities don’t work either so not workable plan.
DN: Think floating point divide should be able to say inf for those reasons. In spec the abstract float doesn’t have nan or inf. Says a computation that results in inf or nan is compile error.

Runtime behavior of NaN-producing math functions #3365

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions