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.

Comments

Coming soon: screen lag?

[xxxJonBoyxxx]

>> 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.

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. (We see it in networking - and networked games - way too often.) Can someone please tell me I'm wrong?

Re:Coming soon: screen lag?

[Tukz]

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.

Re:Coming soon: screen lag?

[Anonymous Coward]

You're wrong.

Re:Coming soon: screen lag?

[Anonymous Coward]

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?

Re:Coming soon: screen lag?

[aliquis]

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.

Re:Coming soon: screen lag?

[Anonymous Coward]

By computing more changes to the game/sim state than are drawn, maybe? This won't reduce the inputvisual result lag of course, but it might make the game behave more accurately (e.g. letting a player move more accurately when the visual refresh rate is low).

Re:Coming soon: screen lag?

[Anonymous Coward]

You're correct, the OP doesn't know shit about this. Basically you want the refresh to be ASAP from fresh graphics instructions from the GPU, and the issue is that the output is variable but the monitors couldn't keep up - if the refresh falls out of synch you get screen tearing or dropped frames. So if you can speed up the monitor to anticipate what's coming from the GPU with variable response, you can closer-match the curve and the result is fluidity and quality.

Re:Coming soon: screen lag?

[wonkey_monkey]

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).

Re:Coming soon: screen lag?

[wonkey_monkey]

With F/G-Sync you get increased input lag.

Why?

Re:Coming soon: screen lag?

[fisted]

I don't know if normally without V-sync just one buffer is used

No. Double buffering (or even triple buffering) is a decades-old thing that has nothing to do with vsync.

Re:Coming soon: screen lag?

[GuB-42]

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.

Re:Coming soon: screen lag?

[omnichad]

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).

Re:Coming soon: screen lag?

[epyT-R]

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.

Re:Coming soon: screen lag?

[fisted]

The point is to only draw an image once it has been completely rendered. Synchronizing that with the display's refresh rate (vsync) came way later.
With no double-buffering you get horrible flicker because you're modifying the frame buffer while the display is drawing it, so what gets drawn are partial images, or the frame buffer right after it has been erased for the next image, etc.

Re:Coming soon: screen lag?

[omnichad]

Thanks for not disagreeing and repeating me...I guess.

Re:Coming soon: screen lag?

[fisted]

I'll give you the benefit of the doubt and assume you're trolling. Since you're doubtlessly going to deny then, I'll follow up by recommending to re-read my post real slow. That and perhaps familiarize yourself with the basics of the topic you're trying to discuss.

Re:Coming soon: screen lag?

[omnichad]

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).

Re:Coming soon: screen lag?

[fisted]

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.

Re:Coming soon: screen lag?

[FireXtol]

A RAMDAC is used for analog signals. Digital signals don't use a Digital to Analog Converter.

Re:Coming soon: screen lag?

[omnichad]

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.

Re:Coming soon: screen lag?

[fisted]

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.

Re:Coming soon: screen lag?

[omnichad]

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.

Re: Coming soon: screen lag?

[Anonymous Coward]

Double buffering is something you use to use extra GPU resources to increase the frame rate of something otherwise not running at the screen retrace.

V-sync is the locking of the screen retrace to 60fps (or faster.) Freesync and G-sync are the asynchronous locking to prevent partial draws. Here is something to try, turn on the hardware AA to the maximum resampled value so that you get the lowest frame rate possible, now override double-buffering/triple-buffering to off. What you should see is the game playing at its intended frame rate (eg 60 FPS) but fast movement should rip the screen in several places. With double buffering on, the game now has to wait until it has drawn a buffer before it can process input, so now it may feel super laggy.

So when someone conflates v-sync with buffering, they do not have a good grasp on what the actual rendering process is, and some games (eg skyrim) logic is tied to the screen retrace and do funny broken things when the screen retrace goes faster than 60fps and v-sync is on. At best buffering introduces a one or two frame latency penalty which is fine if the screen is 30fps or above, but is awful for latency sensitive multiplayer games where the person with v-sync on at 1920x1080x60fps is at a 1/4 second penalty to the person who is running at 640x480x240fps vsync off. Freesync in theory puts them at the same playing field, regardless of GPU capability because the actual effect is that of vsync off, but instead of waiting for the screen to redraw to process logic, the GPU tells the monitor it is ready to start a new frame, should it proceed, or tell the game it is done already.

Re: Coming soon: screen lag?

[Anonymous Coward]

You have no idea what you're talking about.

Re:Coming soon: screen lag?

[Anonymous Coward]

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.

Don't modern TVs already have GPUs in them? Image processing shouldnt need much power at all.

Awesome!

[kelemvor4]

So now our console ports will look like console ports! Oh, wait...

Stunning Image Quality!

[_xanthus_47]

Take our word for it folks, we have all the pixels!

As opposed to what?

[Anonymous Coward]

Monitors that don't display what is sent to them? Monitors that lie, or make up new colors? What the hell kind of pseudo-technical horseshit story is this?

Can someone please explain?

[arth1]

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.)

Re:Can someone please explain?

[JustNiz]

It doesn't. This is a blatantly misleading (and therefore presumably bought-and-paid-for by AMD) article.

Re:Can someone please explain?

[Kjella]

Can someone please explain how FreeSync2 has any influence at all on any of that?

FreeSync 2 comes with a developer API that will let developers access a HDR pipeline on non-HDR operating systems (that's the extended gamut and brightness bit) while skipping the HDR display's layer of tone mapping (that's the lower latency). If the developers don't do anything or you already do HDR, you only get the latter. And they can do that because FreeSync 2 monitors tell the GPU what HDR capabilities they have so the GPU can deliver a custom tailored output and the monitor display it unprocessed.

Re:Can someone please explain?

[Gadget_Guy]

Freesync 2 is all about adding HDR support for the existing Freesync standard. There is more information in the arstechnica article:

HDR on PC is a more complex beast than just panel brightness, though. First, a game performs colour tone mapping after an engine renders a scene. Then, when the frame is passed to a monitor, it's tone-mapped yet again to fit the display's supported colour range. That may or may not be the same colour space required by HDR10 or Dolby Vision. This two-stage process takes time and introduces latency.

With FreeSync 2, AMD is removing the second step, connecting the game engine directly to the HDR display. When you plug in a FreeSync 2 display, the display announces its HDR capabilities, and the AMD graphics driver will shuttle that information over to the game engine. This ensures that gamers get the best possible image quality, because the game tone-maps to the screen's native colour space, while also reducing input lag. Unfortunately, it also means that in order for FreeSync 2 and HDR to work, AMD needs the specific colour and brightness capabilities of every FreeSync 2 monitor, while games and video players must be enabled via AMD's API. AMD is going to have to win over a lot of hardware partners to make FreeSync 2 a reality.

So they are getting more colours by mandating HDR and increasing performance by removing a stage from the rendering process by allowing the game to use to exact colour space of the monitor.

Re:Can someone please explain?

[johannesg]

How does that work on a technical level: do you still use a 24-bit RGB color space, or do you need something else?

Re:Can someone please explain?

[Gadget_Guy]

You need more than that. From Microsoft's DirectX Graphics Infrastructure (DXGI) documentation:

As displays support greater ranges of color and luminance (e.g. HDR), apps should take advantage of this by increasing bit depth. 10-bit/channel color is an excellent starting point. 16-bit/channel color may work well in some cases. Games that want to use HDR to drive an HDR display (a TV or Monitor) will want to use at least 10bit, but could also consider using 16bit floating point, for the format for the final swap chain.

Re:Can someone please explain?

[Anonymous Coward]

Then perhaps you could answer arth1's question?

Re:Can someone please explain?

[Luthair]

Unfortunately VentureBeat is really not the site that should be linked to. From more technical sites apparently specs like HDR10 perform tone mapping on both the source and the display which add latency, AMD is proposing a protocol where the GPU would perform tone mapping onto the space used by that specific monitor which would eliminate latency i the pipeline.

Its too bad they're choosing to use the FreeSync brand for this since it doesn't appear to be related to the original.

Re:Can someone please explain?

[Anonymous Coward]

It actually decreases input lag, it decouples the frame rate from the 30/60/120/144Hz refresh clock and directly displays frames as soon as the GPU has rendered them, removing flicker and input lag. So if say you have a game that fluctuates between 45-58FPS rendered by the GPU the display will show you exactly what the GPU is spitting out instead of having torn partial frames displayed.

Re:Can someone please explain?

[AHuxley]

Think of it as what the better photography and movie production hardware and software have had for years.
The OS, software, driver, GPU knows about the LCD and its factory settings.
In the past user would have to buy a supported brand of display with a supporting display card and software.
i.e. the hardware and software would be "broadcast" ready without needing a user to worry about creating new settings for every project.
Now games and consumer gpu's are getting the same ability to detect each other and the design limits of a lcd.
It will look as good as a game developer wanted as they will have settings for every brand and color space of lcd supported.

Re:Can someone please explain?

[Anonymous Coward]

So other than a Freesync2-compliant monitor, what else is needed to get it to work? What video cards support this, or is it just a driver feature?

Re:Can someone please explain?

[Anonymous Coward]

It can decrease latency in scenarios where the GPU would be stuck waiting for the next frame to begin rendering, such as v-sync with a sub-par framerate.

Re:Can someone please explain?

[K10W]

Freesync 2 is all about adding HDR support for the existing Freesync standard. There is more information in the arstechnica article:

HDR on PC is a more complex beast than just panel brightness, though. First, a game performs colour tone mapping after an engine renders a scene. Then, when the frame is passed to a monitor, it's tone-mapped yet again to fit the display's supported colour range. That may or may not be the same colour space required by HDR10 or Dolby Vision. This two-stage process takes time and introduces latency. With FreeSync 2, AMD is removing the second step, connecting the game engine directly to the HDR display. When you plug in a FreeSync 2 display, the display announces its HDR capabilities, and the AMD graphics driver will shuttle that information over to the game engine. This ensures that gamers get the best possible image quality, because the game tone-maps to the screen's native colour space, while also reducing input lag. Unfortunately, it also means that in order for FreeSync 2 and HDR to work, AMD needs the specific colour and brightness capabilities of every FreeSync 2 monitor, while games and video players must be enabled via AMD's API. AMD is going to have to win over a lot of hardware partners to make FreeSync 2 a reality.

So they are getting more colours by mandating HDR and increasing performance by removing a stage from the rendering process by allowing the game to use to exact colour space of the monitor.

hmmm I am not convinced until I see some real analysis of this, TFA sounds like marketing BS with no real numbers or facts to backup. The HDR has less to do with the gamut and they don't even mention what they are comparing to, shittiest TN panel is my guess (there are some decent ones now). Gamut is more factor of the screens native bitrate and is oft extended with FRC (frame rate control). The HDR if genuine giving a lower black point with real shadow detail and higher white point WITHOUT just applying a harsh S curve would be welcome but sadly most screens even high end ones don't do wide luma well and are 7bit-ish raneg at best. What good screen DO do is not crush the f*** out of the blacks, calibrate very well even when brightness is turned way down (often the case on such a screen) and don't have washed out grey blacks when the white point is set just right.

I do a lot of 10bit end to end editing because of photo and design work where colour accuracy matters but most content will be fine in 8bit sRGB space (or the usual 6bit + frc) and consumers wouldn't see any difference between regular and true higher gamut content on those same screen (apples to apples) is my guess. True aRGB gamut monitors like Eizo and higher end NEC are nice for intended use but they don't jack of all trades because that is the price you pay for that as there is no free lunch despite what this article suggests, but they have the price tag drawback for most folks without a need for wide gamut such as making colour accurate work for subtractive reproduction (print) on additive device (screen). I care more for accuracy/how well it performs AFTER calibration than response times. Althoguh for general use I'd recommend people buy another screen than high gamut ones, I'm typing this on a cheaper LG ah-ips true 8bit panel which has alright response in film/game with overdrive working well enough. Slight smearing but hard to notice and it has decent enough photo viewing etc and nice contrast etc but I'd have to sacrifice that to get better response time by nature of tech and I doubt they have fixed the physical limitations as they'd be boasting about such a breakthrough if they had. I hope I'm wrong but doubt it.

Freesync has nothing to do with color gamut.

[BenJeremy]

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.

Re:Freesync has nothing to do with color gamut.

[Carewolf]

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.

Yeah. As far as I can tell they are trying to say they have added some HDR meta-data to FreeSync though and called it FreeSync2.. Not sure how much of that is just marketing speak though.

Re:Freesync has nothing to do with color gamut.

[Anonymous Coward]

If a refresh happens faster than the LCDs can make the transition

Then you want the monitor to switch anyway. The lagging LCD will cause a halfway transition that is similar to interpolation.
The result would be better than just updating as fast as the LCD can do full transitions.

Re:Freesync has nothing to do with color gamut.

[Anonymous Coward]

> Freesync has nothing to do with color gamut.

Sure, but if you RTFAnandtechArticleOnTheTopic you find that Freesync 2 is:

Freesync (with guaranteed LFC) + EDID information that's _correct_ (did you know that EDID lets monitors inform video cards of their color gamut? It's true!) + an API for software to uniformly and reliably query that EDID information + some uniform and correct instructions on how to do proper colorspace transformation + a testing lab to verify that a manufacturer (whether hardware or software) is not Doing It Wrong.

Microsoft could have done #3, #4, and #5 at any point since the introduction of Direct3D (waaay back in 1996), but they've _consistently_ failed to do so.

As a long-time owner of a monitor that can display the entire AdobeRGB gamut, I'm _really_ glad that AMD is ensuring that EDID information is correct, and telling everyone how to properly do colorspace transformations. It's _waaaay_ fucking past time that this shit gets sorted out.

Here's hoping that Team Green doesn't introduce their own, incompatible way of doing the color management side of things!

Re:Freesync has nothing to do with color gamut.

[AmiMoJo]

The relationship is that the PC controls the monitor directly, controlling when it refreshes the image and now how it displays colour. Without Freesync the monitor takes the video signal, processes it and refreshes the display on its own.

This sort of thing has existed in other display technologies for a while. First you had THX certified video that dictated your brightness and colour settings, and with HDR 4k the video signal actually includes extra for setting those parameters in order to make up for the limitations of current technology.

It produces a really nice image, but it also forces you to adjust your environment rather than simply adjusting the picture.

Re:Freesync has nothing to do with color gamut.

[Anonymous Coward]

> The relationship is that the PC controls the monitor directly, controlling ... how it displays colour.

No, not quite. Read the Anandtech.com article on the topic. It's pretty clear that the color management part of Freesync 2 is

1) Ensuring that EDID (or similar) information about the monitor's color gamut is _present_ and _correct_.
2) Providing a uniform and _correct_ method for getting that information.
3) Providing a uniform and _correct_ method for mapping your program's color space into the monitor's color space.

