Web 高级着色语言（WHLSL） - 为WebGPU设计的Web图形着色语言

译者：UC 国际研发 Jothy> 写在最前：欢迎你来到“UC国际技术”公众号，我们将为大家提供与客户端、服务端、算法、测试、数据、前端等相关的高质量技术文章，不限于原创与翻译。本文介绍了一种新的 Web 图形着色语言：Web 高级着色语言（WHLSL，发音为 “whistle”）。 这种语言受 HLSL 的启发，HLSL 是图形应用开发人员用的主要着色语言。 它扩展了 Web 平台的 HLSL，使其安全可靠。 它易于阅读和编写，使用了正式技术而可以很好地指定。背景

在过去的几十年中，3D 图形已经发生了重大变化，程序员用来编写 3D 应用的 API 也发生了相应的变化。五年前，最先进的图形应用使用 OpenGL 来执行渲染。然而，在过去几年中，3D 图形行业正朝着更新，更低级别的图形框架转变，这种框架更符合真实硬件的行为。 2014 年，Apple 创建了 Metal 框架，让 iOS 和 macOS 应用可以充分利用 GPU。 2015 年，微软创建了 Direct3D 12，这是 Direct3D 的一个重大更新，它允许控制台级的渲染和计算效率。

2016 年，Khronos Group 发布了 Vulkan API，主要用于 Android，具有类似的优势。

就像 WebGL 将 OpenGL 引入 Web 一样，Web 社区正在寻求将这种类型的新型低级 3D 图形 API 引入平台。去年，Apple 在 W3C 内部建立了 WebGPU 社区组，以使新的 3D 图形 API 标准化，该 API 提供了原生 API 的优势，但也适用于 Web 环境。这个新的 Web API 可以在 Metal，Direct3D 和 Vulkan 之上实现。所有主要的浏览器厂商都参与并为该标准化工作做出贡献。这些现代 3D 图形 API 中的每一个都使用着色器，WebGPU 也不例外。着色器是利用 GPU 专用架构的程序。特别是，在重型并行数值处理中，GPU 要优于 CPU。为了利用这两种架构，现代 3D 应用使用混合设计，使用 CPU 和 GPU 来完成不同的任务。通过利用每个架构的最佳特性，现代图形 API 为开发人员提供了一个强大的框架，可以创建复杂，丰富，快速的 3D 应用程序。专为 Metal 设计的应用使用 Metal Shading Language，为 Direct3D 12 设计的应用使用 HLSL，为 Vulkan 设计的应用使用 SPIR-V 或 GLSL。语言要求

就像它的原生同行一样，WebGPU 也需要一种着色器语言。这种语言需要满足几个要求，以适合 Web 平台。

它需要是安全的。无论应用做什么，着色器必须只能从网页的域中读取或写入数据。如果没有这种保证，恶意网站可以运行着色器，从屏幕的其他部分读取像素，甚至是本机应用。它需要明确指定语言规范。语言规范必须明确是否每个可能的字符串都是有效的程序。与所有其他 Web 格式一样，必须精确指定 Web 的着色语言以保证浏览器之间的互操作性。

它也需要明确指定编译规范，以便它可以用作编译目标。许多渲染团队使用内部自定义语言编写着色器，然后交叉编译为必要的语言。出于这个原因，语言应该有一组相当少的明确的语法和类型检查规则，编译器编写者在发出这种语言时可以参考这些规则。它需要翻译成 Metal Shading Language，HLSL（或 DXIL）和 SPIR-V。这是因为 WebGPU 被设计为能同时在 Metal，Direct3D 12 和 Vulkan 之上工作，因此着色器需要能够以以上每个 API 都可以接受的形式表示。

它需要具有高效性。开发人员首先想要使用 GPU 的终极原因是性能。编译器本身需要快速运行，编译器生成的程序需要在真正的 GPU 上高效运行。它需要使用 WebGPU API 进行演变。 WebGPU 功能（如绑定模型和曲面细分模型）与着色语言深度交互。尽管使用独立于 API 开发的语言是可行的，但在同一论坛中使用 WebGPU API 和着色语言可确保共享目标，并使开发更加简化。

