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

• #39486 Abu85 HÁZIGAZDA huskydog17 #39475

  Új Válasz 2019-04-20 20:55:55 #39486

  Ú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 huskydog17 #39475 üzenetére

  Azért én használom, mert lényegesen jobb, mint a DX11-es leképező. Igaz 4 GB VRAM miatt nem tudok maximális textúrával menni, de csak abból kell visszavenni, és sokkal jobb sebességet kapok Vulkan alatt.

  Én Vulkanon is azt látom, hogy jó minden. Igaz GeForce-szal még nem próbáltam. Annyi van, hogy van egy másfél-két perces periódus, amin át kell esni az akadásokat tekintve, és utána nincs egy szál se. Ez minden programindításnál így van, de két perc alatt megszűnik. Kivéve max grafikán, ott sajna kevés a 4 GB VRAM. De ez van, DX11 alatt is kevés.

  Abszolút nem fut szarul, ha a 19.4.2-es meghajtótól használod. Én már egy újabbat használok, de az még béta, van nem kevés egyéb problémája, viszont még a 19.4.2-nél is újabb a Vulkan implementáció, és a WWZ-ben úgy kb. még gyorsul 5-10%-kal.

  Amikor olyan újításokat használ egy program, mint mondjuk a subgroup arra azért nehéz tökéletes drivert csinálni a startra. Az AMD a saját meghajtóit a saját kiterjesztéseire írta, de ezek ugye eleve nem szabványos shaderek a program oldalán, tehát csak AMD-re tesztelik őket, és nyilván egy gyártóra jól lehet ezeket optimalizálni. A WWZ már nem használ gyártónként eltérő shadereket, hanem szimplán a subgroup függvényeket hívja meg, amely szabványos megoldás, viszont így már nem tudsz a shaderből nagyon gyártóspecifikus lenni, vagyis figyelembe kell venni az AMD mellett az NV-t és az Intelt is. Ezeket a shadereket viszont nem teljesen úgy kell fordítani, mint a régieket, mert régebben az történt, hogy egy shader a GPU-n csak egy szállal futottak. Itt a szál nem ugyanaz, mint a CPU-nál, inkább lane-nek szokás hívni, de a lényeg az volt, hogy csak a lane volt definiálva program szintjén, miközben a GPU-k szálszintű párhozamosságra tervezett megoldások, vagyis alapvetően képesek arra, hogy több lane-t futtassanak egy wave-ben (a wave-et a Vulkan subgroupnak hívnak, igazából mindegy a név). Tehát a legacy shadereknél a GPU-k még nem mondták meg az alkalmazás felé, hogy egy waveben/subgroupban hány lane-t képesek futtatni párhuzamosan, vagyis a shader fordító nem tudott más tenni, mint logikailag egy lane-re fordítani, és utána összefűzni a munkákat. Ez viszont nem igazán hatékony, mert a meghajtó számára nincs túl nagy mozgástér arra vonatkozóan, hogy egy shadert milyen GPU ISA-hoz közeli kóddá fordít. Ezért vezetik be az újabb nyelvek a szálszintű párhuzamosságot. Ezt ugyan az AMD már jó ideje elérhetővé teszi kiterjesztésekkel, de mint írtam, ilyenkor a fejlesztőknek specifikus shadert kellett írni AMD-re, aminek vannak karbantartási költségei is. Persze akkora gond ez nem volt, mert az AMD kiterjesztései gyakorlatilag úgy lettek megírva, hogy kis módosítással megegyék a PS4 kódjait, tehát akkora munka ebből így sem volt, viszont egyrészt a karbantartás így is költség, másrészt ezekkel a kódokkal az NVIDIA és az Intel semmit se tudott kezdeni. A szabványos megoldás ugyan picit kevesebbet tud, mint az AMD-é, pár függvény hiányzik belőle, de ezeket amúgy sem használták annyira, illetve a szabványosság nagy előnye, hogy az Intel és az NVIDIA is célozható. Viszont annyira más shader fordítót igényel, hogy elég sok munkát újra kell kezdeni, ugyanis már logikailag több lane-re kell fordítani, mivel a korábbi szálszinten soros feldolgozást felváltotta a szálszinten párhuzamos (a szál itt megint inkább lane-t jelent). Emiatt hiába írtak a gyártók akármilyen hatékony shader fordítót az elmúlt években, azt a know-how-t nagyrészt dobhatják ki, mert teljesen más fordító kell erre az új modellre. Az AMD is a saját kiterjesztéseihez írt fordító módosítását használja, míg az Intel és az NVIDIA számára ez nagyon új terület, ők nem igazán foglalkoztak ezzel a kérdéssel kiterjesztés szintjén, tehát nem sok tapasztaltuk van arról, hogy mi az optimális. Az AMD-nek pedig hiába van itt tapasztalata, más szabványos shaderről fordítani, illetve olyan shaderről, aminél a kiterjesztés specifikációját te magad írtad. Tehát ezzel nekik is lesz munka, csak némileg jobb teljesítményszintről indulnak a GPUOpen intrinsics miatt.

  Egyébként valakinek mindig kell lennie elsőnek. A Doom amikor elsőként bevetette a Vulkan API-t, ugyanígy csak az AMD-nek kedvezett, mert akkoriban az NV drivere sokszor OpenGL alól hívogatta a Vulkan API-t, az meg persze, hogy nem gyors. A Doomnak persze probléma volt az allokációval is, de arra ugye jött egy NV kiterjesztés (NV_dedicated_allocation), amiből később szabvány (VK_KHR_dedicated_allocation) lett. Itt a Khronos Group nagyon sok dolgot csak átmásolt a Mantle-ből, aztán túl későn derült ki, hogy ez nem jól mappelhető GeForce-ra, és ezt az előbb említett kiterjesztéssel korrigálták. De akkor is a Doom az első Vulkan cím volt, és az első problémába bele is futott, pedig nem a Doom leképezőjével volt a gond, hanem csak azzal, hogy úttörők voltak, és az úttörők találják meg az adott ökoszisztéma gondjait is. De aztán jöttek az új NV driverek, és elkezdett gyorsulni a játék. Eltelt a megjelenéstől nagyjából egy év, és elég szépen teljesítettek a GeForce-ok is. Most a WWZ fejlesztői bevetették a subgroupot. Bevállalták az úttörő szerepet, és mint mindig beleütköztek a problémákba. Ettől a Vulkan implementációjukkal, ugyanúgy nincs gond, ahogy a Doomnak se volt, de a driverek nem állnak készen. De ettől az NV nyilván meg fogja írni jól a fordítót. Ezen eleinte elég sokat is lehet javítani. Lehet, hogy beletelik négy-öt hónapba, de ugyanúgy meglesz a támogatás, ahogy a Doomnál, mert nem ez az utolsó játék idén, ami subgroupot használ. Például a Quantic Dream is subgroupra tudja portolni a PS4 intrinsics függvényeit. Más lehetőségük nem igazán van, mert az AMD SPIR-V kiterjesztései csak Radeonon működnek.

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