TW201626218A

TW201626218A - 傳遞ａｐｉ的相依性的技術

Info

Publication number: TW201626218A
Application number: TW104130611A
Authority: TW
Inventors: 傑弗瑞Ａ波茲
Original assignee: 輝達公司
Priority date: 2014-09-16
Filing date: 2015-09-16
Publication date: 2016-07-16
Also published as: DE102015115605A1; US20160077896A1; CN105426259A; US9727392B2; CN105426259B

Abstract

本發明提供傳遞應用程式設計介面API的相依性的技術，其包括識別執行命令之複數個傳遞。對於各組傳遞，其中一個傳遞為目的地傳遞而另一個傳遞為相對於彼此的來源傳遞，一個或多個相依類型之一個或多個相依性在該目的地傳遞與該來源傳遞之該等執行命令之間確定。傳遞物件隨後經建立以用於各已識別之傳遞，其中各傳遞物件均記錄該等對應目的地與來源傳遞之間的該等執行命令和相依性。

Description

傳遞API的相依性的技術

本案係關於傳遞API的相依性的技術。

計算系統已對現代社會的進步做出顯著貢獻，並使用在許多應用中達到具優勢結果。眾多裝置(例如：桌上型個人電腦(Personal computer，PC)、膝上型PC、平板PC、小筆電、智慧型手機、伺服器等)在娛樂、教育、商業、和科學等大多數領域中，於通信及分析資料方面已促進提高生產力並降低成本。計算系統之一個常見態樣為用於建置應用程式、用於應用程式之間通信、及/或用於存取計算系統之硬體資源的應用程式設計介面(Application programming interface，API)，其係為定義獨立於各個實施之功能的一組常式、協定、和工具。

在慣用API中，應用程式連結/附加資源(比如：紋理(texture)和轉列目標(rendertarget))至上下文。該驅動程式追蹤所有這些附件以便理解該等相依性，並依需要***等待其(Wait for it，WFI)、快取無效等等。追蹤這些附件之成本為系統中主要中央處理單元(Central processing unit，CPU)的瓶頸之一。在較近期的API中，有消除資源之連結的需求。在無連結API中，應用程式在物件用法改變時在其上指定「資源變遷」，比如從轉列 (rendering)切換成紋理、從其切換成紋理。此舉提供與較舊API中該等連結(除分離/明確命令外)相同的資訊，而非隱含地與連結之副作用相同的資訊。此種方法儘管拙劣卻作用於同步和快取控制，但是缺少磚式(tiling)資訊等。這對於有時必須施加變遷於數百個物件以指定單一「相依性」的應用程式亦為繁複。工作規範之無序本質相對於工作提交(經由命令緩衝區記錄/播放)更加複雜化慣用的無連結系統。據此，本領域持續地需要改良式無連結API。

本發明技術藉由參照用於針對傳遞API的相依性的技術例示本發明技術之具體實施例的下列說明和所附圖式，可以得到最佳理解。

在一個具體實施例中，該等技術包括識別用於已接收命令的複數個傳遞。該等已接收命令可包含轉列命令以用於由圖形處理單元(Graphics processing unit，GPU)之一個或多個執行引擎執行。對於各組傳遞，其中分別地該組之第一傳遞為目的地傳遞而該組之第二傳遞為來源傳遞，該目的地傳遞與該來源傳遞之該等命令之間的一個或多個相依性經確定。該等已確定之相依性可為一種或多種相依類型，包括執行相依性、快取相依性、磚式相依性等等。隨後建立用於各已識別之傳遞的傳遞物件。各傳遞物件均記錄該等對應目的地與來源傳遞之間的該等命令和相依性。其後，根據該對應傳遞物件提交該等複數個傳遞物件之該等命令以用於執行。

本發明內容係經提供以簡化形式介紹以下在實施方式中進一步說明之概念的選擇。本發明內容不欲識別所主張標的之主要特徵或必要特徵，亦不欲用於限制所主張標的之範疇。

100‧‧‧計算裝置

110‧‧‧中央處理單元

115‧‧‧圖形處理單元

135、140、145、150‧‧‧輸入/輸出裝置

120‧‧‧系統記憶體

125‧‧‧磁碟機

130‧‧‧圖形記憶體

155、155'‧‧‧作業系統

160‧‧‧應用程式及資料

160'‧‧‧應用程式及資料

165‧‧‧晶片組

170‧‧‧北橋

175‧‧‧南橋

210-250‧‧‧步驟

本發明技術之具體實施例在所附圖式之圖示中係藉由範例而非藉由限制例示，其中類似的參考數字係指類似元件，且其中：圖1顯示用於實施本發明技術之具體實施例的示例性計算裝置之區塊圖。

圖2顯示根據本發明技術之具體實施例傳遞應用程式設計介面(API)的相依性的方法之流程圖。

現在將詳細參照本發明技術之具體實施例，其範例在所附圖式中例示。儘管本發明技術將結合這些具體實施例進行說明，但應可理解其不欲將本發明限制在這些具體實施例。反之，本發明係欲涵蓋可包括在如所附諸申請專利範圍所定義本發明之範疇內的替代例、修飾例和相等物。再者，在下列本發明技術之詳細說明中，闡述眾多具體細節以提供對於本發明技術之徹底理解。然而，應可理解可在無需這些具體細節的情況下實施本發明技術。在其他實例中，已習知方法、程序、組件和電路並未經詳細說明，以免不必要地模糊本發明技術之態樣。

後續本發明技術之一些具體實施例係就一台或多台電子裝置內對資料操作之常式、模組、邏輯區塊及其他符號表示的方面而經呈現。該等說明和表示為熟習此項技術者所使用，以向其他熟習此項技術者最有效地傳達其工作之實質的手段。常式、模組、邏輯區塊及/或其類似物於文中且一般係設想為導致所需結果的程序或指令之自相一致序列。該等程序為包括實體量之實體操縱程序。通常，儘管非必要，這些實體操縱具有能在電子裝置中儲存、傳輸、比較及以其他方式操縱的電或磁信號之形式。為方便起見，且參照常見用法，這些信號係指稱為資料、位元、數值、元件、符號、字元、用語、數字、字串及/或參照本發明技術之具體實施例的類似物。

然而，應當記住，所有這些用語均解譯為參考實體操縱和實體量，且僅為便利標記，並鑑於在此領域中普遍使用的用語而進一步解譯。除非如從下列討論顯而易見之其他具體聲明，應可理解透過本發明技術之討論，利用用語例如「接收」及/或其類似物的討論係指稱電子裝置(例如：操縱及轉換資料的電子計算裝置)之動作和程序。該資料表示為在電子裝置的邏輯電路、暫存器、記憶體及/或其類似物內之實體(如電子)量，並轉換成同樣地表示為在電子裝置內之實體量的其他資料。

在本申請案中，使用反意連接詞係欲包括連接詞。使用定冠詞或不定冠詞則不欲指示總量概念(cardinality)。尤其是，參照「該(the)」物件或「一(a)」物件係欲亦意指可複數的此種物件之一者。亦應可理解於文中所使用的措詞和術語係為了說明之目的，而不應被視為限制。

參照圖1，顯示用於實施本發明技術之具體實施例的示例性計算裝置。計算裝置100可為個人電腦、膝上型電腦、平板電腦、智慧型手機、遊戲機、伺服器電腦、用戶端電腦、分散式電腦系統、或其類似物。計算裝置100包括一個或多個中央處理單元(CPU)110、一個或多個專用處理單元(例如：圖形處理單元(GPU)115)、一個或多個計算裝置可讀取媒體120、125、130、以及一個或多個輸入/輸出(I/O)裝置135、140、145、150。 I/O裝置135、140、145、150可包括一網路配接器(如乙太網路卡)、光碟機(CD drive)、數位影音光碟機(DVD drive)及/或其類似物、以及周邊設備(例如：鍵盤、指向裝置、喇叭、印表機及/或其類似物)。

計算裝置可讀取媒體120、125、130可具有主要記憶體和輔助記憶體的特性。一般來說，輔助記憶體(例如；磁性及/或光學儲存體)提供用於供計算裝置100使用的電腦可讀取指令和資料之非揮發性儲存。舉例來說，磁碟機125可儲存作業系統(OS)155和應用程式及資料160。主要記憶體(例如；系統記憶體120及/或圖形記憶體130)提供用於供計算裝置100使用的電腦可讀取指令和資料之揮發性儲存。舉例來說，系統記憶體120可暫時地儲存作業系統155'之一部分和目前由CPU 110、GPU 115等所使用的一個或多個應用程式及相關聯資料160'之一部分。

計算裝置可讀取媒體120、125、130、I/O裝置135、140、145、150、和GPU 115可藉由晶片組165和一個或多個匯流排通信地耦合於處理器110。晶片組165用為在處理器110與計算裝置可讀取媒體120、125、130、I/O裝置135、140、145、150、和GPU 115之間通信資料和指令的簡單輸入/輸出集線器。一個實施例中，晶片組165包括一北橋170和南橋175。北橋170提供用於與處理器110通信和與系統記憶體120交互作用。南橋175提供用於輸入/輸出功能。

在計算裝置100之硬體上運行的軟體之操作之常見態樣為應用程式設計介面(API)。在執行命令期間，存在控制應用程式之適當執行的大量相依性。該API需要提供機制，以傳遞有關用於執行該等命令之該等相依性的資訊。

現在參照圖2，顯示根據本發明技術之具體實施例傳遞應用程式設計介面(API)的相依性的方法。該方法可經實施為儲存在計算裝置可讀取媒體(如電腦記憶體)中並由計算裝置(如處理器)執行的計算裝置可執行指令(如電腦程式)。

在步驟210，該方法開始於接收執行命令。在一個實施例中，該等執行命令包含由一個或多個圖形處理單元及/或中央處理單元之一個或多個執行單元所執行的轉列命令。在步驟220，複數個傳遞係經識別以用於該等已接收執行命令。在步驟230，對於各組傳遞，其中一個傳遞為該目的地傳遞而另一個傳遞為相對於彼此的來源傳遞，一個或多個相依類型之一個或多個相依性在給定目的地傳遞與其各個來源傳遞之間經確定。該等相依類型可包括執行相依性、快取相依性、磚式相依性等等。在步驟240，傳遞物件經建立以用於各已識別之傳遞。該等傳遞物件記錄該對應給定傳遞與其各個來源傳遞之間的執行命令及相依性。該等相依性可由來源遮罩(mask)、目的地遮罩、沖洗(flush)遮罩、無效化(invalidate)遮罩等所指定。在步驟250，根據該對應傳遞物件提交該等傳遞物件的轉列命令以用於執行。

傳遞包括轉列目標之狀態，其包括寫入結果的影像記憶體、以及產生影像內容的轉列命令。該等傳遞之間的相依性在於API如何表達在該等相依性之目的地的傳遞中開始作業前，在該來源相依性中需要完成什麼。

在一個範例中，第一傳遞(來源)可為轉列紋理至其轉列目標，而第二傳遞(目的地)為當其寫入自身轉列目標時，從該來源傳遞之轉列目標之紋理在片段著色器中紋理化。該等相依性因此將會指定該來源傳遞需要在該目的地傳遞開始其片段著色前，完成其所有轉列目標寫入。此外，在一個實施例中，包含於一個或多個沖洗遮罩中的相依性指定若寫回用於該來源傳遞中，則該資料需要沖洗至記憶體。同樣地，在一個實施例中，包含於一個或多個無效遮罩中的相依性指定若一個或多個快取用於該目的地傳遞中的讀取，該快取需要被無效化(invalidated)。

轉列傳遞可在例如1000×1000像素之影像資料上操作。舉例來說，該資料可分成100×100像素之小型磚。在此類情況下，需要在該命令緩衝區中為給定磚群組化該等繪圖命令，以使該資料可局部快取至該處理引擎，以減少或消除對用於各個來源和目的地傳遞之記憶體的讀取及/或寫入。若該相依性之本質為使得該第二傳遞中的各像素均僅依該第一傳遞中的對應像素而定，該等兩個傳遞之間的邊緣被視為磚式邊界而該等兩個傳遞視為可磚式。因此，相關命令可按照各磚次序而發出及執行，且該等傳遞之間的該等相依性指示其為可磚式。

基於上述方法，該相依性資訊可分類為三種概念：執行相依性、快取相依性、和磚式相依性。該等相依性概念均不需要各資源狀態追蹤。該等傳遞物件和相依性可概念化為直接非循環圖。該等傳遞物件和相依性形成部分次序，使得命令之收集必須以有序序列進行。然而在處理其他傳遞之間的相依性時，非相關傳遞可具優勢地繼續執行。

根據本發明技術之具體實施例，轉列傳遞被包裝(encapsulated)在傳遞物件中。傳遞物件在其他傳遞上指定其相依性，而指定相依性之部分係指定在該等相依傳遞上的執行和快取相依性。在一個實施例中，執行和快取相依性使用glMemoryBarrier命令之新穎擴充，其中包括一更整體的快取模型。該傳遞物件亦作為一地點以用於收集有關與先前傳遞磚式快取交互作用的資訊，特別是用於致能(enable)圖形和計算作業之混合之多傳遞磚式快取以及磚式快取。

