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_swapchain extension is available, vkCreateSwapchainKHR will definitly be found by libdl?)
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.
Specifics: https://github.com/KhronosGroup/Vulkan-Loader/blob/main/docs/LoaderApplicationInterface.md#wsi-extensions
Related
I'm probably way out of the loop, but it seems weird to use a native look GUI library and then - if you're not using wxGTK - shoehorn in a text renderer from a different GUI library. What's the deal here?
I think I understand your point. Using GTK (and Pango Cairo) on Windows, by telling wxWidgets to use internally GTK seems duplicating window managers.
It's just a matter of taste. GTK in Windows does call Windows API to do windowing. But some users like the GTK-way for windows, menus, and other controls instead of the native Windows-way, and wxWidgets provides this feature (in addition, of course, of the native usage, keeping native look&feel).
Anyhow, GTK on Linux calls internaly X11 or Wayland for handling windows and menus. Do you also call this "duplicating"?
The question seems to stem from a mistaken assumption, so it's hard to answer it, let me rather explain how things really are instead:
Cairo-based wxGraphicsContext can be optionally used under MSW because this allows to produce exactly the same graphics output under all platforms, which can be important for some kinds of applications. However it is not used by default, you need to explicitly request it, and if you don't you'd be using GDI+ or Direct2D, both of which are perfectly native libraries.
First I wonder about some minor details to see if I understand some concepts properly:
Is vulkan-1.dll (or libvulkan.so.1 on Linux) what is referred to as the loader?
When I use HMODULE vulkan_module = LoadLibrary( "vulkan-1.dll" );, is this using the loader from the graphics driver (provided that the previous detail is true)?
Now to the actual question. It seems that the loader is responsible for pulling drivers together to have them seem as one "unit" of sorts, as well as collecting available extensions and validation layers. What then differs the LunarG loader (for example) from those provided by graphics drivers? Why would one want to use one over the other?
Vulkan drivers do not contain anything that would reasonably be called a "loader". They are "providers".
The purpose of a "loader" is to load what the "providers" provide. The most basic thing a loader does is find the implementations' DLLs and interact with them. This differs based on the platform. With Windows, they probably use registry settings to hunt down the implementation DLLs. On Android, their built-in support probably centralizes things. And so forth.
The only commonly used loader is LunarG's SDK loader (which does use the filename vulkan-1). Some have written their own, but LunarG's is the only one with widespread usage.
"the loader" or "official loader" or "Khronos loader" or "LunarG loader" or "VulkanRT" are AFAIK the same. It's from the project KhronosGroup/Vulkan-LoaderAndValidationLayers.
What differs (between those provided by the Khronos, LunarG SDK, and drivers) is usually only a version. (Typically LunarG SDK lags behind Khronos and driver lags behind both.)
More then you ever wanted to know of its inner workings is in the loader documentation.
Run-time dynamic linking as you propose should be possible (you would do the LoadLibrary() then GetProcAddress() the vkGetInstanceProcAddr() command and then rest from it).
(On Windows) I think most people use the convenient dll import library vulkan-1.lib from LnG SDK with whatever vulkan-1.dll is in the System32.
We'd like to offer a compiled library that implement a protocol layer to be imported into C/C++ source code project for microcontrollers. And eventually expose a sort of compiled function to the source code project. let's say a sort of "dll". Is there any know technique to realize something of similar?
While it is possible to provide functions via a library, generally in the microcontroller/embedded realm it quickly becomes impractical.
Each microcontroller core will have a unique instruction set. Further, micros from the same family may have a variety of extensions which are either supported or not... So you're left with providing a library file for each individual microcontroller (from each vendor) that you'd like to support.
But...
In my experience, calling conventions between compilers are not the same. So a library compiled by one toolchain will not be able to be linked to object files created by another toolchain.
That leads you to then provide a library for each individual micro from each vendor for each toolchain someone might use. Ick. Oh, and don't rely on an OS calls either, as you don't know what you'll be linked with...
A more conventional approach is to use the same approach RTOS vendors tend to use: provide the source, and protect your IP with licensing terms. The reality is that if your end users want to, they can step through the assembly and figure out exactly what is happening, so you're not hiding your implementation that carefully anyway.
loadstring() and loadfile() Lua functions allow loading remote libraries and modules at runtime. As shown in this post it is very simple: How Do I Load Lua Module as a String Instead of a File?
Unfortunately Corona SDK has removed both these function. Here's a list of changes they have.
Is it possible to implement loadstring in lua or load it from a separate module?
They seem to provide a solution here but I don't really understand it and I don't think it will work in Corona cause it requires dofile which is also disabled in Corona
http://lua-users.org/lists/lua-l/2012-04/msg00875.html
loadstring() and dofile() are disabled per Apple's rules for allowing interpreted language apps to work on their devices. Apple will reject any app that has any dynamic programming features.
OK, this is basically just about any non-default OS API running on all different OS. But for my example let´s consider platform Windows, API SDL (Simple DirectMedia Layer).
Actually this question came to my mind when I was reading about SDL. Originally, I thought that on Windows (and basically any other OS) you must use OS API to make certain actions, like writing to screen, creating window and so on, because that API knows what kernel calls and system subroutines calls it has to do. But when I read about SDL, I surprised me, because, you cannot make computer to do anything more than OS can, since you cannot access HW directly, only thru OS API, from Console allocation to DirectX.
So, my question actually is, how does this not-default-OS APIs work? Do they use (wrap) original system API (like MFC wraps win32 api)? Or, do they actually have direct access to Windows kernel? Or is there any third, way in between?
Indeed, SDL is a wrapper for OS-specific calls, although with many simplifications and convenience functions. On Windows, SDL uses DirectX.