Re: [Mesa-dev] Thoughts on fp64 for GLES?
On Thu, Feb 14, 2019 at 11:53 AM Erik Faye-Lund wrote: > > On Thu, 2019-02-14 at 16:25 +0100, Gert Wollny wrote: > > > > > On Wed, Feb 13, 2019 at 11:09 AM Elie Tournier < > > > > > tournier.e...@gmail.com> wrote: > > [...] > > > > > > A solution would be to inline the > > > > > > function in GLSL but I'm scared than the following shader > > > > > > will > > > > > > be huge. > > From my adventures in R600 Evergreen NIR land I can say that the > > shaders with inlined functions get really huge, there were test cases > > in the piglits that resulted in >64k temporaries in ssa form (For > > using > > the NIR lowering fp64 to the emulation code one has to convert the > > shader to from vector to scalar operations first though, this may > > make > > the shader a bit longer too). > > > > > > > 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) > > I wonder why this was never done for r600/evergreen, and unless > > conformance is the aim I'd say that this seems to be the best short > > term option. When I look at the state of D-GL on GLES hosts then I > > think there are more important issues that need to be fixed (e.g. > > KHR- > > GL33 failures) than sinking much time in implementing an extension > > that > > is used by nearly nobody. (a) is probably better in case someone > > wants > > to use this and expects correct results, because then no result is > > better then a result that is slightly off. > > > > > - 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. > > I second that given that Vulkan is the next step anyway, > > I want to add to this that increasing the OpenGL version support on top > of OpenGL ES with the current (non-vulkan) solution is going to be more > and more difficult for each version, because fewer and fewer drivers > are using TGSI, which means TGSI will start lagging more and more > behind NIR in terms of functionality unless we put in a rather sizable > effort to keep TGSI alive. There's good reasons why drivers are moving > away from TGSI; it's a dated IR that even for its time didn't use > modern compiler techniques. As a counterpoint -- I've done a good fraction of the GL 4.x bringup with TGSI, and it was very easy (at least the TGSI bits were). It's easy to extend, it's easy to consume on the other side, and is generally fairly unambiguous. I'm happy to continue extending it as necessary, where warranted to support NVIDIA hardware capabilities. Most of the difficulties tend to lie in glsl_to_tgsi, but I think that's true of any IR conversion. No driver should be using TGSI internally -- it's only meant to convey the instruction stream, so any comments about how it's difficult to modify are entirely true -- it is. I don't think it was ever meant to be. Cheers, -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Thoughts on fp64 for GLES?
On Thu, 2019-02-14 at 16:25 +0100, Gert Wollny wrote: > > > > On Wed, Feb 13, 2019 at 11:09 AM Elie Tournier < > > > > tournier.e...@gmail.com> wrote: > [...] > > > > > A solution would be to inline the > > > > > function in GLSL but I'm scared than the following shader > > > > > will > > > > > be huge. > From my adventures in R600 Evergreen NIR land I can say that the > shaders with inlined functions get really huge, there were test cases > in the piglits that resulted in >64k temporaries in ssa form (For > using > the NIR lowering fp64 to the emulation code one has to convert the > shader to from vector to scalar operations first though, this may > make > the shader a bit longer too). > > > > > 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) > I wonder why this was never done for r600/evergreen, and unless > conformance is the aim I'd say that this seems to be the best short > term option. When I look at the state of D-GL on GLES hosts then I > think there are more important issues that need to be fixed (e.g. > KHR- > GL33 failures) than sinking much time in implementing an extension > that > is used by nearly nobody. (a) is probably better in case someone > wants > to use this and expects correct results, because then no result is > better then a result that is slightly off. > > > - 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. > I second that given that Vulkan is the next step anyway, I want to add to this that increasing the OpenGL version support on top of OpenGL ES with the current (non-vulkan) solution is going to be more and more difficult for each version, because fewer and fewer drivers are using TGSI, which means TGSI will start lagging more and more behind NIR in terms of functionality unless we put in a rather sizable effort to keep TGSI alive. There's good reasons why drivers are moving away from TGSI; it's a dated IR that even for its time didn't use modern compiler techniques. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Thoughts on fp64 for GLES?
> > > On Wed, Feb 13, 2019 at 11:09 AM Elie Tournier < > > > tournier.e...@gmail.com> wrote: > > > > [...] > > > > A solution would be to inline the > > > > function in GLSL but I'm scared than the following shader will > > > > be huge. From my adventures in R600 Evergreen NIR land I can say that the shaders with inlined functions get really huge, there were test cases in the piglits that resulted in >64k temporaries in ssa form (For using the NIR lowering fp64 to the emulation code one has to convert the shader to from vector to scalar operations first though, this may make the shader a bit longer too). > > > 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) I wonder why this was never done for r600/evergreen, and unless conformance is the aim I'd say that this seems to be the best short term option. When I look at the state of D-GL on GLES hosts then I think there are more important issues that need to be fixed (e.g. KHR- GL33 failures) than sinking much time in implementing an extension that is used by nearly nobody. (a) is probably better in case someone wants to use this and expects correct results, because then no result is better then a result that is slightly off. > - 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. I second that given that Vulkan is the next step anyway, Best, Gert ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Thoughts on fp64 for GLES?
On Thu, 2019-02-14 at 08:53 +1000, Dave Airlie wrote: > On Thu, 14 Feb 2019 at 06:04, Stéphane Marchesin > 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)
Re: [Mesa-dev] Thoughts on fp64 for GLES?
On Thu, 14 Feb 2019 at 06:04, Stéphane Marchesin wrote: > > On Wed, Feb 13, 2019 at 11:09 AM Elie Tournier > wrote: > > > > > > > > On Wednesday, 13 February 2019, Stéphane Marchesin > > wrote: > >> > >> On Wed, Feb 13, 2019 at 10:29 AM Elie Tournier > >> wrote: > >> > > >> > > >> > > >> > On Wednesday, 13 February 2019, Ilia Mirkin wrote: > >> >> > >> >> On Wed, Feb 13, 2019 at 12:47 PM Elie Tournier > >> >> 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 > >> >> > > 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. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Thoughts on fp64 for GLES?
On Wed, Feb 13, 2019 at 11:09 AM Elie Tournier wrote: > > > > On Wednesday, 13 February 2019, Stéphane Marchesin > wrote: >> >> On Wed, Feb 13, 2019 at 10:29 AM Elie Tournier >> wrote: >> > >> > >> > >> > On Wednesday, 13 February 2019, Ilia Mirkin wrote: >> >> >> >> On Wed, Feb 13, 2019 at 12:47 PM Elie Tournier >> >> 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 >> >> > > 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. Stéphane > >> >> Stéphane >> >> >> >> >> >> >> -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Thoughts on fp64 for GLES?
On Wednesday, 13 February 2019, Stéphane Marchesin < stephane.marche...@gmail.com> wrote: > On Wed, Feb 13, 2019 at 10:29 AM Elie Tournier > wrote: > > > > > > > > On Wednesday, 13 February 2019, Ilia Mirkin > wrote: > >> > >> On Wed, Feb 13, 2019 at 12:47 PM Elie Tournier > 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 > 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. > Stéphane > > >> > >> > >> -ilia > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Thoughts on fp64 for GLES?
On Wed, Feb 13, 2019 at 10:29 AM Elie Tournier wrote: > > > > On Wednesday, 13 February 2019, Ilia Mirkin wrote: >> >> On Wed, Feb 13, 2019 at 12:47 PM Elie Tournier >> 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 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? Stéphane >> >> >> -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Thoughts on fp64 for GLES?
On Wednesday, 13 February 2019, Ilia Mirkin wrote: > On Wed, Feb 13, 2019 at 1:29 PM Elie Tournier > wrote: > > > > > > > > On Wednesday, 13 February 2019, Ilia Mirkin > wrote: > >> > >> On Wed, Feb 13, 2019 at 12:47 PM Elie Tournier > 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 > 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 > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Thoughts on fp64 for GLES?
On Wed, Feb 13, 2019 at 1:29 PM Elie Tournier wrote: > > > > On Wednesday, 13 February 2019, Ilia Mirkin wrote: >> >> On Wed, Feb 13, 2019 at 12:47 PM Elie Tournier >> 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 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? -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Thoughts on fp64 for GLES?
On Wednesday, 13 February 2019, Ilia Mirkin wrote: > On Wed, Feb 13, 2019 at 12:47 PM Elie Tournier > 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 > 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. > > -ilia > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Thoughts on fp64 for GLES?
On Wed, Feb 13, 2019 at 12:47 PM Elie Tournier 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 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. 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? -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Thoughts on fp64 for GLES?
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 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. Elie > > Stéphane > > > > > > Best, > > Gert > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Thoughts on fp64 for GLES?
On Fri, Jan 25, 2019 at 02:15:25PM -0600, Jason Ekstrand wrote: > On Fri, Jan 25, 2019 at 1:53 PM Stéphane Marchesin < > stephane.marche...@gmail.com> wrote: > > > On Fri, Jan 25, 2019 at 2:25 AM Gert Wollny 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 :) > > > > In our experience, we have yet to see an app actually use the extension. > If we do have such apps, it'd be better to do it in hardware when > available. However, if it's just so that you can claim support, maybe a > GLES extension isn't worth the bother? I don't have a particularly strong > opinion at the moment beyond "fp64 sounds like the most non-ES thing ever". Out of curiousity, what did you want to put in that extension? > > > > > > > > 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. > > > > The core of the soft fp64 stuff is a library of GLSL functions which > actually implement it. We just compile them to NIR and then lower fp64 > math to function calls and inline. You could write a lowering pass in > GLSL, TGSI, or a back-end compiler based on those easily enough. I think the best option is to write a lowering pass in GLSL to be able to use some optimizations later on. I will see if I can come up with a proof-of-concept. > > --Jason > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Thoughts on fp64 for GLES?
On Fri, Jan 25, 2019 at 1:53 PM Stéphane Marchesin < stephane.marche...@gmail.com> wrote: > On Fri, Jan 25, 2019 at 2:25 AM Gert Wollny 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 :) > In our experience, we have yet to see an app actually use the extension. If we do have such apps, it'd be better to do it in hardware when available. However, if it's just so that you can claim support, maybe a GLES extension isn't worth the bother? I don't have a particularly strong opinion at the moment beyond "fp64 sounds like the most non-ES thing ever". > > > > 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. > The core of the soft fp64 stuff is a library of GLSL functions which actually implement it. We just compile them to NIR and then lower fp64 math to function calls and inline. You could write a lowering pass in GLSL, TGSI, or a back-end compiler based on those easily enough. --Jason ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Thoughts on fp64 for GLES?
On Fri, Jan 25, 2019 at 2:25 AM Gert Wollny 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. Stéphane > > Best, > Gert > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Thoughts on fp64 for GLES?
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. 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. Best, Gert ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Thoughts on fp64 for GLES?
On 1/25/19 8:25 AM, Stéphane Marchesin wrote: On Thu, Jan 24, 2019 at 10:17 PM Tapani Pälli wrote: Hi; On 1/25/19 4:57 AM, Stéphane Marchesin wrote: Hi, We'd like to expose fp64 functionality on Chrome OS where we only have GLES. It seems like a simple approach is to enable this extension for GLES: https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_gpu_shader_fp64.txt Anyone knows if what's the right thing to do? It seems to me that the extension might just work on GLES without any changes, but I could be missing something. Sorry for not responding the the actual question but could you share the usecase? Back when this was enabled for HW that supports it we did not find applications (just some fractal shadertoy things), would be interesting to know how it is being used. 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... OK thanks. One thing that comes to mind (specific to GLSL ES) is that should double type have precision qualifier support? Maybe some specific rules what happens when expression has both floats and doubles with some precision qualifiers ... there might be a lot more things to this but this is what comes first to my mind. // Tapani ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Thoughts on fp64 for GLES?
On Thu, Jan 24, 2019 at 10:17 PM Tapani Pälli wrote: > > Hi; > > On 1/25/19 4:57 AM, Stéphane Marchesin wrote: > > Hi, > > > > We'd like to expose fp64 functionality on Chrome OS where we only have > > GLES. It seems like a simple approach is to enable this extension for > > GLES: > > https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_gpu_shader_fp64.txt > > > > Anyone knows if what's the right thing to do? It seems to me that the > > extension might just work on GLES without any changes, but I could be > > missing something. > > Sorry for not responding the the actual question but could you share the > usecase? Back when this was enabled for HW that supports it we did not > find applications (just some fractal shadertoy things), would be > interesting to know how it is being used. 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... Stéphane > > Thanks; > > // Tapani > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Thoughts on fp64 for GLES?
Hi; On 1/25/19 4:57 AM, Stéphane Marchesin wrote: Hi, We'd like to expose fp64 functionality on Chrome OS where we only have GLES. It seems like a simple approach is to enable this extension for GLES: https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_gpu_shader_fp64.txt Anyone knows if what's the right thing to do? It seems to me that the extension might just work on GLES without any changes, but I could be missing something. Sorry for not responding the the actual question but could you share the usecase? Back when this was enabled for HW that supports it we did not find applications (just some fractal shadertoy things), would be interesting to know how it is being used. Thanks; // Tapani ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
