Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Egyrészt az NV DSR semmivel sem jobb az elmosásban, mert 22-tap guassian blur van rajta kötelezően a szoftveres skálázó miatt. Ennél még erősebb lesz az elmosás azzal. Az AMD VSR nem alkalmaz semmilyen elmosást, mert a hardveres skálázót használja, és az élesre megoldja a leskálázást erős guassian blur nélkül is.
Másrészt a DSR/VSR átméretezi a HUD-ot, ami eleve nem nagy ebben a játékban. Harmadrészt DX12 alatt nem működik. -
#21706
Abu85
HÁZIGAZDA
huskydog17
#21697
Abu85
HÁZIGAZDA
válasz
huskydog17
#21697
üzenetére
Nem a motortól függ ez, hanem a leképezőtől. A hagyományos MSAA nem kompatibilis a Dawn leképezőjével, amin úgy kerekednek felül, hogy minden render targetet 8xMSAA-val képeznek le. A másik megoldás, hogy ezt nem csinálják meg, és akkor nem működik az MSAA a kép 90%-án.
A Codemasters motorja azért nem jó példa, mert az EGO korábbi változatainál egy pályán volt összesen annyi részletesség, amennyi a Dawn motoron belül egy kis szobányi területen. Egészen másképp kell leképezőt tervezni erre a részletességszintre.
Warhammer teszt csak ultra presettel. E fölött jönnek a GPUOpen effektek. [link]
Leírtam, hogy a CHS miért működik így. Semmi köze a LOD-hoz. Kell egy második fázis az árnyékra, ami viszont további számítás lenne. Az, hogy az EGO motorban működött nem jelenti azt, hogy százszoros részletességi szinten bevállalható kétfázisú árnyékolás. Ahhoz előbb optimalizálni kell, hogy gyorsabb legyen.
-
Abu85
HÁZIGAZDA
válasz
mlinus
#21677
üzenetére
MSAA nélkül RX 480 vagy gyorsabb VGA-val jellemzően megvan. RX 480-nál lassabb VGA-val nincs meg. Az RX 470 és a GTX 1060 határeset.
MSAA-val sokat esik a sebesség, mert sok a számítás.A beépített benchmark egyébként az abszolút legrosszabbhoz közelítő terhelés, tehát a játék 95%-ban jobban fut. A benchmark azért olyan kemény, mert tele van volumetrikus fénnyel, illetve aránylag sok ideig 3-5 TressFX-es hajat számol. A valós játékban ezek a helyzetek ritkák.
-
Abu85
HÁZIGAZDA
Hozzátéve ehhez: Az AA egy másik probléma, és nincs köze az árnyékokhoz. Azzal ugyanakkor egyetértek, hogy a PC-s szabványos API képességei az AA-ra vonatkozó lehetőségek tekintetében messze elmaradnak a konzolos API-któl. Már rég szabványnak kellene lennie a manuális interpolációnak és a fedettségmintáknak. Ezzel hozható lenne PC-re egy csomó konzolos analitikai AA, ami gyorsan ad kiváló minőséget.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#21666
üzenetére
Azzal az árnyékolási technikával, amit a Dawn motor használ bármelyik CHS-szerű effekt eltűnik. A PCSS is.
Mint írtam van egy megoldás erre, ami arról szól, hogy az árnyékolást két fázisban kell futtatni. Kell egy a lágy szélű, erősödő árnyékra, és ennek a határára után kell egy normál fázis, éles árnyékokkal. Ilyet alkalmaz a GTAV is, és ott megfelelő a CHS és a PCSS mellett is a távoli árnyékok kezelése. Néha a PCSS picit bugzik a határon, de elhanyagolható. Ugyanakkor az már nem elhanyagolható tényező, hogy a GTA5 jelenet- és grafikai komplexitása a Deus Ex MD tizedét sem éri el. Tehát ami ott relatíve jól működik, az tízszer komplexebb grafikai megvalósítás mellett sokkal jobban enné a teljesítményt. Bevethetik, de fájni fog (különösen a GeForce-oknak, mert nem szeretik a több fázisú megoldásokat), ha nem optimalizálják a CHS-t tovább. -
Abu85
HÁZIGAZDA
válasz
TTomax
#21663
üzenetére
Ez teljes tévedés. Egyrészt a CHS erőforrás-igénye még így is a fele PCSS-nek. Az AOFX esetében pedig a HDAO+ ugyanolyan paraméterezés mellett a HBAO+ teljesítményigényének a negyedéért elvégezhető. Tehát ezeken azért látszik az optimalizálás. Az viszont igaz, hogy ezek egy részét a fejlesztők végzik el, de ez a GPUOpen célja, hogy a fejlesztő a saját eredményeit visszaírja, hogy abból más fejlesztő is profitáljon.
Akkor lehetne a CHS-t és a HDAO+-t vádolni a gépigény növelésével, ha létezne nálunk gyorsabb effekt ugyanarra a célra, ugyanolyan paraméterezéssel. Ma azonban ezek a leggyorsabb effektek erre a célra.
A GameWorksöt azért támadják, mert az egyes effektek rosszabb minőséget állítanak elő, mint a GPUOpenes társak, és teszik ezt nagyobb erőforrás-igénye mellett. Például Hairworks kontra TressFX. Utóbbi jobb minőségű és gyorsabb is. -
Abu85
HÁZIGAZDA
válasz
velizare
#21659
üzenetére
Így lett beállítva. Ez egy nagyon GPU-zabáló effekt, tehát ha nem paraméterezik kompromisszumosra, akkor könnyen elveszi a sebesség felét. Általában úgy van kalibrálva, hogy 10-20%-nyi sebességet vigyen el, és ez ennyire elég. DX12-ben az aszinkron compute mellett ezen lehetne segíteni, mert akkor a számítás jó része átlapolható lenne.
Egyébként vannak ennek a kezelésére tipikus trükkök is, de azokat nem alkalmazza a Deus Ex. De persze később bekerülhet. Viszont az is némi sebességbe kerül.
A trükközés ellen szól, hogy azt a módszert, ami a GPUOpennek a része ennek a kezelésére, a GeForce nagyon nem szereti. Négyszer annyit lassít az NV hardverein, mint a Radeonokon. A hardver alkalmas lenne rá, csak dokumentáció nélkül nem lehet jól optimalizálni. -
Abu85
HÁZIGAZDA
válasz
Valdez
#21655
üzenetére
A PCGH-nak szokása kikapcsolni a GPUOpen cuccokat. És a Deus Exben a CHS és az AO is GPUOpen, és különállóan inaktiválhatók. Mindkét effekt compute, tehát nyilván itt sok tempót nyernek a Radeonok.
Tekintve, hogy nem volt padlóra küldve az fps a PCGH-n, így az MSAA off lehetett. A Deus Ex MSAA-ja nagyon speciális, brute force megoldás. Kb. olyan terhelést ad, mintha hétszer csinálná meg egy átlagos program az MSAA-t egy képkockára.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#21654
üzenetére
Az AF sebességvesztése attól függ, hogy szögfüggő vagy sem. A mai játékokba nem építenek szögfüggőt, mert bírja a hardver. Lényegében ugyanannyit lassul az AF mindkét gyártón, ha megegyezik az algoritmus. Persze a szoftverfejlesztő dönthet úgy is, hogy az egyik gyártóra szögfüggő AF-et rak be, míg a másik gyártóra teljeset. Ezt nem szokás megtenni, de csak döntés kérdése az egész. A Deus Ex-ben nem szögfüggő AF van.
-
Abu85
HÁZIGAZDA
Fogalmuk már van róla, mert a DX11-ben aktív az AGS 4.0, és ugyanannyit nyernek vele DX12 alatt is. DX11-ben pedig a Fury X 6%-ra van a GTX 1080-tól.
Maximumon, 4K-ban nem valószínű, mert az MSAA az deferred, tehát azt aktiválva a sebesség nem fogja elérni a 20 fps-t egy VGA-n sem. Maximum a Radeon Pro Duón lesz játszható így. Ezért lesz a DX12-ben több GPU-s támogatás. -
Abu85
HÁZIGAZDA
válasz
Yutani
#21582
üzenetére
Az AAA játékoknál valószínű. Az ID tech 6, az új Frostbite, a Dawn, az új Asura biztosan. Állítólag az ID tech6 leszármazottak is, mint például a Void. De ezek egyébként olyan motorok, amelyek nem licencelhetők, vagy rendkívül drágák.
Ha egy motor használja a gyors kódokat, akkor az erősorrend nagyjából az lesz, ami a Doom Vulkan módjában. Ha nem, akkor nagyjából az az erősorrend, amit a mostani modernebb játékokban látsz.
Aztán lehet olyan is, amikor a konzolos optimalizálást NV-re is áthozzák persze módosított kóddal. Ezt egyedül talán a Dice tudja megpróbálni, mert nekik jóval letisztultabbak a fejlesztéseik, így hogy túl vannak az egységesítés nehezén.
(#21584) Petykemano: Egy PC-s fejlesztőt nyilván sosem fog annyira érdekelni egy PC-s hardver, mint egy konzolost egy konzol. A cél sokkal inkább az, hogy ha már a PC-s kutatásukból hiány van, akkor a konzolos kutatásokat hasznosíthassa a PC.
(#21588) gollo91: Gondolom ezt is számításba vették, amikor kitűzték a célokat.
(#21589) NetTom: Attól messze van mindenki. Nem szaktudásban, hanem inkább időben. Az EA mindenkinél hamarabb felismerte az összevont fejlesztések értékét, és mára egy kész stratégiájuk van erre. A többiek még csak a berendezkedésnél tartanak. Nyilván a Zenimax sem véletlenül vette meg az ID-t. Le se szarták a Doom vagy a Quake jogokat. Az igazi érték a technológia volt, ami mostantól ott van házon belül. Most az Eidos számára is a Dawn egy jó alap a házon belüli kiterjesztésre.
-
Abu85
HÁZIGAZDA
Nem lehet kiszámolni mondom. A lényeg, hogy a fejlesztők célja az, hogy 4K-ban a Fury X a GTX 1080-nál gyorsabb legyen a DX12 módban. Ezért tartalmaz a játék olyan dolgokra támogatást, mint az AGS 4.0. Ezért finanszírozta az AMD éveken át ezt a projektet. Illetve nem pont a Deus Ex-et, hanem magát a kutatási részleget, ugyanis az Eidos Montreal olyan modellre vált, amilyet az EA/Dice használ. Felépítettek egy kutatási részleget Jean-Normand Bucci vezetésével, és ez a részleg a GPUOpen egyik legszorosabb támogatója. Maga a csoport korábban is megvolt, hiszen velük dolgozta ki az AMD a TressFX-et, de akkor csak pár ember volt a Crystal Dynamicsnál. Azóta több emberrel bővült az egész, és különváltak minden stúdiótól. Mostantól a feladatuk az, hogy az Eidos Montreal projektjeihez fejlesszenek technológiát, effektet, motort, bármit. És emiatt gyakorlatilag be vannak olvadva az AMD GPUOpen kezdeményezésébe is, mert ez lehetővé teszi számukra, hogy minden kutatásuk működjön konzolon és PC-n. Ennek a fejlesztési iránynak az első projektje az új Deus Ex. Ehhez csináltak egy új motort (Dawn), ami a Glacier 2 módosított verziója, illetve pár GPUOpen effektet átalakítottak, mint a TressFX, az AOFX és a GeometryFX. És nyilván az átalakítás része az volt, hogy kihasználják az AGS 4.0 lehetőségeit PC-n, mivel célplatform a multiplatform elterjedtség miatt a GCN.
-
#21581
Abu85
HÁZIGAZDA
Petykemano
#21580
Abu85
HÁZIGAZDA
válasz
Petykemano
#21580
üzenetére
A szoftveres csoport, aki ezen dolgozik nem fogja mérlegelni, hogy mi kell az eladáshoz, mert nekik olyan feladatuk van, hogy tegyék a PC-s játékfejlesztést elfogadhatóvá a legtöbb stúdió számára. Olvasszák össze a multiplatform kutatásokat, így a konzolra kifejlesztett kódok is használhatók lesznek PC-n. Ez a szoftveres csoport a GPUOpenben csak erre koncentrál, és láthatóan nagyon jól végzik a dolgukat. Fél év alatt igen sokat tettek azért, hogy a PC-n is elérhetők legyenek bizonyos konzolos képességek. Ennek nagyon fontos költségcsökkentő hatásai vannak, mert úgy sem fog senki direkten PC-s kutatást végezni. Ez az elmúlt évekből már kiderült. Ilyen szempontból egyébként a GPUOpen nem más, mint egy reakció egy problémára. Sőt, a GameWorks sem más, csak más oldalról közelíti meg a problémát, de egyértelmű, hogy az NVIDIA is ugyanazt látja: nincsenek direkt PC-s kutatások.
A GPUOpen és a GameWorks ilyen formában még ki is egészíti egymást, hiszen más a célcsoport is. A GPUOpen a top stúdiókat tudja megszólítani, míg a GameWorks a függetleneket.A hardvereladás más lapra tartozik. Nem a GPUOpenben résztvevő programozóktól függ, nem is kell foglalkozniuk ezzel.
Marketing oldalról egyébként általánosan nehezebb bánni a GPUOpennel, mert az tulajdonképpen nem ad mást, mint hozzáférést a hardverhez. Tehát az ideális marketingje az, hogy a fejlesztő kap dokumentációkat, eszközöket, forráskódot, mindent, ami a fejlesztéshez kell, és a konzolos optimalizálást áthozhatja. Ennek az eredménye sebesség vagy extra effekt lesz, de nem tudsz kiemelni semmit, mert tök általános az egész, minden partner olyan innovációt hoz, amilyet akar. A GameWorksszel sokkal könnyebb bánni, mert az pont nem ad hozzáférést semmihez. Kínál pár előre megírt effektet és kész. Ha egy fejlesztő ennél többet akar, akkor ... nos akarni sok mindent lehet. Viszont a marketing teljesen kötött, mert a fejlesztő nem csinálhat mást, mint amire az NV lehetőséget ad, és az rendkívül szűkös, tehát nincs végtelen opció az innovációra, és arra pár lehetőségre ami van rá lehet építeni az egész marketinget.
De nyilván ez az egész nem ennyire fekete-fehér, mert például a GPUOpen adja meg a lehetőséget az AMD-nek arra, hogy az eddig megjelent Win32-es AAA DX12 játékokból hármat a Gaming Evolveden belül jegyeznek, és ugye csak egyet jegyez az NV. Tehát vannak itt előnyök a hátrányok mellett, ahogy az AAA játékhiány a GameWorks oldalán egy egyértelmű hátrány. -
Abu85
HÁZIGAZDA
válasz
Yutani
#21577
üzenetére
A tendencia eléggé meredek fogalom lesz itt. Még az AMD szerint is biztos, hogy az AGS 4.0 és a SPIR-V kiterjesztéseik csak az AAA multiplatform játékokat fejlesztő stúdiókat érdeklik, mert ők írnak olyan kódokat a konzolra, amelyeket könnyű áthozni PC-re. Egy átlagos fejlesztő, aki esetleg nem is ad ki játékot konzolra, ezekkel nem nagyon tud majd mit kezdeni, mert nincs meg a használathoz szükséges kutatási alap. Csak PC-re pedig nem fognak ilyen dolgokat kutatni. Amit erről tudni, hogy a GPUOpen shader intrinsics az olyan partnereket érdekli, mint a DICE/EA, az ID software, az Eidos csoport (Nixxes/IO), az Ubisoft, a Rebellion, stb. De például az Oxide-ot nem igazán érdekli, annak ellenére, hogy nagy PC-s úttörőkké formálódtak pár év alatt. Szóval a Doommal kialakuló irány egy eléggé szűk csoportot megcélzó tendenciává formálódik, csak azért kap nagyobb figyelmet, mert az elitet célozza.
-
Abu85
HÁZIGAZDA
Nem tudni, hogy mennyit jelent az aszinkron compute. Az új Deus Ex alatt a post process, az SSAO, a volumetrikus fények és a fizikai számítások (PureHair/TressFX) vannak párhuzamosítva a grafikával. A TressFX eléggé ismeretlen tényező, mert minden karakteren ilyen haj lesz.
A mostani tesztből kiindulva a shader intrinsics nagyjából +20-25%-ot jelent, ez az ami biztos ... tekintve, hogy DX11 alatt van AGS 4.0, míg DX12 alatt nincs.
Ha ezt hozzáadod a DX12 eredményekhez, plusz számolsz minimum +5%-ot az async compute-ra, akkor a Fury X már elkapta az 1080-at. Innen elég reális az a target, hogy 4K-ban a Fury X legyen a leggyorsabb VGA az új Deus Ex alatt. -
Abu85
HÁZIGAZDA
válasz
daveoff
#21573
üzenetére
Ez bonyolódik egy picit, mert a Deus Ex már használhatja az új elérési módot az Anniversary Update miatt. Ilyenkor a multi-GPU úgy is használható, ahogy régebben használható volt DX11 alatt. Így már implicit a VRAM hozzárendelése a GPU-khoz, vagyis az SLI/CF-hez hasonló. De ha a hagyományos multiadapter módot használja, akkor nyilván a VRAM kezelése is explicit. 99%, hogy multiadapter még a vezérlési mód, mert a driverekben még nincs benne az Anniversary Update új multi-GPU-s rendszere, vagyis a VRAM tárolhat akármit, amit a fejlesztő kér.
-
Abu85
HÁZIGAZDA
válasz
mlinus
#21491
üzenetére
Nem ezért. Már leírtam, hogy az AGS 4.0 nem aktív a friss Radeon Software meghajtók DX12 driverében. Emiatt lassulnak a Radeonok a DX11-es módhoz képest mert ott gyors kódot futtathatnak, míg DX12-ben csak szabványost, nyilván a tesztproci mellett a procilimit nem tényező. Persze lehetnek még általános optimalizálások, de a fő oka a csúszásnak ez. A DX12 mód stabil, működik a multi-GPU, a gyengébb procikon jó eredményeket produkál, egyedül az async compute inaktív, de azt is csak aktiválni kell a végleges verzióra, illetve meg kell várni, amíg benne lesz a meghajtóban az AGS 4.0 DX12-re is, hogy a Radeonok ott is a gyors shadereket fordíthassák a szabványosak helyett, mert így a DX11 előnyben van, hiszen ott már most is a gyors shaderket futtatják. Ezért van a Fury X a GTX 1070 és 1080 között. A DX12 target az, hogy a Fury X 4K-ban verje a GTX 1080-at, de ahhoz kell ebben a módban is az AGS 4.0, mert gyors kódok nélkül nem tudná megverni.
Az lehet, hogy megdöbbentő, hogy az új Deus Exben a Radeonok sokat gyorsulnak, ha a gyors kódot futtathatják a szabványosak helyett, de régóta pofázom, hogy a konzolokra másképp történik az optimalizálás, és ha azt az optimalizálást áthozzák PC-re, akkor a konzolos optimalizálásokból a Radeonok előnyt kovácsolnak. Lásd a Doom Vulkan módja. Ott is veszettül gyorsul a Radeon, de nem a Vulkan miatt, hanem a SPIR-V kiterjesztések miatt. Ez nem az AGS 4.0, mert ez csak DX11/12-re van, de ugyanazokat a lehetőségeket biztosítja, tehát a várható előny is ugyanaz.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#21342
üzenetére
Az AGS régóta létezik. Ez egy lib, ami kiterjesztéseket ad hozzá a DirectX API-hoz. A 4.0 azért lett lényeges, mert ez adja hozzá a rendszerhez a shader intrinsics függvényeket, amiket a Vulkan API-hoz a SPIR-V-n keresztül adtak hozzá. Ez ugyanazokat az előnyöket biztosítja DX12 alatt, amiket a Doom alatt biztosítottak a SPIR-V kiterjesztések a Radeonokhoz. Az AGS 4.0 azonban nem része a legfrissebb meghajtóknak, mert kisebb problémák miatt követték belőlük, vagyis a Deus Exbe épített Doomhoz hasonló GCN-es optimalizálások ezekkel a meghajtókkal nem futnának le Radeonon. Persze ettől még ki lehetne adni a DX12 módot, de úgy néz ki, hogy a GCN egy specifikus, konzolokhoz hasonló, teljesítményre kigyúrt kódutat kap, míg a több hardver egy általánosat, aminél nem a teljesítmény, hanem csak a működés volt lényeges. Lásd a Doom Vulkan módja, ahol a GCN és a többi hardver más-más kódot futtat. A GCN a Deus Exnél is egy úgynevezett gyors kódot kap a szabványos helyett. Ehhez szükséges az AGS4.0 megléte a meghajtóban, mert nélküle nem fut a gyors kód.
(#21351) namaste: Ha ez ilyen egyszerű lenne, akkor nem kellene bele DRM. A gond az, hogy GameWorks egy D3BC kódot tartalmaz, ami a rendszermemóriából elérhető. Ugyanakkor a meghajtó alapvetően nem tudja, hogy melyik az a shader, amit cserélni kell, mert a tárolt D3BC kód mindig változik, emiatt nem lehet shader cache-t alkalmazni GameWorksre. Ennek van egy változatlan és egy állandóan módosuló része, hogy egy szimpla check és csere ne működjön. A meghajtónak korlátozott ideje van lefordítani a shadert IR-re, mert a GameWorks DRM timebombot alkalmaz. Ez azt jelenti, hogy a shadert a meghajtó lefordítja, majd arról kell egy visszaigazolás a runtime számára. Ha a visszaigazolás időben jött, akkor rendben van, de ha nem, akkor a runtime újra elküldi ugyanazt a shadert, de már más néven és módosult kódrészlettel. Emiatt a meghajtónak sosem fog sikerülni úgy kicserélnie egy shadert, hogy időben küldjön visszaigazolást a runtime számára. Ezért kell magát a DRM-et megtörni, hogy a runtime-ból elküldött shader már eleve a kicserélt shader legyen.
(#21403) cain69: Az EA-nél ez kizárt. Inkább kiadják félkészen, de a startot tartani fogják. Lásd BF4.
(#21373) hpeter10: A BF1 által használt Frostbite-ban ezek a GCN-exkluzív függvények/funkciók lesznek benne: Ballot, mbcnt, Read lane, swizzle, ordered_count, barycentric-linearcentroid, HTile, min3/med3/max3. A GDC-n árulták el. A Frostbite későbbi verziójánál kutatják cross-lane operációkat, de ez még csak abszolút kutatás, mivel a konzolok nem támogatják, ugyanakkor a PC-s vezérplatform a DICE-nál a GCN3/4, ami viszont támogatja. Ez permutációt és DPP-t jelent. A DICE-nak ezzel nem titkolt célja az, hogy a Microsoft és a Khronos tagokat ösztökéljék arra, hogy ezek a funkciók a lehető leghamarabb legyenek ott a szabványban. Ennek az egyik legjobb módja, ha az egyik versenytársuknál kihasználják ezeket a képességeket.
-
Abu85
HÁZIGAZDA
válasz
oAcido
#21321
üzenetére
Valójában ahhoz van köze a döntésnek, hogy akadt egy kis gond az AGS 4.0-val, így a DX12-ből csak a szabványos shaderek futhatnának a startkor. Viszont ezt az AMD nem akarta, így addig vár a DX12 leképező, amíg a driverben nem lesz újra aktív az AGS 4.0 opció. Ez nyilván egy stratégiai döntés, hiszen az AGS 4.0 +20-40%-ot is hozzáadhat a szabványos DX12 sebességhez. Ez azért nem mindegy, hogy ott van a Radeonokon, vagy nincs.
-
Abu85
HÁZIGAZDA
válasz
Venyera7
#21308
üzenetére
Nem lesz AGS 4.0 benne.
(#21316) Loha: Ez nem kérdés, mert átment. Erről papír van, ahogy az AMD is megírta a linkelt oldalon. A kérdés itt az, hogy a hitelesítéssel van gond, vagy az jó, és akkor nem a mérnökök hibáztak, hanem a hobbimérések. Ez jelenleg is kivizsgálás alatt van.
-
#21294
Abu85
HÁZIGAZDA
FollowTheORI
#21293
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#21293
üzenetére
Erre van a kompatibilitási mód. De ha nem 2003-as, vagy az előtti gyártású a tápod, akkor ezzel nem kell foglalkozni, mert a nem referenciakártyák 99%-a többet kér a 6/8 tűn. Ennek az oka, hogy feltételezik, hogy ma már nem sok felhasználónak van 2003 előtti tápja. Már a 2005-ös tápok is minden probléma nélkül átvittek 6 A 12 V-os ágon. Ma már vannak olyan tápok, amik 10A fölött sem problémáznak bizonyos csatikon.
Tervezni egyszerű. Meg volt adva a mérnököknek, hogy mi a határ. Letervezték arra, és át is ment a hitelesítésen. Utána merültek fel a kérdések a hitelesítés helyességével kapcsolatban. Innen még simán lehet, hogy a mérnököknek van igazuk, és nem a tesztelőknek, de érdemes kivizsgálni.
-
#21292
Abu85
HÁZIGAZDA
FollowTheORI
#21279
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#21279
üzenetére
A szoftveres fix arra vonatkozik, hogy valójában az AMD-nek sem éppen tiszta, hogy mi az, ami a tényleges határ. Van egy hitelesítésük a PCI-SIG-től, hogy megfelel az RX 480, és emiatt rajta is van mindegyik referenciatermék dobozán a PCI Express logó. Ezt nem rakhatják rá hitelesítést bizonyító papír nélkül. A gond az, hogy a történtek után át kell gondolni, hogy mi történt, mert lehetett az, hogy a PCI-SIG jobb eszközökkel dolgozik, mint egy átlagos újság, vagy lehetett az, hogy a hitelesítési teszt hibás. Mivel ma még erre nincs válasz, így az AMD megcsinálta, hogy az ominózus meghajtótól kezdve átcsoportosította az energiafelvételt. Egyrészt mindkét módban alacsonyabb lett a PCI Express slotból való áramfelvétel, másrészt van egy compatibility mód is, ami a TGP-t is csökkentette egy picit, így a 2003 előtt gyártott tápokkal sem lehet gond.
A hitelesítési tesztre vonatkozóan szerintem az elkövetkező hónapokban nem lesz változás, de biztosan megvizsgálják.
-
#21289
Abu85
HÁZIGAZDA
FollowTheORI
#21275
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#21275
üzenetére
Nem. A gond az, hogy azt a listát fél évente ha frissítik, mert nem az alapján van eldöntve, hogy mehet-e a logó a dobozra vagy sem. Erről a PCI-SIG egy hitelesítést ad az adott gyártónak. Ezért van rajta a dobozon a PCI Express logó, mert a hivatalos teszteken átment, és megvan a hitelesítés. A listába pedig bekerül, ha valaki leül és frissíti, de a PCI-SIG-nél ez nem fontos szempont, mert nem ez a lista dönt arról, hogy rakhatnak-e rá logót, hanem egy konkrét és direkt mérés eredménye, amiről lesz egy jegyzőkönyve mindkét félnek. Az AMD elismerte, hogy a termék átmegy. [link] - nem csak a belső tesztjeik alapján.
Rég nem az a probléma, hogy nincs meg a PCI-SIG hitelesítése az referencia RX 480-nak, mert ez hivatalosan megvan neki. Az a kérdés ma már, hogy nem kellene-e ezt a hitelesítési módszert felülvizsgálni, mert kérdések merültek fel a helyességével kapcsolatban. Ez most ami a PCI-SIG-nél is zavart okoz, mert nekik most át kell gondolni, hogy a hitelesítésük helyes-e, vagy tényleg vannak olyan helyzetek, ahol probléma lehet. Emiatt valószínűleg egy ideig ezt a listát nem is frissítik, mert egyelőre céltalan lenne belerakni az új hardvereket. Nincs is benne egyetlen olyan új VGA sem, ami nyáron jelent meg.
-
Abu85
HÁZIGAZDA
válasz
killer095
#21272
üzenetére
A swapchain API-k arra valók, hogy szabványos támogatást lehessen írni minden DX12-es programba. Onnantól, hogy a meghajtó támogatja a swapchain API-kat, mindegy lesz, hogy milyen az implementáció. A variálható frissítés egyszerűen működni fog. Bizonyos fejlesztők csupán szeretnének natív támogatást kínálni, mert több lehetőséget biztosít. A swapchain API-k egyöntetű jellemzője, hogy mindent egységesít, vagyis a FreeSync és a G-Sync egységes pontjait működteti, de az egyedi funkcióik nélkül. Ez persze a felhasználók többségének így is elég.
(#21271) cain69: [link] - ebben le van írva, hogy milyen szituációban mi történhet.
-
Abu85
HÁZIGAZDA
válasz
killer095
#21263
üzenetére
Nagyon egyszerű. Az, hogy nincs natív támogatás nem jelenti azt, hogy nem fog működni. A "hogy van" esetében először is külön kell választani a DX11-et és a DX12-t. A DX11 nagyon egyszerű, mert ott a meghajtó számára megoldható a vezérlés, ugyanis láthat, hogy hol van a képkockapuffer. A DX12 esetén ez nem igaz, ugyanis a meghajtó egy nagy bináris pacát lát. Sokmilliárd 0-t és 1-est, és halvány gőze nincs arról, hogy ezen a végtelenül nagynak tűnő tartományon belül hol van a képkockapuffer. A program több dolgot tehet a variálható frissítés működése érdekében.
1. Megmondja a meghajtónak a címtartományt, de ez nem ajánlott, mert a meghajtó akkora erre lesz beállítva, és minden egyes frissítés után működésképtelenné válik a rendszer, amíg egy új meghajtó nem jön az új frissítésre.
2. Sokkal kézenfekvőbb tehát a Swapchain API-kat támogatni, amelyek szabványosan kínálnak egy teljesen elfogadható megoldást a variálható frissítésre vonatkozó támogatásra. Ilyenkor a meghajtó mindig tudja, hogy mit kell tenni, mert a swapchain API-k gondoskodnak a működésről. A programfrissítés nem gond, ahogy a meghajtók változása sem.
3. A legátfogóbb támogatás a natív támogatás, amikor az adott implementáció natív kezelését választja a program. Ilyenkor az alkalmazás és a meghajtó együtt vezérli az egészet. Ez Swapchain API-kat használó megoldáshoz hasonló működést kínál, csak lehetőséget ad még olyan extrákra, mint a V-Sync párhuzamos kezelése is, vagyis a felhasználó dönthet, hogy a variálható frissítést hogyan szeretné használni. A tartományon kívül képtöréssel, és akkor nem lesz limitálva az elérhető fps, vagy képtörés nélkül, és akkor a tartomány minimumán és maximumán kívül sincs képtörés, sőt a maximum fölé nem is megy.Adaptive-Sync tartományok a táblázatban: [link]
A minimális értéknél a FreeSync bonyolultabb, mert bizonyos kijelzők támogatnak LFC-t, ami tulajdonképpen a minimum frissítést alaposan kitolja. De egyik LFC-s kijelző esetében sem alacsonyabb a minimum 25 Hz-nél. -
Abu85
HÁZIGAZDA
válasz
daveoff
#21255
üzenetére
Ennek a legfőbb oka az, hogy a Battlefield 1 csak FreeSync-et támogat natívan. A G-Sync-re nem natív a támogatás, hanem a Microsoft swapchain rétegein keresztül működik, és ugyanez igaz a nem FreeSync-es Adaptive-Sync implementációkra. Valószínű egyébként, hogy a swapchain API-k a mostani programverzióban még nincsenek is támogatva, ezért ma még csak a FreeSync működik a natív támogatás mellett.
-
Abu85
HÁZIGAZDA
válasz
namaste
#21240
üzenetére
Csak úgy tudják kicserélni a shadereket, ha ki tudják ütni azt a DRM-et, amin keresztül működik. Ezáltal a rendszer képes ebbe az izolált környezetbe betölteni egy külső shadert. Más formában a GameWorks runtime nem tölt be D3BC-t.
A GameWorks működése egyszerű. Maga a fejlesztő nem szállít direkten GameWorks shadert, azt egy zárt rendszer hordozza, amit az NV odaad. Azt kell beépíteni a programba. Ilyen formában lehet biztosítani azt, hogy a fejlesztő ne módosíthassa a forráskódot, és ne töltsön be egy alternatív D3BC-t a szállított helyett. Volt már ilyenre példa az AC Unity esetén. Ott az Ubisoft írt egy alternatív D3BC-t a Geometry FX-re, de annak a működését a végső GameWorks DRM megakadályozta. Ezért Geometry FX nélkül jelent meg a játék, annak ellenére, hogy agyon volt reklámozva tesszellált felületekkel, amiből végül egy deka tesszellálás nem lett. Pedig a shader az első verzióban ott volt a játékban, csak a GameWorks DRM miatt nem töltődött be. Aztán a későbbi patch-ekkel eltávolították, mert nem jutott megegyezésre az NV és az Ubisoft.
Az AMD számára a DRM feltörése azért fontos, hogy be tudjanak juttatni ebbe a zárt környezetbe egy kicserélt D3BC shadert. Ugyanezt csinálja egyébként az NV is, csak nekik egyszerűbb a saját rendszerüket kijátszani, mert ők írták a DRM-et. Azért sem szólnak igazán az AMD törései ellen, mert ők is tudják, hogy erre szükség van, hogy a GameWorks egyáltalán működjön. Meg eleve a DRM-et a fejlesztők optimalizálásai ellen tervezték, és nem a gyártóik ellen. A gyártó még a D3BC után is tud módosításokat végezni, csak jóval nehézkesebben, de ha kell, akkor akár minden játékra állítanak egy csapatot és megcsinálják. A fejlesztőnek a D3BC shader cseréje az egyetlen lehetőség arra, hogy gyorsabb kódot futtassanak, de a DRM ezt megakadályozza. Ahhoz tehát, hogy a fejlesztői akarat érvényesüljön az adott shadert az NV-hez kell elküldeni mondva, hogy ezt akarják futtatni, és az NV vagy beépíti, vagy ajtót mutatnak.
A shadert nagyon egyszerű megszerezni. Az még a fejlesztőknek sem okoz igazából fejtörést. Cserélni problémás.
Manapság a shaderek cseréje egyre ritkább. Ennek a fő oka az, hogy sokkal egyszerűbb a fejlesztőkhöz odamenni még a megjelenés előtt pár héttel és mondani nekik, hogy ez a shader nem az igazi. Adni helyette egy jobb shadert és azt építik be. Ez nem csak hatékonyabb fejlesztés a teljes iparág számára, hanem megakadályozza azt is, hogy hetekkel a játék kiadás után kelljen a megírt és letesztelt új shadert biztosítani a meghajtóban. Persze ez ma sem akadály, de ma már az új meghajtók nem hoznak +30-40%-ot, hanem leginkább 4-10%-ot, mert ma már nem igazán nyerő nagyon rossz hatékonyságú shadert szállítani. A legtöbb stúdiónak ma már egy zárt csatornája is van, ahonnan a forrást a gyártók elérhetik, és tehetnek javaslatokat a jobb teljesítmény kinyerése érdekében. Ez sokkal hatékonyabban működik, mint a régi modell. -
-
Abu85
HÁZIGAZDA
válasz
=WiNTeR=
#21233
üzenetére
Arra nincs meg. GoG accountunk sincs. Még nem kellett.
(#21234) cain69: Hát igen, csak az dupla kiadás.
(#21235) Loha: Az a baj, hogy a szervereiken van, és sajnos a játék indításakor csatlakozik.
Kicsi az esélye, hogy a Denuvónak ehhez van köze. Az a Partner alkalmazásban is benne van, mégis annyiszor cserélünk hardvert, ahányszor akarunk. Ez inkább egy szerver oldali ellenőrzésnek tűnik. -
Abu85
HÁZIGAZDA
válasz
Locutus
#21231
üzenetére
Egy csomó játék ilyen már, mert ezzel akadályozzák meg a cégek az account kölcsönzést. Az Origin ezt általánosra alkalmazza, vagyis, ha 24 órán belül öt különböző gépen elindítasz egy-egy játékot az adott felhasználóval, akkor a hatodik gépen már nem enged indítani semmit, és 24 óráig ez így is marad. A Steamen alapértelmezetten ilyen nincs, de már nem egy játék használ ilyen védelmet, amelyek 24 óráig három vagy öt gépre korlátozzák a játékot. Ilyen például a Total War Warhammer. Nem is a normál játékot teszteljük, hanem egy DRM nélküli Partner verziót, ami mentes ettől a limitációtól. Ez a verzió azonban nem vásárolható meg.
Technikailag úgy lehetne megoldani a tesztelést, hogy kevesebb VGA legyen a tesztekben, vagy előre le kell mérni egyes VGA-k eredményét. Egyik sem ideális, amikor számos teszt van még a nyakunkon, mert Gyuri mester nem csak VGA-kat mér. Ilyen időbeosztással nagyon fontos a tervezhetőség, amit a program oldali limitek felrúgnak. Ha lenne mondjuk még egy ember a tesztekre, akkor nem lenne probléma, de így nagyon nehézkes.
Jelenleg leginkább azt szeretnénk elérni, hogy az Origin accountunkat mentsék fel a korlátozás alól, de az EA nem nagyon hajlik rá. Pedig mi aztán nem játszunk ezen, hanem csak tesztelünk, és időre megy a teszt, ezért nagyon zavarók a limitek. -
Abu85
HÁZIGAZDA
válasz
Locutus
#21212
üzenetére
Minden origin játék fos tesztelői szempontból. 24 órán belül csak 5 hardvert lehet cserélni, vagyis egy hatodik VGA-t egy nap már nem tudunk tesztelni, mert 24 órára kibannol a rendszer. A GTA5 pedig ott van még a tesztekben. Addig ott lesz, amíg nem jön új játék, amivel le lesz cserélve.
Doom benne lesz a tesztekben, csak nem tudtuk volna újramérni az összes korábbi VGA-t. De a következő tesztcsomagnak a része lesz, hiszen támogatja a Vulkan API-t.Biztosan nem lesz No Man's Sky teszt, esetleg csak akkor, ha megoldják azt, hogy ne váljon 24 órára használhatatlanná a játék, ha berakjuk a negyedik VGA-t. Esetleg csinálnak egy olyan partner verziót, ami van a Total War Warhammerből, így nem kell a játék DRM-jének a korlátozásaitól függni, ami korlátozza a napi VGA cserét. Ugyanakkor a No Man's Sky nem valami erős cucc a tíz évvel ezelőtti grafikai színvonallal.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#21203
üzenetére
Mint írtam, azok a játékokban, amelyek technológiailag nem képviselik a csúcsot nem is igényelnek olyan erőforrást, mint a csúcsot képviselők. Emiatt akármit választasz jó lesz vele a működés. Kivéve az elbaszott optimalizálású játékok, mint mondjuk az új No Man's Sky. Ott nyilván mindegy, hogy mit veszel alá. Ezen belül lehetnek egyedi szempontok, mint mondjuk a variálható frissítés, például a G-Sync nem működik vele, míg a FreeSync igen, stb.
(#21202) hpeter10: Leginkább a Civilization 6 a megfontolandó az AMD-nek, mert a Civilization 5-öt rengetegen játsszák. A játékosok heti átlagos száma ver minden játékot a tesztcsomagunkból. Nem is kevéssel. Még ha összeadjuk a tesztben szereplő játékok heti játékosainak számát, akkor is magasan a Civilization 5 vezet. Valószínűleg a Battlefield 1-et sem fogják annyian játszani, mint a Civ 6-ot.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#21198
üzenetére
Azok a játékok, amelyek népszerűek (Dota2, CS:GO, TF2, Garry's Mod, Civ5, aktuális FM, LoL) kenyérpirítón is futnak.
A technikai színvonal azért állandó szempont, mert ha ezekben jó az adott hardver, akkor a technikailag elmaradott, de népszerű játékokat is simán megoldja.Bármi, ami online tesztelhetetlen a sok szerveres hibalehetőség miatt. Olyan program kell tesztre, ami állandó környezetben mérhető, hogy az eredmények összehasonlíthatók legyenek.
(#21199) Keldor papa: Tudtommal a Vega 11 jön hamarabb. Ugyanazokkal a paraméterekkel, amilyennek a Fiji, plusz 20-30%-kal magasabb órajellel, alacsonyabb fogyasztással, illetve HBM 2-vel. A Vega 10 a nagyobbik lapka. Ez lehet a csúcsmodell, de ennek a paramétereiről még senki sem hallott.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#21195
üzenetére
Ez különösen a DICE-t nem érdekli. Ők valószínűleg most is felkínálnak majd egymillió kódot 8-10 dolláros áron, ahogy azt szokták. Az AMD-n múlik, hogy elfogadják-e. Ezt másnak nem ajánlják fel, mert a DICE erre amolyan köszönetnyilvánításként tekint. Tulajdonképpen csak ilyen formában tudják viszonozni azt, amit kapnak, mert az AMD-n kívül más az igényeiket nem hallgatja meg. A presztízsérték miatt van esély rá, hogy elfogadják, de a racionalitás azt diktálja, hogy a többi partner ünnepi címe olcsóbb.
A közhiedelemmel ellentétben egyébként ezek a kódok leginkább a nagyobb áruházakban lesznek felhasználva. -
#21194
Abu85
HÁZIGAZDA
#Morcosmedve
#21191
Abu85
HÁZIGAZDA
válasz
#Morcosmedve
#21191
üzenetére
Nem biztos, hogy lesz Battlefield 1 bundle. Azért a DICE mindig is elkérte a pénzt ezekért a kódokért. 8/10 dollár/kód, és ez az AMD-nek 5-10 millió dollárjába került általában. Más cég ennél sokkal olcsóbban kínál promócióra kódot, mert belefoglalják a partnerszerződésbe. A DICE ilyet nem csinál. Ők a tudásért szerződnek és nem a pénzért. Ezt számításba kell venni, mert a Battlefield 1 mellett lesz még Civilization 6, Watch Dogs 2, stb. Szerintem a fő bundle cím az év további részére leginkább az új Deus Ex lesz.
-
#21185
Abu85
HÁZIGAZDA
FollowTheORI
#21144
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#21144
üzenetére
Különösebb változást a hardverben a Samsung 14 nm LPP nem fog okozni. Nagyon hasonló a karakterisztikája a TSMC 16 nm-es FF+-hoz. A lapkaméret persze csökkenhet, de főleg azért mennének a Samsunghoz, mert szükségük van lapkákra, amit a TSMC nem ad meg nekik. Korábban már írtam, hogy az NV a TSMC-nél sokadig megrendelő, vagyis addig nem gyártanak nekik többet, amíg az Apple, a MediaTek, stb. igényeit ki nem szolgálják. ÉS ehhez képest a TSMC-nél a 14/16 nm-es wafer ára nagyon magas. A Samsung sokkal olcsóbban kínálja, a GloFo pedig még olcsóbban. A TSMC ma már nem nyerő egy GPU-kat fejlesztő cégnek.
(#21152) Keldor papa: A grafikus API-k felépítése miatt a GCN verziók nem olyan lényegesek. A GCN2-3 semmiképp, és a GCN4 sem. Persze épp a múlt héten derült ki, hogy lesz a GPUOpen shader intrinsics-ben permutáció és data-parallel primitives (DPP), ami GCN3 és GCN4 only cucc, de ennyiben ki is merül az ISA előnye. Ezeket azért elég kevesen fogják használni játékokban, mert a kutatások főleg a konzolra történnek, vagyis GCN2-re. Amiért bekerülnek az a Star Citizen, mert ott lesz pár eljárás, ami ezekre épül.
Emellett a Vega az GCN5.(#21156) Loha: Semmi köze a játékválasztásnak ahhoz, hogy mi NV-s és mi AMD-s. Pusztán technológiai szempontok döntenek. Az AMD csak azért kerül előnybe, mert jóval több technológiai előrelépés tesznek le az asztalra, mint az NV. De az NV-nek sem mondja senki, hogy ne fejlesszenek új leképező technológiákat, amelyeket a partnerek be tudnak vetni.
Ezzel egyébként nem tudunk igazán mit kezdeni. Az NV idén például egy DX12/Vulkan játékot hozott (Rise of the Tomb Raider). Az AMD hozott négyet (AotS, TW: Warhammer, Hitman, Doom). A bejelentett játékok között az AMD biztosan hoz még hármat (Civilization VI, Battlefield 1, Deus Ex: Mankind Divided), az NV pedig egyet (King of Wushu). Már pusztán emiatt az AMD-nél a mennyiségi előny. Beraknánk mi NV-s DX12/Vulkan játékokat, de nem igazán léteznek ilyenek. Arról nem is beszélve, hogy a Dishonored 2 és a Watch Dogs 2 esetében is az AMD mondta, hogy segítik a fejlesztőket, míg az NV ezt a két címet meg sem említi. Pedig előbbi állítólag Vulkan, míg utóbbi DX12-es lesz.
Az tisztán látszik, hogy az NV inkább az indie játékokra koncentrál. Ők a GameWorks stratégiával leginkább arra rendezkedtek be. Tripla-A-s címeket ezzel a stratégiával nagyon nehéz szerezni. Az AMD ezzel szemben a GPUOpennel szinte csak Tripla-A-s címeket tud szerezni, és indie között csak a nagyon nagy költségvetésű játékokhoz jók, máshoz nem.A GameWorks azért van mindenhol kikapcsolva, mert azokra mindig vannak a driverben trükkök. Az NV és az AMD is kicseréli az eredeti shadert, vagyis innentől kezdve az egész egy specifikus trükközés lesz. Ennek az a hátránya, hogy mindkét gyártó más shadert futtat végeredményben. Elvileg ezt nem tehetné meg az AMD a licenc miatt, de szarnak rá, és feltörik a GameWorks DRM-et, míg az NV ezért nem perli be őket, mert úgy gondolják, hogy nagyobb lenne a felháborodás, ha kiderülni, hogy a GameWorks egy DRM-et rak a játékba. A másik oldalon a Mantle nem befolyásolja a többi hardver teljesítményét.
A Hitman azért ilyen, mert ez az első játék, ami executeindirect funkviót használ. Le is írtam, hogy ezért van benne. Egészen pontosan egy GeometryFX konstrukció van bele építve, bár nem pont az, ami a GPUOpenen elérhető. Ez azért érdekes, mert az új Frostbite ugyanígy fog működni.
Ma már rég nem jelent semmit a játék elején megjelenő logó. Attól, hogy a Division TWIMTBP játék, a kódot konzolra fejlesztették, tehát alapvetően GCN-re. -
Abu85
HÁZIGAZDA
válasz
Peat;)
#21112
üzenetére
Nyilván az RPG elégé átfogó fogalom. Természetesen tisztában vagyok vele, hogy a Deus Ex, a Wincher, a Dragon Age Inquisition, vagy a Dishonored sem igazi RPG, ezért írtam RPG-szerűséget. Ismerem egyébként az RPG-ket, és játszom is az egyik aktuális címmel, csak az nem igazán csúcstechnológia. De nyilván, ha valaki igazi RPG-t akar, akkor a Pillars of Eternity-t veszi elő.
Ugyanakkor az új Deus Ex sorozat, a Witcher sorozat, a Dishonored, és a Dragon Age Inquisition nagyjából egy szinten van az RPG-k világában. Talán a Dragon Age valamelyest átfogóbb, közelebb van a hardcore irányhoz, mint a többi.(#21114) miklosss2012: Jó munkához idő kell.
(#21103) mlinus: A tömegjátékok főbb jellemzője, hogy nem rendelkeznek akkora gépigénnyel, mint azok az új játékok, amiket mi tesztelünk. Másképp nem tudnak tömegjátékká fejlődni.
-
Abu85
HÁZIGAZDA
válasz
velizare
#21086
üzenetére
Felőlem lehetett volna. Ma már igazából mindegy. Ez az RPG vonal úgy alakult ki, hogy eredetileg a Dragon Age Inquisition volt betervezve, de aztán Oli azt mondta, hogy ő inkább a Shadow of Mordort akarja, mert kevés volt az NV-s cím a tesztcsomagban, és jobban is szerette ezt a játékot. Én meg mondtam, hogy akkor legyen az. Amikor erről döntöttünk, akkor még nem létezett Witcher 3, és ez így maradt rajtunk. Mostanra lényegtelenné vált, mert a következő RPG-szerűség a Deus Ex lesz, illetve van némi információnk arról, hogy a Dishonored 2 milyen API-t használ. Nagy az esélye, hogy Vulkánt választanak a fejlesztők a DX12 helyett, mert eredetileg egy Mantle kódjuk volt, és Vulkánra azt könnyebb átrakni. Szóval ha minden jól alakul, akkor lesz egy Vulkan RPG és egy DX12 RPG.
(#21107) huskydog17: Válasz fent.
A Forza 6 nagyszerű, csak borzalmasan körülményes UWP-s programot tesztelni. A Quantum Break is csak azóta merült fel, mert pár hete tudjuk, hogy lesz Win32 API-ra írt változata. UWP programot jelen formájában csak úgy lehet jól mérni, ha van benne benchmark. A WCCFtech erről már tudna mesélni, mert háromszor módosították a teszteredményeket a teszt megjelenése óta a Forza 6-ra. [link] - ami technikailag ilyen problémás, az nem való tesztbe, mert nagy esély van vele hibás eredményeket közölni.
-
Abu85
HÁZIGAZDA
Általánosan felmerült a játékok kérdése, hogy mi hogyan kerül bele a tesztbe. Itt leírom. Alapvetően 9 slotunk van, mert ki van számolva, hogy jellemzően mikor kapunk VGA-t a tesztekre, és abba az NDA-k lejártáig 9 játék fér bele nagy biztonsággal. Persze ez a szám nincs kőbe vésve, ahogy láthatjátok majd, hogy most épp 11 játékkal mérünk, de az a maximum. A 9-11-es tartománytól nem tudunk elmozdulni, mert ez az egész mégiscsak időre megy, ergo sosem lesz benne a tesztekben a világ összes játéka. Sorry. Innentől kezdve szelektálni kell valamivel. Általában szeretünk minden lehetőséget legalább egy játékkal lefedni, és ha van lehetőség rá, akkor ezeket az igényeket kombináljuk, összekötjük a kellemest a hasznossal, ha nyersen akarunk fogalmazni. Lehetőség szerint minden nagyobb műfajból tesztelünk minimum egy játékot. A mostani játékfelhozatalból az játékok az alábbi miatt vannak bent:
- Tom Clancy's The Division - képviseli a TPS/akciót, a Snowdrop motor miatt, amire annyira verte az Ubi.
- GTA V - képviseli a TPS/akciót, a korábbi minősíthetetlen GTA portok után végre valami megütötte az elégséges szintet.
- Sniper Elite 3 - képviseli az FPS/sniper játékokat, illetve alapvetően imádjuk az indie stúdiókat, mert ott még nem a vízfejű kiadói vezetőség dönt. Emiatt minden esetben helyet biztosítunk egy olyan játéknak, amelyet indie stúdió fejlesztett, és ezen belül is az elérhető legjobb technikai színvonalat valósítja meg. Jelen esetben ez a Sniper Elite 3. Persze az elmúlt években is a Sniper Elite volt itt a nyerő, ami sajnos jelzi azt is, hogy kiadói segítség nélkül dolgozni kemény dolog, így a megszerzett technikai előny egy indie stúdiónál évekig megmarad. Ez érthető is, mivel kiadói háttér nélkül nem ömlenek a milliók a felzárkózásra. A Sniper Elite 3 mutatja meg ma, hogy mi az amit el lehet érni egy nagy kiadó segítsége nélkül.
- Thief - képviseli a FPS/tolvajos vonalat, és ez az egyetlen játék, ami Unreal Engine-et használ.
- DiRT Rally - képviseli a verseny vonalat, és ez a legfejlettebb technológiát használó autóverseny.
- Middle-earth: Shadow of Mordor - képviseli a TPS/RPG vonalat, és nincs más RPG-szerűség a tesztcsomagban
- Ashes of the Singularity - képviseli az RTS vonalat, az egyetlen játék, amelynek a motorja texel árnyalást használ
- Total War: Warhammer - képviseli az RTS vonalat, sok rajzolási paranccsal dolgozik, így ideális DX12-re (nem mellesleg magyar fejlesztő is dolgozott rajta, a DX12 leképezőn).
- Hitman - képviseli a TPS/lopakodós vonalat, használja az execute indirect képességét a DX12-nek.
- Rise of the Tomb Raider - képviseli a TPS/akció vonalat, az egyetlen NV-s DX12 játék, ami létezik.
- Far Cry Primal - képviseli az FPS vonalat, a Dunia 2 miatt került be. -
#21080
Abu85
HÁZIGAZDA
Petykemano
#21077
Abu85
HÁZIGAZDA
válasz
Petykemano
#21077
üzenetére
Nem így van.
Az a lényeg, hogy mindig van egy hangos kisebbség, akiknek valami sosem tetszik, de valójában azt, aminek hangot adnak, sosem tudják bizonyítani. Hiába kéred, hogy emeljék ki a problémás részeket az írásokból. Ennyi. Ha valaki nem csak károg, és hoz valamiféle értelmes dolgot, akkor azt nyilván mindenki meghallgatja, még én is. 
(#21079) miklosss2012: Már le is tesztelték a srácok. Szerintem hétfőn megjelenik, de én szabin vagyok szóval erről nem dönthetek.
-
Abu85
HÁZIGAZDA
A Quantum Breakben nyilván nem kapcsolható ki. Annak a motornak a jellegzetessége, hogy nem támogat normális textúraszűrést, tehát mindenképpen kezelni kell a textúrák stabilitását. Ha kikapcsolhatóvá tennék, akkor az nagyon zizegős képet eredményezne.
A legtöbb fejlesztő nem teszi kikapcsolhatóvá az async compute-ot. A játékok között egyedül az AotS-ben kapcsolható ki. Más formában a meghajtóba kell egy olyan profil, ami a compute parancsolat az OS-nek küldi tovább. De csak azért, hogy lehessen mérni a különbséget nem csinálnak olyan meghajtókat, ami mindkét működési módot tartalmazza.
Igazából a legtöbb játékban ez nem GCN-onlyra van megírva. Egyszerűen az NV meghajtói nem a GMU-k parancslistájába, hanem az OS-ébe töltik be a parancsot. Kivéve a Pascal és a Rise of the Tomb Raider. Volt régen olyan kód, ami direkt gyártóspecifikus volt, de ma már ezt kiszedték mindegyik programból. Jobb ezt a meghajtókkal kezelni, mert ha a program oldalán kezelik, akkor például örökre kizárják az NV-t a gyorsulás lehetőségéből. Érthetően ezt nem akarják.És ez itt a probléma az egésszel. Van a konzolról egy fordító, ami fordít HLSL XO nyelvre, és azt a fordítót percek alatt kompatibilissé lehet tenni az AMD shader kiterjesztéseire. Majd onnan mehet a SPIR-V fordítás. Ezért egységesítés ez a fejlesztők szemében. A szabványos SPIR-V-re sokkal nehezebb dolgozni a konzolhoz írt fordítóknál.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#21036
üzenetére
Nem tudom, hogy melyik DX11-es játék megy vagy marad. Azt nem én döntöm el. Nekem mindegy, hogy melyik megy.
(#21037) gbors: Igen az a terv, hogy záros határidőn belül áttérjünk az új irányra. Mi voltunk az elsők a médiában, ahol csak DX11-es játékokkal teszteltek, és szeretnénk mi lenni az elsők, ahol csak explicit API-val tesztelnek. Minden szempontból ez az ideális, mert így jóval hamarabb tudunk az olvasóknak jövőbiztos teszteket készíteni.
-
Abu85
HÁZIGAZDA
Nem. Öt DX12-es játékot akarunk a következő körbe, és mellé öt DX11-est. A DX12-esek közé menne a Quantum Break. Mivel ma négy DX12-es játékot tesztelünk, így ez extra lesz. A DX11-esekből nem tudom, hogy melyik marad és melyik megy. Azt nem én intézem. Az biztos, hogy a Doom az egyik DX11-es játék helyére kerül. Az is lehet, hogy a Civ6 és a Deus Ex kerül be a DX12-esek közé. Mivel nem akarunk három stratégiát ezért az AotS vagy a Warhammer megy.
Ez lesz nagyjából az ősz. Míg télen átállunk teljesen DX12 és Vulkan játékokra. -
#21031
Abu85
HÁZIGAZDA
huskydog17
#21028
Abu85
HÁZIGAZDA
válasz
huskydog17
#21028
üzenetére
Az API-nak semmi köze ahhoz, hogy a Quantum Break mennyire jó játék a kritikusok vagy a felhasználók szemében. Nem a technológiával játszanak, hanem a játékkal.
A DX11-től ne várjatok csodát, mert ez alapvetően egy DX12-es motor, ami viszonylag sokat nyer a DX12-től. A DX11 csak elindíthatóvá teszi a játékot Windows 7-en is, de más előnye nem lesz. Sőt, inkább elvesz a sebességtől, mert nem tudja majd párhuzamosan számolni a volumetrikus fényeket, amelyek a képszámítás nagy részét teszik ki. Nem tud majd másolni sem a temporális projekcióhoz anélkül, hogy a másolás idejére ne állítaná le a GPU-n a munkát. Ez ugye azért van, mert a DX11-ben csak szinkron copy van definiálva.Az alapján amit láttam a játékból technikailag igen rendben van. Megnéztem GPUView-vel. A függetlenségünket egy játék nem befolyásolja. A különbség a vélemények között az, hogy én megnéztem a programot a profilózokkal, illetve utánanéztem az alkalmazott leképezőnek, míg más esetleg nem.
Ezt a 10 éves lemaradást egy olyan programra írod, amely a piacon egyedüliként használ texel árnyalási módszert. Ez az az árnyalási fajta, amire a Pixar animációs filmek épültek. Érdemes elolvasni a texel árnyalás előnyeit. Idei Eurographics paper: [link] - egyre több motorban találkozunk majd vele. Nyilván a Nitrous annyiban előnyben volt, hogy eleve a nulláról építkeztek, tehát volt lehetőség a legjobb árnyalást választani. A többieknek azért nehezebb lesz a váltás, mert számottevő problémát jelent majd a assettekkel való kompatibilitás megőrzése. Emiatt például a szokásos deferred és forward irányok mellett jönnek majd az extrém leképezők, amelyek már bevetik például a deferred texturázást is (az Eidos Dawn motorja erre megy el). Hosszabb távon viszont az objektumtérbe érdemes vinni az árnyalást. Itt elő lehet venni a Quantum Break-et megint, mert a saját leképezőjükkel pont azokra a problémákra akartak reagálni, amelyekre a Nitrous reagált, vagyis a textúrák stabilitását akarták jelentősen javítani. Ha tehették volna, akkor ők is mentek volna az objektumtérbe, de túl nagy változást igényelt volna a motorban. Ez az ami sokaknak nem tetszik, mert annak ára van, hogy a textúrák stabilitását utókezeléssel éred el. A Nitrous előnye ezekből adódik össze. Szinte minden egyes leképezéssel kapcsolatos jelentős problémára olyan megoldásokat kínál, amelyek nem hoznak magukkal jelentős mellékhatásokat. Ezért ez a motor az, amit ma leginkább követnek a stúdiók kutatásai.
-
Abu85
HÁZIGAZDA
Nem a befürdésről van szó, hanem a lehetőségekről. Ma nem lehet úgy megoldani a problémákat, hogy minden maradjon jó minőségű. TXAA, vagy más temporális projekció mindegy, mert a cél minden esetben a filmes hatás. A filmeken is nagyon durván alkalmaznak elmosást.
Nyilván lebutítható a játék a rajzolási parancsok tekintetében, de mondjuk úgy lenne jó a CPU-limit kitolása, hogy a konzolon és a PC-n is elérhető legyen ugyanannyi objektum a kijelzőn, lehetőség szerint hasonló LOD, és hasonló árnyékminőség mellett. Mivel a konzolok jóval többet tudnak rajzolni, mint a PC-k, így az egyetlen lehetséges irány a PC-s API-k cseréje volt. Nem hiszem, hogy bárkinek a fején átkúszott az a gondolat, hogy tartsuk meg az aktuális API-kat, és akkor PC-re meg korlátozzák a látótávolságot. Meg lehet csinálni, csak nem célszerű.
+10-20% azért elég jó. Az persze igaz, hogy jelen formában leginkább GCN-only.
A legtöbb mai játékban az async compute úgy van kialakítva, hogy a shadow mapok számítása mellé legyen betolva valami compute feladat. Ezt semmilyen más formában nem lehet megcsinálni. Akármilyen hardveren malmozni fognak a shaderek, mert a shadow mapok számítása ROP limitált. A GPU-k heterogén jellege miatt számos grafikai futószalag olyan, hogy nem igazán bántja a shadereket, amelyeken ezekben az időszakokban lehet futtatni bármilyen compute futószalagot.
A fejlesztők problémája nem kifejezetten az, hogy az async compute nehéz, hanem az, hogy általánosan jól megírni nehéz úgy, hogy működjön minden hardveren. Ezért írják ma meg nagyrészt csak GCN-re, mert túlságosan eltér a többi hardver a konzoltól, hogy az arra kialakított futószalagokat jól át lehessen hozni PC-re.
Vannak más játékokról is fejlesztői adatok, hogy az async GCN-ekkel mennyit hoz:
Hitman 5-10%
Warhammer 5-15%
Doom (8xTSSAA) 10-20%
Quantum Break 10-15%Más játékokra nincs pontos adat, de tudni lehet, hogy a Forza 6, a GoW és az új Tomb Raider alatt is számít pár százalékot, illetve a Thief és a Sniper Elite 3 alatt is. Mindegyik utóbb említett játékban túl kicsi az átlapolt munka, de az előnyt jelent így is.
Az AotS-en az async compute-nak nincs akkora értéke ma. 5-10%-os pluszt jelent, de az aktuális motorverzióban még nincs aktiválva a texel árnyalás és a raszterizálás átlapolása. Csupán némi post-process fut az új képkockával párhuzamosan. Ennek a fejlesztésnek az az elsődleges problémája, hogy a működéshez szét kell választani a texel árnyalást a raszterizálástól. Ez DX11 alatt nem lehetséges, tehát abban a frissítésben, ahol ezt bevezetik legacy státuszba kell helyezni a DX11-es kódot, mert onnantól kezdve túl sok munka lenne az eltérő API-k karbantartása.Ez leginkább ma már külön fordítót jelent. A legtöbb stúdió, jelen esetben az ID nem ír ennyi shadert. Van egy saját nyelvük, amit több shader nyelvre fordítanak. Ezen belül is nyelvük kezel egy rakás olyan függvényt, amit a PC-s shader nyelvek nem. Ergo nekik kell írni egy alternatív fordítót a PC-hez, hogy ezeket a különbségeket kezeljék. Bármennyire is furcsa, ez nekik sokkal inkább teher, mint olyan shader kiegészítésekre fordítani a kódot, amelyek kezelik a shader intrinsics függvényeket.
-
Abu85
HÁZIGAZDA
Inkább az a kulcstényező, hogy vannak a leképezésnek nagyon tipikus problémái, amelyeknek ma már vannak megoldásai. A kérdés az, hogy a megoldásokat érdemes-e használni, vagy érdemes megtartani a problémákat mondván, hogy a játékosok már megszokták a shimmeringet. A Quantum Break úgy döntött, hogy a leképezőnél kezelik a shimmering jelenséget, így egy Full HD-s képkocka négy HD-s 4xMSAA-s képkocka temporális projekciója. Ennek az előnye a nuku shimmering, de hátránya, hogy mozis, elmosott hatást kelt, ami a máshoz szokott játékosoknak nem jön majd be. Ugyanakkor az nem technológiai gond, ez volt a dizájn szempontjából a célkitűzés. Sajnos jelenleg nincs olyan technológia, amely minden leképzésre vonatkozó vizuális problémát kezel, így vagy az egyik, vagy a másik halmazát fogja kezelni egy elgondolás.
A CPU-limit kitolása minden program oldalán a legfontosabb szempont. Főleg azért, mert ma már nem egymagos processzorok vannak, hanem négy vagy több. Muszáj olyan API-t kínálni, amivel ezek a magok kihasználhatók. És ehhez kellenek az új API-k, mert a régi API-kkal a parancsátadás egy szálra volt korlátozva, ami akkor is erősen limitáló volt, ha a parancskreálás esetleg több szálon történt meg. Mivel a jövőben semmi esély arra, hogy hirtelen jönnek a 15-20 GHz-es egymagos procik, így a többszálú parancskreálás biztosítása egy kulcstényező ahhoz, hogy az eddigieknél több rajzolási parancsot adhassanak ki a fejlesztők. Az, hogy csökkent a többletterhelés is, egy olyan fejlesztés, amit érdemes volt bevállalni, mert úgysem lehetett megőrizni a kompatibilitást a korábbi API-kkal. Ilyen formában érdemes nagyot fejleszteni, hogy legyen muníció évek múlva is.
Az aszinkorn compute jövője nem kérdéses. Mindegyik DX12 és Vulkan alkalmazás használja PC-n. Emellett ahogy nő a GPU-k bonyolultsága, annál több idle buborék keletkezne abból, hogy soros a pipeline-ok feldolgozása. Egy GPU mindig is heterogén rendszer volt, és az egységek számának növelésével a munkájuk összehangolásának hatékonysága csökken. Mondjuk egy GCN a 10 wavefront/CU SIMD-del el tud menni ~6000 shaderig, de ez az a határ, ami után már érdemes növelni a wavefrontok számát, és az nem lehetséges a jelenlegi memóriamodellel. Az NV már a Kepler óta warp limiten van, mert 64/MP-nél többet nem kezel a Fermi dizájn. ~4000 shaderig sem tudnak elmenni, mert hiába rakják bele a több shadert, az architektúra nem skálázódik tovább, ugyanis nem tudnak 128 warpot futtatni a jelenlegi memóriamodellel. Persze az Intelnél látjuk, hogy van olyan megoldás, mint mondjuk a gyorsítótárak hizlalása, de ez csak a probléma kezelése lenne mindkét oldalon, mintsem valós megoldás, mert eszi a tranzisztorokat. Ahogy megyünk számban az egyre nagyobb skálázódás felé, annál inkább kell az aszinkron compute, hogy a hardver egyáltalán skálázódjon. Nem viccből építették bele tehát az API-kba. Az persze igaz, hogy a gyártók az alaparchitektúrát tekintve más fejlődési fázisnál tartanak. Az AMD itt csak azért jó, mert az alapjuk 2012-es, míg az NV-é 2009-es, az Intelé pedig 2010-es. Ennek megfelelően az alapokat rendre 2008, 2005 és 2006 körül dolgozták ki. Az AMD-nek szerencséje volt, hogy belecsúsztak a 2007-es évbe, amikor rengeteg kutatás volt arról, hogy mi a jövő. Az NV és az Intel is láthatta ezt, de ekkor már késő volt, mert nem tudtak változtatni a fejlesztéseken. A Fermi módosítás például 2012-re tolta volna a megjelenést, ami ezen a piacon vállalhatatlan volt. Szóval amint lesz egy nagy váltás az NV-nél és az Intelnél, azonnal meglesz oldva a multiengine konstrukció hatékony támogatása.A Doom nyilván érdekes, de nem szabad elfelejteni, hogy amit mi szegmentálódásnak hívunk (AMD shader intrinsics és NVIDIA shader intrinsics), az a fejlesztők szemében egységesítés (GPUOpen a közös PC és a konzol kutatásokért). Ebben vitathatatlan szerepe van az explicit API-knak is, mert ahhoz, hogy a PC-re és a konzolokra közös legyen a fejlesztés minden szempontból közös lehetőségek kellenek, legyen az API, shader függvények, dokumentáció, stb.
-
Abu85
HÁZIGAZDA
válasz
cyberkind
#21012
üzenetére
Pedig igazából elég jól néz ki. Ennél jobb volumetrikus fényekkel nem igazán lehetett még találkozni. Eléggé szép a shimmering hatás elmosása is.
Nyilván a volumetrikus fények eléggé megterhelők, és ezekre nem véletlen dolgoztak ki olyan módszert a játékban, hogy a shadow mapokkal párhuzamosan lehessen őket számolni, mert nagyon sokáig tart a számolásuk. Sajnos az igaz, hogy ha befutsz egy olyan területre, ahol sok a volumetrikus fény, és nincs hozzá aszinkron compute-od, akkor nagyon durván lemegy az fps. [link] - erre itt fel is hívták a figyelmet. Az NV drivere nem engedi, hogy a számítás párhuzamosan történjen a shadow mapokkal. Szépen beküldik a parancsokat az OS parancslistájába. Ez nem a játék hibája, hiszen láthatod, hogy a 970-nel hasonló teljesítményű 390 70-80%-kal gyorsabb. A DX11 sem fog ezen javítani, mert ott eleve nincs párhuzamos feladatfeldolgozás. -
Abu85
HÁZIGAZDA
válasz
cyberkind
#21009
üzenetére
Jól működik a leképező. Átgondolt a szinkronizálás, szép az allokációs stratégia, kevés az idle buborék, átgondolt a multiengine implementáció. A legújabb patch mellett pedig már támogatva van a két új swapchain API is, így már nem gond a v-sync és a variálható frissítés.
Persze. Megnéztem a játékot, de csak a legújabb verziót. Azt elemeztem, mert gondolkozunk azon, hogy benne lesz a tesztekben.
-
Abu85
HÁZIGAZDA
Az látszik egyébként, hogy nagyon sok múlik a fejlesztőkön a DX12-ben. A legjobb minőséget az Ashes of the Singularity jelenti, de ott nulláról írták motort, illetve a bevonták a fejlesztésben az összes gyártót. Jó minőség még a Hitman, a Total War Warhammer, illetve a Quantum Break. A Forza és a Gears of War közepes, de utóbbi régi alapot használt, így sok volt a korlát, míg a Forza csapata PC-n szűz volt. A legrosszabb minőséget a Rise of the Tomb Raider képviseli. Sok helyen a DX11 kód is gyorsabb, a memoriaigénye indokolatlan. Nem véletlenül nem ajánlja az MS, hogy nagy legyen az allokációs szelet, illetve azt, hogy UAV és SRV legyen direkten a root signature-ben. Tipikus idióta hozzáállás azt feltételezni, hogy az API fejlesztője rosszul tudja, hogyan működik igazan hatékonyan a rendszer.
-
#21004
Abu85
HÁZIGAZDA
Petykemano
#20999
Abu85
HÁZIGAZDA
válasz
Petykemano
#20999
üzenetére
A hardverek nem oldanak meg mindent. Amire szükség lenne a GAB és az ARB számára az egy hardver oldali egységesítése előírása. Ez sokat segítene a fejlesztőknek abban, hogy milyen kódot írjanak az alkalmazásba. Erről egyébként szó van a háttérben. Ugyanakkor egy ilyen egységesítés lassú folyamat, mert egyes cégeknek az architektúra teljes leváltásával járna. Rövidebb távon ez gond, hosszabb távon persze megoldja magát a probléma, mert igazodni fog mindenki az API-k működéséhez. Ez már látszik is, mert a GCN mellett az új Bifrost Mali is nagyon jól illik a Vulkan ajánlásaihoz. De a Rogue is ilyen az Imaginationtől.
-
Abu85
HÁZIGAZDA
válasz
cyberkind
#20986
üzenetére
Már most olyan a DX12, amilyennek lennie kell. Hozza azokat a lehetőségeket, amiket a Microsoft ígért. Az i7 is jelenthet előnyt például az olyan játékokban, mint az AotS vagy a TW: Warhammer. Ezeknél van elég rajzolási parancs, hogy érződjön a skálázódás a több szálra. Egy QB alatt egyszerűen nincs, hiába skálázódik, akkor sem fog jelentős hatékonyságbeli előnyt hozni, mert relatíve kevés a rajzolási parancs. Pár százalékot jelent persze, de drámai különbség ma leginkább stratégiai játékokban van. Ezek azok a játékok, amelyek DX11 alatt már nagyon küszködtek. Ez borzalmasan látszik a Civilization BE alatt. Nem DX12, hanem Mantle, de ugyanaz a lényeg. DX11-gyel nem létezik olyan számítógép még ma sem, ahol a játék vége felé, amikor már felfedezted a térképet értelmes, értsd nem kávészünet jellegű lépésidőt lehet generálni, illetve ha kérsz egy teljes térkép zoom outot, akkor konkrétan 10-15 fps az eredmény. Mindegy milyen gépet raksz alá! Ugyanez Mantle-ben jelentősen jobb lépésidővel jön, majdnek négyszer-ötször jobbal, illetve a zoom out is simán megy 40-60 fps-sel. Szinte nem is esik a teljesítmény. Ugyanezt tudná a DX12 és a Vulkan, illetve majd tudni is fogja a Civ 6 alatt. Egy akciójátékban ilyet már azért nem fogsz tapasztalni, mert itt már léteznek az API-k, így eleve nem fognak DX11-et használni, ha használhatatlanságig csökkenne a teljesítmény. Ezek érthetően alakulnak így, mivel jellemző az iparra, hogy egy stratégiai játék jelenetkomplexitása mindig a legnagyobb, mivel kevés trükközésre van lehetőség. Ha nincs elég kraft, akkor nem csinálhatsz kisebb szobákat, szűkebb utcákat, stb. Nagyon kevés lehetőséged van arra, hogy bármilyen tervezésbeli trükkel sebességet nyerj. Ezért a legtöbb stratégiai játék az elmúlt évtizedből leginkább a kamerát limitálta, illetve rengeteg stúdió konkrétan tiplizett innen, mert annyira nehézzé vált az ilyen játékok fejlesztése, hogy inkább egyszerűbb stílusok után mentek. Ebből látszik, hogy a DX12 és a Vulkan nagyon jól működik, és nagyon jó hír, hogy a stúdiók jönnek vissza stratégiát csinálni.
A DX12 és a Vulkan átmenete egyébként sokkal inkább hardveres probléma, mint szoftveres. Mindkét API-nak igen kötött a működése, tehát van egy hatékony erőforrás és parancs kezelés, amihez jó lenne tartana magát mindenkinek. De vannak hardvergyártók, amelyek számára ez nem kifizetődő, mert még nem tudtak jó hardvert tervezni az igényekhez. Jelenleg a fenti, világos előnyöket leszámítva, azért érzitek töredezettnek az élményt, mert a fejlesztők számára nehéz ideális döntéseket hozni a hardvergyártók számára, ugyanis eléggé eltérnek a hardverek. Erről itt írtam egy bővebb hsz-t. [link] - tényleg csak ennyi a gond. És nem a parancslisták kezelése, mert az kiváltható azzal, hogy ha a driver nem tud dönteni, vagy nem akar, akkor elküldi az OS-nek a parancsot és az OS lekezeli automatikusan. A gondot a memória vezérlése és a bekötés kialakítása jelenti, mert baromira nem lehet úgy programozni, hogy Microsoft és a Khronos ajánl valamit, az AMD pontról-pontra ugyanazt ajánlja, aztán az NVIDIA ennek a gyökeres ellentétét, míg az Intel bekötésben követi a szabványalkotókat, de memóriakezelésben az ellentétét ajánlja. Ez így baromira szar a fejlesztőknek, mert ideálisan kell három kódút, hogy minden gyártót lefedjenek. Ráadásul azt is bele kell kalkulálni, hogy például az NVIDIA bekötésre és erőforrások menedzselésére tett ajánlata számos korlátot idéz elő magában az API-ban, mert nem lehet akármilyen formátumot betölteni az RS-be DX12-ben. Eleven nem arra találták ki az RS-t, hogy direkten tároljon SRV/UAV/CBV-ket.
Jelenleg a leginkább alkalmazott modell az, hogy a fejlesztők a Microsoft és a Khronos ajánlásait követik a bekötésre és az erőforrásokra, de megpróbálnak az ideálisnál nagyobb allokációs szeletekkel dolgozni a memóriára. Emiatt van az is, hogy a DX12-ben nő a memóriaigény a DX11-hez képest, de ha nem így dolgoznának, akkor az nem lenne jó az NV-n és az Intelen. A különbség jól látszik, mert például az új Tomb Raider PC-n 512 MB-os allokációs szeletekkel dolgozik, míg konzolon 64 MB-ossal. Egyébként az 512 MB elég sok. Inkább 128 MB vagy 256 MB az átfogó PC-re, az ideális pedig 64 MB. Szóval ma a hardverek oldalán az egész rendszer pokolian töredezett, és ez nehézzé teszi a fejlesztéseket. De a DX12 és a Vulkan még így is megéri, bár nem egy program inkább úgy készül, hogy kiválasztanak egy célarchitektúrát és arra írják meg a kódot. Ha nem azzal az architektúrával rendelkezel, amit kiválasztottak, akkor hátrányban leszel. -
Abu85
HÁZIGAZDA
válasz
cyberkind
#20980
üzenetére
Már a DX12 port sem bughalmaz, mert ki van javítva a kezdetek óta. Minden benne maradt probléma nem az alkalmazás oldalán keletkezik.
Azért nem láttad a DX12 előnyét, mert az két oldalról jelent extrát. Egyrészt jelentősen csökkenti a processzor terhelését, de ez 4,7 GHz-re tuningolt i7-tel CPU-val mindegy, főleg egy olyan játékban, mint a QB. Ellenben mondjuk nekem nem, mert én megérzem a játékokban az A10-7850K-t. Viszont DX12-vel jelentősen javul mindenhol a teljesítmény. A másik az aszinkron compute, ami neked 980 Ti-vel megint mindegy, mert az NVIDIA egyetlen játékban sem engedélyezi ezt a képességeit a te kártyádra. A Pascal-ban is csak az új Tomb Raiderre. Ellenben mondjuk nekem sokat ér, mert 10-20%-os boost jön tőle R9 285-tel. Ezek mellett én még azért érzek általános előnyt, mert a legtöbb játékot a Microsoft ajánlásai szerint fejlesztenek, és ezekkel az ajánlásokkal az AMD ajánlásai megegyeznek, míg mondjuk az NV ajánlásai eltérnek, sokszor jelentősen. Utóbbit a fejlesztők nem igazán fedik le. A Doom és a Hitman tartalmaz NV-specifikus alternatív kódot is. A Microsoft játékai például abszolút nem, mert a Microsoft arra szeretné sarkallni a hardvergyártókat, hogy ha valami nem működik nekik a DX12-ben, akkor ne alternatív erőforrás-használatra buzdítsanak, hanem javítsák meg a hardvert az új generációban. -
Abu85
HÁZIGAZDA
válasz
cyberkind
#20973
üzenetére
A Steam is ugyanazon a szinten marad, mint a Windows Store-os, azzal a különbséggel, hogy nem UWP, hanem Win32 API-t használ, illetve kap egy DX11 backportot. A DX12 kód azonban ugyanaz, és az már nem változik. Elég sokat javítottak rajta, legalábbis azokat a dolgokat, amelyek a fejlesztőkön múlik. Ami pedig nem rajtuk múlik, azon nem tudnak javítani.
-
#20955
Abu85
HÁZIGAZDA
bertapet11
#20954
Abu85
HÁZIGAZDA
válasz
bertapet11
#20954
üzenetére
Az API-nak nem sok köze van rendszermemóriára vonatkozó követelményekhez. Az erre vonatkozó igény leginkább az aktuális konzolok miatt növekszik.
-
Abu85
HÁZIGAZDA
válasz
imi123
#20864
üzenetére
Inkább az volt a baj, hogy alig volt akkor optimalizálva. Nyilván promóanyag kell, tehát felvették az aktuális állapotot. Túl sok jelentősége nincs.
Sokkal jobb lesz, mint az új Tomb Raider port, aminél azért nem nehéz jobbat csinálni. De jobb lesz a Hitman portjánál is. Eleve az a csapat csinálja, akik a Hitman portját segítették. Egyébként a Tomb Raider csapata most PS4-re portol, egy darabig ők nem csinálnak mást.
-
Abu85
HÁZIGAZDA
válasz
velizare
#20861
üzenetére
Táblázat itt: [link]
(#20862) vitko: Ezek a gyártói csomagok nem feltétlenül szükségesek a működéshez. Extrákat biztosítanak. Mindegyik olyan játék, amely elkészült és megjelent, de extrákat igényelt, támogatja az AMD és az NVIDIA runtime-ját is. Például EVE: Valkyrie, Chronos, The Climb. Persze más-más dolgokat használnak a gyártói csomagokból. Például az NV-éből az MRS-t, hogy a képkocka szélét ne kelljen teljes felbontáson számolni. Az AMD-s párját ennek nem használják, viszont használnak LDL-t.
A professzionális hardver a tartalomkészítőket érdekli. Az egy másik ága volt a vitának. Tartalomfogyasztóknak ez nem kell.
-
#20860
Abu85
HÁZIGAZDA
#Morcosmedve
#20857
Abu85
HÁZIGAZDA
válasz
#Morcosmedve
#20857
üzenetére
Egyelőre nem sokat. Nincs VR-re tervezett professzionális hardver, zárt az VR SDK, és nincs VR-re tervezett API az aktuális szabványok hiányainak foltozására. Nyilván ez lehet az oka annak a logisztikai kérdésnek is, hogy nincs egy fő "támaszpont" sem a filmgyártás központja mellett.
Van viszont egy Titan X, de ez nem olyan gyors VR-re, mint a Radeon Pro Duo, és nincs professzionális támogatás hozzá. Persze sosem mondta az NV, hogy ennek a VR a célpiaca, mindig is a gépi tanulást hangsúlyozták ki. -
#20856
Abu85
HÁZIGAZDA
#Morcosmedve
#20855
Abu85
HÁZIGAZDA
válasz
#Morcosmedve
#20855
üzenetére
Nem tudnak. A VR nagyrészt egy szoftveres probléma. Két dolog hátráltatja ma a tartalomkreálást. Egyrészt a technikai támogatás távolsága, de ez logisztikai kérdés, csak oda kell települni a cégek mellé. A másik egy sokkal nagyobb gond, ami a VR-re tervezett API hiánya. Se a Vulkan, se a D3D12 nem ilyen API. Az input assembler lépcsője még mindig olyan kötöttséget igényel, hogy a kamerapozíció a jelenetszámításból lesz átemelve, és az nem változhat. A VR ezzel szemben azt igényli, hogy ez változzon meg. Itt jön képbe az, hogy az AMD-nek van egy saját Mantle API-ja, amivel API interoperabilitással megváltoztatják a kamerapozíciót, és onnantól kezdve már nincs baj a szabvány API-kkal sem. Ezt rajtuk kívül senki más nem tudja megtenni. Az előnye ennek, hogy nagymértékben növelni tudják a produktivitást, mivel jelentősen csökkentik a tartalomkreálásra használt szoftverek amúgy igen magas késleltetését.
Szintén fontos tényező még, hogy a LiquidVR SDK nyílt forráskódú. Tehát ha van valami egyedi igény, akkor megcsinálják egy hónap alatt és nem kell hónapokig tárgyalni az igény beépítéséről, amiből talán egy év múlva lesz valami.
A cégek csak a produktivitást választják, mert jóval hamarabb kész lesz a projekt. Hónapokat lehet nyerni vele, ami a kiadásoknál igen jelentős tétel. -
Abu85
HÁZIGAZDA
válasz
Locutus
#20852
üzenetére
Az NV-t is érdekli ez a terület, csak nem tudnak mindent lefedni. Az a problémájuk, hogy amíg az AMD le tudja cserélni a szabványos API-k input assembler lépcsőjét, addig ők nem képesek rá, mert nincs egy saját API-juk, amivel azt helyettesíteni tudnák. Emiatt nem koncentrálnak a szükségesnél jobban ide, mert bizonyos eljárásokat nem tudnak megvalósítani a nem VR-re tervezett szabványos API-k kötöttségei miatt.
(#20853) hpeter10: A GRID-nek semmi köze a VR-hez.
Az AMD bevétele pár száz Radeon Pro Duo eladásától nem ugrik meg. Ez csak egy másik piac előkészítésére jó. Amikor a VR mozik kialakulnak, akkor tudnak nagyobb hardvereladást generáli. -
#20850
Abu85
HÁZIGAZDA
huskydog17
#20843
Abu85
HÁZIGAZDA
válasz
huskydog17
#20843
üzenetére
A VRLA-n volt az egyik beszélgetésen. Abban, ahol arról beszéltek, hogy mennyire jól tette az AMD, hogy rakott egy központot Hollywood mellé, mert minden stúdiónak az volt a baja, hogy a legközelebbi technikai támogatás egy napnyi útra volt legalább. Emiatt minden egyes gond után egy napnyi kényszerszünet következett. Tekintve azt, hogy a VR új terület, kb. heti két gond merül fel, ami minden projekt előzetes elkészültének idejét 40-50%-kal növeli meg, hacsak nincs a segítség egy órányira. Az nem számít, hogy piszok sok cég van, az számít, hogy a gondokra egy órán belül van személyes technikai segítség. Ez számít a stúdióknak is.
Nyilván ugyanezt meg tudja tenni az NV is, és kihozhatnak egy VR-re szánt professzionális VGA-t is. De még egyiket sem tették meg, tehát a stúdióknak ma nincs választása.
-
#20841
Abu85
HÁZIGAZDA
huskydog17
#20839
Abu85
HÁZIGAZDA
válasz
huskydog17
#20839
üzenetére
Most volt a VRLA. Ott volt róla szó, hogy Hollywood teljes egészében LiquidVR-t használ a tartalomkészítésre. Nyilván Pro Duóval, mert más VR-re fejlesztett kártya nem létezik. Nekik ugye fontos, hogy speciális meghajtókat kapjanak, illetve az is lényeges, hogy az AMD létrehozott melléjük egy irodát LA-ban, amivel nem csak telefonos supportot biztosítanak azonnal, hanem személyeset is. Bármi gond van, egy órán belül ott van egy technikai csapat.
R&D-re egyébként használnak mást is, az egy olyan terület, ahol a kutatásokat nagyrészt egy gyártó segíti, és egy darabig az adott gyártóhoz lesz kötve az egész.A VRLA-nak volt egy üzleti része, ahol számos orvosi cég jelent meg, illetve a Boeing, akik beszéltek arról, hogy nekik az erő hiányzott a VR szimulációhoz, de már nem hiányzik.
-
Abu85
HÁZIGAZDA
Nem nyers fps. MRS! Ezzel lehet gyorsítani a feldolgozást 50%-kal, mert nem kell minden területet teljes felbontáson számolni. A VR SLI+MRS egy branch része, ráadásul kikapcsolhatatlanok az UE4 alapverziójában. Az AMD itt ott veszít, hogy a teljes képet teljes felbontáson számolja, és nem tudja az oldalát felezetten vagy negyedelve számolni. Ahhoz, hogy tudja be kell építeni a LiquidVR-nek ezt a módját.
Timewarp mindenképpen van SteamVR+UE4 alatt, mert 90 Hz-en is túl sok a fejmozgás és a bemenet között eltelt idő. Aszinkron timewarp nincs. Az Oculus runtime nem teszi kötelezővé a timewarpot. -
Abu85
HÁZIGAZDA
Ehhez hozzátenném, hogy egy Early Access játékról van szó. Érdemes lenne az eltéréseket végleges játéknál megnézni. Ha ragaszkodunk az UE4-hez, akkor az Eve: Valkyrie alatt.
Nyilván a fragmentált piac nem jó, de még egyszer hangsúlyozom, hogy Early Access a tesztjáték. Nem várhatod el, hogy minden be legyen építve alpha készültségi szinten. Végleges játékokban azért olyanok nem igazán lesznek, hogy x vagy y sokkal jobb. Főleg az Oculus áruházában.A PH-n elég sokat írtunk az egészről, hogy az AMD rendszerének mi az előnye. És ezt nem én mondtam, hanem David Kanter az Oculusra hivatkozva. [link] - ettől függetlenül nyilván ez nem alpha programokra vonatkozik. Az egészet én csak megmagyaráztam. [link]
-
Abu85
HÁZIGAZDA
válasz
Dyingsoul
#20826
üzenetére
Vannak motorok, amelyek lefedik az összes funkciót. Ilyen a Serious Engine, az Asura, a Nitrous. A probléma ezekkel az, hogy rohadt drágák. Szintén vannak olyan példák is, ahol a fejlesztő alaposan átgyúrta a licencelt motort. Például a CCP Games az UE4-et. A VR-re vonatkozó részét 100%-ban átírták a már megjelent Eve: Valkyrie-hez.
Az Early Access miatt gondolom az UE4 main branch-et egészítette ki a tesztjáték fejlesztője. Ezt onnan lehet tudni, hogy van VR SLI. Na most ez a VR SLI-s branch MRS és VR SLI-t használ, tehát a GeForce-ok számára lehetővé válik, hogy a képnek csak a közepét számolják teljes felbontással, a szélét pedig felezve vagy negyedelve. Ez jelentősen gyorsít a sebességen. Ugyanilyen lehetőség van a LiquidVR-ben is. Persze nem muszáj ezt használni, de a bekötött branchekből nem szedhető ki. Viszont az UE4-ből alapvetően igen, mert az Eve: Valkyrie sem használ MSR technikákat, hanem teljes felbontáson számolja az egész képet.
-
Abu85
HÁZIGAZDA
Mellé tettem a véleményem.
Minden piac így indul be, kell a killer app.
Nagyon sok függ a programtól a rosszullét tekintetében. A gyártók csak a lehetőséget tudják felkínálni ezek enyhítésére, de a programba kell őket beépíteni. A PC-n a töredezettség a minőségellenőrzést nagyon bonyoluttá tesz, így rövidebb távon valószínűleg eléggé korlátozott lesz az a PC-s felhasználóbázis, akiket a VR meg tud szolítani. Közöttük is többségben lesznek a VR hátizsákot vásárlók.
Valószínűleg a legnagyobb piacot a mobil és az AIO VR szerzi meg, illetve a PlayStation VR.(#20819) miklosss2012: Vannak bizonyos géptípusaikban beágyazott AMD cuccok. Az Airbusban A380-ban is. De ezek nem a repülésért felelnek, hanem a fedélzet szórakoztatásáért.
-
#20817
Abu85
HÁZIGAZDA
bertapet11
#20814
Abu85
HÁZIGAZDA
válasz
bertapet11
#20814
üzenetére
Már minden nagyobb stúdió tér át Pro Duóra. Épp az idei VRLA-n volt szó róla, hogy a filmstúdiók számára a legnagyobb gond, hogy az SDK-k kötött API-khoz kapcsolódnak, és ezeknél az API-knál az input assembler lépcső módosíthatatlan. Tehát a stúdióknak egy saját API-t kellene fejleszteni a rendszerükhöz, ami viszont jelentős probléma lenne a tartalom terjesztésénél. A Radeon Pro Duo előnye itt az, hogy a LiquidVR kicseréli a szabványos input assemblert a Mantle input assemblerjére, és az így kapott tartalom kompatibilis lesz a szabványokkal is. Amíg ezt a problémát csak a Mantle tudja kezelni, addig nem nagyon tudnak másfele menni a filmstúdiók. Ugyanakkor persze kísérletezhetnek egy rakás dologgal emellett. Ellenben jó hír, hogy a Microsoft és a Khronos is dolgozik a szabványos megoldásokon, de ezek 2018 körül jönnek, és addig nem áll le a piac.
-
Abu85
HÁZIGAZDA
Valószínűleg egyik sem. A VR-rel igazából nincs probléma, ahogy a hardverekkel sem. A gond a nagyfokú töredezettség. De ez a gond igazából csak az Early Access címeknél gond, mert mire egy program végleges lesz, addigra mindenre szokott lenni támogatás. Relatíve kevés szopással jár az Rift, mert ott az Oculus a saját áruházát nagyon erősen ellenőrzi, így nem engedik meg, hogy az általuk megszabott minimum követelmények alatt felkerüljön egy program. A Steam ebből a szempontból sokkal megengedőbb, de nekik muszáj is, mert az Early Access címeknél nem várhatják el, hogy működjön. Egyszerűen ha működő Early Accesst tudna egy fejlesztő felrakni, akkor nem lenne szükség az Early Access-re.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#20810
üzenetére
Az életképes megoldás az attól függ, hogy a szoftver mit használ belőle. A VR-ben a hardver erejét nagyrészt a szoftver szolgáltatja. Nyilván abszolút nem véletlen, hogy Hollywood 100%-ban AMD-re épít, ahogy az sem, hogy Boeing is Radeon Pro Duókat használ VR szimulációkhoz, mert sokkal hatékonyabban használható VR-re az a hardver. De a VR a tartalomfogyasztásra jelenleg rendkívül töredezett. Van két különálló runtime (SteamVR és Oculus), amelyek között ráadásul eleve hatalmas a szakadék. Aztán van két gyártói runtime (VRWorks és LiquidVR), amelyek a headsetek runtime-jainak egyes részeit képesek hatékonyabbra cserélni, illetve lehetőséget adnak a két GPU-s módra. És van egy VR API (Mantle), ami lehetőséget ad az LDL-re.
Egy játékfejlesztő számára az általános szabvány hiányában ezekre kell támogatást építeni, külön-külön. Tekintve, hogy ez nem egy kritikus piac, így a legtöbb Early Access játék nem különösebben épít a gyártói runtime-okra, és használják azt, amit az adott motor kínál. És ez jelenleg elég kevés, mert a legtöbb általánosan licencelhető motor mobilra fókuszál.Az UE4-nek van egy nagyon alapvető timewarp támogatása, illetve kihasználható a VR SLI.
A Unity-nek van már PC-re async timewarp támogatása, de csak Oculusra, és nem használható még a mutli-GPU.
A CryEngine általánosan támogat minden headset runtime funkciót, viszont gyártói szinten csak a LiquidVR van implementálva, a multi-GPU-t csak AMD-re támogatják.
A sebesség ma attól függ, hogy a játék melyik motort használja, mert az implementálásban eltérő fázisában vannak. -
Abu85
HÁZIGAZDA
válasz
Dyingsoul
#20808
üzenetére
Az Oculus SDK-ban, illetve a gyártói SDK-kban. A HTC Vive ezeket nem képes kihasználni, mert legalább másfél évvel van szoftveresen az Oculus mögött. A SteamVR ebből a szempontból a gyártói SDK-kra támaszkodik, de a tesztelt játékban csak VRWorks aktív, míg a LiquidVR nem. Az Unreal Engine 4 a VR implementációjában a PC-t figyelembe véve amúgy is eléggé le van maradva, mivel a mobilra gyúrnak, így az async timewarp leginkább androidon működik csak. PC-n az adott runtime dönti el, hogy aktiválja-e vagy sem, de jellemzően nem teszi meg, mert a legtöbb esetben csak problémákat okoz a legtöbb hardveren. Az is fontos, hogy az UE4-nek egyedül a mobil leképzőjét írták tiled rendszerűre, tehát ott tud általánosan működni az async timewarp. A PC-s leképezőre egy-két ember van ráállítva, mert a licencelőket nem igazán érdekli a PC.
Ma teljesen játékfüggő az, hogy melyik hardver a jobb, mert egyes motorok csak a VRWorks-öt, míg mások csak a LiquidVR-t támogatják. Amelyiket támogatja az adott játék az a hardver nyer.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#20770
üzenetére
Volt még a Tonga is, illetve a Carrizo variánsok, valamint az Iceland.
A támogatás és ptimalizálás az explicit API-kban nem olyan, amilyenre gondoltok. Annak ellenére, hogy a hozzáférés a hardverhez sokkal közvetlenebb, még mindig nem annyira alacsony szintű, hogy számításba kelljen venni a GPU-kat. A Mantle részben ilyen volt, de annál egy picit magasabb szintre helyezték a működést a DX12 és a Vulkan API-ban. Tehát effektíve nem annyira lényeges, hogy van GCN1/2/3/4 is, mert azokat DX12/Vulkan alatt el lehet fedni. Az egyetlen kivétel a multi-engine kezelése, amely bizonyos körülmények között finom paraméterezést igényel, de ott sem a GCN1/2/3/4 számít hanem az, hogy mire képesek az ACE-ek, HWS-ek, a GMU-k, vagyis a független parancsmotorok. Nyilván számít, hogy a hardver mennyi független parancslistát kezel, mivel a compute motorokat a driverből kell etetni, míg a grafikai parancslistáról az OS gondoskodik. A driver előtt persze még viszonylag sok lehetőség van arra, hogy egy compute parancsot hova pakol be, de a meghajtók ha tehetik új parancslistába töltik be, és ott már elég nagy különbségek lehetnek. De ugyanakkor az AMD ezért ragaszkodik a GCN2 óta a 64 parancslistához és a 8 különálló parancsmotorhoz, hogy a fejlesztők ezt célozva igen nagy hardverbázist képesek lefedni. A GCN1 ebből persze kevésbé jól profitál a 2 parancslistájával, de működni működik. Rosszabb esetben a driver dönthet úgy, hogy a compute parancsot beküldi az OS grafikai parancslistájába. A GeForce-ok például így csinálják szinte minden DX12-es játékban (kivéve a Pascalt az új Tomb Raiderben).
Aztán ezt a történetet még bonyolítják azok a lehetőségek, mint a priority flag, ami definiálva van a DX12-n belül. Egy fejlesztő egy compute parancsot jelölhet magas prioritásúnak, és akkor azt a drivernek úgy kell beraknia a független parancslistákba, hogy azonnali végrehajtás történjen. Ugyanakkor itt vannak specifikációs lékek, ugyanis a priority flag mehet közvetlenül az OS grafikai parancslistájába is, vagyis nem kötelező a driverben implementálni ezt a képességet. Az AMD-n kívül nem is implementálta más. Bizonyos programokban ezért van letiltva minden más hardverre az aszinkron compute. Nem állítja be a driver a magas prioritást, ezért berakja az azonnali eredményre kijelölt munkát a sorba, a munka eredményét igénylő számítás pedig csak áll, amíg a parancs lefuttatásra nem kerül. Valószínűleg ezt a kerülőutat a Microsoft szándékosan hagyta benne a specifikációban, hogy kifejezetten rossz "egyszálú" teljesítménnyel rendelkező hardvereknél a gyártóknak ne kelljen erre a gyengeségre kötelezően implementációt készíteni. Szóval a drivernek van jelentősége csak nem annyi, mint régen.Aminek sok jelentősége van az a memória vezérlése és a bekötés kialakítása. Na ez már nagyon trükkös. Főleg úgy, hogy a Microsoftnak és a Khronos Groupnak létezik egy ajánlott konstrukciója rá, de a gyártók nem mindenhol értenek azzal egyet. Egyedül az AMD ajánlja pontról-pontra ugyanazt, amit a Microsoft és a Khronos Group. Az Intel a bekötés és erőforrások menedzselésénél egyetért az API-kat szállító konzorciumokkal, de a memória vezérlésénél már nem. Az allokáció tekintetében a VRAM felbontását az MS és a Khronos Group is kicsi szeletekre javasolja, lehetőség szerint a legkisebbekre, ami még hatékony az adott motorral. Ugyanezt írja elő az AMD is. Az Intel pont a nagyobb szeleteket kedveli, ahogy az NVIDIA is. Az NV-nek ez a terület a Vulkan API-val olyannyira problémás, hogy külön hoztak rá egy kiterjesztést, amivel dedikált allokációk alakíthatók ki. Ráadásul a bekötés és erőforrások menedzselésénél sem azt javasolja az NV, amit a Microsoftnak és a Khronos Group, hanem a gyökeres ellentétét. A GeForce-okkal ez működik hatékonyan. Egyébként az NV ajánlott modelljeinek is megvannak a maga hátrányai, lásd az új Tomb Raider DX12-es módját. Nem véletlen, hogy a Microsoftnak és a Khronos Group nem ezeket ajánlja a fejlesztőknek, mert általánosan nem hatékonyak. Máshogy kell kezelni az eltéréseket, és ezek a gyártók közötti ajánlásbeli eltérések sokkal nagyobb problémát fognak okozni, mint a gyártón belüli apróbb különbségek.
-
#20732
Abu85
HÁZIGAZDA
#Morcosmedve
#20722
Abu85
HÁZIGAZDA
válasz
#Morcosmedve
#20722
üzenetére
Ez bonyolultabb. Nézd úgy, hogy a GDS egy nagyon gyorsan elérhető memória a lapkán belül, gyorsabb bármelyik gyorsítótárnál és a Global Ordered Append csoportból a GlobalOrderedCountIncrement függvénnyel megoldható a wave-ek sorrendben történő futtatása. Ehhez azonban az kell, hogy a multiprocesszorok ne futtassanak egy wave-nél többet egy feldolgozótömbön. Az AMD azért implementálja a hardverben így, mert a sorrend egy belső memória alapján lesz kialakítva, ugyanis mindig lesz egy look-up, hogy melyik wave jön. Ha minden look-up kimegy a memóriába, akkor az akármilyen memória mellett eléggé megöli a sebességet. Emellett járulékos veszteség az is, hogy a mai SIMT architektúrák úgy fedik el a memória késleltetését, hogy több wave-et futtatnak, de most a sorrendbe rendezés miatt csak egyet futtathat minden feldolgozótömb, vagyis itt is buknak egy csomót. Erre vezette be egyébként a GCN4 az utasítás-előbetöltést, hogy a szükséges adat már akkor ott legyen valamelyik a multiprocesszor gyorsítótárában, amikor a kérés megtörténik. Emiatt nem kell a memóriáig menni, amivel visszanyernek egy csomót az elméletben elbukott késleltetésből.
A fogyasztás a mérnökök számára nem egy célparaméter. Amit nekik észben kell tartani az a hatékonyság. Ilyen formában nyilván egy GDS+utasítás-előbetöltés a leghatékonyabb, mert gyakorlatilag GlobalOrderedCountIncrement függvény mellett is a lehető legkisebb lesz a késleltetés. Például van egy programod, ami fut 200 fps-sel, de szeretnéd a wave-eket sorrendben futtatni, akkor a GlobalOrderedCountIncrement függvény ezt GCN1/2/3-on megteszi úgy 150 fps mellett, GCN4-en megteszi 190 fps-sel, míg ha a memóriához kell kimenni, akkor ugyanez 30 fps-re csökkenti a teljesítményt. Így már egészen átalakul a hatékonysági sorrend. Ilyen formában egyébként az adott effektet már érdemes a GlobalOrderedCountIncrement függvény nem hatékonyan kezelő hardvereken tiltani, de nyilván a szabványba érdemes belerakni, mert a Microsoft is tudja, hogy a többi cég is fejlődik, tehát egy-két generáció és támogatni fogják. Valószínű egyébként, hogy több shader modell 6.0-s wave ops intrinsics függvényt maga a Microsoft akar, mert megy a vita arról, hogy a mostani specifikáció mennyire jó-e az Intelnek és az NV-nek. A wave scan és prefix kb. semennyire. Az AMD-nek ezekre direkt utasítása van, míg a többieknek semmi. A WaveBallot sem valami előnyös 64 bites maszkolással. A GCN-re ez illik, míg a többire nem. De áthidalható gondokról van szó. Az igazi probléma a Global Ordered Append csoport lesz.
-
Abu85
HÁZIGAZDA
válasz
lezso6
#20720
üzenetére
A patch az nem segít rajta. Le kell butítani, hogy ha csökkenteni akarják a fogyasztást. Ki kell venni belőle a GDS-t, a QoS-t, egy rakás konzolon használt utasítást, stb. Ezekkel csökkenthető a fogyasztás. Csak ugye most ez nem célszerű, mert a QoS működtetni az MxGPU-t. A GDS kell az SM6.0-ban a Global Ordered Append függvénycsoporthoz, anélkül ez csak ~ezerszer lassabban működhet, mert a VRAM-ba kell dolgozni. A szintén SM6.0-s Wave Scan/Prefix szintén egy utasítás GCN-en, míg más hardveren sokkal több ciklus lefuttatni. Persze ezeket ki lehet venni, csak sokkal lassabb lesz az SM6.0 implementáció, pont akkor, amikor kelleni fog.
-
#20719
Abu85
HÁZIGAZDA
#Morcosmedve
#20717
Abu85
HÁZIGAZDA
válasz
#Morcosmedve
#20717
üzenetére
Az igazsághoz hozzátartozik, hogy a GCN4 ISA lényegében megegyezik a GCN3 ISA-val. Inkább a körítés változott (PDA, új ROP, új gyorsítótárak, instruction prefetch, stb.). A CodeXL-ben is GFXIP 8.1-ként van jelezve, miközben a GCN3 GFXIP 8. A Vega már GFXIP 9-es. Itt már a GCN4 alap köré építik az új ISA-t. Szóval ez most ilyen kétmenetes átállás lett. A Polaris az eddigi ISA mellett felújított mindent, míg a Vega megújítja a maradékot. Szerintem amiatt nincs nagyobb Polaris lapka sem, mert az ISA memóriamodellje a GFXIP8-ban a Fiji kialakításáig skálázható. Új memóriamodell kell, hogy mondjuk 4096 shadernél többet belerakjanak.
-
#20619
Abu85
HÁZIGAZDA
Petykemano
#20617
Abu85
HÁZIGAZDA
válasz
Petykemano
#20617
üzenetére
A Sony nem váltott. Nagyon nehéz kiigazodni a szerződésen látatlanba, de úgy néz ki, hogy az AMD csupán lapkaverziókra köt OEM szerződést. Ez azt jelenti, hogy minden új lapka külön semi-custom megrendelésnek minősül, külön szerződéssel. Emiatt az MS és a Sony számára mindig az első verzió marad a legolcsóbb, mert annak az árát nem tárgyalhatja újra az AMD.
Másikra: [link]
-
#20600
Abu85
HÁZIGAZDA
Petykemano
#20599
Abu85
HÁZIGAZDA
válasz
Petykemano
#20599
üzenetére
Gondolom az MS a legolcsóbb átállást választotta, vagyis nem kérte az AMD-től, hogy tervezzék újra az egész lapkát. Valószínűleg benne van a szerződésben, hogy az AMD milyen átállásnál milyen árakat szabhat meg, és úgy kérte az MS a váltást, hogy ne növekedjen túl nagyon a lapkák ára.
Tekintve, hogy az így készült 16 nm-es lapka kb. 50 mm2-rel nagyobb, mint lehetne normális tervezés esetén, valószínű, hogy az AMD csak egy 28 nm-ről portolt dizájnkönyvtárat használt. Ezt más bérgyártóhoz nehezebb lett volna portolni. -
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
Hozzátenném még, hogy vannak olyan vélemények is, hogy szoftveresen kell a problémát kezelni. Lásd az Intel, ahol igazából úgy tekintenek a problémára, hogy jobb kivágás kell, illetve jobb memóriavezérlés a szoftverben. A mobil piacon hasonló szemléletű az Imagination, ahol szintén úgy gondolják, hogy a TBDR nagyon jó és a gyengeségeit szoftverből kell kezelni.
Az alapproblémát az adja, hogy nincs univerzálisan jó konstrukció. De még csak nincs is egyetértés abban, hogy az egyes negatívumokat miképp lehet kezelni. Például a TBR felé azért indul el a legtöbb cég, mert nem tudják értékelhető formában kezelni a raszterizációt a sok nem látható háromszögnél. Ezeket pedig úgy lehet kivágni, ha felállítanak egy sorrendet és akkor már tudják, hogy melyik látszik. De ugye pont az AMD mutatott erre a Polarisban egy másik konstrukciót, ami IMR mellett még a raszterizálás előtt kivág egy rakás nem látható háromszöget. Tehát vannak problémák és számtalan, teljesen más előnyöket és hátrányokat biztosító félmegoldás ezekre.
-
Abu85
HÁZIGAZDA
válasz
Laja333
#20531
üzenetére
A legtöbb mai asztali GPU eleve nem tipikus IMR, hanem egy TBR-IMR keverék. Persze más mértékben. Az korábban is ismert volt, hogy az NV nagyobb teret ad a TBR-nek, és kisebbet az IMR-nek, mint mondjuk az AMD. Az Intel pedig nagyon a klasszikus IMR-hez közelít, de ott is van tiling optimalizálás.
A legutolsó klasszikus IMR dizájn az AMD-nél a Terascale, az Intelnél a Gen6, míg az NV-nél a Fermi volt.
Az oka ezeknek az átmeneteknek az, hogy a klasszikus TBR és IMR ma már nem kifizetődő, mert a klasszikus IMR eszi a sávszélt, míg a klasszikus TBR borzalmasan gyenge a háromszögek számának növekedése mellett. Ellenben persze a hibrid konstrukciók között nagy különbség is lehet, hiszen szabad utat ad a mérnököknek.
Ugyanígy az ultramobil piacon is egyre kevésbé divat a klasszikus TBR, és elkezdtek menni az IMR felé, mert elkezdtek számítani a háromszögek.Az előnyök és a hátrányok egyébként megmaradnak. Minél inkább a TBR felé megy egy dizájn, az annál inkább hátrányos lehet a rendkívül sok háromszög raszterizálásánál, lásd Hitman. De eközben minél inkább IMR felé megy egy dizáj, az annál inkább eszi a sávszélt. Lásd Fiji.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#20540
üzenetére
Ha a memóriaórajelre gondolsz, akkor az nem bug, hanem pár visszajelzés kezelése. A memóriatuning problémás, aminek az az oka, hogy a memória a VGA-n akkor is stabil marad, ha amúgy már nem az. Gondolj a memtestre. Nem addig tuningolod a rendszermemóriád, amíg az OS már be sem tölt, hanem addig, amíg a memtest nem jelez hibát. Na most egy VGA-n a cellahibák nem jelentenek semmit. Akár 100 cellahibával is tök jól elvan a hardver, de a játékokban, 8 GB-os VGA-knál jellemzően 4-6 órás játék után előjönnek a grafikai hibák. Amennyiben erre vonatkozóan a tuning miatt nőttek meg a bejelentések a support felé, akkor lépni kell, hogy ezek a grafikai hibák eltűnjenek. Az elsődleges lépés, hogy limitálod az órajelet, és redukálódik a cellahibák száma.
A felhasználók 99,99%-a képtelen felfogni, hogy az egyes részegységek tuningjánál hol a határ. Nincs megfelelő eszköz arra, hogy a VRAM-ot ilyen formában kimérd, és nagyon sok tuningoló nem fog 4-6 órákat játszani egy olyan specifikus játékkal, ami végre betalál egy tuning miatt hibássá vált cellát.Ez egyébként egy oktatási probléma. Egy gyártó számára sokkal nehezebb a felhasználóiknak elmagyarázni a hardverek működését. Sokkal realistább elfogadni, hogy a user hülye és nem tudja, hogy hol a memóriatuning határa. Következésképpen korlátozni kell a tuninglehetőségeit, mert el fogja árasztani a supportot fals hibabejelentésekkel, ugyanis jellemző, hogy a user a tuningot sosem vallja be. Úgy érzi ez nem fontos adat.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#20538
üzenetére
Elsősorban azért előny, mert minden változásra azonnal lehet reagálni a tuningmodullal. Egy 3rd party alkalmazás erre nem képes, így ha változás van a meghajtóban, akkor minimum egy hetes átfutási idő van, mire arra egy programfrissítés érkezik.
A másik előny, hogy a tuningmodult azt tervezi, aki a hardvert tervezte, vagyis olyan funkciókat tud előhozni, emire egy 3rd party alkalmazás fejlesztője képtelen lenne. Ilyen például a Wattman ventilátorszabályozása, ami akusztikai limitre is paraméterezhető. Ilyen például elméletben megoldható lenne Pascalon is, csak túl kevés az információ a hardverről, hogy bárki megfontolja ezt a funkciót. -
Abu85
HÁZIGAZDA
válasz
TTomax
#20530
üzenetére
Csak nem 3rd party programból kértem.
(#20532) mcwolf79: A tuningprogramokra és tuningmodulokra a cégek különböző felelősségeket vállalnak Ezért javaslom az EULA-k elolvasását, hiszen az segít megérteni a különbségeket.
Az AMD azért vállal többet a 3rd party programoknál, mert gyári modulról van szó, tehát képesek úgymond garantálni azt, hogy a kártya automatikus ventilátor szabályozása működőképes marad. Ezt például egy 3rd party program nem garantálja. De az is igaz, hogy egy módosítás működését már egyik EULA sem garantálja. Ugyanakkor az AMD modulja úgy van beállítva, hogy vannak határok, amelyek biztosítják a reális működési lehetőségeket. Például a memóriaórajel esetében annak olyan hibák, amikor a magasabb órajeltől csak pár 30-40 cella esetében lesz probléma, amit az EDC mondjuk nem képes korrigálni. Ilyenkor a tuning stabil lesz, de 2-3 órával a játék indítása után megjelenhetnek képi hibák. Na most az AMD erre alkalmaz úgynevezett paraméterezési limiteket. -
Abu85
HÁZIGAZDA
Az EULA-ban világosan le van írva, hogy az AMD mire vállal felelősséget és garanciát. Amikor feloldja a user a tuningmodult, akkor ezt el kell fogadni. Sokkal többre vállalnak garanciát, mint bármelyik 3rd party tuningprogram. De természetesen hardvertől függő dolgokra nem. Ebben az órajel és például a ventifordulat paraméterezése is benne van. Ellenben arra van garancia mindenhol, hogy a gyári hűtés szoftverkonfigurációja működni fog.
Olvassatok el egyszer egy ilyen EULA-t. -
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
válasz
schawo
#20362
üzenetére
Mindig megoldják ezt a problémát. Időnként előjön egy nagyobb frissítésben, és pár hét alatt reagálnak is rá. Ezért sem volt érdemes nagy dobra verni, mert viszonylag sűrűn fut bele ebbe a gondba az NVIDIA az új driverekkel. Évente egyszer minimum. Aztán jön egy új driver és újra jó.
Ú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.
- gban: Ingyen kellene, de tegnapra
- exHWSW - Értünk mindenhez IS
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- Android játékok topikja
- Luck Dragon: Asszociációs játék. :)
- Házimozi haladó szinten
- Xiaomi 15T Pro - a téma nincs lezárva
- Telekom mobilszolgáltatások
- Milyen belső merevlemezt vegyek?
- OLED monitor topic
- További aktív témák...
- PlayStation Okosító Blu-ray lemezek - PS4 GoldHEN Loader / BD-JB Lapse és PS5 Auto Jailbreak AIO
- Xiaomi 17 Ultra Starlit Green 512GB használt karcmentes garancia 2029.03.05.-ig + Photographer Kit
- BESZÁMÍTÁS! Asus ROG Strix B450F R5 5600 32GB DDR4 512GB SSD RTX 2070 Super 8GB Zalman S2 TG TT 650W
- Részletfizetés Kamatmentes 12 havi részlet Acer Predator 18 AI Gamer / Laptop RTX 5070 Ti Ultra 9
- Eladó Lenovo ThinkPad X13 Yoga Gen 3 2-in-1 érintőkijelzős üzleti laptop, beépített tollal
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest