khronosgroup / vulkan-extensionlayer Goto Github PK

View Code? Open in Web Editor NEW

121.0 42.0 39.0 6.52 MB

Layer providing Vulkan features when native support is unavailable

Home Page: https://vulkan.lunarg.com/doc/sdk/latest/linux/synchronization2_layer.html

License: Apache License 2.0

CMake 0.51% C++ 18.73% C 77.99% Python 1.80% Shell 0.18% Batchfile 0.18% GLSL 0.61%

vulkan

vulkan-extensionlayer's Introduction

Vulkan Extension Layer (VEL)

Introduction

There are some extensions and features in Vulkan that are not available everywhere due to various reasons. While not available, some extensions are capable of being done as layer and mapping to any Vulkan implementation regardless of it supporting the desired functionality or not.

Currently implemented extensions

Layer	Extension provided	Version	File(s)	Point of Contact
VK_LAYER_KHRONOS_timeline_semaphore	VK_KHR_timeline_semaphore	1	layers/timeline_semaphore.c	@llandwerlin-intel
VK_LAYER_KHRONOS_synchronization2	VK_KHR_synchronization2	1	layers/synchronization2.cpp	@jeremyg-lunarg
VK_LAYER_KHRONOS_shader_object	VK_EXT_shader_object	1	layers/shader_object.cpp	@daniel-story
VK_LAYER_KHRONOS_memory_decompression	VK_NV_memory_decompression	1	layers/decompression/decompression.cpp	@vkushwaha-nv

If you find a problem with one of the layers, please file an Issue and tag the Point of Contact listed in the table above.

NOTE: Not all layers are supported on every platform, please read the documentation for the layer for details.

Information for Developing or Contributing:

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

How to Build and Run

BUILD.md Includes directions for building all components and testing them.

License

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

See LICENSE for a full list of licenses used in this repository.

vulkan-extensionlayer's People

Contributors

Stargazers

Watchers

vulkan-extensionlayer's Issues

Is this intended to work on Windows

I'm not asking for it to be supported. I just don't know if I should even try.

E.g. it's based on pthreads.h which is not native to Windows. There are emulation libraries, but I don't want to work to hard for that at the moment

Get build flow cleaned up

In order to improve adding more layers in the future and making sure everything works on major platforms (Windows, Linux, Android, etc) there are a few things that could be fixed

Bonus:

clang-format check in CI (would just use the same config as validation layers)
Markdown write up with some information about background of each layer added

Is it possible to implement a timeline semaphore with arbitrary payload value by any means?

I'm looking for a way to implement a semaphore with arbitrary payload value.
What I want is that I can signal a semaphore with any uint64_t value, and wait for it to become less/equal/greater than the signaled value.

Both of the VK_KHR_timeline_semaphore extension and this Vulkan-ExtensionLayer requires that the value in question must increase, going backwards is not allowed.

I wonder is it possible to emulate such a semaphore in vulkan layer or just by top level vulkan apis?

synchronization2 layer doesn't implement descriptor updates

It's possible to write a sampled image descriptor which expects the image subresource to be in VK_IMAGE_LAYOUT_READ_ONLY_OPTIMAL, which was introduced in sync2. The sync2 layer doesn't implement vkUpdateDescriptorSets and other descriptor update functions and an invalid value will just be passed further down the dispatch chain.

The workaround is to not use sync2 layouts when an image subresource will be accessed through a descriptor.

A possible fix would need to implement vkCreateImageView so that it can tell the aspect bits when writing the descriptor. Another simpler, but possibly worse-performing, fix would map all read-only layouts to general.

BugGuy11

Unplugging.

Test failure on AMD 6800 machines

Seeing a test failure with ShaderObjectTest.LinkedShadersDraw using the main branch on machines with an AMD Radeon RX 6800 XT (RADV NAVI21) GPU. This was ran on Ubuntu 22.04.

[==========] Running 22 tests from 4 test suites.
[----------] Global test environment set-up.
[----------] 13 tests from Sync2Test
[ RUN      ] Sync2Test.OwnershipTranfersImage
[       OK ] Sync2Test.OwnershipTranfersImage (32 ms)
[ RUN      ] Sync2Test.OwnershipTranfersBuffer
[       OK ] Sync2Test.OwnershipTranfersBuffer (17 ms)
[ RUN      ] Sync2Test.SecondaryCommandBufferBarrier
[       OK ] Sync2Test.SecondaryCommandBufferBarrier (16 ms)
[ RUN      ] Sync2Test.SecondaryCommandBufferImageLayoutTransitions
[       OK ] Sync2Test.SecondaryCommandBufferImageLayoutTransitions (17 ms)
[ RUN      ] Sync2Test.QueueSubmitSemaphoresAndLayoutTracking
[       OK ] Sync2Test.QueueSubmitSemaphoresAndLayoutTracking (17 ms)
[ RUN      ] Sync2Test.CommandBufferSimultaneousUseSync
[       OK ] Sync2Test.CommandBufferSimultaneousUseSync (15 ms)
[ RUN      ] Sync2Test.BarrierLayoutToImageUsage
[       OK ] Sync2Test.BarrierLayoutToImageUsage (16 ms)
[ RUN      ] Sync2Test.WaitEventThenSet
[       OK ] Sync2Test.WaitEventThenSet (11901 ms)
[ RUN      ] Sync2Test.TwoQueueSubmitsSeparateQueuesWithSemaphoreAndOneFenceTwoWFF
/home/lunarg/.jenkins/mel/Vulkan-ExtensionLayer/tests/synchronization2_tests.cpp:858: Skipped
             TEST SKIPPED:  Queue family needs to have multiple queues to run this test.

[  SKIPPED ] Sync2Test.TwoQueueSubmitsSeparateQueuesWithSemaphoreAndOneFenceTwoWFF (17 ms)
[ RUN      ] Sync2Test.TwoSubmitInfosWithSemaphoreOneQueueSubmitsOneFence
[       OK ] Sync2Test.TwoSubmitInfosWithSemaphoreOneQueueSubmitsOneFence (16 ms)
[ RUN      ] Sync2Test.ClearDepthStencilWithValidRange
[       OK ] Sync2Test.ClearDepthStencilWithValidRange (17 ms)
[ RUN      ] Sync2Test.QueueSubmitTimelineSemaphore
[       OK ] Sync2Test.QueueSubmitTimelineSemaphore (18 ms)
[ RUN      ] Sync2Test.SwapchainImage
[       OK ] Sync2Test.SwapchainImage (17 ms)
[----------] 13 tests from Sync2Test (12122 ms total)

[----------] 1 test from Sync2CompatTest
[ RUN      ] Sync2CompatTest.Vulkan10
[       OK ] Sync2CompatTest.Vulkan10 (13 ms)
[----------] 1 test from Sync2CompatTest (13 ms total)

[----------] 2 tests from DecompressionTest
[ RUN      ] DecompressionTest.DecompressMemory
[       OK ] DecompressionTest.DecompressMemory (19 ms)
[ RUN      ] DecompressionTest.DecompressMemoryIndirect
[       OK ] DecompressionTest.DecompressMemoryIndirect (18 ms)
[----------] 2 tests from DecompressionTest (37 ms total)

