<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 6, 2017 at 3:26 AM, Emil Velikov <span dir="ltr"><<a href="mailto:emil.l.velikov@gmail.com" target="_blank">emil.l.velikov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 6 March 2017 at 08:34, Michel Dänzer <<a href="mailto:michel@daenzer.net">michel@daenzer.net</a>> wrote:<br> > On 04/03/17 05:32 AM, Jason Ekstrand wrote:<br> >> On Fri, Mar 3, 2017 at 11:41 AM, Ilia Mirkin <<a href="mailto:imirkin@alum.mit.edu">imirkin@alum.mit.edu</a><br> >> <mailto:<a href="mailto:imirkin@alum.mit.edu">imirkin@alum.mit.edu</a>>> wrote:<br> >><br> >> On Fri, Mar 3, 2017 at 2:16 PM, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a><br> >> <mailto:<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> <mailto:<a href="mailto:tournier.elie@gmail.com">tournier.elie@gmail.<wbr>com</a>>><br> >> > wrote:<br> >> >><br> >> >> From: Elie Tournier <<a href="mailto:elie.tournier@collabora.com">elie.tournier@collabora.com</a> <mailto:<a href="mailto:elie.tournier@collabora.com">elie.tournier@<wbr>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> >> <<a href="https://lists.freedesktop.org/archives/mesa-dev/2016-November/136718.html" rel="noreferrer" target="_blank">https://lists.freedesktop.<wbr>org/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> >> <<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> >> 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> >><br> >><br> >> Whether or not i965 wants softfloat is an ongoing debate. On the one<br> >> hand, we have "hardware support" for it starting with ivy bridge. On<br> >> the other hand, early hardware support is sufficiently terrible that<br> >> softfloat may end up being a better plan. Also, I wouldn't be surprised<br> >> if, at some point in the future, some hardware engineer decides they can<br> >> save a bunch of power on low-power parts if they delete the fp64<br> >> hardware. Since we ship desktop GL on those parts, loosing 4.0 would be<br> >> bad. I don't want to paint ourselves into a corner on fp64.<br> ><br> > Doing it in NIR would make it useless for r600. What's your suggestion<br> > for that?<br></div></div></blockquote><div><br></div><div>I'm not suggesting that we go NIR-only. I thought I was fairly clear on that in my original e-mail. (Maybe I wasn't?) My original e-mail intended to point out some of the issues with the current approach and open things up for discussion about solutions. One of those issues is no NIR support. Lest you ask, "can't you just use the GLSL pass?", please remember that we're shipping a driver that doesn't use GLSL IR.<br><br></div><div>As far as what we do going forward, here's what I'd like to see at least initially:<br><br></div><div> 1) Does r600 have any vec4-based stages or are they all scalar? If it has vec4-based stages, it would be nice if whatever lowering we did used the split pack/unpack opcodes so that scalarizing is optional. That makes it way nicer to vec4 back-ends.<br><br></div><div> 2) I'd like to see at least an example of writing the lowering directly in builder code rather than doing GLSL code-gen. In my experience, builder code isn't that hard to write if you've got the GLSL handy as a reference and the resulting C++ code is way easier to debug than something that comes out of codegen.<br><br></div><div>Note that neither of those two things have anything to do with NIR.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"> </div></div>How about we allows drivers to opt-in for this ? There's already a<br> bunch in gl_shader_compiler_options that we toggle.<br> This will allow Elie's work to land and be [at least partially] useful<br> in the interim.<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br>That's entirely beside the issue. I'm trying to avoid checking piles of very hard-to-read autogenerated C++ code into the tree until we're sure that it's actually a good solution.<br></div></div></div></div>