它需要易于开发者阅读和编写。这包括两个部分：首先，GPU 程序员和 CPU 程序员都应该熟悉这种语言。 GPU 程序员是重要的用户，因为他们有编写着色器的经验。 CPU 程序员很重要，因为 GPU 越来越多地用于渲染之外的目的，包括机器学习，计算机视觉和神经网络。对于他们来说，语言应该与熟悉的编程语言概念和语法兼容。第二部分是语言应该是人类可读的。 Web 的文化是任何人都可以用文本编辑器和浏览器开始编写网页。内容的民主化是 Web 最大的优势之一。这种文化创造了一个丰富的工具和审查员生态系统，修补者可以通过 View-Source 调查任何网页的工作方式。使用单一规范的人类可读语言将极大地帮助社区采用 WebGPU API。

当今网络上使用的所有主要语言都是人类可读的，但有一个例外。 WebAssembly 社区组希望解析字节码比解析文本语言更有效。但事实证明并非如此; Asm.js 是 JavaScript 源代码，在许多用例中仍然比 WebAssembly 快。类似地，使用诸如 WebAssembly 之类的字节码格式并不能避免浏览器对源代码进行优化的需要。每个主要浏览器在执行之前都会在字节码上运行优化。不幸的是，追求更简单的编译器的愿望从未结束。

社区小组正在积极讨论这种人类可读的语言是否应该是 API 本身接受的语言，但该小组同意着色器编写的语言应该易于读写。一种新语言？真的吗？

虽然有许多现有语言，但没有一种语言设计时考虑到 Web 和现代图形应用程序，并且没有一种语言符合上面列出的要求。在我们描述 WHLSL 之前，让我们看看一些现有的语言。Metal Shading Language 与 C++ 非常相似，这意味着它具有位转换和原始指针的所有功能。它非常强大; 甚至可以为 CPU 和 GPU 编译相同的源代码。将现有的 CPU 端代码移植到 Metal Shading Language 非常容易。不幸的是，所有这些能力都有一些缺点。例如，在 Metal Shading Language 中，你可以编写一个着色器，将指针转换为整数，添加 17，将其强制转换回指针，然后取消引用它。这是一个安全问题，因为它意味着着色器可以访问恰好位于应用程序地址空间中的任何资源，这与 Web 的安全模型相反。从理论上讲，可以指定一个没有原始指针的 Metal Shading Language，但指针对于 C 和 C++ 语言来说是如此基础，结果将完全陌生。 C++ 也严重依赖于未定义的行为，因此任何完全指定 C++ 众多功能的努力都不太可能成功。

HLSL 是便携 Direct3D 着色器的受支持语言。它是目前世界上最流行的实时着色语言，因此是图形程序员最熟悉的语言。有多种实现，但没有正式的规范，因此很难创建一致的，可互操作的实现。尽管如此，鉴于 HLSL 无处不在，在 WHLSL 的设计中尽可能采用其语法是很有价值的。GLSL 是 WebGL 使用的语言，并被 WebGL 用于 Web 平台。但是，由于 GLSL 编译器不兼容，达到跨浏览器的互操作性极其困难。由于仍然存在长期的安全性和可移植性错误，GLSL 仍处于调研中。此外，GLSL 到年纪了。它的局限性在于它没有类似指针的对象，或者具有可变长度数组的能力。它的输入和输出是具有硬编码名称的全局变量。

SPIR-V 被设计为开发人员将使用的实际着色语言的低级通用中间格式。人们不写作 SPIR-V; 它们使用人类可读的语言，然后使用工具将其转换为 SPIR-V 字节码。

在 Web 上采用 SPIR-V 存在一些挑战。首先，SPIR-V 不是以安全性作为第一原则编写的，并且不清楚是否可以对其进行修改以满足 Web 的安全性要求。Fork SPIR-V 语言意味着开发人员必须重新编译着色器，可能还是被迫重写他们的源代码。此外，浏览器仍然无法信任传入的字节码，并且需要验证程序以确保它们没有做任何不安全的事情。由于 Windows 和 macOS/iOS 不支持 Vulkan，因此传入的 SPIR-V 仍需要翻译/编译成另一种语言。奇怪的是，这意味着在这两个平台上，起点和终点都是人类可读的，但介于两者之间的位被混淆而没有任何好处。其次，SPIR-V 包含 50 多个可选功能，它们的实现是选择性支持的，因此使用 SPIR-V 的着色器作者不知道它们的着色器是否可以在 WebGPU 实现上工作。这与 Web 的一次写入运行特性相反。

第三，许多图形应用程序（如 Baby