The CPU is expected to start computing the next frame in advance. This is called the "running start algorithm". Actually, if I remember correctly, the CPU is expected to start computing frame N + 2 while the GPU is blocked. When the GPU is unblocked, SteamVR displays frame N while the GPU starts computing frame N + 1 and you have 11ms to do it. Also, the blocking call is expected to be executed about 2ms before the frame is presented, so that's all the "dead time" that SteamVR expects in each frame. (Of course, this doesn't happen in XWA because once the GPU is blocked, the CPU is also blocked.)keiranhalcyon7 wrote: ↑Tue Jun 09, 2020 6:05 amIf SteamVR has to block the GPU, I have to wonder how anything could be expected to get on with (useful) work while it's blocking.
This makes more sense when you see the presentation by Valve. The point is that both the CPU and GPU are fully utilized and busy all the time in this scheme and the blocking call helps sync everything. It makes a lot of sense when you have a multithreaded renderer, but not for XWA at the moment.
Yes, this might work. Again, I need to check if XWA doesn't call other stuff in the meantime (which would cause random crashes). I think other calls, like Begin/EndScene would also have to be buffered, along with the data they use. BTW, I appreciate your suggestions. In the past it's stuff like this that has made me look in interesting directions and then new effects happen afterwards.Hmm... maybe a double buffer? Shunt one to ddraw, and capture any subsequent calls from the engine in the second...
Anyway, I think I've got a fully metric 3D reconstruction now; but it's going to be a while before I rewrite all the VR code and effects to use it. Hopefully, that will fix the distortion that some users have been reporting.