1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

The truth about PRE-RENDERING 0?

Discussion in 'Videocards - NVIDIA GeForce Drivers Section' started by Tastic, Jul 16, 2012.

  1. 2mg

    2mg Member

    Messages:
    32
    Likes Received:
    1
    GPU:
    760
    Sorry if I'm necroing a post, but:

    1.) If Vsync isn't limiting "behind the scenes" engine, then why does the FPS (with possibly uneven frametimes) lock to your refresh rate, and GPU/CPU usage does in fact drop?

    2.) Why doesn't the "fake" (aka DirectX's pre-render frames) Triple Buffer Vsync halve the FPS like DB Vsync does? A missing frame is a missing frame, no matter the number of buffers, no?

    3.) If we could call Nvidia's FastSync "real" Triple Buffered Vsync, why does it not lock FPS like "fake" Triple Buffer Vsync does, since both of them, like DB Vsync, are actually working "behind the scenes"?

    4.) Since DWM/Desktop Compositor has actually a real Triple buffer Vsync, why doesn't it operate like above mentioned FastSync? Run a Windowed Fullscreen and you will get locked to your refresh rate with it, why?

    5.) Does DWM in Win7, besides adding input lag because of Vsync, add additional lag because it has to switch frames from the game to the DWM then to display? Did Win10's compositor improve upon this?
     
  2. RealNC

    RealNC Ancient Guru

    Messages:
    2,916
    Likes Received:
    1,176
    GPU:
    EVGA GTX 980 Ti FTW
    https://forums.guru3d.com/threads/the-truth-about-pre-rendering-0.365860/page-19#post-5494650

    It's about the game not being able to render the next frame while the current one is being scanned out, because in double buffering both buffers are used and the game has to wait for one of them to become available again. That's what causes the FPS halving. We already explained this when you asked about it on the Blur Busters forum.

    Note that pre-rendered frames are NOT a triple buffer mechanism! Pre-rendered frames are frames that have NOT been rendered yet. In a double buffer setup, you have two rendered frames (one in the front buffer, one in the back buffer.) If you add one more back buffer, you have what we today call "triple buffer vsync." All three buffers contain rendered frames. The pre-rendered frames are something else. These are buffers containing the data that the GPU will later use to render frames.

    How the pre-rendered frames interact with double buffer vsync FPS halving is not something I have a clear idea about. I suspect they sometimes can prevent FPS halving due to the asynchronous nature of frame presentation in modern DirectX versions, but really, I could be talking out of my butt here.

    It seems fast sync uses a frame limiter to try and pace the game's FPS in a way that it produces frames at intervals that result in less microstutter. "Real" triple buffering on its own doesn't actually have an effect on FPS.

    Are you sure? If you use vsync off, windowed mode will not lock your FPS.

    Edit: Or it might in the latest W10 version (1803.) I haven't upgraded to that. I think I've seen people complaining about windowed mode now enforcing vsync in W10 1803? I'm still on version 17-something.

    DWM does add 1 frame of lag because of the compositing step, and that's on top of what vsync already adds (if you enable vsync). If you play with vsync off, then you just get the 1 frame of DWM lag.

    W10 does not improve on that, but it can turn itself off for some windowed fullscreen modes (DX12 Windows App Store games) and for "redirected" exclusive fullscreen modes. By default, and if the game is supported, W10 will use "fullscreen optimizations" which will use windowed mode even if you've set exclusive fullscreen in the game's settings. It will then disable DWM. This works as well as exclusive fullscreen but has the benefit of fast alt+tabbing and being able to see DWM overlays (like the volume bar) because DWM is enabled temporarily to display the overlay, and then disabled again once no longer needed. The "disable fullscreen optimizations" compatibility setting disables that behavior and you get exclusive fullscreen back.
     
    Last edited: Jul 20, 2018
  3. 2mg

    2mg Member

    Messages:
    32
    Likes Received:
    1
    GPU:
    760




    I still don't understand it this way:
    Assuming the gpu/cpu can render above 60fps at all times.
    When you fill all buffers, the engine and/or gpu goes to wait state (you stop producing cars).
    You're outputting buffers at 16.6ms.
    Each 16.6ms, a buffer is freed, and the game/gpu wakes up, and renders into the buffer at speed of less than 16.6ms.
    But each time it does it, it's goes back to wait state.
    So why would there even be a bottleneck since
    if buffer=full then wait
    else
    if buffer=empty then write + goto wait?
    What goes out of buffers is at 16.6ms. What goes into is less or equal to 16.6ms. The rest is gpu sleeping.


    1. But isn't it known that common Triple Buffer in DirectX titles means just using "pre-rendered frames X"?
    2. Why this doesn't halve the FPS like DB Vsync does is beyond me.
    3. What is actually a real TB Vsync is either FastSync, OpenGL, or DWM/Compositor, no?


    I only noticed microstuttering, and the frames were uncapped though...


    Windowed modes, at least on Win7, with Vsync OFF in app will not lock your FPS, but it will enforce DWM's Vsync (what FastSync does).


    But DWM automatically enforces Vsyncing too, so there's additional, although lesser, input lag.

    So unless the app has "redirected exclusive fullscreen" that will turn DWM off, it's better to use "disable fullscreen optimizations" to reduce input lag?
     
    Last edited: Jul 21, 2018
  4. janos666

    janos666 Master Guru

    Messages:
    647
    Likes Received:
    41
    GPU:
    MSI GTX1070 SH EK X 8Gb
    I noticed the framerate often tends to settle at N>1 integer multiples of the resfresh rate (like 120fps for 60Hz) with FastSyns but it's far from consistent. I think it's more complicated math (where the main priority is achieving the highest possible framerate and/or GPU-utilization while still hugging the multiples of the refresh rate if it's in close range, probably by interpolating the expected frametime/utilization from the past (few) frame(s)). The problem is FastSync is best for framerate<refreshrate (it's virtually the same as tripple-buffer Vsync in smoothness) or framerate>refresh*2 and worst in between the two (which looks a lot like regular vsync in the 0.5x - 1.0x range: lots of visible stutters). But FastSync + RTSS limiter set to the refresh rate (or -0.01 to make it easy to switch between Fast and regular Vsync) usually work great together in sane games (very minimal amounts of frame drops/repeats but low perceived lag).
     

  5. KneehighPark

    KneehighPark New Member

    Messages:
    2
    Likes Received:
    1
    GPU:
    GTX 1050 Ti
    Hey RealNC.

    1) Cool, I'll stick with vsync in-game unless I notice horrible frametimes.

    2) I've tried 3 different browsers using 2 diff vsync tests on each one. All of them report either 60.001 or 60.002 Hz. I then opened up CRU, and this is what I got. I will say that while my PCs and laptops usually report 59.994 Hz or something, all of my messages/posts referred to using my 4K Samsung TV.

    [​IMG]
    [​IMG]

    3) Gotcha. I guess what I really meant to say was "If I dip below 60 fps even once, will this break anything".
     
  6. RealNC

    RealNC Ancient Guru

    Messages:
    2,916
    Likes Received:
    1,176
    GPU:
    EVGA GTX 980 Ti FTW
    When the rendering pipeline comes back from sleep to render another frame, that frame is added at the bottom of the queue. So by the time that frame makes it to the screen, it has aged a lot. That's where input lag comes from.

    A frame limiter results in the frame being placed at the front of the queue, which is why input lag is reduced.

    Nope. Pre-rendered frames are something different. TB means you can have up to 3 fully rendered frames. Pre-rendered frames are not fully rendered.

    You mean why FPS isn't halved in some games even though they use double buffer vsync? Not sure. Could be because something is forcing triple buffer, or it could be because the API (DX, GL, whatever) is multi-threaded and in some games, depending on how their rendering pipeline was developed, the game is allowed to continue setting up rendering data even though both buffers of the double buffer queue are full. The only reason you get FPS halving with DB vsync is because the game is prevented from starting work on the next frame when the current frame missed the vsync deadline and both buffers are in use. But if the game is allowed to start work on the next frame regardless, then there's no FPS halving. But for that to happen, you need either triple buffer, or some form of asynchronous frame presentation queue, where the game is allowed to start work on a pre-rendered frame.


    I don't think OpenGL does that one. Triple buffer in OpenGL is just your normal third frame in a buffer queue, just like DirectX.

    I only noticed microstuttering, and the frames were uncapped though...

    Yeah. It's what I said :p

    Yes. If DWM is active, you will always get 1 additional frame of latency. Unless you use windowed mode g-sync, which for some reason seems to have no added latency at all. Unless something changed in recent W10 versions. Nobody knows what exactly NVidia is doing to DWM in that mode, but a while back, jorimt on blur busters did input lag tests in windowed mode g-sync with DWM active, and that 1 frame of latency that's normally there wasn't actually there. But to be sure, it's always best to use a mode where DWM is disabled, be it "redirected windowed fullscreen" or true "exclusive fullscreen."
     
  7. jpotts

    jpotts New Member

    Messages:
    9
    Likes Received:
    0
    GPU:
    1070 Gaming X 8GB
    Just curious, the Blur Busters guide specifically cites "VSYNC ON." Is that referring to the nVidia control panel setting? I've noticed that doesn't work very well with some games. Is using in-game vsync a bad idea in conjunction with RTSS frame limiter?
     
  8. RealNC

    RealNC Ancient Guru

    Messages:
    2,916
    Likes Received:
    1,176
    GPU:
    EVGA GTX 980 Ti FTW
    It doesn't matter.
     
  9. plopingo

    plopingo Active Member

    Messages:
    61
    Likes Received:
    6
    GPU:
    GTX 970
    how to enter the decimal in rtss? , or . is not working

    I need to enter this : 143.976

    Thanks !
     
  10. RealNC

    RealNC Ancient Guru

    Messages:
    2,916
    Likes Received:
    1,176
    GPU:
    EVGA GTX 980 Ti FTW
    It works here just fine. What RTSS version are you using?
     

  11. plopingo

    plopingo Active Member

    Messages:
    61
    Likes Received:
    6
    GPU:
    GTX 970
    7.2.2
     
  12. RealNC

    RealNC Ancient Guru

    Messages:
    2,916
    Likes Received:
    1,176
    GPU:
    EVGA GTX 980 Ti FTW
    Well, I don't know. Maybe it works correctly with your keyboard language. Try switching to US English. Or try the numpad "." key too.
     
  13. dezo

    dezo Member

    Messages:
    19
    Likes Received:
    3
    GPU:
    GTX 1080
    I have the US layout and the numeric block "." key doesn't work for some reason. Only the "." key above right alt on main part of the keyboard.
     
  14. plopingo

    plopingo Active Member

    Messages:
    61
    Likes Received:
    6
    GPU:
    GTX 970
    it work thanks but I can only put 6 numbers like 143.97
     
    alexander1986 likes this.
  15. alexander1986

    alexander1986 Member Guru

    Messages:
    166
    Likes Received:
    16
    GPU:
    RTX 2060
    yeah you cant do more than 2 decimals in the interface of RTSS, must be done via the text file/profile cfg for the game in RTSS folder, also needs the correct denominator (amount of decimals)

    add and edit this to your game config with notepad (or global config but I recommend separate game config) in the RTSS /Profiles folder:

    [Framerate]
    Limit=143976
    LimitDenominator=1000




    the [Framerate] section should already be there so just add/modify limit and limitdenominator values there,


    Its been very long time since I did this might be wrong on the denominator value, but pretty sure this will work, also RTSS will display the correct value with full decimals when doing this, but still wont allow you to edit the decimals in interface, always must open the config file with texteditor/notepad and then reload the config in RTSS if you edit limit values like this,


    this is how I got my games to play on 119.994 hz for some testing in some games :p
     
    Last edited: Apr 6, 2019

  16. plopingo

    plopingo Active Member

    Messages:
    61
    Likes Received:
    6
    GPU:
    GTX 970
    https://prnt.sc/n88r2u

    Finally good to go ? xD
    So if I understood everything right. no more screen tearing and reducing input lag when vsynch on. right?

    thanks
     
    alexander1986 likes this.
  17. alexander1986

    alexander1986 Member Guru

    Messages:
    166
    Likes Received:
    16
    GPU:
    RTX 2060
    yes looks good to me, 0.1 fps below true refreshrate for low lag vsync on trick :)

    PS I still recommend making separate game profile for games and edit the game profile in RTSS/Profiles game-by-game instead of global profile, but that is just me ! if it works fine for you with global then its all OK :)
     
  18. plopingo

    plopingo Active Member

    Messages:
    61
    Likes Received:
    6
    GPU:
    GTX 970
    I'm taking note ! ;)
    I will test with Apex Legend because I really have hard time with this fast paced game.
    I will come back with a feedback. :)

    Thanks again !
     
    alexander1986 likes this.
  19. RealNC

    RealNC Ancient Guru

    Messages:
    2,916
    Likes Received:
    1,176
    GPU:
    EVGA GTX 980 Ti FTW
    You don't need to edit the profile files. 2 decimal digit FPS accuracy is good enough. The "-0.01" FPS cap value is just a ballpark figure. It's OK if the cap ends up being -0.016 or -0.02. Anything between -0.01 and -0.02 is fine.
     
    alexander1986 likes this.
  20. alexander1986

    alexander1986 Member Guru

    Messages:
    166
    Likes Received:
    16
    GPU:
    RTX 2060
    no problem! but do you have stable 144 fps all the time in apex? maybe vsync on not best idea if unstable fps, but you can test :) in fast shooter/first person games I think is best with:

    (not ranked in special order just a list)

    A) vsync off and 144 fps limit on 144 hz monitor
    B) vsync off and unlimited framerate (maybe 144 is max framerate in apex I dont know?)
    C) vsync off + ULMB on + 144 fps limit on 144 hz monitor (if you have ULMB or other blur reduction/strobing method on monitor like lightboost / benq blur reduction / benq DyAc, asus ELMB etc)

    D) gsync/freesync on and limit framerate to -3 fps below refreshrate, example 141 fps on 144 hz monitor to keep gsync/freesync active 100% of time

    But I guess you dont have gsync/freesync monitor thats why you test low lag vsync on trick?

    For me personally in fortnite, I get best results with option C, but im also not sensitive to tearing but very sensitive to input lag and motion blur :)

    PS. Also RealNC is correct (he is expert btw) it doesnt have to be *exactly* true refreshrate minus 0.1 fps for low lag vsync on trick, many people use for example 143 fps @ 144 hz etc,

    anything from -0.1 to -1.0 fps below true refreshrate is recommended from what I know, difference will be in how stutter appears, not in input lag,

    143.000 fps or 143.976 fps on 143.986 hz monitor, for example is same input lag as far as I know, only difference is in how periodic stutter will manifest itself, (long time between more noticeable stutter or less time between less noticeable stutter)

    also max prerendered frames = 1 is recommended in graphics card driver when doing this, or always for games IMO for least input lag, many games already have this by default though but yeah, to be on safe side can set it if not already set I guess,



    Good luck anyway!
     
    Last edited: Apr 6, 2019

Share This Page