On Thu, 2019-02-14 at 08:53 +1000, Dave Airlie wrote:
> On Thu, 14 Feb 2019 at 06:04, Stéphane Marchesin
> <stephane.marche...@gmail.com> wrote:
> > On Wed, Feb 13, 2019 at 11:09 AM Elie Tournier <
> > tournier.e...@gmail.com> wrote:
> > >
> > >
> > > On Wednesday, 13 February 2019, Stéphane Marchesin <
> > > stephane.marche...@gmail.com> wrote:
> > > > On Wed, Feb 13, 2019 at 10:29 AM Elie Tournier <
> > > > tournier.e...@gmail.com> wrote:
> > > > >
> > > > >
> > > > > On Wednesday, 13 February 2019, Ilia Mirkin <
> > > > > imir...@alum.mit.edu> wrote:
> > > > > > On Wed, Feb 13, 2019 at 12:47 PM Elie Tournier <
> > > > > > tournier.e...@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.foss...@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.
>
I would propose a fifth "option":
- Do a) and/or b) for now (i.e expose a not-technically-conformant 4.0)
- 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.
Of course I'm biased here since Zink is my baby, but I really believe
this is a better way forward. Adding more string-based lowering in
virglrenderer doesn't sound very palatable to me.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
