Nice, much better than the old website which was basically unusable.
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.
While better websites are nice, what people need is lots better sample code.
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.
very cool! I've been using pyQtGraph for real-time data coming out of microcontrollers. learning to use it was an uphill struggle, and I can't imagine how difficult it must have been to make datoviz
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
The upcoming version of Datoviz features an asynchronous low-level rendering protocol that works nicely with real-time data streaming. It allows you to send data to the GPU in real-time from any thread.
I don’t know what the old site was like so maybe this is actually an improvement, but I find this site really difficult to use and possibly even broken.
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?
As someone who's kinda hovered around graphics land but never really stepped foot into it, it's pretty difficult to determine what Vulkan represents. Is it going to replace OpenGL? If I'm going to start learning graphics for the first time, would it still be useful to start with OpenGL or should I just dive into Vulkan?
Vulkan, Metal, and DirectX 12 are lower-level graphics APIs that provide abstractions better suited towards the GPUs of today (big, big buffers of data, processed by shaders). These new APIs came about because OpenGL and DirectX have grown into handling too many things are are now themselves the source of many bottlenecks for pushing data to your GPU.
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.
Good answer. I would add that, despite all of them being low-level, Metal is quite easier than the other two, and DirectX 12 is also easier than Vulkan, despite having very similar concepts and ideas. This is in part due to API decisions and differences in verbosity, in part due to the "easier" ones having less flexibility. If your ultimate goal is to master Vulkan, starting with another can help. Also: OpenGL and DirectX are easier than those 3.
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.
The big advantage of not using OpenGL is that D3D11, D3D12 and Metal all have excellent validation layers which tell you exactly what's wrong when you mess something up. In OpenGL you're pretty much left alone, staring at that black screen.
Xcode and Visual Studio also have builtin graphics debuggers for Metal and D3D11 (not sure if the VS debugger also supports D3D12 though).
Because you forget to call glGetError and do the error check on your previous call. In a world where we are driven by exceptions, not excepting and requiring you to check is actually a good thing, you wouldn’t want a shader param exception from panicking your game in the middle of a gun fight.
That's a fantastic point. As much as I managed to do stuff in OpenGL for decades, it was definitely left behind DX and Metal in terms of API ergonomics.
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.
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.
You probably should blame the people which made the 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.
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).
> You probably should blame the people which made the game?
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.
You know that Games/Applications can still be developed with Vulkan API targetting win32 and they can be run on Proton/wine in Linux which runs it without the DXVK (dx11->vk)/VKD3D (dx12->vk) translation layer, right? Baldur's Gate 3, Red Dead Redemption 2 are some of popular games which use Vulkan exclusively running on Proton.
It really doesn't make much difference whether the platform abstraction layer code is part of the game, or part of the runtime environment.
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.
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 :)
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.
OpenGL straight up sucks to work with. DirectX 11 is a much nicer API that doesn't require you to write your own allocator for views in the GPU like the lower level APIs. Linux isn't a major platform I personally care about so I use DirectX 11
Mac wannabe-gamers need to comprehend Apple doesn't care about you and has gone out of their way to make gaming on OSX difficult to support. It's not a surprise very few games support OSX...
Apple.. and Nintendo.. and Sony.. Xbox.. And I guess Microsoft/AMD/Nvidia if you want the latest feature set on Windows the same year it comes out..
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.
Apple -> Moltenvk (Have to blame Apple for not supporting Vulkan). Moltenvk is used by games such as Dota2. If moltenvk doesn't work fine for your game, you must not target Apple Mac devices anyway.(valve dropped mac support for cs2). For non game cases, Moltenvk works just fine.
Apple -> MoltenVK is an emulation layer and doesn't give you as much control as using Metal directly.
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.
On top of that, OpenGL/Vulkan advocates tend to ignore that extension spaghetti makes them also completely unportable when extensions are only available for specific vendors, and if they are lucky with multiple vendors offering similar extensions, there is an exponential set of code paths only to deal with all of them.
Making them in the end hardly better than multiple backends, when doing serious stuff across multiple GPUs and OSes.
You know that Vulkan targets vast amount of Hardwares which makes Vulkan Extensions a lucrative deal rather than thing you despise, right?
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
A wall of text to argue in favour of extension spaghetti.
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.
> I did my graduation thesis in 3D particle visualisation
> 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.
Nah, as my experience in 30 years of industry shows, those that come up with appeal to authority argument, aren't really interested in listening anyway.
If you are that knowledgeable person in this domain, try to refute/discuss my content instead of asking my 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.
> Microsoft Windows -> Supports Vulkan natively first class.
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.
I agree that Microsoft has no part in this. But, any computers which run Microsoft Windows has GPUs made by these Manufacturers: Nvidia,AMD,Intel and Qualcomm and all these Manufacturers have good Vulkan Drivers in Windows.
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?
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.
> Why didn't Microsoft immediately embrace it? Or Sony? Or...
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.
That's fine, but my point is that learning Vulkan while learning graphics at the same time is way harder than learning a much simpler APIs + graphics, then moving that knowledge to Vulkan.
I had a renderer in Metal in a (long) afternoon. Vulkan on the other hand took a few weeks to get something presentable.
Note that DirectX is left-handed, while OpenGL, Metal, and Vulkan are all right-handed. Other things that use right-handed coordinate system include Blender, Godot, and my physics textbook, so left-handed coordinate systems is something of a minor annoyance for me.
But then, Unreal Engine is left-handed, so maybe some people prefer that.
This really doesn’t matter. It’s only something you need to care about in your rendering backend. The rest of your engine can use whatever coordinate system you want, and you do the conversion as part of your transforms.
> Note that DirectX is left-handed, while OpenGL, Metal, and Vulkan are all right-handed.
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.
> WebGPU or WebGL are also more straightforward and a good starting point.
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.
> 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
> 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.
The latest hints from Vulkan and D3D12 developments (VK_EXT_Shader_object[0], D3D12 Work Graphs[1]) suggest there might be an industry move away from pipelines and towards alternative solutions.
Good info, interesting. It does add a layer of complexity that takes a bit more to handle. The point of moving away from stateful/naming was to prevent global state and bugs but you can also run into those in other ways as it is somewhat like going from keyed data to offsets/positions binary data. Rebuilding pipelines also seems heavy.
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.
D3D10/11 is the sweet spot IMHO. It splits render pipeline state into a small number of immutable state group objects instead of granular render state toggles (like OpenGL or that new Vulkan extension), or an all-in-one rigid pipeline state object (like WebGPU or Vulkan).
Those D3D11 state objects are roughly: rasterizer-state, blend-state, depth-stencil-state, (vertex-)input-layout, and one shader object per shader stage.
Vulkan and DirectX12 are really lower level than OpenGL. The API of Metal is high level and more beginner friendly. I really hope to have a Metal like API on top of Vulkan because currently vulkan can't replace OpenGL for beginner and simple visualisation but Metal can.
I was one of the N people who decided to delve into Vulkan because of curiosity for low-level optimization... but hearing some news and rumors around the gamedev scene I wonder if I should have spent time elsewhere (like, studying CUDA instead). Note that I'm writing this as a hobbyist so if there are any professional folks feel free to comment on anything problematic...
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.
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.)
Thanks, yeah I'm tempted to just dive into the lowest level. My linear algebra is almost non-existent, so I feel like I should review my math fundamentals first. But I'm not sure how relevant it is to understanding the rendering pipeline itself, or if the math comes in at the applied layer.
dota2 and cs2 do not even have an opengl backend anymore.
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.
You meant zink, I think. I am looking for lean (SDK included), namely plain and simple C without the latest ISO tantrums on the C syntax implementation.
The main issue is the glsl compiler: we are missing a lean, namely plain and simple C without the latest ISO tantrums implementation.
No, I meant Lavapipe, "Mesa's generic CPU-based software Vulkan implementation". Zink is the OpenGL-on-Vulkan implementation by Mike Blumenkrantz & co.
If you've not touched 3d graphics before start with OpenGL with a view to moving on to a modern API soon after.
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.
Both APIs are not all that great, Vulkan has a steep learning curve and requires tons of boilerplate code to even get a triangle on screen, and OpenGL is 30 years of sediment layers all pressed into a single 3D API.
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.
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
...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.
It's worth noting that both Dawn and wgpu (the two primary WebGPU implementations currently) disagree on key parts of that API - particularly around instance creation, and so they are not ABI compatible today.
If you're building an application, you'd better make sure you are using _the implementation's version_ of the webgpu.h header today.
Actually there is something great related to that.
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.
<webgpu/webgpu.h> is actually a very decent C API (it does have explicit lifetime control via 'reference' and 'release' calls like COM though, but that's okay-ish - same rules as D3D basically).
So far I have only bothered with the actual browser version in Chrome.
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++.
dawn is the WebGPU backend in chromium, while wgpu is the WebGPU backend for firefox written in Rust. wgpu is seeing a lot of use in non-browser uses; there are some examples on their website.
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.
I would start with WebGPU. Gives you hands-on cross platform knowledge and good foundations. Can't hurt to also look into WebGL, as that is more mature and deployed everywhere.
Seconding the first recommendation. WebGPU is currently the sweet spot between classic and modern approaches.
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.
Note that wgpu, while mostly mirroring WebGPU (and being used to implement WebGPU in Firefox), doesn't have an identical API; WebGPU being the lowest common denominator* of the underlying low-level APIs, while wgpu offering some minor platform-dependent features on top of that. For exaple wgpu's PrimitiveState has an additional polygon_mode field (that can be used to easily draw wireframes) that doesn't have a WebGPU equivalent.
(* 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.)
In some cases wgpu has extensions that fundamentally change usage (e.g. bindless) which aren't supported in browsers at all, right? i.e. wgpu natively and WebGPU in a browser are really just two different topics entirely
https://webgpufundamentals.org/ is the best learning material I've found. I've been learning Rust's WGPU and I appreciate that the tutorial uses a different language and a slightly different API[0], it keeps me thinking instead of just copy/pasting.
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 also used webgpufundamentals.org to learn webgpu native. Only for me I was porting the examples to C. (I also used WGPU as the backend as I find it easier to debug than Dawn.)
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.
In practice a lot of Vulkan documents assume you already know GL! So for learning purposes, modern GL is probably best.
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.
Vulkan was designed to tackle several issues OpenGL had. For example, OpenGL does not do multithreading, while Vulkan is able to, and OpenGL has a single global state, while with Vulkan you're able to create multiple different command buffers to hold the state in. In general Vulkan is also a lot faster at rendering, as it's closer to modern GPUs in design.
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.
OpenGL is definitely easier to learn and use than Vulkan, but it's reached the end of life so it won't be updated anymore.
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.
> I'm going to start learning graphics for the first time
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.
Don't start with Vulkan, it is extremely complex, and even seasoned graphics programmers have a hard time with it.
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.
Start with WebGPU, DirectX11 or OpenGL. Do learnopengl, try to write a gITF model viewer in it. Then rewrite the gITF renderer in DirectX12, Vulkan or Metal.
Just want to add: As far as I know, the "V" in Vulkan is actually supposed to represent 5. As in, the next thing after OpenGL 4, which will be the last version of OpenGL. That, and the volcanic theme to fit with Mantle, the AMD experiment that sort of... inspired Vulkan? Got merged with it? Not sure on the organizational history there.
OpenGL is recommended to get started and learn the base concept then if you survive that you can try Vulkan.
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.
I'd heard about this, which I think added to my confusion. My general impression is that Vulkan, Metal, and WebGPU are all separate attempts at modernizing graphics, so they're all kind of related in some sense but they're also distinct and incompatible with each other. So graphics in general are moving away from the legacy OpenGL model (good), but it's also fragmenting (bad). Fair take or no?
WebGPU is different because it's an abstraction of Vulkan, Metal or DX. Yes, the fragmenting is bad and annoying, WebGPU is the only graphics API that Apple agreed on and that would be truly natively cross-platform, but it's still new, lacking some features, and evolving.
> WebGPU is the only graphics API that Apple agreed on
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)
OpenGL is not dying only in the sense that vendors and Linux want to keep support around for legacy reasons and applications which don't need to be all that carefully optimized. It is pretty much dead otherwise, as it hasn't received any meaningful updates and extensions in a while exposing the myriad of features that newer GPUs have made available in Vulkan.
> OpenGL is recommended to get started and learn the base concept
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.
I don't think OpenGL and vulkan are interchangeable in this case. I wouldn't really recommend a beginner to start with vulkan. Yes, OpenGL might have some "outdated" concepts compared to vulkan but I don't think throwing someone directly to vulkan is more productive!
Plus, tutorials and in depth guides are much much more common on OpenGL, but that's probably a chicken/egg type of situation.
Yeah both options are bad for beginners, at least for cross-platform 3D APIs (e.g. D3D11 and Metal are both nicely balanced and well-designed 3D APIs, but restricted to Windows or macOS).
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)
Vulkan is positioned to replace OpenGL, but possibly OpenCL/CUDA, vaapi/video acceleration libraries, and probably more. So honestly, it's sort of understandable why things get confusing here. It's quite abstract as well as sprawling in scope.
OpenGL has been deprecated on everything but Android, Windows, Linux, and PS4. Vulkan is the new open standard modeled after Metal (macos, ios) and DirectX 12 (windows,xbox). Vulkan, like Metal and DX12, offer direct memory access to GPU resources. Modern OpenGL (buffers and vao’s) is close to what vulkan is but vulkan takes it further. With command queues for multithreaded rendering and everything is a buffer. Indices, vertices, shader uniforms, everything.
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.
OpenGL has never ever been used on PS4, it has always been a custom API. Unless you're talking homebrew stuff.
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.
Yeah for PS4 OpenGL worked but wasn’t their API, they have GNM.
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 represents a low-level way of talking to the GPU more or less on the GPU's terms. As opposed to OpenGL which is a way of talking to the GPU on boomer CAD programmers' terms.
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.
Regarding the last statement, segregation of game and engine is one way of thinking. But many a times, you do not need a full fledged map editor, sculptor etc. You just implement the parts you need for your game.
That still needs to be seriously, seriously reconsidered in favor of basing your game on a major engine. There's just so much tooling and workflow around the big engines. Personnel to help will also be easier to obtain.
"Vulkan represents a low-level way of talking to the GPU more or less on the GPU's terms. As opposed to OpenGL which is a way of talking to the GPU on boomer CAD programmers' terms."
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?
You might add the following CSS to perhaps improve the presentation of your header logo (which seems a little awkward aligned to the bottom of the navbar as I see it):
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.
Can anyone recommend a good self-contained "hello triangle" example with SDL2 + Vulkan? Just yesterday I was trying to start a project, and I tried building the top 4 example repos on github but couldn't get any of them to compile without errors.
This one's been around a long time. I used it when I started with Vulkan back around 2017/18? It uses glfw but I used sdl2 with it when I went through it. You'll just need to read some sdl2 documentation to get the window hooked up.
(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")
Nicely spotted actually, in that specific case leaving it blank will get you the exact same result. That's because the enum has VK_COMPONENT_SWIZZLE_IDENTITY = 0, and setting everything to IDENTITY is defined to result in exactly what you expect. (r = r, g = g, ...). You can read the spec here if you want to: https://registry.khronos.org/vulkan/specs/1.3-extensions/man...
Most things in Vulkan have reasonable defaults, fortunately. Still, it's best to code with the spec open on another monitor.
That's SPIRV shader bytecode. Does Vulkan actually come with an integrated shader compiler these days? Otherwise there's not much one can do for a standalone sample like that.
"integrated" in the sense that the SDK comes with a compiler, but it's not integrated in the same sense as OpenGL where the compiler is part of the driver.
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.
SPIR-V is an intermediate bytecode format. That bytecode is the data that you use in the Vulkan API, and under the hood your graphics drivers compile that bytecode into the device-specific native shader binary that runs on the graphics hardware.
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.
I'm still suprised that no one has made an equivalent of the old immediate mode graphics apis on top of the newer apis.
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.
There's plenty of abstraction libraries available including for example webgpu. Why do you want immediate mode specifically? It's not a very useful balance to strike between just using an actual 2d library vs. learning how shaders work which you're going to need for anything slightly non-trivial
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.
[1] https://cyrille.rossant.net/datoviz/
[2] https://datoviz.org/howto/standalone_vklite/