[----------] 6 tests from ShaderObjectTest
[ RUN      ] ShaderObjectTest.VertFragShader
[       OK ] ShaderObjectTest.VertFragShader (72 ms)
[ RUN      ] ShaderObjectTest.LinkedShadersDraw
ERROR: -------------------------------------------------------------
ERROR: FAIL during test after 12.52 seconds (12.52 seconds) with execute(/home/lunarg/.jenkins/mel/Vulkan-ExtensionLayer/build/tests/vk_extension_layer_tests --gtest_catch_exceptions=0) failed after 12.51 seconds (12.51 seconds) with returncode=-11 (-0xb=SIGSEGV)
INFO: Test run complete after 2.50 minutes (149.93 seconds)
Build step 'Conditional step (single)' marked build as failure
Archiving artifacts
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
An attempt to send an e-mail to empty list of recipients, ignored.
Finished: FAILURE

Link to test: http://erusea:8080/view/Manual/job/manual-Vulkan-ExtensionLayer/3/console

Can be replicated by running the tests on:

tcubumes
tcubumes4

install target ships incorrect files

The Windows install target currently installs various .lib files. It should not, as these are not shipped by the SDK.

The SDK is also planning on not shipping 32-bit artifacts for the VK_LAYER_KHRONOS_shader_object (though it will continue to ship 32-bit VK_LAYER_KHRONOS_synchronization2 artifacts). So the 32-bit install target should not ship Bin\VkLayer_khronos_shader_object.dll, Bin\VkLayer_khronos_shader_object.json, or ,Bin\VkLayer_khronos_shader_object.pdb.

Feasibility of an extension implementation layer for `VK_KHR_dynamic_rendering` ?

Has there been any discussion of a VK_LAYER_KHRONOS_dynamic_rendering, that would implement VK_KHR_dynamic_rendering on top of the Vulkan 1.0/1.1 core render pass API ?

I have yet to use VK_KHR_dynamic_rendering extensively, but felt like such an implementation layer might come in handy e.g. when developing for Android when one mostly or exclusively uses single-subpass render passes.

Based on your knowledge on the extension, how feasible do you think such an implementation would be ?

One concern is that this hypothetical layer would, for each application-facing VkPipeline, need to create on-demand and track an actual VkPipeline for each actual VkRenderPass, not to mention creating those VkRenderPasss on-demand.

Cannot find source file VkLayer_khronos_timeline_semaphore.def

Hello,

I'm very excited that timeline semaphores have been added to Vulkan 1.2! Since the new SDK is not yet released, I was hoping to try and get this working in our application using 1.1 versions.

I'm currently on Windows 10 using the VulkanSDK 1.1.121.2 and running into an issue while building with cmake. I'm able to finish configuring, but then it seems to be unable to find VkLayer_khronos_timeline_semaphore.def.

Here's the error message I'm getting:

CMake Error at layers/CMakeLists.txt:64 (add_library):
  Cannot find source file:

    VkLayer_khronos_timeline_semaphore.def

  Tried extensions .c .C .c++ .cc .cpp .cxx .cu .m .M .mm .h .hh .h++ .hm
  .hpp .hxx .in .txx
Call Stack (most recent call first):
  layers/CMakeLists.txt:114 (AddVkLayer)


CMake Error at layers/CMakeLists.txt:64 (add_library):
  No SOURCES given to target: VkLayer_khronos_timeline_semaphore
Call Stack (most recent call first):
  layers/CMakeLists.txt:114 (AddVkLayer)


CMake Generate step failed.  Build files cannot be regenerated correctly.

Any help would be greatly appreciated. Thanks a bunch!

noop timeline semaphore when implementation has support

We should check the status of the extension support in the underlying implementation and return the function pointers of the next layer if it's available.

Cleanup CMake / GHA for this repo

Synchronization2 Layer vkCmdPipelineBarrier2KHR fails with Swapchain images

Follow Error occures if a swapchain image from vkGetSwapchainImagesKHR is used in the pipeline barrier:

