Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Számos motornak van valamilyen temporális élsimítási metódusa. Frostbite, ez a Snowdrop, és még sorolhatnám, de ez nem ad olyan jó eredményt, mint a Remedy konstrukciója. Persze nem is igényel annyi erőforrást, tehát megvan a pro-kontra érv mellette és ellene. A TAA leginkább a shader aliasingon segít, lásd a Need For Speed TAA-ját egy rakás specular map mellett.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#15782
üzenetére
A GameWorks csak egy nehezítő tényező. Kapsz egy middleware-t integrálásra, és ha nem fut jól, akkor semmit sem tudsz vele csinálni. A DX12 ezen még annyit nehezít, hogy a GameWorks ilyen API-ba csak speciális emulációs réteg mellett építhető be. Ezért nincs még VXAO az új Tomb Raiderben DX12 alatt, mert még nincs kész rá az emulátor.
Összességében a zártság mindig nehezebb monitorozhatóságot tesz lehetővé. Tulajdonképpen ez a DX12 egyik alapja az, hogy eltűnjön egy nagy zárt réteg a fejlesztők elől, amit kernel drivernek hívtak, így a program teljesítménye teljesen monitorozható legyen. Aztán a toolok állapota egy másik kérdés. Ma nem igazán van stabil DX12 profilozó a PerfStudiót leszámítva. Ez nyilván nem könnyíti meg a fejlesztéseket. A Microsoft ezért hozza amúgy a PIX-et PC-re. -
Abu85
HÁZIGAZDA
válasz
#85552128
#15779
üzenetére
A temporális zavarokat a visszaskálázással nem lehet annyira javítani, amennyire ez cél volt a fejlesztőknél. A radikális előrelépésre az eddigi kutatások szerint négy képkocka számítása jelenti. Azon van a vita, hogy megéri-e ugyanarról a jelenetről készíteni négy eltolt képkockát, vagy jó lesz a korábbi három a negyedik friss mellé. Az aktuális eredmények szerint egyértelműen nincs akkora javulás a natív konstrukcióval, hogy azért megérje megnegyedelni a teljesítményt. Egyébként nyilván megtehetnék azt is, és akkor a mostani eredményeket osszátok el néggyel. Amúgy egy picit az biztos szebb lenne.
Akármilyen képarány támogatható csak be kell építeni a támogatását.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#15777
üzenetére
Azért találták ki ezt, mert radikálisan csökkenti a temporális zavarok jelenlétét. A cél egy grafikai probléma kezelése volt. Nem újdonság ez, más is kísérletezik hasonló modelleken, csak még nem jutottak el addig, hogy kész játékban bevessék. Elsődlegesen azért, mert komoly módosítást igényel a motorban.
Nyilván itt arról van szó, hogy volt egy kitűzött cél a képminőségre, amit el akartak érni, és mondjuk, ha minden jelentről születne négy eltolt 1080p-s 4xMSAA-s képkocka, akkor az sokkal jobban fájna, minthogy most születik egy 720p-s 4xMSAA-s, az előző három jelenet eredményeivel együtt.Akkor arról érdemes lenne szólni a fejlesztőknek, hogy nézzék meg, mert nálunk nincs ismert hiba feljegyezve AMD-re. Én is beleraktam már 15 órát fagyás nélkül.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#15773
üzenetére
Ennek semmi köze a konzolhoz. Van egy alapvető leképezőjük, amelyhez egy olyan temporális rekonstrukciós eljárást választottak, ami az elvégzett tesztjeiken a legjobb minőséget adta. Ennek megírt motorhoz van köze. Ha nem lenne konzolra ez a játék, akkor is így működne a PC-s port, mert ilyen motort írtak.
Van egy ismert, de egyelőre nem kezelt hibája a GeForce drivernek, ami a Tile Resource contract funkcióval befagyaszthatja az OS-ben a DXKG-t. Ez a Quantum Break és a Hitman alatt is előjön szinte mindig ugyanazokon a helyeken. Hozzávetőleg fél éve keresi az NV a megoldást a hibára. Előbb-utóbb kiadnak valami fixet. Legrosszabb esetben a Microsoft csinál egy OS update-et, ha a GeForce-ok mégse tudják lekezelni a GPUMMU specifikációt. Hasonló "fix" van Intel Gen7.5-re is.
-
#15769
Abu85
HÁZIGAZDA
Malibutomi
#15768
Abu85
HÁZIGAZDA
válasz
Malibutomi
#15768
üzenetére
Ez nem a DX12 miatt van, hanem amiatt, hogy az új tervezésű motorok sávszéllimitessek ezekkel a PBR árnyalásokkal. Amikor a Maxwell kijött, akkor a PBR nem volt elterjedt.
-
Abu85
HÁZIGAZDA
válasz
#45185024
#15761
üzenetére
A Quantum Break igazából nem fut rosszul GeForce-on, csak ahol sok a volumetrikus fényhatás és köd ott van egy kisebb ütés. [link] és [link] - Ennek talán lehet köze ahhoz, hogy ezeket a számításokat async compute mellett végzi a motor gyártóspecifikus kód nélkül, vagyis a GeForce-on is aszinkron fut a számítás. Ettől fekszik meg a Maxwell ezeken a területeken. A többi helyen közelebb van a Radeonhoz a GeForce.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#15667
üzenetére
Attól függ, hogy mivel méred. A PresentMon nem mér a CPU után, tehát a valós teljesítményt azzal nem kapod meg, ezért lesz olyan ugrálós az eredmény, mintha állandó mikroakadás lenne, de valóságban nincs, mert az a program csak egy részeredményt közöl a másik fontos eredmény nélkül. Az Action! sem jó erre, de biztosan közelebb van a valósághoz, mint a PresentMon, persze csak ha jól számolsz.
DX12 méréshez egyébként beépített bench vagy mérő szükséges. Külső programmal ez nem lehetséges, legalábbis nem lesz teljes a kép.
(#15668) Loha: Az ASIC Quality marhaságot nem nézzem, de írtam, hogy 12 bin aktív a kötelező 4-ből.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#15662
üzenetére
Maga a hitelesítési folyamat a rossz a GeForce-nál. Minden mai hardveren van már variancia, de a GeForce esetében ez akár 10% is lehet. A 980 Ti esetében konkrétan ennyi, vagyis, ha bemész a boltba és leveszel két ugyanolyan 980 Ti-t, akkor azok között a legrosszabb esetben 10%-nyi teljesítménykülönbség van. Ezt kellene az NV-nek kisebb szintre szorítania. A gyári tuning esetében ez a variancia még rosszabb lehet, ott a maximális érték az EVGA-nál van, ahol 17% lehet a különbség két ugyanolyan gyári tuningos modell között. És a tesztekre amúgy a full bint küldik, nekünk is az van.
Szerintem az AMD és az Intel által elfogadott 5% alatti variancia, ami elmegy. -
Abu85
HÁZIGAZDA
válasz
füles_
#15655
üzenetére
De van DX11-re, már a megjelenés óta. DX12-re meg ugye nem lehet profilt csinálni, mert ott nincs kernel driver.
Az új Hitman alatt a Glacier 2 tartalmaz egy ilyen rendszert: [link] - nem ugyanezt, de hasonlóan működik. Ez segíti a Radeont, mert ehhez a rendszerhez DX11 kiterjesztésekben multi-draw, DX12-ben pedig executeindirect kell. Az ilyen multi-draw rendszerek agresszív használata nem fekszik az Intelnek és az NV-nek. Nem is nagyon ajánlják, hogy túlmenj egy bizonyos limiten. Az Intel sehogy sem ajánlja, mert ők ezt emulálják.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#15621
üzenetére
Mert DX11-ben nem lehet mérni a driver által elrejtett részeket. DX12-ben viszont maga a program a driver, így monitorozhatóvá vállnak ezek a területek is. Ez ugyanaz, mint az Ashes mérése. Ott is több adatod ad a DX12-re csak azért, mert a driver már nem egy hatalmas feketedoboz, hanem egy teljesen nyitott könyv.
-
Abu85
HÁZIGAZDA
Az NVIDIA-é nem. Csak az AMD-nek vannak ilyen multiprecision ALU-i. Az világos, hogy a multiprecision ALU-nak sok előnye van, de a tervezőasztalon iszonyatos mértékű munkával jár. És itt ezt úgy kell érteni, hogy nem elég magát az ALU-t jól tervezni, hanem konkrétan nulláról kell felépíteni hozzá az architektúrát. Az AMD is csak azért csinálta meg, mert a GCN-t nulláról építették. A Pascal még mindig egy Fermi származék az alapjait tekintve. Az NV valószínűleg akkor csinálja meg, amikor ők is a nulláról kezdik elölről.
(#15592) gV: Tökmindegy a játék. Az a pletyi, hogy ebben a lapkában se ROP, se setup nincs.
-
Abu85
HÁZIGAZDA
Egyszerű a működés. A menüben kiválasztott felbontás négy darab korábbi kiszámolt képkockából születik meg. Ezeknek a felbontása a beállított kimeneti felbontás 67%-a. 1080p esetén például 4x720p, 1440p-vel 4x950p, 4K-val 4x1426p. Ilyen formában lesz leszűrve a textúraszűrés temporális zavara.
-
#15461
Abu85
HÁZIGAZDA
FollowTheORI
#15460
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#15460
üzenetére
Az a baj, hogy a SteamVR teszt semmit sem ér, mert egy ősrégi SDK-ra épül, amiben semmi olyan dolog nincs, ami lesz például a játékokban. A gond itt az OpenVR, ami hozzávetőleg egy-másfél évvel van lemaradva az Oculus PC runtime mögött. Emiatt nincsenek olyan dolgok benne, mint TW/ATW/LL, és egy rakás egyéb tényező, amely szükséges ahhoz, hogy a VR jó sebességet adjon jó grafika mellett. Ezért nem az OpenVR-re épít egy csomó ma megjelent játék, mert technikailag képtelenek elérni azt a sebességet, ami szükséges. Persze majdnem egy évtizedes grafikai színvonalra így is jó, de pont ezért lesz előnyben az Oculus, mert ők modern grafikára is képesek.
Ha VR teszt kell, akkor a VRScore és a VRMark a mérvadó. -
Abu85
HÁZIGAZDA
válasz
FLATRONW
#15392
üzenetére
Ez még ennél is bonyolultabb. Mivel buliban vagyok, tényleg nem akarok ennek nagyon a mélyére ásni, de mielőtt még totál részeg leszek leírom, hogy a Maxwell támogatja az async compute-ot, csak olyan GMU-kat használ, amelyek nem támogatják az erőforrás-korlátozást. Lényegében ezt kell beépíteni mindegyik GMU-ba és megvan oldva az, hogy a hardver semmilyen multi-engine kódtól ne lassuljon. Azt tényleg nincs időm kifejteni, hogy ez miért van így, meg hasonló, de szerettem volna jelezni, hogy ezek a cikkek totál szenzációhajhász bullshitek. Lehet róluk beszélni, de felesleges. A százalékos változás pedig folyamatfüggő, de amit az NV ki akar védeni az a lassulás bekövetkezése.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#15380
üzenetére
Nem jelent problémát. Röviden létezik a WCCFtech/BitAndChips és a valóság. Amíg ezek az oldalak képtelenek megérteni, hogy az async compute még csak nem is egy D3D12-es fícsőr, addig azt is felesleges elvárni tőlük, hogy megfelelő helyiértéken kezeljék ezeket a "saját forrásból származó" híreszteléseket.
Nagyon sokan, nagyon sokszor leírták nekik, hogy olyan, hogy async compute nem igazán van. A D3D12-nek ez a funkciója a multi-engine, amit kötelező minden implementációnak támogatni. Olyan nincs, hogy valaki nem támogatja. Azt az implementációt a Microsoft egész egyszerűen nem fogadja el. Konkrétan ahhoz vezet az egész, hogy az alkalmazás nem fog elindulni egy multi-engine-t nem támogató hardveren. És nagyjából ez az, ami számít. Nincs tovább, kész, pont. A programozónak a feladata, hogy a multi-engine implementációkra írjon megfelelő kódot, amit aztán a DXKG, az UMD és az OS minden hardveren megfelelően futtat. Akár az is opció, hogy maga a kód single-engine legyen, vagyis a program egyszerűen direkt kikerüli a DXKG-t és az UMD-t, de ez azért nem ajánlott, mert ilyenkor a parancsok betöltéséért az OS felel, ami jó dolog a grafikai futószalagoknál, de nagyon rossz dolog a copy és a compute futószalagoknál. Emiatt a single-engine kódot a Microsoft csak nagyon indokolt esetben ajánlja, és csak device ID-hez kötve, mert lehet, hogy pár hónap múlva módosítanak az OS betöltőmodulján, amit nem terveztek arra, hogy normálisan kezelje a copy és a compute futószalagokat. Ilyen esetben például egy OS módosítás futtathatatlanná teheti az alkalmazást a single-engine kódot kapó hardvereken. Többek között ezért is használ mindenen multi-engine kódot a Rise of the Tomb Raider, a Hitman és az Ashes of the Singularty az aktuális verzióra vonatkozóan. Egyedül a Gears of War: Ultimate Edition aminek két kódútja van, egy default a egy csomó hardverre, és egy single-engine az Intel Gen9-re, illetve az NVIDIA Maxwell2-re. De ezek a multiadapter beépítése után le lesznek cserélve a default kódra, mert nem jó dolog nyitva hagyni annak a lehetőségét, hogy ezeken a hardvereken egy D3D frissítéssel futtathatatlanná váljon az alkalmazás.
Az async compute és async copy magából a multi-engine kódból dolgozik, és direkten semmi köze a D3D12-höz, de közvetve nyilván a DXKG-n és az UMD-n keresztül működik. Ezért aktív például az összes DX12-es játékban, mert csak az eleve megkövetelt multi-engine kód kell a működéséhez és nem valami nagyon specifikus, komoly szaktudást igénylő, hónapokig tartó programozói munka. És itt jön a lényeg. Maga az async compute és az async copy leginkább arra való, hogy a hardverben kitöltse az idle buborékokat. A gyorsulás mértéke is attól függ minden kódnál, minden hardver esetében, hogy az adott kóddal és adott hardver párosításával mennyi idle buborék maradt, amelyeket potenciálisan le lehet fedni. Szóval a média egy totális tévúton van azzal kapcsolatban, hogy igazából ez az egész hogyan működik. Ez jó táptalaj a szenzációhajhászásnak is.Hosszabb távon egyébként a multi-engine egy nagyon fontos funkció, mert ahhoz, hogy a GPU-k a jövőben skálázódjanak egyre inkább úgy kell őket tervezni, hogy egyre több szálon dolgozzanak, amitől persze nőhet az idle buborékok száma és mérete is, amelyet a multi-engine funkció fog kezelni. A Microsoft pedig azért ennyire erőszakos ezzel a funkcióval kapcsolatban, mert látják, hogy a multi-engine kód bizonyos hardvereken nem hatékony, holott a hardver amúgy képes lenne bizonyos mértékű aszinkron végrehajtásra. Tehát ők ezt nagyon alaposan átrágták és úgy alakították ki a specifikációkat, hogy kiválasztottak a jelenlegi hardverfelhozatalból egy dizájnt, amit jónak tartanak (ez a GCN), és arra írtak egy követelményrendszert, hogy az Intel és az NVIDIA azt lemásolhassa, és a jövőben érkező hardvereik már a GCN-hez hasonlóan működhessenek. Tehát amikor elérjük azt az időt, amikor az általános skálázódás érdekében a hardverek egyre nagyobb problémamegoldásra lesznek tervezve, akkor a multi-engine funkció a ma szigorúnak tartott specifikációk miatt nem engedi, hogy a piac beleessen a potenciális limitációkba.
-
Abu85
HÁZIGAZDA
válasz
namaste
#15312
üzenetére
De most emlékeztetőül arról beszélünk, hogy az NV a DX11-hez tartozó kernel driverben alkalmaz egy speciális memóriavezérlést, amivel sebességet nyernek annak az árán, hogy több VRAM-ot használnak. Ez alapvetően egy jó dolog, mert több lesz tőle az fps. Még ha marginálisan is.
-
Abu85
HÁZIGAZDA
válasz
namaste
#15307
üzenetére
Gondolhatod, hogy az NV nem fog azzal kiállni, hogy ezt meg azt butítottuk a Keplerhez képest a Maxwellben.
Pont azért nincs anomália, mert a driver menedzseli a memóriát. Egyszerűen a programnak nincs kontrollja. Ha nem így működne, akkor beleütköznél ezekbe az anomáliákba.
Jaj azt ne úgy képzeld el, hogy minden négyszer van benne. Ha a bracnhing úgyis elfedi a feltöltést, akkor felesleges többször belerakni a memóriába az adatot. Ha nem fedi el, akkor mehet.
Szép lenne, ha az NV-re vérmókusokat küldenének, csak mert az ilyen trükkökkel nagyobb tempót ad.HUB!
-
Abu85
HÁZIGAZDA
válasz
namaste
#15305
üzenetére
Régebben mondta az NVIDIA, hogy így érdemes csinálni. De ugyanezt mondta az AMD is, csak ők azért tértek váltottak át memóriakímélésre, mert már nem crossbart használnak, de ha azt használnák, akkor valószínűleg ők is így csinálnák, mert előny teljes sávszélességgel elérni az adatot, mintsem felezettel. Azt kell figyelembe venni, hogy a memória olcsó lett. Régen nyilván nem volt célszerű duplikálni az adatot, de ma már az, mert annyira olcsó a GDDR5-ös és a DDR3-as memória, hogy megéri 3+ GB-os kártyákat tervezni. Gyakorlatilag belépőszinten sem találsz 2 GB-nál kevesebb VRAM-ot, tehát az NVIDIA számára célszerű hasznosítani a memóriát, ha már így alakult. Valószínűleg, ha az NV is vált a crossbarról, mert HBM mellett már nem ártana, és az explicit API-k sem a crossbarnak kedveznek, akkor átgondolják a menedzsmentet is.
-
Abu85
HÁZIGAZDA
A csatorna 64 bites. A belső vezérlő 128. A Maxwell egy csomó trükkös dolgot bevezetett, hogy tranyót spóroljon meg. Ilyen például az, hogy két csatornát kifelé egy olyan vezérlő kezel, ami nem különálló. Ezért volt célszerű a keresztbe címző buszok szélességének felezése, mert egy vezérlőnek nagyobb memóriaszeletre van rálátása. Maga a koncepció nem rossz egyébként ha a vezérlés jól van hozzáillesztve. Itt arra kell gondolni, hogy érdemes sokszor duplikálni az adatokat, mert kifizetődik. Az NV sosem riadt vissza ettől a módszertől, csak most nagyon ráerősítettek.
A GTA5 például pont emiatt a működés miatt számol az NV-nek több memóriát ugyanarra a beállításra, mert számításba veszik, hogy a driver az adatok nagyjából 25%-át duplikálja, így a default számolást megszorozzák 1.25-tel. -
Abu85
HÁZIGAZDA
A Fermi idején ez inkább egy rossz optimalizálás volt, amit orvosoltak. A Maxwellhez azért kell, mert a memóriaelérést keresztbe megfelezték, tehát az egyik SMM csak az egyik memóriavezérlő memóriaszeletéből éri el az adatokat teljes sebességgel. Ha nem ott van az adat, akkor a keresztbe kötött busz már rögtön csak fele olyan széles, így az adatelérés elméleti maximuma is felezett lesz. Ezért az NV ma nagyon ráállt arra, hogy duplikálja az adatokat, mert az kedvező, ha nem felezett sebességű az elérés.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#15297
üzenetére
Jó, csak ha ezt te kikötöd, akkor éppenséggel azt várod el, hogy olyan minimum memóriaszelet legyen megadva a specifikációban, amiben garantáltan nem lehet duplikált adat. Ilyen formában egy R9 Fury X 3,5 GB-os, míg egy GTX 980 Ti 1 GB-os. Szóval ez marhára nem egy egyszerű összeadós matek, mert architektúraspecifikus vezérléstől függ a duplikálás mértéke.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#15295
üzenetére
Az a baj, hogy a memóriát úgy képzelitek el, hogy biztosan vagytok benne, hogy minden csak egyszer kerül bele. Nos igen úgy is lehet csinálni, de például az NVIDIA driverei a Maxwell óta alkalmazzák azt a vezérlési sémát, hogy ugyanazokat az adatokat egy GPU-nak a memóriájába többször rakják bele, mindig másik VRAM szeletbe, hogy ne kelljen a Crossbarnak keresztbe címeznie, mert úgy csak felezett sebességű lehet az elérés. Tehát attól, hogy egy adat kétszer van a memóriában, még nem duplikált a memória. A DX12-ben a két GPU-s memóriaelérés elvben nem különbözik attól, amit az NV csinál DX11-ben egy GPU-ra. Azon lehet vitázni, hogy ilyen formában mennyi az annyi, de felesleges. Egyszerűen mindenkinél van valami egzotikus vezérlési séma, ami miatt az x GB a gyakorlatban csak x-y GB.
-
Abu85
HÁZIGAZDA
válasz
cyberkind
#15283
üzenetére
Az összehasonlítást behatárolja, hogy mi létezik. Működő Pascalt még senki sem látott. Működő Polarist már igen. Legutóbb a GDC-n három napig lehetett Hitmanezni egy Polaris 10-en.
A Pascalt nehéz megfejteni, mert az OEM-ek sem kaptak még semmit. De persze áprilisban kapniuk kell valamit, különben a Computexre nem tudnak működő mobil prototípusokat vinni.
-
Abu85
HÁZIGAZDA
válasz
velizare
#15265
üzenetére
Igen, de a megnyitás a PhysX esetében nem sokat ér. Eléggé kötött ugyanis a licenc. Mindenesetre működik és ingyen van, tehát megfontolandó alternatíva. Meg eleve számításba kell venni, hogy a Dawn engine egy Glacier 2 származék, és a Glacier 2 mindig PhysX-et használt.
-
Abu85
HÁZIGAZDA
válasz
velizare
#15262
üzenetére
A PhysX 3, főleg a 3.3 már nagyon jól optimalizált. Ezért is került ki belőle a GPU-s gyorsítás, mert annyira optimalizálták, hogy a CPU-s gyorsabb lett. Egy korábbi 3-as verziót tartalmazott a Witcher 3 is, és az elején a driver még elfogadta a GPU-s kódot, de lassabb volt, mint a CPU-s. Később már csak CPU-n futott a fizika.
Teljesen jó ma a PhysX és az APEX, ha a legújabb verzióról van szó. Nem sokkal kínál kevesebbet, mint a Havok. Utóbbi azoknak jó, akik nagyon bele akarnak nyúlni.
-
#15181
Abu85
HÁZIGAZDA
Firestormhun
#15157
Abu85
HÁZIGAZDA
válasz
Firestormhun
#15157
üzenetére
Nem kell újratölteni. Egyszerűen csak menj a menübe és kapcsold ki az ambient occlusiont. Lépj vissza a játékba, majd menj be újra a menübe és kapcsold vissza. Ugyanaz lesz az eredménye, mint az újratöltésnek, csak újratöltés nélkül. Ez azért van, mert a játékban az összes ambient occlusion effekt middleware-en keresztül van betöltve. Még a játék sajátja is, hogy betölthető legyen az NV-nek a middleware-je. Ugyanakkor ezt a modell a DX12-nél nagyon nehéz normálisan kivitelezni, mert kell építeni rá egy komplett emulációs réteget, ami sajnos extra memóriát használ, az idő előrehaladtával egyre többet (ez egy bug benne, nem kellene, hogy így legyen). Ha kikapcsolod az AO-t és bekapcsolod, akkor az újraindítja a middleware emulációt, ami a gondot okozza. Egyébként bármilyen más effektet is kikapcsolhatsz, ami memória átrendezést igényel, mert akkor is újraindul a middleware emuláció. Amikor váltasz, akkor látni fogod, hogy a váltásnál picit leesik az fps. A menüben vagy, tehát ez nem baj, de a memória átrendezése megtörténik. 1-2-3 másodperces folyamat. Hasonló problémával küzd egyébként a Gears of War Ultimate Edition, csak ott a fejlesztők gondoltak a middleware hátrányaira, így időnként automatikusan újraindítják az emulációs réteget. Ettől lesz egy mikroakadás, de a játék megy tovább.
-
-
#15065
Abu85
HÁZIGAZDA
Malibutomi
#15064
Abu85
HÁZIGAZDA
válasz
Malibutomi
#15064
üzenetére
A PCGH tesztjeiben általában a legnagyobb gyári órajelű kártyák szerepelnek az adott sorozatból. Ironikus módon ezek mennek egyébként vissza a gyártókhoz a legnagyobb arányban.
Instabilan lesznek eladva sajnos, mert senki sem teszteli ki a tuningot rajtuk.(#15066) TTomax: Én azoknál maradok. Túl sokszor égettem már meg magam a gyári tuninggal is. Egyszerűen nem éri meg emiatt szívni.
A kérdés a Fury X-re vonatkozott.
![;]](//cdn.rios.hu/dl/s/v1.gif)
(#15067) Szaby59: 1304 MHz az MSI garanciája.
-
Abu85
HÁZIGAZDA
válasz
rocket
#15039
üzenetére
Szerencsére nem. Annyira nem, hogy memóriával is rendelkeznek, így felismerhetnek, ha gyanús vagy. Mindenestre a lényeg, hogy ennek a játéknak nem az akció a megterhelő része, hanem a tömegjelenetek. A béta alapján megnézheted a Digital Foundry-n, hogy mi történik a sebességgel, ha sok ember van a jelenetben.
Ettől függetlenül a PCGH valóban nem a top. De hát ez az ára, ha valaki első akar lenni.
-
#15009
Abu85
HÁZIGAZDA
Malibutomi
#15007
Abu85
HÁZIGAZDA
válasz
Malibutomi
#15007
üzenetére
Ez nem annyira meglepő ezektől a GPU-driven pipeline motoroktól. Ezek DX11-ben is jelentősen eltérően működnek, mint a korábbi DX11-es leképezők.
-
Abu85
HÁZIGAZDA
válasz
velizare
#14980
üzenetére
A Snowdrop egy GPU-driven pipeline rendszer, mint az új Dunia és a Frostbite. Szóval a kiadott parancsok száma alacsony nagyon. Egyedül Intel IGP-n rossz a buli, mert az Intelnek nincs multidraw kiterjesztése DX11-re. Nem is támogatják az IGP-ik ezt a módot, de le tudják emulálni.
-
#14934
Abu85
HÁZIGAZDA
huskydog17
#14931
Abu85
HÁZIGAZDA
válasz
huskydog17
#14931
üzenetére
Az MS a fejlesztéseit szerintem játéktól függetlenül visszaírja. Elvégre sok játékhoz licencelték az UE4-et.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#14903
üzenetére
A Store vélemény az érdekes. A játék sokkal jobb lenne nélküle. Ez az ami teljesen életképtelenné teszi ezeket a játékokat. Emiatt nem vettem meg én sem. Tesztre is totál alkalmatlan minden Store-os játék.
Az a Hitman béta egy decemberi build volt, persze szűkös a két hónap, de elég idő ahhoz, hogy a decemberben még nem stabil optimalizálásokat beépítsék.
(#14904) Pepeeeee: Nem még.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#14901
üzenetére
Én még nem láttam elégedett júzert az új GoW-val kapcsolatban.
De egyébként ez semmiképpen sem a DX12 hibája. Annyira régi kódot nem lehet már jól felkészíteni egy új API-ra. Ez a remake-ek átka. Már csak azért is egyedi a probléma, mert például az Oxide egy erre írt motorral sokkal többet kihoz a DX12-ből, és akkor még a héten lesz Hitman, szintén DX12-höz tervezett motorral. Ha abban is működik az API, akkor nem azzal van a gond, hanem a GoW-val. -
Abu85
HÁZIGAZDA
válasz
TTomax
#14895
üzenetére
Természetesen QA nélkül hiba kiadni egy végleges kódot. Ennél az is sokkal jobb lett volna, ha kiadják a QA-s kódot, és azt frissítik egy javítással, így maradt volna idő a QA-ra. Viszont nem tudni, hogy a gyártóknak leadott kódról mik voltak a visszajelzések, csak azt, hogy az AMD-nek sokkal gyorsabban futott. Szerintem a béta elfogadhatatlan volt, mert ezen a héten itt a Hitman és nem bétaként szállítja a DX12-t. Az MS első akart lenni. Ez valami beteges perverzió lehet náluk.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#14894
üzenetére
Nem fogod fel, hogy nem az AMD-vel van probléma, hanem a multi-engine kóddal, amin minden új generációs hardver fog futni, mert a single-engine kódot nem viszik tovább. Azt csak a pár Intel és NV hardverre fejlesztették, hogy ne essen össze a teljesítményük a szabványos multi-engine kódtól. Az valóban hiba, hogy egy játékot QA nélkül adnak ki, de manapság ez megszokott, sajnos. Néha nem jön be.
-
Abu85
HÁZIGAZDA
válasz
cyberkind
#14891
üzenetére
Abból amit eddig tudni, vagyis hogy a béta build jól ment arra lehet következtetni, hogy valamit elrontottak az utolsó, kiadásra jelölt buildben és idő hiányában már nem csináltak QA-t, vagyis a hiba lényegében egy-két nappal a megjelenés előtt derülhetett ki. Innen nem mindenki szereti már halasztani a startot. Régen lehet, hogy azt mondták volna, hogy akkor plusz egy hónap, de ma már annyira az internetre van kötve mindenki, hogy simán vállalható a patch.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#14889
üzenetére
Szerintem nem értik a fórumtársak a problémád. A fejlesztők a megjelenés előtt bejelentették, hogy a GCN2 és GCN3 kártyákon problémák lesznek, mivel a kód csak a GCN1-en fut viszonylag jól. Ettől függetlenül azon is lassít, csak nem 30-50%-ot, hanem 3-5%-ot. Ezt nem értik, hogy ezen a tök hivatalos bejelentésen mi az amit nem tudsz megérteni. Még azt sem lehet mondani, hogy a fejlesztők elbújtak. Kiálltak és bevallották, hogy rossz, és úton a javítás.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#14883
üzenetére
Ez a játék a fejlesztők saját bevallása szerint hibás több ponton, amire szintén a fejlesztők saját bevallása szerint tervezik a patch-ek megjelenését. Teljesen értelmetlen egy olyan játékkal jönni, amiről a fejlesztőik, direkt még a megjelenés előtt kiadtak egy listát, hogy milyen komolyabb problémák vannak, és ezekre milyen javítások érkeznek, vagy mit lehet tenni, amíg ezek nincsenek itt.
Ha a szőnyeg alá akarnák söpörni a problémát, akkor nem álltak volna ki a nyilvánosság elé, hogy jönnek a javítások. Nyilván ezt el sem tudják kerülni, mert minden új architektúrára azt a kódot fogja futtatni, amit az AMD futtat most, tehát muszáj megjavítani, ha nem akarják, hogy az összes új hardverrel rossz legyen. -
Abu85
HÁZIGAZDA
válasz
#85552128
#14875
üzenetére
Nem kell, bár a middleware-eket itt pont a kiadási buildben frissítették, tehát ezeknek jó eséllyel közük van bizonyos problémákhoz, mert a játék sok más hibával is küzd. Az persze nagy kérdés, hogy miért frissítenek middleware-t QA után.
A GameWorks itt lényegtelen, mert ebbe a játékba nem middleware formában van belerakva, mivel az nem támogatja még a multi-engine-t. -
Abu85
HÁZIGAZDA
válasz
#85552128
#14868
üzenetére
Az AMD nem tudta, hogy így kerül ki. Ők tesztelték a kiadás előtti buildet, és az hibátlan volt. A kiadásra romlott el az utolsó frissítéssel.
A legvalószínűbb, hogy az történt, hogy volt egy kiadás előtti build, amire lenyomták a QA-t, aztán frissült a játék, és arra már nem csináltak QA-t. Ezzel nyertek nagyjából egy hónapot a kiadás szempontjából. Attól, hogy mondjuk itt esetleg érzékelték a hibát, már nem tehettek semmit. -
Abu85
HÁZIGAZDA
válasz
TTomax
#14866
üzenetére
Mivel ez nem olyan hiba, hogy napokon belül lehessen javítani, így biztosan észrevették a tesztelésnél, csak képtelenség volt a megjelenésre kijavítani. Az MS ezt PR szempontból közelítette meg. Valószínűleg mindenképpen ők akarták az első DX12-es játékot, ami nem early access, nem is egy elbaszott alkotás, hanem kész AAA játék. Ezért mindenképpen a Hitman előtt kellett megjelenni. Ha ez nem számított volna, akkor nyilván eltolják a megjelenést áprilisra, amikorra jön a multiadapter támogatás is, a Hitman pedig elvihette volna az első, ténylegesen kiadott AAA DX12-es játék címét.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#14855
üzenetére
A kód mindegyiken hibás, csak az első GCN-en nem okoz túl nagy lassulást. A javítástól mindegyik gyorsulni fog, csak nem ugyanolyan mértékben. Ugyanez a kód fut majd a jövőben érkező architektúrákon is, immáron gyártóktól függetlenül, ezért fontos megjavítani.
A program úgy oldja meg egyébként a multi-engine és single-engine közötti választást, hogy a futtatás elején van egy feltételes elágazás, ami bekéri a deviceID-t. Ha a deviceID megegyezik a listában lévővel, akkor a korlátozott single-engine kód fut. Ha eltérő, akkor a szabványos multi-enigne kód fog futni. Jelenleg a listában Skylake IGP-k, illetve Kepler és Maxwell GPU-k vannak, és ez nem is fog már változni. -
Abu85
HÁZIGAZDA
válasz
#85552128
#14828
üzenetére
A GCN1-et is sújtja a rossz szinkronizáció, csak nem támogat elég parancslistát, hogy belefusson a problémába. De mint mondták a fejlesztők, ezt ki fogják javítani napokon belül. Valószínűleg azt hitték, hogy elég, ha egy revízión megnézik, de nem, mindegyiken meg kell nézni. Ebből az is érthető, hogy a Maxwell, Kepler, Intel Gen9-en, miért tiltják inkább, ahogy például a Hitman esetében is tiltani fogják. Ez egyébként jelentősen felértékeli az Oxide munkáját, ahol inkább leültek és megoldották, hogy menjen a multi-engine kód minden hardveren. De ahogy látszik messze nem ez lesz az általános, hanem multi-engine AMD-re és single-engine Intel/NV-re.
Egyébként a GoW szinkronhibát javító tesztkódja bő 30%-ot dob a GCN2-3-on.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#14812
üzenetére
Nincs semmiféle ellentmondás. A driveren lehetne javítani, de csak 2-3%-ot jelentene. Ez egyébként eleve be lesz építve elsődlegesen a Hitmanhez, mert az is olyan async compute modellt alkalmaz, mint a GoW. A GoW-ot viszont frissíteni kell, mert szimplán rosszul szinkronizálja a feladatok elindítását, amihez a driver nem nyúlhat. Szóval a driverre felesleges várni, mert az ilyen helyzetben képtelen segíteni a DX12 felépítése miatt.
Szerk.: A Microsoft ezt rendelte meg. Eleve fölösleges volt egy remaster ebből a játékból. Mi extrát nyújt az eredetihez képest? Semmit. Nem vagyok remaster meg HD remake ellenes, de ez arra van, amikor eltelik úgy tíz év, és tényleg jól fel lehetne újítani egy klasszikust. Lásd Tomb Raider 1->Tomb Raider Anniversary.
-
Abu85
HÁZIGAZDA
válasz
#45997568
#14808
üzenetére
Nem. A Deus Ex-et egy másik stúdió fejleszti, meg annak a PC-s portját a Nixxes csinálja. A Hitman esetében az IO felel mindenért, de persze segítséget azért kapnak. Elsődlegesen most azért alakult így, mert az új Hitman célpiaca a PC lesz az évados felépítés miatt. Olyasmi modell készül, mint amilyenek a tévésorozatok. Kapsz epizódokat, amelyek közül az első évad van bejelentve. Ha sikeres lesz, akkor jövőre új évad jön, illetve kapnak a felhasználók is eszközöket, hogy saját epizódokat készítsenek. Lényegében az évadokért, vagy a hivatalos epizódokért kell fizetned.
-
-
Abu85
HÁZIGAZDA
Meg a HBAO+ nem is middleware-ből van betöltve, ugyanis azt még nem támogatja DX12-ben. Szimplán oda van adva a forrás a Microsoftnak, ami gondolom valami speciális licenc. Ugyanígy van a Rise of the Tomb Raiderben is. Ezért sem GameWorks játékként utal ezekre az NVIDIA.
A PhysX meg teljesen bullshit. Teljesen mindegy, hogy a motor erre vonatkozó beállítása False vagy True, ha csak a szoftveres feldolgozást támogató runtime van szállítva, márpedig most csak az van a programban.
UI.: tiltani kellene ezt a WCCFtechet.
-
Abu85
HÁZIGAZDA
Na most azért van pár olyan játék, ami a "DX11-ben is egészségesebben használja a CPU-t", mert a konzolon átállnak a fejlesztők a GPU-driven pipeline-ra. A PS4 és az XO is támogatja, és egyrészt ugyan kihasználható DX12/Vulkan API-ban is, másrészt elérhető DX11-ben egy-egy AMD/NV kiterjesztéssel. Az Intel mindegy, azok az IGP-k ezt a modellt amúgy is csak emulálni tudják, de ettől még kompatibilisek lesznek vele a programok, csak nem nyer vele a hardver semmit.
A GPU-driven pipeline nem csak azért terjedt el az elmúlt hónapokban, mert kedvezőbb az aktuális API-k limitációinak, illetve végeredményben a két konzolnak is, hanem azért, mert olyan optimalizálásokat is be lehet rajta vezetni, amellyel növelhető a raszterizáló hatékonysága. Sőt, a DX12/Vulkan (és konzolok) alatt ezt a compute-alapú szűrést aszinkron ütemezéssel is el lehet végezni, vagyis gyakorlatilag a számítások kvázi ingyenesé vállnak, így csak profitálsz belőle. Ilyen opcióval jön egyébként a Hitman, de tartalmazza egy ilyen koncepciót az új Frostbite is, így a Star Wars Battlefront, Plants vs. Zombies: Garden Warfare 2, és ami még jön erre motorra. Ez az optimalizálás a DX12 executeindirect funkciójával a legjobb, de csak azért, hogy ne kelljen a DX11-hez AGSL-t és NVAPI-t használni. A szabvány például azért fontos, mert a Star Wars Battlefrontba például csak az AGSL van beépítve a Radeonra, vagyis az NV-nél egy emuláció fut. A Plants vs. Zombies: Garden Warfare 2 már tartalmazza az NVAPI-s verziót is, és ezt a Hitman is tartalmazni fogja DX11 alatt.
Az Ashes of the Singularity fejlesztői nem különösebben szeretik a gyártóspecifikus hackeket. Gondolj bele ebbe te is, és tulajdonképpen arra jutsz, hogy meg lehet érteni őket ezért. Azzal persze lehetne rugózni, hogy a DX11-es kódjuk lehetne gyorsabb is, ha bevetnék az AGSL-t és az NVAPI-t, de szerintem ez számukra olyan mindegy, amikor a felhasználónak a megjelenéskor felkínálnak majd két szabványos explicit API-t. Nincs az az ember, aki a DX11-et fogja választani, ezért olyan hihetetlenül mindegy, hogy milyen gyors az a kód. És nem csak nekik, hanem a gyártóknak is. Az NV persze lehet elég perverz ahhoz, hogy ragaszkodjon hozzá, hogy szénné optimalizáljanak rá egy DX11-es profilt, de ha megnézed a tesztoldalakat, mindenki arról ír, hogy a DX12-ben mi van. A DX11 senkit sem érdekel már. És megjegyzem függetlenül attól, hogy mi van most, azt is megértem, hogy az NV-nek bassza a csőrét, hogy beleinvesztáltak egy rakás pénzt a fast path parancsprocesszorba, az NVAPI-ba, az OpenGL kvázi átírásába a command list kiterjesztéssel, és persze ezek támogatásába, de mindeközben az AMD "dobjunk ki mindent és kezdjük elölről" lobbija győzött. És most nyilván az NV mérnökei sem hülyék, látva azt a szart, amit 20 év alatt az ipar felhalmozott simán a tiszta lap a legjobb megoldás, csak hát nem ebben fektették az erőforrásaikat, aminek már nem örülnek. -
Abu85
HÁZIGAZDA
Mit mikor? DX12-ben alapvető a megoldás. DX11-ben pedig a Frostbite, az új Glacier, az új Dunia, de még a Division által használt Snowdrop is GPU-driven pipeline. Szóval a játékok szempontjából tegnap, ma, holnap.
Ha azt várod, hogy az Ashesre optimalizálnak DX11 profilt, akkor ne várd. A játék négy API-t fog támogatni a megjelenéskor. Csak tud már választani a felhasználó egyet, ami nem DX11. -
Abu85
HÁZIGAZDA
A DX12 csak az ultimate megoldás. A DX11-ben is vannak megoldások, mint a multidraw indirect, amit ma már egyre több játék használ. Az újak közül szinten mind. De azzal a terheléssel, ahol ez probléma ott már átmennek a fejlesztők DX12-re, mert a DX11 nem alkalmas a feladatra. Az API-t 2000 batch-re tervezték, és nagyon nem alkalmas arra, hogy 10000-15000 batch átmenjen képkockánként. Természetesen lehet rá tervezni meghajtóprofilt, mert vannak specifikus megoldások, de ha van a programnak egy DX12-es módja, akkor mi a fenének? Úgysem a DX11-es módot fogja használni a felhasználó. Vulkan opció is lesz, ha valaki nem akar Windows 10-re váltani. Az AMD-nek még Mantle mód is van, innentől kezdve mi értelme van nekik a DX11-es módba erőforrást ölni? Ki fogja azt használni a tesztelőkön kívül?
-
Abu85
HÁZIGAZDA
Ugyanazt a sormintát mutatja a GTX 980 Ti csak más teljesítménnyel. A teljesítményeltérés pedig abból jön, hogy az NVIDIA a parancsmotorjába épített bizonyos fast path-okat, hogy gyorsabban dolgozza fel az egyes parancsokat DX11-ben. A DX12-ben ezek mennek a kukába, mert az OS-hez került a vezérlés, és az nem tölti már be a parancsokat a speciális parancsutakhoz, hanem használja az alapértelmezettet.
Ott van például a multidraw indirect is, mint gyártói kiegészítés, aminél szintén nem használhatók a speciális parancsutak, és DX11 alatt is erősebb a Radeon. Ilyen motor a Far Cry Primalhoz készült Dunia, az új Hitman Glacier frissítése, az új Frostbite. Persze ezekben a motorokban eleve nincs is ezekre szükség.
Az ultimate megoldás az egész nagy problémára a DX12-be épített executeindirect. Nagyrészt emiatt vette el az MS a fő parancsmotor vezérlését a gyártóktól. Persze ezzel megöltek pár innovációs lehetőséget, de az eleve csak tördelte volna a piacot.
-
Abu85
HÁZIGAZDA
Az aszinkron compute implementálása egyáltalán nem nehéz. Mivel a DX12 eleve multiengine API, így csak az a lényeg, hogy jó helyre töltsd a futószalagokat és jókor indítsd el. Nagyjából két napos meló egy single-engine korlátozás mellett. Persze el lehet rontani, de ettől nagyon gyorsan meg lehet csinálni. A aszinkron compute ott válik nehézzé, amikor olyat kell írnod, hogy minden architektúrán működjön valamennyire, és ne rontsa a teljesítményt túlságosan. De ezt nagyon kevesen vállalják majd be, legalábbis innen az látszik.
(#14752) Laja333: Ilyen azért lehet, mert amikor meghoztak bizonyos döntéseket a motorban, akkor a DX12-t helyezték előtérbe, így jó eséllyel a DX11-ben a szinkronizáció el van túlozva, vagy eleve nincs is jól optimalizálva. Sajnos nem lehet olyan döntéseket hozni, ami mindkét API-hoz tökéletesen igazodik.
-
Abu85
HÁZIGAZDA
Igazából miben villantsanak? Ez majdnem egy évtizedes motor strukturálisan abszolút nem a DX12-höz tervezve. Az még rendben van, hogy láttunk már UE3-ban jó explicit API implementációt a Thiefben, de abban a kódban kb. 5%-nyi eredeti UE3 kód maradt meg. És nem azért, mert annyira szerették átírogatni, hanem mert át kell írni, hogy működjön. A GoW egyedül a VRAM allokációból profitál, de másra nem is koncentráltak. Nincs mit igazán kirakni az ablakba ebből a szempontból, mert csak azt fogja kérdezni a user, hogy mi a fenének kell bika hardver pár picit élesebb textúráért. Itt inkább azt lehetne mutogatni, hogy hogyan ne csináld.
Ettől függetlenül persze megoldják a problémát, mert már tesztelik a javítást, de a játék alapja ettől még túl régi marad. Így senki sem fogja mutogatni.
-
Abu85
HÁZIGAZDA
válasz
mlinus
#14736
üzenetére
A játékélmény, illetve a játék szórakoztató faktora sajnos végképp nem az API-n múlik. Nyilván a Caffeine egy gyenge játék, amin nem fog a DX12 sem segíteni. Viszont az Ashes of the Singularity, Descent: Underground és a Squad már most többségében pozitív értékelésekkel rendelkezik. Nyilván okkal. Az Ashes of the Singularity az utóbbi évek legjobb RTS-e, a Descent: Underground egy eleve kedvelt játék remake-je (nehéz elrontani), a Squad pedig tényleg hangulatos annak ellenére, hogy a műfaj telített.
-
#14734
Abu85
HÁZIGAZDA
Bratilla95
#14730
Abu85
HÁZIGAZDA
válasz
Bratilla95
#14730
üzenetére
Nagyon egyszerű. A motor, amit alatta használnak majdnem egy évtizedes. De ott van még példának a The Talos Principle Vulkan kódja. Be lehet építeni egy explicit API-t, csak ha nem fejleszted hozzá a motort, akkor nem lesz gyors. A különbség az, hogy a The Talos Principle esetében a fejlesztők elmondták, hogy ez nekik most inkább egy teszt, amit csak kiraktak, hogy más is megnézhesse. Rajtuk nincs is az a nyomás, hogy ki kell javítani, mert sosem úgy beszéltek róla, hogy ettől eladást várnak. A Microsofton rajta van a nyomás, és ezért dolgoznak a patchen.
-
Abu85
HÁZIGAZDA
Most számoltam össze:
Megvásárolható DX12-es játékok:
Ashes of the Singularity, Descent: Underground, Squad, Caffeine, Gears of War: Ultimate Edition
Bejelentett érkező DX12-es patchek:
F1 2015, Just Cause 3, Rise of the Tomb Raider, Survarium, The Elder Scrolls Online: Tamriel Unlimited, ARK: Survival Evolved
Bejelentett érkező DX12-es játékok:
King of Wushu, Fable Legends, Hitman, Total War: Warhammer, Deus Ex: Mankind Divided, Forza Motorsport 6: Apex, Quantum BreakMegvásárolható Vulkan játékok:
The Talos Principle -
Abu85
HÁZIGAZDA
válasz
Habugi
#14696
üzenetére
Amilyen gyorsan változik a játékban a napszak, simán elképzelhető, hogy elegük van abból, hogy erre is ügyelni kell. Amúgy nem hibáztatom őket, de a benchmark pont azért jó ebben a játékban, mert fixen bele van írva, hogy milyen a dinamikus időjárás. Azt kell lefuttatni egymás mellett. Nem ad más eredményt, mint a játék nagy része.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
válasz
#85552128
#14685
üzenetére
Annak tekinti, csak nem teljesen Gaming Evolved játék, mert van szerződésük az Intellel és az NVIDIA-val is. Az Oxide korábban mondta, hogy ezekből az exkluzív marketingre felépített dolgokból ki akarnak maradni, így nem kérnek pénzt, vagy marketingtámogatást. Csupán szaktudásra van szükségek, ezért mindhárom cégnek kell a segítsége. Ilyet lehet, de ilyenkor az említett cégek nem tekintik key title-nek a játékot, mert mindhárman reklámozhatják. Az Oxide amúgy is eléggé próbál teljesen semleges lenni azzal, hogy mindenkinek odaadják a kódot, és mindenkinek a javaslatait várják.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#14664
üzenetére
Azt, hogy itt ezt tökéletesen lehet javítani. Akár azzal, hogy az AMD-t is soros feldolgozásra kényszerítik, de a fejlesztők szerint bőven meg tudják oldani azt is, hogy párhuzamosan fusson.
Az AotS-hez készült press driverbe belekerült csak az még nem publikus.
(#14665) daveoff: Arra számítottam, hogy rosszabbul fog futni. De csalódtam az Ubiban ismét. Ezúttal kellemesen.
Az AotS-t addig nem fogják verni, amíg át nem állnak REYES-féle leképezőre. Óriási különbség az, hogy a mai motorok 2-4-8 shadow casting fényforrást engedhetnek meg, míg a Nitrous ezeket százával lekezeli.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#14658
üzenetére
Nem. Ott az AMD és a többiek más kódot kaptak. Az AMD multi-engine-t, míg más single-engine-t. A multi-engine kódhoz kell egy újabb meghajtó, ha a GPU GCN2 vagy GCN3, illetve az aszinkron compute-tal futó SSAO szinkronizációja rossz, túl hamar futtatja, ezért ahhoz kell egy alkalmazásjavítás. Ez a single-engine kódot futtató Intel és NV hardvereket nem érinti, mert ott sorosra van kényszerítve a futószalagok feldolgozása (AMD-n futhat csak párhuzamosan).
-
#14657
Abu85
HÁZIGAZDA
Malibutomi
#14655
Abu85
HÁZIGAZDA
válasz
Malibutomi
#14655
üzenetére
GameWorks nélkül day1 így működik gyakorlatilag problémamentesen?
Véletlen? Aligha. 
-
-
Abu85
HÁZIGAZDA
A legfőbb oka inkább a multiadapter. Mindenképpen olyan leképező kell, ami jó mindegyik gyártó architektúrájára. Meg kellett keresni a közös "nyelvet". Ha nem lenne keverhető multiadapter simán elég lenne az eredeti ötlet az AMD-re és a még ma is engedélyezhető single engine kód az NV-re.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#14524
üzenetére
Én annyit tudok, hogy az NV jön még egy olyan meghajtóval, ami megpróbál javítani az async compute rontáson, és gyakorlatilag szintbe hozni, vagy 1-2%-os pluszt kihúzni a rendszerből az async off opcióhoz képest. Ez az ahol ők egy picit vesztenek, de az a modell, amit az AotS alkalmaz kedvez a GeForce-nak.
DirectFlip +1-2%-ot hozhat, ha beépítik, mert nem kell sávszélt pazarolni. De ennél többet nem fog hozni.
(#14525) Szaby59: Megcsúsztak egy picit, így szétszedik a frissítést. De márciusban megkapjátok ezt a press frissítést is, természetesen a ma még nem publikus driverekkel együtt.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#14520
üzenetére
A DirectFlip nincs beépítve, ezért viselkedik furcsán. Többek között az AMD-n ez hátráltatja némileg a sebességet, de egy későbbi verzióban beépítik. Ettől jöhet még egy kis gyorsulás neki. Az NV ezt már beépítette a meghajtóba, és le is profilozta az AotS-t rá. Az AMD még erre a zárt benchmarkra még nem adott ki teljesen optimalizált meghajtót.
Ezek a driverek egyébként márciusban publikusak lesznek, amit megjelenik a publikus frissítés a játékhoz.
-
Abu85
HÁZIGAZDA
Annyit hozzátennék, hogy amikor az MS arról beszélt, hogy a DX12-es Xbox One kód PC-re hordozható, akkor az igaz, de itt kifejezetten a DX12-n van a hangsúly. Ugyanakkor az Xbox One rendelkezik egy mono eléréssel, ami tulajdonképpen kizárja az Xbox One operációs rendszerének memóriamenedzsmentjét, illetve a WDDM 2.0-t is. Ilyen formában gyakorlatilag az alkalmazás ~5,2-5,4 GB (ezt nem tudom egészen pontosan mennyi) memóriaterület felett direkten rendelkezhet. Tehát allokálhat területeteket, ezek menedzselését az OS nélkül kezelheti, akár defragmentálhat is, ha elég jó a rendszer, illetve az IGP memóriaelérése is teljesen közvetlen.
(#14511) imi123: Szerintem az MS ezt a motort használja majd arra is. Valószínűleg ezért készítik el ezt az újra kiadást, hogy teszteljék az alapot.
-
Abu85
HÁZIGAZDA
válasz
imi123
#14509
üzenetére
A régi motorba ültetik be az UE4 leképezőjét, amit persze az MS alaposan módosított. Ez nem egy tipikus procedúra, mert ilyet nem szoktak csinálni. Jó okkal persze, ha az egyes motorok között évek vannak.
Az eredeti PC-s portból kiindulva így lesz Xbox One kód. De ez a kód a mono hozzáférést használja, vagyis tulajdonképpen az összeillesztésből eredő memóriamenedzselési problémákat el lehet fedni egy direkt erre kialakított rendszerrel, mert a konzolon a fejlesztő 100%-ban menedzselheti a memóriát. PC-n ebből az operációs rendszer és a WDDM2.0 sajnos nem zárható ki, így ott hátrányban lesz egy olyan program, amelyet alapjaiban nem erre a lényegében meghatározott modellre készítettek fel. -
#14508
Abu85
HÁZIGAZDA
huskydog17
#14502
Abu85
HÁZIGAZDA
válasz
huskydog17
#14502
üzenetére
Az várható volt, hogy a kétmagosok kikerülnek a képből pont azért, mert a low-level jobban párhuzamosítható, tehát az egy magra korlátozódó feldolgozási modell miatt nem húznak majd meg a fejlesztők olyan határokat, amelyeket korábban kényszerből meghúztak. Ilyen formában a négy mag lett a minimum igény, pont a skálázódás lehetősége miatt.
Attól, hogy a kernel driver eltűnik csak a skálázódás lehetősége nyílik meg. Ez is a négymagosoknak előny, és nem a kétmagosoknak.A többi már motorstruktúra kérdése. Nyilván nem kedvező, hogy sok éves a játék alapja, és azt kell átépíteni. Sokkal jobb lenne a nulláról dolgozni, de ez egy újra kiadás.
-
#14475
Abu85
HÁZIGAZDA
#Morcosmedve
#14474
Abu85
HÁZIGAZDA
válasz
#Morcosmedve
#14474
üzenetére
Egy explicit API (DX12) multi GPU-járól még a héten kapsz eredményt.
A VR multi GPU-járól is vannak fejlesztői beszámolók, de csak a LiquidVR-ről. Arra azt írta a Valve, hogy gyakorlatilag kétszerezi a sebességet és felére csökkenti a késleltetést. A VR SLI-ről nem beszélhet senki, ez meg van tiltva, tehát arról még nincsenek beszámolók.
-
#14472
Abu85
HÁZIGAZDA
#Morcosmedve
#14471
Abu85
HÁZIGAZDA
válasz
#Morcosmedve
#14471
üzenetére
Mivel a kernel driver eltűnt az új API-kban, így a dual GPU-s rendszerek driverrel már nem kezelhetők. Semmilyen drivert nem tudsz rájuk írni, mert menedzsment része a dolognak átkerült direkten az alkalmazásba.
A VR része is hasonló, bár ott azért annyi a különbség, hogy maga a menedzselés jóval egyszerűbb, mert tulajdonképpen csak azt akarod elérni, hogy a két szem számára a két GPU külön számolja a képet, ez a módszer pedig minden motorstruktúrával kompatibilis. Ehhez elég meghívni LiquidVR Affinity multi GPU funkcióját, vagy a GameWorksVR VR SLI-jét. Ezek kvázi egy napos munka alatt implementálhatók. Persze másképp működnek, de egy-egy nap alatt beépíthető mindkettő. -
Abu85
HÁZIGAZDA
válasz
#45185024
#14466
üzenetére
Az SC15-ön erről elég sok adat derült ki. A SuperMicro suttogta is, hogy a Pascal DP-ben a 4 TFLOPS-ot célozza meg. Meg persze suttogtak mást is, amiből írtam is egy hírt. [link]
Na most SP teljesítményről nem suttogott senki, tehát az ma még eléggé olyan információ, ami gyakorlatilag ismeretlen. Elképzelhető, hogy 12 TFLOPS lesz, de az is, hogy nem.Sehogy. VR-ben a dual Fiji idén legyőzhetetlen lesz. Szimplán a dual GPU-s felépítése miatt, mert az felezi a késleltetést. Egy single GPU-s rendszer VR-ben eleve hátrányban indul, még ha a teljesítménye ugyanakkora is.
A többi majd kiderül. Az NV annyit ígért csak, hogy a mostani preempcióról a VR miatt átállnak egy finomabb szemcsés modellre. -
Abu85
HÁZIGAZDA
válasz
Sir Ny
#14464
üzenetére
Technikai szinten több ilyen bit lesz. Nem mindegy, hogy milyen ruhában mész, csinálsz-e valamit, mennyire közel mész, váltottál-e ruhát, stb. Eléggé bonyolult rendszer lesz benne ebből a szempontból.
Csak egy példa. Vannak néhol tévés stábok, és ha megzavarod a forgatást azzal, hogy átmész a kamera előtt, akkor beszól az kameraman, hogy "köszi szépen", és ezután jóval könnyebben fog téged felismerni, mintha elmentél volna mögötte, vagy nem zavartad volna meg a forgatását. -
Abu85
HÁZIGAZDA
válasz
#85552128
#14458
üzenetére
Akkor elmondom a problémát. A Hitman esetében az a legnagyobb gond, hogy folyamatosan fejleszteni kellett egy új játékot. Az IO Interactive már régen akar egy homokozónak gúnyolt valamit csinálni, ami lehetővé tenné számukra, hogy gyorsan képesek legyenek bővíteni a sorozatot. Ez már évek óta a levegőben lóg, de sosem voltak ideálisak a körülmények a megvalósításhoz. A mostani Hitman lesz az alap, és erre felépíthetik az elkövetkező 4-5 évben a terveket. Az első évben a már bejelentett területeket.
Ezért lesz az új Hitman elsődlegesen PC-s játék, mert a PC az a terület, ahol a modók elterjedtek, márpedig ez a modell idővel a módokra fog épülni.
A full experience a bejelentett hat környezetet takarja, és a történet kvázi lezárását. A további frissítés már pénzbe fog kerülni. -
Abu85
HÁZIGAZDA
válasz
#85552128
#14455
üzenetére
A World of Warcraft is kap új motorverziókat időnként, mégsem early access a játék. Ugyanígy a Hitman is kapni fog. Azért lett így kialakítva a modell, hogy ez legyen egy teljes alap az IO Interactive számára, hogy legalább 4-5 évig ne kelljen új Hitman játékot fejleszteni, hanem ezt bővíteni lehet az elkövetkező években, gyakorlatilag folyamatosan. Technikailag nem MMO lesz, de hasonló a fejlesztési görbe, mint a World of Warcraft esetében. Évről-évre meg fog újulni, és nagy terv, hogy megadható legyen a játékosoknak, hogy készítsenek ők is saját tartalmakat. Gyakorlatilag kapsz egy homokozót, amibe időnként vehetsz homokot, vagy más homokját beleöntheted.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#14453
üzenetére
Nem. Az Early Access a Steamen belül egy speciális kategória. Azt a Valve sem igazán ellenőrzi, ha ebbe a kategóriába sorolják a fejlesztők az alkotásukat. Ez belsőleg az epizodikus kategóriába lesz sorolva, mert ami megjelenik az kész lesz, azaz nem early szintű, hibáktól hemzsegő kiadás, hanem teljesen játszható kész produktum.
Az epizodikus modell abból a szempontból kedvező az IO Interactive-nak, mert ez a Hitman alap bővíthető, tehát nem kell majd új játékot fejleszteni, hanem ha befejezték a tervezett pályákat, akkor egyszerűen újabb DLC-kkel vihetik tovább a sztorit, és idővel majd a játékosok is kaphatnak eszközöket arra, hogy saját pályákat készítsenek. Ezzel a Hitman gyakorlatilag egy bővíthető játékká válik. -
Abu85
HÁZIGAZDA
válasz
TTomax
#14446
üzenetére
A Glacier 2 nem használ konzolon alacsony szintű elérést. Elképzelhető, hogy visszaportolják oda is, de a startra biztosan nem. Inkább valamelyik év közepe felé érkező csomagba.
A Deus Ex nem a Glacier 2-re épül, hanem annak egy átalakított verziójára, aminek a neve Dawn.
Tipikus overhead para, ha az egyik irányba nézel, akkor jó a sebesség, míg ha a másikba, akkor visszaesik. Ugyanebben a gonddal küzd a Rise of the Tomb Raider a soviet installation és a geothermal valley pályákon. Ezt a DX11 limitjei okozzák.
A Hitman esetében az embertömeg a probléma és a kapcsolódó AI. Ez a Glacier verzió több munkát végez, mert az NPC-k nem csak állnak és néznek, hanem reagálnak rád, megjegyzik az arcod, stb. Ez bonyolultabb AI-t igényel, mint az Absolution esetében.
-
#14442
Abu85
HÁZIGAZDA
Malibutomi
#14440
Abu85
HÁZIGAZDA
válasz
Malibutomi
#14440
üzenetére
A LABS vezetője írta már, hogy még sok effekt van fejlesztés alatt, tehát ezek kimaradtak a bétából. A teljesítmény nyilván változhat, de annyira a DX12-höz alakították ki a motort, hogy a tömegjeleneteknél DX11-ben sosem lesz hatékony. Ez a Glacier verzió akár 300 karaktert is képes mozgatni úgy, hogy egy képen vannak. Erre szükség van, mert az elvegyülés egy alapvető játékelem lesz.
Instabilan lesznek eladva sajnos, mert senki sem teszteli ki a tuningot rajtuk.![;]](http://cdn.rios.hu/dl/s/v1.gif)
De egyébként ez semmiképpen sem a DX12 hibája. Annyira régi kódot nem lehet már jól felkészíteni egy új API-ra. Ez a remake-ek átka. Már csak azért is egyedi a probléma, mert például az Oxide egy erre írt motorral sokkal többet kihoz a DX12-ből, és akkor még a héten lesz Hitman, szintén DX12-höz tervezett motorral. Ha abban is működik az API, akkor nem azzal van a gond, hanem a GoW-val.
Véletlen? Aligha. 
Holnap lesz belőle hír, mert elég vaskos dokumentum.
Ú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.
- GYÖNYÖRŰ iPhone 11 Pro 64GB Silver -1 ÉV GARANCIA - Kártyafüggetlen, MS3565
- Keresek Galaxy S21/S21+/S21 Ultra/S21 FE
- ÁRGARANCIA! Épített KomPhone Ultra 7 265KF 32/64GB RAM RX 9070 XT 16GB GAMER PC termékbeszámítással
- 209 - Lenovo Yoga Pro 7 (14APH8) - AMD Ryzen 7 7840HS, no GPU
- GYÖNYÖRŰ iPhone 13 128GB Red-1 ÉV GARANCIA - Kártyafüggetlen, MS4373, 100% Akkumulátor
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest