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