9 ms·

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, process

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.

whstl 3y ago
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.
- alexarnesen 3y ago
  If you are looking to dig into Metal, this site and book might be useful. I have no graphics background and found it accessible. Metal By Example https://metalbyexample.com/ https://metalbyexample.com/
  - pjmlp 3y ago
    A better one with Swift, https://www.amazon.com/Metal-Programming-Guide-Tutorial-Reference/dp/0134668944 https://www.amazon.com/Metal-Programming-Guide-Tutorial-Refe...
- flohofwoe 3y ago
  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).
  - reactordev 3y ago
    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.
    - flohofwoe 3y ago
      glGetError() is useless unfortunately for getting any information about what went wrong, because it only has 8 error codes: https://registry.khronos.org/OpenGL-Refpages/gl4/html/glGetError.xhtml https://registry.khronos.org/OpenGL-Refpages/gl4/html/glGetE... There's a debug output extension (or core feature since 4.3) that's slightly more verbose, but not universally supported (e.g. AFAIK not on macOS).
  - CyborgCabbage 3y ago
    What about Debug Output? https://www.khronos.org/opengl/wiki/Debug_Output https://www.khronos.org/opengl/wiki/Debug_Output
    - pjmlp 3y ago
      Using those debuggers is like doing CPU debugging. If at least you had posted a link to RenderDoc.
    - flohofwoe 3y ago
      It's better than glGetError() for sure, but not supported everywhere (e.g. macOS is stuck at 4.1 Core Profile).
- drawkbox 3y ago
  > 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. https://webgpufundamentals.org/webgpu/lessons/webgpu-from-webgl.html https://webgpufundamentals.org/webgpu/lessons/webgpu-from-we... > The biggest difference is WebGL is a stateful API and WebGPU is not. By that I mean in WebGL there is a bunch of global state. Which textures are currently bound, which buffers are currently bound, what the current program is, what the blending, depth, and stencil settings are. You set those states by calling various API functions like `gl.bindBuffer`, `gl.enable`, `gl.blendFunc`, etc…, and they stay what you set them globally until you change them to something else. > By contrast, In WebGPU there is almost no global state. Instead, there are the concepts of a pipeline or render pipeline and a render pass which together effectively contain most of the state that was global in WebGL. Which textures, which attributes, which buffers, and all the various other settings. Any settings you don’t set have default values. You can’t modify a pipeline. Instead, you create them and after that they are immutable. If you want different settings you need to create another pipeline. render passes do have some state, but that state is local to the render pass. > The second-biggest difference is that WebGPU is lower level than WebGL. In WebGL many things connect by names. For example, you declare a uniform in GLSL and you look up its location > `loc = gl.getUniformLocation(program, 'nameOfUniform')`; > Another example is varyings, in a vertex shader you use `varying vec2 v_texcoord` or `out vec2 v_texcoord` and in the fragment shader you declare the corresponding varying naming it `v_texcoord`. The good part of this is if you mistype the name you’ll get an error. > WebGPU, on the other hand, everything is entirely connected by index or byte offset. You don’t create individual uniforms like WebGL, instead you declare uniform blocks (a structure that declares your uniforms). It’s then up to you to make sure you manually organize the data you pass to the shader to match that structure. > Note: WebGL2 has the same concept, known as Uniform Blocks, but WebGL2 also had the concept of uniforms by name. And, even though individual fields in a WebGL2 Uniform Block needed to be set via byte offsets, (a) you could query WebGL2 for those offsets and (b) you could still look up the block locations themselves by name. > In WebGPU on the other hand EVERYTHING is by byte offset or index (often called ‘location’) and there is no API to query them. That means it’s entirely up to you to keep those locations in sync and to manually compute byte offsets. For a time, supporting four rendering engines did cause lots of work for game engines, much more integration and abstraction. As OpenGL support fades at least one will drop off. I will miss it as I do still love OpenGL/WebGL. OpenGL and OpenGL ES / WebGL in particular opened up mobile/web gaming in ways never before possible. Prior to that you had Director (3D), Flash (Papervision/Away3D/etc), Silverlight and more recently `<canvas>`. Canvas is great for smaller games but you need raw power for rendering 3d and WebGL (almost a direct port of OpenGL ES) brought that and engines like three.js use that well. Mobile gaming became the biggest gaming market due to OpenGL ES and web games took a leap on WebGL, also apps, interactives and tools became faster rendered. With GL, in many cases the global state is more simple, but to take advantage of GPUs and rendering lower level the innovations were needed. The naming to index/position based for instance is lower level and can also end up in bugs just as the global state in GL could. The benefit is performance and cleaner global state. It is probably a good idea to learn OpenGL/WebGL as some of the concept in WebGPU/newer engines will be more clear, much of it was simpler with naming.
- WCSTombs 3y ago
  Of those three, Vulkan is the only one that is cross platform, and the only one that natively targets Linux.
  - slimsag 3y ago
    Vulkan requires a heavy-weight emulation layer on macOS. Consoles also don't really support it (some do, but not as a first class API) If you only care about Windows and Linux, you can also just use DirectX and require users make use of Proton.
    - vetinari 3y ago
      > Vulkan requires a heavy-weight emulation layer on macOS. That's pretty much self-inflicted issue. > If you only care about Windows and Linux, you can also just use DirectX and require users make use of Proton. Proton drags in Wine, so it is even more heavy-weight than MoltenVK.
    - ho_schi 3y ago
      Please no! 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.
      - shortrounddev2 3y ago
        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
      - iforgotpassword 3y ago
        Please yes! ... At least for commercial, closed source stuff. I'm exclusively on Linux, a casual gamer, and native ports suck. They probably can be done better, but you still run into the problem that some Linux game released 5 years ago doesn't even launch anymore on current distros. I've tried to play the native port of lis2 only to be greeted with a "hey this game needs an AMD or Nvidia GPU" warning, which I could click past only to have the whole system freeze in the main menu. That was literally the first ever crash of that machine ever (about 14 months old at that point). Luckily steam allows you to force using the windows version of a game even if a native port is available and guess what, no warning about GPU, game worked flawlessly. And it very likely still will a decade from now. How many native games released today will? Morale of the story: win32 is the only stable userspace API on Linux. Develop for win32 and test on Linux, boom you got your multi-platform game.
- omoikane 3y ago
  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.
  - cmovq 3y ago
    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.
  - flohofwoe 3y ago
    > 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.
danielvaughn 3y ago
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.
- Grum9 3y ago
  [dead]
- deleted 3y ago
  [deleted]
sylware 3y ago
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.
- Permik 3y ago
  Have you tried running Mesa's lavapipe? It's a software vulkan backend that should already be able to fit your needs if I understood you correctly.
  - sylware 3y ago
    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.
    - Permik 3y ago
      No, I meant Lavapipe, "Mesa's generic CPU-based software Vulkan implementation". Zink is the OpenGL-on-Vulkan implementation by Mike Blumenkrantz & co.
      - sylware 3y ago
        oh, I read wrong I though you were talking about the opengl software implementation. Dunno if lava pipe is clean C and not pulling some horrible c++ stuff like llvm.
- deleted 3y ago
  [deleted]
cyber_kinetist 3y ago
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 https://www.khronos.org/blog/you-can-use-vulkan-without-pipe...) - which overhauls the API by introducing shader objects that you can dynamically link at runtime. Basically somewhere in the middle of DX11/OpenGL and DX12: give back some dynamism to the API, but not up to the point where the driver struggles to maintain performance because of it. - Other attempts seem to resemble more closely towards Render Graphs, which was a strategy that various game engines have already implemented on top of DX12 / Vulkan / console APIs. (See https://logins.github.io/graphics/2021/05/31/RenderGraphs.ht https://logins.github.io/graphics/2021/05/31/RenderGraphs.ht... for a introduction). For example, DX12's Work Graph API as preview (https://devblogs.microsoft.com/directx/d3d12-work-graphs-pre https://devblogs.microsoft.com/directx/d3d12-work-graphs-pre...), or Vulkan's VK_AMDX_shader_enqueue extension (https://gpuopen.com/gpu-work-graphs-in-vulkan/ https://gpuopen.com/gpu-work-graphs-in-vulkan/) But nonetheless, I think I should just wait touching these APIs until things have sorted out between GPU manufacturers and engine developers. (If I would start making a game engine from scratch for my indie game I would probably just use DX11.)
pjmlp 3y ago
And LibGNM, NVN.
Narew 3y ago
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.

