mschuetz

> It's an official Khronos standard

I think that's the problem. Khronos isn't known for good UX, and being from Khronos is exactly the reason why I'm not even bothering to check it out. I want an alternative to CUDA, but I also want it to be as easy to use as CUDA.

Many of the best papers appear an Arxiv first. In some fields, it is customary to put your preprint on Arxiv before/during the submission to the peer reviewed venue.

Arxiv is vital for quickly developing research fields.

Userbenchmark is fairly useless for CPU performance, though. Their results are often completely nonsensical.

The issue with Vulkan is that it's so cumbersome, I just don't want to use it at all. Tried to switch, but went back to OpenGL. There isn't anything in Vulkan that warrants that insane amount of overhead.

WebGPU is based on similar modern paradigms but it's an actually usable, sane, not overly verbose API. It's a pitty that WebGPU is deliberately gutted to make it a 5 year old smartphone graphics API because I'd prefer it over Vulkan any day.

I'm glad that Vulkan is taking some steps back on render passes, pipelines, etc. If they keep removing unnecessary entry barriers, I might eventually try the switch again in a few years.

Because browsers are by far the easiest, safest, and fastest way to distribute applications. Operating Systems still don't have any sort of meaningful sandboxing so downloading and executing binaries from any source is out of question. With web applications, you can do that. Instantly and uncomplicated. This is not going to change anymore, it's just way too useful.

The problem is that GDPR doesn't go far enough. It should completely prohibit third party tracking without the possibility to agree to it. Third party cookies/tracking simply should not exist.

One reason is that WebGL isn't a 2010s technology, but more of a 2005 technology (it doesn't even have compute shaders). WebGPU will finally bring the Web to the state of 2010.

You'd use level of detail structures, like google earth does.

Since I'm doing 3D graphics in Web Browsers, I consider not having 3D graphics APIs in Web Browsers a broken web experience. The browser is the easiest and safest way to distribute applications with virtually no entry barrier to users. I don't trust downloading just any binary and therefore I won't execute them unless they are from a trusted source. But with 3D in browsers, I can trust any web site not do damage my system and try a large amount of experiences that others create and upload.

You're free to disable features you don't like. For others, this is good news.

Yeah, WebGPU unfortunately ended up becoming an outdated mobile phone graphics API on arrival. Still better than WebGL, but not quite what I would have liked it to be.

Unfortunately WebGPU is also an essentially a 5 year old mobile phone graphics API, which means for most desktop features younger than 10 years, you'll still need DirectX, Vulkan, or Metal.

I hope it takes off, a platform independent alternative to CUDA would be great. But if they want it to be successfully outside of supercomputing labs, it needs to be as easy to use as CUDA. And I'd say being successfull outside of supercomputer labs is important for overall adoption and success. For me personally, it would also need fast runtime compilation so that you can modify and hot-reload ROCm programs at runtime.

> Sometimes, like with CUDA, they just have an early enough lead that they entrench.

The problem in case of CUDA isn't just that NVIDIA was there early, it's that AMD and Khronos still offer no viable alternative after more than a decade. I've switched to CUDA half a year ago after trying to avoid it for years due to being proprietary. Unfortunately I discovered that CUDA is absolutely amazing - It's easy to get started, developer friendly in that it "just works" (which is never the case for Khronos APIs and environments), and it's incredibly powerful, kind of like programming C++17 for 80 x 128 SIMD processors. I wish there was a platform independent alternative, but OpenCL, Sycl, ROCm aren't it.

All of the examples look unreadable and hard to debug to me. Why not something like this rather than one massive nested instruction?

    let keys = Object.keys(envars);
    let text = keys.map(envar => `${envar}=${envars[envar]}`).join(" ");
    console.log(chalk.dim(`$ ${text}`), "node", args.join(' '));

That way you can easily inspect and verify the intermediate values at runtime. Helpful for you to see if your code works as expected, helpful for others to see what the code is doing.

I develop programs that take unsorted data as input, and sort them as part of the processing... I haven't touched a database in 10 years, because I do graphics programming, nothing that needs a database. Also, I don't actually use radix sort but a hand written CUDA counting sort that beats the crap out of radix sort for my given use cases, since counting sort is often used as part of radix sort, but simple counting sort is all I need.

> and use a real database.

I'm not going to use a database to store tens of billions of 3D vertices. And I'm not going to use a database to sort them, because it's multiple times, probably orders of magnitude faster to sort them yourself.

It's weird to impose completely out-of-place suggestions onto someone who does something completely different to what you're thinking of.

> be honest, how often are you sorting things by a number and only a number?

More often than not. Sorting by morton code, sorting by index, etc.

Because its the securest way we have to launch any app on any device. With binaries, any binary might be malicious and therefore I can only trust and run a very small amount of selected binaries. With web apps, I can launch whatever I want without compromising my system.

It's simply fraud. There are laws against fraud.

That's normal, most papers are written unnecessarily complex, likely to make them appear more impressive than they actually are. Many blog posts that contain just as much information as papers, but presented in a much more intelligible way.

You are making a surprisingly good case for browser apps. With binaries, you're restricted to a tiny fraction of available apps that are carefully vetted to _reduce_ the chance of security issues, whereas with browser apps, you can run any untrusted web page. A malicious binary can spy on pretty much any private and sensible data on your PC, while a malicious web page can only do some fingerprinting.

> Desktop apps do have to adhere to the same system security permission that the browser provides.

A desktop app on an average users PC has access to most files on disk, including sensitive data. While a browser has that too, apps running inside a browsers sandbox do not.

The average user and use case typically has internet connection so you're talking about edge-case scenarios. In a regular scenario, a native app can send whatever it wants about your system to a server, including your sensitive photos and private information.

> Anything I click on that loads a new resource sends data to the server about what I'm doing.

Nothing stops native apps of doing that. Plenty require you to have internet connection and coerce you into telemetry. The difference is that one can only send data that the browser will allow it to have, while the other can read all your sensitive data on disk.

How is installing a binary supposed to be more secure than a web page? A binary can do largely whatever it wants, especially for an average person that will grant it all the permissions it requests.

> better privacy/security than a webapp.

It's the complete opposite and one of the reasons I prefer to use a comparable web app over a native desktop app. Installing an app requires way more trust into it than using a web app that runs inside a heavily restricted sandbox.

As for why I also like to prefer developing web apps, that's because the available tools make web development more productive. Checking changes to the source is near-instant by simply pressing F5 in the browser, and the dev tools in browsers are some of the best you can get for debugging.

Since when do we not allow children to wander around by themselves? It's perfectly normal in Austria.

Since when do we not allow children to wander around by themselves? It's perfectly normal in Austria.

It's not just the boilerplate, but also seemingly noncensical things like stypes.

I think one of the main issues is that Vulkan is really bad from a usability perspective. OpenGL is too, but there is little incentive to switch from one bad API that you know how to use, to another bad API that you don't know how to use. On the other hand, I've spent time learning WebGPU in the past year and found that it was an excellent API that is an enormous quality of live improvement over OpenGL, so even if it has fewer features (due to Web, not API design), it's still something that I really want to switch to, unlike Vulkan.

True, I do vote with my feet. Which is why I won't apply for jobs with remote teams, and which is why I'm sticking with my current job.