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.
13.6 už vyšla?
Tady někdo asi neví, jak to je nově s Catalysty ?! Catalyst 13.6 Beta jsou už od května a 13.6 Beta2 od června a dále byly dostupné i Catalysty V2-13.15.100.1. Teď tedy vyšly Catalyst 13.8 Beta. Poslední Catalysty WHQL byly myslím 13.4. Od té doby jen zatím beta.
Ještě bych dodal že Frame Pacing zatím nepodporuje eyefinity.
Jo, taky se jsem o tom cetl (samozrejme jinde...), je docela legracni, ze je to primarne urceno pro sestavy, kde se tak nejak s behem na vice monitorech pocita. :-)
Veselé :-) A tady to píšou sice bez klíčového slova, ale taky - "Podporované jsou DirectX 10 a 11 aplikace a rozlišení až po 2560×1600.".
Funny je, že sama AMD prohlásila, že preferovala latence oproti plynulosti u AFR. Sám vím, že třeba GTX690 má lag díky framerate-meteringu kterej je cejtit, takže to dobrá herní karta rozhodně neni.
Přestože se o tom AMd zmínila, že dá lidem na výběr mezi lepšim frame-pacingem nebo latencema, ani jedna z danejch stránek neotestovala ten vlivl na inputlag? Tak co sakra recenzujou. Když někomu nevadí inputlag mohl si zapnout vsync už teď.
Vim že se to obtížně testuje, ale měli se aspoň pokusit, takle opět nevíme jestli je to opravdu použitelné řešení pro hraní her, a nebo spíš ne jako AFR bylo doteď.
Prakticky měřili zda jsou snímky vykreslovány stejnou dobu - čím větší rozdíly mezi vykreslenými snímky jsou, tím větší je pravděpodobnost, že je mezi snímky snímek neúplný (tzn. je přítomný tearing)
A jestli cítíš inputlag na 690 tak je velmi pravděpodobné, že bude na AMD kartách dvojnásobný (resp. framy dvojnásobně "roztrhané") ;) U nV se dá inputlag částečně kompenzovat počtem předrenderovaných snímků nicméně u nižších fps při AFR je tohle zatím neřešitelné (pokud vůbec někdy bude)
Mrkni třeba na AnandTech http://www.anandtech.com/show/7195/amd-frame-pacing-explorer-cat138
U 60Hz monitoru a framerate nad 60 fps je vždy výsledný snímek na monitoru složen ze dvou či více frames - tearing. Pokud by v tomto případě byly latence jednotlivých snímků naprosto stejné, tearing se bude vizuálně projevovat dokonce ještě výrazněji, než-li u gpu, která nebude generovat tak dokonale stejné latence.
Jinak inputlag není o "roztrhaných" snímcích, ale o době od uživatelského vstupu po vykreslení na monitor. Zmenšování command queue se tuším u multi-gpu nedoporučuje.
Mě se to třeba osvědčilo u SHIFTU na klávesnici, u joypadu nemělo vliv (Rumblepad), VSync zapnutý. SHIFT2 pro změnu AFR nefungovalo vůbec (údajně ale fungovalo při přejmenování shift2.exe na afr-friendlyd3d.exe a nehrabat se v global profilu) :)
A ještě jeden postřeh - při nastavení obnovovací frekvence na 60.001Hz (tzn. vlastní rozlišení) se SHIFT ovládal mnohem lépe, to samé třeba u Rage. Typicky to pomohlo u her, které místo 60Hz nastavovaly 59Hz nebo pokud se nehraje v nativním rozlišení
Mícháš jablka a hrušky. Inputlag je časový rozdíl mezi skutečným časem scény a jeho zobrazením. Takže je to přesně naopak než píšeš. U Nvidie byl až dosud vyšší kvůli tomu, že snímky kvůli synchronizaci nezobrazovala hned, ale snímky "čekaly", aby byly sesynchronizované, čímž rostl inputlag. U AMD je nic nezdržovalo a byly zobrazené ihned po vykreslení (resp. s použitím klasického double-bufferingu).
Celá situace kolem měření microstutteringu je ale irelevantní, protože žádná z metod používaných k měření nedokáže změřit to zásadní. Fraps měří rozestupy softwarových příkazů, systém Nvidie rozestupy výstupních snímků, ale ani jeden systém neřeší to klíčové a to, zda časovým intervalům, ve kterých karta "plive" snímky, odpovídá i obsah těchto snímků.
Ne tak docela. On je inputlag jak ten se vstupním zařízením tak ten "zobrazovací" (typicky se tím udával údaj za jak dlouho zpracuje monitor obraz a následně ho vykreslí). Faktem je, že ten se vstupním zařízením je v případě měření benchmarky pasé protože ani jeden z benchmarků nemá nic společného s mačkáním klávesnice a jedou jako timedemo.
FRAPS imho irelevantní je, ale FCAT je už hodně blízko ke kýženým číslům (navíc DataPath karta je opravdu špičková, nad ní už jsou pouze AJA). Navíc silně pochybuju, že by byly benchmarky a hry programovány tak aby vykreslovaly neúplné snímky (v rámci jednoho snímku).
Složený obraz z více snímků ti vzniká až při skenování a kopírování framebufferu na monitor. Jinak pokusy s měřením input lagu pomocí vysokorychlostní kamery tu už byly kdysi také (nechce se mi to teď hledat).
Jasně, pak to jde ještě přes DAC > monitor/FCAT (ten má vlastní double-framebuffer).
Na YouTube ty videa s inputlagem jsou takže kdo chce ať hledá tam ;)
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.