Mapowania są w puli kafelków
Po utworzeniu zasobu za pomocą flagi D3D11_RESOURCE_MISC_TILED kafelki tworzące zasób pochodzą z lokalizacji w puli kafelków. Pula kafelków to pula pamięci (wspierana przez co najmniej jedną alokację w tle — niezaświetliona przez aplikację). System operacyjny i sterownik wyświetlania zarządzają tą pulą pamięci, a zużycie pamięci jest łatwo zrozumiałe dla aplikacji. Zasoby kafelkowe mapować regiony 64 KB, wskazując lokalizacje w puli kafelków. Jednym z opadów tej konfiguracji jest umożliwienie wielu zasobów współużytkowania i ponownego używania tych samych kafelków, a także ponownego użycia tych samych kafelków w różnych lokalizacjach w ramach zasobu w razie potrzeby.
Kosztem elastyczności wypełniania kafelków dla zasobu poza pulą kafelków jest to, że zasób musi wykonać pracę w zakresie definiowania i utrzymywania mapowania kafelków w puli kafelków reprezentujących kafelki wymagane dla zasobu. Mapowania kafelków można zmienić. Ponadto nie wszystkie kafelki w zasobie muszą być mapowane naraz; zasób może mieć mapowania null. Mapowanie o wartości null definiuje kafelek jako niedostępny z punktu widzenia dostępu do zasobu.
Można utworzyć wiele pul kafelków, a dowolna liczba zasobów kafelków może być mapowana na dowolną pulę kafelków w tym samym czasie. Pule kafelków można również uprawiać lub zmniejszać. Aby uzyskać więcej informacji, zobacz Rozmiar puli kafelków. Jedno ograniczenie, które istnieje, aby uprościć implementację sterownika wyświetlania i środowiska uruchomieniowego, jest to, że dany zasób kafelków może mieć mapowania tylko w co najwyżej jednej puli kafelków w danym momencie (w przeciwieństwie do jednoczesnego mapowania na wiele pul kafelków).
Ilość magazynu skojarzonego z samym zasobem kafelkowym (czyli niezależna pamięć puli kafelków) jest w przybliżeniu proporcjonalna do liczby kafelków rzeczywiście zamapowanych na pulę w danym momencie. Na sprzęcie ten fakt sprowadza się do skalowania pamięci dla magazynu tabel stron w przybliżeniu z ilością kafelków mapowanych (na przykład przy użyciu schematu tabeli stron wielopoziomowych zgodnie z potrzebami).
Pula kafelków może być uważana za całkowicie abstrakcję oprogramowania, która umożliwia aplikacjom Direct3D efektywne programowanie tabel stron na jednostce przetwarzania grafiki (GPU) bez konieczności znajomości szczegółów implementacji niskiego poziomu (lub obsługi adresów wskaźników bezpośrednio). Pule kafelków nie stosują żadnych dodatkowych poziomów pośredniego w sprzęcie. Optymalizacje jednopoziomowej tabeli stron przy użyciu konstrukcji, takich jak katalogi stron, są niezależne od koncepcji puli kafelków.
Przyjrzyjmy się, czego może wymagać sama tabela stron w najgorszym przypadku (jednak w praktyce implementacje wymagają tylko magazynu proporcjonalnego do tego, co jest mapowane).
Załóżmy, że każdy wpis tabeli stron to 64 bity.
W przypadku najgorszego rozmiaru tabeli strony dla pojedynczej powierzchni, biorąc pod uwagę limity zasobów w trybie Direct3D 11, załóżmy, że zasób kafelka jest tworzony z formatem 128 bitów na element (na przykład zmiennoprzecinkowym RGBA), więc kafelek 64 KB zawiera tylko 4096 pikseli. Maksymalna obsługiwana Texture2DArray rozmiar 16384*16384*2048 (ale z tylko jedną mipmapą) wymagałaby około 1 GB miejsca w magazynie w tabeli stron, jeśli w pełni wypełnione (nie w tym mipmap) przy użyciu 64-bitowych wpisów tabeli. Dodanie map mipmap spowoduje zwiększenie w pełni mapowanego (najgorszego przypadku) magazynu tabel stron o około jedną trzecią, do około 1,3 GB.
W tym przypadku można uzyskać dostęp do około 10,6 terabajtów pamięci adresowalnej. Może istnieć jednak ograniczenie ilości pamięci adresowalnej, co zmniejszyłoby te ilości, być może do około zakresu terabajtów.
Innym przypadkiem do rozważenia jest pojedynczy zasób Texture2D kafelków 16384*16384 z 32-bitowym formatem elementu, w tym mipmaps. Miejsce potrzebne w pełnej wypełnionej tabeli stron wynosiłoby około 170 KB z 64-bitowymi wpisami tabeli.
Na koniec rozważmy przykład użycia formatu BC, na przykład BC7 z 128 bitami na kafelek 4x4 pikseli. Jest to jeden bajt na piksel. Texture2DArray 16384*16384*2048, w tym mipmaps, wymagałoby około 85 MB, aby w pełni wypełnić tę pamięć w tabeli stron. To nie jest złe, biorąc pod uwagę, że pozwala to na jeden zasób kafelków do 550 gigapixels (512 GB pamięci w tym przypadku).
W praktyce nigdzie w pobliżu tych pełnych mapowań nie zdefiniowano, biorąc pod uwagę, że ilość dostępnej pamięci fizycznej nie pozwoliłaby nigdzie w pobliżu tej ilości mapowania i odwoływała się w danym momencie. Jednak w przypadku puli kafelków aplikacje mogą używać ponownie kafelków (jako prostego przykładu, ponownego użycia "czarnego" kafelka dla dużych czarnych regionów na obrazie) — efektywnie używając puli kafelków (czyli mapowań tabel stron) jako narzędzia do kompresji pamięci.
Początkowa zawartość tabeli stron jest null dla wszystkich wpisów. Aplikacje nie mogą również przekazywać danych początkowych dla zawartości pamięci powierzchni, ponieważ rozpoczyna się od braku kopii zapasowej pamięci.
W tej sekcji
| Temat | Opis |
|---|---|
| tworzenie puli kafelków |
Pula kafelków jest tworzona za pośrednictwem interfejsu API ID3D11Device::CreateBuffer, przekazując flagę D3D11_RESOURCE_MISC_TILE_POOL w elemencie MiscFlags składowej struktury D3D11_BUFFER_DESC, do której wskazuje parametr pDesc. |
|
Zmiana rozmiaru puli kafelków |
Użyj interfejsu API ID3D11DeviceContext2::ResizeTilePool interfejsu API, aby zwiększyć pulę kafelków, jeśli aplikacja potrzebuje więcej zestawu roboczego dla mapowania zasobów kafelków lub zmniejszyć, jeśli jest potrzebna mniejsza ilość miejsca. |
|
Śledzenie zagrożeń a zasoby puli kafelków |
W przypadku zasobów innych niż kafelki funkcja Direct3D może zapobiec pewnym warunkom zagrożenia podczas renderowania, ale ze względu na to, że śledzenie zagrożeń byłoby na poziomie kafelków dla zasobów kafelków, śledzenie warunków zagrożenia podczas renderowania zasobów kafelków może być zbyt kosztowne. |