Analýza latencí gpu - FLACalculator

[Krteq]

40 fps multigpu bude vo vacsine pripadov stale lepsie riesenie ako 1 karta s 30fps.

Ja bych to poupravil - 40 fps na 2-way AFR nebude horsi nez 20fps na single karte.

On ale zřejmě myslel frametimes

[RAD-x]

Rad-x ty nechapes jednoduchu matematiku, to je vsetko. Cas/frames=ms/1frame. Vzdy plati jedno jedine, Frames Per Second= XYZ framov za 1S= 1s:XYZ frames= avg ms/1frame.

40 fps multigpu bude vo vacsine pripadov stale lepsie riesenie ako 1 karta s 30fps.

Tý matematika ti tam bohužel polovička chybí, jelikož u SLI/CF to chodí "trošičku" jinak tohle co si tu popsal platí pro singl GPU kde se nečeká na vyjádření druhý karty, jestli už má svuj každej druhej snímek hotovej... to jen takovej malej detajl, né že bych jich tam nebylo víc ale...

[Krteq]

No a co myslíš, že je frame-metering/framepacing? Už s těmahle algoritmama se variabilita frametimes celkem srovnává.

[Ingamacek]

Nechapem preco riesite spike-y, to ze ma nieco vyssie spike-y neznamena ze to je aj horsie hratelne pokial to ide zvysok casu o xyz% lepsie. Ano, pokial hra clovek na lock fps/vsync kde je stale cap ci uz sw alebo hw je jasne ze single gpu je na tom lepsie ale je sprostost povedat ze single karta ktora nieco nezvlada vykonovo je na tom hratelne lepsie ako identicky cf/sli s 50% viac fps.

Zvysok matematiky je nepodstatnej je jedno ci sa caka na druhu kartu, na vlak, autobus alebo lietadlo, stale plati zakladna rovnost frame/time/FPS.

[RAD-x]

Jo, to je občas užitečná fičurka, bohužel "ne vždy" to funguje podle představ a i když funguje, stále i když je to viditelně lepší, neřeší to dostatečně náš problém, kdyby ano - mám to doma, to mi múžeš věřit, z toho co jsem vyzkoušel, než jsem nakoupil, bylo SLI jako multiGPU asi nej a stejně je to hard suxx a většinu věcí jedeu na singl kartě a pokud bych to tehdá neshnal za hubičku, nikdy bych do toho nešel. Tehdá jsem měl na zkoušku 7990, a u kolegy jsem viděl v akci sploečně s mojí bejvalou 290X jejich cross, se kterym jsem si hrál dva dni... a jestli mi nekdo plánuje říct že sem prostě zelenej, tak NE...já fakt nevyhazuju peníze pro nic za nic, jednoduše jsem si koupil věc která byla nejlepší.

Technická : celou dobu jsem měl takovej jemnej dojem, že ta plynulost "viditelná" neni zpúsobená pruměrným frametimes ale práve jeho rozdílem od předchozího a následujícího... čili ano, prúměrný frametimes klidně mužeš mít nižší(což v multiGPU vs singl mít nebudeš) a stejně se to bude opticky víc trhat - nebude plynulé chcete-li.

[Ingamacek]

Nie nebude kedze poctom frameov klesa aj ms spikeov sposobenych presne tymto. Ok idem spat, nebudem sa dalej hadat, nema to zmysel

[havli]

Technická : celou dobu jsem měl takovej jemnej dojem, že ta plynulost "viditelná" neni zpúsobená pruměrným frametimes ale práve jeho rozdílem od předchozího a následujícího... čili ano, prúměrný frametimes klidně mužeš mít nižší(což v multiGPU vs singl mít nebudeš) a stejně se to bude opticky víc trhat - nebude plynulé chcete-li.

Ano, to je presne ono... tak to v praxi funguje.

Nazorna ukazka - je lepsi HD 5550 (42 avg fps) nebo 8600 GTS (32 avg fps)?

.
.
.


Tohle sice neni mereno na multi GPU (je to jen nazorna ukazka zabugovanosti AMD ovladacu ), ale tam to vypada v extremnich pripadech uplne stejne. Takze asi tak.

[RAD-x]

Nie nebude kedze poctom frameov klesa aj ms spikeov sposobenych presne tymto. Ok idem spat, nebudem sa dalej hadat, nema to zmysel

Jak to ovlivní čekání první karty na tu druhou a pak při dalších dvou FPS třeba obráceně, nebo znovu stejně? máš v tom dost hokej a zjevně sis nepřečtl co jsem psal prve, až si to přečteš, múžeš pak směle zvednout telefon a vysvětlit vývojářúm v MSI a EVGA, že jejich SW který používají lidé po celmé světě funguje špatně, dokonce přesně naopak než by měl, tvoje vysvětlení jim jistě bude ku prospěchu a dočkáme se pak lepšího měřícího SW.

K věci, jak je to tedy s těmi FT? vizuální plynulost se odvíjí od prúměrných, nebo od % rozdílu mezi jednotlivými? ten prúměr mi tedy moc nehraje... pořád si nejsem 100% že nejde o vzájemný nedorumění, nebo že měřímu tu veličinu kterou pak vidime.

EDIT: havli - ták přesně o to mi šlo, čili mimo hlavního problému, si teď nějak nejsem vubec jistej jestli měříme to, co pak vidíme / chceme abychom viděli...

[del42sa]

Myslím, že pravdu máte oba. U single karty se frejmy vykreslují za určitý čas. U multi GPU se snímky vykreslují v kratším čase, ale s různou latencí (microstuttering). Její variabilita má dopad na vizuální plynulost hry, jinými slovy i když má hra více fps, je pocitově pomalejší (trhanější) než tatáž hra na single kartě. Takže matematicky vyjádřeno je správně, že u multi GPU má hra více fps s menší (celkovou) latencí, ale variabilní (snímková) latence není konstatní, což způsobuje onu neplynulost.

[webwalker]

@del42sa: Je to přesně tak. Multi gpu generuje (pokud funguje) více fps s průměrnou nižší latencí. Nikoliv vyšší jak tu píše RAD-x. Problém AFR je ten, a to už jsem psal na předchozí stránce, že tyhle snímky jsou renderovány nepravidelně. Proto SLI/CF v každé recenzi vyhraje nad single gpu pokud se používá pouze průměrné frame rate, ale v praxi to hratelné není, nebo to vypadá tak, jako bys dosahoval daleko nižších fps.
V průměrných fps (nebo latenci) není totiž nijak započítán onen micro stutteringem. Z toho důvodu byl právě vytvořen FLAC, aby vzal do úvahy i MS a variabilitu snímkové frekvence.

[Ingamacek]

Rad-x nechapes ze tu sa jedna o specificku situaciu kde tvrdis ze 2* gpu bude mat horsie ms ako 1* to iste gpu? Si uz tard alebo to teraz prekrucas na 2 rozlicne modely gpu od 2 rozlicnych vyrobcov?

EDIT: teď jsem třeba zjistil, že v BF4 podle FLAC neplatěj multi GPU zákony, prej SLI má v BF4 lepší latence než jedna karta...tak já nevim. Upnu ti ten log jestli z toho budeš nějak moudrej...

NIKDY nebude mat funkcne SLI/CF ktore nieje obmedzovane HW/SW horsie ms na 1 frame ako 1 ta ista single karta. Hokej mas v tom ocividne ty, aj ked su snimky generovane striedavo na kartach tak sa loguje cas po sebe iducich snimkov, takze ked ma sli nizsi cas potrebny na 1 frame tak to tak aj realne bude ten obraz plynulejsi na dualgpu konfiguracii a vyskocit moze sem tam spike, aj to pochybujem pri rovnakych kartach a ovladacoch, to by museli byt tie ovladace pre dualgpu fakt o nicom ak je to vobec mozne.

[webwalker]

@RAD-x:
Tak a teď trocha teorie, i když mě nikdy nenapadlo, že budu právě já v tomhle vláknu vysvětlovat AFR

1. Programy jako Fraps zaznamenávají čas, ve kterém byl proveden swap front/back bufferu. Latence jsou tedy doby mezi swapováním bufferu.
2. U sigle gpu je to jednoduché. Gpu obdrží data od cpu a začne renderovat snímek. Když ho dokončí provede swap bufferů (není li zapnuto vsync). Následně dostane od cpu další data pro nový snímek a tak to jde stále dokola. U single gpu je tedy čas swapů přímo roven době, po kterou gpu renderuje snímek. U multi-gpu však ne!!!
3. U multi gpu je to složitější. Gpu1 (master) obdrží data od cpu a začne renderovat snímek. Mezitím cpu dodá data také gpu2 (slave), které také započne renderování. Dva snímky jsou tedy renderovány paralelně. Gpu1 dokončí rendering, provede swap, dostane nová data od cpu a začne rendering dalšího snímku. Mezi tím už gpu2 dokončuje snímek, odešle ho do framebufferu mastera, provede swap a obdrží data pro rendering dalšího snímku. Díky tomuto paralelnímu renderingu jsou pak latence (časy swapování bufferů) kratší.

