Re: [OE-core] [PATCH] vulkan-loader: Move libvulkan.so to main package
Got it, thank you Ross!
-Original Message-
From: Ross Burton
Sent: Tuesday, October 18, 2022 4:52 AM
To: Tom Hochstein
Cc: Martin Jansa ;
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 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%23L142data=05%7C01%7Ctom.hochstein%40nxp.com%7C9c135c0d4b16464e586208dab0ee669d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638016835220670988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=D5UDy3Fd%2F%2Fq8Hby31cqj4vxn2g8anMNBTZJJMbBdVHo%3Dreserved=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-L257data=05%7C01%7Ctom.hochstein%40nxp.com%7C9c135c0d4b16464e586208dab0ee669d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638016835220670988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=fNOFnmZUbDGZAXGgU5Cq5N4cKmRBgLA7Od7FXcGXpLY%3Dreserved=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%23L25data=05%7C01%7Ctom.hochstein%40nxp.com%7C9c135c0d4b16464e586208dab0ee669d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638016835220827298%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=mlM7Mr%2FEt9LTalhmHo5Js1UliBABxqpkXHC4V8KfUUk%3Dreserved=0
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FKhronosGroup%2FVulkan-Tools%2Fblob%2Fmaster%2Fscripts%2Fgenerate_vulkan_wrapper.py%23L2043data=05%7C01%7Ctom.hochstein%40nxp.com%7C9c135c0d4b16464e586208dab0ee669d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638016835220827298%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=PqV8hitdAseUDE4BnKeqvwOT0B9iQ03h77LCzJbxLj8%3Dreserved=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.htmldata=05%7C01%7Ctom.hochstein%40nxp.com%7C9c135c0d4b16464e586208dab0ee669d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638016835220827298%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=mZURlOcefEkwdI0VUUUi8i3M8zdvZGXVNsg6I75VfyU%3Dreserved=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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171939):
https://lists.openembedded.org/g/openembedded-core/message/171939
Mute This Topic: ht
Re: [OE-core] [PATCH] vulkan-loader: Move libvulkan.so to main package
On 17 Oct 2022, at 17:12, Tom Hochstein 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 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171937): https://lists.openembedded.org/g/openembedded-core/message/171937 Mute This Topic: https://lists.openembedded.org/mt/94372555/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] vulkan-loader: Move libvulkan.so to main package
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 Sent: Monday, October 17, 2022 7:29 AM To: Ross Burton Cc: Tom Hochstein ; 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 mailto:ross.bur...@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=05%7C01%7Ctom.hochstein%40nxp.com%7Cb79ae30157f142e2468e08dab03b378b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638016065621027269%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=ldUoyzxYOQMI33kzqUh9CJ15MGI2n0YRf8rwKopwkJw%3D=0> mailto:nxp@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. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171915): https://lists.openembedded.org/g/openembedded-core/message/171915 Mute This Topic: https://lists.openembedded.org/mt/94372555/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] vulkan-loader: Move libvulkan.so to main package
On Mon, Oct 17, 2022 at 2:10 PM Ross Burton wrote: > On 16 Oct 2022, at 22:43, Tom Hochstein via 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. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171908): https://lists.openembedded.org/g/openembedded-core/message/171908 Mute This Topic: https://lists.openembedded.org/mt/94372555/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] vulkan-loader: Move libvulkan.so to main package
On 16 Oct 2022, at 22:43, Tom Hochstein via lists.openembedded.org wrote: > > Since libvulkan.so is commonly loaded dynamically, put it in the main > package. Can you give an example? Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171906): https://lists.openembedded.org/g/openembedded-core/message/171906 Mute This Topic: https://lists.openembedded.org/mt/94372555/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] vulkan-loader: Move libvulkan.so to main package
Since libvulkan.so is commonly loaded dynamically, put it in the main
package.
Signed-off-by: Tom Hochstein
---
meta/recipes-graphics/vulkan/vulkan-loader_1.3.216.0.bb | 5 +
1 file changed, 5 insertions(+)
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\d+(\.\d+)+)"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171900):
https://lists.openembedded.org/g/openembedded-core/message/171900
Mute This Topic: https://lists.openembedded.org/mt/94372555/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
