Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Renderer backend for the new SDL3 GPU API #7988

Open
lasagnaphil opened this issue Sep 15, 2024 · 6 comments
Open

Renderer backend for the new SDL3 GPU API #7988

lasagnaphil opened this issue Sep 15, 2024 · 6 comments
Labels

Comments

@lasagnaphil
Copy link

Version/Branch of Dear ImGui:

Version 1.91, Branch: master/docking

Back-ends:

imgui_impl_sdl3.cpp + (hypothetical) imgui_impl_sdlgpu3.cpp

Compiler, OS:

All platforms supporting SDL3 (ideally)

Full config/build information:

No response

Details:

My Issue/Question:

It would be useful to have an ImGui backend for the upcoming SDL3 GPU API (libsdl-org/SDL#9312). I'm opening a feature request to see if others are interested in it, and discuss on how I should go with this if I implement a PR!

SDL3 is currently in alpha status and its API is subject to change (especially its GPU API since it was merged only about two weeks ago). However we already have a platform backend for SDL3 (imgui_impl_sdl3.cpp) as well as a rendering backend that uses the 2D renderer (imgui_impl_sdlrenderer3.cpp), so why not! I think this would replace the existing 2D renderer backend for most users since I'm expecting it will have better performance, but we can always keep it as a simpler implementation for others to study.

I currently have a working renderer backend implementation that works only on Windows + Vulkan (not rigorously tested though), made for personal usage. So with a bit more polishing work I think I could open up a PR in the near future (around the time when the GPU API stabilizes enough!)

Though I'm expecting the main challenge for this would be shader compilation: For the Vulkan backend for SDL3 GPU, I can just use SPIR-V bytecode similar to how we do in Vulkan (compile GLSL into SPIR-V and embed them directly in C code). But I would also need to provide seperate shader bytecode for other platforms (DX12 and Metal, if we're aiming for full desktop compatibility), since the SDL3 GPU API is agnostic on the shader bytecode format. I'm currently thinking of two approaches:

  • Use SDL_gpu_shadercross, which is an single-file header library that does the work of converting SPIR-V into platform-specific shader formats. It's officially endorced by SDL3, until they develop a new shading language that can fix this platform-specific inconvenience.

  • Compile shaders for each platform separately and embed them in the source code, since the shaders are not going to change that much. For this I would probably need to investigate how the SDL project manages to do this for their 2D renderer (there's a shell script in the repo that automates this: https://github.com/libsdl-org/SDL/blob/main/src/render/gpu/shaders/build-shaders.sh)

Ideally I'm a fan of the former option since it's much more convenient to maintain, although adding a library for just a backend implementation seems a bit overkill (even if it's a single-file header library). If we go this path then we might need to let the user import this library from an external source (and gate it behind a preprocessor flag, so by default the backend will only support Vulkan)

Screenshots/Video:

No response

Minimal, Complete and Verifiable Example code:

No response

@lukaasm
Copy link
Contributor

lukaasm commented Sep 15, 2024

https://github.com/lukaasm/sdl3-gpu-imgui/blob/main/main.cpp

I am keeping somewhat up to date imgui render pass test implementation for SDL3 GPU ( Based on D3D11 shader compiler ) for my own purposes.

I believe SDL3 as a whole is nearing API "freeze/review" milestone soon

@lasagnaphil
Copy link
Author

@lukaasm Thanks for sharing, think this would be useful to implement the DX11/DX12 side of things!

We might need to get rid of the <d3dcompiler.h> dependency and pre-compile the HLSL shaders into DXIL though (like how we do with SPIR-V), since ideally we want no library dependency other than SDL3.

@ocornut
Copy link
Owner

ocornut commented Sep 17, 2024

Of course we will want a SDL GPU backend, but the shader situation you presented suggests that the API is not really ready for it yet?

What I would do is concatenate all of SDL_gpu_shadercross into a file called e.g. imgui_impl_sdlgpu3_shadercross.h and have our new imgui_impl_sdlgpu3.cpp use that.

@lasagnaphil
Copy link
Author

@ocornut Yup that might be the best solution for now... though I'm guessing some users would already be using this library in their codebases, so we might need a separate IMGUI_SDLGPU3_USE_EXTERNAL_SHADERCROSS preprocessor flag in order to allow users supply this dependency on their own. (Similar to how we are managing users to provide their own GL loader in imgui_impl_opengl3.cpp)

I currently have a fork at https://github.com/lasagnaphil/imgui/tree/sdl3-gpu (currently Windows + Vulkan is working with ./build_win32.bat) I'll start working on other backends (DX11/DX12/Metal) using this approach, and create a PR when it's ready!

image

@ocornut
Copy link
Owner

ocornut commented Sep 19, 2024

, so we might need a separate IMGUI_SDLGPU3_USE_EXTERNAL_SHADERCROSS preprocessor flag in order to allow users supply this dependency on their own. (Similar to how we are managing users to provide their own GL loader in imgui_impl_opengl3.cpp)

I'd prefer if we managed to move things into e.g. a dedicated namespace or made static, and not provide too many options until this settles. Note PR #7998

@Acclution
Copy link

Acclution commented Sep 19, 2024

Can disregard my PR if needed. Just slapped it together in one day without much planning. Will push the feedback fixes later anyway just for completions sake.

Edit: pushed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants