FreeSync rykker stadig nærmere skrivebordet ditt

[Kirchhoff]

 

Feil, input-lag til en skjerm er målbart og er jevn for hver innstilling, panelet er tross alt synkronsiert med dette.

 

Å måle forsinkelse fra mus til piksel på skjerm gir ingen mening, for det er ikke sammenlignbart og heller ikke målbart for den del, siden det varierer fra det ene øyeblikket til det andre.

 

Musa sin forsinkelse er jevn for hver innstilling, buffering og vsync er jevnt gitt en viss ytelse, OS-overhead er neglisjerbart for ikke-jevnt bidrag. Det virker som du mener det er meningsløst å måle forsinkelse på noe annet enn skjerm, det er bare tull.

 

AtW

 

Statistikk er også et stikkord her.

[efikkan]

Musa sin forsinkelse er jevn for hver innstilling, buffering og vsync er jevnt gitt en viss ytelse, OS-overhead er neglisjerbart for ikke-jevnt bidrag. Det virker som du mener det er meningsløst å måle forsinkelse på noe annet enn skjerm, det er bare tull.

Er det én ting du elsker så er det å legge ord i andres munn for å stille andre i dårlig lys.

 

Du skal vite at latency er faktisk noe jeg er veldig opptatt av, langt mer enn rå FPS. Dessverre er mange av kildene til latency vanskelig å forstå og forstå hva som kan gjøres med de.

 

Nå tar jeg med mye i detalj her som du kanskje kan fra før, men det er sikkert flere som har interesse av å lære litt

1) Input latency

PS/2 har 0.73 ms latency per event, standard USB 1.1 HID har ~10 ms per combo som blant annet skyldes handshake frem og tilbake(a la TCP), som gjør at flere raske trykk etter hverandre køes opp eller i verste fall forsvinner pga. begrensninger i kontrolleren. Til sammenligning sender PS/2 en pakke for hver event med CRC, hvis pakken mot formodning blir skadet på veien så ignoreres den, fremfor å sende pakker frem og tilbake. Handshakingen gir kanskje mening for noen typer kritiske bruksområder, men for spilling hadde det vært mye bedre uten. Standard HID har også begrensninger i tastekombinasjoner med det er en annen sak. Noen få dyre tastaturer bruker en modifisert HID over USB 2.0 som reduserer forsinkelsen ned mot rundt 1 ms, eller bruker egne protokoller. Begge deler har sine problemer på tvers av plattformer, men egne protokoller er verst pga. ekstra driveroverhead.

(Mitt forslag til løsning: revidere HID til å utnytte hastigheten til USB 3.1, kanskje vi kan nærme oss 0.1 ms??)

 

I tillegg til protokollbegrensningene er det gjerne utfordringer i tastaturkontrollere også. Prosesseringshastighet, minnemengde til kø og kretser til bryterne spiller inn. Generelt sett er dyre tastaturer ganske bra.

 

Totalt sett gjør dette at input latency kan variere svært mye fra oppsett til oppsett. Latency kan også variere under bruk, avhengig av tastemønster og ikke minst om det brukes trådløs overføring.

 

2) OS Overhead:

OS-overhead er ganske oversett av de fleste, meg inkludert frem til jeg begynte å se nærmere på det. Det har vært kjent i mange år at de som driver med lydproduksjon på Linux merker stor forskjell på standard-kjernen og low-latency-("semi-realtime") kjerne. Dette handler om forsinkelsen som det tar hver gang en prosess vil kommunisere med en annen prosess, thread, drivere eller kjernefunksjoner. Dette er en direkte konsekvens av hvordan scheduleren i kjernen opererer. Jeg forsket på dette i forberedente til min master, og fant ut at dette var en veldig merkbar kilde til microstuttering og at low-latency-kjernen gjorde at spillytelsen til skjermkortet føltes mye raskere pga. fravær av stuttering (dette var uten vsync selvsagt).

 

Jeg vil vise deg et par eksempler fra mine målinger:

(testet på GT 640, X4 940 3 GHz, 8GB RAM, Ubuntu 12.04 standard vs. low-latency. Hvis jeg husker riktig var lasten her et terreng på 2 mill polygon)

(testet på GTX 680, i7-3930K, 64 GB RAM. Med langt større terreng, annet stadie i prosjektet.)

Grafene viser frame latency, blå linje indikerer 60 FPS, rød 30 FPS. Det kan være litt vanskelig å lese fra grafene, men de vertikale strekene kommer fordi ett bilde blir forsinket så det kommer lenge etter det forrige, og deretter kommer påfølgende bilde svært tett på fordi GPUen jobber med jevn last. (bare spørr om du trenger utdyping på dette) Som du ser er gjennomsnittlig FPS helt fin og jevn. Mine observasjoner er at denne forsinkelsen kan være svært variabel, og kan raskt utgjøre 1-5 ms forsinkelse på et bilde eller mer, avhengig av hvor mye spillet må synkronisere.

 

Du tenker kanskje at fordelene med low-latency-kernel jeg snakker om over er god nok grunn til at aller operativsystemer burde brukt det som standard? Vel det har sine bieffekter også, det gir nemlig generelt noe høyere CPU-last som ikke er ideelt for laptoper. Så det jeg mener er løsningen er at operativsystemer i "performance mode" får en slik tweaking av scheduleren sin, noe hverken Linux eller Windows gjør i dag.

 

3) Spillmotoren:(eller simulator)

Så er vi kommet til det punktet hvor det er stort sett ikke en dritt vi som spillere kan gjøre, nemlig spillmotoren. Jeg går ut ifra at du har en grunnleggende forståelse av hvilken mekanismer en spillmotor består av, hvis ikke får du si ifra hvis du ønsker utdyping. Det er enorm variasjon fra spill til spill, og noen spill er flinkere til å utnytte multithreading enn andre så valg av CPU spiller faktisk også inn her.

 

Uavhengig av om spillet er bra kodet eller ikke har du uansett følgende type logikk:

(1)Ta imot liste av events -> (2)game loop(spillets logikk) -> (3)rendering

 

Så er det enklest å forklare forskjeller her med noen eksempler.

Jeg vil starte med et spill som jeg kjenner godt og jeg vet har gjort det på "gamlemåten": Euro Truck Simulator 2. Jeg tilbrakte ikke mange timene i spillet før jeg oppdaget at ekstra CPU-last (f.eks. lasting av nye deler av brettet) stoppet spill-logikken og events køet seg opp. På samme måte køet det seg også opp hvis renderingen plutselig ble tyngre, altså spillet gikk saktere hvis det ble for tungt. Dette forteller meg at rendering og game loop er avhengig av hverandre og er enten synkronisert eller i samme thread. Problemet med dette er at render-ytelse, events og annen CPU-last i spillet påvirker hverandre. Game-loopen har gjerne da en innebygd sleep-funksjon for å hindre at ting går for raskt.

 

Topp-spill i dag har tatt i bruk multithreading, og hovedformålet med dette er å separere annen last bort fra rendering slik at den får gå uforstyrret. Spill-logikk, fysikkberegninger, lyd og nettverk skjer da på en eller flere threads uavhengig av rendering. Men det varierer om spill faktisk synkroniserer threads eller bruker synkroniseringsfrie teknikker*(forklares under).

 

Du er forhåpentligvis inneforstått med at en game loop bør kjøres med konstant intervall for å sørge for jevn flyt i spill(altså flyt i bevegelser). Hvis du tenker deg om forstår du sikkert også at om en game loop kjører i 60 Hz, så har ikke en 120 Hz skjerm noen hensikt, for da vil den bare tegne to og to like bilder og vi er like langt. Så du er nok enig i meg om at en game loop bør kjøres så ofte som mulig, og minst like raskt som skjermen, og ideelt sett bør de være synkronisert slik at game loop blir ferdig akkurat i det skjermen skal starte neste bilde:

Så du ønsker da en game loop som starter "så sent som mulig" men akkurat blir ferdig til et konstant intervall. Den beste måten å få dette til på er å ha så rask iterering i en game loop som mulig, men innenfor det maskinene klarer uten forstyrrelser. F.eks. 120 Hz, 240 Hz eller mer. Men på et tidspunkt blir kollisjonsdeteksjon osv. for tungt. Du har sikkert forstått innen nå at hastigheten til game loop påvirker en totale forsinkelsen en god del, den blir et eget ledd på samme måte som Vsync.

 

I de simulatorene jeg har vært involvert i en game loop og rendering loop som opererer helt uavhengig av hverandre. Game loop operer med sin interne spilltilstand og produserer i hver iterasjon ferdige "snapshots" av alle elementers posisjoner og tilstander og legger dette i en kø. En del spillmotorer ville da prøvd å synkronisere f.eks. med en mutex(lås), men dette kaster bort dyrebar tid, og det er her synkroniseringsfrie algoritmer kommer inn. Ett alternativ er det vi kaller en låsfri kø. Denne fungerer ved at game loop produserer nye states, og render loop henter siste state hver gang den starter ny rendering. Hvor rask rendering er i forhold til game loop har da ingen betydning lenger, og du slipper å få det etterslepet av hendelser. Hvis renderingen plutselig går treger så hopper den elegant til siste state uansett. Da gjenstår det bare å få game loopen til å kjøre med den hastigheten du ønsker. Hvis f.eks. gameloop kjører i 240 Hz og rendering er i 120 Hz (uten vsync) blir forsinkelsen i dette leddet ~0-8.33 ms, mens spillet altså kan dra nytte av skjermer opptil 240 Hz og da få ~0-4.17 ms.

 

4) Buffering og VSync:

Jeg tror de fleste har fått med seg dette punktet.

Latency: ett bilde uten VSync, opptil to bilder med. Varierer med GPU-last.

 

5) Skjerminput:

Skjerminput:

LCD: ~5-35+ ms (kan være ~60 ms på enkelte TVer)

CRT: ~0 ms

 

I tillegg har vi driver-overhead som kan puttes inn som eget punkt. Dette er en konsekvens av både driveren og av spillmotoren.

 

Innen nå har du forhåpentligvis forstått at latency-problemet er langt mer enn input. Å kalle hele kjeden for "input lag" blir i beste fall upresist, og de som kjenner dette i detalj vil da bli forvirret med hva som menes med input. Det blir litt som å kalle forsinkelsen fra du bestiller en vare til du har den i hånden for en input lag, fremfor en levering.

 

Det er bemerkningsverdig at total forsinkelse er stort sett verre i dag enn for 10 år siden. Da tenker jeg spesielt på punkt 1) og 5). Punkt fire har for mange også blitt verre, men er på bedringens vei etter hvert som 120 Hz og mer blir utbredt.

[ATWindsor]

Effikan: du argumenterer for at det er forsinkelse i flere ledd, det er det ingen som har protestert på, og du kan si det er å legge ord i munnen på deg, men det er den naturlige konklusjonen når du framstiller det som alt annet en skjermforsinkelse er nærmest random. Noe det ikke er. Skjermforsinkelsen er et av mange ledd, med hver sin forsinkelse, som er relativt konsistent i et oppsett. Men det varier selvsagt fra oppsett til oppsett, også mellom skjermer.

 

Og når vi snakker om å legge ord i munnen på folk, dette har jeg forklart deg før, i denne samme tråden, man kan fint forstå hva de forskjellige delen av kjeden gjør, og kalle det input lag, jeg har tilogmed forklart deg hvorfor det er naturlig å bruke det på den måten, fordi det er input lag det faktisk er, forsinkelsen fra input til reaksjonen på den inputen vises for meg. De som kjenner dette i detalj burde ikke blir forvirret fordi begrepet jevnlig brukes sånn, og du burde ta innover deg at det brukes på flere måter, istedet for å framstille det som det ene er fasit og det andre er galt.

 

AtW

[efikkan]

Nå har jeg forsøkt å snakke deg til fornuft, men nok en gang fånyttes.

Hvis noen sender deg en SMS, gir det ingen mening å kalle tiden det tar fra den skrives til du ser den for en input-lag. Du kan derimot kalle det overføring, levering osv.

Hvis du har en DVD-plate med filer i PCen din, så dobbelklikker du på en fil for å spille av. Da kan du kalle forsinkelsen til programmet har reagert for input-lag, men ikke hele prosessen.

...

 

Du har en input-forsinkelse fra mus til PC, og fra skjermkort til skjermpanel, men det gir ingen mening å kalle alt i mellom det for input-forsinkelse.

[laban555]

Man lærer ingenting av artikkelen. Lærdommen må man finne i komentarfeltet. lol

[ATWindsor]

Nå har jeg forsøkt å snakke deg til fornuft, men nok en gang fånyttes.

Hvis noen sender deg en SMS, gir det ingen mening å kalle tiden det tar fra den skrives til du ser den for en input-lag. Du kan derimot kalle det overføring, levering osv.

Hvis du har en DVD-plate med filer i PCen din, så dobbelklikker du på en fil for å spille av. Da kan du kalle forsinkelsen til programmet har reagert for input-lag, men ikke hele prosessen.

...

 

Du har en input-forsinkelse fra mus til PC, og fra skjermkort til skjermpanel, men det gir ingen mening å kalle alt i mellom det for input-forsinkelse.

 

Jo, det gir masse mening, det er lag-time fra inpuetet sendes fra deg (feks museklikket), til man ser resultatet av inputet (som helst skule vært umiddelbar), lag fra input til hendelse, input-lag. Begrepet blir brukt også på denne måten, det er bare å innse.

 

AtW

[Olavxxx]

Kommentar til dere som diskuterer input lag:

Det er stort sett to måter å måle input lag, den ene er ved å bruke en fysisk input og en optisk sensor (Leo Bodnar metoden), denne gir høyere tall enn den "gamle" metoden å filme skjermen og sammenligne med en CRT-skjerm.

 

I praksis gir Leo Bodnar-metoden (fysisk knapp og optisk sensor) hele løypen. Begge deler kan måles, men man kan ikke sammenligne tallene fra de to forskjellige målingene. Den enklere målingen kan gjerne gi 16MS hvor Leo Bodnar metoden kanskje gir 30MS :-P (to tall jeg fant på som eksempel).

 

Se gjerne:

[efikkan]

Ja der har du faktisk input lag.

[ATWindsor]

Ja der har du faktisk input lag.

 

Ja, du mener tiden fra input fra måleren og til skjermbildet? Det er det jeg vil kalle input lag (på skjermen) ja.

 

AtW

[Theo343]

latency fra man trykker på musa til det skjer noe på skjermen ble vel kalt "input response lag"?

[Kirchhoff]

latency fra man trykker på musa til det skjer noe på skjermen ble vel kalt "input response lag"?

Ja det gjør det. Noen har bare litt vanskelig for å inrømme at de tar feil på internett.

[amiganostalgia]

Blir å trenge displayport 1.2a/1.3 iirc.

[efikkan]

Som Theo er inne på kan hele forsinkelsen beskrives som en respons, men hele forsinkelsen består ikke av input lag. For hvis alt dette hvor mye er output lag og urelatert prosessering så kan vi like gjerne kalle nedlasting av filer, chatting over nett og lasting av DVD-filmer som "input lag", og utallige andre eksempler, og da har vi effektivt likestilt "input lag" med "lag" og ignorert hva input og output er. Samme hvor mye det vendes og vris på blir ikke hele forsinkelsen "input lag", og det er et faktum.

