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:
    31
    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,673
    Likes Received:
    923
    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:
    31
    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:
    600
    Likes Received:
    28
    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,673
    Likes Received:
    923
    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:
    5
    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,673
    Likes Received:
    923
    GPU:
    EVGA GTX 980 Ti FTW
    It doesn't matter.
     

Share This Page