目錄
- 1. WebGL
- 1.1. 使用 WebGLProgram 表示一個計算程序
- 1.2. WebGL 沒有通道 API
- 2. WebGPU
- 2.1. 使用 Pipeline 組裝管線中各個階段
- 2.2. 使用 PassEncoder 調度管線內的行為
- 2.3. 使用 CommandEncoder 編碼多個通道
- 2.4. PassEncoder 和 Pipeline 的關系
- 3. 總結
前兩篇文章介紹了 WebGL 和 WebGPU 是如何準備頂點和數字型 Uniform 資料的（紋理留到下一篇），當渲染所需的原材料準備完成后，就要進入邏輯組裝的程序，
WebGL 在這方面通過指定“WebGLProgram”，最終觸發“drawArrays”或“drawElements”來啟動渲染/計算，全域狀態為特征的 WebGL 顯然做多步驟渲染來說會麻煩一些，WebGPU 改善了渲染計算程序的介面設計，允許開發者組裝更復雜的渲染、計算流程，
以所有的“draw”函式呼叫為分界線，呼叫后，就認為 CPU 端的任務已經完成，開始移交準備好的渲染、計算原材料（資料與著色器程式）至 GPU，進而運行起渲染管線，直至輸出到幀緩沖/Canvas，我稱 draw 這個行為是“一個通道”，
WebGPU 的出現，除了渲染的功能，還出現了通用計算功能，draw 也有了兄弟概念：dispatch（調度），下文會對比介紹，
1. WebGL
1.1. 使用 WebGLProgram 表示一個計算程序
WebGL 的整個渲染管線（雖然沒有管線 API）中，能介入編程的就兩處：頂點著色階段 和片元著色階段，分別使用頂點著色器和片元著色器完成渲染程序的定制，
很多書或入門教程都會說，頂點著色器和片元著色器是成對出現的，而能管理這兩個著色器的上層容器物件，就叫做程式物件（介面 WebGLProgram），
const vertexShader = gl.createShader(gl.VERTEX_SHADER) // WebGLShader
gl.shaderSource(vertexShader, vertexShaderSource)
gl.compileShader(vertexShader)
const fragmentShader = gl.createShader(gl.FRAGMENT_SHADER) // WebGLShader
gl.shaderSource(fragmentShader, fragmentShaderSource)
gl.compileShader(fragmentShader)
const program = gl.createProgram() // WebGLProgram
gl.attachShader(program, vertexShader)
gl.attachShader(program, fragmentShader)
gl.linkProgram(program)
其實，真正的渲染管線是有很多步驟的，頂點著色和片元著色只是比較有代表性：
- 頂點著色器大多數時候負責取色、圖形變換
- 片元著色大多數時候負責計算并輸出螢屏空間的片元顏色
既然 WebGL 只能定制這兩個階段，又因為這倆 WebGLShader 是被程式物件（WebGLProgram）管理的，所以，一個程式物件所代表的那個“管線”，通常用于執行一個通道的計算，
在復雜的 Web 三維開發中，一個通道還不足以將想要的一幀畫面渲染完成，這個時候要切換著色器程式，再進行 drawArrays/drawElements，繪制下一個通道，這樣組合多個通道的繪制結果，就能在一個 requestAnimationFrame 中完成想要的渲染，
1.2. WebGL 沒有通道 API
上文提及，在一幀的渲染程序中，有可能需要多個通道共同完成渲染，最后一次 gl.drawXXX 的呼叫會使用一個繪制到目標幀緩沖的 WebGLProgram，這么說可能很抽象，不妨考慮這樣一幀的渲染程序：
- 渲染法線、漫反射資訊到 FBO1 中；
- 渲染光照資訊到 FBO2 中；
- 使用 FBO1 和 FBO2，把最后結果渲染到 Canvas 上，
每一步都需要自己的 WebGLProgram，而且每一步都要全域切換各種 Buffer、Texture、Uniform 的系結，這樣就需要一個封裝物件來完成這些狀態的切換，可惜的是 WebGL 并沒有這種物件，大多數時候是第三方庫使用類似的類完成的，
因此，如果你不用第三方庫（ThreeJS等），那么你就要考慮設計自己的通道類來管理通道了，
當然，隨著現代 GPU 的特性挖掘，一個通道不一定是為了繪制一張“畫”，因為有通用計算技術的出現，所以我更樂意稱一個通道為“一個計算集合，由一系列計算程序有邏輯地構成”，在 WebGPU 也就是下面要介紹的內容中會提及計算通道，那個就是為通用計算準備的，
2. WebGPU
2.1. 使用 Pipeline 組裝管線中各個階段
在 WebGPU 中，一個計算程序的任務就交由“管線”完成，也就是我們在各種資料里見得到的“可編程管線”的具象化 API；在 WebGPU 中，可編程管線有兩類：
- 渲染管線，
GPURenderPipeline - 計算管線，
GPUComputePipeline
管線物件在創建時，會傳遞一個引數物件，用不同的狀態屬性配置不同的管線階段，
回顧，WebGL 是使用
gl.attachShader()方法配置兩個 WebGLShader 附著到程式物件上的，
對渲染管線來說，除了可以配置頂點著色器、片元著色器之外，還允許使用其它的狀態來配置管線中的其它狀態：
- 使用
GPUPrimitiveState物件設定 primitive 狀態，配置圖元的裝配階段和光柵化階段； - 使用
GPUDepthStencilState物件設定 depthStencil 狀態，配置深度、模板測驗以及光柵化階段； - 使用
GPUMultisampleState物件設定 multisample 狀態，配置光柵化階段中的多重采樣，
具體內容需要參考 WebGPU 標準的檔案，下面舉個例子：
const renderPipeline = device.createRenderPipeline({
// --- 布局 ---
layout: pipelineLayout,
// --- 五大狀態用于配置渲染管線的各個階段
vertex: {
module: device.createShaderModule({ /* 頂點著色器引數 */ }),
// ...
},
fragment: {
module: device.createShaderModule({ /* 片元著色器引數 */ }),
// ...
},
primitive: { /* 設定圖元狀態 */ },
depthStencil: { /* 設定深度模板狀態 */ },
multisample: { /* 設定多重采樣狀態 */ }
})
然后再看一個異步創建計算管線的例子：
const computePipeline = await device.createComputePipelineAsync({
// --- 布局 ---
layout: pipelineLayout,
// --- 計算管線只需配置計算狀態 ---
compute: {
module: device.createShaderModule({ /* 計算著色器引數 */ }),
// ...
}
})
讀者可自行比對 WebGL 中 WebGLProgram + WebGLShader 的組合，
題外話，我在我的另一文還提到過，管線還具備了 WebGL 中的 VAO 的作用，感興趣的可以找找看看，管線的片元狀態還承擔了 MRT 的資訊，
2.2. 使用 PassEncoder 調度管線內的行為
由上一小節可知，管線物件收集了對應管線各個階段所需的引數，這說明了管線是一個具備行為的程序，
光有武林秘籍，沒有人練，武功是體現不出來的，
所以，PassEncoder（通道編碼器）就起了這么一個作用，它負責記錄 GPU 計算一個通道的前后邏輯，可以對其設定管線、頂點相關的緩沖物件、資源系結組，最后觸發計算，
計算通道編碼器（GPUComputePassEncoder）的觸發動作是呼叫 dispatch() 方法，這個方法譯作“調度”；渲染通道編碼器（GPURenderPassEncoder）的觸發動作是它的各個 “draw” 方法，即觸發繪制，
這個時候就體現出面向物件編程的威力了，你可以將一個通道內的行為（即管線）、資料（即資源系結組和各種緩沖物件）分別創建，獨立于通道編碼器之外，這樣，面對不同的通道計算時，就可以按需選用不同的管線和資料，進而甚至可以實作管線或者資源的共用，
通道編碼器這一小節沒有示例代碼，示例代碼在下一小節，
2.3. 使用 CommandEncoder 編碼多個通道
WebGPU 使用現代圖形 API 的思想，將所有 GPU 該做的操作、需要資訊事先編碼至一個叫“CommandBuffer（指令緩沖）”的容器上，最后統一由 CPU 提交至 GPU，GPU 拿到就吭哧吭哧執行，
編碼指令緩沖的物件叫做 GPUCommandEncoder，即指令編碼器，它最大的作用就是創建兩種通道編碼器（commandEncoder.begin[Render/Compute]Pass()），以及發出提交動作（commandEncoder.finish()），最終生成這一幀所需的所有指令，
話不多說，這里直接借用 austin-eng 的例子 ShadowMapping（陰影映射）
// 創建指令編碼器
const commandEncoder = device.createCommandEncoder()
{
// 陰影通道的編碼程序
const shadowPass = commandEncoder.beginRenderPass(shadowPassDescriptor)
// 使用陰影渲染管線
shadowPass.setPipeline(shadowPipeline)
shadowPass.setBindGroup(0, sceneBindGroupForShadow)
shadowPass.setBindGroup(1, modelBindGroup)
shadowPass.setVertexBuffer(0, vertexBuffer)
shadowPass.setIndexBuffer(indexBuffer, 'uint16')
shadowPass.drawIndexed(indexCount)
shadowPass.endPass()
}
{
// 渲染通道常規操作
const renderPass = commandEncoder.beginRenderPass(renderPassDescriptor);
// 使用常規渲染管線
renderPass.setPipeline(pipeline)
renderPass.setBindGroup(0, sceneBindGroupForRender)
renderPass.setBindGroup(1, modelBindGroup)
renderPass.setVertexBuffer(0, vertexBuffer)
renderPass.setIndexBuffer(indexBuffer, 'uint16')
renderPass.drawIndexed(indexCount)
renderPass.endPass()
}
device.queue.submit([commandEncoder.finish()]);
為了完成三維物體的陰影渲染，在陰影映射有關的技術中一般會把陰影資訊使用一個通道先繪制出來，然后把陰影資訊傳給下一個通道進而完成陰影的效果，
在上面的代碼中，就使用了兩個 RenderPassEncoder 進行陰影的先后步驟渲染，它們在 draw 之前就可以設定不同的渲染材料，包括代表行為的管線，以及代表資源的系結組、各類緩沖等，
2.4. PassEncoder 和 Pipeline 的關系
WebGPU 中的 Pipeline 被劃分成了多個階段，其中有三個階段是可編程的，其它的階段是可配置的，管線由于在三個可編程階段擁有了著色器模塊，所以管線物件更多的是扮演一個“執行者”，它代表的是某個單一計算程序的全部行為，而且是發生在 GPU 上，
而對于 PassEncoder，也就是通道編碼器，它擁有一系列 setXXX 方法，它的角色更多的是“調度者”，
通道編碼器在結束編碼后，整個被編碼的程序就代表了一個 Pass（通道）的計算流程，
3. 總結
多個時間很短的畫面，就構成了動態的渲染結果，這每一個畫面，叫做幀，而每一幀，在實時渲染技術中用多個“通道”，通過圖形學或實時渲染知識有邏輯地組裝在一起共同完成，
通道由行為和資料構成，
行為由著色器程式實作，也就是“你想在這一個通道做什么計算”，在 WebGL 中使用 WebGLProgram 附著兩個著色器，而在 WebGPU 中使用 GPURenderPipeline/GPUComputePipeline 裝配管線的各個階段狀態，
而資料，則希望讀者去看我寫的 Uniform 和 頂點緩沖文章了，
每一幀，在 WebGL 代碼中，其實就是不斷切換 WebGLProgram，系結不同資料，最后發出 draw 動作完成；在 WebGPU 代碼中，就是創建指令編碼器、開始通道編碼、結束通道編碼、結束指令編碼，最后提交指令緩沖完成，
WebGPU 把 WebGLProgram 與 WebGLShader 的行為職能抽離到 GPU[Render/Compute]Pipeline 和 GPUShaderModule 中去了，這樣就可以在幀運算中獨立出行為物件，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/433357.html
標籤：其他