WebGPU 原理與加速條件：與 WebGL 的分別、GPUDevice、Pipeline 及 WGSL

WebGPU API 讓網頁透過裝置的 GPU 進行高效能運算及複雜繪圖。MDN 的介紹亦指出，它使用底層系統的 GPU，在瀏覽器內處理這兩類工作。

關鍵是 WebGPU 並非只供繪圖。WebGL 主要作為圖形 API 普及，而 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、取得 Adapter 及 Device，並處理要求失敗的情況。

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 不存在、沒有可用的 Adapter，或要求失敗時，會回傳 null。若需要額外功能或較高的限制值，應先檢查 Adapter 的 features 與 limits，再指定相應的 requiredFeatures 與 requiredLimits。回傳的 Device 可能已經失效，要求成功並不保證當下或日後均可使用。應監察 device.lost：裝置失效時先停止繪圖迴圈，再重新取得 Adapter 與 Device 並重建資源，或轉用後備顯示。主動呼叫 destroy() 時不應自動重試，復原嘗試亦應設有上限。

GPUAdapter 代表瀏覽器選用的 GPU 實作，以及它提供的功能與限制。它可能對應內置或獨立 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，以及包含目標紋理視圖（TextureView）、格式與管線輸出一致的 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 存在，不代表 Adapter、Device 要求或應用程式初始化必定成功。初始化失敗或裝置失效時，也須有後備路徑。同一 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 的方式延伸至現代圖形與運算模型。面對大量繪圖或運算需求，應把它的能力、實作成本、維護能力及支援環境一併評估。