A o kolik jsou kratší? No teoreticky o tolik, kolik gpu se podílí na multi-gpu řešení.
Ideální stav dual-gpu je ten, kdy v čase dokončení renderingu jednoho gpu, je druhé gpu někde v polovičce své práce. V praxi se ale stává, že v čase dokončení renderingu prvního gpu je druhé gpu třeba už v 90% své práce. Ke swapu druhého gpu tedy dochází příliš rychle po prvním a doba swapu dalšího je pak o to delší. A takto vniká onen MS.

Frame metering a frame pacing se tedy nesnaží o nic jiného než o to, aby bylo co možná nejpřesněji dodrženo pravidelné swapování bufferu tím, že některý krátký swap raději ještě chvilku pozdrží. Sice se tím okrádají o trochu výkonu (snižuje to fps), ale zase nedochází k MS.

Na žádný afterburner s počítadlem fps se spolehnout nemůžeš díky tomu, že on všechny latence průměruje a ukazuje ti sice okamžité, ale zprůměrované fps. Chceš-li to mít přesné, musíš jít a kouknout se do průběhu latencí. Tvoje SLI, které ti u AB ukazuje nádherné okamžité fps ale ve zkutečnosti vypadá úplně jinak pod drobnohledem latencí:

rad_x_sli.jpg

Ještě se divíš, že ti FLAC zkrouhnul díky micro stutteringu původní fps skoro na polovinu?

[Krteq]

Frame metering a frame pacing se tedy nesnaží o nic jiného než o to, aby bylo co možná nejpřesněji dodrženo pravidelné swapování bufferu tím, že některý krátký swap raději ještě chvilku pozdrží. Sice se tím okrádají o trochu výkonu (snižuje to fps), ale zase nedochází k MS.

Jen dodám, že tam přidává menší lag způsobený tímhle zpracováváním.

[RAD-x]

Rad-x nechapes ze tu sa jedna o specificku situaciu kde tvrdis ze 2* gpu bude mat horsie ms ako 1* to iste gpu? Si uz tard alebo to teraz prekrucas na 2 rozlicne modely gpu od 2 rozlicnych vyrobcov?

EDIT: teď jsem třeba zjistil, že v BF4 podle FLAC neplatěj multi GPU zákony, prej SLI má v BF4 lepší latence než jedna karta...tak já nevim. Upnu ti ten log jestli z toho budeš nějak moudrej...

NIKDY nebude mat funkcne SLI/CF ktore nieje obmedzovane HW/SW horsie ms na 1 frame ako 1 ta ista single karta. Hokej mas v tom ocividne ty, aj ked su snimky generovane striedavo na kartach tak sa loguje cas po sebe iducich snimkov, takze ked ma sli nizsi cas potrebny na 1 frame tak to tak aj realne bude ten obraz plynulejsi na dualgpu konfiguracii a vyskocit moze sem tam spike, aj to pochybujem pri rovnakych kartach a ovladacoch, to by museli byt tie ovladace pre dualgpu fakt o nicom ak je to vobec mozne.

Čteš vubec na co reaguješ, nebo jen plácáš do větru? neni to mojí češtinou? Čítaš na čo reaguješ, či len plácaš do vetru? pro ty delší texty prosim tě použij google trans, nemám čas to psát dvojjazyčně.

webwallker: my se evidentně nechápeme... pokud si muj příspěvek přečteš znovu, bavíme se oba o uplně jiné veličině. Samozřejmě to co si napsal teď je teoreticky tak jak to chápu i já, že by to mělo bejt, ačkoliv neni. Každopádně já jsem se chtěl dobrat k tomu, jak to teda je s těmi pruměrnými FT a co je vizuelně co, respektive jak interpretovat číselnou hodnotu plnulosti. Vzhledem k tomu, jak mi potvrdil havli, tak pruměrný frametimes je naprosto nevypovídající hodnota vizuální plynulosti, tím pádem i přes to, že je to zajímavý měření a rozšiřuje to škálu měřitelných parametrú, nerozsekne to co mě osobně zajímá, tím myslím jednoduše pochopitlený číslo, přímo vztažený k plynulosti.

[webwalker]

@RAD-x: Průměrný frametime (tedy latence) aka průměrné fps nemají příliš dobrou vypovídající hodnotu a to je vlastně to, oč tu od samého počátku běží.
Názorným příkladem jsou právě ty SLI/CF řešení, které přinášejí sice vysokou snímkovou frekvenci (tedy nižší průměrnou latenci a nikoliv vyšší, jak jsi tvrdil), ale díky poruchám ve vjemu plynulosti pohybu, jako je (micro)stutteringu, bývá hratelnost mnohdy horší než na single gpu (které sice nedisponuje takovým fps, ale nemá díky absenci AFR tolik stutteringu).

Pokud tedy tak, my musíme nějakým způsobem zjistit, kolik tam takových poruch, které mají vliv na plynulost pohybu v průběhu měření, je přítomno a zhodnotit je. A to je právě to, co dělá FLAC, který ti:

a) Vypočítá průměrnou latenci aka průměrné fps

Následně pak poruchy, které způsobují neplynulost pohybu v daném úseku měření:

b) Nepravidelnost snímkové frekvence
c) Hodnotu stutteringu

Comparable frame rate (dříve playable frame rate) je tedy průměrná snímková frekvence (a), od které jsou odečteny obě poruchy (b+c).

To, že FLAC ukazuje velmi konzistentně ti ukážu na tvém měření se SLI:

Rad_x.jpg

1. Průměrná latence je v tvém případě 6,45ms, průměrné snímková frekvence tedy 155fps a nikoliv 200fps (co ti průběžně ukazuje AfterBurner).
2. Jsou tam viditelné poruchy plynulosti snímkové frekvence a navíc posledních nějakých 20s ti to jelo pouze na 30fps. Každopádně vyčísleno na 3,03ms.
3. Stuttering (díky AFR) je zřejmý, kdybys chtěl můžu ti ten graf ještě zvětšit, každopádně vypočítán na 1.94ms.
4. Tvoje skóre tedy je 6,45 + 3,03 + 1,94 = 11,42ms (tedy 87fps)

Z původních a průměrných 155fps jsi se tedy díky odečtení poruch v plynulosti pohybu dostal na 87fps.
Toto "Comparable frame Rate" pak můžeš použít pro srovnávání s výsledky ostatních gpu (bez SLI, se SLI, mainstreamem nebo lowendem, to je fuk). To je velká výhoda proti třeba 99-percentile, která takto porovnávat nejde a navíc je to svým způsobem náhodná hodnota.

[Ingamacek]

Rad-x vidim to tak ze ocividne kto jediny v poslednych postoch nechape si ty.

[RAD-x]

Rad-x vidim to tak ze ocividne kto jediny v poslednych postoch nechape si ty.

Vzhledem k tomu že ani nečteš na co reaguješ tomu nepřikládám žádnej význam.

webwallker: ale ta intrepretace v číslech je vúči vizuální stránce přesně naopak.

[Krteq]

ale ta intrepretace v číslech je vúči vizuální stránce přesně naopak.

Můžeš to trochu rozvézt?

[webwalker]

@RAD-x: Grafická interpretace je OK.

Abych ti ukázal, že FLAC ukazuje opravdu konzistentní výsledky, ručně jsem odstranil z tvých naměřených hodnot záznamy latencí z počátku měření, kdy ti to tam vylítlo až na 377ms a také ten závěrečný cca 20s úsek, kdy ti to tam zase jelo pouze na 30fps. Takže po odstranění těchto nejhorších hodnot ti SLI ukazuje nyní "best case scenario" a mělo by se to také nějak pozitivně projevit na výsledku FLAC:

RAD_X_SLI2.jpeg

Nyní je průměrná latence 6,08ms tedy nějakých 164 fps.
Díky variabilitě a stutteringu ti bylo připočteno 0,89 + 0,84 ms.
Skóre je tedy 7.81 ms což je nějakých těch 128fps.

PS: Nevím, v jakém úseku jsi to v BF4 měřil, ani jaké bylo nastavení hry. Bylo by dobré, kdybys vzal tohle SLI a projel ten náš testovací úsek BF4 v MP64 (Siege of Shanghai) z videa od Katali a poslal naměřené logy. Pak už bychom mohli nějak srovnávat.

[webwalker]

Tak už se nikdo k testování Star Swarm RTS, kromě Acheho a ChaoSborna, nepřipojí??
Potřeboval bych ke zveřejnění výsledků ještě nějaká ta měření.