本發明技術之具體實施例與較早期API(比如OpenGL)之間主要設計差異在於，文中本發明技術之具體實施例在指稱為RAD後需要對轉列傳遞之間危障(hazard)和相依性有更明確的應用程式控制。由於該API之主要目標為在無需CPU/驅動程式介入的情況下，直接提供狀態和連結變更給該GPU，不再有具備資源已如何使用及該使用何時變更之知識的中央仲裁器，因此RAD必須依賴以某種形式提供該資訊的應用程式。特別是，必須替換的該等主要功能包括：- 執行相依性：理解哪些作業必須在之後作業可以開始前完成；- 快取沖洗和無效：確保不一致(non-coherent)快取在新資料寫入資源時進行沖洗或無效化；- 解壓縮：若壓縮表面將由不支援壓縮的硬體單元存取，將其解析為未壓縮；- 磚式(tiling)：以允許一個或多個傳遞按照各磚重新播放以最佳化晶片外記憶體頻寬的方式，表達轉列傳遞之間的相依性。

這四項功能在轉列演算法期間經常同時需要，並需求類似資訊，因此在用於提供此資訊給該驅動程式的該等操作中有顯著重疊。

考量簡單範例：在片段著色器中轉列至紋理，然後從其紋理化。該執行相依性在於，第一傳遞中的該等轉列目標寫入必須在開展未來片段作業前完成。若轉列目標寫入為寫回快取，此類快取必須進行沖洗，而若來自該轉列目標的資料先前已在紋理快取中進行快取，此類快取必須為無效化。若該紋理單元不支援存取此壓縮的轉列目標，其必須進行解壓縮。最後，該驅動程式需要知道該第二轉列傳遞是否可以連同該第一傳遞依各磚執行，這依該轉列目標之哪些紋素(texels)由該第二傳遞之哪些像素讀取而定。

在這四項功能中，解壓縮操作在特定物件上，因此其處理方式不同於其餘功能。當紋理建立時，經由命令radTextureAccess(較早期文件紀錄)，該應用程式指定其將會與怎樣的存取類型一起使用。如此若任何存取類型會從壓縮受益，則允許該驅動程式用壓縮資源分配該記憶體。應用程式亦可在儲存進行分配前藉由呼叫下列命令選擇明確控制解壓縮：在該儲存進行分配後，該應用程式隨後可查詢當該紋理之格式和類型被特定存取類型使用時是否需求手動解壓縮。若紋理具有被致能的壓縮控制，則該應用程式負責使用該命令依所需來解壓縮該記憶體：若紋理具有被除能(disable)的壓縮控制，則每當驅動程式被解開(unbound)為轉列目標時，均其自動地解壓縮該記憶體。(註：這假設轉列為記憶體變為壓縮的主要方式。若情況並非如此，驅動程式可以要求手動明確解壓縮控制，以便分配用於紋理之壓縮)。

在定義快取無效介面前，具有定義該快取記憶體層(對照其任何介面均可評估)的心智模型很重要。

- 各存取類型均可以具有不一致和可能的分散式L1快取(分散式以更接近該著色器或其他處理引擎)。若該存取類型為唯讀(紋理、均勻緩衝區)，則該快取為唯讀。若該存取類型為可寫入(SSBO、影像、轉列目標)，則該快取可為寫回(writeback)或完全寫入(writethrough)。多種存取類型可在某些實施上共享單一快取。給定針對處理器的局部性，L1快取可僅可由生成該等快取條目的佇列無效化。

- 所有GPU存取可共享一致L2快取。此快取(若存在)則必須在所有GPU存取之間一致，但無需在CPU與GPU之間一致。假設已完成寫入至該L2快取，且讀取並未命中陳舊的L1快取單元(entry)，則在此種情況下的一致(Coherent)意指來自該GPU之任何單元上任何GPU存取的寫入，將會由該GPU之任何單元上任何其他GPU存取所看到。若實施不具有L2快取，則GPU記憶體必須具有此相同的一致行為。該L2快取可為寫回或完全寫入之任一者。

- FenceSync命令造成任何寫回L1快取，其與提交即將在其發信號完成前透過該一致L2寫入的佇列相關聯。

有幾種記憶體「用戶端(clients)」，其中所有前述記憶體「用戶端」讀寫記憶體以及下列快取無效規則定義需要哪些操作以使這些寫入和讀取彼此有效地一致。用戶端包括該CPU、該組GPU複製(Copy)命令、和經由GPU處理的該組GPU存取(所有存取類型)。

發生在命令提交給佇列前的CPU寫入將會自動地可見於該佇列上的那些後續命令，而無需該應用程式所提供的附加資訊。此需求之一個可行驅動程式實施為每當批次作業提交(或「沖洗」)至佇列時，均無效化所有L1快取和該L2快取之任何CPU可存取線路。儘管這樣聽起來可能拙劣，但沖洗通常很罕見，而且由CPU可存取線路所使用的該等快取部分通常很小。

為使CPU讀取經由Copy命令或GPU處理之一者能看到GPU寫入之結果，那些寫入必須從任何寫回L1或L2快取中沖洗出，然後該CPU必須等待該等寫入的完成。此舉可藉由使用該FenceSync命令中的適當旗標來達成。

若該CPU和GPU兩者均寫入同一記憶體而無需執行和快取沖洗之充分同步，則上述規則不適用且該結果不明確。

GPU Copy命令係欲為「串流」操作，因此不使用持續L1快取。其更常見具有簡單線路緩衝，以合併在使用後立即沖洗的讀取和寫入。具體而言，其讀取將會總是從L2存取目前資料，且寫入將會完全寫入(write through)至L2。如此，其不具有需求無效的其自身之快取，但其寫入可在其他存取類型之L1快取陳舊中做出線路(make lines)。

Copy命令造成其他單元之L1快取以半自動方式無效化。該應用程式僅負責經由同步物件表達複製佇列與其他佇列之間的*執行相依性(execution dependencies)*，且基於這些執行相依性的規則為該驅動程式提供無效化該等適當快取所需的資訊。又，該驅動程式知道哪些存取類型致能用於該複製之目的地記憶體，此舉允許其進一步限制哪些快取係無效化。

該基本規則在於，為使複製佇列上的Copy命令具有良好定義行為，必須有：- 來自可具有舊快取值之任何佇列的FenceSync(OtherQ)->QueueWaitSync(CopyQ)相依性，其中該FenceSync在該記憶體之最後讀取/寫入後，而該QueueWaitSync在該Copy前。以及，- 在該Copy後而在另一個佇列上該記憶體之任何後續讀取/寫入前的FenceSync(CopyQ)->QueueWaitSync(OtherQ)。

此半自動快取無效行為有多種可能的實施例。首先，若複製佇列能無效化其他佇列之L1快取，其可立即或在下一個FenceSync命令進行，瑣細地滿足此需求。

第二種可能的實施例在QueueWaitSync時間使用為該同步物件之來源的該佇列所提供的資訊來進行快取無效。此舉允許無效延緩至可無效化其自身快取的佇列。

若GPU記憶體釋放並回收/再分配，該驅動程式負責保證在該記憶體再分配前無陳舊快取線路用於該記憶體。

該等剩餘用戶端為透過使用GPU處理之任何該等存取類型的讀取和寫入。該應用程式之責任為存在相依性時使用「屏障(barrier)」沖洗及無效化這些快取。用於屏障的特定API在下列段落中進行說明，但在概念上該屏障具有四段狀態：

- srcMosk、dstMask：管線階段之位元欄

- flushMask、invalidoteMask：存取類型之位元欄

屏障提供有關執行屏障和快取沖洗及無效的資訊。<srcMosk>和<dstMask>指示該執行相依性之來源和目的地，亦即<dstMask>所指示的該等管線階段上之任何作業均可能不會開始，直到<srcMask>所指示的該等管線階段上之所有先前作業均已完成。<flushMask>和<invalidateMask>指示哪些存取類型之快取需要分別寫回(沖洗至L2)或無效化(廢除)。該快取沖洗及/或無效化在<srcMask>所指示的作業完成後及<dstMask>所指示的作業開始前發生。

重新回到我們稍早的簡單轉列至紋理範例，該操作會負責利用以下參數在該轉列與紋理傳遞之間***屏障：

轉列演算法一般由一組「傳遞」構成，其中各傳遞均產生一個轉列目標作為一輸出(或集體所產生的多個轉列目標，又名「MRT」)。使用該簡單轉列至紋理(render-to-texture)範例，轉列至該紋理為該第一傳遞，而在從該紋理紋理化時轉列至該第二轉列目標為該第二傳遞。

這些傳遞之間的真正相依性形成有向非循環圖(Directed acyclic graph，DAG)，但慣用圖形API僅表達命令之線性序列，其係有效地表示該DAG之「平面化」形式。那些API亦依賴命令之嚴格次序以保證相依的傳遞在後續傳遞開始前完成。在現代API(比如其中該驅動程式不檢驗連結資訊的RAD)中，該驅動程式無法反向工程(reverse engineer)以得出該等真正相依性，因此對於該應用程式明確提供此資訊很重要。

「傳遞」物件表示該DAG中的節點，並包括表示該DAG中該等邊緣的相依性資訊。該傳遞包括有關輸入(相依性、屏障、保留緩衝區)、輸出(轉列目標、廢除緩衝區、分解緩衝區)、和磚式狀態(1：1像素映射、濾波器頻寬、記憶體足跡(footprint))的資訊。該磚式狀態提供足夠資訊，以使實施支援多傳遞磚式，亦即在移至該等轉列目標中下一個磚前轉列一個以上的傳遞。

更詳盡地，該狀態包括：

- 轉列目標附件：顏色、深度、和該傳遞之該等結果所寫入的板緩衝區。初始狀態為無附件。

- 保留緩衝區：該等顏色、深度、和板附件之保留緩衝區在該傳遞之起始處將其內容保留。若附件之該等內容未經保留，則依賴那些內容生成不明確行為。初始狀態為所有附件均保留。

- 廢除緩衝區：其紋理在該傳遞之結尾處將其內容廢除。因為需要廢除的緩衝區可能已是先前傳遞而非該目前傳遞中的轉列目標，此命令採取紋理CPU處理而非附件列舉。此命令亦接受施加於各廢除的「像素偏移」，這稍後會在多傳遞磚式之上下文中說明。初始狀態為無紋理廢除。

- 分解緩衝區：其多重取樣顏色附件在該傳遞之結尾處分解至非多重取樣顏色緩衝區。若此類多重取樣緩衝區經標識為待廢除，則該分解在該廢除前立即發生。初始狀態為無附件分解。

- 儲存緩衝區：因為其內容對於多傳遞磚式序列之其餘部分不被需要，其紋理應在該傳遞之結尾處將其內容沖洗至記憶體。「儲存」為該紋理應從該磚記憶體沖洗至晶片外記憶體的提示。不標記紋理為待儲存並非意味著其被廢除，該等內容將會保留，然而不在該適當時間儲存緩衝區可將其較所需更久地保存在磚記憶體中。基於類似於廢除的原因，儲存亦涉及像素偏移。初始狀態為無紋理儲存。

- 剪輯矩形：對該傳遞中所有操作均用作剪裁的該等轉列目標之二維區域，包括轉列、廢除、和分解。初始狀態為未剪輯，亦即(x,y)=(0,0)、(寬度,高度)=(最大,最大)((width,height)=(max,max))。

void radPassClip(RADpass pass,RADuint x,RADuint y, RADuint width,RADuint height)；

- 相依傳遞：此傳遞依其而定的傳遞清單。該實施必須保證那些傳遞已完成至該屏障所說明的層級。初始狀態為無相依性。

- 屏障：該等先前傳遞與該目前傳遞之間該相依性中所涉及的該等階段和快取之說明。如在該屏障段落中所說明的，在該目前傳遞中的作業可繼續進行達與<dstMask>相同程度前，該等相依傳遞中的作業必須完成達與<srcMask>相同程度，並根據<flushMask>從快取沖洗，以及根據<invalidateMask>無效化。初始狀態為無屏障。

磚式邊界：指示連同其相依性依各磚執行此傳遞是否安全的布林(boolean)。若這成立(指示此為邊界)，則該造磚器(tiler)必須在開始此傳遞前進行沖洗。若該目前傳遞中片段執行緒之間有螢幕空間相關性，且該等先前轉列目標之該等紋素係由那些片段執行緒提取，則應用程式可將此設定為不成立(false)。通常這必須為1：1映射，但該API亦允許非零「濾波器頻寬」。初始狀態為邊界=成立(true)。

void radPassTilingBoundary(RADpass pass,RADboolean boundary)；

- 磚式濾波器頻寬：該API容納多傳遞磚式，其中該第二傳遞在來源紋理座標與片段執行緒視窗座標之間不具有剛好1：1關係。若該應用程式可保證該等紋理座標在該視窗座標之+/-[濾波器頻寬，濾波器高度]內，則其可橫越此類相依性致能多傳遞磚式(即邊界=不成立(boundary=FALSE))。初始狀態為濾波器頻寬=濾波器高度=0(filterWidth=filterHeight=0)。

- 磚足跡：對於多傳遞磚式，該實施可能需要預先知道多少記憶體將由磚使用，使得其可選擇最有效的磚大小。該記憶體足跡依各像素之「作業組(working set)」大小而定，亦即在該等多傳遞期間隨時主動的每像素之總位元組。該足跡亦依最大濾波器頻寬而定，這影響多少像素必須隨時保持帶電(alive)。初始狀態為每像素位元組=最大濾波器頻寬=0(bytesPerPixel=maxFilterWidth=0)。

每像素之位元組可能需要藉由涉及抗失真模式而使其更精確。

傳遞之生命週期用該等通常命令(radCreatePass、radReferencePass、radReleasePass)來管理，並藉由radCompilePass使其不可變。編譯傳遞不涉及使轉列命令與其相關聯，這意指該傳遞後續可用於提交轉列命令。

在深入探討傳遞行為前，理解磚式硬體之該等模型以及其與多個傳遞如何交互作用很重要。造磚器(tiler)行為有兩大類：

(1)明確管理磚記憶體。此類硬體需要在各傳遞之起始處均將晶片外 (off-chip)記憶體明確地加載入晶載(on-chip)磚記憶體，並在各傳遞之結尾處均將磚記憶體逆向地儲存至晶片外記憶體。除了某些簡單情況(比如多重取樣分解)，明確地管理的硬體一般不適合多傳遞磚式，並可有效地***各傳遞之間的邊界。多傳遞磚式會需要以潛在複雜方式由轉列目標來分割(partition)該磚記憶體，並使得紋理請求能瞄準磚記憶體之該等部分。若該應用程式請求多傳遞磚式，則其可以回落至單一傳遞。

(2)統一快取型磚記憶體。此類硬體將磚記憶體用作快取，其具有依需求從記憶體加載及基於需要逐出至記憶體的線路。又，此快取亦用作其他記憶體存取類型(比如紋理)，因此可以自該磚記憶體有效地紋理化。這可為與稍早所說明相同的LZ快取。此硬體風格更適合多傳遞磚式，且為該多傳遞設計之主要目標。

某些傳遞狀態依磚式硬體之種類而定可具有不同的內部行為：

- 「保留」：在明確管理硬體上，這需要從晶片外記憶體至磚記憶體的加載/複製。在快取型硬體上，這可為存取保護(nap)。

- 「廢除」：在明確管理硬體上，廢除緩衝區意味著跳過從磚記憶體至晶片外記憶體的儲存/複製。在快取型硬體上，此舉可無效化該快取之線路而無需將該等髒(dirty)線路沖洗至晶片外記憶體。當附件不廢除時，明確管理硬體將會在傳遞之結尾處儲存/複製該記憶體，而快取型硬體可以什麼也不做。快取型硬體亦可在多傳遞序列之後續傳遞期間廢除/無效化記憶體。

- 「儲存」：在明確管理硬體上，這可為網路存取保護(nap)，因為該資料由於先前傳遞已存在晶片外記憶體中，或者將會在該目前傳遞之結尾處被複製到記憶體。在快取型硬體上，這可以沖洗該寫回快取記憶體之一部分。

- 「剪輯矩形」：在明確管理硬體上，此矩形定義加載和儲存所施加的該等區域。在快取型硬體上，這可以僅用作用於轉列命令的剪裁。

- 「磚足跡」：在明確管理硬體上，這可被忽略且該磚大小僅基於該等轉列目標選定。在快取型硬體上，此足跡可用於計算多傳遞序列的所需磚大小。

在快取型硬體上，假設有從稍早傳遞讀取至該目前傳遞中片段座標的紋素座標之剛好1：1映射，多傳遞磚式相當簡單易懂。該應用程式可藉由設定邊界==不成立(boundary==FALSE)和濾波器頻寬/高度==0(filterWidth/Height==0)而指示此點。當情況如此時，該實施可選擇磚大小使得該多傳遞中傳遞之整個作業組可藉由使用該磚足跡狀態之bytesPerPixel而適應該快取記憶體。該實施仍必須在各磚基礎上考量該屏障狀態，但所有該等相關傳遞之磚均可適應該快取記憶體，且廢除和儲存命令可如往常地操作。

當紋素座標之映射至視窗位置並非剛好1：1時，儘管更複雜，但多傳遞磚式仍是可能的。當該應用程式可保證該等紋素座標在經由該radPassTileFilterWidth命令所指定的視窗座標之預定「filterWidth」內時，RAD支援此類多傳遞磚式。該實施可使用此點以藉由朝向該原點的(filterWidth,filterHeight)像素調整傳遞間的磚矩形，使得來自該先前傳遞的有效內容之邊界在該磚之較遠兩個邊緣周圍可取得。同樣地，該應用程式負責為廢除(Discard)和儲存(Store)命令提供準確像素偏移。這些命令亦朝向該原點偏移，且藉由將其偏移雙倍的filterWidth，有效區域維持在磚之較近兩個邊緣周圍。

由於該實施將會試圖保留快取空間以保持此記憶體在該快取中，因此在該目前和最近磚周圍的有效記憶體之這些額外條帶，係為應用程式應努力提供準確maxFilterWidth的原因。

不同於其中計算命令可與圖形命令隨意交互作用且那些命令隱含地有序的其他API，該RAD API需要計算命令在分離的特定計算傳遞中(或在其他計算佇列上非同步地運行)。當紋理座標與計算著色器調用ID之間有關係時，計算傳遞亦可用轉列傳遞而作為磚式。計算傳遞可指定此關係之本質，其可為每一計算調用之一個像素、或為每一計算調用之N×M個像素。若該等計算調用自然適應選定用於轉列的磚形狀，則磚式橫越此類傳遞係可能的。該應用程式可使用該命令radPassTileComputeFootprint以像素為單位指定計算作業群組之形狀。

除了經由多個傳遞指定相依性，亦可使用該命令定義傳遞內的相依性：這可被認為將該目前節點分成兩個節點，其中該第二節點根據該所指定屏障依該第一節點而定。這在MemoryBarrier或TextureBarrier在OpenGL中有助益的此類情況下可為有助益。

使用該等命令將用於傳遞的作業提交給佇列：在傳遞期間提交Copy或FenceSync命令或在圖形傳遞期間提交計算調度命令為非法。這些命令必須發生在傳遞外部(在此種情況下其將會假設依在其之前所提交所有傳遞而定)，或者Copy和計算命令可提交給不同(非同步)佇列。

如何使用傳遞之一些範例：單一傳遞、無相依性、在該結尾處廢除深度：單一傳遞、降低取樣、然後廢除：pass0=radCreatePass(device)；轉列至兩個紋理，然後用1：1紋素：像素映射進行使用：具有偏移和廢除的複雜多傳遞：本發明技術之具體實施例具優勢地指定用於同步、快取控制、記憶體磚式使用情況等的相依性。本發明技術之具體實施例對於驅動程式和應用程式來實施及使用均較簡單且更有效。

前述本發明技術之特定具體實施例之說明已為了例示及說明之目的而經呈現。其不欲為窮舉、或將本發明限制在所揭示的精確形式，而顯而易見地許多修飾例和變化例鑒於上述教示均是可能的。具體實施例經選擇及說明以最佳解釋本發明技術之原理及其實際應用，以藉此讓其他熟悉此項技術者能最佳利用本發明技術和具有如適於所思及的特定用途之各種修飾例的各種具體實施例。其係欲本發明之範疇由文中所附諸申請專利範圍及其相等物所定義。

210-250‧‧‧步驟

Claims

一種方法，包含以下步驟：接收複數個命令；識別用於該等已接收命令的複數個傳遞；對於各組傳遞，其中分別地該組之一第一傳遞為一目的地傳遞而該組之一第二傳遞為一來源傳遞，確定該目的地傳遞與該來源傳遞之該等命令之間的一個或多個相依類型之一個或多個相依性；建立各已識別之傳遞的傳遞物件，其中各傳遞物件均記錄該等對應目的地與來源傳遞之間的該等命令和相依性；以及根據該對應傳遞物件，提交該等複數個傳遞物件之該等命令以用於執行。
如申請專利範圍第1項之方法，其中該等一個或多個相依類型包含執行相依性、快取相依性、和磚式(tiling)相依性。
如申請專利範圍第2項之方法，其中該等一個或多個相依性由一來源遮罩(mask)、一目的地遮罩、一沖洗(flush)遮罩、和一無效遮罩中之一個或多個來指定。
一種儲存計算裝置可執行指令之非暫態計算裝置可讀取媒體，當該計算裝置可執行指令由一個或多個處理單元執行時會實施包含以下步驟之方法：接收複數個轉列(rendering)命令；識別用於該等已接收轉列命令的複數個傳遞；對於各組傳遞，其中一個傳遞為一目的地傳遞而另一個傳遞為相對於彼此的一來源傳遞，確定該目的地傳遞與該來源傳遞之該等轉列命令之間的一個或多個相依類型之一個或多個相依性；建立各已識別之傳遞的傳遞物件，其中各傳遞物件均記錄該等對應目的地與來源傳遞之間的該等轉列命令和相依性；以及根據該對應傳遞物件，提交該等複數個傳遞物件之該等轉列命令以用於執行。
如申請專利範圍第4項之非暫態計算裝置可讀取媒體，其中該等一個或多個相依類型包含執行相依性、快取相依性、和磚式相依性。
如申請專利範圍第5項之非暫態計算裝置可讀取媒體，其中該等一個或多個相依性由一來源遮罩、一目的地遮罩、一沖洗遮罩、和一無效遮罩中之一個或多個來指定。