Loading...
تعرض اللعبة أكثر من تسعين إطارًا في الثانية، لكنها تتوقف لحظة عند تدوير الكاميرا أو دخول منطقة جديدة. لم يفقد متوسط 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 هو موضع اختناق الأداء.
قبل مقارنة التقارير، تحقق من الإطارات المرسومة والمعروضة، وتوليد الإطارات، والمزامنة الرأسية، وحدود FPS. قد يؤدي خلط الإطارات المولدة بالإطارات المرسومة الأساسية إلى رفع الرقم دون تحسن متناسب في الاستجابة للإدخال. وقد تقع مشكلات مسار العرض خارج سجل الرسم، لذلك لا يستبعد انتظام السجل جميع حالات التقطع المرئية.
يساعد «1% low» على فحص أداء الإطارات البطيئة، لكن البرامج قد تحسبه بطرق مختلفة. احتفظ باسم الأداة وإصدارها وتعريف المقياس ومدة التسجيل مع الرقم. لا تفترض أنه أبطأ إطار منفرد، ولا تجمع نتائج أدوات مختلفة في ترتيب واحد.
يميز CapFrameX بوضوح بين المئينات المبنية على ترتيب الإطارات والمدة المنقضية.[3] لا يمكن تحويل «99% من الإطارات تستوفي حدًا معينًا» بدقة إلى «99% من وقت اللعب سلس»، لأن بضعة إطارات بطيئة قد تشغل وقتًا كبيرًا. كما يشرح الفرق بين قيمة المئين وتلخيص أبطأ جزء من العينة. إذا اكتفى التقرير بتسمية «1% low» دون طريقة الحساب، فاحتفظ بهذا القيد عند تفسيره.
افتح ملف CSV وافحص عناوين الأعمدة أولًا. تعرّف وثائق وحدة تحكم PresentMon الحقول التالية؛ ويعتمد الإخراج الفعلي على الإصدار وخيارات الالتقاط.[2]
| الحقل | المعنى في الوثائق | ما قد يساعد على فحصه |
|---|---|---|
MsBetweenPresents |
الزمن بين استدعاءَي Present متتاليين | هل تباطأ إرسال التطبيق للإطارات فجأة؟ |
MsCPUBusy |
عمل CPU قبل إرسال هذا الإطار | تغير عمل CPU حول إطار طويل |
MsGPUBusy |
عمل GPU الفعلي لإطار هذه العملية | هل زاد عبء الرسوم مع المشهد؟ |
DisplayLatency |
الزمن من بداية الإطار حتى عرضه | الانتظار في مسار العرض |
DisplayedTime |
مدة ظهور الإطار؛ قد تكون NA إذا لم يُعرض | هل بقي إطار على الشاشة مدة غير معتادة؟ |
تصف هذه الحقول فترات مختلفة، وقد يتداخل عمل CPU وGPU. لا تجمع الأعمدة ببساطة ثم تشترط أن يساوي مجموعها مدة الإطار الكلية. ليس MsGPUBusy نسبة استخدام GPU التي يعرضها مدير المهام. اقرأ التعريفات قبل تقرير قابلية رقمين للمقارنة.
إذا طالت فترات الإرسال وازداد زمن GPU الفعلي بوضوح، فعبء الرسوم يستحق الفحص. وإذا كان عمل GPU قصيرًا والانتظار طويلًا، فقد تسهم حدود FPS أو إمداد CPU بالعمل أو الجدولة. تضيق الملاحظة الثانية نطاق البحث، لكنها لا تثبت ضعف قدرة CPU. يوثق المشروع أيضًا قيودًا مرتبطة بواجهات API والجدولة العتادية. تعامل مع الحقول المفقودة أو محدودة القياس كما هي.[4]
اختر مسارًا تستطيع تكراره، وثبت الدقة وإعدادات الرسوم وحركة الكاميرا وحد FPS. احفظ الإعدادات الأصلية، وابدأ التسجيل، واحتفظ بالإخراج بعد الانتهاء. دوّن مع الملفات إصدار اللعبة وتعريف الرسوم والمشهد والإعدادات لتسهيل المقارنة لاحقًا.
لكل قفزة زمنية، سجل هل حدثت عند الدخول الأول، أم تدوير الكاميرا فجأة، أم بدء برنامج في الخلفية، أم عند كل مرور بالمكان نفسه. افحص مقاييس CPU وGPU والذاكرة والتخزين المتاحة معًا. لا تملأ حقول المستشعرات غير المسجلة بأصفار.
كرر التجربة ثلاث مرات مبدئيًا واحفظ كل نتيجة. إذا كانت الفروق كبيرة، فراجع المشهد والحرارة وذاكرات التخزين المؤقت ومهام الخلفية قبل إطالة الاختبارات أو زيادتها. الاحتفاظ بأفضل جولة فقط يمحو التباين الذي تحتاج إلى تفسيره.
الجدول التالي نموذج بداية. ستون ثانية وثلاث جولات أرقام توضيحية، وليست ضمانًا للكفاية في كل لعبة.
| السجل | مثال |
|---|---|
| المقطع | البدء من حفظ ثابت واتباع المسار نفسه لمدة 60 ثانية |
| سجل البداية الباردة | الاحتفاظ بأول دخول إلى المشهد منفصلًا |
| التكرارات | ثلاث جولات بالإعدادات نفسها، في ملفات CSV منفصلة |
| الاستبعادات | تحديد احتساب القوائم وشاشات التحميل قبل الالتقاط |
| متغير هذه الجولة | خفض الظلال فقط مع إبقاء كل شيء آخر ثابتًا |
قارن البدايات الباردة منفصلة عن المشاهد التي سبق دخولها. تقطع التحميل الأول يستحق سجلًا مستقلًا. وعند دراسة الحمل الرسومي المستمر، لا تضع بيانات التحميل الأول في مجموعة وتقابلها ببيانات بعد تهيئة الذاكرة المؤقتة في الأخرى.
يدعم PresentMon اختيار العملية بالاسم وتحديد مدة الالتقاط وملف CSV للإخراج.[2] سواء استخدمت واجهة رسومية أو سطر الأوامر، تأكد من العملية المستهدفة كي لا تختلط إطارات المشغّل بإطارات اللعبة. لم يُنفذ هنا التقاط فعلي للعبة؛ الصور توضح المقاييس.
إذا اشتبهت في عبء الرسوم، فخفّض عبئًا محددًا واحدًا من أعباء الرسم وكرر المسار. وإذا اشتبهت في تداخل برنامج خلفي، فأغلق برنامجًا معروفًا واحدًا وأعد الاختبار. لا تغيّر التعريفات وجودة الرسوم وحد FPS مع إعادة تشغيل اللعبة في آن واحد، وإلا غمض سبب التحسن.
إذا رفع خفض الجودة متوسط FPS لكن القفزة بقيت في المكان نفسه، فقد يكون متوسط عبء الرسم وتلك الوقفة مشكلتين مختلفتين. قد ترتبط الوقفة في المرور الأول التي تخف لاحقًا بتحميل الموارد أو التخزين المؤقت، لكن هذا النمط وحده لا يحدد السبب. وقد يعكس انخفاض استخدام GPU حدًا مفروضًا أو انتظار CPU أو قيودًا أخرى؛ فلا يعني مباشرة أن بطاقة الرسوم ضعيفة الأداء.
احفظ استنتاجًا مرتبطًا بظروفه، مثل «ظهرت القفزة عند دخول المنطقة في الجولات الثلاث، ولم يزلها خفض الظلال»، بدلًا من «يعاني الحاسوب اختناقًا بنسبة 30%». عندها يمكن للاختبار التالي فحص موضع القفزة والفرق في إعداد الظلال دون العودة إلى التخمين من البداية.
صفحة NVIDIA FrameView الرسمية. تدعم معلومات معدل الإطارات وزمن الإطار والتسجيل. لا تثبت إجراء اختبار أو تطابق حقول الطاقة بين وحدات GPU أو تثبيت البرنامج.
وثائق PresentMon Console Application. حالة فرع main المقروءة بتاريخ 2026-09-27. تعرّف حقول CSV والعملية المستهدفة ومدة الالتقاط. تختلف الحقول باختلاف الإصدار، ولا يُقصد بها إثبات التقاط محلي.
CapFrameX: Explanation of different performance metrics. Taxxor، 2020-05-31. يشرح المئينات وx% low. استُخدم لمفاهيم القياس، وليس كلقطة للواجهة الحالية.
وثائق مشروع PresentMon وقيوده. روجعت بتاريخ 2026-09-27. قد تؤثر واجهات API والجدولة العتادية في القياس؛ سجل البيئة بدل استنتاج الاختناق مباشرة.