Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
A BF4 AFR módja nem elég jó. Egyedül Mantle alatt van mindig skálázódás, de DX alatt vannak helyzetek, ahol egyszerűen a kényszeres AFR által kínál QoS nem teszi lehetővé, hogy jó legyen. Se az SLI, se a CF nem skálázódik megfelelően.
Régóta téma már, hogy az API-ból kellene direkt elérést adni mindegyik GPU-ra, de ez egyelőre szabvány szinten még csak álom. Most kezdődött el valami OpenGL-en, mert az NV és az AMD összeállt, hogy elkészítsék a GLX_AMD_gpu_association kiterjesztés ARB változatát, de minimum lesz belőle egy EXT változat. Ez lesz az első szabványosítási kísérlet a jó QoS-es multi-GPU-ra.A BF4-ben láthatók a limitek. Még a direkt optimalizálás nélküli Mantle multi-GPU is veri a DX-es AFR-t.
-
Abu85
HÁZIGAZDA
Valójában nem a hardverekkel volt a gond. Az API korlátozta a lehetőségeket. Később, ha elterjednek a modernebb API-k, akkor vissza lehet térni az eredeti koncepcióhoz. Esetleg next gen konzolokra meg lehetne csinálni az extrákat, de az UE4 fő terepe inkább az ultramobil piac lesz, tehát ennek rendelik alá a fejlesztéseket is. A licencelést is ennek megfelelően lőtték be.
Egyébként mindegyik nagy motorlicencelésre szakosodott cég a mobil irányba megy el. Egyszerűen a napnál is világosabb, hogy a nagy kiadók házon belül fejlesztik a motorokat. A megszokott területeken kvázi megszűnt a felvevőpiac. -
#2058
Abu85
HÁZIGAZDA
Firestormhun
#2056
Abu85
HÁZIGAZDA
válasz
Firestormhun
#2056
üzenetére
Ez az eredeti demó, csak ennyire le kellett butítani a motort. Úgy nem adhatsz ki játékot, hogy bármelyik pillanatban elsötétülhet minden. Nagy ötlet volt az eredeti GI, jó volt a minősége, de ha nem stabil, akkor dobni kell. Helyére a Lightmass került, de a motor alapértelmezetten már Enlightent használ, csak az Elementálban ezt már nem cserélték be, felesleges is lenne.
Az Unreal Engine 4-be számos korábban tervezett effekt nem került bele. Egyszerűen vagy nem volt stabil, vagy kevés volt a 8 UAV/pipeline.
Ezt az Epic is megsínylette. Csúszott a fejlesztés és el is kellett adni a GoW jogokat az életben maradáshoz. -
Abu85
HÁZIGAZDA
válasz
szasanyi
#2055
üzenetére
Azzal nem lesz gondjuk. Engem jobban izgat, hogy a PC-re mit találnak ki. Ha reálisan nézzük, akkor GI-ra két értékelhető alternatíva létezik ma.
Valszeg a legtöbb játék az Enlighten új verzióját fogja erőltetni. A mostani CPU-s számítás még többletterhelés és extra késleltetést jelent, de GPGPU-val is megoldható. Most, hogy az ARM megvette őket, biztos átrakják DC-re vagy OpenCL-re. Asszinkron compute mellett szuper sebessége lesz.
Jobb minőséget ad az LPV, de számításigényesebb is, viszont cserébe egyszerűsíti a volumetrikus fényszámítást.
Opció esetleg a VPL, de ez a jellemző leképzőkhöz nem ideális.
A SVOCT szerintem álom. Maximum az SVPRTCT mehet, de az nem minden architektúrán oldható meg jól. A 3D textúra mérete sem ideális. -
Abu85
HÁZIGAZDA
Meglehet érteni őket. Azért az nem jó dolog, ha hirtelen összeomlik a rendszer és sötét lesz a játék. [link] - itt van a különbség. Sajnos nem stabil az effekt, és hát láthatod, hogy ha leáll, akkor az fáj a színekre nézve.
A Sony csinálta meg egyedül az Voxel Cone Tracinget stabilan, valós időben. Az tényleg jól működik, persze ők nem az Octree-re mentek rá, hanem eleve a PRT-re. PS4-en ez lesz a brutáleffekt az érkező exkluzívokban. -
Abu85
HÁZIGAZDA
Elég sok a bugreport, szóval van benne programhiba. Majd idővel javítják.
Amúgy túl sok értelme nincs a tesztnek, mert az Elementalban olyan effektek és eljárások vannak, amik már nem alapértelmezettek a motorban. Azóta ezeket újakkal cserélték. SVOCT-vel lett volna értelme, de azt kivették sajnos. Látható, hogy visszaesett a minőség az eredeti videóhoz képest. -
Abu85
HÁZIGAZDA
Nem a stabilitás a fő probléma. A kiszámíthatatlanság, ami ma a fejlesztőket a low-level API felé tolja. Azért nagy az érdeklődés egy ilyen koncepció iránt, mert ma a DX-ben az a legnagyobb gond, hogy megjósolhatatlan a működése. Annyira segíteni akar, hogy árt a fejlesztéseknek.
Sokszor kapják a fejlesztők, hogy nem tudnak többszálú kódot írni, így nem tudják kihasználni a többmagos processzorokat. Ez szinte általános nézet a PC-ben, hogy erre a piac képtelen. Eközben konzolon baromira jól kihasználják az erőforrásokat. A tudás és a tapasztalat tehát megvan, csak nincs normális többszálú végrehajtása az API-knak, illetve a driverekre annyi munka a szakad, hogy rengeteg rejtett szál akadályozza a programszálakat. -
Abu85
HÁZIGAZDA
A stabilitási gondok 95%-a arra vezethető vissza, hogy a fejlesztőnek szüksége van a sebességre és egyszerűen bevállal olyan optimalizálásokat, amelyeket meg lehet csinálni DX alatt például, de az MS határozottan nem ajánlja, mert nem garantálható az API stabilitása olyan körülmények között.
Amiket felsoroltál azok mind attól vannak, hogy az aktuális API-k még ma is úgy kezelik a VGA-kat, mintha TnT-k és Voodoo-k lennének. A driver pedig megpróbálja ezt a modellt olyan formába önteni, ahogy a mai hardverek valóban működnek.
Az új low-level API irányzatok lényegében csak azt teszik, hogy eldobják a régi kötöttségeket és úgy tekintenek a hardverekre, mint általános processzorok. Ennek értelmében egy modern API annyit tesz, hogy shadereket futtat a hardveren és kész.
-
Abu85
HÁZIGAZDA
Szerintem a PC-t fel kell segíteni olyan technikai színvonalra, amivel a két új generációs konzol rendelkezik. A fejlesztőknek első a konzol, és minden kutatást arra végeznek. Abból pedig átjön a cucc PC-re, de ha nincs meg a technológiai alap ehhez (low-level API, dedikált hangprocesszor, HSA-szerű integráció), akkor a PC maximum a mobilokhoz készített port grafikailag feljavított verzióját kapja meg.
Az persze igaz, hogy AMD jobban érvényesül, ha a PC megkapja a konzolos új generációs tartalmakat. Az NVIDIA eközben jobban érvényesül, ha inkább mobil portokat kap a PC GameWorks és GPU PhysX effektekkel kiegészítve. Ez a felfogás a két cég szoftveres fejlesztésein egészen világosan látszik. -
Abu85
HÁZIGAZDA
Ez nem értékrend. Az természetesen látszik, hogy az AMD elsők akar lenni az egyes API-k kihasználásában és támogatásában. Ezt évek óta teljesítik is. De ettől még ez nem értékrend, hanem a fejlődés elősegítése. Aki nem így tesz az fékezi a fejlődést. Szóval ez itt egy kötelesség az adott cégtől, hogy a piac ne egy helyben toporogjon, hanem fejlődjön. Aztán persze lehet magyarázni, hogy az csinálja jól, aki nem fejleszt, mert csak, de ettől még a szabványba az egyes funkciók akár követelményként, vagy akár opcionálisan nem véletlenül kerülnek be. Azokat megszavazzák a GAB/Khronos tagok, ráadásul legalább 4-5 évvel a bekerülés előtt, tehát meglepetés senkit sem ér.
-
Abu85
HÁZIGAZDA
Igen. Mostantól még kevésbé lesz meg a best buy termék, mert rengeteg szubjektív tényező jön be. Én arra gondoltam a változások mellett, hogy az értékelés megmarad az objektív szempontok szerint, de a szubjektív tényezőket pár folyamatosan frissülő bejegyzéssel az olvasók elé tárjuk. Ennél jobb rendszer sajnos nincs.
-
#1973
Abu85
HÁZIGAZDA
ricshard444
#1971
Abu85
HÁZIGAZDA
válasz
ricshard444
#1971
üzenetére
Én ma már nagyon leegyszerűsítem a kérdést. A következő tesztplatformban is ez lesz benne. Itt már egységesség nem lesz, mert alapjaiban különböznek az architektúrák. Amit nézni kell, hogy az extrák közül NVIDIA PhysX és TXAA a fontosabb, vagy az AMD TrueAudio és Mantle, vagy az Intel PixelSync.
Mindhárom cégnek meglesz a játékfejlesztői támogatása ezeknél a technológiáknál. A hardverek teljesítménye eléggé közel van egymáshoz azonos árszinten, így az extrák eldöntik a választást. -
Abu85
HÁZIGAZDA
Itt sosincs filozófiai felfogás. Legalábbis a tervezésnél biztos nincs, mert eleve a termékekkel piacokat célzol és nem filozófiai irányzatokat.
Az AMD és az NV között ma az a különbség, hogy pár éve egy válaszút elé kerültek. Az egyetlen dolog ami világos volt, hogy a PC-s VGA-piac nem viheti a hátán a termékportfóliót, mert szenvedni fog. A termékek eladhatók ide, de biztos bevételt kínáló és/vagy növekvő piac kell. Az utat mindketten kiválasztották. Az AMD berakta magát a konzolokba. Legalább 8 évig biztos bevétel ráadásul OEM konstrukcióban. Az NV kiszemelte magának az ultramobil boomot, ami nem olyan stabil bevétel, mert sok a konkurens, viszont masszívan növekvő piac.Ez itt tiszta üzlet. Az architektúra karakterisztikáján is látszik, hogy ultramobilba vagy konzolba tervezték.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#1907
üzenetére
Először is tudni kellene, hogy mit tud majd az új DX. De ha feltételezzük, hogy legalább képes arra, amire a base funkcionalitású Mantle, akkor szerintem a szabványos az előnyösebb (a szabvány miatt
). Az viszont nem kizárt, hogy páran maradnak a Mantle mellett. Legalábbis azok a fejlesztők nagy valószínűséggel nem hagyják el, akik saját idejükből részt vettek a fejlesztésében. Ők amolyan saját gyereknek tekintik ezt. -
Abu85
HÁZIGAZDA
válasz
Casanova*
#1902
üzenetére
A Mantle-t azért fejlesztik, mert a fejlesztők igényelték. Ezután addig fogják fejleszteni, amíg ez az igény megmarad. Alapvetően a Mantle állandó fejlesztése az AMD számára nem nagy költség. A grafikus üzletág szoftveres R&D-jének nagyjából 1-2%-a. Ahol a Mantle költséges az a fejlesztői oldal, mert ami eddig a driverben, illetve az API-ban volt annak most a programban kell lennie. Ebből a szempontból az a kérdés, hogy a nagy támogatók, mint a Frostbite Team azután, hogy az R&D-jük 70-80%-át is elköltik majd a Mantle-re úgy gondolják-e, hogy jobb a szabványos modern API, vagy inkább maradnak a Mantle mellett, vagy esetleg belefér mindkettő. Ettől a kérdéstől függ a Mantle további fejlesztése. Hacsak a Frostbite Team megmarad támogatónak, akkor az már megéri.
-
Abu85
HÁZIGAZDA
Hogy legyen szakmai is kicsit kutattam a multi-GPU jobb kihasználása után. Na most nem olyan tragikus a helyzet, hogy ehhez Mantle kelljen. OpenGL-ben már van egy WGL_AMD_gpu_association kiterjesztés, ami a közvetlen elérést biztosítja a hardverekhez. Ha jól értelmezem, akkor ennél a Mantle csak annyiban több, hogy egy GPU partíció képes egy másik partíció memóriájába írni. Bár ez OpenGL-ben kicsit necces lehet, de az szerintem megoldható, hogy az egyik GPU a másik frame bufferébe írjon adatot.
Az Nv-nek is van egy WGL_NV_gpu_affinity kiterjesztése némileg eltérő működéssel. Sajnos csak Quadro kártyákra.
-
Abu85
HÁZIGAZDA
Az erőforrások explicit elérése megoldható bármilyen gyártón. A Mantle semmi extrát nem kér a hardver oldalán. Tisztán szoftveres technológiáról van szó. Akár beépülhet a DX-be, vagy az OGL-be is, csak egyelőre le se szarja az igényeket az MS és a Khronos. A hardverek egytől-egyig alkalmasak a jobb alapokra épített több GPU-s kezelésre.
-
Abu85
HÁZIGAZDA
Komplikált kérdés. Leginkább jelenettől függ, illetve nem érdemes az AFR-es CF/SLI-t a Mantle megoldásával összehasonlítani. Óriási különbség van aközött, hogy a fejlesztő explicit hozzáférést kap az erőforrásokhoz kiváló QoS mellett, vagy csak kap egy AFR-t (CF/SLI), ami felett leginkább nincs kontrollja és közvetve lehet rá felépíteni egy esetlegesen működő rendszert igen gyenge minőségű QoS-sel.
A Mantle koncepciójával úgy lehet használni több GPU-s kiépítést, hogy az nem ad a működéshez extra késleltetést, és a programban direkten kezelhető minden probléma, ami rossz skálázást vagy mikroakadást okozhat. Olyan extrém gépek is építhetők, amelyekben nyolc GPU is van, és ezeket lineárisan lehetne skálázni, továbbá nem éreznéd a több GPU mellékhatásait az egy GPU-s rendszerhez képest.
-
Abu85
HÁZIGAZDA
válasz
#35434496
#1863
üzenetére
A 4,8 GHz. A Mantle jelenlegi implementációja erre a DX kódhoz képest nagyjából 4%-ot ha rápakol még maximum. Legalábbis egy 290X és 780 Ti kaliberű VGA-hoz ez az órajel és proci elég. A Mantle előnye ilyenkor csak az alacsonyabb késleltetésben nyilvánul meg, de az nem mérhető. Ha ezeket a kártyákat megduplázod, akkor már erősebb lesz a procilimit.
-
Abu85
HÁZIGAZDA
A PS4 (és az X1) a TressFX 2.0-t kapta meg. Annak a szimulációja jobb, mint az első verzió. Sokkal jobban kezeli az extrém gyorsulásokat, ezért hat másképp a mozgás. Nem olyan irreálisan nyúlik el a haj. Ezt egyébként át lehet menteni PC-re DX11-re. Nem tudom, hogy akarják-e, de technikai akadálya nincs.
-
Abu85
HÁZIGAZDA
válasz
#35434496
#1856
üzenetére
A TressFX-re én sosem mondtam azt. Ha megnézed én voltam az egyetlen itthon, aki leírta, hogy szabványos effekt, pedig más fórumokon már ment a sírás.
A TressFX akkor lenne gondban NV-n, ha nem csak Lara hajára csinálták volna meg. Na az úgy már nem futna náluk, mert az már 4 UAV összesen. A játék más effekjei pedig elvisznek hatot, amivel rögtön 10 UAV van, de az NV 8-at támogat.
-
#1854
Abu85
HÁZIGAZDA
TechArtist
#1844
Abu85
HÁZIGAZDA
válasz
TechArtist
#1844
üzenetére
Technikailag mindegy. A Nixxes elmondta, hogy őket elsősorban az asszinkron compute és a kiszámítható shader újrafordítás érdekli. Nem valószínű, hogy olyan CPU-limitet okozna a Thief, hogy ebből sokat profitál a Mantle. De egyébként az API extra effektekre is használható, ami DX-ben esetleg nem megvalósítható.
(#1845) stratova: Elég sok TrueAudio hangeffekt elérhető lesz szimplán CPU-s számítással. Szóval valamennyire mindenképp beleszól majd a játékmenetbe. Ezért kérnek brutálizmos kétmagos CPU-t minimum, mert az átlag játékokhoz képest kétszer több procierőforrást használnak el a hangra. Ha nincs elég erős procid, és TrueAudio blokk sincs, akkor búgni meg sípolni fog a hang.
-
#1842
Abu85
HÁZIGAZDA
Malibutomi
#1841
Abu85
HÁZIGAZDA
válasz
Malibutomi
#1841
üzenetére
Aki virágokkal zombikra akar lőni és fordítva.
-
#1840
Abu85
HÁZIGAZDA
TechArtist
#1839
Abu85
HÁZIGAZDA
válasz
TechArtist
#1839
üzenetére
Tavaszra is van még egy játék bónuszként
-
Abu85
HÁZIGAZDA
válasz
#35434496
#1817
üzenetére
Nehéz megmondani, mert erről sosem szoktak beszélni a cégek. A core funkciókat nem írják sokan sehol sem. Van egy D3D és egy OGL csapat, illetve ha több API-t támogatnak, akkor azokat is általában külön csoport végzi. A tesztelésen és a profilozáson dolgoznak viszonylag sokan. Ha a szinte minden feladatot beszámítunk, akkor leginkább 100 fő körül lehet a létszám. Ez általánosítható más cégre is. Egy prémium drivertámogatáshoz ennyi hardverrel mindenképp szükséges ennyi ember.
-
Abu85
HÁZIGAZDA
válasz
#35434496
#1815
üzenetére
Dollármilliárdos szintű pénz. De itt a büdzsé, amit a fejlesztésre szánnak fontosabb. Ha a grafikára vetítjük le az egészet, akkor az AMD és az NV költ a legtöbbet, míg az Intel kevesebbet. Ezen belül is a driver viszi a legtöbb pénzt. Viszont a Mantle ennek alig 1-2%-át teszi ki az API-val együtt is. Ami sokba kerülhetett az az R&D, de azt a PS4 és az X1 API-jávál együtt megcsinálták. Egyedül a validációs rendszer lehet extra költség. A driver oldalán pedig csak egy vékony felület kell, ami engedi a shadereket futni. Nincsenek hazardok, agresszív kötegelések/pufferelések, külön profilok vagy compute-grafika átlapolási rutinok. Gyakorlatilag a Mantle-re havi szinten költött összes pénz nem teszi ki a D3D driver havi szintű költségeinek 10%-át sem.
-
Abu85
HÁZIGAZDA
A pénz belepumpálása leginkább attól függ, hogy meddig igénylik a fejlesztők. Az első körben eleve úgy fejlesztették, hogy tudták kik lesznek benne (DICE, Oxide, Nixxes, Rebellion, CIG, PopCap, Bioware, Visceral, Stardock, Mohawk). Aztán szeptember óta volt már tagfelvétel, ki tudja kik kerültek még be. Épp most is zajlik egy újabb felvételi.
-
Abu85
HÁZIGAZDA
Az még a nagy kérdés, hogy meddig fognak a fejlesztők 2000-5000 batch/frame között maradni a multiplatform címeknél. Az előző generációs konzolok 20k-t is tudtak, az új generáció 40k-t is tud. A Mantle 100k-ra is képes. Előbb-utóbb elfogy a türelem. A fejlesztők elég sokáig vártak, rájuk nem lehetett panasz, de egy PC-s játékos nem fogja eltűrni, hogy PC-n legyen kisebb a látótávolság vagy gyengébb az általános minőség. Ha az MS és a Khronos nem adja meg, amit kérnek, akkor majd egy gyártó.
-
Abu85
HÁZIGAZDA
válasz
BlackSoft
#1771
üzenetére
Inkább csökkenti az API többletterhelését és valóban többszálú leképzést biztosít. A jelenlegi programok ebből a képességéből profitálnak. Ez több fejlesztőnek nagyon fontos dolog, mert túl vagyunk egy konzolgeneráción, és az Xbox 360-on egy-két exkluzív elérte a 20000 batch/frame-et is 30 fps-sel, amikor ezt a sebességet PC-n jó programozás mellett is csak 5000 batch/frame-mel tudjuk hozni. Kivéve persze az olyan vadállat motorokat, mint a Nitrous, de nem mindenki öl az optimalizálásba annyi pénzt és időt mint az Oxide.
Na most itt az új konzolgeneráció, amelyek képesek 40000 batch/frame-re, és PC-n még mindig nem történt semmi előrelépés. Nem mennének bele egy gyártófüggő API-ba a fejlesztők, ha nem gondolnák, hogy a szabvány már a PC versenyképességét veszélyezteti. -
Abu85
HÁZIGAZDA
válasz
#35434496
#1754
üzenetére
A DX-et 2000 batch/frame-re ajánlják maximum. Ez meg minimum 15000 batch/frame-et csinál, de az átlag inkább 50000-et. Nincs azon mit csodálkozni, hogy egy 90-es évek végére szánt hardverekhez tervezett API-val ezek a komplex jelenetek CPU-limitesek.
Ez a fő oka annak, hogy ma már a tartalomkészítők is driverre optimalizálnak. 15 év, nulla előrelépés, az új konzolok meg 40000 batch/frame-et tudnak. -
Abu85
HÁZIGAZDA
Itt vannak a marketing slide-ok a Mantle-re. A fejlesztői slide-okon volt több adat. A legnagyobb bottleneck a draw call overhead és a működő multithread hiánya. Ez az amiért a fejlesztők kérték. Aztán másodsorban lényeges előny a GPU memória explicit elérése. Látható, hogy mennyire egyenletes lett ennek használatával a frame time Mantle-lel, pedig még nem is használják hatékonyan. Végül a shader fordítás kigyomlálása. Ez nem mindenkinek fáj ugyanannyira, de gondolom emlékszel a Deus Ex: HR-re. Annak voltak akadásai a shader újrafordítás miatt. A Nixxest például inkább ezért érdekli a Mantle.
-
Abu85
HÁZIGAZDA
Az AMD az API-ról beszélt és nem egy játékról. Az API-ban rengeteg lehetőség van a teljesítmény növelésére: többletterhelés csökkentése, multithread, bindless modell, asszinkron compute, explicit memóriamenedzsment, monolitikus futószalag, state fícsőrök, shader fordítás optimalizálása, asszinkron memóriamásolás, stb. Ezek összessége is használható, de lehet használni csak egy részét is, sőt épphogy béta API-ról lévén szó, talán nem ideális az első implementációba mindent bevetni. A többletterhelés/multithread, a bindless, a shader fordítás és az alapvető memóriamenedzsmentnél egyik új program sem ment tovább. Kvázi elsőre beírt kód.
A Nitrous DX kódjában három ember egy évnyi munkája van, a Mantle pedig egy ember három hónapnyi munkája. Azért ez különbség. -
Abu85
HÁZIGAZDA
válasz
MiklosSaS
#1665
üzenetére
Nem. A Mantle semmilyen driver oldali CF-et nem kínál, és a jelenlegi tervek szerint nem is fog. Ehelyett az alkalmazás közvetlen kontrollt kap a detektált erőforrások felett. Mindenki olyan multi-GPU megoldást implementálhat, amilyet akar, és amelyik jó az adott renderhez.
-
Abu85
HÁZIGAZDA
A PhysX-et mindenki leszarja, azzal nincs baja senkinek, irreleváns dologként tekintenek rá. A CUDA probléma. Például az NV a PhysX für és hair effekteket elkészítette DirectCompute platformra. Azokat támogatja az AMD és az Intel. Működik is az új COD-ban. Nem a PhysX-szel van itt a baj, hanem a CUDA-val. Azt nem akarja senki sem támogatni, és az elmúlt évek alatt jól kivégezték a konzumer szinten, tehát most már nem fognak hátramenetbe kapcsolni a konkurensek.
Ha a HSA-nak adná oda az AMD a Mantle-t, akkor olyan, mintha nem adná oda az NV-nek és az Intelnek. Utóbbi két cég sosem fog belépni a HSA-ba, mert az arra szolgál, hogy rázúdítson a piacra egy tucat chiptervezőt. Ez durván növeli a versenyt. -
Abu85
HÁZIGAZDA
Attól, hogy kijön egy SDK még nem változik semmi. Ahhoz, hogy egy konkurens cég támogassa a Mantle-t az kell, hogy egy független alapítvány átvegye a fejlesztését. Az SDK csak annyit jelent, hogy nem kell többet nevezni az AMD partnerfelvételére, hanem csak beütöd az oldalt és töltöd le az SDK-t. Ez a gyártói hozzáálláson nem fog változtatni.
De egyébként nem vagyok meggyőződve arról, hogy a világnak szüksége van egy publikus SDK-ra. A Mantle kontrolláltan lehet hasznára a piacnak. Nemsokára meghirdetik a harmadik felvételit, oda jelentkezhetnek majd a fejlesztők.Szerk.: [link] - már ki is posztolták. Szépen kontrollált környezetben lehet fejleszteni rá.
-
Abu85
HÁZIGAZDA
válasz
SzlobiG
#1607
üzenetére
Ezért nem értem én sem ezt az irányzatot, de ettől még a multis játékosok nagy része csökkenti a részletességet, hogy 100 fps fölött legyen mindig multiban. Nem értem miért, de ha megnézel egy profi játékost, akkor lowra van véve mindene és úgy játszik. Többnyire azért vesz gépet, hogy elérje a 200 fps-t.
(#1608) Malibutomi: A négymagos Inteleken sokat segít a Mantle. Még Full HD ultrán is megdobja azokat egy extra 30%-kal multiban. A hatmagos Inteleken nem dob annyi. Ott 290X mellett is maximum 20%-kal több az ultra multi.
-
Abu85
HÁZIGAZDA
Idén biztos nem jön a 490X. Márpedig idén lesz olyan játék, aminek egy-egy effektje reálisan csak Mantle-ön lesz bekapcsolható. A Frostbite Team mondta, hogy az R&D-jük nagy része a Mantle-re megy.
A 290X-es felhasználók is örülnek. A legtöbb hardcore játékos eleve 100 fps fölé lővi be a rendszert még 290X-szel is. Lásd őt is. [link] - számára a Mantle plusz 60 fps-t jelent. És durva gépje van, csak multis arc és 100 fps fölé paraméterezi a beállításait. Szóval leginkább medium presetre. És még egyszer mondom, a legtöbb hardcore játékos ilyen. A mögöttes koncepciót én sem értem, hogy csúcsgéppel, mi értelme medium preseten játszani, de most mit lehet ezzel kezdeni. -
#1597
Abu85
HÁZIGAZDA
ricshard444
#1596
Abu85
HÁZIGAZDA
válasz
ricshard444
#1596
üzenetére
Mondjuk azt tedd hozzá, hogy leginkább multiban. Single-ben tényleg inkább 10% a bónusz.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#1592
üzenetére
Itt nem a felbontásról van szó, hanem az általános effektminőségről. Régóta tudnánk olyan dolgokat csinálni, amiket a filmekben látsz CGI animációként. Egy dolog miatt nem tesszük meg. Nincs hozzá megfelelő API-unk. De látszik, hogy maga a piac próbál innovatív lenni. John Carmack a megatextúrázással. Berakta, innovatív, de még nem működik. Vagy Tim Sweeney az UE4-nek az Voxel Cone Tracingjével. Berakta, DX alatt nem stabil, így mára kivette, de érzi, hogy merre kellene menni, csak ma még nem tudja megtenni. Bezzeg Capcom. Berakta PS4-re az alternatív implementációt, és eldobta az agyát a piac a Panta Rhei motortól. Ez eddig jó, de hogyan portolod PC-re? És ez felmerült már a Capcomnál is, hogy az új motornál erre nem gondoltak, és ez gond lesz.
-
Abu85
HÁZIGAZDA
A DX kód ledobja az erőforrást. Ezzel küzd a BF4 mióta megjelent. Az januári patch-ek javítottak, de most az új patch-ben nőtt egy picit a DX kód sebessége és megint jönnek a device hung hibák. Többek között nekem is előfordult a hétvégén, pedig két hónapja nem volt ilyenem. A Mantle kód stabil a rendszeremen.
Engem ebben az irányban az érdekel, hogy legyen egy olyan API, amire lehet a konzolról új generációs effekteket portolni. Értem, hogy van más koncepció is, amit az NV csinál, hogy ha valami nem működik, akkor lesz rá OGL- és DX-barát alternatív effekt, de szerintem ez nem reális alternatíva. Egy hardcore PC-s játékos nem fogja elviselni, hogy konzolon szebb lesz xy effekt. Persze a többség le fogja szarni, de a hardcore réteg lázadni fog. Nekik jó lesz a Mantle.
-
Abu85
HÁZIGAZDA
válasz
Casanova*
#1555
üzenetére
Mantle alatt nem romlik a grafika. Van egy bug, ami ködösebb hatást kelt. Ez nem befolyásol semmit. A specular mapok tűnnek még kontrasztosabbnak. Ez valszeg eltérő paraméterezés, de a számítások ugyanazok. Emellett a Mantle alatt olyan helyeken is vannak árnyékok, ahol DX alatt valamiért nem. Ez szembetűnő helyenként, de nem valószínű, hogy ez extra számolást jelent. Valószínű, hogy ez DX alatt is megtörténik, csak valami bug miatt nincs eredménye.
-
Abu85
HÁZIGAZDA
Stabilabb a Mantle kód, mint a DX. A legtöbb helyen az a gond, hogy a tuningot nem vették vissza. Néztem a terhelését. A processzort legalább kétszer jobban használja az új API, és a GPU-n is 40%-os átlagos leterheltségről 70%-ra ugrottam. De a DX elvileg képtelen 60%-nál jobban terhelni egy GPU-t. A CPU-tuningot nekem is vissza kellett vennem, de alapon sokkal jobb. Hozzávetőleg 30%-ot gyorsultam, bár azt hozzá kell tenni, hogy DX eredményeim 3,7 GHz-ről vannak, míg a Mantle mellett a proci alap 2,8 GHz-en ment.
-
Abu85
HÁZIGAZDA
válasz
Casanova*
#1489
üzenetére
Szerintem ezt az NV vs. Linux és magát a Linus fuck off-ot félreértitek. Linus azért mutatott be az NV-nek, mert a vállalat akkoriban teljesen lezárta a hardvereinek a dokumentálását és a specifikációkat. Tehát Linus csak arra reflektált , hogy az NV hozzáállása - tehát nem a támogatása - az open felfogáshoz messze a legrosszabb a piacon.
Te mint egyéni júzer csak telepítesz egy Linuxot és egy zárt drivert és boldog vagy, esetleg nem (![;]](//cdn.rios.hu/dl/s/v1.gif)
). Viszont vannak a zsíros kormányzati megrendelések. Nekik fontos az, hogy a hardverek dokumentálása jól elérhető legyen és ezért támogatják a Linuxot és a mögötte rejlő open dolgokat. Na ez az amiért Linus bemutatott, az NV ezekért a zsíros megrendelésekért semmit sem tesz.A SteamOS csak arra való, hogy ha mész a nappaliba, akkor ne konzolt vegyél.
-
Abu85
HÁZIGAZDA
válasz
Casanova*
#1483
üzenetére
A SteamOS-t a hardcore játékosokat nem fogja megmozdítani. Nem azért vesznek 2000-4000 dolláros gépet, hogy aztán a Windowsos port grafikai szintjének felén futtassák ugyanazt a játékot. A Valve koncepciója szerintem marha jó, csak pont rossz potenciális vásárlóbázist céloznak a reklámmal és az érkező gépekkel.
-
Abu85
HÁZIGAZDA
válasz
WaterWawe
#1435
üzenetére
Az NVIDIA ezt sosem fogja kérni. Legalábbis addig biztos nem, amíg az AMD nem adja ki egy független alapítványnak a fejlesztést. Ez szimpla üzletpolitika. Az NV azt mérlegeli, hogy miképp tudna nyeregben maradni a Mantle mellett és arra fognak majd fejleszteni, de ha beállnak a Mantle mögé, akkor elfogadják azt, hogy az AMD lesz a piacvezető, és másodvonalra kullognak. Ez sosem lehet alternatíva egy cégnek.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#1433
üzenetére
Technikailag rendben van. De sanszos, hogy az AMD ezt mindenkinek oda fogja adni, és nem csak a top stúdióknak. Én a Mantle ötletét nagyon bírom, mert három évvel korábban is írtam itt arról, hogy egy ilyenre lenne szüksége a piacnak. Bár ezt szabványos formában gondoltam, de ettől a szoftver még kell. A Mantle esetében nagyon jónak tartottam, hogy ki lesz kötve, mert azok a fejlesztők kaphatják meg, akiknek van pénzük, és igazán nagy AAA projekteket készítenek. Ha viszont leveszik a Mantle-ről a nyakörvet, akkor félő, hogy a kevésbé tehetősebb fejlesztők nem az extra optimalizálás lehetőségét látják majd benne, hanem a fejlesztési költsége drasztikus csökkentésének a lehetőségét. Utóbbi egyértelműen rossz a piacnak. Ezért kellene ezt mindig pórázon tartani. Szerintem.
-
Abu85
HÁZIGAZDA
válasz
KAMELOT
#1384
üzenetére
Mert az egy hatmagos proci. A BF4 betartja a DX által ajánlott batch countot is, így nem igazán megy 2000 dc/f (egyedi rajzolás/képkocka) fölé. Ennek a DX többletterhelése mellett egy erősebb mag elég. Na most a Mantle ezt többszálúsítja, amitől még mindig nem lesz több a dc/f, de nyolc szálra is szét lehet osztani lineáris skálázódással. Ez hozza az egyik nagy gyorsulást. A másikat a driver szálainak eltűnése jelenti. Ha van 6-8 magod, akkor ez kevésbé érinti a rendszert, mert az OS azért igyekszik szabad erőforrásra ütemezni. Mantle alatt viszont nincs driver szál, tehát nincs olyan láthatatlan folyamat a program számára, ami elvenné az erőforrást.
Nagyon általánosan erős GPU mellett 6-8 maggal 10-30%-os gyorsulás lehetséges, függően a magok teljesítményétől. 2-4 maggal 20-40%-os. -
Abu85
HÁZIGAZDA
válasz
KAMELOT
#1381
üzenetére
Semmilyen terhet nem vesz át a procitól. Dióhéjban eliminálja a driver szálakat, lecsökkenti a többletterhelést és kiszámítható működést biztosít a fejlesztőknek. Ennyi. Megpróbálom a lehető legérthetőbben leírni. A legtöbb gyorsulás abból ered, hogy a fejlesztők szabadon hozzáférhetnek a látható erőforrásokhoz, és nem mondja nekik valamilyen rejtett körülmény, hogy "Bocs az mégse szabad. Ja hogy már késő? Majd legközelebb talán sikerül összehozni (trollface)...". Aki odament az AMD-hez és kérte a Mantle-t, annak ebből lett elege. Meg persze abból, hogy 2007 óta pofázzák ezt a problémájukat az MS-nek és semmi.
-
Abu85
HÁZIGAZDA
Nem akarok nagyon ebbe a PC-s optimalizálásba belemenni, de ha megnézzük az Ubisoft Kiev felhozatalát, akkor igazából soha az életben nem adtak ki normálisan optimalizált játékot PC-re. Egyrészt ebből tökéletesen kikövetkeztethető, hogy valami nem működik jól náluk. Vagy kevés az ember, vagy hiányzik a szaktudás, vagy az Ubi kevés pénzzel látja el őket. Esetleg ezek kombinációja. De igazából az NV-vel és az NV nélkül is rossz portokat készítettek, tehát ezért nehéz lenne mást hibáztatni, mint az Ubisoft Kievet. Esetleg, ha tényleg kevés pénzt adnak nekik, akkor lehet mutogatni az Ubisoft vezetőségére.
-
-
#1182
Abu85
HÁZIGAZDA
TechArtist
#1154
Abu85
HÁZIGAZDA
válasz
TechArtist
#1154
üzenetére
Ez nem tartalmazza a Mantle-t és a TrueAudiót. Akárki akármit állít nincs benne. Majd írok róla, ha olyan driver lesz, amiben benne lesz.
-
Abu85
HÁZIGAZDA
Csak nem fogod tudni belerakni egy játékba. Amíg egy kockás terepen mutogatják addig oké, de a játékban kötelező, hogy a GPU még abban a jelenetben végezzen a számítással, ami szinkronizálva lesz. Mivel erre dedikált grafikus vezérlővel nincs garancia, így az egész megmarad egy kockás terepen futó dologként.
Ezek egyébként nem újdonságok. Évek óta léteznek, de mindig ugyanaz a gond. A lassú buszon bekötött GPU nem tud a szinkronizációra elkészülni. Egyébként a fejlesztők is ezt látják jövőképnek. Ezért kértek megosztott virtuális memóriát a konzolokba, hogy játékokba is be lehessen építeni ilyen fizikai modellezéseket. PC-n ezt maximum szinkronizáció nélkül lehet megoldani, de az nem több a mai particle rendszereknél.
Ezt a rendszert az NV is leginkább az ARM-os APU-ihoz szánja. -
Abu85
HÁZIGAZDA
Igen ez a PC gaming érdekes kérdés. Nyilván fűződik hozzá érdek még a fokozatosan csökkenő piaci igények mellett is, de annyira korlátozó már a szabvány API-k funkcionalitása, hogy az új konzolok effektjeit értelmetlen, vagy lehetetlen rájuk portolni.
Az AAA játékok esetében a megjelenítés erősen filmekhez használ CGI-ból fog építkezni. Nagyjából a mai konzolok elég erősek ahhoz, hogy a filmekhez használt motion blur effektet átvegyék és ne kelljen használni a trükközős megoldásokat, amiket sokak inkább kikapcsolnak. De a GI-t és az árnyékok leképzését is lehet mondjuk voxel cone tracingre építeni. Ezektől majd leesik az állad, viszont DX-en és OGL-en nem lesz.
A filmes motion blurt az érkező StarSwarm technikai demón meg tudod majd nézni. Semmi értelme ugyan, de leportolták DX-re.
-
Abu85
HÁZIGAZDA
Minden cég arra megy, ahol leginkább nyerhetnek a stratégiájukkal. Például a konzolok miatt az AMD-nek sok dolgot összejött, hiszen elindíthatnak egy puccsot a PC-n. De ugyanígy ki lehet emelni, hogy több kiadó is kijelentette, hogy 2014-ben a konzolok után az Android lesz a második, és a PC a harmadik célplatform. Tehát a fókusz megint kezd megváltozni. Ez például az NVIDIA számára kedvező, mert nekik leginkább az volt a kérdés a jövővel kapcsolatban, hogy miképp hozzák át a felhasználóikat Androidra. Hát a piac megoldja helyettük.
Aztán ott a SteamOS, ami képes lehet a nappaliba költöztetni a PC-t.
Rengeteg alternatíva van, és mindenki azokat az irányzatokat fogja majd meg, ahol jók lehetnek, és nem azt, ahol már ma vesztettek. -
Abu85
HÁZIGAZDA
Ha megnézed a CES-es előadásokat, akkor a stratégia minden cégnél különbözik már. Nagyjából látható, hogy ki merre megy. Kivéve az Intelt.
Az AMD koncepciója egyértelmű. Van egy rakás partnerük a Mantle és a TrueAudio szempontjából. A Windows gaming a fókusz és a konzolokból származó előnyt kell kihasználni. Erre építenek fel mindent.
Az NV más irányból közelít. Nem a gigastúdiók, hanem a kisebb cégek igényeit szolgálnák ki, ahol kevés a pénz jó grafikát csinálni. Erre van a GameWorks. Kattintással is lehet xy effektet rakni a játékba. Emellett az Unreal Engine 4-et mára jelentősen lebutították, hogy az Android lehessen a célplatformja.
Igazából mást kínálnak a piacnak, tehát a közvetlen versenyre nem érdemes majd számítani.
-
Abu85
HÁZIGAZDA
Ha az NV akarna egy low-level API-t, akkor igent mondtak volna helyből Repinek erre az igényére. Írtam már, hogy a low-level API elkészítése nem nagy dolog. Bárki meg tudja csinálni, de ahhoz, hogy ennek értelme is legyen több dologra is szükség van. Egyrészt egy olyan architektúrára, ami elég nagy tudással rendelkezik ahhoz, hogy 4-5 évig ne kelljen hozzányúlni az alapokhoz, másrészt szükséges egy olyan dolog, ami miatt ezt az architektúrát megtanulják a fejlesztők. Mert ez az egész nem megy majd magától. Ez nem DX, vagy OGL. Itt direkten az architektúra működésére kell dolgozni különben nem lesz hatékony a kód.
A fejlesztői igény tehát egy dolog, de a megfelelő kivitelezéshez nem elég. A Mantle is csak a konzolok miatt érdekes, abból építkezik. Másnak alternatív stratégia kell.
-
Abu85
HÁZIGAZDA
Eredetileg a Mantle driver a BF4 patch-csel jött volna. Nem szükséges azt külön meghajtóban szállítani. Mindig január végére volt tervezve az első Mantle driver a Catalystban.
A stabilitás nem olyan kritikus most még. Egyelőre nem optimalizálják a végletekig a kódot. Az Oxide mondta, hogy a sebesség jön out-of-box, szóval egyelőre mindent a stabilitásra helyeznek. Az biztos marad benne tartalék, de ráérnek még kihasználni, ha lesz teljes dokumentáció, meg SDK, meg példák.
-
-
Abu85
HÁZIGAZDA
válasz
daneeeeee
#1059
üzenetére
Repi nem árulja el a gépet. De azt tudom, hogy 144 Hz-es nagy kijelzője van. Valszeg 2560x1440 pixeles. Meg a max beállítás az biztos. Esélyes, hogy két Radeonja van, valszeg két R9 290X.
(#1060) daveoff: Lehet, hogy Kaveri volt a proci, és akkor az IGP is dolgozott a grafikai számítóson. De biztos, hogy volt még mellette két nagyobb dedikált GPU. Egy dedikált GPU-val a 180 fps minimum elég nagy volna.
-
Abu85
HÁZIGAZDA
válasz
WaterWawe
#1050
üzenetére
Igen.
Ezt ők nem így fogják fel. Ha lesz egy Mantle kódja a játéknak, akkor eleve úgy állnak hozzá a DX kódhoz, hogy ami túl körülményes DX alatt azt le se portolják a konzolról. Ezért kérték a Mantle-t. Áthozzák konzolról az effektet és ha be akarod kapcsolni, akkor vegyél hozzá hardvert. A DX meg ott lesz a normál kódhoz, ha a Mantle nem érhető el. Ez összességében nekik kevesebb munkát jelent, mert mondjuk PS4-ről, ami sok fejlesztőnél lesz vezérplatform egyszerűbb Mantle-re portolni, mint DX-re.
A Frostbite Team ezért alakult meg az EA-n belül (vált ki a DICE-ból). Minden Frostbite 3 játékhoz ők végzik a kutatást és portolást. Elsősorban PS4-re és Mantle-re. -
Abu85
HÁZIGAZDA
Írtam a másik topikban, hogy a Steamre már felkerült a StarSwarm demó. Az arra vár, hogy a Valve átmenjen rajta a szokásos tesztekkel és aktiválják. Ennek lesz egy full kész DX11 és egy leginkább alpha fázisú, de stabil Mantle kódja. Ehhez lesz egy driver a héten. Ez ugyanaz a driver lesz (13.35-ös iteráció), ami nekünk van január 12-e óta.
A BF4 patch az EA-től függ. Kész van december közepe óta. Működik, játszanak rajta. Repi gépén 180 fps-sel megy, de nem adja ki addig az EA, amíg a DX kód ledobja magáról a hardvert. Nem akarja, hogy a játékosok mutogassanak rájuk, hogy a Mantle-re koncentráltak és azért nem stabil a DX kód.
-
#1047
Abu85
HÁZIGAZDA
->Raizen<-
#1031
Abu85
HÁZIGAZDA
válasz
->Raizen<-
#1031
üzenetére
A DX11 engedi a mutexeket. Nincs ezzel önmagában semmi baj, csak ezek nem ajánlott funkciók. De ha azt nézzük, hogy ebből sok sebességet szednek össze, akkor érdemes vele foglalkozni. Azt viszont nyilván érzi a Frostbite Team, hogy nagyon sok erőforrásukat felemészti a gyors DX kód, ezért kértek egy modernebb API-t.
(#1032) norb55: Repi mondta a TH interjúban, hogy az NV-hez is odament, hogy csináljanak egy low-level API-t. Ők elzárkóztak ettől. A low-level API elkészítése nem nagy dolog, kb. két év. Abból az irányból problémás ez a modell, hogy a low-level API-hoz ismerni kell a megcélzott architektúra működését. Ha valaki egy ilyen felkérésre azt mondja, hogy nem, akkor azért mondja, mert nincs olyan piac, amiért érdemes megtanulni a célzott architektúrát.
-
Abu85
HÁZIGAZDA
válasz
MPowerPH
#1011
üzenetére
Előbb befejezzük a Kaveri tesztet. Aztán megyünk tovább. Mantle driverünk már van a hónap közepe óta, az fog megjelenni a hónap végén publikus formában. A StarSwarm demó fent van a Steamen és engedélyre vár a Valve-tól.
A BF4 patch technikailag kész van december közepe óta. Az EA viszont addig nem akarja kiadni, amíg a D3D-vel kapcsolatos hardverledobálásokat ki nem javítják. Félnek, hogy az lenne a reakció, hogy a Mantle-re koncentráltak, holott a D3D-t jelölték meg elsődleges kódként.
Maga a probléma megoldása egyébként egyszerű lenne, ha Repi nem ragaszkodna az aktuális D3D teljesítményhez. De mivel ragaszkodik ahhoz, hogy a stabil D3D kód csak alig különbözhet az aktuális instabil D3D kód teljesítményétől, így ez megnehezíti a javítást.Ez a gond egyébként a Frostbite 3 sajátja. Soha senki nem dolgozott olyan terheléssel, amit ez a motor megvalósít. A teljesítményt viszont a D3D API-ban nem ajánlott dolgok használatával érik el. Ezek sok tempót hoznak, de könnyen lehet instabil a kód. Ha ezeket a dolgokat kiveszik, akkor stabil lesz a kód, de a teljesítmény fele odavész.
-
Abu85
HÁZIGAZDA
Multiban több eltérés lehet, mivel sokkal több szabad és egyben használható erőforrása marad a CPU-nak. Nincs egyetlen szála sem a Mantle rendernek, míg a DX-nek 5-7 aktív rejtett szála is van. Nincsenek hazardok sem a driverben és az API-ban, nem kezel külsőleg szinkronizációt. Ha ezek nagyon leküldik az fps-t, akkor a Mantle ilyen helyzetben simán tud kétszeres sebességet.
Az EA-től függ. A kód kész van.
Ma leginkább driverlimit van. De ha egy játék használja az IGP-t a dGPU mellett, akkor könnyen kitalálható, hogy az ellen sima CPU-nak nincs esélye. Ettől persze még így is gyorsul.
-
Abu85
HÁZIGAZDA
Nem igazán a driver ennek a helye. A fejlesztők a DX11 megjelenésével elkezdték rágni az MS fülét, hogy compute mellett hülyeség, hogy a hardvernek csak egy parancslistája van és órajelenként csak egy parancsot fogad. Na most ez máig hiányzik a szabvány API-kból, így a program nem tud itt semmit átlapolni, adja a parancsokat az API és kész. A driverben lehet alkalmazásokra külön megoldani, hogy a compute és a grafikai meló legyen átlapolt. Ezt nehéz megcsinálni, de alapvető optimalizálásnak tekinthető, viszont ha kis átlapolásból mondjuk nagyot akarsz csinálni, akkor az több hónapos meló csupán egy alkalmazásra.
-
Abu85
HÁZIGAZDA
Ez csak akkor szokás, amikor a fejlesztő valami hatalmas butaságot csinál. Sajna van erre példa bőven, de nem általános.
A driverbe a mai modern alkalmazásoknál főleg olyan dolgok kerülnek, mint a grafika és compute átlapolás (erre megy messze a legtöbb optimalizálás) specifikusan az alkalmazáshoz igazítva. Ott a Dirt: Showdown esete. Az azért gyorsult sokat GeForce-on, mert 8 hónapig csak ezen dolgozott egy fejlesztőcsoport. Ez lehetett a legdrágább driverprofil a történelemben. -
Abu85
HÁZIGAZDA
Ha megnézed az Intel és az NV stratégiáját, akkor az nem API specifikus. Az Intel és az NV távolodik a Windows gamingtől, mert marha nagy gyomros nekik a low-level elérés hiánya, ha egy konkurens ehhez hozzájut. A SteamOS-re mennek, mert a Valve open kezdeményezéseket akar. Az NV elveszti a PhysX-et és a CUDA-t is, de legalább nem lesz Mantle. Az NV-nél még az Android is nagyon fontos. Direkt kivettek egy csomó ígéretes technikát az UE4-ből, csak azért, hogy Androidon üzemképes legyen.
A Windows mindenképp érdekes marad, de kockázat is, mert az AMD-nek low-level API-ja van rá. Nem mindegy, hogy egy hardver 30-50%-ig van kihasználva, vagy 70-90%-ig. Ha sokan állnak a Mantle mellé, akkor azzal nem tudnak mit kezdeni. Csak saját low-level API-val lenne esélyük.
-
Abu85
HÁZIGAZDA
Nem. Az NV-n is fognak majd futni. Lesz normális DX11 támogatásuk. Esetleg OpenGL. A játékok egy része gyorsulni fog, míg egy részükből hiányozni fog pár extra effekt, ha nincs Mantle (esetleg meglesz az effekt, de aktiválhatatlan lesz, mert kivégzi a teljesítményt - az Oxide például leportolta DX11-re a Film Quality Motion Blurt, de sokat nem ér, mert 5-8 fps-re zuhan a teljesítmény). A stratégiáknál még elképzelhető, hogy bizonyos játékmódok Mantle nélkül nem érhetők majd el, de ezek extrém szituációk lesznek az Oxide szerint is. Amolyan Skirmish mód szinten, amikor kiválasztod, hogy mennyi lehet a maximális egységek száma. A Mantle-lel nagyobb lehet ez a szám.
-
#969
Abu85
HÁZIGAZDA
Malibutomi
#956
Abu85
HÁZIGAZDA
válasz
Malibutomi
#956
üzenetére
[link] - talán érdekes lehet. A címek alapján ő ott volt a CES zárt rendezvényein. Meg tudnám erősíteni, amit leírt csak nincs felhatalmazásom rá.
De ahogy látom az Oxide saját játékát kihagyta, és pár SE címet is.Szerk.: Ja nem, az SE-re odaírta alulra, hogy be nem jelentettek.
-
Abu85
HÁZIGAZDA
Korábban leírtam, hogy az Intel és az NV számára nem elég az, ha Repi azt mondja, hogy ezt támogathatják. Nekik tudniuk kell, hogy az AMD hogyan fejleszti tovább az API-t, mikor jutnak hozzá az új fejlesztésekhez, mennyit kell ezért fizetniük, és a legfontosabb, hogy kapnak-e az API-ról teljes dokumentációt, és ha nem, akkor szabad-e a reverse engineering.
A multivendor azért van bedobva, hogy a felhasználók ne a Mantle-t támogató fejlesztőkre mutogassanak, hogy "mé" csinálnak ilyet, hanem az Intelre és az NV-re, hogy "ménem" támogatják.Ha mondjuk nincs teljes dokumentáció és a speckókat csak megjelenéskor kapja meg az NV, akkor nem fognak bevállalni egy állandó 3-4 éves versenyhátrányt, hanem megmondják az AMD-nek, hogy rohadjon rájuk a PC-s játékpiac.
-
Abu85
HÁZIGAZDA
válasz
#35434496
#895
üzenetére
Nem fogja lehűteni annyira. A kártya mindig igyekszik elérni a 95°C-ot. Erre van beállítva. Ettől gyorsulni fog, de ilyet gyári paraméterekkel nem lehet majd csinálni. Ezért a gyártók leveszik a target hőmérsékletet, amitől viszont lassul a referenciabeállítás. Itt mindent át kell paraméterezni az adott target hőmérséklethez.
-
Abu85
HÁZIGAZDA
Az, hogy átláthatatlanná teszi a termékskálát, mert az egyik cég 290X-je 20%-kal is gyorsabb lehet a másik cég megoldásánál. Ha nem OC-s a termék, akkor be kell tartani a szabályokat. OC felirat mellett azt csinálnak a gyártók, amit akarnak.
(#892) HSM: A 80°C csak példa, de nyilván a DVFS-nek meg kell maradnia, mert ez biztosítja a hatékony kihasználást. Enélkül ott vagyunk, ahol kép éve, hogy 10-15 wattra is kerülünk a limittől. Ezért okozhat a hűtőcsere és csak a hőmérsékletlimit változtatása lassabb terméket a referenciamodellnél.
-
Abu85
HÁZIGAZDA
válasz
#35434496
#889
üzenetére
Nincs semmi baj, csak paraméterezik őket. Olyan gyorsnak kell lenniük, mint a referenciamodelleknek. Ehhez teljesen más paraméterezés szükséges, mert mint írtam a szimpla hűtőcsere és a 80°C-os limit lassít a referenciához képest.
Ez a termék nem olyan egyszerű, hogy csak raksz re egy másik hűtést és már mehet. -
Abu85
HÁZIGAZDA
válasz
Casanova*
#864
üzenetére
Ez nem ilyen egyszerű. A fejlesztő túl sok kontrollt nem kap a VRAM használat paraméterezésére. Minden egyes DX/OGL API object egy új memóriaterületet foglal le, még akkor is, ha lényegében ugyanaz az adat már vagy 4-szer benne a memóriában. Például ezért tudtak a korábbi generációs konzolok annyira kevés memóriával ellenni, mert nem pazarló módon bánnak a memóriával. Szóval még ha terveznének is a memóriahasználatra a GPU-nál, akkor is annyira kevés erre a kontroll, hogy simán mellé lehet lőni. Ennél egyszerűbb a megközelítés. Meg van szabva, hogy 200 dollár fölött már kell a 2 GB és 400 dollár fölött belefér a 4 GB is. Ennyire egyszerűen alakulnak ki a mai memóriasémák.
-
-
Abu85
HÁZIGAZDA
Nem. A Furmark szintű terhelés mellett a GK110 500 MHz-en üzemképes a 300 wattra tervezett PCB-vel. Ezért van driverből lefojtva a működése, hogy ne kelljen az órajelet csökkenteni.
Ha nincs DVFS, akkor mindenképp peakre kell tervezni, ami még a Furmarknál is nagyobb terhelés. -
Abu85
HÁZIGAZDA
A GTX 580 sokszor 40 wattra volt a kártyába épített TDP limittől. Ennyi teljesítmény maradt benne, amit a fix órajel miatt nem tudtak kihasználni. Ha kihasználják, akkor úgy jó 15-20%-kal gyorsabb lehetett volna, de ez már történelem, nyilván ilyen DVFS rendszereket nem könnyű fejleszteni.
(#829) HSM: De minek akarnál rátenni 8-at, amikor 6-tal is megvan a 300 wattos szabványos fogyasztás. Attól, hogy raksz rá 8-at még nem mehetsz a 300 watt fölé, ha el akarod adni a kártyát az OEM-eknek.
-
Abu85
HÁZIGAZDA
Az, hogy hány fázisú a VRM nem határozza meg egzakt módon, hogy milyen erős a rendszer tápellátása. Nem csak a fázisok száma számít. Azokat azért szokás növelni, mert fázisonként lényegesen gyengébb kiépítést lehet alkalmazni, ami összességében olcsóbb, mint a nem spórolós referenciamegoldások. Az, hogy ebből előnyt kovácsol a marketing az mindegy, mert ettől a hardver nem lesz jobb.
-
Abu85
HÁZIGAZDA
Ebből a fórumból szűrted le?
Ez olyan dolog, hogy a google-on beírod az egyik VGA-t és keresel screen hibát. Mindegyikre milliós nagyságrendű találatot kapsz. A legnagyobb gond a black screen hibával, hogy a megfogalmazás teljesen általános. Gyakorlatilag minden hiba fekete képernyőt eredménye, függetlenül attól, hogy mi a hiba forrása. Ezért van minden hardverre milliós találat.
Egyébként maga a gond az UEFI. A gyártók nem garantálják, hogy a fastboot eredményes lesz, csak akkor, ha azonos az alaplap és a kártya gyártója. Legacy módban megy, akinek ez a problémája. -
Abu85
HÁZIGAZDA
Ennél jobb PCB-t nem fog kapni semelyik sem. Ez így is lényegesen drágább, mint minden ma létező VGA PCB-je. A nem gyári megoldások olcsóbb VRM-et kapnak. Ki van zárva, hogy bárki ezekre a csúcskategóriás alkatrészekre építene.
Nem a VRM-mel van a baj, hanem azzal, hogy két munkafolyamat között olyan különbség lehet, hogy az egyiknél 750 MHz-en jó csak az órajel, míg a másiknál 1 GHz fölött is. Ha nincs DVFS, akkor mindenképp a peakre kell tervezni, vagyis a 750 MHz-re. Ezzel pedig számos munkafolyamatban sebességet vesztesz, mert jó lenne az 1 GHz is a szabványos, maximum 300 wattos határon dolgozó VRM-mel, csak nincs DVFS, amivel ezt elérhetnéd.
-
Abu85
HÁZIGAZDA
Miért kellene a vásárlókkal megértetni, hogy mit csinálnak? A vásárlóknak fogalmuk sincsen arról, hogy miképp működik egy ilyen hardver. Ők azt látják, hogy milyen teljesítményt ad le. Ennél tovább ezt nem kell ragozni, mert abból csak értetlenkedés lesz. Elég ha ezt a sokdiplomás mérnökök megértik, ők tudják, hogy mit miért csinálnak. Ez annyira mély információ, hogy felesleges is átadni a vásárlóknak, mert a többségük nem tanult egyetemi szinten fizikát.
Aki meg bele akar képzelni ilyen-olyan dolgot, hát beleképzelheti. Az eredményeket a tesztekben ez sem befolyásolja, illetve ettől még ugyanúgy menni fog a Mantle is. -
Abu85
HÁZIGAZDA
Ma csak a GPU Boost 2.0 és az új PowerTune miatt létezik a GK110 és a Hawaii. Komolyan nem viccelek, amikor leírtam, hogy az előbbi 500, míg az utóbbi 600 MHz-es órajelet kaphatna a DVFS rendszerek nélkül. Azt persze stabilan tartaná, de fel tudnád húzni mindkettőt úgy 650-700 MHz-re, és ez a csúcs a tuningnál. Na most ennél mindkét lapka jobb paraméterekkel dolgozik alapértelmezetten. Szóval lehet utálni minden DVFS-t, de figyelembe kell venni, hogy ezekkel legalább 30-40% teljesítményt nyernek a gyártók.
Az első ES Hawaii kártyákon volt a PowerTune kikapcsolható, mert akkor csak a lapkát mérték fel. Az 550 MHz-en üzemelt. Hiába volt mellette ugyanaz a tápáramkör, ami mellesleg 300 watt most is, akkor sem tudtak magasabb órajelet beállítani.
-
Abu85
HÁZIGAZDA
Attól függ, hogy milyen alkatrészeket használsz. A 290-ek az abszolút csúcsholmikat kapták. Az élettartamot a gyártók mindig a leggyengébb láncszemre alapozzák, ami így a 290-eknél 19 év. Ennél lehet, hogy továbbírják, mert a hitelesítés 120°C-ra van elvégezve, miközben a kártya 94°C-nál nem üzemel melegebben.
Kétségtelen, hogy a 290-ekkel nem a magyar piacot célozták meg, ha ez érdekel. Ha valaki 4K gaminget akar, ott a 290-ek működnek a legjobban, és ha már van egy 3D-s 4K kijelzője, akkor van esély rá, hogy azt filmnézésre is használja majd.
-
Abu85
HÁZIGAZDA
Megnövelték az UVD órajellimitjét, így képes sztereó 3D-s 4K-s anyagokat is lejátszani. Mivel ezt az AMD szerint 4K-ra veszik a játékosok, így ez egy fontos szempont volt, hogy a 4K-s sztereó 3D-s filmekkel is megbirkózzon. Más hardver ma erre nem képes.
(#780) gbors: A kézikönyvekben benne van, hogy miképp működik a hardver. A gyártóknak bele kell írni, hogy az órajel változása normális működés.
(#781) Tirexi: Pedig ez a jelenség a GPU Boost 2.0 és az új PowerTune esetén is teljesen normális. Maga a kártya dizájnja a megadott hőmérsékleten működik a leghatékonyabban. Az NV is 80°C-on kezdte, de haladnak felfelé a GTX 780 Ti-vel, mert minél nagyobb lesz a hőmérséklet annál jobb lesz a hardver működése. Persze a GK110-ben nincs lehetőség órajelváltásra tíz mikromásodpercenként, így muszáj a tűréshatás alámenni, mert a túlmelegedésre a hardver 500 ms-on belül nem reagál. Tehát kell benne hagyni annyit, hogy a túlterhelés hatására az órajelet legyen ideje levágni 150-200 MHz-cel az egyik ciklusról a másikra. Ezt ők kitesztelték, és a 83°C, ahol ez még biztonságos és nem sül meg a hardver. Az AMD azért megy el 94°C-ig, mert nekik 10 mikromásodpercre van szükségük, hogy a hardver kiértékelje a változást, és csökkentsen az órajelen 10 MHz-et. Ezek nagyon átgondolt rendszerek, hónapok tesztelésének eredményei.
Majd a következő körben már mindkét cégtől hasonlóan szoros működést láthatunk. ÉS alapvetően biztos, hogy a limittől mindketten 1 wattos határra kerülnek mindig. Ez azért nagyon fontos, mert a GPU Boost és a PowerTune is a biztonságra van paraméterezve, vagyis ha rezeg a léc, akkor mindkét rendszer órajelcsökkentéssel él. Minél pontosabb ez a csökkentés, annál jobb lesz a kártya hatékonysága.
-
Abu85
HÁZIGAZDA
Nem pont rád gondoltam a név nélküli részen. De túl általánosan fogalmaztam valóban. Elnézést érte.
Nem VRM kell alá, az van alatta. Itt a 300 wattos fogyasztáslimit a probléma. Igaz, hogy ez 250 wattra van állítva, de a VRM amit aláraktak az 300 wattra van tervezve. Ennél többet nem tudsz rátervezni. Ezek azok a problémák, amelyek az életre hívták a DVFS kutatásokat. Kezdve az első PowerTunetól a GPU Booston át a mostani PowerTune-ig. Mindegyik megoldásnál az a cél, hogy ha a GPU-ra kiszabott TDP limit teszem azt 207,5 watt (ennyi a Hawaii-nál, de ez csak példa), akkor minden egyes munkafolyamatnál legyen legalább 206 watt fölötti a fogyasztás, és ezzel maximalizálva van a termék hatékonysága az adott limiten belül. Ha ezt nem teszik meg, akkor be tudnák állítani a Hawaii-t úgy 600 MHz-re, mert akkor egy nagyon irreális peak értéket kell figyelembe venni, de közben a normál feldolgozás mellett a 207,5 wattos limit elérhetetlen, így a GPU csak 150 watton üzemel. Nyilvánvaló, hogy benne marad a teljesítmény negyede.
Ugyanez igaz a GK110-re a GTX 780 Ti-n, csak ott a GPU Boost 2.0 nem olyan kifinomult, így a 214,3, wattos limit a GPU-ra elő van írva, de sok szituáció lesz, ahol így is 201 watt a fogyasztás, mert a boost működése nem engedi meg, hogy közelebb kerüljön a limithez. A GTX 780 Ti esetében a GPU Boost 2.0 nélkül 500 MHz az az órajel, amit be lehet állítani, mert ott is a peak lenne kivitelezve a rendszer, ami a Keplernél, lényeges probléma, mivel az architektúra regiszterkezelése számos munkafolyamatnál elég jó, míg mondják más munkafolyamatoknál nincs elég regiszter, hogy az SMX-en belül a hat tömbből négynél több legyen aktív. Ezzel gyakorlatilag lennének olyan feladatok, ahol a GPU Boost 2.0 nélkül a GTX 780 Ti alig 90 watt mellett üzemelne.
Szóval ez a PowerTune meg a GPU Boost 2.0 egy nagyon realista szemlélet a mai világban, mert enélkül a top R9 290 és GTX 780 hardverek teljesítményének csak a 60%-át kapnád meg. Aztán tuningolhatsz ahogy akarsz, de soha sem lennél képes elérni azt a teljesítményt, amit most nyújtanak a kártyák alapértelmezetten. Sőt, megközelíteni sem tudnád.
A spórolásról meg annyit, hogy jelen állapotban jóval drágább egy kártyát előállítani, mint PowerTune és GPU Boost 2.0 nélkül. De megéri méregdrága vezérlőt és körítést alkalmazni, mert nagyjából +40% teljesítményt hoznak ezek a rendszerek.(#758) gbors: Az AMD minden anyagában Up To órajelről beszélt, illetve ha valakinek ez nem tetszett, akkor PowerTune Boost órajel is használható, vagy maximális magórajel. Ezek közül lehetett választani.
(#776) Tirexi: Nagyon egyszerű a custom hűtőknek a gondja az R9 290 sorozaton. Ez nem olyan egyszerű, hogy hűtőt cserélsz és kész, ugyanis azokra a termékekre át kell paraméterezni a rendszert. Ráadásul az is gond, hogy a kártya a maximális teljesítményhatékonyságot 95°C-on éri el, tehát ha ennél lejjebb mennek a gyártók, akkor gyorsulni fog a termék, de ha a 95°C-ot lejjebb veszik a hűtési teljesítménnyel arányosan, akkor már nem fog olyan hatékonyan boostolni a hardver, tehát teszem azt 80°C-os limitre paraméterezéssel a kártya lassabb lesz, mint 95°C-os paraméterezéssel. Ezeket sorra ki kell tesztelni, ugyanis az AMD 3%-os varianciát enged meg gyári specifikációkkal.
-
Abu85
HÁZIGAZDA
Azért tekintik ezt sokan órajelcsökkentésnek, mert nulla mérnöki tudással mérnöknek képzelik magukat. De egyszer már leírtam, hogy az adott hardver kihasználásánál nem az órajel számít, hanem az, hogy a TDP limitet elért minden egyes szituációban. Ez adja majd a legnagyobb átlagos teljesítményt, mert mindig maximális a kártya kihasználása. A Hawaii új megoldása azért áttörés, mert soha semmi nem tudott még úgy működni, hogy minden szituációban képes volt hozni a beállított TDP limitet, és a legrosszabb kihasználtság mellett is csak 1 wattra volt tőle. És az érdekesség, hogy az NV a GK110-ben is ezért vezette be a hőmérsékletfüggő turbót, mert a normál turbóval volt olyan szituáció, amikor 15 wattra voltak a TDP limittől, ami azt jelenti, hogy teljesítmény maradt a rendszerben, amit hasznosítani lehetne egy GPU Boostnál jobb technikával. Erre volt jó a GPU Boost 2.0, ami legrosszabb szituációkban 10 wattra megközelítette a TDP limitet, de az NV akkor mondta, hogy ez még mindig nem elég jó, mert az lenne az ideális, ha 1 wattra kerülnének a TDP limittől. Ezt az AMD csinálta meg a Hawaii-jal. Technikai értelemben ez a megoldás az, amiért az AMD és az NV elkezdte ezt az órajelállítást, mert a limit minden hardverben megvan, de nem mindegy, hogy mennyire hatékonyan használod a lapkát a limiten belül. A régi hardverek 30 wattra is lehettek a limittől, ami akkor jó volt, de azóta eltelt 3 év, és milliókat költenek arra a cégek, hogy 1 wattra kerüljenek a limittől, vagyis elérjék a hardver maximális kihasználását. A Hawaii az első termék, ami ezt a célkitűzést hatékonyan megvalósítja, de a jövőben mindegyik hardver ilyen lesz, mert a maximális hatékonyságra kell törekedni.
Az meg, hogy függ a hőmérséklettől az órajel. Nos, ezt az NV GPU Boost 2.0 vezette be. Pontosan azért, mert hőmérséklet fontos szerepet tölt be abban, hogy közel kerüljenek a limithez. A Hawaii ezt a rendszert csak továbbfejlesztette. Ráadásul ez a megoldás adja a legjobb eredményt az órajelzuhanásra vonatkozó fps-esésre. Mivel az órajel csökkenése folyamatos, és nem egyszeri. A legrosszabb eredményt a GPU Boost 2.0 adja, mert ott 150 MHz-et eshet az órajel egy ciklus alatt. A Hawaii maximum 10 MHz-es váltást enged meg.
---
(#720) HSM: Az, hogy ezek a rendszerek így működnek nekünk jó, mert a hardver mindig maximális teljesítményt ad le. Ha ez a technológia nem lenne, akkor a Hawaii cGPU nem skálázna 1000 MHz-re, hanem 600 MHz lenne az alapórajele, illetve az NV-nél a GK110 sem mennek 900+ MHz-et, hanem be lenne állítva fixen 500 MHz-re. Ez azt jelenti, hogy a GK110 és a Hawaii sem született volna meg, mert nem lenne gyorsabb a kisebb GPU-knál.
Ne képzeljük már magunkat okosabbnak azoknál a mérnököknél, akik óránként többet keresnek annál, amit mi egy nap összeszedünk. Az interneten mindenki olyan okos, csak azt tudnám, hogy miért nem az itt egybegyűltek ülnek ott a tervezőszékben. Talán azért, mert nem voltunk színjelesek fizikából, és nincs több mérnöki mesterduplimánk. Persze könnyebb beszólni, hogy ez így nem jó, de közben folyamatosan beszélni arról, hogy gyorsabb kártya kell, mert már nem fut 50x-es AA-val a Bátölfíld.Persze mindenkinek lehet véleménye a GPU Boost 2.0-ról és a Hawaii PowerTune-ról. Lehet anonim módon osztani, hogy fosok ezek a hőmérsékletfüggő rendszerek, ahogy mondjuk a prociknál is, hiszen azok is ugyanilyen boostot használnak. Viszont a GPU Boost 2.0 nélkül nem lenne GK110 és az új PowerTune nélkül sem lenne Hawaii.
---
(#721) players111: Ez jól mutatja a színvonalat. Érteni nem érti senki, hogy miért olyan a GPU Boost 2.0 és az új PowerTune, de biztos rossz. Én voltam a hülye, hogy megmagyaráztam.
Az meg külön érdekes, hogy a jobb megoldás van rosszabbnak beállítva. Ez annyira aranyos. Az NV mondta a GPU Boost 2.0-nál, hogy az 1 wattos limithatár elérése a cél. Itt láthatóan örültek ennek a célkitűzésnek. Az AMD elérte, most már ez rossz. Biztosíthatók mindenkit, hogy ezt az NV is el fogja érni, akkor már jó lesz?---
(#706) SzlobiG: A tekercs cicereg. Emellett ezeknek a hűtés nem számít, mert nem a meleg miatt csinálja, hanem azért, mert a gyártás során esetleg gyantahiányosak lettek, így a tekercs megmozdulhat, aztán ezzel meg is repedhet. Ez előjöhet az első használatnál, vagy esetleg egy-két év múlva … kvázi bármikor. Azt meg senki nem tudja garantálni, hogy egy tekercs tökéletes, illetve ez még nem is igazán függ a terheléstől. Szerencsére maga a gond nem okoz működésbeli problémát, amíg a tekercs a helyén marad (hova menne ugye
). -
Abu85
HÁZIGAZDA
Tökéletesen elmagyarázták a speciális helyzeteket, de nem mindenhol vették a worst case szituációt. Mondjuk ezt single GPU és AFR összehasonlításánál nehéz is. A single GPU esetében nincs rosszabb input helyzet, míg AFR-nél azért van. Sajnos az ábra nagyon le van egyszerűsítve. Ugyanis a frame-t nem ott kezdi el számolni, ahol jelzik, hanem ugyanott, ahol az unmetered esetén, csak éppen eltolja a back és a frame buffer cseréjének idejét. Ez extra lag.
Amit mutatnak, az akkor lehetséges, ha a motor fel van készítve az AFR módok megkülönböztetésére, ha ez nem lehetséges, akkor a metered és az unmetered AFR-nél is 2 frame a lag.
Az unmetered ott kerül előnybe a lag tekintetében, hogy ha még a frame n+1 előtt volt az input, annak az eredményét ugyanis eltolás, azaz extra lag nélkül számolja. Tehát amit mutatnak az hazabeszélés, mint tényfeltárás. Nem mintha mást vártunk volna, hiszen nyilván nem fogják megmutatni a jellemző szituációkat, ahol az unmetered kisebb lagot mutat. Nagyjából ekkor hagytam abba a nézést, mert csak arról volt szó, hogy ha a motorba be van optimalizálva a metered AFR direkt kezelése, akkor mi történik, de egyelőre nulla ilyen játék van a piacon. Ami előny, hogy DX9 alatt azért egész jól bele lehet nyúlni a működésbe, de a DX10 után ezt már az MS eléggé megvágta, vagyis a program oldaláról kell optimalizálni.Bevallom engem jobban érdekel, hogy mikor lesz nextgen szintű a hardver, mert sokkal súlyosabb problémának érzem, hogy a nextgen konzolok API-ja ripityára veri a DX11.1-et is. Tök jó a PC-n minden szebben fut beidegződés, csak ez már az első körben sem lesz igaz, ha a DX11.1-et nem fejlesztik tovább sürgősen.
-
-
Abu85
HÁZIGAZDA
Az AMD ilyet nem mondott, csak 4 éve, amikor beszélték, hogy az AFR implementációjuk azért ilyen, hogy az input lag alacsony legyen. 4 éve volt ez. És eleve érthető, hogy ha késleltetés nélkül kezdődik meg minden frame számítása, akkor a késleltetéssel dolgozó megoldás több input lagot eredményez.
Ez nem olyan egyszerű, már írtam. Eleve a smoothing egy GPU-ra is működik, tehát nem SLI specifikus. SLI-vel annyi a különbség, hogy két GPU-ra történik az egész rendszer feldolgozása.
Nem. Az AMD azt mondta, hogy a tesztelők kérésére raknak egy olyan megoldást is a driverbe, ami úgy működik, ahogy az NV AFR-je, de a mostani AFR marad az alapértelmezett, mert a profi játékosok jobban kedvelik ennek az előnyeit. Egy kapcsolóval lehet majd a kettő között váltogatni.
Az a baj, hogy azt hiszed, hogy az egyik AFR megoldásnak csak előnyei vannak, míg a másiknak csak hátrányai. A valóság az, hogy ami az egyiknek előnye, az a másiknak hátránya és fordítva. Olyan AFR nincs, ami minden szempontból előnyös. Ha lenne, akkor mindenki arra építene implementációt. -
Abu85
HÁZIGAZDA
Az AO-ra nem. A fake az nem jó szó. Az AO lehet scene space és screen space. Előbbi baromi jó, de ki tudja azt kiszámoltatni ugye. Utóbbi csak egy szimulált hatás, de nem fake ettől. A fake ott keletkezik, ha túlzott árnyékolásba megy át. A szimulálás jellemző minden SSAO-ra.
A fake hatás az SSAO-nál ott lehet megemlíteni általánosan, hogy nem veszi figyelembe a fény színét. Erre való az SSDO. Az új Ruby demóban nagyon sok mintával lesz használva és teljes képernyőre, így ott durván látható lesz az előnye. -
Abu85
HÁZIGAZDA
A FRAPS az funkcionálisan csak arra jó, hogy kiírja az FPS-t. Ennyi. Semmi mást nem lehet vele ténylegesen vizsgálni.
Az FCAT az jobb, hiszen megtudod belőle a displayidőt. Ezeket nem kell cáfolni.
Input lagot senki sem mér, mert ahhoz egy marha nagy sebességű kamera kell. De igazából mérni sem érdemes, mert az elvben is benne van, hogy a smoothing a számítás késleltetésével jár. De mindegy. Fentebb olvashatsz arról, hogy miért. Ha az nem elég, akkor ennyi.Dehogy szubjektív. Nézz a való világba, és a látottakat ültesd át a virtuális világba. Egyértelmű, hogy olyan erős árnyékokat nem látsz mint az SSAO-nál és a HBAO-nál az FC3-ban. A HDAO megoldása jellemzően fake árnyékoktól mentes ebben a játékban. Hogy ennél a legkisebb a változás? Hát talán azért, mert ez dolgozik a legtöbb mintával, és nem rak oda árnyékot, ahol nem keletkezne a valóságban.
Az AO az abszolút nem a fake árnyékokról szól. A szimulált screen space opciókat azért használjuk, mert az eredményük messze elég jó, és az erőforrás-igényük nem sok a scene megoldásokhoz képest.
). Az viszont nem kizárt, hogy páran maradnak a Mantle mellett. Legalábbis azok a fejlesztők nagy valószínűséggel nem hagyják el, akik saját idejükből részt vettek a fejlesztésében. Ők amolyan saját gyereknek tekintik ezt.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
). Viszont vannak a zsíros kormányzati megrendelések. Nekik fontos az, hogy a hardverek dokumentálása jól elérhető legyen és ezért támogatják a Linuxot és a mögötte rejlő open dolgokat. Na ez az amiért Linus bemutatott, az NV ezekért a zsíros megrendelésekért semmit sem tesz.
Az meg külön érdekes, hogy a jobb megoldás van rosszabbnak beállítva. Ez annyira aranyos. Az NV mondta a GPU Boost 2.0-nál, hogy az 1 wattos limithatár elérése a cél. Itt láthatóan örültek ennek a célkitűzésnek. Az AMD elérte, most már ez rossz. Biztosíthatók mindenkit, hogy ezt az NV is el fogja érni, akkor már jó lesz?
Ú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.
- HP notebook topic
- Kerékpárosok, bringások ide!
- Abarth, Alfa Romeo, Fiat, Lancia topik
- Motorola Edge 50 Neo - az egyensúly gyengesége
- Sorozatok
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- A nagy Szóda, Szódakészítés topic - legyen egy kis fröccs is! :-)
- Kuponkunyeráló
- ThinkPad (NEM IdeaPad)
- További aktív témák...
- Újszerű Dell Latitude 7440 -14"FHD+1 IPS - i5-1345U 16GB - 512GB - Win11 - 1 év garancia + Dokkoló +
- Eredeti, új Lenovo 330W töltők - ADL330SDC3A
- Samsung Galaxy S24+ 256GB,Újszerű,Kabellel, 12 hónap garanciával
- Hibátlan, megkímélt! II Lenovo ThinkPad T540p II i7-4800MQ I GT 730M I 8GB I 240 GB I 15,6" FHD
- Mini Pc HP ProDesk 600 G2 G3 G4 /// 6-8. gen //// i3 / i5 /// garancia /// Budapest / MPL / Foxpost
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest