khronosgroup/vulkan-loaderandvalidationlayers

**Deprecated repository** for Vulkan loader and validation layers

Vulkan-LoaderAndValidationLayers Has Been Deprecated

This repository has been deprecated. It will continue to exist as a read-only repository servicing existing projects. Any projects utilizing this repository should be migrated to use the follow-on repositories listed below. All issues have been migrated to the new repositories.

The four new repositories are:

• Vulkan-Headers
• Vulkan-Loader
• Vulkan-ValidationLayers
• Vulkan-Tools

Repository Maintainers, May 13, 2018

Contact: [email protected]

Original README.md contents follow.

Vulkan Ecosystem Components

This project provides the Khronos official Vulkan ICD desktop loader and the Vulkan validation layers for Windows, Linux, Android, and MacOS.

CI Build Status

Platform	Build Status
Linux/Android
Windows

Introduction

Vulkan is an Explicit API, enabling direct control over how GPUs actually work. By design, minimal error checking is done inside a Vulkan driver. Applications have full control and responsibility for correct operation. Any errors in how Vulkan is used can result in a crash. This project provides Vulkan validation layers that can be enabled to assist development by enabling developers to verify their applications correct use of the Vulkan API.

Vulkan supports multiple GPUs and multiple global contexts (VkInstance). The ICD loader is necessary to support multiple GPUs and VkInstance-level Vulkan commands. Additionally, the loader manages inserting Vulkan layer libraries such as validation layers between the application and the ICD.

The following components are available in this repository:

• Vulkan header files
• ICD Loader
• Validation Layers
• Mock ICD
• Demos
• Tests

Contact Information

• Tobin Ehlis
• Mark Lobodzinski

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 as well as running validation tests and demo applications.

Information on how to enable the various Validation layers is in layers/README.md.

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

License

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

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

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; Google providing significant contributions to the validation layers; Khronos providing oversight and hosting of the project.

vulkan-loaderandvalidationlayers's Issues

validation layer not checking pWaitDstStageMask in VkSubmitInfo

According to the spec, if waitSemaphoreCount is not 0, then pWaitDstStageMask must be a valid pointer to an array, but my current prebuilt LunarG SDK (1.0.3.1) does not report anything in the case that pWaitDstStageMask is null and waitSemaphoreCount > 0.

Draw State layer does not remove a command buffer from the inFlightCmdBuffers set, even though it is implicitly waited upon with a vkWaitForFences() call, which later causes a crash

This issue came from LunarXchange (#307). To be assigned to Google in github.

Description

I'm getting a crash at vkDeviceWaitIdle() call time in the Draw State layer code because of the layer making an invalid assumption that there are command buffers in flight, even though they have been released a long time ago.

The long-dead command buffers are the ones which generate the problem I described earlier today in #303.

What may be also important to note is that the situation, in which #303 arises, results from a single vkQueueSubmit() call which submits 2 command buffers. Recently, the function has been refactored, so that it now is possible to submit multiple command buffers with a single call, and the expectation is that the fence the user (optionally; in this particular case, I do pass a non-NULL handle) specifies is going to be set only after all the command buffers finish executing. Could it be that the debug call-back causes that particular command buffer to not be removed from the dev_data->inFlightCmdBuffers set?

Dialogue from LunarXchange:
Dean Sekulic

I've encoutered the same problem and right before I started to write report here it occured to me that I did something wrong; in this particular case, I had "long-dead" command buffer, but I forgot to wait for its fence before destroying it!

And then validation layer correctly(!) reported something in line that fence (of alive command buffer) was waiting for destroyed command buffer also.

HTH

Dominik Witczak

"Never say never" :) however, we do have an object tracker that keeps track of objects that have not gone out of scope yet, and it does not indicate the object could be dangling somewhere.

@mark: should I quadruple-check this?

Dominik Witczak

Oh, and the app does wait on the fence :) Sorry, I missed that bit when I first read your message, Dean.

Tobine Ehlis

Dominik, can your run with GitHub master? If so, can you double-check and confirm if this is still an issue. I know some code changes related to this have gone in, but don't have a specific test case that was hitting your error.

loader: pointer cast build warnings

When cross-compiling for our 32-bit Linux embedded platform we see warnings regarding pointer casts due to non-dispatchable object handles being uint64_t on these platforms.

Here are the 3 warnings in question. They can all be trivially fixed by adding an intermediate cast to (uintptr_t) between the object and the final type.

[ 14%] Building C object loader/CMakeFiles/vulkan.dir/loader.c.o
.../Vulkan-LoaderAndValidationLayers/loader/loader.c: In function ‘loader_log’:
.../Vulkan-LoaderAndValidationLayers/loader/loader.c:238:33: warning: cast from pointer to integer of different size -Wpointer-to-int-castinst, 0, msg_code, "loader", msg);

[ 28%] Building C object loader/CMakeFiles/vulkan.dir/trampoline.c.o
.../Vulkan-LoaderAndValidationLayers/loader/trampoline.c: In function ‘vkCreateInstance’:
.../Vulkan-LoaderAndValidationLayers/loader/trampoline.c:86:33: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
instance_callback = (VkDebugReportCallbackEXT)ptr_instance;

