你学废了吗？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）局部更新数据 ，这样能避免频繁申请内存空间造成的性能损耗。