[Mesa-dev] Thoughts on fp64 for GLES?

[Dave Airlie]

On Thu, 14 Feb 2019 at 06:04, Stéphane Marchesin
<stephane.marchesin at gmail.com> wrote:
>
> On Wed, Feb 13, 2019 at 11:09 AM Elie Tournier <tournier.elie at gmail.com> wrote:
> >
> >
> >
> > On Wednesday, 13 February 2019, Stéphane Marchesin <stephane.marchesin at gmail.com> wrote:
> >>
> >> On Wed, Feb 13, 2019 at 10:29 AM 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.
> >>
> >>
> >> Yes, at a high level, softfp64 seems to solve the problem we have. If
> >> a TGSI lowering pass is too complex, could we do it as a GLSL lowering
> >> pass?
> >>
> > Hi Stéphane,
> >
> > Currently, we lower everything in GLSL then we convert to TGSI. The issue is that the lowering pass generate something like 'call _umul builtin'. Then we try to convert it to TGSI. The problem appears here.
> > A solution would be to inline the function in GLSL but I'm scared than the following shader will be huge.
>
> 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.

Dave.