两种用于开发现代图形软件的全新技术正在兴起。WebGPU 是 WebGL 的继承者，性能显著提升。然而，像素流式传输则朝着完全不同的方向发展，并被游戏行业积极使用。

在本文中，我们将展望不久的将来，研究一个假设的 3D 应用程序的顶层架构，并从开发人员的角度讨论 WebGPU 与像素流的优缺点。

1. 简介

想要开发软件的公司在开发过程中的某个阶段会问自己应该使用哪些技术。未来可行性方面的投资是一个需要考虑的点；例如，如果 XYZ 公司使用 Perl 编写应用程序，他们可能很难在 20 年后找到能够继续使用这项技术进行开发的新开发人员（The HFT Guy，2019 年）。

以下文章将讨论两种技术，它们为未来几年开发 3D 应用提出了重要问题：公司/开发者应该朝哪个方向投资？它们有哪些优势和劣势？最重要的是：这些技术是什么？

2. WebGPU

在我们讨论 WebGPU 之前，让我们先来看看 WebGL，以及为什么它不再有未来。

2.1 WebGL的缓慢消亡

别误会我的意思；WebGL 是一项了不起的技术！它允许开发人员创建交互式 2D 和 3D 图形，而这在标准 JavaScript 中是不可能实现的。与 Flash 等相比，它允许开发人员在网络上发布其内容而无需安装插件。几乎所有主流浏览器甚至手机都嵌入了 WebGL 1.0 和 WebGL 2.0 的实现。

由于技术通常不会在一夜之间消失，WebGL 肯定会继续存在很多年。无数的应用程序和框架都依赖于 WebGL，数百万人使用它们（Similarweb，nd），每天有数十万开发人员使用 WebGL 开发新软件（npm Inc.，nd）。这是完全可以理解的，因为开发人员可以使用 WebGL 等低级图形 API 创建出非凡的东西。最著名的例子是谷歌地图——尤其是谷歌地球（Shankland，2011）。这样的应用程序直到几年前才出现，而今天，我们已经习以为常，例如在网站上与 3D 内容进行交互——甚至在移动设备上也是如此！

WebGL 为开发人员提供了访问 GPU 所需的 JavaScript 绑定。​​WebGL API（尤其是图形库着色器语言 (GLSL) 中的着色器编程）很难使用。

只有少数开发人员（不包括我自己）了解 OpenGL 的复杂性，因此也了解 WebGL 的复杂性。

这就是 Three.js、Babylon.js 和 Playcanvas 等框架诞生的原因。这些框架基本上是在显卡之上的 WebGL、OpenGL 和图形卡上的抽象，用于理解 JavaScript 代码并在浏览器中渲染 2D/3D 图形。它们被广泛认可并且效果很好（Wappalyzer，nd）。但是，依赖一项已有 10 年历史的技术也有其缺点。自 2011 年以来，WebGL 一直基于 OpenGL ES，它是官方 OpenGL 图形 API 的一个子集，具有各种限制，例如不使用 3D 纹理、仅限于三角形网格等（The Khronos Group Inc.，nd）。从高层的角度来看，WebGL 是基于大约 15 年前对 GPU 技术的理解而构建的 API。从那时起，很多事情都发生了变化。最显著的变化之一是，现代 GPU 通常与共享内存访问配合使用，以比以前更高效的方式执行并行计算（Cabello 和 Wallez，2019）——这就是 WebGPU 发挥作用的地方。

2.2 共享内存

用我初学者的理解来简单解释一下：共享内存在概念上是每个算术逻辑单元 (ALU) 可以有效访问其他 ALU 逻辑而不是自行计算的地方 (Wallez，2020)。我喜欢将共享内存视为动态规划中的哈希图，它可以优化时空复杂度，例如，使用恒定时间操作遍历输入数组来访问来自前几次迭代的数据，而不是再次自行计算它们。

现代显卡 API（例如 Vulkan 或 Metal）使用共享内存等概念（以及许多其他概念）来优化其性能。我喜欢将 OpenGL 与 Vulkan 进行比较，就像将 C 与 JavaScript 进行比较一样：OpenGL（因此 WebGL 也是如此）之所以很慢，是因为其他 API 更接近实际硬件，并且或多或少也针对特定平台进行了优化（Hruska，2015 年）。OpenGL 并未针对这些新概念进行优化。许多开发人员因为这些新概念（如共享内存）和更佳性能的优势而转向 Vulkan、Metal 等。但是，为什么我们不能创建一种新的 OpenGL，使其能够与所有现代显卡 API 对话呢？与其将旧的本机技术移植到 Web，为什么我们不能创建一个 Web API，提供一些现代 API 可以理解的输出（类似于 WebAssembly 与 CPU 的协作方式（Mozilla Foundation，2021 年））？嗯，这正是 W3C 想要通过新的 WebGPU 浏览器标准实现的目标。

2.3 集体努力：WebGPU

WebGPU 是 Apple、Google、Microsoft 等多家公司共同努力的成果，目前正由 W3C 标准化以取代 WebGL（万维网联盟，日期不详）。与 WebGL 相比，WebGPU 不是现有原生图形 API 向 Web 的移植。它基于 Vulkan 等概念，旨在通过优化的架构在现代 GPU 上提供高性能（Wallez，2018 年）。它旨在能够编写 WebGPU 特定的 JavaScript，所有现代显卡 API 都能理解。

此外，WebGPU 是无状态的，允许命令重用，这意味着向 GPU 发送指令比使用 WebGL 更便宜，因为它会创建将提前使用的指令组（Cabello 和 Wallez，2019 年）。在运行时，它可以通过单个函数调用在整个指令组之间切换（得益于共享内存）。简要说明：WebGPU 的当前实现比 WebGL 快得多——尤其是在复杂场景中有很多 3D 对象实例的情况下。

2.4 限制在于用户

总而言之，WebGPU 听起来太完美了。只有一件事需要考虑：我们在不知道客户硬件的情况下将完整的源代码发送给客户。如果用户访问使用现代 WebGPU 技术制作的超先进科学可视化，但只有 5 年前的旧板载显卡怎么办？好吧，这是他们的错。这就像用户在 2021 年仍在使用 Internet Explorer 一样；典型的兼容性问题。但是，如果用户仍然需要更精致的 3D 图形和复杂的可视化怎么办？如果要求超出了普通消费者硬件怎么办？这听起来不可能，但一种新型技术允许开发人员解决这个问题。

3. 像素流

像素流（有时也称为渲染流或远程渲染）可以将托管云软件的视听输出流式传输到客户端（Antunes，2020 年）。客户端不需要昂贵的硬件——只需要良好的互联网连接。

3.1 像素流的工作原理

基本上，像素流式传输就是将繁重的逻辑从客户端转移到服务器。它是在专用硬件（例如专用 GPU）上开发软件并将视听输出流式传输给用户的概念。作为其中的一部分，客户端代码（如 JavaScript）也将被发送以实时与服务器的软件输出进行交互（Epic Games Inc.，nd）。从开发人员的角度来看，与 WebGL/WebGPU 相比，这使得像素流式传输成为一种较难获得的技术，因为它严重依赖昂贵的硬件。

然而，有了像素流，一切似乎都可能实现！开发人员可以制作只能在高端显卡上运行的尖端软件，而用户自己永远不需要购买高端显卡。

然而，问题恰恰在于可扩展性。公司/开发人员需要获得这种高端硬件的使用权。当然，有基础设施即服务 (IaaS) 提供商，如亚马逊网络服务 (AWS) 和谷歌云平台 (GCP)，但仍然存在一个重大限制：成本（Amazon.com Inc.，日期不详）。即使有了 AWS、GCP 等，在所需的高端硬件上运行软件也是一项计算成本高昂的任务，会消耗大量能源。是的，谷歌等公司似乎拥有无限的可用计算能力可供利用，但随着免费像素流应用程序的需求，人们会将其推向昂贵的极限。

NVIDIA、微软等公司的 Project Anywhere 等概念都有实际应用，它们都配备了针对流媒体优化的显卡（Woodard and Young，2020），甚至还运行了 Google Stadia 等产品（Patterson，2020）。然而，克服高昂价格因素的问题是，公司不能在网络上免费提供像素流媒体应用程序；他们需要一种付费模式才能访问。否则，公司可能会陷入财务困境（想象一下，对这样一个免费使用的应用程序进行 DDoS 攻击的成本）。

4. 假设应用：虚拟办公室

现在我们了解了这些技术以及它们的优缺点，让我们想象一下，在不久的将来，我们想要构建一个 3D 应用程序。该应用程序名为 Hejm，旨在为来自世界各地的人们提供一个 3D 虚拟办公室。无论他们经营什么样的业务，Hejm 都能为他们提供远程办公所需的工具。用户可以通过虚拟现实、增强现实耳机或标准电脑屏幕进入办公室。

4.1 像素流的复杂性

在像素流场景中，我们将编写 Hejm 软件以在云 GPU 实例（例如 AWS EC2 GPU）上运行。然后，我们创建软件的客户端，该客户端仅提供交互 JavaScript 代码，以通过实时通信协议访问服务器端逻辑。需要注意的问题是，对于每个访问用户，我们都需要启动一个正在运行的软件实例。可以将一个实例的输出流式传输到多个客户端（它们甚至可以与之交互），但这又是另一个缺点。截至目前，这种意义上的多人游戏只能通过多个实例（Epic Games Inc.，nd）实现，这也会增加成本。当然，我们可以修改我们的软件，使其经过优化，以便每个实例运行多个访问用户。尽管如此，每个 GPU 仍然存在垂直限制。

用户还应该能够实时交互，因此需要实例之间的实时服务器通信。实例还需要一个单一的真实来源来更新虚拟办公室内的更新。必须有一个同步模块来更新其他实例上的所有不同场景。然而，这意味着，如果许多人四处走动或做其他所有实例都可以看到的事情，那么简单的功能可能已经是巨大的计算任务，因此成本高昂。除此之外，虚拟办公室应用程序中还应该有聊天、视频和音频通话功能，而这些功能本身就很昂贵。

4.2 混合解决方案

在一个完美的假设世界中，WebGPU 将具有 >95% 的浏览器兼容性，并且几乎所有传统设备都支持新标准，这对 Hejm 来说将是非常激动人心的时刻！Hejm 将提供不同的产品，包括免费版（仅通过 WebGPU 在浏览器中运行）和企业版（每位用户每月收费约 400 美元）。需要像素流功能的公司（例如模拟制造 CAD 模型等）可能也愿意为这种远程优先解决方案支付额外费用（这样他们至少可以节省 PC 硬件和员工办公室的费用）。我甚至会更进一步，仅通过像素流显示虚拟办公室中的某些房间，让其余房间通过浏览器中的 WebGPU 运行——因此是一种混合解决方案。

5. 结论

就像许多事情一样，永远没有简单的解决方案。但公司/开发人员应该使用哪种技术？我认为这取决于情况。创建一款只能在高端硬件上运行、访问受限且用户群较小的高端 3D 软件：使用像素流进行开发。如果应用程序需要免费提供给数千甚至数百万用户，但不需要高级功能和可视化：使用 WebGPU。如果时间允许，并且有研发资源，我会鼓励公司和开发人员创建一种混合技术来满足两全其美的需求。

我个人也认为，在许多与软件相关的案例中，混合解决方案是最佳答案。

我将其与单页应用程序 (SPA) 和多页应用程序 (MPA) 之间的讨论进行了比较：首先，整个页面在服务器上创建，并以纯 HTML/CSS/JS 的形式发送到客户端。然后出现了 Angular、React 等，UI 逻辑层转移到了客户端；服务器仅用于处理和提供数据。然而，这种解决方案并不理想：小型网站过去常常发送数兆字节的 JavaScript 块只是为了显示一个简单的 UI (Tsarouva，2019)。Web 开发行业的这一部分目前也进入了混合阶段：服务器端渲染 (SSR) 和增量静态生成 (ISG)。这两个不同的术语值得单独写一篇文章；但简而言之：它们通过在服务器上预渲染最关键的软件部分来解决问题，并且所有需要异步的内容都将在浏览器中组合在一起 (Szczeciński，2018)。

6. 展望

关于前端与后端的整个话题是网络开发/软件行业正在进行的讨论。我认为永远不会有明显的赢家。令人兴奋的是，看看图形世界中的两个对手中哪一个会被广泛接受——特别是如果像素流是一个可以保留的东西，以及他们如何克服高价格的缺点。此外，也许我对混合解决方案的看法是正确的，或者也许一种全新的技术进入了这一领域？

关于像素流技术，我后续会出专栏。