Hacker News Reader

Comment by jokoon | Hacker News Reader

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?

View on HN

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.

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…)

There's WebGPU Native, with wgpu-native implementing it on top of wgpu, using Vulkan/Metal/DX11/DX12.

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

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.

AMD had V-EZ which seemed interesting to me when I played a bit with Vulkan, but unfortunately it has been unmaintained since 2018...

People were teasing the idea of a good-enough Metal-like API on top of Vulkan that takes care of the pain points since the early days (most notably this article: https://aras-p.info/blog/2015/03/13/thoughts-on-explicit-gra...), but so far, nothing has materialized.

> 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

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.

People have said this since the early days of Vulkan (such as https://aras-p.info/blog/2015/03/13/thoughts-on-explicit-gra...), but so far nothing has really materialized.

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.

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.

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 :)

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…

Reply on news.ycombinator.com