Here's a little Intel: Beware of Linux graphics vendors bearing gifts of shared code – open-sourcer
- Reference: 1605189607
- News link: https://www.theregister.co.uk/2020/11/12/intel_igc_mesa/
- Source link:
Dave Airlie, a senior engineer at Red Hat, Linux kernel developer and contributor to the [1]Mesa graphics project [2]posted the warning following Intel's [3]GPU announcement and [4]reports of the success the company was having in sharing code between its Windows and Linux development efforts.
Intel is over GPUs and CPUs – it's all about 'XPUs' now that OneAPI code-abstraction tool is golden [5]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," 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 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 [6]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. ®
Get our [7]Tech Resources
[1] https://www.mesa3d.org/
[2] https://airlied.blogspot.com/2020/11/linux-graphics-why-sharing-code-with.html
[3] https://www.theregister.com/2020/11/11/intel_one_api_server_gpu/
[4] https://www.phoronix.com/scan.php?page=article&item=intel-server-igc&num=1
[5] https://www.theregister.com/2020/11/11/intel_one_api_server_gpu/
[6] https://people.freedesktop.org/~cwabbott0/nir-docs/intro.html
[7] https://whitepapers.theregister.com/
A sign of where things are going.
"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."
A sign of things to come.
Hopefully this sound warning will be taken into account.
And those responsible will act accordingly.
O.
Alternativly
Detach your expectations of open source philosophy and culture from your association with the phrase open source. Open source is no more useful a term than human to describe anyone other than by the lowest common denominator and changing the winge from your not sharing, to your not sharing properly seems a bit petulant
End of the day if the code is publicly available and licensed in a manner to allow modification and sharing free as in beer yadda yadda, it's open source, not all projects are community driven or even accept contributions from outside of the organisation, end of the day nothing stopping you forking the code and building a community from your fork (mariadb...), many different styles of open source out there really doesn't need to get religious and dogmatic over how each project/product is run. I dare say the org chart nightmare inside of Intels dev teams makes it community driven enough internally without needing to further complicate matters
Does this include the new Pi4 driver?
https://www.raspberrypi.org/blog/vulkan-update-merged-to-mesa/