-
Fototrend
A legtöbb kérdésre (igen, talán arra is amit éppen feltenni készülsz) már jó eséllyel megtalálható a válasz valahol a topikban. Mielőtt írnál, lapozz vagy tekerj kicsit visszább, és/vagy használd bátran a keresőt a kérdésed kulcsszavaival!
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Erről beszélnek kb. jó ideje a fejlesztők. Hiába nő a teljesítmény, ha ahhoz nem lehet hozzányúlni, mert valami megakadályozza. A DX API akadályozza meg ezt alapból, de ez a probléma többszintű, mert a DX API nem lenne annyira korlátozó tényező, ha a mai grafikus driverek úgy működnének, mint három éve, csak akkor meg a grafikát kellene lebutítani. Régebben nem igazán törődtek azzal a fejlesztők, hogy mik a grafikus driver igényei. Ma ezek annyira máshogy működnek, hogy követni kell a gyártók ajánlásait, mert más irányból megközelítve rossz lesz az eredmény. Főleg az NVIDIA ajánlásait érdemes követni, mert a GeForce driver nagyon agresszívan kisajátítja az erőforrást, így ha DC mellett nem kap három, illetve IC mellett kettő magot, amihez a program onnantól kezdve hozzá sem nyúl, akkor sok esetben káros lesz a sebességre és a stabilitásra a driver működése. Persze ezt nem minden modern motor követi, például a Frostbite 3 csak egy magot ad a drivereknek, és azért éri el így is azt a jó teljesítményt, amit tud, mert minden lehetséges módon megakadályozza a drivert abban, hogy elvégezze a feladatának egy részét. Azt a részét, amelyet amúgy a Frostbite már elvégzett, tehát felesleges lenne még egyszer erőforrást pazarolni rá. A Frostbite 3 ma az egyetlen motor, amely például DX11 alatt az állapotváltások szűrését csak egyszer futtatja, és azután a rendszer elzárja az adatokat a DX API és a driver elől, hogy az a programszál, amely arra létrejött ne futtasson több szűrést ezeken. A driver szimplán várakozásra van kényszerítve, és addig vár az adatra, amíg a program fut. Nem elegáns megoldás, mert ez a várakozás programfagyást eredményezhet (sőt egyszer biztosan fagyni fog, de kb. 20 óra után, ameddig nem sok ember játszik egyhuzamban). A BF4-nél vagy a PvsZ:GW-nél a DX11-es kód igen sokáig bírja anélkül, hogy a Frostbite 3 driver működését akadályozó modulja device hung hibát eredményezne, amivel ugye kilépne a program. A DA Inquisition az ellenpélda. Ott DX11 alatt sajnos igen sűrű a fagyás. Jelenleg 15% az esélye, hogy a program egy óra játék után device hungot dob és kilép. Ezen nagyon dolgoznak a fejlesztők, mert ez sokkal rosszabb arány, mint ahogy a korábbi játékok működtek, igaz azok nem a legújabb Frostbite 3-at kapták meg.
Felelősöket nem érdemes keresni, mert a probléma többszintű. A legtöbb fejlesztő az új grafikus driverek agresszív erőforrásigényét nevezik meg problémaként, de valójában az, hogy ma öt-hét szálat simán futtat egy driver annak az eredménye, hogy a DX11 2000 batch/frame-es limitjét nem teljesítik a fejlesztők, tehát az NV-nek és az AMD-nek sincs igazából sok választása, valamilyen módon meg kell oldani, hogy meglegyen a 3000-5000 batch/frame-re is a teljesítmény. Nehéz azt mondani a fejlesztőknek, hogy márpedig butítsátok le úgy a PC-s port grafikáját, hogy beférjen a DX11 limitjébe. Saját maguknak ásnák a sírt, ha ezt mondanák a PC-ből élő gyártók, mert a konzolon ezt nem kell megtenni. Szóval a probléma alapja egyértelműen a DX11, amely képtelen kompromisszumok nélkül kiszolgálni a fejlesztők igényeit.
Jelenleg nagyjából három opció van a fejlesztők előtt DX11-re:
- betartani a DX11 limitjeit, így maga az API optimálisan működik, tehát viszonylag sok erőforrás marad a szimulációra, de cserébe a grafikát a konzolos szint alá kell belőni
- túllépni a DX11 limitjeit, így a drivernek rengeteg magot adni, hogy egyáltalán optimálisan működjön, azaz hozható legyen a konzolos grafikai szint, cserébe a szimulációra nem lesz több erőforrásod, mint amennyi tíz éve rendelkezésre állt, sőt, lehet, hogy kevesebbel kell kalkulálni
- kidolgozni egy olyan rendszert a motorba, amely nem engedi a grafikus drivert működni, így sokkal optimálisabban lehet a hardver kihasználása és grafikai butítás nélkül is lehetőség lesz több erőforrást kinyerni a szimulációra, cserébe nem lesz stabil a program, illetve egy ilyen rendszert csak a leggazdagabb fejlesztők engedhetnek meg maguknak, mert extrém mértékű tesztelést igényel
És igen, az utolsó pontot fel lehet úgy fogni, hogy csak pénz kérdése a dolog, de valójában cseppet sem optimális az, hogy meghúzol egy határt, hogy mennyi potenciális fagyást tekintesz még elfogadhatónak. Hidd el pont annyira káros a PC-s játékosoknak, hogy DX11-ben 15% az esélye annak, hogy az új Dragon Age lefagy egy óra alatt, mintha lebutították volna a grafikát.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nagyon nehéz meghúzni azt a határt, ahol a driver már káros hatásokat fejt ki. Önmagában nagyon egyszerű a helyzet, hogy a DX11-ben 2000 batch/frame a limit és azt nem kellene túllépni. De túllépjük, és minden problémának ez az alapja. Teoretikusan levezetve rengeteg lehetőség van arra, hogy a driver az elérhető processzoridőt valamilyen módon hasznosítsa. Az egyik a flip-queue mérete, amivel előre több jelenet lesz felkötegelve és így nő a GPU kihasználtsága. A másik a single queue/multiple queue modell. Utóbbi növeli a GPU kihasználást, olyan compute feldolgozás mellett, ahol az adott motor még elavult puffermenedzselési modellre épül. A valós idejű shader fordítás is egy optimalizálási terep. Gyorsan gyors kódot nem lehet fordítani. Szóval meg kell találni az optimális értéket, vagy bevállalni, hogy sok processzoridőt vesz igénybe a valós idejű shader fordítás. És milliónyi apróbb optimalizálási terület van, ahol azt kell mérlegelni, hogy mi az a processzoridő, amit a driver elvehet, ugyanis ez drámaian csökkenti a program által elérhető, szimulációra használható processzoridőt.
Arra Daniel Baker már 2010-ben felhívta a figyelmet, hogy a grafikus driverek pár év múlva túlzott processzorigényekkel fognak rendelkezni, és borzalmasan nehéz lesz kinyerni a legújabb processzorokból is azt a processzoridőt, ami egy évtizede elérhető volt, vagyis a PC azért, hogy a grafika szinten tarthassa magát, a játékmenetbeli butításokkal fog fizetni. És a helyzet az, hogy pokolian igaza lett, mivel ma mindenki arról beszél, hogy nem lehet befogni a gyors processzorok teljesítményét, és közvetve ennek az az oka, hogy a driverek elveszik a processzoridőt a program elől. A mennyit az kérdéses. Én ebből a szempontból a Microsofttal értek egyet. A DX11-nek megvannak maga a korlátjai, és azon belül kell maradni. E korlátok kiterjesztése lehetséges, az MS sem tagadja, de drámaian csökken a program által felhasználható processzoridő is.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Akkor sem szartak rá, de nem nehéz meglátni az időpontok összefüggéseit. A FEAR 2005-ös. Tekintsük úgy, hogy ahhoz hasonló AI van a mai PC-s játékokban is (most ne számítsuk a picit jobb-picit rosszabb dolgokat, a konzolt meg pláne, mert ott jelentősen jobb AI is létezik). Ha Daniel Baker API-s előadásait megtekinted (amit ajánlok, mert ő az egyetlen játékfejlesztő, aki GAB tag, és iszonyatosan nagy rálátása van az egészre, hiszen ő maga is részt vesz a DirectX fejlesztésében), akkor láthatod, hogy szinte mindig elmondja a saját hipotézisét, hogy szerinte mi csúszott félre. Ezt az alábbi ábrán jól prezentálja:
Ugye a narancs a GPU-k teljesítménye a GFLOPS oszlophoz mérve. A piros a batch teljesítmény a Batch/Frame oszlophoz mérve, ami a driverekből jön/jött, míg a szaggatott vonal a terv, ami nem jött be.
És az egész pont az általad megjelölt 2007-2008 körül kezdődött, amikor a több mag elkezdett terjedni.
És itt tartunk most:
Az a kis kék rész maga a program, és az elméleti processzoridő pár százalékán fut, a maradék "Unused CPU Time" pedig azért van piros csíkokkal lesatírozva, mert nem lehet hozzáférni. A DirectX 11 és az API-hoz készült mai modern driverek nem teszik elérhetővé. Programozóként láthatod a profilozóban, de nincs semmilyen mód, hogy hozzányúlj ehhez az elméletben szabad processzoridőhöz.
Ezek után mondhatjuk azt, hogy a fejlesztők a bénák, és ezért nincs fejlődés, de valójában igazságtalanok vagyunk velük, mert ők a DX11-gyel jelenleg egy olyan programozási modellre kényszerülnek, amellyel az elméletben elérhető erőforrások nagy része elérhetetlen.
Ezt Daniel Baker bizonyította az alábbi képpel, hogy ne csak a levegőbe beszéljen:
Látható, hogy egy alpha kóddal is képes használatba venni az elméletben elérhető processzoridő ~50%-át, de ehhez nem a DX11-et, hanem a Mantle-t használta. Ezzel bebizonyította, amit sokan sejtettek, hogy a probléma forrása a DX11 és a hozzá tartozó modern driverek.
És amikor a lustaságról beszélünk, akkor vegyük figyelembe, hogy Daniel Baker már elérte a 85%-os kihasználást is az új motorverziókkal, ugyanis zölddel van jelölve az az "Unused CPU Time" rész a képen, vagyis optimalizálással a gyakorlatban is hozzáférhető, és a nagy részét már hasznosította is. Nehéz azt mondani rá, hogy lustaság miatt nem csinálja ezt meg a DX11 alatt. Főleg úgy, hogy a Nitrous, vagyis a saját motorja sokkal hatékonyabban működik DX11 alatt, mint akármelyik más fejlesztő motorja. Kvázi ő az egyetlen programozó a világon, aki nagymértékben optimalizál DX11-re.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
#1 2007-ben kezdtek el normálisan terjedni a többmagos procik. Elsősorban kétmagosok. Viszont a program nem jutott több erőforráshoz ezekkel sem.
#2 2010 után annyi változott, hogy a grafika fejlődött, és a DX túl lett terhelve, tehát olyan driverek kellettek, amelyek a 2010 utáni grafikát is megjelenítik, vagyis még több erőforrást elvettek a programtól. Ez a folyamat tart máig. Összességében nincs több processzoridő a szimulációra, mint régen.Két tény: a fejlesztők azt mondják, hogy a probléma az API. A Microsoft nem konkrétan a DX11-et látja gondnak, hanem azt, hogy a fejlesztők túlterhelik, és a gyártók ehhez igazodnak a driverekkel. Ez is bőven igaz. Az API tud valamit, és ahhoz lehet butítani a grafikát, de ezt fentebb megbeszéltük, hogy miért nem jó a PC-s gyártóknak.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Bandi79
#8655
üzenetére
CA Engine a kódneve. Eléggé új generációs rendszer. Az meg, hogy jó ... Michael Bailey csinálta és Nicolas Thibieroz segített neki a gyártói oldalról. Ők ketten soha nem tettek le gyenge munkát az asztalra.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#8657
üzenetére
5-6 éve a seggünket csapkodtuk volna a földhöz ilyen minőségű GI és particle effektek, illetve anyagárnyalás láttán:
Azt a fény-árnyék kezelést, részecskerendszert és radiosity modellt, amit az Alien: Isolation használ, még több mai játéknak sem sikerült elérni. Persze no para, majd később más is megkapja azokat az effekteket, amelyeket ez a játék alkalmaz.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#8659
üzenetére
Igen. Játszottam már vele. Első osztályú a megvilágítási modell és a részecskerendszer. De ezt eddig is tudtuk, hiszen a fejlesztők már jó előre elmondták, hogy a legjobban implementálják, ami létezik és bevethető. Majd később a többiek is bedobnak valami hasonlót.
A Creative Assembly előnye, hogy ezt a motort a nulláról építették fel. Úgy választhatták össze a működéshez szolgáló komponenseket, ahogy azt jónak látták. Persze sok pénz volt, de amikor valami mindig a nulláról készül el, az előnyt élvez egy darabig, mert a többi motorba az új technikák nem feltétlenül építhetők be problémamentesen. Ez az oka annak, hogy ebben a motorban van most a legjobb indirekt fénykezelés és részecskerendszer. Egyedül a CryEngine közelít hozzá.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Melyik erőforrásért? Amit a driverek elvesznek? Szapulhatjuk a fejlesztőket, de valójában a többszálú feldolgozásra van egy olyan rendszerük a DX11-ben, amit ma már a Microsoft sem ajánl használatra, mert káros hatásai vannak. A problémára az elvi megoldás valóban a deferred context, ami viszont a gyakorlatban a programfejlesztők és a Microsoft szerint sem működik. Érteném a logikát, amit írsz, ha valaki azt mondaná, hogy márpedig ez működik csak ki kell nyújtani a "kezet", de nem. Ilyet még soha senki sem mondott. De olyat már sokan mondtak, hogy: nézzétek, a konzolon ki tudjuk nyújtani a kezünket! És 2014-ben ki lett kiáltva bűnösnek az API, így kaptunk négy új low-level API-t, vagy egy részükre bejelentést, hogy készülnek.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A driver mindig igényelt erőforrást a működéshez. Másképp aligha tudná ellátni a feladatait, a baj, hogy egyre több kell neki. Viszont ennek nem kellene úgy lennie, hogy erőltessük a DX11 határain túllépő PC-s grafikát. Elfogadhatnánk azt is, hogy ebben annyi van amennyi, és akkor lenne erőforrás a gameplay szimulációra. Viszont ezt nem fogadtuk el, és ennek az a következménye, hogy a fejlesztőknek nincs több erőforrásuk a programra, mint sok éve.
De mondhatjuk azt, hogy a fejlesztők szimplán bénák DX11-ben, a Microsoft is csak félrebeszél, amikor nem ajánlja a deferred contextet, és a Mantle is csak azért működik, mert annak a 3000-4000 soros kódnak a beírását a fejlesztők tehetségesebb "skizofrén" énjük hozta össze.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#8666
üzenetére
Pedig de. Mondok egy példát rá az Alien: Isolationből. A modern GPU-s részecskerendszer, amit használ teljes mértékben mentes a többletrajzolás problémájától. Ez az első mozaikos alapokra épített algoritmus, és kapaszkodj meg ... legalább ötször gyorsabb azoknál a GPU-s megoldásoknál, amelyet ma az egyes játékok használnak, és a még szintén használt CPU-s megoldásoknál nagyjából százszor gyorsabb. Persze a CPU-s megoldások eléggé le vannak butítva, ahogy a GPU-sak is, hogy a többletrajzolás ne okozzon gondot, de az Alien: Isolation motorja koncepció szintjén védekezik ellene. Több tucat ilyen trükkből tevődik össze az Alien: Isolation sebessége. És az oka a nulláról írt motor.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Én igazából azt nem értem, hogy a problémán mit nem lehet érteni. Kiindultunk abból, hogy a FEAR AI-jához képest a mai PC-s játékok AI-ja hasonló szintű. Ezt a fejlesztők azzal magyarázzák, hogy a DX11 nem teszi lehetővé, hogy a processzoridőnek a nagy részét kihasználják. A konzolon ott az Uncharted 3 sokkal jobb AI-val, amivel a FEAR rendelkezett. Ott tehát működik a dolog. Mi az oka annak, hogy számos bizonyítékkal a hátuk mögött nem hisszük el a fejlesztőknek, hogy nem ők a bénák, hanem tényleg a rendszer dolgozik ellenük PC-n? Még ha egy fejlesztő lenne, aki az ellenkezőjét mondja, de nem, mindenki szerint rossz az a programozási paradigma, amit a DX11 rájuk kényszerít.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Még annyit tennék hozzá az egész nagy API leváltós vitához, hogy természetesen bizonyos értelemben megbomlott az egyensúly, illetve az a stabil alap, amit a Microsoft és a Khronos biztosított a DX és az OGL API-kkal. Két cég nyerészkedni akar a váltáson, amit egyébként az MS a DX12-vel és a Khronos az új OGL bejelentésével akceptál. Az Apple és az AMD időben felismerte a problémát, és mertek reagálni egy-egy saját API-val. Nyilvánvaló, hogy ennek lesz hatása a piacra olyan értelemben, hogy a többiek nem mertek lépni, mert például nem akarták megbolygatni a piac számukra megfelelően stabilitását. Egy ideje bizonyosan azon megy a vita a konkurenseknél, hogy "van ez a két marha", akik vágtak magunknak egy saját ösvényt, és több fejlesztőpartnerüket beterelik majd.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
De volt rengeteg előrelépés. Csak nem PC-n. Ez a fontos. A PlayStation 3-on pár exkluzív címben sokkal jobb AI van, mint ami PC-n valaha is létezett. Ezzel példálóznak a fejlesztők évek óta. Nem tudják igénybe venni az elméletben létező erőforrást, ha gyakorlatban nem érhető el, és ezért ma egységesen a DX API, jelenleg DX11 van hibáztatva. Aztán ezt vagy elhisszük nekik vagy sem, de tény, hogy a PS3 és Xbox 360 exkluzív játékokban valamiért tudnak jobb AI-t csinálni, míg PC-n nem.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
letepem
#8679
üzenetére
Majd a második rész ... ott még keményebbek. Kilövik a fedezéket is, mielőtt eljutnál oda, szemetek.
Lehet, hogy nem tiszta minden. Nyugodtan reagálhat rá, erre van a fórum. Peace gyerekek, világbéke.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Akkor itt a félreértés. A deferred context nem feltétlenül kell a többszálúsításhoz, az csak a parancslistát kreálja több szálon, de a beírást már amúgy is egy szálon végzi. Az immediate context manuális többszálúsítással jobb eredményekre képes, és innentől kezdve az egész probléma megszületik, mert a kezdetektől ezt az irányt választották a fejlesztők, ehhez még DX11 sem kellett. A DC csak egy alternatíva volt, ami nem működött végül. Viszont a driverek már 2006-ban több szálon működtek, tehát az erőforrást elvették.
Igazából a low-level API-k előnye nem is feltétlenül a többszálú modell megújítása, az is nagyon jó, de a legfőbb előny az, hogy a grafikus kernel driver nem futtat szerver szálakat a programszálak mellett, így az erőforrást sem veszi el.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az erőforrás tényleges elzárásához nagyon ritkán nyúlnak a mai driverek. Profil nélküli játéknál nem is alkalmazzák.
De az elzárás nem is szükséges ahhoz, hogy gond legyen. Önmagában az is baj, hogy a driver feladatai szimplán futnak a program mellett. 2006-ban már készültek olyan driverek, amelyek 2 szálat is futtattak és ma az 5-7 szál az általános. A fejlesztőknek ezzel az a baja, hogy ha még nem is zárják el az erőforrást, akkor is összeakadnak a programszálakkal, és a driver annyira feketedoboz jellegű rendszer, hogy semmilyen lehetőség nincs a működését normális keretek között kontrollálni.
Ezért alakult ki az az igény az új API-knál, hogy ne legyen kernel driver. A DX12-ben ugyan lesz, de az csak egy fail-safe dolog, vagyis csak azt biztosítja, hogy a program lefagyásától ne fagyjon le az operációs rendszer. Valójában nem fog erőforrást elvenni, mert tényleges számítást nem csinál majd.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Pont ez a baj, amit leírsz. A driver önmagában nem félelmetesen sok processzoridőt, viszont a kiszámíthatatlan működésével hozzáférhetetlenné teszi azt. Ha optimális lenne a driver processzorkihasználása, akkor nem kellenének új API-k, mert elveszi magának az erőforrást, és amit nem használ az csak úgy elérhető lenne. Mindenki boldog lenne egy ilyen modellel, csak nem ez történik, hanem elveszi az erőforrást és ennek következményeként hozzáférhetetlenné tesz még egy csomó processzoridőt, amin valóban kimutathatóan nem csinál semmit, csak ettől még ez a processzoridő nem lesz elérhető a programnak. Lásd a korábbi slide-ok.
Maga a rendszer black box jellege kiszámíthatatlanná teszi az egész feldolgozást, programozóként nem leszel ura a hardvernek, és így pedig borzasztóan nehéz elvárni a stúdióktól, hogy újítsanak.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Te is pontosan tudod, hogy a programfejlesztés elmélete mennyiben különbözik a gyakorlattól. És itt jön elő az anyagiak problémája. Természetesen az egész levezethető egy elméleti alapon, hogy bizonyos, alapvető optimalizálással nem elérhető, de igazából szabad erőforrások hozzáférése mennyi munkaórát, pénzt, programozót igényel. Erre bárki képes, aki tapasztalt a modern játékfejlesztésben. És mivel jutunk előrébb, akkor, ha kiderül, hogy tudnak +10%-nyi erőforrást nyerni, ha még egy évet optimalizálnak? Maximum az EA engedheti meg magának, hogy erre pénzt áldozzanak, mert őszintén szólva +10%-ért baromira nem éri meg belekezdeni.
Ha a Nitrousból való ábrákat felhoztad, akkor érdemes kiemelni, hogy ez egy három éves fejlesztés. Három év alatt jutott el oda a motor, hogy DX alatt az erőforrásokat úgy kihasználja, ahogy a képen van. Ezzel szemben a Mantle erőforrás-kihasználása hat hetes munka eredménye volt akkor. Tehát mit is várunk tőlük? Hány évet öljenek még bele az optimalizálásba? Ha egy kiadó lenne a hátuk mögött, aki időpontra kérné a programot, még ilyen kihasználást sem érhettek volna el, mert nem engedték volna őket három évig dolgozni. Egyedül Brad Wardell fanatizmusának köszönhetik, hogy minderre meglett az anyagi lehetőségük. Valljuk be a mai világban nem sok Brad Wardell szaladgál, inkább Bobby Kotick kaliberű cégvezetők vannak a szoftveriparban. És amíg ez az egész egy nagy üzlet lesz, addig nem fog ez a felállás megváltozni. Bobby Kotick is azt fogja nézni, hogy a low-level kóddal ötödannyi erőforrást sem kell befektetnie, kellenek a halálnak a pénznyelő API-k. Mostantól még olcsóbb lehet a következő Call of Duty, hurrá.Nem kell ahhoz várni, hogy meglásd mennyit fog fejlődni az AI. Csak elő kell kapni pár konzol exkluzív játékot. Ezeknél már rég túlléptek a PC-s szinten.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
ALONSO11
#8704
üzenetére
Az AMD API-ja egy éve létezik. Hat játék jelent meg rá és 100 fejlesztő dolgozik vele. Az eredeti terv kb. 20 fejlesztő volt, de láthatóan kell az iparnak ez a szemlélet.
Az NV-nek semmi baja, szóba sem került az NV ebben a topikban.
Ami szóba került, hogy a szabványnak van baja, például az, hogy a Dragon Age Inquisition nem stabil DX11 alatt. [link] - ez már veszélyezteti a PC-s játékpiacot, mert mégis ha megveszel egy játékot és fagy, akkor mit tennél? Sokan a Radeont már meg sem próbálják, hiába csinált nekik az EA egy alternatív módot az AMD API-jára. Egyszerűbb menni konzolra.
Csak egy dolgot kell figyelembe venni. Az, hogy egy modern játékot nem lehet megírni teljesen stabilra DX11-re, drámaian veszélyezteti a PC-s játékpiacot. És mondhatjátok azt, hogy bénák a fejlesztők, de ez nem változtat azon a tényen, hogy a felhasználóknak elege van a PC-ből, abból a tökölésből, hogy optimalizálatlan vagy nem stabil játékokat kapnak. Ezekről csak a vak nem akar tudomást venni. Az a helyzet, hogy egyszerűbb, ha elfogadjuk a fejlesztők indokát, hogy konzolra miért megy nekik az, ami a PC-re nem megy. Főleg azután, hogy bizonyították is idén, hogy PC-n is megy, csak nem DX11 alatt.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Senki sem a compute shadert bírálja, amikor a bajokról beszél. Sőt, ez a shader lépcső segít abban, hogy begyorsítsák a programot. Az egyetlen fejlesztés, aminek igazából haszna volt a DX11-ben. Ellenben jött még számtalan újítás. Például a deferred context, amit mindenki, ezen belül ma már maga a Microsoft is rossz megoldásnak tart.
Az eddigi pipeline nem fog lebomlani a DX12-vel. A Microsoft csak az Xbox One-on engedi meg az egyszerűsített erőforrás-kezelést, ami minden shader lépcsőt egységesnek tekint.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Sosem tervezték. A 28 nm-es node a GPU-knál jobb, mint a 20 nm-es. Lassan másfél éve lehet tudni.
A WCCFtech egy hihetetlen kókler banda, akik abszolút nem értenek ehhez az egészhez, de rengeteg fals pletykát gyártanak. Tőlük átvenni bármilyen információt igen nagy öngyilkosság, mert 90%, hogy hibás, vagy ha az információ nem is volt az a hírben már hibásan írták meg.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
ALONSO11
#8718
üzenetére
Írtam korábban, hogy az AMD-vel erről beszélgettem nemrég. Lesznek új hardverek, nem tagadják, de a mostani hardvereket elég jónak tartják és arra koncentrálnak, hogy elérhető legyen a tudásuk a fejlesztőpartnereiknek. Sajnos annyira lemaradt a szoftveres oldal, hogy ebben rejlik most messze a legnagyobb innováció lehetősége. Például nagyon fontosnak tekintik, hogy az olyan konzolos innovációk elérhetők legyenek PC-n, mint a HRAA, mert hiába a gyorsabb hardver, ha az említett kiemelkedő minőségű és hatékonyságú AA-t nem tudod aktiválni PC-n. Úgy látják, hogy az nem segít a PC-nek, ha jön egy még gyorsabb VGA, és eközben nézegeted, hogy a konzolon milyen innovatív eljárások születnek, amelyeket nem érhetsz el PC-n dacára a TFLOPS-oknak
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Lehet, hogy félreértjük egymást. Tisztázzuk azt, hogy a DX11 pipeline modellje megváltozik. Tehát a különálló pipeline modell eltűnik, vagyis nem úgy működik majd a DX12, hogy a lépcsőkhöz (legyen az shader vagy fixfunkciós) hozzá kell rendelni egy hardver állapotot. Ehelyett lesznek a PSO-k. Maga a futószalag állapotobjektumként lesz reprezentálva, tehát a futószalag lépcsői be lesznek vonva egy objektum alá, amelyek a létrehozásuk után megváltoztathatatlanok. Ezt főleg azért vezette be az MS, mert a hardverek bizonyos DX11-ben még megkülönböztetett állapotokat az eszközszinten valójában egységes állapot alatt kezelnek. Tehát közelebb került az API működése a hardverhez és a sok többletterheléstől is mentesülünk. Ugyanakkor maga a DX12 még mindig megkülönbözteti a vertex, pixel, geometry, akármi shader lépcsőket. Ezeknek megvan a maguk szabályozása, hogy milyen erőforrásokhoz férhetnek hozzá, stb. Ebből a szempontból a Sony PS4 és az AMD saját API-ja másképp működik, mert ott igazából a vertex, pixel, geometry bár logikailag megkülönböztethető, de mindegyik shader ugyanarra képes, ugyanazokhoz az erőforrásokhoz férhet hozzá. Tehát nincs olyan, hogy a vertex shader nem írhat xy bufferbe, ha a fejlesztő írni akar oda, hát akkor írjon.
Arról nincs szó az eddigi leírásokban, hogy a tesszellációs lépcsők a DX12-ben kivághatók lennének. A PS4-en és az AMD API-ján biztosan azok. De igazából már a DX12 PSO is ad arra lehetőséget, hogy olyan formában optimalizálj, ami korábban nem volt lehetséges. Például, ha egy vertex shaderben számolt értékre később biztos nem lesz szükség, akkor az kiszűrhető, és nem kell, hogy a futószalag többi elemét tovább terhelje. Ebből a szempontból a PSO is lényeges előrelépés a DX11-hez képest.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A hardver fejlesztése valójában egyszerűbb lenne számukra. Megvan az architektúrájuk, még mindig közelében sem járnak az API-k, hogy kihasználják a képességeit, szóval továbbra is élhetnének azzal, hogy átkonfigurálják évente, és arra a konfigra kiadnak három-négy új GPU-t. A probléma ezzel az, hogy semmit sem változtat a piacon. Kapnak a fejlesztők kb. 20%-kal több TFLOPS-ot minden szegmensben, miközben továbbra sem fogják tudni futtatni azokat az effekteket PC-n, amelyeket például a PS4-en igen. Lásd a HRAA a Far Cry 4 esetében.
Az a szoftveres fejlesztés, amit elindítottak valójában sokkal több pénzt emészt fel, mintha új hardvereket hoznának, de jelen pillanatban úgy látják, hogy ennek van értelme, mert csak így tudnak a fejlesztők hozzányúlni azokhoz a tartalékokhoz, amelyeket ma nem lehet elérni.
A mobil szegmensben a fogyasztást semmi sem csökkenti jobban, mint egy low-level API. Ezt te nem tudod megnézni, de a Mantle érdekessége, hogy úgy növeli a sebességet, hogy közben csökkenti a fogyasztást. A Sniper Elite 3-on ezt kipróbáltam már, kb. 50 wattal kevesebbet fogyasztott a gépem, miközben a sebesség 30-40%-kal nőtt.
Neked nem kell arról meggyőzve lenni, hogy kell a low-level API. Nem neked fejlesztik, hanem a fejlesztőpartnereiknek, akik viszont meg vannak arról győződve, hogy számukra egy ilyen irány nélkül a PC nem vállalható platform.
A fragmentáció elkerülhetetlen, nem a low-level API hozza ezt el, hanem az eltérő fejlesztési stratégia, amivel az AMD és az NV dolgozik. Az AMD akarja a low-level API-t, míg az NV nem, ők szándékosan kértek DX11.3-at, mert nem fogják elmondani, hogy miképp lehet az alkalmazásokat GeForce-ra optimalizálni.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#8864
üzenetére
Ezt nem érdemes így kimondani, mert ezek a low-level API-k pont azt csinálják, hogy elérhetővé teszik a memóriát a programozóknak. Eddig az API-k ellentétesen dolgoztak. A fejlesztő hozhatott létre puffereket és a szükséges allokációt az API a driveren keresztül elvégezte. A programozó csak ezeket láthatta és kezelhette, de a valós munkát a driver végezte vagyis a memória el volt rejtve. A low-level API-kkal ez mind ki lett vágva. A hardver inicializálásánál a program megkapja a memóriát, azt csinál benne a fejlesztő, amit akar. Itt jön az, hogy mindent nekik kell megírni és látható, hogy bizonyos allokációs technikákkal jobban is lehet bánni a memóriával, mint ahogy a Sniper Elite 3 teszi. Ott bár a memóriahasználat DX11-hez hasonló, de nő a textúrák minősége. Hasonló modellt vezetett be a Dragon Age: Inquisition is.
Mivel a tartalom minősége nőni fog, így ezek sem lesznek igazán jó alternatívák a jövőben. Főleg az Xbox One miatt olyan koncepciók kerülnek előtérbe, amelyek kevés memóriát igényelnek. A virtuális textúrázás a mostani API-ban ugyan elérhető, de nagyon rosszul működik. Egyszerűen az a gond vele, hogy maga a tartalom törlése rendkívül költséges, tehát lényegében van egy funkció a DX11.2-ben, ami használhatatlan, mert túl magas többletterhelést jelent. A low-level API-kkal ezek a funkciók ugyan eltűnnek, de mivel a programozó mostantól teljesen látja a memóriát és úgy kezeli, ahogy akarja, lehet a GPU-ra írni egyéni virtuális textúrázó rendszereket. Ez a két új konzollal és a legtöbb mai GPU-val (Gen8, Fermi, Kepler, Maxwell, GCN) simán megoldható. Persze a texturalapok külön memóriaallokációt igényelnek, ami limitáció, de például nem kell sokat frissíteni a modernebb hardvereken, hogy több textúralap is tárolható legyen egy allokációban. Ez lényegében teljesen új irányt nyitna meg a textúrák tömörítése szempontjából, radikálisan csökkentve a memóriaigényt. Volt tervezet a Khronosnál a szabványos sparse texture kiterjesztésük kiegészítésére tile-pool támogatással, de elvetették, mert az elmúlt év tavaszán még nem támogatta semmi ezt a technikát hardveresen. De a Radeon R9 285 (aka Tonga) ma már támogatja, és igen nyilvánvaló, hogy az elkövetkező két év során a többi gyártó is beépíti, tehát érdemes foglalkozni a kérdéssel. A konzolokon is megoldható pár alternatív opció, hiszen van egységes memória.
Ezek majd alapvető technikák lesznek, hogy növelni lehessen a textúrák minőségét úgy, hogy töltőképernyőket se kelljen használni. Persze utóbbi majd megint igényel fejlesztéseket, hiszen a tartalmat ki kell kódolni stb., ami megint para, de ezekre PC-n is lesznek megoldások. Elsőként az új API-kkal felszabaduló temérdek processzoridő, majd az IGP-k befogása, és így tovább, ha esetleg gondolkodnánk fixfunkciós technikákban.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#35434496
#8881
üzenetére
Nem. Egyszerűen előbb a szoftveres kérdéseket akarják megoldani. A Fiji is kész van már, csak várni kell a HBM-re. A Tongát meg majd átnevezve eladják. De idén a legfőbb cél akkor is a szoftverfejlesztés. Ez kritikus fontosságú.
Ami nagyon nem halad a tervek szerint az a Mantle első verziójának lezárása. Már rég publikussá kellett volna tenni az 1.0-t. Viszont ezt nem tudják megtenni, mert az eredeti útitervet az AMD a saját munkájához szabta, viszont beesett számos játékfejlesztő és elkezdtek az API-hoz kiterjesztéseket írni. Ez nem baj, mert ennek az API-nak a célja a fejlesztők kiszolgálása, de a publikálást megnehezíti, ha folyamatosan jön egy programozó a "mi lenne, ha még ezt a problémát is megoldanánk" szöveggel. Itt el vannak csúszva.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
stratova
#8888
üzenetére
Igen. A Tonga jóval többre képes, csak úgy kellett paraméterezni, hogy ne legyen sokkal jobb a Tahiti VGA-knál. Az R9 285 azért volt fontos, hogy a fejlesztők arra tudnak optimalizálni low-level kódban, és az a kód automatikusan jó lesz a Carrizo, Fiji, Iceland termékeknek.
Az AMD és a Microsoft lényegében ugyanazokat a problémákat látja a low-level irányban. Lényegtelenné válik a hardverek nyers teljesítménye, mert nagyrészt az határozza majd meg a végső sebességet, hogy az adott programozó képes lesz-e olyan munkát végezni a motor felkészítésében, mint amit ma a gyártók a driverekkel. Mert ugye a programba átkerül minden, amit eddig a driver automatikusan megoldott. Valószínűleg az lesz a jövő tervezési modellje, hogy minden generációváltás előtt ki lesz adva egy új architektúraverzióra épülő lapka, aminél nem számít, hogy mi lesz az eredmény, mert csak azt a célt szolgálja majd, hogy a fejlesztők megtanulják hogyan kell vele bánni. És nagyjából fél évre rá jön az igazi generációváltás, amikor már a programokat optimalizálták az új architektúraverzióra. Ilyenkor az eredetileg kiadott lapkát is fel lehet javítani.
Most már azért vannak eredmények a DX12-ből is, így körvonalazódik, hogy mire lehet számítani. A Nitrous motor esetében az eredeti Mantle kódot DX12-re átültetve lényegében semmi gondja nincs a Hawaii GPU-nak. Nagyjából olyan gyors, mint Mantle módban. De ha ezt a kódot a GM204-en futtatják, akkor az a Hawaii GPU teljesítményének a felére sem képes, holott ugye DX11-ben nagyjából egymás nyakán vannak. Ergo borzalmasan számít az, hogy a programozó a low-level kódot optimalizálja minden egyes architektúra minden egyes verziójára. 20-50%-os mínuszok jönnek, ha ezt valaki nem teszi meg. És itt az Xbox One kódra is igaz ez. Ha azt átmentik a PC-re módosítás nélkül, akkor az a Hawaii GPU-n jó lesz, de a többi GCN-en befigyel majd egy 10-20%-os hatékonysági mínusz, míg a többi architektúrán 50%-os deficit is lehet. Szóval nagyon fontos lesz a jövőben, hogy legalább fél évvel korábban kapjanak gyakorlatilag kész hardvert a fejlesztők abból az architektúraverzióból, amire épül majd az új generációs sorozat.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A PC-t sosem fogják olyan alacsony szinten programozni mint a konzolt. Szóval itt elég azt elérni, hogy nagyjából meglegyen az a kihasználási szint, ami eddig megvolt, vagy valamivel több, ha lehetőség van rá.
A PC-n egyébként pont azért tartják most tovább itt a hardvereket, mint korábban, mert azokat ki kell tanulni. Egy VGA-t akár két-három évig is fogalmaznak majd a jövőben, mert a low-level irány mellett sokkal előnyösebb, egy alap hardvert kínálni, és évente mutatni a fejlesztőknek valami trükköt. Persze átnevezés lehet, sőt lesz is.
Egyébként a PC-t is programozhatnák a jövőben olyan alacsony szinten, mint a konzolt, ehhez az kellene, hogy a gyártók vállalják, hogy 5-7 évig nem fejlesztenek új hardvert, de ez egyelőre álom kategória, szóval ma inkább a 2-3 éves ciklus a realitás, és az arra vonatkozó felületes tanulás.(#8891) Crytek: Aki tudja, hogy nem fog optimalizálni, az ne nyúljon hozzá a low-level API-khoz. Ezért lesz DX11.3 is, az is elérhető lesz majd az Xbox One-on.
Egyébként nem olyan bonyolult ez. PC-n már csak három gyártó van, akiket számításba kell venni. Ráadásul az Xbox One kód eleve GCN optimalizált, tehát azt csak javítgatni kell, vagyis a tényleges munka igazából két gyártóra csökken.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#8897
üzenetére
Mivel a két API-nak a GPU command modellje teljesen azonos, így azokban a tesztekben amelyek ezt terhelik nyilván azonos lesz a teljesítményük is.
Játékokban biztosan lesz másik API a Mantle mellett. Valószínű, hogy a DX12 lesz az. De egyébként az AMD is azt mondja a fejlesztőknek, hogy ha nincs valami olyan dolog, amit a DX12 nem tud, akkor ne használják a Mantle-t, mert nem az a célja, hogy a DX12-t kiváltsa. És ez szerintem logikus is. Ha fejlesztő minden felmerülő problémát meg tud oldani DX12-ben, akkor ne foglalkozzon még egy API-val. A 3DMark azért foglalkozik vele, mert ez egy benchmark. Nekik az a dolguk, hogy támogassanak minden értelmes dolgot, de a játékfejlesztőnek sokkal specifikusabban kell gondolkodni.
(#8900) HSM: Nem egy memóriaterhelő motor a Nitrous. Biztos számít valamennyit, de közel sem ennyit. Egyszerűen nincs megírva rá az optimalizáció. Ezeket egyszerű kipróbálni. Rakjatok vissza egy új, de komolyabb játékhoz egy 1 évvel korábbi drivert. Rossz lesz. Ugyanez a baj csak itt maga az alkalmazás a driver, tehát oda kell megírni a vezérlést.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Sokkal többet tud rontani egy nem ideális kód. Akár 80%-os mínusz is lehet, de láttunk már olyat, amikor egy új driverrel ötszörösére gyorsult egy játék. Lásd a GeForce és a Dragon Age 2 esete.
(#8904) daveoff: A Mantle egyértelműen a tehetős, innovatívan gondolkodó fejlesztők kiváltsága lesz a jövőben. Másnak nincs értelme rá pénzt költeni, mert nem használják jobban, mint ahogy a DX12-t fogják. Annyi biztos egyébként, hogy az EA használni fogja a jövőben is. Ők a GNM-et és a Mantle-t tekintik R&D fókusznak és onnan a DX12-re fognak portolni. A Square Enix is hajlik efelé, bár nekik ott a Nixxes, akik semmi mást nem csinálnak csak PC-re portolnak, szóval ott van egy direkt stúdió, aminek a nyakába lehet varrni egy csomó R&D munkát.
A jelenleg ismert adatokból kiindulva, aki mondjuk komolyan érdekelt a multi-GPU-ban annak kell majd a Mantle, illetve ez az API megengedi az LDS-ben tárolt adatok korlát nélküli kiolvasását, illetve definiál specifikus MSAA módokat is, utóbbi kettő például hasznos lehet, ha az Ubisoft HRAA-t PC-re is át akarjuk menteni. Erre sajnos a DX12 nem ad majd lehetőséget. Nagyjából azokat a dolgokat kell mérlegelni, hogy a fejlesztőnek szüksége van-e azokra a lehetőségekre, amelyeket a Mantle extraként biztosít. Ha ezek kellenek egy-egy PS4-en elérhető effekt PC-re mentéséhez, akkor nyilván támogatniuk kell a Mantle-t. Ha nincs ilyen, akkor felesleges a támogatás, mert a DX12-n belül is elérik, ami kell lényegében hasonló előnyök mellett.
De hangsúlyozom egyébként, hogy ez nagyrészt pénz kérdése. Egy EA egyértelműen megengedheti magának, hogy a legmodernebb API-kat támogassa, mert iszonyú sok pénzük van, és az aktuális stratégiájuk része, hogy rövid időn belül egy éves technológia előnybe kerüljenek minden egyes konkurensükkel szemben. És ezért most piszok nagy pénzt ölnek a Frostbite fejlesztésébe, ezen belül is a PS4 GNM API és a Mantle kutatásába. És ők pontosan tudják, hogy az egyik mód arra, hogy PC-s szinten technológia előnyt szerezzenek az, hogy ha olyan API-t támogatnak, amelyet más kiadó esetleg nem fog. Tehát a konkurensük eleve hátrányból indul, mert kényszerűen butább API-ra dolgozik, ami nem baj, mert azt is támogatni kell, hiszen az a szabvány, de az EA-nek ez akkor is egy ugródeszka. Kihasználják, hogy nagyon mély a zsebük.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Egyelőre nagyon hallgat ebből a szempontból mindenki. A Gamebase mondta régebben, hogy ők a multi-GPU-t Mantle-ön és CUDA-n oldják majd meg. És az, hogy az MS a multi-GPU-ról nem beszél, elég erős utalás arra, hogy ez a DX12-ben nem kap fókuszt.
Egyébként vizsgáljátok a dolgot az MS nézőpontjából. A multi-GPU egy szűkölő piac, amit igazából egy markényi hardcore felhasználó tart életben. Az asztali PC szintén egy szűkölő piac, mert már az asztali szinten is 60%-ban mobil procira épített apró PC-ket adnak el a gyártók. Az MS-nek fel kell tennie a kérdést magának, hogy mennyire érdekeltek abban, hogy egy maréknyi felhasználóért egy komoly befektetést igénylő funkciót tervezzenek az API-ba. Ha meg is teszik, akkor mennyire lesznek érdekeltek a fejlesztők abban, hogy egy maréknyi és csökkenő számú felhasználóért írjanak saját multi-GPU algoritmusokat a programba.
Ha a felhasználók kis számát, és a szűkölő piacot logikusa végiggondolod (nem úgy, hogy te személy szerint igényt tartasz rá, hanem úgy, hogy a GAB felteszi a kérdést: "na és mit kezdjünk ezzel a 0,01%-nyi hardcore felhasználóval"), akkor sokkal valószínűbb, hogy az MS egyszerűen átadja az egész problémát a gyártóknak. Ők teremtették ezt a jelentéktelen piaci réteget, oldják meg ahogy akarják.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ez egy jó indok, de megint problémákat vet fel. Az MS-nek rengeteg erőforrásba kerülne azt elterjeszteni, hogy "tudjuk mennyire fos volt a multi-GPU, de most jó lesz ... trust me!". Eleve nincs rá példájuk. Illetve a Civ: BE-t előszedhetik, de akkor meg az AMD API-ját reklámoznák, hogy "látjátok ezzel lehet jót alkotni". Sokkal egyszerűbb befektetés nélkül elkönyvelni, hogy ez a piac nem éri meg. Mit veszítenek? Átmennek a hardcore PC-sek konzolra? Maximum váltanak Mantle-re, de az sem baj, mert Windows only, tehát akárhogy is döntenek, nem változik semmi a Windows eladásai szempontjából.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#8912
üzenetére
Az EA most abban látja a lehetőségeket, hogy technológiailag mindenkivel szemben kiépítenek egy nagynak mondható előnyt, és ezért hajlandók igen sokat költeni.
Főleg azért választották le a DICE-tól a Frostbite Teamet, hogy a jövőben nekik ne kelljen speciálisan egy-egy játékra koncentrálni, hanem csak fejlesszék a motort házon belül aszerint, hogy az EA stúdiók mit szeretnének. Egyszerűen bezárkóztak és olyan technológiát fejlesztenek maguknak, amellyel más kiadó képtelen versenyezni, ez persze nagyban köszönhető annak, hogy az EA pénzes cég. Hosszútávon ennek két előnye lesz. Az egyik, hogy a legtöbb játékot a Frostbite motor alá rendelik, és ezek a játékok PC-n csak az Originen érhetők majd el. Az Origin terjesztése kritikus fontosságú, mert a Steam túl nagyra nőtt, és ez az EA-nek nem tetszik.
Igen a Mantle jövőjét az nagyban meghatározza, hogy az EA átszervezte magát. A Frostbite Team egyik feladata, hogy kutassák a PC-s lehetőségeket a Mantle-ön keresztül. Nem szabad elfelejteni, hogy ez az API bár jogilag az AMD tulajdona, a fejlesztésben az EA szakemberei nagyban részt vettek. Ők voltak az elsők, akiket ebbe az AMD bevont (igazából az EA vezető motorprogramozója kérte az API-t). Tehát az EA számára ez egy saját technológia. Úgy utasították az AMD-t a fejlesztésre, hogy az nekik biztosan jó legyen. Valószínűleg ma is jelentős szerepe van az API továbbfejlesztéseiben annak, hogy a Frostbite Team mit akar. Ez szintén egy stratégia. Hiába gondol el valamit az EA a jövőről, ha az adott API azt nem támogatja. A Microsoft esetében sokkal nehezebb elérni az olyan változásokat, amelyeket az EA esetleg akar, míg az AMD-nél ez nagyon könnyű, aztán a Microsoft úgyis követni fogja ezt az irányt, mert nem hagyhatják figyelmen kívül azt, amit az egyik legnagyobb kiadó akar.
Az EA két legyet üt egy csapásra. A saját igényei szerint formálják a piacot, és folyamatos fejlesztésre kényszerítik az MS-t. A nagy iramban két lehetősége van a konkurens kiadóknak. Követik az EA-t, ami sok pénzt emészt fel, de ekkor is az EA vezeti be leghamarabb az újdonságokat. Esetleg elhatározzák, hogy nem követik az EA-t, mert nincs elég pénzük versenyezni, de így a játékaik technológiailag lemaradnak az EA mögött. Mindkét lehetőséggel az EA lesz a leginnovatívabb vállalat a maga területén.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A DX12 nem akar annyira mélyre menni. Bár alacsony szintű API, de inkább a Metal és a Mantle közötti absztrakcióval rendelkezik. Bizonyos legacy funkciókat próbálnak átmenteni és így pár területen kompromisszumra van szükség. Például a friss Win 10 érkezésével kiderült, hogy a memória menedzsmentje nem teljesen explicit. Nagyrészt az, de bizonyos pufferek fölött a WDDM fog babáskodni. Ez megnehezíti az explicit GPU menedzsmentet is. Nyilván nem lehetetlen, de nem olyan egyszerű, mint mondjuk az AMD API-jánál. Kell pár kiegészítés az API-ba is.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Olcsóbb biztos nem lesz, mert a HBM egy 2.5D stacking technika, tehát interposer kell hozzá. Ez jó a nyomtatott áramköri lapnak, ami sokkal egyszerűbb lesz, de az interposer elég drága, tehát a lapkát a tokozással együtt megdrágítja. A fogyasztás az nyilván csökken, mert a HBM memória jóval kevesebbet eszik, mint a GDDR5.
Az új gyártástechnológiára akkor éri meg a GPU-kat átvinni, ha jobb mint a 28 nm-es HPM. Jelenleg és az idei évben elérhető gyártástechnológiák közül egyik sem ilyen. A nm előtti számnál fontosabb tényezőket is figyelembe kell venni. Leghamarabb a 14 nm-es LPP a megfontolandó alternatíva, az jobb, mint a 28 nm HPM, de ez idén csak a Samsungnál lesz elérhető, és csak az év végén. A GloFo 28 nm-es SHP-je is alternatíva, de annyit nem ér már, hogy arra átálljanak.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
stratova
#9190
üzenetére
Itt csak azért erős a 285, mert az OpenGL base profil a Radeonon csak egy tesszellátor használatát teszi lehetővé. Ezért van a Hawaii és a Tahiti egymáson, annak ellenére, hogy a Hawaii DX11-ben sokkal jobb eredményeket mutat fel.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Vegyük a Tahitit. Az első hardver volt, ami támogatta a bindless modellt, az erőforrások korlát nélküli kezelését, a stateless compute képességet, az aszinkron DMA lehetőséget, a PRT-t.
A bindless modellt az NV-nél a GK204 vezette be, míg az aszinkron DMA lehetőséget a GM204.
A PRT főbb képességeit a GK204 részlegesen, míg a GM204 teljesen támogatja.
Az erőforrás-kezelés szempontjából nő limit: SRV: Fermi->Kepler-Maxwell esetében 128->1024768, UAV: Fermi/Kepler/Maxwell1->Maxwell2 esetében 8->64 ... nyilván nem korlát nélküli, de látszik az irány.
Később lesz a konkurensek oldalán is stateless compute, és a többi dolog, amit a GCN bevezetett. Ennek az architektúrának a képességei után mennek a konkurensek és másolják le azokat, részben vagy teljesen.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Azért hozzá kell venni azt a stratégiát is, hogy az AMD-t elsődlegesen ennek a piacnak a fennmaradása érdekli, míg a többi másodlagos. Az NVIDIA listájának tetején a mobil és a felhő áll, és a PC a másodlagos.
A tervezési koncepciók csupán ezt reprezentálják. Ha az AMD-t is annyira érdekelné a mobil és a felhő, mint az NVIDIA-t, akkor nekik is olyan architektúrájuk lenne, amelyet az energiahatékonyságra gyúrtak ki, mert az kis fogyasztást jelent és például olcsó fenntartani a felhőt. Ugyanez fordítva, ha az NV-t komolyan érdekelnék az olyan PC-s irányok, mint a VR vagy a 4K, akkor ők is máshogy tervezték volna az architektúrát. Szóval ez fókuszkülönbség. Egyik cég sem hülye, csak más prioritások szerint dolgoznak.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nézd meg hova jutottak. Biztos emlékszel még az R600-as időkre, és utána. Az EA, a Square Enix, a Capcom, a SEGA, mind az NVIDIA partnerei voltak. Ma egyik említett cégnek sincs szerződése az NVIDIA-val, és mindegyik cég az AMD-vel fejleszt. És ebből ma mi látszik? Az AMD Gaming Evolveden belül érkezett játékok jól optimalizáltak. Ezzel szemben az NV-nek maradt az Ubisoft és a Warner, mert belőlük az AMD sem kér. Kapott a piac Watch Dogs-ot, AC: Unity-t, most Dying Lightot, amelyek abszolút nem erősítik meg arról a usert, hogy PC-s játékosnak lenni jó.
Az AMD a stratégiájával az összes olyan kiadót maga mellé állította, akik képesek optimalizált PC-s portokat lerakni az asztalra, míg meghagyták az NV-nek a csőcseléket. Mi ez ha nem eredmény?Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az miért fontos egy felhasználónak? Egy cég tegyen értünk, ne mi tegyünk a cégért. Aki úgy gondolkodik, hogy tartozik egy gyártónak az nem normális világnézetet vall, mert saját érdekeit helyezi a háttérbe. Persze lehet építeni a birkákra is stratégiát, a világ minden táján, sőt hazánkban is láthatjuk, hogy ez az irány sikeres.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ez tévedés. A kettő nagyon összefügg. A fejlesztők mindig kiválasztanak egy domináns architektúrát, amelyre megéri kutatni. Ez most a GCN, részben a konzolok miatt, részben pedig azért, mert dokumentált és van disassembler is hozzá, és persze nem lehet amellett elmenni szó nélkül, hogy azt a stratégiai szerepet, amit az NV betöltött a G80 időkben, most az AMD tölti be, részben azért, mert az NV elzárkózott.
A kutatások szempontjából ott a StarSwarm, ami először mutatta meg, hogy milyen a magas többletterhelés nélküli jövőkép. Idén lesz egy új példaprogram, ami a GPU-limit megszüntetésére helyezi a hangsúlyt, és ott lesz a VR. Utóbbiról maga az Oculus programozója mondta, hogy az AMD megoldása az etalon. Ezek a váltások három alapra épülnek: tudás, nyíltság és igények kiszolgálása.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az, hogy a GCN-en mindenkinél egy évvel korábban futtatták a Nitroust úgy, hogy nem halt meg RTS módban egy műszaki előny. Ma már a szoftver kéz a kézben jár a hardverrel. Számtalan műszaki előny van még, amely idén fókuszt kap. Például az aszinkron compute/DMA, amik az egyik legfontosabb újítások lesznek, hiszen végre nem kell GPU-limitet kiáltanunk akkor, ha a hardver számítási kapacitásának csak a 20-40%-a van kihasználva, mint ahogy az manapság nagyon jellemző.
A VR nem olyan távoli jövő már. Számtalan szoftveres és hardveres probléma van, amit meg kell oldani, de a GDC-n fel lesz vázolva, ezek jó részére egy-egy GCN-en működő megoldás. Persze a szabványos megoldásokra még várni kell, de az Oculus ezekre már építhet, amikor kiadja az első VR eszközét.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Miért csak az FPS-ben lehetnek konkrétumok? Ott a folyamatosság, a minimum sebesség, vagy a képminőség. Minimum sebességben láthatod az előnyt: [link], [link] A folyamatosságot ebből ki lehet találni. Aztán ott a Civilization BE. Mantle alatt van SFR több GPU és jobb az élsimítás minősége a fedettségminták miatt. A Sniper Elite 3-ban is jobb minőségűek maradnak a textúrák a stream algoritmus miatt a DX11 módhoz képest.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A DICE két dolog miatt indult el a low-level irányba. Egyrészt nem tudtak mit kezdeni azzal, hogy az olyan alapvető dolgok, amelyeket nem lehet megkerülni (például allokált memóriatartalom törlése, szükségszerű shader újrafordítás, állapotváltások többletterhelése, hazárdok lekövetése, memóriamásolások), extra késleltetést vagy akadást okoznak, amely ronthatja a játékélményt. Másrészt az a programozási modell, amit a DX11 rájuk kényszerített teljesen lekorlátozta a kutatásaikat, mert nem tudtak közvetlenül hozzáférni a videomemóriához.
Az fontos, hogy a DICE senkivel senkinek sem akar rosszat, csak az évek során túl sok korláttal találták szembe magukat, amelyet a Frostbite 3-nál már nem tudtak egyszerre lenyelni.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
namaste
#9275
üzenetére
Az teljesen világos, hogy két nagy tényező van, amely nagyban meghatározza a fogyasztást. Az egyik az ütemezés. A GCN teljesen hardveres ütemezést használ, a wavefrontok szintjén OOO logikával. Az NV a Kepler óta félig szoftveres ütemezésű, és a feladatütemezés is in-order. A CUDA-ban vannak olyan lehetőségek, hogy az egyes warp-okat lehessen priorizálni.
A másik fontos tényező a belső adatbusz. Ez jelentős fogyasztáskülönbséget okozhat. A GCN egy nagyon széles belső ringbuszt használ, amivel minden egység összekapcsolódik, míg a Maxwell az ultramobil GPU-k irányelveit követve strukturált buszokkal dolgozik és nem minden egység van egymással összekapcsolva.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
letepem
#9312
üzenetére
Hogy a PC-s játékpiac értéke megmaradjon. Az olyan játékok, mint a Watch Dogs, az AC Unity, a Dying Light jelentősen rombolják a PC-s piac értékét a játékosok szemszögéből. Egyre többen pártolnak át konzolra, mert nem hogy megfizethető PC-t nem tudsz a játékok alá tenni, hanem konkrétan olyan hardvert sem tudsz választani, amin problémamentes a program. Ez óriási gond az AMD-nek, mert ők a PC gaminget tekintik elsődlegesnek. Az NV azért ilyen szabadabb felfogású, mert ők a felhőre tekintenek fókuszként, és számukra az a cél, hogy a PC-s júzer idővel a felhő felé menjen. Ez nem jótékonyság csak üzlet.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#9330
Abu85
HÁZIGAZDA
KillerKollar
#9328
Abu85
HÁZIGAZDA
válasz
KillerKollar
#9328
üzenetére
Ezt sokszor olvastam már. Nincs CryEngine 4. Mostantól csak CryEngine van. De ha verziózni akarunk, akkor ez a CryEngine 3.4.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#9343
Abu85
HÁZIGAZDA
KillerKollar
#9332
Abu85
HÁZIGAZDA
válasz
KillerKollar
#9332
üzenetére
Semmi gond. Csak máshol is láttam ezt a 4-est, és nem igaz.
Persze. A 3.4-es CryEngine az elég új. A Lichdom és a Ryse is ezt használja, bár a legújabb a 3.5, de arra még nem jelent meg játék.
Valszeg egyébként, ahogy jön rendbe a Crytek anyagi helyzete úgy elkezdenek majd GeForce-ra is optimalizálni. A 3.4-es CryEngine láthatóan csak GCN-re van igazán jól optimalizálva. Talán a 3.5 is, mert ott a Mantle kapott fókuszt, de lesz még új verzió később.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#9352
üzenetére
Így van. Biztosan nem ilyenek lesznek. Nem mondom, hogy minden paraméter hülyeség, de egy részük az, nagyon az. Én nem értékelnék olyan forrást, amely szerint 1024 bites buszra lehet rakni 4 GB memóriát. Ha valaki ezt leírja úgy, hogy eközben a Hynix HBM termékek listázva vannak (tehát a specifikációik publikusan elérhetők), annak bizonyosan gőze sincs az egészről.
![;]](//cdn.rios.hu/dl/s/v1.gif)
Ahhoz még "kici kínai munkás" forrás sem kell, hogy értelmezni lehessen a Hynix listázott termékeinek specifikációját. Világosan le van írva, hogy 1 GB-nyi memória 1024 bites buszra rakható rá. Ha 4 GB-ot akar valaki, akkor 4096 bites buszra van szükség. Ez nem spekuláció, hanem a Hynix friss termékkatalógusa alapján egy tény (második oldal).[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az AMD éppen érkező, vagy jövőbeni új grafikus processzorainak kivesézése, lehetőleg minél inkább szakmai keretek között maradva. Architektúra, esélylatolgatás, érdekességek, spekulációk, stb.
- BESZÁMÍTÁS! MSI GeForce GTX 1050 Ti 4GB LP GDDR5 videokártya garanciával hibátlan működéssel
- BESZÁMÍTÁS! ASUS TUF RX 7900XTX O24G 24GB GDDR6 videokártya garanciával hibátlan működéssel
- BESZÁMÍTÁS! ASUS ROG STRIX RTX 3080 10GB GDDR6 videokártya garanciával hibátlan működéssel
- Gainward 1660 super 6 GB VGA kártya olcsón!!!AkciÓÓ!
- XFX RX 6800 SWFT - 3 év ALZA garancia - eladó!
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen