WebGPU 原理與加速條件：WebGL 的差異、GPUDevice、Pipeline 與 WGSL

WebGPU API 讓網頁使用裝置的 GPU 執行高效能運算與複雜繪圖。MDN 將它介紹為可透過底層系統 GPU，在瀏覽器中進行高效能運算及繪製複雜影像的 API。

重點在於它不只是繪圖 API。WebGL 主要以圖形處理介面普及，而 WebGPU 從設計上就同時涵蓋繪製（render）與運算（compute）。

不過，使用 WebGPU 不代表任何工作都會變快。CPU 與 GPU 之間的資料傳輸、管線建立、同步、記憶體使用與瀏覽器驗證都有成本。對於規模很小的工作，Canvas 2D、WebGL、WebAssembly 或一般 JavaScript 反而可能更簡單、更快。

WebGL 將 OpenGL ES 的設計帶到網頁，讓瀏覽器可以呈現 3D 遊戲與視覺化內容。它也承襲了較早期圖形 API 的狀態管理方式：應用程式持續變更目前狀態，再送出繪圖指令。

WebGPU 的設計接近 Vulkan、Metal、Direct3D 12 等現代 GPU API。應用程式先準備繪圖或運算所需的設定，再透過命令編碼器（Command Encoder）記錄指令，最後提交至佇列（Queue）。

WebGL 的流程：
  bindBuffer()
  useProgram()
  enableVertexAttribArray()
  drawArrays()

WebGPU 的流程：
  adapter -> device
  shaderModule -> pipeline
  commandEncoder -> renderPass / computePass
  queue.submit()

差異不只在寫法。WebGPU 要求更明確地描述資料格式、使用的著色器，以及讀取的紋理（Texture）與緩衝區（Buffer）。初始化程式碼可能較長，但瀏覽器與驅動程式也能更早進行驗證與最佳化。

因此，WebGPU 並不是「更簡單的 WebGL」，而是讓開發者接觸更多底層設定。Three.js、Babylon.js 等函式庫，以及遊戲引擎或視覺化框架，可將 WebGPU 作為後端；應用程式開發者不一定要直接撰寫每一項 GPU 操作。

WebGPU 的入口是 navigator.gpu。在支援的環境中，先取得 GPUAdapter，再要求 GPUDevice。以下函式依序檢查 API、要求配接器及裝置，並處理取得失敗的情況。

async function requestWebGPUDevice() {
  if (!navigator.gpu) return null;
  try {
    const adapter = await navigator.gpu.requestAdapter();
    if (!adapter) return null;
    return await adapter.requestDevice();
  } catch (error) {
    console.warn("WebGPU 初始化失敗", error);
    return null;
  }
}

這個函式只負責初次取得裝置。如果 API 不存在、沒有可用的配接器，或要求失敗，就傳回 null。若應用程式需要額外功能或較高上限，應先檢查配接器的 features 與 limits，再指定對應的 requiredFeatures 與 requiredLimits。傳回的 Device 可能已經失效，因此要求成功不保證現在或之後都能使用。應監看 device.lost，在裝置失效時停止繪圖迴圈，再重新取得 Adapter 與 Device 並重建資源，或改用替代顯示。主動呼叫 destroy() 時不應自動重試，復原嘗試也應設上限。

GPUAdapter 代表瀏覽器選用的 GPU 實作及其提供的功能與上限。它可能對應整合式或獨立顯示晶片，也可能是軟體實作，不一定等同某個實體 GPU。GPUDevice 則是應用程式用來建立資源與指令的邏輯介面。

這項區分也與安全性有關。網頁不能直接、不受限制地控制 GPU；瀏覽器會管理存取條件、功能、限制與相容性，再提供邏輯裝置介面。WebGPU 的設計同時考量效能與網頁安全模型。

管線（Pipeline）是初學 WebGPU 時容易卡住的概念。它是一組描述 GPU 如何處理工作的設定，主要分為繪製管線（Render Pipeline）與運算管線（Compute Pipeline）。

繪製管線指定頂點與片段著色器、頂點資料格式、色彩輸出格式，以及深度測試等設定。運算管線則指定要執行的運算著色器。

WebGL 的狀態變更可能累積到繪圖前一刻，造成非預期的狀態沿用。WebGPU 將許多設定集中在管線中，較容易掌握。但建立管線本身也可能很耗時，通常應在初始化或需要時建立並快取，而不是每一幀都重建。

WebGPU 在 GPU 上執行的程式以 WGSL（WebGPU Shading Language）撰寫。日文原文於 2026 年 11 月 11 日確認的 W3C 文件，是 2026 年 11 月 6 日發布的 Candidate Recommendation Draft，內容定義 WebGPU 的著色器語言。

WGSL 使用屬性標示著色器入口。主要的階段屬性為 @vertex、@fragment 與 @compute。

@vertex
fn vs(@builtin(vertex_index) i: u32) -> @builtin(position) vec4f {
  let positions = array<vec2f, 3>(
    vec2f(0.0, 0.6), vec2f(-0.6, -0.6), vec2f(0.6, -0.6)
  );
  return vec4f(positions[i], 0.0, 1.0);
}

@fragment
fn fs() -> @location(0) vec4f {
  return vec4f(0.2, 0.7, 1.0, 1.0);
}

@compute @workgroup_size(64)
fn cs(@builtin(global_invocation_id) id: vec3u) {
  // 僅示範入口語法，不進行運算或輸出。
}

上方頂點範例用於 draw(3)，且第一個頂點索引為 0，以三個位置繪製三角形。運算入口刻意留空，只示範語法，不會產生運算結果。實際運算還需要綁定緩衝區等資源，並呼叫 dispatchWorkgroups()。

WGSL 考量了網頁環境的驗證需求，明確描述型別、位址空間、資源綁定與入口點，讓瀏覽器能在執行前檢查。這些限制有助於避免網頁依賴不安全的 GPU 操作。

瀏覽器不會把 WGSL 原始碼字串原封不動地交給 GPU。瀏覽器實作會依平台進行驗證與轉換，透過 Metal、Direct3D 12、Vulkan 等底層圖形介面執行。開發者使用的是 WebGPU 與 WGSL 提供的抽象層。

以下片段假設已備妥可用的 device、由 WGSL 建立的 renderPipeline，以及包含目標紋理檢視、且格式與管線輸出相符的 renderPassDescriptor。若要繪製到 Canvas，還需要取得並設定 WebGPU 繪圖環境；這個片段本身不是完整的繪圖程式。

WebGPU 將繪圖與運算指令記錄在 GPUCommandEncoder 中，再把完成的命令緩衝區提交至 GPUQueue。

const encoder = device.createCommandEncoder();

const pass = encoder.beginRenderPass(renderPassDescriptor);
pass.setPipeline(renderPipeline);
pass.draw(3);
pass.end();

device.queue.submit([encoder.finish()]);

這個流程乍看比較迂迴，但 CPU 與 GPU 是不同的執行單元。CPU 先組合指令，再整批提交給 GPU，有助於瀏覽器與驅動程式管理執行順序及資源狀態。

queue.submit() 呼叫返回，不代表 GPU 已完成工作。如果 CPU 需要讀取結果，必須使用適當的同步機制，例如緩衝區的 mapAsync()。WebGL 也不是每次呼叫都等待 GPU 完成；關鍵差異在於明確的指令記錄與設定方式。

設計 WebGPU 程式時，應思考如何將工作整理成批次交給 GPU。它需要調整工作組織方式，而不只是逐一替換 API 呼叫。

WebGPU 與 WebGL 的重要差異之一，是將運算著色器（Compute Shader）列為核心功能。它在 GPU 上執行平行運算，不必以直接繪製畫面為目的。

以影像處理為例，對一千萬個像素套用相同濾鏡時，各像素的運算往往有很大部分能獨立進行。CPU 也能平行處理，但 GPU 特別適合大量相似的運算。

• 影像模糊、銳利化與色彩轉換
• 粒子模擬與物理運算
• 大量頂點或實例資料的前處理
• 神經網路的矩陣與張量運算

