Open lasagnaphil opened 2 months ago
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
@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.
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.
@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!
, 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
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
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 (https://github.com/libsdl-org/SDL/pull/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