Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
A PhysX-et mindenki leszarja, azzal nincs baja senkinek, irreleváns dologként tekintenek rá. A CUDA probléma. Például az NV a PhysX für és hair effekteket elkészítette DirectCompute platformra. Azokat támogatja az AMD és az Intel. Működik is az új COD-ban. Nem a PhysX-szel van itt a baj, hanem a CUDA-val. Azt nem akarja senki sem támogatni, és az elmúlt évek alatt jól kivégezték a konzumer szinten, tehát most már nem fognak hátramenetbe kapcsolni a konkurensek.
Ha a HSA-nak adná oda az AMD a Mantle-t, akkor olyan, mintha nem adná oda az NV-nek és az Intelnek. Utóbbi két cég sosem fog belépni a HSA-ba, mert az arra szolgál, hogy rázúdítson a piacra egy tucat chiptervezőt. Ez durván növeli a versenyt. -
Abu85
HÁZIGAZDA
Attól, hogy kijön egy SDK még nem változik semmi. Ahhoz, hogy egy konkurens cég támogassa a Mantle-t az kell, hogy egy független alapítvány átvegye a fejlesztését. Az SDK csak annyit jelent, hogy nem kell többet nevezni az AMD partnerfelvételére, hanem csak beütöd az oldalt és töltöd le az SDK-t. Ez a gyártói hozzáálláson nem fog változtatni.
De egyébként nem vagyok meggyőződve arról, hogy a világnak szüksége van egy publikus SDK-ra. A Mantle kontrolláltan lehet hasznára a piacnak. Nemsokára meghirdetik a harmadik felvételit, oda jelentkezhetnek majd a fejlesztők.Szerk.: [link] - már ki is posztolták. Szépen kontrollált környezetben lehet fejleszteni rá.
-
Abu85
HÁZIGAZDA
válasz
SzlobiG
#1607
üzenetére
Ezért nem értem én sem ezt az irányzatot, de ettől még a multis játékosok nagy része csökkenti a részletességet, hogy 100 fps fölött legyen mindig multiban. Nem értem miért, de ha megnézel egy profi játékost, akkor lowra van véve mindene és úgy játszik. Többnyire azért vesz gépet, hogy elérje a 200 fps-t.
(#1608) Malibutomi: A négymagos Inteleken sokat segít a Mantle. Még Full HD ultrán is megdobja azokat egy extra 30%-kal multiban. A hatmagos Inteleken nem dob annyi. Ott 290X mellett is maximum 20%-kal több az ultra multi.
-
Abu85
HÁZIGAZDA
Idén biztos nem jön a 490X. Márpedig idén lesz olyan játék, aminek egy-egy effektje reálisan csak Mantle-ön lesz bekapcsolható. A Frostbite Team mondta, hogy az R&D-jük nagy része a Mantle-re megy.
A 290X-es felhasználók is örülnek. A legtöbb hardcore játékos eleve 100 fps fölé lővi be a rendszert még 290X-szel is. Lásd őt is. [link] - számára a Mantle plusz 60 fps-t jelent. És durva gépje van, csak multis arc és 100 fps fölé paraméterezi a beállításait. Szóval leginkább medium presetre. És még egyszer mondom, a legtöbb hardcore játékos ilyen. A mögöttes koncepciót én sem értem, hogy csúcsgéppel, mi értelme medium preseten játszani, de most mit lehet ezzel kezdeni. -
#1597
Abu85
HÁZIGAZDA
ricshard444
#1596
Abu85
HÁZIGAZDA
válasz
ricshard444
#1596
üzenetére
Mondjuk azt tedd hozzá, hogy leginkább multiban. Single-ben tényleg inkább 10% a bónusz.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#1592
üzenetére
Itt nem a felbontásról van szó, hanem az általános effektminőségről. Régóta tudnánk olyan dolgokat csinálni, amiket a filmekben látsz CGI animációként. Egy dolog miatt nem tesszük meg. Nincs hozzá megfelelő API-unk. De látszik, hogy maga a piac próbál innovatív lenni. John Carmack a megatextúrázással. Berakta, innovatív, de még nem működik. Vagy Tim Sweeney az UE4-nek az Voxel Cone Tracingjével. Berakta, DX alatt nem stabil, így mára kivette, de érzi, hogy merre kellene menni, csak ma még nem tudja megtenni. Bezzeg Capcom. Berakta PS4-re az alternatív implementációt, és eldobta az agyát a piac a Panta Rhei motortól. Ez eddig jó, de hogyan portolod PC-re? És ez felmerült már a Capcomnál is, hogy az új motornál erre nem gondoltak, és ez gond lesz.
-
Abu85
HÁZIGAZDA
A DX kód ledobja az erőforrást. Ezzel küzd a BF4 mióta megjelent. Az januári patch-ek javítottak, de most az új patch-ben nőtt egy picit a DX kód sebessége és megint jönnek a device hung hibák. Többek között nekem is előfordult a hétvégén, pedig két hónapja nem volt ilyenem. A Mantle kód stabil a rendszeremen.
Engem ebben az irányban az érdekel, hogy legyen egy olyan API, amire lehet a konzolról új generációs effekteket portolni. Értem, hogy van más koncepció is, amit az NV csinál, hogy ha valami nem működik, akkor lesz rá OGL- és DX-barát alternatív effekt, de szerintem ez nem reális alternatíva. Egy hardcore PC-s játékos nem fogja elviselni, hogy konzolon szebb lesz xy effekt. Persze a többség le fogja szarni, de a hardcore réteg lázadni fog. Nekik jó lesz a Mantle.
-
Abu85
HÁZIGAZDA
válasz
Casanova*
#1555
üzenetére
Mantle alatt nem romlik a grafika. Van egy bug, ami ködösebb hatást kelt. Ez nem befolyásol semmit. A specular mapok tűnnek még kontrasztosabbnak. Ez valszeg eltérő paraméterezés, de a számítások ugyanazok. Emellett a Mantle alatt olyan helyeken is vannak árnyékok, ahol DX alatt valamiért nem. Ez szembetűnő helyenként, de nem valószínű, hogy ez extra számolást jelent. Valószínű, hogy ez DX alatt is megtörténik, csak valami bug miatt nincs eredménye.
-
Abu85
HÁZIGAZDA
Stabilabb a Mantle kód, mint a DX. A legtöbb helyen az a gond, hogy a tuningot nem vették vissza. Néztem a terhelését. A processzort legalább kétszer jobban használja az új API, és a GPU-n is 40%-os átlagos leterheltségről 70%-ra ugrottam. De a DX elvileg képtelen 60%-nál jobban terhelni egy GPU-t. A CPU-tuningot nekem is vissza kellett vennem, de alapon sokkal jobb. Hozzávetőleg 30%-ot gyorsultam, bár azt hozzá kell tenni, hogy DX eredményeim 3,7 GHz-ről vannak, míg a Mantle mellett a proci alap 2,8 GHz-en ment.
-
Abu85
HÁZIGAZDA
válasz
Casanova*
#1489
üzenetére
Szerintem ezt az NV vs. Linux és magát a Linus fuck off-ot félreértitek. Linus azért mutatott be az NV-nek, mert a vállalat akkoriban teljesen lezárta a hardvereinek a dokumentálását és a specifikációkat. Tehát Linus csak arra reflektált , hogy az NV hozzáállása - tehát nem a támogatása - az open felfogáshoz messze a legrosszabb a piacon.
Te mint egyéni júzer csak telepítesz egy Linuxot és egy zárt drivert és boldog vagy, esetleg nem (![;]](//cdn.rios.hu/dl/s/v1.gif)
). Viszont vannak a zsíros kormányzati megrendelések. Nekik fontos az, hogy a hardverek dokumentálása jól elérhető legyen és ezért támogatják a Linuxot és a mögötte rejlő open dolgokat. Na ez az amiért Linus bemutatott, az NV ezekért a zsíros megrendelésekért semmit sem tesz.A SteamOS csak arra való, hogy ha mész a nappaliba, akkor ne konzolt vegyél.
-
Abu85
HÁZIGAZDA
válasz
Casanova*
#1483
üzenetére
A SteamOS-t a hardcore játékosokat nem fogja megmozdítani. Nem azért vesznek 2000-4000 dolláros gépet, hogy aztán a Windowsos port grafikai szintjének felén futtassák ugyanazt a játékot. A Valve koncepciója szerintem marha jó, csak pont rossz potenciális vásárlóbázist céloznak a reklámmal és az érkező gépekkel.
-
Abu85
HÁZIGAZDA
válasz
WaterWawe
#1435
üzenetére
Az NVIDIA ezt sosem fogja kérni. Legalábbis addig biztos nem, amíg az AMD nem adja ki egy független alapítványnak a fejlesztést. Ez szimpla üzletpolitika. Az NV azt mérlegeli, hogy miképp tudna nyeregben maradni a Mantle mellett és arra fognak majd fejleszteni, de ha beállnak a Mantle mögé, akkor elfogadják azt, hogy az AMD lesz a piacvezető, és másodvonalra kullognak. Ez sosem lehet alternatíva egy cégnek.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#1433
üzenetére
Technikailag rendben van. De sanszos, hogy az AMD ezt mindenkinek oda fogja adni, és nem csak a top stúdióknak. Én a Mantle ötletét nagyon bírom, mert három évvel korábban is írtam itt arról, hogy egy ilyenre lenne szüksége a piacnak. Bár ezt szabványos formában gondoltam, de ettől a szoftver még kell. A Mantle esetében nagyon jónak tartottam, hogy ki lesz kötve, mert azok a fejlesztők kaphatják meg, akiknek van pénzük, és igazán nagy AAA projekteket készítenek. Ha viszont leveszik a Mantle-ről a nyakörvet, akkor félő, hogy a kevésbé tehetősebb fejlesztők nem az extra optimalizálás lehetőségét látják majd benne, hanem a fejlesztési költsége drasztikus csökkentésének a lehetőségét. Utóbbi egyértelműen rossz a piacnak. Ezért kellene ezt mindig pórázon tartani. Szerintem.
-
Abu85
HÁZIGAZDA
válasz
KAMELOT
#1384
üzenetére
Mert az egy hatmagos proci. A BF4 betartja a DX által ajánlott batch countot is, így nem igazán megy 2000 dc/f (egyedi rajzolás/képkocka) fölé. Ennek a DX többletterhelése mellett egy erősebb mag elég. Na most a Mantle ezt többszálúsítja, amitől még mindig nem lesz több a dc/f, de nyolc szálra is szét lehet osztani lineáris skálázódással. Ez hozza az egyik nagy gyorsulást. A másikat a driver szálainak eltűnése jelenti. Ha van 6-8 magod, akkor ez kevésbé érinti a rendszert, mert az OS azért igyekszik szabad erőforrásra ütemezni. Mantle alatt viszont nincs driver szál, tehát nincs olyan láthatatlan folyamat a program számára, ami elvenné az erőforrást.
Nagyon általánosan erős GPU mellett 6-8 maggal 10-30%-os gyorsulás lehetséges, függően a magok teljesítményétől. 2-4 maggal 20-40%-os. -
Abu85
HÁZIGAZDA
válasz
KAMELOT
#1381
üzenetére
Semmilyen terhet nem vesz át a procitól. Dióhéjban eliminálja a driver szálakat, lecsökkenti a többletterhelést és kiszámítható működést biztosít a fejlesztőknek. Ennyi. Megpróbálom a lehető legérthetőbben leírni. A legtöbb gyorsulás abból ered, hogy a fejlesztők szabadon hozzáférhetnek a látható erőforrásokhoz, és nem mondja nekik valamilyen rejtett körülmény, hogy "Bocs az mégse szabad. Ja hogy már késő? Majd legközelebb talán sikerül összehozni (trollface)...". Aki odament az AMD-hez és kérte a Mantle-t, annak ebből lett elege. Meg persze abból, hogy 2007 óta pofázzák ezt a problémájukat az MS-nek és semmi.
-
Abu85
HÁZIGAZDA
Nem akarok nagyon ebbe a PC-s optimalizálásba belemenni, de ha megnézzük az Ubisoft Kiev felhozatalát, akkor igazából soha az életben nem adtak ki normálisan optimalizált játékot PC-re. Egyrészt ebből tökéletesen kikövetkeztethető, hogy valami nem működik jól náluk. Vagy kevés az ember, vagy hiányzik a szaktudás, vagy az Ubi kevés pénzzel látja el őket. Esetleg ezek kombinációja. De igazából az NV-vel és az NV nélkül is rossz portokat készítettek, tehát ezért nehéz lenne mást hibáztatni, mint az Ubisoft Kievet. Esetleg, ha tényleg kevés pénzt adnak nekik, akkor lehet mutogatni az Ubisoft vezetőségére.
-
-
#1182
Abu85
HÁZIGAZDA
TechArtist
#1154
Abu85
HÁZIGAZDA
válasz
TechArtist
#1154
üzenetére
Ez nem tartalmazza a Mantle-t és a TrueAudiót. Akárki akármit állít nincs benne. Majd írok róla, ha olyan driver lesz, amiben benne lesz.
-
Abu85
HÁZIGAZDA
Csak nem fogod tudni belerakni egy játékba. Amíg egy kockás terepen mutogatják addig oké, de a játékban kötelező, hogy a GPU még abban a jelenetben végezzen a számítással, ami szinkronizálva lesz. Mivel erre dedikált grafikus vezérlővel nincs garancia, így az egész megmarad egy kockás terepen futó dologként.
Ezek egyébként nem újdonságok. Évek óta léteznek, de mindig ugyanaz a gond. A lassú buszon bekötött GPU nem tud a szinkronizációra elkészülni. Egyébként a fejlesztők is ezt látják jövőképnek. Ezért kértek megosztott virtuális memóriát a konzolokba, hogy játékokba is be lehessen építeni ilyen fizikai modellezéseket. PC-n ezt maximum szinkronizáció nélkül lehet megoldani, de az nem több a mai particle rendszereknél.
Ezt a rendszert az NV is leginkább az ARM-os APU-ihoz szánja. -
Abu85
HÁZIGAZDA
Igen ez a PC gaming érdekes kérdés. Nyilván fűződik hozzá érdek még a fokozatosan csökkenő piaci igények mellett is, de annyira korlátozó már a szabvány API-k funkcionalitása, hogy az új konzolok effektjeit értelmetlen, vagy lehetetlen rájuk portolni.
Az AAA játékok esetében a megjelenítés erősen filmekhez használ CGI-ból fog építkezni. Nagyjából a mai konzolok elég erősek ahhoz, hogy a filmekhez használt motion blur effektet átvegyék és ne kelljen használni a trükközős megoldásokat, amiket sokak inkább kikapcsolnak. De a GI-t és az árnyékok leképzését is lehet mondjuk voxel cone tracingre építeni. Ezektől majd leesik az állad, viszont DX-en és OGL-en nem lesz.
A filmes motion blurt az érkező StarSwarm technikai demón meg tudod majd nézni. Semmi értelme ugyan, de leportolták DX-re.
-
Abu85
HÁZIGAZDA
Minden cég arra megy, ahol leginkább nyerhetnek a stratégiájukkal. Például a konzolok miatt az AMD-nek sok dolgot összejött, hiszen elindíthatnak egy puccsot a PC-n. De ugyanígy ki lehet emelni, hogy több kiadó is kijelentette, hogy 2014-ben a konzolok után az Android lesz a második, és a PC a harmadik célplatform. Tehát a fókusz megint kezd megváltozni. Ez például az NVIDIA számára kedvező, mert nekik leginkább az volt a kérdés a jövővel kapcsolatban, hogy miképp hozzák át a felhasználóikat Androidra. Hát a piac megoldja helyettük.
Aztán ott a SteamOS, ami képes lehet a nappaliba költöztetni a PC-t.
Rengeteg alternatíva van, és mindenki azokat az irányzatokat fogja majd meg, ahol jók lehetnek, és nem azt, ahol már ma vesztettek. -
Abu85
HÁZIGAZDA
Ha megnézed a CES-es előadásokat, akkor a stratégia minden cégnél különbözik már. Nagyjából látható, hogy ki merre megy. Kivéve az Intelt.
Az AMD koncepciója egyértelmű. Van egy rakás partnerük a Mantle és a TrueAudio szempontjából. A Windows gaming a fókusz és a konzolokból származó előnyt kell kihasználni. Erre építenek fel mindent.
Az NV más irányból közelít. Nem a gigastúdiók, hanem a kisebb cégek igényeit szolgálnák ki, ahol kevés a pénz jó grafikát csinálni. Erre van a GameWorks. Kattintással is lehet xy effektet rakni a játékba. Emellett az Unreal Engine 4-et mára jelentősen lebutították, hogy az Android lehessen a célplatformja.
Igazából mást kínálnak a piacnak, tehát a közvetlen versenyre nem érdemes majd számítani.
-
Abu85
HÁZIGAZDA
Ha az NV akarna egy low-level API-t, akkor igent mondtak volna helyből Repinek erre az igényére. Írtam már, hogy a low-level API elkészítése nem nagy dolog. Bárki meg tudja csinálni, de ahhoz, hogy ennek értelme is legyen több dologra is szükség van. Egyrészt egy olyan architektúrára, ami elég nagy tudással rendelkezik ahhoz, hogy 4-5 évig ne kelljen hozzányúlni az alapokhoz, másrészt szükséges egy olyan dolog, ami miatt ezt az architektúrát megtanulják a fejlesztők. Mert ez az egész nem megy majd magától. Ez nem DX, vagy OGL. Itt direkten az architektúra működésére kell dolgozni különben nem lesz hatékony a kód.
A fejlesztői igény tehát egy dolog, de a megfelelő kivitelezéshez nem elég. A Mantle is csak a konzolok miatt érdekes, abból építkezik. Másnak alternatív stratégia kell.
-
Abu85
HÁZIGAZDA
Eredetileg a Mantle driver a BF4 patch-csel jött volna. Nem szükséges azt külön meghajtóban szállítani. Mindig január végére volt tervezve az első Mantle driver a Catalystban.
A stabilitás nem olyan kritikus most még. Egyelőre nem optimalizálják a végletekig a kódot. Az Oxide mondta, hogy a sebesség jön out-of-box, szóval egyelőre mindent a stabilitásra helyeznek. Az biztos marad benne tartalék, de ráérnek még kihasználni, ha lesz teljes dokumentáció, meg SDK, meg példák.
-
-
Abu85
HÁZIGAZDA
válasz
daneeeeee
#1059
üzenetére
Repi nem árulja el a gépet. De azt tudom, hogy 144 Hz-es nagy kijelzője van. Valszeg 2560x1440 pixeles. Meg a max beállítás az biztos. Esélyes, hogy két Radeonja van, valszeg két R9 290X.
(#1060) daveoff: Lehet, hogy Kaveri volt a proci, és akkor az IGP is dolgozott a grafikai számítóson. De biztos, hogy volt még mellette két nagyobb dedikált GPU. Egy dedikált GPU-val a 180 fps minimum elég nagy volna.
-
Abu85
HÁZIGAZDA
válasz
WaterWawe
#1050
üzenetére
Igen.
Ezt ők nem így fogják fel. Ha lesz egy Mantle kódja a játéknak, akkor eleve úgy állnak hozzá a DX kódhoz, hogy ami túl körülményes DX alatt azt le se portolják a konzolról. Ezért kérték a Mantle-t. Áthozzák konzolról az effektet és ha be akarod kapcsolni, akkor vegyél hozzá hardvert. A DX meg ott lesz a normál kódhoz, ha a Mantle nem érhető el. Ez összességében nekik kevesebb munkát jelent, mert mondjuk PS4-ről, ami sok fejlesztőnél lesz vezérplatform egyszerűbb Mantle-re portolni, mint DX-re.
A Frostbite Team ezért alakult meg az EA-n belül (vált ki a DICE-ból). Minden Frostbite 3 játékhoz ők végzik a kutatást és portolást. Elsősorban PS4-re és Mantle-re. -
Abu85
HÁZIGAZDA
Írtam a másik topikban, hogy a Steamre már felkerült a StarSwarm demó. Az arra vár, hogy a Valve átmenjen rajta a szokásos tesztekkel és aktiválják. Ennek lesz egy full kész DX11 és egy leginkább alpha fázisú, de stabil Mantle kódja. Ehhez lesz egy driver a héten. Ez ugyanaz a driver lesz (13.35-ös iteráció), ami nekünk van január 12-e óta.
A BF4 patch az EA-től függ. Kész van december közepe óta. Működik, játszanak rajta. Repi gépén 180 fps-sel megy, de nem adja ki addig az EA, amíg a DX kód ledobja magáról a hardvert. Nem akarja, hogy a játékosok mutogassanak rájuk, hogy a Mantle-re koncentráltak és azért nem stabil a DX kód.
-
#1047
Abu85
HÁZIGAZDA
->Raizen<-
#1031
Abu85
HÁZIGAZDA
válasz
->Raizen<-
#1031
üzenetére
A DX11 engedi a mutexeket. Nincs ezzel önmagában semmi baj, csak ezek nem ajánlott funkciók. De ha azt nézzük, hogy ebből sok sebességet szednek össze, akkor érdemes vele foglalkozni. Azt viszont nyilván érzi a Frostbite Team, hogy nagyon sok erőforrásukat felemészti a gyors DX kód, ezért kértek egy modernebb API-t.
(#1032) norb55: Repi mondta a TH interjúban, hogy az NV-hez is odament, hogy csináljanak egy low-level API-t. Ők elzárkóztak ettől. A low-level API elkészítése nem nagy dolog, kb. két év. Abból az irányból problémás ez a modell, hogy a low-level API-hoz ismerni kell a megcélzott architektúra működését. Ha valaki egy ilyen felkérésre azt mondja, hogy nem, akkor azért mondja, mert nincs olyan piac, amiért érdemes megtanulni a célzott architektúrát.
-
Abu85
HÁZIGAZDA
válasz
MPowerPH
#1011
üzenetére
Előbb befejezzük a Kaveri tesztet. Aztán megyünk tovább. Mantle driverünk már van a hónap közepe óta, az fog megjelenni a hónap végén publikus formában. A StarSwarm demó fent van a Steamen és engedélyre vár a Valve-tól.
A BF4 patch technikailag kész van december közepe óta. Az EA viszont addig nem akarja kiadni, amíg a D3D-vel kapcsolatos hardverledobálásokat ki nem javítják. Félnek, hogy az lenne a reakció, hogy a Mantle-re koncentráltak, holott a D3D-t jelölték meg elsődleges kódként.
Maga a probléma megoldása egyébként egyszerű lenne, ha Repi nem ragaszkodna az aktuális D3D teljesítményhez. De mivel ragaszkodik ahhoz, hogy a stabil D3D kód csak alig különbözhet az aktuális instabil D3D kód teljesítményétől, így ez megnehezíti a javítást.Ez a gond egyébként a Frostbite 3 sajátja. Soha senki nem dolgozott olyan terheléssel, amit ez a motor megvalósít. A teljesítményt viszont a D3D API-ban nem ajánlott dolgok használatával érik el. Ezek sok tempót hoznak, de könnyen lehet instabil a kód. Ha ezeket a dolgokat kiveszik, akkor stabil lesz a kód, de a teljesítmény fele odavész.
-
Abu85
HÁZIGAZDA
Multiban több eltérés lehet, mivel sokkal több szabad és egyben használható erőforrása marad a CPU-nak. Nincs egyetlen szála sem a Mantle rendernek, míg a DX-nek 5-7 aktív rejtett szála is van. Nincsenek hazardok sem a driverben és az API-ban, nem kezel külsőleg szinkronizációt. Ha ezek nagyon leküldik az fps-t, akkor a Mantle ilyen helyzetben simán tud kétszeres sebességet.
Az EA-től függ. A kód kész van.
Ma leginkább driverlimit van. De ha egy játék használja az IGP-t a dGPU mellett, akkor könnyen kitalálható, hogy az ellen sima CPU-nak nincs esélye. Ettől persze még így is gyorsul.
-
Abu85
HÁZIGAZDA
Nem igazán a driver ennek a helye. A fejlesztők a DX11 megjelenésével elkezdték rágni az MS fülét, hogy compute mellett hülyeség, hogy a hardvernek csak egy parancslistája van és órajelenként csak egy parancsot fogad. Na most ez máig hiányzik a szabvány API-kból, így a program nem tud itt semmit átlapolni, adja a parancsokat az API és kész. A driverben lehet alkalmazásokra külön megoldani, hogy a compute és a grafikai meló legyen átlapolt. Ezt nehéz megcsinálni, de alapvető optimalizálásnak tekinthető, viszont ha kis átlapolásból mondjuk nagyot akarsz csinálni, akkor az több hónapos meló csupán egy alkalmazásra.
-
Abu85
HÁZIGAZDA
Ez csak akkor szokás, amikor a fejlesztő valami hatalmas butaságot csinál. Sajna van erre példa bőven, de nem általános.
A driverbe a mai modern alkalmazásoknál főleg olyan dolgok kerülnek, mint a grafika és compute átlapolás (erre megy messze a legtöbb optimalizálás) specifikusan az alkalmazáshoz igazítva. Ott a Dirt: Showdown esete. Az azért gyorsult sokat GeForce-on, mert 8 hónapig csak ezen dolgozott egy fejlesztőcsoport. Ez lehetett a legdrágább driverprofil a történelemben.
-
Abu85
HÁZIGAZDA
Ha megnézed az Intel és az NV stratégiáját, akkor az nem API specifikus. Az Intel és az NV távolodik a Windows gamingtől, mert marha nagy gyomros nekik a low-level elérés hiánya, ha egy konkurens ehhez hozzájut. A SteamOS-re mennek, mert a Valve open kezdeményezéseket akar. Az NV elveszti a PhysX-et és a CUDA-t is, de legalább nem lesz Mantle. Az NV-nél még az Android is nagyon fontos. Direkt kivettek egy csomó ígéretes technikát az UE4-ből, csak azért, hogy Androidon üzemképes legyen.
A Windows mindenképp érdekes marad, de kockázat is, mert az AMD-nek low-level API-ja van rá. Nem mindegy, hogy egy hardver 30-50%-ig van kihasználva, vagy 70-90%-ig. Ha sokan állnak a Mantle mellé, akkor azzal nem tudnak mit kezdeni. Csak saját low-level API-val lenne esélyük.
-
Abu85
HÁZIGAZDA
Nem. Az NV-n is fognak majd futni. Lesz normális DX11 támogatásuk. Esetleg OpenGL. A játékok egy része gyorsulni fog, míg egy részükből hiányozni fog pár extra effekt, ha nincs Mantle (esetleg meglesz az effekt, de aktiválhatatlan lesz, mert kivégzi a teljesítményt - az Oxide például leportolta DX11-re a Film Quality Motion Blurt, de sokat nem ér, mert 5-8 fps-re zuhan a teljesítmény). A stratégiáknál még elképzelhető, hogy bizonyos játékmódok Mantle nélkül nem érhetők majd el, de ezek extrém szituációk lesznek az Oxide szerint is. Amolyan Skirmish mód szinten, amikor kiválasztod, hogy mennyi lehet a maximális egységek száma. A Mantle-lel nagyobb lehet ez a szám.
-
#969
Abu85
HÁZIGAZDA
Malibutomi
#956
Abu85
HÁZIGAZDA
válasz
Malibutomi
#956
üzenetére
[link] - talán érdekes lehet. A címek alapján ő ott volt a CES zárt rendezvényein. Meg tudnám erősíteni, amit leírt csak nincs felhatalmazásom rá.
De ahogy látom az Oxide saját játékát kihagyta, és pár SE címet is.Szerk.: Ja nem, az SE-re odaírta alulra, hogy be nem jelentettek.
-
Abu85
HÁZIGAZDA
Korábban leírtam, hogy az Intel és az NV számára nem elég az, ha Repi azt mondja, hogy ezt támogathatják. Nekik tudniuk kell, hogy az AMD hogyan fejleszti tovább az API-t, mikor jutnak hozzá az új fejlesztésekhez, mennyit kell ezért fizetniük, és a legfontosabb, hogy kapnak-e az API-ról teljes dokumentációt, és ha nem, akkor szabad-e a reverse engineering.
A multivendor azért van bedobva, hogy a felhasználók ne a Mantle-t támogató fejlesztőkre mutogassanak, hogy "mé" csinálnak ilyet, hanem az Intelre és az NV-re, hogy "ménem" támogatják.Ha mondjuk nincs teljes dokumentáció és a speckókat csak megjelenéskor kapja meg az NV, akkor nem fognak bevállalni egy állandó 3-4 éves versenyhátrányt, hanem megmondják az AMD-nek, hogy rohadjon rájuk a PC-s játékpiac.
-
Abu85
HÁZIGAZDA
válasz
#35434496
#895
üzenetére
Nem fogja lehűteni annyira. A kártya mindig igyekszik elérni a 95°C-ot. Erre van beállítva. Ettől gyorsulni fog, de ilyet gyári paraméterekkel nem lehet majd csinálni. Ezért a gyártók leveszik a target hőmérsékletet, amitől viszont lassul a referenciabeállítás. Itt mindent át kell paraméterezni az adott target hőmérséklethez.
-
Abu85
HÁZIGAZDA
Az, hogy átláthatatlanná teszi a termékskálát, mert az egyik cég 290X-je 20%-kal is gyorsabb lehet a másik cég megoldásánál. Ha nem OC-s a termék, akkor be kell tartani a szabályokat. OC felirat mellett azt csinálnak a gyártók, amit akarnak.
(#892) HSM: A 80°C csak példa, de nyilván a DVFS-nek meg kell maradnia, mert ez biztosítja a hatékony kihasználást. Enélkül ott vagyunk, ahol kép éve, hogy 10-15 wattra is kerülünk a limittől. Ezért okozhat a hűtőcsere és csak a hőmérsékletlimit változtatása lassabb terméket a referenciamodellnél.
-
Abu85
HÁZIGAZDA
válasz
#35434496
#889
üzenetére
Nincs semmi baj, csak paraméterezik őket. Olyan gyorsnak kell lenniük, mint a referenciamodelleknek. Ehhez teljesen más paraméterezés szükséges, mert mint írtam a szimpla hűtőcsere és a 80°C-os limit lassít a referenciához képest.
Ez a termék nem olyan egyszerű, hogy csak raksz re egy másik hűtést és már mehet. -
Abu85
HÁZIGAZDA
válasz
Casanova*
#864
üzenetére
Ez nem ilyen egyszerű. A fejlesztő túl sok kontrollt nem kap a VRAM használat paraméterezésére. Minden egyes DX/OGL API object egy új memóriaterületet foglal le, még akkor is, ha lényegében ugyanaz az adat már vagy 4-szer benne a memóriában. Például ezért tudtak a korábbi generációs konzolok annyira kevés memóriával ellenni, mert nem pazarló módon bánnak a memóriával. Szóval még ha terveznének is a memóriahasználatra a GPU-nál, akkor is annyira kevés erre a kontroll, hogy simán mellé lehet lőni. Ennél egyszerűbb a megközelítés. Meg van szabva, hogy 200 dollár fölött már kell a 2 GB és 400 dollár fölött belefér a 4 GB is. Ennyire egyszerűen alakulnak ki a mai memóriasémák.
-
-
Abu85
HÁZIGAZDA
Nem. A Furmark szintű terhelés mellett a GK110 500 MHz-en üzemképes a 300 wattra tervezett PCB-vel. Ezért van driverből lefojtva a működése, hogy ne kelljen az órajelet csökkenteni.
Ha nincs DVFS, akkor mindenképp peakre kell tervezni, ami még a Furmarknál is nagyobb terhelés. -
Abu85
HÁZIGAZDA
A GTX 580 sokszor 40 wattra volt a kártyába épített TDP limittől. Ennyi teljesítmény maradt benne, amit a fix órajel miatt nem tudtak kihasználni. Ha kihasználják, akkor úgy jó 15-20%-kal gyorsabb lehetett volna, de ez már történelem, nyilván ilyen DVFS rendszereket nem könnyű fejleszteni.
(#829) HSM: De minek akarnál rátenni 8-at, amikor 6-tal is megvan a 300 wattos szabványos fogyasztás. Attól, hogy raksz rá 8-at még nem mehetsz a 300 watt fölé, ha el akarod adni a kártyát az OEM-eknek.
-
Abu85
HÁZIGAZDA
Az, hogy hány fázisú a VRM nem határozza meg egzakt módon, hogy milyen erős a rendszer tápellátása. Nem csak a fázisok száma számít. Azokat azért szokás növelni, mert fázisonként lényegesen gyengébb kiépítést lehet alkalmazni, ami összességében olcsóbb, mint a nem spórolós referenciamegoldások. Az, hogy ebből előnyt kovácsol a marketing az mindegy, mert ettől a hardver nem lesz jobb.
-
Abu85
HÁZIGAZDA
Ebből a fórumból szűrted le?
Ez olyan dolog, hogy a google-on beírod az egyik VGA-t és keresel screen hibát. Mindegyikre milliós nagyságrendű találatot kapsz. A legnagyobb gond a black screen hibával, hogy a megfogalmazás teljesen általános. Gyakorlatilag minden hiba fekete képernyőt eredménye, függetlenül attól, hogy mi a hiba forrása. Ezért van minden hardverre milliós találat.
Egyébként maga a gond az UEFI. A gyártók nem garantálják, hogy a fastboot eredményes lesz, csak akkor, ha azonos az alaplap és a kártya gyártója. Legacy módban megy, akinek ez a problémája. -
Abu85
HÁZIGAZDA
Ennél jobb PCB-t nem fog kapni semelyik sem. Ez így is lényegesen drágább, mint minden ma létező VGA PCB-je. A nem gyári megoldások olcsóbb VRM-et kapnak. Ki van zárva, hogy bárki ezekre a csúcskategóriás alkatrészekre építene.
Nem a VRM-mel van a baj, hanem azzal, hogy két munkafolyamat között olyan különbség lehet, hogy az egyiknél 750 MHz-en jó csak az órajel, míg a másiknál 1 GHz fölött is. Ha nincs DVFS, akkor mindenképp a peakre kell tervezni, vagyis a 750 MHz-re. Ezzel pedig számos munkafolyamatban sebességet vesztesz, mert jó lenne az 1 GHz is a szabványos, maximum 300 wattos határon dolgozó VRM-mel, csak nincs DVFS, amivel ezt elérhetnéd.
-
Abu85
HÁZIGAZDA
Miért kellene a vásárlókkal megértetni, hogy mit csinálnak? A vásárlóknak fogalmuk sincsen arról, hogy miképp működik egy ilyen hardver. Ők azt látják, hogy milyen teljesítményt ad le. Ennél tovább ezt nem kell ragozni, mert abból csak értetlenkedés lesz. Elég ha ezt a sokdiplomás mérnökök megértik, ők tudják, hogy mit miért csinálnak. Ez annyira mély információ, hogy felesleges is átadni a vásárlóknak, mert a többségük nem tanult egyetemi szinten fizikát.
Aki meg bele akar képzelni ilyen-olyan dolgot, hát beleképzelheti. Az eredményeket a tesztekben ez sem befolyásolja, illetve ettől még ugyanúgy menni fog a Mantle is. -
Abu85
HÁZIGAZDA
Ma csak a GPU Boost 2.0 és az új PowerTune miatt létezik a GK110 és a Hawaii. Komolyan nem viccelek, amikor leírtam, hogy az előbbi 500, míg az utóbbi 600 MHz-es órajelet kaphatna a DVFS rendszerek nélkül. Azt persze stabilan tartaná, de fel tudnád húzni mindkettőt úgy 650-700 MHz-re, és ez a csúcs a tuningnál. Na most ennél mindkét lapka jobb paraméterekkel dolgozik alapértelmezetten. Szóval lehet utálni minden DVFS-t, de figyelembe kell venni, hogy ezekkel legalább 30-40% teljesítményt nyernek a gyártók.
Az első ES Hawaii kártyákon volt a PowerTune kikapcsolható, mert akkor csak a lapkát mérték fel. Az 550 MHz-en üzemelt. Hiába volt mellette ugyanaz a tápáramkör, ami mellesleg 300 watt most is, akkor sem tudtak magasabb órajelet beállítani.
-
Abu85
HÁZIGAZDA
Attól függ, hogy milyen alkatrészeket használsz. A 290-ek az abszolút csúcsholmikat kapták. Az élettartamot a gyártók mindig a leggyengébb láncszemre alapozzák, ami így a 290-eknél 19 év. Ennél lehet, hogy továbbírják, mert a hitelesítés 120°C-ra van elvégezve, miközben a kártya 94°C-nál nem üzemel melegebben.
Kétségtelen, hogy a 290-ekkel nem a magyar piacot célozták meg, ha ez érdekel. Ha valaki 4K gaminget akar, ott a 290-ek működnek a legjobban, és ha már van egy 3D-s 4K kijelzője, akkor van esély rá, hogy azt filmnézésre is használja majd.
-
Abu85
HÁZIGAZDA
Megnövelték az UVD órajellimitjét, így képes sztereó 3D-s 4K-s anyagokat is lejátszani. Mivel ezt az AMD szerint 4K-ra veszik a játékosok, így ez egy fontos szempont volt, hogy a 4K-s sztereó 3D-s filmekkel is megbirkózzon. Más hardver ma erre nem képes.
(#780) gbors: A kézikönyvekben benne van, hogy miképp működik a hardver. A gyártóknak bele kell írni, hogy az órajel változása normális működés.
(#781) Tirexi: Pedig ez a jelenség a GPU Boost 2.0 és az új PowerTune esetén is teljesen normális. Maga a kártya dizájnja a megadott hőmérsékleten működik a leghatékonyabban. Az NV is 80°C-on kezdte, de haladnak felfelé a GTX 780 Ti-vel, mert minél nagyobb lesz a hőmérséklet annál jobb lesz a hardver működése. Persze a GK110-ben nincs lehetőség órajelváltásra tíz mikromásodpercenként, így muszáj a tűréshatás alámenni, mert a túlmelegedésre a hardver 500 ms-on belül nem reagál. Tehát kell benne hagyni annyit, hogy a túlterhelés hatására az órajelet legyen ideje levágni 150-200 MHz-cel az egyik ciklusról a másikra. Ezt ők kitesztelték, és a 83°C, ahol ez még biztonságos és nem sül meg a hardver. Az AMD azért megy el 94°C-ig, mert nekik 10 mikromásodpercre van szükségük, hogy a hardver kiértékelje a változást, és csökkentsen az órajelen 10 MHz-et. Ezek nagyon átgondolt rendszerek, hónapok tesztelésének eredményei.
Majd a következő körben már mindkét cégtől hasonlóan szoros működést láthatunk. ÉS alapvetően biztos, hogy a limittől mindketten 1 wattos határra kerülnek mindig. Ez azért nagyon fontos, mert a GPU Boost és a PowerTune is a biztonságra van paraméterezve, vagyis ha rezeg a léc, akkor mindkét rendszer órajelcsökkentéssel él. Minél pontosabb ez a csökkentés, annál jobb lesz a kártya hatékonysága.
-
Abu85
HÁZIGAZDA
Nem pont rád gondoltam a név nélküli részen. De túl általánosan fogalmaztam valóban. Elnézést érte.
Nem VRM kell alá, az van alatta. Itt a 300 wattos fogyasztáslimit a probléma. Igaz, hogy ez 250 wattra van állítva, de a VRM amit aláraktak az 300 wattra van tervezve. Ennél többet nem tudsz rátervezni. Ezek azok a problémák, amelyek az életre hívták a DVFS kutatásokat. Kezdve az első PowerTunetól a GPU Booston át a mostani PowerTune-ig. Mindegyik megoldásnál az a cél, hogy ha a GPU-ra kiszabott TDP limit teszem azt 207,5 watt (ennyi a Hawaii-nál, de ez csak példa), akkor minden egyes munkafolyamatnál legyen legalább 206 watt fölötti a fogyasztás, és ezzel maximalizálva van a termék hatékonysága az adott limiten belül. Ha ezt nem teszik meg, akkor be tudnák állítani a Hawaii-t úgy 600 MHz-re, mert akkor egy nagyon irreális peak értéket kell figyelembe venni, de közben a normál feldolgozás mellett a 207,5 wattos limit elérhetetlen, így a GPU csak 150 watton üzemel. Nyilvánvaló, hogy benne marad a teljesítmény negyede.
Ugyanez igaz a GK110-re a GTX 780 Ti-n, csak ott a GPU Boost 2.0 nem olyan kifinomult, így a 214,3, wattos limit a GPU-ra elő van írva, de sok szituáció lesz, ahol így is 201 watt a fogyasztás, mert a boost működése nem engedi meg, hogy közelebb kerüljön a limithez. A GTX 780 Ti esetében a GPU Boost 2.0 nélkül 500 MHz az az órajel, amit be lehet állítani, mert ott is a peak lenne kivitelezve a rendszer, ami a Keplernél, lényeges probléma, mivel az architektúra regiszterkezelése számos munkafolyamatnál elég jó, míg mondják más munkafolyamatoknál nincs elég regiszter, hogy az SMX-en belül a hat tömbből négynél több legyen aktív. Ezzel gyakorlatilag lennének olyan feladatok, ahol a GPU Boost 2.0 nélkül a GTX 780 Ti alig 90 watt mellett üzemelne.
Szóval ez a PowerTune meg a GPU Boost 2.0 egy nagyon realista szemlélet a mai világban, mert enélkül a top R9 290 és GTX 780 hardverek teljesítményének csak a 60%-át kapnád meg. Aztán tuningolhatsz ahogy akarsz, de soha sem lennél képes elérni azt a teljesítményt, amit most nyújtanak a kártyák alapértelmezetten. Sőt, megközelíteni sem tudnád.
A spórolásról meg annyit, hogy jelen állapotban jóval drágább egy kártyát előállítani, mint PowerTune és GPU Boost 2.0 nélkül. De megéri méregdrága vezérlőt és körítést alkalmazni, mert nagyjából +40% teljesítményt hoznak ezek a rendszerek.(#758) gbors: Az AMD minden anyagában Up To órajelről beszélt, illetve ha valakinek ez nem tetszett, akkor PowerTune Boost órajel is használható, vagy maximális magórajel. Ezek közül lehetett választani.
(#776) Tirexi: Nagyon egyszerű a custom hűtőknek a gondja az R9 290 sorozaton. Ez nem olyan egyszerű, hogy hűtőt cserélsz és kész, ugyanis azokra a termékekre át kell paraméterezni a rendszert. Ráadásul az is gond, hogy a kártya a maximális teljesítményhatékonyságot 95°C-on éri el, tehát ha ennél lejjebb mennek a gyártók, akkor gyorsulni fog a termék, de ha a 95°C-ot lejjebb veszik a hűtési teljesítménnyel arányosan, akkor már nem fog olyan hatékonyan boostolni a hardver, tehát teszem azt 80°C-os limitre paraméterezéssel a kártya lassabb lesz, mint 95°C-os paraméterezéssel. Ezeket sorra ki kell tesztelni, ugyanis az AMD 3%-os varianciát enged meg gyári specifikációkkal.
-
Abu85
HÁZIGAZDA
Azért tekintik ezt sokan órajelcsökkentésnek, mert nulla mérnöki tudással mérnöknek képzelik magukat. De egyszer már leírtam, hogy az adott hardver kihasználásánál nem az órajel számít, hanem az, hogy a TDP limitet elért minden egyes szituációban. Ez adja majd a legnagyobb átlagos teljesítményt, mert mindig maximális a kártya kihasználása. A Hawaii új megoldása azért áttörés, mert soha semmi nem tudott még úgy működni, hogy minden szituációban képes volt hozni a beállított TDP limitet, és a legrosszabb kihasználtság mellett is csak 1 wattra volt tőle. És az érdekesség, hogy az NV a GK110-ben is ezért vezette be a hőmérsékletfüggő turbót, mert a normál turbóval volt olyan szituáció, amikor 15 wattra voltak a TDP limittől, ami azt jelenti, hogy teljesítmény maradt a rendszerben, amit hasznosítani lehetne egy GPU Boostnál jobb technikával. Erre volt jó a GPU Boost 2.0, ami legrosszabb szituációkban 10 wattra megközelítette a TDP limitet, de az NV akkor mondta, hogy ez még mindig nem elég jó, mert az lenne az ideális, ha 1 wattra kerülnének a TDP limittől. Ezt az AMD csinálta meg a Hawaii-jal. Technikai értelemben ez a megoldás az, amiért az AMD és az NV elkezdte ezt az órajelállítást, mert a limit minden hardverben megvan, de nem mindegy, hogy mennyire hatékonyan használod a lapkát a limiten belül. A régi hardverek 30 wattra is lehettek a limittől, ami akkor jó volt, de azóta eltelt 3 év, és milliókat költenek arra a cégek, hogy 1 wattra kerüljenek a limittől, vagyis elérjék a hardver maximális kihasználását. A Hawaii az első termék, ami ezt a célkitűzést hatékonyan megvalósítja, de a jövőben mindegyik hardver ilyen lesz, mert a maximális hatékonyságra kell törekedni.
Az meg, hogy függ a hőmérséklettől az órajel. Nos, ezt az NV GPU Boost 2.0 vezette be. Pontosan azért, mert hőmérséklet fontos szerepet tölt be abban, hogy közel kerüljenek a limithez. A Hawaii ezt a rendszert csak továbbfejlesztette. Ráadásul ez a megoldás adja a legjobb eredményt az órajelzuhanásra vonatkozó fps-esésre. Mivel az órajel csökkenése folyamatos, és nem egyszeri. A legrosszabb eredményt a GPU Boost 2.0 adja, mert ott 150 MHz-et eshet az órajel egy ciklus alatt. A Hawaii maximum 10 MHz-es váltást enged meg.
---
(#720) HSM: Az, hogy ezek a rendszerek így működnek nekünk jó, mert a hardver mindig maximális teljesítményt ad le. Ha ez a technológia nem lenne, akkor a Hawaii cGPU nem skálázna 1000 MHz-re, hanem 600 MHz lenne az alapórajele, illetve az NV-nél a GK110 sem mennek 900+ MHz-et, hanem be lenne állítva fixen 500 MHz-re. Ez azt jelenti, hogy a GK110 és a Hawaii sem született volna meg, mert nem lenne gyorsabb a kisebb GPU-knál.
Ne képzeljük már magunkat okosabbnak azoknál a mérnököknél, akik óránként többet keresnek annál, amit mi egy nap összeszedünk. Az interneten mindenki olyan okos, csak azt tudnám, hogy miért nem az itt egybegyűltek ülnek ott a tervezőszékben. Talán azért, mert nem voltunk színjelesek fizikából, és nincs több mérnöki mesterduplimánk. Persze könnyebb beszólni, hogy ez így nem jó, de közben folyamatosan beszélni arról, hogy gyorsabb kártya kell, mert már nem fut 50x-es AA-val a Bátölfíld.Persze mindenkinek lehet véleménye a GPU Boost 2.0-ról és a Hawaii PowerTune-ról. Lehet anonim módon osztani, hogy fosok ezek a hőmérsékletfüggő rendszerek, ahogy mondjuk a prociknál is, hiszen azok is ugyanilyen boostot használnak. Viszont a GPU Boost 2.0 nélkül nem lenne GK110 és az új PowerTune nélkül sem lenne Hawaii.
---
(#721) players111: Ez jól mutatja a színvonalat. Érteni nem érti senki, hogy miért olyan a GPU Boost 2.0 és az új PowerTune, de biztos rossz. Én voltam a hülye, hogy megmagyaráztam.
Az meg külön érdekes, hogy a jobb megoldás van rosszabbnak beállítva. Ez annyira aranyos. Az NV mondta a GPU Boost 2.0-nál, hogy az 1 wattos limithatár elérése a cél. Itt láthatóan örültek ennek a célkitűzésnek. Az AMD elérte, most már ez rossz. Biztosíthatók mindenkit, hogy ezt az NV is el fogja érni, akkor már jó lesz?---
(#706) SzlobiG: A tekercs cicereg. Emellett ezeknek a hűtés nem számít, mert nem a meleg miatt csinálja, hanem azért, mert a gyártás során esetleg gyantahiányosak lettek, így a tekercs megmozdulhat, aztán ezzel meg is repedhet. Ez előjöhet az első használatnál, vagy esetleg egy-két év múlva … kvázi bármikor. Azt meg senki nem tudja garantálni, hogy egy tekercs tökéletes, illetve ez még nem is igazán függ a terheléstől. Szerencsére maga a gond nem okoz működésbeli problémát, amíg a tekercs a helyén marad (hova menne ugye
). -
Abu85
HÁZIGAZDA
Tökéletesen elmagyarázták a speciális helyzeteket, de nem mindenhol vették a worst case szituációt. Mondjuk ezt single GPU és AFR összehasonlításánál nehéz is. A single GPU esetében nincs rosszabb input helyzet, míg AFR-nél azért van. Sajnos az ábra nagyon le van egyszerűsítve. Ugyanis a frame-t nem ott kezdi el számolni, ahol jelzik, hanem ugyanott, ahol az unmetered esetén, csak éppen eltolja a back és a frame buffer cseréjének idejét. Ez extra lag.
Amit mutatnak, az akkor lehetséges, ha a motor fel van készítve az AFR módok megkülönböztetésére, ha ez nem lehetséges, akkor a metered és az unmetered AFR-nél is 2 frame a lag.
Az unmetered ott kerül előnybe a lag tekintetében, hogy ha még a frame n+1 előtt volt az input, annak az eredményét ugyanis eltolás, azaz extra lag nélkül számolja. Tehát amit mutatnak az hazabeszélés, mint tényfeltárás. Nem mintha mást vártunk volna, hiszen nyilván nem fogják megmutatni a jellemző szituációkat, ahol az unmetered kisebb lagot mutat. Nagyjából ekkor hagytam abba a nézést, mert csak arról volt szó, hogy ha a motorba be van optimalizálva a metered AFR direkt kezelése, akkor mi történik, de egyelőre nulla ilyen játék van a piacon. Ami előny, hogy DX9 alatt azért egész jól bele lehet nyúlni a működésbe, de a DX10 után ezt már az MS eléggé megvágta, vagyis a program oldaláról kell optimalizálni.Bevallom engem jobban érdekel, hogy mikor lesz nextgen szintű a hardver, mert sokkal súlyosabb problémának érzem, hogy a nextgen konzolok API-ja ripityára veri a DX11.1-et is. Tök jó a PC-n minden szebben fut beidegződés, csak ez már az első körben sem lesz igaz, ha a DX11.1-et nem fejlesztik tovább sürgősen.
-
-
Abu85
HÁZIGAZDA
Az AMD ilyet nem mondott, csak 4 éve, amikor beszélték, hogy az AFR implementációjuk azért ilyen, hogy az input lag alacsony legyen. 4 éve volt ez. És eleve érthető, hogy ha késleltetés nélkül kezdődik meg minden frame számítása, akkor a késleltetéssel dolgozó megoldás több input lagot eredményez.
Ez nem olyan egyszerű, már írtam. Eleve a smoothing egy GPU-ra is működik, tehát nem SLI specifikus. SLI-vel annyi a különbség, hogy két GPU-ra történik az egész rendszer feldolgozása.
Nem. Az AMD azt mondta, hogy a tesztelők kérésére raknak egy olyan megoldást is a driverbe, ami úgy működik, ahogy az NV AFR-je, de a mostani AFR marad az alapértelmezett, mert a profi játékosok jobban kedvelik ennek az előnyeit. Egy kapcsolóval lehet majd a kettő között váltogatni.
Az a baj, hogy azt hiszed, hogy az egyik AFR megoldásnak csak előnyei vannak, míg a másiknak csak hátrányai. A valóság az, hogy ami az egyiknek előnye, az a másiknak hátránya és fordítva. Olyan AFR nincs, ami minden szempontból előnyös. Ha lenne, akkor mindenki arra építene implementációt. -
Abu85
HÁZIGAZDA
Az AO-ra nem. A fake az nem jó szó. Az AO lehet scene space és screen space. Előbbi baromi jó, de ki tudja azt kiszámoltatni ugye. Utóbbi csak egy szimulált hatás, de nem fake ettől. A fake ott keletkezik, ha túlzott árnyékolásba megy át. A szimulálás jellemző minden SSAO-ra.
A fake hatás az SSAO-nál ott lehet megemlíteni általánosan, hogy nem veszi figyelembe a fény színét. Erre való az SSDO. Az új Ruby demóban nagyon sok mintával lesz használva és teljes képernyőre, így ott durván látható lesz az előnye. -
Abu85
HÁZIGAZDA
A FRAPS az funkcionálisan csak arra jó, hogy kiírja az FPS-t. Ennyi. Semmi mást nem lehet vele ténylegesen vizsgálni.
Az FCAT az jobb, hiszen megtudod belőle a displayidőt. Ezeket nem kell cáfolni.
Input lagot senki sem mér, mert ahhoz egy marha nagy sebességű kamera kell. De igazából mérni sem érdemes, mert az elvben is benne van, hogy a smoothing a számítás késleltetésével jár. De mindegy. Fentebb olvashatsz arról, hogy miért. Ha az nem elég, akkor ennyi.Dehogy szubjektív. Nézz a való világba, és a látottakat ültesd át a virtuális világba. Egyértelmű, hogy olyan erős árnyékokat nem látsz mint az SSAO-nál és a HBAO-nál az FC3-ban. A HDAO megoldása jellemzően fake árnyékoktól mentes ebben a játékban. Hogy ennél a legkisebb a változás? Hát talán azért, mert ez dolgozik a legtöbb mintával, és nem rak oda árnyékot, ahol nem keletkezne a valóságban.
Az AO az abszolút nem a fake árnyékokról szól. A szimulált screen space opciókat azért használjuk, mert az eredményük messze elég jó, és az erőforrás-igényük nem sok a scene megoldásokhoz képest. -
Abu85
HÁZIGAZDA
A FRAPS és az FCAT nem függ egymástól. Az FCAT semmit sem igényel a FRAPS-tól. De már unom, hogy ezt sokadjára le kell írnom. Vagy elolvasod, amit írok, vagy nem. Ennyi. Ha nem, akkor azt hiszel innentől, amit akarsz.
Igen a CF funkcionálisan nagyjából olyan eredményt ad a kimenetnél, mintha egy GPU-s lenne a rendszer. Pontosan ezért alacsonyabb az input lag, mintha a smootholás miatt eltolnád a frame-számításokat.A HDAO a Far Cry 3-ban a legjobb képminőséget nyúltó AO megoldás. Teljesen szabványos effekt, csak valamiért az utolsó patch óta nem jó GeForce-on. Pont az FC3-mal készítettem összehasonlítást az AO effektekről. [link]
Az meg, hogy ront a látványon ... hát egyáltalán nem, maximum akkor, ha fake árnyékokat csinál, de ez a HDAO-ra pont nem jellemző. -
Abu85
HÁZIGAZDA
Pont azt jelenti, amit leírtál. Erre panaszkodnak.
(#626) TTomax: [link] - itt leírtam, hogy nagyjából miről van szó. A Nixxes előadása nagyon jól értelmezhető. Mondhatni alapmű ebből a szempontból.
Na most a PS4 egy full integráció, míg PC-n a CPU és a GPU különálló. Rendben, hogy egy AMD64-es procival és egy későbbi HD 8000+-es Radeonnal támogatva lesz az egységes címtér, de ez nem olyan egyszerű a PCI Express interfészen keresztül. Egyszerűen túl lassú az összeköttetés ennek a fícsőrnek a hatékony használatához. Ezért nem lesz ez a VGA oldaláról reálisan kihasználható. Ha egy játék követeli az egységes címteret, akkor ahhoz Kaveri APU kell majd. -
Abu85
HÁZIGAZDA
A következő generáció ugyanaz a GCN lesz, mint a mai. A lényegi különbség annyi lesz, hogy ugyanazokat a pointereket kezeli majd, amelyeket egy AMD64-es processzor. Ez reálisan PC-n egy VGA-val nem lesz kihasználható, ahogy a multi queue compite támogatás sem. Ezeknek a funkcióknak a lényege az új generációs konzolokban lesz, illetve a konzolportok butítását megelőzendő az AMD minden konzolba tervezett funkciót belerak a Kaveri APU-ba. Ebben a lapkában lesz értelme az új GCN fícsőröknek.
-
Abu85
HÁZIGAZDA
Mármint a Bioshock finomhangolása? Én láttam a neten ilyen leírásokat. Az eredményét nem tudom, mert most nincs nálam GeForce, de valószínű, hogy van hatása.
Abban igazad van, hogy a fejlesztőknek nem így kellett volna hozzáállni, hanem egy köztes értéket keresni, ami mindkét hardvercsaládon jól működik. Jellemzően így szokás paraméterezni az UE3-as játékokat. A Bioshock-ot is illett volna így beállítani. -
Abu85
HÁZIGAZDA
Ha lehetőségünk lesz az FCAT-hoz szerezni hardvereket, akkor megfontoljuk a lehetőséget, de akkor előre beszéljük meg, hogy nem lesz abból sírás, hogy ha a kevés játék miatt az új programokkal a Radeon sebességelőnye túlzottan nagy lesz összesítésben.
A BF3 az mindegy. Az egy kommunikációs hiba a DICE és az NV között. Nem az ilyenek miatt aggódom, hanem a Tomb Raider eredményi miatt, ami az új patch mellett nagyon nem a GeForce-oknak kedvez. De jön még idén ehhez hasonló játék.(#608) Loha: Ebben nem látom, hogy hol írják, hogy a T_presenttől mér. Azt írják le, hogy a képkockákat color barozza. Ezt írom én is. Ez a display idő.
A Far Cry 3 beférne, ha méltóztatnának a fejlesztők javítani a HDAO-t az NV kártyákon. Az a baj, hogy simán beraknám a játékot, de a HDAO problémás megjelenítése és lassú számítása nem az NV hibája, hanem a játéké. Sportszerűtlen lenne ezért az NV-t lehúzni, hogy nem tudja hibátlanul futtatni a játékot.(#618) TTomax: A GCN az attól még GPU, hogy a CU-k elnagyolt logikai felépítése hasonlít egy CPU-maghoz. A feldolgozási elvet kell nézni. A CPU-k magjai LCU-k, azaz késleltetésre optimalizált magok, pár szállal és nagy gyorsítótárakkal. A GPU-k magjai TCU-k, vagyis adatpárhuzamos végrehajtásra optimalizált magok, baromi sok párhuzamosan futó szállal és relatíve kis gyorsítótárakkal. A GCN az utóbbi csoportba tartozik, csak a mai viszonyokhoz képest fel van okosítva a rendszer, hogy amitől egy hagyományos GPU kikészül, attól ez már ne készüljön ki (például feltételes elágazásokkal és soros for ciklusokkal tarkított kód). Gyakorlatilag egy működő Larrabee, az AMD lemásolta az Intel ötletét.
(#616) TTomax: Nem VRAM limites a Bioshock Infinite. Az UE3 motor nagyon finoman bánik a VRAM-mal. A gond ott kezdődik, hogy a motor streaming rendszere széles skálán paraméterezhető. Na most az amit eredetileg beállítottak arra van szabva, hogy a Radeonokon jól működjön, az NV pedig ezt használja, és a GeForce-okon nem működik jól. Ezt nagyon egyszerűen lehet módosítani az engine-höz tartozó ini fájlokban, és rögtön jól megy GeForce-on is.
-
-
Abu85
HÁZIGAZDA
Azért olyan dolog nincs, ami PRT-vel megoldható, de nélküle már nem. A PRT előnye a sebességben lesz inkább. Itt főleg azokra gondolok, hogy a nextgen Radeon és GeForce VGA-k is támogatják majd ugyanazokat a pointereket, amiket a CPU használ, csak a Kaveri x86/AMD64, vagyis az ARMv8-at támogató GeForce-ok ezzel nem fognak úgy működni, mint az x86/AMD64-et támogató Radeonok.
Jensen nem fog könnycseppeket hullatni. Ha őt a PC-s konzolportok érdekelnék, akkor nem építette volna már ma le a fejlesztői támogatást ezekre a játékokra. Az NV-t a felhő, a mobil, és a PC exkluzív F2P/MMO játékok érdeklik. Ezért engednek át szinte minden AAA PC portot az AMD-nek. Ezt az AMD sem titkolja. Roy Taylor pont mondta, hogy az NV már inkább egy smarthphone cég. Ez teljesen hihető, nyilván logikátlan azt gondolni, hogy a régebben mindent vivő TWIMTBP csupán egy év alatt leépült. Nem, ez a partnerprogram szándékosan koncentrál más területekre, és a Gaming Evolved ebből építkezik. Ha egységesen küzdenének ugyanazért a játékokért, akkor nem lenne ennyire egyoldalúan előretörő a Gaming Evolved a PC-s konzolportok területén.
-
Abu85
HÁZIGAZDA
Már írtam, hogy kevered az input lagot a frame time-mal. Azt hiszed, hogy ez a két fogalom egyenlő, de valójában nem az. A frame time az csak egy képkockára vonatkozik, míg az input lag igazából nem meghatározható így, mivel a bevitt parancsot nem tudod követni, hogy először melyik képkockán jelenik meg.
-
Abu85
HÁZIGAZDA
Érthető volt. Kifejtettem rá a választ is. Ha nem elég, akkor az már a te bajod.
(#585) gbors: Főleg azért, mert az AMD árukapcsolást használ a termékeire. A CPU-kat és a Radeon GPU-kat csomagban is meg lehet vásárolni. Ez így jóval olcsóbb, mint Radeon helyett GeForce-ot venni. Ez természetesen üzletileg törvénytelen, de az NV pontosan tudja, hogy az ilyen árukapcsolások ellen nem tesznek a hatóságok semmit, aminek régebben például az Ion látta kárát, amikor az Intel féláron kínálta az Atomot, ha chipsetet is kértek hozzá a partnerek. Ez az OEM-eknél egy vesztes helyzet. Az Ion kicsinálta tudásban és sebességben az atomos ellenfelét, de mégis alulmaradt az eladásoknál. Én aláírom, hogy elképesztően tisztességtelen volt, amit az Intel csinált, de az AMD is megcsinálja, mert ez a cégérdek.
Ezek mellett, ami az NV-nek kellemetlen lesz, hogy a DirectX 11.1-be kiterjesztésekre is van lehetőség. Ezeket természetesen lehet támogatni a konkurenseknek is, de ahhoz hardvert kell tervezni. A konzolok miatt a GDS kiterjesztett használatára és a PRT-re lesz az AMD-nek kiterjesztése. Mire erre hardveres választ adnak legalább két év. Az NV-nek most az a cél, hogy a konzolra kiadott játékokat lehessen játszani felhőből, mert más lehetőségük nincs a versenyzésre, leszámítva azt, hogy rábeszélik a fejlesztőket a PC-s port butítására és újradizájnolására, ha szükséges. Emellett nyilván nem árt leépíteni a konzolokat egy átgondolt marketingkampánnyal, ezt Tony Tamasi vállalta magára, mostanában mindenféle orbitális baromságokat nyilatkozik a konzolok kárára.
-
Abu85
HÁZIGAZDA
Mit? Azt, hogy az AMD a CF-nél az input lagot veszi figyelembe, míg az NV ezt növelve máshogy dolgozik. Szívük joga eldönteni. Más gond meg már nincs, ha megnézed a teszteket.
Ez egy olyan dolog, mint amikor az NV beharangozta, hogy az AMD képminősége rosszabb az NV-nél. Mindenki lehozta, majd később az AMD elmagyarázta, hogy az NVIDIA a shimmering jelenség eltüntetésére törekszik, míg a Radeonok a Microsoft referencia raszterizáló minőségét követik. De mivel az NV szeretné, így beépítettek egy olyan módot a driverbe, ami úgy dolgozik, ahogy az NV megoldása. Az NV akkor vett vissza, amikor látta, hogy a Radeonokon ez a mód 10%-kal több sebességet ad. Azóta az van kommunikálva, hogy jó az alapbeállítás.
Ezek mind csinált problémák, amik valójában nem is azok, csak másképp működnek. Ugyanaz lesz a vége, mint a képminőségnek. Az AMD a következő driverben belerakja, ahogy az NV dolgozik, és aztán az NV lekommunikálja, hogy jó lesz az alapbeállítás a CF-hez, mert gyorsulnak a frame smoothinggal.
Alapvető stratégiák ezek arra, hogy az emberek ne arról beszélgessenek, hogy az NV nem támogatja a top AAA címeket. Ez a valós probléma és az új generációs konzolok. -
Abu85
HÁZIGAZDA
Az a baj, hogy a népszerűek és újak is AMD-sek. Az NV-nek az új konzolgeneráció betesz. Nem éri meg ebbe pénzt invesztálni, amikor a mobil piacon a Qualcomm is nagyon keményít. Ellenük van esélye az NV-nek. Az AMD hardveres felépítését követő konzolok ellen nincs. Ezt legalább két év, mire az NV is le tudja követni egy megfelelő hardverrel, és annak is ARM processzorosnak kell lennie, vagyis a legacy programok kiesnek.
Elsősorban az idő a tesztelt hardverek szempontjából van megszabva. Nem mehet el egy VGA-tesztnél csak a mérésekre egy hét. Főleg akkor nem, amikor egy kártyával már nem lehet mérni lényeges különbségeket. Más sem mér.
Akik csak VGA-kkal foglalkoznak azoknak ez értékelhető, de nekünk csak akkor válik azzá, ha a játékok számát annyira lecsökkentjük, hogy belefér az eddigi időkeretekbe. Ez számításaim szerint maximum négy játékot jelent. Jelen pillanatban ha négy játékkal számolunk, akkor eléggé meg lenne kötve a kezünk, de a Crysis 3, a Battlefield 3, a Tomb Raider és a Bioshock Infinite lenne benne. Ezekben totál sima minden, nem számítva, hogy az új BF3 patch elrontotta az új GeForce driveren az egyenletességet, amit javítanak.
Pédlául az olyan innovatív motorok, mint ami a DiRT Showdown alatt van teljesen kimaradna. Ezzel alapvetően a jövőről gyengébb képet kapnánk. A Sleeping Dogs is érdekes abból a szempontból, hogy az AA használata rendkívül egyedi. Nem egy, hanem három megoldást vetnek be. -
Abu85
HÁZIGAZDA
Egy kártyánál nulla probléma van. Esetleg specifikus, amiről a driver nem tehet. Például a Far Cry 3-ban a MSAA mellett a Radenokra jellemzi, de ezt az fps korlátozásával meg lehet szüntetni. A konzolba kell beírni egy 999 alatti számot. A Sleeping Dogs is specfikus program. A GeForce-on nagyon pattog, de csak akkor, ha az Extreme AA rajta van a játékon. Ugyanez a gond a Sniper Elite V2-vel, de csak 4xSSAA-val jön elő GeForce-on.
Az új patch-csel és GeForce driverrel a Battlefield 3 is mikroakadásokat csinál, de az NV már szólt, hogy ezt javítani fogják, ez rendkívül speckó hiba, amit a patch hozott elő.
Szóval egy kártyával ez a jelenség jellemezően program oldalon keletkezik bizonyos beállítások mellett.Lehet, hogy csinálunk ilyen tesztet. Nem rajtunk múlik, hanem azon, hogy lesz-e hozzá hardver. Viszont erős ellenérzés az, hogy nagyon le kell csökkenteni a tesztelt játékok számát. Sok felhasználó már most is nehezteli, hogy alig van TWIMTBP AAA játék a tesztben. Szám szerint kettő maradt. Ezzel nagyon nehéz mit kezdeni, mert az NV lemondott az AAA konzolportokról. Nincs rá erőforrásuk, és a next-gen konzolokkal kapcsolatos bizonytalanság miatt a fejlesztők sem látják a helyzetet kellemesnek. A GDC alatt rengeteg vélemény alakult ki és nem vicc, hogy az AAA játékok portolását a fejlesztők jó része ahhoz köti, hogy az AMD Kaveri APU mennyire terjed majd el. Az alapvető gond, hogy a játékot PC-re rendkívül limitált funkciók mellett kell elkészíteni, mert az új konzolok képességei nem csak túlmutatnak a mai PC-s konfigurációkon, hanem a 8 darab Jaguar maggal arra vannak kényszerítve a fejlesztők, hogy az AI-t, a fizikát és a jól párhuzamosítható dolgokat nem a processzormagokon oldják meg. Ha átraksz az IGP-re olyan dolgokat, ami a játékmenetet befolyásolja, akkor csak az év végén érkező Kaveri APU lesz rá alkalmas, hogy játssz PC-n. Roppant kellemetlen probléma, és ezért fektet az AMD erőforrást a fejlesztők támogatásába, hogy akkor is adják ki a játékot PC-re, ha esetleg bizonyos funkciók Kaveri APU-t igényelnek. A többi gyártónak ez viszont nem jó, mert olyan irányba viszik a konzolok a fejlesztést, amire nem készültek fel. Az NV ezért ráállt a PC exkluzív játékokra, mert azoknál a konzolok felépítése nem számít. Mivel jellemzően AAA játékokkal tesztelünk, így gyakorlatilag három-négy játék mellett csak Gaming Evolved címeket fogsz látni. Nem csak a mostani felhozatal alapján, hanem a következő pár hónap megjelenései miatt is, mert az AMD partnerprogramjának a része a GRID 2, a Total War: ROME 2, a Company of Heroes 2, és jórészt az összes AAA cím. Később a Battlefiled 4, a Watch Dogs, a Raven's Cry, a Thief 4 ...
Egyszerűen az AAA játékok esetében kell 9 játék, hogy legalább egy TWIMTBP címet berakjunk. Hárommal csak AMD-s játékok kerülnének be.
Még a kilenc is nagyon kevés, mert jórészt a Metro 2033 tartja magát egyedüliként, hiszen az UE3-as Batmant fel fogja váltani az UE3-as Bioshock Infinite. Vannak persze TWIMTBP játékok is, de a Sniper: Ghost Warrior 2 még a készülő DX11-es patch-csel sem alternatíva, míg az MMO-k (például Neverwinter) elképesztően körülményesek (ahány mérés annyi eredmény még azonos konfigon is). -
Abu85
HÁZIGAZDA
Pont erről írtam korábban, hogy az új driverekben ezt a lehetőséget elvették a felhasználóktól. Ezért háborogtak az SLI tulajok, hogy az új driverekkel nem tudják beszabályozni a lagot, mert a driver egyéni profilt használ minden játékra, vagy a játék alapbeállításait használja.
(#575) siriq: a GPUView az ilyen. [link] - Ez marha jó tool, csak sokszáz frame-et kielemezni belőle eléggé időigényes, mert statisztikát, vagy egyszerű grafikont nem csinál.
Az NV toolja az elég jó, csak kell hozzá egy marha gyors SSD-rendszer. Emellett néztem az időigényét. Kilenc játék helyett három férne bele. Tekintve, hogy alig tesztelünk AFR-t, így a több játékot választjuk, mert egy kártyával a külföldi tesztek sem látnak problémát. -
#571
Abu85
HÁZIGAZDA
Whit3Rav3n
#568
Abu85
HÁZIGAZDA
válasz
Whit3Rav3n
#568
üzenetére
Még a Ferminél beszéltek arról, hogy kidolgoztak egy olyan módszert, hogy késleltetve számolják a frame-eket egy kártyával, mert így tudnak reagálni a frame spike-okra. Gondolom ezt a megoldást terjesztették ki az SLI-re, csak AFR-rel kell csinálni a késleltetett számítást.
Az NV-nek erről nincs mérése, de a Nixxes szokta azt csinálni, hogy a PC-s portokhoz az NV-nek más pre-render frame adatokat állít be, mert egy kártyával is késleltetve számolnak. Innen van az, hogy SLI-nél két kártyával az extra késleltetés az input lagra optimalizált AFR-hez képest +10-15 ms. Azt nem tudom, hogy más is így csinálja-e, igazából nem kötelező, csak érdemes a többletkésleltetésre a programból reagálni.
-
#565
Abu85
HÁZIGAZDA
huskydog17
#563
Abu85
HÁZIGAZDA
válasz
huskydog17
#563
üzenetére
Inkább az a kérdés, hogy hova menjenek. Nem azért van ennyi Gaming Evolved AAA konzolport, mert az AMD letarolja a piacot, hanem inkább azért, mert az NV-nek nincs rájuk erőforrása. Elviszik az embert a PC exkluzív projektek, a Tegra támogatása, ami marha sok embert kíván, és a saját motor fejlesztése, amit az NV a felhőbe szán. Ezek mellett nincs már elég erőforrás az AAA konzolportok kiemelt támogatásához. Az AMD-nek van. A Far Cry 3 is maradt volna TWIMTBP programos, de ez nem csak a fejlesztőkön múlik. Ha az NV-nek ez teher, akkor mennek máshova. Igazából az AMD is túlvállalja magát szerintem, 2013-ban mindenképp.
Javítások lesznek még szerintem. Elsősorban az NV-nek kellene megoldani, hogy végre jól működjön a HDAO. És ezt nem ártana a fejlesztőknek elintézni, mert ők rontották el.
-
#562
Abu85
HÁZIGAZDA
huskydog17
#559
Abu85
HÁZIGAZDA
válasz
huskydog17
#559
üzenetére
Lehet, hogy Ruby nem csak techdemó, hanem játék szintjén tér vissza. Igazából abba érdemes belegondolni, hogy az Illfonic egy játékfejlesztő cég, és ők csinálják a techdemót. Lehet, hogy több az amit rájuk bíztak, csak még nem beszélnek többről, mint techdemó. Eleve a csapat összesen 12 fő, tehát a Ruby demó teljesen leköti őket, viszont ennyi erőforrást belefektetve, meg abból kiindulva, hogy az egészet játékként kezdték el dizájnolni, simán lehet belőle game. Az AMD ingyen osztogatja, az Illfonic pedig felrakja steamre és abból van pénzük.
-
Abu85
HÁZIGAZDA
Az átlag frametime az elég rossz ötlet, mert az a játékokban eléggé ingadozó lehet. Ha ez alapján smootholsz, akkor a smooth nem biztos, hogy smooth lesz. A legjobb megoldás az előző frame idejét mérni, de még azelőtt el kell kezdeni a munkát, mielőtt ez kiderülne. Ezek jelentik a nehézséget.
Illetve a smoothing sémának vannak kellemetlenségei, mert növeli a driverben a hibalehetőséget. Ha több process fut, akkor a driver balanszírozhatja a teljesítményt. Ez multi-monitor környezetben kellemetlen, mert a hardver nem adja le a teljes sebességet minden kijelzőn. [link] - látható, hogy az alkalmazások nem futnak ugyanazzal a teljesítménnyel. És ez egy GTX 460 GPU. Ez az NV smoothing megoldása miatt van így. Ennek 400-500 fps között kellene mindegyik ablakot futtatni.Nem olyan egyszerű ez, mert megold egy jelenséget, aminek lesz némi ára, de ugyanakkor a multimonitor környezeteket eléggé furcsán balanszírozza. Ezért is ragaszkodik az AMD ahhoz, hogy alapértelmezett módban ne állítson fel ütemezést.
-
Abu85
HÁZIGAZDA
Pont az a lényeg, hogy ki szerint mi a normális. Ez marad az alapértelmezett CF mód, míg a másik csak egy kiegészítő lesz, amire át lehet kapcsolni. Az AMD továbbra is úgy gondolja, hogy ez a jó mód.
A smoothing esetén azért kell hangolni, mert ha fix értékkel tolod minden második frame számítását, akkor esély van rá, hogy rátolod a következő frame-re, és akkor lényegében nem tettél semmit. Ezért késleltet mindent a kiegyenlítés, így minden frame egyenletesen jelenik meg csak a normál AFR megoldás lagjához képest nagyobbal.
-
Abu85
HÁZIGAZDA
Input lagra gyúrt AFR mellett kb. olyan lagot kapsz, mint egy GPU-val. Picit többet. Amint kész az első GPU az első frame-mel rögtön fog nekifog a harmadiknak. Ami nagyjából olyan jelenetből jön, mintha az a második lenne egy GPU-s rendszernél.
A smoothing esetében az első frame lesz normál lagos. Aztán a második egy kis eltolással lesz számolva. Ezután van két referenciaidőd, és ezekből lesz mindig számolva, hogy mekkora késleltetéssel lesznek számolva a következő páros és páratlan frame-ek, amelyeknek szintén lesz idejük, és így tovább. A cél az egyenletesség. Cserébe átlagosan 10-15 ms-os plusz lagot kapsz 60 fps mellett. Ha csak az egyik kártyát késlelteted, akkor sokszor az első kártya frame-jéből lesz kevés információ. A smoothingot általánosan kell csinálni, mindkét GPU-ra. Úgy lesz teljesen egyenletes.
(#555) Loha: De könyörgöm jelöld már ki a képen, hogy hol méri az input lagot? Én csak frame time-ot látok. A frame time != input lag!
-
Abu85
HÁZIGAZDA
A marketing ezeket nem vette elő újra. Nem is részletezte. Ezt a CF megoldást azért választották, mert a profi játékosok erre szavaztak. Semmi másért. Nekik is teljesen mindegy, hogy hogyan oldják meg, mert az fps alapján ugyanott lesznek. Egyszerűen dönteni kellett, és az AMD a játékosokra hallgatott. Nyilván az elméleti alapja megvan ennek, és ez a döntés így logikus volt. Most beépítik a másikat is a tesztelők kérelmének megfelelően.
Igazából ez az egész tök lényegtelen, mert az már rég rossz, amikor dönteni kell, hogy egységes legyen a megjelenítés, vagy alacsony legyen az input lag.
Egyébként a smoothingot úgy számold, hogy minden képkockát késleltetve kezd számolni, pont azért, hogy igazodjanak egymáshoz. -
Abu85
HÁZIGAZDA
Én nem az input lagot látom, hanem a frame számításával töltött. A két dolog nem egyenlő. Arra vagyok kíváncsi, hogy hány frame jelenik meg, amíg az egéren leadott parancs megjelenik?
Olvastad ezt? [link] - teljesen érthető dolgot ír, és minden alapja megvan annak, hogy azokon a csíkokon a részleteknek nem szabad elveszni.
(#547) gbors: Az AMD erről a rendszerről, amit használnak 2010-ben beszélt, amikor elemezték az AFR-t, hogy melyik megoldás a jobb. Akkor írták le, hogy két opció van, és a profi játékosok visszajelzései alapján az input lag alacsonyan tartására gyúr a megoldásuk. Ez három évvel ezelött volt. Most csak elmondták, hogy a véleményük nem változott meg, de beépítik a másik módot is.
Azon lehet vitázni, hogy hiba-e a profi játékosok véleményére adni, de valamelyik megoldás mellett dönteni kell akkor is. Mindkettőnek megvannak a hátrányai, így olyan nem lesz, ahol kompromisszum nélkül működik majd az AFR. -
Abu85
HÁZIGAZDA
Ne idézd magad, hanem mutasd meg azon a grafikonon.
És gondolod az NV csak azért küldi ezt a kártyát, hogy az SSD-kre fellendítse a keresletet? Vagy esetleg lehet benne olyan dolog is, hogy ezzel a hardverrel működik a csomagjuk?
Gondolod ha megoldható lenne hagyományos capture kártyával, akkor tényleg olyan hardverhez kötnék a rendszert, ami brutál SSD tárolót követel? -
Abu85
HÁZIGAZDA
És hol van a grafikonon az, hogy az input lag mekkora, vagyis az, hogy az egéren leadott tüzelés mikor jelenik meg a kijelzőn?
Minden játékban be van állítva egy pre-render frame paraméter. Van olyan program, ami CF-hez és SLI-hez szándékosan más paramétert állít be.
[link] - 600 MB/s write kell. Ő is félreértette?
-
Abu85
HÁZIGAZDA
OMG. Vegyük át újra. AFR input lagra optimalizálva. Minden azonnal lesz számolva, mert ahogy jön, úgy mehet a render pipeline-ra. Magát a frame-time-ot ez nem befolyásolja, csak hamar kezdi el minden második frame számítását, így hamarabb lesz eredménye. A smoothing megoldás késlelteti minden második frame kiszámolását, így ezzel növeli az input lagot. A frame-time itt sem változik, de a késleltetés miatt a frame-ek egymás utáni megjelenítése egységesebb. Ennél érthetőbben én sem vagyok képes leírni.
Jaj értem már miért nem érted. Jó, akkor nem én magyarázok rosszul.
Tehát ez nem méri bele a késleltetést, mert csak a kimenetet látod, de az a kimenet bőven késhet. Itt arról a lagról van szó, amit a beviteli eszközön kiadott parancstól a megjelenítésig terjed. De a frame megjelenítésének idejéből honnan tudod, hogy az a frame, amihez a beviteli eszköz parancsa tartozott mikor jelent meg? Hát sehonnan. Ha nem lősz a számítás, akkor is folyamatosan ugyanúgy megtörténik.És azokból a tört képkockákból lesz 60 darab megjelenített 60 Hz-es kijelző esetén. Ha gyorsabb a kártyás, akkor több törés lesz bennük, ha lassabb, akkor kevesebb.
Maradjuk annyiban, hogy a játékok erre mindig kínálnak beállítást, de profilban mindig felülbírálják azokat a gyártók.
Az input lag pedig csak akkor nő, ha pozitív irányba növeled a pre-render számot. Az alapbeállítást csökkentve csökken. Ezért szeretik ezt az SLI tulajok.Nem tudom feltűnt-e, de ez a capture kártya azt csinálja, hogy a frame buffer tartalmát bemásolja a saját memóriájába és abból küldi ki a képet a monitorba, illetve a tárolóba elmenti. Ebből lesz sokezer tömörítetlen 24 bites képfájl, amiből az FCAT program készít egy olyan állományt, aminél a képtörésekhez színezés lesz rendelve, és ebből lehet különböző táblázatokat lekérni, amiből grafikont lehet kreálni. Egy dolog, ami kettőnk között a különbség. Én erről a rendszerről kaptam leírást. Te nem. Enged már meg, hogy az NVIDIA press leírásának tudatában kijelenthessek olyan dolgokat, hogy itt bizony semmilyen tömörített videofelvétel nincs, és olyanokat, hogy az NV 600 MB/s-os write speedet ajánl az adattárolónak.
Részemről ezt a témát lezártam, mert te csak a magadét mondod, nekem pedig sem időm, sem kedvem ezeket elmagyarázni. Főleg úgy, hogy nem is figyelsz oda arra, amiket írok.
-
Abu85
HÁZIGAZDA
Ami nem méri az input lagot, ami szintén egy fontos elem. Mondjuk ezt semmi sem méri. De gondolom eddig ezt nem értetted meg, így ezután sem fogod. Nem töröm magam.
Persze kisebb
... Mit is csinál a smoothing? Fogja magát a rendszer és késleltetve dolgozza fel a jelenet adatait. Na már ha mesterségesen késleltet, akkor hogy a fenébe lehet kisebb az input lag, amikor a késleltetés mértéke biztos pozitív valós szám ms-ban mérve. Ha kisebb lenne, akkor negatív valós szám lenne, de mivel a mai hardverek még nem képesek időutazásra, így be kell érni a fizika törvényei adta keretekkel.
Nincs olyan, hogy a képkocka túl korán jön. Az jön. Annak a számítás késleltethető, de ezzel nő az input lag.A képtörés az a kijelzett kép része. A monitor akkor sem fog 60-nál többet megjeleníteni.
Ha nem állítod, akkor is állítja a driver, mert van minden programra profilozott beállítás. De ennek az opciónak a célja, hogy SLI mellett csökkentse le az input lagot a sebesség csökkentése oltárán is. Ezért ad rá beállítást az NV. Az AMD nem ad, mert nekik erre nincs szükség. Annál kisebb input lagod sosem lesz, mint ahogy működik a CF. Állíthatod egy kártyával is, de sok értelme nincs, mivel a profilban definiált beállítások egy GPU-hoz vannak szabva.
Légyszi hagyjuk már az általad elképzeld dolgokat és szorítkozzunk a tényekre. Kurvára kell a 4 SSD, mert 60 képkockát kell másodpercenként kiírni 24 bites színmélységben. Ezt veszi be az NV-nek a programja, és ebből alakít egy tömörített állományt, amit például virtualdubbal lehet használni. De basszus milyen tömörítésről beszélsz, amikor képkockákat ment a rendszer érted ... nem videót. Képkockát! 24 bites 8/8/8-as színmélységű tömörítetlen frame buffer tartalmat. A videót baszhatom, mert nem tudja az FCAT alkalmazás beszínezni a képtöréseket.
-
Abu85
HÁZIGAZDA
És ha eltolod a frame számítását a smoothinggal, akkor még nagyobb, még jobban ingadozó lagot kapsz. A frame time ettől nem változik. Ezért van az AMD ellene, mert a profi versenyzők a lag csökkentésére koncentrálnak. Ez nem hiba, hanem döntés. Szerinted az SLI-s topikokban miért tweakelik a GeForce drivert a pre-render frame szempontjából? Hát persze, nagy az input lag. A CF-hez ilyen korrekció nincs, mert az úgy van kalibrálva, hogy minimális legyen a lag.
Egyébként az AMD és az NV számtalan dolgot másképp csinál. Például a képminőség. Az NV a shimmering jelenség visszafogása érdekében csökkenti a textúraszűrés minőségét, és így megbuknak az MS tesztjein. Az AMD az MS tesztjeinek akar megfelelni, de kapták az ütéseket, hogy bezzeg az NV másképp csinálja, mert a shimmering fontosabb. Addig erőszakolták ezt a témát a tesztelők, hogy az AMD berakott egy alternatív módot a driverbe, hogy az NV-hez hasonló szűrési minőség mellett is lehessen tesztelni a Radeonokat. Ez a texture filtering quality opció performance beállítása. De az alapértelmezett quality mód az maradt az MS tesztjeinek megfelelő megoldás. Érdekes, hogy a tesztelők kikövetelték ezt a változtatást az AMD-től, de most, hogy ott van a driverben nem tesztelnek vele.
Ez is ugyanúgy fog járni, mint a textúraszűrés. Amint ott lesz a driverben az egész el lesz felejtve. A FRAPS értelmét az NV prezentációja leépítette, míg az FCAT-ra nem lesz sok médiának pénze, egyszerűen négy SSD-t RAID-ben befogni szimplán nem éri meg, amikor mindkét AFR megoldás ugyanúgy fog működni, pontosabban az AMD driverében kiválasztható lesz ugyanaz a működés. -
Abu85
HÁZIGAZDA
Az input lagot én még egyetlen tesztben sem láttam, hogy mérték volna.
A FRAPS lényegtelen, mert az úgy sem méri a grafikus pipeline-on a működést. Ergo mindegy, hogy melyik AFR megoldást választják, mert a FRAPS eredménye a program és a D3D runtime közé ékelődik be és az alapján mér.
Mielőtt folytatnánk ezt jó lenne nem keverni a frame time-ot az input laggal. A két dolog nem egyezik. Az input lag ingadozásához nem kell CF vagy SLI. Az egy kártyánál is ingadozik. CF-nél jobban érződik, míg SLI-nél sokkal nagyobb a kiingás, mert konkrétan direkt késlelteti a frame számítását. Ez a frame smoothing alapvető hátránya, és pontosan ezért nem akarja az AMD kivenni a driverből az input lagra optimalizált AFR megoldást, mert sok multis júzernek ez jobban számít, mint a smoothing. Ez nyilván nagysebességű kamera nélkül nehezen mérhető dolog. A tesztekhez készítenek egy smoothing megoldást CF-hez, de már elmondták, hogy a mostani AFR lesz az alapértelmezett akkor is, mert erről jobbak a profi játékosok visszajelzései.A monitoron látható képkockák szempontjából mindenki olyan helyzetben van, hogy 60 Hz mellett 60 képkockát lát. Ez a kártyák számától független dolog.
-
Abu85
HÁZIGAZDA
Ezt is tárgyaltuk már itt, hogy az AFR-re két lehetőség van. A frame smoothing magasabb input laggal és a smoothing nélküli megoldás az input lag minimalizálásával. Ez nem az erős idegzetűeknek nem ajánlott, hanem azoknak, akik nem értik meg, hogy az AFR soha sem működhet jól, mert a technikának vannak korlátjai és nem a CF-nek illetve az SLI-nek. Az AMD az alacsony input lagot tartja szem előtt, míg az NVIDIA a frame smoothingot. Ezek különböző előnyökkel és hátrányokkal járnak. Éppen ezért nem fogja az AMD kivenni a driverből a mostani AFR-t, hanem mellé építi a másik megoldást, és a két mód között majd lehet váltani. Ha magas input lag jó, de egyenletesebb frame megjelenítést akarsz, akkor be lesz vezetve a frame csúsztatás. Ha idegenkedsz attól, hogy a virtuális fejlövéshez esetleg az ellen feje elé kell célozni ilyenkor, akkor pedig ott az alacsony input lagra optimalizált verzió.
Tényleg ne hidd, hogy ezekről nem tudnak semmit a rendszerprogramozók. Ezek mind ismert jelenséget, csak nagyon nehéz eldönteni, hogy a usernek melyik lesz a szerethetőbb verzió, mert olyan pro-kontra érvek cserélnek helyet, amelyeknek alapvetőnek kellene lennie. Ezért panaszkodtak egy időben az SLI tulajok, hogy kikerült a driverből a pre-render frame limitálás. Nekik ez fontos, mert az SLI AFR megvalósítása miatt a normál pre-render paraméterek mellett hátrányt élveznek. A Radeon tulajok ilyenért sosem panaszkodtak, mert az AMD CF megvalósítása eleve az input lag csökkentését tartja szem előtt. -
Abu85
HÁZIGAZDA
Ez jó kártya csak lassú. legalább olyan kellene, ami 60 fps-t rögzít. Azzal szimulálható lenne a legtöbb kijelző.
Már hogy a fenébe ne kellene? Eleve az, hogy 60 fps-sel rögzítsen frame buffereket eléggé spéci igény. Ez nem az olcsó capture kategória. De még ha a kártya nem is lenne gond, akkor a tárolórendszer az lesz alatta. Legalább négy gyors SSD kell RAID 0+1-ben.
-
Abu85
HÁZIGAZDA
A mezei kártya pont azért nem alkalmas rá, mert az fix képkockaszámot rögzít, míg az a valós frame buffer tartalmat menti le. Ezért kell a gyors tárolórendszer, mert egy frame buffer mérete Full HD-ben 6 MB, és ebből kell másodpercenként annyit kiírni, amennyi a capture szint. Persze a felbontás növelésével nő a tárolókra a teher is. 600 MB/s-os ajánlott konfig nagyjából 100 fps-ig működik Full HD felbontáson. Ha többet és/vagy nagyobb felbontásút akarsz rögzíteni gyorsabb tároló kell.
Ez nem capture kártya, hogy bárhol működhet, itt minden képkockáról egyedi kép van. Még ha meg is kapnád az NV-től a kiírást biztosító kártyát, akkor sincs meg a tárolórendszered alá.
A képminőség összehasonlítása felesleges, mert két mérés mellett sem lesz ugyanolyan az eredmény még azonos hardverrel sem. A képminőségre egyszerűbb a print screen.Otthonra a GPUView-et használjátok. Az képes elkülöníteni a folyamatokat, így abból kellő tapasztalattal minden leolvasható. Még az is, amiről a FRAPS nem ad információt, vagyis a lényeg.
-
Abu85
HÁZIGAZDA
Meg egy olyan tárolórendszer, ami képes 600 MB/s-os tempóval írni.
Azé ez nem mindegy.
Azért nincs publikus letöltő, mert a kártya, amivel működik nem érhető el kereskedelmi forgalomban. Ezt az NV adja óda, és vele együtt a szoftvert is. A tárolórendszert meg be kell szerezni. -
Abu85
HÁZIGAZDA
A mai GPU-kon is megoldható a közös címtér, mert a kártyákon ugyanaz a hardver van. Ami ezt lehetetlenné teszi, hogy az operációs rendszer nem kezeli a VRAM-ot direkten, így azt a driver mögé kell elrejteni. És ez sosem fog megváltozni, mert túl speciális a VRAM kezelése az operációs rendszer számára. A menedzsmenten szinte driverenként változtatnak valamennyit, szóval mindig el lesz rejtve a driver mögé.
A parancslistás megoldással vesztesz 10-20%-ot teljesítményben, de cserébe mindennel kompatibilis lesz, minden AFR gond megszűnik, és az interframe kommunikáció sem jelent majd problémát, ami egyre több motorban egyre nagyobb adatmennyiségre valósul meg. Szerintem egyértelműen megéri.
(#513) TTomax: Mit kell beépíteni azon, hogy a parancsokat szortírozod? Ez egy gyors folyamat a proci simán meg tudja csinálni.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
). Viszont vannak a zsíros kormányzati megrendelések. Nekik fontos az, hogy a hardverek dokumentálása jól elérhető legyen és ezért támogatják a Linuxot és a mögötte rejlő open dolgokat. Na ez az amiért Linus bemutatott, az NV ezekért a zsíros megrendelésekért semmit sem tesz.
Az meg külön érdekes, hogy a jobb megoldás van rosszabbnak beállítva. Ez annyira aranyos. Az NV mondta a GPU Boost 2.0-nál, hogy az 1 wattos limithatár elérése a cél. Itt láthatóan örültek ennek a célkitűzésnek. Az AMD elérte, most már ez rossz. Biztosíthatók mindenkit, hogy ezt az NV is el fogja érni, akkor már jó lesz?
Új hozzászólás Aktív témák
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
Megbízhatatlan oldalakat ahol nem mérnek (pl gamegpu) ne linkeljetek.
- OLED monitor topic
- MWC 2026: Kezünkben a Vivo V70, megvan a magyar ára is
- iPhone topik
- Genshin Impact (PC, PS4, Android, iOS)
- A fociról könnyedén, egy baráti társaságban
- Xbox tulajok OFF topicja
- Kerti grill és bográcsozó házilag (BBQ, tervek, ötletek, receptek)
- Starlink
- Milyen okostelefont vegyek?
- Mobil flották
- További aktív témák...
- ASUS RTX 5080 16GB GDDR7 PRIME OC - Új, 3 év garancia - Eladó!
- PNY RTX 5080 16GB GDDR7 Triple Fan OC - Garis 2028.10.01. -ig - Eladó!
- Sapphire Nitro+ RX 5700 XT 8GB Garanciával!
- Gigabyte GTX 1050 Ti Windforce OC 4GB / Nem kell hozzá tápcsatlakozó!
- Eladó GARANCIÁLIS Asus ROG Astral Nvidia Geforce RTX 5080 OC 16gb
- Samsung Galaxy A20e / 3/32GB / Kártyafüggetlen / 12Hó Garancia
- Telefon felvásárlás!! Xiaomi Redmi Note 13, Xiaomi Redmi Note 13 Pro, Xiaomi Redmi Note 13 Pro+
- MSI Cyborg 15 - 15.6"FHD 144Hz - Intel 7 240H 16GB - 1TB - RTX 5060 - Win11 - 1,5 év garancia
- Dell Latitude 3510 15,6", i5 10210U, 8-16GB RAM, SSD, jó akku, számla, garancia
- Akciós áron eladó HP Dragonfly G3 /I7-1265U/32 GB/512B SSD/13,5"/FHD+/400nit/Touch
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest