为什么精通webgl、webgpu的人很少？
为什么精通webgl、webgpu的人很少？
不妨来看看我写的文章，我对一些常见问题写出了自己的看法：
更多内容可以看看我其它的文章，动动小手点个关注或点个赞就可以
以下为原文：
1. 常见问题
① WebGL、ThreeJS 会淘汰吗？WebGL 是不是过时了？WebGPU 性能是不是比 WebGL 强？
ThreeJS 会淘汰吗？
ThreeJS、BabylonJS 两个应用级 3D 库一直在设计 WebGPU 为底层的新渲染器，后者尤为积极。
什么是应用级？这两个库都屏蔽了 WebGL 的底层调用细节，大多数时候，你编写的代码更专注于“场景”中的“三维物体”的位置，加载“模型文件”，高级点的会写漂亮的“材质”。这些带引号的概念，在 WebGL 底层接口都是没有的，是实时渲染技术的一些概念在 JavaScript 中的实现。
如果你是应用级别的开发者，不关心这些库如何封装底层图形 API，那现在大可不必入场，等正式发布再了解也不迟，毕竟这两个受众这么广的库，为了保持稳定性，在上层封装上不会短时间内进行激进改动。
WebGL 会淘汰吗？WebGL 是不是过时了？
短时间内不会，至少 10 年内。不信你看看 Java8？（开个玩笑）
WebGL 1.0 发布至今已有 10 年，完全落实 WebGL 2.0 的实现也才一年（截至发文），有很多作品、程序依旧在用基于 WebGL 技术族运行着，发光发热。借用马克思主义哲学的一个原理，是说“旧事物在它的作用没有完全发挥出来之前是绝不会自行消亡的，旧事物当中除了消极因素，依然存在积极因素”。
WebGL 的“全局状态”机制继承自 OpenGL，有大量的资料可供查询，大量的案例仍存于互联网中。
WebGPU 的性能是不是比 WebGL 强？
有一部分人被 WebGPU 吸引过来的原因是“跨平台 + 性能”这对组合。
诚然，WebGL 对比 Canvas2D 绘图技术的性能，是直接碾压的，在这十年中给 Web 前端带来了高性能的可能，但是长时间的实践下来，有的人发现了“WebGL 程序有时候，并不是那么快，甚至卡的要死”，他们 也许不会深究底层原因，直接寄希望于一个他们认为的新的王：WebGPU，这其实是一种很不唯物主义的、非常唯心主观的看法。
WebGPU 从设计上来看，确实有不少特征是优于 WebGL 的，列举如下：
- PromiseAPI / async + await 的异步语法加入：对网络数据加载、解码等同步耗时操作有了更好的支持，一定程度上避免了回调地狱问题
- 面向对象的 API 设计：相对于 WebGL API 的过程式调用，选项式图形 API 的使用更科学
- 不再使用全局状态机制：使用指令缓冲节约了 CPU 到 GPU 之间的信息传递成本，要知道 WebGL 切换某个状态（例如纹理、着色器程序），就是在切换全局状态对象，这个在微观上是比较耗时的，而 60 帧速率的每一帧只有 16.67 毫秒左右，能在微观节约每一点每一滴的时间，累计起来就不少了
- 原生支持计算管线、计算着色器：WebGL 磨磨蹭蹭实现的 GPU 并行计算功能直接提供出来，并与渲染管线地位对等
但是这些仅仅是在底层的对话基础上比 WebGL 强，这些底层解决的问题，不一定是有的朋友的“性能问题”。譬如，在应用层、代码逻辑层可能会有这些原因导致了“性能问题”：
- 单帧时间内，JavaScript 代码的解释运行的性能消耗远超 GPU 渲染耗时，导致 rAF 一帧大于 16.67 毫秒，这个时候应该反思在 JavaScript 这一侧各路函数调用耗时多久；这种情况可能是数据编解码耗时、频繁 new 了复杂对象、使用了繁重的 for 循环等；
- 着色器中使用了过量的灯光、巨大的贴图，也就是即便在 JavaScript 一侧进行了数据选择、剔除后，仍然让 GPU 执行负担较重的逻辑、硬件采样计算（而不是它擅长的简单并行运算）
- 单帧内频繁切换状态数据（着色器对象、纹理、顶点缓冲等），导致过多的 DrawCall
- 低端性能的硬件想玩复杂的应用场景；高估了浏览器 JavaScript 的性能、浏览器能调用的内存大小
所以说，一味寄希望于新的王，而不从实际出发审视问题，是解决不了问题的。
② WebGPU 什么时候能用？怎么才能用 WebGPU？我学习 WebGPU 需要什么条件？
WebGPU 什么时候能用？
WebGPU 标准是多个大技术团体相互制衡、妥协的产物，包括但不限于微软、苹果、谷歌等。官方一直在拖延 1.0 版本的发布时间，保守估计 2022 年第四季度上线三大浏览器正式版是最快的结果了，不保守估计可能还要到 2023 年上半年。
怎么才能用 WebGPU？
当前，推荐在以下 PC 端浏览器试用 WebGPU 及其着色器语言 WGSL：
- Google Chrome，使用 Canary 频道（即金丝雀）
- Microsoft Edge，使用 Canary 频道（内核与 Chrome 同宗）
- Firefox，使用 Nightly 频道
- Safari，使用 Technology Preview 频道
虽然正式频道也能用，但是在没发布 1.0 版本之前，都要去申请一个 Origin Trial Token 写在 HTML 代码中，笔者觉得麻烦，当然读者也可以选择配置这个在正式版浏览器中使用。
移动端、Linux 系统恐怕还要等好久（5年后？）。
我学习 WebGPU 需要什么条件？
学习 WebGPU，你要有这样的硬件储备：
- 一台 Windows / macOS 电脑，能运行上述浏览器
- 一些输入设备，例如鼠标键盘
你还需要这样的编程知识储备：
- 合格的 ES6 语法使用习惯，尤其是新的变量声明关键词
const/let、箭头函数、类、反引号字符串、PromiseAPI，最好能用到 ES7 的异步语法async/await； - 一款趁手的代码编辑器，我习惯 VSCode；
- 知道怎么使用 HTTP 协议打开你的页面，运行 HTTP 协议下的 JavaScript 代码，而不是愚蠢的双击 .html 文件用 File 协议打开，你可以使用 VSCode 的 Live-Server 插件，也可以用 Python 调起 HTTP 服务，也可以用 Nginx 等 Web 服务器软件，甚至用前端工具提供的开发服务器；
- 最好掌握简易的立体解析几何（求向量夹角、点线距离等）、线性代数基本功（行列式与向量常规运算）、3D 空间变换与矩阵的基础知识
你可能不需要掌握，但是会了如虎添翼的技能：
- 主流前端框架与各大打包器的基本使用与运行关系，例如 Webpack 是如何用 loader 处理各种资源文件的、vite 等工具的“路径”问题、避免前端框架的性能弱点用法等
- 常用设计模式的使用
- 基于 NodeJS 包机制的前端工程与浏览器应用程序的关系，了解 JavaScript 的运行时环境、JavaScript 模块化规范
- 使用浏览器进行 Web 前端开发三大硬技能：网络请求面板（看请求消耗和抓包）、源代码调试面板（尽量用断点替代 http://console.xxx）、性能测试面板的使用（精准分析性能问题）
- 一定的实时渲染技术积累：这个对于老鸟来说可能会心一笑，但是对于新手来说可能有点蒙，别急，在下面 1.4 小节会细谈
③ WebGPU 有什么用？它解决了什么问题？
WebGPU 有什么用？
WebGPU 是一个跨平台的图形 API 规范，目前能提供的功能有：
- 渲染绘图
- 跨平台调用 GPU 并行计算
前文提及的“计算管线”对应这里的第二点，而沿袭自 WebGL —— 准确的说 GPU 从 CPU 分离之初的首要目的，即“渲染绘图”功能，则是对应了 WebGPU 的“渲染管线”。
我认为，WebGPU 最大的作用可能并不体现在渲染管线上，毕竟它只是对三大原生图形 API 的封装，渲染这方面由 WebGL 实践了这些年，在浏览器上的表现可能已经没有特别惊艳的效果提升了，解决的应该只是 1.1 小节中的各种底层问题；
最大的作用反而应该是较之于 WebGL 更易用的 GPU 并行计算功能，也就是计算管线的新设计。
补充 1.1 小节中 WebGPU 比 WebGL 更先进的 2 个点：
- 脱离 Canvas 元素的依赖，绘图时才需要配置上下文对象与 HTMLCanvasElement 的关系，令 Canvas 作为绘图的容器，也就是一个比较特殊的纹理
- 因为不再强依赖于 Canvas，而是直接从浏览器的 navigator 全局对象上调取 GPU 的使用，所以可以在 WebWorker 中使用 WebGPU，跳出主线程访问 GPU 的能力，进一步增强了 CPU 侧的调度能力（不过就目前来看，这一点优化还不是太好的样子）
第一点就是 WebGPU 计算管线的底气。
当下，使用 GPU 进行深度学习、机器学习的应用有不少，以往想通过 JavaScript 来完成 GPGPU 实在是太麻烦了。WebGPU 允许更好地摆脱浏览器环境 —— 当然，在浏览器环境中，我也可以不参与绘图，使用计算管线就可以做出很多有趣的事情来，不仅仅是 DL、ML。
读者可能知道，如果不知道就当听故事，除了浏览器、NodeJS，有一个叫 Deno 的工具也是 JavaScript 的运行时，它内置了 Firefox 浏览器的 WebGPU 实现成果，也就是 Wgpu 库，Wgpu 使用 Rust 语言实现 WebGPU 规范。
也就是说，Deno 是可以运行 WebGPU 的，虽然它不具备浏览器的多数功能，但是它就是能调起 WebGPU，调用计算管线，完成并行计算。
WebGPU 的实现还有几个，Chrome 和 Edge 在用的是 Google 的 Dawn 项目，使用 C++ 实现 WebGPU 规范，苹果 Safari 是自己家的内核更新实现 —— 这些就是浏览器能调用三大图形 API 的底层原因。
如果你愿意，你也可以把 Dawn 或者 Wgpu 拉下来，直接使用 C++ 或 Rust 来调用这些实现，而不是要经过 JavaScript 运行环境。
它解决了什么问题？
在 1.1 小节和本小节已做出解释，它解决的是 WebGL 长期以来的底层技术问题，把各大厂商安顿好了，在图形技术上达成了一致，建立起新的技术垄断（不是
④ 学了 WebGPU 是不是能写出好看的效果？
这个问题和“会用厨具能不能做出一桌好菜”一样。
WebGPU 和 WebGL，甚至底层的 D3D、Metal、Vulkan 乃至 OpenGL 一样，只是一套调用 GPU 的接口。想要从机械的 GPU 绘图动作，枯燥的 Buffer、纹理贴图、状态值中实现光彩夺目、栩栩如生的渲染效果，还需要结合实时渲染（RealTimeRendering）、图像处理、光线追踪等众多技术。
有一个分享着色器特效的网站，叫 Shadertoy，上面有很多使用片元着色器实现的好看效果，这就是一个典型的例子，它就没有让开发者写什么 WebGL、WebGPU、ThreeJS，你只需要遵守它的规则，就可以实现很多好看的东西 —— 前提是，这些实现，都是基于上面说的非 API 技术的。
例如，下面几个入门、进阶“效果”，严格来说与 WebGL、WebGPU 这些图形 API 无关：
- 点光、环境光、聚光、平行光等光源的使用
- 各种阴影技术
- 各类材质实现
- 后处理图像算法，例如模糊、环境光遮蔽
虽然无关，但是实现起来或多或少离不开这些图形 API —— 我想说的是看待的时候应该界限分明，学的时候又不应该孤立看待。WebGPU 作为一种跨平台标准，一种 API，它是工具属性，并不是“好看效果”的招牌、核心。
⑤ WebGPU 有缺点吗？
当然有。
- 1.0 制定时间略长，从 2021 年望到 2022，眼看可能要到 2023
- 资料太少了，尤其是中文资料，不知道是了解的人不多，还是大佬不屑于写
- 原来的 WebGL 技术和资料不能低成本迁移，例如新旧概念的更替、着色器代码的移植
- 兼容性是一个很漫长是事情，望天
- 对于应用层开发者来说，没有能马上就用的封装库和足够的例子，也许推广起来比较困难，前人还未栽树，后人甚至还得开荒
所以，可预见的估计，哪怕今年年底能发布 1.0 版本，想要广泛应用这套标准于绘图渲染，保守估计都要等 3 年以上，用户的浏览器可能更新得并没有那么勤快。
2. 一些看法与分享
这部分结合了唯物辩证法。
① 使用分析与综合的辩证思维，全面、联系地看问题
图形 API 应与实时渲染、图像处理等技术分开看待，但是不能忽略它们的紧密联系。
大多数人不缺综合的能力，而是缺少系统的分析的能力，不喜欢把事物细致剖析成各个具体的细小环节来研究。
就举两个例子：
- 好多人在学习 WebGL 时没有界清哪一部分属于 API 规范函数的使用，哪一部分属于渲染技术的代码实现，哪一部分属于基础的空间立体几何变换，就把锅甩给“WebGL和3D好难”这个结论上，以至于现在学习 WebGPU 也可能有这个毛病
- GIS 行业中，好多团队没有分析清楚想做什么，需要用什么，喜欢堆砌、翻新名词和概念，不喜欢落实到既有技术，结果就是“蓝图是国画，实施是草图，产出是垃圾”
分析和综合的功力，区别在于深浅、逻辑、科不科学、系不系统上。
② 具体问题具体分析，抽象和具体应该结合在一起
简单的说，就是在合适的范围，说对应的语言。笔者曾经在讨论时遇到很多技术水平不对等的交流，举个例子：
轻量化三维模型以提高性能。
这句话是一句浓缩了很多技术细节的话：“轻量化”是一个可以由多阶段、多目的构成的技术栈，“性能”也有诸多因素构成，可以说是“抽象”。
但是很多工作执行时，虽然以抽象概念为引领，但是我们必须结合具体的条目、具体的细节、技术，才能完成抽象概念想达成的目的。
用机关枪式的提问方法：轻量化三维模型的什么？轻量化是压缩数据文件的体积吗？是减少三维模型的三角面，还是压缩贴图，还是使用更高效的信息编码技术？
“性能”如何定义？是帧速率、网络请求并发量、内存占用量、网络传输时间？
总而言之，抽象的概念就应该在大的领域定向，而在小的范围内应该定量、具体地沟通与交流。
