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.

Comments Locked

38 Comments

View All Comments

  • dreamcat4 - Wednesday, March 2, 2016 - link

    > The bandwidth needed for 8K @ 144hz is probably not gonna be possible over copper

    Ahh. But it what about HMDs with foveated rendering? If the standard included an appropriate mechanism to compress the the outer regions of the display much more. While leaving the central area intact / uncompressed. That would result in maximum fidelity / per the available bandwidth. And higher refresh rates too.
  • boeush - Thursday, March 3, 2016 - link

    I doubt foveated rendering will ever be practical. It would require very accurate and very fast iris tracking, with hardware response (full round-trip) in single-digit milliseconds if not microseconds. And that's even before accounting for effects of accommodation (where the effective FOV projected onto the fovea can change dynamically just by flexing the lens of the eye.)
  • nathanddrews - Wednesday, March 2, 2016 - link

    They are most certainly not more flexible than copper. Depending upon how many fibers the cable needs and accounting for bi-directionality (needed for DRM and EDID among other functions), to get the bandwidth needed you could very well be looking at a heavier and thicker cable, at least with modern, affordable technology. I can't even imagine how expensive the interconnects for that type of optical cable would be. I think we'll have a copper solution long before we get an optical one.
  • boeush - Thursday, March 3, 2016 - link

    What? You can send signals bidirectionally through a single fiber, without those signals interfering (light passes through light without interacting), unless you were deliberately designing the fiber and tuning the frequencies to create some kind of nonlinear-optics side-effects. Similarly, if you need to send multiple data streams through a single fiber, you just send them concurrently on separate wavelengths. All it (and bidirectional transmission) requires, is a beam-splitter and a prism at each end (receiver and transmitter).

    As far as flexibility and weight, compare a typical optical SPDIF cable vs a typical DP/HDMI cable. The latter have to be thick and heavy due to multiple twisted pairs, and shielding/insulation.
  • ikjadoon - Wednesday, March 9, 2016 - link

    I have no idea about the rest of your discussion, but I was so surprised how thin and flexible my sound system's optical cable was. I was like...did they finish manufacturing the cable? Did they forget to fill in the wire in the middle? Felt like a thin empty plastic tube....that is, until you plug it in and see the red lights shining out of the cable, hahahaha.
  • B3an - Thursday, March 3, 2016 - link

    Any ETA on DP 1.3 hardware? It's taking way too long.
  • xenol - Thursday, March 3, 2016 - link

    Variable refresh rates are still optional. *sigh*

    I would love it if VESA would make it mandatory, thereby not giving monitor makers an excuse to slap on "gaming" markups on monitors with it.
  • zodiacfml - Monday, March 7, 2016 - link

    The solution could be useful for industries who can't wait for the next generation speeds but it is still not a optimal solution for a bandwidth problem. Though another interface is what we need right now, making a new display interface based on optics is the next step.

Log in

Don't have an account? Sign up now