I'm on the dustin_nonoptional_threadid branch.

$ /home/papillo/work/LunarG/gfxreconstruct/build/tools/compress/gfxrecon-compress /tmp/resvi/dota2/compress-native-to-LZ4-results/dota2-LZ4.gfxr /tmp/resvi/dota2/compress-LZ4-to-ZLIB-results/dota2-ZLIB.gfxr ZLIB
[gfxrecon] WARNING - Skipping unrecognized file block with type 0
Compression Results:
  Original Size   [Compression:   LZ4] = 304942678324 bytes
  Compressed Size [Compression:  ZLIB] = 259 bytes
  Percent Reduction                    = 100.00%

Add support for a hot key based toggle for trimming, starting or stopping frame capture when the key is pressed.

It would be very useful to be able to export a specific frame to renderdoc, especially for bugs that only persist for a few frames

For Nvidia, vkQuake and Ballistic Overkill will immediately seg fault on replay.

No problems getting the trace.

Trace files are located on NAS: smb://nas.local/smb_traces/GFXR/

For the 1.0 Release, support needs to be added to the trimming state tracker for the following:

• vkBindImageMemory2 and VkBindBufferMemory2 (partially supported)
• vkBindImageMemorySwapchainInfoKHR
• VK_EXT_inline_uniform_block
• VK_EXT_full_screen_exclusive
• VK_AMD_display_native_hdr (vkSetLocalDimmingAMD)
• VK_NV_ray_tracing (probably very similar to KHR_ray_tracing KHR_ray_tracing_pipeline)

• VK_NVX_device_generated_commands defer to post-1.0 trimming support
• VK_KHR_timeline_semaphore #505

• VK_KHR_create_renderpass2 - tracked as if ithe associated structs are the ones for 1.0 renderpass, so some things are not tracked correctly (see #551 )

Additional extensions may require trimming support but are not scheduled for 1.0 Release.

I'm to make a change in one of the generators however when I run generate_vulkan.py it updates all generated_* files reordering structs and methods in them. This causes compilation failure due to incomplete type passed to StructPointerDecoder:

framework/decode/struct_pointer_decoder.h: In instantiation of ‘class gfxrecon::decode::StructPointerDecoder<gfxrecon::decode::Decoded_VkDeviceQueueCreateInfo>’:
generated/generated_vulkan_struct_decoders.h:52:59:   required from here
decode/struct_pointer_decoder.h:57:30: error: invalid use of incomplete type ‘struct gfxrecon::decode::Decoded_VkDeviceQueueCreateInfo’
     typename T::struct_type* GetPointer() const { return struct_memory_; }
                              ^~~~~~~~~~
In file included from decode/descriptor_update_template_decoder.h:23,
                 from decode/descriptor_update_template_decoder.cpp:18:
generated/generated_vulkan_struct_decoders_forward.h:76:8: note: forward declaration of ‘struct gfxrecon::decode::Decoded_VkDeviceQueueCreateInfo’
 struct Decoded_VkDeviceQueueCreateInfo;
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

When replaying a trimmed file, during the initial state setup all resource uploads are performed with vkCmdCopyBuffer and vkCmdCopyBufferToImage. For resources created without TRANSFER_DST usage or images created with sample count greater than 1, a shader based copy should be implemented.

Over the next several months vktrace/vkreplay (https://github.com/LunarG/VulkaTools) will be deprecated, to be replaced by gfxreconstruct . New development work for Vulkan trace tools should be directed to gfxreconstruct. At this point vktrace/vkreplay is in maintenance mode.

A consideration for transitioning from vktrace to gfxreconstruct is the porting of existing traces created with vktrace to gfxreconstruct. At present, there are no plans to create tools or add capability to gfxreconstruct to assist in this porting. Existing vktrace traces will need to be converted by replaying the trace and tracing the replay using gfxreconstruct.

Currently, the capture layer will capture all frames from application start to exit. Add support to the layer for capturing a range of frames, as well as a utility for trimming existing capture files to a sub-range of frames.

This feature will be implemented with the following sub-tasks.

• Implement State Tracking for Trimming (#182)
• Implement Trimming in the Capture Layer (#183)
• Implement a Trimming Utility (#184)

Add support for obtaining page guard options from a configuration file or environment variable/system property.

Settings should be applied in TraceManager::Initialize, where the page guard manager is currently initialized with hard coded constants as Create(true, false, true, true, true, true)

Code generation is currently an offline process. An option to perform code generation at build time should also be added to the CMake scripts to regenerate code as a build step. This option would be intended for use by developers that are actively editing the code generation scripts.

These traces were captured on a Linux machine and immediately replayed on the same machine. Four out of five games produced unexpected output. But the rendering output was fine (at least, as far as I could tell).

Rise of the Tomb Raider:

        [gfxrecon] ERROR - API call (vkGetPipelineCacheData) returned value VK_INCOMPLETE that does not match return value from capture file VK_SUCCESS.
        [gfxrecon] ERROR - API call (vkGetPipelineCacheData) returned value VK_INCOMPLETE that does not match return value from capture file VK_SUCCESS.
        [gfxrecon] ERROR - API call (vkGetPipelineCacheData) returned value VK_INCOMPLETE that does not match return value from capture file VK_SUCCESS.
        [gfxrecon] ERROR - API call (vkGetPipelineCacheData) returned value VK_INCOMPLETE that does not match return value from capture file VK_SUCCESS.
        [gfxrecon] ERROR - API call (vkGetPipelineCacheData) returned value VK_INCOMPLETE that does not match return value from capture file VK_SUCCESS.
        [gfxrecon] ERROR - API call (vkGetPipelineCacheData) returned value VK_INCOMPLETE that does not match return value from capture file VK_SUCCESS.
        [gfxrecon] ERROR - API call (vkGetPipelineCacheData) returned value VK_INCOMPLETE that does not match return value from capture file VK_SUCCESS.
        [gfxrecon] ERROR - API call (vkGetPipelineCacheData) returned value VK_INCOMPLETE that does not match return value from capture file VK_SUCCESS.
        [gfxrecon] ERROR - API call (vkGetPipelineCacheData) returned value VK_INCOMPLETE that does not match return value from capture file VK_SUCCESS.
        [gfxrecon] ERROR - API call (vkGetPipelineCacheData) returned value VK_INCOMPLETE that does not match return value from capture file VK_SUCCESS.
        [gfxrecon] ERROR - API call (vkGetPipelineCacheData) returned value VK_INCOMPLETE that does not match return value from capture file VK_SUCCESS.
        [gfxrecon] ERROR - API call (vkGetPipelineCacheData) returned value VK_INCOMPLETE that does not match return value from capture file VK_SUCCESS.
        [gfxrecon] ERROR - API call (vkGetPipelineCacheData) returned value VK_INCOMPLETE that does not match return value from capture file VK_SUCCESS.
        [gfxrecon] ERROR - API call (vkGetPipelineCacheData) returned value VK_INCOMPLETE that does not match return value from capture file VK_SUCCESS.
        [gfxrecon] ERROR - API call (vkGetPipelineCacheData) returned value VK_INCOMPLETE that does not match return value from capture file VK_SUCCESS.
        [gfxrecon] ERROR - API call (vkGetPipelineCacheData) returned value VK_INCOMPLETE that does not match return value from capture file VK_SUCCESS.
        64.516657 fps, 198.878871 seconds, 12831 frames, 1 loop, framerange 1-12831

Talos: no errors or warnings

Warhammer:

        [gfxrecon] ERROR - API call (vkGetPipelineCacheData) returned value VK_INCOMPLETE that does not match return value from capture file VK_SUCCESS.
        [gfxrecon] ERROR - API call (vkGetPipelineCacheData) returned value VK_INCOMPLETE that does not match return value from capture file VK_SUCCESS.
        45.134589 fps, 126.554823 seconds, 5712 frames, 1 loop, framerange 1-5712

Dawn of War:

        [gfxrecon] ERROR - API call (vkGetPipelineCacheData) returned value VK_INCOMPLETE that does not match return value from capture file VK_SUCCESS.
        [gfxrecon] ERROR - API call (vkGetPipelineCacheData) returned value VK_INCOMPLETE that does not match return value from capture file VK_SUCCESS.
        [gfxrecon] ERROR - API call (vkGetPipelineCacheData) returned value VK_INCOMPLETE that does not match return value from capture file VK_SUCCESS.
        [gfxrecon] ERROR - API call (vkGetPipelineCacheData) returned value VK_INCOMPLETE that does not match return value from capture file VK_SUCCESS.
        [gfxrecon] ERROR - API call (vkGetPipelineCacheData) returned value VK_INCOMPLETE that does not match return value from capture file VK_SUCCESS.
        [gfxrecon] ERROR - API call (vkGetPipelineCacheData) returned value VK_INCOMPLETE that does not match return value from capture file VK_SUCCESS.
        [gfxrecon] ERROR - API call (vkGetPipelineCacheData) returned value VK_INCOMPLETE that does not match return value from capture file VK_SUCCESS.
        [gfxrecon] ERROR - API call (vkGetPipelineCacheData) returned value VK_INCOMPLETE that does not match return value from capture file VK_SUCCESS.
        [gfxrecon] ERROR - API call (vkGetPipelineCacheData) returned value VK_INCOMPLETE that does not match return value from capture file VK_SUCCESS.
        [gfxrecon] ERROR - API call (vkGetPipelineCacheData) returned value VK_INCOMPLETE that does not match return value from capture file VK_SUCCESS.
        [gfxrecon] ERROR - API call (vkGetPipelineCacheData) returned value VK_INCOMPLETE that does not match return value from capture file VK_SUCCESS.
        [gfxrecon] ERROR - API call (vkGetPipelineCacheData) returned value VK_INCOMPLETE that does not match return value from capture file VK_SUCCESS.
        [gfxrecon] ERROR - API call (vkGetPipelineCacheData) returned value VK_INCOMPLETE that does not match return value from capture file VK_SUCCESS.
        [gfxrecon] ERROR - API call (vkGetPipelineCacheData) returned value VK_INCOMPLETE that does not match return value from capture file VK_SUCCESS.
        169.297617 fps, 61.117222 seconds, 10347 frames, 1 loop, framerange 1-10347

Dota 2:

        ...
        [gfxrecon] WARNING - Failed to map handle for object id 2
        [gfxrecon] WARNING - Failed to map handle for object id 1010000
        [gfxrecon] WARNING - Failed to map handle for object id 55dda3519c90
        [gfxrecon] WARNING - Failed to map handle for object id 1010000
        [gfxrecon] WARNING - Failed to map handle for object id 100000001
        [gfxrecon] WARNING - Failed to map handle for object id 55dda3519c90
        [gfxrecon] WARNING - Failed to map handle for object id 1010000
        [gfxrecon] WARNING - Failed to map handle for object id 100000001
        [gfxrecon] WARNING - Failed to map handle for object id 55dda3519c90
        [gfxrecon] WARNING - Failed to map handle for object id 1010000
        [gfxrecon] WARNING - Failed to map handle for object id 55dda3519c90
        [gfxrecon] WARNING - Failed to map handle for object id 1010000
        [gfxrecon] WARNING - Failed to map handle for object id 55dda3519c90
        [gfxrecon] WARNING - Failed to map handle for object id 1010000
        [gfxrecon] WARNING - Failed to map handle for object id 55dda3519c90
        [gfxrecon] WARNING - Failed to map handle for object id 1010000
        [gfxrecon] WARNING - Failed to map handle for object id 55dda3519c90
        [gfxrecon] WARNING - Failed to map handle for object id 1010000
        [gfxrecon] WARNING - Failed to map handle for object id 55dda3519c90
        [gfxrecon] WARNING - Failed to map handle for object id 1010000
        [gfxrecon] WARNING - Failed to map handle for object id 55dda3519c90
        [gfxrecon] WARNING - Failed to map handle for object id 1010000
        [gfxrecon] WARNING - Failed to map handle for object id 55dda3519c90
        210.600937 fps, 43.081480 seconds, 9073 frames, 1 loop, framerange 1-9073

For replay on systems with swapchains supporting different presentation modes and different min/max image requirements than the capture system, swapchain interaction will need to be adjusted. One potential solution would be to substitute VkImage objects with color attachment usage for swapchain images at image acquire, and then blit the substituted image to the appropriate swapchain image at queue present.

Found on an ubuntu 18.04 machine with an AMD device.

Create a trace of vulkaninfo, and then attempt to replay it with gfxrecon-replay. The replay will segfault in GetPhysicalDeviceQueueFamilyProperties2():

#0  0x00007ffff4bd44e0 in ?? () from /opt/amdgpu-pro/lib/x86_64-linux-gnu/amdvlk64.so
#1  0x00007ffff5bb6378 in terminator_GetPhysicalDeviceQueueFamilyProperties2 ()
   from /home/papillo/work/vulkan/1.1.92.1/x86_64/lib/libvulkan.so
#2  0x0000555555623384 in gfxrecon::decode::VulkanReplayConsumer::Process_vkGetPhysicalDeviceQueueFamilyProperties2KHR(unsigned long, gfxrecon::decode::PointerDecoder<unsigned int> const&, gfxrecon::decode::StructPointerDecoder<gfxrecon::decode::Decoded_VkQueueFamilyProperties2> const&) ()
#3  0x000055555560e60d in gfxrecon::decode::VulkanDecoder::Decode_vkGetPhysicalDeviceQueueFamilyProperties2KHR(unsigned char const*, unsigned long) ()
#4  0x00005555555c939f in gfxrecon::decode::FileProcessor::ProcessFunctionCall(gfxrecon::format::BlockHeader const&, gfxrecon::format::ApiCallId) ()
#5  0x00005555555c9ecf in gfxrecon::decode::FileProcessor::ProcessNextFrame() ()
#6  0x00005555555c7049 in gfxrecon::application::Application::Run() ()
#7  0x00005555555c5c39 in main ()

The trace I'm using is in \\nas\smb_traces\vulkan\GFXR\papillo-amd\dota2\dota2_20190213T193643.gfxr. This trace was created on Ubuntu 18.04 with an AMD RX 580 graphics card.

To reproduce, capture the image at (0-based) frame 30, then trim the trace to just (1-based) frame 31. Replay the trimmed trace and capture (0-based) frame 0. The two images do not match.

With an appropriate PATH (that contains gfxrecon-replay) and VK_LAYER_PATH (that contains the screenshot and gfxreconstruct layers):

# Local copy of the file
cp /media/nas/smb_traces/vulkan/GFXR/papillo-amd/dota2/dota2_20190213T193643.gfxr dota2.gfxr

# Create image for frame 30 (screenshot frames are 0-based)
export VK_INSTANCE_LAYERS=VK_LAYER_LUNARG_screenshot
export VK_SCREENSHOT_FRAMES=30
gfxrecon-replay dota2.gfxr

# Trim to the same frame (GFXR frames are 1-based)
export VK_INSTANCE_LAYERS=VK_LAYER_LUNARG_gfxreconstruct
export GFXRECON_CAPTURE_FRAMES=31
gfxrecon-replay dota2.gfxr

# Replay trimmed trace and capture frame 0
export VK_INSTANCE_LAYERS=VK_LAYER_LUNARG_screenshot
export VK_SCREENSHOT_FRAMES=0
gfxrecon-replay gfxrecon_capture_frame_31_XXXX.gfxr

# Examine the two frames
eog 0.ppm 30.ppm

I'm putting this here at Lenny's request...

Trying to run gfxrecon traces on emmeria (Linux AMD), and using the snapshot layer to collect images for comparison purposes, I provoked a cryptic loader segfault:

        Program received signal SIGSEGV, Segmentation fault.
        0x00007ffff62dc104 in loader_validate_instance_extensions ()
           from /home/lunarg/sdks/1.1.101.0/x86_64/lib/libvulkan.so
        (gdb) bt
        #0  0x00007ffff62dc104 in loader_validate_instance_extensions ()
           from /home/lunarg/sdks/1.1.101.0/x86_64/lib/libvulkan.so
        #1  0x00007ffff62dee8d in vkCreateInstance ()
           from /home/lunarg/sdks/1.1.101.0/x86_64/lib/libvulkan.so
        #2  0x00000000004d51c0 in gfxrecon::decode::VulkanReplayConsumerBase::OverrideCreateInstance(VkInstanceCreateInfo const*, VkAllocationCallbacks const*, VkInstance_T**) ()
        #3  0x0000000000539542 in gfxrecon::decode::VulkanReplayConsumer::Process_vkCreateInstance(VkResult, gfxrecon::decode::StructPointerDecoder<gfxrecon::decode::Decoded_VkInstanceCreateInfo> const&, gfxrecon::decode::StructPointerDecoder<gfxrecon::decode::Decoded_VkAllocationCallbacks> const&, gfxrecon::decode::HandlePointerDecoder<VkInstance_T*> const&) ()
        #4  0x00000000004f836a in gfxrecon::decode::VulkanDecoder::Decode_vkCreateInstance(unsigned char const*, unsigned long) ()
        #5  0x00000000004cf8b6 in gfxrecon::decode::FileProcessor::ProcessFunctionCall(gfxrecon::format::BlockHeader const&, gfxrecon::format::ApiCallId) ()
        #6  0x00000000004d059f in gfxrecon::decode::FileProcessor::ProcessBlocks() ()
        #7  0x00000000004cd6a1 in gfxrecon::application::Application::Run() ()
        #8  0x00000000004cbe6a in main ()

No other message was given.

If you turn off the screenshot layer, the reason (or at least part of it) becomes clearer:

        $ unset VK_INSTANCE_LAYERS
        $ /home/lunarg/.jenkins/g0/Release64/gfxreconstruct/build/tools/replay/gfxrecon-replay /home/lunarg/.jenkins/g0/Release64/vulkaninfo/local-copy/vulkaninfo_20190220T162436.gfxr
        [gfxrecon] ERROR - API call (vkCreateInstance) returned value VK_ERROR_EXTENSION_NOT_PRESENT that does not match return value from capture file VK_SUCCESS.
        [gfxrecon] WARNING - API call (vkCreateInstance) returned error result VK_ERROR_EXTENSION_NOT_PRESENT: the specified extension does not exist
        Segmentation fault (core dumped)

So the problem looks like some issue when trying to create an instance using an extension that doesn't exist, while the snapshot layer is active.

Ideally, the loader should return some type of message in this situation.

gfxrecon-toascii currently only writes function names to the text file.

To be more usable, parameters should also be printed to the text file (possibly optionally, controlled by switches).

A switch-controlled option to output compilable (or near-compilable) source would also be helpful.

For replay on systems with more than one GPU (eg Laptop with both integrated and discrete GPUs), select the device that is the best match for the capture device.

Linux replay currently converts all surface creation calls to either Xcb or Wayland surface creation calls. The tool should support creating multiple surface types during replay.

If a capture file contains both Xcb and Wayland surfaces, and the replay tool was built with support for both Xcb and Wayland surfaces, it should create both Wayland and Xcb surfaces instead of converting all surfaces to either Xcb surfaces or Wayland surfaces. It should only convert a surface if it was not built with support for that surface type.

Implement overrides for functions that retrieve an array size and are used with the following pattern:

vkEnumeratePhysicalDevices(instance, &size, nullptr);
data = new VkPhsicalDevice[size];
vkEnumeratePhysicalDevices(instance, size, data);

Current replay behavior is to always use the size value read from the file. If the size value read from the capture file is smaller than the size value returned by the first call in the above example, the replay of the second call will produce a VK_INCOMPLETE return value.

The replay tool will print an error message for the VK_INCOMPLETE return value, but the replay tool will not use the data retrieved by the call, so it should be safe to ignore the message.

Short term, this could be addressed by silencing the VK_INCOMPLETE error message, but long term we will need to implement a portability override, which does the following to make the call with the correct array size:

• When the array parameter is null, skip replay of the call.
• When the array parameter is not null, first call the function with a null array value to obtain the appropriate size, then allocate memory for the array and make the call with retrieved size and allocated memory.

Although this is primarily a portability issue, where the size value would only be different for replay on a different GPU/driver, the vkGetPipelineCacheData has been observed to return different sizes when replayed on the same system used for capture, resulting in the VK_INCOMPLETE error message on replay, which should be addressed for the 'non-portability' replay case.

The capture layer currently writes directly to a file. An option should be added for a client-server mode, where the layer acts as a client that transmits data to a server, similar to the current vktrace.

Add Xlib surface support for Linux replay. Linux replay currently supports Xcb and Wayland surfaces.

The replay process is initializing the debug callback functions (e.g. VkDebugReportCallbackCreateInfoEXT::pfnCallback) as NULL, and never setting them to a valid function pointer.

gfxrecon-toascii currently creates a .txt file in the same directory as the trace.

It should take command-line options to allow the .txt file to go to any desired location (including stdout, for use in pipes).

VK_LAYER_LUNARG_screenshot uses 0-based frame numbers (frame 0 is the first frame, etc.). gfxreconstruct uses 1-based frame numbers (frame 1 is the first frame).

This leads to user confusion when, for example, the user has identified that frame X in a trace is important, and uses it as a screenshot keyframe; but to trim to just that frame in gfxreconstruct would require trimming to frame X+1.

We should be consistent. Although I prefer the gfxreconstruct convention, it's more important to be consistent with the earlier screenshot standard.

Display the FPS after replay

A possible requirement could be that it is similar to vkreplay so that it can handle a framerange from the command line to score on.

Add functionality to capture images

Need a way to specify a frame (or multiple frames) as an argument to capture frames as an image file.

With Python development (for tests) occurring in the repo, it would be very helpful to have a project pylintrc file essentially encoding the project Python style guide.

Note the final $, which is my next prompt - the Percent Reduction line does not appear to be terminated with a newline.

$ /home/papillo/work/LunarG/gfxreconstruct/build/tools/compress/gfxrecon-compress /tmp/resvi/dota2/compress-native-to-LZ4-results/dota2-LZ4.gfxr /tmp/resvi/dota2/compress-LZ4-to-ZLIB-results/dota2-ZLIB.gfxr ZLIB
[gfxrecon] WARNING - Skipping unrecognized file block with type 0
Compression Results:
  Original Size   [Compression:   LZ4] = 304942678324 bytes
  Compressed Size [Compression:  ZLIB] = 259 bytes
  Percent Reduction                    = 100.00%$

It looks the generated cpp and header files are checked in the repo. Why they are not generated in the build time?

The WARNING line was issued to stdout. I'd expect it to go to stderr.

$ /home/papillo/work/LunarG/gfxreconstruct/build/tools/compress/gfxrecon-compress /tmp/resvi/dota2/compress-native-to-LZ4-results/dota2-LZ4.gfxr /tmp/resvi/dota2/compress-LZ4-to-ZLIB-results/dota2-ZLIB.gfxr ZLIB
[gfxrecon] WARNING - Skipping unrecognized file block with type 0
Compression Results:
  Original Size   [Compression:   LZ4] = 304942678324 bytes
  Compressed Size [Compression:  ZLIB] = 259 bytes
  Percent Reduction                    = 100.00%$

The current capture behavior us to record both the input and output/return values for an API call in single packet, which is written to the capture file after the API call has returned. This behavior could be modified to split the input and output values into separate packets, with inputs written before the API call and outputs written after the API call.

This could be useful for capturing crashes where the crash happened in the API call due to invalid inputs. With the current behavior of logging the packet after the API call, the packet would not be written to the file in the case of a crash. Note that this is only true for API calls with return values and/or output parameters. For API calls that only have input parameters, the packet is logged before the API call.

In theory, this could also be used for basic synchronization with multi-threaded replay. Packets captured in the following order would indicate that threads 1 and 2 executed API calls at roughly the same time, while thread 3 executed its API call after thread 1 and 2 completed their calls:

• Thread 1 Input
• Thread 2 Input
• Thread 2 Output
• Thread 1 Output
• Thread 3 Input
• Thread 3 Output

The replay tool would interpret this to mean that the calls from threads 1 and 2 could be executed in parallel by worker threads, but thread 3's call should not be executed until the other calls complete. Multi-threaded replay would then follow a pattern where it reads an Input packet from the file and dispatches that packet to a worker thread. It would continue reading and dispatching Input packets until it encounters an Output packet. When encountering an Output packet, the dispatch thread would block until the associated worker thread completes its API call and commits any resulting state changes (eg. mappings for newly created handles) before continuing to read and process packets from the capture file.

Some downsides to this approach are that every API call, even calls without return values or output parameters, would need an Output packet, and that it complicates single threaded replay. For single threaded replay, Input packets would need to be queued until the associated Output packet is read. To maintain the proper API call order, queue entries can only be processed when the item at the front of the queue is complete.

Edit 2023-03-30 by @andrew-lunarg

Looks like Dustin did some work on this: dev...dustin-lunarg:gfxreconstruct:dustin_separate_in_out_packets

GFXreconstruct cant replay the trace instead I see an error message that the specified extension does not exist.
But I made the trace on the same machine on which I try replay trace.
Gfxreconstruct I builded from the master branch.

$ ./packaging-work/git/gfxreconstruct/build/tools/replay/gfxrecon-replay gfxrecon_capture_20200214T023654.gfxr 
[gfxrecon] FATAL - API call vkCreateDevice returned error value VK_ERROR_EXTENSION_NOT_PRESENT that does not match the result from the capture file: VK_SUCCESS.  Replay cannot continue.
Replay has encountered a fatal error and cannot continue: the specified extension does not exist

Example trace

Implement a command line utility to trim capture files to a user specified range of frames.

Depends on #182 for tracking API state prior to start of trimmed range of frames.

Add an option to omit buffer and texture data from the capture file. It would not be possible to replay the capture file, but could be useful for other tools that want to analyze captured data without replay, and would significantly reduce capture overhead for these cases.

This should be pretty straight forward to implement for Vulkan: ignore data from mapped memory writes and the vkCmdUpdateBuffer call.

Many environment variables need to be set. A script or better command line interface is needed to make it usable.

Some Vulkan structures have members that the spec says should be ignored by the driver in certain cases. For example, the documentation for VkGraphicsPipelineCreateInfo states the following:

pMultisampleState is a pointer to an instance of the VkPipelineMultisampleStateCreateInfo, and is ignored if the pipeline has rasterization disabled.

The Valid Usage for this value only requires that the pointer be valid when rasterization is enabled. There is no requirement that the pointer be null when the rasterization is disabled.

There is a similar issue with VkWriteDescriptorSet and the pImageInfo, pBufferInfo, and pTexelBufferView members.

The capture layer currently will attempt to dereference and encode data from all pointers that are not null, and could incorrectly attempt to process a pointer containing an uninitialized value. Logic needs to be added to ignore certain pointers based on context.

In addition to the capture issue, there is a replay issue with handle mapping. Replay attempts to map all handles read from the capture file, even if the handle will be ignored based on the context of the API call. When the ignored handle contains an uninitialized value, a warning that handle mapping failed is generated. The replay tool could be updated to ignore mapping for handles that will not be used by the call.

Add a trimming mode to the capture layer, which allows capture to start and stop at user designated frames. Capture could be started stopped with the following:

• A user specified range of frames, provided to the layer at initialization.
• A "hot" key, which toggles capture on and off when pressed.

Depends on #182 for tracking API state while capture is disabled.

Map memory types/heaps from the capture device to the types available on the replay device based on memory properties.

The Linux replay tool currently supports Wayland and Xcb windows/surfaces for replay. When replaying a file, the surface creation calls will be converted to one of the supported replay surface types.

There is currently no way to specify at run-time which of the supported window/surface types should be used for replay. It is determined at compile time, where Wayland is only used if it is enabled and Xcb is disabled at build time.

An option should be added to the Linux replay to tool to specify the surface type to be used.

$ export VK_INSTANCE_LAYERS=xxVK_LAYER_LUNARG_gfxreconstructXX
$ gfxrecon-replay capturefile.gfxr

Get a warning that the capture layer is enabled. It isn't.

The statement at line 47 of replay_settings.h is too general:

if (result.find(kCaptureLayer) != std::string::npos)

Hi,

gfxcon-replay doesn't support selecting the physical device and it always uses the first one.
In a multi-gpu scenario, this doesn't allow to replay traces on the second gpu for example.
Can you add a new option please?
Thanks!

Sub-tasks:

• #7: Child Issue 1
• #8: Child Issue 2

Keep track of resource creation info and other state information that is required to capture a subset of frames. API state information will be written to the start of the capture file before the captured frames. The replay tool will use this information to create resources and setup the API state that is required by the captured frames.

Vulkan object handles will be wrapped and the creation/state info will be stored in the wrapper with the handle.

Replay on Android for captures of apps that use the VK_GOOGLE_display_timing extensions will sometimes fail with error VK_ERROR_OUT_OF_DATE_KHR.

This issue can be reproduced with the Action RPG sample from Unreal Engine.

A document is needed to indicate how the GFX Reconstruct tool is used. A getting started or something...

Support could be added for replaying files from vktrace. The vktrace replay would be performed by a separate file processing module, which would be derived from the current vkreplay code, and would not be able to take advantage of new features provided by the new replay framework, such as multi-threaded replay.

Implement a portability mode when attempting to replay on a system with a different GPU/driver than the capture system. This would include the following:
This feature will be implemented with the following sub-tasks.

• Device selection (#275 )
• Memory Type Translation (#276)
• Swapchain Adjustment (#277)

Differences with device features or extensions would most likely need to be handled at capture time, where the capture layer, or the existing dev-sim layer, could disable any features or extensions that will not be supported on the replay device.

Differences with the number of available queue families and number of queues available per family could potentially be handled on replay with some sort of mapping, but care would need to be taken when consolidating queue submissions from N queues to 1 queue to avoid synchronization issues and ensure submissions are merged in the correct order. It may be simpler to handle this case by using the dev-sim layer to report fewer available queues on capture.