[Mesa-dev] Thoughts on fp64 for GLES?

[Ilia Mirkin]

On Thu, Feb 14, 2019 at 11:53 AM Erik Faye-Lund
<erik.faye-lund at collabora.com> wrote:
>
> On Thu, 2019-02-14 at 16:25 +0100, Gert Wollny wrote:
> > > > > On Wed, Feb 13, 2019 at 11:09 AM Elie Tournier <
> > > > > tournier.elie at gmail.com> wrote:
> > [...]
> > > > > >  A solution would be to inline the
> > > > > > function in GLSL but I'm scared than the following shader
> > > > > > will
> > > > > > be huge.
> > From my adventures in R600 Evergreen NIR land I can say that the
> > shaders with inlined functions get really huge, there were test cases
> > in the piglits that resulted in >64k temporaries in ssa form (For
> > using
> > the NIR lowering fp64 to the emulation code one has to convert the
> > shader to from vector to scalar operations first though, this may
> > make
> > the shader a bit longer too).
> >
> > > > > I suspect that's par for the course; the solution we pick will
> > > > > not be pretty either way.
> > > > >
> > > > > Another option is to send TGSI f64 down the wire and lower in
> > > > > the
> > > > > host, in virglrenderer, by emitting glsl helper functions which
> > > > > implement fp64 and calling those.
> > > >
> > > > Options are then:
> > > >
> > > > a) do an Apple on evergreen - export GL4.x don't expose the
> > > > ARB_gpu_shader_fp64 string, a lie, but a consistent lie.
> > > > b) do fp32 for all fp64 - conversion to/from fp64 is still messy,
> > > > but
> > > > might cover at least some basic tests
> > > > c) lower in guest - ugly tgsi, slow
> > > > d) lower in host - emulate in virglrenderer,
> > > >
> > > > I'm actually considering (d) might not be the worst solution, we
> > > > could in theory reuse the GLSL shaders code from mesa, and just
> > > > link
> > > > it in as another GLSL string.
> > > >
> > >
> > > I would propose a fifth "option":
> > >
> > > - Do a) and/or b) for now (i.e expose a not-technically-conformant
> > > 4.0)
> > I wonder why this was never done for r600/evergreen, and unless
> > conformance is the aim I'd say that this seems to be the best short
> > term option. When I look at the state of D-GL on GLES  hosts then I
> > think there are more important issues that need to be fixed (e.g.
> > KHR-
> > GL33 failures) than sinking much time in implementing an extension
> > that
> > is used by nearly nobody. (a) is probably better in case someone
> > wants
> > to use this and expects correct results, because then no result is
> > better then a result that is slightly off.
> >
> > > - Move to productize Zink, which:
> > >   1) Targets Vulkan, where FP64 is an optional feature that
> > > doesn't
> > >      require an extension
> > > (VkPhysicalDeviceFeatures::shaderFloat64).
> > >   2) Uses NIR, where lowering of FP64 is already supported for
> > > those
> > >      devices that doesn't support FP64.
> > I second that given that Vulkan is the next step anyway,
>
> I want to add to this that increasing the OpenGL version support on top
> of OpenGL ES with the current (non-vulkan) solution is going to be more
> and more difficult for each version, because fewer and fewer drivers
> are using TGSI, which means TGSI will start lagging more and more
> behind NIR in terms of functionality unless we put in a rather sizable
> effort to keep TGSI alive. There's good reasons why drivers are moving
> away from TGSI; it's a dated IR that even for its time didn't use
> modern compiler techniques.

As a counterpoint -- I've done a good fraction of the GL 4.x bringup
with TGSI, and it was very easy (at least the TGSI bits were). It's
easy to extend, it's easy to consume on the other side, and is
generally fairly unambiguous. I'm happy to continue extending it as
necessary, where warranted to support NVIDIA hardware capabilities.

Most of the difficulties tend to lie in glsl_to_tgsi, but I think
that's true of any IR conversion.

No driver should be using TGSI internally -- it's only meant to convey
the instruction stream, so any comments about how it's difficult to
modify are entirely true -- it is. I don't think it was ever meant to
be.

Cheers,

  -ilia