whstl 3y ago

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.

alexarnesen 3y ago
If you are looking to dig into Metal, this site and book might be useful. I have no graphics background and found it accessible. Metal By Example https://metalbyexample.com/ https://metalbyexample.com/
- pjmlp 3y ago
  A better one with Swift, https://www.amazon.com/Metal-Programming-Guide-Tutorial-Reference/dp/0134668944 https://www.amazon.com/Metal-Programming-Guide-Tutorial-Refe...
flohofwoe 3y ago
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).
- reactordev 3y ago
  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.
  - flohofwoe 3y ago
    glGetError() is useless unfortunately for getting any information about what went wrong, because it only has 8 error codes: https://registry.khronos.org/OpenGL-Refpages/gl4/html/glGetError.xhtml https://registry.khronos.org/OpenGL-Refpages/gl4/html/glGetE... There's a debug output extension (or core feature since 4.3) that's slightly more verbose, but not universally supported (e.g. AFAIK not on macOS).
- CyborgCabbage 3y ago
  What about Debug Output? https://www.khronos.org/opengl/wiki/Debug_Output https://www.khronos.org/opengl/wiki/Debug_Output
  - pjmlp 3y ago
    Using those debuggers is like doing CPU debugging. If at least you had posted a link to RenderDoc.
  - flohofwoe 3y ago
    It's better than glGetError() for sure, but not supported everywhere (e.g. macOS is stuck at 4.1 Core Profile).
drawkbox 3y ago
> 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. https://webgpufundamentals.org/webgpu/lessons/webgpu-from-webgl.html https://webgpufundamentals.org/webgpu/lessons/webgpu-from-we... > The biggest difference is WebGL is a stateful API and WebGPU is not. By that I mean in WebGL there is a bunch of global state. Which textures are currently bound, which buffers are currently bound, what the current program is, what the blending, depth, and stencil settings are. You set those states by calling various API functions like `gl.bindBuffer`, `gl.enable`, `gl.blendFunc`, etc…, and they stay what you set them globally until you change them to something else. > By contrast, In WebGPU there is almost no global state. Instead, there are the concepts of a pipeline or render pipeline and a render pass which together effectively contain most of the state that was global in WebGL. Which textures, which attributes, which buffers, and all the various other settings. Any settings you don’t set have default values. You can’t modify a pipeline. Instead, you create them and after that they are immutable. If you want different settings you need to create another pipeline. render passes do have some state, but that state is local to the render pass. > The second-biggest difference is that WebGPU is lower level than WebGL. In WebGL many things connect by names. For example, you declare a uniform in GLSL and you look up its location > `loc = gl.getUniformLocation(program, 'nameOfUniform')`; > Another example is varyings, in a vertex shader you use `varying vec2 v_texcoord` or `out vec2 v_texcoord` and in the fragment shader you declare the corresponding varying naming it `v_texcoord`. The good part of this is if you mistype the name you’ll get an error. > WebGPU, on the other hand, everything is entirely connected by index or byte offset. You don’t create individual uniforms like WebGL, instead you declare uniform blocks (a structure that declares your uniforms). It’s then up to you to make sure you manually organize the data you pass to the shader to match that structure. > Note: WebGL2 has the same concept, known as Uniform Blocks, but WebGL2 also had the concept of uniforms by name. And, even though individual fields in a WebGL2 Uniform Block needed to be set via byte offsets, (a) you could query WebGL2 for those offsets and (b) you could still look up the block locations themselves by name. > In WebGPU on the other hand EVERYTHING is by byte offset or index (often called ‘location’) and there is no API to query them. That means it’s entirely up to you to keep those locations in sync and to manually compute byte offsets. For a time, supporting four rendering engines did cause lots of work for game engines, much more integration and abstraction. As OpenGL support fades at least one will drop off. I will miss it as I do still love OpenGL/WebGL. OpenGL and OpenGL ES / WebGL in particular opened up mobile/web gaming in ways never before possible. Prior to that you had Director (3D), Flash (Papervision/Away3D/etc), Silverlight and more recently `<canvas>`. Canvas is great for smaller games but you need raw power for rendering 3d and WebGL (almost a direct port of OpenGL ES) brought that and engines like three.js use that well. Mobile gaming became the biggest gaming market due to OpenGL ES and web games took a leap on WebGL, also apps, interactives and tools became faster rendered. With GL, in many cases the global state is more simple, but to take advantage of GPUs and rendering lower level the innovations were needed. The naming to index/position based for instance is lower level and can also end up in bugs just as the global state in GL could. The benefit is performance and cleaner global state. It is probably a good idea to learn OpenGL/WebGL as some of the concept in WebGPU/newer engines will be more clear, much of it was simpler with naming.
WCSTombs 3y ago
Of those three, Vulkan is the only one that is cross platform, and the only one that natively targets Linux.
- slimsag 3y ago
  Vulkan requires a heavy-weight emulation layer on macOS. Consoles also don't really support it (some do, but not as a first class API) If you only care about Windows and Linux, you can also just use DirectX and require users make use of Proton.
  - vetinari 3y ago
    > Vulkan requires a heavy-weight emulation layer on macOS. That's pretty much self-inflicted issue. > If you only care about Windows and Linux, you can also just use DirectX and require users make use of Proton. Proton drags in Wine, so it is even more heavy-weight than MoltenVK.
  - ho_schi 3y ago
    Please no! 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.
    - shortrounddev2 3y ago
      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
    - iforgotpassword 3y ago
      Please yes! ... At least for commercial, closed source stuff. I'm exclusively on Linux, a casual gamer, and native ports suck. They probably can be done better, but you still run into the problem that some Linux game released 5 years ago doesn't even launch anymore on current distros. I've tried to play the native port of lis2 only to be greeted with a "hey this game needs an AMD or Nvidia GPU" warning, which I could click past only to have the whole system freeze in the main menu. That was literally the first ever crash of that machine ever (about 14 months old at that point). Luckily steam allows you to force using the windows version of a game even if a native port is available and guess what, no warning about GPU, game worked flawlessly. And it very likely still will a decade from now. How many native games released today will? Morale of the story: win32 is the only stable userspace API on Linux. Develop for win32 and test on Linux, boom you got your multi-platform game.
