3 ms·
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 comple
by 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 agoI 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 agoGood point. That would be particularly neat if the OpenGL/D3D implementations became vendor-independent.
- datenwolf 10y agoThis 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.