3 ms·

> 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

> 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.

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.