Features Still Being Sought By Open-Source AMD Users
While the open-source AMD Radeon Linux graphics driver now has support for the latest graphics cards, there's finally UVD video decoding, and the Linux 3.11 kernel brings dynamic power management, there's still features being desired by those using this open-source Linux graphics driver on ATI/AMD GPUs.
In response to AMD's Initial Radeon Driver Changes For Linux 3.12 article, Phoronix readers began talking about other changes and features they are still seeking. The discussion has taken place within this forum thread for those interested. Below is a synopsis of what's going on.
- OpenGL performance. As I am quick to mention in many Phoronix articles, the open-source Radeon Linux graphics driver still doesn't have performance parity with the closed-source Catalyst driver. For those wondering about the current figures see AMD Gallium3D & Catalyst Drivers Compete Against Windows and AMD Radeon, NVIDIA GeForce Linux Comparison For July 2013. The open-source Radeon performance is likely to improve with time, but there's unlikely to be any breakthrough OpenGL performance improvements in the near-term and likely just the gradual evolution of the Radeon Gallium3D drivers.
- CrossFire support, AMD's solution for shared multi-GPU rendering and is common among Windows gamers. AMD's competition to NVIDIA SLI isn't supported by their open-source driver and only with Catalyst. AMD's Alex Deucher responded in the aforelinked thread, "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." Basically, any skilled developer could theoretically work on open-source CrossFire without being held up on AMD documentation or code, but no one has actively pursued this feature. With AMD's scarce open-source resources, don't expect them to get to this soon considering the rather small proportion of AMD CrossFire Linux users.
- HDMI audio support is still being worked on. Radeon KMS HDMI audio is disabled by default and requires a kernel command-line parameter module to be set, but that may change soon. Radeon HDMI audio also isn't yet committed for newer classes of GPUs (e.g. Radeon HD 7000) at this time. For this audio support, it's mostly coming through reverse-engineering as opposed to official AMD documentation.
- Overclock and underclock support for AMD GPUs with the open-source driver, considering the Catalyst driver on Windows and Linux offers this functionality.
- Support for newer versions of OpenGL, which is a long and drawn out process for Mesa/Gallium3D.
- OpenCL/GPGPU is still being matured and isn't yet fully ready for end-users.
- A graphical interface for controlling different driver settings and features, similar to AMD's AMDCCCLE (Catalyst Control Center) or the NVIDIA Settings Panel (nvidia-settings). However, none of the open-source Linux GPU drivers have really been working on a unified control panel outside of driconf, the various RandR utilities, and other random projects.
What else would you like to see out of the Radeon Linux driver (or open-source GPU drivers in general)? Let us know in the forums.
In response to AMD's Initial Radeon Driver Changes For Linux 3.12 article, Phoronix readers began talking about other changes and features they are still seeking. The discussion has taken place within this forum thread for those interested. Below is a synopsis of what's going on.
- OpenGL performance. As I am quick to mention in many Phoronix articles, the open-source Radeon Linux graphics driver still doesn't have performance parity with the closed-source Catalyst driver. For those wondering about the current figures see AMD Gallium3D & Catalyst Drivers Compete Against Windows and AMD Radeon, NVIDIA GeForce Linux Comparison For July 2013. The open-source Radeon performance is likely to improve with time, but there's unlikely to be any breakthrough OpenGL performance improvements in the near-term and likely just the gradual evolution of the Radeon Gallium3D drivers.
- CrossFire support, AMD's solution for shared multi-GPU rendering and is common among Windows gamers. AMD's competition to NVIDIA SLI isn't supported by their open-source driver and only with Catalyst. AMD's Alex Deucher responded in the aforelinked thread, "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." Basically, any skilled developer could theoretically work on open-source CrossFire without being held up on AMD documentation or code, but no one has actively pursued this feature. With AMD's scarce open-source resources, don't expect them to get to this soon considering the rather small proportion of AMD CrossFire Linux users.
- HDMI audio support is still being worked on. Radeon KMS HDMI audio is disabled by default and requires a kernel command-line parameter module to be set, but that may change soon. Radeon HDMI audio also isn't yet committed for newer classes of GPUs (e.g. Radeon HD 7000) at this time. For this audio support, it's mostly coming through reverse-engineering as opposed to official AMD documentation.
- Overclock and underclock support for AMD GPUs with the open-source driver, considering the Catalyst driver on Windows and Linux offers this functionality.
- Support for newer versions of OpenGL, which is a long and drawn out process for Mesa/Gallium3D.
- OpenCL/GPGPU is still being matured and isn't yet fully ready for end-users.
- A graphical interface for controlling different driver settings and features, similar to AMD's AMDCCCLE (Catalyst Control Center) or the NVIDIA Settings Panel (nvidia-settings). However, none of the open-source Linux GPU drivers have really been working on a unified control panel outside of driconf, the various RandR utilities, and other random projects.
What else would you like to see out of the Radeon Linux driver (or open-source GPU drivers in general)? Let us know in the forums.
86 Comments