ফ্রেম রেট বেশি হলেও গেম কেন আটকে যেতে পারে

গেমে প্রতি সেকেন্ডে নব্বইয়ের বেশি ফ্রেম দেখাচ্ছে, অথচ ক্যামেরা ঘোরালে বা নতুন এলাকায় ঢুকলে মুহূর্তের জন্য থেমে যাচ্ছে। গড় 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 পাওয়া যায়। গড়টি ভালো দেখালেও একটি অপেক্ষা অনেক দীর্ঘ থাকে।

Illustrative guide and worked example in English

চিত্র: কৃত্রিম ফ্রেম-টাইম হিসাব ও যাচাইয়ের ধাপ; গেম বেঞ্চমার্কের স্ক্রিনশট নয়।

প্রতি ফ্রেমের তাৎক্ষণিক FPS-এর গাণিতিক গড়ও মোট ফ্রেমকে মোট সময় দিয়ে ভাগ করার সমান নয়। নমুনা নেওয়ার সময়সীমা, লোডিং স্ক্রিন অন্তর্ভুক্ত করা এবং টুলের পরিসংখ্যানগত সংজ্ঞা চূড়ান্ত সংখ্যাকে বদলাতে পারে।

ধীর ফ্রেমগুলো কতটা সময় দখল করে, সেটিও উপকারী পরিমাপ। 60 সেকেন্ডের একটি কাল্পনিক রেকর্ডে 100 ms-এর ছয়টি ফ্রেম থাকলে শুধু এগুলোই 0.6 সেকেন্ড, অর্থাৎ পুরো সময়ের 1%, নেয়। এটিও কৃত্রিম হিসাব, তবে এতে এমন বিরল বিরতির তথ্য থাকে যা কোনো পার্সেন্টাইল বাদ দিতে পারে।

Illustrative guide and worked example in English

চিত্র: 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]

ক্ষেত্র	নথিতে দেওয়া অর্থ	কী তদন্তে সাহায্য করতে পারে
`MsBetweenPresents`	পরপর দুটি Present কলের মধ্যবর্তী সময়	অ্যাপ্লিকেশনের ফ্রেম জমা দেওয়া হঠাৎ ধীর হচ্ছে কি না
`MsCPUBusy`	এই ফ্রেম জমা দেওয়ার আগে CPU-এর কাজ	দীর্ঘ ফ্রেমের আশপাশে CPU-এর কাজের পরিবর্তন
`MsGPUBusy`	এই প্রসেসের ফ্রেমের জন্য GPU-এর সক্রিয় কাজ	দৃশ্যের সঙ্গে গ্রাফিক্সের কাজ ভারী হচ্ছে কি না
`DisplayLatency`	ফ্রেম শুরু থেকে প্রদর্শন পর্যন্ত সময়	ডিসপ্লে পথে অপেক্ষা
`DisplayedTime`	ফ্রেম কতক্ষণ দেখানো হয়েছে; না দেখালে NA হতে পারে	কোনো ফ্রেম অস্বাভাবিক দীর্ঘ সময় স্ক্রিনে থাকছে কি না

এই ক্ষেত্রগুলো ভিন্ন সময়সীমা বোঝায়, আর CPU ও GPU-এর কাজ একসঙ্গে চলতে পারে। কলামগুলো যোগ করে মোটটিকে পুরো ফ্রেমের সময়ের সমান হওয়ার শর্ত দেবেন না। MsGPUBusy Task Manager-এর GPU ব্যবহারের শতাংশ নয়। দুটি সংখ্যা তুলনাযোগ্য কি না ঠিক করার আগে সংজ্ঞা পড়ুন।

জমা দেওয়ার ব্যবধান বাড়ার সঙ্গে GPU-এর সক্রিয় সময়ও স্পষ্টভাবে বাড়লে গ্রাফিক্সের কাজ তদন্ত করা দরকার। GPU-এর কাজ অল্প অথচ অপেক্ষা দীর্ঘ হলে FPS সীমা, CPU থেকে কাজের সরবরাহ বা শিডিউলিং জড়িত থাকতে পারে। দ্বিতীয় পর্যবেক্ষণটি অনুসন্ধানের পরিসর কমায়; CPU-এর ক্ষমতা কম বলে প্রমাণ করে না। প্রকল্পে ভিন্ন API ও হার্ডওয়্যার শিডিউলিংয়ের সীমাবদ্ধতাও লেখা আছে। অনুপস্থিত বা সীমিত পরিমাপের ক্ষেত্রগুলো ইচ্ছামতো পূরণ করবেন না।[4]

পুনরাবৃত্তিযোগ্য ছোট পথ দিয়ে প্রমাণ রাখুন

বারবার অনুসরণ করা যায় এমন পথ বেছে নিন এবং রেজোলিউশন, গ্রাফিক্স সেটিং, ক্যামেরার নড়াচড়া ও FPS সীমা স্থির রাখুন। মূল সেটিং সংরক্ষণ করে লগ শুরু করুন এবং শেষে আউটপুট রাখুন। পরে তুলনার জন্য ফাইলে গেমের সংস্করণ, গ্রাফিক্স ড্রাইভার, দৃশ্য ও সেটিং লিখুন।

প্রতি স্পাইকের ক্ষেত্রে লিখুন সেটি প্রথম প্রবেশে, হঠাৎ ক্যামেরা ঘোরানোর সময়, ব্যাকগ্রাউন্ড প্রোগ্রাম শুরু হলে, নাকি একই জায়গা দিয়ে প্রতিবার যাওয়ার সময় হচ্ছে। পাওয়া CPU, GPU, মেমরি ও স্টোরেজ মেট্রিক একসঙ্গে দেখুন। যে সেন্সর তথ্য রেকর্ড হয়নি, তার জায়গায় শূন্য বসাবেন না।

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

নিচে শুরু করার একটি নমুনা দেওয়া হলো। 60 সেকেন্ড ও তিনটি রান উদাহরণমাত্র; সব গেমের জন্য যথেষ্ট হওয়ার নিশ্চয়তা নয়।

রেকর্ড	উদাহরণ
অংশ	নির্দিষ্ট সেভ থেকে শুরু করে 60 সেকেন্ড একই পথ অনুসরণ
কোল্ড-স্টার্ট রেকর্ড	দৃশ্যে প্রথম প্রবেশ আলাদা করে রাখা
পুনরাবৃত্তি	একই সেটিংয়ে তিনটি রান, আলাদা CSV ফাইল
বাদ দেওয়া অংশ	মেনু ও লোডিং স্ক্রিন গণনা হবে কি না ক্যাপচারের আগে ঠিক করা
এই পরীক্ষার পরিবর্তন	শুধু শ্যাডো কমানো; অন্য সব একই রাখা

কোল্ড স্টার্ট ও আগে দেখা দৃশ্য আলাদা করে তুলনা করুন। প্রথম লোডের আটকে যাওয়া আলাদা রেকর্ডের বিষয়। টানা গ্রাফিক্স লোড পরীক্ষা করতে এক দলের প্রথম-লোড তথ্যের সঙ্গে অন্য দলের আগে থেকে প্রস্তুত অবস্থার তথ্য মেশাবেন না।

PresentMon-এ নাম দিয়ে প্রসেস বেছে নেওয়া, ক্যাপচারের সময়কাল ঠিক করা এবং CSV আউটপুট ফাইল নির্বাচন করা যায়।[2] GUI বা কমান্ড লাইন যেটিই ব্যবহার করুন, লক্ষ্য প্রসেস নিশ্চিত করুন যাতে লঞ্চার ও গেমের ফ্রেম মিশে না যায়। এখানে কোনো বাস্তব গেম ক্যাপচার করা হয়নি; ছবিগুলো মেট্রিক বোঝায়।

একবারে একটি শর্ত বদলান

গ্রাফিক্স লোড সন্দেহ হলে রেন্ডারিংয়ের একটি নির্দিষ্ট চাপ কমিয়ে একই পথ আবার অনুসরণ করুন। ব্যাকগ্রাউন্ড হস্তক্ষেপ সন্দেহ হলে একটি পরিচিত প্রোগ্রাম বন্ধ করে পুনরায় পরীক্ষা করুন। ড্রাইভার, গ্রাফিক্সের মান, FPS সীমা এবং গেম রিস্টার্ট একসঙ্গে বদলাবেন না, নইলে উন্নতির কারণ অস্পষ্ট হবে।

মান কমালে গড় FPS বাড়লেও একই জায়গায় স্পাইক থাকলে গড় রেন্ডারিং লোড ও সেই বিরতি আলাদা সমস্যা হতে পারে। প্রথমবার আটকে যাওয়া পরে কমে আসার সঙ্গে অ্যাসেট লোডিং বা ক্যাশের সম্পর্ক থাকতে পারে, কিন্তু এই ধরন একাই কারণ চিহ্নিত করে না। কম GPU ব্যবহার সীমা, CPU-এর জন্য অপেক্ষা বা অন্য বাধার প্রতিফলন হতে পারে; এটি সরাসরি গ্রাফিক্স কার্ডের ক্ষমতার ঘাটতি বোঝায় না।

“PC-তে 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 ও হার্ডওয়্যার শিডিউলিং পরিমাপে প্রভাব ফেলতে পারে; সরাসরি বটলনেক ধরে না নিয়ে পরিবেশ লিখে রাখুন।