After pushing DisplayPort Freesync out the door earlier this year, back at Computex 2015 AMD began demonstrating a further Freesync proof-of-concept implementation: FreeSync over HDMI.
Implemented over a customized version of HDMI 1.4a and utilizing a prototype Realtek timing controller (TCON), AMD was able to demonstrate variable refresh rate technology running over HDMI. At the time of the presentation AMD was very clear that the purpose of the presentation was to shop around the concept and to influence the various members of the HDMI consortium, but they were also clear that bringing variable refresh rate tech to HDMI was something the company wanted to bring to retail sooner than later.
Sooner, as it turns out, was the operative word there. As part of their presentation last week, RTG has announced that FreeSync over HDMI will be heading to retail, and that it will be doing so very soon: Q1’16. This is just a year after the first DisplayPort adaptive sync monitors hit retail, which for a display technology is a rather speedy turnaround from proof of concept to retail product.
Now there are some key technical differences from FreeSync over DisplayPort(FS-DP) that should be noted here. Unlike FS-DP, which was just AMD’s implementation of DisplayPort adaptive sync on their GPUs and software stack, FS-HDMI is not an open standard, at least not at this time. HDMI does not have a variable refresh rate technology standard, and while RTG is pushing to have one included in a future version of HDMI, the HDMI consortium moves too slowly for RTG’s tastes. As a result RTG is looking to go it alone, and will be implementing FS-HDMI by creating a vendor specific extension for HDMI.
The use of vendor specific extensions is perfectly legal within the HDMI standard, but it does mean that FS-HDMI is proprietary, at least until such a time where the HDMI standard adopts a common variable refresh rate standard. This means that FS-HDMI monitors will need to support RTG’s proprietary extensions, which in turn requires TCON/monitor vendors to work a bit more closely with RTG than was necessary with FS-DP. Meanwhile RTG for their part hasn’t yet decided what to do about the proprietary nature of their implementation – they are open to sharing it, but they also want to retain control and avoid any scenario that results in outright balkanization of HDMI variable refresh rate technology. The fact that it’s an RTG-controlled specification calls into question whether any other GPU vendor would want to implement it in the first place – so concerns about openness may prove to be moot – but it does mean that it’s going to be up to RTG to make or break FS-HDMI.
Perhaps more surprising, and certainly a feather in RTG’s cap, is that RTG has brought so many TCON vendors on-board so early. Along with Realtek, Novatek and Mstar will all be producing TCONs that support FS-HDMI, so TCONs will be available from multiple vendors relatively quickly. With variable refresh rate tech it’s the TCONs that really decide whether the tech is supported, so this is an important set of partnerships for RTG to lock in so soon. Meanwhile traditional AMD/RTG display partners such as Acer, LG, and Samsung will be producing retail monitors with FS-HDMI capabilities.
Meanwhile at this point RTG isn’t talking about GPU compatibility in great detail, however it sounds like FS-HDMI support will be brought over to some of RTG’s current GPUs. Most likely these are the GCN 1.1+ Radeon 300 series cards, with GCN 1.1 also being the minimum requirement for FS-DP. AMD’s Carrizo APU should also support the technology, and RTG is specifically promoting that notebooks implementing an APU + dGPU Radeon dual graphics configuration will also support FS-HDMI, an important development especially given the fact that DisplayPort support is non-existent on consumer AMD laptops.
In fact the lack of DisplayPort availability in displays overall is a big part of why RTG has pursued this. According to numbers from RTG, only about 30% of all monitors sold include a DisplayPort, while the other 70% are only implementing HDMI or HDMI + DVI. Consequently FS-DP is an inherently limited market and the majority of monitor buyers will never be able to use FS-DP. Meanwhile from what I hear the actual cost of implementing variable refresh rate support on a TCON is very low, which means that RTG could get far greater penetration for FreeSync by extending it to support HDMI, not to mention bringing down the overall cost of entry-level FreeSync monitors. We’re still talking about a highly price sensitive commodity market – after all, there’s a reason that most monitors don’t ship with a DisplayPort – but if the costs of adding FreeSync are as low as RTG hints, then there is a market for consumers who would spend a bit more on a variable refresh rate monitor but don’t know anything about display I/O standards beyond HDMI.
Finally, along those lines, it should be no surprise that the first FS-HDMI monitors that have been announced are all focused on lower cost and lower resolution displays. That FP-HDMI is being implemented over HDMI 1.4 immediately rules out 4K monitors, so instead all announced monitors are 1080p or ultra-wide 21:9 aspect ratio 2560x1080 and 3440x1440 monitors. Otherwise there are a few more unknowns here that I expect we’ll see addressed ahead of the Q1 launch, particularly which monitors will support a wide-enough range of rates for low framerate compensation to work.
FreeSync Laptops: Shipping Now
Along with the FreeSync over HDMI announcement, RTG also used their event to announce the first FreeSync-capable laptop, the Lenovo Y700. One of the models of the laptop ships with a variable refresh rate capable 15.6” 1080p IPS panel, and when paired up with a Carrizo APU and R9 M380 GPU, can utilize FreeSync to control the refresh rate. The one notable limitation here is that while this otherwise a rather typical DisplayPort adaptive sync setup within a laptop, the specific panel being used here is only supports a range of 40Hz to 60Hz, so the first FreeSync laptop has a narrow effective range and can’t support LFC.
ncG1vNJzZmivp6x7orrAp5utnZOde6S7zGiqoaenZIZ5f5VomKacXaq7t7HIpapmamBmg27CyKyrnpuYYr%2BwrcOmmKlnYg%3D%3D