PCTuning fórum

webwalker píše: Takže díky všem, co se podíleli na této diskusi a přispěli k vývoji FrapsCutu, jehož další vývoj tímto zastavuji. Budete trvale uvedeni jako testeři v okénku "About FrapsCut", i když vám to bude asi prd platné

Heh, takze je nakonec dobre, ze ja jsem vyvoj zastavil uz pred mesicem. Ale ne teda kvuli nepresnosti frapsu, ale kvuli nedostatku casu.

I tak budu ve svych testech pouzivat fraps dal, i pres jistou nepresnost jsou vysledky porad lepsi, nez jen avg fps... A taky se mi nechce tu spoustu casu stravenou vyvojem jen tak zahodit.

havli: co sem procetl ten clanek na Anandtechu, tak fraps je dobry jen na ty FPS vzhledem k tomu, ze snima data po odeslani aplikace a nevidi na podstatnou cast zpracovani snimku.

The problem here is not in using FRAPS to measure average framerates over the run of a benchmark, but rather when it comes to using FRAPS to measure individual frames. FRAPS is at the very start of the rendering pipeline; it’s before the GPU, it’s before the drivers, it’s even before Direct3D and the context queue. As such FRAPS can tell you all about what goes into the rendering pipeline, but FRAPS cannot tell you what comes out of the rendering pipeline.

Jasne, ja jsem ten clanek cetl taky. A nechapu jak je teda vlastne mozny, ze se nameri ohromny rozdily mezi single/multi GPU.... a presto tam jsou. Treba GF7 SLI ma dvojnasobek fps nez single, ale realna hratelnost je stejna - a to samy je videt i v grafu frametimes. Takze nejakou vypovidajici hodnotu to ma. Porad lepsi, nez klasika avg fps, tam se neduhy SLI/CF neprojevi vubec.

@adamV: Koukám jak blázen, kdopak to sem všechno nechodí
No, hodně rychlé to být muselo. Co zbývá, nejsem blázen
FrapsCut je vlastně jenom analyzátor, který nějakým způsobem analyzuje data. Pokud jsou vstupní data vadná, tak nějak ta analýza ztrácí svůj smysl a kdokoliv ji může napadnout. O tom, že Fraps úplně přesný ani být nemůže jsem věděl, jen jsem myslel, že to tak hrozné nebude. Jinak díky za postnuté výsledky, samozřejmě na ně kouknu, ale i tak si myslím, že v každém případě u "nagrabovaného" videa s identifikací všech snímků bude následná analýza vždy lepším řešením, než matematickou analýzou. Prostě když na videu uvidíš nějaký vizuální zádrhel (stutter, MS ...), hned také vidíš i snímky, které to způsobily. Tohle FrapsCut nikdy nedokáže.

@havli: Ono to je tak nějak jedno. Já to dělal pro zábavu, když jsem se nudil, a musím říct, že jsem se u toho chvilkama i celkem pobavil. No a něco jsem se i přiučil
Měření Frapsem určitě neskončí, protože kdo si může dovolit takovouto grabovací kartu? Na doma je Fraps a jeho frametimes ideálním řešením. Tedy pořád lepším řešením, než měření průměrných fps, jak říkáš.

Takže jen tak pro srandu

Díky adamV (kdopak to asi bude? ), který mi poskytl logy z FCAT, jsem doplnil import dat do FrapsCut. Práce tak na 20 min

Nyní máte na výběr buďto importovat data z FRAPSu nebo FCATu.


Logy z FCATu z jeho článku tu už adamV sice postoval, ale pro jistotu si je můžete stáhnout ještě zde.
http://ulozto.cz/xCyKCnE/run-frametimes1-csv
http://ulozto.cz/xEQ1LwX/run-frametimes2-csv

Škoda jen, že nemáme tenhle úsek naměřený Frapsem, abychom posoudili, jak moc je Fraps mimo mísu.

Novou verzi můžete stahovat zde >>>

Nebo vám to aplikace nahlásí sama.

PS: Jinak práce na FrapsCutu samozřejmě zastavena, ale tenhle import by se vám mohl ještě hodit.

Ten log z frpasu by k tomu byl výbornej aby se ukázalo jak je ten fraps mimo, pravda pravda. Škoda, tak snad příště. Já frapscut budu nadále používat, na domácí podmínky mi to stačí, je to povedenej prográmek.

