8 ms·

> Actually that's not correct. Vulkan was explicitly designed to be an efficient and high-performance API. As it stands, even as a newborn API, it's the BEST av

by Rusky 10y ago

> Actually that's not correct. Vulkan was explicitly designed to be an efficient and high-performance API. As it stands, even as a newborn API, it's the BEST available for 3D rendering on all platforms that support it, unofficial or not. Just because it was designed to be high-performance doesn't mean it automatically wins on platform support and implementation quality. Direct3D 12 is at the same level as Vulkan, and I see no reason for the trend of D3D being higher quality than GL to end with Vulkan.

ioquatix 10y ago
Those are pretty subjective assertions. Do you have any evidence to back that up?
- om2 10y ago
  Do you have any evidence for your claim that Vulkan is best? Metal and D3D 12 are also low-level APIs designed for performance. I've seen no evidence that Vulkan is better on platforms where there are drivers for two different APIs.
  - Zandikar 10y ago
    I think we've all gone a bit off the rails here. Although you and those you've been discussing this with can't agree on which API is better, there's plenty of evidence that Vulcan, Metal and Dx are all quite good. Why then would we introduce yet another "standard" from scratch, as opposed to working to implement one of the existing ones better across platforms (if the desire is truly to build a universal gfx api)?
    - om2 10y ago
      Making a new standard is inevitable. That's not really a choice. Even if the web platform directly replicated one of the existing APIs, you still have to explain how it binds to JavaScript, as well as memory and GPU resource management details. So bringing a modern graphics API to the web will inevitably create a new standard. The question then is whether to try to clone one of the native-level APIs, or make something that works on each of the top 3. We think working on all of them is better than tying ourselves to just one.
      - shmerl 10y ago
        > The question then is whether to try to clone one of the native-level APIs, or make something that works on each of the top 3. We think working on all of them is better than tying ourselves to just one. Besides this approach being supportive of lock-in (of underlying closed APIs like Metal and DX), which is more than questionable, more importantly, what shading language should this Web API use for example?
        ioquatix 10y ago
        When you look at the amount of effort that's gone into SPIR-V you'll only have one conclusion to this question.
        shmerl 10y ago
        Indeed, the question was rhetorical, and more of a poke at using Metal shaders in the initial proposal, instead of going right away with open languages and representations.
        simonh 10y ago
        Tying the implementation to a single underlying API is just another kind of lock-in. You can be locked in to an open standard just as much as a proprietary one. Suppose this had been proposed 5 years ago and been tied deeply into OpenGL? In the world of today, that would pretty much make it a dead end. It's just not the job of a standard like this to pick and choose winners at a different level of abstraction.
        om2 10y ago
        We did actually build a standard tied deeply OpenGL, it's called WebGL. And indeed, we foresee the need to move beyond it (though WebGL is still plenty good and not a dead end yet.) Worth noting also that Khronos is considering a slightly higher-level API than Vulkan as their next iteration. So that's another reason it would be a shame to bind too tightly to Vulkan. I also find it puzzling how designing to support multiple back ends is "lock-in" but binding tightly to only one underlying API is "open".
  - ioquatix 10y ago
    Well, I guess you know all this but you've asked me to elaborate. So, in terms of compatibility you have: DX12: Windows only. Metal: macOS/iOS only. Vulkan: cross-platform and cross-vendor. Windows 7/8/10, Android, Linux, MoltenVK supports iOS/macOS with a wrapper. That's a big win for Vulkan IMHO. Valve also agrees with this assertion. In terms of performance, I don't think Metal is even a contender, given how bad macOS hardware is compared to Wintel. w.r.t. Vulkan vs DX, from what I've seen it's pretty close, with Vulkan usually coming out ahead by a few performance points but of course it depends a lot on the implementation when it's at that level. Vulkan has been shown to be systematically better than OpenGL.
    - MrScruff 10y ago
      It makes no sense to judge the quality of an API by the power of the available hardware it might be running on. The discussion is not about what platform will run VR the best. In addition, Apple will be rightly considering iOS when evaluating options for web technologies, not the increasingly small section of the planet running Nvidia and AMD hardware on Windows.
      - ioquatix 10y ago
        > It makes no sense to judge the quality of an API by the power of the available hardware it might be running on. I didn't make any such judgement or even mention VR a single time! But, looking at the points you've raised, I can say with confidence that Vulkan has been designed, taking into considering these issues. Vulkan has been carefully engineered from the ground up not to alienate tile-based renderer hardware. So, it's just as suitable for mobile GPUs as desktop GPUs. https://www.imgtec.com/blog/tiling-positive-or-how-vulkan-maps-to-powervr-gpus/ https://www.imgtec.com/blog/tiling-positive-or-how-vulkan-ma... As such, it's already supported by many mobile GPU hardware vendors. > In addition, Apple will be rightly considering iOS when evaluating options for web technologies, not the increasingly small section of the planet running Nvidia and AMD hardware on Windows. The GPU in the iPhone 7 uses a custom version of the PowerVR GT7600 GPU. While this is purely speculation, PowerVR does support Vulkan in their other offerings, so it's not that much of a stretch to assume that the hardware is at least capable of it. NVidia, AMD and Intel power all of Apple's desktop graphics, in addition, they collectively power almost all of Windows and Linux setups too (excepting other mobile and SFF computers)
  - pg_is_a_butt 10y ago
    maybe you should crawl back up inside the infinite loop, and stop interacting with the rest of the world, just like the rest of the apptards you claim to work with. you're all idiots.
- Rusky 10y ago
  There's nothing subjective about it. Take a look at the APIs, they operate at the same level and are designed around the same principles. As for past driver quality, ask a graphics developer doing anything more complicated than a toy weekend project. OpenGL drivers are inconsistent and buggy.
  - ioquatix 10y ago
    > Just because it was designed to be high-performance doesn't mean it automatically wins on platform support and implementation quality. I never asserted that. I didn't even qualify what I meant by "BEST". But, let's evaluate the qualities you mention: > platform support Vulkan objectively wins here, supporting Windows 7/8/10, Linux, macOS/iOS with a wrapper, Android, etc. Intel has unofficial drivers for their x86 iGPU. Qualcomm recently announced hardware support, along with ARM. > implementation quality Vulkan is developed as an open specification, and has a full conformance test for implementations (https://www.khronos.org/vulkan/adopters/ https://www.khronos.org/vulkan/adopters/). Many aspects of Vulkan are available on GitHub and you can submit PRs. In my experience, drivers on Linux are very good and there are frequent updates. We currently deploy Vulkan at scale in production and haven't had a single issue with reliability. In addition, the Vulkan validation layers assist with development because they check almost all API invariants and log incorrect usage. This helps to develop programs that work correctly according to the specs. So, from the driver stack to the client software, Vulkan, IMHO, has a quality and well thought out implementation. In comparison to DX12, which is developed behind closed doors, we don't know the implementation quality. I personally haven't heard about any major bugs in Vulkan drivers, but I have seen quite few DX12 demos plagued by bugs. That's my subjective opinion though. > Direct3D 12 is at the same level as Vulkan Vulkan is better than DX12 in terms of openness, conformance testing, development tools, platform support, etc. Performance is about the same. Even Valve agrees: http://www.kitguru.net/components/graphic-cards/anton-shilov/valve-directx-12-does-not-make-a-lot-of-sense-vulkan-does/ http://www.kitguru.net/components/graphic-cards/anton-shilov... > OpenGL drivers are inconsistent and buggy. Agreed :)
    - hifigi 10y ago
      I make no argument against what you've said except you used Valve as an "appeal to authority", when they have a vested interest in promoting Vulkan (since SteamOS is based on Linux). So of course they will be persuading developers to use Vulkan over DX12, because it broadens the domain of users who can buy an individual title on Steam.

by Rusky 10y ago

ioquatix 10y ago

Those are pretty subjective assertions. Do you have any evidence to back that up?

om2 10y ago
Do you have any evidence for your claim that Vulkan is best? Metal and D3D 12 are also low-level APIs designed for performance. I've seen no evidence that Vulkan is better on platforms where there are drivers for two different APIs.
- Zandikar 10y ago
  I think we've all gone a bit off the rails here. Although you and those you've been discussing this with can't agree on which API is better, there's plenty of evidence that Vulcan, Metal and Dx are all quite good. Why then would we introduce yet another "standard" from scratch, as opposed to working to implement one of the existing ones better across platforms (if the desire is truly to build a universal gfx api)?
  - om2 10y ago
    Making a new standard is inevitable. That's not really a choice. Even if the web platform directly replicated one of the existing APIs, you still have to explain how it binds to JavaScript, as well as memory and GPU resource management details. So bringing a modern graphics API to the web will inevitably create a new standard. The question then is whether to try to clone one of the native-level APIs, or make something that works on each of the top 3. We think working on all of them is better than tying ourselves to just one.
    - shmerl 10y ago
      > The question then is whether to try to clone one of the native-level APIs, or make something that works on each of the top 3. We think working on all of them is better than tying ourselves to just one. Besides this approach being supportive of lock-in (of underlying closed APIs like Metal and DX), which is more than questionable, more importantly, what shading language should this Web API use for example?
      - ioquatix 10y ago
        When you look at the amount of effort that's gone into SPIR-V you'll only have one conclusion to this question.
        shmerl 10y ago
        Indeed, the question was rhetorical, and more of a poke at using Metal shaders in the initial proposal, instead of going right away with open languages and representations.
      - simonh 10y ago
        Tying the implementation to a single underlying API is just another kind of lock-in. You can be locked in to an open standard just as much as a proprietary one. Suppose this had been proposed 5 years ago and been tied deeply into OpenGL? In the world of today, that would pretty much make it a dead end. It's just not the job of a standard like this to pick and choose winners at a different level of abstraction.
        om2 10y ago
        We did actually build a standard tied deeply OpenGL, it's called WebGL. And indeed, we foresee the need to move beyond it (though WebGL is still plenty good and not a dead end yet.) Worth noting also that Khronos is considering a slightly higher-level API than Vulkan as their next iteration. So that's another reason it would be a shame to bind too tightly to Vulkan. I also find it puzzling how designing to support multiple back ends is "lock-in" but binding tightly to only one underlying API is "open".
