I followed the Win32 build instructions in vktrace/ReadMe.md, changing the target for cmake to
"Visual Studio 14 2015 Win64". I open vktrace/_out64/vktrace_project.sln in Visual Studio 2015 and select Build on the ALL_BUILD projects. It fails when it is not able to find vk-generate.py. A partial build log is posted here:

1>------ Build started: Project: vktrace_common, Configuration: Debug x64 ------
2>------ Build started: Project: generate_vktrace_layer_helpers, Configuration: Debug x64 ------
3>------ Build started: Project: vktrace_layer-json, Configuration: Debug x64 ------
2>  Building Custom Rule C:/VulkanSDK/VulkanTools/vktrace/src/vktrace_layer/CMakeLists.txt
3>          1 file(s) copied.
2>  CMake does not need to re-run because C:\VulkanSDK\VulkanTools\vktrace\_out64\src\vktrace_layer\CMakeFiles\generate.stamp is up-to-date.
2>  Generating vk_dispatch_table_helper.h
2>  '..\..\..\vk-generate.py' is not recognized as an internal or external command, 
2>  operable program or batch file.
2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5): error MSB6006: "cmd.exe" exited with code 9009.

I'm on Ubuntu 15.10 x86_64 with nvidia driver 355.00.29.

With the latest LunarGLASS, building the ICD fails on this assertion:

// If this fails during compilation, it means LunarGlass has added new sampler types
// We must react to.  Also, see comment above ersatz_static_assert.
ersatz_static_assert<NumSamplerTypes     == gla::EMsCount &&
                     NumSamplerBaseTypes == gla::EMsbCount &&
                     NumSamplerDims      == gla::EMsdCount> SamplerTypeMismatchWithLunarGlass;

I'm on Ubuntu 15.10 x86_64, nvidia driver 355.00.29 and Vulkan SDK 1.0.5.

In my experiments with Vulkan, I came to experience a crash when using VK_LAYER_LUNARG_param_checker, whether I enable the layer from code, or by setting the respective environment variables. The crash is in validateDeviceCreateInfo from libVkLayer_param_checker.so. Here is a sample program (main.c):

#include <stdlib.h>
#include <stdio.h>
#include <vulkan/vulkan.h>

int main(int argc, char **argv)
{
    VkResult res;

    /* create instance */
    VkApplicationInfo app_info = {
        .sType = VK_STRUCTURE_TYPE_APPLICATION_INFO,
        .pApplicationName = "Vulkan Layer Bug",
        .pEngineName = "Vulkan Layer Bug",
        .apiVersion = VK_MAKE_VERSION(1, 0, 3),
    };
    VkInstanceCreateInfo instance_info = {
        .sType = VK_STRUCTURE_TYPE_INSTANCE_CREATE_INFO,
        .pApplicationInfo = &app_info,
    };
    VkInstance vk;

    res = vkCreateInstance(&instance_info, NULL, &vk);
    if (res)
        return EXIT_FAILURE;

    /* get physical device */
    VkPhysicalDevice phy_dev;
    VkPhysicalDeviceFeatures dev_features;
    uint32_t phy_dev_count = 1;

    res = vkEnumeratePhysicalDevices(vk, &phy_dev_count, &phy_dev);
    if (res < 0 || phy_dev_count < 1)
        return EXIT_FAILURE;

    vkGetPhysicalDeviceFeatures(phy_dev, &dev_features);

    /* create device */
    VkDeviceQueueCreateInfo queue_info = {
        .sType = VK_STRUCTURE_TYPE_DEVICE_QUEUE_CREATE_INFO,
        .queueFamilyIndex = 0,
        .queueCount = 1,
    };
    VkDeviceCreateInfo dev_info = {
        .sType = VK_STRUCTURE_TYPE_DEVICE_CREATE_INFO,
        .queueCreateInfoCount = 1,
        .pQueueCreateInfos = &queue_info,
        .pEnabledFeatures = &dev_features,
    };
    VkDevice dev;

    res = vkCreateDevice(phy_dev, &dev_info, NULL, &dev);
    if (res)
        return EXIT_FAILURE;

    fprintf(stderr, "Initialization successful\n");

    /* cleanup */
    vkDeviceWaitIdle(dev);
    vkDestroyDevice(dev, NULL);
    vkDestroyInstance(vk, NULL);

    fprintf(stderr, "Cleanup successful\n");

    return 0;
}

You can build this with:

$ gcc -o layerbug main.c -lvulkan

And try with:

$ ./layerbug

which works fine, and:

$ export VK_INSTANCE_LAYERS=VK_LAYER_LUNARG_param_checker
$ export VK_DEVICE_LAYERS=VK_LAYER_LUNARG_param_checker
$ ./layerbug

which results in segmentation fault. I can verify that enabling the layer from code has the same behavior.

gdb stack trace:

#0  0x00007ffff4159f31 in validateDeviceCreateInfo(VkPhysicalDevice_T*, VkDeviceCreateInfo const*, std::vector<VkQueueFamilyProperties, std::allocator<VkQueueFamilyProperties> >) ()
   from /usr/lib/x86_64-linux-gnu/libVkLayer_param_checker.so
#1  0x00007ffff415ab8d in vkCreateDevice () from /usr/lib/x86_64-linux-gnu/libVkLayer_param_checker.so
#2  0x00007ffff7bbebee in ?? () from /usr/lib/x86_64-linux-gnu/libvulkan.so.1
#3  0x00007ffff7bc402a in vkCreateDevice () from /usr/lib/x86_64-linux-gnu/libvulkan.so.1
#4  0x0000000000400b84 in main ()

Registers:

rax            0x0  0
rbx            0x0  0
rcx            0x7fffffffdc40   140737488346176
rdx            0x0  0
rsi            0xb  11
rdi            0x7fffffffd860   140737488345184
rbp            0x7fffffffdc40   0x7fffffffdc40
rsp            0x7fffffffd800   0x7fffffffd800
r8             0x0  0
r9             0x7ffff7baac68   140737349594216
r10            0x0  0
r11            0x7ffff797cfb0   140737347309488
r12            0x0  0
r13            0x0  0
r14            0x7fffffffdab0   140737488345776
r15            0x640b10 6556432
rip            0x7ffff4159f31   0x7ffff4159f31 <validateDeviceCreateInfo(VkPhysicalDevice_T*, VkDeviceCreateInfo const*, std::vector<VkQueueFamilyProperties, std::allocator<VkQueueFamilyProperties> >)+465>
eflags         0x10246  [ PF ZF IF RF ]
cs             0x33 51
ss             0x2b 43
ds             0x0  0
es             0x0  0
fs             0x0  0
gs             0x0  0

I'm trying to build this repo with debugging symbols to debug further. However, if there is any glaring errors in my code, please let me know. Otherwise, it would be interesting to know if you can reproduce this issue.

From backtrace of my (buggy) application:

(gdb) bt
#0  intel_dev_log (dev=dev@entry=0x625740, msg_flags=msg_flags@entry=8, src_object=src_object@entry=0x0, location=location@entry=0, msg_code=msg_code@entry=0, 
    format=format@entry=0x7ffff75283e0 "invalid presentable image format") at /usr/src/debug/vulkan-sdk-1.0.3.0/VulkanTools/icd/intel/dev.c:206
#1  0x00007ffff6ee02a8 in x11_swap_chain_create (sc_ret=0x7fffec1fdee8, info=0x7fffec1fde40, dev=0x625740)
    at /usr/src/debug/vulkan-sdk-1.0.3.0/VulkanTools/icd/intel/wsi_x11.c:887
#2  vkCreateSwapchainKHR (device=0x625740, pCreateInfo=0x7fffec1fde40, pAllocator=<optimized out>, pSwapchain=0x7fffec1fdee8)
    at /usr/src/debug/vulkan-sdk-1.0.3.0/VulkanTools/icd/intel/wsi_x11.c:1204
[...]
(gdb) list
201 {
202     va_list ap;
203 
204     va_start(ap, format);
205     intel_logv(dev, msg_flags,
206                (src_object->dbg ? src_object->dbg->type : 0),
207                (uint64_t) src_object,
208                location, msg_code,
209                format, ap);
210     va_end(ap);
(gdb) up
#1  0x00007ffff6ee02a8 in x11_swap_chain_create (sc_ret=0x7fffec1fdee8, info=0x7fffec1fde40, dev=0x625740)
    at /usr/src/debug/vulkan-sdk-1.0.3.0/VulkanTools/icd/intel/wsi_x11.c:887
887         intel_dev_log(dev, VK_DEBUG_REPORT_ERROR_BIT_EXT,
(gdb) list
882     struct intel_x11_swap_chain *sc;
883     int fd;
884 
885     /* TODOVV: Add test to validation layer */
886     if (!x11_is_format_presentable(dev, info->imageFormat)) {
887         intel_dev_log(dev, VK_DEBUG_REPORT_ERROR_BIT_EXT,
888                       VK_NULL_HANDLE, 0, 0, "invalid presentable image format");
889 //        return VK_ERROR_INVALID_VALUE;
890         return VK_ERROR_VALIDATION_FAILED_EXT;
891     }

intel_dev_log is called with src_object= VK_NULL_HANDLE, but then it is dereferenced with src_object->dbg.

Interesting series of bugs. This first part is not a VulkanTools bug:

$ cmake -H. -Bbuild -DCMAKE_BUILD_TYPE=Debug -DBUILD_WSI_XLIB_SUPPORT=On
$ grep XLIB build/CMakeCache.txt 
BUILD_WSI_XLIB_SUPPORT:BOOL=On
$ cd build && make

The error I am getting is an interaction between XLib and Qt5:

[ 93%] Building CXX object vktrace/src/vktrace_viewer/CMakeFiles/vktraceviewer.dir/main.cpp.o
In file included from /usr/include/X11/Xlib.h:44:0,
                 from VulkanTools/include/vulkan/vk_platform.h:113,
                 from VulkanTools/include/vulkan/vulkan.h:31,
                 from VulkanTools/include/vulkan/vk_icd.h:26,
                 from VulkanTools/vktrace/src/vktrace_common/vktrace_multiplatform.h:28,
                 from VulkanTools/vktrace/src/vktrace_common/vktrace_trace_packet_utils.h:24,
                 from VulkanTools/vktrace/src/vktrace_viewer/vktraceviewer.h:30,
                 from VulkanTools/vktrace/src/vktrace_viewer/main.cpp:24:
/usr/include/qt5/QtCore/qurl.h:139:9: error: expected identifier before numeric constant
         None = 0x0,
         ^
/usr/include/qt5/QtCore/qurl.h:139:9: error: expected ‘}’ before numeric constant
/usr/include/qt5/QtCore/qurl.h:139:9: error: expected unqualified-id before numeric constant

The Xlib.h header is maybe #included in the wrong place. I'm not sure.

Ok, so punt on that since I don't plan to use XLib anyway.

$ rm -rf build; cmake -H. -Bbuild -DCMAKE_BUILD_TYPE=Debug -DBUILD_WSI_XLIB_SUPPORT=Off
$ grep XLIB build/CMakeCache.txt 
BUILD_WSI_XLIB_SUPPORT:BOOL=Off
$ cd build && make

Now this is interesting:

[  3%] Building C object icd/nulldrv/CMakeFiles/VK_nulldrv.dir/nulldrv_gpa.c.o
VulkanTools/build/icd/nulldrv/nulldrv_gpa.c: In function ‘vk_icdGetInstanceProcAddr’:
VulkanTools/build/icd/nulldrv/nulldrv_gpa.c:333:37: error: ‘vkCreateXlibSurfaceKHR’ undeclared (first use in this function)
         return (PFN_vkVoidFunction) vkCreateXlibSurfaceKHR;
                                     ^
VulkanTools/build/icd/nulldrv/nulldrv_gpa.c:333:37: note: each undeclared identifier is reported only once for each function it appears in
VulkanTools/build/icd/nulldrv/nulldrv_gpa.c:335:37: error: ‘vkGetPhysicalDeviceXlibPresentationSupportKHR’ undeclared (first use in this function)
         return (PFN_vkVoidFunction) vkGetPhysicalDeviceXlibPresentationSupportKHR;
                                     ^
VulkanTools/build/icd/nulldrv/nulldrv_gpa.c: In function ‘vkGetDeviceProcAddr’:
VulkanTools/build/icd/nulldrv/nulldrv_gpa.c:647:37: error: ‘vkCreateXlibSurfaceKHR’ undeclared (first use in this function)
         return (PFN_vkVoidFunction) vkCreateXlibSurfaceKHR;
                                     ^
VulkanTools/build/icd/nulldrv/nulldrv_gpa.c:649:37: error: ‘vkGetPhysicalDeviceXlibPresentationSupportKHR’ undeclared (first use in this function)
         return (PFN_vkVoidFunction) vkGetPhysicalDeviceXlibPresentationSupportKHR;

nulldrv_gpa.c is an auto-generated file. I'm looking at the python scripts since it seems that's where it comes from. If I figure out how to disable Xlib functions, I'll send in a pull request.

I have the api_dump layer enabled in both the instance and the VkDeviceCreateInfo enabled layers, however the call is not reported. Other calls make prior to the vkCreateDevice call are dumped correctly. When I fix the issue with vkCreateDevice so that it returns success, it is dumped correctly.

Running screenshot layer with standard_validation results in some errors reported. Probably, screenshot layer is not quite correct in it's api usage.

Vulkaninfo makes really poor choices about what is displayed as hex values and what is displayed as decimal values. For instance, the Vulkan API verson is reported as a decimal value, even though it's only readable in hex, while device limits are reported as hex, even though decimal would be much more readable.

Furthermore, memory type flags are reported as decimal values rather than a list of flags as with image formats.

Maybe it needs to exit on other errors too?

It looks now the trace file captured from the win32 platform only can be replayed on win32 platform, right?

Can we make the trace file more platform independent? So the trace file can be replayed on different platforms.

When Vulkan Application uses persistently mapped memory, vktrace cannot track updates within this memory.

According to the specs v1.0.17, a subresource's layerCount parameter can be VK_REMAINING_ARRAY_LAYERS to use all layers of a resource (i.e. image). If the image is created with a single layer, setting the parameter to VK_REMAINING_ARRAY_LAYERS should therefore be equivalent to setting it to 1.

However, the parameter validation layer complains that:

ParameterValidation(ERROR): object: 0x0 type: 0 location: 2529 msgCode: 1: vkCreateImageView: if pCreateInfo->viewType is VK_IMAGE_TYPE_2D, pCreateInfo->subresourceRange.layerCount must be 1

Let me know if this is clear enough, or you would need a small code snippet.

The size of packet_vkApiVersion is different from 32bit system to 64bit system so the data packet generated on 32bit system should not be compatible with 64bit traceviewer.

It may be a problem, if the 32bit trace file cannot be replayed on 64 bit system，vice versa.

In working through the code and reading about VkUpdateDescriptorSets, I see that VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT should be handled similar to other descriptor types that reference the pImageInfo member, but it is not included among the switch case statements.

I don't immediately have a sample which uses it, so I can't provide a test/repro case, but since I know there are issues with trace & replay of several applications, I wanted to raise this issue as a potential cause of error. Should be a simple fix, but since I can't test & confirm it, I'll leave it to someone else to resolve.

Specifically:

The instancing sample will trace, but nothing is drawn on replay

The raytracing sample gets this assert while tracing:
"vktrace_trace_packet_utils.c:147: vktrace_trace_packet_get_new_buffer_address: Assertion `pHeader->size >= pHeader->next_buffers_offset + byteCount' failed".

The shadowmappingomni sample traces ok, replays ok, but segfaults when replayed with validation. Running the sample with validation gets errors but no seg fault

I've seen all three of these on both Linux+Mesa and Windows+Nvidia

My workaround for this problem (Ubuntu cmake package is 3.5.1):

diff --git a/icd/intel/kmd/CMakeLists.txt b/icd/intel/kmd/CMakeLists.txt
index baeb3e6..a0214f3 100644
--- a/icd/intel/kmd/CMakeLists.txt
+++ b/icd/intel/kmd/CMakeLists.txt
@@ -29,7 +29,11 @@ if(UNIX)
     set_source_files_properties(${libdrm_sources} PROPERTIES COMPILE_FLAGS
         "-std=gnu99 -Wno-type-limits -Wno-unused-variable")

-    find_package(PthreadStubs REQUIRED)
+
+set(THREADS_PREFER_PTHREAD_FLAG ON)
+find_package(Threads REQUIRED)
+#    find_package(PthreadStubs REQUIRED)
+
     list(APPEND include_dirs ${PTHREADSTUBS_INCLUDE_DIRS})
     list(APPEND libraries ${PTHREADSTUBS_LIBRARIES})

I've tried Examples 4-6 (Linux + Mesa) and they all trace but they all playback only background color. They call vkFlushMappedMemoryRanges so it's probably not the persistently mapped memory issue.

So the path line would turn out to be

vulkan -> SPRIV -> AMDGPU/NVPTX/IntelGPU/OtherGPU

The SPRIV are translated at the runtime.

Trace files can be very large. There should be a way to collect a trace for only a portion of the entire execution, because the user may be interested only in a few frames.

I noticed my machine was churning heavily while I had 2 instances of vktraceviewer running; each one was causing 17-20% CPU utililization.

Suspecting the timeline to be the culprit, I commented out its creation, and confirmed that the CPU utilization goes down to ~0%.

On deeper dive, looks like viewport()->update() is being called within the paintEvent, which would cause another paint event to be signaled. We're continually repainting the timeline... yeah, that's bad.

Windows 7, SDK 1.0.21.2, Nvidia GTX 660 ti, driver 372.54 vktrace the cube.exe in the SDK bin directory then replay and I get no rendering and a stream of VK_ERROR_DEVICE_LOST messages. Going back to the commit before "vktrace: map memory types on replay" 7d5b2e9 and everything works fine.

The driver is a key component to reproducing the failure.

During SDK 1.0.17 testing, I generated a Holgram trace on my Haswell system using the Mesa driver and when playing it back, the window height was bigger than the content being drawn. This also happens with some of the Sascha Willems samples.

Thanks.

vkGetPhysicalDeviceSurfaceFormatsKHR() and GetPhysicalDeviceSurfacePresentModesKHR() functions can have their pXCount and pXs arguments as NULL or not (where X is either SurfaceFormat or PresentMode). The specifications v1.0.17+wsi, in short says:

• if pXs is not provided, only the count is returned
• if pXs is provided, the minimum of pXCount and the supported number of Xs are written to the pXs.

Which is nice and clear. However, the swapchain validation layer complains that:

Swapchain(ERROR): object: 0x7fd2a3725d68 type: 2 location: 0 msgCode: 25: GetPhysicalDeviceSurfaceFormatsKHR() called with non-NULL pSurfaceFormatCount; but no prior positive value has been seen for pSurfaceFormats.
Swapchain(ERROR): object: 0x7fd2a3725d8c type: 2 location: 0 msgCode: 25: GetPhysicalDeviceSurfacePresentModesKHR() called with non-NULL pPresentModeCount; but no prior positive value has been seen for pPresentModes.

Digging into why this error is popped, I found this comment in swapchain.cpp:

// Since we haven't recorded a preliminary value of
// *pSurfaceFormatCount, that likely means that the application
// didn't previously call this function with a NULL value of
// pSurfaceFormats:

The specifications don't seem to require that the function should be called with pXs once NULL, and then another time not NULL.

The specification v1.0.17 for the vkDestroyX functions seem to allow VK_NULL_HANDLE to be given to these functions. For example vkDestroyBufferView says:

If bufferView is not VK_NULL_HANDLE, bufferView must be a valid VkBufferView handle

Which implies that bufferView could be VK_NULL_HANDLE. This is actually nice, similar to how C's free(NULL) is correct and useful.

However, the object tracker validation layer complains that:

OBJTRACK(ERROR): object: 0x0 type: 13 location: 1456 msgCode: 4: Invalid VkBufferView Object 0x0
OBJTRACK(ERROR): object: 0x0 type: 0 location: 690 msgCode: 1: Unable to remove obj 0x0. Was it created? Has it already been destroyed?

I noticed the nvidia driver (under Linux if it makes any difference) crashing when given VK_NULL_HANDLE in these cases as well. Perhaps this is already the established behavior, but the specifications need to be updated to disallow VK_NULL_HANDLE?

The formula in the "Controlling the Viewport" section (specifications v1.0.17) says:

xf = px/2 * xd + ox
yf = py/2 * yd + oy
zf = pz * zd + oz

Is the above formula correct? First of all, it is inconsistent with OpenGL which has:

xf = px/2 * (xd + 1) + ox
yf = py/2 * (yd + 1) + oy

In other words, with OpenGL, if you have a viewport with origin (0, 0) and extent (width, height), then normalized coordinates (0, 0) map to the middle of the screen. With the Vulkan formulas, the same viewport would map normalized coordinates (0, 0) to the corner of the screen.

The nvidia driver on Linux actually maps normalized coordinate (0, 0) to the middle screen with such a viewport, which is either a bug in the driver, or a hint at an incorrect formula in the specifications. Or perhaps I'm missing something?

I received the above error message from the validation layer during the call to vkCreateGraphicsPipelines with the following parameters to the DebugReport callback:

objType:  DeviceExt
obj:  0
location: 0x655
messageCode: 3
layerPrefix:  "SC"
message "VS consumes input at location 0 but not provided"

As someone who is new to Vulkan, I found it less then helpful.

1. Is "VS" VertexShader?

2. I would like to see more detail as to what test failed or possibly an action to take. The VkGraphicsPipelineCreateInfo is very complex and narrowing down the issue would make it easier to track down the error. In this case, I wasn't setting the pVertexInputState structure fields, leaving the values null. So adding something like "pVertexInputState.pVertexBindingDescriptions must not be null" would have pointed me in the right direction.

Exception thrown: read access violation.
this->m_pController-> was 0xFFFFFFFFFFFFFF7F.
If there is a handler for this exception, the program may be safely continued.

vktraceviewer.exe!vktraceviewer::close_trace_file() Line 698 C++
@ the line "m_pController->UnloadTraceFile();"

void vktraceviewer::close_trace_file()
{
    if (m_pController != NULL)
    {
        ui->bottomTabWidget->removeTab(ui->bottomTabWidget->indexOf(m_pTraceStatsTab));
        m_pController->UnloadTraceFile();
#ifndef USE_STATIC_CONTROLLER_LIBRARY
        m_controllerFactory.Unload(&m_pController);
#else
        vtvDeleteQController(m_pController);
#endif
    }

vktrace dies immediately when trying to trace on Win7/32.

vktrace on Win 10/64 using 32 bit libraries seems to work.

Haven't tried vktrace on other 32-bit Windows systems, but they probably don't work either.

I'm using vkreplay on arm+android platform and it crashed in trace files containing "vkUpdateDescriptorSets" calls:

--------- beginning of crash
01-01 17:27:36.791 3356 3394 F libc : Fatal signal 11 (SIGSEGV), code 1, fault addr 0x98b8010c in tid 3394 (Thread-266)
01-01 17:27:36.842 169 169 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
01-01 17:27:36.842 169 169 F DEBUG : Build fingerprint: 'Android/firefly/firefly:6.0/MRA58K/jefyan0106081402:eng/test-keys'
01-01 17:27:36.842 169 169 F DEBUG : Revision: '0'
01-01 17:27:36.842 169 169 F DEBUG : ABI: 'arm'
01-01 17:27:36.842 169 169 F DEBUG : pid: 3356, tid: 3394, name: Thread-266 >>> com.arm.vktrace.vktrace_replay <<<
01-01 17:27:36.842 169 169 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x98b8010c
01-01 17:27:36.851 169 169 F DEBUG : r0 00000002 r1 00000036 r2 ffffffd0 r3 b6d992f0
01-01 17:27:36.851 169 169 F DEBUG : r4 b6d992e8 r5 98bb8670 r6 9eef0000 r7 98b80000
01-01 17:27:36.851 169 169 F DEBUG : r8 a0c92048 r9 b6d8c594 sl 00000001 fp 9ee40191
01-01 17:27:36.851 169 169 F DEBUG : ip 98b800d8 sp 9edede48 lr b6d6e613 pc b6d6b692 cpsr 200f0030
01-01 17:27:36.857 169 169 F DEBUG :
01-01 17:27:36.857 169 169 F DEBUG : backtrace:
01-01 17:27:36.857 169 169 F DEBUG : #00 pc 00055692 /system/lib/libc.so (ifree+49)
01-01 17:27:36.857 169 169 F DEBUG : #01 pc 0005860f /system/lib/libc.so (je_free+374)
01-01 17:27:36.857 169 169 F DEBUG : #02 pc 000592a3 /data/app/com.arm.vktrace.vktrace_replay-1/lib/arm/libreplaycore.so
01-01 17:27:36.857 169 169 F DEBUG : #03 pc 00061413 /data/app/com.arm.vktrace.vktrace_replay-1/lib/arm/libreplaycore.so (vkReplay::manually_replay_vkUpdateDescriptorSets(packet_vkUpdateDescriptorSets*)+2474)
01-01 17:27:36.857 169 169 F DEBUG : #04 pc 0008d003 /data/app/com.arm.vktrace.vktrace_replay-1/lib/arm/libreplaycore.so (vkReplay::replay(vktrace_trace_packet_header*)+16642)
01-01 17:27:36.857 169 169 F DEBUG : #05 pc 0007f059 /data/app/com.arm.vktrace.vktrace_replay-1/lib/arm/libreplaycore.so (VkReplayReplay(vktrace_trace_packet_header*)+36)
01-01 17:27:36.857 169 169 F DEBUG : #06 pc 00091a4b /data/app/com.arm.vktrace.vktrace_replay-1/lib/arm/libreplaycore.so (vktrace_replay::main_loop(vktrace_replay::Sequencer&, vktrace_replay::vktrace_trace_packet_replay_library**, vkreplayer_settings)+266)
01-01 17:27:36.857 169 169 F DEBUG : #07 pc 000921dd /data/app/com.arm.vktrace.vktrace_replay-1/lib/arm/libreplaycore.so (android_main+1168)
01-01 17:27:36.857 169 169 F DEBUG : #08 pc 00051233 /data/app/com.arm.vktrace.vktrace_replay-1/lib/arm/libreplaycore.so
01-01 17:27:36.857 169 169 F DEBUG : #09 pc 0003f817 /system/lib/libc.so (__pthread_start(void*)+30)
01-01 17:27:36.857 169 169 F DEBUG : #10 pc 00019f73 /system/lib/libc.so (__start_thread+6)
01-01 17:27:37.157 1009 3408 W ActivityManager: Force finishing activity com.arm.vktrace.vktrace_replay/android.app.NativeActivity
01-01 17:27:37.157 169 169 F DEBUG :
01-01 17:27:37.157 169 169 F DEBUG : Tombstone written to: /data/tombstones/tombstone_03
01-01 17:27:37.157 169 169 E DEBUG : AM write failed: Broken pipe

The problem may be the memory free part of manually_replay_vkUpdateDescriptorSets, I read the source code and

pRemappedWrites[d].pImageInfo != NULL
pRemappedWrites[d].pBufferInfo != NULL
pRemappedWrites[d].pTexelBufferView != NULL

are suspicious because it seems that these pointers are not initialized after malloc.

Most of Sascha Willems' Vulkan samples have a text overlay in the top left corner, however after trace & replay of these samples, the text overlay is missing during the replay.

Oddly enough, when using RenderDoc to launch vkreplay with the same trace file as above, the text overlay is visible!

From Dan Ginsburg:

I’m trying to use vktrace in Vulkan SDK 1.0.13 on Win7 to capture a tough to reproduce flickering bug on NVIDIA GTX 760. Unfortunately, when I load into the map it seems to get stuck and eventually crash during recording. If I disable scaleform I can get it to record, so it seems like maybe something scaleform does that is not working in vktrace?

Memory types and properties have been changing from driver to driver, so a trace that blindly uses memory type 2 on playback could be getting memory with different properties than it got when the trace was recorded. I think the replayer will need to map memory types with properties on record to memory types with the same properties on playback for all allocations.

Some arm vfp load instructions, e.g. vldr, requires the address of the source to align to 4 bytes.

But sometimes, the address decomposed from the packet is not 4 bytes alignment, e.g., the 4 float type members in the VkPipelineRasterizationStateCreateInfo structure, that is causing the vldr instruction fail.

Currently on vkUnmapMemory, vktrace either serializes the entire memory range or nothing if the memory has had a FlushMappedMemoryRange on it. For non-coherent memory this is correct. For coherent memory the app doesn't necessarily need to use FlushMappedMemoryRange but it might. In this case vktrace should probably still serialize the entire range at Unmap even if it has seen some FlushMappedMemoryRange since these aren't strictly required for coherent memory so the app may be relying on the Unmap.

Building from here: https://github.com/nvpro-samples/gl_vk_bk3dthreaded, using sdk-1.0.24 build of VulkanTools, I can trace the demo, but when I try to replay the trace, I get 2 ERROR_DEVICE_LOST errors fro VkQueueSubmit calls and the replay hangs

"wget" is a necessary dependency.
"autotools" is a necessary dependency.

Prüfe Konnektivität ... Fertig.
./update_external_sources.sh: Zeile 67: wget: Kommando nicht gefunden.

This is the same type of issue as #64, in that QueueFamilies selected are record time will need to have their properties recorded and mapped to QueueFamilies that have the same properties at playback time

Using vktrace to trace the bloom demo (and many other demos), the trace file generates without issue, but when playing back the trace, I get an exception calling free() in GetPhysicalDeviceQueueFamilyProperties (the 5th call) and it looks like the data in .queueFamilyProperties is uninitialized (0xdddddddd)

Error message:

CMake Error at CMakeLists.txt:52 (string):
string sub-command REPLACE requires at least four arguments.

I'm using:
cmake version 3.5.2

https://github.com/LunarG/VulkanTools/blob/master/vktrace/src/vktrace_layer/vktrace_lib_trace.cpp traces data written to mapped memory in __HOOKED_vkUnmapMemory and __HOOKED_vkFlushMappedMemoryRanges . However, allocations made with VK_MEMORY_PROPERTY_HOST_COHERENT_BIT may be written by the host and read by the device with no synchronization other than the implicit synchronization of vkQueueSubmit, and without vkUnmapMemory'ing the vkDeviceMemory . This could allow writes that affect the rendered result (for example, to a uniform buffer) to not be captured by the tracing layer .

One way to solve this would be for the layer to prevent heaps from allowing allocations with VK_MEMORY_PROPERTY_HOST_COHERENT_BIT ?

In update_external_sources.sh this step:
svn checkout -r $LUNARGLASS_REVISION_R32 --force https://cvs.khronos.org/svn/repos/SPIRV/trunk/LunarGLASS/ .
requires passworkd and login which I don't have..
being all opensourced by now doesn't make sense,right?
can update script to fetch from public repos?
thanks..

On 16.04 Mesa a0d9279e3b31ce5e5bb2baf857134bd5f48dbf65 it crashes in the driver on a call to GetPhysicalDeviceXcbPresentationSupportKHRn during replay (a cube trace replays fine using the same call) and on 15.10 Nvidia vktrace hangs.

Right now, screenshot only supports 2 image formats, (neither of which are the default mesa image format) and it would be nice to use a blit to copy from the source image, converting to one of the two formats that lend themselves to easy ppm file generation. If the incoming format has VK_FORMAT_FEATURE_BLIT_SRC_BIT in its features for whatever tiling its using, writePPM could use vkCmdBlitImage instead of vkCopyImage to both copy and convert the format.

It would be nice if vkreplay could know what OS it was running on and translate WSI calls from the trace to WSI calls appropriate for the system it was replaying on.

Using vktrace on cube --validate will produce the following fatal errors on replay:

vktrace -p cube.exe -a --validate -o fred.vktrace vkreplay -t fred.vktrace

Verbose: Enumerated 1 physical devices in the system.
Error: MsgFlags 8 with object 0x7ff94efb9e60, location 1995 returned msgCode 8 and msg vkCreateSwapchainKHR() called with pCreateInfo->imageExtent = (500,500), which is not equal to the currentExtent = (1008,729) returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR().
Error: MsgFlags 8 with object 0x7ff94efb9e60, location 1995 returned msgCode 8 and msg vkCreateSwapchainKHR() called with pCreateInfo->imageExtent = (500,500), which is not equal to the currentExtent = (1008,729) returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR().
Error: Return value VK_ERROR_VALIDATION_FAILED_EXT from API call (vkCreateSwapchainKHR) does not match return value from trace file
VK_SUCCESS.
Error: Failed to replay packet_id 149.

The swapchain layer is logging an error becasue the extents do not match (between trace and replay, on Windows) which causes the vkCreateSwapchain call to fail.

Using vktrace to trace the atw sample at https://github.com/KhronosGroup/Vulkan-Samples results in an assert - vktrace...utils.c line 147: Expression pHeader->size >= pHeader->next_buffer_offset + byteCount

Various improvements suggested by Tony B .

Attempting to trace a Vulkan application where VkInstanceCreateInfo.pApplicationInfo == NULL causes a segfault. Valgrind indicates the issue comes from __HOOKED_vkCreateInstance.