Mengapa permainan masih boleh tersangkut walaupun kadar bingkai tinggi

Permainan menunjukkan lebih sembilan puluh bingkai sesaat, tetapi terhenti seketika apabila anda memusingkan pandangan atau memasuki kawasan baharu. Purata FPS masih berguna; ia menjawab soalan umum: berapa banyak bingkai dihasilkan sepanjang tempoh itu? Untuk mengetahui sama ada bingkai tiba secara sekata, anda perlu melihat masanya.

Mulakan dengan masa bingkai, kemudian tentukan perkara yang perlu diukur seterusnya. Satu peratusan kesesakan atau satu penurunan penggunaan GPU tidak dapat menentukan komponen yang patut diganti.

Bingkai yang lama boleh tersembunyi di sebalik purata yang baik

Dengan output yang seragam secara ideal, sela bingkai dalam milisaat ialah kira-kira 1,000 ÷ FPS. Maka 60 FPS bersamaan kira-kira 16.67 ms, dan 120 FPS kira-kira 8.33 ms. Ini penukaran masa, bukannya penanda aras komputer.

Andaikan rakaman mengandungi 100 bingkai: 99 mengambil 10 ms setiap satu dan satu mengambil 100 ms. Jumlah masa ialah 99 × 10 + 100 = 1,090 ms. Jumlah bingkai dibahagi jumlah tempoh menghasilkan kira-kira 91.74 FPS. Puratanya kelihatan baik, tetapi satu masa menunggu tetap jauh lebih lama.

Rajah: pengiraan masa bingkai sintetik dan aliran semakan, bukan tangkapan skrin penanda aras permainan.

Min aritmetik FPS seketika setiap bingkai juga berbeza daripada jumlah bingkai dibahagi jumlah tempoh. Tetingkap pensampelan, penyertaan skrin pemuatan dan takrif statistik alat boleh mengubah nilai akhir.

Satu lagi ukuran berguna ialah bahagian masa yang digunakan oleh bingkai perlahan. Dalam rakaman hipotesis selama 60 saat dengan enam bingkai 100 ms, enam bingkai itu sahaja mengambil 0.6 saat, iaitu 1% daripada tempoh. Ini masih pengiraan sintetik, tetapi mengekalkan jeda jarang berlaku yang mungkin tidak ditunjukkan oleh persentil.

Rajah: 100 bingkai sintetik. Paksi mendatar ialah nombor bingkai, bukan masa bersela seragam. Bingkai 50 mengambil 100 ms; 99 bingkai lain masing-masing mengambil 10 ms.

Pastikan jenis bingkai yang direkodkan

Halaman rasmi NVIDIA FrameView menyenaraikan pengukuran kadar bingkai, masa bingkai dan kuasa, termasuk sokongan log.[1] Log menyimpan data sekitar sesuatu kejadian, tetapi alat rakaman sahaja tidak dapat membuktikan bahawa CPU menjadi punca kesesakan.

Sebelum membandingkan laporan, semak bingkai yang dirender berbanding yang dipaparkan, penjanaan bingkai, V-sync dan had FPS. Mencampurkan bingkai terjana dengan bingkai render asas boleh menaikkan angka tanpa meningkatkan respons input secara sepadan. Masalah dalam laluan paparan juga mungkin berada di luar log rendering, jadi log yang lancar tidak menolak semua gangguan yang kelihatan.

“1% low” membantu menilai prestasi bingkai yang lemah, tetapi perisiannya mungkin menggunakan kaedah pengiraan berbeza. Simpan nama alat, versi, takrif metrik dan tempoh rakaman bersama angka tersebut. Jangan anggap ia bingkai tunggal paling perlahan atau gabungkan alat berlainan dalam satu kedudukan prestasi.

CapFrameX membezakan dengan jelas persentil mengikut susunan bingkai daripada tempoh sebenar.[3] “99% bingkai memenuhi ambang” tidak semestinya bermaksud “99% masa bermain lancar”, kerana beberapa bingkai perlahan boleh menggunakan masa yang banyak. Ia turut membezakan nilai persentil daripada ringkasan pecahan paling perlahan. Jika laporan hanya menamakan “1% low” tanpa kaedah pengiraan, kekalkan batasan itu dalam tafsiran.

Medan log manakah yang perlu dibaca bersama?

Buka CSV dan periksa pengepala dahulu. Dokumentasi konsol PresentMon mentakrifkan medan berikut; output sebenar bergantung pada versi dan pilihan tangkapan.[2]

Medan ini menerangkan sela yang berbeza, dan kerja CPU serta GPU boleh bertindih. Jangan terus menjumlahkan lajur dan menganggap hasilnya mesti menyamai keseluruhan masa bingkai. MsGPUBusy bukan peratus penggunaan GPU dalam Task Manager. Baca takrif sebelum memutuskan sama ada dua nilai boleh dibandingkan.

