Option to Report Only Family 0, Queue 0 at Capture

[andrew-lunarg]

Some users would like slightly more portable traces than we capture by default.

Many implementations have a single queue family with often a single queue in it that is used for all types of work.

When capturing on a restricted implementation like this, we have a reasonable chance of replay on a different implementation with a more diverse set of queue families as they tend to have their most capable family be at index zero, so a trace using family zero, queue zero maps across very well.

When capturing on an implementation with many queue families, where the engine is written to make use of them, the resulting capture cannot replay on an implementation with a different configuration of queues unless the capabilities of the queues used accidentally happen to be supported by the queue families and queues within them at the same indexes.

Since most implementations have at least one queue in queue family zero that has most capabilities that most applications depend on for non-optional features, and since most applications have the ability to work with a single queue to be able to target implementations that only expose one queue, if gfxr's capture layer had an option to expose only the first queue of the first family, captures made on any implementation with that option enabled would have the greatest chance of cross-implementation portable replay without requiring a sophisticated queue remapping / virtualisation feature within gfxr.

The feature suggested here would be turned on by an environment variable:

• Name: GFXRECON_QUEUE_ZERO_ONLY
• Type: BOOL
• Default false

The traces that resulted from capture with this option would not be useful for workload characterisation of a particular application on particular hardware, but they could represent a substantial stream of Vulkan commands, including leading edge rendering algorithms with multiple passes and compute, that painted the expected colours to the final frame.

Separating this out from #856 as the core of that is a more complex problem that can be pursued in parallel, while this is a one-day PR affecting only the capture layer that could be used in the meantime and would be no burden to support over time.

[locke-lunarg]

The first idea is to modify queue family setting to only zero on CreateDevice and return only zero of queue family on GetPhysicalDeviceQueueFamilyProperties during capturing, and then hopefully, the game's program will use the queue 0 for the whole tasks. This idea only works for the first time capture from a game. Recapture doesn't work.

[andrew-lunarg]

Recapture doesn't work.

Yes, when I wrote "recapture them" in issue #1090 I meant repeat the capture from the application. My mistake for not spotting that I'd used a term we have a specific technical meaning for in this project :disappointed:. I realise that's not much help when debugging a trace pulled off a drive and made by somebody else :-/.

[locke-lunarg]

Because @bradgrantham-lunarg left an idea in PR #1129, reopened it. We might consider this idea in the future. https://github.com/LunarG/gfxreconstruct/pull/1129#discussion_r1207191770