[Mesa-dev] Thoughts on fp64 for GLES?

[Ilia Mirkin]

On Wed, Feb 13, 2019 at 12:47 PM Elie Tournier <tournier.elie at gmail.com> wrote:
>
> On Fri, Jan 25, 2019 at 11:52:56AM -0800, Stéphane Marchesin wrote:
> > On Fri, Jan 25, 2019 at 2:25 AM Gert Wollny <gw.fossdev at gmail.com> wrote:
> > >
> > > Am Donnerstag, den 24.01.2019, 22:25 -0800 schrieb Stéphane Marchesin:
> > > >
> > > > Yes, it's for running virgl on top of GLES. To emulate fp64 in GL on
> > > > the guest side, we need fp64 on the host...
> > >
> > > BTW: we could also get it emulated from the guest side. When Elie (in
> > > CC)  initially proposed the fp64 emulation series it was for r600 and
> > > TGSI was emitted. The created shaders are horribly long and it is
> > > certainly not performant, but if it's just for getting OpenGL 4.0
> > > exposed it should be good enough.
> >
> > Yes, Ilia suggested this on IRC yesterday. My impression is that not
> > many applications/games need high performance fp64 (it's likely mostly
> > compute stuff, which is not our target). I could be wrong though. If
> > anyone knows differently, please tell us :)
> >
> > >
> > > I'm not sure though how much work it would be to add this to the soft
> > > fp64 as it has now landed for NIR, though.
> >
> > Yes, with virgl not using NIR, I am not sure how much work soft fp64
> > will require.
>
> I spent a bit of time on the project recently.
> My thinking so far:
> * FP64 is bad . But everyone knows that. :)
> * Using the current soft fp64 require to emulate int64.
> * Soft fp64 and int64 involve function call which is, iiuc, not really
> supported in TGSI.
> * Soft fp64 is tied to NIR. Some pass/hack need to be port to GLSLIR.
>
> So the project will require a lot of work.

But what's the alternative? Let's say you make a spec to expose
"proper" fp64 in GLES. No one outside mesa will implement this (why
bother). Certainly not the Adreno/Mali proprietary stacks of the
world.

And if you are on a stack that implements this in GLES, you might as
well be using desktop GL anyways...

So going back to the original -- what use-case are you trying to cover
that's not already covered some other way?

  -ilia