nagyon informatív ez a kisregény, csak éppen semmi köze ahhoz, amit kérdeztem. 2007-2008-ról van szó - akkor DX11 még nem volt sehol. akkor is szartak a fizikára és az AI-ra, most is. nehéz ebben nem közös okokat látni, még akkor is, ha jelenleg nem csak a lustaság az akadály.

Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

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.

jó ez a beszélgetés.
#1 mi volt 2007-ben?
#2 hát 2010 után az a helyzet, hogy ...
#3 goto #1

úgy nem nagyon fogunk előremenni, hogy mindig a DX11 problémáit hozod fel, amikor a megelőző időszakról van szó

amúgy meg, ha minden shooterben olyan AI lenne, mint a FEARben, akkor hajlanék rá, hogy valami összefüggést sejtsek, annak ellenére, hogy a négymagosok megjelenésével az egyszálon üzemelő API miatt pont keletkezett extra CPU power, és a mostanában általad rengeteget emlegetett CPU time locknak még híre-hamva nem volt. azonban a legtöbb AI lényegesen ostobább, úgyhogy kénytelen vagyok továbbra is arra gondolni, hogy szartak rá. és a többség most is szarik, maximum a DX11 bajait kényelmes felhozni ürügyként.

Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

#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.

Viszont a program nem jutott több erőforráshoz ezekkel sem.

no itt van a lényeg. de, persze, hogy több erőforráshoz jutott - csak ki kellett volna nyújtania a "kezét".

Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

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.

ember, milyen erőforrást vettek el a driverek 2007-ben, amikor totál egyszálon ment minden?

Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

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.

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.

azt nem lehet érteni, hogy miért nem a problémával foglalkozol, és miért az aktuális vesszőparipádat hajtogatod helyette utoljára: a probléma az, hogy a FEAR óta semmi AI fejlődés nem volt. tegyük fel, hogy a DX11 mostanra tényleg annyira szar lett, mint ahogy lefested - ez akkor sem magyarázat arra, hogy 2006 és 2010 között miért nem volt semmi generál előrelépés AI-ban. számítási erőforrás volt, szakértelem valószínűleg szintén volt - marad az, hogy nem szántak rá pénzt. szinte senki.

[ Szerkesztve ]

Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

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.

Sziasztok, jövőre várható valami új vga család?

Az élet olyan mint a motor, ha nem megy akkor be kell rúgni..

a DX11-et akár még el is hiszem (bár jóval kevésbé sarkított formában, mint ahogy itt szerepel), a többit nem, tekintettel arra, hogy évekig azért szidták a DX-et, mert egyetlen szálat használ.
az pedig, hogy az Uncharted és még 1-2 exkluzív játék készítői igényesebbek az átlagnál, nem jelenti azt, hogy a PC-ben van a hiba...

(#8679) letepem: komolyan? feltettem ugyanazt a kérdést kb. 5x 2007-tel kapcsolatban, és 5x visszakaptam, hogy a DX11 ígymegúgy. ha ez Neked válasz, akkor javaslok egy értelmező olvasás tanfolyamot.

Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

Elvileg igen

Többiek:

Nyomjátok csak nyugodtan olvassuk

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.

na, még a végén eljutunk valahová

Viszont a driverek már 2006-ban több szálon működtek, tehát az erőforrást elvették

tényleg itt a probléma forrása - ez a következtetés ebben a formában nem állja meg a helyét. a többszálúsítás egy lehetőség, egyáltalán nem jár szükségszerűen resource lockkal. ha jól rémlik, kényszerű lockolások nVidia oldalon a FW 300-as szériában bukkantak fel - volt is gond az első driverekkel akkoriban.

Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

Nem szerinte nem,és szerintem se!

★★★★★ I got too much soul, rhythm and blues R&B ya see, all that's cool, but hip-hop and rap yeah that's where my heart's at Even back when I used to break on a box ★★★★★ "Chief Rocka"

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.

gondolom, nem szándékosan, de ezzel a hozzászólással némileg felülírtad a korábbi érvelésedet. eddig az volt a mondásod, hogy a driver elveszi az erőforrásokat, és a programok nem férnek hozzá - itt most ez arra módosult, hogy a driver CPU-használata kiszámíthatlan, és ezért a fejlesztők félnek hozzányúlni a CPU-erőforrás egy bizonyos részéhez, mert benne van a pakliban, hogy ütköznek a driverrel, és kontrollálhatatlan belassulások keletkeznek. maradjunk ennél a verziónál?

Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

Én nem látok itt ellentmondást. Ott az erőforrás, de nem tudod használni, mert összeakadsz a driverrel és rossz lesz az eredmény.

Tehát a driver elveszi az erőforrást, hiszen fenn kell neki tartani, tehát nem férsz hozzá, nem tudod használni.
Tehát a jelenlegi modell rossz hatékonyságú emiatt. Ráadásul ott van még az API overhead-je is.

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.

(@HSM: elég komoly a különbség, az alábbiak miatt: )

érdemes lenne a fogalmakat rendbetenni. ha fizikailag nem elérhető az erőforrás (mert valaki lockolta), az egy dolog, ott sok mindent nem lehet tenni. viszont ha "csak" arról van szó, hogy van esély arra, hogy összeakadjon a program a driverrel, akkor ez az esély (nevezzük kockázatnak) számszerűsíthető - mind az összeakadás valószínűsége, mind a hatása (ie. mennyi időt veszít az ütköző processz). sőt, még hierarchizálni is lehet - mennyi az esélye az ütközésnek 1 szálon, 2 szálon, stb. ebből fel lehet építeni egy modellt, amiből kiesik, hogy mennyi CPU-időt érdemes "feláldozni" a driver számára a beakadások minél nagyobb részének elkerülése érdekében (mert ugye Windows-on 100%-os elkerülésről eleve nem beszélhetünk). ez az engine (és részegységei) toleranciájától legalább annyira függ, mint a szóban forgó drivertől - más szóval, nem törvényszerű, hogy a valamelyik lenti ábrán kisraffozott erőforrás senki számára semmilyen célra nem hozzáférhető.

időzítés tekintetében: vélelmezem, hogy csak az utóbbi időben jutottak el odáig a különféle cégek fejlesztői (és nem feltétlen mindenki), hogy már több magot is odadobnak a drivernek. az biztos, hogy a 2013-as Crysis 3 még úgy tekerte az akkori 2500K-m mind a 4 magját, mint a szél. szóval továbbra is marad nyitva a kérdés, hogy 2007-ben mi más okuk lehetett a fejlesztőknek / kiadóknak az AI hanyagolására, mint a spórolás és / vagy a valós user igények hiánya

amúgy meg lehet nézni a kérdést a másik irányból is - lássuk meg, hogy a low level API-k elterjedése után mennyire fog fejlődni az AI. nagy összegben mernék fogadni, hogy néhány lelkes próbálkozáson túl csak kisebb inkrementális előrelépések lesznek. a fizikára több esélyt látok.

[ Szerkesztve ]

Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

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.

Mentve, 10 év múlva ha írok jöhet a 3 luxus Ferrari a házam elé.

Én személy szerint hiszek benne, hogy a Mantle elindított egy új utat, és ha nem is idén, nem is jövőre, de meg fogjuk látni az eredményét az egész új rendszernek. Ami játék támogatja már lehet látni a változást, az más kérdés, hogy kevesen építenek rá.

[ Szerkesztve ]

D4 klán: HunPH - invért privát rám