Show Your Support: Have you heard of Phoronix Premium? It's what complements advertisements on this site for our premium ad-free service. For less than $4 USD per month, you can help support our site while the funds generated allow us to keep doing Linux hardware reviews, performance benchmarking, maintain our community forums, and much more.
Open-Source AMD Linux Developers Already Thinking About API Improvements
Jerome Glisse, a current Red Hat developer who has long been involved in the open-source AMD/ATI scene going back to the classic xf86-video-avivo days (a driver not many even will know about... it pre-dates RadeonHD), has started proposing some API improvements over what's offered by the current Radeon DRM driver.
Jerome opened, "So if i do not start the discussion now it might be already too late. Given plan to converge open source driver and closed source driver to use a single common kernel driver and that this would be a new kernel driver. This is an opportunity to fix some of the radeon design issues (at least things that i would have done differently if only i could get some gas for my DeLorean)."
For those interested in the technical details, Glisse's message can be found on the dri-devel list. Fortunately, Christian König of AMD has already confirmed they are indeed working on design improvements.
While this new "AMDGPU" driver will only benefit the Radeon Rx 300 "Pirate Islands" GPUs (where we're suspecting it to begin) and future GPUs, at least breaking off to create this new kernel driver allows the developers to evaluate and implement the best interface designs for modern GPUs. The developers are free to experiment (as they have been doing with their prototype Sea Islands support in AMDGPU) and figure out the best design prior to landing the driver in mainline where it must provide a stable interface to user-space without breakage. A lot has been learned over the years by the developers in designing the current Radeon DRM code.
On a side note, as mentioned in yesterday's post, AMD says they plan to start rolling out the new kernel code in stages this fall... Based on the timing of things, it's possible we could see some code proposed ahead of the Linux 3.19 merge window but at this point I'd place my bets on seeing things before the Linux 3.20 merge window.