قياس التأخيرات و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 timing، يعكس 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. يبقى عدد الممرات ثابتًا: أربع ممرات لاحقة. أولًا يُختار نطاق حول الزمن المستهدف، ثم يُضبط ويُتحقق من التكوين المختار. لشغل نفس الزمن على بطاقة رسوميات سريعة، يلزم عمل أكثر تعقيدًا.

في Performance يكون حجم العمل ثابتًا. في 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 هو حدث برمجي لعرض الإطار؛ لا يُستخدم الثنائي الضوئي لقياس الضوء من الشاشة. مقاييس العرض لا تدخل في PC Score؛ وما يدخل فيه موصوف في حساب النقاط. قد يتطلب رفع جلسة ETW التشغيل كمسؤول أو العضوية في مجموعة «Пользователи журнала производительности». إذا تعذّر رفع الجلسة، لن توجد كتلة هذا التشخيص، ويُسجَّل الفشل في النتيجة بشكل صريح. غياب البيانات لا يساوي زمنًا صفريًا.

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

ما تم تطويره في PCBenchmarkX

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

تم التحقق من المعلومات التقنية والمصادر الخارجية في 2026-09-20 للمحرك 0.5.2.