Udostępnij przez


Przegląd list stertowych deskryptorów

Sterty deskryptorów zawierają wiele typów obiektów, które nie są częścią obiektu stanu potoku (PSO), takich jak widoki zasobów cieniowania (SRV), widoki dostępu nieuporządkowanego (UAV), widoki stałego buforu (CBV) i samplery.

Cel stosów deskryptorów

Podstawowym celem sterty deskryptorów jest objęcie zbiorczej alokacji pamięci wymaganej do przechowywania specyfikacji deskryptorów typów obiektów, do których odnoszą się shadery, na jak największy okres renderowania (najlepiej całą ramkę renderowania lub więcej). Jeśli aplikacja szybko zmienia tekstury widziane przez potok z poziomu interfejsu API, musi być dostępne miejsce w stercie deskryptorów, aby dynamicznie zdefiniować tabele deskryptorów dla każdego niezbędnego zestawu stanów. Aplikacja może ponownie wykorzystywać definicje, jeśli zasoby są używane w innym obiekcie, na przykład, lub po prostu przydzielać przestrzeń sterty w sposób sekwencyjny, gdy zmienia różne typy obiektów.

Stosy deskryptorów także umożliwiają poszczególnym składnikom oprogramowania zarządzanie przechowywaniem deskryptorów oddzielnie od siebie.

Wszystkie stosy są widoczne dla procesora. Aplikacja może również zażądać, które właściwości dostępu procesora powinny mieć sterty deskryptorów (jeśli takie istnieją) – zmiana skojarzona, zapisy zwrotne itd. Aplikacje mogą tworzyć dowolną liczbę stert deskryptorów z dowolnymi właściwościami. Aplikacje zawsze mają możliwość tworzenia stert deskryptorów wyłącznie w celach tymczasowego przechowywania, które nie są ograniczone w rozmiarze, oraz kopiowania do stert deskryptorów używanych do renderowania w razie potrzeby.

Istnieją pewne ograniczenia dotyczące tego, co może znajdować się w tym samym stosie deskryptorów. Wpisy CBV, UAV i SRV mogą znajdować się w tym samym stercie deskryptora. Jednak wpisy Samplers nie mogą udostępniać sterty z wpisami CBV, UAV lub SRV. Zazwyczaj istnieją dwa zestawy stert deskryptorów, jeden dla wspólnych zasobów i drugi dla samplerów.

Użycie stert deskryptorów przez Direct3D 12 jest odzwierciedleniem działania większości sprzętu GPU, co wymaga, aby deskryptory były obecne tylko w stertach deskryptorów, lub po prostu, że potrzebna jest mniejsza liczba bitów adresowania, gdy te sterty są używane. Direct3D 12 wymaga użycia stosów deskryptorów, nie ma możliwości umieszczania deskryptorów w dowolnym miejscu w pamięci.

Sterty deskryptorów można edytować wyłącznie bezpośrednio przez CPU. Nie ma możliwości edytowania stert deskryptorów przez GPU.

Synchronizacja

Zawartość sterty deskryptora można zmienić przed, podczas i po rejestrowaniu list poleceń, które się do niej odwołują. Nie można jednak zmienić deskryptorów, gdy lista poleceń przesłana do wykonania może odwoływać się do tej lokalizacji, ponieważ może to wywołać warunek wyścigu.

Wiążący

Co najwyżej jedna sterta połączona CBV/SRV/UAV i jedna sterta samplera mogą być powiązane jednocześnie w dowolnym momencie. Te stosy są współdzielone zarówno między potokami graficznymi, jak i obliczeniowymi, opisanych w ich obiektach PSO.

Przełączanie kopców

Dopuszczalne jest, aby aplikacja przełączała sterty na tej samej liście poleceń lub w różnych przy użyciu interfejsów API SetDescriptorHeaps i Reset. Na pewnym sprzęcie może to być kosztowna operacja, wymagająca zatrzymania GPU w celu opróżnienia wszystkich prac, które są zależne od obecnie związanego sterta deskryptora. W związku z tym, jeśli sterty deskryptorów muszą zostać zmienione, aplikacje powinny próbować to zrobić, gdy obciążenie GPU jest stosunkowo lekkie, na przykład ograniczając zmiany na początku listy poleceń.

Wiązki

W przypadku pakietów może istnieć tylko jedno wywołanie metody SetDescriptorHeaps, a zestaw stertów deskryptora musi odpowiadać dokładnie tym z listy poleceń wywołującej pakiet. Jeśli pakiet nie zmienia tabel deskryptorów, nie musi ustawiać stert deskryptorów.

Aby uzyskać listę wywołań interfejsu API, których nie można używać z pakietami, zobacz Tworzenie i rejestrowanie list poleceń i pakietów.

Zarządzanie

Aby renderować wszystkie obiekty w scenie, będzie potrzebnych wiele deskryptorów i istnieje kilka różnych strategii zarządzania, które można zastosować.

Najbardziej podstawową strategią byłoby wypełnienie nowego obszaru sterta deskryptora ze wszystkimi wymaganiami dotyczącymi następnego wywołania losowania. Tak więc tuż przed wykonaniem wywołania rysowania na liście poleceń, wskaźnik tabeli deskryptora zostanie ustawiony na początek nowo wypełnionej tabeli. Plusem jest to, że nie ma potrzeby rejestrowania, gdzie znajduje się jakiś konkretny deskryptor w stercie.

Wadą tej strategii jest to, że może dojść do wielu powtórzeń deskryptorów w sterpie deskryptorów, zwłaszcza gdy renderowana jest bardzo podobna scena, i że przestrzeń ta zostanie szybko wykorzystana. Oddzielne sterty deskryptora dla tych, które są renderowane na GPU i dla tych, które są zapisywane przez CPU, prawdopodobnie będą konieczne, aby uniknąć konfliktu. Alternatywnie można użyć systemu alokacji podrzędnej.

Ponadto podstawowy system może być dodatkowo zoptymalizowany przez staranne użycie nakładających się tabel deskryptora z jednego wywołania rysowania do następnego, dzięki czemu dodawane są tylko nowe deskryptory wymagane.

Bardziej wydajną strategią niż podstawowa byłoby wstępne wypełnienie stosów deskryptorów tymi, które są wymagane dla obiektów (lub materiałów) znanych jako część sceny. Chodzi o to, że konieczne jest ustawienie tabeli deskryptora podczas rysowania, ponieważ sterta deskryptora jest wypełniana z wyprzedzeniem.

Odmiana strategii wstępnego wypełniania polega na traktowaniu stosu deskryptorów jako jednej ogromnej tablicy zawierającej wszystkie wymagane deskryptory w stałych znanych lokalizacjach. Następnie wywołanie funkcji rysowania musi odbierać tylko zestaw stałych, które są indeksami w tablicy, gdzie znajdują się używane deskryptory.

Dalsza optymalizacja polega na tym, aby stałe główne i deskryptory główne zawierały te elementy, które zmieniają się najczęściej, zamiast umieszczać stałe w stercie deskryptorów. W przypadku większości sprzętu jest to wydajny sposób obsługi stałych.

W praktyce aparat graficzny może używać innej strategii w różnych sytuacjach i łączyć elementy każdej strategii, aby spełnić określone wymagania dotyczące rysunku.

stosy deskryptorów