Stutter Stutter or Smooth as Butter

[jimortality]

Brands Hatch especially, even in practice screen stutter. I think it's not just me and maybe down to the unreal engine? I've tried all different things so if you're smooth as Butter, please post your settings and how you're eliminating it. Thank you.

Acer Predator X34p
I 7-6700k
Nvidia 1080ti
16gb Ram a lam.
And not forgetting my brand new Master Cooler 212 Evo

 

[Neilski]

Nice!
Not sure if I mentioned before, but I had to edit the controls.ini by hand to get AC to use numlock for shifting:

[GEARDN]
JOY=0
BUTTON=5
KEY=0x90; numlockihope
XBOXBUTTON=X

I still haven't yet done it with ACC myself, or indeed the frame rate limiter at a tiny bit less than the monitor refresh rate, because my phone was driving me totally nuts with the short recording time. After something like 12 videos in a row where I didn't capture the event, I gave up in disgust and tried to buy a cheapo GoPro clone to do at least 120fps. tl;dr: I got one but they lied (30fps, ffs).

Have now bought a couple of cheap photodiodes and am in the process of trying to persuade my sound card to record the light-level transients so I can measure the delay with high accuracy for peanuts. Looks like it's gonna work nicely, but the software layer is my next hurdle...

 

[RasmusP]

Nice!
Not sure if I mentioned before, but I had to edit the controls.ini by hand to get AC to use numlock for shifting:

[GEARDN]
JOY=0
BUTTON=5
KEY=0x90; numlockihope
XBOXBUTTON=X

I still haven't yet done it with ACC myself, or indeed the frame rate limiter at a tiny bit less than the monitor refresh rate, because my phone was driving me totally nuts with the short recording time. After something like 12 videos in a row where I didn't capture the event, I gave up in disgust and tried to buy a cheapo GoPro clone to do at least 120fps. tl;dr: I got one but they lied (30fps, ffs).

Have now bought a couple of cheap photodiodes and am in the process of trying to persuade my sound card to record the light-level transients so I can measure the delay with high accuracy for peanuts. Looks like it's gonna work nicely, but the software layer is my next hurdle...

Aaah the gold old numpad key hex codes. I have good memories at creating buy-scripts for one-key-buying equipment in counter strike 1.6 with my friends.
I should have a txt file created by myself with explanations after I got it all done from 2005 or something haha

Wow to the photo diode thing! That sound very interesting!

 

[RasmusP]

I finally did some tests. Grabbed the iPhone 8 from someone and did some 240 fps videos. Due to my tenkeyless keyboard with external usb-numblock I needed to map a number key for upshift.
I pushed the num-key and the 7-key as synced as I could. Basically slammed them to minimize the timing difference.

Results:
AC is completely synced comparing the cockpit-display, gears app and sidekick app. I have AC limited to 60 fps / 60 Hz. Gsync active.

Did multiple upshifts, here are the results. I went frame for frame in vegas and marked the last and first frame before/after the numpad-light and upshift.

7-9 ; 11-13 ; 16-18 ; 13-15 frames.
Average: 12.75 frames

Windows text editor is pretty identical at 100 Hz:
14-16 ; 9-11 ; 13-15 frames
Average: 13 frames

At 240 fps the calculation is pretty simple but I write it down anyway:
1/240 * frames = xx seconds

Time between camera frames is 4.2ms so accurately enough I'd say in relation to my results.

AC min = 29.2 ms
AC max = 75.0 ms
AC average = 53.1 ms

Windows min = 37,5 ms
Windows max = 62.5 ms
Windows avg = 54.2 ms

From my view I'd say the average is pretty much what it really is as my key hits were probably a bit de-synced.
I first wondered that the input lag wasn't lower at 100 Hz instead of 60 Hz but then I remembered that my monitor, according to tft central has an input lag of 3-4 ms.
So the lag would only become more consistent with a frame to frame time of 10ms instead of 16.67 ms.
This is visible in my test results but it's probably just my fingers...

Looking at my measurments, these roughly 7ms don't make a difference...

I'll try to measure ACC tomorrow! Didn't start it since months...

