On Fri, Jan 13, 2017 at 8:43 AM, Marek Olšák <[email protected]> wrote:
> On Fri, Jan 13, 2017 at 5:25 PM, Jason Ekstrand <[email protected]> > wrote: > > On Fri, Jan 13, 2017 at 4:05 AM, Marek Olšák <[email protected]> wrote: > >> > >> On Fri, Jan 13, 2017 at 3:37 AM, Ilia Mirkin <[email protected]> > wrote: > >> > On Thu, Jan 12, 2017 at 9:13 PM, Jason Ekstrand <[email protected] > > > >> > wrote: > >> >> Unless, of course, it's controlled by the same hardware bit... > Clearly, > >> >> we > >> >> can can give you abs on rsq without denorm flushing (easy shader > hacks) > >> >> but > >> >> not the other way around. > >> > > >> > OK, so somehow I missed that earlier. However there's an interesting > >> > section in the PRM: > >> > > >> > > >> > https://01.org/sites/default/files/documentation/intel-gfx- > prm-osrc-skl-vol07-3d_media_gpgpu.pdf > >> > > >> > on PDF page 854, "Dismissed Legacy Behaviors" which has a list of > >> > suggested IEEE 754 deviations for DX9. One of them is indeed that 0 * > >> > x = 0, but another is that input NaNs be propagated with certain > >> > exceptions. Also they suggest that RCP(0)/RSQ(0) = fmax. Interesting. > >> > > >> > So at this point, the zero_wins thing is pretty much blown. i965 > >> > appears to have an all-or-nothing approach, and additionally that > >> > approach doesn't match up exactly to what NVIDIA does (or at least I'm > >> > not aware of a clamp-everything mode). > >> > > >> > This will take some thought to figure out how something can be > >> > specified so that a single spec works for both i965 and nv/amd. OTOH > >> > we could have two different specs that just expose different things - > >> > e.g. i965 could expose a MESA_shader_float_alt_mode or whatever which > >> > is spec'd to do the things that the PRM says, and nv/amd have the > >> > MESA_shader_float_zero_wins ext which does what we were talking about > >> > earlier. > >> > > >> > I'm open to other suggestions too. > >> > >> There is also the "small" problem that it would take a non-trivial > >> effort for us on the LLVM side. You guys can flip a switch. We can't. > > > > > > Don't you have to expend that effort for ARB programs anyway? I thought > > they weren't supposed to generate NaN either. > > No, we don't, because st/mesa adds abs before RSQ and the driver > implements POW as log+mul+exp, where mul follows the rule > 0*anything=0. I don't think any other opcode follows that rule though. > Ah. That makes sense. Do you also implement DIV as MUL+RCP? If so, the two of those should take care of NaN getting generated in the shader. We'd still have to do something about inf and maybe denorms.
_______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
