Hacker News Reader

Comment by on_the_train | Hacker News Reader

But sdl is super high level. If you want to do more than pong, you'll hit a wall very quickly.

I just want OpenGL, it was the perfect level of abstraction. I still use it today, both at work and for personal projects.

View on HN

For what it's worth my experience with Metal was that it was the closest any of the more modern APIs got to OpenGL. It's just stuck on an irrelevant OS. If they made sure you could use it on Windows & Linux I think it'd fill a pretty cool niche.

WebGPU is in many ways closer to Metal than to Vulkan. You can use the API outside of the browser too, especially in Rust.

> WebGPU is in many ways closer to Metal than to Vulkan.

If only that were true for the resource binding model ;) WebGPU BindGroups are a 1:1 mapping to the Vulkan 1.0 binding model, and it's also WebGPU's biggest design wart. Even Vulkan is moving away from that overly rigid model, so we'll probably be stuck with a WebGPU that's more restrictive than required by any of its backend APIs :/

I'll check out WebGPU at some point, I guess. I've written our rendering layer in all of the major APIs (OpenGL, DX12, Vulkan and Metal) and found it very instructive to have all of them to compare at the same time because it really underscored the differences; especially maintaining all of them at the same time. We eventually decided to focus only on DX12, but I think I'll revive this "everything all at once" thing for some side projects.

As someone who has done this since DX7, what you’re looking for is WebGPU either Dawn (Google) or wgpu-native (Firefox). WebGPU works. It’s 99% there across platforms for use.

There’s another wrapper abstraction we all love and use called BGFX that is nice to work with. Slightly higher level than Vulkan or Metal but lower than OpenGL. Works on everything, consoles, fridges, phones, cars, desktops, digital signage.

My own engines have jumped back and forth between WebGPU and BGFX for the last few years.

Personally I'm not interested in the web as a platform. The APIs themselves I'm interested in, but as a target I think the web needs to die for everything that isn't a document.

I never mentioned the web as a target, rather devices. You don’t need a browser, you need a window or a surface to draw on and use C/C++/Rust/C# to write your code.

WebGPU is a standard, not necessarily for the web alone.

At no point does a browser ever enter the picture.

https://eliemichel.github.io/LearnWebGPU/index.html

It sounds like the standard did itself a disfavor by its name, more interesting in how you describe it.

Well, it started off with “all the right intentions” of providing low-level access to the GPU for browsers to expose as an alternative to WebGL (and OpenGL ES like API’s of old).

However, throw a bunch of engineers in a room…

When wgpu got mature enough, they needed a way to expose the rust API for other needs. The C wrapper came. Then for testing and other needs, wgpu-native. I’m not a member of either team so I can’t say why for sure but because of those decisions, we have this powerful abstraction available pretty much on anything that can draw a web page. And since it’s just exposing the buffers and things that Vulkan, Metal, etc are already based on, it’s damned fast.

The added benefit is you get WGSL as your shading language which can translate into any and all the others.

The downsides are it provides NO WINDOW support as that needs to be provided by the platform, i.e. you. Good news is the tests and stuff use glfw and it’s the same setup to get Vulkan working as it is to get WebGPU working. Make window, probe it, make surface/swap chain, start your threads.

The WebGPU spec identifies squarely as a web standard: "WebGPU is an API that exposes the capabilities of GPU hardware for the Web." There are also no mentions of non-web applications.

The It's true that you can use Dawn and wgpu from native code but that's all outside the spec.

There is mention of desktop applications in their getting-started docs; it seems well within the intention of the maintainers to me.

https://eliemichel.github.io/LearnWebGPU/introduction.html

> Yeah, why in the world would I use a web API to develop a desktop application?

> Glad you asked, the short answer is:

    Reasonable level of abstraction

    Good performance

    Cross-platform

    Standard enough

    Future-proof

This is an indie site. Nothing wrong with it but it's not canon.

And yet Electron exists…

The intent and the application are never squarely joined. Yes it’s made for the web. However, it’s an API for graphics. If you need graphics, and you want to run anywhere that a web page could run, it’s a great choice.

If you want to roll your own abstraction over Vulkan, Metal, DX12, Legacy OpenGL, Legacy DX11, Mesa - be my guest.

You mentioned "Google" and Firefox, one of which is a browser. I clarified that I'm not interested in the web as a target, not to dismiss your entire suggestion but rather to clarify that that particular part doesn't interest me.

I like OpenGL ES but the support for compute shaders sucks. I hate transform feedbacks. I am in the process of trying out WebGPU now, but it doesn't have good native support everywhere like OpenGL ES 3 does.

OpenGL is designed-by-committee state-machine crap.

You don't know it yet, but what you really want is DirectX 9/10/11.

Maybe, but Microsoft tech feels icky

SDL GPU, not SDL. The GPU project is a generic wrapper/abstraction on top of the modern GPU APIs, such as Vulkan. You do all the same stuff as you would in a modern GPU API, except in a generic / slightly more accessible way.

In practice SDL is used to abstract away the system-dependent parts required to set up OpenGL.

Reply on news.ycombinator.com