<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jul 26, 2016 at 4:50 PM, 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 Tue, Jul 26, 2016 at 7:44 PM, Marek Olšák <<a href="mailto:maraeo@gmail.com">maraeo@gmail.com</a>> wrote:<br>
> On Wed, Jul 27, 2016 at 12:29 AM, oscar bg <<a href="mailto:rtfss1@gmail.com">rtfss1@gmail.com</a>> wrote:<br>
>> Hi,<br>
>> seems this year 2016 OpenGL ARB update brings a small number of extensions..<br>
>> seems the most important is GL_ARB_gl_spirv.. seems like SPIRV as a binary<br>
>> format for OpenGL and Mesa doesn't have any binary format even supporting<br>
>> ARB_program_binary ext.. a Nvidia driver is already providing support from<br>
>> day 1 for Linux as always..<br>
>><br>
>> just asking how difficult would be to bring support to Mesa drivers.. and if<br>
>> there is any interest by Mesa devs start working on it soon..<br>
>><br>
>> seems already we have SPIRV support in Mesa in Vulkan drivers: Anvil Vulkan<br>
>> Intel driver and some days ago RADV a open source Vulkan driver for AMD GPUs<br>
>> has been anounced.. as this drivers already eat SPIRV code seems this<br>
>> extension would take less work to port to this two vendor GPUs?<br></span></blockquote><div><br></div><div>We're thinking about it but, unfortunately, I haven't had much time to look into the extension.  One thing that I can say right now, is that the spirv_to_nir pass isn't what you'd call OpenGL-friendly.  If you pass it invalid SPIR-V, it will crash.  What little error checking it does do is done via asserts.  That's perfectly acceptable in the Vulkan world but unless they went out of their way to ok it in the extension, crashing generally isn't acceptable in OpenGL.  Also, it's not entirely clear what all hoops we would have to go through to tie a NIR shader into the OpenGL state upload paths for things like uniforms, inputs/outputs, etc.  This isn't to say that it can't be done but it's substantially more than zero work.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> The showstopper for sharing Vulkan code is that OpenGL doesn't have<br>
> pipeline state objects. Because of that, you can ignore RADV. I think<br>
> nobody has enough resources to replicate what the radeonsi TGSI path<br>
> does, so you are pretty much stuck with TGSI.<br>
><br>
> SPIRV -> NIR -> TGSI should work.<br></span></blockquote><div><br></div><div>Eric's NIR -> TGSI pass is a bit rusty at this point, but it wouldn't be hard to revive it.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
</span>FWIW my plans for nouveau definitely involve direct SPIR-V input. This<br>
will also be useful for an independent Vulkan driver, as well as<br>
OpenCL SPIR-V. However I'm not sure when such plans will materialize.<br></blockquote><div><br></div><div>I've just got to say it.  You're crazy...<br><br></div><div>--Jason<br></div></div></div></div>