libsdl-org
Remove Vulkan/Metal WindowFlags?
Something I did want to bring up: The window flags in SDL3 have been kind of a pain point for us; as far as I'm aware the only window flag that actually does anything is SDL_WINDOW_OPENGL since window creation has to know other things about the rendering context in advance, while the other flags are mostly just a "don't do the OpenGL stuff" flag, unless you count implicitly calling SDL_Vulkan_LoadLibrary which SDL_GPU could probably do on its own...
I kind of want to rip out the other window flags entirely to make using Vulkan/Metal/GPU easy like it currently is for D3D, is there any backend that would prevent us from doing that?
Originally posted by @flibitijibibo in https://github.com/libsdl-org/SDL/issues/9312#issuecomment-2081188059
I remember looking at this and concluding that we still needed those flags, but I don't remember the details.
It looks like METAL can be removed but VULKAN is still necessary, as you noted, to manage the Vulkan function loading, and for KMSDRM, to know whether we need non-Vulkan rendering support.
Understood - just to finalize that part then, I would definitely look at the GPU API's opening function calls; SelectBackend and CreateDevice are the two big ones. Without the flags we would be able to move everything into CreateDevice but if the flags are required then we'll need to keep those separate in order to give the application a chance to make the window correctly. If it seems okay we can just leave the flags how they are now!
How does CreateDevice handle the case of using OpenGL rendering with a window created without the OpenGL flag? Or is OpenGL even a thing now?
OpenGL isn't planned for GPU since thread safety would be pretty much impossible without requiring a GL spec that basically equates to having Vulkan support anyhow - but, if it was possible, that's where SelectBackend would be important:
Uint32 windowFlags = 0;
SDL_GpuBackend backend = SDL_GpuSelectBackend(SDL_GPU_BACKEND_ALL, &windowFlags);
windowFlags |= SDL_WINDOW_SHOWN;
SDL_Window *window = SDL_CreateWindow(NULL, 0, 0, windowFlags);
SDL_GpuDevice *device = SDL_GpuCreateDevice(0);
SDL_GpuClaimWindow(
device,
window,
SDL_GPU_PRESENTMODE_FIFO,
SDL_GPU_TEXTUREFORMAT_R8G8B8A8,
SDL_GPU_COLORSPACE_LINEAR_SRGB
);
/* Cool stuff go here */
SDL_GpuDestroyDevice(device);
SDL_DestroyWindow(window);
The trouble usually starts between SelectBackend and CreateDevice; it's basically just a static variable that we have to carry around and there aren't really any rules as to how/when it gets called other than that it may return useful window flags; everything else could be in CreateDevice otherwise.
Yeah, it seems reasonable for you to remove the window flag dependency and always load/unload Vulkan yourself if you use it. There should be no reason you need to have the window created with the Vulkan or metal flags if you do that.
Understood - I guess with that in mind my only other question is this: Do we want to explicitly define what happens when no API flags are passed to SDL_CreateWindow? I'm mostly thinking of macOS where I believe at one point it defaulted to one API or the other and it would just add the flag during window creation (or was it when creating a View?).
In the meantime I'll go ahead and squish those two functions down and strip out the window flag stuff entirely!
No, I don't think so, but you can use the window flags that the window was created with as a hint for which backend to use?
GPU changes have been pushed: https://github.com/libsdl-org/SDL/compare/d55b4fafbaa3374ff2ab84157075d55a2d2b5d22..07d219fdb0520198d974105e1b8e5dea2c829c58
I ended up copying what Dan did for SDL_Render: we grab the VideoDevice directly and ignore the window flags entirely.
The window flag as a hint could be useful for SDL_Render but one interesting detail with GPU is that we're trying to support multiple windows for a single GPU instance by default, so the window surface doesn't actually become a part of the equation until after the device is created; GpuClaimWindow creates swapchains later in the API flow.
I think we're going to keep the flags, since we need them in a few non-GPU bits of the library.
