Microstuttering: FCAT vs FRAPS na jednočipové grafice a multi-GPU

29. 4. 2013

Zdroj: Redakce

Měření FCAT a v čem má prsty Nvidia

Pod úvodním článkem k testování grafických karet pomocí platformy FCAT se objevila hromada narážek (a někdy až hodně rozhořčených komentářů) poukazujících na to, že FCAT je technologie, na které spolupracuje Nvidia a jako takovou ji tedy nelze používat pro objektivní testování grafických karet.

Proto znova v krátkosti zrekapituluji, jak se to s FCAT má. Jde o technologii, kterou začal vyvíjet web PC Perspective a následně na ní začala spolupracovat i Nvidia. Podrobněji je vše popsáno v článku Frame Rating Dissected: Full Details on Capture-based Graphics Performance Testing. Důvody, proč má na celé technologii Nvidia zájem, jsou přinejmenším dva – jednak jde o nástroj, který mohou vývojáři Nvidie sami využívat, jednak je to ideální příležitost, jak dát o této výhodě vědět širší veřejnosti.

Základem celé technologie je záznam, který se následně analyzuje. O nahrávání se stará „běžná“ zachytávací karta společnosti Datapath. U nás o tomto výrobci zatím slyšel asi jen málokdo, v sortimentu má ale celou řadu produktů právě z oblasti profi zobrazovacích zařízení. Založená byla v roce 1982, od roku 1986 se zabývá výrobou profi grafických karet. V roce 2000 uvedla i řadu grafických karet pro videozdi a právě kvůli nim začala v témže roce i s výrobou zachytávacích karet. Karta VisionDVI-DL, kterou FCAT využívá, je jen jedním z celé řady produktů podobného ražení. Samotná karta tedy sloužila primárně k jinému účelu, pro FCAT se ale báječně hodí kvůli tomu, že je s ní možné snadno zaznamenat totéž, co vidíte na monitoru.

Dalším prvkem v celém řetězci pro záznam a analýzu dat je jednoduchá aplikace, jež pomocí overlay vkládá barevné pruhy do vyrenderovaných snímků, které se následně nahrávají. Pokud dojde k překreslení obrazovky dříve, než je vyrenderovaný další snímek, část starého snímku se vykreslí i do další obrazovky. Ze záznamu se pak pomocí skriptů počítá, kolik řádků z daného snímku je vidět a na jak dlouho se tedy snímek zobrazil.

K aplikaci Overlay Nvidia nezveřejnila zdrojové kódy (podle PC Perspective je jediným důvodem riziko porušení patentů). Overlay od Nvidie je asi jediný potenciální „zdroj manipulace“. Celé vkládání barevných proužků do vyrenderovaných snímků je ale poměrně triviální záležitost a Nvidia by záměrnou manipulací s výkonem karet hodně riskovala – odhalit takový podvod by asi nebylo nikterak náročné.

I PC Perspective vyzýval vývojáře k napsání otevřené alternativy k Nvidia Overlay. Naštěstí to netrvalo ani moc dlouho – příležitosti se chopil tvůrce RivaTuneru, který stojí i za dvojicí populárních aplikací MSI Afterburner a EVGA Precision – Alexej Nikolajčuk (známý pod přezdívkou Unwinder). Tyto utilitky mají mimo jiné i vlastní OSD server, který se využívá pro vypisování údajů z diagnostiky grafické karty přímo do obrazu ve hře.

Vyzkoušejte si to i vy

Jak MSI Afterburner, tak EVGA Precision už umí v nejnovějších verzích přes OSD server do obrazu přidávat kromě diagnostických údajů i barevné obdélníčky, které FCAT pro analýzu využívá. Už i poslední problematický prvek řetězce byl tedy snad odstraněn (tedy pokud teď příznivci konspiračních teorií nepříjdou s tím, že autora Nvidia podplatila, aby na Radeonech občas nějaký ten snímek při vkládání dat na OSD přiškrtil).

