SDL_gpu API example

[bovacu]

Hi, now that SDL_gpu new API is out, I was wondering if there will be a new example (in the examples folder) implementing this new API.

Thanks!

[riri]

I doubt it, but PR are welcome ;-)

[bovacu]

Hi, thanks! I will definitely take a look at this when I get some time and try to make that PR

[orosbogdan]

Any news on this?

[sleeptightAnsiC]

IHMO, this would be way too much for Nuklear demo/example, hear me out.

SDL_gpu expects that you pass your own shaders in binary form, which is different per platform/backend. You can read more about this problem here: https://moonside.games/posts/layers-all-the-way-down/

So in order to implement SDL_gpu demo/example, we would have to provide multiple binary blobs (or embed them into source code with xxd) or create dependency on something like SDL_shadercross, which is extremely complex IMO.

Don't get me wrong, I'm not saying "no", I just feel like this would cause more harm than actually help anyone. A lot of people does not seem to understand the real implications of this new API, it's nothing like SDL_renderer, not a silver bullet like some may think.

For anyone who wants to implement this: you can take a look at how imgui solved it, here: ocornut/imgui#8163 Per these instructions, they used HLSL for human-readable shader code, then compiled it into SPIRV blobs, then recompiled the blobs yet again for appropriate platform, then packed the blobs into headers with xxd-like utility. So the end-user does not have to do this on its own, but there is no way to easily change the shaders, which in my opinion breaks the idea of example that is expected to be easy to modify.

[ompadu]

IHMO, this would be way too much for Nuklear demo/example, hear me out.

SDL_gpu expects that you pass your own shaders in binary form, which is different per platform/backend. You can read more about this problem here: https://moonside.games/posts/layers-all-the-way-down/

So in order to implement SDL_gpu demo/example, we would have to provide multiple binary blobs (or embed them into source code with xxd) or create dependency on something like SDL_shadercross, which is extremely complex IMO.

Don't get me wrong, I'm not saying "no", I just feel like this would cause more harm than actually help anyone. A lot of people does not seem to understand the real implications of this new API, it's nothing like SDL_renderer, not a silver bullet like some may think.

For anyone who wants to implement this: you can take a look at how imgui solved it, here: ocornut/imgui#8163 Per these instructions, they used HLSL for human-readable shader code, then compiled it into SPIRV blobs, then recompiled the blobs yet again for appropriate platform, then packed the blobs into headers with xxd-like utility. So the end-user does not have to do this on its own, but there is no way to easily change the shaders, which in my opinion breaks the idea of example that is expected to be easy to modify.

for the people interested in using sdl_gpu with nuklear is way worse to have them write their own backend from scratch compared to going through the hoops of building shaders.

also please consider that anyone developing with sdl_gpu has already jumped through all the hoops of building the shaders.

[sleeptightAnsiC]

for the people interested in using sdl_gpu with nuklear is way worse to have them write their own backend from scratch compared to going through the hoops of building shaders.

I know this may not be exactly what you want here, but for people who just want to get Nuklear running in SDL_gpu'based project: you can try using demo/sdl3_renderer and create an off-screen Renderer with SDL_CreateGPURenderer. This should give you SDL_gpu'compatible Texture that you could apply to your main Window backbuffer. I haven't tested this approach yet but it seems possible. Ofcourse this is not great because dedicated nk_sdl3_gpu demo would be more optimized and straight forward to use, but I hope you get my point.

If anyone here already tried it, please let me know how it went.

I might take a look into implementing nk_sdl3_gpu demo someday.

[sleeptightAnsiC]

Few implementation notes

CLICK ME

dx11, dx12 and vulkan demos also faced this problem so we can steal borrow few ideas from those:

dx11/12:

• one hlsl source (for both FS and VS, you decide which one you want with entry point)
• compiled with FXC into headers with byte arrays (FXC can do this on its own with /Fh, but SDL_shadercross cannot, I think, but I might be mistaken)
• there is a decompiled bytecode in the comments (I believe /Fh does this by default)
• headers are checked into repo
• no Makefile, so the build step invokes FXC each time
• keeping both shaders in one source file might be confusing, but the rest is very straight forward and easy to understand

vulkan:

• two glsl sources
• compiled with GLSLC into spirv blobs
• spirv is embedded into header with XXD and AWK. This step uses "input" header (.in.h) before turning it into the final one
• spirv is NOT checked, but the final header is
• two separate Makefiles, one for generating spirv and header, another one for compiling the demo
• multiple duplicated files in multiple directories and several build steps, which is super confusing...

The dx11/12 demo approach is really nice, but this is because FXC does all required steps on its own.

The vulkan demo approach is way too complicated IMO. There is no need for duplicating files all over the place. Embedding the arrays into the header is also questionable. It could probably avoid the use of AWK.

For sdlgpu demo, it would be "really bad" to follow the approach of the vulkan demo, especially because we need different shader blobs for each platform, which would skyrocket the complexity. If only SDL_shadercross had a switch similar to FXC /Fh, it would help us A LOT.