- Xbox Series X|S
- Fortnite - Battle Royale & Save the World (PC, XO, PS4, Switch, Mobil)
- Alkoholista nevelde
- Red Dead Redemption 2 (PC)
- Dragon Age: Origins
- PlayStation 5
- Dead Island 2 - Túl a 7 millió játékoson
- Forza sorozat (Horizon/Motorsport)
- Battlefield 2042
- Már elérhető Steamen a klasszikus Marathon
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz
daveoff
#13416
üzenetére
Nem nehezebb vagy költségesebb, csak ha nem jó a motor struktúrája, akkor úgy járnak, mint a Unity vagy az Unreal Engine 4. Mindkét motornak van DX12 módja és megfelezi a sebességet.
A legfőbb gond az, hogy kvázi hasonló időben elérhető volt két explicit API. Most ne számítsuk a nagyon korai elérést. Az AMD Mantle a tömegek számára nagyjából 2014 februárjától, míg az Apple Metal márciustól vált elérhetővé. Majdnem azonos időben, az az egy hónap nem számít. Számos cég a Mantle-t igényelte, míg a másik tömeg az Metált. Ekkor már mindenki tudta, hogy lesz DX12, tehát akartak valami tapasztalatot róla.
A Frostbite Team, a Rebellion, a Firaxis, az Oxide, a Nixxes, az EIDOS Montreal, a CIG, az Arkane Studios, a Capcom, a Crytek, a Crystal Dynamics, a Codemasters, a Bohemia Interactive, stb a Mantle-t kezdték tesztelni és erre írták át a motorokat. Nekik a DX12 (és a Vulkan is persze - csak az akkor még nem létezett) implementálása egyszerű volt, mert tulajdonképpen a Mantle a két új PC-s API apja, tehát hasonlók az igények. Emiatt tudott az Oxide előállni egy DX12-es tesztprogrammal viszonylag hamar, és ezek közül a cégek közül más sem panaszkodott gondra. Ezzel szemben voltak akik az Apple Metalt implementálták elsődlegesen, ami persze ment. Ilyen cég az Epic, a Unity, pár Zenimax és WB stúdió, és akik ezeket a motorokat használják erősen panaszkodnak, mert amíg a Metal nem igényel új motorstruktúrát, addig a DX12 igen. Tehát az az elmélet, hogy először tesztelem a Mantle vagy a Metal API-t és aztán majd onnan megyek szabványra csak a Mantle-lel működik. Nem azért mert a Metal rossz, hanem azért, mert túl sok az eltérés a DX12-höz képest. A Unity motorprogramozója ennek teljes előadásokat szentelt az előző évben, hogy portolta a motort Metalra, aktiválta és alázott a teljesítmény, aztán innen portolta DX12-re és még a DX11-hez képest felére esett a tempó. Nem helyrehozhatatlan csak az elmélet nem találkozott a gyakorlattal. Tipikusan egyébként azoknál a cégeknél van a baj, ahol a motor nagyon öreg, így a konzolokon sem használják az alacsonyabb szintű elérést, tehát rá sem voltak kényszerítve arra, hogy modern struktúrát tervezzenek.
Aztán még ott vannak a gyártói profilozó és debug eszközök, amelyek nagyon bugosak a DX12-re vonatkozóan. Ezek javítása nem kevés időt vesz igénybe, tehát a kódok ellenőrzése igen lassan halad. Jellemzően azok a cégek állnak jól, akik írtak maguknak DX12 profilozót, mint az Oxide, mert még az MS cuccával sem lehet igazán haladni. Valószínűleg sokat segít, hogy az AMD a saját fejlesztőcsomagjának a forráskódják nyilvánosságra hozza, hogy lehessen javítani a bugokat a fejlesztőcsomag biztosítója nélkül is.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Azért csökkentik, mert jóval többet tudnak belőle gyártani az új interposer miatt, így jóval több kerül a piacra is, így ugyanazt a mennyiséget gyorsabban kell eladni. Korábban mondtam, hogy a Fiji esetében problémát jelentett az, hogy külön-külön működött az összes komponens, míg összerakva a csomag már nem működött. Ennek az okát lényegében megkeresték és korrigálták, így most már nem kell eldobni egy csomó Fiji-t.
Lesz még a hónap vége felé egy másik, Fury-ra vonatkozó bejelentés is emellett.(#13481) Locutus: Mondj gyorsabb és olcsóbb VGA-t.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#13504
üzenetére
Igen, csak az előző verzióban nem volt még HBAO+, illetve Flex. Mivel ezek a kódok nem módosíthatók, így ahhoz, hogy ezeket beépítsd ki kell kapcsolni bizonyos leképező optimalizálásokat, amik akkor is inaktívak, ha a HBAO+-t vagy a Flexet nem aktiválod. Emiatt változott meg a teljesítmény. Most ezek helyére zsír új optimalizálásokat kell írni, amelyek kompatibilisek az újonnan beépített zárt middleware kódokkal. Nyilván egyébként az kérdés, hogy ilyeneket írnak-e, mert ez akár időigényes is lehet. Önmagában ez nem hiba, hanem annak a mellékterméke, hogy nem módosíthatók az újonnan beépített effektek kódjai, így a leképezőt kell hozzájuk szabni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#13518
üzenetére
Az optimalizált kódút nem jelenti azt, hogy minden architektúrán javít. Inkább az manapság a cél, hogy kihozz egy olyan sorrendet, amit a játékos megszokott. Ezeket a megjelenés előtt nem látod, mert nem mérnek alpha programokkal. Egyszerűen megkapod a végeredményt, és azt hiszed, hogy az jobb mindenben, mint amilyen volt. A valóságban nem az.
Amikor a változás patch-ekben áll be, akkor láthatod, hogy mennyit változik. Az eredeti optimalizálás valószínűleg nem feküdt annyira az AMD-nek, bár azóta a driverek is javultak, tehát valószínűleg ennek a kényszerű kikapcsolásával csak maximum 5%-ot nyertek. De ez lényegtelen már, mert az új effektek miatt ez az optimalizálás nem használható. Írni kell újat, vagy így kell hagyni a kódot.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#13521
üzenetére
Az NV-t biztosan nem érte váratlanul, hogy romlott a teljesítmény a Gameworks beépítésétől. Ők nem először látnak ilyet. Ez csak nektek új, mert még nem láttátok, hogy mit okoz a middleware beépítése. De persze módosítani bármikor lehet rajta, viszont sokkal egyszerűbb így hagyni és majd egy új meghajtóban lecserélni a HBAO+ shadert. Szinte egyik Gameworks játék sem a szállított kódot futtatja, mert az AMD biztosan lecseréli, és emiatt az NV-nek is le kell cserélnie egy optimalizáltabbra.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#13523
üzenetére
Senki nem mondta, hogy gond van.
Egyszerűen csak pár eredeti optimalizálás nem fog működni, ezért megváltozott némileg a teljesítmény és a sorrend. De cserébe kaptál egy új effektet. Fogd fel úgy, hogy most jött ki a játék és az eredeti kód eredményét nem is láttad. 
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#13549
Abu85
HÁZIGAZDA
gainwardgs
#13546
Abu85
HÁZIGAZDA
válasz
gainwardgs
#13546
üzenetére
PureHair=TressFX 3.0 egyedi art pipeline-nal. A Square Enix EIDOS csoportja használja. Sajnos a GPUOpen GitHUB oldalra nem lesz visszatöltve, de a TressFX 3.0-val bárki csinálhat hasonlót.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Finomszemcsés preempcióval gyakorlatilag garantált az aszinkron timewarp elkészülte. Az NV-féle rajzolási szintű preempció is jó, addig amíg 2 ms alatt van az üzemmódváltás. Ha valami beragad 2-nél több ms-ra, akkor a timewarp garantáltan lekési a szinkronablakot. Ezek eléggé nyíltan beszélt problémák a fejlesztők és az Oculus/Valve, illetve a gyártók által.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#13557
Abu85
HÁZIGAZDA
gainwardgs
#13556
Abu85
HÁZIGAZDA
válasz
gainwardgs
#13556
üzenetére
Csak azt tudom, hogy Xbox One-on hogyan csinálják. Ott az OIT-t ordered atomicsre építve használják és mutexszel zárolják a wavefrontokat. Ennek az előnye, hogy memóriakímélő és gyors. Ezzel a módszerrel az OIT az Xbox One-on 1 ms-os feladat. A gond az, hogy a PC-be ezt csak GCN-re lehet átmenteni jó eredménnyel, mert nem minden hardver tudja a feldolgozási sorrendet. Láthatod a Lichdom Battlemage című játékban (patch előtt), hogy a mutex zárolás más hardveren is lefut, de az eredmény hibás lehet. A másik megoldás a PPLL adatstruktúra használata, amely megoldja a problémát minden hardveren jó eredménnyel, de 3-4 ms-ba kerül, tehát sokkal lassabb, mint a mutexes megoldás. A harmadik opció az OIT kikapcsolása, de akkor olyan ronda lesz mint a HairWorks.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A ritka drop nem számít. Nem kellemes, de viszonylag könnyen túléli az agy. A problémát az jelenti, ha folyamatosan lecsúszik a timewarp a szinkronablakról. Itt van egy olyan jelenség, hogy az aktuális grafikus API-kon belül nincs frame megszakítás. A megkezdett munkát be kell fejezni, még akkor is, ha már tudjuk, hogy a szinkronablakról lecsúszott. Ez akár még 3-5 ms-nyi extra számítást is jelenthet, de ugye már mindegy. Viszont a hardver innentől folyamatos hátrányba kerül, mert a még futó, de már felesleges számítás miatt késik az új, de fontos számítás.
Erre lesz egy megoldás idén, de csak a Mantle-be. Ez az instant killnek gúnyolt képesség, ami tulajdonképpen a szinkronablak lekésése után azonnal megöl minden késői timewarp-hez tartozó számítást.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nyilván, ha nem számít a pénz, akkor megveszed a Falcon Northwest Tiki-t és le van tudva. Vagy DIY alapon veszel egy Dual Fiji kártyát. Ezzel biztosan nem lesz gond, mert erre lett tervezve. Csak ennyiért autót is vehetsz majd.
Nem akkora gond a timewarp. Bőven megéri használni, mert biztonságos, hogy ha megkétszerezed a valós frame-számítás szinkronablakát.
Az AMD ma még nem alkalmaz semmilyen képminőséget csökkentő módszert a saját SDK-jában. Az NV alkalmaz egy multi-res shading eljárást, ami a kép szélét csökkentett minőségben számolja. Ezt a fejlesztő aktiválhatja, vagy letilthatja attól függően, hogy mennyire van a programja a "hányáshatáron".
A multi-res shading célja egyébként pont a timewarp szabadabb alkalmazása. Kevesebb számítással csökken a késés esélye.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#45185024
#13563
üzenetére
90 Hz-es a Rift, de mindegy. Viszont a timewarp miatt nem kell 90 sztereó 3D képkocka. Elég 45 és a másik 45 pedig lehet timewarp. Persze ez csak az elmélet. A valóságban kelleni fog a magas frissítés, mert ideális szinkron a gyakorlatban nincs, így a timewarp is a késleltetés csökkentésére megy rá. Legalábbis ez az eredeti célja, de annyira általános a megoldás, hogy többféleképpen lehet használni. Bár az a módszer, amiről írtam most nem ajánlott.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Maga a timewarp eléggé általános megoldás, tehát többféle felhasználási módja van. Most, ha csak arról beszélünk, hogy mi az ideális, akkor nyilván egyértelműen az, ha minden kész nyers képkockát timewarpolunk. De ezt elsődlegesen azért tesszük, mert az aktuális szabványos grafikus API-k csak a jelenet kamerapozícióját fogadják el. Alternatíva a LiquidVR LDL funkciója, amely képes a jelenet kamerapozícióját megváltoztatni a képszámítás előtt. Ilyen módon úgy is kaphatsz felezett késleltetést, hogy nem timewarpolsz.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A mi cikkünk nem a specifikációból származik, hanem a gyártói leírásokból, amelyek részben tartalmazták a specifikációt, de részletezve van, hogy az EMI, a tokozás, illetve az árnyékolás miatt, valamint a dupla órajel fogyasztásnövelő hatása miatt miket kell módosítani. Ez sajnos nem egyszerű. Csak akkor kell kevés módosítás, ha a GDDR5X GDDR5 módban működik, de ekkor nincs magas órajel. Viszont nem gond az EMI.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem szar csak van sokkal jobb.
Előrelépést a HBM hoz. A GDDR5X egy kényszermegoldás, mert az implementálása nagyon nehéz. Az EMI régóta probléma ezeknél a magas effektív órajelű rendszereknél. 6 GHz az, ameddig úgy relatíve egyszerű leárnyékolni a VGA-t. Efölött már egyre nagyobb probléma az EMI. 7-8 GHz még talán megoldható, de például a 14 GHz-es GDDR5X+FPGA tesztszett 256 bites busszal 37 cm-es. Egyszerűen nagyon hosszú NYÁK-ot kell tervezni, hogy az EMI ne jelentsen gondot.
A másik gond a fogyasztás, bár az csak hűtés kérdése. Ugyanakkor a 14 GHz-es effektív órajelen 3,5-5 watt egy ilyen lapka kapacitástól függően. Szimpla GDDR5 módban fogyaszt kevesebbet, de akkor 8 GHz a max órajel.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Valójában HBM2 nincs. A HBM az egyetlen specifikált szabvány, csak a magasabb órajel miatt HBM2-nek hívják, de szabvány szinten csak egy HBM update. A két rendszer, amit mi külsőleg számmal megkülönböztetünk, valójában ugyanabba a JESD235 specifikációba van besorolva. Tehát pontosan ugyanaz a technológia.
Akkor beszélünk külön technológiáról, ha más besorolást kap. Például GDDR5 (JESD212), illetve GDDR5X (JESD232).Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Akkor kezdjük az elején, ******** Egyrészt több tűt használ, tehát bonyolultabb lesz a routing, amivel bonyolultabb lesz a NYÁK. A magasabb effektív órajel miatt az EMI nagyobb gond, tehát a NYÁK-ot ez még tovább bonyolítja. Meg kell oldani, hogy ez ne zavarja a többi komponens működését, ezen belül is a NYÁK-ot érdemes nagyon sok rétegőre tervezni. Ezek nem kisebb módosítások, hanem komplett áttervezés és leárnyékolás. Egyedül akkor nem szükséges ez, ha eldöntöd, hogy GDDR5 módban működteted a GDDR5X-et.
Az interposer nem könnyű, de egyszerűbb vele bánni, mint az EMI-vel.A híreknél mindenkinek joga van benyalni a Micron marketingjét. Az viszont fontos tényező, hogy az AMD és az NVIDIA is a HBM felé tart, mert tisztában vannak a GDDR5X problémáival. A Hynix és a Samsung is erre épít.
[ Módosította: Racecam ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Most nem azért, de mi másban lehet hinni most? Azért Joe Marci már 8 éve felvázolta, hogy a hagyományos elvek szerint épített memóriarendszerek nem skálázhatók addig, ameddig erre szükség lenne. Ergo a fogyasztásuk egy idő után olyan szintre emelkedik, amivel az erre épített termékkategóriában az új generáció nem gyorsulni, hanem lassulni fog. Elég megnézni a GDDR fejlődését, ahol a dupla teljesítmény azonos buszon mindig kétszeresnél nagyobb fogyasztástöbblettel járt. Az persze világos, hogy a JEDEC feje 8 éve még nem tudta, hogy mi lesz a megmentő, de ettől függetlenül az előrejelzése pontról-pontra bejött. Persze őt ezért fizetik.
Ma HBM-en kívül semmilyen más működő alternatíva nem létezik a Marci által 8 éve felvázolt problémára, így baromira nehéz kétségbe vonni a HBM jövőjét.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#13602
üzenetére
A HBM még drága, így bizonyos termékeknél a GDDR5 jobb. A GDDR5X már kérdéses. Ezt nem biztos, hogy sok VGA-n beveti az AMD. Az előny, hogy olcsó maga a memória, de ha nem GDDR5 módban működik, akkor ez a NYÁK költségeinél hátrányos lesz.
Idén a HBM csak a felsőházban kap szerepet. Jövőre fog lejutni a középkategóriába. De itt a középkategóriát majd át kell értelmezni, mert az AMD-nél a termékskála az egyre gyorsabb dGPU-ról, a "leglassabb dGPU->IGP->egy gyorsabb dGPU->egy brutál IGP->és egy még gyorsabb dGPU" termékskálára vált át. Már az IGP is HBM-et kap.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#13605
üzenetére
Számolj utána. Ha mondjuk szükséged van 512 GB/s-os tempóra, akkor az GDDR5X-szel ~80 wattból hozható, míg HBM-mel ~15 wattból. Azért ez nem mindegy.
A HBM-mel szerencsére nincs probléma, hiszen a JESD235a nem kapott működésre vonatkozó módosítást. A Hynix az elmúlt fél évben végig a Fiji-t vizsgálta és leadta a tapasztalatokat, amelyek alapján a JEDEC konstatálta, hogy a HBM hibátlanul működik a gyakorlatban is, tehát az alap specifikációt érintetlenül lehet hagyni, sőt, még kiegészítésre sem szorultak.Az NV-nek is ugyanaz lesz a HBM bevezetésének a modellje. Az teljesen normális, hogy első körben egy gyártó egy terméknél többre nem vállalja be, mert ha az nem sikerült, akkor csak egy terméket kell törölni, vagy jobb esetben részpiacokra korlátozni.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#13611
üzenetére
Attól rárakják, csak a VGA ára lesz magas, de megéri a teljesítmény miatt.
Nyilván az AMD ezért tervezi már azt, hogy nem csak egyetlen egy új generációs lapkára használnak majd HBM-et.
A következő körben még a sima GDDR5 lesz a leginkább használva. Egyelőre egyik cégnél sincs GDDR5X-et használó termék teszten.Az Xbox One-on a D3D12-n fut. A volumetrikus fényt, illetve a TressFX szimulációt aszinkron compute-ban számolja és ehhez kellett az Xbox One frissítés, ami tartalmazza a D3D12-t, mert az eredeti Xbox One API-ban ez nem lehetséges. Emellett az OIT-re ordered atomics-et használ. Ez mondjuk PC-n eleve nem lehetséges szabványosan.
A miértekre tudni kellene, hogy mennyire fut az Xbox One kód az összes D3D12 implementáción. Lehet, hogy nem igazán.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Milka 78
#13628
üzenetére
De a csúcskártyához már kötelező a HBM. Túl sokat fogyasztana a GDDR5X, hogy azzal reálisan hozható legyen egy 12-14 TFLOPS-hoz szükséges 700-900 GB/s-os sávszélesség. Nincs meg rá a fogyasztási keret. Emiatt nem lesz kiadva egyetlen csúcskártya sem hagyományos konfigurációval.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#13633
Abu85
HÁZIGAZDA
Malibutomi
#13632
Abu85
HÁZIGAZDA
válasz
Malibutomi
#13632
üzenetére
A Fiji. Az eléggé sávszéllimites bizonyos motorokban.
Ha nem kellene nekik ekkora sávszél, akkor nem raknának rájuk HBM-et.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#13642
Abu85
HÁZIGAZDA
Malibutomi
#13635
Abu85
HÁZIGAZDA
válasz
Malibutomi
#13635
üzenetére
Nem valamiért, egészen pontosan azért, mert egyszerre 10 wavefront futhat. Minél nagyobb lesz egy hardver, annál fontosabb, hogy a skálázás érdekében egyszerre több wavefront fusson, hogy ha ezeknek nincs elérhető adat, akkor legyen elég tartalék wavefront, ami beugorhat a helyére. A GCN-t az AMD legalább öt generációra tervezte, annak érdekében, hogy a konzolpiacra vonatkozó győzelmet ki tudják használni a PC-n, tehát már az elején úgy kellett tervezniük a hardvert, hogy az elskálázódjon 40 TFLOPS-ig anélkül, hogy a CU főbb jellemzőit megváltoztatnák.
Az NV például már a Maxwellt sem viszi tovább, mert elérte a limitet, amit beleterveztek, így a következő körben meg kell változtatni az ütemezést és a kihasználtságra vonatkozó jellemzőket. Ez több párhuzamosan futó WARP-ot jelent.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#13637
üzenetére
Az AotS nem igazán sávszéllimites. Majd akkor lesz az, amikor hozzáadják a compute megvilágítást. De ez egyelőre még nincs beépítve, mert az első implementáció OpenCL C-ben lett írva, így csak Vulkan API-n fut.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
válasz
daveoff
#13701
üzenetére
Nem tapad rá a trutyi, ha nagyon le akarjuk egyszerűsíteni:
Így néz ki maxon: AMD - NVIDIA
Képzeld azt, hogy Lara sampont és kondicionálót használ, ahogy az első részben.![;]](//cdn.rios.hu/dl/s/v1.gif)
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ezt a TressF X3.0-PureHair dolgot fontos lenne megérteni, mielőtt megint farkast kiáltunk. A lényeg a TressFX 3.0 esetében, hogy az külsőleg egy middleware, tehát teljesen nyílt, így bele lehet túrni, de akkor is egy middleware. Ez annyival jobb, mint a zárt middleware, hogy egyénileg optimalizálható, így nem kell a működőséhez esetleg letiltani a leképező optimalizációit. Viszont az AMD TressFX 3.0-s kutatásaiban az Eidos Montreal, a Crystal Dynamics és a LABS részt vállalat és ők tisztában voltak végig, hogy mi változik. Ezért megcsinálták azt, hogy a TressFX 3.0-t a következő generációs játékoknál már nem nyílt middleware-ként, hanem mélyen a motorba integrálva fogják használni. Ez a PureHair.
Az ilyen felfogásnak nagyon sok előnye van. Ezeket az előnyöket ma még csak a Frostbite-nál láthatjuk a PC-piacon, de az vitathatatlan, hogy mindent mélyen integrálva sokkal jobb minőség és sebesség hozható ki, mert az egész rendszer egymáshoz van tervezve. Nem fogsz csak egy effekt miatt külön RT-ket létrehozni, mert az brutális pazarlás. Nyilván ez viszonylagos kérdés. Például egy Fallout 4-es Creation alap annyira le van maradva technológiailag, hogy nem különösebben számít, hogy hat RT-t használ, amelyből hármat csak egy middleware effekt visz el, és ha az ki van kapcsolva, akkor is ki lesz számolva az a hat RT, de akkor csak megtörténik a számolás és ennyi, eredménye nem lesz. Természetesen forrnának a fórumok, ha kiderülne, hogy a Fallout 4 grafika jól integrált effektekkel 70-80%-kal gyorsabban megoldható mindenen, de a user nem tudja, és amúgy sem nagy a játék gépigénye.
A GPUOpen egyik célja pont az, hogy az effekteket nem tudják készre, mély integrálásra előkészítve odaadni mindenkinek, mert annyiféle motor van, hogy ez lehetetlen, de a fejlesztők a nyílt forráskód miatt el tudják végezni a munkát maguk, és a PureHair egy példa erre a lehetőségre, amely a TressFX 3.0-ból készült. Ez borzasztóan fontos egy olyan világban, ahol az EA-nek van egy Frostbite-ja, és majdnem annyi R&D-ből tartja fent azt az egy motort, amennyiből 5 top AAA stúdió megélne, ráadásul stratégiai megfontolásból nem licencelik. Egyszerűen megtehetik, hogy iszonyatos mennyiségű pénzt beletolnak, és mindent megoldanak maguk. Az olló pedig a nemhogy szűkül a többi motorhoz képest, hanem egyenesen jobban kinyílik. Ilyen felfogással még az Oxide, a Rebellion, a Firaxis és Crytek rendelkezik, mert ők megértik a problémát, de például a Crytek ebbe nemrég majdnem belerokkantak, tehát amellett, hogy piszkosul dicsérendő az, ahogy a CryEngine-t fejlesztik, egyszerűen nincs a hátuk mögött egy EA kaliberű cég, akik beletolnál a dollármilliókat. És tulajdonképpen a Frostbite a CryEngine-höz képest csak itt van előnyben, de ez egy elég nagy előny. És itt jön az a pont, hogy a piac nagy része már meg sem próbálja követni az EA-t ebben. Egyszerűen olyan mértékű strukturális átalakítást igényelne egy EA-hez hasonló fejlesztési politika, hogy borzalmasan nehéz meggyőzni a kiadók vezérkarát arról, hogy technikailag ez megéri. Még ha el is jut a pénzemberek agyáig, hogy ezzel a modellel mennyivel többre lennének képesek, akkor is ott van az az R&D, amit az effektfejlesztésre kell költeni. Ezt a terhet próbálja levenni a GPUOpen. A PureHair ilyen módszerrel anélkül volt megvalósítható, hogy abba a Square Enix beletolt volna egy rakás pénzt. Emiatt lett kivíve a GPUOpen a GitHUB-ra, hogy fejlesztők a többi fejlesztővel is megoszthassák a tudást. A legtöbben nem látnak a színfalak mögé, de amellett, hogy külsőre mindent faszának acceptálnak a stúdiók, azért látják, hogy a Frostbite ilyet tud ([link] , [link]) kurva jó sebességgel. Ez ellen önerőből már képtelenség versenyezni, tehát vagy megosztja a piac a tudást, vagy leszarja a sebességet és a minőséget, így jöhetnek a middleware-ek. A piacra egyébként hosszú távon káros az, hogy az EA az anyagi fölényét, és a jól elvégzett strukturális átalakítás előnyét kihasználva évről-évre távolabb kerül a többiektől. Ennek a lekövetésére maximum egy-két kiadó lenne képes, de ott is ordítják a nemet a pénzemberek, amint látják, hogy ez milyen költségekkel járna. Valamiféle összefogásra mindenképpen szükség van. Az is probléma egyébként, hogy az iparág legjobb szakemberei az EA-nél és a Sony-nál dolgoznak. Őket el kellene kezdeni visszacsábítani a többieknek. Lehet, hogy a fizetési igényeik magasak egy kiadó vezérkara nézőpontjából, de az EA elsődlegesen azért van ott ahol, mert megadta például Johan Anderssonnak azt, amit kér, így őt nem tudta elcsábítani a Sony vagy például az AMD. És utóbbi is probléma, mert az AMD is olyan embereket visz ki erről a piacról, mint Gareth Thomas vagy Timothy Lottes. De például a Sony is Michal Drobottal, illetve Bart Wronskival erősített. Őket nem szabadna a PC-s kiadóknak elengedni.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Megint pár NV tulaj futott bele AMD driver hibába.
Srácok kár erőlködni addig, amíg a tesztekben nincs baj. Márpedig ott nem írnak ezekről a híres, NV tulajokat érintő AMD driverhibákról.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
schwartz
#13812
üzenetére
Tehát egy zárt middleware-kkel teletömött játék nem ment day-1. Hát ez sokkoló.
A viccet félretéve nyilván az NV-nek nem kevésbbé kellemetlen, hogy egy támogatott játék rosszul fut, de mit tudnának csinálni? Ha egyszer megengedik, hogy a fejlesztő módosítsa a kódokat, akkor onnantól mindenki azt fogja kérni.
Azért az nem volt véletlen, hogy az NV 8 éve még a dokumentálás és a nyílt fejlesztés élharcosa volt. Így lehet eredményeket elérni. Csak a mai világban többet ér a hype, mint a minőség, és egy cégnek ez egy mérlegelendő tényező. Lehet érte haragudni rájuk, de pont leszarják.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#13816
üzenetére
Amely stúdió egyébként egyáltalán nem béna, és ők csak segítették a portolast. De amúgy mindegy, hogy ki csinálja. Megjön a middleware csomag, azt be kell fordítani, és tesztelés utan le kell tiltani a nem kompatibilis optimalizálást, illetve létre kell hozni az effektekhez szükséges puffereket. Akárki csinálja ezt, ugyanarra kényszerül. Gondolom a fejlesztők az átlagnál magasabb logikai készség miatt nem hisznek az olyan technikákban, mint a ráolvasás, vagy az ima a gyorsabb kódért, más alternatíva pedig nincs a licenc megszegése nélkül.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#13818
üzenetére
Gyenge hasonlat volt, de ha felhoztad, akkor gondolj arra, hogy az evőeszközök gyártói nem csak kést, hanem villát és kanalat is kínálnak, mert nem szerencsés késsel levest enni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#13962
üzenetére
Az gyakorlatilag azt jelenti, hogy a PC-n még többet gyorsulna, mert az Xbox One-on a magas szintű elérés is nagyon hatékonyan skálázódik köszönhetően annak, hogy az API-ba van építve a kernel driver.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#13979
üzenetére
Akkor szarna be a PC-s világ, ha tudná, hogy Xbox One-on high textúrákkal a memóriahasználat 400 MB. Szerencsére nem tudják, így nem fogják fel, hogy mekkora pazarlás az a streaming modell, amit a PC használ. Bár ha Repi tényleg beváltja, hogy idén már csak WDDM 2.0-ra dolgozik, akkor lehet, hogy leesik a tantusz sokaknál.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Friss DX12 lista redmondból:
Ark: Survival Evolved
Arma 3
Ashes of the Singularity
Caffeine
DayZ
Descent: Underground
Deus Ex: Mankind Divided
F1 2015
Fable Legends
Gears of War: Ultimate Edition
Hitman
Just Cause 3
King of Wushu
Squad
Star Citizen
Survarium
The Elder Scrolls Online
The Isle
Umbra
Warhammer: End Times Vermintide
W.N.C: Infantry
...many more TBA[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#14019
üzenetére
Az Antigua lapka csak azon van rajta, meg a 380X-en de ott több shaderrel. Az Antigua egyébként egy új Tonga stepping.
Az a kérdés, hogy miért merül fel egyáltalán a Kepler, amikor egy éve nem frissítették hozzá a shader fordítót. Nem rossz az architektúra, de ha nincsenek hozzá optimalizálások, akkor túl nagy lesz a regiszterallokáció, és ez baj egy regiszterszegény dizájnnál. Hiába lehetne hatékonyabb a shader fordítás rá, ha nem kapja meg az ehhez szükséges fordítóoptimalizálásokat. Ráadásul a shaderek is csak a Maxwellre vannak már kicserélve a játékokba. A Kepler ezeket a Maxwellre szabott shadereket futtatja.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#14023
Abu85
HÁZIGAZDA
FragMaster
#14021
Abu85
HÁZIGAZDA
válasz
FragMaster
#14021
üzenetére
Igazából a GTX 680-nál legalább 10-20%-kal gyorsabb a 380 vagy egy 960 az újabb játékokban. A GFLOPS-ok és a GB/s-ok akkor számítanak, ha a meghajtó is engedi ezek elérését. Manapság sajnos nincs rá különösebb indoka az NV-nek, hogy Kepler optimalizált fordítót és shadereket rakjon a driverbe. Emiatt hiába van sok GFLOPS és GB/s a hardverben, azok jó része nem elérhető, mert a Maxwell nem igényel olyan specifikus optimalizálást, mint a Kepler. Simán lehetne olyan drivert írni, amely megdobja a GTX 680 teljesítményét az újabb játékokban úgy 10-15%-kal, csak az NV-nek ez már nem érdeke.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#14038
Abu85
HÁZIGAZDA
#Morcosmedve
#14027
Abu85
HÁZIGAZDA
válasz
#Morcosmedve
#14027
üzenetére
Pedig inkább a 960 és a 380 között gondolkodj. Lehet, hogy nem tetszik a 128 bit, vagy a kevés shader, ésatöbbi, de valójában nem ez számít. Sokkal többet ér, hogy az NV a Maxwellel még törődik, és emiatt a 680-nál simán jobb a 960 is az agyonherélés ellenére is. Sőt, a különbség idővel nőni fog a 960 javára.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
solfilo
#14040
üzenetére
Ez azért van, mert az AMD meghajtója takarékosabban bánik a videomemóriával. WDDM felhatalmazás nélkül töröl sokszor, ami nem szabályos művelet, de az AMD másfél éve dolgozik a szabályok megkerülésén, aminek ez az eredménye. A GeForce driver inkább pazarló menedzsmentet alkalmaz, vagyis ugyanazt az adatot egyszerre többször is elhelyezi a memóriába. Ez felfogásbeli különbség. Az NV is megtehetné azt, hogy ráállít egy technikai csoportot arra, hogy találják ki miképpen lehetne takarékosabban bánni a VRAM-mal, de különösebben nem érdekli őket ez a lehetőség. Inkább kínálnak hardvereket több VRAM-mal.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#14048
üzenetére
Mond meg nekik, hogy teszteljék újra a 16.1.1-gyel, mert az már lecserélte a problémás shadereket.
Egyébként nem tudom, hogy mit nem lehet ezen érteni. A WDDM 1.x alatt a VRAM kihasználása rendkívül rossz hatásfokú. A kernel driver felel a menedzsmentért. Az AMD nagyjából másfél éve kutatja azt, hogy miképpen lehetne a WDDM-et megkerülve törölni a memóriából az "ezer éve" nem használt allokációkat. Az első erre vonatkozó implementációt az Omega driver tartalmazta. Azóta ez sokat fejlődött, így ugyanannyi memóriával sokkal takarékosabban bánik az AMD. Ebben az is benne van, hogy az NV a Crossbar miatt meg pont az ellentétét csinálja ennek, vagyis ugyanazt az adatot több helyre is elhelyezi. Ez felfogásbeli különbség, de a WDDM 2.0-val nem lesz jelentősége.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#14051
üzenetére
Nem a memóriától függ a shader, hanem attól, hogy milyen a vektor load/store. Valójában egyik mai VGA-nak sem jó a Rise of the Tomb Raider által használt 16 bájtos elérés. Ez az Xbox 360-nak és a 64 bites busszal rendelkező kártyáknak ideális. Minden VGA, amely nagyobb memóriabuszt használ alternatív shadert igényel. Minél nagyobb a memóriabusz szélessége, annál nagyobb gond a 16 bájtos elérés.
Arra ezért kevesen gondolhattak az AMD-nél és gyakorlatilag másnál, hogy 2016-ban egy PC port az Xbox 360 verzióból készül, miközben van Xbox One változat.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#14053
üzenetére
Mert rossz a textúra streaming. Az Xbox One verzió memóriahasználata a high textúrákra fél gigabájt alatti, heted akkora, mint a PC-n. Ez szimplán egy programozással kapcsolatos probléma. Az Xbox 360 verzió streamingje van PC-be átmentve, és az marhára nem hatékony. Az Xbox One verziót kellett volna PC-re portolni nem az Xbox 360-ast. De erről most nem igazán tehet senki. Az Nixxes baromira leterhelt már így is. Három játékot párhuzamosan portolni egy kis létszámú csoport nem tud. Tartani kellett volna az eredeti tervez, vagyis azt, hogy a Crytal Dynamics elintézi a PC-s portot is.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#14055
üzenetére
Gyerekek mikor értitek már meg, hogy ha a konzolon a memóriaigény a PC-s tizede, akkor nem a PC-s hardverekkel van baj. A memóriakapacitás hajkurászása egy szoftveres probléma eredménye. Kurvára nincs szükséged 8 GB-os VRAM-ra a mai grafikai színvonalhoz. Amiért rárakják a kártyákra az az, hogy a fejlesztő a WDDM 1.x alatt képtelenek törölni egy rég nem használt allokációt úgy, hogy közben a program ne akadjon be. A helyzet az, hogy ha megnézik a gyártók a memória hozzáféréseket, akkor a betöltött adat 90%-a csak ott van, de jó eséllyel hozzáférés egy jelenet elhagyásával nem történik feléjük. Ami baj, hogy még mindig ehhez a 18 éve létrehozott modellhez igazodik a szoftver. 18 éve ez jó volt, de ma nem az, ma már a hardver sem így működik a driver alatt.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#14057
üzenetére
Nincs szükség rá. Csak toljuk magunk előtt azokat a problémákat, amelytől a PC döglődik. Eközben simán portolható az Xbox One-ról az alkalmazás, mert ott a Windows 10-en a WDDM 2.0.
Orbitális baromság, hogy neked kell egy 300K-s VGA ereje. Ehhez a grafikai színvonalhoz nem kell. Viszont baromira jó üzlet lehúzni a júzert egy rakás pénzzel, és működik, mert ha most elolvasod a saját hsz-ed, akkor fel sem merül benned, hogy ez a program sokkal kisebb erőforrásigénnyel is működőképes lenne, ha nem Xbox 360-ról portoltál volna. Mivel alapvetően a gondolkodni nem tudó felhasználók generációjába csöppenünk bele, egyre több ilyen mesterséges vásárláskényszerítés lesz bevetve. És ez mindaddig működni fog, amíg te vagy más nem teszi fel azt a kérdést, hogy miért kell ennek ennyire drága hardver.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#14066
üzenetére
Minden új driver tartalmaz hibajavítást. Ez teljesen általános. A Hotfix mindkét cégnél egy olyan jelző, amely arra vonatkozóik, hogy az adott driver alapja WHQL volt, és azt módosították. A Hotfix emiatt azt jelenti, hogy bizonyos modulok még tartalmazhatnak WHQL aláírást, mert nem biztos, hogy módosultak.
A névvel ellentétben a Hotfix-en belül a fixnek semmi köze ahhoz, hogy ez valami javítás lenne, mert minden meghajtó azért jön, hogy valamit javítson.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
imi123
#14073
üzenetére
A Nixxes esetében ez teljesen érthető. Nekik a 2016-ra az új Hitman és az új Deus Ex a fő projekt. Ezek DX12-vel jönnek. Viszont hirtelen felvenni egy harmadik projektet nem túl könnyű, főleg ha nincs elég embered rá. Korábban is írtam, hogy mindenkinek van egy minimális alvásigénye, és akkor sem tudnak többet dolgozni, ha a kiadó nagyon erőlteti. Ennek az áldozata lett a Rise of the Tomb Raider. Nyilván nem a Nixxes felejtett el portolni, egyszerűen csak a körülmények nem voltak megfelelők egy minőségi PC-s portra. A Nixxes a PC-s RotTR portot nem is jegyzi a projektjei között.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Valdez
#14080
üzenetére
A Nixxes számára az Xbox 360-ról való portolás volt az egyszerűbb, mert arra vannak eszközeik, és eleve ők csinálták az Xbox 360 verziót, tehát ismerik is. Az Xbox One port a Crytal Dynamics számára lett volna egyszerűbb. A Nixxesnek arra nem voltak eszközei, illetve nem is hiszem, hogy ők azzal a kóddal közelebbi viszonyba kerültek volna a játék fejlesztése alatt.
(#14082) Balazs_: Biztosan nem. Párhuzamos projekteknél a csapat fel van osztva. Maximum egy-két ember esett ki az új Tomb Raider miatt.
(#14079) Szaby59: [link] - itt keresd meg.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#14084
üzenetére
Biztos csak elhanyagolták. Tuti nagyon büszkék erre a portra.
A helyzet az, hogy a projekt oldalon minden portjuk ott van, csak a PC-s RotTR hiányzik.
Természetesen felelősek, de attól még nem muszáj kirakniuk. Nem hiszem, hogy büszkék rá, és így inkább be sem sorolják. Nekik ez rontaná az imázsukat.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Egyszerűen csak pár eredeti optimalizálás nem fog működni, ezért megváltozott némileg a teljesítmény és a sorrend. De cserébe kaptál egy új effektet. Fogd fel úgy, hogy most jött ki a játék és az eredeti kód eredményét nem is láttad. 
![;]](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.
- GIGABYTE RTX 3060TI GAMING OC 8G
- Asus TUF FA507 - 15.6" IPS 144Hz / Ryzen 7 6800H / 16Gb DDR5 4800MHz / RTX 3050 Ti / 1 ÉV GARANCIA
- NVIDIA Dell RTX 2080 Ti 11GB GDDR6 - Beszámítás: OK
- AKCIÓ, BOLTI ÁR ALATT! tado BASIC Okos Radiátor Termosztát 3db-os
- AKCIÓ, BOLTI ÁR ALATT! Xiaomi HUTT C6 ablaktisztító robot
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest