從應用程序到驅動程序再到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中內容，那麼，第二步讀取的值就是改寫後的值。