SDL_Gpu API, SDL 3.0 ... New cross-platform graphics API.

[Scott_Arm]

SDL 3.0 is out, or coming out, and it includes a new graphics API (SDL_Gpu). SDL is basically a cross platform SDK that's supposed to give you low-level access to hardware, like peripherals and now the GPU. How low? I'm not sure. It does NOT support ray tracing. Seems like it must be similar to vk3d-proton, so you write SDL_Gpu and it'll run on the native api of the platform (D3D, Metal, Vulkan). I'm not sure how much, or if it differs from bgfx, which is a cross-platform rendering library. The nice thing about SDL is it looks like it's supposed to target other hardware like peripherals, so maybe in combination with some other SDK you could easily make cross-platform games. I'm thinking something to handle file system, network or other OS-level tasks.

Add the SDL_GPU API · libsdl-org/SDL@2e7d5bb

Project Lead: Evan Hemsley <evan@moonside.games> Co-designer, Metal Port, Console Ports: Co-authored-by: Caleb Cornett <caleb.cornett@outlook.com> Production, QA, Debug: Co-authored...

github.com

GitHub - TheSpydog/SDL_gpu_examples: Example collection for the SDL_GPU API

Example collection for the SDL_GPU API. Contribute to TheSpydog/SDL_gpu_examples development by creating an account on GitHub.

github.com

GitHub - libsdl-org/SDL: Simple Directmedia Layer

Simple Directmedia Layer. Contribute to libsdl-org/SDL development by creating an account on GitHub.

github.com

Doesn't seem like SDL 3.0 is out yet, but could be interesting. I'm really interested to see how it works for beginners. I've thought about learning wgpu as a simpler programming model to get into graphics. This might actually be a better path if I wanted to make little games.

For graphics alone bgfx is a lot more mature.

GitHub - bkaradzic/bgfx: Cross-platform, graphics API agnostic, "Bring Your Own Engine/Framework" style rendering library.

Cross-platform, graphics API agnostic, "Bring Your Own Engine/Framework" style rendering library. - bkaradzic/bgfx

github.com

As an aside, I feel like vk3d-proton has sort of shown that you can get high-performance real-time translation of one graphics api to another, so a cross-platform api that translates to a "native" API at compile time should be close to "native" performance. Yah, there are going to be some limitations somewhere. But I kind of feel like maybe Vulkan is getting it wrong. Maybe Vulkan should have been an API that actually got translated to a real native GPU API like Glide. You write Vulkan and it gets translated into AMD, Nvidia, Intel native API. If it were open source, the GPU vendors could contribute their own updates to the back-end. Just a thought. Seems like it'd be easier than writing and maintaining d3d, vulkan and opengl drivers. Plus big game engines typically have an RHI that can target D3D, Vulkan, Metal, Playstation, Switch etc. Why not bake an RHI into the API.

Game->engine->engine-level RHI->engine-level "native" api implementation per platform ->driver per api (gpu vendor)
Game->engine->engine-level cross-platform API implementation ->API-level RHI -> API-level true native API implementation per vendor->native api driver (gpu vendor)

I guess shader languages become a problem, especially if each vendor wants their own ... but there are already a bunch so ... ?

 

[Lurkmass]

There's no way that SDL 3.0 is on the same abstraction level as VKD3D-proton since it has to target older APIs like D3D11. VKD3D-proton as a D3D12 to VK translation layer only works/performs well for ONE vendor (AMD) because of massive help from some corporation being able to closely develop a custom driver stack (AMDGPU/RADV) for it and the HW design nicely matches the fundamental design patterns of explicit APIs. The other vendors (Intel/NV) aren't well supported with VKD3D-proton since their drivers/compilers constantly crash and often hits the slow paths in their Vulkan drivers/hardware ...

IMO developers don't really need anything else outside of D3D12 (AAA PC/console games), Vulkan (mobile), or WebGPU (if the main audience is strictly adamant on needing a simpler interface and want official support for Apple platforms) depending on their case if they want to aim for cross-platform development ...

D3D12 and Vulkan with desktop graphics functionality extensions will get closer to each other in terms of functionality (for modern immediate mode graphics architectures) easing the driver maintenance burden between both. IHVs are potentially looking to retire OpenGL support sometime in the future within several years as is already somewhat the case for OpenGL ES with Google's ANGLE translation layer on some mobile devices. Fully featured desktop OpenGL emulation will get there eventually when translation layers are able to reach a point where all commercial/major/relevant software applications used through them functions on their own hardware/drivers with acceptable performance ...

 

[Dominik D]

SDL3_gpu is pretty cool, actually. I'm currently experimenting with it and for the most part it's a pleasure to use. Just like everything else SDL it's fairly low level so you have to build your own abstractions on top of it but it does the most tedious part competently: it unifies resource, shader, and pipeline management across multiple APIs. I can easily compile HLSL to DXIL, MSL, and SPIRV using SDL_shadercross (offline or online) and use the exact same SDL APIs to render stuff with D3D12, Metal, and Vulkan. The user experience is really good for what it is (a thin layer over multiple APIs).

Design is derived from pre-existing abstraction and driven by FNA and MoonWorks people. FNA is a cross-platform XNA re-implementation; sort of like MonoGame but kept up to date. There's a nice C# wrapper around SDL3 that FNA and Foster use/will use (Foster is an indie framework from the creators of Celeste) and this wrapper comes with even more QoL improvements and utilities. SDL3_gpu isn't designed to compete in the AAA+ space but nothing is stopping you from adding support for RT or mesh shaders. It's definitely less work than developing complete RHI from scratch.

As for "better" alternatives - I wouldn't touch bgfx with a ten foot pole given how unhinged its author has become. The Forge from ConfettiFX (company started by Wolfgang Engel) is in my view a better choice if you want something full-fledged (but also fairly complex). Especially given that it's used in multiple AAA cross-platform titles. Speaking of cross-platform: SDL3_gpu is already supporting gen 8 and 9 Xboxes as well as Switch which makes it so much more viable for AA/AA+ games.

//edit
I think it's also something people often forget but SDL comes with abstractions for things beyond graphics. Ignoring audio for a moment (you probably want to use WWise anyway) it has good input and I/O support (e.g. it deals pretty well with the concept of storage on a console). Like always it's pretty low level but it does abstract things you'd have to do yourself out nicely.