Bakit puwedeng pumalya ang kinis ng laro kahit mataas ang frame rate

Mahigit siyamnapung frame bawat segundo ang ipinapakita ng laro, pero sandali itong humihinto kapag lumilingon ka o pumapasok sa bagong lugar. Hindi nawalan ng saysay ang average FPS. Sinasagot nito ang pangkalahatang tanong: ilang frame ang nalikha sa loob ng panahong iyon? Kailangang tingnan ang oras ng bawat frame upang malaman kung pantay ang pagdating ng mga ito.

Magsimula sa frame time bago magpasya kung ano pa ang susukatin. Hindi masasabi ng iisang porsiyento ng bottleneck o isang pagbaba ng GPU utilization kung aling piyesa ang dapat palitan.

Maaaring maitago ng magandang average ang isang mabagal na frame

Kung ganap na pantay ang output, ang pagitan ng mga frame sa millisecond ay humigit-kumulang 1,000 ÷ FPS. Kaya ang 60 FPS ay mga 16.67 ms at ang 120 FPS ay mga 8.33 ms. Pagpapalit ito ng yunit ng oras, hindi benchmark ng isang computer.

Ipagpalagay na may 100 frame ang isang recording: 99 ang tig-10 ms at isa ang 100 ms. Ang kabuuang oras ay 99 × 10 + 100 = 1,090 ms. Kapag hinati ang bilang ng frame sa kabuuang tagal, lalabas ang humigit-kumulang 91.74 FPS. Maayos tingnan ang average, pero mas mahaba pa rin ang isang paghihintay.

Larawan: halimbawang kalkulasyon ng frame time at daloy ng pagsusuri, hindi screenshot ng benchmark ng laro.

Iba rin ang arithmetic mean ng instant FPS ng bawat frame sa kabuuang frame na hinati sa kabuuang tagal. Maaaring baguhin ng saklaw ng pagsukat, pagsama sa mga loading screen, at estadistikal na depinisyon ng tool ang huling bilang.

Kapaki-pakinabang ding tingnan kung gaano karaming oras ang sinasakop ng mababagal na frame. Sa isang ipinagpalagay na 60-segundong recording na may anim na 100 ms na frame, ang anim na iyon pa lang ay 0.6 segundo, o 1% ng buong pagitan. Halimbawang kalkulasyon pa rin ito, ngunit naipapakita nito ang mga bihirang paghintong maaaring hindi makita sa isang percentile.

Larawan: 100 halimbawang frame. Numero ng frame ang pahalang na axis, hindi pantay-pantay na oras. Ang frame 50 ay 100 ms; tig-10 ms ang natitirang 99.

Alamin muna kung anong uri ng frame ang naitala

Nakalista sa opisyal na pahina ng NVIDIA FrameView ang pagsukat ng frame rate, frame time, at power, kasama ang pag-save ng log.[1] Napapanatili ng mga log ang datos sa paligid ng isang pangyayari, pero hindi sapat ang recording tool lamang upang patunayang CPU bottleneck ito.

Bago maghambing ng mga ulat, suriin ang rendered at displayed frames, frame generation, V-sync, at FPS cap. Kapag pinagsama ang generated frames at orihinal na rendered frames, maaaring tumaas ang bilang nang hindi katumbas ang pagbuti ng tugon sa input. May mga problema rin sa display path na hindi sakop ng rendering log, kaya hindi naaalis ng maayos na log ang lahat ng nakikitang pag-utal.

Nakatutulong ang “1% low” sa pagsusuri ng mabagal na frame performance, pero maaaring magkaiba ang pagkalkula ng bawat software. Isama sa bilang ang pangalan at bersiyon ng tool, depinisyon ng sukatan, at tagal ng recording. Huwag ipagpalagay na ito ang nag-iisang pinakamabagal na frame o pagsamahin ang iba't ibang tool sa isang ranking.

Malinaw na ibinubukod ng CapFrameX ang percentile batay sa pagkakasunod ng mga frame sa aktuwal na tagal.[3] Hindi eksaktong katumbas ng “99% ng mga frame ay pasok sa threshold” ang “makinis ang 99% ng oras ng paglalaro,” dahil maaaring kumain ng malaking oras ang iilang mabagal na frame. Tinatalakay rin nito ang pagkakaiba ng percentile value at buod ng pinakamabagal na bahagi. Kung “1% low” lang ang label at walang paraan ng pagkalkula, panatilihin ang limitasyong iyon sa interpretasyon.

Aling mga field ng log ang dapat basahin nang magkasama?

Buksan ang CSV at tingnan muna ang mga header. Itinatakda ng console documentation ng PresentMon ang mga sumusunod na field; nakadepende sa bersiyon at capture options ang aktuwal na output.[2]

Magkakaibang pagitan ang inilalarawan ng mga field, at maaaring magsabay ang gawain ng CPU at GPU. Huwag basta idagdag ang mga column at asahang katumbas ang suma ng buong tagal ng frame. Hindi GPU-utilization percentage ng Task Manager ang MsGPUBusy. Basahin muna ang mga depinisyon bago magpasya kung maihahambing ang dalawang bilang.

