[Mesa-dev] [RFC PATCH] Add GL_MESA_ieee_fp_alu_mode specification draft

[Matteo Bruni]

On Mon, Feb 24, 2020 at 8:21 PM Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>
> On Mon, Feb 24, 2020 at 1:10 PM Ian Romanick <idr at freedesktop.org> wrote:
> >
> > On 2/23/20 5:57 PM, Ilia Mirkin wrote:
> > > ---
> > >
> > > We talked about something like this a while back, but the end result
> > > was inconclusive. I added a TGSI MUL_ZERO_WINS shader property for nine.
> > > But it'd be nice for wine to be able to control this too.
> > >
> > > I couldn't actually find any evidence of the discussion from 2017 or so,
> > > so ... let's have another one.
> > >
> > >  docs/specs/MESA_ieee_fp_alu_mode.spec | 136 ++++++++++++++++++++++++++
> > >  1 file changed, 136 insertions(+)
> > >  create mode 100644 docs/specs/MESA_ieee_fp_alu_mode.spec
> > >
> > > diff --git a/docs/specs/MESA_ieee_fp_alu_mode.spec b/docs/specs/MESA_ieee_fp_alu_mode.spec
> > > new file mode 100644
> > > index 00000000000..cb274f06571
> > > --- /dev/null
> > > +++ b/docs/specs/MESA_ieee_fp_alu_mode.spec
> > > @@ -0,0 +1,136 @@
> > > +Name
> > > +
> > > +    MESA_ieee_fp_alu_mode
> > > +
> > > +Name Strings
> > > +
> > > +    GL_MESA_ieee_fp_alu_mode
> > > +
> > > +Contact
> > > +
> > > +    Ilia Mirkin, ilia 'at' x.org
> > > +
> > > +IP Status
> > > +
> > > +    No known IP issues.
> > > +
> > > +Status
> > > +
> > > +    Proposed
> > > +
> > > +Version
> > > +
> > > +Number
> > > +
> > > +    TBD
> > > +
> > > +Dependencies
> > > +
> > > +    OpenGL 3.0 or OpenGL ES 3.0 is required.
> > > +
> > > +    The extension is written against the OpenGL GL 3.0 and OpenGL ES 3.0
> > > +    specifications.
> > > +
> > > +Overview
> > > +
> > > +    Pre-GL3 hardware did not generally have full IEEE floating point operation
> > > +    support. Among other things, 0 * Infinity would work out to 0, and NaN's
> > > +    might not be generated, or otherwise be treated improperly. GL3-class and
> > > +    later hardware introduced full IEEE FP support, including NaN, Infinity,
> > > +    and the proper generation of these.
> > > +
> > > +    Some software targeted at older hardware makes assumptions about how the
> > > +    shader ALU works. And to accomodate these, GL3-class hardware has a way to
> > > +    change how the shader ALU behaves. There are no standards around this, and
> > > +    different hardware has different ways of dealing with it. However these
> > > +    modes were designed specifically with such older software in mind.
> > > +
> > > +    This extension introduces a way to configure a context to be in non-IEEE
> > > +    ALU mode. This extension does not specify precisely what this means, as
> > > +    each vendor has something different. Generally it means non-IEEE compliant
> > > +    handling of multiplication, as well as any other unspecified changes.
> >
> > I think many of the other things are specified.  They're the non-IEEE
> > behaviors of GL_ARB_vertex_program and GL_ARB_fragment_program, and
> > those mimic the required behavior of early DX shader models.  There are
> > a bunch of cases that specify that zero is generated when IEEE would
> > require NaN.
> >
> > If there's just a small handful of things like this, we'd probably be
> > better adding a couple new built-in functions to do the job.  The
> > problem on Intel hardware is... we really, really don't want to switch
> > to non-IEEE mode because it changes how a bunch of things work, and we
> > haven't tested any of that in many years.  I'd much rather put in some
> > kind of work-arounds for things that don't want multiplication or pow()
> > to generate NaN.
>
> So basically anything that ever involves multiplication needs to have
> these variants. Things like dot, the various crazy ops of days past
> whose names escape me but involve complex calculations, etc. Things
> like pow are questionable (depends on if they get decomposed or not),
> and things like rcp/rsq unquestionably produce NaN's (or Infinity,
> sorry not 100% sure but easily checked) on NVIDIA irrespective of that
> mode being enabled.
>
> Also on Intel hardware, as you mention, the "non-ieee" mode is ...
> interesting, so to allow for that, I didn't want to say anything other
> than the positive cases. If you have no interest in exposing this, I
> could rewrite this in a NVIDIA/AMD-friendly manner.
>
> >
> > As for the mechanism, I'm very strongly in favor of something that would
> > be locked-in when the shader is compiled.  I really want to avoid any
> > potential that an external glEnable could trigger a a recompile.
>
> Stefan Dösinger suggested a context flag on IRC. I'd be fine with that
> too, even if I have to go create 2 exts due to GLX/EGL.
>
> >
> > The more I think about it... having an extension that adds a handful
> > built-in functions that give old shader model behavior would be a good
> > idea.  We could even test it. :)  I've looked a lot of shaders, and I've
> > seen a lot of not-quite-what-they-wanted methods for avoiding NaN
> > behavior in a bunch of these functions.  Having a special version of
> > inversesqrt() that returns FLT_MAX for 0 would be useful to a lot of
> > users.  As part of the spec we could even provide canonical versions of
> > the functions so that users could copy-and-paste
>
> That would preclude nv50-series hardware from benefiting, since it's
> enabled/disabled context-wide there (see
> https://github.com/NVIDIA/open-gpu-doc/blob/master/classes/compute/cl50c0.h#L563
> for compute, but same deal for graphics). If the plan for Intel is to
> not implement this with a hardware flag change / separate instruction
> encodings, probably best to leave the whole ext unimplemented. The
> idea is to expose the hardware features that were used for DX9
> compatibility, not helper functions which software like WINE could
> very well implement on their own already (and apparently does in some
> wine-staging patches).

For reference, the wine-staging patch in question is
<https://github.com/wine-staging/wine-staging/blob/master/patches/wined3d-zero-inf-shaders/0001-wined3d-Add-a-setting-to-workaround-0-inf-problem-in.patch>.
Essentially it adds a three-state option: aside from the disabled
case, when set to '1' it forces a few specific opcodes (like RSQ,
which is the inversesqrt() Ian mentioned) to return FLT_MAX instead of
+Inf, while when set to '2' it enforces that any multiplication that
has one operand == 0.0 will have a result of 0.0.

I think setting '1' is enough for the vast majority of cases that we
know of, but not all. Setting '2' should always work but has,
unsurprisingly, a pretty significant performance impact.
What we would like to have is an extension that allows to exploit
whatever d3d9 compatibility feature the hardware already has so that
we can get the non-IEEE behavior "for free". An extension that just
moves the computation fixups from the shader source to the GL
implementation is... frankly not that interesting to us.