قياس التأخيرات وPresentMon

PCBenchmarkX يقيس بشكل منفصل زمن الاستجابة الداخلي لمعالجة الإطار وزمن استجابة إخراج الإطار. هذه المقاييس البرمجية لا تصف المسار الكامل من نقرة الفأرة حتى إضاءة البكسل على الشاشة. دورة القياس الكاملة موصوفة في المنهجية.

محفّز برمجي خاص

يولّد التدفق المستمر إشارات بفواصل زمنية محددة 8-12 م.ث. إذا سمح Windows بذلك، ينشئ مؤقت انتظار عالي الدقة؛ وإلا يستخدم مؤقت انتظار عاديًا. يتم انتظار الحدث دون استقصاء مستمر يشغل النواة. دقة مؤقت النظام العامة لا تتغير أثناء ذلك.

لكل إشارة يتم تسجيل الموعد المخطط، واستيقاظ المولّد، والإشارة الفعلية، واستيقاظ المستقبِل، والمحاكاة، وإرسال الأوامر، والطوابع الزمنية لـ GPU وأحداث العرض. معرّف الإطار المشترك يربط جميع المراحل.

الموعد المخطط → استيقاظ المولّد → الإشارة
                                            ↓
                               استيقاظ المستقبِل
                                            ↓
                                CPU → الأوامر → GPU
                                            ↓
                            Present → حدث الإخراج

في هذه السجلات يظهر بشكل منفصل كل من تأخر المؤقت وزمن استيقاظ المستقبِل. بداية Core Latency هي الإشارة الفعلية، لذلك الخطوة من الموعد المخطط إلى الإشارة لا تُحتسب في هذا المقياس.

تفصيل مسار زمن الاستجابة حسب المراحل

تحتوي النتيجة على تفصيل حسب المراحل للمسار المقاس latency_path — بشكل منفصل لـ Baseline و Loaded. تُحتسب المراحل من الإشارة الفعلية:

المرحلة	ما تقيسه
signal_to_consumer_wake	من الإشارة إلى استيقاظ المستقبِل
cpu_processing	معالجة CPU: المحاكاة وتحضير بيانات الإطار
cpu_end_to_submit_start	التوقف من نهاية عمل CPU إلى بداية تحضير الإرسال
workload_submit_cpu_span	تحضير وكتابة أوامر واجهة برمجة الرسوميات
submit_start_to_gpu_begin	من بداية التحضير إلى بداية عمل GPU؛ هذا ليس زمن استجابة صافيًا للطابور
gpu_execution	تنفيذ عمل GPU نفسه، بوحدات GPU
presentation spans	العرض: غلاف Present والفترات من الإشارة ومن نهاية عمل GPU إلى ScreenTime

كل مرحلة تُعطى كتوزيع مع إحصاءات ومئينات. تُحتسب المقاطع لكل زوج من العلامات بشكل منفصل، وليس بطرح وسيطين. إذا كانت العلامة النهائية للمرحلة غائبة أو غير موثوقة، يبقى توزيعها فارغًا — لا توجد قيم بديلة. تأخر المؤقت (الفرق بين الموعد المخطط والإشارة الفعلية) يُسجَّل كتشخيص منفصل قبل الإشارة ولا يدخل في القيم الإجمالية للمسار.

QPC وطوابع GPU الزمنية الخاصة

يُسجَّل زمن CPU عبر QueryPerformanceCounter. بالنسبة لـ GPU، يضع المحرك استعلامين زمنيين حول العمل المقاس، ويحصل على تردد الطابور عبر GetTimestampFrequency، ويحوّل فرق النبضات إلى ميلي ثانية:

GPU work, ms = (GPU_end − GPU_begin) × 1000 / GPU_frequency

وفقًا لـ وثائق Microsoft حول توقيت D3D12، يعكس timestamp query مرور العمل حتى نهاية خط الأنابيب، وتُربط عدادات GPU و CPU عبر GetClockCalibration.

زوج المعايرة GPU/QPC يسمح بالتعبير عن اكتمال عمل GPU على نفس المقياس الزمني للإشارة:

GPU_completion_QPC = calibration_QPC +
  (GPU_end − calibration_GPU) × QPC_frequency / GPU_frequency

Core Latency, ms =
  (GPU_completion_QPC − signal_QPC) × 1000 / QPC_frequency

