SDL_GPU.h

SDL Development
21

AFAIK SDL having its own shader language has been ditched. @icculus’s entire SDL GPU system was ditched in favor of one supplied by the FNA developers.

You can use the SDL shadercross header + the SPIRV-Cross library to generate shaders at runtime.

Not personally a fan of having to pull in SPIRV-Cross (either as a build step or a runtime library) or resort to writing different shaders for every possible backend, but that’s how that particular cookie crumbled (at least for now) :man_shrugging:

1 Like
22

I hope there’s away to get this delay reduced, probably I’m just missing something fundamental?

The tradeoff with presentation is always latency vs screen tearing, unless you are using MAILBOX mode. We currently allow 3 frames to be in flight before blocking in vsync mode. This gives good throughput but as you have noted the tradeoff is visual delay. I’m planning to add a property to make this number configurable, but know that the lower you set it, the worse the framerate will be on weaker GPUs.

1 Like
23

Thank you! I think it would be nice to be able to adjust that per app. You mention the impact on weaker hardware, but it would also depend on the complexity of the scene, so it would make sense that apps with less fidelity can opt in to less latency at the same time. Curious tho, when you say weaker GPUs, is there a lower limit for what SDL_GPU will support? Does it support integrated intel gpus for instance?

24

Yeah for certain apps it would be perfectly fine to make that tradeoff.

The lower limit for support on desktop Linux is basically anything that has a Vulkan 1.0 driver. On Windows we support Direct3D 11 as a backend for legacy devices. On Android it gets more complicated because the feature support on some devices is extremely bad.

1 Like
25

For me it runs with the Intel GPU.

1 Like
26

Not ditched, I’ve just busy on other SDL3 tasks. It will slot into the existing GPU API when it’s ready as a new bytecode format, but existing bytecode formats will also continue to be accepted.

Allowing other formats was a necessity, not just because the new bytecode format wasn’t ready yet, but also because being able to use what you want and like is a general good in any case.

But I do think moving away from the current multi-format shader tapdance will be a big quality of life improvement for developers, so it’s still important to me to get this finished.

4 Likes
27

That’s good to hear, for me having a unified shader bytecode format (and hopefully a shader language targeting it with a compiler that doesn’t drag in tons of dependencies) was one of the biggest features of the GPU API over many other 3D API abstractions (like sokol_gfx)

1 Like
28

Thanks for the update @icculus and @sjr.

I managed to get the current workflow working (based on SDL shader cross and the SPIRV-Cross library) though it is quite messy indeed. Looking forward to your alternative @icculus!

29

Wouldn’t this have been an idea if SDL_GPU was a separate package, like SDL_mix, SDL_images, etc.?

SDL_GPU is quite a complex thing. And many SDL users will never use it. For beginners, the renderer is enough and professional programs use OpenGL or Vulkan.

30
  1. It already exists and is already part of the SDL source code. Too late to split it out now.
  2. It being part of SDL directly means the 2D accelerated renderer now uses SDL GPU. The boatload of separate renderer backends are still there, but SDL GPU is now the default on platforms it supports.
  3. Paired with #2, it opens the possibility of the 2D renderer one day having official support for letting developers supply their own shaders.
1 Like
31

Then of course it makes sense if it is also needed for 2D.

32

same here, I successfully ported my gl4.6+glsl rendering code to SDL3 + GPU on Metal, using a mix of glslang et SPIRV Cross. I had to give up on uniforms though, as I had a problem with the binding number assignment with Metal… This was a non-issue with my multi draw indirect path…
I have a few remaining features to port, but I think it’ll be ok.

Waiting for WebGPU backend to show up now :slight_smile:

Thanks to the whole SDL team for this work!

33

Let’s see how long it takes until WebGPU comes out of Chrome’s beta phase.

34

I haven’t looked at the gpu, is there a tutorial I could look at in specific? I only need 2d so I don’t think I will have any goals with this

35

There aren’t any tutorials that I’m aware of, but SDL comes with two examples in the source code’s test directory, and there are some sample programs that demonstrate various aspects of the API.

36

I haven’t looked at the gpu, is there a tutorial I could look at in specific? I only need 2d so I don’t think I will have any goals with this

Here you can see the first steps:

37

I have a few remaining features to port, but I think it’ll be ok

well… I might have found a problem: stencil operations can be set with SDL_BeginGPURenderPass , but is it possible to change them while rendering? If so, how?

38

The SDL_GPURenderPass object just contains what stencil and/or depth buffer to use (if any), the load/store op, and what their clear value should be.

You change whether or not to use the stencil buffer, what compare function, etc., with the SDL_GraphicsPipeline object.

The example demos have a demo showing how to use the stencil buffer in BasicStencil.c

39

Thank you @sjr!

yes I figured I needed to create several pipelines, which I did (and I saw BasicStencil.c). I’m still struggling to make stencil work on my mac though, I still haven’t figured out how to successively bind different pipelines…

40

Just bind the pipeline, bind whatever buffers, samplers, and textures it needs, issue your draw calls for that pipeline, bind the next pipeline, whatever buffers etc it needs, do the draw calls for that pipeline, etc.

You don’t need to create a new render pass for each one or anything like that.