簡體   English   中英

在 Vulkan 中,將圖形隊列家族與當前隊列家族分開是否有益?

[英]In Vulkan, is it beneficial for the graphics queue family to be separate from the present queue family?

據我所知,隊列系列可能支持在屏幕上顯示但不支持圖形。 假設我有一個支持圖形和呈現的隊列族,以及另一個僅支持呈現的隊列族。 我應該將第一個隊列系列用於兩個進程,還是應該將第一個隊列系列委托給圖形,而將后者委托給呈現? 或者這兩種方法之間沒有明顯的區別?

不存在這樣的硬件,所以最好的方法是沒有方法。 如果你想變得非常好,你可以用最少的腦力來處理單獨的當前隊列家庭案例。 盡管您無法在需要它的真實硬件上對其進行測試。 因此,我會說帶有很好的錯誤消息的中止就足夠了,直到您可以掌握執行此操作的實際硬件。

我認為 Khronoses 部分存在一些設計錯誤。 單獨的當前隊列看起來確實是一種更明確的方式。 但是,present op 本身並不是隊列操作,因此驅動程序無論如何都可以使用它想要的任何東西。 此外,單獨存在需要額外的信號量和隊列家族所有權轉移(或VK_SHARING_MODE_CONCURRENT資源)。 歷史上沒有司機如此極端地報告單獨的當前隊列。 所以我制作了KhronosGroup/Vulkan-Docs#1234

對於在vkQueuePresentKHR發生的情況的粗略概念,您可以檢查 Mesa 代碼: https://github.com/mesa3d/mesa/blob/bf3c9d27706dc2362b81aad12eec1f7e48e53ddd/src/vulkan/wsi/wsi_common . 使用您提供的隊列可能沒有猴子業務,除了等待您的信號量,或者最多制作一個圖像。 如果您(自願)想使用單獨的當前隊列,則需要僅針對驅動程序(可能還有其他影響)對其進行測量並將其列入白名單,它實際上有幫助(如果存在任何此類,並且甚至值得您花時間)。

首先,我假設您的意思是在性能方面“有益”,每當涉及到此類問題時,除非通過分析不同的策略,否則您永遠無法得到明確的答案。 如果您的應用程序需要在各種硬件上運行,您可以讓它在第一次運行時分析不同的策略並將結果保存在本地以供重復使用,為用戶提供基准測試實用程序,如果他們發現性能不佳,他們可以運行,等等等等。試圖在摘要中推理它只能讓你到目前為止。

除此之外,我認為思考此類問題的最簡單方法是記住,當涉及到圖形編程時,您既希望最大化可以並行完成的工作量,又希望最小化整體工作量。 如果您想呈現來自非圖形隊列的圖像並且需要對其執行圖形操作,則需要在對它的圖形操作完成后將其所有權轉移到非圖形隊列。 據推測,如果不出意外,這將花費一些時間在驅動程序中,因此只有在以某種方式節省您在其他地方的時間時才值得這樣做。

如果設備支持異步計算並且還允許您從計算隊列中呈現,這可能會節省您的時間的常見情況。 例如,3D 游戲可能會將計算隊列用於諸如照明、模糊、UI 等在幾何處理完成后最有意義的事情。 在這種情況下,游戲引擎無論如何都會首先將要呈現的圖像的所有權轉移到計算隊列,或者甚至讓計算隊列從頭到尾擁有交換鏈圖像,因此一旦它為幀工作,就從計算隊列中呈現完成將允許圖形隊列忙於下一幀。 AMDNVIDIA盡可能推薦這種方法。

但是,如果您的應用程序不會以其他方式使用計算隊列,那么我不確定在您有選擇權時是否顯示它有多大意義。 這種方法的優點是,一旦給定幀的圖形操作結束,您可以讓圖形隊列立即釋放它的圖像所有權並獲取下一個,而無需暫停來呈現它,這將允許呈現與渲染下一幀並行完成。 另一方面,您必須首先將其所有權轉移到計算隊列並在那里設置演示,這會增加一些復雜性和開銷。 我不確定哪種方法會更快,如果它隨應用程序和環境而變化,我也不會感到驚訝。 當然,我不確定今天有多少具有顯着復雜性的實時 Vulkan 應用程序適合這種情況,而且我猜它不是很多,因為使用計算着色器更容易和更快地完成“每像素”的事情.

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM