<br><br>On Wednesday, 13 February 2019, Ilia Mirkin <<a href="mailto:imirkin@alum.mit.edu">imirkin@alum.mit.edu</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Feb 13, 2019 at 12:47 PM Elie Tournier <<a href="mailto:tournier.elie@gmail.com">tournier.elie@gmail.com</a>> wrote:<br>
><br>
> On Fri, Jan 25, 2019 at 11:52:56AM -0800, Stéphane Marchesin wrote:<br>
> > On Fri, Jan 25, 2019 at 2:25 AM Gert Wollny <<a href="mailto:gw.fossdev@gmail.com">gw.fossdev@gmail.com</a>> wrote:<br>
> > ><br>
> > > Am Donnerstag, den 24.01.2019, 22:25 -0800 schrieb Stéphane Marchesin:<br>
> > > ><br>
> > > > Yes, it's for running virgl on top of GLES. To emulate fp64 in GL on<br>
> > > > the guest side, we need fp64 on the host...<br>
> > ><br>
> > > BTW: we could also get it emulated from the guest side. When Elie (in<br>
> > > CC)  initially proposed the fp64 emulation series it was for r600 and<br>
> > > TGSI was emitted. The created shaders are horribly long and it is<br>
> > > certainly not performant, but if it's just for getting OpenGL 4.0<br>
> > > exposed it should be good enough.<br>
> ><br>
> > Yes, Ilia suggested this on IRC yesterday. My impression is that not<br>
> > many applications/games need high performance fp64 (it's likely mostly<br>
> > compute stuff, which is not our target). I could be wrong though. If<br>
> > anyone knows differently, please tell us :)<br>
> ><br>
> > ><br>
> > > I'm not sure though how much work it would be to add this to the soft<br>
> > > fp64 as it has now landed for NIR, though.<br>
> ><br>
> > Yes, with virgl not using NIR, I am not sure how much work soft fp64<br>
> > will require.<br>
><br>
> I spent a bit of time on the project recently.<br>
> My thinking so far:<br>
> * FP64 is bad . But everyone knows that. :)<br>
> * Using the current soft fp64 require to emulate int64.<br>
> * Soft fp64 and int64 involve function call which is, iiuc, not really<br>
> supported in TGSI.<br>
> * Soft fp64 is tied to NIR. Some pass/hack need to be port to GLSLIR.<br>
><br>
> So the project will require a lot of work.<br>
<br>
But what's the alternative? Let's say you make a spec to expose<br>
"proper" fp64 in GLES. No one outside mesa will implement this (why<br>
bother). Certainly not the Adreno/Mali proprietary stacks of the<br>
world.</blockquote><div><br></div><div>I'm not saying that we should get an extension.</div><div>My point was, it's a lot of work.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
And if you are on a stack that implements this in GLES, you might as<br>
well be using desktop GL anyways...<br>
<br>
So going back to the original -- what use-case are you trying to cover<br>
that's not already covered some other way?</blockquote><div><br></div><div>iiuc, Stephane want to run GL desktop on top of GLES.</div><div>In order to expose a bigger version of GL, he need fp64 support. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
  -ilia<br>
</blockquote>