Slashdot Mirror
AMD Debuts Radeon FreeSync 2 For Gaming Displays With Stunning Image Quality (venturebeat.com)
AMD announced Tuesday it is introducing Radeon FreeSync 2, a new display technology that will enable monitors to show the exact intended image pixels that a game or other application wants to. The result will be better image quality for gamers, according to AMD. From a report on VentureBeat: With the FreeSync 2 specification, monitor makers will be able to create higher-quality monitors that build on the two-year-old FreeSync technology. Sunnyvale, Calif.-based AMD is on a quest for "pixel perfection," said David Glen, senior fellow at AMD, in a press briefing. With FreeSync 2, you won't have to mess with your monitor's settings to get the perfect setting for your game, Glen said. It will be plug-and-play, deliver brilliant pixels that have twice as much color gamut and brightness over other monitors, and have low-latency performance for high-speed games. AMD's FreeSync technology and Nvidia's rival G-Sync allow a graphics card to adjust the monitor's refresh rate on the fly, matching it to the computer's frame rate. This synchronization prevents the screen-tearing effect -- with visibly mismatched graphics on different parts of the screen -- which happens when the refresh rate of the display is out of sync with the computer.
So now our console ports will look like console ports! Oh, wait...
In a manner, yes. With F/G-Sync you get increased input lag.
It's not as bad as with Vertical Sync, but it's still there.
- Don't do what I do, it's probably not healthy nor safe. -
Take our word for it folks, we have all the pixels!
Isn't it quite the opposite? To avoid the negative effects of vertical sync often double or triple buffers are used. If the graphics card controls the refresh it can show the full image as soon as it is done with rendering. This potentially reduces all the lag from the buffering that is currently used.
How can you reduce the lag even further under the assumption of a fixed FPS?
It will be plug-and-play, deliver brilliant pixels that have twice as much color gamut and brightness over other monitors, and have low-latency performance for high-speed games.
Can someone please explain how FreeSync2 has any influence at all on any of that?
(Except possibly increase latency slightly, because you can only delay drawing through synchronization, never display what hasn't been rendered yet.)
One thing is not related to the other.
Freesync is just a way to handle variant refreshes without screen tearing. Those refreshes can happen faster or slower. If a refresh happens faster than the LCDs can make the transition (which is rare, and only will really be an issue on whole scene changes, and likely you'll never see ghosting anyway), it will still happen.
That said, Sync tech has to do with human perception of changes that respond more precisely, and eliminating stutter (which happens because the refresh can't occur at the cyclical vertical refresh, which is mostly an artifact of CRT tech anyway). It is frustrating that nvidia has pushed proprietary sync tech that is costly to implement, rather than go with "Free Sync" which only requires firmware changes for most basic monitor controllers.
It seems like AMD's real push here is to maintain Free Sync capability as monitor manufacturers increase the color gamut and enhance LCD response times.
I thought it signaled the monitor "refresh now" when it had a whole image rendered.
I don't know if normally without V-sync just one buffer is used and if that's the one sent to the monitor and if the graphics card start render onto that and if so that would mean that what has already been drawn there which eventually get sent to the screen would be more up to date than if you waited until the whole scene was drawn or whatever one always let it render completely and use two buffers and switches which is the one the monitor gets and if the tearing only happen when the monitor is fetching an image and you do a buffer switch just then (I also don't know if a monitor fetch image data the whole time or just a part of the time of the period an image is shown.)
Anyway, the alternative to G-sync and FreeSync if you don't want to have tearing is to use V-sync instead, if you don't hit the frame-time on double-buffered V-sync your refresh rate drops to half and if you don't even hit that then it drops even further, if you use tripple buffered V-sync then I don't know how it looks on the lag front from that but the images which are shown on the screen will be shown with the picture periods of the monitor and those fixed time points which of course add latency between when the image was actually rendered and when the monitor is capable/willing to show it.
With G-Sync and FreeSync however the monitor will draw when the image is done rather than at some fixed periods meaning the latency there will be lower.
So what G-Sync and FreeSync grant you is LOWER latency for whole images because the monitor is ok with waiting with an update / not follow a set refresh rate. You get a smoother experience and you don't get any say jumps between 60 and 30 Hz for the frames you see but can get say 45 if that's what you graphics card can deliver and you still get no tearing.
However you can of course turn of both G-Sync / FreeSync and V-sync and go back to tearing and just render as fast as you want and have the monitor fetch whatever is available as fast as possible too, but then you get tearing.
Hmmm...this sounds like something that could cause "screen lag" if the card tries a 1+ second refresh rate because it thinks the computer is busy.
The graphics card doesn't set a frame rate based on how busy the computer is - the new thing is that it tells the monitor what to display and the monitor does it right away, instead of waiting for the next 60th of a second to roll around.
If your computer's having a tough time rendering, and can only mange 50fps, this would have previously resulted in stutter as the monitor's apparent output varied between 60fps and 30fps, because frames could only be displayed at each 1/60th of a second interval. Now they can be displayed at any time (there is presumably a fixed minimum between frames, or at least a practical one).
systemd is Roko's Basilisk.
>> FreeSync 2,... will enable monitors to show the exact intended image pixels that a game or other application wants to.
Since when ever was this NOT happening? , specially with digital interfaces such as HDMI. This is total bullshit
With F/G-Sync you get increased input lag.
Why?
systemd is Roko's Basilisk.
Is this as opposed to all those monitors that just display whatever pixels they want to?
Those must suck.
systemd is Roko's Basilisk.
This Freesync 2 technology should be able to give you the best possible response time your display is capable of without artifacts (i.e. no tearline).
The way rendering works is by using a double buffer. The back buffer is the canvas where the GPU draws the picture where the front buffer contain the completed previous frame, intended for display. When the GPU part of the drawing is complete, the buffers are swapped.
Further down, the RAMDAC (is it still how it is called?) scans the front buffer and send the data to the monitor, line by line. The monitor then processes the data and displays the image.
The problem with the usual fixed framerate is that the scanning is a continuous process, going top down ($refresh_rate) times per second no matter how fast the GPU is drawing new frames, which mean that the image may change mid-display, creating a tearline effect. To avoid this, it is possible to wait for the drawing to complete but it causes lag (that's vsync). It mean that gamers had to choose between an ugly tearline and increased lag.
Freesync/G-Sync fix the problem by synchronizing the GPU rendering, RAMDAC scanning and display. So when a frame is complete, the scanning starts immediately afterwards and the monitor starts the display process at the same time. If the monitor is able to follow, there is no extra lag.
Freesync 2 goes a step further and addresses the data processing part of the monitor. Unlike old CRTs, modern monitors do plenty of things before lighting up pixels : contrast, scaling, color correction, etc..., and it can cause more lag. This is too bad because it is something your GPU can do better and faster. And it is exactly what Freesync 2 does : it takes some image processing out of the monitor and on to the GPU where it belongs.
I wouldn't say it has nothing to do with vsync. It helps ensure you have a frame ready for the next vertical sync by displaying a couple of frames behind - at the expense of screen lag (unless the game is rendering a couple frames ahead with some kind of predictive algorithm).
Essentially, g/freesync is variable refresh rate capability. This is different than the old fixed refresh standard which comes from the old days of CRT refresh strobes. Regardless of what the video chip was doing, the screen had to be refreshed before the phosphor decayed too much or all the eye would see is a flickering mess. The 'multisync' monitors that came later still operated at fixed rates once a mode was set (60hz, 75, 120 etc). LCD panels mimicked this behavior to retain compatibility with established video standards but there's no reason for them to be bound by this limitation. The benefit of gpu driven refresh is that it offers lower latency for applications that can't render at a high fixed refresh rate on the hardware. Because the gpu no longer has to skip frames waiting for the monitor's next cycle, all are displayed, resulting in the smoothest progression of motion possible.
Theoretically, this is also a boon for emulators of hardware that used oddball or variable refresh rates.
you understand that g-sync is a objectively inferior standard when it comes to latency right? Because it requires additional hardware processing on the display's end to enable g-sync. Whereas FreeSync makes use of an optional ISO standard extension for LCD screens (that was mostly designed for laptops as a battery saving measure but is now being used on desktops for stopping screen tear) and therefore doesn't require any additional hardware cost.
Say what you want about 'support' (I personally have opinions about anti-trust/anti-consumer practices that I whole-hardheartedly believe nvidia has done on purpose http://techreport.com/review/21404/crysis-2-tessellation-too-much-of-a-good-thing/2 to make games run slower on all systems, but slowest on ATI/AMD cards (Due to ATI/AMD cards being better at particle effects than nvidia cards, but less strong on poly counts... so nvidia pushes everything to have stupidly high poly counts when it doesn't need it..)) ... but back on topic...
Say what you want about 'support', but AMD's contributions to the open source (mantle -> openGL's replacement: vulkan), freesync (which monitors could EASILY support ALONG with gysnc ... but nvidia won't license its gysnc to any manf. who wants to do that...(again, might be good business, but anti-consumer and I'd argue anti-trust issue)) along with a lot of other technical specifications over the last ...ohh 4~5 years (HBM memory among them) far out weighs in my opinion the crap nvidia has pushed onto society with its practices...
Thanks for not disagreeing and repeating me...I guess.
You just gave a verbose version of exactly what I said. And now you're not even refuting that fact, just jumping to some weird trolling claim.
Did you not even realize I wasn't the GP poster and not continuing their argument? I'll agree with you that they have no idea how vsync/buffering works together.
The only argument I made was that double-buffering and vsync are related because one is necessary for the other to work well (despite one coming along way before the other).
You just gave a verbose version of exactly what I said.
To me, it sounded like you were largely conflating double buffering and vsync, or implying that people came up with double buffering primarily to be able to vsync.
I pointed out that double-buffering and vsync are entirely different concepts (also working on different levels). If you're rendering fast enough, there would be nothing stopping you from doing vsync with a single buffer. People don't do that not because i's a stupid idea (it is, of course), but rather because by the time vsync became a thing, double buffering was already established practice (and frankly the only way to obtain flicker-free animations anyway). Yes, it is one (among many) ingredients to get decent vsync.
It does not make the concepts 'related' in my book, though, similar to how I don't consider, say, a 'bottle of milk' and 'electricity' to be related concepts, even though likely a lot of electricity went into the whole sequence of events that ended with a bottle of milk standing in my fridge.
Did you not even realize I wasn't the GP poster and not continuing their argument?
I was aware that you're not the person I initially replied to.
CLI paste? paste.pr0.tips!
A RAMDAC is used for analog signals. Digital signals don't use a Digital to Analog Converter.
Enlightenment is the elimination of that which is unnecessary.
To me, it sounded like you were largely conflating double buffering and vsync, or implying that people came up with double buffering primarily to be able to vsync.
You didn't get that from anything I said.
If you're rendering fast enough, there would be nothing stopping you from doing vsync with a single buffer.
Scheduling. You would have to precisely schedule your drawing for the VBI period rather than whenever the CPU/GPU are free. That means putting literally everything on hold to draw a frame at a specific time rather than doing it whenever you have spare cycles.
I'm fairly sure nobody would have thought there was a point to creating such a feature as vsync without the existence of double/triple buffering when its entire purpose is to avoid tearing.
Scheduling. You would have to [...]
Hence "if you're rendering fast enough", and the part that you missed when jumping from that sentence to the 'reply' button.
CLI paste? paste.pr0.tips!
It's not just about speed. If you render really fast at any other point, you will have tearing - no matter how fast you can render. And honestly, I'm not sure the GPU gives you that information to schedule off of.
It's a certification that ensures:
1) certain refresh rate range (higher than FreeSync 1)
2) that monitor supports LFC (further increasing supported refresh rates)
3) that monitor supports HDR
4) that if game engine bothered, HDR output will be supported WITHOUT forcing in-monitor chips to do re-calculation of colors, straight out of GPU
AMD also applies stricter rules, e.g. LFC must be supported to get FreeSync 2 certified, etc.