OpenGL定义了数百个以gl开头的函数(可称之为glAPI)，供应用程序调用；OpenGL也规定了从glAPI到on screen buffer中数据的转换过程，即OpenGL的Pipeline。Pipeline直译的中文意思是管道，可以理解为将三维空间中表达的数据（比如三维物体、灯光配备等）经由这个管道转换为二维屏幕上的画面。如上图所示。
OpenGL Pipeline中是有状态的，被称为OpenGL state或者GL state。举例来理解，假如将OpenGL Pipeline这个模块的输入抽象为X，输出抽象为Y，其转换过程被抽象为Y=AX+B，那么，系数A和B就是其状态。。改变状态的glAPI修改A和B的值，描述空间物体数据的glAPI设置X，当绘制glAPI被调用时，OpenGL Pipeline即计算得到Y输出。
正是从这个意义上，OpenGL被称为是一个状态机state machine。
实际上，我们应该将Pipeline理解为一个由众多相互联系的子模块组成的模块。本文的主要内容也就是依次介绍这些子模块。
至此，可能会出现一个疑问，OpenGL Pipeline在物理上到底是个什么存在。概念性的回答是，只要符合GL spec定义的功能，就是OpenGL Pipeline。
假如用纯软件的方式来完成这个模块功能，那么此时的OpenGL Pipeline就是这个软件，比如MESA，此时不需要显卡的3D功能。
OpenGL Pipeline的另外一种可能性是软硬件混合体，硬件部分就是3D显卡上的显示芯片（英文简称为GPU或者VPU），软件部分属于显卡的OpenGL驱动程序。驱动程序根据被调用的glAPI生成GPU能够执行的指令，并将这些指令交给GPU执行。如果GPU的能力强一点，驱动所做的事情就少一点；如果GPU的能力弱一些，那驱动要做的事情就会相应的多一些。
又一个问题随即而来，GPU只有一个，在同时运行多个OpenGL应用程序时，OpenGL Pipeline是如何处理的？这归功于驱动程序。
驱动程序中保存着所有的GL state，驱动程序也负责管理多个GL state在一个GPU上的执行切换的任务。不同GL state对GPU的访问是互斥的，多个GL state分时占用GPU。当某个GL state占用GPU时，就构成了一个OpenGL Pipeline。当占用GPU的GL state发生切换时，驱动程序会确保GPU中的诸如硬件寄存器等状态值都被重新设置。
用CPU作个简单类比，驱动程序相当于操作系统，GL state相当于进程，即操作系统对多个进程在一个CPU上的执行切换的功能，即进程管理。
GPU上的切换对应用程序是透明的，应用程序可以认为它就是独占GPU的，就好像我们在编写一般的CPU程序时，不需要考虑CPU上的进程切换，逻辑上按独占CPU来思维。我们用GL context来表示这样的一个概念，如下图。
本质上，GL context和GL state并无多大差别，GL context是从应用程序的角度来考虑问题，而GL state则是从OpenGL内部来考虑问题。在研究OpenGL spec时，并不考虑多进程多线程的情况，所以，在不引起误解的情况下，OpenGL Pipeline、GL context和GL state是被混用的。