I did the same procedure with ACC, I made sure to really SLAM the numpad + 7 button this time (good thing about this is that I mapped 7 to upshift and home to downshift so I'm shifting back and forth).

Did 8 measurements:
14, 15, 15, 15, 15, 14, 13, 14 frames

Again all summed up, divided by 8 and then divided by 240.

Result: 60ms so within margins of error compared to AC.

Quite amazing to see what how my monitor and gsync perform on paper. I'm not sure if the cockpit-ingame-wheel has some lag though but at least the shifting cockpit display has no lag!

I'll try to do some testing without gsync and no other sync and at 100 fps / 100 hz in AC while alone on track to see what's the absolute minimum my system can reach.

I just though I'd upload my test video. The iPhone 8 thankfully makes the 240fps videos longer and 30fps so you can watch them on any player.

 

[DrRob]

Maybe a stupid question and not trying to take away any of your efforts, but does it really make sense to measure lag by gear shifting lag to keyboard input?

These gearboxes should have a lag in response in real life, too. There is no instantaneous change in gears when hammering the paddle with these pneumatic operated sequential boxes. At least this is what I would expect.
Anyone know the "real" lag on this operation? I suppose the ingame lag of shifting is not deliberately put in, right?

 

[RasmusP]

Maybe a stupid question and not trying to take away any of your efforts, but does it really make sense to measure lag by gear shifting lag to keyboard input?

These gearboxes should have a lag in response in real life, too. There is no instantaneous change in gears when hammering the paddle with these pneumatic operated sequential boxes. At least this is what I would expect.
Anyone know the "real" lag on this operation? I suppose the ingame lag of shifting is not deliberately put in, right?

I thought the same and with some cars you do have shifting time. In ac for example when you select auto clutch and use a old roadcar. Mx-5 miata or something like that.

The hud will instantly change the number on key press but you'll hear the gear being put in slowly.

So I'd say that's the best measuring method we can do with simple methods.

However I'll try to do some wiggling on my wheel and try to mark the frames where my real wheel changes direction and when the in game wheel does.

It was some quick work yesterday and today when I had some short moments with nothing going on hehe

 

[Neilski]

The iPhone 8 thankfully makes the 240fps videos longer and 30fps so you can watch them on any player.

Wow, nice video quality!
Btw, I can't figure out why it sometimes upshifts and sometimes downshifts - can't see your fingers changing position in the video
Also, one shift jumps from 4th to 6th in one hit which is a bit freaky

Result: 60ms so within margins of error compared to AC.

I'm a bit puzzled about the very small range of lags you measured. I'd have expected (given that you were using sync)[edit: oops, sync is irrelevant] the lag to have a peak-peak range of one video frame (just under 17 ms at 60 Hz). You got roughly half that range on the ACC tests, and 8 points sounds like enough to make that fairly improbable if there's no syncing going on. I can't imagine why the numlock LED would be synced up with the video refresh, even a little bit, but it's a bit odd anyway. Your AC measurements had more scatter but you seemed to be putting that down to a measurement/finger-movement thing...

does it really make sense to measure lag by gear shifting lag to keyboard input

Yeah, good question. I think the best we can hope for is to put an upper bound on the "deliberate" lag. My measurements were done in AC and without vsync, I saw lags of as low as 17 ms so I think the AC "deliberate" lag is pretty low. ACC may differ of course, and I look forward to measuring it on my own rig to compare with the other ACC measurements we've had.
If there's another "easy" way to invoke an instant response from the car (maybe switching on headlights?) then that might also be worth trying. I will give it some thought. Suggestions welcome!
Fundamentally though, my AC lag went down from around 90 ms to more like 25 ms, and that reduction is a big win no matter what. If AC imposes (say) 10 ms of deliberate lag - so little it would be pointless anyway - then my "real" input lag would have gone down from 80 ms to 15 ms, which is of course even better...

However I'll try to do some wiggling on my wheel and try to mark the frames where my real wheel changes direction and when the in game wheel does.

Yeah, I'm keen to hear if that's any different. I can't really try do the wheel-wiggling thing easily (naff camera). Am relying on my photodiodes to rescue me, lol.

AC is completely synced comparing the cockpit-display, gears app and sidekick app. I have AC limited to 60 fps / 60 Hz. Gsync active.

Btw, I went back and checked the Sidekick source code (or at least the version I currently have). It only updates the gear indicator at 30 Hz, so maybe you just got lucky
I checked out the pricing on Vegas btw - ouch! I think I'll stick with the free (and naff) video editor built into Windows 10

 

[Neilski]

Update: I have just remembered that I use a (now rare?) PS/2 keyboard. These behave a little differently to USB keyboards in some respects (interrupts vs. polling, etc.) but maybe not enough to influence the results.

Another fun fact is that I had somehow convinced myself years ago that PC keyboards (or maybe just the PS/2 variety) only relied on the OS to set some of the LEDs, but not all. In particular I thought the numlock LED was controlled by the keyboard itself (which is one reason why I was so keen to use it for these tests). I can't now find any evidence of that though, so I guess it's not true.
I originally formed that conclusion, I think, by observing keyboards when the PC had hung (hard) - some LEDs froze, and others didn't. It's all too long ago though now, and thankfully (LOL) I haven't had a freeze for ages. Will maybe have to generate one so I can check!

 

[RasmusP]

Btw, I can't figure out why it sometimes upshifts and sometimes downshifts - can't see your fingers changing position in the video
Also, one shift jumps from 4th to 6th in one hit which is a bit freaky

I'll quite myself:

I made sure to really SLAM the numpad + 7 button this time (good thing about this is that I mapped 7 to upshift and home to downshift so I'm shifting back and forth).

On my USB numpad, 7 and home are the same button but switch function when numlock is pressed or not. In theory I should shift up and down. Instead the games seem to get confused when 7 gets pressed, "held down" and then numlock switches the function while the button is pressed.

I need to repeat the ac test with better key slamming hehe.

About gsync input lag:
As far as I know for my configuration there are the following buffers involved:
1. No prerendered frames? Can't find info on this but setting it to 1 or 3 didn't make a difference for my feel.. Gonna need to test it at some point with the iPhone...

2. Rtss fps limiter: it helds back the cpu afaik? So there's at least 1 frame lag

3. Not really a buffer but due to having Nvidia vsync activated, according to blur busters the gpu waits for the monitor to be done displaying the full frame.
If my gpu fps drop to 30 for 1 frame and then go up to 100 fps for the next frame (33.3ms and 10ms of course), the second frame might be shoved into the monitor before the first frame displaying had reached the bottom row.

4. No idea about how the buffers and gsync work.. I'd say there's 1 frame lag to sync it all somehow but not sure..

I really need to test gsync at 100fps/hz and without gsync.

No idea when though but the acc test was pretty quick work

 

[Neilski]

On my USB numpad, 7 and home are the same button but switch function when numlock is pressed

Ahhhhhh, the penny drops - I wasn't looking at the numpad... Nice one!

prerendered frames? Can't find info on this but setting it to 1 or 3 didn't make a difference for my feel

Try 20 - when I set it really high in AC it made a very big difference

Rtss fps limiter: it helds back the cpu afaik? So there's at least 1 frame lag

I can't claim I understand the fps limiting stuff but my memory is that it's supposed to reduce the lag by preventing the CPU from fetching the events and getting on with rendering a new frame. My hand-wavy explanation would be that the reduction is because the CPU checks at the last possible moment for input, reducing (at least the best-case) gap between an input event and a change on screen.

If my gpu fps drop to 30 for 1 frame and then go up to 100 fps for the next frame (33.3ms and 10ms of course), the second frame might be shoved into the monitor before the first frame displaying had reached the bottom row.

Surely not, because your monitor is capable of 100 Hz (more than that in fact) so that the transfer of the frame must take less than 10 ms. I might be misunderstanding your point tho.

 

[Case_]

Wish I had this kind of "test setup". I am kinda wondering if the lag may be different for shifting and for steering. I've done my tests with steering, always. And it would also be interesting to see if there's a different lag for when the wheels respond and when the virtual wheel responds, like some seemed to have suggested.

 

[RasmusP]

Try 20 - when I set it really high in AC it made a very big difference

Argh, I forgot... Next time I'll do a proper test plan and not jump onto my wheel while actually hanging my wetsuit out to dry but my gf approaching me "you wanted me to record something? Now or some other day"...

I can't claim I understand the fps limiting stuff but my memory is that it's supposed to reduce the lag by preventing the CPU from fetching the events and getting on with rendering a new frame. My hand-wavy explanation would be that the reduction is because the CPU checks at the last possible moment for input, reducing (at least the best-case) gap between an input event and a change on screen.

To be honest I have no clue... Afaik it's basically "holding one frame back". I didn't bother understanding it in depth but I remembered: 1 frame input lag compared to no limiter.

Surely not, because your monitor is capable of 100 Hz (more than that in fact) so that the transfer of the frame must take less than 10 ms. I might be misunderstanding your point tho.

Looking at the 240 fps video I can't see my monitor refreshing the image so yeah I guess you're right. Anyway blurbusters say you should do it so I do it. Doesn't do any harm either and my limiter might screw up, it would run into vsync

 

[Neilski]

To be honest I have no clue... Afaik it's basically "holding one frame back". I didn't bother understanding it in depth but I remembered: 1 frame input lag compared to no limiter.

Yeah, I guess it must add some lag relative to no sync at all. I think I was thinking whether or not it added lag relative to... umm, something else maybe, lol, not sure!

 

[RasmusP]

For Neil to have a read:

G-SYNC 101: Optimal G-SYNC Settings & Conclusion | Blur Busters

Many G-SYNC input lag tests & graphs -- on a 240Hz eSports monitor -- via 2 months of testing via high speed video!

blurbusters.com

Thought it's worth splitting posts:
My steering wheel comparison data:

I wiggled the wheel as fast and harshly as I could

AC, 60 fps, 60 hz, gsync:
3x 8 frames lag, stopped after 3x as it seems completely consistent.
This means 33.3 ms lag

ACC, 60 fps, 60 hz, gsync:
19 ; 14 ; 15 ; 16 ; 16 ; 15 frames
avg = 16 frames
This means 66.6 ms lag

Comment from my gf while recording "oh yeah it's visible in that second game!".
Says it all, doesn't it?!

At the end you find the side by side slow-mo video of AC vs ACC.

Other results:

AC, 100 fps, 100 hz, gsync:
8 ; 7 ; 7 ; 8
To be honest it looked a little smoother but the lag seems to be the same... Or maybe it's 1 frame less.

AC, 130+ fps, 100 hz, no sync, no limiter:
7 ; 8 ; 7, stopped looking...

Guess the input lag, apart from the length of the buffered frames, which seem to be... 1? for Gsync, stays the same.
So at 60 fps you get input lag +/- 16.6ms and at 100 fps you get input lag +/- 10.0 ms.
Which makes a difference of 6.6ms.
At 240 fps one frame is about 4 ms so it makes sense that 100 hz hit 7 camera frames of lag more often than 60 hz do.

I don't understand why no sync doesn't get quicker though but maybe it's just 1 frames and I can't nail the point of movement return from the wheels accurately enough?

Anyway the input lag of ACC is a LOT higher. I uploaded the side by side video at 2x playback speed at therefore 60 fps instead of 30 fps. Which means overall it's just 4x slow-mo and not 8x.

You can see the difference a lot better with 4x and 60 fps

 

[Neilski]

Anyway the input lag of ACC is a LOT higher.

Wow, it is indeed!
What do you have MAXIMUM_FRAME_LATENCY set to in AC? Is there an equivalent in ACC?

I'm also confused about the lack of improvement with no sync. (Meanwhile I'm still working on my own measurement setup - buggering about with software at present. Taking a little longer than anticipated...)

 

[RasmusP]

Wow, it is indeed!
What do you have MAXIMUM_FRAME_LATENCY set to in AC? Is there an equivalent in ACC?

I'm also confused about the lack of improvement with no sync. (Meanwhile I'm still working on my own measurement setup - buggering about with software at present. Taking a little longer than anticipated...)

I have the setting in ac at -1, which is the default. I have pre-rendered frames set to "2" in both sims in Nvidia inspector so that should really be a fair comparison.

I'm currently digging through that crazy blur busters article. Guess I'll find some answers soon...
These guys are completely nuts lol

Little update:
Apparently the scanout is synced to the hz so at 60 hz my monitor will take 16.67ms to go through the pixels from top to bottom.

Apparently, since rtss limits the fps on cpu level, maximum pre-rendered frames becomes almost disabled as the cpu isn't allowed to start queing/prepare more frames.
Which explains why I don't see a difference no matter what I set for pre-rendered frames.
If the limiter has a hiccup, my hz counter (provided by the monitor osd) jumps to 61 for a frame.

I will test to set ac via the config file to 20 at some point over the next days!

To see a difference with gsync though it seems I need to hit the gpu bottleneck within the gsync range? So the cpu can actually pre-render...
Guess I'll throw some 4x dsr at it then...

 

[RasmusP]

Sorry for spamming this thread a little...
Here's a nice video about monitor scanout from blur busters:

So the monitor does the top to bottom scan without pausing between cycles.
I might have thought the scan would be linked to what's the monitor capable, so 120 hz monitor scanouts always being twice as fast as 60 hz monitor scanouts, even when both monitors set to 60 hz.

