0

C++ has a proposal that named std::execution, in this proposal, we don't have to write synchronization manually and it's zero cost abstraction.

I'm new to Vulkan. After some study, I find Vulkan has many complex synchronization commands which is hard for me to study.

I hope we can write Vulkan like std::execution. So, the question is:

Can we wrap Vulkan into a std::execution style API? I find WebGPU don't have to write synchronization manully, is WebGPU the API I want?

macomphy
  • 413
  • 1
  • 9
  • 1
    "*C++ has a proposal that named std::execution, in this proposal, we don't have to write synchronization manually and it's zero cost abstraction.*" Many things have been said to be "zero cost abstractions". Many of them rarely work out that way. Don't get me wrong; executors are nice and extremely useful. But don't pretend they're a panacea which, if you slather it everywhere in your code, magically makes it fast. – Nicol Bolas Jul 07 '23 at 13:32
  • Seems it would be trivial to implement `then()` with Semaphores\Fences, though to me it would feel rather cute rather than helping much anything. Memory Barriers on the other hand are somewhat below C++ level of abstraction (except here and there like `std::memory_order`). Nevertheless they might be somewhat important on GPUs, which are much more architecturally sensitive to memory than CPU. – krOoze Jul 07 '23 at 23:40

1 Answers1

4

Vulkan is an explicit, low-level API. Nothing happens in it without your expressed command that it does. This is by design.

Also, GPUs aren't CPUs. Many of their "threads" have asymmetric capabilities (only certain queues can process certain kinds of work), and picking which to use in what circumstances is an exercise that doesn't have a default case. GPUs are also much more varied in overall capabilities; some GPUs have exactly one queue and one pool of memory, while others have dozens of available queues and several pools of memory.

Vulkan makes you engage with all of these (and more) questions because that's its job: to allow programmers to get into the actionable details of GPU programming.

Could you write some abstraction layer that is easier to use and provides default answers to these questions? Sure. But if performance matters to you, you want to be able to engage with these questions to solve performance problems. There is no "mostly correct" answer in many of these cases; the answer is highly dependent on your workload.

One of the primary reasons Vulkan exists is to be able to use CPU threads to create work largely independently of one another. So whatever abstraction layer you build would need to do this as well. And that requires engaging with synchronization, as the operations being worked on in different threads need to make assumptions about what's going on in other threads.

WebGPU is a fine API for what it is and is intended to be (a lingua franca graphics API). But the thing that powers WebGPU under the hood will be a lower-level API like Vulkan.

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982