Pamięć wirtualna procesora GPU w programie WDDM 2.0

Ten artykuł zawiera szczegółowe informacje na temat zarządzania pamięcią wirtualną procesora GPU począwszy od systemu Windows 10 (WDDM 2.0). Opisano w nim, dlaczego WDDM 2.0 została zmieniona w celu obsługi wirtualnego adresowania procesora GPU i sposobu korzystania z niego sterowników.

Wprowadzenie

Przed WDDM 2.0 interfejs sterownika urządzenia (DDI) został zbudowany tak, aby silniki GPU odwoływały się do pamięci przez adresy fizyczne segmentu. Ponieważ segmenty były współużytkowane przez aplikacje i przeciążone, zasoby zostały przenoszone przez ich czas życia, a przypisane adresy fizyczne zmieniały się. Ten proces wymagał śledzenia odwołań pamięci wewnątrz buforów poleceń poprzez listy alokacji i lokalizacji łat. Te bufory musiały zostać poprawione poprawnym odniesieniem do pamięci fizycznej przed przesłaniem do silnika GPU. To śledzenie i stosowanie poprawek było kosztowne. Zasadniczo narzucił model planowania, w którym menedżer pamięci wideo (VidMm) musiał sprawdzić każdy pakiet, zanim mógł zostać przesłany do silnika.

Z czasem coraz więcej dostawców sprzętu przeniósł się do modelu planowania opartego na sprzęcie. W tym modelu praca jest przesyłana do procesora GPU bezpośrednio z trybu użytkownika, a procesor GPU zarządza różnymi kolejkami pracy. Ewolucja ta sprawiła, że konieczne stało się wyeliminowanie potrzeby, aby VidMm sprawdzał i poprawiał każdy bufor poleceń przed przesłaniem go do silnika GPU.

W tym celu usługa WDDM obsługuje adresowanie wirtualne procesora GPU, począwszy od WDDM 2.0. W tym modelu każdy proces otrzymuje przypisaną unikatową przestrzeń adresu wirtualnego procesora GPU (GPUVA), w której może być wykonywany każdy kontekst procesora GPU. Alokacja utworzona lub otwarta przez proces zostaje przypisana unikatowy wirtualny adres GPU w ramach przestrzeni adresowej GPU tego procesu. Ten przypisany GPUVA pozostaje niezmienny i unikalny przez cały okres istnienia alokacji. Sterownik wyświetlania w trybie użytkownika (UMD) jest w stanie odwoływać się do alokacji pamięci za pośrednictwem wirtualnego adresu procesora GPU bez konieczności martwienia się o zmiany w podstawowej pamięci fizycznej przez cały okres jej istnienia.

Poszczególne silniki procesora GPU mogą działać w trybie fizycznym lub wirtualnym.

• W trybie fizycznym model planowania pozostaje taki sam, jak w przypadku programu WDDM w wersji 1.x. UMD nadal generuje listę alokacji oraz listę lokalizacji poprawek. Te listy alokacji są przesyłane z buforem poleceń i są używane do poprawiania buforów poleceń do rzeczywistych adresów fizycznych przed przesłaniem do silnika.

• W trybie wirtualnym silnik odwołuje się do pamięci za pośrednictwem wirtualnych adresów GPU. UMD generuje bufory poleceń bezpośrednio z trybu użytkownika i używa nowych usług do przesyłania tych poleceń do jądra. UMD nie generuje list alokacji ani lokalizacji poprawek, chociaż nadal jest odpowiedzialne za zarządzanie dostępnością alokacji. Aby uzyskać więcej informacji na temat pobytu kierowcy, zobacz Driver residency in WDDM 2.0 (Pobyt kierowcy w WDDM 2.0).

Modele pamięci procesora GPU

WDDM v2 obsługuje dwa odrębne modele adresowania wirtualnego procesora GPU, GpuMmu i IoMmu. Kierowca musi wyrazić zgodę na obsługę jednego lub obu modeli. Jeden węzeł procesora GPU może obsługiwać oba tryby jednocześnie.

Model GpuMmu

W modelu GpuMmu VidMm zarządza jednostką zarządzania pamięcią procesora GPU i podstawowymi tabelami stron. VidMm udostępnia również usługi UMD, które umożliwiają zarządzanie mapowaniem adresów wirtualnych procesora GPU na alokacje. GpuMmu oznacza, że GPU używa tabel stron GPU do uzyskiwania dostępu do danych. Tabele stron mogą wskazywać pamięć systemową lub lokalną pamięć urządzenia.

Aby uzyskać więcej informacji, zobacz Model GpuMmu.

IoMmu Model

W modelu IoMmu zarówno CPU, jak i GPU współdzielą wspólną przestrzeń adresową oraz tabele stron CPU. W tym przypadku można uzyskać dostęp tylko do pamięci systemowej, więc IoMmu jest odpowiedni dla zintegrowanych procesorów GPU. IoMmu udostępnia prostszy model programowania, w którym zarówno procesor GPU, jak i procesor CPU mogą używać tego samego wskaźnika w celu uzyskania dostępu do pamięci. Nie ma potrzeby zarządzania oddzielnym zestawem tabel stron w pamięci dostępnej dla procesora GPU. Oznacza to, że model IoMmu może spowodować obniżenie wydajności ze względu na obciążenie związane z tłumaczeniem adresów i zarządzaniem.

Aby uzyskać więcej informacji, zobacz Model IoMmu.