Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz
keIdor
#23980
üzenetére
Semmi baja nem lett a DX12-ben a multi-GPU-s AFR-nek. Most, hogy az MS csinált rá egy szabványos rutint teljesen vissza fog térni ez a rendszer. A DX11-ben azért döglött meg, mert borzalmasan nehezen skálázódott, de például a DX12-ben az MS egységes AFR rendszere akár 100%-osan is skálázódik az új Deus Ex alatt. És a fejlesztői oldalról borzalmasan egyszerű támogatni, mert gyártófüggetlen.
Az eddig megjelent DX12-es játékok közül a Total War: Warhammer, a Rise of the Tomb Raider és a Deus Ex: Mankind Divided az MS AFR-jét elég jól kezeli. Az egyetlen nehézsége ennek, hogy visszamenőleg nehéz beépíteni, tehát a már megjelent játékok zömén nem valószínű, hogy módosítanak, de innentől kezdve ez egy elég jó belépő a több GPU-s módra. Aki pedig komolyabbat akar, az mehet a multiadapterre.Teljesen mindegy, hogy az NV mit vet ki a GP106-ból. A DX12-nek nem szükséges az SLI és a CF mikrokód a BIOS-ban. Ezekre ugyanis nem épít az API. Belerakhatod a gépbe a két GP106-öt, és működni fog a multi GPU a DX12-es programokban. Az egyetlen dolog, amire mikrokód kell, az a frame pacing, de ez az NV-nél eleve nem aktív DX12-ben, még ha van hidad, akkor sem. Azt nem tudni, hogy ez szoftveres gond-e. Már csak azért sem, mert az AMD DX12-es frame pacingja is csak az XDMA rendszerekre megy. Ezt ugyanis a Microsoft API-ján kell vezérelni, és az eddigi adatok szerint nem árt 4 GB/s-os összeköttetés, amit egyik hidas megoldás sem tud.
-
Abu85
HÁZIGAZDA
válasz
#35434496
#23973
üzenetére
Attól függ, hogy mi a cél. Az Ubisoft célja az egyszerű karbantarthatóság, ami egy MMO-nál igen fontos szempont, és ezért váltottak DX12-re. Persze rakhattak volna még bele async compute-ot is, de nem volt kritikus fontosságú, mert elsődlegesen a DX11-es support költségtől akartak szabadulni, amit már nem bírtak el. A DX12 port hasonlóan gyors, és sokkal olcsóbb lesz a terméktámogatás rá.
Ettől függetlenül ez nem volt egy egyszerű port, mert át kellett írni a motor struktúráját hozzá, azért érkezett sokkal a megjelenés után. De persze az Ubisoftnak megérte, mert valószínűleg a teljes életciklusra nagyobb költség lett volna a DX11-es karbantartás a csomó befutó panasszal. Most ez így egy megugró költség volt, de a karbantartási költség sokkal alacsonyabb lesz a jövőben. Persze nagyrészt amiatt, hogy ha valaki azt mondja, hogy valami nincs rendben DX11-ben, akkor mehet az a válasz, hogy használj DX12-t. És így a supportig csak azok az esetek jutnak el, ahol a probléma DX12-ben is jelen van, vagyis a DX11-es hibákat már tovább sem adják a fejlesztők felé. Ez az egész kis dolognak tűnik, de egy csomó pénzt meg lehet így spórolni úgy, hogy közben a játék egy másik API alatt stabil marad. A legtöbb modern MMO be fogja járni ezt az utat, mert számít az, hogy mennyi pénzt visz el a folyamatosan fejlődő kód mellett a karbantartás.
-
Abu85
HÁZIGAZDA
válasz
Laja333
#23966
üzenetére
Nem igazán vezet be újításokat a DX12 kód a DX11-hez képest itt. Egyszerűen csak át van portolva a motor rá és kész. Se aszinkron compute, se aszinkron DMA, pusztán egy port. Ahol segít azok a gyenge procis rendszerek. Az Ubisoft rövidtávon teljesen át akar állni a DX12-re, mert a supportjuknál rengeteg erőforrást emészt fel a DX11-es meghajtóproblémák tesztelgetése, amiket még javítani sem tudnak. Emiatt minden olyan játék, amelynek alkalmas a motorja rá és hosszú terméktámogatási ciklust élvez kap egy DX12 módot, hogy a support egyszerűen mondhassa azt a usernek, hogy futtassa DX12-ben. Ezzel rengeteg erőforrást spórolnak meg, és ezt más gondok feltérképezésére lehet fordítani. Ennyi a koncepció mögötte.
Egyébként ez nem jelenti azt, hogy a DX11-es hibákat nem javítják, csak nem kell összetörniük magukat miatta, hanem ráérnek berakni a low priority tasakba. -
Abu85
HÁZIGAZDA
válasz
keIdor
#23944
üzenetére
Ez nagyon változó. Az adatlapomon lévő gép valóban az enyém, tehát olyan alkatrészekből áll, amelyet megvettem, vagy elcseréltem valamire az adott gyártóval. De mivel rajtam keresztül jön és/vagy megy pár holmi a gyártók és a PH között, így elég sokat ül nálam egy-egy termék, hogy berakjam ideiglenesen. Például most is van nálam egy RX 460 és egy RX 470. RX470-et használtam is az elmúlt három hétben, csak szóltak, hogy hamarosan jönnek, így kiszedtem, hogy el tudjanak jönni érte, és ne akkor kelljen szerelni, amikor már vinnék a holmit Belgrádba. Szóval a kérdésedre a válasz igen is, meg nem is.
-
Abu85
HÁZIGAZDA
válasz
bivalyolo
#23935
üzenetére
Be kell állítani a grafikát az adott konfiguráció limitációihoz. Nekem például a 2 GB VRAM a limit, és minden olyan opció ami VRAM-ot fogyaszt közepesre van rakva. Ez a titka az egésznek. Nekem azért könnyebb ezt elérni, mert pontosan tudom, hogy melyik beállítást eszi a VRAM-ot. BF1 esetén a textúra, terrain és mesh. (a mesh lowon van, mert nem akartam a textúrákat beáldozni, ez már egyéni döntés kérdése)
(#23937) Szaby59: 35-40 fps-re van kalibrálva. DX11-ben mindegy, mert nem megy 20 fölé multiban.
-
Abu85
HÁZIGAZDA
válasz
Attix82
#23932
üzenetére
Nem az órajel a gond, hanem a Hyper-Threading kezelése bugos (már megint
) a Frostbite alatt. Ez minden nagyobb motorfrissítésnél előjött. Például még a BF4 alatt is. Az az oka, hogy a programozást Bulldozeren végzik még mindig, és a multi-thread optimalizálást CMT-re csinálják, ami káros a HTT-nek. Viszont, ahogy a BF4 alatt is, úgy BF1 alatt is javíthatók a Hyper-Threading kezelésére vonatkozó bugok, csak kell nekik pár hét hozzá. -
Abu85
HÁZIGAZDA
válasz
#85552128
#23930
üzenetére
Nem mindig. Az inaktiválása eseményhez van kötve. Végre session-based modell van a Frostbite-ban, és ha az adott sessionnek valamiért vége, akkor minden erre aktivált beállítás visszaáll alapra.
Eszközspecifikus volt, nem pedig GPU-specifikus. A különböző eszközök az azonos GPU ellenére is kaphatnak eltérő rutinokat.
Semmi gondom nincs DX12 alatt a multival. DX11 alatt valóban elég rossz az élmény, de DX12-vel majdnem két és félszer gyorsabb a sebesség.
-
Abu85
HÁZIGAZDA
válasz
schawo
#23927
üzenetére
Nem a DX11-hez van köze. A motornak a feldolgozási modelljét úgy írták meg, hogy csak az explicit API-khoz illeszkedjen. Ez azért kockázatos, mert ilyenkor van egy relatíve hatékony modelled, ami igényli az explicit API-t, de ha végén DX11-gyel szállítod, akkor ez a hatékonyság hátrányossá válik, mert nem abban a környezetben fog futni, amire tervezték. Hiába lesz sok fps-ed, akkor sem lesz folyamatos, ha nagy a jelenet komplexitása, amire a TPU is kitér a végén, hogy AMD-n és NV-n is lagos a városokban, akármit csinálsz.
(#23928) Szaby59: Szerencsére a BF1 tartalmaz beépített mérőt, ami mutatja az akadásokat.
Eszközspecifikus hibáról még nem hallottál ugye?
-
Abu85
HÁZIGAZDA
válasz
#85552128
#23925
üzenetére
Elolvastad, hogy eredményektől függetlenül az összes hardver lagos a városokban? Ezért nem jó erre a modellre DX11-et húzni, mert egy rakás szinkronizációs pontot eredményez, amitől hiába van 60 fps-ed, akkor is lagos lesz. Érdemes lenne nem csak a képeket nézni, hanem a szöveget is olvasni.
Megint a konzolok kapták a törődést, mert ez egy tipikus konzolmodell, amit PC-re korábban nem igazán hoztak át. Persze, hogy nem, a sok szinkronizációs pont miatt nem működik. Már akinek lagol a DX12. Nekem szuperül megy.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#23923
üzenetére
"Both AMD and NVIDIA powered systems suffer from various intensities of lag when moving around in city areas..."
Annyira bírom egyébként a fejlesztőket ilyenkor. Arra szabták a motort, hogy a low-level API-val működjön. Az a feldolgozási modell, amit kapott hátrányos DX11 alatt. De a végén leszállítják DX11-gyel a játékot. Akkor mi értelme volt ilyen motort építeni? Sokkal jobb lett volna megtartani a régi feldolgozási modellt, ami nem venné el a sebességet DX11 alatt sem.
Vagy esetleg vannak ennél modernebb modellek is, lásd Frostbite, vagy a Dawn, ami mindkét API koncepcióval működik. -
Abu85
HÁZIGAZDA
Én még nem tapasztaltam ilyet DX12 alatt. Persze az is igaz, hogy béta állapotú DX12 kódon nem játszok, hanem megvárom, amíg végleges lesz.
Egyébként azt tudom, hogy vannak rá panaszok, de sok ilyen problémát okoznak a 3rd party programok. Például az Afterburner nagyon zavarja a DWM működését DX12 alatt. Ebből rengeteg akadás lehet. A DX12 alatt ezeket a programokat el kell felejteni, mert a DWM nem szereti őket, és ma már nem minden DX12 játékba építenek DirectFlipet, mint pár hónapja. Egyre inkább csak DWM-et használ mindenki. Erre lesz megoldás, tehát nem egy végleges probléma ez, mivel UWP alatt elkülöníthető az overlay a programtól, tehát ahogy hagyja el az ipar a Win32-t, úgy vállnak újra használhatóvá ezek az alkalmazások.
-
Abu85
HÁZIGAZDA
Mikroadakások mindenhol vannak. Az, hogy ezt csak az AMD-re vetíted le a saját szegénységi bizonyítványod. Sőt, alapvetően megmutatja, hogy merre halad a világ, hiszen a valós utánajárás helyett egy blődséget talál az ember, és azt terjeszti. Annyiban persze megértem, hogy a valós problémák, mint a WDDM memóriatörlés ára, a shader újrafordítás, stb. olyan dolgok, amelyekhez picit nagyobb hozzáértés kell, így egyszerűbb azt mondani, hogy mikroakadás az AMD miatt van, ha NVIDIA VGA-n fordul elő akkor is.
Miből gondolod, hogy a Pascal számos játékban nem lenne gyorsabb, ha kapna optimalizálást is? Mert egyébként az lenne.
-
Abu85
HÁZIGAZDA
Ez nem olyan egyértelmű, mert OpenGL és DX11 alatt el kell olyan dolgokat viselni, mint a shader újrafordítás, ami egy katasztrófa a játékosoknak, hiszen mikroakadásokat okoz. De persze ha ez így is jó, akkor hajrá.
Nem azért írnak az AMD-re ma motorokat, mert az olyan jó dolog, hanem azért, mert másra nem tudnak optimalizálni. Nem ismerik a hardver működését. Ma már nincs meg az a pénz az iparágba, ami kifutja az architektúránkénti reserve engineeringet. Sokkal költséghatékonyabb az AMD dokumentumait elolvasni, és feltételezni, hogy a többi architektúra is ugyanúgy működik, és ezért nem adnak ki hozzá dokumentációt.
-
#23906
Abu85
HÁZIGAZDA
szmörlock007
#23905
Abu85
HÁZIGAZDA
válasz
szmörlock007
#23905
üzenetére
Mert neked 4 kB-os lapméreteket használ a GPU-d. Nem összehasonlítható a Kepler működésével. Az ID tech 6 megatextúrázója eleve nagyon GCN-re írt rendszer, és a sok Keplernek kedvezőtlen körülmény ahhoz vezet, hogy Kepleren nem elég a 2 GB sehogy sem, míg mondjuk GCN-en elég. De ezt egyébként az ID is írja, hogy NV-n a 2 GB az kevéske.
Más különbség is van. A GCN sokkal gyorsabban dekódolja és tölti be a textúrákat. [link] - ennyit számít, ha egy motort GCN-re írnak.
-
Abu85
HÁZIGAZDA
válasz
proci985
#23900
üzenetére
[link] - a net mondhat sok dolgot, de Jérémy Virga tudja a legjobban. Ő írta.
(#23901) wjbhbdux: Mert az ID tech 6 modelljének nem jó, ha a GPU nem támogatja a 4 kB-os lapméretet. A 64 kB-os lapmérettel túl sok lesz a szemét a VRAM-ban. De 2 GB elég, ha az allokáció 4 kB-os lapmérettel is lehetséges. Sajnos Kepleren nem az.
-
Abu85
HÁZIGAZDA
válasz
proci985
#23898
üzenetére
A VOID-nak semmi köze az ID tech 5-höz. Az ID tech 6-ból lett fejlesztve. Mindegyik ID tech motor vagy ebből átírt motor megatextúráz a Rage óta. Még a Doom is, a mostani Dishonored 2 is, illetve a közelgő új Quake is. De már nem csak ezek a motorok megatextúráznak, hanem például a Frostbite is a 3-as verzió óta.
-
Abu85
HÁZIGAZDA
válasz
wjbhbdux
#23892
üzenetére
Nem mondtam, hogy jó port lesz. A VOID Engine egy csomó PC-s optimalizálást nem kapott meg, amit az ID Tech 6 viszont igen. De a játékot ki kellett adni, mert hoznia kell a pénzt. Majd fél év alatt összerakják, addig ne vegyétek meg. A Bethesda eleve tudta ezt, amikor lelőtték a megjelenés előtti tesztelést. Borzalmasan rosszul áll az összes aktuális projektjük, viszont nem halasztható el a megjelenésük fél évvel, mert benne áll a pénz, illetve a konzolverziók készen vannak. Szarügy, de ez van. A pénz viszi előre őket is, és az év végére tervezet projekteket ki kell adni, akkor is, ha szarok.
A felhasználók tudnak tenni ez ellen. Szavazni kell a pénztárcával, de amíg forró a PC-s pre-order, addig ne várd, hogy ez változzon.
-
Abu85
HÁZIGAZDA
A Summit Ridge ára a legolcsóbb Core i5-től a legdrágább i7-ig fog terjedni. Nyilván nem mind lesz nyolcmagos, mert lehetnek hatmagos verziók is. De előnyben lesz részesítve a több mag alacsonyabb órajel a DX12 miatt, az alsó területeken. Mindegyik modell magonként két szálat futtat, és szorzózármentes lesz, viszont lesznek olyan modellek, amelyek elég drágák lesznek. Ezek pre-tested tuningmodellek.
Core i5 szint alá majd a nyáron lesz APU négy maggal és 16 CU-s IGP-vel. Innen indul és lefelé skálázódik. Itt is mindegyik mag két szálas.
-
Abu85
HÁZIGAZDA
válasz
oAcido
#23872
üzenetére
De engedélyezve van pár AGS 4.0-s függvény abban a játékban, mint például az mbcnt, de ez DX11 alatt is működik. Ezzel az érkező javítással mindkét módba beépítette az Ubi. Végtére is ugyanazt a shadert használja a játék DX11 és DX12 alatt is.
(#23871) Egon: Itt a DX12 kódot nem azért hozták, hogy lényeges gyorsulást érjenek el. A Division egy MMO és nagyon nehézzé teszi a fejleszthetőséget a DX11. Ezért álltak át a DX12-re, mert még igen sokáig kell támogatni, és a tervezett terméktámogatási ciklus alatt lényeges előny származik abból, ha kiszámítható API-t használnak. Ennyi az oka az áttérésnek.
-
#23850
Abu85
HÁZIGAZDA
gainwardgs
#23845
Abu85
HÁZIGAZDA
válasz
gainwardgs
#23845
üzenetére
Az a modell a nagy kiadók szintjén nem hatékony. Fél évtizedig fejlesztenek egy játékot. Egyszer hibáznak és azonnal tönkremennek, mert az eladások nem tudják fedezni a következő fél évtizedes munkát.
-
#23838
Abu85
HÁZIGAZDA
huskydog17
#23837
Abu85
HÁZIGAZDA
válasz
huskydog17
#23837
üzenetére
Nem azzal van a baj, hanem magával a csapattal. A COD-ot összességében bőven 700 fő fejleszti különböző stúdiókban, illetve megbízott cégeknél. Emiatt teljesen kötöttek a motorra vonatkozó fejlesztések, mert ha bedobnak egy olyan leképezőt, vagy árnyalási rendszert, ami módosítja az eddig használt art pipeline-t, akkor hozzávetőleg 400-500 embert kell megtanítani arra, hogy mi módosult, és nekik oktatások után továbbra is tökéletes tartalmat kell előállítaniuk, ráadásul nagyon durván időre, mert novemberenként új COD jön. Na most ez olyan költség lenne, ami felvállalhatatlan. Ugyanakkor főleg az elmúlt három évben nagyon durván fejlődtek, és a jövőben sem számítok másra, mert odavittek olyan szakembereket, mint Michal Drobot, vagy Jorge Jimenez, akik azért nem kis nevek, annak ellenére, hogy nincsenek úgy felkapva, mint mondjuk Johan Andersson.
-
#23836
Abu85
HÁZIGAZDA
gainwardgs
#23831
Abu85
HÁZIGAZDA
válasz
gainwardgs
#23831
üzenetére
Ez elég új motor. Most ért véget a Ghostnál megkezdett fejlesztési stratégia. Bővebben itt: [link]
Tény, hogy nem a legjobb, de tekintve, hogy az Activision milyen mértékű problémákkal küzd meg "az éves szinten egy COD" stratégiával, egyértelműen jó rendszert hoztak össze. Többre pusztán a félelmetesen elszabaduló költségek miatt nincs lehetőség. -
Abu85
HÁZIGAZDA
válasz
gxcman
#23781
üzenetére
A Youtube-on ritka a hiteles és megbízható teszt. Felesleges ott keresni a választ a kérdéseidre. Csak még több kérdés lesz az eredménye. Azok akik értenek ehhez nagyrészt még mindig az írott sajtóban vannak, így a Youtube nagyrészt a nem hozzáértő, de kitörési lehetőségre vágyó emberek kedvelt felülete (tisztelet a kivételnek). Nyilván ez üzleti vonatkozású is, hiszen az írott sajtó a reklámbevételt 100%-ban magánál akarja tartani, tehát nem akarnak a kelleténél nagyobb mértékben nyitni a Youtube felé, mert azzal csak csökkenne a profit. És alapvetően még mindig az írott sajtó tudja megfizetni a szakembereket, mert a Youtube még ma is egy szerencsevadászat.
-
Abu85
HÁZIGAZDA
válasz
mcwolf79
#23775
üzenetére
Ez már nem igazán helytálló. Az IW Engine az elmúlt két évben pont, hogy rendkívül sokat fejlődött. A COD Ghost volt a váltópont, amikor előálltak egy igen nagy felújítással az előző motorhoz képest. Ebben a motorverzióban vezették be a displacement mappingot és a subdivision surface-t, de mivel a korábbi konzolokra is dolgoztak a leképezőt még meghagyták egymenetes forwardnak. Emellett az Activision tipikus problémája, hogy évente kér COD-ot, ezért nem lehet nagy változásokat hozni hirtelen, mert muszáj, hogy a COD mögött dolgozó ~700 fős művészi csapat munkájában megmaradjon a kompatibilitás, így maradt a phong árnyalás is. Ezek miatt a COD Ghost összhatása nevetségesen gyenge volt ahhoz képest, amit mondjuk a Battlefield 4-től láttunk, de mégis rendkívül fontos lépcső volt a motor alapjainak újragondolásához. Ezután a COD: Advanced Warfare ezen a vonalon ment tovább, végre nem volt opció az előző generációs konzol, így a forward leképezőt ugyan nem cserélték még le, de már elkezdődött a PBR-re való átállás, ami egy nagy lépés a művészi munka miatt, ugye ez a ~700 fős csapatra extrém terhet ró. Ez volt a legnehezebb része a váltásnak, ami meglátszott még a COD: Advanced Warfare-en is. De a COD: Black Ops 3-ban már teljes volt az átállás, így leváltották a forward leképezőt deferredre, és tulajdonképpen befejezték a PBR-re való átállást. Ezzel együtt ez volt az a COD játék, ahol a motor fejlesztőeszközeit is újraírták, így beépültek a GI-ra vonatkozó fejlesztések is. Szóval a Black Ops 3 óta a COD alapjául szolgáló IW Engine eléggé újnak és modernnek mondható, legalábbis még csak nem is hasonlít a korábbi verziókra.
Egyébként a Titanfall 2 is igazából csak nevében Source. Olyan sok dolgot átírtak már benne, hogy nem sok köze van ahhoz, amit eredetileg licenceltek.
-
Abu85
HÁZIGAZDA
válasz
Laja333
#23771
üzenetére
Csak nincs benne utasítás-előbetöltés, ahogy a régebbi GCN-ekben sincs, míg a Polarisban van. Emiatt a Polaris jóval hatékonyabb a rosszul optimalizált kódokban. Ez egy nagyon jó indikátor most, mert ami a GCN4-en jó, de a GCN3-on rossz, az rosszul optimalizált játék, hiszen így az utasítás-előbetöltés nagyon dolgozik.
-
Abu85
HÁZIGAZDA
válasz
schawo
#23691
üzenetére
A GPU méret akkor számít, ha ugyanaz a bérgyártó. Elég sok oldalról van adat, hogy a GlobalFoundries szerződése az AMD-nek olyan, hogy ha megvan a wafer rendelésük, akkor még a Samsungnál is sokkal olcsóbban kapják, de ha nincs, akkor utólagos büntetési tételük lesz. Összességében ha nem lesz büntetési tételük, akkor egy 300 mm-es wafert az AMD kb. harmadáron vesz, mint ahogy a TSMC árulja. Ezért tért át az NV a GP107-nél a Samsunghoz, mert így ők most a TSMC-hez képest féláron jutnak waferekhez. A GP107 a TSMC-nél veszteséges lett volna 100-140 dollár közötti árszinten. A TSMC a 300 dollár alatti VGA-khoz szerintem már sosem lesz igazán jó, mert árt a waferáraknak a partnerek versenyeztetése. Nyilván az Apple fogja a legtöbbet fizetni.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#23670
üzenetére
Akármennyire ott van a kód a játékban. A fordító nem ismeri a függvényt. Ergo nem tudja lefordítani. Az a baj, hogy fordítókiterjesztéseket fejleszteni nem egyszerű, mert azokat úgy kell kialakítani, hogy kompatibilisek maradjanak a következő generációs fejlesztésekkel is. Emiatt nem foglalkozott ezzel az AMD 2012-ben, mert a funkció azóta ott van a hardverben. De ugye addig rágták a fejlesztők az AMD fülét, amíg beadták a derekukat. Önmaguktól ezt a munkát a hátuk közepére sem kívánják.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#23635
üzenetére
Az AGS4 nem egy prófécia. Egyszerűen csak egy lehetőség a konzolos optimalizáció PC-re hozására. A Doom és az új Deus Ex támogatja, Vulkan, DirectX alatt programfüggően. Jó a Vulkan alatt nem AGS4-nek hívják, hanem SPIR-V kiterjesztésnek. Nyilván az új Frostbite is támogatja, csak nincs még meg a fordító a driverben, ami lefordítja a konzolon használt, de a PC-n még nem definiált függvényeket, mint például az ordered countot, de nem hiszem, hogy nagyon megdorgálnak ha elárulom, hogy jön még a shader half float kiterjesztés is mindegyik modernebb API-ba, ami a trigonometrikus és egyéb speciális utasítások futtatását kétszeresére gyorsítja. Ezt az Ubisoft és a Bethesda kérte, így valószínű, hogy valamelyik érkező Ubisoft és Bethesda játékban debütál, de persze akárki használhatja. Lehet, hogy beelőzik őket. A Frostbite-nak speciel sokat segítene.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#23630
üzenetére
Hogy megérte-e azt mindenki maga döntötte el. De hogy lényeges előnye volt az biztos, mert például a Fermi akkor jött, amikor már volt 12 darab DX10.1-es játék a piacon, ezek közül 6 DX11-et is tudott, de a lényeg, hogy a DX11-es program DX10.1-ben a gather4 miatt automatikusan 20-25%-kal gyorsabban futott, mint DX10 módban, illetve némelyik alkalmazás kapott extra effekteket is a DX10-hez képet. A GT200-as kártyákon se a sebességet se az effekteket nem érted el DX10-ben, ezekhez a Fermi kellett 2010 áprilisában, vagy még 2009 szeptemberben egy DX11-es Radeon, mert az a DX10.1-et is tudta.
-
#23625
Abu85
HÁZIGAZDA
huskydog17
#23600
Abu85
HÁZIGAZDA
válasz
huskydog17
#23600
üzenetére
Akkor megnézheted, hogy abban a tesztben egy 3rd party program mennyire félreméri a frametime-ot, és a Guru3D fcat mérésében azoknak az állandónagy eltéréseknek nyoma sincs. Persze ehhez kellett, hogy a driver ne csak a DWM-et támogassa, hanem a Directflipet is, így jó lett az fcat, de iszonyatosan látszik, hogy a presentek monitorozása mekkora ordas nagy marhaságot mutat az fcat-hoz képest. Szóval lehet iróniázni, de a valóság az, hogy nekem volt igazam, csak ahogy mindig ciki lenne beismerni.
De a legjobb az lett volna, ha be se számolok róla, hogy a DX12 és a Vulkan API alatt a CPU fps nem sokat ér a késleltésre optimalizált leképezőkkel, és akkor mindenki tudatlanul nyakalná a hibás méréseket. Én hülye azt hittem, hogy segítek eligazodni az új jelenségeken, de csak kiszakítottalak titeket abból az állapotból, amit boldog tudatlanságnak hívnak. -
Abu85
HÁZIGAZDA
válasz
#85552128
#23598
üzenetére
Teljesen felesleges a DX11 és a DX12 összehasonlítása az AGS 4.0 esetében ugyanazt a fordítót használná mindkét API, vagyis ugyanannyit gyorsít rajtuk a shader intrinsics használata. A Doom esetében ez azért volt más, mert a Vulkan fordítója támogatja, míg az OpenGL-hez írt fordító nem. Tehát ha ez beépül, akkor az Xbox One shaderek alapján úgy 10-15% gyorsulást kaphat mindkét mód. De ehhez kellenek még az új függvények, mint az ordered count. Ennek a támogatása nincs benne a driverben.
-
Abu85
HÁZIGAZDA
válasz
velizare
#23575
üzenetére
Az explicit parancskezelésen túl a DX12 mód bindless, így a CPU-terhelés még az erőforrás-bekötés szempontjából is alacsony. Ez főleg a játék végén fog érződni, ugyanis DX11 módban egyetlen hardver sem tud 10-15 fps-nél többet kinyomni zoom outban. A DX12-vel simán megvan a 30-50 fps hardverfüggően. A DX12-ben az AI lépése több szálon lesz számolva, míg DX11-ben ez még mindig egy szálon fut. Tehát DX12-ben nem kell elmenni a játék végén lefőzni egy kávét lépésenként. A motor szoftveres raszterizálással dolgozik, ami DX11-ben eszi a hardvert, de DX12-ben az aszinkron compute miatt ingyenes. Multiadapterre pedig egy alacsony késleltetésű mód lesz beépítve, aminek az SFR az alapja, de ki van egészítve némi temporális átlapolással.
-
-
Abu85
HÁZIGAZDA
válasz
#85552128
#23567
üzenetére
Benne van, legalábbis a 1398924-es buildben: "../Base/Binaries/Win64Steam/CivilizationVI_DX12.exe"
Kérdés, hogy melyik build lett a publikus. Gondolom a teszteléstől is függ, mert nagyon sokban különbözik a DX11-es mód a DX12-estől. A multiadapter mód is teljesen más, mint a DX11-es CF/SLI.
-
Abu85
HÁZIGAZDA
válasz
Crytek
#23549
üzenetére
Nyilván a DX12 kód erősen többszálú, így egy 8 magos procin nagyobb előnyt tud biztosítani a DX11 kódhoz, mint egy erősebb négymagoson. Pusztán a skálázás lehetősége miatt. Emiatt az egy szálú teljesítmény kevésbé domináns, mint DX11-ben, amiből minden rendszer képes profitálni. Hasonlóan viselkedhetnek a kevésbé erős négymagosok is.
Az Intel gyors négymagosával a skálázásból nyert teljesítmény kevésbé domináns, így inkább a hátrányok jönnek elő. A Frostbite alatt ez a GeForce-okat különösen érinti, mert a motor nem tud UAV-t menteni a root signature-be, illetve az NV egy extra másolásra kényszerül, amikor a compute shader adatot ír ki. Az AMD-t bekötési modellje jobban illeszkedik a DX12-höz, így nem zavarja, ha a root signature-ben nincs UAV, illetve a konstans puffer elérése pont ugyanolyan gyors, mint más pufferé, vagyis nem kell másolgatni a compute shader adatkiírását. Emiatt az AMD DX12 alatt gyorsulni tud a DX11-hez képest minden körülmény esetén.
-
Abu85
HÁZIGAZDA
válasz
schawo
#23547
üzenetére
Arra ez nincs hatással. Itt nem rések vannak, hanem tökéletsen kihasználatlan részegységek. Ezek malmoznak, amíg a képkocka számítása befejeződik. Ezeket ezzel a módszerrel befogják, hogy ne csak várjanak ölbe tett kézzel, hanem dolgozzanak. Ez a GPU-k tipikus problémája, hogy nagyjából ~20 elemből álló heterogén processzorok, és ezek az elemek egymástól teljesen függetlenül képesek lennének működni, ha különállóan etetné őket az API. Erre találta ki a Microsoft a multi-engine-t, illetve a Khronos a queue family-t.
Még egyszer kihangsúlyozom ez nem újdonság. Konzolon több tucat cím alkalmazza évek óta. PC-n még csak három, de az látható, hogy nagyon terjed.
(#23548) Szaby59: Nem. Amiatt akadt be, mert a DX12 memóriamenedzsment szemetelt a programban. Megjelenésre kap egy fixet, illetve ehhez kell új driver is.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#23544
üzenetére
Mint írtam ilyen trükköt a Doom, az új Deus Ex és a Battlefield 1 használ. Amelyik játék nem használ ilyen trükközést, ott nyilván nem sok eltérés lesz a CPU és a GPU fps között.
(#23546) Szaby59: Egyik sem. Pont azért, mert a CPU fps a trükközés miatt nem amúgy is pontatlan lenne, úgy meg minek jelezni azt?
Szerk.: Nem értem mit akarsz bizonyítani? Vagy arra gondolsz, hogy a motorokból azért hagyták ki ezeket a méréseket, mert valamit el akarnak titkolni. Nem hiszem, hogy így lenne. A Microsoft se hívná fel erre a figyelmet.
CPU frame-t persze közöl a Frostbite, de nem present-to-present, hanem t_game-to-t_present mérést. -
Abu85
HÁZIGAZDA
válasz
schawo
#23541
üzenetére
Hamarabb elkezdhető a következő képkocka számítása. Ezzel hamarabb lesz eredmény is. Ergo összességében csökken a késleltetés.
Az efféle trükközés miatt a CPU fps más lesz, mint a GPU fps. Régen ez majdnem megegyezett, mert két present között eltelt ms kb. hasonló a frame számításának ms-ban mért idejével. Ma lehet olyat csinálni, hogy a presentek közötti ms eltérjen a frame számításához szükséges időtől, hiszen tulajdonképpen konkrétan az a trükk, hogy a presentek meghívásával játszol, hogy hamarabb végezzen a tényleges képszámítás. Ez azért éri meg, mert a GPU egy heterogén processzor. Bőven dolgozhat már az új képen az egyik része, amíg a másik része befejezi az aktuális képet. Ezek a részek az átlapolás nélkül nem dolgoznának párhuzamosan.(#23542) proci985: Az jó megoldás.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#23539
üzenetére
De érted magát a problémát? A 3rd party program explicit API-val nem megbízható. Teljesen más eredményeket közölhet, mint a valóság. Azzal nem megyünk sokra, hogy később a Guru3D leírja, hogy elbaszták. Ettől a 3rd party programok megbízhatósága nem nő.
Igen, ez elég nehéz, de ha pontos eredményt akarsz, akkor jelen pillanatban nincs választás. Talán fél vagy egy év múlva fejlesztenek egy sokkal jobb 3rd party mérőprogramot, ami minden lehetséges problémát figyelembe vesz, mert amúgy ez nem lehetetlen, de addig meg vagyunk lőve.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#23534
üzenetére
Dehogynem. Bár másik 3rd party mérőprogramról volt szó, de az ExtremeTech is írt arról, hogy ez nem olyan egyszerű, mint a régi rendszer. [link] - itt konkrétan a Guru3D mikroakadást mért, de valójában nem volt mikroakadás, csak az FCAT nem működött úgy, ahogy kellett volna. Viszont a valós output jó volt! Ezért kell programon belüli mérőt használni DX12-ben!
Sajnos nagyon kevesen néznek utána, hogy hogyan működik az explicit API. Még a Microsoft ajánlásait sem olvassák el. Egyszerűen csak nyakalják be azt a számot, amit a 3rd party program kiköp, és fel sem merül senkiben, hogy az esetleg nem jó. A boldog tudatlanság ugye. Nekünk is sokkal egyszerűbb lenne. Lemérnénk 3rd party programmal, és szarnánk bele, hogy az igaz-e vagy sem.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#23532
üzenetére
Sokan nem értik, hogy mi az a multi-engine. A present akármelyik parancslistán meghívható, ha az előnyös. A Radeonon számos programban engedélyezett opcionálisan a compute parancslista, ha az az adott képkocka számítása esetében előnyösebb, késleltetést csökkentő aszinkron compute implementáció például. Persze lehet, hogy nem előnyös, és akkor nem ott hívja meg. Ilyen a Doom, az új Deus Ex, illetve a Battlefield 1 is. Na most a 3rd party monitorozó nem képes ezt lekezelni, mert nem ismeri, hogy az adott játék konstrukcióját. A sebességet ~10%-os hibaaránnyal meg tudja mérni, de képtelen lesz valós frametime-ot felállítani, ha nem látja az összes present hívást. Mivel ezek átlapoltak az egész egy összekuszált frametime lesz. Ennyi.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#23528
üzenetére
Erre már adott megoldást a Microsoft. A mérőmodul úgy is be van építve minden motorba, így azt ajánlja a cég, hogy legyen felvehető a játékmenet. Ennyit kell beépíteni csak.
De egyébként az explicit API-k fejlesztésénél még csak tárgyalni sem tárgyalták azt a szempontot, hogy a benchmarkolás legyen-e egyszerű. Millió egy nagyobb, megoldásra váró probléma volt a rendszerrel.(#23529) Raggie: Az NV-n is félremérhet egy 3rd party program. Ez egy szoftverben keletkező probléma, persze hardverfüggő a hatása, de alapvetően nem válogat a gyártók között. A legjobb módszer, amit a Microsoft mond. Beépített mérőmodul és felvehető játékmenet.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#23525
üzenetére
DX11-ben csak present időket mérhettél. Azért a bármitől az nagyon messze van. Sokszor nem is pontos ez az eredmény. Egyébként programra levetítve itt is van esély rá, hogy a present időket normálisan lehessen mérni, mert természetesen írható egy olyan 3rd party alkalmazás, ami figyelembe veszi az adott játék működését, és az játékon belül a hardverek kategorizálását. A probléma az, hogy senki sem fejleszt ilyen programot játékonként lebontva, mert azt karban kell tartani, és minden patch után ellenőrizni kell, hogy mi változott, azaz a program továbbra is hiteles eredményeket közöl-e. Ezért mondja a Microsoft, hogy csak a programon belüli mérőmodul a hiteles.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#23522
üzenetére
Ha arra gondolsz, hogy általános 3rd party programmal nem biztos, hogy pontos lesz az eredmény, akkor igen. De ez alapvetően az explicit hozzáférés és a multi-engine modell átka, semmint egy szándékos limitáció a DX12 és a Vulkan alatt. Másfelől viszont vannak előnyei is. Amíg DX11 alatt csak CPU oldali fps-t mérhettél (t_present-to-t_present), addig az explicit API-kkal ténylegesen mérhető a t_game-to-t_render idő is, vagyis pontosabb lesz az eredmény, amit az alkalmazás közöl. A hátrányok mellett tehát vannak előnyök is. Nem csak CPU fps-t lehet közölni, hanem GPU fps-t is. Mi a tesztjeinkben DX12-vel már ezt közöljük.
-
Abu85
HÁZIGAZDA
válasz
schawo
#23518
üzenetére
Nem a proci a probléma, hanem a mérőprogram. Ezeket sajnos el kell felejteni, mert a DX12 és a Vulkan nem single-engine API. Ha az adott mérőprogram nincs konkrétan a mért programhoz szabva, akkor teljesen fals eredményeket adhat. Annyira alacsony szintű a működés, hogy egy általánosan, csak a grafikai presentek érzékelésére kialakított program azt képtelen jól mérni. Arra számít, hogy csak ott lehet presentet meghívni, közben ez hardverenként eltérő lehet.
A játékokba épített mérők tudják, hogy melyik hardver hogyan működik, így annak a működésnek megfelelően el tudják dönteni, hogy a több present hívás között ténylegesen mettől meddig tart egy frame számítása. Erre egy 3rd party program sajnos képtelen. -
Abu85
HÁZIGAZDA
válasz
mlinus
#23517
üzenetére
Egy GPU-val nincs frame pacing.
Párszor leírtam már, hogy DX12 és Vulkan alatt 3rd party programmal mérni a legnagyobb hiba, amit el lehet követni egy tesztelés során. Erre kis túlzással mindenki felhívta már figyelmet, mert ezek az API-k nem single-engine rendszerek.
Volt már ilyen grafikon a Guru3D által, aztán kiderült, hogy az egész egy programhiba. [link] - a valóságban a megjelenítés jó volt.Nagyon jól mondja a Microsoft, hogy a DX12-ben (és persze a Vulkanban, csak erre nem térnek ki) csak a direkten az alkalmazásba épített mérőkkel szabad bármit is mérni. Az a mérőmodul ugyanis ismeri az alkalmazást, míg egy 3rd party opció sajnos nem.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#23512
üzenetére
A GoW4-ben az aszinkron compute opció változtatható a Pascal és a GCN architektúrára. A többinél ki van szürkítve, de az is lehet, hogy magát az opciót sem ajánlja fel. Az biztos, hogy csak az említett két architektúrára aktiválható, ezt a Microsoft megerősítette, amikor kérdeztem őket erről.
A PC-re kialakított implementáció a jellege miatt nem segít sokat a sebességen. A legtöbb játék az aszinkron compute-ot compute shader offloadra használja, míg a GoW 4 ilyen formában ezt a funkciót csak Xbox One-on használja. PC-n a többletterhelést próbálja csökkenteni, amivel nem igazán lehet 2-3%-nál többet nyerni. Ez még a Rise of the Tomb Raiderben helyet kapó implementációnál is alacsonyabb határfokú. De szó se róla gyengusabb procikkal tényleg segít egy picit. -
Abu85
HÁZIGAZDA
válasz
schawo
#23510
üzenetére
Láthatod, hogy nem azon múlik, hogy melyik VGA-ban nem lesz, hanem sokkal inkább azon, hogy aktív-e. A Maxwell és a Pascal is támogatja ezt a funkciót, de a meghajtó rendre letiltja a DX12-es játékokra.
Az a baj az aszinkron compute-tal, hogy nem olyan egyszerű a hatékony hardveres implementációja, hogy csak beraksz a lapkába pár független compute parancsmotort, esetleg csinálsz még egy előre definiált statikus particionálást alkalmazó üzemmódot rá. Igen alacsony szinten kell a rendszert beépíteni, ami majdhogynem teljes újratervezést igényel. Amíg ez nem történik meg, addig a funkció támogatható, de előny ebből nagyon korlátozott formában lehet. -
Abu85
HÁZIGAZDA
válasz
schawo
#23508
üzenetére
Ez most nem olyan egyszerű. Az Intel bácsi is látja, hogy az új API-kkal nem az IPC vagy a magszám fog nyerni, hanem az egyensúly. Ez nagyon megnehezíti a fejlesztést. Emellett pont az Intel bácsi mondta nemrég, hogy nem tudják, hogy miket raknak át a játékfejlesztők a tipikus munkafolyamatokból a GPU-ra. Például megemlítették, hogy a Nitrous új verziója más minimum magszámot igényel, ha van aszinkron compute a GPU-n és több mag kell, ha nincs. És ezzel a lehetőséggel többen élhetnek, ami megint nehezíti a processzortervezőket. Többek között ezért hoz az Intel mainstream platformba hatmagost, mert aszinkron compute nélkül a Nitrous minimum igénye hat mag lesz.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#23506
üzenetére
Már most is van ilyen játék, ami három-négy magot igényel minimum.
Általánosságban egyébként azért lesz minimum a négy mag, mert az új API-kkal a skálázás megoldása mellett szereztünk egy új problémát. Ahhoz, hogy ez az explicit parancspufferes modell skálázódjon az kell, hogy a motor job rendszerű legyen, vagyis nincsenek előre leosztott szálak, hanem munkák vannak, és van egy mag, ami ezeket a munkákat kezeli a maradék magokon. Ez egyrészt addig jó, amíg van minimum három magod, mert abból egy csinálja a menedzsmentet, kettő pedig csinálja a valós feldolgozást. Ha két magod van, akkor az azért hátrányos, mert nincs mit menedzselni. Egy mag marad a valós munkára, és egyet pedig elvisz az a menedzsment, hogy minden munka legyen berakva arra az egy szem magra. Emiatt tiltják a fejlesztők ezeknél a job motoroknál, hogy két szállal elinduljanak. A szoftverstruktúra olyan, hogy biztosan rosszul futna.
-
Abu85
HÁZIGAZDA
válasz
schawo
#23503
üzenetére
A GPU egyáltalán nem úgy működik, mint egy CPU. Lehet beszélni itt is IPC-ről, csak nem érdemes.
Ezek a lapkák igen komplex heterogén feldolgozók, míg egy CPU jóval egyszerűbb homogén feldolgozó.(#23493) Yutani: Itt azt kell látni, hogy a következő évben a programok zöme igényli a négy magot, tehát mindenképpen négy szálat kell adni a prociknak. Enélkül egyszerűen nem fognak elindulni. Az mindegy, hogy egy kétmagosban meglenne az erő a programfuttatáshoz, akkor sem fog rajta elindulni, amíg nincs négy szál.
-
Abu85
HÁZIGAZDA
SLI és CF nincs DX12 alatt. Helyette van multiadapter. Ennek vannak implicit és explicit formái. Explicit formában a memória összeadódik, hiszen egyedileg van kezelve a két adapter. Ilyen formában lehet gyártókat is vegyíteni, de ezt engedélyeznie kell a fejlesztőknek. Ilyen rendszert használ az Ashes of the Singularity. Simán explicit multiadapter (gyártói keverés nélkül, de a memória összeadásával) a Hitman és a Deus Ex: Mankind Divided konstrukciója. Implicit módszert alkalmaz a Total War: Warhammer, a Rise of the Tomb Raider és a Gears of War 4. Ezek hagyományos AFR-ek, és így nem adódik össze a memória.
A DICE nem tudni, hogy melyiket választotta.
-
Abu85
HÁZIGAZDA
válasz
Venyera7
#23475
üzenetére
DX11-ben se. Csak a shadereket szállítják, de a fordító még nem ismeri az ordered countot, stb. Szóval ide kell egy új driver, ami tartalmazza a megfelelő fordítót.
(#23476) Szaby59: Persze, hogy ott van. DX11-ben ez a leképező nem működne, ha nem lenne multi draw indirect szállítva AGS-en és NVAPI-n keresztül. De Gollo a shader intrinsics-re gondolt, amihez nem kell dll, hanem shader és fordító szükséges.
-
#23470
Abu85
HÁZIGAZDA
Szeszkazán
#23466
Abu85
HÁZIGAZDA
válasz
Szeszkazán
#23466
üzenetére
A Frostbite-ra ez nem igaz. Ez a motor új fejlesztés, a DX12-re írva. Gyorsít is a Radeonon, még aszinkron csodák nélkül is. Arról a DICE nem tehet, hogy az NV architektúrája nem általánosra van tervezve. A GeForce-ok DX11 alatt azért gyorsak sokszor, mert egy csomó sűrűn használt írási folyamatra, vagy pufferelérésre van speciális gyors hozzáférés, amivel lerövidíthető az az idő, ami a feldolgozáshoz kell. Ellenben az általános adatutak jóval lassabbak, vagyis amit megnyernek a speciális adatutakon, azt elveszthetik az általánosokon. DX12-ben ez látható, mert ez az API rengeteg ilyen speciális adatelérést tesz lehetetlenné, vagyis ellehetetleníti, hogy a GeForce úgy működjön, ahogy a hardvert tervezték. 5-6 év múlva sem tudnak majd ezzel mit kezdeni, mert ez nem programozásbeli, hanem hardveres gond.
-
Abu85
HÁZIGAZDA
Ehhez még a compute culling is hozzájön, amire láttunk már például a Hitmanben és a Deus Ex Mankind Dividedben. A Frostbite azonban eltérő módot használ NV-n, mert amíg AMD-n és Intelen strukturált pufferbe dolgoznak, addig NV-n konstans pufferbe. Ennek jó oka van, mert a Hitmanben és a Deus Ex Mankind Dividedben látszik, hogy az NV mennyire belassul, ha strukturált puffert kell használni, csak éppen a compute shader hátránya, hogy konstans pufferbe eleve nincs írási joga. Viszont ezt a Frostbite új verziója úgy oldja meg, hogy strukturált pufferbe ment NV-n, majd azonnal átmásolja az adatokat a konstans pufferbe. Az aszinkron DMA miatt ez eléggé olcsón megúszható. Viszont ez is lassít, csak éppen nem annyit, amennyit a Hitman és a Deus Ex Mankind Divided konstrukciója.
-
Abu85
HÁZIGAZDA
Nincs engedélyezve. Többször leírtam már, hogy a bétában egy rakás dolog nem aktív, mert nincs kész, ezért van béta ráírva.
Az alap DX12 pedig gyorsít a Radeonokon, annak ellenére, hogy még nem aktív az aszinkron compute. NV-n azért nem gyorsít, mert a GeForce-ok még mindig slotalapú architektúrák, így a root signature modell csak akkor jó nekik, de direkten a root signature-be lehet helyezni az UAV-ket. A Frostbite új verziója alatt ezt nem lehet megtenni, mert egyrészt több UAV van, mint 64, másrészt olyan formátumokat használ, amelyeket a root signature nem támogat. Az NV-nek a motor működéséhez három leíróhalmaz kell, míg az AMD-nek és az Intelnek elég egy. Ettől lassul NV-n.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#23433
üzenetére
Oké, akkor levezetem, de elég bonyolult a dolog. A hardver szempontjából az a helyzet, hogy többféle igénye van a HDR-nek. Három nagy csoport van, videó, kép és játék.
A videók esetében csak az NV Pascal és az AMD Polaris a jó. Mással ne is próbálkozz.
A képek esetében kedvezőbb a helyzet, mivel elég, ha a kijelzőmotor megfelel az alapvető HDR igényeknek, így NV-től ezúttal is csak a Pascal a jó, de az AMD-től jó lesz a 400, a 300, a Nano és a Fury is. Utóbbit azért érdemes kihangsúlyozni, mert a 200-as Radeonok már nem jók, mivel a régebbi kijelzőmotort használó lapkaverziók vannak beépítve.
A játék esetében a helyzet elég bonyolult. A Microsoft Windows 10-be épített szabványos csomagjával ugyanaz az igény, ami a képeknél, tehát jó az NV Pascal, míg az AMD-től a 400/300/Nano/Fury. Ugyanakkor vannak gyártói SDK-k is, amelyek nem annyira kötöttek, így nagyon specifikusan implementálva, csak és kizárólag exkluzív fullscreen módra megoldható, hogy működjenek azok a VGA-k is, amelyek hivatalosan nem jók, pontosan gondolva itt a második generációs Maxwellre, és némelyik 200-as Radeonra (Hawaii, Tonga, Bonaire). Ezeket azért nem verik nagy dobra, mert specifikus támogatást igényel a program oldalán, tehát nem mondhatják általánosan ki, hogy ezekkel a hardverekkel is menni fog a HDR, mert vagy megy vagy nem. Például sima fullscreenben vagy ablakban tuti nem fog menni, illetve bizonyos régebbi OS verziókkal sem. De amúgy ja, írható olyan specifikus támogatás, amivel ráerőltethető a HDR kijelzőre a HDR úgy is, hogy a hardver hivatalosan nem szerepel a HDR-re képes termékek listájában, és a szoftverkörnyezet is pont jó a HDR működéséhez.
A többi nem említett GPU semmilyen formában nem képes erre.A full hivatalos és amúgy teljesen általános álláspont a gyártók részéről az, hogy a videók csak Pascal és Polaris hardvereken mennek, míg a képek és a játék csak NV Pascal GeForce-okon és AMD 400, a 300, a Nano és Fury Radeonokon. A vagy megy vagy nem hardverekre nehéz hivatalos és általános álláspontot kialakítani, ezért ezzel a gyártók nem is törődnek. Nem tudnák érthetően elmagyarázni, hogy mitől fog menni és mitől nem, inkább azt mondják ezekre a hardverekre, hogy nem jó.
-
#23421
Abu85
HÁZIGAZDA
huskydog17
#23417
Abu85
HÁZIGAZDA
válasz
huskydog17
#23417
üzenetére
Valójában a mostani HDR support is teljes. A probléma ezzel nem az, hogy nem működik, hanem az, hogy mi az ideális tone map futószalag, ami jó HDR-re és jó HDR nélkül is.
Nézd a kimenet kezelésének problémájával az egészet. A játék FP16-ra képez le, ami 0 és ~65000 közötti átmenetet jelent. Na most ezt kell úgy kiküldeni a kijelzőkre, hogy azok egy részének ~500 körüli nitig terjed a jeltartománya, míg a HDR-es opcióké ~10000 is lehet. Egyelőre nagyon kevés az adat ezen a területen, hogy egyszerre jó minőségű legyen mindkét kijelzőtípusnak a kezelése. Ezt persze a tapasztalat meg fogja oldani a következő évben, ahogy egyre többet játszanak a fejlesztők a HDR-rel, és közben megosztják a kutatásokat. -
Abu85
HÁZIGAZDA
válasz
#85552128
#23418
üzenetére
A HDR mindegy, hogy ki hozza. A lényeg, hogy jöjjön. Az egész nem igényel radikális fejlesztést. Kivéve az elavult motorokban. Ott eltart egy-két hónapig a beépítés, de a modern motorokban kb. egy hét munka az egész. Ezután megfelelő kijelző mellett, Windows 10 alatt működni fog minden Radeon 300, Nano, Fury és 400, illetve GeForce 1000 sorozatú VGA-val. Az eredmény ugyanaz lesz.
-
Abu85
HÁZIGAZDA
válasz
Venyera7
#23390
üzenetére
Azt nem fogja elérni. Meg azt is bele kell számolni, hogy a Pascal architektúrát, illetve az NV hardvereket ez az új Frostbite ma nem kezeli jól. Például használ olyan UAV formátumokat is, amelyeket nem lehet direkten a root signature-be kötni, ami az NV-nél gáz, mert csökkenti a pixel shader hatékonyságot. Aztán elég sok már a compute futószalag is a motorban, és emiatt vissza van fogva a konstans pufferek használata. A Pascal főleg azért gyors, mert a hardverben van egy huzalozott gyors elérési lehetőség a konstans pufferre, de amint ezt nem tudja használni, a teljesítménye esni kezd. Ilyenje van a Maxwellnek is, csak nem olyan jó, mint a Pascalé, illetve a Pascal tervezésénél az NV feláldozta az általános pufferekből való olvasási teljesítményt a gyorsabb konstans pufferért, míg a Maxwellnél ez még relatíve gyors volt.
-
#23387
Abu85
HÁZIGAZDA
gainwardgs
#23385
Abu85
HÁZIGAZDA
válasz
gainwardgs
#23385
üzenetére
Nem tudom, hogy melyik a látványosabb. Azt tudom, hogy le vannak tiltva még a nem stabil eljárások és optimalizálások. De ezeket folyamatosan tesztelik és a megjelenés előtt aktívak lesznek. Tehát végül majd ugyanaz lesz a képminőség.
A végső verzióban főleg a DX12 változik. Aktív lesz az async compute, a multiadapter, és valószínűleg megjelenésre még aktiválják az AGS 4.0-t is, de ez nem prioritás.
-
#23384
Abu85
HÁZIGAZDA
gainwardgs
#23382
Abu85
HÁZIGAZDA
válasz
gainwardgs
#23382
üzenetére
Most lehet, mert még nem aktív minden. De a végső verzióban nem lesz.
-
-
Abu85
HÁZIGAZDA
válasz
wjbhbdux
#23347
üzenetére
Nem. A CoD egy IW kódnévű, saját fejlesztésű motort használt.
(#23349) Peat: Az UE4 most sem igazán mutatta meg, hogy mit tud. Ez a Microsoft által módosított verziója, nagyon durván módosított. A leképező 90%-át átírták, mert az eredeti leképező rengeteg limitációt használt a mobil irány miatt. A Microsoftnak ezekre nem volt igazán szüksége. A GoW 4 úgy sem jön Windows Phone-ra.
Az UE4-ről sosem tudjuk meg, hogy mit tud, mert az Epic nem fejleszti a PC-re írt leképezőt. Csak a mobil leképezőre koncentrálnak. Ezért vannak olyan limitációk benne, hogy nincs támogatva a multi-GPU. Ezt a limitációt például a Microsoft kiműtötte belőle, és egy patch-ben lesz is haszna.
-
#23346
Abu85
HÁZIGAZDA
FollowTheORI
#23342
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#23342
üzenetére
Még igen, de vannak már elég erős kihívók. Egy idő után mindenkinek korlátozó lesz a felhasznált asset pipeline-nal való kompatibilitás megőrzése. Ez főleg jellemző a nagy kiadókra, mert ők készítenek egy motorra évente legalább fél tucat játékot, és a vezetőségben baromira ütik a piros gombot, amikor a technikai csoport azt mondja, hogy előreléphetünk, ha eldobjuk a kompatibilitást az aktuális asset pipeline-nal. Nagyon tipikus például a LABS olyan rendszert fejleszt, amely igazából egy öszvér megoldás, de végeredményben működik és kompatibilis az aktuális eszközeikkel.
Ha az aktuális asset pipeline nem számítana, mindenki menne texel shadingre. -
Abu85
HÁZIGAZDA
válasz
daveoff
#23335
üzenetére
A Frostbite-tal egyértelműen nem veszi fel a versenyt, de a Frostbite a legtöbb motornak egy utópia, főleg az új verziója, ami szoftveresen implementált GPU-val gyorsított kivágást. Az Unreal Engine 4-nek a Microsoft csak a leképezőjét írta át jóval optimalizáltabb formára, meg persze megszüntették azokat az eljárásokat, amelyek megakadályozzák a több GPU-s rendszerek támogatását, de a motor alapvető működési koncepciója nem igazán változott. Továbbra is egy klasszikushoz közelítő deferred render technika csak a temporális rendszerek nélkül. Ez a klasszikus alap 2002-es kutatásokra épül, míg a Frostbite jóval újabb rendszer, amit 2010 körüli kutatásokra húztak fel. Na de persze a Frostbite hátránya is, hogy mobilon meg sem moccan, míg az Unreal Engine 4 még ezzel a klasszikus deferred leképezővel is megy az új Androidon. Szóval van itt azért pro/kontra érv.
-
Abu85
HÁZIGAZDA
válasz
olymind1
#23315
üzenetére
Nem érdekes a Microsoftnak a GCN. Van egy koncepciójuk, és annak valóban a GCN felel meg a legjobban, de amint lezárják a specifikációt, mindenki látni fogja, hogy erre kell menni és hozzák a hasonló architektúrákat. Valóban felmerült egy rakás helyen az előzetes specifikációkat látva, hogy a wave ops intrinsics egy GCN-barát konstrukció, de nem azért kerülnek bele az egyes függvények, mert azok a GCN-nek jók, hanem azért, mert hasznos maga a függvény, az a funkció, amit ellát. Hardvert tervezni pedig úgyis tud hozzá a többi cég. Ezeket a függvényeket amúgy lehet úgy is támogatni, hogy a hardvert nem készítették fel rá. Nem mondom, hogy hatékony lesz, de a kód működni fog.
-
Abu85
HÁZIGAZDA
válasz
oAcido
#23310
üzenetére
Igen. Ez egy nagyon fontos szempont, mert az AGS4.0 ma még csak GCN only, ami hosszú távon nem jó. De a legfőbb előny, hogy hozható legyen a konzolos optimalizáció. Nagyon sok játéknál az a baj a multiplatform fejlesztés során, hogy van a motornak egy saját nyelve, amiből shadereket fordít a célzott platformokra. PS4-re PSSL-t, Xbox One-ra azt a HLSL-t, amit az MS erre a gépre specifikál, míg PC-re a szabványos HLSL-t (5.1-es verziót). Na most a fordító PSSL-re és XO HLSL-re alapvetően nagyon optimalizált, mert ebbe ölik a pénzt a fejlesztők, de a PC-s HLSL-re már semennyire nem az, ezért hiába ugyanaz a kód a legmagasabb szinten, a teljesítmény amit a konzolokra át tudnak vinni, az a PC-n a szabványos HLSL 5.1-re fordításnál elveszik. Nagyon kevés motor esetében van jó minőségű fordítás ebből a szempontból. A shader model 6.0 bevezet egy új HLSL verziót, ami pontosan ugyanaz lesz Xbox One-on, mint PC-n. Ez nem jelenti azt, hogy a PC-s shader innentől kezdve alázni fog, mert azért ott van az a probléma még mindig, hogy a gyártók architektúrái különböznek, de annyit elér a shader model 6.0, hogy a legfelső fordítási szinten nem fog elveszni az a rengeteg teljesítmény, ami ma sok programban elveszik.
(#23313) olymind1: Nincs különösebb szükség a vertex, geometry, pixel shader lépcsők drasztikus modernizálására. Amit maga a nyelv hoz, azt részben vagy teljesen megkapják. A pixel shader biztos, de nagyjából ennyi. Ha valami olyan igény van, amire esetleg nem jó egyik specifikus shader lépcső sem, akkor ott a compute shader, ami tuti biztos, hogy jó lesz. Emiatt a specifikus lépcsőkhöz mér nem éri meg hozzányúlni, olyan sokat úgy sem tudnak egyik sem, amennyit a compute shader tud.
-
Abu85
HÁZIGAZDA
Az AMD-nek egyáltalán nem probléma ez. Nekik minél több eladás kell. Mindegy, hogy hova veszed a VGA-d. Az AMD-nek magával a piac fejlődésével sincs problémája, mert nagyjából az történik, amire számítottak. A PC-s fejlesztések teljesen leálltak, és minden kutatás a konzolra összpontosul. Emiatt csinálták meg a GPUOpent, hogy ha már a PC-s fejlesztéseket nem tudják újraindítani, akkor legalább a konzolos kódokat áthozassák a fejlesztőkkel. Ez igen jól működik, mert Vulkanra ez elérhető volt májusban és rögtön használta is a Doom, míg DX12-re elérhetővé vált szeptemberben és azonnal jött rá egy Deus Ex MK patch. Nekik az sem számítana, ha nem jönne a shader model 6.0, mert így is tudják másolni a konzolos kódot a fejlesztők. Utóbbi leginkább a Microsoftnak és a többi gyártónak fontos, mert ezekből a kódokból nem tudnak profitálni.
-
Abu85
HÁZIGAZDA
Ennél a PC problémája sokkal bonyolultabb. Arra kell megoldást találni, hogy a kutatások ne a konzolra történjenek meg, mert abból a PC nem tud jól profitálni. Ezért indult minden irányból a lehetőségek keresése. A GameWorks, a GPUOpen, és a Shader Model 6.0 egy reakció az eseményekre. Más a megközelítés, de a cél az, hogy PC-n is jól működjön a port. Nem mintha mindig összejönne ez, de próbálkoznak.
Hosszabb távon a GameWorks kezd problémákba ütközni, mert hiába ad az NV PC-re optimalizált kódot, ha a motor kialakítása olyan, hogy azt nem lehet jól beépíteni. Ez egy zsákutca így.
A GPUOpen hasonlóan problémás, mert bár lehetőséget ad a konzolra írt kódok direkt áthozására, de csak az AMD-re működik. Rendben van, hogy a nagy stúdiók, mint az ID, a Dice, az Eidos számára ez hasznos, de PC-re gyártófüggetlen alap kell.
A Microsoft emiatt döntötte el pár éve, hogy összevonja a PC és a konzol nyelveit, így a PC direkten profitál minden konzolos kutatásból. Ez lesz a Shader Model 6.0. Na innentől kezdve a fejlesztés oldalán a PC már nem egy elszakított mostohagyerek lesz, hanem a konzolos kutatások része, mint egy alternatív platform. -
Abu85
HÁZIGAZDA
Az a nagyon érdekes a GoW4 kapcsán, hogy ehhez az eredményhez majdnem a 90%-át kellett átírni az UE4 leképezőjének. Szóval alap szinten az csúnyán nincs rendben
, viszont a Microsoft csapata megcsinálta. Az egyetlen baj, hogy ezt biztos nem írják vissza a main branchbe. A korábbi gyakorlattal ellentétben ezt a leképezőt és a hozzá készült struktúrát a Microsoft megtartja magának. Pedig amúgy jó lenne visszaírni, mert az eredeti leképező nem támogatja a multi-GPU-t, míg ez képes rá, noha még nincs engedélyezve.
Érdekesség, hogy nulla GameWorks effekt van benne. Kihajították mind az első rész remake-je után.(#23194) oAcido: Specifikus dolgokkal csak Xbox One-on foglalkozik a Microsoft. SM6.0 viszont jöhet hozzá, mert csak át kell másolni PC-re az Xbox One shadereket.
-
Abu85
HÁZIGAZDA
Ez viszont nem menti fel őket attól, hogy a minta mennyiségét közöljék, ahogy a JPR is állandóan közli, noha nem mindig teszik lehetővé azt, hogy ezt az információt publikusan beleírjuk a hírbe. Ugyanakkor a Steamnek nincs egy fizetős része, ahol ezt az információt elérhetővé teszik. Ha pedig magyaráznunk kell, hogy miért bújnak ki a statisztikára vonatkozó szabályok alól, akkor az már rossz. De ezt pontosan tudnod kell, ebből érettségiztél.
(#23173) schawo: Honnan tudjuk? Ki mondta? Sehol nem közlik a minta méretét.
Hamisítani biztos nem hamisítanak. Egyszerűen csak hiányos az egész, alapvető információk hiányában. De a Steam ezt publikus formában egy marketingeszközként használja, nem tájékoztatásra.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#22987
üzenetére
Persze. A DX11 csak egy leképező a motor mögött. Eleve támogatta a motor. Tehát csak annyit kellett csinálni a Steam portnál, hogy az UWP API helyett a Win32 API-ra ültetik, na meg persze meg kellett kerülni azokat az eljárásokat a leképezőnél, amelyeket a DX11 nem támogat. Erre vannak gyártói kiterjesztések. A DX12 módot is képesek áthozni, ha a Steam megengedi az UWP API-s programok futtatását. Ezt biztos nem fogják Win32-re portolni, ha már annyira nem törődtek a Steam verzióval, hogy a két gyártó ugyanolyan minőségű képet állítson elő.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#22984
üzenetére
Teljesen mindegy a jelenet egy screen space effektnél, amit mellesleg DX12-en a GeForce jól megjelenít. Az, hogy másképp lő az ellen nem magyarázza az egyes árnyékok és fények hiányát.
Egy multi-engine-re tervezett programnál ez normális, hiszen rákényszeríted single-engine-re, amikor az egész motorstruktúrát nem erre írták. Mindkét gyártón eléggé ingadozik ez a paraméter. Akit zavar majd megy DX12-re. Ott jóval stabilabb, mert multi-engine a kód.
Nem tud a Steam UWP programot futtatni. A DX12 verzió pedig az UWP API-ra épül.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#22981
üzenetére
A videorögzítés nem csinál olyan különbséget, mint ami van a második képen, ahol van a faszi mögött a fedezékként használt asztal árnyékolásánál. Meg a felvétel nem tünteti el a GeForce-on a szék mögül a világítást.
(#22982) FragMaster: Fogalmam sincs, hogy mi a különbség. Így látszatra a DX12-es kódhoz a Radeon képe van közelebb. És DX12-ben ilyen a GeForce is. Valami a DX11 leképezőben van. Az NV esetleg más kódot futtat. Ez elképzelhető, egy DX12-höz kialakított játéknál. Lehet, hogy az NV-nek nem volt olyan kiterjesztése, amivel megoldható a DX12-es leképező portolása DX11-re, míg az AMD-nek volt. Lehet, hogy később csinálnak és akkor korrigálják, de az is lehet, hogy szarnak bele, akinek ez fontos majd megveszi a DX12-es verziót a Store-on.
-
Abu85
HÁZIGAZDA
válasz
Peat;)
#22950
üzenetére
A scaling számítására célzok, mert az ette a sebességet DX12 alatt. Nézd meg mi a különbség a scaling on és off között. Ennek a beállításnak a kikapcsolásával kikapcsolsz egy csomó scalinghoz kötődő számítást is.
És az, hogy scaling nélkül ezt tudja a DX11, az lószar. Ennél a DX12 jobban fut scaling nélkül.
Tekintve, hogy mennyi számítás egy képet előállítani maximum részletességgel nem látom azt, hogy rosszul lenne optimalizálva. Egyszerűen csak nagyon-nagyon sok a számítás, amivel előállítanak egy képkockát.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#22941
üzenetére
Komoly? Kipakolták belőle a legerőforrásigényesebb számítást, és így produkálja ezeket a gyenge fps-eket? Akkor ez a DX11 mód vagy nincs kész, vagy nem optimalizáltak. Scaling nélkül legalább 50%-kal jobb fps-ekre lenne szükség, mert annyiba kerül kb. a scaling DX12 alatt.
-
Abu85
HÁZIGAZDA
válasz
Ren Hoek
#22938
üzenetére
A GPUOpent félreértitek. Nem arról szól, hogy egységesítse a piacot a gyártók között, hanem hogy egységesítse a fejlesztést a PC és konzolok között. Hasonlóval azért nem állt még elő senki más, mert senki másnak nincs két nyert konzoldizájnja (vagy az új gépek miatt nevezzük ezt konzolplatformnak) ebben a generációban. Ergo hiába hoz az Intel vagy az NV GPUOpent, a kutyát sem fogja érdekelni, mert nincsenek ott az Xboxban és a PS-ben.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#22936
üzenetére
Mit vártatok? A Quantum Break egyszerűen nagyon sokat számol. És DX11-ben is nagyon sokat fog számolni ahhoz, hogy előállítsa azt a képminőséget, amit kínál. Sőt, DX11-ben nincs aszinkron compute, amiből ez a játék simán nyer +15%-ot. Emellett nincs aszinkron DMA sem, ami miatt minden másolásnál le kell állítani a teljes feldolgozást. És az MSAA megoldásuk miatt ez négyszer fog bekövetkezni képkockánként.
-
Abu85
HÁZIGAZDA
válasz
Ren Hoek
#22930
üzenetére
Csak akkor tudjuk megmagyarázni, ha meglátjuk, hogy mit csinál az eljárás. Addig ebből kell megélni. De ha megjelenik ránézünk az tuti.
Utóbbihoz nyilván több köze van az egyéni döntésnek. A DICE mindig így működött, kiválasztottak egy GPU-t és azt nyomatták, mert tényleg arra optimalizálták a játékot. Most a Polaris 10 ez a GPU. De ez eddig nem okozott problémát, szóval szerintem belefér.
-
Abu85
HÁZIGAZDA
válasz
imi123
#22926
üzenetére
A Doom azért gyorsul 20-25%-ot az AMD-n a Vulkan módban, mert kapott shader intrinsics-et. A Deus Ex MK a szeptember második felével kiadott patchben dettó megkapta ugyanezt. Ott 10-15%-ot jelentett.
(#22927) Ren Hoek: Nincs a többi GCN-ben utasítás előbetöltés, így hátrányosan érintené ezeket az erre épülő optimalizálás. Technikailag lefutna, csak lassítana/lassíthatna.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#22922
üzenetére
Nem. Már megkapták a áruházak az utasításokat. A BF1 csak olyan konfigurációhoz és VGA-hoz reklámozható, amiben Polaris 10 van. Ezeket ugye most rakják össze a BF1 startjára, mert kell egy kis idő, hogy berendeljék az alkatrészeket és összeállítsanak egy rakás gépet. Más erősebb GPU-hoz egyáltalán nem reklámozható. Nem is fut le minden, amit a motorba beleraktak.
) a Frostbite alatt. Ez minden nagyobb motorfrissítésnél előjött. Például még a BF4 alatt is. Az az oka, hogy a programozást Bulldozeren végzik még mindig, és a multi-thread optimalizálást CMT-re csinálják, ami káros a HTT-nek. Viszont, ahogy a BF4 alatt is, úgy BF1 alatt is javíthatók a Hyper-Threading kezelésére vonatkozó bugok, csak kell nekik pár hét hozzá.
, viszont a Microsoft csapata megcsinálta. Az egyetlen baj, hogy ezt biztos nem írják vissza a main branchbe. A korábbi gyakorlattal ellentétben ezt a leképezőt és a hozzá készült struktúrát a Microsoft megtartja magának. Pedig amúgy jó lenne visszaírni, mert az eredeti leképező nem támogatja a multi-GPU-t, míg ez képes rá, noha még nincs engedélyezve.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
Megbízhatatlan oldalakat ahol nem mérnek (pl gamegpu) ne linkeljetek.
- Renault, Dacia topik
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Kormányok / autós szimulátorok topikja
- talmida: Változások 2. rész
- Tőzsde és gazdaság
- Samsung Galaxy S25 - végre van kicsi!
- Kerékpárosok, bringások ide!
- Hobby rádiós topik
- Azonnali alaplapos kérdések órája
- Xiaomi 17 Ultra - jó az optikája
- További aktív témák...
- Gigabyte GTX 1050 Ti Windforce OC 4GB / Nem kell hozzá tápcsatlakozó!
- Gigabyte GTX 1060 Windforce OC 6GB / Beszámítás OK!
- RTX 4060 Ti 16GB GARANCIÁS (Alza) + Kingston Fury RAM keveset használt
- Asus Dual RTX 4070 SUPER EVO + FirstShop garancia 2027.04.09-ig
- Eladó GARANCIÁLIS Asus ROG Astral Nvidia Geforce RTX 5080 OC 16gb
- Beszámítás! Logitech G920 Driving Force Racing kormány garanciával hibátlan működéssel
- iPhone 11 64GB 100% (3hónap Garancia)- AKCIÓ
- Lenovo ThinkPad T590 15,6" - i5 8265U, 8-16GB RAM, SSD, jó akku, számla, 6 hó gar
- LENOVO TABLET 10 (N4100),10.1",WUXGA, 2-IN-1 TABLET,Ceruza,LTE kártya,8GB DDR4,128GB SSD,WIN11
- HP ZBook Studio G8 i7 32GB RAM 1TB SSD RTX A3000/Garancia
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest