Please don't misinterpret this as gate keeping, but Vulkan is designed by and for professionals (not hobbyists). It is certainly not a rapid prototyping tool. Vulkan and OpenGL aren't comparable because Vulkan isn't merely a graphics API, but rather it's a low-level GPU API. For example you can use Vulkan in place of CUDA for running highly parallelized computations on the GPU (no graphics implied).
Yeah, I know, that's why I mentioned it being a target. I realize it's meant to be used for extremely low-level stuff. Which is fine, I don't get annoyed at x86_64 assembly being difficult to write.
As I said, the thing that bothers me is when people act like Vulkan is a replacement for OpenGL (presumably because they've never actually written either and they just saw some YouTube demos), and it really isn't, or at least that's an incomplete picture. It's a replacement for OpenGL in the same way writing JVM bytecode directly is a replacement for Java; they fundamentally do the same or similar things, but one is sort of categorically different in its goal.
I do wish that there was a more consumer-friendly API announced in addition to Vulkan though; I'm fine with replacing OpenGL with something newer and better-fitting for newer cards, but that's not what we got. That's why I was trying to say that I was annoyed that Apple didn't open source Metal, because I feel like it really could have taken that role.
Also, while I'm aware that Vulkan doesn't inherently imply "graphics", I would also like to point out that CUDA and rocM are also considerably easier to write than the Vulkan equivalents, at least in the little examples I played with, though I will acknowledge that I felt Vulkan was better than OpenCL.
> I would also like to point out that CUDA and rocM are also considerably easier to write than the Vulkan equivalents
I agree that Vulkan has more boilerplate, but I think that's because Vulkan is an open standard and makes fewer assumptions which means the API has more ceremony. For example Vulkan might be implemented for custom embedded hardware; its design helps give the manufacturer more leeway. CUDA and ROCm were designed by Nvidia and AMD for their own hardware and so they can bake in low-level assumptions which means a more streamlined API.
Well ROCm is more or less designed to be portable between both; that's not strictly true but it's fairly similar to CUDA so I don't know how much of that boilerplate is reduced by the fact that it's AMD specific. Your point is fair though; Vulkan kind of runs on almost-literally everything made in the last nine years or so, so it can assume basically zero about any kind of underlying OS stuff.
Still, Vulkan has convinced me that I have no desire to work that low-level of GPU programming, as I had zero fun playing with it. I guess I like having one layer up of abstraction; I'm happy enough to write CUDA, and I'm happy enough to write anything higher level than that.
> Please don't misinterpret this as gate keeping, but Vulkan is designed by and for professionals (not hobbyists). It is certainly not a rapid prototyping tool. Vulkan and OpenGL aren't comparable because Vulkan isn't merely a graphics API, but rather it's a low-level GPU API. For example you can use Vulkan in place of CUDA for running highly parallelized computations on the GPU (no graphics implied).
This is bullshit and it doesn't mean anything. In the days of OpenGL, you used the same initialization code regardless if you were a "professional" or a "hobbyist." Code is code.
It especially doesn't mean anything because people use CUDA for CUDA, and want to use Vulkan for graphics because OpenGL has been discontinued.