Kung humahaba ang pagitan ng pagsusumite at kapansin-pansing tumataas ang aktibong oras ng GPU, dapat siyasatin ang graphics work. Kung maikli ang GPU work pero mahaba ang paghihintay, maaaring may kinalaman ang FPS cap, pagbibigay ng CPU ng trabaho, o scheduling. Nililimitahan nito ang paghahanap, ngunit hindi pinatutunayan na kulang ang CPU performance. Inilalarawan din ng proyekto ang mga limitasyon sa iba't ibang API at hardware scheduling. Huwag punan o baguhin ang mga field na wala o limitado ang pagsukat.[4]

Magtago ng ebidensiya gamit ang maikling rutang mauulit

Pumili ng rutang mauulit, at panatilihin ang resolution, graphics settings, galaw ng camera, at FPS cap. Itabi ang orihinal na settings, simulan ang pag-log, at panatilihin ang output pagkatapos. Lagyan ang mga file ng bersiyon ng laro, graphics driver, eksena, at settings upang maihambing sa susunod.

Sa bawat spike, itala kung nangyari ito sa unang pagpasok, biglang paglingon, pagsisimula ng background program, o sa bawat pagdaan sa parehong lugar. Sabay na tingnan ang available na sukatan ng CPU, GPU, memory, at storage. Huwag gawing zero ang sensor fields na hindi nakuhanan.

Ulitin muna nang tatlong beses at itabi ang bawat resulta. Kung malaki ang agwat, suriin ang eksena, temperatura, cache, at background tasks bago pahabain o dagdagan ang mga test. Kapag pinakamahusay na run lang ang itinabi, nawawala ang pagkakaibang kailangan mong ipaliwanag.

Panimulang template ang sumusunod. Halimbawa lamang ang 60 segundo at tatlong run; hindi garantisadong sapat ang mga ito para sa lahat ng laro.

Ihambing nang hiwalay ang cold start at mga eksenang napuntahan na. Dapat may sariling record ang pag-utal sa unang pag-load. Para sa tuloy-tuloy na graphics load, huwag paghaluin ang unang-load na datos sa isang grupo at warmed-up na datos sa kabila.

Sinusuportahan ng PresentMon ang pagpili ng proseso ayon sa pangalan, pagtatakda ng tagal ng capture, at pagpili ng CSV output file.[2] GUI man o command line, tiyakin ang target na proseso upang hindi maisama ang frames ng launcher sa laro. Walang aktuwal na game capture na isinagawa rito; nagpapaliwanag lamang ng mga sukatan ang mga larawan.

Isang kondisyon lang ang baguhin sa bawat test

Kung pinaghihinalaan ang graphics load, bawasan ang isang tiyak na rendering burden at ulitin ang ruta. Kung background interference naman, isara ang isang kilalang program at ulitin ang test. Huwag sabay-sabay baguhin ang driver, graphics quality, at FPS cap habang nire-restart ang laro, dahil hindi na malilinaw ang sanhi ng pagbuti.

Kung tumaas ang average FPS matapos ibaba ang quality pero nanatili ang spike sa parehong lugar, maaaring magkahiwalay na problema ang karaniwang rendering load at ang paghintong iyon. Ang pag-utal na malakas sa unang pasada pero humuhupa sa susunod ay maaaring may kaugnayan sa asset loading o cache, ngunit hindi sapat ang pattern na iyon upang tukuyin ang sanhi. Ang mababang GPU utilization ay maaaring dahil sa cap, paghihintay sa CPU, o ibang limitasyon; hindi nito direktang ibig sabihing kulang ang lakas ng graphics card.

Itabi ang konklusyong may malinaw na kondisyon, gaya ng “may spike sa pagpasok sa lugar sa lahat ng tatlong run, at hindi ito nawala nang ibaba ang shadows,” sa halip na “may 30% bottleneck ang PC.” Sa susunod na test, masisiyasat ang lugar ng spike at pagbabago sa shadows nang hindi muling nagsisimula sa hula.

Mga sanggunian

1. Opisyal na pahina ng NVIDIA FrameView. Batayan ng frame-rate, frame-time, at logging capabilities. Hindi patunay na may isinagawang test, pare-pareho ang power fields sa lahat ng GPU, o naka-install ang software.

2. PresentMon Console Application documentation. Bersiyon ng main branch na binasa noong 2026-09-27. Tinutukoy ang CSV fields, target process, at capture duration. Nag-iiba ang fields ayon sa bersiyon; hindi nito ipinahihiwatig na may lokal na capture.

3. CapFrameX: Explanation of different performance metrics. Taxxor, 2020-05-31. Nagpapaliwanag ng percentiles at x% low. Ginamit para sa konsepto ng sukatan, hindi bilang screenshot ng kasalukuyang interface.

4. Dokumentasyon at limitasyon ng PresentMon. Sinuri noong 2026-09-27. Maaaring makaapekto sa pagsukat ang API at hardware scheduling; itala ang kapaligiran sa halip na agad maghinuha ng bottleneck.