Overlay si už tedy můžete vyzkoušet sami. A za pokus to stojí i bez zachytávací karty – při experimentování s vertikální synchronizací je to docela zajímavá hračka, se kterou i při pohledu pouhým okem získáte mnohem lepší představu, jak probíhá zobrazování jednotlivých snímků a co se na monitoru děje.

Nějak takto vypadá výsledek zaznamenaný kartou, na Youtube je záznam bohužel zredukovaný na 30 fps a kvalita obrazu jde kvůli výrazně ztrátové kompresi také hodně dolů.

" width="700" height="394" frameborder="0">

Zobrazení pruhů se zapíná v nastavení OSD serveru (ikona klíče vpravo nahoře). A ještě upozorním, že pokud máte na OSD další text při levém okraji monitoru, bude jej v nastavení OSD třeba o kousek posunout, aby jej pruhy nepřekrývaly (v pravém dolním rohu, v textovém poli je vidět, že mám text OSD posunutý o 40 pixelů).

Záznam se dále analyzuje pomocí skriptů (jejich zdrojové kódy napsané v Perlu už jsou transparentní a veřejně přístupné) a jednotlivé kroky analýzy a výsledky se ukládají do podrobných logů.

Podváděla Nvidia?

Ještě předtím, než začneme s FCAT testovat, jsem se jal ověřit, nakolik se liší údaje z FCAT s pruhy vykreslovanými přes overlay od Nvidie a FCAT s pruhy vkládanými přes OSD server v MSI Afterburner (či chcete-li zkusit, jestli Nvidia u Overlay nepodváděla a jestli se výsledky, které dostaneme z Afterburneru, budou nějak výrazně lišit). K vyzkoušení jsem využil nový Tomb Raider s posledními dostupnými záplatami.

Graf, na kterém je porovnání měření při použití Overlay Nvidie a overlay z MSI Afterburner, je trochu komplikovaný. Navíc je na svislé ose vynesená latence jednotlivých snímků, což je převrácená hodnota oproti fps, na které můžete být z grafů s microstutteringem z Extrahardware zvyklí.

Jak můžete vidět, rozdíly mezi Afterburnerem a Nvidia overlay jsou malé a dokonce to vypadá, že miniaplikace od Nvidie je místy k Radeonu HD 6990 shovívavější, než když se pruhy vkládají přes MSI Afterburner.

Ve druhé části průběhu jsou už ale výsledky téměř stejné. Rozdíly bych tedy spíše přičítal na vrub chybě měření; při výrazném microstutteringu se totiž synchronizace dvou GPU rozjíždí při každém měření jinak a dva průběhy měření nejsou nikdy zcela stejné.

U jednočipových karet jsou odchylky minimální, u problematické HD 6990 je výsledek ve větší části průběhu obdobný (přinejmenším se nedá říct, že by jedna z aplikací kartě výrazně křivdila, v obou případech je vidět výrazný microstuttering).

Nadále budeme nejspíš využívat Afterburner, protože při použití overlay od Nvidie není možné mít souběžně spuštěný FRAPS (ani při vypnutém OSD se na obraze nevykreslují pruhy).

Analýza záznamu, aneb výpadky a skrčci

Pokud je snímková frekvence hry vyšší než frekvence monitoru, microstuttering se projevuje tak, že se některé (rychlé) snímky vykreslují jen po krátkou dobu a ty ostatní se vykreslují podstatně déle.

V extrémním případě může být takový rychlý snímek vykreslený jen jako proužek o výšce několika pixelů (takovým se začíná říkat „runt frame“, lidově si to můžeme přeložit jako „skrček“) nebo dokonce nemusí být vykreslený vůbec (pak se mu říká dropped frame – vypuštěný snímek). Přestože jej na obrazovce téměř nebo vůbec neuvidíte (a změnu na obraze má mizivý či žádný přínos), do průměrů se započítá.

Pro příklad nemusíme chodit daleko, v Tomb Raideru jsem vzal dva snímky ze záznamu. Vlevo je EVGA GeForce GTX 690, vpravo referenční Radeon HD 6990 na OC profilu.

Na detailu trosek je vidět, že se u Radeonu u jednoho hotového snímku vykreslilo sotva pár pixelů a už následuje vykreslování dalšího. Kvůli tomu, že z jednoho mezisnímku toho moc nezbylo, je na hraně dvířek (či co to je) mezi horní a dolní polovinou obrazovky výrazně větší skok než u GeForce GTX 690. Na monitoru se to příliš neliší od situace, kdy by se vykresloval jen každý druhý snímek (což je totéž, jako by vše počítala jednoprocesorová karta). Proužek s výškou nějakých 5 pixelů na obraze totiž prakticky nepostřehnete. Výsledek? „Naměřený“ průměr je ~50 fps, ale obraz přeskakuje jako u 25 fps.

Otázka je, jak něco podobného zohlednit v hodnocení. A nejen kolem toho nás asi čeká ještě hodně filozofování. Jednou ze zajímavých možností, se kterou se pracuje jeden z grafů v FCAT, je takové příliš malé (krátce zobrazené) snímky prostě nepočítat do průměru.

V grafech s průměrnými FPS, které skripty z FCAT produkují, pak můžete vidět původní průběh bez vypuštěných „skrčků“ a křivku, která by vycházela, když jejich „přínos“ zanedbáme.

Limit pro nezapočítané snímky je u skriptů pro FCAT standardně nastavený na 20 řádků. Není to nějak drastická hranice, když uvážíte, že při plném HD rozlišení má obrazovka výšku 1080 řádků. Opět je ale její nastavení a to, zda něco podobného používat, věc k debatě.

Výsledkem by pak byl podobný graf, kde černá linka odpovídá tomu, co by byl výsledek průměrných fps měřených FRAPsem, modrá linka jsou pak „reálně“ zobrazené snímky.

Testovací sestava, metodika

Testovací sestava

Jako testovací platforma posloužila základní deska Gigabyte X79-UD5 s BIOSem F10. Procesor je šestijádrový Core i7-3960X s TDP 130 W, který je přetaktovaný na 4,2 GHz při 1,36 V. Asistuje mu 16GB kit operačních paměti DDR3 od Kingstonu.

základní deska: Gigabyte X79-UD5
procesor: Core i7-3960X (deaktivovaný HTT, C1E, EIST), 4,2 GHz na 1,36 V
chladič CPU: Noctua NH-D14
paměti: 4× 4 GB Kingston DDR3 KHX2133C11D3K4/16GX
zdroj: Enermax Revolution 85 ERV920EWT-00, 920 W
pevný disk: Intel SSD 510 (250 GB)
skříň: Gelid DarkForce
operační systém: Windows 7 x64

Pro záznam se používá profesionální zachytávací karta DataPath VisionDVI-DL, která je vybavená vstupním konektorem dual-link DVI a rozhraním PCI Express 4× a zvládá snímat rozlišení 2560×1440 při 60 Hz (dokonce by měla umět i 3840× 2160 při 30 fps). Na rozdíl od levné alternativy v podobě TV tunerů a zachytávacích karet se vstupem HDMI umí pořizovat záznam i v barevném formátu RGB při 24bitové barevné hloubce.

Karta je schopná generovat datový tok až 650 MB/s, jen při nahrávání z plného HD rozlišení je to kolem 240 MB/s. Kvůli následnému zpracování nesmí při záznamu docházet k výpadku snímků, taková nahrávka by se dala jen stěží korektně analyzovat. Znamená to, že je pro záznam zapotřebí nejen rychlé, ale i docela velké úložiště.

Na tomto místě musíme poděkovat společnosti Kingston, která nám pro tyto účely zapůjčila čtyři 240GB SSD HyperX 3K.

