本文說明從 Windows 11 版本 24H2 （WDDM 3.2） 開始支援的髒位追蹤功能。 在支援 GPU 平行處理裝置的 即時遷移的驅動程式 也必須支援髒位元追蹤。
簡介
隨著雲端案例中的 GPU 變得更受歡迎，因此越來越多的需要確保虛擬機從一部實體主機移轉至另一部實體主機維持合理的效能。 這不僅需要減少用戶的影響，也為了避免在移轉 VM 時發生 TCP 要求逾時等問題。
在實體主機之間傳輸記憶體內容是在兩次整體傳遞中完成：
Brownout：在停電期間，虛擬機仍然運行中，但系統會對任何未儲存的數據進行多次儲存。 目標是，在每次反覆運算期間數據髒污的量會變小，直到其收斂到可以快速複製的小規模數據子集。 此數據量會根據計算機的工作負載而有所不同，且不保證會聚合至任何特定大小。
暫停時期：在停電期間，虛擬機器會暫停，並複製所有剩餘的髒數據。 此復本可確保目的地機器上產生的數據狀態與來源相同。
若沒有髒位元追蹤，系統必須在停電期間依賴 GPU 幀緩衝區（VRAM）的唯一完整副本。 要支援暫時降電處理功能，硬體必須能夠主動追蹤已修改的記憶體頁面，並回報給作業系統，讓作業系統只複製必要的記憶體。
詳細設計
報告功能
在適配卡初始化期間，Dxgkrnl 會查詢驅動程式，以詢問硬體使用的髒位元平面格式的相關資訊。也就是說，每個位所代表的頁面大小（或數據量）。
啟動和停止未加工的擷取
如果追蹤髒資訊對硬體效能的影響成本很高，那麼僅在電力限制期間啟用髒資料追蹤是合理的。 在此期間，將移轉成本降至最低，比追蹤的潛在效能影響更重要。
不過，如果對效能沒有任何影響或微不足道，一律啟用此行為會有好處。 有些使用者可能不會在其 VM 上執行繁重的 GPU 工作負載，因此記憶體可能不會從頭被嚴重地抹除。 藉由在啟動時啟用髒位追蹤，資源耗竭的第一次迭代可以立即使用髒資料，而不需要框架緩衝區的完整拷貝。 如果使用者修改的記憶體數量很小（例如，使用者主要在進行以處理器為基礎的工作負載），那麼遷移所節省的成本可能會相當顯著。
查詢髒位元
髒資訊會以髒頁面的位元平面表示。 位平面中的每個位都代表一個記憶體的「頁面」。 臟資料的頁面大小不需要與 GPU 上虛擬尋址的自然頁面大小對齊（例如 4KB/64KB）。 它可以是最適合特定硬體的任何配置。 驅動程式會在初始化期間報告此頁面大小。
在降電期間，Dxgkrnl 會查詢硬體以獲取每次迭代之間的髒數據。 此時，驅動程式必須能夠原子地查詢和重置位平面數據。 也就是說，硬體必須能夠在單一原子操作中查詢其值，並將其重設為零，以避免遺失未儲存的資訊中的數據。
虛擬機不一定全部移轉至相同的目的地，因此會針對每個虛擬 GPU 實例進行畫面緩衝區移轉。 因此，驅動程式必須能夠查詢代表該特定虛擬 GPU 實例之整體框架緩衝區之指定子範圍的位平面資訊。 例如，8 GB 的 GPU 被分割成四個部分時，必須能夠對每個 2GB VRAM 範圍的位元進行查詢和重設，而不會影響其他髒位元數據。
DDI 變更
能力
下列上限會新增至 DXGK_QUERYADAPTERINFOTYPE。
DXGKQAITYPE_DIRTYBITTRACKINGCAPS
系統現在會在適配卡初始化期間，呼叫 KMD 的 DxgkDdiQueryAdapterInfo 函式，並使用 DXGK_QUERYADAPTERINFOTYPE 的 DXGKQAITYPE_DIRTYBITTRACKINGCAPS，以判斷驅動程式和硬體功能的骯髒位追蹤能力。
KMD 應該填寫所提供的 DXGK_DIRTY_BIT_TRACKING_CAPS 結構體，而該結構體由 pOutputData 指向。
DXGKQAITYPE_DIRTYBITTRACKINGSEGMENTCAPS
如果 KMD 將 DirtyBitTrackingSupported 設為 TRUE，系統會呼叫 KMD 的 DxgkDdiQueryAdapterInfo 函式，並以 DXGKQAITYPE_DIRTYBITTRACKINGSEGMENTCAPS 的 DXGK_QUERYADAPTERINFOTYPE 為參數，針對系統上的每個記憶體區段查詢有關臟位追蹤支持的資訊。
KMD 必須填寫所提供的 DXGK_DIRTY_BIT_TRACKING_SEGMENT_CAPS 結構，該結構由 pOutputData 指向。
記憶體基礎 DIS
追蹤 VRAM 上的修改操作是針對那些可能無法連續支持的內存分配。 例如，Live Migration中的初始用法適用於虛擬功能框架緩衝區保留區域的追蹤。 因此，在追蹤臟位時所代表的實體位址是由代表所作配置的範圍集合所組成。
請務必確保作業符合相同的範圍。 在許多情況下，此比對必須作為介面的強制性規則，以確保狀態的正確追蹤。 為了協助使用 KMD 進行追蹤，會引入下列介面：