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.
github.com
github.com
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.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 ... ?
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: WIP example collection for the SDL_Gpu API proposal
WIP example collection for the SDL_Gpu API proposal - TheSpydog/SDL_gpu_examples
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 ... ?
Last edited:
