رفتن به محتوای اصلی
توضیح کوهستانمعیارهای سخت‌افزاریگزارش تحلیلی· 5 دقیقه مطالعه· در فناوری

توهم چرخه کار: چرا گرافیکی که ۱۰۰٪ درگیر است، هنوز هسته‌های پردازشی بیکار دارد؟

ابزارهای مانیتورینگ مصرف‌کننده، درصد زمانی که کارت گرافیک فعال است را اندازه می‌گیرند، نه اینکه چه مقدار از سیلیکون آن واقعاً در حال انجام محاسبات ریاضی است. این تناقض نشان می‌دهد پردازنده گرافیکی که استفاده حداکثری را نشان می‌دهد، ممکن است هنوز ظرفیت رندرینگ استفاده‌نشده قابل‌توجهی داشته باشد.

به قلم نیما موسوی

این خبر را به اشتراک بگذارید

به‌طور خلاصه

  • ابزارهای مانیتورینگ مصرف‌کننده، چرخه کار GPU را اندازه می‌گیرند، نه اشباع محاسباتی آن را.
  • یک GPU می‌تواند درگیری ۱۰۰ درصدی را گزارش دهد در حالی که تا ۴۰٪ از هسته‌های پردازشی آن بیکار هستند.
  • بارهای کاری وابسته به حافظه اغلب باعث می‌شوند هسته‌های پردازشی در حین انتظار برای داده‌ها متوقف شوند.

کارت گرافیکی که درگیری ۱۰۰ درصدی را گزارش می‌دهد، لزوماً با حداکثر ظرفیت محاسباتی خود کار نمی‌کند؛ بلکه صرفاً در هر بازه زمانیِ نمونه‌برداری، فعال است. وقتی Task Manager ویندوز یا نرم‌افزارهای مانیتورینگ بار کامل را نشان می‌دهند، در واقع «چرخه کار» (duty cycle) — یعنی درصد زمانی که GPU کاملاً بیکار نیست — را اندازه می‌گیرند، نه میزان اشباع واحدهای منطقی-حسابی (ALU) آن را. این یعنی یک پردازنده گرافیکی با وجود نمایش استفاده حداکثری، ممکن است همچنان ظرفیت رندرینگ پنهان و استفاده‌نشده‌ای در پسِ وقفه‌های حافظه داشته باشد.[1][2]

این تمایز توضیح می‌دهد که چرا دو بازی مختلف می‌توانند یک GPU را روی ۱۰۰٪ نگه دارند، اما در عین حال میزان مصرف برق و حرارت تولیدی کاملاً متفاوتی داشته باشند. معیاری که به مصرف‌کننده نمایش داده می‌شود، اساساً معیاری از زمان است، در حالی که اشباع واقعی سخت‌افزار، معیاری از حجم محاسبات است.

اگر یک کارت گرافیک دستوری دریافت کند، پردازش آن را آغاز کند و ۹۰٪ از یک میلی‌ثانیه را منتظر رسیدن داده‌ها از VRAM خود بماند، نرم‌افزار مانیتورینگ همچنان آن میلی‌ثانیه را به عنوان زمان «فعال» ثبت می‌کند.[2]

مستندات مهندسی HP درباره گلوگاه‌های سیستم، دقیقاً به همین تله عیب‌یابی برای مصرف‌کنندگانی که سعی در بهینه‌سازی سیستم خود دارند، اشاره می‌کند. این تولیدکننده خاطرنشان می‌کند: «گلوگاه کامپیوتر زمانی رخ می‌دهد که قطعات سیستم شما مانع کار یکدیگر شوند.» و توضیح می‌دهد که پردازنده‌ای که منتظر حافظه است، از نظر فنی در حال کار است، اما در حال محاسبه نیست. سخت‌افزار در اینجا با سرعت انتقال داده‌ها محدود شده است، نه سرعت پردازش آن‌ها.[6]

برای درک شکاف بین درگیری گزارش‌شده و اشباع واقعی، باید به معماری فیزیکی سیلیکون‌های گرافیکی مدرن نگاه کرد. یک GPU امروزی شامل هزاران چندپردازنده جریانی (SM) مجزا است که برای اجرای موازی محاسبات ریاضی طراحی شده‌اند. این هسته‌ها برای اینکه سازنده بمانند، به یک جریان مداوم از داده‌ها نیاز دارند.[4]

درگیری (Utilization) درصد زمانی را که GPU فعال است اندازه می‌گیرد، در حالی که اشباع (Saturation) نشان می‌دهد چه مقدار از سیلیکون واقعاً در حال محاسبه است.

اگر موتور یک بازی بار کاری ایجاد کند که تنها به ۴۰٪ از آن SMها نیاز داشته باشد، اما این دستورات را به طور پیوسته و بدون وقفه صادر کند، نرم‌افزار مانیتورینگ درگیری ۱۰۰ درصدی را گزارش خواهد داد. ۶۰٪ باقی‌مانده از سیلیکون بیکار می‌نشیند، اما کاربر یک نمودار کاملاً پر شده را می‌بیند، زیرا سخت‌افزار در طول پنجره نمونه‌برداری هرگز وارد حالت خواب کامل نشده است.[2]

این پدیده به ویژه در بارهای کاری وابسته به حافظه (memory-bound) مشهود است. یک مقاله پیش‌چاپ arXiv در سال ۲۰۲۳ که زمان‌بندی استنتاج یادگیری ماشین را تحلیل می‌کرد، نشان داد که در طول عملیات‌های سنگین حافظه، اشباع واقعی محاسبات اغلب زیر ۶۰٪ باقی می‌ماند، حتی زمانی که درگیری در سطح سیستم ۱۰۰٪ گزارش می‌شود. هسته‌ها صرفاً منتظرند تا گذرگاه حافظه (memory bus) دسته بعدی داده‌ها را تحویل دهد.[3]

همین اصل مستقیماً در مورد گیمینگ نیز صدق می‌کند. بافت‌های با وضوح بالا به پهنای باند حافظه عظیمی نیاز دارند. وقتی گذرگاه حافظه GPU اشباع می‌شود، هسته‌های پردازشی متوقف می‌شوند و منتظر می‌مانند تا دسته بعدی داده‌های بافت برسد تا بتوانند نورپردازی و هندسه فریم بعدی را محاسبه کنند. در این حالت، GPU فعال است، اما در حال رندر کردن نیست.[4]

در طول عملیات‌های سنگین حافظه، اشباع واقعی محاسبات اغلب بسیار پایین‌تر از درگیری ۱۰۰ درصدی گزارش‌شده قرار می‌گیرد.

سربار API نیز نقش مهمی در ایجاد این توهم ایفا می‌کند. معماری DirectX 12 مایکروسافت که در آگوست ۲۰۱۴ معرفی شد، دقیقاً برای حل این مشکل طراحی شده بود که چگونه فراخوانی‌های ترسیم (draw calls) — دستوراتی از طرف CPU که به GPU می‌گویند چه چیزی را رندر کند — باعث ایجاد گلوگاه در عملکرد می‌شدند. پیش از این، پردازنده‌های مرکزی (CPU) به سختی می‌توانستند دستورات کافی را برای فعال نگه داشتن پردازنده‌های گرافیکی (GPU) فراهم کنند.[5]

قبل از اینکه APIهای با سربار کم به استاندارد تبدیل شوند، یک CPU تنها می‌توانست از طریق یک رشته (thread) اطلاعات را به GPU تغذیه کند. اگر آن رشته به حداکثر ظرفیت خود می‌رسید، GPU متوقف می‌شد که نتیجه آن درگیری پایین بود. همان‌طور که مایکروسافت در نسخه توسعه‌دهندگان خود در سال ۲۰۱۴ اشاره کرد، «Direct3D 12 به توسعه‌دهندگان اجازه می‌دهد تا بهره‌وری CPU را در بازی‌های خود به میزان قابل‌توجهی بهبود بخشند» و با تولید دستورات چندرشته‌ای، GPU را با دستورات تغذیه کنند.[5]

با این حال، تغذیه مداوم GPU به معنای پر کردن پورت‌های اجرایی آن نیست. این صرفاً به این معناست که GPU هرگز کاملاً به خواب نمی‌رود. یک کارت گرافیک که در حال اجرای یک سایه‌زن محاسباتی (compute shader) بسیار بهینه‌شده است و از تمام ALUهای خود استفاده می‌کند، وات بسیار بیشتری نسبت به همان GPU در حال اجرای یک بازی وابسته به حافظه مصرف می‌کند، حتی اگر هر دو به سیستم‌عامل درگیری ۱۰۰ درصدی را گزارش دهند.[2][4]

پیش از APIهای با سربار کم مانند DirectX 12، فراخوانی‌های ترسیم تک‌رشته‌ای CPU اغلب پردازنده‌های گرافیکی را در انتظار دستورات نگه می‌داشتند.

