ऊँची फ़्रेम दर के बावजूद गेम क्यों अटक सकता है

गेम में प्रति सेकंड नब्बे से अधिक फ़्रेम दिख रहे हैं, फिर भी कैमरा घुमाने या नए क्षेत्र में जाने पर वह पल भर रुक जाता है। औसत FPS बेकार नहीं हुआ है; वह एक मोटे सवाल का जवाब देता है: उस अवधि में कितने फ़्रेम बने? वे नियमित अंतराल पर आए या नहीं, यह जानने के लिए उनका समय देखना होगा।

फ़्रेम टाइम से शुरुआत करें और फिर तय करें कि आगे क्या मापना है। बॉटलनेक का एक प्रतिशत या GPU उपयोग में एक बार की गिरावट यह नहीं बता सकती कि कौन-सा पुर्जा बदलना चाहिए।

अच्छे औसत के पीछे एक लंबा फ़्रेम छिप सकता है

आदर्श रूप से एकसमान आउटपुट में मिलीसेकंड का फ़्रेम अंतराल लगभग 1,000 ÷ FPS होता है। इसलिए 60 FPS लगभग 16.67 ms और 120 FPS लगभग 8.33 ms के बराबर है। यह समय का रूपांतरण है, किसी कंप्यूटर का बेंचमार्क नहीं।

मान लें कि रिकॉर्डिंग में 100 फ़्रेम हैं: 99 फ़्रेम में प्रत्येक को 10 ms और एक को 100 ms लगते हैं। कुल समय 99 × 10 + 100 = 1,090 ms है। कुल फ़्रेम को कुल अवधि से भाग देने पर लगभग 91.74 FPS मिलता है। औसत ठीक दिखता है, लेकिन एक बार का इंतज़ार फिर भी बहुत लंबा है।

चित्र: कृत्रिम फ़्रेम-टाइम गणना और जाँच का क्रम; यह गेम बेंचमार्क का स्क्रीनशॉट नहीं है।

हर फ़्रेम के तात्कालिक FPS का अंकगणितीय औसत भी कुल फ़्रेम को कुल अवधि से भाग देने के बराबर नहीं होता। सैंपलिंग अवधि, लोडिंग स्क्रीन को शामिल करना और टूल की सांख्यिकीय परिभाषा अंतिम संख्या बदल सकते हैं।

यह देखना भी उपयोगी है कि धीमे फ़्रेम कितना समय घेरते हैं। 60 सेकंड की काल्पनिक रिकॉर्डिंग में 100 ms के छह फ़्रेम अकेले 0.6 सेकंड, यानी अवधि का 1%, लेते हैं। यह भी कृत्रिम गणना है, लेकिन इससे वे दुर्लभ विराम बने रहते हैं जिन्हें कोई पर्सेंटाइल छोड़ सकता है।

चित्र: 100 कृत्रिम फ़्रेम। क्षैतिज अक्ष फ़्रेम क्रमांक है, समान अंतराल वाला समय नहीं। फ़्रेम 50 में 100 ms लगते हैं; बाकी 99 में प्रत्येक को 10 ms।

पहले समझें कि किस तरह के फ़्रेम रिकॉर्ड हुए

NVIDIA की आधिकारिक FrameView साइट फ़्रेम दर, फ़्रेम टाइम और पावर मापन के साथ लॉगिंग की सुविधा बताती है।[1] लॉग किसी घटना के आसपास का डेटा बचाते हैं, लेकिन रिकॉर्डिंग टूल अकेले यह साबित नहीं कर सकता कि CPU बॉटलनेक है।

रिपोर्ट की तुलना से पहले रेंडर किए और प्रदर्शित फ़्रेम, फ़्रेम जनरेशन, V-sync और FPS सीमा जाँचें। जनरेट किए गए फ़्रेम को मूल रेंडर किए फ़्रेम में मिलाने से संख्या बढ़ सकती है, जबकि इनपुट प्रतिक्रिया उसी अनुपात में बेहतर न हो। डिस्प्ले पथ की समस्याएँ रेंडरिंग लॉग के बाहर भी हो सकती हैं, इसलिए नियमित लॉग हर दिखाई देने वाले अटकाव को खारिज नहीं करता।

“1% low” धीमे फ़्रेम प्रदर्शन को देखने में मदद करता है, लेकिन अलग सॉफ़्टवेयर इसे अलग तरह से गिन सकते हैं। संख्या के साथ टूल का नाम, संस्करण, मेट्रिक की परिभाषा और रिकॉर्डिंग अवधि रखें। इसे सबसे धीमा एकल फ़्रेम न मानें और अलग-अलग टूल के परिणाम मिलाकर रैंकिंग न बनाएँ।

CapFrameX फ़्रेमों की रैंक के आधार पर निकले पर्सेंटाइल और बीती अवधि के बीच स्पष्ट अंतर करता है।[3] “99% फ़्रेम सीमा पूरी करते हैं” को ठीक-ठीक “खेलने का 99% समय सुचारु है” नहीं कहा जा सकता, क्योंकि कुछ धीमे फ़्रेम काफ़ी समय ले सकते हैं। यह पर्सेंटाइल मान और सबसे धीमे हिस्से के सारांश में भी अंतर बताता है। यदि रिपोर्ट गणना बताए बिना केवल “1% low” लिखती है, तो उस सीमा को ध्यान में रखें।

लॉग के कौन-से फ़ील्ड साथ पढ़ने चाहिए?

CSV खोलें और पहले उसके हेडर देखें। PresentMon का कंसोल दस्तावेज़ नीचे दिए फ़ील्ड परिभाषित करता है; वास्तविक आउटपुट संस्करण और कैप्चर विकल्पों पर निर्भर है।[2]

ये फ़ील्ड अलग-अलग अंतराल बताते हैं और CPU तथा GPU का काम एक-दूसरे पर आच्छादित हो सकता है। कॉलम जोड़कर यह न मानें कि उनका योग पूरे फ़्रेम समय के बराबर होना चाहिए। MsGPUBusy, Task Manager का GPU उपयोग प्रतिशत नहीं है। दो संख्याओं की तुलना करने से पहले उनकी परिभाषाएँ पढ़ें।

यदि फ़्रेम भेजने का अंतराल बढ़े और GPU का सक्रिय समय भी स्पष्ट रूप से बढ़े, तो ग्राफ़िक्स कार्य की जाँच उचित है। यदि GPU का काम छोटा हो लेकिन इंतज़ार लंबा हो, तो FPS सीमा, CPU से काम की आपूर्ति या शेड्यूलिंग की भूमिका हो सकती है। यह खोज का दायरा घटाता है, CPU की कम क्षमता साबित नहीं करता। परियोजना अलग API और हार्डवेयर शेड्यूलिंग की सीमाएँ भी बताती है। अनुपलब्ध या सीमित मापन वाले फ़ील्ड को मनमाने ढंग से न भरें।[4]

दोहराए जा सकने वाले छोटे रास्ते से साक्ष्य बचाएँ

ऐसा रास्ता चुनें जिसे दोहरा सकें और रिज़ॉल्यूशन, ग्राफ़िक्स सेटिंग, कैमरा मूवमेंट तथा FPS सीमा स्थिर रखें। मूल सेटिंग बचाएँ, लॉगिंग शुरू करें और समाप्ति पर आउटपुट रखें। बाद में तुलना के लिए फ़ाइलों पर गेम संस्करण, ग्राफ़िक्स ड्राइवर, दृश्य और सेटिंग लिखें।

हर स्पाइक के लिए नोट करें कि वह पहली बार प्रवेश करने, अचानक कैमरा घुमाने, बैकग्राउंड प्रोग्राम शुरू होने या हर बार उसी स्थान से गुजरने पर आता है। उपलब्ध CPU, GPU, मेमोरी और स्टोरेज मेट्रिक साथ देखें। जो सेंसर डेटा रिकॉर्ड नहीं हुआ, उसकी जगह शून्य न भरें।

शुरुआत में तीन बार दोहराएँ और हर परिणाम बचाएँ। अंतर अधिक हो तो टेस्ट लंबा करने या बढ़ाने से पहले दृश्य, तापमान, कैश और बैकग्राउंड कार्य जाँचें। केवल सबसे अच्छा रन बचाने से वही भिन्नता मिट जाती है जिसे समझाना है।

