> > > On Wed, Feb 13, 2019 at 11:09 AM Elie Tournier < > > > [email protected]> 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 [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
