玩轉著色器語言

基本上，WebGL不只是個圖形程式庫，開發者必須與GPU進行溝通，使用GLSL撰寫程式，因為這是一種著色器語言（Shader language）。

為什麼要用特定語言來撰寫著色器？撰寫時有哪些要注意的地方？又有哪些輔助工具可以使用呢？

著色器能夠執行快速處理的原因

先前我在專欄〈瀏覽器裡的3D建模師〉談過，WebGL開發者需要使用GLSL撰寫著色器程式，透過JavaScript API編譯並送入GPU」。GPU是專門執行繪圖運算的微處理器，在繪圖速度自然比透過HTML5 Canvas API等來得快速，這結論基本上沒錯，然而，若能進一步理解「專門執行繪圖運算」是指什麼，有助於對著色器語言的掌握。

正如我在〈瀏覽器裡的3D建模師〉提及的，著色器程式包含頂點與片段著色器。頂點著色器在編寫時，對象是針對單頂點的演算，片段著色器在編寫時，對象是單個像素的演算。在頂點著色器中，頂點間無法溝通，不知道前一頂點或下個頂點是哪個，更別說是頂點的狀態；頂點也無法得知上一次的狀態為何；在片段著色器中，基本上也是相同，只是頂點換為像素，一樣地，每次都是獨立運算。

若需要處理的畫布有1024 × 768個像素，每秒60個影格，在交給CPU循序處理每個像素的情況下，CPU每秒須處理47,185,920個像素，現代CPU是有多個核心，開發者也可以特意將程式設計為平行處理，讓多個核心來平均分擔這些任務（然而在瀏覽器上做不到，別忘了，JavaScript是單執行緒模型），實際上，GPU就是這麼做的，透過內部許多的微型處理器，平行地處理每個像素。

這也就是為什麼有些開發者會覺得，著色器在學習或編寫上並不容易。因為著色器為了要能配合GPU平行處理的特性，在設計模型上做出了限制，每個頂點或像素都是「獨立地」處理，彼此並不可見，而且不會記憶狀態，無論圖像再怎麼複雜，每個頂點或像素的演算必須是通用的（也就是抽象的），這樣GPU才可以將著色器運行在各個微型處理器上，每個像素的處理，都是個小型任務。

除了平行處理的特性之外，繪圖處理上經常涉及大量的向量、矩陣運算以及數學函數，著色器語言在向量與矩陣的支援上很友善，特定數學函數還能透過硬體來加速，就程式開發的角度來看，專門執行繪圖運算而獲得繪圖優勢，就是這麼一回事。

著色器的程式碼內容

對於著色器的撰寫，若能知道實際上是在進行平行程式設計的任務，其實很重要，因為這讓開發者知道可以做些什麼，又有哪些事做不到。對於做得到的事，也可以用來判斷哪些演算應該放在著色器中，而哪些可以寫在JavaScript（就WebGL而言）。

要將運算實現在哪邊？這完全取決於開發者，我們可以撰寫簡單的著色器，其他都交給JavaScript來處理，或者是除了HTML頁面處理以外的全部運算，都使用著色器來實現。而這會令人直接聯想到效能，理論上，交由GPU運算會有比較好的效率，在〈Introduction to Shaders〉（https://bit.ly/2HOFkZs）也談到這件事，實際上只有CPU才知道怎麼渲染，GPU還是須與CPU合作，亦有常見的效能瓶頸──來自於溝通上的開銷，而不是運算。

對於初次接觸WebGL的前端開發者而言，建議撰寫簡單的著色器，其他由JavaScript來實現；在逐漸熟悉GLSL之後，並發現JavaScript程式中有些通用向量、矩陣或數學函數運算，再來考慮實現在著色器之中。會有此考量的另一個原因在於，GLSL沒什麼通用的除錯工具，這表示著色器中的邏輯不應過於複雜，往往就是一些數學為主的運算。

另一方面，如果著色器摻雜越多瀏覽器的情境，就可能越局限在某些應用場合。為了讓著色器更通用，我們在著色器當中，應儘量只針對頂點、像素進行處理，避免摻雜瀏覽器情境（例如滑鼠座標轉換），而這些也會是考量之一。

當然，詳細地認識GLSL，對著色器可以寫些什麼絕對是有幫助的，最好是個所視即所得的學習方式，〈The Book of Shaders〉是個線上文件，作者以講解片段著色器的設計為主，並提供一個由glslCanvas程式庫（https://bit.ly/2WoIOGc）建立的環境，即便未搭配頂點著色器，也可以搭建出許多立即可見的驚人效果，對於認識GLSL及著色器而言，是不錯的資源。

著色器開發工具？

就WebGL而言，著色器要撰寫在哪？著色器程式碼會作為字串透過WebGL相關的API送進GPU，基本上，寫在JavaScript字串中也可以，當然，在字串中寫程式碼很麻煩；另一方式是寫在<script type="x-shader></script>之間，type只是個自訂型態，因此只要取得DOM的textContent，就可以取得程式碼；開發者也可以寫在獨立的文字檔中，透過XMLHttpRequest、Fetch API之類取得。

如果使用Visual Studio Code，相對來說，有不少著色器延伸模組。例如，Shader languages support for VS Code可以支援語法醒目提示（若是HLSL還可以有函式自動補完、簡易文件說明等），glsl-canvas以方才提到的glslCanvas為基礎做了改進，可以在片段著色器撰寫時即時預覽，另外，還有Shader Toy等模組，相對來說，在著色器工具的支援是比較熱絡而多樣化的。

開發者可能會想，有除錯器嗎？呃！就結論來說，沒有通用的除錯器！因為平行地執行著色器來處理頂點及像素，導致在CPU上運行除錯器的傳統概念行不通；有種說法是，寫出正確的著色器程式就可以減少除錯的機會（https://bit.ly/2HHJtiD），另一種說法是，在著色器領域沒有太多要除錯的（https://bit.ly/2HTufGo）。

這聽來有點可笑，不過，著色器的確會平行地處理頂點、像素，而這讓人聯想到函數式設計，在這類典範中，著重個別函式的功能簡單而正確，從而組合出正確的程式。雖然著色器程式沒有通用的除錯器，也不能列印值，然而，不少文件都建議，可以輸出不同顏色來代表各種預期狀況，例如，在單元測試個別函式時派上用場，而這也表示，著色器的流程應分解為逐個小任務，才能使用這種方式。

如果真的難以除錯，可試著將任務移至JavaScript實現，利用它的除錯器驗證邏輯是否正確；當然，最後的任務是繪製，麻煩的是沒呈現出預期畫面，特別是在處理動畫，瀏覽器上有些外掛，像是Chrome上有WebGL Insight，可以捕捉、控制影格，並顯示函式的呼叫過程。

著色器導向典範

如果對前端與JavaScript有一定的熟悉度，WebGL在JavaScript API方面沒什麼難處，基本上就是按表操課。對我來說，後來反而是著色器語言這方面吸引了我。因為，一開始只覺得，它有個獨特的風味，後來慢慢玩轉了一段時間，發現真正的價值之一，是在於著色器語言的掌握，例如，以向量、矩陣等的運用來思考運算。

另一個價值在於，雖然GLSL語言本身是基於命令式的C語言，而非函數式風格，然而，獨立、無狀態地處理頂點、像素這方面，還是隱含著函數式、平行處理的典範，而如何設計出一個通用的演算，適用於全部像素，然而又能組合出複雜的圖樣，也是滿新奇的概念，因此，這會是個挑戰，然而也會是樂趣之所在！