Jump to content


Photo

Fix for Tearing/Stuttering with RCRN


  • Please log in to reply
6 replies to this topic

#1 Vypir

Vypir

    Noble

  • Citizen
  • 47 posts

Posted 01 June 2012 - 10:28 AM

Hi all,

I recently discovered a problem and a fix that I would like to share. I'll try to keep it as simple as possible.

A) Problem:
  • When using Nvidia's Adaptive Vsync, tearing would occur at the same place on the screen, every frame, at 60FPS.
  • When using Nvidia's Standard Vsync under the same conditions as #1, framerate would drop to around 40FPS with what felt like small stuttering.
B) Additional information:
  • The problem was most noticeable and easily reproducible when moving around the world map with WASD keys. (The only map mods I use reduce the size of markers and remove the HUD.)
  • Both problems would only occur when RCRN was being used. Everything was perfectly smooth when I used the Pause button to switch to vanilla.
  • Maximum Pre-Rendered Frames was set to 1 via the Nvidia driver.
C) Solution:
  • When I set Maximum Pre-Rendered Frames to 2, 3, or Application-Controlled, the problem disappeared and everything was perfectly smooth with RCRN enabled. I don't have the option to set it to 0. Mouse lag was not noticeably affected, and VRAM usage has only gone up a few megabytes, if at all.
Edit: Actually, after more play, I realized that some mouse lag was introduced when increasing pre-rendered frames from 1 to 2.  See my update.

D) Other thoughts:
  • I suspect this may be a problem with post-process injection altogether and not just RCRN. I had the same problem as #A.1 when using the SMAA injector and framerate limiter (60 FPS cap via Nvidia Inspector). I don't use SMAA anymore but I may go back to it for further testing. Basically, I suspect that vertical synchronization is designed with the expectation that post process injection will NOT be used and that it can throw the frame buffers out of sync even though it still limits the framerate. This is just an educated guess.
  • I don't recall having this problem when I used a post-process injector that simply limited the framerate to 60. It showed up when I ditched that injector for the SMAA injector, and again when I ditched SMAA for RCRN. Perhaps controlling Vsync via post-process injection will ensure that the frame buffers are synchronized?
E) My Specs:

  • 0

#2 Vypir

Vypir

    Noble

  • Citizen
  • 47 posts

Posted 26 June 2012 - 12:37 PM

Thought I'd post an update. After some more testing, I determined that the problem is specific to the HDR feature of RCRN. The problem is there even if I just use single pass HDR. Disable HDR completely, and it goes away. So, if I want my game to run perfectly smooth, I need to do one of the following: 1) Yes Vsync, Yes HDR, 2 Pre-rendered frames. 2) No Vsync, Yes HDR, 1 Pre-rendered frame. 3) Yes Vsync, No HDR, 1 pre-rendered frame. Just thought I'd throw this out there for other RCRN users.
  • 0

#3 torminater

torminater

    High King

  • VIP-Supporter
  • PipPipPipPipPipPip
  • 2,108 posts

Posted 26 June 2012 - 02:56 PM

Intreresting! Thanks for sharing!
  • 0

#4 LeetMiniWheat

LeetMiniWheat

    Knight

  • Citizen
  • Pip
  • 250 posts

Posted 04 July 2012 - 03:35 AM

maximum number of pre-rendered frames shouldn't be set to 1 in the first place. I think 1 was a tweak for FPS's but either way it DEFINITELY will increase stutter if your system is struggling to keep up. default is 3 i believe, which allows the video card to have a small buffer of frames to prevent stuttering. (or I may be confusing this with double/triple buffering on vsync, but I believe it works in the same way) also, I think RCRN is only related to this because the post processing may be pushing your GPU over the edge due to the performance hit of the injector/shader. (though it should be very minimal)
  • 0

#5 Vypir

Vypir

    Noble

  • Citizen
  • 47 posts

Posted 05 July 2012 - 01:10 PM

The stutter is definitely not due to something as simple as a straight-up FPS drop due to more demanding graphics.  I've ruled that out.  FPS is almost exactly the same between items #1, #2, and #3 listed in my last post.

By the way, using 2 pre-rendered frames gives me small but noticeable input lag, so I've simply opted out of vsync.  I find this to be the least annoying of all three options - tearing seems to be rather uncommon at my current settings.

The DirectX substitute for "triple buffering" is to use just 1 pre-rendered frame.  The default of 3 is overkill, though it is still best for SLI (for very different reasons).

I still suspect that post-process injection does something to muck with frame buffers - perhaps requiring a third buffer over the standard two (making 1 pre-rendered frame an absolute requirement while 2 is the NEW replacement for "triple buffering" -  not just 1 as was previously the case).

You may want to read these two articles:
Triple Buffering: Why We Love It
Exploring Input Lag Inside and Out

Unfortunately, all other implementations that call themselves triple buffering are actually one frame flip queues at this point. One frame render ahead is fine at framerates lower than the monitor refresh, but if the framerate ever goes past refresh you will experience much more input lag than with vsync alone. For everyone without multiGPU soluitons, we recommend setting flip queue or max pre-rendered frames to either 1 or 0. Set it to 1 if framerate is always less than monitor refresh and set it to 0 if framerate is always greater than or equal to monitor refresh. If it goes back and forth, only NVIDIA's OpenGL triple buffering will provide the best of both worlds without tearing and will further reduce input lag in high framerate situations.
Improperly handling vsync (enabling or disabling a 1 frame flip queue at the wrong time) can degrade performance by at least one additional whole frame. But with multiGPU options, we really don't have a choice. With more than one GPU in the system, you will want to leave maximum pre-rendered frames set to the default of 3 and allow the driver to handle everything. Input lag with multiGPU systems is something we will want to explore at a later time.


  • 0

#6 LeetMiniWheat

LeetMiniWheat

    Knight

  • Citizen
  • Pip
  • 250 posts

Posted 06 July 2012 - 01:40 AM

Hmm, interesting. If 1 pre-rendered frame means it's kind of tripple buffering WITHOUT vsync on, then that must mean it uses by default two pre-rendered frames. possibly the front buffer, back buffer, and then the 1 pre-rendered. but this still doesn't sound right. what then does D3DOverrider do? i know it hasn't been updated in ages but it's supposed to make DirectX triple buffered. or maybe it just overrides the flip-queue sort of. And regarding vsync, if I read that correctly, a 1-flip-queue buffer means the system has to skip an additional frame when the fps drops below refresh in order to sync back up again? I remember reading something posted by a nvidia developer about vsync something along the lines of this: "when your VSYNC'd fps drops below the monitor Hz, you experience a stutter as a frame is dropped (the fps momentarily drops to 1/2 or 1/4 your refresh), and then another stutter to sync up the back-queued frames." they were working on a fix for this so it would gradually sync up again instead of all at once. personally I can't tearing so I could never play with vsync off. tearing will always happen, it just is more noticeable to some people.
  • 0

#7 frihyland

frihyland

    Dwemer Lord

  • Founder
  • PipPipPip
  • 1,606 posts

Posted 06 July 2012 - 01:46 AM

The latest nvidia driver addresses the vsync issues but I can't find the technical details posted anywhere.
  • 0


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users