你学废了吗？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类型：ARRAYBUFFER：顶点属性数据的Buffer，用来传递任何跟顶点相关的数据，比如坐标、颜色等等。这些数据一般是浮点数，最常用的类型是Float32AELEMENTARRAYBUFFER：元素索引数据的Buffer，用来传递读取ARRAYBUFFER元素的顺序。每个元素必须是整数，使用Uint8Array，这一点跟Node。js中的Buffer一致。此buffer是可选项，如果不使用的话，ARRAYBUFFER的元素会被按照index依序读取。
　　虽然WebGL中没有stream的概念（严格来说是从开发者的认知层面没有stream，底层OpenGL处理buffer数据的流程中是有stream的），但Buffer的作用跟Node。js是一致的，都是将数据暂存在一整片预申请的内存中，供后续进程逻辑消费，区别是消费者不同。
　　在WebGL渲染管线中，但从CPU到GPU完整的数据传输链路中，有以下几种buffer：VBO，VertexBufferObject，顶点缓冲对象储存顶点属性数据，消费者是shader，严格的说是FBO，FragmentBufferObject，帧缓冲对象可以简单理解为一个指针集合体，附着RBO、颜色、纹理等用于渲染的所有信息；RBO，RenderingBufferObject，渲染缓冲对象储存depth（深度）、stencil（模板）值。
　　FBO与RBO、纹理的关系如下图：
　　另外一点需要了解的是buffer对象从CPU流转到GPU的过程，这个过程涉及到总线通讯，虽然这些跟Node。js没有一毛钱关系，但是其中的一些实现跟Node。js常见八股文面试题跨进程通信有一些相同的理念。
　　WebGL中buffer最初被创建和寄存在CPU内存中，如何让GPU访问CPU内存呢？回答这个问题之前先介绍几个基本概念：CPU的内存一般称为mainmemoryGPU自己的储存称为localmemory
　　在WebGLOpenGL中，顶点数据被创建被寄存在mainmemory中，GPU需要得到这部分数据进行渲染，但是mainmemory和localmemory是绝对隔离的，不能互相访问。
　　对于集成显卡来说，GPU和CPU共享总线，GPU没有自己独立的储存空间，一般是从CPU储存中分配出一块空间给GPU使用，我们把这部分空间姑且叫做显存（严格来说集成显卡没有显存的概念）。为了实现GPU和CPU数据的共享，业内引入了一种叫做GART（GraphicAddressRemappingTable）的技术，GART简单说就是一个映射mainmemory和localmemory地址的表。集成显卡的显存一般很小，必然是小于内存的（一般默认上限是内存总量的14），OS将整个localmemory空间映射到mainmemory，维护一个GART。此时buffer数据的流转如下图所示：
　　但是这套流程在独立显卡中是行不通的，因为独立显卡的显存非常大，如果使用GART将显存空间完全映射到CPU内存中会占用非常大的内存空间，32位系统的整个内存空间也就仅仅4GB，如果分出2GB给显存映射，那就别干啥了。
　　这下明白为啥64位系统玩游戏更爽了吧
　　所以对于独立显卡需要另外一套CPU与GPU的数据共享机制。目前比较普遍的方式是在内存中单独划出一块物理空间用于CPU和GPU之间的数据交换中转，这部分内存空间叫做pinnedmemory（锁定内存）。buffer数据首先会被从mainmemory中拷贝到pinnedmemory中，然后通过DMA（DirectMemoryAccess，直接内存访问）机制将数据传输到GPU，整个过程如下：
　　请注意，pinnedmemory是一块物理内存而不是虚拟内存，这样能够保证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）局部更新数据，这样能避免频繁申请内存空间造成的性能损耗。