On Thu, Jan 12, 2017 at 7:46 PM, Matt Turner <matts...@gmail.com> wrote: > On Thu, Jan 12, 2017 at 3:20 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: >> On Thu, Jan 12, 2017 at 6:04 PM, Nicolai Hähnle <nhaeh...@gmail.com> wrote: >>> On 12.01.2017 23:46, Ilia Mirkin wrote: >>>> >>>> On Thu, Jan 12, 2017 at 4:03 PM, Matteo Bruni <matteo.myst...@gmail.com> >>>> wrote: >>>>> >>>>> So, what would be really nice to have is a GLSL extension for some >>>>> kind of switch to select the requested behavior WRT NaN. For example a >>>>> three-way option with "don't generate NaN in arithmetic operations", >>>>> "do generate NaN" and "don't care". It could also be a GL state if >>>>> that's easier to implement with the existing hardware, since an >>>>> individual application isn't supposed to require different behavior >>>>> from one shader to the next. >>>>> >>>>> Is anyone interested in / favorable to something like this? It would >>>>> solve the issue with defining NaN behavior in GLSL while making things >>>>> a bit more compatible with "other API a lot of games are ported from >>>>> which happens to be supported by all the desktop GPUs". >>>> >>>> >>>> Not that I'm biased, but on the NVIDIA Tesla series (G80-GT21x), this >>>> enable is handled via a global flag, not in the shader binary, so this >>>> is all-or-nothing for a whole pipeline. On GF100+, I believe there is >>>> also an enable via a global flag, but there are also a FMUL.FMZ (and >>>> FFMA.FMZ) flag, which I *think* has the same effect. So for GF100+ hw, >>>> this could be done at the instruction level. >>> >>> >>> Well, I would also have advocated for what is effectively a >>> per-program/pipeline flag anyway, even though GCN hardware can theoretically >>> do it per-instruction. Tracking a per-instruction bit in the compiler >>> quickly becomes fragile (e.g. there's no good way for us to model this >>> information per-instruction in LLVM IR). Per-shader isn't any better than >>> per-instruction due to linking, and per-shader-stage is awkward if we ever >>> want to do fancier cross-stage optimizations. >>> >>> It's really quite simple. Introduce an extension with a name like >>> MESA_shader_float_dx9. The behavior I'd suggest is: >>> >>> Enabling/requiring the extension in a shader causes various semantics >>> changes to bring floating point behavior in line with DX9 in that shader's >>> code: >>> >>> - 0*x = 0 >> >> Yes. But only for fp32, not for fp64. >> >>> - sqrt/rsqrt are guaranteed to take the absolute value of their argument >> >> Is that necessary? If the software knows about the ext, it also knows >> to stick the abs() in. > > Is there a compelling reason to make the extension offer just one of > these many behavior differences? > > FWIW, i965 has IEEE and "ALT" floating-point modes. ALT, I think > corresponds to d3d9 behavior, and its description says > > A floating-point execution mode that maps +/- inf to +/- fmax, +/- > denorm to +/-0, and NaN to +0 at the FPU inputs and never produces > infinities, denormals, or NaN values as outputs.
Interesting. I believe on NVIDIA hardware, it's just float multiply that's affected. > > Also: Extended mathematics functions of log(), rsq() and sqrt() take > the absolute value of the sources before computation to avoid > generating INF and NaN results. > > If those two behaviors correspond to d3d9 behavior, I wouldn't want an > extension that offered only the "zero wins" behavior and expected > applications to insert abs(). Really? That creates ARB_gpu_shader5-style extensions which do 75 different things and that you can't expose if you can only do 74 of them. I think in the past we've avoided things like having "d3d9 mode" in gallium API's - it's nice for these things to be individually enumerated. I like the direction that e.g. ARB_clip_control went in - make it all configurable individually instead of bundling unrelated things together. This has allowed e.g. dolphin to do things in OpenGL that are impossible on DX. And whether 0 * x = 0 or not seems rather unrelated from whether rsq takes abs of its args. -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
