[Mesa-dev] Thoughts on fp64 for GLES?

[Erik Faye-Lund]

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.