5 ms·

I'm by no means an expert, but my understanding is that OpenGL's API is designed to abstract away details of the underlying hardware, while Vulkan's API is desi

I'm by no means an expert, but my understanding is that OpenGL's API is designed to abstract away details of the underlying hardware, while Vulkan's API is designed to expose the details of the hardware. When OpenGL was designed, the thinking was that graphics programming is hard, and so the API should do the heavy lifting and make the application's job easy. It turns out, though, that graphics programming is so hard that the majority of folk tend to use even higher level graphics libraries to write their applications. The folk writing those graphics libraries want to make their libraries as optimally performant as possible, and the abstract nature of the OpenGL API stands in the way of doing that. They would rather just directly access the hardware. Vulkan is an API that gives that direct access, within the limitations of running in an unprivileged userspace process.

jokoon 4y ago
thanks for the explanation! do you think vulkan will progress into being easier and easier to use? is it mature enough? are there good resource to learn the most basics?
- sounds 4y ago
  Vulkan may be easy to use one day, but it will probably be because you are "writing vulkan" but actually using an impressive set of libraries, languages and other tooling that do stuff for you that you don't want to do.
  - cyber_kinetist 4y ago
    People have said this since the early days of Vulkan (such as https://aras-p.info/blog/2015/03/13/thoughts-on-explicit-graphics-apis/ https://aras-p.info/blog/2015/03/13/thoughts-on-explicit-gra...), but so far nothing has really materialized.
    - johnnyanmac 4y ago
      guess it depends on how specialized to vulkan you mean. Like, Aras in this article even mentioned BGFX as a potential abstracted library, and I'm 99.9% certain that it supports vulkan now. But you can certainly argue that with BGFX you're not "writing vulkan". But if you wanted something that was "vulkan but without 1000 lines to make a triangle", that's what Open GL was trying to be 25 years ago. So Vulkan naturally diverged from that model after seeing the weaknesses. I'm unsure if there's any maintained package trying to wrap this stuff; that's something a graphics engineer would end up doing anyways.
- foxhill 4y ago
  imo, it’s unlikely that it will get much easier directly. if you’re interested in getting into GPU programming, i’d still recommend it. i know it can be daunting at first - the API spec is huge, and there are lots of things to get your head around. ultimately though, the concepts are not exotic or hard to understand. it’s certainly no more difficult than learning to program a regular computer :)
  - cyber_kinetist 4y ago
    Damn, though the hardware of the GPU is a lot much weirder than what you’re used to with the CPU, and don’t let me even get started about CPU-GPU memory transfers…
- adwn 4y ago
  > do you think vulkan will progress into being easier and easier to use? I don't think that is the goal for Vulkan, nor should it be. Vulkan is a low-level, high-performance API that can be used as the backend for high-level, high-performance libraries and frameworks. > is it mature enough? Mature enough for what? It's mature and stable enough that you can develop high-level libraries on top of it. wgpu [1], for example, has a Vulkan backend. [1] wgpu is a WebGPU implementation; https://github.com/gfx-rs/wgpu https://github.com/gfx-rs/wgpu
- izacus 4y ago
  Vulkans ease of use is an explicity non-goal I think - it's benefit comes from exposing the maximally flexible set of APIs to control the underlying GPU hardware, which is in direct opposition of a simple "hello world". The idea is that you use high-level APIs built on top of Vulkan (usually engines like Unity, Unreal or Godot) that then leverage the underlying hardware.
  - cyber_kinetist 4y ago
    I still think that there should be some room for rogue developers who want to make “weirder” games that need specific technical decisions that you can’t make inside an existing game engine. Unity and Unreal all assume that the world you are making is generally made up of static environmental objects, and are hyper-optimized for that use-case both in terms of workflow and performance optimizations. But for types of games that emphasize simulation, procedural generation, or user creation, these assumptions might not hold and custom engines might serve them better. (Games that come to mind are No Man’a Land, Dreams, Factorio, They Are Billions, etc…)
    - formerly_proven 4y ago
      There's WebGPU Native, with wgpu-native implementing it on top of wgpu, using Vulkan/Metal/DX11/DX12.
      - cyber_kinetist 4y ago
        It's still work-in-progress though, and people who are developing games right now shouldn't gamble on it. I would rather want to stick with something that has been for at least 5 years and has successfully shipped multiple games, so that's why I'm using Vulkan even with all its problems. (Maybe I should have used DX11 though, if I was seeking for even more stability.)
      - pjmlp 4y ago
        The restriction there is that by definition will be constrained to the GPU capabilities exposed to WebGPU. Of course, there can be extensions, but use enough of them and it starts not to make sense to use it for native code.