But it's not the case!

With gsync, the scanout speed is determined by the gsync module before each new scanout starts.
If the fps drop from 60 to 50 between one frame to the next, so a frametime of 20ms instead of 16.66ms, the monitor will hold the scanout for 6.67ms before starting the next scanout.

The next scanout will then take 20ms to complete.

Now this vsync relation comes back into play.
If the system instantly goes up to say 100 fps, so the next frametime would only be 10ms, then the scanout would be at 50%, or right in the middle of the screen, when the next frame would be shoved into the scanout buffer.

= tearing!

Vsync will make the the gpu holding back that frame until the scanout is completed.

The next scanout would be set to 10ms without pausing between the 20ms scanout and the 10ms scanout.

So no tearing, and in theory a 10ms input lag on top, although you can't really call this "input lag" imo.

Blur busters say the same. Vsync off can have an input lag advantage but only if tearing happens. So I'd rather have the lowest lag with a clean image instead of tearing with parts of the image being updated.


About gsync buffer: it seems that there is no input lag caused by buffering. The gpu renders frame A, puts it in the scanout buffer to the monitor and while the scanout is done, it renders frame B into a second buffer.
Afaik that's how vsync off works too. You always have to have one buffer for the monitor and one to put the next frame in.

Quite awesome, I didn't know that... I thought gsync would add 1 frame lag, but it does not.

