On 6 March 2017 at 08:34, Michel Dänzer <mic...@daenzer.net> wrote: > On 04/03/17 05:32 AM, Jason Ekstrand wrote: >> On Fri, Mar 3, 2017 at 11:41 AM, Ilia Mirkin <imir...@alum.mit.edu >> <mailto:imir...@alum.mit.edu>> wrote: >> >> On Fri, Mar 3, 2017 at 2:16 PM, Jason Ekstrand <ja...@jlekstrand.net >> <mailto:ja...@jlekstrand.net>> wrote: >> > Hey Elie! >> > >> > On Fri, Mar 3, 2017 at 8:22 AM, Elie Tournier <tournier.e...@gmail.com >> <mailto:tournier.e...@gmail.com>> >> > wrote: >> >> >> >> From: Elie Tournier <elie.tourn...@collabora.com >> <mailto:elie.tourn...@collabora.com>> >> >> >> >> This series is based on Ian's work about GL_ARB_gpu_shader_int64 [1]. >> >> The goal is to expose GL_ARB_shader_fp64 to OpenGL 3.0 GPUs. >> >> >> >> Each function can be independently tested using shader_runner from >> piglit. >> >> The piglit files are stored on github [2]. >> >> >> >> [1] >> >> >> https://lists.freedesktop.org/archives/mesa-dev/2016-November/136718.html >> >> <https://lists.freedesktop.org/archives/mesa-dev/2016-November/136718.html> >> >> [2] https://github.com/Hopetech/libSoftFloat >> <https://github.com/Hopetech/libSoftFloat> >> > >> > >> > Glad to see this finally turning into code. >> > >> > Before, we get too far into things, I'd like to talk about the >> approach a >> > bit. First off, if we (Intel) are going to use this on any hardware, >> we >> > would really like it to be in NIR. The reason for this is that NIR >> has a >> > much more powerful algebraic optimizer than GLSL IR and we would like >> to >> > have as few fp64 instructions as possible before we start lowering >> them to >> > piles of integer math. I believe Ian's plan for this was that someone >> would >> > write a nir_builder back-end for the stand-alone compiler. >> Unfortunately, >> > he sort-of left that as "an exercise to the reader" and no code exists >> to my >> > knowledge. If we're going to write things in GLSL, we really need >> that NIR >> > back-end. >> >> I'm not sure what the impetus was for developing a softfloat library >> (but I'm a big fan). but the current situation is that it will largely >> just be useful for AMD Evergreen/Northern Islands chips, which consume >> TGSI produced from GLSL. (Aside: [1].) As such, I'm not sure if a push >> towards NIR is warranted -- it would cause a more convoluted path >> towards the intended target. >> >> >> Whether or not i965 wants softfloat is an ongoing debate. On the one >> hand, we have "hardware support" for it starting with ivy bridge. On >> the other hand, early hardware support is sufficiently terrible that >> softfloat may end up being a better plan. Also, I wouldn't be surprised >> if, at some point in the future, some hardware engineer decides they can >> save a bunch of power on low-power parts if they delete the fp64 >> hardware. Since we ship desktop GL on those parts, loosing 4.0 would be >> bad. I don't want to paint ourselves into a corner on fp64. > > Doing it in NIR would make it useless for r600. What's your suggestion > for that? > How about we allows drivers to opt-in for this ? There's already a bunch in gl_shader_compiler_options that we toggle. This will allow Elie's work to land and be [at least partially] useful in the interim.
-Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