Jika sela penyerahan bertambah panjang dan masa aktif GPU meningkat dengan ketara, kerja grafik wajar disiasat. Jika kerja GPU singkat tetapi penantian panjang, had FPS, bekalan kerja daripada CPU atau penjadualan mungkin terlibat. Pemerhatian kedua mengecilkan skop siasatan, bukan membuktikan prestasi CPU tidak mencukupi. Projek ini juga menerangkan batasan bagi API dan penjadualan perkakasan yang berbeza. Hormati medan yang tiada atau terhad pengukurannya.[4]

Simpan bukti melalui laluan pendek yang boleh diulang

Pilih laluan yang boleh diulang dan kekalkan resolusi, tetapan grafik, pergerakan kamera serta had FPS. Simpan tetapan asal, mulakan log dan simpan output selepas tamat. Labelkan fail dengan versi permainan, pemacu grafik, adegan dan tetapan untuk perbandingan kemudian.

Bagi setiap lonjakan, catat sama ada ia berlaku semasa kemasukan pertama, putaran kamera mendadak, program latar bermula atau setiap kali melalui lokasi sama. Periksa metrik CPU, GPU, memori dan storan yang tersedia bersama-sama. Jangan isi medan sensor yang tidak dirakam dengan sifar.

Ulang tiga kali dahulu dan simpan setiap hasil. Jika perbezaannya besar, semak adegan, suhu, cache dan tugas latar sebelum memanjangkan atau menambah ujian. Menyimpan hanya percubaan terbaik membuang variasi yang perlu dijelaskan.

Berikut ialah templat permulaan. Enam puluh saat dan tiga percubaan hanyalah contoh, bukannya jaminan mencukupi untuk setiap permainan.

Bandingkan mula sejuk secara berasingan daripada adegan yang sudah dilawati. Gangguan pemuatan pertama memerlukan rekod sendiri. Untuk beban grafik berterusan, jangan bandingkan kumpulan data pemuatan pertama dengan kumpulan yang sudah melalui pemanasan.

PresentMon menyokong pemilihan proses mengikut nama, penetapan tempoh tangkapan dan pemilihan fail CSV output.[2] Sama ada menggunakan GUI atau baris perintah, pastikan proses sasaran betul supaya bingkai pelancar dan permainan tidak bercampur. Tiada tangkapan permainan sebenar dilakukan di sini; imej menerangkan metrik.

Ubah satu keadaan pada satu masa

Jika mengesyaki beban grafik, kurangkan satu beban rendering yang jelas dan ulang laluan. Jika mengesyaki gangguan latar, tutup satu program yang dikenal pasti dan uji semula. Jangan ubah pemacu, kualiti grafik dan had FPS serentak sambil memulakan semula permainan, kerana punca peningkatan akan menjadi kabur.

Jika menurunkan kualiti menaikkan purata FPS tetapi lonjakan kekal di tempat sama, beban rendering purata dan jeda itu mungkin masalah berlainan. Gangguan pada laluan pertama yang berkurang kemudian mungkin melibatkan pemuatan aset atau cache, tetapi corak itu sahaja tidak menentukan puncanya. Penggunaan GPU rendah boleh mencerminkan had, penantian CPU atau sekatan lain; ia tidak terus bermaksud kad grafik kurang berkuasa.

Simpan kesimpulan yang terikat pada keadaan, seperti “ketiga-tiga percubaan mengalami lonjakan ketika memasuki kawasan, dan menurunkan bayang-bayang tidak menghapuskannya”, berbanding “PC mempunyai kesesakan 30%”. Ujian seterusnya boleh meneliti lokasi lonjakan dan perbezaan tetapan bayang-bayang tanpa bermula semula daripada tekaan.

Rujukan

1. Halaman rasmi NVIDIA FrameView. Menyokong fungsi kadar bingkai, masa bingkai dan log. Bukan bukti ujian telah dijalankan, medan kuasa seragam pada semua GPU atau perisian sudah dipasang.

2. Dokumentasi PresentMon Console Application. Keadaan cabang main dibaca pada 2026-09-27. Mentakrifkan medan CSV, proses sasaran dan tempoh tangkapan. Medan berubah mengikut versi; tiada tangkapan setempat tersirat.

3. CapFrameX: Explanation of different performance metrics. Taxxor, 2020-05-31. Menerangkan persentil dan x% low. Digunakan untuk konsep metrik, bukan tangkapan skrin antara muka semasa.

4. Dokumentasi projek dan batasan PresentMon. Disemak pada 2026-09-27. API dan penjadualan perkakasan boleh menjejaskan pengukuran; rekodkan persekitaran daripada terus menyimpulkan kesesakan.