Ano bylo by fajn, kdyby AdamV ještě změřil stejný usek Frapsem a pak jsme mohli porovnat výsledky. To by bylo více než přínosné. Možná by se ukázalo, že ty rozdíly zase tak velké v praxi nejsou a jen AMD se to snaží trochu bagatelizovat, aby měli dost času na nápravu v ovladačích (viz. velký letní update zaměřený na Stuttering a Multi GPU microstuttering)
Smysl by to koneckonců dávalo....

Tak on, ten tajemný adamV , to má ve svém článku uvedeno.

vs

Přes fraps je to prostě "chlupatější". Teď ještě jde o to, zda to nezpůsobuje ten core-parking z no-Xova článku?
http://diit.cz/clanek/mereni-snimkovych ... nema-smysl

Chtělo by to asi otestovat

Funguje core parking i ve win XP na cpu bez HT? Vsechny moje vysledky jsou delany na i5 pod XP a nikde jsem nezaznamenal tenhle druh "chlupatosti", takze na tom mozna neco bude... Ale taky je mozny, ze to je vlastnost novejsich grafik (vselijaky powertune, boosty atd.). Ty jsem v rukach nemel.

myslím, že XP nic takového nemají. Je to featura až W7 (Vist?) a jinak máš nejspíš pravdu, že všechny Boosty, Powertune, Turbo Core, mají vliv na latence a tím pádem i na "chlupatost". Nejvíce asi v případech, kdy frekvence pořád osciluje mezi dvěma (a více) hodnotami.

@Webwalker: tak to se ty křivky od sebe zase tak moc neliší, takže to bude tak trochu jak jsem napsal výše....

Tzn. že tvůj program můžeme nadále s klidným svědomím používat a bude to mít nějakou vypovídající hodnotu

No, co jsem četl já, tak hlavním důvodem proč fraps "kecá" a neměl by být používaný pro měření frametimes je context queue (prerendered frames queue). Jedná se o frontu, kde se kumulují příkazy pro gpu (příkazy až pro 3 snímky) a jejím účelem je absorbování nárazů, které přes D3D zasílá aplikace, čímž zajišťuje právě pravidelnější odesílání snímků ke gpu.

Přitroublý příklad s přehradou:
Do přehrady vtéká řeka, která ji naplňuje. V létě a zimě tam přitéká méně a na jaře a podzim zase vody více. Přehrada tento variabilní přítoky absorbuje a následně z hráze vypouští vodu už v kontrolovaném množství.
Stejně tak se chová context queue, absorbuje nárazové požadavky aplikace na vykreslení a do gpu posílá tyto žádosti už pravidelně.
Pokud do context queue "přitéká" méně požadavků nežli "vytéká" do gpu, fronta se vyprázdní a je to klasický příklad cpu limited hry. Je-li tomu obráceně a fronta je neustále plná (gpu nestíhá frontu vyprazdňovat) přejde cpu do klidu a další obrázek už nepřipravuje - gpu limited.
No a problém Frapsu je v tom, že ten "průtok" měří na přitékající řece a ne "pod přehradou", kde bychom to potřebovali

To je důvod, proč jsem vývoj FrapsCutu zastavil. Prostě data z Frapsu nejsou přesná a žádná jiná lepší nemáme. FCAT vypadá velmi dobře, ale přece jen je to dost overkill. Kdo si může dovolit měřit frametimes se dvěma PC a "mastnou" grabovací kartou, kromě bohatších redakcí? Je sice pravda, že i výstupy z FCAT se musí nějak vyhodnocovat, což FrapsCut umí, ale myslím, že se k těmto datům jako obyčejní smrtelníci jen tak nedostaneme, i když to adamV přislíbil (pokud mu to nebude přidělávat práci). Takže co zbývá?

1. Budeme plně odkázáni na FCAT a redaktory IT serverů
2. Fraps bude předělán na měření latencí až za context queue, nebo vznikne program jiný
3. AMD do léta napraví ovladače, takže nikoho už latence dále zajímat nebudou a vrátíme se zpět k měření fps. Bohatší redakce nám pak sem tam v roce potvrdí měřením přes FCAT, že latence jsou u obou výrobců v pořádku.

PS: Všimli jste si podle jakých kritérií začali na Coumputerbase.de vyhodnocovat křivky latencí?
http://www.computerbase.de/artikel/graf ... im-test/4/

