从应用程序到驱动程序再到Frame buffer，粗略的，可以将memory分成四类：

1. CPU可读可写的，称为system memory。我们一般写的程序使用的memory都是这种类型的，比如OpenGL应用程序，OpenGL驱动程序中的部分memory

2. CPU可写GPU可读的，属于video memory，这种memory在驱动程序中具有重要意义，是驱动程序软件和GPU硬件的桥梁，在驱动开发中，我们一般称之为command buffer。驱动程序往此memory中写入硬件指令或填入数据，GPU从中读取指令并获取数据然后执行。此类型还具有CPU可读的属性，一般来说，GPU不会去写此类型的memory。

3.CPU可读GPU可写的，也属于video memory，在驱动开发中也很重要。GPU将某些执行状态或者反馈数据写入此memory，驱动程序读取就可以了解GPU的状态。一般来说，CPU不会去写此类型的memory，GPU也不会去读此类型的memory。

4. Frame buffer也属于video memory，它是GPU可写的，往往也是GPU可读的，只是如果用CPU直接读取此类型memory的话，会很慢。

以上并不是按照CPU/GPU是否可读写的标准进行分类，只是根据其功能，说明它应该具有的读写属性。很可能在某些地方存在一些例外，所以，无法给出一个严格的标准进行分析分类。

接下去，介绍数据是如何从应用程序被传递到驱动程序到最后能被GPU获取的过程，如下图所示。主要与第一种类型和第二种类型memory相关。

应用程序首先在system memory中准备好数据，然后借助glAPI将数据传递给驱动程序，有两种方法，值传递和指针传递。

驱动程序用如下方法来处理被传入的数据。

1.将传入的数据拷贝到GPU可读的video memory中，拷贝的同时可能进行格式转换。

2.由于video memory总是大小有限的，所以在某些策略下，驱动程序会同时申请system memory和video memory，并将传入的数据写入这两个memory中。以后，假如video memory中的数据被覆盖的话，驱动程序会在需要的时候，将自己维护的system memory中的数据再拷贝到video memory。

3.有时候，即时的将数据写入video memory并不合适，比如，需要根据多个glAPI传入的数据综合计算出新的数据，这个新的数据才是video memory需要的。此时，驱动程序会申请system memory，将传入的数据写入。然后，在时机合适的时候，才写入video memory中。

4.针对指针传递的情况，还存在一种可能性。即，驱动程序只是简单的记录下指针的值以及该指针所指向的数据格式等。然后，在需要的时候，驱动程序根据记录下的指针值，去读取应用程序中的system memory，再按上述第1点或第2点进行处理。记录指针和读取数据是分两步完成的，在两步之间，应用程序也完全有可能改写其system memory中内容，那么，第二步读取的值就是改写后的值.