<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Mar 3, 2017 at 11:41 AM, Ilia Mirkin <span dir="ltr"><<a href="mailto:imirkin@alum.mit.edu" target="_blank">imirkin@alum.mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Mar 3, 2017 at 2:16 PM, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br>
> Hey Elie!<br>
><br>
> On Fri, Mar 3, 2017 at 8:22 AM, Elie Tournier <<a href="mailto:tournier.elie@gmail.com">tournier.elie@gmail.com</a>><br>
> wrote:<br>
>><br>
>> From: Elie Tournier <<a href="mailto:elie.tournier@collabora.com">elie.tournier@collabora.com</a>><br>
>><br>
>> This series is based on Ian's work about GL_ARB_gpu_shader_int64 [1].<br>
>> The goal is to expose GL_ARB_shader_fp64 to OpenGL 3.0 GPUs.<br>
>><br>
>> Each function can be independently tested using shader_runner from piglit.<br>
>> The piglit files are stored on github [2].<br>
>><br>
>> [1]<br>
>> <a href="https://lists.freedesktop.org/archives/mesa-dev/2016-November/136718.html" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>archives/mesa-dev/2016-<wbr>November/136718.html</a><br>
>> [2] <a href="https://github.com/Hopetech/libSoftFloat" rel="noreferrer" target="_blank">https://github.com/Hopetech/<wbr>libSoftFloat</a><br>
><br>
><br>
> Glad to see this finally turning into code.<br>
><br>
> Before, we get too far into things, I'd like to talk about the approach a<br>
> bit.  First off, if we (Intel) are going to use this on any hardware, we<br>
> would really like it to be in NIR.  The reason for this is that NIR has a<br>
> much more powerful algebraic optimizer than GLSL IR and we would like to<br>
> have as few fp64 instructions as possible before we start lowering them to<br>
> piles of integer math.  I believe Ian's plan for this was that someone would<br>
> write a nir_builder back-end for the stand-alone compiler.  Unfortunately,<br>
> he sort-of left that as "an exercise to the reader" and no code exists to my<br>
> knowledge.  If we're going to write things in GLSL, we really need that NIR<br>
> back-end.<br>
<br>
</span>I'm not sure what the impetus was for developing a softfloat library<br>
(but I'm a big fan). but the current situation is that it will largely<br>
just be useful for AMD Evergreen/Northern Islands chips, which consume<br>
TGSI produced from GLSL. (Aside: [1].) As such, I'm not sure if a push<br>
towards NIR is warranted -- it would cause a more convoluted path<br>
towards the intended target.<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I do agree with the larger point - the lowering should be done as late<br>
as possible in order to enable algebraic-style optimizations. (This is<br>
also why I've argued that optimizing in the frontend is too early - it<br>
should be all just be done in the backend, as additional calculations<br>
can easily make their way into the flow. I realize that's impractical<br>
for i965 though as the backend is not SSA though, and some opts are<br>
necessary in GLSL in order to perform the necessary validation.)<br></blockquote><div><br></div><div>That's not really an accurate account of why we do it in NIR for i965...  By the time we get done with all the lowering we do in NIR, the NIR code looks a lot like back-end code.  Certainly, any optimizations on fp64 operations will already have been done.  It's just that anything that looks too much like i965 hardware will be a pain to optimize.<br></div></div></div></div>