Because software now knows without a shadow of a doubt what the monitor's color space is, it can perform a _single_ color transform operation (from the software's color space to that of the monitor's) and the monitor can just display the color data it has received.

Previously, (if you were even _aware_ that there's more to color than just fucking shit-ass sRGB) you had no fucking clue whether or not the EDID gamut information presented by the monitor was correct, so your program
* emitted color values
* which were transformed by the color management subsystem in the OS (even if that transform was from sRGB to sRGB)
* and were then transformed _again_ by whatever colorspace clamping routines were running on the monitor.

What's more, you don't even have to modify old games to work with this! You can pretty reasonably assume that old games were working with something _very_ close to sRGB, and program the driver to know that software that uses OpenGL or D3D (or whatever) that _hasn't_ activated the FreeSync 2 color management APIs is in this really-close-to-sRGB colorspace, and do the transformation to the monitor's colorspace on behalf of the game.

Re:Freesync has nothing to do with color gamut.

[thegarbz]

Freesync doesn't. Freesync 2 does.

Blatant advert or what?

[JustNiz]

>> 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

Re:Blatant advert or what?

[Anonymous Coward]

You're 100% sidestepping the reality of this issue using semantics because you're a moron.

Re:Blatant advert or what?

[Gadget_Guy]

Since when ever was this NOT happening? , specially with digital interfaces such as HDMI.

Consumer-level LCD monitors don't show the full colour gamut. It varies between monitors exactly how much of the computer's idea of the colour range can be displayed. This will only get more complicated as monitors start offering HDR.

FreeSync 2 allows the monitor to tell the computer exactly what it can display so the graphic cards can output the exact colours that can are supported. This eliminates the need for the monitor to convert the video's colours on the fly. Supposedly this makes it faster to display, although given how fast monitors are now I'm not sure how much difference it will make.

Re:Blatant advert or what?

[Fly Swatter]

Many monitors do not support the full color spectrum, instead they dither colors to be 'closer'. This can cause unwanted artifacts. Also it will make some pixels 'not what the computer software intended'. Using a digital interface such as hdmi or displayport will not help in this case.

Re:Blatant advert or what?

[thegarbz]

If you send 255,0,0 to your monitor I guarantee you'll end up with a different red shade as when I send it on mine. The monitor is oblivious to what colour you actually want to display. In Windows we call this colour management. In games we call this non-existent.

This is the problem trying to be solved here.

Re:Blatant advert or what?

[thegarbz]

Sort of right but you're looking at the wrong problem. This doesn't solve dithering. You still have to dither if you want to fill in the gaps in what the monitor can display, but even if you didn't want to, this is a problem limited to the most cheapest and nastiest of screens with a technology that is rapidly going out of fashion (6bit TN film panels).

Instead what is being targetted here is a new range of monitors with a larger colour gamut than standard, and the fact that there's no way to currently tell the computer what gamut the monitor has beyond downloading from the internet or generating an ICC profile, and even then Windows only provides this information via an API, actual games don't implement colour correction.

Re:Blatant advert or what?

[Anonymous Coward]

You are total bullshit. You could have read any other comment, or the article, or anything. What a douche.

As opposed to...

[wonkey_monkey]

Is this as opposed to all those monitors that just display whatever pixels they want to?

Those must suck.

Re:As opposed to...

[thegarbz]

So all of them then. After all there's no way to tell a monitor what colour you should display. At the moment all you can tell a monitor is what to do with the output of each pixel. The resulting colour itself is entirely left up to the monitor itself.

Re:As opposed to...

[Anonymous Coward]

No consumer monitor and only a small number of professional monitors support the full 16-bit, let alone 24-bit color gamut, this addition to the VESA standard that AMD is pushing will allow for reduced input lag and increased color accuracy by having the monitor tell the computer exactly what it can actually handle instead of the monitor having to convert colors that the GPU assumes are supported and having to interpret them.

Freesync is a part of the VESA spec, but it is optional, it is however supported by AMD and Intel, Nvidia is resisting it with their own proprietary tech called GSync.

Nvidia is still better

[Billly Gates]

It has more support and no mouse lag. Nvidia for life

Re:Nvidia is still better

[Anonymous Coward]

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...

Re:Nvidia is still better

[Anonymous Coward]

You're a moron for life, agreed.

from the AMD graphics division shilling dept.

[Anonymous Coward]

why is this this article not clearly marked "Sponsered content" like some of the other shit that get's posted?

Huh? You are wrong

[Kartu]

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

Re:Huh? You are wrong

[Anonymous Coward]

That's exactly what I was thinking, just like the UHD Premium standard...if your monitor supports Freesync 2 standard, it'll support all that's in it.

That said, it doesn't stop this article from feeling like an article bought and paid for by AMD.

Not ONLY about it

[Kartu]

AMD also applies stricter rules, e.g. LFC must be supported to get FreeSync 2 certified, etc.