Kopírování a přístup k datům zdrojů

Příznaky použití označují, jak aplikace zamýšlí používat data prostředků k umístění prostředků do oblasti paměti, která je z hlediska výkonu nejvýhodnější. Údaje o prostředcích se kopírují mezi prostředky, aby k nim CPU nebo GPU mohly přistupovat bez ovlivnění výkonu.

Není nutné uvažovat o prostředcích, které se vytvářejí v paměti videa nebo v systémové paměti, nebo rozhodnout, zda má modul runtime spravovat paměť. S architekturou WDDM (Model ovladače zobrazení systému Windows) aplikace vytvářejí prostředky Direct3D s různými příznaky použití, které indikují, jak aplikace hodlá používat data o prostředcích. Tento model ovladače virtualizuje paměť používanou prostředky; je zodpovědností operačního systému, ovladače nebo správce paměti umístit prostředky do nejvýkonnější oblasti paměti, vzhledem k očekávanému využití.

Výchozím případem je dostupnost prostředků pro GPU. Existují časy, kdy data prostředků musí být k dispozici pro procesor. Kopírování dat o prostředcích kolem, aby k němu příslušný procesor mohl přistupovat, aniž by to mělo vliv na výkon, vyžaduje určité znalosti o tom, jak fungují metody rozhraní API.

Kopírování dat zdrojů

Prostředky se vytvářejí v paměti, když Direct3D spustí volání Create. Mohou být vytvořeny v paměti videa, systémové paměti nebo jiném druhu paměti. Vzhledem k tomu, že model ovladače WDDM virtualizuje tuto paměť, aplikace už nemusí sledovat, v jakém typu paměťových prostředků jsou vytvořeny.

V ideálním případě by se všechny prostředky nacházely v paměti videa, aby k nim gpu mohl mít okamžitý přístup. Někdy je však nutné, aby procesor načetl data o prostředcích nebo aby GPU získal přístup k datům prostředků, která byla zapsána procesorem. Direct3D zpracovává tyto různé scénáře tím, že aplikaci požádá o určení způsobu využití, a poté v případě potřeby nabízí několik metod pro kopírování dat prostředků.

V závislosti na tom, jak byl prostředek vytvořen, není vždy možné získat přímý přístup k podkladovým datům. To může znamenat, že data prostředků musí být zkopírována ze zdrojového prostředku do jiného prostředku, který je přístupný příslušným procesorem. Z hlediska Direct3D je možné k výchozím prostředkům přistupovat přímo pomocí GPU, dynamických a přípravných prostředků, ke které má procesor přímý přístup.

Po vytvoření prostředku nelze jeho využití změnit. Místo toho zkopírujte obsah jednoho prostředku do jiného prostředku, který byl vytvořen s jiným využitím. Zkopírujete data prostředků z jednoho prostředku do jiného nebo zkopírujete data z paměti do prostředku.

Existují dva hlavní druhy prostředků: mapovatelné a nemapovatelné. Prostředky vytvořené s dynamickým nebo přípravným využitím jsou mapovatelné, zatímco prostředky vytvořené s výchozím nebo neměnným využitím nejsou mapovatelné.

Kopírování dat mezi nemapovatelnými prostředky je velmi rychlé, protože se jedná o nejběžnější případ a byl optimalizován tak, aby dobře fungoval. Vzhledem k tomu, že tyto prostředky nejsou přímo přístupné procesorem, jsou optimalizované tak, aby s nimi GPU mohl rychle manipulovat.

Kopírování dat mezi mapovatelnými prostředky je problematické, protože výkon bude záviset na využití, se kterým byl prostředek vytvořen. Gpu může například číst dynamický prostředek poměrně rychle, ale nemůže do něj zapisovat a GPU nemůže číst ani zapisovat přímo do připravovaných zdrojů.

Aplikace, které chtějí kopírovat data z prostředku s výchozím využitím do prostředku s přípravným využitím (aby procesor mohl číst data – tj. problém se zpětným čtením GPU) to musí provést opatrně. Viz Přístup k datům prostředků, níže.

Přístup k prostředkovým datům

Přístup k prostředku vyžaduje mapování prostředku; mapování v podstatě znamená, že se aplikace snaží poskytnout procesoru přístup k paměti. Proces mapování prostředku tak, aby procesor měl přístup k podkladové paměti, může způsobit určité kritické body výkonu a z tohoto důvodu je potřeba vzít v úvahu, jak a kdy provést tuto úlohu.

Výkon se může úplně zastavit, pokud se tato aplikace pokusí namapovat prostředek v nesprávném čase. Pokud se aplikace pokusí získat přístup k výsledkům operace před dokončením této operace, dojde k zastavení pipeline.

Provedení operace mapování v nesprávné době může potenciálně způsobit závažný pokles výkonu vynucením GPU a synchronizace procesoru mezi sebou. K této synchronizaci dojde, pokud aplikace chce získat přístup k prostředku před tím, než GPU dokončí kopírování do prostředku, který procesor může mapovat.

