共用方式為

配置使用量追蹤

  • 發行項

隨著配置清單消失，視訊記憶體管理員 (VidMm) 不再看到特定命令緩衝區中所參考的配置。 因此，VidMm 不再位於追蹤配置使用量及處理相關同步處理的位置。 此責任現在落在 UMD () 的使用者模式驅動程式。 特別是，UMD 必須處理與直接 CPU 存取以配置和重新命名相關的同步處理。

VidMm 會以安全的方式延遲配置解構，這是呼叫線程和效能的非封鎖。 因此，UMD 不需要擔心必須延遲配置解構。 當 VidMm 收到配置解構要求時，預設會假設在解構要求之前排入佇列的命令可能會存取正在終結的配置。 VidMm 因此會延遲解構作業，直到佇列命令完成為止。 如果 UMD 知道擱置的命令無法存取正在終結的配置，它可以指示 VidMm 在呼叫 Deallocate2 或 DestroyAllocation2 時設定 AssumeNotInUse 旗標來處理要求，而不需等候。

Lock2

UMD 負責處理直接 CPU 存取的適當同步處理。 特別是，需要UMD才能：

  1. 支援無覆寫和捨棄鎖定語意，這表示 UMD 必須實作自己的重新命名配置。

  2. 對於需要同步處理 (的對應作業，而非上述不覆寫或捨棄) ：

    • 如果嘗試存取目前忙碌的配置，且呼叫端要求鎖定作業不會封鎖呼叫線程， ( D3D11_MAP_FLAG_DO_NOT_WAIT) ，則傳回 WasStillDrawing。
    • 或者，如果未設定 D3D11_MAP_FLAG_DO_NOT_WAIT 旗標，請等到配置可供CPU存取使用為止。 UMD 必須實作非模擬等候。 UMD 會使用新的內容監視機制。

現在，UMD 會繼續呼叫 LockCb/UnlockCb ，要求 VidMm 設定 CPU 存取的配置。 在大部分情況下，UMD 能夠保留其整個存留期對應的配置。 不過，未來會淘汰LockCb和UnlockCb，以取代新的Lock2Cb和Unlock2Cb呼叫。 這些較新的回呼目標是使用一組全新的自變數和旗標，提供全新的實作。

Swizzling 範圍會從 WDDM 第 2 版中移除。 驅動程式開發人員必須負責移除從呼叫 LockCb 到 LockCb 的相依性，因為它們會移至以 Lock2Cb 為基礎的實作。

Lock2Cb 會公開為取得配置虛擬位址的簡單方法。 根據配置的類型和目前區段目前所在的區段，有一些限制。

驅動程式指出區段是否可透過 CpuVisible 旗標存取，其位於 DXGK_SEGMENTDESCRIPTOR 結構的 Flags 成員中。

針對可存取 CPU 的設定：

  • 快取的 CPU 可存取配置必須位於光圈區段內，或不是固定，才能鎖定。 我們無法保證圖形處理單位上的CPU與記憶體區段之間的快取一致性， (GPU) 。
  • CPU 可存取的配置位於完全 CPU 可存取記憶體區段中， (使用可重設大小的 BAR) ，保證可鎖定且能夠傳回虛擬位址。 在此案例中不需要任何特殊條件約束。
  • 位於非 CPU 存取記憶體區段內的 CPU 可存取配置， (或沒有 CPUHostAperture 存取權) 可能會因為各種原因而無法對應到 CPU 虛擬位址。 如果 CpuHostAperture 空間不足，或配置未指定光圈區段，則無法取得虛擬位址。 基於這個理由，非 CPU 可存取記憶體區段中的所有 CPU 可存取配置都必須在其支援的區段集中包含光圈區段。 這項需求可確保 VidMm 能夠將配置放在系統記憶體中，並提供虛擬位址。
  • CPU 可存取的配置已位於系統記憶體 (和/或對應至光圈區段) ，保證能夠運作。

針對無法存取 CPU 的設定：

  • CPU 可存取的配置是由無法直接指向 GPU 框架緩衝區的區段物件所支援。 若要鎖定無法存取CPU的配置，配置必須支援支援區段中支援的區段，或已在系統記憶體 (不得位於裝置上) 。

如果在配置不在裝置上，但不支援光圈區段時成功鎖定配置，則配置在鎖定期間不得認可到記憶體區段。

Lock2 目前不包含任何旗標， 且保留 旗標位必須全部為 0。

CpuHostAperture

為了在調整 BAR 大小失敗時，以無法存取 CPU 的記憶體區段來更妥善地支持鎖定，PCI 光圈中會提供 CpuHostAperture 。 CpuHostAperture 的行為就像以頁面為基礎的管理員，然後可以透過 DxgkDdiMapCpuHostAperture裝置驅動程式介面，直接對應到視訊記憶體的區域， (DDI) 函式。 然後，VidMm 可以將虛擬位址空間的範圍直接對應至 CpuHostAperture 的非連續範圍，並讓 CpuHostAperture 對應至視訊記憶體，而不需要撥動範圍。

CPU 可以在非 CPU 可存取記憶體區段內參考的最大可鎖定記憶體數量限制為 CpuHostAperture 的大小。 如需向 DirectX 圖形核心公開 CpuHostAperture 的詳細數據，請參閱 CPU 主機光圈。

I/O 共置

在目前 x86/x64 上，所有 GPU 都必須支援透過 PCIe 的 I/O 共合，以允許 GPU 讀取或寫入可快取的系統記憶體介面，並維持與 CPU 的一致性。 當介面從 GPU 的觀點對應為快取一致時，GPU 必須在存取介面時探查 CPU 快取。 這種形式的共合通常用於 CPU 預期從中讀取的資源，例如某些預備介面。

在某些 Arm 平臺上，硬體中不支援 I/O 共合。 在這些平臺上，必須手動使CPU快取階層失效，以模擬I/O共合。 VidMm 藉由追蹤來自 GPU (設定清單讀取/寫入作業的配置作業，以及 CPU (對應) 作業、讀取/寫入) 來進行。 VidMm 會在判斷快取時發出快取失效，可能包含：

  • 需要回寫 (CPU 寫入、GPU 讀取) 的數據
  • 需要 (GPU 寫入、CPU 讀取) 失效的過時數據。

在沒有 I/O 共合的平臺上，追蹤 CPU 和 GPU 存取配置的責任落在 UMD。 圖形核心會公開新的 Invalidate CacheDDI，UMD 可用來回寫和使與可快取配置相關聯的虛擬位址範圍失效。 在不支援 I/O 共通的平臺上，必須在 CPU 寫入和 GPU 讀取之前，以及在寫入和 CPU 讀取之前呼叫此函式。 後者一開始可能有點不直覺。 但是，由於 CPU 在 GPU 寫入到記憶體之前可能會有假設性讀取數據，因此必須使所有 CPU 快取失效，以確保 CPU 會從 RAM 重新讀取數據。