Sdílet prostřednictvím

Sídlo

  • Článek

Objekt je považován za rezidentní, pokud je přístupný GPU.

Rozpočet rezidence

Gpu zatím nepodporují chybování stránky, takže aplikace musí potvrdit data do fyzické paměti, zatímco GPU k němu může získat přístup. Tento proces se označuje jako "vytváření něčeho rezidenta" a musí být proveden pro fyzickou systémovou paměť i fyzickou diskrétní video paměť. V D3D12 zapouzdřuje většina objektů rozhraní API určité množství paměti s podporou GPU. Tato paměť s podporou GPU je při vytváření objektu rozhraní API rezidentní a při zničení objektu rozhraní API se vyřadí.

Množství fyzické paměti dostupné pro proces se označuje jako rozpočet paměti videa. Rozpočet může výrazně kolísat, protože procesy probuzení a spánku na pozadí; a výrazně kolísat, když se uživatel přepne na jinou aplikaci. Aplikace může být upozorněna, když se rozpočet změní, a dotazovat se na aktuální rozpočet i aktuálně spotřebované množství paměti. Pokud aplikace nezůsáhne v rámci svého rozpočtu, proces se přerušovaně zablokuje, aby ostatní aplikace mohly spouštět a/nebo rozhraní API pro vytváření vrátí chybu. Rozhraní IDXGIAdapter3 poskytuje metody týkající se této funkce, zejména QueryVideoMemoryInfo a RegisterVideoMemoryBudgetChangeNotificationEvent.

Aplikace se doporučuje použít rezervaci k označení množství paměti, kterou nemohou bezejdou. V ideálním případě je pro takovou rezervaci správná hodnota nastavení "nízké" grafiky nebo něco ještě nižšího. Nastavení rezervace nikdy neudělí aplikaci vyšší rozpočet, než by normálně dostávala. Místo toho informace o rezervaci pomáhají jádru operačního systému rychle minimalizovat dopad velkých situací na zatížení paměti. I rezervace není zaručená, že aplikace bude k dispozici, pokud aplikace není aplikací na popředí.

Prostředky haldy

Zatímco mnoho objektů rozhraní API zapouzdřuje určitou paměť s podporou GPU, očekává se, že haldy & prostředky budou nejvýznamnějším způsobem, jak aplikace spotřebovávají a spravují fyzickou paměť. Halda je jednotka nejnižší úrovně pro správu fyzické paměti, takže je dobré mít určité znalosti o jejich rezidenci vlastností.

  • Haldy nelze provést částečně rezidentní, ale existují alternativní řešení s rezervovanými prostředky.
  • Haldy by měly být rozpočtovány jako součást určitého fondu. Adaptéry UMA mají jeden fond, zatímco samostatné adaptéry mají dva fondy. I když je pravda, že jádro může posunout některé haldy na diskrétní adaptéry z paměti videa do systémové paměti, dělá to pouze jako extrémní poslední možnost. Aplikace by se neměly spoléhat na chování jádra při nadměrném rozpočtu a měly by se soustředit na dobrou správu rozpočtu.
  • Haldy je možné vyřadit z rezidence, což umožňuje stránkovat jejich obsah na disk. Zničení hald je ale spolehlivější technika, jak uvolnit rezidenci napříč všemi architekturami adaptérů. Na adaptérech, u kterých pole pole D3D12_FEATURE_DATA_GPU_VIRTUAL_ADDRESS_SUPPORT MaxGPUVirtualAddressBitsPerProcess, vyřazení spolehlivě nevymahat rezidenci.
  • Vytvoření haldy může být pomalé; ale je optimalizovaná pro zpracování vlákna na pozadí. Doporučuje se vytvořit haldy na vláknech na pozadí, aby se zabránilo zakrývání vykreslovacího vlákna. V D3D12 může více vláken bezpečně volat rutiny vytváření rutin současně.

D3D12 zavádí do svého modelu prostředků větší flexibilitu a orthogonalitu, aby bylo možné povolit více možností pro aplikace. V D3D12 existují tři základní typy prostředků: potvrzené, umístěné a rezervované.

  • Potvrzené prostředky vytvoří současně prostředek i haldu. Halda je implicitní a nelze k němu přistupovat přímo. Halda je vhodná pro vyhledání celého prostředku v haldě.
  • Umisťované prostředky umožňují umístění prostředku v nenulovém posunu v haldě. Posuny musí být obvykle zarovnány na 64 kB; ale některé výjimky existují v obou směrech. Prostředky MSAA vyžadují zarovnání posunu 4 MB a pro malé textury je k dispozici zarovnání posunu 4 kB. Umístěné prostředky nelze přímo přemístit ani přemapovat na jinou haldu; ale umožňují jednoduché přemístění dat prostředků mezi haldou. Po vytvoření nového umístěného prostředku do jiné haldy a zkopírování dat prostředků bude nutné pro nové umístění dat prostředků použít nové popisovače prostředků.
  • Rezervované prostředky jsou dostupné jenom v případech, kdy adaptér podporuje dlaždicové prostředky vrstvy 1 nebo vyšší. Pokud jsou k dispozici, nabízejí nejpokročilejší techniky správy rezidencí, které jsou k dispozici; ale ne všechny adaptéry je v současné době podporují. Umožňují přemapování prostředku bez nutnosti regenerace popisovačů zdrojů, částečné rezidence na úrovni mip a scénáře zhuštěné textury atd. Ne všechny typy prostředků se podporují, i když jsou k dispozici rezervované prostředky, takže plně obecný správce rezidencí na základě stránky ještě není proveditelný.

