Announcement

Collapse
No announcement yet.

Vulkan 1.0.5 API Specification Released

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

  • Vulkan 1.0.5 API Specification Released

    Phoronix: Vulkan 1.0.5 API Specification Released

    Thanks in part to The Khronos Group hosting the Vulkan specification on GitHub and being more open about the development process of the Vulkan graphics API, version 1.0.5 is now available...

    http://www.phoronix.com/scan.php?pag...1.0.5-Released

  • #2
    Vulkan 1.0.5 also adds NVIDIA's VK_NV_glsl_shader extension
    And there we go, adding vendor specific stuff, thats the first step in order to Vulkan become what OpenGL is

    Comment


    • #3
      Why isn't it still in alpha, if it has to change every week, and isn't feature complete either?

      Comment


      • #4
        Originally posted by TheOne View Post

        And there we go, adding vendor specific stuff, thats the first step in order to Vulkan become what OpenGL is

        and what is vendor specific with this extension? It's not like glsl only works on nvidia gpus...

        Comment


        • #5
          Originally posted by karolherbst View Post


          and what is vendor specific with this extension? It's not like glsl only works on nvidia gpus...
          GLSL doesn't work on a gpu, it's a high-level shading language that should have been let nowhere near the Vulkan specification. Nvidia has royally screwed us over.

          Comment


          • #6
            Originally posted by TheOne View Post

            And there we go, adding vendor specific stuff, thats the first step in order to Vulkan become what OpenGL is
            They just added the text/spec for an extension that the NVidia Vulkan driver has shipped with from the very start. Every implementation vendor (yes, even you!) is free to create their own extensions, and it's still to this date regarded as one of the best features of OpenGL for rapidly making new GPU technologies accessible for people to try out without having to wait for an entirely new API version to come out.

            As someone who has dealt extensively with GL, I'll tell you that vendor extensions really were the least of problems with OpenGL..

            Comment


            • #7
              Originally posted by M1kkko View Post

              GLSL doesn't work on a gpu, it's a high-level shading language that should have been let nowhere near the Vulkan specification. Nvidia has royally screwed us over.
              This
              The whole point of Vulkan was to design a new specification from the ground up without any legacy limitations.
              Introducing glsl ruins the lean driver part of the clean design thing.

              Comment


              • #8
                If I have understood it right, this means that Vulkan drivers must now understand GLSL (almost as OpenGL), which is not a light change and seems to go against one of the main reasons behind Vulkan's design. Is this correct? It's what I got from the extension page.

                EDIT: Nevermind, seems it's just about recognising the existence of the extension, not about incorporating it into Vulkan itself.
                Last edited by kalrish; 03-05-2016, 03:54 PM.

                Comment


                • #9
                  Originally posted by kalrish View Post
                  EDIT: Nevermind, seems it's just about recognising the existence of the extension, not about incorporating it into Vulkan itself.
                  No, but that's the thing: Even if it's not a part of "core" Vulkan, some form of it is in the official, released documentation of Vulkan. It's an extension that, I admit, is going to help a lot of early ports to Vulkan (though with minimal benefits) and while before it was strictly NVidia only, now that it's on the official documentation of the API (definition only or no), people are going to see that as "So everybody ships it, we're okay to use it"... and so everybody will have to ship it. AMD/Intel are basically forced to implement this now.

                  Despite what somebody said earlier, extensions ARE part of why OpenGL was so fucked up. 90% of OpenGL problems were from vender-specific implementations... guess what's harder to implement to spec than core OpenGL? That's right, extensions which, afaik, were never bound to the (already not-very-strict) definitions/implementation rules as core OGL. When there's a lot of them, you're going to have problems in terms of not rending exactly the same as the implementation by the creator of the extensions.

                  Extensions are fine, but I really feel they should be sent to Khronos as a whole for review, then if accepted (changed or not) renamed to fit Vulkan instead of having a ton of "NV_" or "AMD_" etc etc extensions in the spec. It really gets annoying after a while. It could be like the browser --webkit- or --mozilla- flags, where if you're using "VK_NV_glsl_shader", you're using NVidia's specific implementation, but if you're using "VK_VE_glsl_shader", you're using the official, spec-compliant version. AMD/Intel wouldn't be forced to implement the _NV_ (nor NVidia _AMD_/_INTEL_) versions so less complaining from everybody, we get more strict extension definitions (less breakage overall). Win-win.

                  Comment


                  • #10
                    Originally posted by Daktyl198 View Post
                    Extensions are fine, but I really feel they should be sent to Khronos as a whole for review, then if accepted (changed or not) renamed to fit Vulkan instead of having a ton of "NV_" or "AMD_" etc etc extensions in the spec.
                    IIRC those acronyms serve the purpose to identify the company behind the original specification of the extension, not necessarily the implementation...

                    Comment

                    Working...
                    X