Giter VIP home page Giter VIP logo

vulkan-loader's Introduction

Vulkan Loader

This project provides the Khronos official Vulkan Loader for all platforms except Android

Introduction

Vulkan is an explicit API, enabling direct control over how GPUs actually work. As such, Vulkan supports systems that have multiple GPUs, each running with a different driver, or ICD (Installable Client Driver). Vulkan also supports multiple global contexts (instances, in Vulkan terminology). The ICD loader is a library that is placed between a Vulkan application and any number of Vulkan drivers, in order to support multiple drivers and the instance-level functionality that works across these drivers. Additionally, the loader manages inserting Vulkan layer libraries, such as validation layers, between an application and the drivers.

This repository contains the Vulkan loader that is used for Linux, Windows, MacOS, and iOS. There is also a separate loader, maintained by Google, which is used on Android.

The following components are available in this repository:

Contact Information

Information for Developing or Contributing

Please see the CONTRIBUTING.md file in this repository for more details. Please see the GOVERNANCE.md file in this repository for repository management details.

How to Build and Run

BUILD.md includes directions for building all components.

Architecture and interface information for the loader is in docs/LoaderInterfaceArchitecture.md.

Version Tagging Scheme

Updates to this repository which correspond to a new Vulkan specification release are tagged using the following format: v<version> (e.g., v1.3.266).

Note: Marked version releases have undergone thorough testing but do not imply the same quality level as SDK tags. SDK tags follow the vulkan-sdk-<version>.<patch> format (e.g., vulkan-sdk-1.3.266.0).

This scheme was adopted following the 1.3.266 Vulkan specification release.

License

This work is released as open source under a Apache-style license from Khronos including a Khronos copyright.

Acknowledgements

While this project has been developed primarily by LunarG, Inc., there are many other companies and individuals making this possible: Valve Corporation, funding project development; Khronos providing oversight and hosting of the project.

vulkan-loader's People

Contributors

charles-lunarg avatar chrisforbes avatar cnorthrop avatar courtney-g avatar courtney-lunarg avatar davidlunarg avatar dependabot[bot] avatar dustin-lunarg avatar felixdoerre avatar greg-lunarg avatar ianatlunarg avatar ianelliottus avatar jeremy-lunarg avatar jon-lunarg avatar juan-lunarg avatar jzulauf-lunarg avatar karl-lunarg avatar lenny-lunarg avatar lunarpapillo avatar mark-lunarg avatar marky-lunarg avatar mikes-lunarg avatar null77 avatar olvaffe avatar pdaniell-nv avatar scygan avatar shannon-lunarg avatar stroyan avatar tobine avatar tonybarbour avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

vulkan-loader's Issues

Allow using Vulkan-Headers installed on the system

Hi,

I am a maintainer for Gentoo. We cannot have Vulkan-Headers as a submoduble as it currently is, so it is packaged separately. Right now, there only way to use the system version of Vulkan-Headers is to manually modify the source, as I have done below for Vulkan-Loader:

https://raw.githubusercontent.com/gentoo/gentoo/master/media-libs/vulkan-loader/files/vulkan-loader-9999-Use-usr-for-vulkan-headers.patch

Please allow a way to use the system Vulkan-Headers install, perhaps with a -DVULKAN_HEADERS_INSTALL_DIR variable.

Thanks,
Sarnex

vkCreateInstance should return an error if a layer can't be loaded

If the json file for the trace layer is missing or otherwise can't be found, vkCreateInstance returns VK_ERROR_LAYER_NOT_PRESENT.

If the shared library for the trace layer is missing otherwise can't be found, vkCreateInstance returns VK_SUCCESS. It seems it should return VK_ERROR_LAYER_NOT_PRESENT.

Quoting from the vkCreateInstance manual page:

vkCreateInstance verifies that the requested layers exist. If not, vkCreateInstance will return VK_ERROR_LAYER_NOT_PRESENT.

This issue needs to be resolved so that LunarG/VulkanTools#501 can work correctly.

[Android] wrong signatures for terminator_CreateAndroidSurfaceKHR() and vkCreateAndroidSurfaceKHR()

Hi
There is a mismatch in the function signatures causing compilation failure while compiling for Android ,at least for me :).

The type definition of the API can be found in the link below.
https://github.com/KhronosGroup/Vulkan-Headers/blob/master/include/vulkan/vulkan_android.h

typedef VkResult (VKAPI_PTR *PFN_vkCreateAndroidSurfaceKHR)(VkInstance instance, const VkAndroidSurfaceCreateInfoKHR* pCreateInfo, const VkAllocationCallbacks* pAllocator, VkSurfaceKHR* pSurface);

The wrong signatures of the API's can found in the link below .
https://github.com/KhronosGroup/Vulkan-Loader/blob/master/loader/wsi.c

LOADER_EXPORT VKAPI_ATTR VkResult VKAPI_CALL vkCreateAndroidSurfaceKHR(VkInstance instance, ANativeWindow *window,const VkAllocationCallbacks *pAllocator,VkSurfaceKHR *pSurface)

VKAPI_ATTR VkResult VKAPI_CALL terminator_CreateAndroidSurfaceKHR(VkInstance instance, Window window,const VkAllocationCallbacks *pAllocator, VkSurfaceKHR *pSurface)

I guess the body of terminator_CreateAndroidSurfaceKHR() should be modified to comply with the right signature.
In addition terminator_CreateAndroidSurfaceKHR() should be declared in wsi.h

How to create new VkDevices in Layers?

When in a layer you need a new dispatchable object, you need to copy over the dispatch table as documented here: https://github.com/KhronosGroup/Vulkan-Loader/blob/master/loader/LoaderAndLayerInterface.md#creating-new-dispatchable-objects
You can do this manually or with the given helper function vkSetInstanceLoaderData/vkSetDeviceLoaderData.
However you need always to have a corresponding VkInstance/VkDevice object ready for copying the dispatch table pointer. What do you do when you don't have such an object at hand?

Now the concrete example: Suppose you have a "normal" Vulkan application that creates a VkInstance and then selects a VkPhysicalDevice and calls vkCreateDevice upon that and uses this device to render.
Suppose I want to insert a Layer that additionally to creating the VkDevice requested by the application wants to create another device (based on a different VkPhysicalDevice), how is this possible? How can I create this (second) dispatchable object with which I call vkCreateDevice down the chain? The Application is never calling vkCreateDevice on that VkPhysicalDevice so the layer is never getting a hand on the required dispatch table.

Please help me to understand if this is a VulkanLoader limitation or if I just don't understand the given documentation.

tests: Enhance loader tests to run when validation layers are not present

(I think that this may apply only to the tests on Linux)

Some of the current loader tests use the validation layers mainly as "dummy layers" to test for the correct order of layer loading, etc, without really exercising them as actual validation layers.
Before the repo split, the layers were always present because they were built in the same repo, so there was never a problem with "finding" the layers.

It would be good to skip these tests when the layers are not present.
This would allow running the tests, even a subset, without the user having the layers built or installed.
In particular, it would be useful for CI testing because a loader-only CI test could avoid the (significant) cost of building the layers.

Aside from implementing something to skip tests that need these layers, it may be possible to rework the tests to still test the same functionality, but perhaps with the layers already in this repo.
If more layers are needed, then it might be feasible to add more "dummy layers" to this repo, such as replications of the existing "test" layer. Other more creative solutions might exist.

In any case, it would be nice to be able to build and test this repo on Travis-CI without building the (expensive) Vulkan-ValidationLayers dir. However, it would need to build part of Vulkan-Tools to get the mock ICD in order to run the loader tests. But this is cheaper to build than the layers. (Note: The mock ICD might need upgrades to handle some of the things the loader tests throw at it.)

cube --validate segfaults when layers not present

Can reproduce (on Linux) by setting VK_LAYER_PATH to a place where there are no layers and running cube --validate. The segfault (jump to zero) happens in the loader when trying to execute CmdBeginDebugUtilsLabelEXT in vk_loader_extensions.c.

I suppose that the guts of the Debug Utils extensions are implemented in the layers, and if not present, the loader isn't able to dispatch the call.

I'm not sure if there is a way around this in the loader or not. It may also be the case that cube should avoid calling the Debug Utils if the layers are not really loaded? Or perhaps cube should just terminate if it can't get the layers? Or have cube print a message and continue running with validation "turned off", which avoids calling Debug Utils.

MockICD: Double free of physical_device handle with > 1 concurrent instance

vk_loader_validation_test case EnumeratePhysicalDevices.MatchOneAndTwoCallNumbers with mock icd

There is heap corruption causing program termination. Valgrind pointed to DestroyInstance call of

DestroyDispObjHandle((void*)physical_device);

Physical_device is a file scope static, and MatchOneAndTwo creates two instances at the same time and then deletes them. The pointer physical_device is thus double freed since it isn't NULL'd after free -- corrupting the heap, with program termination happening at a later free().

Nulling the pointer after free would avoid the corruption, but result in the surviving instance having a NULL physical_device

Use of a shared pointer and/or unique_ptr, would seem advised (along with mutex or std::call_once on initialization).

Add some detail in layer discovery error reporting

The motivating use case for this request is when a sandboxed application (based on the Apple Cocoa framework in this case) tries to load a layer from a directory that it does not have permission to read. The attempt to read the directory fails and there is not enough detail for diagnosis, even with VK_LOADER_DEBUG=all. This same sort of thing could happen in other environments with a similar set of failing file I/O requests.

One approach for implementing this is to interpret each filesystem operation failure (e.g., directory not found, no files in a directory, insufficient directory read permission, etc) and add them to the error reporting when it is set to "error" or another appropriate level. The downside is that this can create a lot of noise because we intentionally search a lot of directories that may not exist.

One compromise would be to perform this extra reporting only on directories specified by VK_LAYER_PATH. The thinking is that the user explicitly specified the directories in this list and so they should all probably exist and be usable. The user would like to be able to find out if they made a simple typo in the path, or if they are trying to read a directory that they are not allowed to read, etc. For these directories, the loader should report as much as it can, as each platform allows, about any failing filesystem operations. Currently, all we see in the loader debug output is an echoing of the contents of VK_LAYER_PATH and no messages at all about any troubles in using this path.

Current Linux Build broken

When attempting to build loader on Linux from fresh repo with latest code and instructions I get the following CMake error:

CMake Error at tests/CMakeLists.txt:127 (add_subdirectory):
  The source directory

    /usr/local/google/home/tobine/test_repos/Vulkan-Loader/tests/googletest

  does not contain a CMakeLists.txt file.

Here's the general procedure I'm following:

  • Clone Vulkan-Headers repo
  • "make install" headers in cloned Vulkan-Headers repo
  • Clone Vulkan-Loader repo
  • in new build dir run "cmake -DVULKAN_HEADERS_INSTALL_DIR=/build/install -DCMAKE_BUILD_TYPE=Debug .."

Also note that the Download Repository section of the BUILD.md instructions for this repo still instruct users to "--recurse-submodules" even though there's no longer any submodule.

Loader fails to build

Following the windows build instructions (Also happens building for Linux) results in an error:

-- Found VulkanHeaders: C:/Users/xxx/Documents/GitHub/Vulkan-Headers/include
-- Could NOT find VulkanRegistry (missing: VulkanRegistry_DIR)
CMake Error at loader/CMakeLists.txt:19 (message):
  Could not find Vulkan registry path.  This can be fixed by setting
  VULKAN_HEADERS_INSTALL_DIR to an installation of the Vulkan-Headers
  repository.

I can fix it by changing FindVulkanHeaders.cmake from:
HINTS "${VULKAN_REGISTRY_PATH_HINT}/share/vulkan/registry")
to:
HINTS "${VULKAN_REGISTRY_PATH_HINT}/registry")

CMake errors building LVL

Issue by Tony-LunarG (MIGRATED)
Thursday May 10, 2018 at 16:40 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#2667


There are CMake errors that result from CMake looking for pthread_create and secure_getenv in build/CMakeFiles/CMakeError.log. While these don't prevent anything from building, when things do go wrong they are sometimes a distraction from the real issue. We have had them reported in multiple issues, most recently in VulkanSamples, as the cause of compile failures, when the real cause was something else.

Loader test CreateInstanceDeviceIntentionalAllocFail fails on AMD

Issue by krOoze (MIGRATED)
Tuesday Sep 19, 2017 at 17:38 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#2078


Running vk_loader_validation_tests I get:

[ RUN ] Allocation.CreateInstanceDeviceIntentionalAllocFail
C:\Dev\_GitHub\Vulkan-LoaderAndValidationLayers\tests\loader_validation_tests.cpp(1454): error: Value of: VK_SUCCESS
Actual: 0
Expected: result
Which is: -3
[ FAILED ] Allocation.CreateInstanceDeviceIntentionalAllocFail (1639 ms)

This is on Windows 10 x64, AMD R9 280X, Radeon Software 17.9.1.
UPDATE: still in 17.11.1.

Failure to build with musl libc

Issue by dirkson (MIGRATED)
Monday Feb 05, 2018 at 19:25 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#2397


The method used to check for the existence of secure_getenv and __secure_getenv appears to be dependent on the existence of these functions to function. Which is sort of a fun, tautological method to check if they exist, but does prevent the building when they're absent, which is probably not the intent.

Relevant cmake errors:


Determining if the function secure_getenv exists failed with the following output:
Change Dir: /home/dirkson/Vulkan-LoaderAndValidationLayers/dbuild/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/make" "cmTC_a2359/fast"
/usr/bin/make -f CMakeFiles/cmTC_a2359.dir/build.make CMakeFiles/cmTC_a2359.dir/build
make[1]: Entering directory '/home/dirkson/Vulkan-LoaderAndValidationLayers/dbuild/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_a2359.dir/CheckFunctionExists.c.o
/usr/bin/cc   -std=c99 -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -fno-strict-aliasing -fno-builtin-memcmp -Wimplicit-fallthrough=0 -fvisibility=hidden -DCHECK_FUNCTION_EXISTS=secure_getenv   -o CMakeFiles/cmTC_a2359.dir/CheckFunctionExists.c.o   -c /usr/share/cmake-3.10/Modules/CheckFunctionExists.c
Linking C executable cmTC_a2359
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_a2359.dir/link.txt --verbose=1
/usr/bin/cc  -std=c99 -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -fno-strict-aliasing -fno-builtin-memcmp -Wimplicit-fallthrough=0 -fvisibility=hidden -DCHECK_FUNCTION_EXISTS=secure_getenv    -rdynamic CMakeFiles/cmTC_a2359.dir/CheckFunctionExists.c.o  -o cmTC_a2359
CMakeFiles/cmTC_a2359.dir/CheckFunctionExists.c.o: In function `main':
CheckFunctionExists.c:(.text+0x10): undefined reference to `secure_getenv'
collect2: error: ld returned 1 exit status
make[1]: *** [CMakeFiles/cmTC_a2359.dir/build.make:98: cmTC_a2359] Error 1
make[1]: Leaving directory '/home/dirkson/Vulkan-LoaderAndValidationLayers/dbuild/CMakeFiles/CMakeTmp'
make: *** [Makefile:126: cmTC_a2359/fast] Error 2

Determining if the function __secure_getenv exists failed with the following output:
Change Dir: /home/dirkson/Vulkan-LoaderAndValidationLayers/dbuild/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/make" "cmTC_ef332/fast"
/usr/bin/make -f CMakeFiles/cmTC_ef332.dir/build.make CMakeFiles/cmTC_ef332.dir/build
make[1]: Entering directory '/home/dirkson/Vulkan-LoaderAndValidationLayers/dbuild/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_ef332.dir/CheckFunctionExists.c.o
/usr/bin/cc   -std=c99 -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -fno-strict-aliasing -fno-builtin-memcmp -Wimplicit-fallthrough=0 -fvisibility=hidden -DCHECK_FUNCTION_EXISTS=__secure_getenv   -o CMakeFiles/cmTC_ef332.dir/CheckFunctionExists.c.o   -c /usr/share/cmake-3.10/Modules/CheckFunctionExists.c
Linking C executable cmTC_ef332
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_ef332.dir/link.txt --verbose=1
/usr/bin/cc  -std=c99 -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -fno-strict-aliasing -fno-builtin-memcmp -Wimplicit-fallthrough=0 -fvisibility=hidden -DCHECK_FUNCTION_EXISTS=__secure_getenv    -rdynamic CMakeFiles/cmTC_ef332.dir/CheckFunctionExists.c.o  -o cmTC_ef332
CMakeFiles/cmTC_ef332.dir/CheckFunctionExists.c.o: In function `main':
CheckFunctionExists.c:(.text+0x10): undefined reference to `__secure_getenv'
collect2: error: ld returned 1 exit status
make[1]: *** [CMakeFiles/cmTC_ef332.dir/build.make:98: cmTC_ef332] Error 1
make[1]: Leaving directory '/home/dirkson/Vulkan-LoaderAndValidationLayers/dbuild/CMakeFiles/CMakeTmp'
make: *** [Makefile:126: cmTC_ef332/fast] Error 2

My knowledge of cmake isn't sufficient to produce a sane patch, but I was able to delete these variables, which results in an errorless build using musl. (I presume by forcing usage of the non-secure getenv)

Test layer triggers crash if enabled

I've tried this with a couple of application :

VK_INSTANCE_LAYERS=VK_LAYER_LUNARG_test COGL_DRIVER=vulkan gdb --args ../cogl/examples/cogl-hello

Thread 1 "cogl-hello" received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in  ()
#1  0x00007ffff3fd3753 in vkGetDeviceQueue (device=0x555555861fc0, queueNodeIndex=0, queueIndex=0, pQueue=0x55555579f780) at Vulkan-Loader/loader/trampoline.c:1003
#2  0x00007ffff5fa37e1 in _cogl_vulkan_context_init (context=0x55555557f610, error=0x7fffffffd538) at driver/vulkan/cogl-driver-vulkan.c:302
#3  0x00007ffff6021918 in _cogl_winsys_context_init (context=0x55555557f610, error=0x7fffffffd538) at winsys/cogl-winsys-vulkan-x11.c:278
#4  0x00007ffff5fb5235 in cogl_context_new (display=0x555555591d00, error=0x7fffffffd538) at cogl-context.c:237
#5  0x000055555555543a in main (argc=1, argv=0x7fffffffd678) at cogl-hello.c:89

Same with gfxbench :

VK_INSTANCE_LAYERS=VK_LAYER_LUNARG_test gdb --args ./bin/testfw_app -t vulkan_5_normal --gfx=xcb_vulkan -w1280 -h720

Thread 2 "testfw_app" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff519c700 (LWP 10139)]
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007ffff69c4753 in vkGetDeviceQueue (device=0x7ffff0390350, queueNodeIndex=0, queueIndex=0, pQueue=0x7ffff0006c18) at Vulkan-Loader/loader/trampoline.c:1003
#2  0x00000000007fc6ec in ?? ()
#3  0x00000000007fe024 in ?? ()
#4  0x00000000007eb3e6 in ?? ()
#5  0x0000000000768170 in ?? ()
#6  0x0000000000768a45 in ?? ()
#7  0x00000000004282b2 in ?? ()
#8  0x000000000061354f in ?? ()
#9  0x0000000000610856 in ?? ()
#10 0x00007ffff70bbf2a in start_thread (arg=0x7ffff519c700) at pthread_create.c:463
#11 0x00007ffff6596edf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

vkEnumerateInstanceExtensionProperties cannot be called from CreateInstance in a layer

Issue by Themaister (MIGRATED)
Friday Sep 08, 2017 at 14:46 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#2064


I am trying to write a Vulkan layer which injects functionality which requires particular extensions from an ICD.

The application might not enable those extensions, so I am trying to add those extensions in the layer's CreateInstance when going down the chain.

To do this robustly, I need to query that the extensions actually exist before calling pfnNextGetInstanceProcAddr. However, querying vkEnumerateInstanceExtensionProperties fails, yet vkCreateInstance works. This seems a bit odd.

	auto fpGetInstanceProcAddr = chainInfo->u.pLayerInfo->pfnNextGetInstanceProcAddr;

	auto fpEnumerateExts = reinterpret_cast<PFN_vkEnumerateInstanceExtensionProperties>(
			fpGetInstanceProcAddr(nullptr, "vkEnumerateInstanceExtensionProperties"));
	if (!fpEnumerateExts)
		return VK_ERROR_INITIALIZATION_FAILED;

Executable Inside UninstallVulkanRT.exe flagged as Razy Trojan

Issue by colehocking (MIGRATED)
Wednesday Jan 10, 2018 at 17:48 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#2335


Hello,

Within the path C:\Program Files (x86)\VulkanRT\1.0.54.1, I am seeing an executable packed within UninstallVulkanRT.exe that is being executed by igxpun.exe (an Intel executable). The PE being executed is called tmp00077132.exe. It is flagged by multiple AV sources as a Razy Trojan (Link is the VT report) Are you aware of this issue?

I have opened this new issue as it is regarding a different PE that in issue #474.
It is packed within the Uninstaller; it is not the uninstaller itself.

PFN_GetPhysicalDeviceProcAddr has C++ interface.

Issue by stroyan (MIGRATED)
Tuesday Jan 09, 2018 at 16:29 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#2330


When PFN_GetPhysicalDeviceProcAddr was added to vk_icd.h and vk_layer.h in commit b5f087a it was done without an extern "C" declaration.
The pfnGetPhysicalDeviceProcAddr member in struct VkNegotiateLayerInterface and the vk_layerGetPhysicalDeviceProcAddr functions in validation layers are all using C++ interfaces.
It will be awkward to change to a C binding now. But it will be troubling to use a C++ binding forever.

$ nm ~/Downloads/VulkanSDK/1.0.46.0/x86_64/lib/libVkLayer_threading.so | grep vk_layerGetPhysicalDeviceProcAddr
000000000001f2b0 T _Z33vk_layerGetPhysicalDeviceProcAddrP12VkInstance_TPKc

Assertion failure when only some ICDs have VK_KHR_surface support

Issue by polarina (MIGRATED)
Monday Nov 06, 2017 at 23:47 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#2186


Two ICDs are installed, one exposes support for the VK_KHR_surface instance extension and the other doesn't.

From the application's perspective, the loader says it supports VK_KHR_surface since there's at least one ICD that supports it, however, when calling vkGetPhysicalDeviceSurfaceFormatsKHR on a VkPhysicalDevice from the non-surface-supporting ICD, the loader hits an assertion.

vulkaninfo: /home/polarina/projects/Vulkan-LoaderAndValidationLayers/loader/wsi.c:306: terminator_GetPhysicalDeviceSurfaceFormatsKHR: Assertion `false && "loader: null GetPhysicalDeviceSurfaceFormatsKHR ICD pointer"' failed.

Program received signal SIGABRT, Aborted.
0x00007ffff6e678a0 in raise () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007ffff6e678a0 in raise () from /usr/lib/libc.so.6
#1  0x00007ffff6e68f09 in abort () from /usr/lib/libc.so.6
#2  0x00007ffff6e600dc in __assert_fail_base () from /usr/lib/libc.so.6
#3  0x00007ffff6e60153 in __assert_fail () from /usr/lib/libc.so.6
#4  0x00007ffff763ea19 in terminator_GetPhysicalDeviceSurfaceFormatsKHR (physicalDevice=0x5555557757a0, surface=0x5555563155f0, 
    pSurfaceFormatCount=0x7fffffffdd44, pSurfaceFormats=0x0)
    at /home/polarina/projects/Vulkan-LoaderAndValidationLayers/loader/wsi.c:306
#5  0x00007ffff763e902 in vkGetPhysicalDeviceSurfaceFormatsKHR (physicalDevice=0x5555557e2c50, surface=0x5555563155f0, 
    pSurfaceFormatCount=0x7fffffffdd44, pSurfaceFormats=0x0)
    at /home/polarina/projects/Vulkan-LoaderAndValidationLayers/loader/wsi.c:278
#6  0x0000555555558745 in AppDumpSurfaceFormats (inst=0x7fffffffde00, gpu=0x5555557d3ad0, out=0x7ffff71e55a0 <_IO_2_1_stdout_>)
    at /home/polarina/projects/Vulkan-LoaderAndValidationLayers/demos/vulkaninfo.c:1146
#7  0x000055555555f349 in main (argc=1, argv=0x7fffffffe118)
    at /home/polarina/projects/Vulkan-LoaderAndValidationLayers/demos/vulkaninfo.c:2480

windowsRuntimeInstaller Uninstaller succeds (retcode == 0) when ConfigureRT fails

Issue by scyganINTEL (MIGRATED)
Tuesday Nov 21, 2017 at 10:07 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#2223


As the last step of VulkanRT uninstallation, ConfigureRT.exe is run to elect newest loader /&vulkaninfo and place them as vulkan-1.dll / vulkaninfo.exe in %SYSTEM% directory.

It seems when ConfigureRT fails, it seems the error is not passed via uninstaller, which exists with code 0 ignoring the failure.

For example, I have installed 3 RTs of different version and removed N-1 (N == newest) vulkan-1-x-x-x-x.dll.
When running the uninstaller of N (newest), ConfigureRT fails with error 220 due to vulkaninfo & vulkan-1.dll version mismatch (N-1 != N-2). It seems no loader is elected, however this error is not signalized in uninstaller, which silently passes and returns retcode 0.

EXT_debug_utils label functions call a null ptr if there is no layers enabled.

When trying to use CmdBeginDebugUtilsLabelEXT or any other label function from the EXT_debug_utils extenstion without a layer that intercepts the function, a null pointer is called.

Issue can be reproduced with the cube demo by removing the code that loads the validation layer and running with --validate

Exception thrown at 0x0000000000000000 in cube.exe: 0xC0000005: Access violation executing location 0x0000000000000000. occurred
>	vulkan-1.dll!CmdBeginDebugUtilsLabelEXT(VkCommandBuffer_T * commandBuffer, const VkDebugUtilsLabelEXT * pLabelInfo) Line 2079	C
 	cube.exe!demo_draw_build_cmd(demo * demo, VkCommandBuffer_T * cmd_buf) Line 751	C
 	cube.exe!demo_prepare(demo * demo) Line 2230	C
 	cube.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, char * pCmdLine, int nCmdShow) Line 3815	C

cmake: Windows loader DLL should be copied by the test app target and not the loader target

There is CMake code for the loader project that copies the loader DLL to the loader test binary directory so that the test app finds the loader just built in this repo. Instead, the test target's CMake code should be doing the copy since it should take responsibility for its own dependencies (the loader in this case).

See KhronosGroup/Vulkan-ValidationLayers#180 for the general approach. This approach would have to be modified somewhat since the loader is built in this repo and not discovered by find_vulkan.

Enabling extension in layer causes crash

Way to reproduce

  1. Don't pass VK_KHR_get_physical_device_properties2 as instance extension while calling vkCreateInstance inside vulkan application
  2. Enable VK_KHR_get_physical_device_properties2 while calling vkCreateInstance inside implicit layer
  3. Inside implicit layer call vkGetPhysicalDeviceProperties2KHR it will cause AccessViolation exception
    inside loader.c in function VKAPI_ATTR void VKAPI_CALL terminator_GetPhysicalDeviceProperties2(VkPhysicalDevice physicalDevice, VkPhysicalDeviceProperties2 *pProperties)

It causes AccessViolation at

VKAPI_ATTR void VKAPI_CALL terminator_GetPhysicalDeviceProperties2(VkPhysicalDevice physicalDevice,
VkPhysicalDeviceProperties2 *pProperties) {
struct loader_physical_device_term *phys_dev_term = (struct loader_physical_device_term *)physicalDevice;
struct loader_icd_term *icd_term = phys_dev_term->this_icd_term;
const struct loader_instance *inst = icd_term->this_instance;

// Get the function pointer to use to call into the ICD. This could be the core or KHR version
PFN_vkGetPhysicalDeviceProperties2 fpGetPhysicalDeviceProperties2 = NULL;
if (inst != NULL && inst->enabled_known_extensions.khr_get_physical_device_properties2) {
    fpGetPhysicalDeviceProperties2 = icd_term->dispatch.GetPhysicalDeviceProperties2KHR;
} else {
    fpGetPhysicalDeviceProperties2 = icd_term->dispatch.GetPhysicalDeviceProperties2;
}

if (fpGetPhysicalDeviceProperties2 != NULL || !inst->enabled_known_extensions.khr_get_physical_device_properties2) {
    // Pass the call to the driver
    fpGetPhysicalDeviceProperties2(phys_dev_term->phys_dev, pProperties); // <- !!!! calling null pointer
} else {
    // Emulate the call
    loader_log(icd_term->this_instance, VK_DEBUG_REPORT_INFORMATION_BIT_EXT, 0,
               "vkGetPhysicalDeviceProperties2: Emulating call in ICD \"%s\" using vkGetPhysicalDeviceProperties",
               icd_term->scanned_icd->lib_name);

.....

because

fpGetPhysicalDeviceProperties2 == nullptr;
inst->enabled_known_extensions.khr_get_physical_device_properties2 == false;
icd_term->dispatch.GetPhysicalDeviceProperties2KHR != nullptr;
icd_term->dispatch.GetPhysicalDeviceProperties2 == nullptr;

Full crash dump with dll versions at https://ufile.io/ix9jl problem doesn't exist on Intel and Nvidia GPUs

vulkan-1.dll from VulkanSDK-1.1.85.0 causes Vulkan CTS failure

It appears there is a regression in the latest vulkan-1.dll loader which comes with the VulkanSDK-1.1.85.0. It appears the regression comes from b02f642#diff-5b4e070f5ce5cbb7bd1dd11f689d50a8.

The following test from vulkan-cts-1.1.2.1 fails with the new loader:
dEQP-VK.api.device_init.create_instance_device_intentional_alloc_fail

Taking a quick look at the new loader.c code, it seems the problem is in ReadDataFilesInRegistry() when regHKR_result=VK_ERROR_OUT_OF_HOST_MEMORY and reg_result=VK_ERROR_INITIALIZATION_FAILED it causes ReadDataFilesInRegistry() to return VK_ERROR_INCOMPATIBLE_DRIVER instead of VK_ERROR_OUT_OF_HOST_MEMORY.

Since reg_result=VK_ERROR_INITIALIZATION_FAILED is expected when the DLLs are in a driver hive, the logic in ReadDataFilesInRegistry() should use the regHKR_result result rather then hard-coding the result to VK_ERROR_INCOMPATIBLE_DRIVER.

VK_EXT_debug_report makes a duplicate of custom messages

Not sure if loader Issue?

Platform: AMD 18.8.2, SDK 1.1.82.0

  1. vkDebugReportMessageEXT messages are duplicated. From the below code I get:

Hello layer!
Hello layer!
vkEnumeratePhysicalDevices: Received NULL pointer for physical device count return value.

Behaves the same without layers, i.e.:
const VkInstance instance = initInstance( {}, {VK_EXT_DEBUG_REPORT_EXTENSION_NAME} );

Behaves the same without temporary debug, i.e. with VkInstanceCreateInfo::pNext = nullptr.

  1. Surprisingly I get the last Error message too without the layers, weird...
Repro code:
#include <vector>
using std::vector;
#include <iostream>
using std::cout; using std::endl;
#include <vulkan/vulkan.h>

#define RESULT_HANDLER( errorCode, source )  if( errorCode ) throw "Fail!"

constexpr VkDebugReportFlagsEXT debugAmount = VK_DEBUG_REPORT_WARNING_BIT_EXT | VK_DEBUG_REPORT_PERFORMANCE_WARNING_BIT_EXT | VK_DEBUG_REPORT_ERROR_BIT_EXT;
VKAPI_ATTR VkBool32 VKAPI_CALL genericDebugCallback( VkDebugReportFlagsEXT, VkDebugReportObjectTypeEXT, uint64_t, size_t, int32_t, const char*, const char* pMessage, void* );

VkInstance initInstance( const vector<const char*>& layers = {}, const vector<const char*>& extensions = {} );
void loadDebugReportCommands( VkInstance instance );
VkDebugReportCallbackEXT initDebug( const VkInstance instance );

int main(){
	const VkInstance instance = initInstance( {"VK_LAYER_LUNARG_standard_validation"}, {VK_EXT_DEBUG_REPORT_EXTENSION_NAME} );
	loadDebugReportCommands( instance );
	const VkDebugReportCallbackEXT debug = initDebug( instance );

	vkDebugReportMessageEXT( instance, VK_DEBUG_REPORT_ERROR_BIT_EXT, VK_DEBUG_REPORT_OBJECT_TYPE_UNKNOWN_EXT, 0, __LINE__, 0, "Application", "Hello layer!" ); // send custom msg
	vkEnumeratePhysicalDevices( instance, nullptr, nullptr ); // trip VU

	vkDestroyDebugReportCallbackEXT( instance, debug, nullptr );
	vkDestroyInstance( instance, nullptr );
}

VKAPI_ATTR VkBool32 VKAPI_CALL genericDebugCallback( VkDebugReportFlagsEXT, VkDebugReportObjectTypeEXT, uint64_t, size_t, int32_t, const char*, const char* pMessage, void* ){
	cout << pMessage << endl;
	return VK_FALSE; // no abort on misbehaving command
}

VkInstance initInstance( const vector<const char*>& layers, const vector<const char*>& extensions ){
	// in effect during vkCreateInstance and vkDestroyInstance duration (because callback object cannot be created without instance)
	const VkDebugReportCallbackCreateInfoEXT debugCreateInfo{
		VK_STRUCTURE_TYPE_DEBUG_REPORT_CALLBACK_CREATE_INFO_EXT,
		nullptr, // pNext
		::debugAmount,
		::genericDebugCallback,
		nullptr // pUserData
	};

	const VkInstanceCreateInfo instanceInfo{
		VK_STRUCTURE_TYPE_INSTANCE_CREATE_INFO,
		&debugCreateInfo,
		0, // flags - reserved for future use
		nullptr, // appInfo
		static_cast<uint32_t>( layers.size() ),
		layers.data(),
		static_cast<uint32_t>( extensions.size() ),
		extensions.data()
	};

	VkInstance instance;
	const VkResult errorCode = vkCreateInstance( &instanceInfo, nullptr, &instance ); RESULT_HANDLER( errorCode, "vkCreateInstance" );

	return instance;
}

PFN_vkCreateDebugReportCallbackEXT fpCreateDebugReportCallbackEXT = nullptr;
VKAPI_ATTR VkResult VKAPI_CALL vkCreateDebugReportCallbackEXT( VkInstance instance, const VkDebugReportCallbackCreateInfoEXT* pCreateInfo, const VkAllocationCallbacks* pAllocator, VkDebugReportCallbackEXT* pCallback ){
	return fpCreateDebugReportCallbackEXT( instance, pCreateInfo, pAllocator, pCallback );
}

PFN_vkDestroyDebugReportCallbackEXT fpDestroyDebugReportCallbackEXT = nullptr;
VKAPI_ATTR void VKAPI_CALL vkDestroyDebugReportCallbackEXT( VkInstance instance, VkDebugReportCallbackEXT callback, const VkAllocationCallbacks* pAllocator ){
	return fpDestroyDebugReportCallbackEXT( instance, callback, pAllocator );
}

PFN_vkDebugReportMessageEXT fpDebugReportMessageEXT = nullptr;
VKAPI_ATTR void VKAPI_CALL vkDebugReportMessageEXT( VkInstance instance, VkDebugReportFlagsEXT flags, VkDebugReportObjectTypeEXT objectType, uint64_t object, size_t location, int32_t messageCode, const char* pLayerPrefix, const char* pMessage ){
	return fpDebugReportMessageEXT( instance, flags, objectType, object, location, messageCode, pLayerPrefix, pMessage );
}

void loadDebugReportCommands( VkInstance instance ){
	PFN_vkVoidFunction temp_fp;

	temp_fp = vkGetInstanceProcAddr( instance, "vkCreateDebugReportCallbackEXT" );
	if( !temp_fp ) throw "Failed to load vkCreateDebugReportCallbackEXT"; // check shouldn't be necessary (based on spec)
	fpCreateDebugReportCallbackEXT = reinterpret_cast<PFN_vkCreateDebugReportCallbackEXT>( temp_fp );

	temp_fp = vkGetInstanceProcAddr( instance, "vkDestroyDebugReportCallbackEXT" );
	if( !temp_fp ) throw "Failed to load vkDestroyDebugReportCallbackEXT"; // check shouldn't be necessary (based on spec)
	fpDestroyDebugReportCallbackEXT = reinterpret_cast<PFN_vkDestroyDebugReportCallbackEXT>( temp_fp );

	temp_fp = vkGetInstanceProcAddr( instance, "vkDebugReportMessageEXT" );
	if( !temp_fp ) throw "Failed to load vkDebugReportMessageEXT"; // check shouldn't be necessary (based on spec)
	fpDebugReportMessageEXT = reinterpret_cast<PFN_vkDebugReportMessageEXT>( temp_fp );
}

VkDebugReportCallbackEXT initDebug( const VkInstance instance ){
	const VkDebugReportCallbackCreateInfoEXT debugCreateInfo{
		VK_STRUCTURE_TYPE_DEBUG_REPORT_CALLBACK_CREATE_INFO_EXT,
		nullptr, // pNext
		::debugAmount,
		::genericDebugCallback,
		nullptr // pUserData
	};

	VkDebugReportCallbackEXT debug;
	const VkResult errorCode = vkCreateDebugReportCallbackEXT( instance, &debugCreateInfo, nullptr, &debug ); RESULT_HANDLER( errorCode, "vkCreateDebugReportCallbackEXT" );

	return debug;
}

Unable to build vulkan-loader 1.1.77 | "no member named 'GetPhysicalDeviceDisplayProperties2KHR';"

I wanted to update vulkan-loader 1.1.73.0 to 1.1.77.0 but it failed to build for my LibreELEC 9.0 distribution. The last release v73 worked flaweless. I added an extra package for vulkan-headers since they aren't included anymore. Any hints are welcome!

https://pastebin.com/m35GFCvh

/home/supervisedthinking/le90-Remix/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.0-devel/vulkan-loader-1.1.77.0/loader/wsi.c: In function 'vkGetPhysicalDeviceDisplayProperties2KHR':
/home/supervisedthinking/le90-Remix/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.0-devel/vulkan-loader-1.1.77.0/loader/wsi.c:1611:18: error: 'VkLayerInstanceDispatchTable' {aka 'const struct VkLayerInstanceDispatchTable_'} has no member named 'GetPhysicalDeviceDisplayProperties2KHR'; did you mean 'GetPhysicalDeviceDisplayPropertiesKHR'?
return disp->GetPhysicalDeviceDisplayProperties2KHR(unwrapped_phys_dev, pPropertyCount, pProperties);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
GetPhysicalDeviceDisplayPropertiesKHR

_alloca used in a loop - can lead to stack exhaustion

Issue by randomascii (MIGRATED)
Friday Dec 23, 2016 at 01:26 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#1307


It is a good rule of thumb that _alloca/alloca should not be used in a loop because each call allocates additional space and the stack growth can be unbounded. This is done in several places in loader/loader.c, such as here:

https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/master/loader/loader.c#L2349

The call to alloca is hidden inside of GET_JSON_ITEM.

A fixed-size buffer that is reused for all uses of GET_JSON_ITEM that are in loops would avoid this problem. A fixed-size buffer might seem like a step backwards because it limits the maximum size of JSON items, but it actually limits them less than now. Currently the maximum size is, roughly speaking, O(stack-size / count), whereas with a reused buffer the maximum size could be as large as O(stack-size).

This was found through a VC++ static analysis warning when building this in Chromium. The full set of warning are:

loader.c(2349) : warning C6263: Using _alloca in a loop: this can quickly overflow stack.
loader.c(2356) : warning C6263: Using _alloca in a loop: this can quickly overflow stack.
loader.c(2382) : warning C6263: Using _alloca in a loop: this can quickly overflow stack.
loader.c(2383) : warning C6263: Using _alloca in a loop: this can quickly overflow stack.
loader.c(2406) : warning C6263: Using _alloca in a loop: this can quickly overflow stack.
loader.c(2417) : warning C6263: Using _alloca in a loop: this can quickly overflow stack.
loader.c(3018) : warning C6263: Using _alloca in a loop: this can quickly overflow stack.
loader.c(3050) : warning C6263: Using _alloca in a loop: this can quickly overflow stack.
loader.c(4457) : warning C6263: Using _alloca in a loop: this can quickly overflow stack.

Checking for capabilities doesn’t work with multiple VkDevices

validate_shader_capabilities in layers/shader_validation.cpp has a static hash table mapping from capability to a bool pointer to the place storing whether the capability is enabled. Previously it was a member pointer into either VkPhysicalDeviceFeatures or DeviceExtensions. However, this commit changed it so that it is a bool* pointer directly into the struct. Seeing as the hash table is static that means it will always point into the data for the first VkDevice used. If you use multiple devices this will have the wrong data or potentially be a dangling pointer.

Perhaps it would be better to convert it back to being member pointers or make it non-static.

This was discovered using VkRunner with a command like this:

VK_INSTANCE_LAYERS=VK_LAYER_LUNARG_standard_validation \
./src/vkrunner examples/{tricolore,frexp}.shader_test

The first test script has different requirements from the second one so VkRunner creates a new VkDevice. This causes the validation layer to erroneously report an error. It also shows up as a read error in Valgrind because of the dangling pointer.

Unable to build vulkan loader in linux through make -j8

Scanning dependencies of target generate_helper_files
Scanning dependencies of target loader_gen_files
[ 29%] Generating vk_safe_struct.cpp
[ 29%] Generating vk_dispatch_table_helper.h
[ 29%] Generating vk_loader_extensions.c
[ 29%] Generating vk_loader_extensions.h
[ 29%] Generating vk_enum_string_helper.h
[ 33%] Generating vk_safe_struct.h
[ 29%] Generating vk_layer_dispatch_table.h
[ 29%] Generating vk_object_types.h
[ 37%] Generating vk_extension_helper.h
[ 41%] Generating vk_typemap_helper.h
[ 41%] Built target loader_gen_files
[ 41%] Built target generate_helper_files
Scanning dependencies of target asm_offset
[ 45%] Building C object loader/CMakeFiles/asm_offset.dir/asm_offset.c.o
[ 50%] Linking C executable asm_offset
[ 50%] Built target asm_offset
Scanning dependencies of target loader_asm_gen_files
[ 54%] Generating gen_defines.asm
[ 54%] Built target loader_asm_gen_files
Scanning dependencies of target vulkan
[ 58%] Building C object loader/CMakeFiles/vulkan.dir/wsi.c.o
[ 75%] Building C object loader/CMakeFiles/vulkan.dir/loader.c.o
[ 75%] Building C object loader/CMakeFiles/vulkan.dir/trampoline.c.o
[ 75%] Building C object loader/CMakeFiles/vulkan.dir/extension_manual.c.o
[ 75%] Building C object loader/CMakeFiles/vulkan.dir/debug_utils.c.o
[ 83%] Building C object loader/CMakeFiles/vulkan.dir/cJSON.c.o
[ 83%] Building C object loader/CMakeFiles/vulkan.dir/murmurhash.c.o
[ 87%] Building C object loader/CMakeFiles/vulkan.dir/dev_ext_trampoline.c.o
[ 91%] Building C object loader/CMakeFiles/vulkan.dir/phys_dev_ext.c.o
In file included from /home//Documents/Vulkan-Loader/loader/extension_manual.c:30:0:
/home/
/Documents/Vulkan-Loader/loader/wsi.h:168:82: error: unknown type name ‘VkDisplayProperties2KHR’; did you mean ‘VkDisplayPropertiesKHR’?
VkDisplayProperties2KHR pProperties);
^~~~~~~~~~~~~~~~~~~~~~~
VkDisplayPropertiesKHR
In file included from /home/
/Documents/Vulkan-Loader/loader/trampoline.c:32:0:
/home/
/Documents/Vulkan-Loader/loader/wsi.h:168:82: error: unknown type name ‘VkDisplayProperties2KHR’; did you mean ‘VkDisplayPropertiesKHR’?
VkDisplayProperties2KHR pProperties);
^~~~~~~~~~~~~~~~~~~~~~~
VkDisplayPropertiesKHR
/home/
/Documents/Vulkan-Loader/loader/wsi.h:172:87: error: unknown type name ‘VkDisplayPlaneProperties2KHR’; did you mean ‘VkDisplayPlanePropertiesKHR’?
VkDisplayPlaneProperties2KHR pProperties);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
VkDisplayPlanePropertiesKHR
/home/
/Documents/Vulkan-Loader/loader/wsi.h:172:87: error: unknown type name ‘VkDisplayPlaneProperties2KHR’; did you mean ‘VkDisplayPlanePropertiesKHR’?
VkDisplayPlaneProperties2KHR pProperties);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
VkDisplayPlanePropertiesKHR
In file included from /home/
/Documents/Vulkan-Loader/loader/gpa_helper.h:24:0,
from /home/
/Documents/Vulkan-Loader/loader/loader.c:48:
/home/
/Documents/Vulkan-Loader/loader/wsi.h:168:82: error: unknown type name ‘VkDisplayProperties2KHR’; did you mean ‘VkDisplayPropertiesKHR’?
VkDisplayProperties2KHR pProperties);
^~~~~~~~~~~~~~~~~~~~~~~
VkDisplayPropertiesKHR
/home/
/Documents/Vulkan-Loader/loader/wsi.h:176:72: error: unknown type name ‘VkDisplayModeProperties2KHR’; did you mean ‘VkDisplayModePropertiesKHR’?
VkDisplayModeProperties2KHR pProperties);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
VkDisplayModePropertiesKHR
/home/
/Documents/Vulkan-Loader/loader/wsi.h:176:72: error: unknown type name ‘VkDisplayModeProperties2KHR’; did you mean ‘VkDisplayModePropertiesKHR’?
VkDisplayModeProperties2KHR pProperties);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
VkDisplayModePropertiesKHR
/home/
/Documents/Vulkan-Loader/loader/wsi.h:179:81: error: unknown type name ‘VkDisplayPlaneInfo2KHR’
const VkDisplayPlaneInfo2KHR pDisplayPlaneInfo,
^~~~~~~~~~~~~~~~~~~~~~
In file included from /home/
/Documents/Vulkan-Loader/loader/wsi.c:30:0:
/home/
/Documents/Vulkan-Loader/loader/wsi.h:168:82: error: unknown type name ‘VkDisplayProperties2KHR’; did you mean ‘VkDisplayPropertiesKHR’?
VkDisplayProperties2KHR pProperties);
^~~~~~~~~~~~~~~~~~~~~~~
VkDisplayPropertiesKHR
/home/
/Documents/Vulkan-Loader/loader/wsi.h:179:81: error: unknown type name ‘VkDisplayPlaneInfo2KHR’
const VkDisplayPlaneInfo2KHR pDisplayPlaneInfo,
^~~~~~~~~~~~~~~~~~~~~~
/home/
/Documents/Vulkan-Loader/loader/wsi.h:172:87: error: unknown type name ‘VkDisplayPlaneProperties2KHR’; did you mean ‘VkDisplayPlanePropertiesKHR’?
VkDisplayPlaneProperties2KHR pProperties);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
VkDisplayPlanePropertiesKHR
/home/
/Documents/Vulkan-Loader/loader/wsi.h:180:75: error: unknown type name ‘VkDisplayPlaneCapabilities2KHR’; did you mean ‘VkDisplayPlaneCapabilitiesKHR’?
VkDisplayPlaneCapabilities2KHR pCapabilities);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
VkDisplayPlaneCapabilitiesKHR
/home/
/Documents/Vulkan-Loader/loader/wsi.h:180:75: error: unknown type name ‘VkDisplayPlaneCapabilities2KHR’; did you mean ‘VkDisplayPlaneCapabilitiesKHR’?
VkDisplayPlaneCapabilities2KHR pCapabilities);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
VkDisplayPlaneCapabilitiesKHR
/home/
/Documents/Vulkan-Loader/loader/wsi.h:172:87: error: unknown type name ‘VkDisplayPlaneProperties2KHR’; did you mean ‘VkDisplayPlanePropertiesKHR’?
VkDisplayPlaneProperties2KHR pProperties);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
VkDisplayPlanePropertiesKHR
/home/
/Documents/Vulkan-Loader/loader/wsi.h:176:72: error: unknown type name ‘VkDisplayModeProperties2KHR’; did you mean ‘VkDisplayModePropertiesKHR’?
VkDisplayModeProperties2KHR pProperties);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
VkDisplayModePropertiesKHR
/home/
/Documents/Vulkan-Loader/loader/wsi.h:179:81: error: unknown type name ‘VkDisplayPlaneInfo2KHR’
const VkDisplayPlaneInfo2KHR pDisplayPlaneInfo,
^~~~~~~~~~~~~~~~~~~~~~
/home/
/Documents/Vulkan-Loader/loader/wsi.h:176:72: error: unknown type name ‘VkDisplayModeProperties2KHR’; did you mean ‘VkDisplayModePropertiesKHR’?
VkDisplayModeProperties2KHR pProperties);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
VkDisplayModePropertiesKHR
/home/
/Documents/Vulkan-Loader/loader/wsi.h:179:81: error: unknown type name ‘VkDisplayPlaneInfo2KHR’
const VkDisplayPlaneInfo2KHR pDisplayPlaneInfo,
^~~~~~~~~~~~~~~~~~~~~~
/home/
/Documents/Vulkan-Loader/loader/wsi.h:180:75: error: unknown type name ‘VkDisplayPlaneCapabilities2KHR’; did you mean ‘VkDisplayPlaneCapabilitiesKHR’?
VkDisplayPlaneCapabilities2KHR pCapabilities);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
VkDisplayPlaneCapabilitiesKHR
/home/
/Documents/Vulkan-Loader/loader/wsi.h:180:75: error: unknown type name ‘VkDisplayPlaneCapabilities2KHR’; did you mean ‘VkDisplayPlaneCapabilitiesKHR’?
VkDisplayPlaneCapabilities2KHR pCapabilities);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
VkDisplayPlaneCapabilitiesKHR
loader/CMakeFiles/vulkan.dir/build.make:62: recipe for target 'loader/CMakeFiles/vulkan.dir/extension_manual.c.o' failed
make[2]: *** [loader/CMakeFiles/vulkan.dir/extension_manual.c.o] Error 1
make[2]: *** Waiting for unfinished jobs....
loader/CMakeFiles/vulkan.dir/build.make:110: recipe for target 'loader/CMakeFiles/vulkan.dir/trampoline.c.o' failed
make[2]: *** [loader/CMakeFiles/vulkan.dir/trampoline.c.o] Error 1
/home/
/Documents/Vulkan-Loader/loader/wsi.c: In function ‘wsi_create_instance’:
/home/
/Documents/Vulkan-Loader/loader/wsi.c:125:61: error: ‘VK_KHR_GET_DISPLAY_PROPERTIES_2_EXTENSION_NAME’ undeclared (first use in this function); did you mean ‘VK_KHR_GET_PHYSICAL_DEVICE_PROPERTIES_2_EXTENSION_NAME’?
if (strcmp(pCreateInfo->ppEnabledExtensionNames[i], VK_KHR_GET_DISPLAY_PROPERTIES_2_EXTENSION_NAME) == 0) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
VK_KHR_GET_PHYSICAL_DEVICE_PROPERTIES_2_EXTENSION_NAME
/home/
/Documents/Vulkan-Loader/loader/wsi.c:125:61: note: each undeclared identifier is reported only once for each function it appears in
/home/
/Documents/Vulkan-Loader/loader/wsi.c: At top level:
/home/
/Documents/Vulkan-Loader/loader/wsi.c:1607:87: error: unknown type name ‘VkDisplayProperties2KHR’; did you mean ‘VkDisplayPropertiesKHR’?
VkDisplayProperties2KHR pProperties) {
^~~~~~~~~~~~~~~~~~~~~~~
VkDisplayPropertiesKHR
/home/
/Documents/Vulkan-Loader/loader/wsi.c:1616:82: error: unknown type name ‘VkDisplayProperties2KHR’; did you mean ‘VkDisplayPropertiesKHR’?
VkDisplayProperties2KHR pProperties) {
^~~~~~~~~~~~~~~~~~~~~~~
VkDisplayPropertiesKHR
/home/
/Documents/Vulkan-Loader/loader/wsi.c:1656:64: error: unknown type name ‘VkDisplayPlaneProperties2KHR’; did you mean ‘VkDisplayPlanePropertiesKHR’?
VkPhysicalDevice physicalDevice, uint32_t pPropertyCount, VkDisplayPlaneProperties2KHR pProperties) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
VkDisplayPlanePropertiesKHR
/home/
/Documents/Vulkan-Loader/loader/wsi.c:1665:87: error: unknown type name ‘VkDisplayPlaneProperties2KHR’; did you mean ‘VkDisplayPlanePropertiesKHR’?
VkDisplayPlaneProperties2KHR pProperties) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
VkDisplayPlanePropertiesKHR
/home/
/Documents/Vulkan-Loader/loader/wsi.c:1707:77: error: unknown type name ‘VkDisplayModeProperties2KHR’; did you mean ‘VkDisplayModePropertiesKHR’?
VkDisplayModeProperties2KHR pProperties) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~
VkDisplayModePropertiesKHR
/home/
/Documents/Vulkan-Loader/loader/wsi.c:1716:72: error: unknown type name ‘VkDisplayModeProperties2KHR’; did you mean ‘VkDisplayModePropertiesKHR’?
VkDisplayModeProperties2KHR pProperties) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~
VkDisplayModePropertiesKHR
/home/
/Documents/Vulkan-Loader/loader/wsi.c:1756:86: error: unknown type name ‘VkDisplayPlaneInfo2KHR’
const VkDisplayPlaneInfo2KHR pDisplayPlaneInfo,
^~~~~~~~~~~~~~~~~~~~~~
/home/
/Documents/Vulkan-Loader/loader/wsi.c:1757:80: error: unknown type name ‘VkDisplayPlaneCapabilities2KHR’; did you mean ‘VkDisplayPlaneCapabilitiesKHR’?
VkDisplayPlaneCapabilities2KHR pCapabilities) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
VkDisplayPlaneCapabilitiesKHR
/home/
/Documents/Vulkan-Loader/loader/wsi.c:1765:81: error: unknown type name ‘VkDisplayPlaneInfo2KHR’
const VkDisplayPlaneInfo2KHR pDisplayPlaneInfo,
^~~~~~~~~~~~~~~~~~~~~~
/home/
/Documents/Vulkan-Loader/loader/wsi.c:1766:75: error: unknown type name ‘VkDisplayPlaneCapabilities2KHR’; did you mean ‘VkDisplayPlaneCapabilitiesKHR’?
VkDisplayPlaneCapabilities2KHR pCapabilities) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
VkDisplayPlaneCapabilitiesKHR
/home/
/Documents/Vulkan-Loader/loader/wsi.c: In function ‘wsi_swapchain_instance_gpa’:
/home/
/Documents/Vulkan-Loader/loader/wsi.c:1979:68: error: ‘vkGetPhysicalDeviceDisplayProperties2KHR’ undeclared (first use in this function); did you mean ‘vkGetPhysicalDeviceDisplayPropertiesKHR’?
addr = ptr_instance->wsi_display_props2_enabled ? (void )vkGetPhysicalDeviceDisplayProperties2KHR : NULL;
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
vkGetPhysicalDeviceDisplayPropertiesKHR
/home/
/Documents/Vulkan-Loader/loader/wsi.c:1983:68: error: ‘vkGetPhysicalDeviceDisplayPlaneProperties2KHR’ undeclared (first use in this function); did you mean ‘vkGetPhysicalDeviceDisplayPlanePropertiesKHR’?
addr = ptr_instance->wsi_display_props2_enabled ? (void )vkGetPhysicalDeviceDisplayPlaneProperties2KHR : NULL;
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
vkGetPhysicalDeviceDisplayPlanePropertiesKHR
/home/
/Documents/Vulkan-Loader/loader/wsi.c:1987:68: error: ‘vkGetDisplayModeProperties2KHR’ undeclared (first use in this function); did you mean ‘vkGetDisplayModePropertiesKHR’?
addr = ptr_instance->wsi_display_props2_enabled ? (void )vkGetDisplayModeProperties2KHR : NULL;
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
vkGetDisplayModePropertiesKHR
/home/
*/Documents/Vulkan-Loader/loader/wsi.c:1991:68: error: ‘vkGetDisplayPlaneCapabilities2KHR’ undeclared (first use in this function); did you mean ‘vkGetDisplayPlaneCapabilitiesKHR’?
*addr = ptr_instance->wsi_display_props2_enabled ? (void *)vkGetDisplayPlaneCapabilities2KHR : NULL;
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
vkGetDisplayPlaneCapabilitiesKHR
loader/CMakeFiles/vulkan.dir/build.make:134: recipe for target 'loader/CMakeFiles/vulkan.dir/wsi.c.o' failed
make[2]: *** [loader/CMakeFiles/vulkan.dir/wsi.c.o] Error 1
loader/CMakeFiles/vulkan.dir/build.make:86: recipe for target 'loader/CMakeFiles/vulkan.dir/loader.c.o' failed
make[2]: *** [loader/CMakeFiles/vulkan.dir/loader.c.o] Error 1
CMakeFiles/Makefile2:237: recipe for target 'loader/CMakeFiles/vulkan.dir/all' failed
make[1]: *** [loader/CMakeFiles/vulkan.dir/all] Error 2
Makefile:129: recipe for target 'all' failed
make: *** [all] Error 2

MSYS2/MinGW32 linking issue (loader/libvulkan.dll): undefined reference to `_imp__CM_…' symbols

