The take away for me is that vulkan is similar to opengl. Mindlessly complex APIs just to play around with basic stuff. Graphics really doesn't need to be this complicated :/
With all due respect, you're definitely not the target market for Vulkan. It's an incredibly low level abstraction layer over GPUs intended to allow rendering engine developers to control the intricate details of the pipeline. For something simple, you'll want to use a game engine like Unity or Unreal, which build on top of this low level stuff to build nice, high level abstractions.
I wander if mass adoption of Vulkan for engine development would initiate "gentrification" - I mean, currently, engine devs enjoy working with OpenGL (or D3D), and there is a big chance many people simply won't enjoy using Vulkan so they won't use it or just leave the field altogether. I suspect using Vulkan will be comfortable for GPU hardware people (hence different demographic).
> currently, engine devs enjoy working with OpenGL (or D3D)
Where did you get that idea? I almost only ever hear bad things about them both. Bloated APIs with even more bloated drivers. Layers upon layers of hacks and fixes.
Presumably, Vulkan will enable the emergence of slim, nice, rapidly evolving apis built on top of them, giving developers much better tools to build apps or engines with.
> giving developers much better tools to build apps or engines with.
oh, that's the different [good] thing.
I was talking about abstraction level/layer - I doubt those who enjoy (feel comfortable) working at the OpenGL or D3D layer will be the same contingent who will enjoy using Vulkan.
But as you said, if some other API-s emerge on top of Vulkan, better than OpenGL, that would be great of course.
Vulkan has practically no incidental complexity. The API is complex because it maps directly to a very complex system of hardware. Any simplification would make it worse.
If you want a simple way to draw graphics without all the complexity, you don't want a graphics API, you want a game engine.
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).
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.
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.
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]
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.
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.
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.
It's very low level. Khronos noted, that they didn't have time / resources to create a higher level API (on top of Vulkan) that would at least match the level of OpenGL in usability (but would avoid its downsides like stateful nature). Hopefully someone will make such higher level library. Engines can't fill that role - they are too high level and specialized already. So that middle layer is still missing.
Because OpenGL is stateful by design. Since there isn't anything else high level enough, OpenGL is still useful, but yes, I expect it to remain only for legacy applications once something better based on Vulkan will emerge.
Before vulkan you were on the mercy of Nvidia and Ati to literally rewrite your shaders behind the scenes to get good performance. Ati were notoriously bad at this which lead to Nvidia winning big couple of generations in a row, despite having a modest lead at best in tech.
Because it assumes the idea that OpenGL is for higher level, and Vulkan is for lower level. However what's needed for higher level is some stateless API based on Vulkan, and that's currently simply missing.
