Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Obiekt jest uważany za rezydenta, gdy jest dostępny przez procesor GPU.
- Budżet na pobyt
- Zasoby stert
- Priorytety rezydencji
- Zarządzanie rezydencją programową
- Tematy pokrewne
Budżet na pobyt
Procesory GPU nie obsługują jeszcze błędów stron, więc aplikacje muszą zatwierdzać dane w pamięci fizycznej, podczas gdy procesor GPU może uzyskać do niego dostęp. Ten proces jest znany jako "tworzenie czegoś rezydentnego" i musi być wykonywany zarówno dla pamięci systemu fizycznego, jak i fizycznej dyskretnej pamięci wideo. W D3D12 większość obiektów interfejsu API hermetyzuje pewną ilość dostępnej pamięci procesora GPU. Ta pamięć dostępna dla procesora GPU jest rezydentem podczas tworzenia obiektu interfejsu API i eksmitowana podczas niszczenia obiektów interfejsu API.
Ilość pamięci fizycznej dostępnej dla tego procesu jest znana jako budżet pamięci wideo. Budżet może ulegać zauważalnym wahaniom, ponieważ procesy w tle budzą się i śpią; i zmienia się znacząco, gdy użytkownik przełącza się do innej aplikacji. Aplikacja może być powiadamiana, gdy budżet ulegnie zmianie i sonduje zarówno bieżący budżet, jak i aktualnie zużywaną ilość pamięci. Jeśli aplikacja nie pozostanie w budżecie, proces zostanie sporadycznie zamrożony, aby umożliwić innym aplikacjom uruchamianie i/lub interfejsy API tworzenia zwróci błąd. InterfejsIDXGIAdapter3udostępnia metody dotyczące tej funkcji, w szczególności QueryVideoMemoryInfo i RegisterVideoMemoryBudgetChangeNotificationEvent.
Aplikacje są zachęcane do korzystania z rezerwacji w celu określenia ilości pamięci, której nie mogą przejść bez. Najlepiej jest, aby użytkownik określił "niskie" ustawienia grafiki lub coś jeszcze niższego, jest właściwą wartością dla takiej rezerwacji. Ustawienie rezerwacji nie da aplikacji wyższego budżetu niż zwykle. Zamiast tego informacje o rezerwacji pomagają jądro systemu operacyjnego szybko zminimalizować wpływ dużych sytuacji na wykorzystanie pamięci. Nawet rezerwacja nie ma gwarancji, że będzie dostępna dla aplikacji, gdy aplikacja nie jest aplikacją pierwszego planu.
Zasoby stert
Podczas gdy wiele obiektów interfejsu API hermetyzuje część pamięci dostępnej dla procesora GPU, oczekuje się, że sterta i zasoby będą najbardziej znaczącym sposobem, w jaki aplikacje zużywają pamięć fizyczną i zarządzają nią. Sterta jest jednostką najniższego poziomu do zarządzania pamięcią fizyczną, więc dobrze jest mieć pewną znajomość ich właściwości rezydencji.
- Stery nie mogą być częściowo rezydentne, ale obejścia istnieją z zasobami zarezerwowanymi.
- Stery powinny być budżetowane w ramach określonej puli. Karty UMA mają jedną pulę, a dyskretne karty mają dwie pule. Chociaż prawdą jest, że jądro może przesunąć niektóre sterty na dyskretnych kartach z pamięci wideo do pamięci systemowej, robi to tylko jako skrajna ostateczność. Aplikacje nie powinny polegać na nadmiernym zachowaniu jądra i powinny zamiast tego skupić się na dobrym zarządzaniu budżetem.
- Stertę można eksmitować z miejsca zamieszkania, co pozwala na dzielenie zawartości na dysk. Jednak zniszczenie stertów jest bardziej niezawodną techniką zwalniania rezydencji we wszystkich architekturach adapterów. Na kartach, w których poleMaxGPUVirtualAddressBitsPerProcessD3D12_FEATURE_DATA_GPU_VIRTUAL_ADDRESS_SUPPORT jest zbliżone do rozmiaru budżetu, Evict nie będzie niezawodnie odzyskiwać miejsca zamieszkania.
- Tworzenie stert może być powolne; ale jest zoptymalizowany pod kątem przetwarzania wątków w tle. Zaleca się tworzenie stertów na wątkach w tle, aby uniknąć chwalenie wątku renderowania. W D3D12 wiele wątków może bezpiecznie wywoływać procedury współbieżne.
D3D12 wprowadza większą elastyczność i ortogonalność w modelu zasobów w celu włączenia większej liczby opcji dla aplikacji. Istnieją trzy typy zasobów wysokiego poziomu w D3D12: zatwierdzone, umieszczone i zarezerwowane.
- Zatwierdzone zasoby tworzą jednocześnie zasób i stertę. Sterta jest niejawna i nie można uzyskać do niej dostępu bezpośrednio. Sterta ma odpowiedni rozmiar, aby zlokalizować cały zasób w stercie.
- Umieszczone zasoby umożliwiają umieszczanie zasobu w stosie bez zera. Przesunięcia muszą być zwykle wyrównane do 64 KB; ale niektóre wyjątki istnieją w obu kierunkach. Zasoby MSAA wymagają wyrównania przesunięcia 4 MB, a wyrównanie przesunięcia 4 KB jest dostępne dla małych tekstur. Nie można przenieść lub przenieść zasobów umieszczonych bezpośrednio do innej sterty; umożliwiają jednak proste przeniesienie danych zasobów między stertami. Po utworzeniu nowego zasobu umieszczonego w innej stercie i skopiowaniu danych zasobów nowe deskryptory zasobów będą musiały być używane dla nowej lokalizacji danych zasobów.
- Zasoby zarezerwowane są dostępne tylko wtedy, gdy karta obsługuje zasoby kafelkowe w warstwie 1 lub nowszej. Jeśli są dostępne, oferują najbardziej zaawansowane dostępne techniki zarządzania pobytem; ale nie wszystkie karty obecnie je obsługują. Umożliwiają ponowne mapowanie zasobu bez konieczności ponownego odnawiania deskryptorów zasobów, częściowych scenariuszy rezydencji na poziomie mip i rozrzedzeniu tekstur itp. Nie wszystkie typy zasobów są obsługiwane nawet wtedy, gdy są dostępne zasoby zarezerwowane, więc w pełni ogólny menedżer rezydencji opartej na stronie nie jest jeszcze wykonalny.
Priorytety rezydencji
Aktualizacja systemu Windows 10 Dla twórców umożliwia deweloperom wywieranie wpływu na to, które stery i zasoby będą preferowane, aby pozostać rezydentem, gdy wykorzystanie pamięci wymaga, aby niektóre z jego zasobów zostały zdegradowane. Dzięki temu deweloperzy mogą tworzyć aplikacje o lepszej wydajności, wykorzystując wiedzę, że środowisko uruchomieniowe nie może wywnioskować z użycia interfejsu API. Oczekuje się, że deweloperzy staną się bardziej wygodne i zdolne do określania priorytetów podczas przechodzenia z używania zatwierdzonych zasobów do zasobów zarezerwowanych i kafelków.
Stosowanie tych priorytetów musi być łatwiejsze niż zarządzanie dwoma budżetami pamięci dynamicznej, ręczne obniżanie i promowanie zasobów między nimi, ponieważ aplikacje mogą już to zrobić. W związku z tym projekt interfejsu API priorytetu rezydencji jest gruboziarnisty z rozsądnymi domyślnymi priorytetami przypisanymi do każdego sterta lub zasobu podczas jego tworzenia. Aby uzyskać więcej informacji, zobacz ID3D12Device1::SetResidencyPriority i wyliczenie D3D12_RESIDENCY_PRIORITY .
W przypadku priorytetów deweloperzy powinni:
- Podnieś priorytet kilku wyjątkowych stert, aby lepiej ograniczyć doświadczony wpływ tych stert na wydajność tych stert jest obniżany szybciej lub częściej niż ich naturalne wzorce dostępu będą wymagać. Oczekuje się, że takie podejście będzie używane przez aplikacje przeniesione z interfejsów API graficznych, takich jak Direct3D 11 lub OpenGL, który model zarządzania zasobami jest znacznie inny niż model zarządzania zasobami Direct3D 12.
- Zastąp niemal wszystkie priorytety stert przy użyciu własnego schematu zasobnika aplikacji, ustalonego na podstawie wiedzy programisty o częstotliwości dostępu lub dynamicznej; Stały schemat jest prostszy do zarządzania niż dynamiczny, ale może być mniej skuteczny i wymagać interwencji programisty w miarę zmiany wzorców w trakcie opracowywania. Oczekuje się, że takie podejście będzie używane przez aplikacje utworzone przy użyciu zarządzania zasobami w stylu Direct3D 12, takie jak te, które korzystają z biblioteki rezydencji (zwłaszcza schematy dynamiczne).
Domyślny algorytm priorytetu
Aplikacja nie może określić przydatnych priorytetów dla każdej sterty, którą próbuje zarządzać bez uprzedniego zrozumienia domyślnego algorytmu priorytetu. Wynika to z faktu, że wartość przypisania określonego priorytetu do sterty pochodzi z względnego priorytetu do innych priorytetowych sterty, które konkurują o tę samą pamięć.
Strategia wybrana do generowania domyślnych priorytetów polega na kategoryzowaniu sterty na dwa zasobniki, faworyzując (dając wyższy priorytet) sterty, które zakłada się, że są zapisywane często przez procesor GPU na sterty, które nie są.
Zasobnik o wysokim priorytcie zawiera sterty i zasoby, które są tworzone z flagami identyfikującymi je jako obiekty docelowe renderowania, wzornika głębokości lub widoki dostępu nieuporządkowanego (UAV). Są to przypisane wartości priorytetów w zakresie rozpoczynającym się od D3D12_RESIDENCY_PRIORITY_HIGH; aby dalej określać priorytety między tymi stertami i zasobami, najniższe 16-bitowe wartości priorytetu są ustawione na rozmiar sterty lub zasobu podzielonego przez 10 MB (saturating to 0xFFFF dla bardzo dużych sterty). Ta dodatkowa priorytetyzacja sprzyja większym stertom i zasobom.
Zasobnik o niskim priorytcie zawiera wszystkie inne stery i zasoby, które mają przypisaną wartość priorytetu D3D12_RESIDENCY_PRIORITY_NORMAL. Nie jest podejmowana żadna kolejna priorytetyzacja między tymi stertami i zasobami.
Zarządzanie rezydencją programową
Proste aplikacje mogą być w stanie uzyskać, tworząc tylko zatwierdzone zasoby, dopóki nie występują błędy braku pamięci. Po awarii aplikacja może zniszczyć inne zatwierdzone zasoby lub obiekty interfejsu API, aby umożliwić pomyślne tworzenie dalszych zasobów. Jednak nawet proste aplikacje są zdecydowanie zalecane, aby obserwować negatywne zmiany budżetu i zniszczyć nieużywane obiekty interfejsu API mniej więcej raz w ramce.
Złożoność projektu zarządzania pobytem wzrośnie podczas próby optymalizacji pod kątem architektur adaptera lub włączenia priorytetów rezydencji. Dyskretne budżetowanie i zarządzanie dwoma pulami dyskretnej pamięci będzie bardziej złożone niż zarządzanie tylko jednym, a przypisywanie stałych priorytetów na szeroką skalę może stać się obciążeniem konserwacyjnym w przypadku rozwoju wzorców użycia. Przepełnienie tekstur do pamięci systemowej zwiększa złożoność, ponieważ niewłaściwy zasób w pamięci systemowej może poważnie wpływać na szybkość klatek. I nie ma prostych funkcji, aby pomóc zidentyfikować zasoby, które skorzystają z wyższej przepustowości procesora GPU lub tolerować niższą przepustowość procesora GPU.
Jeszcze bardziej skomplikowane projekty będą wykonywać zapytania dotyczące funkcji bieżącej karty. Te informacje są dostępne w D3D12_FEATURE_DATA_GPU_VIRTUAL_ADDRESS_SUPPORT, D3D12_FEATURE_DATA_ARCHITECTURE, D3D12_TILED_RESOURCES_TIER i D3D12_RESOURCE_HEAP_TIER.
Wiele części aplikacji prawdopodobnie zakończy się przy użyciu różnych technik. Na przykład niektóre duże tekstury i rzadko wykonywane ścieżki kodu mogą używać zatwierdzonych zasobów, podczas gdy wiele tekstur może być wyznaczonych z właściwością przesyłania strumieniowego i użyć ogólnej techniki umieszczania zasobów.
Tematy pokrewne