Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Van egy pár százmillió nem használt tranyó a GCN-ben a grafikus API-k szempontjából. Nyilván a natív C++ támogatás, az AMD64-es címzés, különböző DX/OpenGL-ben be nem vezetett technológiák támogatása nem olcsó dolog. Persze a másik oldalról vizsgálva ez konzoldizájnokat hozott az AMD-nek.
A GCN koncepciója meg eleve eléggé másolja a Larrabee-t, amit az Inteltől VGA-ként még nem láttunk, de kétségtelen, hogy marha jó ötletek vannak benne. Persze a Larrabee időzített bomba is, de biztos vagyok benne, hogy az vezetőség erőlteti az x86-ot, és nem a mérnökök.
Majd a Maxwellre leszek kíváncsi, hogy az NV milyen Larrabee/GCN klónt csinál. Az ARM Midgardot látva a mély integráció koncepciója egészen egyszerű alapokra is helyezhető.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Meg, de a HD 3850 minden DX11-es játékba +25-40%-ot kap a DX10.1 leskálázás miatt. A DX10-re skálázás előnytelen a compute shader és a gather4 szempontjából. Mivel a leskálázásnál nem lehet kérni egy hardverre a DX10-et, így nem lehet kiütni a modernebb API előnyét.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Pont az a baj, hogy így nem tudjuk mérni. Én próbáltam, mert van egy gyűjtő spanom a nem túl messzi faluban. Nem tudom, hogy a 30-50% plusz minek tudható be, mert nyilván az, hogy a HD 3850 gather4-ezik míg a 9600GT nem az sokat számít.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ugye te elolvasod azt, amit belinkelsz? Egyébként igaz. A Tegra 4 megveri a Tegra 3-at. Sosem állítottuk ennek az ellenkezőjét. Na de hol vannak az igazi konkurensek, mint mondjuk a Qualcomm Snapdragon S4 Pro? Ja, hogy azt nem tudja verni, így nem is mutatják. Nincs több kérdésem.
Az AMD nem közvetlen ellenfele a Tegrának, de nyilván, ha összehasonlítanánk egy Temash APU-t egy Tegra 4-gyel, akkor előbbi mérföldekkel nyerne. Csak azt gondold el, hogy a Tegra 4 IGP-jének architektúrája 2004-es (NV40) alapokra épül, míg a Temash 2012-esre (GCN). Nyolc év tudásbeli és hatékonyságbeli különbség ebben az iparban nagyon sok.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Feleslegesen húzol azzal, hogy teljesen általános dolgokról úgy nyilatkozol, mintha az AMD exkluzív fejlesztései lennének. A compute shader szabvány, és jelenleg azért tudsz játszani olyan effektekkel a játékokban, amilyenekkel, mert a compute shader létezik! Enélkül rosszabb minőségű grafikát kapnál, mert sokkal drágább lenne megoldani egy effekt számítását minden, hangsúlyozom minden hardveren!
Ha azt hiszed, hogy a compute shader neked rossz, akkor nagyon nagyot tévedsz. A Kepler valóban az eddigi legrosszabb architektúra a compute hatékonyság szempontjából, de még a képességei ellenére is gyorsabb rajta egy compute shader effekt, mintha ugyanazt pixel shaderben írnák meg. Alapvetően ez a rendszer dolga.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A Maxwellnél lesz javulás, mert arról már van olyan adat, hogy az NV olyanra tervezi, mint a GCN-t. Persze lesznek eltérések, de a koncepció megegyezik majd. A fő különbség az lesz, hogy a Maxwellt majd ARMv8 processzor mellé érdemes társítani, mert az x86/AMD64-es procikkal nem lesz kompatibilis az egységes címzést biztosító képessége. Ez várható volt, hiszen az NV-nek nincs megfelelő licence erre, de funkcionálisan a saját megoldásuk is ugyanúgy működik, mint a GCN-é, vagy az ARM-os versenytársak közül a Mali-T600-é.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ez már haladás, de kíváncsi lennék tabletes eredményre, mert a telefonokat rakják szembe ezzel, amikor Tegra 4-re inkább tablet épül. Legalábbis egyelőre három cég jelezte, hogy dolgoznak egy-egy tableten. Azt nem tudom, hogy még mennyi lesz, de a többiek inkább Qualcommra váltanak. Egy Snapdragon 800-as sorozatú termék kellene, mert ez fog versenyezni a Tegra 4 ellen. Ebből a szempontból a HTC One ér valamit a tesztből. Abban egy középszintű 600-as Snapdragon van, vagyis nem a csúcsmodell, de látszik, hogy az már így is izmos, a csúcsmodell még izmosabb.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
Nincs lényegi különbség. A BF3-ban most szerintem egy speckó probléma van, mert a régi driverekkel nem jön elő. Ahol a GeForce frame ideje tényleg számottevően gyengébb az a DiRT Showdown és a Sleeping Dogs. De inkább az előbbiben van kiugró eltérés, utóbbiban is bőven vállalható a különbség.
A Far Cry 3 szerintem egyelőre lényegtelen, mert az 1.04-es patch óta HDAO igen fura képhibákat csinál GeForce-on és a teljesítménye sincs rendben. Ezért nem tudunk vele tesztelni, mert csak Radeonon jelenik meg jól a kép. De az NV tud róla, bár nem tehetnek semmit, mert az Ubi a bűnös most. Az AMD persze rágja a fülem, hogy teszteljünk vele, mert látják, hogy a GeForce-ra nézve kellemetlen lenne az eredmény, ráadásul képhibáról is be kellene számolni, csak nem tudom, hogy mennyire sportszerű az NV nyakába varrni az Ubi hibáját. Részünkről ebből a partiból inkább kimaradunk.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Minden gyártó ezt csinálja. Nyilván nem tetszik egy cégnek, hogy ha adott a PH-nak egy programlicencet (teszem azt most az AMD a Far Cry 3-at), akkor azt miért nem tesszük bele a tesztekbe. Ennek hangot adnak, és megkérdezik, hogy mi lesz ezzel. Csak én nem vagyok hülye, pontosan tudom, hogy az AMD a saját pecsenyéjét sütögeti, és nekik kifejezetten jó lenne, ha ránéznénk erre a játékra. Rá is néztem, és HDAO-val durva képhibát csinál a GeForce. Szerinted nekem ebből nem esik le, hogy miért akarják ezt bent tudni a tesztben?
Én megmondtam nekik, hogy ezt így nem rakjuk bele, a procitesztekhez felhasználjuk, de ha nem javítja ki az Ubi a hibát, akkor a VGA teszteknél ennyi volt.Semmi infót nem ad az AMD. Minden céggel kapcsolatban állunk még az NV-vel is. Utóbbi vállalat is ad nekünk játékokat tesztre. Mindig amikor jön valami nagy cím, akkor kapjuk hozzá a kulcsot. Ezért alapvetően nem várnak el semmit, de gondolhatod, hogy nem azért adják a kulcsot, hogy mi otthon szórakozunk, hanem azért, hogy a programot viszontlássák a tesztben. Na most én speciel nem szeretem azt, amikor problémák vannak egy játékkal. Nem azt mondom, hogy nem fordulhat elő, de rontja a teszt konklúzióját, mert egy probléma miatt lett olyan az eredmény, és nem a hardver miatt. Egyáltalán nem akarunk még egy Shogun 2-t, amikor a GeForce hónapokig nem találta a teljesítményt, ezzel totálisan megnehezítve számunkra a mérést. Inkább nem is rakjuk be a potenciálisan problémás játékokat.
Tukmálni meg nem kell minket. A hardverek képességei magukért beszélnek.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A HDAO teljesítményével sincs minden rendben GeForce-on. Nem csak a képhiba van.
A HBAO-t azt nem preferáljuk, mert rengeteg hamis árnyékot csinál. Olyan helyeken keletkeznek, ahol nem lehet megmagyarázni, hogy mégis mitől született meg. Valamiért ez az effeft nagyon gyengén van paraméterezve a Far Cry 3-ban, valószínű, hogy a kevés mintavétel az oka. Még az SSAO is számottevően jobb, de a minőségben messze a HDAO viszi a pálmát.
A HBAO akkor jó, ha úgy paraméterezik, mint a Hitman: Absolution alatt. Persze ilyenkor a teljesítmény durván esik tőle. Valszeg ezzel az Ubi úgy volt, hogy raknak három különböző teljesítményű és minőségű SSAO-t a játékba és válaszd ki, amelyik jobb. Az FC3-ban a HBAO képviseli a low szintet, az SSAO a medium és a HDAO a high. A teljesítményigény is így nő.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Szerintem egy játék alapján ebből ne induljunk ki. Azon belül, hogy számos képkockára korlátozott AO algoritmus létezik, még ezek az algoritmusok is igen széles skálán paraméterezhetők függően attól, hogy minőség vagy teljesítmény kell.
A játékokban nem azért szép a HDAO, mert maga az algoritmus működése a legszebb képet adja, hanem azért, mert ma ezt paraméterezik úgy, hogy a legszebb képet adja. A kettő nem ugyanaz. Ez teljes egészében fejlesztői döntés. A HDAO-val azért bánnak bőkezűen, mert compute shaderben van írva, így a gather4 és az LDS támogatás miatt jóval gyorsabban dolgozik egységnyi mintával, mint a többi megoldás. Ezért jóval több mintát is rá lehet ereszteni. Ez adja a képminőségelőnyt. De a HBAO ugyanannyi mintával és teljes felbontáson jobb minőségre lenne képes, csak a teljesítményt sokkal jobban megenné mint a HDAO.
A jövőt tekintve olyan megoldásokat tartok reálisnak, mint amit a Hitman használ. A Nixxes átírta compute shaderre a HBAO-t keverve a HDAO-val, és ezzel most ennek a játéknak a legjobb az SSAO megvalósítása.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
És az mennyire a mi hibánk, hogy magas grafikai részletesség mellett az új DX11-es játékokban az AMD architektúrája jobban működik?
A DiRT nem az AMD nyomására van bent. Egyszerűen azért, mert az első játék, ami forward+ lighting modellt használ. Ez az elmúlt évek legnagyobb előrelépése, mert a deferred render problémái nélkül lehet 2000-3000 pontfényforrást hatékonyan feldolgozni. A Sniper Elite V2 az SSAA miatt van bent a tesztekben.
Az NV-től nem tudunk új játékot berakni. Az AC3 egy vicc, mert 20-30 fps-sel sorakoznak egymás mögött a kártyák. Egy kemény procimagot használ. Az elején tudunk mérni, de az meg sokkal jobban fut, mint városi pályán. A másik lehetőség a Passion Leads Army, de az csak keleten, Kínának elérhető.
Az a baj, hogy az NV egy más irányt vett. Ők eldöntötték, hogy a F2P és az MMO játékok jelentik a PC jövőjét ... amiben egyébként lehet, hogy igazuk van. Az AAA játékok támogatását nagyon erősen visszafogták. Az AMD pont ellentétes irányban dolgozik. AAA játék előnyben, míg az F2P és MMO támogatás vissza van fogva. Az is lehet, hogy ebben benne van a next-gen konzol irányzat is. Az a legkevésbé sem jön jól az NV-nek, hogy az AMD ezekbe berakta a hardverét. Egy portolt játéknál az NV eleve hátrányból indul majd. Egy PC exkluzív játéknál ez nem lesz így.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az Anno 2070-hez hozzátartozik, hogy számunkra valóban kényszerű döntés volt. Egy stratégiát mindenképp akarunk tesztre, mert ez a műfaj is létezik. Ellenben a Shogun 2 az NV-n 8 hónapig problémásan futott. Jött egy driver, majd jött egy patch, ami ismét lerontotta a sebességet. Na most nekünk ez rémálom volt végig, így váltottunk Anno 2070-re, mert az kiszámíthatóbb.
Az NV a DiRT-ben igen komoly optimalizálásokat kapott. A különbség oka szimplán hardveres. Az AMD-től mondta Dave, hogy ők lepődtek meg az első Kepler teszteken a legjobban. Máig nem értik, hogy az NV miért nem a fejlesztők által kért irányt vette alapul. Nem volt előlük eltitkolva semmi. Én egyedül a Tegra miatt láttam koncepciót, de most, hogy az is maradt az öreg architektúránál érthetetlen a Kepler.
Lehet, hogy az NV azt gondolta, hogy a fejlesztők nem érdekeltek az új effektekben, ha csak az egyik architektúra veszi fel a kért irányt? Ez nem hangzik logikusan, illetve veszélyes is.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Csak még annyi, hogy a veszélyes mit jelent. Az AMD erre egyre jobban rájátszik.
A GDC-n az előadások lassan körvonalazódnak:
"DirectX 11 Performance Reloaded" ... Olyan azonnal és könnyen beépíthető optimalizálások, amelyek begyorsítják a feldolgozást. Minden hardveren, de legfőképpen a GCN-en.
"DirectCompute for Gaming : Supercharge your engine with Compute Shaders" ... A cím magáért beszél.
"Tile-based forward and deferred rendering" ... A forward+ modernizált verziója és az a verzió, ami deferred render motorba is beilleszthető, és ezzel az átlátszóság problémája nagyon könnyen kezelhető.
Összességében évek óta létező problémákra, gyorsan beépíthető és hatékony megoldások. És a baj, hogy ezektől a Kepler is gyorsul, vagyis miért ne építeni be a fejlesztő, adódik ugye a kérdés. Érvet nem tud ellene felhozni, mert az alapvető cél, hogy az optimalizálással minden hardveren jobban fusson, és ez jó a felhasználónak.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
De az FX-nek nem az volt a baja, hogy sokat akart, hanem, hogy rosszul akarta azt. Felkészítették a feldolgozókat a 32 bites feldolgozásra, de az adatutat 16 bit/operációra optimalizálták. Ha ez 32 bit/operáció lett volna, akkor tökéletesen helytállt volna a hardver. Persze ez nem kevés tranyót igényelt volna. Az FX túlteljesítette a DX precizitásra vonatkozó speckóját, ami nem baj, csak mi értelme ugye. Ezeket a GCN nem teljesíti túl, ugyanazt tudja, mint a Kepler, vagy mint a többi DX11-es hardver. Van amiben túlteljesíti persze, de azok konzol design wint hoztak. Ott a PRT. Egy jó darabig biztos nem lesz szabvány, mert nem olyan könnyű hatékonyan hardverbe implementálni, de DX kiterjesztése hamarosan lesz (OpenGL-re már van). Most mindenkinek, aki nem szoftveres megatextúrázást akar a játékban ezt támogatni kell, és ez tök kellemetlen dolog lesz a konkurenseknek. Le kell követni az AMD-t a nem szabványos technikákban, vagy számottevő hátrány lesz a PC-s portok alatt.
A Doom 4 jó alap lehet erre, mert az a megatextúrázás hardveres implementációját PRT-n keresztül oldja meg. Ennek az egyik nagy hátulütője, hogy a szoftveres implementációt ehhez kell igazítani, és a szoftveres virtuális textúraméret esetében a 32k nem optimális. 64k lenne az, de azt nem támogatja a PRT, mert a hardvernek meg a 32k az optimális. A szoftveres megoldás húzta a rövidebbet, vagyis még rosszabb lesz az élmény, mint a Rage esetében.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
De azzal nem tudunk mit kezdeni, hogy az új DX11-es játékokban igen erős a GCN fölénye. Ez a hardver miatt van. Az NV máshogy tervezte a Keplert, mint az AMD.
Tudunk az AC3-mal mérni, ha kerüljük Bostont. Én ezt megnéztem pár hete. Bostonban a nálam lévő kártyák megakadtak 25-30 fps-en. Egymás mögött sorakoztak konkrétan. A játék elején, amikor kezdődik elég szépen skálázódnak, csak az eredmény nem biztos, hogy reális, mert a GTX 670-et simán verte a HD 7850 fps-ben. Előbbi 45 fps-re volt képes, míg utóbbi 55-re. Ezt a mérést be tudjuk rakni, csak sem a játék egészére, sem pedig a VGA-kra nézve nem reális. Egyszerűen annyira rossz a motor optimalizálása, hogy iszonyatosan torzítja az erősorrendet, vagy jön a CPU-limit.
DX9-es progikkal már nem foglalkozunk. Ezek DX11-es hardverek ott kellene teljesíteni. Elég sok jó DX11-es játék van.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A Crysis 3 az DX11 és Gaming Evolved is. A sebesség ezzel nem függ össze. Főleg a fejlesztői döntéseken múlik, hogy mennyire komplex effekteket raknak egy játékba és hogyan. Főleg a gyorsítóstruktúrával implementált dolgok esetében lesz komoly különbség az architektúrák között.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ez bonyolultabb ennél. A fejlesztők elég sokat nézelődnek a különböző gyorsítóstruktúrák felé, aminek a nevében is benne van, hogy gyorsítják a feldolgozást minden hardveren. Például a forward+ azért fut egyáltalán a mai DX11-es hardvereken, mert használ egy per-tile listázást a fények kivágására. Enélkül jóval gyengébb sebességre lenne képes minden hardveren. Ezért építenek be gyorsítóstruktúrát, és itt jön az, hogy az adott hardver ebből mennyit profitál. Alapvetően mindegyik jelentőset, de a GCN felépítése kifejezetten úgy lett kialakítva, hogy ezeket a komplex megoldásokat sokkal hatékonyabban dolgozza fel, mint a korábbi architektúrák. Innen jön a sebességkülönbség egy része.
Egyébként persze. Vannak problémák és arra vannak koncepciók, amik az adott problémát megoldják. Nem csak a forward+ lighting az egyetlen megoldás arra, hogy forward render mellett hatékonyan kezelj többezer pontfényforrást. Láttam már számos implementációt, de a forward+ lighting ezek közül a leggyorsabb. Sőt, tulajdonképpen az egyetlen, ami összességében gyorsabb az ismertebb deferred render implementációknál.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A user szempontjából csináljuk a teszteket. AAA DX11-es játékok. A technikai részleteket nem kell elolvasni, de leírom, ha szükséges.
A Crysis 3 be lesz véve a tesztbe. A Titános tesztben még nem biztos, hogy benne lesz, mert ott rosszul jött ki a lépés, de egyértelműen számolunk ezzel a játékkal.
Ha lesz jó DX11-es F2P játék, akkor berakjuk tesztbe, de amíg sokkal jobb AAA játékok jönnek, addig nem sok esélyük van.
Persze, azokra várunk, hiszen az AAA címek viszik előre a piacot. Egy F2P cím sokkal kisebb érdeklődést kap.
Az valóban fejfájást okoz, hogy az NV az AAA játékokat nagyon hanyagolja, de azért még annyira nem vészes a helyzet. Ott lesz az új Metro például.A távoli jövőbe nem látunk, de valószínű, hogy az NV nem érzi magát biztosítottnak a konzolportok szempontjából, ezért nyitnak a PC exkluzív játékok felé. Ez érthető, mindegyik konzolban AMD hardver van, és olyan egyedi szolgáltatásokkal, amelyeket a grafikus API-k nem követelnek meg, de kiterjesztés formájában elérhetők. Emellett ott van még az is, hogy az NV képtelen lesz támogatni az (x86-64)/AMD64-es porcik címterét, mivel az ARMv8 irányába léptek. Ha az adott játéknak nem lesz ARM portja, akkor az az NV-nek komoly hátrány, mert csak az AMD-nek lesz rá platformja. Ilyen viszonyok mellett én sem bíznék a konzolportokban, mert kockázatot rejtenek. Bár én úgy gondolom, hogy az ARM-os átállás gond nélkül lezajlik majd. Az NV-nek egyedül a legacy programkompatibilitás hiányával kell megküzdenie.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az egyetlen szépséghiba, hogy GPU-s gyorsítás nélkül használja a PhysX-et. A CD Projekt máskor is dolgozott vele, például a Witcher első részénél. A next-gen konzolok miatt jelentősen fejlődött a PhysX SDK. A 3.2-es verzióban számos olyan megoldás, ami eddig nagyon lassú volt processzoron, most gyorsabb egy szimpla négymagos CPU-n mint GPU-val gyorsítva. Ezzel a PhysX reális alternatívája lett a Havoknak, mert nincs agyonkorlátozva a CPU-s része, hogy a GPU-s gyorsítás valóban gyorsítás legyen és ne lassítás.
Az egyetlen dolog, ami gyorsítás valóban az a particle része a motornak. Ezt lehet természetesen használni, de szintén a next-gen konzolok miatt érdemes egy saját megoldást írni helyette. Például az Unreal Engine 4-ben ez nincs is benne, így a motor a PhysX helyett erre egy saját kódot használ. Ezért futott PS4-en az Elemental demó GPU-val gyorsított fizikával.
Ami majd érdekes lesz az az új PhysX SDK. Mivel az NV-nek is lesz ARM-os APU-ja 2014-ben, így sokkal hatékonyabban tudják kihasználni a GPGPU-t, mint eddig, mert a PCI Express késleltetése nem korlátozza a feldolgozást. Azt el tudom képzelni, hogy a PhysX fel lesz használva egy mézesmadzagnak, hogy ne Intel és AMD APU-t vegyél, hanem az NV-től egy ARM-os megoldást. Nyilván a legacy kompatibilitás hiányát valamivel ellensúlyozni kell.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Fel kell rakni a 13.2 beta6 drivert. A kopaszodás ezzel megszűnik. Ez a gond ugyanúgy driverben lesz javítva az NV-nél is.
A fő különbségeket a Tomb Raiderben a High Precision, az SSAO, a shadows, a DoF és a TressFX adja az architektúrák között. Ezek használnak compute shadert, illetve az FXAA még, de az annyira nem terhel.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#35434496
#422
üzenetére
Az ám.
Egyébként az alapvető probléma az volt, hogy a végleges kódot a cégek nagyon a megjelenés előtt kapták meg. Ami a régi driverekben volt profil az megkopaszította Lara-t, mert a végleges kódban megváltozott a TressFX. Még a patch is változtatott ezen.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A rutinok mellett vannak profilok is. A 13.2-es driver nem tartalmaz CAP opciót, míg a korábbiak igen. Ha valami fennmaradt a korábbi drivereknél a CAP-ből, akkor az működni fog a 13.2 mellett is, holott pont nem kellene.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Én harmadjára fogok neki, és nullaszor futottam bele. És ez a beta6 driver. De amúgy a beta4 unofficial changelogban van benne, ha Lara TressFX hajának eltűnése javítva lett. Csak amikor megjelent ez a driver, akkor még nem volt játék, így ez a tényleges leírásból kimaradt, mert a felhasználó úgy sem fogja látni. Rengeteg javítás van a béta 7-ben BioShockhoz is, ami szintén nem jött még ki.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nagyon jó az Anand cikk. Pontosan azon gondolkodtam én is, hogy a GPUView az ami jól mutatja ezeket, csak rohadt bonyolult. Az Anand cikk szerint az AMD és az NV sem tekinti a FRAPS-ot mérvadónak a működéséből eredő hátrányai miatt. Végre érthetően elmagyarázza valaki, hogy a FRAPS-szal mi a gond.
Az AFR része nagyon érdekes, hogy a CF kap frame packing módot, de megmarad a low latency mód is. Gyakorlatilag az AMD a júzerre hagyja a döntést, hogy simább képkockaszámítást akar, vagy kisebb késleltetést. Bár ebből a szempontból az AFR még mindig egy kisarkított technika. Gyakorlatilag mindegy, hogy honnan közelítik meg a működést annak biztos, hogy valahol hátránya lesz. Talán az NV-nek és az AMD-nek tényleg ideje lenne elgondolkodni azon, hogy az AFR helyett valami kevésbé limitált technikát használjanak. Úgyis egyre több a mai motorokban az interframe kommunikáció, ez az SLI-t és a CF-et nem szereti.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Tudom, de az annyira nem észrevehető, maximum mérhető. Én is láttam ilyet a Boostos GTX 670-en. A Sleeping Dogs-ban, +/-150 MHz-eket ugrált a korábbi tesztkártyánk és hirtelen. Ezért lenne jobb hardveres turbóra váltani, mert ott a hardveres kiértékelés finomabb vezérlést tesz lehetővé.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A PowerTune az csak mínuszos módban kap engedélyt maximum 50 MHz-es órajelváltozásra. Normál módban maximum 10 MHz változás van engedélyezve egy váltás során. Plusszos módban van ez a limit feloldva, mert akkor már a hardver védelmére megy a rendszer. A normál mód eleve úgy van belőve, hogy sose változzon az órajel egy játékban.
A Boost funkció képes többet csinálni. Az gyakorlatilag úgy van kalibrálva, hogy a state 3 (alapórajel) és 4 (Boost órajel) között ugorjon.
Az új gen2 PowerTune bonyolultabb, az eleve nem is jelez vissza valós órajelet.Nekünk ez az NV által küldött kártya. Gondolhatod, hogy a legjobban boostolót adják ide.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A PowerTune profil driverenként változtatható. Ezt tölti be a hardver a Windows indításakor, és a profil leírása alapján dolgozik a továbbiakban. A profil változását nem jelzik, mert a normál módban eleve nincs hatása ezeknek a módosításoknak, hiszen ott nem skálázódhat az órajel, de az overdriver modul az elmúlt évben folyamatosan frissült. Még a 13.3-as driverben is változott. Ezért zseniális ez a rendszer, mert hardveresen működik, de ez szoftveresen paraméterezhető. Nem véletlenül nincs publikusan specifikálva, mert ma mindenki ezt akarja másolni.
A FRAPS méréseknél lehet ezzel probléma, de az NVIDIA is a FRAPS latency mérések értelmetlenségét próbálja magyarázni a tesztelőknek. Ebből a szempontból az AMD-vel egyetértenek. A GPUView az erre való eszköz (vagy valami hasonló), a FRAPS túl általánosan kezeli a dolgokat.
Igazából ahol ez tényleg gondot jelent, azok a Sleeping Dogs-féle igen szélsőséges terhelést kifejtő játékok. Ennél sokkal nagyobb gond például a Tomb Raider, ami agyonterheli a hardvert, és ez szoftveres védelmekkel necces. Gondolom olvastad, hogy az NV a fórumán a gyárilag tuningolt kártyák órajelének csökkentését javasolja, mert egyszerűen túlságosan terhel a játék. Erre be lehetne vetni egy Furmarkos lefojtó profilt, csak itt fps-ekért megy a harc.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
M@trixfan
#469
üzenetére
A FRAPS-szal mindkét cégnek az a baja, hogy olyan dolgokat is jelez, ami nem a VGA vagy a grafikus alrendszer miatt következik be. A GPUView-vel lebontható az egész folyamat a részletekre, így csak az is vizsgálható, ami a GPU és a grafikus alrendszer oldalán történik.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ez valóban fura, mivel a benchmark rendszertelenül, de 10-15 fps közötti minimumokat is mér NV-n, míg az AMD-n 30 alatt nem mértem.
Ahogy néztem más is ezt mérte. [link]Gondolom a guru Fraps-szal nézte, vagy valami hasonló elven működő eszközzel. Azért fontos észben tartani ezt az ábrát, ami mutatja, hogy a FRAPS,és a többiek hogyan működnek. [link]
A GPUView erre a célra a megfelelő eszköz.Szerk.: Épp most futott be, hogy jön egy patch a játékhoz, ami tovább optimalizálja a működés.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A Far Cry 3 az korrekt összevetés. Hiszen a HDAO csak 6x annyi mintával és csak négyszer akkora felbontáson dolgozik, mint a HBAO. Abszolút nem gáz a Radeonnak ekkora többletterhelés.
A legtöbb teszt abból a szempontból nagyon érdekes, hogy nem írja le, hogy az AFR-nek két megközelítése van. Az egyik a késleltetés csökkentése, míg a másik a frame időzítése. Az előbbinek az előnye, hogy az egéren kiadott parancs (lövés) és annak a visszaigazolása a kijelzőn (a megtörtént lövés) hamarabb történik meg, de hátránya, hogy a framek időszerűtlenül jelennek meg. Utóbbi pont az ellentettje ennek. A framek szabályosabban lesznek megjelenítve, viszont az input lag jelentősen megnő. Az AMD szerint az input lag a fontosabb, mert a user a reakcióra jobban odafigyel, míg az NV szerint a framek időzítése fontosabb, és a magasabb input lagot a felhasználó meg tudja szokni. Ez a különbség a CF és az SLI között. Szimplán koncepció.
Sajnos nem egyértelmű, hogy melyik a jobb, és az NV be fogja építeni, azt amit az AMD használ, és az AMD is azt, amit az NV használ. A user majd kiválatszja, hogy alacsonyabb input lagot akar, vagy egyenletesebb megjelenítést.
Igazán szomorú, hogy a média jelentős része ezekkel a technikai dolgokkal egyáltalán nincs tisztában. Egyedül az Anandtech, ahol ezt elemezték.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az a baj ezekkel az effektekkel, hogy ha a valósághoz közel viszed a minőségét, akkor nehezen látszanak, így inkább túllőnek azon, ami nem valósághű, de legalább látszik.
Nézd meg a Tomb Raidert. Ott eléggé úgy van az egész dizájnolva, hogy ne legyen elrugaszkodva a valóságtól, viszont ritkán vehető észre, hogy vannak benne ezek a post-processek. Persze én ennek örültem, mert végre nem lőttek túl a célon, csak sokan úgy kapcsolgatják ki az effekteket, hogy befelezi az fps-t, de nem is látszik. Közben pedig csak úgy van megcsinálva, hogy ott látszódjon, ahol valóban van értelme, mert valósághűen van dizájnolva.(#493) Whit3Rav3n: Szerintem nehéz eldönteni, hogy az input lagra, vagy az frame smoothing a jobb. Főleg akkor, amikor 1000 Hz-es egereket használ a gémer, hogy 8 ms helyett 1 ms legyen a beviteli lagja. A frame smoothing AFR-től nem extra 7 ms-ot kapsz, hanem extra 15-20-at, ha 60 fps környékén van a sebesség. Ha esetleg 30 fps környékén van, akkor 30-40 ms-os többletről beszélünk. A gémerek szentül mondják, hogy ők a +7 ms-ot érzik a gamer egérrel, tehát logikus, hogy a ennek minimum a kétszeresét is érzik. Ez volt a CF kiindulópontja. És máig lehet olvasni, hogy pár gémer arról számol be, hogy a CF-fel jobb a gép reakciója. Ezért nem veszi ki az AMD ezt a módot, sőt, konkrétan ez marad az alapértelmezett, de a nem hardcore gémereknek lesz egy frame smoothing AFR, amivel az extra lagot megkapják. Ezt majd a reakcióra gyúró réteg nem fogja szeretni, de lehet majd választani a driverben.
Egyébként önmagában az, hogy dönteni kell az input lag és a frame-ek egyenletes megjelenítése között elég komoly probléma. Bármelyik AFR opció is van kiválasztva annak meglesz a maga hátránya. Ebből a szempontból az AFR szerintem hosszútávon nem járható út. Már ma sem tekintem annak. A casual gamereknek elfogadható, de a hardcore rétegnek az egyik AFR irány sem elég jó.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#498
Abu85
HÁZIGAZDA
ricshard444
#497
Abu85
HÁZIGAZDA
válasz
ricshard444
#497
üzenetére
A developer buildeknél ez jellemzően előfordul. A PS4 a szoftveres oldalon messze nincs még kész, míg PC-re egy kész környezetben dolgoztak. Ez eleve a DX wrapperen keresztüli verzió, illetve ebben még nincs is benne a PRT támogatás, ami a motor új verziójában benne lesz. Ennél sokkal jobb minőséget és sebességet kihoznak majd belőle, csak az aktuális motorverzióval még nem lehet. Demonstrációra viszont megfelel, mert most kellenének a licencelők, csak mindenkit a Frostbite 3 és a CryEngine 3.5 érdekel, mert ezekkel olyan játékokat is lehet fejleszteni, amelyekből mehet az Xbox 360 és a PS3 port is. Az Unreal Engine 4-gyel ez lehetetlen.
(#499) ricshard444: Persze ez valóban nagyon fontos, csak most még nem lényeges.
Sokkal komolyabb probléma is van ezzel az UE4-gyel. Gyakorlatilag PC-n, PS4-en és új Xboxon kívül sehova máshova nem alkalmas. Wii U mehetne még, de azt leszavazta az Epic. Ehhez képest a zömében hasonló képességű konkurensek (Frostbite 3 és CryEngine 3.5) sokkal több platformra elkészülnek. Ebből előbb-utóbb egy újratervezés lesz, mert compute shader futószalag nélkül nem fut a megvilágítási fázis.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az input lag az az egérgomb lenyomásától a képernyőn megjelenő tüzelésig tart. A frame számításának ideje nem változik, csak a képkocka kirakását késlelteti a smoothing. Ez nem mérhető szoftveresen. Esetlen burtálnagysebességű kamerával manuálisan mérhető lehet, hogy hány ms telt el az parancs kiadása és a látható hatása között.
(#501) gbors: Ezek hardcore játékosok a 60 vs 120 fps különbségét észreveszik 60 Hz-es kijelzőn.
Mindig növeli, mert mindig késleltetni kell minden második képkocka kirakását. A növekedés mértéke az aktuális fps-től függ. Alacsony ~30 fps mellett tényleg észrevehető lehet.
Igazából pár hét múlva ez nem lesz dilemma. Mindkét cég beépíti mindkét módot a driverbe. Tényleg nehéz eldönteni, hogy melyik a jobb. Valójában egyik sem elég jó.
(#502) daneeeeee: Ez nem ilyen egyszerű. Az Epic is ezt mondja, hogy van UE3, csak azért elfelejtik, hogy a cégek nem így működnek. Ha van egy projekt, ami elkészül az aktuális konzolokra, a nextgen gépekre, PC-re, illetve esetleg a Nintendo Wii U-ra, akkor az Unreal Engine 4 kiesett. Hiába jó a motor egyszerűen a megcélzott gépek felén működésképtelen. Nézd meg az alternatívákat. Az előbbi igényeket a Frostbite 3 és a CryEngine 3.5 megoldja. És mindkettő sokkal jobb minőségű grafikát tesz lehetővé az aktuális konzolokon, mintha az UE4 játékot átdizájnolnák UE3-ra. Sem anyagilag, sem minőségben nem éri meg. Az UE4 jelenleg csak azoknak a fejlesztőknek lehet alternatíva, akik csak PS4-re, PC-re és új Xbox-ra dolgoznak. Látható, hogy az eddig bejelentett projektekből kimaradnak a régi rendszerek. Valami csak PC-re jön.
Az UE4 egyébként egész jó, legalábbis az előrelépés tényleg nagy. Ennek viszont azért komoly hátrányai is vannak. Úgy gondold el a motor felépítését, hogy a megvilágítási fázishoz olyan rendszert használ, amit eddig soha senki. Ez az ami nem fut a régi hardvereken, vagyis, ha ezt kikapcsolják, akkor konkrétan nem lesz a pályán megvilágítás. Ergo nem kikapcsolható technika. A másik gond vele, hogy nagyon számításigényes. Ezért van compute shaderben írva. Alapvetően a VCT-hez fel kell építeni egy sparse adatstruktúrát. Ezt nem minden képkockára kell, de a jelenet változásával nyilván tartania kell a lépést a voxelizációnak Na most ezt a jelenlegi motor szoftveresen építi fel a GPU-val, de ez nem mondható annyira gyorsnak. Lehet persze hardveres implementációt is használni, és az új konzolokon nyilván az AMD PRT-jével fog működni (ez lehozható PC-re is), mivel számottevően gyorsabb. Itt mákolt az Epic, hogy GCN-t kap az új Box és PS.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#505
Abu85
HÁZIGAZDA
Whit3Rav3n
#504
Abu85
HÁZIGAZDA
válasz
Whit3Rav3n
#504
üzenetére
Szerintem rég rossz, ha valamelyik oldalon meg kell kötni a kompromisszumot. Én magasabb input lagra sem szavaznék.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Pont ez a lényeg. Érdemes-e azt tovább növelni? Mi az a határ, aminél még jó? Nehéz kérdések. A megkerülő válasz erre, hogy gáz az AFR mód multi GPU-hoz. Mindegy, hogy hogyan csinálod meg, valahol kompromisszum kell. Azzal nem változik a helyzet, hogy az NV és az AMD a user kezébe adja a döntést, hogy hol legyen a kompromisszum. Ez az alapprobléma szőnyeg alá söprése. Itt nem a részproblémákat kellene orvosolni, hanem amiből ez az egész gond ered. Olyan, mint a körömgomba. Gyökerestől kell kezelni.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#511
Abu85
HÁZIGAZDA
Whit3Rav3n
#510
Abu85
HÁZIGAZDA
válasz
Whit3Rav3n
#510
üzenetére
Osszuk el a parancsokat. Nem lesz 90+%-os skálázódás, csak 70-80, de minden AFR-re jellemző kritikus problémának vége. Utóbbi szerintem sokkal többet ér.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Én megmondtam nekik, hogy ezt így nem rakjuk bele, a procitesztekhez felhasználjuk, de ha nem javítja ki az Ubi a hibát, akkor a VGA teszteknél ennyi volt.
Azé ez nem mindegy.Ú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.
