sokol_app vulkan

[pplux]

sokol_app is an extraordinary library, I'm using it with my own render implementation all the time. I have plans to switch to vulkan and I was wondering if you plan to add support for vulkan (not the gfx part, just the app/context) or if you will be willing to accept PR's working towards that goal.

As said, not asking for #285 , just the sokol_app part.

[floooh]

Hmm, not a fan of the idea for at least two reasons:

• the Vulkan setup wouldn't be some isolated chunk of code, but instead needs to be implemented inside the existing platform backends which support Vulkan (Win32, Linux, Android, possibly macOS), that's a lot of "disruption" for the existing code
• without a Vulkan backend in sokol_gfx.h, the Vulkan code in sokol_app.h would "just sit there" without tests and samples using that code

Once it makes sense to remove all OpenGL backends (for instance because of bitrot in OpenGL implementations) I'll be most likely more in favour of the idea, because this would mean ripping out some big and ugly code. Vulkan would probably be more code, but definitely not as ugly as the GL code. But that's not anytime soon I think.

There's also a big change in (very slow) progress implementing multiwindow support for sokol_app.h, so currently isn't a good time to do big PRs anyway I'm afraid.

[pplux]

Thanks! I will stick to glfw meanwhile :)

[cshenton]

So for anyone else going down this path, I've had good results so far with just not defining a graphics API, then commenting out the bits of sokol_app.h that complained (the preprocessor errors and the corresponding function calls to undefined methods).

That so far has enabled me to rely on sokol to handle the window creation, etc., and I just used sapp_win32_get_hwnd to get the information I needed to create a VkSurface on my platform.

I might be in a minefield though. Time will tell 😆

[pplux]

I've done something similar for manual webgpu, and it also worked... so it might be worth giving a try? Maybe it could be a sokol_app with no backend and let the user deal with the specifics for vulkan/webgpu/anything else....

[floooh]

Just some additional thoughts, in case this will ever become an "official feature":

• a SOKOL_NO_BACKEND define (instead of SOKOL_D3D11 etc...)
• a couple new 'custom backend' callbacks defined in sapp_desc (I think that's more robust than doing the device/context and swapchain setup in the regular frame callbacks, especially if I should continue one day with the stalled multi-window experiments):

    .backend = {
        .setup_cb = ..., // this would create the 3D device/context and the swapchain
        .discard_cb = ..., // destroy the swapchain and device/context
        .resize_cb = ..., // called when the swapchain needs resizing
        .present_cb = ..., // called when the swapchain should perform a present
        // any more?
        .user_data = ...,
    }

[mr-sihc]

how far did this go in the time?
i mean pretty much anything uses vulkan nowdays
so, this would probably be a very good thing!

how far is it/ if at all?

[floooh]

No plans for Vulkan support anytime soon, sorry. Next is a WebGPU backend, then at some later pointer when GL is no longer relevant and Vulkan is robust enough on Android, there might be a Vulkan backend replacing the GL backend. But TBH, at that point (with GL no longer defining the minimal feature set), it probably makes more sense to start thinking about a sokol-gfx successor.

If it's just about a 3D-API agnostic sokol_app.h, currently no plans either (GLFW might be the better option).