[m-schuetz]

So I've been told so I'm trying to take another look at it. At least the examples at https://github.com/SaschaWillems/Vulkan, which are probably not 1.3/1.4 yet except for the trianglevulkan13 example, are pure insanity. Coming from CUDA, I can't fathom why what should be simple things like malloc, memcpy and kernel launches, end up needing 300x as many lines.

[jplusequalt]

In part, because Vulkan is a graphics API, not a GPGPU framework like CUDA. They're entirely different beasts.

Vulkan is also trying to expose as many options as possible so as to be extensible on as many platforms as possible. Also, Vulkan isn't even trying to make it more complex than it need be--this is just how complex graphics programming is period. The only reasons people think Vulkan/DX12 are overly complicated is because they're used to using APIs where the majority of the heavy lifting comes from the drivers.

[barchar]

No, it is overly complex for modern hardware (unless you use shader objects). Vulkan forces you to statically specify a ton of state that's actually dynamic on modern GPUs. You could cut things down a ton with a new API. Ofc you'd have to require a certain level of hardware support, but imo that will become natural going forward.

Actually, it would be kinda neat to see an API that's fully designed assuming a coherent, cached, shared memory space between device and host. Metal I guess is closest.

[bsder]

> Vulkan forces you to statically specify a ton of state that's actually dynamic on modern GPUs.

Desktop GPUs. Tiling GPUs are still in use on mobile and you can't use the tiling hardware effectively without baking the description into pipelines.

> You could cut things down a ton with a new API.

VK_KHR_dynamic_rendering is what you are looking for

> Actually, it would be kinda neat to see an API that's fully designed assuming a coherent, cached, shared memory space between device and host.

You can just ask for exactly that--even on Vulkan. If you don't want to support computer systems that don't support RBAR, you can do that.

[jplusequalt]

>Ofc you'd have to require a certain level of hardware support

Have you used Vulkan? Specifying required hardware support for your physical device is literally one of the first thing you do when setting up Vulkan.

[flohofwoe]

> In part, because Vulkan is a graphics API, not a GPGPU framework like CUDA. They're entirely different beasts.

Tbf, the distinction between rendering and compute has been disappearing for quite a while now, apart from texture sampling there isn't much reason to have hardware that's dedicated for rendering tasks on GPUs, and when there's hardly any dedicated rendering hardware on GPUs, why still have dedicated rendering APIs?

[barchar]

And, mesh shading in particular is basically "what if we just deleted all that vertex specification crap and made you write a compute shader"

Note that it's not always better. The task shaders are quite hardware specific and it makes sense to ship defaults inside the driver.

[pjmlp]

Yes, I predict eventually we will be back at software rendering, with the difference that now it will be hardware accelerated due to running on compute hardware.

[jplusequalt]

This is not a statement on the hardware, it's a statement on what the APIs are trying to achieve. In this regard, they are remarkably different.

[flohofwoe]

The point is that a (self-declared) low-level API like Vulkan should just be a thin interface to GPU hardware features. For instance the entire machinery to define a vertex layout in the PSO is pretty much obsolete today, vertex pulling is much more flexible and requires less API surface, and this is just one example of the "disappearing 3D API".

More traditional rendering APIs can then be build on top of such a "compute-first-API", but that shouldn't be the job Khronos.