source access mask should be VK_ACCESS_TRANSFER_WRITE_BIT

The current framework still uses the old VK_EXT_debug_report extension and functionality for validation layer output. We should instead use the newer VK_EXT_debug_utils as described per this document from LunarG.

The cpp file for this example references textures/checkerboard_rgba.ktx and scenes/tunnel_cylinder.gltf but these files are not present under the assets folder.

Running the example throws an exception when the KTX loader fails to find the file.

Several errors from git clone --recurse-submodules https://github.com/KhronosGroup/Vulkan-Samples.git under win10 resulting in several empty directories( subsequent build attempt fails too):

git clone --recurse-submodules https://github.com/KhronosGroup/Vulkan-Samples.git
Cloning into 'Vulkan-Samples'...
remote: Enumerating objects: 118, done.
remote: Counting objects: 100% (118/118), done.
remote: Compressing objects: 100% (105/105), done.
remote: Total 2029 (delta 36), reused 37 (delta 13), pack-reused 1911R
Receiving objects: 100% (2029/2029), 18.87 MiB | 2.79 MiB/s, done.
Resolving deltas: 100% (1168/1168), done.
Checking connectivity... done.
Submodule 'assets' (https://github.com/KhronosGroup/Vulkan-Samples-Assets) registered for path 'assets'
Submodule 'third_party/CTPL' (https://github.com/vit-vit/CTPL) registered for path 'third_party/CTPL'
Submodule 'third_party/astc' (https://github.com/ARM-software/astc-encoder) registered for path 'third_party/astc'
Submodule 'third_party/docopt' (https://github.com/docopt/docopt.cpp) registered for path 'third_party/docopt'
Submodule 'third_party/glfw' (https://github.com/glfw/glfw) registered for path 'third_party/glfw'
Submodule 'third_party/glm' (https://github.com/g-truc/glm) registered for path 'third_party/glm'
Submodule 'third_party/glslang' (https://github.com/KhronosGroup/glslang) registered for path 'third_party/glslang'
Submodule 'third_party/hwcpipe' (https://github.com/ARM-software/HWCPipe) registered for path 'third_party/hwcpipe'
Submodule 'third_party/imgui' (https://github.com/ocornut/imgui) registered for path 'third_party/imgui'
Submodule 'third_party/ktx' (https://github.com/KhronosGroup/KTX-Software) registered for path 'third_party/ktx'
Submodule 'third_party/spdlog' (https://github.com/gabime/spdlog) registered for path 'third_party/spdlog'
Submodule 'third_party/spirv-cross' (https://github.com/KhronosGroup/SPIRV-Cross) registered for path 'third_party/spirv-cross'
Submodule 'third_party/stb' (https://github.com/nothings/stb) registered for path 'third_party/stb'
Submodule 'third_party/tinygltf' (https://github.com/syoyo/tinygltf) registered for path 'third_party/tinygltf'
Submodule 'third_party/vma' (https://github.com/GPUOpen-LibrariesAndSDKs/VulkanMemoryAllocator) registered for path 'third_party/vma'
Submodule 'third_party/volk' (https://github.com/zeux/volk) registered for path 'third_party/volk'
Submodule 'third_party/vulkan' (https://github.com/KhronosGroup/Vulkan-Headers) registered for path 'third_party/vulkan'
Cloning into 'assets'...
remote: Enumerating objects: 26, done.
remote: Counting objects: 100% (26/26), done.
remote: Compressing objects: 100% (24/24), done.
remote: Total 242 (delta 6), reused 11 (delta 2), pack-reused 216
Receiving objects: 100% (242/242), 177.26 MiB | 2.83 MiB/s, done.
Resolving deltas: 100% (47/47), done.
Checking connectivity... done.
fatal: reference is not a tree: e42b9697fa7708f2cca01a82369b31a1ec8a70b4
Cloning into 'third_party/CTPL'...
remote: Enumerating objects: 82, done.
remote: Total 82 (delta 0), reused 0 (delta 0), pack-reused 82
Unpacking objects: 100% (82/82), done.
Checking connectivity... done.
Submodule path 'third_party/CTPL': checked out '437e135dbd94eb65b45533d9ce8ee28b5bd37b6d'
Cloning into 'third_party/astc'...
remote: Enumerating objects: 333, done.
remote: Counting objects: 100% (333/333), done.
remote: Compressing objects: 100% (232/232), done.
remote: Total 1728 (delta 179), reused 235 (delta 96), pack-reused 1395
Receiving objects: 100% (1728/1728), 33.18 MiB | 2.53 MiB/s, done.
Resolving deltas: 100% (1157/1157), done.
Checking connectivity... done.
fatal: reference is not a tree: 6d4094b122476ddc404fcc061b53241af5a6a80b
Cloning into 'third_party/docopt'...
remote: Enumerating objects: 19, done.
remote: Counting objects: 100% (19/19), done.
remote: Compressing objects: 100% (19/19), done.
Receiving objects: 100% (307/307), 108.18 KiB | 0 bytes/s, done.8 eceiving objects:  97% (298/307)

Resolving deltas: 100% (171/171), done.
Checking connectivity... done.
Submodule path 'third_party/docopt': checked out '3dd23e3280f213bacefdf5fcb04857bf52e90917'
Cloning into 'third_party/glfw'...
remote: Enumerating objects: 25743, done.
remote: Total 25743 (delta 0), reused 0 (delta 0), pack-reused 25743
Receiving objects: 100% (25743/25743), 12.27 MiB | 1.63 MiB/s, done.
Resolving deltas: 100% (18158/18158), done.
Checking connectivity... done.
Submodule path 'third_party/glfw': checked out '90e22947c60b0c1fa47cf1496790ce1942e4a5d8'
Cloning into 'third_party/glm'...
remote: Enumerating objects: 33, done.
remote: Counting objects: 100% (33/33), done.
remote: Compressing objects: 100% (28/28), done.
Rremote: Total 55744 (delta 12), reused 17 (delta 4), pack-reused 55711
Receiving objects: 100% (55744/55744), 68.83 MiB | 2.79 MiB/s, done.
Resolving deltas: 100% (42102/42102), done.
Checking connectivity... done.
Submodule path 'third_party/glm': checked out 'fce2abd01ce21063bd25ba67c9318be83bf48813'
Cloning into 'third_party/glslang'...
remote: Enumerating objects: 19, done.
remote: Counting objects: 100% (19/19), done.
remote: Compressing objects: 100% (19/19), done.
remote: Total 44296 (delta 4), reused 5 (delta 0), pack-reused 44277 eceiving objects: 100% (44296/44296), 55.96 MiB | 2.78 MiB/s   Receiving objects: 100% (44296/44296), 55.99 MiB | 2.76 MiB/s, done.

Resolving deltas: 100% (37397/37397), done.
Checking connectivity... done.
Submodule path 'third_party/glslang': checked out '9983f99e87ab0b6608b236ea59bcf873f90e1435'
Cloning into 'third_party/hwcpipe'...
remote: Enumerating objects: 20, done.
remote: Counting objects: 100% (20/20), done.
remote: Compressing objects: 100% (17/17), done.
Receiving objects: 100% (241/241), 215.08 KiB | 0 bytes/s, done.1 eceiving objects:  98% (237/241)

Resolving deltas: 100% (117/117), done.
Checking connectivity... done.
Submodule path 'third_party/hwcpipe': checked out '69d6b734ff129686f73ee817361fe91f99358541'
Cloning into 'third_party/imgui'...
remote: Enumerating objects: 251, done.
remote: Counting objects: 100% (251/251), done.
remote: Compressing objects: 100% (72/72), done.
remote: Total 33701 (delta 187), reused 240 (delta 179), pack-reused 33450 eceiving objects: 100% (33701/33701), 52.26 MiB | 2.82 MiReceiving objects: 100% (33701/33701), 52.60 MiB | 2.82 MiB/s, done.

Resolving deltas: 100% (25227/25227), done.
Checking connectivity... done.
Submodule path 'third_party/imgui': checked out 'c23a19c26fa9cc778f755e76799f0cafdcb5a13b'
Cloning into 'third_party/ktx'...
remote: Enumerating objects: 661, done.
remote: Counting objects: 100% (661/661), done.
remote: Compressing objects: 100% (392/392), done.
remote: Total 17837 (delta 288), reused 485 (delta 210), pack-reused 17176
Receiving objects: 100% (17837/17837), 85.32 MiB | 2.87 MiB/s, done.
Resolving deltas: 100% (10147/10147), done.
Checking connectivity... done.
Submodule path 'third_party/ktx': checked out '726d14d02c95bb21ec9e43807751b491d295dd3c'
Cloning into 'third_party/spdlog'...
remote: Enumerating objects: 115, done.
remote: Counting objects: 100% (115/115), done.
remote: Compressing objects: 100% (87/87), done.
remote: Total 20287 (delta 55), reused 48 (delta 18), pack-reused 20172
Receiving objects: 100% (20287/20287), 39.21 MiB | 2.74 MiB/s, done.
Resolving deltas: 100% (13523/13523), done.
Checking connectivity... done.
Submodule path 'third_party/spdlog': checked out '7bf8f148795d2571b4ae4aa9c6d2a8111fbb7077'
Cloning into 'third_party/spirv-cross'...
remote: Enumerating objects: 54, done.
remote: Counting objects: 100% (54/54), done.
remote: Compressing objects: 100% (41/41), done.
remote: Total 23911 (delta 17), reused 32 (delta 13), pack-reused 23857 eceiving objects: 100% (23911/23911), 9.74 MiB | 1011.00 KiB/s
Receiving objects: 100% (23911/23911), 10.54 MiB | 1.02 MiB/s, done.
Resolving deltas: 100% (16536/16536), done.
Checking connectivity... done.
Submodule path 'third_party/spirv-cross': checked out '84f56d0b43e5a6874de45e11be2bff9dc336fd7e'
Cloning into 'third_party/stb'...
remote: Enumerating objects: 6999, done.
Receiving objects: 100% (6999/6999), 4.65 MiB | 1.48 MiB/s, done.Receiving objects: 100% (6999/6999), 4.53 MiB | 1.48 MiB/s

Resolving deltas: 100% (4664/4664), done.
Checking connectivity... done.
Submodule path 'third_party/stb': checked out '2c2908f50515dcd939f24be261c3ccbcd277bb49'
Cloning into 'third_party/tinygltf'...
remote: Enumerating objects: 18, done.
remote: Counting objects: 100% (18/18), done.
remote: Compressing objects: 100% (13/13), done.
remote: Total 4199 (delta 6), reused 13 (delta 5), pack-reused 4181
Receiving objects: 100% (4199/4199), 16.60 MiB | 2.10 MiB/s, done.
Resolving deltas: 100% (2304/2304), done.
Checking connectivity... done.
Submodule path 'third_party/tinygltf': checked out 'c0d0251e2c7f2273a894aa1b125af9313a88eae4'
Cloning into 'third_party/vma'...
remote: Enumerating objects: 125, done.
remote: Counting objects: 100% (125/125), done.
remote: Compressing objects: 100% (83/83), done.
Receiving objects: 100% (5332/5332), 19.36 MiB | 2.87 MiB/s, done.5207

Resolving deltas: 100% (4078/4078), done.
Checking connectivity... done.
Submodule path 'third_party/vma': checked out '34045555a65f40801ca29e6fc04e9e31a7ea3124'
Cloning into 'third_party/volk'...
remote: Enumerating objects: 80, done.
remote: Counting objects: 100% (80/80), done.
remote: Compressing objects: 100% (61/61), done.
Receiving objects:  99% (484/488)   d 34 (delta 16), pack-reused 408
Receiving objects: 100% (488/488), 187.60 KiB | 0 bytes/s, done.
Resolving deltas: 100% (279/279), done.
Checking connectivity... done.
Submodule path 'third_party/volk': checked out '5e23ac9b980aa906f2de187419d35e48278a9dd8'
Cloning into 'third_party/vulkan'...
remote: Enumerating objects: 1362, done.
Receiving objects:  96% (1308/1362), 5.86 MiB | 879.00 KiB/s   362 eceiving objects:  94% (1281/1362), 5.86 MiB | 879.00 KiB/s
Receiving objects: 100% (1362/1362), 6.15 MiB | 907.00 KiB/s, done.
Resolving deltas: 100% (750/750), done.
Checking connectivity... done.
Submodule path 'third_party/vulkan': checked out '881bbb347a08d1b5aa77f61a52a30b506de9f2bf'
Unable to checkout 'e42b9697fa7708f2cca01a82369b31a1ec8a70b4' in submodule path 'assets'
Unable to checkout '6d4094b122476ddc404fcc061b53241af5a6a80b' in submodule path 'third_party/astc'

The document for the render_passes sample contains this description:

Below is a screenshot showing a scene rendered using LOAD_OP_LOAD. We can estimate the bandwidth cost of loading/storing an uncompressed attachment as width * height * bpp/8 * FPS [MiB/s]. Considering we are using triple buffering, we calculate an estimate of 2220 * 1080 * (32/8) * ~60 = ~575 MiB/s, and multiplying it by 3 we obtain a value close to the External Read Bytes shown in the graph.

I'm just not sure how triple buffering can affect the bandwidth. The claim is that one second's worth of frames at 60fps is 575MiB, which seems right given the frame size. This then gets multiplied by 3 to account for triple-buffering. To the best of my knowledge, triple-buffering won't add any bandwidth, it just cycles through 3 different buffers every 3 frames, not every frame, so the overall bandwidth would be unchanged.

I think it's far more likely that the extra read bandwidth showing in the graphs is from other GPU reads like texture fetches for example.

A previous refactoring moved several functions to the vk_common module, but their original definitions in render_subpasses.cpp didn't all get cleaned up.

As documented in https://github.com/KhronosGroup/Vulkan-Samples/blob/master/docs/build.md#3d-models, the 3D models assets are uploaded by Gradle at compilation time. This means that running a demo from an APK installed on a device that was not plugged at compilation time leads to errors such as:

Failed to open file: /storage/emulated/0/Android/data/com.khronos.vulkan_samples/files/shaders/triangle.vert

To ease the usage of such demos on test labs, it would be much easier to have a standalone APK which embeds the assets. Is there any non-technical reason to not do this?

All samples show the GUI incorrectly on a system with RX 5700 XT, windows, 4K and 200% scaling.
Setting the system to 100% scaling fixes it.

The samples works fine on my Samsung S8 (Android 9) and Google Pixel (Android 9). However, they fail on Samsung S10e (Android 10) and on Google Pixel (Android 10).

I followed the instructions for building for Android with Gradle here. The samples fail to load on my Android 10 devices because vkCreateInstance() returns VK_ERROR_LAYER_NOT_PRESENT:

com.khronos.vulkan_samples E/VulkanSamples: [error] [_triangle/hello_triangle.cpp:234] Detected Vulkan error: VK_ERROR_LAYER_NOT_PRESENT

This is true even if you comment out the part of hello_triangle.cpp that defines the layers to be loaded. I stepped into the Android Studio debugger and inspected instance_info, it seemed to have no layers configured, and yet I still got VK_ERROR_LAYER_NOT_PRESENT.

In the logcat output, you can see that validation layers are still being found and loaded from the app's lib/arm64 directory:

com.khronos.vulkan_samples D/vulkan: added global layer 'VK_LAYER_LUNARG_parameter_validation' from library '/data/app/com.khronos.vulkan_samples-Vl8zpsGcknvYybfWM9fDnA==/lib/arm64/libVkLayer_parameter_validation.so'

(This is just one example, there are other libraries that are also loaded.) I don't know where this library is coming from.

If subpasses is empty, the code should create single subpass with a ColorAttachment by default.
It seems that the the colorAttachmentCount member of this subpass in VkSubpassDescription is not set.

The api sample for generating mip-maps at run-time comes with a tutorial that hasn't been linked from the repo's readme.md.

It should be added to the tutorial list, and with it the list should maybe restructured, so api samples can be grouped together.

See this discussion.

• CMake generate Visual Studio x64 project
• open generated project and build vulkan_samples target

C:\Users\zhuwa.ADS\Desktop\KhronosGroup-Vulkan-Samples\third_party\vma\src\vk_mem_alloc.h(4364,9): error C2280: 'VmaPoolAllocator<VmaAllocation_T>::Item::Item(void)': attempting to reference a deleted function (compiling source file C:\Users\zhuwa.ADS\Desktop\KhronosGroup-Vulkan-Samples\framework\core\device.cpp)

Host: Linux x64 (debian-testing based)
Gradle version: 5.1.1
CMake: 3.13.4

The command ./gradlew assembleDebug fails with:

[...]
[12/12] Linking CXX executable third_party/spirv-cross/bin/Debug/armeabi-v7a/spirv-cross
Build instancing armeabi-v7a
ninja: no work to do.
Build push_descriptors armeabi-v7a
ninja: no work to do.
Build afbc armeabi-v7a
ninja: no work to do.
Build terrain_tessellation armeabi-v7a
ninja: no work to do.
Build hello_triangle armeabi-v7a
ninja: no work to do.
Build hdr armeabi-v7a
ninja: no work to do.

> Task :externalNativeBuildDebug FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':externalNativeBuildDebug'.
> Expected output file at /home/hevrard/work/Vulkan-Samples/build/android_gradle/build-native/cmake/debug/armeabi-v7a/samples/api/hdr/hdr for target hdr but there was none

Getting rid of "armeabi-v7a" in build.gradle's ndk abiFilters leads to a similar error :

Execution failed for task ':externalNativeBuildDebug'.
> Expected output file at /home/hevrard/work/Vulkan-Samples/build/android_gradle/build-native/cmake/debug/arm64-v8a/samples/performance/command_buffer_usage/command_buffer_usage for target command_buffer_usage but there was none

Wondering if this will become a common problem when infrastructure changes are made, and if a check is needed to ensure the cache matches the current version of the APK?

Indeed. I agree that some version checking is probably needed.

Originally posted by @gary-sweet in #24 (comment)

I follow the official doc

Add file named vk_layer_settings.txt in root directory

Change triangle.vert

#extension GL_EXT_debug_printf : enable

debugPrintfEXT("Hit");

But when I run ./cmake-build-debug/app/bin/Debug/x86_64/vulkan_samples hello_triangle, nothing stdout.

The SemaphorePool class declares an rvalue reference constructor like this:

SemaphorePool(SemaphorePool &&other) = default;

However, the class uses RAII sematics, and will destroy all the contained semaphores when it is destroyed. If anyone ever actually uses the SemaphorePool(SemaphorePool &&other) while the pool is non-empty, then both the new instance and the other instance will contain the same set of semaphores. This would lead to semaphores being used after their destroyed or semaphores being double destroyed.

SemaphorePool(SemaphorePool &&other) should either be marked delete or it should be explicitly written to wipe the other.semaphores vector.

Then enabling validation on the hello_triangle example it tries to use the following layers

VK_LAYER_GOOGLE_threading
VK_LAYER_LUNARG_parameter_validation
VK_LAYER_LUNARG_object_tracker
VK_LAYER_LUNARG_core_validation
VK_LAYER_GOOGLE_unique_objects

But these layers do not exist on my up to date system. See this report on vulkan.gpuinfo.org.

The code should attempt to first use VK_LAYER_KHRONOS_validation, then fall back to VK_LAYER_LUNARG_standard_validation, and then fall back to the above list, and if that still doesn't validate against the existing layers, it should use no validation layers (possibly emitting a warning).

Needed for #97 to work.

The primary glad repository contains not an instance of glad, but code for a glad generator. In theory I could have integrated the main repository and used CMake to execute the generator to produce the appropriate GL loader, but that would have made the build process significantly more fragile and added a dependency on Python to execute the generator.

Instead I opted to create a fork of glad, and then create branches with the output of the generator needed for the two specific API's, OpenGL and OpenGL ES.

There are a few possible paths...

• Leave it as it is
• Leave the glad dependencies as submodules, but switch to a fork of Glad owned by KhronosGroup
• Switch to embedding the glad dependencies as files under third-party instead of submodules
  • Unfortunately this would require fixing the CI servers to ignore these files in the linting and copyright headers checks
• Switch to the main glad repository and modify the CMake process to call the generator appropriately and create these files at configure or build time.

Originally posted by @jherico in #97 (comment)

Sascha said you were accepting feature requests and so I was wondering if there were any plans for a glTF skeletal animation project performance project showing best practices for implementing them?

I have followed the instructions for the Window build. Have Python in PATH and have the updated LLVM (9.0.0) and am using the Visual Studio Developer Powershell to build. This is what I see on the console. I am not sure what I am doing wrong.
PS C:\VulkanSamples> cmake .\CMakeLists.txt
-- Building for: Visual Studio 16 2019
-- Selecting Windows SDK version 10.0.18362.0 to target Windows 10.0.17763.
-- The C compiler identification is MSVC 19.24.28319.0
-- The CXX compiler identification is MSVC 19.24.28319.0
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.24.28314/bin/Hostx64/x64/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.24.28314/bin/Hostx64/x64/cl.exe - works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.24.28314/bin/Hostx64/x64/cl.exe
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.24.28314/bin/Hostx64/x64/cl.exe - works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Using Debug VC++ CRT: MDd
-- Using Release VC++ CRT: MD
-- Using MinSizeRel VC++ CRT: MD
-- Using RelWithDebInfo VC++ CRT: MD
CMake Error at C:/Program Files/CMake/share/cmake-3.17/Modules/FindPythonInterp.cmake:126 (execute_process):
execute_process attempted to output into a file: into a source directory.
Call Stack (most recent call first):
third_party/spirv-cross/CMakeLists.txt:133 (find_package)

-- Configuring incomplete, errors occurred!
See also "C:/VulkanSamples/CMakeFiles/CMakeOutput.log".

The MSAA example enables VK_KHR_multiview despite seemingly never using it.

README has a dead link at the moment (Arm is planning to release this as a blog series)

A code snippet in the surface rotation tutorial suggests using APP_CMD_CONTENT_RECT_CHANGED to handle orientation changes.
However, this event is never generated by the current version of NDK without some extra work which is done in the framework (using onContentRectChanged).
This is not mentioned in the tutorial, so the advice is a little bit misleading (see this issue).
Probably it is good to add a little Note section with an explanation.
This NDK issue is already reported and it's very likely that it will be fixed in the version 22, so it would be good to keep in mind (and probably update the code and the tutorial).

name: Issue template
about: Create a report to help us improve
title: ''
labels: ''
assignees: ''

Describe the issue
A clear and concise description of what the problem is.

To Reproduce
Steps to reproduce the behavior:

1. Run '...'
2. Click on '....'
3. View line '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop

• OS: [e.g. Windows 10]
• GPU: [e.g. NVidia GeForce GTX 1080]

Smartphone

• Device: [e.g. Samsung S10]
• OS: [e.g. Android 8.0]
• GPU: [e.g. Mali G72]
• Driver version [Report GL_VENDOR and GL_VERSION from chrome://gpu/ on the device]

Additional context
Add any other context about the problem here.

Hello!

I recently started developing with Vulkan on Arch Linux.
Everything went pretty smooth on Arch, but recently I decided to give NixOS a spin.

I am able to build the samples without any problems, but when I try to run an example it fails with [error] [build/linux/app/main.cpp:75] Failed to initialize volk..
I already opened an issue on the NixOS github page, but haven't gotten a reply yet.

vkcube Does run without a problem, and the output of vulkaninfo seems to be correct.

I also noticed by running the program through strace that I get a lot of the same errors:

uname({sysname="Linux", nodename="nixos", ...}) = 0
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{iov_base="\22\0\10\0\3\0 \1\375\0\0\0\4\0\0\0 \0\1\0\2\0\0\0\373\0\0\0\n\1\0\0"..., iov_len=464}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 464
poll([{fd=3, events=POLLIN}], 1, -1)    = 1 ([{fd=3, revents=POLLIN}])
recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\34\0C\0\3\0 \1\375\0\0\0y\300\270\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 288
poll([{fd=3, events=POLLIN}], 1, -1)    = 1 ([{fd=3, revents=POLLIN}])
recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\34\0L\0\3\0 \1$\0\0\0y\300\270\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 64
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{iov_base="\22\0\7\0\3\0 \1\374\0\0\0\37\0\0\0\10\0\1\0\1\0\0\0C\0\0\0\22\0\n\0"..., iov_len=108}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 108
recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\34\0N\0\3\0 \1\374\0\0\0z\300\270\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\34\0O\0\3\0 \1\10\1\0\0z\300\270\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 64
recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)

and running it in GDB:

(gdb) file ./build/linux/app/bin/Release/x86_64/vulkan_samples 
Reading symbols from ./build/linux/app/bin/Release/x86_64/vulkan_samples...
(gdb) run hello_triangle
Starting program: /home/bryan/Downloads/Vulkan-Samples/build/linux/app/bin/Release/x86_64/vulkan_samples hello_triangle
warning: File "/nix/store/jy89v2q2zv074mvw91jgqcvkmk7yqx69-gcc-9.3.0-lib/lib/libstdc++.so.6.0.28-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load:/nix/store/ihr026g1ijgmjiqn4xn39bk5rr1w379j-gcc-9.3.0-lib".
To enable execution of this file add
	add-auto-load-safe-path /nix/store/jy89v2q2zv074mvw91jgqcvkmk7yqx69-gcc-9.3.0-lib/lib/libstdc++.so.6.0.28-gdb.py
line to your configuration file "/home/bryan/.gdbinit".
To completely disable this security protection add
	set auto-load safe-path /
line to your configuration file "/home/bryan/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
	info "(gdb)Auto-loading safe path"much hassle
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/nix/store/v9j0bsl1bv7ngijmvnvnj9h3qrb1p3mf-glibc-2.30/lib/libthread_db.so.1".
[info] Logger initialized
[info] Window created
[info] Initializing vulkan instance.
[error] [build/linux/app/main.cpp:75] Failed to initialize volk.
[info] Closing App (Runtime: 0.0)

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) backtrace 
#0  0x0000000000000000 in ?? ()
#1  0x00000000004a261b in HelloTriangle::teardown(HelloTriangle::Context&) ()
#2  0x00000000004a2901 in HelloTriangle::~HelloTriangle() ()
#3  0x00000000004a2a19 in HelloTriangle::~HelloTriangle() ()
#4  0x0000000000507f2a in vkb::Platform::terminate(vkb::ExitCode) ()
#5  0x000000000040f159 in main.cold ()
#6  0x00007ffff797fd8b in __libc_start_main () from /nix/store/an6bdv4phxsz14q2sk57iscl2dc7bnj1-glibc-2.30/lib/libc.so.6
#7  0x000000000047f32a in _start () at ../sysdeps/x86_64/start.S:120

Looking at the volk github it says that it will throw this error when it is unable to find the vulkan loader. I do however have a Vulkan loader installed.
But I honestly have no idea how to solve this issue.

I am extremely sorry if this is not the right place to post this kind of issue.

Seem like the framework ignores that set order is important during the vkCreatePipelineLayout call so that the sets are in the correct order. It adds the sets in the semi random order that exists in descriptor_set_layouts. A fix for this can be to change

std::transform(descriptor_set_layouts.begin(), descriptor_set_layouts.end(), descriptor_set_layout_handles.begin(),
	               [](auto &descriptor_set_layout_it) { return descriptor_set_layout_it.second->get_handle(); });

to something like

	for (int setNr=0; setNr<4; setNr++)
	{
		if (descriptor_set_layouts[setNr] != nullptr)
			descriptor_set_layout_handles[setNr] = descriptor_set_layouts[setNr]->get_handle();
	}

in pipeline_layout.cpp
The change above assumes you use all sets in sequence. If there is holes in the sets like you dont use set 0 the framework should inject a empty set layout.

I'm trying to add a new example that depends on GLAD, but it's failing the CI check because of the copyright-headers, clang-tidy and clang-format checks, which should not be applied to content in the third-party folder.

Render Subpasses sample shows flickering and fails to render using renderpasses on some platforms (Adreno 540).

Seems to get fixed after forcing a swapchain re-creation.
Video: render_passes_bug.zip

In ConservativeRasterization::prepare_offscreen(), the framebuffer_depth_format VK_FORMAT_D32_SFLOAT was chosen, but image view creation includes VK_IMAGE_ASPECT_STENCIL_BIT. This gives validation error as title.

The framework needs to be expanded so additional features can be enabled via VkPhysicalDeviceFeatures2. Right now it's only possible to enable the features from VkPhysicalDeviceFeatures2, with no way to enable those that are e.g. required by some extensions.

In my samples I just added a void* pdeviceCreatepNextChain to the base and device classes, and if this is not null the device feature setup is changed to make it possible to pass arbitrary device features to be enabled:

	VkDeviceCreateInfo deviceCreateInfo = {};
         ...
	deviceCreateInfo.pEnabledFeatures = &enabledFeatures;
		
	// If a pNext(Chain) has been passed, we need to add it to the device creation info
	if (pNextChain) {
		VkPhysicalDeviceFeatures2 physicalDeviceFeatures2{};
		physicalDeviceFeatures2.sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FEATURES_2;
		physicalDeviceFeatures2.features = enabledFeatures;
		physicalDeviceFeatures2.pNext = pNextChain;
		deviceCreateInfo.pEnabledFeatures = nullptr;
		deviceCreateInfo.pNext = &physicalDeviceFeatures2;
	}

The code in vkb::Instance::Instance constructs a VkInstance and then (when either VKB_DEBUG or VKB_VALIDATION_LAYERS are defined) populates a VkDebugReportCallbackCreateInfoEXT and creates a debug report callback.

However, the VK_EXT_debug_report extension was specifically designed to ensure that validation could be applied even to instance creation.

if VKB_DEBUG or VKB_VALIDATION_LAYERS are defined, then the VkDebugReportCallbackCreateInfoEXT declaration should be before instance creation code, and the VkDebugReportCallbackCreateInfoEXT structure should be set as the pNext of VkInstanceCreateInfo

Some GPUs, like Broadcom's for example, support Vulkan's performance counter extension, but have no support in hwcpipe which is currently used for the graphs in the UI.

It would be nice if the samples could use the Vulkan extension, where available, to gather the stats for the graph.

The compute_nbody sample seems to be missing a queue family ownership transfer of compute.storage_buffer on platforms where a compute-only queue family is available.

Note how compute.storage_buffer is used as a storage buffer in compute.queue and as as vertex buffer in queue, and consider the following:

• If the platform has a compute only queue family available, it will be preferred.
  • The compute dispatches use the compute.queue queue:

    Vulkan-Samples/samples/api/compute_nbody/compute_nbody.cpp

    Line 629 in 55abaae

    VK_CHECK(vkQueueSubmit(compute.queue, 1, &compute_submit_info, VK_NULL_HANDLE));

  • compute.queue is set here:

    Vulkan-Samples/samples/api/compute_nbody/compute_nbody.cpp

    Line 437 in 55abaae

    vkGetDeviceQueue(get_device().get_handle(), get_device().get_queue_family_index(VK_QUEUE_COMPUTE_BIT), 0, &compute.queue);

  • The logic in Device::get_queue_family_index(VkQueueFlagBits queue_flag) will pick a queue family with compute and no graphics if available;

    Vulkan-Samples/framework/core/device.cpp

    Line 349 in 55abaae

    if (queue_flag & VK_QUEUE_COMPUTE_BIT)

  • On my Radeon RX 590 queue family index 1 is picked here
• The default queue's queue family is the first one available which supports presentation:
  • It's created here

    Vulkan-Samples/framework/api_vulkan_sample.cpp

    Line 57 in 55abaae

    queue = device->get_queue_by_present(0).get_handle();

  • This calls Device::get_queue_by_present which picks the first queue family which can present;

    Vulkan-Samples/framework/core/device.cpp

    Line 328 in 55abaae

    const Queue &Device::get_queue_by_present(uint32_t queue_index)

  • On my Radeon RX 590 queue family index 0 is picked here
• compute.storage_buffer is created with VK_SHARING_MODE_EXCLUSIVE; see

  Vulkan-Samples/framework/core/buffer.cpp

  Line 32 in 55abaae

  VkBufferCreateInfo buffer_info{VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO};

In other words, compute.queue and queue can be from different queue families (and is on my system), which means compute.storage_buffer can not be shared between the two queues without having the queue family ownership transferred:
Resources created with a VkSharingMode of VK_SHARING_MODE_EXCLUSIVE must have their ownership explicitly transferred from one queue family to another in order to access their content in a well defined manner on a queue in a different queue family

The problem is the sample is missing pipeline-barriers to perform this ownership transfer currently. As such, the sample is only correct on systems where the code happens to pick the queues so they are from the same queue family.

The command cmake -G "Unix Makefiles" -H. -Bbuild/android -DCMAKE_TOOLCHAIN_FILE=bldsys/toolchain/android_gradle.cmake fails with:

    "/home/user/work/android-sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/bin/clang"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: /home/user/work/Vulkan-Samples/build/android/CMakeFiles/CMakeTmp
    
    Run Build Command:"/usr/bin/make" "cmTC_cb3df/fast"
    /usr/bin/make -f CMakeFiles/cmTC_cb3df.dir/build.make CMakeFiles/cmTC_cb3df.dir/build
    make[1]: Entering directory '/home/user/work/Vulkan-Samples/build/android/CMakeFiles/CMakeTmp'
    Building C object CMakeFiles/cmTC_cb3df.dir/testCCompiler.c.o
    /home/user/work/android-sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/bin/clang --target=aarch64-none-linux-android --gcc-toolchain=/home/user/work/android-sdk/ndk-bundle/toolchains//prebuilt/linux-x86_64 --sysroot=/home/user/work/android-sdk/ndk-bundle/sysroot  -isystem /home/user/work/android-sdk/ndk-bundle/sysroot/usr/include -isystem /home/user/work/android-sdk/ndk-bundle/sysroot/usr/include/aarch64-linux-android  -funwind-tables -no-canonical-prefixes -D__ANDROID_API__=24 -fexceptions  -g -fPIE   -o CMakeFiles/cmTC_cb3df.dir/testCCompiler.c.o   -c /home/user/work/Vulkan-Samples/build/android/CMakeFiles/CMakeTmp/testCCompiler.c
    Linking C executable cmTC_cb3df
    /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_cb3df.dir/link.txt --verbose=1
    /home/user/work/android-sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/bin/clang --target=aarch64-none-linux-android --gcc-toolchain=/home/user/work/android-sdk/ndk-bundle/toolchains//prebuilt/linux-x86_64 --sysroot=/home/user/work/android-sdk/ndk-bundle/platforms/android-24/arch-arm64 -funwind-tables -no-canonical-prefixes -D__ANDROID_API__=24 -fexceptions  -g  -fPIE -pie -Wl,--gc-sections  CMakeFiles/cmTC_cb3df.dir/testCCompiler.c.o  -o cmTC_cb3df 
    /usr/bin/ld: unrecognised emulation mode: aarch64linux
    Supported emulations: elf_x86_64 elf32_x86_64 elf_i386 elf_iamcu elf_l1om elf_k1om i386pep i386pe
    clang: error: linker command failed with exit code 1 (use -v to see invocation)
    make[1]: *** [CMakeFiles/cmTC_cb3df.dir/build.make:87: cmTC_cb3df] Error 1
    make[1]: Leaving directory '/home/user/work/Vulkan-Samples/build/android/CMakeFiles/CMakeTmp'
    make: *** [Makefile:121: cmTC_cb3df/fast] Error 2

NDK version is r20.

The typo:
In section Double buffering or triple buffering?, the last reference image link should be called Triple buffering at <60 FPS, I suppose? It shows Double buffering at <60 FPS when the image is still loading.

Some questions:
1.For triple-buffering, we need an additional swapchain image allocated, so we will require more memory for this image and maybe some static buffer, right?

2.If some FPS control exists in the application, so we can choose to lower it to save battery. Does that affect how we choose between VK_PRESENT_MODE_FIFO_KHR and VK_PRESENT_MODE_MAILBOX_KHR?

3.Can we safely go for double buffering if we cap FPS to 30, if we guarantee GPU can finish the rendering well within 33ms, to squash down memory usage?

Known Issues

• 'Command Buffer Usage' sample has a crash on Adreno 530 and 540 based devices using Android 8.0 or earlier (resolved in Android 9.0)

The Hello Triangle sample logs the error Failed to present swapchain image. every frame when the device (S10 Mali G76) is in landscape orientation.

This is a test issue to test the funcitonality of this addition

https://github.com/KhronosGroup/Vulkan-Samples/blob/master/samples/performance/afbc/afbc_tutorial.md#further-reading

The logic in gui.cpp takes into account the physical size of the monitor in order to scale content (via dpi_factor) however, it does not handle a disparity between the window coordinate system used for input events and the framebuffer surface pixel coordinate system.

On retina mac displays input events come in at half the resolution of the actual screen. This can be be seen in a disparity between the values returned by glfwGetWindowSize and glfwGetFramebufferSize. In GLFW 3.3 and up this is available from the convenience function glfwGetWindowContentScale.

See the behavior here...

I run vulkaninfo and it displays the following in the console. What does it mean. This is mistake? does the driver not work?

===========
VULKAN INFO
===========

Vulkan Instance Version: 1.1.70

ERROR: [Loader Message] Code 0 : /usr/lib/i386-linux-gnu/libvulkan_intel.so: wrong ELF class: ELFCLASS32
ERROR: [Loader Message] Code 0 : /usr/lib/i386-linux-gnu/libvulkan_radeon.so: wrong ELF class: ELFCLASS32
WARNING: radv is not a conformant vulkan implementation, testing use only.

Fix copyright script to check for all contributors copyright year. For example in the following case the script is only checking for the first time.

/* Copyright (c) 2018-2020, Arm Limited and Contributors
 * Copyright (c) 2019, Sascha Willems

The new debug utilities example adds a few wrapper functions for setting object labels and tags. These could be added to the framework, so that all samples could make use of them.

See this discussion on the PR.

Would it be possible to get a multi-gpu/m-gpu/linked-gpu example for Vulkan?

Direct3D has one: https://github.com/microsoft/DirectX-Graphics-Samples/tree/master/Samples/Desktop/D3D12LinkedGpus

Would be a good addition for people new to the API.

Validation errors are no longer reported, even when running with VKB_VALIDATION_LAYERS enabled.

#60 modified the code to add VkDebugReportCallbackCreateInfoEXT structure to the pNext for the instance create info, adding support for reporting validation errors during instance creation. However, it also removed the calls to vkCreateDebugReportCallbackEXT, presumably in the belief that the instance creation change was a replacement for this logic. It is not. While the structure chaining during instance creation gives the driver enough to report validation errors in creation, it provides no way to populate VkDebugReportCallbackEXT debug_report_callback for later manipulation of the reporting.

The /MP option enables Visual Studio to build in parallel. This drastically reduces build time on systems with sufficient cores. However, this option is only turned on inside a if(${VKB_WARNINGS_AS_ERRORS}) conditional block. If wanrings as errors are turned off, then parallel build is disabled.

I've built the code, and it works fine.

However, there is not much tutorial about how to study those samples code. For example, should I start with Hello_Triangle? What is the key API I should be attention to while I reading the code? And which chapter should I study next?

The Tutorial Chapter currently in the README is more about background knowledge of Vulkan. Which is great!! Just hope you could add the other material which would let us know how to start with these samples and explain more about the Vulkan API themselves through the samples.

Thank you.

The gltf loader has a block beginning here and ending here that begins and ends a command buffer, and then submits it and waits for the work to complete. However, between the begin and end the command buffer isn't reference at all, meaning the submission and wait do nothing.

The implementation appears to default the output to seconds, but the comment refers to milliseconds.

The predominate usage for a swapchain image is to attach it to a framebuffer and render directly to it, or the render to something else and blit to the swapchain image. This corresponds to a usage of VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT and VK_IMAGE_USAGE_TRANSFER_DST_BIT.

However, the default flags in the swapchain constructors here and here are VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT (correct) and VK_IMAGE_USAGE_TRANSFER_SRC_BIT (incorrect).