Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Azért sikerült ennyire összeborulni a fejlesztőkkel, mert az NV-vel a nagyok nem tudnak együtt dolgozni, mert elzárkóztak, és ez nagyban hozzájárul ahhoz, hogy a TWIMTBP az elmúlt évben nagyrészt bugos, alig optimalizált PC-s portokat rakott le az asztalra. Na meg persze nyilván számít az is, hogy az NV-től számos szakember távozott 2014-ben, akik nem értettek egyet az "ezt is lezárom" politikával. Nyilván ők azért ebben élnek nap mint nap, és pontosan tudják, hogy ha ezt csinálja az NV, akkor nem fog az adott stúdió engedelmeskedni, hanem elmegy az AMD-hez és az Intelhez. Ha az NV nem változtatott volna a G80 idején bevált recepten, akkor ma nem lenne az AMD-nek annyi partnere, amivel gyorsan át tudnak nyomni az iparon egy teljes API reformot.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#4814
üzenetére
Ők még a jobbik félbe tartoznak, de azért nem olyan jók, mint a nagyobbak. Bár ez viszonyítás kérdése. A PC Labnál sokkal jobbak, azért akkora eltéréseket ők nem dobnak be, hogy 10 fps legyen két ugyanolyan mérés között a különbség, de nem véletlen, hogy azonnal az elsőségre törnek, mert minőségben a többiek ütik őket.
Ezen a piacon általában így megy a dolog. Ha tudod, hogy nem vagy jó, akkor legyél gyors. Ha pedig tudod, hogy jó vagy, akkor legyél precíz. Nincs ezzel semmi baj egyébként.
-
Abu85
HÁZIGAZDA
válasz
regener
#4811
üzenetére
PCLab mérésekben ne keress logikát, ők régóta össze-vissza mérnek. Nem ez az első eset.
Majd jönnek a nagyok. A GameGPU és a PCLab mindig első, ezért abszolút felületes munkát végeznek, míg a többiek precízek, de elvesztik a megjelenés elsőségét. Valamit valamiért.
(#4808) sayinpety: Oké ez így világos, de mégis milyen motor az, amit csináltok? Hány compute és hány grafikai futószalagot futtattok, hogy ez így ennyire fekszik a GCN-nek?
-
Abu85
HÁZIGAZDA
válasz
sayinpety
#4781
üzenetére
Oké elfogadom ezt a lehetőséget, de azok az adatok amiket írtál itt, azt mutatják, hogy a Hawaii sokkal gyorsabb a GM204-nél. Aszinkron compute mellett és nélkül is erősebb. Aszinkron compute-tal 10 ezresmásodperccel jobb, ami azért nem kevés. Ez azért nem feltétlenül azt támasztja alá, hogy minden rendben lesz az optimalizálás kiszervezésével, de nyugodtan javíts ki, ha tévedek.
-
Abu85
HÁZIGAZDA
Az a gond, hogy nem látom, hogy egy külsős stúdió mégis hogyan tudná jobban optimalizálni a kiadott architektúrákra az adott programot. Azt értem, hogy a kiadónak a költségei így sokkal kedvezőbbek lesznek, és el is fogadom, hogy a mai világban ez egy cél, csak azt nem látom biztosítottnak, hogy a kiszervezett architektúrák optimalizálása legalább olyan jó lesz, mint amit belsőleg elvégeznek a GCN-re.
Még azt elfogadnám, hogy a kiadó esetleg úgy látja, hogy a külsősök jobban meg tudják oldani, mint a saját anyastúdió, csak az már eleve egy olyan hozzáállás a kiadó részéről, hogy belsőleg ezzel nem igazán törődtek volna, tehát a kiszervezett architektúrák hátránya már az anyagiak elosztásánál kialakult, ami viszont előre leosztott erősorrend. -
Abu85
HÁZIGAZDA
válasz
MiklosSaS
#4764
üzenetére
Csak a kiadók nem így gondolkodnak. A konzol és a PC nincs különválasztva, hanem egy nagy next-gen platformként van kezelve, és így már a GCN van többségben. A multiplatform fejlesztéseket három platformra végzik, és ha beleszámolod az Xbox One és a PS4 folyamatosan növekvő felhasználóbázisát a PC-s AMD-s bázisba, akkor az már úgy többet ér, mint ami maradt a PC-ből. Csak PC-re levetítve ez valóban öngól, de a kiadók úgy már nem tekintik annak, ahogy manapság a PC-t, az Xbox One-t és a PS4-et egybeveszik, főleg azért, mert az új lehetőségekkel a programozásuk is nagyon hasonló lesz.
Ebből a szempontból vizsgálva már érthető bizonyos a kiadók álláspontja. Nem is mondom, hogy nincs benne logika, csak PC-s szinten ez akkor is egy rossz irány, és nem tesz jót a piacnak. -
Abu85
HÁZIGAZDA
válasz
mcwolf79
#4761
üzenetére
Értsd meg miről van szó. Amit Gbors felhozott az az, hogy van egy fejlesztő a fórumon, aki azt írta, hogy a kiadójuk kiszervezte az Intel és az NVIDIA optimalizálást. Ez mégis hogyan kedvezhetne bármiben a PC-nek? Ha most azt vizsgáljuk, hogy mennyire rossz a PC-nek az, hogy zárt middleware-ek jönnek az egyik oldalról, akkor azt is el lehet mondani, hogy semmivel sem jobb, ha ezeket middleware-eket kizárod, de közben a fejlesztéseket GCN-re korlátozod. Ezzel csak átesünk a ló túlsó oldalára. Valami kompromisszumos megoldás kellene, mert nem vagyok meggyőződve arról, hogy egy külsős stúdió a motor ismerete nélkül jó optimalizálást tud biztosítani az Intelnek és az NVIDIA-nak.
-
Abu85
HÁZIGAZDA
Ezek alapján ugyanezek az értékek vannak benne egy fél évvel korábbi bétában. Nem lett volna egyszerűbb a WHQL-ekből nem kivenni? Ez az ami szerintem totálisan felesleges a PC-s játékosoknak, hogy egy profilt fél évre kivegyenek, majd most egy bétában visszarakjanak. Csak pár bájttal nyomja meg a letöltést, és már az elmúlt 4-5 WHQL GTA5 ready lenne az NV-nél is.
Egyértelműen amellett vagyok, hogy drivert csupán egy olyan profilért, amely régóta kész van felesleges kiadni, és ez mindenkire vonatkozik. Régen az NV itt volt előnyben, hogy készen várták a játékokat, most meg csak a megjelenés napján lesz WHQL? Ezt egyértelműen rossz iránynak érzem. Rossz iránynak éreztem az AMD-nél is, amikor ezt csinálták csak nem Game Readynek hívták, hanem HotFixnek. -
Abu85
HÁZIGAZDA
Olvastam a bejegyzéseket, amiről beszélsz, és szerintem az az egyik legrosszabb véglet, ami a PC-vel történhet. Én megértem, hogy a kiadó spórolni akar és kiadják az optimalizálást külsős kezekbe, de így szerinted mennyi esélye van az Intel és az NVIDIA GPU-inak jó optimalizálást elérni? Oké a kiadó hozott egy olyan döntést, hogy mivel nem tudják jól megcsinálni ezért inkább nem is foglalkoznak az Intel és az NVIDIA GPU-ival, de az anyastúdió legalább ismeri a motort, még ha a hardvert nem is ismeri, míg a külsős stúdió se a motort se a hardvert nem ismeri. És gondolják, hogy a külsősök jobb munkát végeznek? Jó persze csodák vannak, csak logikusan átgondolva nem látom miért lenne ez lehetséges.
-
Abu85
HÁZIGAZDA
válasz
mcwolf79
#4746
üzenetére
Mégis mi él a PC-s játékiparból? Az MMO biztos, az indie biztos, de az AAA multiplatform címekben a PC hátrányos, és ez az egyes játékok eladási statisztikáján is látszik. Ha előnyös lenne a PC, akkor nem most kapnál GTA5-öt, hanem megkaptad volna, amikor kész lett az X1 és a PS4 verzióval párhuzamosan.
Amikor a cikkek elkezdik bizonygatni, hogy a PC-s AAA játékpiacnak nincs semmi baja, akkor az önmagunk becsapása. Elfogadjuk, hogy az a normális, ha szar portok születnek, és ehhez még rossz support is jár. És az önámítás erre a piacra ma a legnagyobb veszély.
-
Abu85
HÁZIGAZDA
November óta kész van a leképző. Lényegében semmit sem változott. Nehogy azt hidd, hogy a Rockstar azért tolta a játékot, mert technikai gondja volt. Nem, már szeptemberben kiadható állapotban volt a PC verzió, nem véletlenül mutogatta az AMD a szokásos IDF-elleni rendezvényén. Azóta csak bekerült a sztereó3D, pár effekt, amelyek egy része ki is került, meg a TXAA, ami az AMD-nek mindegy. Semmin nem kell változtatniuk, mert semmi nem módosult, ami a grafikát érinti.
Azért meglepődnék, ha volna olyan hardcore PC-s játékos, amely azt mondja, hogy csak azért, mert az az NV-nek jelenleg kedvezőbb, inkább jöjjenek magasabb gépigényű és rondább effektek a játékokba. Hiba azt hinni, hogy a PC-s réteg annyira meghülyült, hogy már az orruknál fogva lehet őket vezetni. Biztos van ilyen ember, de az tisztán látszik, hogy a fejlesztők nem hülyültek meg és az utóbbi egy évben annyi szidást kapott az NV, amennyit a korábbi tíz évben nem. Azért ezek az emberek érteken hozzá, és pontosan látják, hogy mennyire korlátozzák a munkájukat, ami miatt rosszabb minőségű játékokat tudnak letenni az asztalra. Ha valami nem a PC gaming érdeke, akkor az ez, és teljesen normális, hogy erről a jelenségről elkezdtek páran blogolni, reménykednek, hogy az NV még azelőtt észhez tér, mielőtt túl késő lenne.
-
Abu85
HÁZIGAZDA
De ez mindkét oldalon megvalósult/megvalósul. Ha csak ez a kritérium, akkor például ott a GTA5 profil az Omega Catalystben.
Nem kell szélsőségekben gondolkodni. Elég lenne annyi, ha az NV visszaálna arra a modellre, amit 2010 előtt alkalmaztak. Jó persze nyilván hazugságokat is követel, mert nem mondhatják majd ki, hogy a GameWorks azért szűnt meg mert csak lassú és ronda eljárások lehetségesek ilyen formában, de azért vannak ott a marketingesek, hogy kitalálják mit kell hazudni ilyen esetben.
-
Abu85
HÁZIGAZDA
A sűrű WHQL pont azt a célt szolgálta, hogy gyors legyen a reakció. Az mindegy, hogy minek nevezik Game Ready, Hotfix, marika csodája, a cél megegyezik. Na most ez vagy általánosan rossz, vagy általánosan jó, vagy tekinthetjük egy stratégiának, amit jónak tarthatunk vagy rossznak, természetesen magánvéleményként. Olyan viszont nincs, hogy ez akkor rossz, ha az egyik gyártó csinálja, de akkor már jó ha a másik.
Úgy jön ide, hogy a PC valódi problémája ez. Nem az, hogy az NV átvette az AMD régi driverfejlesztési stratégiáját, míg az AMD átvette az NV-ét.
-
Abu85
HÁZIGAZDA
válasz
Bingisz
#4728
üzenetére
Nézd meg a Valve véleményét a témáról. A GDC-n nagyon leteremtették a piacot azért, mert nem gondolnak arra, hogy a felhasználóbázisuk 90%-a nem hozzáértő. Még a felbontást sem tudja átállítani. Az, hogy a cégek elkezdték hozni az olyan segítő programokat, mint a Gaming Evolved, a GeForce Experience, vagy a Raptr Intel támogatással azt jelenti, hogy rájöttek, hogy ez egy komoly gond. Ha a userek 80-90% (és ez a cégek felmérése alapján a felhasználóikra vonatkozik) nem tudja beállítani magának a natív felbontást, és Full HD-s monitoron 1024x768-ban játszik, akkor az probléma. Nagy probléma, és ennek a megoldására pénzt fektetnek. Viszont a Valve szerint ez sem elég jó. A fejlesztőnek kellene ezt egyedileg megoldani egy játékba épített ellenőrzővel, és igazuk van.
-
Abu85
HÁZIGAZDA
A játék hibája nem feltétlenül jelenti azt, hogy új profil kell.
A Frostbite 3 speciális eset. Az nem úgy van profilozva, mint egy mai átlag játék. A motor hív meg egy beépített specifikus driverrutint. Ezt azért teszik, hogy akkor is működjön a motorhoz tervezett profil, ha átnevezed a játékot, mert ugye a driver biztosítja, illetve biztosítaná, hogy ne fagyjon szét a játék DX11-es módja. De mondjuk a Frostbite 3-nál én eleve egy hibás döntésnek tartom egy olyan optimalizálást használni, amit a Microsoft a DX11-hez nem ajánl, mert tudják, hogy nem stabil. Szerintem bődületes baromság ilyenhez nyúlni, de szerencsére ez egyedi eset, más motor nem működik így.A friss driver jó dolog. A felesleges driver a rossz. A legutóbbi 5 GeForce driverben benne lehetne a GTA5 profilja, és ennek az oka az, hogy a leképző november óta változatlan. Csupán két extra effekt került bele, de nem szükséges rájuk új profil, mert ismert eljárások, amikhez már jó kódot fordít az amúgy kigyúrt complier.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#4716
üzenetére
Azt ugye tudod, hogy ha ezért a PC-s játékosbázis 90%-a átáll, akkor a PC-nek lőttek. Ez nem olyan probléma, amit el lehet intézni azzal, hogy hát akkor neked a konzol való, mert az megöli a PC gaminget. Marad pár százezer fanatikus világszerte és kész. Itt olyan megoldást kell találni, ami elfogadható kompromisszum. Például a low-level irány az. Ott profilozás sem lesz, mert az alkalmazás dönt mindenről, amit ma még profilban állítgatni lehet. Ez már egy lépés a helyes irányba.
Én inkább nem szeretnék sok drivert telepíteni, ha nem muszáj. Rakják bele előre és működik. Vannak nekem olyan Catalyst drivereim, amelyek ki sem jöttek, és olyan játékok nevei vannak benne, amelyek még meg sem jelentek. Például hetek kérdése és bejelent valamit a Codemasters, és arra már a 15.4 early test kiadásban ott a végleges profil. Szerintem ez a jó irány, mert amikor megjelenik az a játék, aminek a nevét most nem írom le, de jön, akkor én vígan elvagyok az áprilisi frissítéssel, és kész. Miért is telepítenék csak egyetlen új profilért egy új drivert? Tök feleslegesnek érzem, és tiszta szopatás, hogy rég benne lehetne a csomagban a profil, de nincs, mert a nagyfejűek úgy tartják jónak, ha erről a média ír. Mint mondtam, jelentsék be azt, hogy már ott a profil x ideje, csak ne szopassák a PC-s réteget ezzel. Nem jó, ha ezért valaki konzolra megy.
-
Abu85
HÁZIGAZDA
Nem a világnak jobb, hanem a felhasználóknak. Te is arra panaszkodtál régen, hogy hiba sűrű drivert kiadni, és az NV ezt sokkal jobban csinálta hogy nem tett így. Szerintem is nagyon igazad volt abban, hogy jobb az, amikor előre benne vannak a profilok a driverben, amikor elkészülnek, nem aznap amikor kiadják a játékot, vagy havi rendszerességgel. Volt olyan, hogy egy hónapban háromszor jött Game Ready driver. Mégis minek? Azon a két-három napon múlott a profil elkészítése? Elég lenne előre belerakni a profilt a driverbe és kész. Mindenkinek egyszerűbb lenne. A PC-s piac egyik legnagyobb problémája, hogy ma már minden játékhoz új driver kell. Ismerőseim mind PC-s játékosok voltak, de ~70%-uk már konzolos, és az elsődleges indokuk, hogy a PC túl van bonyolítva, új driver, új ez, új az, ami szükséges, hogy elinduljon a játék. Konzolon berakod és működik. Nagyon fontos lenne, hogy a felhasználókat ezzel ne szopassák, mert mennek a konzolok felé.
De a driverkérdés csak döntés kérdése. Igazából csinálhatják ahogy akarják, ha működik, akkor oké, és igazából ez régóta működik mindkét oldalon. A nagyobb probléma a teljes széthúzás, amit a fejlesztők felé tanúsítanak. Tényleg lassú middleware-ekre van a PC-nek szüksége? Most komolyan, végre közelebb kerül a PC a konzolos fejlesztési modellhez, ami szebb és gyorsabb játékokat eredményezhet, erre most meg az effekteket zárják le. Te is pontosan tudod, hogy az általános middleware-ek a kompatibilitásra alapoznak, és ezért cserébe beáldozzák a minőséget és a sebességet. Tényleg ez a jövő? Jó az árnyékok és a post-process elmegy. Maximum lassú, de a minősége elfogadható szintű lehet, hiszen nem komplex effektek. Egy SSAO algoritmus is screen space. Viszont amint bonyolódik a helyzet jön a gond. Lásd a hajszimuláció. Nem sok embernek tetszik a HairWorks, pedig láthattad több programban is. Mi hiányzik belőle? A transparency eljárás, hogy ne legyen spagettiszerű. Miért nincs benne? Mert zárt a kód, és baromira nehéz, vagy nem is lehet általánosan transparency eljárást csinálni, ami minden leképzővel kompatibilis. Ha beleraknának egy elfogadható technikát, akkor csak bizonyos körülmények között működne az egész rendszer, vagyis nagyon sok motorba nem is lehetne implementálni a technikát. Ezek tipikusan gyengítik a PC-s ipart, ráadásul zéró értelme. Daveoff mint NV tulaj korábban mondta, hogy neki a TressFX jobban tetszik, de igazából ami tetszik neki, az nem a TressFX mint technika előnye, hanem a nyíltságé, hogy a kód módosítható, és aki bedobja a játékba, az tényleg leportolhatja a teljes eljárást. Ha nem kompatibilis az eredetileg szállított analitikai AA és az árnyékolási rendszer, akkor át kell írni és működik. A HairWorks esetében ilyen nincs. Ha valami nem kompatibilis, akkor kikapcs és minden egyes ilyen döntéssel folyamatosan minőséget veszít az effekt. Meggyőződésem, hogy ez nem az a jövő, ami a PC-nek jár, vagy amit egy hardcore PC-s játékos elvár.
-
Abu85
HÁZIGAZDA
válasz
Televan74
#4660
üzenetére
Amióta eldöntötték, hogy jön next-genre, ideértve a PC-t, azóta részt vesznek a fejlesztésében. Az új effektek közül, amik vannak konzolon és most már elmondhatom, hogy lesznek PC-n is, a tesszellációt, az HDAO-t, a DoF-ot az AMD adta a fejlesztőknek, amit a végén megfejeltek egy CHS-sel, ami egy gyors igény volt. Egyetlen dolog nem jön PC-re, az pedig a temporális szűrés, mivel az gépi kódban fut a konzolokon, és magasabb szintre nem portolták. PC-n ez az eljárás jelen formájában működésképtelen, elméletben viszont lehetséges, a DX12 kínál is majd rá egy alapot.
-
Abu85
HÁZIGAZDA
Ez főleg annak tükrében érdekes, hogy a PC-s fejlesztők most folyamatosan szidják az NVIDIA-t a GameWorks middleware-kért. Még az Ubisofttól Bartlomiej Wronski is odaszólt nekik az elmúlt évben, hogy a hardvereik tök jók, de a szoftveres részleg lábon lövi magát a GameWorks-szel. Arra törekszenek, hogy minél jobban elzárják a fejlesztők elől az optimalizálási és dizájnbeli döntési lehetőségeket, ami teljesen érthetetlen, hiszen régen pont ők képviselték azt, hogy a fejlesztőknek szabadság kell, mert csak akkor lesz jó minőségű a program, ha kevés middleware-t használnak.
A legjobb példa most a The Order: 1886. Látszatra azt hiszed, hogy PS4-es csodafícsőrökkel tarkított valami, de Matt Pettineo a GDC-n elárulta a "titkot", és ezt magyar fordításban idézném: "Ne használj kibaszott middleware-ket!". Nyilván egyébként PC-re nem lesz kiadva, mert a Sony-nak nem érdeke, de azt is elmondta, hogy elméleti akadálya nincs a portolásnak, és így nézne ki PC-n is.
Szerintem egy óriási probléma, hogy amikor végre történik valami a PC-n, akkor előkerülnek a mesterséges akadályok. Végre átnyomtuk az új API-kat (nem úgy ahogy azt az MS és a Khronos szerette volna, de ezen már kár siránkozni), a fejlesztők megkapták a lehetőséget, hogy a működést mélységekben profilozzák, és ehhez még hozzájönnek az új API-k új funkciói, de ez csak járulékos extra, most tekintsünk el tőle. Mi lett volna a hardvergyártók feladata? Dokumentálni a hardvereket és kiadni a belsőleg használt disassemblert. Egyszerű az egész, ezt régen, 2010 előtt amúgy is megtette lényegében mindenki. Erre most, amikor igazán szükség lenne rá, előjönnek az önös érdekek, hogy mivel lehetne a fejlesztő munkáját akadályozni. Ma nincs olyan fejlesztőstúdió, vagy szimplán motorprogramozó, aki szerint a nagyobb kontroll ne eredményezne jobb játékokat. És az, hogy látják a kód teljes működését lényegében óriási előny, mert eddig ez hiányzott. Erre előjön az NV, hogy nesze itt a GameWorks, ami zárt middleware-ek gyűjteménye, hogy még véletlenül se tudd optimalizálni a működését, és PC-n ne lehessen előhozni olyan minőségi grafikát, amivel a The Order: 1886 előállt. Megint sikerült kilopni a szenet a mozdonyból.
Egyébként aki kíváncsi a GTA5-re megnézheti. A játék azért nem jelent meg márciusban, mert a Rockstar beépítette az NVIDIA ShadowWorks middleware-t, és amikor megnézték a teljesítményét, akkor megdöbbenve látták, hogy a PS4-en alkalmazott technikáknál rondább és lassabb effekteket kaptak. Éppen ezért a PC-s AO helyére behozták a konzoloknál alkalmazott egyedi HDAO variánst, így a PC-s port ebből a szempontból olyan szép és gyors lesz, mint a konzolos (X1/PS4) verzió, míg az NVIDIA PCSS a szerződés értelmében bennmaradt, de az AMD-től elkérték a CHS-t, amit végül integráltak a mostani startig, hogy ugyanazokat az árnyékokat gyorsabban is kiszámolhassák a PC-k. Ez a baja a zárt middleware-eknek. Az így kapott effektek lassúak és sokszor rondák is, mert nincsenek jól beleintegrálva a motorba. Utóbbi szimplán lehetetlen, mert zártak, és ezért optimalizálhatatlanok is. -
Abu85
HÁZIGAZDA
Technikailag nem szükséges minden játékra új driver. Az NVIDIA csak átállt egy olyan modellre, hogy minden játékhoz új drivert kelljen telepíteni, annak érdekében, hogy ezzel marketingelni lehessen. Ezért van mostanában sokkal több driverük. De csinálhatnák úgy is, mint régen, hogy ritkán jön a driver, és előre belerakják a profilokat. Erre állt most rá az AMD. A GTA5 esetében lényegében nem kell új profil, magához a játékhoz már novemberben kész volt a szükséges profil, és mivel a leképzőn az elmúlt 5 hónapban nem változtattak a Rockstarék semmit, így ezek a profilok ma is jók. A különbség az, hogy ezt az NV a novemberi béta driverből kivette, hogy most bele tudják tenni ugyanazt egy Game Ready driverbe, míg az AMD ezzel nem foglalkozik, és az Omega driver óta szállítják, minden újabb driverben.
A felhasználó nézőpontjából is csak annyi a különbség, hogy GeForce-on telepíteni kell egy új drivert, míg Radeonon nem muszáj.
Régen egyébként pont ellentétesen csinálta az NV és az AMD. Az NV adott ki ritkán drivert és azokban mindent előre beépített, míg az AMD havonta nyomta az új Game Ready drivereket.
Ez nyilván a dolgok stratégiai része, de amit én nem értek, hogy mi értelme egy profilt visszatartani hónapokig, amikor novemberben ott volt egy driverben. Ott lehetett volna hagyni. Nem feltétlenül akarok én minden új játékhoz új drivert telepíteni. Szerintem ez rossz irány, és ez az amitől több PC-s játékos is menekül. Szoftverfrissítésre természetesen szükség van, de hogy minden nagyobb játék előtt? Rakják be amikor kész és azzal le van tudva a támogatás. Azzal is nagyon jól lehet marketingelni, hogy némá ott a profil 5 hónapja, és közben nem szopatod a felhasználóidat. -
Abu85
HÁZIGAZDA
Már az Omega driver tartalmazta a GTA5-re a profilt. A 15.3-as béta driverben is ugyanaz a profil van, és dev csatornán is az van odaírva mellé, hogy nincs szükség módosításra a végleges játéknál sem. Ettől függetlenül lesz áprilisban egy új driver, de nem a GTA5 miatt (hanem a Crossfire FreeSync támogatás miatt). Ennek a játéknak a profilja ugyanaz marad, mint ami az Omega driverben benne van.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#4507
üzenetére
Nem. Nagymértékben függ majd a teljesítmény a szoftvertől, egészen pontosan attól a kódtól, amit a fejlesztő bevisz. Ha az a kód nem jó, akkor azt driver ki nem javítja.
Elsődlegesen az kell, hogy a fejlesztőknek elárulják a gyártók, hogy mit tud az adott GPU. Ezért fejezi be a bemutatókat az MS és a Khronos úgy, hogy "disassembler és dokumentáció"! Ezek mostantól kellenek. -
Abu85
HÁZIGAZDA
válasz
daveoff
#4505
üzenetére
A DX12-ben nincsenek hagyományos értelemben vett driverek. Az alkalmazásban van benne az, ami ma még a driverben van. Ennyi. A driver marad egy shader fordító és nem több, de egy be nem jelentett újítás majd ezen is teker egy nagyot, és onnantól kezdve a gyártónak gyakorlatilag semmi beleszólása nem lesz, hogy melyik program hogyan fut a hardverén. Maximum odaülhetnek a stúdiók programozói mellé tippeket adni. Kb. ennyi marad a hatáskörük.
-
Abu85
HÁZIGAZDA
válasz
Laja333
#4395
üzenetére
Ha a teszt csak szimplán tolná rá a parancsokat a hardverre és igazából a mérés csak az overheadre lenne korlátozva, akkor lényegében az azonos architektúrára épülő GPU-k eredményei megegyeznének.
Mivel a 3DMark tesztje ennél komplexebb teszt a procedurális tartalmakkal és a GPU-k erős terhelésével, így számít a GPU-k teljesítménye. -
Abu85
HÁZIGAZDA
A 3DMark API Overhead tesztje nem tipikus API Overhead teszt. Ezért vannak benne látszatra furcsa eredmények. Ami a teszt célja, hogy az API-nak a többletterhelését küldje az egekbe a sok generált paranccsal. A draw call itt nem csak a grafikai munkára vonatkozik, hanem a procedurális tartalomra is. A teszt a kirajzolandó tartalmat compute-tal generálja, ráadásul a generálás aszinkron. Tehát egyszerre beszélünk egy overhead tesztről, mert generálja a parancsokat, mint az állat, és egyszerre van szó egy stress testről is, mert aszinkron etet mindent a GPU-val, minden lehetséges parancslistán keresztül, illetve a procedurális tartalomgenerálás sincs ingyen, így a GPU-k teljesítménykülönbsége meglátszik.
-
Abu85
HÁZIGAZDA
Szerintem ezt a sample-t eleve nem hardveres összehasonlításra szánta. A jellegét tekintve nagyon szintetikus, tehát nem is igazán reprezentatív, mert egy valós programban sokkal több fényforrás lesz, és sokkal komplexebb a jelenet is. Itt azt akarja reprezentálni, hogy az Ola Olsson, Markus Billeter és Ulf Assarsson által kidolgozott koncepció működik, ahogy ő a gyakorlatba ültette. Persze ezt más is megtette már picit eltérő, de alapjaiban hasonló módon, viszont más csak diagramokat mutogatott. Emil Persson most mutatott egy gyakorlati példát, ami jól reprezentálja a hardvereken elérhető gyorsulási lehetőséget.
-
Abu85
HÁZIGAZDA
Az a szép ebben, hogy itt mindenre vonatkozik a gyorsulás. Persze valamennyire meghatározza az architektúra, hogy mennyi lesz az extra, de az biztos, hogy mindenen extra lesz. Ráadásul erősen két-háromjegyű százalékban.
Ezért írok sokszor ezekről a leképzőkről, mert egy csomó motor leragadt a klasszikus deferrednél, aminél ma már sokkal gyorsabbak vannak, és ugyanarra a minőségre képesek.
Ha megnézed a játékokat, akkor alig van olyan, amely mozaikos koncepciót használ. Klasztereset pedig nagyítóval kell keresni. -
Abu85
HÁZIGAZDA
Tudom, hogy nem gyártógyalázós dolog, de érdekes.
Emil Persson felrakott egy borzasztóan jó sample demót az oldalára. [link] - itt töltsétek le. Kérjetek fullscreent és natív felbontást, illetve max MSAA-t, ami 8x. Nézzétek meg mi történik az fps-sel, ha az F5 és az F7 billentyűvel a Clustered Forward (nem igen alkalmazzák még) és a Classic Deferred (eléggé elterjedt) leképző között váltogattok. Ennyit számít az algoritmus!
Jó szórakozást.
-
Abu85
HÁZIGAZDA
Kisebb felbontáson igen.
Az AotS brutál extrém terhelés. A sávszél nagyon kell neki, de nagyon díjazza azt is, ha az architektúra hatékonyan képes egymás mellett futtatni több compute pipeline-t. Manapság erről azért nincs semmi, mert nincs olyan játék, ami két pipeline-t egymás mellett futtat, erre most jön egy, ami 1 grafikai mellé 7-9 compute pipeline-t is odapakol. Ebben nyilván a GCN új verziója erősebb, mint a GCN2.
(#4299) players111: Májusban opció. De maga a hardver kész, csak az AMD nem akar külön rendezvényt tartani a hardvernek és a szoftvereknek. Nem csak új GPU jön, hanem egy új API is.
-
-
#4144
Abu85
HÁZIGAZDA
Malibutomi
#4142
Abu85
HÁZIGAZDA
válasz
Malibutomi
#4142
üzenetére
De nem ebből a diasorból. Hanem egy másikból. Egyébként maguk az adatok valósak csak nem grafikonon szerepelnek.
-
Abu85
HÁZIGAZDA
Ebben nem is kell hinni. Ez nem a végfelhasználóknak szól, hanem a fejlesztőknek.
Régóta látszik már a piacon, hogy az NV azokat a fejlesztőket gyűjti maga köré, akik azt szeretnék, ha vezetnék őket. Nincsenek különösebb igényeik, csak ki akarják valahogy használni az elérhető API-kat, és itt jön képbe az NV az effektjeivel. Az AMD ezzel szemben azokat gyűjti maga köré, akik diktálni akarnak, és azon gondolkodnak, hogy milyen elméleti kutatásokat lehetne a gyakorlatba önteni, függetlenül attól, hogy szabványos API-n megvalósítható-e. Ha nem, akkor kell hozzá egy felület és itt jön képbe az AMD a saját API-jával. -
Abu85
HÁZIGAZDA
A fejlesztők. Az AMD azért ül oda egy-két mérnökkel a világ top fejlesztői mellé, hogy első kézből, mindössze pár méterre tőlük hallják a bajokat, amire rekordsebességgel akarnak reagálni. Ezzel a fejlesztők meghatározhatják a fejlődést, és fel is gyorsíthatják, mert az MS és a Khronos elfogadja az igényeket, de két évig úgyis csak megbeszélés lesz róla. A Mantle azért marad zárt, mert nem akar az AMD megbeszélést a többi gyártóval. Ha valamire igény van, akkor beépítik, az igénylő használhatja, majd odaadják a speckókat az MS-nek és a Khronosnak, hogy építsék be a szabványos API-kba. Az AMD-től ők persze ülhetnek rajta évekig, de nem fognak, mert kényszerhelyzetben vannak, hogy van egy API, ami már támogatja, így lépni kell szabványos szinten is.
-
#4126
Abu85
HÁZIGAZDA
Malibutomi
#4124
Abu85
HÁZIGAZDA
válasz
Malibutomi
#4124
üzenetére
Valószínű, hogy nem teljesen helytálló az a kép. Csak azért, mert ma nem adható ki ilyen kártya tesztre. Emellett a gyártóknál is egy nagyon megbízható zárt körben érhető el. A nem megbízható körök először csak papírt vagy pdf-et kapnak, és csak utána hardvert.
Egyetlen adat van a Fijiről, mégpedig az Stardock vezérétől. Ő nem mondta ki a termék nevét, illetve a Fiji nevet sem, csak azt, hogy az új generációs Radeon a játékukban minden korábbi VGA-nál egyértelműen gyorsabb, ideértve a 295X2-t is. Bár náluk vélhetőleg felerősíti az előnyt az a tény, hogy a Nitrous új verziója rendkívül ki van éhezve a memória-sávszélre, így a többi VGA teljesítményét ez erősen limitálja. -
#4122
Abu85
HÁZIGAZDA
Malibutomi
#4119
Abu85
HÁZIGAZDA
válasz
Malibutomi
#4119
üzenetére
Nem a takarékosságon volt a hangsúly, hanem a hatékonyságon. Nem ugyanaz.
Van pár be nem jelentett dolog az AMD-nél. Februárban kb. tíz GPU-hoz kötődő projektet zártak le, amelyeket az év további részében beépítenek. Ezek között van pár, ami a dedikált GPU-kat közvetlenül érinti, és elég érdekes irányokat vet fel. Amit eddig tudni, hogy az AMD innentől kezdve nem vár majd az iparra, hanem berendezkedtek egy olyan szisztémára, ahol ők határozzák meg az irányt. Ez majd rengeteg exkluzív programfunkciót fog eredményezni a jövőben, mert számos fejlesztő is azon a véleményen van, hogy ha így hamarabb lesz DX13 vagy Vulkan 2, akkor támogatják az AMD koncepcióit, csak kényszerüljön fejlesztésre az MS és a Khronos. Ez egy igen furcsa váltás lesz a PC-s játékpiacon. -
Abu85
HÁZIGAZDA
válasz
mcwolf79
#4093
üzenetére
(#4092) TTomax: Mármint, hogy az AMD-nek jön jól, vagy az AMD adta az alapját? Igazából többször is elismerték az érintettek, hogy az AMD mutatta meg, hogy PC-ben is lehetséges ez a low-level modell, és erre épített a Microsoft is. Persze az MS mindig is a Win 10-hez tervezte.
Az meg, hogy az AMD-nek jön jól egészen nyilvánvaló, ők szenvednek a leginkább attól, hogy a hardverek nehezen használhatók a limitált API-k miatt. Mostantól ez megszűnik. Nem véletlen, hogy a GCN támogatja a legtöbb DX12 funkciót. -
#3518
Abu85
HÁZIGAZDA
Malibutomi
#3516
Abu85
HÁZIGAZDA
válasz
Malibutomi
#3516
üzenetére
Az 1.0-s Mantle átkerül a Vulkan API-ba. A Khronos nyitja meg.
Aki eddig fejlesztett Mantle-re, annak elérhető marad az SDK, mert nyilván nekik gáz lenne az átmenet, tehát a munkát befejezhetik.
Aki most akar Mantle-re 1.0-ra fejleszteni az ne tegye, mert a Vulkan lényegében ugyanaz. Ez tök logikus felhívás.
Csütörtökön lényegében egy puszilkodás lesz, hogy köszöni a Khronos a Mantle 1.0-t, amivel megmenekültek attól, hogy az MS ismét megalázza őket.
A Mantle jövőjéről májusban lehet majd hallani. Igen egyébként megy tovább, de egy teljesen új API formájában, ami nem lesz kompatibilis az aktuálissal. A Mantle arra szolgál majd, hogy ha egy fejlesztő valamit nem tud megcsinálni a szabványban, akkor nem kell az álmait eldobnia, hanem az AMD csinál kiterjesztést az álmaihoz. -
Abu85
HÁZIGAZDA
Attól még a probléma létezik. A gyártóknak egyénileg kell eldönteni, hogy ez a ghosting hiba belefér-e vagy sem. Az AMD ezzel úgy van, hogy döntsd el te: AFR friendly.
Az XDMA arra való, hogy a multi GPU akkor is működjön, ha a hidas megoldás már nem elég jó. 4K-ban a Crossfire XDMA azért ad sokkal jobb eredményeket, mint az SLI, mert híd sávszélessége kevés. 4K-val az NV már nem is használja. Helyette az adatokat először a rendszermemóriába másolják, majd onnan elérheti a másik GPU. Ennek az előnye, hogy nagyobb a sávszél mint a hídnál, de hátránya, hogy jóval nagyobb a késleltetése is, tehát nehéz a folyamatosságot biztosítani. Ez az oka annak, amiért a H azt írta, hogy 4K-tól a CF folyamatossága jobb.
-
Abu85
HÁZIGAZDA
(#3487) TTomax: Ez nem teljesen igaz. Azt is lehet egyébként tudni, hogy mi a gond. A Dunia Far Cry 4-hez használt iterációja Ka Chen adaptív virtuális textúrázását alkalmazza. Ennek az előnye, hogy igen nagy méretű terepet lehet feltextúrázni, de a hátránya, hogy a rendszer címzése adaptív. Ez AFR-rel egy olyan problémát eredményez, hogy a páros képkockákon bizonyos textúrák eltolódva jelennek meg, mint a páratlanokon. Ez egyfajta ghosting hatást generál, ami elmossa valamennyire a textúraminőséget. Ez csak mozgás közben látszik, mert egy képkockára levetítve a ghosting jelenség nem él. Lehet dönteni, hogy ezt elfogadod és engeded a multi GPU-t, vagy inkább nem, és akkor nem lesz ghosting sem.
A CoH 2-ben is működhet az AFR, csak zizegni fognak a textúrák.
-
Abu85
HÁZIGAZDA
Nem tudom kire gondolsz az OCUK-n. Én főleg Andrew Doddtól kapok erre vonatkozóan adatokat. Ő a driverfejlesztés vezetője. Elmondta, hogy ha az Ubisoft megoldja, hogy hibátlan lehessen az AFR, akkor bekapcsolják a támogatást. Addig csak az AFR friendly az opció erre, ami olyan minőség, mint az SLI. Ennél több ebben a programban még nincs. A nyárt sem véletlenül mondtam. Az Ubi akkorra ígérte, hogy megoldják az AFR-t. De ha mostani minőség elég, akkor ott AFR friendly opció és műxik.
-
Abu85
HÁZIGAZDA
Mert bugos az AFR támogatása a játéknak. Innentől kezdve vagy letiltja a gyártó az AFR-t, vagy bugokkal elfogadja. Egyébként azt ígérte az Ubi még januárban, hogy megoldják a gondokat, csak nem élvez prioritást a multi GPU. Valamikor nyárra talán lesz egy olyan frissítés, amivel bugok nélkül működni fog.
Egyébként az AFR-Friendly profillal bekapcsolhatod a CF-et is, csak ugyanazt az élményt kapod, mint az SLI-vel, ami nem jó.
Azt tudni kell, hogy az AMD akkor nem kapcsolja be AFR támogatást, ha bármilyen hiba van. Az NV akkor is bekapcsolja, ha akadni fog, vagy apró grafikai hibákat generál. A Far Cry 4-nél például a textúrák eltolódása. Ha hiba van, akkor döntsd el, hogy bekapcsolod-e vagy sem AFR-Friendly-vel. -
Abu85
HÁZIGAZDA
válasz
daveoff
#3478
üzenetére
A HBM miatt nem csak az AMD tervezi a hűtést. A Hynix, a Cooler Master és az Asetek is részt vesz benne. Ez az első bevetése egy nagyon új technikának, tehát másnak is nagyon tudni kell, hogy mi az, ami működik. Ez a kártya határozza meg azt is, hogy a Hynix a második generációs HBM-hez mit ajánl és mit nem.
-
Abu85
HÁZIGAZDA
válasz
proci985
#3472
üzenetére
Tulajdonképpen a 295X2 pontosan úgy működik, mint a 290X CrossFire, tehát abszolút mindegy, hogy melyiket választja. Nyilván a 295X2 előnye, hogy eleve egy baromi jó hűtéssel jön, de hátránya, hogy egy kártya, tehát egyben is lehet eladni. A 290X CrossFire pro/kontra dolog pedig fordított.
Az új szériából esélyes, hogy nem is lesz cserélhetű hűtés, mert a HBM nagyon bonyolítja a lehetőségeket. Sokkal jobb, ha marad a gyári, mert annál hatékonyabbat úgy sem fognak építeni a gyártók.
Az mindenképp előny egyébként, hogy az új GPU-k XDMA-sak. Ez majd a DX12-nél fontos lesz, mert XDMA nélkül le kell állítani a futószalagot az adatmásoláskor, míg XDMA-val erre nincs szükség, tehát a másolások mellett is számolhatnak a GPU-k.
-
Abu85
HÁZIGAZDA
Abból megy ki a kép a monitorra. Ma az alkalmazás a low-level API-val megmondja a drivernek, hogy hol a képkockapuffer, majd a driver a kijelzőszinkronhoz igazodva kiteszi a tartalmát. Viszont a belső szinkron mellett azt is meg kell mondani, hogy a képkockapuffer kész-e. Mert ugye itt most törött tartalom is kimegy.
Ezt eddig a driver láthatta, és aszerint szinkronizálhatott, de a low-level API-val már nem látja a meghajtó, tehát az alkalmazásnak kell megmondani, hogy kész a puffer és mehet. Ha nem teszi meg, akkor a driver nem fogja tudni eldönteni, hogy mikor teljes a puffer tartalma, tehát se a V-Sync, se az ilyen-olyan Sync nem fog működni. Nem jelentős probléma, csak pár sor, de bele kell írni az alkalmazásba. Aki támogat V-Sync, annak lényegében nincs igazán dolga más Sync-cel sem. -
Abu85
HÁZIGAZDA
Mert csak az alkalmazás tudja, hogy hol van a memórián belül a képkockapuffer. Erről a DirectX 12 alatt egy külső programnak, vagy akár drivernek fogalma sincs.
Minimális dolog, hogy a külső rutinok megtudják hol van a szükséges adat, és ezt csak a program tudja megmondani nekik. Ehhez kell majd SDK. A fejlesztők munkája nem lesz túl nagy, de meg kell mutatni milyen címtartományban van a képkockapuffer és azt mikor olvashatja a driver.(#3466) Taposo: Mert amikor ezek a technológiák bemutatkoztak még nem került előtérbe a low-level API. Enélkül természetesen általános lehet a támogatás.
-
Abu85
HÁZIGAZDA
Nem írtam, hogy nem lehet használni (és szerintem erre vonatkozóan nincs megkötés a partnerprogramokban), de az A-Sync és a G-Sync támogatásához direkt kód kell az alkalmazásba. Az A-Sync implementálásához szükséges alap ott lesz a DX12 SDK-ben. A G-Sync implementálása is lehetséges, de ahhoz egy külön csomag kell, amit az NV-től kell licencelnie a fejlesztőknek. Ha valamiért nem licencelik, akkor nyilvánvalóan képtelenek lesznek G-Sync támogatást írni az adott programba.
Olyan ez, mint a 3D Vision. Például a Square Enix nem licencelte, így csak több hónappal később épült be a támogatás a Deus Ex: HR-be, amikor az NV már ingyen odaadta nekik az SDK-t. Valószínűleg lesz olyan fejlesztő, aki a G-Sync-ért sem fog fizetni, hanem kierőszakolják az ingyenességet. -
Abu85
HÁZIGAZDA
válasz
daveoff
#3460
üzenetére
Mivel a DX12 egy low-level API, így a Crossfire és az SLI pont annyira lehetetlen, mint az AMD API-ján. A fejlesztőnek kell egyénileg megírnia a több GPU-s módot. A driverből kényszerített megoldások üzemképtelenek.
Minden low-level API, amely explicit memóriamenedzsmentet enged annyit jelent, hogy a grafikus driver az aktuális formában eltűnik. Amit ma be tudsz kapcsolni, mint az MSAA, post-process AA, anizo, akármiizé, V-Sync, A-Sync, G-Sync, adaptív akármiSync, meg még a jó ég tudja, mi van a driverben teljesen eltűnnek. Mindegyik funkcióra az alkalmazásba kell támogatást írni, direkten, minden architektúra minden verziójára, mindenféle különbséget figyelembe véve.
Ez az egész abból keletkezik, hogy eddig a driver látta mi van a memóriában. Mostantól csak az alkalmazás látja ezt. -
Abu85
HÁZIGAZDA
válasz
daveoff
#3455
üzenetére
Dehogy lőttek! Már milliószor írtam, hogy az AMD API-ja mögött egyetlen cég áll, vagyis sokkal gyorsabban fejlődik majd, mint a DirectX 12. Amellett persze, hogy már ma is többet tud. Azért fejleszt számos stúdió elsődlegesen az AMD API-jára, mert ha igényelnek valamit, ami az API-ban nincs benne, akkor azt akár saját maguk belerakhatják. A DirectX 12-nél a Microsoft dönt arról, hogy mi a jövő és nem a fejlesztő. Ez még mindig sokaknak nem tetszik. De a DirectX fejlődése is irányítható, ha van egy olyan API-d, ami kikényszeríti a változást a Microsofttól. Nem kell könyörögni nekik egy funkcióért. Belerakja az AMD a saját API-jába és a fejlesztők odadobják a pöttyös labdát az MS-nek, hogy mi erre megyünk. Követhettek minket, vagy lemaradhattok.
-
Abu85
HÁZIGAZDA
Ez az antiboostolás tök értelmetlen, mint problémaként feltüntetett jelenség. Meg kell érteni, hogy ma annyira széles spektrumú a terhelés, hogy egy alapórajel nem elég hozzá, mert akkor a legrosszabb lehetőséget kellene figyelembe venni. Ezért jöttek a DVFS technikák, amelyeknél elég az átlagos szintekre tervezni, és ha marad kraft, akkor mehet a boost, ha meg nem, akkor az alap alá megy az órajel.
Ti még nem láttátok, de az Oxide-nak lesz egy új demója. A GDC-n mutatják be, és ott nem egy mai kártya az alapórajeléből lead 200-300 MHz-et is, mert annyira túl van terhelve. De lefuttatja a programot, tehát működik a technika. Tuning mellett lehet, hogy probléma lesz, de alapkonfiguráción okés. -
Abu85
HÁZIGAZDA
A 128 bit nem annyira kritikus probléma. De eleve elfelejtjük, hogy a bitek helyett inkább a GB/s-ot kellene nézni. Biztos megszokás.
Egyébként nyilván a mai motorok nagyon sávszélkímélők, ami szerintem abszolút logikus fejlődés volt, mert pár éve világosan látszik, hogy a bandwidth nem igazán nő, miközben a TFLOPS igen. A nagy kérdés ott van, hogy az új motorok merre mennek. A leképzőknél nincs értelme kidobni az eddig elért eredményeket. Mindegy, hogy miért megyünk a klaszteres technikák felé, a lényeg, hogy gyorsak. A jövő technikái viszont érdekesek. A Nitrous 36 mintás temporális MSAA-ja azért nem sávszélbarát, tehát amit most nem használunk ki, annak az új lehetőségekkel nekieshetnek a fejlesztők. Az anizo cseréjére is vannak érdekes javaslatok, és azok kétpofára zabálják a sávszélt, miközben ALU-t alig terhelnek. -
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
A Computerbase tesztjében látszik egyébként az egész probléma: [link] - olyan mintha egy GPU-val is AFR-ed lenne frame pacing nélkül. És látszik, hogy a Radeon kihasználása alacsony, tehát sokkal egyenletesebb a frame-time. Az AFR támogatása itt most a legkisebb gond.
A gyártóknak is mérlegelni kell, hogy a folyamatosságra, vagy a nyers fps-re mennek. Ez így teljesen hibás. Mindenképp változtatni kell a motor paraméterezésén. -
Abu85
HÁZIGAZDA
Kell hozzá profil. Egyelőre ennek a játéknak más baja is van. Ha nő a GPU-k terhelése, akkor iszonyatosan rossz lesz a frame-time. Az AFR-rel ilyenkor nem éri meg foglalkozni, mert a legnagyobb gond, hogy 40%-os kihasználás felett egy GPU-val is 30 ms-os frame-time különbségek vannak nagyon sűrűn. De érdekes, hogy 30%-os kihasználással ez a gond eltűnik, csak úgy meg alacsonyabb a teljesítmény, de érzésre sokkal folyamatosabb. Itt a motort is tovább kell patch-elni, mert az úgy nem jó, hogy növeled a kihasználtságod, amivel nő az fps, de közben bejönnek a mikroakadások.
-
Abu85
HÁZIGAZDA
válasz
Anubris
#3168
üzenetére
A SEGA leányvállalata a CA. Még ha csak partnerek lennének, de nem, vállalati kapcsolat van köztük. De egyébként mindegy ki a bűnös a lényeg, hogy rossz irányba haladnak, és ez igen hamar megbosszulja magát, mert a stratégiai játékok műfaja erősödik. A Firaxis mellett elevickéltek, és a Stardock sem volt nagy versenytárs nulla kiadott játékkal 2014-ben, de mostantól sokkal többel készülnek, vagyis a kiéhezett játékosokra nem lehet számítani, mert egy-két stratégiai játék helyet mostantól kapnak fél tucatot, vagy többet.
-
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.
Csak kezeljük megfelelően.
Ehhez a motorhoz komoly javítások kellenek.
Ú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.
- Kés topik
- Exkluzív órák
- Adobe Lightroom topic
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- Elektromos (hálózati és akkus) kéziszerszámok, tapasztalatok/vásárlás
- Formula-1
- Mibe tegyem a megtakarításaimat?
- OLED TV topic
- AMD GPU-k jövője - amit tudni vélünk
- Itt a Galaxy S26 széria: az Ultra fejlődött, a másik kettő alig
- További aktív témák...
- ÁRGARANCIA!Épített KomPhone i5 14400F 32/64GB RAM RTX 5060 Ti 8GB GAMER PC termékbeszámítással
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7800X3D 32/64GB RAM RX 9070 16GB GAMER PC termékbeszámítással
- Xiaomi 14T 256GB, Kártyafüggetlen, 1 Év Garanciával
- Honor Magic5 Lite / 6/128GB / Kártyafüggetlen / 12Hó Garancia
- PANASONIC Toughbook CF-53,i5-3340M,4GB RAM,500GB HDD,DVD,WIN10
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest