Announcement

Collapse
No announcement yet.

Vulkan 1.1.108 Released With Two New Extensions

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

  • Vulkan 1.1.108 Released With Two New Extensions

    Phoronix: Vulkan 1.1.108 Released With Two New Extensions

    It's been almost a month since the last Vulkan spec update with Vulkan 1.1.107, which is a long time considering they go through some periods of almost weekly updates, but out today is v1.1.108 and it introduces two new extensions...

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

  • #2
    Waiting for OpenCl integration....

    Comment


    • #3
      Remember when Vulkan used to be a lean and mean API without millions of extensions?

      Comment


      • #4
        Originally posted by Weasel View Post
        Remember when Vulkan used to be a lean and mean API without millions of extensions?
        Vulkan is not about being "lean and mean". It is about giving maximum control, being explicit. And that is what those extensions do, give devs more control.

        Comment


        • #5
          Originally posted by Weasel View Post
          Remember when Vulkan used to be a lean and mean API without millions of extensions?
          How do you plan to add support for different new low-level features supported by wildly different hardware without breaking retrocompatibility?

          You either add new and lean extensions to do JUST THAT THING and let the API user decide what to do with it, or make an abstraction clusterfuck that takes decisions behind your back like OpenGL.
          Last edited by starshipeleven; 05-13-2019, 12:02 PM.

          Comment


          • #6
            Typo:

            Originally posted by phoronix View Post
            The NVIDIA-led extension allows definding modes

            Comment


            • #7
              Originally posted by Weasel View Post
              Remember when Vulkan used to be a lean and mean API without millions of extensions?
              It was never "lean and mean" and it was never without millions of extensions. Vulkan was all about extensions from day 0. In fact it's impossible by design to write any Vulkan-based software at all without relying on extensions.

              Comment


              • #8
                Originally posted by Weasel View Post
                Remember when Vulkan used to be a lean and mean API without millions of extensions?
                Not really, no. Weren't there tons of extensions from day 1 which weren't required by the core spec?

                Anyway, the key with Vulkan is that they are all opt-in rather than opt-out, so each app should be getting small subset and have better pre-determined behavior.

                Comment


                • #9
                  Originally posted by smitty3268 View Post

                  Not really, no. Weren't there tons of extensions from day 1 which weren't required by the core spec?

                  Anyway, the key with Vulkan is that they are all opt-in rather than opt-out, so each app should be getting small subset and have better pre-determined behavior.
                  I think there is also a misunderstanding about the meaning of extensions. To many people the word "extensions" suggests that they are somehow optional. They are not: in Vulkan, "extensions" are in fact domain-specific and system-specific API subsets whose use is MANDATORY and necessary to accomplish certain actions, such as initialising the GPU, obtaining a graphics context to do any drawing at all etc.

                  An application must declare which extensions it needs, which is basically never an empty set, and then can only use only those parts of the APIs that are provided by those extensions.

                  Comment


                  • #10
                    Originally posted by jacob View Post
                    I think there is also a misunderstanding about the meaning of extensions. To many people the word "extensions" suggests that they are somehow optional. They are not: in Vulkan, "extensions" are in fact domain-specific and system-specific API subsets whose use is MANDATORY and necessary to accomplish certain actions, such as initialising the GPU, obtaining a graphics context to do any drawing at all etc.

                    An application must declare which extensions it needs, which is basically never an empty set, and then can only use only those parts of the APIs that are provided by those extensions.
                    Pretty much yeah. The problem is that it'll end up in a situation where just making use of all these extensions will require too much memorization of millions of them.

                    I mean sure, you don't have to use certain extensions, but if you don't know about them, how can you know that your current way of doing something in Vulkan is optimal or the best way to achieve it? So technically you'd have to know about (most) extensions just to know which to use and which not to in a particular situation and application. The burden will just be too great cause it seems it's never going to slow down.

                    Remember that the Direct3D propaganda against OpenGL was also mostly about development and documentation, i.e. people were brainwashed to think that OpenGL was just too hard to get into compared to Direct3D. Having so many extensions doesn't really help Vulkan here with this, in my opinion.

                    Comment

                    Working...
                    X