Earlier this week we reported that Novell was finally dropped the RadeonHD driver from openSUSE
as they switch to using the xf86-video-ati driver with kernel mode-setting (KMS) support over using their in-house R500/600/700 driver they had developed as part of AMD's initial open-source strategy for Linux. Whenever bringing up the RadeonHD driver
at Phoronix it generally leads to a heated discussion in our forums between community members, developers, and other representatives over the history of the RadeonHD driver and what really was its purpose, among other dissenting views.
In this most recent discussion
, Luc Verhaegen who formerly worked for Novell
and was one of the few Novell engineers that worked heavily on the xf86-video-radeonhd driver from the beginning, made several more claims. Among these claims were "We at SUSE wanted to do what was best for the free software desktop, and it's a real shame how politics and shortsighted egotripping wasted a lot of resources and destroyed many of the good and honest advancements and goals of this project." In one of the replies, AMD's John Bridgman had then said, "AMD senior management approved a plan that was developed jointly between "AMD people", "ATI people", Dave and Alex. I know you guys worked hard on a separate plan but that was not the plan that we were following." What though was the original, "separate" SUSE plan for a free software ATI driver?
A few months back we read the original proposal to AMD written by the Novell employees that months later began work on the RadeonHD driver. This business letter to AMD was entitled "Proposal to Advanced Micro Devices for the Implementation of a Driver for its ATI Radeon (tm) HD 2000 Family of Graphics Hardware (R600)."
The expressed goals by SUSE were to create an open-source driver with full support for the latest ATI hardware, improving the quality of the open-source driver (xf86-video-ati) for older hardware, add missing support for already released hardware to the open-source driver, to provide the open-source community with specification and programming documentation, and continuing to implement open-source drivers and public specifications for future generation chipsets. While most of this can be seen in AMD's current open-source strategy, the hardware specifications and documentation for newer hardware (such as the ATI Evergreen / Radeon HD 5000 series) hasn't made it out as quickly as some would like within the community.
The SUSE/Novell engineers writing this 2007 proposal also expressed interest in XAA and EXA with RENDER acceleration, which was achieved by the RadeonHD driver as well as the Radeon driver and there is EXA within via the new ATI kernel mode-setting paths too. They also had expressed interest in supporting Glucose, for mapping 2D acceleration over OpenGL. The Glucose acceleration architecture though never materialized in the RadeonHD driver or any other X.Org drivers for that matter with EXA (and the EXA-derived UXA in the case of Intel KMS) living om. One way now emerging through to accelerate 2D EXA over 3D paths on the GPU is via the Xorg state tracker within the Gallium3D driver architecture.
Novell developers also had aspirations of implementing support for XvMC
. The X-Video Motion Compensation extension has been on its way out since NVIDIA provided the VDPAU
specification, but back in 2007 XvMC still had potential to be extended as shared by Keith Packard a year later at FOSDEM
. Novell developers hoped to extend XvMC under this proposal to use AVIVO's Universal Video Decoder (UVD) to support other video codecs like MPEG-4, DiVX, WM9, and H.264/AVC. This, sadly, never materialized in any form for ATI hardware as of yet. Right now with the open-source ATI driver stack, X-Video is still the only real option at this point. Hopefully not too far out in the future we will finally have VDPAU or VA-API over Gallium3D.
In this proposal, plans were also laid for how they planned to tackle the 3D/OpenGL support with writing a new DRM kernel module and a new DRI driver for Mesa. Other longer-term 3D goals of Novell were to implement tessellator support, enhanced shader support, implementation of additional texture formats, support for frame buffer objects, and implementing of less common blending operations. Some of these objectives have been achieved over the past three years within the Mesa community, but some items (like hardware tessellation support) have yet to be touched.
In ending this proposal, Novell also explicitly stated that to ensure an "open development process" they would not use any specifications or programming documentation that would not be made available by AMD to the open-source community. While AMD has publicly made a fair amount of documentation available to the open-source community since announcing their own open-source strategy, their documentation isn't exhaustive compared to what Novell was able to tap into during the development of RadeonHD along with other sample code (TCore
, etc). AtomBIOS
was also not mentioned once in this original proposal.