AMD has taken some of the wraps off their replacement for Catalyst Control Center; which is being branded Radeon Software Crimson. The new software package is part of a nigh-on complete overhaul of the entire Catalyst software stack; a completely non-trivial and resource consuming exercise required by changing conditions in the personal computer markets. In perhaps one of the best moves AMD could have made in regards to programming; Radeon Crimson is being built in QT. This is significant given that QT is a platform-neutral development utility; capable of generating native-performance code that can run on a variety of different operating systems. Leveraging QT is often times a quote/unquote “Gateway Drug” into good coding practices.
In reference to that native-performance of QT developed code; AMD has been quick to comment on the performance difference between Crimson and CCC. A specific example of a time decrease has been given against a low-ranged E-350 mobile platform; with CCC’s 8 second start-up time cratered by Radeon Crimson’s 0.6 seconds. While the gain is certainly significant; I doubt performance alone is a driving factor. Part of the aforementioned changing conditions in personal computing revolve around a massive change in operating systems leveraging the Linux kernel. Perhaps the most popular consumer facing Linux, Google’s Android, has never used a traditional XWindows Xserver. Now most other Linux distributions are likewise leaving the Xserver; instead focusing on decoupled abstractions such as Ozone or Wayland. AMD’s Linux driver, which was constructed in a time when there was nothing but the Xserver, simply hasn’t been up to the task of handling life in an Xserverless Linux world.
Even today the quasi-flagship Radeon R9 290x, of which I have one, is a pain in the rear end to get running on DebianPure based platforms or Debian downstreams such as Tanglu or SteamOS. The difficulty increases when leveraging a discrete Radeon card of one type alongside an APU variant such as the A-10 7850k. In my own case the only way to get the X.org driver in Tanglu’s repositories to attach the screen to the R9 290x without leveraging a complex xorg.conf file is to disable the APU’s R7 within the motherboard’s UEFI. The current release of Catalyst, version 15.9.1, issues warnings through the installer about unmet requirements with no indication, even in the log files, of what those unmet requirements actually are. Given AMD’s stated HSA ambitions and the the reliance on the GPU side of an APU providing floating point functionality in pre-Zen architecture processors; the miserable day-to-day living experience of two different generation graphics products within traditionally styled desktop Linux distributions should have been addressed years ago.
That being said; AMD has been saying all the right things… and contributing all the correct code… to turn their graphics division from laughingstock back into Champions. Former Catalyst-Only Programmers are now contributing directly to the X.org backed drivers. Those contributions include new and revamped code to prep for the unification of AMD’s performance-driven Catalyst Shader compilers with an X.org backed Open-Sourced Kernel Driver. This unification is expected to directly address the low-level kernel and ABI changes that have effectively killed AMD’s flagship and high-end products driver support on traditional Linux; such as the now infamous Xserver 1.16 ABI bump that took over half a calendar year to address. Other aspects of the contributions are intended to handle the conversion of most traditional Linux systems from an X.org Xserver base to an X.org backed Wayland base. The code work to decouple the AMD Performance Shaders from the effectively in-supersession XWindows Xserver might also place AMD in position to start landing Android device and Chromebook contracts with Zen APU designs. Ongoing
Mantle2… excuse me… Khronos Vulkan development could also help AMD reclaim discrete graphics ground ceded to Nvidia; as well as integrated graphics ceded to Intel; as various higher-end x86-64 gaming applications move from legacy DirectX API backends into Vulkan API backends.
Other indications that AMD’s software side is headed in a good direction are found in updates to the GNU Compiler Collection: https://gcc.gnu.org/ml/gcc-patches/2015-09/msg02311.html
The attached patch enables -march=znver1 (AMD family 17h Zen processor).
Costs and tunings are copied from bdver4, but we will be adjusting them later for znver1.
Also a basic scheduler description for znver1 is added and we will update this as we get more information
For reference the bdver4 refers to the Excavator Architecture. Uros Bizjak, one of the GNU developers, has already issued a response. While there are some minor changes to be made to the patch; the patch itself looks good enough to land in the mainline trunk of GCC. This should ensure that AMD’s Zen will be supported out of the box for the upcoming GCC 6.x release.
Stepping back and looking into 2016 several aspects of AMD’s software strategy start to coalesce into something interesting. New platform-agnostic control center code through QT better positions AMD to expose the capabilities of their GPU architectures across a wide range of operating systems. There is an obvious quick-shot that the QT based Radeon Crimson could be easily integrated into SteamOS’s BigPicture User Interface. While that is certainly exciting as more titles start checking in SteamOS/Debian support on their store pages; integrating Crimson into SteamOS perhaps is more of a stop-torquing-existing-customers-off feature than a return-on-investment profit-generating feature. Likewise; applications compiled to take advantage of Zen’s hardware features on launch will certainly satiate a good number of bleeding edge developers; but won’t really do anything for the vast legion of pre-compiled software titles. The lack of new application compiles focusing on Zen’s features would especially be a factor within the Windows Software Ecosystem.
The potential profit-generating kicker, however, is that QT for Android could potentially allow AMD could to directly expose Radeon Crimson’s Vulkan / OpenGL controls directly atop Android. Calling back the submission of Zen into GCC, keep in mind that Android’s NDK includes the full GCC toolchain. Google’s own documentation notes the following bullet point in using GCC optimizations:
- Squeeze extra performance out of a device for computationally intensive applications like games or physics simulations.
Given the rise of gaming-centric Android tablets; such as Acer’s Intel Packing Predator 8 and Nvidia’s Shield; AMD could be setting up for a head-to-head-to-head confrontation. Cracking into the Android market with a flagship device alone could be the profit return that pays off cleaning up the entire Linux driver stack and simply writing huge new swathes of platform-agnostic code.
The Radeon Crimson software package is certainly a good step towards putting AMD back on the path to profitably. The question in my mind is how much this new code will ultimately benefit consumers who have purchased AMD hardware over the past 3 or 4 years. Support for Zen and future GPU products might be shaping up nicely; but how AMD handles consumers currently dis-satisfied with current software support options could be more important than any other factor.