Description
When running the vulkan2 implementation of hello_xr, the program thread execution gets blocked for about 5ms when RenderView() is called the first time in a frame. The Function calls m_cmdBuffer.Wait() which is supposed to wait on the fence set in the previous frame. It should return instantly since the frame should already be rendered, but for some reason it doesn't. This causes the application to miss the optimal xrEndFrame timing, and in an application with an actual GPU workload, it would likely cause a missed frame.
I'm not sure if this is an issue in the application, or if it's caused by something else. Regardless, it seems that blocking on GPU work from the previous frame is a bad practice to teach, since it would break the CPU -> GPU pipelining in a real workload. RenderView() is also run twice per frame, once for each eye. It blocks until the GPU has rendered the first eye before rendering the second (interestingly this does not block for a significant time). A best practice would probably be to have a set of command lists for each swapchain image, with either one list per eye or handling both eyes in the same submission.
Tested on a Valve Index using SteamVR 2.9.5 under Windows 10.
Trace from Nvidia Nsight Systems
