Announcement

Collapse
No announcement yet.

Vulkan 1.2.200 Released With Two New Extensions

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

  • Vulkan 1.2.200 Released With Two New Extensions

    Phoronix: Vulkan 1.2.200 Released With Two New Extensions

    Out today is Vulkan 1.2.200 as the newest spec revision to the Vulkan graphics/compute API...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    the new extension to allow applications to use the OpenGL depth range in NDC rather than Vulkan's default range. This extension is to help in allowing OpenGL implementations over Vulkan. Utilizing VK_EXT_depth_clip_control allows for greater efficiency by avoiding costly emulation in the pre-rasterization shader stages around altering the depth range.
    Could this help Zink too in some way?

    Comment


    • #3
      If Vulkan is so low level why those things cannot be implemented efficiently without extensions?

      Comment


      • #4
        Originally posted by Rexerex View Post
        If Vulkan is so low level why those things cannot be implemented efficiently without extensions?
        Emulating hardware in software will never be as fast as actually using the hardware feature directly.

        That said, this is a good example of why perfect 100% performance of another API isn't something you should rely on from Vulkan, or any other API. They are working through lots of stuff like this in order to get rid of any remaining problems, but it's likely never going to be perfect.

        Comment


        • #5
          Originally posted by Rexerex View Post
          If Vulkan is so low level why those things cannot be implemented efficiently without extensions?
          Because the default way Vulkan does depth range isn't efficient for OpenGL over Vulkan so that needed an efficiently implemented extension.

          Comment


          • #6
            Originally posted by Rexerex View Post
            If Vulkan is so low level why those things cannot be implemented efficiently without extensions?
            Because extensions are an integral part of the Vulkan design. It has always been the intention that all hardware-specific features would be implemented through extensions.

            Comment


            • #7
              Originally posted by smitty3268 View Post

              Emulating hardware in software will never be as fast as actually using the hardware feature directly.
              So those extensions don't implement any extra logic, only provide direct way to some underlying hardware circuit in graphics card that otherwise would be inaccessible?

              Comment


              • #8
                Originally posted by Rexerex View Post
                If Vulkan is so low level why those things cannot be implemented efficiently without extensions?
                Thats like asking if C is so low level, why does something need to be programmed in it. extensions are how VK work.

                Comment


                • #9
                  Originally posted by Quackdoc View Post

                  Thats like asking if C is so low level, why does something need to be programmed in it. extensions are how VK work.
                  I think you totally misunderstand my question. If Vulkan is low level I imagine developers already has access to whatever graphic card is capable of. OpenGL implements extra abstraction layer of state machine over GPU so it is logical that if you want access some extra feature of GPU then it must be in OpenGL API.

                  Comment


                  • #10
                    Originally posted by Rexerex View Post

                    I think you totally misunderstand my question. If Vulkan is low level I imagine developers already has access to whatever graphic card is capable of. OpenGL implements extra abstraction layer of state machine over GPU so it is logical that if you want access some extra feature of GPU then it must be in OpenGL API.
                    Nope, I didn't misunderstand. Again, think of vulkan as an ISA and and extensions the instructions. you still have to implement the instructions on the device. What an Graphics API does is act as a layer between some generic Graphics code, and the proprietary GPU code. Back the ISA analogy. you can add instructions to the set. but you still need the device to support it. so how do vulkan and gpus do this? Vulkan writes an extension. (Adds an instruction to the spec) that is either necessary, or optional. A gpu driver still needs to implement that extension. You cannot just program in that gpu's proprietary code, as it can differ even between gpus in the same family.

                    As another analogy. think of OpenGL as C++, Vulkan as C (Or rust considering that it is still expanding), and GPU proprietary code as assembly. whiie you could in theory, program in GPU's proprietary code.

                    Vulkan is a low level API, meaning it leaves a lot of work in the hands of the developer, but that doesn't mean you can just do what you want with the GPU's hardware, vulkan still needs to support it, and the GPU driver still needs to implement support.

                    This should give you a general idea of how it works, obviously this isn't a great explanation, but the general idea stands.

                    Comment

                    Working...
                    X