/build/vulkan-extensionlayer-1.2.189.0~rc1-1lunarg20.04/layers/synchronization2.cpp:885: synchronization2::DependencyInfoV1::DependencyInfoV1(const synchronization2::DeviceData&, uint32_t, const VkDependencyInfoKHR*, const VkAllocationCallbacks*): Assertion `image_data != device_data.image_map.end()' failed.

Vulkan-ExtensionLayer/layers/synchronization2.cpp

Line 885 in 1bd28d2

ASSERT(image_data != device_data.image_map.end());

imaga_data is only filed with the CreateImage HOOK

Vulkan-ExtensionLayer/layers/synchronization2.cpp

Line 916 in 1bd28d2

 VKAPI_ATTR VkResult VKAPI_CALL CreateImage(VkDevice device, const VkImageCreateInfo* pCreateInfo, const VkAllocationCallbacks* pAllocator, 

Images from vkGetSwapcahinImagesKHR are missing, in image_data map

Vulkan-ExtensionLayer/layers/synchronization2.h

Line 216 in 1bd28d2

vk_concurrent_unordered_map<VkImage, ImageData> image_map;

Vulkan-ExtensionLayer/layers/synchronization2.h

Line 176 in 1bd28d2

struct ImageData {

I think that the ImageAspect From Swapchain images is Color.

vk cts failed "dEQP-VK.api.object_management.alloc_callback_fail.instance"

error msg:
Fail (Invalid allocation callback)

Test case 'dEQP-VK.api.object_management.alloc_callback_fail.device'..
double free or corruption (!prev)

How Can I ship my application with Vulkan-ExtensionLayer

My potato gpu don't have khr_synchronization_2 support by the driver. So I have to use Vulkan-ExtensionLayer. Enable by forcing it with VK_INSTANCE_LAYERS environment variable, and use it from application. It's work fine on my machine. But how can I ship it to different pc with no khr_synchronization_2 support by the driver.

VkPhysicalDeviceTimelineSemaphoreFeatures contains false even when this layer is enabled

Hi,

I'm trying to use this layer with a small program which tests timeline semaphores.

I can clearly see in the code that VkPhysicalDeviceTimelineSemaphoreFeatures should contain true, so I'm not sure what's going on here. I'm sure the layer is working because if I ignore this being false and continue execution the program only works when I request this layer.

I've attached the output of api_dump below, putting >>> on the line where the layer is requested, and the line where the feature is declared unsupported.

❯ VK_INSTANCE_LAYERS=VK_LAYER_LUNARG_api_dump timeline-semaphore-example
Up to date
Thread 0, Frame 0:
vkCreateInstance(pCreateInfo, pAllocator, pInstance) returns VkResult VK_SUCCESS (0):
    pCreateInfo:                    const VkInstanceCreateInfo* = 0x7ffd20cc26a0:
        sType:                          VkStructureType = VK_STRUCTURE_TYPE_INSTANCE_CREATE_INFO (1)
        pNext:                          const void* = NULL
        flags:                          VkInstanceCreateFlags = 0
        pApplicationInfo:               const VkApplicationInfo* = 0x420100c180:
            sType:                          VkStructureType = VK_STRUCTURE_TYPE_APPLICATION_INFO (0)
            pNext:                          const void* = NULL
            pApplicationName:               const char* = NULL
            applicationVersion:             uint32_t = 0
            pEngineName:                    const char* = NULL
            engineVersion:                  uint32_t = 0
            apiVersion:                     uint32_t = 4194304
        enabledLayerCount:              uint32_t = 1
        ppEnabledLayerNames:            const char* const* = 0x420100c1c0
>>>         ppEnabledLayerNames[0]:         const char* const = "VK_LAYER_KHRONOS_timeline_semaphore"
        enabledExtensionCount:          uint32_t = 1
        ppEnabledExtensionNames:        const char* const* = 0x420100c220
            ppEnabledExtensionNames[0]:     const char* const = "VK_KHR_get_physical_device_properties2"
    pAllocator:                     const VkAllocationCallbacks* = NULL
    pInstance:                      VkInstance* = 0x17406f0

<snip>

Thread 0, Frame 0:
vkGetPhysicalDeviceFeatures2KHR(physicalDevice, pFeatures) returns void:
    physicalDevice:                 VkPhysicalDevice = 0x17c5c00
    pFeatures:                      VkPhysicalDeviceFeatures2* = 0x175de40:
        sType:                          VkStructureType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FEATURES_2 (1000059000)
        pNext:                          VkPhysicalDeviceTimelineSemaphoreFeatures = 0x175df40:
            sType:                          VkStructureType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TIMELINE_SEMAPHORE_FEATURES (1000207000)
            pNext:                          void* = NULL
>>>         timelineSemaphore:              VkBool32 = 0 
        features:                       VkPhysicalDeviceFeatures = 0x175de50:
            robustBufferAccess:             VkBool32 = 1
            <snip>

<snip>

shader object emulation layer documentation - remove/update Android information

Since most Android devices do not support dynamic rendering, the shader object emulation layer on Android does not make sense. The documentation for this layer should have such a statement at the top of the document.

And remove all the other Android information from the document.

Manual cloning of `shaderc` needed when building for Android on Windows ?

Running update_external_sources_android.bat seemed to fail with shaderc directory not being present in build-android/third_party,
presumably because there's no entry for shaderc in build-android/known_good.json.

I needed to manually clone shaderc into build-android/third_party and run utils/git-sync-deps inside it before ndk-build -j 8 started working.

Is this expected, or am I missing something?

Validation errors when using timeline semaphores

From a simple program drawing a triangle run with the api_dump layer underneath the timeline_semaphore layer (to capture its output) the Khronos validation layer warns that pWaitDstStageMask[0] should not be zero (marked below).

Thread 0, Frame 149:

Validation: Validation Error: [ UNASSIGNED-GeneralParameterError-RequiredParameter ] Object 0: handle = 0x1930768, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x99fb7dfd | vkQueueSubmit: value of pSubmits[0].pWaitDstStageMask[0] must not be 0

vkQueueSubmit(queue, submitCount, pSubmits, fence) returns VkResult
 VK_SUCCESS (0):
    queue:                          VkQueue = 0x19304e0
    submitCount:                    uint32_t = 1
    pSubmits:                       const VkSubmitInfo* = 0x7ffca414d300
        pSubmits[0]:                    const VkSubmitInfo = 0x7ffca414d300:
            sType:                          VkStructureType = VK_STRUCTURE_TYPE_SUBMIT_INFO (4)
            pNext:                          const void* = NULL
            waitSemaphoreCount:             uint32_t = 1
            pWaitSemaphores:                const VkSemaphore* = 0x7ffca414d2f8
                pWaitSemaphores[0]:             const VkSemaphore = 0x120000000012
            pWaitDstStageMask:              const VkPipelineStageFlags* = 0x7ffca414d2f4
>>>             pWaitDstStageMask[0]:           const VkPipelineStageFlags = 0
            commandBufferCount:             uint32_t = 0
            pCommandBuffers:                const VkCommandBuffer* = NULL
            signalSemaphoreCount:           uint32_t = 1
            pSignalSemaphores:              const VkSemaphore* = 0x1aaddc0
                pSignalSemaphores[0]:           const VkSemaphore = 0x1450000000145
    fence:                          VkFence = 0x180000000018

The only vkQueueSubmit in the application uses PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT as this mask and this error does not occur when running without the timeline_semaphore layer on a different driver.

Looks like the culprit is here: https://github.com/KhronosGroup/Vulkan-ExtensionLayer/blob/master/layers/timeline_semaphore.c#L1256-L1264

The VUID is VUID-VkSubmitInfo-pWaitDstStageMask-parameter

The readme could use some expansion

For instance

Which features are implemented
How they are implemented

shader_object_full_draw_state_struct_members.inl: error: use of undeclared identifier 'assert'

[3/13] Building CXX object layers/CMakeFiles/VkLayer_khronos_shader_object.dir/shader_object.cpp.o
FAILED: layers/CMakeFiles/VkLayer_khronos_shader_object.dir/shader_object.cpp.o
/home/builder/.termux-build/_cache/android-r25c-api-24-v2/bin/clang++ --target=aarch64-none-linux-android --gcc-toolchain=/home/builder/.termux-build/_cache/android-r25c-api-24-v2 --sysroot=/home/builder/.termux-build/_cache/android-r25c-api-24-v2/sysroot -DVK_ENABLE_BETA_EXTENSIONS -DVkLayer_khronos_shader_object_EXPORTS -D_POSIX_C_SOURCE=200112 -I/home/builder/.termux-build/vulkan-extension-layer/src/layers -I/home/builder/.termux-build/vulkan-extension-layer/src/utils -I/home/builder/.termux-build/vulkan-extension-layer/src/utils/generated -fstack-protector-strong -Oz --target=aarch64-linux-android24  -I/data/data/com.termux/files/usr/include -Wpointer-arith -Wno-unused-function -Wno-sign-compare -O3 -DNDEBUG -std=c++17 -fPIC -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -fno-strict-aliasing -fno-builtin-memcmp -fvisibility=hidden -MD -MT layers/CMakeFiles/VkLayer_khronos_shader_object.dir/shader_object.cpp.o -MF layers/CMakeFiles/VkLayer_khronos_shader_object.dir/shader_object.cpp.o.d -o layers/CMakeFiles/VkLayer_khronos_shader_object.dir/shader_object.cpp.o -c /home/builder/.termux-build/vulkan-extension-layer/src/layers/shader_object.cpp
In file included from /home/builder/.termux-build/vulkan-extension-layer/src/layers/shader_object.cpp:888:
/home/builder/.termux-build/vulkan-extension-layer/src/layers/generated/shader_object_full_draw_state_struct_members.inl:1084:22: error: use of undeclared identifier 'assert'
default: assert(false); return 0;
^
1 error generated.
[4/13] Building CXX object layers/CMakeFiles/VkLayer_khronos_synchronization2.dir/synchronization2.cpp.o
ninja: build stopped: subcommand failed.
ERROR: failed to build.

I am not sure where went wrong when I build downstream. This is using a custom build system using Android NDK...

Add VK_EXT_private_data support to the timeline semaphores layer

Since it wraps VkSemaphore, it needs to implement vkGet/SetPrivateDataEXT for it.

VulkanEL_generated_source is broken

When I build it on Windows, I am getting this error:
2>The system cannot find the path specified.
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(238,5): error MSB8066: Custom build for 'E:\Github\lunarg\Vulkan-ExtensionLayer\build\CMakeFiles\fb97cb8fa418af05125ae0822f816186\VulkanEL_generated_source.rule;E:\Github\lunarg\Vulkan-ExtensionLayer\CMakeLists.txt' exited with code 1.
2>Done building project "VulkanEL_generated_source.vcxproj" -- FAILED.

ShaderObject: `VK_NULL_HANDLE` used instead of correct pipeline

There's still a problem with thread safety.
If a pipeline was created in another thread during locking of data for writing, that pipeline should be bound, but in current implementation VK_NULL_HANDLE is bound.

Vulkan-ExtensionLayer/layers/shader_object.cpp

Lines 2488 to 2498 in 6282367

 if (pipeline == VK_NULL_HANDLE) { 

 std::unique_lock<std::shared_mutex> lock; 

 auto& pipelines = vertex_or_mesh_shader->pipelines.GetDataForWriting(lock); 

 // Ensure that a pipeline for this state wasn't created in another thread between the read lock above and the write lock 

 if (pipelines.NumEntries() == pipeline_count || pipelines.Find(state_data_key) == pipelines.end()) { 

 pipeline = CreateGraphicsPipelineForCommandBufferState(data); 

 pipelines.Add(state_data_key, pipeline); 

 } 

 } 

 data.device_data->vtable.CmdBindPipeline(commandBuffer, VK_PIPELINE_BIND_POINT_GRAPHICS, pipeline);

Adding support for VK_EXT_dynamic_rendering_unused_attachements in shader objects layer

The shader objects layer can benefit from this extension and support will be added.

Race condition in shader object layer?

In UpdateDrawState CommandBufferData& data is guaranteed to be externally-synchronized and it owns the FullDrawStateData *state_data.

What worries me is that Shader *vertex_or_mesh_shader taken from state_data->GetShader(...) is not and Shader::pipelines does not use mutexes. I haven't found anything that makes accesses to different Shaders synchronized.

So is it a race condition or is access to VkShaderEXT (being bound to a command buffer) externally-synchronized or something else?

Vulkan-ExtensionLayer/layers/shader_object.cpp

Lines 2436 to 2442 in ace98ff

 auto state_data_key = state_data->GetKey(); 

 auto found_pipeline_ptr = vertex_or_mesh_shader->pipelines.GetOrNullptr(state_data_key); 

 VkPipeline pipeline = found_pipeline_ptr ? *found_pipeline_ptr : VK_NULL_HANDLE; 

 if (pipeline == VK_NULL_HANDLE) { 

 pipeline = CreateGraphicsPipelineForCommandBufferState(data); 

 vertex_or_mesh_shader->pipelines.Add(state_data_key, pipeline); 

 }

Cannot compile with space in directory name

With a clone in, for example ~/source/Vulkan ExtensionLayer I get


[1/2] Re-running CMake...
CMake Warning at CMakeLists.txt:44 (message):
  CMAKE_BUILD_TYPE not set.  Using Debug for dependency build type


********************************************************************************
* NOTE: Adding target vvl_update_deps to run as needed for updating            *
*       dependencies.                                                          *
********************************************************************************
-- Using glslang install located at /home/liam/source/Vulkan ExtensionLayer/external/glslang/build/install
-- Configuring done
-- Generating done
-- Build files have been written to: /home/liam/source/Vulkan ExtensionLayer/build
[10/22] Linking CXX shared library layers/libVkLayer_khronos_synchronization2.so
FAILED: layers/libVkLayer_khronos_synchronization2.so 
: && /usr/lib64/ccache/c++ -fPIC -Wpointer-arith -Wno-unused-function -Wno-sign-compare  -Wl,--version-script=/home/liam/source/Vulkan ExtensionLayer/layers/libVkLayer_khronos_synchronization2.map,-Bsymbolic,--exclude-libs,ALL -shared -Wl,-soname,libVkLayer_khronos_synchronization2.so -o layers/libVkLayer_khronos_synchronization2.so layers/CMakeFiles/VkLayer_khronos_synchronization2.dir/synchronization2.cpp.o  utils/libVkExtLayer_utils.a && :
/usr/bin/ld: cannot open linker script file /home/liam/source/Vulkan: No such file or directory
collect2: error: ld returned 1 exit status
[11/22] Linking CXX shared library layers/libVkLayer_khronos_timeline_semaphore.so
FAILED: layers/libVkLayer_khronos_timeline_semaphore.so 
: && /usr/lib64/ccache/c++ -fPIC -Wpointer-arith -Wno-unused-function -Wno-sign-compare  -Wl,--version-script=/home/liam/source/Vulkan ExtensionLayer/layers/libVkLayer_khronos_timeline_semaphore.map,-Bsymbolic,--exclude-libs,ALL -shared -Wl,-soname,libVkLayer_khronos_timeline_semaphore.so -o layers/libVkLayer_khronos_timeline_semaphore.so layers/CMakeFiles/VkLayer_khronos_timeline_semaphore.dir/hash_table.cpp.o layers/CMakeFiles/VkLayer_khronos_timeline_semaphore.dir/timeline_semaphore.c.o  utils/libVkExtLayer_utils.a && :
/usr/bin/ld: cannot open linker script file /home/liam/source/Vulkan: No such file or directory
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

decompression: DecompressionTest.DecompressMemory crashes on Android

With #212, which adds this layer to the android build, the unit tests are crashing:

5-08 11:26:56.480 15813 15850 I VulkanExtensionLayerTests: [ RUN      ] DecompressionTest.DecompressMemory
05-08 11:26:56.732 16087 16087 F DEBUG   : Cmdline: com.example.VulkanExtensionLayerTests
05-08 11:26:56.732 16087 16087 F DEBUG   : pid: 15813, tid: 15850, name: Thread-2  >>> com.e5-08 11:26:56.480 15813 15850 I VulkanExtensionLayerTests: [ RUN      ] DecompressionTest.DecompressMemory
05-08 11:26:56.732 16087 16087 F DEBUG   : Cmdline: com.example.VulkanExtensionLayerTests
05-08 11:26:56.732 16087 16087 F DEBUG   : pid: 15813, tid: 15850, name: Thread-2  >>> com.example.VulkanExtensionLayerTests <<<
05-08 11:26:56.732 16087 16087 F DEBUG   :       #01 pc 0000000000169c48  /data/app/~~iSBtMnAJGycGA519USOzeQ==/com.example.VulkanExtensionLayerTests-xJiASMywsAdNfqkfP58EBg==/lib/arm64/libVkLayer_khronos_memory_decompression.so (BuildId: 549b3fc0819d10c6728c41bff1e8db0c0d5328b0)
05-08 11:26:56.732 16087 16087 F DEBUG   :       #02 pc 000000000016a624  /data/app/~~iSBtMnAJGycGA519USOzeQ==/com.example.VulkanExtensionLayerTests-xJiASMywsAdNfqkfP58EBg==/lib/arm64/libVkLayer_khronos_memory_decompression.so (BuildId: 549b3fc0819d10c6728c41bff1e8db0c0d5328b0)
05-08 11:26:56.732 16087 16087 F DEBUG   :       #05 pc 00000000002774a0  /data/app/~~iSBtMnAJGycGA519USOzeQ==/com.example.VulkanExtensionLayerTests-xJiASMywsAdNfqkfP58EBg==/lib/arm64/libVulkanExtensionLayerTests.so (BuildId: 928cddb675104a740e7c22970a536c453077d203)
05-08 11:26:56.732 16087 16087 F DEBUG   :       #06 pc 0000000000290610  /data/app/~~iSBtMnAJGycGA519USOzeQ==/com.example.VulkanExtensionLayerTests-xJiASMywsAdNfqkfP58EBg==/lib/arm64/libVulkanExtensionLayerTests.so (BuildId: 928cddb675104a740e7c22970a536c453077d203)
05-08 11:26:56.732 16087 16087 F DEBUG   :       #07 pc 000000000028e9b0  /data/app/~~iSBtMnAJGycGA519USOzeQ==/com.example.VulkanExtensionLayerTests-xJiASMywsAdNfqkfP58EBg==/lib/arm64/libVulkanExtensionLayerTests.so (BuildId: 928cddb675104a740e7c22970a536c453077d203)
05-08 11:26:56.732 16087 16087 F DEBUG   :       #08 pc 0000000000271bb4  /data/app/~~iSBtMnAJGycGA519USOzeQ==/com.example.VulkanExtensionLayerTests-xJiASMywsAdNfqkfP58EBg==/lib/arm64/libVulkanExtensionLayerTests.so (BuildId: 928cddb675104a740e7c22970a536c453077d203)
05-08 11:26:56.732 16087 16087 F DEBUG   :       #09 pc 000000000028822c  /data/app/~~iSBtMnAJGycGA519USOzeQ==/com.example.VulkanExtensionLayerTests-xJiASMywsAdNfqkfP58EBg==/lib/arm64/libVulkanExtensionLayerTests.so (BuildId: 928cddb675104a740e7c22970a536c453077d203)
05-08 11:26:56.732 16087 16087 F DEBUG   :       #10 pc 00000000002b26a4  /data/app/~~iSBtMnAJGycGA519USOzeQ==/com.example.VulkanExtensionLayerTests-xJiASMywsAdNfqkfP58EBg==/lib/arm64/libVulkanExtensionLayerTests.so (testing::Test::Run()+104) (BuildId: 928cddb675104a740e7c22970a536c453077d203)
05-08 11:26:56.732 16087 16087 F DEBUG   :       #11 pc 00000000002b3c78  /data/app/~~iSBtMnAJGycGA519USOzeQ==/com.example.VulkanExtensionLayerTests-xJiASMywsAdNfqkfP58EBg==/lib/arm64/libVulkanExtensionLayerTests.so (testing::TestInfo::Run()+724) (BuildId: 928cddb675104a740e7c22970a536c453077d203)
05-08 11:26:56.732 16087 16087 F DEBUG   :       #12 pc 00000000002b4598  /data/app/~~iSBtMnAJGycGA519USOzeQ==/com.example.VulkanExtensionLayerTests-xJiASMywsAdNfqkfP58EBg==/lib/arm64/libVulkanExtensionLayerTests.so (testing::TestSuite::Run()+352) (BuildId: 928cddb675104a740e7c22970a536c453077d203)
05-08 11:26:56.732 16087 16087 F DEBUG   :       #13 pc 00000000002c4920  /data/app/~~iSBtMnAJGycGA519USOzeQ==/com.example.VulkanExtensionLayerTests-xJiASMywsAdNfqkfP58EBg==/lib/arm64/libVulkanExtensionLayerTests.so (testing::internal::UnitTestImpl::RunAllTests()+1504) (BuildId: 928cddb675104a740e7c22970a536c453077d203)
05-08 11:26:56.732 16087 16087 F DEBUG   :       #14 pc 00000000002c42f0  /data/app/~~iSBtMnAJGycGA519USOzeQ==/com.example.VulkanExtensionLayerTests-xJiASMywsAdNfqkfP58EBg==/lib/arm64/libVulkanExtensionLayerTests.so (testing::UnitTest::Run()+312) (BuildId: 928cddb675104a740e7c22970a536c453077d203)
05-08 11:26:56.732 16087 16087 F DEBUG   :       #15 pc 0000000000273604  /data/app/~~iSBtMnAJGycGA519USOzeQ==/com.example.VulkanExtensionLayerTests-xJiASMywsAdNfqkfP58EBg==/lib/arm64/libVulkanExtensionLayerTests.so (BuildId: 928cddb675104a740e7c22970a536c453077d203)
05-08 11:26:56.732 16087 16087 F DEBUG   :       #16 pc 000000000029c330  /data/app/~~iSBtMnAJGycGA519USOzeQ==/com.example.VulkanExtensionLayerTests-xJiASMywsAdNfqkfP58EBg==/lib/arm64/libVulkanExtensionLayerTests.so (BuildId: 928cddb675104a740e7c22970a536c453077d203)xample.VulkanExtensionLayerTests <<<
05-08 11:26:56.732 16087 16087 F DEBUG   :       #01 pc 0000000000169c48  /data/app/~~iSBtMnAJGycGA519USOzeQ==/com.example.VulkanExtensionLayerTests-xJiASMywsAdNfqkfP58EBg==/lib/arm64/libVkLayer_khronos_memory_decompression.so (BuildId: 549b3fc0819d10c6728c41bff1e8db0c0d5328b0)
05-08 11:26:56.732 16087 16087 F DEBUG   :       #02 pc 000000000016a624  /data/app/~~iSBtMnAJGycGA519USOzeQ==/com.example.VulkanExtensionLayerTests-xJiASMywsAdNfqkfP58EBg==/lib/arm64/libVkLayer_khronos_memory_decompression.so (BuildId: 549b3fc0819d10c6728c41bff1e8db0c0d5328b0)
05-08 11:26:56.732 16087 16087 F DEBUG   :       #05 pc 00000000002774a0  /data/app/~~iSBtMnAJGycGA519USOzeQ==/com.example.VulkanExtensionLayerTests-xJiASMywsAdNfqkfP58EBg==/lib/arm64/libVulkanExtensionLayerTests.so (BuildId: 928cddb675104a740e7c22970a536c453077d203)
05-08 11:26:56.732 16087 16087 F DEBUG   :       #06 pc 0000000000290610  /data/app/~~iSBtMnAJGycGA519USOzeQ==/com.example.VulkanExtensionLayerTests-xJiASMywsAdNfqkfP58EBg==/lib/arm64/libVulkanExtensionLayerTests.so (BuildId: 928cddb675104a740e7c22970a536c453077d203)
05-08 11:26:56.732 16087 16087 F DEBUG   :       #07 pc 000000000028e9b0  /data/app/~~iSBtMnAJGycGA519USOzeQ==/com.example.VulkanExtensionLayerTests-xJiASMywsAdNfqkfP58EBg==/lib/arm64/libVulkanExtensionLayerTests.so (BuildId: 928cddb675104a740e7c22970a536c453077d203)
05-08 11:26:56.732 16087 16087 F DEBUG   :       #08 pc 0000000000271bb4  /data/app/~~iSBtMnAJGycGA519USOzeQ==/com.example.VulkanExtensionLayerTests-xJiASMywsAdNfqkfP58EBg==/lib/arm64/libVulkanExtensionLayerTests.so (BuildId: 928cddb675104a740e7c22970a536c453077d203)
05-08 11:26:56.732 16087 16087 F DEBUG   :       #09 pc 000000000028822c  /data/app/~~iSBtMnAJGycGA519USOzeQ==/com.example.VulkanExtensionLayerTests-xJiASMywsAdNfqkfP58EBg==/lib/arm64/libVulkanExtensionLayerTests.so (BuildId: 928cddb675104a740e7c22970a536c453077d203)
05-08 11:26:56.732 16087 16087 F DEBUG   :       #10 pc 00000000002b26a4  /data/app/~~iSBtMnAJGycGA519USOzeQ==/com.example.VulkanExtensionLayerTests-xJiASMywsAdNfqkfP58EBg==/lib/arm64/libVulkanExtensionLayerTests.so (testing::Test::Run()+104) (BuildId: 928cddb675104a740e7c22970a536c453077d203)
05-08 11:26:56.732 16087 16087 F DEBUG   :       #11 pc 00000000002b3c78  /data/app/~~iSBtMnAJGycGA519USOzeQ==/com.example.VulkanExtensionLayerTests-xJiASMywsAdNfqkfP58EBg==/lib/arm64/libVulkanExtensionLayerTests.so (testing::TestInfo::Run()+724) (BuildId: 928cddb675104a740e7c22970a536c453077d203)
05-08 11:26:56.732 16087 16087 F DEBUG   :       #12 pc 00000000002b4598  /data/app/~~iSBtMnAJGycGA519USOzeQ==/com.example.VulkanExtensionLayerTests-xJiASMywsAdNfqkfP58EBg==/lib/arm64/libVulkanExtensionLayerTests.so (testing::TestSuite::Run()+352) (BuildId: 928cddb675104a740e7c22970a536c453077d203)
05-08 11:26:56.732 16087 16087 F DEBUG   :       #13 pc 00000000002c4920  /data/app/~~iSBtMnAJGycGA519USOzeQ==/com.example.VulkanExtensionLayerTests-xJiASMywsAdNfqkfP58EBg==/lib/arm64/libVulkanExtensionLayerTests.so (testing::internal::UnitTestImpl::RunAllTests()+1504) (BuildId: 928cddb675104a740e7c22970a536c453077d203)
05-08 11:26:56.732 16087 16087 F DEBUG   :       #14 pc 00000000002c42f0  /data/app/~~iSBtMnAJGycGA519USOzeQ==/com.example.VulkanExtensionLayerTests-xJiASMywsAdNfqkfP58EBg==/lib/arm64/libVulkanExtensionLayerTests.so (testing::UnitTest::Run()+312) (BuildId: 928cddb675104a740e7c22970a536c453077d203)
05-08 11:26:56.732 16087 16087 F DEBUG   :       #15 pc 0000000000273604  /data/app/~~iSBtMnAJGycGA519USOzeQ==/com.example.VulkanExtensionLayerTests-xJiASMywsAdNfqkfP58EBg==/lib/arm64/libVulkanExtensionLayerTests.so (BuildId: 928cddb675104a740e7c22970a536c453077d203)
05-08 11:26:56.732 16087 16087 F DEBUG   :       #16 pc 000000000029c330  /data/app/~~iSBtMnAJGycGA519USOzeQ==/com.example.VulkanExtensionLayerTests-xJiASMywsAdNfqkfP58EBg==/lib/arm64/libVulkanExtensionLayerTests.so (BuildId: 928cddb675104a740e7c22970a536c453077d203)

CMake files have googletest support, but no tests are defined

If no tests are planned, then we can simplify the CMake files.

Using VK_LAYER_KHRONOS_timeline_semaphore on android with renderdoc

I wanted to use VK_LAYER_KHRONOS_timeline_semaphore to port my existing renderer which uses timeline semaphores heavilly to android. However I've faced on issue where renderdoc is unable to open any capture since the layer isn't globally visible. Does any method exist to make these extension layers visible to renderdoc and other applications in general?

Bad behaviour of captured `vkEnumerateDeviceExtensionProperties`

In every extension layer in this repository captured vkEnumerateDeviceExtensionProperties advertise their extensions if pLayerName == NULL, but the spec states:

When pLayerName parameter is NULL, only extensions provided by the Vulkan implementation or by implicitly enabled layers are returned. When pLayerName is the name of a layer, the device extensions provided by that layer are returned.

Missing uninstall target: "make: *** No rule to make target 'uninstall'. Stop."

Followed the guide:
https://github.com/KhronosGroup/Vulkan-ExtensionLayer/blob/main/BUILD.md#installed-files
I used a Release build instead of Debug build.

sudo make uninstall
make: *** No rule to make target 'uninstall'.  Stop.

Install works fine.

Fix WIN32 `.lib` installs

The Windows install target currently installs various .lib files. It should not, as these are not shipped by the SDK.

shaderObject: possible alignment issues

Because of the manual memory sub-allocation inside of objects (eg. FullDrawStateData, Shader and CommandBufferData), memory may be misaligned either due VU or to ISO C alignment requirement.

Example of this would be if Shader was created with strlen( pName ) + 1 not being a multiple of 4, then spirv_data is not aligned to 4 which breaks VUID-VkShaderModuleCreateInfo-codeSize-08735.

Places use dynamic allocation with extended fields:

Shader: all dynamically added members must be aligned apart from name (either to VU or ISO C alignment) and all of them are susceptible
FullDrawStateData: all dynamically added fields are arrays that have alignment of 4 (at least for now) and the class is already aligned to 8 (or 4 on 32-bit systems ?) so will not break the alignment unless an new dynamic state extension with greater alignment requirement was added.
CommandBufferData: class already aligned to 8 (4 on 32-bit ?) and only allocating additionally a FullDrawStateData so again it will not break unless something was added to FullDrawStateData that increases alignment requirements.

Also in some places pfnAllocation is called with alignment=0, but I would expect a real alignment here.

Timeline semaphore layer forces VK_KHR_timeline_semaphore extension

In order to allow this layer to pass CTS together with an implementation not supporting the timeline semaphore extension, I had to override the implementation's returned list of supported extension : https://github.com/KhronosGroup/Vulkan-ExtensionLayer/blob/master/layers/timeline_semaphore.c#L1948

This is probably wrong but it works and there are currently no other way of achieving that goal.

v1.3.248 fails to build with libc++

Regressed by 6dd7a3d. Found on FreeBSD but OpenBSD, Android, macOS, ChimeraLinux also use libc++ by default (OpenMandriva seems to use Clang with libstdc++). BSD (unlike GNU) enable extensions by default unless _POSIX_C_SOURCE or _XOPEN_SOURCE is defined. Unfortunately, libc++ uses some of the extensions without resetting POSIX conformance.

$ export CC=clang CXX=clang++ CXXFLAGS=-stdlib=libc++
$ cmake -DBUILD_TESTS=OFF -G Ninja -B _build
$ cmake --build _build
[...]
FAILED: layers/CMakeFiles/VkLayer_khronos_synchronization2.dir/synchronization2.cpp.o
/usr/bin/c++ -DVK_ENABLE_BETA_EXTENSIONS -DVkLayer_khronos_synchronization2_EXPORTS -D_POSIX_C_SOURCE=200112 -Ilayers -Iutils -Iutils/generated -isystem /usr/local/include -Wpointer-arith -Wno-unused-function -Wno-sign-compare -fPIC -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -fno-strict-aliasing -fno-builtin-memcmp -fvisibility=hidden -std=c++17 -MD -MT layers/CMakeFiles/VkLayer_khronos_synchronization2.dir/synchronization2.cpp.o -MF layers/CMakeFiles/VkLayer_khronos_synchronization2.dir/synchronization2.cpp.o.d -o layers/CMakeFiles/VkLayer_khronos_synchronization2.dir/synchronization2.cpp.o -c layers/synchronization2.cpp
In file included from layers/synchronization2.cpp:28:
In file included from layers/synchronization2.h:29:
In file included from utils/vk_concurrent_unordered_map.h:29:
In file included from /usr/include/c++/v1/iomanip:47:
In file included from /usr/include/c++/v1/istream:165:
In file included from /usr/include/c++/v1/ostream:171:
In file included from /usr/include/c++/v1/ios:221:
/usr/include/c++/v1/__locale:680:16: error: use of undeclared identifier 'isascii'
        return isascii(__c) ? (__tab_[static_cast<int>(__c)] & __m) !=0 : false;
               ^
/usr/include/c++/v1/__locale:687:22: error: use of undeclared identifier 'isascii'
            *__vec = isascii(*__low) ? __tab_[static_cast<int>(*__low)] : 0;
                     ^
/usr/include/c++/v1/__locale:695:17: error: use of undeclared identifier 'isascii'
            if (isascii(*__low) && (__tab_[static_cast<int>(*__low)] & __m))
                ^
/usr/include/c++/v1/__locale:704:18: error: use of undeclared identifier 'isascii'
            if (!isascii(*__low) || !(__tab_[static_cast<int>(*__low)] & __m))
                 ^
4 errors generated.

Possible fixes:

Convert -D_POSIX_C_SOURCE=200112 to -D_XOPEN_SOURCE=600
Convert -D_POSIX_C_SOURCE=200112 to -D_GNU_SOURCE
Make -D_POSIX_C_SOURCE=200112 local to the specific file(s)
Drop <iomanip> and maybe more via include-what-you-use

Please rename default branch from 'master' to 'main' per Khronos policy (update 2023-01-16)

To repository owners: please rename the default branch of this repository from 'master' to 'main', using the Github renaming tool. This request is per policy set by the Khronos Promoters in May 2021, to follow Github community practice for respectful naming.

The Github renaming tool sets up URL redirections and retargets outstanding pull requests, so the impact on repository users is minimal. The most visible issue is that people with local repo clones will probably want to rename their clone's 'master' branch, following the popup instructions that will be seen when browsing the github repository after the change; or just delete 'master' and pull the new 'main', if it's purely a tracker with no local content.

You may wish to coordinate with @outofcontrol if you are doing auto-updates from this repository to another location, whether via push/pull mirroring or other mechanisms. The redirects setup by Github should accommodate most such uses transparently, but it's still good practice.

Based on experience with other KhronosGroup repositories which have undergone this renaming already, this is a reasonable approach:

Agree on a date for the renaming within the Working Group or other owners of the repository, and document that date here.
- Date can be adjusted to avoid interaction with major releases in flight.
Provide notice to repository users outside Khronos, insofar as possible (adding a comment in the repo README with the switchover date is one way).
Once the renaming is done, edit the new 'main' branch to replace hardwired references to 'master' with (preferably) 'default branch' or 'main'.
Update the repo README to note the change.

If you have questions or issues about this, please raise them on Khronos internal gitlab 'khronos-general' issue 106 if possible. If not possible, you can @-tag me here.

While we will not force any WG into acting precipitously, this is our agreed policy. Please try to accommodate renaming relatively soon.

Note that this issue is automatically generated, due to the large number of KhronosGroup repositories it's being raised in.

Set up a CI build (eg. travis)

Happy to set it up code-wise, but someone in the KhronosGroup group will need to enable it.

Shader object layer needs documentation

For the SDK we'll need a file similar to docs/synchronization2_layer.md for this layer.

code generation is not documented in BUILD.md

All the other Vulkan repositories that do code generation include information about how to invoke the code generator in their respective BUILD.md files. Vulkan-ExtensionLayer does not. It should.

Potential use of pipeline with different shaders than requested

Because Shaders are allocated on the heap two different Shaders might have the same address if one was deallocated before the other one was allocated, even if they might not have identical contents.

Because stale Shaders might be stored inside FullDrawStateDatas inside vertex/mesh shader's Shader::pipelines, equality test of FullDrawStateData might return true when their Shaders are not equal as argumented above.

If such thing happens a pipeline with wrong shaders attached might be used.

Vulkan-ExtensionLayer/layers/generated/shader_object_full_draw_state_struct_members.inl

Lines 750 to 754 in 745660f

 for (uint32_t i = 0; i < NUM_SHADERS; ++i) { 

 if (!(o.shaders_[i] == shaders_[i])) { 

 return false; 

 } 

 }

Vulkan-ExtensionLayer/layers/generated/shader_object_full_draw_state_struct_members.inl

Line 1174 in 745660f

Shader* shaders_[NUM_SHADERS];

Don

How to compile for Android on Windows?

How do I compile these layers for Android if I'm running on Windows?

The build instructions say to run a script build-android/build-all.sh, which is not a Windows script

I also tried running build-android/update_external_sources_android.bat, since it was a Windows batch file, but I got the error 'py' is not recognized as an internal or external command, operable program or batch file. I'm not even sure what py is - some alias for python?

Is it possible to compile for Android from a Windows?

Do not use applicaiton's alloc in layer

There are several CTS test cases to fail the alloc intensionally. Using application's alloc in layer will cause some problems besides checking allocation result in layers, take timeline_CreateDevice as example,
fpCreateDevice returns success, that means the icd device is added to logic device list of loader, following is the callstack,

#0  loader_add_logical_device (inst=0x53e0b30, icd_term=0x5371f70, dev=0x5bfc9b0) at /jacob/Vulkan-Loader-latest/loader/loader.c:2112
#1  0x00007ffff4f429d1 in terminator_CreateDevice (physicalDevice=0x51095d0, pCreateInfo=0x7fffffffc780, pAllocator=0x7fffffffccc8,
    pDevice=0x7fffffffc6c8) at /jacob/Vulkan-Loader-latest/loader/loader.c:6639
#2  0x00007fffed3a3d67 in timeline_CreateDevice (physicalDevice=0x51095d0, pCreateInfo=0x7fffffffc780, pAllocator=0x7fffffffccc8,
    pDevice=0x7fffffffc6c8) at /source/opensource/Vulkan-ExtensionLayer-Jacob/layers/timeline_semaphore.c:2139

However, if device_new is failed, fpDestroyDevice can't remove the icd device from loader's logic device list because loader's destroy device function can't be gotten by fpGetInstanceProcAddr(NULL, "vkDestroyDevice")，that is to say, there is no way to get the loader's destroy device function pointer. As a result, invalid icd device is stored in loader and double free issue happens later.

This issue can easily be reproduced with dEQP-VK.api.object_management.alloc_callback_fail.device

Version going backwards: v1.3.229 > v1.2.230

I've tried to update FreeBSD package only to notice minor version went back to Vulkan 1.2 days. Is this a typo?

https://github.com/KhronosGroup/Vulkan-ExtensionLayer/tags

update tests to support macOS

We build and ship the synchronization2 layer with the macOS SDK, so we'd like to have macOS build and tests running for it.

Currently all tests are failing, possibly because the tests are not portability-savvy: http://erusea:8080/view/Manual/job/manual-Vulkan-ExtensionLayer/112/console

...
[ RUN      ] Sync2CompatTest.Vulkan10
/Users/lunarg/.jenkins/mel/Vulkan-ExtensionLayer/tests/synchronization2_tests.cpp:1181: Failure
Expected equality of these values:
  VK_SUCCESS
    Which is: 0
  resolved_err
    Which is: -9
VK_ERROR_INCOMPATIBLE_DRIVER
[  FAILED  ] Sync2CompatTest.Vulkan10 (0 ms) 
[----------] 1 test from Sync2CompatTest (0 ms total)
...
[==========] 14 tests from 2 test suites ran. (46 ms total)
[  PASSED  ] 0 tests.
[  FAILED  ] 14 tests, listed below:
[  FAILED  ] Sync2Test.OwnershipTranfersImage
[  FAILED  ] Sync2Test.OwnershipTranfersBuffer
[  FAILED  ] Sync2Test.SecondaryCommandBufferBarrier
[  FAILED  ] Sync2Test.SecondaryCommandBufferImageLayoutTransitions
[  FAILED  ] Sync2Test.QueueSubmitSemaphoresAndLayoutTracking
[  FAILED  ] Sync2Test.CommandBufferSimultaneousUseSync
[  FAILED  ] Sync2Test.BarrierLayoutToImageUsage
[  FAILED  ] Sync2Test.WaitEventThenSet
[  FAILED  ] Sync2Test.TwoQueueSubmitsSeparateQueuesWithSemaphoreAndOneFenceTwoWFF
[  FAILED  ] Sync2Test.TwoSubmitInfosWithSemaphoreOneQueueSubmitsOneFence
[  FAILED  ] Sync2Test.ClearDepthStencilWithValidRange
[  FAILED  ] Sync2Test.QueueSubmitTimelineSemaphore
[  FAILED  ] Sync2Test.SwapchainImage
[  FAILED  ] Sync2CompatTest.Vulkan10

To reproduce, start a manual-Vulkan-ExtensionLayer job with:

NODE: tcdwnapl0

Shader object layer settings should support vk_layer_settings.txt

This layer supports a setting called VK_SHADER_OBJECT_IGNORE_DRIVER_SUPPORT, but it only works as an environment variable.

It should be made to also use vk_layer_settings.txt and the android mechanism. They sync2 layer has a similar setting called VK_SYNC2_FORCE_ENABLE / khronos_synchronization2.force_enable.

Naming should also be made consistent with the sync2 layer.

Unknown types for "VKxxx" structures and constants while building

Describe the Issue

While building Vulkan-ExtensionLayer-sdk version 1.2.189.0, I come up with a set of errors regarding unknown types mostly on VK*** structures and constants.

Environment:

OS: GNU/Linux Slackware
GPU: [AMD/ATI] Baffin [Radeon RX 550 640SP / RX 560/560X]
SDK or header version if building from repo: 1.2.189.0
Options enabled (synchronization, best practices, etc.):

Additional context

Below the command-line I user to compiler the package:

$ cmake                                                       \
  -DCMAKE_INSTALL_PREFIX=/usr            \
  -DCMAKE_INSTALL_SYSCONFDIR=/etc  \
  -DCMAKE_INSTALL_DATADIR=/share      \
  -DCMAKE_SKIP_RPATH=True                  \
  -DBUILD_TESTS=Off                                 \
  -DBUILD_WSI_XLIB_SUPPORT=On         \
  -DBUILD_WSI_XCB_SUPPORT=On          \
  -DBUILD_WSI_WAYLAND_SUPPORT=On \
  -DCMAKE_BUILD_TYPE=Release              \
  -DBUILD_LAYER_SUPPORT_FILES=On    \
  ..

The errors I got look like the following:

[  9%] Building CXX object utils/CMakeFiles/VkExtLayer_utils.dir/generated/vk_safe_struct.cpp.o
In file included from /tmp/Vulkan-ExtensionLayer-sdk-1.2.189.0/utils/generated/vk_safe_struct.cpp:33:
/tmp/Vulkan-ExtensionLayer-sdk-1.2.189.0/utils/generated/vk_safe_struct.h:3503:5: error: ‘VkVideoCapabilityFlagsKHR’ does not name a type; did you mean ‘VkVideoCapabilitiesFlagsKHR’?
 3503 |     VkVideoCapabilityFlagsKHR capabilityFlags;
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~
      |     VkVideoCapabilitiesFlagsKHR
In file included from /tmp/Vulkan-ExtensionLayer-sdk-1.2.189.0/utils/generated/vk_safe_struct.cpp:33:
/tmp/Vulkan-ExtensionLayer-sdk-1.2.189.0/utils/generated/vk_safe_struct.h:3503:5: error: ‘VkVideoCapabilityFlagsKHR’ does not name a type; did you mean ‘VkVideoCapabilitiesFlagsKHR’?
 3503 |     VkVideoCapabilityFlagsKHR capabilityFlags;
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~
      |     VkVideoCapabilitiesFlagsKHR
/tmp/Vulkan-ExtensionLayer-sdk-1.2.189.0/utils/generated/vk_safe_struct.h:4612:55: error: ‘VkPhysicalDevicePresentWaitFeaturesKHR’ does not name a type; did you mean ‘safe_VkPhysicalDevicePresentWaitFeaturesKHR’?
 4612 |     safe_VkPhysicalDevicePresentWaitFeaturesKHR(const VkPhysicalDevicePresentWaitFeaturesKHR* in_struct);
      |                                                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                                       safe_VkPhysicalDevicePresentWaitFeaturesKHR
/tmp/Vulkan-ExtensionLayer-sdk-1.2.189.0/utils/generated/vk_safe_struct.h:4612:55: error: ‘VkPhysicalDevicePresentWaitFeaturesKHR’ does not name a type; did you mean ‘safe_VkPhysicalDevicePresentWaitFeaturesKHR’?
 4612 |     safe_VkPhysicalDevicePresentWaitFeaturesKHR(const VkPhysicalDevicePresentWaitFeaturesKHR* in_struct);
      |                                                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                                       safe_VkPhysicalDevicePresentWaitFeaturesKHR
/tmp/Vulkan-ExtensionLayer-sdk-1.2.189.0/utils/generated/vk_safe_struct.h:4617:27: error: ‘VkPhysicalDevicePresentWaitFeaturesKHR’ does not name a type; did you mean ‘safe_VkPhysicalDevicePresentWaitFeaturesKHR’?
 4617 |     void initialize(const VkPhysicalDevicePresentWaitFeaturesKHR* in_struct);
      |                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                           safe_VkPhysicalDevicePresentWaitFeaturesKHR
/tmp/Vulkan-ExtensionLayer-sdk-1.2.189.0/utils/generated/vk_safe_struct.h:4617:27: error: ‘VkPhysicalDevicePresentWaitFeaturesKHR’ does not name a type; did you mean ‘safe_VkPhysicalDevicePresentWaitFeaturesKHR’?
 4617 |     void initialize(const VkPhysicalDevicePresentWaitFeaturesKHR* in_struct);
      |                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                           safe_VkPhysicalDevicePresentWaitFeaturesKHR

A full output can be found in the following attached file:
vulkan.log

libs/arm64-v8a
libs/armeabi-v7a

How do I get the x86_64 version of the .so built for Android?

Thanks!

	if (pipeline == VK_NULL_HANDLE) {
	std::unique_lock<std::shared_mutex> lock;
	auto& pipelines = vertex_or_mesh_shader->pipelines.GetDataForWriting(lock);
	// Ensure that a pipeline for this state wasn't created in another thread between the read lock above and the write lock
	if (pipelines.NumEntries() == pipeline_count \|\| pipelines.Find(state_data_key) == pipelines.end()) {
	pipeline = CreateGraphicsPipelineForCommandBufferState(data);
	pipelines.Add(state_data_key, pipeline);
	}
	}

	data.device_data->vtable.CmdBindPipeline(commandBuffer, VK_PIPELINE_BIND_POINT_GRAPHICS, pipeline);

	auto state_data_key = state_data->GetKey();
	auto found_pipeline_ptr = vertex_or_mesh_shader->pipelines.GetOrNullptr(state_data_key);
	VkPipeline pipeline = found_pipeline_ptr ? *found_pipeline_ptr : VK_NULL_HANDLE;
	if (pipeline == VK_NULL_HANDLE) {
	pipeline = CreateGraphicsPipelineForCommandBufferState(data);
	vertex_or_mesh_shader->pipelines.Add(state_data_key, pipeline);
	}

	for (uint32_t i = 0; i < NUM_SHADERS; ++i) {
	if (!(o.shaders_[i] == shaders_[i])) {
	return false;
	}
	}