Új hozzászólás Aktív témák
-
#6388
Abu85
HÁZIGAZDA
Malibutomi
#6387
Abu85
HÁZIGAZDA
válasz
Malibutomi
#6387
üzenetére
Ja. Meg új shader fordító. Majd a Windows 10-zel lesz itt a teljes csomag a nyár folyamán. A bátrak a Windows 10 drivert felhackelhetik Windows 8.1-re.
-
Abu85
HÁZIGAZDA
válasz
tom_tol
#6373
üzenetére
Professzionális területen. Az AMD pár negyedéve folyamatosan rekordbevételt ér el a HPC és a munkaállomás piacáról. Nyilván ehhez hozzájárul az, hogy a GCN létezik, és több területen nincs rá alternatíva. Ha te olyan gépet akarsz, ami DP-ben a csúcs, akkor FirePro S9150-et kell venned. Nyilván az is segít ezen, hogy több szabványos rackbe egy Tesla K80-at be sem lehet építeni, mert jóval többet fogyaszt és a rack hűtése miatt a teljesítménye 30%-kal esik.
A Xeon Phi az nem téma manapság. Azért volt felkapott, mert az Intel azt mondta, hogy a meglévő OpenMP kódokat újra lehet fordítani és futnak. Na most ezt elfelejtették azzal kiegészíteni, hogy így viszont nem lesz gyorsulás.
A HPC piacon az NV a Maxwellt érthető okokból nem vezette be, így a Kepler a GCN ellenfele még mindig. -
-
Abu85
HÁZIGAZDA
A FirePro S9150 eléggé nagy siker. Többek között ez a rendszer van a világ leghatékonyabb szuperszámítógépében. Ez az L-CSC, ami 5,27 GFLOPS/wattot tud. A hozzá legközelebbi, hasonló fogyasztási karakterisztikával (~50 kW) rendelkező GPGPU-s szuperszámítógép 3,63 GFLOPS/wattra képes, szóval az előnye a GCN-nek ezen a piacon elég nagy. Nem hiszem, hogy az USA szeretné, ha ez a technológia kínai kézbe kerülne.
(#6368) NetTom: A Tianhe-2 nem számít. Az Xeon Phit használ, pontosabban nem használ, mert csak be van építve. Tehát tud izmozni Kína, de valójában a gép 85%-a kihasználatlan.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#6362
üzenetére
Nem teljesen. Erre rákérdeztem és elvileg senki sem nyilatkozott így, legalábbis senki sem tud róla, de ezt majd kivizsgálják, mert a Northland máskor is írt már meg olyat, hogy xy nyilatkozott és közben nem is.
A Xilinxszel kapcsolatban nem mondtak semmit, de innen tudom, hogy az FPGA-kat rossz ötletnek tartják. Egyébként ez érthető. Minden cég az előrelépés lehetőségét nézi egy új irányzattal. Az Intelnek az FPGA előrelépés, mert minden GPGPU-s koncepciójuk működésképtelen. Az AMD-nek egy FPGA nem előrelépés, mert a GCN működőképes. Itt nem csak a teljesítmény/fogyasztást vizsgálják, hanem azt, hogy az FPGA-k programozására a legbarátságosabb lehetőség az OpenCL, míg egy GPGPU programozására ott a Java9 is, ami azért jóval magasabb szintű nyelv és a hatékonyság így is magas. -
Abu85
HÁZIGAZDA
válasz
Locutus
#6359
üzenetére
Nyilván Kína közeledését nem szívesen veszik. Azért ha ráteszik a kezüket a GCN-re, akkor az nagy baj, mert építhetik a szuperszámítógépeket, amikkel lealázzák az USA-t. Nyilván nagyobb az esélye annak, hogy megkérik az IBM-et, hogy adjanak jobb ajánlatot és akkor kiírnak nekik valami zsíros kormányzati tendert cserébe.
De az amcsik is tudják, hogy az AMD nagyon sok pénzt kér, mert nem cél az eladás, annyit pedig senki sem fog adni, mert ami kell az AMD-ből xy cégnek azt elérik a semi-custommel. Ez sem tetszik az amcsiknak, de ez ellen nem tudnak tenni.
A Xilinxnek nagyobb szüksége van az AMD-re, mint az AMD-nek a Xilinxre. Eleve az AMD az OpenCL-es FPGA-kat a szerverlapkákban rossz ötletnek tartja. Nyilván egy GCN-nel a zsebükben ezt nem nehéz így látni. -
Abu85
HÁZIGAZDA
válasz
Televan74
#6354
üzenetére
A Samsung is mindig ugyanarra jut. Nekik az AMD-ből a GCN és a Mantle kell. Ezeket pedig elérhetik jóval olcsóbban úgy, hogy rendelnek egy semi-custom lapkát a saját technológiájukkal összerakva. A Xilinxnek a Zen kell, ezt pedig szintén elérhetik semi-custom üzletágon keresztül. Megvizsgálható a felvásárlás, de a semi-custom lehetőségével nagyságrendekkel kisebb kockázat megrendelni a terméket, és az a nyereség oldalán ugyanazt fogja hozni az adott cégnek. Még a 3rd party IP is része a semi-custom üzletágnak, tehát semmi hátránya nincs összerakatni a lapkát, mint összerakni.
-
Abu85
HÁZIGAZDA
Nem a kínaiakkal van a baj, hanem, hogy mi értelme lenne nagy felárral vásárolni. A Samsung mindig megvizsgálja az AMD felvásárlásának lehetőségét, de mindig ugyanarra jutnak, hogy IP portfólió ide vagy oda, akkor is jelentős ráfizetéssel mehetne végbe a felvásárlás.
És itt jön elő az, hogy szükséges-e nagyjából 8-10 milliárd dollár kiadása, amikor az AMD teljes IP portfóliója elérhető a Semi-Custom üzletágon keresztül. Tehát ha bárki elgondolkodik ezen, akkor arra fog jutni, hogy ha szüksége van egy olyan lapkára, ami tartalmaz valamit az AMD IP portfóliójából, akkor egyszerűbb azt a Semi-Custom üzletágon keresztül megrendelni, mint egy kockázatos üzletbe belevágni. Nyilván a Xilinxnek erre szüksége van, így ők rendelni fognak. És ilyen formában nagyságrendekkel olcsóbb a buli. -
Abu85
HÁZIGAZDA
Az FP16-ot láttam. Azt nem tudom mennyire fogják használni, de bizonyos pufferek esetében felesleges FP32-ben dolgozni, mert nem hoz minőségelőnyt, viszont az FP16 eddig sok hardveren nem volt elérhető. Az Intel már megmutatta, hogy sokszor lényegesen előnyösebb az FP16, mert kétszeresére növeli az adott eljárásra levetített teljesítményt és csökkenti a fogyasztást.
A legnagyobb DX12-e fícsőrök egyébként nem ezek, hanem az async DMA/shader, a typed UAV loads, a resource heap lehetőségek, illetve ez a szép nevű:
VPAndRTArrayIndexFromAnyShaderFeedingRasterizerSupportedWithoutGSEmulation
-
Abu85
HÁZIGAZDA
Ezek közül minden csak a Mantle-ön érhető el. De a fontosabb dolgok ott vannak a DX12-ben és a Vulkan API-ban. Az FP16 biztosan. A stateless compute igazából egy automatikus hardveres fícsőr, ehhez nem kell külön támogatás. A fine-grained preemption egyelőre valóban nincs ott egyik szabvány API-ban sem, de a WDDM 2.0 fel van rá készítve, szóval bevethető. Sub-dword addressing és cross-lane ops az érkező OpenCL-en keresztül a Vulkan API-n át használható.
-
Abu85
HÁZIGAZDA
Ezt hogyan képzeled? Az NV odamegy az EA-hez és a Square Enix/Eidoshoz, hogy nekünk van xy% részesedésünk, és ezért használjatok GameWorksöt? Ez nem fog megtörténni, mert ezek a kiadók nem akarják lekorlátozni a kiadott játékaik grafikáját. Sokkal célszerűbb saját maguknak megírni a biztosan működő rendszereket.
(#6285) rocket: A Pascal elmondom miket vezet be: FP16, stateless compute, fine-grained preemption, sub-dword addressing, cross-lane ops. Mindegyik újítás már most! ott van a GCN3-ban (Tonga, Iceland, Wani, Fiji). API oldali támogatás is van rájuk.
-
Abu85
HÁZIGAZDA
válasz
Yllgrim
#6278
üzenetére
Nem arra írtam az 1000 eurót, csak úgy általánosan írtam le. De ha visszaolvasol a Radeon találgatós topikban, akkor írtam, hogy nem lesz olcsó.
(#6277) imi123: De mivel? Hogy megőrzi a PC-n az innovációt? Ennek örülni kellene. Jelenleg ezt az Intel és az AMD kutatásai képviselik.
(#6265) huskydog17: Ez nem olyan egyszerű. Az EA, Square Enix/EIDOS, a SEGA, a Capcom, még a Crytek is főleg azért partnere az AMD-nek, mert nekik vannak olyan hozzáértő mérnökeik, akik még egy nagy tudású programozónál is jobban megértik a GeForce hardverek működését. Egyszerűen csak azért, mert maguk is ilyen rendszereket terveznek. Nagyon fontos a PC-ben érdekelt cégeknek, hogy ha az NVIDIA nem mondja meg, hogy mit-hogyan-merre, akkor legalább valaki más tegye meg. Nyilván egy csomó cégnek teljesen jelentéktelen az a modell, amit az NV kínál a zárt middleware-ekkel. Ők kiszámíthatóságot akarnak, és azt csak saját kódokkal lehet elérni. Nagyrészt ennek köszönhető, hogy a downgrade-ek szempontjából az EA és a Square Enix jellemzően nem szokott hírbe kerülni. Képesek maguk irányítani a sorsukat.
Azért meg lehet nézni, mondjuk a Rebelliont. Ők totál független fejlesztők, nincsenek semmilyen kiadó pénzcsapján. Mégis olyan optimalizált játékokat tesznek le az asztalra, hogy azokat sok nagy kiadó is megirigyelné, és azt sem lehet mondani, hogy nem csinálnak semmi különöset, mert például az Asura az első olyan PC-s motor, amely obscurance fields effektet használ. Ez a saját fejlesztésű implementációjuk, és ez egy pici kis angol stúdió, és több grafikára vonatkozó technikai újítást raknak le, mint több nagyobb kiadó, nem beszélve a példás optimalizálásról. Azt akarom ezzel mondani, hogy nem a szaktudás hiányzik azokból a stúdiókból, akik rossz optimalizációval állnak elő. Egyszerűen sok esetben nincs is lehetőségük az optimalizálásra, mert egy vagy két vízfejű a vezetőségben, különböző értelmetlen szerződések megkötése után nem engedi meg, hogy a technikai csoport célirányosan dolgozzon, vagy esetleg nem adnak rá pénzt.
-
Abu85
HÁZIGAZDA
A GameWorks minden hardveren hátrány. Kérdezz meg bárkit, hogy a HairWorks vagy a TressFX minősége a jobb. Még számos NV tulajdonos is azt mondja, hogy a TressFX. Le is írtam egy cikkben, hogy mi hiányzik a GameWorksből, hogy elérjék a TressFX szintjét. Csak ezt nem lesz egyszerű megtenni, mert rengeteg erőforrást elpazarol az algoritmus, lényegében a semmire.
Amit nem értek, hogy ezen miért kell siránkozni? Igen a PC átalakul. A jövőben nem lesz olyan, hogy egy márkán belül mindent elérhetsz. Lesznek GeForce és Radeon exkluzív dolgok. Nem mondom, hogy ez jó, de ez van. Viszont a döntés a tietek, hogy milyen hardvert vásároltok a PC-be. Vagy akár az is, hogy mentek konzolra, teljesen mindegy. De azért siránkozni, hogy az AMD stratégiailag még mindig értékesebbnek tartja az optimalizált játékot, mint a mesterségesen magas gépigényt egyszerűen blődség. Ők ezt az utat választották és kész. Az NVIDIA az ellentétes irányt választotta, fogadjátok el azt is. Ott is ki lehet fizetni 1000 eurót évente az új csúcsért. De alapvetően egyetlen piaci szereplő sem kényszeríti rátok, hogy megvegyétek az új VGA-kat.
A kritizáló fejlesztőkkel mégis mit kezdjen az NVIDIA? Ők választottak, és nem kérnek a GameWorksből. Ennyi. Nekik sem kötelező elfogadni egy olyan szerződést, hogy nem optimalizálhatják a kiadásra váró játékot. Szép is lenne, ha ez kötelező lenne.
(#6275) rocket: Félreérted a fejlesztőket. Johan Anderssont nem érdekli, hogy a GameWorks létezik-e vagy sem. Magasról tesz rá, hogy az NVIDIA éves szinten mennyi pénzt éget el különböző fejlesztésekre, amiket nem lehet végül beépíteni sehova, mert ha megmozdul valami, akkor képi hiba van (lásd GI Works). Ez totál hidegen hagy mindenkit, aki ezt a csomagot kritizálja. Ami nem hagyja hidegen őket, hogy az NV nem dokumentálja a hardvereit, eléggé leépítették a fejlesztőeszközeiket, és nem kínálnak ISA disassemblert. Még ha akarnak sem tudnak jelen formában GeForce-ra optimalizálni. Nem mondja meg az NV, hogy miképp kell. Erről is írt már Matías N. Goldberg, hogy ez miért baj számára, meg azt is, hogy ez régen nem volt így az NV-nél. [link]
Itt alapvetően azt akarják a fejlesztők, hogy az NV ne legyen ilyen elzárkózó. Az, hogy a GameWorksöt nem nyitják meg őszintén szólva senkit sem érdekel, mert nem akarják használni, de az már érdekli őket, hogy amit írnak az mennyire optimalizáltan fut GeForce-on. Az az érdekük, hogy jó legyen, főleg a low-level irány mellett, ahol a fejlesztőkön elég sok múlik a kernel driver eltűnése következtében, és az NV a problémák esetén simán rájuk mutat, hogy ők a hülyék és nem a driver a probléma, mert driver már hagyományos értelemben nincs is.Sajnos a GCN és a Maxwell még mindig lényegesen gyorsabb Witcher 3-ban, mint a Kepler, Fermi, TeraScale 2, stb. Az R9 285 és a GTX 960 még mindig a GTX Titan szintjét képes hozni, mert annyit ezek is gyorsultak, amennyit a Kepler. Mondjuk ez nem baj, de ettől függetlenül nem történt felzárkózás.
-
Abu85
HÁZIGAZDA
Valószínűtlen, hogy az AMD egy akkora rage-et akar a felhasználóktól a fórumon látni, mint amit most az NV kap. Emellett tényleg meg kell érteni, hogy tök logikátlan húzás lenne az AMD-től zárt middleware-ekt fejleszteni. Van a PC-n egy vezető iparági igény arra, hogy szabaduljunk meg a feketedobozoktól. Elsődlegesen az API szintjén és ebben az AMD vezető szerepet vállalat. Kidolgozták a lehetőségeket, hogy hogyan lehetne ezt megtenni, és a Microsoft és a Khronos ezt kisebb nagyobb mértékben átemelte, illetve még átemeli szabványba. Az AMD a PC iránt tényleg érdeklődő nagy stúdióktól folyamatosan azt hallja nem akarnak feketedobozt, de akarnak ISA dokumentációt, használható fejlesztőeszközöket, esetleg ISA disassemblert. Az NVIDIA is tudja ezt, azért annyira még nem távolodtak el ezektől a stúdióktól, hogy Johan Andersson, Daniel Baker, Joshua Barczak, John Kloetzli, Kevin Floyer-Lea, Emil Persson, Tiago Sousa, Masaru Ijuin, stb, lényegében az iparág keménymagjának a véleményét ne ismerjék arról, hogy mennyire nem akarnak feketedobozokat, ettől függetlenül az feketedobozt elimináló igényeikre újjabb feketedobozzal válaszoltak. Twitteren erről olvashatsz is tényleges PC-s fejlesztőktől véleményt: [link] Van köztük Timothy Lottes és Bart Wronski, anno az NVIDIA/Epic Games és az Ubisoftnál dolgoztak. Timothy már az AMD-nél van, míg Brat elment a Sony-hoz. Az Ubisoft esetében például fontos, hogy a technikai csapat magja Michal Drobottal az élen az elmúlt év végén kilépett, és ebben nagy szerepe volt ahhoz, hogy nevüket adták olyan projektekhez, amelyeket valójában nem tudta optimalizálni a sok-sok feketedoboz miatt, illetve alapvetően olyan irányokra kényszerítette őket az Ubisoft, amiről már helyből tudták, hogy nem fog működni, de azt kellett csinálniuk, mert a "hozzáértő" szakemberek a vezetőségben azt mondták, hogy jó lesz. Az NVIDIA is azt mondta nekik. Annyira jó lett, hogy még a GeometryWorksöt sem tudták integrálni, mert képtelenek voltak működésre bírni az egészet, tehát, amire felépült a projekt, hogy majd rajzolási parancsokat spórolnak a tesszellálással teljesen tévút volt. Ezért néz ki az AC: Unityben sok felület sokkal rosszabbul, mint az AC: Black Flagben. Főleg a tetők. Úgy volt tervezve, hogy lesz tesszellálás, de nem működött a zárt middleware-en keresztül. Ezért éri meg a vezetőségnek a döntéseit a technikai csoport véleményére hagyatkozva meghozni, mert ők ismerik a motort, míg például egy külső cég nem. Aztán persze ígérni sok dolgot lehet, majd azok 90%-a a játék kiadásáig nem fog teljesülni. Ezért is volt az Ubisoftnál az elmúlt évben ez a sok downgrade botrány, mert hiába akarsz egy grafikai szintet, ha az zárt effekteket nem tudod működésre bírni. Egy dolog, hogy mit akarsz és mi valósítható meg. CD Projekt is ezzel küzdött. Elgondolták, hogy majd beimplementáljuk a middleware-eket, aztán, ahogy jöttek a middleware-ek sorban derült ki, hogy hát ez ezzel nem kompatibilis, akkor ezt jó lenne átírni a motorban, akkor ezt az effektet így bukjuk, stb. A végére elfogyott az idő, még a megjelenés csúszásával is, és jött a downgrade, mert hiába terveztek dolgokat feketedobozokkal valójában mindig nagyon nehéz dolgozni. Nem a fejlesztőn múlik, hogy valami megvalósítható-e. Ezért látod 2015-ben azt a vezető irányt, hogy egyre több middleware-t nyitnak meg. Annyira komplex lett az egész, hogy sok esetben másképp nem lehet biztosítani a működést, downgrade-et pedig senki sem akar.
Még, ha az AMD-nek ugyanaz meg is fordul a fejében, hogy valahogy mesterségesen érdemes lenne visszafogni az előző generációt, hogy az új jobbnak tűnjön, alapvetően az egyetlen lehetőség erre tényleg egy GameWorks-féle stratégia. De az a hátrány, amit ez ad a fejlesztőknek a sok beláthatatlan downgrade-del a megjelent játékokon, sokkal jobban árt a PC-nek hosszútávon, mint amekkora előnyt jelent az adott időszakban az eladásokban. A konzolok ilyen irány mellett előnybe kerülnek, mert hiába van bennük egy csúcs-PC-hez képest korlátozott teljesítmény, akkor is az előny, hogy amit elgondol a fejlesztő azt képes megcsinálni, míg feketedobozok mellett ez sok esetben nem sikerül. Mindegy, hogy hogyan kommunikálód le a downgrade-et, elmondod nekik, hogy használhatatlan zárt effekteket kaptál, vagy kitalálsz valami kíméletes hazugságot, maga a grafika leépítése megtörtént, és a PC-s játékos szomorú lesz.
És alapvetően az a gond, hogy nem a valós problémáról beszél az ipar. Mert a GameWorks esetében az, hogy xy hardveren rosszul fut, nem valós probléma, kapcsold ki és kész, vagy iktasd ki driverben a teljesítményzabáló részeit. Az a gond, hogy teljesen értelmetlen fejlesztési modellt kényszerít ki, és a végére rengeteg terv nem fog megvalósulni. Egyszerűen egy építésznek is baromira nehéz lesz a munkája, ha azt várják el tőle, hogy egy kész tető alá építsen egy házat. Kvázi ezt várja el a GameWorks a fejlesztőktől. És akkor csodálkozunk, hogy a megjelenés előtti bemutatókon a játék sokkal szebb volt, mint ami végül megjelent?
Ez a valódi problémája a feketedobozoknak. Minden formájuknak. Mindenki döntse el magában, hogy ez jó-e a PC-nek vagy sem.Nem tudom pontosan, hogy mik lesznek az extrák. Vagy több sebesség, vagy több effekt. Két dolgot tudok a fejlesztőktől, hogy a DX12-ből két számukra fontos dolog hiányzik, ami megvan a Mantle-ben. Az LDS tartalmának korlát nélküli olvasása, és a GDS korlát nélküli használata. Ezeket használni fogják konzolon, sőt, már használják is, így az erre épített effektek átmenthetők. Például az Ubisoft HRAA élsimítása az LDS korlát nélküli olvasására épül. Gyakorlatilag PC-re a konzolon alkalmazott AEAA konstrukcióval csak Mantle-re menthető át.
A DX12-ből négy vezető kihasználású funkció lesz, amelyet gyakorlatilag mindenki bevet. A Typed UAV loads, az aszinkron DMA, az aszinkron compute és a multiadapter valamilyen formája. Az első hármat azért alkalmazzák a fejlesztők, mert összességében konzolon 40-70%-os extra sebességet is hozhat, és a kód gyakorlatilag módosítás nélkül átmenthető PC-re, ahol ugyanennyi előnyt fog kínálni. A multiadapter PC-s dolog, de annyira egyszerű használni, hogy legalább az IGP+dGPU rendszerekre lesz valamilyen implementáció. Azok annyira elterjedtek a világban, hogy megéri velük foglalkozni.
A tesszelláció kapcsán ha megnézed a vezető irány a fixfunckiós blokk elhagyása. Ez hardverben megmarad, de például a LORE motor már compute shadert használ a háromszögek felbontására. Az eredmény az, hogy jobb lesz a minőség és gyorsul tőle a program. Több motor is átvált a jövőben szoftveres tesszellálásra, mert a fejlesztők jobb minőséget akarnak nagyobb sebességgel, és erre a fixfunkciós blokk korlátozottan alkalmas.
(#6258) Szaby59: Kettő, de nem a szám lényeges, hanem az, hogy megtörténik.
Többször mondtam, hogy a Dragon Age: Inquisition DX11 kódja nem stabil. Az EA support hivatalosan a Mantle kódot ajánlja. Ezért van beépítve. A DX11 kód sosem lesz teljesen stabil a mutex zárolásaival. Nagyon nem véletlen, hogy a Microsoft ezeket a technikákat nem ajánlja implementálni, függetlenül attól, hogy lehetséges. Sajnálom, de ez van. A következő körben már mindenki kap low-level támogatást.
(#6259) huskydog17: A Capcom a Panta Rhei motort fogja később használni mindenre. Ma még nem létezik PC-s portja, mert DX11-re kvázi portolhatatlan, de később meg lesz oldva.
-
#6257
Abu85
HÁZIGAZDA
Malibutomi
#6253
Abu85
HÁZIGAZDA
válasz
Malibutomi
#6253
üzenetére
Olvasd a GeForce fórumot, hogy milyen felháborodás van a GameWorksből. Abból, hogy a Radeonok egy szimpla driverbeállítással minőségvesztés nélkül nagyon gyorsan tudják futtatni a HairWorksöt, és abból, hogy a Kepler a TWIMTBP játékokban, miért van ennyire leszakadva a Maxwelltől. Ezt baromira el akarja kerülni az AMD, mert ez nem üzlet. Az NV-nek az, mert átállítja az embereket a felhőbe.
Kínálják majd a GRID-et előfizetéssel, és mehetsz oda játszani. Sőt, alapvetően vannak olyan GameWorks effektek fejlesztés alatt, amelyek nem is a kliensgépen futnak, hanem a felhő kiszámolja az aktuális részinformációkat, és visszaküldi az adatot a kliensgépnek, ami összerakja a képkockát az adatok alapján. Ez a jövőkép az AMD szerint nem jó, mert nagyon kevés hely van a világon megfelelő internetinfrastruktúra az effekteket a felhőben számoltatni.(#6255) wjbhbdux: A Frostbite a PC számára fontos, mert az EA akkora lépésekben halad előre, hogy a többieknek mérföldes lemaradásuk lesz sebességben és minőségben a Frostbite új verzióihoz képest. Csupán abból származik majd a Frostbite előnye, hogy az EA-nek van egy valag pénze kutatni, fenntartanak egy teljes stúdiót csak motorfejlesztésre, és mindent saját maguk írnak meg. Ezzel gyakorlatilag lekövetik azt a modellt, amit a Sony felvázolt még pár éve, hogy grafikai áttörés nagyrészt ebből lesz. Ezért kampányolt az EA elsőként a low-level irány mellett, mert szükségük van a nagy kontrollra a hardver felett, hogy kiépítsék az előnyöket. Valószínűleg nem sok kiadó lesz, aki képes majd követni őket. A Squate Enix EIDOS divízió már elindult utánuk, illetve a Capcom is, de az, hogy ők csak később fedezték fel a 100%-ban saját kód jelentőségét időhátrányt jelent az EA-vel szemben. Az Ubisoft még esélyes lenne erre, ha figyelmet fordítanának a PC-re, de annyira ezt a platformot nem tartják fontosnak.
-
#6251
Abu85
HÁZIGAZDA
huskydog17
#6247
Abu85
HÁZIGAZDA
válasz
huskydog17
#6247
üzenetére
Nézd az NV szabadon eldöntheti, hogy milyen optimalizáláshoz adják a nevüket. Korábban is láttuk, hogy nagyon rossz optimalizálással is jó az NV-nek egy játék. Tekintve, hogy sok szabad kapacitásuk van nem valószínű, hogy válogatnak a potenciális címek között.
rocket: Vannak az AMD-nek effektjei. Rengeteg. Radeon SDK a gyűjtőneve. Az valóban igaz, hogy ez nem zárt, hanem nyílt forráskódú. Ez azért van, mert a zárt forráskód sokszor megakadályozhatja az effekt beépítését. Nem véletlen az az irány 2015-ben, hogy nyitják meg sorra az eredetileg middleware-eket. Nagyon sok potenciális licencelőnél ez kritérium lett.
A másik dolog amiért az AMD nem csinál GameWorks alternatívát stratégiai jelleggel, mert nem tartják jó ötletnek az egy éve kiadott hardverek teljesítményét mesterségesen limitálni csak azért, hogy az új generáció jobbnak tűnjön. Ennek nem örülne a felhasználó.
Felsoroltam párat fentebb, hogy az AMD milyen játékokon dolgozik jelenleg. Több cím nem szerepel a doksikban. Annyit tudok még mondani, hogy némelyik játékban vannak olyan funkciók, amelyeket csak Radeonokkal érhetsz majd el. Elsődlegesen azért mert a Mantle-höz kötődnek.
-
Abu85
HÁZIGAZDA
Akkor elmondom az igazi okát. A cél az effekt sebességének meghatározása, és a fejlesztők lehetőségeinek a korlátozása. Az NV meg szeretné határozni a játék gépigényét és az új illetve az előző generáció közötti teljesítménykülönbség nagyságát.
Én PC-s portok minőségével törődő kiadót még nem látok mögötte. Nyilván a fejlesztők tudják, hogy ha licencelik, akkor letámadják a fórumokat a felhasználók, hogy a játék szarul van optimalizálva.
Egyébként nem kell ezt olyan szélsőségesen felfogni. Az NV az Ubisoft és a Warner igényeihez fejleszt, míg az AMD az EA, Square Enix, SEGA, Capcom igényeihez.
-
Abu85
HÁZIGAZDA
Szerinted mire szolgál egy zárt MiddleWare? Miben segíti a fejlesztők munkáját?
Fejtsd ki kérlek miért lenne jó azoknak a fejlesztőknek fekete dobozt adni, akik évek óta ezek megszüntetését követelik.Szerk.: Egyrészt még nincs eldöntve, hogy lesz-e limit és ha lesz, akkor mennyi. Másrészt az AMD-nek ezzel kötelessége foglalkozni, mert az EA hardverpartnerei. Azért kapják az EA-től a támogatást, hogy segítsenek optimalizálni a Frostbite-ot, és írjanak hozzá olyan funkciókat a Mantle-be, amit Johan akar, de szabványosan nincs rá megoldás. A partneri viszony kétirányú az EA és az AMD között.
-
#6245
Abu85
HÁZIGAZDA
huskydog17
#6243
Abu85
HÁZIGAZDA
válasz
huskydog17
#6243
üzenetére
Nem a Frostbite 3-at használja a játék. Az EA egy nagyon durva fejlesztési tempót diktál, amióta különvált a Frostbite Team és a DICE. Mostantól évente lép egy hagyott a Frostbite és nem két évente.
A Ghost Games döntése attól függ, hogy mi az ideális a játékhoz.
-
Abu85
HÁZIGAZDA
Valaki akar innovációt, valaki pedig nem. Ez a kiadó anyagi lehetőségein múlik.
Ez említett kiadók és fejlesztők döntése nem függ az AMD-től. Ők csak nagyobb kontrollt akarnak és ezt a feketefobozok mindenféle formája akadályozza. Volt a Sony-nak egy előadása korábban. Azt hiszem három éve beszélt róla a Santa Monica Studio, hogy totális hiba a middleware-ekre hagyatkozni, mert elveszik a lehetőség összehangolni az egyes pipeline-okat. És akkor mondták, hogy a következő motorjukhoz nem hasznalnak majd middleware-t és mindent saját maguk írnak meg. Ebből született a The Order 1886. Most a nagyobb kiadók ezt akarják követni, hogy el tudjak érni az Order szintű grafikát. Ha képesek finanszírozni ennek a költségeit, akkor joguk van erre menni.
-
#6239
Abu85
HÁZIGAZDA
huskydog17
#6238
Abu85
HÁZIGAZDA
válasz
huskydog17
#6238
üzenetére
Attól függ, hogy a Ghost Games hogyan dönt. Ez nem az AMD és a Frostbite Team döntése.
-
Abu85
HÁZIGAZDA
válasz
Laja333
#6231
üzenetére
Vagy rossz branchet választottak. Az Unreal Engine 4 csak egy alap. Ahhoz meg számos komponens választható. A middleware-ek megkönnyítik a fejlesztő munkáját, de ennek az ára a gépigény növekedése. Függetlenül attól, hogy mennyire gagyi a grafika. Az Epicnek is inkább a lehetőségek kiszélesítése, és az egyszerűbb használhatóság fontosabb az optimalizálásnál. Ezt mindkét megjelent UE4 játéknál láttuk.
-
Abu85
HÁZIGAZDA
A GW felé egy EA, egy Square Enix EIDOS divízió, egy Codemasters, egy SEGA nem tud váltani mert megakadályozza az optimalizálást. Nekik van erre anyagi keretük. Elég csak azt látni, hogy egyre több middleware-t cserélnek saját technológiára. Nekik nem n+1-ik zárt middleware kell, hanem kontroll. Többen rájöttek, hogy ha mindent házon belül írnak, akkor abból nem csak jobb sebességet, hanem jobb grafikát is ki lehet hozni.
-
Abu85
HÁZIGAZDA
Nem tudok most többről. Lehet, hogy van és még nem írták fel. Igazából a jövőben egyszerűbb lesz ez belőni. Amelyik kiadó és fejlesztő saját lábra áll, saját technológiákat fejleszt az AMD-t fogja választani. Amelyik kiadónak és fejlesztőnek ilyen kutatásokat nincs lehetősége finanszírozni azoknak az AMD nem tud mit nyújtani.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#6207
üzenetére
Ezek az AMD címei a következő időszakra: Star Wars: Battlefront, Need for Speed, XCOM 2, Deus EX: Mankind Divided, Ashes of the Singularity, Star Citizen, Mirror's Edge, Mass Effect 4, Hitman, Star Control, EVE Valkyrie. Többet nem soroltak fel. Azt nem tudni mi melyik API-t támogatja, de valamelyik low-levelt, esetleg többet is. Némelyik játék kap TrueAudio támogatást.
-
#6203
Abu85
HÁZIGAZDA
Firestormhun
#6202
Abu85
HÁZIGAZDA
válasz
Firestormhun
#6202
üzenetére
Ez még egy márciusi specifikációra épül, azóta már sok dolog változott. Például megoldották, hogy a Kepler TIER_2 szintre kerüljön a bekötési modell szempontjából, illetve az UAV sincs 8 slotra korlátozva, mert bevezetésre került a virtuális UAV. Igaz, az nem cache-selhető, de működni fog a kód. Emellett a Kepler shader fázisonként támogat 8 UAV-t, ezzel a modellel. Tehát amíg ebből nem fut ki, addig nem kell virtuálishoz nyúlni.
A GCN sem stimmel, mert az TIER_3-as bekötési szintű, és végtelen mennyiségű UAV-t támogat. -
Abu85
HÁZIGAZDA
Nem. A bekötési modellnél a TIER_3 ki lett emelve a feature level szintekből, ahogy a PS-specifikus stencil referencia is, illetve a CR TIER_2 szint.
A Tiled Resources is ki lett ezekből emelve.Valójában ez elég bonyolult lett, de lesz egy cikk, ami táblázatokba foglalja a végleges, és még ámenre váró specifikációt.
Az a lényeg, hogy a TIER az nem egy általános dolog. Vannak funkciók és azoknak belsőleg vannak TIER szintjeik. És ezekből a funkciókból a kötelezőek vannak hozzákötve a feature level szintekhez, ezen belül is egy kötelező minimum TIER szinttel. De ezt majd egyszerűbb lesz a táblázatokból látni.
-
Abu85
HÁZIGAZDA
Mondjuk ez érdekes cikk így. Elmondja, hogy mit támogat a rendszer és berakja a Caps Viewer képet, amiben "No" van odapörkölve két funkció mellé is.
Szerintem le kellett volna írnia, hogy a WHQL driverekben a Microsoft megtiltja a nem véglegesített funkciók támogatását, mert így a user csak azt látja, hogy nem támogatja. -
Abu85
HÁZIGAZDA
Nem lesz kupakja.
(#6153) gbors: Ezt mondom egy ideje. Ezzel csak a saját felhasználóikat szívatják, mert az AMD-seknek csak annyit kell tenni, hogy x16-ra állítják a maximum faktort és jobban megy a HairWorks, mint GeForce-on valaha is fog. Ezért nettó hülyeség, amit csinálnak, hiszen a GeForce tulajdonosoknak az egyetlen lehetőség inaktiválni az effektet. Nekem a HairWorks aktiválása 45-ről 30 fps-re csökkenti a sebességet, de ha beállítom a 16x korlátot, akkor csak -2-4 fps-be kerül, és ugyanazt kapom. Nem velem szúrtak ki, hanem a saját felhasználóikkal. Én boldogan bekapcsolom és élvezem, mindenféle komoly teljesítményveszteség nélkül.
Bár én az Intel terveit nem tudom, de emlékszel az Ionra? Az Intel tudja, hogy nem számít ha valami jobb, ha nem tudod megvenni.
-
Abu85
HÁZIGAZDA
válasz
cyberkind
#6060
üzenetére
Én ezt sem látom annyira reálisnak. Úgy néznek ki a Kepler VGA-sok, mint akik Maxwellre akarnak váltani? Inkább GCN-t nézik, mert nem tetszik nekik, hogy az anno ezer dolláros Titánt már a középkategóriás Maxwellek és GCN-ek ütik.
(#6064) Szaby59: De milyen igény? Fizetünk ennyit és ennyit, ha használod? Ez nem igény, csak vannak olyan fejlesztők, akik pechesek, hogy az Intel és az AMD partnerprogramjába már nem férnek be. Az NV-nek meg erre bőven van kapacitása, mert a tehetős kiadók már elmentek tőlük.
-
Abu85
HÁZIGAZDA
Abszolút nem vagyok arról meggyőződve, hogy a PC-piacnak jót tesz, ha mesterségesen magas egy játék gépigénye a beépített zárt effektekkel. Nem tudom, hogy ezt az NVIDIA miért látja úgy, hogy ez a PC érdeke. Szerintem, ha megkérdeznénk őket, valószínűleg ők sem tudnák elmondani.
-
Abu85
HÁZIGAZDA
Módját vagy hiányát? Mert ez az, amit a fejlesztők a legjobban kritizálnak, hogy nem tudják optimalizálni a zárt middleware-eket. Mi sem láthatjuk azt, hogy ezek jól optimalizált, jó minőséget kínáló rendszerek lennének. Ha azt látnánk semmi gond nem lenne, de helyette azt látjuk, hogy szimpla felhasználói hack minőségvesztés nélkül a kétszeresére gyorsítja a HairWorksöt. Milyen optimalizáció ez, amikor ilyet meg lehet tenni? Miért kellene ezt titkolni? Az iskolában kellene oktatni, hogy ezt ne csináld.
A másik dolog, hogy ezt mennyire célszerű megcsinálni, hogy közben tudod, hogy az iparág nagyágyúit elveszted ezzel a stratégiával? Ők nem akarnak feketedobozokat. Évek óta ezek ellen küzdenek, mert csak megakadályozzák őket abban, hogy jó minőségű programot szállítsanak.
-
Abu85
HÁZIGAZDA
Tehetős fejlesztő még nem is használta, szóval természetesen senkinek a fejéhez nincs pisztoly nyomva. Maximum nem kapnak pénzt, ha nem használják.
Szerintem 2015-ben, amikor sorra nyitják meg a middleware-eket a zártság melletti indokok okafogyottak. Főleg egy hardvergyártónak, ahol nem is ebből élnek. Mert egy Havokot még megértenék, de ők is nyitnak, miután az EA és az Ubisoft belengette, hogy váltanak nyílt forráskódú motorra, ha nem kapnak teljes kontrollt a Havoktól. Nyilván innen nem volt kérdés, hogy nyitni kell.
-
Abu85
HÁZIGAZDA
Sok más oka nincs annak, amiért megéri szívatni a fejlesztőket. Az innováció a PC-n nem szolgálja az NV érdekeit. Ezért minden olyan effekt, amit átadnak a fejlesztőknek zárt, hogy bármennyire okos és tehetős egy partner ne tudja úgy módosítani, hogy szebb és gyorsabb legyen az adott effekt, mint ahogy azt az NV elgondolta.
Cégen belül tök jó példa az AndroidWorks. Nemrég mutatták be. Abban a GameWorks for OpenGL nyílt forráskódú és szabadon módosítható, annak érdekében, hogy a fejlesztő lehetősége meglegyen az innovációra, ami Androidon már érdeke az NV-nek. -
Abu85
HÁZIGAZDA
válasz
#85552128
#6033
üzenetére
Ez a következménye annak, hogy az API-k felnőttek a hardverek tudásához. Az ipar ezzel a lehetőséggel szabadon fejlődhet.
A bekötési modell fejlesztése alapvető lehetőséget ad, hogy egy effekt minősége jó legyen. A TressFX előnye ma, hogy messze ez kínálja a legjobb leképzési minőséget a hajra és a szőrre, mert tartalmaz OIT-t, ami ennek a koncepciónak az alapja, hiszen mindenképp abból a hajtincsből kell a színminta, amely legfelül van. Viszont a TressFX 2 UAV-t igényel a működéshez, vagyis ahhoz, hogy ez minden karakteren működjön korlát nélküli bekötés kell.
A HairWorks a másik véglet, mivel nem igényel UAV-t. Meg is látszik a minőségén, hogy ki van hagyva a legfontosabb eljárás a leképzéséből, amivel nincs garantálva, hogy jó hajtincsből lesz meg a pixel színmintája. -
Abu85
HÁZIGAZDA
válasz
#85552128
#6030
üzenetére
Mások a célok itt. Az új API-knak a korlát nélküli bekötési módjai azt teszik lehetővé, hogy a programozók a hardver használatánál és az algoritmusok kialakításánál szabad kezet kapjanak. Nyilván korlátozza a lehetőségeket, ha hardveres vagy szoftveres szempontok miatt nem tudják létrehozni a szükséges erőforrást a hardveren belül. Ez megakadályozza az innovációt.
A GameWorks egy más céllal született. Azzal, hogy az NVIDIA kontrollálhassa az adott játék igényeit, és teljesen elfojtsák az innováció lehetőségének a csíráját is.
Nagyon érdekes az AndroidWorks. Az NV-nek Androidon érdeke az innováció, és nyílt forráskódú, szabadon módosítható GameWorks effekteket adnak a GitHubra feltöltve, ellentétben a PC-s rendszerrel. -
Abu85
HÁZIGAZDA
válasz
#85552128
#6030
üzenetére
A TIER3-as bekötési szint alapvetően egy skalár processzort igényel a multiprocesszorba, hogy a bekötés ne a mintavételezőbe, hanem magába a multiprocesszorba történjen. Egy ilyen rendszer már eleve garantálja azt, hogy a bekötés korlát nélküli, mert nem egy fixfunkciós egység gondoskodik a meglévő erőforrásokról, hanem egy teljesen programozható. Alapvetően a GCN minden bekötést egységesként kezel. A hardver belül nem különbözteti meg ezeket, így mindegyik létrehozott erőforrás írható, olvasható, akár egyszerre is, és gyorsítótárazható. Az API-kkal kapcsolatos különbségeket majd a meghajtó lekezeli.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#6027
üzenetére
Ahogy írtam korábban, alapvetően a bekötési modell messze a legfontosabb. Mivel ez határozza meg, hogy mennyi erőforrás áll rendelkezésre a fejlesztőknek, vagy másképp fogalmazva mennyi effektet képesek engedélyezni egy játékon belül. Például az idén érkező DX játékban a TressFX mindenkinek a haján rajta lesz, de ezt a módot csak akkor aktiválja, ha TIER3 a bekötési szint. Alacsonyabb szinten csak a főszereplő hajára lesz korlátozva.
Azért tervezte ennyi ideig a bekötési modellt a Microsoft, hogy az mindenkinek jó legyen. Szépen lehessen használni az Xbox One képességeit, miközben ez a PC-s portolást ne nehezítse. Egyszerűen az effekteket alacsonyabb szinten le lehet tiltani, és mindenki boldog. -
Abu85
HÁZIGAZDA
válasz
#85552128
#5992
üzenetére
Nem. A DirectX 12 az DirectX 12. A feature level innentől kezdve nem komoly dolog, mert nagyrészt csak opcionális funkciókat tartalmaz, zömében nem véglegesítetteket.
A DX12-ben a legfontosabb újítás szoftveres, vagyis az overhead csökkentése. Ez a kulcstényező és nem más. A másik fontos újítása az asszinkron compute, ami a GPU-limit ellen küzd. Ezzel lehetőség van ezeket a masszívan párhuzamos lapkákat tényleg párhuzamosan dolgoztatni, mert nem csak sorban kerülhetnek rá feladatok.A bekötési modell az azért nagyon fontos és azért van folyamatosan kiemelve a fejlesztők és a Microsoft által, mert ez határozza meg az API-nak azokat a képességeit, ahogy a hardvert elérheti. A GPU-k nem olyanok, mint a CPU-k, hogy írsz rá programokat és azok futnak. Itt amellett, hogy van memóriájuk, még masszív limitációkkal írhatók programok rá. Ezért került bevezetésre a DX12-ben ez az új bekötési modell, hogy a fejlesztők ahogy egyre komplexebb programokat írnak, ne fussanak ki az erőforrásokból. A hosszabb távú cél igazából az, hogy a fejlesztőnek csak arra kelljen figyelni, hogy a GPU-nak van x GB memóriája és azon belül annyi erőforrást hoznak létre amennyit abba belefér. Ma ez óriási limit, mert az API nem enged meg akármit, még akkor sem, ha a hardverek jók lennének. Ez pedig akadályozza azt, hogy végeredményben hány effektet írhatsz bele az adott játékba. Hosszabb távon ezt az állandó kompromisszumkényszert akarja leküzdeni a Microsoft ezzel az átdolgozott DX12-es bekötési modellel. Egyszerűen, ha a fejlesztő megálmodik valamit, akkor csinálja meg, ne azért legyenek kidobva dolgok a programból, mert kifutott az API által megengedett erőforrásokból.
A véglegesített specifikációk tekintetében a GCN egyes verziói egységesek. A nem véglegesített opcionális specifikációk esetében meg kell várni a véglegesítést.
Az overhead biztosan csökken, az független a feature level szinttől. Ezt két dolog határozza meg. Az egyik a parancsok párhuzamos beírása a parancspufferekbe, ami egy szoftveres funkció, vagyis igazából nem igényel semmilyen komolyabb dolgot a GPU-n. Jó persze kér egy modernebb hardvert, de az elmúlt hét évben megjelent GPU-k elméletben tuti jók. Amelyik cucc kap DX12 drivert ott ez a funkció megy. A másik a bekötési modell, ami szintén meghatározza az overheadet. Ebból a szempontból a TIER1 jár a legnagyobbal, mert az emuláció. Nem rossz így sem, de érezhető lesz. A TIER2 már bindless, tehát eléggé alacsony a többletterhelése. A TIER3 pedig explicit bindless, vagyis nincs többletterhelése.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#5990
üzenetére
A Vulkanról még felesleges beszélni, mert a base specifikációk sincsenek véglegesítve. Ettől függetlenül egy hasonló bekötési modellt használ, mint a DX12, csak más paraméterezéssel, és több emulációs lehetőséggel. De a véglegesítésig ezek változhatnak. Láthatod, hogy a DX12 modelljét négyszer módosítottak, mire végleges lett.
A DX12 végleges bekötési modelljével (amire még mindig rá kell mondani az áment, de szinte ki van zárva, hogy változik) a TIER1 egy emuláció lett. Azt támogatja az Intel Gen7.5, Gen8 és az NV Fermi. A TIER2-t a Kepler és Maxwell, míg a TIER3-at a GCN.
Az opcionális funkciók nincsenek véglegesítve, mert kevés volt rá az idő. A fejlesztők használhatják, de a Microsoft kiadta nekik, hogy vigyázzanak vele, mert ha év végén jön egy végleges verzió és változik, akkor a kiadott program nem fog működni.
Egyébként igazából a ROVs egy mutex zárolás a rendszerben. Olyan mint az Intel PixelSync, a GCN ezt tudja támogatni, mert a GDS-re írható egy olyan implementáció, amely zárolja a folyamatokat a megfelelő megérkezéséig. Ezt OpenGL-ben már támogatják. A Conservative Rasterization igazából eltérő interpolációt igényel a hardverben. De mivel a GCN szoftveres interpolációt használ már évek óta, így az egész támogatás csupán a fordítón múlik és nem a hardveren. Eleve az interpoláció a GCN-en annyi, hogy a CU-nkénti 64 kB-os LDS-ből 32 kB-ban ott vannak az interpolált háromszögadatok. Annyi interpolációs rendszert írsz rá a shadereken keresztül, amennyit akarsz. Most csak egy van, de például a Mantle új verziójában maga a fejlesztő is megírhatja a saját interpolációs rendszerét.A Wikipédiás táblázat teljesen téves. Nincs olyan, hogy hUMA a DX12-ben, az egy HSA specifikáció
. IOMMU-van a WDDM 2.0-ban. És azt sem tudja támogatni egyetlen dedikált GPU. Emellett azt hiszik, hogy a TIER szinten az egyes eljárásokon a bekötésre vonatkoznak. Hát nem.A DX12-ben és a WDDM 2.0-ban nincs minden opcionális rendszer véglegesítve.
Ami véglegesítve van arra a támogatás ilyen:
Bekötési modell fentebb, nem írom le újból.
WDDM MMU modell: emulált: Intel Gen7.5, NV Fermi, dedikált: Intel Gen8, NV Kepler és Maxwell, AMD GCN
WDDM GPUMMU: minden dedikált GPU
WDDM IOMMU: csak APU: AMD Kaveri, Carrizo vagy Intel Broadwell, Skylake
Aszinkron Compute: AMD GCN, NV Maxwell (kivéve a GM107). Az Intel Gen8 támogatja, de az Intel mondta, hogy náluk ez lassulást okoz, így nem fogják engedélyezni.
SAD4: mindenen emulált, kivéve a GCN, ott ez dedikált utasítás
Aszinkron DMA: AMD GCN, NV Maxwell (kivéve a GM107). Emellett számos korábbi Quadro VGA-n ez működni fog, mert a Kepler óta van két DMA az NV GPU-ban, de abból a GeForce-okban egy mindig le lett tiltva.
Atomi számláló: mindenen emulált, kivéve a GCN, ott ez dedikált utasításVéglegesítésre vár még a maradék opcionális funkciók és a WDDM hard preempció. Ezeket az elkövetkező egy évben tervezik befrissíteni a Windows 10-be. Lehet, hogy apránként, lehet, hogy egyszerre.
A bekötési modell gyakorlati haszna csupán az, hogy mennyire limitálja az adott modell az erőforrás-használatot. Kvázi ennek a jelentősége az lesz, hogy mennyi effekt kerülhet egy játékba egyszerre. Itt főleg compute effektre kell gondolni, mert leginkább az UAV-k száma lesz a limit. Ma nagyjából 4-7 compute effekt van egy játékban, de a jövőben ez a szám növekedni fog, tehát végeredményben az a cél, hogy a limitáció tulajdonképpen csak a memória legyen, és ne más.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#5982
üzenetére
Én Witchert az első rész után csak így veszek. Az Enhanced patch mellett kiszedik a bugokat, és jó lesz. Az első részt egy nagy bug miatt be se tudtam fejezni az Enhanced patchig, akkor is újra kellett kezdenem. Szóval a W2-nél már tanultam ebből és csak később vettem meg. Most is ugyanígy teszek. Mire lesz Enhanced verzió, addigra az ára is a fele lesz.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#5979
üzenetére
A gépigényre gyúrni az EA-nek megint egyszerűbb. A Dragon Age: Inquisition a Frostbite aktuális verziójának utolsó nagyobb címe. Ez azt jelenti, hogy a 3-as főverzió már eléggé optimalizált, hiszen az első játék óta másfél évet lehetett polírozni. A Red Engine új, szinte polírozás nélküli rendszer.
Majd az EA is át fog állni a következő nagyobb Frostbite frissítésre. Talán nem 4 lesz a neve, de az NFS és a SW: Battlefront már ezzel jön. -
Abu85
HÁZIGAZDA
válasz
#85552128
#5964
üzenetére
És most hasonlítsd össze az EA és a CDPR készpénzállományát és fejlesztői lehetőségeit.
De amúgy ja egyetértek, a Dragon Age: Inquisition-t grafikailag nem sikerült lenyomni, csak ez pénzkérdés inkább, mintsem technikai.Egyébként nem vagyok benne biztos, hogy az elkövetkező két évben bárkinek is esélye lehet a PC-n az EA által követett újszerű fejlesztési modell mellett. Egyszerűen a váltásokra marha sok pénzt mozgósítottak, és marha jó a szakemberi gárda a Frostbite mögött. Leghamarabb a Square Enix tudja őket befogni, de ők is lassabban kapcsoltak, és alapvetően több erőforrást kell majd mozgósítaniuk.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#5926
üzenetére
Azóta csúnyán eltelt 7 év. 7 éve jó volt, ma semennyire nem az. Valószínűleg 7 év múlva a DX12-re is azt mondjuk, hogy limitál, és jön a következő lépcső. Biztosan megmondom most, hogy a DX12 sem tart örökké. De az elkövetkező fél évtizedre jó lesz. Addig pedig van idő újat fejleszteni.
-
Abu85
HÁZIGAZDA
Nem is kell, hogy összekapcsolva legyenek, bár szinkronizáció azért van. De elég, ha egy rosszul kialakított API és a kernel driver nem engedi a programszálakat hozzáférni az amúgy szabad erőforrásokhoz.
Ez tudom, hogy nagyon mellbevágó dolog, hogy a PC ennyire pazarló platform lett, de ez van. Viszont nem véletlenül alakult úgy, hogy két év alatt egy komplett reformot végigvittek az érintettek a teljes rendszeren.Amikor arról beszélünk, hogy a DX12 micsoda előrelépés a DX11-hez képest, akkor az jön elő, hogy milyen jó ez a DX12. Valójában ezt úgy kellene felfogni, hogy milyen rossz a DX11. A DX12 csak rendbe hozza, amit már rég rendbe kellett volna hozni.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
Szándékosan belinkeltem azt a részt, ahol erről beszél.
Ez egyszerű. Attól, hogy nincs kernel driver még a feladatokat el kell végezni. Az alkalmazásnak explicit elérése van a GPU felé, de ez csak azt jelenti, hogy meghatározhatják, hogy mit csináljon a hardver, de a parancskiadáshoz már szükséges egy driver, ami például lefordítja a szoftver queue-t a hardver nyelvére, stb. Ez a user driverben fog látszódni, még akkor is, ha az alkalmazásban van rá a kód.
-
Abu85
HÁZIGAZDA
Miért lenne irreleváns? Az iparág két legjobb fejlesztője magyarázza, hogy mi a gond a DX11-gyel. Ők a GAB tagjai, pontosan tudják, hogy mi a helyzet. Azért ne őket hibáztasd, hogy azt mondják amit én, valószínűleg azért teszik, mert 15-25 éves tapasztalatuk birtokában képesek megállapítani, hogy mi a probléma a DX11-es modellekkel.
Mert a driver soros feldolgozásra kényszeríti a rendszert. Ez a nagy problémája a rendszernek. Hiába van ott még 7-9-11 szabad mag a soros feldolgozás miatt nem érhetők el.
Tökéletesen ábrázolták, te értelmezed rosszul. A kernel driver eltűnik, ahogy az MS is lerajzolta. Nem veszi át a feladatát a user mode driver. A program lesz, ami átveszi a munkát. A videóban erről is beszélnek.
-
Abu85
HÁZIGAZDA
[link] - ez segít megérteni, hogy miért nem hozzáférhető az a temérdek processzoridő.
Sajnos ezt nagyon rosszul érted. A user mode driver valójában csak allokációval foglalkozik. Eldönti, hogy a programnak 4 vagy 64 kB-os lapokat foglaljon le például, illetve végzi a valós idejű shader fordítást. Az ami régen a kernel driver feladata volt, mint a hazárdok kezelése vagy például a memóriamenedzsment teljesen átkerül a programba. A fejlesztő fogja ezt vezérelni. Ezért hívjuk ezeket explicit vagy low-level API-knak, mert a munkát a programozó határozza meg és nem egy driver. A fentebb linkelt videó erre is kitér.
-
Abu85
HÁZIGAZDA
Miben? Mert a hozzáférhető processzoridőben sajnos az. Hiába vannak erős hardvereid, ha nem nyúlhatsz büntetlenül hozzájuk.
Az nem úgy működik. Valójában az a processzoridő hozzáférhetetlen, mert a meghajtó soros munkára kényszeríti a programot. Hiába van ott elméletben, ha nem férhetsz hozzá.
A user mode driver egy shader fordító, illetve egy alapvető vezérlőcsomag. Nem látja el a kernel driver feladatát. A fejlesztőnek kell megírnia azt a programon belül. Nyilván ez is hozzájárul ahhoz, hogy nő a processzor kihasználásának hatékonysága, mert eltűnik minden olyan rendszer, amit nem profilozhatsz. Ma ha valami nem működik, nem tudnak a fejlesztők beleírni a driverbe. Ez okoz sok gondot. A jövőben ez nem lesz gond, mert lényegében nem lesz driver, a saját kódod pedig tudod javítani.
-
Abu85
HÁZIGAZDA
A multiplatform játékokat eleve úgy tervezik, hogy minden célplatformot figyelembe vesznek, és az egyes szempontok szerint a leggyengébb platformelemekre lőnek. A DX11-ben a PC-n van a legkevesebb befogható processzoridő, így a szimulációt ehhez igazítják.
Nem az NV a probléma, hanem a DirectX 11 és az agresszív kernel driver. Ezért kezeli a Microsoft ezt a problémát úgy a DirectX 12-ben, hogy eltünteti a rendszerből a kernel drivert.
Az NV-nek nyilván az a lényeg, hogy a grafika legyen jó, az nem számít, hogy a játékmenetben az előző generációs konzolcímek is lealázzák a PC-t. Abban viszont igaza van a Microsoftnak, hogy a grafika skálázható, míg az AI nem, tehát ha egy játékot nem tervezel úgy, hogy a PC-t is számításba veszed, akkor az probléma lesz a portolásnál. -
Abu85
HÁZIGAZDA
Nem szerintem, hanem a Microsoft szerint.
Szerintem az egész rendszer úgy ahogy van rossz, ha a gyártók nem képesek betartani a szabályait. Gondolom ezért veszi el a kernel drivert a Microsoft a DirectX 12-ben, hogy a gyökerénél tűnjön el az alapprobléma. Ezzel az a gond is eltűnik, hogy a kevés valós processzoridő miatt nem lehet komoly AI-val konzolra tervezett játékokat PC-re portolni.Az is fontos, hogy az első dolog, ami fejlődni fog a DX12-vel az az AI. Megvannak az algoritmusok. Nem állt le a fejlesztés, csak nincs meg a számítási kapacitást hozzá PC-n, de nem a hardver, hanem a grafikus driverek miatt.
Kevin Floyer-Lea low-level leírásában is ott van ez: "Ability to increase the CPU budget for other systems like AI". -
Abu85
HÁZIGAZDA
Minden multiplatform játékot multiplatformnak terveznek. Veszik minden esetben a legszűkebb keresztmetszetet és arra terveznek. Ha a PC ebben benne van, akkor tudják, hogy a szimuláció korlátozott, mert kevesebb valóban felhasználható processzoridő áll rendelkezésre. Tehát ez már be van tervezve.
A Halo 3 a Microsoft címe, ahogy a Halo és a Halo 2 sem jött Sony gépekre, úgy a Halo 3 sem volt tervben. De Windows-ra ki akarták adni, mert az első két rész is jött PC-re, de nem volt meg az erőforrás hozzá PC-n. Az AI-t kellett volna butítani, de nem tették meg. Aztán mivel a processzoridő évről-évre csak csökkent, így lelőtték a projektet.
A Capcomtól tudom, hogy hasonlóan járt a Dragon's Dogma is. Talán egy remasterre van esély.
-
Abu85
HÁZIGAZDA
válasz
stratova
#5886
üzenetére
A full deferredet semmiképpen, mert a PBS-re az a legjobb. Igaz, szétzabálja a sávszélt, de megvan a maga előnye.
Low-level API-nak annyi az előnye, hogy eltűnik a driver. Tehát a program a teljes processzoridőt megkapja és szabadon felhasználhatja.
A problémát maga a driver okozza. Ezért nincs kernel driver DX12 alatt. Minden új API így oldja meg ezt a gondot. Ez az MS megoldása. A DX11 meg így marad. Nem tudnak vele mit kezdeni.A példákkal az a baj, hogy az MS is itt hasalt el. Lefuttatták a teszteket és szuper volt. De egy játék nem csak rajzolás, hanem szimulációs munka is, és ott már negatívba megy a sebesség. Ezért kért meg mindenkit az MS egy éve, hogy ne használják. Inkább skálázzák le a grafikát.
-
Abu85
HÁZIGAZDA
A Microsoft már magára vállalta a felelősséget. Amikor bemutatták a DirectX 12-t, akkor elmondták, hogy DX11-ben használt modell egy totális tévút, és mindenkit lebeszélnek azóta róla. A probléma egyébként jelentős. Minden évben azt tapasztalták a fejlesztők, hogy jönnek az új processzorok, és eközben csökken az elérhető processzoridő. Ez nem jó irány sehogy sem.
Ha olvastad, amit írok, akkor az Intel drivere ebből a szempontból a legjobb. Az AMD a két végpont között lavírozik.
-
#5880
Abu85
HÁZIGAZDA
Malibutomi
#5875
Abu85
HÁZIGAZDA
válasz
Malibutomi
#5875
üzenetére
Ez egy ballansz probléma. Mennyi processzoridőt igényel a játék és mennyit vesz el a driver. A mai multiplatform címek szándékosan rendkívül butítottak a játékmenet szempontjából, hogy maga a szimuláció kevés processzoridőt igényeljen, és az NV driverének is legyen elég szabad erőforrás. Az AMD és az Intel drivere ezzel biztosan jó lesz, mert kevesebb szálat futtatnak.
(#5877) Szaby59: Ez a lényeg. Azért kapcsolod ki, mert nagyon zabálja a géped, pedig valójában ugyanehhez a minőséghez nem kellene ennyi veszteség. És akkor már átgondolnád, hogy mást kapcsolj ki például.
A Frostbite 3 egy deferred MSAA technikát használ. Minden render targetet leszűr, vagyis más játékokhoz mérten az MSAA munkája 4-5x-ös.
-
Abu85
HÁZIGAZDA
A Halo 3 azért nem jött PC-re, mert nem volt elég processzoridő a driver szálak mellett. Ekkor volt az, hogy az MS összehívta a cégeket, hogy ez így nem lesz jó, mert hiába jönnek a jobb processzorok a reálisan felhasználható processzoridő az egyre agresszívabb driverek mellett inkább csökken. Ezért nem látsz AI innovációt évek óta. Egyre kevesebb rá a büdzsé.
Szinte mindegyik exkluzív ls komolyabb konzolos játék AI-ja és fizikája túlmutat a PC-s szinten. Az AI szempontjából különösen durva a The Last of Us és a Dragon's Dogma. A fizika szempontjából az Uncharted 3. -
#5874
Abu85
HÁZIGAZDA
Malibutomi
#5872
Abu85
HÁZIGAZDA
válasz
Malibutomi
#5872
üzenetére
A D3D driver egy komplex probléma. Amit sokan nem vesznek figyelembe, hogy itt nem csak a megjelent játékokat nézik a cégek, hanem a megjelenés előtt állókat is. Alapvetően az Intel D3D drivere a legjobb. Messze az látszik a legrosszabbnak a tesztekben, de reálisan felhasználható processzoridő jut a programnak. Az NV drivere a másik véglet. Iszonyatosan zabálja az erőforrást, míg az AMD drivere a kettő közötti átmenet.
Hogy ez miért fontos? Bizonyos konzolra írt játékokban az AI és a fizika komplexitása a PC-s játékokon túlmutat. Viszont a D3D driverek miatt ezeket nem lehet PC-re portolni, mert túl sok erőforrást elvesznek a driverek. Ezért kér a Microsoft thin drivert, mert a grafikát képes skálázni a fejlesztő, de az AI-t és a játékmenetre ható fizikát nem. -
Abu85
HÁZIGAZDA
válasz
#85552128
#5869
üzenetére
És lám kiderült, hogy ezért tudják megcsinálni, mert ugyan felfogod, hogy konkrétan veled csesznek ki, de egyszerűen elfogadod, hogy ez így jó, és hogy ez egy szép jövő lesz. A teljesítményigényes és gyenge minőségű effektek jövője. Eközben keresel minden lehetőséget, hogy kontráz, aminek konkrétan semmi köze ahhoz, hogy a HairWorks jóval több teljesítményvesztést okoz annál, mint amennyit igazából kellene, hogy okozzon.
Nem értem mi az, amitől egy felhasználó annyira jól jár, hogy védeni kell a mesterségesen magasra pakolt gépigényt? Többet költhetsz gépre? Ezt megteheted úgy is, hogy az adott program és effekt úgy fut ahogy kell. -
Abu85
HÁZIGAZDA
válasz
stratova
#5866
üzenetére
A saját felhasználóid megszopatása a következő szint ebben a nem túl fényes jövőben. Ez alapvetően sikeresnek mondható, hiszen nem egy ember védi azt az álláspontot, hogy a saját PC-jén legyen egy effektnek -20-30%-os deficitje az amúgy reális -5-10%-os helyett, csak azért, mert biztosan jót akart ezzel az adott gyártó.
-
Abu85
HÁZIGAZDA
Nem értitek a gondot. A gyártók olyan szerződéseket kötnek, amellyel az adott partnernek gyakorlatilag nincs reális kiszállója. Még ha a szerződésnél át is beszélik: jó persze erre nem fog sor kerülni, mert aranyosak vagyunk, akkor is szerződés világosan fogalmaz. Gondoljatok bele. Az AMD fogja magát és ismét hirtelen felindulásból letiltatja a TressFX-et, vagy akármelyik effektet a Star Citizenben. Nem fog a CIG ellenkezni, mert túl drága lenne. Inkább megteszik, amit kérnek.
Ez az egész ipar problémája. Még ha az iparért is akarnak dolgozni a szerződésekben kibiztosítják magukat és ha elpattan a húr, akkor itt tök szabványos effektek lesznek Radeon és GeForce only megoldások szinte minden játékban. Melyikőtök akar ilyen jövőt?
-
Abu85
HÁZIGAZDA
válasz
#85552128
#5852
üzenetére
Pedig a fejlesztő most a legkevésbé okolható azért, hogy az NV milyen paraméterezéssel kéri szállítani a GameWorks csomagokat. Ezt ők határozzák meg.
Szerinted az AMD miért tehette meg, hogy letiltatja a TressFX-et a Lichdom januári frissítésében? Egyszerűen szerződésben megvan hozzá a joguk. Ott sem a fejlesztő a hibás, de ha nem teszi meg, akkor olyan kötbérrel tud kiszállni a szerződésből, hogy azonnal tönkremennek. -
Abu85
HÁZIGAZDA
válasz
#85552128
#5846
üzenetére
Az a baj, hogy a haj annyira vékony geometria, hogy az nem így működik. Elképzelhető, hogy még 16 mintavételi pontnál is úgy átmegy egy haj a pixelen, hogy egyetlen mintavételi pont sem "döfi át". És onnantól kezdve rögtön rossz az adott pixel színe. Ezért nem adnak rá külön opciót, mert tudják, hogy a 8x is kevés.
Az anizo esetében vannak problémák. Nem minden felülettel kompatibilis, így előbb ezeket kell megoldani, hogy használható legyen.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#5843
üzenetére
Az MSAA részletességét a HairWorksre vonatkozóan csökkenteni kérdéses. Így sem elég a 8xMSAA opció. 16x lenne az ideális.
A HairWorks esetében semmilyen minőségvesztést nem eredményezne a tesszellálás 64x-ről 16x-re csökkentése és két-háromszorosára gyorsítaná az effekt sebességét. Ez sem lenne optimalizálás, de gyakorlatilag minőségvesztés nélkül kapnál extra sebességet, ami kezdetnek jó. A következő lépcső egy analitikai élsimítás lenne, ami kiváltaná a HairWorksre futtatott MSAA-t, mert ez valószínűleg olcsóbban jobb minőséget eredményezne pusztán a célirányos jellege miatt.
Ezután esetleg el lehetne gondolkodni az önárnyék és az átlátszóság problémáján, amivel a HairWorks újra -20-30%-os teljesítménybe kerülne, de a minősége a mostani szinthez képest nagyban megugrana. -
Abu85
HÁZIGAZDA
válasz
FLATRONW
#5834
üzenetére
Én a GTX 760-en a 25-30%-os kihasználást nem mondanám magasnak. Ezt szerintem fel lehet tornázni a GCN-es hardverek 35-40%-os szintjére, vagy a közelébe. Az, hogy egy program mit ír semmit sem jelent. A belső kihasználás számít, amit mondjuk GPUView-vel tudsz ellenőrizni, vagy GPUPerfStudióval. Ettől a 99%-ot oda fogja írni rá az olyan kamuprogram, mint az afterburner és bármi hasonló.
-
Abu85
HÁZIGAZDA
A WDDM 2.0 alatt megmarad a régi WDDM szegmentált fizikai címzése. Ez egy legacy funkció lesz, de maga a low-level API meg fogja engedni, hogy a fejlesztő megírja az implementációt a programban a szegmentált fizikai címzés működéséhez. A kezdetekben valszeg ilyen motorok fognak születni, mert túl kevés lesz a Windows 10 felhasználó WDDM 2.0 only játékokhoz. Ilyen esetben a fejlesztőknek lényegében ugyanolyan lehetőségei vannak a VRAM vezérlésére, mint ma a kernek drivernek, persze a közvetlenebb elérés miatt a WDDM ellenőrzésre vonatkozó funkcióit el lehet felejteni, tehát a sebesség jobb lesz.
-
Abu85
HÁZIGAZDA
A low-level API-nál azt is figyelembe kell venni, hogy mit csinál a program. WDDM 2.0 alatt nem szükséges tudnia, hogy mennyi VRAM van a kártyán, mert ott a virtuális memóriára vonatkozó GPUMMU mód. Ha a program mindenképpen fizikai címzésre akarja kényszeríteni magát, akkor kell tudnia a hardver VRAM kapacitását. Ez lehetséges, főleg akkor, ha nem akarják, hogy az alkalmazás csak Windows 10-en fusson. De többen mondták már, hogy 2016 végére inkább bevállalják a Windows 10 only dolgot, mert a WDDM 2.0 túl sok előnyt kínál a GPUMMU-val és az IOMMU-val.
(#5814) Szaby59: A low-level API igazából mindegy. A WDDM 2.0 kínál olyan előnyöket, amelyekkel a VRAM használata a mainál lényegesen hatékonyabb lehet, és igazából lesz is. Mindegy, hogy DX12, Vulkan vagy Mantle, mindegyik rendszerből kihasználható a WDDM 2.0 extrája. A GPUMMU rendkívül hasznos, mert igazából a VRAM működése sokkal jobban fog hasonlítani a rendszermemória működéséhez. Az IOMMU pedig még egy lépés előre, mert igazából az adatnak nem is kell a VRAM-ban lennie, egyszerűen olvashatja és írhatja azt a hardver a rendszermemóriában is. A különböző linkelési lehetőségek is nagyon jók. Például egy GPU-val minden különösebb probléma nélkül olvashatod egy másik GPU memóriáját, sőt írhatsz is abba. Ezek a mai limitált modellhez képest nagyságrendi előrelépések. Elsődlegesen ott fog ez érződni, hogy jóval több szabad VRAM-od marad, amit persze elhasználhatsz másra. Tehát önmagában a mai pazarló rendszer ki lesz ütve.
(#5826) gbors: Hagyományos fizikai címzéssel a fejlesztő is képes beleírni az alkalmazásába, hogy a GTX 970 esetében 3,5 GB gyors memória van és 0,5 GB lassú. Tehát ez egyedi szinten lekezelhető. GPUMMU mellett nem lehet kezelni, mert ott az OS jelzi a rendszernek a VRAM méretét. A user-mode driver csak arról dönt, hogy az allokációhoz 4 kB-os vagy 64 kB-os lapméret legyen használva.
-
Abu85
HÁZIGAZDA
Az XDMA-nak nincs köze az AFR profilhoz. Az XDMA kizárólag azt teszi lehetővé, hogy 4K-ban is egyenletes legyen az AFR frame pacing, és ne legyen tele mikroakadással, mint a hidas megoldásokkal:
Semmi más jelentősége nincs szoftveres és profilozási szempontból. Low-level API-val lehet más előnye is az XDMA-nak, de AFR-ben csak ennyi.
-
Abu85
HÁZIGAZDA
PCLabs teszteket sosem néztem. Korábban is mondtam, hogy az a tesztmetodikájuk, hogy a gyorsaság érdekében több konfiguráción nyomják párhuzamosan nem feltétlenül jó. Még ha tök ugyanaz is két konfigban a VGA-n kívül minden, akkor is lehetnek eltérések a szoftverben. De ettől te hihetsz nekik, de a PCGamesHardware jellemzően jobb konstrukcióban tesztel, és jóval közelebb állnak más oldalakhoz az általuk közölt eredmények, mint a PCLabs-osoké.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#5667
üzenetére
Sajnos semmivel sem jobb egyik AFR technológia sem. Ahol az egyik működőképes ott a másik is, de ahol az egyik nem az ott a másik sem. Erre jön a változás a low-level API-ban, hogy a fejlesztő írja meg, hogy miképp működjön, és ne lehessen a driverekből kényszeríteni egy alig működő megoldást. Ez majd nagy változást fog hozni, mivel újra megéri multi-GPU-ra gyúrni, hiszen a gyártók kontrollja teljesen megszűnik a rendszer felett és átkerül a program irányítása alá a teljes vezérlés.
-
Abu85
HÁZIGAZDA
Az a baj a GameGPU-val, hogy egy olyan driverrel teszteltek, amelyben nincs Witcher 3 profil. A 15.4.1-ben van, ami elérhető volt már május első felében. A 15.4-es áprilisi, és ezt használták. Ezért nem hozza ez a teszt azt, amit más tesztekben látsz a 15.4.1-es driverrel, amibe már raktak profilt pont a játékra készülve.
-
Abu85
HÁZIGAZDA
Kész. Rárepültek a Titan-GTX 960 harcára a W3-ban.
Egyébként azt mondják, hogy a 352-es driver sorozatban egyszerűsítették a shader fordítót. Ez például lehet az oka annak, hogy nem meg annyira jól a Kepler. Érdemes lenne egy régebbi driverrel kipróbálni, ahol még a régi fordító volt.
-
Abu85
HÁZIGAZDA
A Fermi volt az utolsó generáció, ahol a túlterhelés valós problémát jelenthet. Nem feltétlenül kell hardveres védelem és hardveres rendszer. Lehet szoftveresen asszisztált hardveres konstrukció. Ez is stabil marad, csak picit nagyobbat esik az órajel a kelleténél.
A Fermi is stabil marad már, mert a driverbe van egy szoftveres rendszer építve. Ha túlterhelést érzékel, akkor levágja az órajelet elég alacsonyra. Fagyni egyik sem fog. Arra már be vannak építve a rendszerek. A kérdés, hogy mennyire lesz jó a folyamatos órajelállítás. -
Abu85
HÁZIGAZDA
Nem, ezek gyakorlati mérések egy alpha állapotú szoftveren.
Igen a ventit azt pörgeti csúnyán. Ezt írtam az előbb.
A mai hardverek állítható a TDP limit. Az Catalyst erre kínál egy negatív/pozitív csúszkát. Nem tudom, hogy az NV ad-e, de ha nem, akkor tuningprogramokban láttam ilyet. Az persze kérdés, hogy ez negatívba letolható-e.
(#5606) Asbee: Igazából az AotS sem fog a tuningra úgy reagálni, hogy tuti fagy. Ezt kipróbálták. Ha stabil a tuning, akkor annyi történik, hogy a hardver picit jobban veszi vissza az órajeleket. Tehát a stabilitás megmarad, csak lassulást okoz az órajelállítás. Nem stabil tuning meg fagyás, ez egyértelmű. Mondjuk ez a DX12-ben jó lesz, mert nincs TDR a hardverre, és akár viheti a fájlrendszert is magával a gép a resetnél. A bátrak játéka lesz a tuning.
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
Abu85
HÁZIGAZDA
Egészen konkrét mérések is vannak erről, bár csak az R9 290X-ről. Ott a tesztjelenet async shaderrel 45-50 fps között van. Async shader nélkül ez 30-35 fps-re esik. Tehát azzal, hogy a hardvert 85-88% közelébe terheled még úgy is nyersz egy csomó sebességet, hogy a magórajel 150-200 MHz-cel az alapórajel alá esik. Ez a jó a GPU-kban, masszív adatpárhuzamosításra valók.
-
Abu85
HÁZIGAZDA
Azért a boost és az alapórajel különbözik. A hardver szintjén is meg van különböztetve. Ha növeled az alapórajelet növekszik a Boost is.
Hohó de még mennyire. A Fiji-t 94%-ra is leterheli.
A többi hardvert ennyire nem, mert elfogy a sávszél, de a többség 70% fölött van. 80% körül.Hát milyen dizájnra jó?
Ezek a hardverek már képesek az órajelüket visszavenni, ha túlterhelést érzékelnek. -
Abu85
HÁZIGAZDA
Én terelem a témát? Nem én mondtam ki, hogy 1300 MHz-en megy mindegyik 970 out of box. Ki vállalja érte a felelősséget, ha nem? Ilyeneket ne állítsunk, mert nem igaz. Találhatsz olyan alkalmazást, amin jó az a tuning, de biztos találni fogsz olyat is, amin nem. A gyári órajel mindig arra szolgál, hogy oda mindig visszatérhess, ha túlterheli az alkalmazás a rendszeredet, és arra van garancia. Az, hogy te otthon saját felelősségre meghúzod nem jelent semmit. Nincs meg a sok százezer dolláros eszközparkod, hogy kiteszteld úgy, ahogy az NV teszi meg magának, amikor dönt az alapórajelekről.
(#5597) TTomax: Az AotS egy játék lesz. Azzal hívja fel magára a figyelmet, hogy a VGA-k ventijét 70-80% fölé állítja annyira terhel.
50-60% nem jó, csak ennyit lehet ma reálisan kihozni max. A jó a 100%. -
#5598
Abu85
HÁZIGAZDA
Malibutomi
#5595
Abu85
HÁZIGAZDA
válasz
Malibutomi
#5595
üzenetére
Minden stratégiának megvannak a hátrányai. Az NV-nek gyorsan ki kell termelnie az adott architektúrából a pénzt, hogy a gyors váltásokat fenntartsa. Ezért is van az elzárkózás. A fejlesztőknek mindig megmondják az aktuális tutit, ami a korábbi architektúrát és architektúrákat nem érinti olyan pozitívan.
Pedig annyira nyilván nem rossz az első Titan, hogy a GTX 960-nal és az R9 285-tel versenyezzen, de mit tehetnek a fejlesztők, ha nem kapnak dokumentációt a hardverekről. -
Abu85
HÁZIGAZDA
Gondolom ezt a tutimegy 1300-ot out of box dolgot a mai tesztprogramokból és játékokból szűrte le a világ, amelyek mennyire is terhelik a GPU-t? 40-50%-ra?
No offense, de azért ez nem ilyen egyszerű. Az NV nem véletlenül vállal garanciát arra az alapórajelre, amit beállítottak. Ők tudnak olyan alkalmazást írni, ami 100%-ra kimaxolja a terhelést.
A gyári OC meg oké. Ott a VGA gyártója vállalja rá a garanciát, ha mégsem megy. Viszont az, hogy alapmodell out of box tuti megy 1300-on eléggé durva kijelentés. Megnézném azt egy AotS-en, ami leterheli 80% fölé. -
#5591
Abu85
HÁZIGAZDA
Malibutomi
#5585
Abu85
HÁZIGAZDA
válasz
Malibutomi
#5585
üzenetére
Jó, de az NV ráállt az architektúra átlagnál gyorsabb cserélgetésére, míg az AMD előbb letervezett egy jövőbiztosat és azt faragják. Ez két külön stratégia. Nyilván az NV-nél ez költségesebb, hiszen folyamatosan tervezik a rendszereket, amelyekkel hozzák be azokat, amiket az AMD bepakolt a GCN-be. A Maxwell már eléggé megközelítette. Ennek a hátránya, hogy rövidtávon is lesz két olyan architektúra a piacon, amelyet normálisan kellene támogatni, miközben igazából csak az számít, hogy a legújabban jól menjen. A Kepler ennek az áldozata. Majd jövőre jön a Pascal és a Maxwell lesz az áldozat. Ez így megy, ha gyorsan váltod az alapokat.
-
Abu85
HÁZIGAZDA
válasz
Yllgrim
#5582
üzenetére
10% inkább. Valamit elnéztél, vagy fps-t akartál írni. Igaz a Radeon csak 30 MHz-cel volt húzva a gyárihoz képest, míg a GeForce szénné tuningolt verzió a gyárinál ~200 MHz-cel magasabb alapórajellel. A gyári termékek között nyilván kisebb lehet a különbség.
(#5583) TTomax: A 970 is egy gyárinál jó extra 250 MHz-cel megtuningolt verzió.
(#5586) Szaby59: Az AA ilyen MSAA post-process keverék.
-
Abu85
HÁZIGAZDA
[link] - Itt a W3 teszt. Semi-final, Full HD, GameWorks off. GCN és Maxwell jó. A Kepler lemaradt mint a borravaló. Az R9 285 és a GTX 960 ott van az első Titan nyakán. Majdnem verik, de nem, viszont a GTX 780-at elkapta mindkettő.
A Fermi és a régiek ultra grafikára nem jók. -
Abu85
HÁZIGAZDA
Hogy minek? Hát ők írták volna meg az erőforrás-igényes effektek 80%-át a játékba. Azt kell kérdezni, aki megírja, mert ők ismerik a forráskódot és azt, hogy mennyit tudnak rajta gyorsítani x időtartamon belül.
Gondolom nem úgy lett 2013-ban bemutatva az a videó, hogy ezeknek az effekteknek a többségét nem tudjuk megcsinálni, de kell a hype, így rámondták, hogy meglesz. 2013-ban még mindenki kőkeményen hitt benne, hogy ez működni fog. -
-
Abu85
HÁZIGAZDA
válasz
#85552128
#5568
üzenetére
A gamescon demóban nem volt minden aktív.
2013-ban biztosan nem tudták még. 2014-ben valószínűleg tudták, hogy a tervekből nem valósul meg minden.
Azért ez nem olyan dolog, hogy odamész az AMD-hez, vagy az Intelhez, hogy pacsizzunk le. Az AMD hova tudná őket berakni? Ők viszik a teljes EA, a Square Enix nyugati stúdióinak, és a SEGA nagy részének a fejlesztését, amihez még hozzájött a teljes Capcom is. Azért ezek az erőforrások végesek. Az NV-nél most jóval több a szabad kapacitás, mert csak két komolyabb kiadóval dolgoznak. Szóval a mit akarsz és a mit lehet között nagy a különbség.Dying Light sem volt valami korrekt. Persze az első nekifutás a Chrome 6-tól. Egyébként a W3 attól függetlenül, hogy nem tartalmaz majd egy rakás tervezett effektet elég korrekt lesz.
-
Abu85
HÁZIGAZDA
Nyilván 2013-ban látták, hogy miképp fut. Volt mondjuk 10 fps. Megkérdezték az NV-t, hogy 2014-re lesz-e ebből 30. Mondjuk azt mondták igen. Ilyen esetben a fejlesztő csak abban hibás, hogy elhitték, amit mondanak. Ez is valahol egy hiba a fejlesztőknél, csak itt az a gond, hogy nagyrészt meg volt kötve a kezük, tehát még ha akarták sem tudták volna megoldani a problémákat.
Konkrétan ezért menekül az EA az összes zárt környezet elől. Nem rajtuk műlik a problémamegoldás, ami több területen hazavághat egy nagy projektet. A Havokot is csak akkor hajlandók továbbvinni, ha kapnak egy olyan licencet, amivel szabadon átírhatják a forráskódot, ha nem, akkor el fognak menni a Bulletre. Költséges? Az, de a saját kezükben lesz a sorsuk. -
Abu85
HÁZIGAZDA
válasz
#85552128
#5564
üzenetére
In-engine render. Lejátszottak egy előre felvett dolgot. Akkor mindegy, hogy egy másodperc volt egy frame. A hardver offline kiszámolta azt.
Átvihető a Gameworks. Nagyon sok csomagnak van és a jövőben még lesz is konzolra portolható verziója. A GameWorks esetében nem ezzel van a legnagyobb baj, hanem a beépíthetőséggel. Ha nem jó, akkor csak a motort hackelheted addig amíg jó nem lesz, vagy egy idő után feladod.
Hihetitek ezt is, de a helyzet az, hogy lassan érdemes lenne feltenni a kérdést, hogy az utóbbi évben miért volt gond főleg az NV által támogatott PC-s portokkal. Biztos, hogy csak az NV választ mindig bénán partnert? Vagy esetleg a fejlesztők által nyíltan kritizált konstrukciójuk is közrejátszik.
-
Abu85
HÁZIGAZDA
válasz
decibel
#5523
üzenetére
Oké, akkor nézzük, hogy mi butult le két év alatt.
Eltűnt a házakról és a különböző egyéb felületekről a tesszelláció: hiányzik a GeometryWorks
Alaposan megváltozott a tenger hullámzása: hiányzik a WaveWorks.
A részecskeeffektek közül a tűz megváltozott: hiányzik a PhysX Particles
A növényzet minősége és a látótávolság csökkent: beleütköztek a DirectX 11 korlátjaiba.
A víz visszatükröződése a tervezett teljes világhoz képest egy hamis megoldás lett: hiányzik a PostWorks SSR.Persze gondolom így is a fejlesztők a bűnösök. Egyáltalán nincs köze az eredménynek annak, hogy zárt middleware-ekkel vagy magával a korlátozott API-val sokszor lehetetlen helyzetbe hozzák őket.
-
Abu85
HÁZIGAZDA
Azért jobban néz ki, bőven. Meg vannak ennek a váltásnak egyéb technikai részei is. Szóval az előrelépés tényleg megvan. Ha a kategóriához nézzük, akkor valóban a Dragon Age: Inquisition szebb. De itt megint meg kell jegyezni, hogy az EA és a CDPR kasszája között durva különbség van. És alapvetően egy játék technikai oldalát még mindig nagyban befolyásolja a belerakott pénz és erőforrás. Egy CDPR nem képes versenyezni egy EA/Bioware/Frostbite Team felállással. Nem elég tőkeerősek és nagyok hozzá. Viszont a két érintett közötti különbséget figyelembe véve a W3 elég jó lett így is. Legalábbis azért ez a grafika megfelelő a 2015-ös szintre. Persze láttunk szebbet, de egy W3 játékost ez nem fog érdekelni.
-
Abu85
HÁZIGAZDA
válasz
decibel
#5500
üzenetére
Nem értem miért őket kell azért hibáztatni, mert zárt middleware-eket nehéz egy játékba beépíteni. A CDPR igazából nagyon jól megcsinálta a játékot. Amit reálisan ki lehetett hozni, azt kihozták belőle. Az, hogy nem sikerült működésre bírni a GeometryWorksöt, a WaveWorksöt, GPU-s PhysX Particlest, meg pár dolgot, hát van ilyen. Ettől a játék még ugyanolyan jó lesz, csak nem néz ki olyan jól, mint a 2013-as videókban. A kamuzás meg kérdőjeles. Szerintem 2013-ban bőven úgy gondolták, hogy ezek az effektek beépíthetők. Nem hiszem, hogy akkor bárki kételkedett ebben. Valószínűleg 2014-ben került elő először, hogy azért ez a része a dolgoknak nem áll úgy, ahogy tervezték. Maximum azt lehet mondani, hogy 2013-ban túlságosan optimisták voltak és hittek abban, hogy a middleware-ek beépítésével nem lesz semmi gond.
Az vesse rájuk az első követ, aki a GeometryWorksöt és a WaveWorksöt valaha is sikeresen beépítette egy játékba. Na ugye... Ők legalább megpróbálták. Ez dicsérendő inkább. Majd kielemzik, hogy miért nem jött össze.
-
#5497
Abu85
HÁZIGAZDA
huskydog17
#5490
Abu85
HÁZIGAZDA
válasz
huskydog17
#5490
üzenetére
Az NVIDIA a GameWorksöt nem véletlenül vezette be. Nagyon sok fejlesztőnek korlátozott az anyagi tőkéje, és a GameWorks esetében kínálnak kész effektet, amelyeket csak be kell építeni és még egy rakás pénzt is adnak hozzá. Nyilván a GameWorks hátránya, hogy ha nem sikerül integrálni, akkor nem sikerül. Nem tud az adott fejlesztő semmit sem tenni, hogy működésre bírja a rendszert, mert korlátozott az idő a megjelenésig.
Azt nem hiszem, hogy a CDPR megbánta a döntését. Elvették az NV-től a pénzt és befejezték a játékot. Aztán persze a tervekhez képest nem úgy néz ki, kivettek belőle egy csomó GameWorks effektet, illetve a végén már a GPU-s PhysX rendszert is eltávolították, de a játék kész, és ennyi ami számít.A fejlesztők alapvetően nagyon jó munkát végeztek a játékkal. Addig a pontig, amíg azokat az effekteket kapcsolod be, amiket ők terveztek és teljes egészében kontrolláltak nagyon jó a port. A többire pedig nincs ráhatásuk, ezek zárt middleware-ek, így csodát nem lehet velük tenni. Valószínűleg kapni fognak egy ideig a médiától, hogy mekkora butítást lőttek, de most nehéz a médiának megmagyarázni, hogy itt azért ezt a programot működő formában kell kiadni a játékosoknak, márpedig alapvetően megnehezíti a munkát, ha egy integrálásra váró effekt vagy eljárás forráskódját nem módosíthatják, vagy esetleg nem is láthatják. Ez mindig ott fog lebegni azoknál a stúdióknál, akik nyílt megoldások helyett zártra szavaznak, mert inkább pénzre van szükségük, mint szaktudásra.
A Rockstar egészen más kategória. Őket nem fenyegeti az a veszély, hogy a fejlesztés végére elfogy a pénz. Ettől sokkal szabadabb döntéseket lehet hozni. Az olyan stúdiókat szintén nem, mint a EA összes, a Square Enix nyugati csoportja, a Rebellion, a Firaxis, a Stardock stúdiók, ésatöbbi. Ők anyagilag jóval stabilabbak, így számukra logikus döntés a nyíltságot és a szaktudást választani a zártság és a pénz helyett. Ezért is tudják jellemzően jól megoldani azt, hogy a játék a terveknek megfelelően készüljön el.
(#5496) Szaby59: Elég sok olyan konzolos játék van, ahol a látótávolság nagyobb, mint PC-n. Van ellenpélda is, ahol a konzolt a fejlesztők wrapperen használják. A konzolon máshol vannak a limitek. A látótávolságot jellemzően a draw call limit korlátozza és ez PC-n a legnagyobb, amennyiben a konzolon tényleg használod a low-level elérést. Ha nem, akkor a konzol sem fog egymilliószor gyorsabban beírni egy parancsot a parancspufferbe.
Pont két olyan játékot nézel, amelyek nem low-level elérésűek konzolon. Nézz mondjuk egy Dragon Age: Inquisitiont. Az minden platformon kínál low-level elérést és ott a látótávolság elég nagy. Még DX11-be is átmentették ezt a látótávolságot, bár itt elég durva a pop-in probléma, de alapvetően ellátsz addig, amíg low-level eléréssel el lehet.Egyébként a látótávolság (ami egyébként így sem rossz) "gondja" a W3-ban simán meg lesz oldva, ha átállnak low-level API-ra. Azt nem mondom, hogy más kimaradt effekt bekerül, mert ott azért több meló lenne. Alapvetően a kiadó is inkább játékbeli tartalomba forgatná vissza a bevétel egy részét, mert az jobban érdekli a vásárlókat.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#5489
üzenetére
A konzolon jellemzően jobb a látótávolság, már amelyik játék nem wrapperen fut, hanem a tényleges low-level elérésen. Nem mindegy, hogy egy rajzolási parancs beírása a parancspufferbe három órajel, vagy egy-kétmillió. Ezért hozza a Microsoft PC-re is a low-level API-t. A DX11 ebből a szempontból egy fos, és ezzel már ők sem tudnak mit csinálni, ahogy senki sem a világon. Ezért cserélik le a DX12-vel.
Tudom, hogy sok dolog ki lett kapcsolva. A végleges programban már nem lesz GeometryWorks, a WaveWorks, GPU-s PhysX a részecske effektekre (Particles & Fluids). Ezek mind ott voltak, de hiányoznak. Ez azonban nem a fejlesztők hibája. Maguk a csomagok annyira zártak, hogy borzalmasan nehéz integrálni őket. Az idő múlásával, ha nem sikerül, akkor ráhagyják, mert az NV-nél is van erre egy büdzsé. Ha azt elégetik úgy, hogy nem lesz eredménye, akkor nem löknek bele még több pénzt, hanem elfogadják, hogy nem sikerült, és fókuszálnak arra, amit sikerült beépíteni, mint most a HairWorks, vagy a HBAO+.
Sokszor lehet azt mondani, hogy a fejlesztők a hibásak, de akkor nem amikor olyat várnak el tőlük, hogy zárt rendszereket próbáljanak integrálni. Komolyan a legjobb példa a valóságból, hogy házat senki sem épít úgy, hogy kapnak egy kész tetőteret, és alá behúznak mindent. Nem véletlenül kezdik az építést az alappal, majd a falakkal és végül a tetővel. Persze lehetne találni olyat aki esetleg bevállalná ezt, de baromira megnehezíti a munkát, és ugyanez igaz a programfejlesztésre is. Önmagában mint felhasználók titeket ez nem érdekel, de mégis mit vártok egy fejlesztőtől, meddig égessék a pénzt, amikor negyedik vagy ötödik nekifutásra sem sikerült a zárt middleware-t működésre bírni? Egy idő után közeledik a megjelenés, és a kiadó nem fogja elfogadni azt, hogy egy-két extra effekt miatt a fejlesztők kérnek még fél évet, vagy plusz egy évet. Mondjuk inkább úgy, hogy a W3 a körülmények áldozata lett. Így is elég komplex program volt, gondolom úgy voltak vele, hogy nem számít, ha hat-hét tervezett zárt middleware nem kerül bele. Azok a játékmenetet úgy sem befolyásolják. A program pedig ezek nélkül még jobban optimalizáltabbnak fog tűnni.
-
Abu85
HÁZIGAZDA
válasz
proci985
#5484
üzenetére
Így van. És ami a W3-at érinti, az ami a fejlesztőkön múlott az jelen esetben jó. Végigcsinálták, nagyjából jól is optimalizálták. Az amire nem volt hatásuk az vagy nincs beépítve vagy nem jó. És akkor előjön az, hogy mennyire van értelme a fejlesztőket felelőssé tenni azért, mert totál feketedoboz jellegű rendszereket képtelenek voltak jól integrálni. Itt nem velük volt a baj, és ez látszani is fog a játékon. Amint kikapcsolod azokat az effekteket, amelyeket szimplán a konstrukcióból eredően nem tudtak optimalizálni, nagyon jól fog futni a játék.
A látótávolság pedig magának a DX11-nek a problémája. A Microsoftot kell ütni érte, hogy szar az API. A fejlesztők csak próbálják tartani az ideális draw call értékeket. Semennyivel sem jobb kiadni egy játékot, mint a Dying Lightot és egy későbbi patchben limitálni a látótávolságot, azzal, hogy bocsi, de mégse működik az eredeti elképzelés. -
Abu85
HÁZIGAZDA
válasz
#85552128
#5479
üzenetére
A DX12 sem lesz csoda. Oké eltűnik az overhead, így a látótávolság, illetve a szimuláció részét nem képző objektumok száma növelhető. Nyilván ez a W3-ra is igaz lesz, hiszen ez a játék is küzd attól, hogy 10x-es a rajzolási parancsok többletterhelése DX11-ben, mint low-level API-val. Nyilvánvaló, hogy főleg ez fogja korlátozni a látótávolságra vonatkozó beállításokat, illetve a növények mennyiségét. Ezzel ma nem tudnak mit csinálni.
A zárt effekt egy másik lapra tartozik. Az nem egy API-val kapcsolatos probléma. Az egy döntés, ami vagy bejön vagy nem. Ha úgy veszed akkor a végeredményben lehet úgy gondolni rá, hogy nem vesztesz vele semmit. Ha nem működik, akkor nem lesz benne a végleges játékban. A GameWorks esetében főleg az NV pénze áll benne, vagyis nem az adott fejlesztő büdzséje került elégetésre. Nyilván valamennyit az adott stúdió is belerak, de közel sem annyit, mint amennyibe kerülne egy saját rendszer kidolgozása. Mondjuk utóbbinak az előnye, hogy nagy eséllyel működne, de ha valami gondja van, akkor minimum javítható.(#5482) Szaby59: A rajzolási teljesítmény a konzolon nem gond. PS4-en egy rajzolási parancs beírása a parancspufferbe mindössze három órajel a GNM API-val. Ugyanez DX11-en nagyjából kétmillió órajel. A DX12-ben ezt csökkentik 10-20 órajel közé. Világosan látszik, hogy miért nem rajzolhatsz akármekkora távolságra. Majd az új API-k ezen javítanak. Ez az egyik dolog, ami tényleg nem a fejlesztők hibája.
GameWorks nincs konzolra. Fel sem merül, hogy ott olyan kódot használjanak, amelyet nem tudnak optimalizálni. Ergo semmiben nem határozza meg a két konzol azt, hogy melyik GameWorks effekt kerül beépítésre a PC-s portba és melyik nem.(#5481) TTomax: Nem az a probléma, hogy nincs erőforrás ténylegesen megírni egy komplett rendszert, ami működő. Ezt konzolra minden fejlesztő megteszi lassan pár éve állandó jelleggel.
A PC problémája igazából az, hogy sok az olyan komponens, amelyet semmilyen formában nem tudsz befolyásolni. Például az API és a driver modell, amit érdemes egybevenni. Van egy programod, amelyet ezen futtatsz, és tulajdonképpen a driver csinál valami csodát, hogy jó legyen a hardveren. Na de ha nem jó, akkor mit tudsz tenni? Igazából nem sokat. Semmilyen lehetősége nincs a fejlesztőnek megkeresni a hibát, amely a gondokat okozza, mert nem tudja profilozni a meghajtót. Tehát van egy kód, amelyben elvileg nincs gond. A driver valamit elront, és igazából a programozónak fingja nincs róla, hogy mit. Ekkor jönnek a megbeszélések, hogy hol a hiba. A gyártó és a fejlesztő összeül elemezni, és arra jutnak, hogy ez bizony az API hibája. A fejlesztő elmegy az API biztosítójához, ahol kiderül, hogy márpedig a gyártó a bűnös, azok a szemetek még hazudnak is. A gyártó és az API biztosítója esetleg még összeül, és megegyeznek abban, hogy itt csak a fejlesztő lehet a hibás, néznek egymásra, hogy mégis mi a fasz baj van ezekkel az emberekkel... Na ez az iparág legnagyobb hibája. És akkor kezdődik a foltozgatás, hogy legalább egy picit működjön a program, de valójában senki sem tudja igazán, hogy hol a hiba. Ha a gyártó és a fejlesztő nincs szoros kapcsolatban egymással, akkor talán rá sem jönnek, mert a gyártó a program profilozásánál látja, hogy mi történik a driverben, és még annak a forráskódjával is tisztában van, de a program forráskódják már nem látják. A fejlesztő pont a program forráskódjával van tisztában, de a driverét már nem látják. Aztán az ilyen helyzetek jellemzően megoldódnak úgy, hogy a gyártó visszaad a fejlesztőnek egy forráskódot, hogy ezt írják be és elvileg jó lesz. Aztán később azon megint módosítanak, és kezdődik a buli újra. És a gond ott van, hogy egy hibajavítás hónapokig is tarthat, ami miatt előjön a kérdés, hogy megéri-e bizonyos effektek fejlesztésébe invesztálni, ha ekkora az esélye annak, hogy végül úgy sem fog működni.
MultiGPU dettó. Meg van határozva, hogy mire kell ügyelni, hogy működjön a kényszerített AFR. Megírnak erre egy elvileg jó motort és nem működik. Mindenki csak néz előre, hogy na mi lehet a baj, és megint pitiáner dolgokra mennek el olyan erőforrások, amelyeknek meg lenne a helye. Hogy kevesebb az AFR-t támogató játék manapság? Csodálkoztok? Ki garantálja, hogy működni fog az AFR optimalizálás? Senki. Ilyen szituációban mégis miért lehetne cél az, hogy ebbe invesztáljon egy fejlesztő.
Ezek azok a dolgok, amik miatt a fejlesztők ennyire akarják a feketedobozok eldobását. Hogy lehetnek-e hibák low-level API-val? Hogyne, de nagy különbség lesz, hogy ezeket leprofilozzák, és kijavítják, anélkül, hogy hetekig megbeszéléseket folytatnának a gyártókkal, a szabványalkotókkal, és még az isten tudja kivel. MultiGPU dettó ugyanez. Lehet gond vele low-level API-val? Naná, de ki lehet javítani.Az a poén, hogy ha egy fejlesztőt megkérdezel, hogy mit tart a low-level API-k előnyének, akkor sokan nem a kisebb overheaddel jönnek elő, vagy a hasonló dolgokkal, amelyeket az érintettek esetleg hype-olnak, hanem azzal, hogy kiszámítható lesz a működés. Látják, hogy a program hogyan fut a hardveren, és nincsenek elrejtett szálak, amelyeket nem lehet leprofilozni, vagy olyan forráskód, amelyet nem látnak. Minden hibára célirányos megoldást lehet találni, és nem kell új ösvényeket vágni, amelyek vagy működnek vagy nem. És erre már van erőforrás, mert kiszámíthatóvá vált a rendszer. Tudod a buktatókat, és nem egy előre nem várt tényező fogja megakadályozni, hogy végül az effekt ott legyen a játékban.
-
Abu85
HÁZIGAZDA
Elég sok újítás a GameWorksból való. Egyiket sem tervezték konzolra. Azt nem értem, hogy miért várjátok el ezektől a fejlesztőktől, hogy minden szuper legyen, amikor arra kényszerítik őket, hogy előbb tetőt építsenek a háznak. Ez egy baromság, és ezt az eredmény több esetben is bizonyította.
Érdekes, hogy aki alapoktól a tetőig építkezik, az minden eltervezett effektet tökéletesen beépít a játék összes portjába, és furcsamód a portok minősége is elég jó.
Alapvetően két eset lehetséges. Vagy mindenki hülye, aki GameWorksöt használ, vagy tényleg igaz, amit a fejlesztők mondanak egy ideje, hogy nem lehet úgy hatékonyan játékot fejleszteni, hogy a kész "fekete dobozok" alá behúzod a motort. Lehet ennek tapsikolni, hogy ez milyen fasza dolog, meg annak is, hogy a kompatibilitási problémák miatt a tervezett effektek jó része fejlesztés alatt eltűnik.
Ez a valódi problémája a feketedobozoknak. Minden formájuknak. Mindenki döntse el magában, hogy ez jó-e a PC-nek vagy sem.
. IOMMU-van a WDDM 2.0-ban. És azt sem tudja támogatni egyetlen dedikált GPU. Emellett azt hiszik, hogy a TIER szinten az egyes eljárásokon a bekötésre vonatkoznak. Hát nem.
![;]](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.
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7500F 32/64GB DDR5 RTX 5060 8GB GAMER PC termékbeszámítással
- Xbox one X konzol 1Tb
- HIBÁTLAN iPhone 16 Pro 128GB Desert -1 ÉV GARANCIA - Kártyafüggetlen, MS3945, 92% Akkumulátor
- 154 - Lenovo LOQ (15IRX9) - Intel Core i5-13450HX, RTX 4060
- Apple iPhone 15 128 GB Kék 12 hónap Garancia Beszámítás Házhozszállítás
Állásajánlatok
Cég: ATW Internet Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest