Previous  1 ... 4, 5, 6, 7, 8  Next
[diagram] New Lagless VSYNC ON Algorithm for emulator devs 
Author Message
User avatar

Joined: 2014-09-27 09:39
Posts: 2949
 Re: [diagram] New Lagless VSYNC ON Algorithm for emulator de
That's the thing. 3d games want tearing. You didn't read my post.


2018-06-27 17:55
User avatar

Joined: 2018-03-15 23:09
Posts: 24
 Re: [diagram] New Lagless VSYNC ON Algorithm for emulator de
wareya wrote:
That's the thing. 3d games want tearing. You didn't read my post.

I did. However, others will misunderstand your post because this is applicable to emulators here. Emulators don't want tearing. And there are now tricks to resist tearing.

While not on emulator topic, but related contributions/experiments, a new RTSS alpha has already implemented a brand new tearingless VSYNC OFF mode that looks like VSYNC ON but with less lag than graphics-driver-based VSYNC ON. Not quite as low lag as VSYNC OFF, but this can help ULMB and other modes (which amplifies tearing/stutter visibility). I estimate, by lagfeel, about 75% of VSYNC ON lag disappears in certain games that only push GPU utilization ~50% (games always running framerates far above Hz, but where you want tearing and sutters to disappear and sync framerates to refresh rates in the most lagless possible manner). This kind of research is contributing to helping inventing some new low-lag VSYNC modes for 3D games too! RTSS is a free download and popular with benchmarkers, framepacing analysis and frame rate capping, but is also used to reduce lag of VRR in games too, and now can be used to do low-lag VSYNC ON tricks when one hates tearing, or need perfect smooth jitter-free/double-image-free ULMB blur reduction mode without the pain of VSYNC ON lag, etc, for slightly older 3D games capable of running full flat-out framerates.


2018-06-27 18:04
User avatar

Joined: 2014-09-27 09:32
Posts: 850
Location: Moses Lake, WA
 Re: [diagram] New Lagless VSYNC ON Algorithm for emulator de
wareya wrote:
That's the thing. 3d games want tearing. You didn't read my post.

I mean... I would personally take triple buffering (proper, with side-by-side back buffers, not a swap chain) over tearing; I find the distraction caused by tears to impede my gameplay more than the minute amount of added latency at the top of the screen would.

_________________
Shoot the unstompable
Burn the untouchable!
ROW! ROW! FIRE FLOWER!


2018-06-27 20:53
User avatar

Joined: 2014-09-27 09:22
Posts: 5140
Location: A chair.
 Re: [diagram] New Lagless VSYNC ON Algorithm for emulator de
Covarr wrote:
wareya wrote:
That's the thing. 3d games want tearing. You didn't read my post.

I mean... I would personally take triple buffering (proper, with side-by-side back buffers, not a swap chain) over tearing; I find the distraction caused by tears to impede my gameplay more than the minute amount of added latency at the top of the screen would.

Ditto. There is simply no situation where tearing is the best option.

_________________
Just in case you thought something could EVER be straightforward, and needed someone to dash your hopes across the rocky shoals of harsh reality.

; write !!!


2018-06-27 22:34
User avatar

Joined: 2018-03-15 23:09
Posts: 24
 Re: [diagram] New Lagless VSYNC ON Algorithm for emulator de
CaptainJistuce wrote:
Covarr wrote:
wareya wrote:
That's the thing. 3d games want tearing. You didn't read my post.

I mean... I would personally take triple buffering (proper, with side-by-side back buffers, not a swap chain) over tearing; I find the distraction caused by tears to impede my gameplay more than the minute amount of added latency at the top of the screen would.

Ditto. There is simply no situation where tearing is the best option.

Unless you need lowest eSports input lag for CS:GO. Lag tests (page 9 of GSYNC 101) using 1000fps high speed camera.

VSYNC OFF won by almost 10ms at 60Hz and won by a bare few milliseconds at 240Hz. Little importance to most, even myself in most games.... But:

Then again, elite competitive players are doing the virtual equivalent of a 100 meter olympics sprint, when turn a corner, see each other, and fire at each other at the same time. The reduction of lag by even 1-2ms can determine outcomes of well-matched elite reaction times, like crossing the finish line (or fire trigger creating a frag first). You do not have to feel the lag to beat the figurative equivalent of an Olympics race on a photo/replay finish - sprinters dont always know if they won a close race. Likewise, when fragging, the game server tells you who got the frag in a simultaneous see-and-shoot situation. The millisecond lag savings matters a big deal more in the leagues where people play for money in fast closely-matched-reaction-time leagues. Sure, server tickrates add granularity (e.g. 128 tick per second is 8ms per tick) but milliseconds make it more likely that your shot made the previous server tick packet. Even with low tickrate servers, the milliseconds still really begins to statistically matter as a livelihood, and that is where VSYNC OFF is (still) king. At 60Hz, the lag savings is big enough to be felt by amateur players,