Related to media-autobuild_suite issue 883

The archive logs.zip contains, among many other log files, also vulkan-loader-git/build-32bit/ab-suite.make.log as console log of the make step; here some contained error messages from the tail:

...
[1/1] Linking C shared library loader\libvulkan.dll
FAILED: loader/libvulkan.dll loader/libvulkan.dll.a 
cmd.exe /C "cd . && H:\development\media-autobuild_suite-master\msys64\mingw32\bin\gcc.exe  -mthreads -mtune=generic -O2 -pipe -D_WIN32_WINNT=0x0600 -D__STDC_FORMAT_MACROS -std=c99 -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -fno-strict-aliasing -fno-builtin-memcmp -Wimplicit-fallthrough=0 -fvisibility=hidden -Wpointer-arith -O3 -DNDEBUG  -pipe -static-libgcc -static-libstdc++ -shared -o loader\libvulkan.dll -Wl,--out-implib,loader\libvulkan.dll.a -Wl,--major-image-version,1,--minor-image-version,1 loader/CMakeFiles/vulkan.dir/extension_manual.c.o loader/CMakeFiles/vulkan.dir/loader.c.o loader/CMakeFiles/vulkan.dir/trampoline.c.o loader/CMakeFiles/vulkan.dir/wsi.c.o loader/CMakeFiles/vulkan.dir/debug_utils.c.o loader/CMakeFiles/vulkan.dir/cJSON.c.o loader/CMakeFiles/vulkan.dir/murmurhash.c.o loader/CMakeFiles/vulkan.dir/dev_ext_trampoline.c.o loader/CMakeFiles/vulkan.dir/phys_dev_ext.c.o loader/CMakeFiles/vulkan.dir/unknown_ext_chain.c.o  -ldl -lpthread -lm -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd ."
H:/development/media-autobuild_suite-master/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.3.0/../../../../i686-w64-mingw32/bin/ld.exe: loader/CMakeFiles/vulkan.dir/loader.c.o:loader.c:(.text+0xbd71): undefined reference to `_imp__CM_Open_DevNode_Key@24'
H:/development/media-autobuild_suite-master/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.3.0/../../../../i686-w64-mingw32/bin/ld.exe: loader/CMakeFiles/vulkan.dir/loader.c.o:loader.c:(.text+0xc220): undefined reference to `_imp__CM_Get_Device_ID_List_SizeW@12'
H:/development/media-autobuild_suite-master/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.3.0/../../../../i686-w64-mingw32/bin/ld.exe: loader/CMakeFiles/vulkan.dir/loader.c.o:loader.c:(.text+0xc2b1): undefined reference to `_imp__CM_Get_Device_ID_ListW@16'
H:/development/media-autobuild_suite-master/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.3.0/../../../../i686-w64-mingw32/bin/ld.exe: loader/CMakeFiles/vulkan.dir/loader.c.o:loader.c:(.text+0xc37a): undefined reference to `_imp__CM_Locate_DevNodeW@12'
H:/development/media-autobuild_suite-master/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.3.0/../../../../i686-w64-mingw32/bin/ld.exe: loader/CMakeFiles/vulkan.dir/loader.c.o:loader.c:(.text+0xc3aa): undefined reference to `_imp__CM_Get_DevNode_Status@16'
H:/development/media-autobuild_suite-master/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.3.0/../../../../i686-w64-mingw32/bin/ld.exe: loader/CMakeFiles/vulkan.dir/loader.c.o:loader.c:(.text+0xc461): undefined reference to `_imp__CM_Get_Child@12'
H:/development/media-autobuild_suite-master/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.3.0/../../../../i686-w64-mingw32/bin/ld.exe: loader/CMakeFiles/vulkan.dir/loader.c.o:loader.c:(.text+0xc4fb): undefined reference to `_imp__CM_Get_Sibling@12'
H:/development/media-autobuild_suite-master/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.3.0/../../../../i686-w64-mingw32/bin/ld.exe: loader/CMakeFiles/vulkan.dir/loader.c.o:loader.c:(.text+0xc527): undefined reference to `_imp__CM_Get_Device_IDW@16'
H:/development/media-autobuild_suite-master/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.3.0/../../../../i686-w64-mingw32/bin/ld.exe: loader/CMakeFiles/vulkan.dir/loader.c.o:loader.c:(.text+0xc587): undefined reference to `_imp__CM_Get_DevNode_Registry_PropertyW@24'
collect2.exe: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

Can you imagine reasons why the linker does not find symbols with the reported names? Is it a naming convention issue or a lack of supported driver exports (in case there is any step which reads API names out of existing driver DLL's, like for OpenCL headers)?

Build fails if old version of Vulkan-Loader is installed

Hi all,

I am the Gentoo maintainer of the Vulkan-* packages.

We hit an issue when adding support for Vulkan-Loader version 1.1.77.0. The issue is related to #42

If you have Vulkan-Loader < 1.1.77.0 installed when compiling Vulkan-Loader 1.1.77.0, it will use the already-installed '/usr/include/vulkan/vk_layer_dispatch_table.h' header. This causes compile errors because it is not the file which would have been generated:

https://658900.bugs.gentoo.org/attachment.cgi?id=536992

It seems the only way to fix this error is to force regeneration of the vk_layer_dispatch_table.h by deleting or renaming it.

We need this to be handled by the build system. An ideal solution seems to be to universally regenerate vk_layer_dispatch_table.h.

Distro bug report: https://bugs.gentoo.org/658900

Thank you,
Sarnex

Add mode/option to validate dispatchable handles...

From: KhronosGroup/Vulkan-ValidationLayers#288 , based on nimious/vulkan#5

When an invalid dispatchable handle (VkInstance, VkPhysicalDevice, VkDevice, VkQueue, or VkCommandBuffer) is provided by the application, the loader will (in all likelihood) crash before reaching the validation layers. Testing the validity of these handles would be a performance hit, but the loader and validation layers currently provide no capability for debugging this issue.

This mode would allow for validation of these parameters when enabled, while not causing a performance penalty in the default off setting.

`vkGetInstanceProcAddr` disabled extension commands get undefined behavior or NULL?

LoaderAndLayerInterface.md:

If you get an Extension function using either vkGetInstanceProcAddr or vkGetDeviceProcAddr, but fail to enable it, you could experience undefined behavior. This should actually be flagged if you run with Validation layers enabled.

The vkGetInstanceProcAddr Spec:

instance pName return value
* NULL undefined
invalid instance * undefined
instance enabled instance extension commands for instance fp1
instance * (any pName not covered above) NULL

So which is it?

Loader should throw error if validation layers are enabled by the app but not present in the system

From a discussion in KhronosGroup/Vulkan-ValidationLayers#143, it looks like the loader will not error out when the app requests that VK_LUNARG_standard_validation be enabled but the validation layers are not installed in the system.

This seems like a loader bug, vkCreateInstance should probably fail in this case. Instead, vkCreateInstance succeeds and EXT_debug_utils / EXT_debug_report callbacks will be triggered with info messages during device creation, but no validation errors will come through.

Vulkan loader doesn't handle vkGetDeviceQueue2 properly

The Vulkan loader doesn't handle vkGetDeviceQueue2 in the same way it handles vkGetDeviceQueue (more specifically, vkGetDeviceQueue2 is not handled by loader_non_passthrough_gdpa()). This results in validation layers not working on content using the Vulkan 1.1 protected memory feature.

PR: #81

macos: A loader build directory is in the implicit layer search path

Spotted while looking at an unrelated LunarXChange issue. Reproduce by running any app that uses the loader with VK_LOADER_DEBUG=all.

The directory used to build the loader is prefixed to one of the standard search paths. For example, if the loader was built in /mytree/Vulkan-Loader/build, the directory /mytree/Vulkan-Loader/build/etc/vulkan/implicit_layer.d appears in the implicit layer search path.

I suspect that the CMake and/or the loader code that collects all the XDG and "extra" search paths is adding a directory that it shouldn't. Some extra differentiation with the Linux code may be needed here.

Loader should issue informational message when loading each layer

In order to provide run-time confirmation of layer configuration, the loader should emit an INFO message for each layer loaded, including at least name and path.

@krOoze -- What in addition is needed to meet your use cases below?

Moved to loader as it doesn't abuse the VK_DEBUG_REPORT_PERFORMANCE_WARNING_BIT_EXT, and addresses the required use cases below

Issue by krOoze (MIGRATED)
Wednesday Nov 15, 2017 at 16:14 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#2207

Original Text:

Enabled validation layers should give performance warning.

The primary motivation is that I would want a feedback from the implementation, that I enabled the layers properly and my validation environment works. The message could be something like:

Enabling validation layers: [ordered list of layers or the standard_validation] [version] [path] [Debug|Release] {for the duration of vkCreateInstance and vkDestroyInstance}. Receiving messages [debug callback flags]. This will likely have negative performance impact.

The reason for using VK_DEBUG_REPORT_PERFORMANCE_WARNING_BIT_EXT is because it technically is a performance drain. (And it is simpler to have this enabled, otherwise it could be INFO, but that would require filtering out all the other unwanted INFO messages.)

It probably have to be logged twice if the user uses both the temporary and regular debug callback. It is a stretch though to pass the temporary callback as a PERFORMANCE_WARNING...

Loader tests LayerPresent and LayersMatch fail on AMD

LayerPresent and LayersMatch tests fail on AMD 18.11.1:

[ RUN      ] CreateInstance.LayerPresent
vulkan-loader\tests\loader_validation_tests.cpp(456): error: Expected equality of these values:
  result
    Which is: -6
  VK_SUCCESS
    Which is: 0
[  FAILED  ] CreateInstance.LayerPresent (5 ms)
[ RUN      ] EnumerateDeviceLayers.LayersMatch
vulkan-loader\tests\loader_validation_tests.cpp(564): error: Expected equality of these values:
  result
    Which is: -6
  VK_SUCCESS
    Which is: 0
[  FAILED  ] EnumerateDeviceLayers.LayersMatch (5 ms)

Run with .\run_all_tests.ps1 -Debug from PS console.

The tests try to enable some weird non-existent layers, so it is not all that surprising.

Vulkan-loader dlopen large overhead

I noticed a large difference between opengl and vulkan application startup running angle tests, and traced the cost down to dlopen. In one example, I have a test that runs in ~80ms on opengl and ~500ms in vulkan. Callgrind shows that the cost difference is almost entirely coming from dlopen, on my machine almost equally split between loading ICD and layer .so files.

Here is a quick printf trace of what's going on:

vkEnumerateInstanceLayerProperties(&count, nullptr);
vkEnumerateInstanceLayerProperties(7, data);
vkEnumerateInstanceExtensionProperties(&count, nullptr);
 loader_scanned_icd_add()
  dlopen(/usr/lib/x86_64-linux-gnu/libvulkan_radeon.so)
 loader_scanned_icd_add()
  dlopen(libGL.so.1)
 loader_scanned_icd_add()
  dlopen(/usr/lib/x86_64-linux-gnu/libvulkan_intel.so)
vkEnumerateInstanceExtensionProperties(12, data);
 loader_scanned_icd_add()
  dlopen(/usr/lib/x86_64-linux-gnu/libvulkan_radeon.so)
 loader_scanned_icd_add()
  dlopen(libGL.so.1)
 loader_scanned_icd_add()
  dlopen(/usr/lib/x86_64-linux-gnu/libvulkan_intel.so)
vkEnumerateInstance*() done
vkCreateInstance()
 loader_scanned_icd_add()
  dlopen(/usr/lib/x86_64-linux-gnu/libvulkan_radeon.so)
 loader_scanned_icd_add()
  dlopen(libGL.so.1)
 loader_scanned_icd_add()
  dlopen(/usr/lib/x86_64-linux-gnu/libvulkan_intel.so)
 loader_open_layer_lib()
  dlopen(angledata/../libVkLayer_unique_objects.so)
 loader_open_layer_lib()
  dlopen(angledata/../libVkLayer_core_validation.so)
 loader_open_layer_lib()
  dlopen(angledata/../libVkLayer_object_tracker.so)
 loader_open_layer_lib()
  dlopen(angledata/../libVkLayer_parameter_validation.so)
 loader_open_layer_lib()
  dlopen(angledata/../libVkLayer_threading.so)
vkCreateInstance() done
vkEnumeratePhysicalDevices(&count, nullptr);
vkEnumeratePhysicalDevices(1, data);
vkEnumeratePhysicalDevices() done
vkEnumerateDeviceLayerProperties(&count, nullptr);
vkEnumerateDeviceLayerProperties(1, data);
vkEnumerateDeviceExtensionProperties(&count, nullptr);
vkEnumerateDeviceExtensionProperties(33, data);
vkEnumerateDevice*() done
vkCreateDevice()
 loader_open_layer_lib()
  dlopen(angledata/../libVkLayer_unique_objects.so)
 loader_open_layer_lib()
  dlopen(angledata/../libVkLayer_core_validation.so)
 loader_open_layer_lib()
  dlopen(angledata/../libVkLayer_object_tracker.so)
 loader_open_layer_lib()
  dlopen(angledata/../libVkLayer_parameter_validation.so)
 loader_open_layer_lib()
  dlopen(angledata/../libVkLayer_threading.so)
vkCreateDevice() done

As you can see, there are multiple inefficiencies here:

  • Each vkEnumerateInstanceExtensionProperties() call is loading all the ICDs. This can be worked around by providing a large buffer from the start and hope there are fewer extensions (and avoid a second call with the right size).
  • vkCreateInstance() reloads all the ICDs, and there is no way to avoid this reload (once already done by vkEnumerateInstanceExtensionProperties() and thrown away evidently).
  • vkCreateInstance() loads all the layers. The Uber Layer work will probably improve this area as there would be many fewer layers to load.
  • vkCreateDevice() reloads many of the same layers! Again, there is no way to work around this.

If every .so file is loaded only once, the load time (on my machine) would easily get cut in half. With the Uber Layer, that may cut it again in half. Can you please consider looking into this?

One idea could be to keep the .so files open until vkCreateDevice(), at which point any unused one is closed. The handles could be stored in a global (mutex-protected, or thread-local) cache (keyed on filepath).

Loader calls vk_icdGetInstanceProcAddr for vkCreateSwapchainKHR

Issue by polarina (MIGRATED)
Tuesday Nov 07, 2017 at 19:29 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#2190


The loader is calling vk_icdGetInstanceProcAddr to lookup the ICD's vkCreateSwapchainKHR function, which is a device-level function. The loader should be using vkGetDeviceProcAddr instead.

Documentation says that vk_icdGetInstanceProcAddr is only required to support lookups for global- and instance-level functions.

Vulkan-loader build fail

cmake fails with errors like:
CMake Error at CMakeLists.txt:142 (add_compile_options):
Error evaluating generator expression:

$<COMPILE_LANGUAGE:C>

$<COMPILE_LANGUAGE:...> may not be used with Visual Studio generators.

see attached log
log.txt

Unknown masm options cause build to fail

It looks like for the ninja backend cmake is passing /WX to masm, however it's also passing a bunch of what look like cl flags that masm doesn't know how to deal with.

Output from build:

[1/2] Building ASM_MASM object loader\CMakeFiles\loader-opt.dir\unknown_ext_chain_masm.asm.obj
FAILED: loader/CMakeFiles/loader-opt.dir/unknown_ext_chain_masm.asm.obj 
C:\PROGRA~2\MICROS~1\Preview\ENTERP~1\VC\Tools\MSVC\1416~1.269\bin\Hostx64\x64\ml64.exe -DAPI_NAME=\"Vulkan\" -DLOADER_DYNAMIC_LIB -DVK_USE_PLATFORM_WIN32_KHR -DWIN32_LEAN_AND_MEAN -IC:\Users\bartoc\Code\install\include -I..\loader -Iloader -I. /WX /GR- /w34456 /w34701 /w34703 /w34057 /w34245 /guard:cf /c  /Fo loader\CMakeFiles\loader-opt.dir\unknown_ext_chain_masm.asm.obj ..\loader\unknown_ext_chain_masm.asm
Microsoft (R) Macro Assembler (x64) Version 14.16.26926.0
Copyright (C) Microsoft Corporation.  All rights reserved.

MASM : warning A4018:invalid command-line option : /GR-
MASM : warning A4018:invalid command-line option : /w34456
MASM : warning A4018:invalid command-line option : /w34701
MASM : warning A4018:invalid command-line option : /w34703
MASM : warning A4018:invalid command-line option : /w34057
MASM : warning A4018:invalid command-line option : /w34245
MASM : warning A4018:invalid command-line option : /guard:cf
 Assembling: ..\loader\unknown_ext_chain_masm.asm
ninja: build stopped: subcommand failed.

Unreleased extension with physical device parameters

I'm working with a new extension (not release yet) that introduces new entry points for which the first parameter is a physical device.
If I try to use those entrypoints by getting a pointer to them through vkGetInstanceProcAddr() and then calling the returned value, the application crashes in the returned function pointer.
I'm wondering whether that is something supported or not.

In my particular case, the function pointer return by vkGetInstanceProcAddr() is vkdev_ext226.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.