Blur Busters Forums

RealNC wrote:

Chief Blur Buster wrote:Also, be warned, there may exist games that may have a momentum lag for strafing/etc. That, along with low-resolution of current cheap high-speed cameras, can make benchmarking difficult.

Fortunately, in CS:GO you ban bind mouse keys to "look left/right", which should not be affected by anything.

Yep. That too. The best fast-responding action needs to be benchmarked.

Although, that said, sometimes benchmarking muzzle flashes (random lag included) is helpful to some competition gamers wanting to reduce lag between button and kill -- all game physics engine included including randomized gunpowder ignition algorithms and such....

So ultimately, it'd be nice to standardized benchmark maybe 3 different kinds of game responses (fastest response behavior, kill lag behavior, movement lag behavior). Once high speed cameras becomes widespread in smartphones and analysis software makes it much easier to, perhaps automate some of this benchmarking and generate reliable averages (over 100 runs!)

Since I'll be solely looking for differences in input latency between syncing methods (specifically against G-SYNC) and their interaction with framerate limiters for the upcoming entry in my ongoing article, mapping the left click to "look" for my input latency re-tests appears to be the way to go to then.

After I'm finished with this G-SYNC 101 series, it may be worth looking into covering various aspects of input latency that aren't specifically related to G-SYNC, however.

This is what i used to test mouse1 +right.

http://i.imgur.com/SaiZ36z.png

http://www.mediafire.com/file/s7qslggml ... _flood.zip

https://youtu.be/HasevyKpm18?t=7s


Tons of fps and easy to measure.

I was hoping to see an input lag comparison between borderless vs. exclusive fullscreen mode while using g-sync but it seems that no one has even discussed this yet. Remarkably, if g-sync completely overrides desktop v-sync as claimed and introduces no input lag in comparison to exclusive mode that would actually be the #1 selling point of it for me. Past Windows 7, there's no other way to play competitive games in windowed/borderless mode without extra input lag (that I know of).

Good idea @swarna, I will include that scenario in my upcoming input latency re-tests.

swarna wrote:I was hoping to see an input lag comparison between borderless vs. exclusive fullscreen mode while using g-sync but it seems that no one has even discussed this yet. Remarkably, if g-sync completely overrides desktop v-sync as claimed and introduces no input lag in comparison to exclusive mode that would actually be the #1 selling point of it for me. Past Windows 7, there's no other way to play competitive games in windowed/borderless mode without extra input lag (that I know of).

I think the difference is minimal, my bet is there might be a few milliseconds of additional latency because it has to be processed through the DWM? I cannot notice it though.

swarna wrote:I was hoping to see an input lag comparison between borderless vs. exclusive fullscreen mode while using g-sync but it seems that no one has even discussed this yet. Remarkably, if g-sync completely overrides desktop v-sync as claimed and introduces no input lag in comparison to exclusive mode that would actually be the #1 selling point of it for me. Past Windows 7, there's no other way to play competitive games in windowed/borderless mode without extra input lag (that I know of).

G-Sync does NOT override DWM vsync. It only overrides the composition frame rate.

By default, DWM will composite all windows at a frame rate that matches the display refresh. With G-Sync, DWM will do composition at the frame rate of the currently focused application.

DWM still has at least 1 frame of input lag because composition is still happening. (Composition is the combination of all application output into a final image, which happens into a separate buffer.)

This has been documented by Tom Petersen in his windowed mode G-Sync interview.

RealNC wrote:DWM still has at least 1 frame of input lag because composition is still happening. (Composition is the combination of all application output into a final image, which happens into a separate buffer.)

This is very true, but this should not need to exist anymore.

Technologically, in a properly designed OS compositing pipeline, DWM lag can be made to become as little as ~0.25 or 0.5ms on modern NVIDIA/Radeon GPUs.

I wish Microsoft would get with this program (if they haven't already started making moves towards reduced-lag compositing).

Today, modern GPU's now and enough memory throughput to composite multiple 2D framebuffers into a single framebuffer in less than 1 millisecond now -- theoretically it could now be all completed in the middle of a blanking interval --

There are new compositing algorithms that allows sub-frame-lag compositing even on older 8-year old Intel GPUs (e.g. 1/4th frame lag) -- just enough margin to give time for compositing overhead while retaining the same fluidity. It could be dynamically calibrated based on GPU performance. A GTX Titan can composite a bunch of framebuffers into one frame in just mere hundreds of milliseconds -- you could literally squeeze compositing into the blanking interval between refresh cycles!

From rendering workflow basis on an unpredictable-performance GPU, it is much easier to just double-vsync it -- the application then the compositing (vsync the application for proper application fluidity, then vsync the compositing for proper compsositing fluidity). When in reality it could nowadays be single-vsync'd with just a small renderahead margin, to get the same application fluidity AND compositing for just barely more than one wait-for-vsync delay nowadays.

One lower-lag DWM compositing algorithm (for VSYNC ON gaming) is a virtualized VSYNC trigger that triggers 1 millisecond ahead of the real VSYNC. This allows the game (VSYNC ON) to flip the buffer which is then immediately composited and delivered to the monitor on time for the real VSYNC. In a modernized DWM API of any new OS running on Titan-league GPUs, all applications should deliver their framebuffers for DWM compositing approximately 1ms before the real VSYNC. Goodbye DWM lag. This is much better than the 1-additional-frame-lag added by double-VSYNC over VSYNC.

For chrissakes, there are web browsers with 1 frame less lag on Mac than on Windows 10! Apple already does low-latency compositing with their iDevices to reduce touchscreen lag between finger & scrolling.

I really look forward to jorim's benchmarking of latest drivers on GSYNC in fullscreen -vs- bordered windowless mode. Now that jorimt is writing the Blur Busters GSYNC 101 series, he now finally has one computer mouse modifications for input-lag-testing of G-SYNC via high speed camera, so he's now armed and dangerous -- I'm now very curious to see whether Microsoft+NVIDIA has yet successfully eliminated the technologically solvable 1-frame-penalty for windowed GSYNC mode. Eventually they should solve that, technologically that lag doesn't need to be there. DWM makes it more complicated, but intrisinically it is not unsolvable.

Chief Blur Buster wrote:I'm now very curious to see whether Microsoft+NVIDIA has yet successfully eliminated the technologically solvable 1-frame-penalty for windowed GSYNC mode.

As am I.

I'm glad @swarna brought it up, else I wouldn't have thought to test it this time around; I rarely use the option, and play most games in exclusive fullscreen, but it is a valid scenario regardless, and should be tested.

We'll find out soon enough.

I'd assume MS has done nothing in this respect, otherwise they wouldn't have introduced the "independent flip mode" in DX12. It's a windowed mode where the output is not composited.

Windows Store games aren't allowed to use exclusive fullscreen. So to counter DWM's latency, they added this borderless windowed mode that behaves like exclusive fullscreen but isn't. There would be no need for that special mode if DWM was doing low-latency compositing.