[ 42%] Building C object loader/CMakeFiles/vulkan.dir/wsi.c.o
.../Vulkan-LoaderAndValidationLayers/loader/wsi.c: In function ‘loader_DestroySurfaceKHR’:
.../Vulkan-LoaderAndValidationLayers/loader/wsi.c:212:36: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
loader_heap_free(ptr_instance, (void *)surface);

Spacing in Paths

A path with a space in it, whether it be on Linux (update_external_sources.sh) or Windows( update_external_sources.bat), appears to be a nightmare. I did get the batch script to work on Windows with some simple quotes here and there, but then CMake gives me trouble with spacing as well.

This was a little rough since MSYS2 has somewhat of a weird scheme where my full name with a space was used but you can force a home directory name thankfully with a bit of trouble.

Would it be considered a bug to not have the scripts work with spaces in the current directory path?

Subpass index not being validated during pipeline creation

When calling vkCreateGraphicsPipelines, the subpass index represented in VkGraphicsPipelineCreateInfo is not validated against the amount of subpasses created with the vkCreateRenderPass function call.

Detecting descriptor set binding of mismatching type

Currently, the validation layer detects when having a descriptor set of type VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER bound to a binding point which is not declared by the shader. The shader (in GLSL syntax) declared a layout(binding=1) uniform Interfacename where the descriptor set bound to binding point 0.

The error message is something like this:
ERROR OCCURED: Shader uses descriptor slot 0.1 (used as type ptr to uniform struct of (mat4 of vec4 of float32)) but not declared in pipeline layout

However, I had a quite lengthy debug session where the actual error was mismatching descriptor types between shader and descriptor set. The shader (again in GLSL syntax) declared a layout(binding=0) buffer Interfacename where the descriptor set used a VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER type, however both used the same binding point 0.
Then, no error was reported, but rendering was obviously incorrect.

It would be nice if the validation layers check if also the descriptor/binding types between descriptor set and shader match, if at all possible.

Thanks!

Binding a copy of a descriptor set issues warning/error about it not beeing updated.

When binding a descriptor set that was creating using copied elements from other descriptor sets the validation layer output warningss/error:

[DS] Code 44 : DS 0x2a7ab888a60 bound but it was never updated. You may want to either update it or not bind it.
[DS] Code 44 : DS 0x2a7ab888a60 bound but it was never updated. It is now being used to draw so this will result in undefined behavior.

By looking at https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/master/layers/draw_state.cpp it looks like validation is done by checking if "pSet->pUpdateStructs != nullptr".
pUpdateStructs never gets created when doing a copy from another descriptor set.

loader: crashes with combination of implicit overlay layer and explicit layers

Here is the description of crash from Pierre-Loup at Valve.

"Correct, my setup was that all the DSOs and JSON manifest files from the validation layers were installed in /etc/vulkan/explicit_layers.d, and the Steam overlay setup was in place with the implicit layer. The overlay worked fine and the implicit layer was getting loaded, but trying to activate any additional layers through the environment from that selection of available explicit layers would crash the loader. "

The overlay layer should be the same (or similiar) to the one in LunarG VulkanSamples repo.

DrawState false positive claiming deleted event

Running vk_blit_tests with validation enabled, when I get to VkCmdCopyBufferTest.RAWHazard, I get 2 DS validation errors:

DS(ERROR): object: 0x277b420 type: 23 location: 3813 msgCode: 16: Cannot submit cmd buffer using deleted event 41399328.

Looking at the api_dump of the subtest, the event is created, then reset, then vkCmdSetEvent is put into a command buffer referencing it, then vkCmdWaitEvents is put into the command buffer referencing it. Ending the command buffer causes the above DrawState error twice, supposedly once for each reference in the command buffer. Nowhere in the call stream is the event destroyed.

Update Vulkan-LoaderAndValidationLayers to 1.0.4?

When is Vulkan-LoaderAndValidationLayers going to be updated to the latest revision of the api spec?

validatelayerdoc is missing IMAGE_INVALID_LAYOUT

[ RUN ] ./vkvalidatelayerdoc.sh
~/vk/vk ~/vk/vk/dbuild/tests
Error: Undefined DisplayServer
Doc is missing check: IMAGE_INVALID_LAYOUT
[ FAILED ] Validation of vk_validation_layer_details.md failed
[ FAILED ] 1 test
1 TEST FAILED

vkCmdCopyBufferToImage validates "source" image layout

The validation for vkCmdCopyBufferToImage is calling the wrong function for validating layouts:

