Giter VIP home page Giter VIP logo

gfxreconstruct's Introduction

Project Components

The GFXReconstruct project provides tools for the capture and replay of graphics API calls, allowing the graphics commands executed by an application to be recorded to a file that may later be replayed to reconstruct the graphics-specific behavior of the captured application. The replay code has been organized with a framework design to make it easy to create additional tools for processing capture files.

The GFXReconstruct components currently provided with this repository are:

  • The VK_LAYER_LUNARG_gfxreconstruct Vulkan layer for capturing Vulkan application commands.
  • The D3D12 capture libraries for capturing D3D12 application commands.
  • The gfxrecon-replay tool to replay GFXReconstruct capture files.
  • The gfxrecon-info tool to print information describing GFXReconstruct capture files.
  • The gfxrecon-compress tool to compress/decompress GFXReconstruct capture files.
    • NOTE: The gfxrecon-compress tool requires LZ4, Zstandard, and/or zlib, which are currently optional build dependencies.
  • The gfxrecon-extract tool to extract SPIR-V binaries from GFXReconstruct capture files.
  • The gfxrecon-convert tool to convert GFXReconstruct capture files to a JSON Lines listing of API calls. (experimental for D3D12 captures)
  • The gfxrecon-optimize tool to produce new capture files with improved replay performance.

Contributing

If you intend to contribute, the preferred work flow is for you to develop your contribution in a fork of this repo in your GitHub account and then submit a pull request. Please see the CONTRIBUTING file in this repository for more details

Building

Instructions for building the contents of this repository can be found in the BUILD.md documentation.

Usage

Instructions for using the GFXReconstruct capture and replay tools can be found at the following locations:

License

This work is licensed under the terms of the MIT License; see LICENSE for more information.

Appropriate Use

GFXReconstruct is a suite of tools intended for the purpose of improving application and platform quality by allowing the analysis of capture and replay of graphics command streams. Use cases include, for example, regression testing, silicon and platform bringup, and reporting bugs. Using GFXReconstruct to extract assets from an application or game for which you don’t have an appropriate license may violate copyrights or software licenses.

gfxreconstruct's People

Contributors

andrew-lunarg avatar bartosz-muszarski-arm avatar beau-lunarg avatar bradgrantham-lunarg avatar charles-lunarg avatar christophe-lunarg avatar davidd-lunarg avatar davidlunarg avatar dsmolars avatar dustin-lunarg avatar etang-cw avatar fabian-lunarg avatar feimao-gfxr avatar greg-lunarg avatar igorbrsn avatar jerryamd avatar joey-lunarg avatar locke-lunarg avatar marius-pelegrin-arm avatar marky-lunarg avatar mikes-lunarg avatar mizhen avatar naomipappe avatar nickdriscoll-lunarg avatar panos-lunarg avatar patrickpurcell avatar per-mathisen-arm avatar rurra-amd avatar xooiamd avatar xykivo avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

gfxreconstruct's Issues

Add Support for Current vktrace Files

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.

gfxrecon-toascii needs to support arbitrary path

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).

errors and warnings when replaying AMD Pro traces

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

need a pylintrc 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.

Two Nvidia games seg faulting on replay

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/

Warning on capture layer being enabled during replay is incorrect

$ 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)

Include Codegen in CMake Build Definition

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.

Omit/Ignore Values Based on Context

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 functionality to capture images

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.

Add Replay Overrides for Functions that Retrieve Array Sizes

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.

Add Options for Page Guard

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)

Implement Portability Mode: Swapchain Adjustment

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.

Add Option to Omit Resource Data from Capture

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.

warnings go to stdout, not stderr

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%$

Android Replay Failing with VK_GOOGLE_display_timing

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.

Allow to select the physical device with the replay tool

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!

generate_vulkan.py reorders methods and structs in generated_* files causing compilation failure

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;
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

How to Documentation

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

more details in gfxrecon-toascii

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.

Important API Features Not Currently Supported for Trimming for 1.0

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.

Implement State Tracking for Trimming

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.

Improve Resource Upload for Trim Replay

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.

gfxrecon-replay crashes on a trace of vulkaninfo

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 ()

Replay Issue with Debug Callbacks

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

Implement Portability Mode

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.

Add renderdoc frame export

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

AMD RX580 Dota2 trace doesn't trim correctly to frame 30

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

Implement Trimming Support

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)

Split API Call Block into Separate Pre/Post Call Blocks

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

Support Multiple Surfaces Types for Linux Replay

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.

Deprecation of vktrace/vkreplay

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.

compress output doesn't end in newline

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%$

compress from LZ4 to ZLIB appears to succeed but results in bad file

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%

screenshot and gfxreconstruct have different frame number conventions

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.

GFXreconstruct cant replay the trace (specified extension does not exist)

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

linux loader segfault while replaying gfxrecon traces

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.

Add Linux Command Line Option for Replay Window/Surface Type

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.

Implement Trimming in the Capture Layer

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.

Implement a Trimming Utility

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.