But I disgress. Right Tool for Right Job, I say!


2018-06-28 02:42
User avatar

Joined: 2014-09-27 09:39
Posts: 2949
 Re: [diagram] New Lagless VSYNC ON Algorithm for emulator de
CaptainJistuce wrote:
Covarr wrote:
wareya wrote:
That's the thing. 3d games want tearing. You didn't read my post.

I mean... I would personally take triple buffering (proper, with side-by-side back buffers, not a swap chain) over tearing; I find the distraction caused by tears to impede my gameplay more than the minute amount of added latency at the top of the screen would.

Ditto. There is simply no situation where tearing is the best option.

It's simply physically impossible to go below 8ms latency on a typical 60hz display or 4ms latency on a typical 120hz display unless you have screen tearing. No buts. And that latency is added onto how ever long it takes to generate the frame, so it can push it below the 10ms-ish perceptibility threshold.

At framerates that high, you stop caring about screen tearing.


2018-06-28 08:15
User avatar

Joined: 2014-09-27 09:22
Posts: 5140
Location: A chair.
 Re: [diagram] New Lagless VSYNC ON Algorithm for emulator de
wareya wrote:
It's simply physically impossible to go below 8ms latency on a typical 60hz display or 4ms latency on a typical 120hz display unless you have screen tearing. No buts. And that latency is added onto how ever long it takes to generate the frame, so it can push it below the 10ms-ish perceptibility threshold.

At framerates that high, you stop caring about screen tearing.

I have never not cared about tearing.

Also: VR headsets, which require very low latency to be comfortable, don't tear.

_________________
Just in case you thought something could EVER be straightforward, and needed someone to dash your hopes across the rocky shoals of harsh reality.

; write !!!


2018-06-28 09:04
User avatar

Joined: 2014-09-27 09:39
Posts: 2949
 Re: [diagram] New Lagless VSYNC ON Algorithm for emulator de
CaptainJistuce wrote:
I have never not cared about tearing.

Also: VR headsets, which require very low latency to be comfortable, don't tear.

Their latency just has to be below a certain threshold. The only reason they don't have tearing is because tearing in VR makes people nauseous. Tearing on an external monitor doesn't make people nauseous.


2018-06-28 10:30
User avatar

Joined: 2014-09-27 09:22
Posts: 5140
Location: A chair.
 Re: [diagram] New Lagless VSYNC ON Algorithm for emulator de
wareya wrote:
CaptainJistuce wrote:
I have never not cared about tearing.

Also: VR headsets, which require very low latency to be comfortable, don't tear.

Their latency just has to be below a certain threshold. The only reason they don't have tearing is because tearing in VR makes people nauseous. Tearing on an external monitor doesn't make people nauseous.

Latency ALSO makes people nauseous, actually. 'S why most of them run 90 Hz displays, and the publishers test games for their ability to maintain a high framerate on the target hardware.

_________________
Just in case you thought something could EVER be straightforward, and needed someone to dash your hopes across the rocky shoals of harsh reality.

; write !!!


2018-06-28 22:55
User avatar

Joined: 2018-03-15 23:09
Posts: 24
 Re: [diagram] New Lagless VSYNC ON Algorithm for emulator de
wareya wrote:
It's simply physically impossible to go below 8ms latency on a typical 60hz display or 4ms latency on a typical 120hz display.
Yes.
That's average / screen center.
The screen surface area is a lag gradient in the vertical dimension during VSYNC ON delivery.

During VSYNC ON, scanout latency is closer to 0ms for top edge, closer to +8ms for center, and closer to +16ms for bottom edge. That's why Leo Bodnar Lag Tester -- output different numbers for TOP / CENTER / BOTTOM. Leo Bodnar is a VSYNC ON lag tester, since it's a stopwatch between VBI and scanout location.

wareya wrote:
And that latency is added onto how ever long it takes to generate the frame

Correct.

wareya wrote:
At framerates that high, you stop caring about screen tearing.

Not necessarily....Depends on how picky you are.

<shameless plug>
I was the world's first person to test a 480Hz display.
I can still see tearing of 400-600fps at 480 Hz given sufficiently-fast horizontal panning. It's very hard to see, but it's still within the human perceptual threshold.

I've also written another article, Blur Busters Law: The Amazing Journey To Future 1000Hz Displays -- achieving blurless sample-and-hold (strobeless ULMB) -- which has animations that I invented that explains display behaviours & mechanics.
</shameless plug>

wareya wrote:
unless you have screen tearing. No buts.

Correct if you're using full frame buffers.

However, there are strip-rendering-based programmer-conscious raster-conscious tricks to hide the tearing, while getting less than half a frame latency. This would be similar to the strip-based rendering trick used in this Android virtual reality 4-frameslice 3D render beam racing. Reducing latency in mobile VR by using single buffered strip rendering.