تولیدکنندگان سخت‌افزار به خوبی از این تناقض آگاهند. ابزارهای پروفایل گرافیکی Nsight شرکت NVIDIA معیارهای دقیقی مانند «SM Active» و «SM Issue» را در اختیار توسعه‌دهندگان قرار می‌دهند تا بین روشن بودن یک هسته و هسته‌ای که واقعاً در حال انجام محاسبات ریاضی است، تمایز قائل شوند؛ سطحی از جزئیات که در نرم‌افزارهای مانیتورینگ مصرف‌کننده کاملاً غایب است.[2]

برای مصرف‌کننده، نتیجه‌گیری این است که خوانش ۱۰۰ درصدی درگیری، شرطی لازم اما ناکافی برای حداکثر عملکرد است. این عدد تأیید می‌کند که CPU مانع کار کارت گرافیک نمی‌شود، اما تضمین نمی‌کند که کارت گرافیک در حد نهایی ظرفیت محاسباتی تئوری خود کار می‌کند. اشباع واقعی با وات مصرفی و نرخ فریم اندازه‌گیری می‌شود، نه با چرخه‌های کار.[1][6]

اصطلاحات کلیدی

چرخه کار (Duty Cycle)
درصد زمانی که یک قطعه در طول یک دوره اندازه‌گیری مشخص فعال یا روشن است، صرف‌نظر از اینکه چقدر کار انجام می‌دهد.
چندپردازنده جریانی (SM)
خوشه‌های مجزای هسته‌های پردازشی در داخل یک GPU که عملیات ریاضی را به صورت موازی اجرا می‌کنند.
فراخوانی ترسیم (Draw Call)
دستوری که از CPU به GPU ارسال می‌شود و به آن می‌گوید چه هندسه یا بافتی را در مرحله بعد رندر کند.
پهنای باند حافظه (Memory Bandwidth)
حداکثر سرعتی که یک پردازنده می‌تواند داده‌ها را از یک حافظه نیمه‌هادی بخواند یا در آن ذخیره کند.

پرسش‌های متداول

چرا گرافیک من ۱۰۰٪ را نشان می‌دهد اما نرخ فریم پایین است؟

ممکن است GPU شما بیشتر وقت خود را صرف انتظار برای دریافت داده‌ها از حافظه (VRAM) کند تا اینکه واقعاً فریم‌ها را محاسبه کند. در این حالت فعال است، اما سازنده نیست.

آیا درگیری ۱۰۰ درصدی GPU برای کامپیوتر من مضر است؟

خیر. این صرفاً به این معناست که GPU برای دریافت دستورات منتظر CPU نیست. این حالت ایده‌آل برای گیمینگ است، به شرطی که دما در محدوده ایمن باقی بماند.

چگونه بفهمم GPU من واقعاً به حداکثر ظرفیت خود رسیده است؟

میزان مصرف برق (وات) اغلب شاخص بهتری برای اشباع واقعی سخت‌افزار نسبت به درصد درگیری است. یک GPU کاملاً اشباع‌شده، برقی نزدیک به حداکثر حد مجاز خود مصرف می‌کند.

بررسی عمیق دیدگاه‌ها

دیدگاه مهندسی سخت‌افزار

مهندسان درگیری را معیاری ناقص می‌دانند که کارایی واقعی سیلیکون را پنهان می‌کند.

از منظر طراحی سخت‌افزار، یک GPU تنها زمانی واقعاً درگیر است که واحدهای منطقی-حسابی (ALU) آن در هر چرخه ساعت در حال اجرای ریاضیات باشند. مهندسان برای اندازه‌گیری نرخ‌های 'SM Issue' که دقیقاً تعداد دستورات در حال پردازش را ردیابی می‌کنند، به ابزارهای پروفایل سطح پایین متکی هستند. برای آن‌ها، پردازنده گرافیکی که درگیری ۱۰۰ درصدی را گزارش می‌دهد اما منتظر حافظه است، در حال تجربه یک گلوگاه است، نه دستیابی به اوج عملکرد. به همین دلیل است که پیشرفت‌های معماری مدرن به شدت بر افزایش اندازه حافظه پنهان (cache) تمرکز دارند تا داده‌ها را به هسته‌های پردازشی نزدیک‌تر نگه دارند و وقفه‌هایی را که خوانش‌های چرخه کار را متورم می‌کنند، به حداقل برسانند.

دیدگاه توسعه‌دهنده بازی

توسعه‌دهندگان بر تغذیه مداوم GPU با دستورات تمرکز می‌کنند تا از گلوگاه‌های CPU جلوگیری کنند.

