I wouldnt recommend anyone going to Vulkan, though. It's pretty much the worst graphics API out there, and WebGPU is mimicking outdated Vulkan design decisions that even Vulkan is currently outphasing, like render passes and static pipelines.
WebGPU is newer, but lacks modern functionality because it was made to support ancient smartphones. That's great if you want to support ancient smartphones, but not if you want to utilize modern desktop GPUs.
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.
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.
On the contrary, it's great. Cuda is the single sane compute API and system, so I'll use it even if it means being vendor-locked. If my CUDA programs start running elsewhere without much intervention, that'd be amazing
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.
A couple of years ago I evaluated both Vulkan and Cuda as a choice for future projects. I couldnt get anything done after a week in Vulkan, but had the test prototype project working after just a day in Cuda.
Needless to say, I'd never ever pick Vulkan for any project after that experience. It's just way to needlessly overengineered and bloated.
> Ease of programming and a giant leap in performance is one of the key reasons for the CUDA platform’s widespread adoption
This, so much. Other platforms continue to ignore developer UX, but it's one of the main things that get's new users onboard and keeps old users around.
> unimportant implementation detail that should be assessed on performance alone rather than usability
I disagree. Usability is important, or you end up with garbage like Vulkan. I'd rather have 99% of the performance for 100% usability, than 100% of the performance for 5% of the usability.
Unfortunately when it comes to graphics APIs, the choices are between bad and worse, which is why I switched to doing real time rendering in CUDA. Easier to write a fast software rasterizer in cuda, than to draw a single triangle in Vulkan
Having participated in many studies, I lost much faith in studies. You could study the same thing, and get opposite results depending on how you build the study, which people participate (friends and colleagues will be reluctant to speak against your results), and the bias with which you set everything up. Also, many tasks require learning the tools, and some tools will start to be more productive with expertise than others.
That was an interesting read. Also enjoyed reading about the semaphores in the default stream. It's great that cuda implicitly handles syncing of commands for users and makes parallel commands optional and opt-in via streams, unlike Vulkan which completely unloads the full complexity of syncing to users right from the start.
I like the driver API because it allows treating Cuda kernels like hot-reloadable shaders. It's fun to develop while being able to change the code at runtime.
I haven't tried the latest Codex but I switched from GPT to Claude because I think Claude writes much better Code. GPT's code ends up way more verbose/complex/overengineered than it needs to be.
I've always considered shared_ptr to be semi-garbage collection. Allows me to code C++ almost as if it were Java so long as circular references are avoided. I'm perfectly fine with it being considered a type of garbage collection.
You're skillfully dodging the point: Trilinear filtering is in no way an "ideal" alternative.
It has worse quality than something like a Lanczos filter, and it requires computing image pyramids first, i.e., it is also slower for the very common use case of rescaling images just once. And that article isn't really about projected/distorted textures, where trilinear filtering actually makes sense.
Trilinear requires an image pyramid. Without downsampling to create that image pyramid, you can't even do trilinear sampling, so your argument strikes me as odd and circular. Like telling developers of APIs such as ID3D11DeviceContext.GenerateMips to simply use ID3D11DeviceContext.GenerateMips instead of developing ID3D11DeviceContext.GenerateMips. Also, I never took this article to be about 3D rendering and utilizing mip maps for trilinear interpolation. More about 2D image scaling.
Have you never downscaled and upscaled images in a non-3D-rendering context?
Sure is, but there is nothing stopping AMD or Intel from building a working alternative to CUDA, so how is it anti-competitive? The problem with OpenCL, Sycl, ROC, etc. is that the developer experience is terrible. Cumbersome to set up, difficiult to get working accross platforms, lack of major quality of life features, etc.