On Thu, Mar 23, 2017 at 11:51 AM, tournier.elie <tournier.e...@gmail.com> wrote: > Hello, > > It's seems impossible to expose all the drivers to soft fp64 with one > piece of code. > So what do you think about landing this series (with some fix) for r600? > > The other drivers will use the NIR version of soft fp64. > BTW, an "alpha RFC" series is coming on the ML soonish.
Sounds good to me. Thanks, Alex > > Elie > > On 13 March 2017 at 17:00, tournier.elie <tournier.e...@gmail.com> wrote: >> To resume, using NIR resolve some troubles: fp64 can be use by Intel, >> no autogen code, SPIR-V on OpenGL. >> So if nobody opposes (too hard), i will start implement fp64 in NIR. >> >> But NIR doesn't solve everything. How to handle drivers without NIR >> support like r600? Should we land the GLSL IR version of fp64 for >> that? >> I know this imply code duplication but at least GL_ARB_gpu_shader_fp64 >> will be available for r600. >> >> On 11 March 2017 at 18:51, Jason Ekstrand <ja...@jlekstrand.net> wrote: >>> On Sat, Mar 11, 2017 at 9:50 AM, Jason Ekstrand <ja...@jlekstrand.net> >>> wrote: >>>> >>>> >>>> As I said at the top, I'm really not going for NIR or nothing. I agree >>>> that GLSL has advantages for chips like r600 which badly needs emulation >>>> and >>>> isn't moving to NIR any time soon. Also, fp64 isn't a requirement in >>>> Vulkan >>>> and, given that Vulkan covers both desktop and mobile, likely won't be any >>>> time soon. (In fact, if someone wanted Vulkan FP64 on hardware that didn't >>>> support it, I'd be tempted to tell them to pay someone to write a layer.) >>>> However, *if* we decide that emulated fp64 is better on, for instance Ivy >>>> Bridge, *and* we had customers that cared about it (I don't know of any), >>>> then doing it in NIR could yield substantially better results (depending on >>>> initial shader quality) due to being able to run nir_opt_algebraic first. >>>> Those are a lot of ifs so maybe I'm suggesting we design for a >>>> non-use-case, >>>> but I really don't want to paint ourselves into a corner that we have to >>>> crawl out of 2 years from now. >>> >>> >>> Chatting with people on IRC this morning, I realized there's a killer >>> argument for why we *need* NIR support: SPIR-V on OpenGL. As soon as you >>> expose the GL_ARB_spirv extension on an OpenGL 4.0+ driver, you must support >>> fp64. If we ever need emulated fp64 in such a driver, the lowering has to >>> be done in NIR because there is no GLSL IR in the path. > _______________________________________________ > 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
