AMD FreeSync / VESA Adaptive-sync - info a vše okolo

[ttxman]

Kde se vzalo to násobení framů? Kromě PC perspective to nemůžu nikde najít. Když se podívám na původní recenze tak tam nic takovýho není. Pouze zmínky jako "do 30FPS stejný sekání jako s Vsync", "když nestihne vykreslit do 33.3ms, kreslí snímek znova" atd.
Nvidie o v materiálech nic nemá a grafem by se určite pochlubili.
Logicky nemůžu vědět jak dlouho se bude na další snímek čekat, takže předem nemůžu vědět kolikrát a jestli vůbec budu muset násobit, takže začátkem framu nemůžu volit "virtuální" refreshrate.
Mimochodem podle toho co sem našel tak mezi Gsync modulem a GPU běží polling s intervalem ~1ms typu "už máš další snímek?" a nic víc. Takže modul nemá k dispozici pro predikci nic víc než frametimy co si změří. To nemůže fungovat to si na PCPerspective VYCUCALI Z PRSTU

[DOC_ZENITH]

Docela bych i polemizoval o výkonu vs schopnostech onoho modulu. Je to PGA... ok... PGA, ne žádnej super chytrej čip, podobná PGA se používala jako řídící elektornika u některejch starších 30" LCD panelů. je tam paměťovej buffer + ono PGA co jej řídí. PGA =/= plnohodnotné CPU a vy se tu bavíte o algorytmech dopočítávání snímků v případě že ňákej chybí atd, ihmo tak to nemůže nikdy fungovat, jakmile chybí a prodleva by byla pro display přiliš velká tak tam to PGA prostě provede jedno další přereslení na top rychlosti monitoru + když zorvna v tu chvíli dorazí další frame, uloží se dočasně do onoho paměťového bufferu, může tam bejt delay než se ono překreslení dokončí a pak jde tento frame na řadu, opět se tam narve co nejrychleji a pak se zase čeká na další jestli se stihne přivalit v termínu, ihmo tak vidim že to PGA bude fungovat, rozhodně tam nebude něco složitě real-time analyzovat.

[ttxman]

Doc: presne to je moje logika ta predicke nemuze fungovat a vracime se na stranu 37

[hnizdo]

GSync tam ještě u hranice 30 fps refresh zvýší na 60Hz, ale pod 20 fps už to padá také.

Gsync podle pcper "nasobi" fps celymi nasobky tak, aby vysledek presahoval 30Hz. Vyrovna se i s 14Hz a podobne. To dava smysl, a je to jednoducha metoda. Navic kdyz ti prijde novy snimek, okamzite ho muzes po prijeti vrznout na screen, nemusis na nic cekat, proste prerusis cekani na self refresh.

[hnizdo]

Mimochodem podle toho co sem našel tak mezi Gsync modulem a GPU běží polling s intervalem ~1ms typu "už máš další snímek?" a nic víc. Takže modul nemá k dispozici pro predikci nic víc než frametimy co si změří. To nemůže fungovat to si na PCPerspective VYCUCALI Z PRSTU

Co brani modulu prerusit planovanou predikci okamzite po prijeti noveho snimku obdrzeneho mimo planovany interval? V nejhorsim moznem pripade vznikne lag dany schopnosti modulu reagovat na zmenu framebufferu, kdyz stary snimek byl prave vykreslen a teoreticky ihned je k dispozici novy.

[Ache]

Navic kdyz ti prijde novy snimek, okamzite ho muzes po prijeti vrznout na screen, nemusis na nic cekat, proste prerusis cekani na self refresh.

Tohle by dělalo psí kusy s odezvou. Nezapomeň že každý refresh rate potřebuje jiný ovedrive level, takže monitor předem musí vědět za jak dlouho přijde další snímek aby mohl nastavit správně OD na ten který právě má zobrazit.
Podle mě G-SYNC má stejný lag jako V-SYNC, modul v sobě akumuluje jeden snímek dopředu aby věděl co se bude a za jak dlouho vykreslovat. Výhodou takového řešení je 100% plynulost, a 100% možnost odladit odezvu (což se na ACERu třeba povedlo), nevýhodou je inputlag který bude při nízkých fps znát.
Nicméně Adaptive Sync monitory podle mě musí fungovat stejně. Jak chceš udělat adaptivní refresh bez toho aniž by si věděl za jak dlouho vykreslíš další snímek? Pokud by se udělal displej třeba 9-240Hz s tím že by elektronika jen překreslovala snímky, tak by tam musel být nějaký jen mírný OD, který by dělal při nízkých fps jen mírný ghosting a při vysokých fps blur. Což je blbost. Pevný ovedrive level může fungovat jen na pevném refreshrate.

[hnizdo]

Domnivam se, ze prace s overdrive se musi prizpusobit krajnim moznostem.

EDIT:
FreeSync relies on the regular adaptive sync TCONs that at present don't seem capable of correcting for this when operating in VRR modes. The BENQ panel does have a 'Blur Reduction' mode, but that drops it out of FreeSync mode and shifts to constant refresh when enabled. One note - switching this while running the FreeSync demo hung the display and I could only get the screen back up after rebooting both the system and hard restarting the panel by unplugging it.


Protoze tu evidentne nikdo nema whitepapers obou technologii, budeme muset zatim vzit na vedomi, ze zjisteni pcperu jsou platna, dokud se neobjevi neco dalsiho.
Pro mne je tedy fsync fail roku.

[webwalker]

GSync tam ještě u hranice 30 fps refresh zvýší na 60Hz, ale pod 20 fps už to padá také.

Gsync podle pcper "nasobi" fps celymi nasobky tak, aby vysledek presahoval 30Hz. Vyrovna se i s 14Hz a podobne. To dava smysl, a je to jednoducha metoda. Navic kdyz ti prijde novy snimek, okamzite ho muzes po prijeti vrznout na screen, nemusis na nic cekat, proste prerusis cekani na self refresh.

Ne, nikdy ho nemůžeš okamžitě poslat na monitor. Vždy musíš provádět pooling, jestli monitor neprovádí zrovna self-refresh a je ve VBI. Musíš prostě čekat úplně stejně jako normálně, jen ten pooling tě může stát další 1 ms.
Jo ještě jsem zapomněl, gsync tam má ten buffer pouze z toho důvodu, že je bypassována vlastní elektronika monitoru. Pro funkci variabilního refresh jako takovou není vůbec potřeba.

[ttxman]

Gsync podle pcper "nasobi" fps celymi nasobky tak, aby vysledek presahoval 30Hz. Vyrovna se i s 14Hz a podobne. To dava smysl, a je to jednoducha metoda.

Jenže to nejde.. To že je to jede na vykreslovanym snimku 14FPS se dozvíš až když je frame dokreslenej za 71ms. Do tý doby víš tak akorát za kolik se ti vykreslil minulej frame. To je ale k ničemu, jelikož problém kterej to má řešit je kolísání frametimu.

Co brani modulu prerusit planovanou predikci okamzite po prijeti noveho snimku obdrzeneho mimo planovany interval? V nejhorsim moznem pripade vznikne lag dany schopnosti modulu reagovat na zmenu framebufferu, kdyz stary snimek byl prave vykreslen a teoreticky ihned je k dispozici novy.

Pokud vyrobíš novej snímek a při nejbližšim refreshi ho nahraješ do monitoru tak tak přesně funguje obyčejný Vsync. (A freesync s Vsync On) a žádný násobení FPS se nekoná. (pořád se bavíme o chování mimo oblast kde adaptivní vsync funguje)

[hnizdo]

Ne, nikdy ho nemůžeš okamžitě poslat na monitor. Vždy musíš provádět pooling, jestli monitor neprovádí zrovna self-refresh a je ve VBI. Musíš prostě čekat úplně stejně jako normálně, jen ten pooling tě může stát další 1 ms.
Jo ještě jsem zapomněl, gsync tam má ten buffer pouze z toho důvodu, že je bypassována vlastní elektronika monitoru. Pro funkci variabilního refresh jako takovou není vůbec potřeba.

Dekuji CptObvious, ano, pockam na poll, a pak posilam. +1ms

K tomu gsync a k cemu je potreba buffer:
G-Sync uses its on-board memory to buffer the previous frame, using this data combined on-the-fly with the next incoming frame to calculate appropriate drive voltages and compensate for ghosting (similar to overdrive).

Krome toho, podle tvrzeni pcper se buffer pouziva prave pri "nasobeni" fps.

Jenže to nejde.. To že je to jede na vykreslovanym snimku 14FPS se dozvíš až když je frame dokreslenej za 71ms. Do tý doby víš tak akorát za kolik se ti vykreslil minulej frame. To je ale k ničemu, jelikož problém kterej to má řešit je kolísání frametimu.

Potom muze proste gsync pouzivat prumer za casovy usek a jsou dalsi cetne moznosti, jak ridit synchronni proces asynchronnim signalem. Ty sis vybral jednu moznou (tu nejjednodussi) a tu jsi poprel.

Pokud vyrobíš novej snímek a při nejbližšim refreshi ho nahraješ do monitoru tak tak přesně funguje obyčejný Vsync. (A freesync s Vsync On) a žádný násobení FPS se nekoná. (pořád se bavíme o chování mimo oblast kde adaptivní vsync funguje)

To neni pravda. Pokud gsync posila data do monitoru v intervalech X a dostane data asynchronne s timto intervalem, muze interval bud zrusit a data poslat hned, nebo pockat na dokonceni intervalu. Tedy gsync data prijima od gpu a vysila do lcd asynchronne (pod VRR limitem!), zatimco proces vsync je s gpu synchronni (taky mimo VRR). Je irelevantni, jestli je proces vsync synchronni s vytvarenim snimku uvnitr gpu, to si resi gpu pred odeslanim snimku pres DP (tripple buffer atd.)

A panove nezapominejme na to, ze pcper ucinil pozorovani v souladu s jejich vykladem funkce gsync a vsync. Takze nemusite s tim souhlasit, ale nemate ani teorii ani data, takze opatrne. Mne sice zavery pcper prijdou naprosto logicke, ale zatim nevim o podrobnejsi recenzi, ktera by to potvrdila/vvyratila.

[webwalker]

@hnizdo: Nikoliv Jelimánku, ty musíš pollovat neustále, dokud ti poll nevrátí, že monitor má VBLANK.
A přesně tak, bez bufferu by gsync nemohl udělal overdrive, protože modul obchází elektroniku monitoru.

[ttxman]

Jenže to nejde..

Potom muze proste gsync pouzivat prumer za casovy usek a jsou dalsi cetne moznosti, jak ridit synchronni proces asynchronnim signalem. Ty sis vybral jednu moznou (tu nejjednodussi) a tu jsi poprel.

Problem je v tom co ma bejt vysledek. Podle me to ma bejt plynuly zobrazovani i pri nahlym propadu fps, jelikoz nebudu prece hrat na 144Hz Gsync monitoru hru na 20FPS. Zadnej kratkodobej prumer nebude fungovat kzdyz ti to po vterine stabilniho FPS dejme tomu 60 prijdou snimky typu 15FPS 29FPS 60FPS 10FPS a zase stabilita 60FPS.
Pokud do nasobi framy tak aby fps bylo mezi 30 a 60 podle tech grafu, tak frametime spatnym odhadem muze nabrat frametime navic az do nejakejch 16.6ms. Kdezto klasickej Vsync v tomhle pripade nenabere nikdy vic nez nad 6.9ms.
Vysledkem by byly vetsi lagy mozna mene casto, ale vetsi..

Pokud vyrobíš novej snímek....

To neni pravda. Pokud gsync posila data do monitoru v intervalech X a dostane data asynchronne s timto intervalem, muze interval bud zrusit a data poslat hned, nebo pockat na dokonceni intervalu. Tedy gsync data prijima od gpu a vysila do lcd asynchronne (pod VRR limitem!), zatimco proces vsync je s gpu synchronni (taky mimo VRR). Je irelevantni, jestli je proces vsync synchronni s vytvarenim snimku uvnitr gpu, to si resi gpu pred odeslanim snimku pres DP (tripple buffer atd.)

Proces Vsync synchronizuje presun front framebufferu do monitoru ostatni je asynchroni, teda v situaci kdy monitor ma vetsi refresh nez GPU stiha kreslit.
Framebuffer (front) na GPU je pri double a triple bufferingu synchronni s monitorem. Backbuffer se plni asynchronne na refreshi monitoru. Prehozeni bufferu probiha tak aby se v dobe prehozeni neposilali data na LCD.

Gsync modul tohle posunul primo do monitoru a pridal moznost natazeni vblank intervalu coz GPU samotny neumi (aspon u Nvidie), ale funguje to porad uplne stejne jako Vsync.

A panove nezapominejme na to, ze pcper ucinil pozorovani v souladu s jejich vykladem funkce gsync a vsync. Takze nemusite s tim souhlasit, ale nemate ani teorii ani data, takze opatrne. Mne sice zavery pcper prijdou naprosto logicke, ale zatim nevim o podrobnejsi recenzi, ktera by to potvrdila/vvyratila.

Teorii mame, nemame data. A taky mame pochybnost o tom co pise pcper, protoze pcper je jedinej kdo neco takovyho tvrdi, ostatni recenze Gsync nerikaji o fps pod limitem nic, nebo ze je to stejne spatny jako s Vsyncem.

edit: nemluve o tom, ze graf freesync maji pod 40Hz je uplne spatne, protoze to ta rovna cara bejt nemuze, takhle totiz Vsync nevypada (kterej tam AMD ma na 100%) a nevypada tak ani zobrazeni s vypnutym vsyncem.

Data by se dali udelat, ale vzadovalo by to nekoho s Gsyncem a kamerou s hodne vysokym fps idealne aspon 2nasobek maximalniho refreshe cim vic tim lip (1000fps+ by bylo super). Spichnul by se program ktery generuje posloupnost barevnejch obrazovek porad dokola s pevne nastavenymi nizkymi FPS (treba tech 14). Z poctu framu ve videu s urcitou barvou uz by se dalo zjistit jak ta synchronizace probiha

[hnizdo]

Uz neni mozne qutovat, takze jen strucne.

Prvni cast o gsync - jenze ono to s tim nasobenim klidne takto fungovat muze, i s tim lagem. Pokud se podivas na zmerene lagy gsyncu, nejsou vzdy konstantni. Takze to spis potvrzuje teorii pcper.

Druha cast o vsync - zacinam mit pocit, ze mluvime oba dva o tom samem, ale jinymi slovy. V kazdem pripade na veci se tim nic nemeni, gsync dokaze byt z hlediska prenosu do panelu synchronni i mimo VRR (krome horniho limitu, zatim), fsync ne. Ty s tim nesouhlasis, ok, ja ano.

S tim merenim mas pravdu, i kdyz by uplne stacilo mit ty monitory vedle sebe a porovnat gameplay pri 25fps.

[DOC_ZENITH]

Já si quotnu sám sebe protože si myslim že Gsync fakt funguje takhle.

Docela bych i polemizoval o výkonu vs schopnostech onoho modulu. Je to PGA... ok... PGA, ne žádnej super chytrej čip, podobná PGA se používala jako řídící elektornika u některejch starších 30" LCD panelů. je tam paměťovej buffer + ono PGA co jej řídí. PGA =/= plnohodnotné CPU a vy se tu bavíte o algorytmech dopočítávání snímků v případě že ňákej chybí atd, ihmo tak to nemůže nikdy fungovat, jakmile chybí a prodleva by byla pro display přiliš velká tak tam to PGA prostě provede jedno další přereslení na top rychlosti monitoru + když zorvna v tu chvíli dorazí další frame, uloží se dočasně do onoho paměťového bufferu, může tam bejt delay než se ono překreslení dokončí a pak jde tento frame na řadu, opět se tam narve co nejrychleji a pak se zase čeká na další jestli se stihne přivalit v termínu, ihmo tak vidim že to PGA bude fungovat, rozhodně tam nebude něco složitě real-time analyzovat.

Samo sebou, onen buffer a data o snímcích co tečou do něj může bejt použitej pro ovládání overdrive a pod, v tom neni problém.

Otázkou pro mě zůstává jak to dělá Freesync co žádnej buffer nemá. Tam možná snímek čeká na GPU? Tzn fungovalo by to jako vsync on ale s variable refresh rate. To by ale mělo za následek docela tfuj inputlag.... a jak funguje overdrive když tam neni žádná paměť... vejde se to do ňáké cache přímo elektroniky panelu? Jak velká paměť vlastně musí bejt? Pro ovládání overdrive je potřeba jen záznam o příchodu framu a timing nebo celej snímek?

Pokud celej, tak jak sakra fungujou monitory co maj overdrive + maj inputlag 0, a takové existují... ugh...

[del42sa]

Otázkou pro mě zůstává jak to dělá Freesync co žádnej buffer nemá....

samozřejmě že má

[hnizdo]

a jak funguje overdrive když tam neni žádná paměť.

U toho BenQu je overdrive neaktivni, pokud se pouziva VRR. Taky jsou tam ty duchy.

Otázkou pro mě zůstává jak to dělá Freesync co žádnej buffer nemá....

samozřejmě že má

Samozrejme nema, a neni tam ani potreba. K funkci fsync tak jak je popsana prave nepotrebujes vubec zadny buffer, k cemu by tam byl? Proste kdyz je monitor v okne VRR, jedeme synchronne, buffer netreba. Mimo VRR je fsync vypnuty a jedeme asynchronne nebo s vsync, opet neni zvlastni buffer potreba.

[DOC_ZENITH]

Tak bez overdrive to ale bude docela humus... že...

Zajímavé že to v recenzi toho velkého LG neuvedli, to neviděli že jim nefunguje overdrive? Nebo to ten konkrétní monitor řešil ňák jinak...

[del42sa]

Samozrejme nema, a neni tam ani potreba. K funkci fsync tak jak je popsana prave nepotrebujes vubec zadny buffer, k cemu by tam byl? Proste kdyz je monitor v okne VRR, jedeme synchronne, buffer netreba. Mimo VRR je fsync vypnuty a jedeme asynchronne nebo s vsync, opet neni zvlastni buffer potreba.

přemejšlíš vůbec chlape ? a co se asi stane když k tomu monitoru připojíš kartu která nepodporuje FreeSync ? Tak bude fungovat bez bufferu, který má v sobě každý monitor, že ?

[DOC_ZENITH]

Ne každej, buffer maj jen monitory co prováděj postprocessing a většinou moc malej aby se dal použít pro variable refresh/freesync buffering a pod. Zde u tohoto benQ je realita taková že s Freesync nefunguje overdrive. Tim nezavrhuji freesync jako standard ale tento monitor označim za nevhodnej pro freesync.

Bude to prostě chtít počkat na monitory s elektronikou co byla naveržená tak že se tam s tim počítalo. Ne flashnuté starší návrhy kde povypínej spoustu věcí aby to učinili freesync compatible.

[Krteq]

To byl sarkasmus. Jak by pak s Adaptive-Sync fungovali grafiky jiných výrobců (Intel) kdyby Free-Sync nepoužíval žádný buffer

Zde u tohoto benQ je realita taková že s Freesync nefunguje overdrive. Tim nezavrhuji freesync jako standard ale tento monitor označim za nevhodnej pro freesync.

Na tftcentral to vysvětlují jako bug FW toho panelu (TCON issue)