[Mesa-dev] Thoughts on fp64 for GLES?

[Elie Tournier]

On Wednesday, 13 February 2019, Ilia Mirkin <imirkin at alum.mit.edu> wrote:

> On Wed, Feb 13, 2019 at 1:29 PM Elie Tournier <tournier.elie at gmail.com>
> wrote:
> >
> >
> >
> > On Wednesday, 13 February 2019, Ilia Mirkin <imirkin at alum.mit.edu>
> wrote:
> >>
> >> 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.
> >
> >
> > I'm not saying that we should get an extension.
> > My point was, it's a lot of work.
> >>
> >>
> >> 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?
> >
> >
> > iiuc, Stephane want to run GL desktop on top of GLES.
> > In order to expose a bigger version of GL, he need fp64 support.
>
> Right, I get that high-level desire. But it seems like if the
> extension route is taken, this will only happen for cases where a
> desktop GL driver is readily available as well already, so why the
> requirement to run on GLES?


No, the host will only support GLES.
To be fair, I would prefer to avoid the extension route.

>
>   -ilia
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20190213/306f2696/attachment-0001.html>