Habana Labs' Linux AI Driver Causes More Concerns - Changes Dropped Ahead Of Linux 5.15

While Habana Labs has been known for their open-source and upstream Linux kernel driver for their AI training/inference accelerators with that code they had been working on as a start-up even before being acquired by Intel, it's continued to cause friction that they rely in user-space on closed-source components like their compiler. That in turn is again causing problems for changes that the Habana Labs kernel driver planned to land with the upcoming Linux 5.15 cycle.

This past Thursday the Habana Labs pull request of driver updates was submitted to "char/misc" for queuing ahead of the Linux 5.15 merge window opening in a week or so. For the lack of an AI/accelerator subsystem yet, the Habana Labs kernel driver continues to live within the "catch all" char/misc area of the kernel.

That pull request introduced a new API for user-space to export as a DMA-BUF object, allow waiting on multiple command submissions, state dumping support for debugging, and a variety of other changes. But it's the changes around DMA-BUF that ended up opening a can of worms.

Greg Kroah-Hartman as the char/misc maintainer pulled the Habana Labs driver changes into his "-next" Git code ahead of the Linux 5.11 merge window. However, DRM subsystem maintainer David Airlie "NAK'ed" [not acknowledge] the code. He objected to this code being queued up for merging on the basis of the DMA-BUF/P2P changes.

We are opening a major can of worms (some would say merging habanalabs driver opened it), but this places us in the situation that if a GPU vendor just claims their hw is a "vector" accelerator they can use Greg to bypass all the work that been done to ensure we have maintainability long term. I don't want drivers in the tree using dma-buf to interact with other drivers when we don't have access to a userspace project to validate the kernel driver assumptions.

Ultimately the issue stems from DRM/graphics kernel drivers requiring open-source user-space software to exercise all exposed user-space APIs by kernel drivers. This has proven to be beneficial for testing purposes, code maintainability, and ensuring users aren't locked in to using closed-source software in user-space in order to enjoy some kernel driver feature, etc. But in the case of the Habana Labs driver, it lives elsewhere in the kernel (char/misc) and lacks a proper open-source user-space solution while wanting to use code around what is expected of the DRM kernel drivers (DMA-BUF).

Thus DRM (co-)maintainer David Airlie pushed back against these changes that would allow the DMA-BUF/peer-to-peer support due to the user-space source requirements. This issue with Habana Labs' kernel driver was previously talked about in The Growing Number Of AI Accelerator Drivers Reignites Linux Kernel Driver Debate.

Greg already removed the Habana Labs kernel driver changes that were slated for Linux 5.15. We'll see if a new pull request comes in with all the changes but the DMA-BUF/P2P work.

DRM co-maintainer and maintainer of the Intel kernel graphics driver, Daniel Vetter, also agreed with David Airlie's objections. So while Habana Labs is now owned by Intel, there is still more work to do and ideally seeing a fully open-source user-space solution for their AI accelerators.... We'll see if/when that happens given the competitiveness in this space even though Intel normally is quite open with their code.