Er der nogen grund til at begrænse min FPS?

Capping dit framerate kan have et par fordele:

• Nedsat energiforbrug
• Nedsat varmeproduktion
• Nedsat støj (køleventilatorer kører langsommere)

Dækning af din framerate er især gavnlig for bærbare computere eller enhver anden form for mobile computere, da det giver en glimrende måde at forhindre en bærbar computer i at spise batteriet i live og også at brænde et hul i skridtet.

Husk, at capping your framerate is not the same as using v-sync .

Brug af en framerate cap giver ikke en reduktion i skærmbilledet Framerate-hætter begrænser simpelthen et antal rammer, som dit grafikkort kan producere. De tvinger ikke videokortet til at vente, indtil skærmen er begyndt på en ny opdateringscyklus.

Hvis det rammerate, du producerer, er omkring 55-75 fps, så vil du måske sætte den på 50 eller 60 som t han spikes, hvor det er 75, vil føle, at dit spil bremser, når det går tilbage til 55, dette er kun et eksempel, og dine faktiske billeder pr. sekund kan variere.

Brug af v-sync formidler alle de fordele, der er anført om rammehætter ovenfor, med den ekstra fordel at eliminere rivning af skærmen dog har den ulempen at tilføje noget ventetid.

Resume

At generere flere rammer, end din skærm kan vise, er spild af energi; rivning af rammer kan kun elimineres ved videosynkronisering, men det kan minimeres ved at dække FPS ved skærmfrekvensen. Input-latency er dog en relateret overvejelse.

Detalje

Tegning på min erfaring med at skrive GUI-systemer ser det ud til, at følgende skal være sandt.

Givet to kvantiserede systemer, (a) billedgenerering, og (b) billedgengivelse, skal enhver forskel mellem hastighederne lejlighedsvis resultere i rivning, hvis de ikke gensidigt er udelukket fra at forekomme samtidigt (ved at synkronisere GPU og monitor), og enhver FPS, der overstiger de fysiske grænser for monitoren, spildes. Ideelt set ville en nøjagtig matchning i hastighed, forskudt med halvdelen af intervallet, minimere eller eliminere rivning og ikke spilde nogen beregning.

Dette visualiseres let som følger, forudsat 62,5 Hz monitor og hele millisekunder for enkelhedens skyld:

Time (16"ms) : 0---------------1---------------2---------------3 Monitor Frames: x---------------x---------------x---------------x GPU @ 62.5 FPS: x---------------x---------------x---------------x GPU @ 62.5 FPS: --------x---------------x---------------x-------- GPU @ 125 FPS : x-------x-------x-------x-------x-------x-------x GPU @ 125 FPS : ----x-------x-------x-------x-------x-------x---- GPU @ 90 FPS : x----------x----------x----------x-----------x--- GPU @ 90 FPS : ------x----------x----------x-----------x-------- Monitor Frames: x---------------x---------------x---------------x Time (16"ms) : 0---------------1---------------2---------------3 

Som det kan ses, er monitoren 62,5 Hz, så er den optimale billedhastighed 62,5 FPS; ved 90 FPS (som faktisk er en ramme hver 11,11 “ms) har vi en uoverensstemmelse, der vil medføre en mistet ramme omkring hvert tredje interval. Ved 125 FPS har vi en ramme mistet hvert interval. Hvis du aldrig så det, var rammen nødvendig ?

I betragtning af en billedhastighedsbegrænsning på den fysiske enhed kan der således ikke opfattes nogen hastighed, der er større end skærmens kapacitet, da yderligere rammer simpelthen aldrig ses. Derefter ser det ud til at være logisk at dække FPS på skærmen opdateringshastighed resulterer i den maksimale opfattelige bevægelseskvalitet. Derfor synes det logisk, at generering af rammer ud over skærmens opdateringshastighed simpelthen spilder elektricitet.

I betragtning af at du ikke kan forhindre rivning uanset hvad du laver uden synkronisering af skærmen, er det stadig meget bedre at begrænse billedhastigheden og lægge den computerkraft i at generere flere detaljer pr. ramme, og når det maksimale er nået, skal du bare spare energi og reducere spildvarmen. p>

Mine to cent.

Visual Acu ity

At spille i dette også, selvom du har en 144 Hz skærm, er det, du faktisk kan opfatte. De fleste data indikerer, at FPS kun betyder noget op til ca. 60 til 120 Hz, med konklusioner, at 90 Hz (FPS) for de fleste mennesker er afskåret for visuelt mærkbar forbedring. Men hvert individ er unikt, og regelmæssige spillere er blandt de mest følsomme over for bevægelsesgenstande, fordi dit visuelle system kan trænes.

En flot artikel om emnet er http://www.pcgamer.com/how-many-frames-per-second-can-the-human-eye-really-see/

Inputforsinkelse

(Tak til Atli til denne kommentar.)

Med alt det sagt er det værd at påpege her, at tilslutning af FPS til skærmopdateringen kan skabe mærkbar indgangsforsinkelse under spil. IE: med 16ms rammeopdatering, hvis rammen gengives i 1 ms straks efter opdateringen, den bliver nødt til at sidde der i 15 ms og vente, hvilket effektivt skaber en forsinkelse på 15 ms mellem bevægelse og visning af den bevægelse.

Spil er også tilbøjelige til at begrænse deres AI / logiske cyklusser til gengivelse af cykler, hvilket også skaber forsinkelse der. Gengivelse ved 3x skærmopdatering vil gøre dette meget mindre synligt, da rammen, der vises, bliver tættere på visningstiden.

For en sådan brugssag, capping på et passende multiplum af skærmopdateringen rate kan stadig være umagen værd med en moderne GPU, samtidig med at latensen holdes under en ønsket tærskel.

Kommentarer

• Det kan være værd at tilføje en tl; dr eller et resumé, da dette er et ret teknisk svar, men +1 for det detaljerede svar
• Det ‘ er værd at påpege her, at capping FPS til skærmopdateringen kan (og skaber normalt) mærkbar inputlatens. IE: med din 16ms rammeopdatering, hvis rammen gengives i 1ms umiddelbart efter opdateringen, skal den ‘ sidde der i 15ms og vente, hvilket effektivt skaber et 15ms forsinkelse mellem bevægelse og visning af denne bevægelse. Spil er også tilbøjelige til at begrænse deres AI / logiske cyklusser til at gengive cyklusser, hvilket også skaber forsinkelse der. Gengivelse med 3x skærmopdatering vil gøre dette meget mindre synligt, da den viste ramme bliver tættere på visningstiden.