V-Sync
Images are sometimes not shown due to bandwidth/network limitations. Refreshing the page usually helps.
You are currently reading a thread in /g/ - Technology
You are currently reading a thread in /g/ - Technology
Can someone clarify for me how V-Sync works when you are at framerates in between integer quotients of your refresh rate?
The way I understand it is that if you are in between one of those quotients, you are dropped down to the next quotient while frames are held in a buffer until the framerate recovers. So for example on a 60Hz display without triple buffering, if you are at 50fps, then you are effectively playing at 30fps until the framerate can return to 60. With triple buffering you would be dropped to 45 until 60 is recovered.
Is this correct?
If someone would like to explain how adaptive v-sync is different I would appreciate that as well.
Thanks.
>he thinks /g/ actually knows about technology beyond ricing their shitty timesink memeos
>>54389607
Thanks for bumping, I guess.
>>54389649
No problem friend :^)
Heard something pretty much similar.
For instance this is a thing that I get with DIRT 2 (just as an example) where disabling vsync gets me a pretty smooth framerate, only with tearing. Enable vsync, max fps is 50 on high settings, everything looks really sluggish, like 30.
>>54389553
All adaptive v-sync does is it drops the v-sync altogether when the fps drops below the monitor refresh rate.
If I have understood correctly, triple buffering gives you the same refresh rate as is your fps but costs a little because it needs a bit more video memory.
>>54389553
>>54390449
This is correct. Triple buffering usually also introduces some latency as you are always a frame behind whatever the game is spitting out.
All of this will become irrelevant when Freesync/GSync becomes standard, hopefully at some point this decade.
This has pretty good explanation of how triple buffering works.
http://c2.com/cgi/wiki?TripleBuffer
>>54389553
With double buffering the video card has to wait after each completed frame for the monitor to finish displaying the previous frame.
So if the video card could produce 59 fps, but the monitor demands 60, the card will only produce 30 fps and spend almost half the time idling.
With tripple buffering the video card never has to wait:
Once a frame is ready it can start working on a new frame.
So you can get, say, 59 frames in one second on a 60Hz monitor.
However, in that case you would get a (noticeable) stutter once per second as the monitor shows the same frame for two cycles instead of one.
>>54390449
>but costs a little because it needs a bit more video memory.
Yes.
Which was significant in Ye Olde days when video memory was measured in megabytes or even kilobytes.
But with the current gigabytes of video memory it's a non-issue.
Even for UHD you only need 32MB per buffer.
>>54390628
Good explanation.
The recent gsync/freesync technologies try to remedy the problem by making the screen adapt to the GPU's frame output.
>>54389553
vsync just means "wait until the next vertical refresh period"
so if the applications fails to finish a frame in time for one period, it will be held until the following one
so no, it won't just drop to 30fps /unless/ the program is consistently missing the following period, for example, 1 "60fps" period is ~16ms, if the program is consistantly taking longer than that (but less than 32ms), then you will effectively get 30fps
>>54389553
keep in mind most monitors can be run at 50Hz, so if you're getting 50-59fps in a game, you'd be better off running at 50Hz (as you can then vsync to 50fps rather than getting mostly 30fps)
>>54390861
But at 50Hz any missing frame will be extra noticeable.
If you are guaranteed to get at least 50fps it's better, but in the real world where frame rates fluctuate it's better to have a higher refresh rate.
>>54390522
Depends on the specific technique. If you do three buffers:
1. Drawing
2. Ready
3. Displayed
Drawing and ready swap atomically when a frame has completed painting. The most recent ready frame and the current displayed frame swap atomically on VSync interrupt.
These could be simultaneous, or you'll skip a ready frame if you're going too fast and painting two frames per Vsync (menus/chrome?). This introduces an extra frame latency over non-Vsync, but avoids tearing. If you could get a perfect framerate with Vsync, it wouldn't introduce any extra latency. It may, however, do unnecessary paint work without further tuning.
>>54390688
I don't miss that part of Ye Olde Days. The PlayStation's 2MB was especially painful. You might be racing interlaced 50/60Hz fields, because you didn't have enough VRAM to even double-buffer at the top resolutions.
>>54390713
And it's about damn time. These monitors don't "scan" anymore, there's no beam to race, so any screen tearing in this day and age is pure stupidity caused by old video standards still pushing pixels like there were beams to feed, instead of panel controller buffers.
It's terrible that Nvidia patented their technique. Fortunately, Freesync is a great workaround and I hope that it becomes ubiquitous.
Mixing framerates in one display is a very strange thing to composite.
