<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Mar 11, 2017 at 9:50 AM, Jason Ekstrand <span dir="ltr"><<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><div dir="ltr"><div class="gmail_extra">As I said at the top, I'm really not going for NIR or nothing.  I agree that GLSL has advantages for chips like r600 which badly needs emulation and isn't moving to NIR any time soon.  Also, fp64 isn't a requirement in Vulkan and, given that Vulkan covers both desktop and mobile, likely won't be any time soon.  (In fact, if someone wanted Vulkan FP64 on hardware that didn't support it, I'd be tempted to tell them to pay someone to write a layer.)  However, *if* we decide that emulated fp64 is better on, for instance Ivy Bridge, *and* we had customers that cared about it (I don't know of any), then doing it in NIR could yield substantially better results (depending on initial shader quality) due to being able to run nir_opt_algebraic first.  Those are a lot of ifs so maybe I'm suggesting we design for a non-use-case, but I really don't want to paint ourselves into a corner that we have to crawl out of 2 years from now.<br></div></div></blockquote><div><br></div><div>Chatting with people on IRC this morning, I realized there's a killer argument for why we *need* NIR support: SPIR-V on OpenGL.  As soon as you expose the GL_ARB_spirv extension on an OpenGL 4.0+ driver, you must support fp64.  If we ever need emulated fp64 in such a driver, the lowering has to be done in NIR because there is no GLSL IR in the path.<br></div></div></div></div>