Čtyři SSD v RAID 0 jsou momentálně přiškrcené na integrovaném 3,0 Gb/s řadiči z platformy Z77 (pro SATA 6,0 Gb/s má čipset Intelu stejně jen dva kanály), jak se ale zdá, na to, aby sestava zvládala záznam bez výpadků, by i toto řešení mohlo stačit. Zásluhu na tom má i Core i5-3470 s architekturou Ivy Bridge, který už má jižní můstek připojený novou rychlejší generací sběrnice DMI2.

Jako základní deska posloužila Gigabyte GA-Z77X-UP4 TH, která je vybavená i rozhraním Thunderbolt. To, co je zastrčené ve slotu PCI Express ×16 a na pohled připomíná prehistorické, na spotřebu nenáročné, grafické karty a s minimalistickým pasivem, je ve skutečnosti zmiňovaná zachytávací karta. Grafika neschází, využívám tu integrovanou v procesoru.

Protože mě zajímal především rozdíl mezi jednoprocesorovými a dvouprocesorovými grafikami, pro srovnání jsem použil tyto čtyři grafické karty:

referenční GeForce GTX 680
EVGA GeForce GTX 690
referenční AMD Radeon HD 7970
referenční AMD Radeon HD 6990

Testovalo se na ovladačích GeForce 320.00 a Catalyst 13.5 beta 2 + CAP 13.4.

Jsem si vědom, že ke GTX 690 by se slušelo měřit spíše dvě HD 7970 do CrossFire nebo HD 7990, ale HD 7990 zatím bohužel nemáme a ani druhou HD 7970 do CF nedisponuji. Ve výsledcích také (hodně) schází dvě GTX 680 do SLI, které by měly být někde mezi GTX 690 s frame rate meterignem a problematickou HD 6990), dvě GTX 680 už k dispozici mám, ale zatím jsem je nestihl naměřit.

Tomb Raider Benchmark, Tress FX off + FXAA

První nastavení je méně náročné, je vypnutá simulace vlasů Tress FX a je nastaveno méně náročné vyhlazování FXAA. Jinak je vše na maximálních detailech (kvalita Ultimátní a navíc ještě zvýšené stíny z nastavení „normální“ na „ultra“.

Před grafy ještě jednou upozorním, že nejde o obvyklé průběhy FPS, ale o latence v milisekundách (doba jak dlouho byl snímek vykreslený).

První čtveřice grafů s modrými průběhy je vždy měření z FRAPS, v posledním souhrném grafu jsou výsledky naměřené pomocí FCAT. Grafy jsem se snažil lícovat tak, aby bylo možné mezi nimi přepínat, přesto se trochu liší (hlavně u popisků). Grafy z FRAPSu jsou totiž vykreslené pomocí Excelu, zatímco FCAT pro vykreslování využívá Gnuplot.

Tomb Raider Benchmark, Tress FX on + FXAA

Druhé nastavení bude asi používat většina majitelů karet vyšší střední třídy. Vše je nastavené na maximum, ošizené je jenom vyhlazování hran, místo náročného SSAA je zvolené jednoduché a méně kvalitní FXAA.

Tomb Raider Benchmark, Tress FX on + SXAA 2×

S vyhlazováním SXAA mají už co dělat i highendové karty. V benchmarku se snímková frekvence pohybuje v rozmezí 30–50 fps, a to v benchmarku není zdaleka to nejnáročnější prostředí, jaké ve hře potkáte.

Tomb Raider, herní test, Tress FX on + FXAA, ze hry

Kvůli tomu, že scéna použítá v benchmarku není z nejnáročnějších, jsem vyzkoušel ještě náročnější pasáž hry. Bohužel ani ona není to nejnáročnější, co ve hře najdete – prošel jsem jen asi šestinu. A i kdyby – hra jako dnes už obvykle ukládá průběh do jediného checkpointu, takže i s náročnějším testováním je člověk odkázaný jen na dostupné pozice.

Se zapnutým Tress FX se i s nenáročným vyhlazováním FXAA dostanete u GeForce GTX 680 chvílemi k nějakým 28 fps.

Závěrečné shrnutí a polámané vlasy

Pokud už jste viděli některé články zabývající se microstutteringem u multi-GPU, grafy vás asi moc nepřekvapily. Výsledky, které jsem pomocí FCAT naměřil, jsou u všech karet decentně optimističtější než při měření s FRAPsem. Zajímavé je, že při některých nastaveních grafiky jsou na výstupu vyžehlené některé propady a špičky.

Na nějaké závěry je po vyzkoušení jedné hry brzo. Na PC Perspective, kde už na FCAT naměřili podstatně víc výsledků (včetně u nás zatím nedostupné HD 7990), zjistili, že podobnost výsledků s FRAPSem se dost liší titul od titulu a rozdíly jsou dokonce více či méně zřetelné i při různém rozlišení.

Některé zádrhely FRAPSem naměříte (to byl třeba případ Far Cry 3, kde průběhy dobře odpovídaly tomu, co bylo vidět na obrazovce), někdy naopak FRAPsem naměříte něco, co se na monitor už nedostane, a někdy je výsledek z FRAPSu optimističtější než realita.

Porovnávání komplikuje i fakt, že se při microstutteringu při opakovaných měřeních synchronizace snímků nerozjíždí vždy stejně. Průběhy snímkových frekvencí s průměry po sekundách jsou víceméně stejné, ale při rozlišení na jednotlivé snímky mohou být rozdíly podstatně větší.

Bug u Tress FX

K Tomb Raideru a diskutované technologii Tress FX mám ještě jednu zajímavost. Majitelé multi-GPU zjistili, že vlasy vykreslované pomocí TressFX dělají problémy. A stěžovali si na to spíše vlastníci SLI s GeForce než majitelé CrossFire. U CrossFire se prý problém objevoval jen u některých verzí ovladačů.

A skutečně, během testování Laře poblikávaly vlasy na GeForce GTX 690 podstatně víc než u HD 6990, u které to bylo při jednom z průběhu testů vidět jen pár sekund na začátku, a během několika dalších testů už možná jen sem tam něco probliklo.

Při krokování nahrávky jsem zjistil důvod. Vlasy (a jejich stíny) simulované pomocí TressFX se totiž na sudých a lichých snímcích liší, na jednom bývají delší a hustější než na druhém. Podobné rozdíly mezi sudým a lichým snímkem nejsou (u GTX 690) nic výjimečného:

Blikání pak způsobuje střídání sudých a lichých snímků. A proč to na Radeonech tolik (a někdy vůbec) nebliká? Protože se dost často z jednoho ze dvou snímků zobrazí jen uzounký proužek – runt frame a zbytek obrazu už je další snímek.

GeForce GTX 690 v tomto případě paradoxně škodí, že zobrazuje po sobě jdoucí snímky víceméně rovnoměrně. Zatímco u Radeonů HD 6990 je vidět povětšinou jen jeden ze dvou vyrenderovaných snímků, takže vlasy neblikají a na Radeonech to „neblbne“. Občas narazíte i na zmínku, že to novější verze Catalyst řeší. Nezkoušel jsem všechny, jen ty poslední 13.5 beta 2 (a samozřejmě nemohu vyloučit, že s některými ovladači to bude fungovat, jak má, protože vyzkoušet všechny není v mých silách), ale spíše bych tipl, že se problém zatím objevuje u všech multi-GPU (bez ohledu na verzi ovladačů) a u Radeonů to jen kvůli microstutteringu prostě není tolik vidět (a pocit zlepšení je, jak to často bývá, jen placebo efekt, protože někdo i zmiňuje, že problém nezmizel zcela, ale už se neobjevuje tak často).