[Mesa-dev] Thoughts on fp64 for GLES?

[Gert Wollny]

> > > 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, 

Best, 
Gert