AMD Posts 138 Linux Driver Patches, Bringing Up New SMU Block For Future GPUs
Given how long it takes to develop working driver support for a new GPU architecture, it should be as no surprise that internally AMD would already be working on the Linux support for next-generation Navi due out later this year. Today this new SMU driver could be the first signs of that support albeit limited to the system management unit.
The 138 patches comprised of more than six thousand lines of code is preparing for a new SMU (System Management Unit) to be found on "future ASICs" and this block is responsible for the power management tasks and other functionality like OverDrive. Navi isn't explicitly spelled out, but likely a safe assumption given AMD's roadmap.
The code patches explain, "The powerplay driver will be retired. The final version is for vega20 with SMU11. However, the future asic will use the new swSMU framework to implement as well. Here is the first version of new sw smu driver that is basing on vega20...We would like to do re-arch for linux power codes to use a new sw SMU ip block for future asics. We hope to write a simple and readable framework for Linux."
Vega 20 would continue using PowerPlay by default but it turns out this new code should work there as well if booted with amdgpu.dpm=1.
In going through the 138 patches, no interesting details about the next-generation AMD Radeon hardware is exposed, but mostly filling in the infrastructure for supporting the new SMU block. Obviously a lot more code will come in time for actually bringing up the next-gen AMD GPU support in full.
Navi isn't expected out until the second half of the year and it will be interesting to see when the Linux kernel support in full gets published. In the case of Vega, they had open-source support available but it wasn't merged by the time the RX Vega series began to ship, but ended up being after the fact though in that case they were blocked at the time by first merging AMDGPU DC. With the soon-to-ship Radeon VII, the Linux support should already be in place unless there are any last minute issues like was the case with the RX 590. If AMD is (ideally) aiming for support in the mainline kernel by the time the hardware first ships, they will need to get the code published within the next couple of months in order to align with the mainline kernel cycle. Plus if a lot of new code is needed to light up Navi, the public code review process will take some time prior to the next kernel merge window. Or it could be the case of the open-source driver code being available but not yet mainlined so early customers would need to build it themselves (or use a third party kernel build) or just rely upon the Radeon Software / AMDGPU-PRO driver for easy support using its DKMS module.
26 Comments
