1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

Don't Look For Open-Source AMD CrossFire Anytime Soon

AMD

Published on 26 February 2014 02:38 PM EST
Written by Michael Larabel in AMD
23 Comments

While the open-source AMD Linux driver continues gaining ground on Catalyst, one feature you will likely not see from the open-source Linux driver in the foreseeable future is support for AMD's CrossFire technology.

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.

Don't Look For Open-Source AMD CrossFire Anytime Soon


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.

Don't Look For Open-Source AMD CrossFire Anytime Soon


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.

Latest Linux Hardware Reviews
  1. Overclocking The AMD AM1 Athlon & Sempron APUs
  2. AMD Athlon 5350 / 5150 & Sempron 3850 / 2650
  3. Upgraded Kernel & Mesa Yield A Big Boost For Athlon R3 Graphics
  4. AMD Athlon 5350 APU On Linux
Latest Linux Articles
  1. A Quick Look At GCC 4.9 vs. LLVM Clang 3.5
  2. Are AMD Athlon/Sempron APUs Fast Enough For Steam On Linux?
  3. AMD Athlon's R3 Graphics: RadeonSI Gallium3D vs. Catalyst
  4. GCC 4.9 Compiler Optimization Benchmarks For Faster Binaries
Latest Linux News
  1. Maynard: A Lightweight Wayland Desktop
  2. Chromium Browser Going Through Growing Pains In Ubuntu 14.04
  3. KDE 4.13 Is Being Released Today With New Features
  4. Trying Out Radeon R9 290 Graphics On Open-Source
  5. Intel Broadwell GT3 Graphics Have Dual BSD Rings
  6. Early Linux 3.15 Benchmarks Of Intel Core i7 + Radeon
  7. Red Hat Releases Its RHEL 7 Release Candidate
  8. New Features Coming To Xubuntu 14.04 LTS
  9. NVIDIA Officially Releases CUDA 6
  10. Google Releases An AutoFDO Converter For Perf In LLVM
  11. Fedora 21 To Evaluate Remote Journal Logging, 64-bit ARM Emulation
  12. Star Citizen Will Be Coming To Linux
Latest Forum Discussions
  1. The GNOME Foundation Is Running Short On Money
  2. Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd
  3. Bye bye BSD, Hello Linux: A Sys Admin's Story
  4. New tool for undervolt/overclock AMD K8L and K10 processors
  5. How to enable opengl 3.3 on r9 270?
  6. R290x sound problems
  7. radeon-profile: tool for changing profiles and monitoring some GPU parameters
  8. Torvalds Is Unconvinced By LTO'ing A Linux Kernel