原文地址：airlied.blogspot.com/2020/11/lin…
发布时间：2020年11月11日
最近phoronix上的一篇文章有一些关于Windows和Linux之间共享代码的评论，以及这似乎是英特尔喜欢的一个指标。
我想探讨一下这个想法，并解释一下为什么我认为这对基于Linux的发行版和我们在图形领域的开源开发模式不利。
tl;dr 开源发布的项目和开源开发的项目在可持续性和社区方面有很大的区别。
从发行版厂商的角度来看，Linux图形堆栈是由Linux内核和Mesa用户空间两个主要项目组成的。这两个项目是在开放中开发的，采用了完全开放源代码厂商不可知的做法。没有任何厂商控制这两个项目，这两个项目的目标是尽量让所有厂商的驱动程序最大限度地共享代码和共享流程/编码标准。
这种跨厂商的协同作用对Linux图形堆栈的运作生态系统非常重要。该堆栈在某些地方也依赖于LLVM项目，但同样LLVM上游是厂商不可知的，是开源开发的。
对发行版的价值在于，他们有中心的地方来接收驱动堆栈，有良好的发布周期，而且他们需要处理的地方数量最少，可以和这些社区互动。现在通常硬件厂商没有像Linux发行版那样看到外部社区的价值。从硬件厂商内部的角度来看，他们看到更多的好处是在Windows和Linux之间创建一个共享的单一堆栈，以最大化他们的投资回报率，或者让他们的orgchart更漂亮，或者减少关于为什么他们的orgchart不是最佳的powerpoints。
共享的Windows/Linux堆栈是厂商们出于自己的原因而不是为了Linux社区的利益而想要的东西。
为什么说这是个坏主意？
我首先要说的是，这并不总是一个坏主意。理论上，也许可以用开源开发模式的好处来生产这样的堆栈，然而大多数厂商似乎在这一点上失败了。他们把开源看成是一种发布模式，他们在内部开发，每隔X周把成果从栅栏上铲到github repo里，经过一堆周期。他们构建了包含这些开源作品的产品，但他们从未花费时间围绕这些作品建立项目或社区。
以AMDVLK与radv为例。我开始做radv是因为AMD一直向世界承诺为Linux提供一个开源的Vulkan驱动，与他们的Windows堆栈共享。即使是在交付的时候，它也是开源的，但却是内部开发的。在驱动程序的开发过程中，没有社区参与的渠道。外部贡献者从来没有与AMD员工处于同等地位。即使是不同团队的AMD员工也不在同一起跑线上。比较一下Mesa的radv项目，它让Valve贡献了ACO后端编译器，并提供了比AMD厂商共享代码更好的结果，而投入的人力物力却少得多。
英特尔有一个非Mesa编译器，叫Intel Graphics Compiler，文章中提到了。这完全是由英特尔内部开发的，关于项目方向、如何参与、社区在哪里等信息很少。似乎没有太多的公开审查，补丁似乎被igcbot合并到公共repo中，这可能意味着它们是从某个内部repo镜像过来的。没有使用github的合并请求等。比较一下Mesa近红外后台的开发，在这里，大量的修改都会被审查，并尝试最大限度的共享代码，这样所有的厂商都能从代码中受益。
有一个领域，它的内核中AMD的显示代码已经基本解决了。我相信这个代码是和他们的Windows驱动共享的（但我不是100%确定）。他们试图参与社区对代码的修改，但代码仍然是相当可怕的，并不是真正的最佳在Linux上。将其与原子模式设置和重构整合起来是一件很痛苦的事情。所以即使在最好的情况下，即使对厂商来说也不是一个最佳结果。他们必须努力让共享代码能够支持不同的操作系统交互。
我会怎么做呢？
如果我必须共享Windows/Linux驱动堆栈，我会（有偏见的意见）从最开放的项目开始，并将其引入封闭的项目中。我绝对不会从一个新的内部项目开始，试图打乱这两个项目。例如，如果我需要创建一个Windows GL驱动，我可以。
a) 写一个完整的GL实现，然后每隔几周就把它扔到墙上，让Windows/Linux使用它，Linux用户失去了共享堆栈，发行版失去了一个依赖，而不得不建立一个由多个厂商deps组成的堆栈，Windows实际上什么也没得到，但我可以控制自己的命运（社区并不重要）。
b) 使用Mesa，并将我的驱动上传到Linux堆栈中，将Windows代码添加到Mesa堆栈中。我可以分享其他厂商外部开发的好处，而Windows也获得了这种好处，Linux则保留了它的生态系统的好处。
那么给任何希望操作系统之间有更多厂商代码共享的人一个警告，它一般不会以Linux更好的结局而告终，它的结局是Linux更分散，更难支持，从长远来看是不可持续的。
通过www.DeepL.com/Translator （免费版）翻译