Obviously, shifting things mid-scanout wouldn't be recommended for things like turning, but one can 'skew' instead (e.g. shift graphics one scanline at a time, as it scans out), to hide the tearing artifact (essentially having a tearline every pixel row, to the point where it's a skew instead of tearing), using GPU shader sheningians, etc. In fact, it would undo the skew seen at in the TestUFO animation I created, www.testufo.com/scanskew (not all screen skews, but view that at 60Hz on a Dell LCD or CRT, these skews like a mofo) if you did realtime skew-during-scanout, so you'd have tearingless skewless "VSYNC ON looking" equivalent, with zero latency! But it's an overkill, extremely hard-to-do-thing to do realtime skew compensation (subpixel-tearline-every-pixel-row to make tearlines invisible), especially when you now have to vertically sort all the 3D graphics render you have to do, and squeeze it all into your strip-rendering beamracing margin on a super-powerful computer making seamless lagless frameslices on the fly. It can be done -- but extremely hard. (You have to do the defacto 3D equivalent of updating the real world seen through a spinning slit-shutter (metaphorically: camera rolling shutter -- slit on a disc -- a tiny horizontal slit that zooms vertically) -- skew artifacts and all. But unlike seeing the resulting photograph at once (has skew artifacts) but since you're seeing the world in realtime, the per-scanline skew compensation (or metaphorically, subpixel-offset tearline every pixel row, to produce a graceful skew) actually "undoes" the scan skew ... which then actually improves the resulting image while zeroing out lag. True, it may be VSYNC OFF, but because of the subpixel-offset "tearline" every pixel row, it just simply becomes an anti-skew that compensates for the scanning skew ( www.testufo.com/scanskew ) -- and viola. Some people trying original Quake (Quake Live) at >1000fps on new GPUs has noticed this "skew" phenomenon (screen capture example). And it happens to be an opposite-direction to scan skew. So the two, cancels each other out, so a beneficial effect. And at the end of the day, tearlines are gone by metaphorically having tearing every pixel row (subpixel horizontal shifts) -- or using GPU shader to erase the tearing by pre-skewing each frameslice to eliminate tearing seams -- you achieve sub-8ms tearinglessly in a 3D game at 60 Hz.

It theoretically turns into an even better, lagless VSYNC ON (no skew, new lag) -- But it is extremely, extremely hard to do -- it's almost like trying to reach the speed of light and finally hitting it (imagine VSYNC OFF at framerates so fast that each tearline is only 1 pixel apart vertically -- tearing is completely perceptually gone then). As a shortcut, one can just simply use ultrahigh framerates, as tearing is a diminshing-points-of-return behaviour for faster-and-faster horizontal motion (e.g. mouse flicks).

___

Anyway, it is much easier to do with emulators -- they're already raster-scanning offscreen. So just piggybacking on that; we just have to roughly synchronize that with the actual display, to have tearingless VSYNC OFF (creating our lagless VSYNC ON via beamraced framesliced VSYNC OFF). Yes, actual tests show <8ms without tearing in this particular situation to CRTs and to the fastest LCDs -- e.g. if you're doing a mid-screen input read for not-yet-displayed/rendered bottom-of-screen action, and raster-render that on the fly (like original 8bit machines do), which is indeed possible without tearing in the specific emulator use-case.

With beam-raced framesliced output, Leo Bodnar Lag Tester TOP/CENTER/BOTTOM latency can match TOP. So if a DisplayLag.com display measures 3ms/10ms/18ms for TOP/CENTER/BOTTOM, it can measure 3ms/3ms/3ms with beamraced output. DisplayLag.com only displays CENTER numbers though. So subtract 8.3ms from any Leo Bodnar Lag Tester result, to get your beamraced input lag that you can achieve with an emulator.

The complexity of trying to do this, is why it's not done for games like CS:GO, or other traditional 3D programming workflows.

wareya wrote:
Their latency just has to be below a certain threshold. The only reason they don't have tearing is because tearing in VR makes people nauseous. Tearing on an external monitor doesn't make people nauseous.

Correct.

CaptainJistuce wrote:
Latency ALSO makes people nauseous, actually. 'S why most of them run 90 Hz displays, and the publishers test games for their ability to maintain a high framerate on the target hardware.

Correct too.

The higher the Hz, the less evil the lag of VSYNC ON. A very highly optimized VSYNC ON implementation on a 240 Hz display is only ~2ms average lag (midpoint of 0..(1/240)...). A rolling-scan OLED display can be tuned to be virtually lagless, like a CRT. Unlike a strobe-backlight blur reduction LCD (e.g. ULMB, ELMB, LightBoost, DyAc, etc) it the panel must scan-out in darkness first before the backlight is flashed on the fully-refreshed panel.

All of this is kind of a sidetrack from the topic of beamraced output, but I'm considered an industry expert in this topic matter of input lag.


2018-06-29 04:00
Previous  1 ... 4, 5, 6, 7, 8  Next