Skip to content

Conversation

@charles-lunarg
Copy link
Owner

Queries and propagates all of the required function pointers into each struct that needs it, removing the need for a global function/variable to store the loaded vulkan functions.

This does require changing the API of the SwapchainBuilder constructor which takes Vulkan handles directly to include the VkInstance, since otherwise it is impossible to load the required functions.

Queries and propagates all of the required function pointers into each struct
that needs it, removing the need for a global function/variable to store the
loaded vulkan functions.

This does require changing the API of the SwapchainBuilder constructor which
takes Vulkan handles directly to include the VkInstance, since otherwise it is
impossible to load the required functions.
@th3or14
Copy link
Contributor

th3or14 commented Nov 15, 2025

Shouldn't VulkanLibrary have a destructor with calling at least unload_vulkan_library() inside?

@charles-lunarg
Copy link
Owner Author

charles-lunarg commented Nov 15, 2025

Shouldn't VulkanLibrary have a destructor with calling at least unload_vulkan_library() inside?

No because that would break all of the function pointers that have been loaded. Vk-bootstrap never bothered to clean up the libvulkan handle before, and because of the nature of the vkb:: objects not doing any destruction of vulkan objects, making apps keep their vkb:: objects alive would be a breaking change.

I do admit this isn't ideal and leaking dynamic libraries isn't great, but its the corner I've gotten myself into.

@th3or14
Copy link
Contributor

th3or14 commented Nov 19, 2025

What do you think about #442?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants