Hirdetés

  2. Fórumok
  3. Videokártyák
  4. AMD vs. INTEL vs. NVIDIA
Legfrissebb anyagok
Keresés

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

  • #21021 Abu85 HÁZIGAZDA gbors #21019
    Új Válasz #21021
    Ú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 gbors #21019 üzenetére

    Inkább az a kulcstényező, hogy vannak a leképezésnek nagyon tipikus problémái, amelyeknek ma már vannak megoldásai. A kérdés az, hogy a megoldásokat érdemes-e használni, vagy érdemes megtartani a problémákat mondván, hogy a játékosok már megszokták a shimmeringet. A Quantum Break úgy döntött, hogy a leképezőnél kezelik a shimmering jelenséget, így egy Full HD-s képkocka négy HD-s 4xMSAA-s képkocka temporális projekciója. Ennek az előnye a nuku shimmering, de hátránya, hogy mozis, elmosott hatást kelt, ami a máshoz szokott játékosoknak nem jön majd be. Ugyanakkor az nem technológiai gond, ez volt a dizájn szempontjából a célkitűzés. Sajnos jelenleg nincs olyan technológia, amely minden leképzésre vonatkozó vizuális problémát kezel, így vagy az egyik, vagy a másik halmazát fogja kezelni egy elgondolás.

    A CPU-limit kitolása minden program oldalán a legfontosabb szempont. Főleg azért, mert ma már nem egymagos processzorok vannak, hanem négy vagy több. Muszáj olyan API-t kínálni, amivel ezek a magok kihasználhatók. És ehhez kellenek az új API-k, mert a régi API-kkal a parancsátadás egy szálra volt korlátozva, ami akkor is erősen limitáló volt, ha a parancskreálás esetleg több szálon történt meg. Mivel a jövőben semmi esély arra, hogy hirtelen jönnek a 15-20 GHz-es egymagos procik, így a többszálú parancskreálás biztosítása egy kulcstényező ahhoz, hogy az eddigieknél több rajzolási parancsot adhassanak ki a fejlesztők. Az, hogy csökkent a többletterhelés is, egy olyan fejlesztés, amit érdemes volt bevállalni, mert úgysem lehetett megőrizni a kompatibilitást a korábbi API-kkal. Ilyen formában érdemes nagyot fejleszteni, hogy legyen muníció évek múlva is.
    Az aszinkorn compute jövője nem kérdéses. Mindegyik DX12 és Vulkan alkalmazás használja PC-n. Emellett ahogy nő a GPU-k bonyolultsága, annál több idle buborék keletkezne abból, hogy soros a pipeline-ok feldolgozása. Egy GPU mindig is heterogén rendszer volt, és az egységek számának növelésével a munkájuk összehangolásának hatékonysága csökken. Mondjuk egy GCN a 10 wavefront/CU SIMD-del el tud menni ~6000 shaderig, de ez az a határ, ami után már érdemes növelni a wavefrontok számát, és az nem lehetséges a jelenlegi memóriamodellel. Az NV már a Kepler óta warp limiten van, mert 64/MP-nél többet nem kezel a Fermi dizájn. ~4000 shaderig sem tudnak elmenni, mert hiába rakják bele a több shadert, az architektúra nem skálázódik tovább, ugyanis nem tudnak 128 warpot futtatni a jelenlegi memóriamodellel. Persze az Intelnél látjuk, hogy van olyan megoldás, mint mondjuk a gyorsítótárak hizlalása, de ez csak a probléma kezelése lenne mindkét oldalon, mintsem valós megoldás, mert eszi a tranzisztorokat. Ahogy megyünk számban az egyre nagyobb skálázódás felé, annál inkább kell az aszinkron compute, hogy a hardver egyáltalán skálázódjon. Nem viccből építették bele tehát az API-kba. Az persze igaz, hogy a gyártók az alaparchitektúrát tekintve más fejlődési fázisnál tartanak. Az AMD itt csak azért jó, mert az alapjuk 2012-es, míg az NV-é 2009-es, az Intelé pedig 2010-es. Ennek megfelelően az alapokat rendre 2008, 2005 és 2006 körül dolgozták ki. Az AMD-nek szerencséje volt, hogy belecsúsztak a 2007-es évbe, amikor rengeteg kutatás volt arról, hogy mi a jövő. Az NV és az Intel is láthatta ezt, de ekkor már késő volt, mert nem tudtak változtatni a fejlesztéseken. A Fermi módosítás például 2012-re tolta volna a megjelenést, ami ezen a piacon vállalhatatlan volt. Szóval amint lesz egy nagy váltás az NV-nél és az Intelnél, azonnal meglesz oldva a multiengine konstrukció hatékony támogatása.

    A Doom nyilván érdekes, de nem szabad elfelejteni, hogy amit mi szegmentálódásnak hívunk (AMD shader intrinsics és NVIDIA shader intrinsics), az a fejlesztők szemében egységesítés (GPUOpen a közös PC és a konzol kutatásokért). Ebben vitathatatlan szerepe van az explicit API-knak is, mert ahhoz, hogy a PC-re és a konzolokra közös legyen a fejlesztés minden szempontból közös lehetőségek kellenek, legyen az API, shader függvények, dokumentáció, stb.

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