Priority rezidence

Windows 10 Creators Update umožňuje vývojářům ovlivnit, které haldy a prostředky budou preferovány, aby zůstali rezidentní, když zatížení paměti vyžaduje, aby některé z jeho prostředků byly degradovány. To vývojářům pomáhá vytvářet aplikace s lepším výkonem díky znalostem, že modul runtime nemůže odvodit využití rozhraní API. Očekává se, že vývojáři budou pohodlnější a schopní určit priority při přechodu z používání potvrzených prostředků k opětovnému zpronažení a dlaždici prostředků.

Použití těchto priorit musí být jednodušší než správa dvou rozpočtů dynamické paměti, ruční snížení a zvýšení úrovně prostředků, protože aplikace to už můžou udělat. Návrh rozhraní API pro prioritu rezidence je proto samozřejmě odstupňovaný s rozumnými výchozími prioritami přiřazenými ke každé haldě nebo prostředku při vytváření. Další informace najdete v tématu ID3D12Device1::SetResidencyPriority a výčtu D3D12_RESIDENCY_PRIORITY.

S prioritami se očekává, že vývojáři budou:

  • Zvyšte prioritu několika výjimečných hald, aby se lépe zmírnit zkušený dopad na výkon těchto hald dříve nebo častěji, než by jejich vzory přirozeného přístupu požadovaly. Očekává se, že tento přístup budou využívat aplikace portované z grafických rozhraní API, jako je Direct3D 11 nebo OpenGL. Model správy prostředků se výrazně liší od modelu správy prostředků Direct3D 12.
  • Přepsat téměř všechny priority haldy pomocí vlastního schématu kontejnerizace aplikace, buď pevně, na základě znalosti programátora o frekvenci přístupu, nebo dynamické; Pevné schéma je jednodušší spravovat než dynamické, ale může být méně efektivní a vyžadovat programátorské inteventiony, protože se v průběhu vývoje mění vzory použití. Očekává se, že tento přístup budou využívat aplikace vytvořené pomocí správy prostředků ve stylu Direct3D 12, například aplikace, které používají knihovnu rezidencí (zejména dynamická schémata).

Výchozí algoritmus priority

Aplikace nemůže určit užitečné priority pro žádnou haldu, kterou se pokusí spravovat, aniž by nejprve podřadil výchozí algoritmus priority. Důvodem je to, že hodnota přiřazení konkrétní priority haldě je odvozena od relativní priority k jiným prioritním haldům, které soutěží o stejnou paměť.

Strategie zvolená pro generování výchozích priorit je kategorizovat haldy do dvou kbelíků, což upřednostňuje (dává vyšší prioritu) haldy, u které se předpokládá, že se často zapisuje gpu přes haldy, které nejsou.

Kontejner s vysokou prioritou obsahuje haldy a prostředky vytvořené pomocí příznaků, které je identifikují jako cíle vykreslování, vyrovnávací paměti vzorníku nebo neuspořádané zobrazení přístupu (UAV). Tyto hodnoty jsou přiřazeny priority v rozsahu počínaje D3D12_RESIDENCY_PRIORITY_HIGH; pro větší prioritu mezi těmito haldami a prostředky jsou nejnižší 16bitové verze priority nastaveny na velikost haldy nebo prostředku dělené 10 MB (nasycení 0xFFFF pro extrémně velké haldy). Toto další stanovení priority upřednostňuje větší haldy a prostředky.

Kontejner s nízkou prioritou obsahuje všechny ostatní haldy a prostředky, které mají přiřazenou hodnotu priority D3D12_RESIDENCY_PRIORITY_NORMAL. Mezi těmito haldy a prostředky se nepokusí žádné další stanovení priorit.

Programování správy rezidencí

Jednoduché aplikace se můžou dostat pouhým vytvořením potvrzených prostředků, dokud nedojde k selhání nedostatku paměti. Při selhání může aplikace zničit další potvrzené prostředky nebo objekty rozhraní API, aby bylo možné úspěšně vytvořit další prostředky. I jednoduché aplikace se ale důrazně doporučují sledovat negativní změny rozpočtu a zničit nepoužité objekty rozhraní API zhruba jednou za rámec.

Složitost návrhu správy rezidencí se zvýší při pokusu o optimalizaci architektury adaptérů nebo začlenění priorit rezidence. Diskrétní rozpočtování a správa dvou fondů diskrétní paměti bude složitější než správa pouze jedné a přiřazení pevných priorit v širokém měřítku může být zátěží údržby, pokud se vyvíjejí vzorce použití. Přetečení textur do systémové paměti zvyšuje složitost, protože nesprávný prostředek v systémové paměti může mít závažný dopad na snímkovou frekvenci. A neexistuje žádná jednoduchá funkce, která by pomohla identifikovat prostředky, které by buď mohly těžit z větší šířky pásma GPU, nebo tolerovat nižší šířku pásma GPU.

Ještě složitější návrhy budou dotazovat na funkce aktuálního adaptéru. Tyto informace jsou k dispozici v D3D12_FEATURE_DATA_GPU_VIRTUAL_ADDRESS_SUPPORT, D3D12_FEATURE_DATA_ARCHITECTURE, D3D12_TILED_RESOURCES_TIERa D3D12_RESOURCE_HEAP_TIER.

Více částí aplikace se pravděpodobně vymýšlí pomocí různých technik. Například některé rozsáhlé textury a zřídka cvičené cesty kódu můžou používat potvrzené prostředky, zatímco mnoho textur může být označeno vlastností streamování a používat obecnou techniku umístěného prostředku.

ID3D12Heap

správy paměti