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

[Emil Velikov]

On 6 March 2017 at 08:34, Michel Dänzer <michel at daenzer.net> wrote:
> 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?
>
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