One of the more interesting aspects of the DisplayPort standards is how the VESA has the separate but strongly intertwined DisplayPort and Embedded DisplayPort standards. As a result of the standard development process, we see a bit of ping-ponging between the two standards on features. New features get adopted by one sub-standard or the other first, and then after a bit of time show up in the next iteration of the other standard. What would become DisplayPort Adaptive Sync, for example, first started out in Embedded DisplayPort, while the newest bandwidth mode, HBR3, started out on DisplayPort.

After an update for the Embedded DisplayPort standard last year with eDP 1.4a, being announced this week is the next iteration of the DisplayPort standard, bringing it to 1.4. And like the examples above, this is another case where some features are making their way back from eDP to the mainline DP standard, while at the same time new features are coming to the DisplayPort family for the first time. To that end, DP 1.4 is a mix of both old and new, and while also serving as interesting case in highlighting how the two DisplayPort standards differ and why this is necessary.

First off then, despite the updated version number and unlike previous DisplayPort “point updates,” the latest update does not change the physical layer for DisplayPort. HBR3, introduced with DisplayPort 1.3, remains the newest and fastest bandwidth standard for DisplayPort.

Instead what has changed for DisplayPort 1.4 is the DisplayPort feature set, and in a major way. Surprisingly absent in DisplayPort 1.3 was support for the VESA’s Display Stream Compression standard, which uses lossy (“visually lossless”) encoding to cut down on bandwidth needs, allowing for display setups with fewer lanes or at higher resolutions – such as 8K uncompressed – that can’t be carried within the bandwidth limitations of DisplayPort. Rather the first VESA standard to include DSC was last year’s Embedded DisplayPort 1.4a, and now a year later, DisplayPort is finally adding DSC support with the 1.4 standard.

As we’ve since found out, there are a couple of good reasons for why we haven’t seen DSC in the mainline DisplayPort standard until now, and with 1.4 the VESA has finally addressed those issues to allow DSC to be included in the standard. Of particular interest here is support for Forward Error Correction (FEC), which the VESA considers necessary for DSC on external monitors.

From a signal integrity standpoint, as displays are the highest bandwidth external interface on a typical PC, we’ve known that the VESA has been pushing the envelope on external signaling for quite some time now. This is part of the reason vendors are coalescing around USB Type-C, as it’s easier for vendors to all back a single well-developed solution. In the case of HBR3, this means pushing 32.4Gbps over a 4 lane connection, which is easy in a short run inside a laptop measured in centimeters, but it is a greater challenge with DisplayPort cables extending up to 2 meters. Practically speaking, while a solid DP1.3/HBR3 setup shouldn’t see any errors to begin with, the real world error rate – though quite low – is still higher than would be ideal.

For uncompressed images this isn’t an issue; any corruption is limited to a handful of pixels and quickly corrected in the next refresh. However once DSC is brought into the fold, any errors become a much larger problem. An error in a compressed data chunk will cause decoding to fail or make the decoded result very wrong over a large number of pixels, making the error far more noticeable. Consequently DSC requires a high level of reliability, which eDP with its short runs could provide, while DP’s longer runs could not.

The end result is that the combination of DP 1.4 and the recently released DSC 1.2 specification include Forward Error Correction for DSC. Although Forward Error Correction increases bandwidth requirements slightly, the additional, redundant data it carries allows for errors to be corrected, making DSC suitably reliable over DisplayPort connections. This is the key change to DSC and DisplayPort that finally allows DSC to be deployed to external monitors.

Meanwhile at DP 1.4 is also the first DisplayPort standard to incorporate DSC 1.2, it also becomes the first standard to gain DSC 1.2’s other benefits. Along with the aforementioned error resiliency, DSC 1.2 introduces some new functionality specifically for HDR displays. The compression standard now supports 4:2:0 and 4:2:2 color spaces and has added 14-bit and 16-bit per channel color support to the existing 8/10/12-bpc supported bit depths. In this case the VESA has their eye on HDR with displays over 4K, as while DP 1.3/1.4 offers enough bandwidth for HDR at 4K, this is where it tops out.

Display Bandwidth Requirements (RGB/4:4:4 Chroma)
Resolution Minimum DisplayPort Version
1920x1080@60Hz, 8bpc SDR 1.1
3840x2160@60Hz, 8bpc SDR 1.2
3840x2160@60Hz, 10bpc HDR 1.3
5120x2880@60Hz, 8bpc SDR 1.3
5120x2880@60Hz, 10bpc HDR 1.4 w/DSC
7680x4320@60Hz, 8bpc SDR 1.4 w/DSC
7680x4320@60Hz, 10bpc HDR 1.4 w/DSC

While on the subject of HDR, DP 1.4 also includes some HDR functionality of its own. The other major addition for the 1.4 standard is support for HDR static metadata, specifically the CTA 861.3 standard already used in other products and standards such as HDMI 2.0a. While the full details of what it takes to implement HDR are beyond the scope of this article, HDR static metadata is specifically focused on recorded media, such as Ultra HD Blu-Ray, which use static metadata to pass along the necessary HDR information to displays. This also improves DP/HDMI interoperability, as it allows DP-to-HDMI adapters to pass along that metadata.

The last new feature being introduced with DP 1.4 is updating the audio formats supported by the DisplayPort standard. As with the video portion of the standard, this is focused on functionality since the physical layer (and available bandwidth) haven’t changed. The VESA specifically notes that this latest update adds support for items such as 32 audio channel configurations, and while they don’t say its name, this sounds like the underpinnings for supporting decoded Dolby Atmos audio.

Wrapping things up, like previous DisplayPort specification announcements, we’re expecting some significant lag time between today’s announcement of the DisplayPort 1.4 standard and when this functionality shows up in shipping products, as manufacturers still need to develop controllers implementing the standard. As it stands we still haven’t seen any DisplayPort 1.3 equipment hit the market yet (this despite being introduced in 2014), so it’s likely that DisplayPort 1.4 is some time off. Meanwhile as DSC is always a hot topic in our comment section, so far we haven’t heard anything about plans for monitors to actually implement it. Most likely we won’t see anything until monitors with resolutions over 5K hit the market, as the primary focus of DSC for external monitors is for ultra-high resolution monitors coupled with HDR. It's here where the uncompressed bandwidth requirements become well in excess of what DisplayPort could provide.

POST A COMMENT

38 Comments

View All Comments

  • Pork@III - Wednesday, March 2, 2016 - link

    DP 1.4 is too late. Maybe first in real devices we use it in 2018. Reply
  • Fallen Kell - Wednesday, March 2, 2016 - link

    Why do you think it is too late? The article says the physical layer has not changed. The difference then is simply firmware and controller capability, which may simply mean swapping one chip for a different one. Reply
  • fazalmajid - Wednesday, March 2, 2016 - link

    I would expect the compression and FEC logic to be significantly more complex than any other DP feature other than HDCP. Reply
  • Pork@III - Wednesday, March 2, 2016 - link

    You maybe master of change of chip in your display and your videocard? Reply
  • blahsaysblah - Saturday, March 5, 2016 - link

    https://www.reddit.com/r/Amd/comments/48e8rl/radeo...

    From AMD AMA on reddit the other day:
    - Are the cards going to have any overclocking potential, or is this going to be another fury situation? Will the cards come with DP1.4?

    Answer:
    We will discuss specific SKUs and overclocking capabilities at product launch in mid-year.

    They will come with DP1.3. There is a 12-18 month lag time between the final ratification of a display spec and the design/manufacture/testing of silicon compliant with that spec. This is true at all levels of the display industry. For example: DP 1.3 was finished in September, 2014.
    Reply
  • dreamcat4 - Wednesday, March 2, 2016 - link

    Hi there. Its understood the need for a higher resolutions support. But aren't we missing a fact that such an extra compression could also be useful for driving 4k gaming monitors at higher refresh rates? It seems like we really need that for newer premium gaming monitors. Especially the ultra-wide ones. No mention of that in the article here. Reply
  • nathanddrews - Wednesday, March 2, 2016 - link

    DisplayPort 1.3 already supports 4K 8-bit @ 120Hz and 4K 10-bit @ 96Hz.

    http://www.displayport.org/faq/#DisplayPort%201.3%...
    Reply
  • TristanSDX - Wednesday, March 2, 2016 - link

    what is the limit for bandwidth for wire like this (cable monitor) ? Currently DP 1.3 have 8 Gbps for single wire, and this is good speed, the same level as PCI-E 3. Can it go further, to 15 or 20 Gbps, or there are limitations ? Reply
  • jasonelmore - Wednesday, March 2, 2016 - link

    Seems like the Displayport, HDMI, and other display standards need to start looking into optical protocols/cables moving forward. The bandwidth needed for 8K @ 144hz is probably not gonna be possible over copper, and definitely not ideal for a peripheral that could have varying lengths of cable. Reply
  • boeush - Wednesday, March 2, 2016 - link

    Yep. Never mind the likes of 8k at 240 Hz with 16-bit HDR, which would begin to approach the ideal specs for high-quality VR (at 4k per eye). Optical cables are also thinner, lighter, more flexible. And with potential for multi-wavelength multiplexing (at the cost of wider encoder/transmitter/receiver/decoder implementations), optical cable bandwidth can grow well past the terabit/sec range - with virtually no cable length limits (within reasonable constraints of a typical home's dimensions.) Reply

Log in

Don't have an account? Sign up now