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 前端开发三大硬技能：网络申请面板（看申请耗费和抓包）、源代码调试面板（尽量用断点代替 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 行业中，好多团队没有剖析分明想做什么，须要用什么，喜爱堆砌、翻新名词和概念，不喜爱落实到既有技术，后果就是“蓝图是国画，施行是草图，产出是垃圾”
剖析和综合的功力，区别在于深浅、逻辑、科不迷信、系不零碎上。
② 具体问题具体分析，形象和具体应该联合在一起
简略的说，就是在适合的范畴，说对应的语言。笔者已经在探讨时遇到很多技术水平不对等的交换，举个例子：
轻量化三维模型以进步性能。
这句话是一句稀释了很多技术细节的话：“轻量化”是一个能够由多阶段、多目标形成的技术栈，“性能”也有诸多因素形成，能够说是“形象”。
然而很多工作执行时，尽管以抽象概念为引领，然而咱们必须联合具体的条目、具体的细节、技术，能力实现抽象概念想达成的目标。
用机关枪式的发问办法：轻量化三维模型的什么？轻量化是压缩数据文件的体积吗？是缩小三维模型的三角面，还是压缩贴图，还是应用更高效的信息编码技术？
“性能”如何定义？是帧速率、网络申请并发量、内存占用量、网络传输工夫？
总而言之，形象的概念就应该在大的畛域定向，而在小的范畴内应该定量、具体地沟通与交换。