Frame skips/reuses with most monitors?

[SubstantialCt8690]

Thanks a lot for the idea. The topic has been moved here:
https://forums.blurbusters.com/viewtopic...1240e84a3a

(02-09-2024 03:04 AM)ToastyX Wrote:  I still think it's a scheduling issue, so vsync might cause a missed refresh if the CPU happens to be busy with something else. The only way I can think of to get around this is to disable vsync, and then busy wait and time the vsync yourself using D3DKMTGetScanLine or some other method to determine where the refresh is happening, but this will waste CPU cycles on one core.

He talks about this stuff in his beam racing threads, which require precise timing to pull off:

https://forums.blurbusters.com/viewtopic...=22&t=3972
https://forums.blurbusters.com/viewtopic...=22&t=4213

We have checked all the interfaces we're aware of that the OS, graphics API and the GPU manufacturers provide. There may be something we missed still, but not really sure what else to try here.

- Used win32 methods to set the process and thread priorities and power management plans.
-Used DXGI,D3D11,D3DKMT and NvAPI methods to set graphics device priority levels to maximum and use methods such as D3DKMTGetScanLine to determine the precise vsync blanks.

OS methods resulted in micro differences or caused much bigger problems with the scheduling. For example setting the thread priority to REAL_TIME was actually making the scheduling worse by overshadowing critical parts of the OS.
Other graphics related methods also resulted in micro changes and no macro changes was observed.

So we are at a point where we have exhausted the interfaces we've been able to find provided to us by the lower level systems such as OS and graphics api drivers. It's highly likely that OS or graphics device/driver misses synchronization point between them due to OS scheduling. However not sure how to solve that.

Specifically D3DKMTGetScanLine gave us some hope but it has problems. The scanlines were different from setup to setup. Giving manual offset solves this problem up to point where the tearing is visible at the bottom of the screen sometimes. Other problem is that we should be also handling the rasterization offset per setup. It seems the D3DKMTGetScanLine precision changes from device to device and driver implementation to driver implementation, this leads to the responsibility of having all the driver/device combination offsets right.