PCTuning fórum

Ache píše:RAD-X: Ale přece synchronizací LCD (nebo jiného zobrazovače) s frameratem hry docílíš té nejlepší možné plynulosti při jakémkoliv fps (požadovat dnes Crysis 3 na 120fps je asi docela mimo možnosti... pokud nebreu jako možnost používat GTX780 grafiku na 640x480 + low detail ). Co se děje v tvém případě na který tady poukazuješ tj. třeba že dáš 40fps V-sync (při 60Hz displeji)? Budou se mezi sebou střídat pravidelně snímky 16, 16, 33 , 16, 16, 33ms... snímky. Takže jakýkoliv pokles fps při V-Syncu ti způsobí jasně viditelnou neplynulost (micro stuttering)!!! Kdyby si to G-Syncnul/Freesyncnul a LCD se přizpůsobilo frameratu, měl by si v téhle situaci najedou třeba 21, 19, 20, 19... ms snímky (počítam že vždy bude každý snímek na odlišné freamerate) = minimální časové rozdíly mezi snímky.

Bez V-syncu také situace není růžová - máš tam tearing a ten dost nechutně trhá obrazem při fps blízko refreshe monitoru nebo jeho násobku (nastavit si třeba 58 nebo 62fps limiter na 60Hz bez V-sync je fakt hrozný)...

Takže nemůžu si pomoct, ale synchronizace snímků hry s monitorem je nejlepší možný řešení. 120,140Hz monitor ti pomůže jak v případě v-sync on tak vsync off, ale s plynulostí na tom vždy při stejném fps bude plná synchronizace lépe - tomu fakt věřim pokud dobře ošetří lag. nic lepšího se vymyslet nedá... možná V-sync na třeba 1000Hz displeji - tam by se běžné fps jako 50 až 100fps docela snadno synchronizovaly na co nejbližší časové úseky... a bez V-syncu by to akorát způsobovalo efekt jako na snímání rychlého pohybu na rolovací záverce (nebo digi čipu C-mos):
http://abload.de/img/3619226285_6ec9b4cdef7pa8k.jpg
... akorát 1000Hz by vyžadovalo asi monstr datové toky... na 4K budoucnost unreal ...G-sync je ale realizovatelný s kompromisem nějakého lagu.

Ty o voze já....tady jde o to že 30Hz je opticky neplynulý a tečka, že je to ultrasynchro s RR neřeší podstatu problému, oko to jasně pozná, já poznám i 50Hz oproti 60 a oproti 70Hz, proto jsem silně přesvědčený o tom že u FPS multiplayer her teahle technologie těžce selže ať už NV nebo AMD, cokoliv zabývající se nižší RR = fail....protože milion výše uvedených dúvodú.

Jasně že třeba 30fps není opticky plynulý, ale nic ideálnějšího než synchronizace snímků z refreshem monitoru vymyslet asi nejde pořád bude např. lépe okem vnímáno plně synchronizovaných třeba 35fps @ 35Hz, než 35fps @ 60 nebo 120Hz. (v druhém případě to samozřejmě je lepší, ale ideál je až těch fps = Hz)

ifkopifko píše:Keby si radšej napísal niečo konkrétne, ale to by od teba človek chcel priveľa. Bobáčik môj, ťo čo si tam vyššie popísal je presne stabilný refresh, nie variable. g-sync nepochybne môže mať spodný limit kdekoľvek nastavia že sa vykoná self refresh, nie len práve na 30fps (33,33ms). Kľudne 29 či 32fps, či akúkoľvek inú hodnotu, ktorú by panel zvládal. Zvolili 30fps, ale ty tu musíš fabulovať nezmysly, a ešte tu robiť chytráka.

Jak jsem řekl, nevíš o čem jsme tu mluvili a to je tvůj problém, navíc mícháš dvě věci dohromady. Self-refresh nemá s dynamickým sync nic společného, pouze jeho časování má vliv na jeho účinnost a to jsou dvě různé věci ifchytráčku
Dynamický sync nedělá nic jiného než to, že prodlužuje interval vblank tak, aby vykreslování následujícího snímku mohlo začít okamžitě po jeho dokončení v backbufferu. Pokud je snímek dokončen vždy v intervalu refresh, není žádný rozdíl mezi klasickým v-sync a d-sync (interval vblank nemusí být prodlužován). D-sync tedy nabírá významu, až když jsou snímky generovány v backbufferu v latencích vyšších než je hodnota intervalu refresh. Čím déle tedy můžeš prodloužit interval vblank, tím vyšší zisky z něho budou oproti v-sync. Ideální by bylo, kdybys mohl držet vblank libovolně dlouho, ale to nejde díky vlastnostem LCD a tady teprv nastupuje otázka self refresh a kam ho umístit, abychom neztratili účinnost d-sync.

U 60hz monitorů:
Do intervalu 0-16.7ms? To je blbost, není proč a účinnost by klesla pod v-sync (viz výše), takže zbývá 16,7 až nekonečno s tím, že čím více by ses přibližoval k 16,7ms, tím horší účinnost by d-sync měl, takže to nekonečno by bylo neideálnější - jenže to nejde. Někde za 33,4 ms ti začíná prosvětlování pixelů (flickering obrazovky) a půjdeš-li ještě dál k 50ms může dojít k poškození krystalů LCD (zřejmě ta minimální refresh, jak o ní mluvil Hnízdo v souvislosti s EDID). Takže je vlastně rozhodnuto, self refresh nelze udělat prakticky jinde, než v čase 33,4ms (pokud se nám technologie LCD nezmění) a tak tomu bude jak u g-sync, tak jistě také u f-sync. S tím rozdílem, že u g-sync se o self refresh postará modul (ostatně stejně tak se stará držení vblank u sync), kdežto u f-sync gpu.

Ache píše:Jasně že třeba 30fps není opticky plynulý, ale nic ideálnějšího než synchronizace snímků z refreshem monitoru vymyslet asi nejde pořád bude např. lépe okem vnímáno plně synchronizovaných třeba 35fps @ 35Hz, než 35fps @ 60 nebo 120Hz. (v druhém případě to samozřejmě je lepší, ale ideál je až těch fps = Hz)

Já ti rozumim, jako antitearing metoda je to bez debat, ovšem já bych stejně radši viděl stav např 140FPS a 140HZ a tam klidně sync...sice by byl taky inputlag ale asi bych z toho nepadal na hubu. Když se zamyslim nad možnostma dnešní elektroniky a podívám se na věci který nám cpou jako že "you must have" je mi z toho špatně. Každopádně jak budou první monitory Gs monitory, tak to pujdu omrknout jak moc je to na prd a budu doufat v nějakej zázrak.

Krteq píše:
1) Ano, DP to přímo neřeší, ale když si prohlídneš už první revizi standardu, zjistíš, že DP si na Linkové vrstvě vyčítá parametry panelu z EDID, aby mohl korektně uskutečnit spojení mezi adaptérem a zobrazovadlem.

To jsou informace o monitoru, nikoliv panelu. Minimalni refresh panelu je dosud ciste zalezitosti firmware a nikdo to dosud nepotreboval. Takze ne, GPU/OS zadnym zpusobem nemuze zjistit minimalni refresh rate pouziteho panelu.

Krteq píše: 2) Pokud panel podporuje eDP v revizi 1.3, podporuje PSR i FreeSync (vyžaduje eDP 1.0). Pokud není zrovna panel připojen přes adaptér s podporou PSR, může se klidně použít FreeSync.

To je v rozporu s cim konkretne? Samozrejme pokud _panel_ nema dram a neumi PSR, muze se pouzit a zrejme se i pouzije variable vsync. Pokud panel dram ma a PSR podporuje, pouzivat vvsync je ponekud debilni, ze (tedy pokud nekdo nebude takovy debil, ze nalepi PSR panel ke GPU, ktery PSR neumi, ale ja nejsem zodpovedny za duseni poruchy konstrukteru, to tu resit nehodlam).

Krteq píše: 3)Proč by měla být nulová? Myslíš, že výrobci panelů používají pro NTB a Desktop panely pokaždé jiný scaler?

Jiste ze ano, ty muj kulisaku Treba kvuli spotrebe, v ntb zbytecne podpore DVI/VGA a naopak stale potrebe lvds, zbytecnemu hw skalovani v ntb, zbytecne podpore 1:1 pixel formatu a dalsich hovadin nalezicich do domeny desktop monitoru.
A taky porad beru tvrzeni nvidie ze takovy scaler neexistuje jako dobre informovane, be ohledu na to jak je logicke

Krteq píše: A ještě jednou opakuju, že standard DP 1.3 není ještě uzavřený, takže co brání VESA members AMD/Intel atd. do finální podoby tuhle feature protlačit?

Vubec nic, ja hovorim o aktualnim stavu. Je klidne mozne ze za pet let bude vsude v-vsync a gsync updane v zapomeni jako prukopnicka technologie , ktera mela jepici zivot Je to proste mozne. Moc tomu neverim, kdyz se podivam, kolik desktop lcd ma dneska DP.

webwalker píše: Někde za 33,4 ms ti začíná prosvětlování pixelů (flickering obrazovky) a půjdeš-li ještě dál k 50ms může dojít k poškození krystalů LCD (zřejmě ta minimální refresh, jak o ní mluvil Hnízdo v souvislosti s EDID).

