| Message ID | 20221016214357.596913-1-tom.hochstein@nxp.com |
|---|---|
| State | New |
| Headers | show |
| Series | vulkan-loader: Move libvulkan.so to main package | expand |
On 16 Oct 2022, at 22:43, Tom Hochstein via lists.openembedded.org <tom.hochstein=nxp.com@lists.openembedded.org> wrote: > > Since libvulkan.so is commonly loaded dynamically, put it in the main > package. Can you give an example? Ross
On Mon, Oct 17, 2022 at 2:10 PM Ross Burton <ross.burton@arm.com> wrote: > On 16 Oct 2022, at 22:43, Tom Hochstein via lists.openembedded.org > <tom.hochstein=nxp.com@lists.openembedded.org> wrote: > > > > Since libvulkan.so is commonly loaded dynamically, put it in the main > > package. > > Can you give an example? > I'm wondering the same, because e.g. tensorflow-lite. arm-compute-library were also trying to dlopen libOpenCL.so and we've patched them to dlopen libOpenCL.so.1 instead, so why should libvulkan.so be different.
I found a few examples online for both ways. In SaschaWillems examples, .so is used: https://github.com/SaschaWillems/Vulkan/blob/master/base/VulkanAndroid.cpp#L142 In Vulkan-Tools there's a mix. Here the implementation falls back to .so.1 if .so is not found: https://github.com/KhronosGroup/Vulkan-Tools/blob/master/vulkaninfo/vulkaninfo.h#L256-L257 While here only .so is used: https://github.com/KhronosGroup/Vulkan-Tools/blob/master/common/vulkan_wrapper.cpp#L25 https://github.com/KhronosGroup/Vulkan-Tools/blob/master/scripts/generate_vulkan_wrapper.py#L2043 With no consistency or guidance I'm not sure what the right solution is. At first I thought perhaps it is better for the caller to be more specific so that a compatibility problem is detected with a dlopen failure. Complicating that, though, is that vulkan-loader 1.2 is not compatible with 1.3. Plus why does Vulkan-Tools use .so.1 second? Probably to get around the fact that the .so is in the dev package? Is it possible and/or reasonable for a binary to load the .so then check the version and handle that at runtime? If so, then including the .so in the main package makes sense. Or should the user in this case be expected to use RDEPENDS to install the .so? From: Martin Jansa <martin.jansa@gmail.com> Sent: Monday, October 17, 2022 7:29 AM To: Ross Burton <ross.burton@arm.com> Cc: Tom Hochstein <tom.hochstein@nxp.com>; openembedded-core@lists.openembedded.org Subject: Re: [OE-core] [PATCH] vulkan-loader: Move libvulkan.so to main package On Mon, Oct 17, 2022 at 2:10 PM Ross Burton <ross.burton@arm.com<mailto:ross.burton@arm.com>> wrote: On 16 Oct 2022, at 22:43, Tom Hochstein via lists.openembedded.org<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openembedded.org%2F&data=05%7C01%7Ctom.hochstein%40nxp.com%7Cb79ae30157f142e2468e08dab03b378b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638016065621027269%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ldUoyzxYOQMI33kzqUh9CJ15MGI2n0YRf8rwKopwkJw%3D&reserved=0> <tom.hochstein=nxp.com@lists.openembedded.org<mailto:nxp.com@lists.openembedded.org>> wrote: > > Since libvulkan.so is commonly loaded dynamically, put it in the main > package. Can you give an example? I'm wondering the same, because e.g. tensorflow-lite. arm-compute-library were also trying to dlopen libOpenCL.so and we've patched them to dlopen libOpenCL.so.1 instead, so why should libvulkan.so be different.
On 17 Oct 2022, at 17:12, Tom Hochstein <tom.hochstein@nxp.com> wrote: > > I found a few examples online for both ways. In SaschaWillems examples, .so is used: > > https://github.com/SaschaWillems/Vulkan/blob/master/base/VulkanAndroid.cpp#L142 > > In Vulkan-Tools there’s a mix. Here the implementation falls back to .so.1 if .so is not found: > > https://github.com/KhronosGroup/Vulkan-Tools/blob/master/vulkaninfo/vulkaninfo.h#L256-L257 > > While here only .so is used: > > https://github.com/KhronosGroup/Vulkan-Tools/blob/master/common/vulkan_wrapper.cpp#L25 > https://github.com/KhronosGroup/Vulkan-Tools/blob/master/scripts/generate_vulkan_wrapper.py#L2043 > > With no consistency or guidance I’m not sure what the right solution is. At first I thought perhaps it is better for the caller to be more specific so that a compatibility problem is detected with a dlopen failure. Complicating that, though, is that vulkan-loader 1.2 is not compatible with 1.3. Plus why does Vulkan-Tools use .so.1 second? Probably to get around the fact that the .so is in the dev package? I did some research. libvulkan.so* is the Vulkan Loader, which is responsible for finding the correct driver and bridging the application with the driver. As per the documentation at https://vulkan.lunarg.com/doc/sdk/1.3.224.1/linux/LoaderApplicationInterface.html, you can either directly dynamically link (-lvulkan to the compiler) to the loader , or indirectly link (dlopen()) to the loader. Quoting from the ABI Versioning section: “”" On Linux, applications that have a hard dependency on Vulkan should request linking to the unversioned name libvulkan.so in their build system. For example by importing the CMake target Vulkan::Vulkan or by using the output of pkg-config --cflags --libs vulkan as compiler flags. As usual for Linux libraries, the compiler and linker will resolve this to a dependency on the correct versioned SONAME, currently libvulkan.so.1. Linux applications that load Vulkan-Loader dynamically at runtime do not benefit from this mechanism, and should instead make sure to pass the versioned name such as libvulkan.so.1 to dlopen(), to ensure that they load a compatible version. “”” Applications which dlopen(“libvulkan.so”) without a version are broken and should be fixed. The vulkan tools doing exactly what the documentation says not to do is just embarrassing to be honest… So my position is that we don’t mess around with the vulkan-loader recipe, but instead fix the callers. Ross
Got it, thank you Ross! -----Original Message----- From: Ross Burton <Ross.Burton@arm.com> Sent: Tuesday, October 18, 2022 4:52 AM To: Tom Hochstein <tom.hochstein@nxp.com> Cc: Martin Jansa <martin.jansa@gmail.com>; openembedded-core@lists.openembedded.org Subject: Re: [OE-core] [PATCH] vulkan-loader: Move libvulkan.so to main package On 17 Oct 2022, at 17:12, Tom Hochstein <tom.hochstein@nxp.com> wrote: > > I found a few examples online for both ways. In SaschaWillems examples, .so is used: > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSaschaWillems%2FVulkan%2Fblob%2Fmaster%2Fbase%2FVulkanAndroid.cpp%23L142&data=05%7C01%7Ctom.hochstein%40nxp.com%7C9c135c0d4b16464e586208dab0ee669d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638016835220670988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=D5UDy3Fd%2F%2Fq8Hby31cqj4vxn2g8anMNBTZJJMbBdVHo%3D&reserved=0 > > In Vulkan-Tools there's a mix. Here the implementation falls back to .so.1 if .so is not found: > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FKhronosGroup%2FVulkan-Tools%2Fblob%2Fmaster%2Fvulkaninfo%2Fvulkaninfo.h%23L256-L257&data=05%7C01%7Ctom.hochstein%40nxp.com%7C9c135c0d4b16464e586208dab0ee669d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638016835220670988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=fNOFnmZUbDGZAXGgU5Cq5N4cKmRBgLA7Od7FXcGXpLY%3D&reserved=0 > > While here only .so is used: > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FKhronosGroup%2FVulkan-Tools%2Fblob%2Fmaster%2Fcommon%2Fvulkan_wrapper.cpp%23L25&data=05%7C01%7Ctom.hochstein%40nxp.com%7C9c135c0d4b16464e586208dab0ee669d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638016835220827298%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mlM7Mr%2FEt9LTalhmHo5Js1UliBABxqpkXHC4V8KfUUk%3D&reserved=0 > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FKhronosGroup%2FVulkan-Tools%2Fblob%2Fmaster%2Fscripts%2Fgenerate_vulkan_wrapper.py%23L2043&data=05%7C01%7Ctom.hochstein%40nxp.com%7C9c135c0d4b16464e586208dab0ee669d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638016835220827298%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=PqV8hitdAseUDE4BnKeqvwOT0B9iQ03h77LCzJbxLj8%3D&reserved=0 > > With no consistency or guidance I'm not sure what the right solution is. At first I thought perhaps it is better for the caller to be more specific so that a compatibility problem is detected with a dlopen failure. Complicating that, though, is that vulkan-loader 1.2 is not compatible with 1.3. Plus why does Vulkan-Tools use .so.1 second? Probably to get around the fact that the .so is in the dev package? I did some research. libvulkan.so* is the Vulkan Loader, which is responsible for finding the correct driver and bridging the application with the driver. As per the documentation at https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fvulkan.lunarg.com%2Fdoc%2Fsdk%2F1.3.224.1%2Flinux%2FLoaderApplicationInterface.html&data=05%7C01%7Ctom.hochstein%40nxp.com%7C9c135c0d4b16464e586208dab0ee669d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638016835220827298%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mZURlOcefEkwdI0VUUUi8i3M8zdvZGXVNsg6I75VfyU%3D&reserved=0, you can either directly dynamically link (-lvulkan to the compiler) to the loader , or indirectly link (dlopen()) to the loader. Quoting from the ABI Versioning section: """ On Linux, applications that have a hard dependency on Vulkan should request linking to the unversioned name libvulkan.so in their build system. For example by importing the CMake target Vulkan::Vulkan or by using the output of pkg-config --cflags --libs vulkan as compiler flags. As usual for Linux libraries, the compiler and linker will resolve this to a dependency on the correct versioned SONAME, currently libvulkan.so.1. Linux applications that load Vulkan-Loader dynamically at runtime do not benefit from this mechanism, and should instead make sure to pass the versioned name such as libvulkan.so.1 to dlopen(), to ensure that they load a compatible version. """ Applications which dlopen("libvulkan.so") without a version are broken and should be fixed. The vulkan tools doing exactly what the documentation says not to do is just embarrassing to be honest... So my position is that we don't mess around with the vulkan-loader recipe, but instead fix the callers. Ross
diff --git a/meta/recipes-graphics/vulkan/vulkan-loader_1.3.216.0.bb b/meta/recipes-graphics/vulkan/vulkan-loader_1.3.216.0.bb index 15a079879b..698ce112dc 100644 --- a/meta/recipes-graphics/vulkan/vulkan-loader_1.3.216.0.bb +++ b/meta/recipes-graphics/vulkan/vulkan-loader_1.3.216.0.bb @@ -35,6 +35,11 @@ PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'wayland x11', d)}" PACKAGECONFIG[x11] = "-DBUILD_WSI_XLIB_SUPPORT=ON -DBUILD_WSI_XCB_SUPPORT=ON, -DBUILD_WSI_XLIB_SUPPORT=OFF -DBUILD_WSI_XCB_SUPPORT=OFF, libxcb libx11 libxrandr" PACKAGECONFIG[wayland] = "-DBUILD_WSI_WAYLAND_SUPPORT=ON, -DBUILD_WSI_WAYLAND_SUPPORT=OFF, wayland" +# libvulkan.so is commonly loaded dynamically, so put it in the main package +SOLIBS = ".so*" +FILES_SOLIBSDEV = "" +INSANE_SKIP:${PN} += "dev-so" + RRECOMMENDS:${PN} = "mesa-vulkan-drivers" UPSTREAM_CHECK_GITTAGREGEX = "sdk-(?P<pver>\d+(\.\d+)+)"
Since libvulkan.so is commonly loaded dynamically, put it in the main package. Signed-off-by: Tom Hochstein <tom.hochstein@nxp.com> --- meta/recipes-graphics/vulkan/vulkan-loader_1.3.216.0.bb | 5 +++++ 1 file changed, 5 insertions(+)