使用運算著色器不會自動帶來加速。資料傳輸成本、工作群組的大小、記憶體配置、管線重用，以及是否需要把結果讀回 CPU，都會影響效能。

WebGPU 也可用於瀏覽器內的 AI 推論，但不是所有模型都能流暢執行。模型大小、量化格式、記憶體需求、瀏覽器實作與裝置 GPU 效能，都會左右實際表現。

GPU 不只服務某個網頁。作業系統、瀏覽器、其他應用程式及其他分頁，都可能共用同一個 GPU。因此，即使 WebGPU 提供較底層的高效能介面，仍須遵循網頁安全模型。

WebGPU 會驗證緩衝區與紋理的用途、著色器型別、資源綁定及管線設定等。驗證錯誤（Validation Error）表示某項操作未符合 API 的驗證規則。

初學時，這些檢查可能讓「為什麼沒有畫面」更難理解；不過，它們是避免網頁依賴非法 GPU 記憶體存取或未定義行為的重要機制。

WebGPU 在 HTTPS 等安全環境（secure context）中提供。即使本機開發時能使用，正式環境的傳送條件或瀏覽器設定仍可能讓它不可用。使用 WebGPU 的功能應包含支援判定與替代顯示。

截至日文原文 2026 年 11 月 11 日的確認，MDN 仍將 WebGPU API 標示為 Limited availability，表示部分廣泛使用的瀏覽器環境仍不支援。因此，不宜直接宣稱「WebGL 已經不需要了」。

實務上可從以下分支結構開始設計：

// 使用上方定義的 requestWebGPUDevice() 函式。
const device = await requestWebGPUDevice();
if (device) {
  // 初始化 WebGPU 繪圖程式，並處理設定錯誤與裝置失效。
} else {
  const fallbackCanvas = document.createElement("canvas");
  const gl = fallbackCanvas.getContext("webgl2");
  if (gl) {
    // 將 fallbackCanvas 加入頁面，並以 gl 初始化 WebGL2 繪圖程式。
  } else {
    // 提供 Canvas 2D、靜態圖片或伺服器端替代方案。
  }
}

這只是控制流程片段，註解中的繪圖與替代介面仍須另外實作。navigator.gpu 存在，不代表配接器、裝置要求或應用程式初始化一定成功。初始化失敗與裝置失效，也都需要替代路徑。相同 Canvas 取得一種繪圖環境後，不能再取得不同種類；切換繪圖後端時應改用新的 Canvas。

教育內容、公共服務、醫療與業務系統，以及購物結帳等重要流程，不宜只提供 WebGPU 路徑。WebGPU 可以改善體驗，但基本功能能否使用，仍須依服務對象的環境評估。

對於能明確告知支援環境的專業編輯器、3D 檢視器、遊戲、影像處理及 AI 輔助功能，WebGPU 則是值得評估的選項。裝置條件合適時，瀏覽器本身就能處理相當複雜的工作。

WebGPU 很強大，但是否採用，仍應依工作負載與維護條件判斷。

WebGPU 並不是 Canvas 2D 或 CSS 動畫的通用替代品。當資料與運算流程都能配合 GPU 的執行方式設計時，才較容易發揮優勢。

WebGPU 的重點不只是「瀏覽器可以使用 GPU」——WebGL 早已做到這件事。它讓 GPU 工作的設定、記錄與提交方式更加明確。

• WebGL 讓網頁 3D 普及，也承襲 OpenGL ES 的狀態管理方式。
• WebGPU 透過 GPUAdapter、GPUDevice、Pipeline、CommandEncoder 與 Queue 明確組織工作。
• WGSL 提供 vertex、fragment 與 compute 入口。
• 除了繪圖，也支援運算，因此可用於影像處理與 AI 工作負載。
• 支援仍有限，實務上需要判定可用性並準備替代方案。

WebGPU 不會立刻取代 WebGL，而是把瀏覽器的 GPU 使用方式拓展到現代圖形與運算模型。面對大量繪圖或運算需求時，值得把它與實作成本、維護能力及支援環境一起評估。