नीचे शुरुआत के लिए नमूना है। 60 सेकंड और तीन रन उदाहरण हैं; हर गेम के लिए पर्याप्त होने की गारंटी नहीं।

कोल्ड स्टार्ट और पहले देखे जा चुके दृश्यों की तुलना अलग करें। पहली लोडिंग का अटकाव अलग रिकॉर्ड का विषय है। लगातार ग्राफ़िक्स लोड की जाँच में एक समूह के पहली-लोड डेटा को दूसरे के पहले से तैयार डेटा से न मिलाएँ।

PresentMon प्रक्रिया को नाम से चुनने, कैप्चर अवधि तय करने और CSV आउटपुट फ़ाइल चुनने देता है।[2] GUI हो या कमांड लाइन, लक्ष्य प्रक्रिया की पुष्टि करें ताकि लॉन्चर और गेम के फ़्रेम न मिलें। यहाँ किसी वास्तविक गेम का कैप्चर नहीं किया गया; चित्र मेट्रिक समझाते हैं।

एक बार में एक ही शर्त बदलें

ग्राफ़िक्स लोड पर संदेह हो तो रेंडरिंग का एक स्पष्ट भार कम करें और रास्ता दोहराएँ। बैकग्राउंड हस्तक्षेप पर संदेह हो तो एक ज्ञात प्रोग्राम बंद करके फिर टेस्ट करें। ड्राइवर, ग्राफ़िक्स गुणवत्ता, FPS सीमा और गेम रीस्टार्ट सब एक साथ न बदलें, वरना सुधार का कारण अस्पष्ट रहेगा।

यदि गुणवत्ता घटाने पर औसत FPS बढ़े लेकिन उसी स्थान का स्पाइक बना रहे, तो औसत रेंडरिंग लोड और वह विराम अलग समस्याएँ हो सकते हैं। पहले चक्कर में अटकाव और बाद में कमी का संबंध एसेट लोडिंग या कैश से हो सकता है, पर यह पैटर्न अकेले कारण तय नहीं करता। कम GPU उपयोग FPS सीमा, CPU की प्रतीक्षा या दूसरी बाधाओं का संकेत हो सकता है; यह सीधे ग्राफ़िक्स कार्ड की कम क्षमता नहीं बताता।

“PC में 30% बॉटलनेक है” के बजाय शर्तों से जुड़ा निष्कर्ष बचाएँ, जैसे “तीनों रन में क्षेत्र में प्रवेश करते समय स्पाइक आया और शैडो कम करने से वह नहीं हटा।” अगला टेस्ट फिर उसी स्थान और शैडो सेटिंग के अंतर की जाँच कर सकेगा, बिना दोबारा अनुमान से शुरू किए।

संदर्भ

1. NVIDIA FrameView का आधिकारिक पृष्ठ। फ़्रेम दर, फ़्रेम टाइम और लॉगिंग सुविधाओं का आधार। इससे टेस्ट किए जाने, सभी GPU पर समान पावर फ़ील्ड मिलने या सॉफ़्टवेयर इंस्टॉल होने का दावा नहीं निकलता।

2. PresentMon Console Application दस्तावेज़। main शाखा का 2026-09-27 को पढ़ा गया रूप। CSV फ़ील्ड, लक्ष्य प्रक्रिया और कैप्चर अवधि परिभाषित करता है। फ़ील्ड संस्करण के अनुसार बदलते हैं; स्थानीय कैप्चर का संकेत नहीं है।

3. CapFrameX: Explanation of different performance metrics। Taxxor, 2020-05-31। पर्सेंटाइल और x% low समझाता है। मेट्रिक की अवधारणाओं के लिए उपयोग किया गया, वर्तमान इंटरफ़ेस के स्क्रीनशॉट के रूप में नहीं।

4. PresentMon परियोजना दस्तावेज़ और सीमाएँ। 2026-09-27 को जाँचा गया। API और हार्डवेयर शेड्यूलिंग मापन प्रभावित कर सकते हैं; सीधे बॉटलनेक मानने के बजाय परिवेश रिकॉर्ड करें।