On Wednesday, 13 February 2019, Stéphane Marchesin <<a href="mailto:stephane.marchesin@gmail.com">stephane.marchesin@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Feb 13, 2019 at 10:29 AM Elie Tournier <<a href="mailto:tournier.elie@gmail.com">tournier.elie@gmail.com</a>> wrote: > > > > On Wednesday, 13 February 2019, Ilia Mirkin <<a href="mailto:imirkin@alum.mit.edu">imirkin@alum.mit.edu</a>> wrote: >> >> On Wed, Feb 13, 2019 at 12:47 PM Elie Tournier <<a href="mailto:tournier.elie@gmail.com">tournier.elie@gmail.com</a>> 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 <<a href="mailto:gw.fossdev@gmail.com">gw.fossdev@gmail.com</a>> 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? </blockquote><div>Hi Stéphane,</div><div> </div><div>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.</div><div>A solution would be to inline the function in GLSL but I'm scared than the following shader will be huge.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Stéphane >> >> >> -ilia </blockquote>