Перейти к содержимому

লেটেন্সি পরিমাপ ও 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 গ্রাফিক্স API কমান্ডের প্রস্তুতি এবং লেখা
submit_start_to_gpu_begin প্রস্তুতি শুরু থেকে GPU-কাজ শুরু পর্যন্ত; এটি বিশুদ্ধ কিউ বিলম্ব নয়
gpu_execution GPU-কাজের প্রকৃত সম্পাদন, GPU টিকে
presentation spans প্রদর্শন: Present-এর মোড়ক এবং সংকেত থেকে এবং GPU-কাজ শেষ থেকে ScreenTime পর্যন্ত বিরতি

প্রতিটি পর্যায় পরিসংখ্যান এবং পার্সেন্টাইলসহ একটি বিন্যাসে দেওয়া হয়। সেগমেন্টগুলো প্রতিটি চিহ্ন জোড়ার জন্য আলাদাভাবে গণনা করা হয়, দুটি মিডিয়ান বিয়োগ করে নয়। যদি কোনো পর্যায়ের শেষ চিহ্ন অনুপস্থিত বা অবিশ্বস্ত হয়, তার বিন্যাস খালি থাকে — কোনো কৃত্রিম মান নেই। টাইমারের বিলম্ব (নির্ধারিত সময়সীমা এবং প্রকৃত সংকেতের পার্থক্য) সংকেতের আগে আলাদা ডায়াগনস্টিক হিসেবে লিপিবদ্ধ হয় এবং পথের সামগ্রিক মানে অন্তর্ভুক্ত হয় না।

CPU-সময় QueryPerformanceCounter-এর মাধ্যমে লিপিবদ্ধ হয়। GPU-এর জন্য ইঞ্জিন পরিমাপকৃত কাজের চারপাশে দুটি timestamp query স্থাপন করে, GetTimestampFrequency-এর মাধ্যমে কিউ ফ্রিকোয়েন্সি পায় এবং টিক পার্থক্যকে মিলিসেকেন্ডে রূপান্তর করে:

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

D3D12 timing-এর Microsoft ডকুমেন্টেশন অনুযায়ী, 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 8,333333 মিসে-এ ক্যালিব্রেট করা GPU-লোড নিয়ে কাজ করে, অর্থাৎ প্রায় 120 Hz-এর গণনা বাজেটে। প্রকৃত মনিটরের ভিন্ন ফ্রিকোয়েন্সি থাকতে পারে।

ক্যালিব্রেশন শেডারের ভিতরে জটিলতা 1-4096 পরিসরে পরিবর্তন করে। পাসের সংখ্যা স্থির থাকে: চারটি পোস্টপাস। প্রথমে লক্ষ্য সময়ের চারপাশে একটি পরিসর নির্বাচন করা হয়, তারপর তা সূক্ষ্ম করা হয় এবং নির্বাচিত কনফিগারেশন যাচাই করা হয়। দ্রুত ভিডিও কার্ডে একই সময় নিতে আরও জটিল কাজ প্রয়োজন।

Performance-এ কাজের পরিমাণ স্থির। Loaded Latency-তে লোড ক্যালিব্রেট করা হয় যাতে GPU-কাজের সময় বিভিন্ন ভিডিও কার্ডে কাছাকাছি হয়। পরিমাপের পরে প্রাপ্ত টাইমস্ট্যাম্প স্বাভাবিক করা হয় না।

বিলম্ব পরীক্ষার ফ্রেম আউটপুট একটি আলাদা উপস্থাপনা পথের মাধ্যমে যায়: flip-discard মোডে বর্ডারলেস উইন্ডো, সর্বোচ্চ ফ্রেম বিলম্ব (maximum frame latency) 1, প্রত্যাশিত DXGI অবজেক্ট এবং সিস্টেম সমর্থন করলে tearing। এই পথ স্থির পারফরম্যান্স লোড থেকে আলাদা, যা স্ক্রিন বাফারের বাইরে সম্পাদিত হয় এবং Present সৃষ্টি করে না।

প্রদর্শন ইভেন্টের জন্য PresentMon 2.5.1 লাইব্রেরি ব্যবহার করা হয়। এটি Windows-এ গ্রাফিক্স ইভেন্ট বিশ্লেষণের একটি ETW প্রকল্প, এর লেখকদের দ্বারা বর্ণিত। এই পরিমাপ পাইপলাইনে Procmon / Process Monitor প্রয়োগ করা হয় না।

PCBenchmarkX নিজস্ব সংগ্রহ সেশন চালু করে, নিজের প্রক্রিয়ার ইভেন্ট নির্বাচন করে এবং ফ্রেমগুলোকে সফটওয়্যার সংকেতের সাথে সংযুক্ত করে। এর জন্য আলাদা সার্ভিস এবং আলাদা PresentMon ম্যানুয়ালি চালু করার প্রয়োজন নেই।

অতিরিক্ত বিরতি সংরক্ষিত হয়:

  • সংকেত থেকে Present পর্যন্ত;
  • Present থেকে ScreenTime পর্যন্ত;
  • সংকেত থেকে ScreenTime পর্যন্ত।

ScreenTime হলো ফ্রেম প্রদর্শনের একটি সফটওয়্যার ইভেন্ট; স্ক্রিন থেকে আলো পরিমাপের জন্য ফটোডায়োড ব্যবহার করা হয় না। প্রদর্শন মেট্রিকগুলো PC Score-এ অন্তর্ভুক্ত নয়; কী অন্তর্ভুক্ত তা স্কোর গণনায় বর্ণিত হয়েছে। ETW সেশন চালু করতে অ্যাডমিনিস্ট্রেটর হিসেবে চালানো বা «Performance Log Users» গ্রুপের সদস্যপদ প্রয়োজন হতে পারে। যদি সেশন চালু করা না যায়, এই ডায়াগনস্টিকের ব্লক থাকবে না, এবং ব্যর্থতা ফলাফলে স্পষ্টভাবে লিপিবদ্ধ হয়। ডেটার অনুপস্থিতি শূন্য বিলম্বের সমান নয়।

PresentMon-এর GPU-সময়ও নিজস্ব D3D12-সময় থেকে আলাদাভাবে সংরক্ষিত হয়। PresentMon ডেভেলপাররা HAGS-এ GPU-মেট্রিকের নির্ভুলতার সীমাবদ্ধতা উল্লেখ করেন। তাই ইঞ্জিন নিজস্ব GPU timestamps-কে ETW-এর অনুমান দিয়ে প্রতিস্থাপন করে না।

PCBenchmarkX-এ তৈরি করা হয়েছে সংকেত জেনারেটর, ফ্রেম পর্যায়ের মিলকরণ, CPU-সিমুলেশন, D3D12-লোড, Loaded ক্যালিব্রেশন, পুনরাবৃত্ত ব্লকের ক্রম, পরিমাপ সংগ্রহ, পরিসংখ্যান প্রক্রিয়াকরণ এবং স্কোর মডেল। QPC এবং D3D12 Windows প্রদান করে। ETW-এর মাধ্যমে গ্রাফিক্স ইভেন্ট সংগ্রহে ওপেন সোর্স PresentMon প্রকল্প ব্যবহার করা হয়।

প্রযুক্তিগত তথ্য এবং বাহ্যিক সূত্র 2026-09-20 তারিখে ইঞ্জিন 0.5.2-এর জন্য যাচাই করা হয়েছে।