AMD GPU Driver Looks To Make Use Of Intel's New Buddy Allocator Code In The Linux Kernel
Thanks to the nature of open-source, AMD engineers for the "AMDGPU" kernel graphics driver are looking to make use of Intel's new i915 buddy allocator code they introduced as part of all their video memory management changes as part of their discrete graphics bring-up.
As part of Intel's bring-up of device local memory support for their dedicated GPU enablement and adding the notion of memory regions and other changes, they added a buddy allocator implementation for allocating video memory. This is an implementation of the well known buddy system for dividing of memory into equal parts (buddies) and continuing equal splitting that until able to satisfy the memory request.
That buddy allocator code is part of the Intel i915 kernel driver while now for AMDGPU purposes they are also looking to make use of it as well as making improvements in the process to fulfill their intended use-cases. Open-source at its finest.
Sent out on Tuesday was a set of 13 patches that move the buddy allocator code outside of the i915 driver itself and into the common Direct Rendering Manager (DRM) area so that it can be readily used by AMDGPU and any other interested drivers.
After shifting the code into the common DRM area and making it suitable for sharing, various low-level improvements to the code.
While this idea may seem foreign to non-Linux enthusiasts, it's just another example of open-source at its best and leveraging existing fine code within the kernel. There are plenty of common DRM kernel and Mesa user-space code shared among drivers of competing vendors but even features are adapted from being vendor-specific code to common code where it makes sense and under compatible licenses. On the reverse, a prior example is from a few years ago where AMDGPU's scheduler code was similarly shifted into DRM common code. That DRM scheduler code that originated within the AMDGPU driver and developed just for AMD purposes has since been adapted by Intel and other DRM kernel drivers since it has proven to work well.
AMD's patches moving the i915 buddy allocator code out to the common DRM area and other improvements are now under public review.
As part of Intel's bring-up of device local memory support for their dedicated GPU enablement and adding the notion of memory regions and other changes, they added a buddy allocator implementation for allocating video memory. This is an implementation of the well known buddy system for dividing of memory into equal parts (buddies) and continuing equal splitting that until able to satisfy the memory request.
That buddy allocator code is part of the Intel i915 kernel driver while now for AMDGPU purposes they are also looking to make use of it as well as making improvements in the process to fulfill their intended use-cases. Open-source at its finest.
Sent out on Tuesday was a set of 13 patches that move the buddy allocator code outside of the i915 driver itself and into the common Direct Rendering Manager (DRM) area so that it can be readily used by AMDGPU and any other interested drivers.
After shifting the code into the common DRM area and making it suitable for sharing, various low-level improvements to the code.
Open-source buddies around the buddy allocator code...
While this idea may seem foreign to non-Linux enthusiasts, it's just another example of open-source at its best and leveraging existing fine code within the kernel. There are plenty of common DRM kernel and Mesa user-space code shared among drivers of competing vendors but even features are adapted from being vendor-specific code to common code where it makes sense and under compatible licenses. On the reverse, a prior example is from a few years ago where AMDGPU's scheduler code was similarly shifted into DRM common code. That DRM scheduler code that originated within the AMDGPU driver and developed just for AMD purposes has since been adapted by Intel and other DRM kernel drivers since it has proven to work well.
AMD's patches moving the i915 buddy allocator code out to the common DRM area and other improvements are now under public review.
20 Comments