Aniz bych se chtel pustit do analyzy tve dojmologie, jen upresnim: k poskozeni LCD (trvale disociaci obsahu bunky) dojde pri ss buzeni az za nekoli set az tisic ms. Prilis dlouhy refresh jeste hluboko pod touto hodnotou ale zpusobi, ze rozptyl ztratovych parametru jednotlivych pixelu zacne byt tak markantni, ze vzniknou barevne mapy a jine artefakty.

hnizdo píše:To jsou informace o monitoru, nikoliv panelu. Minimalni refresh panelu je dosud ciste zalezitosti firmware a nikdo to dosud nepotreboval. Takze ne, GPU/OS zadnym zpusobem nemuze zjistit minimalni refresh rate pouziteho panelu.

To co jsi napsal snad nemyslíš vážně, že ne Kde myslíš, že jsou EDID informace uloženy? Jaký je podle tebe rozdíl mezi monitorem a panelem?

Pokud tedy není žádná možnost jak ty informace zjistit, jak to tedy řeší G-sync? Ano, vyčítá to z EDID/E-EDID/DisplayID a driver s tím dál manipuluje, však si to přečti znova.

The ability for NVIDIA to pull of this feat of magic is built around the fact that while the monitor sends EDID information to the graphics card to request a specific set of timings, it is in fact, only a request. The graphics card has the ability to adjust these signals in any way it wants though in the past it has always followed the correct timings in order to guarantee compatibility and not damage system components.

Něco málo o FreeSync od Lukáše Fialy - Proč G-sync, když máme standardy? Otevřené řešení podpořil i Intel

@hnizdo: Není problém, pokud to, co jsem napsal je dle tebe dojmologie, rád si přečtu tvůj příběh o dynamickém sync, pokud se tedy o něj s námi podělíš
Mimochodem, označit q-sync jako průkopnickou technologii chtělo asi hodně odvahy teď, když víme, že si to nVidia zřejmě "vypůjčila" někde jinde

@RAD-x, Ache: Imho jakýkoliv d-sync bude těm skalním hráčům, kteří honí fps a inputy asi k prdu. Tohle je tak pro hráče, kteří se chtějí kochat prostředím, nebo s tím pracují nějak profesionálně (3D atp.).

Krteq píše:

hnizdo píše:To jsou informace o monitoru, nikoliv panelu. Minimalni refresh panelu je dosud ciste zalezitosti firmware a nikdo to dosud nepotreboval. Takze ne, GPU/OS zadnym zpusobem nemuze zjistit minimalni refresh rate pouziteho panelu.

To co jsi napsal snad nemyslíš vážně, že ne Kde myslíš, že jsou EDID informace uloženy? Jaký je podle tebe rozdíl mezi monitorem a panelem?

Pokud tedy není žádná možnost jak ty informace zjistit, jak to tedy řeší G-sync? Ano, vyčítá to z EDID/E-EDID/DisplayID a driver s tím dál manipuluje, však si to přečti znova.

The ability for NVIDIA to pull of this feat of magic is built around the fact that while the monitor sends EDID information to the graphics card to request a specific set of timings, it is in fact, only a request. The graphics card has the ability to adjust these signals in any way it wants though in the past it has always followed the correct timings in order to guarantee compatibility and not damage system components.

Něco málo o FreeSync od Lukáše Fialy - Proč G-sync, když máme standardy? Otevřené řešení podpořil i Intel

Poškat počkat. Nefunguje Gsync náhodou komplet jinak? Grafika stále pracuje stejně, a právě proto má ten G-sync vlastní čip a vlastní buffer v monitoru protože ten to dává dohromady. K čemu by tam takovej kus HW byl kdyby to sama grafika posílal už upravené. Tam by pak stačilo upravit drobátko elektroniku monitoru aby přijímala refreshe mimo standardy a bylo by to, žádnej Gsync by nebyl třeba.


Tak jako tak ale když nad tom přemejšil, pro mě je nejdůležitejší aby nebyl inputlag. No lag bez tearingu by byl fajn, ale nebudu akceptovat "menší lag než vsync s tim že bez tearingu". To jest dost podstatné. Bez vsync jsou snímky z grafiky out hned ještě než jsou celý, proto tearing. Vsync bez tripple bufferu nutí grafiku čekat s tvorbou dalšího snímku než se ten předchozí dokončí a odešle při refreshi do monitoru celej, což snižuje výkon a dělá lag. S tripple bufferingem se výko nnesníží ale lag je dvojnásobnej, pro hraní useless.

Tady se teď bavíme o novém standardu který by umožnil monitorům zobrazovat snímky jak jdou z GPU, nemuselo by tedy GPU čekat na pravidelný refresh a odeslat to s ním, ne, odeslalo by se rovnou. Teroeticky pokud by to fungovalo ideálně by jsme tedy neměli mít ani zvedlej lag ani zhoršenej výkon. Plynulost by byla +- stejná. Jo v ideálním světě. Ale v praxi to výrobce grafiky může podělat ala udělá si na straně GPU buffer = lag. Výrobce displaye se s tim nemusí poprat ala vzpomeňte jak dlouho měla většina IPS panelů ohavné input-lagy.

Ještě jsem v ruce neměl Gsnyc monitor takže těžko budu porovnávat, a ani nebudu dokud to budou samé 6-bit TNka, sorry o to zájem nemam.

Radší bych to viděl jako součást DP standardu, už 10 let jsme za dobou CRT a stále tu pořád vládnou videosignály jako by byly pro CRT, ala udržovaly pevné refreshe, pevné kmitočty, atd. Takže s timhle pryč. A stardard lepší než uzavřené propritalní Gsync s kusem HW v monitoru.

Dále je tu ale konkurence která by to mohla zamést, třeba Eizo s tim 240hz PVA monitorem. Resp on má input 120, ale digitálně dopočítává na 240 a ten dopočítávání mu zvedá inputlag jen z 8 na zhruba 12 ms. TV tahle funkce trvá třeba 100+ ms, ale Eizo tu elektroniku vymyslelo dost rychlou. Heh, podá Gsync plynulejší obraz než toto? Asi ne.

webwalker píše:

ifkopifko píše:Keby si radšej napísal niečo konkrétne, ale to by od teba človek chcel priveľa. Bobáčik môj, ťo čo si tam vyššie popísal je presne stabilný refresh, nie variable. g-sync nepochybne môže mať spodný limit kdekoľvek nastavia že sa vykoná self refresh, nie len práve na 30fps (33,33ms). Kľudne 29 či 32fps, či akúkoľvek inú hodnotu, ktorú by panel zvládal. Zvolili 30fps, ale ty tu musíš fabulovať nezmysly, a ešte tu robiť chytráka.

Jak jsem řekl, nevíš o čem jsme tu mluvili a to je tvůj problém, navíc mícháš dvě věci dohromady. Self-refresh nemá s dynamickým sync nic společného, pouze jeho časování má vliv na jeho účinnost a to jsou dvě různé věci ifchytráčku

tak koukám, že už jsi také Ivánkův "bobáčik"

DOC_ZENITH píše:Poškat počkat. Nefunguje Gsync náhodou komplet jinak? Grafika stále pracuje stejně, a právě proto má ten G-sync vlastní čip a vlastní buffer v monitoru protože ten to dává dohromady. K čemu by tam takovej kus HW byl kdyby to sama grafika posílal už upravené. Tam by pak stačilo upravit drobátko elektroniku monitoru aby přijímala refreshe mimo standardy a bylo by to, žádnej Gsync by nebyl třeba.

Ne, komplet jinak nefungují, právě naopak.

Obě technologie jsou, co se týče základního principu funkce, stejné. Obě manipulují s hodnotou VBLANK (viz. citace), obě vyžadují DP, ale každá k tomu přistupuje jinak, jak v práci s bufferem (G-sync v modulu díky 768MB RAM, FreeSync používá vlastní buffer na kartě), tak s časováním snímků (tady má G-sync díky modulu výhodu, protože může intervaly střídat takřka přesně, u FreeSync je driver víceméně "odhaduje").

G-Sync

PCPER píše:G-Sync essentially functions by altering and controlling the vBlank signal sent to the monitor. In a normal configuration, vBlank is a combination of the combination of the vertical front and back porch and the necessary sync time. That timing is set a fixed stepping that determines the effective refresh rate of the monitor; 60 Hz, 120 Hz, etc. What NVIDIA will now do in the driver and firmware is lengthen or shorten the vBlank signal as desired and will send it when one of two criteria is met.

• A new frame has completed rendering and has been copied to the front buffer. Sending vBlank at this time will tell the screen grab data from the card and display it immediately.
• A substantial amount of time has passed and the currently displayed image needs to be refreshed to avoid brightness variation.

In current display timing setups, the submission of the vBlank signal has been completely independent from the rendering pipeline. The result was varying frame latency and either horizontal tearing or fixed refresh frame rates. With NVIDIA G-Sync creating an intelligent connection between rendering and frame updating, the display of PC games is fundamentally changed.

AnandTech píše:G-Sync works by manipulating the display’s VBLANK (vertical blanking interval). VBLANK is the period of time between the display rasterizing the last line of the current frame and drawing the first line of the next frame. It’s called an interval because during this period of time no screen updates happen, the display remains static displaying the current frame before drawing the next one. VBLANK is a remnant of the CRT days where it was necessary to give the CRTs time to begin scanning at the top of the display once again. The interval remains today in LCD flat panels, although it’s technically unnecessary. The G-Sync module inside the display modifies VBLANK to cause the display to hold the present frame until the GPU is ready to deliver a new one.

With a G-Sync enabled display, when the monitor is done drawing the current frame it waits until the GPU has another one ready for display before starting the next draw process. The delay is controlled purely by playing with the VBLANK interval.

"FreeSync"

AnandTech píše: According to AMD, there’s been a push to bring variable refresh rate display panels to mobile for a while now in hopes of reducing power consumption (refreshing a display before new content is available wastes power, sort of the same reason we have panel self refresh displays). There’s apparently already a VESA standard for controlling VBLANK intervals. The GPU’s display engine needs to support it, as do the panel and display hardware itself. If all of the components support this spec however, then you can get what appears to be the equivalent of G-Sync without any extra hardware.

In the case of the Toshiba Satellite Click, the panel already supports variable VBLANK. AMD’s display engines have supported variable VBLANK for a couple of generations, and that extends all the way down to APUs. The Satellite Click in question uses AMD’s low cost Kabini APU, which already has the requisite hardware to support variable VBLANK and thus variable display refresh rates (Kaveri as well as AMD's latest GPUs should support it as well). AMD simply needed driver support for controlling VBLANK timing, which is present in the latest Catalyst drivers. AMD hasn’t yet exposed any of the controls to end users, but all of the pieces in this demo are ready and already available.

PCPER píše:a controller for the screen that understands the variable refresh rate methods of eDP 1.0 specifications and an updated AMD driver to properly send it the signals. The panel can communicate that it supports this variable refresh technology to the graphics card through the EDID as resolutions and timings are communicated today and then the graphics driver would know to send the varying vblank signals to adjust panel refresh times on the fly.

Těch článků je tu linkovaných dost, stačí si je projít

webwalker, del42sa a ifkopifko si dají oraz, tohle navážení se do sebe nemáte zapotřebí akorát plevelíte vlákno

Fajn fajn ale stále nevím co tam má co dělat buffer. Ať už tam nebo tam. K čemu buffer, jakmile monitor akceptuje variabilní framerate tak buffer by byl potřebnej leda k tomu aby se do něj uložil statickej obraz pro dobu kdy framerate je nišší než minimání podporovanej monitorem.

Jinak totiž furt nechápu jak co jiného bufferovat. Karta dokončí snímek a nic bufferovat nebude. Odešle to hned rovnou z framebufferu do monitoru protože ten podporuje variabilní obnovovačku. To nám pomůže s plynulostí na menších FPS.

Problém ale vidim ve chvíli kdy grafika generuje rychlejc než dokáže monitor pojmout. Pak se buďto pokud monitor neni ready zahodí, a nebo zde bude buffer co jej pozdrží na další možnej refresh monitoru, zatímco grafika bude pracovat na dalším, což je defakto princip tripple-bufferingu a to je neakceptovatelné protože to přidělává input-lag.

Vzhledem k tomu že jsem hater input-lagu tak ideální by pro mě bylo aby monitor měl input aspoň 120hz, do těch 120 by jsme měli variabilní framerate do monitoru a nad by byl stav defakto jak vsync-off a 120hz. Prostě aby se nám nikdy nikde negeneroval lag. Obě 2 slibovaná řešení zatim dle mého názoru musí generovat lag, uvidíme v praxi.

webwalker píše:Jak jsem řekl, nevíš o čem jsme tu mluvili a to je tvůj problém, navíc mícháš dvě věci dohromady. Self-refresh nemá s dynamickým sync nic společného, pouze jeho časování má vliv na jeho účinnost a to jsou dvě různé věci ifchytráčku ...

Ale viem o čom je tu reč, o to sa ty neboj. A máš to celé popletené. Na vysvetlenie, že ak je dostatočný výkon GK je výstup g-sync a v-sync rovnaký sa ťa tu nik nepýtal, ale áno, je to určite jednoduchšie, ako si priznať, že si tam napísal riadnu kravinu.
Bavíme sa tu o opačnom konci intervalu fungovania variabilnej synchronizácie, o čase, kedy dojde k self refresh (refresh z pamäte g-sync modulu). A nie, nie sú tam na výber len diskrétne hodnoty tvojich magických 16,67ms. Ostatne, mohol si si všimnúť, že ten jediný monitor s g-sync je 144Hz, takže ti to mohlo dopnúť. Takže podľa toho tvojho nezmyslu by mal mať spodnú hranicu 72, 48, 36, 28.8, 24, 20.6, atď... ale je tam 30fps... divné veru, však? Mohol tam byť skrátka nastavený ľubovoľný čas a v Nvidii sa rozhodli pre 33,33ms (30fps). Nechápem ako si dospel k tomu nezmyslu čo tu stále omieľaš, ale fajn...

Krteq píše:Pokud tedy není žádná možnost jak ty informace zjistit, jak to tedy řeší G-sync? Ano, vyčítá to z EDID/E-EDID/DisplayID a driver s tím dál manipuluje, však si to přečti znova.

The ability for NVIDIA to pull of this feat of magic is built around the fact that while the monitor sends EDID information to the graphics card to request a specific set of timings, it is in fact, only a request. The graphics card has the ability to adjust these signals in any way it wants though in the past it has always followed the correct timings in order to guarantee compatibility and not damage system components.

Sorry, ale myslím, že si si zle vysvetľuješ ten anglický text, ten v žiadnom prípade nepodporuje to, čo tvrdíš. V prípade g-sync nie je nič také potrebné, lebo podporu má len zopár monitorov (momentálne len ten Asus) a tam si to výrobca ustriehne tak, aby bol g-sync modul nastavený správe (resp. aby bol panel spôsobilý ísť až na 30Hz). V prípade freesyncu by to určite bolo možné uložiť do EDID, ale otázka je, či to tam výrobcovia monitorov aj budú dávať ak to bude nepovinné, a čo bude v prípade, že to tam uložené nebude.

EDIT pre DOCa:

DOC_ZENITH píše:Dále je tu ale konkurence která by to mohla zamést, třeba Eizo s tim 240hz PVA monitorem. Resp on má input 120, ale digitálně dopočítává na 240 a ten dopočítávání mu zvedá inputlag jen z 8 na zhruba 12 ms. TV tahle funkce trvá třeba 100+ ms, ale Eizo tu elektroniku vymyslelo dost rychlou. Heh, podá Gsync plynulejší obraz než toto? Asi ne.

Prepáč, zas máš pocit, že vieš o čom píšeš, ale v skutočnosti porovnávaš neporovnateľné.
Tak za prvé, to Eizo nič nedopočítava, snímky len zdvojuje (ale popravde som nepochopil načo vlastne, lebo každý druhý frame pri Turbo režime je čisto čierny) a vzhľadom na výstup na osciloskope v recenzii na EHW by som to 240Hz nenazýval. Pripadá mi to skôr ako 120Hz. Dopočítavanie snímkov u TV je proti tomu niečo úplne iného, osobne si myslím, že dnešné TV používajú na dopočítanie medzisnímku/medzisnímkov viac než len jeden predchádzajúci a jeden nasledujúci frame, kľude 2-3 dopredu a 2-3 dozadu. Z toho pramení ten veľký lag, nie zo samotných výpočtov. V Eizo nie sú kúzelníci.
Za druhé, čítal som, že nevyrovnanosť frametimes je pri tom "Turbo" režime oveľa viac rušivá ako pri normálnom LCD, takže niekedy je lepšie to nechať vypnuté ak má hra takéto problémy. Teraz si nespomínam, či to písal nejaký recenzent, alebo majiteľ.
Ideálny monitor je podľa mňa taký, ktorý zvláda všetky módy. "Turbo", variabilnú synchronizáciu, aj high refresh rate. Pre každú hru je totiž lepšie niečo iné. Toto všetko by vlastne mal ten Asus spĺňať, akurát že je to TN...

Krteq píše:

hnizdo píše:To jsou informace o monitoru, nikoliv panelu. Minimalni refresh panelu je dosud ciste zalezitosti firmware a nikdo to dosud nepotreboval. Takze ne, GPU/OS zadnym zpusobem nemuze zjistit minimalni refresh rate pouziteho panelu.

To co jsi napsal snad nemyslíš vážně, že ne Kde myslíš, že jsou EDID informace uloženy? Jaký je podle tebe rozdíl mezi monitorem a panelem?

Velmi zasadni, vidim ze naprosto ignorujes stejne specifikace kterymi se ohanis, aby ti to pekne vyslo Chipset panelu dava gpu/systemu pres edid standardni set rozliseni a freknvenci, tkere umi zobrazit. To je set ktery umi zpracovat elektronika monitoru a zobrazit je na panelu. Minimalni refresh samotneho panelu s tim nema co delat, to byla dosud zalezitost chipsetu a firmwaru, tento parametr dosud k nicemu nebyl. Kolik monitoru umi refresh 15, 20, 40hz?
Takze po ste znova: monitor nema jak predat informaci o minimalnim refreshi pouziteho panelu. Nikdy to nedelal, nikdy to po nem nikdo nechtel.

Krteq píše: Pokud tedy není žádná možnost jak ty informace zjistit, jak to tedy řeší G-sync? Ano, vyčítá to z EDID/E-EDID/DisplayID a driver s tím dál manipuluje, však si to přečti znova.

Opet umyslne prekrucujes fakta. gsync modul v zadnem pripade nepracuje s edid daty. Proc by to delal, kdyz neni pripojen pres DVI/DP/cokoliv? Ten je uvnitr pripojen k chipsetu primo, bud pres lvds nebo jine prumyslove rozhrani, kterym mezi sebou na boardu monitoru komunikuji dalsi asicy. Jinak by sel pripojit normalne pres kabel jako redukce, kdyby to nebylo treba. Takze on ty informace, pokud je vubec potrebuje (bude montovan jen do kompatibilnich monitoru), ziska treba pres servisni i2c nebo cokoliv dalsiho. Osobne si myslim, ze nvidi stanovila limit 30Hz tak, aby se u oslovenych vendoru vesla do jejich hw portfolia, a nic se zjistovat nebude. Zatimco obecny standard (pokud bude) tenhle problem proste resit musi a je videt z toho ze neexistuje zadny prototyp, ze to nebude jen o tom pridat cteni vvsync headeru na linku DP.
Edit: aha, on to uz napsal ifko

@ifkopifko, hnizdo: Myslím, že máte od vánoc v hlavě trochu vymeteno. EDID sem do vlákna zatáhnul hnízdo, i když to všichni uváděli, že na použití synchronizace nic z toho třeba není, ba dokonce tvrdil, že si ho u f-sync gpu přečíst neumí. Když se Krteq nechal zatáhnout do debaty, aby ukázal, že si EDID umí přečíst každá karta, najednou se to obrátilo a tvrzení bylo vztaženo na modul g-sync s tím závěrem "Osobne si myslim, ze nvidi stanovila limit 30Hz tak, aby se u oslovenych vendoru vesla do jejich hw portfolia, a nic se zjistovat nebude". Panové, to bylo mistrovké. Mimochodem, znáte nějaký monitor, co neumí 30Hz??. Stejně jako ifkopifkovi informace o tom, že existuje pouze jeden monitor s g-sync

Jste-li takoví kabrňáci (jako v tomto případě), tak proč alespoň neodpovíte Docentovi na co se ptal. Tedy proč vlastně potřebuje g-sync modul buffer, kterým provádí self refresh a nevezme si frame přímo framebufferu gpu?? Tak co hoši, který z vás dvou se toho ujme?

webwalker>
1. Vidím, že ten svoj blábol radšej nijako nekomentuješ, aké prekvapivé.

2. Krteq sa tu s hnizdom bavil o tom, ako GK (alebo proste dané riešenie) zistí minimálny refresh rate panelu osadenom v monitore. Napísal jasne, že Nvidia g-sync to zisťuje z EDID, len si to prečítaj. Dal k tomu citáciu z jedného článku, ale tá citácia nič také netvrdí. Toť vše. Zvyšok k tomu už napísaný bol, že si to ty nepochopil je vec druhá.

3. Ad buffer na g-sync. Prečo mu vlastne nodpovieš sám, keď si taký king? To by snáď mala zodpovedať Nvidia, nemyslíš? Ja (narozdiel od teba) sa tu nehrám na jasnovidca aby som si cucal z prstu teórie. Jedno z použití už predsa DOC sám uviedol (sefl refresh). Myslím, že a mýli v tom čo sa deje ak je karta schopná generovať viac fps než monitor dokáže zobraziť. Je tam podľa mňa obmedzenie rovnaké ako u v-sync. Karta začne ďalší snímok až keď ten predošlý odosiela. Nvidia tvrdí, že snímky idú hneď na monitor, nebufferujú sa medzitým v module. Či je to pravda samozrejme nevieme, ale aj ak by sa bufferovali, pridávalo by to len malý lag (závislý na tom, ako rýchlo to následne elektronika zobrazí na LCD), nie porovnateľný s normálnym tripplebufferom.

Čo sa týka toho nápadu, že self refresh by sa udial z bufferu grafickej karty, tak s ohľadom na informácie, že príliš dlhý interval medzi refreshmi (zmenami polarity) by mohol poškodiť LCD sa mi ten nápad nepáči. Čo ak sa niečo stane (chyba driveru, chyba win, chyba čohokoľvek) a GK ako zariadenie riadiace obnovovanie LCD proste obraz neobnoví po dlhšiu dobu? Radšej by som to nechal na dedikovanom zariadení v monitore. Iste, aj to sa môže pokaziť a pod., ale je to predsalen blbovzdornejšie. Obzvlášť, ak by sa pri f-sync nikde ten minimálny refresh nedal vyčítať, a dokonca by bol nastaviteľný užívateľom...

Ešte k mojej "informácii že existuje len jeden g-sync monitor": No tak nech sú dva, tri, či päť. Podstata bola niekde inde. Je ich pár a keď majú nálepku g-sync, tak zrejme budú schopné bežať až po tých 30Hz. Ak sa zavedie aj nejaká nálepka f-sync, ktorá toto bude zaručovať, budem len rád, ale to zas nutne skončí obmedzeným výberom a tiež asi aj vyššou cenou, takže to už nebude až také "free".

BTW: Tie pokusy o urážku sú, v kontexte s tým čo tu predvádzaš, pomerne úsmevné.

@ifkopifko:

1. Nekomentuji, po druhé už fakt ne, stejně bys jako vždy utekl k jinému tématu, takže to nemá cenu.
2. Pro osvěžení paměti vše začalo nějak takhle:

f-sync nenabidne stejnou funcionalitu jako gsync (nemuze resit propad fps pod minimalni panel refresh interval, protoze tato hodnota je pro kazdy panel jina)
Bohuzel toto minimum je pro kazdy panel jine a nelze ho zjistit servisnim kanalem..

Následně se rozpoutala mocná debata ohledně EDID (kde mimochodem ta minimalní refresh rate je), kterou hnízdo ukončil oním zmíněným prohlášením, po kterém jsme se zase vrátili na začátek, tedy k 30Hz

3. Stačilo říct nevím.
Mimochodem, když už jsi zmínil tu neporovnatelnost s triple bufferem, jak dlouho trvá elektronice vykreslit snímek na monitor, ať už to jde s framebufferu nebo z paměti modulu g-sync?

1. Prečítaj si svoje komentáre, nie som to ja kto utiekol k inej téme.
2. Je irelevantné ako to začalo, komentoval som presne to, čo som komentoval, nie ten začiatok. Nejaké limity v EDID sú, ale nemusia to byť tie, ktoré sú potrebné/vhodné pre f-sync. Ak sa výrobca nenamáhal dať monitoru podporu pre 24fps video playback (neviem či sa to robí aj inak ako praktickými 48Hz), tak tam kľudne nemusí byť byť hodnota pod 50Hz, a to by pre f-sync nevyzeralo veľmi dobre.
3. Veď som aj napísal že neviem (niekoľkokrát), ale to by si musel aj čítať.

Ad "Mimochodem": To mimochodom by si predsa mal vedieť ako správny "guru".

webwalker píše:Následně se rozpoutala mocná debata ohledně EDID (kde mimochodem ta minimalní refresh rate je)

Refresha rate a rozliseni monitoru. Nikoliv minimalni refresh rate panelu. To neni totez. Psal jsem to krtkovi, zopakuji to i tobe. Zda se ze v tom mas uz tezkej hokej, uz ani nedokazes mlzit nesouvisejicimi cintaty jako krtek

AMD podalo 25.11.2013 Specification Change Request na zakomponování podpory pro Dynamic Refresh Rates do stávající revize standardu DisplayPort 1.2a

Mimochodem, údaje o refresh rates jsou skutečně vyčítány z EDID

Summary
Extend the "MSA TIMING PARAMETER IGNORE" option to DisplayPort to enable source based control of the frame rate similar to embedded DisplayPort.

Intellectual property rights
N/A

Benefits as a result of changes
This enables the ability for external DisplayPort to take advantage of the option to ignore MSA timing parameter and have the sink slave to source timing to realize per frame dynamic refresh rate.

Assessment of the impact
The proposed change enable per frame dynamic refresh rate for single stream devices that expose dynamic refresh rate capability in EDID for DisplayPort interface. The source will be able to enable this with an SST interface or MST hub with physical ports. Logical MST port support of the feature is not included as part of this SCR. A generic framework to enable such feature for logical port is required that can accommodate other feature where stream related configuration is programmed in DPCD.

Analysis of the device software implication
SST device which support "MSA TIMING PARAMETER IGNORE" option will be able to expose the capability in EDID and DPCD to let source enable dynamic refresh rate.
Source driver would have to be updated to parse EDID and enable "MSA TIMING PARAMETER IGNORE" feature when source want the sink to be refreshed based on its update rate.

Analysis of the compliance test and interop implications
Currently this feature is tested as part of eDP CTS. New test would have to be added as part of DP LL CTS and EDID CTS.

AMD 'FreeSync': proposition pour le DP 1.2a