Jenže je docela dost dobře možné, že to kde Fraps měří není nakonec až tak relevantní, jak trefně poznamenal Havli

Havli píše:Je ovsem zajimavy, jak muze fraps (uspesne) detekovat microsttutering, kdyz "meri" jen zacatek vykreslovaciho procesu. Asi hra nadetekuje SLI/CF a zacne hazet snimky nepravidelne.

protože problém stutteringu vzniká už na začátku renderovacího procesu, tedy na "přítoku" před onou "přehradou" a další zpracování v D3D/ovladač GPU/GPU už na tento fenomén zřejmě nemají až takový významný vliv, jak je to v článku na Annandovi nabo na diit prezentováno

Jak jinak by mohl Fraps už na začátku naměřit takové rozdíly ?

Nakonec ty křivky jsou si dost podobné. Z těch tří možností bych to viděl na tu 3. Pochybuji, že si nějaké redakce budou kupovat kartu za 40 tisíc kvůli testování, leda že by ji některým dala Nvidia zdarma čistě z účelových důvodů

@del42sa: Dle mého u té konfigurace SLI/CF může být vysvětlení následující.

Pokud je hra cpu limited, je context queue (přehrada) prakticky travale prázdná, výkyvy latencí tedy nelze nikde absorbovat! Takže začátek renderingu je pouhým obrazem konce renderingu (pokud tam nezapracuje frame metering).

Pokud je hra gpu limited, je context queue pořád zaplněna a cpu je často v idle. I když je cpu v idle, tak gpu úplně normálně zpracovává snímky z context queue. Jenže Fraps počítá čas dalšího snímku pořád i když ho cpu ještě nezačal vytvářet (není proč a není kam). Až ho pak cpu začne skutečně vytvářet, ta doba z Idle k němu bude neprávem přičtena, takže bude vypadat jako snímek s ohromnou latencí.

No a když máš SLI/CF konfiguraci, tak jseš cpu nebo gpu limited ?

Ano u SLI/CF by to mohlo být vysvětlení, ale co u jedné karty , navíc testované na i7 ?? I tam byl Fraps schopen zaznamenat velké rozdíly mezi AMD GPU a Nvidia GPU (AMD znatelně chlupatější). Toutéž "kritizovanou" metodou měření se po vydání nových driverů zaměřených na problém stutteringu křivka AMD GPU "zázračně" vyhladila, ačkoliv vzhledem k měření na začátku řetězce by Fraps neměl zaznamenat žádný rozdíl



Byly snad i tyto testy s jednou kartou CPU limited ?

@del42sa: Imho to ne. AMD problém s latencema prostě měla i na singlu a ještě je dnes má (minimálně v DX10).

Jinak tenhle obrázek je lepší:

Co jsem tak koukal do svych mereni, tak se naopak zda, ze CPU limitace MS zmirnuje. Na priklad treba 8800GTX SLI v Oblivionu:

takhle vypada 1024x768 noAA


a 1920x1200 4xAA


Tedy GPU se flaka = vyrovnany framerate, GPU je vytizeno = MS. Divny.

havli píše:GPU se flaka = vyrovnany framerate, GPU je vytizeno = MS. Divny.

Na tom mi nic divného nepřijde, naopak je to logické. Při vysokém rozlišení a 4x AA se nároky na paměťovou sběrnici zvyšují několikanásobně, proto bude mít taková konfigurace větší náchylnost k latencím a tím pádem k microstutteringu než v situaci, kterou GPU zvládá levou zadní...

MS přece vzniká v GPU ne v CPU.

Jo jo, to je vlastne pravda. Ja jsem z predchozich prispevku nabyl dojem, ze limitace CPU = MS. Uz jsem dneska na takhle slozitou debatu prilis unavenej.

Jak je to s vestavěnými benchmarky ve hrách, používají stejný způsob měření jako FRAPS?

@Omal: Imho je to naprosto stejné. Jediný rozdíl je v tom, že hra se nemusí nikam "háčkovat" jako Fraps, protože ona samotná zasílá snímky do D3D nebo OGL. Vlastně to co hra do API zašle, to si Fraps z API "ukradne".

Jinak jeden z prvních porovnání Fraps vs Fcat:
http://techreport.com/review/24553/insi ... ture-tools