mschuetz

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.

For me, the 20€/months subscriptions were always sufficient, and it's nice if that subscription give the latest and greatest results.

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?

OpenCL isn't nice to use and lacks tons of quality of life features. I wouldn't use it, even if it was double as fast as CUDA.

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.

The magic is that CUDA actually works well. There is no reason to pick OpenCL, ROCm, Sycl or others if you get a 10x better developer experience with CUDA.

OpenCL is an alternative to CUDA just like Legos are an alternative to bricks. The problem with OpenCL isn't even the performance, it's everything. If OpenCL were any good, people could use it to build similarly powerful applications on cheaper AMD GPUs.

It's currently unparalleled when it comes to realism as in realistic 3D reconstruction from the real world. Photogrammetry only really works for nice surfacic data, whereas gaussian splats work for semi-volumetric data such as fur, vegetation, particles, rough surfaces, and also for glossy/specular surfaces and volumes with strong subdivision surface properties, or generally stuff with materials that are strongly view-dependent.

Immunosuppressants are very commonly used for various diseases that are caused by overreactions or undesired reactions of your immune system. Glucocorticoids, for example, are very widespread for all sorts of stuff (rashes, asthma, allergies, inflammations, ...). Monoclonal antibodies are also getting popular as a way to treat allergic reactions by means such as "killing" your IgE antibodies (They're basically antibodies that, in this instance, are used against your own body's antibodies).

WebGL has been around for more than a decade and didn't turn out to be a security issue, other than occasionally crashing tabs. Neither will WebGPU be.

> No one wants that.

I very much do want that since the WebGPU API is far easier and nicer to use than Vulkan or OpenGL. Also, it makes apps much more accessible to distribute them over web, and it is much more secure to use web apps than native apps. Unfortunately WebGPU is way too limited compared to desktop APIs.

Not really, that is not the problem of WebGPU. The worst you can do is crash the tab. With an unstable graphics driver, there might even be the option to crash the system but that's hardly a security issue, only an annoyance.

I'm really looking forward to 2034, when WebGPU features will catch up to 2024.

Apart from the examples given by the other user: 64 bit integers and their atomics which are the bread and butter of efficient software rasterizers such as Nanite, or for point clouds which can be rendered multiple times faster with 64 bit atomics compared to using the "point-list" primitive; subgroup operations; bindless; sparse buffers; printf; timestamps inside shaders; async memcpy and copy without the necessity for an intermediate copy buffer and so much more. One of the worst is that they're adding limitations of all languages, but not the workarounds that may exist in them. Like WebGPU actively prohibits buffer aliasing or mixing atomic and non-atomic access to memory because of Apple's Metal Shading Language, but Metal supports it via workarounds! I mean... seriously? That actually makes WebGPU even worse than the lowest common denominator.

One of the turning points for the worse was the introduction of WGSL. Before WGSL, you could do lots of stuff with spirv shaders because they weren't artifically limited. But with WGSL, they went all in on turning WebGPU into a toy-language that only supports whatever last decades mobile phones support. I was really hopeful for WebGPU because UX-wise, it is so much better than anything else. Far better than Vulkan or OpenGL. But feature-wise, WebGPU so limited that I had to go back to desktop OpenGL.

In one way WebGPU really has become a true successor to WebGL though - it is a graphics API that is outdated on arrival.

OP is right. WebGPU is targeted towards the lowest common denominator, which is fairly old mobile phones. It therefore doesn't support modern features and is basically an outdated graphics API by design.

I gave up on Vulkan simply because it's too overengineered and cumbersome. WebGPU, on the other hand, is relatively easy to use, even though it is build on many of the same concepts.

> Vulkan 1.3 has pointers, thanks to buffer device address[1].

> [1] https://community.arm.com/arm-community-blogs/b/graphics-gam...

"Using a pointer in a shader - In Vulkan GLSL, there is the GL_EXT_buffer_reference extension "

That extension is utter garbage. I tried it. It was the last thing I tried before giving up on GLSL/Vulkan and switching to CUDA. It was the nail in the coffin that made me go "okay, if that's the best Vulkan can do, then I need to switch to CUDA". It's incredibly cumbersome, confusing and verbose.

What's needed are regular, simple, C-like pointers.

AMD/Intel/Khronos are free to compete with something better. NVIDIA isn't preventing them from doing so. And in that regard, CUDA is a massive benefit to consumers, because the alternatives are really bad.

CUDA is just way to good in terms of UX with nothing platform-independent coming close to it. I wish there was a competitor, but there simply isn't.

I wish AMD&Intel would extend compute shaders with pointers&pointer casting, arbitrary large buffers instead of just 4GB, device-wide sync, and function pointers. Those are kinda my must-have functionality. Even better, just use C++ for compute shaders.

A subset that lacks pointers, which makes compute shaders a toy language next to CUDA.

It's kinda like building Legos vs building actual Skyscrapers. The gap between compute shaders and CUDA is massive. At least it feels massive because CUDA has some key features that compute shaders lack, and which make it so much easier to build complex, powerful and fast applications.

One of the features that would get compute shaders far ahead compared to now would be pointers and pointer casting - Just let me have a byte buffer and easily cast the bytes to whatever I want. Another would be function pointers. These two are pretty much the main reason I had to stop doing a project in OpenGL/Vulkan, and start using CUDA. There are so many more, however, that make life easier like cooperative groups with device-wide sync, being able to allocate a single buffer with all the GPU memory, recursion, etc.

Khronos should start supporting C++20 for shaders (basically what CUDA is) and stop the glsl or spirv nonsense.

That ship has sailed. Choices are stdout or stderr. Given those names, I'll of course send errors to stderr, leaving me with stdout for messages/infos/logs.

Most applications nowadays use stdout for exactly what the name implies - any form of output. Complaining about that is yelling at the clouds.

A board member's husband?

How so? Seems like a fairly simple license.

The problem with "unlimited detail" wasn't that it was static (the majority of any game's environment are), it's that it was using voxels which can't really compete with triangles when it comes to a quality-perf trade-off. They could render massive data sets, but not with a quality that is needed for games. Voxel-based data sets tend to require a whole lot of memory, whereas triangle-based data sets can cheaply "fake" higher details with textures. The blockiness of voxels is also a huge issue for anything that's not an axis-aligned-bounding-box, and to fix that you have to invest so much GPU resources, you might as well go back to textured triangles.

I wouldn't be surprised if gaussian splats make it into AAA games, though. Not as the main rendering primitive, but for specific things like vegetation where they really kick ass.

How are they preventing the competition to create something better than CUDA? And how does it hurt the consumers that they are providing a fantastic product that others refuse to provide?

Those are some poor arguments, imho, because there literally is no other option than CUDA. The alternatives are so bad, it's far better to be vendor-locked and being able to get stuff done, than not being able to get stuff done at all.

As I said, I avoided it for years because of the reasons you mentioned. Turns out I could not avoid it any longer because it's the only (meaningful) option that could do what I needed, has serious support, and great UX. And NVIDIA is hardly to blame because they simply made sure to build a good product. It can't stop AMD, Intel or Khronos from creating a competitive alternative, but so far they haven't.

And regarding support, so far NVIDIA has shown excellent continuous support for CUDA, whereas OpenCL and OpenGL are the ones that went down. And I've chosen CUDA over rocm precisely due to support reasons, because AMD has always treated it as some kind of side gig with uncertain future.