Announcement

Collapse
No announcement yet.

Vulkan 1.0.5 API Specification Released

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

  • #21
    Originally posted by M1kkko View Post

    There is a specification AND the Nvidia's proprietary driver, which happens to be the implementation that developers will actually be testing their software against. And the specification seems to be too high-level to accurately tell how Nvidia compiles the GLSL shaders to SPIR-V in their driver. There's so much newly-introduced complexity that even in the best case scenario, at least some difference in performance across implementations is to be expected.



    Yeah, and the performance of the open source drivers has been in such a great shape for all these years.
    Really? You know, contrary to popular belief, the specifications are generally quite readable. Why don't you read it before spouting more filth?
    http://developer.download.nvidia.com...lsl_shader.txt

    EDIT: Performance isn't an issue. Vulkan was designed to remove overhead and give application developers control, not to speed up implementation. The specification will never take into account "speed" which is a relative term anyways...
    Last edited by computerquip; 05 March 2016, 07:31 PM.

    Comment


    • #22
      Originally posted by computerquip View Post
      Really? You know, contrary to popular belief, the specifications are generally quite readable. Why don't you read it before spouting more filth?
      http://developer.download.nvidia.com...lsl_shader.txt
      Your link requires some authentication to open?

      Comment


      • #23
        Originally posted by M1kkko View Post

        Your link requires some authentication to open?

        Don't think so: https://developer.nvidia.com/vknvglslshader

        Comment


        • #24
          Only standarised features should go to common specification, vendors' extensions should be documented and maintained in their own ext-spec.

          Comment


          • #25
            Why does AMD invest in R&D, if they end either benefiting the competition or shooting themselves in the foot...

            Comment


            • #26
              Originally posted by asdfblah View Post
              Why does AMD invest in R&D, if they end either benefiting the competition or shooting themselves in the foot...

              Because, according to them, they believe in an open game market.

              Comment


              • #27
                Originally posted by computerquip View Post
                Yeah, that. It is indeed quite readable. It clearly says that, instead of writing a shader in SPIR-V (which is low-level and explicit, easy to consume by a driver), a user can write a shader in GLSL (which is high-level and complex), and the Nvidia driver will magically compile it in an efficient manner.

                Comment


                • #28
                  Originally posted by M1kkko View Post

                  Yeah, that. It is indeed quite readable. It clearly says that, instead of writing a shader in SPIR-V (which is low-level and explicit, easy to consume by a driver), a user can write a shader in GLSL (which is high-level and complex), and the Nvidia driver will magically compile it in an efficient manner.
                  It says absolutely nothing about being efficient. It doesn't even say how it will compile the GLSL. In concept, it doesn't have too.

                  Comment


                  • #29
                    I find the notion that the standard is already being extended with alternate (but vendor-specific) ways to do things that are already possible (in the core spec) a very, very bad sign. I had great hopes for Vulkan, that it might not become the mess that is OpenGL (where a beginner is faced with hundreds of extensions that may or may not be supported on specific drivers and hardware), but before there are even proper drivers or applications, the game starts again.

                    I suppose NVidia will frantically port every OpenGL extension they support to Vulkan now, leaving us with (yet again) an absolute jungle of unclear extensions a few years down the road. This is just incredibly disappointing.

                    Comment


                    • #30
                      Originally posted by plonoma View Post
                      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.
                      No, Mantle & now Vulkan were designed to allow a lower level API, closer to the hardware, without the attempted high level abstractions right for the 1990's (but not matching HW now) which resembles strongly to the middle layer mistake anti-pattern. Low level, close to hardware is MESSY; there's ALWAYS vendor specifics, kludges & fixes for broken stuff, imagining that there can be a low level API portable between different GPU architectures is a pipe dream, that's what the game engine/platform is for.

                      A compiler for a shader doesn't even need to be loaded if unused, and IF it's bloat and "ruins the leand driver", it's GOING to be Nvidia's problem, but their engineers will be well aware of that. Probably with Nvidia's HW not supporting multi-threaded async model of DX12 & Vulkan as well as AMD, they're trying to maintain mindshare of developers, by making porting easier, let's them stick the Vulkan label on their product without as much effort.

                      The strength of the open tool chain is going to be key; without much commonality Vulkan will sink in the fragmentation of a morass of confusing implementations with so much pointless differences and brokeness that it adds no real value over a vendor specific API like Mantle.

                      Comment

                      Working...
                      X