WebGPU是浏览器厂商基于W3C组织(主要是W3C)设计的一种新的图形和计算API。它是为Web设计的，由JavaScript和WASM应用程序使用，并由WebAPI的共享原则驱动。不过，这并不一定只针对网络。在这篇文章中，我想分享一下为什么原生平台上的WebGPU对我来说很重要。这是高度主观的，并不代表我所在的任何组织。
WebGPU本机的故事和API本身一样古老。在Khronos的最初听证会上，由同样的人讲述了在探索“3D可移植性”会议和“WebGL Next”会议上听到的相同故事。这些会议有相似的目标：找到一个很好的可移植的原生API交叉点，到那时(2016)，它们显然开始在自己的生态系统中分道扬镳。不同之处在于哲学上：Web优先考虑安全性和便携性，而本机则想要更高的性能。这种分裂表现在创建了两个真正的工作组：一个是W3C构建Web API的工作组，另一个是Khronos的“Vulkan Porability”技术小组。今天，我是这两个组中唯一活跃的人(“大使”)，原因很简单，因为我们在gfx-rs之上实现了这两个API。
Vulkan便携性试图通过将其层叠在金属、D3D12和其他之上，使Vulkan在任何地方都可用。现在，每个人都开始使用Vulkan，庆祝，并且永远不会回头，对吗？不完全同意。Vulkan可能速度很快，但它对“便携”的定义相当薄弱。开发不会触发Vulkan验证警告的应用程序(！)。在任何平台上都是极具挑战性的。阅读Vulkan规范在许多方面都令人兴奋和大开眼界，但将其应用于实践是一种不同的体验。Vulkan并没有为所有的GPU硬件提供低级API，它有狮子头、熊的身体和鳄鱼的尾巴。Vulkan的每一块都匹配一些硬件(例如vkImageLayout匹配AMD的)，但是其他硬件充其量将其视为无操作，在最坏的情况下将其视为负担。这是个万能的千斤顶。
另外，真正的伏尔坎并不是无处不在。更具体地说，在Windows上没有Intel Haswell/Broadwell iGPU的驱动程序，在Windows UWP(包括ARM)上是禁止的，在Android上低于50%，在MacOS和iOS上完全没有。Vulkan Porability旨在解决这个问题，但对于您的应用程序来说，这是另一个相当复杂的层，特别是考虑到SPIRV-Cross的着色器转换逻辑，它仍然是一个WIP。
在gfx-rs社区，我们在Vulkan API上下了很大的赌注，因为我们决定让我们的低级Rusted API与它保持一致(参见我们的Fosdem 2018演讲)，而不是找出我们自己的道路。但是当我们(最终)了解到大多数用户根本无法访问Vulkan API时，我们也意识到原生平台上的WebGPU正是我们需要为他们提供的API。我们看到了现代的、可用的、但低级的API的巨大潜力。最重要的是-WebGPU是安全的，这是Rust在类型系统中表达的东西，这使得任何库都非常需要这个属性。
这就是wgpu项目开始的地方。在很长一段时间里，它只在本机上实现WebGPU，直到最近才成为Firefox的一部分(仅限夜间)。
让我们从一个大胆的、有争议的声明开始：开发人员从来都不可能以单一的API为目标并以高质量始终如一地接触到用户。在纸面上，有OpenGL，而且它确实无处不在。然而，在实践中，桌面和移动设备上的OpenGL驱动程序都很差。这是一个狂野的西部：充满了错误和隐藏的秘密，关于如何说服司机不要做错误的事情。大多数游戏都以Windows为目标，在某种程度上，D3D10+在呈现给开发者的模型和驱动程序质量上都远远领先于OpenGL。今天，Windows上的Web浏览器不能在OpenGL上运行，尽管它们接受WebGL API，而Firefox在OpenGL上有WebRender，Chromium有SkiaGL。他们都在角度上运行，角度将opengl转换为D3D11…。
这就是本机上的WebGPU登台的地方。这里不要被“Web”前缀所迷惑：它是一个非常明智的原生API，非常可移植，性能相当好，并且在瞄准它时非常容易正确。对于编写子弹地狱射击游戏、医学可视化或在学校教授图形编程，它可能是您的默认选择。一旦您将其作为目标，您还可以在Web上部署，这也是一个不错的额外奖励。
从一开始，Google就可以在本地和浏览器中使用它们的实现，现在被称为黎明(Dawn)。我们有一个共同的兴趣，那就是允许开发人员瞄准一个共享的“本地WebGPU”目标，而不是一个具体的“曙光”或“本地wgpu”。因此，我们在一个共享头上进行协作，并且我们将提供实现它的C兼容库。规范仍然是一个不断变化的目标，我们还没有将我们的外部C接口与共享头对齐，但这就是我们的计划。
如果您现在正在开发应用程序，技术堆栈的选择如下所示：
以bgfx或sokol-gfx这样的图形库为目标，接受没有规范的工作，也要准备好修复错误并提交补丁。
选择一个像Unity/虚幻/木场这样的引擎，给你提供便携的图形，接受它附带的所有功能。
今天的引擎相当不错！它们功能强大，使用成本低廉。但我认为，对他们有很大吸引力的原因是下面的空间缺乏适当的解决方案。在平台上处理不同的图形API很困难。把它留给第三方图书馆意味着对它有很大的信任。
如果本机上的WebGPU变得实用，它将严格优于(1)和(2)。它将得到实际规范、丰富的一致性测试套件、大公司的支持，并通过在浏览器中的使用而得到致命的测试。它提供的权衡将使它成为一个可靠的选择，即使对于本来会选择(3)、(4)和(5)的开发人员来说也是如此，但当然不是全部。
我可以看到WebGPU on Native是业余开发人员、学生、独立专业人士、手机游戏工作室和许多其他群体的首选。如果它能兑现其对安全性、性能和可移植性的承诺，它可能会成为默认的GPU API。我们有很多感兴趣的人和早期采用者，还有强大的行动力量来实现这一点。