diff --git a/layers/draw_state.cpp b/layers/draw_state.cpp
index 40fa5f0..31c8efd 100644
--- a/layers/draw_state.cpp
+++ b/layers/draw_state.cpp
@@ -6192,7 +6192,7 @@ VK_LAYER_EXPORT VKAPI_ATTR void VKAPI_CALL vkCmdCopyBufferToImage(VkCommandBuffe
         skipCall |= addCmd(dev_data, pCB, CMD_COPYBUFFERTOIMAGE, "vkCmdCopyBufferToImage()");
         skipCall |= insideRenderPass(dev_data, pCB, "vkCmdCopyBufferToImage");
         for (uint32_t i = 0; i < regionCount; ++i) {
-            skipCall |= VerifySourceImageLayout(commandBuffer, dstImage,
+            skipCall |= VerifyDestImageLayout(commandBuffer, dstImage,
                                                 pRegions[i].imageSubresource,
                                                 dstImageLayout);
         }

loader: Bad free() when running Hologram -v

In testing the fix for standard_validation, I reliably got an assert error when calling DestroySurfaceKHR->loader_heap_free->free(pMemory). The call works fine if I don't specify "-v" to Hologram to turn on validation. This is on Windows 7, Nvidia. Note that to enable validation properly in Hologram, you need to add a line to the Shell::Shell() constructor:

instance_layers_.push_back("VK_LAYER_LUNARG_standard_validation");

Ability to install to a prefix using make/cmake

Could you set it up to where we could install the libraries(layers and etc...) and headers under a prefix defaulting to /usr/local so we could install a local copy of the files where we could point all the tools and other sdk stuff to, it would make it so much simpler for us. Also it would help with packaging systems that don't use CPack or deb files. As it is now CMAKE_INSTALL_PREFIX and make install are ignored.

CPack usage

How do you think about to reuse the software "CPack"?

Memory Layer complaining about invalid memory being read by vkCmdCopyImageToBuffer(), even though it is correctly filled earlier.

This issue came from LunarXchange (issue number 303).

Consider the following command buffers:

Command Buffer 1: Blit image A to image B, possibly performing format conversion along the way. Command Buffer 2: Copy whole image B's contents to buffer X with a vkCmdCopyImageToBuffer() call.

Now, let's build a single submission consisting of the two command buffers. Let Command Buffer 1 signal a semaphore, that Command Buffer 2 waits upon before starting execution.

Once the command buffers finish executing, we try to map the buffer X's memory buffer into process space and read from it.

With this chain of action, I'm getting a call-back from the Memory layer, telling that "VkCmdCopyImageToBuffer(): Cannot read invalid memory <image B's memory buffer>, please fill the memory before using.", which I believe is incorrect.

loader: instance WSI extensions that can be compiled out of loader falsely reported

The WSI surface extensions on Linux are not always built into the loader. This is problematic since
if a driver reports an extension supported you really need the loader to also support the instance
extension for it to work.

A couple solutions:

1. On linux always compile in all four WSI surface extensions
2. Add code to loader filter out any reported instance extensoins by ICD that also require loader support that is not built in.

I favor 2) since this is a general problem of new extensions that a ICD supports but the loader doesn't support yet (or not in the loader version one i suing.)

Improve version identification

Would you like to extend the specification of version information for the involved software components?

Enabling Wayland disables XCB?

I wanted to play with Wayland surfaces, was disappointed finding out that loader from sdk-1.0.3 won't handle that (failing in a very non-obvious way, I spent few hours with gdb before it occurred to me, that the support is just not there) and then happy seeing this implemented on the master branch (through #17).

I rushed to apply those changes, but it failed to build due to ${DisplayServer} not being set it make. I could fix that, but it seems it can be set to either Xcb or Wayland. Does this mean that Vulkan-LoaderAndValidationLayers can be built to support Xcb or Wayland, but not both?

It seems the difference is only in the generated code of the layers, but still, is this limitation necessary? On Linux Wayland and X11 are supposed to be used, by different applications, at the same time, on the same system, at least for some undefined transition period.

Remove unnecessary null pointer checks

An extra null pointer check is not needed in functions like the following.

• VkRenderFramework::ShutdownFramework
• _DESCRIPTOR_POOL_NODE

[draw_state] Handle descriptors dynamically skipped in shader

From LunarXchange #325 from Baldur:

At the moment I have a 'render a texture' shader in renderdoc that has each different type of sampler - 2D array (which could have just 1 slice for just a 'normal' 2D image), 1D array similarly, 3D and 2DMS. Each of these is also duplicated for regular float, uint and int types.
The shader itself only ever samples from one of these 12 images, which one is determined by a uniform uploaded. I only set the corresponding descriptor and update it, the others I leave undefined (either unset, or set from previous use).

This currently crashes in the draw state validation layer, in this loop:
static VkBool32 validate_dynamic_offsets(layer_data* my_data, const GLOBAL_CB_NODE* pCB, const vector<SET_NODE*> activeSetNodes)
{
VkBool32 result = VK_FALSE;

VkWriteDescriptorSet* pWDS = NULL;
uint32_t dynOffsetIndex = 0;
VkDeviceSize bufferSize = 0;
for (auto set_node : activeSetNodes) {
    for (uint32_t i=0; i < set_node->descriptorCount; ++i) {
        switch (set_node->ppDescriptors[i]->sType) {
            case VK_STRUCTURE_TYPE_WRITE_DESCRIPTOR_SET:

because that set_node->ppDescriptors could have some elements be NULL if they haven't been set. This crash should probably be fixed but I'm not clear if this is invalid or not.
I believe that descriptors which aren't used by the shader are allowed to be undefined - either unset, set to deleted objects, or something else. I'm not sure if that applies to descriptors which are used by the shader (in theory) but are then skipped by shader execution. I assume these probably have to be set to something valid, but does that also mean they have to be set to a valid texture of the write type? ie. 1D for 1D, 2D for 2D, etc.

Michael Lentine:
My understanding is that descriptors can have null elements (I would also assume this applies to those that are skipped by shader execution - seems weird to me to have different answers depending on if its used).

Tobin Ehlis:
Seeing NULL ppDescriptors during dynamic offset validation makes me think there's a bug in draw_state. Guarding against this case with the check as you have is certainly a reasonable workaround for the time being.
I suspect a bug b/c those should be active sets, meaning that the shaders are using them and they've been updated so we should have updated data.
Can you put a "TODO" comment in the code at the NULL check and file a GitHub issue against me to investigate and fix this case?
With the workaround I don't consider it high priority but would definitely like to get to it and the solution may involve replacing ppDescriptors with something better as that struct is kind of a vestige of the old, original C-based data structs.

The draw state validation layer incorrectly reports layout error when submitting command buffer.

Using latest code, I get the following error when submitting a command buffer:

"Cannot submit cmd buffer using image with layout VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL when first use is VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL."

Unfortunately the error message does not provide any indication which image is considered problematic (should be an easy fix).

Considering I am rendering to a texture I assume that it is complaining about the frame buffer image. I am not using the render pass initialLayout and finalLayout to transition the image layout. Instead, I am using explicit image memory barrier outside the render pass to transition from VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL to VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL before rendering, and from VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL to VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL after rendering.

The first frame there are no problems. The second frame is the first time I run into the following assert:

// TODO (mlentine): Maybe make vector a set?
assert(std::find(pCB->imageSubresourceMap[image].begin(),
                 pCB->imageSubresourceMap[image].end(),
                 imgpair) != pCB->imageSubresourceMap[image].end());

VkLayer_draw_state.dll!SetLayout(_GLOBAL_CB_NODE * pCB, VkImage_T * image, ImageSubresourcePair imgpair, const VkImageLayout & layout) Line 2436    C++
VkLayer_draw_state.dll!SetLayout(_GLOBAL_CB_NODE * pCB, VkImage_T * image, VkImageSubresource range, const VkImageLayout & layout) Line 2461    C++
VkLayer_draw_state.dll!SetLayout(const layer_data * dev_data, _GLOBAL_CB_NODE * pCB, VkImageView_T * imageView, const VkImageLayout & layout) Line 2477 C++
VkLayer_draw_state.dll!TransitionFinalSubpassLayouts(VkCommandBuffer_T * cmdBuffer, const VkRenderPassBeginInfo * pRenderPassBegin) Line 7144   C++
VkLayer_draw_state.dll!vkCmdEndRenderPass(VkCommandBuffer_T * commandBuffer) Line 7211  C++

If I ignore the assert a bunch of times, then a several frames later I hit the aforementioned error.

DebugReportCallback(unsigned int msgFlags, VkDebugReportObjectTypeEXT objType, unsigned __int64 srcObject, unsigned __int64 location, int msgCode, const char * pLayerPrefix, const char * pMsg, void * pUserData) Line 2062    C
VkLayer_draw_state.dll!debug_report_log_msg(_debug_report_data * debug_data, unsigned int msgFlags, VkDebugReportObjectTypeEXT objectType, unsigned __int64 srcObject, unsigned __int64 location, int msgCode, const char * pLayerPrefix, const char * pMsg) Line 73    C++
VkLayer_draw_state.dll!log_msg(_debug_report_data * debug_data, unsigned int msgFlags, VkDebugReportObjectTypeEXT objectType, unsigned __int64 srcObject, unsigned __int64 location, int msgCode, const char * pLayerPrefix, const char * format, ...) Line 301 C++
VkLayer_draw_state.dll!ValidateCmdBufImageLayouts(VkCommandBuffer_T * cmdBuffer) Line 3763  C++
VkLayer_draw_state.dll!vkQueueSubmit(VkQueue_T * queue, unsigned int submitCount, const VkSubmitInfo * pSubmits, VkFence_T * fence) Line 4058   C++

The image is only rendered to in the submitted command buffer, so it's unclear why the validation layer thinks the first use of the image is VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL. It is also unclear why the validation layer only complains after a couple of frames, when every frame it renders the same way.

Image layer logs error for intialLayout not in proper state for cube and tri

Brief glance at cube.c. I see a spot where initialLayout is not set correctly. I am assuming this is a test problem in tri and cube rather than a problem in image layer. But whoever fixes this needs to figure out where the bug is.

VkPipelineColorBlendStateCreateInfo must have matching number of VkPipelineColorBlendAttachmentState

I was recently debugging an issue with a Vulkan application which works perfectly well on Nvidia but does not draw anything on AMD.
Both of them had the very latest Vulkan Beta Nvidia and Radeon drivers installed.

• Nvidia 356.43 on Windows 7 x64 with a Quadro K2000M
• AMD Radeon 16.15.1009 Beta 5 on Windows 7 x64 with a Radeon HD 8790M

The problem in the end was that VkGraphicsPipelineCreateInfo had a valid pColorBlendState of type VkPipelineColorBlendStateCreateInfo, but that VkPipelineColorBlendStateCreateInfo did not have any VkPipelineColorBlendAttachmentState attachments in its pAttachments.

The rationale behind that was that blending was not used, BUT the bad thing was that this blend state also contains the color write mask, which Nvidia apparently interpreted as 0xF (all of RGBA written) and AMD as 0x0 (none written) when no VkPipelineColorBlendAttachmentState is present.
So Nvidia's driver behaved - let's say - "more lenient."

The validation layers had nothing to say on this.

The spec says the following:

VkPipelineColorBlendStateCreateInfo* pColorBlendState;
"pColorBlendState is a pointer to an instance of the VkPipelineColorBlendStateCreateInfo structure,
or NULL if the pipeline has rasterization disabled or if the subpass of the render pass the pipeline is created against does not use any color attachments."

It says that the pColorBlendState is only to be NULL if rasterization is to be disabled or no color attachments should be used, BUT it does not say what happens when pColorBlendState is not null but at the same time there is no contained pAttachments within that VkPipelineColorBlendStateCreateInfo.

It would be nice if the validation layers catches this. This essentially means that on render pass being, it should be checked whether (page 466 of the Vulkan spec PDF):

attachmentCount is the number of VkPipelineColorBlendAttachmentState elements in
pAttachments. This value must equal the colorAttachmentCount for the subpass in which this pipeline is used.

loader: mutliple ICD JSON files found can lead to crashes

Saw this with using debug_marker dev ext in draw_state.
Also saw this with duplicating Ilo driver JSON file. May not be the same issue though?

demos/tri.c: VkAllocationCallbacks is broken

demos/tri.c implements VkAllocationCallbacks with aligned_alloc/_aligned_malloc, free/_aligned_free, and realloc.

I belive that is broken in many ways:

• realloc does not return a pointer with the necessary alignment.
• realloc(_aligned_malloc(...)) crashes.
• _aligned_free(realloc(...)) crashes.
• aligned_alloc requires that size must be a multiple of alignment, while Vulkan provides no such guarantee to these callbacks.
• On POSIX-based implementations, aligned_alloc requires that alignment must be a multiple of sizeof(void *) as well as a power of two, while Vulkan merely requires it to be a power of two.
• aligned_alloc(0), realloc(p, 0) might return non-NULL, while I think Vulkan requires NULL.
• _aligned_malloc(0, a) is documented to invoke the invalid parameter handler (although I'm not sure it actually does in practice).

Implementing a valid allocator is quite non-trivial, so it may be best to just delete the allocator entirely from the demo.

(See also KhronosGroup/Vulkan-Docs#21 and KhronosGroup/Vulkan-Docs#103 for related discussions.)

Link to vk_layer_settings.txt broken

A link to the vk_layer_settings.txt is broken in this README.
It seems to include an unnecessary extra "layers/"

Remove LunarGLASS from update_external_sources.sh?

Without the LunarG driver in this repo, I wonder if LunarGLASS is still a necessary dependency for this repo? It would greatly shorten build time for new users to not build LunarGLASS if it is not necessary.

Become the most popular graphics API

Vulkan has the potential to become the most popular graphics API, but:

• I hope, in order to minimize the complexity, boilerplate libraries will emerge and provide abstraction layers fitting for different applications. Some of those should probably be officially supported/listed.

  Only then, those small hobby projects will have a chance to use Vulkan and developers get familiar with it. Just targetting AAA engines will lead to having very few developers that use and understand the API which makes it popular.

• In order to prevent totally outdated guides and scattering the community, a central wiki should be in place from the beginning. There, howtos, examples, tutorials and tipps & tricks should be placed and maintained.

• After programs have been written, they will most likely not be updated for new Vulkan versions. Although that was never the problem with e.g. OpenGL, I can only hope Vulkan won't do things like the Python2->3 breakage, qt3->4->5, gtk2->3, gnome2->3, kde4->5, etc.
  Instead, following the Linux kernel way will guarantee ABI stability for a minimalistic interface that provides space for internal improvements and reliably sane behavior.

If the interface remains stable and the community is actively integrated and supported into further evolvement of Vulkan and not only industry giants, the success is probably guaranteed.

Thanks for making all this possible 😄

(and please, use a better repo name...)

assert in vk_layer_validation_test

[ RUN ] VkLayerTest.CreatePipelineAttribMatrixType
/home/jon/vk/vk/tests/vktestbinding.cpp:555: Failure
Failed
Assertion: `vkCreateImage(dev.handle(), &info, __null, &handle) == VK_SUCCESS'
Segmentation fault (core dumped)

Better handling of VK_REMAINING_MIP_LEVELS and VK_REMAINING_ARRAY_LEVELS

Was running with a debug build of the draw_state layer and noticed that some of the loops would loop from 0 to 2^32, thus getting stuck in the validation layers.

Maybe clamp the internal loops by something smaller? Maybe based device limits or actual number of mips / array levels of the resource in question?

draw_state.cpp::find_entrypoint crashes if name is 0

I don't know whether this is covered by the param_checkers_layer, but ideally find_entrypoint would early out if name is null

vk_layer_validation_tests test failure.

vk_layer_validation_tests fails at VkLayerTest.StencilReadMaskNotSet and does a core dump. But it will run it run through gdb.

Nvidia drivers version: 355.00.28

branch: master
commit: 6c2c061

core file:
https://dl.dropboxusercontent.com/u/71062164/Vulkan/vk_layer_validation_tests.tar.xz

run through gdb:
https://gist.github.com/salamanderrake/d2ff98052142f75badcd

run without gdb:
https://gist.github.com/salamanderrake/608e60c5cda93504b246

System specs:
https://gist.github.com/salamanderrake/935ecc98805b0bfcd890

ldd vk_layer_validation_tests
    linux-vdso.so.1 =>  (0x00007ffc54d79000)
    libvulkan.so.1 => /mnt/store/vulkan/Vulkan-LoaderAndValidationLayers/dbuild/loader/libvulkan.so.1 (0x00007f62c134f000)
    libgtest.so => /mnt/store/vulkan/Vulkan-LoaderAndValidationLayers/dbuild/tests/gtest-1.7.0/libgtest.so (0x00007f62c10cf000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f62c0e87000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f62c0aff000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f62c07f7000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f62c05df000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f62c020f000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f62c0007000)
    /lib64/ld-linux-x86-64.so.2 (0x000055985c5f6000)

 export
declare -x CLUTTER_IM_MODULE="xim"
declare -x COMPIZ_BIN_PATH="/usr/bin/"
declare -x COMPIZ_CONFIG_PROFILE="ubuntu"
declare -x DBUS_SESSION_BUS_ADDRESS="unix:abstract=/tmp/dbus-v8qhDmjMfI"
declare -x DEFAULTS_PATH="/usr/share/gconf/ubuntu.default.path"
declare -x DESKTOP_SESSION="ubuntu"
declare -x DISPLAY=":0"
declare -x GDMSESSION="ubuntu"
declare -x GDM_LANG="en_US"
declare -x GNOME_DESKTOP_SESSION_ID="this-is-deprecated"
declare -x GNOME_KEYRING_CONTROL=""
declare -x GNOME_KEYRING_PID=""
declare -x GPG_AGENT_INFO="/tmp/gpg-ABEu2S/S.gpg-agent:9780:1"
declare -x GTK2_MODULES="overlay-scrollbar"
declare -x GTK_IM_MODULE="ibus"
declare -x GTK_MODULES="gail:atk-bridge:unity-gtk-module"
declare -x HISTFILESIZE="1000000000"
declare -x HISTSIZE="1000000"
declare -x HOME="/home/rake"
declare -x IM_CONFIG_PHASE="1"
declare -x INSTANCE=""
declare -x JOB="unity-settings-daemon"
declare -x LANG="en_US.UTF-8"
declare -x LANGUAGE="en_US"
declare -x LD_LIBRARY_PATH="::/mnt/store/vulkan/VulkanTools/dbuild/loader:/mnt/store/vulkan/LunarGLASS/build/install/lib/:"
declare -x LESSCLOSE="/usr/bin/lesspipe %s %s"
declare -x LESSOPEN="| /usr/bin/lesspipe %s"
declare -x LOGNAME="rake"
declare -x LS_COLORS="rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:"
declare -x MANDATORY_PATH="/usr/share/gconf/ubuntu.mandatory.path"
declare -x OAUTH_TOKEN="d9aac8314e4f4e9cdb85949e43bf2a72390fa096"
declare -x OLDPWD="/mnt/store/vulkan/Vulkan-LoaderAndValidationLayers"
declare -x P4CONFIG=".p4config"
declare -x PATH=":/mnt/store/vulkan/LunarGLASS/build/install/bin/:/mnt/store/vulkan/VulkanTools/dbuild/vktrace::/opt/p4/bin:/home/rake/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:~/bin:"
declare -x PWD="/mnt/store/vulkan/Vulkan-LoaderAndValidationLayers/dbuild/tests"
declare -x QT4_IM_MODULE="xim"
declare -x QT_ACCESSIBILITY="1"
declare -x QT_IM_MODULE="ibus"
declare -x QT_LINUX_ACCESSIBILITY_ALWAYS_ON="1"
declare -x QT_QPA_PLATFORMTHEME="appmenu-qt5"
declare -x SESSION="ubuntu"
declare -x SESSIONTYPE="gnome-session"
declare -x SHELL="/bin/bash"
declare -x SHLVL="1"
declare -x SSH_AUTH_SOCK="/run/user/1000/keyring/ssh"
declare -x TERM="xterm-256color"
declare -x UPSTART_EVENTS="xsession started"
declare -x UPSTART_INSTANCE=""
declare -x UPSTART_JOB="unity7"
declare -x UPSTART_SESSION="unix:abstract=/com/ubuntu/upstart-session/1000/9651"
declare -x USER="rake"
declare -x VK_LAYER_PATH=":/mnt/store/vulkan/VulkanTools/dbuild/layers"
declare -x VTE_VERSION="4204"
declare -x WINDOWID="113246218"
declare -x WINEARCH="win32"
declare -x WINEDEBUG="-all"
declare -x XAUTHORITY="/home/rake/.Xauthority"
declare -x XDG_CONFIG_DIRS="/etc/xdg/xdg-ubuntu:/usr/share/upstart/xdg:/etc/xdg"
declare -x XDG_CURRENT_DESKTOP="Unity"
declare -x XDG_DATA_DIRS="/usr/share/ubuntu:/usr/share/gnome:/usr/local/share/:/usr/share/"
declare -x XDG_GREETER_DATA_DIR="/var/lib/lightdm-data/rake"
declare -x XDG_RUNTIME_DIR="/run/user/1000"
declare -x XDG_SEAT="seat0"
declare -x XDG_SEAT_PATH="/org/freedesktop/DisplayManager/Seat0"
declare -x XDG_SESSION_DESKTOP="ubuntu"
declare -x XDG_SESSION_ID="c3"
declare -x XDG_SESSION_PATH="/org/freedesktop/DisplayManager/Session0"
declare -x XDG_SESSION_TYPE="x11"
declare -x XDG_VTNR="7"
declare -x XMODIFIERS="@im=ibus"

The draw state validation layer incorrectly reports that a swapchain image is invalid when used as a storage image.

Using latest code, I get the following error when updating a descriptor set that uses a swapchain image as a storage image:

"vkUpdateDescriptorSets: Attempt to update descriptor with invalid image 0xe7f1268800 in imageView 0xe7f1274b70"

!DebugReportCallback(unsigned int msgFlags, VkDebugReportObjectTypeEXT objType, unsigned __int64 srcObject, unsigned __int64 location, int msgCode, const char * pLayerPrefix, const char * pMsg, void * pUserData) Line 2095   C
VkLayer_draw_state.dll!debug_report_log_msg(_debug_report_data * debug_data, unsigned int msgFlags, VkDebugReportObjectTypeEXT objectType, unsigned __int64 srcObject, unsigned __int64 location, int msgCode, const char * pLayerPrefix, const char * pMsg) Line 73    C++
VkLayer_draw_state.dll!log_msg(_debug_report_data * debug_data, unsigned int msgFlags, VkDebugReportObjectTypeEXT objectType, unsigned __int64 srcObject, unsigned __int64 location, int msgCode, const char * pLayerPrefix, const char * format, ...) Line 301 C++
VkLayer_draw_state.dll!validateImageView(const layer_data * my_data, VkImageView_T * const * pImageView, const VkImageLayout imageLayout) Line 2557 C++
VkLayer_draw_state.dll!validateUpdateContents(const layer_data * my_data, const VkWriteDescriptorSet * pWDS, const VkDescriptorSetLayoutBinding * pLayoutBinding) Line 2677 C++
VkLayer_draw_state.dll!dsUpdate(layer_data * my_data, VkDevice_T * device, unsigned int descriptorWriteCount, const VkWriteDescriptorSet * pWDS, unsigned int descriptorCopyCount, const VkCopyDescriptorSet * pCDS) Line 2787  C++
VkLayer_draw_state.dll!vkUpdateDescriptorSets(VkDevice_T * device, unsigned int descriptorWriteCount, const VkWriteDescriptorSet * pDescriptorWrites, unsigned int descriptorCopyCount, const VkCopyDescriptorSet * pDescriptorCopies) Line 5080    C++
VkLayer_device_limits.dll!vkUpdateDescriptorSets(VkDevice_T * device, unsigned int descriptorWriteCount, const VkWriteDescriptorSet * pDescriptorWrites, unsigned int descriptorCopyCount, const VkCopyDescriptorSet * pDescriptorCopies) Line 663  C++

validate_pipeline_shaders doesn't catch invalid VkPipelineShaderStageCreateInfo name

The spec states:

• pName must be the name of an OpEntryPoint in module with an execution model that matches stage

But the current validation layers don't check this and both AMD and Nvidia drivers blow up and return weird errors on VkGraphicsPipelineCreate if pName doesn't match your shader's entry point. Should be easy enough to check.

mem_tracker incorrect errors

It seems that the mem_tracker layer treats images as buffers when dispatching compute commands (leading to incorrect errors about unbound memory).

This line seems to be the cause. I believe it should be VK_DEBUG_REPORT_OBJECT_TYPE_IMAGE_EXT instead.

Draw state layer tries to traverse VkSwapchainCreateInfoKHR::pQueueFamilyIndices array even if imageSharingMode is set to VK_SHARING_MODE_EXCLUSIVE

Originally posted on gitlab by Dominick Witczak. Moved to this public github.

As per spec, this behavior is invalid: VkSwapchainCreateInfoKHR::pQueueFamilyIndices is an array of queue family indices having access to the images of the swapchain in case imageSharingMode is VK_SHARING_MODE_CONCURRENT.

Validation layers don't detect use-after-free

Found in a bug on RenderDoc (baldurk/renderdoc#194) - the user was calling vkDestroyFramebuffer before submitting that command buffer, so the framebuffer is referenced in that submission after having been destroyed.

loader: standard_validation meta layer doesn't report extensions from the underlying layers

VulkanRT installer's temporary directory/files should use strong ACLs

Originally submitted on gitlab by Jeff Juliano. Moved to the public github.

I'm filing this for record. I don't know yet if there is an actual issue.
The VulkanRT installer unpacks a few files that are written to a temporary location. One of the files is a powershell script that is executed from the temporary location with escalated privilege.
The temporary files should employ strong ACLs to ensure there are no timing attacks against the installer during the unpack and install phase.
The point of this issue is to validate that strong ACLs are used. If that's already the case then the issue can be trivially closed. If it's not the case then it needs to be secured. I haven't been able to determine yet if the temporary files are adequately secured.
The final installed loader and uninstaller binaries are themselves secured because they reside in %windir% and %programfiles%, resp. The question is about temporary files during execution of the installer.

DrawState: crash on vkUpdateDescriptorSets

Hi,

we encounter a crash while calling vkUpdateDescriptorSets when the draw_state layer is active.

In draw_state.cpp:validateSampler:
line:2588: auto sampIt = my_data->sampleMap.find(*pSampler);

Reason:
pSampler is an invalid pointer.

pSampler is inavlid because in line 2968:
if ((skipCall = validateUpdateContents(my_data, &pWDS[i], &pLayout->createInfo.pBindings[binding])) == VK_FALSE) using binding as index for pBindings is invalid for sparsely defined descriptor sets.

This is also a regression to previous versions of the sdk.

The draw state validation layer incorrectly reports that an image layout is VK_IMAGE_LAYOUT_TRANSFER_SRC_LAYOUT.

Using latest code, I get the following error every once in a while when mapping an image that has just been created with VK_IMAGE_LAYOUT_PREINITIALIZED.

"Cannot map an image with layout VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL. Only GENERAL or PREINITIALIZED are supported."

Publish .pdb for VulkanRT installer and VulkanRT uninstaller

Originally posted on private gitlab by Jeff Juliano. Moved to this public github.

A security audit of the VulkanRT installer and uninstaller has generated a request for a pair of .pdb files that match the two .exe files. They are wanted in order to support running a Binscope scan on the .exe files.
I'm not certain, but passing a Binscope scan might be a requirement for including these files in a driver package that gets posted to Windows Update. (I'll try o verify this claim.)
Publishing the .pdb files privately would be sufficient. They need not be published to the public.

Provide dependencies to 3rd party packages, such as lxml for Windows

I spent a hairy amount of yak-shaving on getting the layers to build on Windows and my conclusion is that there is room for improvement to stream-line the build process on Windows.

Most layers build successfully, but the dependency on the lxml python package has been most vexing, as manifested with this error during the build of VkLayer_param_checker:

Traceback (most recent call last):
File "C:/VulkanSDK/Github/Git/genvk.py", line 25, in
from reg import *
File "C:\VulkanSDK\Github\Git\reg.py", line 25, in
from lxml import etree
ImportError: No module named 'lxml'

As part of (unrelated) #39, @cnorthrop and @jon-lunarg provided helpful pointers and documented the dependency in BUILD.md and also point to pre-built Windows binaries of said lxml Python package.

However in the end this did not work since all links on http://www.lfd.uci.edu/~gohlke/pythonlibs/#lxml are dead/and/or timing out with all the various browsers I tried.

Next I tried installing lxml via pip and easy_install, which then turned into an egg-hunt for source for development packages libxml2 and libxslt, which I chased down from ftp://xmlsoft.org/libxml2/win32/

But ultimately 'xslt-config' is not recognized as an internal or external command,' oversaturated my thirst to learn more about the curious world of any subset of Python XML package management (or lack thereof).

Which leads to my questions:

1. Is there a specific reason why the both the spec and layers depend on lxml lib and not the core Python built-in XML support?
2. If there is a strong and valid reason would it be possible to provide the dependencies (such as pre-built lxml Windows packages ) as part of the Github repository?
3. When would this be resolved either way?

Regardless of fundamental differences between Windows and Linux wrt setting up a build environment I strongly believe that a key Vulkan ecosystem component, such as the loader & layers should reduce external dependencies to the minimum and if that's not feasible, host those that are not installed by default by other dependencies (such as Python, or Cmake) as part of the Git repository.

mem tracker validation layer incorrectly assumes VkSemaphore values are unique

From the Vulkan specification:

Non-dispatchable handle types are a 64-bit integer type whose meaning is implementation-dependent, and may encode object information directly in the handle rather than pointing to a software structure. Objects of a non-dispatchable type may not have unique handle values within a type or across types. If handle values are not unique, then destroying one such handle must not cause identical handles of other types to become invalid, and must not cause identical handles of the same type to become invalid if that handle value has been created more times than it has been destroyed.

The Intel driver from Mesa repository always returns value 1 for vkCreateSemaphore() which is valid according to the specification, but causes validation errors when more than one such semaphore is used:

SEMAPHORE(ERROR): object: 0x1 type: 5 location: 1443 msgCode: 0: vkQueueSubmit: Semaphore must not be currently signaled or in a wait state

I know this mem_tracker behaviour might be very useful for debugging (on platforms implementing real semaphores), but it might generate scary looking false positives on compliant devices and valid application code.

Discussion on the mesa-dev mailing list: https://lists.freedesktop.org/archives/mesa-dev/2016-February/108737.html

VULKAN_WSI environment variable scoping

Hello!

I'm aware that XCB is the only Linux WSI with solid support right now, but in attempting to test PR #17, I noticed something that doesn't jive with certain shells and automated packaging systems.

set(ENV{VULKAN_WSI} "Wayland")

I'm on Arch Linux using a PKGBUILD script from AUR to automate the clone, build and package. When the script finishes executing cmake, the ENV goes out of scope and the makefile rules calling vk-layer-generate.py won't propagate VULKAN_WSI, always defaulting to XCB as a result.

In my opinion, having the WSI passed as a CLI argument is a much more stable way to pass this option.. thereby persisting in the makefiles themselves.

Incorrect validation warning with vkAcquireNextImageKHR fence

Reposted by request from this forum thread:

When supplying a fence to vkAcquireNextImageKHR, later calls to query fence status or wait on the fence generate a validation error:

"[MEM] Code 14: vkGetFenceStatus called for fence 0x26f310b1c40 which has not been submitted on a Queue"

reserved identifier violation

I would like to point out that identifiers like "_CALL_STATE" and "_CMD_TYPE" do not fit to the expected naming convention of the C++ language standard.
Would you like to adjust your selection for unique names?

loader: physical devices are aliased within an instance

This might manifest as issues with multiple devices discovered via JSON files.

UninstallVulkanRT.exe is not digitally signed

Originally posted on private gitlab by Jeff Juliano. Moved to this public github.

The VulkankRT uninstaller, UninstallVulkanRT.exe, is not digitally signed.
It should be signed, probably with the same key that is used to sign the VulkanRT installer.
It's against policy for my display driver uninstaller to invoke a .exe that is not signed.