[d3d11,d3d9,util] Add a config option for reproducible VK output

[werman]

It ensures that for the same D3D commands the output VK commands don't change between runs.

Useful for comparative benchmarking, can negatively affect performance.

---

To fully test it I'd need to disable all threading and compare runs with api dump layer. For now, what was compared are renderpasses after d3d11 translation - they are the same between runs.

When reproducibleCommandStream is not set the number of draw calls in renderpass and even the number of renderpasses may vary, which makes hard to make comparisons between runs, especially on GPUs where renderpasses do matter.

[doitsujin]

Why are the thread syncs in ConsiderFlush necessary? We should get consistent behaviour simpy by adjusting the heuristic.

The specific implementation also massively inflates the actual submission count compared to a GPU-bound scneario; if anything I feel like we'd want to do the opposite and minimize submission counts to get more realistic performance characteristics, i.e. something like

if (m_ensureReproducibleHeuristic && flushType != GpuFlushType::ExplicitFlush)
  return false;

switch (flushType) {
  ...

This will break real games that don't use queries correctly (Fallout 4), but should generally be fine for replaying traces and captures since readback isn't really a thing there anyway.

[werman]

I feel like we'd want to do the opposite and minimize submission counts to get more realistic performance characteristics

You are right, we should expect GPU bound scenario and that means there is no pressure to submit earlier, meaning most likely submit would happen only at GpuFlushType::ExplicitFlush.

Why are the thread syncs in ConsiderFlush necessary? We should get consistent behaviour simpy by adjusting the heuristic.

Without it there were differences in VK commands when looping the same frame, probably caused by different current chunk id. However, if we flush only on ExplicitFlush - there is no need to sync.