2. Fórumok
  3. Videokártyák
  4. AMD vs. INTEL vs. NVIDIA
Legfrissebb anyagok
Mobilarena témák
PROHARDVER! témák
IT café témák
GAMEPOD témák

Új hozzászólás Aktív témák

  • #32184 Abu85 HÁZIGAZDA
    Új Válasz #32184
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Abu85

    HÁZIGAZDA

    Először is érdemes tisztába tenni, hogy a konzolokon sem csak egy API van. PS4-en van libGNM és GNMX. Előbbi egy alacsony szintű megoldás, míg utóbbi egy wrapper erre, amivel egyszerű portolni a DX11-re írt játékokat. Az Xbox One-on még bonyolultabb a helyzet. Ott egy ideje elérhető a libGNM-nek az elvi megfelelője, ami a mono hozzáférés, emellett van még a szabványos DirectX 12 is. Ezekre nem épül wrapper helyette konkrétan a DirectX 11-nek egy módosítása van az egyszerű portolások érdekében. Ráadásul nem mindegy, hogy a program univerzális-e, mert ha nem direkten Xbox One API-jait használja, hanem az általános UWP-t, akkor a DirectX 12 és a mono API-k jelenleg el sem érhetők. Nyilván ez később változni fog, persze valószínűleg csak a DX12-re vonatkozóan, így a mono hozzáférés mindenképpen egyedi marad.

    Az, hogy megy játék melyik API-t használja döntés kérdése. A legcélszerűbb a libGNM a PS4 és a D12 az Xbox One/PC platformokra. Persze ettől eltérhetnek, ahogy el is térnek. A Wolf 2 például libGNM-et használ PS4-en, mono hozzáférést Xbox One-on, és Vulkan API-t PC-n, ezt használja majd Switchre is.

    Aki amúgy általánosabb motort használ, mint például UE4, annak szar a helyzete, mert csak a legújabb verziók igazán jók a konzolokon. Ezekre pedig sokan nem frissítenek, pedig PC-n is lényegesen gyorsabb lenne a program. A régebbi verziók még a konzolokon is a magasabb szintű API-kat használják.

    Az Ubisoft régebbi AC játékjai sem túl lényegesek, mert az Origintől használnak low-level hozzáférést a konzolokon. Előtte nem tették ezt. Az Origin viszont libGNM-et használ a PS4-en és mono hozzáférést az Xbox One-okon. Át is írták ennek megfelelően az AnvilNext bekötési struktúráját, ami immáron pure bindless, vagyis minden bekötés a CPU terhelése nélkül történik meg. PC-n ezt a különbséget egy wrapperrel hidalják át, így maga a motor a bekötést a CPU oldali API-t tartalmazó kiegészítéseken keresztül oldja meg a DirectX 11-es hardvereken, mert ugye ez az API ezt a modellt nem támogatja, így kell valami kompatibilitási réteg a program és az API közé.

    A látótávolság növelése sem igazán megoldás. Meg lehet csinálni, de nem ez az elsődleges célja annak, hogy az explicit API-k jelentősen csökkentették a többletterhelést. A helyzet az, hogy a látótávolság egy döntési tényező. Lehet úgy optimalizálni a tartalmat, hogy ez gyér legyen, de lehet úgy is, hogy igen messze el lehessen látni. És még nem is feltétlenül kell ehhez sok rajzolási parancs, elvégre vannak alkalmazható trükkök, például GPU-driven pipeline, stb.
    A rajzolási parancsok számának drasztikus emelése leginkább azért kellett, hogy értékelhető alternatívává váljanak azok a leképezőtechnológiák, amelyeket korábban csak offline alkalmaztak. A tiled/clustered forward/deferred ilyen-olyan optimalizálásokkal is rendkívül limitált. Egy vagy jobb esetben két kézen megszámolható a mai játékok döntő többségében a shadow casting fényforrások száma, holott ezek növelése kritikus lenne a grafikai minőség alapvető emeléséhez, és a kifejezetten sok hamis hatást keltő pixelfények redukálásához. Erre vannak már nem csak koncepciók, hanem létező leképezők, amelyek a texel shading valamilyen formáját használják, és nemhogy tucatnyi, hanem sok száz shadow casting fényforrással is megbirkóznak anélkül, hogy a mai hardverek, akár konzolok teljesítménye összeomlana, a megfelelő skálázódáshoz viszont mindenképpen olyan API kell, aminek a többletterhelése alacsony, így nem lesz majd limitáló a rajzolási parancsok rendszerint magas száma. És ez már egy olyan technika, ami letör olyan korlátokat, amelyek miatt ma képtelenség elérni például a WALL-E vagy a Brave grafikai szintjét, holott igazából a hardver ereje már nem lenne akkora probléma.
    Persze nem csak a texel shading az egyetlen lehetséges irány. A LABS-féle Deferred+ is ígéretes, de a texel shadingben hosszabb távon több a potenciál.

Új hozzászólás Aktív témák