from Hacker News

SDL3 new GPU API merged

by caspar on 8/29/24, 11:04 PM with 122 comments

  • by caspar on 8/29/24, 11:16 PM

    SDL3 is still in preview, but the new GPU API is now merged into the main branch while SDL3 maintainers apply some final tweaks.

    As far as I understand: the new GPU API is notable because it should allow writing graphics code & shaders once and have it all work cross-platform (including on consoles) with minimal hassle - and previously that required Unity or Unreal, or your own custom solution.

    WebGPU/WGSL is a similar "cross-platform graphics stack" effort but as far as I know nobody has written console backends for it. (Meanwhile the SDL3 GPU API currently doesn't seem to support WebGPU as a backend.)

  • by quadhome on 8/29/24, 11:58 PM

  • by rudedogg on 8/30/24, 4:30 AM

    It's exciting to see how this all shakes out. Hopefully we end up with more options for building custom game engines and apps.

    I've been going down the Vulkan rabbit hole. It's been fun/enlightening to learn, but the nature of Vulkan makes progress feel slow. I think if SDL3 were available when I started, I would have happily went that route and have more to show for the amount of time I've invested.

  • by kvark on 8/31/24, 4:05 PM

    Time will tell if this API is usable. In particular, the way resource synchronization works, and object renaming. Time will tell if it will perform better than WebGPU or other abstractions. Time will tell if it remains small in the presence of driver bugs that need working around…

    I’m also sceptical about their new bytecode for a shading language. Parsing shaders at runtime was not a concern with WebGPU - it’s very fast. Even producing native shaders is fast [1]. It’s the pipeline creation that’s slow, and this bytecode wouldn’t help here.

    [1] http://kvark.github.io/naga/shader/2022/02/17/shader-transla...

  • by ivars on 8/30/24, 7:06 AM

    How did they managed to pull this off so quickly? Given how long WebGPU native is in development and still not finalized, you would think it will take SDL GPU API even longer because it supports more platforms.

  • by bartwe on 8/30/24, 7:34 AM

    Glad to have contributed to the dx12 part :)

  • by Ono-Sendai on 8/30/24, 6:54 AM

    I might try this out. SDL I have found to be high quality software - compiles fast, compiles easily on multiple platforms, always works. So I have some hopes for this new API.

  • by JKCalhoun on 8/30/24, 5:13 PM

    Huge fan of SDL generally.

    When I went looking for a cross-platform gaming library, SDL and its API struck the right balance for me. I just wanted a C (++) library I could call to create windows and graphical contexts — a fast sprite rendering framework. I didn't need a whole IDE or a bloated library, didn't want to learn a new language, etc.

  • by immibis on 8/30/24, 12:43 AM

    Feels like SDL3 suffers the second system effect. (SDL2 was just SDL1 with explicit window handles, so SDL3 is the second system, not the third). SDL1/2 is a thin layer that wraps the platform-specific boilerplate of opening a window and handling input events, so you can get to the OpenGL rendering stuff that you actually wanted to write.

  • by jb1991 on 8/30/24, 5:19 AM

    I’ve never used this library before, but I’m very interested to see some examples of its cross-platform GPU compute abilities, if I understand from the link thread that they are now available. Does anyone have a suggestion on where to get started?

  • by JoeyJoJoJr on 8/30/24, 8:48 AM

    I’d love to see Raylib get an SDL GPU backend. I’d pick it up in a heartbeat.

  • by bni on 8/30/24, 5:32 AM

    Is this related to https://github.com/grimfang4/sdl-gpu ? Or is it a completely separate thing with the same name?

  • by davikr on 8/30/24, 12:30 AM

    Are there any examples?

  • by ammar-DLL on 8/30/24, 9:22 AM

    i'm looking forward to wayland native support

  • by kookamamie on 8/30/24, 10:06 AM

    Sorry, but the proposal for the included shading language looks pretty braindead to me.

    See for yourself: https://github.com/libsdl-org/SDL_shader_tools/blob/main/doc...

    Deviations from C-language families, such as "Flow control statements don't need parentheses." are completely unnecessary, I think. Same goes for "Flow control statements must use braces."