What You Need To Know About SPIR-V 1.0

[phoronix]

Phoronix: What You Need To Know About SPIR-V 1.0

For those that haven't been paying attention to SPIR-V as the new intermediate representation that makes up OpenCL 2.1+ and Vulkan, here's various details about this newest Khronos Group specification you may not be familiar with...

http://www.phoronix.com/scan.php?page=news_item&px=SPIR-V-1.0-Details

[abu_shawarib]

This collaboration is no joke. Kudos to them.

[mudig]

Very nice Do I understand correctly that e.g. OpenGL shaders could be transformed to SPIR-V by mesa and then used as input for the GPU drivers? So that amdgpu, nouveau, etc. or the frontends to them could theoretically be simplified (?) to consume only SPIR-V?

[gufide]

Very nice Do I understand correctly that e.g. OpenGL shaders could be transformed to SPIR-V by mesa and then used as input for the GPU drivers? So that amdgpu, nouveau, etc. or the frontends to them could theoretically be simplified (?) to consume only SPIR-V?

OpenGL could be rewritten entirely in Vulkan. That would be awesome. No different bugs per platform, coherent implementation and performance etc. And Vulkan is much simpler (in term of complexity) so it would reduce even more the current incoherence.

[jrch2k8]

OpenGL could be rewritten entirely in Vulkan. That would be awesome. No different bugs per platform, coherent implementation and performance etc. And Vulkan is much simpler (in term of complexity) so it would reduce even more the current incoherence.

Not exactly, i mean OpenGL shaders can be converted to SPIR-V and consumed by the Vulkan driver but OpenGL has a serious fracking lot of static functionality that cannot be simply "ported" internally to Vulkan because Vulkan actual advantage comes from lacking the constructs needed for that functionality in the first place.

As example, lets make an analogy.

Python is too slow but is safe for the developer(OpenGL), so lets throw safety as a whole through the windows and only use ISO C + ASM manual register allocation because it would freaking fast(Vulkan), sure you could think you can make python faster using ISO C + ASM but at the end it will still be slow, because the slowness don't come from the backend or the language itself but from the safe types, garbage collector, RAII types, dynamic allocation, heap usage, memory traversing algorithms, etc. and probably you will have the same implementation issues because there is no guarantee all other implementations of ISO C + ASM python will resolve the issues the same way you did

Additionally the advantage of Vulkan from the implementation level (standardisation), is exactly because is so close to the actual metal that drivers(basically) only need to translate opcodes and upload without giving an actual fuck if the code is correct or if it will blow the GPU to hell because that is actually on the developers hands now.

So not just any developer will take the TITANIC task of using Vulkan, DX12, Metal for the extra FPS until there is enough abstractions tools outside big big studios, i mean seriously a teapot + texture in OpenGL/DX11 could reach 50-100 LoC, in Vulkan/DX12/Metal can easily reach 2-3k LoC(using a very efficient design, otherwise add a couple K's more).

Point, don't expect miracles and understand Vulkan wasn't meant to replace OpenGL and in there future probably new revisions of OpenGL will come simply because they server 2 different needs and markets

[Sethox]

Interesting, really. Thanks for that explanation.

[SystemCrasher]

OpenGL could be rewritten entirely in Vulkan. That would be awesome. No different bugs per platform, coherent implementation and performance etc. And Vulkan is much simpler (in term of complexity) so it would reduce even more the current incoherence.

There is little catch. Somehow you assume devs are going to be eager to do some efforts on doing something ... which has been already here. Resulting in almost zero "added value" (or how the heck you call it). So there're plenty of efforts and very minor gain. So let me doubt it going to happen this way, even if it is not entirely impossible to do.

I guess GL would continue to exist, and older programs would continute using it. Furthermore, some newer programs could also have idea OpenGL API maps better on what they want to do. But some use cases would be clearly better with Vulkan. And so, new programs would start using it.

[erendorn]

There is little catch. Somehow you assume devs are going to be eager to do some efforts on doing something ... which has been already here. Resulting in almost zero "added value" (or how the heck you call it). So there're plenty of efforts and very minor gain. So let me doubt it going to happen this way, even if it is not entirely impossible to do.

I guess GL would continue to exist, and older programs would continute using it. Furthermore, some newer programs could also have idea OpenGL API maps better on what they want to do. But some use cases would be clearly better with Vulkan. And so, new programs would start using it.

I don't think that's what he meant (jrch2k8 made the same confusion). Gufide is not implying that programs would all use Vulkan instead of OpenGL. He is saying that OpenGL implementation itself could be built upon Vulkan, regardless of the underlying driver. So only the vulkan implementation would be driver specific, but Vulkan is expected to be much easier to implement much less quirky driver side.

Basically, mesa (or something else) could do this and mecome driver independent.

[jrch2k8]

I don't think that's what he meant (jrch2k8 made the same confusion). Gufide is not implying that programs would all use Vulkan instead of OpenGL. He is saying that OpenGL implementation itself could be built upon Vulkan, regardless of the underlying driver. So only the vulkan implementation would be driver specific, but Vulkan is expected to be much easier to implement much less quirky driver side.

Basically, mesa (or something else) could do this and mecome driver independent.

nope, my post was specifically why is not worth doing and why you will end with the same problem even if you do.

Again the problem is not about what vulkan or C++ or C could do being low level languages, the problem with OpenGL is its own specification and algorithms against the hardware, type safety, memory allocation, pattern matching, static functionality, etc. Additionally remember most of the code needed to implement OpenGL in all drivers is needed to implement Vulkan too except the actual shader compiler because Vulkan on itself cannot talk directly to the hardware and neither can SPIR-V.

Vulkan/Metal/DX12 are considered easier to implement and more predictable simply because is extremely low level(i mean really don't think about GL or DX here, think about LLVM IR or TGSI with function calls) and the compiler is in user space now, thats it no miracles here

So even if you make an OpenGL Vulkan backend there is no guarantee it will be any better, simply because you will have to implement all the security and safety requirements to be compliant with the specification but is still low level enough for nVidia/AMD/Intel do their thing.

Why they would modify it if vulkan is standard, .., ... ,..? simply because hardware works differently and is low level enough to allow it, so if the OpenGL Spec only allow swizzle operations from 0,0 in 1 step but nVidia knows that their hardware is way faster doing x,y with 5 steps instead(even if it breaks the spec), they will do so and add it as a GamerWorks feature and everyone else receive a kind "Fuck you"(including Kronos btw), so eventually AMD will have to make profiles again to replace this swizzle function for one faster in their hardware to stay competitive in X game and Welcome Back to cluster fuck OpenGL drivers.(exactly what they do now btw, in case you wondered what exactly made those huge performance differences in OpenGL implementations)

If this happened to OpenGL, will it happen to vulkan? is less likely because is low level enough to not provide any huge difference on different hardware and the optimisation is done exclusively by the developers now not the drivers, still is possible that some studio will only care about nVidia hardware tho and this could generate performance problems in all other GPU's but well lets wait and see

[erendorn]

nope, my post was specifically why is not worth doing and why you will end with the same problem even if you do.

Again the problem is not about what vulkan or C++ or C could do being low level languages, the problem with OpenGL is its own specification and algorithms against the hardware, type safety, memory allocation, pattern matching, static functionality, etc. Additionally remember most of the code needed to implement OpenGL in all drivers is needed to implement Vulkan too except the actual shader compiler because Vulkan on itself cannot talk directly to the hardware and neither can SPIR-V.

Vulkan/Metal/DX12 are considered easier to implement and more predictable simply because is extremely low level(i mean really don't think about GL or DX here, think about LLVM IR or TGSI with function calls) and the compiler is in user space now, thats it no miracles here

So even if you make an OpenGL Vulkan backend there is no guarantee it will be any better, simply because you will have to implement all the security and safety requirements to be compliant with the specification but is still low level enough for nVidia/AMD/Intel do their thing.

Why they would modify it if vulkan is standard, .., ... ,..? simply because hardware works differently and is low level enough to allow it, so if the OpenGL Spec only allow swizzle operations from 0,0 in 1 step but nVidia knows that their hardware is way faster doing x,y with 5 steps instead(even if it breaks the spec), they will do so and add it as a GamerWorks feature and everyone else receive a kind "Fuck you"(including Kronos btw), so eventually AMD will have to make profiles again to replace this swizzle function for one faster in their hardware to stay competitive in X game and Welcome Back to cluster fuck OpenGL drivers.(exactly what they do now btw, in case you wondered what exactly made those huge performance differences in OpenGL implementations)

If this happened to OpenGL, will it happen to vulkan? is less likely because is low level enough to not provide any huge difference on different hardware and the optimisation is done exclusively by the developers now not the drivers, still is possible that some studio will only care about nVidia hardware tho and this could generate performance problems in all other GPU's but well lets wait and see

Sorry if I misinterpreted your post. I based my understanding on your conclusion ("Point, don't expect miracles and understand Vulkan wasn't meant to replace OpenGL and in there future probably new revisions of OpenGL will come simply because they server 2 different needs and markets"), which clearly talks about consumming the OpenGL API in applications, and not about providing an OpenGL API on a given platform.
Your analogy was also very confusing, suggesting "using C as a high level language instead of Python", whereas Gufide is suggesting "Implementing a Python interpreter in C for platforms that don't have yet a working native Python interpreter, on the basis that C compilers will be availlable for more platforms so that python can be used as a high level language on these platforms".

The fact that Mesa exists supports the claim that a decent part of OpenGL is not driver specific and can be implemented and shared on top of lower level stuff.
Similarly, it supports the claim that non vendor supplied OpenGL implementations are needed.
One issue in Mesa is that there was no common low level stuff to target. So Mesa currently only works with specific drivers. The question is, is Vulkan capable and low level enough to be considered as a valid backend in this case? This would certainly simplify the IR/GSLSL stuff, and enable more platforms (since Vulkan support is expected to be better and more widespread than full OpenGL and OpenCL and OpenWhatNot support).

I'm not knowledgeable enough, but it isn't clear in your post that you are responding to that.