omoikane 3y ago
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.
- cmovq 3y ago
  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.
- flohofwoe 3y ago
  > 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.

danielvaughn 3y ago

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.

Grum9 3y ago
[dead]
deleted 3y ago
[deleted]

sylware 3y ago

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.

Permik 3y ago
Have you tried running Mesa's lavapipe? It's a software vulkan backend that should already be able to fit your needs if I understood you correctly.
- sylware 3y ago
  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.
  - Permik 3y ago
    No, I meant Lavapipe, "Mesa's generic CPU-based software Vulkan implementation". Zink is the OpenGL-on-Vulkan implementation by Mike Blumenkrantz & co.
    - sylware 3y ago
      oh, I read wrong I though you were talking about the opengl software implementation. Dunno if lava pipe is clean C and not pulling some horrible c++ stuff like llvm.
deleted 3y ago
[deleted]

cyber_kinetist 3y ago

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 https://www.khronos.org/blog/you-can-use-vulkan-without-pipe...) - which overhauls the API by introducing shader objects that you can dynamically link at runtime. Basically somewhere in the middle of DX11/OpenGL and DX12: give back some dynamism to the API, but not up to the point where the driver struggles to maintain performance because of it. - Other attempts seem to resemble more closely towards Render Graphs, which was a strategy that various game engines have already implemented on top of DX12 / Vulkan / console APIs. (See https://logins.github.io/graphics/2021/05/31/RenderGraphs.ht https://logins.github.io/graphics/2021/05/31/RenderGraphs.ht... for a introduction). For example, DX12's Work Graph API as preview (https://devblogs.microsoft.com/directx/d3d12-work-graphs-pre https://devblogs.microsoft.com/directx/d3d12-work-graphs-pre...), or Vulkan's VK_AMDX_shader_enqueue extension (https://gpuopen.com/gpu-work-graphs-in-vulkan/ https://gpuopen.com/gpu-work-graphs-in-vulkan/) But nonetheless, I think I should just wait touching these APIs until things have sorted out between GPU manufacturers and engine developers. (If I would start making a game engine from scratch for my indie game I would probably just use DX11.)

pjmlp 3y ago

And LibGNM, NVN.

Narew 3y ago

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.