Standards Group Adds Adaptive-Sync To DisplayPort 82
MojoKid (1002251) writes "Over the past nine months, we've seen the beginnings of a revolution in how video games are displayed. First, Nvidia demoed G-Sync, its proprietary technology for ensuring smooth frame delivery. Then AMD demoed its own free standard, dubbed FreeSync, that showed a similar technology. Now, VESA (Video Electronics Standard Association) has announced support for "Adaptive Sync," as an addition to DisplayPort. The new capability will debut with DisplayPort 1.2a. The goal of these technologies is to synchronize output from the GPU and the display to ensure smooth output. When this doesn't happen, the display will either stutter due to a mismatch of frames (if V-Sync is enabled) or may visibly tear if V-Sync is disabled. Adaptive Sync is the capability that will allow a DisplayPort 1.2a-compatible monitor and video card to perform FreeSync without needing the expensive ASIC that characterizes G-Sync. You'll still need a DP1.2a cable, monitor, and video card (DP1.2a monitors are expected to ship year end). Unlike G-Sync, a DP1.2a monitor shouldn't cost any additional money, however. The updated ASICs being developed by various vendors will bake the capability in by default."
It's a great idea (Score:3)
I have to wonder why the idea of adaptive vsync wasn't thought of earlier or implemented into display standards earlier. It just seems like such an obvious idea once you've heard of it. Surely someone else in the graphics/display industry must have had the idea before NVidia?
I can't think of any downsides to having this technology; it's pure upside as far as I can tell. Although, I guess I could imagine that there could be some technical downsides, depending upon how displays are typically implemented. For an LCD, I can imagine that knowing the frequency ahead of time allows the LCD panel to perhaps "pipeline" some of its operation, allowing faster grey-to-grey transitions. For example, if the display knows that the next frame is going to come at exactly X milliseconds in the future, then perhaps it could start transitioning all pixels to grey at time X - N, where N is the average time it takes for pixels to transition to grey, and then when the frame is received, it could then transition all pixels from grey to the next frame pixel colors faster. With adaptive vsync, the display would not be able to do this; it would have to start the transition from frame M pixel values to frame M + 1 pixel values only as soon as frame M + 1 becomes available.
Not being able to play grey-to-grey optimization games is I guess a possible downside of adaptive vsync; but I suspect it's a pretty small downside. Aside from gamers who want to see "the next frame" with the smallest latency possible, I don't know that anyone is really going to care much about that potential downside.
Re:It's a great idea (Score:5, Interesting)
For example, if the display knows that the next frame is going to come at exactly X milliseconds in the future, then perhaps it could start transitioning all pixels to grey at time X - N, where N is the average time it takes for pixels to transition to grey, and then when the frame is received, it could then transition all pixels from grey to the next frame pixel colors faster.
What's the reason for transitioning to grey? Is it to minimise the likely "distance" (time) to the new colour?
Won't most pixels, most of the time, remain a similar colour in the next frame? I don't understand the ins and outs, but wouldn't you lose as much, if not more, as you'd gain?
Re: (Score:3)
There goes the great contrast ratio of monitors. Just as we're mourning the loss of vertical resolution thanks to the economics of reusing 16:9 television panels, we'll be mourning the good old days of nice dark blacks and well-saturated colors if they were to completely grey out the screen between each frame. Thanks but no thanks.
Re: (Score:2)
I guess his idea is that you can transition from one frame to the next *while* the frame is building as on a CRT.
Given two colors A and B, you could write the resulting color as
C = A*(1-alpha) + B*alpha
As alpha goes from 0 to 1, the color of the pixel would go from C=A to C=B.
This is then applied to the scanline of the CRT, where alpha is increased from 0 to 1 as the scanline progresses.
Re: (Score:2)
You patent it, I'll rustle up some investors, and before we know it we'll be sitting onna beach, earning twenny percent.
Re: (Score:3)
There's no reason to go through grey between every frame. As you say, most pixels will remain the same color, and making every pixel grey at the V-sync frequency will just make the whole display strobe and look washed out.
Grey-to-grey is just an easy thing to test for benchmarking displays. You don't actually do that in normal operation.
Re: (Score:1)
Re: (Score:3, Informative)
I have to wonder why the idea of adaptive vsync wasn't thought of earlier or implemented into display standards earlier. It just seems like such an obvious idea once you've heard of it. Surely someone else in the graphics/display industry must have had the idea before NVidia?
It's just a vicious compatibility circle.
CRTs have a fixed frame rate for technical reasons.
Therefore graphics cards have a fixed frame rate to support CRTs
Therefore LCD displays have a fixed frame rate to support graphics cards
Therefore graphics cards continue to have a fixed frame rate
etc...
New stuff has to remain compatible with old stuff, so nobody even thinks of breaking the circle. Until now, fortunately.
Re: (Score:2)
What's more, even sending the picture as a set of scanlines is no longer needed. With recent versions of eDP (embedded Displayport) and DP you will have the option to send it as little square chunks, send only those that have changed, and even use compression (for extremely high resolutions or power saving purpose)
Re: (Score:2)
Especially since it's actually an upside to most people: the gray-to-gray "optimization" introduces flicker, at least based on your description.
Re: (Score:3)
The Amiga did this sort of stuff when it first came out. You could create a Copper (the display coprocessor) list that was synced to the vscan quite easily; "beam-synced blitting" I think was the name. Basically, you built your copper list so the screen writes were always just behind the video beam so you could have flicker-free drawing.
Re:It's a great idea (Score:5, Informative)
That's clever in that they presumably accomplished that without a back-buffer back when RAM was expensive, but basically you're describing the vsynced based rendering which has been the standard for decades: Wait until the screen starts updating (the vsync), then start working on the next frame to maximize rendering time. It's nothing like G-sync/free-sync/adaptive sync though - you still have the issue that if your screen updates at 60FPS you have exactly 1/60 of a second (~16.67ms) to render each frame.
Adaptive sync means that if you finish rendering an easy frame in only 14ms the screen can display it immediately instead of waiting an extra 2.67ms for the next scheduled refresh. Even more importantly if a complex frame takes 20ms to render you don't miss the refresh and have to have to wait an extra 13.3ms for the next scheduled refresh, wasting almost an entire frame - instead the screen can hold off on refreshing until the rendering is complete.
TLDR: Adaptive sync means that if you enter a graphically intensive area that you can only render at 50fps, then your monitor will automatically refresh at 50fps, instead of continuing to try to refresh at 60fps and having to spend every other frame waiting for the rendering to finish, for an effective framerate of only 30fps. (or possibly a jittery 40fps with double-buffering: update,update, wait,u,u,w,...)
Re: (Score:2)
Oh wow; thanks for that explanation!
+1 informative if I could mod in this thread now.
Wow (Score:2)
Probably the best explanation of the problem and how adaptive sync works that I've seen. Well done!
Re: (Score:1)
I remember that one, that was a neat feature. It also meant that you were able to split the screen horizontally, having different resolutions and colour depths for the "top part" and "bottom part" of the CRT.
Re:It's a great idea (Score:5, Insightful)
I have to wonder why we still use the concept of sync and porch and blanking interval and even frames, etc at all, when we all now run pixel-addressable digital displays rather than a magnetically confined analog electron beam physically sweeping over a surface.
"Tearing" results from the display updating halfway through a complete refresh. Why the hell do displays still do complete refreshes? No need whatsoever to update anything but the small subset of pixels that have changed. And no need whatsoever to do that in some blessed-from-on-high linear scan pattern from left-to-right top-to-bottom manner, either.
How about if the next gen of video hardware stops pretending it still needs to support CRTs, and we can all move on from caring about metrics like "refresh rate" that haven't meant a damned thing in over a decade?
I didn't realise they didn't already did that. (Score:2)
I didn't realise this wasn't already a thing. I mean it made sense with CRTs, since they had an analog PLL for synching the line sweep to the end of line markers. I'm sort of surprised that with digital ones they went to the effort of syncing frame display when there wasn't any data in the input line.
Re: (Score:2)
I haven't RTFA, but from what I understand of it, it's not syncing the output from the graphics card to the vertical blanking interval on the monitor, it's the other way around. It's running the monitor at a variable frame rate so that if you're running at (say) 60Hz refresh and the next frame takes 1/60th second + a tiny bit, the monitor can hold off painting the new frame until the data is there to paint it, rather than waiting for 2/60th second before displaying an updated frame. Or, if the next frame is
Re:I didn't realise they didn't already did that. (Score:5, Informative)
Re: (Score:2)
Actually from TFA it looks like "or sooner" is also an option, though presumably there's still some monitor-specific minimum.
Re: (Score:2)
Yeah, I understand---and I didn't realise they did that.
I mean a VBI made sense for analog. For digital, I assumed they just dumped the data to the flat panel when they'd either got a frame load from the input source or when that happens and an additional signal arrives. Seems interesting that they've apparently gone to the the effort of running an internal oscillator in the monitor so it dumps it at a fixed rate regardless.
Re: (Score:2)
Yeah, I always found it strange that even a purely digital flat panel monitor still "emulates" a vertical refresh interval signal...
Re: (Score:3)
What's "purely digital" about a LCD? You can have analog VGA inputs, which are digitized in the monitor, then sent over some ridiculously fast serial interface to column driver ICs on the glass... to be converted back to the analog voltages needed to control the LCD shutters.
Guess what? Your LCD monitor has thousands of D/A converters in it!
So for example, a relatively cheap monitor (like mine) 1680x1050, requires 1680x3=5040 columns to be driven in the actual glass. Each pixel has RGB, right? Well, those v
Re: (Score:3)
The pixel addressing of a modern graphics system (GPU to LCD) is purely digital, which is what he meant by "purely digital". Of course there are analog components in the displays, but the signal path is digital.
It seems very inefficient to dump whole frames to the panel at a fixed (or even variable) interval. Why not just change individual pixels only when they are damaged?
Re: (Score:3)
Why does it matter if you dump whole frames to the LCD? It's not like the cable is miles long or that transmitting a signal takes so much power compared to the backlight.
You'd just be adding a lot of complexity to arbitrarily refresh a bunch of pixels.
Oh and suddenly programmers are worried about *efficiency*? I doubt it! You'd just be adding complexity to the monitor. Right now a monitor is a 2 dimensional serial to parallel converter. It does the job just fine.
And I'd argue your assertion that pixels are
Re: (Score:2)
Because 99% of the time you care about an entire composited frame, not individual pixels changing.
Re: (Score:2)
What's "purely digital" about a LCD? For a start, there's nothing in this article talking about VGA. I'm talking about DisplayPort (as is the linked article) which has a signal path from the GPU to the monitor (and if you want to be pedantic about it, the DisplayPort interface on the rear of the monitor) that is purely digital. However, if you really want to take it to it's illogical extreme, even the digital signalling used by DisplayPort is, at it's heart, analogue voltages travelling down a bunch of copp
Re: (Score:2)
Yea, I remember having an argument about this with one of those guys that has to buy everything that's new in home entertainment. He had his brand new $800 15" LCD monitor and was telling me how it didn't have a refresh rate, only CRTs did. "That's silly, why would an LCD have a refresh rate?!?" he lamented. Because that's how CRT's worked for the past 30 years so that's how they designed LCDs. If it isn't broke, don't fix it is every engineers mantra. It's when marketing shows up and tells you they need a
Re:I didn't realise they didn't already did that. (Score:5, Informative)
It's tragic to hear the kind of nonsense people tell themselves. It's like a cyclist buying a car and saying "that's silly, why would a car have a speed?"
It's the same thing, dingus!
A monitor is just a high-speed serial device. Stuff comes in at some rate. The only reason CRTs had such tight timing requirements was because of the humongous amount of reactive power flowing in the deflection coils. You can just short them out but then all that reactive power becomes real (waste) heat. Lots of it. So people didn't do that.
Remember how old Multisync monitors used to click relays as they shifted to different horizontal frequencies? That was the monitor swapping in different capacitors to create the LC tank with the deflection coils. So they could swap the power around between the coil and the cap instead of dissipating it.
But that meant you better be ready to send me those pixels when I'm ready! I can't wait!
There is no such large power being bounced around inside an LCD, it's really just thousands of analog voltages being sent to a glass panel. It can wait a bit, the picture won't fade that quickly. Eventually the capacitor that is formed by the LCD shutter will leak, but that takes time.
Re: (Score:2)
Yes, from what I understand if there's DC on a shutter for too long this chemically degrades the liquid crystal itself. So the TCON NEEDS to refresh the screen no matter what so it can run its inversion scheme.
Anyways you seem to know a thing or two about LCDs!
Re: (Score:2)
Read Anandtech's review of the technology. It makes games much, much more playable. It eliminates tearing and stuttering. It's a real thing, not just some hype. Sorry that you've become so jaded to new tech that you think everything is hype, but seriously, this is real.
By the end of the year? (Score:2)
So it's gonna hit stores earlier than G-Sync?
Yeah, I'm a bit frustrated... does it show? ;)
Re: (Score:2)
So it's gonna hit stores earlier than G-Sync?
Yes, but only compatible stores will be opening their doors early enough for you to buy it first.
Re: (Score:2)
I would think that's likely. After all G-Sync promised to add $150 to the price tag of a $200 monitor for a feature that would really only appeal to hard core gamers (so add some extra $$$s for limited production run overhead) - that's a recipe for a niche product of limited appeal to manufacturers. Adaptive Sync promises to offer basically the same features for no added production cost, which makes for far easier integration into the production line - just put it in everything, there's no down side.
Useful (Score:1)
Re: (Score:2)
NTSC at 59.997 fps
It's 59.94 fps, you insensitive clod!
Re: Useful (Score:1)
Actually its precisely 60000/1001 fields per second :-)
Re: (Score:2)
LCD's refresh the entire screen at once, no scanning.
It also has its own frame buffer. You could update it once a second if you wanted and it would work fine.
Re: (Score:1)
LCD's refresh the entire screen at once, no scanning.
This is not true:
http://www.youtube.com/watch?v=nCHgmCxGEzY
CRTs always flicker (Score:2)
Actually CRTs flicker regardless of refresh rate, it's just that if they flicker fast enough our eyes don't register it visually (but may still experience added eye strain). If you film a CRT with a high-speed camera you can actually see the electron gun racing across the screen, and the first-row phosphors stop glowing long before the beam reaches the bottom rows. Here's an example of a CRT and LCD side-by-side, you can see the effect clearly: https://www.youtube.com/watch?... [youtube.com]
I love the idea of video play
What about normal TVs (Score:1)
You know, for us filthy casual console players?
Re: (Score:1)
Re: (Score:2)
Why on Earth would you want to integrate your computing power (which obeys Moore's Law and will hence be obsolete by the time you finish reading this), with your large expensive TV/monitor which is extremely unlikely to see substantial improvements over the course of a decade?
I mean, sure, I could spend several hundred bucks to upgrade my 40" LCD to a thinner LED backlit model - but aside from a bit of a reduction in weight and power consumption, what would my money buy me? It's lasted through 3 system upgr
Re: What about normal TVs (Score:1)
Re: (Score:2)
You can wait for a revision of the consoles that adds Displayport (unlikely), or a new version of HDMI that supports this (more likely) and a version of the consoles that supports that new HDMI (contingent but plausible), but in either case you'd have to shell out for a new TV, which seems to be a rather fundamental obstruction.
I'd be shocked if new portables (inc. phones and tablets) weren't using this within a few years though.
Re: (Score:1)
About bloody time... (Score:2)
This tech has been a long time overdue, nothing else to say.
DisplayPort? (Score:1)
My video cards are DVI and HDMI, monitors are DVI and VGA...
Re: (Score:2)
It's still not to be found on most low end and even midrange hardware. On motherboards, this is a feature you have to hunt for, especially for use with Intel graphics (and to have a couple of them, that's only found on very rare mobos with Thunderbolt). Even on graphics cards the newly released GTX 750 and 750 ti don't have them, save for a model from one specific vendor that is not sold in Europe as far as I know. The cheaper ones tend to have a HDMI/VGA/DVI triad.
Re: (Score:2)
well I found the card on Amazon. Still has one Displayport rather than two. I'd be happy if they crammed two mini-DP, one HDMI and one VGA on a single row (include a mini DP to single link DVI adapter in the package)
Re: (Score:2)
Look around for it - you might be surprised at the number of new monitors and video cards that support DisplayPort. My guess as to the reason it's not yet everywhere is that some of it's primary features are the support of high resolutions and daisy chaining displays - and most people don't use multiple monitors or own a screen with a resolution greater than a piddly 1920x1080.
Re: (Score:2)
And dual link DVI covers some of the bandwith need, plus VGA optionally piggy-backed on the connector.
I hope the VESA Adaptive-Sync feature gets successful (and that it'll work on linux, why not)
By the way I would like a great 1600x900 monitor with high refresh rate, great blacks and angles.. "piddly" but it would be not too big and still allow comfortable use of a maximized browser.
Re: (Score:2)
Nothing wrong with a maximized browser on a 13" 1920x1080 screen. The problem is that for larger screens 1080 makes for a horrible dpi resolution for arms-length usage. Heck, even at 13" that's only 170dpi - barely newsprint quality. Once upon a time you could get decent resolution monitors at a decent price, but thanks to the LCD monitor market piggybacking on the TV market those have all but disappeared except for niche products at a substantial markup.
As for dual link DVI, that can handle a maximum of
Re: (Score:2)
Re: (Score:1)
I suppose my lack of familiarity is due only to the shortage of my disposable income!
Why does this require a cable change? (Score:2)
I see 2 changes involved here:
Computer: If I don't have a new frame to send yet, don't re-send the current frame.
Monitor: If the sender doesn't send a frame, don't rescan. Just leave the image there.
I see why this is a change to the communications protocol. But why does this require a new cable? And why would the cable require a chip in it?
Re: (Score:2)
It depends on the display.
With CRTs, you would need a framebuffer. But they are obsolete so that doesn't matter.
Plasma uses PWM to modulate pixel color, so they already have a framebuffer. So they just need to keep doing what they are already doing.
LCDs are stable: the crystals don't change until a voltage is applied. Although the voltage is latched-in anyway, so they have a built-in framebuffer of sorts.
Please correct me if I am wrong on any of these. Regardless of what tech the display uses, just addi
Re: (Score:1)
Nope, pretty much correct with one exception.
LCDs (at least current TN, *VA and IPS) need a minimum refresh rate of a few Hz, as the individual transistors lose state similar to DRAM.
Re: (Score:2)
Thanks for the info. I'm still trying to comprehend it all.
I am surprised that they are syching the displays to the wire rate. I see how that causes the problem. The whole "blanking" thing confuses the heck out of me. I understand how it applied to CRTs, but are we really still using that? I thought resolution and timing were negotiated by DDC? Why would a display rely on analog artifacts to guess timing when it is right there in the digital signal?
FreeSync FreeFileSync ? (Score:2)
I hope our government isn't so stupid as to let them trademark FreeSync, as FreeFileSync has been around for years.
BTW, if there is any question I hearby trademark FreeFileSync(TM), and give all rights to the open source file syncronization program: http://sourceforge.net/project... [sourceforge.net]
Re: (Score:2)
I hereby trademark OpenFileSync and NetFileSync, to confuse your users gratuitously.
Good news on standard; bad on time (Score:1)