freedesktop-sdk VS Vulkan-Loader

I think I might have confused two unrelated posts. The one that references Polar Signals is this one:

https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/issues/...

So not a perf issue there, but they don't think the workflow is suitable for whole-system profiling. Perf issues were in the context of `perf` using DWARF:

https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/issues/...

But the fd-sdk https://gitlab.com/freedesktop-sdk/freedesktop-sdk and gnome build meta https://gitlab.gnome.org/GNOME/gnome-build-meta projects can prove as good references.

With all of these hypothetical features out of the way and looking just at current release software, Flatpak allows you to do so much stuff that isn't accessible for a not-so-techy user. Custom installation folder? Yep. Running mesa-git GPU drivers? You got it. Any way to easily do this via GUI? In typical Linux fashion, nope. For a GUI focused packaging format this is a big letdown.

Link to (official?) how-to: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/wikis/Mesa-git

You can load up Mesa GIT using environment variables, see here. Honestly what I miss the most from flatpak Steam is properly working non-Steam shortcuts, but I've given up on that.

It was my understanding that the packages for vaapi are just put into the -extra version of the sdk so app maintainers can opt out, but they are still available if they want to use them. See https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/merge_requests/10616

Take a look at Vulkan Loader Debugging, try running vulkaninfo with set VK_LOADER_DEBUG=all.

probably not given this response from 2021 https://github.com/KhronosGroup/Vulkan-Loader/issues/536

Every program that needs Vulkan does indeed link against and call something with a well-known, long-time stable ABI. This is normally Vulkan-Loader, which provides libvulkan. For OpenGL, libglvnd is a nearly equivalent library that fulfills largely the same function and provides libGL/libGLES/etc.

cmake_minimum_required(VERSION 3.8) include(FetchContent) project(foo LANGUAGES C CXX) # Vulkan FetchContent_Declare( Vulkan-Headers GIT_REPOSITORY "https://github.com/KhronosGroup/Vulkan-Headers.git" GIT_TAG "sdk-1.3.216.0" ) FetchContent_MakeAvailable(Vulkan-Headers) FetchContent_Declare( Vulkan-Loader GIT_REPOSITORY "https://github.com/KhronosGroup/Vulkan-Loader.git" GIT_TAG "sdk-1.3.216.0" ) set(UPDATE_DEPS OFF CACHE INTERNAL "") set(BUILD_TESTS OFF CACHE INTERNAL "") FetchContent_MakeAvailable(Vulkan-Headers Vulkan-Loader) add_executable(dummy "main.cc") set_target_properties( ${PROJECT_NAME} PROPERTIES CXX_STANDARD 17 CXX_STANDARD_REQUIRED ON CXX_EXTENSIONS OFF ) target_compile_options( ${PROJECT_NAME} PRIVATE $<$: /ZI; > ) target_link_libraries( ${PROJECT_NAME} PRIVATE Vulkan::Vulkan )

I'm reading through the official docs before I start a tutorial. The docs mention the loader but not very often. It does link to the loader's docs on github. I've read most of that. I still don't understand if it's an integral part of the API or just a tooling for certain use cases (multiple drivers, complex validation, etc.). I also listened to a webinar about the loader and the speaker claims he is the owner of the loader. That made me even more confused. Can someone please fill me in? Do all Vulkan apps interface with the loader before the driver? Thanks.

It's from here: https://github.com/KhronosGroup/Vulkan-Loader/blob/393e23f91d21ce117c19e8c42e084477c3a25c7c/tests/framework/test_util.h

Not exactly sure, but what you describe seems similar to the issue https://github.com/KhronosGroup/Vulkan-Loader/issues/776 .

This would be good to read to understand why some of the things are the way they are. https://github.com/KhronosGroup/Vulkan-Loader/blob/master/docs/LoaderApplicationInterface.md