Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Nem. Itt az a probléma, hogy a SEGA stratégiai váltásra készül. A Shogun 2 óta a Total War széria technikailag és játékosbázisban is nagyon süllyed. Az NV-t nem érdekli a stratégiai játék, az Intelnek pedig a Rome 2 sem jött be. Maradna az AMD, ahol van képzettség, hogy összerakják a játékot úgy, ahogy a Shogun 2-t, de a Gaming Evolvednél magas a megugrandó léc. Nem azt mondom, hogy a CA-t visszautasítanák, ha végül odamenne hozzájuk, hogy rakják már rendbe a játékot, de kétszer is meggondolnák, hogy megéri-e. Eleve a CA gondja, hogy a Rome 2-t bugosan adták ki, és a DLC-kért is sok pénzt kértek. Ezzel rengeteg vásárlót elvesztettek. Az Attila is bugos sajnos, de gondolom kellett a pénz, így kiadták. Csak ebből megint csalódás lesz a vásárlóknak.
-
Abu85
HÁZIGAZDA
A SEGA-nál az AMD-nek az Alienre és a Sonicra van szerződése. A Total Warból utoljára a Shogun 2-nél volt partner az AMD. A Rome 2-nél ezt a szerződést felbontották, mert nem ugrotta meg a CA a minőségi lécet, még az AFR-t sem támogatták. A CA a Rome 2-re az Intellel állt össze, míg az Attila már az Intelnek sem kellett, mert csak a baj volt a Rome 2-vel is.
Nyilván újra kinyithatná az AMD a pénzcsapot, de a helyzet az, hogy ott van nekik a Stardock és a Firaxis, akik sokkal jobb munkát végeznek, mint a CA/SEGA. Az Intel és az NV pedig leszarja a SEGA-t, mert a kiadó eleve távolodni akar a PC-től.
Majd egy év múlva az Attila-ból is lesz egy bugmentes játszható verzió, mint ahogy a Rome 2-t is kiadták újra. Persze azért is fizetned kell. Manapság sajnos a Total Warral ez így megy. -
Abu85
HÁZIGAZDA
Mert a Keplert azért az elmúlt két évből annyira azért kiismerték, hogy nagyjából tudják mire érzékeny. A Maxwell alig pár hónapos, tehát arról lényegében semmi tapasztalat sincs. Ez még távolról sem jelenti egyébként, hogy a Kepleren jól fut, csak van róla tapasztalat.
(#3150) hpeter10: A Crytek messze nincs krízisben. Eladták az egyik stúdiójukat, az egyik IP-jüket, és kötöttek pár fontos üzletet. Most aránylag biztonságban vannak, tehát nyugodtan ki lehet dolgozni a jövőbeli stratégiát.
-
#3149
Abu85
HÁZIGAZDA
#Morcosmedve
#3147
Abu85
HÁZIGAZDA
válasz
#Morcosmedve
#3147
üzenetére
Nagyon egyszerű a dolog ez. A fejlesztőnek tudnia kell, hogy a célzott architektúrára hogyan lehet optimális kódot írni. Nyilván, ha pénzszűkében van a fejlesztés, akkor sokkal biztonságosabb egy olyan architektúrát célozni, amiről tudják hogyan működik. Már csak azért is, mert így nem érik a fejlesztőket kellemetlen meglepetések.
Itt valójában nem pénz kell, hanem dokumentáció, mert akkor meg lehetne spórolni rengeteg kutatási időt, és helyből tudnák a fejlesztők, hogy miképp lehet Keplerre és Maxwellre gyors kódot írni. Persze a CryEngine távolról sem áll rosszul, mert még mindig nagyon jó motor, annak ellenére, hogy anyagilag a Crytek nem volt rendben. Tehát fatális problémák távolról sincsenek, mert a Crytek még mindig ért hozzá. -
Abu85
HÁZIGAZDA
válasz
daveoff
#3146
üzenetére
Valószínűleg a CryEngine új verziói egyik architektúrán sem futnak tökéletesen, ami az anyagiak szűkössége miatt érthető. Viszont a PS4 és az Xbox One konzol kritikus és az arra készült optimalizálás PC-s szintre átmenthető, ami GCN-nel látszódni fog.
A pénz az nagyrészt marketingtámogatás formájában jelenik meg. Az NV-nek már nincs olyan programja, ami a programfejlesztést anyagilag értékelhető szinten támogatja. Régen a G80-as időkben volt, de ma már nem cél, hogy a program optimalizált legyen, mert nem sarkal hardvervásárlásra.
Nézd, ha az NV nem közöl az architektúráiról dokumentációt a fejlesztőkkel, akkor ők miért törjék magukat azon, hogy optimálisan fusson? Persze jó lenne, de visszafejteni a nem dokumentált architektúrák működését nem olcsó és nem kevés időt igényel.
-
Abu85
HÁZIGAZDA
Már korábban többször is írtam, hogy a CryEngine újabb verzióinál a Cryteknek anyagi gondjaik voltak, így csak a kritikus architektúrákra optimalizáltak, vagy ahol ez relatíve olcsón megoldható. A GeForce esetében Kepler/Maxwell egyrészt nem kritikus, másrészt a dokumentációk hiányában nem oldható meg olcsón sem. Ezért jönnek ki ilyen eredmények az újabb CryEngine játékokkal.
-
Abu85
HÁZIGAZDA
válasz
letepem
#3108
üzenetére
Az egyedüli és egyben legfontosabb cél, amit ezzel az iránnyal elindítanak az a fejlődés teljes kontrollja. Az AMD kihasználja a rendszer gyengeségeit, a Microsoft és a Khronos lassúságát, hogy évekig tartó egyeztetés mire új funkciók bekerülnek. Nem véletlenül van egyeztetve, de az AMD ezt ellehetetleníti. Az új dolgokat behozzák egyeztetés nélkül, és ez már kényszerhelyzet arra, hogy a többiek cselekedjenek. Az iparág azért lépet ennyire gyorsan a low-level irányba, mert próbálják megakadályozni azt, hogy az AMD mondja meg a tutit. Nekik ebben ez lesz az üzlet. Hidd el a legkevésbé sem tetszik az az Intelnek és az NV-nek, hogy az AMD csak úgy nélkülük bármit bevezethet és kikényszerítheti rá a támogatást.
-
Abu85
HÁZIGAZDA
Még mindig keveredés van. Az AMD-nek mindegy, hogy melyik low-level API-val írják a programot.
Az AMD API-jának célja a fejlődés gyorsítása. Nem vicc, de a DX12-ben lesznek olyan funkciók újként eladva, amelyet 2009 óta tudnak a hardverek. Ez elfogadhatatlan a fejlesztők nézőpontjából.
Ez sajnos a jövőben is így lesz, mert van pár power programozó a világon, akik miatt nem éri meg bizonyos képességeket engedélyezni, nem éri meg pénzt ölni bele. De az AMD-hez lehet menni, majd odadörgölhető a Microsoft és a Khronos orra alá, hogy az AMD API-ja már tudja, ideje lépnetek.
Ez egy eszköz lesz az innováció folyamatos kikényszerítésére. -
Abu85
HÁZIGAZDA
válasz
FLATRONW
#3090
üzenetére
Az teljesen világos, hogy van hova fejlődni, mert a hajszimuláció gyakorlati megvalósítása csak most indult. De a Hairworks egyrészt úgy kerül több erőforrásba, mint a TressFX, hogy nem csinálja meg az önárnyékot, nincs rajta semmilyen analitikai élsimítás, és spagettis az egész hatása sorrendtől független átlátszóság nélkül. Oké elfogadom, hogy az NVIDIA-nak ezeket nehéz beintegrálni a Hairworksbe, mert akkor nem lehetne gyorsan beépíteni a motorokba, de azt már nehéz lenyelni, hogy a minőséget eredményező tényezők nélkül is több ideig tart a feldolgozás, mint a TressFX-nél.
HBAO-nak mindig az volt a gondja, hogy rengeteg hamis árnyékot generált. Ezt sosem tudta levetkőzni, bár javult a helyzet. De nem miért nem lépünk. Ott az Obscurance Fields. -
Abu85
HÁZIGAZDA
Nyilván az effekt koncepciójának komplexitása is számít. A HBAO+ esetében hozzá kell tenni, hogy már az NVIDIA és az AMD driverei is lecserélik a shadereket. Ez segít a sebességen, de a minőségétől nem dobod el magad.
[link] - Ebben van egy kapáló macska HairWorks-szel. Tisztán látszik, hogy hiányos az egész.
A GameWorks-re azt lehetne felvetni, hogy ha az NV nem ebbe ölné az erőforrásait, hanem segítené a fejlesztők egyéni igényeit, akkor sokkal jobb effektek születnének ugyanazokra a problémákra. Viszont az NV már nem akar a minőséggel és a sebességgel foglalkozni. Valószínű, hogy az elmúlt években rájöttek, hogy ez nem fontos a vásárlónak, ha már a felhasználóik 80+%-a felbontást sem tud önállóan állítani.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#3082
üzenetére
A Mantle-nek az a célja, hogy a fejlesztők igényeit kiszolgálja. Ha például Johan egyszer elköhögi magát, hogy neki kellene hozzáférés bizonyos GPU-n belüli regiszterekben tárolt adatokhoz, akkor a Microsoftnak ezt hiába mondja, elküldik a fenében, mert az igénye borzalmasan réteges és nem reprezentálja a tömeges igényt, így felesleges ilyen funkció a szabványba, de az AMD készséggel teljesíti az igényét, mert ezért csinálták az API-t.
Az, hogy a Mantle-t támogató motorok DX11 alatt is jól skálázódnak tulajdonképpen egy mellékterméke az iránynak. Azzal, hogy a fejlesztők megértették a low-level API-val a program oldali limitációkat, ezek kijavíthatóvá váltak. Ez olcsósítja a portolást, mert nem néznek hetekig ki a fejlesztők a fejükből, hogy mitől nem skálázódik a DX11 mód. -
#3081
Abu85
HÁZIGAZDA
Malibutomi
#3073
Abu85
HÁZIGAZDA
válasz
Malibutomi
#3073
üzenetére
A GameWorks az nem förtelem minőség, hanem ennyit lehet egy ilyen koncepcióval kihozni. Az a baj, hogy a GameWorks úgy lett beharangozva, hogy extrém minőséget kínál ultragyorsan, meg úgy odabasz, hogy megnyalod a tíz ujjad. Ezt technikailag nem lehet megcsinálni a GameWorks middleware-rel, mert nem ad lehetőséget a fejlesztőnek, hogy optimalizálja a sebességet, és az NVIDIA-nak, hogy optimalizálja a minőséget.
Egy totális félreértés az, amiben a játékosok élnek, hogy a GameWorks célja a minőség és az optimalizálás. Nem, ennek a rendszernek a célja, hogy gyorsan beépíthető legyen xy effekt a játékokba. Szar lesz a minőség és a sebesség is, DE! pár nap alatt működik. Baromi gyorsan beépíthető és stabil. A minőség és a sebesség másodlagos. -
Abu85
HÁZIGAZDA
A GameWorks minőségileg és sebességben mindig elmaradott lesz. Két gond van:
A licencelő megkapja a middleware-t, és neki kell az effekt követelményeihez szabni a motort. Ettől még lehetne jó a rendszer, csak nyilvánvaló, hogy azért kell a GameWorks, hogy időt spóroljon meg. Az integrálás optimalizálásának hiányában mindig lassan fut majd az effekt minden hardveren.
A minőség pedig az NVIDIA problémája. Ha elkezd ezeknek az effekteknek minőséget adni, például a HairWorksnek analitikai AA, vagy önárnyékot, akkor nő annak az esélye, hogy a fejlesztő nem tudja majd beépíteni az adott motorba, mert rengeteg hibát fog generálni. Ezért az NVIDIA a minőséget szándékosan elveszi, hogy megmaradjon az egyszerű beépíthetőség. -
Abu85
HÁZIGAZDA
Nem bűzlik semmi. Régi a kód. Az AMD-nek már nem kell a StarSwarm, így nem éri meg visszaírni bele a Nitrous fejlesztéseit. Valamilyen szempontból ez az egész egy üzlet. Az Oxide nem jókedvből fejleszti ezeket a programokat, hanem azért, mert fizetnek érte a gyártók, hogy meg tudják mutatni az új API-k, technikák képességeit. Viszont, ha egy gyártó valamit nem igényel, akkor felesleges vele foglalkozni, mert az Oxide emellett egy játékot is fejleszt, és oda is kell az erőforrás.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#3052
üzenetére
Nem érted mit írtam le. A Mantle használata csak akkor nem ajánlott, ha az adott fejlesztő mindent meg tud csinálni DX12-vel. De van számos dolog, amit DX12 nem támogat, míg a Mantle igen. Például a fedettségmintákat, amit ha egy analitikai élsimítás esetleg használ, akkor a DX12-n nem futtatható le ez az algoritmus. Például ilyen a Nitrousba épített új AA is. Teljes minőségben csak Mantle-ön működik, mert a DX12-ből hiányzik az a funkció, amivel fedettségmintákat lehetne szerezni.
Ha egy olyan eljárást igényel a program, amit a DX12 nem támogat, akkor mindenképp hozzá kell nyúlni a Mantle-höz. Ezért maradnak páran rajta. Viszont, ha mindenféle extravagáns, egyedi, csúcsszuper effekt vagy AA nem prioritás, akkor elég a DX12, mert az is megadja azt a grafikai minőséget, amit a fejlesztő elgondolt.(#3054) gbors: Azt mindenképp bele kell számolni, hogy az Oxide a világ két legjobb programozóját alkalmazza, tehát az, hogy ők a low-level API problémáival megbirkóznak az nem meglepő. Ha nem birkóznának meg a feladattal, akkor nagy gondban lennénk.
A görbét akkor lehetne megállapítani, ha a Mantle és a DX11 kód nem lenne egy éves, a DX11 deferred context ezért fagy ki, mert az új optimalizálást nem írták vissza a StarSwarmba, pedig ezt az NV megoldotta az elmúlt év őszén. Mint írtam, az AMD-t már nem érdekli a StarSwarm, tehát nem igénylik, hogy az új Mantle pathot visszaírják bele. Egy másik demóval akarnak kampányolni 2015-ben és annak a teljesítménye a fontos.(#3065) HSM: A submission time-ban az a jó, ha kisebb. Erre ráoptimalizált a Nitrous, csak ezt is vissza kell írni a StarSwarmba ahhoz, hogy ennek az eredménye látszódjon. De valszeg csökkentené ezt az időt a specifikus Mantle batch optimalizálás kikapcsolása is. Nem tudom, hogy ez aktív volt-e vagy sem.
-
Abu85
HÁZIGAZDA
A fejlesztők felelőssége megnő ez nem vitás. Nem véletlenül megy el arra az AMD partnerprogramja, hogy a programozóikat odarakják a partnerként szolgáló motorprogramozók mellé. A driver jelentősége nagyrészt megszűnik, mert a motorba épített vezérlés teljesítménye lesz a kulcs. Valószínű egyébként, hogy maga a terméktámogatási ciklus sem fog annyira változni. Azért költöznek a cégek programozói be a stúdiókba, hogy biztosítsák az optimalizálást a régebbi architektúrákra.
Én önmagában a top stúdióknál ezt nem látom gondnak. John Carmack már elment, de a piac "kitermelte" magának az új zseniket: Johan Andersson, Dan Baker, John Kloetzli, Josh Barczak, Kevin Floyer-Lea, Michael Bailey, Emil Persson, stb. Ezekben a programozókban lehet bízni, pláne addig, amíg a cégvezetéstől (EA, SEGA, Firaxis, Avalanche) dől a pénz a fejlesztésre. A gondot a kevésbé tehetős stúdiók jelentik, ahol nem mondom, hogy a szaktudás feltétlenül hiányzik, de a pénz mindenképp szűkös.(#3060) TTomax: A StarSwarm a tervezett feladatát most is ellátja. Megmutatja ma is, hogy a Nitrous képes 100k batcht nagy sebességgel kezelni low-level API-val. Ma is látszik minden gyártónál, hogy mennyit gyorsulnak az új API-kkal a rendszerek, függetlenül attól, hogy mennyire régi kódra épülnek az egyes leképzők. Ha az lenne a célja a tesztnek, hogy konzisztens eredményeket adjon és össze lehessen vele hasonlítani a VGA-kat, akkor nem két AI véletlenszerű csatáját látnád a képernyőn, hanem egy előre felvett jelenet visszajátszását, hogy minden mindig ugyanúgy történjen. Ilyenkor a lefuttatott tesztek eredményei nem 30, hanem 3 százalékos varianciát mutatnának csak.
A DX12 azért került bele a StarSwarmba, mert a Microsoft ezt demózni szeretné, ahogy az NV is. Az AMD a Mantle-t szeretné demózni, és nekik egy másik teszt készül. Ezekkel egyébként semmi gondja nincs az Oxide-nak. Üzletileg is teljesen elfogadható, hogy az MS és az NV elsődlegesen arra szeretné felhívni a figyelmet, hogy mennyivel jobb a DX12 hatékonysága a DX11-nél, csak az AMD-nek ez már nem elég. Ők már egy éve megmutatták a low-level irány egyik előnyét ebből a szempontból, más előnyökre szeretnének koncentrálni 2015-ben. -
Abu85
HÁZIGAZDA
Igen valószínű, hogy a hardverfejlesztések lassulni fognak. De legalábbis egy olyan modell mindenképp fontos lehet, hogy az egyes új architektúrákról jöjjön egy első fecske. Egy olyan termék, amelynek az üzleti sikere abszolút nem lényeges, viszont a fejlesztőknél legyen egy hardver arra vonatkozóan, hogy kezdjék el megtanulni a változásokat. Lásd a Radeon R9 285. Nem lényeges maga a termék, mert annyiba kerül, mint a 280 és kb. ugyanolyan gyors (jó picit gyorsabb és picit drágább a 285, de kb. egy szintre van rakva). Tehát igazából a terméknek nincs különösebb jelentősége kereskedelmi szinten, de a fejlesztőknek nagyon fontos, mert a Tongában alkalmazott architektúra lesz az új GPU-kban.
Ez modell azért is fontos, mert tényleg számolni kell azzal, hogy az új architektúraverzió lassulni fog, tehát ha készül egy olyan termék, amely mondjuk 20%-kal gyorsabb az elődjénél, akkor azt csak akkor szabad kiadni, amikor a legtöbb játékban, már ott van rá a low-level optimalizáció, tehát előre piacra kell dobni egy "fecskét", egy terméket, ami csak a fejlesztőknek szól, és kereskedelmi szinten nem számít, hogy mit teljesít.
Persze itt át kell majd értékelni sok dolgot. Például azt, hogy a nyers teljesítmény mellett bejön a képbe egy olyan tényező, hogy a szoftver jelentősen meghatározza a gyakorlati sebességet. Mai példát előhozva, simán tudsz venni 280-at és 285-öt. Úgy láttam Iponban van mindkettő, vagy más boltban, és kb. azonos áron ... +/- 5k forint. Átlagos gondolkodással megnézed, hogy a 280-nak 384 bites a busza, és 3 GB memóriája van, és ugye a tesztekben is kb. hasonlóan gyorsak, hát akkor legyen több memória. De egy átlagos felhasználónak fogalma sincs arról, hogy a Tonga mire képes. Például nemrég derült ki, hogy az egyedüli hardver a piacon, ami tud tile poolt, és a stateless compute hatékonysága is lényegesen jobb, mint a 280-nak. És itt jön az a tényező be, hogy ha a fejlesztők ezt kihasználják, márpedig a low-level API-k ezekre végre lehetőséget adnak, akkor a 280 lemarad, de nagyon.
Az is egy új dolog, hogy hajlamosak vagyunk a múltból kiindulni. Számos újítás került bele a DirectX 11.2-be és majd sok újítás lesz a DX 11.3-ban is. Például a Tiled Resources funkciót sok fejlesztő várta és senki sem épít rá ma. Ez nem azért van, mert rossz a funkció, ma is nagyon jó, csak korlátozottan használható, ha nem érhetik el közvetlenül a memóriát. Magát a motort úgy kell felépíteni, hogy a Tiled Resources funkciókhoz tervezni kelljen az egészet, erre még van middleware is, amit licencelni lehet és a végén tulajdonképpen kapsz egy funkcionálisan működő rendszert, aminek ugyanakkor a szoftveres oldali késleltetése akkora, hogy a gyakorlatban már nem tudsz vele programot szállítani PC-re. Erre mondta másfél éve Dan Baker, hogy tök jó funkciók vannak az API-kban, de nem tudsz egyikhez sem hozzányúlni, mert nagy késleltetést eredményez. Hiába van benne a tudás a hardverben és API-ban, ha az csak elméletben hangzik jól, de a gyakorlatban bevethetetlen. Ezen a teljes low-level irány nagyon sokat fog változtatni, mert közvetlenül hozzáférést ad a videomemóriához. A Tiled Resources funkciót el lehet dobni, nem kell middleware, és más dolog. Ott a videomemória és fel lehet rá építeni mindenkinek egy saját Tiled Resources technikát, magába a motorba. Innentől kezdve elkezdik használni a fejlesztők azokat a dolgokat, amelyek évek óta léteznek hardveres szinten, de eddig nem tudtak hozzányúlni, mert baromira nem jó az a programozási modell, hogy az API megengedi, hogy létrehoz és törölj puffereket, ráadásul óriási teljesítménybüntetés mellett. -
Abu85
HÁZIGAZDA
Nem lesz itt lényeges változás a pénz elosztásában, de azt látni kell, hogy amíg a DX11-hez komoly pénz kellett a driverbe, addig a low-level API-knál erre nincs szükség. A GPU "vezérlésének" a 80%-át nem a gyártó fogja írni, hanem az adott szoftver programozója. Ennek a következménye az lesz, hogy a driverfejlesztés is az eddigi erőforrás töredékét igényli majd. Viszont ezeket a rendszerprogramozókat alkalmazni lehet más területen. Például elküldeni az egyes stúdiókhoz a vezető motorprogramozó mellé, hogy adjon neki a tanácsokat, ami fontos, mert mostantól a motorprogramozótól függ a hardver teljesítménye.
Anyagi szinten tehát nem lesz lényeges változás, csak máshogy kell befektetni ezeknek az alkalmazottaknak a tudását. -
Abu85
HÁZIGAZDA
Ez a teszt valójában nem arra készült, hogy VGA-kat lehessen összehasonlítani. Erre a teszt fejlesztője is felhívta korrábban a figyelmet. Maga a tesztnek a varianciája magas. Két egymas utáni futtatással is lehet 30% az eredményen között. Emellett az is számít, hogy az egyes pathokban éppen milyen optimalizálás aktív. Ez igazából egy belső engine teszt a fejlesztőknek, csak kiadták, hogy megmutassák a világnak, hogy nem kamuznak, amikor arról beszélnek, hogy a motorjuk 100k batcht lezavar 60 fps-sel.
-
-
Abu85
HÁZIGAZDA
A DX11 lehet jobb, mert nagyon régi a kód. A deferred context bekapcsolására szétfagyott. A Nitrousban ezt már javították, csak nem volt értelme berakni a StarSwarmba. A Mantle is fejlődött az elmúlt egy évben. Mivel ez csak egy teszt, amire eddig nem épített senki, nem volt értelme folyamatosan fejleszteni. Az Oxide számára fontosabb a fejlesztés alatt álló játékuk.
-
Abu85
HÁZIGAZDA
Ahogy többször is mondtam, low-level API-val a hardver sebessége kismértékben szól bele az eredménybe. Az optimalizálás számít.
Azt tudni kell, hogy a DX11 és Mantle kód egy évvel öregebb. De ez csak a StarSwarmra igaz, a Nitrousra nem, csak nem volt fontos frissíteni a StarSwarmot, mert az AMD a GDC-n egy másik demót mutat be. Az MS és az NV demózza a StarSwarmot. -
Abu85
HÁZIGAZDA
válasz
daveoff
#2967
üzenetére
Mivel a probléma a DX11 többletterhelésével van, így itt lehet sebességet nyerni. Ha csökkented a rajzolási parancsok számát a látótávolság csökkentésével, akkor sokat gyorsul a program. Úgy 50% környékére nyugodtan le lehet venni és lényeges lesz az előrelépés, miközben a játék nagy részében nem nagyon fogod látni a különbséget.
Ha program oldali javításra gondolsz, akkor a DX11-en belül nem igazán lehetséges. Low-level API kell hozzá. A Chrome 6 struktúrája egyébként ennek biztosan megfelel, mert konzolokon alacsony szintű az elérés. Ezért nagy a látótávolság ott. -
#2966
Abu85
HÁZIGAZDA
Malibutomi
#2965
Abu85
HÁZIGAZDA
válasz
Malibutomi
#2965
üzenetére
Mert egy olyan játék, amelyhez ~5 GHz-re húzott Sandy kell, hogy egyáltalán 30 fps-t adjon a külső területeken, és a magaslatokon nagyon rossz üzenetet közvetít a PC-s játékpiacról. Ehhez az AMD és az Intel semmilyen formában nem akarja adni a nevét. Ez nem az a jövő, amit ezek a cégek elképzeltek. Innentől kezdve az egész egy elvi kérdés. A Dying Light esetében a kártya mindegy. A külső területeken 20-30 fps között sorakozik mindegyik, mert procilimit van. Ezért teszteltek belső területen, de az meg nem ad képet a játékról.
(#2964) FLATRONW: A profil csak a belső területeken ér majd valamit. A külső területeken CPU-limit van.
-
Abu85
HÁZIGAZDA
válasz
Laja333
#2934
üzenetére
Azért az AMD-nek jelentősen egyszerűbb a helyzete, mert ultramobilban nem érdekeltek, míg az NVIDIA igen, illetve az AMD-nek van egy olyan szoftverpartner az EA személyében, amely kiadó érdekelt az AMD technológiáinak kihasználásában, míg az NV mellett egy PC-vel nem is törődő Ubisoft van. Leegyszerűsíthetjük a kérdést, hogy x fejleszt és y nem, de ennél bonyolultabb a helyzet. Inkább az a fő szempont, hogy az AMD-nél van értelme az EA-nek fejleszteni. Az Ubisoft számára viszont a PC két év múlva is nyűg marad, ami más stratégiai célokat jelent az NV-nél. A kulcsszó az alkalmazkodás.
-
Abu85
HÁZIGAZDA
válasz
Laja333
#2917
üzenetére
Nem gyorsult/lassult semmi. Legalábbis lényegesen semmiképp, maximum valami probléma miatt, de ez általános dolog. Ami történt, hogy az új játékok máshogy működnek, mint az egy évvel régebbiek. Az olyan dolgok, mint a PBS jobban fekszik az AMD architektúrájának, lásd a Ryse: Son of Rome. És amely játékok erősebben építenek erre a technikára ott erősebbnek látszanak a Radeonok. Illetve jött pár olyan játék is, amely nem igazán memóriakímélő, mint az Assetto Corsa. Itt sokat ér a nagyobb memsávszél. Ahol ezek a tényezők egy-egy játékkal bekerültek ott jobban teljesít majd a Radeon.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#2914
üzenetére
Nem ezt írtam. Azt írtam, hogy az AMD API-jára csak azok fejlesztenek majd, akiknek DX12 kevés, például az EA. De egyébként annak tényleg nincs értelme, hogy két API-t támogasson a fejlesztő, miközben minden tervezett dolgot meg tud csinálni a DX12-ben. Ilyenkor egyszerűen teljesen felesleges egy másik API, csak az időt viszi el, de nem ad semmi extrát.
(#2911) Egon: Kettő kéz kell hozzá, mert hat játék támogatja ma. Egyébként azt tudni kell, hogy fél tucat Q4-re tervezett játékot eltoltak Q1-Q2-re. Nyilván ezzel a tényezővel nem lehet mit kezdeni. Ha egy játék nincs kész, akkor nem adják ki.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#2850
üzenetére
Ez rendben van, csak a GameWorks esetében nem cél a tökéletesség. Ha van ugyanarra a gondra gyorsabb és jobban kinéző alternatíva, akkor az sem baj, mert a GameWorks nem versenyzik közvetlenül vele.
Nagyon egyszerű a TressFX-HairWorks esete. Aki csúcsteljesítményt és csúcsminőséget akar, annak van pénze önálló munkára, tehát semmi esély, hogy a HairWorksöt válassza, mert zárt a forráskódja, és ezért nem lehet a végletekig optimalizálni. Aki viszont egyszerű beépíthetőséget akar, és kevés pénze van, az nem fogja a TressFX-et választani, mert úgy sem tudja majd a végletekig optimalizálni, és a kevés pénz miatt úgy sem fogja a kódot átírni. Más a célközönség, ha szabad így jellemezni a fejlesztőket. -
Abu85
HÁZIGAZDA
válasz
daveoff
#2848
üzenetére
Persze csak időbe fog kerülni. De nem valószínű, hogy a Hairworks olyan nagy fókuszt kap a GameWorks csomagon belül. Sokkal több erőforrást fognak ölni azokba a rendszerekbe, amelyeket tényleg használnak is a fejlesztők, nem csak egy-két érintett. A Hairworks igazából nem éri meg a pénzét, mert relatíve kevés céget érdekel. A HBAO+ és a PCSS már más tészta, mert többen érdeklődnek. Sokkal inkább ezek fejlesztésére fognak koncentrálni.
(#2847) Laja333: Az egy szimpla szimuláció, csak a haj modellje jól néz ki, de közelében sincs a GPU-s szimulációknak. Sőt, igazából több játék CPU-s szimulációjának sem.
-
#2846
Abu85
HÁZIGAZDA
Montesantos
#2841
Abu85
HÁZIGAZDA
válasz
Montesantos
#2841
üzenetére
Ezzel ők is tisztában vannak. Nem vakok ott az emberek. A gond itt a teljesítményigény. A HairWorks annyi idő alatt csinálja meg a tincsek, illetve a szőrük kialakítását, amennyi idő alatt például a TressFX végez az egész számítással, élsimítással, önárnyékolással és átlátszósággal, tehát mindennel. A HairWorks nincs ideje ezekre, mert a TressFX-hez képest legalább kétszer hosszabb ideig dolgozik a szőr/haj alapvető kirajzolásán. Nem marad idő azt minőségivé tenni, így az élsimítás például már a programra van bízva. Oldja meg a fejlesztő, hogy jól nézzen ki.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#2842
üzenetére
Minden ilyen szimulációs megoldás több fázisból áll. A TressFX és a HairWorks is. Röviden ez a pipeline kell a megfelelő eredményhez: szimuláció->leképzés és utóbbiban benne kell lennie az önárnyékolásnak és az élsimításnak, illetve ajánlott a sorrendtől független átlátszóság. Ennek az egésznek az egymáshoz tevezett kombinációja adja a minőséget.
A HairWorks problémája, hogy a leképzési fázis nagyon egyszerű önárnyékolást használ és semmilyen élsimítást nem tartalmaz, illetve nincs sorrendtől független átlátszóság sem.
Nagyon egyszerűen fogalmazva a szimuláció és a leképzés megvan, de ami hozzáadja a tényleges minőséget, vagyis eltünteti a spagettihatást (sorrendtől független átlátszóság), a szőr egyenetlenségét (élsimítás) az hiányzik a HairWorksből. -
Abu85
HÁZIGAZDA
Nincs igazán köze ehhez az XDMA-nak. Annyiban segít, hogy sokkal könnyebben paraméterezhető a CF vele, mint a hidas megoldással. De amúgy erre is ugyanúgy meg kell írni a profilokat, tehát az alapprobléma megmarad. Azért vezette be az AMD ezt a rendszert, mert megnövekedett az az adatmennyiség, amit a két kártya között másolni kell, és arra már nem volt elég a hidas megoldás sávszélessége. Ezért annyira erős a CF 4K-ban. Szimplán megvan a sávszél a PCI Express kapcsolaton keresztül.
Az XDMA igazából azoknak a fejlesztőknek fontos, akik nem a driverre bízzák magukat a multi-GPU-nál, hanem írnak egy saját megoldást Mantle-ben. Az XDMA-val ezt sokkal egyszerűbb megtenni, mint a hagyományos hidas összeköttetéssel. -
Abu85
HÁZIGAZDA
Az AFR frame pacing az AMD-nél is növeli az input lagot. Frame pacing nélkül mindkét cégnél jobb a lag. Bármit is választanak AFR mellett mindenképp lesz valamilyen hátrány, vagy a folyamatosság, vagy a lag. Ezek viszont egy GPU-s frame time értékek. Ide nem kell frame pacing.
A mikroakadásokért az egy GPU-nál azok a tényezők felelnek, amelyek a driverben dőlnek el. Például a shader újrafordítás. Tehát a mikroakadás mértéke attól függ, hogy a driver shader fordítója mennyire gyors. Itt van az a pont, amin már évek óta változtatni kellene az API-kban, mert megakadályozza a gyártókat, hogy jól optimalizáló shader fordítót írjanak. Az a fordító ugyanis lassabban fordít, mint a kevésbé jól optimalizáló opció. Az NV-nek azért vannak nagyobb frame time értékei, mert a shader fordítójuk relatíve lassú, ők gyors kódot akarnak mindenképp. Az Intel és az AMD gyorsabb fordítót használ, de nem fordítanak feltétlenül optimális kódot. -
Abu85
HÁZIGAZDA
válasz
deadwing
#2771
üzenetére
Mennyire egyenletes a képmegjelenítés. Értsd a kisebb érték kevesebb potenciális mikroakadást jelent.
(#2770) Laja333: Ez nem a hardver érdeme. A grafikus driver van az AMD-nél az egyenletességre beállítva. Ha az NV sem a nyers teljesítményre paraméterezné, akkor ok is tudnának alacsonyabb értékeket produkálni, csak akkor csökkenne az fps érték.
-
Abu85
HÁZIGAZDA
Nem a driver kérdése ez. Az NVIDIA számára mostantól a Maxwell a lényeges. Ha egy fejlesztő nem tud egy kódot gyorsra megírni, akkor jellemzően megkéri az NV-t, hogy optimalizálják helyettük. Ezt vagy megteszik vagy nem, de általában segítenek. Na most az NV ezt a kódot úgy írja meg, hogy a Maxwell legyen vele gyors, és a Kepler már nem érdekes, sőt az a jó, ha lassabb lesz. Ugyanez a GameWorks esetében, amit mostantól szintén Maxwellre optimalizálnak. Ez lassítja be a 780-akat, nem fontos már, hogy gyorsak legyenek. A Radeonok sem gyorsultak be, csak azokra az AMD ezt nem tudja megcsinálni, mert publikus a dokumentáció és a disassembler, így a fejlesztő képes ezekre a hardverekre optimalizálni. Az NV az architektúra elzárásával úgy írja meg a shadert ahogy akarja, mert a fejlesztő ISA dokumentáció és disassembler nélkül nem tudja megállapítani, hogy az optimalizált kód-e vagy sem, el kell hinnie, hogy az.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#2758
üzenetére
A TressFX nem konzolos effekt. Azt a Crystal Dynamics, az AMD, a Confetti és a Nixxes fejlesztette. Jogilag valóban az AMD-é az egész kód.
Azzal nincs gond egyébként, ha az AMD fejleszt egy effektet, mert annak biztos lesz PC-s portja, sőt csak olyanja lesz, hiszen a konzol csak egy porting guide-ot kap. A nyílt forráskódnak hála mindenki átportolhatja, de az AMD nem ad rá pénzt. Ez szvsz elég normális hozzáállás, hiszen leírják, hogy hogyan lehet a PC-re fejlesztett effektet PS4-re és XO-ra portolni, amit az a fejlesztő elvégez, akit érdekel. Ennyi.
A problémát azok az effektek jelentik, amelyeket az adott stúdió fejleszt. Lásd az Ubisoft a HRAA-val. A legjobb AA, ami valaha készült, hiszen driveres VSR/DSR minőséget ad FXAA teljesítményesésért cserébe. És ez nincs áthozva PC-re, aminek az egyetlen oka a szabványos szoftveres rétegek elavultsága. Ezek jelentenek veszély a PC master race-re, mert gyártóként nem tilthatod meg a stúdióknak, hogy saját eljárásokat fejlesszenek, de megteheted azt, hogy megadod nekik az eszközt, hogy PC-re portolhassák. -
Abu85
HÁZIGAZDA
Itt nem az AMD-s effektekről van szó, hanem a konzolosokról. Ott a PS4-ben és az XO-ban a hangprocesszor. Ilyet PC-n csak az AMD-től érhetsz el. A két konzol jobb API-t használ majd, mint ami például a DX12 lesz (igen még az Xbox One is kap számos kiterjesztés, amelyek PC-re nem jönnek). Erre született meg a Mantle, ami már tudja azt, amit az Xbox One tudni fog a D3D12.X-szel. Könnyű azt mondani, hogy majd a DX12-vel minden rendbe fog jönni, de valójában ez nem ilyen egyszerű. A DX12 valóban rendbe fogja rakni az állapotváltások és a multithread problémát, de nem reflektál az olyan igényekre, mint a multi-GPU QoS, az erőforrás-kezelés egyszerűsítése, az explicit memóriaelérés, az asszinkron DMA, az egységes shader lépcsők, ésatöbbi. Ott az integráció a konzolon, amire a PC-n lesz a HSA. És ott a disassembler, ami lehetőséget ad, hogy PC-re optimalizáljanak a fejlesztők. Szóval előbb meg kell oldani, hogy a PC-n meglegyen a szoftveres alap a konzolról való portolás butítás nélküli elvégzéséhez. Ez most messze a legfontosabb az AMD-nek, mert az NV és az Intel nem akar abban részt venni. Nekik pont jó minden úgy ahogy van, ha butítani kell, hát butítani kell, lásd Far Cry 4-ben a HRAA hiánya PC-n, pedig nagyon egyszerűen megoldható PC-n is, csak nem DX11/12-ben.
Az a gond, hogy rengeteg PC-s elhiszi, hogy itt csak a hardver számít, pedig nem. Csak annyira képes a PC, amennyit a szoftveres rétegek megengednek, miközben konzolon valóban csak a hardver számít. Nem engedhető meg, hogy ekkora szakadék legyen a két platform között, mert a szoftvert csak meg kell írni, és minden ami futtatható konzolon, futtatható lesz PC-n is.
-
Abu85
HÁZIGAZDA
Az AMD érdeke csak annyiból áll, hogy fenntartsák a PC-s játékpiacnak az AAA kategóriás konzolportokat jelentő részét, ami persze nem nagy területe az egész PC-s játékpiacnak, de értékes, és az AMD számára fontos is, mert berendezkedtek rá a két konzol hardveres alapjával, a PC-s disassemblerrel, a HSA-val, a Mantle-lel és a TrueAudióval. Mostantól minden olyan dolgot tudnak biztosítani, ami ahhoz kell, hogy a konzolról a játékot PC-re úgy portolják, hogy ne butítsák le az egyes elemeit, legyen szó a hangról, a grafikáról vagy a játékmenetről. A PC-s versenytársak közül senki más nem kínál disassembler, ami alapvető feltétele az hardverközeli optimalizálásnak, illetve komplex hangprocesszora sincs senkinek, ahogy olyan komplex szoftverökoszisztémája sem, ami a konzolhoz hasonló programozást tesz lehetővé PC-n.
Ha a PC-re jó konzolportokat biztosítasz, akkor a PC-s játékos elégedett lesz, hiszen úgy érzi, hogy minimum megkapja azt, amit megkapna egy konzollal, leszámítva ugye az egyszerűséget, de aktív PC-s játékos eljutott már addig hogy tudjon telepíteni, ismerje a PC-s játék alapjait, mint az egyes runtimeok telepítése. Az AMD minden erejével azon van, hogy a Gaming Evolved játékok optimalizálásával elégedett legyen a teljes PC-s felhasználóbázis, mert ha elégedett vagy, akkor nem mész át konzolra (ami egyébként az AMD-nek nem katasztrófa, de hosszabb távon számukra is jobb ha PC-s maradsz). Ezzel szemben ha nem vagy elégedett az egyes játékok optimalizálásával, ami az Ubisoft esetén nyilván nem mondható el, hogy figyelnének rá, akkor igazából kezd eleged lenni a PC-ből, és hirtelen felindulásból esetleg konzolra váltasz. Ugyanígy a Far Cry 4 esete, hogy PS4-en elérhető a HRAA, míg PC-n nem. Ez sem azt erősíti, hogy a PC a master race, hiszen ponr PS4-en kapsz csúcsminőségű AA-t. Ezeket a szituációkat akarja elkerülni az AMD, hogy ne is gondolkozz el a konzolra váltáson. -
Abu85
HÁZIGAZDA
Ez bonyolult dolog. Egyrészt muszáj ilyenekre áldozniuk, mert az NVIDIA nem segíti a fejlesztők munkáját. Mindent elzárnak a programozók elől, amellyel gyorsabb programot lehetne írni GeForce-ra. A legtöbb fejlesztőnek az az egyetlen lehetősége, ha az AMD megmondja nekik, hogy miképp lehet begyorsítani a kódjukat, vagy jobb esetben már eleve olyan kódot adnak nekik, amelyek gyorsan futnak.
Az NVIDIA az elmúlt három évben a szoftverpartnereik nagy részét elvesztette. Már nem partnerük az EA, a 2K Games, a Capcom és a Deep Silver. Ezek a kiadók mind átpártoltak az AMD-hez, ahol már eleve ott volt a Square Enix, a SEGA, a Nordic Games és az 505 Games. És ők mind elvárják azt, hogy az AMD segítsen nekik például GeForce-ra is optimalizálni, cserébe kiemelten támogatják a technológiáikat.
A kutatások szempontjából is sokan nem számolnak a GeForce-szal, mert az NVIDIA semmilyen formában nem segíti őket, ha a hardvereikre fejlesztenek. Van aki hangot is ad ennek. Ez nagyon régóta egyfajta elégedetlenséget szül a PC-n belül, hiszen számtalan olyan fejlesztő van, akik azt tartják jónak, ha maguk írják meg a szoftver összes komponensét és nem egy hardvergyártó szabályozza, hogy melyik effekt mennyire gyorsan futhat.
Mára egy teljes szerepváltás történt a PC-s piacon. Amit az NV képviselt a G80 idejében, vagyis nagyjából 2006-ban, azt ma az AMD képviseli. A váltás persze fokozatos volt, de látni lehet, hogy akik régen vezették a TWIMTBP-et, azok ma a Gaming Evolvedet koordinálják. Például Roy Taylor, akit az AMD idén kinevezett pontosan abba a szerepkörbe, amit az NV-nél betöltött 2004-2008 között. Alapvetően régóta ő a stratéga a Gaming Evolved mögött, csak most hivatalosan is ezzel foglalkozhat. Ugyanazt csinálja, mint régebben. Elveszi a konkurenstől az értékes partnereket, és ennek a hatása már látszik, mert az NV idén nem tudott olyan PC-s játékot adni a kártyái mellé, amely jól lett volna optimalizálva PC-re. Az ubisoftos portok egyszerűen nem azok, és ezt látja/érzi mindenki. De velük kell építeni a jövőt, mert az AMD (és az Intel - Codemasters, Activision Blizzard) elvitte azokat a kiadókat, akik nagy mennyiségben képesek minőséget lerakni az asztalra. Az NV további partnerei között a Warner Bros eléggé ingadozó munkát végez, így lényegében csak a Konami és a CD Projekt RED marad, akikre abszolút lehet építeni. Velük az a baj, hogy kevés játékot csinálnak. A City Interactive pedig, hát partnernek biztos jó partner, csak nem az NVIDIA igényeinek szintjén, de muszáj megkötni velük a szerződést és reménykedni, hogy egyszer talán letesznek valamit az asztalra, ami képvisel egy olyan értéket, hogy a GeForce mellé lehessen csomagolni. -
Abu85
HÁZIGAZDA
Tomb Raiderben mindenki defaultot, vagyis 3-at használ. Így is igen magas a hardverkihasználás, és maga a motor nagyon stabil a komplex jeleneteknél is. Ilyenkor nem kell agyontrükközni a rendszert, hogy jól fusson. Bár annyi van, hogy ez a default paraméter fix, tehát le van zárva, és nem lehet állítani.
-
Abu85
HÁZIGAZDA
Ilyen módszerrel mind ugyanazt fogjátok látni. Túl kevés a felvett információ, illetve nem számoljátok bele, hogy az fps 100 feletti, vagyis a lag így igen alacsony marad, 30-35 ezredmásodperc közötti. Ez egy másodperc nagyjából harmincad része. Képtelenség a Youtube-on visszaadni. Legalább 480 fps-es kamera kellene.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#2524
üzenetére
Ennek az a célja, hogy minél később és egyben minél ritkábban kelljen törölni a nem használt textúrákat a VRAM-ból, mert a DX11-ben bármit törölni annyira körülményes procedúra, hogy jó eséllyel be fog akadni a program. Maga a DX11 API kényszerítette a Rebelliont egy olyan döntésbe, hogy akadjon, vagy ne, és akkor egy kis minőségcsökkenés belefér. Ez egyáltalán nem a fejlesztők sara. Ők két rossz közül választották ki a nézőpontjuk szerint kevésbé rossz opciót.
És hogy mennyire nem egyedi a Rebellion gondolkodása megemlíthető, hogy a Frostbite és a CryEngine új verziói ugyanerre a streaming modellre állnak át. Sőt, a Ryse már használja is. Bár a Ryse annyiban más, hogy ott még a maximális textúrarészletességet sem állíthatod be egyénileg, hanem a program automatikusan intézi ezt. -
Abu85
HÁZIGAZDA
válasz
FLATRONW
#2522
üzenetére
A régi verzió negyedakkora méretű textúrákat támogatott. A Sniper Elite 3-ban a low szint az, ami a Sniper Elite v2-ben a maximum volt a textúrarészletesség szempontjából. Erre reagál az új streaming stratégia.
Igazából ezeket a streaming rendszereket nagyon nehéz PC-re kifejleszteni. Tökéleteset két év alatt sem lehet alkotni. Nagyon akadályozza a fejlesztőket az a tény, hogy a DX11 nem engedi a közvetlen memóriaelérést, tehát nem tudnak akármit megcsinálni, hanem kerülőutak tucatjait kell kidolgozni, hogy egy átlagosnál jobb streaming rendszer egyáltalán működjön a gyakorlatban.
Kevés olyan játékot láttam, ami annyira példásan lett volna DX11-re optimalizálva, mint a Sniper Elite 3. -
Abu85
HÁZIGAZDA
Ezek a dolgok nagyrészt kapcsolódnak a DX11 API-hoz.
A Capcom beszélt erről egy hete a Panta Rhei kapcsán, hogy az aktuális PC-s kódjukban ez a motor képkockákként 3 interakciót képes kezelni, miközben a PS4-en nem okoz gondot a 30 fizikai interakció sem. És ez nagyrészt a DX11-re vezethető vissza. Hiába nincs köze az API-nak a fizikai motorhoz a Panta Rhei PC-s portjában le kell butítani a fizikát, mert túl sok az API többletterhelése. Az AI-t is ezért kell butítaniuk PC-re.
Masaru Ijuin azt is mondta, hogy PC-n, DX11-ben nagyon korlátozott a gyakorlatban is hozzáférhető processzorteljesítmény. Hiába terjedtek el a 100+ GFLOPS-os procik, DX11-ben nincs mód a teljesítményük kinyerésére. -
Abu85
HÁZIGAZDA
válasz
FLATRONW
#2514
üzenetére
Az Asura motor esetében a textúra streaming működése egy érdekes optimalizálási stratégia valóban, de teljes egészében a DX11 miatt alakították így. Azért tölt be a memóriába alacsonyabb felbontású textúrákat idővel, hogy a nem használt területet ne kelljen törölni. Viszont, ha nem törlöd, akkor egyre kevesebb használható területed van, tehát alacsonyabb felbontáshoz kell folyamodni. Egyszer persze úgyis lesz törlés DX11 alatt is, tehát ezzel csak az időt húzzák. Nyilván nem mindegy, hogy több órás játék során hányszor akad be a program a nem használt textúrák törlésétől. A Rebellion abszolút a folyamatosságot helyezi előtérbe, tehát minél kevesebb akadás lesz ebből, annál jobb lesz az élmény a fejlesztők szerint. És ezért úgy gondolják, hogy megéri beáldozni néhány textúra minőségét is.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#2512
üzenetére
Vannak partnerek, akik már mondták, hogy a DX12 mellett is az AMD API-jait tekintik majd elsődlegesnek. Az EA stúdiók, a Firaxis, az Oxide és a Gamebase biztosan. Azzal indokolták döntésüket, hogy az AMD megoldásai alacsonyabb szintűek, illetve gyorsabban fognak fejlődni. De ettől mindegyik partner készít majd állandóan DX12 portot, és amit abban meg lehet oldani azt implementálni fogják.
Nagyon sok függ attól, hogy mi az adott fejlesztő igénye. Például a multi-GPU támogatását szükségesnek érzik-e, mert ez a DX12 előzetes speckóiban nincs benne, ugyanis az MS szükségtelen részpiacnak tartja, így nem élvez prioritást. Ehhez hasonló tényezők döntenek. -
Abu85
HÁZIGAZDA
válasz
daveoff
#2509
üzenetére
Mindenkinek. A top fejlesztőknek azért, mert esélyt kapnak rá, hogy a konzolra készült új generációs játékokat ne kelljen majd butítani PC-re. Hiába minden TFLOPS, ha a konzol csupán szoftverből többmilliószor gyorsabban ír be egy GPU parancsot egy parancspufferbe. És ez neked is jó, mert a PC-n is megkapod a teljes élményt.
A DX12-vel sok változás nem történik majd, mivel a low-level irány már eleve ki van jelölve. A DX11 támogatása valószínűleg vissza fog szorulni.
Az AMD addig készít saját low-level API-kat, amíg a fejlesztőpartnereik igénylik. Az egészet fogd fel úgy, mint egy problémamegoldást. Van egy gond, amire nincs megoldás létező API-n belül? Csinálunk egy új API-t, vagy kiegészítést, hogy legyen megoldás. Ennyi a célja. Most például a shader nyelvek reformja következik. -
Abu85
HÁZIGAZDA
válasz
daveoff
#2506
üzenetére
Mondtam, hogy ha te ezzel boldog vagy, akkor annak a DICE és az EA nagyon örül. Ezért dolgoztak az elmúlt hónapokban, hogy mindenkinek jó legyen. De ők már nem tartják a DX11-et használható API-nak, és sok dologban teljesen igazuk van. A Frostbite 3 az egyetlen motor a piacon, amely befolyásolja a grafikus driverek működését, és ezt senki sem ajánlja, mert összeomláshoz vezethet. Ez persze random jellegű, de létezik a probléma, és sokat kell tenni azért, hogy az összeomlások megritkuljanak. A BF4 egy évvel a megjelenés után már elég jó, viszont egy fejlesztő alapvetően szeretne a játék megjelenésére stabil programot kínálni. Persze, ha nem jön össze, akkor később ott a patch lehetősége, de ez nem optimális fejlesztési modell.
-
#2505
Abu85
HÁZIGAZDA
Malibutomi
#2504
Abu85
HÁZIGAZDA
válasz
Malibutomi
#2504
üzenetére
Nem valószínű, hogy a DX11 render prioritás. Erre elég drága optimalizálni, és állandó probléma a Frostbite 3-nál a DXGI_ERROR_DEVICE_HUNG hiba, ami ugye ismert a fejlesztők előtt is. DX11 alatt szándékosan feláldozzák a stabilitást a nagyobb sebességért. Enélkül a DX11 kód sokkal lassabb lenne, viszont így meg néha összeomlik a játék. Aki teheti nem a DX11 renderen játszik egy Frostbite 3 játékkal.
Az, hogy a Frostbite 3 értékelhetően fusson DX11 alatt, minden egyes játék, minden egyes új patch-jénél iszonyatos mennyiségű pénz és erőforrás befektetését jelenti. Egy évben az összes megjelent játékra nem kell költeni annyit a driver fejlesztésénél, mint egy Frostbite 3-as programra egymagában. -
Abu85
HÁZIGAZDA
válasz
daveoff
#2502
üzenetére
Mindenkinek mást takar. Ha te elégedett vagy azzal, amit kapsz, akkor a DICE nagyon boldog, hiszen részben azért dolgoztak, hogy elégedett legyél a szoftverükkel. A lehetőségekhez mérten a legjobbnak akarták kihozni. Viszont minden fejlesztőnek van egy nézete arról, hogy mire van szükség. A DICE azért használ low-level elérést, hogy az általuk elgondolt élményt át tudják adni a PC-seknek. Nem kötelező ezzel élni, vagy akár egyetérteni sem. Ők csak a lehetőséget akarják biztosítani nektek, hogy úgy játsszátok a játékot, ahogy elképzelték. De még egyszer mondom, ha te boldog vagy azzal, amit most kapsz, akkor a DICE is boldog, mert pozitív az élményed a szoftverükkel, ami később új vásárlásra fog sarkalni stb.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#2500
üzenetére
Ha megoldható lenne az optimális élmény a Frostbite 3-mal DX11 alatt, akkor nem használna az EA low-level API-t. A PC-ért nem érné meg a beruházás, ha ki lehetne hozni a DX11-ből is a fejlesztők által elfogadottnak tartott élményt. Viszont a fejlesztők már annyival jobbnak tartják a low-level elérést, hogy megéri beruházni annak érdekében, hogy a konzolos élményszintet a PC is megkapja. Nekik megvannak az eszközeik, hogy kimérjék a legkisebb változásokat is a PC-ken, amiket átlag szoftver nem tud mérni. Az fps csak egy mérőszám, és ha nézel DICE előadásokat, akkor sokszor elhangzik, hogy az egyik legrosszabb mérési módszer.
Annak nyilván örül a DICE, hogy te jónak érzed a DX11-es munkájukat. Ők viszont nem érezték annak a DX11-et, ezért használnak más API-t is. -
Abu85
HÁZIGAZDA
válasz
daveoff
#2497
üzenetére
Sehogy. Nem tudják megtenni. De ez nem az NVIDIA hibája. Igazából maga az alapprobléma, ami az API-k lemaradását okozta igen hosszú folyamat eredménye. Már a 2000-es években felmerült, hogy a szoftverrel tenni kellene az olcsóbb rajzolási parancsokért. Egy parancs beírása a parancspufferbe a DX8-ban ~10-15 millió órajel volt. A DX9 erre reagált is az állapotblokkokkal. Aztán a DX10-ben jöttek a nagyobb állapotcsoportok, majd a DX11-ben a deferred context. A DX10-ben leküzdöttük az erőforrásigényt 10 millió órajel alá, míg a deferred context igazából nem ért semmit. Most azért van ez a hatalmas váltás, mert a PS3 GCM 5 órajelből megoldotta a parancsok beírását a parancs pufferbe, és az új API-kkal ezt a teljesítményt akarjuk lekövetni. A 10-20 órajel már jó érték PC-n.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#2494
üzenetére
A DX11 eleve egy olyan API, ami rengeteg alapvető problémát vet fel. Meg kell küzdeni a shader újrafordítással, a sok állapotváltással, az állapotszűrés terhelésével, ami ráadásul háromszoros munka, mert megcsinálja a program, aztán az API és végül a driver. A parancspufferekhez ellenőrizni kell, hogy megvannak-e a szükséges információk a hardver számára. Hiába tervezted programozóként konzisztensre az adatok tárolását, akkor is el kell költeni a processzor erőforrásának felét erre az ellenőrzésre, mert az API megköveteli.
Szóval a DX11 eleve egy nagy kompromisszum, amiben ma jót egy BF4 komplexitású szoftvernél nem lehet alkotni. Egyáltalán nem véletlen, hogy az EA egy másik API-t is használ a DX11 mellé, hogy legalább egy réteg megkapja a fejlesztők által optimálisnak tartott élményt. -
Abu85
HÁZIGAZDA
Mindegyik aktuális API megmarad. Annyi lesz, hogy a mostani 1.0-s API verziót az AMD megnyitja, és a core specifikációkat úgy véglegesítik, hogy többet ahhoz nem lehet hozzányúlni. Ezzel ha az Intel és az NVIDIA támogatni akarja, akkor ingyen és félelem nélkül megtehetik, hiszen a specifikációkat az AMD sosem fogja módosítani, tehát nem kell attól félniük, hogy az AMD később kizárja őket a piacról. Viszont az AMD egy másik API-val tovább szeretne fejlődni.
Én annyit tudok, hogy az új API-nak köze lesz a HSA-hoz, de még nem tudni, hogy milyen mértékben. Reális elképzelés lehet az APU-k IGP-jével gyorsítani a parancspufferek kreálását, így 2015 végére elérhető lehet a 300000 batch/frame, illetve a processzormagok válláról egy egészen nagy teher is lekerülne. -
Abu85
HÁZIGAZDA
válasz
daveoff
#2486
üzenetére
Ez az egész egy rendkívül komplex probléma. A játékfejlesztő és a gyártó is azt a paraméterezést keresi, aminél a játék folyamatos, jó sebességet ad, nem akadozik túl sokat és az input lag is még elfogadható. A preender általában mindegyikre hatással van valamilyen mértékben, tehát meg kell találni azt a beállítást, ahol ezek kombinációja optimális élményt ad. Az input lag biztos nagyobb lesz több jelenet előzetes felpufferelésével, de ha kevesebb jelenet előzetes felpufferelése érezhetően rontja a sebességet, vagy a folyamatosságot, akkor elképzelhető, hogy a magasabb input laggal is előnyösebb az összesített élmény.
(#2485) odorgg: A DX elmegy ott is, csak a BF4-nél van egy összehasonlítási alapod az AMD saját API-jával, ami eleve az az élmény, ahogy az EA eltervezte.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#2473
üzenetére
A Mantle-re nem lehet driverrel válaszolni. Maga a DirectX 11 teremti meg az aktuális korlátokat és addig nem lehet azon túllépni, amíg low-level API-t nem használ a program. Ha elfogadjátok, ha nem ez az irány nagyon sokat ér a fejlesztők szemében, mert megadja az esélyt, hogy a PC-piacot a konzolra tervezett játékok portjával terítsék, és nem a mobilra fejlesztett butított verziót javítsák fel grafikailag.
Egy olyan extrém fejlődés előtt állunk, ami a 2000-es évek elejére volt jellemző. Csak most nem hardvereket kapunk, hanem grafikus API-kat, és innen jön majd a sebesség. És ezt érdemes szó szerint venni, mert a Mantle csak egy API lesz az AMD-től. Már készül a leváltója, ami nem lesz kompatibilis vele. A DX12-vel párhuzamusan akarják bemutatni. -
Abu85
HÁZIGAZDA
válasz
daveoff
#2451
üzenetére
A prerender nem egy univerzálisan használható érték. Jellemzően nincs olyan, hogy egy szám mindenhol jó, mert játék válogatja az eredményt. Simán lehet, hogy az AMD-nél DX alatt a 3 működik a legjobban, míg az NV-nél az 5. Ezt csak a gyártók képesek kiértékelni, mert megvan hozzá minden eszközük. Az Intel például 2-t használ a Frostbite 3-ban a DX alatt.
-
Abu85
HÁZIGAZDA
válasz
Televan74
#2370
üzenetére
Nem szerencsés hármas.
A Withcer 3 TWIMTBP, míg a Dragon Age: Inquisition Gaming Evolved.
A GTA5-re nincs adat. Az AMD reklámozza veszettül a Youtube csatornájukon, de tudtommal nincs benne egyik partnerprogramban sem. Szóval olyan semmilyen, de optimalizált játék lesz. -
Abu85
HÁZIGAZDA
válasz
Goblin12
#2361
üzenetére
Az Apple-nek készítettek egy M295X-et. Az egész jó. Nem tudom, hogy mikor akarják másnak is elérhetővé tenni. Úgy tudom van egy exkluzivitási egyezmény az Apple-lel, szóval lehet, hogy ebből idén nem lesz semmi. A CES-re esélyes, mert az OEM-ek igényelni fogják az új cuccokat.
A Star Citizen nem sok NV-s dolgot tartalmaz. Nem is dolgoznak együtt az NV-vel, csak beépítik a turbulence modult, amit az NV kért és kész. A többi technika, amit használnak AMD-s vagy inteles. De főleg AMD-s kirakatjáték lesz a Star Citizen, gyakorlatilag minden benne lesz, amit a veres oldal kínál.
-
Abu85
HÁZIGAZDA
Erre való a GameWorks, hogy a fejlesztő ezt használja és ne az Xbox One shadereit hozza át PC-re. És ez eléggé egyértelmű koncepció, mert más lehetőségük annyira nincs. Az oké, hogy a Microsoft arra buzdít, hogy ott az Xbox One arra kell DX12 rendert írni és az jó PC-re, de ez nem optimális. Szóval kell PC-re optimalizálni. A Microsoft is egy manipulatív cég. Nekik szuper lesz, hogy az Xbox One kódja sok PC-n nem fut hatékonyan, hát mit fog venni a user? ... konzolt. Persze, hogy azt mondják, hogy nem kell optimalizálni, mert kompatibilis, illetve csak pár extra sor és fut.
![;]](//cdn.rios.hu/dl/s/v1.gif)
Az NV-nek a problémát egyedül a gyártói partnerprogramokban nem résztvevő stúdiók jelentik. Ők sehonnan sem tudják majd megszerezni az optimalizáláshoz szükséges információkat. Lásd Ryse.
-
Abu85
HÁZIGAZDA
válasz
szasanyi
#2355
üzenetére
Nincs olyan forgatókönyv, ami nem jelent majd az eladási mutatókban csökkenést. Ez sajnos a piac változásaival fog járni.
A fő szempont egyébként mindkét cég számára, hogy ne kövessék le egymást sehol. Ez már a fejlesztőkhöz való hozzáállásban kialakult, és a játékok esetében is látszik. Az AMD-nél extrém fókuszt kap az AAA kategória, míg a MOBA/MMO csak támogatott, de nem lényeges. Az NV-nél ez pont fordított. A MOBA/MMO a fókusz és az AAA a másodlagos.
Ez egyértelműen látszik a nagy kiadókkal való üzletelésben is. Gyakorlatilag az NV-nél csak az Ubisoft komoly partner, míg az AMD-nél az EA, a Square Enix és a SEGA is kiemelt támogatást kap. Viszont az NV rengeteg PC-exkluzív MMO és MOBA támogatására is költ. -
Abu85
HÁZIGAZDA
válasz
szasanyi
#2353
üzenetére
Persze, hogy nincs törekvés. Mivel mostantól kezdve nem tekintenek egymásra versenytársként. Minden szempontból az ellenkezőjét teszik annak, amit a másik csinál.
NVIDIA: dokumentációk hiánya és az egyéni optimalizálás akadályozása, lezárt és csak felügyelet mellett módosítható shader kódok
AMD (és az Intel is): dokumentációk biztosítása és az egyéni optimalizálás segítése, nyílt és szabadon módosítható shader kódokAz NVIDIA ezt nem kicseszésből csinálja, hanem azért, mert abban a modellben, amit az AMD és az Intel csinál, illetve amire ők is építettek a 2006-2010-es években már nincs jövőjük. Ez látszik is. Rengeteg top kiadó nem is tartja már velük a kapcsolatot. Az Intel és az AMD többet fog mondani arról, hogy GeForce-ra hogyan kell optimalizálni, mint maga az NVIDIA.
-
#2336
Abu85
HÁZIGAZDA
ricshard444
#2334
Abu85
HÁZIGAZDA
válasz
ricshard444
#2334
üzenetére
A Witcher 3 szempontjából mindegy. Egyetlen GPU PhysX-es játék sem ad jó skálázódást, aminek az oka egyszerű: Mindig csak az első GPU számolja a CUDA feladatokat, tehát ha van mellette egy második GPU, akkor a számítás teljesen aszimmetrikussá válik. Az első GPU nagyon le lesz terhelve, mivel a második GPU grafikai számításánál ki kell számolnia a CUDA effekteket. Ha van egy harmadik GPU, akkor annak is. Ezért skálázódik GPU PhysX mellett az SLI csak 30-50%-os szinten.
-
#2288
Abu85
HÁZIGAZDA
Malibutomi
#2287
Abu85
HÁZIGAZDA
válasz
Malibutomi
#2287
üzenetére
Supersampling mellett van gaussian blur filter. Attól lesz homályos. Supersampling nélkül ez a szűrő nem fut.
-
#2286
Abu85
HÁZIGAZDA
Malibutomi
#2268
Abu85
HÁZIGAZDA
válasz
Malibutomi
#2268
üzenetére
Már kitárgyaltuk: [link]
-
Abu85
HÁZIGAZDA
A shader átírás nem egyedi dolog. Mindenki csinálja. Az AMD is szokta, ahogy az Intel is. A képminőséget ez nem befolyásolja, mert csak optimalizálás történik. Az NV azért csinálja sűrűbben, mert kevés regisztert építenek a hardvereikbe, így mindenképpen optimalizálni kell az übershadereket, hogy elég regiszter legyen.
Semmi gond, ha egy patch javít a shaderen. Ettől a driver még lecserélheti továbbra is. Ha nem kell, akkor egy új driverben kikapcsolják a cserét.A fogyasztásra gyúrnak, így meg kell hozni az áldozatokat a működésben. Mivel ez csak a DX11-et érinti ennyire durva eredménnyel, ami amúgy is elavult, így ez bevállalható.
Igazából terjed a GameWorks, csak nem ott ahol szeretnék, hogy terjedjen. A legtöbb top stúdió elzárkózik előle, ami érthető, hiszen évekig küzdöttek azért, hogy kiirtsák a rendszerből a fekete dobozokat, erre az NV hoz nekik egy fekete dobozt az új rendszerekhez.
-
Abu85
HÁZIGAZDA
Persze. Abba gondolj bele, hogy nem is nagyon lehet mire optimalizálni még. Oké, picit optimalizálták Intelre, amit szintén elismertek, de GeForce-ra nem lehet. Főleg nem úgy, hogy a Crytek anyagilag nem áll most stabil lábakon. Nem fognak arra költeni, hogy visszafejtsék a GeForce-ok működését, csak azért, hogy optimalizáljanak rá. Lásd a TressFX, az AMD fél évig optimalizálta Keplerre, és még Maxwell optimalizálást nem is kapott, az még egy fél év. Az is kérdéses, mennyire jogszerű az AMD-nek megosztani a visszafejtés adatait a Crytekkel. Ugye a reverse engineering alapból egy tiltott dolog, de nagyon jellemző, hogy amikor a teljesítményproblémák, vagy kompatibilitási problémák megoldása érdekében történik, akkor a jog szemet huny a "bűntett" felett. Vannak is a törvényben ilyen kivételek. De a reverse engineering adatok továbbadása egy másik félnek már törvénytelen. A Crytek ráadásul nem Gaming Evolved partner a játékokra vonatkozóan. Ezért nincs a Ryse a Gaming Evolved listában, és így például az sem megoldható, hogy az AMD emberei optimalizálják a játékot GeForce-ra, amit például az új Aliennél megtettek.
Ha az NVIDIA akarja, akkor kihasználhatja a törvény kiskapuit, így visszafejthetik a Ryse shadereit és azokat optimalizálhatják, majd driverből lecserélhetik. Ez biztos eredményt ad majd, csak nem egy gyors folyamat. De nem egyszer csinálták már. Ott volt például a Dirt Showdown. Háromnegyed év alatt átírták a shadereket és jóval gyorsabban futott GeForce-on, mint a kezdetekben.A DX11/DirectCompute 5.0 működésével nem nagyon tudnak mit kezdeni. Azt be kell nyelni. Az optimalizálás leginkább felzárkózást jelent majd, hogy a GTX 770 mondjuk ne egy 270X-szel legyen pariban, vagy mondjuk a 280X se legyen a 970 nyakán. Csodát viszont nem lehet tenni, olyat ne várjon senki.
Az architektúra dokumentálása, illetve annak hiánya egy üzletstratégiai lépés. Az NV rá akarja kényszeríteni a fejlesztőket a GameWorksre, csak láthatóan a Cryteket ez nem érdekli, ahogy számos más fejlesztőt sem. Tehát szükség lesz a driveres hackekre, még ha a hátuk közepére is kívánják. Az NV idézi elő a problémát azzal, hogy nem mondják meg a fejlesztőknek hogyan lehet GeForce-ra optimalizálni.
-
Abu85
HÁZIGAZDA
Fogalmam sincs, de mivel marha sok trükközés lesz a jövőben, így már most érdemes eltávolodni az AFR-től, mert az még low-level szinten sem fog igazán működni. Valószínűleg a Rebellion motorjának a pipeline vágása reális koncepció. Szerintem másnak nem lesz az, de ki tudja.
-
Abu85
HÁZIGAZDA
Az SSAA számít, de nem ennyire, ráadásul eléggé speciális SSAA és TAA keveréket használ a játék.
Igazából ilyen eredményt több tényező együttállása okoz. Valószínűleg az Xbox One shadereit nem sok módosítással hozták át PC-re. Úgy sem tudják hogy működik a Maxwell/Kepler, szóval majd az NV lecseréli őket driverből, ha akarja. A CryEngine is eléggé compute irányba fejlődik. Ezt nyilatkozták is: "We are making heavy use of some DX11 features like Compute Shaders, which however, perform better on some hardware architectures than others, so there will be some noticeable performance gaps between different desktop GPUs." Nyilván a Maxwellnek nem segít, hogy DX11 compute shader mellett az elméleti teljesítményének a negyedét elveszíti, mert a negyedik blokkhoz nem tud 32 kB-os LDS-t rendelni.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#2208
üzenetére
Nem igazán a low-level API a követelménye, hanem az érzékelt GPU-k fölötti teljes kontroll (QoS). Az API absztrakciós szintje nem sokat számít, bár a low-level valószínűleg segít nagyon egzotikus működési modellt tervezni.
A DX-ben azért nincs ilyen, mert az API egy erőforrást detektál, és a mai SLI/CF csak egy szimpla driverhack.
OpenGL-ben van erre egy specifikus megoldás: AMD_gpu_association -
Abu85
HÁZIGAZDA
válasz
FLATRONW
#2206
üzenetére
Például a geometry shader fázisig az egyik hardver dolgozik, míg onnantól a másik. Mintha egy GPU lenne a kettő. Ez akár kombinálható AFR-rel. Vagy az IGP csinálja a geometriát, és a dedikált GPU a többi számítást. Vagy akár két dedikált GPU is megteheti ezt. Sok lehetőség van.
-
Abu85
HÁZIGAZDA
De. Különösen szeretjük, amikor egy független stúdió komoly kiadói tőke nélkül tartja a lépést a nagyokkal. Sajnos alig van ilyen, de a Rebellion a példa, hogy meg lehet csinálni.
(#2200) FLATRONW: Kérdés, hogy milyen lesz a multi-GPU, mert nem AFR-t akarnak az Asura motorba építeni, ami ezt különösen érdekessé teszi. Erre én is befizetek, mert feladatfelosztásos modellt még nem láttunk.
-
Abu85
HÁZIGAZDA
Nekem Q9550-en 30%-kal jobb Full HD-ben maxon a 270X. De most azért tesztelték nagy procival, mert ott is hoz a Mantle. Plusz a textúrákra vonatkozó javulás.
(#2193) Televan: Az egy szabványos effekt. Nem kötelező kikapcsolni, bár rendkívül fényes lesz tőle a bunda, és mivel a rejtett fényforrások megvilágítják, még este is csillogni fog. Ha Lara haja samponreklám volt, akkor itt óránként kondicionálják is a tisztaság érdekében. Ez sajnos még mindig tipikus probléma az efféle szimulációknál.
-
Abu85
HÁZIGAZDA
Négy játék jött. [link] - no offense, csak a pontosság végett.
Az Asura motort az előző verzióhoz képest teljesen átírták. A Sniper Elite 3 már job rendszerű, vagyis nincs dedikált mag az egyes feladatokra. Ehhez még hozzájön, hogy a nyáron átírták a rendert is, hogy jobban illeszkedjen a low-level API-khoz, és kiműtötték belőle a korábban még problémás többletterhelést. Emiatt DX11-ben is gyorsult 10-20%-ot az új patch-csel.
Lehet vele olyat is, de az jóval nehezebb, és igényli azt, hogy a driver támogassa az aszinkron compute-ot. Ilyen driver még nincs a felhasználóknál. De azt mondta a Rebellion is, hogy képesek ingyenessé tenni az OF effektet a Mantle alatt. -
#2160
Abu85
HÁZIGAZDA
Dragbajnok
#2159
Abu85
HÁZIGAZDA
válasz
Dragbajnok
#2159
üzenetére
Ja. Beépítették a state blokkokat optimalizálásnak +50% sebesség reményében. Olyan fasza lett az implementáció, hogy -50% lett az eredmény. De azért maradt a kód, me miért ne. Legalább nem mondhatják a játékra, hogy elavult a DX9 kódja is, mert nincs state blokk támogatás sem. Most már van.
-
Abu85
HÁZIGAZDA
Inkább úgy mondanám, hogy hasonló számban nincs jelen. Nagyon tipikus dolog lett önmagában már a fekete képernyő miatt is a GPU-t hibáztatni. Mi mástól lehetne, hiszen arra van kötve a monitor ... de nem?
A garanciára BS-sel visszaküldött kártyák zöme ebből a téves alapból születik meg, mert a szerviznél ugyan nem jön elő, de nyilván a user mondhatja, hogy rossz és ragaszkodik ahhoz, hogy ezt megvizsgálják. Ilyenkor megy a gyártóhoz. Sokáig tart, de teljesen normális és jogilag indokolt ügyintézés ez. A gyártó meg vagy visszaküldi, vagy utasítást ad, hogy cseréljék ki, és az amúgy jó kártyákra raknak egy új sorozatszámot és megy újra a piacra. Utóbbi szimplán kedvezőbb, mert egyszerűbb és olcsóbb nem visszaküldeni a terméket. -
Abu85
HÁZIGAZDA
Pontosan. Eleve a gyártók nem is tesztelik az ilyen hibákat kereskedelmi forgalomban kapható alaplappal. Van egy direkt erre kialakított tesztgépjük, amivel minden hardver összeférhetetlenségi gond kizárható, és csak arra koncentrálnak, hogy a VGA hibás-e. Egy mezei szerviznek ilyen berendezésre se pénze, se szakképzettsége.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#2128
üzenetére
Azért mert még nem ütötted be a Google-be az NVIDIA (esetleg Intel) black screen keresését. Ott is milliós nagyságrendű találatot kapsz.
Egyébként nem feltétlen más komponens okozza, hanem két komponens közötti kompatibilitási probléma. Külön-külön lehet, hogy minden jó, de együtt ... -
Abu85
HÁZIGAZDA
válasz
the_mad
#2126
üzenetére
Jóval jobb tesztmegoldásaik vannak, mint bárkinek innen, vagy akár a sarki szervizből. Ha azok azt mondják, hogy jó a kártya, akkor az jó.
A BS hibák nagyon nagy többsége kompatibilitási gond, tehát a problémásnak hitt komponenst átrakva egy másik rendszerbe megjavul az egész. Ugyanezt tapasztalja minden gyártó a garizás során. Teljesen normális, hogy a szervizben is jól működik, mert más a konfig.
A BS-re vannak olyan tesztjavaslatok, amelyeket a szervizpartnerek megkapnak. A legfőbb javaslat, ha hardvert hoznak BS-sel, akkor rögtön kérjék be a teljes gépet, mert a csavarokat leszámítva bármitől lehet. -
Abu85
HÁZIGAZDA
válasz
Locutus
#2124
üzenetére
Nincs elég számítási kapacitás egyetlen PC-s processzorban sem, hogy kiszámolja a mozgásszimulációt és az AI-t. Ha másképp le is programozzák, amit le lehet, akkor is hiányozni fognak a GFLOPS-ok. Esetleg a 24 magos szerverprocesszorokra meg tudnák oldani.
Broadwellre és Kaveri APU-ra meg tudnák csinálni, mert azok támogatják a megosztott virtuális memóriát. Ettől persze még az IGP számolna, csak meglenne a GFLOPS és a hatékonyság, ami kell a feladathoz.Hidd el egyébként az EA-nek sem akkora öröm két motort párhuzamosa fejleszteni és fenntartani. Ha megoldható lenne, hogy csak az újat használják, akkor már a jóval kisebb költségek miatt is átállnának rá.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#2122
üzenetére
Ez nem elmélet, csak nincs még általános fejlesztőkörnyezet. Az EA egyébként a sportjátékaihoz már használja a next-gen igazi extráit. Ők is úgy implementálták, hogy írtak egy saját fejlesztőkörnyezetet. Ha nem tudod megnézni, akkor hallgasd meg az bemutatókat a X1/PS4-es és a PC-s FIFA különbségeiről. Megdöbbentően életszerű a next-gen verzióban a játékosok mozgása. Azt mind a CPU és az IGP közös munkája számolja, pont úgy ahogy kérték a fejlesztők. Az AI-t is IGP számolja.
Mi PC-sek biztos kitörölhetjük majd, mert ide a valóban next-gen játékmeneti dolgok nem lesznek vissza portolva. Amelyik játékot nem butítják le azt ki sem adják PC-re.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#2119
üzenetére
Ott, hogy ők fejlesztik a gépekre a tartalmat. Nekik vannak ötleteik, és szeretnének olyan hardvert, amin ezek az ötletek megvalósíthatók.
Az a gond a piaccal, hogy mindenki sír, hogy hol van a játékokból az innováció. Most mindenki azon sír, hogy miért olyan gépek jöttek, amik lehetővé teszik az innovációt. -
Abu85
HÁZIGAZDA
válasz
the_mad
#2116
üzenetére
Ezek amiket felsoroltál mindenen vannak. Sőt, most elmondom neked, hogy a PC Partnerhez BS-sel visszaküldött kártyák 99,98%-a hibátlan. Újracsomagolják, új sorozatszámot kap és eladják, mert a PC egy más komponense okozta a fekete képernyőt, csak a user nem lát túl a VGA-n.
Manapság egyébként teljesen normális (szintén PC Partner adat), hogy a garira (akármilyen hibával) visszaküldött termékek ~40%-át újra eladják, mert nem hibásak. Ez arra utal, hogy rengeteg a kompatibilitási probléma.
-
Abu85
HÁZIGAZDA
válasz
the_mad
#2111
üzenetére
Nekem az az érzésem, hogy a Titan Z-t még az NV sem tudja mire szánta. Olyan kísérlet lehet mint a sima Titan. Bedobták 3000-ért, hátha ezt is megveszik, csak arra nem gondoltak, hogy az AMD készít egy ugyanilyen koncepciót 1500-ért. Innentől kezdve pedig jön, nem jön, visszavonták, még drivert írnak. Az ASUS-nak annyira későn szóltak, hogy a sajtókat is kiküldték április végén. Most azon mehet a vita, hogy mivel járnak jobban ... ha megjelenik, vagy ha törlik.
-
Abu85
HÁZIGAZDA
válasz
#17954112
#2099
üzenetére
A nyomós ok kimerült abban, hogy az AMD mellett az összes többi nevező azt mondta, hogy az a hardver, amit kérnek előtt kivitelezhetetlen. Az AMD azt mondta, hogy 2014-re összerakják. Mivel 2014-2015-re új konzolokat akart a Sony és az MS, így eldőlt a kérdés. Ha 2016 végére tervezték volna a startot simán nem az AMD nyeri meg a tendert, mert ARM vagy Power magok licencelésével sokkal olcsóbb üzleti konstrukciókra is lehetőség van, és úgy a Sony és az MS megveszi a dizájnt, majd megdobja a beszállítót 3-5 dolláros gépenkénti zsetonnal. Ezzel szemben az AMD-nél az x86 miatt csak OEM konstrukcióra van lehetőség, vagyis nem lehet megvenni a dizájnt. Ez gyakorlatilag azt jelenti, hogy gépenként 3-5 dollár helyett 20-30 dollárral többet rak zsebre a beszállító.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#2095
üzenetére
Ezt még ma is félreérti mindenki. A fejlesztők igazából egy dolgot kértek nagyon, ami miatt az eredeti hardverkoncepciók mentek a kukába. Az egységes memória és a vele járó egyéb extrák, mint a C1x atomics. Egyszerűen fogalmazva kértek egy gyorsabb Cellt a Cell hátrányai nélkül.
Amit majd látni fogsz, hogy ami PC-re megjelenik az már biztos nem fog tartalmazni olyan dolgokat, amelyek a fenti fícsőröket kérik. Vagy esetleg butított lesz a port lásd Fifa 14.
Egyébként ezt már más leírta igen jól. Erről szól a next-gen. És az az architektúra, amit beleraktak olyan, ami pont ezeket teszi lehetővé. Hogy új szoftvereket kell írni? Persze, de az eredmény lenyűgöz majd mindenkit. -
Abu85
HÁZIGAZDA
Nem. Nem alkalmazták a PS4-re és az X1-re sem az aszinkron compute-ot, és még a DMA transzfert sem csinálták meg nemhogy shared memre, de még aszinkronra sem. Ez az egyelten next-gen játék, ami DMA transzfernél leállítja a futószalagot. Eredetileg valóban úgy tájékoztatták a Sony-t, hogy a PS4-re meglesz a 60 fps és az 1080p, csak akkor még úgy volt, hogy a kidolgozott optimalizálásokat beépítik. Ezek nélkül viszont a teljesítmény több mint a felével esik. Vagy csúszik még negyed-fél évet, vagy kiadják mindenre úgy, ahogy van. Esetleg év végére befejezik és jön egy patch.
A legtöbb eljárást láthatóan pre-gen konzolokra építették. Az X360 és a PS3 verzió alig néz ki rosszabbul, mint a többi, pedig ezek majd egy évtizedes hardverek.
Szóval ott már optimalizált minden mindkét oldalról.
![;]](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!
Megbízhatatlan oldalakat ahol nem mérnek (pl gamegpu) ne linkeljetek.
- Samsung Galaxy A52s 5G - jó S-tehetség
- Xiaomi 15T - reakció nélkül nincs egyensúly
- Brave
- Battlefield 6
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Konzolokról KULTURÁLT módon
- Végleg kitiltaná a Huawei-t az EU a hálózatkiépítésből
- Hat év támogatást csomagolt fém házba a OnePlus Nord 4
- PROHARDVER! feedback: bugok, problémák, ötletek
- Assetto Corsa Rally
- További aktív témák...
- 27% - GIGABYTE RTX 3080 Ti OC 12GB GDDR6X GAMING Videokártya! BeszámítOK
- Hp NVidia RTX 2070 Super 8Gb Videokártya - HP L84981-001
- ASUS RTX 5090 32GB GDDR7 ROG ASTRAL OC - Új, Bontatlan, 3 év garancia - Eladó!
- ASUS ROG RTX 3060 OC 12GB GDDR6 jegelve nagyadam29-nek
- RTX 5000-ES SZÉRIA ÚJONNAN GARANCIÁLIS ELADÓ TERMÉKEK! 5050, 5060, 5070, 5080, 5090.
- Apple iPhone 12 Mini 128 GB Fekete 1 év Garancia Beszámítás Házhozszállítás
- GYÖNYÖRŰ iPhone 12 mini 256GB Black-1 ÉV GARANCIA -Kártyafüggetlen, MS3626, 100% Akkumulátor
- HIBÁTLAN iPhone 14 Plus 128GB Purple -1 ÉV GARANCIA - Kártyafüggetlen, MS3659, 100% Akksi
- LG 27MR400 - 27" IPS LED - 1920x1080 FHD - 100hz 5ms - AMD FreeSync - Villódzásmentes
- Fitbit Versa 4 okos óra
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: NetGo.hu Kft.
Város: Gödöllő