Expose GetBlockIndexGFXR() from capture layer

[panos-lunarg]

GetBlockIndexGFXR() returns the current block index being processed by the capture manager.

[ci-tester-lunarg]

CI gfxreconstruct build queued with queue ID 2998.

[ci-tester-lunarg]

CI gfxreconstruct build # 2793 running.

[ci-tester-lunarg]

CI gfxreconstruct build # 2793 passed.

[ci-tester-lunarg]

CI gfxreconstruct build queued with queue ID 3620.

[ci-tester-lunarg]

CI gfxreconstruct build # 2797 running.

[ci-tester-lunarg]

CI gfxreconstruct build # 2797 passed.

[ci-tester-lunarg]

CI gfxreconstruct build queued with queue ID 4671.

[ci-tester-lunarg]

CI gfxreconstruct build # 2798 running.

[ci-tester-lunarg]

CI gfxreconstruct build # 2798 failed.

[ci-tester-lunarg]

CI gfxreconstruct build queued with queue ID 6312.

[ci-tester-lunarg]

CI gfxreconstruct build # 2809 running.

[ci-tester-lunarg]

CI gfxreconstruct build # 2809 passed.

[locke-lunarg]

The code looks good to me. Could you please give me some examples of where we will need the capture block index? How is the purpose different from the decoder block index? Thank you.

Plus, this capture block index is different from the decoder block index since the capture includes system code, but the decoder has only Vulkan code. Should we care about it? My consideration is if the difference will confuse users or not.
Sorry. The decoder also includes system code, so it looks the capture block index matches the decoder block index. Right?

[panos-lunarg]

This change is needed for the perfetto layer (https://github.com/panos-lunarg/GFXR_layers). The perfetto layer is basically a vulkan layer that queries the current block id (by calling the GetBlockIndexGFXR function from the capture layer) and emits it to perfetto.

I am not sure what you mean with system code but with this change the vulkan capture manager should generate the same block ids as the file processor as it parses the file. So the block ID should be the same when capturing and when replaying

[locke-lunarg]

System code I mean something aren't Vulkan function calls. It doesn't matter. LGTM.

[locke-lunarg]

I'm thinking that could we write this block index to the file? So the decoder could just read the block index to ensure both have the same block index. The decoder won't count it by itself.

[panos-lunarg]

I am not sure if it's worth it. We can't store the id in the block header without breaking backward compatibility, so we'll have to store it as a metadata? This would essentially double the blocks written to the file.
Can you think of a better way?

[locke-lunarg]

You are right. We shouldn't break backward compatibility.

[bradgrantham-lunarg]

This looks pretty good to me. Later we can consider whether this should be exposed through some kind of "LUNARG" Vulkan extension, maybe even make it generic like VK_LUNARG_get_tooling_marker or some such.

[ci-tester-lunarg]

CI gfxreconstruct build queued with queue ID 4799.

[ci-tester-lunarg]

CI gfxreconstruct build # 2963 running.

[ci-tester-lunarg]

CI gfxreconstruct build # 2963 passed.