تعتمد دقة هذا التقدير إلى حد كبير على مدى دقة مطابقة ساعتي CPU و GPU. وهي مع ذلك لا تغطي مسار USB للفأرة، ولا زمن مسح المصفوفة، ولا استجابة البكسل. تشرح Microsoft بشكل منفصل تفاصيل العلامات الزمنية عالية الدقة QPC.

Baseline و Loaded

يقيس Baseline زمن الاستجابة في الحد الأدنى من تكوين هذا الحمل. يعمل Loaded مع حمل GPU معاير على 8,333333 م.ث، أي على ميزانية حسابية تبلغ حوالي 120 هرتز. قد تكون للشاشة الفعلية تردد مختلف.

تغيّر المعايرة التعقيد داخل التظليل في نطاق 1-4096. يبقى عدد التمريرات ثابتًا: أربع تمريرات لاحقة. أولًا يُختار نطاق حول الزمن المستهدف، ثم يُضبط ويُتحقق من التكوين المختار. لشغل نفس الوقت على بطاقة رسوميات سريعة، يلزم عمل أكثر تعقيدًا.

في اختبارات الأداء يكون حجم العمل ثابتًا. في Loaded Latency يُعاير الحمل ليكون زمن عمل GPU قريبًا على بطاقات رسوميات مختلفة. العلامات الزمنية الناتجة لا تُطبَّع بعد القياس.

يتم إخراج إطارات اختبار زمن الاستجابة عبر مسار عرض منفصل: نافذة بلا إطار في وضع flip-discard، وأقصى تأخر للإطار (maximum frame latency) 1، وكائن DXGI المنتظر، وtearing إذا كان النظام يدعمه. هذا المسار منفصل عن حمل الأداء الثابت الذي يُنفَّذ خارج المخزن المؤقت للشاشة ولا يسبب Present.

دور PresentMon

لأحداث العرض تُستخدم مكتبة PresentMon 2.5.1. هذا مشروع ETW لتحليل أحداث الرسوميات في Windows، موصوف من مؤلفيه. لا يُستخدم Procmon / Process Monitor في خط القياس هذا.

يرفع PCBenchmarkX جلسة جمع خاصة به، وينتقي أحداث عمليته، ويربط الإطارات بالإشارات البرمجية. لا يحتاج ذلك إلى خدمة منفصلة ولا إلى تشغيل PresentMon منفصل يدويًا.

تُحفظ فترات إضافية:

• من الإشارة إلى Present;
• من Present إلى ScreenTime;
• من الإشارة إلى ScreenTime.

ScreenTime هو حدث برمجي لعرض الإطار؛ لا يُستخدم صمام ضوئي لقياس الضوء من الشاشة. في النموذج الأساسي CPU/GPU/Latency تشكّل أوزان Baseline و Loaded 20/80 داخل مكوّن زمن الاستجابة. مقاييس العرض لا تدخل في PC Score؛ وما يدخل فيه موصوف في حساب النقاط. قد يتطلب رفع جلسة ETW التشغيل كمسؤول أو العضوية في مجموعة «مستخدمو سجل الأداء». إذا تعذّر رفع الجلسة، لن توجد كتلة هذا التشخيص، ويُسجَّل الفشل في النتيجة بشكل صريح. غياب البيانات لا يساوي زمن استجابة صفريًا.

يُخزَّن زمن GPU من PresentMon أيضًا بشكل منفصل عن زمن D3D12 الخاص. يشير مطوّرو PresentMon إلى قيود دقة مقاييس GPU عند HAGS. لذلك لا يستبدل المحرك طوابع GPU الزمنية الخاصة بتقدير من ETW.

ما طُوِّر في PCBenchmarkX

في PCBenchmarkX طُوِّرت مولّد الإشارات، ومطابقة مراحل الإطار، ومحاكاة CPU، وأحمال D3D12، ومعايرة Loaded، وترتيب الكتل المتكررة، وجمع القياسات، والمعالجة الإحصائية، ونموذج النقاط. يوفر Windows كلاً من QPC و D3D12. ولجمع أحداث الرسوميات عبر ETW يُستخدم مشروع PresentMon المفتوح.

وُصف القياس محدَّثًا في 2026-10-02 للمحرك 0.8.0. وقد أُعيد التحقق من وثائق Microsoft حول QPC و D3D12 في هذا التاريخ. وتشير مرجعية PresentMon إلى الإصدار المستخدم 2.5.1.