doitsujin
[d3d9] Added functionality to empty WaitForVBlank function.
I imagine it is due to the test being broken that it fixes the test?
It is not possible for us to implement this properly without present timing maybe (or doing something hacky with present wait).
The test:
- calls present
- calls WaitForVBlank which should "Suspend execution of the calling thread until the next vertical blank signal." (https://docs.microsoft.com/en-us/windows/win32/api/d3d9/nf-d3d9-idirect3ddevice9ex-waitforvblank)
- measures time between presents
This is why SyncFrameLatency was added there.
Isn't it good enough solution?
No for two reasons:
- Our frame latency implementation does not use present wait right now. (It is triggered on the present thread when we call queuepresent, not on vblank or TTL)
- The call you are using waits for up to the Max frame latency, not 1.
If the docs are anything to go by, this function doesn't really interact with presents anyway, so even present_wait wouldn't really help. We can't really implement this correctly.
The main problem with this particular implementation is that we'll return immediately if
- the app is CPU-bound
- there is any sort of GPU->CPU sync point between frames (e.g. occlusion queries)
- no presents are queued between calls
I think there's a way to come somewhat close to expected behaviour if we store a CPU-side timer somewhere and do something like this (pseudocode):
auto now = dxvk::high_resolution_clock::now();
auto refreshPeriod = getDisplayRefreshPeriod();
auto vblankCount = (now - m_startTime) / refreshPeriod;
auto target = m_startTime + (vblankCount + 1) * refreshPeriod;
sleep_until(target);
This is going to need some preliminary work though, and may behave weirdly in VRR scenarios.
