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是被混用的。