英文:
Why are some Vulkan extensions available through dynamic linking, but not others?
问题
- 为什么某些Vulkan扩展支持动态链接而其他一些不支持？
- 我可以依赖于这些可以动态链接的扩展始终存在吗？（例如，如果
VK_KHR_swapchain扩展可用，我可以确定vkCreateSwapchainKHR将始终在libdl中找到吗？）
英文:
I've been trying to write Vulkan bindings for a language and I'm a bit confused about how extensions work. On Linux I'm using libdl to load function pointers from libvulkan.so.1, and I've noticed that some extension functions (like those from VK_KHR_swapchain and VK_KHR_Wayland_Surface) can be linked through libdl, but others (like the ones in VK_EXT_debug_utils or VK_EXT_extended_dynamic_state2) can only be found through vkGetInstanceProcAddr or vkGetDeviceProcAddr.
My questions are these:
- Why are some Vulkan extensions available through dynamic linking but not others?
- Can I rely on these dynamically-linkable extensions always being there? (For example, can I be sure that if the
VK_KHR_swapchainextension is available,vkCreateSwapchainKHRwill definitly be found by libdl?)
答案1
得分: 2
TFM:
Vulkan直接导出
在Windows、Linux、Android和macOS上，加载程序库将导出所有核心Vulkan入口点和所有适当的窗口系统接口（WSI）入口点。这样做是为了让Vulkan开发更加简单。当应用程序以这种方式直接链接到加载程序库时，Vulkan调用只是简单的跳板函数，它们会跳转到给定对象的适当调度表条目。
具体细节：https://github.com/KhronosGroup/Vulkan-Loader/blob/main/docs/LoaderApplicationInterface.md#wsi-extensions
英文:
TFM:
> ## Vulkan Direct Exports
>
> The loader library on Windows, Linux, Android, and macOS will export all core Vulkan entry-points and all appropriate Window System Interface (WSI) entry-points. This is done to make it simpler to get started with Vulkan development. When an application links directly to the loader library in this way, the Vulkan calls are simple trampoline functions that jump to the appropriate dispatch table entry for the object they are given.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论