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? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