Anyway, next tests will be:

- Gsync + gpu limit to test lag within gsync range but without a limiter

- combined with ac max frame latency at 20

- no gpu limit but rtss limit + ac latency at 20

 

[Neilski]

Hmmmmm, I am a bit confused here @RasmusP...

That monitor in the video is an XL2720Z, which can do 144 Hz. It doesn't appear to have Gsync though, so I think it's simply running at 60 Hz and therefore the dot-clock from the GPU will be consistent with that; thus the frame transmission time is around 16 ms. If you have a Gsync monitor which is (a) capable of running at say 144 Hz, and (b) configured to use it (I assume that (b) is a necessary condition for what follows) then my assumption would be that the frame transmission time would always be a little under 7 ms. (A high-speed video of that would show a sweep, then a delay of nearly 10 ms, then another sweep...)

Otherwise you'd indeed have the (crazy) problem of having to wait longer than necessary between frames, every time the delay between frames gets shorter. My assumption totally conflicts with what you're saying here though:

With gsync, the scanout speed is determined by the gsync module before each new scanout starts.

Is that logic taken directly from a web page somewhere? To me, it just makes no sense at all for Gsync to do that. It would be holding back pictures that are finished rendering and could be sent to the display...

 

[RasmusP]

Hmmmmm, I am a bit confused here @RasmusP...

That monitor in the video is an XL2720Z, which can do 144 Hz. It doesn't appear to have Gsync though, so I think it's simply running at 60 Hz and therefore the dot-clock from the GPU will be consistent with that; thus the frame transmission time is around 16 ms. If you have a Gsync monitor which is (a) capable of running at say 144 Hz, and (b) configured to use it (I assume that (b) is a necessary condition for what follows) then my assumption would be that the frame transmission time would always be a little under 7 ms. (A high-speed video of that would show a sweep, then a delay of nearly 10 ms, then another sweep...)

Otherwise you'd indeed have the (crazy) problem of having to wait longer than necessary between frames, every time the delay between frames gets shorter. My assumption totally conflicts with what you're saying here though:

Is that logic taken directly from a web page somewhere? To me, it just makes no sense at all for Gsync to do that. It would be holding back pictures that are finished rendering and could be sent to the display...

Blur busters are writing that, yeah. They measured it with a 1000fps camera and really know their stuff since years so I believe them.
Apparently a monitor "has to do scanout all the time". So at 60fps you can't scanout a frame in 6ms and then wait 10ms until you scanout the next frame within 6ms and wait again.

So before each frame thr gsync module put the scanout speed/time according to the frame time so the scanout process always keeps going without interrupts.

And I agree, this is totally weird and not great...

 

[Neilski]

Blur busters are writing that, yeah. They measured it with a 1000fps camera and really know their stuff since years so I believe them.
Apparently a monitor "has to do scanout all the time". So at 60fps you can't scanout a frame in 6ms and then wait 10ms until you scanout the next frame within 6ms and wait again.

Wow, seriously trippy stuff. Do you mean you've found 1000fps footage by them of a Gsync situation too? (Cos that footage wasn't.)

 

[RasmusP]

Wow, seriously trippy stuff. Do you mean you've found 1000fps footage by them of a Gsync situation too? (Cos that footage wasn't.)

No I sadly haven't.. But I've read all this stuff on my phone and didn't watch it all.
They say this in the "why enable vsync with gsync" part.

They also say that at the early days of gsync, vsync was hard-coded into the gsync setting.
For some reason nobody knows, it became a separate setting later on and now leads to confusion.

I'm gonna try to dig out some better information when I'm at the pc tomorrow.
Maybe I can record it with my phone, although it only records like half a second.
Gsync pendulum with gsync active at 40 fps limiter against 90 fps... Maybe I get the scanout time on video. I don't think so though


Update: can't record it... I see a lot of weird stuff when turning swiftly in counter strike and recording at 480 fps but there's no scan out visible at all...

However what I've found:
Look at the bottom of this