Here's a little Intel: Beware of Linux graphics vendors bearing gifts of shared code – open-sourcer

Mesa contributor issues a warning: community matters


Intel's driver support for Linux is improving, but has raised an eyebrow or two within the open source community as a Mesa contributor noted that Chipzilla's code-sharing development model was not necessarily a win.

Dave Airlie, a senior engineer at Red Hat, Linux kernel developer and contributor to the Mesa graphics project posted the warning following Intel's GPU announcement and reports of the success the company was having in sharing code between its Windows and Linux development efforts.

Intel Server GPU

Intel is over GPUs and CPUs – it's all about 'XPUs' now that OneAPI code-abstraction tool is golden

READ MORE

Airlie's take was that there is quite the difference between open source released and open source developed projects, with the former not being entirely healthy "in terms of sustainability and community".

Citing the Linux kernel, and the Mesa project to which he contributes, Airlie pointed out that both were developed in the open "with completely open source vendor-agnostic practices" and neither project was under the control of a given vendor. The community was more interested in sharing code and processes across drivers.

"This cross-vendor synergy is very important to the functioning ecosystem that is the Linux graphics stack. The stack also relies in some places on the LLVM project, but again LLVM upstream is vendor agnostic and open source developed."

A potential issue is where a vendor is perhaps more keen on seeing a return on investment, lobbing internally developed code into an open source repo every few development cycles rather than building a community around the project.

AMD

Airlie cited his own initiation of the radv project, which was a (Mesa-led) reaction to AMD's open source Vulkan driver, replete with Windows and Linux code sharing. "There was no avenue for community participation in the driver development," he said. "External contributors were never on the same footing as an AMD employee. Even AMD employees on different teams weren't on the same footing."

Unsurprisingly, Airlie's opinion is that the radv project in Mesa ended up with far better results than AMD's vendor shared code.

He did, however, have kinder words for AMD and its display code in the kernel and credited the team with community engagement although remarked that "the code is still pretty horrible and not really optimal on Linux."

Community spirit

It was the Intel Graphics Compiler (IGC) that attracted much of Airlie's ire. IGC for Mesa looks to be on the way and, at face value, the performance figures being bandied about look promising.

Noting that IGC was an internal Intel project, Airlie complained "there is little info on project direction or how to get involved or where the community is."

He contrasted the IGC approach with that of the NIR compiler within Mesa, "where lots of changes are reviewed and maximal common code sharing is attempted so that all vendors benefit from the code."

While end-users may not be too worried about the development approach taken for their open source drivers, so long as things crack on at a decent pace (at least when compared to Windows), Airlie's point remains valid. Keeping things internal and just pushing out snapshots defeats the community-first approach beloved by many in the community.

"A warning then to anyone wishing for more vendor code sharing between OSes it generally doesn't end with Linux being better off, it ends up with Linux being more fragmented, harder to support and in the long run unsustainable."

If one is to wear the open source badge, it would probably be best to take an open source-first approach. ®


Biting the hand that feeds IT © 1998–2020