[G]

 

Tear-free gaming uten ekstra forsinkelse er jo et av g-sync sine største salgsargumenter. ?

Input-lag er som flere av oss vet prosesseringsforsinkelse internt i skjermen. Som du er inne på, litt av hensikten med adaptiv synkronisering er borte om det kommer et ekstra ledd med forsinkelse i tillegg.

 

Freesync gjr akkurat det samme som G-sync, bare at Freesync er mye billigere, både å utvikle og i deler. og ja, det blir ikke noe input lag, eller hvis det blir det, veldig lite.

Fortell meg gode mann(?), hvorfor blir FreeSync billigere enn G-Sync? Det trengs nøyaktig samme maskinvare, og begge er implementasjoner av samme standard.

 

Freesync og AdaptiveSync er nesten akkurat det samme, det er fordi Adaptive Sync er på en måte ferdigversjonen av Freesync, og er den eneste som kommer på markedet. Freesync er bare AMD, Adaptive sync er når AMD gikk sammen med VESA for å faktisk lage en standard av det som funker med Displayport og derfor stand alone skjermer og ikke bare laptoper.

Feil. Adaptiv synkronisering har vært planalgt av DP 1.3 i lang tid. Nvidia ønsket å bringe det til markedet før uten å vente på den ferdige standarden. Deretter ville AMD også fremskynde teknologien (det kalles konkurranse, og det er en bra ting, så takken være Nvidia har AMD fått fart på baken!) og fikk VESA til å lage en modifisert 1.2-standard, som er akkurat det samme som Nvidia har gjort uten standarden.

 

 

nVidia skal ihvertfall ha kudos for å ha brakt søkelys på problemet, lenge før andre implementerte noen tilsvarende løsning

[Theo343]

Som Theo er inne på kan hele forsinkelsen beskrives som en respons, men hele forsinkelsen består ikke av input lag. For hvis alt dette hvor mye er output lag og urelatert prosessering så kan vi like gjerne kalle nedlasting av filer, chatting over nett og lasting av DVD-filmer som "input lag", og utallige andre eksempler, og da har vi effektivt likestilt "input lag" med "lag" og ignorert hva input og output er. Samme hvor mye det vendes og vris på blir ikke hele forsinkelsen "input lag", og det er et faktum.

I skjemaet du viste oss stod det "input response lag" på punktet ved mus, tastatur osv. Var der jeg fikk det fra.

[ATWindsor]

Som Theo er inne på kan hele forsinkelsen beskrives som en respons, men hele forsinkelsen består ikke av input lag. For hvis alt dette hvor mye er output lag og urelatert prosessering så kan vi like gjerne kalle nedlasting av filer, chatting over nett og lasting av DVD-filmer som "input lag", og utallige andre eksempler, og da har vi effektivt likestilt "input lag" med "lag" og ignorert hva input og output er. Samme hvor mye det vendes og vris på blir ikke hele forsinkelsen "input lag", og det er et faktum.

 

Det du kaller output lag er også med i din egen definisjon av input lag.

 

AtW

[efikkan]

Jeg har allerede påpekt ved flere andledninger dine logiske brister hvor "lag" og "input lag" er synonym, og at dermed alle typer forsinkelser kan da kalles "input" lag. Jeg kan ikke stoppe deg i å forsøke på en redefinisjon av input og output, men du lurer bare deg selv...

[ATWindsor]

Jeg har allerede påpekt ved flere andledninger dine logiske brister hvor "lag" og "input lag" er synonym, og at dermed alle typer forsinkelser kan da kalles "input" lag. Jeg kan ikke stoppe deg i å forsøke på en redefinisjon av input og output, men du lurer bare deg selv...

 

Det er bare du i dine overdrivelser som mener input lag skal gjelde for "alle typer forsinkelser". Og det er ingen redefinisjon som må til for at din definisjon av input lag også innheloder det du kaller output.

 

AtW