2. Fórumok
  3. Videokártyák
  4. AMD vs. INTEL vs. NVIDIA

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

  • #29427 Abu85 HÁZIGAZDA cskamacska #29424
    Új Válasz #29427
    Ú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

    válasz cskamacska #29424 üzenetére

    A Vulkan aktuális, és igazából a startra felhasználható verziója nem tud mindent, ami kell. Például nincs benne multi-GPU, míg a DX12-ben van. Emellett hasznos, ha van egy alternatív API-d. Igazából csak két back-end kell a motorba. A teljes költséghez képest ez elhanyagolható költség és számos előnnyel jár, hiszen kapásból kedvezőbb döntéshelyzeteket teremt, hogy xy játékba melyiket aktivált (opcionálisan akár mindkettőt).

    A Unity-ben már van Vulkan és DX12 is. Főleg a Vulkan leképező, ami jól áll.
    Az Epic a SIGGRAPH-on beszélt erről. A Vulkan elég jól áll a 4.17-es verzióban. Már az SM5-ös leképező és RHI (ez a layer, ami a motor és az API között van) az alapértelmezett a Vulkan desktop implementációihoz. Lényegében mindent tud, amit a DX11-es verzió, csak pár apró effekt hiányzik, amit később hozzáadnak. De a rendszer stabil és működik. Hamarosan ez lesz Linuxon a default RHI az OpenGL 4.3 helyett. Windowson még marad a DX11 és a DX12, de később ki tudja.
    Azt is elmondták, hogy a következő időszakban optimalizálják a bekötéseket és párhuzamosítják az RHI-t. A GPU oldalon a még hiányzó effekteket pótolják, majd nekimennek a motor optimalizálásának a Radeon GPU Profilerrel és a RenderDoc párosával. Ehhez Sweeney már kapott egy saját Vegát, és úton a többi is. Ezek most a prioritások.

    Az async compute-ot tudja, csak egy időre kikerült, mert furcsán viselkedett, de aztán készült hozzá egy másik implementáció, amivel újra visszakerült.
    A mostani DX12 játékok leginkább semmit nem használnak a nagyobb feature_levelekből. A hardverek a bekötési szintjüknek megfelelően dolgoznak, de igazából sok esetben a motor bekötési modellje még mindig a DX11-hez illeszkedik.
    A következő lépés a DX12 bekötési modelljéhez való illeszkedés. Ez az, ami most történik a motorokban. Ezzel kihasználásra kerülnek a resource binding és a resource heap fícsőrök. A resource bindingről eléggé sokat beszéltünk, és ismert az is, hogy mi a különbség a Tier szintjei között. Megjegyzem, hogy belinkelt képen lévő táblázat tuti hibás, mert ha Tier3-as a resource binding szint, akkor nem lehet fix értékben meghatározni az UAV slotok számát. Mindenképpen a teljes halmaz lesz felhasználható, vagyis akár egymillió. Ha a hardvert nem készítették fel erre, akkor ezt emulálni kell a videomemóriában, de Tier3-as visszatéréssel ez nem korlátozható.
    A resource heapről kevésbé beszéltünk. De ennek is van két szintje. Röviden a fícsőr több típusra kategorizálja az erőforrásokat. A Tier1 szinten az alkalmazás csak olyan halmazokat hozhat létre, ahol a flagek csak egy kategóriába sorolt típust engednek használni. Tier2 szinten értelemszerűen olyan halmazok is létrehozhatók, ahol a flagek megengedik az összes típus használatát. Utóbbival hatékonyabban működtethető a hardver. Ennyi.
    Feature_Levelből 11_1-re ugrunk, mert ez minimum szükséges a DX12 bekötési modelljének optimális használatához. Bizonyos motorok ugorhatnak 12_0-ra, leginkább a shader modell 6 miatt.

    A ROVs lehet potenciálisan probléma, de ez a Vegát leszámítva rendkívül lassú minden eddig megjelent dedikált GPU-n. Az Intel IGP-in gyors még, azokból csak a nyers erő hiányzik. Főleg emiatt nem használták eddig a DX12-ből ezt a képességet. Valamit támogatni nem minden, a teljesítményt is alá kell rakni. A hiányokat megtalálod az Intel Pixelsync játékok összehasonlító képeinél. Páran csináltak ilyet. A ROVs ugyanezt kínálja.
    A konzervatív raszterizálás iránt a legtöbben a GPU-s occlusion culling lehetősége miatt érdeklődnek. Ezt ma leginkább egy CPU-s feladat, de ezzel az újítással áttehető GPU-ra. Viszont ez mindenképpen igényli az inner input coverage funkciót, ami csak Tier3-as szinttől van, tehát ebből maximum csak sebességhátrány lehet, mert egy CPU-s occlusion cullingot úgyis megtartanak a motorokban fallbacknek. Ezt leginkább az Intel erőlteti, mert ők ebből sokat nyernének, és nyilván a Vega mellett az AMD-nek is érdeke lesz. Más hardveren nincs sok érdek mellette, mert nincs támogatva az inner input coverage. Opció lehet még használni a sub-pixel shadow map, ami értékes, és Tier1-től támogatható, illetve gyorsítható vele a mozaikos leképezés is. A Tier2 eléggé haszontalan szint önmagában, valószínűleg csak azért került be, mert az NV Pascal nem támogatta a inner input coverage-et, de képes volt arra, hogy ne vágja ki a degeneratív háromszögeket.

    Az FP16-ra nyilván az AMD nagyon rá fog feküdni, de ezzel igazából csak teljesítményt nyernek a GCN3/4/5-nek.

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