Hacker News Reader

Comment by panic | Hacker News Reader

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

View on HN

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

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

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?

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.

Good point. That would be particularly neat if the OpenGL/D3D implementations became vendor-independent.

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.

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.

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

[2] https://www.youtube.com/watch?v=6ChMEMQxQLw

Don't forget Ashes of the Singularity! 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.

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

[2] https://translate.google.de/translate?hl=de?sl=auto&sl=auto&...

I'd compare performance gains of Vulkan with OpenGL, not with DX11.

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.

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.

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.

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!

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.

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.

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

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

Reply on news.ycombinator.com