Thracks

Would work on any GCN-based product. It is very important to note that Mantle is like any other API, though, and a developer has to choose to support the feature. Here and now, developers are much more interested in simply learning the API and cutting down software overhead. Getting better multi-threading, reducing overhead and having an API that can fully saturate the GPU resources are mission critical for the next 10 years in gaming. Collectively, the development community just started on that with Mantle, so it will take time to explore the more exotic features. //EDIT: I'm reminded that the initial applications with any API are relatively rudimentary. Things like contact-hardening shadows, global illumination, compute depth of field were unthinkable in the earliest DX11 titles. But here we are, global illumination can be done with DX11 now, and was shipped in a real game in 2012(ish). So, yeah, this is normal for the industry.

Non-mirrored VRAM isn't the only cool thing you can do with mGPU in Mantle. You can also create an asymmetric CrossFire configuration between GPUs of substantially different performance envelopes, then load-balance the workloads between them so each card runs at peak performance. For example, you could have the dGPU do geometry and lighting, where an APU can do physics and AI work. You can also asynchronously schedule compute and graphics workloads at very fine granularity, which is tremendously helpful to the latency of a VR solution. You could do split-frame rendering, which treats mGPU as a single faster GPU. No AFR latency penalty, no queue depth. In every way it will behave like one GPU with the resources of two. Mantle can do its own command buffer prediction, where the command buffer is the stream of work sent to the CPU by the game, which the CPU reorders for the GPU. Typically the CPU would have to calculate scenarios for the command buffer, working ahead of the game to predict what will happen for peak performance. All of this ahead-of-time calculation has to be shared with the GPU, with the GPU replying back with what it's currently doing. You can eliminate all of that round trip performance junk if the GPU is able to make its own estimations based on the knowledge is has of its current rendering state. This applies to any sort of graphics config if the developer chooses to use it. You can do per-eye rendering with mGPU, with each GPU giving full performance of a GPU to one eye in a VR or stereo3D configuration. There's so much more lurking in that API that is so far beyond what we think of as "rules" in the PC industry about how CPUs and GPUs should work together, or MGPU must be done. I'm pleased to see people are interested in this kind of stuff in Mantle.

This is not a power AMD can give. We don't control the firmware or make the monitors.

By "charge extra," surely you mean "pay for the man hours and expertise required to perform additional validation/QC of a variable refresh LCD panel." Tell ya what's not free: labor.

I don't understand this conspiracy theory. Is there anyone that doesn't understand that a monitor has upgradeable firmware, and that Nixeus worked with us to use their monitor as a proof of concept? The tcon's silicon was given new firmware. Voila: DP1.2a and FreeSync across a range allowed by the LCD. //EDIT: Sorry about the double post. Forgot to use multiquote and didn't see a merge ability.

1) We do not charge licensing, royalties, or any other sort of cost for FreeSync. That's free. 2) For a monitor manufacturer that already has the appropriate panel and scaler in their supply chain, FreeSync is a firmware choice. The firmware is free from the scaler supplier. 3) DisplayPort Adaptive-Sync is free. In fact, all of DisplayPort is free to license. 4) Validating an LCD with dynamic refresh costs more in man hours than a fixed refresh display. This is not free. But this is something every dynamic refresh technology must go through, so the point is moot. This cost could be passed on to the consumer, or it could be absorbed by the display vendor as a margin hit. This is not AMD's choice to make. 5) Monitors are not free. If they were, well, I'd have more than my desk could reasonably accommodate. 6) Most of our current-gen GPUs support it. Alas, some do not have the relevant IP in their display controllers to enable highly variable refresh rates. Yes, those people will have to upgrade. Yes, that is not free. Aside from monitor companies just giving displays away, FreeSync is in every possible way free as a technology. No licensing, no incremental material costs, no royalties. Nothing. I don't know how much more clear I can make it.

Hi!

You clearly have your opinions on the matter and are entitled to them. I've explained the facts as they are. What you do with those facts is your discretion.

A good question, and a couple reasons: 1) An industry standard just takes time. There are rounds of submission, editing, voting, drafts, etc. You have to finish the spec (Adaptive-Sync) and get it ratified in the body before you can ever truly begin the software development of new firmware. Big multi-party consortiums are by necessity pretty slow, because the standard has to be fair and equitable to all participating parties, and everyone has an opinion. 2) Okay, now the spec is done. Now you have to get support from scaler vendors, which means months and weeks of meetings and pitches and proposals and technical demonstrations. 3) Okay, now there's scalers. Repeat the same pitch process for monitor vendors using those scalers. 4) Okay, now you've convinced the industry's biggest vendors. Software development isn't lightning fast, either. A monitor scaler is a complicated piece of silicon, and it takes time to design an entirely new piece of firmware on an entirely specification. Then, and most people don't know this, the monitor QA period is incredibly long. That's it. It takes time to build an industry standard, and then get people onboard, then they have to build things.

This is accurate. Sort of. What most people probably don't think about is what kind of electronics run their monitor. We all go gaga over great panels, but great scalers--those electronics--are just as vital. There are three vendors in the world for those scalers: Realtek, MStar and Novatek. All three of them support FreeSync in their portfolio. This support was predominantly achieved by developing new firmware that utilized latent capabilities in the silicon of the units already in mass production. That is to say, if a monitor vendor is using one of these scalers in their units or supply chain, now they only need to obtain a different ROM for their monitor and validate the monitor for DRR. Tada: a FreeSync monitor is born, with no licensing or material costs beyond what they were already going to pay to build that monitor. Nor do we charge any sort of royalty fee. This is what puts the "free" in FreeSync. We made it as simple and as economical as possible for monitor guys. There are certainly other scalers in the world that were not so lucky. For whatever reason, the silicon doesn't support DRR, or didn't support a range that would be "useful" for gaming. Monitors based on these scalers could not be retooled or upgraded, so the manufacturer would need to bring a new SKU into their lineup with a different scaler. Finally, the scaler guys are also working on new SKUs to entice monitor vendors into sourcing them for new designs. These scalers are adopting FreeSync also, because the expertise and the Adaptive-Sync standard is already established and incorporable. Like 4K, audio, daisychaining, and a whole host of other features, Adaptive-Sync is an optional feature of the 1.2a spec. Not every 1.2a monitor can be FreeSync, for the technical reason I described above, or simply because the vendor does not want to adopt the optional feature. I hope that clears things up.

PM sent. Thanks!

The tool didn't support roaming framerates then. It does now, and the footage from CES at TechReport et. al. will show you that. Even so, having a fixed framerate can still demonstrate stuttering and tearing. There is a common misconception that matching the framerate to the refresh rate will solve all tearing, but that is patently false. Furthermore, please see the comments from Nixeus that confirm my own.

Yep. Three posts. Just because I don't post doesn't mean I'm not watching. OOOOOHHHHH *spooky noises* But seriously. Most people can find me on Twitter (where I just sent out a tweet confirming my identity for interested people), and sometimes I post on Reddit/OCUK/OCN.

I'm afraid I cannot really comment on behalf of our partners. It's not my place, and I happen to like my job and not getting yelled at.

I've lurked for a very long time. But nothing rustles my jimmies like incorrect conspiracy theories.