Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz
Venyera7
#25796
üzenetére
A shader model 6-os szabványos megoldást kérdezed, vagy az AMD-féle zárt opciót? Előbbi valószínű, hogy lesz, illetve a SPIR-V is ki fog egészülni idén egyre több szabványos beépített függvénnyel. Nyilván hosszabb távon ezeket érdemes használni, tehát amint megérkeznek, áttérnek rá a fejlesztők. Már csak a szabványosság miatt is.
Az AMD-féle megoldás addig általános lesz, hiszen az Xbox One-hoz meg van írva a shader. Ahhoz minimális módosítás kell, hogy PC-n is működjön a GCN-en. Az érkező játékok közül a Resident Evil 7: Biohazard, a Sniper Elite 4, Styx: Shards of Darkness és a Mass Effect Andromeda használja. Utóbbi ugyanazt fogja bevetni belőle, amit a Battlefield 1, míg az előbbi három esetében kérdéses, hogy milyen függvényekhez nyúlnak. -
Abu85
HÁZIGAZDA
Csak nem érdemes a játékokra levetíteni őket, mert nagyon másképp működnek a modern motorok.
Az Umbra csak egy occlusion culling megoldás. Ez, illetve a view-frustum culling még mindig a CPU dolga, bár vannak kísérletek arra, hogy áttegyük őket a GPU-ra. Az occlusion cullingra van az Intelnek egy GPU-s megoldása, de az egyelőre TIER_3-as conservative rastert követel, tehát csak a Gen9 hardvereken futna. Mindenesetre az ígéretes. Ugyanakkor közel sem vágnak ki ezek minden háromszöget, emiatt további technikákat kell bevetni. Ezek a technikák a GPU-driven pipeline motorokkal kifejezetten hatékonyak, ezért építi be őket egy csomó stúdió. A technikák gyűjtőneve a CTF. Persze van aki ezt másképp hívja, az AMD például GeometryFX-nek. Az egész arról szól, hogy radikálisan nőjön a raszterizáció hatásfoka sok háromszög mellett.
-
Abu85
HÁZIGAZDA
Ez megközelítőleg sem ilyen egyszerű. A szintetikus programok azért nagyon megtévesztők, mert egy heterogén processzor (ugyanis a GPU ilyen) egy apró elemét terheli a limitig. Egy játék azonban teljesen más, számos elemet terhel egymás mellett, és egyrészt ez máshova helyezi a belső limiteket, másrészt annyira eltérő egy mai játék működése egy szintetikus programtól, hogy teljesen mindegy mit mutatnak ezek.
Annak is oka van, hogy a Hitman és főleg a Deus Ex Mankind Divided miért dolgozik sok háromszöggel, jelenetszinten akár 220 millióval. A Square Enix használja az új Glacier 2-ben és az ebből kifejlesztett Dawn motorban egy úgynevezett CTF modult. Ez a compute-based triangle filtering, vagyis egy olyan kivágási rendszer, amely miatt igen szabadon lehet bánni a háromszögek adagolásával, mivel a hardveren futni fog végül egy olyan program, amely a nem látható háromszögek nagy részét úgyis kivágja, és teszi ezt a korábbi opcióknál sokkal-sokkal hatékonyabban. Ezek persze jórészt befutnak a GPU-ba, de a feldolgozás különböző szakaszain jól meg lesz ritkítva a pipeline tőlük. Ezért nagyon fontos megkülönböztetni a szintetikus tesztet a játéktól, mert a szintetikus teszt egy ilyen modult úgy sem fog alkalmazni, hiszen pont a teszt lényegét vágná ki, mivel ettől jól futna a program a hardvereken, és nem ütköznének bele a vizsgálni kívánt limitbe. Egy sok háromszöggel dolgozó játék viszont ilyen CTF modul nélkül nem fog elkészülni, mert nem futna jól a hardvereken. Ergo teljesen mindegy, hogy a GeForce klasszikus kivágás nélküli, vagy szimpla CPU-s feldolgozás mellett jól viseli a terhelést, ha a sok háromszöggel dolgozó játékokban GPU-s kivágásos feldolgozással fog találkozni, és abban már a Radeon a gyorsabb. Arról nem is beszélve, hogy a kivágás lépcsői között az egyes hardverek más kódot kaphatnak. A Hitman és a Deus Ex Mankind Divided a CTF modult más kóddal futtatja Radeonon és más kóddal az összes többi GPU-n. Például a GCN-re a fejlesztők használnak ballot/mbcnt/read lane-t, míg a többi hardveren ezeket igen drága algoritmusok helyettesítik a direkt utasítások hiányában.
Amiről pedig te írsz, hogy "compute vs. poligon"... Ezek ma már nagyon is egybefüggő dolgok egy modern motorban. A CTF modulok ugyanis per háromszög szintű shaderek, vagyis minél több háromszög lesz egy játékban annál nagyobb előnye lesz az AMD-nek benne, hiszen a CTF minden még élő háromszögre lefuttatja a különböző fázisait. Effektíve a háromszögek számának növelése egy modern játékban leginkább a compute teljesítményt szívja le manapság. Így működik egyébként a legújabb Frostbite is, csak ott nem lőtték még el a terhelést 200+ millió háromszög per jelenetig, de idővel ők is megteszik.
-
#25673
Abu85
HÁZIGAZDA
SpongyaBob
#25671
Abu85
HÁZIGAZDA
válasz
SpongyaBob
#25671
üzenetére
Ebbe ne menjünk bele. Elég ha a moderátorok kezelik az újrareges kérdést, amellett persze, hogy nyilván ami feltűnő az feltűnő, és más sem hülye itt. Viszont mindenki kaphat még esélyt. Ha pedig nem él vele, akkor ugyanaz lesz a vége, mint először, vagy esetenként az azelőtti regisztrációval.
-
Abu85
HÁZIGAZDA
Aszinkron compute a játékokban: [link]
Az aszinkron compute előnye változó. +7-10%-ot hoz átlagosan a GCN2/3/4-en. Valahol többet is, de a feldolgozás formájától függ. GCN1-en +2-5%-ot hoz, ha aktív. Maxwellv2-n szinte semmit. Pascalon +2-5%-ot.
Az Unreal Engine 4.14-től aktiválható az UE4 játékokra is az aszinkron compute, de csak GCN-re aktiválja a motor.
-
Abu85
HÁZIGAZDA
válasz
Puma K
#25638
üzenetére
A pályaméretnek nincs különösebb jelentősége az erőforrás-igényre nézve. Manapság a legtöbb esetben nem is a motor korlátozza azt, hanem a tartalomtervezésbe rakott erőforrás.
A Hitman erőforrás-igénye leginkább azért nagyobb a GTA5-nél, mert egy jelenet nagyjából tízszer komplexebb. Jóval több háromszögből áll az egységnyi területre levetített térkép, jóval több a szimuláció rajta, jóval komplexebb már maga a leképező. Az így megugró számításigény pedig nyilván növeli a gépigényt. Speciálisan kiemelve az új Hitman az élmezőnyben van a poligonszám tekintetében, egyedül a Deus Ex Mankind Divided dolgozik több poligonnal a jelenetekre levetítve. Tehát a Hitman esetében igazából a háromszög-feldolgozás gyilkolja a GPU-kat, ideértve minden háromszögekkel kapcsolatos munkát.
-
Abu85
HÁZIGAZDA
válasz
#02119936
#25487
üzenetére
A gyártók árengedményt adnak az exkluzivitásért. Az AMD és az NV is így csinálja. Ezért nem éri meg a már kialakított exkluzív kapcsolatokat feladni. Például emiatt váltott az XFX az NV-ről AMD-re, és nem csinálták úgy, hogy mindkettő céget kiszolgálják párhuzamosan.
-
#25486
Abu85
HÁZIGAZDA
#Morcosmedve
#25484
Abu85
HÁZIGAZDA
válasz
#Morcosmedve
#25484
üzenetére
Nem olyan véletlen az. Az AMD megmutatta a nem partner alaplapgyártóknak is, hogy mit tud a Ryzen. Azóta mindenki érdeklődik. Az EVGA is köztük van. De hogy ebből a médiában miképp lett Radeon+EVGA házasság...
-
#25466
Abu85
HÁZIGAZDA
->Raizen<-
#25465
Abu85
HÁZIGAZDA
válasz
->Raizen<-
#25465
üzenetére
A shader model 6.0, ezen belül is az intrinsics függvények eleve nem a lassulásról szól. Attól, hogy most nincsenek szabványban ilyen lehetőségek PC-n átmentik a konzolos kódokat, csak a nyilván PC-n nem egy utasítás lesz mondjuk egy préselés, hanem írni kell rá egy algoritmust. Az intrinsics függvények azt akarják, hogy legyen PC-n is egy-két utasítás. Nyilván amelyik hardverben nincs rá hardveres támogatás, az továbbra is megoldja csak emulációval, ami nagyjából megfelel a mostani formának.
[link] - ebben a tesztben látható már, hogy mit ér az intrinsics, ha jól használják. A Radeonokon rajta van, míg a GeForce-okon nincs, kvázi emulálnak. Ergo semmi nem fog belassulni, egyszerűen csak azok a hardverek húznak el, amelyeknek nem kell "emulálni". -
#25463
Abu85
HÁZIGAZDA
->Raizen<-
#25459
Abu85
HÁZIGAZDA
válasz
->Raizen<-
#25459
üzenetére
Mindig ezt mondtam. A shader model 6.0 minimum igénye a feature_level_12_0. Ez nem változott. Tehát AMD GCN2/3/4, NVIDIA Maxwellv2/Pascal, Intel Gen9/en9.5.
Az intrinsics függvények esetében igazából mindegyik függvény megoldható ezeket a hardvereken, csak az egyes függvények az egyes hardverekre nem mapelhetők rá hatékonyan. Ez azért van, mert a Microsoft az egész rendszert a GCN-re alakította ki. Annyit tudni jelenleg, hogy a mostani felhozatalból a GCN3/4 támogat minden függvényt hardveresen.
Igazából a shader model 6.0 intrinsics függvényei az AMD-t eleve kevésbé érintik, mert ők már kínálnak AGS4/5-öt, amelyekben a függvények többsége megtalálható. Ezt már ki is használja pár játék (Doom, új Deus Ex, új Hitman, Battlefield 1). A Microsoft azért hozza a szabványos rendszert, hogy a fejlesztők ne a csak az AMD-nek segítő AGS-en keresztül műtsék be ezeket a játékaikba, hanem szabványból, így ha majd az Intel és az NV is előáll a függvények hardveres támogatásával, akkor ők is nyerhetnek belőle. -
Abu85
HÁZIGAZDA
válasz
Ren Hoek
#25213
üzenetére
A Deus Ex: MD-benben +10-15%-ot jelent. A méréseket pedig láthatod: [link] - egyébként, ha levonod a 10-15%-ot, akkor nagyjából a normál DX12-es helyükre kerülnek a Radeonok.
A BF1-ben kevésbé van használva az AGS4, így ott inkább 6-7% körül nyernek. A többi játékban (Doom, Hitman) is finomabb a felhasználási forma.
-
Abu85
HÁZIGAZDA
válasz
Ren Hoek
#25201
üzenetére
Most is kihasználják a fejlesztők az AGS4-et, sőt van már AGS5 is. Tehát a Volta érkezése itt lényegtelen. A funkció elérhetősége a lényeges. A szabvány csupán annyit segít, hogy ha arra van leportolva a funkció, akkor amint megérkezik a Volta az is tudja futtatni a gyorsabb kódutat. Nyilván ez egy lényeges szempont a fejlesztő oldalán. Az AGS itt csak egy menekülőút addig, amíg nincs szabványos megoldás.
(#25207) Szaby59: Mert konzolba pötyögni tilos. Játszani lehet, ott van a gép mellett egy ember, aki figyel, hogy ne csinálj olyat, amit nem szabad.
-
Abu85
HÁZIGAZDA
válasz
imi123
#25197
üzenetére
A Star Wars Battlefront Rogue One: Scarif DLC miatt. Az EA-nek most van egy szerződése, hogy az AMD az új hardvereit egy Star Wars játékkal reklámozza. Ez azért lényeges, mert az EA az összes érkező Star Wars játékot AMD-re optimalizálja, és AMD-s funkciókat építenek beléjük. A BF1-nek a Polarishez van reklámszerződése.
-
Abu85
HÁZIGAZDA
válasz
cyberkind
#25193
üzenetére
A Volta az mindig 2017-re volt tervezve GPGPU szinten és 2017-2018-ra VGA szinten.
Eddig is konvertálással készültek a portok. A gond eleve az, hogy a konvertálás által a konzolos funkciók nem érhetők el, emiatt jóval lassabb eljárással kell helyettesíteni azokat. A shader model 6.0 azért jön, hogy ami a konzolon egy utasítás az a PC-n is egy utasítás legyen, és erre legyen a nyelvben egy függvény. Az egyetlen dolga innentől az iparnak, hogy a függvényekhez direkt utasításokat rendeljen a hardver oldalán. Persze a függvény emulálható is, és nagyon sok aktuális hardver így futtatja majd a shader model 6.0 újításait. Ma egyedül a GCN3/4 architektúráknak van minden függvényhez direkt utasításuk, de a Vega, Volta, stb. már felkészül ezekre.
-
Abu85
HÁZIGAZDA
válasz
cyberkind
#25189
üzenetére
A Voltát nem tolták el. Eleve a Vega a Volta ellen készül, és nem a Pascal ellen. Nem véletlen a Poor Volta felirat a reklámban. A Pascal közel sem rendelkezik olyan képességekkel, hogy támogatni tudja azt, amit a Vega támogat. Az a Volta lesz, ami hasonló tudásszintet biztosít az új DirectX és Vulkan verzió mellé.
A fő cél most mindenkinek az, hogy hardveresen tudják támogatni az összes shader model 6.0-s függvényt. Ezt ma csak a GCN3/4 tudja megcsinálni, de a Vega és a Volta is tudni fogja, sőt lesz ugye programozható blending, ami ugye a következő áttörés. Kicsit visszatér majd a régi shader modeles szívás, hogy ha nincs meg a legnagyobb shader model szinted, akkor nem lesz minden effekt aktív. De ezen túl kell esni sajnos.
-
#25155
Abu85
HÁZIGAZDA
FollowTheORI
#25152
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#25152
üzenetére
Azért FreeSync a neve, mert bele kell tervezni a FreeSync-et is a monitorba, hogy egyáltalán hitelesítsék FreeSync 2-re. Emiatt minden FreeSync 2-es HDR kijelző egyben sima FreeSync megoldás is. Ez részben üzleti döntés, mert a FreeSync annyira ismert lett a Samsung és az LG reklámok miatt, hogy tulajdonképpen szinte elkerülhetetlen már, hogy a konkurensek amikor rá/áttérnek a szabvány támogatására, ne fizessenek licencet az AMD-nek a névhasználatért. Másrészt nagyon kedvező, ha az összes FreeSync 2-es HDR kijelzőből kizárják a többi VRR eljárást. A monitorgyártók gyakorlata itt kedvező az AMD-nek. Ők minden buzzwordre ugranak, hogy a HDR kijelzőjük ne HDR-ként legyen reklámozva, hanem FreeSync 2-ként. Ez nekik egy extra technológia(tm) a dobozra és a marketinganyagba a simán HDR-rel reklámozó konkurensekhez képest.
-
Abu85
HÁZIGAZDA
válasz
Puma K
#25103
üzenetére
A Valve alapvetően anonim módon bánik az adataiddal, amelyeket felhasználnak markegingre, illetve megosztanak bizonyos partnereikkel. A Steam HWSurvey az egyetlen olyan pont, ahol az adataid mellé valós felhasználót rendelnek, és emiatt is kérdez rá, hogy részt akarsz-e venni a felmérésben, mert onnantól kezdve már nem leszel anonim. Én pedig nem nagyon szeretném, hogy az immáron felhasználóhoz kötött adataimmal harmadik fél dolgozzon. Ez egyszerűen túlmegy azon a ponton, amit elfogadok. Tanultam, hogy mennyire vissza lehet élni ezekkel. Önmagában az nem zavar, hogy a Valve tudja, de hogy egy harmadik fél, az nem fér bele.
-
Abu85
HÁZIGAZDA
válasz
Zeratul
#25086
üzenetére
Az a kisebb probléma. Van még kettő nagyobb:
Egyrészt az adatokat nem felhasználószinten, hanem gépszinten összegzi, vagyis ha cseréltél gépet vagy valamit a gépben, akkor egy évig megőrzi az előző adatokat is, és csak akkor törli, ha nem jelentkeztél be egy évig a régi konfiggal. Ez azért lényeges, mert ha mondjuk eladtad a VGA-d a használt piacon egy másik Steam felhasználónak, aki bejelentkezik és elküldi az adatokat, akkor az adott VGA kétszer van benne a kimutatásban legalább egy évig.
Másrészt csak az első grafikus vezérlőig érzékeli a kimutatást, tehát ha van egy aktív IGP-d, akkor azzal kerülsz be. -
Abu85
HÁZIGAZDA
válasz
FLATRONW
#25014
üzenetére
Mint írtam a számítás mennyisége megegyezik. Ugyanaz lenne az eredmény, ha megegyezne a textúrák részletessége. Ezekkel a modern stream rendszerekkel nem lehet mit kezdeni. Így működnek és kész. Még mindig jobb ez, mintha azt mondaná a játék, hogy közepes fölé nem helyezheted a textúrarészletességet.
Nem tudom a VRAM mennyiségét. Tőle kell megkérdezni.
(#25015) V!ck: Persze. A 2 GB ahhoz kell, hogy elinduljon a játék, és fusson valamennyire. De hogy élvezni is fogod, az nem biztos. 4 GB-tól már jó. Egyébként nem tipikus VRAM-para ez, hanem folyamatosan kikódolást kér a rendszer, és ez elveszi az erőforrást a többi grafikai számítástól.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#25012
üzenetére
Azzal nincs gond, ha a textúra részletessége nem egyezik meg a tesztek között. Ez csak a VRAM-ra vonatkozóan terhelés, valójában az elvégzendő számítás ultra low és ultra high textúrák mellett is pontosan ugyanannyi.
Ma már nagyon sok játékban a motor "intelligens" streaming konstrukció. GoW 4, Dishonored 2, Shadow Warrior 2, Titanfall 2, Just Cause 3. Ezeknél hiába állítod be a textúrarészletességet a motor azt bármikor felülbírálhatja, ha nincs elég VRAM. És nem fog megkérdezni róla. -
Abu85
HÁZIGAZDA
Félig. Abban a videóban az látszik, hogy a kikódolás lassú GeForce-on. De ez például attól is lehet, hogy a teljes részletességre történik a kikódolás, ami nyilván lassabban van meg, mint az alacsonyabb részletességnél. Természetesen amellett, hogy a motor igyekszik jól dönteni nem mindig dönt jól. Nagyon komplex a virtuális textúrázás az ID tech 6-ban, és ez okozhat kellemetlenségeket.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#25005
üzenetére
Esetleg értelmezzétek is, hogy mi van oda írva. A grafikát a Doom alatt nem ti állítjátok be. A motor bármikor felülbírálhatja a textúrarészletességet. Ha mindig maximális részletességű textúrabetöltést akartok Vulkan alatt, akkor AMD-n 8 GB, míg NV-n 12 GB VRAM kell. Ha ez nincs meg, akkor a mozaikok egy része nem lesz maximális minőségűre kikódolva, illetve lassan töltődhetnek be.
A jövőben ez teljesen általános lesz. Egyszerűen a textúrarészletesség annyit jelent, hogy ha van elég memória és elég számítási kapacitás a virtuális textúrarészletességet kikódolni, akkor betöltheti a maximum részletességet. Ha nincs, hát akkor nem tölti be. Nem fogja megkérdezni futtatás közben, hogy neked jó lesz-e a fal textúrája egy szinttel alacsonyabb minőséggel. Észre sem fogod venni a különbséget.
Az NV-n sincs igazából semmi gond. Nem hardveres hibáról van szó, hanem egy szoftveres problémáról. Ahhoz, hogy az NV-n is jobb legyen az allokáció hatásfoka szükség van az NV_dedicated_allocation kiterjesztés használatára. Ezt már használja az ID tech 6, csak a Doom Vulkan leképezőjébe nem portolták vissza, és valószínűleg nem is fogják már. Elsődlegesen nem az extra memóriahasználat az aktuális verzióval a gond, hanem az, hogy NV-n 3 GB a minimum VRAM igény, míg AMD-n elég 2 GB is. Valójában nem használ több hasznos adatot a Doom NV-n, csak valamiért sokkal töredezettebb lesz a memória a futtatás során (és ez nem csak kevés VRAM-nál számít, hanem soknál is, tehát a töredezettségből eredő hátrány megmarad 8-10-12 GB-on is). Ezt a töredezettséget lehet kezelni az NV_dedicated_allocation kiterjesztéssel. Elképzelhető, sőt, kifejezetten valószínű, hogy ezen lehetne mit reszelni a Vulkan driver oldalán is, de ahhoz nagyon mélyre kellene menni, így az NV jobbnak látta ezt a kiterjesztést, mivel ha dolgoznak is rajta, az hónapokat fog igénybe venni, addig pedig 10 Vulkan játék is jöhet ugyanazzal a problémával, ami a Doomban felütötte a fejét. Szóval a kiterjesztés inkább egy gyorsfix.
Persze az egészben nagy szerepet játszik az is, hogy az ID-nek ez az első Vulkan projektje, tehát nem veti még szét őket a tapasztalat sem. De mondjuk az NV-t sem az explicit UMD-k tekintetében, tehát az egész még nagyon tanulási szakaszban van. Az AMD-nél sem dolgoznak okosabb programozók, csak az ottani emberek két évvel korábban tesztelhették ezt az irányt, mint az NV programozói. Ez azért számít. Pusztán az időelőny miatt sokkal jobban átlátják ma, hogy milyen rutinok működnek, és melyek tűnnek jó iránynak, de valójában zsákutcák. Utóbbit is csak azért tudják eldönteni, mert két év alatt kipróbálhattak pár zsákutcát, míg mondjuk az NV élesben fut bele ezekbe, amiből nem lehet gyorsan kijönni és jöhetnek a gyorsfixek kiterjesztésekkel. Ha mondjuk az AMD-nek nem lett volna Mantle, akkor most ők is belefutnának ezekbe a problémákba, mert hiányozna a tapasztalat. Talán ugyanolyan gyorsfixekkel dolgoznának ők is a problémás UMD réteg javításáig. -
Abu85
HÁZIGAZDA
válasz
TTomax
#24993
üzenetére
Ez sokkal bonyolultabb. A Vulkannak vannak ebben a játékban igen specifikus követelményei is.
Például AMD-n a Doom olyan memóriaallokációt használ, hogy elég legyen 2 GB VRAM is. Tehát AMD-n a VRAM igény Vulkan API-ra minimum 2 GB.
Ezzel szemben az NV-re már nem elég 2 GB VRAM, mert eltérő az allokációs stratégia. 2 GB-tal egy GeForce-on visszautasítja a Doom, hogy elinduljon. Függetlenül attól, hogy AMD-nél elég a 2 GB is. NV-nél már 3 GB kell minimum.
Az ajánlott az AMD-nél 4 GB, míg az NV-nél 6 GB. De ha mindent be akarsz kapcsolni, tehát nem akarsz automatikus mesterséges korlátozást, akkor Vulkan alatt az AMD-nél 8 GB kell, míg az NV-nél 12 GB.
Ezen lehetne egyébként még optimalizálni, mert aki csinálta a Vulkan kódot gyakorlatilag elismerte, hogy az NV-re nem nagyon tudott optimalizálni, tehát le tudná szorítani az NV-nek a VRAM igényét az AMD szintjére, csak erre a játékra már nem költenek, ergo marad így. De az ID tech 6 új verziójára épülő játékokban nyilván az NV-nek a memóriaproblémája is meg lesz oldva, lévén ez teljes egészében egy ID tech 6-on belül keletkező gond. Az NVIDIA egyébként erre a problémára hozott egy NV_dedicated_allocation Vulkan kiterjesztést, amivel jobban lehet bánni a VRAM allokációval, így a GeForce-okhoz is jobban lehet igazodni. Ezt majd a Vulkanra fejlesztő rétegnek érdemes lesz használni, mert a GeForce a full szabványos allokációval nincs mindig kibékülve, túl sokat szemetel valamiért.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#24990
üzenetére
Mint írtam nem a VRAM mennyisége az egyetlen paraméter. A textúra mozaikok kikódolása GPU compute, és ebben a GCN-ek háromszor is hatékonyabbak. Effektíve tehát egy textúra mozaikot egységnyi FLOPS-ból háromszor gyorsabban számol a GCN. Emiatt van az, hogy a Radeonon szinte nincs is pop-up, míg a GeForce-on meg van. Egyszerűen mindig kész van időre a számítás. Persze ez Vulkan alatt van így, OpenGL-ben más problémák miatt jóval limitáltabb az egész működés, például nincs aszinkron compute, ami ennél a motornál nagyon számít. Elvégre aszinkron compute mellett a mozaikok kikódolása párhuzamosan történhet, míg aszinkron compute nélkül ez csak sorosan lehetséges.
Device ID alapján paraméterez a játék. A Vendor ID ide nem elég.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#24985
üzenetére
Jó oka van arra, hogy korlátozza a grafikát. A virtuális textúrázáshoz ugyanis ki kell kódolni a mozaikokat, amely időt vesz igénybe a grafikus vezérlőn. Ezért biztosítani kell hogy kellő mozaik legyen használat alatt, amíg a kikódolás megtörténik. Ha ezt nem teszik meg, akkor olyan lesz az egész, mint a Rage, sok pop-up hülyeséggel.
A grafikai beállítások korlátozása egyébként nem csak pont a VRAM függvénye, hanem részben a számítási teljesítményé is, illetve a kikódolás számításának hatékonyságáé. [link] - itt erről beszélnek, hogy mennyivel másképp tölt be a beállított részletességre a virtuális textúra az egyes kártyákon. -
Abu85
HÁZIGAZDA
válasz
TTomax
#24979
üzenetére
Igazából nem az OpenGL-lel van a gond, hanem maga a motor nem barátja az AFR-nek. Virtuális textúrázás mellett nem is csodálom.
[link] - nézd meg a gyorsulást.
A Radeon Pro Duo egy VR kártya. Az elején is az volt. Ez a professzionális piacra megy a tartalomkészítőknek.
Az OpenGL-t az ID nagyon jól használja. Azért ez az API került bele a Doomba, mert a DX11-es portjuk lassabb volt. Mert van DX11-es portja az ID tech 6-nak. De a Vulkan volt a fő irány, mert az mindkettőnél gyorsabb. -
Abu85
HÁZIGAZDA
válasz
TTomax
#24976
üzenetére
Sokszor több GPU-val sincs annyi fps-ed OpenGL-ben, mint egy GPU-val Vulkan alatt. És akkor ne feledjük az OpenGL-ben az AFR kötelezően tripla pufferes késleltetését, ami szembe van állítva a Doom Vulkan leképező speciális front bufferes aszinkron compute modelljével. Nincs különösebb indok a Vulkan leképező használata ellen. Főleg akkor, ha alacsony késleltetés kell, ebben meg nem közelíti az OpenGL. Még egy GPU-s back buffer modell mellett sem.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#24964
üzenetére
Tök egyszerű a helyzet. Kétféle DX12 alkalmazás van. Ahol az MS ajánlásait vették figyelembe és ahol az NV-ét. A RotTR-nél az NV-ét, és emiatt ott lassul az egész DX12 is a DX11-hez képest. Minden más játékban az MS ajánlásai domináltak, amitől az NV bekap egy 7-9%-os deficitet.
Ez az egész egy többszintű probléma. Egyrészt az NV-nek a DX12 meghajtója a bekötési modell miatt nagyobb többletterhelést generál, míg az AMD-nek a bekötés ingyenes. Másrészt ha nem kötvetlenül a root signature-be van kötve egy buffer view, akkor az NV-nél csökken a pixel shader teljesítmény. Harmadrészt pedig az NV-nek a hardverébe vannak különböző fast path-ok építve, hogy bizonyos sűrűn használt funkciókkal gyors legyen. Ezek azonban DX12/Vulkan alatt nem használhatók, tehát az általános path-on keresztül működik az egész, ami lassú. Ezek kombinált hatása okozza azt, hogy a GCN DX12/Vulkan alatt elhúz a DX12/Vulkan játékok 99%-ában. Az NV hardvere túl specifikusan van tervezve, hogy általános környezetben is gyors legyen. Ezzel szemben az AMD hardvere arra van tervezve, hogy általános környezetben működjön, és nincsenek is benne specifikus fast path-ok. Lényegében az NV tervezett a hardvereibe egy rakás speciális funkciót a DX11-hez, amelyektől a DX12 és a Vulkan elvágja őket.
Ez egyébként nem pont az API hibája, hanem sokkal inkább a Microsoft és a Khronos szabta olyanra a specifikációkat, hogy a hardvergyártók trükközését kivágják. Nem az NV-nek akartak persze ezzel rosszat, hanem csak közelebb akarták vinni egymáshoz az eltérő cégek által fejlesztett hardverek működését. Ilyen formában az NV kénytelen az AMD-nek az általánosan kigyúrt hardveres modelljét követni, mert hiába építenek fast path-ot a hardverekbe, azokat nem tudják majd használni. -
Abu85
HÁZIGAZDA
A flipqueue/pre-rendered frame tök egyszerűen kategorizálható.
Az NVIDIA GeForce driverben alapértelmezetten 3, de opcionálisan 1-4 között állítható.
A régi AMD Catalyst driverekben fixen 3.
Az AMD Radeon Software driverekben fixen 1. Kivéve a ReLive csomagok új Chill módját. Ha a Chill aktív, akkor ez az érték 0 a scene pacing miatt.
Ezek a beállítások addig élnek, amíg egy DirectX 11-es alkalmazás másképp nem rendelkezik. Ugyanis az alkalmazás oldalán lehet kérni azt, hogy a meghajtóba épített beállítást ne vegye figyelembe. Például a BF4 ilyen. Az új Frostbite motor már jobb, így a BF1-ben a meghajtó beállítása érvényesül. Tehát még csak motorhoz sem nagyon lehet ezt kötni. Maximum motorverzióhoz.
DirectX 12-ben a flip queue méret kiválasztása csak és kizárólag az alkalmazás feladata. Egy meghajtó nem képes felülírni. Az alkalmazás fejlesztője dönti el, hogy mi legyen a beállítás, és akár architektúránként eltérőt alkalmazhat.
Konzolokon a flip queue méret univerzálisra van szabva. A fix hardver miatt mindig 1. Ehhez kell írni a programokat.
Általánosan érdemes mindig azt az értéket használni, amit a driver alapértelmezetten felkínál, mert ehhez építették be a rendszerprogramozók az alkalmazásspecifikus optimalizálást.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#24873
üzenetére
Nem igaz, hogy pontosan ugyanaz. A PresentMon egy single-engine mérőprogram, míg az OCAT multi-engine. Ez óriási különbség. Az engine-eken ettől mérhet ugyanúgy, még akár a present detektálás módja is lehet ugyanaz, vagy akár felhasználhat a PresentMon kódjából, de a lényege az OCAT-nak az, hogy nem csak egy, hanem az összes queue-t figyeli. A PresentMon addig volt jó, amíg a program single-engine módban futott, de amint multi-engine volt az alkalmazás rögtön rossz adatokat mért. Ha ez nem lenne probléma, akkor az AMD nem törődött volna egy ilyen program kidolgozásával, hiszen a PresentMon ellátta volna a feladatát. De sajnos közel sem volt teljes a működése. Erre jött az OCAT, mint az első multi-engine mérőprogram DX12/Vulkan API-ra.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#24867
üzenetére
[link] - itt ki van fejtve, hogy ez már egy multi-engine mérőprogram. Ha visszaolvasol nem a külső méréssel volt a gond, hanem azzal, hogy single-engine-ek voltak a mérők.
Ez se tökéletes egyébként, mert külön profilja van például a Deus Ex és a Doom felismerésére. Tehát nem általános megoldás, de nyilván annyira eltérőek a játékok, hogy általános programot senki sem tud majd írni. Viszont játékspecifikusan legalább ez kiegészíthető, tehát mindenre lehet benne reagálni.(#24869) TTomax: Csak elmagyarázom, hogy tök felesleges bizonyos dolgokat várni. Az Intel nem fog azért fizetni, hogy egy generációnyi versenyhátrányba kerüljenek.
(#24872) Szaby59: Az OCAT eltérően működik, mint a PresentMon. Elsődlegesen azért, mert a PresentMon egy single-engine mérőprogram, míg az OCAT multi-engine. Ez különbözteti meg a két rendszert, de nagyon. A PresentMonnál is a multi-engine hiányzott a pontos méréshez, mert single-engine erejéig az is jól mért, de hát a DX12 és a Vulkan multi-engine API.
Azt állítottam, hogy single-engine mérőprogrammal multi-engine API-ban nem lehet pontosan mérni. De ezért lett az OCAT multi-engine mérőprogram, mert ez hiányzott a piacnak.Az AMD mondta el, hogy bizonyos játékok annyira speciálisan működnek, hogy specifikus mérési rutinokat igényelnek. Ilyen például a Deus Ex és a Doom. De erre is lehetőség van az OCAT-ban, és folyamatosan frissülni fog. Tehát mindig a legfrissebb verziót kell használni, és pontosan lehet mérni DX12/Vulkan alatt.
-
#24864
Abu85
HÁZIGAZDA
FollowTheORI
#24863
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#24863
üzenetére
Ezt rosszul tudod. Nagyon sok időt vesz igénybe egy sematikus dizájn fizikai implementációja. Minimum egy évet. És ezt úgy, hogy a tervek teljesen készek. Emiatt vezette be az ARM és az Imagination a fizikai IP licencelését. Elkészítenek mindenből egy fizikai dizájnt egy-két elterjedt node-ra, hogy azt átemelhesse a megrendelő. Ez nagyon sikeres az ultramobil piacon, mert a jellemző egy-másfél év közötti időigény fél évre csökken.
Az AMD ilyen üzleti modellt nem tervez. Szerintük ez nem kifizetődő. Inkább megrendelhetik a lapkát, ha igény van rá, és az AMD majd elintézi a gyártást is. A megrendelő egy kész terméket kap tokozva, tesztelve. Ha ez nem jó, akkor az ARM és az Imagination szívesen kiszolgál alternatív igényeket.
-
#24861
Abu85
HÁZIGAZDA
FollowTheORI
#24858
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#24858
üzenetére
Csak gondolj bele. A GPU IP még nem fizikai dizájn, tehát előbb implementálni kell egy adott node-ra. Az AMD pedig nem tipikusan egy licenceléssel foglalkozó cég, tehát konfigurálható sematikus dizájnt nem fognak árulni. Lesznek azok a sematikus dizájnok, amiket maguknak terveztek és kész. Ha valaki akar egy GPU IP-t az AMD-től, akkor ahhoz licenceli az igényekhez legjobban hasonlító AMD dizájnt, illetve annak komponenseit. Abból megtervezi a saját GPU-ját, amiből készít egy fizikai dizájnt arra a gyártástechnológiára, amit választ. Ehhez a procedúrához nagyjából két-két és fél év kell. Tehát bármit is rendel egy cég ahhoz mindig csak egy generációval később tud fizikai dizájnt szállítani, mint az AMD.
-
#24857
Abu85
HÁZIGAZDA
FollowTheORI
#24856
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#24856
üzenetére
Nem tudnak átállni. Az IP licencelés a ARM-nak és az Imaginationnek azért működik, mert maguk nem fejlesztenek kész lapkát. De az AMD igen. És végeredményben ki akar egy generációval régebbi IP-t licencelni, ha azt az AMD egy saját lapkával úgyis veri?
Az AMD-nek erre a problémára a megoldása a Semi-Custom divízió: rendelj dizájnt és megkapod a legújabbat. Bárkinek terveznek lapkát, aki kifizeti a minimális díjazást. Még az Intelnek is. Akár az is elfogadható, hogy nem árulják el, hogy az Intel egy megrendelő. Teljes titokban is lehet rendelni. -
Abu85
HÁZIGAZDA
válasz
#85552128
#24847
üzenetére
Ugye a gond az ASW-vel, hogy nem te döntöd el, hogy aktív legyen-e, vagy sem. Ha mondjuk nem tetszenek a vele járó apró röcögések, akkor esélyed sincs megszabadulni tőlük.
Ha nagy lesz rá a user oldali igény, akkor az AMD is be tudja kapcsolni a GCN2/3-ra, de szerintük romlik tőle a VR élmény. Viszont egy kapcsoló az egész a driverben. Csak át kell rakni a tiltás oldalon szereplő hardverek ID-jét az engedélyezett oldalra.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#24845
üzenetére
Az ASW eleve az AMD ötlete volt, mert előrántottak a kalapból egy olyan hardvert, ami képes bármilyen warp feladatot 10 nm-on belül elkezdeni. Ez kell ugyanis ahhoz, hogy az ASW mellett a VR ciklikusan folyamatos maradjon. Az egész tehát a kiszámíthatóságtól függ, ugyanis a felhasználó ciklikusan fog látni warpolt és valós frame-et.
A kiszámíthatóságot viszont csak úgy lehet biztosítani, ha tényleg nem a memória elérésétől függ a warp megkezdése, mert az lehet 100-1000 ns között bármi. Ergo bármilyen más hardver nem képes ciklikusan biztosítani a warpolt és a valós frame-et, amit érzékel a felhasználó és kis ugrásokat lát majd a VR-ban. Így működik a Polarist leszámítva az összes többi architektúra. Az AMD szerint ezek a kis ugrások rombolják annyira az élményt, hogy nem éri meg az ASW, míg az NV szerint így is megéri. Pont. -
Abu85
HÁZIGAZDA
válasz
#85552128
#24843
üzenetére
Az ASW-t. Benne van a rendszer, ki van építve a LiquidVR driverben, de egy bizonyos minőség alatt nem éri meg bekapcsolni, mert rombolhatja az élményt.
Az NV-nek ez azért más, mert nekik nincs modern VR környezetre tervezett hardverük, így náluk nem lesz olyan, hogy ha a juzer Maxwellről Pascalra vált, akkor rá sem fog ismerni olyan folyamatos lesz a mozgás VR-ban. Az AMD-nél viszont ha GCN2/3-ról GCN4-re váltasz, akkor nagy lenne a különbség a GCN4 javára a folyamatosságban, ha az ASW aktív lenne a régebbi rendszereken. Ezért inkább nem aktív, mert a folyamatosság VR-ben is fontos lehet, annak ellenére, hogy az ASW segít növelni a sebességet. Sajnos ezt nem csodával éri el, hanem ára van. -
Abu85
HÁZIGAZDA
válasz
#85552128
#24840
üzenetére
Igazából megkapta, csak nincs engedélyezve. Az ASW ugyanis a minőségre is hat. Nem érzed magad rosszul tőle, de úgy érzed, mintha mikroakadozna a program. Az ASW minősége tehát nem egységes, hanem hardverfüggő, és emiatt a VR runtime fejlesztői a VGA-gyártókra bízták, hogy eldöntsék mi az, ami szerintük megfelelő minőség, és mi az, ami már nem fér bele. Az AMD nagyon magasra helyezte a minimum minőségi lécet, amibe csak a Polaris fér bele. Ez nagyrészt egyéni döntés kérdése, semmint technikai probléma. Egyszerűen nem akarják, hogy a LiquidVR-t a játékosok akadozással párosítsák.
Ezt azért fontos egy gyártónak eldönteni, mert az ASW a felhasználó oldalán nem kikapcsolható. Tehát a gyártó fogja eldönteni helyetted, hogy milyen VR élményt kapsz. Ha nem értesz egyet, akkor át kell szöknöd a másik gyártóhoz. -
#24752
Abu85
HÁZIGAZDA
SpongyaBob
#24617
Abu85
HÁZIGAZDA
válasz
SpongyaBob
#24617
üzenetére
Ez bonyolult nagyon. A hardverek és a meghajtók más motorkonstrukciókra vannak felkészítve, és eltérő játékok (motorok) esetében eltérően reagálnak. Szóval még általánosítani sem lehet, hogy x jobban igényli a procit y-nál. Az egész motorfüggő. Pontosabban annak a függvénye, hogy a motor milyen módszerrel adja át a rajzolási parancsokat: indexelt/nem indexelt, valamint direkt/indirekt. Az NV jobban szereti a direktet, míg az AMD az indirektet. Eszerint változik a meghajtó működése is. Tehát általánosítás haszontalan, mert annyiféle lehetőség van, hogy az egész motorfüggővé válik. Sőt, nem egy motorban külön path van AMD-re és külön NV-re.
Majd DX12-ben ez az egész jelentősen egyszerűsödik, mert ott már nem lesznek külön optimalizálások. -
Abu85
HÁZIGAZDA
Nem mindenhova kell árnyékolás. De tényleg. Ebbe a szobába hova kellene ilyen fényviszonyok mellett? Az a jó pont, hogy nem keletkezik egy rakás teljesen hamis környezeti árnyékolás. Egy SSAO konstrukciónál nincs rosszabb, ha mindenhova ész nélkül árnyékolást pakol, csak azért, mert a user kívánja a különbséget. A HBAO nagyon sok, teljesen hamis árnyékot generál. Az a legjobb, ha a fejlesztő csinálja meg a saját SSAO megoldását, mert házon belül tudja ellenőrizni a megfelelő eredményt offline számolt AO-val. Ennél egyébként több árnyék kellene, de ez egy alap konstrukció.
[link] - itt láthatod, hogy ahova kell oda rak árnyékot.
Erre a játékra egyébként az SSBC-t ajánlom.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#24511
üzenetére
A DX11 teljesen más. Ott nem a program, hanem a meghajtó kezeli a VRAM-ot. Szóval arra vonatkozóan jóval limitáltabbak a fejlesztők eszközei. Tulajdonképpen nem is tudják befolyásolni, hogy mi legyen a VRAM-ba, erre vonatkozóan a meghajtónak szabad keze van. Persze próbálkozások voltak itt is, de inkább hátrányosan sültek el.
Amiért ez a kérdés újra felmerült az az explicit API, mert itt már nincs kernel driver, itt már a fejlesztő mondja meg, hogy mi lesz a VRAM-ban.
Valószínűleg egyébként a problémát nem kell sokáig kezelni. Pusztán a Microsoft ajánlásai miatt el fogja érni minden VGA a jövőben a 8 GB VRAM-ot. Illetve lehet olyan alternatívákon dolgozni a szoftverben, mint a virtuális textúrázás. -
-
#24503
Abu85
HÁZIGAZDA
->Raizen<-
#24502
Abu85
HÁZIGAZDA
válasz
->Raizen<-
#24502
üzenetére
Felbontástól függ, és persze a pályától. De igen, ennél a játéknál előfordul, hogy huzamosabb játékidő után pár textúra már nem maximális részletességű. Ez alól egyedül a benchmark mód a kivétel. Ott force-olva az van, amit beállítasz.
-
#24501
Abu85
HÁZIGAZDA
->Raizen<-
#24499
Abu85
HÁZIGAZDA
válasz
->Raizen<-
#24499
üzenetére
A Deus Ex Mankind Divided jelenetei borzalmasan eltérők. Ott nem ideális egy ilyen funkciót állandóra tenni. Az a program jelenleg azt teszi DX12 alatt, hogy a beállított textúraméretet rakja be mindenhova. Aztán ahogy fogy a VRAM úgy cseréli le az egyel kisebbre. Eléggé trükkös megoldás, de nagyon jól működik.
-
Abu85
HÁZIGAZDA
válasz
sakal83
#24498
üzenetére
1. Akadozni fog. De a program mindenképpen figyelmeztetni fog, ha nincs elég VRAM-od. Ez egy követelmény, amit a Microsoft jövőre kér minden Store-ra is dolgozó fejlesztőtől. Ma még csak felugrik egy üzenet, hogy kevés VRAM mellett probléma lehet.
2. A DX11 esetén annyira sok beleszólása van a drivernek, hogy megjósolhatatlan. Valszeg tölti majd fel a memóriát, és ha kifut, akkor töröl. Minden törlés akadást jelent.
3. 3 GB-ra nincs egzakt ajánlás. Annyira kevés ilyen VGA van, hogy felesleges foglalkozni ezekkel külön. A 2 GB-os ajánlás fog érvényesülni.Akadásokat fogsz érezni. Másodperces szintűeket. A sebességed alapvetően meglesz.
-
Abu85
HÁZIGAZDA
válasz
sakal83
#24476
üzenetére
A Microsoft nemrég kiadott egy ajánlást, hogy szerintük mit érdemes csinálni a DX12 alatt (ez használható Vulkan API-ra is).
Végeredményben négy textúraméretet tartanak ideálisnak, azaz a textúraminőség elvileg lehet: low, medium, high és very high. A DX12 sajátosságai miatt az MS nem ajánlja, hogy ez változtatható legyen és az alábbi VRAM mennyiséghez ajánlják kötni a paramétert: 2 GB-tól low, 4 GB-tól medium, 6 GB-tól high, 8 GB-tól very high. A VRAM mennyiségét úgy érdemes megválasztani, hogy milyen textúraminőséggel szeretnél játszani, és az MS ajánlása szerint nem tudsz majd belelő kifutni, mert meg sem engedné egy program, hogy beállítsd a magasabb részletességet. -
Abu85
HÁZIGAZDA
válasz
pengwin
#24475
üzenetére
Mert baromira sok háromszögből épül fel. A Civ5-höz képest majdnem tízszer többől.
Vulkanban nincs multi-GPU jelenleg. Mivel az explicit API elsődleges szempontja a SFR-szerű multi-GPU mód, így olyan API-t kellett választani, amelyben ez megvalósítható. Két ilyen van: DX12 és Mantle. Utóbbit csak akkor választhatták volna, ha DX12-ben valami nem megoldható, mert szimpla extra API-ként ennek a használatát megtiltotta az AMD. Ebből maradt a DX12.
-
Abu85
HÁZIGAZDA
válasz
Sinesol
#24469
üzenetére
A Vulkan alatt nincs kernel driver. Szóval az teljesen alkalmazáshiba. Az ilyen hibák a DX12/Vulkan portok alatt nem a drivertől vannak-lesznek. Felesleges innen várni a javítást. Már nincs kernel driver, ahogy írtam. Amikor fel van véve hibának nem azért van, hogy azt képesek egyoldalúan javítani, hanem azért, hogy tudnak róla, és egyszer jön majd egy patch a fejlesztőktől.
-
Abu85
HÁZIGAZDA
Nem VR-ben. De a VR az más. Tipikusan összefoglalható úgy a helyzet, hogy ha x teljesítményt ki akarod hozni egy vagy két GPU-ból, akkor nem VR-nél az egy GPU a kedvezőbb, de VR-nél már a kettő. Nem csak a jobb hatékonyság miatt, hanem amiatt is, hogy a fejlesztők így fogják szétválasztani a grafikai minőséget.
-
#24459
Abu85
HÁZIGAZDA
Petykemano
#24457
Abu85
HÁZIGAZDA
válasz
Petykemano
#24457
üzenetére
Ha jön egy két GPU-s egy NYÁK-os kártya, akkor az a VR-hez jön. Mégpedig azért, mert az AMD úgy szegmentálja a VR grafikált, hogy ha két GPU-d van, akkor jobb grafikát kapsz, míg ha egy GPU-d van, akkor megy ugyanúgy 90 fps-sel, de csak gyengébb grafikával. Ez konkrétan le lesz kódolva az érkező VR játékokba, tehát még a legerősebb GPU-val sem kapsz jobb grafikát, mint két gyengébb GPU-val. Persze ez működni fog két külön VGA-val is, szóval ehhez nem kell dual GPU-s megoldás.
A Serious Sam VR ilyen lesz.
-
Abu85
HÁZIGAZDA
válasz
adler741
#24449
üzenetére
A problémád nem egyedi, de csupán ahhoz kötődik, hogy az NV-nek a gyári alapbeállítása nem olyan jó, mint az AMD-é. A fakóság abból ered, hogy nagyon alulszaturált a kép és a szürkeárnyalatok aránya nem optimális. Ugyanakkor ezek korrigálhatók a szaturáció (NV-nél digital vibrance), a gamma és a kontraszt csúszkákkal. Ezekkel játssz és idővel eljutsz nagyjából ahhoz a képhez, amit AMD-vel kaptál. Semmiképpen sem hardveres a gond, csak kevésbé jó az alapbeállítás. Amint megvagy, írd fel a beállításokat, és persze mentsd el.
-
-
Abu85
HÁZIGAZDA
válasz
#85552128
#24442
üzenetére
Utólag nyilván én is tudom, hogy hol van, de előtte kerestem három percet. Szisztematikusan átnéztem az összes beállítást, mert tudtam, hogy ennél a játéknál külön kell aktiválni. Persze amikor megtaláltam, akkor az sokkoló felismerés volt, hogy nem is van logikátlan helyen.
[link] - ebben a videóban egyébként van látható gyorsulás. Az első két perc a DX12 mGPU, míg 6:16-tól van a single GPU módba kényszerítve a hardver. Nyilván a split-screen mód sajátosságai miatt nem fog kétszeresre gyorsulni, mert ez egy késleltetést csökkentő mód elsődlegesen.
Az eredmények a várost nézve: DX12 mGPU ~97 fps, single GPU pedig ~67 fps
-
Abu85
HÁZIGAZDA
válasz
#85552128
#24439
üzenetére
Bőven előfordulhat, hiszen nincs még egy játék, amely erre vonatkozóan manuális beállítást igényelne. Még ha van is erre opció, akkor is van rá egy automatikus rutin, ami felismeri a több VGA-t és a user helyett bepipálja a több GPU-s módot. A Civ 6 ezt nem teszi meg, így minden ilyen változás előtt manuálisan kell elcammogni a menübe és ki-be kapcsolgatni. Ráadásul eléggé el van rejtve. Én is 3 percig kerestem, mire megtaláltam.
(#24440) lezso6: Szerencsére nem. Nemrég volt olyan híresztelés, de a fejlesztők szerint minden megvan a legfrissebb Windows 10 frissítésben, ami kell. Csak nem szabad elfelejteni aktiválni. Egy későbbi javításban egyébként ki fogják emelni ezt a beállítást, mert sokak nem találják. Nem is gondolnak arra, hogy manuálisan kell aktiválni, mert nem jellemző ez.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#24436
üzenetére
Az eredmények láttán én nagyon kétlem, hogy a felbontás beállítása alatt kiválasztották a megfelelő mGPU opciót. Ha azt nem választják ki, akkor nem aktiválja a motor. Ez a Civ6-ban nem fog automatikusan működni. Még csak be sem kapcsol automatikusan. Egyedileg kell aktiválni. Ez nyilván a tesztelésnél nagyon szar, mert mindig menni kell a beállításokba ki-be kapcsolgatni, de ez van, így működik a játék.
-
Abu85
HÁZIGAZDA
válasz
Raggie
#24432
üzenetére
A DX11-es AFR, vagyis a CrossFire és SLI nem ugyanaz, mint a DX12-es. A DX11-es megoldással az a baj, hogy még gyártón belül is töredezett, vagyis legalább négy-öt implementáció kell, hogy működjön minden lehetséges konfiguráción.
A DX12-es szabványos AFR tényleg szabványos. Minden egyes sűrűn alkalmazott funkciót szabványosít, vagyis a gyártóknak a meghajtókban csak ezeket kell egyénileg lekezelni, de a fejlesztőknél az egész egy programkódot igényel.
A skálázódásra nem lehet panasz: [link] - egészen elképesztő a hatékonysága a Microsoft szabványos AFR-jének. Az egészre az nyomja rá a bélyeget, hogy az NV szerint akkor is szarul működik, ha a Microsoft azt állítja, hogy jó.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#24430
üzenetére
A Civilization 6-ban van multi GPU. Működik is, ha nem procilimites a beállítás.
Az újabb DX12 játékokban ezek szerencsére sokkal nagyobb figyelmet kapnak. Elsődlegesen azért, mert a Microsoft hozott egy szabványos AFR-t. Ez van a Warhammerben és az új Deus Exben. Az új Tomb Raider is ezzel kezdett, de lecserélték saját AFR-re.
Egy összefüggő probléma van DX12 alatt. Saját AFR-t nem nagyon akarnak írni a fejlesztők, viszont a Microsoft szabványos AFR-je körül vannak gondok. Ez az AMD-vel nagyon működik, lásd új Deus Ex és Warhammer, míg NV-vel alig használható. A Microsoft szerint jó a konstrukciójuk, mert az AMD-vel tökéletes, míg az NV szerint a konstrukció szar, nem pedig a driverük. Jelenleg itt állnak az álláspontok.
-
#24422
Abu85
HÁZIGAZDA
Petykemano
#24421
Abu85
HÁZIGAZDA
válasz
Petykemano
#24421
üzenetére
Áh, hát én azt honnan tudhatnám.
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
#24420
Abu85
HÁZIGAZDA
huskydog17
#24419
Abu85
HÁZIGAZDA
válasz
huskydog17
#24419
üzenetére
Nyilván nem csak Kína számított, de messze az a legnagyobb felvásárlópiac a célzott régiókon. Ha ott nem megy egy márkának, akkor nincs értelme erőltetni. A TUL szempontjából igazából mindegy, hogy az OEM-ből megmaradt termékeket hány márkára osztják el.
A Club 3D már nem akkora probléma. Átváltottak a kábelbizniszre.
Egyébként nem hülyeség az, amit a TUL csinált. Elég egy brand és azt kell nagyon nyomni.
-
Abu85
HÁZIGAZDA
válasz
wjbhbdux
#24399
üzenetére
A Club 3D kábelekre, adapterekre és dokkolókra váltott. Nekik ez kivételesen nagyon bejött.
(#24401) fules: A VTX3D sosem volt független cég. A TUL birtokolta, amely cég a legtöbb Radeont adja el ma is. Volt nekik két leányvállalatuk: PowerColor és VTX3D. A VTX3D célja az volt, hogy Kínában érjen el sikereket, ugyanakkor annak ellenére a PowerColor maradt inkább a kedveltebb márka, hogy a VTX3D-t Kínára szabták. Emiatt nem volt értelme a VTX3D-t megtartani, így eldobták a márkát. Ettől a TUL, és a másik leányvállalat, a PowerColor él és virul.
A Point of View senkinek nem volt a leányvállalata. Abba mentek tönkre, hogy minőséget árultak, miközben az NV egyre drágábban adta a GPU-kat. Manapság már az EVGA is jelentősen leadta a minőséget, igaz, hogy nagyon meg is szívták a GTX1000 sorozatnál.
-
#24379
Abu85
HÁZIGAZDA
huskydog17
#24371
Abu85
HÁZIGAZDA
válasz
huskydog17
#24371
üzenetére
Ez szerintem már PC. De tuti, hogy nem maximum grafikával, mert a HFTS árnyékok nem ilyenek. Szóval az biztos ki van kapcsolva, esetleg a DX12-es módban tényleg nem aktiválható. Az árnyék sima PCSS-nek tűnik, az is elég rosszra paraméterezve, de lehet, hogy a HFTS miatt ezt direkt rossz minőségűre vették, hogy ne zabáljon sok erőforrást. 11:42-től látszik, hogy gyakorlatilag teljesen elmossa a kerítés árnyékát. Ennek alap árnyékkal, vagy HFTS-sel látszania kellene.
A HBAO is észrevehető, hogy aktív, mert látszanak a tipikus jellemzői, a hatás extrém túlerősítése. A 7:15-kor látszik a szoba sarka, amit borzalmasan erős árnyék emel ki. Ez nagyon tipikus hibája a HBAO, különösen a HBAO+ opciónak, hogy olyan helyekre is rendkívül erős árnyékot rak, ahova igazából csak alig látszó kellene. -
#24345
Abu85
HÁZIGAZDA
huskydog17
#24343
Abu85
HÁZIGAZDA
válasz
huskydog17
#24343
üzenetére
Attól, hogy ráírják, hogy PC trailer, még nem jelenti azt, hogy PC-ről vették fel. Már csak azon is látszik, hogy az NV által említette effektek hatását egyáltalán nem lehet felfedezni, és ugye tudom, hogy mit kell keresni.
Hint: ez szvsz egy PS4 Próról felvett videó. Különösebb jelentősége persze nincs. -
Abu85
HÁZIGAZDA
válasz
imi123
#24337
üzenetére
Hardverspecifikus effekteket nem kap, de GPU services specifikusat igen.
Az effektek közül egyedül a HFTS van úgy megírva, hogy NVAPI-t igényeljen, vagyis Maxwell+ exkluzív. Egyébként meg lehetne írni DX12-re szabványosan, de a tesztverzióból hiányzik ez az implementáció, így ez az effekt jelenleg DX11-hez van kötve még NV-n is (valszeg a megjelenésig nem változik, de persze ki tudja). Hasonló a helyzet, mint az új Tomb Raidernél a VXAO-val. DX12-re nem volt leportolva és nem is lehetett bekapcsolni. Ez igazából a Titan X tulajokat érinti, mert a HFTS felezi az fps-t.
AGS4 van. Ballot és readfirstlane van a tesztverzióban. Ezek nyilván Radeon exkluzívak, de működnek DX11 és DX12 alatt is.
-
-
Abu85
HÁZIGAZDA
válasz
cyberkind
#24332
üzenetére
Nem. Az AMD a DX12 leképezőben segített. Az Ubin belül alakult egy csapat, amely a meglévő motorokat írja át DX12-re. Első körben a Snowdropot és most a Disruptot. Explicit API-kban csak az AMD-nek van értékelhető tapasztalata, így ezt a munkát ők segítik. Persze ettől még lehet szar PC-s port is, csak ezúttal az Ubi azért dolgozik kooperációban az AMD-vel és az NV-vel is, mert kedvezőbb minőséget tudnak lerakni az asztalra. Ez már előrelépés ahhoz képest, hogy le se szarják a PC-s portot.
Az egyes gyártók ott segítenek, ahol többet tudnak tenni. -
Abu85
HÁZIGAZDA
válasz
imi123
#24331
üzenetére
Kooperációs fejlesztés volt. Az AMD és az NV is segített. Az AMD azzal, hogy segített összerakni az Ubinak egy normális DX12 leképezőt, amit egyébként a Divisionben is használnak. Ugyanerre épül a Watch Dogs 2, mert mindkét motorba ugyanaz a csapat csinálta meg. Az NV az effekteket segített átírni, mert azok is eléggé el voltak avulva. Egyik sem könnyű feladat, ezért kellett az Ubinak mindkét segítéség. A kódvásárlás már döntés kérdése. A Samsung és az NV kért kódokat a termékei mellé, míg az AMD nem, mert eleve van Doom, BF1 és Civ6 promóciójuk az év végére.
-
Abu85
HÁZIGAZDA
Ehhez még annyit, hogy ez már a tervezésen meglátszik, mert az NV a ROP-ok kialakításán spórol. A Maxwell óta kihagyják a dedikált color-depth cache-t. Ez egy alapvető tranyóspórolás, amivel ugyan vesztenek némi tempót, de számolni kell azzal, hogy sok ROP kell.
A többi kérdésre:
A DX11 eleve sokat hagy a modern GPU-kban. A D3BC egy tizenx éves alap a négykomponenses vektor ALU-s függőséglimites architektúrákra. Ma már ettől gyökeresen eltérnek a hardverek. Ezért jön a D3BC helyére a DXIL.Az API specifikáció nem foglalkozik a CPU-terheléssel. Az API csak követel valamit, amit valahogy a meghajtónak el kell érnie. Akár a host CPU befogásával. Nyilván a mintavételezőbe bekötött erőforrás nem varázslattal kerül át a multiprocesszorba.
-
Abu85
HÁZIGAZDA
válasz
namaste
#24325
üzenetére
Nagyon is jellemző a TBR rendszerekre, hogy több ROP-ot igényelnek. Bár az NV-é nem tipikus TBR, de alkalmaz egy olyan optimalizálást a Maxwell óta, amivel a sok pixelt lefedő háromszögekre vonatkozóan nem engedi kiírni a részleges pixeladatokat a memóriába. Ezzel sávszélt spórol meg, és a hardver belül tárol sokezer nagy háromszögre vonatkozó adatot. Ezért van a nagy L2 cache. Viszont azt el kell dönteni, hogy melyik háromszög részleges pixeladatai maradnak belül és mi kerül kiírásra. Ezt a ROP ellenőrzi minden háromszögre még a valós munka előtt. Ez egy ballansz döntés az NV ROP teljesítményt áldoz a sávszél spórolásért. Ilyen formában legalább 40-50%-kal több ROP kell, de 30-40% sávszél spórolható.
-
Abu85
HÁZIGAZDA
Nehezen fog a DX11 maradni még egy évig is. Az a gond, hogy a konzolról portolják a játékokat és ezeknek a DX11 már nem jó. Annyira különbözne a konzolos és a PC-s fejlesztés, hogy még ha alkalmaznák is a DX11 pathot a motorokban, akkor sem kapna szinte semmilyen optimalizálást. Tehát vagy DX12 lesz vagy Vulkan. Más opció a fejlesztők előtt most nincs.
Új shader modelt tavasszal kap a DX12. Ez lesz a shader model 6.0, és lehetővé teszi, hogy az Xbox One-ra írt shadereket ne kelljen egyáltalán módosítani, így ezek jöhetnek direkten PC-re.
További fejlődés egyébként ezekben az API-kban nem nagyon van. A DX12 legalább 6-7 évig itt marad, mert nincs igazán hova lépkedni. Ami fejlődni fog az a shader nyelv, aminek nyilván a shader model 6.0 lesz az alapja. -
Abu85
HÁZIGAZDA
válasz
#85552128
#24279
üzenetére
Amit már elmagyaráztam, hogy a BF1-nek a Frostbite verziója megköveteli az executeindirectet, amihez hasonló nincs a Vulkan API-ban. A Civ6-nál pedig a multiGPU miatt választották a DX12-t, mert ilyen sincs a Vulkanban.
Nem minden funkciót kapott meg a Vulkan a Mantle-ből, mondjuk executeindirecthez hasonló megoldás a Mantle-ben sem volt.
Ettől függetlenül össze lehet hasonlítani, hogy a függvények 85%-a ugyanaz a két API-ban, és ezeknél a gr-t kell átírni vk-ra. -
Abu85
HÁZIGAZDA
válasz
namaste
#24208
üzenetére
Bocs, de ez megint nem ilyen egyszerű. A TFLOPS és a blending teljesítmény igazából csak architektúrán belül lényeges. Elsődlegesen azért, mert az AMD és az NV ma már eléggé hibrid architektúrákat tervez. Nem igazán IMR-ek, de nem is igazán TBR-ek. Valahol a kettő között vannak, de az gyártótól függ, hogy mennyire húznak az egyik irány felé. Az NV a Maxwell óta inkább a TBR felé húz, ami miatt jóval aktívabban használnak mozaikos optimalizálást, mint az inkább IMR felé húzó AMD GCN. Ennek a hátránya, hogy jóval nagyobb blending teljesítményt igényel, viszont kisebb terhelés a memória-sávszélesség felé. Az AMD ennek pont az ellentéte. Nem igényel nagy blending teljesítményt, de nagyon igényli a memória-sávszélességet. Tehát már az eltérő architektúrák miatt is lényegtelen a direkt ROP és sávszél összehasonlítása, mert az NV-nek sok ROP kell, de kevés sávszél, míg az AMD-nek kevés ROP, de sok sávszél. Persze ezt relatív összehasonlításban kell érteni. A TFLOPS pedig azért erősen elméleti, mert a DX12 alatt is D3BC-n keresztül működnek a rendszerek, amely IR-t a 2000-es évek elején befutott architektúrákra húztak fel. Ma már egyáltalán nem úgy működnek a hardverek, hogy a D3BC jól mappelhető legyen rájuk. Ezért hoz a Microsoft a shader model 6.0-ban egy új IR-t, ami a DXIL. Microsofttól elszakadva ugyanezért hozott a Khronos is egy SPIR-V-t. Szóval az elméleti TFLOPS az tök jó, de nincs olyan PC-s hardver, ami nem SIMT modellt használna és ezáltal ne függene a teljesítmény a regiszterhasználattól, hiszen minél erősebb terhelés éri a regisztereket, annál kevesebb wavefront-warp/akármiwave futhat párhuzamosan, és annál rosszabb lesz a rendszer kihasználása. Ugye erre reakció részben a GCN4 utasítás-előbetöltése. A DXIL-en és a shader model 6.0-n már lehet látni, hogy a SIMT modell felé lépdel, hiszen mindegyik hardver ilyen már. Ettől nőni fog a hardver kihasználhatósága is, mindegyik hardveré.
A DirectX 12 több szintre bontja a bekötési rendszer. Van a TIER_3, aminél az erőforrás direkten a multiprocesszorba kerül bekötésre. Ez az alapvető modell, és ennek vannak butított szintjei. A TIER_2 szint a mintavételezőbe engedi bekötni az erőforrást, és driverrutinra van szükség ahhoz, hogy az onnan átkerüljön a multiprocesszorra. Na most ez a driverrutin processzoridőt igényel. A TIER_1 szint esetében maga a bekötés úgy zajlik, hogy a host processzor végzi a teljes munkafolyamatot, és köti be az erőforrást a multiprocesszorba.
Abból egyébként nincs semmi gond, hogy minden cég hardvere ideálisan működik a maga módján, és ha nem lenne az API, akkor ezek abszolút tökéletesek lennének, de az API létezik, és ebben vannak bizonyos szabályok, amelyeket követni kell az adott implementációnak. Szóval az NV-nek azért van szüksége arra a processzoridőt használó driverrutinra, mert abban a fránya DX12 API-ban megkövetelte a Microsoft, ugyanis a pure bindless modellre építették fel a bekötést, és a rosszabb modelleket ehhez igazították hozzá, ami áldozatokkal járt, hogy ez a három szint egyáltalán kompatibilis legyen egymással. Ez teljes mértékben egy szoftveres döntés volt, gondolva arra, hogy a DX12 itt lesz 2020-ban is, amikor már minden hardver pure bindless lesz. De egyébként dönthettek volna úgy is, hogy a DX12 bekötési modelljét arra húzzák fel, hogy elég a mintavételezőbe bekötni az erőforrást, és akkor az az NV-nek lett volna jó, de a jövő szempontjából nem ez tűnt a legjobb döntésnek.Persze, hogy nincsenek kötelező szabályok. Az MS csak azért ajánlja, amit ajánl, mert így működik az API gyorsan. Lásd Rise of the Tomb Raider, ahol nem követték az MS ajánlásait. Azóta mindenki ezeket követi, mert látványosan nem működik akkor a DX12, ha kifejezetten nem ajánlott RS modellt követnek a fejlesztők. Függetlenül attól, hogy az NV ajánlja ezt vagy nem.
-
Abu85
HÁZIGAZDA
válasz
namaste
#24195
üzenetére
Semmi köze a számítási teljesítménynek ehhez, hiszen a DX11 ugyanazokat a shadereket használja, amiket a DX12. Ahol ez számítani fog az.a Shader model 6.0, és az ebben érkező DXIL
A skalár egység nem lenne lényeges, ha a Microsoft nem erre építette volna fel a DX12 bekötésig modelljét. De mivel ez az API már támogatja azt, ha egy erőforrás direkten a multiprocesszorba kerül bekötésre, így az előny annyi, hogy semmilyen bekötés nem jár processzorterheléssel. Ezért ment el az Intel is öszvér megoldás felé, mert számít az, hogy a processzoridő 15-20% ezáltal felszabadul.
A Microsoft nem írja elő, hogy miképp kell használni az RS-t. A fejlesztőknek ajánlásokat tesznek elsősorban a fejlesztők érdekében.
Félreérted, az NV támogat mindent, ami kell a base funkcionalitáshoz. Az RS-nek magának vannak limitációi, ha egy buffer view direkten van kapcsolva, vagy egy leíróra mutató pointeren keresztül. Ez teljesen hardverfüggetlen, magában az API-ban van limitálva.
-
Abu85
HÁZIGAZDA
Ez nem ilyen egyszerű. És ez alapvetően félre van értve.
A GCN azért tud jól alkalmazkodni ezekhez az explicit API-khoz, mert van a multiprocesszorokon belül egy elég sokat tudó skalár egység. Ilyen nem nagyon szokott lenni a GPU-ban. A CPU-kban alap, de a GPU-kban inkább úgynevezett branch egység van, ami nem tud annyit, mint a GCN-nek a skalár egysége. A legfőbb különbség a konstans puffer és a erőforrásleíró hardver között van. Az AMD nem fixfunkciósat használ ezekből, hanem programozhatót. Ez lehetővé teszi, hogy bármelyik API-hoz tökéletesen alkalmazkodjon az architektúra, és teljesen mindegy, hogy az adott API milyen bekötési modellt ír elő. Egyszerűen azt a modellt leprogramozzák a meghajtóban, és az erőforrásokról az aktuális képet a memóriában tárolhatják. Ezért van az is, hogy az AMD a Mantle, a DirectX 12 és a Vulkan API-ra is ugyanazt a PAL réteget használja a meghajtóban, mert egyszerűen a felszín alatt mindegyik API-t pontosan ugyanúgy kezelik. Erre a PAL rétegre pedig fel van húzva egy ICD réteg, ami az adott API specifikus jellemzői szerint dolgozik. A modell előnye, hogy bármit is optimalizálnak a PAL rétegen belül az mindhárom API-ra pozitív hatással van, és nem mellesleg három helyett csak egy meghajtót írnak, vagyis az x mennyiségű humán- és pénzbeli erőforrást háromszor hatékonyabban költik el. És ennek az egésznek az a skalár egység az alapja a multiprocesszoron belül. De akkor most már járjuk végig ezt, és az a skalár egység azért jóval robusztusabb, mint egy szimpla branch egység, amit a konkurensek használnak. Ez magával hozza azt, hogy romlik az energiahatékonyság, mert egy fixfunkciós motor egy kialakított feladatra hatékonyabb, mint egy programozható rendszer. Ezt talán nem kell magyarázni, hogy miért. Ezért is van az, hogy a GCN energiahatékonysága rosszabb, mint a többi architektúra energiahatékonysága. Persze itt most kössük generációkat, tehát ne jöjjön senki azzal, hogy a GCN4 jobb, mint a Kepler/Maxwell.
Az AMD konstrukciója annyi volt, amikor megtervezték a GCN-t, hogy kiszámíthatatlan lesz az API-k fejlődése, amiben valljuk be, hogy nagyon igazuk volt, hiszen jelenleg két új szabványos API van, és mindkettő más bekötési modellt követel. Ha megtartják a klasszikus értelemben vett branch egységet, akkor vagy az egyikben lettek volna jók, vagy a másikban, vagy leginkább egyikben sem. A programozható skalár egységgel viszont nincsenek a hardvernek direkt limitációi, úgy fog működni, ahogy azt a meghajtóban leprogramozzák. Jöhet egy harmadik vagy negyedik API is, arra is rá lehet illeszteni a GCN-t, egyszerűen csak kódolás kérdése az egész.
Az NV és az Intel ma különböző képességű branch egységgel dolgozik. Az Intel azért érdekes (erre kitérhetünk), mert ők brute force megoldással próbálnak az API-k után menni. Egyszerűen nem léptek át a skalár egységre, hanem csúnya szóval hardveresen emuláltak egy memóriaalapú architektúrát. A Gen9 valójában nem az, de a programozó felé pontosan úgy viselkedik. Ezt úgy érték el, hogy a korábbi 255 bejegyzéses erőforrás-kezelésüket leváltották több, kétmillió bejegyzéses megoldásra. Ez ilyen furcsa öszvér megoldás. Nem tudják programozni, de a DX12 bekötési modelljét maradéktalanul kielégíti a legmagasabb szinten. Viszont zabálja a tranyót, mert nyilván azt a több szintre lebontott, szintenként kétmillió bejegyzést tárolni kell. De itt is trükköznek, mert nem tárolják az összes szintet, hanem csak mindig egyet, és a többi szintet lementik a memóriába. Ezeket a szinteket cserélgeti a hardver ezért mondható emulált memóriaalapú architektúrának (persze, ha valójában nincs annyi bejegyzés, akkor mind befér a lapkán belülre is). Ennek nyilván az az előnye, hogy amit most a DX12 megkövetel formátum és erőforrás-kezelés gyanánt, azt a Gen9 megoldja, de ha a Microsoft mondjuk úgy dönt, hogy bevezet egy új puffert vagy formátumot, akkor nem tudnak utánamenni, míg az AMD-nek egy ilyen újítás támogatása csak egy meghajtófrissítésbe kerül.
Az NVIDIA branch egysége sokkal inkább klasszikus, tehát nem AMD-féle programozható rendszerről van szó, vagy nem Intel-féle öszvér modellről, hanem a klasszikus konstans puffer és erőforrásleíró hardver köszön benne vissza, abszolút fix limitációkkal, különállóan minden egyes pufferre és formátumra. A fenti két megoldáshoz képest ez a leghatékonyabb, ha a fogyasztásról van szó, de messze ez a legbutább, ha a működésről. Ezért van az NV-nek a DX12-vel az a problémája, hogy nem tudják támogatni a legmagasabb bekötési szintet, miközben az AMD és az Intel tudja, illetve pusztán ez a klasszikus modell vezetett oda is, hogy a Microsoftnak Root Signature ajánlásai sem jók az NV-nek. A klasszikus modell miatt a GeForce-ok alkalmaznak úgynevezett fast pathokat. Ezek a DX11-ből maradtak meg, mert ez az API sokkal limitáltabb volt az erőforrások bekötése szempontjából. Egyszerűen voltak tipikus feladatok, és arra vonatkozóan tipikusan tudni lehetett, hogy a fejlesztő milyen puffert és milyen formátumot fog használni. Ennek az oka, hogy a DX11-es modellben általában egy tipikusan jól működő megoldás volt az egyes problémákra és kész, minek kell több ugye? Az NV ezekre a tipikus megoldásokra csúnyán mondva gyorsabb feldolgozást épített be a hardverbe, így az javított a teljesítményen. Na most a DX12-ben a Microsoft ott rontotta el ezt a játékát az NV-nek, hogy lényegesen nagyobb szabadságot adott a fejlesztőknek a erőforrás-kezelés szempontjából, és ennek az alapja az, hogy a Root Signature-be csak pointereket ajánlott helyezni, amelyek leírótáblákra, root konstansokra és puffer pointerekre mutatnak. Ugyanakkor a Root Signature végeredményben elfogadja, ha direkt puffereket is rak bele a fejlesztő, de akkor ezek a pufferek különféle limitációkat kénytelenek elszenvedni, például nem támogatják az össze formátumot, illetve teljesítményvesztés is lehet a vége. Az NV azért megy szembe a Microsoft ajánlásaival, és biztatják a fejlesztőket, hogy rakjanak puffereket is a Root Signature-be, mert azzal néhány formátum erejéig elérik a hardverbe épített fast pathokat, de ha a fejlesztők a Microsoft ajánlásait követik, akkor ezek a fast pathok kihasználhatatlanok lesznek. A legtöbb DX11-DX12 váltásnál az NV hardverek sebessége ezért csökken, egyszerűen elvesztik a hardverbe épített fast pathok használatának lehetőségét. Az NV-nek a DX12-ben ez a legrémisztőbb, hogy minél inkább használják ki az API-t a programok, annál több fast pathot buknak el a hardverben. Ma még ez nem annyira kedvezőtlen (bár BF1-ben azért már erősebben látszik), de ha a programok átváltanak bindlessre, akkor minden fast path odalesz, és az ezzel nyert 20-25%-os extra teljesítmény is.A másik dolog a hsz-edből az API-k fejlődése. Na most az nem igazán baj, ha az API diktálja a tempót. Azért lássuk be sok területen nagyon le van maradva a rendszer az aktuális hardverdizájnoktól. Tehát mindenképpen egy nagy lépést kell tenni ebben az ügyben. Részben ezt meg is tették az érintettek. És végre figyelnek a shader nyelvre is. Mikor is volt utoljára nagy váltás? Kb. 10 éve a shader model 4.0-val. Azóta átment alattunk pár architektúra, és az újak nagyon nem úgy működnek, mint 10 éve. És persze óriásit lépünk majd előre, ami látva például a cross lane operációkat még a GCN-en belül is le fogja szakítani a GCN1/2 hardvereket a GCN3/4-től, de ez a lépés fontos a fejlődésben. Ezt le fogják követni a hardverek, mert a konzolon már ma használják a programozók az újításokat. És nem azért használják, mert mazochista mind, hanem azért, mert olyan újítások, amelyek nélkül nem igazán jó élni.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#24124
üzenetére
A fejlesztés inkább kooperációs volt. Az ugye egy másik kérdés, hogy ki akar kódot venni a VGA-ihoz. Az AMD nem, míg az NV igen. Az Ubinak ez igazából mindegy. Az AMD eleve kiköltekezett a BF1-re és a Civ 6-ra. Egy harmadik nagy játékot felvenni eléggé célszerűtlen lenne. AZ NV-nek pedig célszerű, és az Ubinak is célszerű eladni.
-
Abu85
HÁZIGAZDA
válasz
Ren Hoek
#24121
üzenetére
Mellélőttél, mert az NV erőlteti, hogy a DX12 címeit teszteljük. Emiatt lesz több DX12 cím a csomagban.
Mivel hoztak és hoznak jó címeket, így nekünk ez csak jó. Kezdésnek kapásból ott a Division DX12 patch.(#24123) smc: Skype-on. Alapvetően igazuk van, hogy kevés az NV-től származó DX12 játék a tesztben. De elsődlegesen azért, mert kevés DX12 játékot szponzorálnak. De én sosem zárkóztam el attól, hogy a jól optimalizált DX12-s NV-s játékokat bevegyük a tesztbe, csak hozzanak jó címeket. Ott van példának a Division. Hozták a DX12-t, át is váltunk rá. Ők boldogok tőle, én boldog vagyok, hogy végre hozzák a címeket, ti pedig több DX12 mérést láthattok.
-
Abu85
HÁZIGAZDA
válasz
Ren Hoek
#24115
üzenetére
Akkor ne olvasd el, de az aktuális és az érkező tesztjátékok támogatnak DX12 módot. Nyilván a legjobb leképezőt fogjuk használni.
Senki se mondta, hogy a retro rossz dolog, viszont jövőre 2017 lesz. Kellenek az új játékok a tesztbe.
(#24117) do3om: Idén már nem frissítünk nagymértékben a tesztcsomagon. Leginkább februárban esedékes a teljes váltás. Egyrészt már eleve van számos DX12 játék, és a DX11-esekből is a Division DX12-re vált, jön a Watch Dogs 2, itt lesz a Civ 6 is a DX12 móddal, stb.
Ugyanezt lejátszottuk a DX11-nél. Sokaknak nem tetszett, hogy gyorsan váltottunk DX11-re, de nekünk lett igazunk, mert elterjedt az API. -
#24103
Abu85
HÁZIGAZDA
Petykemano
#24102
Abu85
HÁZIGAZDA
válasz
Petykemano
#24102
üzenetére
Ne számíts semmi komolyra, mert jön még a Vega11 is a Polaris10 helyére. Igaz később, mint a Vega10.
-
Abu85
HÁZIGAZDA
válasz
Ren Hoek
#24100
üzenetére
Nem alulról építkeznek. A Vega10 12-14 TFLOPS közötti lapka lesz. Nem lesz annyira sok SKU sem. A jelenlegi adatok szerint lesz egy csúcs SKU, aminek két verziója lesz: egy Fury X-hez hasonló vizes és egy Nano-hoz hasonló mini. Ezek mennek a Titan X és a GTX 1080 Ti ellen. És lesz egy vagy kettő butított verzió, de elég sok CU-t kell letiltani ahhoz, hogy pont az 1070 ellen legyen jó. Legalább 16-20-at. Annyi CU-t nem fognak lekapcsolni.
Később lesz egy dual Vega 10 a Radeon Pro Duo mintájára. Annak nem lesz ellenfele, mert 24+ TFLOPS-os szörnyeteg lesz. Az megint ilyen Radeon Pro típusú termék lesz marha drágán. -
Abu85
HÁZIGAZDA
Így változik meg az egész.
GPU<->DRAM
És a jövőben ebből GPU<->DRAM<->NAND flash lesz. Tehát DRAM-od az SSD-s VGA-kon is lesz, csak mivel borzalmasan terjedni fog a tiled resources, így a játékok elkezdenek 200-300 GB-os virtuális textúrákat használni. Azokra érdemes a GPU mellé tenni egy SSD-t. -
Abu85
HÁZIGAZDA
válasz
füles_
#24086
üzenetére
A NAVI teljesen más koncepció, az nem jön olyan hamar a teljes piacra vonatkozóan. Ott már terabájtos kapacitású memória lesz a GPU-n. Ahhoz új API-k is kellenek majd, mert a játékokat konkrétan a GPU melletti SSD-re kell rakni.
A Volta alapvetően a Vega ellen megy majd. Az NV a Volta után hozza a GPU melletti SSD-t. -
#24084
Abu85
HÁZIGAZDA
FollowTheORI
#24080
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#24080
üzenetére
A GF-nek most felesleges a Samsung 10 nm-es LPP node-ját licencelni. Mire azt tömeggyártásban be tudják vetni (fél évvel a Samsung mögött), addigra már bevetésre kész lesz az IBM-tól vásárolt 7 nm-es gyártástechnológia. Emiatt ki is hagyják a 10 nm-es lépcsőt, az IBM-tól vásárolt alapokra jobb építeni.
De érdemes nézni, hogy az 1080 Ti-ről én nem beszéltem hetek óta. Ha lett volna reaális esélye, hogy megérkezik a CES-en valahol elejtek valami hintet.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Ráadásul az adatgyűjtés nem anonim, mert hozzákötik a profilomhoz. 
pff... 
Ú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.
- Apple iPhone 16 Pro Max 256GB fekete titán használt, megkímélt 100% akku (140 ciklus)
- 219 - Lenovo LOQ (15ARP9) - AMD Ryzen 7 7435HS, RTX 4070 (ELKELT)
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- LG 77C3 - 77" OLED evo - 4K 120Hz 1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - PS5 és Xbox!
- HIBÁTLAN iPhone 12 Pro Max 256GB Graphite -1 ÉV GARANCIA - Kártyafüggetlen, MS4520
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest