• 1. 常見問題
  • ① WebGL、ThreeJS 會淘汰嗎？WebGL 是不是過時了？WebGPU 性能是不是比 WebGL 強？
  • ② WebGPU 什么時候能用？怎么才能用 WebGPU？我學習 WebGPU 需要什么條件？
  • ③ WebGPU 有什么用？它解決了什么問題？
  • ④ 學了 WebGPU 是不是能寫出好看的效果？
  • ⑤ WebGPU 有缺點嗎？
• 2. 一些看法與分享
  • ① 使用分析與綜合的辯證思維，全面、聯系地看問題
  • ② 具體問題具體分析，抽象和具體應該結合在一起

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 行業中，好多團隊沒有分析清楚想做什么，需要用什么，喜歡堆砌、翻新名詞和概念，不喜歡落實到既有技術，結果就是“藍圖是國畫，實施是草圖，產出是垃圾”

分析和綜合的功力，區別在于深淺、邏輯、科不科學、系不系統上，

② 具體問題具體分析，抽象和具體應該結合在一起

簡單的說，就是在合適的范圍，說對應的語言，筆者曾經在討論時遇到很多技術水平不對等的交流，舉個例子：

輕量化三維模型以提高性能，

這句話是一句濃縮了很多技術細節的話：“輕量化”是一個可以由多階段、多目的構成的技術堆疊，“性能”也有諸多因素構成，可以說是“抽象”，

但是很多作業執行時，雖然以抽象概念為引領，但是我們必須結合具體的條目、具體的細節、技術，才能完成抽象概念想達成的目的，

用機關槍式的提問方法：輕量化三維模型的什么？輕量化是壓縮資料檔案的體積嗎？是減少三維模型的三角面，還是壓縮貼圖，還是使用更高效的資訊編碼技術？

“性能”如何定義？是幀速率、網路請求并發量、記憶體占用量、網路傳輸時間？

總而言之，抽象的概念就應該在大的領域定向，而在小的范圍內應該定量、具體地溝通與交流，

標籤：其他

上一篇：在Cesium中實作與CAD的DWG圖疊加顯示分析

下一篇：WebGPU 匯入[2] - 核心概念與重要機制解讀