Don't Look For Open-Source AMD CrossFire Anytime Soon
CrossFire is the multi-GPU solution for Radeon graphics cards that's now been through four generations of improvements, plus there's also Hybrid CrossFire / Dual Graphics. CrossFire allows for improved OpenGL performance in some games and other workloads by combining multiple GPUs of the same generation to work together to split the rendering workload. CrossFire support is a very low work item for the open-source AMD Linux driver just as SLI (Scalable Link Interface) support as NVIDIA's equivalent is a very low priority item within the Nouveau camp.
There isn't great demand for SLI/CrossFire by the open-source drivers since there's more pressing items to address first: better performance, newer OpenGL support, and various other features. Even when it comes to the proprietary AMD and NVIDIA Linux graphics drivers, these multi-GPU solutions aren't very common and tend to benefit very few workloads on Linux at this point (hence why SLI/CrossFire is rarely tested at Phoronix; if you are curious you can read about Radeon CrossFire on Linux from a few years back). So while there's been multi-GPU improvements in general for the open-source Linux graphics stack when it comes to Optimus-like situations, DRI_PRIME, and render nodes, don't expect this to carry over into CrossFire and SLI support anytime soon unless some really interested independent contributors magically start working on the support.
The lack of open-source CrossFire support is being brought up today since it was asked about in our forums. Via our forums, AMD's Alex Deucher has commented on a few occasions about this support.
The lack of open-source CrossFire support also isn't due to any missing AMD hardware documentation or similar blocking issues. Alex had written, "There isn't really any magic to crossfire. You just have split work between two gpus in the 3D driver. If anyone is interested, they could start playing with it. Support for the crossfire connectors are just an optimization and are not required for an implementation; in fact a number of crossfire scenarios don't use them at all." Additionally, "you don't really need any hw details to implement it. It mostly sits above the hw specific layers. Unfortunately, there is not much demand for crossfire outside of windows."
Alex had also written at length about the implementation process:
Both hybrid graphics and crossfire require large amounts of driver independent infrastructure. Just about everything you'd need from the drivers is already there. Someone who really wants those features would need to sit down and just do the work and for the most part.
For hybrid graphics it really doesn't have anything to do with power management per se, and just about everything you need from the driver is already there. You just need a windowing system specific infrastructure to enumerate and select which GPU they want to render with and call down to the kernel and turn the dGPU on/off as needed. You have to teach X or wayland or mir to pick the GPU it wants to render with and make sure it's turned on when they want to use it and turned off when they don't. From the driver's perspective, it just looks like resume and suspend with a little APCI magic thrown in completely power on/off the device. Whether you use vgaswitcheroo or a custom drm ioctl, the driver code is pretty much the same. Once the window system code to handle this is in place any remaining bugs around the edges in the driver can be fixed, but the main effort is device independent.
For crossfire, you'd need some sort of layer on top of the 3D driver what would dispatch to multiple instances of the driver. Once again, largely driver independent.
Anyone interested in either of these features could start working on them without really having to any of the low level hw details. Unfortunately, neither of these features are a high priority for paying Linux customers.
23 Comments
