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

• #6264 Abu85 HÁZIGAZDA rocket #6256

  Új Válasz 2015-06-07 10:38:27 #6264

  Ú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 rocket #6256 üzenetére

  Valószínűtlen, hogy az AMD egy akkora rage-et akar a felhasználóktól a fórumon látni, mint amit most az NV kap. Emellett tényleg meg kell érteni, hogy tök logikátlan húzás lenne az AMD-től zárt middleware-ekt fejleszteni. Van a PC-n egy vezető iparági igény arra, hogy szabaduljunk meg a feketedobozoktól. Elsődlegesen az API szintjén és ebben az AMD vezető szerepet vállalat. Kidolgozták a lehetőségeket, hogy hogyan lehetne ezt megtenni, és a Microsoft és a Khronos ezt kisebb nagyobb mértékben átemelte, illetve még átemeli szabványba. Az AMD a PC iránt tényleg érdeklődő nagy stúdióktól folyamatosan azt hallja nem akarnak feketedobozt, de akarnak ISA dokumentációt, használható fejlesztőeszközöket, esetleg ISA disassemblert. Az NVIDIA is tudja ezt, azért annyira még nem távolodtak el ezektől a stúdióktól, hogy Johan Andersson, Daniel Baker, Joshua Barczak, John Kloetzli, Kevin Floyer-Lea, Emil Persson, Tiago Sousa, Masaru Ijuin, stb, lényegében az iparág keménymagjának a véleményét ne ismerjék arról, hogy mennyire nem akarnak feketedobozokat, ettől függetlenül az feketedobozt elimináló igényeikre újjabb feketedobozzal válaszoltak. Twitteren erről olvashatsz is tényleges PC-s fejlesztőktől véleményt: [link] Van köztük Timothy Lottes és Bart Wronski, anno az NVIDIA/Epic Games és az Ubisoftnál dolgoztak. Timothy már az AMD-nél van, míg Brat elment a Sony-hoz. Az Ubisoft esetében például fontos, hogy a technikai csapat magja Michal Drobottal az élen az elmúlt év végén kilépett, és ebben nagy szerepe volt ahhoz, hogy nevüket adták olyan projektekhez, amelyeket valójában nem tudta optimalizálni a sok-sok feketedoboz miatt, illetve alapvetően olyan irányokra kényszerítette őket az Ubisoft, amiről már helyből tudták, hogy nem fog működni, de azt kellett csinálniuk, mert a "hozzáértő" szakemberek a vezetőségben azt mondták, hogy jó lesz. Az NVIDIA is azt mondta nekik. Annyira jó lett, hogy még a GeometryWorksöt sem tudták integrálni, mert képtelenek voltak működésre bírni az egészet, tehát, amire felépült a projekt, hogy majd rajzolási parancsokat spórolnak a tesszellálással teljesen tévút volt. Ezért néz ki az AC: Unityben sok felület sokkal rosszabbul, mint az AC: Black Flagben. Főleg a tetők. Úgy volt tervezve, hogy lesz tesszellálás, de nem működött a zárt middleware-en keresztül. Ezért éri meg a vezetőségnek a döntéseit a technikai csoport véleményére hagyatkozva meghozni, mert ők ismerik a motort, míg például egy külső cég nem. Aztán persze ígérni sok dolgot lehet, majd azok 90%-a a játék kiadásáig nem fog teljesülni. Ezért is volt az Ubisoftnál az elmúlt évben ez a sok downgrade botrány, mert hiába akarsz egy grafikai szintet, ha az zárt effekteket nem tudod működésre bírni. Egy dolog, hogy mit akarsz és mi valósítható meg. CD Projekt is ezzel küzdött. Elgondolták, hogy majd beimplementáljuk a middleware-eket, aztán, ahogy jöttek a middleware-ek sorban derült ki, hogy hát ez ezzel nem kompatibilis, akkor ezt jó lenne átírni a motorban, akkor ezt az effektet így bukjuk, stb. A végére elfogyott az idő, még a megjelenés csúszásával is, és jött a downgrade, mert hiába terveztek dolgokat feketedobozokkal valójában mindig nagyon nehéz dolgozni. Nem a fejlesztőn múlik, hogy valami megvalósítható-e. Ezért látod 2015-ben azt a vezető irányt, hogy egyre több middleware-t nyitnak meg. Annyira komplex lett az egész, hogy sok esetben másképp nem lehet biztosítani a működést, downgrade-et pedig senki sem akar.
  Még, ha az AMD-nek ugyanaz meg is fordul a fejében, hogy valahogy mesterségesen érdemes lenne visszafogni az előző generációt, hogy az új jobbnak tűnjön, alapvetően az egyetlen lehetőség erre tényleg egy GameWorks-féle stratégia. De az a hátrány, amit ez ad a fejlesztőknek a sok beláthatatlan downgrade-del a megjelent játékokon, sokkal jobban árt a PC-nek hosszútávon, mint amekkora előnyt jelent az adott időszakban az eladásokban. A konzolok ilyen irány mellett előnybe kerülnek, mert hiába van bennük egy csúcs-PC-hez képest korlátozott teljesítmény, akkor is az előny, hogy amit elgondol a fejlesztő azt képes megcsinálni, míg feketedobozok mellett ez sok esetben nem sikerül. Mindegy, hogy hogyan kommunikálód le a downgrade-et, elmondod nekik, hogy használhatatlan zárt effekteket kaptál, vagy kitalálsz valami kíméletes hazugságot, maga a grafika leépítése megtörtént, és a PC-s játékos szomorú lesz.
  És alapvetően az a gond, hogy nem a valós problémáról beszél az ipar. Mert a GameWorks esetében az, hogy xy hardveren rosszul fut, nem valós probléma, kapcsold ki és kész, vagy iktasd ki driverben a teljesítményzabáló részeit. Az a gond, hogy teljesen értelmetlen fejlesztési modellt kényszerít ki, és a végére rengeteg terv nem fog megvalósulni. Egyszerűen egy építésznek is baromira nehéz lesz a munkája, ha azt várják el tőle, hogy egy kész tető alá építsen egy házat. Kvázi ezt várja el a GameWorks a fejlesztőktől. És akkor csodálkozunk, hogy a megjelenés előtti bemutatókon a játék sokkal szebb volt, mint ami végül megjelent? Ez a valódi problémája a feketedobozoknak. Minden formájuknak. Mindenki döntse el magában, hogy ez jó-e a PC-nek vagy sem.

  Nem tudom pontosan, hogy mik lesznek az extrák. Vagy több sebesség, vagy több effekt. Két dolgot tudok a fejlesztőktől, hogy a DX12-ből két számukra fontos dolog hiányzik, ami megvan a Mantle-ben. Az LDS tartalmának korlát nélküli olvasása, és a GDS korlát nélküli használata. Ezeket használni fogják konzolon, sőt, már használják is, így az erre épített effektek átmenthetők. Például az Ubisoft HRAA élsimítása az LDS korlát nélküli olvasására épül. Gyakorlatilag PC-re a konzolon alkalmazott AEAA konstrukcióval csak Mantle-re menthető át.

  A DX12-ből négy vezető kihasználású funkció lesz, amelyet gyakorlatilag mindenki bevet. A Typed UAV loads, az aszinkron DMA, az aszinkron compute és a multiadapter valamilyen formája. Az első hármat azért alkalmazzák a fejlesztők, mert összességében konzolon 40-70%-os extra sebességet is hozhat, és a kód gyakorlatilag módosítás nélkül átmenthető PC-re, ahol ugyanennyi előnyt fog kínálni. A multiadapter PC-s dolog, de annyira egyszerű használni, hogy legalább az IGP+dGPU rendszerekre lesz valamilyen implementáció. Azok annyira elterjedtek a világban, hogy megéri velük foglalkozni.

  A tesszelláció kapcsán ha megnézed a vezető irány a fixfunckiós blokk elhagyása. Ez hardverben megmarad, de például a LORE motor már compute shadert használ a háromszögek felbontására. Az eredmény az, hogy jobb lesz a minőség és gyorsul tőle a program. Több motor is átvált a jövőben szoftveres tesszellálásra, mert a fejlesztők jobb minőséget akarnak nagyobb sebességgel, és erre a fixfunkciós blokk korlátozottan alkalmas.

  (#6258) Szaby59: Kettő, de nem a szám lényeges, hanem az, hogy megtörténik.

  Többször mondtam, hogy a Dragon Age: Inquisition DX11 kódja nem stabil. Az EA support hivatalosan a Mantle kódot ajánlja. Ezért van beépítve. A DX11 kód sosem lesz teljesen stabil a mutex zárolásaival. Nagyon nem véletlen, hogy a Microsoft ezeket a technikákat nem ajánlja implementálni, függetlenül attól, hogy lehetséges. Sajnálom, de ez van. A következő körben már mindenki kap low-level támogatást.

  (#6259) huskydog17: A Capcom a Panta Rhei motort fogja később használni mindenre. Ma még nem létezik PC-s portja, mert DX11-re kvázi portolhatatlan, de később meg lesz oldva.

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