Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
A felügyelt textúrák, más néven az automatikus textúrakezelés a 6-os verzió óta elérhetők a DirectX-ben, a későbbi kiadásokban számos változattal és fejlesztéssel. A Direct3D 9 API megjelenésekor az automatikus erőforrás-kezelés támogatja a textúrákat, a csúcspontpuffereket és az indexpuffereket, mindezt konzisztens megosztott felülettel. A Direct3D-erőforrás-kezelő használatával az alkalmazások jelentősen leegyszerűsíthetik az elveszett eszközökkel kapcsolatos helyzetek kezelését, és a rendszerre támaszkodhatnak a videomemória-erőforrások ésszerű mértékű túlzott elkötelezettségének kezelésére.
A fejlesztőknek néha nehézségekbe ütközik a felügyelt erőforrások használata, részben a rendszer absztrakciós jellege miatt. Bár az erőforrások számos gyakori forgatókönyve jó választás a felügyelt erőforrásokhoz, bizonyos esetekben jobban teljesít, ha nem felügyelt erőforrásokat használ. Ez a cikk az erőforrások általános kezelésének ajánlott eljárásait, a felügyelt és a nem felügyelt erőforrások viselkedését ismerteti, és részletesen ismerteti, hogyan kezelik az erőforrásokat általában a futtatókörnyezet és az illesztőprogramok.
Ez a cikk a következő fogalmakat ismerteti:
- videomemória
- felügyelt erőforrások
- Driver-Managed erőforrások
- alapértelmezett erőforrások
- rendszermemória-erőforrások
- általános javaslatok
- Kapcsolódó témakörök
Videomemória
Ahhoz, hogy a videorendszer egy erőforrást használjon, a GPU számára elérhető memóriában kell lennie. A helyi videomemória biztosítja a GPU legjobb teljesítményét, és bizonyos erőforrásoknak (például a renderelési céloknak és a mélységi/rajzsablonpuffereknek) a helyi videomemóriában kell lenniük. Az AGP megjelenésével a GPU közvetlenül is hozzáférhet a rendszermemória egy részéhez. Ezt az AGP-apertúrának nevezett memóriaterületet nem helyi videomemóriának nevezzük, és más célokra nem érhető el. A nem helyi videomemória olvasható és írható a CPU-ból, amely általában nem rendelkezik nagy teljesítményű hozzáféréssel a helyi videomemóriához, ezért ideális megosztott memóriaerőforrásként való használatra. Az AGP-memóriával kapcsolatban fontos megjegyezni, hogy a helyi videómemóriához hasonlóan az eszköz elveszett helyzetekben is érvénytelen, és az ott található állandó objektumokat vissza kell állítani.
1. ábra. A GPU, a CPU, a video RAM és a rendszer RAM kapcsolata
Egyes integrált videomegoldások egységes memóriaarchitektúrát (UMA) használnak, ahol a fő memória a rendszerek összes összetevője számára kezelhető. A Direct3D az alkalmazás módosítása nélkül támogatja az UMA-t, és ugyanazokat a tippeket használja, mint a helyi videomemória-konfigurációk esetében. Az ilyen rendszerek esetében az erőforrások mindig a rendszermemória részét képezik, és az illesztőprogram feladata, hogy az erőforrások ugyanúgy működjön, mint egy hagyományosabb architektúrában, miközben kihasználják az UMA tulajdonságait és a hardveres megvalósítás bármilyen sajátos viselkedését.
2. ábra. A GPU és a CPU egyenlő hozzáféréssel rendelkezik a rendszer RAM-hoz egységes memóriaarchitektúrában
Felügyelt erőforrások
Az erőforrások többségét felügyelt erőforrásként kell létrehozni POOL_MANAGED. A rendszer minden erőforrását a rendszermemóriában hozza létre, majd szükség szerint átmásolja a videomemóriába. Az elveszett eszközökkel kapcsolatos helyzeteket automatikusan kezeli a rendszer memóriamásolatából. Mivel nem minden felügyelt erőforrásra van szükség ahhoz, hogy egyszerre elférjen a videómemóriában, túlterhelheti a memóriát, ahol egy kisebb videomemória-munkaerőforrás-készlet szükséges minden adott keretben való megjelenítéshez. Vegye figyelembe, hogy valószínű, hogy a háttértár rendszer memória nagy része idővel lemezre kerül, ami miatt az Alaphelyzetbe állítási művelet lassú lehet, mert vissza kell tölteni ezeket az adatokat az elveszett videomemória visszaállításához.
A futtatókörnyezet megtartja az erőforrás utolsó használatakor használt időbélyeget, és ha a videómemória-lefoglalás nem sikerül betölteni egy szükséges felügyelt erőforrást, az erőforrásokat az adott időbélyeg alapján LRU módon fogja felszabadítni. A SetPriority használata elsőbbséget élvez az időbélyeggel szemben, ezért a gyakrabban használt erőforrásokat magasabb prioritási értékre kell állítani. A Direct3D 9.0 korlátozott információval rendelkezik az illesztőprogram által felügyelt videómemóriáról, ezért előfordulhat, hogy a futtatókörnyezetnek több erőforrást is ki kell kiürítenie ahhoz, hogy elég nagy régiót hozzon létre a foglalás sikerességéhez. A megfelelő prioritások segíthetnek kiküszöbölni azokat a helyzeteket, amikor valamit kiürítenek, majd röviddel később ismét szükség van rá. Az alkalmazás meghívhatja EvictManagedResources is, hogy kényszerítse az összes felügyelt erőforrás eltávolítását. Ez szintén időigényes művelet lehet a következő kerethez szükséges összes erőforrás újratöltéséhez, de nagyon hasznos olyan szintáttűnésekhez, ahol a munkakészlet jelentősen megváltozik, és eltávolítja a videomemória töredezettségét.
A keretszám azt is lehetővé teszi, hogy a futtatókörnyezet észlelje, hogy az imént kiürített erőforrást az aktuális keret korai szakaszában használták-e, ami olyan csonkoló helyzetet jelent, amikor több erőforrás van használatban egyetlen keretben, mint amennyi a videomemóriába illeszkedik. Ez aktiválja a csereszabályzatot, hogy a keret hátralévő részére az LRU helyett MRU módra váltson, mivel általában ezekben a körülmények között kissé jobb teljesítményt nyújt. Az ilyen daráló viselkedés jelentősen befolyásolja a renderelési teljesítményt. Vegye figyelembe, hogy az aktuális keret fogalma EndScenevan kötve, ezért a felügyelt erőforrásokat használó alkalmazásoknak rendszeres hívásokat kell indítaniuk ehhez a módszerhez.
Azok a fejlesztők, akik többet szeretnének megtudni arról, hogy a felügyelt erőforrások hogyan viselkednek az alkalmazásban, használhatják a RESOURCEMANAGER esemény lekérdezést az IDirect3DQuery9 felületen keresztül. Ez csak a hibakeresési futtatókörnyezetek használatakor működik, így ezektől az információktól az alkalmazás nem függhet, de részletes információkat nyújt a futtatókörnyezet által felügyelt erőforrásokról.
Bár az erőforrás-kezelő működésének megértése segíthet az alkalmazások finomhangolásában és hibakeresésében, fontos, hogy ne kösse túl szorosan az alkalmazást az aktuális futtatókörnyezet vagy illesztőprogramok implementálási részleteihez. Az illesztőprogram vagy a hardver változásai jelentősen megváltoztathatják a viselkedést, és a Direct3D jövőbeli verziói jelentősen továbbfejlesztett és kifinomult erőforrás-kezelést fognak eredményezni.
Driver-Managed erőforrások
A Direct3D-illesztőprogramok ingyenesen implementálják az illesztőprogram által felügyelt textúrák képességét, amelyet a D3DCAPS2_CANMANAGERESOURCE jelez, amely lehetővé teszi, hogy az illesztőprogram a futtatókörnyezet helyett az erőforrás-kezelést kezelje. A funkciót megvalósító (ritka) illesztőprogram esetében az illesztőprogram erőforrás-kezelőjének pontos viselkedése nagy mértékben változhat, és a megvalósításuk módjáról az illesztőprogram gyártójánál kell érdeklődnie. Alternatív megoldásként biztosíthatja, hogy a futtatókörnyezet-kezelő mindig használatban legyen a D3DCREATE_DISABLE_DRIVER_MANAGEMENT megadásával az eszköz létrehozásakor.
Alapértelmezett erőforrások
Bár a felügyelt erőforrások egyszerűek, hatékonyak és könnyen használhatók, vannak olyan esetek, amikor a videomemória közvetlen használata előnyben részesíthető, vagy akár kötelező is. Ezek az erőforrások a POOL_DEFAULT kategóriában jönnek létre. Az ilyen erőforrások használata további bonyodalmakat okoz az alkalmazás számára. A kód szükséges ahhoz, hogy megbirkózzon az összes POOL_DEFAULT erőforrás elveszett eszközével, és figyelembe kell venni a teljesítményre vonatkozó szempontokat az adatok bemásolásakor. A USAGE_WRITEONLY megadásának vagy a renderelési cél zárolhatóvá tételének elmulasztása súlyos teljesítménybeli szankciókat is vonhat maga után.
Az POOL_DEFAULT-erőforrás zárolási hívása nagyobb valószínűséggel okozza, hogy a GPU elakad, mint egy POOL_MANAGED erőforrás használata, kivéve, ha bizonyos tippjelölőket használ. Az erőforrás helyétől függően a visszaadott mutató mutathat ideiglenes rendszermemória-pufferhez, vagy közvetlenül az AGP-memóriába. Ha ideiglenes rendszermemória-pufferről van szó, az adatokat a hívás feloldása után át kell vinni a videomemóriabe. Ha a videoerőforrás nem csak írható, az adatokat át kell helyezni az ideiglenes pufferbe a zárolása során. Ha AGP-memóriaterületről van szó, a rendszer elkerüli az ideiglenes másolatokat, de a szükséges gyorsítótár-működés lassú teljesítményt eredményezhet.
Ügyelni kell arra, hogy a teljes gyorsítótár sor adatai beíródjanak az AGP-rekeszi memóriába, hogy elkerüljük az íráskombinációs művelet büntetését, ami olvasási-írási ciklust eredményez, továbbá előnyben kell részesíteni a memóriaterület szekvenciális elérését. Ha az alkalmazásnak véletlenszerűen kell hozzáférnie az adatokhoz a létrehozás során, és nem szeretne felügyelt erőforrást használni a pufferhez, akkor inkább egy rendszermemória-másolattal kell dolgoznia. Az adatok létrehozása után az eredményt streamelheti a zárolt erőforrásmemóriába, hogy ne kelljen nagy büntetést fizetnie a gyorsítótár írás-egyesítési műveletéért.
A LOCK_NOOVERWRITE jelző használatával egyes erőforrásokhoz hatékonyan fűzhet hozzá adatokat, de ideális esetben elkerülhetők egyazon erőforráshoz intézendő többszöri Zárolás és Feloldás hívások. A különböző zárolási jelzők megfelelő használata fontos az optimális teljesítmény érdekében, ahogyan az adathozzáférés gyorsítótárbarát mintájának használata is a zárolt memória betöltésekor.
Felügyelt és alapértelmezett erőforrások használata
A felügyelt és POOL_DEFAULT erőforrások lefoglalásának keverése a videomemória töredezettségét okozhatja, és megzavarhatja a futtatókörnyezet által a felügyelt erőforrások számára elérhető videomemória nézetét. Ideális esetben az összes POOL_DEFAULT erőforrást létre kell hoznia, mielőtt POOL_MANAGED erőforrásokat használ, vagy a nem felügyelt erőforrások kiosztása előtt használja az EvictManagedResources hívást. Ne feledje, hogy a videómemóriában található POOL_DEFAULT összes foglalása az adott erőforrás élettartama alatt leköti a memóriát, és nem áll az erőforrás-kezelő vagy más célú felhasználás rendelkezésére.
Vegye figyelembe, hogy a Direct3D korábbi verzióitól eltérően a 9-es verzió futtatókörnyezete automatikusan kiürít néhány felügyelt erőforrást, mielőtt lemond a sikertelen, nem felügyelt erőforrás-foglalásról a videómemória hiánya miatt, de ez további töredezettséghez vezethet, és akár egy erőforrást is optimálisnak nem megfelelő helyre kényszeríthet (például statikus anyagmintával rendelkezik a nem helyi videomemória). A felügyelt erőforrások használata előtt célszerű az összes szükséges nem felügyelt erőforrást előre lefoglalni.
Dinamikus alapértelmezett erőforrások
A nagy gyakorisággal létrehozott és frissített adatoknak nincs szükségük a háttértárra, mivel az eszköz visszaállításakor minden információ újra létrejön. Az ilyen adatokat tipikusan a POOL_DEFAULT-ben hozzák létre, megadva a USAGE_DYNAMIC útmutatást, hogy a meghajtó optimalizálási döntéseket hozhasson az erőforrás elhelyezésekor, tudván, hogy gyakran lesznek frissítve. Ez általában azt jelenti, hogy az erőforrást nem helyi videomemóriába helyezi, így a GPU általában sokkal lassabban fér hozzá, mint a helyi videomemória. Az UMA-architektúrák esetében az illesztő kiválaszthat egy adott elhelyezést a dinamikus erőforrásokhoz a CPU írási hozzáféréséhez való optimalizáláshoz.
Ez a használat jellemző a szoftveres skinning megoldásokra és a CPU-alapú részecskerendszerekre, amelyek csúcs-/indexpuffereket töltenek ki, és a LOCK_DISCARD jelző biztosítja, hogy ne jöjjenek létre megakadások olyan esetekben, amikor az erőforrás még az előző képből van használatban. Ha ebben az esetben egy felügyelt erőforrást használna, frissítene egy rendszermemória-puffert, amelyet aztán átmásolnának a videomemóriába, majd csak egy-két képkockára használná a lecserélés előtt. A nem helyi videomemóriával rendelkező rendszerek esetében a többletmásolás a dinamikus minta megfelelő használatával megszűnik.
A standard textúrák nem zárolhatók, és csak UpdateSurface vagy UpdateTexturekeresztül frissíthetők. Egyes rendszerek támogatják a dinamikus textúrákat, amelyek zárolhatók, és használhatják a LOCK_DISCARD mintát, de az erőforrások használata előtt ellenőrizni kell a képességeket (D3DCAPS2_DYNAMICTEXTURES). A rendkívül dinamikus textúrák (videó vagy eljárás) esetén az alkalmazás megfelelő POOL_DEFAULT és POOL_SYSTEMMEM erőforrásokat hozhat létre, és UpdateTexturehasználatával kezelheti a videomemória-frissítéseket. A nagyon gyakori és részleges frissítések esetében valószínűleg az UpdateTexture paradigma a jobb választás.
Amennyire a dinamikus erőforrások hasznosak lehetnek, körültekintően tervezzen olyan rendszereket, amelyek nagy mértékben támaszkodnak a dinamikus beküldésre. A statikus erőforrásokat POOL_MANAGED kell elhelyezni a helyi videomemória megfelelő kihasználtságának biztosítása, valamint a korlátozott busz- és fő memória-sávszélesség hatékonyabb kihasználása érdekében. A félig statikus erőforrások esetében előfordulhat, hogy a helyi videómemóriára való alkalmankénti feltöltés költsége sokkal kisebb, mint a dinamikussá tétellel generált állandó buszforgalom.
Rendszermemória-erőforrások
Az erőforrások POOL_SYSTEMMEM is létrehozhatók. Bár a grafikus folyamat nem tudja használni őket, forrásként használhatók POOL_DEFAULT erőforrások frissítéséhez UpdateSurface vagy UpdateTexturehasználatával. A zárolási viselkedésük egyszerű, bár előfordulhatnak leállások, ha a korábban említett módszerek valamelyike használatban van.
Bár a rendszermemóriában találhatók, POOL_SYSTEMMEM erőforrások az eszközillesztő által támogatott formátumra és képességekre (például maximális méretre) korlátozódnak. A POOL_SCRATCH erőforrástípus a rendszermemória-erőforrás egy másik formája, amely a futtatókörnyezet által támogatott összes formátumot és képességet képes használni, de az eszköz nem tudja elérni. A Scratch erőforrások elsősorban a tartalomeszközök használatára szolgálnak.
3. ábra. Memóriaerőforrások a videó-RAM-ban, az AGP-rekeszben és a rendszer-RAM-ban
Általános javaslatok
Az erőforrás-kezelés technikai megvalósítási részleteinek helyes lekérése hosszú utat tesz meg az alkalmazás teljesítménycéljainak elérése felé. Az erőforrások Direct3D-ben való bemutatásának megtervezése és az adatok időben történő betöltése körüli architektúratervezés bonyolultabb feladat. Számos ajánlott eljárást ajánlunk az alkalmazással kapcsolatos döntések meghozatalakor:
- Az összes erőforrás előzetes feldolgozása. Az erőforrások költséges terhelés-konvertálására és optimalizálására támaszkodva a fejlesztés során kényelmes, de ez nagy teljesítményterhelést jelent a felhasználók számítógépein. Az előre feldolgozott erőforrások gyorsabban tölthetők be, gyorsabban használhatók, és lehetővé teszik, hogy kifinomult off-line munkát végezhessenek.
- Ne hozzon létre több erőforrást keretenként. A szükséges illesztőprogram-interakciók sorba állíthatják a CPU-t és a GPU-t, és az érintett műveletek erőforrásigényesek, mivel gyakran kernel váltásokat igényelnek. Több keretre bonthatja a létrehozást, vagy újra felhasználhatja az erőforrásokat anélkül, hogy létrehozták vagy felszabadítanák őket. Ideális esetben több képkockát kell várnia a nemrég rendereléshez használt erőforrások zárolása vagy felszabadítása előtt.
- A keret végén mindenképpen válassza le az összes erőforráscsatornát (vagyis a streamforrásokat, a textúraszinteket és az aktuális indexeket). Ezzel biztosíthatja, hogy az erőforrásokra mutató lógó hivatkozások el legyenek távolítva, mielőtt azok miatt az erőforrás-kezelő megtartaná azokat az erőforrásokat, amelyek valójában már nincsenek használatban.
- A textúrákhoz használjon tömörített formátumokat (például DXTn) mip-térképek használatával, és fontolja meg a textúra atlasz használatát. Ezek jelentősen csökkentik a sávszélességre vonatkozó követelményeket, és csökkenthetik az erőforrások teljes méretét, ezáltal hatékonyabbá téve őket.
- A geometria esetében használja az indexelt geometriát, mivel ez segít a csúcspuffer-erőforrások tömörítésében, és a modern videohardverek nagymértékben optimalizálva lesznek a csúcspontok újrafelhasználása köré. Programozható vertex-aranyozók használatával tömörítheti a csúcsinformációkat, és kibonthatja azokat a csúcsok feldolgozása során. Ez is segít csökkenteni a sávszélességre vonatkozó követelményeket, és hatékonyabbá teszi a csúcspontok puffererőforrásait.
- Kerülje az erőforrás-kezelés túlzott optimalizálását. Az illesztőprogramok, a hardverek és az operációs rendszer jövőbeli változatainak kompatibilitási problémái lehetnek, ha az alkalmazás túl nagy mértékben hangolódik egy különösen kombinációra. Mivel a legtöbb alkalmazás processzorhoz kötött, a drága CPU-alapú felügyelet általában több teljesítményproblémát okoz, mint amennyit megold.
Kapcsolódó témakörök