Announcement

Collapse
No announcement yet.

What You Need To Know About SPIR-V 1.0

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • What You Need To Know About SPIR-V 1.0

    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?pag...-V-1.0-Details

  • #2
    This collaboration is no joke. Kudos to them.

    Comment


    • #3
      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?

      Comment


      • #4
        Originally posted by mudig View Post
        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.

        Comment


        • #5
          Originally posted by gufide View Post
          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

          Comment


          • #6
            Interesting, really. Thanks for that explanation.
            Last edited by Sethox; 11-17-2015, 01:58 PM.

            Comment


            • #7
              Originally posted by gufide View Post
              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.

              Comment


              • #8
                Originally posted by jrch2k8 View Post
                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
                thank you very much i read your very good analogy and i am happy that i am on phoronix to read stuff like your writing here.
                Phantom circuit Sequence Reducer Dyslexia

                Comment


                • #9
                  Originally posted by SystemCrasher View Post
                  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.

                  Comment


                  • #10
                    Originally posted by erendorn View Post

                    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

                    Comment

                    Working...
                    X