4 ms·

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 mo

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

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