Re: [Mesa-dev] Interest in GL_ARB_gl_spirv support?

[Matt Turner]

On Tue, Jul 26, 2016 at 9:16 PM, Jason Ekstrand  wrote:
> On Tue, Jul 26, 2016 at 4:50 PM, Ilia Mirkin  wrote:
>>
>> On Tue, Jul 26, 2016 at 7:44 PM, Marek Olšák  wrote:
>> > On Wed, Jul 27, 2016 at 12:29 AM, oscar bg  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 spec says

The OpenGL API expects the SPIR-V module to have already been validated,
and can return an error if it discovers anything invalid in
the module.  An invalid SPIR-V module is allowed to result in undefined
behavior.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Interest in GL_ARB_gl_spirv support?

[Jason Ekstrand]

On Tue, Jul 26, 2016 at 4:50 PM, Ilia Mirkin  wrote:

> On Tue, Jul 26, 2016 at 7:44 PM, Marek Olšák  wrote:
> > On Wed, Jul 27, 2016 at 12:29 AM, oscar bg  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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Interest in GL_ARB_gl_spirv support?

[Ilia Mirkin]

On Tue, Jul 26, 2016 at 7:44 PM, Marek Olšák  wrote:
> On Wed, Jul 27, 2016 at 12:29 AM, oscar bg  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?
>
> 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.

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.

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Interest in GL_ARB_gl_spirv support?

[Marek Olšák]

On Wed, Jul 27, 2016 at 12:29 AM, oscar bg  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?

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.

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Interest in GL_ARB_gl_spirv support?

[oscar bg]

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?

would like to hear feedback,
thanks..
Oscar.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev