5 ms·

It's possible to make a less-complex low-level graphics API. Apple's Metal framework manages to be much easier to use (though still a bit of work to set up).

by panic 10y ago

flohofwoe 10y ago
I fully agree that Metal is a much nicer API than Vulkan or OpenGL, but IMHO it isn't really a low-level API in the sense of D3D12 or Vulkan. While Metal also has pipeline-state-objects, command-buffers and some other 'explicit features' like the other two APIs, the entire resource binding is very high level, more like in D3D11 (which IMHO is a good thing, because that is exactly the part that makes D3D12 and Vulkan so complex, while providing only few advantages over the more traditional resource binding). Also, it is still unclear whether D3D12 or Vulkan (or Metal on OSX for that matter) actually provide a real-world advantage in complex games. Most big games that have been released with a D3D12 renderer so far, don't run better than with the D3D11 renderer. Metal mostly shines on iOS, where it is dramatically faster then OpenGLES, but it isn't dramatically better on OSX (at least on the Intel GPU configs I'm testing on).
- shmerl 10y ago
  I'd compare performance gains of Vulkan with OpenGL, not with DX11.
  - tormeh 10y ago
    Why? OpenGL is hardly relevant on the desktop. It lost to D3D and everyone knows it. Besides CAD-users few would notice if it stopped working. It should be compared with Dx11 and Dx12 which are the competitors.
    - floatboth 10y ago
      The new DOOM uses OpenGL! And it will receive Vulkan support in a patch "soon". Also, there are platforms other than Windows. All the games ported to OS X and Linux use OpenGL.
      - tormeh 10y ago
        I used to be a Linux gamer, so I know. OpenGL (and Mac/Linux) still lost. That's just how it is. Now that Vulkan is out, non-Windows gaming has a second chance. We can stop pretending OpenGL matters now.
        floatboth 10y ago
        If it "lost", why did Valve port their games to it & encourage others to port their stuff as well? Oh, also, pretty much all mobile gaming is OpenGL ES. Also there's WebGL!
        pjmlp 10y ago
        Because they are afraid of being left out of Windows when everyone starts making use of Windows Store and they lose their STEAM margins. OpenGL ES on iOS is for compatibility purposes nowadays, as presented at WWDC 2015, all new features are on Metal. WebGL still under delivers on mobile devices, only the most expensive devices are able to render something without chocking. On the desktop is basically used for web site animations and 3D viewers, VRML style.
        shmerl 10y ago
        To all the above - Vulkan is a next iteration of open API, not of MS lock-in. All this "lost" or not is irrelevant. Try using DX anywhere outside of MS systems, and then come back and propose using it if you succeed.
- redtuesday 10y ago
  Depends probably on the games. I can see games like the recently released Stellaris [1] or Star Ruler 2 [2] with it's tens of thousands of spaceships or similar gain the most thanks to the new API's, and it should possibly enable developers to implement things that were previously not feasable because of the draw calls. [1] https://www.paradoxplaza.com/stellaris https://www.paradoxplaza.com/stellaris [2] https://www.youtube.com/watch?v=6ChMEMQxQLw https://www.youtube.com/watch?v=6ChMEMQxQLw
  - floatboth 10y ago
    Don't forget Ashes of the Singularity! http://www.legitreviews.com/ashes-singularity-dx12-benchmarks-amd-nvidia_179551/3 http://www.legitreviews.com/ashes-singularity-dx12-benchmark... DX12 makes AMD cards work really well (thanks to async stuff) and allows AMD+nVidia multi-GPU.
    - redtuesday 10y ago
      Yes, totally forgot that game. Really a good showcase of what's possible. Yes, AMD profits probably the most from the new API's, the CPU's from them get also a good boost because the kind of single threaded-ness of DX11 [1] hurt them. For example, Hitman with DX11 on a AMD FX 8370 and GTX 980 Ti achieves only 41.5 fps while a Intel 6700k reaches 72.5 fps. With DX12 the same AMD system achieves 65.2 fps (Intel 68.3).[2] [1] http://www.littletinyfrogs.com/article/460524/DirectX_11_vs_DirectX_12_oversimplified http://www.littletinyfrogs.com/article/460524/DirectX_11_vs_... [2] https://translate.google.de/translate?hl=de?sl=auto&sl=auto&tl=en&u=http%3A%2F%2Fwww.computerbase.de%2F2016-03%2Fhitman-benchmarks-directx-12%2F2%2F https://translate.google.de/translate?hl=de?sl=auto&sl=auto&...
- pandaman 10y ago
  Surprisingly, resource binding is the key to performance both on CPU and GPU. The method of binding resources to some "slots" (registers/handles/etc) while being easy to understand is not present in modern hardware. There used to be actual registers for textures/samplers/buffers (well, I don't recall if there had been any hardware with buffers, but there had been just float4 regs to get non-texture data into the shaders) but not any more. Emulating these in software is expensive as you are essentially running a multi-process application, where every process gets parameters from the global state. You can either run it sequentially (very slow) or make a copy of the state for each process (generally slow, but there are tricks like fragmenting the state and only copying the changed fragments). I suspect the reason the DX12/Vulkan games are not showing much improvement in performance is that they share most of the code with the legacy DX11/OpenGL and keep emulating the global state for the new API.
- datenwolf 10y ago
  > Also, it is still unclear whether D3D12 or Vulkan (or Metal on OSX for that matter) actually provide a real-world advantage in complex games. The main reason for revamped APIs like Vulkan are not performance enhancements but reducing driver complexity and give better diagnostics to developers. Also huge amounts of current generation GPU drivers are heuristics for increasing applications' performance but more importantly to make inherently broken applications (that violate the API contract) still work. At a recent Khronos event one of the Vulkan engineers of Team Red put it in the following words: "OpenGL and Direct3D-11 and before have the architectural legacy of GPUs as they were 10, 20 years ago. Since then GPUs went that way, while OpenGL and <=D3D-11 went another one. D3D-12 and Vulkan are APIs designed for the modern GPU way, and in 20 years we'll likely see another way of GPUs and APIs".
  - tgb 10y ago
    I know driver complexity is a common point for Vulcan, but given that opengl and direct3d are here to stay, aren't the drivers going to get strictly more complex due to it?
    - wtetzner 10y ago
      I imagine the drivers could just support Vulkan, and the OS could provide a library that implements OpenGL and D3D on top of Vulkan. That way only one implementation of OpenGL would be needed, and it could live outside of the driver.
      - tgb 10y ago
        Good point. That would be particularly neat if the OpenGL/D3D implementations became vendor-independent.
    - datenwolf 10y ago
      This aspect is two-fold (at least). Yes, it's on the roadmap to implement OpenGL on Vulkan and probably also legacy-D3D on top of D3D-12. But what's more important is, that all the complexity of OpenGL and legacy-D3D drivers make it very difficult to hit the fast codepaths of the driver. And OpenGL has the problem that one cannot effectively queue drawing commands from several threads; not to be confused with the (ill) attempt to render from several threads at the same time. We're just talking about the preparation steps here, i.e. traversing the scene, visiting each element sorting them, and one drawing order is determined submitting them into a queue that then can be batched for drawing. With Vulkan one can utilize the multiple CPU cores we have these days: Each core may collect a different aspect of a scene into a different queue.
gulpahum 10y ago
I had a look at a Metal tutorial [1], which does the same initialization as the Vulkan tutorial. Indeed, it has similar concept, but is also simpler (partly because it is written in Swift, not C++). I wonder if anyone has written a wrapper, which would be at the same level as Metal, but run on top of Metal and Vulkan. That would be something I'd like to use! I still think Vulkan is great. Now, we need to start building libraries on top of it. The nice thing about very low-level APIs is that it is possible to write higher-level APIs on top of them. The opposite isn't really possible. [1] https://www.raywenderlich.com/77488/ios-8-metal-tutorial-swift-getting-started https://www.raywenderlich.com/77488/ios-8-metal-tutorial-swi...
- izym 10y ago
  The gfx-rs library for Rust is actually targeting exactly that, although they aren't there yet.

It's possible to make a less-complex low-level graphics API. Apple's Metal framework manages to be much easier to use (though still a bit of work to set up).

by panic 10y ago

It's possible to make a less-complex low-level graphics API. Apple's Metal framework manages to be much easier to use (though still a bit of work to set up).

flohofwoe 10y ago

I fully agree that Metal is a much nicer API than Vulkan or OpenGL, but IMHO it isn't really a low-level API in the sense of D3D12 or Vulkan. While Metal also has pipeline-state-objects, command-buffers and some other 'explicit features' like the other two APIs, the entire resource binding is very high level, more like in D3D11 (which IMHO is a good thing, because that is exactly the part that makes D3D12 and Vulkan so complex, while providing only few advantages over the more traditional resource binding). Also, it is still unclear whether D3D12 or Vulkan (or Metal on OSX for that matter) actually provide a real-world advantage in complex games. Most big games that have been released with a D3D12 renderer so far, don't run better than with the D3D11 renderer. Metal mostly shines on iOS, where it is dramatically faster then OpenGLES, but it isn't dramatically better on OSX (at least on the Intel GPU configs I'm testing on).

shmerl 10y ago
I'd compare performance gains of Vulkan with OpenGL, not with DX11.
- tormeh 10y ago
  Why? OpenGL is hardly relevant on the desktop. It lost to D3D and everyone knows it. Besides CAD-users few would notice if it stopped working. It should be compared with Dx11 and Dx12 which are the competitors.
  - floatboth 10y ago
    The new DOOM uses OpenGL! And it will receive Vulkan support in a patch "soon". Also, there are platforms other than Windows. All the games ported to OS X and Linux use OpenGL.
    - tormeh 10y ago
      I used to be a Linux gamer, so I know. OpenGL (and Mac/Linux) still lost. That's just how it is. Now that Vulkan is out, non-Windows gaming has a second chance. We can stop pretending OpenGL matters now.
      - floatboth 10y ago
        If it "lost", why did Valve port their games to it & encourage others to port their stuff as well? Oh, also, pretty much all mobile gaming is OpenGL ES. Also there's WebGL!
        pjmlp 10y ago
        Because they are afraid of being left out of Windows when everyone starts making use of Windows Store and they lose their STEAM margins. OpenGL ES on iOS is for compatibility purposes nowadays, as presented at WWDC 2015, all new features are on Metal. WebGL still under delivers on mobile devices, only the most expensive devices are able to render something without chocking. On the desktop is basically used for web site animations and 3D viewers, VRML style.
        shmerl 10y ago
        To all the above - Vulkan is a next iteration of open API, not of MS lock-in. All this "lost" or not is irrelevant. Try using DX anywhere outside of MS systems, and then come back and propose using it if you succeed.
redtuesday 10y ago
Depends probably on the games. I can see games like the recently released Stellaris [1] or Star Ruler 2 [2] with it's tens of thousands of spaceships or similar gain the most thanks to the new API's, and it should possibly enable developers to implement things that were previously not feasable because of the draw calls. [1] https://www.paradoxplaza.com/stellaris https://www.paradoxplaza.com/stellaris [2] https://www.youtube.com/watch?v=6ChMEMQxQLw https://www.youtube.com/watch?v=6ChMEMQxQLw
- floatboth 10y ago
  Don't forget Ashes of the Singularity! http://www.legitreviews.com/ashes-singularity-dx12-benchmarks-amd-nvidia_179551/3 http://www.legitreviews.com/ashes-singularity-dx12-benchmark... DX12 makes AMD cards work really well (thanks to async stuff) and allows AMD+nVidia multi-GPU.
  - redtuesday 10y ago
    Yes, totally forgot that game. Really a good showcase of what's possible. Yes, AMD profits probably the most from the new API's, the CPU's from them get also a good boost because the kind of single threaded-ness of DX11 [1] hurt them. For example, Hitman with DX11 on a AMD FX 8370 and GTX 980 Ti achieves only 41.5 fps while a Intel 6700k reaches 72.5 fps. With DX12 the same AMD system achieves 65.2 fps (Intel 68.3).[2] [1] http://www.littletinyfrogs.com/article/460524/DirectX_11_vs_DirectX_12_oversimplified http://www.littletinyfrogs.com/article/460524/DirectX_11_vs_... [2] https://translate.google.de/translate?hl=de?sl=auto&sl=auto&tl=en&u=http%3A%2F%2Fwww.computerbase.de%2F2016-03%2Fhitman-benchmarks-directx-12%2F2%2F https://translate.google.de/translate?hl=de?sl=auto&sl=auto&...
pandaman 10y ago
Surprisingly, resource binding is the key to performance both on CPU and GPU. The method of binding resources to some "slots" (registers/handles/etc) while being easy to understand is not present in modern hardware. There used to be actual registers for textures/samplers/buffers (well, I don't recall if there had been any hardware with buffers, but there had been just float4 regs to get non-texture data into the shaders) but not any more. Emulating these in software is expensive as you are essentially running a multi-process application, where every process gets parameters from the global state. You can either run it sequentially (very slow) or make a copy of the state for each process (generally slow, but there are tricks like fragmenting the state and only copying the changed fragments). I suspect the reason the DX12/Vulkan games are not showing much improvement in performance is that they share most of the code with the legacy DX11/OpenGL and keep emulating the global state for the new API.
datenwolf 10y ago
> Also, it is still unclear whether D3D12 or Vulkan (or Metal on OSX for that matter) actually provide a real-world advantage in complex games. The main reason for revamped APIs like Vulkan are not performance enhancements but reducing driver complexity and give better diagnostics to developers. Also huge amounts of current generation GPU drivers are heuristics for increasing applications' performance but more importantly to make inherently broken applications (that violate the API contract) still work. At a recent Khronos event one of the Vulkan engineers of Team Red put it in the following words: "OpenGL and Direct3D-11 and before have the architectural legacy of GPUs as they were 10, 20 years ago. Since then GPUs went that way, while OpenGL and <=D3D-11 went another one. D3D-12 and Vulkan are APIs designed for the modern GPU way, and in 20 years we'll likely see another way of GPUs and APIs".
- tgb 10y ago
  I know driver complexity is a common point for Vulcan, but given that opengl and direct3d are here to stay, aren't the drivers going to get strictly more complex due to it?
  - wtetzner 10y ago
    I imagine the drivers could just support Vulkan, and the OS could provide a library that implements OpenGL and D3D on top of Vulkan. That way only one implementation of OpenGL would be needed, and it could live outside of the driver.
    - tgb 10y ago
      Good point. That would be particularly neat if the OpenGL/D3D implementations became vendor-independent.
  - datenwolf 10y ago
    This aspect is two-fold (at least). Yes, it's on the roadmap to implement OpenGL on Vulkan and probably also legacy-D3D on top of D3D-12. But what's more important is, that all the complexity of OpenGL and legacy-D3D drivers make it very difficult to hit the fast codepaths of the driver. And OpenGL has the problem that one cannot effectively queue drawing commands from several threads; not to be confused with the (ill) attempt to render from several threads at the same time. We're just talking about the preparation steps here, i.e. traversing the scene, visiting each element sorting them, and one drawing order is determined submitting them into a queue that then can be batched for drawing. With Vulkan one can utilize the multiple CPU cores we have these days: Each core may collect a different aspect of a scene into a different queue.

gulpahum 10y ago

I had a look at a Metal tutorial [1], which does the same initialization as the Vulkan tutorial. Indeed, it has similar concept, but is also simpler (partly because it is written in Swift, not C++). I wonder if anyone has written a wrapper, which would be at the same level as Metal, but run on top of Metal and Vulkan. That would be something I'd like to use! I still think Vulkan is great. Now, we need to start building libraries on top of it. The nice thing about very low-level APIs is that it is possible to write higher-level APIs on top of them. The opposite isn't really possible. [1] https://www.raywenderlich.com/77488/ios-8-metal-tutorial-swift-getting-started https://www.raywenderlich.com/77488/ios-8-metal-tutorial-swi...

izym 10y ago
The gfx-rs library for Rust is actually targeting exactly that, although they aren't there yet.