- Rage3D Home Page
- Discuss This Article
AMD Eyefinity & DisplayPort Difficulties
Author: James Prior
Editor: Charles Oliver
Date: February 7th, 2013
AMD Eyefinity & DisplayPort Difficulties
Over that past three years I've been using ATI (now AMD) Eyefinity technology quite extensively, and one bug bear has persisted over that time - DisplayPort Link failures. My first setup came courtesy of AMD themselves with the launch of the AMD ATI Radeon HD 5870 Eyefinity 6 edition, a graphics card test that came replete with six Dell P2210h monitors featuring the all important DisplayPort input connector. Until ATI Eyefinity was revealed on the USS Hornet in 2009, just weeks before Windows 7 and the new AMD ATI Radeon HD 5000 series launched, consumer graphics cards were restricted to dual displays. Eyefinity changed all that, using the newly developed DisplayPort specification outputs on the AMD ATI Radeon 5000 series and Windows Vista and newer OS.
The essence of AMD's Eyefinity technology is simple; the GPU has the capability to drive six independent displays, broken down as two displays that AMD terms 'legacy' displays, DVI/HDMI/VGA, and up to four DisplayPort displays. There is some flexibility there as cards can be equipped with all DisplayPort outputs (like the AMD Radeon HD 5870 Eyefinity 6 edition) or have a mix of all different kinds, for flexibility. DisplayPort connectors come in full and mini sizes for consumers, with the switch over from full size on the card to mini size on the card occurring in the AMD Radeon HD 6000 series. DisplayPort is preferred over standards like HDMI and DVI due its royalty light nature, customizability, and bandwidth. AMD's Add-in board (AIB) partners have flexibility to choose what outputs they have on their boards, but typically follow AMD's reference designs to reduce their costs, at least at each series launch. Sapphire's FLEX technology neatly sidesteps the DisplayPort requirement, permitting three 'legacy' outputs, as do Active DisplayPort Adapters.
AMD Eyefinity mode differs from extended desktop modes in that it presents the attached screens as a single large surface (SLS) to the user, you can stretch games in full screen mode over the attached displays without extensive retooling by the developer, if you don't mind some niggles with aspect ratio or field of view, and HUD/menu placement. Eyefinity was a game changer, at the time of introduction it allowed ultra-enthusiast gamers to get more pixels for cheaper, typically you could buy three 22” 1080p DisplayPort panels for less than the cost of a 27” or 30” 2560x1440 display. Released soon after, AMD's Eyefinity SDK documented the driver hooks that developers can use to do clever things like know where bezel edges are and ensure HUD elements aren't hidden under them, and it's probably just a matter of time before it occurs to some developer to spawn AI or begin attacks in the bezel compensated hidden regions on Nightmare difficulty campaigns. I hope I didn't just give anyone a bad idea ...
To enter SLS mode you need to create an Eyefinity group, the process by which you enumerate your attached displays location and orientation, before specifying things like bezel compensation, taskbar positioning (if you don't want it spread over all displays width) and which display to move UI prompts to. Mega-taskers can extend this further with HydraVision, which allows compartmentalizing windows to predefined Eyefinity monitor bezel boundaries and to custom sub-dividers beyond that. Of all these things, the part that has given me the most trouble over the years is step 1, creating the Eyefinity group.
When you've invested a lot of money in something, when it has problems you are irritated. Looking for someone to resolve the problem, you complain to the guy that sold you the expensive bit - typically the GPU manufacturer; after all, they sold on you the idea in the first place. This bias is usually confirmed by things like different drivers offering different levels of resolution for issues, we've seen many times a new driver touting performance for the latest and greatest game take out something else along the way. My experience with moving from Catalyst 12.11 beta to 13.1 WHQL appeared to be one of those, as I just spent a number of hours on our new smoothness testing analysis with lots of time in Eyefinity under Catalyst 12.11 beta only to install 13.1 and literally lose 6 hours trying to do what I'd just done before for weeks on end. Given that Catalyst 13.1 WHQL were supposed to be final tweak versions of the 12.11 beta, this was endlessly annoying and it wasn't until I'd vented on the Rage3D forums that a helpful forum member pointed out another possibility - the display cable.
DisplayPort is a standard from VESA, the Video Electronics Standards Association, and is a royalty free digital display interface designed to replace VGA, DVI and LVDS connections to displays. The essence of DisplayPort is a much higher bandwidth and more flexible form of working with attached displays by utilizing micro-packets of data instead of serial or parallel signaled forms. This allows for multiple data streams to be encapsulated in one connection, allowing (like HDMI) embedded LPCM audio, but also extending to USB and Ethernet as well. With this type of flexibility, the standard has evolved since its inception in 2006 and now at revision 1.2 includes HDCP, Stereo3D, global time code synchronization, daisy chaining and a new subvariant known as MyDP.
MyDP (MobilitY DisplayPort) is used for connecting portable devices or devices that need to be powered from the Display itself - it transmits power. The Google Nexus 4 features MyDP compatibility; you can charge it from a DisplayPort screen while using the screen and you may know this feature better by the name SlimPort, a product from Analogix Semiconductor which comes in variants for DisplayPort, VGA, DVI and HDMI. The essence of MyDP is one end of the cable is a DisplayPort connector for your display, the other is customized or even built in to the device you're powering. In the case of the Nexus 4 it looks like you're plugging in a microUSB cable, just like your charger or sync cable. Variations of this have been demonstrated by AMD as well, Project Lightning Bolt allows you to charge a laptop and provide USB 3.0, Ethernet and display connectivity (with audio) over a single cable.
What does this have to do with Eyefinity? Well, it's all about ecosystems, certifications and logos. The standards for using the DisplayPort logo are clearly laid out in the standards: a consumer display cable must not pass power back from the display, that's reserved for MyDP and embedded applications where the use is specifically controlled. What the post on the forums opened my eyes to was that his cables, and therefore possibly mine, were not actually DisplayPort compliant. They permitted the voltage source on the monitor to connect to the card, the 3.3v supply line used to charge phones or power dongles and adaptor.
This realization hit me like a Hollywood movie, flashbacks to incidences of unexplained behavior that I'd attributed to drivers. Thinking systemically about AMD Eyefinity, I'd considered four components, video card, driver, display and application. All the times I'd had unstable overclocks under Eyefinity that were perfectly fine at single display - DVI - configuration; the constant rejiggling of cables and mini-DP to DP adapters, making my own stress release loop; the simple power cycle of the displayport link failure display to get the group back working; booting up and then plugging in the extra displays to get around cold boot niggles, incorrectly ascribed to a CPU overclock; the time I hooked up a mobo and video card open bench to a DisplayPort monitor and wondered at the standby light being lit up, without a PSU plugged in - these incidents hit me like the Picard of a thousand facepalms. Damn, the signs were all right there and my BSc in n Electrical & Electronic Engineering was as unused and useless as toilet paper. D'oh!
Putting the multi-meter on a card connected to a display, I soon found I could replicate the results seen in the forum - there it was, voltage on a card where there should be none. I reproduced this on a Radeon HD 6670, 6870 and 7970 - all gave a power reading on Pin 20 of the DisplayPort connector. I used the original DisplayPort cables AMD had sent me with the ATI Radeon HD 5870 E6, and another mini-DP to DP cable I'd bought when AMD switched to mini-DP on cards, in an attempt to see if removing adapters would increase reliability of the Eyefinity experience. Both cables have the official VESA DisplayPort logo, and both supply voltage from the monitor to the card. Bugger. I tried one final card, an NVIDIA GeForce GTX 680, which behaved slightly differently - the sink voltage was present for a fraction of a second and then dropped to zero. It remained zero for around 4 seconds and then returned to the same reading as seen on the Radeon's, only to drop again. This cycle continued as long as I wanted to sit and watch the process, indicating the presence of a type of drain circuit on the pin, presumably to handle circumstances just like this. Brownie points to NVIDIA, but we need more time with the card in Surround to be sure.
So where does that leave you, dear consumer? You have a logo ecosystem that isn't compliant; the DP logo isn't enough to give you the information you need. I contacted VESA to get more information about what is happening here, and they agree it's likely a non-compliant cable.
VESA: Power is provided by the DisplayPort connector on both the Source and Sink side (500mA at 3.3V, which is 1.5 watts). Power is not carried through a standard DP cable, otherwise the Source and Sink power supplies would conflict. Power is carried in a MyDP cable, however, to provide power to the MyDP Source (such as smartphone or tablet). Power is also used by a DisplayPort display adaptor by the Source, or for an active cable. Power is also used for a DP-to-optical converter at the Source, and optical-to-DP converter at the Sink and can be used this way for other signal conversion as well at either end. Power is not, however, carried through a standard DP cable. For one, there is no need for this and two, problems can result as described above.
VESA publish a database of tested components that have passed their strict compliance testing, and there's a whopping list of one, count it, one DP cable. In the graphics cards section the HD 7970 and HD 6870 are listed but not the GeForce 680 or the HD 6670, but the listing of FirePro and Quadro cards indicates both companies take the certification very seriously.
I contacted AMD about this and they have the following to say:
AMD: We have passed all of the DP1.2 CTS compliance testing, so our implementation meets spec as much as the CTS can verify. DP_PWR is meant for powering source and sink side dongles, and you are correct in your assessment of the spec, that it should not be passed through on a 'compliant' DP cable.
AMD: Our board level implementation assumes that a DP cable follows the spec, and as such, there is no circuitry to specifically monitor for a potential power supply conflict. There is a potential ecosystem issue here as there seem to be non-compliant cables in the market, so it may be something we need to account for in our future reference board designs.
It's disappointing that there are improperly marked DisplayPort cables for sale, which could be causing stability issues and ruining the experience for ultra-enthusiasts everywhere. The blame here rests on the cable manufacturers who improperly placed the DisplayPort logo on devices that didn't meet - or even get submitted to - certification standards. The single cable in the certification database isn't going to meet the needs of all users (although it is available in 2m and 3m lengths), so if you're searching for a cable the question to ask the reseller or manufacturer is if the product has been VESA Authorized Test Center (ATC) certified, and which DisplayPort version it is compliant with.
Devices like a multi-stream transport hub that can break out a single DP 1.2 connection into three DP or DVI outputs might be an easy solution for existing users, as presumably the device would be compliant not to pass the sink power back to the card, being powered themselves from it or safely ignoring it. MST hubs are a sore point for some Eyefinity users, touted as the savior to timing synchronization issues and simplifying connectivity but never appearing. Pre-production versions were shown at CES 2013 so hopefully they will make their way into the market this year. Haven't heard that before.
With AMD's next generation of graphics cards looking to be launched after Computex this year it might be too late in the process for AMD to change their reference design for the next generation, but maybe AMD's AIB partners can accommodate it in their non-reference designs. In the meantime, I'm off to figure out a way to gnaw on this stack of DisplayPort cables just right to break the pin 20 DP_PWR connection. If I leave it plugged in to the monitor, the 500mA current should tingle nicely to let me know when I've done it. ED: Just kidding, don't do that. Really.