برای برنامه‌نویسان موتور بازی، دیدن درگیری ۱۰۰ درصدی GPU عموماً یک موفقیت محسوب می‌شود زیرا نشان می‌دهد CPU با سرعت کافی فراخوانی‌های ترسیم را ارائه می‌دهد تا کارت گرافیک را مشغول نگه دارد. معرفی APIهای با سربار کم مانند DirectX 12 و Vulkan ناشی از نیاز به چندرشته‌ای کردن این فراخوانی‌های ترسیم بود. در حالی که توسعه‌دهندگان می‌دانند GPU ممکن است همچنان در واکشی حافظه متوقف شود، اطمینان از اینکه CPU عامل محدودکننده نیست، اولین و حیاتی‌ترین گام در بهینه‌سازی رندرینگ است.

دیدگاه عیب‌یابی مصرف‌کننده

سازندگان کامپیوتر از معیارهای درگیری به عنوان یک شاخص صفر و یکی برای تعادل سیستم استفاده می‌کنند.

در فضای مصرف‌کننده، درگیری ۱۰۰ درصدی GPU به عنوان استاندارد طلایی برای یک کامپیوتر گیمینگ متعادل در نظر گرفته می‌شود. اگر یک سیستم در طول بازی استفاده ۹۹٪ یا ۱۰۰٪ از GPU را گزارش دهد، علاقه‌مندان نتیجه می‌گیرند که پردازنده آن‌ها مناسب است و حداکثر نرخ فریم ممکن را از کارت گرافیک خود دریافت می‌کنند. اگرچه از نظر فنی این یک ساده‌سازی بیش از حد از نحوه عملکرد سخت‌افزار است، اما این رویکرد صفر و یکی همچنان کاربردی‌ترین راه برای مصرف‌کنندگان است تا تصمیم بگیرند آیا برای بهبود عملکرد نیاز به ارتقای CPU دارند یا GPU.

مهندسان سخت‌افزار 40%توسعه‌دهندگان بازی 30%علاقه‌مندان به کامپیوتر 30%
مهندسان سخت‌افزار
تمرکز بر اشباع فیزیکی چندپردازنده‌های جریانی و تمایز بین فعال بودن یک هسته در مقابل اجرای محاسبات ریاضی.
توسعه‌دهندگان بازی
اولویت دادن به سربار API، فراخوانی‌های ترسیم و بهینه‌سازی پهنای باند حافظه برای تغذیه مداوم GPU با دستورات.
علاقه‌مندان به کامپیوتر
تکیه بر معیارهای سطح سیستم‌عامل برای تشخیص گلوگاه‌های سیستم و تعیین مسیرهای ارتقای سخت‌افزار.

دیدگاه‌هایی که این گزارش پوشش نداده

  • توسعه‌دهندگان نرم‌افزارهای مانیتورینگ (Overlay)

منابع

پوشش منابع

7 منبع

3 دیدگاه شناسایی‌شده

مهندسان سخت‌افزار 40%توسعه‌دهندگان بازی 30%علاقه‌مندان به کامپیوتر 30%
  1. [1]Tech Guidedعلاقه‌مندان به کامپیوتر

    Why Is My GPU Utilization Low While Gaming?

    مطالعه در Tech Guided →
  2. [2]ArthurChiao's Blogمهندسان سخت‌افزار

    Understanding NVIDIA GPU Performance: Utilization vs. Saturation

    مطالعه در ArthurChiao's Blog →
  3. [3]arXivمهندسان سخت‌افزار

    ML Inference Scheduling with Predictable Latency

    مطالعه در arXiv →
  4. [4]Wccftechعلاقه‌مندان به کامپیوتر

    CPU or GPU Bottleneck? How to Diagnose What's Really Limiting Your Gaming Performance

    مطالعه در Wccftech →
  5. [5]Microsoft Developer Blogsتوسعه‌دهندگان بازی

    DirectX 12 - High Performance and High Power Savings

    مطالعه در Microsoft Developer Blogs →
  6. [6]HP® Official Siteعلاقه‌مندان به کامپیوتر

    What is PC Bottleneck and How Do I Prevent It?

    مطالعه در HP® Official Site →
  7. [7]تیم سردبیری کوهستان

    تحلیل تیم سردبیری کوهستان

    مطالعه در تیم سردبیری کوهستان →

نظرات

همیشه در جریان باشید

هر زاویه. هر روز.

اخبار فناوری با پوشش کامل منابع و تحلیل دیدگاه‌ها، هر روز و رایگان.