[Mesa-dev] Interest in GL_ARB_gl_spirv support?

[Jason Ekstrand]

On Tue, Jul 26, 2016 at 4:50 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:

> On Tue, Jul 26, 2016 at 7:44 PM, Marek Olšák <maraeo at gmail.com> wrote:
> > On Wed, Jul 27, 2016 at 12:29 AM, oscar bg <rtfss1 at gmail.com> wrote:
> >> Hi,
> >> seems this year 2016 OpenGL ARB update brings a small number of
> extensions..
> >> seems the most important is GL_ARB_gl_spirv.. seems like SPIRV as a
> binary
> >> format for OpenGL and Mesa doesn't have any binary format even
> supporting
> >> ARB_program_binary ext.. a Nvidia driver is already providing support
> from
> >> day 1 for Linux as always..
> >>
> >> just asking how difficult would be to bring support to Mesa drivers..
> and if
> >> there is any interest by Mesa devs start working on it soon..
> >>
> >> seems already we have SPIRV support in Mesa in Vulkan drivers: Anvil
> Vulkan
> >> Intel driver and some days ago RADV a open source Vulkan driver for AMD
> GPUs
> >> has been anounced.. as this drivers already eat SPIRV code seems this
> >> extension would take less work to port to this two vendor GPUs?
>

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.


> > The showstopper for sharing Vulkan code is that OpenGL doesn't have
> > pipeline state objects. Because of that, you can ignore RADV. I think
> > nobody has enough resources to replicate what the radeonsi TGSI path
> > does, so you are pretty much stuck with TGSI.
> >
> > SPIRV -> NIR -> TGSI should work.
>

Eric's NIR -> TGSI pass is a bit rusty at this point, but it wouldn't be
hard to revive it.


> FWIW my plans for nouveau definitely involve direct SPIR-V input. This
> will also be useful for an independent Vulkan driver, as well as
> OpenCL SPIR-V. However I'm not sure when such plans will materialize.
>

I've just got to say it.  You're crazy...

--Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160726/0ce4413a/attachment.html>