Vulkan Documentation
docs.vulkan.org
docs.vulkan.org
I've been strongly attracted to Vulkan since it was announced in 2015. Being annoyed by the limitations of OpenGL for scientific visualizations, it seemed like a significant improvement. When the specification was released, I was both fascinated and terrified by its extreme complexity. I understood mostly nothing at first. I took it as a personal challenge to learn it and do something with it.
After dozens of times reading the documentation and experimenting with the code (tutorials were scarce at the time), I started to understand the most basic functionality. I spent much of the Covid lockdowns playing with Vulkan and developing prototypes of a scientific visualization library in C [1].
In the process, I wrote a thin wrapper in C on top of Vulkan to make it less painful to use [2]. It turns out this wrapper is quite similar to WebGPU. I'll explore interoperability avenues later.
Datoviz is still an experimental project. I'm actively working on the next version of Datoviz which I hope to release in a few months.
The way I've been working with pyQtGraph, I have an object reading data from a serial port. That object parses the raw data and sends it to a buffer. The pyQtGraph runs in a separate thread, which consumes the buffer, generates a new frame, then displays that frame.
How does datovis handle real time data streaming? It seems like your digital signals example is similar
(I'm a technical writer, not affiliated with Vulkan, just trying to get data points on what generally makes good / bad docs sites)
Everything Vulkan currently is contaminated with C++ Object-itis Global State which makes everything look like old-school OpenGL code in spite of the fact that's not the way anyone uses these modern APIs.
With Vulkan, especially, this is a real crime since the C API is incredibly well done. (This is especially infuriating in the case of the Vulkan Memory Allocator which requires C++).
For example, timeline semaphores in Vulkan simplify so much, yet very little of the sample code uses them because they are relatively new. Dynamic state, similarly. Subpasses need to die unless you are on mobile and are verifiably GPU performance bound.
Have you looked into it?
First off it’s really weird to start with a page that links back to the main site and then explains how to navigate the site. If it’s not obvious how to use your nav bar then you’re off to a really bad start. The home page should describe Vulkan and give me enough info to figure out where I need to go next. It should not be a mini tutorial on how to navigate.
Further, when I click on Education from the home page for example, it doesn't go anywhere (scrolls to the top of the page). When I click on the Vulkan Proposals link, it goes to a one paragraph thing that says it’s a cross link and when I click the link it goes back to the homepage. I’m so confused. I’m using mobile right now maybe it’s not broken on desktop?
It was a running joke that it was faster to search on the PDF documentation, than load the site.
Also, don't be fooled by the name. While WebGPU was designed for the web browser, there are already some solid native implementations (wgpu and Dawn), and can definitely fill in the same role as Vulkan/DX12/Metal for most casual usages.
I never learned OpenGL, but think I will have to eventually refer to some OpenGL material, because there's no WebGPU material except the spec and like 3 incomplete tutorials.
[0]: WebGPU is a JavaScript API, so Rust cannot implement it exactly, but it's very close.
I agree it keeps you thinking about how to do things as opposed to just copy pasting. It also helps that the examples are small and in JavaScript so it's easier to figure out the logic that need for them to work.
(* meaning, while simplified, it's also missing some convenience features sprinkled in the lower-level APIs. For example, from what I've seen, pipeline explosion is much harder to deal with here.)
OpenGL does a lot of work for you behind the scenes and abstracts away most of the memory management, state management and GPU/CPU synchronization. It lets you worry about 'what' you are rendering and handles a lot of the 'how' internally. Vulcan and its peers (DirectX12, Metal) assume the programmer knows best and requires you to do everything manually. You have more control that way but for a beginner it will swamp you with minutia and make it far more difficult to things up and running.
These APIs being lower level means they are harder to get into, you really have to understand how GPUs work to understand why these APIs are the way they are. If you want to know that then by all means, dive in! It's fascinating stuff, IMO.
To answer your specific question, yes, Vulkan is intended to replace OpenGL.
If I were learning those APIs today, I would personally start with either OpenGL, Metal or DirectX 11 (or 12 if you're slightly braver). They can give someone lots of insights that one can use when learning Vulkan.
Like other people mentioned, WebGPU or WebGL are also more straightforward and a good starting point.
Metal By Example https://metalbyexample.com/
https://www.amazon.com/Metal-Programming-Guide-Tutorial-Refe...
Xcode and Visual Studio also have builtin graphics debuggers for Metal and D3D11 (not sure if the VS debugger also supports D3D12 though).
https://registry.khronos.org/OpenGL-Refpages/gl4/html/glGetE...
There's a debug output extension (or core feature since 4.3) that's slightly more verbose, but not universally supported (e.g. AFAIK not on macOS).
If at least you had posted a link to RenderDoc.
WebGL and WebGPU also show some of the difference in how rendering libraries have evolved. They used to be all "stateful" global state like OpenGL/OpenGL ES. WebGL followed that model as it was simple and needed for the time, but could have bugs if correct flags weren't set.
WebGPU and other newer rendering libraries (Vulkan, Metal, and Direct3D 12) are more "modern" in that they have almost no global state. They are also more raw and lower level and take a bit more to grok.
This is one of the best overviews of the differences between WebGL/WebGPU but also is similar to how OpenGL to Vulkan, Metal, and Direct3D 12 evolved.
https://webgpufundamentals.org/webgpu/lessons/webgpu-from-we...
> The biggest difference is WebGL is a stateful API and WebGPU is not. By that I mean in WebGL there is a bunch of global state. Which textures are currently bound, which buffers are currently bound, what the current program is, what the blending, depth, and stencil settings are. You set those states by calling various API functions like `gl.bindBuffer`, `gl.enable`, `gl.blendFunc`, etc…, and they stay what you set them globally until you change them to something else.
> By contrast, In WebGPU there is almost no global state. Instead, there are the concepts of a pipeline or render pipeline and a render pass which together effectively contain most of the state that was global in WebGL. Which textures, which attributes, which buffers, and all the various other settings. Any settings you don’t set have default values. You can’t modify a pipeline. Instead, you create them and after that they are immutable. If you want different settings you need to create another pipeline. render passes do have some state, but that state is local to the render pass.
> The second-biggest difference is that WebGPU is lower level than WebGL. In WebGL many things connect by names. For example, you declare a uniform in GLSL and you look up its location
> `loc = gl.getUniformLocation(program, 'nameOfUniform')`;
> Another example is varyings, in a vertex shader you use `varying vec2 v_texcoord` or `out vec2 v_texcoord` and in the fragment shader you declare the corresponding varying naming it `v_texcoord`. The good part of this is if you mistype the name you’ll get an error.
> WebGPU, on the other hand, everything is entirely connected by index or byte offset. You don’t create individual uniforms like WebGL, instead you declare uniform blocks (a structure that declares your uniforms). It’s then up to you to make sure you manually organize the data you pass to the shader to match that structure.
> Note: WebGL2 has the same concept, known as Uniform Blocks, but WebGL2 also had the concept of uniforms by name. And, even though individual fields in a WebGL2 Uniform Block needed to be set via byte offsets, (a) you could query WebGL2 for those offsets and (b) you could still look up the block locations themselves by name.
> In WebGPU on the other hand EVERYTHING is by byte offset or index (often called ‘location’) and there is no API to query them. That means it’s entirely up to you to keep those locations in sync and to manually compute byte offsets.
For a time, supporting four rendering engines did cause lots of work for game engines, much more integration and abstraction.
As OpenGL support fades at least one will drop off. I will miss it as I do still love OpenGL/WebGL. OpenGL and OpenGL ES / WebGL in particular opened up mobile/web gaming in ways never before possible. Prior to that you had Director (3D), Flash (Papervision/Away3D/etc), Silverlight and more recently `<canvas>`. Canvas is great for smaller games but you need raw power for rendering 3d and WebGL (almost a direct port of OpenGL ES) brought that and engines like three.js use that well. Mobile gaming became the biggest gaming market due to OpenGL ES and web games took a leap on WebGL, also apps, interactives and tools became faster rendered.
With GL, in many cases the global state is more simple, but to take advantage of GPUs and rendering lower level the innovations were needed. The naming to index/position based for instance is lower level and can also end up in bugs just as the global state in GL could. The benefit is performance and cleaner global state.
It is probably a good idea to learn OpenGL/WebGL as some of the concept in WebGPU/newer engines will be more clear, much of it was simpler with naming.
Maybe the solution is a lower level API (current) and a higher level API (somewhat stateful/named but not so global). That does add extra weight though.
Those D3D11 state objects are roughly: rasterizer-state, blend-state, depth-stencil-state, (vertex-)input-layout, and one shader object per shader stage.
Not at all.
Glide and others before IrisGL became OpenGL and Doom helped miniGL get widespread adoption weren't.
Most game console 3D APIs never were, DirectX also never was.
If you only care about Windows and Linux, you can also just use DirectX and require users make use of Proton.
That's pretty much self-inflicted issue.
> If you only care about Windows and Linux, you can also just use DirectX and require users make use of Proton.
Proton drags in Wine, so it is even more heavy-weight than MoltenVK.
Don’t use Proton as API. It is a compatibility layer trying to implement what Microsoft’s implementation probably does. Use Vulkan or OpenGL if you can.
Proprietary APIs? In 2023 we shall all know to avoid them. It is not 1998.
The unfortunate move from Apple is Metal instead of going all in for Vulkan. And now they struggle and need foster native ports. They shall support itself Vulkan and improve it - and therefore improve support of Linux and MacOS.
... At least for commercial, closed source stuff.
I'm exclusively on Linux, a casual gamer, and native ports suck. They probably can be done better, but you still run into the problem that some Linux game released 5 years ago doesn't even launch anymore on current distros.
I've tried to play the native port of lis2 only to be greeted with a "hey this game needs an AMD or Nvidia GPU" warning, which I could click past only to have the whole system freeze in the main menu. That was literally the first ever crash of that machine ever (about 14 months old at that point). Luckily steam allows you to force using the windows version of a game even if a native port is available and guess what, no warning about GPU, game worked flawlessly. And it very likely still will a decade from now. How many native games released today will?
Morale of the story: win32 is the only stable userspace API on Linux. Develop for win32 and test on Linux, boom you got your multi-platform game.
This way you can evade proprietary DirectX12.
Valves native ports of games - CS1, CSS, CSGO, CS2 [sic!], HL1 and HL2 run well on Linux. As the famous titles of id Software? As far as I know you can still run the original executable from Quake3 but it is not a wise decision (missing bugfixes, X86_32 and OSS). But they went the save way and just published the engine sources.
And? Proton's own foundation is Linux. And Valve layered a lot of complexity away with it Linux-Runtimes (the most recent is "Sniper 3.x"). I would be just happy if developers accustomed to Windows stop supporting specific (outdated) Linux-Distributions with awkward self made packages. Instead they should merely publishing ELF-Executables, the resources and a list of dependencies - and the maintainers will care. And aside they could ship one Flatpak, made itself. Both things are done by Valve :)
I think most of that issues come from "training" from Windows, where just everyone does the task itself and no rules for shipping exist. And when a developer isn't familiar with the target system and porting problems are more likely. Apple does handle this different, they force the developers doing it in the specified way (you don't get a certification if not).
Ironically most of those games use DirectX with a translation layer.
No, why, when there is a working alternative available. Why should they waste money and resources on this if they could just make the game better overall instead, or maybe just pour the money saved into wine/proton somehow, which benefits not just their game but every Windows game.
> We face the same issue on Windows, too. Low quality ports from console to Windows (e.g. The last of us). So it is more about appropriate ports.
Well yes and no. If the windows port sucks too, just use an emulator a few years down the line.
And funnily enough, wine is even more future proof for Windows games than Windows itself. You can find a lot of stories about old Windows games from the XP era and earlier that won't run on 10, but work fine with wine on current Linux.
Regarding quake 3, I can also still run the windows version of the original release on Linux, and in that case don't even need to care about OSS or anything because wine just does that for me. And sure, I'd rather play a popular modern fork of the original game since as you say, the source code is available, but my point is entirely about closed source games where we'll never see the code. If I'm dealing with a black box binary, I don't see what I'd gain even with a well made Linux port over the game running just as well under proton.
Metal was version 1.0 and used in production a year before there was even a proposal for Vulkan.
Why would Apple go all in on Vulkan?
Why they should? Because it it would improve portability for their platform and Linux. And it weakens Microsoft. What we've instead, three competing APIs. Apple labled OpenGL deprecated and many rely now upon MoltenVK. At the same time Apple switched to ARM. Both in combination are problematic because AAA-Titles are closed-source. For the same reasons Apple supports OpenGL they also support Vulkan.
I wonder about the reasons of Valve to the decision to support Linux (Vulkan) and Windows (Direct3D) with native ports of CS2. But not MacOS. I'm happy because Linux is supported but the Mac people are obviously not so happy. AFAIK Source2 was already used in the past on MacOS.
PS: Thanks to Valve for the native port of CS2 on Linux :)
Because of the Steam Deck
You mean it was ready when it was ready, and Apple released it. When Apple released it, Vulkun was not even an idea.
> Why they should? Because it it would improve portability for their platform and Linux. And it weakens Microsoft.
Why would Apple care about that?
The rest of that paragraph reads like a loosely connected stream of consciousness with no reasons for Apple to drop Metal and go all in on Vulkan.
To remind you, again, the timeline:
- Metal has been available since June 2, 2014 on iOS devices powered by Apple A7 or later
- The Khronos Group began a project to create a next generation graphics API in July 2014
- Vulkan was formally named and announced at Game Developers Conference 2015
- Metal has been available since June 8, 2015 on Macs (2012 models or later) running OS X El Capitan.
- On December 18, 2015, the Khronos Group announced that the 1.0 version of the Vulkan specification was nearly complete
- The full Vulkan specification and the open-source Vulkan SDK were released on February 16, 2016
By the time Vulkan was just released, Apple had already been running Metal on its devices for two years. By the time Apple released Metal 2 in 2017 Vulkan was 1 year old
> For the same reasons Apple supports OpenGL they also support Vulkan.
Apple doesn't support Vulkan.
Each cross-platform game has such an abstraction layer, usually it's just inhouse code or provided by a game engine vendor. Moving that part out of the game and into a shared set of 'system libraries', maintained by specialists who actually know how the Linux graphics system works inside out is actually a very good thing.
That this abstraction layer implements a subset of the Win32 APIs really isn't all that important from a technical perspective (it is however very important from a business perspective).
I never heard a Linux users complain about game developers writing their games against SDL for instance, yet the basic idea isn't all that different from Proton.
Apple is the only party to blame here.
I'm fine with passing blame to all those parties for not getting it together and making Vulkan a first-class citizen. But reality is reality, they're not - Vulkan is a second-class citizen for all those HW manufacturers - ignoring that doesn't help.
Nintendo -> supports Vulkan natively
Sony -> supports Vulkan (as per latest patch notes of BG3: https://baldursgate3.game/news/hotfix-9-now-live_95 )
Xbox -> Doesn't support Vulkan
Microsoft Windows -> Supports Vulkan natively first class.
AMD/Nvidia/Intel -> Supports Vulkan as First class APIs.
Android -> supports First Class Vulkan APIs natively.
Linux -> supports First Class Vulkan APIs natively.
Nintendo and Sony prefer their own APIs, NVN and LibGNM, and AIUI Vulkan is a second-class API on those platforms which does not offer as much power, it is widely understood studios use NVN and LibGNM to get access to the real hardware on those platforms.
Windows/AMD/NVidia/Intel -> HW manufacturers tend to prototype and release new features with D3D first and then 'backport' them to Vulkan after a while. DirectX 12 for example had mesh shaders for over 2 years before Vulkan got a vendor neutral extension for them[0]
Android and Linux are the only platform where Vulkan is a first-class citizen.
You could maybe argue Nvidia treats Vulkan as a first-class citizen because they tend to have vendor-specific Vulkan extensions for the latest features available before anyone else. But otherwise, no, Vulkan is not a first-class API anywhere except Linux and Android.
Graphics API wars are alive and well.
Making them in the end hardly better than multiple backends, when doing serious stuff across multiple GPUs and OSes.
Don't get me wrong. I agree that it's less worrying to know beforehand that all the features will be available in the target environment with features made mandatory rather than extensions. But, it's not like the case of Apple/Sony/Xbox which has software tailored for the device.
Vulkan devices range from Virtual devices(Moltenvk) to Android(Low powered devices) to Desktops(Linux, Windows) to Workstations(Linux). Having ray tracing mandatory in low powered devices like low budget android phones doesn't make any sense, that's why it's made as extension.
But, you can be sure that any modern desktop with modern GPU by any vendor atleast adheres to Vulkan standard and has specified extensions available. That can't be said about experimental extensions though (Like Vulkan Video).
> Making them in the end hardly better than multiple backends, when doing serious stuff across multiple GPUs and OSes.
This "multiple backend" solution is not ideal too. Firstly, it was necessary because not all Vendors supported single Graphics API standard. Secondly, it isn't powerful as main API it gets translated to(DX,Vk,Mt). Thirdly, I don't see how it helps when target environment doesn't have an extension available.
Maybe "Multiple Backend" solutions might make few things easier like removing Verbosity and maybe they are good for Small applications but I don't think they are worthy replacements to Main APIs
How many cross platform applications have you shipped with Khronos APIs?
I did my graduation thesis in 3D particle visualisation and marching cubes implementation, based on a framework ported from NeXT/Objective-C in Windows/C++, using OpenGL.
Contributed to SDL, Ogre3D and jMonkeyEngine.
Also contributed to some BabylonJS stuff in WebGPU.
What are you 3D credentials?
What is the best alternative to Vulkan extensions in your opinion? Remember that Vulkan supports vast number of devices. I think that making featureset mandatory for all devices is not sensible approach here.
> Contributed to SDL, Ogre3D and jMonkeyEngine.
> What are you 3D credentials?
Appealing to Authority[1] is a fallacy/bias and a quick way to lose a debate.
Instead of saying you have all these creds and therefore your opinion matters more - explain why what you are arguing against is bad. If you are an actual expert, that will be shown through well formed arguments all on it's own.
Not all experts share your opinion, clearly, which makes this angle unhelpful.
Life is too short to bother.
Erm, no? Vulkan is completely implemented in GPU vendor driver DLLs, Microsoft has no part in this. The only first class 3D APIs on Windows are the D3D APIs.
In reality, Vulkan doesn't matter much except on Android and Linux.
Thus said, even though Microsoft doesn't support Vulkan officially, you can tell that Vulkan has first class support on Microsoft Windows given that all GPU drivers have good first class Vulkan support and all Vulkan Applications run just fine on Windows.
> In reality, Vulkan doesn't matter much except on Android and Linux.
No, it matters. Vulkan is the first modern cross platform Graphics API which can run across Linux,Windows,Android,MacOS,Switch to name a few. No similar API does exist currently which offers high performance along with being portable.
Why would Apple support something that appeared two years later than Metal?
And as others pointed out already, Android and Linux are the only platforms where Vulkan is first class.
Because Vulkan is Open Standard? It's similar to how EV car manufacturers other than Tesla are now embracing NACS even though it was born at Tesla. It's also similar to how Apple adopted USB C given Lightning was already a standard before USB C.
You can't blame community or Khoronos either. Khoronos and developers did their best with best effort Vulkan-> Metal translator with Moltenvk and you can now not worry that your Vulkan apps won't run on MacOS(exceptions are heavy games and there are still many Vulkan extensions not implemented thanks to Metal).
And note that it's not you or I who is losing because Apple didn't support Vulkan. It's Apple themselves whose Mac devices have started losing share in Gaming Market. Day by day, Developers are ignoring MacOS as target. If this isn't a warning call to Apple, i don't know what is.
Why didn't Microsoft immediately embrace it? Or Sony? Or...
> You can't blame community or Khoronos either. Khoronos and developers did their best with best effort Vulkan-> Metal translator
Yes. Yes, we can and should blame Khronos. For their mismanagement of OpenGL. For the fact that they woke up and decided they needed a new API a full year after both DirectX and Metal, and managed to release first version a full two years after those two.
> And note that it's not you or I who is losing because Apple didn't support Vulkan. It's Apple themselves whose Mac devices have started losing share in Gaming Market.
Ah yes. They are losing because of not supporting Vulkan.
Let's see:
- iPhone is Metal (before you say that more people are gaming on Android, iOS's mobile gaming revenue dwarfs Android)
- Xbox is DirectX
- Playstation is GNM and GNMX
Apple is losing, should abandon Metal and go all in on Vulkan because.
Because they are already established platforms in Gaming Industry? Windows has much of Gaming market share. Xbox and PlayStation are popular Consoles. They probably don't loose anything by supporting Vulkan although supporting Vulkan would be awesome on their part.
> Ah yes. They are losing because of not supporting Vulkan.Xbox is DirectX. Playstation is GNM and GNMX
I was only talking about MacOS.
> before you say that more people are gaming on Android, iOS's mobile gaming revenue dwarfs Android
I didn't talk about iPhone either. I was only talking about MacOS. despite being prominent OS, game title developers often ignore MacOS. Why? Because of Graphics API. No one bothers to target Metal for Games and this is exactly what i am talking about. If MacOS allows Vulkan or DX(ik that it's not possible), i think there could be more influx of games.
If we are talking about Gaming on iPhone, you must know that gaming landscape on mobile phones is vastly different than that of mainstream gaming experience on Consoles/PC. Mobile gaming landscape is mostly filled with non graphics intensive, micro transactions filled, Ad-filled(many times freewares) games. iPhone gets targeted because it has prominent share in Mobile Market but even then, not everything gets ported to it. Not to mention, Android gaming landscape doesn't suck than iphone. Prominent Mobile games which are on iPhone are on Android too and on Android they use Vulkan which proves that Vulkan is not a bad choice.
> Xbox is DirectX. Playstation is GNM and GNMX
Vulkan probably runs on PlayStation (see latest Baldur's Gate 3 patch notes; grep for PS5 Vulkan) but I am not so sure. Like i said earlier, these platforms are already household names when it comes to gaming.
My point was not to tell you that Vulkan is the "supreme" Graphics APIs out there. But my point was to tell you that Vulkan is the only one of "supreme" APIs which is most cross platform, modern, supported by gaming and graphics forerunners(valve, rockstar, nintendo) and there are no viable alternative to Vulkan right now.
> Yes, we can and should blame Khronos. For their mismanagement of OpenGL
What should they have done? At the point, we needed modern Graphics API. Mantle by AMD was forerunner and AMD was willing to co-operate. Nvidia too joined that bandwagon. Thus, Vulkan was born out of Mantle.
Should they have copied Metal? Since it was closed API from Apple, it wasn't possible. Should they have copied Microsoft's DX12? If Microsoft actually loved Open Source and Standards and gifted Khronos DX12, it would have been possible but they didn't do it. I think Khronos did sensible thing at that time.
- you're willingly ignoring other platforms that Apple has and that are more important to Apple than Mac
- you're willingly ignoring the fact that Apple never care d about gaming on Macs
- you're pretending that gaming success is predicated on supporting Vulkan even though huge gaming platforms never supported Vulkan, and are successful
But sure. Apple absolutely must support Vulkan on Macs because they are losing out or something.
> But my point was to tell you that Vulkan is the only one of "supreme" APIs which is most cross platform, modern, supported by gaming and graphics forerunners(valve, rockstar, nintendo)
1. As if Apple (or anyone really, see Microsoft and Sony) cared about it being crossplatform and modern
2. There are thousands of game developers, and a very small number of those "forerunners" care about Vulkan.
> What should [Khronos] have done?
Not sit on their asses until it was two late. Both DirectX 12 and Metal were released in 2014. It means that Apple and Microsoft had been working on these new APIs since at least 2012.
Khronos woke up and decided to create a new API in 2015.
It's amazing you're blaming Apple and Microsoft for not doing something for Khronos out of the goodness of their hearts when the "amazing open innovative forerunners" like NVidia, AMD, Valve, Epic etc. are their members and literally did nothing until, well, it was too late.
I had a renderer in Metal in a (long) afternoon. Vulkan on the other hand took a few weeks to get something presentable.
But then, Unreal Engine is left-handed, so maybe some people prefer that.
This was only relevant in the past when 3D APIs implemented fixed function vertex processing. Today this is just a contract between your CPU-side code and your shader code.
There are other other subtle coordinate system differences though, like the framebuffer and/or texture origin being in the top-left vs bottom-left, or clip space z ranging from -1.0 to +1.0 or 0.0 to +1.0.
On my side, I am waiting valve to trash their 32bits legacy code and get a clean vulkan->CPU fallbacked steam client (discovered you cannot libdl libGL because of that pesky ELF static_tls flag). I'll get some old games running with XWayland(maybe, and I would need a drm/vulkan|cpu implementation), and my own wayland drm/vulkan(or CPU) compositor.
The main issue is the glsl compiler: we are missing a lean, namely plain and simple C without the latest ISO tantrums implementation.
Dunno if lava pipe is clean C and not pulling some horrible c++ stuff like llvm.
Currently Vulkan and DX12 seem to be in a state of turmoil. The main assumption with the two low-level APIs are that you need to have a fully specified static list of configuration options to send to the GPU when you send render commands (I'm essentially talking about the Pipeline State Object) - which will aid in optimization since there's not any dynamic state for the GPU driver to wrangle with. However, many devs in the game industry has tried making performant renderers with this model and not many have succeeded, because if you see actual GPU usage patterns in game engines they do need some of the flexibility previously had in DX11 / OpenGL. Without this dynamism, as a rendering engineer you essentially need to do one of the two:
- Pre-build all combinations of PSOs to implement your shader effects (if you have three different options for your rendering with A, B, C possible states each then you need to prebuild all A * B * C combinations of PSOs)... which will become ridiculous later on.
- Create an automatic caching system that caches PSOs, so that the initial pipeline compilation will introduce some lag but later cached usage of the same PSOs will be fast. Now you have a much worse version of what DX11 / OpenGL was already doing behind the scenes... (unless you git gud and surpass the abilities of NVIDIA driver developers)
With this in mind and also the various difficulties with managing the complexity of the new APIs (such as synchronization)... the reality is that a DX11 backend will probably be more performant than a naively written DX12 / Vulkan engine, since it's really just hard to beat NVIDIA's ridiculously optimized DX11 drivers that they have spent ridiculous amounts of time and money on. Unless you have a world-class team like Unreal or the ID tech folks... it seems like a gargantuan task to do. (Even Unreal Engine 5 had problems with heavy stuttering that are now fixed... and I suspect the issues were with how DX12 / Vulkan works)
Nowadays the problem seems to be widely known in the industry, up to the point that both DX12 and Vulkan have introduced experimental extensions which provide alternatives to the PSO model:
- The initial attempt is Vulkan's VK_EXT_shader_object extension (basically "Vulkan without Pipelines": https://www.khronos.org/blog/you-can-use-vulkan-without-pipe...) - which overhauls the API by introducing shader objects that you can dynamically link at runtime. Basically somewhere in the middle of DX11/OpenGL and DX12: give back some dynamism to the API, but not up to the point where the driver struggles to maintain performance because of it.
- Other attempts seem to resemble more closely towards Render Graphs, which was a strategy that various game engines have already implemented on top of DX12 / Vulkan / console APIs. (See https://logins.github.io/graphics/2021/05/31/RenderGraphs.ht... for a introduction). For example, DX12's Work Graph API as preview (https://devblogs.microsoft.com/directx/d3d12-work-graphs-pre...), or Vulkan's VK_AMDX_shader_enqueue extension (https://gpuopen.com/gpu-work-graphs-in-vulkan/)
But nonetheless, I think I should just wait touching these APIs until things have sorted out between GPU manufacturers and engine developers. (If I would start making a game engine from scratch for my indie game I would probably just use DX11.)
While Vulkan has been slowly replacing OpenGL, it's also more complex than OpenGL is. This means that OpenGL is still great for many simple use-cases, as you won't be overwhelmed by the complexity that Vulkan can bring along with it.
Will Vulkan replace everything? Seems unlikely considering Microsoft is not dropping DirectX anytime soon, and apple pretty much despise The khronos group, while the web seems to want to go the WebGPU route now.
And openGL seems to simply not die.
So in a way it doesn't really matter what these low level APIs are like.
It's was an API they and Firefox presented as a proposal for new graphics API. And it was Google who agreed to follow suit (they had their own proposal)
And as other have stated the absolutely CRUCIAL question in picking your API, is going to be :
what do you want to do ?
They mostly differ in details like 'programmer ergonomics', design philosophy, and of course platform-availability.
WebGPU is basically the cross section of those three native APIs.
IMHO learning OpenGL today just fills your head with outdated concepts, the API is much more confusing than it should be, and error reporting is non-existent.
At least more modern APIs tell you exactly what you did wrong in their validation layers.
Plus, tutorials and in depth guides are much much more common on OpenGL, but that's probably a chicken/egg type of situation.
As other have said, WebGPU is probably the best cross-platform option right now.
(also IME the tricky thing with GL information on the web is that there's a lot of really outdated and sometimes conflicting information around - e.g. worst case is you end up with code that mixes old and new GL concepts without realizing what's what)
Is there anyone who doesn't despise the Khronos Group?
Meanwhile Vulkan is supported by Android, Nintendo Switch, Linux.
Windows, Apple Platforms, Xbox, PlayStation (aka where money for developers is) couldn't care less about Vulkan.
As for whether Vulkan is going to replace OpenGL... yes and no. Over the next 10 or so years we may see OpenGL drivers for GPUs get replaced with Vulkan drivers plus an OpenGL layer based on Vulkan. But you will still be able to develop to OpenGL.
Ad for what you should start with... what do you plan on doing? If you're looking to write a game, use a widely available engine like Unreal or Godot that abstracts the graphics library details. If you're looking to write your own engine... seriously, seriously reconsider.
If you're still interested in programming immediate-mode graphics below the engine layer, start with DirectX 11 and 12. They're much more tractable than OpenGL and Vulkan and have unbeatable tooling support from Microsoft. Even if you're targeting Linux, you will have much more binary compatibility across distros by shipping it as a Windows program and running it under Wine.
You are not going to want work in it developing your own game... unless you really want to, it shouldn't be necessary.
Kind of like that description. I've been doing GL since before it was OpenGL.
In my Common Lisp 3D system [1], I've been happily using very simple immediate mode OpenGL calls, taking advantage of CAD-like features such as drawing wireframes of various thickness over shaded polygons. OpenGL provides specific Z-buffer API calls to facilitate such things.
Is there a simple way of doing such CAD-centric things in Vulkan?
WebGPU is currently probably the best balance between:
- easy to learn
- easy to tinker with (in web browsers at least)
- modern concepts (close enough to Metal, Vulkan and D3D12 that what you learned carries over)
- platform-agnostic
If you are on Windows, D3D11 is also a good native option, as is Metal on macOS.
In regards to the boilerplate: Yes, for the first draw you require a lot, but after that, it quickly becomes almost neglible.
E.g. without Metal as example of what a modern user-friendly 3D API can look like, WebGPU would probably look very different, and not in a good way.
My personal hope is that the concept of a "3D API" will eventually disappear into compilers like Clang and GCC and their standard libs.
E.g. WebGPU has a pretty big API surface just for ensuring that the CPU-provided data is compatible with what the GPU expects, and any mismatches manifest as runtime errors, not compile-time errors.
Most of this API surface would simply disappear if the same compiler can see both the CPU and GPU side code, integrated into the same compilation process.
A massive shame that it's more or less bolted to the Sodom and Gomorrah of modern software development (Browsers and JS). Atleast in mindshare for sure.
There appears to be a non browser implementation of WebGPU now looking into it, but I can't find anyone using it or attempting to use it in production
Despite my usual rants on how they are outdated in regards to native APIs, there is a great plus for them, WebGL and WebGPU are the only 3D APIs designed from scratch for managed languages.
It goes beyond it, because CPU-GPU interfaces were also designed with JavaScript GC in mind.
Hence why on Android they are finally thinking about using WebPGU to expose Vulkan to app developers, as most keep using GL ES instead of downgrading their developer experience dealing with NDK, C and C++.
https://github.com/webgpu-native/webgpu-headers/blob/main/we...
...and this standardized API would also enable other independent native implementations (and shader compilation aside, it's actually not in the realm of the impossible to write a WebGPU implementation from scratch with a small team or even alone).
There's even thought put into the API being extensible via 'struct chaining', this is how the native implementations also accept SPIRV shader bytecode instead of just WGSL shader source code.
If you're building an application, you'd better make sure you are using _the implementation's version_ of the webgpu.h header today.
Hopefully one day it does become fully standard.
WebGPU (wgpu) is another abstraction on top of all of them that I feel is the modern bgfx, that is, a modern abstraction of those buffers and queues that work across DX12, Metal, and Vulkan. If you aren’t in the graphics space, I would skip learning vulkan and learn webgpu wgpu-native.
Vulkan was modeled after Mantle, AMD's own API that was basically what was available on consoles but less specific (ie. supporting more than a few custom GPUs). Direct3D 12 was modeled after consoles and Mantle, just like Vulkan. Same for Metal, that was made available in 2014, same year D3D12 was publicly announced.
https://en.wikipedia.org/wiki/Mantle_(API) https://twitter.com/repi/status/446718535616585730
Yes but they all have a similar design around treating the GPU as a buffer store. You’re right about Mantle but that was the inspiration of many. They each took some concepts.
I’m not an expert on driving decisions behind them. Just from my own experience. Vulkan is much more difficult and verbose than the others. This is one of the main hurtles to Vulkan.
Vulkan is a quagmire of very low-level concepts, the danger of getting stuck in them and give up without learning anything is just too high.
At the same time making something with OpenGL that is more interesting than a simple rotating cube is not that difficult and you will get a lot of mid-level understanding - how rendering pipeline implemented and organized, what kind of task it is. "Porting" this knowledge to Vk is straightforward.
I'm not sure Vulkan can ever replace OpenGL since it's much more complex and low level.
I think a better option for a beginner would be to use a rendering library like bgfx, sokol_gfx or even facebook's igl, since you can learn the basic concepts of rendering triangles and not bother too much with all the minute rendering details.
One can get an idea of the complexity build-up of the current graphics APIs by measuring how much code it takes make a triangle show up on screen.
Compared to the OpenGL fixed function days, the required Vulkan setup code is massive.
Start learning modern GL: if the Hello Triangle doesn't use 2 shaders you're not learning modern GL. Hello Triangle for GL requires about 80 lines of code, while Hello Triangle for Vulkan requires about 1000 lines of code.
I highly recommend learnopengl.com and vulkan-tutorial.com.
If you're going to write a simple game, it's probably better to stick with GL. If you're going to write a real complex engine, Vulkan is the only acceptable path these days. Gl deviates way too much from what the GPU does, so there's a lot of CPU overhead and synchronization choke-points. Vulkan is way similar to an actual GPU and gives you more power to uses the resources in the appropriate way.
Its purpose is to give as much control as possible to 3D engine developers. If you don't want to use an engine and don't want to make an engine, OpenGL is still the answer, and I don't think it will disappear anytime soon.
If you want still want to learn Vulkan, at least use something simpler (like OpenGL) to get familiar with the basics, it is simply too much for a beginner.
```css
.navbar-item > .navbar-item {
padding: 0;
} footer.footer {
display: none;
}
This css seems shared across multiple sites, so I'd be afraid of breaking one of them if not introducing yet another class, though I am not sure where the HTML for the inclusion of this logo is generated from.
Edit: seems likes it comes from there: https://github.com/KhronosGroup/antora-ui-khronos/blob/e6d03...
https://github.com/glfw/glfw/blob/master/tests/triangle-vulk...
(yes it's over 2kloc for a triangle - that's Vulkan for you ;) but at least it's all in one file readable from top to bottom instead of being spread over a dozen obscure "helper classes")
If you can compile that code, then you necessarily have the compiler at hand. You can't make a simple single code file example though. The build system has to get involved somehow.
FWIW, I think this is a good thing. Any non-trivial 3D project is going to involve some kind of asset baking sooner or later, which makes the barrier of entry to that negligible. At the same time, driver-driven compilation is just too convenient and sticky. That's a bad combination.
Vulkan doesn't come with any tools to generate that bytecode though. Foreign shader language (like HLSL, GLSL, etc) to SPIR-V compilers exist, and various graphics toolchains can generate SPIR-V. https://github.com/KhronosGroup/SPIRV-Tools does have tools to validate and optimize bytecode.
edit: i lied apparently - the SPIRV-Tools does have an assembler that translates text such as the "Corresponding SPIR-V" at https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.htm... to bytecode. However, that's not something you'd want to write manually, especially if you're used to something like GLSL.
My understanding is that VK_EXT_shader_object should make such examples simpler? https://www.khronos.org/blog/you-can-use-vulkan-without-pipe...
.components =
{
.r = VK_COMPONENT_SWIZZLE_R,
.g = VK_COMPONENT_SWIZZLE_G,
.b = VK_COMPONENT_SWIZZLE_B,
.a = VK_COMPONENT_SWIZZLE_A,
},Most things in Vulkan have reasonable defaults, fortunately. Still, it's best to code with the spec open on another monitor.
Try reading the above implementation. It’s a Hello, Triangle with SDL. Should compile out of the box on Windows.
I know the old school way is very slow and limited but it's a lot more fun and easy to use then dealing with thousands of lines for a single triangle and plus by using the old school way you get to move onto other stuff instead of being stuck in the infinitely deep rabit hole of modern rendering.