Důležité informace o výkonu

Je nejlepší si představit počítač jako počítač běžící jako paralelní architekturu se dvěma hlavními typy procesorů: jeden nebo více procesorů a jeden nebo více GPU. Stejně jako v jakékoli paralelní architektuře je nejlepšího výkonu dosaženo, když je každý procesor naplánován s dostatečnými úlohami, aby se zabránilo nečinnosti a když práce jednoho procesoru nečeká na práci jiného.

Nejhorší scénář paralelismu GPU/CPU nastává, když je potřeba donutit jeden procesor, aby čekal na výsledky práce provedené jiným procesorem. Direct3D odstraňuje tyto náklady tím, že metody kopírování jsou asynchronní; kopie nemusí být nutně dokončena v době, kdy metoda vrátí výsledek.

Výhodou je, že aplikace neplatí náklady na výkon při skutečném kopírování dat, dokud procesor nepřistoupí k datům, což nastane při zavolání Map. Pokud je metoda Map volána po zkopírování dat, nedojde ke ztrátě výkonu. Na druhou stranu, pokud je metoda Map volána před zkopírováním dat, dojde k zárůstu latence potrubí.

Asynchronní volání v Direct3D (což je velká většina metod, a zejména volání vykreslování) jsou uložena v takzvané vyrovnávací paměti příkazů. Tato vyrovnávací paměť je interní součástí grafického ovladače a používá se k seskupenému volání podkladového hardwaru, aby nákladný přechod z uživatelského režimu do režimu jádra v systému Microsoft Windows probíhal co nejzřídka.

Příkazový buffer se vyprázdní, což způsobí přepnutí mezi uživatelským a jádrovým režimem v jedné ze čtyř následujících situací.

1. Je přítomnost potvrzena.
2. Volá se vyprazdnutí.
3. Příkazový buffer je plný; jeho velikost je nastavena dynamicky a je řízena operačním systémem a grafickým ovladačem.
4. Procesor vyžaduje přístup k výsledkům příkazu, který čeká na spuštění ve vyrovnávací paměti příkazů.

Ze čtyř výše uvedených situací je číslo čtyři nejdůležitější pro výkon. Pokud aplikace vydá volání ke zkopírování prostředku nebo podprostředku, toto volání se zařadí do příkazového bufferu.

Pokud se aplikace pokusí namapovat přípravný prostředek, který byl cílem volání kopírování před vyprázdněním vyrovnávací paměti příkazů, dojde k zastavení pipeline, protože nejenže musí být volání metody kopírování provedeno, ale musí být také provedeny všechny ostatní příkazy ve vyrovnávací paměti příkazů. Toto způsobí synchronizaci GPU a CPU, protože CPU bude čekat na přístup k přípravnému zdroji, zatímco GPU vyprázdní vyrovnávací paměť příkazů a nakonec naplní zdroj, který CPU potřebuje. Jakmile GPU dokončí kopírování, procesor začne přistupovat k přechodovému prostředku, ale během této doby bude GPU nečinné.

Pokud to uděláte často za běhu, výrazně snížíte výkon. Z tohoto důvodu by se mělo mapování prostředků vytvořených s výchozím využitím provádět opatrně. Aplikace musí počkat dostatečně dlouho, než se příkazový buffer vyprázdní, a proto musí všechny tyto příkazy dokončit provádění, než se pokusí namapovat odpovídající přípravný zdroj.

Jak dlouho má aplikace čekat? Alespoň dva snímky, protože to umožní maximální využití paralelismu mezi CPU a GPU. GPU funguje tak, že zatímco aplikace zpracovává rámec N odesláním volání do vyrovnávací paměti příkazů, GPU je zaneprázdněn prováděním volání z předchozího rámce N-1.

Takže pokud aplikace chce namapovat prostředek, který pochází z paměti videa a zkopíruje prostředek v rámci N, toto volání se ve skutečnosti začne spouštět v rámci N+1, když aplikace odesílá volání pro další snímek. Kopie by měla být dokončena, když aplikace zpracovává rámec N+2.

Rámec	Stav CPU a GPU
N	Problémy s procesorem ovlivňují vykreslování volání pro aktuální snímek.
N+1	GPU spouští volání odesílaná z procesoru během rámce N. Problémy s procesorem ovlivňují vykreslování volání pro aktuální snímek.
N+2	GPU dokončilo provádění volání odeslaných z procesoru během rámce N. Výsledky jsou připravené. GPU spouští volání odesílaná z procesoru během rámce N+1. Problémy s procesorem ovlivňují vykreslování volání pro aktuální snímek.
N+3	GPU dokončilo provádění volání odesílaných z procesoru během rámce N+1. Výsledky jsou připravené. GPU spouští volání odesílaná z procesoru během rámce N+2. Problémy s procesorem ovlivňují vykreslování volání pro aktuální snímek.
N+4	...

 

související témata

Prostředky