Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
On ten obrázek zjevně začíná už ve framu 6, sedmička je zase ten prázdný pruh, místo framů 6-10 by tam měl být jeden s fps < 60.
"...že Nvidia s touto metodikou přišla jednoduše proto, že u sestav s CrossFire skutečně problém se špatnou synchronizací práce obou grafik existuje "
on ale ten problém se synchronizací existuje i u SLI pokud vím...
Mno rekl bych ze aby tohle fungovalo tak nemaji vyply jen vsync ale taky jakykoliv framebuffer. Tech 40 radku navic bude asi proste smazani grafickeho bufferu. Proto je to vzdy cerne a proto to trva vzdy stejnou dobu.
Těch 40 řádků už nesouvisí nijak s framebufferem. To je věc analýzy toho nagrabovaného videa.
"Kdybych měl mluvit za sebe, tak mě výsledky těchto testů přijdou jako šťourovi celkem zajímavé, ale pro praxi bezvýznamné."
Ale zapnutím vsyncu se neřeší problém runt frames. Pouze se ukazuje jiným způsobem.
Pro jednoduchost si představme, že máme tu samou scénu - jednou bez vsync a podruhé s vsync (a pro jednoduchost příkladu i s triplebufferem). Pokud máme snímek, který se bez Vsync zobrazí na 12 řádcích z 1200, v případě vsync+tb se takový snímek zobrazí v jednom případě ze sta. Pouze se z prostorové efektivity 1/100 přesunul problém na pravděpodobnostní 1/100. Přes dostatečně velké množství takových snímků je přinesená informace úplně stejná v obou případech.
Nevím, jestli jsem tě správně pochopil, ale z toho, co jsem četl na PC Perspective, mi připadá, že to funguje jinak. Jak to chápu já, v případě vypnutého VSyncu se snímky kreslí do framebufferu tak, jak přijdou, tzn. jakmile jsou hotovy. Proto jich tam může být více a jsou natrhané (prostě jak je to hotové, tak se to tam sype, zjednodušeně řečeno). Zatímco při zapnutém VSyncu nesmí jít další snímek, přestože už je hotov, do framebufferu k zobrazení, dokud neuběhla doba rezervovaná pro předchozí snímek (1/60 s). Takže ten "runt frame" se na řadu dostane celý. Kdyby to tak nefungovalo, generovaly by grafiky snímky pořád a v podstatě jen ty, co by přišly zrovna na řadu k zobrazení, by se zobrazily a ostatní se zahazovaly. To by bylo výkonnostně strašně neefektivní a já doufám, že to tak nefunguje ;).
vSync řeší hlavně problém, kdy nový snímek ještě hotový není. Předhotovost není problém.
„…generovaly by grafiky snímky pořád a v podstatě jen ty, co by přišly zrovna na řadu k zobrazení, by se zobrazily a ostatní se zahazovaly.“
…takhle se myslím běžně implementuje triple buffering. :-)
To je politováníhodná implementace ;) Chudák grafika, takový dřiny a velká část se vyleje do záchoda :)
Nevyleje. Pokud spočítá snímek za 2 ms, a 14,6.. ms se bude flákat, budeš mít pak na monitoru zbytečně 16,6 ms starý obraz... Bohužel nelze přesně odhadnout, jak dlouho budou snímky trvat, tak nezbývá než počítat, počítat, počítat, a taky topit, topit, topit... Ale spousta her už má i FPS limitery, které se snaží tohle eliminovat. Bohužel pak je tu protipól, když grafika čekala, a další snímek nestihne, a musí nastoupit vSync, a za ušetřený výkon, elektriku a teplo dostaneme propad FPS :/
Takže vyleje :) Jestli musí pět snímků spočítat a jen pátý použít, čtyři byly spočítány jen pro strýčka Příhodu :).
Né - proto abys měl "aktuálnější" obraz :) Predikce je složitá, takže tohle je jediný možný způsob, jak toho docílit. Nebo ten nejjednodušší, a "vyhozený výkon" nás zrovna tady nebolí, i když u notebooků už je to celkem na zvážení.. A jak jsem říkal níže, kde mě díky slohu nikdo ani nečte a nepovídá si se mnou, jistá predikce tu možná je, díky souvislosti obrazu... Kdyby se toho využilo, pravděpodobně by klesla spotřeba energie, resp zvýšila se výdrž, na druhou stranu kdy se stane, že výpočet snímku trvá <5 ms? V místnosti bez předmětů a jedním statickým světlem?
Problém je, když náročnost scény s každým snímkem dynamicky kolísá. Pak se předvídat nedá. A to se v akčních hrách často děje, takže kdybychom jakkoliv predikovali, a do klidu vrazilo mračna partizánů, propad FPS by byl v tu chvíli dramatičtější. Prostě počítat furt je snadné řešení.. :)
Jasně, té snaze o co nejaktuálnější snínek rozumím, stejně jako tomu, že nejsnazší metodou je to počítat pořád a poslední snímek, který je k dispozici v době potřeby jeho zobrazení, vzít a zobrazit.
Na druhou stranu - zrovna mě by asi netrápilo mít snímek starý 16 milisekund, takže bych ocenil tu první možnost, kdy se spočítá a pak se jen čeká na jeho zobrazení a mezitím se další snímek nepočítá.
Když ale pak přijde náročný snímek, díky předčasnému zahájení výpočtu se stihne spočíst beznutnosti zásahu vSyncu. V praxi se to asi moc neděje, resp přijde celá sekvence náročných snímků, a jeden stihnutý už to nezachrání..
Také bych dovedl ocenit první variantu. Například když na GTX660M hraju Rise of Nations. Taková nenáročná hra, běžící asi na 1000 FPS, udržuje grafiku při 70 °C, naprosto zbytečně. Ale na staré hry nikdo nekouká.
Kde bys to chtěl využít ty? Ve 2D?
Ne, právě v takto nenáročných hrách, které se dají zvládnout na stovky FPS. BTW Windows Aero takto grafiku využívá. Renderuje plochu pouze při změně obsahu (pohyb kurzoru není považován za změnu, ten je další nezávislou vrstvou). Navíc ji renderuje typicky na low-power režim (proto to skoro nic nežere, jak si mnozí mylně myslí, a je to i tak svižnější než tradiční „2D“ režim ;-).
Jasně no, ale ve "3D" režimu to běží skoro vždy naplno, nebo na většinu výkonu. Ale tyhle nenáročné hry asi nikoho nezajímají... BTW ty hraješ hry? :D
Je Angry Birds hra? ;)
Ne? :D Tedy pokud bys toto chtěl dostat do smartfounů.... To tedy není uplně hra, při které by 80% práce grafiky bylo zahozeno její přilišnou rychlostí.. Ale jo, smartfouny se více a více podobají počítačům, a smysl by to tam určitě mělo, a úspory by mohly být masivní.. Tak do toho, prosaď to.
Ještě mě na tom zaujala jedna věc: pokud je ta implementace opravdu taková, neměl by Fraps tyhle zahozené snímky také započítávat?
Schválně jsem si něco vyzkoušel: pustil jsem fakt jednoduchou OpenGL aplikaci (Angry Birds) na své integrované IONce (GeForce 9300) se zapnutým VSyncem a zátěž byla zhruba 57 % (refresh mám 60 Hz). Zapnutí Tripple bufferingu (mám-li tak chápat český popisek Trojité vyrovnávání) se zátěží nehnulo (jestli, tak o 1 procentní bod nahoru). Když jsem VSync vypnul, zátěž byla skoro 100 % (přesně 96 %, podle frapsu to umí dát něco přes 110 fps).
Z toho soudím, že při zapnutém VSyncu se skutečně generovaly jen ty snímky, které šly na výstup (a bylo jich 60 za sekundu).
When we asked Nvidia about the merits of triple buffering versus adaptive vsync, we got a response from one of their software engineers, who offered a nice, detailed explanation of the contrasts, including the differences between triple buffering in OpenGL and DirectX:
…
OGL triple buffering: The GPU renders frames as fast as it can (equivalent to v-sync off) and the most recently completed frame is display at the next v-sync. This means you get tear-free rendering, but entire frames are affectively dropped (never displayed) so smoothness is severely compromised and the effective time interval between successive displayed frames can vary by a factor of two. Measuring fps in this case will return the v-sync off frame rate which is meaningless when some frames are not displayed (can you be sure they were actually rendered?). To summarize - this implementation combines high power consumption and uneven motion sampling for a poor user experience.
http://techreport.com/review/22735/a-closer-look-at-some-geforce-gtx-680...
Nechápu, no. :-)
Asi to holt na staré GeForce 9300 funguje jinak, nebo je to závislé ještě na nějakém jiném nastavení (mám všechno default, jen jsem zapnul to trojité vyrovnávání - AB, což je OGL hra, zapínají vsync a zátěž grafiky je zhruba poloviční). Takže žádné zahozené snímky tam v tomto případě nejsou.
No já mám GTX 570 a taky se mi právě zdá, že to ty snímky nezahazuje, ale ještě to vyzkouším. Akorát jsem našel, že to nefunguje současně s FXAA, jinak nevím, čím by to mohlo být.
Však on ten triple buffering na OGL funguje přesně tak, jak jsi naměřil na té GF9300 a v rozporu s tím co píše nVidia to není :)
Pokud zapneš triple buffering bez explicitního vsync, chová se to přesně tak, jak jste tady diskutovali. Snímky jsou renderovány střídavě mezi dva back buffery, postupně přepisovány a při vblank (tedy každých 16,7ms u 60Hz monitoru) je poslední kompletně hotový backbuffer swapnut s fontbufferem (je tam nastaven vsync implicitně). Cpu tedy pojede na full load, Fraps ti bude ukazovat stovky fps, ale většina snímků bude zahozena.
Pokud k triple bufferingu zapneš ještě vsync explicitně co se stane? No oba backbuffery se ti zařadí do fronty. Tedy naplní se ti první backbuffer, pak druhý backbuffer, ale pak už se nic nekoná a čeká se na vblank a swap. Cpu jde do idle, Fraps ti ukazuje maximálně 60 fps, spotřeba klesá a žádný snímek zahozen není.
V každém případě je tu celkem dost možností nastavení jako double, tripple buffering, kombinace vsync, adaptive vsync, frame limiter. Každé nastavení má své plusy i mínusy, ale každý si může vybrat, co mu vyhovuje. Můžeme se bavit celkem o třech věcech:
1. kvalita obrázku (tearing)
2. kvalita iluze pohybu (stuttering či micro stuttering)
3. input lag (doba od input do zobrazení)
Žádné z výše uvedených nastavení nesplní všechna tato kritéria na jedničku. Chcete-li tedy hrát s vysokým fps s kvalitní a netrhavým obrazem, musíte si krom silné gpu pořídit také monitor s vyšším refresh rate (nejlépe 120Mhz). Pokud takový monitor nemáte, musíte holt jít do kompromisu :(
Takhle se mi zdá, že to také nefunguje, když zapnu triple buffering a vypnu vertical sync, tak vidím tearing. Nebo tobě to tak funguje? Na jaké kombinaci HW a SW?
Takto to funguje u OpenGL v případě her, které mají podporu triple bufferingu již (a správně) v sobě implementovanou. Pokud ne, nebo si triple buffering přesto vynutíš v ovladačích, může docházet vizuálním poruchám obrazu jako třeba právě tearing.
U DX to imho funguje také trochu jinak.
Já to pochopil tak, že ta aplikace právě nemusí dělat nic zvláštního, aby to fungovalo (narozdíl od Direct3D). Nejsem expert na OpenGL, ale OpenGL aplikace podle mne vypadá zjednodušeně nějak jako: vykresli snímek, zavolej SwapBuffers, vykresli další snímek, zavolej SwapBuffers atd.
Pokud je zapnutý vertical sync, tak s double bufferingem se to buď ve SwapBuffers, nebo při pokusu o vykreslení dalšího snímku zablokuje, dokud se ty buffery neprohodí. S triple bufferingem se to nemusí zablokovat, protože ti to může dát ten třetí buffer. Pro aplikaci to ale funguje transparentně.
Aplikace by se sama mohla pokusit implementovat triple buffering pomocí FBO (ale nevím, jak by se dělalo to zahazování), to by ale pak fungovalo nezávisle na tom nastavení v ovl. panelu.
Při DB s vSyncem by tedy mohlo docházet k propadům FPS kvůli čekání, na dokončení druhého bufferu, bez vSyncu k tearingu;
U TB by tedy mělo docházet, alespoň u DX aplikací, k neustálému vykreslování střídavě do dvou bufferů, a pokud je jeden hotový, s vSyncem bude akceptován ten poslední hotový, přičemž pokud nebude hotový žádný, bez vSyncu by se udělal tearing, a s vSyncem se počká na dokončení..
No podle té odpovědi od sw inženýra z Nvidie uvedené v tom článku na Tech Reportu (viz odkaz výše) to má u OpenGL fungovat tak, jak píšeš, a u DX tak, že se ty snímky postupně zobrazují všechny a žádný se nezahodí (a když jsou oba back buffery plné, tak se čeká). Akorát to mně ani WIFTovi nechce ty snímky zahazovat ani u OpenGL. :-)
No Wiftovi se snímky zřejmě v té AB zahazovaly (on tearing nehlásil), jenže jak to vůbec bez záznamu FCATu poznat? :)
Můžu to zkusit zaznamenat tou naší HDMI kartou (pokud bude ochotná do sebe nechat poslat obraz z DVI, kde deska s HDMI na DVI vůbec nepočítá). Tearing by neměl být problém tam při hraní najít (kreslená krajina pohybující se horizontálně), pokud tam je (zvlášť na tý Roviácký kreslený krajině to musí být naprosto markantní). Já se zatím díval jen na splash screen a tam se tearing hledá blbě (jen lítající objektíky přes obrazovku).
No on měl ale myslím zapnutý vertical sync. Když zapnu vertical sync i triple buffering, tak tearing nemám, ale nezdá se mi, že by to něco zahazovalo (aplikace hlásí 60 fps, FRAPS hlasí 60 fps a zátěž GPU taky odpovídá 60 fps). Když nechám zapnutý triple buffering a vypnu vertical sync, tak to hlásí hodně fps a vidím tearing. Zkoušel jsem třeba OpenArenu a Unigine Heaven.
Potvrzuji, že ze svého testování mám stejný pocit, akorát tearing jsem detailně nesledoval (jen zátěž GPU-Zkem a fps Frapsem).
... (přesně 96 %, podle frapsu to umí dát něco přes 110 fps). ...
Pokud ti Fraps ukazuje více jak 60 fps u 60Hz monitoru, tak ty snímky nad 60 fps se musely nějak "rozpustit". Buďto byly zahozeny (správnou funkcí TB OGL), nebo jich bylo "nasázeno" do jednoho snímku vícero (tearing). Takže detekce tearingu je při testu rozhodující.
Podle mého je to následovně (opět všechno imho):
OCL implementace TB:
Gpu vykresluje snímek střídavě do obou backbufferů. Když snímek do prvního bakbufferu vykreslí, označí si ho jako (nej)aktuálnější a následující snímek začne vykreslovat do druhého backbufferu. Když je hotovo opět ho si ho označí jako (nej)aktuálnější. No a začne překreslovat zase první backbuffer. Takhle ty backbuffery překresluje střídavě stále dokola a vyčkává na signál začátku vblank. Když přijde vblank, jednoduše provede swap backbufferu, který je označen jako (nej)aktuálnější, a frontbufferu.
DX implementace TB:
U DX je to jiné. Tady se to imho chová úplně stejně jako DB pouze s tím rozdílem, že je přidán do fronty ještě jeden backbuffer. Když gpu vykreslí snímky do obou backbufferů a obsah frontbuffer ještě nebyl kompletně odeslán do monitoru, gpu jde do idle, protože není kam další snímek vykreslovat (tady se backbuffery nepřekreslují).
Jo, takhle to píšou v tom článku (a i všude možně jinde), ale mně se to nějak nedaří donutit, aby to tak fungovalo. :-)
Mám tomu rozumět tak, že:
1. vypnutý vsync a vypnutý tripple buffering vytěžuje grafiku na max a dochází k tearingu
2. vypnutý vsync a zapnutý tripple buffering vytěžuje grafiku na max, ale nedochází k tearingu
3. nastavení tripple bufferingu nemá v podstatě žádný význam, když zapnu vsync
?
V podstatě ano.
1. určitě
2. pokud hra má implementaci TB tak ano
3. spíše negativní dopad - vyšší input lag (je tam o jeden buffer ve frontě více)
Imho on ale i dobře zapracovaný a správně fungující TB má své mouchy. Při vyšších fps, kdy se zahazuje hodně snímků může docházet trhavým pohybům (takový jittering).
PS: Já hry moc nehraju a tyhle úvahy vychází pouze z teorií, takže vyzkoušet v praxi musíš sám. Všechno to je jen IMHO :)
3. třeba nVidia tvrdí, alespoň v ovladači, že zapnutí TB při vSyncu zlepšuje výkon..
Při snímkové frekvenci pod hranicí refresh rate teoreticky ano, jenže tam by měl být dopad vyššího lagu z TB ještě markantnější :(
Pravda je, že ne všechny typy her jsou na nízkém input lagu závislé tak, jako třeba FPS, takže někomu by to zase tak vadit nemuselo.
Právě kvůli tomu, že FPS jsou závislé na input lagu bych očekával provázanost snímků a iterací core/AI, jinak by prakticky nebylo možné trefit (berme vpotaz hru jako Mafia, kde střelbou z Coltu střelíš při klidu přesně tam, kde je puntík). Odtud pramenící výhoda "neviditelného", ale chtěného FPS v online střílečkách, viz předchozí diskuse...
Tak fps to zvyšuje, akorát to v závislosti na té implementaci přidává menší či větší lag.
Právě pro zjednodušení situace jsem mluvil o triplebufferu, protože se principielně z pohledu toho, co všechno se počítá neliší od případu bez vsync. Snímky se generují tak rychle, jak jen to jde. Jediné v čem se liší, je výstup. Zatímco v případě TB dojde de facto k zahození některých snímků, vsync off "pláče".
A důvod použití TB proti DB je jasný - zobrazuje aktuálnější obraz.
@Wift:
".... do framebufferu tak, jak přijdou, tzn. jakmile jsou hotovy. Proto jich tam může být více a jsou natrhané (prostě jak je to hotové, tak se to tam sype, zjednodušeně řečeno). Zatímco při zapnutém VSyncu nesmí jít další snímek, přestože už je hotov, do framebufferu k zobrazení, dokud neuběhla doba rezervovaná pro předchozí snímek"
Jen pro upřesnění. Ty snímky nejsou roztrhané ve frontbufferu, ten obsahuje vždy snímek celý. K "natrhání" dojde až když je frontbuffer odesílán do monitoru, což trvá nějakých těch 16,7ms. V této době se frontbuffer může několikrát změnit (swap front a back bufferu), takže na monitoru vyleze snímek skládající se ze snímků několika - tearing.
Při zapnutém vsync je zakázán swap bufferů do doby vblank (VBI) - tedy do doby, kdy se na monitor nic nevykresluje a nemůže tedy dojít k prolnutí dvou snímků.
Jenže vy tu srovnáváte dva problémy... Rozpadnutý snímek není shuttering - ten vypadá tak, že ve spojitém pohybu něčeho vidíte nějakou nespojitost - objekt (celý snímek, ale u nehybné části to vidět není, proto sledujme třeba valící se sud) se na chvilku zastaví, nebo zpomalí, (v řádu milisekund), a následně poposkočí vpřed. A děje se to i na jednočipovkách, výkonnějších i slabších, se synchronizací, i bez.. Přijde mi nemyslitelné, že by si toho většina lidí nevšimla, ale možná jsem sám - v takových chvílích je ostříží zrak na škodu.
vSync pak řeší něco jiného - tedy když se snímek 1 nestihne dopočítat celý, ale podle uplynulého času je kvůli zachování synchronizace s výstupem na dohodnuté snímkové frekvenci, čas tento snímek exportovat na monitor, a začít pracovat na snímku novém. V takovou chvíli je chybějící část obrazu převzata z předchozího exportovaného snímku, proto vypadá zpožděně (alespoň na jednočipovkách), a v obraze je zlom. Zbytek snímku se buď zahodí, a počítá se nový, nebo se dopočítá, a použije se v případě, že následující snímek opět nebude dokončen včas. Vypadá to na druhou možnost, protože jak se jednou vytvoří zlom, a náročnost renderu zůstane konstantní, tak se ten zlom v obraze pohybuje stále na přibližně stejném řádku, ale spodní část obrazu není "stuck in time" z posledního kompletního snímku - ona se aktualizuje také, ale je v aktivním zpoždění. Zapnutí vSyncu samozřejmě způsobí, že výstup exportuje opakovaně poslední kompletní snímek v bufferu do doby, než se nový snímek dokončí.
Kromě vSyncu by mohlo být ještě jedno řešení, a to dynamické FPS - jakýkoliv LCD displej se totiž samozřejmě může obnovovat pomaleji, než je jeho maximum, přičemž je tu asi nějaký limit, kdy už je nutné pixel obnovit, a blabla, ale vše se dá spočítat a předvídat. Grafika může snadno zjistit, jak je na tom, jak dlouho už tenhle snímek třeba trvá oproti předchozímu (většina 3D obrazu je spojitá, bez střihů), a tedy jak dlouho bude trvat zbytek, a pokud bude trvat 200% přiděleného času, tak si prostě sama displej obnoví se starým snímkem v půlce, a když se čas protáhne na 210%, tedy už do třetího snímku, počká si grafika s jeho obnovením, a jakoby celkově zpoždí celý monitor - jemu to ale asi bude jedno, uživatel nemá šanci si všimnout, a bude to určitě rychlejší a efektivnější, než vSync, který by to celé zpozdil ještě o celý další snímek (a tři stejné snímky už asi nespojitost pohybu vytvoří). Typicky se protáhne čas snímku na kolik 150%? To je zpoždění, které ještě pixel vydrží, a snížení FPS při dynamické frekvenci by bylo nižší, než při statickém vSyncu. A pokud správně chápu technologii LCD, pak může pixel svítit bez refreshe do aleluja, pouze při požadovaném refreshi změí barvu - to nemůže dělat rychleji, než je jeho specifikace, ale pomaleji určitě ano... Opravte mne, prosím, pokud ne.
A ještě co se týče toho neviditelného FPS. Hodně se o tom hráči hádají, ale né nadarmo hrají naprostí závisláci třeba CS 1.6 na grafikách za 5K, ostatní hry na nejnižších detailech, mají třeba 250 FPS.. Ono to vidět není, ale ta hra se jinak chová "v počítači", a je dokázáno, že hráči s vyšším FPS běhají rychleji. Ne o moc, a bez srovnání si toho nevšimnete, ale v rovném sprintu už by to bylo vidět - a hráči to samozřejmě dává do ruky taktickou výhodu, které je v multiplayer hrách k nezaplacení.. Nejspíš to souvisí s množstvím iterací jádra, které jsou vázané na snímkovou frekvenci, a při více iteracích jsou reakce přesnější, dochází k menšímu zaokrouhlování a ztrátám, a hráč tedy běží tak rychle, jak má, zatímco hráči s nižším FPS běhají pomaleji, než by numericky měli. Možná to znáte například ze starších závodních her na slabých počítačích, kde s nižším FPS také sekundy v časomíře utíkaly pomaleji. A to je přesně ono. A deSync je samozřejmě netíží, protože pri FPS 250 nemůže nastat.
Jo jo,
„The Answer is non‐isochronous display updates.“
— John Carmack
Jenom asi budou potřeba nové grafické karty, monitory a přenosové protokoly. :-) Ale v principu to problém není.
Mohly by stačit aj protokoly a nový firmware pro monitory, což?
Už se na to těší v praxi :)
IMHO Odhliadnuc od tech detailov meranie vykonu na samom vystupe meradlom nezavislym na meranom stroji bude vzdy presnejsie ako meranie "uprostred pred samotnym renderovanim" FRAPsom. Aj vykon auta ako celku sa mera najlepsie az na kolesach/dynamometrom a nie na spojke medzi motorom a prevodovkou.
Mylná úvaha. Jen je zbytečné z každého auta vyndavat motor, nebo ho třeba napevno k zdvihnout na zvedáky, a montovat něco ke kolu, atd.
Jinak jde jen o připojení k nějaké části. Při vývoji se motory samozřejmě testují samotné, místo převodovky se k nim našroubuje brzda.
Pak se ale měří i různý výkon - výkon samotného motoru, vs ztráta na převodovce, vs výkon reálně přenesený na kola - ten je nejdůležitější, a k němu se využívá právě velkých válcových brzd.
Lepší paralela měření frapsem je třeba měření změny tlaku ve válci, nebo ještě lépe, sledovuním množství vstřikovaného paliva. Protože co čte Fraps, jsou příkazy aplikace směrem ke grafice/DX, stejně jako je množství paliva pro motor příkazem zaber...
OK v podstate Ste lepsie vysvetlili to co som mal na mysli.Presne tak,na samy zaver nieje podstatne kolko koni ma motor na brzde ale kolko sa prenesie na cestu.Tiez ci bude mat optimalne prevodove pomery ,aerodynamicky pritlak atd..
Tvé přirovnání je stále mimo mísu, ale pointu jsme oba pochopili. Ten systém od nVidie je sice velice přesný, ale zatraceně břehnaně drahý....
Na samotné zjišťování snímkových frekvencí by jistě stačila levnější sestava, jenže toto není jediným účelem FCATu. Nekomprimované video totiž umožní navíc porovnání obrazové kvality...
Ona se obrazová kvalita různých po sobě jdoucích snímků liší? Že by třeba tady grafika nestíhala, tak na chvilku použije texturu s nízkým rozlišením, nebo tak něco?
Možná se pletu, ale z recenzí jsem pochopil, že post procesing se na screenshotech neukáže, neboli je to vlastně podobný problém jako s FRAPSem - může být rozdíl mezi tím co "změřím", a obrazem na monitoru. Konkrétně se to řešilo například v rozborech MLAA.
Jo takhle jsi to myslel.. Je to možné, a dalo by se to tak využít - superdrahá mašinka na dělání screenshotů s proužkem...
Pokud jsem dobře pochopil tvůj příspěvek, pak záznam FCATu není screenshot, ale zachycený finální signál do monitoru - tedy je zde přítomen také veškerý post-processing (krom toho, který je prováděn monitorem)
Ta aplikace na hostovi přímo duplikuje výstup obrazu na druhý fyzický výstup, ne?
Z gpu testovací sestavy jde video signál do DVI splitteru, kde je rozdělen do dvou stejných DVI video výstupů. Jeden pak jde do monitoru a druhý do grabovací karty v druhé sestavě, která video zaznamenává a ukládá. Je tedy zachycen finální obraz (včetně post processingu).
Heh, když dneska grafiky umí 100% klonovat obraz na další výstupy, tak proč nepoužít externí krabičku za další dotované korunky... Celá ta grabovací stanice je sakra předražená.. Ale jo, efekt je stejný..
Imho jde o to, jestli náhodou klonování obrazu při vyšším rozlišení nemá také dopad na výkon a tím i ovlivnění výsledků :(
Jak? Dva výstupy by zároveň braly hotový obraz z jednoho buffferu - tentýž obraz.. Tak bych čekal, že duplikace obrazu pod Win funguje O.o
Zapomněl jsi na blanking ;-), navíc 60 Hz nemusí nutně být úplně přesně 60 Hz, viz např. tenhle režim z EDIDu Achieva Shimian 27" monitoru:
Mode "2560x1440" # vfreq 59.951Hz, hfreq 88.787kHz
DotClock 241.500000
HTimings 2560 2608 2640 2720
VTimings 1440 1443 1448 1481
Flags "-HSync" "+VSync"
EndMode
U toho se posílá 1481 řádků, ale viditelných je jenom 1440, takže ty další, to budou ty černé.
OK, beru, že 60 Hz nemusí být přesně 60 Hz, ale to je kosmetický detail. Blanking mi do toho ale netahej, ten se přece do videa nezaznamenává :).
Je potřeba si uvědomit, jak ta extrakce barevných dat funguje. Program vezme NAHRANÉ video (které lze normálně přehrát - je to obrazový záznam toho, co bylo vidět na výstupu, akorát to není nijak kódováno, je to nekomprimovaný v podstatě RAW) a sleduje na zadaném sloupci pixelů (ano, to lze zadat, standardně je to první sloupec vlevo), jaké jsou tam barevné pixely a tyto barevné pixely zaznamenává do souboru (položka [color]). Dále sleduje, kolik pixelů stejné barvy za sebou jde a tyto sledy stejně barevných pixelů považuje za snímek. Ví, jaké má video framerate, kolik pixelů má video na výšku a z toho počítá ty zbylé sloupce jako čas, fps a tak.
Kdyby se mu předhodilo normální video, kde ty barevné pruhy nejsou, vysype haldu zdánlivých nesmyslů, ale ve skutečnosti bude dělat to, co má - sledovat barvy pixelů v zadaném sloupci. S největší pravděpodobností vyjde něco jako řada framů dlouhých 1 až 2 pixely (výjimečně více), což se projeví jako mraky snímků o rychlosti tisícovek fps.
No to, že je ta zachytávací karta nezaznamenává ale neznamená, že tam nejsou. :-) Když chceš počítat ty časy přesně, tak si myslím, že by se tam měly započítávat. Např. když budu uvažovat ten režim, který jsem psal, tak zobrazit (resp. poslat) 30 řádek bude trvat (30 / 1481) * (1 / 59,951) sekund, ne?
Taky si myslím, že je to vertical blanking a po těžkém párminutovém přemýšlení jsem dospěl k názoru, že je to správně že se započítává :) Kdyby totiž s ním takhle nepočítali, musel by se rendering na počítači po dobu těch 40 řádků vždy pozastavit, aby to vycházelo přesně...jenže on se nezastaví...
Suchý čertík má pravdu. Pokud vím tak u udávaného rozlišení 2560x1440 je skutečné rozlišení 2720x1481 z čehož 41 řádek připadá právě na VBI.
Zní mi to logicky až do té doby, kdy si předstravím ten jeden dlouhý frame jedné barvy, který je přes 3 obrazovky, tedy 2× přerušený pseudo černým snímkem. Kromě toho kdyby se s tím prostě jen počítalo, nemusí to být součástí logu, ne? Bude to dělat vždy 40 meziřádků navíc, nebo ne? Krom toho ten 41. VBI řádek součástí logu není, počítá to s ním?
Tak jsem koukal na ty skripty a funguje to takhle:
{ r => 0x00, g=> 0x00, b=>0x00, cname => "---vblank",}, #vblank
Černou si označí jako ---vblank.
…
#----------------------------------------------------------------------------------------
# Case 1 : Vblank
#----------------------------------------------------------------------------------------
# Check for a vblank - just remember vblank size and continue.
…
Když to na ni narazí, tak si uloží počet těch řádek:
$vblank = $lines;
…
#----------------------------------------------------------------------------------------
# Case 3 : Continued color. Must have a vblank in between
#----------------------------------------------------------------------------------------
# Check for a continued colored bar (note that last_index is not updated for vblanks)
…
Když pokračuje stejný frame, tak k němu ty řádky přičtou:
# this must be a continued bar accross a vblank - Add the vblank time to the rendered frame length
$cur_stripe_length += $lines + $vblank;
…
#----------------------------------------------------------------------------------------
# Case 5 : New color...and correct (after shifting above for dropped frames
#----------------------------------------------------------------------------------------
…
Když pokračuje jiný frame, tak přičtou polovinu k němu a polovinu k předchozímu (nic moc lepšího se vymyslet nedá):
# If the prior line was a vblank then a color change happened during the vblank. split the difference
if ($vblank) {
$cur_stripe_length += $vblank/2;
$lines += $vblank/2;
$vblank = 0;
}
Klobouk dolů :). Takže vlastně to s těmi černými kousky počítá, což je skvělé. Jinými slovy není to bug, je to feature a vlastně ten extractor do toho sám strká ty vblanky, aby s tím pak ty počítací softwary korektně počítaly. Skvělé, o problém méně, děkuji za spolupráci :).
Ale ono to tak vlastně je - jeden herní frame přes 3 obrazovky, 2x přerušený. Správně pro názornost by i to zachycené video mělo mít 1480 (nebo 1481, to už je fuk) řádků, ale je zespodu oříznuto jen na to co jde na monitoru vidět. Při výpočtu se ale s těmi řádky musí počítat.
Problém podle mě bude v tom, že pokud během těch "slepých" 40ti řádků dojde ke změně vykreslovaného framu, tak nelze přesně zjistit kdy to bylo a tímpádem jak dlouho přesně trval. A taky v extrémním případě se do tohoto krátkého okamžiku může schovat celý "microstutterový" frame, který na videu prostě nebude a nebude se dát už nijak zjistit (tj. ve framebufferu karty se objevil zrovna jen ve chvíli, kdy z karty žáden obraz nelezl) - ale to pro nás, co u toho monitoru sedíme, tak není vůbec na škodu.
> Kromě toho kdyby se s tím prostě jen počítalo, nemusí to být součástí logu, ne? Bude to dělat vždy 40 meziřádků navíc, nebo ne?
On ten skript má tu hodnotu i jako vstupní parametr a kontroluje, jestli to bylo opravdu vždy tolik, jinak si stěžuje:
printf ("Likely Mode change @ $refresh_num : Mismatched vblank size expect $blank_interval, got $lines\n");
> Krom toho ten 41. VBI řádek součástí logu není, počítá to s ním?
Tak to buď mají jiné časování, nebo tam mají chybu. :-)
Co se týče té popisované "plnotučné" sestavy na zachytávání snímků, tak jsem si říkal, jestli je skutečně nutné to diskové pole pro ty zmiňované datové toky... Jestli jsem to dobře pochopil, tak nakonec pro účely analýzy jde jen o ty barevné pruhy na krajích, tzn. zbytek obrazu by se mohl zahodit a ukládat jen část snímku, která obsahuje ten pruh nebo víc částí různých pruhů... Nebo je v tom nějaká kulišárna? :)
Není. Zbytek by se opravdu mohl zahodit. Dokonce si myslím, že je to tak málo dat ke zpracování (teoreticky stačí chytat video o rozměrech třeba 1×1080 pro FullHD ;-), že si myslím, že kdyby se dala udělat aplikace, která bude sama hlídat VSync a jen típne obrazovku při každém dalším obrázku na obrazovce (nebo to bude dělat se železnou pravidelností odpovídající refresh rate), tak by se to nakonec vůbec nemuselo grabovat externí sestavou, ale šlo by to udělat přímo lokálně, opět bez znatelného vlivu na výkon.
Jestli tomu dobře rozumím, tak podle Vás je měření FPS bez vsync ať už FRAPSem nebo i jinak je nesmyslné, protože stejně všichni mají vsync zapnutý a obraz se jim proto bude obnovovat s frekvencí 60, 30, 20, ... FPS. V příštích recenzích grafických karet tedy budete ve výsledcích uvádět pouze tyto hodnoty?
V-sync odstraní nepravidelnosti v distribuci snímků (zobrazuje v pravidelných intervalech kompletní snímky), to je pravda. Tak to funguje bez ohledu na sestavu. Nedá se ale říct, že bez ohledu na sestavu se zapnutým v-sync dostanu tentýž výkon - což je předpoklad pro to, aby s ním mělo smysl testovat. Takový test by neměl vypovídací hodnotu, protože by v závislosti na zvoleném LCD (60 nebo 120Hz) vycházely různé výsledky.
A s vyšším refreshem bychom dostali vyšší přesnost (lepší rozlišení), pomalu se blížící o dynamickém refreshi, o kterém jsem lamentoval výše... V tu chvíli by odpadl největší neduh vSyncu u 60 Hz displeje.
Nutno ale říct, že drtivá většina má 60 Hz displeje.. A deSync zlom ve 3D obraze, v různé výšce pro každé oko by musel vypadat opravdu zvláštně... Tady stojím za WIFTem, vSync je "a must have", a pokud se ti FPS propadá moc, kup si lepší grafiku.. A proto taky testy, které grafika dokáže tuhle hru rozjet při aktivním vSyncu, alespoň 4x AA a 2x AF s maximální latencí snímku =33,3... ms alias 2 framy. Protože bez těchto "detailů" hrají jenom sadisti..
4xAA + 2xAF? Hodne divna kombinace....
Jinak ja vsude vsync vypinam, protoze ty sileny skoky z 60fps na 30 a naopak opravdu nemusim. :-D Radsi si zahrat pekne plynule treba na 100fps avg s obcasnymi (pozvolnymi) propady na 50, nez 60 se skokovymi propady na 30. A tearing si ani nepamatuju kdy jsem naposledy videl, takze bez problemu. Nektery hry na to trpi vic, nektery min... tak mam asi stesti na ty "bez-tearingovy" :-)
Tak většinou si tearingu (tak se tomu odborně říká?) všimneš jen lokálně - zejména při otáčení - na větších samostatných objektech - sloupy, domy.. V džungli Crysis 3 si toho asi nevšimneš, no, ale viděl jsem tam nějaké indoor scény, kde to teda bylo vidět celkem hodně, a dokonce i lehce při zapnutém vSyncu @HD7950 OC. A mě to teda "hodně sere" :)
Co je na 4x AA + 2x AF divného? Je to nutné minimum, ale při 16x AF tam kdovíjaký propad ve FPS není. S AA už to tak slavné neni, a nelíbí se mi ani MLAA, FX/TXAA... SSAA FTW, ale taky baští nechutně moc, zejména při vrstvách průhlednosti. Ale ty občasné škuby za parádně vyhlazený obraz stojí.. Ale dostupné/funkční jen na Radeonech.. Zato TXAA, to je v krizových situacích ještě horší, než nonAA.
Jasne, mne naopak vadi sebemensi naznak neplynulosti. Tearing mi naopak (pokud neni prilis masivni) vubec nevadi. :-)
2x AF je docela malo, sice lepsi, nez nic, ale k dokonalosti ma daleko. Dneska uz nema smysl nic mensiho nez 16x. Problemy s narocnosti AF byly naposledy na GF4 Ti. AA uz je horsi, no. Osobne jedu bud bez, nebo 4x/8x MSAA (v zavislosti na vykonu) + k tomu nekdy jeste TRAA. Tyhle SW osery taky neuznavam.
SSAA chci v dohledny dobe vyzkouset, zrovna mi tu v PC vedle bezi Radeon 8500, kterej ani nic jinyho neumi. :-)
V podání, které znám já, funguje SSAA na Radeonech od HD5000 výše.. Ten na 8500 asi tak "dobrý" nebude, a zkreslí ti o něm představu...
Tak minimum je "aspoň něco", protože už s 2xAA, resp 2xAF je situace o dost lepší. Nad 4xAA má smysl jít snad jen u něčeho většího, než je notebookový 15" FHD, tu je celkem jemný rastr.. A AF, jak říkáš, nemá moc smysl řešit, a rovnou valit na plno.. Ale když chceš urvat pár FPS - i moře je složené z kapek...
Neplynulost mi samozřejmě taky vadí, ale když ubírat, tak jinde :) Na něčem, co není vidět... Hodně záleží na hře, ale třeba u MMO her máš nad každým jmenovku a tituly atd, a tohle třeba ani "zapnuté" SSAA, ani nic jiného na nVidii vyhladit neumí, naopak tam ještě pixely tancují, snad u každé takové hry, a to je teprv humus - tancující pixely. Proti nim je Radeonský SSAA skvělá zbraň.. U každé pomalu se hýbající, ale detailní scény s nějaou průhledností (stromy) dochází ke hroznému tancování... Sneaking mise u Sniper Elite a podobné pomalosti, kde si okolí všímáš, to bych pomalu zešílel.. :) U závodních her by zase stačilo provádět AA jen tam, kde jsou auta :D To by FPS trochu povyskočilo...
Tak co se tyce fontu, tak tam vyhlazovani spis vadi.... jsou pak hnusne rozmazany. MSAA na ne prave nema vliv, kdezto SSAA obvykle jo, ale zalezi taky podle hry.
R8500 se nemuze s dnesnima kartama rovnat v zadnym ohledu, to je jasny. Az na kvalitu 2D obrazu pres VGA vystup. :-) Ale je to relativne vzacna karta, kterou jsem dlouho shanel - tak si chci pohrat. Ted jsem zrovna zkousel HL2: Lost Coast a je prekvapivy, jak dobre to vypada. :-) Pro zajimavost dva screenshoty:
http://www.abload.de/img/hl2_1r8u9a.jpg
http://www.abload.de/img/hl2_2f8u7b.jpg
HD5000+ bohuzel nemam, takze kvalitu SSAA proti ostatnim rezimum nemuzu posoudit.
Voda, tráva... Další krásné místo pro aliassing a tancující pixely :)
Pokud jde o HD5770, pro zajímavost screeny z http://cdr.cz/clanek/lenovo-ideapad-y580-kvalitni-vykon-pro-studenta/vla... v původním (smysluplném) rozlišení
https://dl.dropboxusercontent.com/u/6113761/%C4%8Cl%C3%A1nky%20PCP%20a%2... (GTX 660M)
https://dl.dropboxusercontent.com/u/6113761/%C4%8Cl%C3%A1nky%20PCP%20a%2... HD5770
Ano, SSAA má vliv na text a průhledné textury, a to je právě dobře, protože tancující pixely v takovýchto místěch jsou šíleně vidět, a strašně ruší, jak se to chvěje, a v každém framu vypadá něčí jméno jako jiný hieroglyf.. Je to jen příklad hry, ale snad v každé je něco..
Může se zdát, že SSAA lehce rozmazává, ale ono to tak úplně není, a hlavní je, že obraz je stabilní v pohybu, a netancuje, zatímco v jiných AA režimech vypadají snímky v pořadí různorodě, a drtivá většina vyhedávacích algoritmů by v nich nenašla souvislost.. Cenou je šílená náročnost, stoupající právě s vrstvami průhledností..
Masy SSAA odsuzují právě proto, že si ho nikdy nezkusily. A dobře jim tak. Já ho ale považuji za nutnost, stejně jako vSync, a proto si z recenzí absolutně nic nedělám. Jen teď na noutu s nVidií trpím jeho absencí :/
Je to hlavne o osobnich preferencich, ale tady z tech dvou screenu bych osobne volil radsi nv. Sice to bude misty za pohybu problikavat, ale ten druhej obrazek je na muj vkus rozmazanej az prilis. Treba ta dlazdena cesta je viditelne rozmazana a nebo zeme napravo od vody - pobliz cervenyho ramecku. To je zablurovany uplne silene a jemny prokresleni travy a hliny se uplne ztraci. Proto prave nemam rad vselijaky ty SW metody antialiasingu, ty obraz jen rozmazou a tohle vypada dost podobne.
Supersampling jsem pouzival jen na Voodoo5 a tam jsem nezaznamenal takhle velky rozmazani a tim ztratu detailu. AMD zrejme pouziva nejakej jinej algoritmus a horsi kvalitou (a mozna mensim propadem vykonu).
Ano, staticky to vypadá zablurovaně, ale dynamicky je to stabilní, netancující obraz. A zrovna na té trávě, stromech, a jmenovkách je to tancování enormně vidět díky kontrastu barvy objektu a pozadí. Říkám, musíš vidět, pak pochopíš :) Někoho tancování neruší, někoho ano; někde vidět je, někde není.
Vtip je ale v tom, že na nVidii je SSAA for transparency také zapnuto. Přitom za tím ve všech (enginově odlišných) zkoušených hrách je naprosto inertní, a nic nedělá. To mě silně zaráží.
Re: „Jestli tomu dobře rozumím, tak podle Vás je měření FPS bez vsync ať už FRAPSem nebo i jinak je nesmyslné, protože stejně všichni mají vsync zapnutý a obraz se jim proto bude obnovovat s frekvencí 60, 30, 20, ... FPS. V příštích recenzích grafických karet tedy budete ve výsledcích uvádět pouze tyto hodnoty?“
(citoval jsem proto, aby bylo jasné, nač odpovídám, protože diskuze není přehledná)
Jednoduše: pro srovnání grafik při testování výkonu je skutečně potřeba VSync vypnout, protože bez toho bychom skutečně dostali jen ty kulaté hodnoty. Pro praktické využití VSync nechávám zapnutý, protože chci mít obraz plynulý a netrhaný. Já grafiky netestuji, proto se na to dívám jinak. Mám na grafiky jiné nároky.
Pokud to chci použít jen na měření FPS a ten obraz na nic nepotřebuju, nestačilo by zachytávat jen ten levý pruh? :)
Podobný dotaz již padl, ano, stačilo, ale grabovací karta normálně chytá všechno ;) Musela by se udělat aplikace, která z toho zachyceného obrazu bude ukládat jen to, co chceme (tedy ten pruh, klidně by stačilo, aby byl jen 1 pixel široký).
Dufam ze buduce grafiky budu natolko vykonne, ze nebudeme potrebovat kupovat viac ako jednocip! :P a ked ten jednocip zvlade 120FPS vsync, pri rozliseni 4k+3D, kde netreba AA, na OLED, tak vsetko bude parada... snad sa dozijem... myslim ze graficky vykon by mal stupnut aspon 4 nasobne aby sme boli na tom OK, ale nasa korupcna kriza to kvalitne vsetko zabrzdi... :p cize sci-fi
tolik penez a pritom takova blbost.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.