Khronos Group Announces Vulkan, OpenCL 2.1, SPIR-V

[smitty3268]

Sometimes the internet makes me sad at the state of humanity

Reading this list of comments is one of those times.

[dh04000]

Reading this list of comments is one of those times.

I see it as a divine comedy. Just grab the popcorn, sit back, and watch the world burn.

[oleid]

[...] watch the world burn.

Reminds me at this song

[dh04000]

Reminds me at this song

I'm not a huge fan of Heavy Metal, so when I think about it, I go to this song.

[zanny]

You are writing some nonsense.
1. You couldn't compile Vulkan to SPIR-V, Vulkan is API while SPIR-V is intermediate representation for shaders/kernels.
2. Differently working implementations of GLSL/OpenCL/(other lang) -> SPIR-V compilers is not such a big problem because you can use only one and don't care about the rest. If different drivers will interpret SPIR-V differently this would be a huge problem.
3. JVM or CLR, WTF?
4. It doesn't make much sense to have a common implementation of low level API because if it is low level it means most parts will be vendor specific.
5. Official GLSL -> SPIR-V compiler will probably be open source. GLSL will be the first langugage for writing Vulkan shaders.

1. Vulcan will be an API and a shader language. Just like OpenGL is. Just like every graphics API is. The API will hopefully be a dumb library that calls into the minimal amount of fixed function driver mechanisms necessary to leverage a comprehensive SL.
2. You only need one SPIR -> ASM for each GPU. You still need shaders / API -> Spir on top of that. In OGL terms, it is like how Mesa is an OGL implementation while Gallium implements a Mesa IR to hardware compiler. The fact GPU vendors today do not use Mesa as the reference and target one of the Mesa IRs with drivers is indicative of a failed policy on Khronos' part that fragmented the ecosystem and was a contributing factor to why OGL has such huge problems for game devs.
3. Java Virtual Machine and Common Language Runtime. They are interpreters / JIT compilers (depending on version) that are exactly like how compiling to SPIR and then to ASM will work.
4. LLVM is a demonstration of how much sense a common implementation makes. I hate the misdirection inspired by calling raw GPU programming which is what Vulcan will be "low level" when any other level is a facsimile of the actual hardware and makes things harder.
5. Those are not Vulkan shaders though, they are OGL shaders compiled to Khonos' IR the same way you can compile GLSL shaders to Mesa IR (which are then converted to Gallium IR and LLVM IR if you use the Gallium stack) and Vulkan will either need to include a modernized version dialect of GLSL or will have to stuff way more than it needs to into its fixed function API. Look at HSA as the potential of how little CPU side work you need to do to put everything in shaders - if you just load textures from disk into GPU memory or unified memory, and have async calls and precompiled GPU kernels your GPU should be doing 99% of the work in shader code.

[pasaulais]

If Khronos is going to publish a GLSL to SPIR V frontend, what about adding support to OpenGL to load SPIR V shaders?

[grndzro]

4. LLVM is a demonstration of how much sense a common implementation makes. I hate the misdirection inspired by calling raw GPU programming which is what Vulcan will be "low level" when any other level is a facsimile of the actual hardware and makes things harder.

From what I recall wasn't Mantle's low level code optional? Wouldn't Vulkan's be the same?
I thought the low level stuff was handled by Mantle, with optional tuning.

[Marc Driftmeyer]

I'm not a huge fan of Heavy Metal, so when I think about it, I go to this song.

Don't misconstrue Death Metal with a hard-on mix of Speed Metal drumming with Heavy Metal.

[Szzz]

1. Vulcan will be an API and a shader language. Just like OpenGL is. Just like every graphics API is.

SPIR-V is this shading language. Just read their presentation: https://www.khronos.org/vulkan

2. You only need one SPIR -> ASM for each GPU.

Right.

You still need shaders / API -> Spir on top of that. In OGL terms, it is like how Mesa is an OGL implementation while Gallium implements a Mesa IR to hardware compiler. The fact GPU vendors today do not use Mesa as the reference and target one of the Mesa IRs with drivers is indicative of a failed policy on Khronos' part that fragmented the ecosystem and was a contributing factor to why OGL has such huge problems for game devs.

But how is this related to Vulkan where drivers don't even need to care about compiling whatever shader programming language to SPIR-V?

3. Java Virtual Machine and Common Language Runtime. They are interpreters / JIT compilers (depending on version) that are exactly like how compiling to SPIR and then to ASM will work.

I know what they are, they are a bad choice for GPU IR.

4. LLVM is a demonstration of how much sense a common implementation makes. I hate the misdirection inspired by calling raw GPU programming which is what Vulcan will be "low level" when any other level is a facsimile of the actual hardware and makes things harder.

What do you want to be in this common implementation?
SPIR-V -> target GPU compilation is GPU specific and cannot be shared.
API implementation itself, we don't know yet how low-level it will be, maybe some sharing is possible here.

5. Those are not Vulkan shaders though, they are OGL shaders compiled to Khonos' IR

According to Khronos they are, you will be able to use GLSL to write shaders for Vulkan.

[BeardedGNUFreak]

If Khronos wants to avoid the hell that was OpenGL versioning and extensions,

Do we laugh or cry at someone that stupid.

Protip dunce. When it comes to graphics API discussions, keep your dimwitted mouth shut from now on.