學廢了系列 - WebGL與Node.js中的Buffer

WebGL 和 Node.js 中都有 Buffer 的使用，簡單對比記錄一下兩個完全不相幹的領域中 Buffer 異同，加強記憶。

Buffer 是用來存儲二進制資料的「緩沖區」，其本身的定義和用途在任何技術領域都是一緻的，跟 WebGL 和 Node.js 沒有直接關系，兩者唯一的共同點就是都使用 JavaScript。

在 ES6 将

TypedArray

（二進制類型數組）正式加入 ECMA 标準之前，JavaScript 語言本身并沒有标準的處理二進制資料的能力，Buffer 就是為了彌補這一缺陷。

TypedArray

成為 ECMA 标準之前就已經在 WebGL 領域廣泛使用了。

Node.js 加入 Buffer 的作用主要是為了處理 stream，比如網絡流、檔案流等等。Buffer 占用預申請的一整片記憶體，stream 被消費的速度如果低于接收速度，就會被暫存在緩沖區内，然後被消費者從緩存區依序取出消費。

Node.js 中的 Buffer 是

Uint8Array

的子類，

Uint8Array

是ECMA 标準中

TypedArray

中的一種資料類型。

console.log(Buffer.__proto__) 
// 列印 [Function: Uint8Array] 
           

其實 Node.js 中的 Buffer 與 ECMA 标準的

TypedArray

并沒有直接關系，Node.js 很早期的版本（v0.10.0）版本就支援了 Buffer。

Uint8Array

，或者說 ECMA 标準中所有的

TypedArray

都是 JavaScript 引擎提供的一種 API，早期未被加入 ECMA 标準的時候就已經有不少引擎實作了這些 API，而最早使用二進制類型數組的場景就是 WebGL。

話說回來，ECMA 标準做的不就是“集百家之長”（修辭手法-反諷）的事嗎哈哈😂

然後說到 WebGL 中的 Buffer。

WebGL 有兩種 Buffer 類型：

• ARRAY_BUFFER

  ：頂點屬性資料的 Buffer，用來傳遞任何跟頂點相關的資料，比如坐标、顔色等等。這些資料一般是浮點數，最常用的類型是

  Float32Array

  ；

• ELEMENT_ARRAY_BUFFER

  ：元素索引資料的 Buffer，用來傳遞讀取

  ARRAY_BUFFER

  元素的順序。每個元素必須是整數，使用

  Uint8Array

  ，這一點跟 Node.js 中的 Buffer 一緻。此 buffer 是可選項，如果不使用的話 ，

  ARRAY_BUFFER

  的元素會被按照 index 依序讀取。

雖然 WebGL 中沒有 stream 的概念（嚴格來說是從開發者的認知層面沒有 stream，底層 OpenGL 處理 buffer 資料的流程中是有 stream 的），但 Buffer 的作用跟 Node.js 是一緻的，都是将資料暫存在一整片預申請的記憶體中，供後續程序邏輯消費，差別是消費者不同。

在WebGL渲染管線中，但從CPU到GPU完整的資料傳輸鍊路中，有以下幾種buffer：

• VBO，Vertex Buffer Object，頂點緩沖對象儲存頂點屬性資料，消費者是 shader，嚴格的說是 vertex shader；
• FBO，Fragment Buffer Object，幀緩沖對象可以簡單了解為一個指針集合體，附着 RBO、顔色、紋理等用于渲染的所有資訊；
• RBO，Rendering Buffer Object，渲染緩沖對象儲存 depth（深度）、stencil（模闆）值。

FBO 與 RBO、紋理的關系如下圖：

另外一點需要了解的是 buffer 對象從 CPU 流轉到 GPU 的過程，這個過程涉及到總線通訊，雖然這些跟 Node.js 沒有一毛錢關系，但是其中的一些實作跟 Node.js 常見八股文面試題「跨程序通信」有一些相同的理念。

WebGL中buffer最初被建立和寄存在CPU記憶體中，如何讓GPU通路CPU記憶體呢？回答這個問題之前先介紹幾個基本概念：

• CPU 的記憶體一般稱為 main memory
• GPU 自己的儲存稱為 local memory

在 WebGL/OpenGL 中，頂點資料被建立被寄存在 main memory 中，GPU 需要得到這部分資料進行渲染，但是 main memory 和 local memory 是絕對隔離的，不能互相通路。

對于內建顯示卡來說，GPU 和 CPU 共享總線，GPU 沒有自己獨立的儲存空間，一般是從 CPU 儲存中配置設定出一塊空間給 GPU 使用，我們把這部分空間姑且叫做顯存（嚴格來說內建顯示卡沒有顯存的概念）。為了實作 GPU 和 CPU 資料的共享，業内引入了一種叫做 GART（Graphic Address Remapping Table）的技術，GART簡單說就是一個映射 main memory 和 local memory 位址的表。內建顯示卡的顯存一般很小，必然是小于記憶體的（一般預設上限是記憶體總量的1/4），OS 将整個 local memory 空間映射到 main memory，維護一個 GART。此時 buffer 資料的流轉如下圖所示：

但是這套流程在獨立顯示卡中是行不通的，因為獨立顯示卡的顯存非常大，如果使用 GART 将顯存空間完全映射到 CPU 記憶體中會占用非常大的記憶體空間，32位系統的整個記憶體空間也就僅僅4GB，如果分出 2GB 給顯存映射，那就别幹啥了。

這下明白為啥64位系統玩遊戲更爽了吧~

是以對于獨立顯示卡需要另外一套 CPU 與 GPU 的資料共享機制。目前比較普遍的方式是在記憶體中單獨劃出一塊實體空間用于 CPU 和 GPU 之間的資料交換中轉，這部分記憶體空間叫做 pinned memory（鎖定記憶體）。buffer 資料首先會被從 main memory 中拷貝到 pinned memory 中，然後通過 DMA（Direct Memory Access，直接記憶體通路）機制将資料傳輸到 GPU，整個過程如下：

請注意， pinned memory 是一塊實體記憶體而不是虛拟記憶體，這樣能夠保證DMA的傳輸性能。

這下明白為啥打遊戲一定要加大記憶體了吧~

獨立顯示卡的這套資料交換機制跟 Node.js 八股文「跨程序通信」的共享記憶體理念很接近，不過複雜度更高一些。

上面這些内容大都是 OpenGL 和計算機底層的機制，對 WebGL 開發者來說是無感覺的，具體到涉及 Buffer 的代碼層面， WebGL 需要比 Node.js 更謹慎的處理 Buffer 的記憶體管理。

Node.js 中 Buffer 在配置設定記憶體時采用了 slab 預先申請、事後配置設定機制，這是在底層C++的邏輯，開發者不可控。這套機制能夠提高 Node.js 需要頻繁申請 buffer 記憶體場景下的性能表現。而 WebGL 中并沒有這套機制，需要開發者自行處理。一般的做法是預申請一個容量很大的 buffer，然後使用

gl.bufferSubData

（類似Node.js 的

Buffer.fill

）局部更新資料，這樣能避免頻繁申請記憶體空間造成的性能損耗。

以上。