- Jhsto 4y ago
  There's a point to make which is that most people don't probably have problems writing Vulkan code, but shaders instead (that's unless you already know OpenGL). For Vulkan you have many good bindings already in different languages, but then you get into actually writing shaders which requires completely different programming mindset -- everything runs in parallel by default. All your algorithms have to be divide and conquer, so say bye bye to imperative style accumulators. The concepts might be hard to grasp unless you know your way around functional and array programming languages.
cyber_kinetist 4y ago
I still wish there was some kind of middle ground between OpenGL and Vulkan though, as an aspiring indie dev who’s making a 3D game without using Unity/Unreal (The reason for this is that for my game I need at least tens of thousands of simulated AI agents, and conventional gameobject systems aren’t designed to do this performantly.) The Metal API from Apple seems to be just the right abstraction for general graphics programming, though it sucks that you can only use it on Apple devices. Maybe SDL_gpu can take this role once it’s finished, but till then I’m toiling away with Vulkan… yeah it’s still better than OpenGL, but its usability can definitely be improved. Maybe I should have just gone to DirectX 11… since the drivers there are ridiculously optimized.
- SotCodeLaureate 4y ago
  > at least tens of thousands of simulated AI agents Are you planning on displaying all/most of them every frame, or just to control that many of them, then draw those nearby/visible? If it's the former (but how exactly?) then perhaps Vk is the way to go, if the latter, then it's hard to see how Vulkan vs OpenGL is all that relevant here.
  - TillE 4y ago
    Right, there's no reason to discard a game engine just because its most common usage patterns are inappropriate to your needs. Even if you do need to draw a zillion objects on screen, any engine will let you create your own mesh and feed that to the renderer.
    - robotnikman 4y ago
      IIRC the game From the Depths does this, being a game where you create ships using thousands of voxels. Using gameobjects for everything just would not have worked
  - cyber_kinetist 4y ago
    Many of the enemy entities (which I’m expecting to be around the ten-thousands in the late portions of the game) are going to be visible on-screen, since most of them are going to be flying above the ground and only the terrain is going to hide them (no big architectural structures on the map obstructing them). And I would like to create lighting effects when they explode, which would require huge lighting counts. The AI for the flying enemies isn’t going to be too complex, it will probably going to be some variation of boid simulation. However I still expect this to be computationally intensive, particularly when it comes to querying nearby entities and terrain. I am expecting some of the expensive geometric querying can be moved to the GPU via compute shaders. The reason for using Vulkan instead of OpenGL was more of a pragmatic one: I’ve heard that OpenGL drivers can be hilariously bad on Windows, when it comes to both conformance and performance. Vulkan seems to be better in that respect, since both Nvidia and Amd has incentive to develop decent enough Vulkan drivers since some high-profile AAA games use it. Also, it is a pain in the ass to debug issues in OpenGL, and Vulkan is at least better than that.
dixie_land 4y ago
also there was no programmable shaders back then and the fixed pipeline was a very reasonable abstraction for the hardware at the time. https://www.khronos.org/opengl/wiki/Fixed_Function_Pipeline https://www.khronos.org/opengl/wiki/Fixed_Function_Pipeline

jokoon 4y ago

thanks for the explanation! do you think vulkan will progress into being easier and easier to use? is it mature enough? are there good resource to learn the most basics?

sounds 4y ago
Vulkan may be easy to use one day, but it will probably be because you are "writing vulkan" but actually using an impressive set of libraries, languages and other tooling that do stuff for you that you don't want to do.
- cyber_kinetist 4y ago
  People have said this since the early days of Vulkan (such as https://aras-p.info/blog/2015/03/13/thoughts-on-explicit-graphics-apis/ https://aras-p.info/blog/2015/03/13/thoughts-on-explicit-gra...), but so far nothing has really materialized.
  - johnnyanmac 4y ago
    guess it depends on how specialized to vulkan you mean. Like, Aras in this article even mentioned BGFX as a potential abstracted library, and I'm 99.9% certain that it supports vulkan now. But you can certainly argue that with BGFX you're not "writing vulkan". But if you wanted something that was "vulkan but without 1000 lines to make a triangle", that's what Open GL was trying to be 25 years ago. So Vulkan naturally diverged from that model after seeing the weaknesses. I'm unsure if there's any maintained package trying to wrap this stuff; that's something a graphics engineer would end up doing anyways.
foxhill 4y ago
imo, it’s unlikely that it will get much easier directly. if you’re interested in getting into GPU programming, i’d still recommend it. i know it can be daunting at first - the API spec is huge, and there are lots of things to get your head around. ultimately though, the concepts are not exotic or hard to understand. it’s certainly no more difficult than learning to program a regular computer :)
- cyber_kinetist 4y ago
  Damn, though the hardware of the GPU is a lot much weirder than what you’re used to with the CPU, and don’t let me even get started about CPU-GPU memory transfers…
adwn 4y ago
> do you think vulkan will progress into being easier and easier to use? I don't think that is the goal for Vulkan, nor should it be. Vulkan is a low-level, high-performance API that can be used as the backend for high-level, high-performance libraries and frameworks. > is it mature enough? Mature enough for what? It's mature and stable enough that you can develop high-level libraries on top of it. wgpu [1], for example, has a Vulkan backend. [1] wgpu is a WebGPU implementation; https://github.com/gfx-rs/wgpu https://github.com/gfx-rs/wgpu
izacus 4y ago
Vulkans ease of use is an explicity non-goal I think - it's benefit comes from exposing the maximally flexible set of APIs to control the underlying GPU hardware, which is in direct opposition of a simple "hello world". The idea is that you use high-level APIs built on top of Vulkan (usually engines like Unity, Unreal or Godot) that then leverage the underlying hardware.
- cyber_kinetist 4y ago
  I still think that there should be some room for rogue developers who want to make “weirder” games that need specific technical decisions that you can’t make inside an existing game engine. Unity and Unreal all assume that the world you are making is generally made up of static environmental objects, and are hyper-optimized for that use-case both in terms of workflow and performance optimizations. But for types of games that emphasize simulation, procedural generation, or user creation, these assumptions might not hold and custom engines might serve them better. (Games that come to mind are No Man’a Land, Dreams, Factorio, They Are Billions, etc…)
  - formerly_proven 4y ago
    There's WebGPU Native, with wgpu-native implementing it on top of wgpu, using Vulkan/Metal/DX11/DX12.
    - cyber_kinetist 4y ago
      It's still work-in-progress though, and people who are developing games right now shouldn't gamble on it. I would rather want to stick with something that has been for at least 5 years and has successfully shipped multiple games, so that's why I'm using Vulkan even with all its problems. (Maybe I should have used DX11 though, if I was seeking for even more stability.)
    - pjmlp 4y ago
      The restriction there is that by definition will be constrained to the GPU capabilities exposed to WebGPU. Of course, there can be extensions, but use enough of them and it starts not to make sense to use it for native code.
Jhsto 4y ago
There's a point to make which is that most people don't probably have problems writing Vulkan code, but shaders instead (that's unless you already know OpenGL). For Vulkan you have many good bindings already in different languages, but then you get into actually writing shaders which requires completely different programming mindset -- everything runs in parallel by default. All your algorithms have to be divide and conquer, so say bye bye to imperative style accumulators. The concepts might be hard to grasp unless you know your way around functional and array programming languages.

cyber_kinetist 4y ago

I still wish there was some kind of middle ground between OpenGL and Vulkan though, as an aspiring indie dev who’s making a 3D game without using Unity/Unreal (The reason for this is that for my game I need at least tens of thousands of simulated AI agents, and conventional gameobject systems aren’t designed to do this performantly.) The Metal API from Apple seems to be just the right abstraction for general graphics programming, though it sucks that you can only use it on Apple devices. Maybe SDL_gpu can take this role once it’s finished, but till then I’m toiling away with Vulkan… yeah it’s still better than OpenGL, but its usability can definitely be improved. Maybe I should have just gone to DirectX 11… since the drivers there are ridiculously optimized.

SotCodeLaureate 4y ago
> at least tens of thousands of simulated AI agents Are you planning on displaying all/most of them every frame, or just to control that many of them, then draw those nearby/visible? If it's the former (but how exactly?) then perhaps Vk is the way to go, if the latter, then it's hard to see how Vulkan vs OpenGL is all that relevant here.
- TillE 4y ago
  Right, there's no reason to discard a game engine just because its most common usage patterns are inappropriate to your needs. Even if you do need to draw a zillion objects on screen, any engine will let you create your own mesh and feed that to the renderer.
  - robotnikman 4y ago
    IIRC the game From the Depths does this, being a game where you create ships using thousands of voxels. Using gameobjects for everything just would not have worked
- cyber_kinetist 4y ago
  Many of the enemy entities (which I’m expecting to be around the ten-thousands in the late portions of the game) are going to be visible on-screen, since most of them are going to be flying above the ground and only the terrain is going to hide them (no big architectural structures on the map obstructing them). And I would like to create lighting effects when they explode, which would require huge lighting counts. The AI for the flying enemies isn’t going to be too complex, it will probably going to be some variation of boid simulation. However I still expect this to be computationally intensive, particularly when it comes to querying nearby entities and terrain. I am expecting some of the expensive geometric querying can be moved to the GPU via compute shaders. The reason for using Vulkan instead of OpenGL was more of a pragmatic one: I’ve heard that OpenGL drivers can be hilariously bad on Windows, when it comes to both conformance and performance. Vulkan seems to be better in that respect, since both Nvidia and Amd has incentive to develop decent enough Vulkan drivers since some high-profile AAA games use it. Also, it is a pain in the ass to debug issues in OpenGL, and Vulkan is at least better than that.

dixie_land 4y ago

also there was no programmable shaders back then and the fixed pipeline was a very reasonable abstraction for the hardware at the time. https://www.khronos.org/opengl/wiki/Fixed_Function_Pipeline https://www.khronos.org/opengl/wiki/Fixed_Function_Pipeline