- ioquatix 10y ago
  Well, I guess you know all this but you've asked me to elaborate. So, in terms of compatibility you have: DX12: Windows only. Metal: macOS/iOS only. Vulkan: cross-platform and cross-vendor. Windows 7/8/10, Android, Linux, MoltenVK supports iOS/macOS with a wrapper. That's a big win for Vulkan IMHO. Valve also agrees with this assertion. In terms of performance, I don't think Metal is even a contender, given how bad macOS hardware is compared to Wintel. w.r.t. Vulkan vs DX, from what I've seen it's pretty close, with Vulkan usually coming out ahead by a few performance points but of course it depends a lot on the implementation when it's at that level. Vulkan has been shown to be systematically better than OpenGL.
  - MrScruff 10y ago
    It makes no sense to judge the quality of an API by the power of the available hardware it might be running on. The discussion is not about what platform will run VR the best. In addition, Apple will be rightly considering iOS when evaluating options for web technologies, not the increasingly small section of the planet running Nvidia and AMD hardware on Windows.
    - ioquatix 10y ago
      > It makes no sense to judge the quality of an API by the power of the available hardware it might be running on. I didn't make any such judgement or even mention VR a single time! But, looking at the points you've raised, I can say with confidence that Vulkan has been designed, taking into considering these issues. Vulkan has been carefully engineered from the ground up not to alienate tile-based renderer hardware. So, it's just as suitable for mobile GPUs as desktop GPUs. https://www.imgtec.com/blog/tiling-positive-or-how-vulkan-maps-to-powervr-gpus/ https://www.imgtec.com/blog/tiling-positive-or-how-vulkan-ma... As such, it's already supported by many mobile GPU hardware vendors. > In addition, Apple will be rightly considering iOS when evaluating options for web technologies, not the increasingly small section of the planet running Nvidia and AMD hardware on Windows. The GPU in the iPhone 7 uses a custom version of the PowerVR GT7600 GPU. While this is purely speculation, PowerVR does support Vulkan in their other offerings, so it's not that much of a stretch to assume that the hardware is at least capable of it. NVidia, AMD and Intel power all of Apple's desktop graphics, in addition, they collectively power almost all of Windows and Linux setups too (excepting other mobile and SFF computers)
- pg_is_a_butt 10y ago
  maybe you should crawl back up inside the infinite loop, and stop interacting with the rest of the world, just like the rest of the apptards you claim to work with. you're all idiots.
Rusky 10y ago
There's nothing subjective about it. Take a look at the APIs, they operate at the same level and are designed around the same principles. As for past driver quality, ask a graphics developer doing anything more complicated than a toy weekend project. OpenGL drivers are inconsistent and buggy.
- ioquatix 10y ago
  > Just because it was designed to be high-performance doesn't mean it automatically wins on platform support and implementation quality. I never asserted that. I didn't even qualify what I meant by "BEST". But, let's evaluate the qualities you mention: > platform support Vulkan objectively wins here, supporting Windows 7/8/10, Linux, macOS/iOS with a wrapper, Android, etc. Intel has unofficial drivers for their x86 iGPU. Qualcomm recently announced hardware support, along with ARM. > implementation quality Vulkan is developed as an open specification, and has a full conformance test for implementations (https://www.khronos.org/vulkan/adopters/ https://www.khronos.org/vulkan/adopters/). Many aspects of Vulkan are available on GitHub and you can submit PRs. In my experience, drivers on Linux are very good and there are frequent updates. We currently deploy Vulkan at scale in production and haven't had a single issue with reliability. In addition, the Vulkan validation layers assist with development because they check almost all API invariants and log incorrect usage. This helps to develop programs that work correctly according to the specs. So, from the driver stack to the client software, Vulkan, IMHO, has a quality and well thought out implementation. In comparison to DX12, which is developed behind closed doors, we don't know the implementation quality. I personally haven't heard about any major bugs in Vulkan drivers, but I have seen quite few DX12 demos plagued by bugs. That's my subjective opinion though. > Direct3D 12 is at the same level as Vulkan Vulkan is better than DX12 in terms of openness, conformance testing, development tools, platform support, etc. Performance is about the same. Even Valve agrees: http://www.kitguru.net/components/graphic-cards/anton-shilov/valve-directx-12-does-not-make-a-lot-of-sense-vulkan-does/ http://www.kitguru.net/components/graphic-cards/anton-shilov... > OpenGL drivers are inconsistent and buggy. Agreed :)
  - hifigi 10y ago
    I make no argument against what you've said except you used Valve as an "appeal to authority", when they have a vested interest in promoting Vulkan (since SteamOS is based on Linux). So of course they will be persuading developers to use Vulkan over DX12, because it broadens the domain of users who can buy an individual title on Steam.