glMapBuffer返回的一定是顯存的地址嗎？

1 glGenBuffer產生的vbo是否必然分配的是顯存，為什麼

2 在一個圖形引擎群里看到一個人說glMapBuffer返回的不一定是顯存空間的地址

3 gles2.0 不能創建debugContext,如何準確的輸出錯誤信息？

---

1.不一定

glGenBuffer並不申請內存 它的作用只是在服務端申請了一個handle而已

申請內存需要使用glBufferData

glBufferData的最後一個參數會影響內存到底從哪裡申請

當然這個僅僅是hint而已

這個hint是給做opengl implementation的人看的

所以你能做的僅僅是去選用最合理的參數

而不是去糾結到底是在顯存上還是在別的地方(關鍵所謂的顯存可能種類還非常多 也許有亂七八糟的各種高速緩存用來優化不同用途的Buffer)

2.不一定

理由基本和上面一樣

完全看實際的opengl implementation

一般來說做實現的人 只要硬體條件允許

當然會直接做內存映射 而不是去拷貝 他們又不傻

除非真的是你這個平台的硬體上無法實現直接映射

或者你這個操作系統上無法實現

或者為了優化性能 有些Buffer可能是從某些特殊的高速緩存中申請的空間 這種緩存可能讀寫的時機和條件都非常苛刻 做不了映射

那也沒辦法

我只能說

極端情況下glMapBuffer可能會出現非常差的效率（多半是沒正確使用）

開發者能做的就是正確使用而已

什麼叫正確使用？

我就舉一個反例:

Map也有hint參數

如果你對一個STATIC_READ的Buffer去用WRITE_ONLY or READ_WRITE的方式Map 肯定是不合適的 也許這個Buffer申請的地方就是一塊 對客戶端來說讀得快但是寫的慢（甚至客戶端無法寫 或者寫入的條件和時機都有嚴格限制的內存）的地方的內存

你要去強行去Map 有可能就得到很差的性能 甚至是失敗

---

1.基本就是不會，目前的驅動都是惰性的，不可能你gen一下就把資源分配給你，都是到你什麼時候用了什麼時候給你。除非你的驅動設計的很奇怪。

2.當然不一定是顯存，或者說很大可能不是顯存。具體你可以私信我，我給你看資料。

---

1：基本不是。

按照OpenGL的spec，GL各種對象基本都在第一次bind一個空ID的時候才真正生成。GenXXX函數只是給你一個未被使用的ID。

2：通常不是顯存。

它很可能是宿主端傳說中的「pinned memory」，一塊能與GPU高速交互的內存區域。我估計只有在AMD APU的某些情況下，才會真的直接給你顯存地址。

3：我Debug OpenGL的時候，第一靠男人的直覺，第二靠各種調試器（比如AMD的GDebugger及其後繼者）觀察device端對象內容，第三靠渲染數據到圖像然後肉眼看。從沒用過debug context。。。

---

推薦閱讀：