1.引言
Vulkan規範已經釋出，本文将和你分享為什麼Vulkan是一個牛逼的圖形API， 它和OpenGL有何差別。Nvidia認為， Vulkan将是OpenGL 很好的補充，兩個API都各有優勢。
Vulkan的優勢在于它能夠更好的多線程處理和GPU底層控制能力，并能減少CPU消耗。而OpenGL，繼續提供簡單的硬體通路接口，這對那些CPU消耗不大應用程式來說是很友善的。 目前Nvidia 針對OpenGL的技術像“bindless”, NV_command_list, 和“ADZ0”， 都能夠實作較好的單線程性能。
為使下面介紹更加容易讀懂，我們省略掉其中的一些細節。
2.指令送出
在這篇文章中，我們看下繪制一幀需要哪些API
OpenGL API 的狀态和繪制指令通常是立即發給GPU的， 而Vulkan API會累計這些API延遲發送；CommandBuffe 存儲設定渲染狀态的指令，然後送出給 Queue 去執行。
CommandBuffer 内部的操作過程看起來不應該陌生。 一個 RenderPass 和 FBO 綁定是相似的， 一個 DescriptorSet 處理 uniform bindings (buffer, texture...)， 後面有詳細介紹。
- Device：Device 用來查詢資訊，建立大部分Vulkan API 對象。
- Queue：一個Device 可以暴露多個隊列，例如， 專門的進行拷貝資料的隊列，通用計算的隊列，繪圖的隊列。單獨的隊列裡面的操作是按序進行；但有多個對列時，多個隊列的操作并行進行。
- CommandBuffer：通過CommandBuffer， 我們紀錄了指令像設定狀态，從頂點緩沖取資料繪制，分發計算網絡，buffer之間的資料拷貝. 然而編譯這些指令仍然需要一定代價,不過送出這些指令到指令隊列是很快的.
3. Command Buffer 用法 我們能夠并行的建立和送出多個CommandBuffers, 并重用它們. 重用在下面這些情況下尤其有用:傳統CPU負擔比較重, 建構多個陰影圖,或者為虛拟現實眼睛生成左右圖,或者送出多個複雜的對象, 或者幾幀低CPU消耗的場景. Vulkan 驅動并不需要推算它們的用法, 因為開發者需要預建立各個對象資訊. 下圖展示的了primary commandbuffer 和 second commandbuffer 用法差別
- Primary CommandBuffer 總是處理RenderPass 狀态設定. 其他的渲染操作可以直接記錄或者被Secondary CommandBuffer記錄.
- Second CommandBuffer 可以對Commands的子集進行編碼.
就核心 Vulkan來說, CommandBuffers 之間不存在繼承關系. 僅存的繼承關系是, Secondary CommandBuffer 會使用Primary CommandBuffer的images.
4. 通用對象
是什麼讓CommandBuffer 編碼那麼快呢? 最關鍵的一方面是CommandBuffers引用更多的預先驗證好的對象,是以,它克服了一些OpenGL存在的缺點. 盡管OpenGL 的 multi-draw-indirect buffers 也是重用對象完全并行處理的,但是它不允許狀态改變.我們更遠一點想,顯示清單允許多個狀态改變,但結果僅僅是部分子集内容是運作快的. 顯示清單也存儲了不可改變資料, 而現代方法采用的是引用資料.這意味着CommandBuffer 驅動的内容仍然可以動畫, 像參考的資料矩陣和頂點資料可以獨立改變.
下圖展示了各種指令中用到的各種對象
- Image: 類似OpenGL Texture.
- FrameBuffer: 可被渲染的一組Image,. 它必須同RenderPass 配套使用.
- RenderPass: