Hacker News new | ask | show | jobs
by thegrim33 206 days ago
SDL 3.0 introduced their GPU API a year or so ago, which is an abstraction layer on top of vulkan/others, might want to check it out.

Although after writing an entire engine with it, I ended up wanting more control, more perf, and to not be limited by the lowest common denominator limits of the various backends, and just ended up switching back to a Vulkan-based engine.

However, I took a lot of learnings from the SDL GPU code, such as their approach to synchronization, which was a pattern that solved a lot of problems for me in my Vulkan engine, and made things a lot easier/nicer to work with.

3 comments

I'm working with SDL GPU now, and while it's nice, it hasn't quite cracked the cross platform nut yet. You still need to maintain and load platform-specific shaders for each incompatible ecosystem, or you need a set of "source of truth" HLSL shaders that your build system processes into platform-specific shaders, through a set of disparate tools that you have to download from all over the place, that really should be one tool. I have high hopes for SDL_shadercross to one day become that tool.
I thought shaders just needed to be compiled to spir-v
My comment was specifically about cross-platform. Apple operating systems don't know what spir-v is.
Oh well sure if you're targeting apple as a platform you're gonna have to deal with their special snowflake graphics API
I wish Apple had made a point to support Vulkan. I know about MoltenVK and all that fun stuff, but for a time, there was a graphics API that worked on all of the major platforms: OpenGL.

Vulkan was meant to succeed OpenGL, and despite my annoyances with the API, I still think that it's nice to have an open standard for these things, but now there isn't any graphics API that works on everything.

SDL GPU is extremely disappointing in that it follows the Vulkan 1.0 model of static pipelines and rigid workflows. Using Vulkan 1.3 with a few extensions is actually far more ergonomic beyond a basic "Hello, World" than using SDL GPU.
That might exclude a lot of your user base. For example a big chunk of Android users, or Linux workstation users in enterprise settings who are on older LTS distributions.
SDL GPU doesn't properly support Android anyways due to driver issues, and I doubt anyone's playing games on enterprise workstations.
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.

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 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.