[Mesa-dev] [RFC 00/11] GL_ARB_gpu_shader_fp64

[Michel Dänzer]

On 04/03/17 05:32 AM, Jason Ekstrand wrote:
> On Fri, Mar 3, 2017 at 11:41 AM, Ilia Mirkin <imirkin at alum.mit.edu
> <mailto:imirkin at alum.mit.edu>> wrote:
> 
>     On Fri, Mar 3, 2017 at 2:16 PM, Jason Ekstrand <jason at jlekstrand.net
>     <mailto:jason at jlekstrand.net>> wrote:
>     > Hey Elie!
>     >
>     > On Fri, Mar 3, 2017 at 8:22 AM, Elie Tournier <tournier.elie at gmail.com <mailto:tournier.elie at gmail.com>>
>     > wrote:
>     >>
>     >> From: Elie Tournier <elie.tournier at collabora.com <mailto:elie.tournier at 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