Vulkan 設計指南

與早期圖形 API 不同,Vulkan 的驅動程式不會為應用程式執行特定最佳化作業,例如重複使用管道。相反地,使用 Vulkan 的應用程式必須自行實作這類最佳化作業。否則,相較於執行 OpenGL ES 的應用程式,這些應用程式的效能可能較差。

應用程式在自行實作這些最佳化作業時,由於可存取特定使用情境更詳細的資訊,因此可能比驅動程式表現更佳。因此,如果能有技巧性地將使用 Vulkan 的應用程式進行最佳化,應用程式的效能就會比起在 OpenGL ES 上執行更佳。

本頁面會介紹 Android 應用程式可於 Vulkan 實作的幾種最佳化方式,有助於提升應用程式效能。

硬體加速

大多數裝置都透過硬體加速支援 Vulkan 1.1,而少部分的裝置則透過軟體模擬支援。應用程式可以透過 vkGetPhysicalDeviceProperties 和檢查所傳回結構的 deviceType 欄位,偵測出軟體型態的 Vulkan 裝置。SwiftShader 和其他以 CPU 為基礎的實作會包含 VK_PHYSICAL_DEVICE_TYPE_CPU 值。透過檢查這個相同結構的 vendorIDdeviceID 欄位是否包含 SwiftShader 專屬值,應用程式就能特別針對 SwiftShader 進行檢查。

著重效能的應用程式應避免使用軟體模擬的 Vulkan 實作,而應改用 OpenGL ES。

在算繪時套用畫面旋轉設定

當應用程式的向上方向與裝置螢幕方向不一致時,合成器會旋轉應用程式的交換鏈圖片,讓兩者方向一致。合成器會在顯示圖片時旋轉圖片方向,這會導致耗電量增加,有時耗電量甚至比不旋轉圖片時還高出許多。

相較之下,如果在產生交換鏈圖片時就旋轉圖片方向,則即使有額外耗電量,增幅也十分有限。VkSurfaceCapabilitiesKHR::currentTransform 欄位顯示合成器套用至視窗的旋轉效果。應用程式在算繪期間套用該旋轉效果後,會透過 VkSwapchainCreateInfoKHR::preTransform 欄位回報已完成旋轉。

最大程度減少每個影格的算繪通道

在大部分的行動 GPU 架構中,開始和結束算繪通道是一項耗時且耗費資源的作業。透過將算繪作業控制在盡可能少的算繪通道中,就能提升您的應用程式效能。

不同的附件載入和附件儲存操作會有不同等級的效能。例如,如果您不需要保存附件內容,可以使用更快的 VK_ATTACHMENT_LOAD_OP_CLEARVK_ATTACHMENT_LOAD_OP_DONT_CARE,而不是 VK_ATTACHMENT_LOAD_OP_LOAD。同樣地,如果您不需要將附件的最終值寫入記憶體以供日後使用,則可以使用 VK_ATTACHMENT_STORE_OP_DONT_CARE,就能獲得比 VK_ATTACHMENT_STORE_OP_STORE 更佳的效能。

此外,在大部分算繪通道中,應用程式不需要載入或儲存深度/模板附件。在這些情況下,您可以在建立附件圖片時使用 VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT 旗標,就不需為附件分配實體記憶體。這個位元提供與 OpenGL ES 中的 glFramebufferDiscard 相同的優點。

選擇合適的記憶體類型

分配裝置記憶體時,應用程式必須選擇記憶體類型。記憶體類型決定應用程式可以如何使用記憶體,同時也會說明記憶體的快取和一致性屬性。不同裝置可使用的記憶體類型皆不同;不同記憶體類型展現的效能特性也不相同。

應用程式可透過簡單的演算法,針對特定用途選擇最合適的記憶體類型。這個演算法會從 VkPhysicalDeviceMemoryProperties::memoryTypes 陣列中選取符合以下兩個條件的第一個記憶體類型:緩衝區或圖片必須適用這個記憶體類型,而且這個記憶體類型必須至少具備應用程式所需的屬性。

行動系統通常不會有 CPU 和 GPU 各自獨立的實體記憶體堆積。比起具有獨立 GPU (擁有獨立專屬記憶體) 的系統,對於這類系統而言,VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT 的重要性沒有那麼大。應用程式不應假設這類屬性為必要屬性。

依頻率為描述元集分組

如果您的資源繫結會在不同頻率下變更,請針對每個管道使用多個描述元集,而不是在每次繪圖時重新繫結所有資源。例如,您可以為按情境的繫結建立一組描述元集,為按材料的繫結建立另一組描述元集,以及為按網格執行個體的繫結建立第三組描述元集。

為頻率最高的變更 (例如每次繪製呼叫時所執行的變更) 使用立即常數。