Intel Mesa Driver / libdrm_intel Going Through Rework
An initiative taking place within the Intel open-source Linux driver camp is trying to effectively move libdrm_intel -- the Intel-specific code for the DRM library -- into the i965 Mesa driver itself.
Moving libdrm_intel into the Intel Mesa driver itself could allow for simplifying some areas of the code like relocation handling while not having to worry about breaking the ABI with libdrm enforcing ABI compatibility. Kenneth Graunke who has been leading this charge titled this set of 53 patches, "Eat libdrm_intel for breakfast."
The libdrm_intel code is about 13,000 lines of code made up of 15 source files while this new version is three files and just over two thousand lines of code.
Ken wrote more about their motives, "The rest of the [libdrm_intel] library is basically useless to us. It contains a lot of legacy cruft from the pre-GEM, DRI1, or 8xx/9xx era. But even the parts we do use are in bad shape. BO offset tracking is non-threadsafe. Relocation handling is way too complicated. These things waste memory, burn CPU time, and make it difficult for us to take advantage of new kernel features like I915_EXEC_NO_RELOC which would reduce overhead further. The unsynchronized mapping API performs a synchronized mapping on non-LLC platforms, which can massively hurt performance on Atoms. Mesa is also using uncached GTT mappings for almost everything on Atoms, rather than fast CPU or WC maps where possible."
With the simplified code in Mesa, they are free to break their own ABI and can better future-proof the code as well as letting it evolve when warranted. Those wanting to learn more can see this mailing list patch series.
There is some concern though about importing much of the Intel libdrm functionality into Mesa could cause problems for Intel-using non-Mesa components like Beignet, xf86-video-intel, and the VA-API Intel driver which all rely upon libdrm. From other comments on this patch series, it sounds like the plan is for the driver interfaces to still evolve a lot more. There's also some comments that the Intel VA-API driver should even be moved inside Mesa as it could share more code with the i965 driver. Interesting times ahead.
Moving libdrm_intel into the Intel Mesa driver itself could allow for simplifying some areas of the code like relocation handling while not having to worry about breaking the ABI with libdrm enforcing ABI compatibility. Kenneth Graunke who has been leading this charge titled this set of 53 patches, "Eat libdrm_intel for breakfast."
The libdrm_intel code is about 13,000 lines of code made up of 15 source files while this new version is three files and just over two thousand lines of code.
Ken wrote more about their motives, "The rest of the [libdrm_intel] library is basically useless to us. It contains a lot of legacy cruft from the pre-GEM, DRI1, or 8xx/9xx era. But even the parts we do use are in bad shape. BO offset tracking is non-threadsafe. Relocation handling is way too complicated. These things waste memory, burn CPU time, and make it difficult for us to take advantage of new kernel features like I915_EXEC_NO_RELOC which would reduce overhead further. The unsynchronized mapping API performs a synchronized mapping on non-LLC platforms, which can massively hurt performance on Atoms. Mesa is also using uncached GTT mappings for almost everything on Atoms, rather than fast CPU or WC maps where possible."
With the simplified code in Mesa, they are free to break their own ABI and can better future-proof the code as well as letting it evolve when warranted. Those wanting to learn more can see this mailing list patch series.
There is some concern though about importing much of the Intel libdrm functionality into Mesa could cause problems for Intel-using non-Mesa components like Beignet, xf86-video-intel, and the VA-API Intel driver which all rely upon libdrm. From other comments on this patch series, it sounds like the plan is for the driver interfaces to still evolve a lot more. There's also some comments that the Intel VA-API driver should even be moved inside Mesa as it could share more code with the i965 driver. Interesting times ahead.
11 Comments