SDL_Vulkan_LoadLibrary(3)
π SDL_Vulkan_LoadLibrary(3) β the SDL3 functions era β¨
okay bestie, so this one lives in the SDL3 FUNCTIONS lineup and it's genuinely iconic if you're doing Vulkan stuff. buckle up π¦
β¨ NAME β¨
SDL_Vulkan_LoadLibrary β dynamically load the Vulkan loader library. that's it, that's the job π
π SYNOPSIS π
#include <SDL3/SDL_vulkan.h>
bool SDL_Vulkan_LoadLibrary(const char *path);
πΈ DESCRIPTION πΈ
okay so the vibe check here: call this after you've initialized the video driver, but before you create any Vulkan windows. timing is everything, no cap. β°
if no Vulkan loader library is loaded yet, the default library gets loaded for you automatically when the first Vulkan window is created. so like, the universe handles it, but only if you didn't already.
SDL keeps a whole counter of how many times this function has been successfully called, which means it is safe to call this multiple times β as long as you eventually pair it with an equivalent number of calls to SDL_Vulkan_UnloadLibrary. it's giving "we're keeping receipts" π§Ύβ¨
also the path argument is ignored unless there is no library currently loaded, and the library isn't actually unloaded until there have been an equivalent number of calls to SDL_Vulkan_UnloadLibrary. so yeah, the counter runs both directions, periodt.
it is fairly common for Vulkan applications to link with libvulkan instead of explicitly loading it at run time. this will totally work with SDL provided the application links to a dynamic library and both it and SDL use the same search path. matching energy only π«Ά
if you specify a non-NULL path, an application should retrieve all of the Vulkan functions it uses from the dynamic library using SDL_Vulkan_GetVkGetInstanceProcAddr β unless you can guarantee path points to the same vulkan loader library the application linked to. otherwise you're living dangerously and not in the cute way π
π Apple devices moment π
on Apple devices, if path is NULL, SDL will attempt to find the vkGetInstanceProcAddr address within all the Mach-O images of the current process. why? because it is fairly common for Vulkan applications to link with libvulkan (and historically MoltenVK was provided as a static library). nostalgia era π
if it is not found, on macOS, SDL will attempt to load these, in that order:
vulkan.framework/vulkanlibvulkan.1.dylibMoltenVK.framework/MoltenVKlibMoltenVK.dylib
on iOS, SDL will attempt to load libMoltenVK.dylib.
π¨ applications using a dynamic framework or .dylib must ensure it is included in its application bundle. do not skip this step bestie, it will not go well.
π non-Apple devices π
on non-Apple devices, application linking with a static libvulkan is not supported. like, at all. either do not link to the Vulkan loader, or link to a dynamic library version. pick one, choose your fighter π
β FUNCTION PARAMETERS β
pathβ the platform dependent Vulkan loader library name orNULL.
π RETURN VALUE π
returns true on success or false on failure. and when it fails? call SDL_GetError() for more information, she'll tell you everything π
π THREAD SAFETY π
this function is not thread safe. one at a time, bestie. no chaos gremlin behavior π
π§ AVAILABILITY π§
this function is available since SDL 3.2.0. so if you're on something older, sorry babe π
π₯ SEE ALSO π₯
and that's the whole page, you ate it up fr fr πβ¨
this one came to you courtesy of Simple Directmedia Layer β SDL 3.4.18 edition π¦ she's a keeper. mwah π
π¦ where this page comes from
- fedora 43: SDL3-devel 3.4.18-1.fc43 Β· Zlib AND MIT AND Apache-2.0 AND (Apache-2.0 OR MIT)
- fedora 43: SDL3-devel 3.4.18-1.fc43 Β· Zlib AND MIT AND Apache-2.0 AND (Apache-2.0 OR MIT)
- fedora 44: SDL3-devel 3.4.18-1.fc44 Β· Zlib AND MIT AND Apache-2.0 AND (Apache-2.0 OR MIT)
- fedora 44: SDL3-devel 3.4.18-1.fc44 Β· Zlib AND MIT AND Apache-2.0 AND (Apache-2.0 OR MIT)
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms