[replay] Introduced Assertion breaks Replaying of Some Previously Working Traces

[laurentiu-erhan-arm]

Describe the replay bug:

Previously Working Captured Traces Fail To Replay as a result of commit 6b26889 - "Track image layouts to facilitate FB screenshots". Replaying is failing as a result of the introduced assertion, resulting in the error bellow:

"Assertion failed: 'framebuffer_info->attachment_image_view_ids.size() == render_pass_info->attachment_descriptions.size()'"

The behaviour has been noticed on both Android and Linux machines.

Verify before submission:

• Was trimming enabled?
• • No
• Was replayer renamed if necessary? NO
• • No
• Was --sync used if title is known to need forced synchronization?
• • No

Build Environment:

For capturing an older commit has been used.

For replaying the following commit has been used:

• Branch: dev

• SHA: 6b26889

• Commit Name:Track image layouts to facilitate FB screenshots

To Reproduce
Steps to reproduce the behavior:

1. Get the .gfxr file from [insert download location here, e.g. LunarShare]
2. No specific parameters have been provided when replaying.

System environment:

• GPU and driver version on which capture was taken
• • GPU: NVIDIA GeForce RTX 3050
• • Driver version: 2203910400 (0x835d0100) (Output of gfxrecon-info)
• GPU and driver version on which capture file was replayed with issue
• • GPU: NVIDIA GeForce RTX 3050
• • Driver version: 525.125.06

Title configuration:

• Title name:
• • Hollow Knight (Linux)
• Title version:
• Steam
• • ID 367520
• Is DXR enabled?
• • No

Additional information (optional):

• is there a SHA for which replayer is known to replay correctly? (indicates possible regression in decoder/consumer)

• • Any commit before 6b26889 results in expected behaviour, any commit after results in the assertion being trigger
    Also just commenting out the introduced assertion results in the expected behaviour.
• • The behaviour has also been noticed on an android trace

• Is there an older trace that works? What SHA was used to build those capture DLLs? (indicates possible regression in capture/encoder)

• Does a newer capture work? (indicates bug fix in capture/encoder that needs to be noted)

• Does the capture file replay correctly on a different GPU?

[bradgrantham-lunarg]

My initial, shallow read of the spec is that the number of attachments in the VkFramebuffer needs to match the number of attachments in the RenderPass. (https://registry.khronos.org/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-VkFramebufferCreateInfo-attachmentCount-00876) If that's the case, then either:

1. We have a bug in GFXR and have copied an array or count wrong.
2. The application is using Vulkan incorrectly. We could determine this by running --validate in replay or running the original app with Validation Layers enabled. If that's the case we can attempt to catch it as a special case if we determined this is an "important" capture.

It could also be that I've read the spec incorrectly or there's an additional qualifier for dynamic rendering or some other extension and this is valid usage and we need to handle the case where the count is different.

[davidd-lunarg]

PR #1260 adds tracking render pass image layouts for vkCreateRenderPass2 and it should resolve this issue.

[laurentiu-erhan-arm]

Everything seems to work as expected now. Thank you. I will close the issue.