Weird, most people have the exact opposite experience.

Having to deal with closed source opaque poorly documented stacks sucks.

They really don't, no. Vulkan: 50 lines to allocate device memory. Cuda: One single line. What kind of extensive documentation stack do you want for functionality that is trivial in Cuda? And that exact issue continues through every little step of the way to your first usable application. I know there is VMA, it is a very poor solution to a problem that shouldn't even exist, and it only poorly addresses one of 100 parts of the API where Cuda is vastly simpler than Vulkan. Cuda also doesnt force you to use queue families but you can optionally use streams. No ridiculous descriptor management and binding in cuda, just passing pointers and handles via launch arguments. No overengineered explicit syncing mechanis in cuda, everything is nicely implicitly synced until you explicitly opt in to parallel streams. etc.

▲

xyzsparetimexyz a day ago | parent [-]

It's quite easy to set up a light abstraction layer with Vulkan where you simply use VMA, buffer device addresses and push constants for everything. No descriptor sets or bindings anything.

Alternatively you can use one of many abstraction layers that do this for you.

▲

mschuetz 21 hours ago | parent [-]

It absolutely isn't. After having spent 5 days not getting anything done in Vulkan, and being able to implement that same thing in a single day in Cuda (no prior experience in either API), I decided to never ever use Vulkan. It's a hopelessly overengineered API that is in dire need of a successor.

I may give it another try once it does not require a wrapper before it is remotely usable. I.e., once it has a single-line malloc without the need for third-party libs; default queues so I don't need to query and select queues; implicit sync by default and explicit sync by choice; NV-style bindless (i.e. no descriptors, just a handle); and so much more.

▲

xyzsparetimexyz 21 hours ago | parent [-]

Skill issue. Vulkan is intended to be unopinionated around those things. If you want defaults then use a wrapper.

P.s. devices and queues are generally ordered for simple programs you can just pick the 1st one.

	▲	pjmlp 8 hours ago \| parent \| next [-]
		Of course, which is why no one is racing to adopt Vulkan, and since last year they have started multiple activities to try to turn Vulkan around to be usable for everyone, not only AAA game engines experts. Do you want the Vulkanised 2025 and 2026 talks where this is discussed and acknowledged as a problem for Vulkan adoption?
	▲	mschuetz 20 hours ago \| parent \| prev [-]
		Of course it is a skill issue, I'm not afraid of admitting I'm not smart enough for Vulkan. That so many people have skill issues is the reason why Cuda trumps and will continue to trump Vulkan despite being vendor-locked. If you want people to actually use Vulkan, you need to remove barriers to skill-issued people like me. Poor third party wrappers like VMA that barely address one out of hundreds of issues aren't going to accomplish that, you need to resolve barriers in the core API. With a design like Cuda where there is always a default easy path, and a complex but optional path.