热点|Hot
谷歌正式发布WebGPU！90多位贡献者研发6年，浏览器终于可以利用底层硬件了
经过六年的开发，当地时间4月6日，谷歌Chrome团队正式发布WebGPU，用于在网络上进行高性能3D图形与数据并行计算。WebGPU现已在Beta测试阶段的Chrome 113中默认启用。
WebGPU是一种新型Web图形API，具有显著减少同等图形规模下JavaScript工作量、将机器学习模型的推理效率提升3倍以上等优势。之所以能实现这样的飞跃，要归功于其令WebGL无法实现的灵活GPU编程和高级功能访问能力。
据悉，WebGPU的首个版本已经在ChromeOS、macOS和Windows上开放，对其他平台的支持将于今年晚些时候推出。
“Web图形的新曙光”
WebGPU是一种新型Web API，能够公开现代硬件功能并允许在GPU上执行渲染与计算操作，功能定位类似于Direct3D 12、Metal和Vulkan。与WebGL系列API不同，WebGPU能够访问更高级的GPU功能，并为GPU上的常规计算提供一流支持。该API在设计上充分适应Web平台，提供符合习惯的JavaScript API、promises集成、支持导入视频和完备错误提示信息的完善开发者体验。
WebGPU的首个版本将成为未来更新和功能增强的基础构建块。该API后续还将提供更高级的图形功能，并鼓励开发者提出对其他功能的申请。Chrome团队正计划提供对着色器核心的深入访问，以便在WGSL（WebGPU着色语言）中进行更多的机器学习优化和额外的人体工程学调整。
根据介绍，WebGPU是W3C“Web GPU”社区小组协同努力的结果，其中包括来自Mozilla、苹果、英特尔和微软等主要公司的贡献。从2017年初始设计以来，经过六年的开发（涉及90位贡献者、2000次提交、3000个问题），WebGPU的首个实现终于正式登陆Chrome，同时可支持Firefox和Safari。
Chromium和Dawn库和Firefox的wgpu库均可作为独立包使用，提供出色的可移植性与人体工程学层，将操作系统GPU API抽象出来。在本机应用程序中使用这些库时，开发者还可轻松通过Emscripten和Rust web-sys移植向WASM。
WebGPU的首个版本可在支持Vulkan的ChromeOS设备、支持Direct3D 12的Windows设备和macOS的Chrome 113中使用。Linux、Android及其他现有平台的扩展支持也将在年内推出。除Chrome之外，WebGPU目前还初步登陆了Firefox和Safari浏览器。
许多被广泛使用的WebGL库正在或已经能够支持WebGPU，因此用户只需做单行变更即可使用WebGPU：
· Babylon.js已经全面支持WebGPU。
· PlayCanvas宣布可初步支持WebGPU。
· TensorFlow.js可支持大部分运算符的WebGPU优化版本。
· Three.js正在着手实现WebGPU支持。
兴奋与担忧同在
据悉，WebGPU的诞生实际上就是大厂角力的结果。2016年，Google发现WebGL存在一些问题，于是就提出了一个新的提案叫WebGL Next，称要再做一个精确的图形API。然后，其他的厂商也纷纷跟进，Mozilla、Apple、Opera都提出了自己的概念。
这个时候，Apple起名部的工作人员向W3C提交了一个叫做WebGPU的提案，W3C决定采纳这个名字作为未来新标准的命名，并且成立工作组来做WebGPU的工作。
因为这个名字是Apple起的，所以最后只有Apple的提案进入了他们“gpuweb proposals”的代码仓库，不过为了避免重名造成的误解和冲突，Apple最初那个提案的名字被改为了WebMetal。
看到W3C接纳了Apple的提案，Mozilla不甘心，转而又向Khornos Group提交了一个基于Vulkan的命名为WebGL Next的提案，但这已经是WebGL的最后一搏了。这最后，浏览器厂商用脚投票，站到了WebGPU这边。
如今，经过多年等待，谷歌团队正式发布WebGPU让很多开发者感到激动。
“这非常令人兴奋！”
“这是一个巨大的里程碑，也是更大旅程的一部分。在我开发高级2D渲染器Vello的工作中，我开始相信WebGPU是游戏规则的改变者。我们将拥有可在任何地方运行的、相当现代的基础架构：Web、Windows、Mac、Linux、ChromeOS、iOS和Android。”开发者raphlinus表示。
当有人问起，“假设您是ML从业者。您是否仍会推荐学习WebGPU，而不是说花更多时间在CUDA上？”时，raphlinus给出建议，“这完全取决于您的目标。如果您正在研究实际的机器学习算法，那么使用像TensorFlow或Torch这样的框架，它们提供了所有张量操作并抽象出硬件。如果您今天想在硬件上获得最大性能，请坚持使用Nvidia并选择CUDA。如果您对跨一系列硬件部署感兴趣，或者想要亲自动手实现算法（例如wonnx），那么WebGPU是您的不二之选。”
开发者“FL33TW00D”表示，“这非常令人兴奋！（我曾怀疑它会滑到114）WebGPU实现仍然很不成熟，但肯定足以开始使用。”FL33TW00D讲道，“在过去的几个月里，一直在实现Rust + WebGPU ML运行时，并且很喜欢编写WGSL。最近，我得到了一个250M参数的LLM在浏览器中运行，没有太多优化，它表现得很好！也就是说，matmuls在浏览器中仍然有很大的缺陷（特别是考虑到浏览器中强制执行的边界检查）。在我的基准测试中，我一直在努力达到理论FLOPS的50%，当边界检查开始时，它会减少到30%。我期待访问帖子中提到的着色器核心。”
还有Burn（Rust深度学习框架）项目的贡献者也表示将添加WebGPU后端。
WebGPU，晚了吗？
当然，也有一些开发者对WebGPU如今才发布是不是还“赶趟”表示怀疑。前Unity游戏引擎工程师Aras Pranckevičius提出疑问，“WebGL已经过时了。我想知道WebGPU是不是也有点晚了（比如现在Vulkan认为PSOs可能不是一个好主意，哈哈）。”
他补充道，就像8年前一样，WebGPU是一种“现代图形API设计”。迟做总比不做好，但是……“现代”的概念如今似乎在朝着这样的方向发展：无绑定的一切（就像“无绑定”的含义的第三次迭代）、网格着色器、光线跟踪、灵活的管道状态。然而，所有这些都不在WebGPU中。
对此，谷歌图形管道工程师Corentin Wallez回应道，原生API确实向前发展了，而PSO确实推动了游戏开发者们当时认为他们可以维持的特定方向（预编译所有内容，结果并非如此）。他表示，WebGPU必须支持目前使用的所有硬件，包括不支持无绑定或网格着色器的设备。“但希望在第一个版本之后，它会继续改进，并赶上一些重要的新功能。”
另外，开发者“flohofwoe”表示赞同Aras的观点，但他认为，“房间里的大象”仍然是糟糕的移动GPU。这些新奇技术中的大多数都不适用于移动GPU，并且在可预见的未来可能仍然不会。（Vulkan实际上应该有两个API：一个用于桌面GPU，一个用于移动GPU——这些新扩展正在将Vulkan分成两个或多或少分别独立的API，一个对于移动GPU来说很糟糕，另一个相当不错，但只适用于桌面GPU。）
“WebGPU无法承受这样的分裂。它必须在同一代码库的桌面和移动设备上同样出色地工作（移动设备实际上比桌面设备重要得多）。”flohofwoe表示。
WebGPU VS WebGL
那么，作为WebGL的继承者，有开发者提出WebGPU与WebGL的差异究竟如何？贝壳找房资深工程师郝稼力曾在GMTC全球大前端技术大会上分享了他对两者做的性能对比，我们可以看下。
这是复杂场景的渲染性能对比。这个场景中有1000棵树，它们不是使用实例化绘制的，而是每一棵树都有一个draw call，所以一个场景我要有1000多个draw call。如果使用WebGL进行绘制的话，可以看到，使用2070显卡只能跑到21FPS，而且每一帧的CPU时间需要44毫秒，但是同样用WebGPU来处理，可以跑到123帧，每一帧的CPU时间只有0.1毫秒，这个是WebGPU和WebGL最大最显著的性能上的差距。
另外就是一个代码上的差距。用WebGL原生API绘制的过程，所有的东西的起点都在于Canvas；然而这是一件很不可思议的事情，就是即使不需要画什么东西，用户也需要创建一个Canvas元素，这个操作对于前端可能是无感知的，但是对于浏览器开发者来说就要新建一个DOM元素，要给它增加所有它需要有的东西，一旦DOM元素崩溃了，浏览器要处理所有这些事情，对于开发者而言后面的事情就会变得非常复杂。
但是WebGPU不是这样，WebGPU的入口是navigator.gpu，用户可以从这里获取到一个显卡，再从显卡获取到一个设备，而中间的Canvas是没有的。
更多内容可查看《从WebGL到WebGPU，网页图形的全新时代》
参考链接