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

کارت گرافیک چیست؟ GPU چیست ؟ راهنمای جامع شناخت پردازنده گرافیکی


دانشنامه سخت‌افزار استوک‌شاپ

کارت گرافیک GPU چیست؟ راهنمای جامع معماری، عملکرد و کاربردهای GPU

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

GPU برای پردازش موازی حجم بزرگی از داده‌ها طراحی شده
و در اجرای بازی‌ها، رندر سه‌بعدی، تدوین ویدئو،
هوش مصنوعی، پردازش تصویر
و بسیاری از محاسبات حرفه‌ای استفاده می‌شود.

در این دانشنامه،
ساختار کارت گرافیک،
معماری GPU،
حافظه VRAM،
Graphics Pipeline،
Ray Tracing،
AI Acceleration،
توان مصرفی،
خنک‌کاری،
PCIe،
Display
و Software Stack
را از سطح پایه تا تحلیل عملکرد بررسی می‌کنیم.

معماری GPU
حافظه VRAM
Graphics Pipeline
Performance

خلاصه مقاله کارت گرافیک GPU

کارت گرافیک GPU در یک نگاه

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

  • GPU پردازنده اصلی انجام محاسبات گرافیکی و موازی است.
  • GPU می‌تواند مجتمع، مجزا یا بخشی از یک شتاب‌دهنده تخصصی باشد.
  • VRAM داده‌های موردنیاز GPU را در حافظه محلی نگهداری می‌کند.
  • عملکرد واقعی فقط به Core Count یا حجم VRAM وابسته نیست.
  • بازی، Rendering، Video Processing، AI و Compute از مهم‌ترین کاربردهای GPU هستند.


کارت گرافیک GPU چیست؟

کارت گرافیک یک مجموعه سخت‌افزاری برای پردازش داده‌های تصویری،
گرافیکی و بسیاری از محاسبات موازی است.
در کارت‌های گرافیک مجزا، این مجموعه معمولاً شامل
پردازنده گرافیکی، حافظه VRAM، مدار تغذیه،
برد مدار چاپی، سیستم خنک‌کننده و خروجی‌های تصویر است.

مهم‌ترین بخش این مجموعه
GPU
یا
Graphics Processing Unit
است.
GPU محاسبات اصلی مربوط به Rendering،
پردازش تصویر، تولید Frame
و بسیاری از Workloadهای موازی را انجام می‌دهد.

کارت گرافیک در کاربردهایی مانند اجرای بازی،
تدوین ویدئو، طراحی و مدل‌سازی سه‌بعدی،
Rendering، پردازش تصویر، شبیه‌سازی
و هوش مصنوعی استفاده می‌شود.

پردازش تصویر

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

تولید Frame

در بازی‌ها و محیط‌های سه‌بعدی،
GPU مجموعه‌ای از محاسبات را انجام می‌دهد
تا Frameهای متوالی برای نمایش آماده شوند.

محاسبات موازی

ساختار GPU برای اجرای حجم بزرگی از عملیات
به صورت موازی مناسب است و به همین دلیل
در بسیاری از Workloadهای حرفه‌ای نیز استفاده می‌شود.


آیا GPU همیشه روی یک کارت گرافیک جداگانه قرار دارد؟

خیر. پردازنده گرافیکی می‌تواند به صورت Integrated
داخل پردازنده یا SoC قرار داشته باشد،
یا به صورت یک GPU مجزا
روی کارت گرافیک مستقل استفاده شود.

بنابراین GPU و «کارت گرافیک»
دو مفهوم کاملاً یکسان نیستند.
GPU تراشه پردازشی است،
در حالی که کارت گرافیک
یک مجموعه سخت‌افزاری کامل‌تر است.


GPU چیست و چه کاری انجام می‌دهد؟

GPU
مخفف
Graphics Processing Unit
و به معنی «پردازنده گرافیکی» است.
GPU برای اجرای حجم بزرگی از عملیات
به صورت موازی طراحی شده است.

این ویژگی باعث می‌شود GPU در پردازش تصویر،
Rendering، تولید Frame، پردازش ویدئو،
محاسبات علمی و بسیاری از Workloadهای
هوش مصنوعی کارایی بالایی داشته باشد.

در مقایسه مفهومی با CPU،
GPU معمولاً منابع اجرایی موازی بیشتری دارد
و بیشتر روی
Throughput
تمرکز می‌کند؛
در حالی که CPU برای Workloadهای عمومی،
Control-heavy و اجرای وظایف متنوع طراحی شده است.


موازی


اجرای تعداد زیادی Work به صورت هم‌زمان

Throughput


تمرکز بر پردازش حجم زیادی از داده در واحد زمان

چندمنظوره


Graphics، Compute، AI و Video Processing

GPU چگونه داده را پردازش می‌کند؟

مرحله ۱

دریافت Work

Application، Engine، API و Driver
دستورها و داده‌های موردنیاز برای پردازش
را در اختیار GPU قرار می‌دهند.

مرحله ۲

تقسیم و زمان‌بندی کار

Work به واحدهای کوچک‌تر تقسیم می‌شود
تا منابع پردازشی GPU بتوانند
تعداد زیادی عملیات را به صورت موازی اجرا کنند.

مرحله ۳

پردازش

واحدهای مختلف GPU محاسبات گرافیکی،
Compute، Texture، Rasterization
یا سایر عملیات موردنیاز را انجام می‌دهند.

مرحله ۴

تولید نتیجه

نتیجه می‌تواند یک Frame،
داده پردازش‌شده، خروجی Compute
یا ورودی مرحله بعدی Pipeline باشد.


نکته مهم

GPU فقط برای نمایش تصویر نیست.
ساختار پردازش موازی آن باعث شده
در بسیاری از محاسبات غیرگرافیکی،
هوش مصنوعی، پردازش ویدئو
و Workloadهای حرفه‌ای نیز استفاده شود.



تفاوت GPU و کارت گرافیک چیست؟

اصطلاح‌های
GPU
و
کارت گرافیک
در گفت‌وگوی روزمره گاهی به جای یکدیگر استفاده می‌شوند،
اما از نظر فنی یک مفهوم نیستند.

GPU

GPU یا
Graphics Processing Unit
خودِ پردازنده گرافیکی است؛
یعنی تراشه‌ای که بخش اصلی محاسبات گرافیکی
و پردازش‌های موازی را انجام می‌دهد.

  • یک واحد پردازشی است.
  • می‌تواند Integrated یا Discrete باشد.
  • اجرای Shaderها و بسیاری از عملیات Compute را بر عهده دارد.
  • لزومی ندارد روی یک کارت گرافیک مستقل قرار داشته باشد.

کارت گرافیک

کارت گرافیک یک مجموعه سخت‌افزاری کامل‌تر است
که GPU یکی از مهم‌ترین اجزای آن محسوب می‌شود.

  • GPU را در خود جای می‌دهد.
  • معمولاً دارای VRAM اختصاصی است.
  • PCB و مدار تغذیه دارد.
  • از سیستم خنک‌کننده استفاده می‌کند.
  • می‌تواند دارای خروجی‌های تصویر و رابط PCIe باشد.
مقایسه GPU و کارت گرافیک
ویژگی GPU کارت گرافیک
ماهیت پردازنده گرافیکی مجموعه سخت‌افزاری
وظیفه اصلی انجام محاسبات فراهم‌کردن بستر کامل برای فعالیت GPU
حافظه از Memory System در دسترس خود استفاده می‌کند در مدل‌های مجزا معمولاً VRAM اختصاصی دارد
خنک‌کننده خود تراشه سیستم خنک‌کننده کامل نیست معمولاً Heatsink، Fan یا سایر راهکارهای Cooling دارد
شکل فیزیکی یک تراشه پردازشی برد و مجموعه‌ای از قطعات سخت‌افزاری


یک مثال ساده

می‌توان GPU را مانند «موتور» در نظر گرفت
و کارت گرافیک را مجموعه کامل‌تری دانست
که موتور، سیستم تغذیه، خنک‌کننده،
حافظه و سایر اجزای لازم را کنار هم قرار می‌دهد.


پس چرا معمولاً به کارت گرافیک می‌گوییم GPU؟

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

وظیفه کارت گرافیک چیست؟

وظیفه اصلی کارت گرافیک
پردازش داده‌های گرافیکی،
اجرای بخشی از محاسبات مرتبط با تصویر
و آماده‌سازی خروجی موردنیاز Application یا Display است.

در Workloadهای گرافیکی،
GPU می‌تواند
Geometry،
Texture،
Lighting،
Shading
و سایر داده‌های لازم برای تولید Frame
را پردازش کند.

در Workloadهای Compute نیز
GPU می‌تواند برای پردازش‌های موازی،
Video Processing،
Simulation
و AI استفاده شود.

تولید خروجی تصویر

کارت گرافیک
Frame یا تصویر پردازش‌شده را
برای Presentation
و در صورت وجود Display Output
برای نمایشگر آماده می‌کند.

اجرای بازی‌ها

GPU بخش بزرگی از محاسبات مربوط به
Geometry،
Shading،
Texture Sampling،
Lighting
و بسیاری از Effectهای تصویری بازی را انجام می‌دهد.

Rendering و طراحی سه‌بعدی

در نرم‌افزارهای سه‌بعدی،
GPU می‌تواند در نمایش Viewport،
پردازش Material و Texture
و بسته به موتور نرم‌افزار،
در Rendering نیز استفاده شود.

پردازش ویدئو

GPU می‌تواند در Decode،
Encode،
پردازش Effectها،
Color Processing
و برخی مراحل تدوین ویدئو نقش داشته باشد.

هوش مصنوعی

ماهیت موازی GPU
آن را برای بسیاری از عملیات موردنیاز
Machine Learning و AI مناسب می‌کند.

محاسبات عمومی

GPU فقط یک پردازنده مخصوص تصویر نیست
و می‌تواند برای Workloadهای محاسباتی موازی،
Simulation و پردازش داده نیز استفاده شود.


وظیفه GPU به نوع Workload بستگی دارد

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


کارت گرافیک GPU چگونه کار می‌کند؟

در یک مدل ساده،
Application و CPU
دستورها و داده‌های موردنیاز را آماده می‌کنند
و GPU بخش بزرگی از پردازش‌های گرافیکی
یا محاسبات موازی مناسب را انجام می‌دهد.

داده‌های موردنیاز GPU
می‌توانند شامل
Geometry،
Texture،
Buffer،
Lighting Data
و سایر Resourceهای مورد استفاده Workload باشند.

در کارت‌های گرافیک مجزا،
بخش بزرگی از این داده‌ها
در حافظه محلی GPU یا
VRAM
قرار می‌گیرند.

مرحله ۱

Application

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

مرحله ۲

CPU و Driver

CPU، API و Driver
در آماده‌سازی Commandها،
Resourceها و ارسال Work
به GPU نقش دارند.

مرحله ۳

GPU Processing

GPU عملیات موردنیاز را
با استفاده از واحدهای پردازشی
و Fixed-Function Hardware
اجرا می‌کند.

مرحله ۴

Memory

داده‌ها، Textureها، Bufferها
و نتایج میانی
بین GPU و Memory System
خوانده یا نوشته می‌شوند.

مرحله ۵

Output

نتیجه می‌تواند
Frame نهایی،
داده محاسباتی،
Video Output
یا ورودی مرحله بعدی پردازش باشد.

Graphics Pipeline در یک نگاه

Application / CPU
        │
        ▼
      Driver
        │
        ▼
   Commands + Data
        │
        ▼
       GPU
        │
   ┌────┴────┐
   ▼         ▼
Compute   Graphics
             │
             ▼
      Graphics Pipeline
             │
             ▼
           Frame
             │
             ▼
          Display


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

مسیر واقعی پردازش GPU
بسته به نوع Application،
Graphics API،
معماری GPU،
نوع Workload
و نحوه استفاده نرم‌افزار از سخت‌افزار
می‌تواند بسیار پیچیده‌تر باشد.


VRAM فقط محل ذخیره تصویر نهایی نیست

VRAM می‌تواند
Texture،
Geometry Data،
Bufferها،
Render Targetها
و انواع دیگری از داده‌های موردنیاز GPU
را نگهداری کند.



اجزای اصلی کارت گرافیک GPU

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

طراحی و هماهنگی این اجزا
می‌تواند بر Performance،
دمای کاری،
مصرف انرژی،
پایداری
و قابلیت حفظ فرکانس‌های کاری
تأثیر بگذارد.

پردازنده گرافیکی یا GPU

GPU
تراشه پردازشی اصلی کارت گرافیک است
و Workloadهای گرافیکی
و بسیاری از محاسبات موازی
روی آن اجرا می‌شوند.

حافظه گرافیکی یا VRAM

VRAM
حافظه محلی کارت گرافیک مجزا است
و داده‌هایی مانند
Texture،
Buffer،
Render Target
و سایر Resourceهای موردنیاز GPU
را نگهداری می‌کند.

برد مدار چاپی یا PCB

GPU،
تراشه‌های حافظه،
مدار تغذیه
و بسیاری از اجزای الکترونیکی کارت
روی PCB قرار می‌گیرند
و مسیرهای الکتریکی لازم
میان آن‌ها روی همین برد ایجاد می‌شود.

مدار تغذیه یا VRM

مدار تغذیه
ولتاژ و جریان موردنیاز GPU،
حافظه
و سایر بخش‌های کارت را
تأمین و تنظیم می‌کند.

سیستم خنک‌کننده

Heatsink،
Heat Pipe،
Fan
و سایر اجزای Cooling
حرارت تولیدشده توسط GPU
و بخش‌های دیگر کارت را دفع می‌کنند.

رابط‌های ارتباطی

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


چرا طراحی خود کارت گرافیک مهم است؟

دو کارت که از GPU مشابه استفاده می‌کنند
می‌توانند به دلیل تفاوت در
Cooling،
Power Delivery،
PCB Design
و تنظیمات فرکانسی،
رفتار حرارتی،
Noise
و Performance متفاوتی داشته باشند.


انواع کارت گرافیک GPU

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

برای جلوگیری از مخلوط شدن این معیارها،
در این بخش ابتدا سه شکل رایج پیاده‌سازی
یعنی گرافیک مجتمع،
کارت گرافیک مجزا
و GPU خارجی را بررسی می‌کنیم.
محصولات Gaming،
Workstation
و Data Center
دسته‌بندی کاربردی متفاوتی هستند
که در بخش‌های تخصصی‌تر بررسی می‌شوند.

گرافیک مجتمع یا Integrated GPU

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

  • مصرف انرژی معمولاً کمتر است.
  • فضای فیزیکی کمتری نیاز دارد.
  • برای بسیاری از کارهای روزمره و سبک مناسب است.
  • Performance آن به طراحی پردازنده و Memory System وابسته است.

کارت گرافیک مجزا یا Dedicated GPU

در این حالت،
GPU به صورت یک پردازنده گرافیکی مجزا
در سیستم استفاده می‌شود
و معمولاً حافظه گرافیکی اختصاصی دارد.

  • توان پردازشی و Memory Bandwidth بیشتری می‌تواند ارائه کند.
  • معمولاً VRAM اختصاصی دارد.
  • برای Gaming، Rendering و Workloadهای حرفه‌ای رایج است.
  • به توان و خنک‌کاری بیشتری نیاز دارد.

GPU خارجی یا eGPU

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

  • امکان افزودن GPU مجزا به برخی لپ‌تاپ‌ها را فراهم می‌کند.
  • نیازمند رابط و پشتیبانی سازگار است.
  • Performance می‌تواند تحت تأثیر پهنای باند اتصال قرار گیرد.
  • محفظه، منبع تغذیه و Cooling مستقل می‌تواند داشته باشد.
مقایسه کلی انواع پیاده‌سازی GPU
نوع محل GPU حافظه کاربرد کلی
Integrated داخل CPU یا SoC معمولاً Shared Memory روزمره، اداری و استفاده سبک
Dedicated GPU مجزا معمولاً VRAM اختصاصی Gaming و Workloadهای حرفه‌ای
External GPU محفظه خارجی VRAM اختصاصی کارت افزودن توان گرافیکی خارجی به سیستم سازگار


Gaming، Workstation و Data Center معیار دیگری هستند

این اصطلاح‌ها بیشتر به
بازار هدف و نوع Workload اشاره دارند؛
بنابراین نباید آن‌ها را مستقیماً
هم‌رده Integrated، Dedicated و eGPU
در نظر گرفت.



تفاوت گرافیک مجتمع و مجزا

یکی از مهم‌ترین تفاوت‌ها در سیستم‌های گرافیکی،
تفاوت میان
Integrated Graphics
و
Dedicated Graphics
است.

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

گرافیک مجتمع

  • معمولاً داخل CPU یا SoC قرار دارد.
  • اغلب از حافظه اصلی سیستم استفاده می‌کند.
  • مصرف انرژی و تولید حرارت معمولاً کمتر است.
  • فضای فیزیکی کمتری نیاز دارد.
  • برای کارهای روزمره، اداری و بسیاری از Workloadهای سبک مناسب است.

گرافیک مجزا

  • دارای GPU مجزا است.
  • معمولاً VRAM اختصاصی دارد.
  • توان پردازشی و Memory Bandwidth بیشتری می‌تواند ارائه کند.
  • مصرف انرژی و نیاز به Cooling معمولاً بیشتر است.
  • برای Gaming، Rendering و بسیاری از Workloadهای حرفه‌ای مناسب‌تر است.
مقایسه گرافیک مجتمع و گرافیک مجزا
ویژگی گرافیک مجتمع گرافیک مجزا
محل GPU معمولاً داخل CPU یا SoC GPU مجزا
حافظه معمولاً Shared System Memory معمولاً VRAM اختصاصی
مصرف انرژی معمولاً کمتر معمولاً بیشتر
خنک‌کاری وابسته به طراحی کلی سیستم معمولاً نیازمند Cooling قوی‌تر
توان گرافیکی وابسته به معماری و Memory System معمولاً ظرفیت Performance بالاتر
کاربرد رایج روزمره، اداری و سبک Gaming، Rendering و کار حرفه‌ای


آیا همه کاربران به کارت گرافیک مجزا نیاز دارند؟

خیر.
برای وب‌گردی،
پخش ویدئو،
کارهای اداری
و بسیاری از استفاده‌های سبک،
Integrated Graphics
می‌تواند کافی باشد.

کارت گرافیک مجزا
بیشتر زمانی اهمیت پیدا می‌کند
که Workload به
Compute،
VRAM،
Graphics Performance
یا Featureهای تخصصی بیشتری نیاز داشته باشد.


Performance فقط به GPU وابسته نیست

عملکرد نهایی
می‌تواند به CPU،
RAM،
Storage،
Driver،
Software،
Power،
Cooling
و نوع Workload نیز وابسته باشد.

بنابراین ضعیف بودن Performance
همیشه به معنی ضعیف بودن کارت گرافیک نیست.

مشخصات فنی کارت گرافیک

برای مقایسه کارت‌های گرافیک
نباید فقط به یک عدد مانند
حجم VRAM،
فرکانس
یا تعداد Coreها توجه کرد.
عملکرد واقعی حاصل ترکیب
معماری GPU،
منابع پردازشی،
Memory System،
توان،
Cooling
و Software است.

معماری GPU

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

تعداد واحدهای پردازشی

CUDA Core،
Stream Processor،
Execution Unit
و نام‌های مشابه
به منابع اجرایی معماری‌های مختلف اشاره دارند.
مقایسه مستقیم این اعداد بین معماری‌های متفاوت
همیشه معتبر نیست.

فرکانس GPU

Clock Speed یکی از عوامل مؤثر بر Performance است،
اما مقدار Performance نهایی
فقط از روی فرکانس قابل تعیین نیست.

حافظه VRAM

VRAM داده‌های موردنیاز GPU را نگهداری می‌کند.
ظرفیت حافظه اهمیت دارد،
اما نوع حافظه،
پهنای Bus
و Bandwidth نیز مهم هستند.

Memory Bus

عرض رابط حافظه یکی از عوامل مؤثر
بر مقدار داده‌ای است
که می‌تواند میان GPU و VRAM جابه‌جا شود.

Memory Bandwidth

Bandwidth نشان می‌دهد
Memory System در شرایط نظری
چه حجمی از داده را در واحد زمان
می‌تواند منتقل کند.

توان مصرفی

Power Limit و مشخصات توان
بر نیاز منبع تغذیه،
حرارت
و رفتار فرکانسی کارت تأثیر دارند.

سیستم خنک‌کننده

طراحی Cooling
در دمای کاری،
Noise
و توانایی کارت برای حفظ Performance
در بارهای طولانی مؤثر است.

رابط PCIe

PCI Express
مسیر ارتباط کارت گرافیک
با سایر بخش‌های سیستم را فراهم می‌کند.
نسل PCIe و تعداد Laneها
بر پهنای باند این ارتباط اثر می‌گذارند.

مشخصات مهم هنگام بررسی کارت گرافیک
مشخصه چه چیزی را نشان می‌دهد؟
GPU Architecture ساختار و قابلیت‌های نسل پردازنده گرافیکی
Core / Execution Resources بخشی از ظرفیت پردازش موازی GPU
Clock فرکانس فعالیت بخش‌هایی از GPU
VRAM Capacity ظرفیت حافظه محلی در دسترس GPU
Memory Type فناوری حافظه مورد استفاده
Memory Bus عرض رابط حافظه
Memory Bandwidth ظرفیت انتقال داده Memory System
Power نیاز و محدودیت‌های انرژی کارت
Cooling توانایی دفع حرارت و حفظ شرایط کاری مناسب
PCIe رابط ارتباطی GPU با سیستم


اشتباه رایج: مقایسه GPU فقط با یک مشخصه

حجم بیشتر VRAM،
Core Count بالاتر
یا Clock بیشتر
به تنهایی تضمین نمی‌کند
که یک GPU در همه Workloadها سریع‌تر باشد.

مقایسه درست باید
معماری،
Memory System،
Software،
Power،
Cooling
و مهم‌تر از همه
نوع کاربرد واقعی را هم در نظر بگیرد.


برندهای کارت گرافیک

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

امروزه سه شرکت اصلی پردازنده‌های گرافیکی دسکتاپ را
تولید می‌کنند:
NVIDIA،
AMD
و
Intel.
سپس شرکت‌هایی مانند ASUS، MSI، Gigabyte، ZOTAC،
Sapphire، PowerColor، XFX، PNY و سایر تولیدکنندگان،
کارت نهایی را بر پایه همین GPUها طراحی و عرضه می‌کنند.

NVIDIA

NVIDIA یکی از بزرگ‌ترین تولیدکنندگان پردازنده‌های
گرافیکی جهان است و محصولات آن در بازارهای
گیمینگ، ورک‌استیشن، هوش مصنوعی، دیتاسنتر،
رندرینگ و پردازش‌های علمی استفاده می‌شوند.

معروف‌ترین خانواده‌های این شرکت شامل
GeForce،
RTX Professional
(Quadro سابق)
و شتاب‌دهنده‌های دیتاسنتری هستند.

AMD

AMD نیز یکی از مهم‌ترین تولیدکنندگان GPU است.
محصولات این شرکت در بازار مصرف‌کننده، ورک‌استیشن
و مراکز پردازشی حضور گسترده‌ای دارند.

خانواده Radeon برای کاربران عمومی و گیمرها و
Radeon Pro برای بسیاری از کاربران حرفه‌ای طراحی
شده است.

Intel

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

محصولات Arc در برخی بازی‌ها، تولید محتوا،
رمزگذاری ویدئو و کاربردهای عمومی عملکرد مناسبی
ارائه می‌کنند.

تفاوت NVIDIA و GeForce چیست؟

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

تفاوت Quadro و GeForce

خانواده GeForce برای اجرای بازی، استفاده روزمره،
تولید محتوا و بسیاری از کاربردهای عمومی طراحی شده است.

در مقابل، کارت‌های
Quadro
که امروزه با نام
NVIDIA RTX Professional
شناخته می‌شوند،
بیشتر برای ایستگاه‌های کاری، نرم‌افزارهای CAD،
طراحی صنعتی، مدل‌سازی سه‌بعدی، انیمیشن،
شبیه‌سازی و پروژه‌های مهندسی توسعه یافته‌اند.

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


آیا Quadro از GeForce قوی‌تر است؟

همیشه خیر.
اگر هدف اجرای بازی باشد،
معمولاً کارت‌های GeForce هم‌رده ارزش خرید بیشتری
دارند؛ اما در بسیاری از نرم‌افزارهای حرفه‌ای،
مزیت Quadro و RTX Professional به دلیل درایورهای
تخصصی و پایداری بیشتر مشخص می‌شود.

تفاوت Radeon و Radeon Pro

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

Radeon Pro برای محیط‌های حرفه‌ای، طراحی صنعتی،
معماری، مدل‌سازی سه‌بعدی و برخی نرم‌افزارهای تخصصی
عرضه می‌شود و مانند کارت‌های حرفه‌ای NVIDIA،
تمرکز بیشتری بر پایداری و سازگاری نرم‌افزاری دارد.

شرکت‌های سازنده کارت گرافیک

GPU توسط NVIDIA، AMD یا Intel طراحی می‌شود؛ اما
بسیاری از کارت‌های موجود در بازار توسط شرکت‌های
دیگری تولید می‌شوند.

تفاوت سازنده GPU و سازنده کارت گرافیک
نوع شرکت نمونه‌ها وظیفه
سازنده GPU NVIDIA، AMD، Intel طراحی پردازنده گرافیکی و معماری
سازنده کارت ASUS، MSI، Gigabyte،
ZOTAC، Sapphire،
PowerColor، XFX،
PNY و …
طراحی برد، سیستم خنک‌کننده،
مدار تغذیه و تولید کارت نهایی

آیا دو کارت با GPU یکسان عملکرد یکسانی دارند؟

خیر.
حتی اگر دو کارت از یک GPU استفاده کنند،
ممکن است به دلیل تفاوت در طراحی سیستم خنک‌کننده،
کیفیت مدار تغذیه، محدودیت توان،
فرکانس کارخانه‌ای،
ابعاد هیت‌سینک و کیفیت ساخت،
عملکرد و دمای متفاوتی داشته باشند.


هنگام انتخاب برند به چه مواردی توجه کنیم؟

کیفیت سیستم خنک‌کننده، میزان نویز،
خدمات پس از فروش،
کیفیت مدار تغذیه،
گارانتی،
ابعاد کارت،
نسخه BIOS
و کیفیت ساخت معمولاً از لوگوی روی جعبه مهم‌تر هستند.


برند مشهور همیشه بهترین انتخاب نیست

هر شرکت ممکن است مدل‌های اقتصادی،
میان‌رده و حرفه‌ای تولید کند.
بنابراین بهتر است مدل دقیق کارت،
بررسی‌های تخصصی و نتایج آزمون عملکرد همان محصول
را ملاک تصمیم‌گیری قرار دهید.

حافظه گرافیکی (VRAM) چیست؟

حافظه گرافیکی یا
Video Random Access Memory (VRAM)
نوعی حافظه پرسرعت است که به صورت اختصاصی در اختیار
پردازنده گرافیکی قرار دارد و داده‌های موردنیاز GPU را
برای پردازش تصاویر، بازی‌ها، مدل‌های سه‌بعدی، ویدئوها،
بافت‌ها و محاسبات گرافیکی ذخیره می‌کند.

برخلاف حافظه RAM که میان پردازنده مرکزی و سایر بخش‌های
سیستم مشترک است، VRAM معمولاً فقط توسط GPU استفاده
می‌شود تا داده‌ها با کمترین تأخیر در اختیار پردازنده
گرافیکی قرار بگیرند.

ذخیره بافت‌ها

Textureها، تصاویر و جزئیات سطوح اجسام سه‌بعدی
داخل VRAM نگهداری می‌شوند تا GPU بتواند به سرعت
آن‌ها را پردازش کند.

ذخیره مدل‌های سه‌بعدی

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

نگهداری Frame Buffer

فریم‌های تولیدشده توسط GPU قبل از ارسال به
نمایشگر در حافظه گرافیکی ذخیره می‌شوند.

پردازش ویدئو

هنگام تدوین یا پخش ویدئوهای با وضوح بالا،
بخشی از داده‌های تصویری در VRAM قرار می‌گیرد تا
پردازش سریع‌تر انجام شود.

پردازش هوش مصنوعی

بسیاری از مدل‌های هوش مصنوعی، داده‌ها و وزن‌های
شبکه عصبی را هنگام اجرا در حافظه گرافیکی نگهداری
می‌کنند.

رندر سه‌بعدی

در پروژه‌های سنگین معماری، انیمیشن و جلوه‌های
ویژه، حجم بزرگی از اطلاعات داخل VRAM ذخیره
می‌شود.

VRAM چگونه کار می‌کند؟

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

اگر این اطلاعات مستقیماً از RAM سیستم خوانده شوند،
سرعت پردازش کاهش پیدا می‌کند؛ بنابراین داده‌هایی که
بیشترین استفاده را دارند داخل VRAM ذخیره می‌شوند تا
دسترسی GPU به آن‌ها بسیار سریع‌تر باشد.

آیا VRAM بیشتر همیشه بهتر است؟

خیر.

ظرفیت بالاتر VRAM تنها زمانی مفید است که نرم‌افزار،
بازی یا پروژه واقعاً به آن مقدار حافظه نیاز داشته
باشد.

برای مثال ممکن است یک کارت با ۸ گیگابایت حافظه،
به دلیل GPU قوی‌تر، از کارتی با ۱۲ گیگابایت حافظه
عملکرد بهتری ارائه کند.


مهم‌ترین نکته درباره VRAM

ظرفیت حافظه فقط نشان می‌دهد چه مقدار داده می‌تواند
در حافظه گرافیکی قرار گیرد؛ اما سرعت اجرای برنامه
همچنان به قدرت GPU، معماری، پهنای باند حافظه،
نوع حافظه و بهینه‌سازی نرم‌افزار بستگی دارد.

کمبود VRAM چه مشکلاتی ایجاد می‌کند؟

  • افت نرخ فریم در بازی‌ها
  • بارگذاری دیرهنگام بافت‌ها
  • ایجاد مکث یا Stutter
  • کاهش کیفیت Textureها
  • کند شدن رندر پروژه‌های سه‌بعدی
  • کاهش سرعت برخی مدل‌های هوش مصنوعی
  • انتقال مداوم داده میان RAM و VRAM

چه عواملی مصرف VRAM را افزایش می‌دهند؟

عوامل مؤثر بر مصرف حافظه گرافیکی
عامل میزان تأثیر دلیل
وضوح تصویر بسیار زیاد فریم‌های بزرگ‌تر به حافظه بیشتری نیاز دارند.
کیفیت Texture بسیار زیاد بافت‌های حجیم فضای بیشتری اشغال می‌کنند.
مدل‌های سه‌بعدی زیاد تعداد Polygon و Mesh افزایش می‌یابد.
Ray Tracing زیاد داده‌های بیشتری برای محاسبات نوری لازم است.
هوش مصنوعی بسیار زیاد وزن مدل‌ها و داده‌های پردازشی در حافظه قرار می‌گیرند.

VRAM در کارت‌های Quadro و RTX Professional

یکی از تفاوت‌های مهم بسیاری از کارت‌های حرفه‌ای مانند
NVIDIA Quadro
و
RTX Professional
ظرفیت بالاتر حافظه گرافیکی نسبت به بسیاری از مدل‌های
گیمینگ است.

پروژه‌های CAD، مدل‌سازی صنعتی، انیمیشن‌های پیچیده،
شبیه‌سازی، اسکن سه‌بعدی، پروژه‌های BIM، تدوین فیلم‌های
سنگین و برخی مدل‌های هوش مصنوعی ممکن است به حجم زیادی
از VRAM نیاز داشته باشند.

به همین دلیل در برخی ورک‌استیشن‌ها مشاهده می‌شود که
ظرفیت حافظه گرافیکی حتی به چند ده گیگابایت نیز می‌رسد؛
موضوعی که برای بسیاری از کاربران خانگی ضرورتی ندارد.


برای خرید فقط به عدد گیگابایت نگاه نکنید

ابتدا نرم‌افزار یا بازی موردنظر خود را بررسی کنید،
سپس ظرفیت VRAM، نوع حافظه، پهنای باند، معماری GPU و
قدرت پردازشی کارت را در کنار یکدیگر مقایسه کنید.


ظرفیت زیاد حافظه، ضعف GPU را جبران نمی‌کند

کارت گرافیکی که GPU ضعیفی دارد، حتی اگر حافظه زیادی
داشته باشد، الزاماً عملکرد بهتری نسبت به یک GPU
قدرتمند با حافظه کمتر ارائه نخواهد کرد.

انواع حافظه گرافیکی؛ از GDDR3 تا GDDR6X، HBM و ECC

حافظه گرافیکی فقط با عدد ظرفیت آن، مانند ۲، ۴، ۸ یا
۱۶ گیگابایت شناخته نمی‌شود. نوع حافظه، فرکانس مؤثر،
پهنای رابط، پهنای باند، مصرف برق و نحوه اتصال آن به GPU
نیز بر عملکرد واقعی کارت گرافیک اثر می‌گذارند.

در کارت‌های گرافیک قدیمی‌تر، لپ‌تاپ‌های استوک و
ورک‌استیشن‌های نسل قبل ممکن است با حافظه‌هایی مانند
DDR2، DDR3، GDDR3 و GDDR5 روبه‌رو شویم؛ در حالی که
کارت‌های جدیدتر بیشتر از GDDR6، GDDR6X یا حافظه‌های
خانواده HBM استفاده می‌کنند.


تفاوت DDR و GDDR چیست؟

حافظه‌های DDR عمدتاً برای حافظه اصلی سیستم طراحی
شده‌اند، اما GDDR برای انتقال حجم بالای داده‌های
گرافیکی بهینه شده است. بااین‌حال برخی کارت‌های
اقتصادی و لپ‌تاپ‌های قدیمی از حافظه‌های DDR2 یا
DDR3 نیز به‌عنوان حافظه گرافیکی اختصاصی استفاده
می‌کنند.

چرا نوع حافظه گرافیکی مهم است؟

نوع حافظه بر سرعت انتقال داده میان GPU و VRAM،
پهنای باند، مصرف انرژی و عملکرد کارت در وضوح‌های بالا،
بازی، رندر، تدوین و پردازش‌های حرفه‌ای تأثیر می‌گذارد.

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

حافظه DDR2

DDR2 در برخی کارت‌های بسیار قدیمی و اقتصادی
استفاده می‌شد. این حافظه پهنای باند محدودی دارد
و برای بازی‌ها یا نرم‌افزارهای امروزی انتخاب
مناسبی نیست.

مدل‌هایی از خانواده‌های قدیمی
GeForce 8، GeForce 9 و Radeon HD ممکن است در
برخی نسخه‌ها از DDR2 استفاده کرده باشند.

حافظه DDR3

DDR3 در کارت‌های اقتصادی و لپ‌تاپ‌های قدیمی
بسیار رایج بود. این حافظه نسبت به DDR2 سریع‌تر
است، اما معمولاً از GDDR5 پهنای باند کمتری دارد.

کارت‌هایی مانند برخی نسخه‌های
GeForce GT 610، GT 620، GT 710، GT 730،
GT 740M، Radeon HD 7470 و مدل‌های مشابه ممکن
است با DDR3 عرضه شده باشند.

حافظه GDDR3

GDDR3 یکی از حافظه‌های پرکاربرد در کارت‌های
گرافیک دهه‌های گذشته بود و در بسیاری از مدل‌های
دسکتاپ، لپ‌تاپ و ورک‌استیشن استفاده شد.

کارت‌هایی مانند GeForce 9600 GT،
9800 GT، GT 240، برخی نسخه‌های GT 630،
Quadro FX و بعضی کارت‌های Radeon قدیمی از
نمونه‌های شناخته‌شده این دوره هستند.

حافظه GDDR5

GDDR5 سال‌ها حافظه اصلی کارت‌های گرافیک
میان‌رده و قدرتمند بود و هنوز در بسیاری از
لپ‌تاپ‌ها، سیستم‌های استوک و کارت‌های دست‌دوم
دیده می‌شود.

مدل‌هایی مانند GTX 750 Ti، GTX 950،
GTX 960، GTX 1050، GTX 1050 Ti،
GTX 1060، GTX 1650، RX 460، RX 470،
RX 570 و RX 580 معمولاً از GDDR5 استفاده
می‌کنند.

حافظه GDDR5X

GDDR5X نسخه سریع‌تر GDDR5 بود و بیشتر در برخی
کارت‌های رده‌بالای نسل Pascal استفاده شد.

کارت‌هایی مانند GTX 1080، GTX 1080 Ti و
Titan Xp از نمونه‌های مشهور مجهز به GDDR5X
هستند.

حافظه GDDR6

GDDR6 در بسیاری از کارت‌های جدیدتر NVIDIA،
AMD و Intel استفاده می‌شود و نسبت به GDDR5
سرعت بالاتر و بهره‌وری انرژی بهتری دارد.

کارت‌هایی مانند GTX 1650 GDDR6،
GTX 1660 Super، RTX 2060، RTX 3060،
RTX 4060، RX 5600 XT، RX 6600،
RX 7600 و Intel Arc از این نوع حافظه استفاده
می‌کنند.

حافظه GDDR6X

GDDR6X برای دستیابی به نرخ انتقال بالاتر طراحی
شده و در برخی کارت‌های قدرتمند NVIDIA استفاده
می‌شود.

مدل‌هایی مانند RTX 3080، RTX 3090،
RTX 4070 Ti Super، RTX 4080 و RTX 4090
از نمونه‌های شناخته‌شده دارای GDDR6X هستند.

حافظه HBM

HBM یا High Bandwidth Memory از ساختاری متفاوت
نسبت به GDDR استفاده می‌کند و تراشه‌های حافظه
را با فاصله بسیار کم در کنار GPU قرار می‌دهد.

این طراحی امکان دستیابی به پهنای باند بسیار بالا
با رابط حافظه عریض را فراهم می‌کند.

حافظه ECC

ECC قابلیتی برای شناسایی و اصلاح برخی خطاهای
حافظه است. این ویژگی بیشتر در کارت‌های حرفه‌ای،
ورک‌استیشن‌ها، دیتاسنترها و پردازش‌های حساس
اهمیت دارد.

برخی مدل‌های Quadro، NVIDIA RTX Professional،
Tesla، Radeon Pro و شتاب‌دهنده‌های محاسباتی
دارای پشتیبانی ECC هستند.

حافظه DDR3 در کارت‌های گرافیک قدیمی

در بازار لپ‌تاپ و قطعات استوک هنوز تعداد زیادی کارت یا
GPU با حافظه DDR3 وجود دارد. این حافظه در زمان خود برای
کارهای عمومی، پخش ویدئو، نرم‌افزارهای سبک و بازی‌های
قدیمی مناسب بود، اما در مقایسه با GDDR5 پهنای باند
بسیار محدودتری دارد.

برای نمونه، ممکن است دو نسخه از یک مدل مانند
GeForce GT 730 وجود داشته باشد که یکی از DDR3 و دیگری
از GDDR5 استفاده کند. نسخه GDDR5 معمولاً عملکرد بهتری
دارد، حتی اگر ظرفیت حافظه آن کمتر باشد.


نام یکسان، حافظه متفاوت

برخی کارت‌های قدیمی با یک نام تجاری، در نسخه‌های
متفاوت DDR3 و GDDR5 عرضه شده‌اند. بنابراین هنگام
خرید کارت دست‌دوم یا بررسی لپ‌تاپ قدیمی، نوع حافظه،
عرض باس و کد دقیق GPU را کنترل کنید.

نمونه کارت‌ها و لپ‌تاپ‌های قدیمی با حافظه DDR3

  • NVIDIA GeForce GT 610
  • NVIDIA GeForce GT 620
  • برخی نسخه‌های GeForce GT 630
  • برخی نسخه‌های GeForce GT 710
  • برخی نسخه‌های GeForce GT 730
  • NVIDIA GeForce GT 720M
  • NVIDIA GeForce GT 730M
  • برخی نسخه‌های GeForce GT 740M
  • AMD Radeon HD 7470
  • برخی مدل‌های Radeon HD 8000M
  • برخی کارت‌های قدیمی Quadro سری NVS و FX

GDDR5؛ حافظه رایج در لپ‌تاپ‌ها و کارت‌های استوک

GDDR5 یکی از مهم‌ترین حافظه‌ها برای بازار فعلی محصولات
استوک و لپ‌تاپ‌های چند نسل قبل است. تعداد زیادی از
لپ‌تاپ‌های گیمینگ، مهندسی و ورک‌استیشن هنوز از GPUهایی
با حافظه GDDR5 استفاده می‌کنند.

مدل‌هایی مانند GTX 850M، GTX 860M، GTX 950M،
GTX 960M، GTX 965M، GTX 970M، GTX 980M،
GTX 1050 Laptop، GTX 1050 Ti Laptop،
GTX 1060 Laptop، MX150 و برخی نسخه‌های MX250
از نمونه‌های شناخته‌شده هستند.

در لپ‌تاپ‌های ورک‌استیشن نیز کارت‌هایی مانند
Quadro K2100M، K3100M، K4100M، M1000M،
M2000M، M3000M، P1000، P2000 و P3200
در بسیاری از مدل‌ها از حافظه GDDR5 استفاده می‌کنند.

HBM، HBM2 و HBM3

حافظه HBM با قرار دادن چند لایه حافظه روی یکدیگر و
اتصال آن‌ها از طریق مسیرهای بسیار کوتاه، پهنای باند
بسیار زیادی ایجاد می‌کند.

نسل نخست HBM در کارت‌هایی مانند AMD Radeon R9 Fury
استفاده شد. HBM2 در محصولاتی مانند Radeon Vega،
Radeon VII، برخی کارت‌های Radeon Pro،
NVIDIA Tesla و Quadro GP100 دیده می‌شود.

نسل‌های جدیدتر مانند HBM2e و HBM3 بیشتر در
شتاب‌دهنده‌های دیتاسنتر، هوش مصنوعی و پردازش‌های
محاسباتی بسیار سنگین استفاده می‌شوند.

مقایسه نسل‌های مهم حافظه گرافیکی
نوع حافظه دوره استفاده رایج نمونه محصولات کاربرد معمول
DDR2 کارت‌های بسیار قدیمی برخی GeForce و Radeon اقتصادی قدیمی کارهای عمومی و نمایش تصویر
DDR3 کارت‌ها و لپ‌تاپ‌های اقتصادی قدیمی GT 610، GT 710، برخی GT 730 کاربری عمومی و بازی‌های سبک
GDDR3 نسل‌های قدیمی دسکتاپ و ورک‌استیشن 9600 GT، 9800 GT، Quadro FX بازی و طراحی نسل‌های قدیمی
GDDR5 چندین نسل از کارت‌های قدیمی و میان‌رده GTX 1050 Ti، GTX 1060، RX 580،
Quadro P2000
بازی، طراحی، رندر و ورک‌استیشن
GDDR5X کارت‌های رده‌بالای Pascal GTX 1080، GTX 1080 Ti بازی و پردازش سنگین
GDDR6 کارت‌های مدرن مصرف‌کننده و حرفه‌ای RTX 2060، RTX 3060، RX 6600،
Intel Arc
بازی، تولید محتوا و پردازش حرفه‌ای
GDDR6X برخی کارت‌های قدرتمند جدید NVIDIA RTX 3080، RTX 3090، RTX 4090 بازی سنگین، رندر و هوش مصنوعی
HBM و HBM2 کارت‌های تخصصی و رده‌بالا R9 Fury، Radeon VII، Quadro GP100 پردازش حرفه‌ای و محاسباتی
HBM3 شتاب‌دهنده‌های جدید دیتاسنتر شتاب‌دهنده‌های هوش مصنوعی و HPC مدل‌های بزرگ هوش مصنوعی و محاسبات علمی

حافظه ECC چیست؟

عبارت ECC مخفف
Error-Correcting Code
است. حافظه ECC می‌تواند برخی خطاهای تصادفی داده را
شناسایی و اصلاح کند.

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

به همین دلیل برخی کارت‌های NVIDIA Quadro،
NVIDIA RTX Professional، Tesla، Radeon Pro و
شتاب‌دهنده‌های دیتاسنتری از ECC پشتیبانی می‌کنند.


ECC فقط برای افزایش سرعت نیست

هدف اصلی ECC افزایش اطمینان و صحت داده‌ها است، نه
افزایش مستقیم نرخ فریم یا سرعت رندر. این قابلیت در
پروژه‌هایی ارزشمند است که یک خطای کوچک می‌تواند
نتیجه محاسبه یا فایل خروجی را خراب کند.

حافظه کارت‌های Quadro و RTX Professional

کارت‌های حرفه‌ای قدیمی Quadro از انواع متنوع حافظه
استفاده می‌کردند. برای مثال مدل‌های Quadro FX و
Quadro K در نسل‌های مختلف با GDDR3 یا GDDR5 عرضه
شدند، در حالی که بسیاری از کارت‌های Quadro M و
Quadro P از GDDR5 استفاده می‌کنند.

در نسل Quadro RTX و NVIDIA RTX A Series استفاده از
GDDR6 رایج‌تر شد. برخی مدل‌های حرفه‌ای همچنین ظرفیت
حافظه بیشتر، پشتیبانی ECC یا قابلیت‌های ویژه برای
پروژه‌های CAD، شبیه‌سازی و تولید محتوای سنگین دارند.

برای نرم‌افزارهایی مانند AutoCAD، SolidWorks،
CATIA، Maya و نرم‌افزارهای مهندسی، نوع حافظه تنها یکی
از معیارها است. درایور حرفه‌ای، تأییدیه ISV، قدرت GPU
و ظرفیت VRAM نیز باید بررسی شوند.

آیا GDDR6 همیشه از GDDR5 بهتر است؟

از نظر فناوری حافظه، GDDR6 معمولاً سرعت و بهره‌وری
بالاتری دارد؛ اما این موضوع به‌تنهایی ثابت نمی‌کند که
یک کارت GDDR6 از هر کارت GDDR5 سریع‌تر است.

برای نمونه، یک کارت قدرتمند قدیمی با GDDR5 ممکن است
از یک کارت اقتصادی جدید با GDDR6 عملکرد بیشتری داشته
باشد. قدرت تراشه، تعداد واحدهای پردازشی، پهنای باس،
محدودیت توان و معماری باید در کنار نوع حافظه سنجیده
شوند.

چگونه نوع حافظه کارت گرافیک را تشخیص دهیم؟

  1. مدل دقیق کارت یا GPU را در مشخصات سازنده بررسی کنید.
  2. از ابزارهای شناسایی سخت‌افزار مانند GPU-Z یا
    نرم‌افزارهای اطلاعات سیستم استفاده کنید.
  3. در لپ‌تاپ، کد دقیق مدل دستگاه و GPU را بررسی کنید؛
    زیرا یک لپ‌تاپ ممکن است با چند پیکربندی متفاوت عرضه
    شده باشد.
  4. فقط به مقدار حافظه نمایش‌داده‌شده در ویندوز اعتماد
    نکنید؛ زیرا حافظه اشتراکی سیستم نیز ممکن است در آن
    عدد محاسبه شده باشد.


حافظه اشتراکی را با VRAM واقعی اشتباه نگیرید

در گرافیک‌های مجتمع، بخشی از RAM سیستم به GPU
اختصاص داده می‌شود. برخی صفحات مشخصات یا ابزارهای
سیستم ممکن است مجموع حافظه اختصاصی و اشتراکی را
نمایش دهند؛ این عدد به معنی وجود همان مقدار VRAM
پرسرعت روی کارت نیست.

برای لپ‌تاپ قدیمی کدام نوع حافظه مناسب‌تر است؟

در لپ‌تاپ‌های قدیمی معمولاً امکان تعویض مستقیم GPU یا
حافظه گرافیکی وجود ندارد؛ بنابراین باید عملکرد همان
ترکیب موجود را ارزیابی کرد.

برای کاربری عمومی و نرم‌افزارهای سبک، DDR3 ممکن است
کافی باشد. برای بازی‌های قدیمی، طراحی سه‌بعدی سبک و
نرم‌افزارهای گرافیکی، مدل‌های مجهز به GDDR5 معمولاً
گزینه بهتری هستند.

در لپ‌تاپ‌های ورک‌استیشن قدیمی، یک Quadro با GDDR5 و
درایور حرفه‌ای ممکن است برای SolidWorks یا CAD مناسب‌تر
از یک GPU گیمینگ هم‌رده باشد؛ هرچند برای بازی معمولاً
برتری با مدل گیمینگ است.

راهنمای کلی انتخاب حافظه در سیستم‌های قدیمی
نوع کاربرد حافظه قابل قبول پیشنهاد بهتر
استفاده اداری و اینترنت DDR3 یا گرافیک مجتمع SSD و RAM کافی معمولاً مهم‌تر است
پخش ویدئو DDR3 یا GDDR3 پشتیبانی سخت‌افزاری کدک بررسی شود
بازی‌های قدیمی GDDR3 GDDR5 معمولاً انتخاب مناسب‌تری است
طراحی و CAD سبک GDDR5 با حداقل ۲ گیگابایت Quadro یا Radeon Pro سازگار با نرم‌افزار
رندر سه‌بعدی GDDR5 با ظرفیت کافی GDDR6 و VRAM بیشتر
هوش مصنوعی نوع حافظه به‌تنهایی کافی نیست VRAM بیشتر و پشتیبانی نرم‌افزاری مناسب


معیار درست برای مقایسه

ظرفیت VRAM، نوع حافظه، پهنای باند، عرض باس و قدرت
GPU را در کنار هم بررسی کنید. مقایسه فقط بر اساس
عبارت GDDR5 یا GDDR6 ممکن است نتیجه اشتباهی ایجاد
کند.

معماری‌های کارت گرافیک NVIDIA؛ از Tesla و Fermi تا RTX و Blackwell

شرکت NVIDIA در نسل‌های مختلف، معماری‌های گوناگونی برای
پردازنده‌های گرافیکی خود طراحی کرده است. معماری GPU
ساختار داخلی تراشه، نحوه اجرای پردازش‌ها، تعداد و نوع
واحدهای محاسباتی، حافظه کش، موتورهای ویدئویی و قابلیت‌های
گرافیکی کارت را تعیین می‌کند.

شناخت معماری کارت گرافیک به‌خصوص هنگام بررسی لپ‌تاپ‌ها،
سیستم‌های استوک و ورک‌استیشن‌های قدیمی اهمیت زیادی دارد؛
زیرا نام تجاری کارت به‌تنهایی اطلاعات کاملی درباره
قابلیت‌های آن ارائه نمی‌دهد.

برای مثال، دو کارت از خانواده GeForce یا Quadro ممکن است
ظرفیت حافظه مشابهی داشته باشند، اما به دلیل تفاوت معماری،
در مصرف برق، پشتیبانی نرم‌افزاری، قدرت پردازش و قابلیت‌های
ویدئویی کاملاً متفاوت باشند.


معماری GPU یعنی چه؟

معماری GPU به طرح کلی و سازمان داخلی پردازنده
گرافیکی گفته می‌شود. هر معماری می‌تواند شامل نسل
متفاوتی از هسته‌های CUDA، حافظه کش، واحدهای پردازش
بافت، موتورهای ویدئویی، Tensor Core و RT Core باشد.

چرا شناخت نسل کارت گرافیک مهم است؟

  • تعیین سازگاری کارت با نسخه‌های جدید درایور
  • بررسی پشتیبانی از CUDA و قابلیت‌های محاسباتی
  • تشخیص توانایی رمزگشایی و رمزگذاری ویدئو
  • بررسی پشتیبانی از DirectX، Vulkan و OpenGL
  • مقایسه مصرف برق و حرارت
  • تشخیص وجود Tensor Core و RT Core
  • ارزیابی مناسب‌بودن کارت برای بازی یا نرم‌افزارهای مهندسی
  • تشخیص ارزش خرید لپ‌تاپ یا ورک‌استیشن استوک

جدول کلی معماری‌های مهم NVIDIA

نسل‌های مهم معماری NVIDIA و نمونه کارت‌های آن‌ها
معماری خانواده‌های شناخته‌شده نمونه کارت‌ها کاربرد و ویژگی شاخص
Tesla GeForce 8، 9، 100، 200 و برخی Quadro FX 8800 GT، 9600 GT، 9800 GT،
GTX 260، Quadro FX 1700
آغاز معماری یکپارچه سایه‌زن و نسل‌های قدیمی CUDA
Fermi GeForce 400 و 500، Quadro 2000 تا 6000 GTX 460، GTX 560 Ti، GTX 580،
Quadro 2000، Quadro 4000
بهبود پردازش عمومی GPU و کاربردهای محاسباتی
Kepler GeForce 600 و 700، Quadro K GT 730، GTX 650، GTX 660،
GTX 760، Quadro K2000، K4000
مصرف برق بهتر و حضور گسترده در لپ‌تاپ‌های قدیمی
Maxwell GeForce 700، 800M، 900 و Quadro M GTX 750 Ti، GTX 850M، GTX 960M،
GTX 970، Quadro M2000
بهره‌وری انرژی مناسب و محبوبیت در لپ‌تاپ‌ها
Pascal GeForce 10، Quadro P، بعضی Teslaها GTX 1050 Ti، GTX 1060، GTX 1080،
Quadro P1000، P2000، P4000
جهش عملکرد، محبوب در سیستم‌های استوک و ورک‌استیشن
Volta Titan V، Tesla V100، Quadro GV100 Titan V، Tesla V100، Quadro GV100 معرفی Tensor Core برای پردازش‌های هوش مصنوعی
Turing GeForce GTX 16، RTX 20، Quadro RTX GTX 1650، GTX 1660، RTX 2060،
RTX 2080، Quadro RTX 4000
معرفی گسترده RT Core و Tensor Core در بازار حرفه‌ای و گیمینگ
Ampere GeForce RTX 30، RTX A Series RTX 3060، RTX 3070، RTX 3080،
RTX A2000، RTX A4000
افزایش توان Ray Tracing، CUDA و هوش مصنوعی
Ada Lovelace GeForce RTX 40 و RTX Ada Generation RTX 4060، RTX 4070، RTX 4090،
RTX 2000 Ada، RTX 4000 Ada
بهره‌وری بالاتر، تولید فریم و موتورهای جدیدتر ویدئویی
Blackwell نسل‌های جدید GeForce RTX و RTX Professional مدل‌های جدید گیمینگ، ورک‌استیشن و دیتاسنتر تمرکز بیشتر بر هوش مصنوعی، رندر عصبی و پردازش حرفه‌ای

معماری Tesla

Tesla یکی از معماری‌های قدیمی و مهم NVIDIA بود که در
کارت‌های خانواده GeForce 8، GeForce 9 و برخی محصولات
سری 200 استفاده شد. این معماری با شتاب‌دهنده‌های
دیتاسنتری جدیدی که ممکن است نام Tesla داشته باشند،
نباید اشتباه گرفته شود.

کارت‌هایی مانند GeForce 8800 GT، 9600 GT، 9800 GT،
GTX 260 و GTX 280 از نمونه‌های شناخته‌شده این دوران
هستند. برخی کارت‌های حرفه‌ای Quadro FX نیز بر اساس
تراشه‌های همین نسل تولید شدند.

محصولات Tesla امروزه برای بازی‌ها و نرم‌افزارهای جدید
بسیار قدیمی محسوب می‌شوند، اما هنوز ممکن است در
سیستم‌های اداری، کامپیوترهای صنعتی و ورک‌استیشن‌های
قدیمی دیده شوند.


محدودیت کارت‌های بسیار قدیمی

کارت‌های مبتنی بر Tesla ممکن است با درایورها،
سیستم‌عامل‌ها، رابط‌های برنامه‌نویسی و نرم‌افزارهای
جدید سازگاری محدودی داشته باشند. ظرفیت حافظه کم و
نبود قابلیت‌های جدید رمزگشایی ویدئو نیز باید بررسی شود.

معماری Fermi

Fermi در خانواده‌های GeForce 400 و GeForce 500 عرضه شد
و توجه بیشتری به پردازش‌های عمومی روی GPU داشت. این
معماری در زمان خود در محاسبات CUDA، طراحی سه‌بعدی و
پردازش‌های علمی نیز اهمیت پیدا کرد.

از مدل‌های شناخته‌شده این نسل می‌توان به GTX 460،
GTX 470، GTX 560 Ti و GTX 580 اشاره کرد.

کارت‌های حرفه‌ای Quadro 2000، Quadro 4000،
Quadro 5000 و برخی مدل‌های مشابه نیز متعلق به همین
دوره هستند و هنوز ممکن است در ورک‌استیشن‌های قدیمی
HP، Dell و Lenovo دیده شوند.

یکی از نقاط ضعف بسیاری از کارت‌های Fermi، مصرف برق و
تولید حرارت نسبتاً زیاد در مقایسه با نسل‌های بعدی است.

معماری Kepler

Kepler در تعداد زیادی از کارت‌های دسکتاپ، لپ‌تاپ و
ورک‌استیشن استفاده شد. محصولات خانواده GeForce 600،
بخش قابل‌توجهی از GeForce 700 و کارت‌های حرفه‌ای
Quadro K متعلق به این معماری هستند.

مدل‌هایی مانند GT 710، برخی نسخه‌های GT 730،
GTX 650، GTX 660، GTX 680، GTX 760 و GTX 780
از نمونه‌های معروف Kepler هستند.

در لپ‌تاپ‌ها نیز GPUهایی مانند GT 720M، GT 730M،
GT 740M، GTX 765M، GTX 770M و GTX 780M در بسیاری
از دستگاه‌های نسل قدیمی دیده می‌شوند.

کارت‌های Quadro K

خانواده Quadro K یکی از مهم‌ترین گروه‌های کارت گرافیک
در لپ‌تاپ‌ها و ورک‌استیشن‌های قدیمی است. مدل‌هایی مانند
Quadro K600، K1000M، K1100M، K2000، K2100M،
K2200، K3100M، K4000 و K4100M در سیستم‌های حرفه‌ای
استفاده شده‌اند.

این کارت‌ها ممکن است هنوز برای نسخه‌های قدیمی‌تر
AutoCAD، SolidWorks، CATIA، 3ds Max و نرم‌افزارهای
مهندسی سبک قابل استفاده باشند، اما باید سازگاری
نسخه نرم‌افزار، درایور و سیستم‌عامل بررسی شود.


Quadro K برای چه کسی مناسب است؟

یک لپ‌تاپ مجهز به Quadro K می‌تواند برای آموزش،
نقشه‌کشی دوبعدی و پروژه‌های سبک ارزش خرید داشته
باشد؛ اما برای رندر سنگین، هوش مصنوعی، Ray Tracing
یا نسخه‌های جدید نرم‌افزارها نباید انتظار عملکرد
کارت‌های جدید را داشت.

معماری Maxwell

Maxwell تمرکز زیادی بر بهبود بهره‌وری انرژی داشت و به
همین دلیل در لپ‌تاپ‌ها بسیار موفق بود. کارت‌هایی مانند
GTX 750، GTX 750 Ti، GTX 950، GTX 960، GTX 970 و
GTX 980 از معماری Maxwell استفاده می‌کنند.

در لپ‌تاپ‌های قدیمی و استوک نیز مدل‌های GTX 850M،
GTX 860M، GTX 950M، GTX 960M، GTX 965M،
GTX 970M و GTX 980M بسیار رایج هستند.

بعضی GPUهای اقتصادی مانند سری GeForce 800M و 900M
ممکن است با معماری‌ها و مشخصات متفاوت عرضه شده باشند؛
بنابراین نام مدل به‌تنهایی برای شناسایی دقیق GPU کافی نیست.

کارت‌های Quadro M

کارت‌های Quadro M در بسیاری از ورک‌استیشن‌های موبایل
و دسکتاپ نسل قبل استفاده شدند. Quadro M600M،
M1000M، M1200، M2000M، M2200، M3000M،
M4000M و M5000M از مدل‌های مهم این گروه هستند.

این خانواده نسبت به Quadro K معمولاً عملکرد و بهره‌وری
انرژی بهتری ارائه می‌کند و در بازار لپ‌تاپ‌های
ورک‌استیشن استوک همچنان اهمیت دارد.

معماری Pascal

Pascal یکی از موفق‌ترین و ماندگارترین معماری‌های
NVIDIA است. این معماری در کارت‌های سری GeForce 10،
کارت‌های Quadro P و تعدادی از شتاب‌دهنده‌های حرفه‌ای
استفاده شد.

مدل‌هایی مانند GT 1030، GTX 1050، GTX 1050 Ti،
GTX 1060، GTX 1070، GTX 1080 و GTX 1080 Ti
از محصولات مشهور این نسل هستند.

در لپ‌تاپ‌ها نیز نسخه‌های GTX 1050، GTX 1050 Ti،
GTX 1060، GTX 1070 و GTX 1080 عرضه شدند. در این نسل،
فاصله عملکرد نسخه لپ‌تاپی و دسکتاپ در برخی مدل‌ها نسبت
به نسل‌های قدیمی کمتر شد، اما توان مصرفی و فرکانس دستگاه
همچنان اهمیت زیادی دارد.

کارت‌های Quadro P

Quadro P یکی از مهم‌ترین خانواده‌ها برای بازار
ورک‌استیشن استوک است. مدل‌هایی مانند Quadro P500،
P600، P1000، P2000، P2200، P3000، P3200،
P4000، P5000 و P6000 در لپ‌تاپ‌ها و سیستم‌های
حرفه‌ای استفاده شده‌اند.

این کارت‌ها در بسیاری از پروژه‌های CAD، طراحی صنعتی،
معماری، مدل‌سازی و نرم‌افزارهایی مانند AutoCAD،
SolidWorks، CATIA، Maya و 3ds Max قابل استفاده‌اند.

Quadro P2000 و P2200 به دلیل مصرف برق مناسب، حافظه
GDDR5 و درایورهای حرفه‌ای، از کارت‌های شناخته‌شده بازار
ورک‌استیشن‌های دست‌دوم هستند.


آیا Pascal هنوز قابل استفاده است؟

بسیاری از کارت‌های Pascal هنوز برای بازی‌های سبک تا
متوسط، تدوین، طراحی سه‌بعدی، CAD و کاربری عمومی
قابل استفاده‌اند. بااین‌حال نبود RT Core و Tensor
Core اختصاصی، آن‌ها را در قابلیت‌های جدید RTX و
برخی پردازش‌های هوش مصنوعی محدود می‌کند.

معماری Volta

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

Tesla V100، Titan V و Quadro GV100 از محصولات
شناخته‌شده مبتنی بر Volta هستند.

یکی از مهم‌ترین ویژگی‌های Volta معرفی Tensor Core بود.
این واحدها برای افزایش سرعت برخی محاسبات ماتریسی و
پردازش‌های هوش مصنوعی طراحی شدند.

معماری Turing

Turing نقطه مهمی در تاریخ کارت‌های NVIDIA محسوب می‌شود؛
زیرا فناوری RTX، هسته‌های RT و نسل گسترده‌تری از
Tensor Core را وارد کارت‌های گرافیک گیمینگ و
ورک‌استیشن کرد.

سری GeForce RTX 20 شامل مدل‌هایی مانند RTX 2060،
RTX 2070، RTX 2080 و RTX 2080 Ti بر پایه Turing
ساخته شد.

سری GTX 16 مانند GTX 1650، GTX 1650 Super،
GTX 1660 و GTX 1660 Ti نیز از معماری Turing استفاده
می‌کند، اما معمولاً فاقد RT Core و Tensor Core فعال
مشابه کارت‌های RTX است.

کارت‌های Quadro RTX

Quadro RTX 3000، RTX 4000، RTX 5000، RTX 6000
و RTX 8000 از محصولات حرفه‌ای مهم این دوره هستند.

این کارت‌ها علاوه بر درایورهای حرفه‌ای، امکان استفاده
از Ray Tracing سخت‌افزاری و قابلیت‌های هوش مصنوعی را
در نرم‌افزارهای رندر، طراحی و تولید محتوا فراهم کردند.

لپ‌تاپ‌های ورک‌استیشن مجهز به Quadro RTX 3000،
RTX 4000 و RTX 5000 هنوز در بازار استوک دیده می‌شوند
و می‌توانند برای برخی پروژه‌های رندر، CAD و تولید
محتوای حرفه‌ای مناسب باشند.

معماری Ampere

Ampere در کارت‌های GeForce RTX 30 و محصولات حرفه‌ای
NVIDIA RTX A Series استفاده شد. این معماری قدرت
پردازش CUDA، Ray Tracing و هوش مصنوعی را نسبت به
نسل قبلی افزایش داد.

RTX 3050، RTX 3060، RTX 3070، RTX 3080 و RTX 3090
از مدل‌های شناخته‌شده گیمینگ این نسل هستند.

کارت‌های RTX A Series

با نسل Ampere، نام Quadro در بسیاری از محصولات جدید
کنار گذاشته شد و کارت‌های حرفه‌ای با نام‌هایی مانند
RTX A1000، RTX A2000، RTX A3000، RTX A4000،
RTX A4500، RTX A5000 و RTX A6000 عرضه شدند.

این کارت‌ها ادامه‌دهنده مسیر Quadro هستند و برای
ورک‌استیشن‌ها، نرم‌افزارهای حرفه‌ای، پروژه‌های CAD،
رندر، شبیه‌سازی و هوش مصنوعی طراحی شده‌اند.

RTX A2000 به دلیل ابعاد کوچک، مصرف برق کنترل‌شده و
پشتیبانی از قابلیت‌های RTX در بسیاری از ورک‌استیشن‌های
کوچک و سیستم‌های حرفه‌ای استفاده شده است.

معماری Ada Lovelace

Ada Lovelace در کارت‌های سری GeForce RTX 40 و
محصولات حرفه‌ای RTX Ada Generation استفاده می‌شود.
این معماری بر بهره‌وری انرژی، Ray Tracing، پردازش
هوش مصنوعی و موتورهای جدیدتر تولید ویدئو تمرکز دارد.

مدل‌هایی مانند RTX 4050 Laptop، RTX 4060،
RTX 4070، RTX 4080 و RTX 4090 از محصولات مصرف‌کننده
مبتنی بر Ada هستند.

در بازار حرفه‌ای نیز کارت‌هایی مانند RTX 2000 Ada،
RTX 4000 Ada، RTX 4500 Ada، RTX 5000 Ada و
RTX 6000 Ada برای ورک‌استیشن‌ها عرضه شدند.

این کارت‌ها برای نرم‌افزارهای مهندسی، مدل‌سازی،
رندر GPU، تدوین، واقعیت مجازی و پردازش‌های هوش مصنوعی
کاربرد دارند.

معماری Blackwell

Blackwell نسل جدیدتری از معماری‌های NVIDIA است که
تمرکز زیادی بر پردازش‌های هوش مصنوعی، رندر عصبی،
Ray Tracing و افزایش بهره‌وری پردازشی دارد.

این معماری در خانواده‌های جدید مصرف‌کننده، حرفه‌ای و
دیتاسنتری استفاده می‌شود و ادامه‌دهنده مسیر محصولات
RTX و RTX Professional است.

هنگام مقایسه محصولات مبتنی بر Blackwell باید مدل دقیق،
ظرفیت حافظه، توان مصرفی، نوع سیستم خنک‌کننده و رده
محصول بررسی شود؛ زیرا کارت‌های گیمینگ، لپ‌تاپی،
ورک‌استیشن و دیتاسنتر اهداف متفاوتی دارند.

تفاوت معماری با سری کارت گرافیک

معماری و سری تجاری یک مفهوم واحد نیستند. ممکن است چند
سری کارت از یک معماری استفاده کنند یا یک سری تجاری
شامل GPUهایی با معماری‌های متفاوت باشد.

برای مثال، خانواده GeForce 700 شامل محصولاتی با
معماری‌های متفاوت بود. برخی مدل‌ها Kepler و بعضی
مدل‌های دیگر Maxwell بودند.

همین موضوع درباره کارت‌های لپ‌تاپی نیز اهمیت دارد؛
زیرا نام‌هایی مانند GT 730M، GT 740M یا سری‌های MX
ممکن است در نسخه‌های مختلف مشخصات متفاوتی داشته باشند.


فقط به نام سری اعتماد نکنید

برای تشخیص دقیق کارت، کد GPU، معماری، نوع حافظه،
تعداد هسته‌های CUDA، پهنای باس و مشخصات نسخه
لپ‌تاپی یا دسکتاپ را بررسی کنید.

معماری کارت‌های گرافیک لپ‌تاپ

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

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

این موضوع در کارت‌های جدید و قدیمی هر دو وجود دارد.
برای نمونه، عملکرد یک GTX 960M یا Quadro M2000M به
خنک‌کننده و توان دستگاه وابسته است و در نسل‌های جدیدتر
نیز تفاوت توان نسخه‌های لپ‌تاپی می‌تواند اختلاف عملکرد
قابل‌توجهی ایجاد کند.

نمونه نسل‌های رایج در لپ‌تاپ‌های قدیمی و استوک

معماری کارت‌های رایج در لپ‌تاپ‌های قدیمی
مدل کارت معماری معمول سطح کاربرد تقریبی
GeForce GT 720M Kepler کاربری عمومی و بازی‌های بسیار سبک
GeForce GT 740M معمولاً Kepler بازی‌ها و نرم‌افزارهای قدیمی سبک
GeForce GTX 860M بسته به نسخه Kepler یا Maxwell بازی و طراحی نسل قدیمی
GeForce GTX 960M Maxwell بازی، تدوین و طراحی سبک
GeForce GTX 1050 Laptop Pascal بازی متوسط، تدوین و طراحی
GeForce GTX 1060 Laptop Pascal بازی، رندر و تولید محتوا
Quadro K2100M Kepler CAD و نرم‌افزارهای حرفه‌ای قدیمی
Quadro M2000M Maxwell طراحی مهندسی و مدل‌سازی متوسط
Quadro P2000 Pascal CAD، SolidWorks، مدل‌سازی و رندر سبک
Quadro RTX 3000 Turing طراحی، رندر و پروژه‌های حرفه‌ای
RTX A2000 Laptop Ampere ورک‌استیشن، رندر و پردازش حرفه‌ای

بهترین معماری NVIDIA برای نرم‌افزارهای مهندسی

انتخاب معماری مناسب به نسخه نرم‌افزار، حجم پروژه،
بودجه و نوع پردازش بستگی دارد. برای نقشه‌کشی دوبعدی و
پروژه‌های سبک، کارت‌های قدیمی‌تر Quadro K یا Quadro M
ممکن است کافی باشند.

برای پروژه‌های متوسط CAD و SolidWorks، کارت‌های
Quadro P و نسل‌های جدیدتر معمولاً گزینه متعادل‌تری
هستند. در پروژه‌های رندر، شبیه‌سازی و مدل‌سازی سنگین،
Quadro RTX، RTX A Series و RTX Professional
قابلیت‌های بیشتری ارائه می‌کنند.

در نرم‌افزارهایی مانند AutoCAD، SolidWorks، CATIA و
Maya فقط معماری GPU تعیین‌کننده نیست. ظرفیت VRAM،
قدرت CPU، مقدار RAM، نوع ذخیره‌ساز، درایور حرفه‌ای و
گواهی‌های ISV نیز اهمیت دارند.


برای ورک‌استیشن استوک چه نسلی مناسب است؟

Quadro P و Quadro RTX معمولاً تعادل مناسبی میان
قیمت، عملکرد و پشتیبانی نرم‌افزاری ایجاد می‌کنند.
Quadro K و M ارزان‌تر هستند، اما برای خرید آن‌ها
باید محدودیت درایور، عمر دستگاه و نیاز نرم‌افزار
با دقت بیشتری بررسی شود.

تفاوت GeForce و Quadro در معماری یکسان

گاهی یک کارت GeForce و یک کارت Quadro از GPUهایی با
معماری نزدیک استفاده می‌کنند، اما این موضوع به معنی
یکسان‌بودن کامل آن‌ها نیست.

تفاوت می‌تواند در ظرفیت حافظه، فرکانس، توان مصرفی،
نوع درایور، پشتیبانی ECC، خروجی‌های تصویری، قابلیت‌های
مدیریتی و تأییدیه نرم‌افزارهای حرفه‌ای باشد.

GeForce معمولاً برای بازی و عملکرد عمومی بهینه می‌شود،
در حالی که Quadro و RTX Professional بیشتر بر پایداری،
دقت، سازگاری و عملکرد قابل پیش‌بینی در نرم‌افزارهای
مهندسی و تولید محتوا تمرکز دارند.


نسل معماری یکسان، کاربرد متفاوت

یک GeForce و Quadro هم‌نسل ممکن است در برخی
پردازش‌ها عملکرد نزدیک داشته باشند، اما نوع درایور
و قابلیت‌های حرفه‌ای می‌تواند تجربه متفاوتی در
SolidWorks، CATIA، Maya یا نرم‌افزارهای CAD
ایجاد کند.

چگونه معماری کارت NVIDIA را تشخیص دهیم؟

  1. مدل دقیق GPU را از Device Manager یا مشخصات
    سازنده پیدا کنید.
  2. در لپ‌تاپ، مدل کامل دستگاه و کد پیکربندی آن را
    بررسی کنید.
  3. با نرم‌افزارهایی مانند GPU-Z مشخصات تراشه،
    حافظه و کد GPU را مشاهده کنید.
  4. نام معماری را با مدل دقیق کارت تطبیق دهید.
  5. در کارت‌های دارای چند نسخه، نوع حافظه و تعداد
    هسته‌ها را نیز کنترل کنید.
  6. نسخه درایور و آخرین سیستم‌عامل پشتیبانی‌شده را
    بررسی کنید.


نام نمایش‌داده‌شده در ویندوز همیشه کافی نیست

در بعضی لپ‌تاپ‌ها یا کارت‌های بازسازی‌شده، نام
نمایش‌داده‌شده توسط درایور ممکن است برای تشخیص دقیق
نسخه GPU کافی نباشد. شناسه سخت‌افزاری و مشخصات
واقعی تراشه را نیز بررسی کنید.

معماری‌های کارت گرافیک AMD؛ از ATI و Terascale تا GCN، RDNA و CDNA

تاریخ پردازنده‌های گرافیکی AMD با محصولات شرکت ATI
پیوند خورده است. بسیاری از کارت‌های قدیمی که با نام
ATI Radeon شناخته می‌شوند، همچنان در رایانه‌های اداری،
لپ‌تاپ‌های قدیمی، سیستم‌های صنعتی و ورک‌استیشن‌های
استوک دیده می‌شوند.

پس از پیوستن ATI به AMD، برند Radeon برای کارت‌های
مصرف‌کننده ادامه پیدا کرد و خانواده‌هایی مانند
FirePro، Radeon Pro و AMD Instinct نیز برای
ورک‌استیشن‌ها، پردازش‌های حرفه‌ای، محاسبات علمی و
هوش مصنوعی توسعه یافتند.

شناخت معماری GPUهای AMD کمک می‌کند تفاوت میان
کارت‌های Radeon HD، سری R، سری RX، Radeon Pro،
FirePro و Instinct را بهتر درک کنیم. این موضوع هنگام
خرید کارت دست‌دوم یا لپ‌تاپ استوک اهمیت بیشتری دارد؛
زیرا ممکن است دو کارت با ظرفیت حافظه مشابه، قابلیت‌ها
و عملکرد کاملاً متفاوتی داشته باشند.


معماری GPU در کارت‌های AMD چیست؟

معماری GPU ساختار داخلی تراشه را مشخص می‌کند؛ از
جمله نحوه سازمان‌دهی واحدهای پردازشی، حافظه کش،
واحدهای بافت، خروجی‌های رندر، موتورهای ویدئویی،
شتاب‌دهنده‌های Ray Tracing و واحدهای مرتبط با
هوش مصنوعی.

تفاوت Radeon، FirePro، Radeon Pro و Instinct

AMD Radeon

Radeon نام اصلی کارت‌های گرافیک مصرف‌کننده AMD
است. این محصولات برای بازی، استفاده روزمره،
تولید محتوا، نمایش تصویر و پردازش گرافیکی عمومی
طراحی می‌شوند.

خانواده‌های Radeon HD، Radeon R5، R7، R9،
RX 400، RX 500، RX Vega و Radeon RX جدیدتر
در این گروه قرار می‌گیرند.

AMD FirePro

FirePro نام نسل قدیمی کارت‌های حرفه‌ای AMD
برای ورک‌استیشن‌ها بود. این کارت‌ها برای
نرم‌افزارهای CAD، طراحی صنعتی، مدل‌سازی،
تولید محتوا و کاربردهای تخصصی عرضه می‌شدند.

مدل‌هایی مانند FirePro V3900، V4900،
W5000، W5100، W7000، W7100 و W9100
از محصولات شناخته‌شده این خانواده هستند.

AMD Radeon Pro

Radeon Pro جانشین اصلی برند FirePro در بازار
ورک‌استیشن است. این کارت‌ها با تمرکز بر
پایداری، درایور حرفه‌ای، حافظه بیشتر، نمایشگرهای
تخصصی و سازگاری با نرم‌افزارهای حرفه‌ای عرضه
می‌شوند.

Radeon Pro WX، Radeon Pro W و برخی GPUهای
حرفه‌ای لپ‌تاپی در این گروه قرار دارند.

AMD Instinct

Instinct خانواده شتاب‌دهنده‌های محاسباتی AMD
برای دیتاسنتر، هوش مصنوعی، یادگیری ماشین،
محاسبات علمی و HPC است.

این محصولات معمولاً برای اجرای بازی یا اتصال
مستقیم نمایشگر ساخته نشده‌اند و باید آن‌ها را
از کارت‌های Radeon و Radeon Pro جدا دانست.

جدول کلی نسل‌ها و معماری‌های مهم AMD

معماری‌های مهم کارت گرافیک AMD و نمونه محصولات
معماری یا خانواده محصولات رایج نمونه کارت‌ها ویژگی و کاربرد کلی
Radeonهای پیش از Terascale Radeon 7000 تا X1000 Radeon 9200، 9600، X1300، X1600 کارت‌های قدیمی برای نمایش تصویر و بازی‌های کلاسیک
Terascale 1 Radeon HD 2000 و HD 3000 HD 2400، HD 2600، HD 3850، HD 3870 نسل ابتدایی سایه‌زن‌های یکپارچه AMD
Terascale 2 Radeon HD 4000، HD 5000 و بخشی از HD 6000 HD 4550، HD 5450، HD 5770، HD 5850 حضور گسترده در کامپیوترها و لپ‌تاپ‌های قدیمی
Terascale 3 بخش‌هایی از Radeon HD 6000 HD 6790، HD 6850، HD 6870، HD 6970 آخرین نسل اصلی پیش از GCN
GCN نسل اول Radeon HD 7000 HD 7750، HD 7770، HD 7850، HD 7970 معماری جدید برای گرافیک و پردازش عمومی
GCN نسل دوم و سوم Radeon R7 و R9 سری 200 و 300 R7 250، R9 270X، R9 280X، R9 290X بازی، OpenCL و پردازش‌های گرافیکی چندمنظوره
GCN نسل چهارم؛ Polaris Radeon RX 400 و RX 500 RX 460، RX 470، RX 480، RX 570، RX 580 مصرف مناسب‌تر و محبوبیت زیاد در بازار دست‌دوم
GCN نسل پنجم؛ Vega RX Vega، Radeon VII و برخی Radeon Pro RX Vega 56، Vega 64، Radeon VII پهنای باند بالا و کاربردهای گرافیکی و محاسباتی
RDNA Radeon RX 5000 RX 5500 XT، RX 5600 XT، RX 5700 XT معماری جدیدتر با تمرکز ویژه بر بازی
RDNA 2 Radeon RX 6000 RX 6400، RX 6600، RX 6700 XT، RX 6800 Ray Tracing سخت‌افزاری و Infinity Cache
RDNA 3 Radeon RX 7000 و Radeon Pro W7000 RX 7600، RX 7700 XT، RX 7800 XT،
Radeon Pro W7800
طراحی پیشرفته‌تر، موتور نمایش و رسانه جدیدتر
RDNA 4 Radeon RX 9000 مدل‌های خانواده Radeon RX 9000 تمرکز بیشتر بر Ray Tracing و شتاب‌دهی هوش مصنوعی
CDNA AMD Instinct شتاب‌دهنده‌های سری MI هوش مصنوعی، HPC و پردازش دیتاسنتری

کارت‌های Radeon قدیمی پیش از Terascale

پیش از معماری‌های Terascale و GCN، شرکت ATI نسل‌های
متعددی از کارت‌های Radeon را تولید کرده بود. کارت‌هایی
مانند Radeon 9200، Radeon 9600، Radeon 9800،
X1300، X1600 و X1950 در رایانه‌های دهه‌های گذشته
استفاده می‌شدند.

این محصولات ممکن است از رابط‌هایی مانند AGP یا
نسخه‌های اولیه PCI Express استفاده کنند. بسیاری از
آن‌ها با سیستم‌عامل‌ها و نمایشگرهای جدید سازگاری
محدودی دارند و برای استفاده امروزی بیشتر جنبه صنعتی،
تعمیراتی یا آرشیوی پیدا کرده‌اند.


کارت AGP را با PCI Express اشتباه نگیرید

کارت‌های AGP و PCI Express از نظر اسلات و ارتباط
الکتریکی با یکدیگر سازگار نیستند. پیش از خرید کارت
برای سیستم بسیار قدیمی، نوع اسلات مادربرد را بررسی
کنید.

معماری Terascale

Terascale یکی از دوره‌های مهم تاریخ GPUهای AMD بود و
در خانواده‌های متعددی از Radeon HD استفاده شد. این
معماری چند نسل مختلف داشت و در کارت‌های اقتصادی تا
رده‌بالا به کار رفت.

Terascale 1

نخستین نسل Terascale در کارت‌های Radeon HD 2000 و
HD 3000 دیده شد. HD 2400، HD 2600، HD 3650،
HD 3850 و HD 3870 از مدل‌های رایج این دوره هستند.

این کارت‌ها امروز برای بازی یا نرم‌افزارهای سنگین
مناسب نیستند، اما ممکن است برای خروجی تصویر در
سیستم‌های قدیمی یا اجرای نرم‌افزارهای هم‌دوره خود
استفاده شوند.

Terascale 2

نسل دوم Terascale در تعداد زیادی از کارت‌های
Radeon HD 4000، HD 5000 و بعضی مدل‌های HD 6000
استفاده شد.

Radeon HD 4350، HD 4550، HD 5450، HD 5670،
HD 5750، HD 5770، HD 5850 و HD 5870 از
نمونه‌های معروف آن هستند.

کارت Radeon HD 5450 هنوز هم در برخی رایانه‌های اداری
قدیمی دیده می‌شود. این کارت بیشتر برای ایجاد خروجی
تصویر، استفاده چندنمایشگره سبک و پخش محتوای قدیمی
کاربرد دارد و نباید آن را یک کارت مناسب برای بازی یا
پردازش سه‌بعدی جدید دانست.

Terascale 3

Terascale 3 در تعدادی از کارت‌های قدرتمند خانواده
Radeon HD 6000 استفاده شد. HD 6790، HD 6850،
HD 6870، HD 6950 و HD 6970 از نمونه‌های مهم این
نسل هستند.

بعضی کارت‌های سری HD 6000 از معماری‌ها و تراشه‌های
متفاوتی استفاده می‌کنند؛ بنابراین برای شناسایی دقیق،
باید مدل کامل GPU بررسی شود.

معماری GCN چیست؟

عبارت GCN مخفف
Graphics Core Next
است. این معماری جایگزین Terascale شد و برای اجرای
پردازش‌های گرافیکی و محاسبات عمومی روی GPU طراحی شده
بود.

معماری GCN برای چندین سال پایه تعداد زیادی از کارت‌های
Radeon، FirePro، Radeon Pro و شتاب‌دهنده‌های حرفه‌ای
AMD بود.

واحد محاسباتی در GCN

GPUهای GCN از مجموعه‌هایی با عنوان Compute Unit
تشکیل می‌شوند. هر Compute Unit شامل تعدادی واحد
پردازش برداری، زمان‌بند، حافظه محلی و منابع مشترک است.

عدد Stream Processor که در مشخصات کارت‌های AMD دیده
می‌شود، به تعداد واحدهای پردازشی ساده‌تر اشاره دارد؛
اما مقایسه مستقیم این عدد میان معماری‌های متفاوت همیشه
صحیح نیست.


تعداد Stream Processor معیار کامل عملکرد نیست

دو کارت با تعداد Stream Processor یکسان ممکن است
به دلیل تفاوت معماری، فرکانس، حافظه، تعداد ROP،
پهنای باند و محدودیت توان، عملکرد متفاوتی داشته
باشند.

GCN نسل اول و Radeon HD 7000

نخستین نسل GCN در کارت‌های Radeon HD 7000 وارد بازار
شد. HD 7730، HD 7750، HD 7770، HD 7850،
HD 7870، HD 7950 و HD 7970 از مهم‌ترین مدل‌های
این خانواده هستند.

Radeon HD 7750 به دلیل مصرف برق نسبتاً کنترل‌شده و
وجود نسخه‌هایی بدون کانکتور برق مجزا، در برخی
سیستم‌های اداری و کیس‌های قدیمی محبوب بود.

Radeon HD 7970 نیز یکی از کارت‌های قدرتمند زمان خود
بود و بعدها برخی تراشه‌ها یا مدل‌های نزدیک به آن با
نام‌های تجاری دیگری در خانواده R9 عرضه شدند.

خانواده‌های Radeon R5، R7 و R9

AMD پس از Radeon HD از نام‌گذاری R5، R7 و R9 استفاده
کرد. R5 معمولاً برای محصولات اقتصادی، R7 برای مدل‌های
اقتصادی تا میان‌رده و R9 برای مدل‌های قدرتمندتر به کار
می‌رفت.

مدل‌هایی مانند R7 240، R7 250، R7 260X،
R9 270، R9 270X، R9 280X، R9 290 و R9 290X
در بازار سیستم‌های قدیمی و دست‌دوم دیده می‌شوند.

بعضی محصولات این خانواده نسخه تغییرنام‌یافته یا
اصلاح‌شده تراشه‌های نسل قبل بودند. بنابراین فقط بر
اساس نام R7 یا R9 نمی‌توان معماری، قدرت یا سن واقعی
کارت را تشخیص داد.

معماری Polaris و Radeon RX 400

Polaris یکی از شناخته‌شده‌ترین نسل‌های GCN است و در
کارت‌های Radeon RX 400 وارد بازار شد. RX 460،
RX 470 و RX 480 از مهم‌ترین کارت‌های این نسل هستند.

Polaris با هدف ارائه عملکرد مناسب و بهره‌وری انرژی
بهتر نسبت به بسیاری از نسل‌های قدیمی توسعه یافت.
محصولات این نسل هنوز در بازار کارت‌های گرافیک استوک
و دست‌دوم حضور قابل توجهی دارند.

Radeon RX 500 و محبوبیت RX 570 و RX 580

خانواده Radeon RX 500 ادامه و تکامل محصولات Polaris
بود. RX 550، RX 560، RX 570 و RX 580 از مدل‌های
اصلی این خانواده هستند.

RX 570 و RX 580 برای سال‌ها در سیستم‌های گیمینگ
اقتصادی بسیار محبوب بودند. این کارت‌ها معمولاً با
حافظه GDDR5 و ظرفیت‌های مختلف عرضه شدند.

تعداد زیادی از کارت‌های RX 470، RX 480، RX 570 و
RX 580 در دوره استخراج ارز دیجیتال استفاده شده‌اند؛
بنابراین هنگام خرید نمونه دست‌دوم باید وضعیت تراشه،
حافظه، فن‌ها، بایوس و تعمیرات احتمالی بررسی شود.


بررسی RX 570 و RX 580 دست‌دوم

وجود بایوس تغییر‌یافته، فن فرسوده، حافظه معیوب،
آثار تعمیر، دمای غیرعادی یا Artifacts می‌تواند
نشانه استفاده سنگین یا نگهداری نامناسب کارت باشد.
تست کوتاه تصویر برای ارزیابی کامل کافی نیست.

نسخه‌های Radeon RX 500X و نام‌گذاری‌های مشابه

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

برای مقایسه باید تعداد واحدهای پردازشی، فرکانس،
نوع حافظه، پهنای باس و توان مصرفی مدل دقیق بررسی شود.

معماری Vega

Vega نسل پیشرفته‌تری از GCN بود و در کارت‌های مصرف‌کننده،
پردازنده‌های دارای گرافیک مجتمع، ورک‌استیشن‌ها و
شتاب‌دهنده‌های محاسباتی استفاده شد.

Radeon RX Vega 56، RX Vega 64 و Radeon VII از
کارت‌های شناخته‌شده این دوره هستند. بعضی از این
محصولات از حافظه HBM2 استفاده می‌کنند که پهنای باند
بالایی ارائه می‌دهد.

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


اهمیت Dual Channel برای گرافیک مجتمع Vega

استفاده از دو ماژول RAM سازگار برای فعال‌شدن حالت
دوکاناله می‌تواند پهنای باند حافظه در دسترس گرافیک
مجتمع را افزایش دهد. تأثیر آن در بازی و پردازش
گرافیکی بیشتر از استفاده اداری ساده دیده می‌شود.

Radeon VII

Radeon VII یک کارت رده‌بالا مبتنی بر خانواده Vega بود
که از حافظه HBM2 با ظرفیت بالا استفاده می‌کرد. این کارت
علاوه بر بازی، در بعضی پردازش‌های تولید محتوا و
محاسباتی مورد توجه قرار گرفت.

بااین‌حال مصرف برق، حرارت، وضعیت درایور و قیمت نمونه
دست‌دوم باید هنگام خرید آن بررسی شود.

معماری RDNA چیست؟

RDNA معماری جدیدتر AMD برای کارت‌های گرافیک Radeon
است که بعد از دوره طولانی GCN معرفی شد. این معماری
با تمرکز بیشتر بر عملکرد گرافیکی، بازی و بهره‌وری
طراحی شده است.

ساختار واحدهای پردازشی RDNA نسبت به GCN تغییر کرد؛
به همین دلیل مقایسه تعداد Stream Processor میان
کارت‌های GCN و RDNA بدون توجه به معماری، نتیجه دقیقی
ایجاد نمی‌کند.

RDNA نسل اول و Radeon RX 5000

نخستین نسل RDNA در کارت‌های Radeon RX 5000 استفاده
شد. RX 5500 XT، RX 5600 XT، RX 5700 و RX 5700 XT
از مدل‌های مهم این خانواده هستند.

این نسل عملکرد مناسبی در بازی‌های Rasterization ارائه
می‌کرد، اما شتاب‌دهنده اختصاصی Ray Tracing مشابه
نسل‌های بعدی RDNA در آن وجود نداشت.

کارت‌های RX 5000 معمولاً از حافظه GDDR6 استفاده
می‌کنند و از نظر موتورهای رسانه، رابط PCI Express و
بهره‌وری نسبت به بسیاری از کارت‌های Polaris جدیدتر
هستند.

RDNA 2 و Radeon RX 6000

RDNA 2 در خانواده Radeon RX 6000 استفاده شد و
پشتیبانی سخت‌افزاری از Ray Tracing را به کارت‌های
Radeon مصرف‌کننده اضافه کرد.

RX 6400، RX 6500 XT، RX 6600، RX 6600 XT،
RX 6700 XT، RX 6800، RX 6800 XT و RX 6900 XT
از نمونه‌های شناخته‌شده این نسل هستند.

یکی از قابلیت‌های مهم این نسل Infinity Cache است.
این حافظه کش بزرگ روی تراشه می‌تواند بخشی از درخواست‌های
حافظه را بدون مراجعه مداوم به VRAM پاسخ دهد و به
افزایش پهنای باند مؤثر کمک کند.

محدودیت رابط در بعضی مدل‌های اقتصادی

بعضی کارت‌های اقتصادی RDNA 2 از تعداد محدودی Lane
در رابط PCI Express استفاده می‌کنند. در این شرایط،
نصب کارت روی مادربردی با نسل قدیمی‌تر PCIe ممکن است
در بعضی بازی‌ها یا کاربردها افت عملکرد بیشتری ایجاد
کند.


تعداد Lane را بررسی کنید

فقط عبارت PCIe 4.0 برای مقایسه کافی نیست. باید
مشخص شود کارت از رابط x16، x8 یا x4 استفاده
می‌کند و مادربرد نیز از چه نسل PCI Express
پشتیبانی می‌کند.

RDNA 3 و طراحی Chiplet

RDNA 3 در خانواده Radeon RX 7000 و برخی محصولات
حرفه‌ای Radeon Pro استفاده می‌شود. در بعضی GPUهای
رده‌بالای این نسل، بخش‌های مختلف تراشه با طراحی
Chiplet سازمان‌دهی شده‌اند.

RX 7600، RX 7700 XT، RX 7800 XT، RX 7900 GRE،
RX 7900 XT و RX 7900 XTX از مدل‌های شناخته‌شده
خانواده RX 7000 هستند.

این نسل علاوه بر بهبود واحدهای گرافیکی، موتور رسانه
پیشرفته‌تری دارد و در محصولات سازگار می‌تواند از
رمزگذاری یا رمزگشایی کدک‌های جدیدتر مانند AV1
پشتیبانی کند.

RDNA 4 و Radeon RX 9000

RDNA 4 نسل جدیدتر معماری گرافیکی AMD برای کارت‌های
Radeon RX 9000 است. در این نسل تمرکز بیشتری بر
عملکرد Ray Tracing، شتاب‌دهی هوش مصنوعی، کیفیت
تصویر و بهره‌وری پردازشی دیده می‌شود.

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


RDNA برای چه کاربردی طراحی شده است؟

معماری RDNA عمدتاً برای پردازش گرافیکی، بازی،
نمایش تصویر، تولید محتوا و کاربردهای تعاملی طراحی
شده است؛ در حالی که CDNA بیشتر برای محاسبات
دیتاسنتری، هوش مصنوعی و HPC توسعه می‌یابد.

معماری CDNA چیست؟

CDNA خانواده معماری‌های محاسباتی AMD است که برای
شتاب‌دهنده‌های Instinct و بارهای کاری دیتاسنتری
طراحی شده است.

این محصولات روی محاسبات برداری، ماتریسی، یادگیری ماشین،
شبیه‌سازی علمی و پردازش‌های HPC تمرکز دارند. استفاده
از حافظه HBM، فناوری‌های ارتباطی پرسرعت و پشتیبانی از
قالب‌های عددی مختلف از ویژگی‌های مهم این خانواده است.

یک شتاب‌دهنده Instinct معمولاً جایگزین مستقیم کارت
Radeon گیمینگ نیست. این محصولات ممکن است خروجی نمایشگر
معمولی نداشته باشند و برای سرور، رک، خنک‌کننده تخصصی
و نرم‌افزارهای محاسباتی طراحی شده باشند.

تفاوت RDNA و CDNA

مقایسه کلی معماری‌های RDNA و CDNA
معیار RDNA CDNA
کاربرد اصلی گرافیک، بازی و تولید محتوا هوش مصنوعی، HPC و دیتاسنتر
خانواده محصولات Radeon RX و بخشی از Radeon Pro AMD Instinct
خروجی تصویر معمولاً دارد ممکن است برای نمایش مستقیم طراحی نشده باشد
نوع حافظه رایج معمولاً GDDR معمولاً HBM در شتاب‌دهنده‌های رده‌بالا
نرم‌افزار هدف بازی، رندر، تدوین و برنامه‌های گرافیکی ROCm، یادگیری ماشین و محاسبات علمی
محیط نصب دسکتاپ، لپ‌تاپ یا ورک‌استیشن سرور و دیتاسنتر

معماری کارت‌های FirePro

خانواده FirePro در نسل‌های مختلف از GPUهای متفاوتی
استفاده کرده است. بعضی مدل‌های قدیمی بر پایه Terascale
و محصولات جدیدتر آن بر پایه نسل‌های GCN ساخته شده‌اند.

FirePro V3900، V4900، V5900 و V7900 از کارت‌های
قدیمی این خانواده هستند. مدل‌های FirePro W مانند
W4100، W5000، W5100، W7000، W7100، W8100 و
W9100 در ورک‌استیشن‌های حرفه‌ای دیده می‌شوند.

این کارت‌ها برای نسخه‌های مشخصی از نرم‌افزارهای CAD،
طراحی صنعتی و تولید محتوا عرضه شده‌اند. هنگام خرید
نمونه قدیمی باید آخرین درایور پشتیبانی‌شده و سازگاری
آن با نسخه نرم‌افزار بررسی شود.

Radeon Pro WX

خانواده Radeon Pro WX پس از FirePro در بازار
ورک‌استیشن معرفی شد. مدل‌هایی مانند WX 2100،
WX 3100، WX 3200، WX 4100، WX 5100،
WX 7100، WX 8200 و WX 9100 در این گروه قرار
دارند.

بعضی مدل‌های Radeon Pro WX بر پایه Polaris و بعضی
مدل‌های رده‌بالا بر پایه Vega ساخته شده‌اند. بنابراین
قرارگرفتن دو کارت در خانواده WX به معنی یکسان‌بودن
معماری آن‌ها نیست.

Radeon Pro W Series

خانواده Radeon Pro W نسل جدیدتری از کارت‌های حرفه‌ای
AMD است. مدل‌هایی مانند W5500، W5700، W6400،
W6600، W6800 و محصولات W7000 در این گروه قرار
می‌گیرند.

این کارت‌ها برای نرم‌افزارهای CAD، طراحی، مدل‌سازی،
مهندسی، تولید محتوا، تدوین و محیط‌های چندنمایشگره
حرفه‌ای عرضه می‌شوند.

محصولات Radeon Pro W7000 بر پایه RDNA 3 هستند و
مدل‌های رده‌بالا می‌توانند ظرفیت حافظه زیادی برای
پروژه‌های پیچیده، مدل‌های سه‌بعدی بزرگ و محتوای
وضوح‌بالا فراهم کنند.

Radeon Pro در لپ‌تاپ‌ها

بعضی لپ‌تاپ‌های ورک‌استیشن از GPUهای Radeon Pro
موبایل استفاده می‌کنند. نام‌هایی مانند Radeon Pro WX
و Radeon Pro سری W ممکن است در لپ‌تاپ‌های حرفه‌ای
Dell Precision، HP ZBook یا Lenovo ThinkPad P
دیده شوند.

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

AMD در لپ‌تاپ‌های قدیمی

در لپ‌تاپ‌های قدیمی نام‌هایی مانند Radeon HD 6470M،
HD 7470M، HD 7570M، HD 7670M، HD 8570M،
R5 M230، R7 M260، R7 M360 و R9 M290X دیده
می‌شود.

بعضی از این محصولات نسخه تغییرنام‌یافته نسل‌های قبلی
هستند. علاوه بر آن، نوع حافظه می‌تواند DDR3 یا GDDR5
باشد و تفاوت قابل توجهی در پهنای باند ایجاد کند.

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


پسوند M به معنی قدرت یکسان با دسکتاپ نیست

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

گرافیک مجتمع AMD

بسیاری از پردازنده‌های AMD دارای گرافیک مجتمع هستند.
این محصولات در دوره‌های مختلف از معماری‌هایی مانند
Terascale، GCN، Vega و RDNA استفاده کرده‌اند.

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

عبارت Radeon Graphics به‌تنهایی برای تشخیص قدرت گرافیک
مجتمع کافی نیست. باید مدل دقیق پردازنده، تعداد واحدهای
محاسباتی و نسل معماری بررسی شود.

آیا Radeon برای AutoCAD مناسب است؟

بسیاری از کارت‌های Radeon می‌توانند AutoCAD و
نرم‌افزارهای دوبعدی را اجرا کنند. برای پروژه‌های سبک،
قدرت بسیار بالای GPU معمولاً ضروری نیست و عملکرد
تک‌هسته‌ای CPU نیز اهمیت زیادی دارد.

برای محیط‌های حرفه‌ای، پروژه‌های سه‌بعدی بزرگ و
سازمان‌هایی که پایداری و تأییدیه نرم‌افزاری اهمیت
بیشتری دارد، Radeon Pro می‌تواند انتخاب مناسب‌تری
نسبت به Radeon مصرف‌کننده باشد.

آیا Radeon برای SolidWorks مناسب است؟

کارت‌های Radeon مصرف‌کننده ممکن است SolidWorks را
اجرا کنند، اما برای محیط کاری حرفه‌ای باید سازگاری
درایور و فهرست سخت‌افزارهای تأییدشده نرم‌افزار بررسی
شود.

Radeon Pro با درایور حرفه‌ای و تمرکز بر نرم‌افزارهای
مهندسی، معمولاً انتخاب منطقی‌تری برای پروژه‌های حساس
SolidWorks، مونتاژهای بزرگ و محیط‌های سازمانی است.

آیا Radeon برای Blender مناسب است؟

کارت‌های Radeon می‌توانند در Viewport، مدل‌سازی و
رندر GPU در Blender استفاده شوند، اما پشتیبانی دقیق
به نسخه Blender، سیستم‌عامل، معماری GPU و Backend
محاسباتی بستگی دارد.

برای انتخاب کارت باید ظرفیت VRAM، عملکرد رندر، پشتیبانی
نرم‌افزاری و سازگاری افزونه‌ها بررسی شود. داشتن
Stream Processor بیشتر به‌تنهایی تضمین‌کننده رندر
سریع‌تر نیست.

آیا Radeon برای Maya مناسب است؟

کارت‌های Radeon و Radeon Pro می‌توانند در Viewport،
مدل‌سازی، انیمیشن و برخی موتورهای رندر Maya استفاده
شوند. نوع موتور رندر تعیین می‌کند که GPU از چه رابط
محاسباتی باید پشتیبانی کند.

در پروژه حرفه‌ای، Radeon Pro به دلیل درایورهای
سازمانی و تمرکز بر پایداری می‌تواند نسبت به یک Radeon
گیمینگ انتخاب قابل پیش‌بینی‌تری باشد.

آیا AMD برای هوش مصنوعی مناسب است؟

AMD در حوزه هوش مصنوعی از کارت‌های Radeon، کارت‌های
حرفه‌ای و شتاب‌دهنده‌های Instinct استفاده می‌کند.
بااین‌حال سازگاری نرم‌افزاری باید پیش از خرید با دقت
بررسی شود.

حجم VRAM، نوع معماری، سیستم‌عامل، نسخه فریم‌ورک،
پشتیبانی ROCm و وجود بسته‌های آماده برای نرم‌افزار
موردنظر اهمیت زیادی دارند.

شتاب‌دهنده‌های Instinct برای پروژه‌های سروری و
دیتاسنتری طراحی شده‌اند و نباید فقط بر اساس ظرفیت
حافظه با کارت‌های دسکتاپ مقایسه شوند.

نرم‌افزار ROCm چیست؟

ROCm پلتفرم نرم‌افزاری AMD برای محاسبات شتاب‌یافته،
هوش مصنوعی و HPC است. این پلتفرم شامل ابزارها،
کتابخانه‌ها، کامپایلرها و رابط‌هایی برای استفاده از
GPUهای سازگار AMD است.

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

تفاوت Stream Processor و CUDA Core

Stream Processor نام رایج واحدهای پردازشی در مشخصات
GPUهای AMD است، در حالی که CUDA Core اصطلاح مورد
استفاده NVIDIA محسوب می‌شود.

این دو عدد را نمی‌توان به‌صورت یک‌به‌یک با هم مقایسه
کرد؛ زیرا معماری، زمان‌بندی دستورها، فرکانس، پهنای
حافظه و ساختار واحدهای پردازشی دو شرکت متفاوت است.

تشخیص معماری کارت گرافیک AMD

  1. مدل کامل کارت را از Device Manager، GPU-Z یا
    مشخصات سازنده پیدا کنید.
  2. شناسه سخت‌افزاری GPU را در صورت وجود چند نسخه
    متفاوت بررسی کنید.
  3. نوع حافظه، ظرفیت VRAM و عرض باس را ثبت کنید.
  4. مشخص کنید کارت دسکتاپ، لپ‌تاپی، ورک‌استیشن یا
    شتاب‌دهنده سروری است.
  5. معماری دقیق تراشه را با مدل تجاری تطبیق دهید.
  6. آخرین نسخه درایور و سیستم‌عامل پشتیبانی‌شده را
    بررسی کنید.
  7. برای نرم‌افزارهای حرفه‌ای، فهرست سازگاری و
    تأییدیه‌های ISV را کنترل کنید.

راهنمای کلی خرید کارت AMD دست‌دوم

  • سلامت خروجی‌های تصویر را آزمایش کنید.
  • دمای بیکاری و دمای تحت بار را بررسی کنید.
  • کارت را برای Artifacts، خطوط رنگی و خاموش‌شدن
    تصویر آزمایش کنید.
  • سرعت و صدای فن‌ها را کنترل کنید.
  • مشخصات واقعی کارت را با GPU-Z بخوانید.
  • نسخه BIOS کارت را با مدل اصلی تطبیق دهید.
  • وضعیت کانکتورهای برق و مدار تغذیه را بررسی کنید.
  • آثار بازشدن، لحیم‌کاری یا تعمیر حافظه را کنترل کنید.
  • توان موردنیاز کارت را با پاور سیستم مقایسه کنید.
  • پشتیبانی درایور برای سیستم‌عامل خود را بررسی کنید.


معماری را در کنار وضعیت فیزیکی کارت بسنجید

یک کارت قدیمی سالم می‌تواند انتخاب بهتری از یک
کارت جدیدتر تعمیرشده یا فرسوده باشد. معماری،
عملکرد، وضعیت حافظه، کیفیت خنک‌کننده و سابقه
استفاده باید در کنار هم ارزیابی شوند.

سوالات متداول درباره معماری‌های کارت گرافیک AMD

تفاوت ATI و AMD Radeon چیست؟

ATI شرکت سازنده اصلی برند Radeon بود.
پس از پیوستن ATI به AMD، محصولات گرافیکی
با نام AMD Radeon ادامه پیدا کردند.

آیا RX 580 هنوز برای بازی مناسب است؟

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

تفاوت RX 570 و RX 580 چیست؟

RX 580 معمولاً واحدهای پردازشی و عملکرد
بیشتری دارد، اما نسخه حافظه، فرکانس،
سیستم خنک‌کننده و وضعیت سلامت کارت نیز
در نتیجه نهایی مؤثر است.

آیا کارت‌های FirePro برای بازی مناسب هستند؟

FirePro برای نرم‌افزارهای حرفه‌ای طراحی
شده است. ممکن است بعضی بازی‌ها را اجرا
کند، اما درایور، فرکانس و طراحی آن معمولاً
برای بازی بهینه نشده است.

Radeon Pro چه تفاوتی با Radeon دارد؟

Radeon بیشتر برای بازی و استفاده عمومی
طراحی می‌شود؛ Radeon Pro بر درایور حرفه‌ای،
پایداری، حافظه، محیط‌های چندنمایشگره و
سازگاری با نرم‌افزارهای کاری تمرکز دارد.

آیا Stream Processor بیشتر همیشه بهتر است؟

خیر. این عدد فقط در کنار معماری، فرکانس،
پهنای باند حافظه، تعداد ROP و محدودیت توان
معنا پیدا می‌کند.

تفاوت GCN و RDNA چیست؟

GCN معماری قدیمی‌تر و چندمنظوره AMD بود.
RDNA ساختار جدیدتری دارد و بیشتر برای
عملکرد گرافیکی، بازی و بهره‌وری طراحی شده
است.

کدام نسل AMD از Ray Tracing سخت‌افزاری پشتیبانی می‌کند؟

پشتیبانی سخت‌افزاری Ray Tracing در
کارت‌های مصرف‌کننده Radeon از معماری
RDNA 2 وارد خانواده RX 6000 شد.

Infinity Cache چیست؟

Infinity Cache نوعی حافظه کش روی GPU است
که می‌تواند تعداد مراجعه‌های مستقیم به
VRAM را کاهش دهد و پهنای باند مؤثر را
افزایش دهد.

آیا Radeon RX برای هوش مصنوعی مناسب است؟

برخی کارت‌های Radeon برای هوش مصنوعی قابل
استفاده‌اند، اما باید پشتیبانی ROCm،
سیستم‌عامل، فریم‌ورک، معماری و ظرفیت VRAM
پیش از خرید بررسی شود.

تفاوت Radeon و AMD Instinct چیست؟

Radeon برای پردازش گرافیکی و نمایش تصویر
طراحی می‌شود؛ Instinct شتاب‌دهنده محاسباتی
مخصوص سرور، هوش مصنوعی و HPC است.

آیا گرافیک مجتمع Vega حافظه اختصاصی دارد؟

معمولاً خیر. گرافیک مجتمع از بخشی از RAM
سیستم استفاده می‌کند و عملکرد آن به پهنای
باند حافظه اصلی وابسته است.

معماری‌های گرافیکی Intel؛ از Intel HD Graphics تا Iris Xe و Arc

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

نام‌هایی مانند Intel HD Graphics، Intel UHD Graphics،
Iris Graphics و Iris Xe بیشتر در پردازنده‌های دارای
گرافیک مجتمع دیده می‌شوند؛ در حالی که خانواده Intel Arc
شامل محصولات گرافیکی مجزا برای بازی، تولید محتوا،
ورک‌استیشن و بعضی پردازش‌های هوش مصنوعی است.

شناخت نسل گرافیک Intel به‌خصوص هنگام خرید لپ‌تاپ
استوک اهمیت زیادی دارد. عبارت کلی
Intel HD Graphics
به‌تنهایی قدرت GPU را مشخص نمی‌کند؛ زیرا مدل‌هایی مانند
HD 3000، HD 4000، HD 4600 و HD 520 از نسل‌ها و
قابلیت‌های کاملاً متفاوتی هستند.


گرافیک مجتمع Intel چیست؟

گرافیک مجتمع Intel داخل پردازنده یا مجموعه پردازشی
سیستم قرار دارد و معمولاً از حافظه RAM دستگاه
استفاده می‌کند. این GPU حافظه VRAM مستقل مشابه
کارت گرافیک مجزا ندارد.

خانواده‌های اصلی گرافیک Intel

Intel HD Graphics

این نام برای چندین نسل از گرافیک‌های مجتمع Intel
استفاده شد. مدل‌های HD 2000، HD 3000،
HD 4000، HD 4400، HD 4600، HD 520 و
HD 620 از نمونه‌های شناخته‌شده این خانواده‌اند.

Intel UHD Graphics

نام UHD در نسل‌های بعدی برای بسیاری از
گرافیک‌های مجتمع Intel استفاده شد. UHD 600،
UHD 620، UHD 630 و مدل‌های جدیدتر در این
گروه قرار دارند.

Intel Iris و Iris Pro

خانواده Iris معمولاً نسبت به مدل‌های عادی
Intel HD همان نسل، واحدهای پردازشی بیشتر یا
پیکربندی قدرتمندتری داشت.

بعضی مدل‌های Iris Pro از حافظه کش پرسرعت
اضافی برای افزایش پهنای باند مؤثر استفاده
می‌کردند.

Intel Iris Xe

Iris Xe نسل جدیدتری از گرافیک‌های Intel است
که در تعدادی از پردازنده‌های لپ‌تاپی و بعضی
محصولات مجزا استفاده شده است.

عملکرد آن به مدل پردازنده، تعداد واحدهای
اجرایی، توان مصرفی و پیکربندی RAM وابسته است.

Intel Arc

Arc نام خانواده کارت‌ها و GPUهای مجزای Intel
برای بازی، تولید محتوا، پردازش گرافیکی و
شتاب‌دهی هوش مصنوعی است.

Arc A-Series و Arc B-Series از مهم‌ترین نسل‌های
این خانواده محسوب می‌شوند.

Intel Arc Pro

Arc Pro برای ورک‌استیشن‌ها، نرم‌افزارهای
حرفه‌ای، طراحی، تولید محتوا و محیط‌های سازمانی
عرضه می‌شود.

این محصولات را می‌توان رقیبی برای بعضی مدل‌های
NVIDIA RTX Professional و AMD Radeon Pro دانست.

جدول کلی نسل‌های مهم گرافیک Intel

نسل‌های مهم گرافیک Intel و نمونه محصولات
خانواده نمونه مدل‌ها دوره استفاده رایج کاربرد تقریبی
Intel GMA GMA 950، GMA X3100، GMA 4500 لپ‌تاپ‌ها و سیستم‌های بسیار قدیمی نمایش تصویر، کار اداری و ویدئوی قدیمی
Intel HD Graphics نسل اول Intel HD Graphics پردازنده‌های قدیمی Core استفاده عمومی و نمایش تصویر
HD 2000 و HD 3000 Intel HD 2000، HD 3000 نسل دوم پردازنده‌های Core کار اداری، ویدئو و بازی‌های بسیار سبک
HD 2500 و HD 4000 Intel HD 2500، HD 4000 نسل سوم پردازنده‌های Core کار عمومی، ویدئو و نرم‌افزارهای سبک
HD 4200 تا HD 5200 HD 4400، HD 4600، Iris 5100،
Iris Pro 5200
نسل چهارم پردازنده‌های Core کاربری عمومی، طراحی سبک و بعضی بازی‌ها
HD 500 Series HD 520، HD 530، Iris 540،
Iris Pro 580
نسل‌های میانی پردازنده‌های Core استفاده روزمره، ویدئو و پردازش سبک
UHD Graphics UHD 600، UHD 620، UHD 630 لپ‌تاپ‌ها و دسکتاپ‌های چند نسل اخیر کار اداری، ویدئو و بازی‌های سبک
Iris Plus Iris Plus 640، 645، G7 لپ‌تاپ‌های باریک و حرفه‌ای تولید محتوا و گرافیک سبک تا متوسط
Iris Xe Iris Xe Graphics پردازنده‌های جدیدتر لپ‌تاپی کار عمومی، تولید محتوا و بازی سبک
Arc A-Series A310، A380، A580، A750، A770 نسل نخست کارت‌های Arc مجزا بازی، تولید محتوا، Ray Tracing و AI
Arc B-Series مدل‌های خانواده Arc B نسل دوم کارت‌های Arc مجزا بازی، تولید محتوا و پردازش هوش مصنوعی
Arc Pro Arc Pro A و Arc Pro B ورک‌استیشن‌های جدید Intel CAD، تولید محتوا و نرم‌افزارهای حرفه‌ای

Intel GMA چیست؟

پیش از رایج‌شدن نام Intel HD Graphics، بسیاری از
سیستم‌های Intel از گرافیک‌هایی با نام
Graphics Media Accelerator
یا GMA استفاده می‌کردند.

GMA 950، GMA X3100 و GMA 4500 از نمونه‌های
شناخته‌شده این خانواده هستند. این GPUها برای نمایش
محیط سیستم‌عامل، ویدئوهای قدیمی و کارهای اداری ساده
طراحی شده بودند.

قدرت پردازش سه‌بعدی و پشتیبانی نرم‌افزاری آن‌ها برای
برنامه‌های جدید بسیار محدود است. هنگام خرید لپ‌تاپ
بسیار قدیمی دارای GMA باید سازگاری سیستم‌عامل،
درایور و خروجی تصویر بررسی شود.

Intel HD Graphics 2000 و 3000

HD 2000 و HD 3000 در بسیاری از لپ‌تاپ‌های نسل دوم
پردازنده‌های Core دیده می‌شوند. لپ‌تاپ‌هایی مانند
بعضی مدل‌های Dell Latitude، HP ProBook و Lenovo
ThinkPad قدیمی ممکن است از HD 3000 استفاده کنند.

HD 3000 برای کارهای اداری، مرور وب، پخش محتوای سبک و
اجرای نرم‌افزارهای قدیمی مناسب بود؛ اما برای بازی‌های
جدید، تدوین سنگین یا طراحی سه‌بعدی امروزی بسیار محدود
است.

این گرافیک از حافظه RAM سیستم استفاده می‌کند و مقدار
حافظه نمایش‌داده‌شده در ویندوز نباید با VRAM واقعی
کارت گرافیک مجزا اشتباه گرفته شود.


محدودیت درایور HD 3000

HD 3000 متعلق به یک نسل قدیمی است و پشتیبانی آن
از سیستم‌عامل‌ها، DirectX و OpenGL جدید محدود است.
پیش از خرید دستگاه باید نرم‌افزار موردنظر و آخرین
درایور سازگار بررسی شود.

Intel HD Graphics 4000

HD 4000 در تعداد زیادی از لپ‌تاپ‌های نسل سوم پردازنده‌های
Core دیده می‌شود و نسبت به HD 3000 قدرت پردازشی و
قابلیت‌های گرافیکی بهتری دارد.

این GPU می‌تواند برای کار اداری، تماشای ویدئو،
برنامه‌نویسی، آموزش، ویرایش سبک تصویر و بعضی بازی‌های
قدیمی مورد استفاده قرار گیرد.

بااین‌حال محدودیت درایور، حافظه مشترک و قدرت پردازشی
پایین باعث می‌شود HD 4000 برای نرم‌افزارهای سه‌بعدی
جدید یا پروژه‌های حرفه‌ای گزینه مناسبی نباشد.

Intel HD Graphics 4400 و 4600

HD 4400 و HD 4600 در بسیاری از لپ‌تاپ‌ها و
کامپیوترهای نسل چهارم Intel استفاده شدند.

HD 4600 در مقایسه با HD 4000 معمولاً عملکرد بهتری
در پردازش گرافیکی، ویدئو و بعضی بازی‌های سبک ارائه
می‌کند.

این GPU هنوز هم در لپ‌تاپ‌های استوک اداری و بعضی
ورک‌استیشن‌های قدیمی دیده می‌شود. در سیستم‌هایی که
Quadro یا GeForce مجزا دارند، HD 4600 ممکن است برای
کارهای سبک و مدیریت مصرف برق استفاده شود.

Intel Iris و Iris Pro

خانواده Iris برای ارائه عملکرد گرافیکی بالاتر از
مدل‌های عادی Intel HD همان نسل ساخته شد.

بعضی مدل‌های Iris Pro دارای حافظه کش داخلی پرسرعت
بودند که با نام‌هایی مانند eDRAM شناخته می‌شد و به
افزایش پهنای باند مؤثر کمک می‌کرد.

Iris Pro 5200، Iris Pro 580 و بعضی مدل‌های Iris
Plus از نمونه‌های شناخته‌شده این خانواده هستند.

این محصولات می‌توانند برای تدوین سبک، طراحی دوبعدی،
برنامه‌های آموزشی و بعضی بازی‌ها مناسب باشند؛ اما
جایگزین کامل کارت گرافیک مجزای قدرتمند نیستند.

Intel HD Graphics 520 و 620

HD 520 و HD 620 در تعداد زیادی از لپ‌تاپ‌های اداری
و باریک استفاده شده‌اند.

این GPUها برای مرور وب، نرم‌افزارهای Office، پخش
ویدئو، برنامه‌نویسی و طراحی سبک مناسب‌اند.

در صورت استفاده از RAM دوکاناله، عملکرد گرافیکی آن‌ها
می‌تواند نسبت به پیکربندی تک‌کاناله بهتر باشد؛ زیرا
GPU مجتمع به پهنای باند حافظه اصلی وابسته است.

Intel UHD Graphics 600 و 620

UHD 600 معمولاً در پردازنده‌های اقتصادی و دستگاه‌های
کم‌مصرف دیده می‌شود. این گرافیک برای استفاده روزمره،
آموزش و پخش ویدئو طراحی شده است.

UHD 620 در بسیاری از لپ‌تاپ‌های تجاری و اداری استفاده
شده و برای کارهای عمومی، فتوشاپ سبک، برنامه‌نویسی و
نمایش ویدئو مناسب است.

بااین‌حال عبارت UHD به‌تنهایی قدرت GPU را مشخص نمی‌کند.
مدل پردازنده، تعداد واحدهای اجرایی، فرکانس و نوع RAM
باید بررسی شوند.

Intel Iris Xe چیست؟

Iris Xe نسل جدیدتری از گرافیک‌های Intel است و در
تعدادی از پردازنده‌های لپ‌تاپی و محصولات مجزا استفاده
شده است.

این GPU نسبت به بسیاری از مدل‌های قدیمی HD و UHD،
واحدهای اجرایی بیشتر، موتور رسانه پیشرفته‌تر و توان
گرافیکی بالاتری دارد.

Iris Xe می‌تواند برای تولید محتوا، تدوین سبک، طراحی،
برنامه‌نویسی، شتاب‌دهی بعضی نرم‌افزارها و اجرای
بازی‌های سبک یا رقابتی مورد استفاده قرار گیرد.


RAM دوکاناله برای Iris Xe مهم است

عملکرد Iris Xe در بسیاری از لپ‌تاپ‌ها به پهنای
باند RAM وابسته است. پیکربندی دوکاناله یا حافظه
سریع‌تر می‌تواند نسبت به RAM تک‌کاناله عملکرد
بهتری ایجاد کند.

Iris Xe MAX چیست؟

Iris Xe MAX یک GPU مجزای کم‌مصرف Intel بود که در
تعدادی از لپ‌تاپ‌ها و کارت‌های محدود دسکتاپ استفاده شد.

این محصول از حافظه و رابط مجزای خود استفاده می‌کرد و
با هدف شتاب‌دهی تولید محتوا، پردازش رسانه و بعضی
بارهای گرافیکی طراحی شده بود.

Iris Xe MAX را نباید صرفاً بر اساس نام با Iris Xe
مجتمع مقایسه کرد؛ زیرا نوع حافظه، توان و پیکربندی آن
متفاوت است.

معماری Xe چیست؟

Xe نام خانواده‌ای از معماری‌های گرافیکی Intel است که
در محصولات مجتمع، کارت‌های Arc و شتاب‌دهنده‌های
مختلف استفاده می‌شود.

شاخه‌های مختلف Xe برای اهداف متفاوت طراحی شده‌اند؛
از گرافیک کم‌مصرف لپ‌تاپی تا GPUهای مجزا، ورک‌استیشن
و پردازش‌های دیتاسنتری.

Xe-LP

Xe-LP یا Xe Low Power برای گرافیک‌های کم‌مصرف و
پردازنده‌های لپ‌تاپی طراحی شد.

بسیاری از محصولات Iris Xe مجتمع و بعضی GPUهای مجزای
کم‌مصرف بر اساس این خانواده ساخته شده‌اند.

تمرکز Xe-LP بر بهره‌وری انرژی، پردازش رسانه،
نمایشگرها و عملکرد گرافیکی مناسب در محدودیت توان
لپ‌تاپ است.

Xe-HPG و Arc Alchemist

نخستین نسل اصلی کارت‌های Arc با نام Arc A-Series
شناخته می‌شود و از معماری
Xe-HPG
استفاده می‌کند.

عبارت HPG به معماری گرافیکی پرفورمنس بالا اشاره دارد.
این معماری شامل Xe Core، واحدهای شتاب‌دهی هوش مصنوعی
و واحدهای اختصاصی Ray Tracing است.

Arc A310، A380، A580، A750 و A770 از مدل‌های
شناخته‌شده این نسل هستند.

Arc A310

Arc A310 یک کارت اقتصادی برای خروجی تصویر، پردازش
رسانه، بعضی کاربردهای تولید محتوا و بازی سبک است.

این کارت ممکن است در سیستم‌های کوچک یا دستگاه‌هایی
که به موتور رسانه جدید و خروجی‌های مدرن نیاز دارند،
مورد استفاده قرار گیرد.

Arc A380

Arc A380 نسبت به A310 منابع پردازشی بیشتری دارد و
برای بازی‌های سبک، تولید محتوا و شتاب‌دهی ویدئو مناسب‌تر
است.

Arc A580، A750 و A770

این مدل‌ها برای بازی و تولید محتوا طراحی شده‌اند.
A770 معمولاً در نسخه‌هایی با ظرفیت حافظه بیشتر نیز
عرضه شده و برای پروژه‌هایی که به VRAM بالاتر نیاز
دارند، گزینه قابل‌توجهی است.


اهمیت Resizable BAR در Intel Arc

بسیاری از کارت‌های Arc برای دستیابی به عملکرد
مناسب به فعال‌بودن Resizable BAR و پلتفرم سازگار
وابسته‌اند. در مادربردها یا پردازنده‌های قدیمی،
عملکرد ممکن است کمتر از انتظار باشد.

Xe2 و Arc Battlemage

نسل دوم کارت‌های Arc با خانواده Arc B-Series شناخته
می‌شود و از معماری Xe2 استفاده می‌کند.

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

این نسل از Xe Coreهای جدیدتر، موتورهای هوش مصنوعی XMX
و قابلیت‌های گرافیکی و رسانه‌ای بهبودیافته استفاده
می‌کند.

Xe Core چیست؟

Xe Core یکی از بلوک‌های اصلی پردازش در GPUهای جدید
Intel است.

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

تعداد Xe Core را نمی‌توان مستقیماً با تعداد CUDA Core
یا Stream Processor مقایسه کرد؛ زیرا ساختار داخلی
معماری‌های NVIDIA، AMD و Intel متفاوت است.

XMX چیست؟

XMX یا Xe Matrix Extensions واحدهای ماتریسی Intel
برای افزایش سرعت بعضی پردازش‌های هوش مصنوعی و
محاسباتی هستند.

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

Ray Tracing در Intel Arc

کارت‌های Arc دارای واحدهای اختصاصی برای محاسبات
Ray Tracing هستند.

عملکرد نهایی Ray Tracing به مدل GPU، بازی، درایور،
وضوح تصویر، تنظیمات کیفیت و استفاده از فناوری‌هایی
مانند XeSS وابسته است.

XeSS چیست؟

XeSS فناوری افزایش وضوح و بازسازی تصویر Intel است.
این فناوری بازی را در وضوح داخلی پایین‌تر رندر می‌کند
و سپس با استفاده از الگوریتم‌های پیشرفته، تصویر نهایی
را به وضوح بالاتر بازسازی می‌کند.

هدف XeSS افزایش نرخ فریم با حفظ کیفیت قابل قبول تصویر
است. نتیجه نهایی به نسخه فناوری، بازی و سخت‌افزار
مورد استفاده بستگی دارد.

موتور رسانه Intel

یکی از نقاط مهم بسیاری از GPUهای Intel، موتورهای
سخت‌افزاری رمزگذاری و رمزگشایی ویدئو است.

این موتور می‌تواند در پخش ویدئو، تدوین، استریم،
تبدیل فایل و خروجی گرفتن از نرم‌افزارهای تولید محتوا
نقش مهمی داشته باشد.

پشتیبانی از کدک‌هایی مانند H.264، H.265 و AV1 به
نسل GPU و نوع موتور رسانه وابسته است.

Quick Sync Video چیست؟

Quick Sync Video فناوری سخت‌افزاری Intel برای
رمزگذاری و رمزگشایی ویدئو است.

نرم‌افزارهایی مانند برنامه‌های تدوین، تبدیل ویدئو،
استریم و تماس تصویری می‌توانند در صورت پشتیبانی از
این قابلیت استفاده کنند.

وجود Quick Sync به‌تنهایی تضمین نمی‌کند که تمام
کدک‌ها یا فرمت‌ها پشتیبانی شوند. نسل پردازنده و موتور
رسانه باید بررسی شود.

Intel Arc Pro چیست؟

Arc Pro خانواده GPUهای حرفه‌ای Intel برای
ورک‌استیشن‌ها، طراحی، تولید محتوا و نرم‌افزارهای
سازمانی است.

این محصولات با تمرکز بر درایور حرفه‌ای، حافظه مناسب،
چندنمایشگره بودن و سازگاری با برنامه‌های تخصصی عرضه
می‌شوند.

خانواده Arc Pro شامل محصولات مبتنی بر نسل‌های Arc A
و Arc B است.

مقایسه Intel Arc Pro با Quadro و Radeon Pro

مقایسه کلی GPUهای حرفه‌ای Intel، NVIDIA و AMD
خانواده شرکت کاربرد اصلی نکته مهم
Arc Pro Intel ورک‌استیشن، تولید محتوا و CAD موتور رسانه قوی و معماری Xe
Quadro / RTX Professional NVIDIA مهندسی، رندر، AI و نرم‌افزار حرفه‌ای اکوسیستم CUDA و درایورهای حرفه‌ای گسترده
Radeon Pro AMD CAD، طراحی، تولید محتوا و نمایشگر حرفه‌ای درایور حرفه‌ای و خانواده‌های RDNA

آیا Intel HD برای AutoCAD مناسب است؟

Intel HD و UHD می‌توانند برای نقشه‌کشی دوبعدی،
آموزش و پروژه‌های سبک AutoCAD قابل استفاده باشند.

برای مدل‌سازی سه‌بعدی، فایل‌های بزرگ، چند نمایشگر یا
محیط حرفه‌ای، GPU مجزا معمولاً انتخاب مناسب‌تری است.

HD 3000 و HD 4000 برای نسخه‌های جدید نرم‌افزار محدود
هستند و باید سازگاری DirectX، OpenGL و درایور بررسی
شود.

آیا Intel Iris Xe برای Photoshop مناسب است؟

Iris Xe برای ویرایش عکس، شتاب‌دهی رابط کاربری و بسیاری
از قابلیت‌های Photoshop مناسب است؛ به‌خصوص اگر دستگاه
RAM کافی و حافظه دوکاناله داشته باشد.

برای فایل‌های بسیار سنگین، چند نمایشگر با وضوح بالا،
هوش مصنوعی یا پردازش حرفه‌ای طولانی، کارت گرافیک مجزا
می‌تواند عملکرد بهتری ارائه کند.

آیا Intel Arc برای Premiere Pro مناسب است؟

کارت‌های Arc به دلیل موتور رسانه و پشتیبانی از
رمزگذاری و رمزگشایی سخت‌افزاری می‌توانند در تدوین و
خروجی ویدئو مفید باشند.

عملکرد دقیق به نسخه Premiere Pro، کدک ویدئو، درایور،
پردازنده مرکزی، حافظه RAM و تنظیمات پروژه وابسته است.

آیا Intel Arc برای Blender مناسب است؟

کارت‌های Arc می‌توانند در Viewport، مدل‌سازی و بعضی
موتورهای رندر Blender استفاده شوند.

پیش از خرید باید پشتیبانی نسخه Blender، Backend
رندر، درایور و ظرفیت VRAM کارت بررسی شود.

آیا Intel Arc برای هوش مصنوعی مناسب است؟

GPUهای Arc دارای واحدهای XMX برای پردازش‌های ماتریسی
و هوش مصنوعی هستند.

بااین‌حال انتخاب GPU برای AI فقط به توان سخت‌افزار
بستگی ندارد. سازگاری کتابخانه، فریم‌ورک، سیستم‌عامل،
درایور و ابزارهای توسعه Intel نیز باید بررسی شود.

Intel oneAPI چیست؟

oneAPI مجموعه‌ای از ابزارها و مدل‌های برنامه‌نویسی
Intel برای استفاده از CPU، GPU و سایر شتاب‌دهنده‌ها
است.

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

تفاوت Intel Arc و گرافیک مجتمع Intel

مقایسه Intel Arc با گرافیک مجتمع Intel
معیار گرافیک مجتمع Intel Intel Arc مجزا
محل قرارگیری داخل پردازنده یا مجموعه پردازشی GPU یا کارت مجزا
حافظه استفاده از RAM سیستم معمولاً حافظه گرافیکی اختصاصی
توان پردازشی سبک تا متوسط متوسط تا سنگین
مصرف برق کمتر بیشتر
Ray Tracing وابسته به نسل و معمولاً محدود واحدهای اختصاصی در Arc
هوش مصنوعی قابلیت‌های محدودتر استفاده از XMX در مدل‌های سازگار

راهنمای خرید لپ‌تاپ با گرافیک Intel

  • مدل دقیق پردازنده و GPU را بررسی کنید.
  • فقط به عبارت Intel HD یا UHD اکتفا نکنید.
  • تعداد کانال‌های RAM را بررسی کنید.
  • امکان ارتقای RAM را کنترل کنید.
  • نسخه درایور و سیستم‌عامل سازگار را بررسی کنید.
  • پشتیبانی سخت‌افزاری از کدک‌های ویدئویی را کنترل کنید.
  • برای بازی، نتایج همان GPU و همان پیکربندی RAM را
    بررسی کنید.
  • برای کار حرفه‌ای، وجود GPU مجزا را در نظر بگیرید.

راهنمای خرید Intel Arc دست‌دوم

  • سازگاری مادربرد با Resizable BAR را بررسی کنید.
  • ظرفیت و نوع حافظه VRAM را کنترل کنید.
  • کارت را با آخرین درایور پایدار آزمایش کنید.
  • خروجی‌های HDMI و DisplayPort را تست کنید.
  • دمای GPU و حافظه را تحت بار بررسی کنید.
  • عملکرد کارت را در DirectX 11 و DirectX 12 آزمایش کنید.
  • سلامت فن‌ها و عدم وجود صدای غیرعادی را کنترل کنید.
  • توان پاور و کانکتورهای موردنیاز را بررسی کنید.
  • عملکرد موتور ویدئو و AV1 را در صورت نیاز آزمایش کنید.


Arc روی سیستم بسیار قدیمی ممکن است انتخاب مناسبی نباشد

نبود Resizable BAR، پردازنده قدیمی، نسخه قدیمی
PCI Express یا درایور ناسازگار می‌تواند باعث کاهش
عملکرد کارت Arc شود. سازگاری کل پلتفرم باید پیش از
خرید بررسی شود.

سوالات متداول درباره گرافیک‌های Intel

آیا Intel HD Graphics کارت گرافیک مجزا است؟

معمولاً خیر. Intel HD Graphics داخل
پردازنده قرار دارد و از RAM سیستم استفاده
می‌کند.

تفاوت Intel HD و Intel UHD چیست؟

UHD نام تجاری نسل‌های جدیدتر است؛ اما
نام به‌تنهایی قدرت GPU را مشخص نمی‌کند.
مدل دقیق و نسل پردازنده باید بررسی شود.

آیا HD 4000 برای Windows جدید مناسب است؟

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

آیا HD 4600 برای AutoCAD کافی است؟

برای نقشه‌کشی دوبعدی و پروژه‌های سبک ممکن
است کافی باشد؛ اما برای مدل‌سازی سه‌بعدی
و پروژه‌های بزرگ محدود است.

آیا Iris Xe برای بازی مناسب است؟

برای بعضی بازی‌های سبک و رقابتی مناسب است.
عملکرد آن به مدل پردازنده، توان و RAM
دوکاناله وابسته است.

Intel Arc چیست؟

Arc خانواده GPUهای مجزای Intel برای بازی،
تولید محتوا، Ray Tracing و پردازش هوش
مصنوعی است.

تفاوت Arc A-Series و B-Series چیست؟

A-Series از معماری Xe-HPG و نسل Alchemist
استفاده می‌کند؛ B-Series نسل جدیدتر مبتنی
بر Xe2 است.

آیا Intel Arc به Resizable BAR نیاز دارد؟

برای دستیابی به عملکرد مناسب، فعال‌بودن
Resizable BAR در بسیاری از سیستم‌ها بسیار
مهم است.

XeSS چیست؟

XeSS فناوری بازسازی و افزایش وضوح تصویر
Intel برای افزایش نرخ فریم در بازی‌های
پشتیبانی‌شده است.

آیا Intel Arc برای تدوین مناسب است؟

بله، موتور رسانه و پشتیبانی از کدک‌های
جدید می‌تواند در تدوین و خروجی ویدئو مفید
باشد؛ سازگاری نرم‌افزار باید بررسی شود.

Arc Pro چه تفاوتی با Arc معمولی دارد؟

Arc Pro برای ورک‌استیشن و نرم‌افزارهای
حرفه‌ای طراحی شده و از درایورها و قابلیت‌های
سازمانی متفاوتی استفاده می‌کند.

آیا می‌توان CUDA را روی Intel Arc اجرا کرد؟

CUDA فناوری اختصاصی NVIDIA است. برای Intel
باید از ابزارها و Backendهای سازگار مانند
oneAPI یا رابط‌های پشتیبانی‌شده نرم‌افزار
استفاده شود.


فصل ۱۵

ساختمان داخلی GPU و اجزای پردازنده گرافیکی

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

ساختمان کلی GPU

GPU یک تراشه پیچیده است که برای اجرای تعداد زیادی
عملیات به‌صورت موازی طراحی شده است. برخلاف CPU که
معمولاً تعداد محدودی هسته قدرتمند و انعطاف‌پذیر
دارد، GPU از تعداد زیادی واحد پردازشی کوچک‌تر
استفاده می‌کند.

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

ساختمان دقیق GPU میان NVIDIA، AMD و Intel متفاوت
است؛ اما بیشتر پردازنده‌های گرافیکی مدرن از
بخش‌هایی با وظایف مشابه تشکیل می‌شوند.

تفاوت تراشه GPU با کل کارت گرافیک

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

داخل تراشه GPU

  • واحدهای Shader
  • هسته‌های CUDA یا واحدهای معادل
  • واحدهای Tensor یا AI
  • واحدهای Ray Tracing
  • TMU و ROP
  • حافظه‌های کش
  • زمان‌بندها و Registerها
  • کنترل‌کننده‌های حافظه

روی کارت گرافیک

  • تراشه GPU
  • تراشه‌های VRAM
  • مدار تنظیم ولتاژ
  • برد مدار چاپی
  • هیت‌سینک و فن
  • کانکتورهای برق
  • درگاه‌های تصویر
  • BIOS یا Firmware کارت

Die یا سطح سیلیکونی GPU چیست؟

واژه
Die
به قطعه فیزیکی سیلیکون گفته می‌شود که مدارهای
پردازنده گرافیکی روی آن ساخته شده‌اند.

میلیاردها ترانزیستور، واحد پردازشی، حافظه کش،
مسیرهای ارتباطی و کنترل‌کننده‌ها روی این بخش
بسیار کوچک قرار می‌گیرند.

Die زیر محافظ یا پکیج تراشه قرار دارد و از طریق
اتصالات بسیار ریز با برد کارت گرافیک و حافظه‌های
اطراف آن ارتباط برقرار می‌کند.


ترانزیستور چیست؟

ترانزیستور یک کلید الکترونیکی بسیار کوچک است.
میلیاردها ترانزیستور با ترکیب و هماهنگی یکدیگر،
عملیات منطقی و محاسباتی GPU را اجرا می‌کنند.

طراحی یکپارچه و Chiplet

در طراحی یکپارچه یا
Monolithic،
بیشتر اجزای اصلی GPU روی یک Die قرار دارند.

در طراحی
Chiplet،
تراشه می‌تواند از چند بخش سیلیکونی تشکیل شود که
هرکدام وظیفه مشخصی دارند و از طریق ارتباط پرسرعت
با یکدیگر کار می‌کنند.

مقایسه طراحی یکپارچه و Chiplet در GPU
معیار طراحی یکپارچه طراحی Chiplet
تعداد قطعات سیلیکونی معمولاً یک Die اصلی دو یا چند بخش مرتبط
ارتباط داخلی مسیرهای داخل همان Die ارتباط میان Chipletها
انعطاف طراحی محدودتر امکان ترکیب بخش‌های متفاوت
پیچیدگی طراحی تراشه بزرگ طراحی اتصال و هماهنگی چند تراشه
نمونه کاربرد بسیاری از GPUهای NVIDIA، AMD و Intel بعضی GPUهای جدید AMD و شتاب‌دهنده‌های پیشرفته

Front End یا بخش ورودی GPU

بخش ورودی GPU دستورها و داده‌های ارسالی از CPU،
درایور و نرم‌افزار را دریافت و برای پردازش آماده
می‌کند.

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

نام و ساختار دقیق Front End میان معماری‌های مختلف
متفاوت است، اما معمولاً وظایفی مانند دریافت
Command، مدیریت صف‌ها و آماده‌سازی پردازش را بر
عهده دارد.

Command Processor چیست؟

Command Processor دستورهای ارسال‌شده از برنامه
و درایور را می‌خواند و آن‌ها را به عملیات قابل
اجرا برای بخش‌های مختلف GPU تبدیل می‌کند.

این دستورها می‌توانند مربوط به رسم یک صحنه،
اجرای یک Shader، انتقال داده، محاسبه هوش مصنوعی
یا پردازش ویدئو باشند.

GPUهای جدید می‌توانند چند صف کاری را مدیریت کنند؛
برای نمونه، یک صف برای گرافیک و صف دیگری برای
Compute یا انتقال داده.

Geometry Engine چیست؟

موتور هندسه اطلاعات مربوط به رأس‌ها، خطوط،
مثلث‌ها و ساختار اولیه مدل‌های سه‌بعدی را پردازش
می‌کند.

بیشتر مدل‌های سه‌بعدی از تعداد زیادی مثلث ساخته
می‌شوند. موتور هندسه موقعیت رأس‌ها را با توجه به
دوربین، زاویه دید و تبدیل‌های سه‌بعدی محاسبه
می‌کند.

برخی وظایف هندسی در Shaderهای قابل برنامه‌ریزی
اجرا می‌شوند و بعضی عملیات نیز توسط واحدهای ثابت
یا اختصاصی معماری انجام می‌گیرند.

Tessellation Engine چیست؟

Tessellation فرایندی است که سطح هندسی ساده را به
تعداد بیشتری چندضلعی کوچک‌تر تقسیم می‌کند.

این کار می‌تواند جزئیات مدل، سطح زمین، چهره،
پارچه یا اشیای منحنی را افزایش دهد؛ بدون اینکه
مدل اولیه از ابتدا با تعداد بسیار زیادی Polygon
ساخته شده باشد.


Tessellation بیشتر همیشه بهتر نیست

افزایش بیش‌ازحد جزئیات هندسی می‌تواند بار
پردازشی GPU را بالا ببرد، در حالی که تفاوت
بصری آن در فاصله زیاد یا وضوح پایین محسوس
نباشد.

Raster Engine چیست؟

پس از پردازش هندسه، شکل‌های سه‌بعدی باید به
مجموعه‌ای از نقاط قابل نمایش روی صفحه تبدیل شوند.
این فرایند
Rasterization
نام دارد.

موتور Raster مشخص می‌کند هر مثلث یا سطح روی کدام
قسمت تصویر قرار می‌گیرد و کدام پیکسل‌ها یا
Fragmentها باید برای پردازش بعدی تولید شوند.

Rasterization روش اصلی تولید تصویر در بیشتر
بازی‌ها و نرم‌افزارهای سه‌بعدی است؛ حتی زمانی که
Ray Tracing نیز در بخشی از صحنه استفاده می‌شود.

Shader Cluster چیست؟

بخش بزرگی از سطح GPU به مجموعه‌های پردازشی قابل
برنامه‌ریزی اختصاص دارد. این مجموعه‌ها دستورهای
Shader و محاسبات موازی را اجرا می‌کنند.

NVIDIA این مجموعه‌ها را در بسیاری از معماری‌ها
با نام
Streaming Multiprocessor
یا SM معرفی می‌کند.

AMD از ساختارهایی مانند
Compute Unit
و در معماری‌های جدیدتر از گروه‌بندی‌های مرتبط با
Workgroup Processor استفاده می‌کند.

Intel نیز در معماری Xe از Xe Core و ساختارهای
مرتبط برای سازمان‌دهی واحدهای پردازشی استفاده
می‌کند.

نام گروه‌های پردازشی در معماری‌های مختلف
شرکت نام رایج گروه پردازشی واحدهای داخل آن
NVIDIA Streaming Multiprocessor یا SM CUDA Core، Tensor Core، Register،
Scheduler و حافظه مشترک
AMD Compute Unit یا ساختارهای جدیدتر WGP Stream Processor، Scheduler،
Register و حافظه محلی
Intel Xe Core واحدهای برداری، XMX، Register و
منابع پردازشی مشترک


چرا نام‌ها متفاوت‌اند؟

هر شرکت معماری و نام‌گذاری اختصاصی خود را دارد.
به همین دلیل نمی‌توان یک SM، یک Compute Unit و
یک Xe Core را بدون بررسی ساختار داخلی، مستقیماً
معادل یکدیگر دانست.

واحدهای ثابت یا Fixed Function

همه وظایف GPU توسط Shaderهای قابل برنامه‌ریزی
انجام نمی‌شوند. برخی عملیات توسط مدارهایی اجرا
می‌شوند که برای وظیفه مشخصی طراحی شده‌اند.

به این مدارها معمولاً واحدهای
Fixed Function
گفته می‌شود.

  • واحدهای پردازش بافت
  • واحدهای خروجی رندر
  • موتور Raster
  • موتورهای رمزگذاری ویدئو
  • موتورهای رمزگشایی ویدئو
  • واحدهای Ray Tracing
  • واحدهای نمایشگر
  • کنترل‌کننده‌های حافظه

استفاده از سخت‌افزار اختصاصی می‌تواند بعضی عملیات
را سریع‌تر و کم‌مصرف‌تر از اجرای همان وظیفه روی
واحدهای عمومی انجام دهد.

واحدهای پردازش بافت

واحدهای پردازش بافت یا TMU داده‌های Texture را
نمونه‌برداری و فیلتر می‌کنند.

زمانی که یک بافت روی سطح مدل سه‌بعدی قرار می‌گیرد،
GPU باید مشخص کند هر نقطه از بافت چگونه روی پیکسل
نهایی نمایش داده شود.

فیلترهایی مانند Bilinear، Trilinear و Anisotropic
Filtering با پردازش بافت ارتباط دارند.

TMU در یکی از زیرمرحله‌های بعدی این فصل به‌صورت
کامل توضیح داده خواهد شد.

واحدهای خروجی رندر یا ROP

ROPها در مراحل پایانی تولید تصویر نقش دارند و
عملیاتی مانند ترکیب رنگ، نوشتن نتیجه در Frame
Buffer و بعضی آزمون‌های عمق را انجام می‌دهند.

تعداد و ساختار ROP می‌تواند در عملکرد وضوح‌های
بالا، نرخ پرکردن پیکسل و بعضی روش‌های
Anti-Aliasing اثر داشته باشد.

تعداد ROP نیز مانند تعداد CUDA Core یا Stream
Processor به‌تنهایی معیار کامل قدرت GPU نیست.

سلسله‌مراتب حافظه کش GPU

GPU برای کاهش زمان دسترسی به داده‌ها از چند سطح
حافظه سریع استفاده می‌کند.

این حافظه‌ها ممکن است شامل Register، حافظه محلی،
Shared Memory، کش L0، کش L1، کش L2 و در بعضی
معماری‌ها حافظه‌های کش بزرگ‌تری مانند Infinity
Cache باشند.

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

Register

حافظه بسیار سریع داخل واحد پردازشی برای
نگهداری داده‌های فعال هر Thread.

Shared یا Local Memory

حافظه سریع مشترک میان گروهی از Threadها
یا واحدهای یک بلوک پردازشی.

L1 Cache

کش نزدیک به واحدهای پردازشی برای کاهش
مراجعه به حافظه‌های دورتر.

L2 Cache

حافظه کش بزرگ‌تر که میان بخش‌های بیشتری
از GPU مشترک است.

Last-Level Cache

کش بزرگ‌تر در بعضی معماری‌ها برای کاهش
مراجعه مستقیم به VRAM.

VRAM

حافظه اصلی گرافیکی برای نگهداری داده‌های
بزرگ‌تر مانند بافت، مدل و Frame Buffer.

کنترل‌کننده حافظه GPU

کنترل‌کننده حافظه ارتباط میان GPU و تراشه‌های
VRAM را مدیریت می‌کند.

داده‌ها باید از مسیرهای حافظه خوانده یا در آن‌ها
نوشته شوند. کنترل‌کننده تعیین می‌کند درخواست‌ها
چگونه زمان‌بندی و میان کانال‌های حافظه توزیع شوند.

تعداد کنترل‌کننده‌ها و عرض هر کانال در شکل‌گیری
پهنای رابط حافظه نقش دارد.

برای مثال، باس ۲۵۶ بیتی می‌تواند از چند کانال
کوچک‌تر تشکیل شده باشد که در مجموع یک رابط
۲۵۶ بیتی ایجاد می‌کنند.

شبکه ارتباط داخلی GPU

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

شبکه ارتباط داخلی، واحدهای Shader، حافظه‌های کش،
کنترل‌کننده‌های حافظه، موتورهای کپی و سایر بخش‌ها
را به یکدیگر متصل می‌کند.

طراحی این شبکه بر تأخیر، پهنای باند، مصرف برق و
مقیاس‌پذیری GPU اثر می‌گذارد.

Copy Engine یا موتور انتقال داده

GPUهای جدید ممکن است دارای موتورهای اختصاصی برای
انتقال داده باشند.

این موتورها می‌توانند داده‌ها را میان RAM،
VRAM یا بخش‌های مختلف حافظه جابه‌جا کنند؛ بدون
اینکه تمام منابع Shader درگیر عملیات کپی شوند.

وجود چند Copy Engine می‌تواند امکان هم‌پوشانی
انتقال داده با اجرای محاسبات را فراهم کند.

موتورهای ویدئویی داخل GPU

بسیاری از GPUها دارای واحدهای اختصاصی برای
رمزگذاری و رمزگشایی ویدئو هستند.

این واحدها می‌توانند پردازش کدک‌هایی مانند
H.264، H.265، VP9 یا AV1 را سریع‌تر و
کم‌مصرف‌تر از اجرای کامل روی Shaderها انجام دهند.

نام این موتور میان شرکت‌ها متفاوت است؛ مانند
NVENC و NVDEC در NVIDIA، موتورهای رسانه AMD و
Quick Sync یا Media Engine در Intel.

Display Engine چیست؟

موتور نمایش، خروجی تصویر، زمان‌بندی نمایشگر،
وضوح، نرخ نوسازی، عمق رنگ و ارتباط با درگاه‌هایی
مانند HDMI و DisplayPort را مدیریت می‌کند.

توان پردازشی بالای GPU لزوماً به معنی پشتیبانی از
تمام خروجی‌ها یا نرخ‌های نوسازی جدید نیست؛ زیرا
قابلیت Display Engine و نسخه رابط‌ها نیز اهمیت
دارد.

این موضوع در کارت‌های قدیمی Quadro، FirePro و
گرافیک‌های لپ‌تاپی اهمیت زیادی دارد.

مدیریت توان و فرکانس داخل GPU

GPU به‌صورت پیوسته دما، بار پردازشی، توان مصرفی و
محدودیت‌های تعیین‌شده را بررسی می‌کند.

فرکانس و ولتاژ بخش‌های مختلف می‌توانند متناسب با
نیاز افزایش یا کاهش یابند.

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

اگر دما یا مصرف برق از حد تعیین‌شده عبور کند،
GPU ممکن است فرکانس را کاهش دهد. این رفتار
Thermal Throttling یا Power Throttling نامیده
می‌شود.

دیاگرام ساده ساختمان داخلی GPU

مسیر کلی حرکت داده در GPU


مرحله ۱


ارسال دستور از نرم‌افزار

بازی یا نرم‌افزار از طریق API و درایور،
دستورها و داده‌های موردنیاز را آماده می‌کند.


مرحله ۲


ورود به صف پردازش

دستورها در صف‌های گرافیکی، Compute یا
انتقال داده قرار می‌گیرند.


مرحله ۳


آماده‌سازی هندسه

رأس‌ها، مدل‌ها و موقعیت عناصر سه‌بعدی
پردازش می‌شوند.


مرحله ۴


Rasterization

شکل‌های هندسی به Fragmentهای قابل پردازش
برای تصویر تبدیل می‌شوند.


مرحله ۵


اجرای Shaderها

رنگ، نور، سایه، بافت و دیگر محاسبات توسط
واحدهای پردازشی اجرا می‌شوند.


مرحله ۶


پردازش بافت و خروجی

TMUها، ROPها و واحدهای ثابت نتیجه را برای
Frame Buffer آماده می‌کنند.


مرحله ۷


ذخیره در VRAM

تصویر نهایی یا داده محاسباتی در حافظه
گرافیکی نوشته می‌شود.


مرحله ۸


نمایش یا تحویل نتیجه

تصویر برای نمایشگر ارسال می‌شود یا نتیجه
محاسبات در اختیار نرم‌افزار قرار می‌گیرد.

ساختمان GPU در NVIDIA، AMD و Intel

نام بخش‌های مشابه در معماری‌های مختلف
وظیفه NVIDIA AMD Intel
گروه پردازشی SM CU یا WGP Xe Core
واحد محاسباتی عمومی CUDA Core Stream Processor Vector Engine
پردازش ماتریسی و AI Tensor Core Matrix یا AI Accelerator XMX
Ray Tracing RT Core Ray Accelerator Ray Tracing Unit
کش بزرگ اختصاصی L2 Cache بزرگ‌تر در نسل‌های جدید Infinity Cache در مدل‌های سازگار کش متناسب با معماری Xe

ساختمان داخلی در کارت‌های Quadro و ورک‌استیشن

کارت‌های
NVIDIA Quadro
و
NVIDIA RTX Professional
از همان اصول کلی معماری GPUهای NVIDIA استفاده
می‌کنند؛ اما ممکن است پیکربندی سخت‌افزاری،
ظرفیت حافظه، قابلیت ECC، درایور و محدودیت توان
متفاوتی داشته باشند.

برای نمونه، Quadro K بر پایه معماری Kepler،
Quadro M بر پایه Maxwell، Quadro P بر پایه
Pascal و Quadro RTX بر پایه Turing ساخته شده‌اند.

کارت‌های RTX A Series و RTX Professional جدیدتر
نیز از معماری‌های Ampere، Ada یا نسل‌های بعدی
استفاده می‌کنند.

ساختار اصلی پردازشی می‌تواند با GeForce هم‌نسل
شباهت داشته باشد، اما تفاوت در ظرفیت VRAM،
درایور حرفه‌ای، قابلیت‌های سازمانی و پایداری
نرم‌افزاری اهمیت دارد.

همین موضوع درباره AMD FirePro، Radeon Pro و
Intel Arc Pro نیز صدق می‌کند.

ساختار GPU در کارت‌های قدیمی

کارت‌های قدیمی نیز بسیاری از اجزای پایه مانند
Shader، TMU، ROP، حافظه کش و کنترل‌کننده حافظه
را داشتند؛ اما تعداد، ساختار و قابلیت این بخش‌ها
ساده‌تر بود.

برای مثال:

  • GeForce 9600 GT از نسل قدیمی Tesla است.
  • Quadro K2100M بر پایه Kepler ساخته شده است.
  • Quadro M2000M از معماری Maxwell استفاده می‌کند.
  • Quadro P2000 بر پایه Pascal است.
  • Radeon HD 5450 به دوره Terascale تعلق دارد.
  • Radeon RX 580 از معماری Polaris استفاده می‌کند.
  • Intel HD 4000 یک گرافیک مجتمع نسل قدیمی Intel است.
  • Intel UHD 620 از گرافیک مجتمع جدیدتری نسبت به
    HD 4000 استفاده می‌کند.

معماری قدیمی‌تر معمولاً به معنی نبود واحدهای
اختصاصی Tensor، RT یا XMX و محدودیت بیشتر در
درایور، API و موتورهای ویدئویی است.

اشتباهات رایج درباره ساختمان GPU

مقایسه مستقیم تعداد هسته‌ها

CUDA Core، Stream Processor و Xe Core
معادل مستقیم یکدیگر نیستند.

برابر دانستن GPU با کارت گرافیک

GPU فقط تراشه پردازشی است؛ کارت گرافیک
شامل اجزای بیشتری است.

توجه فقط به اندازه Die

Die بزرگ‌تر لزوماً به معنی عملکرد بهتر یا
بهره‌وری بالاتر نیست.

توجه فقط به تعداد ترانزیستور

نوع معماری و کاربرد ترانزیستورها به اندازه
تعداد آن‌ها اهمیت دارد.

تصور اینکه Ray Tracing کل تصویر را می‌سازد

بیشتر بازی‌ها ترکیبی از Rasterization و
Ray Tracing را استفاده می‌کنند.

تصور اینکه تمام واحدها همیشه فعال‌اند

نوع برنامه و بار پردازشی تعیین می‌کند کدام
واحدهای GPU بیشتر استفاده شوند.

هنگام خرید، کدام بخش ساختمان GPU مهم‌تر است؟

پاسخ به نوع استفاده بستگی دارد.

اجزای مهم GPU بر اساس نوع کاربرد
نوع استفاده بخش‌های مهم‌تر نکته
بازی Shader، TMU، ROP، کش و پهنای حافظه نتایج آزمون واقعی مهم‌تر از یک عدد منفرد است
Ray Tracing واحدهای RT، Shader و AI نسل واحدها نیز اهمیت دارد
هوش مصنوعی واحدهای ماتریسی، VRAM و پهنای حافظه سازگاری نرم‌افزاری تعیین‌کننده است
CAD و SolidWorks پایداری درایور، VRAM و توان Viewport Quadro یا RTX Professional ممکن است مزیت داشته باشد
Blender و رندر هسته‌های Compute، VRAM و Backend رندر موتور رندر باید از GPU پشتیبانی کند
تدوین ویدئو موتور رسانه، VRAM و Shader پشتیبانی کدک بسیار مهم است
لپ‌تاپ استوک معماری، توان، خنک‌کننده و درایور نام GPU به‌تنهایی کافی نیست


فصل ۱۵-۲

Shader، CUDA Core، Stream Processor و Xe Core چیست؟

بخش بزرگی از توان پردازنده گرافیکی توسط واحدهای
پردازشی قابل‌برنامه‌ریزی تأمین می‌شود. این واحدها
محاسبات مربوط به تصویر، نور، رنگ، هندسه، فیزیک،
رندر، ویدئو و پردازش‌های موازی را اجرا می‌کنند.

Shader چیست؟

Shader برنامه‌ای کوچک است که روی GPU اجرا می‌شود
و نحوه پردازش بخشی از داده‌های گرافیکی یا محاسباتی
را مشخص می‌کند.

Shader می‌تواند موقعیت یک رأس سه‌بعدی، رنگ یک
پیکسل، نحوه تابش نور، شکل سایه، حرکت ذرات، کیفیت
بافت یا نتیجه یک محاسبه موازی را تعیین کند.

واژه Shader در ابتدا بیشتر با محاسبات نور و سایه
ارتباط داشت؛ اما امروزه Shaderها دامنه بسیار
گسترده‌تری از وظایف را اجرا می‌کنند.


Shader یک قطعه فیزیکی نیست

Shader معمولاً یک برنامه یا مجموعه دستور است.
واحدهای پردازشی داخل GPU این دستورها را اجرا
می‌کنند. بنابراین Shader را نباید با CUDA Core
یا Stream Processor یکسان دانست.

انواع Shader در مسیر رندر

Vertex Shader

اطلاعات رأس‌های مدل سه‌بعدی را پردازش می‌کند.
تغییر موقعیت، مقیاس، چرخش و تبدیل مختصات از
وظایف رایج این مرحله است.

Pixel یا Fragment Shader

رنگ نهایی، نور، سایه، بافت و بسیاری از
افکت‌های مربوط به پیکسل یا Fragment را
محاسبه می‌کند.

Geometry Shader

می‌تواند Primitiveهای هندسی را دریافت،
تغییر یا تولید کند. کاربرد آن به موتور
گرافیکی و API بستگی دارد.

Tessellation Shader

میزان تقسیم سطوح هندسی را کنترل می‌کند تا
جزئیات مدل در بخش‌های لازم افزایش پیدا کند.

Compute Shader

برای محاسبات عمومی موازی استفاده می‌شود و
الزاماً بخشی از تولید مستقیم تصویر نیست.

Mesh Shader

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

معماری Unified Shader چیست؟

در نسل‌های قدیمی‌تر کارت گرافیک، بعضی واحدها فقط
برای پردازش Vertex و بعضی دیگر فقط برای Pixel
Shader طراحی شده بودند.

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

این روش استفاده انعطاف‌پذیرتری از منابع GPU فراهم
می‌کند؛ زیرا اگر یک صحنه به پردازش پیکسلی بیشتری
نیاز داشته باشد، منابع بیشتری می‌توانند به همان
وظیفه اختصاص داده شوند.

معماری قدیمی‌تر

  • واحدهای جدا برای وظایف مشخص
  • انعطاف کمتر در توزیع بار
  • احتمال بیکارماندن بخشی از منابع

Unified Shader

  • واحدهای پردازشی قابل‌برنامه‌ریزی‌تر
  • توزیع منعطف‌تر وظایف
  • مناسب برای گرافیک و Compute

CUDA Core چیست؟

CUDA Core نام رایج واحدهای محاسباتی اسکالر یا
برداری در بسیاری از GPUهای NVIDIA است.

این واحدها دستورهای ریاضی موردنیاز Shaderها،
پردازش تصویر، فیزیک، رندر، شبیه‌سازی و محاسبات
موازی را اجرا می‌کنند.

CUDA Coreها داخل گروه‌هایی مانند
Streaming Multiprocessor
یا SM سازمان‌دهی می‌شوند و همراه با Scheduler،
Register، حافظه کش و سایر واحدها فعالیت می‌کنند.


CUDA Core با هسته CPU برابر نیست

هسته CPU واحدی پیچیده و مناسب اجرای طیف
گسترده‌ای از دستورها است. CUDA Core واحد
کوچک‌تری برای اجرای حجم زیادی از عملیات موازی
محسوب می‌شود.

CUDA چیست؟

CUDA نام پلتفرم برنامه‌نویسی و اکوسیستم محاسبات
موازی NVIDIA است. CUDA Core نیز نام واحدهای
پردازشی سازگار با این معماری در GPUهای NVIDIA
محسوب می‌شود.

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

CUDA Core در چه کارهایی استفاده می‌شود؟

  • اجرای Shaderهای بازی
  • رندر سه‌بعدی
  • پردازش تصویر و ویدئو
  • شبیه‌سازی علمی
  • فیزیک و ذرات
  • یادگیری ماشین
  • محاسبات مهندسی
  • اجرای Compute Shader

آیا CUDA Core بیشتر همیشه بهتر است؟

خیر. تعداد CUDA Core فقط در کنار معماری، فرکانس،
پهنای حافظه، ظرفیت VRAM، توان مصرفی و نوع برنامه
معنا پیدا می‌کند.

برای نمونه، تعداد هسته‌های یک کارت قدیمی را نباید
مستقیماً با کارت جدیدی از معماری متفاوت مقایسه کرد.
هسته‌های نسل جدید ممکن است در هر سیکل کار بیشتری
انجام دهند یا ساختار متفاوتی داشته باشند.

CUDA Core در GeForce و Quadro قدیمی

کارت‌های قدیمی NVIDIA نیز دارای واحدهای پردازشی
سازگار با معماری CUDA بودند؛ اما نسل معماری،
Compute Capability و پشتیبانی نرم‌افزاری آن‌ها
محدودتر است.

نمونه خانواده‌های قدیمی و حرفه‌ای NVIDIA
خانواده معماری نمونه مدل کاربرد تقریبی امروز
GeForce 400 و 500 Fermi GTX 460، GTX 560 Ti نرم‌افزارها و بازی‌های قدیمی
Quadro K عمدتاً Kepler K1100M، K2100M، K2200 CAD و طراحی سبک یا قدیمی
Quadro M Maxwell M1000M، M2000M، M4000M مدل‌سازی و طراحی متوسط
GeForce GTX 10 Pascal GTX 1050 Ti، GTX 1060 بازی، تدوین و Compute متوسط
Quadro P Pascal P1000، P2000، P4000 CAD، طراحی و رندر سبک تا متوسط
Quadro RTX Turing Quadro RTX 3000 و 4000 رندر، CAD و قابلیت‌های RTX
RTX A Series Ampere RTX A2000 و A4000 ورک‌استیشن، رندر و AI


در Quadro فقط تعداد CUDA Core مهم نیست

نوع درایور، تأییدیه نرم‌افزار، ظرفیت VRAM،
محدودیت توان و نسل معماری می‌توانند برای
SolidWorks، CATIA، Maya و نرم‌افزارهای
حرفه‌ای مهم‌تر از تعداد خام هسته‌ها باشند.

Stream Processor چیست؟

Stream Processor نام رایج واحدهای پردازشی در
مشخصات بسیاری از GPUهای AMD است.

این واحدها عملیات ریاضی مربوط به Shader، گرافیک،
پردازش تصویر و Compute را اجرا می‌کنند و در
ساختارهایی مانند Compute Unit یا WGP سازمان‌دهی
می‌شوند.

وظیفه کلی آن‌ها از بعضی جهات به CUDA Core نزدیک
است؛ اما ساختار داخلی، نحوه زمان‌بندی و معماری
دو شرکت متفاوت است.


CUDA Core و Stream Processor را عددی مقایسه نکنید

نمی‌توان گفت یک CUDA Core دقیقاً برابر یک
Stream Processor است. فقط نتایج آزمون واقعی
و عملکرد در برنامه موردنظر مقایسه قابل‌اعتماد
ایجاد می‌کند.

Stream Processor در GCN

در معماری GCN، واحدهای پردازشی داخل Compute Unit
سازمان‌دهی می‌شدند و گروه‌های کاری با ساختاری
متناسب با Wavefront اجرا می‌شدند.

کارت‌هایی مانند Radeon HD 7000، سری R9،
RX 470، RX 570 و RX 580 از نسل‌های مختلف GCN
استفاده می‌کنند.

Stream Processor در RDNA

معماری RDNA ساختار داخلی و نحوه اجرای دستورها را
نسبت به GCN تغییر داد. به همین دلیل مقایسه صرف
تعداد Stream Processor میان RX 580 و یک کارت
RDNA جدید، تصویر کاملی از عملکرد ارائه نمی‌دهد.

Stream Processor در Radeon Pro

کارت‌های Radeon Pro و FirePro نیز از واحدهای
پردازشی AMD استفاده می‌کنند، اما درایور حرفه‌ای،
ظرفیت حافظه و ویژگی‌های ورک‌استیشن آن‌ها متفاوت
است.

Xe Core چیست؟

Xe Core یکی از بلوک‌های پردازشی اصلی در معماری‌های
جدید گرافیکی Intel است.

هر Xe Core می‌تواند شامل موتورهای برداری،
Registerها، واحدهای بارگذاری و ذخیره داده و در
بعضی نسل‌ها واحدهای ماتریسی XMX باشد.

Xe Core یک واحد ساده و منفرد مانند یک هسته کوچک
نیست؛ بلکه مجموعه‌ای از منابع پردازشی را در خود
جای می‌دهد.

Vector Engine در Intel

موتورهای برداری داخل GPUهای Intel دستورهای
Shader و محاسبات عددی را روی چند داده به‌صورت
هم‌زمان اجرا می‌کنند.

Xe Core در Intel Arc

کارت‌های Intel Arc از Xe Coreها برای اجرای
پردازش‌های گرافیکی، Compute، Ray Tracing و
وظایف مرتبط با تولید محتوا استفاده می‌کنند.

Xe Core در Arc Pro

کارت‌های Arc Pro نیز بر پایه معماری Xe ساخته
می‌شوند، اما برای ورک‌استیشن، نرم‌افزارهای حرفه‌ای
و درایورهای سازمانی هدف‌گذاری شده‌اند.


Xe Core با CUDA Core قابل مقایسه مستقیم نیست

Xe Core یک بلوک شامل چند منبع پردازشی است،
در حالی که CUDA Core معمولاً به واحد محاسباتی
کوچک‌تری درون SM اشاره دارد.

مقایسه CUDA Core، Stream Processor و Xe Core

مقایسه مفهومی واحدهای پردازشی GPU
معیار CUDA Core Stream Processor Xe Core
شرکت NVIDIA AMD Intel
ماهیت نام واحد محاسباتی داخل SM واحد پردازشی داخل CU یا WGP بلوک پردازشی شامل چند منبع
اجرای Shader بله بله بله
اجرای Compute بله بله بله
واحد AI اختصاصی Tensor Core جداگانه بسته به معماری، واحدهای AI یا Matrix XMX در مدل‌های سازگار
مقایسه مستقیم تعداد معتبر نیست؛ معماری و ساختار متفاوت است

نمونه واحدهای پردازشی در کارت‌های قدیمی

بازار لپ‌تاپ و قطعات استوک شامل تعداد زیادی GPU
از معماری‌های قدیمی است. شناخت نسل معماری از تعداد
خام هسته‌ها مهم‌تر است.

نمونه کارت‌های قدیمی و نوع واحد پردازشی
مدل شرکت معماری نام واحد پردازشی
GeForce GT 740M NVIDIA معمولاً Kepler CUDA Core
GTX 960M NVIDIA Maxwell CUDA Core
Quadro K2100M NVIDIA Kepler CUDA Core
Quadro P2000 NVIDIA Pascal CUDA Core
Radeon HD 7970 AMD GCN Stream Processor
Radeon RX 580 AMD Polaris Stream Processor
Radeon Pro WX 7100 AMD Polaris Stream Processor
Intel HD 4000 Intel گرافیک مجتمع قدیمی Execution Unit
Intel Iris Xe Intel Xe-LP Execution Unit و ساختار Xe
Intel Arc Intel Xe-HPG یا Xe2 Xe Core

واحدهای پردازشی در Quadro، Radeon Pro و Arc Pro

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

تفاوت اصلی می‌تواند شامل ظرفیت حافظه، درایور،
پایداری، تأییدیه ISV، توان مصرفی و قابلیت‌های
سازمانی باشد.

NVIDIA Quadro و RTX Professional

از CUDA Core استفاده می‌کنند و در نسل‌های
جدید ممکن است Tensor Core و RT Core نیز
داشته باشند.

AMD FirePro و Radeon Pro

از واحدهای پردازشی AMD مانند Stream
Processor استفاده می‌کنند و با درایورهای
حرفه‌ای عرضه می‌شوند.

Intel Arc Pro

از ساختار Xe Core و در مدل‌های سازگار از
XMX و واحدهای Ray Tracing استفاده می‌کند.

نقش واحدهای پردازشی در نرم‌افزارهای مختلف

نقش واحدهای Shader و Compute در کاربردهای مختلف
کاربرد نقش واحدهای پردازشی عامل مهم دیگر
بازی اجرای Shader، نور، رنگ و افکت TMU، ROP، حافظه و درایور
AutoCAD نمایش Viewport و مدل سه‌بعدی CPU و پیچیدگی پروژه
SolidWorks نمایش مدل و افکت‌های Viewport درایور حرفه‌ای و گواهی ISV
Blender Viewport و رندر GPU Backend رندر و ظرفیت VRAM
Premiere Pro افکت، رنگ و شتاب‌دهی محاسبات موتور ویدئو و کدک
هوش مصنوعی محاسبات برداری و عددی واحدهای ماتریسی و اکوسیستم نرم‌افزار

هنگام خرید چگونه تعداد هسته‌ها را بررسی کنیم؟

  1. ابتدا مدل دقیق GPU و معماری آن را مشخص کنید.
  2. تعداد هسته‌ها را فقط با مدل‌های هم‌معماری
    مقایسه کنید.
  3. ظرفیت و پهنای باند VRAM را بررسی کنید.
  4. توان مصرفی و فرکانس واقعی کارت را کنترل کنید.
  5. نتایج نرم‌افزار یا بازی موردنظر خود را ببینید.
  6. در لپ‌تاپ، توان GPU و کیفیت خنک‌کننده را
    بررسی کنید.
  7. برای CAD، گواهی و درایور حرفه‌ای را بررسی کنید.
  8. برای AI، سازگاری فریم‌ورک و ظرفیت VRAM را
    در اولویت قرار دهید.


قاعده ساده خرید

به‌جای پرسیدن «کدام کارت هسته بیشتری دارد؟»،
بپرسید «کدام کارت در نرم‌افزار و پروژه من
سریع‌تر، پایدارتر و سازگارتر است؟»

اشتباهات رایج درباره هسته‌های GPU

  • برابر دانستن CUDA Core با هسته CPU
  • مقایسه مستقیم تعداد هسته‌های NVIDIA و AMD
  • مقایسه مستقیم Xe Core با CUDA Core
  • توجه نکردن به نسل معماری
  • نادیده‌گرفتن پهنای باند حافظه
  • فرض اینکه هسته بیشتر همیشه نرخ فریم بیشتری می‌دهد
  • نادیده‌گرفتن محدودیت توان در لپ‌تاپ
  • انتخاب Quadro فقط بر اساس تعداد CUDA Core
  • انتخاب کارت AI بدون بررسی سازگاری نرم‌افزاری

سؤالات متداول درباره Shader و هسته‌های GPU

Shader چیست؟

Shader برنامه‌ای کوچک است که روی GPU اجرا
می‌شود و عملیات گرافیکی یا محاسباتی مانند
نور، رنگ، هندسه و افکت را کنترل می‌کند.

CUDA Core چیست؟

CUDA Core واحد محاسباتی داخل GPUهای NVIDIA
است که دستورهای Shader و پردازش موازی را
اجرا می‌کند.

آیا CUDA Core همان هسته CPU است؟

خیر. هسته CPU بسیار پیچیده‌تر است و برای
وظایف عمومی طراحی شده؛ CUDA Core واحدی
کوچک‌تر برای اجرای عملیات موازی است.

Stream Processor چیست؟

Stream Processor نام رایج واحدهای
پردازشی داخل GPUهای AMD است که Shader و
عملیات محاسباتی را اجرا می‌کنند.

آیا CUDA Core و Stream Processor برابر هستند؟

خیر. ساختار و معماری آن‌ها متفاوت است و
تعدادشان نباید مستقیماً مقایسه شود.

Xe Core چیست؟

Xe Core بلوک پردازشی در معماری‌های جدید
Intel است و مجموعه‌ای از منابع برداری و
محاسباتی را در خود جای می‌دهد.

آیا تعداد هسته بیشتر همیشه بهتر است؟

خیر. معماری، فرکانس، حافظه، توان و نوع
نرم‌افزار نیز بر عملکرد نهایی اثر دارند.

چرا Quadro با CUDA Core کمتر ممکن است گران‌تر باشد؟

قیمت کارت حرفه‌ای فقط بر اساس تعداد هسته
نیست و عواملی مانند VRAM، درایور حرفه‌ای،
گواهی ISV، پایداری و قابلیت‌های سازمانی
در آن اثر دارند.


فصل ۱۵-۳

Tensor Core، RT Core، Ray Accelerator و XMX چیست؟

پردازنده‌های گرافیکی جدید علاوه بر واحدهای عمومی
اجرای Shader، از شتاب‌دهنده‌های اختصاصی برای
محاسبات ماتریسی، هوش مصنوعی و رهگیری پرتو استفاده
می‌کنند. نام و ساختار این واحدها در محصولات NVIDIA،
AMD و Intel متفاوت است.

شتاب‌دهنده اختصاصی داخل GPU چیست؟

واحدهای عمومی Shader می‌توانند طیف گسترده‌ای از
محاسبات را اجرا کنند؛ اما اجرای بعضی عملیات روی
سخت‌افزار اختصاصی، سریع‌تر و کم‌مصرف‌تر است.

به همین دلیل، پردازنده‌های گرافیکی جدید ممکن است
واحدهایی ویژه برای محاسبات ماتریسی، رهگیری پرتو،
پردازش ویدئو، نمونه‌برداری بافت یا تولید خروجی
تصویر داشته باشند.

این واحدها جایگزین کامل Shader Coreها نیستند.
معمولاً بخش‌های عمومی و اختصاصی GPU به‌صورت
هم‌زمان با یکدیگر کار می‌کنند.

واحدهای عمومی

عملیات Shader، محاسبات عددی عمومی و
پردازش‌های قابل‌برنامه‌ریزی را اجرا می‌کنند.

واحدهای ماتریسی

ضرب و جمع ماتریس‌ها و محاسبات رایج در
هوش مصنوعی را شتاب می‌دهند.

واحدهای Ray Tracing

محاسبات مربوط به برخورد پرتو با هندسه و
پیمایش ساختارهای فضایی را سریع‌تر می‌کنند.

موتورهای رسانه

رمزگذاری و رمزگشایی کدک‌های ویدئویی را
بدون درگیرکردن کامل Shaderها انجام می‌دهند.

Tensor Core چیست؟

Tensor Core نام واحدهای اختصاصی محاسبات ماتریسی
در تعدادی از GPUهای NVIDIA است.

این واحدها برای اجرای سریع عملیات ضرب و جمع
ماتریسی طراحی شده‌اند؛ عملیاتی که در آموزش و
اجرای شبکه‌های عصبی، پردازش تصویر، بازسازی تصویر
و بسیاری از محاسبات علمی تکرار می‌شوند.

Tensor Coreها در کنار CUDA Coreها قرار می‌گیرند.
CUDA Core وظایف عمومی‌تر را اجرا می‌کند و Tensor
Core بخش‌های سازگار از محاسبات ماتریسی را شتاب
می‌دهد.


Tensor در هوش مصنوعی یعنی چه؟

Tensor را می‌توان ساختاری چندبعدی برای نگهداری
داده‌های عددی دانست. یک عدد، بردار، ماتریس یا
آرایه‌ای با ابعاد بیشتر می‌تواند نوعی Tensor
باشد.


وجود Tensor Core به معنی اجرای خودکار هر برنامه نیست

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

نسل‌های Tensor Core

Tensor Core نخست در محصولات حرفه‌ای و محاسباتی
NVIDIA ظاهر شد و سپس وارد کارت‌های گیمینگ و
ورک‌استیشن RTX شد.

نسل‌های مختلف Tensor Core از نظر قالب‌های عددی،
توان عملیاتی، دقت، قابلیت پراکندگی و ویژگی‌های
مرتبط با هوش مصنوعی تفاوت دارند.

حضور Tensor Core در معماری‌های مهم NVIDIA
معماری نمونه محصولات وضعیت Tensor Core کاربرد شاخص
Volta Tesla V100، Titan V، Quadro GV100 نسل ابتدایی هوش مصنوعی و محاسبات علمی
Turing RTX 20، Quadro RTX حضور در گیمینگ و ورک‌استیشن DLSS، AI و رندر حرفه‌ای
Ampere RTX 30، RTX A Series نسل بهبودیافته AI، رندر و پردازش ماتریسی
Ada Lovelace RTX 40، RTX Ada توان و قابلیت‌های جدیدتر بازسازی تصویر و تولید فریم
نسل‌های جدیدتر RTX محصولات جدید مصرف‌کننده و حرفه‌ای متناسب با معماری هر نسل رندر عصبی و پردازش‌های AI


تعداد Tensor Core میان نسل‌ها قابل مقایسه مستقیم نیست

یک Tensor Core جدیدتر ممکن است از قالب‌های
عددی بیشتر یا توان عملیاتی بالاتری برخوردار
باشد. فقط تعداد خام این واحدها معیار کاملی
برای مقایسه نیست.

کاربردهای Tensor Core

آموزش مدل‌های هوش مصنوعی

شتاب‌دادن به محاسبات ماتریسی در شبکه‌های
عصبی و مدل‌های یادگیری عمیق.

اجرای مدل یا Inference

پردازش سریع‌تر ورودی و تولید خروجی توسط
مدل آموزش‌دیده.

بازسازی تصویر

استفاده در فناوری‌هایی مانند DLSS برای
تولید تصویر با وضوح یا کیفیت بالاتر.

حذف نویز رندر

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

تولید فریم

مشارکت در بعضی فناوری‌های تولید فریم و
محاسبات مرتبط با حرکت.

محاسبات علمی

شتاب‌دادن به عملیات ماتریسی در شبیه‌سازی،
تحلیل داده و پژوهش.

Tensor Core در Stable Diffusion

نرم‌افزارها و رابط‌های مبتنی بر Stable Diffusion
می‌توانند در پیکربندی سازگار از Tensor Core برای
اجرای بعضی محاسبات با دقت‌های عددی مناسب استفاده
کنند.

سرعت نهایی علاوه بر Tensor Core به ظرفیت VRAM،
معماری GPU، نسخه نرم‌افزار، روش بهینه‌سازی و
اندازه تصویر وابسته است.

Tensor Core در مدل‌های زبانی

اجرای مدل‌های زبانی روی GPU به حجم حافظه، پهنای
باند، قالب عددی، نوع Quantization و پشتیبانی
نرم‌افزار وابسته است.

داشتن Tensor Core مفید است، اما اگر مدل در VRAM
جا نشود یا Backend از GPU پشتیبانی نکند، تعداد
بالای Tensor Core مشکل را حل نمی‌کند.

RT Core چیست؟

RT Core نام واحدهای اختصاصی رهگیری پرتو در GPUهای
RTX شرکت NVIDIA است.

این واحدها بخشی از محاسبات سنگین مربوط به حرکت
پرتو در صحنه، پیمایش ساختارهای فضایی و تشخیص
برخورد پرتو با مثلث‌ها را شتاب می‌دهند.

نتیجه این محاسبات می‌تواند برای تولید بازتاب،
سایه، نور غیرمستقیم، شکست نور یا افکت‌های دیگر
استفاده شود.


پرتو چیست؟

پرتو یک خط یا مسیر محاسباتی فرضی است که از
نقطه‌ای در صحنه حرکت می‌کند تا برخورد آن با
اجسام، نورها یا سطوح بررسی شود.

RT Core دقیقاً چه کاری انجام می‌دهد؟

  • پیمایش ساختار شتاب‌دهنده هندسی
  • بررسی برخورد پرتو با محدوده اجسام
  • بررسی برخورد پرتو با مثلث‌ها
  • کاهش بار این محاسبات از روی Shaderها
  • کمک به اجرای Ray Tracing بلادرنگ


RT Core به‌تنهایی تصویر را تولید نمی‌کند

Shaderها، واحدهای بافت، ROPها، حافظه و
درایور همچنان در تولید تصویر نقش دارند.
RT Core فقط بخش‌هایی از رهگیری پرتو را شتاب
می‌دهد.

نسل‌های RT Core

RT Core در معماری Turing وارد کارت‌های Quadro RTX
و GeForce RTX شد و در نسل‌های بعدی بهبود پیدا کرد.

حضور RT Core در خانواده‌های مهم NVIDIA
معماری خانواده کارت نمونه‌ها وضعیت کلی
Turing RTX 20 و Quadro RTX RTX 2060، Quadro RTX 4000 نسل نخست گسترده RT Core
Ampere RTX 30 و RTX A RTX 3060، RTX A2000 نسل بهبودیافته
Ada Lovelace RTX 40 و RTX Ada RTX 4060، RTX 4000 Ada قابلیت‌های جدیدتر رهگیری پرتو
نسل‌های جدیدتر RTX و RTX Professional متناسب با خانواده محصول بهبود عملکرد و رندر عصبی

Ray Accelerator در کارت‌های AMD چیست؟

کارت‌های Radeon مبتنی بر معماری‌های سازگار AMD
از واحدهای اختصاصی رهگیری پرتو استفاده می‌کنند
که معمولاً با عنوان
Ray Accelerator
شناخته می‌شوند.

این واحدها بخشی از محاسبات برخورد پرتو با هندسه
را شتاب می‌دهند و در کنار Compute Unitها،
Shaderها، حافظه و درایور فعالیت می‌کنند.

پشتیبانی سخت‌افزاری گسترده رهگیری پرتو در محصولات
مصرف‌کننده Radeon از خانواده RDNA 2 وارد کارت‌های
RX 6000 شد و در نسل‌های بعدی توسعه یافت.

وضعیت کلی Ray Tracing در نسل‌های Radeon
خانواده معماری واحد اختصاصی Ray Tracing
RX 400 و RX 500 Polaris ندارد
RX Vega Vega ندارد
RX 5000 RDNA ندارد
RX 6000 RDNA 2 دارد
RX 7000 RDNA 3 نسل بهبودیافته
نسل‌های جدیدتر Radeon معماری‌های جدیدتر RDNA متناسب با معماری

واحد Ray Tracing در Intel Arc چیست؟

GPUهای مجزای Intel Arc دارای واحدهای سخت‌افزاری
برای شتاب‌دادن به محاسبات Ray Tracing هستند.

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

کارایی نهایی به نسل معماری، تعداد واحدها، درایور،
موتور بازی، وضوح تصویر و استفاده از فناوری‌هایی
مانند XeSS وابسته است.

XMX چیست؟

XMX مخفف
Xe Matrix Extensions
است و به واحدهای ماتریسی موجود در بعضی GPUهای
جدید Intel اشاره دارد.

این واحدها برای شتاب‌دادن به محاسبات هوش مصنوعی،
ضرب ماتریسی، بازسازی تصویر و وظایف مرتبط با
یادگیری ماشین طراحی شده‌اند.

XMX از نظر نقش کلی به واحدهای ماتریسی سایر
شرکت‌ها شباهت دارد؛ اما ساختار، قالب‌های عددی و
اکوسیستم نرم‌افزاری آن متفاوت است.

XMX در XeSS

فناوری XeSS در سخت‌افزارهای سازگار می‌تواند از
XMX برای اجرای شبکه بازسازی تصویر استفاده کند.

XeSS ممکن است در بعضی سخت‌افزارهای دیگر نیز مسیر
اجرایی متفاوتی داشته باشد؛ اما استفاده از واحد
اختصاصی می‌تواند مزیت عملکردی ایجاد کند.


XMX با Xe Core یکسان نیست

Xe Core یک بلوک پردازشی بزرگ‌تر است. XMX
واحدی تخصصی برای محاسبات ماتریسی داخل ساختار
GPUهای سازگار محسوب می‌شود.

واحدهای AI و Matrix در GPUهای AMD

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

این قابلیت‌ها ممکن است در کارت‌های Radeon،
Radeon Pro یا شتاب‌دهنده‌های Instinct با ساختار
و هدف متفاوت ارائه شوند.

محصولات Instinct و معماری‌های محاسباتی CDNA برای
هوش مصنوعی، محاسبات علمی و دیتاسنتر طراحی شده‌اند،
در حالی که Radeon بیشتر بر گرافیک، بازی و تولید
محتوا تمرکز دارد.


برای AI فقط نام واحد سخت‌افزاری کافی نیست

پشتیبانی ROCm، سیستم‌عامل، نسخه فریم‌ورک،
کتابخانه‌ها، ظرفیت حافظه و مدل دقیق GPU باید
پیش از خرید بررسی شوند.

مقایسه واحدهای AI و Ray Tracing

مقایسه مفهومی شتاب‌دهنده‌های اختصاصی GPU
شرکت واحد AI یا Matrix واحد Ray Tracing خانواده‌های رایج
NVIDIA Tensor Core RT Core GeForce RTX، Quadro RTX،
RTX Professional
AMD AI یا Matrix Accelerator متناسب
با معماری
Ray Accelerator Radeon RX، Radeon Pro، Instinct
Intel XMX Ray Tracing Unit Intel Arc و Arc Pro


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

یک Tensor Core، یک XMX یا یک شتاب‌دهنده AI
در AMD ساختار و توان یکسانی ندارند. نتایج
واقعی نرم‌افزار و پشتیبانی اکوسیستم معیار
معتبرتری هستند.

Tensor و RT Core در Quadro و RTX Professional

تمام کارت‌های Quadro دارای Tensor Core یا RT Core
نیستند. وجود این واحدها به معماری GPU بستگی دارد.

Quadro K، Quadro M و Quadro P پیش از معرفی گسترده
RTX عرضه شدند و معمولاً فاقد Tensor Core و RT Core
اختصاصی هستند.

خانواده Quadro RTX بر پایه Turing، واحدهای Tensor
و RT را وارد محصولات ورک‌استیشن کرد.

محصولات جدیدتر RTX A Series، RTX Ada و
RTX Professional نیز بر اساس نسل معماری خود از
این شتاب‌دهنده‌ها بهره می‌برند.

وضعیت واحدهای اختصاصی در خانواده‌های حرفه‌ای NVIDIA
خانواده معماری رایج Tensor Core RT Core
Quadro K Kepler ندارد ندارد
Quadro M Maxwell ندارد ندارد
Quadro P Pascal معمولاً ندارد ندارد
Quadro GV100 Volta دارد ندارد
Quadro RTX Turing دارد دارد
RTX A Series Ampere دارد دارد
RTX Ada Ada Lovelace دارد دارد


Quadro قدیمی هنوز می‌تواند برای CAD مناسب باشد

نبود Tensor Core یا RT Core به معنی بی‌استفاده
بودن کارت نیست. Quadro P2000 یا M2000M ممکن است
برای CAD و مدل‌سازی سبک مناسب باشد؛ اما برای
Ray Tracing، AI جدید و رندر عصبی محدود است.

آیا کارت‌های GTX و GPUهای قدیمی Tensor یا RT Core دارند؟

بیشتر کارت‌های GTX قدیمی مانند GTX 750 Ti،
GTX 960، GTX 1050 Ti و GTX 1060 فاقد Tensor Core
و RT Core اختصاصی هستند.

سری GTX 16 از معماری Turing استفاده می‌کند، اما
بیشتر مدل‌های آن واحدهای اختصاصی فعال مشابه
GeForce RTX را ندارند.

نبود RT Core مانع اجرای تمام بازی‌ها نمی‌شود.
این کارت‌ها همچنان می‌توانند مسیر Rasterization
و Shaderهای عادی را اجرا کنند.

بعضی محاسبات هوش مصنوعی نیز ممکن است روی CUDA Core
اجرا شوند؛ اما سرعت و بهره‌وری آن‌ها با GPU دارای
Tensor Core یکسان نیست.

وضعیت تقریبی واحدهای اختصاصی در کارت‌های قدیمی
مدل یا خانواده Tensor Core RT Core توضیح
GTX 750 Ti ندارد ندارد معماری Maxwell
GTX 960M ندارد ندارد لپ‌تاپی و مبتنی بر Maxwell
GTX 1050 Ti ندارد ندارد معماری Pascal
GTX 1060 ندارد ندارد معماری Pascal
GTX 1650 معمولاً واحد اختصاصی فعال ندارد ندارد خانواده GTX مبتنی بر Turing
RTX 2060 دارد دارد نخستین نسل GeForce RTX
RX 580 واحد اختصاصی جدید ندارد ندارد معماری Polaris
Intel HD 4000 ندارد ندارد گرافیک مجتمع قدیمی

کاربرد واحدهای AI و Ray Tracing در نرم‌افزارها

نقش شتاب‌دهنده‌های اختصاصی در کاربردهای مختلف
کاربرد واحد مؤثر نکته مهم
بازی با Ray Tracing RT Core، Ray Accelerator یا واحد معادل DLSS، FSR یا XeSS ممکن است به افزایش
نرخ فریم کمک کند
Blender واحدهای Compute، RT و AI موتور رندر و Backend تعیین‌کننده است
حذف نویز رندر واحدهای AI یا Matrix نرم‌افزار باید از مسیر سازگار استفاده کند
Stable Diffusion Tensor یا واحدهای ماتریسی VRAM و پشتیبانی نرم‌افزار بسیار مهم است
تدوین ویدئو AI برای بعضی افکت‌ها موتور Encode و Decode نقش جداگانه دارد
CAD معمولاً Shader و درایور حرفه‌ای Tensor و RT همیشه عامل اصلی نیستند
رندر معماری RT، AI و Compute موتور رندر باید شتاب‌دهی GPU را پشتیبانی کند

هنگام خرید، Tensor Core و RT Core چقدر اهمیت دارند؟

برای بازی بدون Ray Tracing

قدرت Rasterization، VRAM، پهنای حافظه و
عملکرد واقعی بازی اهمیت بیشتری دارند.

برای بازی با Ray Tracing

نسل و عملکرد واحدهای RT، فناوری افزایش
وضوح و ظرفیت حافظه مهم هستند.

برای هوش مصنوعی

واحدهای ماتریسی مهم‌اند؛ اما VRAM،
اکوسیستم نرم‌افزار و پشتیبانی فریم‌ورک
اولویت بالاتری دارند.

برای AutoCAD

Tensor Core و RT Core معمولاً اولویت اصلی
نیستند؛ پایداری، CPU و Viewport مهم‌ترند.

برای SolidWorks

درایور حرفه‌ای، گواهی ISV و VRAM معمولاً
مهم‌تر از تعداد واحدهای AI هستند.

برای Blender و رندر

واحدهای RT و AI می‌توانند بسیار مفید باشند؛
اما موتور رندر و Backend باید سازگار باشد.


کارت جدیدتر را فقط به دلیل عبارت AI خریداری نکنید

بررسی کنید نرم‌افزار شما دقیقاً از کدام سخت‌افزار،
API و Backend استفاده می‌کند. امکانات تبلیغاتی
بدون پشتیبانی نرم‌افزار ممکن است برای کاربرد
شما سودی نداشته باشند.

اشتباهات رایج درباره Tensor و RT Core

  • تصور اینکه هر کارت NVIDIA دارای Tensor Core است
  • تصور اینکه تمام کارت‌های Quadro دارای RT Core هستند
  • برابر دانستن Tensor Core با CUDA Core
  • برابر دانستن XMX با Xe Core
  • مقایسه عددی واحدهای AI سه شرکت
  • انتخاب GPU هوش مصنوعی بدون بررسی VRAM
  • انتخاب کارت Ray Tracing بدون بررسی عملکرد Raster
  • نادیده‌گرفتن نسل واحدهای اختصاصی
  • فرض اینکه RT Core کل فرایند رندر را انجام می‌دهد
  • فرض اینکه نرم‌افزار به‌صورت خودکار از AI Core استفاده می‌کند

سؤالات متداول درباره Tensor Core، RT Core و XMX

Tensor Core چیست؟

Tensor Core واحد اختصاصی NVIDIA برای
شتاب‌دادن به محاسبات ماتریسی و بعضی
پردازش‌های هوش مصنوعی است.

آیا همه کارت‌های NVIDIA دارای Tensor Core هستند؟

خیر. این واحد در معماری‌ها و خانواده‌های
مشخصی مانند Volta و محصولات RTX وجود دارد.

آیا GTX 1060 Tensor Core دارد؟

خیر. GTX 1060 مبتنی بر Pascal است و
Tensor Core اختصاصی ندارد.

RT Core چیست؟

RT Core واحد اختصاصی NVIDIA برای شتاب‌دادن
به بخشی از محاسبات رهگیری پرتو است.

آیا Quadro P2000 دارای RT Core است؟

خیر. Quadro P2000 مبتنی بر Pascal است و
پیش از معرفی RT Core عرضه شده است.

آیا Quadro RTX دارای Tensor و RT Core است؟

بله. خانواده Quadro RTX مبتنی بر Turing
دارای Tensor Core و RT Core است.

Ray Accelerator چیست؟

نام واحدهای اختصاصی رهگیری پرتو در
معماری‌های سازگار AMD است.

XMX چیست؟

XMX واحد ماتریسی Intel برای شتاب‌دادن به
بعضی محاسبات AI و فناوری‌هایی مانند XeSS
است.

آیا Tensor Core برای AutoCAD ضروری است؟

معمولاً خیر. پردازنده، درایور، Viewport
و توان عمومی GPU برای بیشتر پروژه‌های
AutoCAD مهم‌تر هستند.

برای Stable Diffusion چه چیزی مهم‌تر است؟

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


فصل ۱۵

راهنمای فصل ساختمان داخلی پردازنده گرافیکی (GPU)

این فصل تمام اجزای داخلی GPU را از واحدهای پردازشی
تا حافظه، موتورهای رندر، فناوری‌های هوش مصنوعی،
Ray Tracing، موتورهای ویدئویی و APIهای گرافیکی
به‌صورت مرحله‌به‌مرحله بررسی می‌کند.


فصل ۱۵

راهنمای فصل ساختمان داخلی پردازنده گرافیکی (GPU)

این فصل تمام اجزای داخلی GPU را از واحدهای پردازشی
تا حافظه، موتورهای رندر، فناوری‌های هوش مصنوعی،
Ray Tracing، موتورهای ویدئویی و APIهای گرافیکی
به‌صورت مرحله‌به‌مرحله بررسی می‌کند.


فصل ۱۵-۴

TMU، ROP، Raster Engine و موتور رندر کارت گرافیک

بعد از پایان پردازش Shaderها و محاسبات هندسی،
GPU باید بافت‌ها را روی مدل‌ها قرار دهد،
پیکسل‌ها را تولید کند،
عملیات عمق و شفافیت را انجام دهد
و در نهایت تصویر آماده را داخل حافظه Frame Buffer ذخیره کند.

تمام این مراحل توسط مجموعه‌ای از واحدهای سخت‌افزاری
مانند TMU، Raster Engine و ROP انجام می‌شود.

مسیر کامل تولید تصویر در GPU

تولید یک فریم سه‌بعدی فقط توسط هسته‌های Shader
انجام نمی‌شود. داده‌های صحنه باید از چند مرحله
پردازشی عبور کنند تا در نهایت به تصویری قابل نمایش
روی مانیتور تبدیل شوند.

مسیر دقیق پردازش با توجه به معماری GPU، موتور بازی،
رابط گرافیکی و نوع تکنیک رندر متفاوت است؛ اما
ساختار کلی بیشتر روش‌های Rasterization را می‌توان
به مراحل زیر تقسیم کرد.


این مسیر همیشه کاملاً خطی نیست

GPUهای جدید می‌توانند چندین مرحله را هم‌زمان
اجرا کنند، داده‌ها را در صف نگه دارند و بعضی
عملیات را با یکدیگر هم‌پوشانی دهند. نمودار بالا
فقط ترتیب مفهومی تولید تصویر را نشان می‌دهد.

Primitive در گرافیک سه‌بعدی چیست؟

Primitive به شکل‌های پایه‌ای گفته می‌شود که GPU
برای ساخت مدل‌های گرافیکی پردازش می‌کند. نقطه،
خط و مثلث از رایج‌ترین Primitiveها هستند.

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

Point

یک موقعیت منفرد در فضای گرافیکی است و
می‌تواند برای ذرات، نقاط یا داده‌های ساده
استفاده شود.

Line

مسیری میان دو یا چند رأس است و در رسم
خطوط، نمودارها، Wireframe و رابط‌های فنی
کاربرد دارد.

Triangle

مهم‌ترین Primitive در رندر سه‌بعدی است و
سطح بیشتر مدل‌ها با کنارهم‌قرارگرفتن
مثلث‌ها ساخته می‌شود.

Primitive Assembly چیست؟

پس از پردازش رأس‌ها، GPU باید آن‌ها را بر اساس
دستور رسم به نقطه، خط یا مثلث تبدیل کند. این مرحله
Primitive Assembly نام دارد.

در این مرحله مشخص می‌شود کدام رأس‌ها یک مثلث را
تشکیل می‌دهند و ترتیب آن‌ها چگونه است. سپس
Primitiveهای ساخته‌شده برای ادامه پردازش به بخش
Rasterization فرستاده می‌شوند.

بعضی Primitiveها ممکن است پیش از Rasterization
حذف شوند؛ برای نمونه، اشیایی که خارج از میدان دید
دوربین قرار دارند یا سطح پشتی آن‌ها قابل مشاهده
نیست.

Rasterization چیست؟

Rasterization فرایند تبدیل Primitiveهای هندسی
مانند مثلث به مجموعه‌ای از Fragmentهای قابل پردازش
برای تصویر است.

موتور Raster محاسبه می‌کند که هر مثلث چه بخشی از
صفحه را پوشش می‌دهد و برای کدام نقاط تصویر باید
Fragment ایجاد شود.

Fragment هنوز الزاماً پیکسل نهایی نیست. این داده
باید مراحل دیگری مانند Pixel Shader، نمونه‌برداری
بافت، آزمون عمق و ترکیب رنگ را طی کند.

Fragment

  • خروجی اولیه Rasterization است.
  • اطلاعاتی مانند مختصات، عمق و
    داده‌های درون‌یابی‌شده دارد.
  • ممکن است در مراحل بعدی حذف شود.

Pixel نهایی

  • نتیجه‌ای است که در Frame Buffer
    نوشته می‌شود.
  • آزمون‌های عمق و Stencil را پشت سر
    گذاشته است.
  • ممکن است با رنگ قبلی ترکیب شده باشد.

TMU چیست؟

TMU مخفف عبارت
Texture Mapping Unit
و به معنی «واحد نگاشت یا پردازش بافت» است.

TMU داده‌های Texture را از حافظه یا کش دریافت
می‌کند، مختصات بافت را پردازش می‌کند و نمونه مناسب
را برای Shader فراهم می‌سازد.

زمانی که سطح یک مدل باید ظاهر چوب، فلز، سنگ،
پارچه، پوست یا هر ماده دیگری داشته باشد، اطلاعات
بافت در کنار Shaderها برای ایجاد ظاهر نهایی آن
استفاده می‌شوند.


Texture چیست؟

Texture مجموعه‌ای از داده‌های تصویری یا عددی
است که برای افزودن جزئیات به سطح مدل استفاده
می‌شود. Texture فقط یک عکس رنگی نیست و می‌تواند
اطلاعات عمق، زبری، فلزی‌بودن، نرمال یا شفافیت
را نیز نگهداری کند.

TMU چه وظایفی دارد؟

خواندن Texture

دریافت داده‌های بافت از حافظه کش یا VRAM
بر اساس مختصات درخواستی Shader.

Addressing

تعیین نحوه برخورد با مختصاتی که خارج از
محدوده اصلی Texture قرار می‌گیرند.

Sampling

انتخاب یک یا چند Texel برای محاسبه نتیجه
مناسب هر Fragment.

Filtering

ترکیب نمونه‌های مجاور برای کاهش حالت
پیکسلی، لرزش یا افت کیفیت بافت.

انتخاب Mipmap

انتخاب نسخه مناسب بافت بر اساس فاصله و
اندازه آن روی صفحه.

فشرده‌سازی بافت

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

Texel چیست؟

Texel مخفف
Texture Element
است و کوچک‌ترین عنصر قابل نمونه‌برداری در یک
Texture محسوب می‌شود.

همان‌طور که Pixel کوچک‌ترین عنصر یک تصویر
نمایش‌داده‌شده است، Texel نیز یکی از عناصر داده‌ای
داخل بافت است.

یک Texel ممکن است فقط اطلاعات رنگ نداشته باشد.
بسته به نوع Texture، می‌تواند شامل داده‌های نرمال،
زبری، عمق، جابه‌جایی یا ماسک نیز باشد.


Texel و Pixel همیشه رابطه یک‌به‌یک ندارند

یک Texel ممکن است روی چند پیکسل نمایش داده شود
یا چند Texel برای محاسبه یک پیکسل نمونه‌برداری
شوند. فاصله دوربین، زاویه سطح و وضوح Texture
این رابطه را تغییر می‌دهند.

مختصات UV چیست؟

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

این نگاشت معمولاً با مختصات
U
و
V
انجام می‌شود. حروف U و V به‌جای X و Y به کار
می‌روند تا مختصات Texture از مختصات فضایی مدل
جدا باشد.

فرایند بازکردن سطح مدل و قراردادن آن روی فضای
دوبعدی Texture با عنوان
UV Unwrapping
شناخته می‌شود.


اهمیت UV در Blender و Maya

اگر UV مدل به‌درستی ساخته نشده باشد، بافت ممکن
است کشیده، فشرده، چرخیده یا درزدار دیده شود.
قدرت بالاتر GPU نمی‌تواند یک UV Map نامناسب را
اصلاح کند.

حالت‌های Texture Addressing

اگر مختصات Texture از محدوده اصلی آن خارج شود،
GPU باید تعیین کند داده بافت چگونه خوانده شود.
این رفتار با حالت‌های Addressing کنترل می‌شود.

حالت‌های رایج آدرس‌دهی Texture
حالت رفتار کاربرد نمونه
Wrap Texture به‌صورت تکرارشونده ادامه
پیدا می‌کند.
زمین، دیوار، پارچه و الگوهای تکراری
Mirror نسخه‌های تکراری با جهت معکوس نمایش
داده می‌شوند.
کاهش بعضی درزهای بصری
Clamp مقدار مختصات در محدوده لبه Texture
نگه داشته می‌شود.
جلوگیری از تکرار بافت
Border خارج از محدوده، رنگ یا مقدار مشخصی
استفاده می‌شود.
سایه‌ها، ماسک‌ها و پردازش‌های خاص

Texture Sampling چیست؟

Texture Sampling فرایند خواندن داده از Texture
بر اساس مختصات مشخص است.

Shader یک مختصات Texture را درخواست می‌کند و
واحدهای بافت یک یا چند Texel نزدیک به آن موقعیت
را می‌خوانند.

نتیجه ممکن است مستقیماً از نزدیک‌ترین Texel گرفته
شود یا از ترکیب چند نمونه مجاور به دست آید.


مرحله ۱


دریافت مختصات

Shader مختصات UV یا مختصات نمونه‌برداری را
برای Texture Unit ارسال می‌کند.


مرحله ۲


انتخاب سطح Mipmap

GPU نسخه‌ای از Texture را متناسب با اندازه
آن روی صفحه انتخاب می‌کند.


مرحله ۳


خواندن Texelها

یک یا چند نمونه از کش Texture یا VRAM
دریافت می‌شوند.


مرحله ۴


فیلترکردن نمونه‌ها

نمونه‌ها با روش انتخاب‌شده ترکیب می‌شوند
تا خروجی نرم‌تر و دقیق‌تری تولید شود.


مرحله ۵


تحویل نتیجه به Shader

مقدار نهایی برای ادامه محاسبات رنگ، نور یا
ماده در اختیار Shader قرار می‌گیرد.

Texture Cache چیست؟

دسترسی مستقیم و مداوم به VRAM زمان و پهنای باند
زیادی مصرف می‌کند. به همین دلیل GPU از حافظه کش
مخصوص یا مشترک برای نگهداری داده‌های Texture
پراستفاده بهره می‌گیرد.

اگر Texel موردنیاز داخل کش باشد، داده سریع‌تر در
اختیار واحد پردازش قرار می‌گیرد. اگر داده در کش
موجود نباشد، باید از سطح پایین‌تر حافظه یا VRAM
خوانده شود.

الگوی دسترسی منظم و نزدیک‌بودن نمونه‌ها به یکدیگر
می‌تواند استفاده مؤثرتری از Texture Cache ایجاد
کند.

Texture Filtering چیست؟

Texture Filtering روشی برای محاسبه مقدار مناسب
میان Texelهای موجود است تا بافت در زمان بزرگ‌شدن،
کوچک‌شدن یا مشاهده از زاویه‌های مختلف کیفیت بهتری
داشته باشد.

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

مقایسه روش‌های رایج Texture Filtering
روش نحوه نمونه‌برداری کیفیت نسبی هزینه پردازشی نسبی
Nearest انتخاب نزدیک‌ترین Texel پایین یا پیکسلی بسیار کم
Bilinear ترکیب نمونه‌های مجاور یک سطح متوسط کم
Trilinear ترکیب نمونه‌های دو سطح Mipmap بهتر و نرم‌تر متوسط
Anisotropic نمونه‌برداری متناسب با زاویه سطح بالا در سطوح زاویه‌دار بیشتر

Nearest-Neighbor Filtering

در روش Nearest، نزدیک‌ترین Texel به مختصات
درخواستی انتخاب می‌شود و مقدار آن بدون ترکیب با
نمونه‌های دیگر بازگردانده می‌شود.

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

Nearest Filtering در بازی‌های Pixel Art یا زمانی
که حفظ لبه‌های سخت و پیکسل‌های اصلی مطلوب است،
می‌تواند انتخاب مناسبی باشد.

Bilinear Filtering

Bilinear Filtering معمولاً چند Texel مجاور در
یک سطح Texture را نمونه‌برداری و با توجه به فاصله
آن‌ها ترکیب می‌کند.

این روش ظاهر پیکسلی را کاهش می‌دهد و نتیجه نرم‌تری
نسبت به Nearest ایجاد می‌کند.

بااین‌حال هنگام جابه‌جایی میان سطوح مختلف Mipmap
ممکن است مرز یا تغییر محسوسی دیده شود.

Trilinear Filtering

Trilinear Filtering نتیجه Bilinear Filtering را
میان دو سطح مجاور Mipmap نیز ترکیب می‌کند.

این کار تغییر ناگهانی کیفیت میان Mipmapها را کاهش
می‌دهد و حرکت دوربین روی سطوح را نرم‌تر نشان
می‌دهد.

هزینه آن از Bilinear بیشتر است، اما در GPUهای
جدید معمولاً فشار غیرعادی و بسیار سنگینی ایجاد
نمی‌کند.

Mipmap چیست؟

Mipmap مجموعه‌ای از نسخه‌های کوچک‌تر یک Texture
است که از قبل تولید و ذخیره می‌شوند.

زمانی که جسم از دور دیده می‌شود، استفاده از نسخه
کامل و بزرگ Texture ضروری نیست. GPU می‌تواند سطح
کوچک‌تری را انتخاب کند که با اندازه جسم روی صفحه
تناسب بیشتری دارد.

مزایای Mipmap

  • کاهش لرزش و Aliasing در بافت‌های دور
  • کاهش پهنای باند موردنیاز
  • بهبود استفاده از Texture Cache
  • افزایش ثبات کیفیت هنگام حرکت دوربین
  • کاهش نمونه‌برداری غیرضروری از Texture بزرگ


Mipmap حافظه مصرف می‌کند

ذخیره سطوح اضافی Mipmap به فضای بیشتری در
حافظه یا فایل نیاز دارد؛ اما معمولاً مزایای
کیفیت و عملکرد آن ارزش این هزینه را دارد.

Anisotropic Filtering چیست؟

زمانی که یک سطح با زاویه تند نسبت به دوربین دیده
می‌شود، نمونه‌برداری معمولی می‌تواند باعث محوشدن
سریع Texture شود.

Anisotropic Filtering الگوی نمونه‌برداری را با
جهت و زاویه سطح تطبیق می‌دهد تا جزئیات بافت در
فاصله و زاویه بیشتر حفظ شود.

این قابلیت به‌ویژه روی جاده‌ها، کف زمین، دیوارهای
طولانی و سطوحی که به سمت افق امتداد دارند، تأثیر
محسوسی دارد.

2x

بهبود محدود با هزینه پردازشی پایین.

4x

تعادل مناسب میان کیفیت و عملکرد در
سخت‌افزارهای قدیمی‌تر.

8x

وضوح بهتر بافت در زاویه‌های تند.

16x

بالاترین سطح رایج برای حفظ جزئیات بافت.


آیا Anisotropic Filtering را فعال کنیم؟

روی بسیاری از GPUهای جدید، فعال‌کردن سطح 8x
یا 16x افت عملکرد نسبتاً محدودی دارد؛ اما روی
کارت‌های بسیار قدیمی یا بازی‌های سنگین بهتر است
نتیجه عملی همان سیستم بررسی شود.

فشرده‌سازی Texture چیست؟

Textureهای باوضوح بالا می‌توانند مقدار زیادی
حافظه و پهنای باند مصرف کنند. قالب‌های فشرده‌سازی
بافت برای کاهش حجم داده و انتقال مؤثرتر آن طراحی
شده‌اند.

GPU می‌تواند قالب‌های فشرده سازگار را مستقیماً
بخواند و هنگام نمونه‌برداری، داده موردنیاز را
بازگشایی کند.

میزان کیفیت، نرخ فشرده‌سازی و پشتیبانی سخت‌افزاری
به قالب Texture و API مورد استفاده بستگی دارد.


فشرده‌سازی بافت با فشرده‌سازی فایل یکسان نیست

قالب فشرده Texture معمولاً برای دسترسی مستقیم
و تصادفی GPU طراحی شده است؛ درحالی‌که فایل‌های
فشرده عمومی ممکن است پیش از استفاده کاملاً
باز شوند.

تعداد TMU چه تأثیری بر عملکرد دارد؟

تعداد TMU می‌تواند بر تعداد نمونه‌های بافتی که GPU
در هر سیکل پردازش می‌کند اثر بگذارد؛ اما این عدد
به‌تنهایی قدرت واقعی کارت را مشخص نمی‌کند.

فرکانس GPU، معماری، کش، پهنای باند حافظه، تعداد
Shaderها، نوع Texture و موتور بازی نیز بر عملکرد
بافت‌گذاری اثر دارند.

دو کارت با تعداد TMU مشابه ممکن است به دلیل تفاوت
معماری یا حافظه، عملکرد کاملاً متفاوتی داشته باشند.


Texture Fill Rate معیار کامل نیست

نرخ پرکردن بافت معمولاً از تعداد TMU و فرکانس
محاسبه می‌شود، اما محدودیت حافظه، کش و نوع
بار پردازشی می‌تواند مانع رسیدن کارت به مقدار
نظری شود.

اهمیت TMU در کارت‌های قدیمی و ورک‌استیشن

کارت‌های قدیمی مانند GTX 960M، GTX 1050 Ti،
Quadro K2100M، Quadro M2000M، Quadro P2000،
Radeon RX 570 و RX 580 نیز دارای واحدهای پردازش
بافت هستند.

عملکرد این کارت‌ها در Viewport و بازی فقط به تعداد
TMU وابسته نیست. معماری، VRAM، پهنای باند حافظه،
درایور و توان مصرفی نیز باید بررسی شوند.

کارت‌های Quadro و RTX Professional ممکن است در
نرم‌افزارهای مهندسی به دلیل درایور حرفه‌ای و
بهینه‌سازی Viewport عملکرد پایدارتر یا قابل
پیش‌بینی‌تری ارائه کنند؛ حتی اگر مشخصات خام آن‌ها
از یک کارت گیمینگ بسیار بالاتر نباشد.

نقش پردازش بافت در چند نوع کاربرد
کاربرد اهمیت TMU و Texture عامل مکمل
بازی بسیار زیاد Shader، ROP، VRAM و پهنای باند
Blender Viewport زیاد Shader، VRAM و درایور
Maya زیاد پیچیدگی صحنه و درایور
SolidWorks متوسط درایور حرفه‌ای و CPU
AutoCAD دوبعدی کم تا متوسط CPU و پیچیدگی فایل
تدوین ویدئو وابسته به افکت و نرم‌افزار موتور رسانه و VRAM

ROP چیست؟

ROP مخفف
Raster Operations Pipeline
یا
Render Output Unit
است و یکی از بخش‌های پایانی مسیر تولید تصویر در GPU
محسوب می‌شود.

پس از آنکه Pixel Shader یا Fragment Shader رنگ،
نور، بافت و سایر ویژگی‌های یک Fragment را محاسبه
کرد، نتیجه باید آزمون‌های نهایی را پشت سر بگذارد
و در حافظه Frame Buffer نوشته شود.

ROPها در عملیاتی مانند آزمون عمق، آزمون Stencil،
ترکیب رنگ، نوشتن پیکسل و بعضی روش‌های
Anti-Aliasing نقش دارند.


تعریف ساده ROP

ROP آخرین ایستگاه اصلی پیکسل پیش از نوشته‌شدن
در Frame Buffer است. این واحد بررسی می‌کند
نتیجه جدید باید نمایش داده شود، حذف شود یا با
اطلاعات قبلی ترکیب شود.

مهم‌ترین وظایف ROP

Depth Test

بررسی می‌کند Fragment جدید در جلوی پیکسل
قبلی قرار دارد یا پشت آن پنهان شده است.

Stencil Test

مشخص می‌کند نوشتن یا پردازش یک بخش از
تصویر بر اساس ماسک Stencil مجاز است یا نه.

Color Blending

رنگ Fragment جدید را با رنگ موجود در
Frame Buffer ترکیب می‌کند.

Pixel Write

نتیجه نهایی را در Render Target یا
Frame Buffer ذخیره می‌کند.

Anti-Aliasing Operations

در بعضی روش‌های Anti-Aliasing، نمونه‌ها
را ترکیب و نتیجه نهایی پیکسل را تولید
می‌کند.

Compression

در معماری‌های سازگار، داده‌های رنگ یا عمق
را برای کاهش مصرف پهنای باند فشرده می‌کند.

تفاوت Raster Engine و ROP

مقایسه Raster Engine و ROP
معیار Raster Engine ROP
مرحله پردازش میانه مسیر رندر مراحل پایانی رندر
وظیفه اصلی تبدیل Primitive به Fragment آزمون و نوشتن خروجی پیکسل
ورودی مثلث‌ها و Primitiveها Fragmentهای پردازش‌شده
خروجی Fragmentهای اولیه داده نهایی Frame Buffer
عملیات شاخص Coverage و Rasterization Depth، Stencil، Blending و Write

Depth Buffer چیست؟

Depth Buffer حافظه‌ای است که فاصله تقریبی هر
پیکسل یا نمونه را نسبت به دوربین ذخیره می‌کند.

این اطلاعات کمک می‌کند GPU تشخیص دهد کدام سطح
در جلوی سطح دیگر قرار دارد و باید دیده شود.

Depth Buffer معمولاً با نام
Z-Buffer
نیز شناخته می‌شود؛ زیرا در بسیاری از سیستم‌های
مختصات، محور Z با عمق صحنه ارتباط دارد.


مثال ساده

اگر دو مثلث روی یک بخش از صفحه قرار گرفته
باشند، مقداری که به دوربین نزدیک‌تر است باید
دیده شود. Depth Test این دو مقدار را مقایسه
می‌کند و سطح پشتی را حذف می‌کند.

Depth Test چگونه کار می‌کند؟


مرحله ۱


تولید مقدار عمق

برای Fragment جدید یک مقدار Depth محاسبه
می‌شود.


مرحله ۲


خواندن عمق قبلی

مقدار ذخیره‌شده در Depth Buffer برای همان
موقعیت خوانده می‌شود.


مرحله ۳


مقایسه

GPU بررسی می‌کند Fragment جدید بر اساس
تابع Depth انتخاب‌شده جلوتر است یا عقب‌تر.


مرحله ۴


پذیرش یا حذف

Fragment پذیرفته می‌شود یا بدون نوشتن رنگ
کنار گذاشته می‌شود.


مرحله ۵


به‌روزرسانی عمق

در صورت مجازبودن، مقدار جدید داخل Depth
Buffer ذخیره می‌شود.

Early-Z چیست؟

اگر GPU بتواند پیش از اجرای کامل Pixel Shader
تشخیص دهد که یک Fragment پشت سطح دیگری پنهان است،
می‌تواند آن را زودتر حذف کند.

این تکنیک با عنوان
Early-Z
شناخته می‌شود و از اجرای محاسبات غیرضروری Shader
جلوگیری می‌کند.

Early-Z به‌ویژه در صحنه‌هایی که تعداد زیادی سطح
روی یکدیگر قرار گرفته‌اند، می‌تواند باعث کاهش بار
پردازشی شود.


Early-Z همیشه قابل استفاده نیست

بعضی Shaderها مقدار Depth را تغییر می‌دهند یا
عملیات خاصی انجام می‌دهند که مانع تصمیم‌گیری
زودهنگام GPU می‌شود.

Z-Fighting چیست؟

اگر دو سطح فاصله بسیار کمی از یکدیگر داشته باشند،
دقت محدود Depth Buffer ممکن است باعث شود GPU
نتواند به‌صورت پایدار تشخیص دهد کدام سطح جلوتر است.

نتیجه می‌تواند به‌شکل لرزش، چشمک‌زدن یا جابه‌جایی
متناوب میان دو سطح دیده شود. این مشکل
Z-Fighting
نام دارد.

افزایش دقت Depth Buffer، اصلاح Near و Far Plane،
ایجاد فاصله میان سطوح یا استفاده از Depth Bias
می‌تواند این مشکل را کاهش دهد.

Stencil Buffer چیست؟

Stencil Buffer حافظه‌ای برای ذخیره مقادیر کوچک
کنترلی در هر پیکسل یا نمونه است.

این مقادیر به GPU اجازه می‌دهند بخش‌هایی از تصویر
را علامت‌گذاری کند و در مراحل بعدی فقط در نواحی
مشخص عملیات انجام دهد.

Stencil Buffer برای ساخت ماسک‌های گرافیکی،
سایه‌ها، آینه‌ها، Portalها، Outline و افکت‌های
ترکیبی کاربرد دارد.


تعریف ساده Stencil

Stencil مانند یک شابلون دیجیتال است. بخشی از
صفحه مجاز و بخشی غیرمجاز علامت‌گذاری می‌شود تا
رندر فقط در ناحیه تعیین‌شده انجام شود.

Stencil Test چگونه کار می‌کند؟

GPU مقدار Stencil ذخیره‌شده را با یک مقدار مرجع
مقایسه می‌کند.

بر اساس تابع مقایسه، Fragment می‌تواند پذیرفته یا
رد شود. همچنین ممکن است مقدار Stencil بعد از
عبور یا شکست آزمون تغییر کند.

چند کاربرد رایج Stencil Buffer
کاربرد نقش Stencil
آینه محدودکردن تصویر بازتابی به سطح آینه
Portal نمایش صحنه دوم فقط داخل محدوده درگاه
Outline علامت‌گذاری شیء و ترسیم حاشیه اطراف آن
Shadow Volume تعیین نواحی قرارگرفته در سایه
رابط کاربری محدودکردن رندر به ناحیه یا شکل مشخص

Color Buffer چیست؟

Color Buffer بخشی از حافظه است که مقادیر رنگی
تصویر رندرشده در آن نگهداری می‌شوند.

هر پیکسل می‌تواند شامل کانال‌های قرمز، سبز، آبی
و در صورت نیاز Alpha باشد.

قالب Color Buffer تعیین می‌کند هر کانال چه میزان
دقت داشته باشد؛ برای نمونه ۸، ۱۰، ۱۶ یا ۳۲ بیت
برای هر کانال.

در رندر HDR یا محاسبات حرفه‌ای ممکن است از قالب‌های
دقیق‌تر و اعشاری استفاده شود.

Alpha Channel چیست؟

Alpha Channel معمولاً اطلاعات شفافیت یا وزن ترکیب
رنگ را ذخیره می‌کند.

مقدار Alpha می‌تواند مشخص کند رنگ جدید با چه
شدتی روی رنگ قبلی اعمال شود.

کاربرد دقیق Alpha به موتور رندر و Shader بستگی
دارد و همیشه فقط به معنی شفافیت ساده نیست.

Color Blending چیست؟

Blending فرایند ترکیب رنگ Fragment جدید با رنگی
است که از قبل در Render Target ذخیره شده است.

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


شفافیت می‌تواند ترتیب رندر را پیچیده کند

اجسام شفاف معمولاً باید با ترتیب مشخصی رندر
شوند؛ زیرا رنگ نهایی به محتوای موجود پشت آن‌ها
وابسته است.

Frame Buffer چیست؟

Frame Buffer بخشی از حافظه گرافیکی است که تصویر
آماده یا داده‌های مرتبط با رندر در آن ذخیره می‌شوند.

پس از پایان عملیات Shader، Depth، Stencil و
Blending، نتیجه نهایی هر پیکسل در یکی از Render
Targetها نوشته می‌شود.

Display Engine می‌تواند تصویر نهایی را از Buffer
مناسب بخواند و برای نمایشگر ارسال کند.


Frame Buffer فقط یک تصویر ساده نیست

در رندر مدرن ممکن است چندین Buffer برای رنگ،
عمق، نرمال، حرکت، نور، شناسه اشیا و سایر داده‌ها
به‌صورت هم‌زمان وجود داشته باشد.

Render Target چیست؟

Render Target مقصدی در حافظه است که GPU نتیجه
یک مرحله رندر را در آن می‌نویسد.

یک Render Target می‌تواند تصویر نهایی صفحه باشد
یا داده‌ای میانی که در مراحل بعدی دوباره خوانده
می‌شود.

موتورهای رندر مدرن معمولاً چند Render Target را
هم‌زمان استفاده می‌کنند.

Multiple Render Targets چیست؟

در فناوری
Multiple Render Targets
یا MRT، یک مرحله Shader می‌تواند چند خروجی متفاوت
را هم‌زمان در Bufferهای جدا ذخیره کند.

این قابلیت در روش‌هایی مانند Deferred Rendering
کاربرد دارد؛ جایی که رنگ، نرمال، عمق و خصوصیات
متریال جداگانه ذخیره و بعداً برای محاسبه نور
استفاده می‌شوند.

Double Buffering و Triple Buffering

برای جلوگیری از نمایش تصویر ناقص، معمولاً یک Buffer
در حال نمایش و Buffer دیگری در حال رندر است.

در Double Buffering دو Buffer و در Triple Buffering
سه Buffer برای مدیریت فریم‌ها استفاده می‌شوند.

مقایسه Double و Triple Buffering
ویژگی Double Buffering Triple Buffering
تعداد Buffer دو سه
مصرف حافظه کمتر بیشتر
انعطاف صف فریم محدودتر بیشتر
تأخیر وابسته به حالت Sync ممکن است در بعضی حالت‌ها بیشتر شود

Screen Tearing چیست؟

اگر نمایشگر هنگام دریافت تصویر جدید هنوز در حال
نمایش فریم قبلی باشد، ممکن است بخش‌های مختلف دو
فریم به‌صورت هم‌زمان روی صفحه دیده شوند.

این پدیده
Screen Tearing
نام دارد و معمولاً به‌شکل یک یا چند خط شکست افقی
در تصویر دیده می‌شود.

فناوری‌هایی مانند V-Sync، Adaptive Sync،
FreeSync و G-SYNC برای هماهنگ‌کردن تولید فریم و
نرخ نوسازی نمایشگر استفاده می‌شوند.

تعداد ROP چه تأثیری بر عملکرد دارد؟

تعداد ROP می‌تواند بر نرخ نوشتن پیکسل‌ها، عملیات
Blending، آزمون‌های عمق و عملکرد در وضوح‌های بالا
اثر بگذارد.

بااین‌حال تعداد ROP به‌تنهایی معیار کامل قدرت کارت
نیست. فرکانس، معماری، پهنای باند حافظه، فشرده‌سازی،
کش و نوع بار پردازشی نیز اهمیت دارند.

در بعضی بازی‌ها محدودیت Shader یا حافظه زودتر از
ROP ظاهر می‌شود و افزایش تعداد ROP تأثیر زیادی
ایجاد نمی‌کند.


Pixel Fill Rate مقدار نظری است

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

ROP در کارت‌های قدیمی، Quadro و ورک‌استیشن

کارت‌هایی مانند GTX 960M، GTX 1050 Ti، GTX 1060،
Quadro K2100M، Quadro M2000M، Quadro P2000،
Quadro RTX 4000، Radeon RX 580 و Intel Arc نیز
از واحدهای خروجی رندر استفاده می‌کنند.

در نرم‌افزارهای CAD، تعداد ROP به‌تنهایی معیار
اصلی انتخاب نیست و درایور حرفه‌ای، توان Viewport،
ظرفیت VRAM و سازگاری نرم‌افزار اهمیت بیشتری دارند.

در بازی، وضوح بالا، Anti-Aliasing و افکت‌های
شفافیت می‌توانند فشار بیشتری روی مراحل پایانی
رندر ایجاد کنند.

اشتباهات رایج درباره TMU، ROP و Frame Buffer

  • تصور اینکه تعداد TMU به‌تنهایی قدرت کارت را
    مشخص می‌کند.
  • مقایسه مستقیم تعداد ROP میان معماری‌های
    متفاوت.
  • یکی‌دانستن Raster Engine با ROP.
  • یکی‌دانستن Texel با Pixel.
  • تصور اینکه Frame Buffer فقط همان حافظه VRAM
    است.
  • نادیده‌گرفتن پهنای باند حافظه در کنار TMU و
    ROP.
  • تصور اینکه Anisotropic Filtering روی همه
    کارت‌های قدیمی بدون افت عملکرد اجرا می‌شود.
  • انتخاب کارت ورک‌استیشن فقط بر اساس تعداد TMU
    یا ROP.
  • تصور اینکه ROP تمام مراحل تولید تصویر را انجام
    می‌دهد.
  • یکی‌دانستن Depth Buffer، Stencil Buffer و
    Color Buffer.

سؤالات متداول درباره TMU، ROP و Frame Buffer

TMU چیست؟

TMU واحد پردازش بافت است و وظایفی مانند
خواندن Texture، نمونه‌برداری، Filtering و
انتخاب Mipmap را انجام می‌دهد.

آیا تعداد TMU بیشتر همیشه بهتر است؟

خیر. معماری، فرکانس، کش، پهنای باند حافظه
و نوع بار پردازشی نیز بر عملکرد اثر دارند.

تفاوت Texel و Pixel چیست؟

Texel عنصر داخل Texture است، اما Pixel
عنصر نهایی تصویر نمایش‌داده‌شده محسوب
می‌شود.

Mipmap چه کاربردی دارد؟

Mipmap نسخه‌های کوچک‌تر یک Texture را
نگهداری می‌کند تا اشیای دور با کیفیت و
کارایی بهتری نمایش داده شوند.

Anisotropic Filtering چیست؟

روشی برای حفظ وضوح Texture روی سطوحی است
که با زاویه تند یا در فاصله زیاد دیده
می‌شوند.

ROP چیست؟

ROP یکی از واحدهای پایانی مسیر رندر است و
در آزمون عمق، Stencil، Blending و نوشتن
نتیجه در Frame Buffer نقش دارد.

آیا ROP و Raster Engine یکی هستند؟

خیر. Raster Engine Primitiveها را به
Fragment تبدیل می‌کند؛ ROP در مراحل پایانی
خروجی پیکسل را پردازش و ذخیره می‌کند.

Depth Buffer چیست؟

حافظه‌ای است که فاصله سطوح نسبت به دوربین
را ذخیره می‌کند تا GPU تشخیص دهد کدام سطح
باید دیده شود.

تفاوت Depth Buffer و Stencil Buffer چیست؟

Depth Buffer عمق سطوح را ذخیره می‌کند؛
Stencil Buffer مقادیر کنترلی برای محدودکردن
رندر به نواحی مشخص نگه می‌دارد.

Frame Buffer چیست؟

بخشی از حافظه گرافیکی است که تصویر نهایی
یا داده‌های میانی رندر در آن ذخیره می‌شوند.

آیا VRAM بیشتر باعث افزایش تعداد ROP می‌شود؟

خیر. ظرفیت VRAM و تعداد ROP دو مشخصه جدا
هستند، هرچند پهنای باند حافظه می‌تواند روی
عملکرد خروجی رندر اثر بگذارد.

برای AutoCAD تعداد ROP مهم است؟

در پروژه‌های دوبعدی معمولاً عامل اصلی
نیست. CPU، درایور، پایداری و پیچیدگی فایل
اهمیت بیشتری دارند.

برای Blender تعداد TMU مهم‌تر است یا VRAM؟

هر دو مهم‌اند، اما در صحنه‌های بزرگ کمبود
VRAM می‌تواند محدودیت شدیدتری ایجاد کند.
نوع موتور رندر و توان Compute نیز باید
بررسی شود.

آیا Quadro قدیمی برای پردازش Texture مناسب است؟

مدل‌هایی مانند Quadro M2000M یا P2000
می‌توانند برای Viewport و پروژه‌های سبک تا
متوسط مناسب باشند، اما باید معماری، VRAM،
درایور و حجم پروژه بررسی شود.


فصل ۱۵-۵

حافظه داخلی GPU، Cache، Register، Shared Memory و VRAM

پردازنده گرافیکی برای اجرای سریع هزاران Thread به
چندین سطح حافظه نیاز دارد. Registerها، حافظه مشترک،
کش‌های L1 و L2، حافظه‌های کش بزرگ‌تر و VRAM هرکدام
ظرفیت، سرعت، تأخیر و کاربرد متفاوتی دارند.

سلسله‌مراتب حافظه GPU چیست؟

همه حافظه‌های GPU سرعت و ظرفیت یکسانی ندارند.
حافظه‌های بسیار نزدیک به واحدهای پردازشی سریع‌ترند،
اما ظرفیت کمتری دارند. حافظه‌های دورتر ظرفیت بیشتری
ارائه می‌کنند، اما دسترسی به آن‌ها زمان بیشتری
نیاز دارد.

GPU برای کاهش تأخیر و جلوگیری از مراجعه مداوم به
VRAM، داده‌های پراستفاده را در Registerها و
حافظه‌های کش نگهداری می‌کند.


چرا چند سطح حافظه وجود دارد؟

ساخت حافظه‌ای که هم بسیار سریع، هم بسیار بزرگ
و هم کم‌مصرف باشد دشوار و پرهزینه است. به همین
دلیل GPU از چند سطح با ویژگی‌های متفاوت استفاده
می‌کند.

مقایسه سطوح مختلف حافظه GPU

مقایسه مفهومی حافظه‌های داخلی و خارجی GPU
سطح حافظه سرعت نسبی ظرفیت نسبی کاربرد اصلی
Register بسیار زیاد بسیار کم داده‌های فعال هر Thread
Shared Memory بسیار زیاد کم اشتراک داده میان گروه Threadها
L1 Cache زیاد کم تا متوسط داده‌های نزدیک به واحد پردازشی
L2 Cache متوسط تا زیاد متوسط اشتراک داده میان بخش‌های GPU
Last-Level Cache متوسط متوسط تا زیاد کاهش مراجعه مستقیم به VRAM
VRAM کمتر از Cache زیاد Texture، مدل، Buffer و داده محاسباتی
System RAM کمتر بسیار زیاد حافظه اصلی سیستم و گرافیک مجتمع

Register در GPU چیست؟

Register سریع‌ترین نوع حافظه‌ای است که واحدهای
پردازشی GPU برای نگهداری داده‌های فعال استفاده
می‌کنند.

متغیرهای موقت، نتیجه محاسبات میانی، مختصات، اندیس‌ها
و داده‌هایی که هر Thread به‌طور مداوم نیاز دارد،
می‌توانند داخل Register قرار بگیرند.

Registerها داخل یا بسیار نزدیک به بلوک‌های پردازشی
مانند SM، Compute Unit یا Xe Core قرار دارند.


Register حافظه اختصاصی هر Thread است

هر Thread معمولاً مجموعه‌ای از Registerها را برای
داده‌های خودش استفاده می‌کند. تعداد زیاد Threadها
باعث می‌شود ظرفیت کلی Register File اهمیت زیادی
پیدا کند.

Register File چیست؟

Register File مجموعه بزرگی از Registerهای فیزیکی
داخل یک بلوک پردازشی GPU است.

زمانی که یک گروه Thread روی یک SM یا Compute Unit
اجرا می‌شود، بخشی از Register File به آن‌ها اختصاص
پیدا می‌کند.

ظرفیت Register File می‌تواند روی تعداد Threadها یا
گروه‌های کاری هم‌زمان اثر بگذارد.

Register Pressure چیست؟

اگر یک Shader یا Kernel برای هر Thread به تعداد
زیادی Register نیاز داشته باشد، فشار مصرف Register
افزایش پیدا می‌کند.

از آنجا که ظرفیت Register File محدود است، مصرف زیاد
Register می‌تواند تعداد گروه‌های کاری هم‌زمان روی
هر واحد پردازشی را کاهش دهد.

این وضعیت ممکن است Occupancy را کاهش دهد و توانایی
GPU برای پنهان‌کردن تأخیر حافظه را محدود کند.


Register بیشتر همیشه باعث سرعت بیشتر نمی‌شود

Register کافی از مراجعه به حافظه کندتر جلوگیری
می‌کند؛ اما مصرف بیش‌ازحد آن می‌تواند تعداد
Threadهای هم‌زمان را کاهش دهد.

Register Spilling چیست؟

اگر کامپایلر نتواند تمام داده‌های موردنیاز یک Thread
را در Registerهای موجود نگهداری کند، ممکن است بخشی
از آن‌ها را به حافظه کندتری منتقل کند.

این فرایند Register Spilling نام دارد و می‌تواند
باعث افزایش دسترسی به حافظه و کاهش عملکرد شود.

حافظه‌ای که برای Spill استفاده می‌شود ممکن است در
مستندات برنامه‌نویسی با عنوان Local Memory دیده
شود؛ اما از نظر فیزیکی معمولاً داخل VRAM یا مسیر
حافظه عمومی GPU قرار دارد.

Shared Memory در GPU چیست؟

Shared Memory حافظه‌ای سریع و قابل مدیریت است که
گروهی از Threadهای یک بلوک کاری می‌توانند به‌صورت
مشترک از آن استفاده کنند.

این حافظه برای تبادل داده میان Threadها، ذخیره
نتایج میانی و کاهش مراجعه مکرر به VRAM کاربرد دارد.

در NVIDIA معمولاً اصطلاح Shared Memory رایج است.
AMD از اصطلاحاتی مانند Local Data Share و Intel
از نام‌های متناسب با معماری خود استفاده می‌کند.

نام‌های رایج حافظه مشترک در معماری‌های مختلف
شرکت نام رایج سطح اشتراک
NVIDIA Shared Memory میان Threadهای یک Block
AMD Local Data Share یا LDS میان Work-Itemهای یک Workgroup
Intel Shared Local Memory یا ساختار مشابه میان Threadهای گروه کاری

کاربردهای Shared Memory

اشتراک داده

چند Thread می‌توانند داده‌ای را یک بار
بارگذاری و سپس به‌صورت مشترک استفاده کنند.

ضرب ماتریسی

بخش‌هایی از ماتریس در حافظه سریع نگهداری
می‌شوند تا چندین بار استفاده شوند.

پردازش تصویر

ناحیه‌ای از تصویر برای فیلتر، Blur یا
تشخیص لبه داخل Shared Memory ذخیره می‌شود.

Reduction

Threadها نتایج خود را برای محاسبه مجموع،
کمینه یا بیشینه با یکدیگر ترکیب می‌کنند.

Histogram

شمارش داده‌ها ابتدا در حافظه محلی سریع و
سپس در حافظه اصلی ادغام می‌شود.

شبیه‌سازی

داده‌های مجاور در فیزیک، سیالات یا شبکه‌های
محاسباتی میان Threadها به اشتراک گذاشته می‌شوند.

Bank Conflict چیست؟

Shared Memory معمولاً به چند Bank تقسیم می‌شود تا
دسترسی هم‌زمان Threadها امکان‌پذیر باشد.

اگر چند Thread به‌گونه‌ای به داده‌ها دسترسی پیدا
کنند که درخواست‌های آن‌ها روی یک Bank تداخل ایجاد
کند، ممکن است دسترسی‌ها به‌صورت ترتیبی انجام شوند.

این وضعیت Bank Conflict نام دارد و می‌تواند کارایی
Shared Memory را کاهش دهد.


چیدمان داده اهمیت دارد

تغییر نحوه قرارگیری آرایه‌ها یا افزودن Padding
می‌تواند بعضی Bank Conflictها را کاهش دهد.

Local Memory چیست؟

اصطلاح Local Memory در پلتفرم‌ها و APIهای مختلف
ممکن است معنی متفاوتی داشته باشد.

در بعضی مستندات CUDA، Local Memory به حافظه‌ای
خصوصی برای هر Thread گفته می‌شود که از نظر فیزیکی
ممکن است در VRAM قرار داشته باشد و از Register
بسیار کندتر باشد.

در بعضی استانداردها، واژه Local به حافظه مشترک
میان اعضای یک Workgroup اشاره می‌کند. بنابراین
باید تعریف همان API یا معماری بررسی شود.


Local Memory همیشه داخل تراشه نیست

نام Local ممکن است گمراه‌کننده باشد. در بعضی
پلتفرم‌ها این حافظه از نظر منطقی برای Thread
خصوصی است، اما از مسیر حافظه عمومی GPU استفاده
می‌کند.

کش L0 در GPU چیست؟

بعضی معماری‌های GPU از سطحی بسیار نزدیک به واحدهای
اجرایی با عنوان L0 Cache استفاده می‌کنند.

L0 ممکن است برای دستورها، داده‌ها یا مسیرهای خاص
داخل یک زیرمجموعه پردازشی طراحی شده باشد.

وجود، اندازه و وظیفه دقیق L0 میان معماری‌های
NVIDIA، AMD و Intel یکسان نیست.

Instruction Cache چیست؟

Instruction Cache دستورهای برنامه یا Shader را
نزدیک به واحدهای اجرایی نگهداری می‌کند.

اگر گروه‌های زیادی از Threadها دستورهای یکسانی را
اجرا کنند، نگهداری این دستورها در Cache باعث کاهش
دسترسی‌های تکراری به حافظه دورتر می‌شود.

Shaderهای بسیار بزرگ یا دارای مسیرهای پیچیده ممکن
است فشار بیشتری روی Instruction Cache وارد کنند.

کش L1 در GPU چیست؟

L1 Cache حافظه‌ای سریع و نزدیک به بلوک‌های پردازشی
است که داده‌های پراستفاده را نگهداری می‌کند.

در بعضی معماری‌ها، L1 Cache و Shared Memory از
بخشی از منابع فیزیکی مشترک استفاده می‌کنند و
ظرفیت میان آن‌ها قابل تنظیم است.

نوع داده‌ای که در L1 نگهداری می‌شود به معماری و
مسیر دسترسی بستگی دارد و ممکن است شامل داده عمومی،
Texture یا اطلاعات Read-Only باشد.

Cache Hit و Cache Miss چیست؟

Cache Hit

داده موردنیاز داخل Cache پیدا می‌شود و
بدون مراجعه به حافظه دورتر در اختیار
واحد پردازشی قرار می‌گیرد.

Cache Miss

داده داخل Cache نیست و باید از سطح
پایین‌تر مانند L2 یا VRAM خوانده شود.

نرخ بالاتر Cache Hit معمولاً باعث کاهش تأخیر و
مصرف پهنای باند حافظه می‌شود.

کش L2 در GPU چیست؟

L2 Cache معمولاً از L1 بزرگ‌تر است و میان تعداد
بیشتری از بلوک‌های پردازشی GPU مشترک است.

بسیاری از درخواست‌های حافظه پیش از رسیدن به VRAM
از L2 عبور می‌کنند.

L2 می‌تواند داده‌های Shader، Texture، Buffer و
بعضی اطلاعات محاسباتی را نگهداری کند.

افزایش ظرفیت یا بهره‌وری L2 می‌تواند وابستگی GPU
به پهنای باند خارجی VRAM را کاهش دهد.

Cache Coherency چیست؟

زمانی که چند واحد پردازشی نسخه‌هایی از یک داده را
داخل Cacheهای مختلف نگهداری می‌کنند، باید مشخص شود
تغییرات چگونه میان آن‌ها هماهنگ شود.

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

GPUها ممکن است برای انواع مختلف حافظه و عملیات،
قوانین Coherency متفاوتی داشته باشند و برنامه‌نویس
در بعضی موارد باید از Barrier یا عملیات همگام‌سازی
استفاده کند.

Last-Level Cache چیست؟

Last-Level Cache آخرین سطح Cache پیش از مراجعه به
حافظه خارجی GPU است.

در بعضی معماری‌ها همان L2 نقش آخرین سطح را دارد و
در بعضی طراحی‌ها کش‌های بزرگ‌تری برای کاهش فشار روی
VRAM اضافه شده‌اند.

نام، ظرفیت و ساختار این Cache میان شرکت‌ها و نسل‌ها
متفاوت است.

AMD Infinity Cache چیست؟

Infinity Cache نام کش بزرگ روی تراشه در بعضی
معماری‌های Radeon است.

هدف آن کاهش مراجعه مداوم به حافظه GDDR و افزایش
پهنای باند مؤثر برای داده‌هایی است که قابلیت
استفاده مجدد دارند.

ظرفیت Infinity Cache در همه مدل‌ها یکسان نیست و
نتیجه آن به وضوح تصویر، نوع بازی، الگوی دسترسی و
معماری GPU بستگی دارد.


Infinity Cache جایگزین VRAM نیست

این کش ظرفیت بسیار کمتری از VRAM دارد و فقط
داده‌های پراستفاده را موقتاً نگهداری می‌کند.

فشرده‌سازی داده در مسیر حافظه GPU

GPUهای مدرن می‌توانند بعضی داده‌های رنگ، عمق یا
Texture را بدون افت قابل مشاهده فشرده کنند.

این کار مقدار داده‌ای را که باید میان Cache و
VRAM جابه‌جا شود کاهش می‌دهد و پهنای باند مؤثر را
افزایش می‌دهد.

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

Memory Controller چیست؟

Memory Controller ارتباط میان GPU، Cache و
تراشه‌های VRAM را مدیریت می‌کند.

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

تعداد کنترل‌کننده‌ها و عرض هر کانال در شکل‌گیری
Bus Width نهایی کارت نقش دارد.

کانال حافظه در کارت گرافیک چیست؟

رابط حافظه GPU معمولاً از چند کانال مستقل تشکیل
می‌شود.

هر کانال بخشی از Bus Width را تأمین می‌کند و به
یک یا چند تراشه حافظه متصل می‌شود.

ترکیب چند کانال می‌تواند رابط‌هایی مانند ۶۴،
۱۲۸، ۱۹۲، ۲۵۶ یا ۳۸۴ بیت ایجاد کند.

Memory Bus و Bus Width چیست؟

Memory Bus مسیر انتقال داده میان GPU و VRAM است.
Bus Width نشان می‌دهد در هر انتقال چه تعداد بیت
می‌تواند میان آن‌ها جابه‌جا شود.

عرض باس بیشتر می‌تواند پهنای باند را افزایش دهد،
اما نوع حافظه و سرعت انتقال نیز اهمیت دارند.

نمونه عرض باس‌های رایج کارت گرافیک
عرض باس رده رایج نکته
۳۲ بیت کارت‌های بسیار اقتصادی پهنای باند محدود
۶۴ بیت اقتصادی و لپ‌تاپی وابستگی زیاد به سرعت حافظه و Cache
۱۲۸ بیت اقتصادی تا میان‌رده بسیار رایج در چندین نسل
۱۹۲ بیت میان‌رده تعادل ظرفیت و پهنای باند
۲۵۶ بیت میان‌رده قدرتمند تا رده‌بالا پهنای باند بیشتر با حافظه مناسب
۳۲۰ یا ۳۸۴ بیت کارت‌های رده‌بالا هزینه، مصرف و پیچیدگی بیشتر


عرض باس بیشتر همیشه به معنی کارت سریع‌تر نیست

یک کارت جدید با باس باریک‌تر، حافظه سریع‌تر و
Cache بزرگ‌تر ممکن است از کارت قدیمی با باس
عریض‌تر عملکرد بهتری داشته باشد.

Memory Clock و Effective Clock چیست؟

Memory Clock به فرکانس کاری حافظه اشاره دارد؛ اما
مقدار نمایش‌داده‌شده در ابزارهای مختلف ممکن است
Clock پایه، Clock واقعی یا نرخ مؤثر انتقال باشد.

حافظه‌های GDDR می‌توانند در هر سیکل چند انتقال
انجام دهند؛ به همین دلیل نرخ مؤثر آن‌ها از Clock
پایه بیشتر است.

هنگام مقایسه باید مشخص شود عدد اعلام‌شده بر حسب
MHz، Gbps یا نرخ مؤثر انتقال است.

پهنای باند حافظه چیست؟

Memory Bandwidth مقدار داده‌ای است که در مدت‌زمان
مشخص میان GPU و VRAM منتقل می‌شود.

پهنای باند معمولاً با واحد گیگابایت بر ثانیه
نمایش داده می‌شود و به سرعت حافظه و عرض باس وابسته
است.


فرمول تقریبی پهنای باند

پهنای باند تقریبی از ضرب نرخ انتقال حافظه در
عرض باس و تقسیم نتیجه بر هشت به دست می‌آید.

Cache، فشرده‌سازی و الگوی دسترسی می‌توانند پهنای
باند مؤثر را نسبت به مقدار خام تغییر دهند.

تأخیر حافظه یا Memory Latency چیست؟

Latency مدت‌زمانی است که از ارسال درخواست حافظه
تا دریافت داده طول می‌کشد.

پهنای باند بالا لزوماً به معنی تأخیر پایین نیست.
یک مسیر حافظه می‌تواند حجم زیادی داده منتقل کند،
اما پاسخ هر درخواست همچنان زمان‌بر باشد.

GPU با اجرای Threadهای متعدد و جابه‌جایی میان آن‌ها
تلاش می‌کند تأخیر حافظه را پنهان کند.

ظرفیت VRAM چه تأثیری دارد؟

VRAM داده‌های بزرگ مانند Textureها، مدل‌ها،
Frame Bufferها، داده‌های رندر و مدل‌های هوش مصنوعی
را نگهداری می‌کند.

اگر ظرفیت کافی باشد، داده‌ها می‌توانند داخل حافظه
سریع کارت باقی بمانند. اگر ظرفیت کافی نباشد، بخشی
از داده‌ها ممکن است به RAM سیستم منتقل شوند یا
نرم‌افزار مجبور به کاهش کیفیت و اندازه پروژه شود.


VRAM بیشتر همیشه به معنی GPU سریع‌تر نیست

یک کارت ضعیف با حافظه زیاد ممکن است از کارت
قدرتمندتر با حافظه کمتر کندتر باشد. ظرفیت فقط
یکی از عوامل انتخاب است.

چه داده‌هایی داخل VRAM ذخیره می‌شوند؟

Texture

تصاویر رنگ، Normal Map، Roughness،
Displacement و سایر داده‌های سطح.

Geometry

Vertexها، Indexها، Meshها و داده مدل‌های
سه‌بعدی.

Frame Buffer

تصویر نهایی، Depth، Stencil و Render Targetها.

Shader Data

Constantها، Bufferها و داده‌های موردنیاز
اجرای Shader.

Ray Tracing Data

ساختارهای شتاب‌دهنده، هندسه و داده‌های
مربوط به پرتوها.

AI Models

وزن‌های مدل، Activationها، KV Cache و
داده‌های محاسباتی.

خطای Out of Memory در GPU چیست؟

اگر نرم‌افزار نتواند فضای کافی داخل VRAM برای
داده‌های موردنیاز اختصاص دهد، ممکن است خطای
Out of Memory نمایش داده شود.

این مشکل در رندرهای سنگین، مدل‌های هوش مصنوعی،
بازی‌های با Texture بسیار بزرگ و پروژه‌های تدوین
وضوح‌بالا دیده می‌شود.

  • کاهش وضوح Texture
  • کاهش اندازه Batch
  • استفاده از مدل Quantized
  • کاهش اندازه تصویر یا Render Tile
  • بستن برنامه‌های مصرف‌کننده GPU
  • استفاده از کارت با VRAM بیشتر

Shared GPU Memory در ویندوز چیست؟

ویندوز ممکن است بخشی از RAM سیستم را به‌عنوان
Shared GPU Memory نمایش دهد.

این مقدار به معنی وجود همان ظرفیت حافظه پرسرعت روی
کارت گرافیک نیست.

کارت مجزا در صورت نیاز می‌تواند بخشی از RAM سیستم
را استفاده کند، اما این مسیر معمولاً از VRAM
اختصاصی کندتر است.


Dedicated و Shared را با هم جمع نکنید

اگر ویندوز ۴ گیگابایت Dedicated و ۸ گیگابایت
Shared نشان می‌دهد، کارت شما ۱۲ گیگابایت VRAM
واقعی ندارد.

حافظه گرافیک مجتمع چگونه کار می‌کند؟

گرافیک‌های مجتمع معمولاً VRAM مستقل ندارند و از
RAM سیستم استفاده می‌کنند.

سرعت RAM، تعداد کانال‌ها، تأخیر حافظه و محدودیت
توان پردازنده بر عملکرد گرافیک مجتمع اثر می‌گذارد.

استفاده از حافظه دوکاناله می‌تواند پهنای باند بیشتری
برای Intel HD، UHD، Iris Xe و گرافیک‌های مجتمع AMD
فراهم کند.

حافظه در Quadro، RTX Professional و Radeon Pro

کارت‌های حرفه‌ای ممکن است ظرفیت VRAM بیشتر،
پشتیبانی ECC، درایورهای تخصصی و مدیریت حافظه مناسب
پروژه‌های بزرگ داشته باشند.

Quadro K، M و P معمولاً از حافظه‌های نسل قدیمی‌تر
مانند GDDR5 استفاده می‌کنند. Quadro RTX،
RTX A Series و RTX Professional جدیدتر بیشتر از
GDDR6 و ظرفیت‌های بالاتر بهره می‌برند.

Radeon Pro و Arc Pro نیز بر اساس نسل و مدل، ظرفیت
حافظه و قابلیت‌های متفاوتی ارائه می‌کنند.

حافظه در کارت‌ها و لپ‌تاپ‌های قدیمی

نمونه حافظه در مدل‌های قدیمی و استوک
مدل نوع حافظه رایج ظرفیت‌های متداول نکته
GeForce GT 740M DDR3 یا GDDR5 بسته به نسخه ۱ تا ۲ گیگابایت نوع حافظه حتماً بررسی شود
GTX 960M GDDR5 ۲ یا ۴ گیگابایت برای پروژه‌های جدید محدود است
Quadro K2100M GDDR5 معمولاً ۲ گیگابایت مناسب پروژه‌های سبک قدیمی
Quadro M2000M GDDR5 معمولاً ۴ گیگابایت مناسب CAD متوسط نسل قبل
Quadro P2000 GDDR5 معمولاً ۵ گیگابایت تعادل مناسب برای ورک‌استیشن استوک
GTX 1050 Ti GDDR5 معمولاً ۴ گیگابایت مناسب بازی و طراحی سبک
GTX 1060 GDDR5 ۳ یا ۶ گیگابایت نسخه ۶ گیگابایت محدودیت کمتری دارد
Radeon RX 580 GDDR5 ۴ یا ۸ گیگابایت سلامت کارت دست‌دوم بررسی شود

گلوگاه حافظه GPU چیست؟

گلوگاه حافظه زمانی ایجاد می‌شود که واحدهای پردازشی
GPU سریع‌تر از توان سیستم حافظه به داده نیاز داشته
باشند.

در این وضعیت، Shader Coreها، CUDA Coreها،
Stream Processorها یا Xe Coreها بخشی از زمان خود
را منتظر رسیدن داده می‌مانند.

ظرفیت ناکافی VRAM

داده‌ها به RAM سیستم منتقل می‌شوند یا
نرم‌افزار مجبور به کاهش کیفیت می‌شود.

پهنای باند محدود

حجم کافی داده در زمان مناسب به واحدهای
پردازشی نمی‌رسد.

تأخیر بالا

پاسخ‌گویی به درخواست‌های حافظه زمان بیشتری
نیاز دارد.

Cache Miss زیاد

داده‌های موردنیاز به‌جای Cache باید از
VRAM خوانده شوند.

دسترسی نامنظم

Threadها به نواحی پراکنده حافظه دسترسی
پیدا می‌کنند و بهره‌وری کاهش می‌یابد.

مصرف بیش‌ازحد Register

تعداد Threadهای هم‌زمان کاهش پیدا می‌کند
و پنهان‌سازی تأخیر دشوارتر می‌شود.

الگوی دسترسی به حافظه چرا مهم است؟

عملکرد حافظه فقط به مشخصات سخت‌افزاری وابسته نیست.
نحوه دسترسی برنامه به داده‌ها نیز اهمیت زیادی دارد.

اگر Threadهای مجاور به آدرس‌های نزدیک و منظم
دسترسی داشته باشند، GPU می‌تواند درخواست‌ها را
مؤثرتر ترکیب کند.

دسترسی‌های پراکنده، نامنظم یا تکراری می‌توانند
پهنای باند بیشتری مصرف کنند و Cache را با داده‌های
کم‌استفاده پر کنند.

دسترسی منظم

  • آدرس‌های نزدیک
  • استفاده بهتر از Cache
  • انتقال مؤثرتر داده
  • درخواست‌های حافظه کمتر

دسترسی نامنظم

  • آدرس‌های پراکنده
  • Cache Miss بیشتر
  • درخواست‌های متعدد
  • تأخیر بالاتر

Memory Coalescing چیست؟

Memory Coalescing به ترکیب چند درخواست حافظه
Threadهای یک گروه در تعداد کمتری تراکنش بزرگ‌تر
گفته می‌شود.

اگر Threadهای مجاور داده‌های پشت‌سرهم را بخوانند،
کنترل‌کننده حافظه می‌تواند انتقال را با بهره‌وری
بالاتری انجام دهد.

دسترسی‌های پراکنده ممکن است به چندین تراکنش جدا
تبدیل شوند و پهنای باند مؤثر را کاهش دهند.

Prefetching چیست؟

Prefetching یعنی داده پیش از لحظه استفاده احتمالی
از حافظه دورتر خوانده و به Cache نزدیک‌تر منتقل شود.

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

Prefetch نامناسب ممکن است پهنای باند و فضای Cache
را با داده‌هایی مصرف کند که هرگز استفاده نمی‌شوند.

Paging و جابه‌جایی داده میان VRAM و RAM

اگر داده‌های موردنیاز از ظرفیت VRAM بیشتر شوند،
سیستم‌عامل و درایور ممکن است بخشی از آن‌ها را میان
VRAM و RAM سیستم جابه‌جا کنند.

این انتقال از طریق PCI Express انجام می‌شود و
معمولاً بسیار کندتر از دسترسی مستقیم GPU به VRAM
است.

نتیجه ممکن است افت نرخ فریم، مکث، کندشدن Viewport،
افزایش زمان رندر یا خطای حافظه باشد.


Shared Memory جای VRAM واقعی را نمی‌گیرد

استفاده از RAM سیستم می‌تواند از بسته‌شدن
برنامه جلوگیری کند، اما سرعت و تأخیر آن با
VRAM اختصاصی برابر نیست.

نقش PCI Express در انتقال داده‌های GPU

PCI Express مسیر اصلی ارتباط کارت گرافیک مجزا با
CPU و RAM سیستم است.

زمانی که داده داخل VRAM وجود ندارد، ممکن است از
RAM سیستم از طریق PCIe منتقل شود.

نسل PCIe و تعداد Laneها روی پهنای باند این ارتباط
اثر می‌گذارند، اما همچنان ارتباط داخلی GPU با
VRAM معمولاً بسیار سریع‌تر است.

Resizable BAR چه ارتباطی با حافظه GPU دارد؟

Resizable BAR به CPU اجازه می‌دهد بخش بزرگ‌تری از
VRAM کارت گرافیک را به‌صورت مستقیم در فضای آدرس
خود مشاهده کند.

بدون این قابلیت، دسترسی ممکن است در پنجره‌های
کوچک‌تر انجام شود.

تأثیر عملکرد به بازی، درایور، معماری GPU،
مادربرد و پردازنده بستگی دارد و همیشه یکسان نیست.

حافظه ECC در کارت گرافیک چیست؟

ECC مخفف
Error-Correcting Code
است و برای شناسایی و اصلاح بعضی خطاهای حافظه
استفاده می‌شود.

این قابلیت در محاسبات علمی، سرور، شبیه‌سازی،
پزشکی، مهندسی و پروژه‌هایی که صحت داده اهمیت
بالایی دارد، مفید است.

بعضی کارت‌های حرفه‌ای Quadro، RTX Professional،
Radeon Pro و شتاب‌دهنده‌های دیتاسنتر از ECC
پشتیبانی می‌کنند.


ECC در همه کارت‌های حرفه‌ای وجود ندارد

پشتیبانی ECC به مدل کارت، نوع حافظه، معماری
و تنظیمات درایور بستگی دارد.

خرابی حافظه گرافیکی چه نشانه‌هایی دارد؟

  • نمایش نقاط یا خطوط رنگی
  • ایجاد مربع‌ها و الگوهای غیرعادی
  • خراب‌شدن Textureها
  • بسته‌شدن بازی یا نرم‌افزار
  • خطای Driver Timeout
  • صفحه سیاه زیر بار
  • خطا در تست حافظه GPU
  • ناپایداری در فرکانس حافظه

این نشانه‌ها همیشه به معنی خرابی قطعی VRAM نیستند
و ممکن است از درایور، اورکلاک، گرما، پاور یا GPU
نیز ناشی شوند.

دمای حافظه گرافیکی

تراشه‌های VRAM در زمان بازی، رندر یا استخراج
می‌توانند گرمای قابل‌توجهی تولید کنند.

تماس مناسب Thermal Pad با هیت‌سینک، جریان هوا و
طراحی خنک‌کننده روی دمای حافظه اثر دارند.

دمای بیش‌ازحد می‌تواند باعث کاهش فرکانس، خطا،
ناپایداری یا کاهش عمر قطعات شود.

VRAM مناسب برای بازی

میزان حافظه موردنیاز بازی به وضوح، کیفیت Texture،
Ray Tracing، بسته‌های گرافیکی و طراحی موتور بازی
بستگی دارد.

وقتی مصرف حافظه به سقف VRAM نزدیک شود، ممکن است
Textureها دیر بارگذاری شوند یا مکث ایجاد شود.

عدد مناسب ثابت نیست و باید با بازی‌ها و تنظیمات
موردنظر کاربر سنجیده شود.

VRAM برای AutoCAD و SolidWorks

پروژه‌های دوبعدی سبک معمولاً حافظه گرافیکی زیادی
نیاز ندارند.

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

در SolidWorks و نرم‌افزارهای حرفه‌ای، درایور و
گواهی سازگاری نیز در کنار ظرفیت حافظه اهمیت دارند.

VRAM برای Blender و رندر سه‌بعدی

در رندر GPU، مدل‌ها، Textureها، نورها و داده‌های
صحنه باید در حافظه کارت قرار بگیرند.

اگر صحنه داخل VRAM جا نشود، موتور رندر ممکن است
خطا دهد، به CPU منتقل شود یا با سرعت بسیار کمتر
از حافظه سیستم استفاده کند.

صحنه‌های دارای Textureهای 4K و 8K، Geometry زیاد
و چندین Asset به VRAM بیشتری نیاز دارند.

VRAM برای هوش مصنوعی

در هوش مصنوعی، وزن‌های مدل، Activationها،
Gradientها و داده‌های ورودی داخل حافظه GPU قرار
می‌گیرند.

آموزش مدل معمولاً حافظه بیشتری از اجرای مدل نیاز
دارد.

Quantization، کاهش Batch Size، Offloading و
Gradient Checkpointing از روش‌های کاهش مصرف حافظه
هستند.


برای AI ظرفیت VRAM بسیار مهم است

کارت سریع با حافظه ناکافی ممکن است نتواند مدل
موردنظر را اجرا کند؛ درحالی‌که کارت کندتر با
حافظه بیشتر ممکن است پروژه را کامل اجرا کند.

اشتباهات رایج درباره حافظه GPU

  • جمع‌کردن Dedicated VRAM و Shared Memory
  • مقایسه کارت‌ها فقط بر اساس ظرفیت حافظه
  • تصور اینکه باس عریض‌تر همیشه سریع‌تر است
  • نادیده‌گرفتن نوع حافظه
  • نادیده‌گرفتن Cache و فشرده‌سازی
  • یکی‌دانستن Memory Clock و نرخ مؤثر انتقال
  • تصور اینکه ECC در تمام Quadroها وجود دارد
  • تصور اینکه حافظه بیشتر نرخ فریم را همیشه افزایش می‌دهد
  • نادیده‌گرفتن دمای VRAM در کارت دست‌دوم
  • مقایسه مستقیم پهنای باند نسل‌های مختلف بدون
    توجه به معماری

سؤالات متداول درباره حافظه GPU

VRAM چیست؟

حافظه اختصاصی کارت گرافیک برای نگهداری
Texture، مدل، Frame Buffer و داده‌های
محاسباتی است.

آیا VRAM بیشتر همیشه بهتر است؟

ظرفیت بیشتر محدودیت پروژه‌های بزرگ را کاهش
می‌دهد، اما قدرت GPU، پهنای باند و معماری
نیز اهمیت دارند.

Shared GPU Memory چیست؟

بخشی از RAM سیستم است که GPU در صورت نیاز
می‌تواند از آن استفاده کند.

آیا Shared Memory به اندازه VRAM سریع است؟

معمولاً خیر. کارت مجزا از طریق PCI Express
به RAM سیستم دسترسی دارد و این مسیر کندتر
از VRAM است.

Bus Width چیست؟

عرض مسیر انتقال داده میان GPU و VRAM است
و همراه با سرعت حافظه روی پهنای باند اثر
می‌گذارد.

آیا باس ۲۵۶ بیتی همیشه از ۱۲۸ بیتی سریع‌تر است؟

خیر. نوع حافظه، سرعت انتقال، Cache و
معماری نیز باید مقایسه شوند.

Register Pressure چیست؟

مصرف زیاد Register برای هر Thread است که
می‌تواند تعداد Threadهای هم‌زمان را کاهش
دهد.

Infinity Cache چیست؟

کش بزرگ داخل بعضی GPUهای AMD است که مراجعه
به VRAM را کاهش می‌دهد.

ECC چه کاربردی دارد؟

بعضی خطاهای حافظه را شناسایی و اصلاح می‌کند
و برای محاسبات حساس مفید است.

کمبود VRAM چه نشانه‌ای دارد؟

افت عملکرد، مکث، دیر بارگذاری‌شدن Texture،
خطای Out of Memory یا بسته‌شدن برنامه.

برای Blender چه مقدار VRAM لازم است؟

به حجم صحنه، Textureها و موتور رندر بستگی
دارد و یک مقدار ثابت برای همه پروژه‌ها وجود
ندارد.

برای هوش مصنوعی VRAM مهم‌تر است یا سرعت GPU؟

هر دو مهم‌اند، اما اگر مدل داخل حافظه جا
نشود، سرعت بالاتر GPU قابل استفاده نخواهد
بود.


فصل ۱۵-۶

Thread، Warp، Wavefront، Scheduler و Occupancy در GPU

پردازنده گرافیکی برای اجرای تعداد بسیار زیادی
عملیات موازی، کارها را به Threadها و گروه‌های
پردازشی تقسیم می‌کند. این Threadها در معماری‌های
NVIDIA، AMD و Intel با ساختارها و نام‌گذاری‌های
متفاوت زمان‌بندی و اجرا می‌شوند.

نمای کلی اجرای موازی در GPU

مهم‌ترین تفاوت پردازنده گرافیکی با پردازنده مرکزی
در نحوه اجرای دستورها است. CPU معمولاً تعداد کمی
Thread بسیار قدرتمند را اجرا می‌کند، در حالی که GPU
برای اجرای هم‌زمان هزاران Thread طراحی شده است.

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

البته GPU تمام Threadها را به صورت کاملاً مستقل
اجرا نمی‌کند؛ بلکه آن‌ها را در قالب گروه‌هایی
سازمان‌دهی می‌کند تا سخت‌افزار بتواند با کمترین
هزینه، بیشترین میزان پردازش موازی را انجام دهد.


تعریف ساده

GPU ابتدا کار بزرگ را به هزاران Thread تقسیم
می‌کند و سپس آن‌ها را به صورت گروهی روی
واحدهای پردازشی اجرا می‌کند.

چرا GPU هزاران Thread را هم‌زمان اجرا می‌کند؟

حافظه گرافیکی نسبت به واحدهای محاسباتی تأخیر
بیشتری دارد. اگر GPU فقط چند Thread اجرا کند،
هنگام انتظار برای دریافت داده بخش زیادی از
سخت‌افزار بیکار خواهد ماند.

به همین دلیل GPU هزاران Thread آماده اجرا نگه
می‌دارد تا هر زمان گروهی منتظر حافظه شد،
گروه دیگری فوراً جایگزین آن شود.

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

تفاوت مدل اجرای CPU و GPU

مقایسه مدل اجرای CPU و GPU
ویژگی CPU GPU
تعداد Thread کم بسیار زیاد
قدرت هر Thread بسیار زیاد کمتر
هدف طراحی اجرای عمومی پردازش موازی انبوه
تأخیر کم با مخفی‌سازی تأخیر مدیریت می‌شود
مناسب برای سیستم‌عامل، برنامه‌های عمومی بازی، رندر، هوش مصنوعی و پردازش تصویر

Thread در GPU چیست؟

کوچک‌ترین واحد اجرایی در پردازنده گرافیکی
Thread است.

هر Thread مجموعه مشخصی از دستورها را اجرا می‌کند،
Registerهای مخصوص خود را دارد و روی داده‌ای مشخص
کار می‌کند.

برای مثال اگر قرار باشد یک تصویر چهار میلیون
پیکسلی پردازش شود، ممکن است میلیون‌ها Thread ایجاد
شوند و هر Thread مسئول پردازش یک یا چند پیکسل باشد.


مثال ساده

تصور کنید هزار نفر هم‌زمان در حال رنگ‌آمیزی
یک نقاشی بسیار بزرگ هستند. هر نفر فقط قسمت
کوچکی را رنگ می‌کند؛ اما در پایان کل تصویر
بسیار سریع آماده می‌شود.

تفاوت Thread در CPU و GPU

واژه Thread هم در CPU و هم در GPU استفاده می‌شود،
اما مفهوم و هدف طراحی آن‌ها کاملاً یکسان نیست.

در CPU هر Thread تقریباً یک واحد پردازشی قدرتمند
محسوب می‌شود که می‌تواند وظایف پیچیده، شاخه‌های
شرطی متعدد و دسترسی‌های نامنظم به حافظه را مدیریت
کند.

در مقابل، Threadهای GPU بسیار سبک هستند و برای
اجرای تعداد بسیار زیادی عملیات مشابه طراحی شده‌اند.

مقایسه Thread در CPU و GPU
ویژگی CPU Thread GPU Thread
تعداد کم بسیار زیاد
قدرت هر Thread زیاد کمتر
هدف اجرای برنامه‌های عمومی پردازش موازی گسترده
شاخه‌های شرطی بسیار مناسب مناسب ولی با محدودیت
تأخیر حافظه با Cache مدیریت می‌شود با اجرای هزاران Thread پنهان می‌شود

Thread ID و Thread Index چیست؟

هر Thread دارای شناسه‌ای است که محل آن را در میان
سایر Threadها مشخص می‌کند.

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

برای مثال اگر یک تصویر شامل یک میلیون پیکسل باشد،
هر Thread می‌تواند بر اساس شناسه خود فقط یک پیکسل
مشخص را پردازش کند.


مثال

Thread شماره ۵۲۳۴ فقط روی داده شماره ۵۲۳۴
عملیات انجام می‌دهد و با سایر Threadها تداخلی
ندارد.

Thread Group چیست؟

مدیریت میلیون‌ها Thread به صورت مستقل امکان‌پذیر
نیست؛ بنابراین GPU آن‌ها را در قالب گروه‌هایی
سازمان‌دهی می‌کند.

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

نام این گروه‌ها در APIهای مختلف متفاوت است؛ برای
مثال در CUDA از Block و در OpenCL از Workgroup
استفاده می‌شود.

Thread Block در CUDA چیست؟

در CUDA مجموعه‌ای از Threadها که روی یک
Streaming Multiprocessor اجرا می‌شوند،
Thread Block نام دارند.

تمام Threadهای یک Block می‌توانند از Shared Memory
مشترک استفاده کنند و با دستورهای همگام‌سازی
یکدیگر را هماهنگ کنند.

اندازه Block هنگام طراحی برنامه انتخاب می‌شود و
روی کارایی GPU تأثیر مستقیم دارد.


نکته

انتخاب Block بسیار کوچک یا بسیار بزرگ ممکن است
باعث کاهش Occupancy و افت عملکرد شود.

Workgroup چیست؟

در OpenCL، Vulkan Compute و بسیاری از APIهای
مدرن، به مجموعه‌ای از Threadها که با هم اجرا
می‌شوند Workgroup گفته می‌شود.

مفهوم Workgroup بسیار شبیه Thread Block در CUDA
است، هرچند جزئیات پیاده‌سازی آن به API و معماری
بستگی دارد.

اعضای یک Workgroup می‌توانند از حافظه مشترک،
Barrier و عملیات هماهنگ‌سازی استفاده کنند.

Grid در پردازش GPU چیست؟

Grid مجموعه کامل Thread Blockها یا Workgroupهایی
است که برای اجرای یک Kernel یا Compute Shader
ایجاد می‌شوند.

هر Grid می‌تواند یک‌بعدی، دوبعدی یا سه‌بعدی باشد.
این ساختار کمک می‌کند داده‌هایی مانند آرایه،
تصویر، ویدئو یا حجم سه‌بعدی به‌شکل منظم میان
Threadها تقسیم شوند.

کاربرد ابعاد مختلف Grid
ساختار Grid نمونه داده کاربرد رایج
یک‌بعدی آرایه یا فهرست پردازش عددی، جست‌وجو و مرتب‌سازی
دوبعدی تصویر یا ماتریس پردازش تصویر، فیلتر و رندر
سه‌بعدی حجم، Voxel یا داده فضایی شبیه‌سازی، پزشکی و رندر حجمی

Dispatch و Compute Dispatch چیست؟

Dispatch دستوری است که اجرای مجموعه‌ای از
Workgroupها یا Threadها را روی GPU آغاز می‌کند.

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

در DirectCompute، Vulkan، OpenCL و سایر رابط‌های
محاسباتی، نام و شیوه تعریف Dispatch متفاوت است؛
اما مفهوم اصلی یکسان باقی می‌ماند.


مرحله ۱


تعیین داده

برنامه مشخص می‌کند چه تعداد عنصر باید
پردازش شوند.


مرحله ۲


انتخاب اندازه گروه

تعداد Threadهای هر Block یا Workgroup
تعیین می‌شود.


مرحله ۳


ایجاد Dispatch

تعداد گروه‌ها در یک، دو یا سه بُعد مشخص
می‌شود.


مرحله ۴


توزیع روی GPU

Scheduler گروه‌ها را میان واحدهای آزاد
توزیع می‌کند.

تفاوت SIMD و SIMT چیست؟

SIMD مخفف
Single Instruction, Multiple Data
است؛ یعنی یک دستور روی چند داده اجرا می‌شود.

SIMT مخفف
Single Instruction, Multiple Threads
است و مدل برنامه‌نویسی رایج در GPUهای NVIDIA را
توصیف می‌کند.

در SIMT برنامه‌نویس با Threadهای مستقل کار می‌کند،
اما سخت‌افزار بسیاری از آن‌ها را به‌صورت گروهی
و با دستور مشترک اجرا می‌کند.

مقایسه SIMD و SIMT
معیار SIMD SIMT
دید برنامه‌نویس یک دستور برداری چند Thread مستقل
اجرای سخت‌افزاری یک دستور روی چند Lane یک دستور روی گروهی از Threadها
شاخه شرطی معمولاً با Mask ممکن است Divergence ایجاد کند
کاربرد رایج CPUهای برداری و GPU مدل اجرایی CUDA و GPU

Warp در NVIDIA چیست؟

Warp گروه پایه زمان‌بندی و اجرای Threadها در
بسیاری از GPUهای NVIDIA است.

یک Warp معمولاً شامل ۳۲ Thread است. این Threadها
در حالت عادی دستور مشترکی را اجرا می‌کنند، اما هر
Thread روی داده و Registerهای مخصوص خود کار می‌کند.

Thread Block پیش از اجرا به چند Warp تقسیم می‌شود.
برای نمونه، یک Block دارای ۲۵۶ Thread به هشت Warp
۳۲تایی تقسیم خواهد شد.

نمونه تقسیم Thread Block به Warp
تعداد Thread در Block تعداد Warp وضعیت Warp آخر
۳۲ ۱ کامل
۶۴ ۲ کامل
۱۲۸ ۴ کامل
۲۵۶ ۸ کامل
۲۸۰ ۹ Warp آخر فقط ۲۴ Thread فعال دارد

Wavefront در AMD چیست؟

Wavefront گروهی از Work-Itemها است که در GPUهای
AMD با یکدیگر زمان‌بندی و اجرا می‌شوند.

در بسیاری از معماری‌های قدیمی GCN، اندازه رایج
Wavefront برابر ۶۴ Thread یا Work-Item بود.

معماری‌های جدیدتر RDNA می‌توانند از حالت‌های
Wave32 یا Wave64 استفاده کنند. انتخاب اندازه
Wave به Shader، API، کامپایلر و معماری بستگی دارد.

اندازه Wavefront در خانواده‌های مختلف AMD
خانواده معماری اندازه رایج نمونه محصولات
GCN Wave64 Radeon HD 7000، R9، RX 400 و RX 500
Vega معمولاً Wave64 Radeon RX Vega و Radeon Pro Vega
RDNA Wave32 و در بعضی مسیرها Wave64 Radeon RX 5000
RDNA 2 و جدیدتر متناسب با Shader و معماری Radeon RX 6000 و نسل‌های بعد

اجرای Thread در GPUهای Intel

GPUهای Intel نیز Threadها را در گروه‌های SIMD یا
Subgroup سازمان‌دهی می‌کنند.

عرض اجرای SIMD می‌تواند بر اساس معماری، نوع
Shader، کامپایلر و دستورهای برنامه متفاوت باشد.

در APIهایی مانند OpenCL، SYCL و Vulkan، اصطلاح
Subgroup برای مجموعه‌ای از Invocationها استفاده
می‌شود که می‌توانند عملیات گروهی و ارتباط مستقیم
انجام دهند.

مقایسه Warp، Wavefront و Subgroup

مقایسه گروه‌های اجرایی در NVIDIA، AMD و Intel
شرکت یا رابط نام گروه اندازه رایج نکته مهم
NVIDIA Warp معمولاً ۳۲ Thread واحد اصلی زمان‌بندی Threadها
AMD Wavefront Wave32 یا Wave64 اندازه به معماری و Shader وابسته است
Intel SIMD Group یا Subgroup وابسته به معماری عرض اجرا ممکن است متغیر باشد
Vulkan و OpenCL Subgroup وابسته به سخت‌افزار نباید بدون بررسی، اندازه ثابت فرض شود

Warp Scheduler چیست؟

Warp Scheduler بخشی از GPU است که Warpهای آماده
اجرا را انتخاب می‌کند و دستور بعدی آن‌ها را برای
واحدهای اجرایی می‌فرستد.

یک SM می‌تواند چندین Warp فعال داشته باشد، اما
همه آن‌ها در یک لحظه دستور صادر نمی‌کنند.
Scheduler بررسی می‌کند کدام Warp آماده است و
منابع موردنیاز آن در دسترس قرار دارند.

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

Instruction Scheduler چیست؟

Instruction Scheduler مشخص می‌کند کدام دستور،
در چه زمان و روی کدام واحد اجرایی اجرا شود.

دستورها ممکن است مربوط به محاسبات عددی، بارگذاری
حافظه، ذخیره داده، Texture Sampling، عملیات
ماتریسی یا Branch باشند.

Scheduler باید وابستگی میان دستورها را نیز در نظر
بگیرد. اگر نتیجه یک دستور هنوز آماده نشده باشد،
دستور وابسته به آن نمی‌تواند اجرا شود.

نمونه انواع دستورهای زمان‌بندی‌شده در GPU
نوع دستور واحد اجرایی احتمالی نمونه کاربرد
FP32 واحد محاسبات اعشاری Shader و رندر
INT واحد محاسبات صحیح Index، آدرس‌دهی و منطق
Load Load/Store Unit خواندن داده از حافظه
Store Load/Store Unit نوشتن نتیجه در حافظه
Texture TMU نمونه‌برداری و فیلتر بافت
Matrix Tensor Core، XMX یا واحد معادل هوش مصنوعی و ضرب ماتریسی
Branch واحد کنترل جریان شرط و حلقه

Warp آماده و Warp متوقف‌شده چیست؟

وضعیت‌های رایج Warp در زمان اجرا
وضعیت معنی دلیل نمونه
Ready دستور بعدی Warp قابل اجرا است داده و واحد اجرایی آماده‌اند
Stalled on Memory Warp منتظر داده حافظه است Cache Miss یا دسترسی به VRAM
Stalled on Dependency نتیجه دستور قبلی هنوز آماده نیست وابستگی داده
Stalled on Barrier Warp منتظر رسیدن سایر Threadها است Synchronization
Stalled on Resource واحد اجرایی یا صف موردنیاز آزاد نیست رقابت برای منابع
Completed اجرای Warp تمام شده است پایان دستورها

Latency Hiding چگونه انجام می‌شود؟

GPU به‌جای تلاش برای کاهش کامل تأخیر حافظه،
معمولاً آن را با اجرای Warpهای دیگر پنهان می‌کند.

وقتی یک Warp منتظر داده است، Scheduler می‌تواند
دستور Warp آماده دیگری را صادر کند.

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


۱


Warp نخست دستور حافظه می‌فرستد

دریافت داده چندین سیکل زمان نیاز دارد.


۲


Warp نخست متوقف می‌شود

تا آماده‌شدن داده، قابل صدور نیست.


۳


Scheduler Warp دیگری را انتخاب می‌کند

دستورهای مستقل Warp دوم اجرا می‌شوند.


۴


داده Warp نخست آماده می‌شود

Warp دوباره وارد فهرست آماده‌ها می‌شود.

جابه‌جایی میان گروه‌های Thread در GPU

GPU می‌تواند میان Warpها یا Wavefrontهای فعال
بسیار سریع جابه‌جا شود؛ زیرا وضعیت اجرایی آن‌ها
مانند Registerها از قبل روی تراشه نگهداری می‌شود.

این جابه‌جایی با Context Switch سنگین میان
Threadهای CPU یکسان نیست و معمولاً هزینه بسیار
کمتری دارد.

هدف اصلی این سازوکار، پنهان‌کردن تأخیر و استفاده
مداوم از واحدهای اجرایی است.

Branch Divergence چیست؟

Branch Divergence زمانی رخ می‌دهد که Threadهای
یک Warp یا Wavefront در یک شرط، مسیرهای متفاوتی
انتخاب کنند.

از آنجا که اعضای گروه معمولاً دستور مشترکی را
اجرا می‌کنند، سخت‌افزار ممکن است هر مسیر را
جداگانه اجرا و Threadهای مسیر دیگر را موقتاً
غیرفعال کند.

Warp Serialization چیست؟

Warp Serialization به حالتی گفته می‌شود که
عملیات اعضای یک Warp به‌جای اجرای هم‌زمان، در
چند مرحله جدا انجام شوند.

Branch Divergence، بعضی دسترسی‌های حافظه،
Atomic Operationهای پرتداخل و Bank Conflict
می‌توانند باعث نوعی Serialization شوند.

نتیجه معمولاً کاهش بهره‌وری و طولانی‌ترشدن زمان
اجرای Warp است.

دلایل رایج Serialization در GPU
عامل اثر راهکار احتمالی
Branch Divergence اجرای جداگانه مسیرهای شرطی گروه‌بندی داده‌های مشابه
Bank Conflict دسترسی ترتیبی به Shared Memory اصلاح چیدمان داده
Atomic Contention انتظار Threadها برای یک آدرس کاهش اشتراک نقطه نوشتن
دسترسی پراکنده حافظه تراکنش‌های بیشتر Coalescing بهتر

Reconvergence چیست؟

پس از پایان مسیرهای متفاوت یک Branch، Threadهای
گروه دوباره در نقطه مشترکی به یکدیگر می‌رسند.

این فرایند Reconvergence نام دارد و پس از آن
اعضای گروه می‌توانند اجرای دستور مشترک را ادامه
دهند.

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

مقایسه مفهومی زمان‌بندی در NVIDIA، AMD و Intel

نام‌گذاری اجزای زمان‌بندی در معماری‌های مختلف
شرکت گروه اجرایی بلوک پردازشی حافظه مشترک رایج
NVIDIA Warp SM Shared Memory
AMD Wavefront CU یا WGP LDS
Intel Subgroup یا SIMD Group Xe Core و ساختارهای مرتبط Shared Local Memory

Occupancy در GPU چیست؟

Occupancy نسبت تعداد Warpها، Wavefrontها یا
Threadهای فعال به حداکثر تعداد قابل پشتیبانی در
هر واحد پردازشی GPU است.

این معیار نشان می‌دهد چه مقدار از ظرفیت اجرایی
SM، Compute Unit یا بلوک مشابه توسط گروه‌های
فعال اشغال شده است.

Occupancy بالاتر معمولاً Warpهای آماده بیشتری در
اختیار Scheduler قرار می‌دهد و می‌تواند به
پنهان‌کردن تأخیر حافظه کمک کند.

آیا Occupancy بیشتر همیشه به معنی عملکرد بهتر است؟

خیر. Occupancy بالا فقط یکی از عوامل عملکرد است و
به‌تنهایی سرعت بیشتر را تضمین نمی‌کند.

یک Kernel ممکن است با Occupancy متوسط، استفاده
بسیار خوبی از واحدهای محاسباتی داشته باشد و سریع‌تر
از Kernel دیگری با Occupancy بالا اجرا شود.

اگر برنامه به حافظه وابستگی کمی داشته باشد یا
محاسبات سنگین و مستقل اجرا کند، افزایش Occupancy
ممکن است سود محدودی ایجاد کند.

رابطه Occupancy با عملکرد
وضعیت نتیجه احتمالی توضیح
Occupancy بسیار پایین احتمال افت عملکرد Warp آماده کافی برای پنهان‌کردن
تأخیر وجود ندارد
Occupancy متوسط ممکن است کاملاً مناسب باشد منابع بیشتری برای هر Thread باقی
می‌ماند
Occupancy بسیار بالا لزوماً سریع‌تر نیست ممکن است محدودیت دیگری مانند حافظه
یا دستور وجود داشته باشد
Occupancy بالا با Register کم احتمال Spilling کاهش Register می‌تواند دسترسی به
حافظه را افزایش دهد

عوامل محدودکننده Occupancy

مهم‌ترین عوامل محدودکننده تعداد Threadهای فعال
عامل نحوه ایجاد محدودیت پیامد احتمالی
تعداد Register هر Thread بخشی از Register File را
اشغال می‌کند
کاهش تعداد Warpهای مقیم
Shared Memory هر Block بخشی از حافظه مشترک را
رزرو می‌کند
کاهش تعداد Blockهای هم‌زمان
اندازه Thread Block Blockهای بسیار بزرگ منابع بیشتری
مصرف می‌کنند
جای‌گیری دشوارتر روی SM
سقف Thread سخت‌افزار هر واحد پردازشی حداکثر Thread مشخصی
پشتیبانی می‌کند
محدودیت مستقل از حافظه
سقف Warp یا Wavefront تعداد گروه‌های مقیم محدود است توقف افزایش Occupancy
سقف تعداد Block تعداد Blockهای مقیم در هر واحد
محدود است
Blockهای کوچک همیشه بهتر نیستند

تأثیر Register بر Occupancy

هر Thread برای نگهداری داده‌های موقت خود تعدادی
Register مصرف می‌کند.

اگر هر Thread Register زیادی نیاز داشته باشد،
Register File سریع‌تر پر می‌شود و تعداد Threadهای
هم‌زمان کاهش پیدا می‌کند.

کاهش مصرف Register می‌تواند Occupancy را افزایش
دهد؛ اما اگر بیش‌ازحد انجام شود، Register Spilling
و دسترسی بیشتر به حافظه ایجاد خواهد شد.

تأثیر Shared Memory بر Occupancy

هر Thread Block یا Workgroup می‌تواند مقداری از
Shared Memory واحد پردازشی را رزرو کند.

اگر هر Block بخش بزرگی از Shared Memory را مصرف
کند، تعداد Blockهایی که هم‌زمان روی SM یا Compute
Unit قرار می‌گیرند کاهش پیدا می‌کند.

استفاده مناسب از Shared Memory می‌تواند دسترسی به
VRAM را کاهش دهد و با وجود Occupancy کمتر، عملکرد
نهایی را افزایش دهد.

اندازه Block چه اثری بر Occupancy دارد؟

اندازه Block تعیین می‌کند هر گروه چند Thread داشته
باشد و به چند Warp یا Wavefront تقسیم شود.

Block بسیار کوچک ممکن است نتواند تمام ظرفیت واحد
پردازشی را استفاده کند. Block بسیار بزرگ نیز ممکن
است به دلیل محدودیت Register یا Shared Memory
تعداد گروه‌های مقیم را کاهش دهد.

اثر احتمالی اندازه Thread Block
اندازه Block مزیت احتمالی محدودیت احتمالی
بسیار کوچک مصرف منابع کمتر برای هر Block تعداد Warp کم و استفاده ضعیف از SM
متوسط تعادل مناسب منابع و تعداد Warp نیازمند آزمون عملی
بسیار بزرگ Threadهای بیشتر در هر Block کاهش تعداد Blockهای هم‌زمان
غیرمضرب اندازه Warp انعطاف در بعضی الگوریتم‌ها ایجاد Warp نیمه‌خالی

Active Warp و Resident Warp چیست؟

Resident Warp به Warpi گفته می‌شود که منابع لازم
برای آن روی واحد پردازشی رزرو شده و وضعیت اجرایی
آن داخل GPU قرار دارد.

Active Warp معمولاً Warpi است که هنوز اجرای آن
کامل نشده و می‌تواند در چرخه زمان‌بندی شرکت کند.

همه Warpهای Resident در هر لحظه آماده صدور دستور
نیستند؛ بعضی ممکن است منتظر حافظه، Barrier یا نتیجه
دستور قبلی باشند.

تفاوت وضعیت‌های Warp
اصطلاح تعریف قابلیت صدور فوری دستور
Resident Warp منابع آن روی SM رزرو شده است لزوماً نه
Active Warp اجرای آن هنوز پایان نیافته است وابسته به وضعیت
Eligible Warp دستور بعدی آن قابل صدور است بله
Stalled Warp منتظر رویداد یا منبع است خیر

مثال ساده محاسبه مفهومی Occupancy

فرض کنید یک SM حداکثر توان نگهداری ۶۴ Warp فعال
را دارد، اما به دلیل مصرف Register و Shared Memory
فقط ۳۲ Warp روی آن قرار گرفته‌اند.

در این مثال Occupancy مفهومی برابر نصف ظرفیت
سخت‌افزار است.

این عدد به‌تنهایی مشخص نمی‌کند Kernel سریع یا کند
است؛ زیرا ممکن است همان ۳۲ Warp برای مشغول نگه
داشتن واحدهای اجرایی کافی باشند.

چگونه Occupancy را بهینه کنیم؟

روش‌های رایج بهینه‌سازی Occupancy
روش مزیت خطر یا محدودیت
کاهش Register افزایش Threadهای مقیم احتمال Register Spilling
کاهش Shared Memory هر Block افزایش Blockهای هم‌زمان افزایش مراجعه به VRAM
تغییر اندازه Block جای‌گیری بهتر روی SM کاهش کارایی الگوریتم
کاهش پیچیدگی Kernel مصرف منابع کمتر نیاز به چند Dispatch جدا
استفاده از ابزار Profiling شناسایی محدودیت واقعی نیاز به آزمون روی سخت‌افزار هدف

Synchronization در GPU چیست؟

هنگام اجرای هزاران Thread، همیشه همه آن‌ها با سرعت
یکسان پیش نمی‌روند. بعضی زودتر به نتیجه می‌رسند،
بعضی منتظر حافظه می‌مانند و برخی هنوز در حال انجام
محاسبات هستند.

Synchronization مکانیزمی است که باعث می‌شود گروهی
از Threadها قبل از ادامه اجرای برنامه، منتظر
رسیدن سایر اعضای گروه بمانند.

این قابلیت از تولید داده‌های ناقص، خواندن اطلاعات
اشتباه و ایجاد Race Condition جلوگیری می‌کند.

دلایل استفاده از Synchronization
کاربرد دلیل نمونه
اشتراک داده جلوگیری از خواندن داده ناقص Shared Memory
محاسبات گروهی اطمینان از پایان مرحله قبلی Reduction
پردازش ماتریسی هماهنگی میان Tileها Tensor Core
پردازش تصویر آماده بودن همسایه‌ها Blur و Filter
شبیه‌سازی جلوگیری از استفاده از داده قدیمی Fluid Simulation

Barrier چیست؟

Barrier نقطه‌ای در برنامه است که تمام Threadهای
یک گروه باید به آن برسند تا اجرای مرحله بعد آغاز
شود.

اگر حتی یک Thread دیرتر برسد، سایر اعضای همان
گروه منتظر خواهند ماند.

Thread 0 ─────────────┐
Thread 1 ───────┐     │
Thread 2 ─────────────┤
Thread 3 ──┐          │
            ▼
         Barrier
            │
            ▼
   Continue Execution

Memory Barrier چیست؟

Memory Barrier تضمین می‌کند عملیات خواندن و
نوشتن حافظه با ترتیب مشخصی برای سایر Threadها
قابل مشاهده باشد.

این مکانیزم هنگام استفاده از Shared Memory،
Global Memory و عملیات موازی اهمیت زیادی دارد.

بدون Memory Barrier ممکن است بعضی Threadها
داده‌های قدیمی را مشاهده کنند.

Atomic Operation چیست؟

Atomic Operation عملیاتی است که به‌صورت تجزیه‌ناپذیر
روی یک مقدار حافظه انجام می‌شود؛ یعنی Threadهای دیگر
نمی‌توانند همان مقدار را در میانه عملیات تغییر دهند.

این قابلیت زمانی مهم است که چند Thread بخواهند
هم‌زمان یک شمارنده، Histogram، آدرس مشترک یا ساختار
داده یکسان را به‌روزرسانی کنند.

بدون Atomic Operation ممکن است چند Thread مقدار
قدیمی را بخوانند و نتیجه بعضی به‌روزرسانی‌ها از بین
برود.

عملیات Atomic رایج در GPU
عملیات وظیفه نمونه کاربرد
Atomic Add افزودن مقدار به متغیر مشترک شمارنده و Histogram
Atomic Sub کم‌کردن مقدار مدیریت شمارنده منابع
Atomic Min نگهداری کوچک‌ترین مقدار جست‌وجوی کمینه
Atomic Max نگهداری بزرگ‌ترین مقدار جست‌وجوی بیشینه
Compare and Swap مقایسه مقدار و جایگزینی شرطی Lock و ساختار داده هم‌زمان
Atomic Exchange جایگزینی مقدار به‌صورت اتمیک علامت‌گذاری وضعیت

Atomic Contention چیست؟

اگر تعداد زیادی Thread بخواهند هم‌زمان یک آدرس
حافظه را با عملیات Atomic تغییر دهند، درخواست‌ها
ممکن است پشت‌سرهم اجرا شوند.

این وضعیت Atomic Contention نام دارد و می‌تواند
اجرای موازی را به گلوگاه تبدیل کند.

هرچه تعداد Threadهای درگیر و تمرکز آن‌ها روی یک
آدرس بیشتر باشد، احتمال Serialization نیز بیشتر
می‌شود.

Race Condition چیست؟

Race Condition زمانی رخ می‌دهد که نتیجه برنامه به
ترتیب زمان‌بندی و اجرای Threadها وابسته باشد.

اگر دو یا چند Thread بدون هماهنگی روی یک داده
مشترک بخوانند یا بنویسند، نتیجه می‌تواند در هر
اجرا متفاوت باشد.

Race Condition ممکن است باعث خروجی اشتباه، ناپایداری،
خطای تصویری یا خراب‌شدن داده شود.

الگوهای رایج Race Condition
نوع تداخل توضیح خطر
Write After Write چند Thread روی یک آدرس می‌نویسند یکی از نتایج از بین می‌رود
Read After Write Thread داده‌ای را پیش از کامل‌شدن
نوشتن می‌خواند
دریافت مقدار قدیمی یا ناقص
Write After Read داده پیش از پایان استفاده Thread
دیگر تغییر می‌کند
نتیجه غیرقابل پیش‌بینی

مثال ساده Race Condition

فرض کنید مقدار یک شمارنده برابر ۱۰ است و دو Thread
هم‌زمان می‌خواهند آن را یک واحد افزایش دهند.

استفاده از Atomic Add می‌تواند تضمین کند هر افزایش
بدون ازبین‌رفتن نتیجه Thread دیگر انجام شود.

Data Hazard چیست؟

Data Hazard زمانی ایجاد می‌شود که ترتیب اجرای
دستورها و دسترسی به داده برای صحت نتیجه اهمیت
داشته باشد.

این وابستگی ممکن است داخل یک Thread، میان Threadهای
یک گروه یا میان چند Dispatch ایجاد شود.

Barrier، Atomic Operation، Memory Fence و طراحی
درست الگوریتم از ابزارهای مدیریت این وابستگی‌ها
هستند.

Lock و Spinlock در GPU

Lock مکانیزمی برای محدودکردن دسترسی هم‌زمان به
یک منبع مشترک است.

Spinlock حالتی است که Thread تا آزادشدن Lock در
یک حلقه منتظر می‌ماند.

استفاده نادرست از Spinlock در GPU می‌تواند تعداد
زیادی Thread را مشغول انتظار کند و کارایی را به‌شدت
کاهش دهد.

Deadlock در پردازش GPU چیست؟

Deadlock زمانی رخ می‌دهد که چند Thread یا گروه
برای منابع یا رویدادهایی منتظر یکدیگر بمانند و
هیچ‌کدام نتوانند ادامه دهند.

Barrier شرطی، Lockهای تو در تو، انتظار حلقه‌ای و
هماهنگی نادرست میان Threadها از دلایل رایج Deadlock
هستند.

دلایل رایج Deadlock در GPU
علت وضعیت راهکار
Barrier داخل شرط فقط بخشی از Threadها به Barrier
می‌رسند
اطمینان از رسیدن تمام اعضای گروه
Lock حلقه‌ای هر Thread منتظر منبع Thread دیگر است ترتیب ثابت دریافت Lock
Spinlock نامناسب Threadها بدون پیشرفت منتظر می‌مانند استفاده از الگوریتم بدون Lock
هماهنگی میان Blockها فرض هم‌زمانی Blockهایی که ممکن است
هم‌زمان مقیم نباشند
تقسیم کار به چند Dispatch

چرا Barrier داخل شرط خطرناک است؟

اگر فقط بعضی Threadهای یک Workgroup وارد مسیر شرطی
شوند و به Barrier برسند، سایر Threadها ممکن است
هرگز به همان Barrier نرسند.

در نتیجه Threadهای رسیده برای همیشه منتظر باقی
می‌مانند و برنامه متوقف می‌شود یا رفتار تعریف‌نشده
ایجاد می‌کند.

اصول همگام‌سازی امن در GPU

روش‌های کاهش خطاهای هم‌زمانی
اصل توضیح
کاهش داده مشترک تا جای ممکن هر Thread روی داده
مستقل کار کند
استفاده محدود از Atomic Atomic فقط در نقاط لازم استفاده شود
Barrier یکنواخت تمام Threadهای گروه باید به Barrier
برسند
تقسیم الگوریتم مراحل پیچیده به چند Kernel یا Dispatch
تقسیم شوند
استفاده از Shared Memory محلی رقابت روی Global Memory کاهش پیدا کند
Profiling و Validation خطاهای هم‌زمانی روی سخت‌افزار هدف
بررسی شوند

Cooperative Groups چیست؟

Cooperative Groups روشی برای تعریف و مدیریت
گروه‌های مختلف Thread در برنامه‌های موازی است.

به‌جای اینکه برنامه فقط کل Thread Block را به‌عنوان
یک گروه در نظر بگیرد، می‌تواند زیرگروه‌های کوچک‌تر
یا مجموعه‌های بزرگ‌تری از Threadها را برای همکاری
و همگام‌سازی ایجاد کند.

این قابلیت در الگوریتم‌هایی که نیاز به ارتباط
مستقیم، رأی‌گیری، جابه‌جایی داده و هماهنگی میان
گروه‌های مشخص دارند مفید است.

نمونه گروه‌های همکاری در پردازش GPU
نوع گروه اعضا کاربرد
Thread Block Group تمام Threadهای یک Block همگام‌سازی و Shared Memory
Tiled Group زیرمجموعه‌ای با اندازه مشخص عملیات گروهی کوچک‌تر
Warp-Level Group Threadهای یک Warp Shuffle، Vote و Reduction
Grid Group مجموعه بزرگ‌تری از Blockها هماهنگی گسترده در اجرای سازگار

عملیات Subgroup و Warp-Level

اعضای یک Warp، Wavefront یا Subgroup می‌توانند
بعضی عملیات را بدون استفاده مستقیم از Shared
Memory انجام دهند.

این عملیات برای تبادل سریع داده، رأی‌گیری جمعی،
یافتن Threadهای فعال و انجام Reductionهای کوچک
کاربرد دارند.

عملیات رایج در سطح Warp یا Subgroup
عملیات وظیفه نمونه کاربرد
Shuffle انتقال مستقیم مقدار میان Laneها Reduction و Scan
Ballot ساخت Mask از نتیجه شرط Threadها تشخیص اعضای فعال
Any بررسی درست‌بودن شرط برای حداقل یک عضو خروج زودهنگام گروهی
All بررسی درست‌بودن شرط برای همه اعضا تصمیم‌گیری جمعی
Match شناسایی اعضای دارای مقدار مشابه گروه‌بندی داده

Parallel Reduction چیست؟

Parallel Reduction روشی برای تبدیل مجموعه بزرگی
از داده‌ها به یک نتیجه کوچک‌تر مانند مجموع،
میانگین، کمینه یا بیشینه است.

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

کاربردهای Parallel Reduction
عملیات نتیجه نمونه کاربرد
Sum مجموع داده‌ها آمار و تحلیل عددی
Minimum کوچک‌ترین مقدار جست‌وجوی کمینه
Maximum بزرگ‌ترین مقدار جست‌وجوی بیشینه
Average میانگین پردازش تصویر و داده
Logical Reduction نتیجه AND یا OR بررسی شرط جمعی

Prefix Sum یا Scan چیست؟

Prefix Sum عملیاتی است که برای هر عنصر، مجموع
عناصر قبلی یا عناصر قبلی به‌علاوه خود آن را
محاسبه می‌کند.

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

تفاوت Inclusive و Exclusive Scan
نوع Scan ورودی خروجی نمونه
Inclusive ۱، ۲، ۳، ۴ ۱، ۳، ۶، ۱۰
Exclusive ۱، ۲، ۳، ۴ ۰، ۱، ۳، ۶

ساخت Histogram روی GPU

Histogram تعداد تکرار مقادیر مختلف را محاسبه
می‌کند. برای نمونه در تصویر خاکستری می‌توان تعداد
پیکسل‌های هر سطح روشنایی را شمارش کرد.

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

برای کاهش رقابت، معمولاً هر Block یک Histogram
محلی در Shared Memory می‌سازد و در پایان نتایج
محلی با یکدیگر ادغام می‌شوند.


۱


تقسیم داده

هر Thread بخشی از تصویر یا آرایه را
پردازش می‌کند.


۲


شمارش محلی

هر Block شمارنده‌های محلی خود را می‌سازد.


۳


همگام‌سازی

Threadها پس از پایان شمارش محلی هماهنگ
می‌شوند.


۴


ادغام نتایج

Histogramهای محلی در خروجی نهایی جمع
می‌شوند.

مرتب‌سازی موازی روی GPU

الگوریتم‌هایی مانند Radix Sort، Bitonic Sort و
Merge Sort می‌توانند برای اجرای موازی روی GPU
طراحی شوند.

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

چند الگوریتم مرتب‌سازی مناسب GPU
الگوریتم مزیت محدودیت
Radix Sort مناسب کلیدهای عددی نیاز به چند مرحله عبور
Bitonic Sort الگوی منظم و قابل موازی‌سازی برای داده بسیار بزرگ همیشه بهینه نیست
Merge Sort مناسب داده‌های عمومی نیاز به حافظه میانی

اجرای محاسبات ماتریسی توسط Threadها

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

ماتریس‌های بزرگ به Tileهای کوچک‌تر تقسیم می‌شوند
و هر Block یا Workgroup مسئول پردازش بخشی از
خروجی است.

داده‌های Tile می‌توانند در Shared Memory قرار
بگیرند تا چندین بار بدون مراجعه مکرر به VRAM
استفاده شوند.

مقایسه Reduction، Scan و Histogram

مقایسه الگوریتم‌های پایه پردازش موازی
الگوریتم ورودی خروجی چالش اصلی
Reduction آرایه بزرگ یک یا چند مقدار خلاصه ترکیب مرحله‌ای داده‌ها
Scan آرایه ترتیبی مجموع‌های پیشوندی حفظ ارتباط ترتیب عناصر
Histogram داده دسته‌بندی‌شونده شمارنده هر دسته Atomic Contention
Matrix Multiply دو ماتریس ماتریس نتیجه پهنای باند و استفاده مجدد داده

نقش Threadها در بازی و رندر گرافیکی

در رندر گرافیکی، هر Thread می‌تواند بخشی از
پردازش یک رأس، Fragment، پیکسل، نمونه بافت،
پرتو یا داده مربوط به یک افکت را انجام دهد.

موتور بازی یا نرم‌افزار سه‌بعدی حجم بزرگی از
داده‌ها را به GPU می‌فرستد و سخت‌افزار آن‌ها را
میان هزاران Thread تقسیم می‌کند.

عملکرد نهایی به هماهنگی میان Shaderها، حافظه،
Scheduler، TMU، ROP و واحدهای اختصاصی بستگی دارد.

نمونه وظایف Threadها در مسیر رندر
مرحله وظیفه Thread داده پردازش‌شده
Vertex Shader محاسبه موقعیت و ویژگی رأس Vertex، Normal و مختصات
Pixel Shader محاسبه رنگ و نور Fragment Texture، Material و نور
Compute Shader اجرای افکت یا محاسبه عمومی تصویر، Buffer و داده عددی
Ray Tracing Shader پردازش پرتو و برخورد هندسه و ساختار شتاب‌دهنده
Post Processing پردازش پیکسل‌های تصویر نهایی Frame Buffer و Render Target

اجرای Thread در موتورهای بازی

موتورهای بازی از GPU برای پردازش نور، سایه،
Texture، ذرات، انعکاس، Ambient Occlusion،
Anti-Aliasing و بسیاری از افکت‌های تصویری استفاده
می‌کنند.

هر Draw Call یا Dispatch می‌تواند هزاران Thread
ایجاد کند. تعداد و نوع Threadها به پیچیدگی Shader،
وضوح تصویر و تعداد اشیای صحنه وابسته است.

در وضوح‌های بالاتر، تعداد Fragmentها افزایش
پیدا می‌کند و فشار بیشتری روی Pixel Shaderها،
حافظه و مراحل خروجی رندر وارد می‌شود.

نقش Threadها در Ray Tracing

در Ray Tracing تعداد زیادی پرتو از دوربین، منابع
نور یا نقاط برخورد تولید می‌شوند.

هر Thread می‌تواند یک یا چند پرتو را پردازش کند،
ساختار شتاب‌دهنده را پیمایش کند و نتیجه برخورد را
برای Shaderهای بعدی آماده سازد.

پرتوها ممکن است مسیرها و تعداد برخوردهای متفاوتی
داشته باشند. این تفاوت می‌تواند باعث Divergence
میان Threadهای یک Warp یا Wavefront شود.

منابع واگرایی Thread در Ray Tracing
عامل اثر نتیجه احتمالی
مسیر متفاوت پرتو پیمایش متفاوت ساختار هندسی Divergence بیشتر
Material متفاوت اجرای Shaderهای گوناگون کاهش یکپارچگی Warp
تعداد Bounce متفاوت طول اجرای نامساوی Threadهای غیرفعال بیشتر
Miss و Hit متفاوت مسیرهای برنامه متفاوت Serialization برخی مسیرها

نقش Threadها در هوش مصنوعی

مدل‌های هوش مصنوعی شامل تعداد بسیار زیادی عملیات
ماتریسی، برداری و انتقال داده هستند.

Threadها بخش‌های مختلف ماتریس، Tensor یا Batch را
پردازش می‌کنند و داده‌ها را برای CUDA Core،
Tensor Core، XMX یا واحدهای مشابه آماده می‌سازند.

عملکرد مناسب به چیدمان حافظه، اندازه Tile، نوع
داده، Occupancy و هماهنگی میان Threadها وابسته است.

نقش Threadها در مراحل هوش مصنوعی
مرحله وظیفه Threadها منبع مهم
بارگذاری وزن‌ها انتقال بخش‌های مدل به حافظه سریع VRAM و پهنای باند
ضرب ماتریسی تقسیم محاسبات میان Tileها Tensor Core و Shared Memory
Activation اجرای تابع روی عناصر خروجی Shader Core و Register
Reduction جمع یا نرمال‌سازی داده Subgroup و Shared Memory
Attention پردازش ماتریس‌های Query، Key و Value VRAM، Cache و واحد ماتریسی

اجرای Thread در مدل‌های زبانی بزرگ

در مدل‌های زبانی، Threadها در عملیات ضرب ماتریسی،
Attention، نرمال‌سازی، نمونه‌گیری و مدیریت
KV Cache مشارکت می‌کنند.

ظرفیت VRAM تعیین می‌کند چه مقدار از وزن مدل و
KV Cache روی GPU باقی بماند.

اگر بخشی از مدل به RAM یا CPU منتقل شود، Threadهای
GPU ممکن است منتظر انتقال داده بمانند و استفاده
از واحدهای محاسباتی کاهش پیدا کند.

نقش Threadها در پردازش ویدئو

بخشی از پردازش ویدئو توسط موتورهای اختصاصی Encode
و Decode انجام می‌شود، اما Shaderها و Compute
Threadها نیز در افکت، تصحیح رنگ، Scaling،
Denoising و پردازش فریم نقش دارند.

نرم‌افزارهایی مانند Premiere Pro، DaVinci Resolve
و After Effects ممکن است بسته به افکت و کدک از
مسیرهای متفاوت GPU استفاده کنند.

تقسیم وظایف ویدئویی میان واحدهای GPU
وظیفه واحد اصلی نقش Threadهای عمومی
Decode موتور رمزگشایی پردازش تکمیلی فریم
Encode موتور رمزگذاری آماده‌سازی و افکت
Color Grading Shader و Compute پردازش پیکسل‌ها
Noise Reduction Compute و AI تحلیل همسایگی فریم
Scaling Shader یا واحد رسانه نمونه‌برداری و بازسازی تصویر

نقش Threadها در AutoCAD، SolidWorks و نرم‌افزارهای CAD

در نرم‌افزارهای CAD، GPU بیشتر برای نمایش Viewport،
رسم خطوط، سایه‌زنی، Anti-Aliasing و نمایش مدل
سه‌بعدی استفاده می‌شود.

هرچه Assembly، تعداد قطعات، خطوط و افکت‌های Viewport
بیشتر باشد، تعداد بیشتری Thread و منابع گرافیکی
درگیر می‌شوند.

بااین‌حال بسیاری از عملیات مدل‌سازی، بازسازی Feature
و محاسبات هندسی همچنان به CPU وابسته‌اند.

نقش GPU در چند نرم‌افزار مهندسی
نرم‌افزار وظیفه رایج GPU عامل مهم دیگر
AutoCAD نمایش دوبعدی و سه‌بعدی قدرت تک‌هسته‌ای CPU
SolidWorks Viewport و RealView درایور حرفه‌ای و CPU
CATIA نمایش Assembly و مدل گواهی ISV و VRAM
Siemens NX Viewport و Visualization درایور و پیچیدگی پروژه
Revit نمایش سه‌بعدی و افکت‌ها CPU و RAM سیستم

اجرای Thread در Quadro و کارت‌های حرفه‌ای

کارت‌های Quadro، RTX Professional، Radeon Pro و
Arc Pro از اصول کلی اجرای موازی مشابه GPUهای
مصرف‌کننده استفاده می‌کنند.

تفاوت اصلی می‌تواند در تعداد واحدهای فعال، ظرفیت
VRAM، قابلیت ECC، توان مصرفی، Firmware و درایور
حرفه‌ای باشد.

درایور حرفه‌ای می‌تواند نحوه اجرای Shaderها،
مدیریت حافظه و پایداری Viewport را برای نرم‌افزارهای
تخصصی بهینه کند.

نقش معماری Thread در خانواده‌های حرفه‌ای
خانواده گروه اجرایی کاربرد رایج
NVIDIA Quadro Warp CAD، مدل‌سازی و Visualization
NVIDIA RTX Professional Warp و واحدهای RTX رندر، AI و طراحی حرفه‌ای
AMD Radeon Pro Wavefront CAD، محتوا و محاسبات حرفه‌ای
Intel Arc Pro Subgroup و SIMD تولید محتوا و ورک‌استیشن

اجرای Thread در GPUهای قدیمی

کارت‌های قدیمی نیز از اجرای گروهی Threadها استفاده
می‌کنند، اما ظرفیت Register، Cache، تعداد Scheduler
و ویژگی‌های معماری آن‌ها محدودتر است.

نمونه معماری Thread در کارت‌های قدیمی و استوک
مدل یا خانواده معماری گروه اجرایی محدودیت امروز
Quadro K2100M Kepler Warp ۳۲تایی VRAM و توان محدود
Quadro M2000M Maxwell Warp ۳۲تایی فاقد واحدهای جدید AI و RT
Quadro P2000 Pascal Warp ۳۲تایی بدون RT Core اختصاصی
GTX 960M Maxwell Warp ۳۲تایی توان و حافظه محدود لپ‌تاپی
GTX 1060 Pascal Warp ۳۲تایی محدودیت در AI و Ray Tracing جدید
Radeon RX 580 Polaris / GCN Wave64 مصرف برق و نبود RT اختصاصی
Radeon Pro WX 7100 Polaris Wave64 محدودیت نسل معماری
Intel HD 4000 نسل قدیمی Intel SIMD توان پردازشی و حافظه مشترک محدود

فهرست مطالب فصل الگوهای دسترسی به حافظه GPU
بخش عنوان موضوع اصلی سطح مطالعه
۱
مفهوم Memory Access
آشنایی با نحوه دسترسی Threadها به حافظه
مقدماتی
۲
Coalesced Memory Access
ترکیب درخواست‌های حافظه و افزایش پهنای باند مؤثر
متوسط
۳
Uncoalesced Memory Access
دسترسی پراکنده و افزایش تعداد تراکنش‌های حافظه
متوسط
۴
Memory Alignment
هم‌ترازی آدرس‌ها و چیدمان صحیح داده‌ها
پیشرفته
۵ Strided Access دسترسی Threadها به داده‌ها با فاصله ثابت
پیشرفته
۶
Random Access
دسترسی تصادفی و تأثیر آن بر Cache و VRAM
پیشرفته
۷
Gather و Scatter
خواندن و نوشتن داده از آدرس‌های پراکنده
پیشرفته
۸
Cache-Friendly Access
طراحی الگوی دسترسی مناسب برای افزایش Cache Hit
متوسط
۹
مقایسه روش‌های دسترسی
مقایسه سرعت، تأخیر، Cache و پهنای باند
متوسط
۱۰
بهینه‌سازی دسترسی به حافظه
روش‌های کاهش تراکنش و افزایش بهره‌وری GPU
پیشرفته
۱۱
نمونه در GPUهای قدیمی
GTX، Quadro، Radeon و گرافیک‌های قدیمی Intel
متوسط
۱۲ کاربرد در کارت‌های حرفه‌ای Quadro، RTX Professional، Radeon Pro و Arc Pro
متوسط
۱۳
اشتباهات رایج
خطاهای متداول در تحلیل و برنامه‌نویسی حافظه
مقدماتی
۱۴
خلاصه فصل
مرور نکات مهم و نتیجه‌گیری نهایی
مقدماتی
۱۵
سؤالات متداول
پاسخ به پرسش‌های رایج کاربران
مقدماتی

Memory Access در GPU چیست؟

Memory Access به فرایند خواندن داده از حافظه یا
نوشتن نتیجه در حافظه توسط Threadهای GPU گفته می‌شود.

هر Thread برای اجرای دستورهای خود ممکن است به
Register، Shared Memory، Cache، VRAM یا حافظه
سیستم دسترسی پیدا کند.

سرعت این دسترسی‌ها یکسان نیست. Register و Shared
Memory معمولاً بسیار سریع‌تر از VRAM هستند، اما
ظرفیت محدودتری دارند.

اگر Threadها داده‌ها را با الگوی منظم و نزدیک به
یکدیگر بخوانند، سخت‌افزار می‌تواند درخواست‌های
آن‌ها را با تراکنش‌های کمتری انجام دهد.

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

مسیر دسترسی Thread به حافظه

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

اگر داده داخل Cache پیدا نشود، درخواست باید به
سطح پایین‌تر حافظه و در نهایت VRAM ارسال شود.

انواع اصلی دسترسی حافظه در GPU

دسته‌بندی الگوهای رایج دسترسی به حافظه
نوع دسترسی ساختار آدرس‌ها بهره‌وری احتمالی نمونه کاربرد
Sequential آدرس‌های متوالی بسیار مناسب پردازش آرایه و تصویر
Coalesced درخواست‌های مجاور Threadهای یک گروه بسیار مناسب خواندن بردار و ماتریس
Strided آدرس‌ها با فاصله ثابت وابسته به اندازه Stride پردازش ستون‌های ماتریس
Random آدرس‌های پراکنده و نامنظم معمولاً ضعیف‌تر گراف و ساختارهای نامنظم
Gather خواندن از چند آدرس پراکنده وابسته به Cache نمونه‌برداری و جست‌وجو
Scatter نوشتن در چند آدرس پراکنده ممکن است پرتداخل باشد ساخت خروجی و Histogram

تفاوت خواندن و نوشتن حافظه

عملیات Read داده را از حافظه دریافت می‌کند،
درحالی‌که عملیات Write نتیجه را در آدرس مشخصی
ذخیره می‌کند.

خواندن ممکن است از Cache پاسخ داده شود، اما نوشتن
باید بر اساس سیاست Cache و معماری به سطح مناسب
حافظه منتقل شود.

نوشتن هم‌زمان چند Thread روی یک آدرس می‌تواند
Race Condition ایجاد کند و ممکن است به Atomic
Operation نیاز داشته باشد.

مقایسه عملیات خواندن و نوشتن حافظه
معیار Memory Read Memory Write
جهت انتقال حافظه به واحد پردازشی واحد پردازشی به حافظه
استفاده از Cache معمولاً گسترده وابسته به سیاست معماری
خطر تداخل کمتر بیشتر
نیاز احتمالی به Atomic معمولاً ندارد در نوشتن مشترک ممکن است لازم باشد

Memory Transaction چیست؟

GPU برای هر مقدار کوچک الزاماً یک انتقال جداگانه
انجام نمی‌دهد. درخواست‌های Threadها می‌توانند در
تراکنش‌های بزرگ‌تر حافظه ترکیب شوند.

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

اگر آدرس‌ها پراکنده باشند، سخت‌افزار مجبور می‌شود
چندین تراکنش انجام دهد؛ حتی اگر هر Thread فقط مقدار
کوچکی داده نیاز داشته باشد.

چه عواملی بر سرعت دسترسی حافظه اثر دارند؟

عوامل مؤثر بر کارایی دسترسی Threadها به حافظه
عامل اثر نتیجه احتمالی
نزدیکی آدرس‌ها امکان ترکیب درخواست‌ها تراکنش کمتر
Memory Alignment قرارگیری داده روی مرز مناسب انتقال مؤثرتر
اندازه داده تعیین حجم هر درخواست مصرف پهنای باند متفاوت
Cache Hit Rate کاهش مراجعه به VRAM تأخیر کمتر
Stride افزایش فاصله آدرس‌ها احتمال تراکنش بیشتر
Branch Divergence تغییر الگوی فعال‌بودن Threadها دسترسی نامنظم‌تر
Atomic Contention رقابت برای آدرس مشترک Serialization
پهنای باند VRAM سقف انتقال داده محدودیت در بارهای سنگین

تفاوت Memory-Bound و Compute-Bound

مقایسه گلوگاه حافظه و گلوگاه محاسبات
معیار Memory-Bound Compute-Bound
عامل محدودکننده انتقال یا تأخیر حافظه توان واحدهای محاسباتی
وضعیت Shader Core بخشی از زمان منتظر داده بیشتر زمان در حال محاسبه
بهبود مؤثر Cache، Coalescing و کاهش انتقال کاهش دستور و افزایش توان Compute
نمونه جابه‌جایی آرایه بزرگ با محاسبه کم ضرب ماتریسی سنگین

Coalesced Memory Access چیست؟

Coalesced Memory Access زمانی رخ می‌دهد که
Threadهای مجاور یک Warp، Wavefront یا Subgroup
به آدرس‌های نزدیک و منظم حافظه دسترسی داشته باشند.

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

نتیجه این فرایند کاهش تعداد تراکنش‌ها، استفاده
بهتر از پهنای باند و کاهش زمان انتظار Threadها است.

ساختار یک دسترسی Coalesced

چرا Coalescing اهمیت دارد؟

حافظه خارجی GPU مانند GDDR یا HBM داده را در
بلوک‌ها و تراکنش‌های مشخص منتقل می‌کند.

اگر Threadها فقط بخش کوچکی از چندین بلوک حافظه را
درخواست کنند، مقدار زیادی از پهنای باند بدون
استفاده مفید مصرف می‌شود.

دسترسی Coalesced کمک می‌کند داده منتقل‌شده با
نیاز واقعی Threadها تطابق بیشتری داشته باشد.

مزایای دسترسی Coalesced
مزیت اثر مستقیم نتیجه احتمالی
تراکنش کمتر درخواست‌های Threadها ترکیب می‌شوند کاهش فشار روی حافظه
استفاده بهتر از پهنای باند داده منتقل‌شده بیشتر استفاده می‌شود سرعت بالاتر Kernel
Cache Line مؤثرتر Threadهای مجاور از داده‌های یک بلوک
استفاده می‌کنند
Cache Hit بیشتر
تأخیر قابل پنهان‌سازی درخواست‌های حافظه سریع‌تر تکمیل می‌شوند Warpهای متوقف‌شده کمتر
مصرف انرژی کمتر انتقال‌های اضافی کاهش پیدا می‌کنند بهره‌وری بالاتر GPU

مثال دسترسی Coalesced به آرایه

فرض کنید هر Thread باید یک عنصر از یک آرایه بزرگ
را پردازش کند.

اگر Thread شماره صفر عنصر صفر، Thread شماره یک
عنصر یک و Thread شماره دو عنصر دو را بخواند،
دسترسی‌ها منظم و مجاور خواهند بود.

دسترسی سطری به ماتریس

در بسیاری از زبان‌ها، عناصر هر سطر ماتریس به‌صورت
پشت‌سرهم در حافظه ذخیره می‌شوند.

اگر Threadهای مجاور عناصر یک سطر را پردازش کنند،
آدرس‌های حافظه نیز مجاور خواهند بود و دسترسی
Coalesced شکل می‌گیرد.

پردازش ستونی همان ماتریس ممکن است فاصله بیشتری
میان آدرس‌ها ایجاد کند و به Strided Access تبدیل
شود.

مقایسه دسترسی سطری و ستونی به ماتریس
روش دسترسی الگوی آدرس وضعیت احتمالی
دسترسی سطری عناصر متوالی مناسب برای Coalescing
دسترسی ستونی عناصر با فاصله ثابت احتمال Strided Access
دسترسی Tile-Based بلوک‌های کوچک و محلی مناسب برای Cache و Shared Memory

تفاوت Structure of Arrays و Array of Structures

نحوه چیدمان داده‌های ساختاریافته می‌تواند بر
Coalescing تأثیر زیادی داشته باشد.

در Array of Structures، تمام ویژگی‌های هر عنصر
کنار یکدیگر ذخیره می‌شوند.

در Structure of Arrays، هر ویژگی در یک آرایه
جداگانه قرار می‌گیرد.

مقایسه AoS و SoA
چیدمان ساختار حافظه مزیت محدودیت
Array of Structures تمام ویژگی‌های هر عنصر کنار هم مناسب دسترسی کامل به هر شیء دسترسی یک ویژگی ممکن است پراکنده شود
Structure of Arrays هر ویژگی در آرایه جدا مناسب دسترسی گروهی Threadها مدیریت ساختار پیچیده‌تر

اندازه داده و Coalescing

اندازه هر عنصر نیز بر تعداد تراکنش‌ها اثر دارد.
Thread ممکن است داده‌ای ۱، ۲، ۴، ۸ یا ۱۶ بایتی
بخواند.

اگر اندازه و هم‌ترازی داده با نیاز سخت‌افزار
هماهنگ باشد، دسترسی مؤثرتر انجام می‌شود.

ساختارهایی با Padding نامناسب یا اندازه غیرمعمول
می‌توانند مرز تراکنش را بشکنند و انتقال بیشتری
ایجاد کنند.

اثر اندازه داده بر دسترسی حافظه
اندازه عنصر نمونه نوع داده نکته
۱ بایت Byte یا Char ممکن است چند مقدار در یک تراکنش قرار گیرند
۲ بایت FP16 یا Int16 رایج در AI و پردازش تصویر
۴ بایت FP32 یا Int32 یکی از اندازه‌های رایج و مناسب
۸ بایت FP64 یا Int64 پهنای باند بیشتری مصرف می‌کند
۱۶ بایت Vector چهارتایی هم‌ترازی مناسب اهمیت بیشتری دارد

Coalesced Write چیست؟

Coalescing فقط به عملیات Read محدود نیست. نوشتن
Threadهای مجاور در آدرس‌های نزدیک نیز می‌تواند
با تراکنش‌های مؤثرتری انجام شود.

اگر هر Thread نتیجه خود را در یک عنصر متوالی از
آرایه خروجی بنویسد، الگوی Write معمولاً منظم خواهد
بود.

نوشتن در آدرس‌های پراکنده می‌تواند تراکنش بیشتر،
فشار بالاتر روی Cache و احتمال تداخل ایجاد کند.

محدودیت‌های دسترسی Coalesced

همه الگوریتم‌ها به‌طور طبیعی الگوی منظم ندارند.
پردازش گراف، ساختارهای درختی، Ray Tracing و
جست‌وجوی نامنظم ممکن است به آدرس‌های پراکنده نیاز
داشته باشند.

در چنین شرایطی، استفاده از Cache، مرتب‌سازی داده،
گروه‌بندی Workload یا تغییر چیدمان حافظه می‌تواند
بخشی از هزینه را کاهش دهد.

عواملی که Coalescing را دشوار می‌کنند
عامل مشکل ایجادشده راهکار احتمالی
داده نامنظم آدرس‌های پراکنده مرتب‌سازی یا گروه‌بندی داده
Branch Divergence فقط بخشی از Threadها دسترسی دارند همگن‌سازی Workload
ساختار AoS فاصله میان ویژگی‌های مشابه استفاده از SoA
Stride بزرگ عبور از چندین بلوک حافظه Transpose یا Tile-Based Processing
Alignment نامناسب شکستن تراکنش روی چند مرز Padding و هم‌ترازی مناسب

کاربرد Coalesced Access در نرم‌افزارهای مختلف

اهمیت دسترسی منظم در کاربردهای مختلف GPU
کاربرد نوع داده اهمیت Coalescing
پردازش تصویر پیکسل‌های مجاور بسیار زیاد
ضرب ماتریسی سطرها، ستون‌ها و Tileها بسیار زیاد
رندر Vertex، Texture و Buffer زیاد
هوش مصنوعی Tensor و Weight بسیار زیاد
شبیه‌سازی Grid و داده‌های همسایه زیاد
پردازش گراف Node و Edge پراکنده دشوار ولی مهم

Random Memory Access چیست؟

Random Memory Access به حالتی گفته می‌شود که
Threadهای GPU داده‌های موردنیاز خود را از آدرس‌های
کاملاً نامنظم و غیرقابل پیش‌بینی دریافت می‌کنند.

برخلاف Coalesced Access که آدرس‌ها کنار هم قرار
دارند، در Random Access هر Thread ممکن است به
نقطه‌ای کاملاً متفاوت از حافظه مراجعه کند.

این الگو معمولاً باعث افزایش Cache Miss،
افزایش Memory Transaction و کاهش کارایی GPU
می‌شود.

نمونه دسترسی تصادفی

Memory

0   1   2   3   4   5   6   7

12  18  31  44  51  70  83  99

Thread0 → 83

Thread1 → 12

Thread2 → 44

Thread3 → 99

Thread4 → 18

Thread5 → 70

Random Pattern

تأثیر Random Access بر عملکرد GPU

زمانی که درخواست‌های حافظه تصادفی باشند،
کنترل‌کننده حافظه نمی‌تواند آن‌ها را به‌خوبی
ادغام کند و در نتیجه تعداد زیادی انتقال مستقل
ایجاد می‌شود.

اثر دسترسی تصادفی بر منابع GPU
بخش اثر Random Access
Memory Transaction افزایش تعداد انتقال‌ها
Cache افزایش Cache Miss
پهنای باند استفاده غیربهینه
Scheduler افزایش زمان انتظار Threadها
GPU Utilization کاهش بهره‌وری واقعی

Random Access در چه کاربردهایی دیده می‌شود؟

نمونه کاربردهای دارای دسترسی تصادفی
کاربرد دلیل
Ray Tracing برخورد پرتوها با سطوح مختلف
پردازش Graph ارتباط نامنظم گره‌ها
دیتابیس GPU جستجوی آدرس‌های متنوع
هوش مصنوعی برخی عملیات Sparse Tensor
شبیه‌سازی دسترسی به ذرات پراکنده

Random Access در کارت‌های حرفه‌ای

کارت‌های Quadro، RTX Professional، Radeon Pro و
Arc Pro نیز از همین اصول پیروی می‌کنند.

تفاوت اصلی در ظرفیت Cache، سرعت VRAM،
پهنای باند حافظه و معماری کنترل‌کننده حافظه است.

حتی در کارت‌های حرفه‌ای، Random Access شدید
می‌تواند باعث کاهش محسوس راندمان شود.

نمونه کارت‌های حرفه‌ای
کارت گرافیک کاربرد رایج اهمیت مدیریت حافظه
Quadro P2000 CAD زیاد
RTX A2000 طراحی و AI بسیار زیاد
RTX 4000 Ada ورک‌استیشن بسیار زیاد
Radeon Pro W6600 طراحی صنعتی زیاد
Intel Arc Pro A40 Visualization زیاد

نمونه در GPUهای قدیمی

اثر Random Access در کارت‌های استوک
مدل معماری نتیجه
Quadro K2100M Kepler افت محسوس پهنای باند
Quadro M2000M Maxwell افزایش Cache Miss
GTX 970M Maxwell کاهش راندمان Compute
GTX 1060 Pascal افزایش زمان انتظار Threadها
Radeon RX580 Polaris افت کارایی حافظه

Gather Access چیست؟

Gather Access الگویی از دسترسی حافظه است که در آن
هر Thread داده‌های موردنیاز خود را از چندین آدرس
مختلف حافظه جمع‌آوری (Gather) می‌کند.

مقصد همه این داده‌ها یک Thread است، اما منابع
آن‌ها در نقاط مختلف حافظه قرار دارند.

این روش در پردازش تصویر، هوش مصنوعی، فیلترها،
Texture Sampling، دیتابیس و پردازش گراف بسیار
رایج است.

ساختار Gather Access

Memory

A1
A7
A21
A43

   │
   │
   ▼

Single Thread

Result

یک Thread اطلاعات خود را از چندین آدرس مختلف
جمع‌آوری کرده و نتیجه را تولید می‌کند.

کاربردهای Gather Access

کاربردهای متداول Gather
کاربرد نمونه استفاده میزان استفاده
Texture Sampling خواندن چند Pixel بسیار زیاد
Ray Tracing داده‌های پراکنده صحنه زیاد
هوش مصنوعی Sparse Tensor زیاد
پردازش تصویر فیلترهای همسایگی بسیار زیاد
Graph Processing خواندن گره‌های مختلف زیاد

اثر Gather بر عملکرد GPU

عملکرد Gather به فاصله آدرس‌ها، وضعیت Cache،
پهنای باند حافظه و نوع الگوریتم بستگی دارد.

اگر داده‌ها در Cache موجود باشند، هزینه Gather
بسیار کمتر خواهد بود.

عوامل مؤثر بر سرعت Gather
عامل اثر
Cache Hit افزایش سرعت
Cache Miss مراجعه به VRAM
فاصله آدرس‌ها افزایش Transaction
پهنای باند محدودکننده سرعت
Memory Latency افزایش زمان انتظار

نمونه در کارت‌های قدیمی

عملکرد Gather در نسل‌های مختلف GPU
کارت گرافیک وضعیت Gather
Quadro K2100M وابسته به Cache
Quadro K2200M مناسب برای CAD
Quadro M2000M بهتر از Maxwell قدیمی
GTX 970M عملکرد خوب در Texture
GTX 1060 Cache مؤثرتر
RTX A2000 بسیار مناسب

Scatter Access چیست؟

Scatter Access برعکس Gather Access است. در این
روش یک یا چند Thread نتایج محاسبات خود را در
آدرس‌های مختلف حافظه ذخیره می‌کنند.

مقصد داده‌ها معمولاً پراکنده است و ممکن است
هر Thread در موقعیت متفاوتی از حافظه عملیات
نوشتن (Write) را انجام دهد.

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

ساختار Scatter Access

One Thread

      │
      ▼

Write

 ├──► Address 5

 ├──► Address 19

 ├──► Address 81

 └──► Address 204

یک Thread نتیجه پردازش را در چندین آدرس
مختلف حافظه ذخیره می‌کند.

تفاوت Gather و Scatter

مقایسه Gather و Scatter
ویژگی Gather Scatter
عملیات اصلی خواندن نوشتن
مسیر داده چند آدرس → یک Thread یک Thread → چند آدرس
استفاده از Cache زیاد وابسته به معماری
احتمال برخورد کم زیاد
نیاز به Atomic معمولاً خیر گاهی ضروری

نقش Atomic Operation در Scatter

اگر چندین Thread هم‌زمان بخواهند روی یک آدرس
حافظه عملیات نوشتن انجام دهند، ممکن است داده‌ها
به‌درستی ذخیره نشوند.

برای جلوگیری از این مشکل، GPU از
Atomic Operation
استفاده می‌کند.

عملیات Atomic تضمین می‌کند که هر بار فقط یک
Thread بتواند مقدار آن آدرس را تغییر دهد.

کاربردهای Scatter Access

نمونه کاربردهای Scatter
نرم‌افزار یا کاربرد نمونه عملیات
Blender تولید بافرهای خروجی
Unreal Engine Compute Shader
CUDA Histogram
OpenCL Parallel Reduction
هوش مصنوعی بروزرسانی Weightها
شبیه‌سازی ثبت نتایج ذرات

Scatter در کارت‌های حرفه‌ای

Scatter Access در کارت‌های حرفه‌ای مانند
Quadro، RTX Ada، Radeon Pro و Intel Arc Pro
نیز اهمیت زیادی دارد.

هرچه Cache، حافظه اشتراکی (Shared Memory)
و پهنای باند VRAM قوی‌تر باشند، هزینه اجرای
Scatter کاهش پیدا می‌کند.

نمونه GPUهای مناسب Scatter
مدل کاربرد
Quadro P2000 CAD و Visualization
RTX A2000 AI و Render
RTX 4000 Ada Workstation
Radeon Pro W6600 طراحی صنعتی
Intel Arc Pro A40 پردازش گرافیکی

Cache-Friendly Access چیست؟

Cache-Friendly Access به الگویی از دسترسی حافظه
گفته می‌شود که احتمال پیداشدن داده در Cache را
افزایش می‌دهد و مراجعه مستقیم به VRAM را کاهش
می‌دهد.

اگر Threadها در مدت کوتاه چند بار از داده‌های نزدیک
یا یکسان استفاده کنند، Cache می‌تواند آن داده‌ها
را نگه دارد و درخواست‌های بعدی را سریع‌تر پاسخ دهد.

چیدمان منظم داده، پردازش بلوکی، استفاده مجدد از
اطلاعات و محدودکردن Working Set از مهم‌ترین اصول
طراحی دسترسی Cache-Friendly هستند.

Temporal Locality و Spatial Locality

بهره‌وری Cache تا حد زیادی به دو مفهوم
Temporal Locality
و
Spatial Locality
وابسته است.

مقایسه Temporal و Spatial Locality
نوع Locality مفهوم نمونه اثر بر Cache
Temporal Locality استفاده دوباره از همان داده در
فاصله زمانی کوتاه
خواندن چندباره یک Tile ماتریس افزایش احتمال Cache Hit
Spatial Locality استفاده از داده‌های نزدیک به
آدرس فعلی
پردازش عناصر متوالی آرایه استفاده بهتر از Cache Line

نمونه الگوی Cache-Friendly

Working Set چیست؟

Working Set مجموعه داده‌هایی است که یک Kernel،
Shader یا مرحله پردازشی در یک بازه کوتاه به‌طور
فعال استفاده می‌کند.

اگر Working Set داخل ظرفیت Cache جا شود، بخش
بزرگی از درخواست‌ها می‌توانند بدون مراجعه به
VRAM پاسخ داده شوند.

اگر Working Set بسیار بزرگ باشد، داده‌های مفید
مرتباً از Cache خارج می‌شوند و Cache Miss افزایش
پیدا می‌کند.

Cache Thrashing چیست؟

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

در این وضعیت داده قبل از استفاده مجدد از Cache
خارج می‌شود و سخت‌افزار مجبور است همان اطلاعات را
دوباره از سطح پایین‌تر حافظه دریافت کند.

Working Set بزرگ، دسترسی پراکنده و رقابت چند
Kernel یا واحد پردازشی برای Cache می‌توانند باعث
Thrashing شوند.

دلایل و پیامدهای Cache Thrashing
عامل اتفاق ایجادشده پیامد
Working Set بزرگ داده‌ها در Cache جا نمی‌شوند Cache Miss بیشتر
Random Access Cache Lineهای متعدد بارگذاری می‌شوند استفاده مجدد کمتر
چند جریان داده داده‌های یکدیگر را جایگزین می‌کنند کاهش Locality
Tile نامناسب اندازه بلوک از ظرفیت Cache بیشتر است مراجعه مکرر به VRAM

Tiling چگونه بهره‌وری Cache را افزایش می‌دهد؟

Tiling یعنی داده بزرگ به بلوک‌های کوچک‌تر تقسیم
شود تا هر بلوک در Cache یا Shared Memory جا بگیرد.

به‌جای پردازش یک ماتریس یا تصویر کامل، GPU ابتدا
یک Tile کوچک را بارگذاری می‌کند، چندین عملیات روی
آن انجام می‌دهد و سپس به Tile بعدی می‌رود.

این روش استفاده مجدد از داده را افزایش و حجم
انتقال میان VRAM و واحدهای پردازشی را کاهش می‌دهد.

ترتیب حلقه‌ها و دسترسی به حافظه

ترتیب اجرای حلقه‌ها می‌تواند تعیین کند داده‌ها
به‌صورت متوالی یا با Stride بزرگ خوانده شوند.

در ماتریس Row-Major، پردازش عناصر هر سطر معمولاً
Locality بهتری از پردازش ستونی دارد.

تغییر ترتیب حلقه‌ها یا استفاده از Transpose می‌تواند
الگوی دسترسی را Cache-Friendlyتر کند.

اثر ترتیب پردازش ماتریس
روش الگوی حافظه بهره‌وری Cache
پردازش سطری آدرس‌های متوالی معمولاً بالا
پردازش ستونی Stride برابر عرض سطر معمولاً کمتر
پردازش Tile-Based بلوک‌های کوچک محلی بسیار مناسب
Transpose اولیه تبدیل دسترسی ستونی به متوالی وابسته به هزینه Transpose

Data Reuse چیست؟

Data Reuse یعنی داده‌ای که یک‌بار از حافظه خوانده
شده است، پیش از خارج‌شدن از Cache یا Shared Memory
چندین بار استفاده شود.

ضرب ماتریسی، Convolution، فیلتر تصویر و محاسبات
همسایگی نمونه‌هایی هستند که می‌توانند از استفاده
مجدد گسترده داده بهره ببرند.

نمونه‌های استفاده مجدد از داده
کاربرد داده قابل استفاده مجدد محل نگهداری مناسب
Matrix Multiply Tileهای ماتریس A و B Shared Memory و Cache
Convolution پیکسل‌های مشترک پنجره‌های مجاور L1 و Shared Memory
Texture Sampling Texelهای نزدیک Texture Cache
Ray Tracing بخش‌هایی از BVH و Material Cacheهای داخلی GPU
AI Inference Weightهای یک لایه Cache و Shared Memory

چیدمان داده مناسب Cache

محل قرارگیری فیلدها، اندازه ساختارها و ترتیب
آرایه‌ها می‌تواند تعیین کند چه مقدار داده مفید
داخل هر Cache Line قرار بگیرد.

اگر یک Kernel فقط یک ویژگی از مجموعه اشیا را
پردازش کند، Structure of Arrays معمولاً Locality
بهتری نسبت به Array of Structures ایجاد می‌کند.

اگر تمام ویژگی‌های هر شیء هم‌زمان استفاده شوند،
Array of Structures نیز ممکن است انتخاب مناسبی
باشد.

اهمیت Cache-Friendly Access در کاربردهای مختلف

اهمیت Locality و Cache در بارهای کاری GPU
کاربرد داده اصلی روش بهینه‌سازی اهمیت
بازی Texture، Vertex و Buffer مرتب‌سازی و Locality فضایی زیاد
Blender Mesh، Texture و BVH Tiling و Data Reuse بسیار زیاد
SolidWorks Geometry و Viewport Buffer Batch و چیدمان منظم زیاد
هوش مصنوعی Weight، Tensor و Activation Tiling و Fusion بسیار زیاد
ویرایش ویدئو فریم و Buffer پردازش بلوکی زیاد
Ray Tracing BVH، Geometry و Material گروه‌بندی پرتوهای مشابه بسیار زیاد

Cache-Friendly Access در کارت‌های قدیمی و حرفه‌ای

در GPUهای قدیمی که Cache کوچک‌تر و پهنای باند
محدودتری دارند، طراحی Cache-Friendly اهمیت بیشتری
پیدا می‌کند.

مدل‌هایی مانند Quadro K2100M، Quadro K2200M،
Quadro M2000M، GTX 960M و GTX 970M در برابر
Working Set بزرگ یا Random Access زودتر با گلوگاه
حافظه مواجه می‌شوند.

کارت‌های جدیدتر مانند RTX A2000، RTX 4000 Ada،
Radeon Pro و Intel Arc Pro Cache و سیستم حافظه
پیشرفته‌تری دارند، اما همچنان از Locality مناسب
سود می‌برند.

اهمیت بهینه‌سازی Cache در چند نسل GPU
خانواده محدودیت رایج اهمیت Cache-Friendly Access
Quadro K Series Cache و VRAM محدودتر بسیار زیاد
Quadro M Series ظرفیت محدود در لپ‌تاپ‌های قدیمی بسیار زیاد
Quadro P Series نبود Cacheهای بزرگ نسل جدید زیاد
RTX Professional Working Set سنگین رندر و AI بسیار زیاد
Radeon Pro وابستگی به معماری و Infinity Cache زیاد
Intel Arc Pro وابستگی به چیدمان داده و درایور زیاد

چک‌لیست طراحی دسترسی Cache-Friendly

موارد مهم برای افزایش بهره‌وری Cache
بررسی هدف
داده‌های مجاور با هم پردازش شوند افزایش Spatial Locality
داده خوانده‌شده دوباره استفاده شود افزایش Temporal Locality
Working Set کوچک نگه داشته شود جلوگیری از Cache Thrashing
پردازش به Tile تقسیم شود جاگیری بهتر در Cache
چیدمان AoS و SoA مقایسه شود کاهش داده بلااستفاده
Random Access کاهش یابد کاهش Cache Miss
ابزار Profiling استفاده شود شناسایی گلوگاه واقعی

مقایسه کامل الگوهای دسترسی به حافظه GPU

هیچ الگوی دسترسی حافظه‌ای برای تمام الگوریتم‌ها
بهترین نیست. کارایی هر روش به چیدمان داده، نوع
پردازش، معماری GPU، اندازه Cache و میزان استفاده
مجدد از اطلاعات بستگی دارد.

بااین‌حال، دسترسی‌های منظم و مجاور معمولاً پهنای
باند مؤثرتری ایجاد می‌کنند و دسترسی‌های پراکنده
فشار بیشتری بر Cache و VRAM وارد می‌کنند.

مقایسه کلی الگوهای دسترسی حافظه در GPU
الگوی دسترسی ساختار آدرس‌ها تعداد تراکنش بهره‌وری Cache کارایی معمول
Coalesced منظم و مجاور کم زیاد بسیار عالی
Uncoalesced پراکنده یا نامرتب زیاد کمتر ضعیف‌تر
Strided فاصله ثابت میان آدرس‌ها وابسته به Stride متوسط تا ضعیف وابسته به فاصله
Random غیرقابل پیش‌بینی معمولاً زیاد معمولاً ضعیف پایین‌تر
Gather خواندن از چند آدرس وابسته به پراکندگی وابسته به Locality متوسط
Scatter نوشتن در چند آدرس وابسته به پراکندگی وابسته به معماری متوسط تا ضعیف
Cache-Friendly نزدیک و دارای استفاده مجدد کاهش مراجعه به VRAM بسیار زیاد بسیار عالی

انتخاب الگوی مناسب برای هر نوع پردازش

الگوهای مناسب برای کاربردهای مختلف
نوع پردازش الگوی مطلوب الگوی اجتناب‌پذیر راهکار اصلی
پردازش آرایه Coalesced و Sequential Random نگاشت هر Thread به عنصر مجاور
پردازش تصویر Tile-Based و Cache-Friendly Gather پراکنده بارگذاری ناحیه محلی در Shared Memory
ضرب ماتریسی Coalesced و Tiled Stride بزرگ Transpose یا بازچینی داده
پردازش گراف Gather گروه‌بندی‌شده Random کاملاً پراکنده مرتب‌سازی گره‌ها و یال‌ها
Ray Tracing گروه‌بندی پرتوهای مشابه دسترسی کاملاً واگرا افزایش Coherence پرتوها
هوش مصنوعی Tiled، Coalesced و Data Reuse Tensor نامتراکم بدون ساختار Layout مناسب و Kernel Fusion
Histogram Scatter محلی Atomic مشترک سراسری شمارنده محلی و ادغام نهایی

روش‌های بهینه‌سازی دسترسی به حافظه GPU

هدف بهینه‌سازی حافظه این است که مقدار داده مفید
منتقل‌شده افزایش پیدا کند، تعداد تراکنش‌های اضافی
کاهش یابد و Threadها مدت کمتری منتظر حافظه بمانند.

مهم‌ترین روش‌های بهینه‌سازی Memory Access
روش هدف مزیت خطر یا محدودیت
Coalescing ترکیب درخواست‌های مجاور تراکنش کمتر نیازمند چیدمان مناسب داده
Memory Alignment قرارگیری داده روی مرز مناسب جلوگیری از انتقال چندبخشی ممکن است Padding افزایش یابد
Tiling کوچک‌کردن Working Set استفاده مجدد از داده پیچیدگی بیشتر Kernel
Shared Memory کاهش دسترسی تکراری به VRAM تأخیر کمتر محدودیت ظرفیت و Bank Conflict
Structure of Arrays کنار هم قراردادن ویژگی‌های مشابه Coalescing بهتر دسترسی کامل به هر شیء پیچیده‌تر می‌شود
Data Reordering نزدیک‌کردن داده‌های مرتبط Locality بیشتر هزینه مرتب‌سازی
Kernel Fusion کاهش نوشتن و خواندن میانی انتقال حافظه کمتر مصرف Register بیشتر
Prefetching آماده‌سازی زودهنگام داده پنهان‌کردن تأخیر Prefetch اشتباه پهنای باند مصرف می‌کند
Compression کاهش حجم انتقال پهنای باند مؤثر بیشتر همه داده‌ها قابل فشرده‌سازی نیستند

فرایند مرحله‌به‌مرحله بهینه‌سازی حافظه


مرحله ۱


شناسایی گلوگاه

مشخص شود Kernel واقعاً Memory-Bound است
یا محدودیت اصلی از بخش دیگری ایجاد می‌شود.


مرحله ۲


بررسی الگوی آدرس

آدرس‌های خوانده‌شده توسط Threadهای یک
Warp یا Wavefront تحلیل شوند.


مرحله ۳


اندازه‌گیری Cache

نرخ Cache Hit، Cache Miss و میزان مراجعه
به VRAM بررسی شود.


مرحله ۴


اصلاح Data Layout

AoS، SoA، Alignment، Padding و ترتیب
عناصر مقایسه شوند.


مرحله ۵


استفاده از حافظه نزدیک‌تر

داده‌های پرتکرار در Register، Cache یا
Shared Memory نگهداری شوند.


مرحله ۶


آزمون مجدد

تغییرات با ابزار Profiling و روی سخت‌افزار
هدف اندازه‌گیری شوند.

معیارهای مهم در بررسی عملکرد حافظه

معیارهای مفید برای تحلیل Memory Access
معیار چه چیزی را نشان می‌دهد؟ نشانه احتمالی مشکل
Memory Throughput حجم انتقال واقعی داده فاصله زیاد با ظرفیت سخت‌افزار
Cache Hit Rate درصد درخواست‌های پاسخ‌داده‌شده از Cache نرخ بسیار پایین
Memory Transactions تعداد انتقال‌های موردنیاز تراکنش زیاد برای داده کم
Global Load Efficiency نسبت داده مفید به داده منتقل‌شده هدررفت پهنای باند
Global Store Efficiency بهره‌وری عملیات نوشتن Scatter پراکنده
Memory Stall زمان انتظار Warpها برای داده تأخیر یا پهنای باند ناکافی
Atomic Contention میزان رقابت روی آدرس مشترک Serialization زیاد
Shared Memory Bank Conflict تداخل دسترسی به Bankها دسترسی ترتیبی ناخواسته

هزینه‌ها و مصالحه‌های بهینه‌سازی حافظه

بهینه‌سازی یک بخش ممکن است فشار بیشتری به منبع
دیگری وارد کند. برای مثال، Kernel Fusion انتقال
حافظه را کاهش می‌دهد، اما ممکن است مصرف Register
را افزایش دهد.

نمونه مصالحه‌ها در بهینه‌سازی Memory Access
تغییر مزیت هزینه احتمالی
استفاده بیشتر از Shared Memory کاهش مراجعه به VRAM کاهش Occupancy
Kernel Fusion حذف Buffer میانی Register Pressure بیشتر
Padding Alignment و Bank Conflict بهتر مصرف حافظه بیشتر
Data Reordering Locality بهتر هزینه پیش‌پردازش
Prefetching کاهش زمان انتظار مصرف پهنای باند و Cache
Tile بزرگ‌تر Data Reuse بیشتر مصرف Shared Memory بیشتر

بهترین روش‌ها برای طراحی دسترسی حافظه در GPU

در پروژه‌های حرفه‌ای، افزایش تعداد هسته‌های پردازشی یا
فرکانس GPU همیشه باعث افزایش سرعت برنامه نمی‌شود.
در بسیاری از موارد، نحوه دسترسی به حافظه مهم‌ترین عامل
تعیین‌کننده عملکرد نهایی است.

برنامه‌نویسان CUDA، OpenCL، Vulkan Compute و DirectX Compute
معمولاً پیش از هرگونه بهینه‌سازی پردازشی، الگوی دسترسی
حافظه را بررسی می‌کنند.

مهم‌ترین توصیه‌های مهندسی

بهترین روش‌های بهینه‌سازی Memory Access
توصیه دلیل نتیجه
استفاده از Coalesced Access کاهش تعداد Memory Transaction افزایش پهنای باند مؤثر
کوچک نگه داشتن Working Set جلوگیری از Cache Thrashing افزایش Cache Hit
استفاده از Tiling افزایش استفاده مجدد از داده کاهش مراجعه به VRAM
استفاده از Shared Memory کاهش تأخیر حافظه اجرای سریع‌تر Kernel
کاهش Random Access افزایش Locality افزایش کارایی Cache
استفاده از Profiler یافتن گلوگاه واقعی جلوگیری از بهینه‌سازی اشتباه

سؤالات متداول درباره دسترسی به حافظه GPU

Memory Access در GPU چیست؟

Memory Access به فرایند خواندن داده از
Register، Shared Memory، Cache، VRAM یا
حافظه سیستم و همچنین نوشتن نتیجه در این
حافظه‌ها گفته می‌شود.

چرا الگوی دسترسی حافظه بر سرعت GPU اثر دارد؟

زیرا Threadهای GPU به‌صورت گروهی اجرا
می‌شوند. اگر آدرس‌های موردنیاز آن‌ها نزدیک
و منظم باشند، سخت‌افزار می‌تواند درخواست‌ها
را با تراکنش‌های کمتری انجام دهد.

Coalesced Memory Access چیست؟

حالتی است که Threadهای مجاور یک Warp،
Wavefront یا Subgroup به آدرس‌های مجاور و
منظم حافظه دسترسی دارند و درخواست‌های آن‌ها
در تعداد کمی تراکنش ترکیب می‌شود.

آیا Coalesced Access همیشه سریع‌ترین روش است؟

برای انتقال آرایه‌ها و داده‌های منظم معمولاً
بسیار مؤثر است؛ اما عملکرد نهایی به Cache،
نوع داده، Alignment، معماری GPU و الگوریتم
نیز بستگی دارد.

Uncoalesced Access چیست؟

زمانی رخ می‌دهد که Threadهای یک گروه به
آدرس‌های پراکنده، نامرتب یا دور از یکدیگر
دسترسی داشته باشند و سخت‌افزار مجبور به
انجام تراکنش‌های بیشتری شود.

Strided Access چیست؟

الگویی است که در آن Threadهای متوالی به
آدرس‌هایی با فاصله ثابت دسترسی دارند. این
فاصله Stride نامیده می‌شود و افزایش آن
می‌تواند کارایی حافظه را کاهش دهد.

آیا Stride برابر یک مناسب است؟

معمولاً بله. Stride برابر یک یعنی عناصر
متوالی خوانده یا نوشته می‌شوند و در بسیاری
از موارد شرایط مناسبی برای Coalescing ایجاد
می‌شود.

Random Access چه مشکلی برای GPU ایجاد می‌کند؟

دسترسی تصادفی می‌تواند تعداد تراکنش‌های
حافظه و Cache Miss را افزایش دهد و باعث
انتظار بیشتر Warpها برای دریافت داده شود.

آیا Random Access همیشه قابل حذف است؟

خیر. الگوریتم‌هایی مانند پردازش گراف،
Ray Tracing، جست‌وجوی درختی و Sparse
Computing ذاتاً دارای دسترسی‌های نامنظم
هستند؛ اما می‌توان داده‌ها را گروه‌بندی یا
مرتب کرد تا Locality افزایش یابد.

تفاوت Gather و Scatter چیست؟

Gather معمولاً داده را از چند آدرس مختلف
می‌خواند و برای یک محاسبه جمع‌آوری می‌کند؛
Scatter نتیجه را در چند آدرس مختلف حافظه
می‌نویسد.

چرا Scatter ممکن است به Atomic Operation نیاز داشته باشد؟

اگر چند Thread هم‌زمان بخواهند یک آدرس
مشترک را تغییر دهند، ممکن است بخشی از
به‌روزرسانی‌ها از بین برود. عملیات Atomic
دسترسی به آن مقدار مشترک را کنترل می‌کند.

Atomic Operation چه اثری بر عملکرد دارد؟

Atomic برای صحت داده ضروری است، اما اگر
Threadهای زیادی روی یک آدرس مشترک رقابت
کنند، عملیات ممکن است به‌صورت ترتیبی انجام
شود و سرعت کاهش یابد.

Memory Alignment چیست؟

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

Padding چیست و چرا استفاده می‌شود؟

Padding فضای خالی کنترل‌شده‌ای است که میان
فیلدها یا ردیف‌های داده قرار می‌گیرد تا
Alignment بهتر شود یا از بعضی Bank Conflictها
جلوگیری شود.

آیا Padding باعث افزایش مصرف حافظه می‌شود؟

بله. Padding مقداری فضای اضافه مصرف می‌کند؛
اما اگر باعث کاهش تراکنش حافظه یا جلوگیری
از تداخل شود، این افزایش ظرفیت می‌تواند
ارزشمند باشد.

Cache-Friendly Access چیست؟

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

Temporal Locality چیست؟

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

Spatial Locality چیست؟

یعنی پس از دسترسی به یک آدرس، داده‌های
نزدیک به همان آدرس نیز به‌زودی موردنیاز
باشند.

Working Set چیست؟

Working Set مجموعه داده‌هایی است که یک
Kernel یا Shader در یک بازه کوتاه به‌طور
فعال استفاده می‌کند. کوچک‌بودن آن می‌تواند
احتمال جاگیری داده‌ها در Cache را افزایش دهد.

Cache Thrashing چیست؟

زمانی رخ می‌دهد که داده‌ها پیش از استفاده
مجدد، مرتباً از Cache خارج و با داده‌های
دیگر جایگزین شوند. این وضعیت باعث Cache
Miss و مراجعه مکرر به VRAM می‌شود.

Tiling چگونه سرعت دسترسی حافظه را افزایش می‌دهد؟

Tiling داده بزرگ را به بخش‌های کوچک‌تر
تقسیم می‌کند تا هر بخش در Cache یا Shared
Memory قرار بگیرد و چندین بار استفاده شود.

تفاوت Array of Structures و Structure of Arrays چیست؟

در Array of Structures تمام ویژگی‌های هر
شیء کنار هم قرار می‌گیرند؛ در Structure of
Arrays هر ویژگی در آرایه‌ای مستقل ذخیره
می‌شود. SoA برای پردازش گروهی یک ویژگی
معمولاً Coalescing بهتری ایجاد می‌کند.

آیا Shared Memory همیشه باعث افزایش سرعت می‌شود؟

خیر. Shared Memory زمانی مفید است که داده
چندین بار استفاده شود. مصرف بیش‌ازحد آن
می‌تواند Occupancy را کاهش دهد و چیدمان
نامناسب نیز Bank Conflict ایجاد کند.

Memory-Bound بودن برنامه یعنی چه؟

یعنی سرعت برنامه بیشتر توسط تأخیر یا
پهنای باند حافظه محدود شده است، نه توان
واحدهای محاسباتی GPU.

چگونه بفهمیم Kernel به حافظه محدود شده است؟

باید با ابزارهای Profiling معیارهایی مانند
Memory Throughput، Cache Hit Rate، تعداد
تراکنش‌ها، Load Efficiency و زمان انتظار
Warpها بررسی شوند.

آیا VRAM بیشتر مشکل Memory Access را حل می‌کند؟

خیر. ظرفیت بیشتر کمک می‌کند داده‌های بزرگ‌تر
روی کارت قرار بگیرند، اما الگوی دسترسی
نامناسب، Cache Miss و تراکنش‌های اضافی را
به‌تنهایی برطرف نمی‌کند.

آیا پهنای باند بالاتر همیشه عملکرد بیشتری ایجاد می‌کند؟

نه لزوماً. اگر برنامه Compute-Bound باشد
یا داده‌ها به‌صورت نامناسب و پراکنده خوانده
شوند، افزایش پهنای باند خام ممکن است تأثیر
محدودی داشته باشد.

آیا کارت‌های Quadro قدیمی از Coalescing استفاده می‌کنند؟

بله. GPUهای قدیمی NVIDIA مانند Quadroهای
مبتنی بر Kepler، Maxwell و Pascal نیز از
اجرای Warp و ترکیب درخواست‌های حافظه بهره
می‌برند؛ هرچند جزئیات معماری آن‌ها متفاوت
است.

برای Blender ظرفیت VRAM مهم‌تر است یا الگوی دسترسی حافظه؟

هر دو مهم‌اند. VRAM کافی برای جاگیری صحنه
ضروری است و الگوی دسترسی مناسب نیز مشخص
می‌کند داده‌ها با چه بهره‌وری در اختیار
واحدهای پردازشی قرار بگیرند.

برای هوش مصنوعی چرا Data Layout اهمیت دارد؟

زیرا Tensorها و ماتریس‌ها باید با قالبی
ذخیره شوند که واحدهای محاسباتی و ماتریسی
بتوانند داده را با تراکنش‌های منظم و استفاده
مجدد بالا دریافت کنند.


فصل فرکانس، توان و مصرف انرژی GPU

فرکانس GPU، توان مصرفی، ولتاژ، TGP، TDP و مدیریت انرژی

عملکرد واقعی پردازنده گرافیکی فقط به تعداد هسته‌ها
یا معماری آن وابسته نیست. فرکانس هسته و حافظه،
ولتاژ، محدودیت توان، دما، سیستم خنک‌کننده و تنظیمات
سازنده تعیین می‌کنند GPU در عمل با چه سرعتی کار کند.

فهرست فصل فرکانس، توان و مصرف انرژی GPU
بخش عنوان موضوع اصلی سطح مطالعه
۱
فرکانس GPU چیست؟
مفهوم Clock و سیکل کاری پردازنده گرافیکی
مقدماتی
۲
Base Clock چیست؟
فرکانس پایه و شرایط تضمین‌شده کاری
مقدماتی
۳
Boost Clock چیست؟
افزایش پویا و خودکار فرکانس GPU
مقدماتی
۴
Clock Domainهای مختلف GPU
فرکانس هسته، Shader، حافظه و موتورهای رسانه
متوسط
۵
فرکانس حافظه و نرخ مؤثر انتقال
تفاوت Clock واقعی، Effective Clock و Gbps
متوسط
۶
ولتاژ GPU چیست؟
ارتباط ولتاژ با فرکانس، توان و پایداری
متوسط
۷
منحنی ولتاژ و فرکانس
رفتار پویا در نقاط مختلف Voltage/Frequency
پیشرفته
۸
توان مصرفی GPU
مصرف انرژی هسته، حافظه و اجزای جانبی
مقدماتی
۹
تفاوت TDP، TGP و TBP
اصطلاحات توان در NVIDIA، AMD و سازندگان سیستم
متوسط
۱۰
Power Limit چیست؟
سقف توان و اثر آن بر Boost Clock
متوسط
۱۱
Power Throttling چیست؟
کاهش فرکانس هنگام رسیدن به محدودیت توان
متوسط
۱۲
Thermal Throttling چیست؟
کاهش سرعت برای کنترل دما
مقدماتی
۱۳
حسگرهای دمای GPU
Core Temperature، Hotspot و Memory Junction
متوسط
۱۴
تأثیر سیستم خنک‌کننده
رابطه دما، Boost، نویز و پایداری
مقدماتی
۱۵
محدودیت توان GPUهای لپ‌تاپی
تفاوت توان یک مدل مشابه در لپ‌تاپ‌های مختلف
متوسط
۱۶
NVIDIA Dynamic Boost
تقسیم پویا توان میان CPU و GPU لپ‌تاپ
متوسط
۱۷
Performance State یا P-State
حالت‌های مختلف فرکانس و مصرف انرژی
پیشرفته
۱۸
مصرف انرژی در حالت Idle
کاهش فرکانس و خاموش‌کردن بخش‌های بلااستفاده
مقدماتی
۱۹
اورکلاک GPU
افزایش فرکانس هسته و حافظه
پیشرفته
۲۰
Undervolting چیست؟
کاهش ولتاژ برای کنترل توان و دما
پیشرفته
۲۱
بهره‌وری انرژی GPU
عملکرد به‌ازای وات و مقایسه نسل‌ها
متوسط
۲۲
توان در Quadro و کارت‌های حرفه‌ای
پایداری، محدودیت توان و بارهای کاری طولانی
متوسط
۲۳
نمونه در GPUهای قدیمی
Quadro K، M، P و GTXهای قدیمی
متوسط
۲۴
اهمیت توان هنگام خرید
بررسی آداپتور، باتری، خنک‌کننده و عملکرد
مقدماتی
۲۵
اشتباهات رایج
خطاهای متداول در مقایسه فرکانس و توان
مقدماتی
۲۶
خلاصه فصل
مرور نکات اصلی فرکانس و مصرف انرژی
مقدماتی
۲۷
سؤالات متداول
پاسخ به پرسش‌های رایج کاربران
مقدماتی

فرکانس GPU چیست؟

فرکانس GPU نشان می‌دهد بخش‌های مختلف پردازنده
گرافیکی در هر ثانیه چند چرخه کاری اجرا می‌کنند.
این مقدار معمولاً با واحد مگاهرتز یا گیگاهرتز
نمایش داده می‌شود.

برای مثال، فرکانس ۱۵۰۰ مگاهرتز به این معنی است که
مدار مربوطه در شرایط مشخص می‌تواند حدود یک‌ونیم
میلیارد چرخه در ثانیه داشته باشد.

بااین‌حال، هر چرخه لزوماً معادل یک عملیات کامل
نیست. تعداد دستورهای اجراشده در هر چرخه به معماری،
نوع واحد پردازشی، پهنای اجرا، Scheduler و نوع
دستور وابسته است.

آیا فرکانس بیشتر همیشه به معنی GPU سریع‌تر است؟

خیر. دو GPU با فرکانس یکسان می‌توانند عملکرد کاملاً
متفاوتی داشته باشند؛ زیرا تعداد هسته‌ها، معماری،
Cache، پهنای باند حافظه، واحدهای اختصاصی و توان
مصرفی آن‌ها متفاوت است.

حتی در یک معماری مشابه نیز افزایش فرکانس زمانی
مفید است که محدودیت دما، توان یا پهنای باند حافظه
مانع استفاده کامل از آن نشود.

عواملی که همراه با فرکانس بر عملکرد GPU اثر دارند
عامل نقش اثر احتمالی
معماری تعیین توان انجام کار در هر چرخه اختلاف عملکرد حتی در Clock یکسان
تعداد هسته‌ها تعیین میزان پردازش موازی توان عملیاتی بیشتر
پهنای باند حافظه تأمین داده برای واحدهای پردازشی جلوگیری از گلوگاه حافظه
Power Limit محدودکردن توان مصرفی کاهش یا حفظ Boost Clock
دما تعیین فضای حرارتی برای Boost احتمال Thermal Throttling
نوع بار کاری تعیین واحدهای فعال GPU رفتار فرکانسی متفاوت

Base Clock چیست؟

Base Clock فرکانس پایه‌ای است که سازنده برای یک
GPU در شرایط تعریف‌شده اعلام می‌کند.

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

GPUهای جدید دائماً فرکانس خود را بر اساس دما،
ولتاژ، Power Limit، نوع بار کاری و ظرفیت سیستم
خنک‌کننده تغییر می‌دهند.

Boost Clock چیست؟

Boost Clock فرکانسی است که GPU در صورت مناسب‌بودن
شرایط توان، دما و ولتاژ می‌تواند به‌صورت خودکار
به آن برسد یا حتی در بعضی لحظات از آن عبور کند.

سیستم مدیریت فرکانس به‌طور پیوسته حسگرهای مختلف را
بررسی می‌کند و بالاترین نقطه پایدار و مجاز را
انتخاب می‌کند.

به همین دلیل دو کارت دارای GPU یکسان ممکن است به
علت تفاوت خنک‌کننده، BIOS، Power Limit یا طراحی
برد، فرکانس واقعی متفاوتی داشته باشند.

تفاوت Base Clock و Boost Clock

مقایسه فرکانس پایه و فرکانس بوست GPU
معیار Base Clock Boost Clock
مفهوم فرکانس مرجع پایه فرکانس افزایش‌یافته پویا
ثابت‌بودن در عمل ثابت نیست کاملاً وابسته به شرایط
وابستگی به دما کمتر بسیار زیاد
وابستگی به Power Limit محدود مستقیم
کاربرد در مقایسه مرجع اولیه مشخصات تخمین بهتر عملکرد لحظه‌ای
عملکرد طولانی‌مدت به‌تنهایی تعیین‌کننده نیست به خنک‌کننده و توان وابسته است

Sustained Clock یا فرکانس پایدار چیست؟

Sustained Clock فرکانسی است که GPU می‌تواند در یک
بار کاری طولانی‌مدت بدون افت شدید حفظ کند.

این مقدار معمولاً برای ارزیابی رندر طولانی،
شبیه‌سازی، هوش مصنوعی و بازی ممتد از Boost لحظه‌ای
مهم‌تر است.

لپ‌تاپی که در چند ثانیه اول فرکانس بالایی نشان
می‌دهد، ممکن است پس از گرم‌شدن به فرکانس بسیار
پایین‌تری برسد.

Effective Clock در هسته GPU چیست؟

بعضی ابزارها علاوه بر Clock گزارش‌شده، مقدار
Effective Clock را نیز نمایش می‌دهند.

Clock گزارش‌شده ممکن است نقطه فرکانسی انتخاب‌شده
توسط کنترل‌کننده باشد؛ اما Effective Clock نشان
می‌دهد هسته در عمل چه مقدار از زمان با آن نرخ
مشغول اجرای مفید بوده است.

توقف واحدها، محدودیت توان، Clock Gating، انتظار
برای حافظه و بار کاری ناقص می‌توانند باعث تفاوت
میان Clock اعلام‌شده و Clock مؤثر شوند.

تفاوت Clock گزارش‌شده و Effective Clock
معیار Clock گزارش‌شده Effective Clock
مفهوم نقطه فرکانسی انتخاب‌شده نرخ مؤثر فعالیت واقعی
اثر Idle Cycle ممکن است نشان داده نشود در مقدار نهایی منعکس می‌شود
کاربرد بررسی رفتار Boost تحلیل استفاده واقعی از فرکانس

Clock Domainهای مختلف در GPU

تمام اجزای GPU الزاماً با یک فرکانس واحد کار
نمی‌کنند. معماری می‌تواند چند Clock Domain مستقل
داشته باشد که هرکدام بر اساس نیاز خود تنظیم شوند.

جداشدن Domainها کمک می‌کند بخش‌های بلااستفاده با
فرکانس پایین‌تر کار کنند و مصرف انرژی کاهش یابد.

نمونه Clock Domainهای رایج در پردازنده گرافیکی
Clock Domain بخش تحت‌تأثیر کاربرد
Core Clock بخش اصلی GPU Shader، Compute و Raster
Shader Clock واحدهای Shader در برخی نسل‌های قدیمی اجرای دستورهای محاسباتی
Memory Clock VRAM و رابط حافظه انتقال داده
Fabric یا Interconnect Clock ارتباط داخلی بخش‌های GPU جابه‌جایی داده میان بلوک‌ها
Video Engine Clock موتور Encode و Decode پردازش ویدئو
Display Clock موتور نمایشگر خروجی تصویر و مدیریت مانیتور

Shader Clock در GPUهای قدیمی

در بعضی نسل‌های قدیمی NVIDIA، فرکانس واحدهای
Shader با Core Clock یکسان نبود و با ضریب بالاتری
کار می‌کرد.

در معماری‌های جدیدتر، ساختار Clock Domainها تغییر
کرده و مقایسه مستقیم Shader Clock قدیمی با Core
Clock نسل‌های جدید معتبر نیست.

فرکانس حافظه (Memory Clock) چیست؟

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

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

البته سرعت واقعی انتقال داده فقط به فرکانس حافظه
وابسته نیست و نوع حافظه، فناوری انتقال و عرض باس
نیز نقش مهمی دارند.

تفاوت فرکانس واقعی و Effective Memory Clock

در بسیاری از حافظه‌های گرافیکی مانند GDDR5،
GDDR6 و GDDR6X عددی که در مشخصات مشاهده می‌شود
معمولاً نرخ مؤثر انتقال داده است، نه فرکانس واقعی
نوسان مدار حافظه.

تفاوت Clock واقعی و Effective Clock حافظه
ویژگی Clock واقعی Effective Clock
مفهوم فرکانس فیزیکی حافظه نرخ مؤثر انتقال داده
کاربرد طراحی سخت‌افزار محاسبه پهنای باند
عدد درج‌شده در تبلیغات معمولاً خیر معمولاً بله

رفتار فرکانس در انواع حافظه

مقایسه فناوری‌های مختلف حافظه گرافیکی
نوع حافظه نرخ انتقال کاربرد رایج
GDDR5 تا حدود 8Gbps کارت‌های قدیمی
GDDR6 12 تا 20Gbps اغلب GPUهای جدید
GDDR6X تا بیش از 24Gbps کارت‌های رده‌بالا
HBM2 و HBM3 بسیار بالا شتاب‌دهنده‌های حرفه‌ای

رابطه Memory Clock و پهنای باند

افزایش Memory Clock معمولاً باعث افزایش پهنای
باند حافظه می‌شود، اما فقط زمانی که عرض باس
تغییر نکند.

به همین دلیل ممکن است یک کارت دارای Memory Clock
بالاتر، به علت باس باریک‌تر، پهنای باند کمتری
نسبت به کارت دیگر داشته باشد.

Memory Clock
       │
       ▼

Transfer Rate
       │
       ▼

Memory Bus Width
       │
       ▼

Memory Bandwidth

نمونه‌هایی از فرکانس حافظه در GPUهای مختلف

نمونه فرکانس حافظه چند کارت گرافیک
مدل نوع حافظه نرخ مؤثر
Quadro K2200 GDDR5 حدود 5Gbps
Quadro P2000 GDDR5 حدود 7Gbps
RTX A2000 GDDR6 حدود 12Gbps
RTX 4090 GDDR6X حدود 21Gbps
H100 HBM3 بسیار بالا

ولتاژ GPU چیست؟

ولتاژ (Voltage) نیروی الکتریکی موردنیاز برای
عملکرد ترانزیستورهای پردازنده گرافیکی را فراهم
می‌کند. بدون ولتاژ کافی، مدارها نمی‌توانند
تغییر وضعیت داده و محاسبات را انجام دهند.

هرچه فرکانس GPU افزایش پیدا کند، معمولاً برای
حفظ پایداری مدار به ولتاژ بیشتری نیاز خواهد بود.
البته این رابطه کاملاً خطی نیست و به معماری،
فرآیند ساخت و کیفیت تراشه بستگی دارد.

ارتباط ولتاژ و فرکانس

برای اجرای پایدار در فرکانس‌های بالاتر، معمولاً
باید ولتاژ نیز افزایش یابد تا ترانزیستورها بتوانند
سریع‌تر تغییر وضعیت دهند.

اگر ولتاژ کمتر از مقدار لازم باشد، ممکن است GPU
دچار خطای محاسباتی، Crash، ریست درایور یا ناپایداری
شود.

Higher Clock
      │
      ▼
Needs Higher Voltage
      │
      ▼
Higher Power
      │
      ▼
Higher Temperature

منحنی Voltage/Frequency

GPUهای مدرن تنها یک مقدار ولتاژ یا یک فرکانس
ثابت ندارند، بلکه از یک منحنی ولتاژ-فرکانس
(Voltage/Frequency Curve) استفاده می‌کنند.

کنترل‌کننده داخلی GPU با توجه به بار کاری،
دما، توان و کیفیت تراشه، مناسب‌ترین نقطه این
منحنی را انتخاب می‌کند.

رفتار تقریبی منحنی ولتاژ و فرکانس
ولتاژ فرکانس قابل دستیابی مصرف انرژی
پایین پایین کم
متوسط متوسط متوسط
بالا زیاد زیاد

تنظیم پویای ولتاژ

GPUهای امروزی به‌صورت مداوم ولتاژ خود را تغییر
می‌دهند. هنگام اجرای کارهای سبک، ولتاژ کاهش پیدا
می‌کند و هنگام پردازش‌های سنگین دوباره افزایش
می‌یابد.

این فناوری با نام‌هایی مانند Dynamic Voltage،
DVFS یا Adaptive Voltage شناخته می‌شود.

هدف اصلی این سیستم کاهش مصرف انرژی، کنترل دما
و افزایش عمر قطعات بدون کاهش محسوس عملکرد است.

اثر افزایش ولتاژ

پیامدهای افزایش ولتاژ GPU
اثر نتیجه
پایداری بیشتر امکان رسیدن به فرکانس بالاتر
مصرف انرژی افزایش توان مصرفی
دما تولید گرمای بیشتر
فشار روی مدار تغذیه افزایش بار VRM
طول عمر در ولتاژهای بسیار بالا ممکن است
کاهش یابد

چه بخشی ولتاژ GPU را کنترل می‌کند؟

کنترل ولتاژ توسط همکاری Firmware، BIOS کارت،
درایور، کنترل‌کننده توان داخلی GPU و مدار VRM
انجام می‌شود.

این بخش‌ها به‌طور مداوم اطلاعات مربوط به دما،
جریان، توان و فرکانس را بررسی کرده و مناسب‌ترین
ولتاژ را انتخاب می‌کنند.

Driver
   │
   ▼
GPU Firmware
   │
   ▼
Power Controller
   │
   ▼
VRM
   │
   ▼
GPU Core

مدیریت ولتاژ در کارت‌های حرفه‌ای

در کارت‌های حرفه‌ای مانند NVIDIA RTX Ada،
Quadro، AMD Radeon Pro و Intel Arc Pro، کنترل
ولتاژ معمولاً محافظه‌کارانه‌تر از کارت‌های گیمینگ
انجام می‌شود.

هدف اصلی این کارت‌ها حفظ پایداری در پردازش‌های
چندساعته، رندرهای طولانی و محاسبات علمی است،
نه دستیابی به بیشترین Boost لحظه‌ای.

مدیریت ولتاژ در انواع GPU
خانواده اولویت طراحی
GeForce عملکرد لحظه‌ای و بازی
RTX Professional پایداری طولانی‌مدت
Radeon Pro عملکرد پایدار ورک‌استیشن
Intel Arc Pro تعادل عملکرد و مصرف انرژی

توان مصرفی GPU چیست؟

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

مصرف توان ثابت نیست و بر اساس نوع بار کاری،
فرکانس، ولتاژ، دما، تعداد واحدهای فعال و سرعت
حافظه تغییر می‌کند.

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

کدام بخش‌های کارت گرافیک انرژی مصرف می‌کنند؟

مصرف انرژی کارت گرافیک فقط مربوط به هسته اصلی
GPU نیست. حافظه، مدار تغذیه، کنترل‌کننده‌ها،
موتورهای رسانه و حتی فن‌ها نیز بخشی از توان
دریافت‌شده را مصرف می‌کنند.

اجزای مؤثر بر توان مصرفی کارت گرافیک
بخش وظیفه سهم احتمالی در مصرف
GPU Core اجرای Shader، Compute و رندر معمولاً بیشترین سهم
VRAM نگهداری و انتقال داده قابل‌توجه، به‌ویژه در حافظه‌های سریع
Memory Controller مدیریت ارتباط GPU و حافظه وابسته به بار حافظه
RT و Matrix Units Ray Tracing و محاسبات ماتریسی وابسته به نوع بار کاری
Video Engine Encode و Decode معمولاً کمتر از بار سه‌بعدی کامل
VRM تبدیل و تنظیم ولتاژ بخشی از توان به‌صورت تلفات
فن‌ها و مدارهای جانبی خنک‌سازی و کنترل برد سهم کمتر

تفاوت توان Static و Dynamic

مصرف انرژی تراشه را می‌توان به‌صورت مفهومی به دو
بخش توان ایستا و توان پویا تقسیم کرد.

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

مقایسه توان ایستا و پویا در GPU
نوع توان علت عوامل مؤثر
Dynamic Power تغییر وضعیت مدارها هنگام پردازش فرکانس، ولتاژ و میزان فعالیت
Static Power نشت جریان ترانزیستورها دما، فرآیند ساخت و ولتاژ

چرا مصرف توان در برنامه‌های مختلف متفاوت است؟

هر برنامه مجموعه متفاوتی از واحدهای GPU را فعال
می‌کند. به همین دلیل دو نرم‌افزار با درصد استفاده
ظاهری مشابه می‌توانند توان مصرفی متفاوتی داشته
باشند.

رفتار مصرف توان در چند نوع بار کاری
بار کاری بخش‌های فعال رفتار توان
بازی Shader، TMU، ROP، Cache و VRAM متغیر و وابسته به صحنه
رندر GPU Compute، حافظه و گاهی RT Core بالا و نسبتاً پایدار
هوش مصنوعی Matrix Unit، Compute و VRAM بالا و وابسته به مدل
Encode ویدئو موتور رسانه و بخشی از حافظه معمولاً کمتر از رندر سه‌بعدی کامل
CAD Viewport Shader، Raster و Buffer متغیر و وابسته به پیچیدگی مدل
Idle Display Engine و بخش‌های ضروری بسیار پایین‌تر

کارت گرافیک انرژی خود را از کجا دریافت می‌کند؟

کارت گرافیک دسکتاپ می‌تواند بخشی از توان خود را
از اسلات PCI Express و بخش دیگر را از کابل‌های
مستقیم منبع تغذیه دریافت کند.

در لپ‌تاپ، انرژی GPU از مدار تغذیه مادربرد تأمین
می‌شود و محدودیت آن به طراحی دستگاه، آداپتور،
باتری و سیستم خنک‌کننده وابسته است.

بازده مدار VRM چه اثری بر مصرف دارد؟

مدار VRM ولتاژ ورودی منبع تغذیه را به ولتاژهای
پایین و دقیق موردنیاز هسته GPU و حافظه تبدیل
می‌کند.

این تبدیل کاملاً بدون اتلاف نیست و بخشی از انرژی
به گرما تبدیل می‌شود. کیفیت طراحی، تعداد فازها،
نوع قطعات و دمای VRM بر بازده آن اثر دارند.

VRM ضعیف یا بسیار گرم ممکن است پایداری فرکانس را
کاهش دهد یا باعث محدودشدن توان کارت شود.

تفاوت TDP، TGP و TBP چیست؟

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

این اصطلاحات همیشه دقیقاً یک محدوده یکسان را
اندازه‌گیری نمی‌کنند؛ بنابراین مقایسه مستقیم
اعداد بدون توجه به تعریف سازنده می‌تواند گمراه‌کننده
باشد.

مقایسه مفهومی اصطلاحات توان GPU
اصطلاح مفهوم عمومی محدوده احتمالی نکته مهم
TDP شاخص طراحی حرارتی گرمایی که سیستم خنک‌کننده باید مدیریت کند الزاماً مصرف دقیق لحظه‌ای نیست
TGP توان کلی پردازنده یا زیرسیستم گرافیکی معمولاً GPU و اجزای وابسته تعریف دقیق به سازنده وابسته است
TBP توان کلی برد هسته، حافظه و اجزای کارت به توان کل کارت نزدیک‌تر است
Board Power توان اندازه‌گیری‌شده یا محدودشده برد کل کارت گرافیک ممکن است لحظه‌ای یا میانگین باشد

چرا TGP در لپ‌تاپ اهمیت بیشتری دارد؟

یک مدل GPU لپ‌تاپی ممکن است در دستگاه‌های مختلف
با سقف توان متفاوت تنظیم شود.

نسخه کم‌مصرف‌تر معمولاً فرکانس پایدار پایین‌تری
دارد، درحالی‌که نسخه پرتوان‌تر در صورت وجود
خنک‌کننده مناسب می‌تواند عملکرد بیشتری ارائه دهد.

به همین دلیل نام GPU به‌تنهایی برای مقایسه دو
لپ‌تاپ کافی نیست و باید توان واقعی یا محدوده TGP
آن‌ها نیز بررسی شود.

اثر تفاوت TGP در GPUهای لپ‌تاپی
TGP پایین‌تر TGP بالاتر
مصرف و گرمای کمتر عملکرد بالقوه بیشتر
مناسب دستگاه باریک‌تر نیازمند خنک‌کننده قوی‌تر
فشار کمتر بر آداپتور و باتری مصرف انرژی و صدای فن بیشتر
Boost پایدار پایین‌تر Boost پایدار بالاتر در شرایط مناسب

Power Limit چیست؟

Power Limit سقفی است که مشخص می‌کند کارت گرافیک
در یک بازه زمانی چه مقدار توان الکتریکی می‌تواند
مصرف کند.

کنترل‌کننده توان GPU به‌طور پیوسته مصرف هسته،
حافظه و بخش‌های مختلف کارت را بررسی می‌کند. اگر
توان مصرفی به محدوده تعیین‌شده نزدیک شود، سیستم
ممکن است فرکانس، ولتاژ یا میزان Boost را کاهش دهد.

Power Limit برای جلوگیری از فشار بیش‌ازحد بر مدار
تغذیه، منبع انرژی، آداپتور، باتری و سیستم خنک‌کننده
استفاده می‌شود.

Power Limit چگونه عمل می‌کند؟

GPU برای رسیدن به فرکانس بالاتر معمولاً به ولتاژ
و توان بیشتری نیاز دارد. کنترل‌کننده داخلی بررسی
می‌کند که افزایش فرکانس باعث عبور از سقف توان
نشود.

اگر فضای توان وجود داشته باشد، GPU می‌تواند Boost
بیشتری اعمال کند. اگر مصرف به سقف برسد، فرکانس
کاهش پیدا می‌کند تا توان در محدوده مجاز باقی بماند.

تفاوت Power Limit و TGP

TGP معمولاً مشخصه‌ای برای توان طراحی‌شده زیرسیستم
گرافیکی است، درحالی‌که Power Limit محدودیتی است
که Firmware یا BIOS برای کنترل مصرف واقعی اعمال
می‌کند.

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

مقایسه Power Limit و TGP
معیار Power Limit TGP
مفهوم سقف اجرایی مصرف توان مشخصه توان زیرسیستم گرافیکی
محل تنظیم BIOS، Firmware یا نرم‌افزار طراحی و مشخصات سازنده
قابلیت تغییر در بعضی کارت‌ها قابل تنظیم است معمولاً مشخصه محصول است
اثر مستقیم محدودکردن Boost و مصرف لحظه‌ای تعیین کلاس توان و خنک‌کننده

افزایش Power Limit چه اثری دارد؟

در بعضی کارت‌های دسکتاپ، نرم‌افزارهای تنظیم GPU
اجازه می‌دهند Power Limit در محدوده‌ای مشخص افزایش
پیدا کند.

افزایش این مقدار به معنی افزایش مستقیم فرکانس نیست؛
بلکه فضای بیشتری در اختیار سیستم Boost قرار می‌دهد
تا در صورت مناسب‌بودن دما و ولتاژ، فرکانس بالاتری
حفظ شود.

پیامدهای احتمالی افزایش Power Limit
اثر نتیجه احتمالی
فضای توان بیشتر حفظ Boost Clock بالاتر
مصرف برق بیشتر فشار بیشتر بر منبع تغذیه و آداپتور
تولید گرمای بیشتر افزایش دما و سرعت فن
فشار بیشتر بر VRM نیاز به مدار تغذیه و خنک‌کننده مناسب
احتمال محدودیت حرارتی تبدیل Power Limit به Thermal Limit

کاهش Power Limit چه کاربردی دارد؟

کاهش Power Limit می‌تواند برای کنترل دما، کاهش
صدای فن، کاهش مصرف انرژی و افزایش پایداری سیستم
خنک‌کننده مفید باشد.

در بعضی GPUها، کاهش محدود توان افت عملکرد کمی
ایجاد می‌کند؛ زیرا بخش پایانی منحنی فرکانس و
ولتاژ بهره‌وری پایینی دارد.

این روش برای ورک‌استیشن‌های کوچک، لپ‌تاپ‌های
قدیمی، سیستم‌های کم‌صدا و کارت‌هایی با خنک‌کننده
محدود کاربرد دارد.

مزایا و محدودیت‌های کاهش Power Limit
مزیت محدودیت
دمای کمتر کاهش احتمالی فرکانس
صدای فن کمتر افت عملکرد در بارهای سنگین
مصرف انرژی کمتر نیاز به آزمون برای یافتن نقطه مناسب
فشار کمتر بر VRM و آداپتور محدودیت در رندر یا محاسبات طولانی

Power Throttling چیست؟

Power Throttling زمانی رخ می‌دهد که GPU به سقف
توان تعیین‌شده برسد و برای جلوگیری از عبور از آن،
فرکانس یا ولتاژ خود را کاهش دهد.

این وضعیت لزوماً نشانه خرابی نیست؛ بلکه بخشی از
رفتار طبیعی سیستم مدیریت توان است.

اگر Power Throttling دائماً رخ دهد، ممکن است کارت
در بار کاری موردنظر به توان بیشتری نیاز داشته باشد
یا طراحی دستگاه عمداً برای مصرف پایین‌تر تنظیم شده
باشد.

نشانه‌های Power Throttling

نشانه‌های احتمالی محدودشدن GPU توسط توان
نشانه توضیح
رسیدن مصرف به سقف مشخص توان گزارش‌شده نزدیک Power Limit باقی می‌ماند
افت دوره‌ای فرکانس Clock برای حفظ سقف توان کاهش پیدا می‌کند
دمای قابل‌قبول همراه با افت Clock محدودیت احتمالاً حرارتی نیست
نمایش Power Limit در ابزار مانیتورینگ دلیل محدودیت توسط حسگر یا Firmware ثبت می‌شود
عملکرد متفاوت در بارهای مختلف بعضی Workloadها توان بیشتری مصرف می‌کنند

تفاوت Power Throttling و Thermal Throttling

مقایسه محدودیت توان و محدودیت دما
معیار Power Throttling Thermal Throttling
عامل اصلی رسیدن به سقف توان رسیدن به سقف دما
دمای GPU ممکن است کاملاً مناسب باشد معمولاً بالا است
راهکار اصلی اصلاح محدودیت توان یا بهره‌وری بهبود خنک‌کننده
اثر افزایش فن ممکن است تأثیر کمی داشته باشد معمولاً مفید است
اثر Undervolting کاهش مصرف و حفظ فرکانس کاهش توان و دما

محدودیت توان در GPUهای لپ‌تاپی

در لپ‌تاپ، Power Limit فقط به خود GPU وابسته نیست.
CPU، GPU، حافظه، باتری و سایر اجزا از ظرفیت مشترک
آداپتور و سیستم خنک‌کننده استفاده می‌کنند.

سازنده لپ‌تاپ بر اساس ضخامت دستگاه، تعداد فن‌ها،
اندازه هیت‌سینک و توان آداپتور، سقف مصرف GPU را
تعیین می‌کند.

بنابراین دو لپ‌تاپ با نام GPU یکسان می‌توانند
عملکرد پایدار متفاوتی داشته باشند.

عوامل تعیین‌کننده Power Limit لپ‌تاپ
عامل اثر
توان آداپتور تعیین بودجه کل انرژی دستگاه
سیستم خنک‌کننده تعیین توان قابل حفظ در مدت طولانی
مصرف CPU کاهش یا افزایش توان قابل اختصاص به GPU
BIOS سازنده تعیین سقف‌ها و رفتار Boost
حالت عملکرد دستگاه تغییر توان میان Silent، Balanced و Performance
کار با باتری کاهش شدید توان و فرکانس در بسیاری از مدل‌ها

رفتار توان در لپ‌تاپ‌های ورک‌استیشن

لپ‌تاپ‌های ورک‌استیشن قدیمی مجهز به Quadro K،
M یا P معمولاً با توان‌های محافظه‌کارانه طراحی
شده‌اند تا پایداری در رندر، CAD و محاسبات طولانی
حفظ شود.

در این دستگاه‌ها، گردوغبار، خشک‌شدن خمیر حرارتی،
فرسودگی فن و استفاده از آداپتور نامناسب می‌تواند
باعث کاهش توان قابل‌دستیابی GPU شود.

هنگام خرید دستگاه استوک، فقط نام Quadro کافی نیست
و باید توان پایدار، دما، فرکانس و وضعیت آداپتور
زیر بار بررسی شود.

Thermal Throttling چیست؟

Thermal Throttling زمانی رخ می‌دهد که دمای GPU
به محدوده تعیین‌شده توسط سازنده نزدیک شود و
پردازنده گرافیکی برای جلوگیری از افزایش بیشتر
دما، فرکانس یا ولتاژ خود را کاهش دهد.

این فرایند یک مکانیزم حفاظتی طبیعی است و از
آسیب‌دیدن تراشه، حافظه، مدار تغذیه و سایر اجزای
سیستم جلوگیری می‌کند.

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

Thermal Throttling چگونه اتفاق می‌افتد؟

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

Thermal Limit چیست؟

Thermal Limit دمایی است که کنترل‌کننده GPU پس از
رسیدن به آن، رفتار فرکانس و ولتاژ را برای کنترل
گرما تغییر می‌دهد.

این مقدار میان معماری‌ها، مدل‌ها، BIOSها و
محصولات دسکتاپ یا لپ‌تاپی متفاوت است.

Thermal Limit را نباید با دمای خرابی تراشه یکی
دانست. محدودیت حرارتی معمولاً پیش از رسیدن به
شرایط خطرناک فعال می‌شود.

نشانه‌های Thermal Throttling

نشانه‌های احتمالی محدودشدن GPU توسط دما
نشانه توضیح
دمای بالا دما نزدیک محدودیت تعیین‌شده باقی می‌ماند
افت فرکانس پس از چند دقیقه خنک‌کننده در شروع سرد است اما به‌تدریج اشباع می‌شود
نوسان Clock GPU میان Boost و فرکانس پایین‌تر جابه‌جا می‌شود
افزایش سرعت فن سیستم برای کنترل دما تلاش می‌کند
افت FPS یا سرعت رندر کاهش فرکانس باعث افت عملکرد پایدار می‌شود
ثبت Thermal Limit ابزار مانیتورینگ دلیل محدودیت را حرارتی نشان می‌دهد

دلایل رایج Thermal Throttling

مهم‌ترین دلایل افزایش بیش‌ازحد دمای GPU
علت اثر راهکار احتمالی
گردوغبار کاهش عبور هوا از هیت‌سینک تمیزکردن سیستم خنک‌کننده
خمیر حرارتی خشک‌شده انتقال ضعیف گرما از تراشه تعویض اصولی خمیر حرارتی
فرسودگی Thermal Pad افزایش دمای VRAM یا VRM استفاده از Pad با ضخامت مناسب
فن ضعیف یا خراب کاهش جریان هوا بررسی، تعمیر یا تعویض فن
تهویه نامناسب کیس تجمع هوای گرم اطراف کارت اصلاح ورودی و خروجی هوا
توان مصرفی بالا تولید گرمای بیشتر از ظرفیت خنک‌کننده کاهش Power Limit یا Undervolting
دمای محیط بالا کاهش اختلاف دمای خنک‌کننده با محیط بهبود تهویه محیط
مسدودبودن دریچه لپ‌تاپ کاهش هوای ورودی قراردادن دستگاه روی سطح مناسب

حسگرهای دمای GPU

کارت‌های گرافیک جدید ممکن است چندین حسگر حرارتی
در نقاط مختلف تراشه، حافظه و مدار تغذیه داشته
باشند.

به همین دلیل عددی که با عنوان GPU Temperature
نمایش داده می‌شود الزاماً گرم‌ترین نقطه کارت نیست.

دماهای رایج گزارش‌شده در کارت گرافیک
حسگر محل یا مفهوم کاربرد
GPU Core Temperature دمای عمومی یا میانگین هسته بررسی وضعیت کلی تراشه
Hotspot Temperature گرم‌ترین نقطه اندازه‌گیری‌شده روی Die تشخیص تمرکز گرما یا تماس نامناسب
Memory Junction دمای داخلی یا نقطه اتصال حافظه بررسی وضعیت VRAM
VRM Temperature دمای مدار تغذیه بررسی فشار روی MOSFET و فازها
Board Temperature دمای بخش‌هایی از برد تحلیل تهویه کلی کارت

Hotspot Temperature چیست؟

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

Hotspot Temperature بالاترین دمای ثبت‌شده میان
حسگرهای داخلی تراشه است.

اختلاف زیاد میان Core Temperature و Hotspot
می‌تواند در بعضی موارد نشانه توزیع نامناسب خمیر
حرارتی، فشار نابرابر هیت‌سینک یا تمرکز طبیعی بار
کاری باشد.

Memory Junction Temperature چیست؟

Memory Junction Temperature دمای مربوط به تراشه‌های
VRAM یا گرم‌ترین نقطه اندازه‌گیری‌شده در حافظه
گرافیکی است.

حافظه‌های پرسرعت، به‌ویژه در بارهای سنگین انتقال
داده، می‌توانند گرمای قابل‌توجهی تولید کنند.

Thermal Pad نامناسب، تماس ضعیف با هیت‌سینک یا
جریان هوای کم می‌تواند باعث افزایش دمای حافظه شود.

سیستم خنک‌کننده چه اثری بر عملکرد GPU دارد؟

خنک‌کننده بهتر فقط دمای پایین‌تری ایجاد نمی‌کند؛
بلکه می‌تواند فضای حرارتی بیشتری برای حفظ Boost
Clock فراهم کند.

اگر GPU در دمای پایین‌تر و بدون رسیدن به محدودیت
حرارتی کار کند، فرکانس پایدار در بازی، رندر و
پردازش‌های طولانی بهتر حفظ می‌شود.

اثر کیفیت خنک‌کننده بر رفتار GPU
خنک‌کننده ضعیف خنک‌کننده مناسب
افزایش سریع دما کنترل بهتر دمای تراشه
افت زودهنگام Boost حفظ فرکانس پایدارتر
صدای زیاد فن امکان عملکرد کم‌صداتر
فشار بیشتر بر قطعات شرایط حرارتی متعادل‌تر
احتمال نوسان عملکرد عملکرد یکنواخت‌تر

انواع سیستم خنک‌کننده GPU

مقایسه روش‌های رایج خنک‌سازی کارت گرافیک
نوع خنک‌کننده ویژگی کاربرد رایج
Passive بدون فن و کاملاً بی‌صدا GPUهای کم‌مصرف
Blower خروج مستقیم هوای گرم از کیس ورک‌استیشن و کیس‌های فشرده
Open-Air چند فن و هیت‌سینک بزرگ کارت‌های دسکتاپ عمومی و گیمینگ
Vapor Chamber توزیع بهتر گرما روی سطح خنک‌کننده کارت‌های قدرتمند و لپ‌تاپ‌ها
Liquid Cooling انتقال گرما با مایع سیستم‌های رده‌بالا
Shared Laptop Heatpipe اشتراک بخشی از خنک‌کننده CPU و GPU لپ‌تاپ‌های باریک و ورک‌استیشن

Thermal Throttling در لپ‌تاپ‌ها

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

هنگام بار هم‌زمان CPU و GPU، حرارت تولیدشده می‌تواند
باعث کاهش توان یا فرکانس یکی از این دو قطعه شود.

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

NVIDIA Dynamic Boost چیست؟

Dynamic Boost قابلیتی در بعضی لپ‌تاپ‌های مجهز به
پردازنده گرافیکی NVIDIA است که توان قابل‌استفاده
را به‌صورت پویا میان CPU و GPU تقسیم می‌کند.

اگر یک برنامه بیشتر به GPU وابسته باشد و CPU به
تمام بودجه توان خود نیاز نداشته باشد، بخشی از توان
می‌تواند به GPU منتقل شود تا فرکانس و عملکرد آن
افزایش پیدا کند.

در بارهای CPU-محور نیز ممکن است سهم بیشتری از توان
به پردازنده مرکزی اختصاص داده شود.

Dynamic Boost چگونه کار می‌کند؟

Firmware، درایور و کنترل‌کننده توان دستگاه به‌طور
پیوسته بار CPU، بار GPU، دما و توان کل سیستم را
بررسی می‌کنند.

انتقال توان تنها زمانی انجام می‌شود که آداپتور،
مدار تغذیه و سیستم خنک‌کننده ظرفیت لازم را داشته
باشند.

چه عواملی بر Dynamic Boost اثر دارند؟

عوامل تعیین‌کننده تقسیم پویا توان
عامل اثر
نوع بار کاری تعیین می‌کند CPU یا GPU به توان بیشتری نیاز دارد
دمای CPU و GPU قطعه گرم‌تر ممکن است توان کمتری دریافت کند
توان آداپتور سقف بودجه انرژی کل سیستم را تعیین می‌کند
طراحی خنک‌کننده توان قابل حفظ در بار طولانی را محدود می‌کند
حالت عملکرد لپ‌تاپ پروفایل Silent، Balanced یا Performance رفتار توان را تغییر می‌دهد
BIOS و Firmware محدوده جابه‌جایی توان و اولویت‌ها را تعیین می‌کند

مزایا و محدودیت‌های Dynamic Boost

مزایا و محدودیت‌های تقسیم پویا توان
مزیت محدودیت
استفاده بهتر از بودجه توان لپ‌تاپ وابستگی شدید به طراحی سازنده
افزایش عملکرد در بارهای GPU-محور توان اضافه همیشه دائمی نیست
تنظیم خودکار بدون دخالت کاربر دما می‌تواند انتقال توان را محدود کند
تعادل بهتر میان CPU و GPU در بار هم‌زمان سنگین، هر دو قطعه محدود می‌شوند
بهبود بهره‌وری دستگاه رفتار دقیق در هر لپ‌تاپ متفاوت است

بودجه مشترک توان و حرارت CPU و GPU

در بسیاری از لپ‌تاپ‌ها، CPU و GPU علاوه بر آداپتور،
بخشی از هیت‌پایپ، فن یا ظرفیت دفع حرارت را نیز با
یکدیگر به اشتراک می‌گذارند.

اگر هر دو قطعه هم‌زمان تحت بار کامل باشند، ممکن است
توان قابل‌اختصاص به هرکدام کاهش یابد.

به همین دلیل عملکرد بازی، رندر و شبیه‌سازی فقط به
مشخصات GPU وابسته نیست و رفتار CPU نیز می‌تواند روی
فرکانس پایدار GPU اثر بگذارد.

اثر نوع بار بر تقسیم توان لپ‌تاپ
نوع بار وضعیت CPU وضعیت GPU نتیجه احتمالی
بازی GPU-محور متوسط سنگین توان بیشتر برای GPU
شبیه‌سازی CPU-محور سنگین سبک توان بیشتر برای CPU
رندر ترکیبی سنگین سنگین رقابت برای توان و خنک‌کننده
پخش ویدئو سبک موتور رسانه فعال مصرف کلی پایین‌تر

Performance State یا P-State چیست؟

P-State حالت عملکرد و مصرف انرژی GPU را مشخص
می‌کند. هر حالت می‌تواند محدوده متفاوتی از فرکانس،
ولتاژ و فعالیت واحدهای داخلی داشته باشد.

GPU هنگام تغییر بار کاری میان این حالت‌ها جابه‌جا
می‌شود تا تعادل مناسبی میان عملکرد و مصرف انرژی
ایجاد کند.

نام‌گذاری و تعداد P-Stateها میان سازندگان و نسل‌های
مختلف یکسان نیست.

نمونه حالت‌های عملکرد GPU

حالت‌های مفهومی عملکرد و مصرف انرژی GPU
حالت فرکانس مصرف انرژی کاربرد
High Performance بالا بالا بازی، رندر و Compute
Medium Performance متوسط متوسط Viewport و کار سبک‌تر
Video State متناسب با موتور رسانه پایین‌تر Decode و Encode
Idle State بسیار پایین حداقل دسکتاپ و کارهای ساده
Sleep یا Power-Gated خاموش یا نزدیک صفر بسیار کم بخش‌های بلااستفاده GPU

Clock Gating چیست؟

Clock Gating روشی برای متوقف‌کردن سیگنال Clock در
بخش‌هایی از GPU است که در لحظه استفاده نمی‌شوند.

وقتی یک واحد Clock دریافت نکند، تغییر وضعیت کمتری
در ترانزیستورهای آن رخ می‌دهد و توان پویا کاهش پیدا
می‌کند.

این روش می‌تواند بدون خاموش‌کردن کامل بخش مربوطه،
مصرف انرژی را در زمان‌های کوتاه کاهش دهد.

Power Gating چیست؟

Power Gating روشی عمیق‌تر برای کاهش مصرف است که
جریان برق بخش‌های بلااستفاده تراشه را تا حد زیادی
قطع می‌کند.

این روش توان ایستا و نشت جریان را کاهش می‌دهد، اما
بازگرداندن بخش خاموش‌شده به حالت فعال ممکن است
زمان و انرژی بیشتری نسبت به Clock Gating نیاز
داشته باشد.

مقایسه Clock Gating و Power Gating
معیار Clock Gating Power Gating
روش توقف سیگنال Clock قطع یا کاهش شدید جریان برق
کاهش توان پویا زیاد زیاد
کاهش نشت جریان محدود بیشتر
سرعت بازگشت سریع معمولاً کندتر
کاربرد توقف‌های کوتاه بیکاری طولانی‌تر

مصرف انرژی GPU در حالت Idle

در حالت Idle، فرکانس هسته و حافظه کاهش پیدا می‌کند
و بسیاری از واحدهای پردازشی وارد حالت Clock-Gated
یا Power-Gated می‌شوند.

بااین‌حال، GPU ممکن است همچنان برای مدیریت خروجی
تصویر، مانیتورهای متصل، شتاب‌دهی رابط کاربری و
برنامه‌های پس‌زمینه فعال باقی بماند.

تعداد مانیتورها، وضوح، نرخ تازه‌سازی، HDR و نوع
اتصال می‌توانند روی فرکانس حافظه و مصرف Idle اثر
بگذارند.

عوامل افزایش مصرف GPU در حالت Idle
عامل اثر احتمالی
چند مانیتور افزایش فعالیت Display Engine و حافظه
نرخ تازه‌سازی بالا جلوگیری از کاهش کامل Memory Clock
وضوح بالا افزایش پهنای باند خروجی تصویر
برنامه‌های شتاب‌یافته فعال نگه‌داشتن بخشی از GPU
ضبط صفحه یا Overlay فعالیت موتور رسانه یا Shader
تنظیمات درایور جلوگیری از ورود به حالت کم‌مصرف

نقش گرافیک ترکیبی در کاهش مصرف لپ‌تاپ

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

در صورت عدم نیاز، GPU مجزا می‌تواند وارد حالت
کم‌مصرف یا تقریباً خاموش شود تا عمر باتری افزایش
پیدا کند.

برنامه‌ای که به‌اشتباه GPU مجزا را فعال نگه دارد
می‌تواند مصرف باتری و دمای Idle را افزایش دهد.

Overclocking یا اورکلاک GPU چیست؟

Overclocking به افزایش فرکانس هسته، حافظه یا هر دو
نسبت به تنظیمات پیش‌فرض سازنده گفته می‌شود.

هدف اورکلاک افزایش عملکرد در بازی، رندر، پردازش
محاسباتی یا سایر بارهای کاری است؛ اما نتیجه نهایی
به ظرفیت خنک‌کننده، Power Limit، ولتاژ و کیفیت
تراشه بستگی دارد.

افزایش عدد فرکانس به‌تنهایی کافی نیست. تنظیم جدید
باید در بارهای طولانی پایدار باشد و باعث خطای
محاسباتی، Artifact، Crash یا افزایش بیش‌ازحد دما
نشود.

تفاوت اورکلاک هسته و حافظه

مقایسه افزایش فرکانس هسته و VRAM
نوع اورکلاک بخش تحت‌تأثیر کاربردهای حساس خطاهای احتمالی
Core Overclock هسته و واحدهای پردازشی GPU Shader، Compute، رندر و بازی Crash، ریست درایور یا Artifact
Memory Overclock VRAM و مسیر انتقال حافظه بارهای وابسته به پهنای باند خطای حافظه، بافت خراب یا کاهش عملکرد
Core و Memory هم‌زمان کل زیرسیستم گرافیکی بارهای ترکیبی تشخیص دشوارتر عامل ناپایداری

چه عواملی اورکلاک GPU را محدود می‌کنند؟

مهم‌ترین محدودیت‌های اورکلاک کارت گرافیک
محدودیت اثر نشانه احتمالی
Power Limit جلوگیری از حفظ فرکانس بالاتر رسیدن مداوم به محدودیت توان
Thermal Limit کاهش Boost در اثر دما افت فرکانس پس از گرم‌شدن
ولتاژ محدودیت پایداری در Clock بالاتر Crash یا خطای محاسباتی
کیفیت تراشه تفاوت ظرفیت اورکلاک میان نمونه‌ها نتیجه متفاوت در دو کارت مشابه
VRM محدودیت جریان و توان پایدار افزایش دمای مدار تغذیه
محدودیت BIOS جلوگیری از تغییر بعضی پارامترها قفل‌بودن Power Limit یا Voltage
خنک‌کننده حافظه محدودیت Memory Overclock افزایش دمای VRAM یا خطای حافظه

نشانه‌های ناپایداری اورکلاک

خطاهای رایج ناشی از اورکلاک ناپایدار
نشانه علت احتمالی اقدام مناسب
بسته‌شدن برنامه Core Clock یا Memory Clock بیش‌ازحد کاهش تدریجی فرکانس
ریست درایور ناپایداری هسته یا ولتاژ ناکافی بازگشت به تنظیم پایدارتر
نقاط یا خطوط رنگی خطای VRAM یا Shader کاهش Memory Clock یا Core Clock
افت ناگهانی عملکرد Power یا Thermal Throttling بررسی توان، دما و Effective Clock
نتیجه محاسباتی اشتباه خطای خاموش در Compute تست صحت خروجی، نه فقط نبود Crash
هنگ کامل سیستم تنظیم بسیار ناپایدار بازگرداندن تنظیمات پیش‌فرض

اورکلاک GPU در لپ‌تاپ

اورکلاک در لپ‌تاپ معمولاً محدودتر از دسکتاپ است؛
زیرا GPU، CPU، VRM و حافظه در فضای کوچکی قرار دارند
و ظرفیت دفع حرارت محدود است.

بعضی سازندگان امکان تغییر محدود Core Clock یا
Memory Clock را فراهم می‌کنند، اما Power Limit و
Voltage معمولاً قفل یا بسیار محدود هستند.

در لپ‌تاپ‌های استوک و ورک‌استیشن‌های قدیمی، سرویس
خنک‌کننده و سلامت آداپتور معمولاً اهمیت بیشتری از
اورکلاک دارند.

Undervolting چیست؟

Undervolting به کاهش ولتاژ GPU در یک فرکانس مشخص
گفته می‌شود.

هدف این کار کاهش توان مصرفی، دما و صدای فن است،
بدون آنکه عملکرد به‌طور محسوسی کاهش پیدا کند.

اگر تراشه بتواند همان فرکانس را با ولتاژ کمتر
پایدار نگه دارد، فضای بیشتری در محدودیت توان و
حرارت ایجاد می‌شود.

مزایای احتمالی Undervolting

اثرات احتمالی کاهش ولتاژ GPU
مزیت نتیجه
توان مصرفی کمتر کاهش فشار بر منبع تغذیه و آداپتور
دمای پایین‌تر کاهش احتمال Thermal Throttling
صدای فن کمتر عملکرد آرام‌تر سیستم
Sustained Clock بهتر حفظ فرکانس پایدار در سقف توان مشخص
بهره‌وری بالاتر عملکرد بیشتر به‌ازای هر وات
فشار کمتر بر VRM گرمای کمتر مدار تغذیه

محدودیت‌ها و خطرهای Undervolting

کاهش بیش‌ازحد ولتاژ می‌تواند باعث ناپایداری،
بسته‌شدن برنامه، ریست درایور یا خطای محاسباتی شود.

هر تراشه کیفیت متفاوتی دارد و تنظیم پایدار یک GPU
الزاماً روی نمونه دیگر قابل استفاده نیست.

مشکلات احتمالی Undervolting ناپایدار
مشکل علت راهکار
Crash ولتاژ ناکافی برای فرکانس انتخاب‌شده افزایش جزئی ولتاژ یا کاهش Clock
ریست درایور ناپایداری لحظه‌ای اصلاح نقطه Voltage/Frequency
افت عملکرد انتخاب فرکانس هدف بسیار پایین تنظیم منحنی متعادل‌تر
خطای Compute ناپایداری بدون نشانه تصویری تست صحت محاسبات و رندر
بازگشت تنظیم پس از Restart محدودیت نرم‌افزار یا درایور ذخیره پروفایل و بررسی سازگاری

تفاوت Undervolting و کاهش Power Limit

مقایسه دو روش کاهش مصرف و دمای GPU
معیار Undervolting کاهش Power Limit
روش کاهش ولتاژ در فرکانس مشخص کاهش سقف توان مجاز
کنترل فرکانس امکان حفظ Clock هدف کنترل خودکار توسط Boost
پیچیدگی نیازمند تنظیم و تست دقیق‌تر ساده‌تر
افت عملکرد در تنظیم مناسب ممکن است بسیار کم باشد به میزان کاهش سقف توان وابسته است
خطر ناپایداری در ولتاژ بسیار پایین وجود دارد معمولاً کمتر

بهره‌وری انرژی GPU چیست؟

بهره‌وری انرژی نشان می‌دهد GPU در برابر هر وات
مصرف انرژی چه مقدار عملکرد ارائه می‌کند.

یک GPU ممکن است سریع‌تر باشد، اما برای دستیابی به
آن عملکرد توان بسیار بیشتری مصرف کند. در مقابل،
مدلی دیگر ممکن است با مصرف کمتر، بخش بزرگی از همان
عملکرد را ارائه دهد.

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

چه عواملی عملکرد به‌ازای وات را تعیین می‌کنند؟

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

نقطه بهینه بهره‌وری GPU

بیشتر GPUها در حداکثر فرکانس و ولتاژ خود بهترین
عملکرد به‌ازای وات را ندارند.

معمولاً بخشی از عملکرد نهایی با افزایش شدید توان
به دست می‌آید. کاهش محدود Clock، Voltage یا Power
Limit ممکن است مصرف و دما را به‌طور محسوسی کاهش
دهد، درحالی‌که افت عملکرد کم باقی بماند.

مدیریت توان در Quadro و کارت‌های حرفه‌ای

کارت‌های حرفه‌ای مانند NVIDIA Quadro، سری RTX
Professional، AMD Radeon Pro و Intel Arc Pro برای
بارهای کاری طولانی، پایداری درایور و عملکرد یکنواخت
طراحی می‌شوند.

در این محصولات، بیشترین Boost لحظه‌ای همیشه هدف
اصلی نیست. سازنده ممکن است فرکانس، ولتاژ و Power
Limit را محافظه‌کارانه‌تر تنظیم کند تا کارت در
رندرهای چندساعته، محاسبات مهندسی و پروژه‌های حساس
رفتار قابل‌پیش‌بینی‌تری داشته باشد.

ظرفیت VRAM، پشتیبانی ECC در مدل‌های خاص، طراحی
خنک‌کننده و گواهی نرم‌افزارهای حرفه‌ای نیز می‌توانند
در انتخاب تنظیمات توان نقش داشته باشند.

مقایسه رفتار توان کارت حرفه‌ای و گیمینگ

تفاوت‌های رایج در مدیریت توان کارت‌های حرفه‌ای و گیمینگ
معیار کارت حرفه‌ای کارت گیمینگ
اولویت اصلی پایداری، سازگاری و عملکرد یکنواخت بیشترین عملکرد در بازی و بار لحظه‌ای
رفتار Boost معمولاً کنترل‌شده‌تر معمولاً تهاجمی‌تر
بار کاری هدف CAD، رندر، شبیه‌سازی و محاسبات طولانی بازی، تولید محتوا و استفاده عمومی
خنک‌کننده متناسب با ورک‌استیشن و کار مداوم متنوع و گاهی متمرکز بر Boost بالا
محدودیت توان ممکن است محافظه‌کارانه‌تر باشد در مدل‌های رده‌بالا معمولاً بالاتر است
تنظیم دستی ممکن است محدودتر باشد معمولاً انعطاف بیشتری دارد

چرا بسیاری از کارت‌های حرفه‌ای از خنک‌کننده Blower استفاده می‌کنند؟

خنک‌کننده Blower هوای گرم را از داخل کارت عبور
داده و مستقیماً از پشت کیس خارج می‌کند.

این طراحی در ورک‌استیشن‌های چندکارت، کیس‌های فشرده
و سیستم‌هایی با جریان هوای کنترل‌شده مفید است؛ زیرا
گرمای کارت کمتر داخل کیس پخش می‌شود.

در مقابل، Blower ممکن است صدای بیشتری تولید کند و
در یک کارت منفرد، دمای بالاتری نسبت به خنک‌کننده
Open-Air داشته باشد.

مزایا و محدودیت‌های خنک‌کننده Blower
مزیت محدودیت
خروج مستقیم گرما از کیس صدای بیشتر فن
مناسب چند کارت نزدیک به هم سطح هیت‌سینک محدودتر
رفتار حرارتی قابل‌پیش‌بینی دمای بالاتر در بعضی مدل‌ها
مناسب کیس‌های ورک‌استیشن Boost کمتر از طراحی‌های بزرگ Open-Air

رفتار توان در رندر و محاسبات طولانی

در بارهای کوتاه، GPU ممکن است برای چند ثانیه یا
چند دقیقه Boost بالایی حفظ کند؛ اما در پردازش‌های
طولانی، تعادل حرارتی سیستم اهمیت بیشتری پیدا می‌کند.

پس از گرم‌شدن کامل هیت‌سینک، VRM، حافظه و هوای داخل
کیس، فرکانس ممکن است در مقدار پایین‌تری تثبیت شود.

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


مرحله ۱


شروع بار کاری

GPU سرد است و فضای حرارتی زیادی دارد.


مرحله ۲


Boost اولیه

فرکانس به بالاترین مقدار مجاز نزدیک می‌شود.


مرحله ۳


اشباع حرارتی

دمای GPU، VRAM و خنک‌کننده افزایش پیدا می‌کند.


مرحله ۴


فرکانس پایدار

Clock در نقطه متعادل توان و دما تثبیت می‌شود.

ECC چه اثری بر توان و عملکرد دارد؟

برخی کارت‌ها و شتاب‌دهنده‌های حرفه‌ای از حافظه ECC
یا سازوکارهای تشخیص و اصلاح خطا پشتیبانی می‌کنند.

این قابلیت برای محاسبات علمی، مدل‌سازی طولانی و
پردازش‌های حساس اهمیت دارد؛ زیرا احتمال خطای خاموش
در داده را کاهش می‌دهد.

فعال‌بودن ECC ممکن است مقداری از ظرفیت حافظه،
پهنای باند یا توان پردازشی را مصرف کند، اما در
پروژه‌های حساس، صحت داده معمولاً مهم‌تر از این
سربار محدود است.

رفتار توان در GPUهای قدیمی و لپ‌تاپ‌های استوک

GPUهای قدیمی معمولاً با فرآیند ساخت بزرگ‌تر، Cache
محدودتر و معماری کم‌بازده‌تری نسبت به نسل‌های جدید
تولید شده‌اند.

بااین‌حال، بسیاری از آن‌ها به دلیل Power Limit
پایین‌تر، همچنان برای CAD سبک، کارهای اداری،
آموزش و پروژه‌های نیمه‌حرفه‌ای قابل استفاده‌اند.

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

ویژگی‌های توان چند خانواده قدیمی GPU
مدل یا خانواده نسل رفتار رایج نکته خرید
Quadro K2100M Kepler توان متوسط و Boost محدودتر بررسی خنک‌کننده و آداپتور
Quadro K2200M Maxwell اولیه بهره‌وری بهتر از نسل Kepler توجه به دمای طولانی‌مدت
Quadro M1000M Maxwell مناسب ورک‌استیشن میان‌رده قدیمی بررسی ظرفیت VRAM
Quadro M2000M Maxwell عملکرد بهتر با توان کنترل‌شده تست فرکانس پایدار زیر بار
Quadro P1000 Pascal بهره‌وری مناسب در توان پایین مناسب CAD سبک و متوسط
Quadro P2000 Pascal تعادل خوب توان و عملکرد بررسی نوع دسکتاپ یا لپ‌تاپی
GTX 960M Maxwell محدود به توان لپ‌تاپی مناسب پروژه‌های سبک‌تر
GTX 1060 Laptop Pascal توان بالاتر و نیاز به خنک‌کننده بهتر بررسی عملکرد هم‌زمان CPU و GPU
Radeon Pro WX 4170 Polaris مصرف متوسط در ورک‌استیشن موبایل بررسی سازگاری درایور نرم‌افزار
Radeon RX 580 Polaris مصرف نسبتاً بالا در بار کامل نیازمند منبع تغذیه و تهویه مناسب

مشکلات رایج توان در لپ‌تاپ‌های قدیمی

عوامل کاهش عملکرد GPU در لپ‌تاپ‌های استوک
مشکل اثر روش بررسی
آداپتور ضعیف محدودشدن Power Limit بررسی وات و شناسه آداپتور
باتری خراب ناتوانی در جبران پیک مصرف تست دستگاه با باتری سالم
گردوغبار Thermal Throttling بررسی دما و جریان هوا
خمیر حرارتی فرسوده افت Sustained Clock مقایسه دمای شروع و دمای پایدار
BIOS قدیمی مدیریت نامناسب توان یا فن بررسی نسخه و مستندات سازنده
فن فرسوده کاهش ظرفیت خنک‌کننده بررسی صدا و سرعت فن
Thermal Pad نامناسب افزایش دمای VRAM یا VRM بررسی تعمیرات قبلی دستگاه

هنگام خرید GPU یا لپ‌تاپ، توان مصرفی را چگونه بررسی کنیم؟

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

این موضوع در لپ‌تاپ‌های گیمینگ، ورک‌استیشن‌های
استوک و مدل‌های باریک اهمیت بیشتری دارد؛ زیرا
سازنده می‌تواند همان تراشه را با Power Limit
متفاوت عرضه کند.

هنگام خرید باید عملکرد پایدار زیر بار بررسی شود،
نه فقط عدد Boost Clock، تعداد هسته یا نتیجه یک
آزمایش بسیار کوتاه.

چک‌لیست توان GPU هنگام خرید لپ‌تاپ

موارد مهم برای بررسی توان و عملکرد GPU لپ‌تاپی
مورد بررسی چرا مهم است؟ روش بررسی
TGP یا Power Limit تعیین‌کننده فضای توان GPU است مشخصات رسمی و ابزار مانیتورینگ
توان آداپتور باید توان CPU، GPU و سایر اجزا را تأمین کند بررسی وات درج‌شده روی آداپتور
اصالت آداپتور آداپتور ناسازگار می‌تواند توان را محدود کند بررسی مدل، ولتاژ، جریان و شناسه سازنده
طراحی خنک‌کننده تعیین‌کننده توان پایدار در بار طولانی است بررسی تعداد فن، هیت‌پایپ و خروجی هوا
اشتراک خنک‌کننده CPU و GPU بار CPU می‌تواند توان و دمای GPU را تغییر دهد بررسی طراحی داخلی و تست بار ترکیبی
فرکانس پایدار عملکرد واقعی را بهتر از Boost لحظه‌ای نشان می‌دهد تست چنددقیقه‌ای یا طولانی زیر بار
دمای Core و Hotspot وضعیت انتقال حرارت و خنک‌کننده را نشان می‌دهد استفاده از ابزار مانیتورینگ
صدای فن نشان‌دهنده فشار خنک‌کننده و سلامت فن است شنیدن صدا در حالت Idle و Load
حالت کار با باتری عملکرد GPU بدون آداپتور معمولاً کاهش می‌یابد مقایسه عملکرد با برق و باتری
پروفایل‌های عملکرد Silent، Balanced و Performance توان متفاوتی دارند بررسی نرم‌افزار سازنده لپ‌تاپ

بررسی توان GPU در لپ‌تاپ ورک‌استیشن استوک

در لپ‌تاپ استوک، وضعیت فعلی دستگاه ممکن است با
شرایط کارخانه تفاوت زیادی داشته باشد. گردوغبار،
خمیر حرارتی فرسوده، فن ضعیف، باتری خراب یا آداپتور
غیراصلی می‌توانند عملکرد GPU را محدود کنند.

مدل‌های مجهز به Quadro قدیمی ممکن است هنوز برای
AutoCAD، SolidWorks، CATIA، Revit، Maya یا Blender
سبک مناسب باشند؛ اما باید توان پایدار و وضعیت
حرارتی آن‌ها بررسی شود.

تست‌های پیشنهادی برای ورک‌استیشن استوک
تست هدف نشانه مشکل
تست بار GPU بررسی Clock، Power و دما افت سریع و مداوم فرکانس
تست هم‌زمان CPU و GPU بررسی بودجه مشترک توان و حرارت افت شدید عملکرد یکی از قطعات
بررسی آداپتور اطمینان از تأمین توان کامل محدودشدن فرکانس یا پیام آداپتور ناشناخته
بررسی فن کنترل سلامت مکانیکی و جریان هوا صدای ساییدگی، توقف یا سرعت نامنظم
تست VRAM بررسی سلامت حافظه گرافیکی Artifact، خطا یا Crash
تست نرم‌افزار واقعی بررسی عملکرد در کاربرد هدف ناپایداری فقط در پروژه سنگین
بررسی دمای Idle تشخیص فعالیت غیرعادی یا خنک‌کننده ضعیف دمای بالا بدون بار قابل‌توجه

هنگام خرید کارت گرافیک دسکتاپ چه مواردی را بررسی کنیم؟

بررسی توان و سازگاری کارت گرافیک دسکتاپ
مورد اهمیت نکته
منبع تغذیه تأمین توان پایدار کارت و کل سیستم فقط وات اسمی کافی نیست؛ کیفیت مهم است
کانکتور برق سازگاری فیزیکی و الکتریکی نوع و تعداد اتصال‌ها بررسی شود
فضای کیس نصب کارت و عبور مناسب هوا طول، ضخامت و ارتفاع کارت بررسی شود
تهویه کیس دفع گرمای GPU ورودی و خروجی هوا متعادل باشد
نوع خنک‌کننده اثر بر دما، صدا و Boost Blower و Open-Air کاربرد متفاوت دارند
توان پایدار کارت تعیین مصرف واقعی زیر بار به نسخه سفارشی سازنده نیز وابسته است
دمای VRAM و VRM پایداری در بارهای طولانی فقط دمای Core کافی نیست
نویز کیفیت تجربه استفاده سرعت فن زیر بار بررسی شود

اهمیت توان GPU در کاربردهای مختلف

اثر Power Limit و خنک‌کننده در کاربردهای مختلف
کاربرد نوع بار عامل مهم اهمیت توان پایدار
AutoCAD متغیر و وابسته به Viewport درایور، CPU و فرکانس پایدار متوسط
SolidWorks Viewport و نمایش Assembly Quadro، درایور حرفه‌ای و خنک‌کننده متوسط تا زیاد
Blender رندر طولانی و Compute VRAM، توان و Sustained Clock بسیار زیاد
Maya Viewport، شبیه‌سازی و رندر تعادل CPU، GPU و حافظه زیاد
ویرایش ویدئو Decode، افکت، Color و Export موتور رسانه، VRAM و توان پایدار زیاد
هوش مصنوعی Matrix و Memory Intensive VRAM، پهنای باند و Power Limit بسیار زیاد
بازی بار پویا و ترکیبی Boost، دما و توان زیاد
کار اداری سبک مصرف Idle و گرافیک مجتمع کم

اشتباهات رایج درباره فرکانس و توان GPU

باورهای اشتباه رایج درباره Clock، TGP و دمای GPU
باور اشتباه واقعیت
فرکانس بیشتر همیشه یعنی GPU سریع‌تر معماری، تعداد واحدها و حافظه نیز تعیین‌کننده‌اند
دو لپ‌تاپ با GPU یکسان عملکرد برابر دارند TGP، خنک‌کننده و BIOS می‌توانند متفاوت باشند
Boost Clock همیشه ثابت می‌ماند Boost به توان، دما و نوع بار وابسته است
TDP همان مصرف دقیق برق است TDP معمولاً یک شاخص طراحی حرارتی است
TGP بالاتر همیشه بهتر است خنک‌کننده و بهره‌وری معماری نیز اهمیت دارند
دمای پایین همیشه نشان‌دهنده عملکرد بهتر است ممکن است GPU توسط Power Limit محدود شده باشد
استفاده ۱۰۰ درصد یعنی حداکثر توان نوع واحدهای فعال و Workload توان را تعیین می‌کند
اورکلاک همیشه سرعت را افزایش می‌دهد محدودیت توان و دما ممکن است نتیجه را خنثی کند
Undervolting همیشه بدون خطر است ولتاژ بسیار پایین می‌تواند ناپایداری ایجاد کند
آداپتور با وات مشابه حتماً مناسب است ولتاژ، جریان، کانکتور و شناسایی سازنده مهم‌اند
تست چندثانیه‌ای برای لپ‌تاپ استوک کافی است اشباع حرارتی ممکن است بعداً ظاهر شود
فقط دمای Core باید بررسی شود Hotspot، VRAM و VRM نیز مهم هستند

سؤالات متداول درباره فرکانس، توان و دمای GPU

فرکانس GPU چیست؟

فرکانس GPU نشان می‌دهد بخش‌های پردازنده
گرافیکی در هر ثانیه چند چرخه کاری انجام
می‌دهند. این مقدار معمولاً با مگاهرتز یا
گیگاهرتز بیان می‌شود.

آیا فرکانس بیشتر همیشه به معنی عملکرد بهتر است؟

خیر. معماری، تعداد هسته‌ها، پهنای باند
حافظه، Cache، Power Limit و نوع بار کاری
نیز بر عملکرد اثر دارند.

تفاوت Base Clock و Boost Clock چیست؟

Base Clock فرکانس مرجع پایه است، درحالی‌که
Boost Clock فرکانسی پویا است که GPU در صورت
مناسب‌بودن دما، توان و ولتاژ به آن می‌رسد.

آیا GPU همیشه با Boost Clock اعلام‌شده کار می‌کند؟

خیر. فرکانس واقعی به دما، محدودیت توان،
ولتاژ، نوع بار کاری، خنک‌کننده و تنظیمات
سازنده بستگی دارد.

Sustained Clock چیست؟

Sustained Clock فرکانسی است که GPU می‌تواند
در یک بار کاری طولانی بدون افت شدید حفظ کند.
این معیار برای رندر، هوش مصنوعی و شبیه‌سازی
بسیار مهم است.

Effective Clock چه تفاوتی با Clock معمولی دارد؟

Clock معمولی نقطه فرکانسی انتخاب‌شده را نشان
می‌دهد، اما Effective Clock میزان فعالیت
واقعی هسته را با درنظرگرفتن توقف‌ها و چرخه‌های
بدون کار مفید منعکس می‌کند.

Memory Clock چیست؟

Memory Clock فرکانس کاری حافظه گرافیکی است
و همراه با نوع حافظه و عرض باس، پهنای باند
VRAM را تعیین می‌کند.

تفاوت Clock واقعی حافظه و نرخ مؤثر چیست؟

Clock واقعی فرکانس فیزیکی مدار حافظه است،
اما نرخ مؤثر تعداد انتقال‌های قابل انجام
در هر ثانیه را با درنظرگرفتن فناوری انتقال
داده نشان می‌دهد.

آیا Memory Clock بالاتر همیشه پهنای باند بیشتری دارد؟

فقط در صورت ثابت‌بودن عرض باس و نوع حافظه.
کارت دارای حافظه سریع‌تر اما باس باریک‌تر
ممکن است پهنای باند کمتری داشته باشد.

ولتاژ GPU چه نقشی دارد؟

ولتاژ انرژی لازم برای تغییر وضعیت
ترانزیستورها را فراهم می‌کند. فرکانس‌های
بالاتر معمولاً به ولتاژ بیشتری برای حفظ
پایداری نیاز دارند.

چرا افزایش ولتاژ دمای GPU را بالا می‌برد؟

ولتاژ بیشتر معمولاً توان مصرفی و گرمای
تولیدشده را افزایش می‌دهد و فشار بیشتری
بر تراشه و مدار VRM وارد می‌کند.

منحنی Voltage/Frequency چیست؟

مجموعه‌ای از نقاط ولتاژ و فرکانس است که GPU
بر اساس بار کاری، توان و دما از میان آن‌ها
نقطه مناسب را انتخاب می‌کند.

توان مصرفی GPU شامل چه بخش‌هایی می‌شود؟

هسته GPU، VRAM، کنترل‌کننده حافظه، واحدهای
رسانه، مدار VRM، فن‌ها و سایر اجزای برد
همگی بخشی از توان کارت را مصرف می‌کنند.

تفاوت TDP، TGP و TBP چیست؟

TDP معمولاً شاخص طراحی حرارتی است، TGP
توان زیرسیستم گرافیکی را بیان می‌کند و
TBP به توان کل برد نزدیک‌تر است. تعریف دقیق
هر اصطلاح به سازنده وابسته است.

آیا TDP همان مصرف واقعی برق است؟

لزوماً خیر. TDP اغلب برای طراحی خنک‌کننده
استفاده می‌شود و ممکن است با مصرف لحظه‌ای
یا حداکثر توان واقعی برابر نباشد.

Power Limit چیست؟

Power Limit سقف توانی است که GPU اجازه دارد
در یک بازه مشخص مصرف کند. رسیدن به این سقف
می‌تواند باعث کاهش فرکانس شود.

آیا افزایش Power Limit همیشه عملکرد را بیشتر می‌کند؟

خیر. اگر محدودیت اصلی دما، ولتاژ، حافظه یا
خنک‌کننده باشد، افزایش Power Limit ممکن است
فقط مصرف برق و گرما را بیشتر کند.

کاهش Power Limit چه فایده‌ای دارد؟

می‌تواند دما، صدای فن و مصرف انرژی را کاهش
دهد. در بعضی GPUها افت عملکرد محدود است،
زیرا بخش پایانی منحنی فرکانس بهره‌وری کمی دارد.

Power Throttling چیست؟

زمانی رخ می‌دهد که GPU برای باقی‌ماندن در
محدوده Power Limit، فرکانس یا ولتاژ خود را
کاهش دهد.

Thermal Throttling چیست؟

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

چگونه Power Throttling را از Thermal Throttling تشخیص دهیم؟

باید هم‌زمان دما، توان، فرکانس و دلیل
محدودیت ثبت‌شده توسط ابزار مانیتورینگ بررسی
شود. دمای مناسب همراه با افت Clock معمولاً
می‌تواند نشانه محدودیت توان باشد.

Hotspot Temperature چیست؟

بالاترین دمای ثبت‌شده میان حسگرهای داخلی
سطح تراشه GPU است و ممکن است از دمای عمومی
Core بیشتر باشد.

Memory Junction Temperature چیست؟

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

آیا دمای پایین همیشه به معنی عملکرد بهتر است؟

خیر. ممکن است GPU دمای پایینی داشته باشد
اما توسط Power Limit، ولتاژ یا تنظیمات
Firmware محدود شده باشد.

خنک‌کننده بهتر چه اثری بر عملکرد دارد؟

خنک‌کننده بهتر می‌تواند دما را پایین نگه
دارد، Thermal Throttling را کاهش دهد و
فرکانس پایدار بالاتری ایجاد کند.

چرا دو لپ‌تاپ با GPU یکسان عملکرد متفاوتی دارند؟

زیرا TGP، Power Limit، خنک‌کننده، BIOS،
توان آداپتور، مصرف CPU و پروفایل عملکرد
آن‌ها ممکن است متفاوت باشد.

NVIDIA Dynamic Boost چیست؟

قابلیتی است که در بعضی لپ‌تاپ‌ها توان را
بر اساس نوع بار کاری به‌صورت پویا میان CPU
و GPU تقسیم می‌کند.

P-State چیست؟

یک حالت داخلی عملکرد و مصرف انرژی است که
محدوده فرکانس، ولتاژ و فعالیت واحدهای GPU
را مشخص می‌کند.

Clock Gating و Power Gating چه تفاوتی دارند؟

Clock Gating سیگنال Clock را در بخش
بلااستفاده متوقف می‌کند، اما Power Gating
جریان برق آن بخش را نیز تا حد زیادی قطع
می‌کند.

چرا مصرف Idle با چند مانیتور افزایش پیدا می‌کند؟

وضوح بالا، نرخ تازه‌سازی زیاد و چند خروجی
تصویر ممکن است Display Engine و Memory
Clock را فعال‌تر نگه دارند.

Overclocking چیست؟

افزایش فرکانس هسته یا حافظه نسبت به تنظیمات
پیش‌فرض سازنده با هدف افزایش عملکرد است.

نشانه‌های اورکلاک ناپایدار چیست؟

Artifact، Crash، ریست درایور، هنگ سیستم،
افت غیرعادی عملکرد و نتایج محاسباتی اشتباه
از نشانه‌های احتمالی هستند.

آیا نبود Crash به معنی پایداری کامل اورکلاک است؟

خیر. در برنامه‌های محاسباتی ممکن است GPU
بدون توقف، نتیجه اشتباه تولید کند. صحت
خروجی نیز باید بررسی شود.

Undervolting چیست؟

کاهش ولتاژ GPU در یک فرکانس مشخص با هدف
کاهش مصرف، دما و صدای فن است.

آیا Undervolting باعث افت عملکرد می‌شود؟

در تنظیم مناسب ممکن است افت عملکرد بسیار
کم باشد یا حتی به دلیل حفظ بهتر Sustained
Clock، عملکرد پایدار بهبود پیدا کند.

تفاوت Undervolting و کاهش Power Limit چیست؟

Undervolting ولتاژ لازم برای یک فرکانس را
کاهش می‌دهد، اما کاهش Power Limit سقف توان
کلی قابل‌مصرف GPU را پایین می‌آورد.

Performance per Watt چیست؟

مقدار عملکردی است که GPU در برابر هر وات
مصرف انرژی ارائه می‌دهد و یکی از معیارهای
مهم بهره‌وری معماری است.

آیا کارت‌های حرفه‌ای همیشه توان کمتری مصرف می‌کنند؟

خیر. کارت حرفه‌ای ممکن است توان زیادی مصرف
کند، اما معمولاً برای پایداری، بار طولانی
و عملکرد یکنواخت تنظیم شده است.

چرا کارت‌های Quadro قدیمی هنوز برای بعضی کارها مناسب‌اند؟

درایور حرفه‌ای، مصرف کنترل‌شده و سازگاری
با نرم‌افزارهای CAD می‌تواند آن‌ها را برای
پروژه‌های سبک و متوسط قابل استفاده نگه دارد.

هنگام خرید لپ‌تاپ استوک چه چیزی مهم‌تر از Boost Clock است؟

فرکانس پایدار زیر بار، دما، Power Limit،
سلامت خنک‌کننده، آداپتور و عملکرد هم‌زمان
CPU و GPU اهمیت بیشتری دارند.

آداپتور غیراصلی چه اثری بر GPU لپ‌تاپ دارد؟

ممکن است توان کافی تأمین نکند یا توسط BIOS
شناسایی نشود و باعث محدودشدن فرکانس CPU و
GPU شود.


فصل موتورهای ویدئویی GPU

موتورهای Encode و Decode در کارت گرافیک؛
NVENC، NVDEC، VCN، Quick Sync و Video Core Next

کارت گرافیک فقط برای بازی، رندر سه‌بعدی و محاسبات
موازی استفاده نمی‌شود. بسیاری از GPUها دارای
موتورهای سخت‌افزاری اختصاصی برای رمزگشایی، رمزگذاری،
تبدیل و پردازش ویدئو هستند که می‌توانند بدون درگیرکردن
کامل هسته‌های Shader، فایل‌های ویدئویی را پردازش کنند.

فهرست فصل موتورهای Encode و Decode در GPU
بخش عنوان موضوع اصلی سطح مطالعه
۱
موتور ویدئویی GPU چیست؟
آشنایی با واحدهای اختصاصی پردازش ویدئو
مقدماتی
۲
تفاوت Encode و Decode
رمزگذاری و رمزگشایی فایل‌های ویدئویی
مقدماتی
۳
پردازش سخت‌افزاری و نرم‌افزاری
مقایسه موتور اختصاصی GPU با CPU و Shader
مقدماتی
۴
کدک و Container چیست؟
تفاوت Codec، Format و Container
مقدماتی
۵
H.264 یا AVC
رایج‌ترین کدک ویدئویی و پشتیبانی GPU
مقدماتی
۶
H.265 یا HEVC
فشرده‌سازی پیشرفته‌تر و نیاز سخت‌افزاری
متوسط
۷
کدک AV1
Decode و Encode نسل جدید AV1
متوسط
۸
کدک VP9
پخش ویدئوهای وب و سرویس‌های آنلاین
متوسط
۹
Chroma Subsampling
تفاوت 4:2:0، 4:2:2 و 4:4:4
پیشرفته
۱۰
عمق رنگ ۸، ۱۰ و ۱۲ بیت
دقت رنگ، HDR و پشتیبانی سخت‌افزاری
متوسط
۱۱
وضوح و Frame Rate
پشتیبانی 1080p، 4K، 8K و نرخ فریم بالا
متوسط
۱۲
NVIDIA NVENC
موتور رمزگذاری سخت‌افزاری NVIDIA
متوسط
۱۳
NVIDIA NVDEC
موتور رمزگشایی ویدئویی NVIDIA
متوسط
۱۴
AMD VCN
موتور Video Core Next در Radeon و Radeon Pro
متوسط
۱۵
Intel Quick Sync Video
پردازش ویدئو در گرافیک مجتمع و Arc
متوسط
۱۶ مقایسه کیفیت Encoderها کیفیت تصویر، Bitrate و نسل موتور ویدئو
پیشرفته
۱۷ Bitrate و Rate Control CBR، VBR، CQ، CQP و کنترل کیفیت
پیشرفته
۱۸ Preset، Profile و Level تنظیم سرعت، کیفیت و سازگاری خروجی
پیشرفته
۱۹
B-Frame و Reference Frame
ساختار فریم و افزایش راندمان فشرده‌سازی
پیشرفته
۲۰
Sessionهای هم‌زمان Encode و Decode
پردازش چند جریان ویدئویی به‌صورت هم‌زمان
پیشرفته
۲۱
نقش VRAM در پردازش ویدئو
Frame Buffer، Cache و نگهداری پروژه
متوسط
۲۲ اثر موتور ویدئو بر مصرف CPU کاهش بار پردازنده مرکزی هنگام پخش و Export
مقدماتی
۲۳ مصرف انرژی موتور ویدئو تفاوت توان Dedicated Engine و Shader
متوسط
۲۴ Premiere Pro Playback، Export و Hardware Encoding
مقدماتی
۲۵ DaVinci Resolve Decode، Effects، Color و Deliver
متوسط
۲۶ OBS و استریم رمزگذاری زنده با فشار کمتر بر CPU
مقدماتی
۲۷ HandBrake و تبدیل ویدئو Transcoding سخت‌افزاری و نرم‌افزاری
متوسط
۲۸ پخش ویدئو در مرورگر YouTube، Streaming و Hardware Acceleration
مقدماتی
۲۹ موتور ویدئو در Quadro و کارت‌های حرفه‌ای پایداری، چند نمایشگر و تولید محتوای حرفه‌ای
متوسط
۳۰ موتور ویدئو در GPUهای قدیمی Quadro K، M، P، GTX و Radeon قدیمی
متوسط
۳۱ راهنمای خرید برای تدوین و استریم انتخاب GPU بر اساس Codec، VRAM و نرم‌افزار
مقدماتی
۳۲
اشتباهات رایج
خطاهای متداول در تشخیص پشتیبانی و کیفیت
مقدماتی
۳۳
خلاصه فصل
مرور نکات مهم موتورهای ویدئویی
مقدماتی
۳۴
سؤالات متداول
پاسخ به پرسش‌های رایج کاربران
مقدماتی

موتور ویدئویی GPU چیست؟

موتور ویدئویی بخشی اختصاصی در پردازنده گرافیکی
است که برای رمزگذاری، رمزگشایی و پردازش برخی
فرمت‌های ویدئویی طراحی شده است.

این واحدها برخلاف CUDA Core، Stream Processor،
Xe Core یا Shader Core، برای اجرای محاسبات عمومی
ساخته نشده‌اند و وظایف مشخص مربوط به ویدئو را با
مدارهای ثابت و بهینه انجام می‌دهند.

استفاده از موتور اختصاصی می‌تواند فشار واردشده
بر CPU و هسته‌های عمومی GPU را کاهش دهد و در
پخش، ضبط، استریم و تبدیل ویدئو مصرف انرژی کمتری
ایجاد کند.

مسیر پردازش ویدئو در GPU

فایل فشرده ویدئویی ابتدا از حافظه سیستم یا فضای
ذخیره‌سازی خوانده می‌شود و سپس برای Decode به
موتور ویدئویی ارسال می‌شود.

فریم‌های رمزگشایی‌شده ممکن است داخل VRAM قرار
بگیرند تا Shaderها، موتور نمایشگر یا نرم‌افزار
تدوین آن‌ها را پردازش کنند.

در مرحله خروجی نیز فریم پردازش‌شده می‌تواند به
موتور Encode فرستاده شود تا به یک جریان ویدئویی
فشرده تبدیل شود.

اجزای اصلی زیرسیستم ویدئویی GPU

واحدهای مؤثر در پردازش و نمایش ویدئو
واحد وظیفه اصلی نمونه کاربرد
Decode Engine تبدیل جریان فشرده به فریم قابل پردازش پخش فیلم و Timeline تدوین
Encode Engine تبدیل فریم خام یا پردازش‌شده به فایل فشرده Export، ضبط صفحه و استریم
Video Processing Unit Scaling، Deinterlacing و تبدیل رنگ پخش و تبدیل ویدئو
Shader Core اجرای افکت، تصحیح رنگ و پردازش عمومی تصویر Premiere Pro و DaVinci Resolve
Display Engine ارسال تصویر نهایی به نمایشگر مانیتور، تلویزیون و خروجی HDR
VRAM نگهداری Frame Buffer و داده‌های پروژه ویدئوی 4K، 8K و پروژه چندلایه

تفاوت Encode و Decode چیست؟

Decode فرایند بازکردن داده فشرده ویدئو و تبدیل آن
به فریم‌هایی است که سیستم بتواند نمایش یا پردازش
کند.

Encode فرایند معکوس است؛ یعنی فریم‌های خام یا
پردازش‌شده با استفاده از یک کدک به جریان فشرده
ویدئویی تبدیل می‌شوند.

مقایسه رمزگذاری و رمزگشایی ویدئو
معیار Decode Encode
ورودی جریان ویدئویی فشرده فریم خام یا پردازش‌شده
خروجی فریم قابل نمایش یا ویرایش فایل یا Stream فشرده
کاربرد پخش، Preview و Timeline Export، ضبط و استریم
فشار اصلی بازسازی فریم از داده فشرده تحلیل فریم و کاهش حجم
حساسیت به کیفیت باید تصویر کدگذاری‌شده را صحیح بازسازی کند میان کیفیت، حجم و سرعت تعادل ایجاد می‌کند
نمونه پخش فایل H.264 خروجی H.264 برای YouTube

Transcoding چیست؟

Transcoding به تبدیل یک فایل ویدئویی از یک کدک،
رزولوشن، Bitrate یا فرمت به حالت دیگر گفته می‌شود.

این فرایند معمولاً شامل Decode فایل ورودی،
پردازش فریم‌ها و سپس Encode خروجی است.

برای مثال، تبدیل یک فایل 4K HEVC به ویدئوی 1080p
H.264 شامل رمزگشایی HEVC، کاهش وضوح و رمزگذاری
مجدد با H.264 است.

تفاوت پردازش سخت‌افزاری و نرم‌افزاری ویدئو

در پردازش نرم‌افزاری، CPU یا هسته‌های عمومی GPU
بیشتر مراحل Encode و Decode را با اجرای دستورهای
قابل برنامه‌ریزی انجام می‌دهند.

در پردازش سخت‌افزاری، مدار اختصاصی ویدئو وظیفه
مشخصی را با مصرف انرژی و تأخیر کمتر انجام می‌دهد.

موتور سخت‌افزاری معمولاً سریع‌تر و کم‌مصرف‌تر است،
اما کیفیت، قابلیت تنظیم و پشتیبانی کدک آن به نسل
سخت‌افزار وابسته است.

مقایسه پردازش سخت‌افزاری و نرم‌افزاری ویدئو
معیار Hardware Processing Software Processing
واحد پردازشی موتور اختصاصی Encode یا Decode CPU یا واحدهای عمومی Compute
سرعت معمولاً بسیار بالا وابسته به توان CPU و تنظیمات
مصرف انرژی معمولاً کمتر معمولاً بیشتر
انعطاف تنظیمات محدود به قابلیت موتور معمولاً بیشتر
کیفیت در Bitrate بسیار پایین وابسته به نسل Encoder در تنظیمات کند می‌تواند بهتر باشد
فشار بر CPU کمتر بیشتر
کاربرد مناسب استریم، Preview و Export سریع آرشیو با کیفیت بالا و تنظیمات تخصصی

تفاوت موتور اختصاصی ویدئو با Shader Core

Shader Coreها واحدهای عمومی‌تر و قابل برنامه‌ریزی
هستند و می‌توانند افکت، Scaling، Denoising،
Color Grading، AI Upscaling و بسیاری از عملیات
تصویری را انجام دهند.

موتور اختصاصی ویدئو برای مجموعه محدودی از عملیات
Codec طراحی شده و همان کار را با بازده بیشتری
انجام می‌دهد.

در یک پروژه تدوین، هر دو نوع واحد ممکن است هم‌زمان
فعال باشند؛ موتور Decode فایل را باز می‌کند،
Shaderها افکت‌ها را اجرا می‌کنند و موتور Encode
خروجی را فشرده می‌کند.

تقسیم وظایف میان موتور ویدئو و Shaderها
وظیفه واحد مناسب‌تر توضیح
H.264 Decode Decode Engine بازکردن جریان فشرده
Color Grading Shader یا Compute پردازش محاسباتی پیکسل‌ها
Noise Reduction Shader، Compute یا AI Unit تحلیل مکانی و زمانی فریم‌ها
H.265 Encode Encode Engine تولید جریان فشرده خروجی
AI Upscaling Matrix Unit یا Shader بازسازی تصویر با مدل هوش مصنوعی
نمایش تصویر Display Engine ارسال فریم به مانیتور

چرا نسل GPU در پردازش ویدئو مهم است؟

پشتیبانی موتور ویدئویی به نسل معماری وابسته است.
یک GPU قدیمی ممکن است توان سه‌بعدی کافی داشته باشد،
اما فاقد Decode یا Encode سخت‌افزاری یک کدک جدید
مانند HEVC ده‌بیتی یا AV1 باشد.

در این شرایط نرم‌افزار مجبور می‌شود از CPU یا
Shaderها استفاده کند که می‌تواند مصرف انرژی،
دما و فشار سیستم را افزایش دهد.

این موضوع در لپ‌تاپ‌های قدیمی مجهز به Quadro K،
Quadro M، GTX 800M، GTX 900M و گرافیک‌های مجتمع
قدیمی اهمیت زیادی دارد.

Codec و Container چیست؟

در فایل‌های ویدئویی، Codec و Container دو مفهوم
متفاوت هستند که اغلب با یکدیگر اشتباه گرفته می‌شوند.

Codec روشی است که برای فشرده‌سازی و بازسازی داده‌های
صوتی یا تصویری استفاده می‌شود.

Container قالبی است که تصویر، صدا، زیرنویس،
Metadata و سایر داده‌ها را در یک فایل واحد نگهداری
می‌کند.

تفاوت Codec و Container

مقایسه Codec و Container در فایل‌های ویدئویی
معیار Codec Container
وظیفه فشرده‌سازی و بازسازی تصویر یا صدا نگهداری چند جریان رسانه‌ای در یک فایل
نمونه H.264، HEVC، AV1 و VP9 MP4، MKV، MOV و WebM
اثر بر حجم فایل بسیار زیاد معمولاً محدود
اثر بر کیفیت مستقیم غیرمستقیم
ارتباط با GPU موتور ویدئویی باید Codec را پشتیبانی کند معمولاً توسط نرم‌افزار مدیریت می‌شود
پسوند فایل الزاماً از روی پسوند مشخص نمی‌شود معمولاً پسوند فایل را تعیین می‌کند

Container چه اطلاعاتی را نگهداری می‌کند؟

یک Container می‌تواند علاوه بر جریان تصویر،
چندین Track صوتی، زیرنویس، Chapter، تصویر بندانگشتی
و Metadata را نیز نگهداری کند.

Containerهای رایج ویدئویی

مقایسه قالب‌های متداول فایل ویدئویی
Container پسوند رایج کاربرد ویژگی
MP4 .mp4 وب، موبایل، پخش و انتشار عمومی سازگاری بسیار گسترده
MKV .mkv آرشیو، فیلم و چند Track انعطاف‌پذیری بالا
MOV .mov تدوین و اکوسیستم Apple مناسب Workflowهای حرفه‌ای
WebM .webm پخش ویدئو در وب رایج با VP9، AV1 و Opus
AVI .avi نرم‌افزارها و آرشیوهای قدیمی ساختار قدیمی‌تر و انعطاف کمتر
MPEG-TS .ts پخش زنده و تلویزیون دیجیتال مقاوم‌تر در برابر قطع جریان

آیا دو فایل MP4 می‌توانند Codec متفاوتی داشته باشند؟

بله. پسوند MP4 فقط Container را نشان می‌دهد و
داخل آن می‌توان از Codecهای مختلفی مانند H.264،
HEVC یا AV1 استفاده کرد.

بنابراین ممکن است یک سیستم یک فایل MP4 را به‌راحتی
پخش کند، اما فایل MP4 دیگری را به دلیل Codec،
Bit Depth یا Profile متفاوت نتواند به‌صورت
سخت‌افزاری Decode کند.

نمونه فایل‌هایی با Container یکسان و Codec متفاوت
فایل Container Video Codec وضعیت احتمالی پشتیبانی
File A MP4 H.264 8-bit سازگاری بسیار گسترده
File B MP4 HEVC 10-bit نیازمند سخت‌افزار و نرم‌افزار جدیدتر
File C MP4 AV1 پشتیبانی سخت‌افزاری وابسته به نسل GPU

تفاوت Codecهای Lossy و Lossless

Codecهای Lossy بخشی از اطلاعات تصویر را برای
کاهش بیشتر حجم حذف می‌کنند.

Codecهای Lossless تصویر را به‌گونه‌ای فشرده می‌کنند
که پس از Decode، داده اصلی بدون کاهش اطلاعات
بازسازی شود.

مقایسه فشرده‌سازی با اتلاف و بدون اتلاف
معیار Lossy Lossless
حذف اطلاعات دارد ندارد
حجم فایل کمتر بیشتر
کاربرد استریم، انتشار و مصرف عمومی آرشیو، Master و پردازش تخصصی
نمونه H.264، HEVC، AV1 و VP9 FFV1 و بعضی حالت‌های تخصصی
پشتیبانی موتور سخت‌افزاری گسترده‌تر معمولاً محدودتر

تفاوت فشرده‌سازی Intraframe و Interframe

در فشرده‌سازی Intraframe هر فریم تا حد زیادی مستقل
از فریم‌های دیگر ذخیره می‌شود.

در فشرده‌سازی Interframe، Codec تفاوت میان فریم‌های
متوالی را نیز بررسی می‌کند و برای کاهش حجم از
ارتباط زمانی میان آن‌ها استفاده می‌کند.

مقایسه Codecهای Intraframe و Interframe
معیار Intraframe Interframe
وابستگی فریم‌ها کمتر بیشتر
جست‌وجو در Timeline معمولاً آسان‌تر ممکن است سنگین‌تر باشد
حجم فایل معمولاً بیشتر معمولاً کمتر
کاربرد تدوین و تولید حرفه‌ای انتشار، استریم و آرشیو فشرده
فشار Decode معمولاً قابل‌پیش‌بینی‌تر وابسته به ساختار GOP

پشتیبانی یک Codec به چه عواملی وابسته است؟

مشاهده نام یک Codec در مشخصات GPU به‌تنهایی برای
اطمینان از پشتیبانی کامل کافی نیست.

ممکن است موتور ویدئویی فقط Decode، فقط Encode یا
مجموعه محدودی از Profileها، Bit Depthها و وضوح‌ها
را پشتیبانی کند.

موارد لازم برای بررسی پشتیبانی سخت‌افزاری Codec
مورد پرسش مهم
Encode یا Decode موتور فقط فایل را پخش می‌کند یا خروجی نیز می‌سازد؟
Profile کدام قابلیت‌های Codec پشتیبانی می‌شوند؟
Level حداکثر وضوح، Bitrate و Frame Rate چیست؟
Bit Depth فقط 8-bit یا 10-bit و 12-bit نیز پشتیبانی می‌شود؟
Chroma Subsampling 4:2:0، 4:2:2 یا 4:4:4 قابل پردازش است؟
Resolution حداکثر وضوح قابل Encode یا Decode چقدر است؟
Frame Rate موتور چند فریم در ثانیه را پردازش می‌کند؟
نرم‌افزار برنامه موردنظر از API موتور ویدئو استفاده می‌کند؟
درایور قابلیت در نسخه نصب‌شده درایور فعال است؟

H.264 یا AVC چیست؟

H.264 که با نام AVC یا Advanced Video Coding نیز
شناخته می‌شود، یکی از رایج‌ترین Codecهای ویدئویی
در جهان است.

این Codec در فایل‌های MP4، ضبط دوربین، استریم،
ویدئوهای آموزشی، شبکه‌های اجتماعی، تماس تصویری،
تلویزیون و خروجی نرم‌افزارهای تدوین استفاده می‌شود.

پشتیبانی سخت‌افزاری H.264 در بسیاری از GPUهای
قدیمی و جدید وجود دارد؛ به همین دلیل معمولاً
سازگاری گسترده‌تری نسبت به Codecهای جدیدتر دارد.

H.264 در چه کاربردهایی استفاده می‌شود؟

کاربردهای رایج Codec H.264
کاربرد دلیل استفاده اهمیت شتاب‌دهی سخت‌افزاری
استریم زنده سازگاری گسترده با سرویس‌ها و دستگاه‌ها بسیار زیاد
ضبط صفحه حجم مناسب و پخش آسان زیاد
خروجی تدوین مناسب انتشار عمومی بسیار زیاد
دوربین‌های نظارتی کاهش حجم ذخیره‌سازی زیاد
تماس تصویری تأخیر کم و پشتیبانی گسترده زیاد
ویدئوی آموزشی قابل پخش روی دستگاه‌های قدیمی‌تر متوسط
شبکه‌های اجتماعی سازگاری مناسب با پلتفرم‌های مختلف زیاد

Hardware Decode در H.264

هنگام پخش فایل H.264، موتور Decode می‌تواند بخش
اصلی رمزگشایی جریان ویدئویی را به‌جای CPU انجام
دهد.

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

اگر Decode سخت‌افزاری در دسترس نباشد، نرم‌افزار
ممکن است از CPU یا Shaderهای GPU استفاده کند.

Hardware Encode در H.264

موتور Encode می‌تواند فریم‌های خام یا پردازش‌شده
را به جریان H.264 تبدیل کند.

این قابلیت در ضبط بازی، استریم زنده، Export سریع،
تبدیل ویدئو و سیستم‌های نظارتی کاربرد دارد.

Encode سخت‌افزاری معمولاً بسیار سریع‌تر و
کم‌مصرف‌تر از Encode نرم‌افزاری روی CPU است؛
اما کیفیت نهایی در Bitrate یکسان به نسل Encoder،
تنظیمات نرم‌افزار و نوع محتوا بستگی دارد.

Profileهای مهم H.264

Profile مجموعه‌ای از قابلیت‌های Codec را مشخص
می‌کند. دستگاه یا موتور ویدئویی ممکن است فقط
بعضی Profileهای H.264 را پشتیبانی کند.

Profileهای متداول H.264
Profile ویژگی عمومی کاربرد رایج
Baseline ساختار ساده‌تر و سازگاری بالا دستگاه‌های قدیمی و ارتباط زنده
Main فشرده‌سازی بهتر از Baseline پخش عمومی و Broadcast
High راندمان و کیفیت بهتر Blu-ray، وب و خروجی باکیفیت
High 10 پشتیبانی از عمق رنگ بیشتر کاربردهای تخصصی
High 4:2:2 اطلاعات رنگی بیشتر تولید حرفه‌ای و Broadcast
High 4:4:4 حفظ کامل‌تر اطلاعات رنگ پردازش و آرشیو تخصصی

Level در H.264 چه چیزی را مشخص می‌کند؟

Level محدودیت‌هایی مانند حداکثر وضوح، نرخ فریم،
Bitrate، اندازه Frame Buffer و پیچیدگی جریان
ویدئویی را تعیین می‌کند.

ممکن است یک GPU Codec و Profile مشخصی را پشتیبانی
کند، اما در وضوح یا Frame Rate بسیار بالا از
محدودیت موتور سخت‌افزاری عبور کند.

مفهوم عمومی Level در H.264
Level پایین‌تر Level بالاتر
وضوح پایین‌تر وضوح بالاتر
نرخ فریم محدودتر نرخ فریم بیشتر
Bitrate پایین‌تر Bitrate بیشتر
نیاز پردازشی کمتر نیاز پردازشی و حافظه بیشتر

عمق رنگ و Chroma در H.264

رایج‌ترین نوع H.264 برای انتشار عمومی و پخش
سخت‌افزاری، ویدئوی ۸ بیت با Chroma Subsampling
برابر 4:2:0 است.

حالت‌های ۱۰ بیت، 4:2:2 و 4:4:4 نیز در استاندارد
وجود دارند، اما پشتیبانی سخت‌افزاری آن‌ها بسیار
محدودتر است.

وضعیت عمومی حالت‌های مختلف H.264
حالت کاربرد سازگاری سخت‌افزاری عمومی
8-bit 4:2:0 انتشار، وب، استریم و پخش عمومی بسیار گسترده
10-bit 4:2:0 کاربردهای تخصصی‌تر محدودتر
8-bit 4:2:2 Broadcast و تدوین محدود
10-bit 4:2:2 تولید حرفه‌ای بسیار محدودتر
4:4:4 حفظ اطلاعات کامل‌تر رنگ وابسته به محصول و نرم‌افزار

GOP در H.264 چیست؟

GOP یا Group of Pictures مجموعه‌ای از فریم‌های
ویدئو است که از فریم‌های مستقل و وابسته تشکیل
می‌شود.

ساختار GOP روی کیفیت، حجم، تأخیر، امکان جابه‌جایی
در Timeline و مقاومت جریان در برابر خطا اثر دارد.

تفاوت I-Frame، P-Frame و B-Frame

مقایسه انواع فریم در H.264
نوع فریم ساختار حجم کاربرد
I-Frame مستقل از سایر فریم‌ها بیشتر شروع GOP و جابه‌جایی سریع
P-Frame وابسته به فریم‌های قبلی کمتر کاهش حجم جریان
B-Frame وابسته به فریم‌های قبلی و بعدی معمولاً کمتر افزایش راندمان فشرده‌سازی

تأخیر Encode در H.264

تنظیمات فشرده‌سازی می‌توانند تأخیر Encode را
افزایش یا کاهش دهند.

استفاده از B-Frameهای بیشتر، Lookahead و تحلیل
پیچیده‌تر معمولاً کیفیت یا راندمان فشرده‌سازی را
بهتر می‌کند، اما تأخیر بیشتری ایجاد می‌کند.

برای استریم زنده، تماس تصویری و Remote Desktop
معمولاً تنظیمات Low-Latency اهمیت بیشتری دارند.

تفاوت تنظیمات کم‌تأخیر و باکیفیت‌تر H.264
معیار Low-Latency High-Quality
تأخیر کمتر بیشتر
تحلیل فریم محدودتر گسترده‌تر
B-Frame کمتر یا غیرفعال بیشتر
کاربرد استریم زنده و تماس تصویری Export و آرشیو

پشتیبانی H.264 در GPUهای قدیمی

H.264 به دلیل قدمت و گسترش زیاد، در بسیاری از
GPUهای قدیمی نیز دارای شتاب‌دهی سخت‌افزاری است.

بااین‌حال، نسل‌های قدیمی‌تر ممکن است در وضوح بالا،
نرخ فریم زیاد، تعداد جریان هم‌زمان یا بعضی
Profileها محدود باشند.

وضعیت عمومی H.264 در چند خانواده قدیمی GPU
خانواده Decode H.264 Encode H.264 نکته
Quadro K Series معمولاً موجود وابسته به مدل و تراشه بررسی نسل دقیق موتور ویدئو ضروری است
Quadro M Series گسترده‌تر در بسیاری مدل‌ها موجود محدودیت کیفیت و قابلیت به نسل وابسته است
Quadro P Series مناسب‌تر برای وضوح و نرخ فریم بالاتر معمولاً پیشرفته‌تر مناسب‌تر برای تدوین و استریم
GTX 800M و 900M معمولاً قابل استفاده وابسته به تراشه دقیق نام سری به‌تنهایی کافی نیست
Intel HD قدیمی در بسیاری نسل‌ها موجود وابسته به نسل Quick Sync درایور و نرم‌افزار اهمیت زیادی دارند

H.265 یا HEVC چیست؟

H.265 که با نام HEVC یا
High Efficiency Video Coding
نیز شناخته می‌شود، نسل بعدی H.264 است و با هدف
کاهش بیشتر حجم فایل ویدئویی بدون افت محسوس کیفیت
توسعه یافته است.

این Codec برای ویدئوهای 4K، 8K، HDR، دوربین‌های
حرفه‌ای، فیلم‌های با Bitrate بالا و سرویس‌های
استریم مدرن بسیار رایج است.

الگوریتم‌های پیچیده‌تر HEVC باعث می‌شوند عملیات
Encode و Decode نسبت به H.264 به توان پردازشی
بیشتری نیاز داشته باشد؛ به همین دلیل وجود موتور
سخت‌افزاری اختصاصی اهمیت بیشتری پیدا می‌کند.

تفاوت H.264 و H.265

مقایسه H.264 و HEVC
معیار H.264 H.265 (HEVC)
سال معرفی قدیمی‌تر جدیدتر
راندمان فشرده‌سازی خوب بهتر
حجم فایل بیشتر کمتر
نیاز پردازشی کمتر بیشتر
مناسب برای استفاده عمومی و استریم 4K، HDR و آرشیو باکیفیت
اهمیت Decode سخت‌افزاری زیاد بسیار زیاد
سازگاری دستگاه‌ها بسیار گسترده وابسته به نسل سخت‌افزار

چرا HEVC پردازش سنگین‌تری دارد؟

HEVC برای کاهش بیشتر حجم فایل، از ساختارهای
پیشرفته‌تر، بلوک‌های متغیر، پیش‌بینی دقیق‌تر،
تحلیل حرکت پیچیده‌تر و روش‌های بهینه‌تری برای
کدگذاری استفاده می‌کند.

این قابلیت‌ها باعث می‌شوند حجم فایل کاهش یابد،
اما Decode و Encode به محاسبات بیشتری نیاز داشته
باشند.

به همین دلیل لپ‌تاپ‌های قدیمی که موتور HEVC
ندارند، ممکن است هنگام پخش ویدئوهای 4K HEVC
مصرف CPU بسیار بالایی داشته باشند.

اهمیت Hardware Acceleration در HEVC

وجود موتور Decode سخت‌افزاری در HEVC اهمیت
بسیار بیشتری نسبت به H.264 دارد؛ زیرا Decode
نرم‌افزاری فایل‌های 4K یا HDR می‌تواند فشار
زیادی بر CPU وارد کند.

همچنین هنگام Export ویدئو، استفاده از موتور
Encode اختصاصی می‌تواند زمان خروجی گرفتن را
به‌طور محسوسی کاهش دهد.

قابلیت‌های مهم HEVC

ویژگی‌های مهم استاندارد HEVC
قابلیت اهمیت کاربرد
فشرده‌سازی بهتر کاهش حجم فایل آرشیو و استریم
پشتیبانی بهتر از 4K و 8K وضوح‌های بسیار بالا فیلم و تولید محتوا
HDR نمایش دامنه دینامیکی بیشتر تلویزیون و مانیتورهای HDR
10-bit و 12-bit افزایش دقت رنگ تدوین حرفه‌ای
Chromaهای مختلف انعطاف بیشتر در تولید محتوا Broadcast و Cinema
Bitrate پایین‌تر صرفه‌جویی در فضای ذخیره‌سازی سرویس‌های آنلاین

Profileهای مهم HEVC

مانند H.264، استاندارد HEVC نیز دارای Profileهای
مختلفی است و همه GPUها الزاماً از تمام آن‌ها
پشتیبانی نمی‌کنند.

Profileهای رایج HEVC
Profile ویژگی کاربرد
Main 8-bit استفاده عمومی
Main 10 10-bit HDR و تولید محتوا
Main Still Picture تصویر ثابت کاربردهای خاص

Level در HEVC چه چیزی را مشخص می‌کند؟

Level در HEVC محدودیت‌های فنی جریان ویدئویی را
مشخص می‌کند؛ از جمله حداکثر وضوح، نرخ فریم،
Bitrate، پیچیدگی Decode و ظرفیت پردازش موردنیاز.

ممکن است یک GPU از Codec HEVC و حتی Profile
موردنظر پشتیبانی کند، اما نتواند یک فایل با Level
بسیار بالا، وضوح 8K یا نرخ فریم سنگین را به‌صورت
سخت‌افزاری پردازش کند.

نقش Level در جریان HEVC
مشخصه Level پایین‌تر Level بالاتر
وضوح تصویر محدودتر بالاتر
نرخ فریم کمتر بیشتر
Bitrate پایین‌تر بالاتر
نیاز به حافظه کمتر بیشتر
فشار پردازشی سبک‌تر سنگین‌تر

تفاوت Main Tier و High Tier در HEVC

HEVC علاوه بر Profile و Level، از مفهوم Tier نیز
استفاده می‌کند.

Tier بیشتر به محدوده Bitrate مجاز مربوط است و
مشخص می‌کند جریان ویدئویی برای کاربرد عمومی یا
کاربردهای حرفه‌ای با Bitrate بالاتر طراحی شده است.

مقایسه Main Tier و High Tier
معیار Main Tier High Tier
Bitrate مجاز پایین‌تر بالاتر
کاربرد پخش و انتشار عمومی Broadcast و تولید حرفه‌ای
نیاز ذخیره‌سازی کمتر بیشتر
سازگاری سخت‌افزاری گسترده‌تر محدودتر و وابسته به دستگاه

پشتیبانی HEVC از عمق رنگ ۸، ۱۰ و ۱۲ بیت

HEVC می‌تواند ویدئو را با Bit Depthهای مختلف
ذخیره کند. افزایش عمق رنگ تعداد سطوح قابل نمایش
در هر کانال رنگی را بیشتر می‌کند.

ویدئوی ۱۰ بیت برای HDR، Color Grading و کاهش
Banding بسیار رایج است؛ اما Decode و Encode
سخت‌افزاری آن به نسل GPU وابسته است.

مقایسه عمق رنگ‌های مختلف در HEVC
عمق رنگ ویژگی کاربرد پشتیبانی سخت‌افزاری عمومی
8-bit سازگاری گسترده پخش و انتشار عمومی گسترده
10-bit رنگ دقیق‌تر و Banding کمتر HDR و تدوین حرفه‌ای وابسته به نسل جدیدتر GPU
12-bit دقت بسیار بالای رنگ Cinema و Workflow تخصصی محدودتر

پشتیبانی HEVC از 4:2:0، 4:2:2 و 4:4:4

بیشتر فایل‌های مصرف عمومی HEVC با Chroma
Subsampling برابر 4:2:0 تولید می‌شوند.

حالت‌های 4:2:2 و 4:4:4 اطلاعات رنگی بیشتری حفظ
می‌کنند و برای تدوین، Broadcast، Keying و تولید
حرفه‌ای مناسب‌تر هستند.

بااین‌حال، پشتیبانی سخت‌افزاری این حالت‌ها به‌ویژه
در Encode بسیار محدودتر از 4:2:0 است.

وضعیت عمومی Chroma در HEVC
Chroma میزان اطلاعات رنگ کاربرد پشتیبانی عمومی GPU
4:2:0 کمتر وب، استریم، فیلم و پخش عمومی بسیار گسترده
4:2:2 بیشتر دوربین حرفه‌ای و Broadcast محدودتر
4:4:4 کامل‌تر VFX، Keying و Mastering وابسته به GPU و نرم‌افزار

نقش HEVC در ویدئوی HDR

HEVC یکی از Codecهای اصلی برای ذخیره و انتشار
محتوای HDR است؛ زیرا از عمق رنگ بالاتر و Metadata
مرتبط با دامنه دینامیکی پشتیبانی می‌کند.

برای نمایش صحیح HDR، فقط Decode شدن ویدئو کافی
نیست. سیستم‌عامل، نرم‌افزار، درایور، Display
Engine، کابل و نمایشگر نیز باید از مسیر HDR
پشتیبانی کنند.

تفاوت پشتیبانی Decode و Encode در HEVC

معمولاً پشتیبانی سخت‌افزاری Decode یک Codec زودتر
و گسترده‌تر از Encode آن وارد GPUها می‌شود.

دلیل این موضوع آن است که پخش ویدئو برای کاربران
بیشتری ضروری است، درحالی‌که Encode سخت‌افزاری به
مدار پیچیده‌تر و قابلیت‌های بیشتری نیاز دارد.

مقایسه پشتیبانی سخت‌افزاری Decode و Encode HEVC
معیار HEVC Decode HEVC Encode
ورود به سخت‌افزار معمولاً زودتر معمولاً دیرتر
کاربرد پخش، Preview و Timeline Export، ضبط و Transcoding
نیاز به کیفیت تصمیم‌گیری کمتر بیشتر
پشتیبانی Profileهای حرفه‌ای محدود محدودتر
اهمیت نسل Encoder متوسط بسیار زیاد

اگر GPU از HEVC پشتیبانی نکند چه می‌شود؟

نرم‌افزار می‌تواند پردازش را به CPU یا Shaderهای
عمومی GPU منتقل کند.

این روش ممکن است برای فایل‌های سبک قابل‌قبول باشد،
اما در ویدئوهای 4K، 10-bit، HDR یا نرخ فریم بالا
فشار زیادی بر سیستم وارد می‌کند.

پیامدهای نبود شتاب‌دهی سخت‌افزاری HEVC
بخش پیامد احتمالی
CPU Usage افزایش شدید
مصرف انرژی بیشتر
دما و صدای فن افزایش
پخش ویدئو احتمال افت فریم
Timeline تدوین Scrubbing و Preview ضعیف‌تر
عمر باتری لپ‌تاپ کاهش

پشتیبانی HEVC در نسل‌های مختلف NVIDIA

قابلیت HEVC در محصولات NVIDIA به نسل دقیق موتور
NVDEC و NVENC وابسته است، نه فقط نام تجاری GeForce
یا Quadro.

بعضی GPUهای قدیمی ممکن است Decode محدود HEVC
داشته باشند، اما از Main 10، Encode یا وضوح‌های
بالاتر پشتیبانی نکنند.

وضعیت کلی HEVC در خانواده‌های NVIDIA
خانواده وضعیت عمومی نکته مهم
Kepler پشتیبانی محدود یا وابسته به مدل بررسی تراشه دقیق ضروری است
Maxwell نسل اول قابلیت‌های محدودتر همه مدل‌ها یکسان نیستند
Maxwell نسل دوم پشتیبانی HEVC گسترده‌تر Main 10 و Encode باید جداگانه بررسی شوند
Pascal مناسب‌تر برای HEVC و 4K پشتیبانی دقیق به تراشه وابسته است
Turing و جدیدتر کیفیت و قابلیت بهتر Encoder مناسب‌تر برای تدوین و استریم

پشتیبانی HEVC در AMD و Intel

AMD و Intel نیز در نسل‌های مختلف، قابلیت‌های HEVC
متفاوتی ارائه کرده‌اند.

در محصولات AMD باید نسل UVD، VCE یا VCN و در
محصولات Intel باید نسل Quick Sync و Media Engine
بررسی شود.

نکات بررسی HEVC در AMD و Intel
سازنده موتور مرتبط موارد قابل بررسی
AMD قدیمی UVD و VCE Decode، Encode و Bit Depth
AMD جدیدتر VCN HEVC، HDR و Sessionهای هم‌زمان
Intel قدیمی Quick Sync نسل‌های اولیه احتمال Decode محدود یا Hybrid
Intel جدیدتر Media Engine و Quick Sync Main 10، 4K و Encode سریع‌تر
Intel Arc Xe Media Engine HEVC و Codecهای جدیدتر

HEVC در تدوین و تولید حرفه‌ای

دوربین‌ها و تلفن‌های جدید ممکن است ویدئو را با
HEVC ده‌بیتی، HDR یا 4:2:2 ضبط کنند.

اگر موتور ویدئویی GPU این حالت دقیق را پشتیبانی
نکند، Timeline ممکن است کند شود؛ حتی اگر کارت
گرافیک قدرت سه‌بعدی بالایی داشته باشد.

در چنین شرایطی ساخت Proxy، Transcode به Codec
تدوینی یا استفاده از CPU قدرتمندتر می‌تواند
Workflow را روان‌تر کند.

AV1 چیست؟

AV1 یک Codec ویدئویی مدرن و با راندمان فشرده‌سازی
بالا است که برای پخش آنلاین، استریم، ویدئوهای
با وضوح بالا و کاهش مصرف پهنای باند طراحی شده است.

این Codec می‌تواند در Bitrate مشابه، کیفیت بهتری
نسبت به Codecهای قدیمی‌تر ارائه دهد یا برای کیفیت
یکسان، حجم فایل و پهنای باند کمتری مصرف کند.

پیچیدگی بالاتر AV1 باعث می‌شود Decode و به‌ویژه
Encode نرم‌افزاری آن سنگین باشد؛ بنابراین وجود
موتور سخت‌افزاری اختصاصی اهمیت زیادی دارد.

AV1 در چه کاربردهایی استفاده می‌شود؟

کاربردهای رایج AV1
کاربرد مزیت AV1 اهمیت شتاب‌دهی سخت‌افزاری
استریم ویدئوی آنلاین کاهش مصرف پهنای باند بسیار زیاد
ویدئوی 4K و 8K فشرده‌سازی بهتر فایل‌های حجیم بسیار زیاد
استریم زنده کیفیت بهتر در Bitrate محدود بسیار زیاد
تماس تصویری کیفیت مناسب در اینترنت ضعیف‌تر زیاد
ضبط ویدئو کاهش فضای ذخیره‌سازی زیاد
آرشیو ویدئو کاهش حجم مجموعه‌های بزرگ متوسط تا زیاد
پخش در مرورگر کاهش حجم داده دریافتی بسیار زیاد

مقایسه AV1 با H.264 و HEVC

مقایسه عمومی H.264، HEVC و AV1
معیار H.264 HEVC AV1
سازگاری بسیار گسترده گسترده در دستگاه‌های جدیدتر وابسته‌تر به نسل جدید سخت‌افزار
راندمان فشرده‌سازی خوب بهتر بسیار بالا
پیچیدگی Decode کمتر بیشتر زیاد
پیچیدگی Encode متوسط زیاد بسیار زیاد
مناسب برای انتشار عمومی و سازگاری بالا 4K، HDR و آرشیو استریم مدرن و پهنای باند محدود
نیاز به موتور سخت‌افزاری مفید بسیار مهم بسیار مهم

Hardware Decode در AV1

Decode سخت‌افزاری AV1 به موتور اختصاصی GPU اجازه
می‌دهد جریان فشرده را بدون فشار سنگین بر CPU به
فریم‌های قابل نمایش تبدیل کند.

این قابلیت برای پخش ویدئوی 4K، نرخ فریم بالا،
استریم آنلاین و افزایش عمر باتری لپ‌تاپ اهمیت
زیادی دارد.

در نبود AV1 Hardware Decode، مرورگر یا نرم‌افزار
ممکن است پردازش را به CPU منتقل کند و باعث افزایش
مصرف، دما و احتمال افت فریم شود.

Hardware Encode در AV1

AV1 Hardware Encode امکان تبدیل فریم‌های خام یا
پردازش‌شده به جریان AV1 را با استفاده از موتور
اختصاصی GPU فراهم می‌کند.

این قابلیت برای استریم، ضبط بازی، تولید محتوای
آنلاین و تبدیل سریع ویدئو بسیار مهم است؛ زیرا
Encode نرم‌افزاری AV1 می‌تواند پردازش بسیار سنگینی
داشته باشد.

کیفیت Encoder سخت‌افزاری به نسل موتور، تنظیمات
Bitrate، Preset، تعداد Passها و نوع محتوای تصویر
وابسته است.

Profileهای AV1

Profile در AV1 مشخص می‌کند جریان ویدئویی از چه
عمق رنگ، Chroma Subsampling و مجموعه قابلیت‌هایی
استفاده می‌کند.

Profileهای اصلی AV1
Profile ویژگی عمومی کاربرد
Main Profile حالت رایج برای محتوای مصرف عمومی وب، استریم و پخش عمومی
High Profile پشتیبانی از اطلاعات رنگی بیشتر کاربردهای تصویری پیشرفته‌تر
Professional Profile عمق رنگ و Chroma حرفه‌ای‌تر تولید، آرشیو و Workflow تخصصی

عمق رنگ در AV1

AV1 می‌تواند از عمق رنگ‌های مختلف برای نمایش
دقیق‌تر طیف رنگ و کاهش Banding استفاده کند.

ویدئوی ۱۰ بیت برای HDR و محتوای با دامنه رنگی
گسترده اهمیت زیادی دارد، اما پشتیبانی سخت‌افزاری
باید برای مدل دقیق GPU بررسی شود.

کاربرد عمق رنگ‌های مختلف در AV1
Bit Depth ویژگی کاربرد وضعیت عمومی پشتیبانی
8-bit سازگاری بیشتر پخش و استریم عمومی گسترده‌تر
10-bit رنگ دقیق‌تر و HDR ویدئوی مدرن و HDR وابسته به نسل GPU
12-bit دقت رنگ بسیار بالا کاربردهای حرفه‌ای محدودتر

Chroma Subsampling در AV1

مانند سایر Codecها، AV1 می‌تواند میزان اطلاعات
رنگی را با روش‌های مختلف Chroma Subsampling ذخیره
کند.

حالت 4:2:0 برای پخش آنلاین و مصرف عمومی رایج‌تر
است؛ درحالی‌که 4:2:2 و 4:4:4 برای کاربردهای
حرفه‌ای و پردازش دقیق رنگ اهمیت بیشتری دارند.

کاربرد حالت‌های Chroma در AV1
Chroma اطلاعات رنگ کاربرد پشتیبانی سخت‌افزاری
4:2:0 کمتر وب، استریم و پخش عمومی رایج‌تر
4:2:2 بیشتر Broadcast و تدوین محدودتر
4:4:4 کامل‌تر VFX، Keying و Mastering وابسته به محصول

Film Grain Synthesis در AV1

دانه‌های فیلم یا Film Grain می‌توانند فشرده‌سازی
ویدئو را دشوار کنند؛ زیرا تغییرات ریز و تصادفی
تصویر به Bitrate زیادی نیاز دارند.

AV1 می‌تواند بخشی از Grain را پیش از Encode حذف
کند و اطلاعات لازم برای بازسازی آن را جداگانه
ذخیره کند.

در زمان Decode، موتور یا نرم‌افزار Grain را دوباره
روی تصویر اعمال می‌کند تا ظاهر سینمایی حفظ شود،
بدون آنکه تمام جزئیات تصادفی داخل جریان اصلی
کدگذاری شوند.

AV1 و Screen Content

محتوای صفحه‌نمایش مانند متن، رابط نرم‌افزار،
اسلاید، کدنویسی و Remote Desktop با ویدئوی دوربین
تفاوت دارد.

AV1 دارای ابزارهایی برای فشرده‌سازی بهتر خطوط
تیز، متن و نواحی با رنگ یکنواخت است.

این ویژگی می‌تواند برای ضبط آموزش، استریم دسکتاپ،
جلسه آنلاین و نرم‌افزارهای Remote Work مفید باشد.

Encode نرم‌افزاری AV1

Encode نرم‌افزاری AV1 می‌تواند کیفیت و انعطاف
زیادی ارائه دهد، اما در Presetهای باکیفیت بسیار
پردازش‌بر است.

سرعت خروجی به تعداد هسته‌های CPU، نوع Encoder،
Resolution، Preset، Bitrate و تنظیمات تحلیل
ویدئو وابسته است.

برای آرشیو نهایی ممکن است Encode نرم‌افزاری انتخاب
مناسبی باشد؛ اما برای استریم یا خروجی سریع، موتور
سخت‌افزاری معمولاً کاربردی‌تر است.

مقایسه AV1 Hardware Encode و Software Encode
معیار Hardware Encode Software Encode
سرعت بسیار بالا معمولاً پایین‌تر
مصرف CPU کم زیاد
مصرف انرژی معمولاً کمتر بیشتر
انعطاف تنظیم محدودتر بیشتر
کاربرد استریم، ضبط و Export سریع آرشیو و Encode باکیفیت

چرا نسل GPU برای AV1 اهمیت دارد؟

AV1 در GPUهای قدیمی‌تر معمولاً فاقد Decode یا
Encode سخت‌افزاری است.

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

همچنین بعضی نسل‌ها فقط AV1 Decode دارند و پشتیبانی
AV1 Encode در نسل‌های جدیدتر اضافه شده است.

AV1 در GPUها و لپ‌تاپ‌های قدیمی

بسیاری از کارت‌های Quadro K، Quadro M، Quadro P،
GTXهای قدیمی و گرافیک‌های مجتمع نسل قبل، موتور
اختصاصی AV1 ندارند.

در این سیستم‌ها پخش AV1 ممکن است توسط CPU انجام
شود یا نرم‌افزار سرویس پخش، Codec دیگری مانند
H.264 یا VP9 را انتخاب کند.

برای استفاده‌های آموزشی و پخش عمومی، این سیستم‌ها
همچنان قابل استفاده‌اند؛ اما مصرف CPU، توان و
کیفیت پخش AV1 باید بررسی شود.

رفتار احتمالی سیستم فاقد شتاب‌دهی AV1
وضعیت پیامد
Decode توسط CPU افزایش مصرف پردازنده
ویدئوی 4K احتمال افت فریم
لپ‌تاپ با باتری کاهش عمر باتری
مرورگر احتمال انتخاب Codec جایگزین
Export AV1 نیاز به Encode نرم‌افزاری کندتر

VP9 چیست؟

VP9 یک Codec ویدئویی متن‌باز است که برای کاهش حجم
فایل و بهبود کیفیت استریم اینترنتی توسعه یافته است.

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

VP9 نسبت به H.264 راندمان فشرده‌سازی بهتری دارد،
اما Decode نرم‌افزاری آن سنگین‌تر است و وجود موتور
سخت‌افزاری اختصاصی می‌تواند مصرف CPU را به‌طور
محسوسی کاهش دهد.

چرا VP9 توسعه پیدا کرد؟

با افزایش کیفیت ویدئوهای آنلاین، نیاز به Codecی
با راندمان بهتر از H.264 احساس شد.

VP9 برای کاهش مصرف پهنای باند و هزینه انتقال داده
توسعه یافت و سال‌ها در سرویس‌های پخش آنلاین
محبوب‌ترین گزینه برای ویدئوهای 4K محسوب می‌شد.

امروزه AV1 به‌تدریج جایگزین VP9 می‌شود، اما VP9
همچنان در بسیاری از سیستم‌ها و مرورگرها پشتیبانی
می‌شود.

کاربردهای VP9

مهم‌ترین کاربردهای Codec VP9
کاربرد دلیل استفاده اهمیت Hardware Decode
YouTube کاهش پهنای باند بسیار زیاد
مرورگرها پخش آنلاین زیاد
ویدئوهای 4K حجم کمتر بسیار زیاد
Smart TV استریم اینترنتی زیاد
Android TV کاهش مصرف اینترنت زیاد
آموزش آنلاین کیفیت بهتر در Bitrate پایین متوسط

تفاوت VP9 و H.264

مقایسه VP9 و H.264
معیار H.264 VP9
راندمان فشرده‌سازی خوب بهتر
نیاز پردازشی کمتر بیشتر
حجم فایل بیشتر کمتر
سازگاری بسیار گسترده وابسته به مرورگر و GPU
کاربرد اصلی انتشار عمومی استریم اینترنتی

Hardware Decode در VP9

موتور Decode اختصاصی VP9 می‌تواند ویدئوهای اینترنتی
را بدون فشار زیاد بر CPU پخش کند.

این موضوع مخصوصاً هنگام پخش ویدئوهای 4K، نرخ فریم
بالا یا HDR اهمیت بیشتری پیدا می‌کند.

Hardware Encode در VP9

پشتیبانی Encode سخت‌افزاری VP9 نسبت به Decode آن
محدودتر است و در همه GPUها وجود ندارد.

هنگام تولید محتوا باید مشخص شود GPU علاوه بر Decode،
امکان Encode VP9 را نیز ارائه می‌دهد یا خیر.

عمق رنگ در VP9

VP9 علاوه بر ویدئوی ۸ بیت، از عمق رنگ ۱۰ و ۱۲ بیت
نیز پشتیبانی می‌کند و می‌تواند برای محتوای HDR نیز
مورد استفاده قرار گیرد.

Bit Depthهای رایج در VP9
Bit Depth کاربرد وضعیت عمومی
8-bit پخش عمومی بسیار رایج
10-bit HDR وابسته به GPU
12-bit کاربردهای تخصصی محدود

پشتیبانی VP9 در نسل‌های مختلف GPU

پشتیبانی VP9 به نسل موتور ویدئویی GPU وابسته است،
نه صرفاً نام کارت گرافیک.

بسیاری از GPUهای قدیمی Decode سخت‌افزاری VP9
ندارند و هنگام پخش ویدئوهای آنلاین، CPU بار اصلی
پردازش را بر عهده می‌گیرد.

وضعیت کلی VP9 در نسل‌های مختلف GPU
نسل GPU وضعیت عمومی نکته
نسل‌های قدیمی معمولاً بدون Decode اختصاصی وابسته به CPU
نسل‌های میانی Decode در برخی مدل‌ها بررسی دقیق تراشه لازم است
نسل‌های جدید Decode گسترده‌تر مناسب استریم 4K

VP9 در مرورگرها

هنگام مشاهده ویدئوهای آنلاین، مرورگر بر اساس
قابلیت GPU، Codecهای پشتیبانی‌شده، سیستم‌عامل و
تنظیمات سرویس استریم، ممکن است VP9، AV1 یا H.264
را انتخاب کند.

وجود Decode سخت‌افزاری VP9 باعث کاهش مصرف CPU،
افزایش عمر باتری و پخش روان‌تر ویدئوهای آنلاین
می‌شود.

Bit Depth یا عمق رنگ در ویدئو چیست؟

Bit Depth مشخص می‌کند برای نمایش مقدار روشنایی
یا رنگ هر کانال، چند بیت اطلاعات در اختیار سیستم
قرار دارد.

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

ویدئوهای ۸ بیت برای استفاده عمومی بسیار رایج‌اند،
درحالی‌که ویدئوهای ۱۰ و ۱۲ بیت بیشتر در HDR،
تدوین حرفه‌ای، Color Grading و تولید سینمایی
استفاده می‌شوند.

تفاوت ویدئوی ۸، ۱۰ و ۱۲ بیت

مقایسه عمق رنگ‌های رایج در ویدئو
عمق رنگ سطح هر کانال کاربرد رایج وضعیت پشتیبانی
8-bit 256 سطح وب، استریم و استفاده عمومی بسیار گسترده
10-bit 1024 سطح HDR، تدوین و Color Grading وابسته به Codec و نسل GPU
12-bit 4096 سطح Cinema، Mastering و Workflow تخصصی محدودتر

Bit Depth چگونه تعداد رنگ‌ها را افزایش می‌دهد؟

در تصویر RGB، هر پیکسل معمولاً از سه کانال قرمز،
سبز و آبی تشکیل می‌شود.

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

Color Banding چیست؟

Color Banding زمانی دیده می‌شود که تعداد سطوح
رنگ یا روشنایی برای نمایش یک Gradient نرم کافی
نباشد.

به‌جای تغییر تدریجی رنگ، نوارهای مشخص و جدا از
یکدیگر در آسمان، سایه، مه، دود یا پس‌زمینه‌های
نرم دیده می‌شوند.

افزایش Bit Depth می‌تواند احتمال Banding را کاهش
دهد؛ اما Bitrate پایین، فشرده‌سازی شدید، تنظیمات
نادرست رنگ و نمایشگر ضعیف نیز می‌توانند این مشکل
را ایجاد کنند.

عوامل ایجاد Color Banding
عامل اثر
Bit Depth پایین تعداد محدود سطوح رنگ و روشنایی
Bitrate پایین حذف جزئیات Gradient هنگام فشرده‌سازی
Encode چندباره افزایش خطاهای فشرده‌سازی
Color Space نامناسب تبدیل نادرست دامنه رنگ
نمایشگر ۸ بیت ضعیف نمایش ناتوان Gradientهای نرم

چرا ویدئوی HDR معمولاً ۱۰ بیت است؟

HDR دامنه روشنایی و رنگ بیشتری نسبت به SDR دارد.
برای نمایش این دامنه گسترده، تعداد سطوح رنگی بیشتری
لازم است.

استفاده از ۱۰ بیت باعث می‌شود Gradientهای روشنایی
و رنگ در سایه‌ها و نقاط بسیار روشن نرم‌تر نمایش
داده شوند.

مسیر کامل HDR شامل Codec، موتور Decode، سیستم‌عامل،
نرم‌افزار، Display Engine، اتصال تصویر و نمایشگر
سازگار است.

تفاوت Bit Depth فایل، پردازش و نمایشگر

عمق رنگ فایل ویدئویی، دقت پردازش نرم‌افزار و عمق
رنگ خروجی نمایشگر سه موضوع جداگانه هستند.

ممکن است فایل ۱۰ بیت باشد، اما نمایشگر فقط خروجی
۸ بیت واقعی ارائه دهد.

همچنین بعضی نرم‌افزارها پردازش داخلی را با دقت
بالاتر انجام می‌دهند، حتی اگر فایل ورودی یا خروجی
۸ بیت باشد.

اجزای مختلف مسیر Bit Depth
بخش مفهوم نمونه محدودیت
File Bit Depth عمق رنگ ذخیره‌شده در Codec فایل HEVC ده‌بیتی
Decode Bit Depth توان موتور ویدئو برای بازکردن فایل نبود Decode سخت‌افزاری ۱۰ بیت
Processing Precision دقت داخلی نرم‌افزار و Shader پردازش 16-bit Float یا 32-bit Float
Output Bit Depth عمق رنگ مسیر خروجی GPU خروجی محدود به ۸ بیت
Display Panel عمق رنگ واقعی پنل پنل 8-bit یا 8-bit + FRC

تفاوت نمایشگر ۱۰ بیت واقعی و 8-bit + FRC

پنل ۱۰ بیت واقعی می‌تواند تعداد بیشتری سطح رنگ
را مستقیماً نمایش دهد.

نمایشگر 8-bit + FRC با تغییر سریع میان دو رنگ
نزدیک، سطح رنگ میانی را شبیه‌سازی می‌کند.

FRC برای بسیاری از کاربردهای عمومی نتیجه مناسبی
دارد، اما در Color Grading حساس و Mastering حرفه‌ای،
پنل واقعی ۱۰ بیت قابل‌اعتمادتر است.

مقایسه پنل ۱۰ بیت واقعی و FRC
معیار True 10-bit 8-bit + FRC
تولید رنگ نمایش مستقیم سطوح بیشتر شبیه‌سازی زمانی رنگ‌های میانی
دقت حرفه‌ای بالاتر مناسب بسیاری از کاربردهای عمومی
قیمت معمولاً بیشتر معمولاً اقتصادی‌تر
کاربرد Mastering، Cinema و Color Critical تدوین عمومی، طراحی و مصرف محتوا

پشتیبانی Bit Depth در Codecهای مختلف

وضعیت عمومی عمق رنگ در Codecهای رایج
Codec 8-bit 10-bit 12-bit
H.264 بسیار رایج موجود اما سخت‌افزار محدودتر کاربرد محدود
HEVC رایج بسیار رایج در HDR موجود در Profileهای خاص
VP9 رایج رایج برای HDR وب محدودتر
AV1 رایج مهم برای HDR پشتیبانی تخصصی‌تر
ProRes وابسته به Profile رایج در Workflow حرفه‌ای وابسته به نسخه و Profile

بررسی پشتیبانی سخت‌افزاری ویدئوی ۱۰ بیت

برای اطمینان از پشتیبانی کامل ویدئوی ۱۰ بیت، فقط
وجود نمایشگر یا فایل ۱۰ بیت کافی نیست.

باید Decode، Encode، پردازش، خروجی تصویر و پنل
نمایشگر به‌صورت جداگانه بررسی شوند.

چک‌لیست پشتیبانی ویدئوی ۱۰ بیت
بررسی پرسش اصلی
Codec فایل با H.264، HEVC، VP9 یا AV1 است؟
Decode Engine GPU همان Codec را با عمق ۱۰ بیت Decode می‌کند؟
Encode Engine خروجی سخت‌افزاری ۱۰ بیت پشتیبانی می‌شود؟
Chroma فایل 4:2:0، 4:2:2 یا 4:4:4 است؟
نرم‌افزار برنامه از مسیر ۱۰ بیت GPU استفاده می‌کند؟
اتصال تصویر کابل و درگاه پهنای باند کافی دارند؟
نمایشگر پنل ۱۰ بیت واقعی یا FRC است؟
تنظیمات سیستم خروجی ۱۰ بیت در درایور فعال شده است؟

ویدئوی ۱۰ بیت در GPUهای قدیمی

بعضی GPUهای قدیمی می‌توانند خروجی رنگ ۱۰ بیت
ارائه دهند، اما Decode سخت‌افزاری Codecهای ۱۰ بیت
جدیدتر را نداشته باشند.

همچنین ممکن است کارت Quadro قدیمی در نرم‌افزارهای
حرفه‌ای خروجی ۱۰ بیت داشته باشد، اما موتور Decode
آن برای HEVC Main 10 یا VP9 Profile 2 مناسب نباشد.

بنابراین خروجی ۱۰ بیت نمایشگر و پشتیبانی ۱۰ بیت
موتور ویدئویی نباید با یکدیگر اشتباه گرفته شوند.

Bit Depth در تدوین و Color Grading

پروژه‌های حرفه‌ای معمولاً با دقت رنگ بالاتر پردازش
می‌شوند تا هنگام اعمال افکت، تصحیح نور، Keying و
تغییر رنگ، خطا و Banding کمتری ایجاد شود.

حتی اگر خروجی نهایی ۸ بیت باشد، پردازش داخلی
۱۰ بیت، 16-bit Float یا 32-bit Float می‌تواند
کیفیت مراحل میانی را حفظ کند.

اهمیت Bit Depth در مراحل تولید ویدئو
مرحله اهمیت Bit Depth بالا
ضبط حفظ اطلاعات بیشتر نور و رنگ
تدوین کاهش تخریب تصویر در تغییرات چندباره
Color Grading کنترل دقیق‌تر سایه و Highlight
VFX و Keying لبه‌های بهتر و رنگ دقیق‌تر
HDR Mastering نمایش دامنه روشنایی گسترده
خروجی نهایی کاهش Banding و حفظ Gradient

Chroma Subsampling چیست؟

Chroma Subsampling روشی برای کاهش حجم داده‌های
ویدئویی است که بخشی از اطلاعات رنگ را با دقت
کمتری نسبت به روشنایی ذخیره می‌کند.

چشم انسان معمولاً به جزئیات روشنایی حساس‌تر از
تغییرات بسیار ریز رنگ است. Codecهای ویدئویی از
این ویژگی استفاده می‌کنند تا حجم فایل و پهنای
باند موردنیاز را کاهش دهند.

حالت‌های 4:2:0، 4:2:2 و 4:4:4 نشان می‌دهند اطلاعات
رنگی با چه دقتی نسبت به اطلاعات روشنایی ذخیره شده‌اند.

تفاوت Luma و Chroma

در بسیاری از سیستم‌های ویدئویی، تصویر به اطلاعات
روشنایی و اطلاعات رنگی تقسیم می‌شود.

Luma جزئیات روشنایی و ساختار اصلی تصویر را نگهداری
می‌کند. Chroma اطلاعات تفاوت رنگ را ذخیره می‌کند.

مقایسه اطلاعات روشنایی و رنگ در ویدئو
مؤلفه وظیفه حساسیت چشم انسان
Luma ذخیره جزئیات روشنایی و ساختار تصویر بسیار زیاد
Chroma ذخیره اطلاعات رنگ کمتر از روشنایی

اعداد 4:2:0، 4:2:2 و 4:4:4 چه معنایی دارند؟

این اعداد نسبت نمونه‌برداری روشنایی و رنگ را در
یک ناحیه تصویری نشان می‌دهند.

عدد اول معمولاً مرجع نمونه‌های روشنایی است و دو
عدد بعدی مقدار اطلاعات رنگی ذخیره‌شده را نشان
می‌دهند.

مقایسه 4:2:0، 4:2:2 و 4:4:4

مقایسه حالت‌های رایج Chroma Subsampling
حالت اطلاعات رنگ حجم داده کاربرد رایج
4:2:0 کمتر کم وب، استریم، فیلم و مصرف عمومی
4:2:2 بیشتر متوسط دوربین حرفه‌ای، Broadcast و تدوین
4:4:4 کامل‌تر زیاد VFX، Keying، متن و Mastering

Chroma 4:2:0 چیست؟

4:2:0 رایج‌ترین حالت در فیلم، استریم، Blu-ray،
شبکه‌های اجتماعی و سرویس‌های پخش آنلاین است.

در این روش اطلاعات رنگی هم در جهت افقی و هم در
جهت عمودی کاهش پیدا می‌کند.

برای تصاویر طبیعی و فیلم، کاهش جزئیات رنگ معمولاً
کمتر قابل تشخیص است و در مقابل حجم فایل به‌طور
محسوسی کاهش می‌یابد.

Chroma 4:2:2 چیست؟

در 4:2:2 اطلاعات رنگی افقی کاهش می‌یابد، اما دقت
رنگ در جهت عمودی بهتر از 4:2:0 حفظ می‌شود.

این حالت در دوربین‌های حرفه‌ای، Broadcast،
Color Grading و تولید محتوایی که نیاز به تغییرات
رنگی بیشتری دارد رایج است.

فایل‌های 4:2:2 نسبت به 4:2:0 حجم و پهنای باند
بیشتری دارند و پشتیبانی سخت‌افزاری Decode و Encode
آن‌ها نیز محدودتر است.

Chroma 4:4:4 چیست؟

در 4:4:4 اطلاعات رنگی با وضوح کامل‌تری ذخیره
می‌شوند و کاهش نمونه‌برداری رنگ وجود ندارد یا
بسیار محدود است.

این حالت برای متن، رابط نرم‌افزار، Keying، VFX،
ترکیب تصاویر، تولید گرافیک و کاربردهای حساس به
لبه‌های رنگی مناسب‌تر است.

4:4:4 حجم داده، نیاز حافظه و پهنای باند بیشتری
دارد و همه موتورهای ویدئویی از Encode یا Decode
سخت‌افزاری آن پشتیبانی نمی‌کنند.

اثر Chroma Subsampling بر متن و رابط کاربری

متن‌های رنگی کوچک، خطوط باریک و مرزهای تیز ممکن
است در 4:2:0 یا 4:2:2 وضوح کمتری داشته باشند.

دلیل این موضوع آن است که اطلاعات رنگی لبه حروف
با دقت پایین‌تری ذخیره یا منتقل می‌شود.

برای استفاده از تلویزیون به‌عنوان مانیتور، Remote
Desktop، ضبط آموزش نرم‌افزار و محتوای شامل متن،
4:4:4 می‌تواند وضوح بیشتری ارائه دهد.

اثر Chroma بر انواع محتوا
نوع محتوا حساسیت به کاهش Chroma حالت مناسب‌تر
فیلم طبیعی کم تا متوسط 4:2:0
Broadcast متوسط تا زیاد 4:2:2
متن و رابط کاربری بسیار زیاد 4:4:4
Green Screen بسیار زیاد 4:2:2 یا 4:4:4
VFX و Compositing بسیار زیاد 4:4:4

چرا Chroma برای Green Screen مهم است؟

در Keying، نرم‌افزار باید مرز میان سوژه و پس‌زمینه
رنگی را با دقت تشخیص دهد.

اگر اطلاعات رنگی کاهش زیادی داشته باشد، لبه مو،
لباس، اجسام باریک و جزئیات نیمه‌شفاف ممکن است
آسیب ببینند.

ضبط 4:2:2 یا 4:4:4 معمولاً اطلاعات مناسب‌تری برای
Keying و حذف دقیق پس‌زمینه فراهم می‌کند.

اثر Chroma Subsampling بر حجم و پهنای باند

هرچه اطلاعات رنگ بیشتری ذخیره شود، حجم فریم خام،
Bitrate و نیاز به پهنای باند حافظه افزایش پیدا
می‌کند.

در پروژه‌های 4K، 8K، نرخ فریم بالا و عمق رنگ
۱۰ یا ۱۲ بیت، این اختلاف می‌تواند بسیار قابل‌توجه
باشد.

اثر Chroma بر نیازهای پردازشی و ذخیره‌سازی
حالت حجم نسبی داده فشار بر VRAM فشار بر Storage
4:2:0 کمتر کمتر کمتر
4:2:2 متوسط بیشتر بیشتر
4:4:4 زیاد زیاد زیاد

پشتیبانی Chroma در Codecهای مختلف

وضعیت عمومی Chroma در Codecهای رایج
Codec 4:2:0 4:2:2 4:4:4
H.264 بسیار رایج موجود در Profileهای خاص موجود اما سخت‌افزار محدودتر
HEVC بسیار رایج مناسب کاربرد حرفه‌ای وابسته به Profile و سخت‌افزار
VP9 رایج محدودتر وابسته به Profile
AV1 رایج در Profileهای پیشرفته‌تر پشتیبانی تخصصی‌تر
ProRes وابسته به Profile رایج در Profileهای حرفه‌ای

بررسی پشتیبانی سخت‌افزاری Chroma

وجود نام Codec در مشخصات GPU به معنی پشتیبانی از
تمام حالت‌های Chroma نیست.

ممکن است موتور Decode فقط 4:2:0 را پشتیبانی کند،
اما فایل دوربین 4:2:2 باشد و پردازش آن به CPU یا
Shaderها منتقل شود.

موارد لازم برای بررسی پشتیبانی Chroma
مورد پرسش اصلی
Codec فایل H.264، HEVC، VP9 یا AV1 است؟
Profile Profile موردنظر از 4:2:2 یا 4:4:4 پشتیبانی می‌کند؟
Decode Engine موتور GPU همان Chroma را Decode می‌کند؟
Encode Engine خروجی سخت‌افزاری با همان Chroma ممکن است؟
Bit Depth حالت ۸، ۱۰ یا ۱۲ بیت پشتیبانی می‌شود؟
نرم‌افزار برنامه از مسیر سخت‌افزاری همان حالت استفاده می‌کند؟
Resolution و Frame Rate موتور در وضوح و نرخ فریم موردنظر محدودیت ندارد؟

Chroma در GPUهای قدیمی و Quadro

کارت‌های حرفه‌ای قدیمی ممکن است خروجی رنگ دقیق یا
قابلیت‌های نمایش حرفه‌ای داشته باشند، اما موتور
ویدئویی آن‌ها الزاماً Codecهای جدید 4:2:2 یا
4:4:4 را به‌صورت سخت‌افزاری Decode نمی‌کند.

همچنین نام Quadro تضمین نمی‌کند که Encode یا
Decode سخت‌افزاری Chroma حرفه‌ای در دسترس باشد.

مدل دقیق GPU، نسل موتور ویدئو، Codec، Profile و
نرم‌افزار باید به‌صورت جداگانه بررسی شوند.

انتخاب Chroma مناسب برای هر Workflow

پیشنهاد عمومی Chroma برای کاربردهای مختلف
کاربرد Chroma پیشنهادی دلیل
انتشار وب 4:2:0 حجم کمتر و سازگاری گسترده
استریم زنده 4:2:0 محدودیت پهنای باند و پشتیبانی پلتفرم
تدوین عمومی 4:2:0 یا 4:2:2 وابسته به منبع و میزان اصلاح رنگ
Broadcast 4:2:2 حفظ بهتر اطلاعات رنگ
Green Screen 4:2:2 یا 4:4:4 لبه‌های رنگی دقیق‌تر
VFX و Compositing 4:4:4 حفظ کامل‌تر اطلاعات رنگ
ضبط صفحه و متن 4:4:4 در صورت امکان وضوح بیشتر نوشته‌ها و خطوط

وضوح تصویر (Resolution) و نرخ فریم (Frame Rate) چه تأثیری بر موتور ویدئویی GPU دارند؟

هنگام بررسی قابلیت‌های Decode و Encode یک GPU،
تنها نوع Codec اهمیت ندارد. وضوح تصویر، نرخ فریم،
عمق رنگ و Chroma Subsampling نیز میزان بار پردازشی
موتور ویدئویی را به‌شدت تغییر می‌دهند.

ممکن است یک GPU بتواند فایل HEVC را در وضوح
Full HD به‌راحتی Decode کند، اما همان Codec را
در 8K یا نرخ فریم بسیار بالا به‌صورت سخت‌افزاری
پشتیبانی نکند.

وضوح‌های رایج ویدئویی

وضوح‌های متداول ویدئویی
نام Resolution تعداد تقریبی پیکسل کاربرد
HD 1280 × 720 0.9 میلیون آموزش و استریم سبک
Full HD 1920 × 1080 2.1 میلیون رایج‌ترین وضوح عمومی
QHD 2560 × 1440 3.7 میلیون مانیتورهای حرفه‌ای
4K UHD 3840 × 2160 8.3 میلیون فیلم و تولید محتوا
8K UHD 7680 × 4320 33.2 میلیون تولید حرفه‌ای و آینده‌نگر

Frame Rate چیست؟

Frame Rate یا نرخ فریم نشان می‌دهد در هر ثانیه
چند تصویر کامل نمایش داده می‌شود.

هرچه نرخ فریم بیشتر باشد، موتور Decode یا Encode
باید تعداد بیشتری فریم را در هر ثانیه پردازش کند.

نرخ‌های فریم متداول
Frame Rate کاربرد فشار پردازشی
24 fps فیلم سینمایی کم
30 fps ویدئوهای عمومی متوسط
60 fps بازی و ویدئوهای روان زیاد
120 fps Slow Motion و کاربرد حرفه‌ای بسیار زیاد

چرا افزایش Resolution و Frame Rate اهمیت دارد؟

افزایش وضوح تصویر یا نرخ فریم باعث می‌شود حجم
داده‌ای که موتور ویدئویی باید در هر ثانیه پردازش
کند چند برابر شود.

ارتباط Resolution با پهنای باند حافظه

افزایش وضوح تصویر فقط Decode را سنگین‌تر نمی‌کند،
بلکه میزان انتقال داده میان موتور ویدئویی، حافظه،
Display Engine و سایر بخش‌های GPU را نیز افزایش
می‌دهد.

به همین دلیل بعضی GPUها اگرچه از یک Codec
پشتیبانی می‌کنند، اما در وضوح‌های بسیار بالا یا
نرخ فریم زیاد با محدودیت مواجه می‌شوند.

Pixel Throughput در پردازش ویدئو چیست؟

Pixel Throughput نشان می‌دهد موتور ویدئویی باید
در هر ثانیه چه تعداد پیکسل را برای Decode، Encode
یا پردازش میان‌مرحله‌ای مدیریت کند.

این مقدار از ضرب تعداد پیکسل‌های هر فریم در نرخ
فریم به دست می‌آید و معیار مفیدی برای مقایسه
سنگینی جریان‌های مختلف ویدئویی است.

افزایش Resolution یا Frame Rate می‌تواند حتی بدون
تغییر Codec، فشار پردازشی موتور ویدئویی را چند
برابر کند.

مقایسه حجم پردازش در وضوح‌ها و نرخ‌های فریم مختلف

تعداد تقریبی پیکسل پردازش‌شده در هر ثانیه
حالت ویدئو پیکسل هر فریم نرخ فریم پیکسل در ثانیه فشار نسبی
1080p 30fps حدود 2.1 میلیون 30 حدود 62 میلیون پایه
1080p 60fps حدود 2.1 میلیون 60 حدود 124 میلیون حدود دو برابر
1440p 60fps حدود 3.7 میلیون 60 حدود 221 میلیون زیاد
4K 30fps حدود 8.3 میلیون 30 حدود 249 میلیون حدود چهار برابر 1080p
4K 60fps حدود 8.3 میلیون 60 حدود 498 میلیون بسیار زیاد
8K 30fps حدود 33.2 میلیون 30 حدود 995 میلیون بسیار سنگین
8K 60fps حدود 33.2 میلیون 60 حدود 1.99 میلیارد فوق‌سنگین

اثر هم‌زمان Resolution، Frame Rate، Bit Depth و Chroma

بار واقعی موتور ویدئویی تنها با تعداد پیکسل‌ها
تعیین نمی‌شود. عمق رنگ و مقدار اطلاعات Chroma نیز
حجم داده هر فریم را تغییر می‌دهند.

برای مثال، ویدئوی 4K ده‌بیتی 4:2:2 نسبت به ویدئوی
4K هشت‌بیتی 4:2:0 داده بیشتری برای Decode،
پردازش، انتقال در VRAM و Encode نیاز دارد.

عوامل افزایش بار پردازش ویدئویی
عامل حالت سبک‌تر حالت سنگین‌تر اثر اصلی
Resolution 1080p 4K یا 8K افزایش تعداد پیکسل
Frame Rate 24 یا 30fps 60 یا 120fps افزایش تعداد فریم در ثانیه
Bit Depth 8-bit 10-bit یا 12-bit افزایش اطلاعات هر نمونه
Chroma 4:2:0 4:2:2 یا 4:4:4 افزایش جزئیات رنگ
Codec H.264 HEVC یا AV1 افزایش پیچیدگی رمزگشایی و رمزگذاری

نرخ داده ویدئوی خام و فشرده‌نشده

پس از Decode، فریم‌ها معمولاً به شکلی نزدیک‌تر به
داده خام در حافظه قرار می‌گیرند. این داده می‌تواند
بسیار بزرگ‌تر از فایل فشرده روی Storage باشد.

به همین دلیل فایل کم‌حجم HEVC یا AV1 پس از Decode
ممکن است فشار قابل‌توجهی بر VRAM و پهنای باند
داخلی GPU ایجاد کند.

Frame Buffer و حافظه موردنیاز ویدئو

موتور Decode برای بازسازی فریم‌ها معمولاً چندین
فریم را هم‌زمان در حافظه نگهداری می‌کند.

تعداد این فریم‌ها به Codec، ساختار GOP، تعداد
Reference Frameها، B-Frameها و تنظیمات نرم‌افزار
وابسته است.

پروژه‌های چندلایه، Multicam، Noise Reduction،
Color Grading و افکت‌های زمانی می‌توانند مصرف
VRAM را بسیار بیشتر کنند.

عوامل افزایش مصرف VRAM در پردازش ویدئو
عامل اثر بر حافظه
وضوح بالاتر افزایش اندازه هر فریم
Bit Depth بالاتر افزایش اطلاعات هر کانال
Chroma کامل‌تر افزایش داده رنگی
Reference Frame بیشتر نگهداری تعداد بیشتری فریم در حافظه
Multicam Decode چند جریان هم‌زمان
افکت‌های زمانی نیاز به فریم‌های قبل و بعد
پروژه چندلایه نگهداری چند Buffer تصویری

پردازش چند جریان ویدئویی هم‌زمان

در تدوین Multicam، سیستم نظارتی، پخش چند ویدئو،
Video Wall و Transcoding Server ممکن است چند
جریان به‌صورت هم‌زمان Decode یا Encode شوند.

هر جریان بخشی از ظرفیت موتور ویدئویی، پهنای باند
حافظه و VRAM را مصرف می‌کند.

حتی اگر موتور بتواند یک فایل 4K را Decode کند،
ممکن است برای چند جریان 4K هم‌زمان ظرفیت کافی
نداشته باشد.

نمونه بارهای چندجریانی ویدئویی
کاربرد نوع جریان‌ها محدودیت احتمالی
Multicam Editing چند فایل دوربین هم‌زمان Decode Throughput و VRAM
سیستم نظارتی ده‌ها Stream با وضوح متوسط تعداد Session و پهنای باند
Transcoding Server Decode و Encode هم‌زمان ظرفیت Encoder و Decoder
Video Wall چند خروجی ویدئویی Decode، Display Engine و خروجی تصویر
Live Production چند ورودی زنده تأخیر، Session و حافظه

Session در Encode و Decode چیست؟

Session به یک جریان مستقل پردازش ویدئویی گفته
می‌شود که توسط موتور Encode یا Decode مدیریت
می‌شود.

برای مثال، Decode دو فایل و Encode یک خروجی می‌تواند
شامل چند Session مستقل باشد.

تعداد Session قابل اجرا ممکن است به ظرفیت واقعی
موتور، محدودیت درایور، نوع محصول، Codec، Resolution
و نرم‌افزار وابسته باشد.

تفاوت ظرفیت سخت‌افزار و محدودیت نرم‌افزاری Session

موتور ویدئویی ممکن است از نظر سخت‌افزاری توان
پردازش چند جریان را داشته باشد، اما درایور یا نوع
محصول تعداد Sessionهای هم‌زمان را محدود کند.

در بعضی محصولات حرفه‌ای، سرور یا دیتاسنتر،
محدودیت‌های نرم‌افزاری متفاوتی نسبت به کارت‌های
مصرف‌کننده اعمال می‌شود.

عوامل تعیین‌کننده تعداد Sessionهای ویدئویی
عامل نقش
تعداد موتورهای فیزیکی ظرفیت پردازش موازی سخت‌افزار
Codec پیچیدگی متفاوت H.264، HEVC و AV1
Resolution مصرف بیشتر ظرفیت در وضوح بالاتر
Frame Rate افزایش Pixel Throughput
Bit Depth و Chroma افزایش حجم داده هر فریم
درایور امکان اعمال محدودیت نرم‌افزاری
نرم‌افزار نحوه مدیریت و تقسیم Sessionها
نوع کارت تفاوت میان مصرف‌کننده، حرفه‌ای و سرور

Decode و Encode هم‌زمان

در Transcoding، تدوین و استریم ممکن است موتور
Decode و Encode به‌صورت هم‌زمان فعال باشند.

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

اگر ورودی و خروجی از Codecهای سنگین، وضوح بالا یا
چند Stream تشکیل شده باشند، ظرفیت هر دو موتور و
حافظه GPU اهمیت پیدا می‌کند.

Real-Time Processing در ویدئو چیست؟

پردازش Real-Time یعنی سیستم بتواند هر فریم را پیش
از رسیدن زمان نمایش یا ارسال فریم بعدی آماده کند.

برای ویدئوی 60fps، هر فریم باید تقریباً در بازه
کوتاه‌تری نسبت به ویدئوی 30fps پردازش شود.

اگر موتور یا نرم‌افزار نتواند به سرعت موردنیاز
برسد، افت فریم، افزایش تأخیر یا توقف Timeline
رخ می‌دهد.

کاربردهای نیازمند پردازش Real-Time
کاربرد نیاز اصلی پیامد کمبود توان
پخش ویدئو Decode پیش از زمان نمایش افت فریم
استریم زنده Encode سریع با تأخیر کم افزایش Latency یا Frame Drop
تدوین Decode و افکت هم‌زمان Preview کند
تماس تصویری Encode و Decode دوطرفه تأخیر و ناپایداری تصویر
Remote Desktop Capture و Encode کم‌تأخیر واکنش کند رابط کاربری

گلوگاه‌های رایج در پردازش ویدئو

بخش‌هایی که می‌توانند سرعت پردازش ویدئو را محدود کنند
گلوگاه نشانه علت احتمالی
Decode Engine افت فریم با CPU کم‌مصرف Codec یا Stream سنگین‌تر از ظرفیت موتور
Encode Engine Export یا استریم کند Session زیاد یا Resolution بالا
Shader Core Decode روان ولی افکت کند Color، Noise Reduction یا Scaling سنگین
VRAM کندی پروژه چندلایه ظرفیت ناکافی یا Buffer زیاد
Memory Bandwidth افت سرعت در 4K یا 8K انتقال چند فریم بزرگ هم‌زمان
CPU مصرف بالا با Video Engine غیرفعال Software Decode یا پردازش Container
Storage توقف Timeline هنگام خواندن فایل سرعت ناکافی دیسک یا چند Stream هم‌زمان
نرم‌افزار و درایور استفاده‌نشدن از Hardware Acceleration تنظیم یا سازگاری نامناسب

NVIDIA NVENC چیست؟

NVENC مخفف NVIDIA Encoder است و به موتور سخت‌افزاری
اختصاصی رمزگذاری ویدئو در بسیاری از GPUهای NVIDIA
گفته می‌شود.

این موتور می‌تواند فریم‌های خام یا پردازش‌شده را
به جریان‌های فشرده‌ای مانند H.264، HEVC و در
نسل‌های جدیدتر AV1 تبدیل کند.

NVENC از هسته‌های عمومی Shader یا CUDA Core جدا
است؛ بنابراین در بسیاری از بارهای کاری می‌تواند
عملیات Encode را با درگیری کمتر CPU و واحدهای
پردازشی اصلی GPU انجام دهد.

مسیر پردازش ویدئو با NVENC

پیش از ورود فریم به NVENC، ممکن است Shaderها،
نرم‌افزار تدوین یا موتور بازی تصویر را پردازش
کرده باشند.

سپس فریم نهایی از حافظه GPU به NVENC ارسال می‌شود
تا با Codec و تنظیمات انتخاب‌شده فشرده شود.

کاربردهای NVENC

کاربردهای رایج موتور NVIDIA NVENC
کاربرد نقش NVENC مزیت اصلی
استریم زنده Encode تصویر بازی یا دوربین کاهش فشار بر CPU
ضبط بازی ذخیره فریم‌ها در فایل فشرده افت عملکرد کمتر نسبت به بعضی روش‌های نرم‌افزاری
Export ویدئو تولید خروجی H.264، HEVC یا AV1 زمان خروجی کوتاه‌تر
Transcoding Encode خروجی پس از Decode و تبدیل پردازش سریع چند فایل
Remote Desktop فشرده‌سازی تصویر دسکتاپ تأخیر کمتر
سیستم نظارتی فشرده‌سازی جریان‌های تصویری کاهش مصرف CPU سرور
Cloud Gaming Encode بلادرنگ تصویر بازی سرعت بالا و Latency پایین

تفاوت NVENC با CUDA Core

CUDA Coreها واحدهای پردازشی عمومی برای Shader،
Compute، افکت، Scaling، Color Correction و سایر
عملیات قابل برنامه‌ریزی هستند.

NVENC یک مدار ثابت و تخصصی برای Encode Codecهای
مشخص است و نمی‌تواند جایگزین واحدهای عمومی در تمام
پردازش‌های تصویری شود.

مقایسه NVENC و CUDA Core
معیار NVENC CUDA Core
نوع واحد موتور ثابت و تخصصی واحد محاسباتی قابل برنامه‌ریزی
وظیفه اصلی Encode ویدئو افکت، رندر و Compute
مصرف انرژی برای Encode معمولاً کمتر وابسته به بار محاسباتی
انعطاف محدود به Codec و قابلیت‌های موتور بسیار بیشتر
اجرای افکت معمولاً انجام نمی‌دهد انجام می‌دهد
فعالیت هم‌زمان می‌تواند هم‌زمان با CUDA Coreها کار کند افکت‌ها را پیش از Encode پردازش می‌کند

Codecهای قابل استفاده با NVENC

قابلیت دقیق NVENC به نسل معماری و تراشه بستگی دارد.
همه GPUهای NVIDIA مجموعه Codecها و Profileهای
یکسانی ندارند.

وضعیت عمومی Codecهای NVENC
Codec وضعیت عمومی کاربرد رایج نکته
H.264 گسترده در نسل‌های متعدد استریم، ضبط و انتشار عمومی Profile و کیفیت به نسل وابسته است
HEVC در نسل‌های جدیدتر 4K، HDR و آرشیو Bit Depth و Chroma جداگانه بررسی شوند
AV1 در نسل‌های جدیدتر استریم مدرن و Bitrate پایین‌تر Decode AV1 الزاماً به معنی Encode AV1 نیست
VP9 Encode سخت‌افزاری عمومی محدودتر کاربردهای خاص پشتیبانی نرم‌افزار و تراشه بررسی شود

چرا نسل NVENC اهمیت دارد؟

NVIDIA در نسل‌های مختلف، کیفیت فشرده‌سازی،
Codecهای پشتیبانی‌شده، Presetها، کنترل نرخ،
Bit Depth و قابلیت‌های NVENC را تغییر داده است.

دو کارت با تعداد CUDA Core متفاوت ممکن است موتور
NVENC هم‌نسل یا متفاوتی داشته باشند. بنابراین
قدرت رندر سه‌بعدی معیار دقیقی برای کیفیت Encoder
نیست.

تغییرات عمومی NVENC میان نسل‌ها
ویژگی نسل‌های قدیمی‌تر نسل‌های جدیدتر
کیفیت در Bitrate محدود ضعیف‌تر بهبود‌یافته
Codecها بیشتر متمرکز بر H.264 HEVC و AV1 در نسل‌های مناسب
Bit Depth گزینه‌های محدودتر پشتیبانی گسترده‌تر در برخی Codecها
B-Frame محدودیت بیشتر قابلیت‌های پیشرفته‌تر
Lookahead محدودتر یا وابسته به نرم‌افزار گزینه‌های پیشرفته‌تر
کیفیت Preset گزینه‌های ساده‌تر کنترل بهتر سرعت و کیفیت

چه عواملی کیفیت خروجی NVENC را تعیین می‌کنند؟

کیفیت خروجی فقط به نام NVENC وابسته نیست. Codec،
Bitrate، Resolution، Preset، Rate Control،
B-Frame، Lookahead و نوع محتوای تصویر نیز نقش
مهمی دارند.

عوامل مؤثر بر کیفیت Encode با NVENC
عامل اثر
نسل NVENC تعیین قابلیت‌ها و راندمان فشرده‌سازی
Codec تعیین سازگاری و بهره‌وری فشرده‌سازی
Bitrate تعیین مقدار داده قابل اختصاص به تصویر
Preset تعادل میان سرعت و کیفیت
Rate Control نحوه توزیع Bitrate میان فریم‌ها
B-Frame بهبود راندمان فشرده‌سازی
Lookahead تحلیل فریم‌های آینده برای تصمیم بهتر
محتوای تصویر حرکت سریع، Grain و جزئیات زیاد Encode را دشوارتر می‌کنند

NVENC و Encode کم‌تأخیر

یکی از کاربردهای مهم NVENC، Encode بلادرنگ با
تأخیر کم است.

در استریم بازی، Cloud Gaming، تماس تصویری و Remote
Desktop، فریم باید با فاصله زمانی کوتاهی پس از
تولید فشرده و ارسال شود.

برای کاهش تأخیر ممکن است بعضی قابلیت‌های تحلیل
پیشرفته یا تعداد B-Frameها محدود شوند؛ در نتیجه
میان Latency و راندمان فشرده‌سازی مصالحه ایجاد
می‌شود.

مقایسه تنظیمات Low-Latency و High-Quality
معیار Low-Latency High-Quality
تأخیر کمتر بیشتر
Lookahead محدود یا غیرفعال قابل استفاده
B-Frame کمتر بیشتر
راندمان فشرده‌سازی پایین‌تر بهتر
کاربرد استریم، Remote و تماس زنده Export و آرشیو

آیا NVENC هیچ فشاری بر GPU وارد نمی‌کند؟

NVENC بخش اصلی Encode را روی موتور اختصاصی انجام
می‌دهد، اما کل Workflow الزاماً بدون استفاده از
سایر بخش‌های GPU نیست.

Scaling، تبدیل رنگ، Capture، Compositing، افکت،
حذف نویز و انتقال فریم‌ها می‌توانند از Shader،
VRAM و پهنای باند حافظه استفاده کنند.

به همین دلیل هنگام استریم هم‌زمان با بازی، ممکن
است مصرف کلی GPU افزایش یابد؛ حتی اگر موتور Encode
مستقل باشد.

واحدهای درگیر در یک Workflow مبتنی بر NVENC
عملیات واحد اصلی
رندر بازی Shader، Raster، RT و حافظه
Capture فریم GPU، Driver و VRAM
Resize Shader یا واحد پردازش تصویر
تبدیل رنگ Shader یا Video Processing Unit
Encode NVENC
نگهداری Buffer VRAM

محدودیت Session در NVENC

تعداد Encodeهای هم‌زمان می‌تواند به نسل GPU،
تعداد موتورهای فیزیکی NVENC، نوع محصول، درایور،
Codec و وضوح جریان‌ها وابسته باشد.

ظرفیت سخت‌افزاری و محدودیت نرم‌افزاری همیشه یکسان
نیستند و ممکن است میان محصولات مصرف‌کننده،
حرفه‌ای و دیتاسنتر تفاوت وجود داشته باشد.

NVENC در Quadro و GPUهای قدیمی

بعضی GPUهای قدیمی NVIDIA دارای NVENC هستند، اما
کیفیت، Codecها و قابلیت‌های آن‌ها با نسل‌های جدید
یکسان نیست.

در Quadro K، M و P باید تراشه دقیق بررسی شود؛ زیرا
نام سری یا نام تجاری کارت به‌تنهایی نسل NVENC را
مشخص نمی‌کند.

نکات عمومی بررسی NVENC در GPUهای قدیمی
مورد پرسش لازم
تراشه دقیق GPU از کدام معماری و Die استفاده می‌کند؟
H.264 Encode Profile و حداکثر Resolution چیست؟
HEVC Encode آیا وجود دارد و چه Bit Depthی را پشتیبانی می‌کند؟
کیفیت Encoder نسل NVENC در Bitrate هدف چه عملکردی دارد؟
Session هم‌زمان محدودیت سخت‌افزار و درایور چیست؟
نرم‌افزار نسخه برنامه و درایور از NVENC پشتیبانی می‌کنند؟

NVIDIA NVDEC چیست؟

NVDEC مخفف NVIDIA Video Decoder
است و به موتور سخت‌افزاری اختصاصی Decode ویدئو در
بسیاری از پردازنده‌های گرافیکی NVIDIA گفته می‌شود.

این موتور وظیفه باز کردن جریان‌های فشرده ویدئویی
مانند H.264، HEVC، VP9 و AV1 را برعهده دارد و
فریم‌های خام را برای نمایش یا پردازش در اختیار
سایر بخش‌های GPU قرار می‌دهد.

وجود NVDEC باعث می‌شود پردازش ویدئوهای سنگین با
فشار بسیار کمتری بر CPU انجام شود و مصرف انرژی نیز
کاهش یابد.

مسیر Decode با NVDEC

هنگام پخش یک فایل ویدئویی، ابتدا Bitstream فشرده
وارد موتور NVDEC می‌شود. سپس این موتور فریم‌ها را
بازسازی کرده و آن‌ها را برای پردازش‌های بعدی یا
نمایش آماده می‌کند.

کاربردهای NVDEC

مهم‌ترین کاربردهای موتور NVIDIA NVDEC
کاربرد نقش NVDEC مزیت
پخش فیلم Decode فایل ویدئویی کاهش مصرف CPU
YouTube و استریم Decode آنلاین مصرف انرژی کمتر
تدوین ویدئو Decode فایل‌های پروژه Preview روان‌تر
Transcoding Decode فایل ورودی آماده‌سازی برای Encode
سیستم نظارتی Decode چند Stream افزایش تعداد کانال‌های قابل پردازش
هوش مصنوعی و Video Analytics آماده‌سازی فریم برای پردازش AI حذف بار Decode از CPU

تفاوت NVDEC و Software Decode

اگر GPU از Codec موردنظر پشتیبانی نکند، Decode
توسط CPU انجام می‌شود که به آن Software Decode
گفته می‌شود.

Software Decode در Codecهای سنگین مانند HEVC،
VP9 یا AV1 و وضوح‌های بالا می‌تواند فشار زیادی
به پردازنده وارد کند.

مقایسه Decode سخت‌افزاری و نرم‌افزاری
معیار NVDEC Software Decode
محل پردازش موتور اختصاصی GPU CPU
مصرف CPU بسیار کمتر بیشتر
مصرف انرژی کمتر بیشتر
مناسب برای چند Stream بهتر محدودتر
مناسب برای 4K و 8K بله (در صورت پشتیبانی GPU) وابسته به قدرت CPU

تفاوت NVDEC و NVENC

مقایسه دو موتور ویدئویی NVIDIA
ویژگی NVDEC NVENC
وظیفه Decode Encode
ورودی فایل فشرده فریم خام
خروجی فریم خام فایل یا Stream فشرده
کاربرد پخش ویدئو ضبط و استریم
محل استفاده ابتدای Pipeline انتهای Pipeline

چرا نسل NVDEC اهمیت دارد؟

قابلیت‌های NVDEC در نسل‌های مختلف NVIDIA یکسان
نیستند. پشتیبانی از Codec، عمق رنگ، Chroma،
وضوح، نرخ فریم و تعداد Streamهای هم‌زمان به
معماری و تراشه دقیق GPU وابسته است.

ممکن است دو کارت از یک خانواده تجاری مشابه باشند،
اما به دلیل استفاده از تراشه‌های متفاوت، موتور
Decode یکسانی نداشته باشند.

بنابراین نام‌هایی مانند GeForce، Quadro، RTX یا
Tesla به‌تنهایی برای تشخیص قابلیت‌های NVDEC کافی
نیستند.

تغییرات عمومی NVDEC در نسل‌های مختلف
ویژگی نسل‌های قدیمی‌تر نسل‌های جدیدتر
Codecهای قابل Decode بیشتر متمرکز بر MPEG و H.264 HEVC، VP9 و AV1 در نسل‌های مناسب
Bit Depth عمدتاً ۸ بیت پشتیبانی گسترده‌تر از ۱۰ بیت
Resolution محدودتر پشتیبانی بهتر از 4K و 8K
Frame Rate ظرفیت کمتر Pixel Throughput بیشتر
چند Stream هم‌زمان محدودتر ظرفیت بیشتر در مدل‌های مناسب
بهره‌وری انرژی پایین‌تر بهتر

Codecهای قابل Decode با NVDEC

مجموعه Codecهای پشتیبانی‌شده به نسل موتور NVDEC
بستگی دارد. برخی GPUها فقط Codecهای قدیمی‌تر را
Decode می‌کنند، درحالی‌که نسل‌های جدیدتر قابلیت
Decode سخت‌افزاری HEVC، VP9 و AV1 را نیز دارند.

وضعیت عمومی Codecهای قابل Decode در NVIDIA
Codec وضعیت عمومی کاربرد نکته بررسی
MPEG-2 در بسیاری از نسل‌های قدیمی و جدید DVD و Broadcast قدیمی Profile و Resolution بررسی شود
VC-1 در برخی نسل‌ها محتوای قدیمی و Blu-ray پشتیبانی به تراشه وابسته است
H.264 بسیار گسترده وب، پخش، تدوین و استریم Profile و Level بررسی شود
HEVC در نسل‌های جدیدتر 4K، HDR و فایل‌های جدید Main، Main 10 و Chroma جداگانه بررسی شوند
VP8 وابسته به نسل ویدئوی وب قدیمی‌تر قابلیت دقیق مدل بررسی شود
VP9 در نسل‌های جدیدتر YouTube و Streaming Profile 0 و Profile 2 یکسان نیستند
AV1 فقط در نسل‌های مناسب جدیدتر استریم مدرن و ویدئوی 4K یا 8K Decode و Encode AV1 جدا هستند

محدودیت Profile و Level در NVDEC

اعلام پشتیبانی از یک Codec به معنی پشتیبانی از
تمام Profileها و Levelهای آن نیست.

ممکن است NVDEC بتواند H.264 High Profile را
Decode کند، اما یک Profile حرفه‌ای‌تر یا Level
بسیار بالا را به CPU منتقل کند.

همین موضوع درباره HEVC Main 10، VP9 Profile 2
و حالت‌های حرفه‌ای‌تر AV1 نیز صدق می‌کند.

موارد لازم برای بررسی Profile و Level
مورد اثر احتمالی
Profile تعیین قابلیت‌های فعال Codec
Level تعیین سقف Resolution، Frame Rate و Bitrate
Tier تعیین محدوده Bitrate در بعضی Codecها
Bit Depth تعیین پشتیبانی ۸، ۱۰ یا ۱۲ بیت
Chroma تعیین پشتیبانی 4:2:0، 4:2:2 یا 4:4:4

پشتیبانی NVDEC از ویدئوی ۸، ۱۰ و ۱۲ بیت

بسیاری از GPUهای قدیمی Decode سخت‌افزاری ویدئوی
۸ بیت را ارائه می‌کنند، اما پشتیبانی ۱۰ بیت در
Codecهایی مانند HEVC، VP9 و AV1 به نسل‌های
جدیدتر وابسته است.

ویدئوی ۱۲ بیت و حالت‌های حرفه‌ای‌تر معمولاً
محدودیت بیشتری دارند و ممکن است به Software
Decode نیاز داشته باشند.

وضعیت عمومی Bit Depth در NVDEC
Bit Depth کاربرد وضعیت عمومی
8-bit پخش عمومی و SDR گسترده
10-bit HDR و تولید محتوای جدید وابسته به Codec و نسل GPU
12-bit Workflow حرفه‌ای و تخصصی محدودتر

پشتیبانی NVDEC از 4:2:0، 4:2:2 و 4:4:4

رایج‌ترین مسیر Hardware Decode در GPUهای مصرف‌کننده
برای ویدئوی 4:2:0 طراحی شده است.

فایل‌های 4:2:2 و 4:4:4 که در دوربین‌های حرفه‌ای،
Broadcast و VFX استفاده می‌شوند، ممکن است توسط
همه نسل‌های NVDEC پشتیبانی نشوند.

وضعیت عمومی Chroma در NVDEC
Chroma کاربرد وضعیت عمومی Decode
4:2:0 فیلم، وب و Streaming گسترده‌ترین پشتیبانی
4:2:2 دوربین حرفه‌ای و Broadcast محدودتر و وابسته به نسل
4:4:4 VFX، Keying و Mastering تخصصی‌تر و محدودتر

محدودیت Resolution و Frame Rate در NVDEC

ظرفیت NVDEC بر اساس Pixel Throughput محدود است.
هرچه تعداد پیکسل‌ها و نرخ فریم بیشتر باشند، سهم
بیشتری از توان موتور Decode مصرف می‌شود.

پشتیبانی از 4K به‌تنهایی مشخص نمی‌کند که موتور
توان Decode فایل 4K با نرخ 120fps یا چند جریان
4K هم‌زمان را دارد.

اثر Resolution و Frame Rate بر بار NVDEC
حالت بار نسبی کاربرد
1080p 30fps پایین پخش عمومی
1080p 60fps متوسط استریم بازی و آموزش
4K 30fps زیاد فیلم و تدوین
4K 60fps بسیار زیاد محتوای حرفه‌ای و Streaming
8K فوق‌سنگین تولید و پخش نسل جدید

Decode چند Stream هم‌زمان با NVDEC

NVDEC می‌تواند بسته به ظرفیت موتور، چند جریان
ویدئویی را هم‌زمان Decode کند.

تعداد واقعی Streamها به Codec، Resolution،
Frame Rate، Bit Depth، Chroma و ظرفیت حافظه
بستگی دارد.

در تدوین Multicam، سیستم نظارتی و Video Analytics،
مجموع Pixel Throughput همه جریان‌ها اهمیت دارد.

مصرف VRAM هنگام استفاده از NVDEC

پس از Decode، فریم‌ها در حافظه GPU نگهداری می‌شوند.
هرچه Resolution، Bit Depth و Chroma بیشتر باشد،
اندازه Frame Buffer افزایش پیدا می‌کند.

Codecهایی که از Reference Frameهای بیشتری استفاده
می‌کنند نیز ممکن است تعداد بیشتری فریم را هم‌زمان
در VRAM نگهداری کنند.

عوامل افزایش مصرف VRAM در NVDEC
عامل اثر
Resolution بالا افزایش اندازه هر فریم
Bit Depth بیشتر افزایش داده هر نمونه رنگ
Chroma کامل‌تر افزایش اطلاعات رنگی
Reference Frame بیشتر نگهداری فریم‌های بیشتری در حافظه
چند Stream هم‌زمان ایجاد چند مجموعه Frame Buffer
افکت و پردازش بعدی ایجاد Bufferهای اضافه

Zero-Copy Processing در NVDEC

در یک Workflow بهینه، فریم Decodeشده می‌تواند
داخل حافظه GPU باقی بماند و بدون انتقال غیرضروری
به RAM یا CPU، مستقیماً وارد CUDA، Shader،
Tensor Core یا NVENC شود.

کاهش انتقال میان حافظه سیستم و VRAM می‌تواند
Latency، مصرف پهنای باند PCI Express و بار CPU
را کاهش دهد.

ارتباط NVDEC با CUDA و Tensor Core

NVDEC فقط وظیفه Decode را انجام می‌دهد. پس از
بازسازی فریم، عملیات پردازشی می‌تواند توسط CUDA
Core، Tensor Core یا سایر واحدهای GPU ادامه پیدا
کند.

این مسیر در Video Analytics، تشخیص اشیا، Super
Resolution، حذف نویز، تبدیل رنگ و پردازش هوش
مصنوعی استفاده می‌شود.

تقسیم وظایف در پردازش ویدئویی مبتنی بر NVIDIA
مرحله واحد اصلی نمونه وظیفه
Decode NVDEC بازکردن H.264، HEVC، VP9 یا AV1
Resize و Color Conversion CUDA، Shader یا Video Processor آماده‌سازی فریم
AI Inference Tensor Core و CUDA Core تشخیص چهره یا اشیا
Encode خروجی NVENC ذخیره یا ارسال نتیجه

تفاوت NVDEC در GeForce، Quadro، RTX و کارت‌های دیتاسنتر

محصولات مختلف NVIDIA ممکن است از تراشه یا نسل
NVDEC مشابه استفاده کنند، اما ظرفیت حافظه، تعداد
موتورهای فیزیکی، درایور، پایداری و محدودیت‌های
نرم‌افزاری آن‌ها متفاوت باشد.

تفاوت‌های عمومی کلاس‌های مختلف GPU در کاربرد ویدئویی
خانواده کاربرد اصلی مزیت احتمالی نکته
GeForce بازی، استریم و تولید محتوا قیمت و عملکرد مناسب محدودیت‌ها به مدل و درایور وابسته‌اند
Quadro قدیمی CAD و ورک‌استیشن درایور حرفه‌ای و پایداری موتور ویدئو ممکن است قدیمی باشد
RTX Professional تولید محتوا و پردازش حرفه‌ای VRAM بیشتر و Workflow پایدار قابلیت دقیق به تراشه وابسته است
Tesla و Data Center Transcoding و Video Analytics ظرفیت چندجریانی و پردازش سروری بعضی مدل‌ها خروجی نمایشگر ندارند

NVDEC در Quadro و GPUهای قدیمی

GPUهای قدیمی ممکن است برای H.264 عملکرد مناسبی
داشته باشند، اما در HEVC ده‌بیتی، VP9 یا AV1
فاقد Decode سخت‌افزاری کامل باشند.

در لپ‌تاپ‌های استوک، گاهی گرافیک مجتمع Intel
Codec جدیدتری را نسبت به Quadro مجزای قدیمی
Decode می‌کند.

نرم‌افزار ممکن است بر اساس Codec و تنظیمات، میان
گرافیک مجتمع، Quadro یا CPU یکی را انتخاب کند.

نکات بررسی NVDEC در کارت‌های قدیمی
مورد پرسش لازم
تراشه دقیق کارت از چه Die و معماری استفاده می‌کند؟
H.264 حداکثر Resolution و Frame Rate چیست؟
HEVC Main و Main 10 پشتیبانی می‌شوند؟
VP9 Decode کامل، Hybrid یا Software است؟
AV1 آیا موتور اختصاصی وجود دارد؟
نرم‌افزار تدوین برنامه از NVDEC این مدل استفاده می‌کند؟
درایور نسخه نصب‌شده با نرم‌افزار سازگار است؟

چگونه فعال‌بودن NVDEC را بررسی کنیم؟

هنگام پخش یا تدوین، ابزارهای مانیتورینگ می‌توانند
میزان استفاده از Video Decode، CPU، VRAM و
موتورهای مختلف GPU را نمایش دهند.

مصرف بالای CPU همراه با استفاده بسیار کم از Video
Decode ممکن است نشان دهد فایل به‌صورت نرم‌افزاری
Decode می‌شود.

نشانه‌های فعال یا غیرفعال‌بودن Hardware Decode
نشانه تفسیر احتمالی
Video Decode Usage بالا NVDEC احتمالاً فعال است
CPU Usage پایین‌تر بخش اصلی Decode به GPU منتقل شده است
CPU Usage بسیار بالا احتمال Software Decode وجود دارد
افت فریم با Video Decode صفر Codec یا Profile پشتیبانی نمی‌شود
افزایش VRAM Frame Bufferها داخل GPU نگهداری می‌شوند
استفاده هم‌زمان از Compute افکت یا پردازش AI نیز فعال است

چرا نرم‌افزار از NVDEC استفاده نمی‌کند؟

دلایل رایج غیرفعال‌بودن NVDEC
علت توضیح اقدام پیشنهادی
Codec پشتیبانی‌نشده موتور نسل موردنظر Codec را ندارد بررسی مشخصات تراشه و فایل
Profile یا Chroma نامناسب Codec اصلی پشتیبانی می‌شود اما حالت فایل نه بررسی Media Info فایل
Hardware Acceleration خاموش تنظیم نرم‌افزار غیرفعال است فعال‌کردن Decode سخت‌افزاری
درایور قدیمی API یا قابلیت لازم در دسترس نیست نصب درایور سازگار
انتخاب GPU اشتباه برنامه روی GPU دیگری اجرا می‌شود تنظیم Graphics Preference
محدودیت نرم‌افزار برنامه از مسیر NVDEC پشتیبانی نمی‌کند بررسی نسخه یا نرم‌افزار جایگزین
افکت ناسازگار بخشی از Pipeline به CPU منتقل شده است تست فایل بدون افکت

AMD VCN چیست؟

VCN مخفف Video Core Next است و
موتور اختصاصی Encode و Decode ویدئو در بسیاری از
پردازنده‌های گرافیکی AMD محسوب می‌شود.

این موتور جانشین نسل‌های قدیمی‌تر UVD
(Unified Video Decoder) و VCE
(Video Coding Engine) شده و هر دو وظیفه Decode و
Encode را در یک مجموعه سخت‌افزاری مجتمع انجام
می‌دهد.

هدف اصلی VCN کاهش بار CPU، افزایش سرعت پردازش
ویدئو و فراهم‌کردن قابلیت Hardware Acceleration
برای نرم‌افزارهای تدوین، استریم و پخش ویدئو است.

از UVD و VCE تا VCN

AMD در نسل‌های اولیه دو موتور جداگانه برای Decode
و Encode داشت.

بعدها این دو بخش در معماری Video Core Next یا VCN
ادغام شدند تا مدیریت Codecها، مصرف انرژی و عملکرد
بهینه‌تر شود.

روند تکامل موتورهای ویدئویی AMD
نسل وظیفه توضیح
UVD Decode موتور اختصاصی Decode
VCE Encode موتور اختصاصی Encode
VCN Decode + Encode نسل جدید موتور ویدئویی AMD

مسیر پردازش ویدئو در VCN

VCN می‌تواند فایل‌های فشرده را Decode کرده،
فریم‌ها را برای پردازش آماده کند و در صورت نیاز
خروجی را دوباره Encode نماید.

کاربردهای AMD VCN

مهم‌ترین کاربردهای موتور VCN
کاربرد نقش VCN مزیت
پخش ویدئو Decode سخت‌افزاری کاهش مصرف CPU
استریم Encode زنده Latency پایین
تدوین Decode و Export Preview روان‌تر
ضبط بازی Encode تصویر افت عملکرد کمتر
Video Transcoding Decode و Encode هم‌زمان سرعت پردازش بیشتر
سیستم‌های نظارتی Decode چند Stream بار کمتر روی CPU

تفاوت AMD VCN با NVENC و NVDEC

در NVIDIA معمولاً موتورهای Encode و Decode با
نام‌های NVENC و NVDEC معرفی می‌شوند؛ اما AMD هر دو
قابلیت را در مجموعه VCN ارائه می‌کند.

مقایسه موتورهای ویدئویی AMD و NVIDIA
ویژگی AMD VCN NVIDIA
Decode VCN NVDEC
Encode VCN NVENC
معماری موتور مجتمع دو موتور مستقل
هدف Hardware Video Processing Hardware Video Processing

Codecهای پشتیبانی‌شده توسط VCN

قابلیت دقیق VCN به نسل GPU وابسته است و همه
محصولات AMD از Codecهای یکسانی پشتیبانی نمی‌کنند.

وضعیت عمومی Codecهای قابل استفاده در VCN
Codec Decode Encode توضیح
H.264 گسترده گسترده رایج‌ترین Codec
HEVC نسل‌های جدید نسل‌های جدید مناسب 4K و HDR
VP9 وابسته به نسل محدودتر بیشتر برای پخش وب
AV1 نسل‌های جدید نسل‌های جدید منتخب وابسته به معماری GPU

نسل‌های مختلف AMD VCN

AMD در طول نسل‌های مختلف معماری RDNA و Vega،
موتور Video Core Next را نیز توسعه داده است.
هر نسل علاوه بر بهبود کیفیت Encode و Decode،
قابلیت پشتیبانی از Codecهای جدید، وضوح‌های بالاتر
و مصرف انرژی کمتر را ارائه می‌دهد.

هنگام بررسی یک GPU تنها وجود عبارت VCN کافی نیست،
زیرا قابلیت‌های VCN 1.0 با VCN 4.x یا VCN 5.x
یکسان نیست.

روند تکامل نسل‌های AMD VCN
نسل ویژگی شاخص تغییرات کلی
VCN 1.x اولین نسل Video Core Next جایگزینی UVD و VCE
VCN 2.x بهبود Codecها افزایش کارایی Decode و Encode
VCN 3.x پشتیبانی گسترده‌تر از AV1 بهبود پردازش ویدئوی نسل جدید
VCN 4.x و جدیدتر افزایش Throughput بهینه‌سازی برای تولید محتوای حرفه‌ای

پشتیبانی Codecها در نسل‌های مختلف VCN

هر نسل VCN ممکن است Codecهای متفاوتی را برای
Decode یا Encode سخت‌افزاری پشتیبانی کند.

حتی در یک Codec مشترک نیز امکان تفاوت در Bit Depth،
Chroma، Profile، Level و Resolution وجود دارد.

نکات بررسی پشتیبانی Codec در VCN
Codec موارد قابل بررسی اهمیت
H.264 Profile، Level و Resolution سازگاری عمومی
HEVC Main، Main 10 و HDR تولید محتوای 4K
VP9 Profileها پخش آنلاین
AV1 Decode و Encode مستقل نسل جدید Streaming

پشتیبانی Bit Depth در AMD VCN

توانایی Decode یا Encode ویدئوهای ۸، ۱۰ و ۱۲ بیت
به نسل موتور VCN و Codec انتخاب‌شده وابسته است.

در Workflowهای HDR معمولاً استفاده از ۱۰ بیت اهمیت
بیشتری دارد و باید مشخصات دقیق GPU بررسی شود.

وضعیت عمومی Bit Depth در VCN
Bit Depth کاربرد وضعیت کلی
8-bit ویدئوی SDR پشتیبانی گسترده
10-bit HDR وابسته به نسل VCN
12-bit تولید حرفه‌ای محدودتر

پشتیبانی Chroma Subsampling

همانند سایر موتورهای سخت‌افزاری، بیشترین تمرکز
VCN روی فایل‌های 4:2:0 است.

فایل‌های 4:2:2 و 4:4:4 در بعضی Workflowهای
Broadcast و تولید حرفه‌ای استفاده می‌شوند و
پشتیبانی آن‌ها به نسل GPU وابسته است.

وضعیت عمومی Chroma در VCN
Chroma کاربرد وضعیت کلی
4:2:0 فیلم و Streaming رایج‌ترین حالت
4:2:2 Broadcast وابسته به نسل
4:4:4 VFX و Mastering محدودتر

محدودیت Resolution و Frame Rate

ظرفیت واقعی VCN تنها با عبارت «پشتیبانی از 4K»
مشخص نمی‌شود.

تعداد پیکسل، نرخ فریم، Codec، Bit Depth و تعداد
Streamهای هم‌زمان همگی بر توان موتور ویدئویی
تأثیر می‌گذارند.

اثر وضوح و نرخ فریم بر بار VCN
حالت بار نسبی توضیح
1080p 30fps کم پخش عمومی
1080p 60fps متوسط استریم
4K 60fps زیاد تولید محتوا
8K بسیار زیاد نسل‌های جدید

پردازش چند Stream هم‌زمان

VCN می‌تواند چند جریان ویدئویی را به‌صورت هم‌زمان
Decode یا Encode کند؛ اما ظرفیت واقعی به مدل GPU،
نسل VCN، Codec و Resolution وابسته است.

VCN در برابر Software Processing

اگر فایل ویدئویی توسط VCN پشتیبانی نشود، بخشی از
عملیات Encode یا Decode ممکن است به CPU منتقل شود.

مقایسه Hardware و Software Video Processing
معیار VCN CPU
مصرف CPU کمتر بیشتر
مصرف انرژی کمتر بیشتر
چند Stream بهتر محدودتر
مناسب برای Export بله وابسته به توان پردازنده

Intel Quick Sync Video چیست؟

Quick Sync Video یا QSV نام مجموعه قابلیت‌های
سخت‌افزاری Intel برای Decode، Encode و پردازش
ویدئو در بسیاری از پردازنده‌های دارای گرافیک
مجتمع و همچنین بعضی GPUهای مجزای Intel است.

این فناوری از موتورهای اختصاصی رسانه استفاده
می‌کند و می‌تواند عملیات مربوط به Codecهای ویدئویی
را بدون درگیرکردن کامل هسته‌های CPU یا واحدهای
عمومی گرافیکی انجام دهد.

Quick Sync در پخش فیلم، تدوین، استریم، ضبط صفحه،
تماس تصویری، Transcoding و تبدیل گروهی فایل‌های
ویدئویی کاربرد دارد.

Quick Sync در کدام بخش سخت‌افزار قرار دارد؟

در بسیاری از پردازنده‌های Intel، موتور رسانه در
بخش گرافیک مجتمع قرار دارد و از هسته‌های پردازشی
CPU جدا است.

در کارت‌های Intel Arc نیز موتورهای رسانه اختصاصی
داخل GPU مجزا قرار گرفته‌اند و می‌توانند مستقل از
گرافیک مجتمع پردازنده فعالیت کنند.

وجود پردازنده Intel به‌تنهایی تضمین نمی‌کند که
Quick Sync در دسترس باشد. مدل پردازنده، فعال‌بودن
گرافیک مجتمع، BIOS، درایور و نرم‌افزار هدف نیز
اهمیت دارند.

مسیر پردازش ویدئو با Quick Sync

در یک عملیات Transcoding، موتور Decode ابتدا فایل
ورودی را به فریم تبدیل می‌کند.

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

کاربردهای Intel Quick Sync

کاربردهای رایج Quick Sync Video
کاربرد نقش Quick Sync مزیت اصلی
پخش ویدئو Decode فایل فشرده مصرف کمتر CPU و باتری
تدوین Decode فایل‌های Timeline Preview روان‌تر
Export Encode خروجی کاهش زمان خروجی
استریم زنده Encode بلادرنگ فشار کمتر بر CPU
ضبط صفحه فشرده‌سازی تصویر دسکتاپ مصرف انرژی پایین‌تر
تماس تصویری Decode و Encode دوطرفه تأخیر و مصرف کمتر
Transcoding Server تبدیل چند فایل پردازش چند جریان هم‌زمان
Media Server تبدیل ویدئو برای دستگاه‌های مختلف کاهش بار پردازنده مرکزی

تفاوت Quick Sync و پردازش نرم‌افزاری CPU

Encode و Decode نرم‌افزاری روی CPU با اجرای
دستورهای عمومی انجام می‌شود و می‌تواند انعطاف
زیادی داشته باشد.

Quick Sync همان عملیات را با مدار اختصاصی انجام
می‌دهد و معمولاً سرعت بالاتر و مصرف انرژی کمتری
ارائه می‌کند.

مقایسه Quick Sync و پردازش نرم‌افزاری CPU
معیار Quick Sync CPU Software Processing
سرعت معمولاً بیشتر وابسته به CPU و Preset
مصرف CPU کمتر بیشتر
مصرف انرژی معمولاً کمتر بیشتر
انعطاف تنظیمات محدود به موتور و درایور معمولاً بیشتر
کیفیت در Preset بسیار کند وابسته به نسل موتور ممکن است بالاتر باشد
پردازش چند Stream مناسب‌تر در بسیاری از کاربردها به تعداد هسته‌های CPU وابسته است

تفاوت Quick Sync با Execution Unit و Xe Core

Execution Unitها و Xe Coreها واحدهای پردازشی
عمومی‌تری هستند که Shader، Compute، افکت و عملیات
قابل برنامه‌ریزی را اجرا می‌کنند.

موتور Quick Sync برای عملیات مشخص Codec طراحی شده
و نمی‌تواند جایگزین واحدهای عمومی در تمام مراحل
تدوین یا پردازش تصویر شود.

مقایسه موتور رسانه Intel با واحدهای عمومی GPU
معیار Quick Sync Execution Unit یا Xe Core
وظیفه اصلی Encode و Decode Codecها Shader، Compute و افکت
نوع سخت‌افزار مدار تخصصی واحد قابل برنامه‌ریزی
Scaling و افکت بخشی از مسیر رسانه یا واحدهای جانبی قابل انجام با Shader
انعطاف محدودتر بیشتر
بهره‌وری Encode بالا معمولاً پایین‌تر از موتور اختصاصی

چرا نسل Quick Sync اهمیت دارد؟

Intel در نسل‌های مختلف پردازنده و GPU، موتور رسانه
را توسعه داده و قابلیت‌های جدیدی مانند HEVC،
VP9، AV1، عمق رنگ بالاتر و ظرفیت بیشتر پردازش را
اضافه کرده است.

دو پردازنده Intel با نام Core i7 ممکن است به دلیل
تفاوت نسل، قابلیت‌های ویدئویی کاملاً متفاوتی داشته
باشند.

شماره خانواده پردازنده، نسل گرافیک مجتمع و مدل
دقیق Media Engine باید بررسی شوند.

تغییرات عمومی Quick Sync میان نسل‌ها
ویژگی نسل‌های قدیمی‌تر نسل‌های جدیدتر
Codecها بیشتر متمرکز بر MPEG و H.264 HEVC، VP9 و AV1 در نسل‌های مناسب
Bit Depth عمدتاً ۸ بیت پشتیبانی گسترده‌تر از ۱۰ بیت
Resolution محدودتر پشتیبانی بهتر از 4K و 8K
کیفیت Encode ساده‌تر بهبود‌یافته
چند Stream ظرفیت کمتر Throughput بیشتر
بهره‌وری انرژی پایین‌تر بهتر

Codecهای قابل استفاده با Quick Sync

پشتیبانی دقیق Codecها به نسل پردازنده، گرافیک
مجتمع یا GPU مجزای Intel وابسته است.

Decode و Encode هر Codec باید جداگانه بررسی شوند؛
زیرا ممکن است یک نسل فقط Decode سخت‌افزاری یک
Codec را ارائه دهد.

وضعیت عمومی Codecها در Quick Sync
Codec Decode Encode نکته
MPEG-2 در بسیاری از نسل‌ها وابسته به نسل و نرم‌افزار مناسب محتوای قدیمی
H.264 بسیار گسترده بسیار گسترده Profile و کیفیت به نسل وابسته است
HEVC در نسل‌های جدیدتر در نسل‌های مناسب Main 10 و Chroma بررسی شوند
VP9 در نسل‌های جدیدتر محدودتر بیشتر برای پخش وب اهمیت دارد
AV1 در نسل‌های جدید در GPUهای جدید منتخب Decode و Encode AV1 جدا هستند
JPEG و MJPEG وابسته به موتور و API وابسته به محصول کاربرد در دوربین و پردازش تصویر

تفاوت Decode و Encode در Quick Sync

مقایسه دو مسیر اصلی Quick Sync
معیار Hardware Decode Hardware Encode
ورودی جریان فشرده فریم خام یا پردازش‌شده
خروجی Frame Buffer Bitstream فشرده
کاربرد پخش، Preview و Timeline Export، ضبط و استریم
حساسیت به نسل Codec و Throughput Codec، کیفیت و Rate Control
دسترسی زودتر در نسل‌ها معمولاً Decode ممکن است دیرتر اضافه شود

پشتیبانی Quick Sync از ویدئوی ۸، ۱۰ و ۱۲ بیت

نسل‌های قدیمی‌تر Quick Sync بیشتر برای ویدئوی
۸ بیت طراحی شده بودند.

با گسترش HEVC، VP9، AV1 و HDR، پشتیبانی از ۱۰ بیت
در نسل‌های جدیدتر اهمیت بیشتری پیدا کرد.

پشتیبانی ۱۲ بیت و حالت‌های حرفه‌ای‌تر همچنان باید
برای Codec و محصول دقیق بررسی شود.

وضعیت عمومی Bit Depth در Quick Sync
عمق رنگ کاربرد وضعیت عمومی
8-bit SDR و استفاده عمومی گسترده
10-bit HDR و تدوین جدید وابسته به نسل و Codec
12-bit Workflow تخصصی محدودتر

پشتیبانی Quick Sync از 4:2:0، 4:2:2 و 4:4:4

بیشترین پشتیبانی سخت‌افزاری در Quick Sync معمولاً
مربوط به محتوای 4:2:0 است.

ویدئوهای 4:2:2 و 4:4:4 که در دوربین‌های حرفه‌ای،
Broadcast، Keying و VFX استفاده می‌شوند، ممکن است
فقط در نسل‌ها یا محصولات خاص شتاب‌دهی کامل داشته
باشند.

وضعیت عمومی Chroma در Quick Sync
Chroma کاربرد وضعیت عمومی
4:2:0 پخش، وب و استریم گسترده‌ترین پشتیبانی
4:2:2 دوربین حرفه‌ای و Broadcast وابسته به نسل و Codec
4:4:4 VFX، متن و Mastering محدودتر و تخصصی‌تر

آیا برای استفاده از Quick Sync باید گرافیک مجتمع فعال باشد؟

در سیستم‌هایی که Quick Sync داخل گرافیک مجتمع
پردازنده قرار دارد، معمولاً iGPU باید توسط BIOS
و سیستم‌عامل شناسایی و درایور آن نصب شده باشد.

در بعضی مادربردها، نصب کارت گرافیک مجزا باعث
غیرفعال‌شدن خودکار iGPU می‌شود و Quick Sync نیز
از دسترس نرم‌افزار خارج می‌شود.

گزینه‌هایی مانند Integrated Graphics،
iGPU Multi-Monitor یا Internal Graphics می‌توانند
برای فعال نگه‌داشتن موتور رسانه لازم باشند.

پردازنده‌های Intel بدون گرافیک مجتمع و Quick Sync

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

در چنین مدل‌هایی، Quick Sync مبتنی بر iGPU نیز
در دسترس نیست و برای Encode یا Decode سخت‌افزاری
باید از GPU مجزا یا CPU استفاده شود.

بنابراین پیش از خرید پردازنده برای تدوین، استریم
یا Media Server باید وجود گرافیک مجتمع و قابلیت
Quick Sync مدل دقیق بررسی شود.

استفاده هم‌زمان از Quick Sync و GPU مجزا

در یک سیستم تدوین، ممکن است Quick Sync وظیفه
Decode یا Encode را انجام دهد و کارت NVIDIA یا AMD
برای افکت، Color Grading، رندر و پردازش Compute
استفاده شود.

این تقسیم وظایف می‌تواند ظرفیت کل سیستم را افزایش
دهد، اما نیازمند پشتیبانی صحیح نرم‌افزار و درایور
است.

Quick Sync در لپ‌تاپ‌ها

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

Quick Sync می‌تواند هنگام پخش ویدئو یا تماس تصویری
به‌جای GPU مجزای پرمصرف استفاده شود و عمر باتری را
افزایش دهد.

در لپ‌تاپ‌های ورک‌استیشن قدیمی، ممکن است گرافیک
مجتمع Intel Codec جدیدتری را نسبت به Quadro مجزا
پشتیبانی کند.

مزایای Quick Sync در لپ‌تاپ
مزیت نتیجه
Decode کم‌مصرف افزایش عمر باتری
فعال‌نشدن GPU مجزا دما و صدای کمتر
Encode سریع خروجی سریع‌تر در دستگاه کم‌مصرف
تقسیم بار آزادماندن GPU مجزا برای افکت
پخش Codec جدیدتر برتری احتمالی نسبت به GPU مجزای قدیمی

Quick Sync در سیستم‌ها و لپ‌تاپ‌های قدیمی

نسل‌های قدیمی Quick Sync معمولاً برای H.264 بسیار
مفید هستند، اما ممکن است HEVC ده‌بیتی، VP9 یا AV1
را به‌صورت کامل پشتیبانی نکنند.

در ورک‌استیشن‌های استوک، باید نسل پردازنده در کنار
مدل Quadro یا Radeon Pro بررسی شود؛ زیرا موتور
رسانه iGPU ممکن است نقش مهمی در تدوین و پخش داشته
باشد.

نکات بررسی Quick Sync در سیستم قدیمی
مورد پرسش لازم
نسل CPU موتور رسانه متعلق به کدام نسل است؟
مدل iGPU گرافیک مجتمع دقیقاً چه مدلی است؟
H.264 Decode و Encode در چه Resolutionی انجام می‌شوند؟
HEVC Main و Main 10 پشتیبانی می‌شوند؟
VP9 و AV1 Hardware Decode وجود دارد؟
BIOS گرافیک مجتمع فعال است؟
درایور نسخه مناسب Intel Graphics نصب شده است؟
نرم‌افزار برنامه از QSV این نسل پشتیبانی می‌کند؟

چگونه فعال‌بودن Quick Sync را بررسی کنیم؟

هنگام پخش، Export یا Transcoding می‌توان فعالیت
موتورهای Video Decode و Video Encode گرافیک Intel
را در ابزارهای مانیتورینگ بررسی کرد.

کاهش مصرف CPU همراه با افزایش فعالیت موتور رسانه
می‌تواند نشان دهد Quick Sync در حال استفاده است.

نشانه‌های استفاده از Quick Sync
نشانه تفسیر
Video Decode فعال Decode سخت‌افزاری در حال انجام است
Video Encode فعال خروجی با Quick Sync ساخته می‌شود
مصرف CPU کمتر بخشی از پردازش به موتور رسانه منتقل شده است
فعالیت iGPU با GPU مجزا Quick Sync در کنار کارت مجزا فعال است
Video Engine بدون 3D Load زیاد موتور اختصاصی مستقل از رندر سه‌بعدی کار می‌کند

چرا Quick Sync در نرم‌افزار فعال نمی‌شود؟

دلایل رایج غیرفعال‌بودن Quick Sync
علت توضیح اقدام پیشنهادی
نبود iGPU مدل پردازنده گرافیک مجتمع ندارد بررسی مشخصات مدل دقیق CPU
iGPU غیرفعال BIOS گرافیک مجتمع را خاموش کرده است فعال‌کردن Integrated Graphics
درایور نصب نیست موتور رسانه توسط سیستم شناسایی نمی‌شود نصب درایور Intel Graphics
Codec پشتیبانی‌نشده نسل QSV از حالت فایل پشتیبانی نمی‌کند بررسی Codec، Profile و Bit Depth
Hardware Acceleration خاموش تنظیمات نرم‌افزار غیرفعال است فعال‌کردن QSV در تنظیمات برنامه
نسخه نرم‌افزار قدیمی موتور جدیدتر را پشتیبانی نمی‌کند به‌روزرسانی نرم‌افزار
انتخاب Encoder دیگر برنامه از CPU یا GPU مجزا استفاده می‌کند انتخاب Intel Quick Sync
محدودیت سیستم مجازی موتور رسانه به ماشین مجازی منتقل نشده است بررسی قابلیت Passthrough

تکامل Quick Sync Video در نسل‌های مختلف Intel

Quick Sync از زمان معرفی تاکنون در هر نسل پردازنده
Intel بهبود یافته است. این بهبودها شامل افزایش
کیفیت Encode، پشتیبانی از Codecهای جدید، افزایش
ظرفیت Decode و کاهش مصرف انرژی هستند.

بنابراین هنگام مقایسه دو پردازنده Intel، نسل
Media Engine اهمیت بیشتری از نام تجاری Core i5،
Core i7 یا Core Ultra دارد.

روند کلی پیشرفت Quick Sync
نسل مهم‌ترین تغییر نتیجه
نسل‌های اولیه تمرکز بر H.264 Encode و Decode سریع‌تر
نسل‌های میانی پشتیبانی HEVC و VP9 آماده برای 4K و HDR
نسل‌های جدید پشتیبانی AV1 Streaming و تولید محتوای نسل جدید
Intel Arc و Core Ultra Media Engine پیشرفته‌تر کیفیت بهتر و ظرفیت بیشتر

اهمیت Profile و Level در Quick Sync

پشتیبانی از یک Codec به این معنی نیست که تمامی
Profileها و Levelهای آن نیز توسط موتور رسانه
Intel پشتیبانی می‌شوند.

ممکن است یک پردازنده H.265 را Decode کند اما از
Main 10، Profileهای خاص یا Resolutionهای بالاتر
پشتیبانی کامل نداشته باشد.

پارامترهای مؤثر بر Hardware Decode
پارامتر تأثیر
Codec تعیین نوع فشرده‌سازی
Profile تعیین قابلیت‌های Codec
Level تعیین سقف Resolution و Bitrate
Bit Depth تعیین عمق رنگ
Chroma تعیین ساختار نمونه‌برداری رنگ

پشتیبانی از Resolutionهای مختلف

ظرفیت واقعی موتور رسانه تنها با عبارت
«پشتیبانی از 4K» مشخص نمی‌شود.

نرخ فریم، تعداد Stream، Codec و Bit Depth نیز
در میزان بار پردازشی Quick Sync نقش دارند.

اثر Resolution بر بار موتور رسانه
حالت بار نسبی نمونه کاربرد
1080p پایین پخش عمومی
1440p متوسط تولید محتوا
4K زیاد تدوین و HDR
8K بسیار زیاد Workflow حرفه‌ای

پردازش چند Stream هم‌زمان

موتور Quick Sync می‌تواند هم‌زمان چند جریان
ویدئویی را Decode یا Encode کند، اما ظرفیت واقعی
به نسل Media Engine، Codec، وضوح تصویر و حافظه
سیستم بستگی دارد.

مصرف حافظه در Quick Sync

هنگام Decode، فریم‌های خام داخل حافظه گرافیکی
ذخیره می‌شوند و هرچه Resolution، Bit Depth و
Chroma بیشتر باشد، فضای بیشتری اشغال خواهد شد.

عوامل افزایش مصرف حافظه
عامل اثر
Resolution بالاتر افزایش اندازه Frame Buffer
Bit Depth بیشتر داده بیشتر در هر پیکسل
Chroma کامل‌تر افزایش اطلاعات رنگ
چند Stream ایجاد چند Buffer هم‌زمان

Zero-Copy Processing در Quick Sync

در بسیاری از Workflowهای حرفه‌ای، فریم Decodeشده
مستقیماً داخل حافظه گرافیکی باقی می‌ماند و بدون
انتقال غیرضروری به RAM وارد مراحل بعدی پردازش
می‌شود.

این روش موجب کاهش Latency، کاهش استفاده از
گذرگاه حافظه و افزایش سرعت Export خواهد شد.

استفاده Quick Sync در نرم‌افزارهای حرفه‌ای

بسیاری از نرم‌افزارهای تدوین، تبدیل و استریم
از Quick Sync برای Decode، Preview یا Export
استفاده می‌کنند.

نمونه کاربرد Quick Sync در نرم‌افزارها
نرم‌افزار کاربرد Quick Sync
Adobe Premiere Pro Decode و Export
DaVinci Resolve Decode بعضی Codecها
HandBrake Hardware Transcoding
OBS Studio Encode برای استریم
FFmpeg Decode و Encode سخت‌افزاری

Codecهای ویدئویی (Video Codecs)

Codecهای ویدئویی روش فشرده‌سازی و بازیابی داده‌های
تصویری را مشخص می‌کنند. تقریباً تمام موتورهای
سخت‌افزاری مانند NVIDIA NVENC، NVDEC،
AMD VCN و Intel Quick Sync بر اساس Codecهای
مختلف کار می‌کنند.

Codec ویدئویی چیست؟

واژه Codec از ترکیب دو عبارت
Coder و
Decoder
ساخته شده است.

Codec مشخص می‌کند داده‌های تصویری چگونه
فشرده شوند، چگونه ذخیره شوند و هنگام پخش
چگونه دوباره به تصویر قابل نمایش تبدیل شوند.

بدون Codec حجم فایل‌های ویدئویی چندین برابر
افزایش پیدا می‌کند و انتقال یا ذخیره آن‌ها
بسیار دشوار خواهد بود.

چرا ویدئو باید فشرده شود؟

هر فریم ویدئو از میلیون‌ها پیکسل تشکیل شده است.
ذخیره هزاران فریم بدون فشرده‌سازی به فضای
بسیار زیادی نیاز دارد.

Codecها اطلاعات تکراری میان پیکسل‌ها و میان
فریم‌های متوالی را حذف یا بازنویسی می‌کنند تا
حجم فایل کاهش یابد.

تفاوت Encode و Decode

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

تفاوت Encode و Decode
ویژگی Encode Decode
ورودی تصویر خام فایل فشرده
خروجی فایل فشرده فریم خام
کاربرد ذخیره و استریم نمایش و تدوین

مسیر کلی پردازش Codec

Codecهای Lossy و Lossless

برخی Codecها برای کاهش شدید حجم، بخشی از اطلاعات
تصویر را حذف می‌کنند. این گروه را
Lossy می‌نامند.

گروه دیگر اطلاعات تصویر را بدون حذف دائمی
ذخیره می‌کنند و به آن‌ها
Lossless
گفته می‌شود.

مقایسه Codecهای Lossy و Lossless
ویژگی Lossy Lossless
حجم فایل کمتر بیشتر
کیفیت کاهش احتمالی حفظ کامل اطلاعات
کاربرد وب و استریم آرشیو و تولید حرفه‌ای

تفاوت Intra-frame و Inter-frame

بعضی Codecها هر فریم را مستقل ذخیره می‌کنند که
به آن Intra-frame گفته می‌شود.

Codecهای دیگر اطلاعات فریم‌های قبلی و بعدی را
نیز برای کاهش حجم استفاده می‌کنند که به آن
Inter-frame گفته می‌شود.

مقایسه دو روش فشرده‌سازی
ویژگی Intra-frame Inter-frame
هر فریم مستقل بله خیر
حجم فایل بیشتر کمتر
مناسب تدوین بسیار مناسب نیازمند Decode بیشتر

H.264 / AVC

H.264 که با نام Advanced Video Coding یا AVC نیز
شناخته می‌شود، یکی از موفق‌ترین و پراستفاده‌ترین
Codecهای ویدئویی تاریخ است و هنوز هم در وب،
استریم، دوربین‌ها، تماس تصویری، سیستم‌های نظارتی
و بسیاری از نرم‌افزارهای تدوین استفاده می‌شود.

H.264 چیست؟

H.264 یک استاندارد فشرده‌سازی ویدئو است که توسط
گروه‌های استانداردسازی ITU-T و ISO/IEC توسعه داده
شد.

هدف این استاندارد، کاهش حجم فایل بدون افت شدید
کیفیت تصویر و فراهم‌کردن امکان انتقال ویدئو روی
اینترنت، رسانه‌های ذخیره‌سازی و شبکه‌های مخابراتی
است.

تقریباً تمام GPUهای امروزی دارای موتور سخت‌افزاری
برای Decode و Encode فایل‌های H.264 هستند.

چرا H.264 این‌قدر محبوب شد؟

H.264 نسبت به نسل‌های قدیمی‌تر مانند MPEG-2
کیفیت مشابهی را با حجم بسیار کمتر ارائه می‌دهد.

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

دلایل محبوبیت H.264
عامل توضیح
حجم کم کاهش قابل توجه اندازه فایل
کیفیت مناسب کیفیت بالا نسبت به Bitrate
سازگاری گسترده تقریباً تمام دستگاه‌ها
Hardware Acceleration پشتیبانی توسط اکثر GPUها
اکوسیستم نرم‌افزاری پشتیبانی تقریباً همه برنامه‌ها

مسیر پردازش H.264

کاربردهای H.264

مهم‌ترین کاربردهای H.264
حوزه کاربرد
YouTube بارگذاری ویدئو
تماس تصویری Zoom، Teams و Meet
دوربین‌های دیجیتال ضبط ویدئو
سیستم‌های نظارتی ذخیره تصاویر دوربین
استریم زنده Twitch و بسیاری از سرویس‌ها
تدوین ویدئو فایل ورودی و خروجی

پشتیبانی سخت‌افزاری H.264

تقریباً تمام موتورهای رسانه امروزی از H.264
پشتیبانی می‌کنند و این Codec به استاندارد مشترک
صنعت تبدیل شده است.

پشتیبانی H.264 در موتورهای سخت‌افزاری
موتور رسانه Decode Encode
NVIDIA NVDEC / NVENC بله بله
AMD VCN بله بله
Intel Quick Sync بله بله
Apple Video Engine بله بله

مزایای H.264

مزیت‌های H.264
مزیت توضیح
سازگاری بسیار بالا تقریباً همه دستگاه‌ها
کیفیت مناسب نسبت خوب کیفیت به حجم
سرعت Decode پشتیبانی سخت‌افزاری گسترده
مناسب Streaming Bitrate انعطاف‌پذیر
نرم‌افزارهای فراوان پشتیبانی کامل اکثر برنامه‌ها

محدودیت‌های H.264

با وجود محبوبیت بالا، H.264 نسبت به Codecهای
جدید مانند HEVC و AV1 راندمان فشرده‌سازی پایین‌تری
دارد.

محدودیت‌های H.264
محدودیت اثر
حجم بیشتر نسبت به HEVC Bitrate بالاتر
راندمان کمتر از AV1 فایل بزرگ‌تر
محدودیت در Workflowهای جدید مناسب نبودن برای بعضی پروژه‌های 8K

Profile در H.264 چیست؟

Profile مجموعه‌ای از قابلیت‌های مجاز در استاندارد
H.264 است و مشخص می‌کند Encoder و Decoder باید از
چه ویژگی‌هایی پشتیبانی کنند.

دو فایل H.264 ممکن است کاملاً متفاوت باشند؛ زیرا
یکی با Baseline Profile و دیگری با High Profile
تولید شده است.

معروف‌ترین Profileهای H.264
Profile کاربرد ویژگی
Baseline تماس تصویری و موبایل ساده و کم‌مصرف
Main تلویزیون و Broadcast فشرده‌سازی بهتر
High Blu-ray و Streaming کیفیت بالاتر
High 10 تولید حرفه‌ای پشتیبانی از 10-bit
High 4:2:2 Broadcast Chroma حرفه‌ای
High 4:4:4 VFX و Mastering کیفیت بسیار بالا

Level در H.264 چیست؟

Level محدودیت‌های سخت‌افزاری و عملیاتی فایل را
مشخص می‌کند؛ مانند بیشترین Resolution، نرخ فریم،
تعداد Macroblockها و Bitrate.

ممکن است دو فایل هر دو High Profile باشند اما
یکی Level 4.1 و دیگری Level 5.2 داشته باشد که
نیازمندی سخت‌افزاری متفاوتی ایجاد می‌کند.

نمونه‌ای از Levelهای H.264
Level کاربرد رایج ظرفیت کلی
3.1 HD متوسط
4.0 Full HD بالا
5.1 4K بسیار بالا
5.2 4K با نرخ فریم بیشتر بسیار زیاد

ساختار Bitstream در H.264

خروجی Encoder مجموعه‌ای از واحدهای داده است که
Bitstream نامیده می‌شود.

این Bitstream شامل اطلاعات تصویر، پارامترهای Codec،
Headerها و داده‌های موردنیاز Decoder است.

NAL Unit چیست؟

Network Abstraction Layer یا NAL لایه‌ای است که
داده‌های فشرده H.264 را برای انتقال و ذخیره‌سازی
بسته‌بندی می‌کند.

تقریباً تمام فایل‌های H.264 از مجموعه‌ای از
NAL Unitها تشکیل شده‌اند.

انواع متداول NAL Unit
نوع وظیفه
SPS اطلاعات کلی ویدئو
PPS پارامترهای تصویر
Slice داده تصویری
SEI اطلاعات جانبی

SPS و PPS چه هستند؟

Decoder قبل از Decode تصویر باید پارامترهای اصلی
فایل را دریافت کند.

این اطلاعات داخل Sequence Parameter Set و Picture
Parameter Set قرار می‌گیرند.

تفاوت SPS و PPS
بخش اطلاعات
SPS Resolution، Profile، Level و…
PPS پارامترهای مربوط به Sliceها

Macroblock در H.264

یکی از واحدهای اصلی پردازش در H.264، Macroblock
است که معمولاً ناحیه‌ای 16×16 پیکسلی را نمایش
می‌دهد.

بسیاری از مراحل Encode مانند Motion Estimation،
Prediction و Transform بر اساس Macroblock انجام
می‌شوند.

انواع فریم در H.264

یکی از مهم‌ترین دلایل حجم پایین فایل‌های H.264،
استفاده از چند نوع فریم مختلف است.

تمام فریم‌ها اطلاعات کامل تصویر را ذخیره نمی‌کنند.
بعضی فریم‌ها تنها تغییرات نسبت به فریم‌های دیگر را
ثبت می‌کنند.

انواع اصلی فریم در H.264
نوع فریم وابستگی حجم تقریبی کاربرد
I-Frame مستقل زیاد شروع گروه فریم
P-Frame وابسته به گذشته متوسط ثبت تغییرات
B-Frame وابسته به گذشته و آینده کم بیشترین فشرده‌سازی

I-Frame چیست؟

I-Frame یا Intra Frame تصویری کامل و مستقل است که
بدون نیاز به سایر فریم‌ها Decode می‌شود.

این فریم‌ها معمولاً بزرگ‌ترین حجم را دارند اما
سریع‌ترین نقطه برای شروع پخش یا جابه‌جایی در
Timeline هستند.

ویژگی‌های I-Frame
وابستگی ندارد
کیفیت کامل
حجم زیاد
مناسب برای Seek بله

P-Frame چیست؟

P-Frame فقط تغییرات نسبت به فریم‌های قبلی را ذخیره
می‌کند.

اگر بخشی از تصویر ثابت باشد، Encoder دوباره آن را
ذخیره نمی‌کند و تنها اختلاف‌ها ثبت می‌شوند.

B-Frame چیست؟

B-Frame علاوه بر فریم گذشته، از فریم آینده نیز برای
پیش‌بینی تصویر استفاده می‌کند.

همین موضوع باعث می‌شود حجم فایل کاهش یابد اما
عملیات Decode پیچیده‌تر شود.

GOP چیست؟

Group of Pictures یا GOP مجموعه‌ای از فریم‌های
وابسته به یک I-Frame است.

هرچه فاصله بین I-Frameها بیشتر باشد، حجم فایل کمتر
می‌شود اما جابه‌جایی و ویرایش فایل دشوارتر خواهد شد.

مقایسه I، P و B Frame

مقایسه سه نوع اصلی فریم
ویژگی I P B
وابستگی ندارد گذشته گذشته و آینده
حجم زیاد متوسط کم
کیفیت مستقل کامل خیر خیر
سرعت Seek بسیار خوب متوسط ضعیف
فشرده‌سازی کم خوب بسیار زیاد

Motion Estimation چیست؟

Motion Estimation فرآیندی است که Encoder حرکت
اشیاء را بین فریم‌های متوالی پیدا می‌کند.

به‌جای ذخیره مجدد کل تصویر، تنها بردار حرکت
(Motion Vector) ذخیره می‌شود.

Motion Compensation چیست؟

پس از یافتن بردار حرکت، Decoder تصویر جدید را با
استفاده از اطلاعات فریم قبلی و Motion Vector
بازسازی می‌کند.

این روش یکی از مهم‌ترین دلایل کاهش حجم فایل‌های
H.264 محسوب می‌شود.

Motion Vector چیست؟

Motion Vector برداری است که جهت و مقدار جابه‌جایی
هر Macroblock را نسبت به فریم مرجع نشان می‌دهد.

به‌جای ذخیره دوباره تصویر، تنها این بردارها ذخیره
می‌شوند که حجم فایل را به‌شدت کاهش می‌دهد.

تفاوت CABAC و CAVLC

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

H.264 دو روش اصلی برای این کار دارد:
CAVLC و CABAC.

مقایسه CABAC و CAVLC
ویژگی CAVLC CABAC
پیچیدگی کمتر بیشتر
سرعت Encode بیشتر کمتر
راندمان فشرده‌سازی کمتر بیشتر
حجم فایل بزرگ‌تر کوچک‌تر

Reference Frame چیست؟

هنگام Encode، بسیاری از فریم‌ها به‌صورت مستقل
ذخیره نمی‌شوند؛ بلکه از یک یا چند فریم قبلی به
عنوان مرجع (Reference Frame) استفاده می‌کنند.

هرچه تعداد Reference Frameها بیشتر باشد، Encoder
می‌تواند تطابق دقیق‌تری پیدا کند، اما عملیات
Encode و Decode پیچیده‌تر خواهد شد.

Multiple Reference Frame

H.264 می‌تواند به‌جای یک فریم مرجع، از چندین
Reference Frame استفاده کند.

این قابلیت کیفیت فشرده‌سازی را افزایش می‌دهد،
اما حافظه، توان پردازشی و زمان Encode بیشتری
نیاز خواهد داشت.

اثر تعداد Reference Frameها
تعداد مرجع کیفیت سرعت حافظه
1 مناسب سریع کم
چند مرجع بهتر کندتر بیشتر

Transform در H.264

پس از پیش‌بینی تصویر، اختلاف میان تصویر واقعی و
تصویر پیش‌بینی‌شده وارد مرحله Transform می‌شود.

هدف این مرحله تبدیل داده‌های فضایی به ضرایبی است
که فشرده‌سازی آن‌ها ساده‌تر باشد.

Quantization چیست؟

مهم‌ترین مرحله کاهش حجم فایل، Quantization است.

در این مرحله بخشی از اطلاعات کم‌اهمیت حذف یا
تقریب زده می‌شود تا حجم Bitstream کاهش پیدا کند.

هرچه Quantization شدیدتر باشد، حجم فایل کمتر و
احتمال افت کیفیت بیشتر خواهد بود.

اثر Quantization
Quantization حجم فایل کیفیت
کم بیشتر بهتر
زیاد کمتر پایین‌تر

Quantization Parameter (QP)

شدت Quantization توسط پارامتری به نام
Quantization Parameter یا QP کنترل می‌شود.

افزایش مقدار QP باعث کاهش حجم فایل و افزایش
افت کیفیت می‌شود.

اثر تغییر QP
QP کیفیت حجم فایل
پایین بسیار خوب زیاد
متوسط متعادل متوسط
بالا افت محسوس کم

Deblocking Filter

Quantization ممکن است باعث ایجاد مرزهای قابل مشاهده
میان Macroblockها شود.

Deblocking Filter این مرزها را نرم‌تر می‌کند تا
تصویر طبیعی‌تر دیده شود.

Rate Control چیست؟

Rate Control تعیین می‌کند Encoder چگونه Bitrate
فایل را در طول Encode مدیریت کند.

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

روش‌های مختلف Rate Control

مقایسه روش‌های کنترل Bitrate
روش ویژگی اصلی کاربرد
CBR Bitrate ثابت Streaming
VBR Bitrate متغیر آرشیو و کیفیت بهتر
CQP QP ثابت تست و تولید محتوا
CRF کیفیت تقریباً ثابت x264 و FFmpeg

Hardware Acceleration در H.264

امروزه تقریباً تمام GPUهای مدرن دارای موتور
اختصاصی برای Decode و Encode فایل‌های H.264
هستند.

موتورهای سخت‌افزاری H.264
سازنده Decode Encode
NVIDIA NVDEC NVENC
AMD VCN VCN
Intel Quick Sync Quick Sync
Apple Media Engine Media Engine

H.265 / HEVC

H.265 که با نام High Efficiency Video Coding
یا HEVC نیز شناخته می‌شود، نسل بعدی H.264 است.
این Codec با هدف دستیابی به کیفیت تصویری مشابه
با حدود نصف Bitrate H.264 طراحی شده و امروزه
در ویدئوهای 4K، HDR، پخش آنلاین، Blu-ray UHD،
دوربین‌های حرفه‌ای و بسیاری از سرویس‌های
استریم استفاده می‌شود.

H.265 یا HEVC چیست؟

HEVC یک استاندارد فشرده‌سازی ویدئویی است که
برای افزایش راندمان نسبت به H.264 توسعه یافت.

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

امروزه تقریباً تمام GPUهای جدید دارای موتور
سخت‌افزاری برای Decode فایل‌های HEVC هستند و
بسیاری از آن‌ها Encode سخت‌افزاری را نیز
پشتیبانی می‌کنند.

چرا HEVC توسعه یافت؟

با افزایش وضوح تصویر به 4K، 8K و HDR،
H.264 دیگر راندمان کافی برای کاهش حجم فایل
نداشت.

HEVC با افزایش بهره‌وری فشرده‌سازی، امکان
انتقال و ذخیره ویدئوهای باکیفیت را با
پهنای باند کمتر فراهم کرد.

اهداف طراحی HEVC
هدف نتیجه
کاهش Bitrate حجم فایل کمتر
پشتیبانی 4K و 8K کیفیت بالاتر
HDR عمق رنگ بیشتر
Streaming مصرف کمتر پهنای باند

مسیر پردازش HEVC

مزایای HEVC

مهم‌ترین مزایای HEVC
مزیت توضیح
راندمان بیشتر کیفیت مشابه با Bitrate کمتر
مناسب 4K و 8K فشرده‌سازی بهتر تصاویر بزرگ
پشتیبانی HDR کیفیت رنگ بهتر
مناسب Streaming کاهش مصرف پهنای باند
کیفیت بالاتر Artifact کمتر نسبت به H.264

محدودیت‌های HEVC

در مقابل راندمان بالاتر، Encode و Decode
HEVC نسبت به H.264 پیچیده‌تر هستند.

همچنین برخی تجهیزات قدیمی از Decode سخت‌افزاری
HEVC پشتیبانی نمی‌کنند.

محدودیت‌های HEVC
محدودیت اثر
Encode پیچیده‌تر زمان پردازش بیشتر
نیاز پردازشی بالاتر وابستگی بیشتر به GPU
سازگاری کمتر بعضی دستگاه‌های قدیمی

مقایسه H.264 و HEVC

مقایسه دو Codec محبوب
ویژگی H.264 HEVC
راندمان فشرده‌سازی خوب بسیار بهتر
حجم فایل بیشتر کمتر
نیاز پردازشی کمتر بیشتر
مناسب 4K قابل استفاده بسیار مناسب
HDR محدود مناسب‌تر

کاربردهای HEVC

مهم‌ترین کاربردهای HEVC
حوزه کاربرد
UHD Blu-ray فیلم‌های 4K
Streaming سرویس‌های آنلاین
دوربین‌های حرفه‌ای ضبط 4K و 8K
پهپادها ضبط با Bitrate پایین‌تر
آرشیو ویدئو کاهش فضای ذخیره‌سازی

Coding Tree Unit (CTU)

بزرگ‌ترین تفاوت HEVC با H.264 استفاده از
Coding Tree Unit (CTU)
به‌جای Macroblock است.

در H.264 هر Macroblock معمولاً اندازه ثابتی برابر
با 16×16 پیکسل داشت، اما در HEVC اندازه CTU
می‌تواند تا 64×64 پیکسل افزایش یابد.

این ساختار انعطاف‌پذیر باعث افزایش راندمان
فشرده‌سازی، مخصوصاً در تصاویر 4K و 8K می‌شود.

مقایسه Macroblock و CTU
ویژگی H.264 HEVC
واحد اصلی Macroblock CTU
اندازه معمول 16×16 تا 64×64
انعطاف‌پذیری محدود بسیار زیاد

Coding Tree چیست؟

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

این تقسیم‌بندی با ساختاری درختی انجام می‌شود که
دلیل نام‌گذاری Coding Tree نیز همین موضوع است.

Coding Unit (CU)

Coding Unit کوچک‌ترین واحد تصمیم‌گیری برای Encode
است و مشخص می‌کند هر بخش تصویر چگونه فشرده شود.

اندازه CU می‌تواند متناسب با پیچیدگی تصویر تغییر
کند؛ بنابراین بخش‌های ساده و پیچیده تصویر به شکل
متفاوتی Encode می‌شوند.

Prediction Unit (PU)

Prediction Unit نحوه پیش‌بینی هر بخش تصویر را
تعیین می‌کند.

هر CU می‌تواند شامل یک یا چند Prediction Unit
باشد تا بهترین روش پیش‌بینی انتخاب شود.

وظیفه Prediction Unit
وظیفه توضیح
Intra Prediction پیش‌بینی از همان فریم
Inter Prediction پیش‌بینی از فریم‌های مرجع

Transform Unit (TU)

پس از پایان Prediction، اختلاف تصویر وارد مرحله
Transform می‌شود.

Transform Unit مشخص می‌کند ضرایب Transform چگونه
تولید و Quantize شوند.

ساختار داخلی CTU

Profileهای اصلی HEVC

مانند H.264، استاندارد HEVC نیز دارای Profileهای
مختلف است که قابلیت‌های Codec را مشخص می‌کنند.

Profileهای متداول HEVC
Profile ویژگی کاربرد
Main 8-bit استفاده عمومی
Main 10 10-bit HDR و 4K
Main Still Picture تصویر ثابت کاربردهای خاص

Level در HEVC

Level در HEVC نیز همانند H.264 محدودیت‌هایی مانند
حداکثر Resolution، نرخ فریم، تعداد CTUها و Bitrate
را تعیین می‌کند.

نمونه Levelهای HEVC
Level کاربرد رایج
4 Full HD
5 4K
6 8K

Intra Prediction در HEVC

Intra Prediction روشی است که در آن تصویر تنها با
استفاده از اطلاعات همان فریم پیش‌بینی می‌شود و
نیازی به مراجعه به فریم‌های قبلی یا بعدی وجود ندارد.

HEVC تعداد حالت‌های پیش‌بینی درون‌فریمی را نسبت به
H.264 به‌طور قابل توجهی افزایش داده است و به همین
دلیل می‌تواند لبه‌ها و جزئیات تصویر را دقیق‌تر
مدل‌سازی کند.

مزایای Intra Prediction
ویژگی نتیجه
پیش‌بینی از همان فریم عدم وابستگی به فریم‌های دیگر
جهت‌های بیشتر دقت بالاتر در لبه‌ها
خطای کمتر فشرده‌سازی بهتر

Inter Prediction در HEVC

Inter Prediction از اطلاعات فریم‌های مرجع برای
پیش‌بینی تصویر جدید استفاده می‌کند.

در HEVC الگوریتم‌های جستجوی حرکت نسبت به H.264
بهینه‌تر شده‌اند و همین موضوع یکی از دلایل اصلی
افزایش راندمان این Codec است.

Motion Vector در HEVC

Motion Vector جهت و میزان جابه‌جایی هر بخش تصویر را
نسبت به فریم مرجع مشخص می‌کند.

HEVC از Motion Vectorهای دقیق‌تر و ساختارهای
پیشرفته‌تری برای کاهش حجم فایل استفاده می‌کند.

Advanced Motion Vector Prediction (AMVP)

AMVP روشی است که Motion Vector مناسب را از میان
بردارهای اطراف انتخاب می‌کند تا نیاز به ذخیره
اطلاعات اضافی کاهش یابد.

این قابلیت یکی از ابزارهای افزایش راندمان
فشرده‌سازی در HEVC محسوب می‌شود.

Merge Mode

در بسیاری از نواحی تصویر، Motion Vector مناسب
قبلاً توسط بلوک‌های مجاور محاسبه شده است.

Merge Mode اجازه می‌دهد همان Motion Vector دوباره
استفاده شود و دیگر نیازی به ذخیره بردار جدید نباشد.

مزایای Merge Mode
مزیت اثر
داده کمتر کاهش حجم Bitstream
Encode سریع‌تر کاهش محاسبات
راندمان بیشتر فشرده‌سازی بهتر

Tile چیست؟

Tile تصویر را به چند ناحیه مستقل تقسیم می‌کند تا
عملیات Encode و Decode بتواند به‌صورت موازی انجام
شود.

این قابلیت مخصوصاً برای پردازنده‌های چند هسته‌ای و
GPUهای مدرن اهمیت زیادی دارد.

Wavefront Parallel Processing (WPP)

WPP روشی برای اجرای موازی Encode و Decode است که
بدون تقسیم تصویر به Tile، چندین ردیف CTU را
هم‌زمان پردازش می‌کند.

این فناوری باعث استفاده بهتر از CPUهای چند هسته‌ای
و افزایش سرعت پردازش می‌شود.

مقایسه Tile و WPP

تفاوت دو روش پردازش موازی
ویژگی Tile WPP
تقسیم تصویر بله خیر
پردازش موازی بالا بالا
راندمان فشرده‌سازی اندکی کمتر بهتر

Sample Adaptive Offset (SAO)

پس از پایان Decode ممکن است به علت Quantization
بخشی از جزئیات تصویر از بین برود یا لبه‌ها به‌درستی
بازسازی نشوند.

HEVC برای کاهش این خطاها از مرحله‌ای به نام
Sample Adaptive Offset (SAO)
استفاده می‌کند.

SAO مقادیر برخی پیکسل‌ها را پس از Decode اصلاح
می‌کند تا تصویر طبیعی‌تر و Artifactها کمتر شوند.

Deblocking Filter در HEVC

مانند H.264، در HEVC نیز پس از Quantization ممکن
است مرز میان بلوک‌ها قابل مشاهده باشد.

Deblocking Filter این مرزها را نرم‌تر می‌کند و
ظاهر تصویر را طبیعی‌تر نشان می‌دهد.

وظیفه Deblocking Filter
قبل از فیلتر بعد از فیلتر
مرزهای قابل مشاهده لبه‌های نرم‌تر
Block Artifact تصویر طبیعی‌تر

Reference Picture Set (RPS)

HEVC برای مدیریت فریم‌های مرجع از ساختاری به نام
Reference Picture Set استفاده
می‌کند.

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

Entropy Coding

آخرین مرحله Encode، تبدیل اطلاعات فشرده‌شده به
Bitstream نهایی است.

HEVC مانند High Profile در H.264 از CABAC برای
افزایش راندمان فشرده‌سازی استفاده می‌کند.

ویژگی‌های CABAC در HEVC
ویژگی اثر
فشرده‌سازی بهتر کاهش حجم فایل
پیچیدگی بیشتر Encode سنگین‌تر
راندمان بالا کیفیت بهتر در Bitrate یکسان

Bit Depth در HEVC

HEVC از Bit Depthهای مختلف پشتیبانی می‌کند و
نسخه Main 10 به یکی از رایج‌ترین Profileهای
این Codec تبدیل شده است.

Bit Depthهای رایج
Bit Depth کاربرد
8-bit استفاده عمومی
10-bit HDR و تولید حرفه‌ای
12-bit کاربردهای تخصصی

Chroma Sampling در HEVC

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

حالت‌های Chroma Sampling
حالت کاربرد
4:2:0 رایج‌ترین حالت
4:2:2 Broadcast
4:4:4 تدوین حرفه‌ای و VFX

HEVC و HDR

یکی از مهم‌ترین دلایل محبوبیت HEVC، پشتیبانی مناسب
از محتوای HDR است.

ترکیب Main 10، عمق رنگ 10-bit و فضای رنگ گسترده،
HEVC را به گزینه‌ای مناسب برای ویدئوهای HDR تبدیل
کرده است.

پشتیبانی سخت‌افزاری HEVC

موتورهای سخت‌افزاری HEVC
موتور رسانه Decode Encode
NVIDIA NVDEC / NVENC بله بله
AMD VCN بله بله
Intel Quick Sync بله بله
Apple Media Engine بله بله

AV1

AV1 یکی از پیشرفته‌ترین Codecهای ویدئویی نسل
جدید است که توسط اتحاد
Alliance for Open Media (AOMedia)
توسعه یافته است. این Codec با هدف ارائه کیفیت
بالاتر، کاهش بیشتر حجم فایل و حذف وابستگی به
حق امتیاز (Royalty-Free) طراحی شده و امروزه
به‌سرعت در سرویس‌های استریم، مرورگرها،
کارت‌های گرافیک و دستگاه‌های جدید گسترش
یافته است.

AV1 چیست؟

AV1 یک استاندارد فشرده‌سازی ویدئویی متن‌باز است
که به‌عنوان جایگزین نسل جدید H.264 و HEVC
توسعه یافته است.

این Codec از تکنیک‌های بسیار پیشرفته‌تری برای
Prediction، Transform، Motion Compensation و
Entropy Coding استفاده می‌کند تا حجم فایل را
بدون افت محسوس کیفیت کاهش دهد.

چرا AV1 توسعه یافت؟

با رشد سریع استریم ویدئو، نیاز به Codecی با
راندمان بیشتر و بدون هزینه حق امتیاز احساس شد.

AV1 علاوه بر افزایش کیفیت، هزینه استفاده از
Codec را نیز برای شرکت‌ها کاهش می‌دهد.

اهداف طراحی AV1
هدف نتیجه
کاهش Bitrate حجم کمتر
کیفیت بالاتر Artifact کمتر
Royalty-Free استفاده آزاد
پشتیبانی 4K و 8K مناسب برای آینده

Alliance for Open Media

AV1 توسط اتحاد AOMedia توسعه یافته است؛
کنسرسیومی که با هدف ایجاد استانداردهای آزاد
برای رسانه‌های دیجیتال تشکیل شد.

برخی اعضای AOMedia
شرکت نقش
Google توسعه و استفاده در YouTube
Microsoft پشتیبانی نرم‌افزاری
Intel توسعه سخت‌افزار
AMD GPU و Media Engine
NVIDIA Decode و Encode سخت‌افزاری
Meta استفاده در سرویس‌های آنلاین

مسیر کلی Encode و Decode

مزایای AV1

مهم‌ترین مزیت‌های AV1
مزیت توضیح
راندمان بسیار بالا Bitrate کمتر نسبت به HEVC
متن‌باز بدون Royalty
کیفیت بالا مناسب HDR و 8K
مناسب Streaming کاهش مصرف پهنای باند
آینده‌نگر پشتیبانی گسترده در حال توسعه

محدودیت‌های AV1

Encode نرم‌افزاری AV1 نسبت به HEVC و H.264
پیچیده‌تر و زمان‌برتر است.

به همین دلیل وجود موتورهای سخت‌افزاری Encode و
Decode برای استفاده گسترده از AV1 اهمیت زیادی
دارد.

محدودیت‌های AV1
محدودیت اثر
Encode سنگین زمان بیشتر
نیاز پردازشی بالا وابستگی بیشتر به سخت‌افزار
تجهیزات قدیمی عدم پشتیبانی سخت‌افزاری

Superblock در AV1

همان‌طور که HEVC از Coding Tree Unit استفاده
می‌کند، AV1 نیز از ساختاری به نام
Superblock
به‌عنوان بزرگ‌ترین واحد پردازش تصویر بهره می‌برد.

هر Superblock می‌تواند اندازه‌ای تا
128×128 پیکسل
داشته باشد و سپس به بلوک‌های کوچک‌تر تقسیم شود.

این ساختار یکی از عوامل اصلی افزایش راندمان AV1
در ویدئوهای با وضوح بالا است.

واحد اصلی پردازش تصویر
Codec واحد اصلی اندازه حداکثر
H.264 Macroblock 16×16
HEVC CTU 64×64
AV1 Superblock 128×128

Partition Tree

Superblockها در AV1 به‌صورت پویا و درختی به
بلوک‌های کوچک‌تر تقسیم می‌شوند.

این تقسیم‌بندی انعطاف‌پذیر باعث می‌شود هر قسمت
تصویر متناسب با میزان جزئیات خود فشرده شود.

Intra Prediction

AV1 از تعداد بسیار بیشتری حالت پیش‌بینی درون‌فریمی
نسبت به Codecهای قدیمی استفاده می‌کند.

این موضوع باعث می‌شود لبه‌ها، خطوط و بافت‌های
تصویر با دقت بیشتری پیش‌بینی شوند و خطای Encode
کاهش یابد.

Inter Prediction

در Inter Prediction، AV1 از فریم‌های مرجع برای
پیش‌بینی تصویر استفاده می‌کند.

الگوریتم‌های پیشرفته‌تر Motion Search و Motion
Compensation باعث افزایش راندمان نسبت به HEVC
شده‌اند.

Overlapped Block Motion Compensation (OBMC)

یکی از فناوری‌های اختصاصی AV1 استفاده از
Overlapped Block Motion Compensation است.

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

Warped Motion

بسیاری از حرکت‌های واقعی تنها جابه‌جایی ساده
نیستند و شامل چرخش، تغییر زاویه یا پرسپکتیو نیز
می‌شوند.

Warped Motion این نوع حرکت‌ها را دقیق‌تر مدل
می‌کند و خطای پیش‌بینی را کاهش می‌دهد.

Constrained Directional Enhancement Filter (CDEF)

CDEF یکی از فیلترهای اختصاصی AV1 است که پس از
Decode اجرا می‌شود.

این فیلتر نویزهای ناشی از فشرده‌سازی را کاهش داده
و در عین حال جزئیات لبه‌ها را حفظ می‌کند.

عملکرد CDEF
قبل بعد
Artifact بیشتر تصویر نرم‌تر
نویز لبه‌ها حفظ جزئیات

Loop Restoration Filter

پس از پایان Decode و اجرای CDEF، مرحله دیگری
به نام Loop Restoration اجرا می‌شود.

هدف این فیلتر بازیابی جزئیات تصویر و کاهش نویزهای
باقی‌مانده است تا کیفیت نهایی افزایش یابد.

Film Grain Synthesis

یکی از فناوری‌های منحصربه‌فرد AV1، بازسازی نویز
طبیعی فیلم پس از Decode است.

در بسیاری از فیلم‌های سینمایی، Grain بخشی از ظاهر
طبیعی تصویر محسوب می‌شود. ذخیره مستقیم این نویز،
حجم فایل را به‌شدت افزایش می‌دهد.

AV1 به‌جای ذخیره تمام Grain، تنها پارامترهای آن را
ذخیره کرده و هنگام Decode دوباره آن را تولید
می‌کند.

Tile و Tile Group

AV1 تصویر را می‌تواند به چند Tile مستقل تقسیم کند
تا عملیات Encode و Decode به‌صورت موازی انجام شود.

Tile Group نیز مجموعه‌ای از Tileها است که مدیریت
پردازش آن‌ها را ساده‌تر می‌کند.

Open Bitstream Unit (OBU)

ساختار Bitstream در AV1 از واحدهایی به نام
Open Bitstream Unit (OBU)
تشکیل شده است.

هر OBU بخشی از اطلاعات فایل مانند Header،
پارامترهای Sequence، داده‌های تصویری یا Metadata
را نگهداری می‌کند.

انواع متداول OBU
نوع OBU وظیفه
Sequence Header اطلاعات کلی ویدئو
Frame Header اطلاعات هر فریم
Tile Group داده تصویری
Metadata اطلاعات جانبی

Profileهای AV1

AV1 برای پشتیبانی از عمق رنگ و نمونه‌برداری رنگ،
چند Profile مختلف ارائه می‌کند.

Profileهای اصلی AV1
Profile ویژگی کاربرد
Profile 0 8 و 10 بیت، 4:2:0 استفاده عمومی
Profile 1 4:4:4 تدوین حرفه‌ای
Profile 2 12 بیت HDR پیشرفته

Bit Depth و Chroma Sampling

AV1 از عمق رنگ 8، 10 و 12 بیت و همچنین حالت‌های
مختلف Chroma Sampling پشتیبانی می‌کند.

پشتیبانی رنگ در AV1
ویژگی حالت‌های متداول
Bit Depth 8 / 10 / 12 بیت
Chroma Sampling 4:2:0 ، 4:2:2 ، 4:4:4

پشتیبانی سخت‌افزاری AV1

در سال‌های اخیر تقریباً تمام GPUهای جدید از Decode
سخت‌افزاری AV1 پشتیبانی می‌کنند و بسیاری از آن‌ها
قابلیت Encode سخت‌افزاری را نیز ارائه می‌دهند.

موتورهای رسانه AV1
سازنده Decode Encode
NVIDIA Ada / Blackwell بله بله
AMD RDNA 3 و جدیدتر بله بله
Intel Arc و Xe بله بله
Apple Media Engine بله بسته به نسل تراشه

مقایسه H.264، HEVC و AV1

مقایسه سه Codec پرکاربرد
ویژگی H.264 HEVC AV1
راندمان فشرده‌سازی خوب بسیار خوب عالی
حجم فایل بیشتر کمتر کمترین
پیچیدگی Encode کم متوسط بسیار زیاد
مناسب 8K و HDR محدود مناسب بسیار مناسب

Containerهای ویدئویی (Video Containers)

یکی از رایج‌ترین اشتباهات هنگام کار با فایل‌های
ویدئویی، یکسان دانستن Container و Codec است.
Codec مسئول فشرده‌سازی تصویر و صدا است، در حالی
که Container تنها ساختار نگهداری و سازمان‌دهی
داده‌ها را مشخص می‌کند.

Container چیست؟

Container قالبی برای ذخیره فایل‌های چندرسانه‌ای
است که می‌تواند هم‌زمان ویدئو، صدا، زیرنویس،
Chapter، Metadata و اطلاعات جانبی را در یک
فایل واحد نگهداری کند.

Container هیچ تغییری در کیفیت تصویر ایجاد
نمی‌کند و عملیات فشرده‌سازی نیز انجام نمی‌دهد.

تفاوت Codec و Container

Codec الگوریتم فشرده‌سازی و بازسازی داده‌های
ویدئویی یا صوتی است، اما Container تنها فایل
نهایی را سازمان‌دهی می‌کند.

مقایسه Codec و Container
ویژگی Codec Container
وظیفه فشرده‌سازی نگهداری داده
کیفیت تصویر مؤثر بدون تأثیر
نمونه H.264، HEVC، AV1 MP4، MKV، MOV

ساختار داخلی Container

یک Container می‌تواند چندین Stream مختلف را
در یک فایل نگهداری کند.

چرا به Container نیاز داریم؟

اگر فایل ویدئویی فاقد Container باشد،
هماهنگ‌سازی صدا، تصویر، زیرنویس و اطلاعات
جانبی بسیار دشوار خواهد بود.

Container امکان مدیریت همه این داده‌ها را در
قالب یک فایل واحد فراهم می‌کند.

رایج‌ترین Containerهای ویدئویی

Containerهای متداول
Container پسوند کاربرد
MPEG-4 Part 14 .mp4 عمومی و استریم
Matroska .mkv آرشیو و کیفیت بالا
QuickTime .mov اکوسیستم Apple
WebM .webm وب
AVI .avi قالب قدیمی
Flash Video .flv کاربرد تاریخی

MP4 (MPEG-4 Part 14)

MP4 پرکاربردترین Container ویدئویی جهان است.
تقریباً تمام سیستم‌عامل‌ها، مرورگرها،
تلفن‌های همراه، تلویزیون‌های هوشمند و
سرویس‌های استریم از این قالب پشتیبانی
می‌کنند و به همین دلیل به استاندارد
رایج تبادل فایل‌های ویدئویی تبدیل شده است.

MP4 چیست؟

MP4 یک Container چندرسانه‌ای است که برای
نگهداری هم‌زمان ویدئو، صدا، زیرنویس،
تصویر، Chapter و Metadata طراحی شده است.

برخلاف تصور بسیاری از کاربران، MP4 یک Codec
نیست و تنها داده‌های تولیدشده توسط Codecها را
در قالبی استاندارد ذخیره می‌کند.

ساختار داخلی MP4

فایل MP4 از مجموعه‌ای از Boxها (که گاهی Atom نیز
نامیده می‌شوند) تشکیل شده است.

هر Box وظیفه مشخصی مانند نگهداری اطلاعات
فایل، مسیر داده‌ها یا Streamهای صوتی و تصویری
را بر عهده دارد.

مهم‌ترین Boxهای MP4

Boxهای اصلی فایل MP4
Box وظیفه
ftyp نوع فایل و سازگاری
moov اطلاعات ساختاری فایل
mdat داده‌های اصلی صوت و تصویر
free فضای رزرو شده

Codecهای قابل استفاده در MP4

MP4 می‌تواند چندین Codec مختلف را در خود
نگهداری کند؛ البته میزان پشتیبانی نرم‌افزارها
ممکن است متفاوت باشد.

Codecهای رایج در MP4
نوع نمونه‌ها
Video H.264، HEVC، AV1، MPEG-4 Visual
Audio AAC، ALAC، MP3
Subtitle Timed Text و فرمت‌های سازگار

مزایای MP4

مزیت‌های MP4
مزیت توضیح
سازگاری بسیار بالا تقریباً تمام دستگاه‌ها
مناسب Streaming بارگذاری و پخش سریع
پشتیبانی نرم‌افزاری تقریباً تمام پلیرها
مدیریت Metadata اطلاعات جانبی فایل

محدودیت‌های MP4

MP4 نسبت به بعضی Containerهای مدرن مانند MKV
انعطاف‌پذیری کمتری در نگهداری چندین زیرنویس،
Trackهای متعدد یا Metadata پیچیده دارد.

محدودیت‌های MP4
محدودیت اثر
قابلیت کمتر نسبت به MKV امکانات جانبی محدودتر
برخی Codecهای خاص سازگاری کمتر

MKV (Matroska)

Matroska یا MKV یکی از قدرتمندترین و
انعطاف‌پذیرترین Containerهای ویدئویی است.
این قالب به‌صورت متن‌باز توسعه یافته و امکان
ذخیره هم‌زمان چندین Track ویدئو، صدا،
زیرنویس، Chapter، فونت، تصویر جلد و انواع
Metadata را در یک فایل فراهم می‌کند.

MKV چیست؟

MKV یک Container چندرسانه‌ای متن‌باز است که
برای نگهداری انواع Streamهای صوتی و تصویری
بدون وابستگی به Codec خاص طراحی شده است.

این قالب به دلیل انعطاف بالا، یکی از رایج‌ترین
گزینه‌ها برای آرشیو فیلم، نسخه‌های Blu-ray،
محتوای HDR و پروژه‌های حرفه‌ای محسوب می‌شود.

ساختار داخلی MKV

MKV بر پایه استاندارد
EBML (Extensible Binary Meta Language)
ساخته شده است.

ساختار درختی EBML باعث می‌شود اضافه کردن
اطلاعات جدید بدون شکستن سازگاری فایل امکان‌پذیر
باشد.

چه داده‌هایی در MKV ذخیره می‌شوند؟

انواع داده‌های قابل ذخیره در MKV
نوع داده پشتیبانی
Video Track ✔
Audio Track ✔
Subtitle ✔
Chapter ✔
Font Attachment ✔
Cover Image ✔
Metadata ✔

Codecهای قابل استفاده در MKV

تقریباً تمام Codecهای رایج صوتی و تصویری
می‌توانند داخل MKV قرار بگیرند.

نمونه Codecهای پشتیبانی‌شده
نوع نمونه‌ها
Video H.264، HEVC، AV1، VP9، MPEG-2
Audio AAC، FLAC، Opus، Vorbis، DTS،
Dolby Digital، TrueHD
Subtitle SRT، ASS، SSA، PGS، VobSub

مزایای MKV

مهم‌ترین مزیت‌های MKV
مزیت توضیح
انعطاف بسیار بالا پشتیبانی از انواع Track
چندین زیرنویس بدون محدودیت عملی
چندین Audio Track دوبله و زبان‌های مختلف
متن‌باز توسعه آزاد
مناسب آرشیو کیفیت بالا و امکانات زیاد

محدودیت‌های MKV

اگرچه MKV امکانات بسیار زیادی دارد، اما هنوز
همه دستگاه‌های قدیمی و برخی تجهیزات مصرفی از
تمام قابلیت‌های آن پشتیبانی نمی‌کنند.

محدودیت‌های MKV
محدودیت اثر
سازگاری کمتر برخی دستگاه‌های قدیمی
امکانات زیاد پیاده‌سازی پیچیده‌تر

مقایسه MP4 و MKV

مقایسه دو Container پرکاربرد
ویژگی MP4 MKV
سازگاری بسیار بالا بالا
چندین زیرنویس محدودتر عالی
چند Audio Track مناسب بسیار مناسب
Attachment محدود پشتیبانی کامل
مناسب Streaming بسیار مناسب کمتر از MP4
مناسب آرشیو خوب بسیار عالی

MOV (QuickTime File Format)

MOV قالب چندرسانه‌ای اختصاصی Apple است که بر
پایه QuickTime File Format توسعه یافته است.
این Container یکی از مهم‌ترین قالب‌های صنعت
تدوین ویدئو محسوب می‌شود و در نرم‌افزارهایی
مانند Final Cut Pro، DaVinci Resolve،
Adobe Premiere Pro و بسیاری از Workflowهای
حرفه‌ای استفاده می‌شود.

MOV چیست؟

MOV یک Container چندرسانه‌ای است که برای
نگهداری انواع Streamهای ویدئو، صدا، زیرنویس،
Metadata و اطلاعات زمانی طراحی شده است.

این قالب پایه بسیاری از فناوری‌های تصویری
Apple بوده و بعدها استاندارد MP4 نیز از همین
معماری الهام گرفت.

ساختار داخلی MOV

مانند MP4، فایل‌های MOV نیز از مجموعه‌ای از
Box یا Atom تشکیل می‌شوند.

Codecهای رایج در MOV

MOV تقریباً از تمام Codecهای حرفه‌ای Apple و
بسیاری از Codecهای عمومی پشتیبانی می‌کند.

Codecهای متداول در MOV
نوع نمونه‌ها
Video Apple ProRes، H.264، HEVC،
DNxHD، Animation
Audio PCM، AAC، ALAC، Dolby Digital
Subtitle Timed Text و Trackهای سازگار

چرا MOV در تدوین حرفه‌ای محبوب است؟

بسیاری از Codecهای حرفه‌ای مانند
Apple ProRes به‌صورت طبیعی در Container
MOV ذخیره می‌شوند.

همچنین پشتیبانی مناسب از Metadata، Timecode،
Alpha Channel و کیفیت بالا باعث شده MOV
به یکی از قالب‌های استاندارد Post Production
تبدیل شود.

مزایای MOV

مزیت‌های MOV
مزیت توضیح
مناسب تدوین Workflow حرفه‌ای
پشتیبانی Timecode همگام‌سازی پروژه
Metadata کامل اطلاعات فنی و پروژه
کیفیت بالا مناسب Master File
سازگاری با Apple Final Cut Pro و macOS

محدودیت‌های MOV

محدودیت‌های MOV
محدودیت اثر
حجم فایل معمولاً بیشتر از MP4
مناسب نبودن برای وب Streaming محدودتر
تمرکز بر Apple بهترین عملکرد در اکوسیستم Apple

مقایسه MOV و MP4

تفاوت MOV و MP4
ویژگی MOV MP4
کاربرد اصلی تدوین حرفه‌ای توزیع و استریم
سازگاری عالی در Apple تقریباً همه دستگاه‌ها
حجم فایل بیشتر کمتر
مناسب Master File بسیار مناسب کمتر
مناسب Streaming متوسط بسیار مناسب

WebM

WebM یک Container متن‌باز است که توسط Google
برای استفاده در وب توسعه یافت. هدف اصلی این
قالب، ارائه فایل‌های ویدئویی با کیفیت بالا،
حجم کم و سازگاری مناسب با مرورگرهای مدرن و
سرویس‌های استریم اینترنتی است.

WebM چیست؟

WebM یک Container چندرسانه‌ای متن‌باز است که
بر پایه ساختار Matroska توسعه یافته اما برای
استفاده در وب ساده‌تر و بهینه‌تر شده است.

این قالب معمولاً همراه با Codecهای VP8، VP9
و AV1 برای ویدئو و Opus یا Vorbis برای صدا
استفاده می‌شود.

ساختار داخلی WebM

WebM نیز مانند MKV بر پایه EBML ساخته شده
است، اما تنها از مجموعه‌ای محدود از قابلیت‌های
Matroska استفاده می‌کند.

Codecهای قابل استفاده در WebM

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

Codecهای استاندارد WebM
نوع Codec
Video VP8، VP9، AV1
Audio Opus، Vorbis

چرا WebM توسعه یافت؟

با گسترش HTML5 و ویدئوهای آنلاین، نیاز به
قالبی آزاد و بدون هزینه حق امتیاز برای پخش
مستقیم در مرورگرها احساس شد.

WebM پاسخی به این نیاز بود و امروزه یکی از
قالب‌های اصلی ویدئوی وب محسوب می‌شود.

مزایای WebM

مزیت‌های WebM
مزیت توضیح
متن‌باز بدون Royalty
مناسب وب HTML5 و مرورگرها
حجم کم مناسب Streaming
پشتیبانی AV1 مناسب نسل جدید ویدئو

محدودیت‌های WebM

محدودیت‌های WebM
محدودیت اثر
Codec محدود پشتیبانی فقط از Codecهای مشخص
امکانات کمتر از MKV انعطاف‌پذیری پایین‌تر
مناسب نبودن برای آرشیو تمرکز بر پخش آنلاین

مقایسه WebM، MP4 و MKV

مقایسه سه Container رایج
ویژگی MP4 MKV WebM
مناسب وب عالی خوب عالی
انعطاف‌پذیری خوب بسیار زیاد متوسط
پشتیبانی Codec زیاد بسیار زیاد محدود
مناسب آرشیو خوب عالی متوسط
مناسب Streaming عالی خوب عالی

AVI (Audio Video Interleave)

AVI یکی از قدیمی‌ترین Containerهای ویدئویی است
که در سال 1992 توسط Microsoft معرفی شد. اگرچه
امروزه Containerهای مدرن‌تری مانند MP4 و MKV
جایگزین آن شده‌اند، اما AVI هنوز در بسیاری از
آرشیوهای قدیمی، تجهیزات صنعتی و نرم‌افزارهای
کلاسیک مورد استفاده قرار می‌گیرد.

AVI چیست؟

AVI یک Container چندرسانه‌ای است که برای
ذخیره هم‌زمان Streamهای ویدئو و صدا طراحی شد.

نام Audio Video Interleave به این دلیل انتخاب
شده که داده‌های صوتی و تصویری به‌صورت
درهم‌تنیده (Interleaved) داخل فایل ذخیره
می‌شوند تا همگام‌سازی (Synchronization)
ساده‌تر انجام شود.

ساختار داخلی AVI

AVI بر پایه قالب RIFF (Resource Interchange
File Format) ساخته شده است.

فایل از چندین Chunk تشکیل می‌شود که هر کدام
اطلاعات مشخصی را نگهداری می‌کنند.

Codecهای قابل استفاده در AVI

AVI از Codecهای متنوعی پشتیبانی می‌کند، اما
این قالب برای Codecهای مدرن طراحی نشده است.

Codecهای رایج در AVI
نوع نمونه‌ها
Video DivX، Xvid، MPEG-4 Visual،
MJPEG، DV
Audio PCM، MP3، AC-3

مزایای AVI

مزیت‌های AVI
مزیت توضیح
ساختار ساده پیاده‌سازی آسان
سازگاری با ویندوز پشتیبانی گسترده تاریخی
مناسب فایل‌های قدیمی آرشیو کلاسیک
مناسب Capture برخی تجهیزات ضبط قدیمی

محدودیت‌های AVI

AVI پیش از ظهور بسیاری از فناوری‌های مدرن
ویدئویی طراحی شده است؛ بنابراین از قابلیت‌های
امروزی به‌خوبی پشتیبانی نمی‌کند.

محدودیت‌های AVI
محدودیت اثر
Metadata محدود امکانات کمتر
زیرنویس داخلی پشتیبانی ضعیف
چندین Audio Track محدود
مناسب نبودن Streaming عملکرد ضعیف در وب
Codecهای جدید سازگاری محدود

مقایسه AVI با MP4 و MKV

مقایسه سه Container
ویژگی AVI MP4 MKV
سال معرفی 1992 2001 2002
مناسب Streaming خیر بسیار مناسب مناسب
چندین زیرنویس ضعیف متوسط عالی
Metadata محدود خوب بسیار کامل
مناسب پروژه‌های جدید خیر بله بله

وضعیت امروزی AVI

امروزه AVI بیشتر در فایل‌های قدیمی، سیستم‌های
نظارتی، تجهیزات صنعتی و برخی دوربین‌های قدیمی
دیده می‌شود.

در پروژه‌های جدید، معمولاً MP4، MKV یا MOV
جایگزین AVI شده‌اند؛ زیرا امکانات بیشتری برای
Codecهای مدرن، Metadata، زیرنویس و استریم
ارائه می‌کنند.

FLV (Flash Video)

FLV یکی از مهم‌ترین Containerهای تاریخی وب است
که برای انتقال و پخش ویدئو با Adobe Flash Player
توسعه یافت. این قالب سال‌ها در وب‌سایت‌های
اشتراک ویدئو، پخش زنده و سامانه‌های آموزشی
استفاده می‌شد، اما با پایان پشتیبانی از Flash
و گسترش HTML5، جایگاه آن به‌شدت کاهش یافت.

FLV چیست؟

FLV مخفف Flash Video است و
Containerی برای نگهداری و انتقال Streamهای
صوتی و تصویری در محیط Adobe Flash محسوب می‌شود.

این قالب در دوره‌ای که مرورگرها هنوز پخش
داخلی ویدئو با HTML5 را ارائه نمی‌کردند،
راهکاری رایج برای نمایش ویدئوی اینترنتی بود.

نقش FLV در تاریخ ویدئوی اینترنتی

در سال‌های ابتدایی رشد ویدئوی آنلاین، مرورگرها
استاندارد یکپارچه‌ای برای پخش مستقیم فایل‌های
ویدئویی نداشتند.

Flash Player با نصب افزونه مرورگر، محیطی مشترک
برای پخش ویدئو ایجاد کرد و FLV به یکی از
قالب‌های اصلی این اکوسیستم تبدیل شد.

بسیاری از وب‌سایت‌های ویدئویی قدیمی، پخش‌کننده‌های
آموزشی و سامانه‌های استریم اولیه از FLV استفاده
می‌کردند.

ساختار داخلی FLV

فایل FLV از یک Header و مجموعه‌ای از Tagهای
متوالی تشکیل می‌شود.

هر Tag می‌تواند شامل داده ویدئویی، صوتی یا
Metadata باشد.

Tagهای اصلی FLV

انواع داده در ساختار FLV
نوع Tag وظیفه نمونه اطلاعات
Video Tag نگهداری داده تصویری فریم‌های فشرده ویدئو
Audio Tag نگهداری داده صوتی Stream صوتی
Script Data Tag نگهداری Metadata Duration، Resolution و اطلاعات فایل

Codecهای رایج در FLV

FLV در طول زمان از چند Codec تصویری و صوتی
پشتیبانی کرد، اما مجموعه قابلیت‌های آن در
مقایسه با Containerهای مدرن محدودتر است.

Codecهای متداول در فایل‌های FLV
نوع Codecهای رایج کاربرد تاریخی
Video Sorenson Spark، VP6، H.264 ویدئوی وب و پخش زنده
Audio MP3، AAC، Speex صدا، گفتار و موسیقی

ارتباط FLV با RTMP

FLV ارتباط نزدیکی با پروتکل
RTMP یا Real-Time Messaging Protocol
دارد.

در بسیاری از سیستم‌های پخش زنده، داده‌های صوتی
و تصویری با ساختاری مشابه Tagهای FLV داخل
اتصال RTMP منتقل می‌شوند.

به همین دلیل، حتی پس از کاهش استفاده مستقیم از
فایل‌های FLV، ساختارهای مرتبط با آن برای ارسال
Stream زنده به بعضی سرورها و پلتفرم‌ها همچنان
مورد استفاده قرار گرفتند.

کاربردهای تاریخی FLV

مهم‌ترین کاربردهای FLV
کاربرد توضیح وضعیت امروزی
پخش ویدئو در مرورگر با افزونه Flash Player منسوخ
ویدئوی آموزشی سامانه‌های آموزش قدیمی بیشتر جایگزین شده است
پخش زنده همراه با RTMP ساختار ارسال هنوز در برخی Workflowها دیده می‌شود
وب‌سایت‌های اشتراک ویدئو پخش اینترنتی اولیه جایگزین با HTML5
بازی و محتوای تعاملی داخل پروژه‌های Flash منسوخ

مزایای تاریخی FLV

نقاط قوت FLV در زمان رواج Flash
مزیت نتیجه
پخش داخل مرورگر بدون نیاز به پلیر خارجی
شروع سریع پخش مناسب ویدئوی آنلاین
ارتباط با RTMP مناسب پخش زنده
اکوسیستم گسترده Flash پشتیبانی وسیع در وب قدیمی

محدودیت‌های FLV

مهم‌ترین ضعف FLV وابستگی تاریخی آن به Flash
Player و اکوسیستم منسوخ Flash است.

محدودیت‌های اصلی FLV
محدودیت پیامد
پایان پشتیبانی Flash عدم پخش مستقیم در مرورگرهای جدید
Codecهای محدودتر سازگاری ضعیف با فناوری‌های جدید
امکانات کمتر از MKV و MP4 Metadata و Trackهای محدودتر
پشتیبانی ضعیف از HDR و AV1 نامناسب برای محتوای مدرن
وابستگی به نرم‌افزار قدیمی ریسک امنیتی و ناسازگاری

مقایسه FLV با MP4 و WebM

مقایسه FLV با Containerهای جدیدتر وب
ویژگی FLV MP4 WebM
پخش HTML5 ضعیف بسیار گسترده بسیار گسترده
H.264 قابل استفاده بسیار رایج استاندارد اصلی WebM نیست
AV1 نامناسب قابل استفاده بسیار مناسب
وضعیت امروزی عمدتاً منسوخ بسیار رایج رایج در وب مدرن
پخش زنده تاریخی با RTMP مناسب در Workflowهای جدید وابسته به پلتفرم و پروتکل

تبدیل FLV به MP4 یا MKV

اگر Streamهای داخلی فایل FLV با Container مقصد
سازگار باشند، می‌توان آن‌ها را بدون Encode
مجدد به MP4 یا MKV منتقل کرد.

این عملیات Remux نام دارد و
معمولاً سریع انجام می‌شود و افت کیفیت ایجاد
نمی‌کند.

اگر Codec داخلی قدیمی یا ناسازگار باشد، لازم
است فایل Transcode شود که زمان بیشتری می‌برد
و ممکن است کیفیت را تغییر دهد.

روش‌های تبدیل فایل FLV
روش Encode مجدد سرعت افت کیفیت
Remux خیر بسیار سریع ندارد
Transcode بله کندتر وابسته به تنظیمات

وضعیت امروزی FLV

FLV دیگر گزینه مناسبی برای تولید و انتشار
محتوای جدید محسوب نمی‌شود.

برای ویدئوی عمومی و سازگاری گسترده، MP4 و برای
ویدئوی متن‌باز وب، WebM گزینه‌های مناسب‌تری
هستند.

بااین‌حال، شناخت FLV برای تبدیل آرشیوهای قدیمی،
مدیریت سامانه‌های Legacy و درک ارتباط تاریخی
میان Flash و RTMP همچنان اهمیت دارد.

MPEG-TS و M2TS

MPEG Transport Stream یا MPEG-TS یک Container
طراحی‌شده برای انتقال پیوسته و مقاوم ویدئو و
صدا در شبکه‌ها، تلویزیون دیجیتال، IPTV و
سامانه‌های Broadcast است. نسخه M2TS نیز
ساختاری نزدیک به MPEG-TS دارد و بیشتر در
دیسک‌های Blu-ray و دوربین‌های AVCHD دیده
می‌شود.

MPEG-TS چیست؟

MPEG-TS مخفف
MPEG Transport Stream
است و داده‌های صوتی، تصویری و اطلاعات کنترلی
را در بسته‌های کوچک و پیوسته منتقل می‌کند.

این ساختار برای محیط‌هایی طراحی شده است که
احتمال گم‌شدن، خراب‌شدن یا تأخیر بعضی بسته‌ها
وجود دارد.

برخلاف Containerهایی مانند MP4 که بیشتر برای
ذخیره فایل کامل مناسب‌اند، MPEG-TS برای انتقال
زنده و دریافت تدریجی Stream بهینه شده است.

ساختار Packet در MPEG-TS

Stream در MPEG-TS به Packetهای کوچک تقسیم
می‌شود. اندازه رایج هر Packet برابر
188 بایت است.

هر Packet دارای Header و Payload است. Header
اطلاعاتی مانند شناسه Stream، ترتیب بسته و
وضعیت خطا را نگهداری می‌کند و Payload شامل
بخشی از داده صوتی، تصویری یا اطلاعات کنترلی
است.

Sync Byte چیست؟

ابتدای هر Packet استاندارد MPEG-TS با یک
Sync Byte مشخص می‌شود.

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

PID در MPEG-TS چیست؟

هر نوع داده داخل Transport Stream با شناسه‌ای
به نام
Packet Identifier یا PID
مشخص می‌شود.

گیرنده با استفاده از PID تشخیص می‌دهد هر Packet
به ویدئو، صدا، زیرنویس یا اطلاعات مدیریتی مربوط
است.

نمونه کاربرد PID در یک Stream
PID نوع داده نمونه
Video PID تصویر H.264 یا HEVC
Audio PID صدا AAC یا AC-3
Subtitle PID زیرنویس یا داده جانبی DVB Subtitle
Control PID اطلاعات ساختار برنامه PAT و PMT

PAT و PMT چه هستند؟

برای اینکه گیرنده بداند چه برنامه‌ها و
Streamهایی داخل MPEG-TS وجود دارند، جدول‌های
کنترلی در Stream ارسال می‌شوند.

دو جدول مهم در این ساختار
PAT
و
PMT
هستند.

تفاوت PAT و PMT
جدول نام کامل وظیفه
PAT Program Association Table معرفی برنامه‌ها و PID مربوط به PMT هر برنامه
PMT Program Map Table معرفی PIDهای ویدئو، صدا و داده‌های هر برنامه

حمل چند برنامه در یک Transport Stream

یک MPEG-TS می‌تواند یک یا چند برنامه مستقل را
هم‌زمان حمل کند.

برای مثال، در پخش تلویزیون دیجیتال ممکن است
چند کانال تلویزیونی داخل یک Transport Stream
مشترک Multiplex شوند.

مقاومت MPEG-TS در برابر خطا

MPEG-TS برای محیط‌های انتقال طراحی شده است؛
بنابراین از Packetهای مستقل، شمارنده ترتیب و
اطلاعات همگام‌سازی استفاده می‌کند.

اگر بخشی از Stream خراب یا گم شود، معمولاً
تنها قسمت کوتاهی از تصویر یا صدا آسیب می‌بیند
و گیرنده می‌تواند با Packetهای بعدی پخش را
ادامه دهد.

قابلیت‌های افزایش پایداری MPEG-TS
قابلیت نقش
Packet ثابت بازیابی سریع مرز داده
Sync Byte حفظ و بازیابی همگام‌سازی
Continuity Counter تشخیص Packet گم‌شده یا تکراری
ارسال تکراری PAT و PMT امکان ورود گیرنده در میانه Stream

PTS، DTS و PCR

برای هماهنگ‌سازی صدا و تصویر و حفظ زمان‌بندی
پخش، MPEG-TS از Timestampهای مختلف استفاده
می‌کند.

Timestampهای مهم در MPEG-TS
مقدار نام کامل وظیفه
PTS Presentation Time Stamp زمان نمایش یا پخش فریم
DTS Decoding Time Stamp زمان Decode فریم
PCR Program Clock Reference مرجع ساعت برای همگام‌سازی گیرنده

Codecهای رایج در MPEG-TS

Streamهای متداول داخل MPEG-TS
نوع Codecهای رایج کاربرد
Video MPEG-2 Video، H.264، HEVC تلویزیون، IPTV و Broadcast
Audio MPEG Audio، AAC، AC-3، E-AC-3 صدا و چندکاناله
Subtitle DVB Subtitle و Teletext زیرنویس Broadcast
Data Service Information و Metadata جدول کانال و اطلاعات برنامه

کاربردهای MPEG-TS

مهم‌ترین کاربردهای MPEG Transport Stream
کاربرد دلیل استفاده
تلویزیون دیجیتال انتقال چند کانال و اطلاعات سرویس
ماهواره مقاومت در برابر خطای انتقال
IPTV ارسال Stream زنده در شبکه
HLS استفاده تاریخی از قطعه‌های TS
دوربین و Capture ذخیره پیوسته و مقاوم‌تر در برابر قطع ناگهانی
Broadcast Studio انتقال و توزیع برنامه زنده

M2TS چیست؟

M2TS نسخه‌ای از MPEG Transport Stream است که
بیشتر در Blu-ray Disc و دوربین‌های مبتنی بر
AVCHD استفاده می‌شود.

Packetهای M2TS معمولاً یک بخش اضافه برای
Timestamp دارند و اندازه آن‌ها نسبت به Packet
استاندارد TS بزرگ‌تر است.

مقایسه Packet در TS و M2TS
قالب اندازه Packet کاربرد رایج
MPEG-TS 188 بایت Broadcast، IPTV و Streaming
M2TS 192 بایت Blu-ray و AVCHD

M2TS در Blu-ray

دیسک‌های Blu-ray معمولاً Streamهای اصلی فیلم،
صدا و زیرنویس را داخل فایل‌های M2TS نگهداری
می‌کنند.

یک فایل M2TS می‌تواند شامل ویدئوی باکیفیت،
چند Track صوتی، زیرنویس تصویری و اطلاعات جانبی
باشد.

داده‌های رایج داخل M2TS در Blu-ray
نوع داده نمونه
Video AVC، HEVC یا MPEG-2
Audio DTS-HD MA، Dolby TrueHD، AC-3
Subtitle PGS
Chapter و Playlist مدیریت‌شده توسط ساختار Blu-ray

مقایسه MPEG-TS و MP4

تفاوت MPEG-TS و MP4
معیار MPEG-TS MP4
هدف اصلی انتقال و پخش زنده ذخیره و توزیع فایل
مقاومت در برابر خطا بالا کمتر
ورود از میانه Stream مناسب وابسته به ساختار فایل
سربار Container بیشتر کمتر
Metadata و آرشیو محدودتر مناسب‌تر
Broadcast بسیار مناسب کاربرد محدودتر

مقایسه MPEG-TS و MKV

کاربرد مناسب TS و MKV
ویژگی MPEG-TS MKV
پخش زنده بسیار مناسب کاربرد محدودتر
آرشیو فیلم متوسط بسیار مناسب
چند زیرنویس و Attachment محدودتر بسیار کامل
تحمل خطای شبکه بهتر کمتر
ویرایش Metadata محدودتر انعطاف‌پذیرتر

تبدیل TS و M2TS به MP4 یا MKV

اگر Codecهای داخلی با Container مقصد سازگار
باشند، می‌توان Streamهای TS یا M2TS را بدون
Encode مجدد به MP4 یا MKV منتقل کرد.

این عملیات Remux نام دارد، سریع است و کیفیت
ویدئو و صدا را تغییر نمی‌دهد.

Transcode فقط زمانی لازم است که Codec مقصد
ناسازگار باشد یا تغییر Resolution، Bitrate،
Frame Rate یا Codec موردنیاز باشد.

تفاوت Remux و Transcode
عملیات تغییر Codec افت کیفیت سرعت
Remux خیر ندارد بسیار سریع
Transcode بله وابسته به تنظیمات کندتر

Remux، Transcode و Re-encode

یکی از رایج‌ترین اشتباهات در دنیای ویدئو،
یکسان دانستن Remux و Transcode است.
این دو فرآیند کاملاً متفاوت هستند و اثر
مستقیمی بر زمان پردازش، کیفیت تصویر، حجم فایل
و مصرف CPU و GPU دارند.

چرا شناخت این سه فرآیند مهم است؟

هنگام تبدیل فایل‌های ویدئویی ممکن است تنها
Container تغییر کند یا کل ویدئو دوباره Encode
شود.

تفاوت این دو حالت می‌تواند چند ثانیه یا چند
ساعت زمان پردازش و همچنین تفاوت قابل توجهی در
کیفیت خروجی ایجاد کند.

Remux چیست؟

در عملیات Remux، Streamهای صوتی، تصویری و
زیرنویس بدون Decode و Encode مجدد، فقط از یک
Container به Container دیگر منتقل می‌شوند.

Codec، Bitrate، Resolution و کیفیت تصویر
کاملاً بدون تغییر باقی می‌مانند.

Transcode چیست؟

در عملیات Transcode ابتدا فایل Decode شده و
سپس دوباره توسط یک Codec دیگر Encode می‌شود.

این فرآیند معمولاً برای کاهش حجم فایل،
تغییر Codec یا افزایش سازگاری انجام می‌شود.

Re-encode چیست؟

Re-encode نوعی Transcode است که معمولاً
Codec تغییر نمی‌کند اما ویدئو دوباره Encode
می‌شود.

برای مثال H.264 دوباره به H.264 تبدیل می‌شود
ولی Bitrate یا Resolution تغییر می‌کند.

مقایسه Remux، Transcode و Re-encode

تفاوت سه فرآیند اصلی
ویژگی Remux Transcode Re-encode
Decode خیر بله بله
Encode خیر بله بله
تغییر Codec خیر معمولاً بله خیر
افت کیفیت ندارد ممکن است ممکن است
سرعت بسیار سریع کند کند

مصرف CPU و GPU

میزان مصرف منابع
عملیات CPU GPU
Remux بسیار کم تقریباً صفر
Software Transcode بسیار زیاد ندارد
Hardware Encode متوسط زیاد

مثال‌های عملی

نمونه عملیات
عملیات نتیجه
MKV → MP4 معمولاً Remux
H.264 → HEVC Transcode
H.264 50Mbps → H.264 10Mbps Re-encode
Blu-ray M2TS → MKV معمولاً Remux

چه زمانی از هرکدام استفاده کنیم؟

انتخاب مناسب
نیاز بهترین انتخاب
فقط تغییر Container Remux
کاهش حجم فایل Transcode
تغییر Codec Transcode
تغییر Resolution Re-encode
تغییر Bitrate Re-encode

Pipeline کامل پردازش ویدئو

پردازش ویدئو فقط به Decode یا Encode محدود
نمی‌شود. از لحظه دریافت تصویر تا نمایش،
ذخیره یا ارسال آن، چندین مرحله متوالی انجام
می‌شود که در مجموع Video Processing Pipeline
نام دارند.

Video Processing Pipeline چیست؟

Video Processing Pipeline زنجیره‌ای از مراحل
سخت‌افزاری و نرم‌افزاری است که داده تصویری را
از منبع دریافت کرده و برای نمایش، تدوین،
ذخیره‌سازی یا انتقال آماده می‌کند.

هر مرحله ممکن است توسط CPU، موتور ویدئویی
اختصاصی GPU، Shader Core، واحد پردازش تصویر،
حافظه یا نرم‌افزار انجام شود.

مراحل اصلی Pipeline ویدئو

وظیفه هر مرحله در Pipeline

مراحل اصلی پردازش ویدئو و وظیفه آن‌ها
مرحله وظیفه واحد درگیر
Capture دریافت تصویر از دوربین، نمایشگر یا ورودی خارجی Capture Device، CPU یا GPU
Demux جداسازی Streamهای صوت، تصویر و زیرنویس نرم‌افزار و CPU
Decode تبدیل Bitstream فشرده به Frame NVDEC، VCN، QSV یا CPU
Color Conversion تبدیل YUV، RGB، Bit Depth و Color Space GPU، Video Processor یا CPU
Scaling تغییر Resolution Shader، Scaler یا CPU
Filtering حذف نویز، Sharpening و اصلاح تصویر Shader، CUDA، Compute یا CPU
Encode تبدیل Frame به Bitstream فشرده NVENC، VCN، QSV یا CPU
Mux قرار دادن Streamها داخل Container نرم‌افزار و CPU
Output ذخیره، نمایش یا ارسال در شبکه Storage، Display Engine یا Network

منابع ورودی ویدئو

Pipeline ویدئو می‌تواند از منابع مختلفی آغاز
شود. نوع منبع مشخص می‌کند اولین مرحله Capture،
خواندن فایل یا دریافت Stream شبکه باشد.

انواع ورودی در Pipeline ویدئو
منبع نوع داده مرحله اول
دوربین تصویر زنده یا Stream فشرده Capture
فایل ویدئویی Container روی Storage Demux
شبکه RTMP، HLS، RTP یا WebRTC دریافت و Buffering
Capture Card HDMI یا SDI Capture و تبدیل سیگنال
ضبط صفحه Frame Buffer دسکتاپ یا بازی Screen Capture
دوربین نظارتی H.264 یا HEVC شبکه‌ای دریافت Stream و Decode

مرحله Capture

Capture به معنی دریافت تصویر از منبعی مانند
دوربین، نمایشگر، کارت کپچر یا خروجی یک برنامه
است.

داده Captureشده ممکن است خام باشد یا از همان
ابتدا با Codec مشخصی فشرده شده باشد.

در ضبط صفحه یا بازی، فریم‌ها معمولاً مستقیماً
از حافظه GPU خوانده و برای پردازش یا Encode
آماده می‌شوند.

انواع Capture

روش‌های رایج دریافت تصویر
روش منبع کاربرد چالش اصلی
Camera Capture دوربین داخلی یا USB تماس تصویری و ضبط Latency و کیفیت سنسور
HDMI Capture کنسول، دوربین یا رایانه دیگر استریم و تولید زنده پهنای باند و تأخیر
SDI Capture تجهیزات Broadcast استودیو حرفه‌ای همگام‌سازی و تجهیزات تخصصی
Screen Capture دسکتاپ یا برنامه آموزش و ارائه وضوح متن و نرخ فریم
Game Capture Frame Buffer بازی ضبط و استریم گیم افت عملکرد و Frame Pacing

مرحله Demux

فایل‌های MP4، MKV، MOV یا TS ممکن است چندین
Stream صوتی، تصویری و زیرنویس داشته باشند.

Demuxer ساختار Container را می‌خواند و Stream
موردنیاز را برای Decoder جدا می‌کند.

در این مرحله هنوز Codec Decode نمی‌شود و کیفیت
تصویر تغییری نمی‌کند.

تفاوت Demux و Decode

مقایسه Demux و Decode
معیار Demux Decode
ورودی Container Bitstream فشرده
خروجی Stream جداشده Frame خام یا نیمه‌خام
تغییر کیفیت ندارد بازسازی تصویر
واحد اصلی CPU و نرم‌افزار Video Engine یا CPU

مرحله Decode

Decoder جریان فشرده H.264، HEVC، VP9 یا AV1 را
به Frameهای قابل پردازش تبدیل می‌کند.

Decode ممکن است توسط CPU یا موتور سخت‌افزاری
اختصاصی مانند NVDEC، AMD VCN و Intel Quick
Sync انجام شود.

پس از Decode، حجم داده بسیار بیشتر از Bitrate
فایل اولیه است؛ زیرا فریم‌ها باید در حافظه برای
پردازش یا نمایش نگهداری شوند.

Decode سخت‌افزاری و نرم‌افزاری در Pipeline

تفاوت مسیر Hardware و Software Decode
معیار Hardware Decode Software Decode
واحد پردازش موتور اختصاصی GPU هسته‌های CPU
مصرف انرژی کمتر بیشتر
مصرف CPU پایین‌تر بالاتر
انعطاف Codec محدود به قابلیت موتور معمولاً گسترده‌تر
چند Stream هم‌زمان معمولاً بهتر وابسته به قدرت CPU

Frame Buffer در Pipeline

فریم‌های Decodeشده باید در RAM یا VRAM نگهداری
شوند تا مراحل بعدی بتوانند آن‌ها را بخوانند.

Codecهای Inter-frame علاوه بر فریم فعلی، چند
Reference Frame را نیز در حافظه نگهداری می‌کنند.

در پروژه‌های Multicam، تدوین چندلایه یا پردازش
AI، ممکن است تعداد زیادی Buffer به‌صورت هم‌زمان
ایجاد شود.

انواع Buffer در پردازش ویدئو
Buffer کاربرد اثر بر حافظه
Decode Buffer نگهداری فریم‌های بازسازی‌شده وابسته به Resolution و Codec
Reference Buffer پیش‌بینی فریم‌های بعدی وابسته به GOP و Codec
Processing Buffer افکت، Color و Scaling افزایش مصرف VRAM
Encode Buffer آماده‌سازی فریم برای Encoder وابسته به Bit Depth و Chroma
Display Buffer ارائه تصویر به نمایشگر وابسته به Resolution خروجی

Zero-Copy Pipeline

در Pipeline بهینه، فریم‌ها پس از Decode داخل
حافظه GPU باقی می‌مانند و بدون کپی‌شدن به RAM،
وارد مراحل Scaling، افکت و Encode می‌شوند.

این روش Latency، مصرف پهنای باند PCI Express و
بار CPU را کاهش می‌دهد.

هزینه انتقال فریم میان RAM و VRAM

اگر یک مرحله روی CPU و مرحله بعدی روی GPU اجرا
شود، ممکن است فریم چندین‌بار میان RAM و VRAM
جابه‌جا شود.

در Resolutionهای بالا و چند Stream هم‌زمان،
این انتقال می‌تواند به گلوگاه مهمی تبدیل شود.

پیامدهای انتقال مکرر Frame Buffer
پیامد نتیجه
مصرف PCI Express کاهش پهنای باند در دسترس
افزایش Latency تأخیر بیشتر در استریم و Preview
مصرف CPU افزایش مدیریت حافظه و کپی داده
افت Throughput کاهش تعداد Streamهای قابل پردازش

گلوگاه‌های مراحل ابتدایی Pipeline

مشکلات رایج از ورودی تا Decode
گلوگاه نشانه علت احتمالی
Capture Device افت فریم ورودی پهنای باند USB، HDMI یا درایور
Network Buffer توقف یا نوسان تصویر Packet Loss یا Jitter
Storage Timeline ناپایدار سرعت خواندن ناکافی
Demuxer خطا در بازکردن فایل Container خراب یا ناسازگار
Decoder مصرف CPU بالا یا Frame Drop نبود Hardware Decode سازگار
Memory Copy Latency و مصرف منابع زیاد انتقال مکرر میان RAM و VRAM

Color Space Conversion در Pipeline ویدئو

فریم Decodeشده همیشه در قالب مناسب نمایش، تدوین یا
Encode بعدی قرار ندارد. به همین دلیل ممکن است لازم
باشد فضای رنگ، مدل رنگ، دامنه سیگنال یا عمق رنگ آن
تغییر کند.

تبدیل‌هایی مانند YUV به RGB، Limited Range به
Full Range، Rec.709 به Rec.2020 و SDR به HDR یا
برعکس، در این مرحله انجام می‌شوند.

این عملیات ممکن است توسط موتور پردازش ویدئو،
Shaderهای GPU، واحدهای Compute یا CPU اجرا شود.

تفاوت YUV و RGB

بیشتر فایل‌های فشرده ویدئویی با ساختاری مبتنی بر
روشنایی و مؤلفه‌های رنگ ذخیره می‌شوند که معمولاً
با نام عمومی YUV یا دقیق‌تر YCbCr شناخته می‌شود.

نمایشگرها و بسیاری از مراحل رندر گرافیکی معمولاً
با مقادیر قرمز، سبز و آبی یا RGB کار می‌کنند.

بنابراین در مسیر پخش یا تدوین، تبدیل میان YUV و RGB
یکی از عملیات بسیار رایج است.

مقایسه ساختارهای YUV و RGB
معیار YUV / YCbCr RGB
مؤلفه‌ها روشنایی و اطلاعات رنگ قرمز، سبز و آبی
کاربرد اصلی Codec، Broadcast و Video نمایشگر، رابط کاربری و رندر
Chroma Subsampling رایج معمولاً وجود ندارد
حجم داده قابل کاهش با 4:2:0 و 4:2:2 معمولاً بیشتر
مناسب تدوین گرافیکی وابسته به Workflow بسیار رایج

مسیر تبدیل YUV به RGB

هنگام پخش یک فایل ویدئویی، Decoder معمولاً فریم را
در قالب YUV تولید می‌کند. سپس Display Pipeline یا
GPU آن را به RGB مناسب نمایشگر تبدیل می‌کند.

اگر ماتریس رنگ، Range یا Transfer Function به‌درستی
تفسیر نشوند، تصویر ممکن است روشن‌تر، تیره‌تر،
کم‌رنگ یا دارای رنگ‌های اشتباه نمایش داده شود.

Color Matrix چیست؟

Color Matrix مجموعه ضرایبی است که نحوه تبدیل
مؤلفه‌های YCbCr به RGB و برعکس را تعیین می‌کند.

استانداردهایی مانند Rec.601، Rec.709 و Rec.2020
از ضرایب متفاوتی استفاده می‌کنند.

انتخاب Matrix اشتباه می‌تواند باعث تغییر محسوس
رنگ پوست، سبزها، قرمزها و میزان اشباع تصویر شود.

ماتریس‌های رنگ رایج در ویدئو
استاندارد کاربرد رایج نکته
Rec.601 SD Video رایج در محتوای قدیمی‌تر
Rec.709 HD و SDR استاندارد رایج Full HD
Rec.2020 UHD و HDR محدوده رنگ گسترده‌تر

تفاوت Full Range و Limited Range

دامنه عددی سیگنال ویدئویی می‌تواند به‌صورت Full
Range یا Limited Range تعریف شود.

در Limited Range بخشی از محدوده عددی برای مقادیر
کنترلی و سازگاری Broadcast کنار گذاشته می‌شود،
درحالی‌که Full Range از دامنه گسترده‌تری استفاده
می‌کند.

مقایسه دامنه رنگ Full و Limited
معیار Limited Range Full Range
کاربرد Video و Broadcast رایانه و Graphics
سیاه و سفید در محدوده محدودتر در کل دامنه قابل استفاده
خطر تنظیم اشتباه سیاهی خاکستری یا تصویر کم‌کنتراست ازبین‌رفتن جزئیات سایه و Highlight
استفاده رایج تلویزیون و فایل ویدئویی مانیتور و محتوای رایانه‌ای

خطای Range Mismatch

اگر فایل Limited Range به‌عنوان Full Range تفسیر
شود، سایه‌ها بیش‌ازحد تیره و بخش‌های روشن بریده
می‌شوند.

اگر فایل Full Range به‌عنوان Limited Range نمایش
داده شود، تصویر خاکستری، کم‌کنتراست و شسته‌شده
به نظر می‌رسد.

نشانه‌های تنظیم نادرست Range
خطا نشانه ظاهری نتیجه
Limited به‌عنوان Full سایه‌های بسیار تیره Black Crush و White Clipping
Full به‌عنوان Limited سیاهی خاکستری کاهش Contrast

Transfer Function چیست؟

Transfer Function رابطه میان مقدار عددی سیگنال
و روشنایی قابل نمایش را تعیین می‌کند.

محتوای SDR و HDR از منحنی‌های متفاوتی استفاده
می‌کند. برای نمونه، PQ و HLG برای HDR طراحی
شده‌اند.

Transfer Functionهای رایج
منحنی کاربرد ویژگی
Gamma / BT.1886 SDR نمایش سنتی تلویزیونی
PQ HDR10 و Dolby Vision مدل‌سازی دامنه روشنایی بسیار گسترده
HLG Broadcast HDR مناسب پخش زنده و سازگاری Broadcast

تبدیل SDR و HDR

تبدیل میان SDR و HDR تنها افزایش یا کاهش روشنایی
نیست. فضای رنگ، Transfer Function، Metadata،
Bit Depth و محدوده روشنایی باید هم‌زمان مدیریت
شوند.

تبدیل HDR به SDR معمولاً با Tone Mapping انجام
می‌شود تا جزئیات نقاط روشن در محدوده محدودتر SDR
حفظ شوند.

تبدیل SDR به HDR می‌تواند دامنه روشنایی را گسترش
دهد، اما جزئیات واقعی HDR را که در منبع ثبت نشده‌اند
ایجاد نمی‌کند.

Tone Mapping چیست؟

Tone Mapping دامنه روشنایی تصویر را با توان
نمایشگر یا قالب خروجی هماهنگ می‌کند.

برای مثال، ویدئوی HDR ممکن است نقاط بسیار روشنی
داشته باشد که نمایشگر SDR قادر به نمایش مستقیم
آن‌ها نیست.

الگوریتم Tone Mapping تلاش می‌کند این اطلاعات را
به محدوده کوچک‌تر منتقل کند، بدون اینکه تصویر
بیش‌ازحد تاریک یا Highlightها کاملاً سفید شوند.

اهداف اصلی Tone Mapping
هدف نتیجه
حفظ Highlight کاهش White Clipping
حفظ سایه جلوگیری از تاریک‌شدن بیش‌ازحد
حفظ Contrast طبیعی‌ماندن تصویر
تطبیق با نمایشگر استفاده از توان واقعی پنل

Gamut Mapping چیست؟

اگر فضای رنگ منبع از توان نمایشگر یا مقصد بزرگ‌تر
باشد، بعضی رنگ‌ها خارج از محدوده قابل نمایش قرار
می‌گیرند.

Gamut Mapping این رنگ‌ها را به محدوده مقصد منتقل
می‌کند تا از Clipping شدید یا تغییر غیرطبیعی رنگ
جلوگیری شود.

نمونه تبدیل محدوده رنگ
مبدأ مقصد نیاز اصلی
Rec.2020 Rec.709 فشرده‌سازی Gamut
P3 Rec.709 مدیریت رنگ‌های اشباع
Rec.709 Rec.2020 تبدیل فضای سیگنال بدون ایجاد رنگ واقعی جدید

تبدیل Bit Depth در Pipeline

ممکن است فریم ۱۰ بیت برای پردازش وارد Pipeline
شود، اما خروجی نهایی ۸ بیت باشد یا برعکس.

کاهش Bit Depth می‌تواند باعث Banding شود، به‌ویژه
در Gradientهای نرم، آسمان، سایه و محتوای HDR.

افزایش عددی Bit Depth بدون وجود اطلاعات واقعی
بیشتر، جزئیات ازدست‌رفته را بازسازی نمی‌کند؛ اما
می‌تواند برای پردازش داخلی دقیق‌تر مفید باشد.

اثر تبدیل عمق رنگ
تبدیل نتیجه خطر
10-bit به 8-bit کاهش سطوح رنگ Banding
8-bit به 10-bit فضای پردازشی بزرگ‌تر ایجادنشدن اطلاعات واقعی جدید
Integer به Float دقت بیشتر در پردازش میانی مصرف حافظه و محاسبات بیشتر

Dithering در کاهش Bit Depth

هنگام تبدیل ویدئوی ۱۰ یا ۱۲ بیت به ۸ بیت، Dithering
می‌تواند احتمال Banding را کاهش دهد.

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

Scaling در Pipeline ویدئو

Scaling به معنی تغییر Resolution تصویر است.
کاهش وضوح Downscaling و افزایش وضوح Upscaling
نامیده می‌شود.

کیفیت Scaling به الگوریتم، Bit Depth، Chroma،
نوع محتوا و توان واحد پردازشی وابسته است.

Scaling ممکن است توسط Shaderهای GPU، واحد ثابت
Video Processor، نمایشگر یا CPU انجام شود.

انواع Scaling در ویدئو
نوع نمونه کاربرد
Downscaling 4K به 1080p کاهش حجم و سازگاری
Upscaling 1080p به 4K تطبیق با نمایشگر یا خروجی
Aspect Ratio Scaling 4:3 به 16:9 تطبیق قاب تصویر
Adaptive Scaling تولید چند Resolution Streaming تطبیقی

الگوریتم‌های Scaling

مقایسه الگوریتم‌های رایج Scaling
الگوریتم سرعت کیفیت کاربرد
Nearest Neighbor بسیار سریع پایین Pixel Art و کاربرد خاص
Bilinear سریع متوسط پردازش Real-Time
Bicubic متوسط خوب تدوین و خروجی عمومی
Lanczos کندتر بالا Downscaling باکیفیت
AI Upscaling وابسته به سخت‌افزار بالقوه بسیار بالا بازسازی جزئیات و Super Resolution

Chroma Scaling

در فایل‌های 4:2:0 و 4:2:2، وضوح اطلاعات رنگ کمتر
از وضوح روشنایی است.

پیش از تبدیل YUV به RGB یا اجرای بعضی افکت‌ها،
اطلاعات Chroma باید Upsample شود.

الگوریتم ضعیف Chroma Upsampling می‌تواند باعث
لبه‌های رنگی، تاری متن یا تغییر رنگ در مرز اجسام
شود.

Aspect Ratio در Scaling

تغییر Resolution بدون توجه به نسبت تصویر می‌تواند
باعث کشیدگی یا فشردگی سوژه‌ها شود.

Pipeline باید میان Pixel Aspect Ratio، Display
Aspect Ratio و Resolution واقعی تفاوت قائل شود.

روش‌های مدیریت نسبت تصویر
روش نتیجه کاربرد
Stretch پرشدن قاب با تغییر شکل تصویر معمولاً نامطلوب
Letterbox نوار افقی یا عمودی حفظ کامل تصویر
Crop حذف بخشی از تصویر پرکردن کامل قاب
Smart Reframe Crop متحرک بر اساس سوژه شبکه‌های اجتماعی و AI

ویدئوی Interlaced چیست؟

در ویدئوی Interlaced هر تصویر به دو Field تقسیم
می‌شود. یک Field خطوط فرد و Field دیگر خطوط زوج
تصویر را نگهداری می‌کند.

این روش در تلویزیون‌های قدیمی و بسیاری از سیستم‌های
Broadcast استفاده می‌شد تا با پهنای باند محدود،
حرکت روان‌تری ایجاد شود.

Deinterlacing چیست؟

نمایشگرهای جدید Progressive هستند و باید دو Field
ویدئوی Interlaced را به فریم کامل تبدیل کنند.

این عملیات Deinterlacing نام دارد و کیفیت آن
تأثیر مستقیمی بر وضوح و روانی حرکت دارد.

Deinterlacing می‌تواند توسط Display Engine،
Video Processor، Shaderهای GPU یا CPU انجام شود.

روش‌های رایج Deinterlacing
روش کیفیت ویژگی
Weave مناسب تصویر ثابت ترکیب دو Field بدون تحلیل حرکت
Bob متوسط تبدیل هر Field به فریم مستقل
Motion Adaptive خوب انتخاب روش بر اساس حرکت
Motion Compensated بسیار بالا بازسازی بر اساس تخمین حرکت
AI Deinterlacing بالقوه بسیار بالا بازسازی Field با مدل یادگیری ماشین

خطاهای رایج Deinterlacing

Artifactهای ناشی از Deinterlacing نامناسب
خطا ظاهر علت
Combing لبه‌های دندانه‌دار در حرکت ترکیب Fieldهای متعلق به زمان‌های متفاوت
Flicker لرزش خطوط ریز بازسازی ضعیف Field
کاهش وضوح تصویر نرم یا تار Bob یا فیلتر ساده
Ghosting رد حرکت تحلیل نادرست Motion

کدام واحدها Color Conversion و Scaling را انجام می‌دهند؟

تقسیم وظایف مراحل میانی Pipeline
عملیات واحد احتمالی نکته
YUV به RGB Video Processor، Shader یا Display Engine وابسته به مسیر نمایش یا تدوین
Tone Mapping Shader، Compute، AI یا نمایشگر کیفیت الگوریتم اهمیت زیادی دارد
Scaling Fixed-Function Scaler، Shader یا CPU کیفیت و سرعت متفاوت است
Deinterlacing Video Processor، GPU یا CPU نیازمند تحلیل حرکت در روش‌های پیشرفته
Bit Depth Conversion Shader، Video Processor یا Encoder Dithering ممکن است لازم باشد
Gamut Mapping Color Management Engine یا Shader وابسته به پروفایل رنگ و خروجی

گلوگاه‌های مراحل میانی Pipeline

مشکلات رایج در Color، Scaling و Deinterlacing
گلوگاه نشانه علت احتمالی
Color Conversion رنگ یا Contrast اشتباه Matrix، Range یا Transfer نادرست
Tone Mapping HDR بسیار تاریک یا روشن الگوریتم نامناسب یا Metadata ناقص
Scaling تاری، Halo یا لبه‌های دندانه‌دار الگوریتم ضعیف یا Resize چندباره
Chroma Upsampling متن رنگی تار بازسازی ضعیف 4:2:0 یا 4:2:2
Deinterlacing Combing یا Ghosting تحلیل حرکت نامناسب
Memory Bandwidth افت سرعت در 4K یا 8K چند Buffer و فیلتر هم‌زمان

مرحله Filtering و Video Processing

پس از Decode، تبدیل فضای رنگ و تغییر Resolution،
معمولاً تصویر وارد مرحله‌ای می‌شود که در آن
کیفیت تصویر بهبود یافته یا افکت‌های مختلف روی آن
اعمال می‌شوند.

این مرحله ممکن است شامل حذف نویز، افزایش وضوح،
اصلاح رنگ، تثبیت تصویر، هوش مصنوعی، جلوه‌های ویژه
یا پردازش‌های تخصصی دیگر باشد.

بسته به نوع نرم‌افزار و سخت‌افزار، این عملیات
می‌تواند روی CPU، Shaderهای GPU، واحدهای Compute،
Tensor Core یا NPU انجام شود.

جایگاه Filtering در Pipeline

انواع Filterهای پردازش تصویر

مهم‌ترین گروه‌های Filter در پردازش ویدئو
گروه هدف نمونه
Noise Reduction حذف نویز Denoise
Sharpening افزایش وضوح Unsharp Mask
Color Correction اصلاح رنگ White Balance
Tone Mapping مدیریت HDR PQ → SDR
Geometric تغییر شکل تصویر Rotate و Crop
AI Filters بازسازی تصویر Super Resolution

Noise Reduction یا Denoising

نویز می‌تواند توسط سنسور دوربین، ISO بالا،
فشرده‌سازی شدید یا انتقال تصویر ایجاد شود.

الگوریتم‌های Denoise تلاش می‌کنند بدون از بین بردن
جزئیات مهم، نویز را کاهش دهند.

انواع Denoise
روش ویژگی سرعت
Spatial بررسی پیکسل‌های همسایه زیاد
Temporal استفاده از چند Frame متوسط
AI Denoise مدل یادگیری ماشین وابسته به GPU

Sharpening

Sharpening اختلاف روشنایی در لبه‌ها را افزایش
می‌دهد تا تصویر واضح‌تر به نظر برسد.

افزایش بیش از حد Sharpening باعث Halo، نویز و
مصنوعی‌شدن تصویر می‌شود.

Color Correction

Color Correction برای اصلاح خطاهای ثبت تصویر
استفاده می‌شود و معمولاً شامل تنظیم White Balance،
Exposure، Contrast، Saturation و Gamma است.

هدف این مرحله بازگرداندن تصویر به ظاهر طبیعی است،
نه ایجاد سبک هنری.

Color Grading

برخلاف Color Correction، در Color Grading ظاهر
هنری تصویر تغییر داده می‌شود.

فیلم‌های سینمایی، تبلیغات و بازی‌های رایانه‌ای
معمولاً از Grading برای ایجاد حس بصری خاص استفاده
می‌کنند.

تفاوت Color Correction و Color Grading
معیار Correction Grading
هدف اصلاح تصویر خلق ظاهر هنری
زمان انجام ابتدای تدوین پس از اصلاح
نمونه اصلاح White Balance ظاهر سینمایی گرم یا سرد

پردازش مبتنی بر هوش مصنوعی

در سال‌های اخیر بسیاری از مراحل Pipeline توسط
مدل‌های هوش مصنوعی انجام می‌شوند.

این مدل‌ها می‌توانند جزئیات ازدست‌رفته را بازسازی،
نویز را حذف، چهره را ترمیم یا Resolution را افزایش
دهند.

کاربردهای AI در پردازش ویدئو
عملیات هدف
AI Upscaling افزایش Resolution
AI Denoise حذف نویز
Frame Interpolation افزایش نرخ فریم
Object Removal حذف عناصر ناخواسته
Face Restoration ترمیم چهره
Background Replacement تعویض پس‌زمینه

اجرای Filterها توسط کدام واحد؟

تقسیم وظایف سخت‌افزاری
عملیات واحد رایج
Blur Shader یا Compute
Sharpen Shader
Color LUT Shader
AI Processing Tensor Core یا NPU
Temporal Filter GPU Compute یا CPU
Motion Estimation Video Engine یا GPU

گلوگاه‌های مرحله Filtering

مشکلات رایج هنگام پردازش تصویر
گلوگاه پیامد
فیلترهای AI سنگین افزایش زمان پردازش
کمبود VRAM جابجایی مکرر داده میان RAM و VRAM
فیلترهای متعدد کاهش سرعت Timeline
Temporal Filter مصرف حافظه زیاد
CPU Processing استفاده زیاد از پردازنده

مرحله Encode

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

Encoder با استفاده از Codec انتخاب‌شده مانند
H.264، HEVC، AV1 یا VP9 داده تصویری را فشرده
می‌کند تا برای ذخیره یا انتقال مناسب باشد.

برخلاف Decoder که Bitstream را بازسازی می‌کند،
Encoder باید تصمیم بگیرد کدام اطلاعات حفظ شوند،
کدام قسمت‌ها حذف شوند و هر Frame چگونه فشرده شود.

مسیر Encode در Pipeline

Encoder چه کارهایی انجام می‌دهد؟

مراحل اصلی عملیات Encode
مرحله توضیح
Motion Estimation تشخیص حرکت میان Frameها
Prediction پیش‌بینی بخش‌های مشابه تصویر
Transform تبدیل داده برای فشرده‌سازی
Quantization کاهش دقت داده برای کم‌شدن حجم
Entropy Coding تولید Bitstream نهایی

Encode سخت‌افزاری و نرم‌افزاری

مقایسه Hardware و Software Encoding
ویژگی Hardware Software
سرعت بسیار زیاد کمتر
مصرف CPU پایین زیاد
کیفیت در Bitrate پایین معمولاً کمتر معمولاً بهتر
تنظیمات قابل کنترل محدودتر بسیار گسترده
مناسب برای Live Streaming آرشیو و خروجی نهایی

مرحله Multiplexing یا Mux

خروجی Encoder تنها Stream تصویری است. برای تولید
فایل نهایی باید این Stream همراه با صدا، زیرنویس،
Chapter و Metadata داخل یک Container قرار گیرد.

این عملیات Multiplexing یا به اختصار Mux نام
دارد.

تفاوت Demux و Mux

مقایسه Demux و Mux
معیار Demux Mux
ورودی Container Streamهای جداگانه
خروجی Streamها Container
جهت عملیات جداسازی ترکیب
تغییر Codec خیر خیر

خروجی نهایی Pipeline

پس از عملیات Mux، خروجی می‌تواند به‌صورت فایل،
Stream زنده یا مستقیماً برای نمایش ارسال شود.

انواع خروجی Pipeline
خروجی نمونه
File MP4، MKV، MOV
Streaming RTMP، HLS، DASH، WebRTC
Broadcast MPEG-TS
Display نمایش مستقیم روی مانیتور

Pipeline هنگام پخش ویدئو

تفاوت Export و Playback

مقایسه Export و Playback
معیار Playback Export
Encode معمولاً ندارد دارد
Mux ندارد دارد
سرعت Real-Time وابسته به پروژه
خروجی نمایش تصویر فایل یا Stream

جمع‌بندی کامل Pipeline ویدئو

گلوگاه‌های رایج Pipeline

عوامل محدودکننده عملکرد Pipeline
مرحله گلوگاه رایج
Capture پهنای باند ورودی
Decode توان Decoder
Color Processing Memory Bandwidth
Scaling Shader یا Video Processor
Filtering GPU Compute و VRAM
Encode Encoder و Bitrate
Mux Storage و I/O
Output دیسک یا شبکه

معماری سخت‌افزاری پردازش ویدئو در GPU

پردازش ویدئو در GPU تنها توسط یک واحد انجام
نمی‌شود. موتور Decode، موتور Encode، واحدهای
Shader یا Compute، حافظه گرافیکی، موتور نمایش
و مسیرهای انتقال داده، همگی بخش‌هایی از یک
زیرسیستم هماهنگ هستند که هرکدام وظیفه مشخصی
در Pipeline ویدئو دارند.

نمای کلی معماری پردازش ویدئو در GPU

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

Decode و Encode Codecهای مشخص معمولاً روی
موتورهای ثابت انجام می‌شوند، اما افکت،
Color Grading، Scaling پیشرفته، پردازش AI و
Compositing به Shader Core، Compute Unit یا
واحدهای هوش مصنوعی نیاز دارند.

مسیر کامل داده درون GPU

واحدهای اصلی در پردازش ویدئو

اجزای سخت‌افزاری درگیر در Pipeline ویدئو
واحد وظیفه اصلی نمونه عملیات
Decode Engine بازکردن Bitstream فشرده H.264، HEVC، VP9 و AV1 Decode
Encode Engine فشرده‌سازی Frameها ضبط، Export و Streaming
Shader Core پردازش قابل برنامه‌ریزی تصویر Color، Blur، Sharpen و Scaling
Compute Unit عملیات محاسباتی عمومی Denoise، Optical Flow و Effects
AI Accelerator اجرای مدل‌های یادگیری ماشین Upscaling، حذف نویز و تشخیص اشیا
Display Engine آماده‌سازی خروجی نمایشگر Timing، HDR، Overlay و Scanout
Memory Controller مدیریت دسترسی به VRAM انتقال Frame Buffer و Texture
Copy Engine جابه‌جایی داده میان حافظه‌ها RAM به VRAM و Buffer Copy

واحدهای Fixed-Function چیستند؟

واحد Fixed-Function مداری است که برای انجام
مجموعه‌ای مشخص از عملیات طراحی شده است.

موتورهای NVENC، NVDEC، AMD VCN و Intel Media
Engine نمونه‌هایی از واحدهای Fixed-Function
هستند.

این واحدها انعطاف Shaderها را ندارند، اما برای
وظیفه تخصصی خود معمولاً سریع‌تر و کم‌مصرف‌تر
هستند.

ویژگی‌های واحدهای Fixed-Function
ویژگی نتیجه
طراحی تخصصی سرعت زیاد برای Codecهای مشخص
مصرف انرژی کمتر مناسب لپ‌تاپ و پخش طولانی
انعطاف محدود فقط قابلیت‌های پیاده‌سازی‌شده در سخت‌افزار
فعالیت مستقل امکان Encode یا Decode هم‌زمان با Shader
وابستگی به نسل تفاوت Codec و Profile در معماری‌های مختلف

واحدهای قابل برنامه‌ریزی

Shader Coreها و Compute Unitها می‌توانند
الگوریتم‌های متنوعی را اجرا کنند و محدود به
یک Codec یا عملیات ثابت نیستند.

این واحدها معمولاً برای پردازش‌های میانی
Pipeline مانند Color، Scaling، Filtering،
Compositing، Optical Flow و AI استفاده می‌شوند.

تفاوت واحد ثابت و قابل برنامه‌ریزی
معیار Fixed-Function Programmable Unit
انعطاف محدود بسیار زیاد
مصرف انرژی برای Codec کمتر بیشتر
قابلیت اجرای افکت محدود یا ندارد گسترده
قابلیت به‌روزرسانی الگوریتم محدود به سخت‌افزار از طریق نرم‌افزار و Shader
وظیفه رایج Encode و Decode Processing و Effects

نقش Shader Core در پردازش ویدئو

Shader Coreها تنها برای بازی و رندر سه‌بعدی
استفاده نمی‌شوند. بسیاری از افکت‌ها و
تبدیل‌های تصویری نیز با Shader اجرا می‌شوند.

هرچه Resolution، Bit Depth و تعداد Layerها
بیشتر باشد، تعداد عملیات موردنیاز Shaderها
نیز افزایش پیدا می‌کند.

وظایف رایج Shaderها در ویدئو
عملیات توضیح فشار سخت‌افزاری
Color Correction تغییر رنگ، Gamma و Contrast متوسط
LUT Processing اعمال جدول تبدیل رنگ کم تا متوسط
Scaling تغییر Resolution وابسته به الگوریتم
Blur و Sharpen فیلترهای Spatial متوسط
Compositing ترکیب چند Layer زیاد
Noise Reduction پردازش Spatial یا Temporal زیاد تا بسیار زیاد

نقش Compute در ویدئو

Compute APIهایی مانند CUDA، OpenCL، DirectCompute
و Metal اجازه می‌دهند نرم‌افزار الگوریتم‌های
پیچیده پردازش ویدئو را روی GPU اجرا کند.

پردازش Temporal، Optical Flow، Stabilization،
Noise Reduction و بعضی عملیات RAW Processing
معمولاً به Compute وابسته هستند.

نقش Tensor Core، XMX و واحدهای AI

بعضی GPUها دارای واحدهای اختصاصی برای محاسبات
ماتریسی و مدل‌های هوش مصنوعی هستند.

این واحدها می‌توانند الگوریتم‌هایی مانند
Super Resolution، Frame Interpolation،
Denoising، Background Removal و Face
Restoration را سریع‌تر اجرا کنند.

نام واحدهای هوش مصنوعی در معماری‌های مختلف
سازنده نام واحد کاربرد ویدئویی
NVIDIA Tensor Core AI Upscaling، Denoise و Inference
Intel XMX XeSS، AI Processing و Media Effects
AMD AI Accelerator پردازش مدل‌های AI در معماری‌های مناسب
Apple Neural Engine Video Effects و Machine Learning

تفاوت Video Engine و واحد AI

مقایسه موتور Codec و شتاب‌دهنده AI
معیار Video Engine AI Accelerator
وظیفه اصلی Encode و Decode Codec اجرای مدل یادگیری ماشین
ورودی Bitstream یا Frame Tensor و داده پردازشی
انعطاف محدود به Codecها وابسته به مدل نرم‌افزاری
نمونه کاربرد H.264 و AV1 Encode Upscaling و حذف پس‌زمینه
فعالیت هم‌زمان امکان‌پذیر امکان‌پذیر

Display Engine چیست؟

Display Engine بخش مستقلی از GPU است که Frame
نهایی را از حافظه خوانده و با Timing مناسب به
خروجی‌های HDMI، DisplayPort یا پنل داخلی
ارسال می‌کند.

این واحد ممکن است وظایفی مانند Scaling نهایی،
ترکیب Overlayها، مدیریت HDR، تبدیل Range،
Refresh Rate و همگام‌سازی نمایشگر را انجام دهد.

وظایف اصلی Display Engine
وظیفه توضیح
Scanout خواندن Frame Buffer و ارسال به نمایشگر
Timing تولید زمان‌بندی پیکسل و Refresh Rate
Overlay ترکیب Video Plane و رابط کاربری
HDR Output ارسال Metadata و سیگنال HDR
Output Encoding آماده‌سازی سیگنال HDMI یا DisplayPort

Video Overlay و Hardware Plane

بعضی GPUها می‌توانند ویدئو را روی یک Hardware
Plane مستقل از رابط کاربری نمایش دهند.

در این حالت، Display Engine تصویر ویدئو و
Desktop را هنگام خروجی ترکیب می‌کند و نیاز
به Compositing کامل توسط Shader کاهش می‌یابد.

Copy Engine و انتقال Frame

Copy Engine برای جابه‌جایی داده میان RAM،
VRAM و Bufferهای مختلف استفاده می‌شود.

این واحد می‌تواند انتقال داده را بدون اشغال
کامل Shaderها انجام دهد، اما همچنان به پهنای
باند PCI Express و حافظه محدود است.

مسیرهای رایج انتقال داده ویدئویی
مسیر کاربرد گلوگاه احتمالی
RAM به VRAM بارگذاری Frame یا Texture PCI Express
VRAM به RAM Readback، Capture یا پردازش CPU Latency و پهنای باند
VRAM به VRAM کپی میان Bufferها Memory Bandwidth
GPU به GPU سیستم‌های چند GPU Interconnect یا PCI Express

فعالیت هم‌زمان واحدهای مختلف GPU

یکی از مزیت‌های GPU مدرن این است که Decode،
Compute، Encode و Display می‌توانند تا حدی
هم‌زمان فعالیت کنند.

برای مثال، در یک Workflow زنده ممکن است NVDEC
فریم ورودی را Decode کند، Shaderها افکت را
اعمال کنند و NVENC هم‌زمان Frame قبلی را
Encode کند.

پردازش Asynchronous در Pipeline

در پردازش Asynchronous، نرم‌افزار تلاش می‌کند
هر موتور مستقل GPU را بدون انتظار غیرضروری
برای سایر بخش‌ها مشغول نگه دارد.

استفاده صحیح از Queueها، Fenceها، Bufferها و
Synchronization می‌تواند Throughput را افزایش
دهد.

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

تعادل میان واحدهای GPU

قدرت بالای یک واحد به‌تنهایی عملکرد کل Pipeline
را تضمین نمی‌کند.

ممکن است Encoder بسیار سریع باشد، اما Decode،
VRAM، Memory Bandwidth یا Shader Processing
نتواند Frame کافی در اختیار آن قرار دهد.

نمونه عدم تعادل در معماری ویدئویی
بخش قدرتمند بخش محدودکننده نتیجه
Encode Engine Shader Processing Encoder منتظر Frame می‌ماند
Shader Core Decode Engine ورودی کافی برای افکت وجود ندارد
Decode Engine VRAM چند Stream قابل نگهداری نیست
AI Accelerator Memory Bandwidth مدل منتظر انتقال داده می‌ماند
GPU Compute PCI Express انتقال RAM و VRAM گلوگاه می‌شود

گلوگاه‌های رایج معماری GPU در ویدئو

محدودیت‌های متداول در زیرسیستم ویدئویی GPU
گلوگاه نشانه علت احتمالی
Video Decode افت فریم در پخش چند Stream Throughput ناکافی Decoder
Video Encode Export یا Stream کند Session یا ظرفیت Encoder
Shader Core Preview کند با افکت فعال بار زیاد Color یا Filtering
AI Unit کندی Super Resolution ظرفیت کم یا نبود شتاب‌دهنده سازگار
VRAM Stutter یا انتقال به RAM ظرفیت ناکافی Frame Buffer
Memory Bandwidth افت سرعت در 8K و Multicam انتقال چند Buffer بزرگ
Copy Engine تأخیر در Readback یا Upload انتقال‌های هم‌زمان زیاد
PCI Express کندی میان CPU و GPU Zero-Copy نبودن Pipeline

موتورهای پردازش ویدئو در GPUهای مدرن

تقریباً تمام GPUهای امروزی دارای یک یا چند
موتور اختصاصی برای Decode و Encode ویدئو هستند.
این موتورها مستقل از Shader Coreها کار
می‌کنند و وظیفه آن‌ها اجرای سریع و کم‌مصرف
Codecهای ویدئویی است.

Video Engine چیست؟

Video Engine مجموعه‌ای از مدارهای
Fixed-Function است که عملیات Decode،
Encode و در بعضی معماری‌ها پردازش‌های جانبی
ویدئو را انجام می‌دهد.

این موتور به گونه‌ای طراحی شده است که بدون
اشغال Shader Coreها بتواند چندین Stream
ویدئویی را با مصرف انرژی پایین پردازش کند.

معماری عمومی موتورهای ویدئویی

NVIDIA Video Engine

NVIDIA برای Decode از موتور
NVDEC
و برای Encode از
NVENC
استفاده می‌کند.

این دو موتور از Shaderها مستقل هستند و حتی
هنگام اجرای بازی یا رندر سه‌بعدی نیز می‌توانند
فعال باقی بمانند.

اجزای موتور ویدئویی NVIDIA
واحد وظیفه
NVDEC Decode سخت‌افزاری
NVENC Encode سخت‌افزاری
Optical Flow Engine تحلیل حرکت
Tensor Core AI Video Processing

AMD Video Core Next (VCN)

AMD از معماری
Video Core Next یا VCN
برای Encode و Decode استفاده می‌کند.

VCN نسل‌های مختلفی دارد که هر نسل قابلیت
پشتیبانی از Codecهای بیشتری را اضافه کرده است.

اجزای VCN
واحد وظیفه
Decode بازکردن Stream
Encode تولید Stream فشرده
Memory Interface ارتباط با VRAM

Intel Media Engine و Quick Sync Video

اینتل سال‌هاست از فناوری
Quick Sync Video
برای Encode و Decode سخت‌افزاری استفاده می‌کند.

در معماری‌های جدید Xe، این قابلیت بخشی از
Media Engine محسوب می‌شود و در کنار واحدهای
XMX برای پردازش AI فعالیت می‌کند.

اجزای Media Engine اینتل
بخش وظیفه
Quick Sync Encode و Decode
XMX AI Processing
Display Engine خروجی تصویر

مقایسه موتورهای ویدئویی

مقایسه کلی معماری‌های ویدئویی
سازنده نام موتور Decode Encode قابلیت‌های ویژه
NVIDIA NVDEC / NVENC بله بله Optical Flow، Tensor Core
AMD VCN بله بله Video Core Next
Intel Media Engine بله بله Quick Sync، XMX

اجرای هم‌زمان موتورهای ویدئویی

یکی از مهم‌ترین مزایای GPUهای مدرن، اجرای
موازی چند موتور مستقل است.

گلوگاه‌های موتورهای ویدئویی

محدودیت‌های رایج Video Engine
گلوگاه پیامد
ظرفیت Decode کاهش تعداد Stream هم‌زمان
ظرفیت Encode کاهش سرعت Export
Memory Bandwidth انتظار موتورهای ویدئویی برای داده
VRAM محدودشدن تعداد Frame Bufferها
انتقال RAM و VRAM افزایش Latency

نسل‌های موتورهای Encode و Decode

نام Video Engine تنها بخشی از مشخصات آن است.
آنچه در عمل اهمیت بیشتری دارد، نسل موتور است.
هر نسل قابلیت پشتیبانی از Codecهای جدید،
Bit Depth بالاتر، Chroma Sampling متنوع‌تر،
رزولوشن‌های بزرگ‌تر و نرخ فریم بیشتر را اضافه
می‌کند.

چرا نسل Video Engine مهم‌تر از مدل GPU است؟

ممکن است دو کارت گرافیک از نظر تعداد Shader،
فرکانس یا حافظه تفاوت زیادی داشته باشند اما
دقیقاً از یک نسل Video Engine استفاده کنند.

در چنین شرایطی توان Encode و Decode آن‌ها
تقریباً یکسان خواهد بود.

برعکس، گاهی اختلاف یک نسل Video Engine باعث
اضافه شدن قابلیت‌هایی مانند AV1 Encode،
Decode سخت‌افزاری AV1، HDR پیشرفته یا
پشتیبانی از رزولوشن‌های بالاتر می‌شود.

نسل‌های NVENC و NVDEC

انویدیا تقریباً در هر نسل معماری GPU، نسخه
جدیدی از NVENC و NVDEC معرفی کرده است.

روند تکامل NVENC و NVDEC
معماری GPU قابلیت شاخص تغییر مهم
Kepler اولین NVENC Encode سخت‌افزاری اولیه
Maxwell HEVC اولیه بهبود کیفیت Encode
Pascal HEVC 10-bit HDR و کیفیت بهتر
Turing کیفیت بسیار بالاتر بهبود Motion Estimation
Ampere AV1 Decode Decode نسل جدید
Ada Lovelace AV1 Encode جهش بزرگ در Streaming

نسل‌های AMD VCN

AMD از زمان معرفی Video Core Next، چندین نسل
از VCN را ارائه کرده که هر نسل پشتیبانی از
Codecهای بیشتری را فراهم کرده است.

تکامل Video Core Next
نسل ویژگی شاخص
VCN 1.x HEVC و VP9
VCN 2.x بهبود کیفیت Encode
VCN 3.x Decode پیشرفته‌تر
VCN 4.x AV1 Encode و Decode

نسل‌های Intel Media Engine

Quick Sync Video از نسل Sandy Bridge تاکنون
به‌طور مداوم توسعه یافته و در معماری‌های Xe
بخشی از Media Engine محسوب می‌شود.

تکامل موتور رسانه اینتل
نسل ویژگی شاخص
Quick Sync اولیه H.264
Skylake HEVC 10-bit
Tiger Lake AV1 Decode
Arc و Xe AV1 Encode

قابلیت‌های هر نسل

ویژگی‌هایی که با هر نسل تغییر می‌کنند
قابلیت توضیح
Codec H.264، HEVC، VP9، AV1 و …
Bit Depth 8-bit، 10-bit، 12-bit
Chroma 4:2:0، 4:2:2، 4:4:4
Resolution 4K، 8K و بالاتر
FPS نرخ فریم قابل Encode و Decode
HDR HDR10، HLG و سایر قابلیت‌ها
کیفیت Encode الگوریتم Motion و Quantization

نسل جدید همیشه فقط سریع‌تر نیست

پیشرفت نسل‌های جدید تنها به افزایش سرعت محدود
نمی‌شود.

کیفیت Encode، پشتیبانی از Codecهای جدید،
مصرف انرژی، تعداد Streamهای هم‌زمان و امکانات
پردازشی نیز معمولاً بهبود پیدا می‌کنند.

نقش VRAM در پردازش ویدئو

VRAM حافظه محلی GPU است و Frameهای Decodeشده،
Textureها، Cacheها، Bufferهای پردازشی،
داده‌های افکت و خروجی‌های موقت را نگهداری
می‌کند. ظرفیت VRAM به‌تنهایی سرعت GPU را
مشخص نمی‌کند، اما کمبود آن می‌تواند باعث
افت شدید عملکرد، افزایش انتقال داده و
ناپایداری Timeline شود.

VRAM چیست؟

VRAM مخفف
Video Random Access Memory
است و حافظه‌ای با پهنای باند بالا محسوب می‌شود
که GPU برای دسترسی سریع به داده‌های گرافیکی و
ویدئویی از آن استفاده می‌کند.

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

Frameهای ویدئویی پس از Decode معمولاً در VRAM
ذخیره می‌شوند تا Shaderها، واحدهای Compute،
موتور Encode یا Display Engine بتوانند بدون
انتقال غیرضروری به RAM از آن‌ها استفاده کنند.

مسیر داده ویدئویی در VRAM

چه داده‌هایی در VRAM نگهداری می‌شوند؟

مهم‌ترین داده‌های ویدئویی داخل VRAM
نوع داده کاربرد عامل افزایش مصرف
Decode Frame Buffer نگهداری Frameهای بازسازی‌شده Resolution، Bit Depth و Chroma
Reference Frames پیش‌بینی فریم‌های وابسته Codec، GOP و تعداد Reference
Processing Buffers افکت، Scaling و Color تعداد Pass و Layer
Textures تصویر، Overlay، LUT و Asset اندازه و تعداد Texture
Temporal Buffers Denoise، Optical Flow و AI تعداد Frameهای تحلیل‌شده
Encode Surfaces آماده‌سازی Frame برای Encoder تعداد Stream و Lookahead
Display Buffers Frame نهایی نمایشگر Resolution و تعداد نمایشگر
AI Model Data وزن‌ها و Tensorهای مدل اندازه مدل و Precision

اندازه Frame Buffer چگونه تعیین می‌شود؟

اندازه یک Frame خام به Resolution، Bit Depth،
Chroma Sampling و فرمت ذخیره‌سازی داخلی بستگی
دارد.

افزایش Resolution تنها تعداد پیکسل را بیشتر
نمی‌کند؛ بلکه تقریباً تمام Bufferهای وابسته
به آن Frame را نیز بزرگ‌تر می‌سازد.

عوامل اصلی تعیین اندازه Frame Buffer
عامل اثر
Resolution افزایش تعداد کل پیکسل‌ها
Bit Depth افزایش داده هر مؤلفه رنگ
Chroma Sampling تعیین مقدار اطلاعات رنگی ذخیره‌شده
Alpha Channel افزودن مؤلفه شفافیت
Internal Format امکان استفاده از Integer یا Float
Alignment ایجاد Padding برای دسترسی سریع‌تر

اثر Resolution بر مصرف VRAM

با دو برابر شدن عرض و ارتفاع تصویر، تعداد کل
پیکسل‌ها تقریباً چهار برابر می‌شود.

به همین دلیل عبور از 1080p به 4K می‌تواند
مصرف حافظه Frame Buffer و بسیاری از افکت‌های
وابسته را چند برابر کند.

مقایسه تعداد تقریبی پیکسل در Resolutionهای رایج
Resolution تعداد تقریبی پیکسل بار نسبی حافظه
1920×1080 حدود 2.1 میلیون مبنا
2560×1440 حدود 3.7 میلیون بیشتر
3840×2160 حدود 8.3 میلیون نزدیک به چهار برابر 1080p
7680×4320 حدود 33.2 میلیون نزدیک به چهار برابر 4K

اثر Bit Depth بر مصرف VRAM

ویدئوی ۱۰ یا ۱۲ بیت برای هر مؤلفه رنگ داده
بیشتری نسبت به ویدئوی ۸ بیت نگهداری می‌کند.

در بسیاری از Pipelineهای حرفه‌ای، فریم‌ها
برای جلوگیری از خطای محاسباتی به فرمت‌های
16-bit Integer یا 16-bit و 32-bit Float تبدیل
می‌شوند که مصرف VRAM را بیشتر می‌کند.

اثر فرمت پردازشی بر حافظه
فرمت کاربرد مصرف نسبی
8-bit Integer پخش و خروجی عمومی پایین
10-bit / 12-bit HDR و تدوین حرفه‌ای بیشتر
16-bit Integer پردازش داخلی دقیق‌تر زیاد
16-bit Float Color Grading و Compositing زیاد
32-bit Float VFX و پردازش بسیار دقیق بسیار زیاد

اثر Chroma Sampling بر VRAM

در 4:2:0 اطلاعات رنگ با وضوح کمتری نسبت به
روشنایی ذخیره می‌شود، اما در 4:4:4 تمام
مؤلفه‌های رنگی با وضوح کامل نگهداری می‌شوند.

بنابراین پروژه‌های 4:4:4، RGB و دارای Alpha
معمولاً حافظه بیشتری نسبت به ویدئوی معمولی
4:2:0 مصرف می‌کنند.

مصرف نسبی حافظه در ساختارهای رنگی
ساختار اطلاعات رنگ مصرف نسبی VRAM
4:2:0 کاهش‌یافته کمترین
4:2:2 بیشتر متوسط
4:4:4 کامل زیاد
RGBA RGB کامل همراه Alpha بسیار زیاد

تعداد Layerها و مصرف VRAM

در Timelineهای چندلایه، هر Track ویدئویی،
Adjustment Layer، Mask، Graphic یا Overlay
ممکن است Frame Buffer مستقلی ایجاد کند.

پیش از ترکیب نهایی، چندین Layer باید هم‌زمان
در حافظه باقی بمانند.

مصرف VRAM در پروژه‌های Multicam

در تدوین Multicam چند Stream باید هم‌زمان
Decode شوند و Frameهای آن‌ها برای Preview،
Switching یا ساخت Proxy در حافظه باقی بمانند.

تعداد دوربین‌ها، Resolution، Codec، Bit Depth
و افکت‌های هر زاویه، مصرف VRAM را تعیین می‌کنند.

عوامل افزایش مصرف VRAM در Multicam
عامل اثر
تعداد Camera Angle افزایش Frame Bufferهای هم‌زمان
4K یا 8K بزرگ‌ترشدن هر Buffer
HEVC یا AV1 افزایش Reference و Decode Surface
Color Correction مستقل ایجاد Buffer پردازشی برای هر زاویه
Preview چندگانه نگهداری هم‌زمان خروجی چند Stream

افکت‌های Temporal و مصرف حافظه

افکت‌های Temporal تنها Frame فعلی را بررسی
نمی‌کنند و به Frameهای قبلی یا بعدی نیز نیاز
دارند.

Noise Reduction زمانی، Optical Flow،
Stabilization و Frame Interpolation ممکن است
چندین Frame کامل را هم‌زمان در VRAM نگهداری
کنند.

نمونه افکت‌های وابسته به چند Frame
افکت داده موردنیاز فشار حافظه
Temporal Denoise چند Frame متوالی زیاد
Optical Flow Frameهای مرجع و Motion Data زیاد
Stabilization تحلیل حرکت چند Frame متوسط تا زیاد
Frame Interpolation Frame قبل، بعد و Flow Map بسیار زیاد
Motion Blur Sampleهای زمانی متعدد وابسته به کیفیت

مصرف VRAM در پردازش ویدئویی AI

پردازش AI علاوه بر Frameهای ورودی و خروجی،
وزن‌های مدل، Activationها، Tensorهای میانی و
Bufferهای موقت را نیز در VRAM نگهداری می‌کند.

افزایش Resolution، Batch Size، Precision مدل
و تعداد Frameهای هم‌زمان می‌تواند مصرف حافظه
را به‌سرعت افزایش دهد.

عوامل مصرف VRAM در مدل‌های ویدئویی AI
عامل اثر
Model Size نگهداری وزن‌های بیشتر
Input Resolution افزایش Tensorهای ورودی و میانی
Batch Size پردازش چند Frame به‌صورت هم‌زمان
Precision تفاوت میان FP32، FP16 و INT8
Temporal Context نگهداری چند Frame برای تحلیل زمانی

تفاوت ظرفیت VRAM و سرعت VRAM

ظرفیت VRAM مشخص می‌کند چه مقدار داده می‌تواند
هم‌زمان در حافظه GPU باقی بماند.

پهنای باند حافظه مشخص می‌کند این داده‌ها با چه
سرعتی میان GPU و VRAM منتقل شوند.

یک کارت ممکن است VRAM زیادی داشته باشد اما
پهنای باند آن برای پردازش سنگین محدود باشد؛
یا برعکس، حافظه سریعی داشته باشد اما ظرفیت آن
برای پروژه بزرگ کافی نباشد.

مقایسه ظرفیت و پهنای باند VRAM
معیار ظرفیت VRAM پهنای باند VRAM
واحد اندازه‌گیری GB GB/s
نقش مقدار داده قابل نگهداری سرعت انتقال داده
کمبود Eviction و انتقال به RAM انتظار واحدهای پردازشی
کاربرد حساس 8K، AI و پروژه چندلایه Filtering، Color و Frameهای بزرگ

هنگام پرشدن VRAM چه اتفاقی می‌افتد؟

وقتی داده‌های پروژه از ظرفیت VRAM بیشتر شوند،
نرم‌افزار یا درایور ممکن است بخشی از Bufferها
را به RAM سیستم منتقل کند یا آن‌ها را دوباره
ایجاد نماید.

این فرآیند باعث افزایش Latency و استفاده از
PCI Express می‌شود و می‌تواند Timeline را
ناپایدار کند.

نشانه‌های کمبود VRAM

علائم رایج کمبود حافظه گرافیکی
نشانه علت احتمالی
Stutter ناگهانی Timeline انتقال Buffer میان VRAM و RAM
افت شدید سرعت با فعال‌شدن افکت ایجاد Bufferهای موقت بزرگ
خطای Out of Memory نبود فضای کافی برای Allocation جدید
کرش نرم‌افزار یا درایور شکست مدیریت حافظه یا Allocation
کاهش ناگهانی Resolution Preview تلاش نرم‌افزار برای کاهش مصرف حافظه
افزایش استفاده از RAM Shared یا Evicted GPU Memory

Shared GPU Memory چیست؟

سیستم‌عامل ممکن است بخشی از RAM را به‌عنوان
Shared GPU Memory در اختیار GPU قرار دهد.

این حافظه جایگزین واقعی VRAM نیست؛ زیرا دسترسی
به آن معمولاً تأخیر بیشتر و پهنای باند کمتری
دارد.

در گرافیک مجتمع، RAM سیستم حافظه اصلی GPU است،
اما در کارت مجزا Shared Memory بیشتر نقش فضای
اضطراری را دارد.

تفاوت VRAM و Shared GPU Memory
معیار VRAM اختصاصی Shared Memory
محل روی کارت گرافیک RAM سیستم
پهنای باند معمولاً بیشتر کمتر یا مشترک با CPU
Latency کمتر بیشتر
کاربرد فضای کاری اصلی GPU حافظه مجتمع یا فضای پشتیبان

Unified Memory در GPUهای مجتمع

در معماری‌های مجتمع، CPU و GPU ممکن است از
حافظه فیزیکی مشترک استفاده کنند.

این طراحی می‌تواند انتقال جداگانه میان RAM و
VRAM را کاهش دهد، اما CPU و GPU برای ظرفیت و
پهنای باند یک حافظه مشترک رقابت می‌کنند.

مزایا و محدودیت‌های حافظه یکپارچه
ویژگی نتیجه
فضای آدرس مشترک کاهش بعضی عملیات Copy
ظرفیت مشترک امکان استفاده انعطاف‌پذیرتر از RAM
پهنای باند مشترک رقابت CPU و GPU برای حافظه
نبود VRAM مجزا وابستگی بیشتر به سرعت RAM

چه عواملی VRAM موردنیاز پروژه را تعیین می‌کنند؟

عوامل تعیین‌کننده نیاز به VRAM
عامل مصرف VRAM
1080p با افکت ساده کم تا متوسط
4K ده‌بیتی متوسط تا زیاد
8K بسیار زیاد
Multicam وابسته به تعداد Stream
Fusion و VFX زیاد تا بسیار زیاد
Temporal Noise Reduction زیاد
AI Upscaling وابسته به مدل و Resolution
RAW Processing زیاد

روش‌های کاهش مصرف VRAM

روش‌های مدیریت بهتر حافظه گرافیکی
روش نتیجه
کاهش Preview Resolution کوچک‌شدن Frame Bufferهای Timeline
استفاده از Proxy کاهش Resolution و پیچیدگی Decode
Render Cache کاهش پردازش زنده بعضی افکت‌ها
کاهش Layerهای فعال آزادشدن Bufferهای Compositing
غیرفعال‌کردن افکت سنگین کاهش Bufferهای موقت و Temporal
کاهش Batch یا AI Model کاهش Tensor و وزن‌های فعال
بستن برنامه‌های GPUمحور آزادشدن VRAM رزروشده

چگونه مصرف VRAM را بررسی کنیم؟

ابزارهای مانیتورینگ می‌توانند مقدار Dedicated
GPU Memory، Shared GPU Memory، Memory
Bandwidth و فعالیت موتورهای مختلف GPU را
نمایش دهند.

تنها رسیدن مصرف VRAM به عدد بالا الزاماً مشکل
نیست؛ بعضی نرم‌افزارها حافظه آزاد را برای Cache
رزرو می‌کنند.

نشانه مهم‌تر، افت عملکرد هم‌زمان با افزایش
Shared Memory، انتقال PCI Express یا خطای
Allocation است.

پهنای باند حافظه (Memory Bandwidth)

اگر VRAM را انبار داده‌های GPU در نظر بگیریم،
Memory Bandwidth سرعت جابه‌جایی داده میان GPU و
این انبار است. بسیاری از پروژه‌های ویدئویی،
مخصوصاً در رزولوشن‌های بالا، نه به دلیل کمبود
قدرت پردازشی GPU بلکه به علت محدود بودن پهنای
باند حافظه کند می‌شوند.

Memory Bandwidth چیست؟

Memory Bandwidth مقدار داده‌ای است که GPU در
هر ثانیه می‌تواند میان هسته‌های پردازشی و
حافظه گرافیکی منتقل کند.

این مقدار معمولاً برحسب
GB/s
بیان می‌شود.

مسیر انتقال داده

چرا پهنای باند اهمیت دارد؟

هر افکت، هر Shader، هر عملیات AI و حتی Decode
و Encode برای پردازش باید داده را از VRAM
بخوانند و نتیجه را دوباره در VRAM بنویسند.

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

چه بخش‌هایی از پهنای باند استفاده می‌کنند؟

مصرف‌کنندگان اصلی Memory Bandwidth
بخش نوع دسترسی شدت مصرف
Shader خواندن و نوشتن Frame زیاد
Compute دسترسی تصادفی زیاد
AI Tensor و Buffer بسیار زیاد
Decode Frame Buffer متوسط
Encode Encode Surface متوسط
Display Engine Scanout کم تا متوسط

چه عواملی پهنای باند را تعیین می‌کنند؟

عوامل مؤثر بر Memory Bandwidth
عامل اثر
Memory Clock افزایش نرخ انتقال داده
Bus Width افزایش حجم داده در هر سیکل
نوع حافظه GDDR6، GDDR6X، HBM و …
تعداد کانال حافظه افزایش مسیرهای انتقال
Compression کاهش نیاز واقعی به انتقال

Bus Width چیست؟

Bus Width تعداد بیت‌هایی است که در هر سیکل
ساعت میان GPU و حافظه منتقل می‌شود.

هرچه Bus Width بیشتر باشد، در صورت ثابت بودن
سرعت حافظه، پهنای باند نیز افزایش پیدا می‌کند.

نمونه Bus Widthهای رایج
Bus Width کاربرد معمول
64-bit کارت‌های اقتصادی
128-bit رده میان‌رده
192-bit میان‌رده قدرتمند
256-bit حرفه‌ای
320-bit رده بالا
384-bit پرچمدار

نوع حافظه و اثر آن بر پهنای باند

مقایسه فناوری‌های حافظه
نوع ویژگی کاربرد
GDDR5 نسل قدیمی کارت‌های قدیمی
GDDR6 پهنای باند بالا اکثر GPUهای امروزی
GDDR6X نرخ انتقال بسیار بالا کارت‌های پرچمدار
HBM پهنای باند بسیار زیاد HPC و AI

گلوگاه‌های ناشی از پهنای باند کم

اثر کمبود Memory Bandwidth
وضعیت نتیجه
4K و 8K کاهش سرعت افکت‌ها
AI Processing انتظار Tensor Core برای داده
Color Grading افت FPS Preview
Temporal Effects افزایش زمان پردازش
Multicam Stutter و Lag
Fusion / VFX کند شدن Rendering

ظرفیت حافظه یا پهنای باند؟

تفاوت دو مفهوم مهم حافظه
ویژگی ظرفیت پهنای باند
واحد GB GB/s
بیانگر حجم داده سرعت انتقال
کمبود Out of Memory Memory Bottleneck
اثر روی پروژه اندازه پروژه سرعت پردازش

معماری Memory Controller و Memory Bus

داشتن VRAM سریع به‌تنهایی کافی نیست. GPU باید
بتواند داده‌ها را به‌درستی میان هسته‌های
پردازشی و تراشه‌های حافظه هدایت کند. این وظیفه
بر عهده Memory Controller و Memory Bus است.
این دو بخش تعیین می‌کنند داده‌ها با چه سرعت،
چه ترتیبی و از چه مسیری میان GPU و VRAM جابه‌جا
شوند.

Memory Controller چیست؟

Memory Controller واحدی در داخل GPU است که
تمام عملیات خواندن و نوشتن حافظه را مدیریت
می‌کند.

این بخش درخواست‌های Shader، Compute، Video
Engine، Display Engine و سایر واحدها را
دریافت کرده و آن‌ها را به دستورات قابل اجرا
برای تراشه‌های حافظه تبدیل می‌کند.

مسیر انتقال داده

وظایف اصلی Memory Controller

مسئولیت‌های Memory Controller
وظیفه توضیح
Memory Scheduling زمان‌بندی درخواست‌ها
Read / Write Control کنترل عملیات خواندن و نوشتن
Address Translation تبدیل آدرس حافظه
Channel Distribution تقسیم بار میان کانال‌ها
Error Handling مدیریت خطاهای حافظه
Priority Control اولویت‌بندی درخواست‌ها

Memory Channel چیست؟

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

افزایش تعداد کانال‌ها باعث افزایش پهنای باند
کل سیستم حافظه می‌شود.

Bus Width چگونه تشکیل می‌شود؟

هر کانال حافظه معمولاً عرض ثابتی دارد. مجموع
عرض تمام کانال‌ها Bus Width نهایی GPU را
تشکیل می‌دهد.

نمونه تشکیل Bus Width
تعداد کانال عرض هر کانال Bus Width
4 32-bit 128-bit
6 32-bit 192-bit
8 32-bit 256-bit
10 32-bit 320-bit
12 32-bit 384-bit

جریان درخواست‌های حافظه

درخواست هم‌زمان چند واحد

در یک GPU مدرن تنها Shaderها از حافظه استفاده
نمی‌کنند.

Decode Engine، Encode Engine، Display Engine،
AI Accelerator و Copy Engine نیز هم‌زمان
درخواست خواندن یا نوشتن حافظه ارسال می‌کنند.

نمونه درخواست‌های هم‌زمان
واحد نوع درخواست
Shader Texture Read
Compute Random Access
Decode Frame Buffer Write
Encode Surface Read
Display Scanout Read
Copy Engine Buffer Copy

زمان‌بندی دسترسی به حافظه

اگر همه واحدها هم‌زمان بخواهند به یک بخش از
حافظه دسترسی داشته باشند، Memory Controller
باید درخواست‌ها را زمان‌بندی کند.

هدف این زمان‌بندی کاهش انتظار، افزایش Throughput
و جلوگیری از بلااستفاده ماندن واحدهای پردازشی
است.

Memory Contention چیست؟

وقتی چند واحد سخت‌افزاری هم‌زمان به یک مسیر
حافظه نیاز داشته باشند، رقابت برای دسترسی
ایجاد می‌شود.

این وضعیت Memory Contention نام دارد و می‌تواند
باعث افزایش Latency و کاهش کارایی شود.

چرا دو کارت با VRAM یکسان عملکرد متفاوتی دارند؟

ظرفیت حافظه تنها یکی از ویژگی‌های سیستم حافظه
است.

عوامل ایجاد تفاوت عملکرد
عامل اثر
Bus Width تفاوت پهنای باند
Memory Clock سرعت انتقال
نوع حافظه GDDR6 یا GDDR6X
Controller Design کارایی زمان‌بندی
Cache کاهش نیاز به VRAM
Compression کاهش انتقال واقعی

سلسله‌مراتب Cache در GPU

GPU برای هر عملیات نمی‌تواند مستقیماً به VRAM
مراجعه کند؛ زیرا دسترسی به حافظه گرافیکی نسبت
به Cache داخلی تأخیر بیشتری دارد و پهنای باند
بیشتری مصرف می‌کند. به همین دلیل، GPUهای مدرن
از چند سطح Cache برای نگهداری موقت داده‌های
پرکاربرد استفاده می‌کنند.

Cache در GPU چیست؟

Cache حافظه‌ای کوچک‌تر و سریع‌تر از VRAM است
که نزدیک واحدهای پردازشی قرار می‌گیرد.

داده‌هایی که احتمال استفاده دوباره از آن‌ها
زیاد است، به‌صورت موقت داخل Cache نگهداری
می‌شوند تا Shader، Compute Unit یا سایر
بخش‌های GPU مجبور نباشند هر بار به حافظه
اصلی مراجعه کنند.

مسیر دسترسی داده از هسته تا VRAM

نام و ترتیب دقیق Cacheها در معماری‌های مختلف
یکسان نیست، اما هدف کلی آن‌ها کاهش دسترسی
مستقیم به VRAM است.

سطوح اصلی Cache در GPU

نمای کلی سلسله‌مراتب Cache
سطح محل تقریبی سرعت ظرفیت
Register داخل واحد پردازشی بسیار زیاد بسیار کم
L0 بسیار نزدیک به هسته بسیار زیاد کم
L1 داخل یا نزدیک هر Cluster زیاد کم تا متوسط
L2 مشترک میان بخش‌های بزرگ GPU کمتر از L1 بیشتر
Last-Level Cache نزدیک Memory Controller بیشتر از VRAM وابسته به معماری
VRAM حافظه خارجی GPU کمتر از Cache بسیار بیشتر

Register File

Registerها نزدیک‌ترین فضای ذخیره‌سازی به
واحدهای محاسباتی هستند و داده‌های فعال هر
Thread یا Wave را نگهداری می‌کنند.

متغیرهای موقت، مختصات پیکسل، ضرایب محاسباتی
و نتایج میانی Shader ممکن است داخل Register
باقی بمانند.

اگر مصرف Register یک Kernel بیش‌ازحد بالا
باشد، تعداد Threadهای قابل اجرای هم‌زمان کاهش
می‌یابد و Occupancy افت می‌کند.

ویژگی‌های Register File
ویژگی نتیجه
Latency بسیار کم دسترسی سریع واحد محاسباتی
ظرفیت محدود محدودیت تعداد داده فعال
اختصاص به Thread نگهداری متغیرهای محلی
مصرف زیاد کاهش Occupancy

L0 Cache

در بعضی معماری‌ها، سطحی بسیار کوچک و نزدیک
به واحدهای اجرایی با عنوان L0 Cache وجود
دارد.

این Cache ممکن است برای Instruction، داده،
Texture یا عملیات خاص داخلی استفاده شود.

وجود و نام L0 در همه GPUها یکسان نیست و باید
بر اساس معماری دقیق بررسی شود.

L1 Cache

L1 Cache معمولاً نزدیک مجموعه‌ای از Shader
Coreها یا Compute Unitها قرار دارد و داده‌های
موردنیاز آن مجموعه را نگهداری می‌کند.

در بعضی معماری‌ها، بخشی از L1 با Shared
Memory یا Local Data Store ارتباط نزدیک دارد
یا منابع آن‌ها به‌صورت مشترک مدیریت می‌شود.

کاربردهای رایج L1 Cache
داده کاربرد
Pixel Data فیلترهای تصویری و Shader
Texture Samples Sampling و Scaling
Intermediate Results نتایج محاسبات میانی
Neighboring Data Blur، Sharpen و Denoise

L2 Cache

L2 Cache معمولاً میان بخش‌های بزرگ GPU مشترک
است و آخرین سطح Cache پیش از Memory Controller
محسوب می‌شود.

Shaderها، Compute Unitها، Copy Engine و برخی
واحدهای دیگر ممکن است از طریق L2 به داده‌های
مشترک دسترسی پیدا کنند.

افزایش ظرفیت L2 می‌تواند تعداد مراجعه‌های
مستقیم به VRAM را کاهش دهد و پهنای باند مؤثر
سیستم حافظه را بهتر کند.

Cache Hit و Cache Miss

اگر داده موردنیاز داخل Cache پیدا شود،
Cache Hit رخ می‌دهد.

اگر داده در Cache وجود نداشته باشد، GPU باید
آن را از سطح پایین‌تر یا VRAM دریافت کند که
به آن Cache Miss گفته می‌شود.

تفاوت Cache Hit و Cache Miss
وضعیت منبع داده نتیجه
Cache Hit Cache داخلی Latency کمتر و مصرف پهنای باند پایین‌تر
Cache Miss Cache پایین‌تر یا VRAM انتظار بیشتر و ترافیک حافظه بالاتر

Locality در پردازش ویدئو

عملکرد Cache به الگوی دسترسی داده وابسته است.
اگر Shader چند بار به داده‌های نزدیک یا مشابه
مراجعه کند، احتمال Cache Hit افزایش می‌یابد.

Spatial Locality به استفاده از داده‌های نزدیک
به یکدیگر و Temporal Locality به استفاده دوباره
از یک داده در فاصله زمانی کوتاه اشاره دارد.

انواع Locality در پردازش تصویر
نوع مثال ویدئویی اثر
Spatial Locality خواندن پیکسل‌های مجاور در Blur استفاده بهتر از Cache Line
Temporal Locality استفاده مجدد از LUT یا Texture افزایش Cache Hit
Poor Locality دسترسی پراکنده به Frame بزرگ افزایش Cache Miss

Texture Cache

Texture Cache برای الگوهای دسترسی مربوط به
Sampling تصویر و Texture بهینه شده است.

Scaling، Rotation، Warp، LUT و بسیاری از
افکت‌های تصویری از Texture Sampling استفاده
می‌کنند.

Texture Cache می‌تواند داده‌های پیکسل نزدیک
را نگهداری کند تا عملیات Interpolation با
دسترسی کمتر به VRAM انجام شود.

کاربردهای Texture Cache در ویدئو
عملیات نوع دسترسی
Bilinear Scaling خواندن چند پیکسل مجاور
Bicubic Scaling Sampling گسترده‌تر همسایگی
LUT مراجعه مکرر به جدول رنگ
Warp و Stabilization Sampling مختصات غیرخطی
Chroma Upsampling بازسازی مؤلفه‌های رنگ

Constant Cache

Constant Cache برای داده‌های کوچک و ثابتی
مناسب است که تعداد زیادی Thread به مقدار
یکسان آن‌ها نیاز دارند.

ضرایب Color Matrix، پارامترهای افکت، مقدار
Gamma یا تنظیمات Kernel می‌توانند در چنین
حافظه‌ای نگهداری شوند.

Shared Memory و Local Data Store

Shared Memory در CUDA یا Local Data Store در
برخی معماری‌ها، حافظه‌ای سریع و قابل مدیریت
توسط برنامه است که میان Threadهای یک گروه
مشترک می‌شود.

Shader می‌تواند بخشی از Frame را داخل این
حافظه بارگذاری کند و چندین عملیات را بدون
مراجعه دوباره به VRAM انجام دهد.

اثر Cache بر Filterهای ویدئویی

رابطه نوع Filter با الگوی استفاده از Cache
Filter الگوی دسترسی اهمیت Cache
Blur پیکسل‌های مجاور بسیار زیاد
Sharpen Kernel همسایگی زیاد
Color LUT جدول کوچک و پرتکرار زیاد
Temporal Denoise چند Frame بزرگ محدودتر به دلیل حجم داده
AI Upscaling وزن مدل و Tensor بسیار مهم
Random Particle Effect دسترسی پراکنده Cache Hit کمتر

AMD Infinity Cache

Infinity Cache نام تجاری AMD برای یک Cache
بزرگ در سطح بالای سلسله‌مراتب حافظه برخی
GPUهای Radeon است.

هدف این Cache کاهش تعداد دسترسی‌های مستقیم
به VRAM و افزایش پهنای باند مؤثر است.

میزان اثرگذاری آن به ظرفیت Cache، Resolution،
نوع بار پردازشی و الگوی دسترسی داده بستگی دارد.

افزایش ظرفیت L2 در GPUهای جدید

برخی معماری‌های جدید ظرفیت L2 Cache را به شکل
محسوسی افزایش داده‌اند.

L2 بزرگ‌تر می‌تواند در بعضی بارهای کاری تعداد
مراجعه به VRAM را کاهش دهد، اما نتیجه نهایی
به نوع داده و میزان Locality وابسته است.

مزایا و محدودیت‌های L2 بزرگ‌تر
اثر نتیجه احتمالی
Cache Hit بیشتر کاهش دسترسی به VRAM
ترافیک کمتر حافظه آزادشدن پهنای باند برای واحدهای دیگر
Latency پایین‌تر تحویل سریع‌تر داده‌های تکراری
Dataset بزرگ‌تر از Cache ادامه وابستگی به VRAM
دسترسی پراکنده سود محدودتر از Cache

Cacheهای داخلی Video Engine

موتورهای Decode و Encode ممکن است Bufferها،
SRAMها یا Cacheهای داخلی مخصوص خود داشته
باشند.

این فضاها برای نگهداری داده‌های موقت Codec،
Reference Data، Context و نتایج میانی استفاده
می‌شوند.

جزئیات این Cacheها معمولاً به‌صورت کامل در
مشخصات عمومی GPU منتشر نمی‌شود و میان نسل‌ها
تفاوت دارد.

داده‌های احتمالی داخل حافظه محلی Video Engine
داده کاربرد
Codec Context نگهداری وضعیت Decoder یا Encoder
Motion Data پردازش بردارهای حرکت
Transform Data نتایج میانی Transform و Quantization
Bitstream Buffer نگهداری موقت داده فشرده
Reference Metadata مدیریت Frameهای مرجع

Cache Coherency

وقتی چند واحد GPU یا CPU و GPU به یک Buffer
مشترک دسترسی دارند، باید اطمینان حاصل شود که
همه واحدها جدیدترین نسخه داده را مشاهده
می‌کنند.

این هماهنگی Cache Coherency نام دارد و ممکن
است با Barrier، Fence، Flush، Invalidate یا
سازوکارهای سخت‌افزاری انجام شود.

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

Flush و Invalidate

عملیات مدیریت Cache
عملیات وظیفه
Flush نوشتن داده تغییرکرده Cache در سطح پایین‌تر
Invalidate بی‌اعتبارکردن نسخه قدیمی داده در Cache
Barrier کنترل ترتیب مشاهده عملیات حافظه
Fence اعلام تکمیل عملیات یک Queue یا Engine

مقایسه Cache و VRAM

تفاوت Cache داخلی و حافظه گرافیکی
معیار Cache VRAM
ظرفیت کم زیاد
سرعت بسیار زیاد کمتر
Latency پایین بالاتر
وظیفه نگهداری موقت داده پرتکرار نگهداری اصلی Frame و Asset
مدیریت بیشتر توسط سخت‌افزار یا Kernel توسط درایور و نرم‌افزار
جایگزینی یکدیگر نمی‌تواند جای VRAM را بگیرد نمی‌تواند سرعت Cache را فراهم کند

گلوگاه‌های مرتبط با Cache

مشکلات رایج در سلسله‌مراتب Cache
مشکل نشانه پیامد
Cache Miss زیاد افزایش ترافیک VRAM افت عملکرد
Dataset بزرگ خارج‌شدن مکرر داده از Cache کاهش بهره‌وری Cache
دسترسی پراکنده Locality ضعیف استفاده ناکامل از Cache Line
Synchronization زیاد Flush و Barrier مکرر توقف Pipeline
Register Pressure Spill به حافظه پایین‌تر افزایش Latency
Cache Thrashing جایگزینی سریع و مداوم داده‌ها Cache Hit پایین

بهینه‌سازی استفاده از Cache

روش‌های افزایش بهره‌وری Cache در پردازش ویدئو
روش نتیجه
Tile-Based Processing پردازش بخش کوچک‌تر Frame داخل Cache
Coalesced Access ترکیب دسترسی Threadهای مجاور
استفاده از Shared Memory کاهش خواندن تکراری از VRAM
کاهش Passهای غیرضروری کاهش خواندن و نوشتن Frame
ادغام Filterها اجرای چند عملیات در یک Kernel
Buffer Reuse کاهش Allocation و جابه‌جایی داده
حفظ Zero-Copy جلوگیری از خروج Frame از حافظه GPU

PCI Express و انتقال داده میان CPU و GPU

در کارت‌های گرافیک مجزا، RAM سیستم و VRAM دو
فضای حافظه مستقل هستند. داده‌های ویدئویی،
Textureها، Frame Bufferها و نتایج پردازش باید
در صورت نیاز از طریق PCI Express میان این دو
فضا جابه‌جا شوند. اگر این انتقال‌ها به‌درستی
مدیریت نشوند، حتی یک GPU قدرتمند نیز ممکن است
به دلیل انتظار برای داده، عملکرد ضعیفی داشته
باشد.

PCI Express چیست؟

PCI Express یا PCIe رابط ارتباطی پرسرعت میان
CPU، چیپ‌ست، کارت گرافیک، کارت Capture،
تجهیزات ذخیره‌سازی و سایر قطعات توسعه است.

در یک سیستم دارای GPU مجزا، بسیاری از داده‌ها
از RAM سیستم از طریق PCIe به VRAM منتقل
می‌شوند و در صورت نیاز، نتایج نیز از GPU به
حافظه سیستم بازگردانده می‌شوند.

مدل حافظه در GPU مجزا

در کارت گرافیک مجزا، CPU معمولاً به RAM سیستم
دسترسی مستقیم دارد و GPU نیز داده‌های فعال خود
را در VRAM نگهداری می‌کند.

هر زمان داده‌ای در محل مناسب قرار نداشته باشد،
باید میان این دو حافظه منتقل شود.

Upload و Download داده در GPU

انتقال داده از RAM سیستم به VRAM معمولاً
Upload و انتقال از VRAM به RAM معمولاً
Download یا Readback نامیده می‌شود.

مسیرهای اصلی انتقال میان CPU و GPU
عملیات مسیر نمونه کاربرد
Upload RAM به VRAM ارسال Frame، Texture یا Model
Download VRAM به RAM ذخیره خروجی یا پردازش CPU
GPU-to-GPU Copy VRAM به VRAM انتقال میان Bufferها یا GPUها
Device Readback GPU به CPU Screenshot، Analysis یا Export

Lane در PCI Express چیست؟

هر اتصال PCIe از یک یا چند Lane تشکیل می‌شود.
هر Lane یک مسیر ارسال و یک مسیر دریافت مستقل
دارد.

کارت‌های گرافیک معمولاً از اتصال‌هایی مانند
x16، x8 یا در بعضی مدل‌ها x4 استفاده می‌کنند.

تعداد Laneهای رایج PCIe
اتصال تعداد Lane کاربرد رایج
PCIe x1 1 کارت‌های جانبی سبک
PCIe x4 4 SSD و بعضی GPUهای اقتصادی
PCIe x8 8 GPU، Capture و Accelerator
PCIe x16 16 کارت گرافیک اصلی

نسل‌های PCI Express

در هر نسل PCIe، نرخ انتقال هر Lane افزایش
پیدا می‌کند. بنابراین یک اتصال x8 نسل جدید
ممکن است پهنای باندی مشابه یا بیشتر از x16
یک نسل قدیمی داشته باشد.

روند کلی افزایش سرعت PCI Express
نسل وضعیت نسبی پهنای باند کاربرد رایج
PCIe 3.0 مبنای سیستم‌های قدیمی‌تر GPU و SSD نسل قبل
PCIe 4.0 تقریباً دو برابر نسل قبل سیستم‌های مدرن
PCIe 5.0 تقریباً دو برابر PCIe 4.0 Workstation و Storage سریع
PCIe 6.0 و جدیدتر پهنای باند بسیار بالاتر Server، AI و زیرساخت حرفه‌ای

تفاوت پهنای باند PCIe و VRAM

پهنای باند داخلی میان GPU و VRAM معمولاً بسیار
بیشتر از پهنای باند PCIe است.

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

مقایسه کاربرد PCIe و Memory Bus
مسیر وظیفه سرعت نسبی
PCI Express ارتباط CPU، RAM و GPU کمتر
Memory Bus ارتباط GPU با VRAM بسیار بیشتر
Cache Fabric ارتباط داخلی Cacheها و Coreها بسیار سریع

DMA چیست؟

DMA مخفف
Direct Memory Access
است و به یک دستگاه اجازه می‌دهد بدون دخالت
مستقیم CPU در انتقال تک‌تک داده‌ها، اطلاعات
را میان حافظه‌ها جابه‌جا کند.

GPU و کارت‌های Capture می‌توانند با استفاده
از DMA داده را به Bufferهای حافظه منتقل کنند
و CPU تنها عملیات را تنظیم و کنترل کند.

نقش Copy Engine در انتقال داده

Copy Engine واحدی در GPU است که عملیات انتقال
Buffer را مستقل از Shader Coreها انجام می‌دهد.

این واحد می‌تواند هم‌زمان با Compute، Decode
یا Encode فعالیت کند؛ البته همه این عملیات
همچنان برای دسترسی به حافظه و PCIe رقابت
می‌کنند.

وظایف متداول Copy Engine
عملیات مسیر
Host-to-Device RAM به VRAM
Device-to-Host VRAM به RAM
Device-to-Device VRAM به VRAM
Peer-to-Peer GPU به GPU

Pinned Memory چیست؟

Pinned یا Page-Locked Memory بخشی از RAM است
که سیستم‌عامل آن را هنگام عملیات جابه‌جا
نمی‌کند.

این ویژگی به DMA و GPU اجازه می‌دهد انتقال
داده را با مسیر پایدارتر و معمولاً سریع‌تر
انجام دهند.

استفاده بیش‌ازحد از Pinned Memory می‌تواند
حافظه در دسترس سیستم‌عامل و برنامه‌های دیگر
را کاهش دهد.

تفاوت حافظه معمولی و Pinned
معیار Pageable Memory Pinned Memory
جابه‌جایی توسط سیستم‌عامل امکان‌پذیر محدود یا غیرفعال
مناسب DMA نیازمند مرحله اضافی احتمالی مناسب‌تر
سرعت انتقال GPU معمولاً کمتر معمولاً بیشتر
هزینه تخصیص کمتر بیشتر

Staging Buffer چیست؟

گاهی داده نمی‌تواند مستقیماً از حافظه برنامه
به VRAM منتقل شود و ابتدا در یک Buffer میانی
قرار می‌گیرد.

این Buffer میانی Staging Buffer نام دارد و
برای تطبیق فرمت حافظه، Alignment یا نوع دسترسی
استفاده می‌شود.

وجود Staging Buffer ممکن است یک کپی اضافی
ایجاد کند، اما در بسیاری از APIها برای انتقال
ایمن و سازگار ضروری است.

انتقال Synchronous

در انتقال Synchronous، برنامه تا پایان عملیات
کپی منتظر می‌ماند.

این روش ساده است، اما می‌تواند CPU یا GPU را
بدون انجام کار مفید متوقف نگه دارد.

انتقال Asynchronous

در انتقال Asynchronous، Copy Engine داده را
جابه‌جا می‌کند و CPU یا سایر موتورهای GPU
می‌توانند هم‌زمان کار دیگری انجام دهند.

این روش برای Pipelineهای Real-Time و چند
Stream بسیار مهم است.

Double Buffering و Pipeline انتقال

با استفاده از چند Buffer می‌توان هم‌زمان یک
Frame را منتقل، Frame قبلی را پردازش و Frame
بعدی را آماده کرد.

این روش باعث کاهش زمان انتظار میان مراحل
Pipeline می‌شود.

نقش Bufferهای موازی در Pipeline
Buffer وضعیت
Buffer A در حال پردازش توسط GPU
Buffer B در حال انتقال به GPU
Buffer C در حال آماده‌سازی توسط CPU

Zero-Copy چیست؟

Zero-Copy به معماری‌ای گفته می‌شود که در آن
داده بدون ایجاد نسخه‌های غیرضروری میان مراحل
مختلف Pipeline استفاده می‌شود.

Zero-Copy الزاماً به معنی نبود کامل هیچ انتقال
فیزیکی نیست؛ بلکه هدف آن حذف Copyهای اضافی و
نگهداری داده در مناسب‌ترین حافظه است.

Zero-Copy در پردازش ویدئو

در یک Pipeline بهینه، Decoder فریم را مستقیماً
در سطحی از حافظه GPU تولید می‌کند که Shader،
Compute و Encoder بتوانند همان Buffer را
استفاده کنند.

Pipeline دارای Copyهای غیرضروری

اگر Decode روی CPU، افکت روی GPU و Encode
دوباره روی CPU انجام شود، Frame ممکن است
چند بار میان RAM و VRAM جابه‌جا شود.

این مسیر Latency، مصرف حافظه و ترافیک PCIe
بیشتری ایجاد می‌کند.

Interop میان APIها

مراحل مختلف Pipeline ممکن است از APIهای
متفاوت مانند CUDA، OpenCL، Vulkan، Direct3D،
OpenGL، VA-API یا VideoToolbox استفاده کنند.

Interop اجازه می‌دهد یک Buffer یا Surface
بدون کپی کامل میان این APIها به اشتراک گذاشته
شود.

نمونه کاربرد Interoperability
مرحله اول مرحله دوم هدف
Hardware Decode CUDA Processing استفاده مستقیم از Decode Surface
Vulkan Render Video Encode Encode مستقیم Frame رندرشده
Direct3D Capture NVENC یا QSV ضبط صفحه با Copy کمتر
Camera Surface AI Processing پردازش زنده با Latency پایین

انتقال مستقیم دستگاه به GPU

در بعضی سامانه‌های حرفه‌ای، کارت شبکه،
تجهیزات ذخیره‌سازی یا کارت Capture می‌توانند
داده را با دخالت کمتر CPU مستقیماً به حافظه
قابل استفاده GPU منتقل کنند.

نام و قابلیت دقیق این فناوری میان سازندگان و
سیستم‌عامل‌ها متفاوت است، اما هدف مشترک کاهش
Copy، Latency و مصرف CPU است.

Resizable BAR چیست؟

در بعضی معماری‌های قدیمی، CPU تنها می‌توانست
بخش کوچکی از VRAM را در هر لحظه در فضای آدرس
خود مشاهده کند.

Resizable BAR اجازه می‌دهد CPU ناحیه بزرگ‌تری
از VRAM را آدرس‌دهی کند.

اثر این قابلیت بر پردازش ویدئو به نرم‌افزار،
الگوی انتقال داده و معماری سیستم وابسته است و
لزوماً در همه Workflowها افزایش عملکرد قابل
توجهی ایجاد نمی‌کند.

IOMMU و آدرس‌دهی دستگاه‌ها

IOMMU واحدی برای ترجمه و محافظت از آدرس‌های
حافظه مورد استفاده دستگاه‌های I/O است.

این بخش به سیستم‌عامل اجازه می‌دهد دسترسی DMA
دستگاه‌ها را کنترل و فضای حافظه مجازی مناسبی
برای آن‌ها ایجاد کند.

IOMMU در مجازی‌سازی، امنیت، Passthrough و
مدیریت حافظه میان چند دستگاه اهمیت دارد.

انتقال داده در GPU مجتمع

در GPU مجتمع، CPU و GPU معمولاً از RAM فیزیکی
مشترک استفاده می‌کنند.

این طراحی می‌تواند نیاز به انتقال جداگانه از
RAM به VRAM را کاهش دهد، اما همچنان ممکن است
تبدیل Layout، Synchronization یا Copy داخلی
میان Bufferها لازم باشد.

مقایسه مدل حافظه GPU مجزا و مجتمع
معیار GPU مجزا GPU مجتمع
حافظه اصلی GPU VRAM مستقل RAM مشترک
انتقال CPU به GPU معمولاً از طریق PCIe ممکن است بدون انتقال فیزیکی مجزا
پهنای باند معمولاً بالاتر در VRAM مشترک با CPU
ظرفیت حافظه محدود به VRAM کارت وابسته به RAM سیستم
رقابت حافظه کمتر با CPU بیشتر میان CPU و GPU

Latency انتقال داده

پهنای باند تنها معیار عملکرد انتقال نیست.
شروع هر عملیات Copy نیز هزینه زمانی دارد.

انتقال تعداد زیادی Buffer کوچک ممکن است حتی
با حجم کل پایین، به دلیل Overhead و
Synchronization کندتر از انتقال یک Buffer بزرگ
باشد.

عوامل مؤثر بر Latency انتقال
عامل اثر
اندازه Buffer Buffer کوچک‌تر معمولاً سربار نسبی بیشتری دارد
تعداد Transfer افزایش Command و Synchronization
نوع حافظه میزبان Pinned یا Pageable بودن
وضعیت PCIe نسل، Lane و اشتراک مسیر
Queue Synchronization انتظار میان Copy و Compute
NUMA Placement فاصله CPU و دستگاه در Workstation و Server

رقابت برای پهنای باند PCIe

ممکن است چند دستگاه یا چند موتور هم‌زمان از
مسیر PCIe استفاده کنند.

کارت Capture، SSD، GPU دوم و تجهیزات شبکه
می‌توانند برای Laneها یا مسیرهای مشترک چیپ‌ست
رقابت ایجاد کنند.

نشانه‌های گلوگاه انتقال CPU و GPU

علائم رایج محدودیت PCIe و Copy
نشانه علت احتمالی
GPU Utilization پایین انتظار GPU برای Frame ورودی
Copy Engine Utilization بالا انتقال مکرر RAM و VRAM
Preview ناپایدار Readback یا Upload بیش‌ازحد
کندی با فعال‌شدن CPU Filter خروج Frame از VRAM و بازگشت دوباره
Shared Memory زیاد کمبود VRAM و Paging
افت عملکرد در سیستم چند GPU انتقال Peer-to-Peer یا مسیر نامناسب
Latency بالای استریم کپی‌های متوالی میان مراحل

روش‌های بهینه‌سازی انتقال داده

راهکارهای کاهش هزینه انتقال CPU و GPU
روش نتیجه
Zero-Copy Pipeline حذف Copyهای میانی غیرضروری
Hardware Decode و Encode باقی‌ماندن Frame در GPU
API Interop اشتراک Surface میان مراحل
Asynchronous Copy هم‌پوشانی انتقال و پردازش
Pinned Memory افزایش کارایی DMA
Batch Transfer کاهش سربار Bufferهای کوچک
Buffer Reuse کاهش Allocation و Copy
نگهداری افکت‌ها روی یک Device جلوگیری از رفت‌وبرگشت CPU و GPU
بررسی Lane و نسل PCIe جلوگیری از لینک محدودشده

Pipeline پردازش در GPU

GPU مجموعه‌ای از واحدهای مستقل نیست که هرکدام
جداگانه کار کنند؛ بلکه بیشتر شبیه یک خط تولید
بزرگ است که داده در آن مرحله‌به‌مرحله حرکت
می‌کند. این زنجیره پردازش را Pipeline می‌نامند.

Pipeline چیست؟

Pipeline مجموعه‌ای از مراحل متوالی است که
هر مرحله وظیفه مشخصی را روی داده انجام می‌دهد.

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

نمای کلی Pipeline

مراحل اصلی Pipeline

مراحل رایج پردازش یک Frame
مرحله وظیفه خروجی
Decode تبدیل Bitstream به Frame Surface
Color Convert تبدیل فضای رنگ RGB / YUV
Compute اجرای افکت‌ها Frame جدید
AI Denoise، Upscale و… Frame بهبود یافته
Encode فشرده‌سازی خروجی Bitstream

اجرای هم‌زمان مراحل Pipeline

در GPU مدرن، مراحل مختلف می‌توانند به‌صورت
هم‌زمان روی Frameهای متفاوت اجرا شوند.

همگام‌سازی (Synchronization) در GPU

GPU ده‌ها یا حتی صدها واحد پردازشی دارد که
هم‌زمان روی داده‌های مختلف کار می‌کنند. برای
جلوگیری از خواندن داده ناقص، نوشتن هم‌زمان روی
یک Buffer یا اجرای نادرست مراحل Pipeline،
لازم است ترتیب اجرای عملیات کنترل شود. این
وظیفه را مکانیزم‌های Synchronization بر عهده
دارند.

Synchronization چیست؟

Synchronization مجموعه‌ای از مکانیزم‌ها برای
هماهنگ‌کردن ترتیب اجرای عملیات میان CPU،
موتورهای مختلف GPU و Threadهای پردازشی است.

هدف اصلی آن جلوگیری از استفاده از داده‌ای است
که هنوز تولید نشده یا هنوز در حافظه نوشته
نشده است.

چرا Synchronization لازم است؟

فرض کنید Decode هنوز در حال تولید Frame است،
اما Shader بخواهد همان Frame را پردازش کند.
اگر هماهنگی وجود نداشته باشد، Shader داده
ناقص یا نامعتبر دریافت خواهد کرد.

انواع همگام‌سازی

انواع Synchronization
نوع هدف مثال
CPU ↔ GPU هماهنگی پردازنده و GPU پایان Render
GPU ↔ GPU هماهنگی Engineها Decode → Compute
Thread هماهنگی Threadها Shared Memory
Memory ترتیب مشاهده داده Barrier

Fence

Fence شیئی برای اطلاع از پایان یک عملیات
پردازشی است.

CPU یا Queue دیگر می‌تواند منتظر بماند تا Fence
سیگنال پایان عملیات را دریافت کند.

Barrier

Barrier ترتیب دسترسی به حافظه را کنترل می‌کند.

قبل از اینکه مرحله بعدی داده را بخواند،
Barrier اطمینان حاصل می‌کند که تمام عملیات
نوشتن قبلی کامل شده‌اند.

کاربردهای Barrier
وضعیت نقش Barrier
Compute → Compute تکمیل نوشتن Buffer
Compute → Encode آماده بودن Frame
Copy → Shader پایان انتقال داده
Render → Display جلوگیری از نمایش Frame ناقص

Semaphore

Semaphore برای هماهنگی میان Queueها یا Engineهای
مختلف GPU استفاده می‌شود.

یک Queue می‌تواند تا زمان دریافت سیگنال از
Queue دیگر منتظر بماند.

Event

Event روشی برای ثبت وقوع یک عملیات است و
معمولاً جهت زمان‌سنجی، همگام‌سازی سبک یا
پروفایلینگ استفاده می‌شود.

بسیاری از APIها امکان اندازه‌گیری زمان اجرای
Kernelها را با استفاده از Event فراهم می‌کنند.

Memory Barrier

Memory Barrier تضمین می‌کند که تمام عملیات
خواندن و نوشتن حافظه پیش از ادامه اجرای
دستورهای بعدی کامل شده باشند.

این موضوع هنگام استفاده از Cache، Shared
Memory و Bufferهای مشترک اهمیت زیادی دارد.

Thread Barrier

در بسیاری از Shaderها، تمام Threadهای یک Work
Group باید قبل از ادامه اجرا به یک نقطه مشخص
برسند.

Thread Barrier این هماهنگی را برقرار می‌کند و
از استفاده زودهنگام از داده‌های Shared Memory
جلوگیری می‌کند.

Deadlock

اگر دو Queue یا دو Thread منتظر پایان کار
یکدیگر بمانند، هیچ‌کدام ادامه پیدا نمی‌کنند.

این وضعیت Deadlock نام دارد و یکی از مشکلات
مهم طراحی Pipelineهای موازی است.

هزینه Synchronization

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

اثر Synchronization بیش‌ازحد
علت نتیجه
Barrier زیاد توقف Kernelها
Fence مکرر انتظار CPU
Semaphore اضافی کاهش موازی‌سازی
Readback مداوم افزایش Latency

Command Buffer و Command Queue در GPU

GPU هیچ‌گاه مستقیماً کد برنامه را اجرا نمی‌کند.
نرم‌افزار ابتدا دستورات را به مجموعه‌ای از
فرمان‌ها تبدیل می‌کند. این فرمان‌ها داخل
Command Buffer ذخیره شده و سپس از طریق
Command Queue به GPU ارسال می‌شوند تا توسط
Scheduler اجرا شوند.

چرا Command Buffer وجود دارد؟

اگر CPU برای هر دستور مستقیماً با GPU ارتباط
برقرار کند، سربار بسیار زیادی ایجاد می‌شود.

به همین دلیل، تعداد زیادی دستور ابتدا در یک
Buffer جمع‌آوری شده و سپس به صورت یکجا به GPU
ارسال می‌شوند.

مسیر حرکت دستورات

Command Buffer چیست؟

Command Buffer مجموعه‌ای از فرمان‌هایی است
که CPU یا Driver برای GPU آماده می‌کند.

این فرمان‌ها می‌توانند شامل اجرای Shader،
انتقال Buffer، Decode، Encode، رسم تصویر،
تغییر وضعیت Pipeline یا عملیات دیگر باشند.

نمونه فرمان‌های داخل Command Buffer
فرمان وظیفه
Copy Buffer انتقال داده
Dispatch Compute اجرای Compute Shader
Draw اجرای Render
Decode اجرای Video Decoder
Encode اجرای Video Encoder
Pipeline Barrier همگام‌سازی

Command Queue چیست؟

Command Queue صفی است که Command Bufferهای
آماده اجرا در آن قرار می‌گیرند.

Scheduler GPU از این صف، فرمان‌ها را با توجه
به منابع سخت‌افزاری، اولویت و وابستگی‌ها
انتخاب و اجرا می‌کند.

تفاوت Command Buffer و Command Queue

مقایسه Buffer و Queue
ویژگی Command Buffer Command Queue
وظیفه نگهداری فرمان‌ها صف اجرای فرمان‌ها
ایجاد توسط CPU یا Driver Driver یا Runtime
قابلیت اجرا خیر بله
ترتیب مجموعه دستور ترتیب اجرای Bufferها

چند Command Queue

بسیاری از GPUهای مدرن چند Queue مستقل دارند
تا عملیات مختلف بتوانند به‌صورت هم‌زمان اجرا
شوند.

انواع Queue

Queueهای متداول GPU
Queue کاربرد
Graphics Render
Compute Compute Shader
Copy انتقال Buffer
Video Decode Decode Engine
Video Encode Encode Engine

Recording Command Buffer

برنامه ابتدا Command Buffer را ضبط یا Record
می‌کند.

در این مرحله هیچ پردازشی انجام نمی‌شود و فقط
فهرست دستورات آماده می‌شود.

Submit چیست؟

پس از آماده شدن Command Buffer، برنامه آن را
به Queue ارسال می‌کند. این عملیات Submit
نام دارد.

Submit به معنی اجرای فوری نیست؛ بلکه Buffer
وارد صف انتظار می‌شود.

ترتیب اجرای فرمان‌ها

Scheduler معمولاً ترتیب داخل هر Command Buffer
را حفظ می‌کند، اما ممکن است اجرای Queueهای
مختلف را بر اساس منابع موجود مدیریت کند.

وابستگی میان فرمان‌ها

بعضی فرمان‌ها تنها پس از پایان فرمان قبلی
قابل اجرا هستند.

Queue خالی

اگر Queue هیچ فرمانی نداشته باشد، بخشی از GPU
بیکار خواهد ماند.

طراحی مناسب Pipeline تلاش می‌کند Queueها تا
حد امکان پر باقی بمانند تا استفاده از GPU
افزایش یابد.

چرخه عمر Command Buffer

مزایای Command Buffer

مزایای استفاده از Command Buffer
مزیت نتیجه
کاهش سربار CPU ارسال گروهی فرمان‌ها
موازی‌سازی بهتر آماده‌سازی هم‌زمان فرمان‌ها
مدیریت وابستگی‌ها اجرای صحیح Pipeline
استفاده بهتر از GPU کاهش زمان بیکاری Queueها

GPU Scheduler و Hardware Queue

پس از آنکه Command Bufferها در Command Queue
قرار گرفتند، GPU باید تصمیم بگیرد هر دستور
چه زمانی، با چه اولویتی و روی کدام واحد
سخت‌افزاری اجرا شود. این وظیفه بر عهده
Scheduler و Queueهای سخت‌افزاری GPU است.

GPU Scheduler چیست؟

GPU Scheduler بخشی از معماری سخت‌افزار و
درایور است که اجرای Workloadهای مختلف را
زمان‌بندی می‌کند.

Scheduler مشخص می‌کند کدام Command، Kernel،
Draw Call، عملیات Copy، Decode یا Encode
در چه زمانی برای اجرا به Engine مناسب ارسال
شود.

مسیر زمان‌بندی دستورات

Software Scheduling و Hardware Scheduling

بخشی از تصمیم‌گیری‌های زمان‌بندی ممکن است توسط
سیستم‌عامل و Driver انجام شود و بخش دیگری در
خود GPU و Firmware اجرا شود.

Scheduler نرم‌افزاری بیشتر با برنامه‌ها،
Contextها، اولویت‌ها و مدیریت منابع سروکار
دارد؛ درحالی‌که Scheduler سخت‌افزاری وظایف
آماده را میان Engineها و واحدهای اجرایی توزیع
می‌کند.

تفاوت زمان‌بندی نرم‌افزاری و سخت‌افزاری
معیار Software Scheduler Hardware Scheduler
محل اجرا سیستم‌عامل و Driver GPU یا Firmware
وظیفه مدیریت Context و اولویت توزیع Workload میان Engineها
سطح تصمیم‌گیری برنامه و Process Queue، Command و Work Item
Latency بیشتر کمتر
انعطاف بیشتر وابسته به معماری

Hardware Queue چیست؟

Hardware Queue صفی در سطح GPU است که فرمان‌های
آماده اجرا را برای یک Engine یا گروهی از
واحدهای سخت‌افزاری نگهداری می‌کند.

وجود چند Hardware Queue به GPU اجازه می‌دهد
چند نوع عملیات را با استقلال بیشتری مدیریت
و اجرا کند.

تفاوت Software Queue و Hardware Queue

مقایسه Queue نرم‌افزاری و سخت‌افزاری
ویژگی Software Queue Hardware Queue
محل Driver یا Runtime داخل GPU
مدیریت CPU و Driver Scheduler سخت‌افزاری
سرعت تصمیم‌گیری کمتر بیشتر
تعداد می‌تواند زیاد باشد محدود به معماری GPU
نقش اصلی نگهداری درخواست برنامه‌ها تغذیه مستقیم Engineها

GPU Context چیست؟

هر برنامه‌ای که از GPU استفاده می‌کند، معمولاً
دارای Context مخصوص خود است.

Context شامل وضعیت Pipeline، Shaderها،
Bufferها، تنظیمات حافظه و اطلاعات لازم برای
ادامه اجرای آن برنامه است.

Scheduler هنگام جابه‌جایی میان برنامه‌ها باید
Context فعلی را ذخیره و Context برنامه بعدی
را فعال کند.

Context Switch

Context Switch زمانی رخ می‌دهد که GPU اجرای
یک Workload را متوقف کرده و اجرای Workload
دیگری را آغاز کند.

در این فرآیند، بخشی از وضعیت قبلی باید ذخیره
و وضعیت جدید بارگذاری شود.

Context Switch برای اجرای چند برنامه ضروری
است، اما اگر بیش‌ازحد تکرار شود می‌تواند
Latency و سربار ایجاد کند.

Preemption چیست؟

Preemption به Scheduler اجازه می‌دهد اجرای
یک Workload را موقتاً متوقف کند تا وظیفه‌ای
با اولویت بالاتر اجرا شود.

برای مثال، سیستم ممکن است پردازش طولانی
Compute را متوقف کند تا رابط کاربری یا Frame
نمایشگر با تأخیر مواجه نشود.

کاربردهای Preemption
وضعیت Workload متوقف‌شده Workload اولویت‌دار
Desktop Responsiveness Compute طولانی Render رابط کاربری
Video Playback Background Render Frame نمایش
Real-Time Capture Export غیرزنده Capture و Encode زنده
System Recovery Kernel کند عملیات حیاتی سیستم

Preemption Granularity

Granularity مشخص می‌کند GPU در چه نقطه‌ای
می‌تواند اجرای Workload را متوقف کند.

هرچه سطح Preemption ریزتر باشد، Scheduler
سریع‌تر می‌تواند میان وظایف جابه‌جا شود؛ اما
پیاده‌سازی و ذخیره وضعیت پیچیده‌تر خواهد بود.

سطوح مختلف Preemption
سطح محل توقف Latency واکنش
Command Level پایان یک Command زیاد
Draw / Dispatch Level پایان Draw یا Dispatch متوسط
Thread Group Level پایان یک Work Group کمتر
Instruction Level نزدیک سطح دستور بسیار کم

اولویت Queueها

Queueها می‌توانند اولویت‌های متفاوتی داشته
باشند.

عملیات Real-Time مانند پخش ویدئو، Capture،
رابط کاربری یا پردازش صدا ممکن است نسبت به
Export پس‌زمینه اولویت بیشتری دریافت کنند.

نمونه سطح اولویت Workloadها
Workload اولویت احتمالی دلیل
Display Scanout بسیار بالا جلوگیری از Frame Drop
Live Video Encode بالا حفظ Latency و نرخ فریم
Interactive Preview بالا پاسخ‌گویی Timeline
Background Export متوسط حساسیت کمتر به Latency
Offline AI Processing پایین تا متوسط تمرکز بر Throughput

Fairness در Scheduler

Scheduler باید میان Workloadهای مختلف تعادل
برقرار کند تا یک برنامه تمام منابع GPU را
برای مدت طولانی اشغال نکند.

اگر تنها Priority در نظر گرفته شود، ممکن است
Queueهای کم‌اولویت هرگز فرصت اجرا پیدا نکنند.
این وضعیت Starvation نام دارد.

Queue Starvation

Queue Starvation زمانی رخ می‌دهد که یک Queue
به دلیل حضور مداوم Queueهای پراولویت، زمان
اجرای کافی دریافت نکند.

Schedulerهای مناسب معمولاً از مکانیزم‌هایی
برای جلوگیری از Starvation استفاده می‌کنند.

Round-Robin Scheduling

در روش Round-Robin، هر Queue یا Context برای
مدت محدودی فرصت اجرا دریافت می‌کند و سپس نوبت
به Queue بعدی می‌رسد.

این روش Fairness مناسبی ایجاد می‌کند، اما ممکن
است برای Workloadهای Real-Time نیاز به Priority
اضافی داشته باشد.

Time Slice چیست؟

Time Slice بازه زمانی مشخصی است که Scheduler
برای اجرای یک Context یا Queue در نظر می‌گیرد.

Time Slice بسیار کوتاه باعث افزایش Context
Switch می‌شود و Time Slice بسیار بلند ممکن
است Latency برنامه‌های دیگر را افزایش دهد.

اثر اندازه Time Slice
Time Slice مزیت محدودیت
کوتاه پاسخ‌گویی بهتر Context Switch بیشتر
متوسط تعادل Latency و Throughput نیازمند تنظیم مناسب
بلند Throughput بیشتر برای یک Workload تأخیر Queueهای دیگر

Queue Depth

Queue Depth تعداد Work Itemها یا Command
Bufferهایی است که در صف انتظار قرار دارند.

Queue بسیار خالی باعث بیکار ماندن Engine می‌شود،
اما Queue بسیار عمیق می‌تواند Latency را افزایش
دهد.

اثر Queue Depth بر عملکرد
وضعیت نتیجه
Queue خالی بیکارشدن Engine
Queue کم‌عمق Latency پایین، Throughput محدودتر
Queue متعادل استفاده مناسب از سخت‌افزار
Queue بسیار عمیق افزایش زمان انتظار Command

Work-Conserving Scheduler

Scheduler نوع Work-Conserving تلاش می‌کند تا
زمانی که Workload آماده وجود دارد، واحد
سخت‌افزاری را بیکار نگذارد.

اگر Graphics Queue منتظر داده باشد، ممکن است
Compute Queue یا Copy Queue از ظرفیت آزاد
استفاده کند؛ البته فقط درصورتی‌که منابع و
وابستگی‌ها اجازه دهند.

زمان‌بندی چند Engine

GPU مدرن ممکن است چند Engine مستقل داشته باشد.
Scheduler می‌تواند Workloadهای سازگار را
هم‌زمان روی آن‌ها اجرا کند.

زمان‌بندی وابسته به Dependency

Scheduler نمی‌تواند فقط بر اساس خالی‌بودن
Engine تصمیم بگیرد؛ وابستگی داده‌ها نیز باید
رعایت شود.

برای مثال، Encode یک Frame تنها زمانی آغاز
می‌شود که پردازش Compute همان Frame کامل شده
باشد.

گلوگاه‌های مربوط به Scheduler

مشکلات رایج در زمان‌بندی GPU
مشکل نشانه پیامد
Queue خالی Utilization پایین بیکارشدن Engine
Queue بسیار عمیق تأخیر زیاد افزایش Latency
Context Switch زیاد نوسان عملکرد سربار Scheduler
Priority نامناسب افت Frame یا کندی رابط اجرای دیرهنگام کار حیاتی
Starvation پیشرفت‌نکردن Queue توقف Workload کم‌اولویت
Dependency زیاد Engineهای منتظر کاهش Parallelism
Preemption ضعیف تأخیر رابط کاربری واکنش کند سیستم

بهینه‌سازی زمان‌بندی GPU

راهکارهای بهبود استفاده از Scheduler
راهکار نتیجه
پر نگه‌داشتن Queueها کاهش بیکاری Engine
کاهش Synchronization اضافی افزایش اجرای هم‌زمان
اولویت صحیح Workload حفظ پاسخ‌گویی Real-Time
Command Buffer مناسب کاهش سربار Submit
تقسیم Workload طولانی Preemption و Fairness بهتر
استفاده از چند Queue بهره‌گیری از Engineهای مستقل
Queue Depth کنترل‌شده تعادل Throughput و Latency

Asynchronous Compute و اجرای هم‌زمان Engineها

GPUهای مدرن می‌توانند عملیات Graphics،
Compute، Copy، Decode و Encode را تا حدی
هم‌زمان اجرا کنند. این قابلیت زمانی مفید است
که Workloadها از واحدهای مستقل استفاده کنند،
منابع مشترک کافی داشته باشند و میان آن‌ها
وابستگی یا Synchronization غیرضروری وجود
نداشته باشد.

Asynchronous Compute چیست؟

Asynchronous Compute به اجرای Workloadهای
Compute در کنار سایر عملیات GPU گفته می‌شود،
بدون اینکه همه مراحل مجبور باشند کاملاً
متوالی اجرا شوند.

برای مثال، در حالی که بخشی از GPU یک Frame را
Render می‌کند، بخشی دیگر ممکن است Optical
Flow، Color Processing یا یک فیلتر Compute را
روی Frame دیگری اجرا کند.

اجرای متوالی و اجرای Asynchronous

در اجرای متوالی، هر مرحله باید کاملاً پایان
یابد تا مرحله بعدی شروع شود.

در اجرای Asynchronous، عملیات مستقل یا
بخش‌هایی از آن‌ها می‌توانند در بازه‌های زمانی
مشترک اجرا شوند.

چه زمانی اجرای واقعاً موازی رخ می‌دهد؟

قرارگرفتن چند Command در Queueهای متفاوت
به‌تنهایی تضمین نمی‌کند که آن‌ها واقعاً
هم‌زمان اجرا شوند.

اجرای واقعی موازی به وجود Engineهای مستقل،
منابع آزاد، نبود وابستگی مستقیم و پشتیبانی
Scheduler و Driver بستگی دارد.

شرایط لازم برای Parallel Execution
شرط دلیل
Engine مستقل جلوگیری از رقابت برای یک واحد اجرایی
نبود Dependency مستقیم امکان شروع بدون انتظار برای مرحله دیگر
Memory Bandwidth کافی تغذیه هم‌زمان چند Engine
ظرفیت VRAM کافی نگهداری Bufferهای هم‌زمان
Queue و Scheduler مناسب ارسال Workload به Engine صحیح
Synchronization محدود جلوگیری از توقف غیرضروری Pipeline

Multi-Engine Execution

GPU مدرن ممکن است چند Engine مستقل برای
Graphics، Compute، Copy، Decode، Encode و
Display داشته باشد.

Multi-Engine Execution یعنی استفاده هم‌زمان
از این واحدها برای اجرای بخش‌های مختلف
Pipeline.

استقلال Engineها

برخی Engineها مدارهای کاملاً جداگانه‌ای دارند،
اما همچنان ممکن است از منابع مشترکی مانند
VRAM، L2 Cache، Memory Controller و PCIe
استفاده کنند.

بنابراین مستقل‌بودن Engine به معنی مستقل‌بودن
کامل همه منابع سیستم نیست.

منابع اختصاصی و مشترک Engineهای GPU
منبع وضعیت معمول پیامد
Decode Unit اختصاصی Decode مستقل از Shader
Encode Unit اختصاصی Encode مستقل از Compute
Shader Core مشترک میان Graphics و Compute رقابت Workloadهای Shader
VRAM مشترک رقابت برای ظرفیت و پهنای باند
L2 Cache معمولاً مشترک Cache Contention احتمالی
Memory Controller مشترک رقابت درخواست‌های حافظه

هم‌پوشانی Graphics و Compute

Graphics و Compute ممکن است از Shader Coreهای
مشترک استفاده کنند. در این حالت، Scheduler
تلاش می‌کند Workloadهای آن‌ها را میان منابع
موجود توزیع کند.

اگر Graphics تمام Shaderها، Registerها یا
حافظه محلی را اشغال کرده باشد، Compute فضای
کافی برای اجرای هم‌زمان نخواهد داشت.

مزایای Asynchronous Compute

مزایای اجرای Compute به‌صورت Asynchronous
مزیت نتیجه
استفاده از منابع آزاد افزایش GPU Utilization
پنهان‌کردن Latency انجام کار دیگر هنگام انتظار یک مرحله
افزایش Throughput پردازش Frameهای بیشتر در زمان یکسان
کاهش زمان بیکاری Engine استفاده بهتر از سخت‌افزار
مناسب Pipeline ویدئو هم‌زمانی Decode، Effect و Encode

محدودیت‌های Asynchronous Compute

اجرای هم‌زمان همیشه باعث افزایش سرعت نمی‌شود.
اگر Workloadها برای یک منبع مشترک رقابت کنند،
ممکن است عملکرد هر دو کاهش یابد.

عوامل محدودکننده Async Compute
محدودیت اثر
Shader Saturation نبود فضای اجرایی برای Compute دوم
Memory Bandwidth Saturation انتظار هم‌زمان چند Engine برای داده
Register Pressure کاهش Workloadهای Resident
Shared Memory Usage محدودشدن تعداد Work Groupها
Dependency تبدیل اجرای موازی به انتظار متوالی
Synchronization Overhead کاهش سود اجرای هم‌زمان

ارتباط Async Compute با Occupancy

برای اجرای هم‌زمان چند Workload، باید منابع
کافی برای Resident شدن آن‌ها روی واحدهای
پردازشی وجود داشته باشد.

اگر Kernel اول تمام Register File، Shared
Memory یا ظرفیت Waveها را مصرف کند، Kernel دوم
حتی با وجود Queue مستقل منتظر خواهد ماند.

منابع مؤثر بر هم‌زمانی Kernelها
منبع اثر مصرف زیاد
Register کاهش Threadها و Kernelهای Resident
Shared Memory کاهش Work Groupهای هم‌زمان
Wave / Warp Slot محدودشدن Workload دوم
Cache افزایش Cache Thrashing
Memory Bandwidth کاهش Throughput هر دو Workload

مثال اجرای Asynchronous در Pipeline ویدئو

در یک Transcode سخت‌افزاری، چند Frame می‌توانند
هم‌زمان در مراحل مختلف Pipeline قرار داشته
باشند.

هم‌پوشانی Copy و Compute

Copy Engine می‌تواند Frame بعدی را Upload کند،
در حالی که Compute Engine Frame فعلی را
پردازش می‌کند.

برای این کار معمولاً از چند Buffer و انتقال
Asynchronous استفاده می‌شود.

Double Buffering و Triple Buffering

استفاده از چند Buffer اجازه می‌دهد یک Buffer
در حال انتقال، Buffer دیگر در حال پردازش و
Buffer سوم در حال آماده‌سازی یا نمایش باشد.

کاربرد Bufferهای هم‌زمان
Buffer وضعیت نمونه
Buffer A در حال پردازش Compute
Buffer B در حال Upload یا Decode
Buffer C در حال Encode یا Display

Pipeline Bubble چیست؟

Pipeline Bubble بازه‌ای است که یک یا چند Engine
به دلیل نبود Workload آماده یا انتظار برای
داده بیکار می‌مانند.

Queue خالی، Synchronization، انتقال کند و
Dependency می‌توانند Pipeline Bubble ایجاد
کنند.

موازی‌سازی ظاهری

ممکن است ابزار Profiler چند Queue فعال نشان
دهد، اما Workloadها عملاً به‌صورت نوبتی اجرا
شوند.

این حالت زمانی رخ می‌دهد که Queueها از Engine
مشترک استفاده کنند یا برای یک منبع اشباع‌شده
رقابت داشته باشند.

دلایل موازی نبودن واقعی Workloadها
علت نتیجه
Engine مشترک اجرای نوبتی Queueها
Dependency پنهان انتظار یک Queue برای Queue دیگر
Memory Saturation کندشدن هم‌زمان همه Engineها
Resource Exhaustion Resident نشدن Workload دوم
Driver Serialization اجرای متوالی در سطح Runtime

اثر Async Execution بر Latency و Throughput

Asynchronous Execution معمولاً Throughput کل
را افزایش می‌دهد، اما ممکن است زمان تکمیل یک
Frame مشخص را کاهش ندهد.

Queue Depth و Buffering بیشتر می‌توانند
سخت‌افزار را مشغول نگه دارند، ولی Latency
انتها‌به‌انتهای Pipeline را افزایش دهند.

تفاوت هدف در Workloadهای مختلف
کاربرد هدف اصلی تنظیم مناسب
Live Streaming Latency پایین Queue کوتاه و Buffer محدود
Offline Export Throughput بالا Queue عمیق‌تر و Parallelism بیشتر
Interactive Preview پاسخ‌گویی Priority بالا و Preemption مناسب
Batch Transcode بیشترین تعداد Frame در ثانیه چند Stream و Buffer موازی

گلوگاه‌های اجرای Asynchronous

مشکلات رایج در Multi-Engine Execution
گلوگاه نشانه پیامد
Memory Contention فعالیت زیاد چند Engine با سرعت پایین افت Throughput
Synchronization زیاد فاصله خالی میان Workloadها Pipeline Bubble
Queue Imbalance یک Engine بیکار و Engine دیگر اشباع استفاده ناقص از GPU
Resource Saturation اجرا نشدن Workload دوم تبدیل Async به Serial
Buffer کم انتظار Engine برای Frame کاهش موازی‌سازی
Buffer زیاد صف طولانی افزایش Latency

بهینه‌سازی Multi-Engine Execution

راهکارهای افزایش بهره‌وری اجرای هم‌زمان
راهکار نتیجه
توزیع Workload میان Engineهای مستقل افزایش Parallelism واقعی
کاهش Barrierهای غیرضروری حذف زمان انتظار
استفاده از Buffer Ring تغذیه پیوسته مراحل Pipeline
تنظیم Queue Depth تعادل Latency و Throughput
کاهش Register Pressure امکان Resident شدن Kernelهای بیشتر
ادغام Passهای حافظه‌محور کاهش Memory Traffic
Zero-Copy و API Interop کاهش Copy و PCIe Traffic
Profiling Timeline شناسایی Bubble و Serialization

Frame Buffer، Video Surface، Texture و Render Target

در طول اجرای Pipeline، داده‌های تصویری بارها میان
واحدهای مختلف GPU جابه‌جا می‌شوند. این داده‌ها در
ساختارهای حافظه متفاوتی نگهداری می‌شوند که هرکدام
برای نوع خاصی از پردازش طراحی شده‌اند.

Frame Buffer چیست؟

Frame Buffer بخشی از حافظه GPU است که تصویر کامل یک
Frame در آن ذخیره می‌شود.

این تصویر ممکن است در حال Render شدن باشد،
آماده نمایش باشد یا نتیجه پردازش یک Shader یا
Video Engine را نگهداری کند.

Video Surface چیست؟

Video Surface ساختاری در حافظه GPU است که معمولاً
برای نگهداری Frameهای خام ویدئویی استفاده می‌شود.

Decoder، Video Processor، AI Engine و Encoder
مستقیماً روی Surfaceها کار می‌کنند.

Texture چیست؟

Texture نوعی ساختار حافظه است که برای دسترسی سریع
دوبعدی یا سه‌بعدی به داده‌ها طراحی شده است.

Texture تنها برای تصاویر رنگی نیست و می‌تواند شامل
داده‌های عمق، حجم، نویز، LUT یا هر آرایه دوبعدی
دیگری باشد.

Render Target چیست؟

Render Target حافظه‌ای است که خروجی عملیات Render
مستقیماً در آن نوشته می‌شود.

پس از پایان Render، همین تصویر می‌تواند به Texture،
Frame Buffer یا تصویر نهایی نمایشگر تبدیل شود.

مسیر حرکت Frame

مقایسه ساختارهای حافظه

تفاوت انواع ساختارهای نگهداری تصویر
ساختار کاربرد خواندن نوشتن
Video Surface پردازش ویدئو بله بله
Texture Sampling بسیار سریع محدود
Render Target خروجی Render گاهی بله
Frame Buffer تصویر نهایی بله بله

چند Frame Buffer

برای جلوگیری از توقف Pipeline معمولاً بیش از یک
Frame Buffer وجود دارد.

در سیستم‌های Real-Time معمولاً از Double Buffering یا
Triple Buffering استفاده می‌شود.

Layout حافظه تصویر

داده‌های تصویر همیشه به صورت خطی ذخیره نمی‌شوند.
بسیاری از GPUها از Tile Layout یا Block Layout
استفاده می‌کنند تا دسترسی Cache سریع‌تر شود.

Image Memory Layout در GPU

تصویر در حافظه GPU تنها مجموعه‌ای از Pixelها نیست.
نحوه چیدمان این Pixelها در حافظه، یکی از مهم‌ترین
عوامل تعیین‌کننده عملکرد Cache، پهنای باند حافظه،
سرعت Texture Sampling و کارایی Render Pipeline است.
به این نحوه سازمان‌دهی داده‌ها، Image Memory Layout
گفته می‌شود.

Image Memory Layout چیست؟

Image Memory Layout مشخص می‌کند Pixelهای یک تصویر
با چه ترتیبی در حافظه فیزیکی GPU ذخیره شوند.

دو تصویر ممکن است کاملاً یکسان به نظر برسند اما
داده‌های آن‌ها در حافظه کاملاً متفاوت سازمان‌دهی
شده باشند.

چرا Layout اهمیت دارد؟

Shaderها معمولاً Pixelهای مجاور را پشت سر هم
پردازش می‌کنند.

اگر Pixelهای مجاور در حافظه نیز کنار هم باشند،
Cache بسیار مؤثرتر عمل خواهد کرد و تعداد دسترسی
به VRAM کاهش می‌یابد.

انواع رایج Layout

رایج‌ترین Layoutهای حافظه تصویر
Layout کاربرد
Linear CPU ،DMA ،فایل‌ها
Pitched Alignment سطرها
Tiled Render و Texture
Block Linear GPUهای مدرن NVIDIA
Swizzled Texture Cache
Morton (Z-order) Locality بالا

تصویر و حافظه

Linear Layout

در این Layout تمام Pixelها دقیقاً پشت سر هم
ذخیره می‌شوند.

ساده‌ترین Layout است و معمولاً توسط CPU، فایل‌های
تصویری و انتقال DMA استفاده می‌شود.

مزایا و محدودیت‌های Linear Layout

ویژگی‌های Linear Layout
ویژگی وضعیت
سادگی بسیار زیاد
مناسب CPU بله
مناسب Cache GPU معمولاً خیر
سرعت Texture Sampling کمتر از Layoutهای Tiled

فصل بعد

GPU MEMORY ARCHITECTURE

Pitch، Stride و Row Alignment

بررسی فاصله واقعی میان سطرهای تصویر در حافظه،
Padding، Alignment و دلایلی که باعث می‌شوند اندازه
واقعی یک تصویر در حافظه با حاصل‌ضرب ساده عرض و ارتفاع
برابر نباشد.


سطح فصل


متوسط


زمان مطالعه


حدود ۱۵ دقیقه


موضوع


Image Memory Layout


نسخه


v1.0

پیش‌نیازهای فصل

  • آشنایی با Pixel و Byte
  • شناخت Linear Layout
  • درک مقدماتی حافظه و Alignment

در این فصل یاد می‌گیرید

  • Pitch و Stride چه تفاوتی دارند
  • چرا میان سطرهای تصویر Padding ایجاد می‌شود
  • چگونه آدرس یک Pixel در حافظه محاسبه می‌شود
  • چرا فرض فشرده‌بودن سطرها خطرناک است

نقشه مفهومی فصل
Image Row Layout
Row Size
Pitch / Stride
Alignment
Padding
Pixel Address
Buffer Size

Pitch چیست؟

Pitch تعداد Byteهایی است که از ابتدای یک سطر تصویر تا
ابتدای سطر بعدی در حافظه فاصله وجود دارد.

این مقدار ممکن است دقیقاً برابر اندازه واقعی داده‌های
یک سطر باشد، اما در بسیاری از Bufferهای GPU بزرگ‌تر است.

Stride چیست؟

Stride نیز معمولاً به فاصله میان دو عنصر متوالی در حافظه
اشاره دارد.

در پردازش تصویر، اصطلاح Row Stride اغلب همان مفهومی را
بیان می‌کند که Pitch بیان می‌کند؛ یعنی فاصله میان شروع
دو سطر متوالی.

بااین‌حال، Stride می‌تواند برای فاصله میان Pixelها،
Channelها، Planeها یا عناصر یک Tensor نیز استفاده شود.

تفاوت Pitch و Stride

مقایسه Pitch و Stride
معیار Pitch Stride
کاربرد رایج فاصله میان سطرهای تصویر فاصله میان عناصر یا سطرها
واحد معمولاً Byte Byte یا تعداد عنصر
حوزه استفاده APIهای گرافیکی و ویدئویی تصویر، Tensor و آرایه
هم‌معنی بودن در بسیاری از APIها بله وابسته به Context

اندازه واقعی داده یک سطر

در یک تصویر Packed، اندازه خام یک سطر از حاصل‌ضرب عرض
تصویر در تعداد Byteهای هر Pixel به‌دست می‌آید.

برای نمونه، در تصویر RGBA هشت‌بیتی هر Pixel چهار Byte
دارد.

Padding میان سطرها

GPU یا Driver ممکن است چند Byte اضافی در انتهای هر سطر
قرار دهد تا ابتدای سطر بعدی با مرز حافظه مناسب هم‌تراز
شود.

این Byteهای اضافی Padding نام دارند و بخشی از داده
قابل‌مشاهده تصویر نیستند.

Row Alignment چیست؟

Alignment مشخص می‌کند شروع یک سطر باید روی مضربی از چه
تعداد Byte قرار گیرد.

برای مثال، اگر Alignment برابر 256 Byte باشد، Pitch باید
مضربی از 256 باشد.

نمونه Alignmentهای متداول
Alignment کاربرد احتمالی
4 Byte داده‌های ساده CPU
16 Byte SIMD و Vector Access
64 Byte Cache Line و دسترسی سریع‌تر
128 Byte بعضی Bufferهای GPU
256 Byte Copy و Texture Resourceهای خاص

محاسبه Pitch بر اساس Alignment

برای محاسبه Pitch، اندازه خام سطر به نزدیک‌ترین مضرب
بالاتر Alignment گرد می‌شود.

فرض کنید اندازه خام سطر 1000 Byte و Alignment برابر
256 Byte باشد.

نمایش حافظه‌ای Pitch

محاسبه آدرس یک Pixel

برای یافتن آدرس Pixel با مختصات x و y، باید Pitch واقعی
Buffer استفاده شود، نه صرفاً عرض تصویر.

بخش y × Pitch آدرس ابتدای سطر و بخش x × Bytes Per Pixel
محل Pixel در همان سطر را مشخص می‌کند.

اندازه واقعی Buffer

اندازه حافظه موردنیاز تصویر دارای Pitch معمولاً از
حاصل‌ضرب Pitch در ارتفاع به‌دست می‌آید.

بنابراین مقدار واقعی حافظه می‌تواند از اندازه منطقی
Pixelهای تصویر بیشتر باشد.

اندازه منطقی و اندازه فیزیکی تصویر

تفاوت اندازه منطقی و فیزیکی Buffer
مفهوم فرمول شامل Padding
Logical Size Width × Height × Bpp خیر
Physical Buffer Size Pitch × Height بله

Negative Stride

در بعضی فرمت‌ها یا APIها، Stride می‌تواند منفی باشد.

Stride منفی معمولاً نشان می‌دهد سطرها در حافظه از پایین
به بالا ذخیره یا پیمایش می‌شوند.

این حالت در بعضی Bitmapهای قدیمی یا ساختارهای خاص
سیستم‌عامل دیده می‌شود.

Pitch در تصاویر چند Plane

فرمت‌های YUV Planar یا Semi-Planar ممکن است برای هر Plane
دارای Pitch مستقل باشند.

برای مثال، Plane روشنایی و Plane رنگ ممکن است عرض،
ارتفاع و Alignment متفاوتی داشته باشند.

نمونه Pitch در فرمت چند Plane
Plane داده Pitch
Y Plane روشنایی مستقل
U Plane مؤلفه رنگ اول ممکن است کوچک‌تر باشد
V Plane مؤلفه رنگ دوم ممکن است کوچک‌تر باشد
UV Plane رنگ Interleaved مستقل از Y

Pitch در APIهای مختلف


CUDA

cudaMallocPitch و مقدار pitch


Direct3D

RowPitch در Subresource Mapping


Vulkan

rowPitch در Subresource Layout


FFmpeg

linesize برای هر Plane


OpenCV

step یا step1


Metal

bytesPerRow

چرا GPU به Row Alignment نیاز دارد؟

دلایل استفاده از Alignment
دلیل نتیجه
دسترسی حافظه منظم کاهش عملیات حافظه شکسته
سازگاری با Cache Line استفاده بهتر از Cache
انتقال DMA افزایش کارایی Copy
محدودیت سخت‌افزار دسترسی ساده‌تر Memory Controller
Texture Sampling خواندن منظم Blockها

کپی تصویر دارای Pitch

هنگام کپی یک تصویر دارای Pitch، معمولاً نباید کل Buffer
را به‌عنوان یک آرایه فشرده از Pixelها در نظر گرفت.

Copy باید سطر‌به‌سطر انجام شود یا از API مخصوص کپی
دوبعدی استفاده شود.

تفاوت Source Pitch و Destination Pitch

هنگام انتقال تصویر میان CPU و GPU یا میان دو Buffer،
Pitch مبدأ و مقصد ممکن است متفاوت باشند.

تنها بخش واقعی Pixel Data هر سطر کپی می‌شود و Padding
مبدأ لزوماً به مقصد منتقل نمی‌شود.


PERFORMANCE IMPACT

اثر Pitch و Alignment بر عملکرد

Memory Access


زیاد

Copy Performance


زیاد

VRAM Usage


کم تا متوسط

Correctness


بسیار زیاد

خطاهای رایج مرتبط با Pitch

مشکلات متداول پردازش تصویر دارای Pitch
خطا نشانه علت
تصویر مورب جابه‌جایی تدریجی سطرها استفاده از Row Size به‌جای Pitch
خطوط خراب نمایش Pixelهای نامعتبر خواندن Padding به‌عنوان داده تصویر
رنگ‌های اشتباه Channelهای جابه‌جا یا شکسته Stride Pixel یا Format اشتباه
Crash دسترسی خارج از Buffer محاسبه نادرست اندازه حافظه
کپی ناقص سطرهای بریده‌شده Copy Size نادرست


M2


CHAPTER SUMMARY

خلاصه فصل

  • Pitch فاصله میان شروع دو سطر متوالی در حافظه است.
  • Pitch ممکن است از اندازه واقعی داده یک سطر بیشتر باشد.
  • Padding برای رعایت Alignment به انتهای سطر افزوده می‌شود.
  • آدرس Pixel باید با استفاده از Pitch واقعی محاسبه شود.
  • تصاویر چند Plane می‌توانند برای هر Plane Pitch جداگانه داشته باشند.
  • اندازه فیزیکی Buffer معمولاً Pitch ضرب‌در Height است.

واژه‌نامه فصل

Pitchفاصله Byteای میان شروع دو سطر متوالی تصویر.
Strideفاصله حافظه‌ای میان عناصر، Pixelها یا سطرها.
Paddingفضای اضافی میان داده واقعی و ابتدای بخش بعدی.
Alignmentقرارگیری آدرس یا اندازه روی مضربی مشخص از Byte.
RowPitchنام رایج Pitch در بعضی APIهای گرافیکی.

فصل بعد

GPU MEMORY ARCHITECTURE

Planar، Semi-Planar و Packed Pixel Formats

بررسی روش‌های ذخیره مؤلفه‌های رنگ در حافظه، تفاوت
Plane و Channel، ساختار فرمت‌هایی مانند RGB، RGBA،
YUV420P، NV12 و P010 و اثر چیدمان Pixelها بر Decode،
پردازش، Copy و نمایش تصویر.


سطح فصل


متوسط


زمان مطالعه


حدود ۲۰ دقیقه


موضوع


Pixel Memory Organization


نسخه


v1.0

پیش‌نیازهای فصل

  • شناخت فضای رنگ RGB و YUV
  • آشنایی با Chroma Subsampling
  • درک Pitch، Stride و Row Alignment

در این فصل یاد می‌گیرید

  • Plane و Channel چه تفاوتی دارند
  • Packed و Planar چگونه داده را ذخیره می‌کنند
  • NV12 و P010 چرا Semi-Planar هستند
  • آدرس هر مؤلفه رنگ چگونه محاسبه می‌شود

نقشه مفهومی فصل
Pixel Format Layout
Packed
Planar
Semi-Planar
Channel Order
Plane Pitch
Chroma Layout

Pixel Format چیست؟

Pixel Format مشخص می‌کند اطلاعات رنگ هر Pixel از چه
مؤلفه‌هایی تشکیل شده، هر مؤلفه چند Bit دارد و این
مؤلفه‌ها با چه ترتیبی در حافظه ذخیره می‌شوند.

دو تصویر با Resolution و محتوای کاملاً یکسان می‌توانند
به دلیل تفاوت Pixel Format، اندازه، Layout و روش دسترسی
متفاوتی در حافظه داشته باشند.

تفاوت Channel و Plane

Channel یک مؤلفه معنایی تصویر مانند Red، Green، Blue،
Alpha، Y، U یا V است.

Plane یک ناحیه یا Buffer حافظه‌ای است که یک یا چند
Channel را نگهداری می‌کند.

مقایسه Channel و Plane
مفهوم تعریف نمونه
Channel یک مؤلفه رنگ یا داده R، G، B، A، Y، U، V
Plane یک ناحیه مستقل حافظه Y Plane یا UV Plane

Packed Format

در فرمت Packed، مؤلفه‌های مربوط به یک Pixel یا گروهی از
Pixelها پشت سر هم در یک Plane حافظه ذخیره می‌شوند.

فرمت‌های RGB، RGBA و BGRA از نمونه‌های رایج Packed
هستند.

ویژگی‌های Packed Format

مزایا و محدودیت‌های فرمت Packed
ویژگی نتیجه
یک Plane مدیریت ساده‌تر Buffer
مؤلفه‌های مجاور دسترسی آسان به تمام Channelهای Pixel
مناسب Rendering سازگار با Texture و Render Target
استخراج یک Channel نیازمند عبور از داده‌های Interleaved
اندازه هر Pixel معمولاً ثابت و قابل محاسبه مستقیم

ترتیب Channelها در فرمت Packed

نام فرمت معمولاً ترتیب منطقی Channelها را بیان می‌کند،
اما نمایش Byteها در حافظه ممکن است به Endianness،
تعریف API و اندازه عنصر ذخیره‌سازی وابسته باشد.

نمونه فرمت‌های Packed رنگی
فرمت Channelها کاربرد رایج
RGB24 R، G، B تصویر سه‌کاناله ۸ بیت
RGBA32 R، G، B، A Rendering و Compositing
BGRA32 B، G، R، A رابط‌های گرافیکی و Frame Buffer
RGB565 R5، G6، B5 نمایشگر و سخت‌افزار کم‌حافظه
RGB10A2 RGB ده‌بیتی و Alpha دوبیتی خروجی رنگ با دقت بیشتر

فرمت‌های YUV Packed

فرمت Packed تنها مخصوص RGB نیست. در بعضی فرمت‌های YUV،
مؤلفه‌های روشنایی و رنگ چند Pixel در یک Stream مشترک
قرار می‌گیرند.

نمونه فرمت‌های YUV Packed
فرمت ترتیب حافظه Chroma
YUY2 / YUYV Y0 U0 Y1 V0 4:2:2
UYVY U0 Y0 V0 Y1 4:2:2
AYUV A Y U V برای هر Pixel 4:4:4

Planar Format

در فرمت Planar، هر Channel یا گروه مشخصی از داده‌ها در
Plane جداگانه ذخیره می‌شود.

در فرمت YUV420P، مؤلفه Y در Plane اول، U در Plane دوم
و V در Plane سوم قرار می‌گیرد.

سازمان‌دهی حافظه در فرمت Planar

Planeها ممکن است در Allocationهای کاملاً جداگانه باشند
یا به‌صورت متوالی داخل یک Buffer بزرگ قرار گیرند.

برای دسترسی صحیح، آدرس پایه، Pitch، ارتفاع و Offset هر
Plane باید جداگانه شناخته شود.

ویژگی‌های Planar Format

مزایا و محدودیت‌های فرمت Planar
ویژگی نتیجه
Plane مستقل پردازش جداگانه هر مؤلفه
Chroma Subsampling ذخیره U و V با ابعاد کوچک‌تر
مناسب Codec سازگار با ساختار طبیعی بسیاری از Codecها
مدیریت پیچیده‌تر نیاز به Pitch و Offset جداگانه
تبدیل به RGB نیازمند Sampling از چند Plane

ساختار YUV420P

در YUV420P برای هر Pixel یک Sample روشنایی وجود دارد،
اما هر Sample از U و V میان یک بلوک ۲×۲ از Pixelها
مشترک است.

ابعاد Planeها در YUV420P
Plane عرض ارتفاع
Y Width Height
U Width ÷ 2 Height ÷ 2
V Width ÷ 2 Height ÷ 2

تفاوت I420 و YV12

هر دو فرمت Planar و 4:2:0 هستند، اما ترتیب Planeهای
رنگی آن‌ها متفاوت است.

Semi-Planar Format

در فرمت Semi-Planar، روشنایی در یک Plane مستقل قرار دارد،
اما مؤلفه‌های U و V به‌صورت Interleaved در Plane دوم
ذخیره می‌شوند.

NV12 یکی از رایج‌ترین نمونه‌های این ساختار است.

NV12

NV12 یک فرمت YUV 4:2:0 هشت‌بیتی و دو Plane است.

ساختار NV12
Plane محتوا ابعاد منطقی
Plane 0 Y هشت‌بیتی Width × Height
Plane 1 UV Interleaved Width × Height ÷ 2 از نظر Byte

NV12 در Decode سخت‌افزاری، Video Processing و مسیرهای
Zero-Copy بسیار رایج است؛ زیرا تعداد Planeها را نسبت به
YUV420P کاهش می‌دهد.

NV21

NV21 از نظر ابعاد و Subsampling مشابه NV12 است، اما ترتیب
مؤلفه‌های Plane رنگی متفاوت است.

P010

P010 یک فرمت Semi-Planar از خانواده YUV 4:2:0 است که
معمولاً برای ویدئوی ده‌بیتی و HDR استفاده می‌شود.

هر Sample معمولاً داخل یک Container شانزده‌بیتی نگهداری
می‌شود؛ بنابراین نام ده‌بیتی فرمت به معنی مصرف دقیق ده
Bit فیزیکی برای هر Sample در حافظه نیست.

P016

P016 از نظر ساختار Plane مشابه P010 است، اما Container
شانزده‌بیتی می‌تواند Precision بیشتری را نمایش دهد.

تفسیر دقیق Bitهای معتبر باید از تعریف API، Codec یا
Metadata منبع مشخص شود.

مقایسه Packed، Planar و Semi-Planar

تفاوت سه روش اصلی چیدمان Pixel Format
معیار Packed Planar Semi-Planar
تعداد Plane معمولاً یک چند Plane مستقل معمولاً دو
Channelها Interleaved جدا بخشی جدا، بخشی Interleaved
نمونه RGBA، YUY2 I420، YV12 NV12، P010
مدیریت Buffer ساده‌تر پیچیده‌تر متعادل
کاربرد رایج Rendering و Display Codec و پردازش مستقل Plane Video Engine و Zero-Copy

محاسبه آدرس Pixel در فرمت Packed

پس از یافتن آدرس Pixel، Offset هر Channel بر اساس ترتیب
تعریف‌شده فرمت محاسبه می‌شود.

محاسبه آدرس در فرمت Planar

در فرمت Planar، هر Plane دارای Base Address و Pitch
مخصوص خود است.

تقسیم مختصات بر دو به دلیل Subsampling افقی و عمودی
مؤلفه‌های رنگ در 4:2:0 است.

محاسبه آدرس Chroma در NV12

در NV21، Offset مؤلفه‌های U و V در Pair برعکس می‌شود.

Pitch مستقل هر Plane

نباید فرض کرد Pitch تمام Planeها با یکدیگر برابر است.
Driver یا API می‌تواند هر Plane را بر اساس نیاز سخت‌افزار
به‌طور جداگانه Align کند.

اطلاعات موردنیاز برای دسترسی به هر Plane
ویژگی وظیفه
Base Address آدرس شروع Plane
Row Pitch فاصله میان سطرها
Width تعداد Sampleهای افقی
Height تعداد سطرهای Plane
Sample Size اندازه هر عنصر حافظه

محاسبه اندازه تقریبی Buffer

در Buffer فشرده و بدون Padding، فرمت‌های هشت‌بیتی YUV
4:2:0 معمولاً به ازای هر Pixel منطقی حدود ۱٫۵ Byte داده
ذخیره می‌کنند.

اندازه Allocation واقعی می‌تواند به دلیل Pitch، Alignment،
Metadata یا Layout سخت‌افزاری بیشتر باشد.

تبدیل میان Pixel Formatها

تبدیل Pixel Format تنها جابه‌جایی Byteها نیست. در بسیاری
از موارد باید Chroma بازسازی، Matrix رنگ اعمال، Range
تبدیل یا Bit Depth تغییر داده شود.

Pixel Format و Zero-Copy

Zero-Copy تنها زمانی مؤثر است که تمام مراحل Pipeline
بتوانند Surface را با Format و Layout موجود مصرف کنند.

اگر Decoder خروجی NV12 تولید کند ولی فیلتر فقط RGBA را
بپذیرد، مرحله تبدیل Format و احتمالاً Buffer جدید لازم
خواهد بود.

خطاهای رایج Pixel Format

مشکلات متداول هنگام تفسیر Layout
خطا نشانه علت
جابه‌جایی U و V رنگ‌های غیرطبیعی اشتباه میان I420، YV12، NV12 یا NV21
Pitch مشترک فرض‌شده خرابی سطرهای Chroma نادیده‌گرفتن Pitch مستقل Plane
ابعاد اشتباه Chroma دسترسی خارج از Buffer نادیده‌گرفتن Subsampling
RGBA و BGRA اشتباه جابه‌جایی قرمز و آبی ترتیب Channel نادرست
P010 مانند 10-bit Packed تصویر تاریک یا خراب نادیده‌گرفتن Container شانزده‌بیتی


PERFORMANCE IMPACT

اثر Pixel Format Layout بر عملکرد

Memory Usage
زیاد
Conversion Cost
بسیار زیاد
Cache Behavior
زیاد
Zero-Copy Compatibility
بسیار زیاد


API MAPPING

Pixel Format در APIهای مختلف

FFmpeg
AVPixelFormat، data و linesize
Vulkan
VkFormat و Multi-Planar Image Format
Direct3D
DXGI_FORMAT_NV12، P010 و BGRA
CUDA
Linear Memory، Array، Surface و Texture View
VA-API
Surface Format و Image Format
OpenCV
Channel Layout و Color Conversion


M3


CHAPTER SUMMARY

خلاصه فصل

  • Channel مفهوم رنگی است، اما Plane ساختار حافظه‌ای است.
  • در Packed Format مؤلفه‌ها در یک Plane Interleaved هستند.
  • در Planar Format مؤلفه‌ها در Planeهای مستقل قرار می‌گیرند.
  • Semi-Planar ترکیبی از Plane مستقل و Channelهای Interleaved است.
  • NV12 دارای Y Plane و UV Plane است؛ NV21 ترتیب VU دارد.
  • P010 داده ده‌بیتی را معمولاً در عنصر شانزده‌بیتی نگهداری می‌کند.
  • هر Plane می‌تواند Base Address، Pitch و ابعاد مستقل داشته باشد.

واژه‌نامه فصل

Packedذخیره Channelها به‌صورت Interleaved در یک Plane.
Planarذخیره مؤلفه‌ها در Planeهای مستقل.
Semi-Planarترکیب Plane مستقل و Channelهای Interleaved.
Planeناحیه مستقل حافظه برای یک یا چند Channel.
Interleavedقرارگیری متناوب چند مؤلفه در یک Stream حافظه.
NV12فرمت YUV 4:2:0 هشت‌بیتی با Y Plane و UV Plane.
P010فرمت Semi-Planar ده‌بیتی با Storage شانزده‌بیتی.

فصل بعد

GPU MEMORY ARCHITECTURE

Tiled Image Layout

بررسی تقسیم تصویر به Tileهای کوچک، تفاوت چیدمان
خطی و دوبعدی، اثر Tile بر Cache Locality، Texture
Sampling، Rendering و کاهش ترافیک حافظه در GPU.


سطح فصل


پیشرفته


زمان مطالعه


حدود ۲۰ دقیقه


موضوع


GPU Image Memory Layout


نسخه


v1.0

پیش‌نیازهای فصل

  • شناخت Linear Layout
  • آشنایی با Pitch و Alignment
  • درک Cache Line و Spatial Locality

در این فصل یاد می‌گیرید

  • Tile چیست و چگونه در حافظه قرار می‌گیرد
  • چرا GPU چیدمان دوبعدی را ترجیح می‌دهد
  • Tile Size چگونه بر Cache اثر می‌گذارد
  • چرا دسترسی CPU به Tiled Image دشوارتر است

نقشه مفهومی فصل
Tiled Image Layout
Tile
Locality
Cache Line
Sampling
Rendering
Memory Traffic

Tiled Layout چیست؟

در Tiled Layout تصویر به بلوک‌های کوچک دوبعدی تقسیم
می‌شود و Pixelهای هر Tile نزدیک یکدیگر در حافظه قرار
می‌گیرند.

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

تفاوت Linear و Tiled Layout

در Layout خطی، مجاورت حافظه عمدتاً افقی است؛ اما در
Tiled Layout، همسایگی افقی و عمودی داخل Tile بهتر حفظ
می‌شود.

چرا GPU از Tile استفاده می‌کند؟

بسیاری از عملیات تصویری به Pixelهای همسایه نیاز دارند.
Sampling، Blur، Scaling، Depth Test و Rendering معمولاً
تنها یک Pixel منفرد را نمی‌خوانند.

اگر همسایه‌های دوبعدی در حافظه نزدیک باشند، GPU می‌تواند
با تعداد Cache Line و Transaction کمتر به آن‌ها دسترسی
پیدا کند.

مزایای اصلی Tiled Layout
مزیت نتیجه
Locality دوبعدی دسترسی سریع‌تر به Pixelهای مجاور
Cache Hit بیشتر کاهش مراجعه مستقیم به VRAM
Transaction منظم‌تر استفاده بهتر از Memory Bus
مناسب Rendering پردازش Blockهای کوچک تصویر
مناسب Sampling دسترسی مؤثر به همسایگی دوبعدی

ساختار یک Tile

Tile معمولاً یک ناحیه مستطیلی از Pixelهاست. اندازه دقیق
آن به معماری GPU، Format، نوع Resource و Layout بستگی
دارد.

این Pixelها ممکن است در حافظه به ترتیب خطی داخل همان
Tile قرار گیرند یا از Swizzle داخلی استفاده کنند.

Tile Size

Tile Size ممکن است برحسب Pixel، Sample، Byte یا Block
تعریف شود.

اندازه Tile ثابت و عمومی نیست. یک GPU ممکن است برای
Color Buffer، Depth Buffer و Video Surface از Tileهای
متفاوت استفاده کند.

عوامل تعیین‌کننده اندازه Tile
عامل اثر
Bytes Per Pixel تغییر تعداد Pixel قابل نگهداری در Tile
Pixel Format تفاوت Packed، Planar و Compressed
Cache Line Size هماهنگی Tile با Transaction حافظه
Resource Type تفاوت Texture، Depth و Render Target
GPU Architecture تفاوت Layout میان سازندگان و نسل‌ها

آدرس‌دهی Pixel در Tiled Layout

در Layout خطی، آدرس Pixel با Pitch و Offset افقی محاسبه
می‌شود؛ اما در Layout کاشی‌بندی‌شده ابتدا باید Tile
شامل Pixel مشخص شود.

مرحله پنجم ممکن است ساده، Block-Linear، Swizzled یا
وابسته به معماری باشد.

محاسبه Tile Index

در ساده‌ترین مدل، Tileها به‌صورت ردیفی شماره‌گذاری
می‌شوند.

اثر Tile بر Cache Locality

فرض کنید یک فیلتر برای هر Pixel، همسایه بالا، پایین،
چپ و راست را بخواند.

در Linear Layout، همسایه عمودی ممکن است یک Pitch کامل
دورتر باشد؛ اما در Tiled Layout احتمال بیشتری دارد که
داخل همان Tile یا Cache Line نزدیک قرار گیرد.

رفتار Locality در دو Layout
نوع دسترسی Linear Tiled
همسایه افقی معمولاً نزدیک نزدیک
همسایه عمودی ممکن است دور باشد اغلب داخل Tile نزدیک است
بلوک دوبعدی Cache Lineهای بیشتر Cache Lineهای کمتر
دسترسی سطر کامل بسیار مناسب ممکن است پیچیده‌تر باشد

مثال فیلتر همسایگی

Blur، Sharpen، Edge Detection و بسیاری از عملیات Spatial
چنین الگویی دارند و از Locality دوبعدی سود می‌برند.

Tiled Layout و Texture Sampling

Bilinear Sampling برای تولید یک Sample معمولاً چند Pixel
مجاور را می‌خواند.

Bicubic و Anisotropic Sampling ممکن است ناحیه بزرگ‌تری
را بررسی کنند. چیدمان Tiled دسترسی به این همسایه‌ها را
برای Texture Unit مؤثرتر می‌کند.

Tiled Layout در Render Target

هنگام Rendering، Pixelهای نزدیک صفحه معمولاً در بازه
زمانی مشابه تولید یا به‌روزرسانی می‌شوند.

نگهداری آن‌ها در Tileهای مشترک باعث می‌شود عملیات Blend،
Depth Test، Color Write و Resolve با ترافیک حافظه کمتری
انجام شوند.

Depth و Stencil Tiling

Depth Buffer و Stencil Buffer نیز معمولاً از Layoutهای
Tiled استفاده می‌کنند.

دلیل آن این است که تست عمق برای بلوک‌های نزدیک Pixelها
انجام می‌شود و دسترسی دوبعدی منظم اهمیت زیادی دارد.

مزایای Tiling برای Depth و Stencil
مزیت نتیجه
دسترسی Block-Based تست سریع‌تر نواحی نزدیک
Compression بهتر کاهش ترافیک Depth Buffer
Early-Z ردکردن Pixelهای پنهان زودتر
Cache Reuse استفاده دوباره از داده همان Tile

Tile Boundary

وقتی یک عملیات به Pixelهایی در دو Tile متفاوت نیاز داشته
باشد، GPU ممکن است مجبور شود Cache Line یا Tile دیگری
را نیز بارگذاری کند.

طراحی Tile Size و Cache تلاش می‌کند هزینه این مرزها را
محدود کند، اما آن را کاملاً حذف نمی‌کند.

Partial Tile

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

Driver یا سخت‌افزار ممکن است فضای اضافی برای تکمیل
Alignment Tile رزرو کند.

اندازه Allocation در Tiled Layout

اندازه واقعی Resource ممکن است از حاصل‌ضرب ساده Width،
Height و Bytes Per Pixel بیشتر باشد.

Padding سطر، Padding Tile، Metadata، Compression Surface
و Alignment کلی Allocation می‌توانند فضای بیشتری مصرف
کنند.

اجزای احتمالی Allocation
بخش توضیح
Pixel Data داده اصلی تصویر
Tile Padding فضای تکمیل Tileهای لبه
Row Alignment هماهنگی ردیف Tileها
Compression Metadata اطلاعات فشرده‌سازی سطحی
Allocation Alignment هم‌ترازی کل Resource

دسترسی CPU به تصویر Tiled

CPU معمولاً انتظار دارد تصویر به‌صورت Linear و با Pitch
مشخص در حافظه قرار گرفته باشد.

اگر Resource دارای Layout اختصاصی GPU باشد، CPU نمی‌تواند
همیشه Byteها را مستقیماً به‌عنوان سطرهای تصویر تفسیر کند.

در این حالت معمولاً Resource باید به Staging Buffer خطی
کپی یا Resolve شود.

Display Engine و Layout تصویر

Display Engine تنها Layoutهایی را می‌تواند مستقیماً
Scanout کند که سخت‌افزار و Driver پشتیبانی کنند.

بعضی Surfaceها باید پیش از نمایش Resolve، Convert یا به
Layout سازگار با Scanout منتقل شوند.

Tiling در Video Surface

Surfaceهای Decode و Encode نیز ممکن است از Layoutهای
Tiled یا Block-Based اختصاصی استفاده کنند.

Video Engine، Shader و Encoder باید برای Zero-Copy از
Layout و Modifier سازگار استفاده کنند.

ارتباط Tiling و Compression

بسیاری از فناوری‌های فشرده‌سازی Frame Buffer یا Color
Surface بر پایه Blockها و Tileها عمل می‌کنند.

اگر یک Tile دارای رنگ یا الگوی قابل پیش‌بینی باشد، ممکن
است به‌جای ذخیره تمام Pixelها، Metadata فشرده‌تری ذخیره
شود.

Layout Modifier چیست؟

در بعضی APIها و سیستم‌عامل‌ها، Pixel Format به‌تنهایی
برای توصیف Resource کافی نیست.

Modifier اطلاعاتی مانند Tiling، Compression و سازمان‌دهی
اختصاصی حافظه را مشخص می‌کند.

تفاوت Format و Modifier
ویژگی Format Modifier
مؤلفه‌های رنگ مشخص می‌کند معمولاً خیر
Bit Depth مشخص می‌کند خیر
Tiling همیشه کافی نیست مشخص می‌کند
Compression معمولاً مشخص نمی‌کند ممکن است مشخص کند
Vendor Layout خیر بله

اشتباهات رایج

خطاهای متداول در تفسیر Tiled Resource
اشتباه پیامد علت
تفسیر مستقیم به‌عنوان Linear تصویر کاملاً خراب نادیده‌گرفتن Tile Addressing
محاسبه اندازه با Width × Height Allocation ناکافی نادیده‌گرفتن Padding و Metadata
یکسان فرض‌کردن Layout سازندگان ناسازگاری Resource وابستگی Tiling به معماری
اشتراک فقط بر اساس Format خطای Import یا نمایش نادرست نادیده‌گرفتن Modifier
CPU Mapping مستقیم داده غیرقابل تفسیر نبود Staging یا Detiling


PERFORMANCE IMPACT

اثر Tiled Layout بر عملکرد

Cache Locality
بسیار زیاد
Texture Sampling
بسیار زیاد
Memory Bandwidth
زیاد
CPU Accessibility
کمتر


API MAPPING

Tiled Layout در APIهای مختلف

Vulkan
Optimal Tiling و Linear Tiling
Direct3D 12
Texture Layout و Tiled Resources
OpenGL
Layout داخلی مدیریت‌شده توسط Driver
Metal
Private Texture و Storage Mode
DRM / Linux
Format Modifier و DMA-BUF
CUDA
CUDA Array و Texture / Surface Object


M4


CHAPTER SUMMARY

خلاصه فصل

  • Tiled Layout تصویر را به بلوک‌های دوبعدی کوچک تقسیم می‌کند.
  • Pixelهای نزدیک دوبعدی در حافظه نزدیک‌تر قرار می‌گیرند.
  • Tiling باعث افزایش Cache Hit و کاهش ترافیک VRAM می‌شود.
  • Tile Size به Format، معماری و نوع Resource وابسته است.
  • CPU معمولاً برای خواندن Tiled Image به Staging Buffer نیاز دارد.
  • Format یکسان به معنی Layout یا Modifier یکسان نیست.
  • Compression و Render Targetها معمولاً ارتباط نزدیکی با Tiling دارند.

واژه‌نامه فصل

Tileبلوک دوبعدی کوچک از Pixelها یا Sampleها.
Tiled Layoutچیدمان تصویر بر اساس Tileهای دوبعدی.
Tile Boundaryمرز میان دو Tile مجاور.
Partial TileTile ناقص در لبه Resource.
Detilingتبدیل Layout کاشی‌بندی‌شده به Layout خطی.
Modifierتوصیف تکمیلی Layout، Tiling یا Compression.

فصل بعد

GPU MEMORY ARCHITECTURE

Block Linear Layout

بررسی چیدمان سلسله‌مراتبی تصویر در Blockهای حافظه،
مفهوم GOB و Block Height، تفاوت Block Linear با
Tiled ساده و نقش این Layout در Texture، Video Surface،
Decode، Encode و مسیرهای Zero-Copy.


سطح فصل


پیشرفته


زمان مطالعه


حدود ۲۲ دقیقه


موضوع


Hierarchical Image Layout


نسخه


v1.0

پیش‌نیازهای فصل

  • شناخت Linear و Tiled Layout
  • آشنایی با Pitch و Alignment
  • درک Cache Line و Locality دوبعدی
  • شناخت Planeهای فرمت‌های ویدئویی

در این فصل یاد می‌گیرید

  • Block Linear چه تفاوتی با Tiled ساده دارد
  • GOB و Block Height چه نقشی دارند
  • چرا آدرس‌دهی آن سلسله‌مراتبی است
  • چرا Layout دقیق نباید از روی Format حدس زده شود

نقشه مفهومی فصل
Block Linear Layout
GOB
Block Height
Block Address
Cache Locality
Video Surface
Interoperability

Block Linear Layout چیست؟

Block Linear نوعی Layout کاشی‌بندی‌شده و سلسله‌مراتبی
است که تصویر را ابتدا به Blockهای دوبعدی تقسیم می‌کند
و سپس داده‌های هر Block را با ترتیب داخلی مشخصی در
حافظه قرار می‌دهد.

برخلاف Linear Layout، یک سطر کامل تصویر الزاماً به‌صورت
پیوسته در حافظه قرار ندارد. بخشی از سطر در یک Block و
بخش بعدی آن در Block دیگری ذخیره می‌شود.

مقایسه Linear، Tiled و Block Linear

تفاوت ساختارهای اصلی حافظه تصویر
معیار Linear Tiled Block Linear
چیدمان اصلی سطر به سطر Tileهای دوبعدی Blockهای دارای زیرساختار داخلی
آدرس‌دهی ساده بر اساس Tile سلسله‌مراتبی
Locality دوبعدی محدود زیاد زیاد و معماری‌محور
دسترسی مستقیم CPU آسان محدود معمولاً نامناسب
کاربرد رایج Staging و CPU Mapping Texture و Rendering Surfaceهای بهینه GPU و Video Engine

ساختار سلسله‌مراتبی

در یک مدل ساده، تصویر ابتدا به Blockهای بزرگ‌تر و هر
Block به واحدهای کوچک‌تر تقسیم می‌شود.

نام، اندازه و ترتیب دقیق این لایه‌ها به معماری، نسل GPU،
Pixel Format و نوع Resource وابسته است.

GOB یا Group of Bytes

در برخی مستندات معماری NVIDIA، واحدهای داخلی Block Linear
با عنوان
Group of Bytes یا GOB
توصیف می‌شوند.

GOB را می‌توان یک واحد کوچک سازمان‌دهی حافظه دانست که
چندین Sample یا Pixel را در یک ساختار دوبعدی داخلی
گروه‌بندی می‌کند.

نمایش مفهومی GOB

Block Height چیست؟

Block Height مشخص می‌کند چند واحد داخلی مانند GOB در
جهت عمودی برای تشکیل یک Block بزرگ‌تر گروه‌بندی شوند.

افزایش Block Height باعث بلندترشدن ناحیه دوبعدی هر Block
می‌شود و نحوه حرکت از یک Block به Block بعدی را تغییر
می‌دهد.

اثر Block Height

نتایج تغییر Block Height
ویژگی Block کوتاه‌تر Block بلندتر
ناحیه دوبعدی Block کوچک‌تر بزرگ‌تر
تعداد Blockهای عمودی بیشتر کمتر
Padding لبه ممکن است کمتر باشد ممکن است بیشتر شود
Locality مناسب نواحی کوچک‌تر مناسب دسترسی عمودی گسترده‌تر
آدرس‌دهی وابسته به Blockهای بیشتر وابسته به زیرواحدهای بیشتر در هر Block

آدرس‌دهی در Block Linear

برای یافتن آدرس یک Pixel، تنها استفاده از Row Pitch
کافی نیست. ابتدا باید Block شامل Pixel، سپس واحد داخلی
Block و در نهایت Offset محلی Sample تعیین شود.

فرمول دقیق آدرس‌دهی باید از API، Driver یا مستندات
همان پلتفرم دریافت شود.

مدل مفهومی محاسبه آدرس

این رابطه فقط ساختار منطقی محاسبه را نشان می‌دهد و
جایگزین فرمول اختصاصی سخت‌افزار نیست.

مفهوم Pitch در Block Linear

در Block Linear ممکن است مقداری با عنوان Pitch یا
Stride وجود داشته باشد، اما این مقدار الزاماً فاصله
مستقیم میان دو سطر Pixel نیست.

Pitch می‌تواند فاصله میان ردیف‌های Block، پهنای
Allocation هم‌تراز یا پارامتری برای محاسبه آدرس داخلی
باشد.

Layout مستقل Planeها

در Surfaceهای چند Plane مانند NV12 یا P010، هر Plane
می‌تواند ابعاد، Offset، Pitch، Alignment و Block Height
مستقل داشته باشد.

ویژگی‌های مستقل هر Plane
ویژگی Y Plane UV Plane
Resolution کامل وابسته به Subsampling
Base Offset مستقل مستقل
Pitch ممکن است متفاوت باشد ممکن است متفاوت باشد
Block Height وابسته به Allocation می‌تواند متفاوت باشد
Padding مستقل مستقل

Block Linear در Pipeline ویدئو

Video Decoder می‌تواند Frame را مستقیماً در Surface
بهینه GPU تولید کند. سپس Video Processor، Compute
Shader یا Encoder همان Surface را مصرف می‌کنند.

این مسیر زمانی Zero-Copy باقی می‌ماند که تمام واحدها
Format و Layout واقعی Surface را پشتیبانی کنند.

تبدیل Block Linear و Pitch Linear

برای دسترسی مستقیم CPU، ذخیره فایل یا استفاده در
نرم‌افزاری که Layout اختصاصی GPU را نمی‌شناسد، معمولاً
باید Surface به Layout خطی تبدیل شود.

این تبدیل ممکن است Detiling، تغییر Alignment یا
تبدیل Pixel Format را نیز شامل شود.

Block Linear و Zero-Copy

اشتراک یک Buffer تنها با انتقال Handle حافظه کامل
نمی‌شود. مصرف‌کننده باید اطلاعات Layout، Planeها،
Offsetها، Pitchها و Modifierهای Resource را نیز دریافت
کند.

دسترسی CPU

Block Linear برای الگوی دسترسی GPU طراحی شده و معمولاً
برای پیمایش مستقیم سطر‌به‌سطر توسط CPU مناسب نیست.

حتی اگر CPU بتواند Allocation را Map کند، داده خام
الزاماً شکل قابل‌مشاهده تصویر را ندارد.

روش‌های دسترسی CPU به Surface
روش وضعیت
Map مستقیم تنها در صورت پشتیبانی و شناخت Layout
Copy به Staging Buffer روش رایج و قابل‌اعتماد
GPU Detiling تبدیل سریع‌تر با Engine یا Shader
Software Detiling پیچیده و وابسته به جزئیات معماری

اندازه واقعی Allocation

اندازه Block Linear Resource از اندازه منطقی تصویر
بیشتر است؛ زیرا عرض، ارتفاع، Planeها و Blockها باید
بر اساس محدودیت‌های سخت‌افزار Align شوند.

عوامل افزایش اندازه Allocation
عامل اثر
Block Padding تکمیل Blockهای لبه تصویر
Plane Alignment هم‌ترازی شروع هر Plane
Block Height گردکردن ارتفاع Plane
Metadata اطلاعات Compression یا Surface
Allocation Alignment هم‌ترازی کل حافظه

اشتباهات رایج

خطاهای متداول در کار با Block Linear
اشتباه پیامد راه صحیح
تفسیر به‌عنوان Linear تصویر کاملاً درهم‌ریخته استفاده از Copy یا Layout Metadata
حدس Block Height آدرس‌دهی نادرست دریافت مقدار از API یا Driver
یکسان‌فرض‌کردن Planeها خرابی Chroma بررسی مستقل هر Plane
اشتراک تنها با Pixel Format ناسازگاری Interop انتقال Modifier و Layout
محاسبه ساده اندازه Buffer Allocation ناکافی استفاده از اندازه اعلام‌شده API


PERFORMANCE IMPACT

اثر Block Linear بر عملکرد

GPU Locality
بسیار زیاد
Video Throughput
زیاد
Zero-Copy Potential
بسیار زیاد
CPU Accessibility
کم


API MAPPING

Block Linear در APIها و Frameworkها

NvMedia
Surface Layout و Video Surface
NvSciBuf
Image Attributes و Plane Layout
CUDA
Array، Surface و External Memory Interop
EGL
Image Interoperability میان Engineها
DRM / DMA-BUF
Format Modifier و Buffer Sharing
V4L2
Multi-Planar Video Buffer و Memory Type


M5


CHAPTER SUMMARY

خلاصه فصل

  • Block Linear یک Layout دوبعدی و سلسله‌مراتبی است.
  • داده داخل Blockها و واحدهای کوچک‌تر سازمان‌دهی می‌شود.
  • Block Height آرایش عمودی واحدهای داخلی Block را کنترل می‌کند.
  • Pitch در این Layout الزاماً فاصله دو سطر Pixel نیست.
  • Planeهای یک Surface می‌توانند Layout مستقل داشته باشند.
  • CPU معمولاً برای خواندن Surface به تبدیل Pitch Linear نیاز دارد.
  • Zero-Copy به سازگاری Format، Layout و Metadata وابسته است.

واژه‌نامه فصل

Block Linearچیدمان سلسله‌مراتبی داده در Blockهای دوبعدی.
GOBواحد داخلی گروه‌بندی Byteها در برخی معماری‌ها.
Block Heightتعداد واحدهای عمودی تشکیل‌دهنده یک Block.
Pitch Linearچیدمان سطر‌به‌سطر همراه با Pitch مشخص.
Detilingتبدیل Layout بلوکی یا Tiled به Layout خطی.
Surface Metadataاطلاعات لازم برای تفسیر Format و Layout حافظه.

فصل بعد

GPU MEMORY ARCHITECTURE

Swizzled Image Layout

بررسی تکنیک Swizzling، مفهوم Morton (Z-Order)،
نحوه جابه‌جایی بیت‌های مختصات، حفظ Spatial Locality،
تفاوت آن با Tiled و Block Linear و تأثیر آن بر
Texture Cache و Sampling.

نقشه مفهومی فصل
Swizzled Layout
Morton Order
Bit Interleaving
Locality
Texture Cache
Sampling
GPU Memory

Swizzling چیست؟

Swizzling روشی برای سازمان‌دهی حافظه است که در آن
ترتیب ذخیره Pixelها از ترتیب معمول سطر به سطر
(Linear) پیروی نمی‌کند.

هدف این روش نزدیک نگه داشتن Pixelهایی است که
در فضای دوبعدی تصویر به یکدیگر نزدیک هستند.

چرا Swizzle استفاده می‌شود؟

هنگام Texture Sampling،
GPU معمولاً فقط یک Pixel را
نمی‌خواند.

Bilinear،
Trilinear،
Anisotropic،
Blur،
Shadow Sampling
و بسیاری از الگوریتم‌ها
چندین Pixel همسایه را
به صورت همزمان نیاز دارند.

اگر این Pixelها در حافظه
نیز نزدیک باشند،
تعداد Cache Miss
به شدت کاهش پیدا می‌کند.

مقایسه Linear و Swizzled



Linear

A B C D
E F G H
I J K L
M N O P


Memory

A B C D E F G H I J K L ...


Swizzled

A B
E F

C D
G H

I J
M N

K L
O P

در Swizzle،
همسایگی دوبعدی
اهمیت بیشتری از
ترتیب خطی حافظه دارد.

Morton Order (Z-Order)

مشهورترین الگوریتم Swizzle،
Morton Order
یا Z-Order Curve است.

در این روش
بیت‌های X و Y
در هم تنیده
(Interleave)
می‌شوند.



X = x2 x1 x0

Y = y2 y1 y0


Morton Index

y2 x2 y1 x1 y0 x0

این کار باعث می‌شود
Pixelهای مجاور
معمولاً آدرس‌های نزدیک‌تری
داشته باشند.

Spatial Locality

Spatial Locality
یعنی داده‌هایی که
در فضای تصویر
به یکدیگر نزدیک‌اند،
در حافظه نیز
فاصله کمی داشته باشند.

Swizzle
دقیقاً برای
بهبود همین ویژگی
طراحی شده است.

تفاوت Swizzle و Tile

ویژگی Tiled Swizzled
واحد اصلی Tile Bit Mapping
آدرس‌دهی Tile سپس Offset Interleaved Bits
Locality زیاد بسیار زیاد
پیچیدگی کمتر بیشتر

تفاوت Swizzle و Block Linear

Block Linear
معمولاً ابتدا تصویر را
به Block تقسیم می‌کند
و سپس داخل هر Block
آرایش خاصی دارد.

اما Swizzle
معمولاً نگاشت مختصات
را مستقیماً تغییر می‌دهد.

اثر بر Texture Cache

هنگام Bilinear Sampling،
چهار Pixel مجاور
اغلب داخل همان
Cache Line
قرار می‌گیرند.

بنابراین تعداد Transaction
حافظه کاهش پیدا می‌کند.

اشتباهات رایج

اشتباه پیامد
فرض کردن Swizzle
مانند Linear
تصویر خراب می‌شود.
یکسان فرض کردن
همه GPUها
عدم سازگاری
نادیده گرفتن
Layout Modifier
شکست Interop


UNDER THE HOOD

Swizzle در داخل GPU چگونه عمل می‌کند؟

برنامه‌نویس معمولاً یک Texture یا Image منطقی می‌بیند؛
اما GPU باید مختصات دوبعدی را به آدرس واقعی حافظه تبدیل
کند. این تبدیل ممکن است شامل Tile، Swizzle، Bit
Interleaving، Bank Selection و محاسبه Offset داخلی باشد.


01

Behind the Abstraction

APIهایی مانند Vulkan و Direct3D معمولاً جزئیات کامل
ترتیب Byteها را پنهان می‌کنند. برنامه فقط Image،
Format، Usage و Layout منطقی را تعیین می‌کند و Driver
سازمان‌دهی فیزیکی مناسب را انتخاب می‌کند.


02

Address Generation

Texture Unit مختصات X و Y را دریافت کرده و با استفاده
از منطق Address Generator، Tile، Block و Offset داخلی
Sample را محاسبه می‌کند.


03

چرا Morton خالص همیشه استفاده نمی‌شود؟

Morton Order دوبعدی Locality مناسبی دارد، اما الزاماً
با ساختار Memory Channel، Cache Line، Compression Block
یا Burst سخت‌افزار هماهنگ نیست.

به همین دلیل GPU ممکن است از Morton اصلاح‌شده، Swizzle
چندمرحله‌ای یا ترکیب Tile و Bit Mapping استفاده کند.


04

Cache Line Mapping

هدف فقط نزدیک‌کردن Pixelها نیست؛ داده باید به شکلی
توزیع شود که Texture Unit بتواند یک ناحیه دوبعدی را
با تعداد کمی Cache Line و Transaction حافظه دریافت
کند.

رابطه الگوی دسترسی با Swizzle
الگوی دسترسی هدف Layout
Bilinear Sampling قرارگیری چهار Sample نزدیک یکدیگر
Mipmap Sampling دسترسی سریع به سطح و Tile مناسب
Anisotropic Sampling کاهش Transaction برای مسیر گسترده‌تر
Render Target Write گروه‌بندی Pixelهای مجاور در Block

05

تعامل با Compression

Swizzle باید با اندازه Blockهای فشرده‌سازی هماهنگ
باشد. اگر Metadata و Pixel Data از Layoutهای متفاوتی
استفاده کنند، Address Generator باید هر دو ساختار را
هم‌زمان مدیریت کند.


06

Practical Impact

  • Buffer اشتراکی باید Modifier صحیح داشته باشد.
  • Map کردن حافظه به معنی Linear بودن داده نیست.
  • Detiling نرم‌افزاری به اطلاعات معماری نیاز دارد.
  • تبدیل Layout ممکن است از تبدیل Format پرهزینه‌تر باشد.
  • Zero-Copy بدون توافق روی Layout کامل نیست.

M7

GPU MEMORY ARCHITECTURE


Frame Buffer Compression و Compression Layout

بررسی فشرده‌سازی داخلی Surfaceهای GPU، تفاوت آن با
Codecهای ویدئویی، نقش Metadata، فشرده‌سازی Color و
Depth، اثر آن بر پهنای باند حافظه و شرایطی که باعث
Resolve یا Decompression یک Resource می‌شوند.


سطح فصل


پیشرفته

زمان مطالعه


حدود ۲۵ دقیقه

موضوع


Memory Bandwidth Optimization

نسخه


v1.0


پیش‌نیازهای فصل

  • شناخت Tiled و Block Linear Layout
  • آشنایی با Cache و Memory Bandwidth
  • درک Frame Buffer و Render Target
  • شناخت Pixel Format و Plane


در این فصل یاد می‌گیرید

  • Frame Buffer Compression چیست
  • چرا با Video Codec متفاوت است
  • Metadata Surface چه نقشی دارد
  • چه زمانی Resource باید Resolve شود
  • Compression چگونه پهنای باند را کاهش می‌دهد

نقشه مفهومی فصل
Frame Buffer Compression
Pixel Data
Metadata
Compression Block

Bandwidth
Resolve
Interoperability

Frame Buffer Compression چیست؟

Frame Buffer Compression روشی برای کاهش مقدار داده‌ای
است که میان GPU، Cache و VRAM جابه‌جا می‌شود.

GPU به‌جای نوشتن و خواندن تمام Byteهای یک Tile، تلاش
می‌کند الگوی آن Tile را با داده کمتر و Metadata مناسب
نمایش دهد.

تفاوت Frame Buffer Compression و Video Codec

مقایسه فشرده‌سازی حافظه GPU و Codec ویدئویی
معیار Frame Buffer Compression Video Codec
هدف کاهش ترافیک داخلی حافظه کاهش حجم فایل یا Bitstream
محل استفاده داخل GPU و VRAM ذخیره‌سازی و انتقال ویدئو
Latency بسیار پایین بیشتر و وابسته به Codec
نوع فشرده‌سازی معمولاً Lossless اغلب Lossy یا ترکیبی
خروجی قابل حمل معمولاً خیر بله
وابستگی به GPU زیاد مبتنی بر استاندارد Codec

مسیر داده در یک Surface فشرده

هنگام خواندن Resource، سخت‌افزار Metadata را بررسی
می‌کند تا مشخص شود Tile به‌صورت فشرده، یکنواخت یا کامل
ذخیره شده است.

Compression Block

فشرده‌سازی معمولاً روی گروهی از Pixelها یا Sampleها
انجام می‌شود، نه روی کل تصویر به‌صورت یکجا.

این گروه می‌تواند با Tile، Cache Block یا واحد داخلی
Memory Controller هماهنگ باشد.

Color Compression

Color Compression برای Render Targetها، Textureها و
Frame Bufferهای رنگی استفاده می‌شود.

اگر Pixelهای یک Block مشابه یا قابل پیش‌بینی باشند،
GPU می‌تواند آن‌ها را با Base Color، Deltaها یا یک حالت
خاص مانند Uniform Block نمایش دهد.

Delta Color Compression

در Delta Color Compression، سخت‌افزار یک مقدار پایه
برای Block انتخاب می‌کند و تفاوت Pixelهای دیگر نسبت به
آن را ذخیره می‌کند.

اگر Deltaها کوچک باشند، تعداد Bit کمتری برای ذخیره
Block لازم خواهد بود.

Fast Clear و Clear Color

هنگام پاک‌کردن یک Render Target، GPU ممکن است به‌جای
نوشتن رنگ جدید در تمام Pixelها، تنها Metadata آن Surface
را به‌روزرسانی کند.

در خواندن بعدی، سخت‌افزار می‌داند که آن Block باید مانند
یک ناحیه یکنواخت با Clear Color تفسیر شود.

Depth و Stencil Compression

Depth Bufferها نیز معمولاً فشرده می‌شوند، زیرا مقادیر
عمق در نواحی مجاور اغلب رابطه قابل پیش‌بینی دارند.

مزایای فشرده‌سازی Depth و Stencil
اثر نتیجه
ترافیک کمتر کاهش خواندن و نوشتن Depth
Early-Z مؤثرتر رد سریع‌تر Geometry پنهان
Cache Hit بیشتر نگهداری Blockهای بیشتری در Cache
Fast Clear پاک‌سازی سریع Depth Buffer

Metadata Surface چیست؟

Metadata Surface ناحیه‌ای جدا یا همراه Resource است که
وضعیت فشرده‌سازی Blockها را نگهداری می‌کند.

اطلاعات احتمالی Metadata
اطلاعات کاربرد
Compression State فشرده یا Uncompressed بودن Block
Clear State استفاده از Clear Color
Compression Mode روش تفسیر Block
Base / Delta Data بازسازی Pixelهای فشرده
Validity معتبر بودن Metadata

Resolve و Decompression

اگر Engine یا دستگاه مقصد نتواند Layout فشرده را مستقیماً
مصرف کند، Resource باید به حالت سازگار تبدیل شود.

این عملیات ممکن است Resolve، Decompress، Expand یا
Materialize نامیده شود.

چه زمانی Resolve لازم می‌شود؟

دلایل رایج Resolve شدن Resource
وضعیت علت
CPU Readback CPU Layout فشرده را نمی‌شناسد
API Interop مصرف‌کننده Modifier را پشتیبانی نمی‌کند
Display Scanout Display Engine Layout را نمی‌پذیرد
Video Encode Encoder به Surface سازگار دیگری نیاز دارد
Copy خاص Copy Engine قادر به حفظ Compression نیست
Partial Update تغییر Block با حالت فشرده فعلی ناسازگار است

تغییر وضعیت Compression

Driver و Command Processor باید این تغییر وضعیت‌ها را
با Barrier و Metadata Update مناسب مدیریت کنند.

Compression و Zero-Copy

یک Surface فشرده تنها زمانی می‌تواند بدون Copy میان
Engineها یا APIها به اشتراک گذاشته شود که تمام طرف‌ها
Format، Modifier، Compression State و Metadata آن را
پشتیبانی کنند.


PERFORMANCE IMPACT

اثر Frame Buffer Compression بر عملکرد

Memory Bandwidth
بسیار زیاد

Power Efficiency
زیاد

Cache Capacity
زیاد

Interop Complexity
بسیار زیاد


API MAPPING

Compression Surface در APIها

Vulkan

Image Tiling، Layout Transition و Modifier
Direct3D 12

Resource State، Render Target و Resolve
DRM / DMA-BUF

Format Modifier و اشتراک Layout
Metal

Private Texture و مدیریت داخلی Compression
CUDA Interop

External Memory و Array-Compatible Resource
Display Pipeline

Scanout Modifier و Plane Compatibility


UNDER THE HOOD

سخت‌افزار چگونه Surface فشرده را مدیریت می‌کند؟

Shader معمولاً تفاوتی میان Pixel فشرده و غیر‌فشرده
مشاهده نمی‌کند. Cache Controller و Compression Unit
جزئیات بازسازی یا ذخیره Block را در پشت صحنه انجام
می‌دهند.


01

Behind the Abstraction

برنامه یک Image یا Render Target می‌بیند، اما
Driver ممکن است علاوه بر Pixel Data، Allocation
دیگری برای Metadata و State Tracking ایجاد کند.


02

Read Path

Texture Request
      │
      ▼
Metadata Lookup
      │
      ├── Uncompressed ─► Read Pixels
      │
      └── Compressed ───► Decode Block
                              │
                              ▼
                           Cache


03

Write Path

هنگام پایان Write، سخت‌افزار بررسی می‌کند که آیا
Block با یکی از حالت‌های Compression قابل نمایش
است یا باید به‌صورت کامل نوشته شود.


04

Why This Design?

انتقال داده از VRAM یکی از پرهزینه‌ترین عملیات
GPU است. افزودن منطق Compression می‌تواند از نظر
انرژی و پهنای باند بسیار ارزان‌تر از افزایش دائمی
Memory Bus باشد.


05

Hidden Resolve

Profiler ممکن است عملیات Resolve یا Copy پنهانی
را نشان دهد که هنگام تغییر Usage، Export یا
دسترسی Engine ناسازگار ایجاد شده است.


06

Practical Impact

  • Resource Stateها را دقیق مدیریت کنید.
  • Modifier را همراه Format منتقل کنید.
  • Copyهای پنهان را با Profiler بررسی کنید.
  • از Mapping مستقیم Surface به CPU پرهیز کنید.
  • Interop را روی سخت‌افزار واقعی آزمایش کنید.

اشتباهات رایج

خطاهای رایج در Resourceهای فشرده
اشتباه پیامد راه صحیح
فرض Lossy بودن برداشت اشتباه از کیفیت تصویر تفکیک Compression داخلی از Codec
نادیده‌گرفتن Metadata تفسیر نادرست Resource انتقال کامل Layout Information
فرض Zero-Copy واقعی Copy یا Resolve پنهان بررسی Timeline و Profiler
CPU Mapping مستقیم داده غیرقابل تفسیر استفاده از Staging Resource
تغییر State نامناسب Decompression اضافی مدیریت دقیق Resource Transition


M7


CHAPTER SUMMARY

خلاصه فصل

  • Frame Buffer Compression برای کاهش ترافیک VRAM
    استفاده می‌شود.
  • این روش با Codecهای ویدئویی متفاوت و معمولاً
    Lossless است.
  • فشرده‌سازی اغلب در سطح Block یا Tile انجام می‌شود.
  • Metadata وضعیت و روش بازسازی Block را نگهداری می‌کند.
  • Fast Clear می‌تواند از نوشتن کامل Surface جلوگیری کند.
  • Engine ناسازگار ممکن است Resource را Resolve کند.
  • Zero-Copy واقعی به پشتیبانی کامل Compression و Modifier
    نیاز دارد.

واژه‌نامه فصل

Frame Buffer Compression
فشرده‌سازی داخلی و کم‌تأخیر Surfaceهای GPU.

Compression Metadata
اطلاعات لازم برای تعیین وضعیت و بازسازی Block فشرده.

Fast Clear
پاک‌سازی Surface با تغییر Metadata به‌جای نوشتن تمام Pixelها.

Resolve
تبدیل Resource به Layout یا حالت قابل استفاده برای مصرف‌کننده.

Delta Compression
ذخیره اختلاف Sampleها نسبت به یک مقدار پایه.

Compression State
وضعیت منطقی یک Block مانند فشرده، Clear یا Expanded.

M8

ENGINEERING REVIEW


مرور مهندسی Image Memory Layoutها

جمع‌بندی و مقایسه Linear، Pitch-Linear، Planar،
Tiled، Block Linear، Swizzled و Compression Layout
با تمرکز بر آدرس‌دهی، Cache Locality، دسترسی CPU،
Zero-Copy، پهنای باند حافظه و انتخاب Layout مناسب
برای کاربردهای واقعی.


سطح فصل


پیشرفته


زمان مطالعه


حدود ۳۰ دقیقه


نوع فصل


Reference و Decision Guide


نسخه


v1.0


پیش‌نیازهای این مرور

  • شناخت Linear و Pitch-Linear Layout
  • درک Plane، Pixel Format و Row Pitch
  • آشنایی با Tile، Block و Swizzle
  • شناخت Compression Metadata و Resolve


پس از این فصل می‌توانید

  • Layout مناسب هر Workload را انتخاب کنید
  • Copy و Resolve پنهان را بهتر تشخیص دهید
  • شرایط واقعی Zero-Copy را ارزیابی کنید
  • مشکلات ناشی از Format و Layout ناسازگار را تحلیل کنید

نقشه کلی تصمیم‌گیری
Image Resource
Format
Layout
Usage

CPU Access
GPU Performance
Interoperability

چرا انتخاب Layout مهم است؟

Pixel Format مشخص می‌کند چه داده‌ای ذخیره می‌شود؛ اما
Memory Layout مشخص می‌کند همان داده چگونه در حافظه
سازمان‌دهی و آدرس‌دهی شود.

ممکن است دو Resource هر دو فرمت NV12 یا RGBA داشته باشند،
اما یکی Linear، دیگری Tiled و سومی دارای Compression
Metadata باشد. این Resourceها از نظر معنای رنگ مشابه‌اند،
ولی از نظر تفسیر حافظه، قابلیت اشتراک و عملکرد یکسان نیستند.

جدول جامع مقایسه Layoutها

مقایسه مهندسی ساختارهای اصلی حافظه تصویر
Layout ساختار اصلی Locality دوبعدی دسترسی CPU کاربرد اصلی
Linear Byteهای پیوسته سطر‌به‌سطر کم بسیار آسان فایل، CPU و Buffer ساده
Pitch-Linear سطرهای دارای Padding کم تا متوسط آسان Staging، Copy و Mapping
Planar Planeهای مستقل وابسته به Layout هر Plane متوسط Video Codec و پردازش Channel
Tiled Tileهای دوبعدی زیاد محدود Texture و Render Target
Block Linear Blockهای سلسله‌مراتبی زیاد ضعیف Video Surface و GPU Engine
Swizzled نگاشت تغییر‌یافته مختصات بسیار زیاد ضعیف Texture Sampling و Cache
Compressed Pixel Data به‌همراه Metadata وابسته به Layout پایه معمولاً غیرمستقیم کاهش Bandwidth و Power

نمای مقایسه‌ای چیدمان‌ها

چه زمانی Linear یا Pitch-Linear انتخاب می‌شود؟

Linear Layout زمانی مناسب است که سادگی آدرس‌دهی، دسترسی
مستقیم CPU یا انتقال سطر‌به‌سطر مهم‌تر از Locality
دوبعدی GPU باشد.

موارد مناسب و نامناسب Linear Layout
سناریو مناسب بودن دلیل
CPU Readback بسیار مناسب پیمایش ساده سطرها
Staging Buffer بسیار مناسب انتقال منظم و قابل پیش‌بینی
File Encoding مناسب سازگار با Bufferهای نرم‌افزاری
Texture Sampling سنگین معمولاً نامناسب Locality عمودی ضعیف‌تر
Render Target پرترافیک معمولاً نامناسب ترافیک حافظه بیشتر

چه زمانی Tiled یا Swizzled مناسب‌تر است؟

زمانی که Workload مرتباً به ناحیه‌های دوبعدی، همسایه‌های
Pixel یا Sampleهای مجاور دسترسی دارد، Layoutهای Tiled و
Swizzled معمولاً عملکرد بهتری دارند.

Workloadهای مناسب Locality دوبعدی
Workload Layout مناسب علت
Bilinear Sampling Tiled یا Swizzled خواندن چند Sample مجاور
Blur و Sharpen Tiled استفاده از Neighborhood
Render Target Tiled و Compressed نوشتن Block-Based
Depth Buffer Tiled و Compressed Early-Z و Locality
Texture Mipmap Swizzled Locality در چند سطح Resolution

انتخاب Layout برای Video Surface

در Pipeline ویدئویی، انتخاب Layout معمولاً فقط بر اساس
سرعت Shader نیست. Decoder، Video Processor، Encoder،
Display Engine و API Interop نیز باید همان Surface را
پشتیبانی کنند.

ماتریس Format و Layout

Pixel Format و Memory Layout باید جداگانه بررسی شوند.
جدول زیر چند ترکیب رایج را نشان می‌دهد.

نمونه ترکیب‌های Format و Layout
Format Layout احتمالی کاربرد
RGBA8 Linear Readback و Upload
RGBA8 Tiled / Compressed Render Target و Texture
NV12 Pitch-Linear CPU Access یا نرم‌افزار ویدئویی
NV12 Block Linear Decode و Encode سخت‌افزاری
P010 Linear یا Block-Based HDR Video Pipeline
Depth Format Tiled و Compressed Depth Test و Early-Z

چک‌لیست واقعی Zero-Copy

وجود یک Allocation مشترک تنها یکی از شروط Zero-Copy
است. همه موارد زیر باید بررسی شوند.

شرایط لازم برای اشتراک واقعی Surface
شرط پرسش کنترلی
Pixel Format آیا همه Engineها Format را می‌پذیرند؟
Plane Layout آیا Planeها، Offsetها و Pitchها شناخته شده‌اند؟
Memory Layout آیا مصرف‌کننده Tiling یا Swizzle را پشتیبانی می‌کند؟
Modifier آیا Modifier دقیق منتقل شده است؟
Compression آیا Metadata و Compression State قابل مصرف‌اند؟
Synchronization آیا Producer و Consumer به‌درستی هماهنگ‌اند؟
Ownership آیا انتقال مالکیت Resource صحیح انجام شده است؟
Profiler Validation آیا Copy یا Resolve پنهان مشاهده نمی‌شود؟

راهنمای سریع انتخاب Layout


PERFORMANCE TRADE-OFFS

مقایسه اثر Layout بر سیستم

CPU Accessibility
Linear

2D Cache Locality
Swizzled

Video Engine Compatibility
Block-Based

Bandwidth Reduction
Compressed

الگوهای رایج خطا

تشخیص مشکلات متداول Layout
نشانه علت احتمالی بررسی لازم
تصویر مورب Pitch اشتباه Row Pitch واقعی
رنگ‌های جابه‌جا Plane یا Channel Order اشتباه Format و Chroma Order
تصویر کاملاً درهم تفسیر Tiled به‌عنوان Linear Modifier و Layout
Copy پنهان Interop ناسازگار Profiler و Resource Transition
Latency ناگهانی Resolve یا Decompression Timeline و Compression State
Crash یا Out-of-Bounds Allocation Size نادرست Plane Size، Alignment و Metadata


API MAPPING

Layout در APIهای مختلف

Vulkan

Linear Tiling، Optimal Tiling، Subresource Layout
و External Memory
Direct3D 12

RowPitch، Texture Resource، Resource State و Resolve
CUDA

Linear Memory، Pitched Memory، Array و Surface Object
FFmpeg

data، linesize و Hardware Frame Context
DRM / DMA-BUF

FourCC، Modifier، Plane Offset و Buffer Sharing
Metal

Texture Storage Mode، bytesPerRow و Private Resource


UNDER THE HOOD

چگونه Driver Layout نهایی را انتخاب می‌کند؟

برنامه معمولاً Usage و محدودیت‌های Resource را تعیین
می‌کند، اما Driver بر اساس معماری GPU، Engineهای
مصرف‌کننده، Alignment، Compression و قابلیت Interop
Layout فیزیکی را انتخاب می‌کند.


01

Usage Analysis

Driver بررسی می‌کند Resource برای Render، Sampling،
Copy، Video، Display یا CPU Mapping استفاده خواهد شد.


02

Capability Intersection

Layout باید در نقطه اشتراک قابلیت Engineهای مختلف
قرار گیرد؛ در غیر این صورت تبدیل یا Resource دوم
لازم خواهد بود.


03

Hidden Allocation

Driver ممکن است برای Metadata، Resolve Target،
Staging یا نسخه سازگار Display حافظه اضافی رزرو کند.


04

Layout Transition

Transition همیشه فقط تغییر وضعیت منطقی نیست؛ گاهی
باعث Flush، Decompression، Resolve یا Copy واقعی
داده می‌شود.


05

Architecture Dependency

Layout به نسل GPU و معماری وابسته است. الگوریتم
Detiling یا Swizzle یک دستگاه نباید برای دستگاه
دیگر فرض شود.


06

Practical Rule

  • اندازه Allocation را از API دریافت کنید.
  • Pitch و Offset را حدس نزنید.
  • Format را با Layout اشتباه نگیرید.
  • Modifier را هنگام Export منتقل کنید.
  • Zero-Copy را با Profiler تأیید کنید.


M8


KEY TAKEAWAYS

جمع‌بندی مهندسی

  • Linear Layout برای CPU ساده است، اما همیشه برای GPU
    بهترین Locality را ندارد.
  • Pitch بخشی از ساختار حافظه است و نباید از Width
    محاسبه یا حدس زده شود.
  • Planar بودن به تعداد Planeها مربوط است، نه به خطی
    یا Tiled بودن حافظه.
  • Tiled و Swizzled Layoutها دسترسی دوبعدی GPU را
    بهینه می‌کنند.
  • Block Linear معمولاً برای Engineهای سخت‌افزاری و
    Video Surfaceها مناسب است.
  • Compression Layout با Metadata همراه است و ممکن
    است هنگام Interop نیازمند Resolve باشد.
  • Zero-Copy واقعی به سازگاری Format، Layout،
    Modifier، Compression و Synchronization وابسته است.
  • Layout مناسب باید برای کل Pipeline انتخاب شود، نه
    فقط سریع‌ترین Engine منفرد.

واژه‌نامه مرور مهندسی

Memory Layout
روش سازمان‌دهی و آدرس‌دهی داده‌های Resource در حافظه.

Modifier
اطلاعات تکمیلی درباره Tiling، Compression یا Layout اختصاصی.

Pitch-Linear
چیدمان سطر‌به‌سطر با فاصله ثابت میان ابتدای سطرها.

Optimal Layout
Layout انتخاب‌شده برای عملکرد مناسب GPU، نه دسترسی مستقیم CPU.

Resolve
تبدیل Resource به حالت، Layout یا نمایش سازگارتر.

Layout Transition
تغییر وضعیت استفاده یا نمایش حافظه Resource میان عملیات.

Hidden Copy
انتقال داده‌ای که Driver بدون درخواست صریح برنامه انجام می‌دهد.

Capability Intersection
مجموعه Format و Layoutهایی که همه مصرف‌کنندگان Pipeline می‌پذیرند.

M9

GPU MEMORY ARCHITECTURE


Texture Cache و Texture Addressing

بررسی نحوه تبدیل مختصات Texture به آدرس حافظه،
نقش Texture Unit و Texture Cache، روش‌های Sampling،
Address Modeها، Mipmap، Cache Locality و عواملی که
باعث Cache Hit، Cache Miss یا افزایش ترافیک VRAM
می‌شوند.


سطح فصل


پیشرفته

زمان مطالعه


حدود ۳۰ دقیقه

موضوع


Texture Memory System

نسخه


v1.0


پیش‌نیازهای فصل

  • شناخت Tiled و Swizzled Layout
  • آشنایی با Cache Line و Spatial Locality
  • درک Texture، Pixel و Sample
  • شناخت مختصات دوبعدی و سه‌بعدی


در این فصل یاد می‌گیرید

  • Texture Unit چگونه آدرس تولید می‌کند
  • Texture Cache چه تفاوتی با Cache عمومی دارد
  • Bilinear و Trilinear چه داده‌هایی می‌خوانند
  • Address Mode چگونه مختصات خارج از محدوده را مدیریت می‌کند
  • چه الگوهایی باعث Cache Thrashing می‌شوند

نقشه مفهومی فصل
Texture Sampling
Coordinates
Addressing
Filtering

Texture Cache
Mipmap
Memory Layout

مسیر خواندن Texture

هنگام اجرای Shader، برنامه معمولاً آدرس Byteای Texture
را مستقیماً محاسبه نمی‌کند. Shader مختصات Texture را به
واحد Sampling می‌دهد و سخت‌افزار مراحل آدرس‌دهی، انتخاب
Mipmap، Filtering و Cache Lookup را انجام می‌دهد.

Texture Unit چیست؟

Texture Unit بخشی از GPU است که عملیات تخصصی خواندن و
Sampling از Textureها را انجام می‌دهد.

این واحد می‌تواند مختصات را تبدیل کند، Address Mode را
اعمال کند، Mip Level مناسب را انتخاب کند و چند Sample
مجاور را برای Filtering بخواند.

Texture Cache چیست؟

Texture Cache حافظه‌ای کوچک و سریع در نزدیکی واحدهای
Sampling است که Sampleهای اخیراً خوانده‌شده را نگهداری
می‌کند.

این Cache برای الگوهای دسترسی دوبعدی و سه‌بعدی Texture
بهینه شده و هدف آن کاهش تعداد مراجعه‌ها به L2 Cache و
VRAM است.

جایگاه Texture Cache در سلسله‌مراتب حافظه

ساختار دقیق Cache به معماری GPU بستگی دارد. در بعضی
معماری‌ها Texture Cache و L1 Cache مسیرهای جداگانه دارند
و در بعضی دیگر بخشی از ساختار Unified Cache هستند.

مختصات Normalized

بسیاری از APIهای گرافیکی Texture را با مختصات Normalized
نمونه‌برداری می‌کنند؛ یعنی معمولاً بازه صفر تا یک به عرض
و ارتفاع کامل Texture نگاشت می‌شود.

Texture Unit این مختصات را با توجه به ابعاد Mip Level
انتخاب‌شده به مختصات Sample یا Texel تبدیل می‌کند.

مختصات Integer و Texel Fetch

در بعضی عملیات، Shader به‌جای Sampling فیلترشده، یک
Texel مشخص را با مختصات صحیح می‌خواند.

این نوع دسترسی معمولاً برای جدول‌ها، Bufferهای دوبعدی،
داده‌های محاسباتی و خواندن دقیق بدون Filtering مناسب است.

مقایسه Sample و Texel Fetch
ویژگی Texture Sample Texel Fetch
مختصات اغلب Normalized معمولاً Integer
Filtering ممکن است اعمال شود معمولاً خیر
Mip Selection خودکار یا صریح اغلب صریح
کاربرد Rendering و Sampling دسترسی دقیق داده

Texture Address Mode

Address Mode مشخص می‌کند مختصاتی که خارج از محدوده
Texture قرار می‌گیرد چگونه تفسیر شود.

Address Modeهای رایج
Mode رفتار کاربرد
Clamp استفاده از نزدیک‌ترین لبه تصویر و Render Result
Repeat / Wrap تکرار Texture Material و Pattern
Mirrored Repeat تکرار آینه‌ای کاهش Seam در Pattern
Border Color بازگرداندن رنگ ثابت Shadow و Sampling کنترل‌شده
Clamp to Zero Sample خارج از محدوده برابر صفر پردازش داده و Mask

Clamp Addressing

مختصات کوچک‌تر از حداقل به لبه اول و مختصات بزرگ‌تر از
حداکثر به لبه آخر نگاشت می‌شوند.

Repeat و Wrap

در حالت Repeat، بخش کسری مختصات برای تکرار Texture
استفاده می‌شود.

این روش برای Materialهای تکرارشونده مانند سنگ، پارچه،
خاک و الگوهای سطحی کاربرد زیادی دارد.

Nearest Filtering

در Nearest Filtering تنها نزدیک‌ترین Texel به مختصات
Sampling خوانده می‌شود.

این روش سریع و دقیق است، اما هنگام بزرگ‌نمایی یا
کوچک‌نمایی ممکن است تصویر Blocky یا Aliased دیده شود.

Bilinear Filtering

Bilinear Filtering چهار Texel مجاور را می‌خواند و نتیجه
را بر اساس فاصله Sample از هر Texel ترکیب می‌کند.

به همین دلیل Locality دوبعدی و Tiled Layout برای
Texture Sampling اهمیت زیادی دارند.

Trilinear Filtering

Trilinear Filtering از Bilinear Sampling روی دو Mip
Level مجاور استفاده می‌کند و سپس نتایج آن‌ها را با
یکدیگر ترکیب می‌کند.

بنابراین یک Sample منطقی می‌تواند به چندین Fetch حافظه
در دو سطح مختلف Texture نیاز داشته باشد.

Anisotropic Filtering

وقتی Texture با زاویه شدید روی سطح نمایش داده می‌شود،
Footprint یک Pixel در فضای Texture دیگر تقریباً مربع
نیست و می‌تواند ناحیه‌ای کشیده را پوشش دهد.

Anisotropic Filtering چند Sample را در امتداد این ناحیه
کشیده می‌خواند تا جزئیات بهتر حفظ شوند.

این روش کیفیت بالاتری دارد، اما تعداد Fetchها و فشار
روی Texture Cache را افزایش می‌دهد.

Sample Footprint

Sample Footprint ناحیه‌ای از Texture است که برای تولید
یک Sample نهایی باید خوانده شود.

اندازه تقریبی Footprint در روش‌های Filtering
Filtering حداقل Sampleهای پایه ویژگی
Nearest یک Texel کمترین دسترسی حافظه
Bilinear چهار Texel Locality دوبعدی
Trilinear دو مجموعه Bilinear دو Mip Level
Anisotropic چندین Sample Footprint کشیده و متغیر

Mipmap و Texture Cache

Mipmap مجموعه‌ای از نسخه‌های کوچک‌تر Texture است که هر
سطح معمولاً نصف عرض و نصف ارتفاع سطح قبلی را دارد.

استفاده از Mip Level متناسب با اندازه نمایش، Footprint
حافظه و Cache Miss را کاهش می‌دهد.

Level of Detail یا LOD

Texture Unit بر اساس تغییرات مختصات Texture میان Pixelهای
مجاور، اندازه تقریبی Footprint را محاسبه و Mip Level مناسب
را انتخاب می‌کند.

Texture Cache Hit

Cache Hit زمانی رخ می‌دهد که Sampleهای موردنیاز از قبل
در Texture Cache موجود باشند.

عواملی که Cache Hit را افزایش می‌دهند
عامل اثر
مختصات نزدیک Threadها استفاده مشترک از Cache Line
Tiled یا Swizzled Layout Locality دوبعدی بهتر
Mip Level مناسب کاهش Footprint غیرضروری
Texture کوچک‌تر احتمال Resident ماندن بیشتر
Reuse زمانی استفاده مجدد از داده‌های تازه‌خوانده‌شده

Texture Cache Miss

Cache Miss زمانی رخ می‌دهد که داده موردنیاز در Cache
موجود نباشد و باید از سطح پایین‌تر حافظه خوانده شود.

دلایل رایج Texture Cache Miss
علت نتیجه
دسترسی تصادفی Cache Lineهای پراکنده
Texture بسیار بزرگ Working Set بزرگ‌تر از Cache
Mip Level نامناسب خواندن Resolution بیش‌ازحد
چند Texture هم‌زمان رقابت برای ظرفیت Cache
Anisotropy بالا Fetchهای بیشتر و پراکنده‌تر
Layout نامناسب Locality پایین‌تر

Texture Cache Thrashing

Cache Thrashing زمانی رخ می‌دهد که Working Set یا الگوی
دسترسی باعث شود داده‌ها پیش از استفاده مجدد مرتباً از
Cache خارج شوند.

این وضعیت باعث افزایش شدید ترافیک L2 و VRAM می‌شود،
حتی اگر GPU از نظر توان محاسباتی اشباع نشده باشد.

Coherence میان Threadها

اگر Threadهای یک Warp یا Wavefront مختصات نزدیک را
Sample کنند، درخواست‌های آن‌ها می‌توانند به Cache Lineها
و Transactionهای مشترک تبدیل شوند.

Divergent Texture Sampling

اگر Threadهای یک گروه از Textureهای متفاوت یا نواحی
بسیار دور Sample کنند، امکان اشتراک Cache Line کاهش
می‌یابد.

این حالت می‌تواند تعداد درخواست‌های مستقل حافظه را
افزایش دهد و Latency را دشوارتر پنهان کند.

تبدیل Format در Texture Unit

Texture Unit می‌تواند برخی Formatهای ذخیره‌شده را هنگام
خواندن به نمایش قابل استفاده Shader تبدیل کند.

نمونه عملیات هنگام Texture Fetch
عملیات نمونه
Normalization UNORM به مقدار شناور صفر تا یک
Signed Conversion SNORM به بازه منفی یک تا مثبت یک
Channel Expansion تبدیل RGB به Vector کامل
Swizzle جابه‌جایی یا تکرار Channelها
sRGB Decode تبدیل به فضای خطی برای محاسبه

Texture View

Texture View نحوه تفسیر یک Resource را برای Sampling
مشخص می‌کند.

View می‌تواند Format قابل مشاهده، Mip Range، Array Layer
و Channel Mapping را تعیین کند، بدون اینکه الزاماً داده
جدیدی کپی شود.

Texture Array و Layer Selection

Texture Array چند Texture هم‌اندازه و هم‌فرمت را به شکل
Layerهای یک Resource نگهداری می‌کند.

تغییر Layer میان Threadهای مجاور می‌تواند روی Locality
و Cache Behavior اثر بگذارد، به‌خصوص اگر Layerها در
حافظه فاصله زیادی داشته باشند.

Texture سه‌بعدی

در Texture سه‌بعدی، Sampleها دارای مختصات X، Y و Z هستند
و Filtering ممکن است چندین Texel را در حجم سه‌بعدی
بخواند.

Trilinear Filtering در Texture سه‌بعدی می‌تواند به ترکیب
هشت Texel مجاور در یک سطح حجمی اشاره کند؛ این مفهوم با
Trilinear Mipmap Filtering یکسان نیست.

Sampling از Video Surface

Surfaceهای ویدئویی مانند NV12 و P010 دارای چند Plane
هستند. Sampling آن‌ها ممکن است از Viewهای چند Plane،
Conversion سخت‌افزاری یا Shaderهای جداگانه استفاده کند.

پشتیبانی دقیق این مسیر به API، Format و قابلیت سخت‌افزار
وابسته است.

الگوهای دسترسی و اثر آن‌ها بر Cache

مقایسه الگوهای رایج Sampling
الگو رفتار Cache ریسک
Sequential 2D بسیار مناسب کم
Small Neighborhood مناسب با Tiling مرز Tile
Large Kernel Reuse بالا در صورت طراحی درست Working Set بزرگ
Random Lookup ضعیف Cache Miss زیاد
Multiple Large Textures رقابت برای Cache Thrashing
High Anisotropy Footprint گسترده Fetch زیاد

راهکارهای بهینه‌سازی Texture Cache

روش‌های بهبود رفتار Texture Memory
راهکار نتیجه
استفاده از Mipmap کاهش Sample Footprint و Aliasing
مختصات منسجم اشتراک Cache Line میان Threadها
Texture Atlas کاهش تغییر Resource در بعضی Workloadها
کاهش Format Size Texelهای بیشتر در هر Cache Line
Texture Compression کاهش ترافیک و ظرفیت مؤثر بیشتر
LOD مناسب جلوگیری از خواندن Resolution بیش‌ازحد
کاهش Divergence درخواست‌های حافظه منظم‌تر
Profiling تشخیص Cache Miss و Bottleneck واقعی


PERFORMANCE IMPACT

اثر Texture Cache بر عملکرد

Memory Bandwidth
بسیار زیاد

Shader Latency
بسیار زیاد

Power Efficiency
زیاد

Image Quality
وابسته به Filtering


API MAPPING

Texture Sampling در APIهای مختلف

Vulkan

VkImageView، VkSampler، Address Mode و LOD
Direct3D 12

Shader Resource View و Sampler Descriptor
OpenGL

Texture Object، Sampler Object و Texture Parameters
Metal

MTLTexture و MTLSamplerState
CUDA

Texture Object، CUDA Array و Address Mode
OpenCL

Image Object، Sampler و Read Image Functions


UNDER THE HOOD

یک Texture Sample در داخل GPU چگونه اجرا می‌شود؟

دستور Sampling در ظاهر یک عملیات ساده Shader است،
اما ممکن است شامل محاسبه مشتق مختصات، انتخاب Mip،
تولید چند آدرس، Cache Lookup، Fetch چند Block و
Interpolation سخت‌افزاری باشد.


01

Coordinate Derivatives

GPU می‌تواند تغییر مختصات Texture میان Invocationهای
نزدیک را بررسی کند تا Footprint و LOD تقریبی را
به‌دست آورد.


02

Address Generation

مختصات با Address Mode، Mip Dimensions، Tile
Layout و Swizzle ترکیب می‌شوند تا آدرس فیزیکی
Blockهای حافظه تعیین شود.


03

Request Coalescing

درخواست‌های Threadهای یک گروه می‌توانند بر اساس
Block یا Cache Line مشترک ادغام شوند. میزان این
ادغام به نزدیکی مختصات آن‌ها بستگی دارد.


04

Format Decode

داده خوانده‌شده ممکن است Decompress، Normalize،
Channel-Swizzle یا از sRGB به فضای خطی تبدیل شود
تا نتیجه قابل استفاده Shader تولید شود.


05

Latency Hiding

هنگام انتظار Texture Fetch، Scheduler می‌تواند
Wave یا Warp دیگری را اجرا کند؛ به شرط آنکه
Workload Resident کافی وجود داشته باشد.


06

Practical Impact

  • Cache Hit را فقط از روی FPS حدس نزنید.
  • Mip Level و Anisotropy را با Profiler بررسی کنید.
  • دسترسی تصادفی ممکن است Memory-Bound شود.
  • Format کوچک‌تر ظرفیت مؤثر Cache را افزایش می‌دهد.
  • Texture Layout و Sampling Pattern را با هم تحلیل کنید.

اشتباهات رایج

برداشت‌های نادرست درباره Texture Cache
اشتباه واقعیت
هر Texture Sample فقط یک Read است Filtering ممکن است چندین Texel و Mip Level را بخواند.
Texture Cache همیشه سریع است دسترسی تصادفی و Thrashing می‌تواند آن را کم‌اثر کند.
Mipmap فقط برای کیفیت است Mipmap می‌تواند ترافیک حافظه را نیز کاهش دهد.
Format روی Cache اثری ندارد اندازه Texel تعداد داده قابل نگهداری در Cache را تغییر می‌دهد.
Sampleهای Threadها مستقل‌اند درخواست‌های نزدیک می‌توانند Cache Line مشترک داشته باشند.


M9


CHAPTER SUMMARY

خلاصه فصل

  • Texture Unit آدرس‌دهی، Filtering و Fetch را مدیریت می‌کند.
  • Texture Cache برای الگوهای دسترسی دوبعدی و سه‌بعدی بهینه شده است.
  • Bilinear Filtering حداقل چهار Texel مجاور را ترکیب می‌کند.
  • Trilinear Filtering می‌تواند دو Mip Level را بخواند.
  • Anisotropic Filtering Footprint گسترده‌تر و Fetch بیشتری دارد.
  • Mipmap می‌تواند کیفیت و رفتار Cache را هم‌زمان بهبود دهد.
  • Threadهای دارای مختصات نزدیک، از Cache Lineهای مشترک سود می‌برند.
  • دسترسی تصادفی و Working Set بزرگ باعث Cache Thrashing می‌شوند.

واژه‌نامه فصل

Texture Unit
واحد سخت‌افزاری آدرس‌دهی، Fetch و Filtering Texture.

Texture Cache
Cache بهینه‌شده برای دسترسی Sampleهای تصویری و دوبعدی.

Texel
عنصر پایه Texture، مشابه Pixel در فضای Texture.

Sample Footprint
ناحیه‌ای از Texture که برای تولید نتیجه Sampling خوانده می‌شود.

Address Mode
قانون مدیریت مختصات خارج از محدوده Texture.

Mipmap
مجموعه نسخه‌های کاهش‌یافته یک Texture.

LOD
سطح جزئیات یا Mip Level انتخاب‌شده برای Sampling.

Cache Thrashing
جایگزینی مکرر داده‌های Cache پیش از استفاده مجدد.

M10

GPU TEXTURE SYSTEM


Mipmap، Level of Detail (LOD)
و Texture Minification

بررسی کامل علت ایجاد Mipmap،
نحوه سازمان‌دهی سطوح مختلف تصویر،
انتخاب خودکار Level توسط GPU،
ارتباط LOD با مشتق‌های Texture Coordinate،
نقش Texture Cache و تأثیر آن بر کیفیت تصویر و کارایی سیستم.


سطح فصل


پیشرفته


زمان مطالعه


حدود ۴۵ دقیقه


موضوع


Texture Level Selection


نسخه


v1.0

پیش‌نیازهای این فصل

  • Texture Cache
  • Texture Sampling
  • Bilinear Filtering
  • Address Modes

در پایان این فصل

  • دلیل ایجاد Mipmap را درک خواهید کرد.
  • خواهید دانست GPU چگونه Level مناسب را انتخاب می‌کند.
  • مفهوم LOD را به صورت مهندسی خواهید شناخت.
  • ارتباط Mipmap با Cache و Bandwidth را تحلیل خواهید کرد.

نقشه مفهومی فصل

MIPMAP

Minification
LOD
Texture Cache

Filtering
Derivatives
Bandwidth

چرا Mipmap به وجود آمد؟

تقریباً تمام موتورهای گرافیکی مدرن،
از بازی‌های رایانه‌ای گرفته تا نرم‌افزارهای CAD،
برای نمایش Textureها از Mipmap استفاده می‌کنند.

اما سؤال اصلی این است:

چرا اصلاً چنین ساختاری لازم شد؟

پاسخ این سؤال مستقیماً به رابطه میان
اندازه Texture در حافظه
و اندازه واقعی آن روی صفحه نمایش مربوط می‌شود.

یک مثال واقعی

فرض کنید روی دیوار یک ساختمان،
یک Texture با وضوح

4096 × 4096

قرار گرفته است.

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

در این وضعیت ممکن است کل آن دیوار
تنها حدود

40 × 40 Pixel

روی مانیتور دیده شود.



Texture In Memory

4096 × 4096 Texels

        │
        │
        ▼

Rendered On Screen

40 × 40 Pixels

در این لحظه تقریباً تمام اطلاعات موجود
در Texture دیگر قابل نمایش نیست.

سؤال مهم

آیا GPU همچنان باید
تمام Texture چهار هزار در چهار هزار
را بخواند
تا فقط چهل پیکسل روی صفحه تولید کند؟

هزینه این کار چقدر است؟

هر Pixel صفحه ممکن است
نماینده صدها یا حتی هزاران Texel باشد.

نسبت Texel به Pixel

Resolution Texture

Screen Size

نتیجه

4096²

40²

حجم زیادی از اطلاعات
هرگز دیده نمی‌شود.

2048²

80²

هنوز اطلاعات اضافی
بسیار زیاد است.

512²

500²

تقریباً متناسب.

UNDER THE HOOD

اگر Mipmap وجود نداشت…

01

Texture Fetch

هر Pixel باید از Texture
با وضوح کامل نمونه‌برداری می‌کرد.

02

Cache

Cache دائماً با داده‌های
غیرضروری پر می‌شد.

03

Memory Traffic

پهنای باند حافظه
به شدت افزایش پیدا می‌کرد.

04

Image Quality

Aliasing،
Shimmering
و Moiré Pattern
ظاهر می‌شدند.

Mipmap دقیقاً چیست؟

Mipmap مجموعه‌ای از نسخه‌های کوچک‌شده یک Texture است که
هر نسخه، یک سطح مستقل از زنجیره Mipmap را تشکیل می‌دهد.

سطح اصلی Texture با بیشترین وضوح، معمولاً
Level 0
نام دارد. هر Level بعدی معمولاً نصف عرض و نصف ارتفاع
Level قبلی را دارد.

ساختار زنجیره Mipmap

فرض کنید Texture اصلی ابعاد
1024 × 1024
دارد. سطوح بعدی به‌صورت زیر ساخته می‌شوند:

آخرین Level معمولاً به یک Texel با ابعاد
1 × 1
می‌رسد و میانگین کلی رنگ Texture را تقریب می‌زند.

Level 0

Level 0 همان Texture اصلی با بیشترین وضوح است و تمام
جزئیات منبع را نگهداری می‌کند.

هنگام Magnification یا زمانی که Texture نزدیک به اندازه
واقعی خود روی صفحه نمایش داده می‌شود، GPU معمولاً از
Level 0 یا Levelهای نزدیک به آن استفاده می‌کند.

Levelهای کوچک‌تر

Levelهای کوچک‌تر نسخه‌هایی از Texture هستند که جزئیات
فرکانس بالای آن‌ها از قبل حذف یا میانگین‌گیری شده است.

بنابراین زمانی که Texture در فاصله دور نمایش داده می‌شود،
GPU به‌جای نمونه‌برداری مستقیم از Level 0، از Level
متناسب با اندازه نمایش استفاده می‌کند.

چرا هر Level نصف می‌شود؟

نصف‌کردن عرض و ارتفاع باعث می‌شود مساحت هر Level تقریباً
یک‌چهارم Level قبلی شود.

این نسبت هم ساده است، هم با محاسبات دودویی GPU سازگار
است و هم امکان انتخاب پیوسته Resolution را با تعداد
Levelهای محدود فراهم می‌کند.

Textureهای غیرمربعی

Mipmap محدود به Textureهای مربعی نیست. در Textureهای
مستطیلی نیز هر بُعد تا رسیدن به مقدار یک کاهش می‌یابد.

زمانی که یکی از ابعاد به یک می‌رسد، بُعد دیگر همچنان تا
رسیدن به یک کاهش پیدا می‌کند.

ابعاد فرد

اگر عرض یا ارتفاع Texture عددی فرد باشد، اندازه Level
بعدی بر اساس قواعد API یا پیاده‌سازی به مقدار صحیح مناسب
کاهش می‌یابد.

تعداد Levelهای Mipmap

تعداد کامل Levelها بر اساس بزرگ‌ترین بُعد Texture محاسبه
می‌شود.

مقدار یک اضافه می‌شود، زیرا Level 0 نیز بخشی از زنجیره
محسوب می‌شود.

مثال محاسبه تعداد Level

تعداد Levelهای کامل برای چند اندازه Texture
ابعاد Texture بزرگ‌ترین بُعد تعداد Level
256 × 256 256 9
1024 × 1024 1024 11
1920 × 1080 1920 11
4096 × 2048 4096 13

زنجیره کامل و زنجیره ناقص

Resource ممکن است تمام Levelهای ممکن را داشته باشد یا
تنها بخشی از آن‌ها را ذخیره کند.

مقایسه Full Mip Chain و Partial Mip Chain
نوع ساختار کاربرد
Full Chain از Level 0 تا 1×1 Sampling در تمام فاصله‌ها
Partial Chain فقط بخشی از Levelها کاهش مصرف حافظه یا Streaming

در زنجیره ناقص باید Sampler و LOD Range طوری تنظیم شوند
که GPU به Levelهای موجود دسترسی پیدا کند.

هزینه حافظه Mipmap

تصور اولیه ممکن است این باشد که ذخیره چند نسخه Texture
مصرف حافظه را چند برابر می‌کند، اما هر Level تنها یک‌چهارم
Level قبلی مساحت دارد.

بنابراین یک زنجیره کامل دوبعدی تقریباً
۳۳ درصد
بیشتر از Level 0 حافظه مصرف می‌کند.

مثال مصرف حافظه

فرض کنید Texture فرمت RGBA8 و ابعاد
4096 × 4096
دارد. هر Texel چهار Byte مصرف می‌کند.

Mip Levelها چگونه در حافظه قرار می‌گیرند؟

از دید منطقی هر Level یک تصویر مستقل با ابعاد کوچک‌تر
است، اما از دید فیزیکی ممکن است تمام Levelها داخل یک
Allocation مشترک ذخیره شوند.

Offset، Pitch، Alignment و Tiling هر Level ممکن است با
Level دیگر متفاوت باشد.

Mip Tail چیست؟

Levelهای بسیار کوچک ممکن است از نظر Allocation مستقل
ناکارآمد باشند؛ زیرا اندازه آن‌ها از حداقل Tile یا Page
حافظه بسیار کوچک‌تر است.

برخی سیستم‌ها چند Level کوچک انتهایی را در یک ناحیه
مشترک با عنوان
Mip Tail
گروه‌بندی می‌کنند.

Mipmap در Texture Array و Cubemap

هر Layer در Texture Array و هر Face در Cubemap معمولاً
زنجیره Mipmap مخصوص خود را دارد.

View می‌تواند تنها بخشی از Layerها یا بازه‌ای مشخص از
Mip Levelها را در اختیار Shader قرار دهد.

Mipmap در Texture سه‌بعدی

در Texture سه‌بعدی معمولاً عرض، ارتفاع و عمق هم‌زمان
کاهش پیدا می‌کنند.

به همین دلیل هزینه کامل Mipmap در Texture سه‌بعدی با
Texture دوبعدی متفاوت است و باید جداگانه محاسبه شود.

Mipmap تولیدشده یا آماده؟

Levelهای Mipmap می‌توانند به‌صورت Offline توسط ابزار
Asset Pipeline ساخته شوند یا در Runtime توسط GPU تولید
شوند.

مقایسه تولید Offline و Runtime
روش مزیت محدودیت
Offline کیفیت کنترل‌شده و بدون هزینه Runtime نیاز به ذخیره Asset آماده
Runtime مناسب Textureهای پویا هزینه Compute یا Blit


UNDER THE HOOD

Resource واقعاً چگونه چند Mip Level را نگهداری می‌کند؟

برنامه یک Texture واحد می‌بیند، اما Driver و Memory
Manager باید برای هر Level ابعاد، Tile Layout، Offset،
Pitch و Alignment مناسب تولید کنند.


01

Subresource

هر ترکیب Mip Level، Array Layer و Plane می‌تواند
یک Subresource مستقل محسوب شود.


02

Alignment

Levelهای کوچک نیز ممکن است به مرزهای Tile یا Page
خاص Align شوند و فضای بیشتری از اندازه منطقی خود
مصرف کنند.


03

Address Generation

Texture Unit پس از انتخاب LOD، آدرس پایه همان
Level و Offset داخلی Sample را محاسبه می‌کند.


04

Cache Behavior

Levelهای کوچک‌تر Working Set کمتری دارند و احتمال
Resident ماندن آن‌ها در Cache بیشتر است.


05

Mip Tail

Levelهای کوچک انتهایی ممکن است داخل یک Tile یا
Page مشترک بسته‌بندی شوند.


06

Practical Impact

  • تعداد Levelها را هنگام ساخت Resource مشخص کنید.
  • زنجیره ناقص را با LOD Range هماهنگ کنید.
  • اندازه Allocation را از API دریافت کنید.
  • Mip Tail را مانند سطرهای Linear تفسیر نکنید.
  • Streaming را بر اساس Subresource مدیریت کنید.

Mipmap چگونه ساخته می‌شود؟

ساخت Mipmap فقط کوچک‌کردن ابعاد تصویر نیست. هر Level باید
نماینده مناسبی از اطلاعات Level قبلی در Resolution پایین‌تر
باشد.

برای تولید هر Texel در Level جدید، مجموعه‌ای از Texelهای
Level قبلی نمونه‌برداری و با یکدیگر ترکیب می‌شوند. این فرایند
Downsampling
نام دارد.

تفاوت Resize ساده و Prefiltering

اگر تصویر بدون فیلتر مناسب کوچک شود، جزئیات فرکانس بالا
مستقیماً به Resolution پایین‌تر منتقل می‌شوند و می‌توانند
Aliasing ایجاد کنند.

مقایسه کوچک‌سازی ساده و تولید صحیح Mipmap
روش رفتار نتیجه
Nearest Resize انتخاب یک Texel Aliasing و ازبین‌رفتن اطلاعات
Average Downsampling ترکیب چند Texel نمایش بهتر میانگین ناحیه
Filtered Prefiltering کاهش فرکانس‌های نامناسب کیفیت پایدارتر هنگام Minification

مدل ساده Downsampling دو در دو

در ساده‌ترین حالت، هر چهار Texel مجاور از Level قبلی برای
تولید یک Texel در Level بعدی میانگین‌گیری می‌شوند.

این روش سریع و ساده است، اما همیشه بهترین کیفیت را تولید
نمی‌کند؛ به‌خصوص برای Textureهایی با لبه‌های تیز، Alpha،
Normal Map یا داده‌های غیررنگی.

Box Filter

Box Filter تمام Sampleهای داخل ناحیه فیلتر را با وزن برابر
ترکیب می‌کند.

ویژگی‌های Box Filter
ویژگی نتیجه
پیاده‌سازی ساده مناسب تولید سریع Mipmap
وزن برابر میانگین یکنواخت Sampleها
هزینه پایین مناسب Runtime Generation
پاسخ فرکانسی محدود امکان باقی‌ماندن Aliasing
Blur احتمالی کاهش جزئیات نازک

Gaussian Filter

Gaussian Filter به Sampleهای نزدیک مرکز وزن بیشتری و به
Sampleهای دورتر وزن کمتری می‌دهد.

Gaussian می‌تواند فرکانس‌های بالا را نرم‌تر از Box Filter
کاهش دهد، اما ممکن است Texture را کمی Blur کند.

Lanczos Filter

Lanczos یک فیلتر بازنمونه‌برداری با کیفیت بالاتر است که تلاش
می‌کند جزئیات و وضوح لبه‌ها را بهتر حفظ کند.

این فیلتر معمولاً برای تولید Offline Asset مناسب‌تر است؛
زیرا هزینه محاسباتی و تعداد Sampleهای بیشتری نسبت به Box
Filter دارد.

مقایسه فیلترهای رایج تولید Mipmap
Filter کیفیت هزینه کاربرد
Box متوسط کم Runtime و مسیرهای سریع
Gaussian نرم و پایدار متوسط کاهش نویز و Aliasing
Lanczos زیاد زیاد Asset Pipeline آفلاین

Filter Footprint

Filter Footprint محدوده‌ای از Level مبدأ است که برای تولید
یک Texel در Level مقصد خوانده می‌شود.

Footprint بزرگ‌تر می‌تواند Aliasing را بهتر کاهش دهد، اما
هزینه تولید Mipmap و احتمال Blur را افزایش می‌دهد.

مشکل Gamma در تولید Mipmap

بسیاری از Textureهای رنگی به‌صورت sRGB ذخیره می‌شوند.
مقادیر ذخیره‌شده در sRGB با شدت واقعی نور رابطه خطی ندارند.

اگر میانگین‌گیری مستقیماً روی مقادیر sRGB انجام شود، نتیجه
می‌تواند از نظر روشنایی نادرست و معمولاً تیره‌تر از مقدار
فیزیکی مناسب باشد.

مسیر صحیح Gamma-Correct Downsampling

این قاعده برای Textureهای رنگی اهمیت دارد، اما برای داده‌هایی
مانند Normal Map، Roughness، Mask یا Depth نباید به‌طور
خودکار sRGB Decode اعمال شود.

Texture رنگی و Texture داده‌ای

تفاوت تفسیر Texture هنگام تولید Mipmap
نوع Texture فضای مناسب فیلتر نکته
Base Color Linear Light sRGB Decode پیش از فیلتر
Emissive Color Linear Light حفظ شدت صحیح نور
Normal Map Vector Space نیازمند Normalization مجدد
Roughness فضای داده وابسته به مدل BRDF
Metalness فضای داده معمولاً بدون sRGB
Mask فضای داده یا Coverage میانگین ساده همیشه مناسب نیست

مشکل Alpha در Mipmap

Textureهای دارای Alpha می‌توانند هنگام کوچک‌شدن دچار Halo،
نشت رنگ لبه یا کاهش Coverage شوند.

رفتار صحیح به معنای Alpha بستگی دارد؛ Alpha ممکن است برای
Transparency پیوسته، Cutout، Coverage یا Mask استفاده شود.

Straight Alpha

در Straight Alpha، کانال RGB مستقل از مقدار Alpha ذخیره
می‌شود. حتی Pixelهای کاملاً شفاف نیز ممکن است رنگ RGB داشته
باشند.

میانگین مستقیم این دو Pixel می‌تواند رنگ لبه را تیره کند،
حتی اگر Pixel شفاف نباید در نتیجه بصری سهم رنگی مستقلی داشته
باشد.

Premultiplied Alpha

در Premultiplied Alpha، مقادیر RGB پیش از ذخیره در Alpha
ضرب می‌شوند.

این نمایش در بسیاری از عملیات Filtering و Compositing رفتار
مناسب‌تری دارد؛ زیرا Pixel کاملاً شفاف سهم رنگی صفر خواهد
داشت.

Halo Artifact

Halo زمانی ایجاد می‌شود که رنگ Pixelهای شفاف یا پس‌زمینه
هنگام Downsampling وارد لبه جسم شود.

استفاده از Premultiplied Alpha، Edge Color Dilation یا
Padding مناسب می‌تواند این مشکل را کاهش دهد.

Alpha Coverage در Textureهای Cutout

در Textureهایی مانند برگ درخت، حصار یا مو، Alpha اغلب با
Threshold برای نگه‌داشتن یا حذف Pixel استفاده می‌شود.

میانگین‌گیری ساده Alpha می‌تواند باعث شود بخش زیادی از
Texture در Mipهای کوچک‌تر از Threshold پایین‌تر برود و ناپدید
شود.

حفظ Alpha Coverage

برای Textureهای Alpha-Test می‌توان مقادیر Alpha هر Mip را
طوری Scale یا تنظیم کرد که نسبت تقریبی Pixelهای عبورکننده از
Threshold حفظ شود.

راهکارهای متداول Alpha Cutout
راهکار هدف
Coverage Preservation حفظ مساحت قابل مشاهده
Alpha Scaling جبران افت مقدار Alpha
Alpha-to-Coverage نمایش نرم‌تر مرز Cutout
Signed Distance Field حفظ بهتر لبه در Scaleهای مختلف

جزئیات نازک و خطوط باریک

سیم، نرده، خطوط شبکه، نوشته‌های ریز و جزئیات باریک ممکن است
در Mipهای کوچک‌تر کاملاً از بین بروند.

اگر Threshold یا Contrast بالا باشد، خط نازک ممکن است دیگر
قابل مشاهده نباشد.

حفظ جزئیات مهم

برخی Asset Pipelineها پس از Downsampling از Sharpening محدود
یا فیلترهای Detail-Preserving استفاده می‌کنند.

Sharpening بیش‌ازحد می‌تواند Ringing، Overshoot یا Aliasing
جدید ایجاد کند؛ بنابراین باید بر اساس نوع Texture تنظیم شود.

Trade-off حفظ جزئیات
تنظیم مزیت خطر
Blur بیشتر Aliasing کمتر ازبین‌رفتن وضوح
Sharpen بیشتر جزئیات واضح‌تر Shimmering و Ringing
Filter متعادل کیفیت پایدار نیازمند تنظیم Asset

تولید Mipmap برای Normal Map

Normal Map رنگ معمولی نیست. کانال‌های آن معمولاً مؤلفه‌های
یک Vector جهت را نمایش می‌دهند.

میانگین‌گیری Vectorها می‌تواند طول Normal را کاهش دهد؛
بنابراین نتیجه باید بر اساس کاربرد، Normalize یا با روش
مناسب‌تری پردازش شود.

Mipmap برای Roughness

Roughness پارامتری از مدل Material است و میانگین ساده آن
همیشه معادل میانگین رفتار بازتابی سطح نیست.

جزئیات ریز Normal Map نیز در فاصله دور می‌توانند به
Roughness ظاهری تبدیل شوند. Asset Pipelineهای پیشرفته ممکن
است این اثر را هنگام تولید Mip در نظر بگیرند.

Mipmap برای Height Map

بسته به الگوریتم مصرف‌کننده، Height Map ممکن است به میانگین،
کمینه، بیشینه یا اطلاعات آماری دیگری نیاز داشته باشد.

روش‌های احتمالی کاهش Height Data
روش کاربرد احتمالی
Average نمایش ارتفاع متوسط
Minimum حفظ پایین‌ترین سطح
Maximum حفظ برجسته‌ترین ویژگی
Min-Max Pair حفظ دامنه ارتفاع در هر Block

Seam در Cubemap

اگر Faceهای Cubemap به‌صورت کاملاً مستقل فیلتر شوند، Pixelهای
نزدیک مرز Faceها ممکن است اطلاعات Face مجاور را در نظر نگیرند.

نتیجه می‌تواند ایجاد خط یا ناپیوستگی در مرز Cubemap باشد،
به‌خصوص در Mip Levelهای کوچک‌تر.

Prefiltering در Environment Map

Mipهای Environment Map ممکن است فقط نسخه کوچک‌شده تصویر
نباشند. در Rendering مبتنی بر فیزیک، هر Level می‌تواند
نمایش ازپیش‌فیلترشده‌ای از نور محیط برای Roughness متفاوت
باشد.

در چنین Resourceهایی، Mip Level علاوه بر Resolution می‌تواند
معنای فیزیکی خاصی نیز داشته باشد.

Pipeline پیشنهادی تولید Offline

تولید Mipmap در Runtime

Render Targetهای پویا، Procedural Textureها، Video Frameها
یا Textureهای تولیدشده توسط Compute ممکن است به تولید Mipmap
در زمان اجرا نیاز داشته باشند.

این عملیات می‌تواند با Blit Engine، Render Pass، Compute
Shader یا دستور اختصاصی API انجام شود.

روش‌های تولید Runtime

مقایسه روش‌های تولید Mipmap روی GPU
روش مزیت محدودیت
Hardware Blit ساده و سریع کنترل محدود روی Filter
Render Pass استفاده از Sampler و Shader نیاز به Attachment و Transition
Compute Shader کنترل کامل و Semantic-Aware پیچیدگی و Synchronization بیشتر
API Generate Command پیاده‌سازی آسان رفتار وابسته به API و Driver

Synchronization میان Levelها

هر Level معمولاً ورودی Level بعدی است. بنابراین Write یک
Level باید پیش از Read همان Level برای تولید سطح بعدی قابل
مشاهده باشد.

تولید زنجیره‌ای یا مستقیم

در روش زنجیره‌ای، هر Level از Level قبلی تولید می‌شود.
در روش مستقیم، هر Level ممکن است مستقیماً از منبع اصلی
محاسبه شود.

مقایسه دو راهبرد تولید Mipmap
راهبرد مزیت محدودیت
Recursive ساده و کم‌هزینه تجمع خطای Filter
From Base Level کنترل بهتر Footprint هزینه Sample بیشتر

چگونه کیفیت Mipmap را ارزیابی کنیم؟

چک‌لیست کنترل کیفیت Mipmap
بررسی نشانه مشکل
حرکت دوربین Shimmering یا Flickering
مرز Alpha Halo یا ناپدیدشدن Coverage
روشنایی تیره‌شدن Mipهای کوچک
Normal Map تغییر شدت نور یا Normalهای نادرست
جزئیات نازک ناپدیدشدن زودهنگام
Cubemap Seam میان Faceها


UNDER THE HOOD

چرا یک فیلتر عمومی برای همه Textureها کافی نیست؟

GPU فقط Byteها را می‌بیند، اما Asset Pipeline باید معنای
هر Channel را بداند. نحوه صحیح ترکیب داده به این بستگی
دارد که آن Texture رنگ، Vector، Coverage یا پارامتر
Material را نمایش دهد.


01

Frequency Reduction

Level مقصد توان نمایش تمام فرکانس‌های Level مبدأ را
ندارد؛ Filter باید آن‌ها را پیش از Sample Reduction
کاهش دهد.


02

Semantic Interpretation

RGB ممکن است رنگ، Normal، ID یا داده Packed باشد.
عملیات صحیح تنها از روی Format قابل تشخیص نیست.


03

Gamma Domain

Filter رنگ باید در فضای خطی انجام شود، نه روی
مقادیر Encode‌شده برای نمایش.


04

Alpha Semantics

Transparency پیوسته، Cutout و Coverage به روش‌های
متفاوتی برای Downsampling نیاز دارند.


05

Vector Data

میانگین‌گیری Normalها می‌تواند طول Vector را تغییر
دهد و نیازمند Renormalization یا مدل پیشرفته‌تر باشد.


06

Practical Rules

  • نوع Texture را در Metadata Asset ثبت کنید.
  • Base Color را در Linear Light فیلتر کنید.
  • Normal Map را پس از فیلتر Normalize کنید.
  • Alpha Cutout را با Coverage Preservation بسازید.
  • فیلتر Runtime را با نیاز کیفیت پروژه هماهنگ کنید.

Aliasing در Texture Minification

هنگام Minification، چندین Texel از Texture ممکن است روی یک
Pixel صفحه نگاشت شوند. اگر GPU فقط تعداد محدودی Sample از
این ناحیه بردارد، بخشی از اطلاعات تصویر به‌صورت نادرست در
خروجی ظاهر می‌شود.

این خطا
Aliasing
نام دارد و می‌تواند به شکل خطوط کاذب، تغییر Pattern،
Flickering یا حرکت ظاهری جزئیات دیده شود.

رابطه Texel و Pixel

یک Texel عنصر Texture است، اما یک Pixel عنصر خروجی صفحه
نمایش محسوب می‌شود. نسبت این دو هنگام Rendering ثابت نیست.

Mipmap بیشترین اهمیت را در حالت سوم دارد؛ زیرا GPU باید
نماینده مناسبی از یک ناحیه بزرگ Texture برای یک Pixel نهایی
پیدا کند.

Spatial Frequency چیست؟

Spatial Frequency میزان سرعت تغییر رنگ یا مقدار داده در
طول تصویر را توصیف می‌کند.

Textureهایی با نواحی بزرگ و یکنواخت دارای فرکانس فضایی
پایین هستند، درحالی‌که خطوط باریک، Checkerboard، نوشته‌های
ریز و نویز دارای فرکانس فضایی بالا هستند.

مثال‌های فرکانس فضایی

مقایسه محتوای Texture از نظر Spatial Frequency
محتوا فرکانس تقریبی ریسک Minification
Gradient نرم پایین کم
سطح رنگی یکنواخت بسیار پایین بسیار کم
نوشته ریز بالا زیاد
Checkerboard بسیار بالا بسیار زیاد
نویز تصادفی گسترده بسیار زیاد

Sampling Rate

Sampling Rate مشخص می‌کند در یک فاصله فضایی معین چند Sample
گرفته می‌شود.

وقتی Texture کوچک می‌شود، تعداد Pixelهای صفحه که آن را
نمایش می‌دهند کاهش پیدا می‌کند و در نتیجه نرخ Sampling
نسبت به جزئیات Texture کمتر می‌شود.

Undersampling

اگر Sampling Rate کمتر از مقدار لازم برای نمایش جزئیات
Texture باشد، سیستم وارد حالت
Undersampling
می‌شود.

در این شرایط، چند Pattern متفاوت می‌توانند Sampleهای
مشابهی تولید کنند و GPU دیگر قادر نیست شکل اصلی Texture را
از داده‌های محدود بازسازی کند.

Nyquist Limit

بر اساس اصل Nyquist، برای بازسازی یک فرکانس، نرخ Sampling
باید حداقل دو برابر آن فرکانس باشد.

در Texture Sampling، اگر جزئیات Texture سریع‌تر از توان
تفکیک Pixelهای صفحه تغییر کنند، آن جزئیات باید پیش از
Sampling کاهش یا حذف شوند.

Band-Limiting

Band-Limiting یعنی حذف فرکانس‌هایی که سیستم مقصد توان نمایش
آن‌ها را ندارد.

هنگام ساخت Mipmap، Prefiltering تلاش می‌کند Texture را برای
Sampling در Resolution جدید Band-Limited کند.

اگر Downsampling پیش از Low-Pass Filtering انجام شود،
فرکانس‌های بالا به فرکانس‌های پایین کاذب تبدیل می‌شوند.

Frequency Folding

هنگام Undersampling، فرکانس‌های بالا ممکن است به‌صورت
Patternهای کم‌فرکانس اشتباه دیده شوند.

این پدیده یکی از دلایل ایجاد Moiré و الگوهای موجی روی
Textureهای ریز است.

مثال Checkerboard

Checkerboard یکی از بهترین مثال‌ها برای مشاهده Aliasing است؛
زیرا تغییرات رنگی سریع و منظم دارد.

اگر Sampleها همواره روی خانه‌های روشن یا تیره قرار بگیرند،
خروجی ممکن است کاملاً سفید، کاملاً سیاه یا دارای Pattern
نادرست شود.

Sample Phase

نتیجه Sampling فقط به فاصله Sampleها وابسته نیست؛ محل شروع
Sampleها نسبت به Pattern نیز اهمیت دارد.

هنگام حرکت دوربین، Sample Phase تغییر می‌کند و همین موضوع
می‌تواند باعث Shimmering شود.

Shimmering

Shimmering نوعی ناپایداری زمانی است که در آن جزئیات Texture
هنگام حرکت دوربین روشن و خاموش یا جابه‌جا به نظر می‌رسند.

علت اصلی آن تغییر Sample Position نسبت به جزئیات
فرکانس بالاست.

ناپایداری زمانی

یک تصویر ثابت ممکن است در یک Frame قابل‌قبول به نظر برسد،
اما هنگام حرکت دوربین مشکلات Sampling آشکار شوند.

به همین دلیل ارزیابی Mipmap تنها با Screenshot کافی نیست و
باید Texture در حرکت و زوایای مختلف بررسی شود.

Moiré Pattern

Moiré زمانی ظاهر می‌شود که دو الگوی منظم با فرکانس یا زاویه
نزدیک روی یکدیگر اثر بگذارند.

در Rendering، الگوی Texture و شبکه Pixelهای صفحه می‌توانند
چنین تداخلی ایجاد کنند.

Moiré بیشتر کجا دیده می‌شود؟

سناریوهای رایج ایجاد Moiré
محتوا علت
پارچه ریزبافت Pattern متراکم و منظم
توری و حصار خطوط باریک تکرارشونده
سقف سفالی یا آجر جزئیات تکراری در فاصله دور
Grid و Checkerboard فرکانس بالا در دو محور
خطوط مورب تداخل زاویه Pattern و Pixel Grid

LOD Popping

اگر GPU تنها یک Mip Level را انتخاب کند و ناگهان به Level
بعدی سوئیچ شود، ممکن است تغییر قابل مشاهده‌ای در وضوح یا
روشنایی Texture ایجاد شود.

Trilinear Filtering با ترکیب دو Level مجاور تلاش می‌کند این
گذار را نرم‌تر کند.

Mipmap به‌عنوان نمایش ازپیش‌فیلترشده

هر Mip Level را می‌توان پاسخ تقریبی Texture برای یک محدوده
خاص از اندازه Sampling دانست.

GPU به‌جای فیلترکردن تعداد زیادی Texel از Level 0 در هر
Frame، از نتیجه Prefiltering ذخیره‌شده در Level مناسب
استفاده می‌کند.

چرا Bilinear روی Level 0 کافی نیست؟

Bilinear Filtering تنها چهار Texel نزدیک را ترکیب می‌کند.
اگر Footprint واقعی Pixel صدها Texel را پوشش دهد، چهار Sample
نمی‌توانند نماینده صحیح آن ناحیه باشند.

انتخاب Mip مناسب باعث می‌شود همان Footprint بزرگ به چند
Texel از Level کوچک‌تر نگاشت شود.

Mipmap چه مشکلاتی را کاملاً حل نمی‌کند؟

Mipmap یک تقریب مؤثر برای Footprintهای تقریباً مربعی است،
اما برای Footprintهای بسیار کشیده یا زاویه‌دار ممکن است کافی
نباشد.

محدودیت‌های اصلی Mipmap
وضعیت محدودیت راهکار تکمیلی
سطح با زاویه شدید Footprint کشیده Anisotropic Filtering
Mip تولیدشده نامناسب Aliasing باقی‌مانده Prefiltering بهتر
سوئیچ Level ناگهانی LOD Popping Trilinear Filtering
جزئیات Alpha Cutout کاهش Coverage Coverage Preservation
Temporal Aliasing Shimmering باقی‌مانده TAA یا روش‌های زمانی

Trade-off میان Blur و Aliasing

اگر فیلتر Mipmap بیش‌ازحد نرم باشد، Texture Blur می‌شود.
اگر فیلتر بیش‌ازحد تیز باشد، Aliasing و Shimmering باقی
می‌مانند.

تنظیم مناسب به نوع Asset، فاصله مشاهده، حرکت دوربین و سبک
بصری پروژه بستگی دارد.

آزمایش عملی Aliasing

روش‌های ارزیابی کیفیت Minification
آزمایش هدف
حرکت آرام دوربین تشخیص Shimmering
سطح مورب بلند بررسی نیاز به Anisotropy
Checkerboard ریز آشکارسازی Aliasing شدید
تغییر LOD Bias بررسی Blur و Sharpness
نمایش رنگی Mip Level مشاهده انتخاب Level
ضبط ویدئوی حرکت بررسی Temporal Stability


UNDER THE HOOD

چرا GPU نمی‌تواند جزئیات حذف‌شده را بعداً بازیابی کند؟

پس از Undersampling، چندین سیگنال یا Pattern متفاوت
می‌توانند مجموعه Sampleهای یکسانی تولید کنند. در این
مرحله اطلاعات کافی برای تشخیص Texture اصلی باقی نمانده
است.


01

Information Loss

Sampleهای محدود تمام تغییرات میان دو نقطه را ثبت
نمی‌کنند.


02

Ambiguous Reconstruction

چند الگوی فرکانسی مختلف می‌توانند در نرخ Sampling
پایین نتیجه مشابهی داشته باشند.


03

Low-Pass Filtering

فرکانس‌های غیرقابل نمایش باید پیش از کاهش Sampleها
حذف شوند.


04

Mip Selection

Texture Unit تلاش می‌کند Levelی را انتخاب کند که
Resolution آن با Footprint Pixel نزدیک باشد.


05

Temporal Behavior

تغییر جزئی مختصات می‌تواند Sampleها را روی Texelهای
متفاوت قرار دهد و خروجی را میان Frameها تغییر دهد.


06

Practical Rules

  • Mipmap را با Filter مناسب Asset بسازید.
  • کیفیت را در حرکت ارزیابی کنید.
  • LOD Bias منفی را با احتیاط استفاده کنید.
  • برای سطوح مورب Anisotropy را بررسی کنید.
  • Temporal Aliasing را جدا از Spatial Aliasing تحلیل کنید.

GPU چگونه Mip Level مناسب را انتخاب می‌کند؟

تا اینجا یاد گرفتیم که یک Texture ممکن است ده‌ها Mip Level
داشته باشد، اما هنوز یک سؤال بسیار مهم بی‌پاسخ مانده است.

GPU از کجا می‌فهمد کدام Level باید استفاده شود؟

آیا فاصله دوربین را اندازه می‌گیرد؟

آیا اندازه مدل را بررسی می‌کند؟

آیا تعداد Pixelهای جسم را می‌شمارد؟

چرا فاصله دوربین معیار مناسبی نیست؟

دو جسم می‌توانند دقیقاً در یک فاصله از دوربین قرار داشته
باشند اما اندازه کاملاً متفاوتی روی صفحه ایجاد کنند.



Camera

      │

      ▼

 ┌────────────┐

 Large Wall

 Occupies

 900 Pixels


 ┌───┐

 Small Sign

 Occupies

 35 Pixels

بنابراین فاصله تنها یکی از عوامل است.

چیزی که اهمیت دارد،

اندازه واقعی تصویر روی Screen است.

چیزی که واقعاً اهمیت دارد

GPU سعی می‌کند تخمین بزند

یک Pixel صفحه

چه ناحیه‌ای از Texture را پوشش می‌دهد.

این ناحیه را

Texture Footprint

می‌نامیم.

مثال

فرض کنید این Pixel روی صفحه دیده می‌شود.



Texture

┌─────────────────────────────┐

██████████████████████████████

██████████████████████████████

██████████████████████████████

██████████████████████████████

██████████████████████████████

└─────────────────────────────┘


One Screen Pixel

        ▲

covers this entire region

اگر این ناحیه

80×80 Texel

باشد،

نمونه‌برداری از فقط چهار Texel کافی نیست.

مسئله‌ای که Texture Unit باید حل کند

Texture Unit باید قبل از Sampling
پاسخ سه سؤال را پیدا کند.

تصمیم‌های Texture Unit

سؤال

اهمیت

Footprint چقدر بزرگ است؟

انتخاب Mip

شکل Footprint چیست؟

Anisotropic Filtering

مرکز Footprint کجاست؟

Sample Location

GPU این اطلاعات را از کجا به دست می‌آورد؟

پاسخ در Shader است.

هنگام اجرای Pixel Shader،
هر Pixel دارای مختصات Texture مخصوص خود است.



uv

↓

Pixel Shader

↓

Texture()

GPU تغییرات همین مختصات را
بین Pixelهای مجاور اندازه می‌گیرد.

مشتق‌های Texture Coordinate

برای تخمین اندازه Footprint،

GPU از مشتق‌های مختصات Texture استفاده می‌کند.

این مشتق‌ها معمولاً با دو تابع شناخته می‌شوند.



ddx(uv)

ddy(uv)

شهود موضوع

اگر مختصات Texture
بین دو Pixel مجاور

تقریباً ثابت بماند،

یعنی هر Pixel فقط قسمت کوچکی
از Texture را می‌بیند.

اما اگر مختصات Texture
خیلی سریع تغییر کند،

هر Pixel قسمت بزرگی از Texture
را پوشش می‌دهد.



Small Derivative

Pixel

↓

Tiny Texture Region



Large Derivative

Pixel

↓

Huge Texture Region

UNDER THE HOOD

وارد قلب Texture Unit شدیم…

تا اینجا فقط فهمیدیم که GPU
از مشتق‌های Texture Coordinate
برای تخمین اندازه Footprint استفاده می‌کند.

اما هنوز نمی‌دانیم

ddx و ddy واقعاً چگونه محاسبه می‌شوند؟

پاسخ این سؤال ما را وارد یکی از مهم‌ترین بخش‌های معماری GPU
یعنی

Pixel Quad

خواهد کرد؛ جایی که خواهیم دید چرا Pixel Shader همیشه به‌صورت
گروه‌های ۲×۲ اجرا می‌شود و چگونه همین ساختار، امکان محاسبه
مشتق‌ها و انتخاب خودکار Mip Level را فراهم می‌کند.

Pixel Quad؛ راز محاسبه مشتق‌ها

اکنون می‌دانیم GPU برای انتخاب Mipmap از مشتق‌های مختصات
Texture استفاده می‌کند.

اما یک سؤال مهم باقی مانده است.

GPU چگونه مشتق را برای یک Pixel محاسبه می‌کند، در حالی که
هر Pixel فقط مختصات خودش را می‌شناسد؟

پاسخ این سؤال، ما را وارد یکی از مهم‌ترین ویژگی‌های معماری
GPUهای مدرن می‌کند:

Pixel Quad

مشکل یک Pixel تنها

فرض کنید فقط یک Pixel در اختیار داریم.



Pixel

UV = (0.42 , 0.77)

از روی این اطلاعات،
هیچ راهی برای فهمیدن سرعت تغییر مختصات وجود ندارد.

مشتق همیشه به مقایسه حداقل دو نقطه احتیاج دارد.

برای محاسبه مشتق به همسایه نیاز داریم

اگر مختصات Pixel کناری را نیز بدانیم،
می‌توانیم میزان تغییر را اندازه بگیریم.



Pixel A

UV = (0.42 , 0.77)



Pixel B

UV = (0.44 , 0.77)



Difference

ΔU = 0.02

همین اختلاف کوچک،
همان چیزی است که بعدها به ddx تبدیل می‌شود.

چرا چهار Pixel؟

برای محاسبه تغییرات در هر دو جهت صفحه،
تنها داشتن دو Pixel کافی نیست.

GPU باید هم تغییرات افقی
و هم تغییرات عمودی را اندازه بگیرد.



A ---- B

|      |

|      |

C ---- D

این آرایش ۲×۲
همان چیزی است که Pixel Quad نامیده می‌شود.

تعریف Pixel Quad

ساختار Quad



Screen Pixels

+---------+---------+

|    A    |    B    |

+---------+---------+

|    C    |    D    |

+---------+---------+

این چهار Pixel
همزمان داخل یک گروه اجرایی قرار می‌گیرند.

Quad چه کمکی می‌کند؟

کاربردهای Pixel Quad

قابلیت

دلیل

ddx

اختلاف Pixelهای افقی

ddy

اختلاف Pixelهای عمودی

LOD

تخمین اندازه Footprint

Texture Filtering

انتخاب Mipmap

محاسبه ddx



A --------> B

UVA

UVB


ddx

≈ UVB − UVA

بنابراین ddx
تقریب اختلاف مختصات
در جهت افقی صفحه است.

محاسبه ddy



A

↓

C


ddy

≈ UVC − UVA

ddy نیز
نرخ تغییر مختصات
در راستای عمودی صفحه را نشان می‌دهد.

یک مثال عددی



A

(0.10 , 0.20)



B

(0.14 , 0.20)



C

(0.10 , 0.24)



ddx

=

0.04



ddy

=

0.04

مشاهده می‌کنیم
که GPU حتی بدون دانستن فاصله دوربین،
فقط از اختلاف مختصات
اندازه تغییر را استخراج می‌کند.

نکته بسیار مهم

UNDER THE HOOD

Quad فقط برای Texture نیست

وجود Pixel Quad
یکی از پایه‌های معماری Shaderهای مدرن است.

همین ساختار،
اجرای توابع

ddx()

و

ddy()

و همچنین بسیاری از بهینه‌سازی‌های داخلی GPU را ممکن می‌کند.

در بخش بعدی خواهیم دید
چگونه GPU از همین ddx و ddy
اندازه واقعی Footprint را محاسبه کرده،
فرمول مشهور

LOD = log₂(…)

را به دست می‌آورد
و دقیقاً Mip Level مناسب را انتخاب می‌کند.

از مشتق‌ها تا انتخاب Mip Level

اکنون دو مقدار مهم در اختیار GPU قرار دارد:

  • ddx(UV)
  • ddy(UV)

اما این دو مقدار هنوز مستقیماً شماره Mip Level را مشخص
نمی‌کنند.

ابتدا باید اندازه واقعی Footprint روی Texture تخمین زده شود.

Footprint را دوباره ببینیم

فرض کنید یک Pixel صفحه،
به جای یک Texel،
ناحیه‌ای از Texture را پوشش می‌دهد.



Texture

┌───────────────────────────────┐

████████████████████████████████

████████████████████████████████

████████████████████████████████

████████████████████████████████

████████████████████████████████

└───────────────────────────────┘

          ▲

      One Pixel

covers this region

هدف GPU این است که اندازه تقریبی این ناحیه را محاسبه کند.

مشتق‌ها چه چیزی را نشان می‌دهند؟

مشتق‌های Texture Coordinate
نرخ تغییر مختصات روی صفحه هستند.



ddx(U)

How much U changes

between neighboring pixels.



ddy(U)

How much U changes

vertically.

هرچه این تغییرات بزرگ‌تر باشند،
یعنی Pixel صفحه
قسمت بزرگ‌تری از Texture را پوشش می‌دهد.

چرا طول بردار مهم است؟

ddx و ddy
خودشان بردار هستند.

GPU ابتدا اندازه این بردارها را محاسبه می‌کند.



ddx =

(dxU , dxV)



Length

=

√(dxU² + dxV²)

این مقدار،
سرعت حرکت روی Texture
را نشان می‌دهد.

انتخاب بزرگ‌ترین جهت

معمولاً اندازه Footprint
در جهت افقی و عمودی
یکسان نیست.



Horizontal

Length = 3.2



Vertical

Length = 5.8

GPU معمولاً
بزرگ‌ترین مقدار را
مبنای انتخاب Mip قرار می‌دهد.

اندازه تقریبی Footprint

بعد از محاسبه مشتق‌ها،
Texture Unit
تخمین می‌زند که
هر Pixel تقریباً چند Texel
را پوشش می‌دهد.



Small Derivatives

↓

Footprint

≈ 1 Texel



Large Derivatives

↓

Footprint

≈ 64 Texels

چرا log₂؟

به خاطر دارید که
هر Level از Mipmap
نصف Level قبلی بود.



Level 0

1024



Level 1

512



Level 2

256



Level 3

128

بنابراین رابطه بین اندازه‌ها
به صورت توان‌های عدد ۲ است.

به همین دلیل
تابع لگاریتم پایه دو
طبیعی‌ترین انتخاب است.

شهود فرمول LOD

اگر Footprint

یک Texel باشد،

باید Level صفر انتخاب شود.

اگر اندازه Footprint

دو برابر شود،

باید یک Level پایین‌تر برویم.

اگر چهار برابر شود،

دو Level پایین‌تر.



Footprint

1 Texel

↓

LOD 0



2 Texels

↓

LOD 1



4 Texels

↓

LOD 2



8 Texels

↓

LOD 3

فرمول پایه LOD



LOD

=

log₂(Footprint Size)

این همان ایده اصلی است
که تقریباً تمام GPUهای مدرن
بر اساس آن
Level مناسب را انتخاب می‌کنند.

مثال عددی



Footprint

=

16 Texels



LOD

=

log₂(16)



LOD

=

4

بنابراین
GPU مستقیماً

Mip Level 4

را انتخاب می‌کند.

اگر LOD عدد صحیح نباشد چه می‌شود؟

در عمل،
اندازه Footprint
تقریباً هیچ‌وقت
دقیقاً توان عدد دو نیست.



LOD

=

3.42

این مقدار
بین دو Level قرار دارد.

در بخش بعد خواهیم دید
چگونه Trilinear Filtering
همین مقدار اعشاری را
به نرمی بین دو Mip ترکیب می‌کند.

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

Texture Unit
هرگز فاصله دوربین،
اندازه مدل
یا نوع Mesh را بررسی نمی‌کند.

تنها چیزی که برای انتخاب LOD لازم دارد،
مشتق‌های مختصات Texture است.

مسیر انتخاب LOD

مرحله

خروجی

Pixel Quad

همسایه‌ها

ddx / ddy

مشتق‌ها

Footprint

اندازه ناحیه

log₂

LOD

Texture Unit

انتخاب Mip

UNDER THE HOOD

نکته‌ای که معمولاً کتاب‌ها از آن عبور می‌کنند

فرمولی که در این بخش دیدیم، نسخه ساده‌شده مفهوم LOD است.

در سخت‌افزار واقعی، GPU تنها یک عدد را محاسبه نمی‌کند؛ بلکه
بردارهای مشتق، طول آن‌ها، محور غالب (Major Axis)، نسبت کشیدگی
Footprint و محدودیت‌های Sampler را نیز در نظر می‌گیرد.

همین اطلاعات در ادامه مشخص می‌کند که آیا
Bilinear کافی است،
باید از Trilinear Filtering استفاده شود،
یا حتی لازم است
Anisotropic Filtering
وارد عمل شود.

چرا Bilinear Filtering کافی نیست؟

در بخش قبل دیدیم که GPU با استفاده از مشتق‌های
ddx
و
ddy
مقدار LOD را محاسبه می‌کند.

اما تقریباً همیشه این مقدار یک عدد اعشاری است.



LOD

=

3.37

مشکل اینجاست که Mipmap فقط Levelهای صحیح دارد.



Mip 0

Mip 1

Mip 2

Mip 3

Mip 4

Mip 5

اگر نزدیک‌ترین Level را انتخاب کنیم چه می‌شود؟

فرض کنید

LOD = 3.49

GPU ممکن است فقط

Level 3

را انتخاب کند.

اما فقط با یک حرکت بسیار کوچک دوربین،

مقدار LOD به

3.51

برسد.

اکنون GPU ناگهان

Level 4

را انتخاب می‌کند.



LOD

3.49

↓

Mip 3



Camera moves slightly



LOD

3.51

↓

Mip 4

نتیجه چیست؟

ناگهان وضوح Texture تغییر می‌کند.

این همان پدیده‌ای است که قبلاً با نام

LOD Popping

شناختیم.

ایده اصلی Trilinear Filtering

به جای انتخاب تنها یک Level،

GPU دو Level مجاور را انتخاب می‌کند.



LOD = 3.37



Mip 3



Mip 4

سپس خروجی این دو Level
با هم ترکیب می‌شود.

دو Bilinear مستقل

ابتدا روی هر Mip
یک Bilinear Filtering
انجام می‌شود.



Mip 3

↓

Bilinear Sample



Mip 4

↓

Bilinear Sample

اکنون دو رنگ مستقل
در اختیار GPU قرار دارد.

مرحله دوم

حالا GPU
این دو رنگ را
با نسبت مناسب
مخلوط می‌کند.



Color

from Mip 3



Blend



Color

from Mip 4

ضریب ترکیب از کجا می‌آید؟

بخش اعشاری LOD
دقیقاً همین ضریب را مشخص می‌کند.



LOD

=

3.37



Integer Part

3



Fraction

0.37

بنابراین

37٪

از Level چهار

و

63٪

از Level سه

استفاده می‌شود.

فرمول ترکیب



Final Color

=

(1−t)

×

MipLow



+

t

×

MipHigh

که در آن

t

همان قسمت اعشاری LOD است.

نتیجه بصری



LOD

3.00

↓

100%

Mip3



LOD

3.25

↓

75%

Mip3

25%

Mip4



LOD

3.50

↓

50%

50%



LOD

3.75

↓

25%

75%



LOD

4.00

↓

100%

Mip4

چرا Trilinear؟

Bilinear
روی دو محور Texture

(U و V)

عمل می‌کند.

Trilinear
علاوه بر این دو محور،

روی محور سوم یعنی

Mipmap Level

نیز Interpolation انجام می‌دهد.



Axis 1

U



Axis 2

V



Axis 3

Mip Level

هزینه Trilinear

هر Bilinear
چهار Texel
را می‌خواند.

Trilinear
دو Bilinear انجام می‌دهد.



Bilinear

4 Texels



Trilinear

8 Texels

آیا Trilinear دو برابر کندتر است؟

از نظر تئوری،
تعداد Sampleها دو برابر می‌شود.

اما GPUهای مدرن
این عملیات را
داخل Texture Unit
به‌شدت بهینه کرده‌اند.

مقایسه Bilinear و Trilinear

ویژگی

Bilinear

Trilinear

Mip

یک Level

دو Level

Texel Reads

4

8

LOD Popping

زیاد

تقریباً حذف می‌شود

کیفیت

متوسط

بالا

UNDER THE HOOD

داخل Texture Unit چه اتفاقی می‌افتد؟

Texture Unit
ابتدا مقدار LOD را محاسبه می‌کند.

سپس دو Level مجاور را انتخاب می‌کند،
برای هرکدام یک Bilinear Sample می‌گیرد
و در پایان با استفاده از بخش اعشاری LOD
نتیجه را Interpolate می‌کند.



ddx / ddy

↓

LOD

↓

Mip 3

↓

Bilinear



Mip 4

↓

Bilinear

↓

Linear Blend

↓

Final Color

در فصل بعد خواهیم دید که حتی Trilinear نیز برای سطوحی که با زاویه
شدید دیده می‌شوند کافی نیست، زیرا Footprint دیگر مربع نیست، بلکه
به یک بیضی کشیده تبدیل می‌شود. همین مسئله دلیل تولد
Anisotropic Filtering
است.

آیا Trilinear Filtering پایان ماجراست؟

تا اینجا به نظر می‌رسد تمام مشکلات Texture Sampling حل شده‌اند.

  • ✔ Mipmap تولید شد.
  • ✔ GPU مقدار LOD را محاسبه کرد.
  • ✔ دو Mip با Trilinear ترکیب شدند.

اما هنوز یک مشکل بسیار مهم باقی مانده است.

اگر سطح با زاویه زیاد دیده شود چه اتفاقی می‌افتد؟

یک مثال واقعی

فرض کنید روبه‌روی یک دیوار ایستاده‌اید.



Camera

↓

████████████████████████

████████████████████████

████████████████████████

در این حالت تقریباً تمام Pixelها
اندازه مشابهی از Texture را مشاهده می‌کنند.

حالا دوربین را بچرخانید

اکنون دیوار را با زاویه بسیار کم نگاه می‌کنیم.



Camera

   

    

     

██████████████████████████

در این حالت شکل Footprint کاملاً تغییر می‌کند.

فرض Bilinear و Trilinear

تقریباً تمام مطالبی که تاکنون بررسی کردیم
یک فرض پنهان داشتند.

فرض می‌کردیم Footprint تقریباً مربع است.



Ideal Footprint

┌───────┐

│       │

│       │

└───────┘

اما در واقعیت…

هنگام مشاهده سطح با زاویه،
Footprint دیگر مربع نیست.



Real Footprint

┌─────────────────────────────┐

│                             │

└─────────────────────────────┘

در بسیاری از موارد،
این ناحیه ده‌ها برابر کشیده‌تر از عرض خود است.

چرا این موضوع مهم است؟

Trilinear فقط یک Mip Level انتخاب می‌کند.

یعنی فرض می‌کند
Resolution موردنیاز
در تمام جهت‌ها یکسان است.



Texture Detail

←──────────────→



Same Resolution

in every direction

اما Footprint کشیده
چنین رفتاری ندارد.

محور بزرگ و محور کوچک

هر Footprint را می‌توان با دو محور توصیف کرد.



        Minor Axis

            ↑

            │

────────────┼────────────

            │

            ▼



<────────────── Major Axis ──────────────>

یکی از این محورها
بسیار بزرگ‌تر از دیگری است.

مشکل یک LOD واحد

اگر GPU فقط یک Level انتخاب کند،
باید بین دو حالت یکی را انتخاب کند.

نتیجه انتخاب یک LOD

انتخاب

نتیجه

Mip بزرگ‌تر

Aliasing

Mip کوچک‌تر

Blur شدید

مثال باند فرودگاه

مشهورترین مثال،
Texture آسفالت باند فرودگاه است.

نزدیک دوربین،
خطوط بسیار واضح هستند.

اما هرچه دورتر می‌شوند،
Texture تقریباً به یک نوار بسیار باریک تبدیل می‌شود.



Near Camera

██████████████████████



Far Away

====================

دقیقاً همینجا Trilinear شکست می‌خورد.

آثار بصری

نشانه‌های کمبود Anisotropic Filtering

Artifact

توضیح

Blur

از دست رفتن جزئیات دوردست

Shimmering

لرزش هنگام حرکت دوربین

Aliasing

خطوط و Patternهای کاذب

Moiré

ایجاد موج‌های مصنوعی

ایده اصلی Anisotropic Filtering

به جای اینکه Footprint را
یک مربع فرض کنیم،

GPU شکل واقعی آن را
در نظر می‌گیرد.



Square Approximation

□



Real Approximation

══════════════════

سپس Sampleها
در امتداد محور بزرگ Footprint
توزیع می‌شوند.

توزیع Sampleها



Without AF

×

×

×

×



With AF

×──×──×──×──×──×──×

به جای چهار Sample نزدیک،
GPU چندین Sample را
در امتداد محور کشیده قرار می‌دهد.

نسبت Anisotropy

اگر طول محور بزرگ
چهار برابر محور کوچک باشد،

نسبت Anisotropy برابر است با:



Major Axis

16



Minor Axis

4



Ratio

=

4 : 1

مقادیر رایج

سطوح رایج Anisotropic Filtering

تنظیم

بیشترین نسبت

2×

2:1

4×

4:1

8×

8:1

16×

16:1

UNDER THE HOOD

Trilinear و Anisotropic رقیب هم نیستند

یکی از رایج‌ترین برداشت‌های اشتباه این است که
Anisotropic Filtering جایگزین Trilinear Filtering می‌شود.

در واقع چنین نیست.



Texture Coordinate

↓

ddx / ddy

↓

LOD

↓

Two Neighbor Mips

↓

Trilinear Filtering

↓

Anisotropic Sample Distribution

↓

Final Color

در GPUهای مدرن، Anisotropic Filtering معمولاً **بر پایه Trilinear Filtering** ساخته می‌شود؛ یعنی ابتدا Mip مناسب انتخاب می‌شود و سپس تعداد و محل Sampleها در امتداد محور بزرگ Footprint تنظیم می‌گردد.

Footprint واقعی یک مربع نیست

تا اینجا برای ساده شدن بحث،
Footprint را تقریباً یک مربع فرض کردیم.

اما GPU چنین فرضی نمی‌کند.

در واقعیت، هر Pixel روی صفحه
معمولاً ناحیه‌ای چهارضلعی یا تقریباً بیضوی
از Texture را پوشش می‌دهد.



Simple Approximation

┌────────┐

│        │

└────────┘



Real Footprint

      ________

   .-'        '-.

  /              

                /

   '-.________.-'

این شکل از کجا به دست می‌آید؟

تمام اطلاعات موردنیاز
داخل دو بردار مشتق قرار دارد.



ddx

(dxU , dxV)



ddy

(dyU , dyV)

این دو بردار،
دو ضلع اصلی ناحیه‌ای را تشکیل می‌دهند
که یک Pixel روی Texture اشغال می‌کند.

اولین تقریب: متوازی‌الاضلاع

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



         ddy

        ↑

       /

      /

A ─────────► ddx

 

  

   B

این شکل،
تقریب بسیار خوبی از Footprint واقعی است.

چرا از بیضی صحبت می‌کنیم؟

بسیاری از GPUها
برای ساده‌تر شدن محاسبات Filtering،
این متوازی‌الاضلاع را
به یک بیضی معادل تبدیل می‌کنند.



Parallelogram

╱────────╲

╲────────╱



↓

Approximation



     _______

   /         

  |           |

   _________/

به همین دلیل در مقالات علمی،
اصطلاح

Elliptical Footprint

بسیار رایج است.

محور بزرگ و محور کوچک چگونه پیدا می‌شوند؟

طول دو بردار مشتق
اطلاعات اولیه را فراهم می‌کند.



|ddx|

=

3.1



|ddy|

=

9.4

در این مثال،
محور عمودی تقریباً سه برابر
محور افقی است.

محاسبه نسبت Anisotropy



Anisotropy

=

Major Axis

────────────

Minor Axis

اگر این نسبت

6.2

باشد،
یعنی Footprint حدود شش برابر
در یک جهت کشیده‌تر است.

چرا Sample بیشتری لازم است؟

فرض کنید طول Footprint
ده برابر عرض آن باشد.



□□□□□□□□□□□□□□□

□

اگر فقط چهار Sample بگیریم،
بخش بزرگی از Texture
اصلاً خوانده نخواهد شد.

راه‌حل GPU

Sampleها
در امتداد محور بزرگ
پخش می‌شوند.



Without AF

×

×

×

×





With AF

×

──×

────×

──────×

────────×

──────────×

────────────×

ترتیب عملیات



Determine

Footprint



↓

Major Axis



↓

Choose

Sample Count



↓

Sample Along Axis



↓

Average

Results

GPU چگونه تعداد Sample را انتخاب می‌کند؟

هرچه نسبت کشیدگی بیشتر باشد،
Sample بیشتری لازم است.

نمونه‌ای از انتخاب Sample

نسبت

Sample تقریبی

1×

Bilinear

2×

2 Sample

4×

4 Sample

8×

8 Sample

16×

16 Sample

چرا همیشه Sample نامحدود نمی‌گیریم؟

چون هر Sample
یعنی Texture Fetch جدید.

تعداد زیاد Sample
هم پهنای باند حافظه را افزایش می‌دهد
و هم بار Texture Unit را بیشتر می‌کند.



More Samples

↓

Higher Quality



More Samples

↓

More Memory Reads

چرا اکثر GPUها تا 16× محدود هستند؟

بررسی‌های تجربی نشان داده است
که پس از حدود

16×

افزایش کیفیت بسیار کم می‌شود،
اما هزینه سخت‌افزاری همچنان افزایش پیدا می‌کند.

کیفیت نسبی

AF

کیفیت

هزینه

2×

متوسط

کم

4×

خوب

متوسط

8×

بسیار خوب

زیاد

16×

نزدیک به حداکثر

زیاد

UNDER THE HOOD

واقعاً داخل Texture Unit چه اتفاقی می‌افتد؟

در سخت‌افزارهای مدرن،
Anisotropic Filtering
به معنی اجرای یک الگوریتم ثابت و واحد نیست.

هر سازنده GPU
(NVIDIA، AMD، Intel و Apple)
تقریب مخصوص خود را برای محاسبه Footprint،
انتخاب محور غالب،
تعداد Sampleها و محل قرارگیری آن‌ها پیاده‌سازی می‌کند.



Pixel Quad

↓

ddx / ddy

↓

Footprint

↓

Major Axis

↓

Anisotropy Ratio

↓

Choose Samples

↓

Multiple Trilinear Fetches

↓

Weighted Average

↓

Final Pixel

به همین دلیل ممکن است خروجی دو GPU مختلف با وجود استفاده از تنظیم
16× AF
کاملاً یکسان نباشد؛ زیرا استاندارد API تنها نتیجه مورد انتظار را مشخص
می‌کند، نه نحوه دقیق پیاده‌سازی داخلی.

داخل Texture Unit چه اتفاقی می‌افتد؟

تاکنون هر قسمت از فرآیند Sampling را جداگانه بررسی کردیم.

اکنون زمان آن رسیده است که کل مسیر اجرای یک دستور
texture()
را از ابتدا تا انتها مشاهده کنیم.

برخلاف تصور رایج،
Texture Sampling تنها یک خواندن ساده از حافظه نیست؛
بلکه زنجیره‌ای از تصمیم‌گیری‌ها، محاسبات ریاضی و فیلترگذاری
در مدت چند نانوثانیه انجام می‌شود.

نمای کلی Pipeline



Texture()

      │

      ▼

Receive UV

      │

      ▼

Pixel Quad

      │

      ▼

ddx / ddy

      │

      ▼

Footprint

      │

      ▼

LOD

      │

      ▼

Mip Selection

      │

      ▼

Filtering

      │

      ▼

Return Color

مرحله ۱
دریافت مختصات Texture

Pixel Shader مختصات UV را
به Texture Unit ارسال می‌کند.



float4 color =

Texture.Sample

(

Sampler,

uv

);

این تنها اطلاعاتی نیست که Texture Unit دریافت می‌کند.

مرحله ۲
تشکیل Pixel Quad

GPU چهار Fragment مجاور
را کنار هم قرار می‌دهد.



A  B

C  D

این گروه کوچک
مبنای تمام محاسبات مشتق است.

مرحله ۳
محاسبه مشتق‌ها



ddx(uv)



ddy(uv)

اکنون GPU می‌داند
مختصات Texture
روی صفحه
با چه سرعتی تغییر می‌کنند.

مرحله ۴
ساخت Footprint

مشتق‌ها
اندازه تقریبی ناحیه‌ای را
که هر Pixel از Texture پوشش می‌دهد
مشخص می‌کنند.



ddx

+

ddy

↓

Footprint

مرحله ۵
محاسبه LOD



LOD

=

log₂

(

Footprint

)

نتیجه معمولاً
یک مقدار اعشاری است.

مرحله ۶
انتخاب Mipmap



LOD

3.42



Mip3



Mip4

دو Level مجاور
برای Filtering آماده می‌شوند.

مرحله ۷
Bilinear Filtering

روی هر Mip،
چهار Texel
خوانده می‌شود.



Texel

●──●

│  │

●──●

مرحله ۸
Trilinear Filtering

خروجی دو Bilinear
با نسبت اعشاری LOD
ترکیب می‌شود.



Mip3

↓

Color A



Mip4

↓

Color B



↓

Blend

مرحله ۹
Anisotropic Filtering (در صورت نیاز)

اگر Footprint کشیده باشد،
Texture Unit
چندین Sample
در امتداد محور اصلی
دریافت می‌کند.



×

──×

────×

──────×

────────×

مرحله ۱۰
بازگرداندن رنگ نهایی

پس از پایان تمام فیلترها،
فقط یک رنگ نهایی
به Pixel Shader برمی‌گردد.



Texture Unit

↓

RGBA

↓

Pixel Shader

خلاصه کل فرآیند

مراحل داخلی Texture Sampling

مرحله ورودی خروجی
Texture Coordinate UV مختصات اولیه
Pixel Quad ۴ Fragment همسایه‌ها
Derivatives Quad ddx / ddy
Footprint مشتق‌ها اندازه ناحیه
LOD Footprint Mip Level
Filtering Mipها رنگ نهایی

همه این مراحل چقدر طول می‌کشند؟

از دید برنامه‌نویس،
تنها یک فراخوانی
texture()
نوشته می‌شود.

اما در سطح سخت‌افزار،
تمام مراحل قبلی
به صورت Pipeline و موازی
داخل Texture Unit اجرا می‌شوند.

UNDER THE HOOD

آنچه واقعاً هنگام اجرای texture() رخ می‌دهد



Pixel Shader

      │

      ▼

Texture Coordinate

      │

      ▼

Texture Unit

      │

      ├── Pixel Quad

      ├── ddx / ddy

      ├── Footprint

      ├── LOD

      ├── Mip Selection

      ├── Bilinear

      ├── Trilinear

      ├── Anisotropic

      ▼

Filtered Color

      │

      ▼

Pixel Shader Continues

برای برنامه‌نویس، همه این مراحل تنها در قالب یک تابع ساده دیده می‌شوند؛ اما درون GPU، ده‌ها مدار تخصصی به‌صورت هم‌زمان و Pipeline شده کار می‌کنند تا رنگ نهایی را در کمترین زمان ممکن تولید کنند.

Sampler State چیست؟

تا اینجا تقریباً تمام مراحل داخلی Texture Sampling را بررسی کردیم.

اما هنوز یک سؤال مهم باقی مانده است.

GPU از کجا می‌فهمد Texture را چگونه بخواند؟

فرض کنید مختصات UV خارج از محدوده
0.0 → 1.0
باشد.

یا فرض کنید بخواهیم از Bilinear استفاده کنیم،
یا Trilinear،
یا Anisotropic.

تمام این رفتارها توسط شیئی به نام
Sampler State
کنترل می‌شوند.

Texture و Sampler یکی نیستند

یکی از رایج‌ترین اشتباهات برنامه‌نویسان تازه‌کار،
یکسان دانستن Texture و Sampler است.

تفاوت Texture و Sampler

Texture

Sampler

داده تصویری

قوانین خواندن داده

Texelها

Filtering

Mipmapها

Address Mode

در حافظه ذخیره می‌شود

مجموعه تنظیمات Sampling

یک تشبیه ساده

Texture را مانند یک کتاب در نظر بگیرید.

Sampler تعیین می‌کند که این کتاب
چگونه خوانده شود.



Texture

↓

Image Data



Sampler

↓

Reading Rules

Sampler چه تنظیماتی دارد؟

مهم‌ترین تنظیمات Sampler

گزینه

وظیفه

Min Filter

Minification

Mag Filter

Magnification

Mip Filter

انتخاب بین Mipmapها

Address Mode

رفتار UV خارج از محدوده

Max Anisotropy

کیفیت AF

LOD Bias

تغییر دستی LOD

Border Color

رنگ خارج از Texture

اولین تصمیم Sampler

اگر مختصات UV از محدوده
استاندارد خارج شود چه باید کرد؟



UV

=

1.35



or



UV

=

−0.42

پاسخ این سؤال را
Address Mode مشخص می‌کند.

انواع Address Mode

حالت‌های رایج Addressing

Mode

رفتار

Wrap

تکرار Texture

Clamp

قفل شدن روی لبه

Mirror

تکرار آینه‌ای

Border

استفاده از Border Color

Wrap Mode

رایج‌ترین حالت Sampling است.



UV

1.20

↓

0.20



UV

2.65

↓

0.65

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

Clamp Mode

مختصات خارج از Texture
روی نزدیک‌ترین لبه قفل می‌شود.



UV

−0.30

↓

0.00



UV

1.72

↓

1.00

Mirror Mode

در هر بار تکرار،
Texture برعکس می‌شود.



Texture

ABCDE



Repeat

ABCDE

EDCBA

ABCDE

EDCBA

Border Mode

خارج از Texture،
هیچ Texelی خوانده نمی‌شود.

در عوض،
رنگ Border بازگردانده می‌شود.



Texture

□□□□□□



Outside

↓

Border Color

مقایسه حالت‌ها

انتخاب مناسب Address Mode

Mode

کاربرد

Wrap

Terrain، Tile، Brick

Clamp

UI، Shadow Map

Mirror

Patternهای متقارن

Border

برخی Shadow Techniques

UNDER THE HOOD

Sampler State قبل از Texture Fetch اجرا می‌شود

Texture Unit پیش از آنکه حتی یک Texel را از حافظه بخواند، ابتدا Sampler State را بررسی می‌کند. اگر مختصات UV خارج از محدوده باشند، Address Mode آن‌ها را اصلاح می‌کند؛ سپس Filtering، انتخاب Mipmap و سایر مراحل آغاز می‌شوند.



UV

↓

Address Mode

↓

Valid UV

↓

LOD

↓

Filtering

↓

Final Color

به همین دلیل، **Texture و Sampler دو منبع مستقل هستند**؛ یک Texture می‌تواند با Samplerهای مختلف (Wrap، Clamp، Anisotropic و…) استفاده شود، بدون اینکه داده‌های Texture تغییری کنند.

Filter Mode چیست؟

پس از اینکه Address Mode مختصات UV را اصلاح کرد،
Texture Unit باید تصمیم بگیرد
رنگ نهایی چگونه محاسبه شود.

آیا فقط یک Texel خوانده شود؟

یا چهار Texel؟

یا هشت Texel؟

یا حتی چندین Sample در امتداد یک محور؟

این تصمیم توسط
Filter Mode
گرفته می‌شود.

Filter دقیقاً چه چیزی را مشخص می‌کند؟



Texture Coordinate

↓

Sampler

↓

Which Texels?

↓

How Many?

↓

How To Blend?

بنابراین Filter فقط تعداد Texelها را مشخص نمی‌کند،
بلکه نحوه ترکیب آن‌ها را نیز تعیین می‌کند.

سه نوع Filter مستقل

برخلاف تصور بسیاری از افراد،
Sampler فقط یک Filter ندارد.

Filterهای مستقل Sampler

Filter

زمان استفاده

Min Filter

هنگام کوچک شدن Texture

Mag Filter

هنگام بزرگ شدن Texture

Mip Filter

بین Mipmapها

Point Filtering

ساده‌ترین روش Sampling است.

فقط نزدیک‌ترین Texel خوانده می‌شود.



●

Only One Texel

Bilinear Filtering

چهار Texel مجاور
خوانده می‌شوند.



●────●

│    │

│ X  │

│    │

●────●

رنگ نهایی
میانگین وزن‌دار
این چهار Texel است.

Trilinear Filtering

ابتدا دو Bilinear مستقل
روی دو Mipmap مجاور اجرا می‌شوند.

سپس خروجی آن‌ها
با هم ترکیب می‌شود.



Mip A

↓

Bilinear



Mip B

↓

Bilinear



↓

Blend

Anisotropic Filtering

پیشرفته‌ترین Filter سخت‌افزاری
برای Texture Sampling است.

Sampleها
در امتداد محور اصلی Footprint
توزیع می‌شوند.



×

──×

────×

──────×

────────×

ترکیب Filterها

Filterهای Min، Mag و Mip
مستقل از هم هستند.

نمونه ترکیب Filterها

Min

Mag

Mip

نتیجه

Point

Point

Point

Nearest Sampling

Linear

Linear

Point

Bilinear + Nearest Mip

Linear

Linear

Linear

Trilinear

Anisotropic

Linear

Linear

Full AF

چرا Min و Mag جدا هستند؟

چون رفتار Texture
هنگام بزرگ شدن
کاملاً با کوچک شدن متفاوت است.



Magnification

1 Texel

↓

Many Pixels



Minification

Many Texels

↓

1 Pixel

به همین دلیل
ممکن است Min Filter
بسیار پیچیده‌تر از Mag Filter باشد.

این تنظیمات در API چگونه دیده می‌شوند؟

نمونه Filterهای رایج در APIها

نام

توضیح

Point

بدون Interpolation

Linear

Bilinear

Linear + Linear Mip

Trilinear

Anisotropic

سخت‌افزاری

مقایسه کیفیت

کیفیت و هزینه Filterها

Filter

کیفیت

هزینه

Point

کم

بسیار کم

Bilinear

خوب

کم

Trilinear

بسیار خوب

متوسط

16× AF

عالی

زیاد

UNDER THE HOOD

Sampler State در واقع یک «برنامه کوچک» برای Texture Unit است

Texture Unit هنگام اجرای دستور texture() فقط به Texture نگاه نمی‌کند. ابتدا Sampler State را می‌خواند تا بداند:

  • اگر UV خارج از محدوده بود چه رفتاری داشته باشد.
  • برای Minification از چه فیلتری استفاده کند.
  • برای Magnification از چه فیلتری استفاده کند.
  • آیا بین Mipmapها Interpolation انجام شود یا خیر.
  • آیا Anisotropic Filtering فعال باشد.
  • حداکثر نسبت Anisotropy چند باشد.


Texture

      +

Sampler State

        │

        ▼

Texture Unit

        │

        ▼

Filtered Result

به همین دلیل در موتورهای بازی و APIهایی مانند Direct3D و Vulkan، **Texture Resource** و **Sampler State** دو شیء مستقل هستند و می‌توان یک Texture را با Samplerهای مختلف، بدون کپی کردن داده‌ها، استفاده کرد.

LOD Bias چیست؟

تاکنون فرض کردیم که GPU همیشه مناسب‌ترین Mip Level را انتخاب می‌کند.

اما گاهی برنامه‌نویس یا موتور بازی می‌خواهد
این انتخاب را کمی تغییر دهد.

اگر بخواهیم همیشه Texture کمی شارپ‌تر یا کمی نرم‌تر دیده شود چه باید کرد؟

پاسخ این سؤال،
LOD Bias
است.

تعریف LOD Bias

فرمول



Final LOD

=

Computed LOD

+

LOD Bias

Bias منفی

اگر Bias منفی باشد،
GPU به سمت Mipmapهای بزرگ‌تر می‌رود.



LOD

4.0



Bias

−1



Final

3.0

نتیجه:

  • ✔ تصویر شارپ‌تر
  • ✔ جزئیات بیشتر
  • ✖ احتمال Aliasing بیشتر

Bias مثبت



LOD

4.0



Bias

+1



Final

5.0

نتیجه:

  • ✔ تصویر نرم‌تر
  • ✔ Aliasing کمتر
  • ✖ جزئیات کمتر

کاربردهای LOD Bias

کاربردهای رایج

سناریو Bias

Sharpen Texture

منفی

کاهش Shimmering

مثبت

تنظیم هنری پروژه

هر دو

MinLOD و MaxLOD

گاهی لازم است GPU
اجازه نداشته باشد
از تمام Mipmapها استفاده کند.

برای همین دو محدودیت تعریف می‌شود.



LOD

↓

Clamp

↓

MinLOD

↓

MaxLOD

مثال MinLOD



Computed LOD

1.4



MinLOD

3



Final LOD

3

حتی اگر GPU
بخواهد Mip 1 را انتخاب کند،
پایین‌تر از Mip 3 نخواهد رفت.

مثال MaxLOD



Computed

7.2



MaxLOD

5



Final

5

چرا این محدودیت‌ها مفید هستند؟

کاربرد MinLOD و MaxLOD

قابلیت

کاربرد

MinLOD

جلوگیری از Texture بسیار شارپ

MaxLOD

جلوگیری از Texture بسیار تار

هر دو

کنترل هنری و بهینه‌سازی

Comparison Sampler

نوع خاصی از Sampler وجود دارد که
به جای بازگرداندن رنگ،
نتیجه یک مقایسه را برمی‌گرداند.

این Sampler
تقریباً همیشه برای

Shadow Mapping

استفاده می‌شود.



Depth Texture

↓

Compare

↓

Visible ?

↓

0 or 1

مثال



Current Depth

0.42



Shadow Map

0.40



0.42 >

0.40



Pixel

In Shadow

UNDER THE HOOD

Sampler فقط فیلتر انتخاب نمی‌کند

در GPUهای مدرن، Sampler State مجموعه‌ای از قوانین است که قبل از هر Texture Fetch اجرا می‌شود. این قوانین مشخص می‌کنند مختصات چگونه اصلاح شوند، چه Mipmapی انتخاب شود، LOD چگونه تغییر کند، چه فیلتری اعمال شود و حتی در بعضی حالت‌ها آیا مقدار خوانده‌شده باید با یک مقدار مرجع مقایسه شود یا خیر.



UV

↓

Address Mode

↓

LOD Bias

↓

Clamp LOD

↓

Filtering

↓

Comparison (Optional)

↓

Final Result

به همین دلیل Sampler را می‌توان «کنترل‌کننده رفتار Texture Unit» دانست، نه صرفاً مجموعه‌ای از گزینه‌های Filtering.

چرا Texture Sampling این‌قدر سریع است؟

اگر به تمام مطالب این فصل نگاه کنیم،
ممکن است تصور کنیم Texture Sampling
عملیاتی بسیار سنگین است.

  • محاسبه مشتق‌ها
  • محاسبه LOD
  • انتخاب Mipmap
  • Bilinear یا Trilinear Filtering
  • Anisotropic Filtering
  • خواندن چندین Texel از حافظه

سؤال طبیعی این است:

اگر هر Pixel چندین Texel از حافظه بخواند،
چرا GPU به شدت کند نمی‌شود؟

پاسخ در معماری حافظه GPU نهفته است.

دسترسی به حافظه بسیار گران است

واحدهای پردازشی GPU
می‌توانند میلیاردها عملیات محاسباتی
را در هر ثانیه انجام دهند.

اما دسترسی مستقیم به حافظه اصلی
(VRAM)
چندین برابر کندتر است.



Shader Core

↓

Needs Texel



VRAM

(High Latency)

اگر هر Texture Fetch
مستقیماً به VRAM مراجعه کند،
بیشتر زمان GPU صرف انتظار خواهد شد.

ایده Cache

به جای مراجعه مداوم به حافظه اصلی،
GPU داده‌هایی را که احتمال استفاده مجدد دارند،
در حافظه‌ای بسیار سریع نگه می‌دارد.



Texture Unit

      │

      ▼

Texture Cache

      │

      ▼

VRAM

این حافظه کوچک اما بسیار سریع،
همان Texture Cache است.

تعریف Texture Cache

Cache Hit و Cache Miss

هر درخواست Texture
ابتدا Cache را بررسی می‌کند.



Texture Fetch

      │

      ▼

Texture Cache

   │        │

Hit       Miss

 │          │

 ▼          ▼

Fast      Read VRAM

Cache Hit

اگر Texel موردنیاز
داخل Cache باشد،
نتیجه تقریباً بلافاصله
بازگردانده می‌شود.

  • ✔ بدون مراجعه به VRAM
  • ✔ تأخیر بسیار کم
  • ✔ مصرف انرژی کمتر

Cache Miss

اگر Texel داخل Cache نباشد،
Texture Unit مجبور است
آن را از VRAM بخواند.



Cache

✖



↓

VRAM Read



↓

Cache Update

پس از خواندن،
Texel داخل Cache ذخیره می‌شود
تا درخواست‌های بعدی سریع‌تر باشند.

چرا Cache مؤثر است؟

زیرا Pixelهای مجاور
معمولاً Texelهای مجاور را
Sample می‌کنند.



Pixels

A B C D



↓

Need



Texels

20

21

22

23

بنابراین احتمال استفاده مجدد
از همان داده‌ها بسیار زیاد است.

Spatial Locality

این ویژگی را
Spatial Locality
می‌نامند.

Temporal Locality

علاوه بر نزدیکی مکانی،
بسیاری از داده‌ها
در مدت کوتاهی دوباره استفاده می‌شوند.



Texel

25

↓

Used

↓

Used Again

↓

Used Again

این ویژگی را
Temporal Locality
می‌نامند.

مزایای Texture Cache

تأثیر Texture Cache

ویژگی

نتیجه

Cache Hit

کاهش زمان Sampling

کاهش VRAM Reads

کاهش پهنای باند

مصرف انرژی

کمتر

Throughput

بیشتر

UNDER THE HOOD

Texture Unit تقریباً هیچ‌وقت فقط یک Texel نمی‌خواند

یکی از مهم‌ترین ویژگی‌های معماری GPU این است که هنگام وقوع یک Cache Miss، معمولاً تنها Texel درخواست‌شده از حافظه خوانده نمی‌شود.

در عوض، سخت‌افزار یک **بلوک کامل از Texelهای مجاور** را وارد Cache می‌کند؛ زیرا احتمال بسیار زیادی وجود دارد که Pixelهای بعدی به همان ناحیه نیاز داشته باشند.



Request

Texel 25

        │

        ▼

VRAM

        │

        ▼

Read Block

24 25 26 27
40 41 42 43

        │

        ▼

Texture Cache

همین اصل ساده، پایه‌ی تمام بهینه‌سازی‌های Texture Sampling در GPUهای مدرن است و در بخش بعد خواهیم دید که چگونه این بلوک‌ها در حافظه به شکلی خاص (Swizzled / Morton Order) ذخیره می‌شوند تا احتمال Cache Hit به حداکثر برسد.

یک باور اشتباه

بسیاری تصور می‌کنند وقتی Shader یک Texel درخواست می‌کند،
GPU دقیقاً همان یک Texel را از حافظه می‌خواند.

در واقع تقریباً هیچ GPU مدرنی چنین کاری انجام نمی‌دهد.

دلیل این موضوع بسیار ساده است.

خواندن یک Texel یا خواندن چند Texel مجاور،
تقریباً هزینه مشابهی برای دسترسی به VRAM دارد.

Cache Line چیست؟

بنابراین GPU به جای انتقال یک Texel،
یک بلوک کامل از Texelهای مجاور را منتقل می‌کند.

Block Fetch

فرض کنید Shader فقط Texel شماره ۱۸ را نیاز دارد.



Requested

↓

18

اما GPU ممکن است این بلوک را وارد Cache کند.



16 17 18 19

20 21 22 23

چون احتمال زیادی وجود دارد
که Pixelهای بعدی
همین Texelهای اطراف را نیز بخواهند.

چرا Pixelهای مجاور مهم هستند؟

Pixel Shader معمولاً روی Pixelهای کنار هم اجرا می‌شود.



A B C D

E F G H

این Pixelها
تقریباً همیشه
Texelهای مجاور را Sample می‌کنند.

اگر Texture به صورت خطی ذخیره شود…

فرض کنید Texture
به شکل سطر به سطر
در حافظه ذخیره شده باشد.



0  1  2  3

4  5  6  7

8  9 10 11

12 13 14 15

از نظر منطقی درست است،
اما از نظر Cache چندان مناسب نیست.

مشکل Layout خطی

Bilinear Filtering
معمولاً چهار Texel مجاور را می‌خواند.



5

6

9

10

در حافظه خطی،
این چهار Texel
همیشه کنار هم قرار ندارند.

Swizzled Texture Layout

برای افزایش احتمال Cache Hit،
GPU Texture را
به صورت بلوک‌های دوبعدی
در حافظه ذخیره می‌کند.



┌──────┬──────┐

│0 1   │2 3   │

│4 5   │6 7   │

├──────┼──────┤

│8 9   │10 11 │

│12 13 │14 15 │

└──────┴──────┘

مزیت Swizzle

حالا Bilinear Filtering
معمولاً تمام Texelهای موردنیاز را
از همان Cache Line
دریافت می‌کند.

بنابراین تعداد Cache Missها
به شدت کاهش پیدا می‌کند.

Morton Order (Z-Order)

بسیاری از GPUها
از الگویی به نام

Morton Order

برای ذخیره Texture استفاده می‌کنند.

در این روش،
Texelهای نزدیک در فضای دوبعدی،
تا حد امکان نزدیک هم
در حافظه نیز قرار می‌گیرند.



Memory Order

0

1

4

5

2

3

6

7

...

چرا Z-Order؟

هدف اصلی این روش،
حفظ همسایگی دوبعدی
هنگام تبدیل به حافظه خطی است.

بنابراین Pixelهای مجاور
معمولاً Cache Lineهای مشترک
خواهند داشت.

نتیجه نهایی

اثر Layout مناسب

ویژگی

نتیجه

Cache Hit

بیشتر

VRAM Access

کمتر

Bandwidth

کمتر مصرف می‌شود

Texture Sampling

سریع‌تر

UNDER THE HOOD

Textureها تقریباً هیچ‌وقت به صورت خطی در VRAM ذخیره نمی‌شوند

در بسیاری از GPUهای مدرن، قبل از اینکه Texture در حافظه قرار گیرد، Layout آن به شکلی تغییر داده می‌شود که دسترسی دوبعدی برای Cache بهینه شود. این فرآیند با نام‌هایی مانند Swizzling، Tiling یا Morton Layout شناخته می‌شود.



Image

      │

      ▼

Tile / Swizzle

      │

      ▼

VRAM

      │

      ▼

Texture Cache

      │

      ▼

Texture Unit

این سازمان‌دهی حافظه یکی از دلایل اصلی سرعت بالای Texture Sampling است. اگر Textureها مانند آرایه‌های دوبعدی معمولی ذخیره می‌شدند، نرخ Cache Miss به‌مراتب بیشتر بود و بخش قابل توجهی از توان GPU صرف انتظار برای دریافت داده از VRAM می‌شد.

چرا Cache دوبعدی طراحی شده است؟

برنامه‌های معمولی CPU
اغلب داده‌ها را به صورت خطی پردازش می‌کنند.



0

↓

1

↓

2

↓

3

↓

4

↓

5

اما Textureها ماهیتی دوبعدی دارند.

الگوی دسترسی Pixel Shader

Pixelهای مجاور،
تقریباً همیشه Texelهای مجاور را درخواست می‌کنند.



Pixels

A  B  C

D  E  F

↓

↓

↓

Texels

30 31 32

46 47 48

این رفتار،
پایه طراحی Texture Cache است.

Cache Coherency

اگر Pixelهای مجاور،
به داده‌های مجاور دسترسی داشته باشند،
می‌گوییم دسترسی دارای

Cache Coherency

است.

نمونه خوب



30 31 32

30 31 32

31 32 33

30 31 32

تقریباً تمام Sampleها
داخل همان چند Cache Line قرار دارند.

نمونه بد



5

930

48

712

140

3

در این حالت تقریباً هر Sample
باعث Cache Miss می‌شود.

چه چیزهایی Cache را خراب می‌کنند؟

دلایل کاهش Cache Hit

عامل

اثر

Noise شدید

پرش زیاد بین Texelها

Random UV

کاهش Locality

Procedural Sampling

Hit Rate پایین

Textureهای بسیار بزرگ

جابجایی مداوم Cache

چه چیزهایی Cache را تقویت می‌کنند؟

بهترین شرایط برای Texture Cache

ویژگی

نتیجه

UV پیوسته

Hit زیاد

Mesh منظم

Sampling منظم

Mipmap

Locality بهتر

Swizzled Layout

Cache بسیار مؤثر

UNDER THE HOOD

راز سرعت Texture Sampling فقط Texture Unit نیست

اگرچه Texture Unit مدارهای بسیار پیچیده‌ای برای Filtering دارد، اما بدون یک Cache کارآمد، بیشتر زمان خود را منتظر دریافت داده از VRAM می‌گذراند.

در عمل، سرعت بالای Texture Sampling حاصل همکاری سه بخش است:



Swizzled Memory

        │

        ▼

Texture Cache

        │

        ▼

Texture Unit

        │

        ▼

Filtering Hardware

هر کدام از این بخش‌ها برای دیگری طراحی شده‌اند؛ به همین دلیل حذف یا ضعف هر کدام، کارایی کل سیستم را به‌طور محسوسی کاهش می‌دهد.

بهترین روش‌های Texture Sampling

اکنون تقریباً تمام مسیر Texture Sampling را می‌شناسیم.

اما دانستن معماری کافی نیست.

یک Graphics Programmer حرفه‌ای باید بداند چگونه از این معماری
بیشترین کارایی را بگیرد.

هدف فقط اجرای صحیح برنامه نیست؛

هدف استفاده بهینه از سخت‌افزار GPU است.

اصل اول

Cache Friendly باشید

همیشه سعی کنید Pixelهای مجاور،
Texture Coordinateهای مجاور داشته باشند.



GOOD

0.10

0.11

0.12

0.13



BAD

0.10

0.82

0.04

0.71

هرچه Locality بیشتر باشد،
احتمال Cache Hit نیز بیشتر خواهد بود.

اصل دوم

از Mipmap استفاده کنید

خاموش کردن Mipmap تقریباً همیشه تصمیم اشتباهی است.

اثر Mipmap

فعال

نتیجه

✔

Aliasing کمتر

✔

Bandwidth کمتر

✔

Cache بهتر

اصل سوم

Anisotropic Filtering را هوشمندانه انتخاب کنید

فعال بودن 16× AF برای تمام Textureها
همیشه بهترین انتخاب نیست.

سطوحی که تقریباً عمود بر دوربین هستند،
از AF سود بسیار کمی می‌برند.

در مقابل،

زمین،

جاده،

باند فرودگاه،

کف اتاق،

بیشترین سود را از AF می‌برند.

اصل چهارم

Textureهای بسیار بزرگ همیشه بهتر نیستند

Texture با Resolution بسیار بالا

ممکن است:

  • VRAM بیشتری مصرف کند.
  • Bandwidth بیشتری بخواهد.
  • Cache Miss بیشتری ایجاد کند.

در بسیاری از پروژه‌ها،
دو Texture با Resolution متوسط
کیفیت بهتری نسبت به یک Texture بسیار بزرگ ایجاد می‌کنند.

اصل پنجم

LOD Bias را با احتیاط تغییر دهید

Bias منفی زیاد
ممکن است تصویر را شارپ‌تر کند،

اما معمولاً باعث Shimmering و Aliasing خواهد شد.

به همین دلیل موتورهای بازی
تنها مقدار بسیار کوچکی از Bias را اعمال می‌کنند.

اصل ششم

Sampling تصادفی را کاهش دهید

Shaderهایی که دائماً
به نقاط تصادفی Texture مراجعه می‌کنند،
تقریباً همیشه Cache را نابود می‌کنند.



Random

×

↓

Cache Miss



Sequential

×

×

×

×

↓

Cache Hit

اشتباهات رایج

Common Mistakes

اشتباه

نتیجه

بدون Mipmap

Aliasing شدید

Texture 8K بی‌دلیل

مصرف زیاد VRAM

Bias منفی زیاد

Shimmering

AF برای همه Textureها

کاهش Performance

Sampling تصادفی

Cache Miss

UNDER THE HOOD

بهینه‌سازی Texture فقط کاهش تعداد Sampleها نیست

بسیاری از برنامه‌نویسان تصور می‌کنند Performance فقط با کم کردن تعداد Texture Fetchها افزایش پیدا می‌کند.

در عمل، کیفیت دسترسی به حافظه اهمیت بیشتری دارد. دو Shader ممکن است هر دو ۸ Texture Fetch انجام دهند، اما اگر یکی از آن‌ها نرخ Cache Hit بالاتری داشته باشد، عملکرد آن به‌مراتب بهتر خواهد بود.



Shader A

8 Fetch

95% Cache Hit



Shader B

8 Fetch

35% Cache Hit

بنابراین یکی از مهم‌ترین مهارت‌های Graphics Programmer، طراحی Shaderهایی است که علاوه بر درستی، با ساختار Cache و Texture Unit نیز همسو باشند.

CHAPTER SUMMARY

Grand Summary — Texture Sampling Pipeline

در طول این فصل، مسیر کامل تبدیل یک تصویر دوبعدی به رنگ نهایی هر Pixel را بررسی کردیم. اکنون می‌توانیم تمام این مراحل را به‌صورت یک Pipeline واحد مشاهده کنیم.



Image File

      │

      ▼

Texture Resource

      │

      ▼

Texture Memory

      │

      ▼

Mip Generation

      │

      ▼

Swizzled Layout

      │

      ▼

Texture Cache

      │

      ▼

Texture Coordinate (UV)

      │

      ▼

Pixel Quad

      │

      ▼

ddx / ddy

      │

      ▼

Footprint

      │

      ▼

LOD Calculation

      │

      ▼

Sampler State

      │

      ▼

Address Mode

      │

      ▼

Mip Selection

      │

      ▼

Bilinear

      │

      ▼

Trilinear

      │

      ▼

Anisotropic

      │

      ▼

Filtered Color

      │

      ▼

Pixel Shader

      │

      ▼

Framebuffer

Key Takeaways

  1. Texture فقط یک تصویر نیست؛ یک منبع داده ساختاریافته در حافظه GPU است.

  2. Texture Sampling یک عملیات سخت‌افزاری پیچیده است، نه یک خواندن ساده از حافظه.

  3. LOD از مشتق‌های ddx و ddy محاسبه می‌شود، نه صرفاً از فاصله دوربین.

  4. Bilinear، Trilinear و Anisotropic هر کدام مشکل متفاوتی را حل می‌کنند.

  5. Sampler State قوانین Sampling را کنترل می‌کند، نه خود Texture را.

  6. Texture Cache مهم‌ترین عامل سرعت بالای Sampling است.

  7. Swizzled Layout باعث افزایش چشمگیر Cache Hit می‌شود.

  8. Performance فقط به تعداد Texture Fetchها وابسته نیست؛ کیفیت دسترسی به حافظه نیز نقش تعیین‌کننده دارد.

Common Misconceptions

❌ Texture و Sampler یک چیز نیستند.

❌ Trilinear جایگزین Anisotropic نیست.

❌ LOD فقط از فاصله دوربین محاسبه نمی‌شود.

❌ GPU یک Texel را مستقیماً از VRAM نمی‌خواند.

❌ Textureهای بزرگ‌تر همیشه کیفیت بهتری ایجاد نمی‌کنند.

❌ Cache فقط مخصوص CPU نیست؛ GPU نیز Cacheهای تخصصی متعددی دارد.

Frequently Asked Questions

آیا همیشه باید Mipmap فعال باشد؟

تقریباً همیشه بله. تنها در موارد خاص مانند Pixel Art یا برخی عناصر UI ممکن است غیرفعال شود.

چرا Textureهای دوردست تار دیده می‌شوند؟

زیرا GPU عمداً Mipmap کوچک‌تر را انتخاب می‌کند تا Aliasing کاهش یابد.

آیا Anisotropic همیشه باید روی 16× باشد؟

خیر. برای بسیاری از Textureها، مقادیر 4× یا 8× کیفیت بسیار خوبی با هزینه کمتر فراهم می‌کنند.

چرا Texture Cache تا این حد مهم است؟

زیرا مراجعه مستقیم به VRAM بسیار پرهزینه‌تر از استفاده از داده‌های موجود در Cache است.

Design Notes

یکی از تصمیم‌های کلیدی در طراحی GPUهای مدرن، جداسازی کامل Texture Unit از Shader Core است. این جداسازی باعث می‌شود عملیات پیچیده‌ای مانند انتخاب Mipmap، Filtering و Anisotropic Sampling توسط سخت‌افزار اختصاصی انجام شوند و هسته‌های محاسباتی روی اجرای Shaderها متمرکز بمانند.

همچنین استفاده از Swizzled Layout و Texture Cache نشان می‌دهد که معماری GPU از ابتدا بر اساس الگوهای دسترسی دوبعدی طراحی شده است؛ برخلاف CPU که عمدتاً برای دسترسی‌های خطی بهینه شده است.

Historical Notes

  • 1983

    Lance Williams مفهوم Mipmap را معرفی کرد.

  • اواخر دهه 1990

    Bilinear و Trilinear Filtering به قابلیت‌های استاندارد GPUهای مصرفی تبدیل شدند.

  • اوایل دهه 2000

    Anisotropic Filtering به‌صورت سخت‌افزاری در GPUها گسترش یافت.

  • نسل‌های جدید GPU

    Texture Cacheهای پیشرفته، Layoutهای Swizzled و فشرده‌سازی Texture نقش مهمی در افزایش کارایی پیدا کردند.

Further Reading

کتاب‌ها

  • Real-Time Rendering
  • GPU Gems
  • GPU Zen
  • Physically Based Rendering (بخش‌های مرتبط با Texture Sampling)

مستندات رسمی

  • Direct3D 12 Documentation
  • Vulkan Specification
  • OpenGL Specification

Knowledge Map



Vertex Processing

        │

        ▼

Rasterization

        │

        ▼

Interpolation

        │

        ▼

Texture Sampling

        │

        ▼

Lighting

        │

        ▼

Post Processing

What’s Next

اکنون که مسیر کامل Texture Sampling را می‌شناسیم، آماده ورود به یکی از مهم‌ترین بخش‌های معماری GPU هستیم:

GPU Memory Architecture

در فصل بعد خواهیم دید داده‌ها چگونه بین Register، Shared Memory، L1 Cache، L2 Cache، VRAM و واحدهای پردازشی جابه‌جا می‌شوند و چرا معماری حافظه، نقش تعیین‌کننده‌ای در کارایی GPU دارد.

CHAPTER 10

GPU Memory Architecture

Understanding How Data Moves Inside Modern GPUs

Architecture Overview

قبل از اینکه وارد جزئیات شویم،
ابتدا کل سیستم حافظه GPU را از نمای بالا مشاهده می‌کنیم.



                    GPU CHIP

┌─────────────────────────────────────────────┐

           Shader Cores

                │

        ┌───────┴────────┐

        │                │

   Register File    Shared Memory

        │                │

        └───────┬────────┘

                │

            L1 Cache

                │

                ▼

            L2 Cache

                │

                ▼

       Memory Controllers

                │

                ▼

        GDDR / HBM Memory

                │

                ▼

               VRAM

└─────────────────────────────────────────────┘

در این فصل،
هر کدام از این بخش‌ها را از نزدیک بررسی خواهیم کرد و خواهیم دید داده چگونه بین آن‌ها جابه‌جا می‌شود.

چرا GPU فقط یک نوع حافظه ندارد؟

در نگاه اول ممکن است تصور کنیم وجود یک حافظه بزرگ برای کل GPU کافی است.

اما چنین طراحی‌ای باعث می‌شود تقریباً تمام هسته‌های پردازشی بیشتر زمان خود را منتظر دریافت داده از حافظه بمانند.

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

هرچه حافظه کوچک‌تر باشد،
معمولاً سریع‌تر است.

به همین دلیل GPU از یک سلسله‌مراتب حافظه استفاده می‌کند؛
هر لایه ظرفیت، سرعت و کاربرد متفاوتی دارد.

سلسله‌مراتب حافظه

می‌توان حافظه‌های GPU را مانند یک هرم تصور کرد.



          Registers

              ▲

      Shared Memory

              ▲

          L1 Cache

              ▲

          L2 Cache

              ▲

         VRAM (GDDR/HBM)

هرچه به رأس هرم نزدیک‌تر می‌شویم:

  • ✔ سرعت بیشتر می‌شود.
  • ✔ ظرفیت کمتر می‌شود.
  • ✔ هزینه هر بایت افزایش پیدا می‌کند.

و هرچه به پایین هرم می‌رویم:

  • ✔ ظرفیت بیشتر می‌شود.
  • ✔ تأخیر دسترسی افزایش پیدا می‌کند.
  • ✔ پهنای باند قابل استفاده تغییر می‌کند.

هدف اصلی این معماری چیست؟

تمام این ساختار تنها یک هدف دارد:

داده، قبل از آنکه Shader به آن نیاز پیدا کند،
تا حد امکان به هسته پردازشی نزدیک باشد.

اگر داده در Register باشد،
دسترسی تقریباً آنی است.

اگر در Shared Memory باشد،
تنها چند سیکل زمان لازم است.

اگر در L2 Cache باشد،
هزینه بیشتر می‌شود.

و اگر مجبور شویم مستقیماً از VRAM بخوانیم،
تأخیر به‌مراتب بیشتر خواهد بود.

UNDER THE HOOD

GPU برای «محاسبه سریع» ساخته نشده؛ برای «پنهان کردن تأخیر حافظه» هم طراحی شده است.

یکی از بزرگ‌ترین تفاوت‌های GPU و CPU در همین نقطه است. بخش بزرگی از معماری GPU صرف نزدیک نگه داشتن داده به واحدهای محاسباتی و کاهش اثر تأخیر حافظه می‌شود. بسیاری از ویژگی‌هایی که در فصل‌های بعد خواهیم دید—مانند Warp Scheduling، Occupancy و Coalesced Memory Access—مستقیماً برای رسیدن به همین هدف طراحی شده‌اند.

Register چیست؟

سریع‌ترین حافظه‌ای که یک Shader Core به آن دسترسی دارد،
Register است.

هر دستور Shader،
قبل از هر چیز،
سعی می‌کند داده‌های خود را داخل Register نگهداری کند.

اگر داده داخل Register باشد،
تقریباً هیچ انتظار محسوسی برای دسترسی وجود ندارد.

یک تشبیه ساده

فرض کنید یک مهندس روی میز خود مشغول طراحی است.



Bookshelf

↓

Desk

↓

Notebook

↓

Pencil

در این مثال:

  • 📚 کتابخانه = VRAM
  • 🗂 میز کار = Cache
  • 📒 دفتر = Shared Memory
  • ✏️ مداد در دست = Register

Register نزدیک‌ترین محل نگهداری داده به واحد محاسباتی است.

Register کجا قرار دارد؟

برخلاف VRAM،
Register خارج از تراشه نیست.

بلکه داخل هر Shader Core
یا Compute Unit
قرار گرفته است.



GPU

│

├── Shader Core

│      │

│      ├── ALU

│      ├── Register File

│      └── Scheduler

│

└── ...

Register چه چیزی نگه می‌دارد؟

تقریباً تمام داده‌های موقتی Shader
ابتدا داخل Register ذخیره می‌شوند.

نمونه داده‌های داخل Register

نوع داده

نمونه

متغیرهای محلی

float color

نتیجه عملیات

dot()

مختصات

UV

مقادیر موقت

temp0

نتیجه Texture Fetch

RGBA

یک مثال واقعی



float3 color = textureColor.rgb;

float lighting = saturate(dot(N, L));

float3 result = color * lighting;

هنگام اجرای این کد،
تقریباً تمام این متغیرها
داخل Register قرار می‌گیرند.



R0

textureColor



R1

lighting



R2

result

چرا Register این‌قدر سریع است؟

زیرا Register نیازی به جستجو،
Cache Lookup
یا مراجعه به VRAM ندارد.

واحد محاسباتی تقریباً مستقیماً به آن متصل است.



ALU

│

▼

Register

آیا Register نامحدود است؟

خیر.

سریع بودن Register
بهای سنگینی دارد.

  • ✔ بسیار سریع
  • ✔ نزدیک ALU
  • ✖ ظرفیت بسیار محدود
  • ✖ گران‌ترین نوع حافظه روی تراشه

Register Pressure

اگر Shader
Registerهای زیادی مصرف کند،
GPU با مشکل جدیدی روبه‌رو می‌شود.

Register کافی برای اجرای Warpهای بیشتر باقی نمی‌ماند.

به این وضعیت
Register Pressure
گفته می‌شود.

UNDER THE HOOD

Registerها حافظه اشتراکی نیستند

یکی از مهم‌ترین ویژگی‌های Register این است که هر Thread مجموعه Registerهای مخصوص به خود را دارد. Threadهای دیگر نه می‌توانند آن‌ها را ببینند و نه به آن‌ها دسترسی داشته باشند. این ویژگی باعث می‌شود Register سریع‌ترین و خصوصی‌ترین حافظه در GPU باشد.



Thread 0

R0 R1 R2



Thread 1

R0 R1 R2



Thread 2

R0 R1 R2

به همین دلیل، Register بهترین محل برای نگهداری داده‌های موقتی هر Thread است؛ اما اگر تعداد Registerهای موردنیاز یک Shader بیش از حد افزایش یابد، روی تعداد Warpهای قابل اجرای هم‌زمان اثر مستقیم خواهد گذاشت. در فصل **Occupancy** این ارتباط را به‌صورت عمیق بررسی خواهیم کرد.

Register Allocation چیست؟

وقتی Shader را می‌نویسید،
هیچ Registerی را مستقیماً انتخاب نمی‌کنید.

در واقع شما فقط متغیر تعریف می‌کنید.



float3 normal;

float3 light;

float intensity;

float4 color;

اما GPU این نام‌ها را نمی‌شناسد.

کامپایلر Shader
تمام این متغیرها را
به Registerهای واقعی تبدیل می‌کند.

چه کسی Registerها را انتخاب می‌کند؟

این کار توسط Shader Compiler انجام می‌شود.



HLSL / GLSL

        │

        ▼

Shader Compiler

        │

        ▼

Register Allocation

        │

        ▼

GPU Instructions

بنابراین Register Allocation
قبل از اجرای Shader اتفاق می‌افتد.

مثال ساده



float a;

float b;

float c;

float d;

کامپایلر ممکن است آن را به شکل زیر تبدیل کند.



R0

↓

a



R1

↓

b



R2

↓

c



R3

↓

d

اما همیشه این‌گونه نیست

اگر دو متغیر
هم‌زمان مورد استفاده نباشند،
کامپایلر می‌تواند
هر دو را داخل یک Register قرار دهد.



time

──────────────▶

Variable A

██████



Variable B

      ██████



↓

Both

↓

Register R0

به این کار

Register Reuse

گفته می‌شود.

Lifetime متغیرها

هر متغیر،
فقط در بخشی از اجرای Shader زنده است.



Instruction

1

2

3

4

5

6

7

8



Color

██████



Normal

  ███████



Result

       █████

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

هدف Register Allocation

اهداف اصلی کامپایلر

هدف

دلیل

کمترین Register

Occupancy بیشتر

Reuse

کاهش مصرف Register

عدم تداخل

درستی اجرا

بدون Spill

حداکثر Performance

چرا این موضوع اهمیت دارد؟

فرض کنید یک Shader

تنها

۲۴ Register

نیاز دارد.

اکنون نسخه جدید Shader
به دلیل چند محاسبه اضافی

به

۶۴ Register

نیاز پیدا می‌کند.

اگرچه تعداد دستورها شاید فقط کمی بیشتر شده باشد،
اما مصرف Register تقریباً سه برابر شده است.

گاهی کند شدن Shader
نه به خاطر دستورهای بیشتر،
بلکه به خاطر Registerهای بیشتر است.

UNDER THE HOOD

کامپایلر تلاش می‌کند Registerها را مانند جای پارک مدیریت کند

می‌توان Registerها را مانند تعداد محدودی جای پارک تصور کرد. هر متغیر فقط در بازه‌ای از زمان به یک جای پارک نیاز دارد. به محض پایان عمر آن متغیر، همان جای پارک می‌تواند در اختیار متغیر دیگری قرار گیرد.



Variable A

──────┐

      ▼

     R0

      ▲

──────┘

Variable B

هرچه Compiler بتواند Registerها را بیشتر بازاستفاده (Reuse) کند، Shader با Registerهای کمتری اجرا می‌شود و امکان اجرای Warpهای بیشتری روی همان Shader Core فراهم می‌شود.

وقتی Registerها تمام می‌شوند…

تا اینجا فرض کردیم
کامپایلر همیشه Register کافی در اختیار دارد.

اما واقعیت این است که
تعداد Registerهای هر Shader Core محدود است.

اگر Shader به Register بیشتری نیاز داشته باشد،
GPU دیگر نمی‌تواند همه داده‌ها را داخل Register نگه دارد.

در این لحظه فرآیندی به نام

Register Spilling

رخ می‌دهد.

Spill یعنی چه؟

واژه Spill
به معنی «سرریز شدن» است.

وقتی Registerها پر شوند،
کامپایلر بعضی از متغیرها را
از Register خارج می‌کند.



Registers

██████████

FULL



↓

Overflow



Local Memory

داده‌ها کجا می‌روند؟

یک تصور اشتباه این است که
این داده‌ها وارد Shared Memory می‌شوند.

خیر.

در اکثر GPUها،
متغیرهای Spill شده
داخل حافظه‌ای قرار می‌گیرند که در مدل برنامه‌نویسی
Local Memory
نامیده می‌شود.

با وجود نام آن،
این حافظه معمولاً در
VRAM قرار دارد و از طریق سلسله‌مراتب Cache قابل دسترسی است.



Register

      │

      ▼

Local Memory

      │

      ▼

L1 / L2 Cache

      │

      ▼

VRAM

چرا Spill خطرناک است؟

دسترسی به Register
تقریباً آنی است.

اما دسترسی به Local Memory
ممکن است ده‌ها یا حتی صدها سیکل بیشتر طول بکشد،
به‌ویژه اگر داده در Cache نباشد و نیاز به مراجعه به VRAM باشد.

مقایسه تقریبی هزینه دسترسی

محل داده

تأخیر نسبی

Register

بسیار کم

Shared Memory

کم

L1 Cache

متوسط

L2 Cache

زیادتر

VRAM

بسیار زیاد

مقادیر دقیق به معماری GPU بستگی دارند؛ این جدول تنها ترتیب نسبی سرعت را نشان می‌دهد.

یک مثال ساده



float a0;
float a1;
float a2;
...
float a63;

اگر تعداد متغیرهای زنده به‌طور هم‌زمان
از Registerهای قابل تخصیص بیشتر شود،
کامپایلر ناچار است برخی از آن‌ها را Spill کند.

Spill همیشه به معنی کد بد نیست

گاهی Spill نتیجه یک Shader بسیار پیچیده است.

گاهی نیز به دلیل انتخاب‌های نامناسب در کدنویسی رخ می‌دهد.

  • ✔ نگه داشتن متغیرهای غیرضروری برای مدت طولانی
  • ✔ محاسبات بسیار بزرگ در یک تابع
  • ✔ استفاده هم‌زمان از تعداد زیادی مقدار موقت
  • ✔ باز شدن بیش از حد حلقه‌ها (Loop Unrolling)

چگونه از Spill جلوگیری کنیم؟

راهکارهای کاهش Register Spilling

روش

تأثیر

کاهش Lifetime متغیرها

Reuse بهتر Registerها

تقسیم Shaderهای بسیار بزرگ

کاهش Register Pressure

حذف متغیرهای موقت غیرضروری

مصرف کمتر Register

بازبینی خروجی Compiler

شناسایی Spillهای ناخواسته

UNDER THE HOOD

Local Memory همیشه «محلی» نیست

نام Local Memory ممکن است گمراه‌کننده باشد. منظور از «محلی» این است که این حافظه از دید برنامه‌نویسی به هر Thread تعلق دارد، نه اینکه از نظر فیزیکی نزدیک هسته پردازشی باشد. در بسیاری از معماری‌های GPU، این داده‌ها در نهایت در VRAM ذخیره می‌شوند و تنها در صورت وجود، از Cacheها بهره می‌برند.



Thread Variable

        │

        ▼

Local Memory

 (Programming Model)

        │

        ▼

Cache Hierarchy

        │

        ▼

VRAM

به همین دلیل، هر بار که یک مقدار Spill شده دوباره موردنیاز باشد، هزینه دسترسی آن می‌تواند چندین برابر بیشتر از یک Register باشد. به همین علت، کامپایلرها تا حد امکان از Register Reuse استفاده می‌کنند تا از وقوع Spill جلوگیری شود.

Register Pressure چیست؟

تا اینجا یاد گرفتیم که هر Thread
برای نگهداری داده‌های موقت خود
از Register استفاده می‌کند.

اما تعداد Registerهای هر Shader Core
محدود است.

هرچه یک Thread
Register بیشتری مصرف کند،
Register کمتری برای Threadهای دیگر باقی می‌ماند.

مصرف زیاد Register،
به معنی کاهش تعداد Threadهای هم‌زمان است.

یک مثال شهودی

فرض کنید یک Shader Core
فقط ۶۴ Register داشته باشد.



Register File

□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□

Total = 64

حالت اول

هر Thread فقط ۸ Register نیاز دارد.



64 Registers

÷

8 Registers / Thread

=

8 Threads

در این حالت،
هشت Thread می‌توانند هم‌زمان اجرا شوند.

حالت دوم

اکنون همان Shader
به دلیل چند متغیر اضافه،
به ۱۶ Register نیاز دارد.



64 Registers

÷

16 Registers / Thread

=

4 Threads

بدون اینکه تعداد هسته‌ها تغییر کند،
تعداد Threadهای هم‌زمان
نصف شده است.

همین موضوع را در مقیاس Warp ببینیم

در GPU واقعی،
Scheduler معمولاً Warpها را زمان‌بندی می‌کند،
نه Threadهای تکی.



Warp 0

████████



Warp 1

████████



Warp 2

████████



Warp 3

████████

اگر Register کافی وجود نداشته باشد،
Scheduler اصلاً نمی‌تواند Warpهای بیشتری را
فعال کند.

چرا این موضوع Performance را کاهش می‌دهد؟

GPU برای پنهان کردن تأخیر حافظه،
بین Warpهای مختلف جابه‌جا می‌شود.



Warp A

Memory Wait



↓

Scheduler



↓

Warp B

Compute



↓

Warp C

Compute

اگر Warpهای آماده کم باشند،
Scheduler گزینه‌ای برای جایگزینی ندارد.

تعریف Register Pressure

نشانه‌های Register Pressure

علائم رایج

علامت

دلیل

Occupancy پایین

کمبود Register

Register Spill

Register کافی وجود ندارد

Latency بالا

Warp کافی برای جایگزینی نیست

Performance پایین

Scheduler بیکار می‌ماند

آیا Register کمتر همیشه بهتر است؟

خیر.

اگر فقط برای کاهش مصرف Register،
محاسبات اضافی انجام دهیم،
ممکن است زمان اجرای Shader افزایش پیدا کند.

هدف، کمترین تعداد Register نیست؛

هدف، بهترین تعادل بین مصرف Register و حجم محاسبات است.

رابطه Register با Occupancy

یکی از سه عامل اصلی تعیین‌کننده Occupancy عبارت‌اند از:

  • ✔ تعداد Register هر Thread
  • ✔ Shared Memory هر Block
  • ✔ محدودیت سخت‌افزاری تعداد Warpها

در فصل Occupancy
این رابطه را به‌صورت عددی بررسی خواهیم کرد.

UNDER THE HOOD

گاهی Shader سریع‌تر، Register بیشتری مصرف می‌کند

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

به همین دلیل، افزایش Register همیشه یک تصمیم بد نیست. مسئله اصلی پیدا کردن نقطه تعادل است؛ جایی که مصرف Register آن‌قدر زیاد نباشد که Occupancy را محدود کند و در عین حال آن‌قدر کم هم نباشد که داده‌ها مدام بین Register و حافظه جابه‌جا شوند.



More Registers

        │

        ├── Less Memory Access

        └── Lower Occupancy



Less Registers

        │

        ├── More Occupancy

        └── More Memory Traffic

بهینه‌سازی واقعی Shader، پیدا کردن تعادل بین این دو حالت است؛ نه حرکت افراطی به سمت یکی از آن‌ها.

چرا GPU هزاران Thread را هم‌زمان اجرا می‌کند؟

تا اینجا دیدیم که دسترسی به Register بسیار سریع است،
اما مراجعه به حافظه‌های دورتر مانند L2 Cache یا VRAM
می‌تواند ده‌ها تا صدها سیکل زمانی طول بکشد.

سؤال مهم این است:

اگر یک Thread منتظر دریافت داده از حافظه باشد،
آیا کل GPU متوقف می‌شود؟

خوشبختانه پاسخ منفی است.

ایده اصلی GPU

به جای منتظر ماندن،
GPU به سراغ Warp دیگری می‌رود
که آماده اجراست.



Warp A

Memory Wait

      │

      ▼

Scheduler

      │

      ▼

Warp B

Running

      │

      ▼

Warp C

Running

به این ترتیب،
تأخیر حافظه پشت اجرای Warpهای دیگر پنهان می‌شود.

این همان Latency Hiding است

Occupancy چیست؟

برای اینکه Scheduler همیشه Warp آماده داشته باشد،
باید تعداد کافی Warp
روی Shader Core مستقر باشند.



Shader Core

────────────────────

Warp 0 ✔

Warp 1 ✔

Warp 2 ✔

Warp 3 ✔

Warp 4 Waiting

Warp 5 Ready

Warp 6 Ready

Warp 7 Ready

به نسبت Warpهای فعال،
Occupancy
گفته می‌شود.

Register چه نقشی دارد؟

هر Warp
برای هر Thread
Register مخصوص خود را نیاز دارد.



Register File

────────────────────

Warp 0

████████



Warp 1

████████



Warp 2

████████

اگر Registerها پر شوند،
Warp جدید دیگر جایی برای اجرا نخواهد داشت.

زنجیره علت و معلول



More Registers

        │

        ▼

Fewer Active Warps

        │

        ▼

Lower Occupancy

        │

        ▼

Less Latency Hiding

        │

        ▼

Possible Performance Loss

اما Occupancy همیشه همه چیز نیست

گاهی افزایش Occupancy
باعث افزایش Performance می‌شود.

اما همیشه این‌طور نیست.

اگر برای افزایش Occupancy،
Registerهای لازم را حذف کنیم
و در نتیجه Register Spilling رخ دهد،
ممکن است عملکرد حتی بدتر شود.

Occupancy بیشتر،
همیشه Performance بیشتر نیست.

این فصل فقط یک پیش‌نمایش است

در فصل اختصاصی

Warp Scheduling & Occupancy

تمام این مفاهیم را با مثال‌های عددی،
نمودارهای زمانی،
محدودیت‌های سخت‌افزاری
و ابزارهای تحلیل واقعی مانند Nsight و Radeon GPU Profiler بررسی خواهیم کرد.

UNDER THE HOOD

چرا Register، Shared Memory و Occupancy همیشه با هم بررسی می‌شوند؟

در معماری GPU این سه مفهوم از یکدیگر جدا نیستند. Register مصرف‌شده توسط هر Thread، Shared Memory مصرف‌شده توسط هر Block و حداکثر تعداد Warpهای قابل استقرار روی یک Shader Core همگی از منابع محدود یک واحد پردازشی استفاده می‌کنند. افزایش مصرف هر یک از این منابع می‌تواند تعداد Warpهای هم‌زمان را کاهش دهد.



Register Usage

        │

        ├──────────┐

        ▼          │

Active Warps       │

        ▲          │

        └──────────┤

                   ▼

Shared Memory Usage

به همین دلیل، مهندسان GPU هنگام بهینه‌سازی Shaderها معمولاً Register Usage، Shared Memory Usage و Occupancy را هم‌زمان تحلیل می‌کنند، نه به‌صورت جداگانه.

Shared Memory چیست؟

تا اینجا دیدیم که هر Thread
Registerهای مخصوص به خود را دارد.

اما اگر چند Thread
بخواهند روی یک مجموعه داده مشترک کار کنند چه؟

استفاده از Register دیگر ممکن نیست،
زیرا Registerها خصوصی هستند.

برای حل این مشکل،
GPU حافظه‌ای بسیار سریع به نام

Shared Memory

در اختیار Threadها قرار می‌دهد.

اول یک مثال واقعی

فرض کنید ۳۲ کارگر
در حال ساخت یک دیوار هستند.

اگر هر کارگر
آجرهای خودش را از انبار اصلی بردارد،
زمان زیادی صرف رفت‌وآمد می‌شود.

اما اگر یک پالت آجر
کنار همه آن‌ها قرار بگیرد،
همه می‌توانند
از همان پالت استفاده کنند.



Warehouse

      │

      ▼

Shared Pallet

 ┌──────────────┐

 Worker Worker Worker

 Worker Worker Worker

Shared Memory
دقیقاً همان پالت آجر است.

Shared بین چه کسانی؟

یکی از رایج‌ترین سوءبرداشت‌ها این است
که Shared Memory
بین تمام Threadهای GPU مشترک است.

این تصور اشتباه است.



GPU

│

├── Block 0

│      └── Shared Memory

│

├── Block 1

│      └── Shared Memory

│

├── Block 2

│      └── Shared Memory

هر Block
Shared Memory مخصوص به خود را دارد.

Threadهای Blockهای دیگر
به آن دسترسی ندارند.

جایگاه Shared Memory

از نظر سرعت،
Shared Memory
بعد از Register قرار می‌گیرد.



Registers

      ▲

Shared Memory

      ▲

L1 Cache

      ▲

L2 Cache

      ▲

VRAM

به همین دلیل،
هر زمان چند Thread
به داده مشترک نیاز داشته باشند،
Shared Memory انتخاب بسیار مناسبی است.

چه داده‌هایی داخل Shared Memory قرار می‌گیرند؟

نمونه استفاده‌ها

داده

دلیل

Tileهای ماتریس

استفاده مجدد زیاد

همسایه‌های تصویر

پردازش فیلترها

Histogram

اشتراک بین Threadها

Reduction

جمع نتایج

ENGINEERING INSIGHT

چرا Shared Memory را «برنامه‌نویس» مدیریت می‌کند؟

برخلاف Cache که به‌صورت خودکار توسط سخت‌افزار مدیریت می‌شود، Shared Memory معمولاً تحت کنترل برنامه‌نویس یا کامپایلر است. این یعنی شما تصمیم می‌گیرید چه داده‌ای وارد آن شود، چه زمانی استفاده شود و چه زمانی کنار گذاشته شود.

این آزادی عمل، قدرت بسیار زیادی می‌دهد؛ اما مسئولیت بیشتری هم ایجاد می‌کند. اگر داده نامناسبی را وارد Shared Memory کنید یا از آن به‌درستی استفاده نکنید، نه‌تنها سودی نخواهید برد، بلکه ممکن است Occupancy نیز کاهش پیدا کند.

UNDER THE HOOD

Shared Memory یک «دفتر مشترک» نیست؛ بخشی از طراحی معماری GPU است

Shared Memory فقط برای راحتی برنامه‌نویس اضافه نشده است. بسیاری از الگوریتم‌های پردازش موازی، مانند ضرب ماتریس، کانولوشن تصاویر، FFT و Reduction، بدون وجود یک حافظه سریع و مشترک مجبور بودند بارها همان داده را از VRAM بخوانند. Shared Memory این الگو را تغییر می‌دهد: داده یک‌بار از حافظه اصلی خوانده می‌شود، داخل Shared Memory قرار می‌گیرد و سپس ده‌ها یا صدها Thread همان داده را دوباره استفاده می‌کنند.



VRAM

   │

   ▼

Shared Memory

   │

   ├────► Thread 0

   ├────► Thread 1

   ├────► Thread 2

   └────► Thread 3

این قابلیت یکی از مهم‌ترین دلایل کارایی بالای GPU در محاسبات موازی است و در ادامه خواهیم دید که در کنار مزایای آن، محدودیت‌هایی مانند Bank Conflict نیز وجود دارد که در صورت نادیده گرفتن، می‌تواند بخش زیادی از این مزیت را از بین ببرد.

چرا Shared Memory به Bank تقسیم شده است؟

اگر تمام Threadهای یک Warp
هم‌زمان بخواهند
از Shared Memory داده بخوانند،
یک سؤال مهم مطرح می‌شود.

اگر همه Threadها
دقیقاً در یک لحظه
به Shared Memory مراجعه کنند،
آیا فقط یک نفر می‌تواند بخواند؟

اگر پاسخ مثبت بود،
تمام مزیت Shared Memory
از بین می‌رفت.

برای حل این مشکل،
Shared Memory
به چندین بخش مستقل تقسیم شده است.

Bank چیست؟

یک تصویر ذهنی

به جای اینکه Shared Memory
را یک خیابان تک‌بانده تصور کنیم،

آن را مانند بزرگراهی با چندین خط عبور در نظر بگیرید.



Lane 0

Lane 1

Lane 2

Lane 3

Lane 4

Lane 5

Lane 6

Lane 7

هر Bank
مانند یک خط عبور مستقل عمل می‌کند.

مزیت Bankها

اگر Threadهای مختلف
به Bankهای مختلف مراجعه کنند،
تمام درخواست‌ها
هم‌زمان انجام می‌شوند.



Thread 0

↓

Bank 0



Thread 1

↓

Bank 1



Thread 2

↓

Bank 2



Thread 3

↓

Bank 3

در این حالت
تقریباً هیچ تأخیری ایجاد نمی‌شود.

نگاشت داده‌ها روی Bankها

هر آدرس Shared Memory
به یکی از Bankها نگاشت می‌شود.

به صورت مفهومی می‌توان آن را چنین تصور کرد:



Address

0 → Bank 0

1 → Bank 1

2 → Bank 2

3 → Bank 3

4 → Bank 4

...

الگوی دقیق نگاشت
به معماری GPU بستگی دارد،
اما اصل ایده در همه آن‌ها مشابه است.

وقتی همه چیز عالی پیش می‌رود



Warp

↓

Thread 0 → Bank 0

Thread 1 → Bank 1

Thread 2 → Bank 2

Thread 3 → Bank 3

...

در این حالت
تمام درخواست‌ها
به صورت موازی اجرا می‌شوند.

ENGINEERING INSIGHT

چرا تعداد Bankها محدود است؟

ممکن است این سؤال پیش بیاید که چرا Shared Memory را به صدها Bank تقسیم نمی‌کنند تا هیچ‌گاه تداخلی رخ ندهد.

پاسخ، هزینه سخت‌افزار است.

هر Bank به مدارهای مستقل، خطوط داده، منطق کنترل و مسیرهای سیلیکونی بیشتری نیاز دارد. افزایش تعداد Bankها باعث بزرگ‌تر شدن تراشه، افزایش مصرف انرژی و پیچیده‌تر شدن طراحی می‌شود.

در نتیجه، معماران GPU تعداد Bankها را طوری انتخاب می‌کنند که بین **کارایی، مساحت تراشه و مصرف انرژی** تعادل برقرار شود.

UNDER THE HOOD

Bankها دقیقاً مانند Cache نیستند

گاهی Shared Memory Bank با Cache اشتباه گرفته می‌شود. Cache به‌طور خودکار داده‌های پرکاربرد را نگهداری می‌کند، اما Bankها صرفاً مسیرهای موازی دسترسی به Shared Memory هستند. وجود Bankهای متعدد به این معنی نیست که داده‌ها کپی شده‌اند؛ بلکه فقط امکان پاسخ‌گویی هم‌زمان به چند درخواست مستقل فراهم شده است.



Shared Memory

        │

 ┌──────┼──────┐

 ▼      ▼      ▼

Bank0 Bank1 Bank2 ...

یک سؤال ساده

فرض کنید چهار Thread
هم‌زمان می‌خواهند
از Shared Memory داده بخوانند.

حالت اول را ببینید.



Warp

Thread0 ─────► Bank0

Thread1 ─────► Bank1

Thread2 ─────► Bank2

Thread3 ─────► Bank3

به نظر می‌رسد
همه چیز ایده‌آل است.

اما اگر این اتفاق بیفتد چه؟



Warp

Thread0 ─────► Bank0

Thread1 ─────► Bank0

Thread2 ─────► Bank0

Thread3 ─────► Bank0

اکنون چهار Thread
به طور هم‌زمان
یک Bank را درخواست کرده‌اند.

اگر شما جای سخت‌افزار بودید،
چه می‌کردید؟

پاسخ

بانک نمی‌تواند
همه درخواست‌ها را
در یک لحظه پاسخ دهد.

در نتیجه درخواست‌ها
پشت سر هم اجرا می‌شوند.



Cycle 1

Thread0



Cycle 2

Thread1



Cycle 3

Thread2



Cycle 4

Thread3

به این وضعیت

Bank Conflict

گفته می‌شود.

تعریف Bank Conflict

بدون Conflict



Cycle 1

Thread0

Thread1

Thread2

Thread3

✔

تمام درخواست‌ها
در یک سیکل انجام می‌شوند.

با Conflict



Cycle1

Thread0



Cycle2

Thread1



Cycle3

Thread2



Cycle4

Thread3

همان چهار درخواست

اکنون چهار سیکل زمان نیاز دارند.

درجه‌های مختلف Conflict

Bank Conflict
فقط یک حالت ندارد.

درجه‌های مختلف Bank Conflict

تعداد درخواست

نوع Conflict

اثر تقریبی

1

ندارد

حداکثر سرعت

2

2-Way

تقریباً دو برابر تأخیر

4

4-Way

حدود چهار برابر تأخیر

8

8-Way

بسیار کندتر

میزان دقیق افت کارایی به معماری GPU و الگوی دسترسی بستگی دارد؛ جدول بالا تنها برای نمایش روند کلی است.

اما یک استثنا وجود دارد

اگر تمام Threadهای Warp
دقیقاً یک آدرس مشترک را بخوانند،
بسیاری از GPUهای مدرن
می‌توانند همان مقدار را
به همه Threadها ارسال کنند.



Thread0

│

Thread1

│

Thread2

│

Thread3

▼

Address 120

▼

Broadcast

به این مکانیزم

Broadcast

گفته می‌شود.

ENGINEERING INSIGHT

چرا Broadcast استثنا است؟

در نگاه اول ممکن است تصور شود اگر چند Thread به یک Bank مراجعه کنند، همیشه Conflict رخ می‌دهد. اما اگر همه آن‌ها دقیقاً یک آدرس را درخواست کنند، سخت‌افزار لازم نیست چند بار همان مقدار را بخواند. یک بار خواندن کافی است و همان داده بین همه Threadها توزیع می‌شود.

به همین دلیل، دسترسی‌های «کاملاً یکسان» معمولاً بسیار سریع‌تر از دسترسی‌های «متفاوت ولی روی یک Bank» هستند.

UNDER THE HOOD

Bank Conflict همیشه فاجعه نیست

یکی از برداشت‌های اشتباه این است که هر Bank Conflict باعث افت شدید عملکرد می‌شود. در عمل، شدت تأثیر به عواملی مانند تعداد Threadهای درگیر، الگوی دسترسی، معماری GPU و توانایی سخت‌افزار در Broadcast یا بهینه‌سازی درخواست‌ها بستگی دارد.

مهندس GPU هدفش حذف کامل Bank Conflict نیست؛ بلکه کاهش Conflictهای پرهزینه و طراحی الگوهای دسترسی است که بیشترین بهره را از Shared Memory ببرند.

بهترین روش‌های استفاده از Shared Memory

Shared Memory یکی از سریع‌ترین حافظه‌های GPU است،
اما فقط در صورتی که به‌درستی از آن استفاده شود.

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

اصل اول

فقط داده‌هایی را وارد Shared Memory کنید که دوباره استفاده می‌شوند

اگر داده فقط یک بار خوانده می‌شود،
کپی کردن آن به Shared Memory
هیچ سودی ندارد.



VRAM

↓

Shared Memory

↓

One Read

✖

اما اگر همان داده
توسط ده‌ها Thread
چندین بار استفاده شود،
Shared Memory بسیار ارزشمند خواهد بود.

اصل دوم

دسترسی منظم داشته باشید

سعی کنید Threadهای مجاور،
به آدرس‌های مجاور مراجعه کنند.



GOOD

T0 → 0

T1 → 1

T2 → 2

T3 → 3



BAD

T0 → 0

T1 → 97

T2 → 12

T3 → 211

الگوهای منظم،
هم Cache و هم Bankها را بهتر استفاده می‌کنند.

اصل سوم

Bank Conflict را کاهش دهید

حتی اگر Shared Memory بسیار سریع باشد،
Conflict می‌تواند آن را به یک گلوگاه تبدیل کند.

  • ✔ داده‌ها را با Layout مناسب ذخیره کنید.
  • ✔ از الگوهای دسترسی متوالی استفاده کنید.
  • ✔ در صورت نیاز از Padding استفاده کنید.

Padding چیست؟

گاهی فقط اضافه کردن
یک عنصر اضافی
بین سطرها یا ستون‌ها
باعث می‌شود چند Thread
روی یک Bank قرار نگیرند.



Without Padding

□□□□□□□□

□□□□□□□□



With Padding

□□□□□□□□□

□□□□□□□□□

این تکنیک ساده،
در بسیاری از الگوریتم‌های پردازش تصویر و ضرب ماتریس
برای کاهش Bank Conflict استفاده می‌شود.

اصل چهارم

حجم Shared Memory را کنترل کنید

هر Block
مقدار محدودی Shared Memory دارد.

اگر یک Block
بخش زیادی از آن را مصرف کند،
ممکن است Blockهای کمتری
به‌طور هم‌زمان روی همان Shader Core اجرا شوند.

مصرف زیاد Shared Memory،
می‌تواند Occupancy را کاهش دهد.

چه زمانی از Shared Memory استفاده نکنیم؟

مواردی که Shared Memory انتخاب مناسبی نیست

شرایط

دلیل

داده فقط یک بار استفاده می‌شود

هزینه کپی بیهوده است

حجم داده بسیار زیاد است

کاهش Occupancy

الگوی دسترسی کاملاً تصادفی است

کاهش بهره‌وری Shared Memory

Cache عملکرد مناسبی دارد

ممکن است Shared Memory سودی نداشته باشد

PERFORMANCE DETECTIVE

اگر Shared Memory سرعت را افزایش نداد، چه چیزی را بررسی کنیم؟

  • آیا داده‌ها واقعاً چند بار استفاده می‌شوند؟
  • آیا Bank Conflict رخ می‌دهد؟
  • آیا حجم Shared Memory باعث کاهش Occupancy شده است؟
  • آیا Cache به‌تنهایی کافی بوده و Shared Memory فقط یک مرحله اضافی ایجاد کرده است؟

در بسیاری از پروژه‌ها، پاسخ این پرسش‌ها علت اصلی اختلاف عملکرد بین دو پیاده‌سازی ظاهراً مشابه را آشکار می‌کند.

UNDER THE HOOD

Shared Memory یک ابزار است، نه یک راه‌حل جادویی

گاهی تصور می‌شود که انتقال هر داده‌ای به Shared Memory باعث افزایش سرعت خواهد شد. در عمل چنین نیست. انتقال داده از VRAM به Shared Memory خود نیز هزینه دارد. این هزینه تنها زمانی جبران می‌شود که همان داده چندین بار توسط Threadهای مختلف مورد استفاده قرار گیرد.



VRAM

   │

Load Once

   │

   ▼

Shared Memory

   │

Reuse Many Times

   │

   ▼

Threads

به همین دلیل، یکی از مهم‌ترین مهارت‌های برنامه‌نویسی GPU این نیست که «همیشه از Shared Memory استفاده کند»، بلکه این است که تشخیص دهد **کِی استفاده از آن واقعاً ارزش دارد**.

چرا به Synchronization نیاز داریم؟

تا اینجا فرض کردیم
همه Threadها مستقل از یکدیگر کار می‌کنند.

اما در بسیاری از الگوریتم‌های موازی،
Threadها روی داده‌های مشترک کار می‌کنند.

در این حالت،
سرعت اجرای Threadها
ممکن است یکسان نباشد.

اگر یک Thread زودتر به داده‌ای برسد که هنوز توسط Thread دیگر تولید نشده باشد،
نتیجه اجرای برنامه نادرست خواهد بود.

یک مثال واقعی

فرض کنید چهار Thread
در حال محاسبه یک ماتریس هستند.



Thread 0

Load Tile



Thread 1

Load Tile



Thread 2

Load Tile



Thread 3

Load Tile

همه Threadها
ابتدا داده‌ها را
داخل Shared Memory قرار می‌دهند.

اما آیا می‌توانند
بلافاصله شروع به خواندن کنند؟

مشکل Race Condition

فرض کنید Thread 0
بسیار سریع‌تر اجرا شود.



Thread0

Read Shared Memory

✔



Thread3

Still Writing...

Thread 0
ممکن است داده‌ای را بخواند
که هنوز کامل نوشته نشده است.

به این وضعیت

Race Condition

گفته می‌شود.

Synchronization

برای جلوگیری از Race Condition،
همه Threadها
باید در یک نقطه
منتظر یکدیگر بمانند.



Thread0

──────┐



Thread1

──────┤



Thread2

──────┤

        ▼

    Barrier

        ▼

Continue



Thread3

──────┘

به این نقطه،
Barrier
گفته می‌شود.

Barrier چه کاری انجام می‌دهد؟

Memory Barrier چیست؟

گاهی کافی نیست که فقط منتظر Threadهای دیگر بمانیم.

باید مطمئن شویم
تمام عملیات خواندن و نوشتن حافظه
نیز کامل شده‌اند.

به این منظور از

Memory Barrier

استفاده می‌شود.



Write

↓

Memory Barrier

↓

Read

Barrier و Memory Barrier یکی نیستند

مقایسه دو مفهوم

Barrier

Memory Barrier

هماهنگی اجرای Threadها

هماهنگی عملیات حافظه

کنترل زمان اجرا

کنترل ترتیب دسترسی به حافظه

منتظر سایر Threadها می‌ماند

منتظر تکمیل عملیات حافظه می‌ماند

هزینه Synchronization

Synchronization رایگان نیست.

وقتی Warpها به Barrier می‌رسند،
آن‌هایی که زودتر رسیده‌اند
باید منتظر Warpهای کندتر بمانند.



Warp A

█████ Waiting



Warp B

██ Computing



Warp C

████ Loading

بنابراین استفاده بیش از حد از Barrier
می‌تواند Performance را کاهش دهد.

ENGINEERING INSIGHT

بهترین Barrier، Barrierی است که به آن نیاز نداشته باشید

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

PERFORMANCE DETECTIVE

اگر GPU زمان زیادی را در انتظار می‌گذراند…

  • آیا Barrierهای غیرضروری دارید؟
  • آیا بعضی Warpها بسیار دیرتر از بقیه به Barrier می‌رسند؟
  • آیا وابستگی بین Threadها را می‌توان کاهش داد؟
  • آیا می‌توان داده‌ها را طوری تقسیم کرد که هر Thread مستقل‌تر کار کند؟

UNDER THE HOOD

Barrier فقط برای «صبر کردن» نیست

در بسیاری از معماری‌های GPU، عملیات همگام‌سازی علاوه بر هماهنگ کردن Threadها، به سخت‌افزار اعلام می‌کند که اکنون همه داده‌های مورد انتظار باید در وضعیت قابل مشاهده و سازگار قرار گرفته باشند. این موضوع برای الگوریتم‌هایی که چندین Thread روی یک ساختار داده مشترک کار می‌کنند، ضروری است.



Threads

      │

      ▼

Write Shared Memory

      │

      ▼

Barrier

      │

      ▼

Read Shared Memory

اگر این مرحله حذف شود، نتیجه برنامه ممکن است از یک اجرا به اجرای دیگر متفاوت باشد؛ حتی اگر کد تغییری نکرده باشد.

L1 Cache چیست؟

تا اینجا دو نوع حافظه را شناختیم:

  • Register

    (خصوصی و فوق‌العاده سریع)

  • Shared Memory

    (اشتراکی و سریع)

اما هنوز یک سؤال باقی مانده است.

اگر داده‌ای داخل Register یا Shared Memory نباشد،
آیا GPU باید مستقیماً به VRAM مراجعه کند؟

اگر پاسخ «بله» بود،
تقریباً بیشتر زمان GPU
صرف انتظار برای حافظه می‌شد.

برای جلوگیری از این اتفاق،
GPU از حافظه‌ای به نام

L1 Cache

استفاده می‌کند.

اول یک مثال ساده

فرض کنید روی میز کارتان مشغول طراحی هستید.

کتاب اصلی داخل کتابخانه است.

اما چند صفحه‌ای که مدام به آن‌ها مراجعه می‌کنید
روی میز قرار داده‌اید.



Bookshelf

↓

Desk

↓

Open Notebook

↓

Pencil

در این مثال:

  • Bookshelf → VRAM

  • Desk → L2 Cache

  • Open Notebook → L1 Cache

  • Pencil → Register

هرچه داده به شما نزدیک‌تر باشد،
سریع‌تر به آن دسترسی پیدا می‌کنید.

چرا L1 Cache وجود دارد؟

بسیاری از برنامه‌ها
بارها و بارها
به داده‌های مشابه مراجعه می‌کنند.



Pixel 120

↓

Texture

↓

Pixel 121

↓

Same Texture

↓

Pixel 122

↓

Same Texture

اگر هر بار
داده از VRAM خوانده شود،
بخش بزرگی از زمان اجرا
صرف دسترسی به حافظه خواهد شد.

L1 Cache این مشکل را حل می‌کند.

Cache چگونه کار می‌کند؟

وقتی GPU
داده‌ای را از حافظه اصلی می‌خواند،
آن را برای مدتی
داخل Cache نیز نگه می‌دارد.



VRAM

│

▼

L2 Cache

│

▼

L1 Cache

│

▼

Shader Core

اگر درخواست بعدی
همان داده را بخواهد،
دیگر نیازی به مراجعه مجدد به VRAM نیست.

L1 Cache را چه کسی مدیریت می‌کند؟

برخلاف Shared Memory،
برنامه‌نویس مستقیماً داده‌ای را
داخل L1 Cache قرار نمی‌دهد.

این کار به صورت خودکار
توسط سخت‌افزار انجام می‌شود.

مقایسه Shared Memory و L1 Cache

ویژگی

Shared Memory

L1 Cache

مدیریت

برنامه‌نویس / کامپایلر

سخت‌افزار

بارگذاری داده

دستی

خودکار

کنترل کامل

بله

خیر

ENGINEERING INSIGHT

چرا Cache را قابل برنامه‌ریزی نکرده‌اند؟

در نگاه اول شاید به نظر برسد اگر برنامه‌نویس بتواند Cache را مستقیماً مدیریت کند، عملکرد همیشه بهتر خواهد شد.

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

UNDER THE HOOD

Cache فقط سرعت را زیاد نمی‌کند؛ ترافیک حافظه را هم کم می‌کند

اگر صدها Thread به یک داده یکسان نیاز داشته باشند، بدون Cache ممکن است همان داده بارها از VRAM خوانده شود. Cache با نگه داشتن نسخه‌ای از داده در نزدیکی Shader Core، تعداد مراجعه به حافظه اصلی را کاهش می‌دهد. این کار علاوه بر کاهش تأخیر، فشار روی Memory Bus و کنترلرهای حافظه را نیز کمتر می‌کند.



Without Cache

VRAM

↓

Read

↓

Read

↓

Read

↓

Read



With Cache

VRAM

↓

Read Once

↓

L1 Cache

↓

Reuse

Reuse

Reuse

وقتی Shader داده‌ای را درخواست می‌کند چه اتفاقی می‌افتد؟

فرض کنید Shader به یک مقدار از حافظه نیاز دارد.

اولین جایی که سخت‌افزار بررسی می‌کند،
L1 Cache است.



Shader

    │

    ▼

L1 Cache

    │

 ┌──┴──┐

 │     │

Hit   Miss

از اینجا به بعد
دو سناریوی کاملاً متفاوت رخ می‌دهد.

Cache Hit

اگر داده داخل L1 Cache وجود داشته باشد،
GPU مستقیماً همان نسخه را استفاده می‌کند.



Shader

↓

L1 Cache

↓

✔ Found

↓

Return Data

این حالت
Cache Hit
نام دارد.

Cache Hit
سریع‌ترین حالت ممکن
بعد از Register و Shared Memory است.

Cache Miss

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



Shader

↓

L1 Cache

↓

✖ Not Found

↓

L2 Cache

↓

VRAM

به این وضعیت

Cache Miss

گفته می‌شود.

بعد از Cache Miss چه اتفاقی می‌افتد؟

اگر داده از L2 Cache
یا VRAM خوانده شود،
معمولاً نسخه‌ای از آن
دوباره داخل L1 Cache قرار می‌گیرد.



VRAM

↓

L2

↓

L1

↓

Shader

بنابراین اگر همان داده
دوباره موردنیاز باشد،
احتمال زیادی وجود دارد
که این بار Cache Hit رخ دهد.

چرا Cache Hit مهم است؟

فرض کنید
هزار Thread
به یک Texture مراجعه می‌کنند.

اگر همه آن‌ها
مستقیماً از VRAM بخوانند،
Memory Bus به شدت شلوغ خواهد شد.

اما اگر اولین Thread
داده را وارد Cache کند،
Threadهای بعدی
همان نسخه را استفاده خواهند کرد.



Thread 0

↓

VRAM



↓

Cache Filled



↓

Thread 1

Cache Hit



↓

Thread 2

Cache Hit



↓

Thread 3

Cache Hit

Cache Hit Rate

یکی از مهم‌ترین شاخص‌های عملکرد Cache،

Hit Rate

است.

نمونه نرخ موفقیت Cache

Hit Rate

وضعیت تقریبی

95%

عالی

80%

خوب

50%

نیاز به بررسی

20%

الگوی دسترسی نامناسب

مقادیر بالا نمونه‌هایی برای درک مفهوم هستند و به نوع برنامه، الگوی دسترسی و معماری GPU بستگی دارند.

ENGINEERING INSIGHT

Cache فقط برای داده‌های «تکراری» نیست

بسیاری تصور می‌کنند Cache فقط زمانی مفید است که دقیقاً همان آدرس دوباره خوانده شود.

در عمل، Cache معمولاً داده‌ها را در بلوک‌های متوالی نگه می‌دارد. بنابراین حتی اگر درخواست بعدی دقیقاً همان آدرس نباشد، ممکن است در همان بلوک قرار داشته باشد و بدون مراجعه به VRAM پاسخ داده شود.

PERFORMANCE DETECTIVE

اگر Cache Hit Rate پایین باشد…

  • آیا الگوی دسترسی به حافظه کاملاً تصادفی است؟
  • آیا داده‌ها آن‌قدر بزرگ هستند که سریع از Cache خارج می‌شوند؟
  • آیا Threadهای مجاور به داده‌های کاملاً متفاوت مراجعه می‌کنند؟
  • آیا می‌توان Locality را افزایش داد؟

UNDER THE HOOD

Cache Miss همیشه به معنی مراجعه مستقیم به VRAM نیست

یکی از برداشت‌های اشتباه این است که اگر L1 Cache داده‌ای را پیدا نکند، حتماً باید از VRAM خوانده شود. در عمل، درخواست معمولاً به سطوح بعدی سلسله‌مراتب حافظه مانند L2 Cache ارسال می‌شود و فقط در صورت نبودن داده در آنجا، دسترسی به حافظه اصلی انجام می‌شود. همین سلسله‌مراتب باعث می‌شود بسیاری از Cache Missها بدون رسیدن به VRAM برطرف شوند.

آیا Cache فقط یک عدد را ذخیره می‌کند؟

فرض کنید Shader
فقط یک عدد را از حافظه درخواست کند.

به نظر شما GPU
فقط همان یک عدد را داخل Cache قرار می‌دهد؟

شاید در نگاه اول
این منطقی به نظر برسد.

اما سخت‌افزار
تقریباً هیچ‌وقت این کار را انجام نمی‌دهد.

Cache معمولاً داده‌ها را
به صورت بلوک‌های متوالی
ذخیره می‌کند،
نه تک‌تک مقادیر.

Cache Line چیست؟

یک مثال ساده

فرض کنید برنامه
فقط مقدار شماره ۱۲ را می‌خواهد.



Memory

...

8

9

10

11

12

13

14

15

...

GPU معمولاً فقط مقدار ۱۲ را
داخل Cache قرار نمی‌دهد.

بلکه کل این بلوک را
یکجا وارد Cache می‌کند.



Cache Line

┌─────────────────────┐

8

9

10

11

12

13

14

15

└─────────────────────┘

چرا این کار انجام می‌شود؟

زیرا در بسیاری از برنامه‌ها،
اگر مقدار ۱۲ استفاده شود،
احتمال زیادی وجود دارد
که چند لحظه بعد
۱۳ یا ۱۴ نیز استفاده شوند.

به این ویژگی

Spatial Locality

گفته می‌شود.

یک مثال در پردازش تصویر

فرض کنید Shader
در حال پردازش Pixel شماره ۱۰۰ باشد.



98

99

100

101

102

103

104

احتمال بسیار زیادی وجود دارد
که Pixel بعدی
۱۰۱ باشد،
نه Pixel شماره ۹۰۰۰۰.

پس آوردن چند Pixel مجاور
کاملاً منطقی است.

مزیت Cache Line

چرا Cache از بلوک استفاده می‌کند؟

مزیت

دلیل

Hit Rate بیشتر

داده‌های مجاور آماده هستند

ترافیک کمتر

چند درخواست با یک بار انتقال پاسخ داده می‌شود

Latency کمتر

نیاز به مراجعه مجدد کاهش می‌یابد

اما همیشه هم مفید نیست

اگر برنامه
به داده‌های کاملاً تصادفی مراجعه کند،

بخش بزرگی از Cache Line
هیچ‌وقت استفاده نخواهد شد.



Cache Line

8

9

10

11

12

13

14

15

↓

Only 12 Used

در این حالت
کارایی Cache کاهش پیدا می‌کند.

ENGINEERING INSIGHT

چرا اندازه Cache Line بزرگ‌تر نمی‌شود؟

اگر Cache Line بسیار کوچک باشد،
تعداد زیادی انتقال حافظه انجام می‌شود.

اگر هم بیش از حد بزرگ باشد،
ممکن است حجم زیادی از داده‌هایی منتقل شوند که هرگز استفاده نمی‌شوند.

معماران GPU اندازه Cache Line را طوری انتخاب می‌کنند که بین احتمال استفاده مجدد، پهنای باند و هزینه سخت‌افزار تعادل برقرار شود.

PERFORMANCE DETECTIVE

اگر Cache Hit پایین است…

  • آیا Threadهای مجاور
    به داده‌های مجاور مراجعه می‌کنند؟

  • آیا الگوی دسترسی
    Spatial Locality دارد؟

  • آیا داده‌ها
    کاملاً تصادفی هستند؟

  • آیا Cache Lineها
    قبل از استفاده مجدد
    جایگزین می‌شوند؟

UNDER THE HOOD

GPU آدرس‌ها را یکی‌یکی منتقل نمی‌کند

یکی از دلایل اصلی سرعت Cache این است که سخت‌افزار انتقال داده را در واحدهای بزرگ‌تر از یک مقدار انجام می‌دهد. این تصمیم باعث کاهش تعداد تراکنش‌های حافظه و افزایش بهره‌وری Memory Bus می‌شود. به همین دلیل، الگوهای دسترسی متوالی تقریباً همیشه نسبت به دسترسی‌های کاملاً تصادفی عملکرد بهتری دارند.

وقتی Cache پر می‌شود چه اتفاقی می‌افتد؟

فرض کنید روی میز کار شما
فقط برای چهار کتاب جا وجود دارد.



Desk

┌─────────┐
│ Book A  │
│ Book B  │
│ Book C  │
│ Book D  │
└─────────┘

FULL

حالا به کتاب پنجم نیاز دارید.

برای قرار دادن آن روی میز،
یکی از کتاب‌های قبلی باید کنار گذاشته شود.

اما کدام کتاب؟

Cache نیز با همین مسئله روبه‌رو می‌شود.

Cache ظرفیت محدودی دارد

L1 Cache نمی‌تواند
تمام داده‌های موجود در VRAM را نگه دارد.

بنابراین با ورود Cache Lineهای جدید،
ممکن است لازم باشد
یکی از Lineهای موجود جای خود را به داده جدید بدهد.



L1 Cache

┌────────────┐
│ Line A     │
│ Line B     │
│ Line C     │
│ Line D     │
└────────────┘

       ▲

       │ New Line E

       │

Which line should leave?

تصمیم‌گیری درباره اینکه
کدام داده کنار گذاشته شود،
بخشی از سیاست جایگزینی Cache است.

Cache Replacement Policy چیست؟

چرا انتخاب قربانی مهم است؟

فرض کنید Cache داده‌ای را حذف کند
که چند دستور بعد دوباره به آن نیاز داریم.



Line X in Cache

      │

      ▼

Evicted

      │

      ▼

Needed Again

      │

      ▼

Cache Miss

      │

      ▼

Lower Memory Level

در این حالت،
یک Cache Miss اضافی ایجاد شده است.

اما اگر داده‌ای حذف شود
که دیگر به آن نیاز نداریم،
فضای Cache با هزینه بسیار کمتری آزاد شده است.

Replacement Policy تلاش می‌کند
داده‌ای را قربانی کند
که احتمال استفاده مجدد از آن کمتر است.

یک ایده معروف: LRU

یکی از سیاست‌های کلاسیک برای توضیح مفهوم جایگزینی،

Least Recently Used

یا به اختصار

LRU

است.

ایده بسیار ساده است:

داده‌ای را حذف کن
که برای طولانی‌ترین مدت استفاده نشده است.



Most Recently Used

A
│
B
│
C
│
D   ← Least Recently Used

New Line E arrives

↓

Evict D

↓

A
B
C
E

چرا LRU منطقی به نظر می‌رسد؟

چون بسیاری از برنامه‌ها
نوع دیگری از Locality را نشان می‌دهند:

به همین دلیل،
داده‌ای که مدت زیادی استفاده نشده
می‌تواند نامزد مناسبی برای جایگزینی باشد.

Spatial و Temporal Locality را کنار هم ببینیم

دو اصل مهم پشت عملکرد Cache

نوع Locality

ایده

مثال

Spatial Locality

داده‌های نزدیک احتمالاً به‌زودی استفاده می‌شوند

Pixelهای مجاور

Temporal Locality

داده‌ای که اخیراً استفاده شده ممکن است دوباره استفاده شود

خواندن چندباره یک مقدار

Cache Line از Spatial Locality بهره می‌برد،
در حالی که تصمیم‌های مربوط به نگه‌داری و جایگزینی داده
می‌توانند از Temporal Locality نیز بهره ببرند.

یک سیاست ساده دیگر: FIFO

در مدل

First In, First Out

قدیمی‌ترین داده‌ای که وارد مجموعه شده،
اول خارج می‌شود.



Cache

A  ← Oldest
B
C
D  ← Newest

New E arrives

↓

Remove A

↓

B
C
D
E

این روش ساده‌تر است،
اما لزوماً بهترین تصمیم را برای Locality برنامه نمی‌گیرد.

پس GPU از LRU استفاده می‌کند؟

اینجا باید بسیار محتاط باشیم.

GPUهای واقعی الزاماً از
LRU کامل یا FIFO ساده استفاده نمی‌کنند.

سیاست واقعی می‌تواند
تقریبی،
چندمرحله‌ای،
وابسته به نوع Cache
یا مخصوص یک معماری باشد.

LRU و FIFO در اینجا مدل‌های آموزشی هستند؛
نه توصیف قطعی پیاده‌سازی تمام GPUها.

ENGINEERING INSIGHT

چرا از LRU کاملاً دقیق استفاده نکنیم؟

LRU کامل در ظاهر ایده جذابی است،
اما سخت‌افزار باید دائماً ترتیب استفاده از تعداد زیادی Cache Line را ثبت و به‌روزرسانی کند.

هرچه Cache بزرگ‌تر و Associativity بیشتر شود،
پیاده‌سازی چنین تصمیمی می‌تواند به منطق کنترلی،
فضای سخت‌افزاری و انرژی بیشتری نیاز داشته باشد.

به همین دلیل،
پردازنده‌های واقعی ممکن است از سیاست‌های تقریبی یا Heuristicهایی استفاده کنند
که با هزینه کمتر،
رفتاری مناسب برای workloadهای هدف ایجاد کنند.

Cache Thrashing

حالا یک حالت بدتر را تصور کنید.

برنامه دائماً مجموعه‌ای از داده‌ها را درخواست می‌کند
که از ظرفیت مؤثر Cache بزرگ‌تر است.



Need A B C D E

Cache fits only:

A B C D

↓

Load E

Evict A

↓

Need A again

Evict B

↓

Need B again

Evict C

↓

...

Cache دائماً داده وارد می‌کند
و کمی بعد همان داده را بیرون می‌اندازد.

به این رفتار

Cache Thrashing

گفته می‌شود.

Working Set

برای درک Thrashing،
یک مفهوم دیگر بسیار مفید است:

اگر Working Set مناسبِ یک مرحله
در Cache جا شود،
احتمال Reuse بالا می‌رود.



Small Working Set

┌──────────────┐
│ A B C D      │
└──────────────┘

Fits in Cache

        ↓

High Reuse


Large Working Set

┌──────────────────────────┐
│ A B C D E F G H I J ...  │
└──────────────────────────┘

        ↓

Cache Capacity

        ↓

Frequent Eviction

PERFORMANCE DETECTIVE

Hit Rate پایین است؛ اما دسترسی‌ها ظاهراً منظم‌اند

در این شرایط،
فقط دنبال Random Access نگردید.

  • بررسی کنید Working Set
    نسبت به Cache بیش از حد بزرگ نباشد.

  • بررسی کنید داده قبل از استفاده مجدد
    از Cache خارج نمی‌شود.

  • به میزان Data Reuse توجه کنید.

  • بررسی کنید چند workload
    برای ظرفیت Cache با یکدیگر رقابت نمی‌کنند.

گاهی مشکل نه «الگوی بد آدرس‌دهی»،
بلکه صرفاً
Cache Capacity
است.

UNDER THE HOOD

Cache Miss فقط یک نوع ندارد

تا اینجا همه Cache Missها را مشابه یکدیگر در نظر گرفتیم،
اما از دید تحلیل معماری می‌توان علت Missها را بهتر تفکیک کرد.

نوع

ایده اصلی

Compulsory Miss

داده برای اولین بار درخواست شده است

Capacity Miss

Working Set از ظرفیت Cache بزرگ‌تر است

Conflict Miss

محدودیت محل قرارگیری داده‌ها باعث جایگزینی نامناسب می‌شود

این تفکیک مهم است،
زیرا راه‌حل هر نوع Cache Miss متفاوت است.

ARCHITECTURE NOTE

Replacement Policy یک جزئیات معماری است

نباید فرض کنیم تمام GPUهای NVIDIA، AMD، Intel یا Apple
سیاست جایگزینی یکسانی دارند.

حتی میان نسل‌های مختلف یک سازنده نیز
طراحی Cache می‌تواند تغییر کند.

بنابراین هنگام Performance Tuning،
به‌جای وابسته کردن الگوریتم به یک سیاست جایگزینی فرضی،
به Locality، Working Set، Hit Rate و رفتار اندازه‌گیری‌شده روی سخت‌افزار هدف توجه کنید.

GPU MEMORY ARCHITECTURE

Cache Mapping و Associativity

وقتی یک Cache Line وارد Cache می‌شود،
آیا سخت‌افزار می‌تواند آن را در هر جای خالی قرار دهد؟

یک سؤال ساده، اما بسیار مهم

تا اینجا گفتیم Cache ظرفیت محدودی دارد
و وقتی پر شود،
ممکن است لازم باشد یک Cache Line جایگزین شود.

اما هنوز یک سؤال مهم را پاسخ نداده‌ایم:

آیا یک Cache Line جدید
می‌تواند در هر قسمت خالی Cache قرار بگیرد؟

پاسخ این است:

نه، لزوماً.

در بسیاری از طراحی‌های Cache،
آدرس حافظه تعیین می‌کند
یک Cache Line در کدام بخش یا مجموعه از Cache
اجازه قرار گرفتن دارد.

اول با یک پارکینگ تصورش کنیم

فرض کنید یک پارکینگ
صد جای خالی دارد.

در ساده‌ترین حالت،
هر خودرو می‌تواند
در هر جای خالی پارک کند.


CAR A
   │
   ▼

┌────────────────────────────┐
│ Any available parking spot │
└────────────────────────────┘

اما حالا تصور کنید
شماره پلاک هر خودرو تعیین کند
در کدام قسمت پارکینگ
اجازه پارک دارد.


Car A ─────► Zone 0

Car B ─────► Zone 1

Car C ─────► Zone 0

Car D ─────► Zone 3

Cache Mapping
تقریباً چنین مسئله‌ای را حل می‌کند:

هر آدرس حافظه
در کدام قسمت Cache
اجازه قرار گرفتن دارد؟

Cache Set چیست؟

Cache معمولاً می‌تواند
به مجموعه‌هایی به نام
Set
تقسیم شود.


Cache

┌─────────────────┐
│ Set 0           │
├─────────────────┤
│ Set 1           │
├─────────────────┤
│ Set 2           │
├─────────────────┤
│ Set 3           │
└─────────────────┘

بخشی از آدرس حافظه
برای انتخاب Set مناسب استفاده می‌شود.


Memory Address

┌─────────┬─────────┬─────────┐
│   Tag   │  Index  │ Offset  │
└─────────┴─────────┴─────────┘
              │
              ▼
          Cache Set

فعلاً کافی است این سه بخش را چنین در ذهن نگه داریم:

بخش نقش مفهومی
Offset انتخاب محل داده درون Cache Line
Index انتخاب Set
Tag تشخیص اینکه Cache Line متعلق به کدام آدرس است

حالت اول: Direct-Mapped Cache

در یک مدل
Direct-Mapped،
هر بلوک حافظه فقط
یک محل مشخص در Cache دارد.


Memory Blocks

A ─────────► Set 0
B ─────────► Set 1
C ─────────► Set 2
D ─────────► Set 3

E ─────────► Set 0
F ─────────► Set 1
G ─────────► Set 2
H ─────────► Set 3

به این نکته دقت کنید:

هم A و هم E
به Set 0 نگاشت شده‌اند.

اینجا اتفاق عجیبی می‌افتد

فرض کنید بخش‌های دیگر Cache
کاملاً خالی هستند.


Cache

Set 0  [ A ]
Set 1  [ EMPTY ]
Set 2  [ EMPTY ]
Set 3  [ EMPTY ]

حالا E وارد می‌شود.

E نیز فقط اجازه دارد
در Set 0 قرار بگیرد.


E arrives

     │
     ▼

Set 0

[ A ]

     │
     ▼

Evict A

     │
     ▼

[ E ]

یعنی A خارج می‌شود،
با اینکه بخش‌های دیگری از Cache
هنوز خالی هستند.

پس «ظرفیت خالی Cache»
لزوماً به این معنی نیست
که هر داده‌ای می‌تواند از آن استفاده کند.

حالا Conflict Miss معنا پیدا می‌کند

فرض کنید برنامه مرتباً
A و E را درخواست کند.


Request A
    ↓
Cache A

Request E
    ↓
Evict A
    ↓
Cache E

Request A
    ↓
Evict E
    ↓
Cache A

Request E
    ↓
Evict A

...

دو داده دائماً یکدیگر را
از Cache بیرون می‌اندازند.

این اتفاق می‌تواند
حتی زمانی رخ دهد که Cache
از نظر ظرفیت کلی
فضای کافی داشته باشد.

راه‌حل: به هر Set چند جایگاه بدهیم

اینجاست که مفهوم
Associativity
وارد می‌شود.

به‌جای اینکه هر Set
فقط یک Cache Line نگه دارد،
می‌توان چند جایگاه درون آن ایجاد کرد.

هر جایگاه معمولاً
Way
نامیده می‌شود.


2-Way Set-Associative Cache

          Way 0       Way 1

Set 0    [  A  ]     [  E  ]

Set 1    [     ]     [     ]

Set 2    [     ]     [     ]

Set 3    [     ]     [     ]

حالا A و E
می‌توانند هم‌زمان در Set 0 باقی بمانند.

N-Way Set Associative یعنی چه؟

عدد N مشخص می‌کند
هر Set چند Cache Line
می‌تواند هم‌زمان نگه دارد.

ساختار Way در هر Set انعطاف قرارگیری
Direct-Mapped 1 کم
2-Way 2 بیشتر
4-Way 4 بیشتر
8-Way 8 زیاد

با افزایش Associativity،
احتمال Conflict Miss
معمولاً کاهش پیدا می‌کند.

اگر محدودیت را کاملاً حذف کنیم چه؟

در انتهای دیگر طیف،
ساختاری به نام
Fully Associative
وجود دارد.

در مدل مفهومی آن،
یک Cache Line می‌تواند
در هر جایگاه Cache قرار بگیرد.


Memory Line

      │
      ▼

┌──────────────────────────┐
│ Way │ Way │ Way │ Way    │
│     │     │     │        │
└──────────────────────────┘

Can use any available entry

این انعطاف Conflict را کاهش می‌دهد،
اما جست‌وجوی داده و پیاده‌سازی سخت‌افزاری
پیچیده‌تر می‌شود.


ENGINEERING INSIGHT

چرا Associativity را تا جای ممکن زیاد نمی‌کنیم؟

در نگاه اول پاسخ ساده به نظر می‌رسد:
Wayهای بیشتری بسازیم
تا Conflict Miss کمتر شود.

اما سخت‌افزار هنگام Cache Lookup
باید بررسی کند که Tag موردنظر
در کدام Way قرار دارد.


Requested Tag

      │
      ▼

Set

 ├── Way 0 ── Compare
 ├── Way 1 ── Compare
 ├── Way 2 ── Compare
 └── Way 3 ── Compare

      │
      ▼

Match?

Associativity بیشتر می‌تواند
Conflict Miss را کاهش دهد،
اما در مقابل
منطق مقایسه، مصرف انرژی،
مساحت سخت‌افزار و پیچیدگی طراحی را افزایش می‌دهد.

بنابراین دوباره با همان اصل همیشگی معماری روبه‌رو هستیم:

بهترین طراحی،
بیشترین مقدار یک ویژگی نیست؛
بهترین تعادل میان هزینه‌ها و مزایا است.

حالا سه نوع Cache Miss را واقعاً می‌فهمیم

نوع Miss علت اصلی سؤال تشخیصی
Compulsory اولین دسترسی به داده آیا این داده قبلاً وارد Cache شده بود؟
Capacity Working Set بیش از ظرفیت Cache است آیا داده فعال واقعاً در Cache جا می‌شود؟
Conflict رقابت برای Setهای یکسان آیا Mapping باعث Eviction زودهنگام شده است؟

Myth vs Reality

تصور رایج واقعیت
اگر Cache فضای خالی داشته باشد، داده حتماً در آن جا می‌شود. لزوماً نه؛ Mapping می‌تواند محل‌های مجاز را محدود کند.
تمام Cache Missها به دلیل کوچک بودن Cache هستند. Conflict Miss می‌تواند حتی با وجود ظرفیت آزاد رخ دهد.
Associativity بیشتر همیشه بهتر است. Conflict کمتر می‌شود، اما هزینه و پیچیدگی سخت‌افزار افزایش می‌یابد.


PERFORMANCE DETECTIVE

وقتی Cache بزرگ است ولی Hit Rate هنوز پایین مانده…

فقط ظرفیت Cache را مقصر ندانید.

  • الگوی آدرس‌دهی را بررسی کنید.
  • به Strideهای منظم اما نامناسب توجه کنید.
  • بررسی کنید چند جریان داده برای Setهای مشابه رقابت نمی‌کنند.
  • Working Set و Data Layout را با هم تحلیل کنید.
  • نتیجه را روی سخت‌افزار هدف اندازه‌گیری کنید؛
    نه بر اساس حدس درباره سیاست داخلی Cache.


ARCHITECTURE NOTE

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

Direct-Mapped،
Set-Associative و Fully Associative
مدل‌های بنیادی و بسیار مفیدی برای فهم طراحی Cache هستند.

اما جزئیات واقعی Cache در GPUهای مدرن
می‌تواند بسیار پیچیده‌تر باشد
و سازندگان همیشه تمام جزئیات Mapping،
Associativity یا Replacement Policy را منتشر نمی‌کنند.

بنابراین این مفاهیم را برای
استدلال معماری
استفاده می‌کنیم
و برای Performance Tuning نهایی،
رفتار واقعی سخت‌افزار هدف را اندازه‌گیری می‌کنیم.

خلاصه این بخش

  • Cache Line لزوماً نمی‌تواند در هر نقطه Cache قرار بگیرد.
  • Index مشخص می‌کند یک آدرس به کدام Set نگاشت شود.
  • Way تعداد جایگاه‌های قابل استفاده در هر Set را مشخص می‌کند.
  • Associativity بیشتر معمولاً Conflict Miss را کاهش می‌دهد.
  • Conflict Miss با Capacity Miss یکسان نیست.
  • افزایش Associativity هزینه سخت‌افزاری دارد.

در پایان این بخش باید چه چیزهایی بلد باشید؟

  • تفاوت Cache Line، Set و Way را توضیح دهید.
  • Direct-Mapped Cache را به زبان ساده تشریح کنید.
  • توضیح دهید چرا Conflict Miss می‌تواند با وجود ظرفیت آزاد رخ دهد.
  • مفهوم N-Way Set Associativity را توضیح دهید.
  • Trade-off افزایش Associativity را تحلیل کنید.
  • Compulsory، Capacity و Conflict Miss را از یکدیگر تشخیص دهید.

فصل: L2 Cache

سطح: متوسط

پیش نیاز:
L1 Cache،
Cache Line،
Cache Hit / Miss،
Cache Mapping

موضوع:
GPU Memory Hierarchy

زمان مطالعه:
حدود 12 تا 15 دقیقه


GPU MEMORY ARCHITECTURE

L2 Cache در GPU؛ حافظه مشترک میان واحدهای پردازشی

اگر هر بخش پردازشی GPU به L1 Cache نزدیک خودش دسترسی دارد،
پس وقتی داده باید میان بخش های مختلف GPU استفاده شود چه اتفاقی می افتد؟
اینجا L2 Cache وارد معماری می شود.


پاسخ سریع: L2 Cache چیست؟

L2 Cache یک سطح بزرگ تر و معمولا مشترک تر از Cache در GPU است
که میان واحدهای پردازشی و حافظه اصلی قرار می گیرد.
این Cache می تواند بسیاری از درخواست هایی را که در Cacheهای نزدیک تر
پاسخ داده نشده اند، بدون مراجعه مستقیم به VRAM پاسخ دهد و در نتیجه
Latency و ترافیک حافظه را کاهش دهد.

در این فصل چه چیزهایی یاد می گیریم؟

  • L2 Cache در کجای Memory Hierarchy قرار دارد.
  • تفاوت نقش L1 و L2 Cache چیست.
  • چرا L2 معمولا بزرگ تر اما دورتر از L1 است.
  • چگونه L2 ترافیک VRAM را کاهش می دهد.
  • چرا اشتراک داده میان بخش های مختلف GPU به L2 اهمیت می دهد.
  • L2 Hit و L2 Miss چه تفاوتی در مسیر دسترسی حافظه ایجاد می کنند.
  • چرا بزرگ تر شدن L2 می تواند مفید باشد اما به تنهایی تضمین کننده Performance بالاتر نیست.

نقشه مفهومی فصل


01


Core نیاز به داده دارد

درخواست حافظه از واحد پردازشی آغاز می شود.


02


Cacheهای نزدیک بررسی می شوند

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


03


L2 Cache

یک سطح بزرگ تر از Cache می تواند درخواست را پاسخ دهد.


04


Memory

اگر داده در سطوح Cache موجود نباشد،
درخواست باید به حافظه اصلی GPU برسد.

چرا بعد از L1 به Cache دیگری نیاز داریم؟

فرض کنید GPU از تعداد زیادی
واحد پردازشی تشکیل شده است.


Compute Unit 0
     │
     ▼
    L1


Compute Unit 1
     │
     ▼
    L1


Compute Unit 2
     │
     ▼
    L1


Compute Unit 3
     │
     ▼
    L1

Cacheهای نزدیک به واحدهای پردازشی
برای سرعت بسیار بالا طراحی شده اند.

اما ظرفیت آنها محدود است.

حالا فرض کنید داده مورد نیاز
در L1 پیدا نشود.


Core

 │

 ▼

L1

 │
 │ MISS
 ▼

???

یک طراحی ساده می توانست
هر L1 Miss را مستقیما به حافظه اصلی بفرستد.

اما این کار بسیار پرهزینه است.

بنابراین سطح دیگری از Cache
میان Cacheهای نزدیک و حافظه اصلی قرار می گیرد:


Compute Units

     │

     ▼

L1 / Local Caches

     │

     ▼

┌────────────────────┐
│      L2 CACHE      │
└────────────────────┘

     │

     ▼

Memory Controllers

     │

     ▼

VRAM / Main Memory

L1 و L2 قرار نیست یک کار را انجام دهند

ممکن است در نگاه اول این سوال ایجاد شود:

اگر L1 Cache داریم،
چرا آن را بسیار بزرگ تر نمی کنیم
و L2 را حذف نمی کنیم؟

پاسخ در یکی از بنیادی ترین Trade-offهای طراحی Cache قرار دارد:


سرعت، ظرفیت، فاصله و هزینه.

مقایسه مفهومی L1 و L2 Cache
ویژگی L1 Cache L2 Cache
فاصله از واحد پردازشی بسیار نزدیک دورتر
ظرفیت نسبی کمتر بیشتر
Latency نسبی کمتر بیشتر
دامنه استفاده محلی تر مشترک تر
نقش اصلی دسترسی بسیار سریع کاهش مراجعه به حافظه اصلی

بنابراین L1 و L2
رقیب یکدیگر نیستند.

آنها دو سطح متفاوت
از یک سلسله مراتب حافظه هستند.

وقتی L2 Hit رخ می دهد

فرض کنید داده در L1 موجود نیست.


Request

   │

   ▼

  L1
   │
   │ MISS
   ▼

  L2
   │
   │ HIT
   ▼

Return Data

در این حالت،
درخواست بدون رسیدن به حافظه اصلی
پاسخ داده می شود.

این اتفاق بسیار مهم است،
زیرا دسترسی به سطح پایین تر حافظه
معمولا هزینه بیشتری دارد.

اگر L2 هم داده را نداشته باشد چه؟

حالا حالت دیگری را در نظر بگیرید.


Request

   │

   ▼

  L1
   │
   │ MISS
   ▼

  L2
   │
   │ MISS
   ▼

Memory Controller

   │

   ▼

VRAM / Main Memory

در این حالت،
درخواست باید به سطح پایین تر
Memory Hierarchy ارسال شود.

به همین دلیل
L2 Hit Rate می تواند تاثیر مهمی
بر میزان ترافیک حافظه داشته باشد.

ویژگی مهم L2: دید مشترک تر

یکی از تفاوت های مفهومی مهم L2
این است که معمولا نسبت به L1
در سطح گسترده تری از GPU قابل استفاده است.

برای مثال،
فرض کنید دو بخش پردازشی
به یک داده مشابه نیاز دارند.


Compute Unit A
      │
      ▼
     L1 A
      │
      └─────────┐
                │
                ▼
          ┌──────────┐
          │    L2    │
          └──────────┘
                ▲
                │
      ┌─────────┘
      │
     L1 B
      ▲
      │
Compute Unit B

وجود یک سطح Cache مشترک تر
می تواند از مراجعه های تکراری
به حافظه اصلی جلوگیری کند.

Under the Hood — چرا L2 باید به Memory System نزدیک باشد؟

L2 Cache فقط یک فضای ذخیره سازی بزرگ تر نیست.
جایگاه آن در معماری باعث می شود بتواند بخشی از ترافیک
میان واحدهای پردازشی و زیرسیستم حافظه را جذب کند.


Shader / Compute Work

        │

        ▼

Local Cache Level

        │

        ▼

      L2

        │

        ▼

Memory System

        │

        ▼

External / Main Memory

بنابراین تاثیر L2 را نباید فقط با عبارت
«Cache بزرگ تر»
توضیح داد.

L2 بخشی از طراحی کل Memory System است.

L2 چگونه ترافیک حافظه را کاهش می دهد؟

فرض کنید چند درخواست
به داده مشابه نیاز دارند.

بدون استفاده موثر از Cache،
ممکن است درخواست ها بارها
به حافظه اصلی برسند.


Without Effective Cache Reuse

Request A ─────────► Memory
Request A ─────────► Memory
Request A ─────────► Memory
Request A ─────────► Memory

اما اگر داده در L2 باقی بماند:


First Request

Memory
  │
  ▼
 L2


Later Requests

Request ───► L2 HIT
Request ───► L2 HIT
Request ───► L2 HIT

در نتیجه تعداد تراکنش هایی
که باید به حافظه اصلی برسند
کاهش پیدا می کند.

Performance Impact — چرا L2 Hit مهم است؟

وقتی بخش بیشتری از درخواست های حافظه در L2 پاسخ داده شوند،
فشار روی مسیرهای پایین تر Memory Hierarchy کاهش پیدا می کند.

این موضوع می تواند برای workloadهایی که
Data Reuse مناسبی دارند یا فشار زیادی روی حافظه ایجاد می کنند،
اهمیت ویژه ای داشته باشد.

اما L2 Hit Rate را نباید به تنهایی معیار Performance دانست.
اگر workload از جای دیگری مانند توان محاسباتی،
Synchronization یا Latency دیگری محدود شده باشد،
افزایش Hit Rate الزاما به همان نسبت Performance را افزایش نمی دهد.

پس چرا L2 را فوق العاده بزرگ نمی کنیم؟

اگر Cache مفید است،
یک سوال طبیعی شکل می گیرد:

چرا مقدار بسیار زیادی L2 Cache
روی GPU قرار ندهیم؟

زیرا Cache رایگان نیست.

ظرفیت بیشتر می تواند
به ترانزیستور بیشتر،
مساحت Die بیشتر،
مصرف انرژی،
پیچیدگی بیشتر
و Trade-offهای طراحی دیگر منجر شود.

علاوه بر این،
هر workload به یک اندازه
از Cache بزرگ تر سود نمی برد.

Engineering Insight — ظرفیت Cache را جدا از Memory System تحلیل نکنید

مقایسه دو GPU فقط بر اساس عدد L2 Cache
می تواند گمراه کننده باشد.

عملکرد واقعی به مجموعه ای از عوامل بستگی دارد:
معماری Cache،
الگوی دسترسی workload،
پهنای باند حافظه،
Memory Controller،
Latency،
Data Reuse
و سایر بخش های معماری.

بنابراین گزاره ای مانند
«GPU A چون L2 بیشتری دارد حتما سریع تر است»
نتیجه گیری مهندسی معتبری نیست.

ارتباط L2 با Working Set

در بخش قبل با مفهوم Working Set آشنا شدیم.

حالا می توانیم اهمیت آن را
در سطح L2 بهتر ببینیم.


Working Set

┌───────────────────┐
│ A B C D E F       │
└───────────────────┘

        │

        ▼

┌───────────────────┐
│     L2 Cache      │
│ A B C D E F       │
└───────────────────┘

        │

        ▼

High Reuse Potential

اگر بخش مفیدی از Working Set
در L2 باقی بماند،
درخواست های بعدی می توانند
بدون مراجعه مجدد به حافظه اصلی
پاسخ داده شوند.

اما اگر Working Set بسیار بزرگ باشد:


Very Large Working Set

A B C D E F G H I J K L M N ...

             │

             ▼

       Limited L2 Capacity

             │

             ▼

      Frequent Evictions

احتمال Eviction افزایش پیدا می کند
و Reuse موثر کاهش می یابد.

آیا Cache پهنای باند حافظه را بیشتر می کند؟

اینجا باید بین دو مفهوم
تفاوت قائل شویم.

L2 Cache مشخصات فیزیکی
Memory Bus یا تراشه های حافظه را
جادویی تغییر نمی دهد.

اما می تواند تعداد درخواست هایی را
که مجبورند از آن مسیر عبور کنند
کاهش دهد.


More Cache Hits

      │

      ▼

Fewer Memory Requests

      │

      ▼

Less External Traffic

      │

      ▼

Better Effective Use
of Memory System

این تفاوت برای تحلیل Performance
بسیار مهم است.

Common Mistakes — اشتباهات رایج درباره L2 Cache
  • تصور اینکه L1 Miss همیشه مستقیما به VRAM می رود.
  • تصور اینکه L2 فقط نسخه بزرگ تر L1 است و نقش معماری متفاوتی ندارد.
  • مقایسه GPUها فقط بر اساس ظرفیت L2 Cache.
  • فرض اینکه L2 بزرگ تر در تمام workloadها Performance بیشتری ایجاد می کند.
  • یکی دانستن ظرفیت Cache با پهنای باند حافظه.
  • فرض اینکه جزئیات L1/L2 در تمام معماری های GPU یکسان است.

حالا Memory Hierarchy شکل واضح تری دارد


Fast / Small / Close

        Registers

            │

            ▼

     Shared / Local
      Memory Paths

            │

            ▼

        L1 Cache

            │

            ▼

        L2 Cache

            │

            ▼

      Main GPU Memory

            │

            ▼

Large / Farther / Higher Latency

اما هنوز یک بخش بسیار مهم
از این تصویر را کامل نکرده ایم:


مسیر واقعی انتقال داده از L2
به تراشه های حافظه.

برای فهم آن باید سراغ
Memory Controllerها،
Memory Channels
و ساختار ارتباط GPU با حافظه برویم.

سوالات متداول L2 Cache

آیا L2 Cache از L1 کندتر است؟

به طور مفهومی L2 سطح دورتر و بزرگ تری از Cache است
و دسترسی به آن معمولا نسبت به Cache نزدیک تر هزینه بیشتری دارد؛
اما همچنان می تواند از مراجعه به حافظه اصلی جلوگیری کند.
جزئیات دقیق Latency به معماری وابسته است.

آیا L2 Cache بین همه واحدهای GPU مشترک است؟

L2 معمولا دامنه اشتراک گسترده تری نسبت به Cacheهای محلی دارد،
اما توپولوژی دقیق، تقسیم بندی و نحوه دسترسی به آن
به معماری GPU وابسته است.

آیا L2 بیشتر همیشه باعث FPS بیشتر می شود؟

خیر.
تاثیر Cache به workload، الگوی دسترسی حافظه،
Working Set و سایر محدودیت های سیستم بستگی دارد.
یک عدد بزرگ تر به تنهایی تضمین کننده Performance بالاتر نیست.

اگر داده در L2 پیدا نشود چه اتفاقی می افتد؟

در مدل مفهومی، درخواست باید به سطح پایین تر Memory Hierarchy
و در نهایت به حافظه اصلی برسد.
مسیر دقیق این درخواست به طراحی GPU بستگی دارد.

تفاوت اصلی L1 و L2 چیست؟

L1 برای نزدیکی و دسترسی سریع تر طراحی می شود،
در حالی که L2 معمولا ظرفیت و دامنه اشتراک بیشتری دارد
و نقش مهمی در کاهش ترافیک حافظه اصلی ایفا می کند.

خلاصه فصل

  • L2 سطح بزرگ تر و مشترک تری از Cache در Memory Hierarchy است.
  • L2 میان Cacheهای نزدیک تر و Memory System قرار می گیرد.
  • L2 Hit می تواند از مراجعه به حافظه اصلی جلوگیری کند.
  • L2 Miss درخواست را به سطح پایین تر Memory Hierarchy هدایت می کند.
  • L2 می تواند ترافیک حافظه را با نگه داشتن داده های قابل استفاده مجدد کاهش دهد.
  • Working Set و Locality تعیین می کنند یک workload تا چه اندازه از Cache سود ببرد.
  • L2 بزرگ تر به تنهایی تضمین کننده Performance بالاتر نیست.
  • برای تحلیل GPU باید Cache را بخشی از کل Memory System در نظر گرفت.


سطح: متوسط

پیش نیاز:
Memory Hierarchy،
L1 Cache،
L2 Cache

موضوع:
GPU Memory Architecture

زمان مطالعه:
حدود 15 دقیقه


GPU MEMORY ARCHITECTURE

Memory Controller در GPU چیست و چگونه داده را به VRAM می رساند؟

Shader داده ای را درخواست کرده،
L1 آن را ندارد،
L2 هم Miss شده است.

حالا چه کسی درخواست را
به حافظه گرافیکی می رساند؟


پاسخ سریع

Memory Controller بخشی از زیرسیستم حافظه GPU است
که درخواست های حافظه را مدیریت می کند
و ارتباط با حافظه اصلی GPU را سازمان می دهد.

این بخش در مسائلی مانند زمان بندی درخواست ها،
دسترسی به کانال ها یا پارتیشن های حافظه،
خواندن و نوشتن داده
و استفاده موثر از پهنای باند حافظه نقش دارد.

در این فصل چه چیزهایی یاد می گیریم؟

  • Memory Controller چه نقشی در GPU دارد.
  • بعد از L2 Cache Miss چه اتفاقی می افتد.
  • چرا GPU به چند مسیر یا پارتیشن حافظه نیاز دارد.
  • Memory Request چگونه به حافظه اصلی می رسد.
  • چرا ترتیب درخواست های حافظه روی Performance اثر می گذارد.
  • تفاوت Memory Controller، Memory Bus و Memory Channel چیست.
  • چرا تعداد Memory Controllerها را نباید به تنهایی معیار قدرت GPU دانست.

نقشه مفهومی فصل


01


Memory Request

واحد پردازشی داده ای را درخواست می کند.


02


Cache Hierarchy

درخواست ابتدا در سطوح Cache بررسی می شود.


03


Memory Controller

درخواست هایی که باید به حافظه اصلی برسند
وارد زیرسیستم کنترل حافظه می شوند.


04


VRAM

داده خوانده یا نوشته می شود
و نتیجه در مسیر حافظه باز می گردد.

چرا GPU اصلا به Memory Controller نیاز دارد؟

ممکن است در نگاه اول
مسیر حافظه بسیار ساده به نظر برسد:


GPU

 │

 ▼

VRAM

اما GPU می تواند تعداد بسیار زیادی
درخواست حافظه تولید کند.


Request
Request
Request
Request
Request
Request
Request
Request

    │
    ▼

   VRAM ?

همه این درخواست ها
نمی توانند بدون سازمان دهی
به حافظه ارسال شوند.

باید سازوکاری وجود داشته باشد
که جریان درخواست ها را مدیریت کند.

Memory Controller یکی از بخش های کلیدی
این زیرسیستم مدیریت حافظه است.

مسیر یک Memory Request را دنبال کنیم

فرض کنید Shader
به داده ای نیاز دارد
که در Cache موجود نیست.


Shader / Compute Unit

        │
        ▼

      L1 Cache

        │
      MISS
        ▼

      L2 Cache

        │
      MISS
        ▼

 Memory Subsystem

        │
        ▼

 Memory Controller

        │
        ▼

 Memory Interface

        │
        ▼

   VRAM / Memory

این نمودار یک مدل مفهومی است.

جزئیات دقیق مسیر،
تقسیم بندی L2،
تعداد Controllerها
و نحوه اتصال آنها
بین معماری های مختلف متفاوت است.

Memory Controller را مثل چهارراه حافظه تصور کنید

فرض کنید چند مسیر
هم زمان به یک چهارراه می رسند.


Request A ─────┐
               │
Request B ─────┤
               │
Request C ─────┼──► MEMORY SYSTEM
               │
Request D ─────┤
               │
Request E ─────┘

اگر هیچ سیستم مدیریتی وجود نداشته باشد،
استفاده موثر از منابع حافظه دشوار می شود.

Memory Controller باید درخواست ها را
با محدودیت ها و وضعیت حافظه هماهنگ کند.

آیا درخواست ها همیشه به ترتیب ورود اجرا می شوند؟

نه لزوما.

در یک سیستم حافظه واقعی،
اجرای کورکورانه درخواست ها
فقط بر اساس ترتیب ورود
همیشه بهترین استفاده از حافظه را ایجاد نمی کند.


Incoming Requests

A
B
C
D
E

      │
      ▼

Memory Scheduling

      │
      ▼

Order optimized according
to hardware constraints
and current memory state

سخت افزار می تواند درخواست ها را
با توجه به محدودیت های معماری
و وضعیت زیرسیستم حافظه مدیریت کند.

بنابراین:

ترتیب صدور درخواست توسط Shader
لزوما همان ترتیب دقیق اجرای فیزیکی
در حافظه نیست.

Under the Hood — چرا زمان بندی حافظه اهمیت دارد؟

حافظه مدرن یک آرایه ساده نیست
که تمام آدرس های آن دقیقا با هزینه یکسان
و بدون محدودیت داخلی پاسخ داده شوند.

زیرسیستم حافظه دارای ساختار،
مسیرهای موازی،
صف ها
و محدودیت های زمانی است.

به همین دلیل،
Memory Controller باید بین درخواست های فراوان
و منابع محدود حافظه هماهنگی ایجاد کند.


Many Requests

      │
      ▼

┌──────────────────────┐
│ Queues / Scheduling  │
│ Address Routing      │
│ Read / Write Control │
└──────────────────────┘

      │
      ▼

Memory Resources

چرا یک مسیر حافظه کافی نیست؟

GPU برای پردازش موازی طراحی شده است.

اگر تمام درخواست های حافظه
مجبور باشند از یک مسیر واحد عبور کنند،
آن مسیر می تواند به گلوگاه تبدیل شود.


BAD CONCEPTUAL DESIGN

GPU Requests

A ─┐
B ─┤
C ─┼────► ONE MEMORY PATH ────► Memory
D ─┤
E ─┘

              ▲
              │
          Bottleneck

به همین دلیل،
زیرسیستم حافظه GPU
از موازی سازی در چند سطح استفاده می کند.


             GPU

              │

      ┌───────┼───────┐
      │       │       │

      ▼       ▼       ▼

   Path A   Path B   Path C

      │       │       │

      ▼       ▼       ▼

       Memory Resources

Memory Partition چیست؟

در بسیاری از معماری ها،
زیرسیستم حافظه به بخش هایی تقسیم می شود
تا درخواست های بیشتری بتوانند
به صورت موازی پردازش شوند.

برای درک مفهومی،
می توانیم چنین تصویری داشته باشیم:


                 GPU

                  │

                 L2

                  │

      ┌───────────┼───────────┐
      │           │           │

      ▼           ▼           ▼

 Partition 0  Partition 1  Partition 2

      │           │           │

      ▼           ▼           ▼

 Memory       Memory       Memory
 Interface    Interface    Interface

هدف اصلی این تقسیم بندی،
ایجاد امکان استفاده موازی تر
از زیرسیستم حافظه است.

GPU از کجا می داند درخواست باید به کدام مسیر برود؟

آدرس حافظه فقط مشخص نمی کند
«چه داده ای» مورد نیاز است.

بخش هایی از آدرس و سازوکار Mapping
می توانند در تعیین مقصد درخواست
در ساختار حافظه نیز نقش داشته باشند.


Memory Address

      │
      ▼

Address Mapping

  ┌───┼───┐
  │   │   │
  ▼   ▼   ▼

 P0  P1  P2

جزئیات این Mapping
وابسته به معماری است
و نباید یک فرمول ثابت را
به تمام GPUها تعمیم داد.

Engineering Insight — پهنای باند فقط یک عدد روی جعبه نیست

داشتن یک Memory Interface سریع
به تنهایی کافی نیست.

GPU باید بتواند تعداد زیادی درخواست را
به شکلی سازمان دهی کند
که منابع حافظه تا حد امکان
به صورت موثر استفاده شوند.

بنابراین Performance زیرسیستم حافظه
نتیجه تعامل چند بخش است:

  • Cache Hierarchy
  • Memory Controllers
  • Request Scheduling
  • Address Mapping
  • Memory Channels / Partitions
  • Memory Interface
  • نوع و سرعت حافظه
  • الگوی دسترسی خود Workload

خواندن و نوشتن هر دو باید مدیریت شوند

GPU فقط از حافظه نمی خواند.

نتایج پردازش نیز
ممکن است به حافظه نوشته شوند.


READ

Memory
   │
   ▼
  GPU


WRITE

GPU
   │
   ▼
Memory

بنابراین زیرسیستم حافظه
باید جریان Read و Write را
مدیریت و هماهنگ کند.

وقتی حجم درخواست ها بالا باشد،
نحوه مدیریت این ترافیک
می تواند روی بهره وری سیستم اثر بگذارد.

Memory Controller دو مشکل متفاوت دارد

در بحث حافظه،
دو مفهوم را نباید با یکدیگر اشتباه گرفت:

مفهوم سؤال اصلی
Latency رسیدن یک درخواست به نتیجه چقدر طول می کشد؟
Bandwidth در یک بازه زمانی چه مقدار داده می توان منتقل کرد؟

ممکن است یک سیستم
Bandwidth بالایی داشته باشد
اما Latency یک درخواست منفرد
همچنان قابل توجه باشد.

این تفاوت را در فصل های بعدی
دقیق تر بررسی خواهیم کرد.

Performance Impact — وقتی Memory System اشباع می شود

اگر نرخ تولید درخواست های حافظه
از توان موثر زیرسیستم حافظه بیشتر شود،
درخواست ها می توانند منتظر بمانند
و فشار روی صف ها افزایش پیدا کند.


Request Rate

████████████████████████

        │
        ▼

Memory System Capacity

████████████

        │
        ▼

Queues / Waiting

        │
        ▼

Potential Performance Limit

در چنین workloadهایی،
افزایش توان محاسباتی Shaderها
لزوما مشکل را حل نمی کند؛
زیرا گلوگاه در مسیر حافظه قرار دارد.

اینجا مفهوم Memory-Bound کم کم معنا پیدا می کند

فرض کنید Shader Coreها
توان محاسباتی کافی دارند،
اما دائما منتظر داده هستند.


Shader Cores

READY TO COMPUTE

      │

      ▼

Waiting for Data...

      │

      ▼

Memory System

در این حالت،
افزایش تعداد واحدهای محاسباتی
ممکن است سود محدودی داشته باشد.

چون مشکل اصلی
کمبود توان محاسباتی نیست.

Performance می تواند توسط
Memory System محدود شده باشد.

بعدا این مفهوم را
به صورت کامل در بحث
Compute-Bound و Memory-Bound
بررسی خواهیم کرد.

Common Mistakes — اشتباهات رایج
  • Memory Controller را با خود VRAM یکی ندانید.
  • Memory Controller و Memory Bus یک مفهوم نیستند.
  • تعداد Controller بیشتر به تنهایی تضمین کننده Performance بیشتر نیست.
  • Bandwidth بالا به معنی Latency پایین نیست.
  • هر L2 Miss را یک انتقال ساده و مستقیم به VRAM تصور نکنید.
  • جزئیات Mapping و Scheduling یک معماری را به تمام GPUها تعمیم ندهید.

Memory Controller، Memory Bus و VRAM چه تفاوتی دارند؟

بخش نقش مفهومی
Memory Controller مدیریت و سازمان دهی دسترسی به زیرسیستم حافظه
Memory Interface / Bus مسیر انتقال داده میان GPU و حافظه
VRAM محل نگهداری حجم بزرگی از داده های مورد استفاده GPU

پس این سه مفهوم
به هم مرتبط هستند،
اما قابل جایگزینی با یکدیگر نیستند.

حالا تصویر بزرگ تر را ببینیم


              GPU WORK

                 │
                 ▼

        Registers / Local Data

                 │
                 ▼

              L1 Cache

                 │
                 ▼

              L2 Cache

                 │
                 ▼

       Memory Subsystem

                 │
                 ▼

       Memory Controllers

                 │
                 ▼

       Memory Interface

                 │
                 ▼

               VRAM

حالا تقریبا تمام اجزای اصلی
مسیر حافظه را داریم.

اما هنوز یک سؤال بسیار مهم باقی مانده است:

این مسیر در هر ثانیه
چقدر داده می تواند منتقل کند؟

برای پاسخ به این سؤال،
باید وارد بحث
Memory Bus Width
و سپس
Memory Bandwidth
شویم.

سوالات متداول

Memory Controller داخل GPU قرار دارد؟

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

آیا Memory Controller همان Memory Bus است؟

خیر.
Controller دسترسی و جریان درخواست های حافظه را مدیریت می کند،
در حالی که Bus یا Interface به مسیر و پهنای ارتباط داده مربوط است.

آیا Memory Controller سریع تر باعث FPS بیشتر می شود؟

چنین رابطه ساده و مستقیمی وجود ندارد.
عملکرد به کل Memory System،
الگوی دسترسی برنامه،
Cache،
Bandwidth،
Latency
و گلوگاه های دیگر بستگی دارد.

چرا GPU چند مسیر حافظه دارد؟

زیرا حجم درخواست های موازی GPU بسیار زیاد است.
استفاده از منابع و مسیرهای موازی
می تواند امکان سرویس دهی هم زمان تر
به درخواست های حافظه را فراهم کند.

آیا هر درخواست حافظه مستقیما به VRAM می رسد؟

خیر.
بسیاری از درخواست ها می توانند
در Cache Hierarchy پاسخ داده شوند.
فقط درخواست هایی که نیاز به دسترسی به سطح پایین تر دارند
به سمت Memory System ادامه پیدا می کنند.

خلاصه فصل

  • Memory Controller بخشی کلیدی از زیرسیستم حافظه GPU است.
  • درخواست هایی که در Cache پاسخ داده نمی شوند
    باید در مسیر حافظه مدیریت شوند.
  • GPU برای پاسخ به حجم بالای درخواست ها
    از موازی سازی در زیرسیستم حافظه استفاده می کند.
  • Scheduling و Address Mapping
    می توانند بر نحوه استفاده از منابع حافظه اثر بگذارند.
  • Read و Write هر دو نیازمند مدیریت هستند.
  • Latency و Bandwidth دو مفهوم متفاوت اند.
  • Memory Controller،
    Memory Bus
    و VRAM یک مفهوم نیستند.
  • عملکرد حافظه نتیجه تعامل کل Memory System است،
    نه یک مشخصه منفرد.


سطح: متوسط

پیش نیاز:
Memory Hierarchy،
L2 Cache،
Memory Controller

موضوع:
GPU Memory Architecture

زمان مطالعه:
حدود 12 تا 15 دقیقه


GPU MEMORY ARCHITECTURE

Memory Channel در GPU چیست؟

GPU می‌تواند هزاران درخواست حافظه تولید کند.
اگر همه این درخواست‌ها مجبور باشند
از یک مسیر واحد عبور کنند،
آن مسیر خیلی زود به گلوگاه تبدیل می‌شود.

Memory Channel یکی از مفاهیم مهم
برای درک موازی‌سازی مسیر حافظه است.


پاسخ سریع

Memory Channel یک مسیر منطقی یا فیزیکی
در زیرسیستم حافظه است
که امکان انتقال و سرویس‌دهی به بخشی از
درخواست‌های حافظه را فراهم می‌کند.

وجود چند مسیر مستقل یا نیمه‌مستقل
به سیستم حافظه اجازه می‌دهد
درخواست‌های بیشتری را به شکل موازی مدیریت کند.

در این فصل چه چیزهایی یاد می‌گیریم؟

  • Memory Channel چیست.
  • چرا یک مسیر حافظه برای GPU کافی نیست.
  • Channel چگونه به Memory Parallelism کمک می‌کند.
  • تفاوت Memory Channel و Memory Controller چیست.
  • چرا توزیع درخواست‌ها میان Channelها اهمیت دارد.
  • Channel Imbalance چگونه می‌تواند Performance را محدود کند.
  • ارتباط Channel با Memory Interface و Bandwidth چیست.

نقشه مفهومی فصل


01


Memory Requests

GPU تعداد زیادی درخواست حافظه تولید می‌کند.


02


Address Mapping

درخواست‌ها باید به بخش مناسب
از زیرسیستم حافظه هدایت شوند.


03


Memory Channels

چند مسیر امکان سرویس‌دهی موازی‌تر
به درخواست‌ها را فراهم می‌کنند.


04


Memory Devices

داده از حافظه خوانده
یا در آن نوشته می‌شود.

چرا به چند Memory Channel نیاز داریم؟

فرض کنید یک بزرگراه
فقط یک خط عبور داشته باشد.


Car
Car
Car
Car
Car
Car

 │
 ▼

ONE LANE

 │
 ▼

Traffic

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

حالا چند مسیر موازی ایجاد کنیم:


Requests

   │

   ├────────► Channel 0
   │
   ├────────► Channel 1
   │
   ├────────► Channel 2
   │
   └────────► Channel 3

                 │

                 ▼

              Memory

اکنون چند جریان درخواست
می‌توانند هم‌زمان‌تر
از زیرسیستم حافظه استفاده کنند.

Memory Parallelism فقط به تعداد Shader Coreها مربوط نیست؛
خود زیرسیستم حافظه نیز باید بتواند
درخواست‌های موازی را سرویس دهد.

Memory Channel دقیقاً چه مفهومی دارد؟

برای درک معماری،
Memory Channel را می‌توان
به عنوان یکی از مسیرهای ارتباطی
در زیرسیستم حافظه در نظر گرفت.

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


                  GPU

                   │

             Memory System

                   │

        ┌──────────┼──────────┐
        │          │          │
        ▼          ▼          ▼

    Channel 0  Channel 1  Channel 2

        │          │          │
        ▼          ▼          ▼

     Memory      Memory      Memory

ساختار دقیق Channelها،
عرض آنها،
نحوه اتصالشان
و ارتباطشان با Controllerها
به معماری بستگی دارد.

Memory Controller و Memory Channel یکی نیستند

این دو اصطلاح
گاهی با یکدیگر اشتباه گرفته می‌شوند.

تفاوت مفهومی Memory Controller و Memory Channel
مفهوم نقش
Memory Controller مدیریت و سازمان‌دهی درخواست‌های حافظه
Memory Channel یکی از مسیرهای ارتباط و انتقال در زیرسیستم حافظه

یک تشبیه ساده:


Memory Controller
       │
       │ manages / coordinates
       ▼

 ┌─────────────┐
 │  Channel 0  │
 ├─────────────┤
 │  Channel 1  │
 ├─────────────┤
 │  Channel 2  │
 └─────────────┘

البته این نمودار
یک مدل آموزشی است
و نباید آن را شماتیک دقیق
تمام GPUها در نظر گرفت.

Channelها چگونه Parallelism ایجاد می‌کنند؟

فرض کنید چهار درخواست مستقل داریم:


A
B
C
D

اگر همه مجبور باشند
از یک مسیر عبور کنند:


A ─┐
B ─┤
C ─┼────► Channel 0
D ─┘

ظرفیت همان مسیر
می‌تواند محدودکننده شود.

اما اگر درخواست‌ها
میان چند مسیر مناسب توزیع شوند:


A ─────► Channel 0

B ─────► Channel 1

C ─────► Channel 2

D ─────► Channel 3

زیرسیستم حافظه
فرصت بیشتری برای انجام کارهای موازی دارد.

Under the Hood — درخواست چگونه Channel مناسب را پیدا می‌کند؟

سخت‌افزار باید بتواند
آدرس‌های حافظه را به منابع مناسب
در زیرسیستم حافظه نگاشت کند.


Memory Address

      │
      ▼

Address Mapping

      │

 ┌────┼────┬────┐
 │    │    │    │
 ▼    ▼    ▼    ▼

CH0  CH1  CH2  CH3

نحوه دقیق استخراج یا ترکیب بیت‌های آدرس
برای انتخاب Channel یا Partition
یک جزئیات معماری است.

هدف کلی این است که درخواست‌ها
بتوانند به منابع حافظه مناسب هدایت شوند
و زیرسیستم تا حد امکان
از Parallelism موجود استفاده کند.

داشتن چند Channel کافی نیست

فرض کنید چهار Channel داریم.

در حالت مناسب،
درخواست‌ها میان آنها توزیع شده‌اند:


Balanced

CH0  ████████

CH1  ████████

CH2  ████████

CH3  ████████

اما حالا حالتی را تصور کنید
که بیشتر درخواست‌ها
به یک Channel هدایت شوند:


Imbalanced

CH0  ████████████████████████

CH1  ██

CH2  ██

CH3  ██

در این شرایط،
بخشی از منابع حافظه
ممکن است کم‌استفاده بمانند،
در حالی که یک مسیر
تحت فشار زیادی قرار گرفته است.

Performance Impact — Channel Imbalance

Performance حافظه فقط به تعداد Channelها وابسته نیست.

نحوه توزیع واقعی درخواست‌ها
میان منابع حافظه نیز اهمیت دارد.

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

Bandwidth اسمی بالا زمانی مفید است
که Workload بتواند
از منابع حافظه به شکل موثری استفاده کند.

الگوی دسترسی برنامه چرا اهمیت دارد؟

دو برنامه می‌توانند
روی یک GPU یکسان اجرا شوند
اما رفتار کاملاً متفاوتی
در زیرسیستم حافظه داشته باشند.

برنامه اول ممکن است
درخواست‌هایش را به شکلی ایجاد کند
که منابع حافظه به خوبی مورد استفاده قرار گیرند.


Workload A

Requests
 │ │ │ │
 ▼ ▼ ▼ ▼

CH0 CH1 CH2 CH3

در حالی که برنامه دوم
ممکن است الگوی دسترسی نامناسب‌تری داشته باشد.


Workload B

Requests
 │ │ │ │
 └─┴─┴─┴────► CH0

CH1   CH2   CH3
 ↓     ↓     ↓

underused

به همین دلیل،
مشخصات سخت‌افزار
فقط بخشی از داستان Performance هستند.

Memory Channel چه ارتباطی با Memory Interface دارد؟

Memory Interface
تصویر کلی‌تری از ارتباط
میان GPU و حافظه ارائه می‌دهد.

Channelها یا ساختارهای مشابه
می‌توانند بخش‌هایی از این ارتباط موازی را تشکیل دهند.


             GPU

              │

      Memory Interface

              │

    ┌─────────┼─────────┐
    │         │         │
    ▼         ▼         ▼

 Channel   Channel   Channel

    │         │         │
    ▼         ▼         ▼

        Memory Devices

در فصل بعد،
عرض این مسیر ارتباطی را
دقیق‌تر بررسی خواهیم کرد.

Channel و Bus Width را یکی ندانیم

اینجا یکی از اشتباهات رایج
در مشخصات GPU رخ می‌دهد.

Memory Channel
به سازمان‌دهی مسیرهای حافظه مربوط است.

اما Memory Bus Width
به عرض مسیر انتقال داده مربوط می‌شود
و معمولا با واحد bit بیان می‌شود.

مفهوم سؤال اصلی
Memory Channel درخواست‌ها از چه مسیرها یا منابعی می‌توانند عبور کنند؟
Bus Width مسیر داده در مجموع چه عرضی دارد؟
Memory Bandwidth در واحد زمان چه مقدار داده می‌تواند منتقل شود؟

Engineering Insight — Parallelism باید در تمام مسیر ادامه پیدا کند

GPU ممکن است هزاران Thread فعال داشته باشد،
اما Parallelism محاسباتی به تنهایی کافی نیست.

اگر همه آن Threadها برای دریافت داده
به یک منبع محدود وابسته باشند،
بخش حافظه می‌تواند سرعت کل سیستم را محدود کند.


Compute Parallelism
        +
Cache Parallelism
        +
Memory Parallelism
        +
Sufficient Bandwidth

        │
        ▼

Balanced GPU Architecture

طراحی GPU در واقع تلاش برای ایجاد تعادل
میان تمام این بخش‌ها است.

آیا Channel بیشتر همیشه بهتر است؟

نه.

مانند بسیاری از مفاهیم معماری،
افزایش منابع فقط زمانی مفید است
که بخش‌های دیگر سیستم
بتوانند از آنها استفاده کنند.

Channelها و مسیرهای بیشتر
می‌توانند به Parallelism بیشتر کمک کنند،
اما در مقابل
هزینه طراحی،
مساحت سخت‌افزار،
پیچیدگی Routing
و محدودیت‌های دیگر نیز وجود دارند.

علاوه بر این،
Workload باید بتواند
درخواست کافی و مناسبی ایجاد کند
تا این منابع مورد استفاده قرار گیرند.

Common Mistakes — اشتباهات رایج درباره Memory Channel
  • Memory Channel را با Memory Controller یکی ندانید.
  • Channel را با Bus Width یکی ندانید.
  • تعداد مسیر بیشتر را به تنهایی معادل Performance بیشتر در نظر نگیرید.
  • فرض نکنید درخواست‌ها همیشه به طور کاملا مساوی میان Channelها توزیع می‌شوند.
  • مشخصات یک معماری را به همه GPUها تعمیم ندهید.
  • Bandwidth اسمی را با Bandwidth موثر Workload یکی ندانید.

حالا مسیر حافظه کامل‌تر شده است


Shader / Compute Units

          │

          ▼

       L1 Cache

          │

          ▼

       L2 Cache

          │

          ▼

   Memory Controllers

          │

          ▼

    Memory Channels

          │

          ▼

   Memory Interface

          │

          ▼

         VRAM

حالا می‌دانیم
چرا زیرسیستم حافظه
به چند مسیر موازی نیاز دارد.

اما هنوز یک سؤال مهم باقی مانده است:

هر بار که داده روی این مسیرها منتقل می‌شود،
عرض مسیر چقدر است؟

اینجا دقیقا به مفهوم
Memory Bus Width
می‌رسیم.

سؤالات متداول

Memory Channel چیست؟

یکی از مسیرهای موجود در زیرسیستم حافظه
برای ارتباط و انتقال داده است
که به ایجاد Parallelism در دسترسی حافظه کمک می‌کند.

آیا Memory Channel همان Memory Controller است؟

خیر.
Controller در مدیریت درخواست‌های حافظه نقش دارد،
در حالی که Channel به مسیر ارتباط و انتقال داده مربوط است.

آیا Channel بیشتر همیشه GPU را سریع‌تر می‌کند؟

خیر.
Performance به کل معماری،
عرض و سرعت حافظه،
Cache،
الگوی دسترسی Workload
و توان استفاده مؤثر از منابع حافظه بستگی دارد.

Channel Imbalance چیست؟

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

آیا برنامه‌نویس مستقیماً Memory Channel را انتخاب می‌کند؟

در مدل معمول برنامه‌نویسی GPU،
انتخاب فیزیکی Channel مستقیماً توسط Shader تعیین نمی‌شود.
Address Mapping و معماری زیرسیستم حافظه
در هدایت درخواست‌ها نقش دارند.

تفاوت Channel و Memory Bandwidth چیست؟

Channel بخشی از سازمان‌دهی مسیرهای حافظه است،
اما Bandwidth میزان داده‌ای را بیان می‌کند
که سیستم می‌تواند در واحد زمان منتقل کند.

خلاصه فصل

  • Memory Channel یکی از مسیرهای زیرسیستم حافظه است.
  • چند Channel امکان Parallelism بیشتر در دسترسی حافظه را فراهم می‌کنند.
  • Memory Controller و Memory Channel دو مفهوم متفاوت هستند.
  • Address Mapping در هدایت درخواست‌ها به منابع حافظه نقش دارد.
  • توزیع نامتوازن درخواست‌ها می‌تواند باعث Channel Imbalance شود.
  • Channel بیشتر به تنهایی تضمین‌کننده Performance بالاتر نیست.
  • Channel، Bus Width و Bandwidth باید از یکدیگر تفکیک شوند.
  • عملکرد واقعی نتیجه تعامل Workload با کل Memory System است.


سطح: متوسط

پیش نیاز:
Memory Controller،
Memory Channel،
Memory Interface

موضوع:
GPU Memory Architecture

زمان مطالعه:
حدود 15 تا 18 دقیقه


GPU MEMORY ARCHITECTURE

Memory Bus Width در GPU چیست؟ معنی 64-bit تا 384-bit

وقتی در مشخصات کارت گرافیک عبارتی مانند
128-bit، 256-bit یا 384-bit می بینیم،
این عدد دقیقا چه چیزی را اندازه می گیرد؟

Bus Width یکی از اجزای مهم زیرسیستم حافظه است،
اما بدون در نظر گرفتن سرعت حافظه،
Cache و معماری GPU نمی توان از روی آن
درباره Performance قضاوت کرد.


پاسخ سریع: Memory Bus Width چیست؟

Memory Bus Width عرض رابط انتقال داده میان GPU
و حافظه گرافیکی را بیان می کند و معمولا با واحد
bit
نمایش داده می شود.

Bus عریض تر می تواند در هر انتقال همزمان
بیت های بیشتری جابه جا کند،
اما پهنای باند نهایی فقط به Bus Width وابسته نیست
و سرعت انتقال حافظه نیز نقش مستقیم دارد.

در این فصل چه چیزهایی یاد می گیریم؟

  • Memory Bus Width دقیقا چه چیزی را بیان می کند.
  • معنی اعداد 64-bit تا 384-bit چیست.
  • چرا Bus Width را باید از ظرفیت VRAM جدا دانست.
  • Bus Width چه ارتباطی با Memory Channel و Interface دارد.
  • چرا Bus عریض تر لزوما GPU سریع تر ایجاد نمی کند.
  • Bus Width چگونه در محاسبه Memory Bandwidth وارد می شود.
  • چرا Cache بزرگ تر می تواند نیاز به ترافیک خارجی را کاهش دهد.
  • چگونه مشخصات حافظه را به شکل مهندسی مقایسه کنیم.

نقشه مفهومی فصل


01


Memory Data Rate

مشخص می کند هر خط داده با چه نرخ موثری
اطلاعات منتقل می کند.


02


Bus Width

مشخص می کند چند بیت داده
در رابط حافظه به صورت موازی وجود دارند.


03


Theoretical Bandwidth

سرعت حافظه و عرض Bus
با هم ظرفیت نظری انتقال را تعیین می کنند.


04


Effective Performance

Cache، Compression، Locality و Workload
تعیین می کنند چه مقدار از این ظرفیت
واقعا مفید باشد.

چرا عرض مسیر انتقال اهمیت دارد؟

دو جاده را تصور کنید.

هر دو خودروها را با سرعت یکسان حرکت می دهند،
اما جاده دوم تعداد خط عبور بیشتری دارد.


Narrow Path

[ Data ]
    │
    ▼
────────────


Wider Path

[ Data ][ Data ][ Data ][ Data ]
    │       │       │       │
    ▼       ▼       ▼       ▼
──────────────────────────────

اگر سایر شرایط یکسان باشند،
مسیر عریض تر می تواند
در یک بازه زمانی
داده بیشتری عبور دهد.

Memory Bus نیز
از همین ایده استفاده می کند.

256-bit دقیقا یعنی چه؟

عدد
256-bit
به ظرفیت VRAM اشاره نمی کند.

این عدد عرض کلی مسیر داده
در رابط حافظه را بیان می کند.


Conceptual Memory Interface

GPU

 │
 │  256 data bits wide
 ▼

════════════════════════════════

 │
 ▼

VRAM

از دید مفهومی،
یک رابط 256-bit
تعداد بیشتری خط داده موازی
نسبت به رابط 128-bit دارد.

مقایسه مفهومی Busهای مختلف

مقایسه ساده Memory Bus Width
Bus Width عرض نسبی رابط برداشت درست
64-bit باریک تر تعداد خطوط داده کمتر
128-bit متوسط دو برابر عرض 64-bit
192-bit عریض تر 50 درصد عریض تر از 128-bit
256-bit عریض دو برابر عرض 128-bit
384-bit بسیار عریض سه برابر عرض 128-bit

اما این جدول فقط
عرض
را مقایسه می کند.

هنوز چیزی درباره
سرعت حافظه نگفته ایم.

عرض Bus تنها نصف داستان است

فرض کنید دو سیستم حافظه داریم.


System A

Wide Bus
+
Lower Data Rate


System B

Narrower Bus
+
Higher Data Rate

فقط با مشاهده Bus Width
نمی توان نتیجه گرفت
کدام سیستم پهنای باند بیشتری دارد.

برای پاسخ،
باید هر دو عامل را بدانیم:

  • عرض Bus
  • Data Rate حافظه

Bus Width چگونه وارد فرمول Bandwidth می شود؟

برای حافظه هایی که نرخ انتقال آنها
به صورت
Gbps per pin
بیان می شود،
فرمول مفهومی رایج چنین است:


Memory Bandwidth

=

Data Rate × Bus Width
─────────────────────
         8

تقسیم بر 8
برای تبدیل bit به byte انجام می شود.

مثلا اگر:


Data Rate = 18 Gbps

Bus Width = 256 bit

خواهیم داشت:


18 × 256
────────
   8

=

576 GB/s

این مقدار
پهنای باند نظری
رابط حافظه است.

در فصل بعد،
این فرمول را کامل تر بررسی خواهیم کرد.

Under the Hood — Bus Width از کجا ساخته می شود؟

رابط حافظه در GPU
معمولا یک مسیر غول پیکر و یکپارچه
به معنای ساده نیست.

در طراحی واقعی،
رابط حافظه می تواند
از چند بخش یا مسیر تشکیل شود
که در مجموع
عرض کلی Interface را ایجاد می کنند.


Conceptual Example

Memory Path A  ───┐
Memory Path B  ───┤
Memory Path C  ───┼──► Aggregate Interface Width
Memory Path D  ───┘

جزئیات دقیق تقسیم بندی،
عرض هر بخش
و اتصال آن به تراشه های حافظه
به معماری و نوع حافظه وابسته است.

به همین دلیل،
Bus Width را بهتر است
به عنوان
عرض کلی رابط داده حافظه
در نظر بگیریم.

Bus Width و ظرفیت VRAM دو مفهوم جدا هستند

یکی از اشتباهات رایج این است
که تصور کنیم VRAM بیشتر
یعنی Bus عریض تر.

این رابطه الزامی نیست.

مشخصه چه چیزی را بیان می کند؟ واحد
VRAM Capacity چه مقدار داده می تواند در حافظه نگهداری شود GB
Memory Bus Width عرض مسیر انتقال داده حافظه bit
Memory Bandwidth چه مقدار داده در واحد زمان قابل انتقال است GB/s

ظرفیت می گوید «چقدر داده جا می شود».

Bus Width بخشی از پاسخ به این سوال است که
«داده با چه ظرفیتی می تواند جابه جا شود».

پس چرا همه GPUها 384-bit یا بیشتر نیستند؟

اگر Bus عریض تر
می تواند به Bandwidth بیشتر کمک کند،
چرا همیشه رابط بسیار عریض نمی سازیم؟

چون Bus Width رایگان نیست.

یک رابط حافظه عریض تر
می تواند بر مواردی مانند اینها اثر بگذارد:

  • تعداد خطوط سیگنال
  • پیچیدگی طراحی تراشه
  • مساحت بخش های رابط حافظه
  • طراحی PCB
  • چیدمان تراشه های حافظه
  • مصرف توان
  • هزینه ساخت

بنابراین معمار GPU
باید میان Bandwidth مورد نیاز
و هزینه پیاده سازی آن تعادل ایجاد کند.

Engineering Insight — Cache می تواند معادله Bus Width را تغییر دهد

اگر GPU بتواند بخش بیشتری از داده مورد نیاز
را داخل Cache نگه دارد،
تعداد درخواست هایی که باید
از رابط خارجی حافظه عبور کنند کاهش پیدا می کند.


More Useful Cache Hits

        │

        ▼

Less External Memory Traffic

        │

        ▼

Lower Pressure on Memory Interface

به همین دلیل،
مقایسه Bus Width میان دو معماری
بدون در نظر گرفتن Cache Hierarchy
می تواند گمراه کننده باشد.

معماری جدیدتر ممکن است
با Bus باریک تر
از داده های موجود در Cache
موثرتر استفاده کند.

چرا مقایسه نسل ها فقط با Bus Width اشتباه است؟

فرض کنید GPU قدیمی
یک Bus عریض تر داشته باشد
و GPU جدید Bus باریک تری.

از این مشخصه به تنهایی
نمی توان نتیجه گرفت
GPU قدیمی Memory System بهتری دارد.

GPU جدید ممکن است:

  • حافظه سریع تری داشته باشد.
  • Cache بزرگ تر یا موثرتر داشته باشد.
  • Compression بهتری داشته باشد.
  • Locality را بهتر استفاده کند.
  • Memory Controller متفاوتی داشته باشد.
  • Workload را با ترافیک حافظه کمتری اجرا کند.

Theoretical Bandwidth با Performance واقعی یکی نیست

فرمول Bus Width و Data Rate
یک عدد نظری تولید می کند.

این عدد بسیار مفید است،
اما به این معنی نیست
که هر برنامه همیشه همان نرخ انتقال
را تجربه خواهد کرد.


Theoretical Bandwidth

        │

        ▼

Hardware Maximum Model

        │

        ▼

Real Workload

   ┌────┼────┐
   │    │    │
   ▼    ▼    ▼

Cache  Access  Scheduling
Hits   Pattern Overheads

        │

        ▼

Effective Behavior

Performance Impact — چه زمانی Bus Width اهمیت بیشتری پیدا می کند؟

Bus Width زمانی اهمیت بیشتری پیدا می کند
که Workload حجم زیادی از داده را
از حافظه خارجی جابه جا کند
و Cache نتواند بخش بزرگی از این ترافیک را جذب کند.

نمونه های مفهومی می توانند شامل
workloadهای دارای داده حجیم،
دسترسی های کم Reuse
یا فشار زیاد روی Memory Bandwidth باشند.

در مقابل،
اگر Workload بیشتر Compute-Bound باشد
یا Cache Hit بالایی داشته باشد،
افزایش Bandwidth حافظه
ممکن است تاثیر محدودتری ایجاد کند.

یک مثال: Bus عریض تر همیشه برنده نیست

دو سیستم فرضی را مقایسه کنیم.

ویژگی System A System B
Bus Width 256-bit 192-bit
Data Rate 14 Gbps 21 Gbps
Theoretical Bandwidth 448 GB/s 504 GB/s

System B
با وجود Bus باریک تر،
به دلیل Data Rate بالاتر
پهنای باند نظری بیشتری دارد.

هیچ وقت Bus Width را
جدا از سرعت حافظه مقایسه نکنید.

اگر خریدار کارت گرافیک هستیم، Bus Width را چگونه بخوانیم؟

Bus Width مشخصه بی اهمیتی نیست،
اما نباید آن را تبدیل به معیار نهایی خرید کنیم.

برای مقایسه Memory System
حداقل این موارد را کنار هم ببینید:

Bus Width

عرض رابط حافظه.

Memory Data Rate

نرخ موثر انتقال حافظه.

Bandwidth

ظرفیت نظری انتقال داده.

Cache Architecture

میزان کاهش نیاز به حافظه خارجی.

VRAM Capacity

مقدار حافظه قابل استفاده.

Real Workload

رفتار واقعی نرم افزار یا بازی.

Common Mistakes — اشتباهات رایج درباره Memory Bus
  • 256-bit را به معنی 256 GB حافظه یا ظرفیت VRAM ندانید.
  • Bus عریض تر را به تنهایی معادل GPU سریع تر ندانید.
  • Bus Width را بدون Data Rate مقایسه نکنید.
  • VRAM Capacity و Memory Bandwidth را یکی ندانید.
  • پهنای باند نظری را معادل Performance واقعی ندانید.
  • GPUهای نسل های متفاوت را فقط بر اساس Bus Width رتبه بندی نکنید.
  • تاثیر Cache و Compression را در تحلیل Memory System نادیده نگیرید.

جای Bus Width در کل Memory System


Shader / Compute Units

          │
          ▼

       L1 Cache

          │
          ▼

       L2 Cache

          │
          ▼

   Memory Controller

          │
          ▼

   Memory Channels

          │
          ▼

┌─────────────────────────┐
│   MEMORY INTERFACE      │
│                        │
│   Bus Width = N bits   │
└─────────────────────────┘

          │
          ▼

         VRAM

سوالات متداول درباره Memory Bus Width

Bus Width کارت گرافیک چیست؟

عرض رابط داده میان GPU و حافظه گرافیکی است
و معمولا با واحد bit بیان می شود.

آیا 256-bit همیشه از 128-bit سریع تر است؟

خیر.
سرعت حافظه، معماری Cache،
Compression و Workload نیز اهمیت دارند.
برای مقایسه بهتر باید حداقل Memory Bandwidth
و معماری کلی را نیز بررسی کرد.

آیا VRAM بیشتر یعنی Bus Width بیشتر؟

خیر.
ظرفیت حافظه و عرض رابط
دو مشخصه متفاوت هستند.

چرا بعضی GPUهای جدید Bus باریک تری دارند؟

طراحی Memory System فقط به Bus Width وابسته نیست.
حافظه سریع تر، Cache متفاوت،
Compression و تغییرات معماری
می توانند نیاز طراحی را تغییر دهند.

آیا Bus Width همان Memory Bandwidth است؟

خیر.
Bus Width فقط یکی از ورودی های محاسبه Bandwidth است.
Data Rate حافظه نیز باید در نظر گرفته شود.

برای خرید کارت گرافیک Bus Width مهم تر است یا VRAM؟

این دو مشخصه وظایف متفاوتی دارند
و هیچ کدام به تنهایی معیار مناسبی برای انتخاب GPU نیستند.
ظرفیت VRAM، Bandwidth، معماری GPU
و Performance واقعی workload باید در کنار هم بررسی شوند.

خلاصه فصل

  • Memory Bus Width عرض رابط داده حافظه را با واحد bit بیان می کند.
  • Bus عریض تر می تواند بیت های بیشتری را به صورت موازی منتقل کند.
  • Bus Width و VRAM Capacity دو مشخصه کاملا متفاوت هستند.
  • Bandwidth به Bus Width و Data Rate حافظه وابسته است.
  • 256-bit لزوما از یک طراحی 192-bit سریع تر نیست.
  • Cache می تواند میزان نیاز به انتقال داده روی Bus خارجی را کاهش دهد.
  • رابط عریض تر هزینه و پیچیدگی سخت افزاری بیشتری دارد.
  • پهنای باند نظری با Performance واقعی workload یکسان نیست.
  • Memory System باید به صورت یک مجموعه کامل تحلیل شود.

ارتباط با فصل های دیگر

سطح: متوسط

پیش نیاز:
Memory Controller،
Memory Channel،
Memory Bus Width

موضوع:
GPU Memory Architecture

زمان مطالعه:
حدود 18 تا 22 دقیقه


GPU MEMORY ARCHITECTURE

Memory Bandwidth در GPU چیست؟ از Bus Width تا GB/s

وقتی در مشخصات کارت گرافیک عددی مانند
300 GB/s، 500 GB/s یا بیشتر می بینیم،
این عدد دقیقا چه چیزی را بیان می کند؟

Memory Bandwidth ظرفیت انتقال داده
در زیرسیستم حافظه را توصیف می کند،
اما برای فهم درست آن باید بین
Clock، Data Rate، Bus Width
و Bandwidth تفاوت قائل شویم.


پاسخ سریع: Memory Bandwidth چیست؟

Memory Bandwidth مقدار داده ای است
که رابط حافظه از نظر نظری
می تواند در یک بازه زمانی منتقل کند
و معمولا با واحد
GB/s
بیان می شود.

در حافظه هایی که Data Rate آنها
با Gbps per pin مشخص می شود،
Bandwidth نظری از ترکیب
Data Rate و Memory Bus Width
به دست می آید.

در این فصل چه چیزهایی یاد می گیریم؟

  • Memory Bandwidth چیست.
  • تفاوت Clock، Data Rate و Bandwidth چیست.
  • GB/s و Gbps چه تفاوتی دارند.
  • فرمول محاسبه پهنای باند نظری حافظه چیست.
  • چرا در فرمول بر عدد 8 تقسیم می کنیم.
  • چگونه دو Memory System را به شکل درست مقایسه کنیم.
  • تفاوت Theoretical Bandwidth و Effective Bandwidth چیست.
  • Cache و Compression چگونه فشار روی Memory Bandwidth را کاهش می دهند.
  • چه زمانی GPU به اصطلاح Memory-Bound می شود.

نقشه مفهومی فصل


01


Memory Data Rate

نرخ انتقال موثر هر خط داده حافظه.


02


Bus Width

تعداد بیت هایی که
رابط حافظه به صورت موازی حمل می کند.


03


Theoretical Bandwidth

ظرفیت نظری انتقال داده
در رابط حافظه.


04


Effective Memory Behavior

رفتار واقعی تحت تاثیر
Cache، Compression،
Access Pattern و Workload.

چرا فقط دانستن Bus Width کافی نبود؟

در فصل قبل دیدیم
که Bus Width
عرض مسیر انتقال داده را مشخص می کند.

اما فرض کنید دو بزرگراه داریم:


Road A

4 Lanes
60 km/h


Road B

3 Lanes
120 km/h

جاده A عریض تر است،
اما خودروها در جاده B سریع تر حرکت می کنند.

بنابراین فقط با دانستن
تعداد Laneها
نمی توان ظرفیت انتقال را مقایسه کرد.

در حافظه GPU نیز همین اتفاق رخ می دهد:


Bus Width

      +

Memory Data Rate

      │
      ▼

Memory Bandwidth

Memory Bandwidth دقیقا چه چیزی را اندازه می گیرد؟

Memory Bandwidth
ظرفیت انتقال داده
در مسیر حافظه را
در واحد زمان بیان می کند.

واحد رایج آن:


GB/s

Gigabytes per Second

مثلا:


500 GB/s

به این معنا است
که رابط حافظه از نظر نظری
ظرفیت انتقال صدها گیگابایت داده
در هر ثانیه را دارد.

این عدد
ظرفیت نظری مسیر
را بیان می کند،
نه تضمین عملکرد واقعی یک برنامه.

Gbps و GB/s را با هم اشتباه نکنیم

یکی از رایج ترین اشتباهات
در مشخصات حافظه
مخلوط کردن
Gbps
و
GB/s
است.

واحد معنی بر پایه
Gbps Gigabits per second bit
GB/s Gigabytes per second byte

هر Byte شامل 8 bit است.


1 Byte = 8 bits

به همین دلیل
در فرمول Bandwidth
باید تبدیل bit به byte انجام شود.

فرمول Memory Bandwidth

برای حافظه هایی که
Data Rate آنها با
Gbps per pin
بیان می شود،
فرمول رایج چنین است:


Bandwidth (GB/s)

=

Data Rate (Gbps) × Bus Width (bit)
──────────────────────────────────
                 8

سه مرحله داریم:

  1. Data Rate حافظه را پیدا می کنیم.
  2. آن را در Bus Width ضرب می کنیم.
  3. نتیجه را برای تبدیل bit به byte
    بر 8 تقسیم می کنیم.

مثال اول: حافظه 18 Gbps با Bus 256-bit

فرض کنیم یک Memory System
مشخصات زیر را دارد:


Data Rate

18 Gbps


Bus Width

256 bit

ابتدا ضرب می کنیم:


18 × 256

=

4608

حالا بر 8 تقسیم می کنیم:


4608 ÷ 8

=

576 GB/s

پس پهنای باند نظری این سیستم:


576 GB/s

مثال دوم: Bus باریک تر، حافظه سریع تر

حالا سیستم دیگری را فرض کنیم:


Data Rate

21 Gbps


Bus Width

192 bit

محاسبه:


21 × 192
────────
   8

=

504 GB/s

در این مثال
Bus باریک تر است،
اما Data Rate بالاتر
بخش زیادی از اختلاف را جبران کرده است.

مقایسه دو سیستم حافظه

دو Memory System فرضی
مشخصه System A System B
Bus Width 256-bit 192-bit
Data Rate 14 Gbps 21 Gbps
Bandwidth 448 GB/s 504 GB/s

این مثال
یک نکته مهم را ثابت می کند:

Bus Width بزرگ تر
به تنهایی به معنی
Memory Bandwidth بیشتر نیست.

Memory Clock و Data Rate یکی نیستند

یکی از بخش هایی که
در مشخصات کارت گرافیک
بسیار ایجاد سردرگمی می کند،
عبارت Memory Clock است.

فرکانس داخلی حافظه
و نرخ موثر انتقال داده
الزاما یک عدد نیستند.


Physical / Internal Clock

        │

        ▼

Transfer Encoding
and Signaling

        │

        ▼

Effective Data Rate

به همین دلیل
هنگام محاسبه Bandwidth
نباید بدون بررسی واحد
یک عدد MHz یا GHz را
مستقیما در فرمول قرار دهیم.

باید مشخص باشد
عدد ارائه شده:

  • Clock واقعی است،
  • Clock موثر است،
  • یا Data Rate با واحد Gbps.

Under the Hood — چرا Memory Bandwidth فقط حاصل سرعت حافظه نیست؟

هر خط داده حافظه
ظرفیت مشخصی برای انتقال اطلاعات دارد.

وقتی تعداد زیادی از این خطوط
در کنار یکدیگر قرار می گیرند،
Bus Width شکل می گیرد.


One Data Line

   │
   ▼

Data Rate


Many Data Lines

│ │ │ │ │ │ │ │

      │

      ▼

Aggregate Bus Width

      │

      ▼

Total Theoretical Bandwidth

پس Bandwidth
محصول دو نوع Parallelism است:

  • سرعت انتقال روی هر خط،
  • تعداد خطوط داده موازی.

Theoretical Bandwidth و Effective Bandwidth

عدد حاصل از فرمول
یک سقف نظری است.

اما Workload واقعی
الزاما نمی تواند
در تمام لحظات از کل این ظرفیت استفاده کند.


Theoretical Bandwidth

        │

        ▼

Maximum Interface Capacity

        │

        ▼

Real Execution

 ┌──────┼────────┬──────────┐
 │      │        │          │
 ▼      ▼        ▼          ▼

Cache  Access   Queue     Protocol /
Hits   Pattern  Behavior  System Effects

        │

        ▼

Effective Useful Traffic

بنابراین:

Theoretical Bandwidth
یک مشخصه سخت افزاری مهم است،
اما Benchmark واقعی
رفتار کل Memory System را نشان می دهد.

Cache چگونه نیاز به Bandwidth خارجی را کاهش می دهد؟

فرض کنید یک Shader
ده بار به یک داده نیاز دارد.

بدون Cache موثر:


Request
Request
Request
Request
Request

   │
   ▼

External Memory Traffic

اما اگر داده
پس از اولین دسترسی
در Cache قابل استفاده باشد:


First Request
     │
     ▼
External Memory

     │
     ▼

Cache

 ├── Reuse
 ├── Reuse
 ├── Reuse
 └── Reuse

در نتیجه
داده کمتری باید
از رابط خارجی حافظه عبور کند.

Engineering Insight — Effective Bandwidth فقط یک مشخصه سخت افزاری نیست

دو GPU با Bandwidth نظری مشابه
می توانند در Workload واقعی
رفتار متفاوتی داشته باشند.

دلیل آن می تواند شامل
Cache Hierarchy،
Data Compression،
Memory Scheduling،
Access Pattern
و نوع Workload باشد.

به همین دلیل،
یک مهندس فقط عدد GB/s را نگاه نمی کند.

سوال اصلی این است:

Workload برای انجام همان کار
واقعا چقدر ترافیک حافظه تولید می کند؟

Compression چه نقشی دارد؟

اگر داده بتواند
با حجم کمتری
در مسیر حافظه منتقل شود،
فشار روی Bandwidth کاهش پیدا می کند.


Without Compression

████████████████████


With Compression

██████████

در Graphics Pipeline
روش های مختلفی برای کاهش ترافیک حافظه
می توانند وجود داشته باشند.

جزئیات این روش ها
وابسته به معماری و نوع داده است،
اما اصل مهندسی ثابت می ماند:

هر Byte که لازم نباشد
از حافظه خارجی منتقل شود،
فشار کمتری روی Memory Interface ایجاد می کند.

Memory-Bound یعنی چه؟

فرض کنید GPU
توان محاسباتی زیادی دارد.

اما واحدهای محاسباتی
مدام منتظر داده هستند.


Compute Units

████████████████████

Ready


Memory Supply

██████

Too Slow / Insufficient

        │

        ▼

Compute Units Wait

در این حالت،
Performance ممکن است
به جای Compute Throughput
توسط Memory System محدود شود.

به چنین Workloadی
به صورت مفهومی
Memory-Bound
گفته می شود.

Performance Impact — افزایش Bandwidth چه زمانی واقعا مفید است؟

افزایش Memory Bandwidth
بیشترین تاثیر را زمانی دارد
که Workload واقعا توسط
انتقال داده حافظه محدود شده باشد.

اگر یک برنامه Compute-Bound باشد،
افزایش Bandwidth ممکن است
تغییر محدودی ایجاد کند.

در مقابل،
Workloadهایی با ترافیک حافظه زیاد،
Reuse کم
یا Working Set بزرگ
می توانند حساسیت بیشتری
به Bandwidth داشته باشند.

بنابراین قبل از نتیجه گیری
باید Bottleneck واقعی
اندازه گیری شود.

Bandwidth بالا همه مشکلات حافظه را حل نمی کند

یک Memory System
می تواند پهنای باند زیادی داشته باشد
اما هنوز با مشکلات دیگری روبه رو شود.

مشکل آیا Bandwidth بیشتر حتما حلش می کند؟
Latency بالا خیر
Random Access لزوما خیر
Cache Miss زیاد فقط بخشی از هزینه را می تواند کاهش دهد
Poor Locality خیر
Compute Bottleneck معمولا خیر

Bandwidth و Latency دو سوال متفاوت هستند

مفهوم سوال مثال ذهنی
Bandwidth در هر ثانیه چقدر داده منتقل می شود؟ عرض بزرگراه
Latency رسیدن یک درخواست چقدر طول می کشد؟ زمان سفر یک خودرو

یک بزرگراه می تواند
بسیار عریض باشد،
اما سفر از ابتدا تا انتهای آن
هنوز زمان ببرد.

به همین شکل،
Bandwidth بالا
به معنی Latency بسیار پایین نیست.

چطور مشخصات حافظه یک GPU را بخوانیم؟

وقتی مشخصات Memory System را می بینید،
اعداد را جدا از هم تحلیل نکنید.

VRAM Capacity

چه مقدار داده در حافظه جا می شود؟

Bus Width

رابط داده چقدر عریض است؟

Data Rate

هر خط داده با چه نرخ موثری کار می کند؟

Bandwidth

ظرفیت نظری انتقال کل سیستم چقدر است؟

Cache

چه مقدار ترافیک را می توان قبل از VRAM پاسخ داد؟

Workload

برنامه واقعا چه الگویی از حافظه ایجاد می کند؟

Common Mistakes — اشتباهات رایج درباره Memory Bandwidth
  • Gbps را با GB/s اشتباه نگیرید.
  • Memory Clock را بدون بررسی واحد
    به عنوان Data Rate وارد فرمول نکنید.
  • Bus Width بیشتر را به تنهایی
    معادل Bandwidth بیشتر ندانید.
  • Bandwidth نظری را معادل Performance واقعی فرض نکنید.
  • Bandwidth بیشتر را راه حل تمام مشکلات Memory System ندانید.
  • نقش Cache و Compression را نادیده نگیرید.
  • Bandwidth و Latency را یکی ندانید.
  • یک GPU را فقط بر اساس عدد GB/s رتبه بندی نکنید.

فرمول را یک بار دیگر جمع بندی کنیم


Data Rate
  Gbps

   ×

Bus Width
   bit

   ÷

    8

   =

Bandwidth
  GB/s

مثال:


20 Gbps × 320 bit
─────────────────
        8

=

800 GB/s

این مقدار
پهنای باند نظری است.

سوالات متداول درباره Memory Bandwidth

Memory Bandwidth چیست؟

ظرفیت نظری انتقال داده
میان GPU و حافظه در واحد زمان است
و معمولا با GB/s بیان می شود.

فرمول Memory Bandwidth چیست؟

اگر Data Rate با Gbps per pin بیان شده باشد،
می توان Data Rate را در Bus Width ضرب کرد
و نتیجه را برای تبدیل bit به byte
بر 8 تقسیم کرد.

آیا Bandwidth بیشتر همیشه FPS بیشتری ایجاد می کند؟

خیر.
افزایش Bandwidth زمانی بیشترین تاثیر را دارد
که Workload واقعا توسط Memory System محدود شده باشد.
اگر گلوگاه Compute یا بخش دیگری باشد،
تاثیر می تواند محدود باشد.

تفاوت Gbps و GB/s چیست؟

Gbps بر پایه bit
و GB/s بر پایه byte است.
هر Byte برابر 8 bit است.

آیا Bus Width بیشتر همیشه Bandwidth بیشتری می دهد؟

خیر.
Data Rate حافظه نیز در Bandwidth نقش مستقیم دارد.
یک رابط باریک تر با حافظه سریع تر
می تواند Bandwidth بیشتری
از رابط عریض تر با حافظه کندتر داشته باشد.

چرا Bandwidth واقعی کمتر از عدد نظری است؟

عدد نظری ظرفیت Interface را بیان می کند.
Workload واقعی تحت تاثیر
Access Pattern،
Cache،
Scheduling،
Latency
و سایر رفتارهای Memory System قرار دارد.

Bandwidth با VRAM Capacity چه تفاوتی دارد؟

VRAM Capacity مشخص می کند
چه مقدار داده در حافظه جا می شود،
در حالی که Bandwidth مشخص می کند
داده با چه نرخ نظری می تواند منتقل شود.

خلاصه فصل

Memory Bandwidth را نباید فقط یک عدد
در جدول مشخصات در نظر گرفت.

این عدد حاصل تعامل
سرعت انتقال هر خط حافظه
و عرض رابط داده است.

اما Performance واقعی
به این بستگی دارد که Workload
اصلا چه مقدار ترافیک تولید کند،
چه مقدار از داده در Cache پاسخ داده شود
و Bottleneck واقعی سیستم کجا قرار داشته باشد.

  • Bandwidth معمولا با GB/s بیان می شود.
  • Data Rate و Bus Width دو ورودی اصلی Bandwidth نظری هستند.
  • تقسیم بر 8 برای تبدیل bit به byte انجام می شود.
  • Gbps و GB/s دو واحد متفاوت هستند.
  • Clock و Data Rate را نباید بدون بررسی واحد یکی دانست.
  • Bandwidth نظری سقف مدل شده رابط حافظه است.
  • Cache و Compression می توانند ترافیک خارجی را کاهش دهند.
  • Bandwidth بالا Latency پایین را تضمین نمی کند.
  • افزایش Bandwidth زمانی ارزشمندتر است که Workload Memory-Bound باشد.

ارتباط با فصل های دیگر

سطح: متوسط

پیش نیاز:
Memory Hierarchy،
L1 Cache،
L2 Cache،
Memory Bandwidth

موضوع:
GPU Memory Architecture

زمان مطالعه:
حدود 18 تا 22 دقیقه


GPU MEMORY ARCHITECTURE

Memory Latency در GPU چیست؟ چرا داده همیشه فوری نمی رسد؟

Memory Bandwidth می گوید
در هر ثانیه چه مقدار داده می توان جابه جا کرد.

اما Latency سوال دیگری می پرسد:

از لحظه ارسال یک درخواست حافظه
تا زمانی که داده آماده استفاده شود،
چقدر زمان می گذرد؟


پاسخ سریع: Memory Latency چیست؟

Memory Latency مدت زمانی است
که بین صدور یک درخواست حافظه
و در دسترس قرار گرفتن نتیجه آن سپری می شود.

هرچه داده در سطح نزدیک تری از Memory Hierarchy باشد،
معمولا Latency کمتر است.
دسترسی به Register و Cacheهای نزدیک بسیار سریع تر
از مراجعه به حافظه اصلی است.

در این فصل چه چیزهایی یاد می گیریم؟

  • Memory Latency چیست.
  • چرا Latency با Bandwidth متفاوت است.
  • چرا سطوح مختلف Memory Hierarchy
    Latency متفاوتی دارند.
  • چرا یک Load منفرد می تواند مدت قابل توجهی منتظر بماند.
  • GPU چگونه Latency را پنهان می کند.
  • Warp Scheduling چه نقشی در Latency Hiding دارد.
  • Outstanding Memory Requests چه کمکی می کنند.
  • Memory-Level Parallelism چیست.
  • چرا Occupancy بالا همیشه به معنی Latency Hiding بهتر نیست.

نقشه مفهومی فصل


01


Memory Request

Thread یا Warp داده ای را درخواست می کند.


02


Memory Hierarchy

درخواست در سطوح مختلف حافظه بررسی می شود.


03


Waiting Time

اگر داده دورتر باشد،
زمان انتظار بیشتر می شود.


04


Latency Hiding

GPU با اجرای Warpهای دیگر
بخشی از این زمان را پنهان می کند.

Bandwidth و Latency دو سوال متفاوت هستند

فرض کنید یک بزرگراه
ده خط عبور داشته باشد.

این یعنی در هر لحظه
خودروهای زیادی می توانند
روی آن حرکت کنند.

اما اگر طول مسیر بسیار زیاد باشد،
یک خودرو هنوز زمان زیادی
برای رسیدن به مقصد نیاز دارد.


Bandwidth

How much data
can move per second?


Latency

How long does
one request take?
مفهوم سوال مثال ذهنی
Bandwidth در هر ثانیه چقدر داده منتقل می شود؟ عرض بزرگراه
Latency رسیدن یک درخواست چقدر طول می کشد؟ زمان سفر

چرا سطوح مختلف حافظه Latency متفاوت دارند؟

داده هرچه به واحد پردازشی نزدیک تر باشد،
معمولا سریع تر در دسترس قرار می گیرد.


Lower Latency

Registers

    │
    ▼

Shared Memory / Local Fast Storage

    │
    ▼

L1 Cache

    │
    ▼

L2 Cache

    │
    ▼

Main GPU Memory

Higher Latency

این ترتیب مفهومی است.

مقادیر دقیق Latency
به معماری،
نوع دسترسی،
Cache State
و شرایط اجرا بستگی دارند.

یک Load ساده چه مسیری طی می کند؟

فرض کنید Shader
یک مقدار را از حافظه درخواست می کند.


Load Instruction

      │
      ▼

     L1

      │
    MISS
      ▼

     L2

      │
    MISS
      ▼

Memory System

      │
      ▼

Main Memory

      │
      ▼

Return Data

      │
      ▼

Shader Continues

هرچه درخواست
در سطوح بیشتری حرکت کند،
زمان بیشتری قبل از آماده شدن داده
سپری می شود.

پس چرا GPU در هر Memory Miss متوقف نمی شود؟

اگر فقط یک Thread فعال وجود داشت،
این موضوع مشکل بزرگی ایجاد می کرد.


Thread

Compute

  │

  ▼

Memory Request

  │

  ▼

WAIT...

WAIT...

WAIT...

  │

  ▼

Continue

اما GPU
به طور معمول تعداد زیادی Thread و Warp فعال دارد.

بنابراین وقتی یک Warp
منتظر داده است،
Scheduler می تواند
Warp دیگری را اجرا کند.

Under the Hood — Latency Hiding چگونه کار می کند؟

GPU تلاش نمی کند
Latency حافظه را کاملا حذف کند.

در بسیاری از موارد،
راه حل موثرتر این است
که زمان انتظار یک Warp
با اجرای Warp دیگری پوشانده شود.


Warp A

Memory Wait
───────────────


Warp B

      Compute
      ────────


Warp C

              Compute
              ────────

اگر Warpهای کافی
برای اجرا وجود داشته باشند،
واحدهای محاسباتی می توانند
در بخشی از زمان انتظار حافظه
همچنان مشغول بمانند.

Latency Hiding یعنی چه؟


Latency Hiding

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

در GPU،
این کار اغلب با جابه جایی
میان Warpهای آماده
انجام می شود.


Warp A
Waiting for Memory

        │

        ▼

Scheduler

        │

        ├────► Warp B
        │       Compute
        │
        └────► Warp C
                Compute

برای پنهان کردن Latency به Warpهای آماده نیاز داریم

اگر فقط یک Warp
روی واحد پردازشی فعال باشد
و همان Warp منتظر حافظه بماند،
Scheduler انتخاب زیادی ندارد.


Only Warp A

Memory Wait

     │

     ▼

Nothing else ready

اما اگر چند Warp آماده باشند:


Warp A  Waiting

Warp B  Ready

Warp C  Ready

Warp D  Ready

Scheduler فرصت بیشتری
برای انجام کار مفید دارد.

Occupancy چه ارتباطی با Latency دارد؟

در فصل Register Pressure دیدیم
که تعداد Warpهای قابل استقرار
می تواند تحت تاثیر Register
و Shared Memory قرار گیرد.

اکنون دلیل اهمیت آن
واضح تر می شود.


Higher Resource Usage

        │

        ▼

Fewer Resident Warps

        │

        ▼

Fewer Scheduling Choices

        │

        ▼

Potentially Less Latency Hiding

اما این رابطه
به معنی
«Occupancy بیشتر همیشه بهتر است»
نیست.

Engineering Insight — Occupancy هدف نیست، ابزار است

هدف اصلی GPU
رسیدن به بیشترین درصد Occupancy ممکن نیست.

هدف این است
که Warpهای کافی برای پوشاندن Stallها
و استفاده موثر از واحدهای اجرایی وجود داشته باشند.

اگر برای افزایش Occupancy
Register Usage را بیش از حد محدود کنیم
و در نتیجه Spill رخ دهد،
ممکن است ترافیک حافظه بیشتر شود
و Performance بدتر شود.

Occupancy باید در کنار
Register Pressure،
Memory Traffic،
Instruction Mix
و Bottleneck واقعی تحلیل شود.

آیا GPU باید منتظر پایان یک درخواست بماند تا درخواست بعدی را بفرستد؟

نه لزوما.

سیستم های پردازشی مدرن
می توانند چندین درخواست حافظه
را در حال انتظار داشته باشند.

به چنین درخواست هایی
به صورت مفهومی
Outstanding Requests
گفته می شود.


Request A ─────────────► Memory

Request B ─────────────► Memory

Request C ─────────────► Memory

Request D ─────────────► Memory

All in flight

این رفتار
باعث می شود زیرسیستم حافظه
فرصت بیشتری برای استفاده
از Parallelism داخلی داشته باشد.

Memory-Level Parallelism چیست؟

اگر چند درخواست مستقل حافظه
هم زمان در حال پردازش باشند،
سیستم می تواند
بخش بیشتری از منابع حافظه
را درگیر نگه دارد.


Memory-Level Parallelism

توانایی داشتن چندین عملیات حافظه مستقل
به صورت هم زمان یا هم پوشان
در زیرسیستم حافظه.


Low MLP

Request A
   │
   ▼
Wait
   │
   ▼
Request B


Higher MLP

Request A ─────►
Request B ─────►
Request C ─────►
Request D ─────►

اما همه درخواست ها مستقل نیستند

فرض کنید دستور دوم
برای محاسبه آدرس خود
به نتیجه دستور اول نیاز داشته باشد.


Load A

  │
  ▼

Need A to compute address B

  │
  ▼

Load B

در این حالت،
Load B نمی تواند
قبل از دریافت نتیجه A
کاملا مستقل پیش برود.

وابستگی میان دستورها
می تواند توانایی پنهان کردن Latency
را کاهش دهد.

Cache چگونه Latency را کاهش می دهد؟

یکی از نقش های اساسی Cache
این است که داده پرکاربرد
را به واحد پردازشی نزدیک تر کند.


L1 Hit

Shorter Path


L2 Hit

Longer Path


Main Memory Access

Longest Path
in this simplified model

هر Cache Hit موفق
می تواند از رفتن درخواست
به سطح دورتر جلوگیری کند.

Locality فقط Hit Rate را بهتر نمی کند

وقتی برنامه
Spatial و Temporal Locality خوبی دارد،
داده مورد نیاز
احتمال بیشتری دارد
در Cache باقی بماند.

در نتیجه:


Better Locality

      │

      ▼

More Useful Cache Hits

      │

      ▼

Fewer Long-Latency Accesses

      │

      ▼

Lower Effective Memory Cost

Performance Impact — چه زمانی Latency مهم تر از Bandwidth می شود؟

اگر Workload درخواست های کوچک،
وابسته
و غیرقابل هم پوشانی زیادی داشته باشد،
Latency می تواند نقش بسیار مهمی پیدا کند.

در مقابل،
Workloadی که تعداد زیادی درخواست مستقل
و حجم بالایی از داده دارد
ممکن است بیشتر به Bandwidth
و Memory-Level Parallelism حساس باشد.

بنابراین دو برنامه
می توانند روی یک GPU
Bottleneckهای حافظه کاملا متفاوتی داشته باشند.

چرا Random Access می تواند Latency را دردناک تر کند؟

دسترسی تصادفی
معمولا Locality کمتری ایجاد می کند.


Sequential

100
101
102
103


Random

100
9001
42
78002

در الگوی دوم،
احتمال استفاده از داده های موجود
در همان Cache Line یا ناحیه Cache
می تواند کاهش پیدا کند.

در نتیجه تعداد بیشتری
Long-Latency Access
ممکن است رخ دهد.

Latency بالا لزوما یعنی GPU کاملا بیکار نیست

این نکته بسیار مهم است.

ممکن است یک Warp
صدها سیکل برای داده منتظر بماند،
اما در همان مدت
Warpهای دیگر کار مفید انجام دهند.


Time ─────────────────────────────►

Warp A
Load ───── Waiting ───────── Result

Warp B
     Compute ────────

Warp C
             Compute ─────────

Warp D
                      Compute ─────

آنچه اهمیت دارد
این است که آیا سیستم
کار دیگری برای انجام دادن دارد یا خیر.

Latency Hiding چه زمانی شکست می خورد؟

چند حالت رایج وجود دارد:

Warp کم

Scheduler گزینه کافی برای اجرا ندارد.

وابستگی زیاد

عملیات بعدی منتظر نتیجه Load قبلی است.

Cache Miss زیاد

درخواست های بیشتری به سطوح دورتر می روند.

MLP پایین

درخواست های مستقل کافی در حال اجرا نیست.

Resource Pressure

Register یا Shared Memory زیاد
تعداد Warpهای فعال را محدود می کند.

Divergence / Stalls

سایر Stallها نیز می توانند
گزینه های Scheduler را محدود کنند.

Common Mistakes — اشتباهات رایج درباره Memory Latency
  • Bandwidth بالا را معادل Latency پایین ندانید.
  • هر Memory Access را دارای Latency یکسان فرض نکنید.
  • Cache Hit و Main Memory Access را از نظر هزینه یکسان ندانید.
  • تصور نکنید GPU Latency را حذف می کند؛ اغلب آن را پنهان می کند.
  • Occupancy بیشتر را همیشه معادل Performance بیشتر ندانید.
  • Random Access را فقط مشکل Bandwidth در نظر نگیرید.
  • وابستگی میان Loadها را در تحلیل Latency نادیده نگیرید.
  • مقدار دقیق Latency یک معماری را بدون منبع معتبر حدس نزنید.

Bandwidth و Latency را کنار هم ببینیم

ویژگی Bandwidth Latency
سوال اصلی چه مقدار داده در واحد زمان؟ یک درخواست چقدر زمان می برد؟
مشکل نمونه حجم داده بسیار زیاد انتظار طولانی برای Load
راهکار معماری مهم رابط سریع و موازی Cache + Latency Hiding
بهینه سازی نرم افزاری کاهش Traffic افزایش Locality و Parallelism

سوالات متداول درباره Memory Latency

Memory Latency چیست؟

مدت زمانی است
که از صدور درخواست حافظه
تا در دسترس قرار گرفتن نتیجه آن
سپری می شود.

آیا Bandwidth بیشتر یعنی Latency کمتر؟

خیر.
Bandwidth ظرفیت انتقال داده در واحد زمان را بیان می کند،
در حالی که Latency زمان پاسخ یک درخواست را توصیف می کند.

GPU چگونه Latency حافظه را پنهان می کند؟

یکی از روش های اصلی
اجرای Warpهای آماده دیگر
در زمانی است که یک Warp
منتظر داده حافظه است.

آیا Occupancy بالا همیشه Latency را حل می کند؟

خیر.
Warpهای فعال باید واقعا آماده اجرا باشند
و Bottleneckهای دیگری مانند وابستگی دستورها،
Cache Miss یا Register Spill نیز مهم هستند.

Memory-Level Parallelism چیست؟

توانایی داشتن چندین عملیات حافظه مستقل
به صورت هم زمان یا هم پوشان
در زیرسیستم حافظه است.

چرا Cache Miss باعث Latency بیشتر می شود؟

زیرا درخواست باید به سطح دورتر
از Memory Hierarchy ادامه پیدا کند
و مسیر طولانی تری برای دسترسی به داده طی شود.

خلاصه فصل

Memory Latency درباره
زمان پاسخ یک درخواست است،
نه حجم داده قابل انتقال.

GPUها با استفاده از Cache،
Warp Scheduling،
چندین درخواست هم زمان
و Threadهای فراوان
تلاش می کنند اثر Latency را پنهان کنند.

به همین دلیل،
فهم Memory Performance
بدون درک Latency Hiding
کامل نیست.

  • Latency و Bandwidth دو مفهوم متفاوت هستند.
  • سطوح نزدیک تر Memory Hierarchy معمولا Latency کمتری دارند.
  • Cache Miss می تواند مسیر درخواست را طولانی تر کند.
  • GPU معمولا Latency را با اجرای Warpهای دیگر پنهان می کند.
  • Warpهای آماده برای Latency Hiding اهمیت دارند.
  • Occupancy بیشتر همیشه Performance بیشتر نیست.
  • Outstanding Requests می توانند دسترسی های حافظه را هم پوشان کنند.
  • Memory-Level Parallelism به استفاده بهتر از Memory System کمک می کند.
  • وابستگی میان Loadها می تواند Latency Hiding را محدود کند.

ارتباط با فصل های دیگر


Latency حافظه در GPU واقعا چقدر است؟

همه سطوح Memory Hierarchy
هزینه دسترسی یکسانی ندارند.

به طور کلی،
داده ای که در منابع On-Chip نزدیک به واحدهای اجرایی
قرار دارد،
با هزینه بسیار کمتری نسبت به داده ای
که نیازمند دسترسی به حافظه Off-Chip است
در اختیار واحد پردازشی قرار می گیرد.


Lower Access Cost

Registers
   │
   ▼
Shared Memory / L1
   │
   ▼
L2 Cache
   │
   ▼
Off-Chip GPU Memory

Higher Access Cost

اما یک نکته بسیار مهم وجود دارد:


برای تمام این سطوح نمی توان
یک عدد ثابت و مستقل از معماری
به عنوان Latency اعلام کرد.

Latency واقعی به عواملی مانند
GPU Architecture،
Cache Hit/Miss،
نوع دستور،
Access Pattern،
Memory Contention
و وضعیت اجرای Workload بستگی دارد.

دسترسی به Off-Chip Memory می تواند صدها Cycle طول بکشد

مستندات رسمی NVIDIA
برای دسترسی به حافظه خارج از Chip
از Latency در مقیاس
صدها Clock Cycle
صحبت می کنند.


Arithmetic / On-Chip Work
        │
        │
        ▼

Off-Chip Memory Request
        │
        │
        ▼

Potential Latency:

Hundreds of Clock Cycles

CUDA Best Practices Guide
نیز برای دسترسی
Uncached Local یا Global Memory
Latency در مقیاس
صدها Clock Cycle
را ذکر می کند.

بنابراین اگر یک Warp
برای دریافت Operand
مجبور به مراجعه به حافظه Off-Chip شود،
فاصله زمانی تا آماده شدن آن Operand
می تواند در مقایسه با بسیاری از عملیات محاسباتی
بسیار بزرگ باشد.

نمونه های واقعی از معماری های NVIDIA

برای اینکه مقیاس Latency ملموس تر شود،
مستندات رسمی نسل های قدیمی CUDA
اعداد تقریبی مشخصی ارائه کرده اند.

معماری / شرایط Latency گزارش شده توضیح
Compute Capability 2.x 400–800 cycles Off-Chip Memory Operand
Compute Capability 3.x ~200–400 cycles Off-Chip Memory Operand
Uncached Local / Global Memory 400–600 cycles عدد ذکر شده در یکی از نسخه های
CUDA Best Practices Guide
مستندات جدید CUDA صدها Clock Cycle NVIDIA دیگر یک محدوده عددی واحد
برای تمام معماری های جدید ارائه نمی کند.

این اعداد نباید
به عنوان مشخصه ثابت GPUهای امروزی
در نظر گرفته شوند.

هدف آنها نشان دادن
مقیاس هزینه Off-Chip Memory Access
است.

Engineering Insight — عدد Latency را بدون نام معماری نقل نکنید

عبارت هایی مانند
«Global Memory Latency برابر 500 Cycle است»
بیش از حد ساده سازی شده اند.

مستندات رسمی NVIDIA
برای نسل های مختلف GPU
محدوده های متفاوتی گزارش کرده اند.


Older NVIDIA Examples

CC 2.x
≈ 400–800 cycles

CC 3.x
≈ 200–400 cycles


Modern CUDA Documentation

Off-Chip Memory
→ typically hundreds of clock cycles

بنابراین در تحلیل معماری
باید میان دو نوع گزاره تفاوت بگذاریم:

  • اصل معماری:
    Off-Chip Memory Latency می تواند
    در مقیاس صدها Cycle باشد.
  • عدد دقیق:
    وابسته به معماری،
    مسیر حافظه
    و شرایط اجرای Workload است.
Engineering Insight — عدد Latency را بدون نام معماری نقل نکنید

عبارت هایی مانند
«Global Memory Latency برابر 500 Cycle است»
بیش از حد ساده سازی شده اند.

مستندات رسمی NVIDIA
برای نسل های مختلف GPU
محدوده های متفاوتی گزارش کرده اند.


Older NVIDIA Examples

CC 2.x
≈ 400–800 cycles

CC 3.x
≈ 200–400 cycles


Modern CUDA Documentation

Off-Chip Memory
→ typically hundreds of clock cycles

بنابراین در تحلیل معماری
باید میان دو نوع گزاره تفاوت بگذاریم:

  • اصل معماری:
    Off-Chip Memory Latency می تواند
    در مقیاس صدها Cycle باشد.
  • عدد دقیق:
    وابسته به معماری،
    مسیر حافظه
    و شرایط اجرای Workload است.

سطح: متوسط تا پیشرفته

پیش نیاز:
Warp،
Memory Coalescing،
Cache Line،
Memory Bandwidth،
Memory Latency

موضوع:
GPU Memory Architecture

زمان مطالعه:
حدود 20 تا 25 دقیقه


GPU MEMORY ARCHITECTURE

Memory Transaction در GPU چیست؟

وقتی یک Thread فقط 4 Byte داده می خواهد،
لزومی ندارد Memory System
دقیقا همان 4 Byte را به تنهایی منتقل کند.

حافظه در واحدهای مشخصی
داده را جابه جا می کند.

همین تفاوت میان
Requested Bytes
و
Transferred Bytes
یکی از کلیدهای درک Performance حافظه GPU است.


پاسخ سریع: Memory Transaction چیست؟

Memory Transaction
یک عملیات واقعی انتقال داده
در زیرسیستم حافظه است.

Threadها درخواست های منطقی Load و Store تولید می کنند،
اما سخت افزار این درخواست ها را
بر اساس Address Pattern،
Alignment
و قوانین معماری
به یک یا چند Memory Transaction تبدیل می کند.

در این فصل چه چیزهایی یاد می گیریم؟

  • Memory Transaction چیست.
  • تفاوت Memory Request و Memory Transaction چیست.
  • چرا یک Load چهار‌بایتی
    الزاما فقط چهار Byte ترافیک ایجاد نمی کند.
  • چگونه درخواست های یک Warp
    به Transaction تبدیل می شوند.
  • Transaction Size در معماری های جدید NVIDIA چگونه تعریف می شود.
  • چرا 32 Thread متوالی می توانند
    با چهار Transaction پاسخ داده شوند.
  • Over-fetch چیست.
  • Misalignment چگونه Transaction اضافی ایجاد می کند.
  • چگونه دسترسی پراکنده
    Memory Efficiency را به شدت کاهش می دهد.

نقشه مفهومی فصل


01


Thread Requests

Threadها آدرس های مورد نیاز را تولید می کنند.


02


Coalescing

درخواست های Warp بررسی و گروه بندی می شوند.


03


Memory Transactions

سخت افزار واحدهای واقعی انتقال را ایجاد می کند.


04


Useful Bytes

بخشی یا تمام داده منتقل شده
توسط Threadها استفاده می شود.

Memory Request و Memory Transaction یکی نیستند

فرض کنید یک Thread
یک مقدار float را بخواند:


float x = data[i];

از دید برنامه:


Thread Request

4 Bytes

اما زیرسیستم حافظه
در واحدهای انتقال سخت افزاری کار می کند.


Logical Request

4 B

   │
   ▼

Memory System

   │
   ▼

Physical Memory Transaction

Larger Transfer Unit

بنابراین:

Requested Bytes
و
Transferred Bytes
الزاما برابر نیستند.

یک مثال واقعی: Global Memory در GPUهای جدید NVIDIA

طبق CUDA Programming Guide،
Global Memory در مدل توضیح داده شده
با Memory Transactionهای
32-Byte
سرویس داده می شود.


Global Memory

┌──────────────┐
│     32 B     │
└──────────────┘

Memory Transaction

اگر Thread فقط یک Word چهار‌بایتی
از آن ناحیه بخواهد،
Transaction حافظه همچنان
32 Byte داده را پوشش می دهد.


32-Byte Transaction

┌────┬────┬────┬────┬────┬────┬────┬────┐
│ 4B │ 4B │ 4B │ 4B │ 4B │ 4B │ 4B │ 4B │
└────┴────┴────┴────┴────┴────┴────┴────┘
  ▲
  │
Thread needs
only this word

مثال رسمی: 32 Thread × 4 Byte

فرض کنیم 32 Thread یک Warp
هرکدام یک float چهار‌بایتی بخوانند.


32 Threads

×

4 Bytes per Thread

=

128 Bytes Useful Data

اگر Threadهای متوالی
به Wordهای متوالی حافظه دسترسی داشته باشند،
این 128 Byte
با چهار Transaction سی‌ودو‌بایتی
سرویس داده می شود.


Warp Requests

T00 T01 T02 T03 T04 T05 T06 T07
T08 T09 T10 T11 T12 T13 T14 T15
T16 T17 T18 T19 T20 T21 T22 T23
T24 T25 T26 T27 T28 T29 T30 T31

                 │
                 ▼

┌───────────────┐
│ Transaction 1 │ 32 B
└───────────────┘

┌───────────────┐
│ Transaction 2 │ 32 B
└───────────────┘

┌───────────────┐
│ Transaction 3 │ 32 B
└───────────────┘

┌───────────────┐
│ Transaction 4 │ 32 B
└───────────────┘


Total Traffic

4 × 32 B

=

128 B

در این مثال:


Useful Bytes      = 128 B

Transferred Bytes = 128 B

Efficiency        = 100%

Under the Hood — چرا چهار Transaction؟

32 Thread هرکدام 4 Byte می خواهند.


32 × 4 B

=

128 B

هر Transaction در این مدل
32 Byte را پوشش می دهد.


128 B
─────
 32 B

=

4 Transactions

اما این نتیجه فقط زمانی برقرار است
که آدرس ها به شکلی توزیع شده باشند
که همان چهار Segment
برای پاسخ به Warp کافی باشند.

پس فرمول بالا
به تنهایی قانون Coalescing نیست؛
Address Distribution
نیز تعیین کننده است.

Over-fetch چیست؟

Over-fetch زمانی رخ می دهد
که Memory System
داده بیشتری از مقداری که Workload
واقعا استفاده می کند منتقل کند.


Transferred

████████████████████████████████
             32 B


Actually Used

████
 4 B

در این مثال فرضی:


Transferred = 32 B

Useful      = 4 B

Unused      = 28 B

البته داده اضافه
ممکن است بعدا از طریق Cache
برای Threadهای دیگر مفید شود.

بنابراین Over-fetch
همیشه به معنی Waste قطعی نیست.

مثال رسمی NVIDIA: دسترسی بسیار پراکنده

حالا همان Warp را در نظر بگیریم.

32 Thread داریم
و هر Thread فقط 4 Byte می خواهد.

اما این بار
آدرس های Threadهای متوالی
حداقل 32 Byte از یکدیگر فاصله دارند.


T00 → [4 B] ──────────────

T01 →                 [4 B] ──────────────

T02 →                                 [4 B]

...

Each thread touches
a different 32-byte region

در مثال رسمی CUDA،
این وضعیت می تواند
برای هر Thread
یک Transaction سی‌ودو‌بایتی ایجاد کند.


32 Threads

×

32 B Transaction

=

1024 B Memory Traffic

در حالی که داده واقعا مورد استفاده:


32 Threads

×

4 B Useful Data

=

128 B

نتیجه: فقط 12.5 درصد Memory Traffic مفید است

حالا نسبت داده مفید
به کل داده منتقل شده را محاسبه کنیم:


Useful Data
────────────── × 100
Traffic

=

128
──── × 100
1024

=

12.5%


Memory Utilization = 12.5%

در این مثال،
87.5 درصد Traffic ایجاد شده
برای Wordهایی است که Warp
در آن درخواست مشخص
از آنها استفاده نمی کند.

Engineering Insight — Bandwidth اسمی و Bandwidth مفید یکی نیستند

فرض کنید GPU
Memory Bandwidth بسیار بالایی دارد.

اگر فقط 12.5 درصد داده منتقل شده
برای Workload مفید باشد،
بخش بزرگی از ظرفیت Memory System
صرف انتقال داده غیرضروری
برای همان درخواست ها می شود.


Peak Memory Bandwidth

          │
          ▼

Memory Transactions

          │
          ▼

Access Efficiency

          │
          ▼

Useful Bandwidth
Seen by Workload

داشتن Bus سریع کافی نیست؛
باید از Byteهایی که روی آن Bus منتقل می شوند
به شکل موثر استفاده کنیم.

Misalignment چگونه Transaction اضافی ایجاد می کند؟

حتی اگر Threadها
داده های کاملا متوالی بخوانند،
شروع Access Pattern نیز اهمیت دارد.

در مثال NVIDIA برای Compute Capability 6.0 یا بالاتر،
یک Warp که 32 مقدار چهار‌بایتی متوالی
و مناسب با Segmentها می خواند،
به چهار Transaction نیاز دارد.


Aligned

|----32 B----|
|----32 B----|
|----32 B----|
|----32 B----|

4 Transactions

اما اگر همان دسترسی متوالی
نسبت به مرز 32-Byte جابه جا شود،
ممکن است پنج Segment درگیر شوند.


Misaligned

     [ Requested 128 B ]
     │                 │
     ▼                 ▼

|--32--|--32--|--32--|--32--|--32--|

5 Segments Touched

پس فقط Sequential بودن کافی نیست؛
Alignment نیز اهمیت دارد.

خبر خوب: cudaMalloc داده را Align می کند

طبق CUDA Best Practices Guide،
حافظه تخصیص داده شده توسط
cudaMalloc()
حداقل
256-Byte aligned
است.

این موضوع کمک می کند
شروع Allocation
برای دسترسی های حافظه
Alignment مناسبی داشته باشد.

اما برنامه هنوز می تواند
با Indexing نامناسب،
Offset
یا Data Layout نامناسب
دسترسی Misaligned ایجاد کند.

آیا Transaction Size همیشه 32 Byte است؟

خیر.

اینجا باید همان قانون مهم کتاب را رعایت کنیم:


عدد معماری را نباید به تمام GPUها تعمیم داد.

CUDA Best Practices Guide
برای دستگاه های Compute Capability 6.0 یا بالاتر
Coalescing را بر اساس تعداد
32-Byte Transactionهای لازم
توضیح می دهد.

اما در معماری های قدیمی تر،
قواعد متفاوتی وجود داشته است.

معماری / حالت واحد مورد اشاره در مستند NVIDIA
Compute Capability 6.0+ 32-Byte Transaction
برخی دستگاه های CC 5.2 با L1 Caching 128-Byte Aligned Segment
نسل های قدیمی تر قواعد وابسته به Compute Capability

Performance Impact — Transaction اضافی دقیقا چه چیزی را خراب می کند؟

Transactionهای غیرضروری
می توانند Traffic حافظه را افزایش دهند.

این موضوع می تواند باعث شود:

  • Bandwidth بیشتری مصرف شود،
  • Byteهای غیرضروری بیشتری منتقل شوند،
  • فشار روی Cache و Memory System افزایش یابد،
  • تعداد درخواست های در حال حرکت بیشتر شود،
  • و Workloadهای Memory-Bound
    Performance کمتری دریافت کنند.

بنابراین Optimization حافظه
فقط درباره کاهش تعداد Load Instructionها نیست.

گاهی همان تعداد Load
با Address Pattern بهتر
ترافیک بسیار کمتری ایجاد می کند.

دو Warp، همان 128 Byte داده مفید؛ رفتار کاملا متفاوت

ویژگی Coalesced Highly Scattered
Threads 32 32
Data per Thread 4 B 4 B
Useful Data 128 B 128 B
32-B Transactions 4 32
Memory Traffic 128 B 1024 B
Utilization 100% 12.5%

این مثال یکی از بهترین دلایل
برای اهمیت Memory Coalescing است.

Common Mistakes — اشتباهات رایج درباره Memory Transaction
  • 4-Byte Load را معادل 4 Byte Memory Traffic ندانید.
  • تعداد Threadها را معادل تعداد Transactionها ندانید.
  • Sequential Access را بدون بررسی Alignment کامل فرض نکنید.
  • Transferred Bytes و Useful Bytes را یکی ندانید.
  • Over-fetch را در تحلیل Bandwidth نادیده نگیرید.
  • Transaction Size یک معماری NVIDIA را
    به تمام GPUها تعمیم ندهید.
  • فقط Peak Bandwidth را معیار Performance حافظه قرار ندهید.
  • Access Pattern را بدون Profiler بهینه فرض نکنید.

سوالات متداول درباره Memory Transaction

Memory Transaction چیست؟

عملیات واقعی انتقال داده
در زیرسیستم حافظه است
که برای پاسخ به درخواست های Threadها ایجاد می شود.

آیا یک Load چهار‌بایتی فقط 4 Byte از حافظه منتقل می کند؟

الزاما خیر.

Memory System در واحدهای انتقال سخت افزاری کار می کند
و ممکن است برای پاسخ به یک Word کوچک
داده بیشتری منتقل شود.

Transaction Size در GPUهای NVIDIA چقدر است؟

در مدل Global Memory توضیح داده شده
برای Compute Capability 6.0 و بالاتر،
CUDA Best Practices Guide
Coalescing را بر اساس
32-Byte Transactionها توضیح می دهد.

قواعد دقیق باید برای معماری هدف بررسی شوند.

32 Thread که floatهای متوالی می خوانند چند Transaction ایجاد می کنند؟

در مثال رسمی NVIDIA برای
Compute Capability 6.0 یا بالاتر،
32 Thread که Wordهای چهار‌بایتی متوالی
با Alignment مناسب می خوانند،
با چهار Transaction سی‌ودو‌بایتی
سرویس داده می شوند.

Misalignment چه تاثیری دارد؟

ممکن است Access Range
از مرز Segment عبور کند
و در نتیجه Transactionهای بیشتری لازم شوند.

در مثال رسمی NVIDIA،
دسترسی متوالی 128-Byte
می تواند به جای چهار Segment،
پنج Segment سی‌ودو‌بایتی را درگیر کند.

Over-fetch چیست؟

حالتی است که Memory System
Byteهای بیشتری از مقداری که Workload
واقعا نیاز دارد منتقل می کند.

خلاصه فصل

Threadها Memory Request تولید می کنند،
اما Memory System
آن درخواست ها را به Memory Transaction تبدیل می کند.

بنابراین برای تحلیل Performance
نباید فقط بپرسیم
«چند Byte درخواست شده؟»

باید بپرسیم:


برای تحویل آن Byteها
واقعا چند Byte در Memory System جابه جا شده است؟

  • Memory Request و Memory Transaction متفاوت هستند.
  • Global Memory در مدل فعلی CUDA
    با Transactionهای 32-Byte توضیح داده می شود.
  • 32 Thread × 4 B برابر 128 B داده مفید است.
  • دسترسی Coalesced مناسب می تواند آن را با چهار Transaction پاسخ دهد.
  • دسترسی شدیدا پراکنده در مثال NVIDIA
    می تواند 32 Transaction ایجاد کند.
  • در آن مثال 1024 B Traffic برای 128 B داده مفید ایجاد می شود.
  • Memory Utilization در آن حالت فقط 12.5 درصد است.
  • Misalignment می تواند Transaction اضافی ایجاد کند.
  • Transaction Size و Coalescing Rules وابسته به معماری هستند.

منابع فنی این فصل

  • NVIDIA CUDA Programming Guide —
    Coalesced Global Memory Access
  • NVIDIA CUDA C++ Best Practices Guide —
    Coalesced Access to Global Memory


سطح: متوسط تا پیشرفته

پیش نیاز:
Memory Transaction،
Memory Coalescing،
Cache Line،
Memory Bandwidth

موضوع:
GPU Memory Architecture

زمان مطالعه:
حدود 20 تا 25 دقیقه


GPU MEMORY ARCHITECTURE

Memory Alignment و Padding در GPU چیست؟

دو برنامه می توانند
دقیقا همان تعداد Byte را بخوانند،
اما تعداد متفاوتی Memory Transaction ایجاد کنند.

یکی از دلایل مهم این تفاوت
Memory Alignment
است.

Alignment مشخص می کند
آدرس داده نسبت به مرزهای طبیعی
نوع داده و واحدهای انتقال حافظه
در چه موقعیتی قرار گرفته است.


پاسخ سریع: Memory Alignment چیست؟

یک داده
Naturally Aligned
است اگر آدرس شروع آن
مضربی از اندازه مورد نیاز Alignment آن باشد.

برای مثال،
یک مقدار 4-Byte
که نیازمند Alignment چهار‌بایتی است،
در آدرس هایی مانند
0، 4، 8، 12 و 16
به صورت طبیعی Align است.

Alignment مناسب
به سخت افزار کمک می کند
دسترسی حافظه را با تعداد مناسب
Instruction و Transaction انجام دهد.

در این فصل چه چیزهایی یاد می گیریم؟

  • Memory Alignment چیست.
  • Naturally Aligned Address یعنی چه.
  • چرا اندازه Data Type در Alignment اهمیت دارد.
  • تفاوت Alignment نوع داده
    و Alignment مربوط به Memory Transaction چیست.
  • چرا Misalignment می تواند Transaction اضافی ایجاد کند.
  • Padding چیست و چرا Compiler آن را اضافه می کند.
  • Alignment در Structureها چگونه عمل می کند.
  • چرا ترتیب Fieldهای Structure مهم است.
  • چرا Custom Allocator می تواند Alignment را خراب کند.
  • چگونه Alignment و Coalescing با یکدیگر تعامل دارند.

نقشه مفهومی فصل


01


Data Size

نوع داده اندازه و نیاز Alignment مشخصی دارد.


02


Start Address

آدرس شروع داده نسبت به مرز مناسب بررسی می شود.


03


Memory Access

سخت افزار Load یا Store را اجرا می کند.


04


Transactions

Alignment و الگوی Warp
بر تعداد Transactionهای لازم اثر می گذارند.

Natural Alignment یعنی چه؟

فرض کنید یک مقدار
4 Byte اندازه دارد.

اگر آدرس شروع آن
مضربی از 4 باشد،
داده نسبت به این نیاز
Naturally Aligned است.


4-Byte Value

Aligned Addresses

0
4
8
12
16
20
24
28
...

به صورت عمومی:


Naturally Aligned

Address mod Alignment = 0

مثلا:


Address = 16

Alignment = 4


16 mod 4 = 0

Aligned

اما:


Address = 18

Alignment = 4


18 mod 4 = 2

Not 4-Byte Aligned

CUDA درباره Size و Alignment چه می گوید؟

در مدل Global Memory مستندشده توسط NVIDIA،
دسترسی به Wordهایی با اندازه های زیر
به صورت مستقیم پشتیبانی می شود:


1 Byte

2 Bytes

4 Bytes

8 Bytes

16 Bytes

برای اینکه دسترسی به چنین داده ای
به یک Global Memory Instruction
کامپایل شود،
اندازه باید یکی از مقادیر پشتیبانی شده باشد
و داده نیز
Naturally Aligned
باشد.

Data Size Natural Alignment Example
1 Byte هر آدرس Byte
2 Bytes مضرب 2
4 Bytes مضرب 4
8 Bytes مضرب 8
16 Bytes مضرب 16

دو نوع سوال درباره Alignment را از هم جدا کنیم

در تحلیل GPU Memory
دو مسئله مرتبط اما متفاوت داریم.

Data Alignment

آیا خود Operand
نسبت به اندازه و نیاز Alignment نوع داده
در آدرس مناسبی قرار گرفته است؟

Transaction Alignment

آیا مجموعه آدرس های Warp
به شکلی روی Segmentهای حافظه قرار گرفته
که Transaction اضافی ایجاد نشود؟

ممکن است تک تک مقادیر float
به صورت 4-Byte Aligned باشند،
اما کل Access Pattern یک Warp
نسبت به مرز 32-Byte
جابه جا شده باشد.

در این حالت
Data Alignment صحیح است،
اما Transaction Efficiency
می تواند ایده آل نباشد.

یک Warp با Alignment مناسب

برای دستگاه های NVIDIA
با Compute Capability 6.0 یا بالاتر،
درخواست های Global Memory یک Warp
بر اساس تعداد Segmentهای 32-Byte لازم
Coalesce می شوند.

اگر 32 Thread
هرکدام یک float چهار‌بایتی متوالی بخوانند:


32 Threads × 4 B

=

128 B

اگر محدوده مورد استفاده
با Segmentهای 32-Byte مناسب باشد:


|------ 32 B ------|
|------ 32 B ------|
|------ 32 B ------|
|------ 32 B ------|

Total

4 Transactions
128 B

حالا فقط آدرس شروع را جابه جا کنیم

فرض کنید همان 128 Byte داده متوالی
از نقطه ای شروع شود
که نسبت به مرز 32-Byte مناسب نیست.


32-B Segments

|------|------|------|------|------|
    [==========================]
       Requested Data

اکنون محدوده درخواست شده
ممکن است به جای چهار Segment،
پنج Segment را لمس کند.


Aligned Sequential Access

4 × 32 B segments


Misaligned Sequential Access

5 × 32 B segments

این دقیقا همان حالتی است
که NVIDIA در CUDA Best Practices Guide
برای Sequential but Misaligned Access
نشان می دهد.

Under the Hood — چرا چند Byte Offset می تواند یک Transaction اضافه کند؟

Memory Transactionها
مرزهای مشخصی دارند.

فرض کنید Segmentها
32 Byte باشند.


Segment 0
0 ─────────────── 31

Segment 1
32 ────────────── 63

Segment 2
64 ────────────── 95

Segment 3
96 ───────────── 127

Segment 4
128 ──────────── 159

یک محدوده 128-Byte
که دقیقا از Address 0 شروع شود:


Requested

0 ───────────────────────────── 127

Touches:

Segment 0
Segment 1
Segment 2
Segment 3

= 4 Segments

اما اگر همان طول دسترسی
مثلا از Address 4 شروع شود:


Requested

4 ───────────────────────────── 131

Touches:

Segment 0
Segment 1
Segment 2
Segment 3
Segment 4

= 5 Segments

فقط 4 Byte جابه جایی در شروع،
باعث شده محدوده
از مرز Segment پنجم عبور کند.

اثر نظری روی Traffic

در مثال قبل:

حالت Segment داده پوشش داده شده
Aligned 4 × 32 B 128 B
Misaligned 5 × 32 B 160 B

برای همان 128 Byte داده مورد درخواست،
حالت دوم 160 Byte از Segmentها را درگیر می کند.


Useful Data

128 B


Segments Requested

160 B


Theoretical Useful Ratio

128 / 160

=

80%

اما این نسبت
نباید مستقیما معادل Performance واقعی فرض شود،
زیرا Cache Reuse می تواند
بخشی از Over-fetch را برای Warpهای بعدی مفید کند.

مثال واقعی NVIDIA: Tesla V100

NVIDIA در CUDA Best Practices Guide
یک Copy Kernel را روی Tesla V100
با Compute Capability 7.0 بررسی کرده است.

در حالت بدون Offset
یا Offsetهایی که مضرب 8 Word هستند،
چهار Transaction سی‌ودو‌بایتی ایجاد می شود
و Bandwidth اندازه گیری شده
تقریبا:


≈ 790 GB/s

برای Offsetهای دیگر،
پنج Segment سی‌ودو‌بایتی
در هر Warp بارگذاری می شوند.

اگر فقط نسبت Transactionها را در نظر بگیریم،
ممکن است انتظار داشته باشیم
Throughput تقریبا به:


4 / 5

=

80%

حالت Aligned کاهش پیدا کند.

اما NVIDIA در این آزمایش
حدود 90 درصد Throughput حالت بدون Offset
را مشاهده کرده است.

دلیل اصلی این تفاوت،
استفاده Warpهای مجاور
از Cache Lineهای Over-fetched
توسط Warp قبلی بوده است.

Engineering Insight — تعداد Transaction مهم است، اما Cache می تواند نتیجه را تغییر دهد

یک مدل ساده ممکن است بگوید:


4 Transactions
vs
5 Transactions

→ 20% Efficiency Loss

اما Performance واقعی
فقط از تعداد Transactionهای یک Warp
تعیین نمی شود.

اگر Warp بعدی
از داده Over-fetched قبلی استفاده کند،
بخشی از Traffic اضافی
عملا Reuse می شود.

Transaction Analysis
مدل بسیار مهمی برای فهم رفتار حافظه است،
اما Cache Behavior تعیین می کند
هزینه نهایی Workload چقدر باشد.

cudaMalloc چه Alignmentی تضمین می کند؟

طبق مستندات NVIDIA،
آدرس حافظه ای که توسط
CUDA Runtime یا Driver Allocation
بازگردانده می شود،
حداقل
256-Byte Aligned
است.


cudaMalloc()

      │
      ▼

Base Address

Aligned to at least

256 Bytes

این Alignment قوی
باعث می شود Base Address Allocation
شروع مناسبی داشته باشد.

اما این تضمین
به این معنی نیست
که تمام Accessهای بعدی برنامه
خودکار Aligned باقی می مانند.

Base Address صحیح است؛ Offset می تواند آن را خراب کند

فرض کنید یک Allocation بزرگ ایجاد کنیم:


char* base;

cudaMalloc(&base, totalSize);

خود
base
Alignment مناسبی دارد.

اما اگر داخل آن
چند Array بسازیم:


float* arrayA =
    reinterpret_cast<float*>(base);

double* arrayB =
    reinterpret_cast<double*>(base + offset);

باید مطمئن شویم
offset
نیاز Alignment
نوع دوم را نیز رعایت می کند.


Aligned Base

0
│
▼
+-----------------------------------+
| Array A | Padding | Array B       |
+-----------------------------------+
                   ▲
                   │
             Must also satisfy
             Array B alignment

Padding چیست؟

Padding فضای اضافه ای است
که میان Fieldها
یا در انتهای یک Structure قرار می گیرد
تا Alignment مورد نیاز داده ها حفظ شود.

مثال مفهومی:


struct Example
{
    char   a;
    int    b;
};


Possible Layout

Byte

0       a
1       padding
2       padding
3       padding

4-7     b

سه Byte میان
a
و
b
داده کاربردی برنامه نیستند.

آنها برای قرار گرفتن
b
روی مرز مناسب
استفاده شده اند.

ترتیب Fieldها می تواند اندازه Structure را تغییر دهد

این Structure را در نظر بگیرید:


struct A
{
    char   x;
    double y;
    char   z;
};

به دلیل Alignment،
Compiler ممکن است
میان Fieldها و انتهای Structure
Padding قرار دهد.

در بعضی Layoutها،
تغییر ترتیب Fieldها
می تواند Padding را کاهش دهد.


struct B
{
    double y;
    char   x;
    char   z;
};

اما اندازه دقیق Structure
و ABI Rules
وابسته به Compiler،
Platform
و نوع داده هستند.

بنابراین مقدار دقیق
باید با ابزارهایی مانند
sizeof
و
alignof
بررسی شود.

Alignment را حدس نزنید؛ اندازه گیری کنید

در C++ می توان
اندازه و Alignment یک Type را
مستقیما بررسی کرد.


#include <iostream>

struct Particle
{
    float x;
    float y;
    float z;
    float mass;
};

int main()
{
    std::cout
        << sizeof(Particle)
        << "n";

    std::cout
        << alignof(Particle)
        << "n";
}

این روش
بهتر از فرض کردن Layout حافظه
بر اساس ظاهر Structure است.

Explicit Alignment

گاهی برنامه نویس
به Alignment مشخصی برای یک Type نیاز دارد.

در C++ استاندارد
می توان از
alignas
استفاده کرد:


struct alignas(16) Particle
{
    float x;
    float y;
    float z;
    float mass;
};

در مستندات CUDA
همچنین نمونه هایی از
Alignment Specifierهای CUDA
برای Structureها وجود دارد.

اما Explicit Alignment
نباید بدون دلیل استفاده شود.

Alignment بیشتر
می تواند Padding
و Memory Footprint را افزایش دهد.

Vector Typeها و Alignment

NVIDIA اعلام می کند
که Built-in Vector Typeهای CUDA
نیازهای Alignment مربوط به خود را
به صورت خودکار رعایت می کنند.

این موضوع برای Load و Storeهای Vectorized
اهمیت زیادی دارد.


Scalar Access

float


Vector Access

float2
float4

      │
      ▼

Larger Operand
      │
      ▼

Stricter Alignment Requirements
may apply

هنگام تبدیل Pointer
به Vector Type
باید مطمئن شویم
آدرس مبدا Alignment مورد نیاز
آن Type را رعایت می کند.

Alignment فقط Performance نیست؛ گاهی Correctness است

این نکته بسیار مهم است.

CUDA Programming Guide
هشدار می دهد
که خواندن Wordهای
8-Byte یا 16-Byte
که Naturally Aligned نیستند
می تواند نتیجه نادرست ایجاد کند.


قانون مهم

Alignment را فقط
به عنوان یک Optimization اختیاری نبینید.

برای برخی انواع دسترسی،
رعایت Alignment
جزئی از Correctness برنامه است.

این مسئله به ویژه
هنگام ساخت Custom Allocator،
تقسیم یک Allocation بزرگ
یا Cast کردن Pointerها
باید جدی گرفته شود.

Alignment و Coalescing چه تفاوتی دارند؟

مفهوم سوال اصلی
Alignment آدرس نسبت به مرز مورد نیاز در چه موقعیتی قرار دارد؟
Coalescing درخواست های Threadهای Warp
با چند Transaction پاسخ داده می شوند؟
Padding برای حفظ Layout و Alignment
چقدر فضای اضافی قرار داده شده است؟

این سه مفهوم
به یکدیگر متصل هستند،
اما نباید یکی فرض شوند.

Padding همیشه بد نیست

در نگاه اول،
Padding فضای تلف شده به نظر می رسد.


Useful Data

████████████


Padding

░░░░

اما Padding می تواند
Alignment مناسب ایجاد کند
و Access Pattern را ساده تر کند.

در مقابل،
Padding بیش از حد
می تواند:

  • Memory Footprint را افزایش دهد،
  • تعداد Objectهای قابل قرارگیری در Cache را کاهش دهد،
  • فاصله میان Fieldهای مورد استفاده Threadها را افزایش دهد،
  • و در بعضی Layoutها Coalescing را بدتر کند.

پس Padding یک Trade-off است،
نه چیزی که همیشه باید حذف شود.

Performance Impact — Alignment چه زمانی واقعا مهم می شود؟

Alignment نامناسب
می تواند از چند مسیر
به Performance آسیب بزند:

  • افزایش تعداد Memory Transactionها،
  • افزایش Over-fetch،
  • کاهش Memory Bandwidth Efficiency،
  • ایجاد چند Instruction برای برخی Accessها،
  • و کاهش کیفیت Coalescing.

اما هزینه واقعی
به Access Pattern،
Cache Reuse،
Data Type،
GPU Architecture
و Workload بستگی دارد.

به همین دلیل
Alignment Optimization
باید همراه با Profiling انجام شود.

Alignment چگونه به AoS و SoA وصل می شود؟

فرض کنید:


struct Particle
{
    float positionX;
    float positionY;
    float positionZ;

    float velocityX;
    float velocityY;
    float velocityZ;
};

اگر یک Warp
فقط
positionX
را از Particleهای متوالی بخواند،
آدرس های مورد استفاده
با فاصله
sizeof(Particle)
از یکدیگر قرار می گیرند.


Particle 0

Px Py Pz Vx Vy Vz


Particle 1

Px Py Pz Vx Vy Vz


Particle 2

Px Py Pz Vx Vy Vz


Warp wants only:

Px          Px          Px

Padding یا بزرگ شدن Structure
می تواند این Stride را بیشتر کند.

بنابراین Alignment،
Padding،
Data Layout
و Coalescing
در طراحی واقعی GPU
به صورت جداگانه تحلیل نمی شوند.

چک لیست عملی Alignment

  1. نوع داده و اندازه آن را مشخص کنید.
  2. نیاز Alignment آن Type را بررسی کنید.
  3. Base Allocation را بررسی کنید.
  4. Offsetهای داخلی را محاسبه کنید.
  5. Alignment هر Sub-allocation را جداگانه حفظ کنید.
  6. Access Pattern کل Warp را بررسی کنید.
  7. تعداد Segmentهای درگیر را تخمین بزنید.
  8. Padding و Structure Layout را بررسی کنید.
  9. با Profiler رفتار واقعی را اندازه گیری کنید.

Common Mistakes — اشتباهات رایج درباره Memory Alignment
  • Alignment را فقط مسئله Performance ندانید.
  • Aligned بودن Base Pointer را
    معادل Aligned بودن تمام Offsetها فرض نکنید.
  • Natural Alignment یک Operand را
    با Transaction Alignment یک Warp یکی ندانید.
  • Sequential Access را همیشه Optimal فرض نکنید.
  • Padding را همیشه فضای بی مصرف ندانید.
  • اندازه Structure را از روی Fieldها ذهنی محاسبه نکنید.
  • هنگام Pointer Cast نیاز Alignment نوع مقصد را فراموش نکنید.
  • Custom Allocator را بدون Alignment Logic طراحی نکنید.
  • قواعد Transaction یک GPU را
    به تمام معماری ها تعمیم ندهید.

مدل ذهنی نهایی


Data Type

    │
    ▼

Size + Alignment Requirement

    │
    ▼

Memory Address

    │
    ▼

Thread Access Pattern

    │
    ▼

Warp Address Distribution

    │
    ▼

Coalescing

    │
    ▼

Memory Transactions

    │
    ▼

Transferred Bytes

    │
    ▼

Cache Reuse

    │
    ▼

Effective Memory Performance

این زنجیره
یکی از مهم ترین مدل های ذهنی
برای تحلیل Performance حافظه GPU است.

سوالات متداول درباره Memory Alignment

Memory Alignment چیست؟

قرار گرفتن آدرس داده
روی مرزی است
که نیاز Alignment آن داده یا عملیات
را برآورده می کند.

Naturally Aligned یعنی چه؟

یعنی آدرس شروع داده
مضربی از Alignment مورد نیاز آن باشد.

مثلا یک مقدار با Alignment چهار‌بایتی
در Address 16
Naturally Aligned است،
زیرا 16 مضرب 4 است.

آیا cudaMalloc حافظه Aligned می دهد؟

بله.
طبق مستندات NVIDIA،
آدرس های بازگردانده شده توسط
Memory Allocation Routineهای CUDA
حداقل 256-Byte Aligned هستند.

پس چرا با cudaMalloc هنوز Misalignment رخ می دهد؟

زیرا Base Address می تواند کاملا Aligned باشد،
اما Indexing،
Offset،
Sub-allocation
یا Data Layout
آدرس های بعدی را نسبت به مرز مورد نظر
جابه جا کند.

آیا دسترسی متوالی همیشه چهار Transaction ایجاد می کند؟

خیر.

در مثال NVIDIA برای
Compute Capability 6.0 یا بالاتر،
32 دسترسی متوالی چهار‌بایتی
در حالت مناسب
چهار Segment سی‌ودو‌بایتی را درگیر می کنند.

اما Misalignment می تواند
همان Access Range را
به پنج Segment گسترش دهد.

Padding چیست؟

فضای اضافه ای است
که برای حفظ Layout یا Alignment مناسب
میان Fieldها یا انتهای Structure قرار می گیرد.

آیا Padding همیشه Performance را بدتر می کند؟

خیر.

Padding می تواند Alignment مناسب ایجاد کند،
اما در مقابل ممکن است
Memory Footprint یا Stride را افزایش دهد.

اثر نهایی به Data Layout
و Access Pattern بستگی دارد.

Alignment و Coalescing یکی هستند؟

خیر.

Alignment درباره موقعیت آدرس نسبت به مرز مشخص است،
در حالی که Coalescing درباره تبدیل
درخواست های Threadهای Warp
به تعداد کمتری Memory Transaction است.

این دو مفهوم ارتباط مستقیم دارند،
اما یکسان نیستند.

آیا Misalignment فقط Performance را کاهش می دهد؟

خیر.

طبق CUDA Programming Guide،
برخی دسترسی های 8-Byte و 16-Byte
در صورت Natural Alignment نامناسب
حتی می توانند نتیجه نادرست تولید کنند.

خلاصه فصل

Memory Alignment
پل میان Data Layout
و رفتار واقعی Memory Hardware است.

فقط اینکه Threadها
«داده متوالی» بخوانند کافی نیست؛
باید بررسی کنیم
این داده از کجا شروع می شود،
چه Alignmentی دارد
و محدوده Warp
چند Segment حافظه را درگیر می کند.

  • Natural Alignment یعنی آدرس مضربی از Alignment مورد نیاز باشد.
  • CUDA Global Memory از Operandهای 1، 2، 4، 8 و 16 Byte پشتیبانی می کند.
  • Size و Natural Alignment مناسب
    برای تولید یک Global Memory Instruction اهمیت دارند.
  • در CC 6.0+ Coalescing بر مبنای Segmentهای 32-Byte توضیح داده می شود.
  • 32 float متوالی در حالت مناسب
    چهار Segment سی‌ودو‌بایتی را درگیر می کنند.
  • Misalignment می تواند این مقدار را به پنج Segment افزایش دهد.
  • در مثال V100، Cache Reuse بخشی از هزینه Over-fetch را جبران کرده است.
  • cudaMalloc حداقل 256-Byte Alignment فراهم می کند.
  • Offset و Custom Sub-allocation هنوز می توانند Misalignment ایجاد کنند.
  • Padding برای حفظ Alignment استفاده می شود.
  • Alignment، Padding، Coalescing و Data Layout باید با هم تحلیل شوند.

منابع فنی این فصل

  • NVIDIA —
    CUDA C++ Programming Guide،
    Device Memory Accesses،
    Global Memory،
    Size and Alignment Requirement
  • NVIDIA —
    CUDA C++ Best Practices Guide،
    Coalesced Access to Global Memory
  • NVIDIA —
    CUDA C++ Best Practices Guide،
    Sequential but Misaligned Access Pattern
  • NVIDIA —
    CUDA C++ Best Practices Guide،
    Effects of Misaligned Accesses

سطح: مقدماتی تا متوسط

پیش نیاز:
Memory Controller،
Memory Bus Width،
Memory Bandwidth

موضوع:
GPU Memory Architecture

زمان مطالعه:
حدود 10 تا 12 دقیقه


GPU MEMORY ARCHITECTURE

VRAM در GPU چیست و چه کاری انجام می دهد؟

VRAM حافظه اصلی مورد استفاده GPU
برای نگهداری حجم زیادی از داده های گرافیکی و محاسباتی است.

Textureها،
Bufferها،
Render Targetها
و بسیاری از داده های مورد نیاز GPU
در این حافظه قرار می گیرند.


پاسخ سریع

VRAM حافظه ای با ظرفیت بالا
و پهنای باند زیاد است
که GPU برای نگهداری داده های مورد نیاز پردازش
از آن استفاده می کند.

VRAM نسبت به Register و Cache
ظرفیت بسیار بیشتری دارد،
اما دسترسی به آن نیز پرهزینه تر است.

در این فصل چه چیزهایی یاد می گیریم؟

  • VRAM چیست.
  • چه نوع داده هایی در VRAM قرار می گیرند.
  • چرا ظرفیت VRAM مهم است.
  • تفاوت ظرفیت VRAM و Memory Bandwidth چیست.
  • چرا VRAM بیشتر همیشه به معنی GPU سریع تر نیست.

نقشه مفهومی فصل


01


Application Data

Texture، Mesh، Buffer و سایر داده ها آماده می شوند.


02


VRAM

داده ها در حافظه اصلی GPU نگهداری می شوند.


03


Memory System

GPU داده مورد نیاز را از طریق زیرسیستم حافظه دریافت می کند.


04


GPU Processing

Shaderها و واحدهای مختلف GPU از داده استفاده می کنند.

VRAM دقیقا چیست؟

VRAM مخفف
Video Random Access Memory
است.

این حافظه
برای نگهداری حجم زیادی از داده هایی طراحی شده
که GPU در طول پردازش به آنها نیاز دارد.


GPU

 │
 ▼

Memory Controller

 │
 ▼

VRAM

┌──────────────────────┐
│ Textures             │
│ Vertex Buffers       │
│ Index Buffers        │
│ Render Targets       │
│ Depth Buffers        │
│ Compute Data         │
└──────────────────────┘

چه چیزهایی داخل VRAM قرار می گیرند؟

Textures

تصاویر و داده هایی که روی Surfaceها استفاده می شوند.

Geometry

Vertex و Index Bufferهای مربوط به مدل های سه بعدی.

Render Targets

تصاویر میانی یا نهایی که GPU در آنها می نویسد.

Depth / Stencil

داده های مربوط به عمق و برخی عملیات Rasterization.

Compute Buffers

داده های مورد استفاده Compute Shader و محاسبات عمومی.

Temporary Resources

منابع موقتی که در مراحل مختلف Rendering یا Compute ساخته می شوند.

چرا ظرفیت VRAM مهم است؟

اگر داده های مورد نیاز برنامه
داخل VRAM جا شوند،
GPU می تواند آنها را
در حافظه اختصاصی خود نگه دارد.

اما اگر نیاز حافظه
از ظرفیت موجود بیشتر شود،
سیستم ممکن است مجبور شود
برخی داده ها را جابه جا کند
یا از حافظه های دیگر کمک بگیرد.


Required Data

████████████████

VRAM Capacity

████████████████

Fits

اما:


Required Data

████████████████████████████

VRAM Capacity

████████████████

Does Not Fully Fit
Under the Hood — چرا GPU نمی تواند فقط از RAM سیستم استفاده کند؟

GPU به حجم بسیار زیادی از داده
با سرعت بالا نیاز دارد.

داشتن حافظه ای نزدیک تر
با رابط مناسب برای GPU
باعث می شود زیرسیستم گرافیکی
به پهنای باند بالاتری دسترسی داشته باشد.

در سیستم های مختلف
مدل حافظه می تواند متفاوت باشد،
اما اصل کلی این است که
هرچه داده به GPU نزدیک تر و مسیر دسترسی مناسب تر باشد،
هزینه انتقال کاهش پیدا می کند.

VRAM Capacity و Memory Bandwidth یکی نیستند

مشخصه سوال اصلی واحد
VRAM Capacity چه مقدار داده در حافظه جا می شود؟ GB
Memory Bandwidth داده با چه نرخ نظری جابه جا می شود؟ GB/s

یک GPU می تواند VRAM زیادی داشته باشد
اما Bandwidth متوسطی داشته باشد.

GPU دیگری ممکن است
VRAM کمتری داشته باشد
اما Memory System سریع تری ارائه دهد.

Engineering Insight — VRAM بیشتر همیشه Performance بیشتر نیست

اگر یک بازی یا برنامه
فقط 6 GB حافظه نیاز داشته باشد،
وجود 16 GB VRAM
به تنهایی باعث نمی شود
GPU سریع تر از یک مدل 8 GB شود.

VRAM بیشتر زمانی اهمیت بیشتری پیدا می کند
که Workload واقعا به آن ظرفیت اضافه نیاز داشته باشد.

Capacity مشکل «جا شدن داده» را حل می کند؛
Performance مسئله کل معماری است.

رزولوشن و کیفیت تصویر چگونه VRAM را افزایش می دهند؟

افزایش Resolution
معمولا باعث می شود
بافرهای تصویری بزرگ تر شوند.

Textureهای با کیفیت بالاتر نیز
می توانند فضای بیشتری مصرف کنند.


Higher Resolution
       +
Higher Texture Quality
       +
More Render Buffers

       │
       ▼

Higher VRAM Usage

Ray Tracing و Workloadهای مدرن

برخی تکنیک های جدید Rendering
به Bufferها و ساختارهای داده بیشتری نیاز دارند.

Ray Tracing،
Rendering با رزولوشن بالا،
Textureهای سنگین
و برخی Workloadهای تولید محتوا
می توانند مصرف VRAM را افزایش دهند.

میزان دقیق مصرف
به موتور،
تنظیمات،
Scene
و نرم افزار وابسته است.

Performance Impact — وقتی VRAM کافی نباشد

کمبود VRAM
می تواند باعث افزایش جابه جایی داده
میان سطوح مختلف حافظه شود.

بسته به سیستم و نرم افزار،
نتیجه ممکن است شامل مواردی مانند:

  • Stutter،
  • افزایش زمان بارگذاری داده،
  • افت Performance،
  • کاهش کیفیت خودکار Resourceها،
  • یا محدود شدن تنظیمات گرافیکی باشد.

اما رفتار دقیق
به سیستم عامل،
Driver،
API
و Application وابسته است.

همه VRAMها یکسان نیستند

VRAM یک نام عمومی برای نقش حافظه GPU است.

نوع فناوری حافظه
می تواند متفاوت باشد.

GDDR

خانواده ای از حافظه های گرافیکی
که در بسیاری از کارت های گرافیک استفاده می شود.

HBM

حافظه ای با طراحی متفاوت
که روی پهنای باند بسیار بالا
و رابط بسیار عریض تمرکز دارد.

در بخش های بعدی
این دو خانواده را
به صورت ساده مقایسه می کنیم.

Common Mistakes — اشتباهات رایج درباره VRAM
  • VRAM بیشتر را همیشه معادل GPU سریع تر ندانید.
  • VRAM Capacity را با Memory Bandwidth یکی ندانید.
  • فقط با حجم VRAM دو کارت گرافیک را مقایسه نکنید.
  • مصرف VRAM یک بازی را برای همه تنظیمات و Resolutionها ثابت فرض نکنید.
  • نوع حافظه را فقط با ظرفیت آن قضاوت نکنید.
  • پر بودن VRAM را همیشه به معنی خرابی Performance ندانید؛
    رفتار واقعی به نحوه مدیریت حافظه برنامه و سیستم بستگی دارد.

سوالات متداول درباره VRAM

VRAM چیست؟

حافظه اصلی مورد استفاده GPU
برای نگهداری داده هایی مانند Texture،
Buffer
و Render Target است.

VRAM بیشتر همیشه بهتر است؟

ظرفیت بیشتر برای Workloadهایی که
به حافظه بیشتری نیاز دارند مفید است،
اما به تنهایی Performance بالاتر را تضمین نمی کند.

آیا 8 GB VRAM برای همه بازی ها کافی است؟

نمی توان یک عدد ثابت برای همه بازی ها تعیین کرد.
نیاز VRAM به Resolution،
Texture Quality،
Ray Tracing،
موتور بازی
و تنظیمات گرافیکی بستگی دارد.

VRAM و RAM چه تفاوتی دارند؟

RAM سیستم حافظه عمومی CPU و سیستم است،
در حالی که VRAM برای استفاده GPU
و نیازهای پهنای باند زیرسیستم گرافیکی طراحی شده است.

آیا VRAM بیشتر FPS را افزایش می دهد؟

اگر Workload با کمبود VRAM روبه رو نباشد،
افزایش ظرفیت به تنهایی
معمولا باعث افزایش مستقیم FPS نمی شود.

خلاصه فصل

  • VRAM حافظه اصلی با ظرفیت بالای مورد استفاده GPU است.
  • Texture، Geometry، Render Target و Compute Data می توانند در VRAM قرار گیرند.
  • ظرفیت VRAM مشخص می کند چه مقدار داده در حافظه جا می شود.
  • Memory Bandwidth سرعت انتقال داده را توصیف می کند.
  • VRAM بیشتر به تنهایی Performance بیشتر ایجاد نمی کند.
  • Resolution، Texture Quality و Workload می توانند مصرف VRAM را افزایش دهند.
  • کمبود VRAM می تواند باعث افزایش جابه جایی داده و افت تجربه کاربری شود.
  • GDDR و HBM دو خانواده مهم حافظه GPU هستند.


سطح: مقدماتی تا متوسط

پیش نیاز:
VRAM،
Memory Bus Width،
Memory Bandwidth

موضوع:
GPU Memory Architecture

زمان مطالعه:
حدود 8 تا 10 دقیقه


GPU MEMORY ARCHITECTURE

GDDR چیست و چرا در کارت های گرافیک استفاده می شود؟

GDDR خانواده ای از حافظه های DRAM
است که برای نیازهای پهنای باند بالای
پردازنده های گرافیکی طراحی شده است.

نسل هایی مانند
GDDR5،
GDDR6
و GDDR7
در کارت های گرافیک مختلف استفاده شده اند
و با افزایش نرخ انتقال داده،
به GPU اجازه می دهند
حجم بیشتری از اطلاعات را
در واحد زمان جابه جا کند.


پاسخ سریع: GDDR چیست؟

GDDR مخفف

Graphics Double Data Rate

است.

این خانواده از حافظه ها
برای سیستم هایی طراحی شده است
که به پهنای باند حافظه زیادی نیاز دارند
و به همین دلیل
در بسیاری از کارت های گرافیک
به عنوان VRAM استفاده می شود.

در این فصل چه چیزهایی یاد می گیریم؟

  • GDDR چیست.
  • چرا GPU به حافظه گرافیکی پرسرعت نیاز دارد.
  • نسل های مختلف GDDR چه تفاوت کلی دارند.
  • GDDR6X چیست.
  • GDDR7 چه تغییر مهمی ایجاد کرده است.
  • سرعت حافظه چگونه به Memory Bandwidth مرتبط می شود.
  • چرا نوع GDDR به تنهایی سرعت GPU را تعیین نمی کند.

چرا GPU به GDDR نیاز دارد؟

GPU در بسیاری از Workloadها
به صورت هم زمان
روی حجم بزرگی از داده کار می کند.

Textureها،
Frame Bufferها،
Geometry،
Render Targetها
و داده های محاسباتی
باید با نرخ بالایی
میان VRAM و GPU جابه جا شوند.


VRAM
 │
 │  Large Amounts of Data
 ▼
Memory Interface
 │
 ▼
GPU
 │
 ├── Shaders
 ├── Texture Units
 ├── Render Backends
 └── Compute Units

به همین دلیل،
یکی از اهداف اصلی حافظه گرافیکی
فراهم کردن
Memory Bandwidth بالا
است.

رابطه GDDR و VRAM چیست؟

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


VRAM
"What role does the memory have?"

        │
        ▼

Memory Technology

        │
        ├── GDDR
        │
        └── HBM

بنابراین VRAM و GDDR
دو نام برای یک مفهوم واحد نیستند.

برای مثال،
یک کارت گرافیک ممکن است
16 GB VRAM داشته باشد
و فناوری حافظه آن
GDDR6 باشد.

نسل های GDDR

GDDR طی سال ها
نسل های مختلفی داشته است.

نسل جایگاه کلی
GDDR3 نسل قدیمی مورد استفاده در GPUهای گذشته
GDDR5 نسلی بسیار رایج در چندین نسل کارت گرافیک
GDDR5X توسعه ای برای افزایش نرخ انتقال نسبت به GDDR5
GDDR6 نسل پرکاربرد در کارت های گرافیک مدرن
GDDR6X فناوری توسعه یافته با Signaling متفاوت و نرخ انتقال بالاتر
GDDR7 نسل جدیدتر با نرخ انتقال بالاتر و Signaling پیشرفته تر

آیا نسل جدیدتر GDDR یعنی GPU سریع تر؟

نه لزوما.

نوع حافظه
فقط یکی از اجزای معماری GPU است.


GPU Performance

     │
     ├── Compute Resources
     ├── Architecture
     ├── Clock
     ├── Cache
     ├── Memory Controllers
     ├── Bus Width
     ├── Memory Speed
     └── Workload

بنابراین یک GPU مجهز به GDDR7
الزاما از هر GPU مجهز به GDDR6
سریع تر نیست.

برای مقایسه واقعی
باید کل معماری
و Performance محصول
بررسی شود.

Memory Speed در GDDR چه معنایی دارد؟

حافظه GDDR
در هر ثانیه تعداد زیادی Bit
را روی هر مسیر داده منتقل می کند.

نرخ انتقال موثر حافظه
معمولا با واحدهایی مانند:


Gb/s per pin

بیان می شود.

هرچه نرخ انتقال بالاتر باشد،
با ثابت بودن سایر عوامل،
پتانسیل Memory Bandwidth نیز افزایش پیدا می کند.

GDDR چگونه به Memory Bandwidth وصل می شود؟

دو عامل بسیار مهم هستند:


Memory Data Rate
       ×
Memory Bus Width

       │
       ▼

Memory Bandwidth

به همین دلیل،
فقط نگاه کردن به سرعت Memory Chip
برای مقایسه Memory System کافی نیست.

یک GPU می تواند
Memory Bus عریض تر
و حافظه ای با سرعت کمتر داشته باشد،
اما همچنان Bandwidth زیادی تولید کند.

یک مثال ساده

فرض کنید حافظه ای
نرخ انتقال موثر
20 Gb/s
داشته باشد
و Memory Bus برابر
256 Bit باشد.


20 Gb/s × 256 bit

        │
        ▼

5120 Gb/s

        │
        ▼

÷ 8

        │
        ▼

640 GB/s

بنابراین پهنای باند نظری این مثال:


640 GB/s

است.

این یک مثال محاسباتی است
و به یک GPU مشخص اشاره نمی کند.

GDDR6

GDDR6
یکی از نسل های مهم و پرکاربرد
حافظه گرافیکی است
که در طیف گسترده ای از GPUها
و سیستم های گرافیکی استفاده شده است.

این نسل نسبت به نسل های قدیمی تر
امکان دستیابی به نرخ انتقال بالاتر
و Memory Bandwidth بیشتر را فراهم کرد.


GDDR6

High Data Rate
      +
Wide GPU Memory Interface

      │
      ▼

High Memory Bandwidth

GDDR6X چیست؟

GDDR6X
نوعی حافظه گرافیکی توسعه یافته
برای دستیابی به نرخ انتقال بالاتر است.

یکی از تفاوت های مهم آن
استفاده از
PAM4 Signaling
است.


Traditional Binary Signaling

2 Signal Levels


PAM4

4 Signal Levels

PAM4 اجازه می دهد
در هر Symbol
اطلاعات بیشتری کدگذاری شود.

این روش
امکان افزایش نرخ انتقال داده را فراهم می کند،
هرچند طراحی Signaling
و مدیریت Signal Integrity
پیچیده تر می شود.

GDDR7 چه تغییری ایجاد کرده است؟

GDDR7 نسل جدیدتر خانواده GDDR است
که برای افزایش بیشتر
Memory Bandwidth
و بهبود بهره وری انتقال داده طراحی شده است.

یکی از تغییرات مهم آن
استفاده از
PAM3 Signaling
برای رابط داده است.


PAM3

Three Signal Levels

 -1
  0
 +1

این روش
با استفاده از سه سطح سیگنال
اطلاعات را منتقل می کند
و یکی از تفاوت های مهم
GDDR7 با نسل های قبلی است.

چرا همیشه Memory Bus را عریض تر نمی کنند؟

افزایش Bus Width
می تواند Memory Bandwidth را افزایش دهد،
اما رایگان نیست.

رابط حافظه عریض تر
معمولا به موارد بیشتری نیاز دارد:

  • Memory Controllerهای بیشتر،
  • مسیرهای الکتریکی بیشتر،
  • فضای بیشتر روی Chip و Board،
  • پیچیدگی بیشتر طراحی،
  • و هزینه بیشتر.

به همین دلیل
افزایش Data Rate حافظه
راه دیگری برای افزایش Bandwidth
بدون افزایش مستقیم Bus Width است.

نوع حافظه و ظرفیت حافظه را جدا ببینید

عبارت هایی مانند:


8 GB GDDR6

12 GB GDDR6X

16 GB GDDR7

دو ویژگی متفاوت را هم زمان بیان می کنند.

مشخصه معنا
8 / 12 / 16 GB ظرفیت VRAM
GDDR6 / GDDR6X / GDDR7 فناوری حافظه

ظرفیت بیشتر
به معنی فضای ذخیره سازی بیشتر است.

نوع و سرعت حافظه
در کنار Bus Width
روی Bandwidth اثر می گذارند.

GDDR و DDR معمولی چه تفاوتی دارند؟

هر دو خانواده
بر پایه فناوری DRAM قرار دارند،
اما برای نیازهای متفاوتی بهینه شده اند.

ویژگی DDR System Memory GDDR
کاربرد اصلی حافظه عمومی سیستم حافظه گرافیکی
پردازنده اصلی مصرف کننده CPU / System GPU
تمرکز طراحی تعادل نیازهای حافظه عمومی پهنای باند بالا برای Workloadهای GPU

بنابراین نباید
GDDR6 را صرفا نسخه دیگری از DDR6 فرض کرد.

این دو خانواده
نام گذاری و مسیر تکامل متفاوتی دارند.

Performance Impact — حافظه سریع تر چه زمانی اهمیت دارد؟

افزایش Memory Bandwidth
بیشترین تاثیر را زمانی دارد
که Workload واقعا
به انتقال حجم زیادی از داده محدود شده باشد.

این Workloadها را معمولا
Memory-Bound
می نامیم.


Memory-Bound Workload

GPU Compute Units
      ▲
      │
Waiting for Data
      │
      ▲
Memory System

اگر Bottleneck اصلی
جای دیگری باشد،
حافظه سریع تر
الزاما افزایش Performance بزرگی ایجاد نمی کند.

Common Mistakes — اشتباهات رایج درباره GDDR
  • نسل جدیدتر GDDR را همیشه معادل GPU سریع تر ندانید.
  • Memory Speed را با Memory Bandwidth یکی ندانید.
  • Bus Width را به تنهایی معیار قدرت Memory System قرار ندهید.
  • ظرفیت VRAM را با نوع GDDR اشتباه نگیرید.
  • GDDR و DDR سیستم را یک خانواده با شماره نسل مشترک فرض نکنید.
  • Peak Memory Bandwidth را معادل Performance واقعی برنامه ندانید.

سوالات متداول درباره GDDR

GDDR چیست؟

خانواده ای از حافظه های DRAM
است که برای نیازهای پهنای باند بالای
سیستم های گرافیکی طراحی شده است.

آیا GDDR همان VRAM است؟

دقیقا نه.

VRAM نقش حافظه GPU را توصیف می کند،
در حالی که GDDR
نوعی فناوری حافظه است
که می تواند برای VRAM استفاده شود.

GDDR6X چه تفاوت مهمی با GDDR6 دارد؟

یکی از تفاوت های مهم GDDR6X
استفاده از PAM4 Signaling
برای دستیابی به نرخ انتقال بالاتر است.

GDDR7 چه نوع Signalingی دارد؟

GDDR7 برای رابط داده
از PAM3 Signaling استفاده می کند
که سه سطح سیگنال دارد.

آیا GDDR7 همیشه از GDDR6 سریع تر است؟

فناوری GDDR7 امکان نرخ انتقال بالاتری را فراهم می کند،
اما Performance نهایی یک GPU
به کل معماری،
Bus Width،
Clock،
Cache،
Compute Resources
و Workload بستگی دارد.

آیا 256-bit GDDR6 از 128-bit GDDR7 سریع تر است؟

فقط با Bus Width یا نسل حافظه
نمی توان پاسخ داد.

برای مقایسه باید
Data Rate و Bus Width را با هم بررسی کرد
و Memory Bandwidth نهایی را مقایسه کرد.

خلاصه فصل

  • GDDR خانواده ای از حافظه های گرافیکی با پهنای باند بالا است.
  • GDDR می تواند به عنوان فناوری VRAM کارت گرافیک استفاده شود.
  • GDDR5، GDDR6 و GDDR7 نسل های مختلف این خانواده هستند.
  • GDDR6X از PAM4 Signaling استفاده می کند.
  • GDDR7 از PAM3 Signaling استفاده می کند.
  • Memory Data Rate و Bus Width با هم Memory Bandwidth را شکل می دهند.
  • ظرفیت VRAM و نوع GDDR دو مشخصه متفاوت هستند.
  • نسل جدیدتر حافظه به تنهایی Performance بیشتر GPU را تضمین نمی کند.


سطح: مقدماتی تا متوسط

پیش نیاز:
VRAM،
GDDR،
Memory Bandwidth،
Memory Bus Width

موضوع:
GPU Memory Architecture

زمان مطالعه:
حدود 8 تا 10 دقیقه


GPU MEMORY ARCHITECTURE

HBM چیست و چه تفاوتی با GDDR دارد؟

HBM یا
High Bandwidth Memory
خانواده ای از حافظه های پرسرعت است
که با استفاده از Memory Stackها
و رابط حافظه بسیار عریض،
برای دستیابی به پهنای باند بالا طراحی شده است.

HBM به ویژه در GPUهای حرفه ای،
شتاب دهنده های محاسباتی
و سیستم های هوش مصنوعی
اهمیت زیادی پیدا کرده است.


پاسخ سریع: HBM چیست؟

HBM نوعی حافظه با پهنای باند بالا است
که چند لایه حافظه را
به صورت Stack
در کنار پردازنده قرار می دهد.

به جای تکیه اصلی بر
نرخ انتقال بسیار بالا روی یک رابط نسبتا باریک،
HBM از یک رابط بسیار عریض
برای انتقال حجم زیادی از داده استفاده می کند.

در این فصل چه چیزهایی یاد می گیریم؟

  • HBM چیست.
  • Memory Stack چیست.
  • چرا HBM پهنای باند بالایی دارد.
  • HBM چه تفاوتی با GDDR دارد.
  • چرا HBM در شتاب دهنده های AI و HPC محبوب است.
  • چرا تمام کارت های گرافیک از HBM استفاده نمی کنند.

ایده اصلی HBM چیست؟

در حافظه های سنتی،
Memory Chipها معمولا
به صورت جداگانه
در اطراف GPU روی برد قرار می گیرند.

HBM رویکرد متفاوتی دارد.

چند Die حافظه
روی یکدیگر قرار می گیرند
و یک
Memory Stack
را تشکیل می دهند.


HBM Stack

┌──────────────────┐
│   DRAM Layer     │
├──────────────────┤
│   DRAM Layer     │
├──────────────────┤
│   DRAM Layer     │
├──────────────────┤
│   DRAM Layer     │
├──────────────────┤
│   Base Layer     │
└──────────────────┘

این طراحی اجازه می دهد
ظرفیت و پهنای باند زیادی
در فضای فیزیکی نسبتا فشرده
فراهم شود.

Stacked Memory یعنی چه؟

به جای اینکه تمام تراشه های حافظه
فقط در سطح برد
کنار یکدیگر قرار بگیرند،
در HBM چند لایه DRAM
روی یکدیگر ساخته می شوند.


Traditional Arrangement

[Memory] [Memory] [GPU] [Memory] [Memory]


HBM Concept

        [HBM Stack]
             │
             │
[HBM Stack] [GPU] [HBM Stack]
             │
             │
        [HBM Stack]

این تفاوت فیزیکی
یکی از ویژگی های اصلی HBM است.

لایه های حافظه چگونه به هم متصل می شوند؟

در فناوری های HBM،
اتصال عمودی میان Dieها
با فناوری هایی مانند

Through-Silicon Via

یا
TSV
انجام می شود.


DRAM Layer
●  ●  ●  ●
│  │  │  │
DRAM Layer
●  ●  ●  ●
│  │  │  │
DRAM Layer
●  ●  ●  ●
│  │  │  │
Base Layer

│  │  │  │
└──┴──┴──┴── TSV Connections

در یک توضیح ساده،
TSVها مسیرهای عمودی
برای ارتباط میان لایه های Silicon فراهم می کنند.

HBM چگونه به GPU متصل می شود؟

در پیاده سازی های رایج HBM،
GPU و Memory Stackها
با استفاده از یک بستر ارتباطی بسیار متراکم
در نزدیکی یکدیگر قرار می گیرند.

یکی از فناوری های شناخته شده برای این کار
Silicon Interposer
است.


┌───────────┐     ┌───────────────┐     ┌───────────┐
│ HBM Stack │     │      GPU      │     │ HBM Stack │
└─────┬─────┘     └───────┬───────┘     └─────┬─────┘
      │                   │                   │
════════════════════════════════════════════════════
                  Interposer
════════════════════════════════════════════════════

این ساختار
امکان ایجاد تعداد بسیار زیادی اتصال
میان GPU و حافظه را فراهم می کند.

راز اصلی HBM: رابط بسیار عریض

یکی از مهم ترین تفاوت های HBM
با حافظه های GDDR
عرض بسیار زیاد رابط حافظه است.

ایده کلی را می توان این طور دید:


GDDR

Higher Signaling Rate
        +
Relatively Narrower Interface


HBM

Wide Memory Interface
        +
Many Parallel Data Paths

HBM با ایجاد تعداد زیادی مسیر موازی
می تواند حجم بسیار زیادی از داده را
به صورت هم زمان منتقل کند.

یک مثال ساده: بزرگراه

برای درک تفاوت کلی،
Memory Interface را
مانند یک بزرگراه تصور کنید.


GDDR

→ → → → → → → →

Fewer Lanes
Higher Speed per Lane


HBM

→ → → → → → → → → → → → → → → →
→ → → → → → → → → → → → → → → →
→ → → → → → → → → → → → → → → →

Many More Parallel Lanes

این تشبیه دقیق الکتریکی نیست،
اما برای فهم ایده اصلی مفید است:


HBM بیشتر روی تعداد زیاد مسیرهای موازی تکیه می کند.

مقایسه کلی GDDR و HBM

ویژگی GDDR HBM
ساختار حافظه تراشه های حافظه مجزا Stackهای چندلایه
رابط حافظه نسبتا باریک تر با نرخ انتقال بالا بسیار عریض
فضای Board تراشه ها در اطراف GPU قرار می گیرند حافظه در Package بسیار نزدیک به GPU قرار می گیرد
پیچیدگی Packaging معمولا ساده تر بالاتر
کاربرد رایج Gaming و کارت های گرافیک عمومی HPC، AI و شتاب دهنده های حرفه ای

چرا HBM برای AI مهم شده است؟

مدل های هوش مصنوعی
می توانند حجم عظیمی از داده
و پارامترها را پردازش کنند.

واحدهای محاسباتی سریع
اگر داده کافی دریافت نکنند،
نمی توانند از تمام ظرفیت خود استفاده کنند.


AI Accelerator

Huge Compute Capability
        │
        ▼
Needs Large Data Flow
        │
        ▼
High Memory Bandwidth
        │
        ▼
HBM

به همین دلیل
Memory Bandwidth و Memory Capacity
در بسیاری از شتاب دهنده های AI
به مشخصه هایی بسیار مهم تبدیل شده اند.

HBM در HPC

محاسبات علمی و
High Performance Computing
نیز اغلب با حجم بزرگی از داده سروکار دارند.

Simulation،
Scientific Computing،
Machine Learning
و Data Analytics
از جمله Workloadهایی هستند
که می توانند از Memory Bandwidth بالا
استفاده کنند.

به همین دلیل HBM
در بسیاری از Acceleratorهای حرفه ای
و پردازنده های مخصوص HPC دیده می شود.

اگر HBM خوب است، چرا همه GPUها از آن استفاده نمی کنند؟

HBM مزایای مهمی دارد،
اما طراحی و Packaging آن
پیچیده تر است.

استفاده از Memory Stack،
اتصال های متراکم
و Packaging پیشرفته
می تواند هزینه ساخت را افزایش دهد.


HBM

High Bandwidth
      +
Compact Integration
      +
Advanced Packaging

      │
      ▼

Higher Design and Packaging Complexity

در بازارهایی مانند Gaming،
GDDR می تواند
تعادل مناسبی میان:

  • Performance،
  • Capacity،
  • Cost،
  • و پیچیدگی ساخت

فراهم کند.

نسل های HBM

HBM نیز مانند GDDR
در طول زمان تکامل پیدا کرده است.


HBM

 │
 ▼

HBM2

 │
 ▼

HBM2E

 │
 ▼

HBM3

 │
 ▼

HBM3E

 │
 ▼

HBM4

با پیشرفت نسل ها،
ظرفیت،
سرعت انتقال
و پهنای باند قابل دستیابی
افزایش پیدا کرده است.

مقادیر دقیق
به نسل حافظه،
Memory Stack
و محصول نهایی بستگی دارند.

ظرفیت HBM چگونه افزایش پیدا می کند؟

هر HBM Stack
از چند Die حافظه تشکیل می شود.

افزایش ظرفیت Dieها،
تعداد لایه ها
و تعداد Stackهای استفاده شده
می تواند ظرفیت کل حافظه سیستم را افزایش دهد.


Stack 1
   +
Stack 2
   +
Stack 3
   +
Stack 4

   │
   ▼

Total HBM Capacity

در HBM هم Capacity و Bandwidth متفاوت هستند

وجود مقدار زیادی HBM
الزاما به معنی Bandwidth بیشتر نیست.

مشخصه معنا
HBM Capacity چه مقدار داده در حافظه قرار می گیرد؟
HBM Bandwidth با چه نرخ نظری می توان داده را جابه جا کرد؟

هر دو مشخصه مهم هستند،
اما مشکل متفاوتی را حل می کنند.

مدل ذهنی ساده GDDR و HBM


GDDR

Fast Memory Chips
      │
      ▼
High-Speed Links
      │
      ▼
GPU


HBM

Stacked Memory
      │
      ▼
Very Wide Interface
      │
      ▼
GPU / Accelerator

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

جزئیات واقعی
به نسل حافظه
و طراحی محصول بستگی دارند.

Performance Impact — HBM چه زمانی مزیت بزرگی ایجاد می کند؟

HBM زمانی بیشترین اهمیت را دارد
که Performance برنامه
به نرخ دسترسی به حافظه محدود شده باشد.


Compute Units

Very Fast

    │
    ▼

Need More Data

    │
    ▼

Memory Bandwidth Bottleneck

    │
    ▼

Higher Bandwidth Can Help

اما مانند هر فناوری حافظه دیگری،
HBM به تنهایی
Performance بالاتر را تضمین نمی کند.

Common Mistakes — اشتباهات رایج درباره HBM
  • HBM را همیشه سریع تر از هر نوع GDDR فرض نکنید.
  • HBM Capacity را با HBM Bandwidth یکی ندانید.
  • HBM را فقط مخصوص Gaming ندانید؛
    کاربرد مهم آن در AI و HPC است.
  • نسل جدیدتر HBM را بدون بررسی محصول نهایی
    معادل Performance بیشتر ندانید.
  • فقط نوع حافظه را معیار قدرت GPU قرار ندهید.
  • مزایای HBM را بدون در نظر گرفتن
    هزینه و پیچیدگی Packaging ارزیابی نکنید.

سوالات متداول درباره HBM

HBM مخفف چیست؟

مخفف
High Bandwidth Memory
به معنی حافظه با پهنای باند بالا است.

تفاوت اصلی HBM و GDDR چیست؟

HBM از Memory Stackها
و رابط حافظه بسیار عریض استفاده می کند،
در حالی که GDDR معمولا از
تراشه های مجزا با رابط های پرسرعت
روی برد استفاده می کند.

چرا HBM برای هوش مصنوعی مناسب است؟

زیرا بسیاری از Workloadهای AI
به انتقال حجم بزرگی از داده نیاز دارند
و Memory Bandwidth بالا
می تواند به تغذیه واحدهای محاسباتی سریع کمک کند.

آیا HBM همیشه از GDDR بهتر است؟

خیر.

انتخاب حافظه
به Performance مورد نیاز،
ظرفیت،
هزینه،
توان،
Packaging
و نوع محصول بستگی دارد.

آیا HBM فقط در GPU استفاده می شود؟

خیر.

HBM می تواند در
GPUها،
AI Acceleratorها،
پردازنده های HPC
و سایر سیستم های محاسباتی
با نیاز پهنای باند بالا استفاده شود.

TSV چیست؟

Through-Silicon Via
فناوری اتصال عمودی
از میان Silicon است
که برای ارتباط میان لایه های
Stacked Memory استفاده می شود.

خلاصه فصل

  • HBM مخفف High Bandwidth Memory است.
  • HBM از چند Die حافظه به صورت Stack استفاده می کند.
  • TSV امکان ارتباط عمودی میان لایه های حافظه را فراهم می کند.
  • HBM از رابط حافظه بسیار عریض استفاده می کند.
  • GDDR بیشتر بر Signaling سریع و HBM بیشتر بر Parallelism گسترده رابط تکیه دارد.
  • HBM در AI و HPC اهمیت زیادی دارد.
  • Packaging پیشرفته یکی از دلایل هزینه و پیچیدگی بیشتر HBM است.
  • HBM2، HBM2E، HBM3، HBM3E و HBM4 از نسل های این خانواده هستند.
  • ظرفیت و Bandwidth دو مشخصه متفاوت هستند.
  • نوع حافظه به تنهایی Performance نهایی GPU را تعیین نمی کند.

سطح: مقدماتی تا متوسط

پیش نیاز:
VRAM،
GDDR،
HBM،
Memory Bandwidth

موضوع:
GPU Memory Architecture

زمان مطالعه:
حدود 8 تا 10 دقیقه


GPU MEMORY ARCHITECTURE

VRAM Capacity و Memory Bandwidth چه تفاوتی دارند؟

دو کارت گرافیک می توانند
حجم VRAM متفاوت
و پهنای باند حافظه متفاوتی داشته باشند.

این دو مشخصه
به دو سوال کاملا متفاوت پاسخ می دهند:


چقدر داده در حافظه جا می شود؟

و


داده با چه سرعتی می تواند جابه جا شود؟


پاسخ سریع

VRAM Capacity
مقدار حافظه قابل استفاده GPU را نشان می دهد
و معمولا با GB بیان می شود.

Memory Bandwidth
ظرفیت نظری انتقال داده
میان GPU و حافظه را نشان می دهد
و معمولا با GB/s بیان می شود.

ظرفیت بیشتر و Bandwidth بیشتر
هر دو می توانند مهم باشند،
اما مشکل متفاوتی را حل می کنند.

در این فصل چه چیزهایی یاد می گیریم؟

  • تفاوت Capacity و Bandwidth چیست.
  • چرا VRAM بیشتر همیشه FPS بیشتر ایجاد نمی کند.
  • چرا Bandwidth بالا کمبود ظرفیت را جبران نمی کند.
  • چه Workloadهایی بیشتر به ظرفیت حساس هستند.
  • چه Workloadهایی بیشتر به Bandwidth حساس هستند.
  • چگونه مشخصات حافظه GPU را درست مقایسه کنیم.

دو مشخصه، دو سوال متفاوت

مشخصه سوال واحد
VRAM Capacity چه مقدار داده در حافظه جا می شود؟ GB
Memory Bandwidth داده با چه نرخ نظری جابه جا می شود؟ GB/s

مثال ساده: انبار و در ورودی

VRAM را مانند یک انبار تصور کنید.


Capacity

How large is the warehouse?


Bandwidth

How much cargo
can move through the doors
per second?

یک انبار می تواند بسیار بزرگ باشد
اما در ورودی باریکی داشته باشد.

یا ممکن است انبار کوچک تر باشد
اما مسیر ورود و خروج بسیار سریعی داشته باشد.

این دو ویژگی
جای یکدیگر را نمی گیرند.

چه زمانی ظرفیت VRAM مهم تر می شود؟

ظرفیت زمانی مهم است
که Workload حجم زیادی از داده
را هم زمان در حافظه نیاز داشته باشد.

نمونه ها می توانند شامل این موارد باشند:

  • Textureهای با Resolution بالا،
  • Sceneهای پیچیده،
  • Render Targetهای بزرگ،
  • مدل های سه بعدی حجیم،
  • برخی پروژه های تولید محتوا،
  • و بعضی Workloadهای AI یا Compute.

چه زمانی Bandwidth مهم تر می شود؟

Bandwidth زمانی اهمیت بیشتری پیدا می کند
که GPU مجبور باشد
حجم زیادی از داده را
به طور پیوسته جابه جا کند.


Large Data Flow

VRAM
 │
 ▼
GPU
 │
 ▼
VRAM
 │
 ▼
GPU

در چنین Workloadهایی،
اگر واحدهای پردازشی
سریع تر از زیرسیستم حافظه
داده مصرف کنند،
Memory System می تواند
به Bottleneck تبدیل شود.

چرا VRAM بیشتر همیشه FPS را افزایش نمی دهد؟

فرض کنید یک بازی
در تنظیمات مشخص
6 GB VRAM نیاز دارد.

دو کارت داریم:


GPU A

8 GB VRAM


GPU B

16 GB VRAM

اگر هر دو ظرفیت کافی داشته باشند،
وجود 8 GB حافظه اضافه
در GPU B
به تنهایی Performance بیشتری ایجاد نمی کند.

حافظه اضافه زمانی مفید است
که Workload واقعا به آن نیاز داشته باشد.

Bandwidth بالا هم کمبود ظرفیت را حل نمی کند

فرض کنید Workload
به 12 GB داده در VRAM نیاز دارد،
اما GPU فقط 8 GB VRAM دارد.

حتی اگر Memory Bandwidth بسیار بالا باشد،
ظرفیت فیزیکی همچنان محدود است.


Required

12 GB


Available

8 GB

↓

Capacity Problem

پس:

Bandwidth سریع تر
نمی تواند داده ای را
که در VRAM جا نمی شود
ناگهان در آن جا دهد.

ظرفیت زیاد هم Bandwidth کم را حل نمی کند

حالت برعکس را تصور کنید.

GPU مقدار زیادی VRAM دارد،
اما Workload
به انتقال سریع حجم زیادی از داده نیاز دارد.


Large VRAM Capacity

████████████████████████


Memory Throughput

██████

        │
        ▼

Data Movement Bottleneck

در اینجا مشکل
فضای ذخیره سازی نیست؛
سرعت جابه جایی داده است.

دو GPU فرضی را مقایسه کنیم

مشخصه GPU A GPU B
VRAM 16 GB 12 GB
Bandwidth 400 GB/s 600 GB/s

آیا GPU A بهتر است؟

نه لزوما.

آیا GPU B بهتر است؟

باز هم نه لزوما.

GPU A ظرفیت بیشتری دارد،
در حالی که GPU B
پهنای باند بیشتری ارائه می دهد.

برنده نهایی
به Workload و کل معماری GPU بستگی دارد.

در Gaming کدام مهم تر است؟

هر دو می توانند مهم باشند.

VRAM کافی
کمک می کند Resourceهای مورد نیاز بازی
در حافظه GPU قرار بگیرند.

Bandwidth کافی
کمک می کند داده ها
با نرخ مناسبی
به واحدهای پردازشی برسند.


Gaming Performance

        │
        ├── Enough VRAM?
        │
        ├── Enough Bandwidth?
        │
        ├── GPU Compute Power?
        │
        ├── Cache?
        │
        └── Game Engine?

Resolution بالاتر چه تغییری ایجاد می کند؟

با افزایش Resolution،
تعداد Pixelهای بیشتری پردازش می شوند
و اندازه برخی Bufferها افزایش پیدا می کند.


Higher Resolution

      │

      ├── Larger Buffers
      ├── More Pixel Work
      └── More Data Movement

      │
      ▼

More Pressure
on Memory System

به همین دلیل
در Resolutionهای بالاتر
هم Capacity
و هم Bandwidth
می توانند اهمیت بیشتری پیدا کنند.

Cache چگونه این مقایسه را پیچیده تر می کند؟

دو GPU ممکن است
Memory Bandwidth خارجی متفاوتی داشته باشند،
اما معماری Cache آنها نیز متفاوت باشد.

اگر GPU بتواند
داده بیشتری را داخل Cache پاسخ دهد،
ترافیک کمتری
به VRAM می رسد.


Better Cache Reuse

      │
      ▼

Fewer VRAM Requests

      │
      ▼

Less External Bandwidth Pressure

بنابراین فقط عدد GB/s
برای مقایسه کامل
Memory System کافی نیست.

Engineering Insight — مشخصات حافظه را به صورت یک سیستم ببینید

برای تحلیل Memory System
بهتر است این موارد
کنار یکدیگر بررسی شوند:

  • VRAM Capacity،
  • Memory Type،
  • Memory Data Rate،
  • Bus Width،
  • Memory Bandwidth،
  • Cache Architecture،
  • و Workload واقعی.

یک عدد به تنهایی
معماری حافظه GPU را توضیح نمی دهد.

Performance Impact — اول Bottleneck را پیدا کنید

اگر Workload با کمبود VRAM روبه رو باشد،
ظرفیت بیشتر می تواند ارزشمند باشد.

اگر Workload Memory-Bound باشد،
Bandwidth بیشتر می تواند اهمیت بیشتری پیدا کند.

اگر Bottleneck اصلی Compute باشد،
افزایش هیچ کدام
ممکن است Performance را
به شکل بزرگی تغییر ندهد.

Common Mistakes — اشتباهات رایج
  • VRAM بیشتر را همیشه معادل FPS بیشتر ندانید.
  • Bandwidth بیشتر را همیشه معادل GPU سریع تر ندانید.
  • کمبود ظرفیت را با Bandwidth بالا قابل جبران فرض نکنید.
  • Bandwidth پایین را با VRAM زیاد قابل جبران فرض نکنید.
  • فقط یک عدد از جدول مشخصات را برای مقایسه GPU استفاده نکنید.
  • نقش Cache و Workload را نادیده نگیرید.

سوالات متداول

VRAM Capacity چیست؟

مقدار داده ای است
که حافظه GPU می تواند نگهداری کند
و معمولا با GB بیان می شود.

Memory Bandwidth چیست؟

ظرفیت نظری انتقال داده
در زیرسیستم حافظه است
و معمولا با GB/s بیان می شود.

برای Gaming VRAM مهم تر است یا Bandwidth؟

هیچ پاسخ ثابتی وجود ندارد.

اگر ظرفیت کافی نباشد،
VRAM مهم می شود.

اگر Workload توسط انتقال داده محدود باشد،
Bandwidth اهمیت بیشتری پیدا می کند.

Performance نهایی به کل GPU
و بازی بستگی دارد.

آیا 16 GB VRAM همیشه بهتر از 12 GB است؟

از نظر ظرفیت، فضای بیشتری ارائه می دهد،
اما Performance بالاتر
فقط زمانی تضمین نمی شود
که Workload به آن ظرفیت اضافه نیاز نداشته باشد.

آیا Bandwidth بیشتر برای 4K مهم است؟

Resolution بالاتر
می تواند فشار بیشتری
روی Memory System ایجاد کند،
اما تاثیر دقیق Bandwidth
به معماری GPU،
Game Engine،
Cache
و تنظیمات بستگی دارد.

خلاصه فصل

  • VRAM Capacity میزان فضای حافظه GPU را نشان می دهد.
  • Memory Bandwidth نرخ نظری انتقال داده را نشان می دهد.
  • Capacity با GB و Bandwidth با GB/s بیان می شود.
  • VRAM بیشتر همیشه FPS بیشتر ایجاد نمی کند.
  • Bandwidth بیشتر کمبود VRAM را حل نمی کند.
  • VRAM بیشتر Bandwidth پایین را حل نمی کند.
  • Resolution و Workload می توانند نیاز به هر دو را افزایش دهند.
  • Cache میزان نیاز واقعی به Bandwidth خارجی را تغییر می دهد.
  • Memory System باید به صورت یک مجموعه کامل تحلیل شود.

سطح: مقدماتی تا متوسط

پیش نیاز:
VRAM،
System RAM،
Memory Bandwidth

موضوع:
GPU Memory Architecture

زمان مطالعه:
حدود 8 تا 10 دقیقه


GPU MEMORY ARCHITECTURE

Unified Memory چیست؟

در بسیاری از سیستم ها
CPU و GPU حافظه های جداگانه ای دارند.

اما در بعضی معماری ها
یا مدل های برنامه نویسی،
CPU و GPU می توانند
به یک فضای حافظه مشترک یا یکپارچه
دسترسی داشته باشند.

این ایده
با عنوان هایی مانند
Unified Memory،
Shared Memory Architecture
یا Unified Memory Architecture
دیده می شود.


پاسخ سریع

Unified Memory
به مدلی اشاره دارد
که CPU و GPU
می توانند به یک فضای حافظه مشترک
یا یک فضای آدرس یکپارچه دسترسی داشته باشند.

اما این عبارت
در معماری ها و APIهای مختلف
معنای دقیقا یکسانی ندارد.

گاهی منظور حافظه فیزیکی مشترک است
و گاهی منظور یک مدل برنامه نویسی
برای مدیریت خودکار جابه جایی داده میان CPU و GPU است.

در این فصل چه چیزهایی یاد می گیریم؟

  • Unified Memory چیست.
  • تفاوت حافظه جداگانه و حافظه مشترک چیست.
  • چرا Unified Memory برنامه نویسی را ساده تر می کند.
  • چرا Unified Memory همیشه سریع تر نیست.
  • تفاوت Shared Physical Memory و Unified Address Space چیست.
  • چرا مدل حافظه در PC، APU و SoC می تواند متفاوت باشد.

مدل سنتی: CPU و GPU حافظه جدا دارند

در بسیاری از سیستم های دارای
Discrete GPU،
CPU و GPU
حافظه های اصلی جداگانه دارند.


CPU
 │
 ▼
System RAM


GPU
 │
 ▼
VRAM

اگر GPU به داده ای نیاز داشته باشد
که ابتدا در RAM سیستم قرار دارد،
داده باید به شکلی
در اختیار GPU قرار گیرد.


System RAM

    │

    │ Data Transfer
    ▼

   VRAM

    │

    ▼

   GPU

مشکل حافظه جداگانه چیست؟

وجود دو حافظه جدا
به این معنی است
که برنامه باید بداند
داده در کجا قرار دارد.

در بعضی مدل های برنامه نویسی،
برنامه نویس باید
به صورت صریح
داده را میان CPU و GPU
منتقل کند.


Create Data on CPU

        │
        ▼

Copy to GPU

        │
        ▼

GPU Processing

        │
        ▼

Copy Result Back

        │
        ▼

CPU Processing

این مدل کنترل زیادی می دهد،
اما مدیریت حافظه
پیچیده تر می شود.

ایده Unified Memory

هدف Unified Memory
ساده تر کردن این تصویر است.


             Shared / Unified
             Memory Space

          ┌─────────────────┐
          │                 │
CPU ◄────►│      DATA       │◄────► GPU
          │                 │
          └─────────────────┘

از دید برنامه نویس،
CPU و GPU
می توانند با مدل ساده تری
به داده دسترسی داشته باشند.

اما پشت این مدل ساده
ممکن است سخت افزار،
Driver
و Runtime
کارهای زیادی انجام دهند.

Unified Memory همیشه به معنی یک حافظه فیزیکی نیست

این نکته بسیار مهم است.

عبارت Unified Memory
ممکن است به دو حالت کلی اشاره کند.

Shared Physical Memory

CPU و GPU
از یک مجموعه حافظه فیزیکی مشترک استفاده می کنند.

Unified Programming Model

برنامه یک فضای حافظه یکپارچه می بیند،
اما سیستم ممکن است
داده را پشت صحنه
میان حافظه های مختلف جابه جا کند.

بنابراین هنگام مشاهده عبارت
Unified Memory
باید مشخص شود
دقیقا درباره کدام مدل صحبت می کنیم.

Integrated GPU چگونه از حافظه استفاده می کند؟

در بسیاری از سیستم های Integrated،
GPU حافظه اختصاصی بزرگی مانند
VRAM کارت گرافیک مجزا ندارد.

در عوض،
CPU و GPU
می توانند از System Memory
استفاده کنند.


       System Memory

┌────────────────────────┐
│                        │
│      Shared Data       │
│                        │
└────────────────────────┘
       ▲            ▲
       │            │
      CPU          GPU

این طراحی
می تواند انتقال های اضافی میان
RAM و VRAM جداگانه
را در برخی سناریوها کاهش دهد.

Unified Memory در SoCها

در System-on-Chipها،
CPU،
GPU
و سایر واحدهای پردازشی
ممکن است بسیار نزدیک به یکدیگر
در یک Package یا Chip قرار داشته باشند.


        SoC

┌──────────────────────┐
│ CPU                  │
│ GPU                  │
│ NPU                  │
│ Media Engines        │
│ Memory Controllers   │
└──────────────────────┘
          │
          ▼
     Shared Memory

در چنین معماری هایی،
استفاده از حافظه مشترک
می تواند طراحی تبادل داده
میان واحدهای مختلف را ساده تر کند.

چرا حذف Copy مهم است؟

فرض کنید CPU
یک تصویر بزرگ تولید کرده
و GPU باید آن را پردازش کند.

در مدل جداگانه:


CPU Memory

    │
    ▼

Copy

    │
    ▼

GPU Memory

    │
    ▼

GPU Processing

در مدلی که داده
واقعا قابل اشتراک باشد،
ممکن است نیاز به برخی Copyهای صریح
کاهش پیدا کند.


Shared Data

   ▲   ▲
   │   │
 CPU  GPU

این موضوع
می تواند هم برنامه نویسی را ساده تر کند
و هم در بعضی Workloadها
از انتقال داده غیرضروری جلوگیری کند.

مزیت بزرگ Unified Memory: سادگی

یکی از بزرگ ترین مزایای Unified Memory
سادگی مدیریت داده است.

به جای اینکه برنامه نویس
همیشه دو نسخه جدا
از داده را مدیریت کند:


CPU Copy

+

GPU Copy

+

Synchronization

+

Manual Transfers

مدل Unified می تواند
بخشی از این پیچیدگی
را از برنامه نویس پنهان کند.

Under the Hood — ساده برای برنامه نویس، لزوما ساده برای سخت افزار نیست

Unified Memory
ممکن است از دید برنامه نویس
مانند یک فضای حافظه واحد دیده شود.

اما زیر سیستم
ممکن است همچنان مجبور باشد:

  • محل داده را دنبال کند،
  • داده را جابه جا کند،
  • Cacheها را هماهنگ کند،
  • دسترسی CPU و GPU را مدیریت کند،
  • و وضعیت صفحات حافظه را کنترل کند.

بنابراین:

Unified Memory
پیچیدگی را لزوما حذف نمی کند؛
بخشی از آن را از برنامه نویس
به سیستم منتقل می کند.

آیا Unified Memory همیشه سریع تر است؟

خیر.

Unified Memory
در درجه اول
یک مدل معماری و مدیریت حافظه است.

Performance واقعی
به عواملی مانند این موارد بستگی دارد:

  • محل واقعی داده،
  • نوع پردازنده،
  • Memory Bandwidth،
  • Memory Latency،
  • تعداد جابه جایی های داده،
  • Cache Architecture،
  • و Access Pattern.

حافظه مشترک یعنی منابع مشترک

اگر CPU و GPU
از یک Memory System مشترک استفاده کنند،
هر دو برای بخشی از منابع حافظه
رقابت می کنند.


CPU Requests ───┐
                │
                ▼
         Shared Memory
                ▲
                │
GPU Requests ───┘

بنابراین Shared Memory Architecture
می تواند انتقال های اضافی را کاهش دهد،
اما پهنای باند موجود
همچنان یک منبع محدود است.

Discrete VRAM و Shared Memory را مقایسه کنیم

ویژگی Discrete VRAM Shared / Unified Memory
حافظه GPU اختصاصی مشترک یا یکپارچه
CPU Memory معمولا جدا ممکن است با GPU مشترک باشد
Data Copy ممکن است لازم باشد در بعضی سناریوها می تواند کاهش پیدا کند
Bandwidth وابسته به VRAM اختصاصی وابسته به Shared Memory System
سادگی مدیریت گاهی پیچیده تر می تواند ساده تر باشد

Engineering Insight — نام Unified Memory به تنهایی کافی نیست

دو سیستم ممکن است
هر دو از عبارت
Unified Memory
استفاده کنند،
اما طراحی واقعی آنها
کاملا متفاوت باشد.

برای درک یک سیستم
باید سوال های دقیق تری بپرسیم:

  • آیا حافظه فیزیکی واقعا مشترک است؟
  • آیا فقط Virtual Address Space یکپارچه است؟
  • آیا داده پشت صحنه Migration می شود؟
  • CPU و GPU چه Bandwidthی به حافظه دارند؟
  • Cache Coherency چگونه مدیریت می شود؟

Performance Impact — Unified Memory چه زمانی مفید است؟

Unified Memory
می تواند برای Workloadهایی مفید باشد
که CPU و GPU
به صورت مکرر روی داده مشترک کار می کنند.

کاهش Copyهای اضافی
و ساده تر شدن Data Sharing
می تواند مزیت مهمی باشد.

اما اگر داده
دائما مجبور به Migration
میان حافظه های مختلف باشد،
هزینه جابه جایی
می تواند بخشی از این مزیت را کاهش دهد.

برای کاربر عادی چه چیزی مهم است؟

برای مقایسه یک GPU یا سیستم،
فقط عبارت
Unified Memory
کافی نیست.

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

Total Capacity

کل حافظه قابل استفاده سیستم چقدر است؟

Memory Bandwidth

زیرسیستم حافظه با چه سرعتی داده منتقل می کند؟

GPU Access

GPU چگونه و با چه محدودیت هایی به حافظه دسترسی دارد؟

Real Performance

برنامه مورد نظر در عمل چه عملکردی دارد؟

Common Mistakes — اشتباهات رایج درباره Unified Memory
  • Unified Memory را همیشه به معنی یک حافظه فیزیکی واحد ندانید.
  • Unified Memory را همیشه سریع تر از VRAM اختصاصی فرض نکنید.
  • حافظه مشترک را به معنی پهنای باند نامحدود ندانید.
  • Unified Address Space و Shared Physical Memory را یکی ندانید.
  • سادگی برنامه نویسی را با Performance بیشتر یکی ندانید.
  • مدل حافظه یک شرکت یا API را به همه معماری ها تعمیم ندهید.

سوالات متداول درباره Unified Memory

Unified Memory چیست؟

مدلی است
که CPU و GPU
می توانند از یک فضای حافظه مشترک
یا فضای آدرس یکپارچه استفاده کنند.

جزئیات دقیق آن
به معماری و پلتفرم بستگی دارد.

آیا Unified Memory همان Shared RAM است؟

نه همیشه.

در بعضی سیستم ها
حافظه فیزیکی واقعا مشترک است،
اما در بعضی مدل ها
Unified Memory
یک لایه مدیریت حافظه و فضای آدرس یکپارچه است.

آیا Integrated GPU از RAM سیستم استفاده می کند؟

در بسیاری از طراحی های Integrated،
GPU از System Memory
برای بخشی یا تمام نیازهای حافظه خود استفاده می کند.

جزئیات دقیق
به طراحی پلتفرم بستگی دارد.

آیا Unified Memory همیشه Performance بیشتری دارد؟

خیر.

مزیت اصلی آن
می تواند ساده تر شدن مدیریت داده
و کاهش برخی انتقال های اضافی باشد.

Performance نهایی
به معماری و Workload بستگی دارد.

چرا Discrete GPU هنوز VRAM اختصاصی دارد؟

VRAM اختصاصی
می تواند زیرسیستم حافظه ای
با پهنای باند بالا
و طراحی متناسب با نیاز GPU فراهم کند.

خلاصه فصل

  • Unified Memory یک اصطلاح کلی برای مدل های حافظه یکپارچه یا مشترک است.
  • CPU و GPU می توانند فضای حافظه یا Address Space مشترک داشته باشند.
  • Unified Memory همیشه به معنی یک حافظه فیزیکی واحد نیست.
  • Integrated GPUها معمولا از System Memory استفاده می کنند.
  • حافظه مشترک می تواند برخی Copyهای اضافی را کاهش دهد.
  • Unified Memory مدیریت داده را می تواند ساده تر کند.
  • سادگی بیشتر لزوما Performance بیشتر ایجاد نمی کند.
  • CPU و GPU در حافظه مشترک می توانند برای Bandwidth رقابت کنند.
  • مدل دقیق Unified Memory به معماری و پلتفرم بستگی دارد.

سطح: مقدماتی تا متوسط

پیش نیاز:
VRAM،
Cache،
Memory Bandwidth،
Memory Latency،
Coalescing

موضوع:
GPU Memory Architecture

زمان مطالعه:
حدود 10 تا 12 دقیقه


GPU MEMORY ARCHITECTURE

Memory Bottleneck در GPU چیست و چگونه آن را تشخیص دهیم؟

گاهی GPU توان محاسباتی زیادی دارد،
اما واحدهای پردازشی
دائما منتظر داده می مانند.

در چنین شرایطی،
مشکل اصلی لزوما تعداد Shader Coreها نیست؛
ممکن است Memory System
به عامل محدودکننده Performance تبدیل شده باشد.


پاسخ سریع

Memory Bottleneck زمانی رخ می دهد
که سرعت یا نحوه دسترسی به حافظه
نتواند نیاز واحدهای پردازشی GPU را
به شکل موثری پاسخ دهد.

این محدودیت می تواند
از Bandwidth ناکافی،
Latency بالا،
Cache Miss زیاد،
دسترسی های پراکنده،
کمبود VRAM
یا الگوی نامناسب داده ایجاد شود.

در این فصل چه چیزهایی یاد می گیریم؟

  • Memory Bottleneck چیست.
  • Memory-Bound و Compute-Bound چه تفاوتی دارند.
  • چه نشانه هایی می توانند به محدودیت حافظه اشاره کنند.
  • Cache چگونه Bottleneck را کاهش می دهد.
  • چرا Access Pattern اهمیت دارد.
  • چه زمانی VRAM Capacity مشکل اصلی است.
  • چه Best Practiceهایی برای استفاده بهتر از Memory System وجود دارد.

Memory-Bound یعنی چه؟

فرض کنید GPU
واحدهای محاسباتی قدرتمندی دارد،
اما داده با سرعت کافی
به آنها نمی رسد.


Compute Units

████████████████████

        ▲
        │
Waiting for Data
        │

Memory System

████████

در این حالت،
افزایش توان محاسباتی
ممکن است تاثیر محدودی داشته باشد.

زیرا Bottleneck
در Memory System قرار دارد.

Compute-Bound چیست؟

در حالت مقابل،
ممکن است Memory System
داده کافی در اختیار GPU قرار دهد،
اما واحدهای محاسباتی
توان پردازش بیشتری نداشته باشند.


Memory System

████████████████████

        │
        ▼

Compute Units

████████

        ▲
        │
   Bottleneck

به چنین Workloadی
به صورت کلی
Compute-Bound
گفته می شود.

Memory-Bound و Compute-Bound را مقایسه کنیم

وضعیت عامل محدودکننده بهبود احتمالی
Memory-Bound Memory System کاهش Traffic،
بهبود Cache Usage،
Access Pattern بهتر،
Bandwidth بیشتر
Compute-Bound توان محاسباتی کاهش محاسبات،
استفاده بهتر از واحدهای اجرایی،
GPU قوی تر

البته Workload واقعی
ممکن است ترکیبی از چند Bottleneck باشد
و Bottleneck حتی در مراحل مختلف
تغییر کند.

رایج ترین Memory Bottleneckها

Bandwidth Pressure

حجم داده مورد نیاز
از ظرفیت موثر مسیر حافظه بیشتر است.

High Latency

Threadها مدت زیادی
منتظر آماده شدن داده می مانند.

Poor Locality

داده ها به شکل پراکنده
و با Reuse کم استفاده می شوند.

Low Cache Hit Rate

درخواست های زیادی
از Cache عبور کرده
و به سطوح دورتر حافظه می رسند.

Uncoalesced Access

Threadهای مجاور
به آدرس های نامناسب و پراکنده دسترسی دارند.

VRAM Pressure

Working Set برنامه
به ظرفیت بیشتری از VRAM نیاز دارد.

وقتی Memory Bandwidth اشباع می شود

فرض کنید GPU
در هر لحظه درخواست های زیادی
برای خواندن و نوشتن داده ایجاد کند.


Memory Requests

████████████████████████████

           │
           ▼

Available Memory Throughput

██████████████

           │
           ▼

Waiting / Queues

در این حالت
Memory Interface
به ظرفیت عملی خود نزدیک می شود
و درخواست های بیشتر
نمی توانند بلافاصله سرویس داده شوند.

Cache Miss زیاد چه اثری دارد؟

Cache
برای جلوگیری از مراجعه مکرر
به حافظه اصلی استفاده می شود.

اگر Hit Rate پایین باشد:


More Cache Misses

      │
      ▼

More L2 / VRAM Accesses

      │
      ▼

More Memory Traffic

      │
      ▼

Higher Pressure
on Memory System

بنابراین Locality مناسب
می تواند نقش بسیار مهمی
در کاهش Memory Bottleneck داشته باشد.

Best Practice اول: Threadهای مجاور، داده های مجاور

تا حد امکان،
Threadهای مجاور
را به داده های مجاور متصل کنید.


Better

T0 → A[0]
T1 → A[1]
T2 → A[2]
T3 → A[3]


Less Efficient

T0 → A[0]
T1 → A[200]
T2 → A[15]
T3 → A[900]

الگوی منظم
می تواند Coalescing،
Cache Usage
و Bandwidth Efficiency
را بهتر کند.

Best Practice دوم: داده را دوباره استفاده کنید

اگر داده ای
چند بار مورد استفاده قرار می گیرد،
بهتر است تا حد امکان
از نسخه موجود در Cache
یا Shared Memory استفاده شود.


Bad Pattern

VRAM → Use
VRAM → Use
VRAM → Use
VRAM → Use


Better Pattern

VRAM
 │
 ▼
Cache / Shared Memory
 │
 ├── Use
 ├── Use
 ├── Use
 └── Use

Best Practice سوم: داده غیرضروری منتقل نکنید

گاهی ساده ترین بهینه سازی
کاهش مقدار داده ای است
که اصلا باید از حافظه عبور کند.

برای مثال:

  • داده غیرضروری ذخیره نکنید،
  • Bufferهای موقتی بی دلیل نسازید،
  • از Formatهای مناسب استفاده کنید،
  • داده تکراری را دوباره منتقل نکنید،
  • و تا حد امکان Intermediate Data را کاهش دهید.


Less Data Movement

       │

       ▼

Less Memory Traffic

       │

       ▼

Lower Bandwidth Pressure

Best Practice چهارم: Data Layout را با Access Pattern هماهنگ کنید

ساختار داده ای که برای CPU مناسب است
الزاما برای GPU نیز بهترین انتخاب نیست.

اگر Warpها
فقط یک Attribute مشخص
از تعداد زیادی Object بخوانند،
چیدمان داده
می تواند تاثیر زیادی
روی Memory Traffic داشته باشد.

Data Layout بخشی از طراحی Performance است،
نه فقط شکل ذخیره سازی داده.

Best Practice پنجم: VRAM را فقط پر نکنید

وجود فضای خالی در VRAM
به خودی خود مشکل نیست.

هدف این نیست
که تمام VRAM همیشه پر باشد.

هدف این است
که Working Set مورد نیاز برنامه
با کمترین جابه جایی غیرضروری
در دسترس GPU باشد.


Healthy Memory Usage

Required Resources
        │
        ▼
VRAM
        │
        ▼
Stable Access


Problematic Pressure

Too Many Resources
        │
        ▼
VRAM Full
        │
        ▼
Frequent Movement / Eviction

Best Practice ششم: انتقال CPU ↔ GPU را کاهش دهید

در سیستم هایی که
CPU و GPU حافظه جداگانه دارند،
انتقال داده میان آنها
هزینه دارد.


CPU

 │
 │ Copy
 ▼

GPU

 │
 │ Copy
 ▼

CPU

 │
 │ Copy
 ▼

GPU

اگر بتوان داده را
برای مدت بیشتری
در سمت GPU نگه داشت
و چند مرحله پردازش را همانجا انجام داد،
ممکن است انتقال های اضافی کاهش پیدا کنند.

Under the Hood — Memory Performance فقط یک Bottleneck ندارد

وقتی یک برنامه
کند به نظر می رسد،
ممکن است وسوسه شویم
فقط Memory Bandwidth را مقصر بدانیم.

اما Memory Performance
از چند عامل تشکیل شده است:


Memory Performance

      │
      ├── Bandwidth
      ├── Latency
      ├── Cache Hit Rate
      ├── Access Pattern
      ├── Coalescing
      ├── VRAM Capacity
      ├── Data Reuse
      └── Memory Transfers

بهینه سازی واقعی
از پیدا کردن عامل محدودکننده
شروع می شود.

Engineering Insight — اول اندازه گیری، بعد بهینه سازی

بدون Profiling
تشخیص Bottleneck واقعی دشوار است.

گاهی برنامه نویس
زمان زیادی صرف بهینه سازی Memory Bandwidth می کند،
در حالی که برنامه
اصلا Memory-Bound نیست.

بهینه سازی خوب
از Measurement شروع می شود،
نه از حدس.

Performance Impact — یک تغییر کوچک در Memory Access می تواند اثر بزرگی داشته باشد

GPUها تعداد بسیار زیادی Thread اجرا می کنند.

بنابراین یک دسترسی حافظه نامناسب
که برای یک Thread
هزینه کمی دارد،
وقتی میلیون ها بار تکرار شود
می تواند Traffic زیادی ایجاد کند.


Small Inefficiency

      ×

Millions of Threads

      │
      ▼

Large Memory Cost

به همین دلیل
Memory Access Pattern
یکی از مهم ترین بخش های
Performance Tuning در GPU است.

یک مسیر ساده برای تشخیص مشکل


GPU Performance Low

        │
        ▼

Is Compute Fully Busy?

   │              │
  Yes            No
   │              │
   ▼              ▼

Check          Check
Compute        Memory /
Bottleneck     Stalls

                  │
                  ▼

            Memory Traffic High?

               │       │
              Yes      No
               │       │
               ▼       ▼

          Check Access  Check
          Pattern /     Latency /
          Bandwidth     Dependencies

این نمودار
یک راهنمای مفهومی است،
نه جایگزین Profiler.

Best Practices حافظه GPU

کار هدف
دسترسی متوالی Coalescing بهتر
Data Reuse کاهش VRAM Traffic
Locality بهتر Cache Hit بیشتر
Data Layout مناسب Traffic کمتر
کاهش CPU ↔ GPU Copy کاهش هزینه انتقال
کنترل VRAM Usage کاهش Memory Pressure
Profiling پیدا کردن Bottleneck واقعی

Common Mistakes — اشتباهات رایج در بهینه سازی حافظه
  • بدون Measurement فرض نکنید برنامه Memory-Bound است.
  • فقط Peak Memory Bandwidth را ملاک قرار ندهید.
  • Cache Hit Rate را بدون بررسی Access Pattern تحلیل نکنید.
  • VRAM بیشتر را راه حل همه مشکلات حافظه ندانید.
  • فقط تعداد Loadها را بررسی نکنید؛
    Memory Transaction و Traffic واقعی مهم هستند.
  • Data Layout را از Performance جدا ندانید.
  • برای افزایش Occupancy،
    Register Usage را بدون بررسی اثر جانبی کاهش ندهید.
  • انتقال های CPU و GPU را بی هزینه فرض نکنید.

سوالات متداول درباره Memory Bottleneck

Memory-Bound یعنی چه؟

یعنی Performance برنامه
بیشتر توسط Memory System
محدود شده باشد
تا توان محاسباتی GPU.

چطور بفهمیم برنامه Memory-Bound است؟

بهترین روش استفاده از Profiler
و بررسی رفتار Memory System،
Stallها،
Bandwidth Usage
و Utilization واحدهای محاسباتی است.

آیا Bandwidth بیشتر همیشه مشکل را حل می کند؟

خیر.

اگر مشکل Latency،
Access Pattern،
Cache Miss،
Compute
یا بخش دیگری باشد،
Bandwidth بیشتر
ممکن است تاثیر محدودی داشته باشد.

بهترین Access Pattern در GPU چیست؟

به صورت عمومی،
Threadهای مجاور بهتر است
تا حد امکان
به داده های مجاور و منظم دسترسی داشته باشند.

جزئیات دقیق
به معماری و Workload بستگی دارد.

آیا Cache بزرگ تر همیشه بهتر است؟

نه لزوما.

Cache زمانی مفید است
که Workload بتواند
از Locality و Data Reuse استفاده کند.

مهم ترین قانون بهینه سازی حافظه چیست؟

ابتدا Bottleneck واقعی را اندازه گیری کنید
و سپس دقیقا همان بخش را بهینه کنید.

خلاصه فصل

  • Memory Bottleneck زمانی رخ می دهد که Memory System عامل محدودکننده Performance باشد.
  • Memory-Bound و Compute-Bound دو وضعیت متفاوت هستند.
  • Bandwidth، Latency، Cache و Access Pattern همگی روی Performance حافظه اثر دارند.
  • Threadهای مجاور بهتر است به داده های مجاور دسترسی داشته باشند.
  • Data Reuse می تواند Traffic حافظه را کاهش دهد.
  • Data Layout بخشی از Performance Design است.
  • کاهش CPU ↔ GPU Transfer می تواند هزینه حافظه را کاهش دهد.
  • VRAM کافی مهم است، اما ظرفیت بیشتر همه مشکلات را حل نمی کند.
  • بهینه سازی باید بر اساس Profiling انجام شود.

سطح: جمع بندی

پیش نیاز:
تمام بخش های GPU Memory Architecture

موضوع:
GPU Memory Architecture

زمان مطالعه:
حدود 10 تا 12 دقیقه


GPU MEMORY ARCHITECTURE

جمع بندی نهایی GPU Memory Architecture

Memory System در GPU
فقط به VRAM محدود نمی شود.

از Register و Shared Memory
تا L1 و L2 Cache،
Memory Controller،
Memory Channel،
Bus Width،
Bandwidth،
Latency
و VRAM،
همه این اجزا
در کنار یکدیگر تعیین می کنند
داده با چه سرعت و چه هزینه ای
به واحدهای پردازشی برسد.


پاسخ سریع

GPU Memory Architecture
یک سلسله مراتب چندلایه از حافظه ها،
Cacheها و مسیرهای انتقال داده است.

هر سطح
بین سه عامل اصلی تعادل ایجاد می کند:


Speed،
Capacity
و Cost.

حافظه های نزدیک تر
سریع تر و کوچک تر هستند،
در حالی که حافظه های دورتر
ظرفیت بیشتری دارند
اما دسترسی به آنها پرهزینه تر است.

تصویر بزرگ Memory Hierarchy


Fastest / Smallest / Closest

Registers

   │
   ▼

Shared Memory

   │
   ▼

L1 Cache

   │
   ▼

L2 Cache

   │
   ▼

Memory Controllers

   │
   ▼

Memory Channels

   │
   ▼

Memory Interface

   │
   ▼

VRAM

Slowest / Largest / Farther

این سلسله مراتب
کمک می کند GPU
برای داده های مختلف
از سطح مناسب حافظه استفاده کند.

Registers

Registerها
نزدیک ترین حافظه
به واحدهای اجرایی هستند.

آنها برای نگهداری
داده های موقت Threadها استفاده می شوند
و دسترسی بسیار سریعی دارند.

اما ظرفیت آنها محدود است
و مصرف بیش از حد Register
می تواند تعداد Warpهای فعال
را کاهش دهد.

Shared Memory

Shared Memory
یک حافظه سریع On-Chip است
که Threadهای یک گروه
می توانند برای اشتراک داده از آن استفاده کنند.

این حافظه
برای Reuse داده،
همکاری Threadها
و کاهش مراجعه به VRAM
بسیار مفید است.

Bank Conflict
و Synchronization
دو مفهوم مهم مرتبط
با Shared Memory هستند.

L1 و L2 Cache

Cacheها
داده های پرکاربرد را
به واحدهای پردازشی نزدیک تر می کنند.

L1 معمولا نزدیک تر
و کوچک تر است،
در حالی که L2
ظرفیت و دامنه اشتراک بیشتری دارد.


Cache Hit

Data Found Nearby

      │
      ▼

Lower Access Cost


Cache Miss

Data Not Found

      │
      ▼

Go to Lower Memory Level

Locality

Cache زمانی بهترین عملکرد را دارد
که برنامه Locality خوبی داشته باشد.

نوع ایده
Spatial Locality داده های نزدیک
احتمالا با هم استفاده می شوند.
Temporal Locality داده ای که اخیرا استفاده شده
ممکن است دوباره استفاده شود.

Cache Line، Mapping و Replacement

Cache داده را
معمولا به صورت بلوک هایی
به نام Cache Line نگه می دارد.

هر داده
نمی تواند لزوما
در هر نقطه Cache قرار بگیرد.

Mapping و Associativity
مشخص می کنند
داده در کدام بخش Cache
اجازه قرار گرفتن دارد.

وقتی Cache پر شود،
Replacement Policy
مشخص می کند
کدام Line جای خود را
به داده جدید بدهد.

Memory Controller و Memory Channel

Memory Controller
در مدیریت درخواست های حافظه
و ارتباط با Memory System
نقش دارد.

Memory Channelها
امکان ایجاد Parallelism بیشتر
در انتقال داده را فراهم می کنند.


Memory Requests

       │
       ▼

Memory Controllers

       │
       ▼

Memory Channels

   ┌───┼───┐
   │   │   │
   ▼   ▼   ▼

  CH0 CH1 CH2

Memory Bus Width

Bus Width
عرض رابط انتقال داده حافظه
را بیان می کند.

اعدادی مانند:


64-bit

128-bit

192-bit

256-bit

384-bit

نشان می دهند
رابط حافظه
در مجموع چند Bit داده
را به صورت موازی حمل می کند.

Bus Width بیشتر
به تنهایی
Performance بیشتر را تضمین نمی کند.

Memory Bandwidth

Memory Bandwidth
ظرفیت نظری انتقال داده
در واحد زمان را نشان می دهد.


Bandwidth

=

Data Rate × Bus Width
─────────────────────
         8

واحد رایج:


GB/s

اما Bandwidth نظری
با Performance واقعی
یکسان نیست.

Memory Latency

Latency
مدت زمان رسیدن
از Memory Request
به Data Ready
را بیان می کند.

Bandwidth و Latency
دو مفهوم متفاوت هستند.


Bandwidth

How much data per second?


Latency

How long for one request?

GPU برای پنهان کردن Latency
از Threadها و Warpهای متعدد
استفاده می کند.

Memory Coalescing و Transaction

Threadهای یک Warp
اگر به آدرس های مجاور
دسترسی داشته باشند،
می توانند از Memory System
موثرتر استفاده کنند.


Good

T0 → A[0]
T1 → A[1]
T2 → A[2]
T3 → A[3]


Poor

T0 → A[0]
T1 → A[100]
T2 → A[900]
T3 → A[17]

درخواست منطقی Thread
و Memory Transaction واقعی
یک مفهوم نیستند.

الگوی Access
تعیین می کند
چه مقدار Traffic واقعی ایجاد شود.

Memory Alignment

Alignment مناسب
کمک می کند داده
نسبت به مرزهای مناسب حافظه
در موقعیت درستی قرار گیرد.

Misalignment
می تواند Transactionهای اضافی
یا دسترسی نامناسب ایجاد کند.

Padding،
Structure Layout
و Data Alignment
باید در طراحی Data Structure
در نظر گرفته شوند.

VRAM

VRAM
حافظه اصلی با ظرفیت بالای GPU است.

داده هایی مانند:

  • Textures،
  • Geometry،
  • Render Targets،
  • Depth Buffers،
  • و Compute Data

می توانند در VRAM قرار بگیرند.

ظرفیت بیشتر
فضای بیشتری برای داده فراهم می کند،
اما به تنهایی
GPU را سریع تر نمی کند.

GDDR و HBM

فناوری ویژگی کلی
GDDR حافظه گرافیکی پرسرعت
با استفاده گسترده در کارت های گرافیک
HBM حافظه Stacked
با رابط بسیار عریض
و پهنای باند بالا

هیچ کدام
به صورت مطلق
«بهتر» نیستند.

انتخاب فناوری حافظه
به نوع محصول،
هزینه،
ظرفیت
و نیاز Bandwidth بستگی دارد.

Capacity و Bandwidth را هیچ وقت یکی ندانید

مشخصه معنا واحد
Capacity چه مقدار داده جا می شود؟ GB
Bandwidth داده با چه نرخ نظری منتقل می شود؟ GB/s

Unified Memory

در بعضی معماری ها
CPU و GPU
می توانند از حافظه فیزیکی مشترک
یا فضای آدرس یکپارچه استفاده کنند.

این مدل
می تواند مدیریت داده را ساده تر کند
و برخی Copyهای اضافی را کاهش دهد.

اما Unified Memory
لزوما به معنی
Performance بیشتر نیست.

مدل ساده Performance حافظه


Memory Performance

      │
      ├── Capacity
      ├── Bandwidth
      ├── Latency
      ├── Cache Hit Rate
      ├── Locality
      ├── Coalescing
      ├── Alignment
      ├── Data Layout
      └── Workload

هیچ کدام از این عوامل
به تنهایی
Performance کامل Memory System
را توضیح نمی دهند.

Under the Hood — چرا Memory Hierarchy چند سطح دارد؟

اگر می شد
یک حافظه ساخت که هم:

  • به سرعت Register باشد،
  • به اندازه VRAM ظرفیت داشته باشد،
  • انرژی کمی مصرف کند،
  • و بسیار ارزان باشد،

نیازی به Memory Hierarchy نبود.

اما چنین حافظه ای وجود ندارد.

بنابراین معماری GPU
چند سطح حافظه می سازد
تا میان:


Speed

Capacity

Cost

Power

Area

تعادل برقرار کند.

Engineering Insight — سریع ترین Memory Access همان Accessی است که انجام نمی شود

یکی از مهم ترین اصول
Performance Engineering این فصل
کاهش Data Movement است.

اگر بتوانیم:

  • داده را Reuse کنیم،
  • از Cache استفاده کنیم،
  • Traffic اضافی را حذف کنیم،
  • Data Layout را بهتر کنیم،
  • و Copyهای غیرضروری را کاهش دهیم،

فشار روی Memory System
کمتر می شود.

بهینه سازی حافظه
اغلب درباره سریع تر منتقل کردن داده نیست؛
درباره منتقل نکردن داده غیرضروری است.

Performance Impact — Memory-Bound یا Compute-Bound؟

اگر GPU
بیشتر زمان خود را
منتظر داده بگذراند،
Workload می تواند
Memory-Bound باشد.

اگر Memory System
داده کافی فراهم کند
اما واحدهای محاسباتی
در حداکثر توان خود باشند،
Workload می تواند
Compute-Bound باشد.

تشخیص این تفاوت
برای Optimization بسیار مهم است.

Common Mistakes — اشتباهات نهایی این فصل
  • VRAM بیشتر را همیشه معادل GPU سریع تر ندانید.
  • Bus Width بیشتر را همیشه معادل Bandwidth بیشتر ندانید.
  • Bandwidth بیشتر را همیشه معادل Latency کمتر ندانید.
  • Memory Clock را بدون بررسی واحد با Data Rate یکی ندانید.
  • Cache Hit و Coalescing را یک مفهوم فرض نکنید.
  • Thread Load و Memory Transaction را یکی ندانید.
  • Unified Memory را همیشه حافظه فیزیکی مشترک فرض نکنید.
  • بدون Profiling فرض نکنید Workload Memory-Bound است.
  • یک مشخصه حافظه را جدا از کل GPU تحلیل نکنید.

بعد از این فصل باید بتوانید…

  • Memory Hierarchy GPU را از Register تا VRAM توضیح دهید.
  • Register و Shared Memory را از Cache تفکیک کنید.
  • L1 و L2 Cache را مقایسه کنید.
  • Cache Hit و Cache Miss را توضیح دهید.
  • Spatial و Temporal Locality را تشخیص دهید.
  • Memory Controller و Channel را از Bus Width جدا کنید.
  • Memory Bandwidth را از روی Data Rate و Bus Width محاسبه کنید.
  • Latency و Bandwidth را از یکدیگر تفکیک کنید.
  • Memory Coalescing را توضیح دهید.
  • VRAM Capacity و Bandwidth را اشتباه نگیرید.
  • GDDR و HBM را در سطح معماری مقایسه کنید.
  • Memory-Bound و Compute-Bound را از نظر مفهومی تشخیص دهید.

سوالات متداول GPU Memory Architecture

سریع ترین حافظه GPU چیست؟

در مدل مفهومی این فصل،
Registerها نزدیک ترین
و سریع ترین محل نگهداری داده
برای Threadها هستند.

جزئیات دقیق
به معماری GPU بستگی دارد.

چرا GPU فقط از VRAM استفاده نمی کند؟

زیرا VRAM
ظرفیت زیادی دارد
اما دسترسی به آن
نسبت به منابع On-Chip
پرهزینه تر است.

Cache،
Register
و Shared Memory
برای کاهش این هزینه استفاده می شوند.

VRAM بیشتر بهتر است یا Bandwidth بیشتر؟

این دو مشخصه
مشکل متفاوتی را حل می کنند.

Capacity
فضای ذخیره سازی را تعیین می کند
و Bandwidth
نرخ انتقال داده را.

انتخاب مهم تر
به Workload بستگی دارد.

GDDR بهتر است یا HBM؟

هیچ پاسخ مطلقی وجود ندارد.

GDDR و HBM
Trade-offهای متفاوتی
از نظر Cost،
Bandwidth،
Packaging
و نوع محصول دارند.

Memory-Bound یعنی چه؟

یعنی Memory System
عامل اصلی محدودکننده Performance
Workload باشد.

مهم ترین قانون Performance حافظه GPU چیست؟

داده را تا حد امکان
با Locality مناسب،
Reuse بالا
و Traffic کمتر
در اختیار GPU قرار دهید
و Bottleneck واقعی را
با Profiling مشخص کنید.

خلاصه نهایی GPU Memory Architecture

معماری حافظه GPU
یک زنجیره ساده
از «GPU به VRAM» نیست.

این سیستم
از چند سطح حافظه،
Cache،
Controller،
Channel
و Interface تشکیل شده است.

هدف تمام این طراحی
این است که تعداد بسیار زیادی واحد پردازشی
بتوانند با کمترین زمان انتظار ممکن
به داده مورد نیاز دسترسی پیدا کنند.

  • Register سریع و کوچک است.
  • Shared Memory برای همکاری Threadها مفید است.
  • Cache داده های پرکاربرد را نزدیک نگه می دارد.
  • L2 ترافیک حافظه اصلی را کاهش می دهد.
  • Memory Controller درخواست ها را مدیریت می کند.
  • Memory Channel امکان Parallelism در حافظه را فراهم می کند.
  • Bus Width عرض رابط داده را مشخص می کند.
  • Bandwidth نرخ انتقال داده را بیان می کند.
  • Latency زمان پاسخ یک درخواست را بیان می کند.
  • Coalescing استفاده از Transactionها را موثرتر می کند.
  • VRAM ظرفیت اصلی داده GPU را فراهم می کند.
  • GDDR و HBM دو رویکرد مهم برای ساخت حافظه GPU هستند.
  • Performance نهایی حاصل تعامل تمام این اجزا با Workload است.

سطح: مقدماتی تا متوسط

پیش نیاز:
GPU Core Architecture،
GPU Memory Architecture

موضوع:
GPU Execution Architecture

زمان مطالعه:
حدود 10 تا 12 دقیقه


GPU EXECUTION ARCHITECTURE

GPU چگونه هزاران Thread را اجرا می کند؟

قدرت GPU فقط از داشتن تعداد زیادی واحد محاسباتی نمی آید.

نکته مهم تر این است که
GPU چگونه حجم بسیار بزرگی از Threadها را
گروه بندی،
زمان بندی
و روی سخت افزار اجرا می کند.

برای فهم این فرایند
باید ارتباط میان
Thread،
Warp یا Wavefront،
Workgroup،
Scheduler
و واحدهای اجرایی را بشناسیم.


پاسخ سریع

GPU تعداد بسیار زیادی Thread را
به صورت گروه های اجرایی مدیریت می کند.

Threadها به تنهایی و کاملا مستقل
روی سخت افزار زمان بندی نمی شوند؛
بلکه گروه هایی از Threadها
به صورت هماهنگ اجرا می شوند.

در معماری NVIDIA
این گروه معمولا
Warp
نامیده می شود.

در معماری AMD
اصطلاح
Wavefront
رایج است.

در این بخش چه چیزهایی یاد می گیریم؟

  • Thread در GPU چیست.
  • چرا GPU Threadها را گروه بندی می کند.
  • Warp و Wavefront چیست.
  • Workgroup یا Thread Block چه نقشی دارد.
  • Scheduler چگونه گروه های آماده را انتخاب می کند.
  • SIMT چیست.
  • Branch Divergence چگونه ایجاد می شود.
  • Occupancy چه معنایی دارد.
  • چرا داشتن Threadهای زیاد برای GPU مفید است.

CPU و GPU چه تفاوتی در اجرای برنامه دارند؟

CPU معمولا برای اجرای تعداد کمتری
Thread پیچیده
با Latency پایین طراحی شده است.

GPU در مقابل
برای اجرای تعداد بسیار زیادی
Thread مشابه
به صورت موازی طراحی شده است.


CPU

Thread
Thread
Thread
Thread

Complex / Powerful Cores


GPU

Thread Thread Thread Thread Thread Thread
Thread Thread Thread Thread Thread Thread
Thread Thread Thread Thread Thread Thread
Thread Thread Thread Thread Thread Thread

Massive Parallel Execution

Thread چیست؟

Thread
یک نمونه اجرایی از برنامه یا Shader است.

برای مثال،
در یک Compute Shader
ممکن است هر Thread
روی یک عنصر از Array کار کند.


Thread 0 → Data 0

Thread 1 → Data 1

Thread 2 → Data 2

Thread 3 → Data 3

همه Threadها
می توانند همان کد را اجرا کنند،
اما روی داده های متفاوت.

چرا GPU هزاران Thread ایجاد می کند؟

یکی از مهم ترین ایده های معماری GPU
این است که همیشه
کارهای زیادی برای اجرا آماده باشند.

اگر یک گروه Thread
منتظر حافظه باشد،
GPU می تواند گروه دیگری را اجرا کند.


Group A

Waiting for Memory

        │

        ▼

Scheduler

        │

        ▼

Group B

Ready to Execute

وجود Threadهای زیاد
به GPU کمک می کند
زمان های انتظار را بهتر پنهان کند.

GPU Threadها را به صورت گروهی اجرا می کند

اگر GPU
هر Thread را کاملا مستقل
مدیریت می کرد،
سخت افزار Scheduling
بسیار پیچیده می شد.

به همین دلیل
Threadها در گروه های کوچکتر
سازمان دهی می شوند.


Threads

T0 T1 T2 T3 T4 T5 T6 T7
T8 T9 T10 T11 T12 T13 T14 T15
...

        │
        ▼

Execution Groups

Group 0
Group 1
Group 2
...

Warp چیست؟


Warp

در معماری NVIDIA،
Warp گروه اصلی Threadهایی است
که Scheduler آنها را
برای اجرا مدیریت می کند.

در CUDA،
یک Warp از
32 Thread
تشکیل می شود.


One NVIDIA Warp

T00 T01 T02 T03 T04 T05 T06 T07
T08 T09 T10 T11 T12 T13 T14 T15
T16 T17 T18 T19 T20 T21 T22 T23
T24 T25 T26 T27 T28 T29 T30 T31

= 32 Threads

Wavefront چیست؟

AMD برای مفهوم مشابه
از اصطلاح
Wavefront
استفاده می کند.

بسته به معماری و حالت اجرا،
اندازه Wave
می تواند متفاوت باشد.


NVIDIA

Warp


AMD

Wavefront / Wave

مفهوم اصلی مشابه است:

تعدادی Thread
به صورت یک گروه اجرایی
توسط سخت افزار مدیریت می شوند.

SIMT چیست؟

یکی از مفاهیم مهم GPU

Single Instruction, Multiple Threads

یا
SIMT
است.

ایده ساده است:

Threadهای زیادی
یک جریان دستور مشابه را اجرا می کنند،
اما هر Thread
داده و State مخصوص خود را دارد.


Same Instruction

       │
       ▼

T0 → Data A

T1 → Data B

T2 → Data C

T3 → Data D

یک مثال ساده

فرض کنید Shader
این عملیات را انجام دهد:


output[i] = input[i] * 2.0f;

Threadهای مختلف
همان دستور را
روی Elementهای متفاوت اجرا می کنند.


Thread 0

output[0] = input[0] * 2


Thread 1

output[1] = input[1] * 2


Thread 2

output[2] = input[2] * 2


Thread 3

output[3] = input[3] * 2

این نوع Parallelism
برای GPU بسیار مناسب است.

Thread Block یا Workgroup چیست؟

Threadها فقط در Warp یا Wave
گروه بندی نمی شوند.

برنامه نویس نیز
Threadها را در گروه های بزرگ تری
سازمان دهی می کند.

محیط اصطلاح رایج
CUDA Thread Block
OpenCL Workgroup
DirectX / Vulkan / Compute Thread Group / Workgroup

یک Thread Block چگونه روی سخت افزار اجرا می شود؟

فرض کنید یک CUDA Block
شامل 128 Thread باشد.

از آنجا که Warp
32 Thread دارد:


128 Threads

÷

32 Threads per Warp

=

4 Warps

بنابراین Block
به چند Warp تقسیم می شود
و Scheduler آنها را
برای اجرا مدیریت می کند.

Warp Scheduler چه کاری انجام می دهد؟

در هر لحظه
ممکن است چند Warp
روی یک بخش پردازشی GPU
آماده اجرا باشند.


Warp A → Ready

Warp B → Waiting for Memory

Warp C → Ready

Warp D → Waiting


        │

        ▼

    Scheduler

        │

        ▼

Choose Ready Work

Scheduler
از میان Warpهای آماده
کار مناسب را
برای اجرا انتخاب می کند.

Under the Hood — چرا Context Switching در GPU مفید است؟

GPU معمولا State مربوط به Threadهای فعال
را روی منابع On-Chip نگه می دارد.

به همین دلیل
جابه جایی میان Warpهای آماده
می تواند بسیار سریع انجام شود.


Warp A

Waiting

   │

   ▼

Warp B

Execute

   │

   ▼

Warp C

Execute

این توانایی
یکی از پایه های
Latency Hiding در GPU است.

اگر Threadهای یک Warp مسیرهای متفاوت بروند چه؟

فرض کنید Shader چنین شرطی داشته باشد:


if (value > 0)
{
    pathA();
}
else
{
    pathB();
}

اگر همه Threadهای یک Warp
یک مسیر را انتخاب کنند،
اجرای گروهی ساده است.


T0 → A
T1 → A
T2 → A
T3 → A

Good Agreement

اما اگر برخی Threadها
Path A
و بقیه
Path B
را انتخاب کنند:


T0 → A
T1 → B
T2 → A
T3 → B

Branch Divergence
ایجاد می شود.

Branch Divergence چرا می تواند Performance را کاهش دهد؟

Threadهای یک گروه اجرایی
بهترین عملکرد را زمانی دارند
که مسیر دستور مشابهی را دنبال کنند.

اگر گروه به چند مسیر تقسیم شود،
سخت افزار باید
مسیرهای لازم را مدیریت کند.


Warp

      │

 ┌────┴────┐

Path A   Path B

   │        │
   ▼        ▼

Execute Required Paths

      │

      ▼

Continue Together

در فصل بعد
Branch Divergence
را جداگانه بررسی خواهیم کرد.

Occupancy چیست؟

هر واحد پردازشی GPU
می تواند تعداد محدودی
Warp یا Wave
را هم زمان Resident نگه دارد.

Occupancy
به میزان استفاده از این ظرفیت
اشاره می کند.


Execution Unit Capacity

[Warp]
[Warp]
[Warp]
[Warp]
[Warp]
[Warp]
[Warp]
[Warp]


Resident

[Warp]
[Warp]
[Warp]
[Warp]

Warpهای Resident بیشتر
می توانند گزینه های بیشتری
برای Scheduler فراهم کنند.

Occupancy بیشتر همیشه بهتر نیست

Occupancy بالا
می تواند برای Latency Hiding مفید باشد،
اما هدف نهایی
بیشترین Occupancy ممکن نیست.

Performance به عوامل دیگری نیز وابسته است:

  • Register Usage،
  • Shared Memory Usage،
  • Instruction Mix،
  • Memory Access،
  • Branch Divergence،
  • و نوع Workload.

Occupancy یک ابزار برای Performance است،
نه خود Performance.

Register و Shared Memory دوباره وارد داستان می شوند

هر Thread به Register نیاز دارد
و هر Workgroup ممکن است
Shared Memory مصرف کند.

این منابع محدود هستند.


More Registers per Thread

        │
        ▼

Fewer Threads / Warps
may fit simultaneously


More Shared Memory per Block

        │
        ▼

Fewer Blocks
may fit simultaneously

اینجا می بینیم
چرا Memory Architecture
و Execution Architecture
از یکدیگر جدا نیستند.

Performance Impact — GPU به کار آماده نیاز دارد

اگر تعداد کافی Warp آماده وجود داشته باشد،
Scheduler می تواند
بخشی از Stallهای حافظه یا اجرای دستور را
با کار مفید دیگر پوشش دهد.

اما اگر اکثر Warpها هم زمان
منتظر یک منبع باشند،
واحدهای اجرایی ممکن است
کمتر مورد استفاده قرار گیرند.


Many Ready Warps

      │
      ▼

More Scheduling Choices

      │
      ▼

Better Chance
to Keep Hardware Busy

Common Mistakes — اشتباهات رایج درباره اجرای GPU
  • تصور نکنید هر Thread کاملا مستقل روی یک Core جدا اجرا می شود.
  • Thread Block را با Warp یکی ندانید.
  • Warp و Wavefront را نام دقیق یک ساختار مشترک در همه GPUها فرض نکنید.
  • Branch زیاد را همیشه بد ندانید؛
    Divergence داخل یک گروه اجرایی مهم است.
  • Occupancy بالا را همیشه معادل FPS یا Performance بالاتر ندانید.
  • تعداد زیاد Threadها را فقط افزایش کار ندانید؛
    آنها برای Latency Hiding نیز مهم هستند.
  • Register و Shared Memory را از Execution Scheduling جدا تحلیل نکنید.

سلسله مراتب اجرای GPU


Application / Dispatch

        │
        ▼

Grid / Dispatch

        │
        ▼

Thread Blocks / Workgroups

        │
        ▼

Warps / Waves

        │
        ▼

Threads

        │
        ▼

Instructions

        │
        ▼

Execution Units

این مدل
پایه بسیاری از مباحث بعدی
در معماری GPU است.

سوالات متداول درباره GPU Execution

Warp چیست؟

Warp گروه اجرایی Threadها
در معماری NVIDIA است.

در CUDA
هر Warp شامل 32 Thread است.

Wavefront چیست؟

اصطلاحی است
که AMD برای گروه های اجرایی Threadها
استفاده می کند.

اندازه دقیق Wave
می تواند به معماری و حالت اجرا وابسته باشد.

SIMT چیست؟

مدل Single Instruction, Multiple Threads
است که در آن
Threadهای متعدد
دستورهای مشابهی را
روی داده های متفاوت اجرا می کنند.

آیا هر Thread یک GPU Core دارد؟

خیر.

GPU تعداد بسیار بیشتری Thread
از واحدهای اجرایی فیزیکی دارد
و سخت افزار آنها را
در طول زمان زمان بندی می کند.

Occupancy چیست؟

به میزان استفاده از ظرفیت
Warp یا Threadهای Resident
روی واحد پردازشی اشاره دارد.

Occupancy بالا می تواند مفید باشد،
اما به تنهایی Performance را تعیین نمی کند.

Branch Divergence چیست؟

زمانی رخ می دهد
که Threadهای یک گروه اجرایی
در Branchهای مختلف
مسیرهای متفاوتی را دنبال کنند.

خلاصه فصل

  • GPU برای اجرای تعداد بسیار زیادی Thread طراحی شده است.
  • Threadها روی سخت افزار به صورت گروهی مدیریت می شوند.
  • NVIDIA از Warp و AMD از Wavefront یا Wave استفاده می کند.
  • یک Warp CUDA شامل 32 Thread است.
  • SIMT اجازه می دهد Threadهای متعدد دستور مشابه را روی داده های متفاوت اجرا کنند.
  • Thread Block یا Workgroup شامل چندین گروه اجرایی است.
  • Scheduler از میان Warpها یا Waveهای آماده، کار قابل اجرا را انتخاب می کند.
  • Threadهای زیاد به Latency Hiding کمک می کنند.
  • Branch Divergence می تواند بهره وری اجرای گروهی را کاهش دهد.
  • Occupancy تعداد کارهای Resident را توصیف می کند، اما به تنهایی معیار Performance نیست.
  • Register و Shared Memory می توانند تعداد Threadها و Warpهای Resident را محدود کنند.

سطح: مقدماتی تا متوسط

پیش نیاز:
Thread،
Warp / Wavefront،
SIMT،
GPU Scheduler

موضوع:
GPU Execution Architecture

زمان مطالعه:
حدود 10 تا 12 دقیقه


GPU EXECUTION ARCHITECTURE

Branch Divergence در GPU چیست؟

GPU زمانی بهترین بهره وری را دارد
که Threadهای یک Warp یا Wave
مسیر اجرایی مشابهی را دنبال کنند.

اگر بخشی از Threadها
یک Branch
و بخش دیگری مسیر متفاوتی را انتخاب کنند،
گروه اجرایی دچار
Branch Divergence
می شود.


پاسخ سریع

Branch Divergence زمانی رخ می دهد
که Threadهای یک گروه اجرایی
در یک شرط یا Branch
مسیرهای متفاوتی را انتخاب کنند.

در این شرایط،
سخت افزار باید اجرای مسیرهای لازم
را به گونه ای مدیریت کند
که نتیجه تمام Threadها صحیح باقی بماند.

هرچه مسیرهای Threadهای یک گروه
هماهنگ تر باشند،
اجرای SIMT معمولا بهره وری بیشتری دارد.

در این فصل چه چیزهایی یاد می گیریم؟

  • Branch Divergence چیست.
  • چرا Divergence داخل Warp یا Wave اهمیت دارد.
  • چرا وجود Branch به تنهایی مشکل نیست.
  • Uniform Branch چیست.
  • Divergent Branch چیست.
  • چرا بعضی Branchها تقریبا رایگان و بعضی پرهزینه هستند.
  • Loop Divergence چیست.
  • چگونه Data Layout و Thread Mapping روی Divergence اثر می گذارند.
  • چه Best Practiceهایی برای کاهش Divergence وجود دارد.

یک Branch ساده

این کد را در نظر بگیرید:


if (value > 0.0f)
{
    result = value * 2.0f;
}
else
{
    result = 0.0f;
}

هر Thread
مقدار مخصوص خود را دارد.

اگر همه Threadهای یک Warp
شرط را True ببینند:


T0 → TRUE
T1 → TRUE
T2 → TRUE
T3 → TRUE
T4 → TRUE
T5 → TRUE

        │
        ▼

All Threads
Execute Same Path

Branch وجود دارد،
اما Divergence رخ نداده است.

Uniform Branch چیست؟


Uniform Branch

شرطی است که Threadهای یک گروه اجرایی
برای آن نتیجه یکسانی می گیرند.


Warp

T0  ─► Path A
T1  ─► Path A
T2  ─► Path A
T3  ─► Path A
T4  ─► Path A
T5  ─► Path A

No Path Split

از دید اجرای گروهی،
این حالت مطلوب است.

Divergent Branch چگونه ایجاد می شود؟

حالا فرض کنید
Threadها نتایج متفاوتی بگیرند:


T0 → Path A
T1 → Path B
T2 → Path A
T3 → Path B
T4 → Path A
T5 → Path B

گروه اجرایی دیگر
نمی تواند تمام Threadها را
روی یک مسیر یکسان جلو ببرد.


Warp

        │

   ┌────┴────┐

   ▼         ▼

 Path A    Path B

   │         │

   └────┬────┘

        ▼

 Continue

این وضعیت
Branch Divergence نام دارد.

چرا Divergence می تواند Performance را کاهش دهد؟

وقتی Threadها
مسیرهای متفاوتی دارند،
همه Laneهای اجرایی
لزوما در هر لحظه
کار مفید انجام نمی دهند.


Execute Path A

T0  ACTIVE
T1  INACTIVE
T2  ACTIVE
T3  INACTIVE


Then Execute Path B

T0  INACTIVE
T1  ACTIVE
T2  INACTIVE
T3  ACTIVE

در نتیجه،
بخشی از ظرفیت گروه اجرایی
در هر مسیر
ممکن است بلااستفاده بماند.

وجود if همیشه بد نیست

یکی از اشتباهات رایج
این است که تصور کنیم
هر
if
در Shader
Performance را خراب می کند.

مشکل اصلی
وجود Branch نیست.

مسئله مهم این است:

آیا Threadهای یک Warp یا Wave
در Branch
تصمیم متفاوتی می گیرند؟

اگر تمام Threadها
یک مسیر را انتخاب کنند،
Branch می تواند Uniform باشد
و Divergence ایجاد نکند.

Branch وابسته به داده

Divergence اغلب زمانی ایجاد می شود
که شرط
به داده متفاوت هر Thread وابسته باشد.


if (particle.temperature > threshold)
{
    coolParticle();
}
else
{
    heatParticle();
}

چون Particleهای مختلف
ممکن است Temperature متفاوتی داشته باشند،
Threadهای یک گروه اجرایی
می توانند به مسیرهای مختلف تقسیم شوند.

Branch بر اساس Thread ID

این الگو را در نظر بگیرید:


if ((threadIndex % 2) == 0)
{
    pathA();
}
else
{
    pathB();
}

Threadهای زوج
Path A
و Threadهای فرد
Path B
را انتخاب می کنند.


T0 → A
T1 → B
T2 → A
T3 → B
T4 → A
T5 → B
T6 → A
T7 → B

این الگو
برای اجرای گروهی
بسیار Divergent است.

همان کار، اما با Thread Mapping بهتر

فرض کنید بتوانیم
کارها را طوری گروه بندی کنیم
که Threadهای مجاور
مسیر مشابهی داشته باشند.


Group 0

T0 → A
T1 → A
T2 → A
T3 → A


Group 1

T4 → B
T5 → B
T6 → B
T7 → B

اگر این گروه بندی
با مرزهای گروه اجرایی
هماهنگ باشد،
Divergence می تواند کاهش پیدا کند.

Branch کوتاه و Branch بلند یکسان نیستند

اگر دو مسیر
فقط یک یا دو Instruction کوتاه داشته باشند،
هزینه Divergence
ممکن است محدود باشد.

اما اگر هر مسیر
صدها Instruction انجام دهد:


Path A

████████████████████████


Path B

████████████████████████

اجرای مسیرهای جداگانه
هزینه بیشتری ایجاد می کند.

بنابراین فقط وجود Divergence
مهم نیست؛
مقدار کاری که در مسیرهای متفاوت انجام می شود
نیز مهم است.

Under the Hood — Masked Execution

یک مدل ساده برای فهم Divergence
استفاده از Active Mask است.

در هر مسیر،
فقط Threadهایی که باید
آن مسیر را اجرا کنند
فعال در نظر گرفته می شوند.


Original Warp

T0 T1 T2 T3 T4 T5 T6 T7


Path A Mask

1  0  1  0  1  0  1  0


Path B Mask

0  1  0  1  0  1  0  1

جزئیات اجرای Branch
میان معماری ها متفاوت است،
اما این مدل
برای فهم اینکه چرا
Laneهای غیرفعال
کار مفیدی انجام نمی دهند
مناسب است.

Divergence فقط در if رخ نمی دهد

Loop نیز می تواند
رفتار Divergent ایجاد کند.


for (int i = 0; i < iterationCount[threadIndex]; ++i)
{
    process();
}

اگر Threadهای مختلف
تعداد Iteration متفاوتی داشته باشند:


T0 → 2 iterations

T1 → 10 iterations

T2 → 4 iterations

T3 → 20 iterations

برخی Threadها زودتر تمام می شوند
و تا پایان Threadهای دیگر
کار کمتری برای انجام دارند.

Early Exit

گاهی بعضی Threadها
خیلی زود از Shader خارج می شوند.


if (!visible)
{
    return;
}

performExpensiveWork();

این کار می تواند مفید باشد،
زیرا Threadهای غیرضروری
کار اضافی انجام نمی دهند.

اما اگر Threadهای یک Warp
به شکل نامنظم
بین Exit و Continue تقسیم شوند،
باید اثر Divergence نیز در نظر گرفته شود.

Early Exit نه همیشه خوب است
و نه همیشه بد؛
نتیجه به مقدار کاری که حذف می شود
و الگوی Threadها بستگی دارد.

Divergence می تواند روی Memory Access هم اثر بگذارد

اگر مسیرهای مختلف
به داده های متفاوتی دسترسی داشته باشند،
Divergence ممکن است
با Access Pattern نامناسب
ترکیب شود.


Path A

Threads → Region A


Path B

Threads → Region B


Result

Different Execution Paths
+
Different Memory Paths

بنابراین Branch Behavior
و Memory Behavior
گاهی باید با هم تحلیل شوند.

گاهی Compiler Branch را به شکل دیگری اجرا می کند

برای Branchهای بسیار کوتاه،
Compiler ممکن است
به جای Jump کامل
از تکنیک هایی مانند
Predicated Execution
استفاده کند.


Condition

   │
   ▼

Instruction A
enabled for some lanes


Instruction B
enabled for other lanes

این موضوع یکی از دلایلی است
که نباید فقط با دیدن
if
در Source Code
درباره Performance نتیجه گیری کرد.

Engineering Insight — Branch را حذف نکنید؛ Divergence پرهزینه را حذف کنید

تبدیل کورکورانه تمام Branchها
به محاسبات بدون شرط
می تواند تعداد Instructionها را افزایش دهد.

در برخی شرایط،
یک Branch Uniform
بسیار ارزان تر
از انجام محاسبه غیرضروری
برای تمام Threadها است.

هدف Optimization
کم کردن تعداد ifها نیست؛
هدف کم کردن کار غیرضروری است.

Best Practice: داده های مشابه را کنار هم قرار دهید

اگر بتوان Work Itemهای مشابه
را کنار یکدیگر قرار داد،
احتمال اینکه Threadهای یک گروه اجرایی
مسیر مشابهی بروند
بیشتر می شود.


Before

A B A B A B A B


After Grouping

A A A A B B B B

البته Sorting یا Grouping
خودش هزینه دارد.

بنابراین این روش
زمانی منطقی است
که سود آن
از هزینه سازمان دهی داده بیشتر باشد.

Divergence را در سطح گروه اجرایی ببینید

فرض کنید نیمی از کل Threadهای برنامه
Path A
و نیم دیگر
Path B
را اجرا کنند.

این موضوع به تنهایی
نمی گوید Divergence زیاد است.

اگر Warpها یا Waveها
به شکل زیر باشند:


Warp 0 → All A

Warp 1 → All A

Warp 2 → All B

Warp 3 → All B

هر Warp Uniform است.

اما:


Every Warp

A B A B A B A B ...

Divergence در سطح گروه اجرایی بالا است.

Performance Impact — چه زمانی Divergence واقعا مهم می شود؟

Divergence معمولا زمانی اهمیت بیشتری پیدا می کند
که:

  • تعداد زیادی Thread در گروه
    مسیرهای متفاوت داشته باشند،
  • مسیرها طولانی باشند،
  • اختلاف مقدار کار میان Threadها زیاد باشد،
  • Branch در بخش پرتکرار Shader قرار داشته باشد،
  • یا Branch همراه با Memory Access سنگین باشد.

یک Branch کوچک و کم تکرار
ممکن است عملا
ارزش Optimization زیادی نداشته باشد.

Best Practices ساده

کار هدف
Threadهای مشابه را کنار هم قرار دهید Uniform Branch بیشتر
Branchهای سنگین را بررسی کنید کاهش اجرای مسیرهای طولانی متعدد
Loopهای با طول بسیار متفاوت را بررسی کنید کاهش Idle Lane
Branchهای کوچک را کورکورانه حذف نکنید جلوگیری از Instruction اضافی
Profiler استفاده کنید تشخیص Divergence واقعا مهم

Common Mistakes — اشتباهات رایج درباره Branch Divergence
  • هر if را مشکل Performance ندانید.
  • Uniform Branch را با Divergent Branch یکی ندانید.
  • تعداد Branchهای کل برنامه را ملاک Divergence قرار ندهید.
  • Divergence را در سطح کل Grid تحلیل نکنید؛ گروه اجرایی مهم است.
  • Branch را بدون در نظر گرفتن طول مسیرها ارزیابی نکنید.
  • Loop Divergence را نادیده نگیرید.
  • برای حذف Branch، محاسبات اضافی سنگین ایجاد نکنید.
  • بدون Profiling فرض نکنید Divergence Bottleneck اصلی است.

سوالات متداول درباره Branch Divergence

Branch Divergence چیست؟

زمانی رخ می دهد
که Threadهای یک Warp یا Wave
در یک Branch
مسیرهای اجرایی متفاوتی انتخاب کنند.

آیا استفاده از if در Shader بد است؟

خیر.

اگر Threadهای گروه اجرایی
نتیجه یکسانی برای شرط داشته باشند،
Branch می تواند Uniform باشد
و Divergence ایجاد نکند.

چرا Divergence Performance را کاهش می دهد؟

زیرا ممکن است مسیرهای متفاوت
در زمان های جداگانه اجرا شوند
و بخشی از Laneهای گروه
در هر مسیر غیرفعال باشند.

آیا Loop هم می تواند Divergent باشد؟

بله.

اگر Threadهای یک گروه
تعداد Iteration متفاوتی داشته باشند،
برخی Threadها
زودتر از بقیه Loop را تمام می کنند.

آیا حذف همه Branchها باعث سریع تر شدن Shader می شود؟

خیر.

حذف Branch ممکن است
باعث اجرای محاسبات غیرضروری شود.

هدف باید کاهش Divergence پرهزینه
و کار غیرضروری باشد،
نه حذف همه شرط ها.

بهترین راه کاهش Divergence چیست؟

در صورت امکان،
Work Itemهایی که رفتار مشابهی دارند
را در گروه های اجرایی مشابه قرار دهید
و Branchهای سنگین و پرتکرار را
با Profiler بررسی کنید.

خلاصه فصل

  • Branch Divergence زمانی ایجاد می شود که Threadهای یک گروه مسیرهای متفاوتی بروند.
  • وجود Branch به تنهایی مشکل نیست.
  • Uniform Branch زمانی است که همه Threadهای گروه یک مسیر را انتخاب کنند.
  • Divergent Branch می تواند باعث غیرفعال شدن بخشی از Laneها در هر مسیر شود.
  • هرچه مسیرهای متفاوت طولانی تر باشند، هزینه بالقوه Divergence بیشتر است.
  • Loopها نیز می توانند Divergence ایجاد کنند.
  • Thread Mapping و Data Grouping می توانند Divergence را کاهش دهند.
  • Branch کوتاه را نباید بدون دلیل حذف کرد.
  • Divergence باید در سطح Warp یا Wave تحلیل شود.
  • Profiler بهترین ابزار برای تشخیص اهمیت واقعی Divergence است.

سطح: مقدماتی تا متوسط

پیش نیاز:
Thread،
Warp / Wavefront،
Register،
Shared Memory،
GPU Scheduler

موضوع:
GPU Execution Architecture

زمان مطالعه:
حدود 10 تا 12 دقیقه


GPU EXECUTION ARCHITECTURE

Occupancy در GPU چیست؟

GPU برای پنهان کردن زمان انتظار
به تعداد کافی Thread و Warp آماده نیاز دارد.

Occupancy نشان می دهد
چه مقدار از ظرفیت سخت افزار
برای نگهداری گروه های اجرایی فعال
در حال استفاده است.

اما Occupancy بالا
به تنهایی به معنی Performance بالا نیست.


پاسخ سریع

Occupancy به نسبت Warpها یا Threadهای Resident
به حداکثر تعداد قابل پشتیبانی
روی یک واحد پردازشی GPU اشاره می کند.

Occupancy بیشتر
می تواند گزینه های بیشتری
در اختیار Scheduler قرار دهد
و به Latency Hiding کمک کند.

اما اگر Workload به منابع دیگری محدود باشد،
افزایش Occupancy
ممکن است تاثیر کمی داشته باشد.

در این فصل چه چیزهایی یاد می گیریم؟

  • Occupancy چیست.
  • Resident Warp یعنی چه.
  • چرا GPU به چند Warp فعال نیاز دارد.
  • Register Usage چگونه Occupancy را محدود می کند.
  • Shared Memory چگونه تعداد Blockهای Resident را کاهش می دهد.
  • Thread Block Size چه ارتباطی با Occupancy دارد.
  • چرا Occupancy بالا همیشه بهتر نیست.
  • چه زمانی افزایش Occupancy مفید است.

Resident Warp چیست؟

وقتی یک Warp
روی یک واحد پردازشی GPU
مستقر شده
و منابع لازم برای اجرای آن
اختصاص داده شده باشد،
می توان آن را
Resident Warp
در نظر گرفت.


Processing Unit

┌────────────────────┐
│ Warp A             │
│ Warp B             │
│ Warp C             │
│ Warp D             │
│                    │
│ Resident Warps     │
└────────────────────┘

همه Warpهای Resident
الزاما در همان لحظه
در حال اجرای Instruction نیستند.

برخی ممکن است:

  • آماده اجرا باشند،
  • منتظر Memory باشند،
  • منتظر Dependency باشند،
  • یا در انتظار Resource دیگری قرار داشته باشند.

ایده ساده Occupancy

فرض کنید یک واحد پردازشی
از نظر معماری
ظرفیت نگهداری
8 Warp Resident داشته باشد.

اگر فقط 4 Warp
Resident باشند:


Maximum Capacity

[Warp]
[Warp]
[Warp]
[Warp]
[Warp]
[Warp]
[Warp]
[Warp]


Resident

[Warp]
[Warp]
[Warp]
[Warp]

Occupancy

4 / 8

=

50%

این مثال فقط برای فهم مفهوم است
و اعداد واقعی
به معماری GPU وابسته هستند.

چرا داشتن چند Warp Resident مفید است؟

فرض کنید Warp A
یک Memory Request ارسال کند
و مجبور شود منتظر بماند.


Warp A

Execute
   │
   ▼
Memory Request
   │
   ▼
Waiting

اگر Warp دیگری آماده باشد:


Warp A → Waiting

Warp B → Ready

Warp C → Ready

Warp D → Ready

        │
        ▼

Scheduler

        │
        ▼

Execute Warp B

GPU می تواند
به جای بیکار ماندن
کار دیگری انجام دهد.

ارتباط Occupancy با Latency Hiding

Occupancy بیشتر
می تواند تعداد گزینه های Scheduler
را افزایش دهد.


More Resident Warps

        │
        ▼

More Ready Work
Potentially Available

        │
        ▼

Better Chance
to Hide Stalls

اما کلمه مهم
Potentially
است.

اگر همه Warpها
هم زمان منتظر همان Resource باشند،
وجود Warpهای بیشتر
ممکن است کمک زیادی نکند.

چه چیزی Occupancy را محدود می کند؟

هر واحد پردازشی GPU
مقدار محدودی Resource دارد.

Registers

هر Thread بخشی از Register File را مصرف می کند.

Shared Memory

هر Block می تواند بخشی از Shared Memory را رزرو کند.

Thread Slots

تعداد Threadهای Resident محدود است.

Warp / Wave Slots

تعداد گروه های اجرایی Resident نیز محدود است.

Block Slots

تعداد Workgroup یا Blockهای Resident محدود است.

Register Usage چگونه Occupancy را کاهش می دهد؟

هر Thread
به تعدادی Register نیاز دارد.

اگر Register Usage هر Thread زیاد شود،
تعداد Threadهایی که
به طور هم زمان
در Register File جا می شوند
کاهش پیدا می کند.


Low Registers per Thread

        │
        ▼

More Threads Can Fit


High Registers per Thread

        │
        ▼

Fewer Threads Can Fit

این همان ارتباطی است
که قبلا در بحث
Register Pressure
دیدیم.

Shared Memory چگونه Occupancy را محدود می کند؟

Shared Memory
بین Blockهای Resident
روی یک واحد پردازشی تقسیم می شود.

اگر هر Block
مقدار زیادی Shared Memory مصرف کند،
تعداد Blockهایی که
به صورت هم زمان
روی واحد پردازشی جا می شوند
کاهش پیدا می کند.


Small Shared Memory per Block

Block A
Block B
Block C
Block D


Large Shared Memory per Block

Block A
Block B

Thread Block Size چرا مهم است؟

Block Size
تعیین می کند
هر Workgroup
چند Thread داشته باشد.


Small Block

64 Threads


Medium Block

128 Threads


Larger Block

256 Threads

Blockهای بسیار کوچک
ممکن است از ظرفیت سخت افزار
به خوبی استفاده نکنند.

Blockهای بسیار بزرگ نیز
می توانند منابع زیادی مصرف کنند
و تعداد Blockهای Resident را کاهش دهند.

بنابراین Block Size
یک Trade-off است.

چرا اندازه گروه را با Warp هماهنگ می کنیم؟

در CUDA،
Warp شامل 32 Thread است.

اگر Block Size
مضربی از Warp Size باشد،
Threadها بهتر
در Warpهای کامل گروه بندی می شوند.


128 Threads

=

4 Full Warps


160 Threads

=

5 Full Warps

این یک قاعده عمومی مفید
برای CUDA است،
هرچند انتخاب نهایی Block Size
باید بر اساس Workload
و سخت افزار هدف انجام شود.

Under the Hood — Resource Allocation قبل از اجرا

قبل از اینکه یک Block
روی واحد پردازشی Resident شود،
سخت افزار باید
Resourceهای لازم آن را فراهم کند.


Thread Block

     │
     ▼

Needs

Registers
+
Shared Memory
+
Thread Slots
+
Warp Slots

     │
     ▼

Enough Resources?

   │       │
  Yes      No
   │       │
   ▼       ▼

Resident   Wait

به همین دلیل
مصرف Resource
مستقیما بر تعداد Blockهای Resident
اثر می گذارد.

چرا 100٪ Occupancy همیشه هدف نیست؟

فرض کنید یک Kernel
در 60٪ Occupancy
به اندازه کافی Warp آماده دارد
تا Stallها را پنهان کند.

افزایش Occupancy به 100٪
ممکن است هیچ سود مهمی ایجاد نکند.


60% Occupancy

Enough Ready Warps
        │
        ▼
Hardware Already Busy


100% Occupancy

More Resident Warps
        │
        ▼
No Additional Useful Gain

بنابراین Occupancy
پس از رسیدن به حد کافی
ممکن است بازده نزولی داشته باشد.

گاهی Occupancy کمتر سریع تر است

فرض کنید برای افزایش Occupancy
Register Usage را به شدت کاهش دهیم.

اگر این کار باعث
Register Spill شود:


Force Fewer Registers

       │
       ▼

Higher Occupancy

       │
       ▼

Register Spill

       │
       ▼

More Memory Traffic

       │
       ▼

Lower Performance

در این حالت،
Occupancy بالاتر
نتیجه بدتری ایجاد کرده است.

Workloadهای Compute-Heavy

بعضی Kernelها
عملیات محاسباتی زیادی دارند
و Memory Stall کمتری تجربه می کنند.

در این شرایط،
Occupancy بسیار بالا
ممکن است اهمیت کمتری داشته باشد.

اگر هر Warp
کار محاسباتی کافی برای انجام دادن داشته باشد،
واحدهای اجرایی
ممکن است حتی با Occupancy متوسط
به خوبی استفاده شوند.

Workloadهای Memory-Heavy

در Kernelهایی که
Memory Latency زیادی دارند،
داشتن Warpهای آماده بیشتر
می تواند اهمیت بیشتری پیدا کند.


Warp A → Memory Wait

Warp B → Memory Wait

Warp C → Ready

Warp D → Ready

Warp E → Ready

       │
       ▼

Scheduler Still Has Work

در چنین Workloadهایی،
Occupancy مناسب
می تواند به Latency Hiding کمک کند.

Engineering Insight — دنبال عدد جادویی نباشید

هیچ مقدار Occupancy
به صورت عمومی
برای تمام Kernelها بهترین نیست.

مقدار مناسب
به عواملی مانند:

  • Instruction Mix،
  • Register Usage،
  • Shared Memory Usage،
  • Memory Latency،
  • Branch Divergence،
  • و معماری GPU

بستگی دارد.

هدف این نیست که Occupancy را بیشینه کنیم؛
هدف این است که GPU
کار آماده کافی برای انجام دادن داشته باشد.

مدل ساده Performance


Registers
     │
     ├──────────┐
     │          │
Shared Memory   │
     │          │
     ▼          ▼

Resident Blocks / Warps

        │
        ▼

Scheduling Choices

        │
        ▼

Latency Hiding

        │
        ▼

Execution Efficiency

اما مسیر دیگری نیز وجود دارد:


Too Aggressive
Occupancy Optimization

        │
        ▼

Less Registers
or Less Shared Memory

        │
        ▼

More Instructions /
More Memory Traffic

        │
        ▼

Lower Performance

برای تحلیل Occupancy چه چیزهایی را بررسی کنیم؟

مورد سوال
Registers هر Thread چند Register مصرف می کند؟
Shared Memory هر Block چه مقدار Shared Memory می گیرد؟
Block Size هر Block چند Thread دارد؟
Resident Warps چند Warp می توانند هم زمان Resident باشند؟
Stalls آیا Warpهای Resident واقعا آماده اجرا هستند؟
Performance تغییر Occupancy واقعا Runtime را بهتر می کند؟

Performance Impact — چه زمانی Occupancy مهم است؟

Occupancy اهمیت بیشتری پیدا می کند
زمانی که GPU
برای پنهان کردن Stallها
به Warpهای بیشتری نیاز داشته باشد.

اگر Scheduler
مرتب با کمبود Warp آماده مواجه شود،
افزایش تعداد Resident Warpها
می تواند مفید باشد.

اما اگر واحدهای اجرایی
از قبل به خوبی مشغول باشند،
Occupancy بیشتر
الزاما Performance را افزایش نمی دهد.

Common Mistakes — اشتباهات رایج درباره Occupancy
  • Occupancy را با GPU Utilization یکی ندانید.
  • 100٪ Occupancy را همیشه بهترین حالت فرض نکنید.
  • برای افزایش Occupancy، Register Usage را کورکورانه کاهش ندهید.
  • Shared Memory Usage را از Occupancy جدا تحلیل نکنید.
  • Block Size بزرگ تر را همیشه بهتر ندانید.
  • Occupancy بالا را معادل FPS یا Runtime بهتر ندانید.
  • فقط تعداد Warpهای Resident را بررسی نکنید؛
    Warpهای Ready مهم هستند.
  • بدون Profiling دنبال عدد جادویی Occupancy نگردید.

سوالات متداول درباره Occupancy

Occupancy در GPU چیست؟

نسبت Warpها یا Threadهای Resident
به حداکثر ظرفیت قابل پشتیبانی
روی یک واحد پردازشی GPU است.

آیا Occupancy بیشتر همیشه بهتر است؟

خیر.

Occupancy بیشتر
می تواند برای Latency Hiding مفید باشد،
اما پس از فراهم شدن کار آماده کافی
ممکن است افزایش بیشتر
مزیت قابل توجهی ایجاد نکند.

چه چیزهایی Occupancy را محدود می کنند؟

Register Usage،
Shared Memory Usage،
Block Size
و محدودیت های Thread،
Warp
و Block
در معماری GPU.

چرا Register زیاد Occupancy را کم می کند؟

زیرا Register File محدود است
و اگر هر Thread
Register بیشتری مصرف کند،
تعداد کمتری Thread
می توانند هم زمان Resident باشند.

آیا Occupancy پایین همیشه بد است؟

خیر.

اگر Kernel
با Occupancy پایین تر
همچنان کار آماده کافی داشته باشد
و از منابع خود موثر استفاده کند،
Performance می تواند کاملا مناسب باشد.

Occupancy و Utilization یکی هستند؟

خیر.

Occupancy درباره تعداد کارهای Resident است،
در حالی که Utilization نشان می دهد
واحدهای سخت افزاری
در عمل تا چه اندازه مشغول کار هستند.

خلاصه فصل

  • Occupancy میزان استفاده از ظرفیت Resident Thread یا Warp را بیان می کند.
  • Warp Resident الزاما در همان لحظه در حال اجرا نیست.
  • Warpهای بیشتر می توانند گزینه های بیشتری برای Scheduler ایجاد کنند.
  • Occupancy مناسب می تواند به Latency Hiding کمک کند.
  • Register Usage می تواند Occupancy را محدود کند.
  • Shared Memory Usage می تواند تعداد Blockهای Resident را کاهش دهد.
  • Block Size بر نحوه استفاده از منابع اثر می گذارد.
  • Occupancy بیشتر همیشه Performance بیشتر نیست.
  • گاهی Occupancy کمتر با Register بیشتر می تواند سریع تر باشد.
  • هدف نهایی داشتن کار آماده کافی برای سخت افزار است.

سطح: مقدماتی تا متوسط

پیش نیاز:
Warp / Wavefront،
Occupancy،
Branch Divergence،
Memory Latency

موضوع:
GPU Execution Architecture

زمان مطالعه:
حدود 10 تا 12 دقیقه


GPU EXECUTION ARCHITECTURE

Warp Scheduling در GPU چگونه کار می کند؟

در هر لحظه
تعداد زیادی Warp یا Wave
ممکن است روی GPU آماده،
منتظر حافظه
یا در حال انتظار برای یک Dependency باشند.

وظیفه Scheduler این است
که از میان کارهای آماده،
گروه مناسب را برای اجرای دستور بعدی انتخاب کند.

همین توانایی
یکی از دلایل اصلی قدرت GPU
در پنهان کردن Latency است.


پاسخ سریع

Warp Scheduler
بخشی از منطق اجرای GPU است
که از میان Warpهای Resident و آماده،
گروهی را برای اجرای Instruction انتخاب می کند.

اگر یک Warp
منتظر Memory یا نتیجه یک Instruction باشد،
Scheduler می تواند
Warp دیگری را که آماده است اجرا کند.

در این فصل چه چیزهایی یاد می گیریم؟

  • Warp Scheduler چیست.
  • تفاوت Resident Warp و Ready Warp چیست.
  • چرا همه Warpهای Resident قابل اجرا نیستند.
  • Scheduler چگونه Latency را پنهان می کند.
  • Stall چیست.
  • چرا داشتن Warpهای بیشتر مفید است.
  • چرا Scheduling به تنهایی تمام Stallها را حل نمی کند.
  • چگونه Occupancy و Scheduling به هم مرتبط هستند.

Resident Warp و Ready Warp یکی نیستند

Warp Resident
روی واحد پردازشی مستقر شده
و منابع لازم را در اختیار دارد.

اما ممکن است
در همان لحظه
آماده اجرای Instruction بعدی نباشد.


Resident Warps

Warp A → Ready

Warp B → Waiting for Memory

Warp C → Ready

Warp D → Waiting for Dependency

Warp E → Ready

Scheduler
بیشتر به Warpهای
Ready
اهمیت می دهد.

Scheduler چه کاری انجام می دهد؟

فرض کنید چند Warp
روی یک واحد پردازشی وجود داشته باشند.


Warp A → Ready

Warp B → Waiting

Warp C → Ready

Warp D → Ready

        │

        ▼

    Scheduler

        │

        ▼

Select Ready Warp

Scheduler
یک Warp آماده را انتخاب می کند
و Instruction مناسب
برای اجرای آن صادر می شود.

چرا GPU فقط یک Warp را تا آخر اجرا نمی کند؟

چون Warp ممکن است
در طول اجرای خود
بارها منتظر بماند.

برای مثال:


Warp A

Compute

   │
   ▼

Memory Load

   │
   ▼

Wait

   │
   ▼

Continue

اگر GPU فقط همان Warp را اجرا کند،
بخشی از زمان
واحدهای اجرایی بیکار می مانند.

اما با چند Warp:


Warp A → Waiting

Warp B → Execute

Warp C → Ready

Warp D → Ready

زمان انتظار یک Warp
می تواند با اجرای Warp دیگری پوشانده شود.

Stall چیست؟


Stall

وضعیتی است
که یک Warp موقتا
نمی تواند Instruction بعدی خود را اجرا کند.

دلایل مختلفی
می توانند Stall ایجاد کنند.

Memory Wait

داده هنوز از Memory System نرسیده است.

Instruction Dependency

Instruction بعدی به نتیجه قبلی نیاز دارد.

Synchronization

Threadها منتظر رسیدن دیگر اعضای گروه هستند.

Execution Resource

واحد اجرایی مورد نیاز
در آن لحظه در دسترس نیست.

Scheduling چگونه Latency را پنهان می کند؟

فرض کنید Warp A
برای Memory Load
منتظر بماند.


Time ─────────────────────────────────►


Warp A

Compute ─ Load ───── WAIT ───── Continue


Warp B

             Compute ─────────────


Warp C

                       Compute ───────

Latency Warp A
از بین نرفته است.

اما GPU
در زمان انتظار آن
کار مفید دیگری انجام داده است.

GPU به Ready Work نیاز دارد

داشتن تعداد زیادی Warp Resident
فقط زمانی مفید است
که بخشی از آنها واقعا آماده اجرا باشند.


Scenario A

Warp A → Ready
Warp B → Ready
Warp C → Ready
Warp D → Waiting

Good Scheduling Choices


Scenario B

Warp A → Waiting
Warp B → Waiting
Warp C → Waiting
Warp D → Waiting

No Ready Work

در حالت دوم
Scheduler گزینه ای برای اجرا ندارد.

Under the Hood — Scheduler معجزه نمی کند

Warp Scheduling
فقط زمانی Latency را پنهان می کند
که کار مستقل دیگری آماده باشد.

اگر تمام Warpها
به داده مشابهی وابسته باشند
یا همگی برای یک Resource منتظر بمانند،
Scheduler نمی تواند
از هیچ کاری کار مفید بسازد.


All Warps Waiting

Warp A ─┐
Warp B ─┤
Warp C ─┼──► Same Bottleneck
Warp D ─┘

        │
        ▼

Scheduler Has No Ready Warp

Occupancy چگونه به Scheduling کمک می کند؟

Occupancy بالاتر
می تواند تعداد Warpهای Resident
را افزایش دهد.


More Resident Warps

        │
        ▼

Potentially More Ready Warps

        │
        ▼

More Scheduling Choices

اما همان طور که دیدیم،
این رابطه تضمینی نیست.

Warpهای Resident
ممکن است هم زمان
Stall شده باشند.

Instruction Dependency

گاهی Warp
به خاطر Memory منتظر نیست.

ممکن است Instruction بعدی
به نتیجه Instruction قبلی نیاز داشته باشد.


float a = x * y;

float b = a + z;

float c = b * 2.0f;

اینجا:


Instruction 1

a = x * y

    │
    ▼

Instruction 2

b = a + z

    │
    ▼

Instruction 3

c = b * 2

هر مرحله
به نتیجه مرحله قبلی وابسته است.

اگر Latency Instruction
هنوز تمام نشده باشد،
Warp ممکن است موقتا
قابل اجرا نباشد.

کار مستقل فرصت بیشتری برای Scheduling ایجاد می کند

اگر چند عملیات مستقل باشند:


float a = x * y;

float b = p * q;

float c = m + n;

وابستگی کمتری میان آنها وجود دارد.

این نوع Parallelism
می تواند به سخت افزار
فرصت بیشتری برای
پوشاندن Latency دستورها بدهد.

همه Instructionها از یک واحد سخت افزاری استفاده نمی کنند

GPU می تواند
انواع مختلفی از واحدهای اجرایی داشته باشد.

Integer Units

عملیات Integer.

Floating-Point Units

محاسبات Floating-Point.

Special Function Units

برخی توابع ریاضی خاص.

Tensor / Matrix Units

در برخی GPUها،
عملیات Matrix یا AI.

Load / Store Path

دسترسی های حافظه.

اگر یک نوع Resource
بیش از حد درخواست شود،
ممکن است بخشی از Warpها
برای استفاده از همان Resource
منتظر بمانند.

Synchronization چگونه Scheduling را متوقف می کند؟

گاهی Threadهای یک Block
باید منتظر یکدیگر بمانند.


Warp A ─────► Barrier

Warp B ───────────► Barrier

Warp C ─────────────────► Barrier

                 │
                 ▼

All Required Threads Arrive

                 │
                 ▼

Continue

Warpی که به Barrier رسیده
تا برطرف شدن شرط Synchronization
نمی تواند از آن عبور کند.

اگر Warpهای دیگری آماده باشند،
Scheduler هنوز می تواند
آنها را اجرا کند.

آیا Scheduler همیشه Warpها را به ترتیب اجرا می کند؟

نه.

GPU مجبور نیست
Warpها را دقیقا به ترتیب شماره آنها اجرا کند.

سخت افزار می تواند
براساس وضعیت Warpها،
آمادگی Instructionها
و سیاست های داخلی معماری
گروه مناسب را انتخاب کند.


Warp 0 → Waiting

Warp 1 → Ready

Warp 2 → Ready

Warp 3 → Waiting

        │
        ▼

Possible Scheduling

Warp 1
Warp 2
...

جزئیات دقیق Scheduling Policy
به معماری GPU بستگی دارد.

Engineering Insight — Throughput مهم تر از ترتیب یک Warp است

در بسیاری از طراحی های GPU،
هدف اصلی این نیست
که یک Warp خاص
در کمترین زمان ممکن تمام شود.

هدف این است
که کل واحد پردازشی
در بازه زمانی طولانی
کار مفید زیادی انجام دهد.


CPU-Oriented Thinking

Finish one task quickly


GPU-Oriented Thinking

Keep many execution resources
busy across many tasks

GPU بیشتر برای Throughput بالا طراحی شده
تا Latency بسیار پایین یک Thread منفرد.

وقتی Warp آماده کافی وجود ندارد

اگر Resource Usage بالا باشد
و فقط تعداد کمی Warp Resident شوند،
Scheduler انتخاب های کمتری دارد.


Only Two Resident Warps

Warp A → Waiting

Warp B → Waiting

        │
        ▼

No Ready Work

در چنین شرایطی،
Latency می تواند
بیشتر قابل مشاهده شود.

Warp بیشتر همیشه بهتر نیست

اگر Scheduler
همین حالا
کار آماده کافی داشته باشد،
افزایش تعداد Warpها
ممکن است سود زیادی نداشته باشد.

ضمن اینکه افزایش Occupancy
ممکن است نیازمند کاهش
Register یا Shared Memory
برای هر Thread یا Block باشد.

در نتیجه دوباره
به همان Trade-off اصلی می رسیم:

منابع بیشتر برای هر Thread
یا
Threadهای بیشتر به صورت هم زمان؟

Performance Impact — Scheduling خوب چه زمانی مهم می شود؟

Warp Scheduling
در Workloadهایی اهمیت زیادی دارد
که Stallهای فراوانی دارند.

برای مثال:

  • Memory Latency بالا،
  • Dependencyهای زیاد،
  • Synchronization،
  • یا Resource Contention.

اگر Warpهای مستقل کافی
برای اجرا وجود داشته باشند،
Scheduler می تواند
بخشی از این زمان انتظار را
با کار مفید پوشش دهد.

Common Mistakes — اشتباهات رایج درباره Warp Scheduling
  • Resident Warp را همیشه Ready Warp فرض نکنید.
  • تصور نکنید GPU یک Warp را تا پایان اجرا می کند.
  • Scheduling را فقط برای Memory Latency ندانید.
  • Occupancy بالا را معادل Ready Warp بیشتر ندانید.
  • فرض نکنید Scheduler می تواند همه Stallها را پنهان کند.
  • ترتیب اجرای Warpها را ثابت و قابل پیش بینی فرض نکنید.
  • جزئیات Scheduler یک معماری را به همه GPUها تعمیم ندهید.
  • Throughput کل GPU را با سرعت یک Thread یا Warp منفرد اشتباه نگیرید.

مدل ذهنی نهایی


Resident Warps

      │
      ▼

Ready or Stalled?

      │
      ▼

Ready Warps

      │
      ▼

Scheduler

      │
      ▼

Issue Instruction

      │
      ▼

Execution Unit

      │
      ▼

Next Scheduling Opportunity

سوالات متداول درباره Warp Scheduling

Warp Scheduler چیست؟

منطقی در GPU است
که از میان Warpهای آماده
کار مناسب برای اجرا را انتخاب می کند.

آیا تمام Warpهای Resident در حال اجرا هستند؟

خیر.

برخی آماده اجرا هستند
و برخی ممکن است
منتظر Memory،
Dependency
یا Synchronization باشند.

Scheduler چگونه Memory Latency را کاهش می دهد؟

Latency را لزوما کاهش نمی دهد؛
بلکه با اجرای Warpهای دیگر
در زمان انتظار یک Warp،
اثر آن را پنهان می کند.

آیا Warpها به ترتیب شماره اجرا می شوند؟

نه لزوما.

ترتیب Scheduling
به آمادگی Warpها
و سیاست داخلی سخت افزار بستگی دارد.

اگر همه Warpها Stall شوند چه اتفاقی می افتد؟

Scheduler کار آماده ای برای اجرا ندارد
و بخشی از واحدهای اجرایی
ممکن است تا رفع Stall
بیکار بمانند.

آیا Occupancy بیشتر همیشه Scheduling را بهتر می کند؟

خیر.

Occupancy بیشتر
فقط امکان وجود Warpهای Resident بیشتر را می دهد.

اگر آنها آماده اجرا نباشند،
Scheduler همچنان ممکن است
با کمبود کار مواجه شود.

خلاصه فصل

  • Warp Scheduler از میان Warpهای آماده کار قابل اجرا را انتخاب می کند.
  • Resident Warp و Ready Warp دو مفهوم متفاوت هستند.
  • Warp می تواند به دلیل Memory، Dependency، Synchronization یا Resource Stall شود.
  • Scheduler با اجرای Warpهای دیگر به Latency Hiding کمک می کند.
  • Latency حذف نمی شود؛ با کار مفید دیگر پوشانده می شود.
  • Occupancy بیشتر می تواند انتخاب های Scheduler را افزایش دهد.
  • اگر همه Warpها Stall باشند، Scheduler کاری برای اجرا ندارد.
  • Instruction Dependency نیز می تواند Warp را متوقف کند.
  • ترتیب دقیق Scheduling به معماری GPU وابسته است.
  • هدف اصلی GPU حفظ Throughput بالا در تعداد زیادی Thread است.

سطح: مقدماتی تا متوسط

پیش نیاز:
Thread،
Warp / Wavefront،
Warp Scheduling،
Occupancy

موضوع:
GPU Execution Architecture

زمان مطالعه:
حدود 10 تا 12 دقیقه


GPU EXECUTION ARCHITECTURE

GPU Execution Pipeline چگونه کار می کند؟

وقتی یک Shader یا Compute Kernel اجرا می شود،
دستورها مستقیما و بدون واسطه
به واحدهای محاسباتی نمی رسند.

GPU باید کار را
گروه بندی،
زمان بندی،
Decode
و در نهایت
روی واحدهای اجرایی مناسب اجرا کند.

این زنجیره را می توان
به صورت یک Execution Pipeline
در نظر گرفت.


پاسخ سریع

GPU Execution Pipeline
مسیری است که Workload
از Dispatch شدن
تا اجرای Instructionها
روی واحدهای سخت افزاری طی می کند.

در یک مدل ساده:

Dispatch
به Workgroupها تقسیم می شود،
Workgroupها به Warp یا Wave تبدیل می شوند،
Scheduler گروه های آماده را انتخاب می کند
و Instructionها
روی واحدهای مناسب اجرا می شوند.

در این فصل چه چیزهایی یاد می گیریم؟

  • Execution Pipeline چیست.
  • Dispatch چگونه به Threadها تبدیل می شود.
  • Workgroup چه نقشی دارد.
  • Warp یا Wave چگونه وارد Scheduler می شود.
  • Instruction Issue چیست.
  • Execution Unit چه کاری انجام می دهد.
  • Result چگونه دوباره وارد جریان برنامه می شود.
  • چرا GPU چند مرحله را هم زمان جلو می برد.

تصویر کلی Execution Pipeline


Application

    │
    ▼

Dispatch / Draw

    │
    ▼

Workgroups / Blocks

    │
    ▼

Warps / Waves

    │
    ▼

Scheduler

    │
    ▼

Instruction Issue

    │
    ▼

Execution Units

    │
    ▼

Results

    │
    ▼

Continue Execution

مرحله اول: Dispatch

CPU یا Command Processor
به GPU اعلام می کند
که یک Workload باید اجرا شود.

این Workload
ممکن است یک:

  • Compute Dispatch،
  • Draw Call،
  • یا بخشی از Graphics Pipeline

باشد.


Application

      │
      ▼

Command

      │
      ▼

GPU Dispatch

مرحله دوم: Workgroup یا Thread Block

Workload به گروه هایی از Threadها
تقسیم می شود.

در CUDA
این گروه
Thread Block
نام دارد.

در APIهای دیگر
معمولا از اصطلاح
Workgroup
یا Thread Group
استفاده می شود.


Dispatch

   │
   ├── Workgroup 0
   ├── Workgroup 1
   ├── Workgroup 2
   └── Workgroup 3

Workgroup روی کجا اجرا می شود؟

هر Workgroup
روی یکی از واحدهای پردازشی GPU
قرار می گیرد.

نام این واحد
بین معماری ها متفاوت است.

شرکت / معماری نام رایج
NVIDIA Streaming Multiprocessor — SM
AMD Compute Unit — CU
نام عمومی Processing Unit / Compute Unit

مرحله بعد: تبدیل Threadها به گروه های اجرایی

Threadهای Workgroup
برای اجرا
به Warp یا Wave تقسیم می شوند.


Thread Block

128 Threads

      │
      ▼

Warp 0
Warp 1
Warp 2
Warp 3

این گروه ها
واحد اصلی Scheduling
در GPU هستند.

Warp چه زمانی آماده اجرا است؟

Warp زمانی Ready است
که Instruction بعدی آن
قابل اجرا باشد.

یعنی:

  • Operandهای لازم آماده باشند،
  • Dependency حل شده باشد،
  • Barrier مانع ادامه نباشد،
  • و Resource لازم در دسترس باشد.


Warp

 │
 ▼

Operands Ready?

 │
 ├── No  → Stall
 │
 └── Yes
       │
       ▼
   Ready to Issue

Instruction Issue چیست؟


Instruction Issue

فرایندی است
که در آن Scheduler
یک Instruction آماده
را برای اجرا
به مسیر سخت افزاری مناسب ارسال می کند.


Ready Warp

    │
    ▼

Scheduler

    │
    ▼

Issue Instruction

    │
    ▼

Execution Unit

Instruction روی چه واحدی اجرا می شود؟

نوع Instruction
تعیین می کند
کدام واحد سخت افزاری
برای اجرای آن مناسب است.

FP Units

محاسبات Floating-Point.

Integer Units

محاسبات Integer.

Load / Store

عملیات حافظه.

Special Function

برخی توابع خاص ریاضی.

Matrix / Tensor Units

عملیات ماتریسی در GPUهای مجهز به این واحدها.

مرحله Execute

پس از Issue شدن،
Instruction
روی واحد مناسب اجرا می شود.


Instruction

    │
    ▼

Execution Unit

    │
    ▼

Operation

    │
    ▼

Result

مدت اجرای Instructionها
یکسان نیست.

برخی عملیات ساده هستند
و برخی ممکن است
Latency بیشتری داشته باشند.

نتیجه کجا می رود؟

بسته به Instruction،
نتیجه می تواند:

  • داخل Register قرار بگیرد،
  • به Shared Memory نوشته شود،
  • به Cache یا VRAM ارسال شود،
  • یا به عنوان ورودی Instruction بعدی استفاده شود.


Execution Result

      │
      ├── Register
      ├── Shared Memory
      ├── Cache / VRAM
      └── Next Instruction

چرا به آن Pipeline می گوییم؟

GPU لازم نیست
صبر کند تا تمام مراحل یک Instruction
به طور کامل تمام شوند
و بعد کار بعدی را شروع کند.

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


Time ─────────────────────────────►

Warp A

Issue → Execute → Result


Warp B

       Issue → Execute → Result


Warp C

              Issue → Execute → Result

این هم پوشانی
به افزایش Throughput کمک می کند.

GPU فقط یک Pipeline ندارد

یک GPU مدرن
تعداد زیادی واحد پردازشی
و چندین مسیر اجرایی دارد.


Processing Unit 0
 ├── FP
 ├── INT
 ├── Load / Store
 └── Special Units


Processing Unit 1
 ├── FP
 ├── INT
 ├── Load / Store
 └── Special Units


Processing Unit 2
 ...

به همین دلیل
تعداد بسیار زیادی Instruction
می توانند در بخش های مختلف GPU
در حال پیشرفت باشند.

Under the Hood — یک Instruction همیشه در یک Cycle تمام نمی شود

عبارت
«یک Instruction اجرا شد»
نباید به این معنی برداشت شود
که حتما در یک Clock Cycle
کامل شده است.

Instructionهای مختلف
Latency و Throughput متفاوت دارند.


Instruction A

Shorter Latency


Instruction B

Longer Latency


Memory Operation

Potentially Much Longer

GPU با Pipelining،
Warp Scheduling
و Parallelism
تلاش می کند
اثر این Latencyها را کاهش دهد.

Data Dependency چگونه Pipeline را متوقف می کند؟

این کد را در نظر بگیرید:


float a = x + y;

float b = a * 2.0f;

float c = b + 1.0f;

Instruction دوم
به نتیجه اول
و Instruction سوم
به نتیجه دوم نیاز دارد.


a = x + y

    │
    ▼

b = a * 2

    │
    ▼

c = b + 1

اگر نتیجه قبلی
آماده نشده باشد،
Warp باید منتظر بماند.

Instructionهای مستقل مفید هستند

اگر چند Instruction
به یکدیگر وابسته نباشند،
سخت افزار فرصت بیشتری
برای هم پوشانی کار دارد.


float a = x + y;

float b = p * q;

float c = m - n;

در این مثال
سه عملیات
وابستگی مستقیم به یکدیگر ندارند.

این نوع استقلال
به
Instruction-Level Parallelism
کمک می کند.

Instruction-Level Parallelism چیست؟


Instruction-Level Parallelism — ILP

وجود چند Instruction مستقل
که بتوان بخشی از اجرای آنها را
بدون انتظار مستقیم برای یکدیگر
پیش برد.

GPU علاوه بر
Thread-Level Parallelism،
می تواند از
Instruction-Level Parallelism
نیز سود ببرد.

سه سطح مهم Parallelism در GPU

Thread-Level Parallelism

تعداد زیادی Thread مستقل.

Warp-Level Parallelism

چند Warp آماده برای Scheduling.

Instruction-Level Parallelism

Instructionهای مستقل داخل جریان اجرا.

Performance بالا
اغلب نتیجه ترکیب
این سطوح مختلف Parallelism است.

Engineering Insight — GPU فقط «تعداد Core زیاد» نیست

قدرت GPU
فقط از تعداد زیاد ALUها نمی آید.

برای استفاده موثر از آن واحدها،
GPU به یک سیستم کامل نیاز دارد:

  • Thread Grouping،
  • Warp Scheduling،
  • Execution Pipelines،
  • Register File،
  • Memory Hierarchy،
  • و Latency Hiding.

واحد محاسباتی زمانی ارزشمند است
که بتوانیم به طور مداوم
کار آماده در اختیار آن قرار دهیم.

Performance Impact — Pipeline چه زمانی خالی می شود؟

اگر Instruction آماده کافی وجود نداشته باشد،
بخشی از Pipeline
ممکن است بدون کار بماند.

دلایل رایج:

  • Memory Stall،
  • Dependency،
  • Branch Divergence،
  • Synchronization،
  • یا Resource Bottleneck.


No Ready Work

      │
      ▼

Pipeline Bubble / Idle Opportunity

      │
      ▼

Lower Throughput

مدل ذهنی نهایی Execution Pipeline


Dispatch

   │
   ▼

Workgroup

   │
   ▼

Warp / Wave

   │
   ▼

Ready?

   │
   ▼

Scheduler

   │
   ▼

Issue

   │
   ▼

Execute

   │
   ▼

Write Result

   │
   ▼

Next Instruction

Common Mistakes — اشتباهات رایج درباره Execution Pipeline
  • تصور نکنید Thread مستقیما به یک Core ثابت متصل است.
  • Dispatch را با Warp یکی ندانید.
  • Issue Instruction را با پایان اجرای Instruction یکی ندانید.
  • فرض نکنید تمام Instructionها یک Latency دارند.
  • Execution Pipeline را فقط یک مسیر سخت افزاری واحد تصور نکنید.
  • Dependency را در Performance Analysis نادیده نگیرید.
  • Thread-Level Parallelism را تنها نوع Parallelism GPU ندانید.
  • Pipeline Stall را همیشه فقط به Memory نسبت ندهید.

سوالات متداول درباره GPU Execution Pipeline

GPU Execution Pipeline چیست؟

مجموعه مراحلی است
که Workload
از Dispatch شدن
تا اجرای Instruction و تولید نتیجه
طی می کند.

Instruction Issue چیست؟

مرحله ای است
که یک Instruction آماده
برای اجرا
به واحد سخت افزاری مناسب ارسال می شود.

آیا هر Instruction در یک Cycle اجرا می شود؟

خیر.

Instructionها
Latency و Throughput متفاوتی دارند
و بعضی عملیات
چندین Cycle یا بیشتر زمان نیاز دارند.

Instruction-Level Parallelism چیست؟

وجود چند Instruction مستقل است
که اجرای آنها
نیازمند انتظار مستقیم برای نتیجه یکدیگر نیست.

چرا Pipeline خالی می شود؟

اگر Warp آماده،
Operand آماده
یا Resource اجرایی مناسب وجود نداشته باشد،
بخشی از Pipeline
ممکن است موقتا بدون کار بماند.

خلاصه فصل

  • Execution Pipeline مسیر تبدیل Workload به اجرای واقعی Instructionها است.
  • Dispatch به Workgroupها و سپس گروه های اجرایی تقسیم می شود.
  • Scheduler Warp یا Wave آماده را انتخاب می کند.
  • Instruction Issue به معنی ارسال دستور برای اجرا است.
  • نوع Instruction تعیین می کند از کدام Execution Unit استفاده شود.
  • Instructionها Latency یکسانی ندارند.
  • GPU چندین Pipeline و واحد اجرایی را به صورت موازی استفاده می کند.
  • Data Dependency می تواند اجرای Warp را متوقف کند.
  • Instructionهای مستقل ILP ایجاد می کنند.
  • Performance GPU نتیجه ترکیب Thread-Level، Warp-Level و Instruction-Level Parallelism است.

سطح: جمع بندی

پیش نیاز:
تمام بخش های GPU Execution Architecture

موضوع:
GPU Execution Architecture

زمان مطالعه:
حدود 8 تا 10 دقیقه


GPU EXECUTION ARCHITECTURE

جمع بندی GPU Execution Architecture

GPU فقط مجموعه بزرگی از Coreها نیست.

برای اینکه هزاران Thread
بتوانند به شکل موثر اجرا شوند،
GPU باید آنها را گروه بندی کند،
منابع لازم را در اختیارشان قرار دهد،
Warpها یا Waveهای آماده را زمان بندی کند
و Instructionها را
به واحدهای اجرایی مناسب بفرستد.

Execution Architecture
همان سیستمی است
که این Parallelism عظیم
را قابل مدیریت می کند.


پاسخ سریع

GPU Execution Architecture
روش سازمان دهی و اجرای Threadها
روی سخت افزار GPU را توصیف می کند.

Threadها در گروه های اجرایی
مانند Warp یا Wave
مدیریت می شوند،
Scheduler کار آماده را انتخاب می کند
و Instructionها
روی واحدهای مختلف اجرایی اجرا می شوند.

هدف اصلی
حفظ Throughput بالا
و جلوگیری از بیکار ماندن سخت افزار است.

تصویر کلی اجرای GPU


Application

    │
    ▼

Draw / Dispatch

    │
    ▼

Workgroups / Blocks

    │
    ▼

Warps / Waves

    │
    ▼

Resident Work

    │
    ▼

Ready Warps

    │
    ▼

Scheduler

    │
    ▼

Instruction Issue

    │
    ▼

Execution Units

    │
    ▼

Results

    │
    ▼

Continue

Thread

Thread
یکی از کوچک ترین واحدهای منطقی کار
در برنامه GPU است.

Threadهای مختلف
معمولا همان Shader یا Kernel
را روی داده های متفاوت اجرا می کنند.


Same Program

   │
   ├── Thread 0 → Data 0
   ├── Thread 1 → Data 1
   ├── Thread 2 → Data 2
   └── Thread 3 → Data 3

Workgroup / Thread Block

Threadها
در گروه های بزرگ تری
سازمان دهی می شوند.

این گروه ها
امکان همکاری Threadها،
استفاده از Shared Memory
و Synchronization
را فراهم می کنند.


Dispatch

 ├── Workgroup 0
 │    ├── Threads
 │    ├── Shared Memory
 │    └── Synchronization
 │
 ├── Workgroup 1
 │
 └── Workgroup 2

Warp و Wavefront

GPU Threadها را
برای اجرای سخت افزاری
در گروه های کوچک تری مدیریت می کند.

در NVIDIA
اصطلاح
Warp
رایج است.

در AMD
اصطلاح
Wavefront
یا
Wave
استفاده می شود.

در CUDA،
Warp شامل
32 Thread
است.

SIMT

GPU از مدلی استفاده می کند
که در آن تعداد زیادی Thread
Instructionهای مشابه
را روی داده های متفاوت اجرا می کنند.


One Instruction Stream

        │
        ▼

Thread 0 → Data A

Thread 1 → Data B

Thread 2 → Data C

Thread 3 → Data D

این مدل
برای Workloadهای دارای Parallelism زیاد
بسیار مناسب است.

Branch Divergence

اگر Threadهای یک Warp یا Wave
مسیرهای مختلفی در Branch انتخاب کنند،
Divergence رخ می دهد.


Uniform

A A A A A A A A


Divergent

A B A B A B A B

وجود
if
به تنهایی مشکل نیست.

مشکل زمانی مهم می شود
که Threadهای یک گروه
کارهای متفاوت و طولانی انجام دهند.

Occupancy

هر واحد پردازشی GPU
ظرفیت محدودی
برای نگهداری Thread،
Warp
و Blockهای Resident دارد.

Occupancy نشان می دهد
چه مقدار از این ظرفیت
در حال استفاده است.


Maximum Resident Capacity

████████████████


Current Resident Work

██████████

Occupancy بیشتر
می تواند گزینه های بیشتری
برای Scheduler فراهم کند،
اما به تنهایی
Performance بیشتر را تضمین نمی کند.

چه چیزی تعداد Threadهای Resident را محدود می کند؟

Registers

مصرف بیشتر Register برای هر Thread
می تواند تعداد Threadهای Resident را کاهش دهد.

Shared Memory

مصرف بیشتر Shared Memory برای هر Block
می تواند تعداد Blockهای Resident را کاهش دهد.

Thread Limits

سخت افزار تعداد مشخصی Thread
را هم زمان پشتیبانی می کند.

Block Limits

تعداد Workgroupهای Resident نیز محدود است.

Resident بودن به معنی Ready بودن نیست

Warp ممکن است
روی GPU Resident باشد
اما نتواند در همان لحظه اجرا شود.


Resident Warps

Warp A → Ready

Warp B → Memory Wait

Warp C → Dependency

Warp D → Ready

Warp E → Barrier

Scheduler
فقط از میان کارهای آماده
می تواند Instruction صادر کند.

Warp Scheduler

Scheduler
از میان Warpهای Ready
یک گروه مناسب
برای اجرای Instruction انتخاب می کند.


Ready Warps

A   C   F   H

     │
     ▼

Scheduler

     │
     ▼

Issue Work

همین سازوکار
کمک می کند
GPU هنگام انتظار یک Warp
کار Warp دیگری را انجام دهد.

Latency Hiding

GPU همیشه Latency را کاهش نمی دهد.

در بسیاری از موارد
اثر آن را
با اجرای کار دیگر
پنهان می کند.


Warp A

Memory Wait
────────────────


Warp B

      Compute
      ─────────


Warp C

               Compute
               ─────────

این روش
برای GPU بسیار مهم است،
زیرا Memory Access
می تواند زمان قابل توجهی نیاز داشته باشد.

Stall

Warp زمانی Stall می شود
که موقتا قادر به ادامه اجرا نباشد.

دلایل رایج:

  • Memory Wait،
  • Instruction Dependency،
  • Synchronization،
  • Execution Resource Contention،
  • و سایر محدودیت های Pipeline.

Execution Pipeline

پس از انتخاب Warp آماده،
Instruction
برای اجرا صادر می شود.


Ready Warp

    │
    ▼

Instruction Issue

    │
    ▼

Execution Unit

    │
    ▼

Result

    │
    ▼

Next Instruction

Execution Units

GPU می تواند
انواع مختلفی از واحدهای اجرایی داشته باشد.

نوع واحد کاربرد عمومی
Floating-Point محاسبات اعشاری
Integer محاسبات Integer
Load / Store عملیات مربوط به حافظه
Special Function برخی عملیات خاص ریاضی
Matrix / Tensor محاسبات ماتریسی در GPUهای مجهز

Instruction Dependency

اگر Instruction بعدی
به نتیجه Instruction قبلی نیاز داشته باشد،
امکان اجرای فوری آن وجود ندارد.


Instruction A

    │
    ▼

Result A

    │
    ▼

Instruction B

    │
    ▼

Result B

    │
    ▼

Instruction C

وابستگی زیاد
می تواند Parallelism قابل استفاده
را کاهش دهد.

Instruction-Level Parallelism

اگر چند Instruction
مستقل از یکدیگر باشند،
سخت افزار فرصت بیشتری
برای هم پوشانی اجرای آنها دارد.


Independent

A = X + Y

B = P * Q

C = M - N

این مفهوم
Instruction-Level Parallelism
یا
ILP
نام دارد.

GPU از چند نوع Parallelism استفاده می کند

Thread-Level

تعداد بسیار زیادی Thread مستقل.

Warp-Level

چندین Warp یا Wave آماده برای Scheduling.

Instruction-Level

Instructionهای مستقل در یک جریان اجرا.

Unit-Level

استفاده از واحدهای مختلف سخت افزاری به صورت موازی.

Execution Architecture و Memory Architecture از هم جدا نیستند

اجرای GPU
به صورت مستقیم
به Memory System وابسته است.


Execution

Registers
Shared Memory
Warp Scheduling
Occupancy

      │
      │ interact
      ▼

Memory

Cache
Latency
Bandwidth
VRAM

برای مثال:

  • Register Usage روی Occupancy اثر می گذارد.
  • Memory Latency روی Ready Warpها اثر می گذارد.
  • Shared Memory مصرف Blockها را محدود می کند.
  • Memory Bottleneck می تواند Scheduler را با کمبود کار آماده مواجه کند.

Under the Hood — راز اصلی GPU داشتن کار آماده است

اگر بخواهیم
بخش بزرگی از Execution Architecture GPU
را در یک ایده خلاصه کنیم،
آن ایده این است:

واحدهای اجرایی را
تا حد امکان با کار آماده تغذیه کن.

GPU برای رسیدن به این هدف
از ابزارهای مختلفی استفاده می کند:


Many Threads

    │
    ▼

Many Warps / Waves

    │
    ▼

Resident Work

    │
    ▼

Ready Work

    │
    ▼

Fast Scheduling

    │
    ▼

Busy Execution Units

Performance Impact — چه چیزی GPU را کند می کند؟

Performance می تواند
به دلایل بسیار متفاوتی محدود شود:


Low GPU Throughput

      │
      ├── Memory Stalls
      ├── Branch Divergence
      ├── Low Ready-Warp Count
      ├── Resource Pressure
      ├── Instruction Dependencies
      ├── Synchronization
      └── Execution Unit Bottleneck

به همین دلیل
یک Optimization واحد
برای تمام GPU Workloadها وجود ندارد.

Engineering Insight — GPU برای Throughput ساخته شده است

CPU اغلب تلاش می کند
یک Thread پیچیده را
با Latency پایین جلو ببرد.

GPU بیشتر تلاش می کند
در یک بازه زمانی
حجم بسیار بزرگی از کار
را تمام کند.


CPU

Lower Thread Count
+
Strong Single-Thread Execution


GPU

Huge Thread Count
+
High Aggregate Throughput

این تفاوت
یکی از مهم ترین پایه های
معماری CPU و GPU است.

بعد از این بخش باید بتوانید…

  • Thread را در معماری GPU تعریف کنید.
  • Workgroup و Warp را از یکدیگر جدا کنید.
  • SIMT را توضیح دهید.
  • Branch Divergence را تشخیص دهید.
  • Occupancy را به صورت مفهومی توضیح دهید.
  • Resident Warp و Ready Warp را از هم تفکیک کنید.
  • نقش Warp Scheduler را توضیح دهید.
  • Latency Hiding را شرح دهید.
  • Execution Pipeline را از Dispatch تا Result دنبال کنید.
  • Instruction Dependency را تشخیص دهید.
  • Instruction-Level Parallelism را توضیح دهید.
  • ارتباط Execution Architecture و Memory Architecture را درک کنید.

سوالات متداول GPU Execution Architecture

آیا هر Thread روی یک Core جدا اجرا می شود؟

خیر.

تعداد Threadهای فعال
می تواند بسیار بیشتر
از تعداد واحدهای اجرایی فیزیکی باشد.

GPU Threadها را
در طول زمان
و به صورت گروهی اجرا می کند.

Warp چیست؟

گروه اجرایی Threadها
در معماری NVIDIA است.

در CUDA،
هر Warp شامل 32 Thread است.

Occupancy بیشتر همیشه بهتر است؟

خیر.

Occupancy فقط یکی از عوامل Performance است
و پس از فراهم شدن کار آماده کافی،
افزایش بیشتر آن
ممکن است سود قابل توجهی ایجاد نکند.

Branch Divergence چیست؟

زمانی رخ می دهد
که Threadهای یک Warp یا Wave
مسیرهای متفاوتی در Branch انتخاب کنند.

Warp Scheduler چه کاری انجام می دهد؟

از میان Warpهای آماده
کار قابل اجرا را انتخاب می کند
و به Latency Hiding کمک می کند.

چرا GPU هزاران Thread اجرا می کند؟

زیرا Parallelism زیاد
به GPU اجازه می دهد
هم حجم بزرگی از کار را پردازش کند
و هم زمان انتظار برخی Threadها
را با اجرای Threadهای دیگر پنهان کند.

GPU بیشتر به Latency اهمیت می دهد یا Throughput؟

در طراحی عمومی GPU،
Throughput کل تعداد زیادی Thread
معمولا هدف مهم تری
از کمینه کردن Latency یک Thread منفرد است.

خلاصه نهایی GPU Execution Architecture

  • GPU تعداد بسیار زیادی Thread را به شکل موازی مدیریت می کند.
  • Threadها ابتدا در Workgroup یا Block سازمان دهی می شوند.
  • در سطح سخت افزار، Threadها در Warp یا Wave اجرا می شوند.
  • SIMT پایه اجرای گروهی Threadها است.
  • Branch Divergence می تواند بخشی از ظرفیت اجرایی را غیرفعال کند.
  • Occupancy تعداد کارهای Resident را توصیف می کند.
  • Register و Shared Memory می توانند Occupancy را محدود کنند.
  • Scheduler از میان Warpهای Ready کار قابل اجرا را انتخاب می کند.
  • Warpهای Stall شده ممکن است منتظر Memory، Dependency یا Synchronization باشند.
  • GPU با اجرای Warpهای دیگر Latency را پنهان می کند.
  • Execution Pipeline شامل Scheduling، Issue، Execute و Result است.
  • Instructionهای مستقل می توانند ILP ایجاد کنند.
  • هدف اصلی معماری Execution حفظ Throughput بالا است.


سطح: مقدماتی تا متوسط

پیش نیاز:
GPU Core Architecture،
GPU Memory Architecture،
GPU Execution Architecture

موضوع:
GPU Graphics Pipeline

زمان مطالعه:
حدود 10 تا 12 دقیقه


GPU GRAPHICS PIPELINE

Graphics Pipeline در GPU چیست؟

وقتی یک بازی یا نرم افزار سه بعدی
یک Scene را نمایش می دهد،
GPU مستقیما مدل سه بعدی را
به تصویر نهایی تبدیل نمی کند.

داده باید از چند مرحله عبور کند:

Vertexها پردازش می شوند،
Primitiveها شکل می گیرند،
هندسه به Pixelهای قابل نمایش تبدیل می شود
و در نهایت رنگ هر بخش از تصویر محاسبه می شود.

مجموع این مراحل
Graphics Pipeline نام دارد.


پاسخ سریع

Graphics Pipeline
زنجیره مراحلی است
که داده سه بعدی را
به تصویر دوبعدی قابل نمایش
روی صفحه تبدیل می کند.

در یک مدل ساده:

Vertex Data
پردازش می شود،
Primitiveها ساخته می شوند،
Rasterization آنها را به Fragment یا Pixel Candidate تبدیل می کند
و Pixel Shader
ظاهر نهایی آنها را محاسبه می کند.

در این بخش چه چیزهایی یاد می گیریم؟

  • Graphics Pipeline چیست.
  • Vertex چیست.
  • Primitive چیست.
  • Vertex Shader چه کاری انجام می دهد.
  • Rasterization چیست.
  • Pixel Shader یا Fragment Shader چه نقشی دارد.
  • Depth Test چیست.
  • Blending چیست.
  • Frame Buffer چگونه ساخته می شود.
  • چگونه تصویر نهایی برای نمایش آماده می شود.

نقشه مفهومی Graphics Pipeline


01


Vertex Data

اطلاعات هندسی مدل وارد Pipeline می شود.


02


Vertex Processing

موقعیت Vertexها و برخی Attributeها پردازش می شوند.


03


Rasterization

Primitiveها به بخش های قابل پردازش روی صفحه تبدیل می شوند.


04


Pixel Processing

رنگ و ظاهر نهایی Pixelها محاسبه می شود.

تصویر کلی Graphics Pipeline


3D Model Data

      │
      ▼

Vertex Processing

      │
      ▼

Primitive Assembly

      │
      ▼

Clipping / Viewport

      │
      ▼

Rasterization

      │
      ▼

Pixel / Fragment Processing

      │
      ▼

Depth / Stencil Tests

      │
      ▼

Blending

      │
      ▼

Frame Buffer

      │
      ▼

Display

این مدل
یک نسخه ساده شده از Graphics Pipeline است.

APIها و GPUهای مدرن
می توانند مراحل بیشتری داشته باشند،
اما همین زنجیره
برای درک تصویر کلی کافی است.

Graphics Pipeline از چه داده ای شروع می شود؟

مدل سه بعدی
معمولا از مجموعه ای از Vertexها
و اطلاعات مرتبط با آنها ساخته می شود.

Position

موقعیت Vertex در فضای سه بعدی.

Normal

جهت Surface برای محاسبات نور.

Texture Coordinate

مشخص می کند کدام بخش Texture به Surface مربوط است.

Color

رنگ یا Attribute اضافی Vertex.

Vertex چیست؟


Vertex

Vertex یک نقطه منطقی
از هندسه مدل است
که می تواند علاوه بر Position،
اطلاعات دیگری مانند Normal،
Color
و Texture Coordinate
نیز داشته باشد.


Vertex

Position
Normal
UV
Color
Other Attributes

Vertex فقط یک نقطه تصویری نیست؛
بلکه مجموعه ای از Attributeها
برای ساخت و پردازش Geometry است.

چرا Triangle این قدر مهم است؟

در Graphics سه بعدی،
Triangle
یکی از رایج ترین Primitiveها است.


      V0
      /
     /  
    /    
   /      
 V1────────V2

سه Vertex
یک Triangle می سازند.

مدل های پیچیده
از تعداد زیادی Triangle
تشکیل می شوند.


Simple Object

Triangle
Triangle
Triangle
Triangle
Triangle
...

        │
        ▼

3D Mesh

Vertex Shader چه کاری انجام می دهد؟

Vertex Shader
روی Vertexها اجرا می شود.

یکی از مهم ترین وظایف آن
تبدیل Position
از فضای مدل
به فضای مناسب برای Rendering است.


Vertex Position

Model Space

     │
     ▼

Vertex Shader

     │
     ▼

World / View / Clip Transformation

     │
     ▼

Screen-Oriented Position

Vertex Shader
می تواند Attributeهای دیگری
را نیز محاسبه یا تغییر دهد.

یک مثال ساده از Vertex Shader


VSOutput VSMain(VSInput input)
{
    VSOutput output;

    output.position =
        mul(float4(input.position, 1.0),
            WorldViewProjection);

    output.uv = input.uv;

    return output;
}

در این مثال،
Position سه بعدی
به فضای Clip تبدیل می شود
و Texture Coordinate
برای مراحل بعدی ارسال می شود.

Primitive Assembly چیست؟

پس از پردازش Vertexها،
GPU باید بداند
کدام Vertexها
یک Primitive را تشکیل می دهند.


V0
V1
V2
V3
V4
V5

      │
      ▼

Primitive Assembly

      │
      ▼

Triangle 0
V0 V1 V2


Triangle 1
V3 V4 V5

Index Buffer
نیز می تواند مشخص کند
کدام Vertexها
برای ساخت Primitive استفاده شوند.

Clipping چیست؟

همه Geometryهای Scene
الزاما داخل محدوده قابل مشاهده Camera نیستند.

Clipping
بخش هایی از Primitive
را که خارج از محدوده قابل نمایش هستند
حذف یا اصلاح می کند.


View Area

┌────────────────────┐
│                    │
│      Triangle      │──────
│                    │
└────────────────────┘
                     
                      
                 Outside Area

قسمت های خارج از محدوده
نباید به شکل عادی
در تصویر نهایی ظاهر شوند.

Viewport Transform چیست؟

پس از پردازش هندسه،
مختصات باید
به ناحیه واقعی تصویر
روی Screen Mapping شوند.


Normalized / Clip Coordinates

        │
        ▼

Viewport Transform

        │
        ▼

Screen Coordinates

X = Pixel Position
Y = Pixel Position

Rasterization چیست؟


Rasterization

فرایند تبدیل Primitiveهای هندسی
به Fragmentها یا Pixel Candidateهایی است
که بخش هایی از تصویر
را پوشش می دهند.


Triangle

      /
     /  
    /    
   /______

      │
      ▼

Rasterization

      │
      ▼

■■■■
■■■■■■
■■■■■■■■

Rasterizer مشخص می کند
کدام نواحی Screen
توسط Primitive پوشش داده شده اند.

Attributeها چگونه بین Vertexها پخش می شوند؟

هر Vertex
ممکن است UV،
Color،
Normal
یا Attribute دیگری داشته باشد.

هنگام Rasterization،
این مقادیر
در سطح Triangle
Interpolation می شوند.


Vertex A
Color = Red

Vertex B
Color = Green

Vertex C
Color = Blue

        │
        ▼

Interpolation

        │
        ▼

Smooth Values
Across Triangle

Pixel Shader یا Fragment Shader چیست؟

پس از Rasterization،
Pixel Shader
برای محاسبه ظاهر Fragmentها اجرا می شود.

این Shader می تواند
از داده هایی مانند:

  • Texture،
  • Normal،
  • Light،
  • Material،
  • Color،
  • و سایر Attributeها

استفاده کند.


Interpolated Data

      │
      ▼

Pixel Shader

      │
      ├── Texture Sampling
      ├── Lighting
      ├── Material
      └── Effects

      │
      ▼

Output Color

یک Pixel Shader ساده


float4 PSMain(PSInput input) : SV_Target
{
    float4 color =
        DiffuseTexture.Sample(
            LinearSampler,
            input.uv
        );

    return color;
}

در این مثال،
Pixel Shader
Texture را Sample می کند
و رنگ حاصل را
به عنوان Output برمی گرداند.

Texture Sampling چیست؟

Texture
یک تصویر یا مجموعه داده
است که روی Surface استفاده می شود.

Texture Coordinate مشخص می کند
کدام قسمت Texture
برای Fragment فعلی
مورد نیاز است.


Texture

┌──────────────────────┐
│                      │
│        ●             │
│                      │
└──────────────────────┘
         ▲
         │
        UV

         │
         ▼

Texture Sample

         │
         ▼

Color / Data

Depth Test چیست؟

در یک Scene سه بعدی
ممکن است چند Surface
روی یک Pixel از Screen
قرار بگیرند.

Depth Test
کمک می کند مشخص شود
کدام Surface
به Camera نزدیک تر است.


Camera

  │
  ▼

Object A
Depth = Near

Object B
Depth = Far

  │
  ▼

Visible Pixel

Object A

Depth Buffer چیست؟

Depth Buffer
برای هر بخش از تصویر
اطلاعات مربوط به عمق
را نگهداری می کند.


Color Buffer

Pixel Colors


Depth Buffer

Pixel Depth Values

هنگام Rendering،
عمق Fragment جدید
با مقدار موجود
مقایسه می شود.

Stencil Test چیست؟

Stencil Buffer
می تواند برای ایجاد Mask
و کنترل اینکه کدام بخش های تصویر
اجازه Rendering داشته باشند
استفاده شود.


Stencil Mask

0 0 0 0
0 1 1 0
0 1 1 0
0 0 0 0

      │
      ▼

Render Only
Where Allowed

Stencil
در تکنیک های مختلف گرافیکی
کاربرد دارد.

Blending چیست؟

پس از محاسبه رنگ Fragment،
ممکن است این رنگ
با رنگی که قبلا
در Frame Buffer وجود دارد
ترکیب شود.

این مرحله
Blending نام دارد.


Existing Pixel Color

        +

New Fragment Color

        │
        ▼

Blending

        │
        ▼

Final Pixel Color

Transparency
یکی از کاربردهای معروف Blending است.

Frame Buffer چیست؟

Frame Buffer
حافظه ای است
که نتیجه Rendering
در آن نگهداری می شود.


Rendered Pixels

      │
      ▼

Frame Buffer

┌────────────────────┐
│                    │
│   Final Image      │
│                    │
└────────────────────┘

این تصویر
بعدا می تواند
برای نمایش،
Post Processing
یا مراحل دیگر استفاده شود.

Under the Hood — همه مراحل Graphics Pipeline قابل برنامه نویسی نیستند

Graphics Pipeline
ترکیبی از مراحل
Programmable
و Fixed-Function است.

مرحله نوع کلی
Vertex Shader Programmable
Rasterization Fixed-Function
Pixel / Fragment Shader Programmable
Depth / Stencil Fixed-Function Hardware
Blending Fixed-Function Hardware

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

Engineering Insight — Graphics Pipeline یک خط مستقیم ساده نیست

نمودارهای آموزشی
Graphics Pipeline
را مانند یک زنجیره ساده نشان می دهند.

اما در GPU واقعی،
مراحل مختلف می توانند:

  • به صورت Pipeline اجرا شوند،
  • روی داده های متفاوت هم زمان کار کنند،
  • از Cache و Memory مشترک استفاده کنند،
  • و با مراحل دیگر هم پوشانی داشته باشند.

Graphics Pipeline
بیشتر شبیه یک کارخانه موازی است
تا یک صف تک مرحله ای.

Performance Impact — Bottleneck می تواند در هر مرحله باشد

یک Scene
ممکن است در مراحل مختلف
محدود شود.


Possible Bottlenecks

Vertex Processing

Geometry

Rasterization

Pixel Shading

Texture Sampling

Memory Bandwidth

Depth / Blending

برای مثال،
Scene دارای Geometry بسیار زیاد
می تواند فشار بیشتری روی
مراحل ابتدایی Pipeline ایجاد کند.

Scene دارای Shaderهای سنگین
می تواند Pixel یا Compute Units
را بیشتر درگیر کند.

Common Mistakes — اشتباهات رایج درباره Graphics Pipeline
  • Graphics Pipeline را فقط Pixel Shader ندانید.
  • Vertex را فقط یک مختصات سه بعدی فرض نکنید.
  • Rasterization را با Pixel Shading یکی ندانید.
  • Fragment را همیشه دقیقا معادل Pixel ندانید.
  • Depth Test را با Blending یکی ندانید.
  • Frame Buffer را فقط تصویر نمایش داده شده فعلی فرض نکنید.
  • تمام مراحل Pipeline را Programmable تصور نکنید.
  • Graphics Pipeline را مستقل از Memory System و Execution Architecture تحلیل نکنید.

مدل ذهنی ساده


3D Geometry

     │
     ▼

Vertex Shader

     │
     ▼

Triangles

     │
     ▼

Rasterizer

     │
     ▼

Fragments

     │
     ▼

Pixel Shader

     │
     ▼

Depth / Stencil

     │
     ▼

Blending

     │
     ▼

Frame Buffer

     │
     ▼

Image

سوالات متداول درباره Graphics Pipeline

Graphics Pipeline چیست؟

مجموعه مراحلی است
که داده هندسی سه بعدی
را به تصویر دوبعدی
قابل ذخیره و نمایش
تبدیل می کند.

Vertex Shader چه کاری انجام می دهد؟

روی Vertexها اجرا می شود
و می تواند Position
و Attributeهای آنها
را پردازش کند.

Rasterization چیست؟

فرایند تبدیل Primitiveهای هندسی
به Fragmentها
یا نواحی قابل پردازش
روی تصویر است.

Pixel Shader چه کاری انجام می دهد؟

ظاهر Fragment
را با استفاده از Texture،
Material،
Lighting
و سایر داده ها
محاسبه می کند.

Depth Test چیست؟

آزمایشی است
که کمک می کند مشخص شود
کدام Fragment
از نظر عمق
باید در تصویر باقی بماند.

Blending چیست؟

فرایند ترکیب
رنگ Fragment جدید
با رنگ موجود
در Render Target است.

خلاصه فصل

  • Graphics Pipeline داده سه بعدی را به تصویر نهایی تبدیل می کند.
  • Vertexها داده هندسی و Attributeها را نگهداری می کنند.
  • Triangle یکی از مهم ترین Primitiveهای گرافیکی است.
  • Vertex Shader موقعیت و Attributeهای Vertexها را پردازش می کند.
  • Primitive Assembly هندسه را از Vertexها می سازد.
  • Rasterization Primitiveها را به Fragmentهای قابل پردازش تبدیل می کند.
  • Attributeها میان Vertexها Interpolate می شوند.
  • Pixel Shader ظاهر Fragmentها را محاسبه می کند.
  • Depth Test مشخص می کند کدام Surface در جلو قرار دارد.
  • Stencil برای Mask و کنترل Rendering استفاده می شود.
  • Blending رنگ جدید و رنگ موجود را ترکیب می کند.
  • Frame Buffer نتیجه Rendering را نگهداری می کند.
  • Graphics Pipeline ترکیبی از مراحل Programmable و Fixed-Function است.

سطح: مقدماتی تا متوسط

پیش نیاز:
Graphics Pipeline،
Pixel Shader،
VRAM،
Cache

موضوع:
GPU Graphics Pipeline

زمان مطالعه:
حدود 8 تا 10 دقیقه


GPU GRAPHICS PIPELINE

Texture Unit چیست و Texture Sampling چگونه انجام می شود؟

Textureها بخش بزرگی از ظاهر نهایی
بازی ها و تصاویر سه بعدی را می سازند.

اما Shader معمولا
مستقیما یک Byte خاص از Texture
را از VRAM نمی خواند.

GPU واحدهای تخصصی دارد
که آدرس دهی،
Filtering
و Sample کردن Texture
را با سرعت بالا انجام می دهند.

این واحدها
Texture Unit نامیده می شوند.


پاسخ سریع

Texture Unit
بخشی تخصصی از GPU است
که عملیات مربوط به خواندن Texture،
محاسبه محل Sample،
Filtering
و آماده کردن داده Texture
برای Shader را انجام می دهد.

Texture Sampling
فرایند دریافت مقدار مناسب
از Texture
بر اساس مختصات Texture
و تنظیمات Sampling است.

در این فصل چه چیزهایی یاد می گیریم؟

  • Texture چیست.
  • Texel چیست.
  • Texture Coordinate چیست.
  • Texture Unit چه کاری انجام می دهد.
  • Texture Sampling چیست.
  • Nearest و Bilinear Filtering چه تفاوتی دارند.
  • Mipmapping چیست.
  • Trilinear و Anisotropic Filtering چه کاربردی دارند.
  • Texture Cache چرا مهم است.

Texture چیست؟

Texture
یک مجموعه داده منظم است
که معمولا برای ذخیره اطلاعات تصویری
یا داده های Surface استفاده می شود.

یک Texture
فقط برای Color نیست.

Color Texture

رنگ Surface را نگهداری می کند.

Normal Map

اطلاعات جهت Surface را برای Lighting فراهم می کند.

Roughness / Metalness

ویژگی های Material را ذخیره می کند.

Depth Texture

اطلاعات عمق را نگهداری می کند.

Texel چیست؟


Texel

Texel
کوچک ترین عنصر منطقی
یک Texture است.


Texture

┌───┬───┬───┬───┐
│ T │ T │ T │ T │
├───┼───┼───┼───┤
│ T │ T │ T │ T │
├───┼───┼───┼───┤
│ T │ T │ T │ T │
└───┴───┴───┴───┘

T = Texel

در Texture رنگی،
هر Texel می تواند
اطلاعاتی مانند
Red،
Green،
Blue
و Alpha
داشته باشد.

Texel و Pixel یکی نیستند

مفهوم معنا
Texel عنصر داخل Texture
Pixel عنصر تصویر نهایی یا Render Target

یک Pixel
ممکن است از چند Texel
اطلاعات دریافت کند.

یک Texel نیز ممکن است
روی چند Pixel مختلف
اثر بگذارد.

Texture Coordinate یا UV چیست؟

Texture Coordinate
مشخص می کند
کدام ناحیه Texture
باید روی یک نقطه از Surface استفاده شود.

برای Texture دو بعدی
معمولا از مختصات
U
و
V
استفاده می شود.


Texture

V
▲
│
│   (U,V)
│      ●
│
└────────────► U

در بسیاری از کاربردها،
مختصات UV
به صورت Normalized
بین 0 و 1 بیان می شوند.

Texture چگونه روی مدل قرار می گیرد؟

Vertexهای مدل
می توانند Texture Coordinate داشته باشند.


Triangle

V0 → UV(0,0)

V1 → UV(1,0)

V2 → UV(0.5,1)

        │
        ▼

Interpolation

        │
        ▼

UV for each Fragment

GPU این مختصات را
در سطح Triangle
Interpolation می کند
تا Pixel Shader
بداند از کدام بخش Texture
Sample بگیرد.

Texture Unit چه کاری انجام می دهد؟

Texture Unit
بخشی تخصصی برای عملیات Texture است.


Shader

  │
  │ Texture Sample Request
  ▼

Texture Unit

  │
  ├── Address Calculation
  ├── Texture Lookup
  ├── Filtering
  └── Format Handling

  │
  ▼

Sample Result

  │
  ▼

Shader

این واحد تخصصی
باعث می شود Shader Coreها
مجبور نباشند
تمام عملیات Sampling
را با دستورهای عمومی انجام دهند.

Texture Sampling چگونه انجام می شود؟

Pixel Shader
مختصات Texture را
به Sampler می دهد.


UV Coordinate

      │
      ▼

Sampler State

      │
      ▼

Texture Unit

      │
      ▼

Select Texel(s)

      │
      ▼

Filtering

      │
      ▼

Sampled Value

Nearest Filtering

ساده ترین روش Sampling
انتخاب نزدیک ترین Texel
به مختصات مورد نظر است.


Texels

A   B

C   D

    ● Sample Point

Nearest Texel

→ B

این روش ساده و سریع است،
اما در بزرگ نمایی Texture
می تواند ظاهر Pixelated ایجاد کند.

Bilinear Filtering

در Bilinear Filtering
به جای انتخاب یک Texel،
چند Texel نزدیک
برای تولید مقدار نهایی
ترکیب می شوند.


A ───── B
│   ●   │
│       │
C ───── D

Sample

≈ Weighted Combination
of A, B, C, D

نتیجه معمولا
نرم تر از Nearest Filtering است.

وقتی Texture خیلی دور می شود چه اتفاقی می افتد؟

فرض کنید یک Texture بزرگ
روی یک Surface بسیار کوچک
در تصویر نمایش داده شود.


Large Texture

████████████████████

        │
        ▼

Tiny Screen Area

██

تعداد زیادی Texel
باید به تعداد کمی Pixel
تبدیل شوند.

استفاده مستقیم از Texture اصلی
می تواند هم کیفیت تصویر
و هم Efficiency را کاهش دهد.

برای حل این مشکل
از Mipmapping استفاده می شود.

Mipmapping چیست؟


Mipmaps

نسخه های کوچک تر
از یک Texture اصلی هستند
که برای نمایش Texture
در اندازه های مختلف استفاده می شوند.


Mip Level 0

████████████████

Mip Level 1

████████

Mip Level 2

████

Mip Level 3

██

Mip Level 4

█

وقتی Surface دورتر شود،
GPU می تواند
از Mip Level کوچک تر استفاده کند.

Mipmaps چه مزیتی دارند؟

  • کاهش Aliasing در Textureهای دور،
  • کاهش نیاز به خواندن داده بسیار بزرگ،
  • بهبود Cache Locality،
  • و بهبود کیفیت Sampling.


Far Object

Without Mipmap

Large Texture
      │
      ▼
Too Much Detail


With Mipmap

Smaller Texture Level
      │
      ▼
More Suitable Data

Trilinear Filtering چیست؟

گاهی اندازه مناسب Texture
دقیقا بین دو Mip Level قرار دارد.

Trilinear Filtering
نمونه های دو Mip Level مجاور
را با یکدیگر ترکیب می کند.


Mip Level 2

      │
      ├── Bilinear Sample
      │
      ▼

      Mix

      ▲
      │
      ├── Bilinear Sample
      │

Mip Level 3

      │
      ▼

Final Sample

هدف
ایجاد انتقال نرم تر
میان Mip Levelها است.

Anisotropic Filtering چیست؟

وقتی Surface
با زاویه زیاد نسبت به Camera دیده شود،
ناحیه مورد نیاز Texture
شکل ساده مربعی ندارد.


Front-Facing Surface

Texture Footprint

□


Angled Surface

Texture Footprint

────────────

Anisotropic Filtering
برای چنین شرایطی
نمونه برداری دقیق تری انجام می دهد.

این روش
به ویژه برای Surfaceهایی مانند:

  • زمین،
  • جاده،
  • دیوارهای کشیده،
  • و سطوحی که با زاویه دیده می شوند

می تواند کیفیت بیشتری ایجاد کند.

اگر UV خارج از محدوده Texture باشد چه؟

Sampler State
مشخص می کند
در خارج از محدوده اصلی Texture
چه رفتاری انجام شود.

Address Mode رفتار کلی
Wrap Texture تکرار می شود.
Clamp مختصات در لبه Texture محدود می شود.
Mirror Texture به شکل آینه ای تکرار می شود.
Border خارج از محدوده از مقدار Border استفاده می شود.

Texture Cache چرا مهم است؟

Pixelهای نزدیک
اغلب به Texelهای نزدیک
یا حتی یکسان
دسترسی دارند.


Nearby Fragments

F0 F1 F2 F3

 │  │  │  │
 ▼  ▼  ▼  ▼

Nearby Texture Region

T0 T1 T2 T3

این Spatial Locality
برای Cache مناسب است.

Texture Cache
می تواند بخشی از درخواست ها
را بدون مراجعه مجدد
به VRAM پاسخ دهد.

Texture Sample رایگان نیست

هر Texture Sample
می تواند شامل:

  • محاسبه آدرس،
  • Cache Lookup،
  • خواندن داده،
  • Filtering،
  • و گاهی چند Sample داخلی

باشد.

بنابراین Shaderی که
تعداد بسیار زیادی Texture Sample دارد
ممکن است به Texture یا Memory Performance
حساس شود.

Under the Hood — یک Texture Sample لزوما یک Texel Read نیست

بسته به Filtering،
یک Sample منطقی
ممکن است برای محاسبه نتیجه نهایی
به چند Texel نیاز داشته باشد.


Nearest

1 nearby Texel
conceptually selected


Bilinear

Several nearby Texels
combined


Trilinear

Samples from
two Mip Levels


Anisotropic

Potentially more samples
along texture footprint

جزئیات دقیق
به Filtering Mode
و معماری GPU بستگی دارد.

Performance Impact — چه زمانی Texture Sampling Bottleneck می شود؟

Texture Sampling
می تواند اهمیت بیشتری پیدا کند
زمانی که:

  • Shader تعداد Sample زیادی داشته باشد،
  • Textureها بزرگ باشند،
  • Cache Locality ضعیف باشد،
  • Filtering پیچیده باشد،
  • یا Memory Bandwidth تحت فشار باشد.

اما در بسیاری از Shaderها
محاسبات،
Branchها
یا بخش های دیگر
می توانند Bottleneck اصلی باشند.

Engineering Insight — Texture Unit یک نمونه مهم از Fixed-Function Acceleration است

GPU می توانست
تمام عملیات Texture Sampling
را با Shader Coreهای عمومی انجام دهد.

اما چون این عملیات
در Graphics بسیار پرتکرار هستند،
سخت افزار تخصصی
برای آنها طراحی شده است.

هرجا عملیاتی بسیار پرتکرار،
قابل پیش بینی
و قابل تخصصی سازی باشد،
Fixed-Function Hardware
می تواند بسیار موثر باشد.

Common Mistakes — اشتباهات رایج درباره Texture Sampling
  • Texel را با Pixel یکی ندانید.
  • Texture را فقط تصویر رنگی تصور نکنید.
  • یک Texture Sample را همیشه معادل خواندن یک Texel ندانید.
  • Nearest و Bilinear Filtering را یکی ندانید.
  • Mipmapping را فقط برای کاهش مصرف حافظه ندانید.
  • Anisotropic Filtering را فقط یک Sharpening ساده فرض نکنید.
  • Texture Unit را با Shader Core یکی ندانید.
  • تعداد Texture Sample را بدون در نظر گرفتن Cache و Filtering تحلیل نکنید.

مدل ذهنی ساده Texture Sampling


Pixel / Fragment Shader

        │
        ▼

Texture Coordinate

        │
        ▼

Sampler State

        │
        ▼

Texture Unit

        │
        ├── Choose Mip
        ├── Find Texels
        ├── Fetch Data
        └── Filter

        │
        ▼

Sample Result

        │
        ▼

Shader Continues

سوالات متداول درباره Texture Units

Texture Unit چیست؟

واحدی تخصصی در GPU است
که عملیات مربوط به Texture Lookup،
Addressing
و Filtering را انجام می دهد.

Texel چیست؟

کوچک ترین عنصر منطقی
یک Texture است.

Texel و Pixel چه تفاوتی دارند؟

Texel عنصر Texture است،
در حالی که Pixel
عنصر تصویر یا Render Target است.

Mipmapping چیست؟

استفاده از نسخه های کوچک تر
یک Texture
برای نمایش آن
در اندازه ها و فاصله های مختلف است.

Bilinear Filtering چیست؟

روشی است
که چند Texel نزدیک
را برای تولید Sample نهایی
با یکدیگر ترکیب می کند.

Anisotropic Filtering چه کاری انجام می دهد؟

Sampling را برای Surfaceهایی
که با زاویه زیاد نسبت به Camera دیده می شوند
بهبود می دهد.

خلاصه فصل

  • Texture مجموعه داده ای است که برای Surfaceها و بسیاری از کاربردهای گرافیکی استفاده می شود.
  • Texel عنصر منطقی داخل Texture است.
  • Texel و Pixel یک مفهوم نیستند.
  • UV مشخص می کند کدام بخش Texture باید Sample شود.
  • Texture Unit عملیات تخصصی Sampling را انجام می دهد.
  • Nearest نزدیک ترین Texel را انتخاب می کند.
  • Bilinear چند Texel نزدیک را ترکیب می کند.
  • Mipmaps نسخه های کوچک تر Texture هستند.
  • Trilinear میان Mip Levelهای مجاور ترکیب انجام می دهد.
  • Anisotropic Filtering برای Surfaceهای زاویه دار مناسب است.
  • Texture Cache می تواند درخواست های تکراری و نزدیک را سریع تر پاسخ دهد.
  • Texture Sampling می تواند بخشی مهم از هزینه Pixel Shader باشد.

سطح: مقدماتی تا متوسط

پیش نیاز:
Graphics Pipeline،
Pixel Shader،
Depth Test،
Blending،
Frame Buffer

موضوع:
GPU Graphics Pipeline

زمان مطالعه:
حدود 8 تا 10 دقیقه


GPU GRAPHICS PIPELINE

ROP چیست و Render Output Unit چه کاری انجام می دهد؟

بعد از اینکه Pixel Shader
رنگ Fragment را محاسبه کرد،
کار هنوز تمام نشده است.

GPU باید بررسی کند
آیا Fragment از Depth Test عبور می کند،
آیا Stencil اجازه نوشتن می دهد،
آیا رنگ باید با مقدار قبلی ترکیب شود
و در نهایت نتیجه چگونه
در Render Target نوشته شود.

این بخش از Pipeline
به طور سنتی با
ROP یا Render Output Unit
مرتبط است.


پاسخ سریع

ROP یا Render Output Unit
بخش انتهایی Graphics Pipeline است
که عملیات مربوط به
Depth / Stencil،
Blending
و نوشتن نتیجه در Render Target
را مدیریت می کند.

این واحد
میان Pixel Shader
و Frame Buffer
قرار می گیرد
و نقش مهمی در تولید تصویر نهایی دارد.

در این فصل چه چیزهایی یاد می گیریم؟

  • ROP چیست.
  • Render Output Stage چه کاری انجام می دهد.
  • Depth Test چگونه به ROP مرتبط است.
  • Stencil Test چه نقشی دارد.
  • Blending در کجا انجام می شود.
  • Render Target چیست.
  • Pixel Fill Rate چیست.
  • چرا تعداد ROPها به تنهایی Performance را تعیین نمی کند.

ROP در کجای Graphics Pipeline قرار دارد؟


Rasterization

      │
      ▼

Pixel / Fragment Shader

      │
      ▼

Depth / Stencil

      │
      ▼

Blending

      │
      ▼

Render Target Write

      │
      ▼

Frame Buffer

در یک مدل آموزشی ساده،
ROP را می توان
در بخش انتهایی Pipeline
و نزدیک به نوشتن خروجی نهایی در نظر گرفت.

Render Target چیست؟


Render Target

حافظه ای است
که GPU نتیجه Rendering
را در آن می نویسد.

این نتیجه
می تواند تصویر نهایی
یا یک تصویر میانی
برای مراحل بعدی باشد.


Pixel Shader Output

        │
        ▼

Render Output Stage

        │
        ▼

Render Target

┌─────────────────────┐
│                     │
│     Image Data      │
│                     │
└─────────────────────┘

Depth Test چه نقشی دارد؟

اگر چند Fragment
برای یک ناحیه از تصویر
رقابت کنند،
GPU باید بداند
کدام یک جلوتر است.


Fragment A
Depth = 0.2

Fragment B
Depth = 0.8

        │
        ▼

Depth Test

        │
        ▼

Keep Nearer Fragment

اگر Fragment
Depth Test را رد کند،
ممکن است دیگر
نیازی به نوشتن رنگ آن
در Render Target نباشد.

Stencil Test

Stencil Buffer
مانند یک Mask قابل کنترل عمل می کند.

برنامه می تواند مشخص کند
که Rendering
در کدام ناحیه ها
اجازه انجام داشته باشد.


Stencil Buffer

0 0 0 0 0
0 1 1 1 0
0 1 1 1 0
0 0 0 0 0

        │
        ▼

Render Only
Where Condition Passes

Blending در ROP چه کاری انجام می دهد؟

گاهی رنگ جدید
نباید مستقیما جایگزین رنگ قبلی شود.

مثلا برای Transparency
ممکن است رنگ جدید
با رنگ موجود
ترکیب شود.


Destination Color

        +

Source Color

        │
        ▼

Blend Operation

        │
        ▼

Final Color

Blending
یکی از وظایف مهم
مرحله Render Output است.

Alpha Blending

یکی از معروف ترین کاربردهای Blending
Transparency است.

Alpha
معمولا مقدار شفافیت
یا سهم Source Color
را مشخص می کند.


Source Color
      │
      │ Alpha
      ▼

Destination Color

      │
      ▼

Blend

      │
      ▼

Final Pixel

فرمول دقیق Blend
به تنظیمات Pipeline
بستگی دارد.

Multiple Render Targets چیست؟

در بعضی تکنیک های Rendering،
Pixel Shader
می تواند هم زمان
به چند Render Target
خروجی بدهد.


Pixel Shader

      │
      ├──► Render Target 0
      │      Color
      │
      ├──► Render Target 1
      │      Normal
      │
      └──► Render Target 2
             Material Data

این روش
در تکنیک هایی مانند
Deferred Rendering
کاربرد دارد.

Pixel Fill Rate چیست؟


Pixel Fill Rate

یک معیار نظری
برای تعداد Pixelهایی است
که GPU می تواند
در واحد زمان
در بخش خروجی پردازش کند.

در مدل ساده،
این مقدار
با تعداد ROPها
و Clock مرتبط است.


ROP Count

   ×

Clock Rate

   │
   ▼

Theoretical Pixel Fill Rate

اما این عدد
Performance واقعی بازی
را به تنهایی مشخص نمی کند.

چه زمانی Fill Rate مهم می شود؟

اگر Workload
تعداد بسیار زیادی Pixel
یا Render Target Write
داشته باشد،
بخش خروجی Pipeline
می تواند تحت فشار قرار گیرد.


High Resolution
      +
Many Layers
      +
Multiple Render Targets
      +
Heavy Blending

      │
      ▼

More Render Output Work

در این شرایط،
ROP Throughput
و Memory Bandwidth
می توانند اهمیت بیشتری پیدا کنند.

Overdraw چیست؟

Overdraw زمانی رخ می دهد
که یک Pixel
چندین بار
توسط Geometryهای مختلف
پردازش و بازنویسی شود.


Same Screen Pixel

Object A
   │
   ▼

Object B
   │
   ▼

Object C
   │
   ▼

Final Visible Color

اگر تعداد زیادی Fragment
در نهایت دیده نشوند،
بخشی از کار Rendering
عملا به تصویر نهایی کمک نکرده است.

Early Depth Test چرا مفید است؟

اگر GPU بتواند
قبل از انجام Pixel Shading سنگین
تشخیص دهد
که Fragment پشت Surface دیگری قرار دارد،
می تواند بخشی از کار غیرضروری
را حذف کند.


Fragment

   │
   ▼

Early Depth Test

   │
   ├── Fail
   │     │
   │     └── Discard Early
   │
   └── Pass
         │
         ▼
      Pixel Shader

این روش
می تواند Overdraw پرهزینه
را کاهش دهد.

آیا Depth Test همیشه قبل از Pixel Shader است؟

نه لزوما.

Graphics Pipeline واقعی
می تواند Depth و Stencil
را در زمان های مختلفی
اجرا یا بهینه سازی کند.

برخی Shader Behaviorها
ممکن است باعث شوند
بخشی از تست ها
در مرحله دیرتری انجام شوند.

برای فهم عمومی،
کافی است بدانیم
GPU تلاش می کند
Fragmentهای غیرضروری
را تا حد امکان زود حذف کند.

مرحله نهایی: Color Write

بعد از عبور از تست ها
و انجام Blending،
رنگ نهایی
در Render Target نوشته می شود.


Pixel Shader Result

       │
       ▼

Depth / Stencil

       │
       ▼

Blending

       │
       ▼

Color Write

       │
       ▼

Render Target

این نوشتن
در نهایت به Memory System
و VRAM نیز وابسته است.

ROP و Memory Bandwidth به هم مرتبط هستند

ROP می تواند
Pixelهای زیادی تولید کند،
اما نتیجه باید
در حافظه نوشته شود.


High ROP Throughput

       │
       ▼

Many Pixel Writes

       │
       ▼

Memory System

       │
       ▼

VRAM

اگر Memory Bandwidth کافی نباشد،
توان بالای Render Output
به تنهایی قابل استفاده نخواهد بود.

Under the Hood — ROP فقط «نوشتن Pixel» نیست

در توضیح های بسیار ساده
ROP را فقط
Pixel Writer معرفی می کنند.

اما مرحله Render Output
می تواند مجموعه ای از عملیات را درگیر کند:

  • Depth،
  • Stencil،
  • Blend،
  • Color Write،
  • و مدیریت Formatهای Render Target.

جزئیات دقیق
به معماری GPU
و Graphics API بستگی دارد.

Performance Impact — چه زمانی ROP Bottleneck می شود؟

Render Output
می تواند اهمیت بیشتری پیدا کند
زمانی که Workload:

  • Resolution بسیار بالا داشته باشد،
  • Overdraw زیادی ایجاد کند،
  • از چند Render Target استفاده کند،
  • Blending سنگین داشته باشد،
  • یا حجم زیادی Pixel Write انجام دهد.

اما در بسیاری از بازی ها
Shader،
Texture،
Geometry
یا Memory
می توانند Bottleneck اصلی باشند.

Engineering Insight — ROP Count را جدا از بقیه GPU نبینید

دو GPU
ممکن است تعداد ROP متفاوتی داشته باشند،
اما مقایسه Performance
فقط با این عدد
معنی کاملی ندارد.

باید مواردی مانند:

  • Clock،
  • Memory Bandwidth،
  • Cache،
  • Shader Throughput،
  • Resolution،
  • و Workload

نیز بررسی شوند.

ROP Count یک مشخصه معماری است،
نه یک امتیاز نهایی Performance.

Common Mistakes — اشتباهات رایج درباره ROP
  • ROP را با Pixel Shader یکی ندانید.
  • ROP را فقط واحد Blending تصور نکنید.
  • Pixel Fill Rate را با FPS یکی ندانید.
  • ROP بیشتر را همیشه معادل GPU سریع تر ندانید.
  • Overdraw را فقط مشکل Pixel Shader ندانید.
  • Depth Test را از Memory و Render Output جدا تصور نکنید.
  • Render Target را همیشه تصویر نهایی نمایش داده شده فرض نکنید.
  • تعداد ROPها را بدون بررسی Bandwidth و Workload مقایسه نکنید.

مدل ذهنی ساده ROP


Pixel Shader

     │
     ▼

Fragment Output

     │
     ▼

Depth / Stencil

     │
     ▼

Blend

     │
     ▼

Color Write

     │
     ▼

Render Target

     │
     ▼

Frame Buffer / Next Pass

سوالات متداول درباره ROP

ROP چیست؟

بخشی از Render Output Pipeline است
که عملیات مربوط به
Depth،
Stencil،
Blending
و نوشتن خروجی
را مدیریت می کند.

ROP و Pixel Shader چه تفاوتی دارند؟

Pixel Shader
رنگ یا داده Fragment را محاسبه می کند.

ROP
خروجی آن را
برای تست،
ترکیب
و نوشتن در Render Target
پردازش می کند.

Pixel Fill Rate چیست؟

معیاری نظری
برای توان پردازش خروجی Pixel
در واحد زمان است.

این عدد
Performance واقعی بازی
را به تنهایی مشخص نمی کند.

Overdraw چیست؟

زمانی رخ می دهد
که یک ناحیه از تصویر
چندین بار توسط Fragmentهای مختلف
پردازش یا بازنویسی شود.

Early Depth Test چیست؟

روشی است
که GPU تلاش می کند
Fragmentهایی را که قابل مشاهده نیستند
قبل از انجام کار پرهزینه تر
حذف کند.

آیا ROP بیشتر همیشه بهتر است؟

خیر.

Performance نهایی
به کل Graphics Pipeline،
Memory Bandwidth،
Shader Throughput
و Workload بستگی دارد.

خلاصه فصل

  • ROP در بخش انتهایی Graphics Pipeline قرار دارد.
  • Render Target محل نگهداری خروجی Rendering است.
  • Depth Test برای تعیین Visibility بر اساس عمق استفاده می شود.
  • Stencil برای Mask و کنترل Rendering استفاده می شود.
  • Blending رنگ جدید را با رنگ موجود ترکیب می کند.
  • Alpha Blending یکی از کاربردهای معروف Blending است.
  • GPU می تواند به چند Render Target هم زمان خروجی بدهد.
  • Pixel Fill Rate یک معیار نظری برای توان Render Output است.
  • Overdraw می تواند کار غیرضروری ایجاد کند.
  • Early Depth می تواند برخی Fragmentهای غیرضروری را زود حذف کند.
  • ROP Throughput و Memory Bandwidth به یکدیگر وابسته هستند.
  • ROP Count به تنهایی Performance GPU را تعیین نمی کند.

سطح: مقدماتی تا متوسط

پیش نیاز:
Graphics Pipeline،
Texture Units،
ROP،
Shader Units

موضوع:
GPU Graphics Pipeline

زمان مطالعه:
حدود 8 تا 10 دقیقه


GPU GRAPHICS PIPELINE

Fixed-Function Hardware در GPU چیست؟

همه کارهای GPU
توسط Shader Coreهای عمومی انجام نمی شوند.

بعضی عملیات
آن قدر پرتکرار،
قابل پیش بینی
و تخصصی هستند
که اجرای آنها روی سخت افزار اختصاصی
موثرتر است.

این بخش های تخصصی
Fixed-Function Hardware
نامیده می شوند.


پاسخ سریع

Fixed-Function Hardware
بخش هایی از GPU هستند
که برای انجام مجموعه مشخصی از عملیات
به صورت تخصصی طراحی شده اند.

برخلاف Shader Coreهای Programmable،
این واحدها برای اجرای کد عمومی ساخته نشده اند.

نمونه های رایج شامل
Rasterization،
Texture Sampling،
Depth / Stencil،
Blending
و برخی واحدهای Video Processing هستند.

در این فصل چه چیزهایی یاد می گیریم؟

  • Fixed-Function Hardware چیست.
  • تفاوت آن با Programmable Shader Unit چیست.
  • چرا GPU از سخت افزار تخصصی استفاده می کند.
  • Rasterizer چه نقشی دارد.
  • Texture Unit چرا Fixed-Function است.
  • ROP و Depth / Stencil چرا تخصصی هستند.
  • Video Encode / Decode چگونه در این دسته قرار می گیرند.
  • چرا همه چیز را به Shader Core نمی سپاریم.

Programmable و Fixed-Function چه تفاوتی دارند؟

نوع ویژگی
Programmable Hardware می تواند انواع مختلف Shader و محاسبات عمومی تر را اجرا کند.
Fixed-Function Hardware برای مجموعه مشخصی از عملیات تخصصی طراحی شده است.

چرا اصلا Fixed-Function Hardware لازم است؟

فرض کنید یک عملیات
در تقریبا هر Frame
میلیون ها بار تکرار شود.

اگر این عملیات
ساختار مشخص و قابل پیش بینی داشته باشد،
سخت افزار تخصصی
می تواند آن را
با Efficiency بالاتری انجام دهد.


General-Purpose Execution

Flexible
but
More General Hardware


Fixed-Function Execution

Less Flexible
but
Highly Specialized

این Trade-off
یکی از اصول مهم طراحی GPU است.

Rasterizer یک نمونه مهم Fixed-Function است

Rasterizer
Primitiveهای هندسی
را به Fragment Candidateها
روی Screen تبدیل می کند.


Triangle

     /
    /  
   /____

      │
      ▼

Rasterizer

      │
      ▼

Covered Screen Samples

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

Texture Unit

Texture Sampling
شامل عملیات پرتکراری مانند:

  • Address Calculation،
  • Texture Lookup،
  • Filtering،
  • Mip Selection،
  • و Format Handling

است.


Shader

  │
  ▼

Texture Request

  │
  ▼

Texture Unit

  │
  ▼

Filtered Sample

  │
  ▼

Shader

Texture Unit
یکی از شناخته شده ترین نمونه های
Fixed-Function Acceleration
در GPU است.

Depth و Stencil

Depth و Stencil Test
نیز عملیات ساختارمند
و بسیار پرتکراری هستند.


Fragment

   │
   ▼

Depth Test

   │
   ▼

Stencil Test

   │
   ▼

Pass / Reject

انجام این تست ها
با سخت افزار تخصصی
به GPU اجازه می دهد
Fragmentهای نامعتبر را
سریع تر مدیریت کند.

Blending

Blending
رنگ Fragment جدید
را با رنگ موجود در Render Target
ترکیب می کند.


Source Color

      +

Destination Color

      │
      ▼

Blend Hardware

      │
      ▼

Final Color

چون این عملیات
در Rendering بسیار پرتکرار است،
بخش زیادی از آن
با سخت افزار تخصصی انجام می شود.

چرا Shader Unit متفاوت است؟

Shader Core
برای انعطاف طراحی شده است.

برنامه نویس می تواند
منطق متفاوتی در آن اجرا کند.


Shader Core

Can Execute

Lighting
Math
AI-like Operations
Procedural Logic
Image Processing
Custom Algorithms
...

اما Fixed-Function Unit
برای کار مشخصی ساخته شده است.


Texture Unit

Texture Sampling


Rasterizer

Triangle Coverage


ROP

Output Operations

چرا همه چیز را Programmable نمی کنیم؟

Programmability
انعطاف زیادی ایجاد می کند،
اما هزینه دارد.

سخت افزار عمومی تر
معمولا باید:

  • Instructionهای بیشتری پشتیبانی کند،
  • منطق کنترل بیشتری داشته باشد،
  • Register و Scheduling بیشتری نیاز داشته باشد،
  • و برای کارهای ساده
    منابع عمومی مصرف کند.

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

پس چرا همه چیز Fixed-Function نیست؟

چون Graphics و Compute
به انعطاف زیادی نیاز دارند.

اگر تمام Pipeline
Fixed-Function بود،
برنامه نویس فقط
مجموعه محدودی از افکت ها
را می توانست اجرا کند.


Too Much Fixed Function

Fast
but
Rigid


Too Much General Purpose

Flexible
but
Potentially Less Efficient

GPU مدرن
بین این دو رویکرد
تعادل ایجاد می کند.

GPU مدرن ترکیبی از هر دو است


Modern GPU

├── Programmable Shader Units
│
├── Texture Units
│
├── Rasterization Hardware
│
├── Depth / Stencil
│
├── Render Output
│
├── Video Engines
│
└── Other Specialized Units

این ترکیب
به GPU اجازه می دهد
هم انعطاف داشته باشد
و هم عملیات پرتکرار
را با Efficiency بالا اجرا کند.

Video Encode و Decode

GPUهای مدرن
اغلب واحدهای تخصصی
برای Video Processing نیز دارند.

این واحدها می توانند
عملیات Decode یا Encode
برخی Codecهای ویدیویی
را بدون اجرای کامل آنها
روی Shader Coreها انجام دهند.


Compressed Video

      │
      ▼

Video Decode Engine

      │
      ▼

Decoded Frames

این طراحی
می تواند مصرف منابع Shader
و توان را کاهش دهد.

Fixed-Function و بهره وری انرژی

یکی از مزایای مهم
سخت افزار تخصصی
می تواند Efficiency انرژی باشد.

اگر یک کار مشخص
با مدار اختصاصی انجام شود،
ممکن است نسبت به اجرای همان کار
با دستورهای عمومی متعدد
انرژی کمتری مصرف شود.


Same Task

General Shader Path
      │
      ▼
More General Work


Specialized Hardware
      │
      ▼
Purpose-Built Path

البته نتیجه واقعی
به طراحی معماری بستگی دارد.

Fixed-Function Hardware رایگان نیست

هر واحد تخصصی
فضایی روی Silicon مصرف می کند.

بنابراین طراح GPU باید تصمیم بگیرد
چه مقدار Chip Area
به واحدهای تخصصی
و چه مقدار
به Compute Resources اختصاص داده شود.


Finite Chip Area

      │
      ├── Shader Units
      ├── Cache
      ├── Memory Logic
      ├── Texture Units
      ├── ROP
      └── Specialized Engines

این یکی از Trade-offهای اصلی
طراحی GPU است.

Under the Hood — Fixed-Function به معنی «بدون تنظیم» نیست

عبارت Fixed-Function
به این معنی نیست
که برنامه نویس هیچ کنترلی روی آن واحد ندارد.

برای مثال،
برنامه می تواند
حالت های مختلفی برای:

  • Texture Filtering،
  • Depth Comparison،
  • Stencil Operation،
  • Blending،
  • Cull Mode

تنظیم کند.

اما اجرای آن عملیات
بر اساس مجموعه قابلیت های
از پیش طراحی شده سخت افزار انجام می شود.

Performance Impact — Bottleneck می تواند داخل Fixed-Function Stage باشد

اگر یک Workload
تعداد بسیار زیادی عملیات
از یک نوع خاص ایجاد کند،
همان Fixed-Function Unit
می تواند Bottleneck شود.


Possible Pressure

Too Many Triangles
     │
     ▼
Rasterizer Pressure


Too Many Texture Samples
     │
     ▼
Texture Unit Pressure


Too Many Pixel Writes
     │
     ▼
ROP / Memory Pressure

بنابراین
Fixed-Function بودن
به معنی ظرفیت نامحدود نیست.

Engineering Insight — GPU یک ماشین Hybrid است

GPU را نباید
فقط یک پردازنده موازی عمومی
یا فقط یک Graphics Processor ثابت
در نظر گرفت.

GPU مدرن
ترکیبی است از:

  • Programmable Compute،
  • Fixed-Function Graphics،
  • Specialized Matrix Hardware،
  • Media Engines،
  • Memory Hierarchy،
  • و Scheduling Hardware.

قدرت GPU مدرن
از همکاری سخت افزار عمومی
و سخت افزار تخصصی می آید.

Common Mistakes — اشتباهات رایج درباره Fixed-Function Hardware
  • Fixed-Function را به معنی سخت افزار قدیمی ندانید.
  • تصور نکنید GPU مدرن فقط Shader Core است.
  • Fixed-Function را به معنی بدون قابلیت تنظیم ندانید.
  • Texture Unit را با Shader Unit یکی ندانید.
  • Rasterizer را نرم افزار Shader فرض نکنید.
  • ROP را فقط یک Pixel Writer ساده ندانید.
  • واحد تخصصی را دارای Throughput نامحدود فرض نکنید.
  • Fixed-Function Performance را جدا از Memory System تحلیل نکنید.

مدل ذهنی ساده


GPU Work

      │
      ├── Custom / Flexible?
      │        │
      │        ▼
      │   Shader Units
      │
      └── Repetitive / Specialized?
               │
               ▼
        Fixed-Function Units

در عمل
بسیاری از Workloadها
از هر دو مسیر
به صورت هم زمان استفاده می کنند.

سوالات متداول درباره Fixed-Function Hardware

Fixed-Function Hardware چیست؟

واحد سخت افزاری تخصصی است
که برای انجام مجموعه مشخصی از عملیات
طراحی شده
و مانند Shader Core
برای اجرای کد عمومی ساخته نشده است.

آیا Fixed-Function Hardware هنوز در GPUهای مدرن وجود دارد؟

بله.

Rasterization،
Texture Sampling،
Depth / Stencil،
Render Output
و بسیاری از Media Operations
هنوز از سخت افزار تخصصی استفاده می کنند.

چرا همه چیز روی Shader Core اجرا نمی شود؟

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

آیا Fixed-Function قابل تنظیم است؟

بله، در بسیاری از موارد
برنامه نویس می تواند
State و Modeهای مختلف را تنظیم کند،
اما منطق اصلی سخت افزار
از پیش طراحی شده است.

آیا Video Decoder بخشی از Shader Core است؟

معمولا GPUهای مدرن
برای برخی عملیات Video Encode / Decode
واحدهای تخصصی جداگانه دارند.

خلاصه فصل

  • Fixed-Function Hardware برای کارهای مشخص و پرتکرار طراحی می شود.
  • Shader Unit انعطاف بیشتر و Fixed-Function تخصص بیشتر دارد.
  • Rasterizer نمونه ای از سخت افزار تخصصی Graphics Pipeline است.
  • Texture Unit عملیات Sampling و Filtering را شتاب می دهد.
  • Depth، Stencil و Blending نیز از سخت افزار تخصصی استفاده می کنند.
  • GPUهای مدرن می توانند Video Encode / Decode Engineهای تخصصی داشته باشند.
  • Fixed-Function Hardware می تواند Performance و Efficiency انرژی را بهبود دهد.
  • واحدهای تخصصی Chip Area مصرف می کنند و بخشی از Trade-off معماری هستند.
  • Fixed-Function به معنی بدون قابلیت تنظیم نیست.
  • GPU مدرن ترکیبی از Programmable و Specialized Hardware است.

سطح: مقدماتی تا متوسط

پیش نیاز:
Graphics Pipeline،
Vertex Shader،
Pixel Shader،
Fixed-Function Hardware

موضوع:
GPU Graphics Pipeline

زمان مطالعه:
حدود 10 تا 12 دقیقه


GPU GRAPHICS PIPELINE

Shader Stageها در Graphics Pipeline چه هستند؟

Graphics Pipeline
فقط یک Shader ندارد.

در مراحل مختلف Rendering
ممکن است Shaderهای متفاوتی اجرا شوند
و هر کدام
روی نوع خاصی از داده
و در مرحله مشخصی از Pipeline
کار کنند.

Vertex Shader،
Pixel یا Fragment Shader،
و در برخی Pipelineها
Shader Stageهای دیگری
برای Geometry،
Tessellation،
Mesh Processing
یا Compute وجود دارند.


پاسخ سریع

Shader Stage
یک مرحله Programmable در GPU Pipeline است
که برنامه نویس می تواند
برای پردازش نوع مشخصی از داده
کد Shader بنویسد.

هر Stage
ورودی و خروجی خاص خود را دارد
و در نقطه مشخصی
از Graphics یا Compute Pipeline
اجرا می شود.

در این فصل چه چیزهایی یاد می گیریم؟

  • Shader Stage چیست.
  • Vertex Shader چه نقشی دارد.
  • Pixel / Fragment Shader چه کاری انجام می دهد.
  • Geometry Shader چیست.
  • Tessellation Shaderها چه کاربردی دارند.
  • Mesh Shader چیست.
  • Compute Shader چه تفاوتی با Graphics Shader دارد.
  • چرا همه Stageها در همه Workloadها استفاده نمی شوند.

Programmable Pipeline یعنی چه؟

در GPUهای قدیمی،
بخش بیشتری از Graphics Pipeline
رفتار ثابت داشت.

GPUهای مدرن
اجازه می دهند
بخش های مهمی از Pipeline
با Shaderهای قابل برنامه نویسی
کنترل شوند.


Graphics Pipeline

Fixed-Function Stages
        +
Programmable Shader Stages

این ترکیب
انعطاف بسیار زیادی
برای ساخت Material،
Lighting،
Animation،
Post Processing
و تکنیک های Rendering ایجاد می کند.

نقشه ساده Shader Stageها


Vertex Data

    │
    ▼

Vertex Shader

    │
    ▼

Optional Tessellation Stages

    │
    ▼

Optional Geometry Stage

    │
    ▼

Rasterization

    │
    ▼

Pixel / Fragment Shader

    │
    ▼

Render Output

در معماری های مدرن،
مسیرهای جدیدتری مانند Mesh Shader
نیز می توانند
بخشی از این زنجیره کلاسیک را تغییر دهند.

Vertex Shader

Vertex Shader
روی Vertexهای ورودی
اجرا می شود.

کارهای رایج آن:

  • تبدیل Position،
  • Skinning،
  • تغییر Attributeها،
  • آماده کردن داده برای Rasterization،
  • و ارسال داده به مراحل بعدی

است.


Input Vertex

Position
Normal
UV

    │
    ▼

Vertex Shader

    │
    ▼

Transformed Vertex

Pixel Shader / Fragment Shader

Pixel Shader
روی Fragmentهای تولید شده
پس از Rasterization اجرا می شود.

این Stage معمولا
ظاهر نهایی Surface را محاسبه می کند.


Interpolated Data

Normal
UV
Color
Position

    │
    ▼

Pixel Shader

    │
    ├── Texture Sampling
    ├── Lighting
    ├── Material
    └── Effects

    │
    ▼

Output Color / Data

Geometry Shader چیست؟

Geometry Shader
روی Primitiveها
مانند Point،
Line
یا Triangle
کار می کند.

این Shader
می تواند Primitive را:

  • تغییر دهد،
  • حذف کند،
  • یا Primitiveهای جدید تولید کند.


Input Triangle

     /
    /  
   /____

      │
      ▼

Geometry Shader

      │
      ▼

Modified / Additional Geometry

در بسیاری از Rendering Pipelineهای مدرن،
Geometry Shader
الزاما Stage اصلی یا پرتکرار نیست.

Tessellation چیست؟

Tessellation
برای افزایش جزئیات Geometry
با تقسیم Primitiveهای بزرگ
به Primitiveهای کوچک تر استفاده می شود.


Before Tessellation

     /
    /  
   /____


After Tessellation

     /
    /__
   /  /
  /__/__

این روش
می تواند Geometry را
بر اساس فاصله،
سطح جزئیات
یا نیاز Rendering
افزایش دهد.

Tessellation Stageها

نام دقیق Stageها
میان APIها متفاوت است،
اما مفهوم کلی شامل:


Input Patch

    │
    ▼

Tessellation Control
 / Hull Shader

    │
    ▼

Tessellator
Fixed Function

    │
    ▼

Tessellation Evaluation
 / Domain Shader

    │
    ▼

Detailed Geometry

است.

در این مسیر،
بخشی Programmable
و بخشی Fixed-Function است.

Mesh Shader چیست؟

Mesh Shader
رویکرد جدیدتری
برای پردازش Geometry است.

هدف کلی آن
دادن کنترل بیشتر به GPU
روی تولید و مدیریت Geometry
در گروه های کاری
است.


Traditional Geometry Path

Vertex Processing
      │
      ▼
Primitive Assembly
      │
      ▼
Geometry Processing


Mesh Shader Path

Workgroup
      │
      ▼
Mesh Processing
      │
      ▼
Vertices + Primitives

Mesh Shader
می تواند در Pipelineهای مدرن
بخشی از مسیر کلاسیک Geometry
را جایگزین کند.

Compute Shader چیست؟

Compute Shader
برای محاسبات عمومی تر
روی GPU استفاده می شود
و به Rasterization
وابسته نیست.


Compute Dispatch

      │
      ▼

Thread Groups

      │
      ▼

Compute Shader

      │
      ▼

Buffers / Images / Results

Compute Shader
در کاربردهایی مانند:

  • Image Processing،
  • Simulation،
  • Particle Systems،
  • Post Processing،
  • Data Processing،
  • و برخی تکنیک های Rendering

استفاده می شود.

Graphics Shader و Compute Shader چه تفاوتی دارند؟

نوع جایگاه کاربرد کلی
Graphics Shader داخل Graphics Pipeline پردازش Geometry و Pixel
Compute Shader Compute Pipeline محاسبات عمومی تر روی داده

آیا هر Shader Stage سخت افزار جداگانه دارد؟

در GPUهای مدرن،
بسیاری از Shader Stageها
روی همان مجموعه کلی
Programmable Execution Units
اجرا می شوند.


Vertex Shader
      │
      ├─────┐
Pixel Shader
      │     │
Compute Shader
      │     ▼

Programmable Shader Hardware

یعنی الزاما
یک «Vertex Core»
و یک «Pixel Core»
کاملا جدا
برای هر Stage وجود ندارد.

جزئیات دقیق
به معماری GPU بستگی دارد.

Unified Shader Architecture

در معماری های مدرن،
واحدهای Shader
معمولا می توانند
انواع مختلف Workloadهای Programmable
را اجرا کنند.


Programmable Shader Pool

     │
     ├── Vertex Work
     ├── Pixel Work
     ├── Compute Work
     └── Other Shader Work

این رویکرد
به GPU اجازه می دهد
منابع Programmable خود را
انعطاف پذیرتر استفاده کند.

چرا بعضی Shader Stageها اختیاری هستند؟

همه Workloadها
به تمام Stageها نیاز ندارند.

یک Pipeline ساده
ممکن است فقط از:


Vertex Shader

      │
      ▼

Rasterizer

      │
      ▼

Pixel Shader

استفاده کند.

Pipeline دیگری
ممکن است Tessellation،
Geometry
یا Mesh Processing
نیز داشته باشد.

استفاده از Stage بیشتر
به خودی خود
به معنی کیفیت یا Performance بیشتر نیست.

داده چگونه میان Shader Stageها منتقل می شود؟

هر Shader Stage
ورودی دریافت می کند
و خروجی تولید می کند.


Vertex Attributes

      │
      ▼

Vertex Shader

      │
      ▼

Shader Outputs

      │
      ▼

Interpolation / Pipeline

      │
      ▼

Pixel Shader Inputs

این داده ها
می توانند شامل:

  • Position،
  • UV،
  • Normal،
  • Color،
  • Material Data،
  • و مقادیر سفارشی دیگر

باشند.

Under the Hood — نام Shader Stage و سخت افزار واقعی را یکی ندانید

Shader Stage
یک مفهوم Pipeline و Programming Model است.

اما سخت افزار واقعی
ممکن است همان Workloadها را
روی مجموعه مشترکی از Execution Unitها اجرا کند.


Programming View

Vertex Shader
Pixel Shader
Compute Shader


Hardware View

Shared Programmable
Execution Resources

به همین دلیل
نباید نام Stageهای نرم افزاری
را مستقیما
به واحدهای فیزیکی جداگانه
تبدیل کرد.

Performance Impact — Bottleneck می تواند در Shader Stageهای مختلف باشد

Workloadهای مختلف
می توانند به Stageهای متفاوتی
فشار وارد کنند.


Heavy Vertex Processing

      │
      ▼

Vertex Workload Pressure


Heavy Pixel Shader

      │
      ▼

Fragment / Pixel Pressure


Heavy Compute

      │
      ▼

Compute Resource Pressure

Performance
به مقدار کار،
نوع Instruction،
Memory Access
و تعداد Threadهای هر Stage بستگی دارد.

Engineering Insight — Shader Stage بیشتر لزوما بهتر نیست

هر Stage اضافی
کار بیشتری ایجاد می کند.

اگر Stage خاصی
برای تکنیک Rendering لازم نباشد،
اضافه کردن آن
فقط Pipeline را پیچیده تر می کند.

از هر Stage زمانی استفاده کنید
که واقعا مسئله ای را حل می کند.

Common Mistakes — اشتباهات رایج درباره Shader Stageها
  • Vertex Shader و Pixel Shader را سخت افزارهای کاملا جدا فرض نکنید.
  • همه Pipelineها را دارای Geometry Shader ندانید.
  • Tessellation را برای همه Sceneها ضروری ندانید.
  • Compute Shader را بخشی اجباری از Graphics Pipeline فرض نکنید.
  • Mesh Shader را صرفا نسخه سریع تر Vertex Shader ندانید.
  • Shader Stage بیشتر را معادل کیفیت بهتر ندانید.
  • نام Stage نرم افزاری را مستقیما معادل یک Core فیزیکی ندانید.
  • Shader Performance را بدون توجه به Memory و Scheduling تحلیل نکنید.

مدل ذهنی ساده Shader Stageها


Graphics Work

      │
      ▼

Geometry Processing

Vertex
Tessellation
Geometry / Mesh

      │
      ▼

Rasterization

      │
      ▼

Pixel Processing

Pixel / Fragment Shader

      │
      ▼

Render Output


Separate Path

Compute Dispatch
      │
      ▼
Compute Shader

سوالات متداول درباره Shader Stageها

Shader Stage چیست؟

مرحله ای Programmable
در Pipeline است
که برای پردازش نوع مشخصی از داده
Shader اجرا می کند.

مهم ترین Shader Stageهای Graphics Pipeline کدام هستند؟

Vertex Shader
و Pixel / Fragment Shader
دو Stage بسیار مهم و رایج هستند.

Pipelineهای دیگر
می توانند Stageهای بیشتری نیز داشته باشند.

Geometry Shader چه کاری انجام می دهد؟

روی Primitiveها کار می کند
و می تواند Geometry را
تغییر دهد،
حذف کند
یا Primitive جدید تولید کند.

Compute Shader چیست؟

Shaderی برای محاسبات عمومی تر روی GPU است
که به Rasterization
یا مسیر کلاسیک Graphics Pipeline وابسته نیست.

آیا هر Shader Stage Core جدا دارد؟

معمولا در GPUهای مدرن
بسیاری از Stageهای Programmable
روی مجموعه مشترکی از Shader Execution Unitها اجرا می شوند.

Mesh Shader چیست؟

مدل جدیدتری برای پردازش Geometry است
که کنترل بیشتری
روی تولید Vertex و Primitive
در اختیار Workgroupهای GPU قرار می دهد.

خلاصه فصل

  • Shader Stage یک مرحله Programmable در GPU Pipeline است.
  • Vertex Shader روی Vertexها کار می کند.
  • Pixel / Fragment Shader ظاهر Fragmentها را محاسبه می کند.
  • Geometry Shader روی Primitiveها کار می کند.
  • Tessellation Geometry را به بخش های کوچک تر تقسیم می کند.
  • Mesh Shader رویکرد جدیدتری برای Geometry Processing است.
  • Compute Shader برای محاسبات عمومی تر GPU استفاده می شود.
  • همه Shader Stageها در همه Pipelineها استفاده نمی شوند.
  • GPUهای مدرن معمولا از Unified Programmable Shader Resources استفاده می کنند.
  • نام Shader Stage الزاما معادل سخت افزار فیزیکی جداگانه نیست.
  • Performance هر Stage به Workload، Memory و Execution Architecture وابسته است.

سطح: جمع بندی

پیش نیاز:
تمام بخش های Graphics Pipeline

موضوع:
GPU Graphics Pipeline

زمان مطالعه:
حدود 8 تا 10 دقیقه


GPU GRAPHICS PIPELINE

جمع بندی نهایی Graphics Pipeline

Graphics Pipeline
سیستمی است که داده های هندسی،
Textureها،
Shaderها
و مراحل Fixed-Function
را کنار یکدیگر قرار می دهد
تا در نهایت
یک تصویر قابل نمایش تولید شود.

از Vertexهای یک مدل سه بعدی
تا Pixelهای نهایی Frame،
GPU مجموعه بزرگی از عملیات
Programmable و Specialized
را به صورت موازی انجام می دهد.


پاسخ سریع

Graphics Pipeline
زنجیره ای از مراحل
برای تبدیل Geometry
به تصویر نهایی است.

در یک مدل ساده:

Vertexها پردازش می شوند،
Primitiveها شکل می گیرند،
Rasterizer مشخص می کند
کدام قسمت های Screen پوشش داده شده اند،
Pixel Shader ظاهر آنها را محاسبه می کند
و در نهایت
Depth،
Stencil،
Blending
و Render Output
تصویر نهایی را تشکیل می دهند.

تصویر کلی Graphics Pipeline


3D Scene Data

      │
      ▼

Vertex Processing

      │
      ▼

Primitive Assembly

      │
      ▼

Geometry Processing

      │
      ▼

Clipping / Viewport

      │
      ▼

Rasterization

      │
      ▼

Fragments

      │
      ▼

Pixel / Fragment Shader

      │
      ▼

Depth / Stencil

      │
      ▼

Blending

      │
      ▼

Render Target

      │
      ▼

Frame

داده ورودی Graphics Pipeline

Rendering معمولا
با مجموعه ای از داده های Geometry
شروع می شود.

Vertex Position

موقعیت نقاط مدل.

Normal

اطلاعات جهت Surface.

Texture Coordinate

ارتباط Surface با Texture.

Index Data

مشخص می کند Vertexها چگونه Primitive می سازند.

Vertex و Vertex Shader

Vertex
فقط یک مختصات سه بعدی نیست.

هر Vertex
می تواند مجموعه ای از Attributeها
مانند Position،
Normal،
Color
و UV داشته باشد.

Vertex Shader
این اطلاعات را پردازش می کند
و Position مناسب
برای ادامه Graphics Pipeline
را تولید می کند.


Vertex Data

     │
     ▼

Vertex Shader

     │
     ▼

Transformed Vertex

Primitiveها

Vertexها
برای تشکیل Primitiveها
با یکدیگر ترکیب می شوند.

یکی از مهم ترین Primitiveها
Triangle است.


V0
     /
    /  
   /    
  /______
V1      V2

Triangle

یک Mesh پیچیده
می تواند از تعداد زیادی Triangle
تشکیل شود.

Geometry Processing

Graphics Pipeline
می تواند مراحل مختلفی
برای پردازش Geometry داشته باشد.

بسته به Pipeline
ممکن است از:

  • Vertex Shader،
  • Tessellation،
  • Geometry Shader،
  • Mesh Shader،
  • یا ترکیبی از آنها

استفاده شود.

همه این Stageها
در همه Rendering Pipelineها
اجباری نیستند.

Rasterization

Rasterizer
Geometry را
به نواحی قابل پردازش
روی Screen تبدیل می کند.


Triangle

     /
    /  
   /____

      │
      ▼

Rasterizer

      │
      ▼

Fragments / Covered Samples

Rasterization
یک مرحله مهم Fixed-Function
در Graphics Pipeline است.

Interpolation

Attributeهای Vertexها
مانند UV،
Color
و Normal
می توانند در سطح Primitive
Interpolation شوند.


Vertex A
Value = 0

Vertex B
Value = 1

        │
        ▼

Interpolation

        │
        ▼

Intermediate Values
Across Primitive

این مقادیر
به Pixel یا Fragment Shader
ارسال می شوند.

Pixel / Fragment Shader

Pixel Shader
ظاهر Fragmentها
را محاسبه می کند.

این Stage
می تواند از:

  • Texture،
  • Lighting،
  • Material،
  • Normal،
  • Shadow Data،
  • و سایر داده ها

استفاده کند.


Fragment Inputs

      │
      ▼

Pixel Shader

      │
      ▼

Color / Render Data

Texture Units

Texture Unit
یک واحد تخصصی
برای Texture Sampling است.

این واحد
عملیاتی مانند:

  • Texture Addressing،
  • Mip Selection،
  • Filtering،
  • و خواندن Sample

را انجام می دهد.


Shader

   │
   ▼

Texture Request

   │
   ▼

Texture Unit

   │
   ▼

Filtered Sample

   │
   ▼

Shader

Texel و Pixel

مفهوم معنا
Texel عنصر Texture
Pixel عنصر تصویر یا Render Target

یک Pixel
الزاما متناظر با یک Texel واحد نیست.

Texture Filtering

GPU می تواند
از روش های مختلف Sampling
استفاده کند.

روش کاربرد کلی
Nearest انتخاب نزدیک ترین Texel
Bilinear ترکیب Texelهای نزدیک
Trilinear ترکیب Sample میان دو Mip Level
Anisotropic Sampling بهتر روی Surfaceهای زاویه دار

Mipmaps

Mipmaps
نسخه های کوچک تر
از Texture اصلی هستند.


Large Texture

████████████████

      │
      ▼

████████

      │
      ▼

████

      │
      ▼

██

      │
      ▼

█

آنها به GPU کمک می کنند
برای Objectهای دورتر
از Texture Resolution مناسب تری استفاده کند.

Depth Test

Depth Test
مشخص می کند
کدام Fragment
در مقابل Camera
قابل مشاهده تر است.


Near Fragment

     │

Far Fragment

     │
     ▼

Depth Test

     │
     ▼

Visible Fragment

Depth Buffer
مقادیر عمق
را برای بخش های تصویر نگهداری می کند.

Stencil

Stencil
برای ایجاد Mask
و کنترل Rendering
در بخش های خاص تصویر استفاده می شود.


Stencil Mask

0 0 0 0
0 1 1 0
0 1 1 0
0 0 0 0

      │
      ▼

Controlled Rendering

Blending

Blending
رنگ Fragment جدید
را با رنگ موجود
در Render Target ترکیب می کند.


New Color

    +

Existing Color

    │
    ▼

Blend

    │
    ▼

Final Color

Transparency
یکی از کاربردهای رایج این مرحله است.

ROP / Render Output

مرحله Render Output
بخش نهایی
Graphics Pipeline را مدیریت می کند.

این بخش
با عملیاتی مانند:

  • Depth،
  • Stencil،
  • Blending،
  • و Render Target Write

مرتبط است.


Pixel Shader Output

       │
       ▼

Render Output

       │
       ▼

Render Target

Overdraw

Overdraw زمانی رخ می دهد
که یک ناحیه Screen
چندین بار توسط Fragmentهای مختلف
پردازش شود.


Pixel Position

Object A
   │
   ▼

Object B
   │
   ▼

Object C
   │
   ▼

Final Visible Result

Early Depth Testing
می تواند در برخی شرایط
بخشی از این کار اضافی
را کاهش دهد.

Fixed-Function Hardware

GPU مدرن
فقط از Shader Core تشکیل نشده است.


GPU

├── Programmable Shader Hardware
│
├── Rasterizer
│
├── Texture Units
│
├── Depth / Stencil
│
├── Render Output
│
└── Other Specialized Units

Fixed-Function Hardware
برای عملیات مشخص و پرتکرار
با Efficiency بالا طراحی می شود.

Programmable و Fixed-Function مکمل یکدیگر هستند

نوع مزیت اصلی
Programmable انعطاف و اجرای منطق سفارشی
Fixed-Function Efficiency بالا برای عملیات مشخص

GPU مدرن
از ترکیب این دو رویکرد استفاده می کند.

Unified Shader Architecture

در GPUهای مدرن،
بسیاری از Shader Stageها
روی مجموعه مشترکی
از Programmable Execution Unitها
اجرا می شوند.


Vertex Shader
Pixel Shader
Compute Shader

       │
       ▼

Unified Programmable
Execution Hardware

بنابراین
نام Stageهای Shader
الزاما به معنی وجود
Coreهای فیزیکی جداگانه نیست.

Compute Shader در کنار Graphics Pipeline

Compute Shader
مسیر مستقلی برای اجرای محاسبات عمومی تر
روی GPU فراهم می کند.


Graphics Pipeline

Geometry
   │
Rasterization
   │
Pixel Processing


Compute Pipeline

Dispatch
   │
Compute Shader
   │
Buffers / Images

بسیاری از موتورهای مدرن
از Graphics و Compute
در کنار یکدیگر استفاده می کنند.

Graphics Pipeline به Memory System وابسته است

تقریبا تمام مراحل Graphics Pipeline
به نوعی
با حافظه ارتباط دارند.


Vertex Buffers

Texture Data

Depth Buffer

Render Targets

Shader Data

       │
       ▼

Memory System

       │
       ▼

Graphics Pipeline

به همین دلیل
Memory Bandwidth،
Cache
و VRAM
می توانند Performance Rendering
را تحت تاثیر قرار دهند.

Graphics Pipeline به Execution Architecture نیز وابسته است

Shader Stageها
در نهایت
به Threadها،
Warpها یا Waveها
و Execution Unitهای GPU
تبدیل می شوند.


Shader Work

    │
    ▼

Threads

    │
    ▼

Warps / Waves

    │
    ▼

Scheduler

    │
    ▼

Execution Units

بنابراین سه بخش بزرگی که تاکنون دیدیم:


Graphics Architecture

        +

Execution Architecture

        +

Memory Architecture

        │
        ▼

Real GPU Performance

همگی به یکدیگر متصل هستند.

Under the Hood — یک Frame حاصل همکاری کل GPU است

تصویر نهایی
فقط نتیجه Pixel Shader نیست.

یک Frame
می تواند حاصل همکاری:

  • Command Processing،
  • Geometry Processing،
  • Shader Execution،
  • Rasterization،
  • Texture Sampling،
  • Cache،
  • VRAM،
  • Depth / Stencil،
  • Blending،
  • و Render Output

باشد.

Rendering یک کار گروهی در سطح معماری GPU است.

مدل ساده Bottleneck در Graphics Pipeline


Frame Performance

      │
      ├── Geometry Load
      ├── Vertex Shader Cost
      ├── Rasterization Load
      ├── Pixel Shader Cost
      ├── Texture Sampling
      ├── Overdraw
      ├── Render Output
      ├── Memory Bandwidth
      └── Synchronization

بسته به Scene
فقط یکی یا چند مورد
می توانند Bottleneck اصلی باشند.

Performance Impact — Resolution همه چیز را یکسان افزایش نمی دهد

با افزایش Resolution
تعداد Pixelها افزایش پیدا می کند.

به همین دلیل
بخش هایی مانند:

  • Pixel Shading،
  • Texture Sampling،
  • Depth،
  • Blending،
  • Render Target Traffic

می توانند فشار بیشتری تجربه کنند.

اما تعداد Vertexهای Scene
صرفا با افزایش Resolution
الزاما تغییر نمی کند.

این تفاوت
برای تشخیص Bottleneckهای Rendering
بسیار مهم است.

Engineering Insight — عدد واحدی برای «قدرت Graphics Pipeline» وجود ندارد

مشخصاتی مانند:

  • Shader Count،
  • Texture Unit Count،
  • ROP Count،
  • Clock،
  • Memory Bandwidth

هر کدام
فقط بخشی از GPU
را توصیف می کنند.

قدرت واقعی GPU
حاصل تعادل کل Pipeline است،
نه بیشینه بودن یک عدد خاص.

بعد از این بخش باید بتوانید…

  • Graphics Pipeline را از Geometry تا Frame دنبال کنید.
  • Vertex و Primitive را از یکدیگر جدا کنید.
  • نقش Vertex Shader را توضیح دهید.
  • Rasterization را تعریف کنید.
  • Fragment و Pixel را از نظر مفهومی تفکیک کنید.
  • Pixel Shader را توضیح دهید.
  • Texel و Pixel را از یکدیگر تشخیص دهید.
  • Texture Filtering و Mipmapping را توضیح دهید.
  • Depth و Stencil را از هم جدا کنید.
  • Blending را توضیح دهید.
  • Render Target و Frame Buffer را تعریف کنید.
  • ROP را از Pixel Shader تفکیک کنید.
  • Fixed-Function و Programmable Hardware را مقایسه کنید.
  • Shader Stage و Shader Core را یکی ندانید.
  • ارتباط Graphics، Memory و Execution Architecture را توضیح دهید.

سوالات متداول Graphics Pipeline

Graphics Pipeline چیست؟

مجموعه مراحلی است
که داده هندسی
را پردازش کرده
و در نهایت
تصویر قابل نمایش تولید می کند.

Rasterizer چه کاری انجام می دهد؟

Primitiveهای هندسی
را به Fragmentها
یا Sampleهای پوشش داده شده
روی Screen تبدیل می کند.

Pixel Shader چه کاری انجام می دهد؟

ظاهر Fragmentها
را با استفاده از Material،
Texture،
Lighting
و سایر داده ها محاسبه می کند.

Texture Unit چیست؟

سخت افزار تخصصی
برای Texture Sampling،
Filtering
و عملیات مربوط به Texture است.

ROP چیست؟

بخشی از Render Output Pipeline است
که با عملیات Depth،
Stencil،
Blending
و نوشتن خروجی
مرتبط است.

آیا Graphics Pipeline فقط از Shaderها تشکیل شده است؟

خیر.

GPU از ترکیب
Programmable Shader Stages
و Fixed-Function Hardware
استفاده می کند.

آیا همه Shader Stageها در هر Frame استفاده می شوند؟

خیر.

Pipeline می تواند
بر اساس تکنیک Rendering
فقط Stageهای مورد نیاز
را استفاده کند.

مهم ترین عامل Performance Graphics Pipeline چیست؟

یک عامل واحد وجود ندارد.

Geometry،
Shader Cost،
Texture Sampling،
Overdraw،
Memory،
Resolution
و Render Output
همگی می توانند Bottleneck ایجاد کنند.

خلاصه نهایی Graphics Pipeline

  • Graphics Pipeline داده سه بعدی را به تصویر نهایی تبدیل می کند.
  • Vertexها Attributeهای هندسی را حمل می کنند.
  • Primitiveها از Vertexها ساخته می شوند.
  • Vertex Shader Geometry را پردازش می کند.
  • Rasterizer Primitiveها را به Fragment تبدیل می کند.
  • Pixel Shader ظاهر Fragmentها را محاسبه می کند.
  • Texture Unit وظیفه Sampling تخصصی Texture را بر عهده دارد.
  • Mipmaps و Filtering کیفیت و Efficiency Sampling را بهبود می دهند.
  • Depth و Stencil Visibility و Masking را مدیریت می کنند.
  • Blending رنگ جدید و موجود را ترکیب می کند.
  • ROP بخش مهم Render Output است.
  • Fixed-Function Hardware عملیات پرتکرار و تخصصی را شتاب می دهد.
  • Shader Stageها روی منابع Programmable GPU اجرا می شوند.
  • Compute Shader مسیر مستقلی برای محاسبات عمومی تر فراهم می کند.
  • Graphics Pipeline با Execution Architecture و Memory Architecture یک سیستم واحد می سازد.

سطح: مقدماتی تا متوسط

پیش نیاز:
Graphics Pipeline،
Shader Stages،
GPU Execution Architecture،
VRAM

موضوع:
GPU Ray Tracing Architecture

زمان مطالعه:
حدود 10 تا 12 دقیقه


GPU RAY TRACING ARCHITECTURE

Ray Tracing در GPU چگونه کار می کند؟

Rasterization
سال ها روش اصلی تولید Graphics Real-Time بوده است،
اما برای شبیه سازی بهتر رفتار نور،
GPUهای مدرن
از تکنیک هایی مانند
Ray Tracing
نیز استفاده می کنند.

در Ray Tracing،
به جای اینکه فقط بررسی کنیم
کدام Triangle روی Screen قرار می گیرد،
Rayهایی در Scene دنبال می شوند
تا برخورد آنها با Geometry
و رفتار نور
محاسبه شود.


پاسخ سریع

Ray Tracing
روشی برای شبیه سازی مسیر نور
با دنبال کردن Rayها در یک Scene سه بعدی است.

GPU باید برای هر Ray
بررسی کند
آیا با Geometry برخورد می کند،
نزدیک ترین برخورد کجاست
و بعد از برخورد
چه اتفاقی برای نور می افتد.

برای سریع تر شدن این کار
از ساختارهای داده ای مانند
Acceleration Structure
و در برخی GPUها
از سخت افزار تخصصی Ray Tracing
استفاده می شود.

در این فصل چه چیزهایی یاد می گیریم؟

  • Ray Tracing چیست.
  • Ray چیست.
  • Intersection چیست.
  • چرا بررسی مستقیم همه Triangleها بسیار پرهزینه است.
  • Acceleration Structure چیست.
  • BVH چیست.
  • Ray Generation چه کاری انجام می دهد.
  • Closest Hit و Miss چه مفهومی دارند.
  • Shadow Ray چیست.
  • چرا Ray Tracing معمولا با Rasterization ترکیب می شود.

Rasterization و Ray Tracing چه تفاوتی دارند؟

روش ایده اصلی
Rasterization Geometry را به نواحی Screen تبدیل می کند.
Ray Tracing Rayها را در Scene دنبال می کند
و برخورد آنها با Geometry را بررسی می کند.


Rasterization

Triangles
    │
    ▼
Screen Coverage
    │
    ▼
Pixels


Ray Tracing

Camera
    │
    ▼
Rays
    │
    ▼
Scene Geometry
    │
    ▼
Intersections

Ray چیست؟

Ray را می توان
یک خط جهت دار در فضای سه بعدی
در نظر گرفت.

هر Ray
معمولا شامل:

  • Origin،
  • Direction،
  • و محدوده ای برای جستجوی برخورد

است.


Origin
  ●
   
    
     
      ──────────────► Direction

Primary Ray چیست؟

در یک مدل ساده،
می توان از Camera
به سمت Scene
Ray ارسال کرد.


Camera

   ●
   │
   │ 
   │  
   │   
   ▼    ▼

Scene Geometry

این Rayها
می توانند مشخص کنند
در هر بخش تصویر
چه Surfaceای دیده می شود.

Ray Intersection چیست؟


Intersection

نقطه ای است
که Ray
با یک Primitive یا Surface
برخورد می کند.


Ray

──────────────►

             /
            /  
           / ●  
          /______

             ▲
             │
         Intersection

GPU باید مشخص کند:

  • آیا برخوردی وجود دارد،
  • کدام Primitive برخورد کرده،
  • فاصله برخورد چقدر است،
  • و نزدیک ترین برخورد کدام است.

چرا Ray Tracing می تواند بسیار سنگین باشد؟

فرض کنید Scene
میلیون ها Triangle داشته باشد.

اگر برای هر Ray
بخواهیم تک تک Triangleها
را بررسی کنیم:


Ray 0

Check Triangle 0
Check Triangle 1
Check Triangle 2
...
Check Triangle 1,000,000


Ray 1

Check Triangle 0
Check Triangle 1
...

هزینه محاسباتی
بسیار سریع افزایش پیدا می کند.

برای حل این مشکل
از
Acceleration Structures
استفاده می شود.

Acceleration Structure چیست؟

Acceleration Structure
ساختار داده ای است
که کمک می کند
GPU بدون بررسی تمام Geometry
ناحیه های نامرتبط را
سریع حذف کند.


Scene

├── Region A
│   ├── Objects
│   └── Triangles
│
├── Region B
│   ├── Objects
│   └── Triangles
│
└── Region C
    ├── Objects
    └── Triangles

اگر Ray
اصلا وارد Region B نشود،
نیازی نیست
Triangleهای آن ناحیه
بررسی شوند.

BVH چیست؟


Bounding Volume Hierarchy — BVH

یک ساختار سلسله مراتبی است
که Geometryهای Scene
را داخل Bounding Volumeهای بزرگ تر
گروه بندی می کند.


Scene

        Root Box

       /        

   Box A        Box B

   /           /   

Obj  Obj      Obj   Obj

Ray ابتدا
با Boxهای بزرگ تر بررسی می شود.

فقط اگر برخورد ممکن باشد،
GPU به سطوح پایین تر
و Geometry دقیق تر می رود.

BVH Traversal چگونه کار می کند؟


Ray

 │
 ▼

Root Node

 │
 ├── Miss
 │     └── Stop Branch
 │
 └── Hit
       │
       ▼

   Child Nodes

       │
       ▼

More Detailed Tests

       │
       ▼

Triangle Intersection

این روش
می تواند حجم بسیار بزرگی
از Geometry نامرتبط را
از جستجو حذف کند.

چرا GPUهای مدرن سخت افزار تخصصی Ray Tracing دارند؟

دو بخش از Ray Tracing
بسیار پرتکرار هستند:

  • Traversal در Acceleration Structure،
  • و Intersection Test.

به همین دلیل
برخی GPUهای مدرن
واحدهای سخت افزاری تخصصی
برای شتاب دادن این عملیات دارند.


Shader

   │
   ▼

Trace Ray Request

   │
   ▼

Ray Tracing Hardware

   │
   ├── BVH Traversal
   └── Intersection Assistance

   │
   ▼

Hit / Miss Information

   │
   ▼

Shader Continues

اگر Ray به Object برخورد کند چه؟

پس از پیدا شدن برخورد،
GPU می تواند
اطلاعات Surface را بررسی کند.

برای مثال:

  • Material،
  • Normal،
  • Texture،
  • Position،
  • و Lighting Data.


Ray

 │
 ▼

Hit Surface

 │
 ▼

Material / Normal / Texture

 │
 ▼

Shading

اگر Ray به هیچ چیز برخورد نکند چه؟

اگر Ray
هیچ Geometryای را قطع نکند،
یک Miss رخ می دهد.


Ray

──────────────►

No Geometry Hit

      │
      ▼

Miss

      │
      ▼

Sky / Environment / Default Result

در این حالت
می توان مثلا
رنگ آسمان
یا Environment Map
را استفاده کرد.

Closest Hit چیست؟

ممکن است یک Ray
در مسیر خود
چند Surface را قطع کند.


Ray

────────► Obj A ───► Obj B ───► Obj C

          ▲
          │
      Closest Hit

برای بسیاری از کاربردها
نزدیک ترین برخورد
اهمیت اصلی دارد.

Closest Hit Stage
می تواند Shading مربوط
به همین برخورد را انجام دهد.

Shadow Ray چیست؟

برای بررسی اینکه
یک نقطه توسط Light دیده می شود یا نه،
می توان Ray دیگری
از Surface به سمت Light فرستاد.


Light
  ●
   
    
     
      ● Surface Point

اگر Object دیگری
مسیر Ray را مسدود کند:


Light
  ●
   
       Obstacle
        ███
        ███
        ███
        ● Surface

Ray Blocked

Surface
می تواند در Shadow قرار بگیرد.

Reflection Ray

بعد از برخورد Ray
با Surface بازتابنده،
می توان Ray جدیدی
در جهت Reflection ایجاد کرد.


Incoming Ray

       
        
         ● Surface
        /
       /
      ▼

Reflected Ray

Ray جدید
Scene را دوباره بررسی می کند
تا مشخص شود
چه چیزی در Reflection دیده می شود.

Refraction Ray

در Materialهای شفاف
مانند Glass،
Ray می تواند
بعد از ورود به Surface
مسیر متفاوتی پیدا کند.


Incoming Ray

       
        
─────────●──────── Surface
          
           
            ▼

Refracted Ray

این رفتار
برای شبیه سازی شکست نور
استفاده می شود.

Ray Bounce چیست؟

یک Ray
ممکن است پس از برخورد
Rayهای جدیدی تولید کند.


Primary Ray

     │
     ▼

Hit

     │
     ├── Reflection Ray
     ├── Shadow Ray
     └── Refraction Ray

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

چرا تعداد Bounce محدود می شود؟

اگر Rayها
بدون محدودیت
Rayهای جدید تولید کنند،
هزینه Rendering
می تواند بسیار بالا شود.


Ray

 ├── Ray
 │   ├── Ray
 │   └── Ray
 │
 └── Ray
     ├── Ray
     └── Ray

به همین دلیل
در Real-Time Rendering
معمولا تعداد Bounceها
محدود می شود
یا فقط Effectهای خاصی
با Ray Tracing محاسبه می شوند.

Hybrid Rendering چیست؟

در بسیاری از موتورهای Real-Time،
Rasterization و Ray Tracing
در کنار یکدیگر استفاده می شوند.


Rasterization

Primary Scene Rendering

        +

Ray Tracing

Reflections
Shadows
Global Illumination
Other Effects

        │
        ▼

Hybrid Frame

این روش
کمک می کند
مزایای Ray Tracing
بدون هزینه اجرای کامل
تمام Frame با Ray Tracing
استفاده شوند.

چرا Ray-Traced Image گاهی Noise دارد؟

اگر تعداد Ray Sampleها کم باشد،
اطلاعات کافی
برای تولید تصویر کاملا پایدار
وجود ندارد.


Few Ray Samples

      │
      ▼

Noisy Result

      │
      ▼

Denoising

      │
      ▼

Cleaner Image

Denoiser
از اطلاعات Spatial،
Temporal
و داده های کمکی Scene
برای کاهش Noise استفاده می کند.

Ray Tracing به Memory System هم فشار وارد می کند

Ray Tracing
فقط یک مسئله Compute نیست.

GPU باید به داده هایی مانند:

  • Acceleration Structure،
  • Geometry،
  • Material،
  • Texture،
  • و Ray State

دسترسی داشته باشد.


Ray Work

   │
   ├── BVH Data
   ├── Geometry
   ├── Materials
   ├── Textures
   └── Ray State

   │
   ▼

Memory System

به همین دلیل
Cache،
VRAM Capacity
و Memory Bandwidth
در Ray Tracing اهمیت دارند.

Under the Hood — Ray Tracing فقط «RT Core» نیست

سخت افزار تخصصی Ray Tracing
فقط بخشی از فرایند است.

Frame واقعی
ممکن است از همکاری:

  • Shader Units،
  • Ray Traversal Hardware،
  • Texture Units،
  • Cache،
  • Memory System،
  • Denoising،
  • و Rasterization Hardware

استفاده کند.

Ray Tracing یک Pipeline کامل است،
نه فقط یک واحد سخت افزاری.

Performance Impact — چه چیزی Ray Tracing را سنگین می کند؟

هزینه Ray Tracing
می تواند با عوامل مختلف افزایش پیدا کند:

  • تعداد Rayها،
  • تعداد Bounceها،
  • پیچیدگی Scene،
  • تعداد Geometryها،
  • نوع Material،
  • تعداد Lightها،
  • Resolution،
  • و نوع Effect.

به همین دلیل
Ray-Traced Reflection،
Ray-Traced Shadow
و Path Tracing
هزینه یکسانی ندارند.

Engineering Insight — Acceleration Structure قلب Performance Ray Tracing است

اگر GPU مجبور بود
هر Ray را با تمام Triangleهای Scene مقایسه کند،
Real-Time Ray Tracing
برای Sceneهای پیچیده
بسیار دشوارتر می شد.

Acceleration Structure
کمک می کند
بخش بزرگی از Scene
اصلا وارد Intersection Test دقیق نشود.

به جای سریع تر بررسی کردن همه چیز،
ابتدا بیشتر چیزهای نامرتبط را حذف کن.

Common Mistakes — اشتباهات رایج درباره Ray Tracing
  • Ray Tracing را فقط Reflection ندانید.
  • Ray Tracing را فقط به معنی Path Tracing کامل ندانید.
  • RT Hardware را به تنهایی مسئول کل Ray Tracing فرض نکنید.
  • BVH را با Geometry Scene یکی ندانید.
  • Acceleration Structure را فقط یک Cache فرض نکنید.
  • هر Ray را فقط یک بار برخوردکننده تصور نکنید.
  • تعداد Bounce بیشتر را همیشه معادل تصویر بهتر ندانید.
  • Ray Tracing را مستقل از Memory Performance تحلیل نکنید.
  • Rasterization و Ray Tracing را همیشه دو روش کاملا جدا و غیرقابل ترکیب فرض نکنید.

مدل ذهنی ساده Ray Tracing


Generate Ray

     │
     ▼

Traverse Acceleration Structure

     │
     ▼

Intersection?

 ┌───┴───┐

No      Yes
│         │
▼         ▼

Miss    Hit

          │
          ▼

       Shading

          │
          ├── Shadow Ray
          ├── Reflection Ray
          └── Other Rays

          │
          ▼

      Final Result

سوالات متداول درباره Ray Tracing

Ray Tracing چیست؟

روشی برای Rendering است
که Rayها را در Scene دنبال می کند
تا برخورد آنها با Geometry
و رفتار نور محاسبه شود.

BVH چیست؟

Bounding Volume Hierarchy
ساختاری سلسله مراتبی
برای گروه بندی Geometry است
که جستجوی Intersection
را سریع تر می کند.

Shadow Ray چیست؟

Rayی است
که برای بررسی وجود مانع
میان Surface و Light
استفاده می شود.

چرا Ray Tracing سنگین است؟

زیرا تعداد زیادی Ray
باید در Scene دنبال شوند
و برخورد آنها
با ساختارها و Geometry بررسی شود.

تعداد Rayها و Bounceها
می تواند هزینه را بیشتر کند.

آیا Ray Tracing جای Rasterization را کاملا گرفته است؟

خیر.

در بسیاری از Workloadهای Real-Time،
هر دو روش
به صورت Hybrid
در کنار یکدیگر استفاده می شوند.

Denoising چرا لازم است؟

وقتی تعداد Ray Sampleها محدود باشد،
تصویر می تواند Noise داشته باشد.

Denoising
برای بازسازی نتیجه تمیزتر
از Sampleهای محدود استفاده می شود.

خلاصه فصل

  • Ray Tracing مسیر Rayها را در Scene دنبال می کند.
  • Ray دارای Origin و Direction است.
  • Intersection برخورد Ray با Geometry است.
  • بررسی تمام Triangleها برای هر Ray بسیار پرهزینه است.
  • Acceleration Structure جستجوی Geometry مرتبط را سریع تر می کند.
  • BVH یکی از مهم ترین ساختارهای شتاب دهنده Ray Tracing است.
  • BVH Traversal بخش های نامرتبط Scene را حذف می کند.
  • Ray Tracing Hardware می تواند Traversal و Intersection را شتاب دهد.
  • Closest Hit نزدیک ترین برخورد Ray را مشخص می کند.
  • Miss زمانی رخ می دهد که Ray به Geometry برخورد نکند.
  • Shadow Ray برای بررسی Visibility نور استفاده می شود.
  • Reflection و Refraction می توانند Rayهای جدید ایجاد کنند.
  • تعداد Bounceها معمولا برای کنترل هزینه محدود می شود.
  • Hybrid Rendering از Rasterization و Ray Tracing در کنار هم استفاده می کند.
  • Denoising برای کاهش Noise ناشی از Sample محدود استفاده می شود.
  • Ray Tracing به Compute، Memory و سخت افزار تخصصی به صورت هم زمان وابسته است.

سطح: مقدماتی تا متوسط

پیش نیاز:
Ray Tracing،
Ray Intersection،
Shadow Ray،
Reflection،
Refraction

موضوع:
GPU Ray Tracing Architecture

زمان مطالعه:
حدود 8 تا 10 دقیقه


GPU RAY TRACING ARCHITECTURE

Path Tracing چیست؟

Path Tracing
روشی پیشرفته تر برای شبیه سازی نور است
که مسیرهای مختلف حرکت نور
را در Scene دنبال می کند.

به جای محاسبه فقط یک Reflection
یا یک Shadow،
Path Tracing تلاش می کند
رفتار پیچیده تر نور
مانند Bounceهای متعدد،
Indirect Lighting
و انتقال نور میان Surfaceها
را شبیه سازی کند.


پاسخ سریع

Path Tracing
نوعی Ray Tracing است
که Rayها می توانند
پس از برخورد با Surface
چندین بار در Scene Bounce کنند.

با جمع آوری Sampleهای متعدد
از مسیرهای احتمالی نور،
تصویری تولید می شود
که Lighting،
Reflection،
Shadow
و Global Illumination
را به شکل یکپارچه تر مدل می کند.

در این فصل چه چیزهایی یاد می گیریم؟

  • Path Tracing چیست.
  • تفاوت آن با Ray Tracing ساده چیست.
  • Bounce چیست.
  • Global Illumination چیست.
  • Indirect Lighting چه معنایی دارد.
  • چرا Path Tracing به Sampleهای زیاد نیاز دارد.
  • چرا تصویر Path Traced می تواند Noise داشته باشد.
  • Denoising چه نقشی دارد.
  • چرا Path Tracing برای Real-Time Rendering سنگین است.

Ray Tracing و Path Tracing چه تفاوتی دارند؟

Ray Tracing
یک مفهوم کلی برای دنبال کردن Rayها در Scene است.

Path Tracing
یکی از روش های استفاده از Ray Tracing
برای شبیه سازی کامل تر رفتار نور است.

روش ایده کلی
Ray Tracing Rayها برای Effectهای مشخص
مانند Shadow یا Reflection دنبال می شوند.
Path Tracing مسیرهای متعدد نور
با Bounceهای مختلف نمونه برداری می شوند.

Path یعنی مسیر نور

یک مسیر نور
می تواند شامل چند برخورد
میان Surfaceهای مختلف باشد.


Camera

  ●
   
    
     ● Surface A
      
       
        ● Surface B
         
          
           ● Light

این زنجیره برخوردها
یک Light Path
را تشکیل می دهد.

Bounceهای متعدد چرا مهم هستند؟

در دنیای واقعی،
نور معمولا فقط یک بار
به Surface برخورد نمی کند.

نور می تواند
بارها میان Surfaceها Bounce کند.


Light

  ●
   
    ▼

Wall A

    
     ▼

Floor

     
      ▼

Object

      
       ▼

Camera

هر Bounce
می تواند بخشی از Color
و Energy سطح قبلی را
به Surface بعدی منتقل کند.

Indirect Lighting چیست؟

Direct Lighting
نوری است
که مستقیما از Light
به Surface می رسد.

Indirect Lighting
نوری است
که ابتدا به Surface دیگری برخورد کرده
و سپس به نقطه مورد نظر رسیده است.


Direct

Light ─────────► Surface


Indirect

Light ─► Wall ─► Surface

Indirect Lighting
نقش بسیار مهمی
در طبیعی دیده شدن Scene دارد.

Global Illumination چیست؟


Global Illumination

به محاسبه نور
با در نظر گرفتن
تعامل نور میان بخش های مختلف Scene
گفته می شود.

یعنی فقط نور مستقیم
بررسی نمی شود.

Bounceهای نور،
بازتاب رنگ Surfaceها
و روشنایی غیرمستقیم
نیز در نتیجه نقش دارند.


Light

  │
  ▼

Red Wall

  │
  │ Reflected Red Light
  ▼

White Floor

  │
  ▼

Slight Red Tint

این پدیده
گاهی
Color Bleeding
نامیده می شود.

Color Bleeding چیست؟

وقتی نور
از یک Surface رنگی بازتاب می شود،
می تواند بخشی از رنگ آن Surface
را به محیط اطراف منتقل کند.


White Light

    │
    ▼

Blue Wall

    │
    ▼

Reflected Bluish Light

    │
    ▼

Nearby Object

Path Tracing
می تواند این نوع اثرها
را به شکل طبیعی تری مدل کند.

چرا Path Tracing از Sampling استفاده می کند؟

پس از برخورد Ray با Surface،
مسیرهای بسیار زیادی
برای ادامه نور وجود دارند.


        ↖
      ↑
    ↗

────●──── Surface

    ↘
      ↓
        ↙

بررسی تمام مسیرهای ممکن
عملا بسیار پرهزینه است.

بنابراین
Path Tracer
فقط تعدادی مسیر را Sample می کند
و از آنها
برای تخمین نتیجه نهایی استفاده می کند.

اگر فقط یک Sample داشته باشیم چه؟

یک Sample
فقط یکی از مسیرهای ممکن نور
را نمایندگی می کند.


Possible Paths

A
B
C
D
E
F

Sampled

C

نتیجه
ممکن است نماینده دقیقی
از میانگین تمام مسیرهای نور نباشد.

به همین دلیل
تصویر می تواند Noise داشته باشد.

Sample بیشتر چه تغییری ایجاد می کند؟

هرچه Sampleهای بیشتری جمع شود،
تخمین Lighting معمولا پایدارتر می شود.


1 Sample

Very Noisy


8 Samples

Less Noisy


64 Samples

Cleaner


Many Samples

Closer to Stable Result

اما Sample بیشتر
به معنی Ray بیشتر
و در نتیجه
هزینه محاسباتی بیشتر است.

Samples Per Pixel چیست؟


Samples Per Pixel — SPP

تعداد Sampleهایی است
که برای تخمین رنگ
یک Pixel استفاده می شود.


Pixel

Sample 1
Sample 2
Sample 3
Sample 4

    │
    ▼

Average / Accumulate

    │
    ▼

Final Pixel Estimate

SPP بیشتر
معمولا کیفیت تخمین را افزایش می دهد
اما Render Time را نیز بالا می برد.

Noise از کجا می آید؟

Noise نتیجه
عدم قطعیت Sample محدود است.

Pixelهای مجاور
ممکن است مسیرهای متفاوتی
را Sample کنند
و نتیجه های متفاوتی بگیرند.


Pixel A

Samples bright path


Pixel B

Samples dark path


Result

Visible Noise

Denoising چرا مهم است؟

در Real-Time Rendering
نمی توان همیشه
صدها یا هزاران Sample
برای هر Pixel محاسبه کرد.

بنابراین
Renderer ممکن است
Sample کمی تولید کند
و سپس Denoiser
نتیجه را تمیزتر کند.


Few Samples

      │
      ▼

Noisy Image

      │
      ▼

Denoiser

      │
      ▼

Cleaner Image

Temporal Accumulation چیست؟

در Real-Time Graphics
می توان اطلاعات چند Frame
را با یکدیگر ترکیب کرد.


Frame 1 Samples
       │
       ▼

Frame 2 Samples
       │
       ▼

Frame 3 Samples
       │
       ▼

Temporal Accumulation

       │
       ▼

More Stable Result

این کار
کمک می کند
Sampleهای محدود هر Frame
در طول زمان
اطلاعات بیشتری ایجاد کنند.

اما حرکت Camera یا Objectها
مدیریت این فرایند را
پیچیده تر می کند.

یک Path چه زمانی تمام می شود؟

Path می تواند
به دلایل مختلفی
متوقف شود.

  • Ray از Scene خارج شود،
  • حداکثر Bounce تعیین شده برسد،
  • Contribution مسیر بسیار کم شود،
  • یا الگوریتم تصمیم بگیرد
    ادامه مسیر ارزش محاسباتی ندارد.


Ray

 │
 ▼

Bounce 1

 │
 ▼

Bounce 2

 │
 ▼

Bounce 3

 │
 ▼

Terminate

Real-Time Path Tracing چرا دشوار است؟

یک Frame
می تواند میلیون ها Pixel داشته باشد.

اگر برای هر Pixel
چند Ray
و برای هر Ray
چند Bounce محاسبه شود،
تعداد Rayها بسیار سریع بالا می رود.


Millions of Pixels

      ×

Samples per Pixel

      ×

Multiple Bounces

      │
      ▼

Huge Ray Workload

به همین دلیل
Real-Time Path Tracing
به ترکیبی از:

  • GPU قدرتمند،
  • Ray Tracing Hardware،
  • Acceleration Structures،
  • Denoising،
  • Temporal Techniques،
  • و Reconstruction

وابسته است.

Offline Path Tracing

در Rendering آفلاین
محدودیت زمانی یک Frame
مانند بازی Real-Time وجود ندارد.

Renderer می تواند
Sampleهای بسیار بیشتری
برای رسیدن به کیفیت بالاتر
محاسبه کند.


Real-Time

Milliseconds per Frame


Offline Rendering

Seconds
Minutes
or Longer
per Frame

به همین دلیل
Path Tracing
سال ها در Film Rendering
و Visualization حرفه ای
استفاده شده است.

Hybrid Ray Tracing و Path Tracing کامل

روش رویکرد کلی
Hybrid Rendering Rasterization برای بخش اصلی Frame
و Ray Tracing برای Effectهای مشخص.
Path Tracing بخش بسیار بیشتری از Lighting
با دنبال کردن Pathهای نور محاسبه می شود.

Under the Hood — Path Tracing جواب دقیق همه مسیرها را محاسبه نمی کند

تعداد مسیرهای ممکن نور
در یک Scene واقعی
بسیار بزرگ است.

Path Tracing
معمولا همه آنها را دنبال نمی کند.

در عوض
از Sampling آماری
برای تخمین نتیجه استفاده می کند.


All Possible Light Paths

████████████████████████████


Actually Sampled Paths

█   █      █  █      █


        │
        ▼

Statistical Estimate

این نکته
دلیل اصلی وجود Noise
و اهمیت Sample Count است.

Performance Impact — چه چیزی هزینه Path Tracing را بالا می برد؟
  • Resolution بالاتر،
  • Samples Per Pixel بیشتر،
  • Bounce بیشتر،
  • Geometry پیچیده تر،
  • Materialهای پیچیده تر،
  • Lighting پیچیده،
  • و Denoising یا Reconstruction سنگین تر.

به همین دلیل
Path Tracing یکی از سنگین ترین
Real-Time Graphics Workloadها است.

Engineering Insight — Real-Time Path Tracing بیشتر یک مسئله مدیریت Sample است

در Real-Time Rendering
نمی توان Sample نامحدود داشت.

بنابراین بخش بزرگی از طراحی
به این سوال برمی گردد:

با تعداد محدود Ray
چطور بهترین تصویر ممکن را بسازیم؟

به همین دلیل
Denoising،
Temporal Accumulation،
Adaptive Sampling
و Reconstruction
به اندازه خود Ray Tracing
اهمیت پیدا می کنند.

Common Mistakes — اشتباهات رایج درباره Path Tracing
  • Path Tracing را کاملا جدا از Ray Tracing ندانید.
  • Path Tracing را فقط Reflection بهتر فرض نکنید.
  • Global Illumination را فقط Shadow نرم ندانید.
  • Sample بیشتر را بدون هزینه فرض نکنید.
  • Noise را خرابی الگوریتم تصور نکنید؛ اغلب نتیجه Sample محدود است.
  • Denoising را جایگزین کامل اطلاعات واقعی نور ندانید.
  • Bounce بیشتر را همیشه معادل تصویر بهتر ندانید.
  • Path Tracing Real-Time را فقط به قدرت RT Hardware نسبت ندهید.

مدل ذهنی ساده Path Tracing


Pixel

 │
 ▼

Generate Ray

 │
 ▼

Hit Surface

 │
 ▼

Sample New Direction

 │
 ▼

Bounce

 │
 ▼

Hit Another Surface

 │
 ▼

Repeat

 │
 ▼

Accumulate Light Contribution

 │
 ▼

Average Samples

 │
 ▼

Denoise / Reconstruct

 │
 ▼

Final Pixel

سوالات متداول درباره Path Tracing

Path Tracing چیست؟

روشی مبتنی بر Ray Tracing است
که مسیرهای متعدد نور
را با Bounceهای مختلف Sample می کند
تا Lighting نهایی تخمین زده شود.

Global Illumination چیست؟

محاسبه نور با در نظر گرفتن
نور مستقیم
و تعامل غیرمستقیم نور
میان Surfaceهای مختلف Scene است.

Samples Per Pixel چیست؟

تعداد Sampleهایی است
که برای تخمین رنگ
یک Pixel استفاده می شود.

چرا Path Tracing Noise دارد؟

زیرا فقط تعداد محدودی
از مسیرهای بسیار زیاد نور
Sample می شوند.

Sample بیشتر
معمولا Noise را کاهش می دهد.

چرا Denoising در Path Tracing مهم است؟

زیرا در Real-Time Rendering
امکان محاسبه Sampleهای بسیار زیاد وجود ندارد
و Denoiser
کمک می کند از Sampleهای محدود
تصویر تمیزتری ساخته شود.

Path Tracing و Rasterization می توانند با هم استفاده شوند؟

بله.

موتور Rendering می تواند
برای برخی بخش ها از Rasterization
و برای بخش های دیگر
از Ray یا Path Tracing استفاده کند.

خلاصه فصل

  • Path Tracing یکی از روش های مبتنی بر Ray Tracing است.
  • نور می تواند چندین بار میان Surfaceها Bounce کند.
  • Indirect Lighting نور بازتاب شده از Surfaceهای دیگر است.
  • Global Illumination تعامل گسترده نور در Scene را در نظر می گیرد.
  • Color Bleeding یکی از نتایج Indirect Lighting است.
  • Path Tracing همه مسیرهای ممکن نور را بررسی نمی کند؛ آنها را Sample می کند.
  • Sample محدود می تواند Noise ایجاد کند.
  • Samples Per Pixel تعداد Sampleهای هر Pixel را بیان می کند.
  • Sample بیشتر معمولا کیفیت بالاتری ایجاد می کند اما هزینه را افزایش می دهد.
  • Denoising برای ساخت تصویر تمیزتر از Sampleهای محدود استفاده می شود.
  • Temporal Accumulation اطلاعات چند Frame را ترکیب می کند.
  • Bounceها برای کنترل هزینه معمولا محدود می شوند.
  • Real-Time Path Tracing به Ray Hardware، Memory، Denoising و Reconstruction وابسته است.
  • Offline Rendering می تواند زمان بسیار بیشتری برای Sampleهای بیشتر صرف کند.

سطح: مقدماتی تا متوسط

پیش نیاز:
GPU Execution Architecture،
Matrix Operations،
Memory Bandwidth،
HBM

موضوع:
GPU AI Acceleration

زمان مطالعه:
حدود 8 تا 10 دقیقه


GPU AI ACCELERATION

GPU چگونه محاسبات هوش مصنوعی را شتاب می دهد؟

بخش بزرگی از محاسبات
Machine Learning
و Deep Learning
از عملیات ماتریسی
و محاسباتی تشکیل شده است
که می توانند روی تعداد زیادی داده
به صورت موازی انجام شوند.

این دقیقا همان نوع Workloadی است
که GPU برای آن مناسب است.

GPUهای مدرن
علاوه بر Shader و Compute Unitهای عمومی،
ممکن است واحدهای تخصصی
برای محاسبات Matrix و AI نیز داشته باشند.


پاسخ سریع

GPU برای AI مناسب است
زیرا می تواند
تعداد بسیار زیادی عملیات ریاضی مشابه
را به صورت موازی اجرا کند.

شبکه های عصبی
به طور گسترده از
Matrix Multiplication،
Vector Operations
و عملیات Multiply-Accumulate
استفاده می کنند.

GPUهای جدید
ممکن است برای این نوع محاسبات
واحدهای تخصصی Matrix
نیز داشته باشند.

در این فصل چه چیزهایی یاد می گیریم؟

  • چرا GPU برای AI مناسب است.
  • Matrix Multiplication چرا مهم است.
  • Multiply-Accumulate چیست.
  • Matrix / Tensor Hardware چه کاری انجام می دهد.
  • Training و Inference چه تفاوتی دارند.
  • Precision چرا در AI مهم است.
  • چرا Memory Capacity و Bandwidth در AI اهمیت دارند.
  • چرا AI Performance فقط با تعداد AI Coreها مشخص نمی شود.

چرا GPU برای AI مناسب است؟

بسیاری از الگوریتم های AI
یک عملیات مشابه را
روی حجم بزرگی از داده
بارها تکرار می کنند.


Large Amount of Data

        │
        ▼

Same / Similar Math

        │
        ▼

Massive Parallel Work

        │
        ▼

GPU

GPU به دلیل
Parallelism بالا
می تواند تعداد زیادی از این عملیات
را هم زمان پردازش کند.

شبکه عصبی در ساده ترین مدل

یک Neural Network
را می توان مجموعه ای از Layerها در نظر گرفت
که داده را مرحله به مرحله
تبدیل می کنند.


Input

  │
  ▼

Layer 1

  │
  ▼

Layer 2

  │
  ▼

Layer 3

  │
  ▼

Output

در بسیاری از این Layerها
حجم زیادی از محاسبات
روی Matrixها و Tensorها انجام می شود.

چرا Matrix Multiplication مهم است؟

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


Matrix A

× 

Matrix B

=

Matrix C

هر عنصر Matrix خروجی
از ترکیب تعداد زیادی
Multiply و Add
ساخته می شود.

از آنجا که بسیاری از این عملیات
می توانند مستقل از یکدیگر انجام شوند،
GPU برای اجرای آنها مناسب است.

Multiply-Accumulate چیست؟


Multiply-Accumulate — MAC

عملیاتی است
که یک ضرب انجام می دهد
و نتیجه آن را
به مقدار قبلی اضافه می کند.


a × b + c

این نوع عملیات
در Matrix Multiplication
و بسیاری از شبکه های عصبی
به صورت بسیار گسترده تکرار می شود.

Matrix / Tensor Hardware چیست؟

برخی GPUهای مدرن
واحدهای تخصصی
برای اجرای سریع تر
عملیات ماتریسی دارند.


General Shader / Compute Unit

        +
        
Specialized Matrix Hardware

        │
        ▼

AI / Matrix Workloads

نام دقیق این واحدها
میان معماری ها و شرکت ها متفاوت است،
اما ایده اصلی مشابه است:

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

Tensor چیست؟

در ساده ترین توضیح،
Tensor
ساختاری برای نگهداری داده
در یک یا چند بعد است.


Scalar

5


Vector

[1 2 3]


Matrix

[1 2]
[3 4]


Higher-Dimensional Tensor

Data in More Dimensions

Frameworkهای هوش مصنوعی
معمولا داده ها،
Weightها
و Activationها
را به صورت Tensor مدیریت می کنند.

Training چیست؟

Training
فرایندی است
که در آن مدل
Weightهای خود را
بر اساس داده آموزشی تنظیم می کند.


Training Data

     │
     ▼

Model

     │
     ▼

Prediction

     │
     ▼

Compare with Target

     │
     ▼

Calculate Error

     │
     ▼

Update Weights

     │
     ▼

Repeat

Training
معمولا محاسبات زیادی
و مقدار قابل توجهی حافظه نیاز دارد.

Inference چیست؟

Inference
استفاده از مدل آموزش دیده
برای تولید نتیجه جدید است.


New Input

    │
    ▼

Trained Model

    │
    ▼

Inference

    │
    ▼

Prediction / Output

برای مثال:

  • تشخیص تصویر،
  • تولید متن،
  • پردازش صدا،
  • یا Upscaling تصویر

می توانند شامل Inference باشند.

Training و Inference چه تفاوتی دارند؟

مرحله هدف
Training یادگیری و تغییر Weightهای مدل
Inference استفاده از Weightهای آموزش دیده
برای تولید خروجی

نیاز سخت افزاری این دو
می تواند متفاوت باشد.

Precision چرا مهم است؟

عددها می توانند
با Formatهای مختلفی
در سخت افزار نمایش داده شوند.

نمونه های رایج در AI
می توانند شامل:


FP32

FP16

BF16

INT8

and other formats

باشند.

Format کوچک تر
می تواند:

  • حافظه کمتری مصرف کند،
  • داده کمتری منتقل کند،
  • و در سخت افزار مناسب
    Throughput بیشتری فراهم کند.

اما کاهش Precision
باید با نیاز دقت مدل
هماهنگ باشد.

Mixed Precision چیست؟

در Mixed Precision
تمام محاسبات
الزاما با یک Format عددی
انجام نمی شوند.


Some Operations

FP16 / BF16

      +

Other Operations

Higher Precision

      │
      ▼

Mixed Precision Workflow

هدف
ایجاد تعادل میان:

  • Performance،
  • Memory Usage،
  • و Numerical Accuracy

است.

چرا VRAM Capacity در AI مهم است؟

مدل AI
می تواند مقدار زیادی داده
در حافظه نگهداری کند.

از جمله:

  • Model Weights،
  • Activations،
  • Intermediate Results،
  • Training State،
  • و Input Data.


AI Workload

├── Weights
├── Activations
├── Inputs
├── Temporary Buffers
└── Other State

        │
        ▼

GPU Memory

اگر Working Set
در حافظه جا نشود،
مدیریت داده
پیچیده تر و پرهزینه تر می شود.

چرا Memory Bandwidth در AI اهمیت دارد؟

واحدهای Matrix
برای کار کردن
به جریان مداوم داده نیاز دارند.


Memory

  │
  ▼

Weights + Activations

  │
  ▼

Matrix Units

  │
  ▼

AI Computation

اگر Compute Units
سریع تر از Memory System
داده مصرف کنند،
Workload می تواند
Memory-Bound شود.

چرا HBM در AI Acceleratorها رایج است؟

AI Acceleratorهای قدرتمند
می توانند حجم بسیار بزرگی
از عملیات ماتریسی انجام دهند.

برای تغذیه این واحدها
به Memory Bandwidth زیادی نیاز است.


High Compute Throughput

        │
        ▼

Needs Large Data Flow

        │
        ▼

High Memory Bandwidth

        │
        ▼

HBM

به همین دلیل
HBM در بسیاری از GPUها
و Acceleratorهای حرفه ای AI
اهمیت زیادی دارد.

Model Size فقط تعداد Parameter نیست

وقتی درباره حافظه مورد نیاز مدل صحبت می کنیم،
فقط Weightها مهم نیستند.


Memory Requirement

      │
      ├── Model Weights
      ├── Activations
      ├── Temporary Buffers
      ├── Runtime Overhead
      └── Training State

به همین دلیل
دو Workload با Model Size مشابه
ممکن است
حافظه متفاوتی مصرف کنند.

AI فقط برای مدل های زبانی نیست

AI Acceleration
در Graphics نیز
کاربردهای مهمی دارد.

Upscaling

ساخت تصویر با Resolution بالاتر
از اطلاعات کمتر.

Denoising

کاهش Noise در Ray Tracing و Path Tracing.

Frame Reconstruction

استفاده از اطلاعات Frameهای مختلف
برای تولید نتیجه بهتر.

Content Processing

پردازش تصویر،
ویدیو
و سایر داده های رسانه ای.

AI و Ray Tracing چگونه با هم کار می کنند؟

Ray Tracing Real-Time
اغلب با Sample محدود اجرا می شود.

AI می تواند
در بازسازی تصویر
و کاهش Noise
کمک کند.


Limited Ray Samples

      │
      ▼

Noisy / Partial Image

      │
      ▼

AI Reconstruction / Denoising

      │
      ▼

Cleaner Final Image

Under the Hood — AI Core به تنهایی AI اجرا نمی کند

یک AI Workload واقعی
به همکاری چند بخش GPU نیاز دارد.


AI Workload

      │
      ├── Matrix Hardware
      ├── General Compute Units
      ├── Registers
      ├── Cache
      ├── Memory Controllers
      ├── HBM / VRAM
      └── Interconnect

اگر یکی از این بخش ها
Bottleneck شود،
بقیه منابع
ممکن است به طور کامل استفاده نشوند.

AI Performance حاصل یک سیستم است،
نه فقط یک نوع Core.

Performance Impact — چه چیزی AI Workload را محدود می کند؟

Bottleneck می تواند
در بخش های مختلفی باشد:

  • Matrix Compute،
  • Memory Bandwidth،
  • VRAM Capacity،
  • Data Transfer،
  • Precision،
  • Batch Size،
  • یا ساختار خود مدل.

به همین دلیل
یک GPU ممکن است
در یک مدل بسیار سریع
و در مدل دیگری
کمتر موثر باشد.

Engineering Insight — Compute سریع بدون Data Feed کافی بی فایده است

اگر واحدهای Matrix
توان محاسباتی بسیار بالایی داشته باشند
اما داده کافی
از Memory System دریافت نکنند،
بخشی از توان آنها
استفاده نمی شود.


Fast Matrix Units

       ▲
       │
Need Data
       │

Memory System

       │
       ▼

Possible Bottleneck

در AI،
Compute و Memory باید با هم مقیاس پیدا کنند.

Common Mistakes — اشتباهات رایج درباره GPU و AI
  • AI Performance را فقط با تعداد AI Coreها مقایسه نکنید.
  • Training و Inference را یک Workload یکسان فرض نکنید.
  • Precision کمتر را همیشه بهتر ندانید.
  • VRAM Capacity را با Memory Bandwidth یکی ندانید.
  • Model Size را فقط برابر تعداد Weightها ندانید.
  • GPU را فقط برای Graphics مناسب ندانید.
  • Matrix Hardware را جایگزین کامل Compute Unitهای عمومی فرض نکنید.
  • AI Acceleration را مستقل از Memory System تحلیل نکنید.

مدل ذهنی ساده AI Acceleration


AI Model

   │
   ▼

Tensor Data

   │
   ▼

Matrix Operations

   │
   ▼

GPU Compute
+
Specialized Matrix Hardware

   │
   ▼

Memory System

   │
   ▼

Results

   │
   ▼

Next Layer

سوالات متداول درباره AI Acceleration

چرا GPU برای هوش مصنوعی مناسب است؟

زیرا بسیاری از محاسبات AI
Parallelism زیادی دارند
و GPU می تواند
تعداد بزرگی عملیات مشابه
را به صورت موازی اجرا کند.

Matrix Hardware چیست؟

سخت افزار تخصصی
برای شتاب دادن عملیات ماتریسی
و Multiply-Accumulate
است که در بسیاری از AI Workloadها پرتکرار هستند.

Training و Inference چه تفاوتی دارند؟

Training
برای یادگیری و تغییر Weightهای مدل است.

Inference
از مدل آموزش دیده
برای تولید خروجی استفاده می کند.

چرا Precision پایین تر در AI استفاده می شود؟

Formatهای کوچک تر
می توانند حافظه و Bandwidth کمتری مصرف کنند
و روی سخت افزار مناسب
Throughput بیشتری ایجاد کنند.

اما دقت عددی مورد نیاز مدل
باید حفظ شود.

چرا HBM برای AI مهم است؟

زیرا شتاب دهنده های AI
برای تغذیه واحدهای محاسباتی سریع
به Memory Bandwidth بسیار زیادی نیاز دارند.

HBM برای چنین Workloadهایی
مناسب است.

آیا GPU فقط برای Training استفاده می شود؟

خیر.

GPU می تواند
هم برای Training
و هم برای Inference
و همچنین کاربردهای AI در Graphics
استفاده شود.

خلاصه فصل

  • GPU به دلیل Parallelism زیاد برای AI مناسب است.
  • بسیاری از AI Workloadها به Matrix Multiplication وابسته هستند.
  • Multiply-Accumulate یکی از عملیات پرتکرار در این محاسبات است.
  • برخی GPUها سخت افزار تخصصی Matrix یا AI دارند.
  • Tensor ساختاری برای داده های چندبعدی است.
  • Training برای یادگیری Weightها و Inference برای استفاده از مدل است.
  • Precision پایین تر می تواند مصرف حافظه و هزینه محاسبات را کاهش دهد.
  • Mixed Precision میان Performance و Accuracy تعادل ایجاد می کند.
  • VRAM Capacity تعیین می کند چه مقدار از Working Set مدل در حافظه جا می شود.
  • Memory Bandwidth برای تغذیه واحدهای محاسباتی AI بسیار مهم است.
  • HBM در بسیاری از AI Acceleratorها به دلیل Bandwidth بالا استفاده می شود.
  • AI در Graphics برای Upscaling، Denoising و Reconstruction نیز استفاده می شود.
  • AI Performance حاصل همکاری Compute، Memory و سخت افزار تخصصی است.

سطح: مقدماتی تا متوسط

پیش نیاز:
GPU Performance Metrics،
Memory Architecture،
Execution Architecture،
Graphics Pipeline

موضوع:
GPU Performance Analysis

زمان مطالعه:
حدود 10 تا 12 دقیقه


GPU PERFORMANCE ANALYSIS

GPU Bottleneck چیست و چگونه آن را پیدا کنیم؟

وقتی Performance پایین است،
دلیل آن همیشه
«ضعیف بودن GPU»
نیست.

ممکن است
Pixel Shader سنگین باشد،
Memory Bandwidth محدود شده باشد،
CPU نتواند Workload را سریع آماده کند،
VRAM کافی نباشد
یا بخشی از Pipeline
منتظر داده بماند.

Bottleneck Analysis
یعنی پیدا کردن بخشی
که در شرایط فعلی
سرعت کل سیستم را محدود می کند.


پاسخ سریع

Bottleneck
بخشی از سیستم است
که Performance کل Workload
بیشتر از همه
توسط آن محدود می شود.

در GPU Workloadها،
Bottleneck می تواند
در Compute،
Memory،
Texture Sampling،
Rasterization،
Render Output،
Ray Tracing،
CPU،
Data Transfer
یا حتی Software قرار داشته باشد.

بهترین روش تشخیص Bottleneck
اندازه گیری،
Profiling
و تغییر کنترل شده Workload است.

در این فصل چه چیزهایی یاد می گیریم؟

  • Bottleneck چیست.
  • چرا Bottleneck ثابت نیست.
  • CPU-Bound و GPU-Bound چه تفاوتی دارند.
  • Compute-Bound و Memory-Bound چه هستند.
  • چگونه Resolution به تشخیص Bottleneck کمک می کند.
  • چرا کاهش تنظیمات گرافیکی ابزار تشخیصی خوبی است.
  • VRAM Bottleneck چه نشانه هایی دارد.
  • چرا Utilization به تنهایی کافی نیست.
  • چرا Profiling از حدس زدن مهم تر است.

Bottleneck دقیقا چیست؟

یک سیستم
از چند مرحله تشکیل شده است.

اگر یکی از این مراحل
نسبت به بقیه
ظرفیت کمتری برای Workload فعلی داشته باشد،
سرعت کل سیستم
به همان مرحله محدود می شود.


Stage A

████████████████████


Stage B

████████


Stage C

██████████████████


Overall Throughput

Limited by Stage B

Bottleneck سریع ترین بخش سیستم نیست؛
کندترین بخش موثر در مسیر Workload است.

Bottleneck همیشه ثابت نیست

یک GPU
ممکن است در یک Scene
Pixel-Bound باشد
و چند ثانیه بعد
در Scene دیگری
Memory-Bound شود.


Scene A

Heavy Pixel Shading
      │
      ▼
Shader Bottleneck


Scene B

Large Texture Traffic
      │
      ▼
Memory Bottleneck


Scene C

Many Draw Calls
      │
      ▼
Possible CPU Bottleneck

بنابراین Bottleneck
یک ویژگی ثابت کارت گرافیک نیست؛
نتیجه تعامل

Workload + Hardware + Software

است.

CPU-Bound یعنی چه؟

در برخی Workloadها،
CPU نمی تواند
با سرعت کافی
کار جدید برای GPU آماده کند.


CPU

Prepare Work
██████

       │
       ▼

GPU

Can Process More
████████████████

در این حالت،
GPU ممکن است
بخشی از زمان خود را
منتظر Work جدید بماند.

افزایش قدرت GPU
در چنین شرایطی
ممکن است Performance را
به شکل قابل توجهی افزایش ندهد.

GPU-Bound یعنی چه؟

اگر CPU
کار کافی آماده کند
اما GPU
برای پردازش Frame
زمان بیشتری نیاز داشته باشد،
Workload می تواند
GPU-Bound باشد.


CPU

Work Ready
████████████████


GPU

Rendering Work
████████

        ▲
        │
   Limiting Stage

در این حالت،
کاهش Workload گرافیکی
یا استفاده از GPU سریع تر
ممکن است تاثیر بیشتری داشته باشد.

Resolution چگونه به تشخیص Bottleneck کمک می کند؟

یکی از تست های ساده
برای Gaming
تغییر Resolution است.

اگر Resolution را
به شکل قابل توجهی کاهش دهیم،
Pixel Workload
و بخشی از Memory Traffic
کاهش پیدا می کند.


High Resolution

3840 × 2160

      │
      ▼

More Pixel Work


Lower Resolution

1920 × 1080

      │
      ▼

Less Pixel Work

اگر FPS
با کاهش Resolution
به شکل زیادی افزایش پیدا کند،
این نشانه ای است
که GPU-side Workload
اهمیت زیادی داشته است.

اگر FPS
تقریبا ثابت بماند،
ممکن است محدودیت
در بخش دیگری مانند CPU باشد.


نکته مهم

تست Resolution
یک ابزار تشخیصی مفید است،
اما اثبات قطعی Bottleneck نیست.

Game Engine،
Upscaling،
Frame Generation،
V-Sync،
Frame Cap،
Dynamic Resolution
و سایر عوامل
می توانند نتیجه را تغییر دهند.

Compute-Bound

اگر واحدهای محاسباتی GPU
عامل اصلی محدودکننده باشند،
Workload
Compute-Bound است.

نمونه هایی از عوامل ایجاد فشار Compute:

  • Shaderهای ریاضی سنگین،
  • عملیات Matrix زیاد،
  • Lighting پیچیده،
  • Simulation،
  • و برخی AI Workloadها.


Data Available

      │
      ▼

Execution Units

████████████████████

      ▲
      │
 Fully Loaded

      │
      ▼

Compute Bottleneck

Memory-Bound

اگر واحدهای اجرایی
به اندازه کافی سریع باشند
اما داده
با نرخ مناسب در دسترس آنها قرار نگیرد،
Workload می تواند
Memory-Bound باشد.


Execution Units

████████████████████

       ▲
       │
   Need More Data
       │

Memory System

████████

مشکل ممکن است
به Bandwidth،
Latency،
Cache Miss،
Data Layout
یا Access Pattern مربوط باشد.

Memory Bottleneck فقط Bandwidth نیست

دو Workload
ممکن است هر دو
Memory-Bound به نظر برسند
اما دلیل متفاوتی داشته باشند.

مشکل توضیح
Bandwidth-Bound حجم داده بسیار زیاد است
و مسیر حافظه نزدیک اشباع قرار دارد.
Latency-Bound Threadها برای پاسخ درخواست های حافظه
منتظر می مانند
و Parallelism کافی برای پنهان کردن انتظار وجود ندارد.

Texture Bottleneck

Shaderی که
Texture Sampleهای زیادی انجام می دهد
می تواند
Texture Hardware،
Cache
یا Memory System
را تحت فشار قرار دهد.


Pixel Shader

   │
   ├── Sample
   ├── Sample
   ├── Sample
   ├── Sample
   ├── Sample
   └── Sample

   │
   ▼

Texture / Memory Pressure

Filtering پیچیده،
Textureهای بزرگ
و Locality ضعیف
می توانند این فشار را بیشتر کنند.

Pixel Shader Bottleneck

Resolution بالا
و Shaderهای پیچیده
می توانند حجم بسیار بزرگی
از Fragment Work ایجاد کنند.


More Pixels

     ×

Expensive Pixel Shader

     │
     ▼

Large Shader Workload

Effectهایی مانند
Lighting پیچیده،
Materialهای سنگین
و Post Processing
می توانند فشار این بخش را افزایش دهند.

Geometry Bottleneck

گاهی مشکل
تعداد Pixelها نیست؛
تعداد Primitiveها
و پردازش Geometry است.

نمونه ها:

  • Meshهای بسیار متراکم،
  • Tessellation زیاد،
  • Geometry Amplification،
  • و Draw Workload سنگین.


Huge Geometry Count

      │
      ▼

Vertex / Primitive Processing

      │
      ▼

Geometry Pressure

Render Output Bottleneck

Workloadهایی با:

  • Resolution بالا،
  • Multiple Render Targets،
  • Blending زیاد،
  • Overdraw زیاد،
  • و Pixel Write سنگین

می توانند
Render Output
و Memory Traffic
را تحت فشار قرار دهند.


Many Fragment Outputs

       │
       ▼

Depth / Blend / Writes

       │
       ▼

ROP + Memory Pressure

Ray Tracing Bottleneck

Ray Tracing
می تواند فشار را
در چند بخش مختلف ایجاد کند:


Ray Tracing Work

      │
      ├── BVH Traversal
      ├── Intersection
      ├── Shading
      ├── Texture Sampling
      ├── Memory Access
      └── Denoising

بنابراین پایین بودن Performance
در Ray Tracing
الزاما فقط به معنی
کمبود Ray-Tracing Hardware نیست.

AI Workload Bottleneck

در AI نیز
محدودیت می تواند
در بخش های مختلف باشد.

  • Matrix Compute،
  • Memory Bandwidth،
  • VRAM Capacity،
  • Data Transfer،
  • Interconnect،
  • یا ساختار مدل.

مدلی که
Compute-heavy است
با مدلی که
بیشتر درگیر Memory Transfer است
رفتار Performance یکسانی ندارد.

وقتی VRAM کافی نیست

کمبود VRAM
با کمبود Bandwidth
یکسان نیست.

اگر Working Set
از ظرفیت موثر حافظه GPU بیشتر شود،
سیستم ممکن است مجبور شود
داده را بیشتر جابه جا کند
یا Resourceهای مختلف را
مرتب مدیریت کند.


Required Working Set

████████████████████


Available VRAM

██████████

      │
      ▼

Memory Pressure

نتیجه ممکن است
به صورت افت Performance،
Stutter
یا رفتار ناپایدارتر ظاهر شود.


Allocated VRAM با Required VRAM یکی نیست

بعضی برنامه ها
ممکن است حافظه بیشتری
از مقدار مورد نیاز فوری
Reserve یا Allocate کنند.

بنابراین مشاهده
یک عدد بالای VRAM Usage
به تنهایی
اثبات نمی کند
که Workload با کمبود VRAM مواجه شده است.

رفتار Performance
و Telemetry دقیق تر
باید همراه آن بررسی شوند.

Power Limit چگونه Performance را محدود می کند؟

GPU مدرن
Clock خود را
بر اساس محدودیت های عملیاتی تنظیم می کند.

اگر Workload
به Power Limit برسد،
GPU ممکن است
نتواند Clock بالاتری حفظ کند.


High Workload

      │
      ▼

Higher Power Demand

      │
      ▼

Power Limit Reached

      │
      ▼

Clock Adjustment

Thermal Limitation

اگر Temperature
به محدوده کنترلی سخت افزار برسد،
GPU می تواند
Clock یا Power را تنظیم کند.


High Temperature

      │
      ▼

Thermal Control

      │
      ▼

Lower Effective Clock

      │
      ▼

Lower Performance

بنابراین Cooling
می تواند روی
Performance پایدار
اثر داشته باشد.

Data Transfer Bottleneck

در بعضی Compute Workloadها،
خود GPU بسیار سریع است
اما داده
مرتب باید میان CPU و GPU
جابه جا شود.


CPU Memory

   │
   │ Transfer
   ▼

GPU Memory

   │
   ▼

Compute

   │
   │ Transfer Back
   ▼

CPU Memory

اگر زمان انتقال
بخش بزرگی از Runtime را تشکیل دهد،
افزایش Compute Performance GPU
ممکن است سود محدودی ایجاد کند.

گاهی Bottleneck سخت افزار نیست

Performance می تواند
توسط Software نیز محدود شود.

برای مثال:

  • Shader نامناسب،
  • Data Layout ضعیف،
  • Synchronization زیاد،
  • Draw Callهای غیرضروری،
  • Memory Allocation نامناسب،
  • یا Algorithm نامناسب.

سخت افزار سریع
نمی تواند همیشه
Algorithm ضعیف را نجات دهد.

قانون مهم تشخیص: هر بار یک متغیر را تغییر دهید

اگر هم زمان
Resolution،
Texture Quality،
Shadow Quality،
Ray Tracing
و چند گزینه دیگر را تغییر دهید،
نمی دانید
کدام تغییر
باعث بهبود Performance شده است.


Good Test

Change One Setting
        │
        ▼
Measure
        │
        ▼
Compare


Poor Test

Change Everything
        │
        ▼
FPS Changes
        │
        ▼
Unknown Cause

تنظیمات گرافیکی چگونه به تشخیص کمک می کنند؟

تغییر بخش هایی که ممکن است بیشتر تحت تاثیر باشند
Resolution Pixel Shading،
Render Targets،
Memory Traffic
Texture Quality VRAM Capacity،
Memory Traffic
Shadow Quality Geometry،
Pixel Work،
Memory،
بسته به روش Shadow
Ray Tracing Traversal،
Intersection،
Shading،
Denoising
Geometry / LOD Vertex و Primitive Processing

اثر دقیق هر Setting
به Engine و روش پیاده سازی
وابسته است.

چرا GPU Utilization به تنهایی کافی نیست؟

فرض کنید ابزار Monitoring
عدد 100٪ GPU Usage نشان دهد.

این عدد ممکن است بگوید
GPU درگیر Workload است،
اما لزوما مشخص نمی کند
کدام بخش آن محدود شده است.


100% GPU Usage

Could Mean Pressure On

Compute

Memory

Texture

Ray Tracing

Render Output

or mixed workload

برای تحلیل بهتر،
Metricهای جزئی تر
مورد نیاز هستند.

Profiler چه کاری انجام می دهد؟

Profiler
داده های دقیق تری
از رفتار Workload ارائه می دهد.

بسته به ابزار
می توان مواردی مانند:

  • GPU Time،
  • Shader Cost،
  • Memory Traffic،
  • Cache Behavior،
  • Occupancy،
  • Stall Reason،
  • Draw / Dispatch Cost،
  • و Pipeline Utilization

را بررسی کرد.


Guessing

"I think memory is slow"


Profiling

"Measurements show
memory traffic and stalls
dominate this pass"

Under the Hood — رفع یک Bottleneck معمولا Bottleneck بعدی را آشکار می کند

فرض کنید Memory Bottleneck
را بهینه کنیم.


Before

Memory
██████

Compute
██████████████


After Memory Optimization

Memory
████████████████

Compute
██████████

      ▲
      │

New Bottleneck

این رفتار طبیعی است.

هدف Optimization
حذف همیشگی تمام Bottleneckها نیست؛
بلکه بهبود تعادل سیستم
برای Workload مورد نظر است.

Performance Impact — Optimization باید روی محدودکننده واقعی انجام شود

اگر Workload
Memory-Bound باشد،
افزایش Compute Performance
ممکن است نتیجه کمی داشته باشد.

اگر Workload
CPU-Bound باشد،
کاهش Pixel Shader Cost
ممکن است FPS را تغییر ندهد.

اگر Workload
با کمبود VRAM مواجه باشد،
افزایش Clock GPU
مشکل Capacity را حل نمی کند.

بهینه سازی بخشی که Bottleneck نیست،
اغلب Performance قابل توجهی ایجاد نمی کند.

Engineering Insight — به دنبال علت باشید، نه فقط نشانه

افت FPS
یک نشانه است.

100٪ GPU Usage
یک نشانه است.

VRAM Usage بالا
یک نشانه است.

اما Bottleneck Analysis
باید پاسخ دهد:

کدام Resource
چرا
و در چه بخشی از Workload
سرعت سیستم را محدود کرده است؟

این تفاوت
میان Monitoring ساده
و Performance Analysis واقعی است.

مسیر عملی ساده برای پیدا کردن Bottleneck


Performance Problem

        │
        ▼

Reproduce Consistently

        │
        ▼

Measure Frame / Runtime

        │
        ▼

CPU or GPU Limited?

        │
        ▼

Change One Variable

        │
        ▼

Check Relevant Metrics

        │
        ▼

Profile Suspected Stage

        │
        ▼

Apply Optimization

        │
        ▼

Measure Again

یک مسیر ساده برای Gaming


Low FPS

   │
   ▼

Lower Resolution

   │
   ├── FPS rises a lot
   │       │
   │       ▼
   │   GPU-side work likely important
   │
   └── FPS barely changes
           │
           ▼
       Check CPU / Engine / Limits


Then

Change one graphics setting
at a time

   │
   ▼

Observe Frame Time

   │
   ▼

Identify expensive features

این فقط یک مدل آموزشی است
و باید با Telemetry
و شرایط واقعی سیستم
تکمیل شود.

جدول سریع Bottleneckهای رایج

Bottleneck عامل کلی آزمایش مفهومی
CPU آماده سازی Work یا Game Logic کاهش Resolution تاثیر کمی دارد
Pixel / Shader محاسبات Fragment سنگین Resolution یا Shader Quality پایین تر کمک می کند
Memory Bandwidth Traffic زیاد کاهش Data Movement موثر است
VRAM Capacity Working Set بزرگ کاهش Texture / Resource Quality ممکن است کمک کند
Geometry Primitive Work زیاد کاهش Geometry Detail یا LOD موثر است
Ray Tracing Traversal، Intersection و Ray Shading کاهش RT Quality یا Ray Count موثر است
Power / Thermal محدودیت Clock عملی بررسی Clock، Power و Temperature

Common Mistakes — اشتباهات رایج در Bottleneck Analysis
  • هر Performance پایین را GPU Bottleneck ندانید.
  • 100٪ GPU Usage را تشخیص کامل Bottleneck فرض نکنید.
  • VRAM Usage بالا را به تنهایی کمبود VRAM ندانید.
  • Memory-Bound را همیشه Bandwidth-Bound فرض نکنید.
  • Resolution Test را اثبات قطعی CPU یا GPU Bottleneck ندانید.
  • چند Setting را هم زمان برای تشخیص تغییر ندهید.
  • Average FPS را بدون Frame Time بررسی نکنید.
  • Power و Thermal Limit را نادیده نگیرید.
  • Bottleneck یک Scene را به کل بازی یا برنامه تعمیم ندهید.
  • قبل از Profiling وارد Optimization سنگین نشوید.

سوالات متداول درباره GPU Bottleneck

Bottleneck چیست؟

بخشی از سیستم است
که در Workload فعلی
بیشتر از سایر بخش ها
Performance کل را محدود می کند.

چگونه بفهمیم بازی CPU-Bound است؟

یکی از نشانه های مفهومی
این است که کاهش قابل توجه
Resolution یا GPU Workload
تغییر کمی در FPS ایجاد کند.

اما برای نتیجه مطمئن تر
باید CPU Time،
GPU Time
و Frame Profiling
بررسی شوند.

100٪ GPU Usage یعنی GPU Bottleneck است؟

می تواند نشان دهد
GPU به شدت درگیر Workload است،
اما به تنهایی مشخص نمی کند
کدام بخش داخلی GPU
عامل محدودکننده است.

VRAM پر یعنی حتما کمبود VRAM داریم؟

نه لزوما.

برنامه ممکن است
حافظه را Reserve یا Cache کند.

برای تشخیص کمبود واقعی
باید رفتار Performance،
Memory Pressure
و Telemetry دقیق تر بررسی شود.

Memory-Bound چیست؟

زمانی است
که رفتار Memory System
عامل اصلی محدودکننده Performance باشد.

این محدودیت می تواند
به Bandwidth،
Latency،
Cache
یا Access Pattern مربوط باشد.

چرا Bottleneck بعد از Optimization تغییر می کند؟

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

بهترین ابزار برای پیدا کردن Bottleneck چیست؟

Profiler مناسب Workload
در کنار آزمایش های کنترل شده
و مقایسه Frame Time یا Runtime.

Monitoring ساده مفید است،
اما معمولا برای تحلیل دقیق کافی نیست.

خلاصه فصل

  • Bottleneck بخشی است که Performance کل را محدود می کند.
  • Bottleneck می تواند در طول Workload تغییر کند.
  • CPU-Bound و GPU-Bound دو حالت متفاوت هستند.
  • Compute-Bound یعنی توان محاسباتی عامل محدودکننده است.
  • Memory-Bound می تواند ناشی از Bandwidth، Latency یا Access Pattern باشد.
  • Pixel Shading، Texture، Geometry، ROP و Ray Tracing هر کدام می توانند Bottleneck شوند.
  • کمبود VRAM با کمبود Memory Bandwidth یکسان نیست.
  • Power و Thermal Limit می توانند Clock عملی را محدود کنند.
  • Data Transfer نیز در Compute Workloadها می تواند Bottleneck باشد.
  • کاهش Resolution ابزار مفیدی برای تشخیص اولیه است، اما نتیجه قطعی نیست.
  • برای تشخیص بهتر هر بار فقط یک متغیر را تغییر دهید.
  • Utilization بالا به تنهایی نوع Bottleneck را مشخص نمی کند.
  • Profiler برای تحلیل دقیق از حدس زدن مهم تر است.
  • رفع یک Bottleneck معمولا Bottleneck بعدی را آشکار می کند.

سطح: مقدماتی تا متوسط

پیش نیاز:
GPU Performance Metrics،
GPU Bottleneck Analysis،
Clock،
Voltage،
Cooling

موضوع:
GPU Power & Thermal Behavior

زمان مطالعه:
حدود 8 تا 10 دقیقه


GPU POWER & THERMALS

Power، Temperature و Throttling در GPU چگونه به هم مرتبط هستند؟

GPU فقط بر اساس تعداد Core
یا Clock اسمی کار نمی کند.

توان مصرفی،
ولتاژ،
دمای تراشه،
طراحی خنک کننده
و محدودیت های Firmware
همگی تعیین می کنند
GPU در عمل
چه Clockی را
برای چه مدت حفظ کند.

به همین دلیل
Performance واقعی
می تواند با شرایط حرارتی و توان
تغییر کند.


پاسخ سریع

GPU هنگام کار
توان الکتریکی مصرف می کند
و بخشی از آن
به گرما تبدیل می شود.

اگر Power،
Voltage
یا Temperature
به محدودیت های طراحی نزدیک شوند،
GPU ممکن است
Clock یا Voltage را تنظیم کند
تا در محدوده امن باقی بماند.

این رفتار
به صورت کلی
با مفاهیمی مانند
Power Limit،
Thermal Limit
و Throttling
مرتبط است.

در این فصل چه چیزهایی یاد می گیریم؟

  • Power Consumption چیست.
  • Temperature چرا افزایش پیدا می کند.
  • Clock، Voltage و Power چه ارتباطی دارند.
  • Power Limit چیست.
  • Thermal Limit چیست.
  • Throttling چه معنایی دارد.
  • چرا Cooling روی Performance پایدار اثر دارد.
  • Undervolting چیست.
  • چرا توان مصرفی بیشتر همیشه Performance بیشتری نمی دهد.

Power Consumption چیست؟

Power Consumption
مقدار انرژی مصرفی
در واحد زمان است.

واحد رایج آن:


Watt

W

هرچه GPU
بخش های بیشتری از سخت افزار را
فعال کند
و با Clock و Voltage بالاتری کار کند،
توان مصرفی می تواند افزایش پیدا کند.

گرمای GPU از کجا می آید؟

مدارهای دیجیتال
هنگام تغییر وضعیت
انرژی مصرف می کنند.

بخش مهمی از این انرژی
در نهایت
به گرما تبدیل می شود.


Electrical Power

      │
      ▼

GPU Transistors Switching

      │
      ▼

Work Performed

      +

Heat Generated

هرچه Workload سنگین تر باشد،
ممکن است بخش بزرگ تری از GPU
فعال شود
و گرمای بیشتری تولید شود.

Clock چه ارتباطی با Power دارد؟

Clock بالاتر
یعنی مدار
فرصت های بیشتری
برای انجام کار در واحد زمان دارد.

اما افزایش Clock
معمولا هزینه انرژی دارد.


Higher Clock

      │
      ▼

More Switching Activity

      │
      ▼

Potentially Higher Power

در عمل
رابطه دقیق
به معماری،
Voltage،
Workload
و شرایط تراشه بستگی دارد.

Voltage چرا مهم است؟

برای کار کردن ترانزیستورها
در Frequencyهای مشخص،
تراشه به Voltage مناسب نیاز دارد.

افزایش Voltage
می تواند امکان Clock بالاتر
یا Stability بیشتر
را فراهم کند،
اما معمولا
Power Consumption
و Heat را نیز افزایش می دهد.


Higher Voltage

      │
      ├── Potentially Higher Stable Clock
      │
      └── Higher Power / Heat

یک مدل ذهنی ساده برای Dynamic Power

برای درک مفهومی،
توان دینامیکی مدارهای CMOS
اغلب با رابطه ای از این جنس
توضیح داده می شود:


Dynamic Power

≈

C × V² × f

که در آن:

  • C نماینده ظرفیت موثر Switching است،
  • V Voltage است،
  • f Frequency یا Clock است.

این رابطه
یک مدل ساده آموزشی است
و تمام رفتار توان یک GPU واقعی
را به تنهایی توضیح نمی دهد.

چرا Voltage تاثیر بزرگی روی Power دارد؟

در مدل ساده قبلی،
Voltage به صورت
V²
ظاهر می شود.

یعنی افزایش Voltage
می تواند اثر غیرخطی
روی Dynamic Power داشته باشد.


Small Voltage Increase

        │
        ▼

Potentially Noticeable
Power Increase

به همین دلیل
افزایش Frequency در فرکانس های بالا
گاهی نیازمند هزینه انرژی بیشتری می شود.

Power Limit چیست؟


Power Limit

محدوده ای است
که سیستم مدیریت توان GPU
برای مصرف توان
در شرایط مشخص
در نظر می گیرد.

اگر GPU
به این محدوده برسد،
ممکن است Clock یا Voltage
تنظیم شود
تا مصرف توان کنترل شود.


Workload Demand

      │
      ▼

Power Draw Increases

      │
      ▼

Power Limit Reached

      │
      ▼

Clock / Voltage Adjustment

Thermal Limit چیست؟

GPU باید
در محدوده دمایی مشخصی
کار کند.

اگر Temperature
به محدوده کنترلی طراحی نزدیک شود،
سیستم مدیریت حرارتی
می تواند رفتار GPU را تنظیم کند.


Temperature Rising

      │
      ▼

Thermal Control Region

      │
      ▼

Clock / Voltage / Fan Adjustment

جزئیات دقیق
به GPU،
Firmware
و طراحی Board بستگی دارد.

Throttling چیست؟


Throttling

کاهش یا تنظیم Performance
برای رعایت محدودیت هایی مانند
Power،
Temperature
یا سایر شرایط عملیاتی است.


High Demand

    │
    ▼

Limit Reached

    │
    ▼

Clock Reduced

    │
    ▼

Lower Power / Heat

    │
    ▼

Safe Operation

Throttling همیشه نشانه خرابی نیست

یکی از وظایف
سیستم مدیریت GPU
حفظ تراشه در محدوده امن است.

بنابراین تنظیم Clock
در واکنش به Power
یا Temperature
بخشی طبیعی
از عملکرد GPU مدرن است.

Adaptive Clocking
بخشی از طراحی Performance است،
نه لزوما یک خطا.

Cooling چگونه روی Performance اثر می گذارد؟

خنک کننده
گرما را از GPU
به محیط منتقل می کند.


GPU Die

   │
   ▼

Thermal Interface

   │
   ▼

Heatsink

   │
   ▼

Air / Liquid Cooling

   │
   ▼

Environment

اگر Cooling موثرتر باشد،
GPU ممکن است
برای مدت بیشتری
در شرایط حرارتی مطلوب
کار کند.

چرا بعضی کارت های گرافیک خنک کننده بزرگی دارند؟

GPUهای پرمصرف
باید حجم زیادی از Heat
را دفع کنند.

خنک کننده بزرگ تر
می تواند:

  • سطح تماس و Heat Dissipation بیشتری ایجاد کند،
  • از Fanهای بزرگ تر استفاده کند،
  • در دور پایین تر Airflow بیشتری فراهم کند،
  • و به حفظ Temperature مناسب کمک کند.

اما اندازه خنک کننده
به تنهایی
کیفیت آن را مشخص نمی کند.

Fan Curve چیست؟

Fan Curve
مشخص می کند
سرعت Fan
با تغییر Temperature
چگونه تغییر کند.


Low Temperature
      │
      ▼
Low Fan Speed


Medium Temperature
      │
      ▼
Medium Fan Speed


High Temperature
      │
      ▼
Higher Fan Speed

Fan Curve
میان Noise
و Temperature
Trade-off ایجاد می کند.

Boost Clock چگونه باید فهمیده شود؟

GPUهای مدرن
معمولا Clock ثابت واحدی
در تمام Workloadها ندارند.

Clock عملی
می تواند بر اساس:

  • Power Headroom،
  • Thermal Headroom،
  • Voltage،
  • Workload،
  • و Firmware Policy

تغییر کند.


Available Headroom

      │
      ▼

Boost Higher


Less Headroom

      │
      ▼

Boost Lower

Burst Performance و Sustained Performance یکی نیستند

GPU ممکن است
برای مدت کوتاه
Clock بالایی داشته باشد.

اما در Workload طولانی،
Temperature و Power
به وضعیت پایدارتر می رسند.


Start Workload

Clock
████████████████


After Sustained Load

Clock
██████████████

به همین دلیل
Benchmark کوتاه
و Workload طولانی
می توانند رفتار متفاوتی نشان دهند.

Undervolting چیست؟


Undervolting

کاهش Voltage کاری GPU
برای یک محدوده Frequency مشخص
است.

هدف می تواند
کاهش:

  • Power Consumption،
  • Temperature،
  • Fan Noise،
  • و در برخی شرایط
    بهبود Performance پایدار

باشد.

اما اگر Voltage بیش از حد کاهش پیدا کند،
Stability می تواند آسیب ببیند.

Overclocking چیست؟

Overclocking
تلاش برای اجرای GPU
در Clock بالاتر
از تنظیمات مرجع یا پیش فرض است.


Default Clock

██████████


Overclocked Target

████████████

Clock بالاتر
ممکن است Performance بیشتری ایجاد کند،
اما می تواند
Power،
Temperature
و نیاز به Voltage
را نیز افزایش دهد.

نتیجه واقعی
به Silicon،
Cooling
و Workload بستگی دارد.

Performance per Watt چرا مهم است؟

دو GPU
ممکن است Performance مشابهی داشته باشند
اما توان مصرفی متفاوتی نیاز داشته باشند.


Performance

──────────────

Power

      │
      ▼

Performance per Watt

Efficiency بالاتر
برای:

  • Laptop،
  • Data Center،
  • سیستم های کوچک،
  • و Workloadهای طولانی

اهمیت زیادی دارد.

توان بیشتر همیشه Performance متناسب نمی دهد

در بعضی محدوده های فرکانسی،
افزایش کوچک Performance
ممکن است
نیازمند افزایش قابل توجه Power باشد.


Performance Gain

███████████


Power Increase

████████████████████

این همان جایی است
که مفهوم
Efficiency Curve
اهمیت پیدا می کند.

GPU Temperature همیشه یک عدد واحد نیست

یک تراشه بزرگ
ممکن است در نقاط مختلف
Temperature متفاوتی داشته باشد.

به همین دلیل
برخی Monitoring Toolها
Metricهایی مانند:


GPU Temperature

Hotspot / Junction Temperature

Memory Temperature

را جداگانه گزارش می کنند.

معنای دقیق این Metricها
به Vendor و Sensor Design
وابسته است.

فقط GPU Core گرم نمی شود

Memory Chipها،
VRM
و سایر اجزای Board
نیز Heat تولید می کنند.


Graphics Card

├── GPU Die
├── VRAM
├── VRM
└── Other Components

      │
      ▼

All Need Thermal Management

به همین دلیل
طراحی Cooling
فقط برای GPU Die نیست.

چرا دو Laptop با نام GPU یکسان می توانند Performance متفاوتی داشته باشند؟

در Laptopها،
محدودیت توان
و Cooling
اهمیت بسیار زیادی دارد.

دو سیستم
ممکن است از GPU
با نام مشابه استفاده کنند،
اما:

  • Power Budget متفاوت،
  • Cooling متفاوت،
  • CPU Power Sharing متفاوت،
  • و Firmware متفاوت

داشته باشند.


Same GPU Family Name

       │
       ├── Laptop A
       │   Higher Power / Better Cooling
       │
       └── Laptop B
           Lower Power / Smaller Cooling

       │
       ▼

Different Sustained Performance

Under the Hood — GPU دائما بین چند محدودیت تعادل ایجاد می کند

Clock Control
فقط به Temperature نگاه نمی کند.

GPU مدرن
ممکن است چند محدودیت را
هم زمان در نظر بگیرد:


Performance Target

      │
      ▼

Check

Power
Temperature
Voltage
Current
Workload
Reliability

      │
      ▼

Choose Operating Point

به همین دلیل
Clock عملی GPU
یک عدد پویا است.

Performance Impact — Cooling خوب بیشتر روی Performance پایدار اثر می گذارد

اگر یک GPU
در شروع Workload
Clock بالایی داشته باشد
اما پس از گرم شدن
Clock کاهش پیدا کند،
Performance طولانی مدت
کمتر از Burst اولیه خواهد بود.

Cooling بهتر
می تواند
Thermal Headroom بیشتری فراهم کند
و در بعضی طراحی ها
به حفظ Clock بالاتر کمک کند.

Performance واقعی
فقط Peak Clock نیست؛
Clockی است که سیستم
می تواند در Workload واقعی حفظ کند.

Engineering Insight — بهترین Operating Point همیشه بیشترین Clock نیست

ممکن است GPU
در Frequency کمی پایین تر
بخش بزرگی از Performance
را حفظ کند،
اما Power و Temperature
به شکل محسوسی کمتر شوند.


Maximum Clock

Performance
████████████████

Power
████████████████████


Efficient Operating Point

Performance
███████████████

Power
████████████

به همین دلیل
Efficiency
در بسیاری از طراحی های مدرن
به اندازه Performance خام اهمیت دارد.

مسیر ساده تشخیص محدودیت Power یا Thermal


Performance Lower Than Expected

        │
        ▼

Check Effective Clock

        │
        ▼

Check Temperature

        │
        ▼

Check Power / Limit Indicators

        │
        ▼

Clock Drops Under Load?

     ┌──┴──┐

    Yes    No
     │      │
     ▼      ▼

Investigate   Look for
Thermal /     Other
Power Limit   Bottlenecks

Common Mistakes — اشتباهات رایج درباره Power و Temperature
  • دمای بالاتر را همیشه معادل Performance کمتر ندانید.
  • Throttling را همیشه نشانه خرابی ندانید.
  • Boost Clock تبلیغاتی را Clock ثابت GPU فرض نکنید.
  • Power Limit و Thermal Limit را یکی ندانید.
  • Cooling بزرگ تر را همیشه بهتر فرض نکنید.
  • Voltage بیشتر را بدون هزینه فرض نکنید.
  • Overclocking را همیشه معادل افزایش زیاد Performance ندانید.
  • Undervolting را بدون تست Stability انجام ندهید.
  • Burst Performance را با Sustained Performance یکی ندانید.
  • Temperature یک Sensor را نماینده تمام Board فرض نکنید.

سوالات متداول درباره Power و Temperature GPU

Power Limit چیست؟

محدوده ای برای مصرف توان GPU است
که سیستم مدیریت توان
برای حفظ شرایط عملیاتی مناسب
در نظر می گیرد.

Thermal Throttling چیست؟

زمانی است
که GPU برای کنترل Temperature
Performance یا Clock خود را
تنظیم می کند.

آیا GPU داغ تر همیشه کندتر است؟

نه لزوما.

تا زمانی که GPU
در محدوده عملیاتی خود کار کند،
ممکن است Performance کاملا طبیعی باشد.

مسئله زمانی مهم می شود
که Temperature
روی Clock یا Power Behavior اثر بگذارد.

Undervolting چیست؟

کاهش Voltage کاری GPU
برای کاهش Power و Heat است.

اگر به درستی تنظیم شود
می تواند Efficiency را بهتر کند،
اما Voltage بیش از حد پایین
ممکن است Instability ایجاد کند.

آیا Overclocking همیشه FPS را زیاد می کند؟

نه.

اگر Workload
در بخش دیگری Bottleneck باشد،
افزایش Clock
ممکن است تاثیر کمی داشته باشد.

همچنین Power و Thermal Limits
می توانند سود عملی را محدود کنند.

چرا Clock GPU هنگام بازی تغییر می کند؟

زیرا GPU مدرن
Clock را با توجه به
Workload،
Power،
Temperature،
Voltage
و Firmware Policy
به صورت پویا تنظیم می کند.

چرا دو کارت با یک GPU Performance متفاوت دارند؟

Power Limit،
Cooling،
Board Design،
BIOS،
Memory Configuration
و Clock Behavior
می توانند متفاوت باشند.

خلاصه فصل

  • GPU برای انجام کار توان الکتریکی مصرف می کند و گرما تولید می کند.
  • Clock بالاتر معمولا می تواند Power بیشتری نیاز داشته باشد.
  • Voltage روی Stability، Power و Heat اثر دارد.
  • مدل ساده Dynamic Power با C × V² × f توضیح داده می شود.
  • Power Limit مصرف توان GPU را کنترل می کند.
  • Thermal Limit برای کنترل شرایط حرارتی استفاده می شود.
  • Throttling تنظیم Performance برای رعایت محدودیت های عملیاتی است.
  • Cooling می تواند روی Clock پایدار اثر بگذارد.
  • Boost Clock یک مقدار کاملا ثابت در تمام شرایط نیست.
  • Burst Performance و Sustained Performance متفاوت هستند.
  • Undervolting می تواند Efficiency را بهتر کند اما نیازمند Stability Test است.
  • Overclocking می تواند Performance را افزایش دهد اما هزینه Power و Heat دارد.
  • توان مصرفی بیشتر همیشه Performance متناسب ایجاد نمی کند.
  • Temperatureهای Core، Hotspot و Memory می توانند متفاوت باشند.
  • در Laptopها Power Budget و Cooling می توانند اختلاف Performance زیادی ایجاد کنند.

سطح: مقدماتی تا متوسط

پیش نیاز:
Power،
Temperature،
Throttling،
GPU Board Design

موضوع:
GPU Form Factors & Cooling Designs

زمان مطالعه:
حدود 8 تا 10 دقیقه


GPU PHYSICAL DESIGN

GPU Form Factor و Cooling Design چه تاثیری دارند؟

دو کارت گرافیک
ممکن است از GPU مشابهی استفاده کنند،
اما از نظر اندازه،
Power Limit،
Cooling،
Noise،
Clock پایدار
و حتی رفتار Performance
متفاوت باشند.

طراحی فیزیکی کارت گرافیک
فقط مسئله ظاهر نیست.

PCB،
VRM،
Heatsink،
Fanها،
Airflow
و فضای داخل Case
همگی در عملکرد واقعی
کارت نقش دارند.


پاسخ سریع

Form Factor
به شکل و ابعاد فیزیکی کارت گرافیک
و نحوه نصب آن در سیستم اشاره دارد.

Cooling Design
روش انتقال گرما
از GPU،
VRAM
و سایر اجزای کارت
به محیط است.

کارت بزرگ تر
الزاما سریع تر نیست،
اما فضای بیشتر
می تواند امکان Heatsink بزرگ تر،
Fanهای بزرگ تر
و توان دفع حرارت بیشتر
را فراهم کند.

در این فصل چه چیزهایی یاد می گیریم؟

  • Form Factor کارت گرافیک چیست.
  • Slot Width چه معنایی دارد.
  • Length و Height چرا مهم هستند.
  • Open-Air Cooler چیست.
  • Blower Cooler چه تفاوتی دارد.
  • Passive Cooling چیست.
  • Liquid Cooling چگونه کار می کند.
  • PCB و Cooler چه ارتباطی دارند.
  • Case Airflow چرا اهمیت دارد.
  • چرا دو مدل از یک GPU می توانند دما و Noise متفاوتی داشته باشند.

Form Factor چیست؟


GPU Form Factor

مجموعه ویژگی های فیزیکی کارت گرافیک
مانند:

  • طول،
  • ارتفاع،
  • ضخامت،
  • تعداد Slot اشغال شده،
  • و نحوه قرارگیری Cooler

است.

Form Factor
مشخص می کند
آیا کارت
از نظر فیزیکی
در Case و سیستم مورد نظر
جا می شود یا نه.

طول کارت گرافیک چرا مهم است؟

بعضی GPUها
از Cooler و PCB طولانی استفاده می کنند.


Short Card

┌───────────────┐
│ GPU           │
└───────────────┘


Long Card

┌───────────────────────────────┐
│ GPU       Large Cooler        │
└───────────────────────────────┘

اگر طول کارت
بیشتر از فضای آزاد Case باشد،
ممکن است با:

  • Front Fan،
  • Radiator،
  • Drive Cage،
  • یا سایر اجزای داخلی

تداخل ایجاد شود.

ارتفاع کارت

بعضی کارت ها
فقط به اندازه براکت استاندارد PCIe
ارتفاع دارند.

مدل های دیگر
ممکن است PCB
یا Cooler بلندتری داشته باشند.


Standard Height

┌───────────────┐


Taller Card

┌───────────────┐
│               │
│               │
└───────────────┘

ارتفاع بیشتر
می تواند
روی Clearance
با Side Panel
یا کابل Power
اثر بگذارد.

Slot Width چیست؟

کارت گرافیک
ممکن است بیش از یک Expansion Slot
فضا اشغال کند.


1-Slot

█


2-Slot

██


2.5-Slot

██▌


3-Slot

███


4-Slot

████

عدد Slot
بیشتر درباره فضای فیزیکی
Cooler و Card
است،
نه تعداد Connectorهای PCIe.

کارت ضخیم تر چه مزیتی دارد؟

Cooler ضخیم تر
می تواند فضای بیشتری
برای:

  • Fin Stack بزرگ تر،
  • Heatpipeهای بیشتر،
  • Vapor Chamber،
  • و Fanهای بزرگ تر

فراهم کند.

این موضوع
می تواند توان دفع Heat را افزایش دهد.

اما کارت ضخیم تر
ممکن است
Slotهای مجاور را مسدود کند.

وظیفه اصلی Cooler چیست؟

Cooler باید Heat
را از اجزای کارت
به محیط انتقال دهد.


GPU Die

   │
   ▼

Thermal Interface

   │
   ▼

Cold Plate /
Vapor Chamber

   │
   ▼

Heatpipes

   │
   ▼

Heatsink Fins

   │
   ▼

Airflow

   │
   ▼

Environment

هر مرحله
اگر عملکرد مناسبی نداشته باشد،
می تواند Thermal Resistance
کل سیستم را افزایش دهد.

Heatsink چه کاری انجام می دهد؟

Heatsink
سطح بزرگی
برای انتقال Heat
به Air فراهم می کند.


Small Contact Area

      │
      ▼

Heatpipes / Base

      │
      ▼

Large Fin Area

|||||||||||||||||||||

      │
      ▼

Airflow

هرچه Heat
روی سطح بزرگ تری توزیع شود،
انتقال آن به Air
ساده تر می شود.

Heatpipe چیست؟

Heatpipe
برای انتقال موثر Heat
از Base Cooler
به بخش های مختلف Heatsink
استفاده می شود.


GPU

 │
 ▼

Base

 ═════════ Heatpipe ═════════

          │
          ▼

       Fin Stack

Heatpipe
فقط یک میله فلزی ساده نیست
و برای انتقال Heat
از سازوکار داخلی خاصی استفاده می کند.

Vapor Chamber چیست؟

Vapor Chamber
را می توان
نوعی Heat Spreader
با سازوکار انتقال حرارت
مبتنی بر تغییر فاز
در نظر گرفت.


GPU Hotspot

     │
     ▼

Vapor Chamber

┌──────────────────────┐
│ Spread Heat Wider    │
└──────────────────────┘

     │
     ▼

Heatsink

هدف آن
پخش کردن Heat
روی سطح بزرگ تر
و کاهش تمرکز گرما
در نقطه کوچک است.

Open-Air Cooler چیست؟

در طراحی Open-Air،
Fanها هوا را
از میان Heatsink عبور می دهند
و Heat عمدتا
داخل فضای Case منتشر می شود.


Fans

↓↓↓↓↓↓

██████████████
Heatsink
██████████████

↙   ↓   ↘

Warm Air
into Case

این طراحی
در کارت های گرافیک مصرف کننده
بسیار رایج است.

مزایای Open-Air

  • امکان استفاده از Heatsink بزرگ،
  • Fanهای متعدد،
  • Noise کمتر در بسیاری از طراحی ها،
  • و Cooling مناسب در Case دارای Airflow خوب.

اما Heat
داخل Case باقی می ماند
و باید توسط Case Fanها
خارج شود.

Blower Cooler چیست؟

در طراحی Blower،
یک Fan
هوا را از داخل Cooler عبور می دهد
و بخش بزرگی از هوای گرم
از پشت کارت
به بیرون Case هدایت می شود.


Air In

   ▼

[ Blower Fan ]

      │
      ▼

Heatsink

════════════════════►

Hot Air Out
Rear Exhaust

Blower چه زمانی مفید است؟

Blower Design
می تواند در سیستم هایی
که Airflow داخلی محدود است
یا چند کارت کنار هم قرار دارند
مفید باشد.

مزیت مهم:

بخش زیادی از Heat
مستقیما از Case خارج می شود.

اما این طراحی
اغلب برای جابه جایی Air
با محدودیت فضای بیشتر
به Fan Speed بالاتری نیاز دارد
و می تواند Noise بیشتری تولید کند.

Open-Air و Blower

ویژگی Open-Air Blower
مسیر Heat بیشتر داخل Case بخش زیادی به Rear Exhaust
Heatsink Size معمولا امکان طراحی بزرگ تر اغلب محدودتر
Noise در بسیاری از طراحی ها کمتر می تواند بیشتر باشد
نیاز به Case Airflow زیادتر در بعضی سیستم ها کمتر

نتیجه واقعی
به طراحی مشخص کارت
و سیستم بستگی دارد.

Passive Cooling چیست؟

در Passive Cooling
خود کارت
Fan فعال ندارد.


GPU

 │
 ▼

Large Heatsink

████████████████

 │
 ▼

Natural / Case Airflow

این روش
برای GPUهای کم مصرف تر
یا کاربردهای خاص
مناسب تر است.

مزیت اصلی:

  • Noise بسیار کم یا صفر از خود کارت.

اما ظرفیت دفع Heat
محدودتر است.

Liquid Cooling چیست؟

در Liquid Cooling
Heat
از GPU به یک Liquid Loop
منتقل می شود
و سپس در Radiator
به Air داده می شود.


GPU Block

   │
   ▼

Coolant

   │
   ▼

Pump

   │
   ▼

Radiator

   │
   ▼

Fans

   │
   ▼

Air

این روش
می تواند ظرفیت دفع Heat بالایی
فراهم کند،
اما Complexity،
Cost
و فضای بیشتری نیاز دارد.

AIO GPU Cooling

برخی کارت ها
از سیستم Liquid Cooling بسته
یا AIO استفاده می کنند.


GPU Card

   │
   ▼

Pump / Cold Plate

   │
   ▼

Tubes

   │
   ▼

Radiator

   │
   ▼

Fans

این طراحی
نسبت به Custom Loop
نصب ساده تری دارد،
اما همچنان
به فضای Radiator نیاز دارد.

Custom Liquid Loop

در Custom Loop،
کاربر می تواند
اجزای Cooling را
به صورت جداگانه انتخاب کند.

برای مثال:

  • GPU Water Block،
  • CPU Block،
  • Pump،
  • Reservoir،
  • Radiator،
  • و Tubing.

این روش
انعطاف و ظرفیت Cooling بالایی دارد
اما هزینه،
پیچیدگی
و Maintenance بیشتری نیز دارد.

PCB چه نقشی دارد؟


Printed Circuit Board — PCB

بردی است
که GPU،
VRAM،
VRM
و سایر اجزای الکترونیکی
روی آن قرار می گیرند.


Graphics Card PCB

┌─────────────────────────────┐
│ GPU                         │
│ VRAM  VRAM  VRAM            │
│                             │
│ VRM                         │
│ Power Delivery              │
└─────────────────────────────┘

Cooler
روی این مجموعه
قرار می گیرد
و باید چند بخش مختلف
را خنک کند.

VRM چیست؟


Voltage Regulator Module — VRM

بخشی از Power Delivery System است
که Voltage مناسب
برای GPU
و سایر بخش های کارت
را فراهم می کند.

VRM نیز هنگام کار
Heat تولید می کند
و در کارت های پرقدرت
نیازمند Cooling مناسب است.

VRAM نیز باید خنک شود

Memory Chipها
در Workloadهای سنگین
می توانند Heat قابل توجهی تولید کنند.


GPU Cooler

   │
   ├── GPU Die Cooling
   ├── VRAM Cooling
   └── VRM Cooling

بعضی Coolerها
از Thermal Pad
برای انتقال Heat
از VRAM و VRM
به Heatsink استفاده می کنند.

Case Airflow چرا مهم است؟

حتی بهترین GPU Cooler
اگر هوای گرم
داخل Case محبوس شود،
نمی تواند به شکل ایده آل کار کند.


Cool Air In

Front / Bottom
      │
      ▼

GPU + CPU

      │
      ▼

Warm Air

      │
      ▼

Rear / Top Exhaust

هدف کلی
ایجاد مسیر مناسب
برای ورود هوای خنک
و خروج هوای گرم است.

Hot Air Recirculation چیست؟

اگر هوای گرم خروجی GPU
دوباره توسط Fanهای آن
مکیده شود،
دمای ورودی Cooler
بالاتر می رود.


GPU Exhaust

     ↘

     Warm Air

        ↘

      GPU Fan

        │
        ▼

Warmer Intake

Airflow نامناسب Case
می تواند این مشکل
را تشدید کند.

سه Fan همیشه بهتر از دو Fan نیست

Fan Count
به تنهایی
کیفیت Cooler را تعیین نمی کند.

عوامل مهم تر شامل:

  • اندازه Fan،
  • Heatsink Area،
  • Fin Density،
  • Heatpipe Design،
  • Fan Curve،
  • و Airflow واقعی

هستند.

Fan Count یک مشخصه ظاهری است؛
Cooling Performance حاصل کل طراحی است.

Zero RPM Mode چیست؟

برخی کارت ها
در Load پایین
Fanهای خود را متوقف می کنند.


Low Load

Temperature Low

      │
      ▼

Fans Off


Higher Load

Temperature Rises

      │
      ▼

Fans Start

هدف
کاهش Noise
در حالت Idle
یا Load سبک است.

Cooling Performance فقط Temperature نیست

دو Cooler
ممکن است GPU را
در Temperature مشابه نگه دارند،
اما Noise متفاوتی داشته باشند.


Cooler A

75°C
High Fan Speed
High Noise


Cooler B

75°C
Lower Fan Speed
Lower Noise

برای بررسی کیفیت Cooling
بهتر است
Temperature،
Noise
و Sustained Clock
با هم دیده شوند.

Coil Whine چیست؟

Coil Whine
صدای الکتریکی
با فرکانس بالا
است که می تواند
از برخی اجزای Power Delivery
ایجاد شود.

این صدا
با Fan Noise متفاوت است.


Fan Noise

Air Movement


Coil Whine

Electrical Component Vibration

شدت آن
می تواند
با Load،
Power
و حتی نمونه کارت
تفاوت داشته باشد.

GPU Sag چیست؟

کارت های بزرگ و سنگین
ممکن است
در انتهای خود
کمی به سمت پایین خم شوند.


PCIe Slot

───────────────┐
               │
GPU Card ──────┘
               
                
                 ▼

               Sag

برای کارت های بسیار سنگین
ممکن است
از Support Bracket
یا Holder استفاده شود.

Vertical GPU Mount

در بعضی Caseها
می توان GPU را
به صورت عمودی نصب کرد.

این روش
معمولا از PCIe Riser Cable
استفاده می کند.


Motherboard

   │
   ▼

PCIe Riser Cable

   │
   ▼

Vertical GPU

اگر GPU
بیش از حد
به Side Panel نزدیک شود،
Airflow آن
ممکن است محدود شود.

Small Form Factor GPU

در سیستم های کوچک،
فضای بسیار محدودی
برای GPU وجود دارد.

در این سیستم ها
باید موارد زیر
با دقت بیشتری بررسی شوند:

  • Card Length،
  • Slot Thickness،
  • Power Connector Clearance،
  • Radiator Placement،
  • و Airflow.

کارت کوچک تر
ممکن است
Cooler کوچک تری نیز داشته باشد
و در نتیجه
برای کنترل Heat
به Fan Speed بالاتری نیاز پیدا کند.

Low-Profile GPU چیست؟

Low-Profile Card
برای Caseهای کم ارتفاع
طراحی می شود.


Standard Card

┌───────────────────┐
│                   │
│                   │
└───────────────────┘


Low Profile

┌───────────────────┐
└───────────────────┘

این کارت ها
معمولا محدودیت بیشتری
در اندازه Cooler
و Power Budget دارند.

Reference Design و Custom Design

یک GPU
می تواند روی چند کارت گرافیک مختلف
استفاده شود.

شرکت های سازنده Board
ممکن است طراحی های مختلفی
برای:

  • PCB،
  • Power Delivery،
  • Cooler،
  • BIOS،
  • Clock،
  • و Fan Profile

ارائه کنند.


Same GPU Chip

      │
      ├── Card A
      │   Large Cooler
      │
      ├── Card B
      │   Compact Cooler
      │
      └── Card C
          Higher Power Design

چرا دو کارت با GPU یکسان رفتار متفاوت دارند؟

حتی اگر GPU Chip یکسان باشد،
عوامل زیر می توانند متفاوت باشند:


Same GPU

   │
   ├── Different Cooler
   ├── Different Power Limit
   ├── Different PCB
   ├── Different Fan Curve
   ├── Different Factory Clock
   └── Different Case Environment

در نتیجه
Temperature،
Noise
و Sustained Clock
می توانند متفاوت باشند.

Under the Hood — Cooler فقط GPU Die را خنک نمی کند

در یک کارت گرافیک واقعی
چند منبع Heat مهم وجود دارد.


Heat Sources

├── GPU Die
├── VRAM
├── VRM
└── Power Components

       │
       ▼

Cooling System

اگر GPU Core خنک باشد
اما VRAM یا VRM
Cooling ضعیفی داشته باشند،
طراحی حرارتی
همچنان ایده آل نیست.

Performance Impact — Cooling خوب بیشتر روی Sustained Behavior اثر دارد

اگر دو کارت
از GPU یکسان استفاده کنند،
تفاوت Cooler
معمولا باعث
دو برابر شدن Performance نمی شود.

اما Cooling بهتر
می تواند در Load طولانی:

  • Clock پایدارتر،
  • Temperature پایین تر،
  • Fan Noise کمتر،
  • و Thermal Headroom بیشتر

ایجاد کند.

Cooling Design
بیشتر کیفیت حفظ Performance را تعیین می کند
تا قدرت پایه معماری GPU را.

Engineering Insight — Cooler را همراه با Case ببینید

یک کارت Open-Air عالی
در Case بدون Airflow مناسب
ممکن است
نتیجه ضعیفی داشته باشد.

در مقابل،
یک سیستم Airflow مناسب
می تواند
دمای هوای ورودی GPU
را کاهش دهد.


GPU Cooler

      +

Case Airflow

      +

Ambient Temperature

      │
      ▼

Real Cooling Performance

Cooling
یک ویژگی سیستم است،
نه فقط کارت گرافیک.

قبل از خرید یک کارت گرافیک چه ابعادی را بررسی کنیم؟

  • Maximum GPU Length قابل پشتیبانی Case.
  • Maximum Card Thickness و تعداد Slotها.
  • Card Height.
  • فضای مورد نیاز Power Connector.
  • وجود Radiator یا Fan در مسیر کارت.
  • Airflow ورودی و خروجی Case.
  • فضای Slotهای PCIe مجاور.
  • وزن کارت و نیاز احتمالی به Support Bracket.
  • توان PSU و Connectorهای مورد نیاز.
  • نوع Cooler و Noise مورد انتظار.

Common Mistakes — اشتباهات رایج درباره GPU Form Factor و Cooling
  • کارت بزرگ تر را همیشه سریع تر ندانید.
  • تعداد Fan بیشتر را همیشه Cooling بهتر ندانید.
  • Slot Width را با تعداد Laneهای PCIe یکی ندانید.
  • Open-Air Cooler را بدون توجه به Case Airflow انتخاب نکنید.
  • Blower را همیشه طراحی ضعیف فرض نکنید؛ کاربرد آن متفاوت است.
  • Temperature پایین تر را بدون بررسی Noise مقایسه نکنید.
  • Cooling را فقط مربوط به GPU Core ندانید.
  • طول کارت را تنها Dimension مهم فرض نکنید.
  • Vertical Mount را بدون بررسی فاصله با Side Panel انجام ندهید.
  • Reference و Custom Card را فقط بر اساس ظاهر مقایسه نکنید.

مدل ذهنی ساده


GPU Chip

   │
   ▼

PCB + Power Delivery

   │
   ▼

Cooling System

   │
   ▼

Card Form Factor

   │
   ▼

Installed in Case

   │
   ▼

Case Airflow

   │
   ▼

Temperature / Noise

   │
   ▼

Sustained Clock

   │
   ▼

Real-World Behavior

سوالات متداول درباره GPU Form Factor و Cooling

GPU Form Factor چیست؟

ابعاد و طراحی فیزیکی کارت گرافیک
مانند طول،
ارتفاع،
ضخامت
و تعداد Slotهای اشغال شده است.

آیا کارت سه Fan همیشه از کارت دو Fan بهتر است؟

خیر.

کیفیت Cooling
به کل طراحی Heatsink،
Fan،
Heatpipe،
Airflow
و Fan Curve بستگی دارد.

Open-Air Cooler چیست؟

Coolerی است
که هوای گرم را عمدتا
داخل Case منتشر می کند
و برای عملکرد مناسب
به Case Airflow خوب نیاز دارد.

Blower Cooler چیست؟

طراحی ای است
که هوا را از داخل Cooler عبور می دهد
و بخش بزرگی از آن را
از پشت کارت خارج می کند.

آیا Water Cooling همیشه Performance بیشتری می دهد؟

نه لزوما.

Water Cooling
می تواند Temperature و Noise را کاهش دهد
و Headroom حرارتی بیشتری ایجاد کند،
اما Performance نهایی
همچنان به Power Limit،
Architecture
و Bottleneck Workload بستگی دارد.

چرا دو کارت با یک GPU دمای متفاوت دارند؟

Cooler،
Fan Curve،
Power Limit،
PCB،
Case Airflow
و Ambient Temperature
می توانند متفاوت باشند.

آیا GPU ضخیم تر بهتر است؟

ضخامت بیشتر
می تواند امکان Heatsink بزرگ تر را فراهم کند،
اما کیفیت طراحی
مهم تر از ضخامت به تنهایی است.

قبل از خرید GPU چه اندازه هایی باید بررسی شوند؟

طول،
ارتفاع،
ضخامت،
تعداد Slot،
فضای Connector برق
و Clearance با Fan،
Radiator
و Side Panel.

خلاصه فصل

  • Form Factor ابعاد و طراحی فیزیکی کارت گرافیک را توصیف می کند.
  • طول، ارتفاع و Slot Width باید با Case سازگار باشند.
  • Cooler گرما را از GPU، VRAM و VRM به محیط منتقل می کند.
  • Heatsink سطح انتقال Heat را افزایش می دهد.
  • Heatpipe و Vapor Chamber به انتقال و پخش Heat کمک می کنند.
  • Open-Air Cooler هوای گرم را عمدتا داخل Case منتشر می کند.
  • Blower بخش زیادی از هوای گرم را از Rear Exhaust خارج می کند.
  • Passive Cooling بدون Fan فعال روی خود کارت کار می کند.
  • Liquid Cooling Heat را به Radiator منتقل می کند.
  • PCB میزبان GPU، VRAM، VRM و Power Delivery است.
  • Case Airflow بخشی مهم از Cooling واقعی کارت است.
  • Fan Count به تنهایی معیار کیفیت Cooler نیست.
  • Temperature باید همراه Noise و Sustained Clock بررسی شود.
  • دو کارت با GPU یکسان می توانند Cooling و Power Design متفاوت داشته باشند.
  • Cooling بهتر بیشتر روی رفتار پایدار GPU اثر می گذارد تا قدرت پایه معماری.

سطح: مقدماتی تا متوسط

پیش نیاز:
GPU Form Factor،
VRAM،
CPU-GPU Data Transfer،
Motherboard Basics

موضوع:
GPU System Interface

زمان مطالعه:
حدود 8 تا 10 دقیقه


GPU SYSTEM INTERFACE

PCIe چیست و GPU چگونه به سیستم متصل می شود؟

کارت گرافیک
برای ارتباط با CPU،
حافظه سیستم
و سایر بخش های کامپیوتر
به یک مسیر ارتباطی نیاز دارد.

در کامپیوترهای شخصی،
این مسیر معمولا
PCI Express
یا PCIe است.

PCIe
داده ها،
Commandها
و Transferهای لازم
را میان GPU و سیستم
جابه جا می کند.


پاسخ سریع

PCIe
یک رابط پرسرعت
برای اتصال دستگاه هایی مانند GPU
به سیستم است.

GPU از طریق PCIe
با CPU و حافظه سیستم
تبادل داده می کند.

سرعت این ارتباط
به Generation
و تعداد Laneها
وابسته است،
اما در بسیاری از Workloadهای Gaming،
تمام Performance GPU
مستقیما توسط PCIe Bandwidth محدود نمی شود.

در این فصل چه چیزهایی یاد می گیریم؟

  • PCIe چیست.
  • Lane چیست.
  • x16، x8 و x4 چه معنایی دارند.
  • PCIe Generation چه چیزی را تغییر می دهد.
  • GPU چه نوع داده هایی را از PCIe عبور می دهد.
  • چرا VRAM باعث می شود GPU دائما به RAM سیستم وابسته نباشد.
  • چه زمانی PCIe می تواند Bottleneck شود.
  • چرا اسلات فیزیکی و تعداد Lane واقعی همیشه یکی نیستند.

PCI Express چیست؟


PCI Express — PCIe

یک رابط ارتباطی پرسرعت
برای اتصال Deviceها
به سیستم است.


CPU / Chipset

      │
      ▼

PCI Express

      │
      ▼

GPU

PCIe فقط برای GPU نیست
و دستگاه های دیگری نیز
می توانند از آن استفاده کنند.

PCIe Lane چیست؟

PCIe
از Laneهای ارتباطی
برای انتقال داده استفاده می کند.


x1

[ Lane ]


x4

[ Lane ][ Lane ][ Lane ][ Lane ]


x8

[ Lane ][ Lane ][ Lane ][ Lane ]
[ Lane ][ Lane ][ Lane ][ Lane ]


x16

16 Lanes

هرچه تعداد Lane بیشتر باشد،
ظرفیت انتقال داده
بیشتر می شود.

PCIe x16 یعنی چه؟

x16
یعنی Link
می تواند از 16 Lane
برای ارتباط استفاده کند.

بسیاری از کارت های گرافیک Desktop
از Connector فیزیکی x16
استفاده می کنند.


GPU

════════════════════════

PCIe x16 Physical Connector

اما Connector فیزیکی x16
همیشه به معنی
16 Lane الکتریکی فعال نیست.

Physical x16 و Electrical x16 یکی نیستند

یک Slot
ممکن است از نظر شکل
x16 باشد،
اما از نظر اتصال واقعی
فقط x8 یا x4 Lane داشته باشد.


Physical Slot

x16 Size


Electrical Connection

x4

or

x8

or

x16

این موضوع
به طراحی Motherboard
و تقسیم Laneها
بستگی دارد.

PCIe Generation چیست؟

نسخه های جدیدتر PCIe
نرخ انتقال داده بیشتری
برای هر Lane فراهم می کنند.


PCIe Gen 3

Lower Per-Lane Bandwidth


PCIe Gen 4

Higher Per-Lane Bandwidth


PCIe Gen 5

Higher Again

یعنی یک Link x8
در Generation جدیدتر
می تواند Bandwidth قابل توجهی داشته باشد.

آیا نسل های مختلف PCIe با هم سازگار هستند؟

PCIe
به طور کلی
با نسل های قبلی و بعدی
سازگاری خوبی دارد.

اگر GPU جدیدتر
در Slot قدیمی تر نصب شود،
معمولا Link
با Generation مشترک قابل پشتیبانی
کار می کند.


Newer GPU

      │
      ▼

Older PCIe Slot

      │
      ▼

Negotiated Common Link Speed

Performance واقعی
بسته به Workload
ممکن است کمی یا بیشتر
تحت تاثیر قرار بگیرد.

چه چیزهایی از PCIe عبور می کنند؟

بسته به Workload،
PCIe می تواند
داده های مختلفی حمل کند.

  • Commandها،
  • Buffer Data،
  • Texture Data،
  • Compute Inputs،
  • Readback Results،
  • و سایر Transferها.


System Memory

     │
     ▼

PCIe

     │
     ▼

GPU VRAM

چرا GPU داده را در VRAM نگه می دارد؟

اگر GPU
برای هر Texture،
Buffer
یا Intermediate Result
مجبور بود
دائما از RAM سیستم
از طریق PCIe داده بگیرد،
Performance بسیار محدودتر می شد.


Preferred

GPU
 │
 ▼
Local VRAM
 │
 ▼
Fast Repeated Access


Less Ideal for Constant Access

GPU
 │
 ▼
PCIe
 │
 ▼
System RAM

VRAM
حافظه محلی GPU است
و برای Workloadهای پرتکرار
اهمیت زیادی دارد.

PCIe Bandwidth و VRAM Bandwidth یکی نیستند

این دو
مسیرهای متفاوتی را توصیف می کنند.

مسیر کاربرد
PCIe ارتباط GPU با سیستم
VRAM Interface ارتباط GPU با حافظه محلی خود

در بسیاری از GPUها،
VRAM Bandwidth
به مراتب برای دسترسی داخلی
اهمیت بیشتری دارد.

آیا PCIe همیشه Gaming Performance را محدود می کند؟

نه.

در بسیاری از بازی ها،
بخش بزرگی از داده های مورد نیاز
داخل VRAM قرار دارد
و GPU
برای هر Operation
به RAM سیستم مراجعه نمی کند.

به همین دلیل
کاهش PCIe Bandwidth
در برخی سناریوها
اثر محدودی دارد.

اما نتیجه
به Game،
VRAM Capacity،
Asset Streaming
و معماری GPU بستگی دارد.

چه زمانی PCIe مهم تر می شود؟

PCIe
در شرایطی می تواند
اهمیت بیشتری پیدا کند که:

  • داده مرتب بین CPU و GPU جابه جا شود،
  • VRAM کافی نباشد،
  • Workload نیاز به Readback مکرر داشته باشد،
  • Data Streaming سنگین باشد،
  • یا GPU از Lane Count محدودتری استفاده کند.

PCIe در Compute Workloadها

در Compute
گاهی زمان انتقال داده
به اندازه زمان Compute
اهمیت پیدا می کند.


Host Memory

   │
   │ Transfer
   ▼

GPU Memory

   │
   ▼

Compute

   │
   │ Transfer Back
   ▼

Host Memory

اگر Compute بسیار کوتاه باشد
اما Data Transfer بزرگ باشد،
PCIe می تواند
بخش مهم Runtime شود.

چرا Batching می تواند مفید باشد؟

به جای انتقال
تعداد زیادی داده کوچک
در دفعات متعدد،
گاهی می توان
Transferها را بزرگ تر و کمتر کرد.


Many Small Transfers

A
B
C
D
E


Batched Transfer

ABCDE

این کار
می تواند Overhead
تعداد Transferهای کوچک
را کاهش دهد.

PCIe فقط Bandwidth نیست

مانند سایر رابط ها،
PCIe هم
Bandwidth
و هم Latency دارد.

برای Transferهای بسیار کوچک
ممکن است Latency
اهمیت بیشتری پیدا کند.

برای Transferهای بزرگ
Bandwidth
می تواند مهم تر شود.


Small Transfers

Latency Matters More


Large Transfers

Bandwidth Matters More

Resizable BAR چیست؟

Resizable BAR
قابلیتی در PCIe
و Platform است
که می تواند به CPU اجازه دهد
بخش بزرگ تری
از فضای VRAM GPU
را در یک Window قابل دسترسی
Map کند.


Traditional Smaller Mapping Window

CPU
 │
 ▼
Small VRAM Window


Resizable BAR

CPU
 │
 ▼
Larger Accessible VRAM Region

این قابلیت
می تواند در بعضی Workloadها
رفتار Data Access را بهتر کند،
اما Performance Gain
در همه برنامه ها یکسان نیست.

چند GPU و PCIe Lane Sharing

در سیستم های چند GPU
یا سیستم هایی با چند Device پرسرعت،
Laneهای PCIe
ممکن است میان دستگاه ها تقسیم شوند.


CPU PCIe Lanes

       │
       ├── GPU 1
       ├── GPU 2
       └── Other Devices

پیکربندی واقعی
به CPU،
Motherboard
و Platform بستگی دارد.

همه Slotها مستقیما به CPU وصل نیستند

در بعضی Motherboardها
برخی Slotها
از Laneهای مستقیم CPU
استفاده می کنند
و برخی دیگر
از Chipset عبور می کنند.


Direct Path

CPU
 │
 ▼
GPU


Chipset Path

CPU
 │
 ▼
Chipset
 │
 ▼
Device

برای GPU اصلی
معمولا باید
Slot توصیه شده توسط سازنده Motherboard
استفاده شود.

چرا معمولا GPU را در اولین Slot x16 نصب می کنیم؟

در بسیاری از Motherboardها،
اولین Slot اصلی
بیشترین Lane مستقیم
یا بهترین مسیر اتصال
را برای GPU دارد.

به همین دلیل
Manual Motherboard
معمولا محل پیشنهادی GPU
را مشخص می کند.

ظاهر مشابه Slotها
به معنی اتصال داخلی یکسان نیست.

Under the Hood — PCIe مسیر اصلی اجرای Shader نیست

وقتی Shader
روی داده ای که از قبل در VRAM قرار دارد
کار می کند،
دسترسی اصلی آن
از مسیر Memory System داخلی GPU است.


Shader Execution

      │
      ▼

GPU Cache / VRAM

      │
      ▼

Local Memory Path


PCIe

used mainly for
system-to-GPU communication
and transfers

به همین دلیل
PCIe Bandwidth
را نباید با
Memory Bandwidth داخلی GPU
اشتباه گرفت.

Performance Impact — PCIe چه زمانی Bottleneck واقعی می شود؟

PCIe
زمانی می تواند
Performance را بیشتر محدود کند
که Data Transfer
بخش بزرگی از Workload باشد.

نمونه ها:

  • Compute با Transferهای مکرر،
  • کمبود VRAM،
  • Asset Streaming سنگین،
  • Readbackهای زیاد،
  • یا Link با Lane Count بسیار محدود.

در Workloadهای دیگر،
Compute،
Memory داخلی GPU
یا Graphics Pipeline
ممکن است محدودکننده اصلی باشند.

Engineering Insight — داده ای که یک بار منتقل و بارها استفاده شود، ارزشمند است

اگر Texture یا Buffer
یک بار به VRAM منتقل شود
و سپس بارها توسط GPU استفاده شود،
هزینه PCIe
روی تعداد زیادی Operation
پخش می شود.


Upload Once

      │
      ▼

Store in VRAM

      │
      ▼

Use
Use
Use
Use
Use

اما اگر داده
برای هر Operation
دوباره منتقل شود،
هزینه ارتباط
می تواند بسیار مهم تر شود.

برای کاربر عادی چه چیزهایی مهم است؟

  • GPU را در Slot اصلی توصیه شده Motherboard نصب کنید.
  • Generation و Lane Configuration سیستم را بررسی کنید.
  • از نصب GPU در Slot محدودتر بدون دلیل خودداری کنید.
  • برای کارت های دارای Link باریک تر، تاثیر Generation اهمیت بیشتری دارد.
  • کمبود VRAM را با PCIe Bandwidth اشتباه نگیرید.
  • برای Gaming، Benchmark واقعی مهم تر از حدس زدن از روی PCIe Spec است.

Common Mistakes — اشتباهات رایج درباره PCIe
  • PCIe x16 فیزیکی را همیشه x16 الکتریکی فرض نکنید.
  • PCIe Bandwidth را با VRAM Bandwidth یکی ندانید.
  • نسل قدیمی تر PCIe را همیشه معادل افت شدید Gaming Performance ندانید.
  • هر GPU را در هر Slot x16 ظاهری نصب نکنید.
  • PCIe Bottleneck را بدون بررسی Data Transfer نتیجه گیری نکنید.
  • VRAM Capacity پایین را فقط یک مشکل PCIe ندانید.
  • Link Speed در Idle را بدون Load تست قضاوت نکنید.
  • Generation و Lane Count را جدا از هم بررسی نکنید.

مدل ذهنی ساده PCIe


CPU / System Memory

        │
        ▼

PCIe Link

Generation
+
Lane Count

        │
        ▼

GPU

        │
        ▼

Local VRAM

        │
        ▼

Shader / Compute / Graphics Work

سوالات متداول درباره PCIe و GPU

PCIe چیست؟

یک رابط پرسرعت
برای اتصال GPU
و سایر Deviceها
به سیستم است.

PCIe x16 یعنی چه؟

یعنی Link
می تواند از 16 Lane
برای انتقال داده استفاده کند.

اما Slot فیزیکی x16
الزاما همیشه 16 Lane فعال ندارد.

آیا PCIe Gen جدیدتر GPU را سریع تر می کند؟

فقط اگر Workload
به Bandwidth بیشتر PCIe
نیاز داشته باشد.

در بسیاری از Workloadها
بخش دیگری از GPU
محدودکننده اصلی است.

PCIe و VRAM Bandwidth چه تفاوتی دارند؟

PCIe
ارتباط GPU با سیستم را مدیریت می کند.

VRAM Bandwidth
ارتباط GPU با حافظه محلی خودش را توصیف می کند.

چرا GPU را در اولین Slot PCIe نصب می کنیم؟

چون در بسیاری از Motherboardها
اولین Slot اصلی
بهترین اتصال و بیشترین Lane مستقیم
را برای GPU فراهم می کند.

Manual Motherboard
مرجع اصلی این موضوع است.

Resizable BAR چیست؟

قابلیتی است
که به CPU اجازه می دهد
بخش بزرگ تری از فضای VRAM
را به صورت مستقیم Map کند.

اثر Performance آن
به Workload بستگی دارد.

آیا کمبود VRAM می تواند فشار روی PCIe را بیشتر کند؟

بله.

اگر Working Set
به خوبی در VRAM جا نشود،
Data Movement میان حافظه سیستم و GPU
می تواند افزایش پیدا کند.

خلاصه فصل

  • PCIe رابط ارتباطی اصلی GPU با سیستم در بسیاری از کامپیوترها است.
  • PCIe از Laneها برای انتقال داده استفاده می کند.
  • x16 به تعداد Laneهای Link اشاره دارد.
  • Slot فیزیکی x16 الزاما 16 Lane فعال ندارد.
  • Generation جدیدتر Bandwidth بیشتری برای هر Lane فراهم می کند.
  • PCIe نسل های مختلف معمولا با یکدیگر سازگاری دارند.
  • GPU از PCIe برای Command و Data Transfer استفاده می کند.
  • VRAM باعث می شود GPU بسیاری از داده های پرتکرار را محلی نگه دارد.
  • PCIe Bandwidth و VRAM Bandwidth دو مفهوم متفاوت هستند.
  • در Gaming، PCIe همیشه Bottleneck اصلی نیست.
  • در Compute و Data Streaming، PCIe می تواند اهمیت بیشتری داشته باشد.
  • Transferهای کوچک بیشتر به Latency و Transferهای بزرگ بیشتر به Bandwidth حساس هستند.
  • Resizable BAR می تواند دسترسی CPU به VRAM را تغییر دهد.
  • اسلات اصلی Motherboard معمولا بهترین محل نصب GPU است.
  • برای تحلیل واقعی، Workload و Benchmark مهم تر از Spec تنها هستند.

سطح: مقدماتی تا متوسط

پیش نیاز:
Graphics Pipeline،
Frame Buffer،
VRAM،
PCIe Interface

موضوع:
Display Output & Final Image Path

زمان مطالعه:
حدود 8 تا 10 دقیقه


GPU DISPLAY PIPELINE

تصویر نهایی چگونه از GPU به مانیتور می رسد؟

بعد از اینکه GPU
رندر یک Frame را تمام کرد،
کار هنوز کاملا تمام نشده است.

تصویر نهایی باید
از حافظه GPU خوانده شود،
برای نمایش آماده شود،
از طریق رابطی مانند
DisplayPort یا HDMI
ارسال شود
و در نهایت
توسط Display
روی صفحه نمایش داده شود.

بنابراین Rendering
و Display
دو مرحله مرتبط
اما متفاوت هستند.


پاسخ سریع

GPU ابتدا Frame را Render می کند
و نتیجه معمولا
در یک Buffer داخل حافظه گرافیکی
قرار می گیرد.

Display Engine
اطلاعات لازم برای نمایش را
از Buffer مناسب می خواند
و Signal خروجی را
برای Display Interface
آماده می کند.

سپس تصویر
از طریق رابطی مانند
HDMI یا DisplayPort
به مانیتور منتقل می شود.

در این فصل چه چیزهایی یاد می گیریم؟

  • Rendering و Display چه تفاوتی دارند.
  • Frame Buffer چیست.
  • Front Buffer و Back Buffer چه هستند.
  • Double Buffering چیست.
  • Triple Buffering چه مفهومی دارد.
  • Screen Tearing چرا اتفاق می افتد.
  • V-Sync چیست.
  • Variable Refresh Rate چیست.
  • Refresh Rate و FPS چه تفاوتی دارند.
  • HDMI و DisplayPort چه نقشی دارند.
  • Resolution، Refresh Rate و Color Depth چگونه روی Display Bandwidth اثر می گذارند.
  • مسیر کامل یک Frame از GPU تا صفحه چگونه است.

Rendering و Display یکی نیستند

Rendering
فرایند ساخت تصویر توسط GPU است.

Display
فرایند نمایش آن تصویر
روی مانیتور است.


3D Scene

   │
   ▼

GPU Rendering

   │
   ▼

Completed Frame

   │
   ▼

Display Pipeline

   │
   ▼

Monitor

   │
   ▼

Visible Image

GPU ممکن است Frameها را
با سرعتی متفاوت
از Refresh Rate مانیتور
تولید کند.

Frame Buffer چیست؟


Frame Buffer

ناحیه ای از حافظه است
که اطلاعات تصویر
برای یک Frame
در آن نگهداری می شود.


Rendered Pixels

      │
      ▼

┌─────────────────────────┐
│                         │
│      Frame Buffer       │
│                         │
└─────────────────────────┘

      │
      ▼

Display

در سیستم های مدرن
معمولا چند Buffer
در فرایند Rendering و Presentation
وجود دارد.

Front Buffer چیست؟

به صورت مفهومی،
Front Buffer
تصویری است
که در حال حاضر
برای نمایش استفاده می شود.


Front Buffer

┌──────────────────────┐
│ Current Frame        │
└──────────────────────┘

          │
          ▼

       Display

Back Buffer چیست؟

Back Buffer
فضایی است
که Frame جدید
می تواند در آن
آماده شود
بدون اینکه مستقیما
تصویر در حال نمایش
تغییر کند.


Front Buffer
     │
     └── Currently Displayed


Back Buffer
     │
     └── Next Frame Being Prepared

Double Buffering چیست؟

در مدل ساده Double Buffering
دو Buffer داریم.


Buffer A

Currently Displayed


Buffer B

Next Frame


After Presentation

Buffer B
Currently Displayed

Buffer A
Available for Next Frame

به جای تغییر مستقیم
تصویر در حال نمایش،
Frame کامل جدید
آماده می شود
و سپس نقش Bufferها
تغییر می کند.

Swap Chain چیست؟


Swap Chain

مجموعه ای از Bufferها
و سازوکار Presentation است
که برنامه از طریق Graphics API
برای آماده سازی و ارائه Frameها
استفاده می کند.


Application

     │
     ▼

Render Frame

     │
     ▼

Swap Chain Buffer

     │
     ▼

Present

     │
     ▼

Display System

Triple Buffering چیست؟

Triple Buffering
به صورت کلی
از Buffer اضافی
در زنجیره Presentation
استفاده می کند.


Buffer A

Buffer B

Buffer C

وجود Buffer بیشتر
می تواند انعطاف بیشتری
میان Rendering
و Display Timing
ایجاد کند.

اما رفتار دقیق
به Graphics API،
Presentation Mode
و Application
وابسته است.

Refresh Rate چیست؟


Refresh Rate

تعداد دفعاتی است
که Display
در هر ثانیه
فرایند Refresh تصویر را انجام می دهد.

واحد رایج آن:


Hertz

Hz

برای مثال:


60 Hz

120 Hz

144 Hz

240 Hz

Refresh Rate
یک ویژگی مسیر Display است
و با FPS
یک مفهوم واحد نیست.

FPS و Hz چه تفاوتی دارند؟

FPS
سرعت تولید Frame
توسط Application و GPU
را توصیف می کند.

Hz
سرعت Refresh Display
را توصیف می کند.


GPU

Frames Per Second
FPS


Display

Refreshes Per Second
Hz

این دو
به یکدیگر مرتبط هستند،
اما الزاما برابر نیستند.

Refresh Interval چگونه محاسبه می شود؟

برای یک Refresh Rate ثابت،
زمان تقریبی بین Refreshها
از رابطه زیر به دست می آید:


Refresh Interval

=

1
────────────
Refresh Rate

برای مثال،
در 60 Hz
هر Refresh تقریبا
16.67 میلی ثانیه
فاصله دارد.

در 120 Hz
این فاصله تقریبا
8.33 میلی ثانیه است.

Screen Tearing چیست؟

اگر تصویر مورد استفاده برای Scanout
در زمانی تغییر کند
که Display
در حال دریافت یا نمایش Frame است،
ممکن است بخش های مختلف صفحه
از Frameهای متفاوت دیده شوند.


Top of Screen

Frame A
──────────────

Tear Line
══════════════

Frame B

Bottom of Screen

این پدیده
Screen Tearing
نامیده می شود.

V-Sync چیست؟


Vertical Synchronization — V-Sync

مکانیزمی برای هماهنگ کردن
Presentation Frame
با Timing نمایشگر است
تا Tearing کاهش پیدا کند.


GPU Frame Ready

      │
      ▼

Wait for
Presentation Timing

      │
      ▼

Present Frame

      │
      ▼

Display

این هماهنگی
می تواند روی Latency
و رفتار Frame Queue
نیز اثر بگذارد.

Variable Refresh Rate چیست؟


Variable Refresh Rate — VRR

قابلیتی است
که اجازه می دهد
Timing Refresh نمایشگر
در محدوده پشتیبانی شده
با زمان آماده شدن Frameها
هماهنگ تر شود.


Fixed Refresh

|----|----|----|----|


Variable Refresh

|---|-----|--|------|

هدف اصلی
کاهش مشکلات ناشی از
عدم هماهنگی
میان Frame Production
و Display Refresh است.

Display Engine چیست؟

GPU فقط واحدهای Shader ندارد.

بخش هایی از GPU
برای مدیریت خروجی تصویر
و Display Pipeline
طراحی شده اند.


Rendered Frame

      │
      ▼

Display Engine

      │
      ▼

Output Interface

      │
      ▼

Monitor

Display Engine
وظایفی مرتبط با
Scanout،
Timing،
Composition
و Output
را مدیریت می کند.

Scanout چیست؟

Scanout
به فرایند خواندن اطلاعات تصویر
برای ارسال به Display
گفته می شود.


Frame Buffer

┌───────────────────────┐
│ Row 1                 │
│ Row 2                 │
│ Row 3                 │
│ ...                   │
└───────────────────────┘

        │
        ▼

     Scanout

        │
        ▼

Display Output

این فرایند
با Rendering خود Frame
یکسان نیست.

HDMI چیست؟


HDMI

یک رابط دیجیتال
برای انتقال تصویر
و در بسیاری از کاربردها
صدا است.


GPU

 │
 ▼

HDMI

 │
 ▼

Monitor / TV

Resolution،
Refresh Rate،
Color Format
و قابلیت های قابل استفاده
به نسخه رابط
و تجهیزات دو طرف اتصال
بستگی دارند.

DisplayPort چیست؟


DisplayPort

یک رابط دیجیتال
برای انتقال Display Data
است
که در مانیتورها
و کارت های گرافیک
کاربرد گسترده ای دارد.


GPU

 │
 ▼

DisplayPort

 │
 ▼

Monitor

نسخه های مختلف DisplayPort
قابلیت ها و ظرفیت های متفاوتی
دارند.

HDMI بهتر است یا DisplayPort؟

پاسخ مطلقی وجود ندارد.

انتخاب مناسب
به GPU،
Display،
نسخه رابط،
Resolution،
Refresh Rate
و Featureهای مورد نیاز
بستگی دارد.

موضوع نکته
Monitor DisplayPort در بسیاری از مانیتورهای PC رایج است.
TV HDMI در تلویزیون ها بسیار رایج است.
High Refresh باید نسخه رابط و قابلیت واقعی Display بررسی شود.
VRR پشتیبانی GPU، Display و Connection باید با هم بررسی شوند.

چه چیزهایی Display Bandwidth را افزایش می دهند؟

به طور کلی
افزایش موارد زیر
به Data Rate بیشتری نیاز دارد:

  • Resolution بالاتر،
  • Refresh Rate بالاتر،
  • Color Depth بیشتر،
  • و برخی Color Formatها.


Higher Resolution

        +

Higher Refresh Rate

        +

Higher Color Depth

        │
        ▼

More Display Data

Resolution چه تاثیری دارد؟

Resolution بالاتر
یعنی Pixelهای بیشتری
در هر Frame وجود دارند.


1920 × 1080

≈ 2.07 Million Pixels


2560 × 1440

≈ 3.69 Million Pixels


3840 × 2160

≈ 8.29 Million Pixels

افزایش Resolution
هم می تواند
Rendering Workload را افزایش دهد
و هم
به Display Data بیشتری نیاز داشته باشد.

Color Depth چیست؟

Color Depth
به مقدار اطلاعات
برای نمایش سطوح رنگ
مربوط است.

در مسیر Display،
Color Depth بالاتر
می تواند
به Data Rate بیشتری نیاز داشته باشد.


Resolution

     ×

Refresh Rate

     ×

Color Information

     │
     ▼

Display Data Requirement

HDR چیست؟


High Dynamic Range — HDR

مجموعه ای از قابلیت ها
برای نمایش دامنه گسترده تر
روشنایی و رنگ
در زنجیره سازگار
است.

برای تجربه صحیح HDR
فقط GPU کافی نیست.


Content

   │
   ▼

Application / OS

   │
   ▼

GPU Output

   │
   ▼

Compatible Connection

   │
   ▼

HDR-Capable Display

GPU چگونه چند مانیتور را مدیریت می کند؟

بسیاری از GPUها
چند Display Output
دارند
و می توانند
بیش از یک Display
را مدیریت کنند.


             ┌──► Display 1
             │
GPU ─────────┼──► Display 2
             │
             └──► Display 3

تعداد و ترکیب Displayهای قابل پشتیبانی
به GPU،
Display Engine،
Port Configuration
و Resolution/Refresh مورد استفاده
بستگی دارد.

آیا داشتن HDMI یا DisplayPort جدیدتر GPU را سریع تر می کند؟

خیر.

Display Interface
ظرفیت و قابلیت های خروجی تصویر
را تعیین می کند.

قدرت Rendering
به بخش هایی مانند:

  • GPU Architecture،
  • Shader Throughput،
  • Memory System،
  • Clock،
  • و Workload

وابسته است.

Display Bandwidth
با Rendering Performance
یک مفهوم نیست.

مسیر ساده یک Frame از برنامه تا مانیتور


Application

      │
      ▼

Graphics API

      │
      ▼

GPU Work

      │
      ▼

Rendered Frame

      │
      ▼

Swap Chain / Presentation

      │
      ▼

Display Engine

      │
      ▼

HDMI / DisplayPort

      │
      ▼

Monitor

      │
      ▼

Visible Image

Input-to-Display Latency فقط GPU Render Time نیست

زمانی که کاربر
Input ایجاد می کند
تا زمانی که نتیجه آن
روی Display دیده شود،
چند مرحله وجود دارد.


Input

  │
  ▼

Game / Application

  │
  ▼

CPU Work

  │
  ▼

GPU Rendering

  │
  ▼

Frame Queue / Present

  │
  ▼

Display Scanout

  │
  ▼

Panel Response

  │
  ▼

Visible Result

بنابراین
کاهش Render Time
فقط یکی از راه های
کاهش End-to-End Latency است.

Under the Hood — GPU می تواند هم زمان Frame بعدی را بسازد و Frame قبلی را نمایش دهد

Rendering Pipeline
و Display Pipeline
می توانند تا حدی
مستقل از یکدیگر کار کنند.


Time ─────────────────────────►


GPU Rendering

Frame B
██████████████


Display Engine

Frame A
████████████████████

در حالی که Display Engine
Frame قبلی را
برای نمایش می خواند،
GPU می تواند
روی Frame جدید
کار کند.

Buffering
این هم پوشانی
را ممکن می کند.

Performance Impact — FPS بالا بدون Frame Delivery مناسب کافی نیست

Average FPS
فقط بخشی از تجربه نهایی است.

مواردی مانند:

  • Frame Time Consistency،
  • Presentation Timing،
  • Refresh Rate،
  • VRR،
  • V-Sync،
  • و Input Latency

نیز روی تجربه کاربر
اثر دارند.

Frame باید نه فقط سریع Render شود،
بلکه در زمان مناسب
به Display برسد.

Engineering Insight — Rendering و Presentation را جدا تحلیل کنید

اگر Performance پایین است،
باید مشخص شود
مشکل در کدام بخش قرار دارد.


Low Visible Frame Rate

        │
        ▼

Is GPU Rendering Slow?

      /   
    Yes    No
     │      │
     ▼      ▼

Rendering   Check Presentation
Bottleneck  V-Sync / Frame Cap
            Display Timing

گاهی GPU
قادر به Render سریع تر است،
اما Presentation Policy
Frame Rate قابل مشاهده
را محدود کرده است.

بعد از نصب GPU چه چیزهایی را بررسی کنیم؟

  • مانیتور به خروجی GPU مناسب متصل باشد.
  • Resolution صحیح در سیستم عامل انتخاب شده باشد.
  • Refresh Rate واقعی مانیتور فعال شده باشد.
  • کابل و Port از حالت مورد نظر پشتیبانی کنند.
  • در صورت نیاز VRR فعال و سازگار باشد.
  • HDR فقط در زنجیره سازگار فعال شود.
  • Color Depth و Output Mode مناسب انتخاب شود.
  • برای High Refresh فقط به نام کابل اکتفا نشود و قابلیت واقعی Connection بررسی شود.

Common Mistakes — اشتباهات رایج درباره Display Output
  • FPS و Refresh Rate را یک مفهوم ندانید.
  • Rendering و Display را یک مرحله فرض نکنید.
  • Frame Buffer را با VRAM کامل یکی ندانید.
  • V-Sync را فقط یک FPS Limiter ساده فرض نکنید.
  • VRR و V-Sync را دقیقا یک فناوری ندانید.
  • HDMI یا DisplayPort جدیدتر را معادل GPU سریع تر ندانید.
  • High Refresh Monitor را بدون تنظیم Refresh Rate در سیستم عامل استفاده نکنید.
  • فقط Resolution را برای بررسی Display Bandwidth در نظر نگیرید.
  • Color Depth و Refresh Rate را نادیده نگیرید.
  • Average FPS بالا را به تنهایی تضمین کننده تجربه روان ندانید.

مدل ذهنی ساده


Render

  │
  ▼

Store Frame

  │
  ▼

Present

  │
  ▼

Scanout

  │
  ▼

Encode / Transmit

  │
  ▼

Display Receives

  │
  ▼

Panel Updates

  │
  ▼

You See the Frame

سوالات متداول درباره خروجی تصویر GPU

FPS و Hz یکی هستند؟

خیر.

FPS
سرعت تولید Frame توسط سیستم است،
در حالی که Hz
Refresh Rate نمایشگر را بیان می کند.

Screen Tearing چیست؟

حالتی است
که بخش های مختلف تصویر قابل مشاهده
از Frameهای متفاوت تشکیل شوند
و یک شکست افقی در تصویر دیده شود.

V-Sync چه کاری انجام می دهد؟

Presentation Frameها
را با Timing نمایشگر
هماهنگ تر می کند
تا Tearing کاهش یابد.

VRR چیست؟

Variable Refresh Rate
به Display اجازه می دهد
در محدوده پشتیبانی شده
Timing Refresh خود را
با Frame Delivery هماهنگ تر کند.

DisplayPort بهتر است یا HDMI؟

به نسخه رابط،
GPU،
Display،
Resolution،
Refresh Rate
و Featureهای مورد نیاز بستگی دارد.

نام رابط به تنهایی
برای تصمیم گیری کافی نیست.

چرا مانیتور 144 Hz من روی 60 Hz کار می کند؟

ممکن است Refresh Rate صحیح
در سیستم عامل انتخاب نشده باشد
یا Port،
Cable،
Resolution
یا تنظیمات Display
حالت مورد نظر را محدود کرده باشند.

آیا Resolution بالاتر فقط GPU Rendering را سنگین تر می کند؟

خیر.

Resolution بالاتر
علاوه بر افزایش تعداد Pixelهای Rendering،
مقدار Display Data
را نیز افزایش می دهد.

آیا چند مانیتور را می توان به یک GPU متصل کرد؟

در بسیاری از GPUها بله.

اما تعداد،
Resolution،
Refresh Rate
و ترکیب خروجی های قابل استفاده
به GPU و Display Engine آن بستگی دارد.

خلاصه فصل

  • Rendering و Display دو مرحله متفاوت هستند.
  • Frame Buffer اطلاعات تصویر را نگهداری می کند.
  • Front و Back Buffer امکان آماده سازی Frame جدید بدون تغییر مستقیم تصویر فعلی را فراهم می کنند.
  • Swap Chain مدیریت Bufferهای Presentation را ممکن می کند.
  • Refresh Rate با Hz اندازه گیری می شود.
  • FPS و Refresh Rate یک مفهوم نیستند.
  • Screen Tearing از عدم هماهنگی مناسب Frame Delivery و Scanout ایجاد می شود.
  • V-Sync Presentation را با Timing نمایشگر هماهنگ می کند.
  • VRR اجازه می دهد Refresh Timing در محدوده پشتیبانی شده تغییر کند.
  • Display Engine مسیر خروجی تصویر را مدیریت می کند.
  • HDMI و DisplayPort رابط های انتقال تصویر هستند.
  • Resolution و Refresh Rate بالاتر به Display Data بیشتری نیاز دارند.
  • Color Depth نیز روی نیاز Bandwidth خروجی اثر دارد.
  • HDR به یک زنجیره سازگار از Content تا Display نیاز دارد.
  • Display Interface جدیدتر به خودی خود Rendering Performance را افزایش نمی دهد.
  • تجربه نهایی به FPS، Frame Time، Presentation و Display Timing با هم وابسته است.


سطح: مقدماتی تا متوسط

پیش نیاز:
Graphics Pipeline،
Compute Pipeline،
PCIe Interface،
Display Output

موضوع:
GPU Driver & Software Stack

زمان مطالعه:
حدود 8 تا 10 دقیقه


GPU SOFTWARE STACK

GPU Driver و Software Stack چه کاری انجام می دهند؟

برنامه مستقیما
با ترانزیستورهای GPU صحبت نمی کند.

بین Application
و سخت افزار GPU
چند لایه نرم افزاری قرار دارند
که Commandها،
Shaderها،
Memory Resourceها
و Stateهای مختلف
را مدیریت می کنند.

Driver
یکی از مهم ترین بخش های این زنجیره است.


پاسخ سریع

GPU Driver
نرم افزاری است
که ارتباط میان Operating System،
Graphics / Compute API
و سخت افزار GPU
را مدیریت می کند.

Application
از APIهایی مانند
Direct3D،
Vulkan،
OpenGL،
CUDA
یا سایر Runtimeها استفاده می کند
و Driver
این درخواست ها را
به Commandهای قابل اجرا
برای GPU تبدیل و مدیریت می کند.

در این فصل چه چیزهایی یاد می گیریم؟

  • Driver چیست.
  • Graphics API چه نقشی دارد.
  • Runtime و Driver چه تفاوتی دارند.
  • Shader Compilation چیست.
  • Command Submission چگونه انجام می شود.
  • Memory Management چه نقشی دارد.
  • چرا Driver می تواند روی Performance اثر بگذارد.
  • چرا Driver Update همیشه Performance بیشتری ایجاد نمی کند.

تصویر کلی Software Stack


Application

     │
     ▼

Graphics / Compute API

     │
     ▼

Runtime / Driver

     │
     ▼

Command Submission

     │
     ▼

GPU Hardware

در عمل
جزئیات این مسیر
میان Operating Systemها،
APIها
و Vendorها متفاوت است،
اما همین مدل
برای درک معماری کلی مناسب است.

GPU Driver چیست؟


GPU Driver

مجموعه ای از نرم افزارهاست
که Operating System
و برنامه ها
را قادر می سازد
از GPU استفاده کنند.

Driver
می تواند مسئول یا درگیر
مواردی مانند:

  • Command Submission،
  • Memory Management،
  • Shader Compilation،
  • Resource Management،
  • Synchronization،
  • Display Configuration،
  • و Power / Performance Policy

باشد.

Graphics API چیست؟


Graphics API

رابط برنامه نویسی
برای تعریف عملیات Rendering
و ارتباط نرم افزار
با Graphics System است.

نمونه های شناخته شده:


Direct3D

Vulkan

OpenGL

Metal

API
به برنامه نویس اجازه می دهد
بدون مدیریت مستقیم
جزئیات سخت افزاری هر GPU
کار گرافیکی تعریف کند.

Compute APIها

GPU
فقط برای Graphics استفاده نمی شود.

Compute Frameworkها و APIهای مختلف
می توانند
GPU را برای محاسبات عمومی تر
به کار بگیرند.


Application

     │
     ▼

Compute API / Runtime

     │
     ▼

Driver

     │
     ▼

GPU Compute Hardware

نمونه ها
می توانند شامل
CUDA،
OpenCL
و Compute Shaderهای Graphics APIها باشند.

High-Level و Low-Level API چه تفاوتی دارند؟

APIهایی که کنترل بیشتری
روی Resource،
Synchronization
و Command Submission می دهند،
معمولا
مسئولیت بیشتری نیز
به برنامه نویس منتقل می کنند.

رویکرد ویژگی کلی
Higher-Level مدیریت بیشتر توسط Driver / Runtime
Lower-Level کنترل بیشتر برای Application
و مدیریت صریح تر Resourceها

کنترل بیشتر
می تواند Optimization بهتری فراهم کند،
اما Complexity بیشتری نیز ایجاد می کند.

Command Submission چیست؟

CPU
به GPU دستورهای مختلفی
برای انجام کار ارسال می کند.

برای مثال:

  • Draw،
  • Dispatch،
  • Copy،
  • Resource Transition،
  • یا Synchronization Operation.


CPU

  │
  ▼

Build Commands

  │
  ▼

Command Queue

  │
  ▼

GPU Executes

Command Buffer چیست؟

به جای ارسال
هر عملیات به صورت کاملا جداگانه،
Application می تواند
مجموعه ای از Commandها
را در یک ساختار آماده کند.


Command Buffer

├── Set Pipeline
├── Bind Resources
├── Draw
├── Draw
├── Dispatch
└── Copy

سپس این مجموعه
برای اجرا
به GPU Queue ارسال می شود.

Shader Source مستقیما روی GPU اجرا نمی شود

Shader
معمولا با یک زبان برنامه نویسی
نوشته می شود.

برای مثال:


HLSL

GLSL

Other Shader Languages

این کد
باید به فرم مناسب
برای Pipeline و سخت افزار
تبدیل شود.

Shader Compilation چیست؟

Shader Compiler
کد Shader
را به فرم میانی
یا کد مناسب تر برای GPU
تبدیل می کند.


Shader Source

      │
      ▼

Compiler

      │
      ▼

Intermediate Representation
or
GPU-Specific Code

      │
      ▼

Execution

در برخی Stackها
بخشی از Compilation
قبل از اجرای برنامه
و بخشی
نزدیک Runtime انجام می شود.

Shader Cache چیست؟

اگر Shader
هر بار از ابتدا Compile شود،
ممکن است هزینه اضافی ایجاد شود.

Shader Cache
می تواند نتیجه Compilation
را برای استفاده مجدد
نگهداری کند.


First Run

Shader
  │
  ▼
Compile
  │
  ▼
Cache Result


Later

Shader
  │
  ▼
Cached Result

Shader Compilation چگونه می تواند Stutter ایجاد کند؟

اگر Compilation
در لحظه ای انجام شود
که Frame باید سریع آماده شود،
CPU یا Pipeline
ممکن است موقتا متوقف شود.


Normal Frames

16 ms
16 ms
16 ms


Compilation Event

16 ms
16 ms
80 ms
16 ms

نتیجه
ممکن است
به صورت Frame Time Spike
یا Stutter دیده شود.

Pipeline State چیست؟

Graphics Pipeline
فقط Shader نیست.

حالت های مختلفی
باید برای Rendering مشخص شوند.


Pipeline State

├── Shaders
├── Blend State
├── Depth State
├── Rasterization State
├── Formats
└── Other Configuration

APIهای مدرن
می توانند بخش بزرگی از این State
را در ساختارهای Pipeline
تعریف کنند.

Software چگونه Resourceهای GPU را مدیریت می کند؟

Application
با Resourceهایی مانند:

  • Texture،
  • Buffer،
  • Render Target،
  • Depth Buffer،
  • Acceleration Structure

کار می کند.

Driver و Runtime
کمک می کنند
این Resourceها
به حافظه و سخت افزار واقعی
مرتبط شوند.

GPU Virtual Memory در Software Stack

Application
معمولا لازم نیست
آدرس فیزیکی واقعی
هر Byte در VRAM
را مدیریت کند.


Application Resource

      │
      ▼

Virtual GPU Address

      │
      ▼

Memory Management

      │
      ▼

Physical Memory Location

Memory Manager
می تواند Mapping
و Placement
را مدیریت کند.

Operating System هم در GPU Scheduling نقش دارد

در یک سیستم Desktop
چند Application
می توانند
به GPU نیاز داشته باشند.


Game

Browser

Video Player

Compute App

      │
      ▼

OS / Driver Scheduling

      │
      ▼

GPU

Software Stack
باید میان این Workloadها
مدیریت و Scheduling انجام دهد.

Synchronization چرا لازم است؟

اگر GPU
قرار است داده ای را بخواند
که هنوز نوشته نشده،
یا CPU
بخواهد نتیجه GPU
را قبل از پایان کار استفاده کند،
مشکل ایجاد می شود.


Producer

   │
   ▼

Write Data

   │
   ▼

Synchronization

   │
   ▼

Consumer

   │
   ▼

Read Data

Fence،
Semaphore
و Barrier
نمونه هایی از مکانیزم های Synchronization
در APIهای مختلف هستند.

Synchronization بیش از حد چه مشکلی ایجاد می کند؟

اگر CPU و GPU
بیش از حد
منتظر یکدیگر بمانند،
Parallelism کاهش پیدا می کند.


CPU Work

██████
      WAIT
          ██████


GPU Work

      ██████
            WAIT
                ██████

یکی از اهداف Optimization
کاهش Waitهای غیرضروری
و افزایش Overlap مناسب
میان CPU و GPU است.

Driver چگونه می تواند Performance را تغییر دهد؟

Driver
می تواند روی رفتار
Workload تاثیر بگذارد.

برای مثال
تغییرات Driver ممکن است:

  • Compiler را بهبود دهد،
  • Bug را رفع کند،
  • Scheduling را تغییر دهد،
  • Application Compatibility را بهتر کند،
  • یا مسیرهای خاصی را Optimize کند.

به همین دلیل
نسخه Driver
می تواند در Benchmarkها مهم باشد.

Driver Profile چیست؟

Driver
می تواند
برای بعضی Applicationها
تنظیمات یا Optimizationهای خاصی داشته باشد.


Application Detected

      │
      ▼

Driver Profile

      │
      ▼

Known Settings /
Compatibility Behavior

این موضوع
یکی از دلایلی است
که Update Driver
گاهی روی یک بازی خاص
اثر بیشتری
از بازی دیگر دارد.

آیا Driver جدید همیشه بهتر است؟

نه لزوما
برای هر سیستم
و هر Workload.

نسخه جدید
می تواند:

  • Bug Fix،
  • Security Update،
  • Game Support،
  • Feature Support،
  • یا Performance Improvement

داشته باشد.

اما Regression
یا مشکل Compatibility
نیز در نرم افزار ممکن است رخ دهد.

بنابراین
برای سیستم های حساس
بهتر است Update
با نیاز واقعی و Stability
بررسی شود.

API Overhead چیست؟

هر Command
برای رسیدن از Application
به GPU
مقداری Software Work
نیاز دارد.

اگر تعداد بسیار زیادی
Command کوچک
ارسال شود،
CPU-side Overhead
می تواند اهمیت پیدا کند.


Thousands of Tiny Commands

      │
      ▼

CPU / Driver Work

      │
      ▼

Possible Submission Bottleneck

این یکی از دلایلی است
که Batching
در برخی Workloadها
مفید است.

Draw Call چیست؟

Draw Call
یک دستور Rendering
برای پردازش Geometry
با State و Resourceهای مشخص است.


CPU

Draw Object A

Draw Object B

Draw Object C

      │
      ▼

GPU Work

تعداد زیاد Draw Call
می تواند CPU،
Driver
و Command Submission
را تحت فشار قرار دهد.

Async Work چیست؟

در بعضی GPUها و APIها
انواع مختلف Work
می توانند تا حدی
هم پوشانی داشته باشند.


Graphics Work

████████████████


Compute Work

      ███████████


Copy Work

            ███████

هدف
استفاده بهتر از بخش هایی از GPU
است که در زمان خاص
آزاد هستند.

اما Overlap واقعی
به معماری،
Dependency
و Workload بستگی دارد.

Compiler چرا در Performance مهم است؟

Shader Compiler
فقط Syntax را تبدیل نمی کند.

Compiler می تواند
تصمیم هایی درباره:

  • Instruction Selection،
  • Register Usage،
  • Code Scheduling،
  • Dead Code Removal،
  • و سایر Optimizationها

بگیرد.


Same Shader Logic

      │
      ▼

Different Compilation Quality

      │
      ▼

Different Register / Instruction Behavior

      │
      ▼

Possible Performance Difference

Compiler و Register Pressure

اگر Generated Code
Registerهای زیادی نیاز داشته باشد،
ممکن است Occupancy
کاهش پیدا کند.


Shader Compilation

      │
      ▼

Register Usage

      │
      ▼

Resident Warps

      │
      ▼

Occupancy / Scheduling Options

این نمونه خوبی است
از اینکه چگونه
Software و Hardware Architecture
مستقیما به هم متصل هستند.

Performance فقط وظیفه Driver نیست

Application
بخش بزرگی از رفتار GPU
را تعیین می کند.

مواردی مانند:

  • Shader Design،
  • Resource Layout،
  • Batching،
  • Synchronization،
  • Rendering Technique،
  • LOD،
  • و Memory Usage

همگی
بر Performance اثر دارند.

Driver می تواند مسیر را بهتر کند،
اما Workload را Application می سازد.

Under the Hood — همان سخت افزار می تواند با Software متفاوت رفتار متفاوتی داشته باشد

فرض کنید دو برنامه
از GPU یکسانی استفاده کنند.


Same GPU


Application A

Good Batching
Good Memory Access
Efficient Shaders


Application B

Excessive Sync
Poor Data Layout
Expensive Shaders

Performance آنها
می تواند بسیار متفاوت باشد،
با اینکه سخت افزار
هیچ تغییری نکرده است.

GPU Performance
حاصل همکاری Hardware و Software است.

Performance Impact — Driver Bottleneck و GPU Bottleneck را یکی ندانید

ممکن است GPU
ظرفیت بیشتری داشته باشد،
اما CPU یا Driver
نتوانند با سرعت کافی
Command آماده کنند.


CPU / Driver

██████

      │
      ▼

GPU

██████████████████

در چنین شرایطی
بهینه سازی Shader Core
مشکل اصلی را حل نمی کند.

باید مشخص شود
محدودیت
در Submission،
CPU،
Driver
یا خود GPU است.

Engineering Insight — API پایین سطح آزادی می دهد، نه Performance رایگان

APIهایی که کنترل بیشتری
به برنامه نویس می دهند،
می توانند فرصت Optimization بیشتری ایجاد کنند.

اما همان کنترل
یعنی Application
باید موارد بیشتری را
درست مدیریت کند.

Control بیشتر
فقط زمانی مفید است
که Software بتواند از آن درست استفاده کند.

مسیر ساده یک Draw Call


Game / Application

      │
      ▼

Graphics Engine

      │
      ▼

Graphics API

      │
      ▼

Driver / Runtime

      │
      ▼

Command Queue

      │
      ▼

GPU Front-End

      │
      ▼

Graphics Pipeline

      │
      ▼

Rendered Frame

      │
      ▼

Presentation

برای کاربر عادی چه چیزهایی مهم است؟

  • Driver مناسب GPU و Operating System نصب باشد.
  • پس از مشکلات Performance یا Compatibility، نسخه Driver بررسی شود.
  • در Benchmarkها از نسخه Driver یکسان استفاده شود.
  • Shader Compilation را با GPU ضعف اشتباه نگیرید.
  • پس از Driver Update فقط Average FPS را بررسی نکنید؛ Stability و Frame Time نیز مهم هستند.
  • برای Workstationهای حساس، Stability می تواند از جدیدترین نسخه مهم تر باشد.
  • تنظیمات Application و Driver Profile را بدون دلیل تغییر ندهید.

Common Mistakes — اشتباهات رایج درباره Driver و Software Stack
  • Application را مستقیما متصل به Shader Core تصور نکنید.
  • Graphics API را با Driver یکی ندانید.
  • Shader Source را کد نهایی GPU فرض نکنید.
  • هر Stutter را GPU Hardware Bottleneck ندانید.
  • Driver جدید را همیشه سریع تر فرض نکنید.
  • Draw Call زیاد را فقط مشکل GPU ندانید.
  • Synchronization را رایگان فرض نکنید.
  • Low-Level API را به معنی Performance تضمینی ندانید.
  • Shader Compiler را از Performance Analysis جدا ندانید.
  • Software Optimization را کمتر از Hardware Specification مهم ندانید.

مدل ذهنی ساده


Application Logic

      │
      ▼

API Calls

      │
      ▼

Runtime / Driver

      │
      ├── Compile
      ├── Manage Memory
      ├── Submit Commands
      └── Synchronize

      │
      ▼

GPU Hardware

      │
      ▼

Result

سوالات متداول درباره GPU Driver

GPU Driver چیست؟

نرم افزاری است
که ارتباط میان
Operating System،
APIها
و سخت افزار GPU
را مدیریت می کند.

Graphics API چیست؟

رابطی است
که Application
از طریق آن
عملیات Graphics
را تعریف و ارسال می کند.

Shader Compilation چیست؟

فرایند تبدیل Shader Source
به فرم قابل استفاده
برای Runtime
و GPU است.

چرا Shader Compilation می تواند Stutter ایجاد کند؟

اگر Compilation
در حین Frame Rendering
و در مسیر حساس زمانی انجام شود،
می تواند Frame Time را
به طور موقت افزایش دهد.

آیا Driver جدید همیشه Performance را بهتر می کند؟

خیر.

نسخه جدید ممکن است
Performance،
Compatibility
یا Stability را بهتر کند،
اما رفتار آن
به Application و سیستم بستگی دارد.

چرا Draw Call زیاد می تواند مشکل ایجاد کند؟

زیرا هر Draw Call
مقداری CPU،
Driver
و Command Submission Work
ایجاد می کند.

آیا Low-Level API همیشه سریع تر است؟

نه.

این APIها
کنترل بیشتری ارائه می دهند،
اما Application
باید مدیریت Resource،
Synchronization
و Submission را
به خوبی انجام دهد.

خلاصه فصل

  • Application مستقیما با سخت افزار GPU ارتباط خام ندارد.
  • Graphics و Compute APIها رابط برنامه با GPU Software Stack هستند.
  • Driver ارتباط میان Software و Hardware را مدیریت می کند.
  • Commandها از CPU به Queueهای GPU ارسال می شوند.
  • Shader Source قبل از اجرا Compile می شود.
  • Shader Cache می تواند هزینه Compilation تکراری را کاهش دهد.
  • Compilation در زمان نامناسب می تواند Stutter ایجاد کند.
  • Software Stack در Resource و Memory Management نقش دارد.
  • Synchronization برای ترتیب صحیح کار لازم است اما هزینه دارد.
  • Driver Version می تواند Performance و Compatibility را تغییر دهد.
  • API Overhead در Workloadهای دارای Commandهای بسیار زیاد مهم می شود.
  • Draw Call زیاد می تواند CPU-side Bottleneck ایجاد کند.
  • Compiler Quality می تواند روی Instruction و Register Usage اثر بگذارد.
  • Low-Level API Performance رایگان ایجاد نمی کند.
  • GPU Performance حاصل همکاری Hardware، Driver و Application است.


سطح: جمع بندی نهایی

پیش نیاز:
تمام فصل های GPU

موضوع:
GPU Architecture & Performance

زمان مطالعه:
حدود 10 تا 12 دقیقه


GPU MASTER SUMMARY

جمع بندی نهایی GPU؛ از معماری تا Performance واقعی

GPU را نمی توان
فقط با تعداد Core،
حجم VRAM،
Clock
یا TFLOPS توضیح داد.

یک GPU واقعی
سیستمی متشکل از
واحدهای محاسباتی،
Memory Hierarchy،
Schedulerها،
Graphics Pipeline،
Fixed-Function Hardware،
Ray Tracing Hardware،
Matrix Hardware،
Display Engine
و Software Stack است.

Performance نهایی
از همکاری تمام این بخش ها
و نحوه استفاده Workload
از آنها ساخته می شود.


پاسخ نهایی کوتاه

GPU
پردازنده ای بسیار موازی است
که برای پردازش حجم بزرگی از داده
با Throughput بالا طراحی شده است.

در Graphics،
Geometry را پردازش می کند،
Pixelها را می سازد،
Textureها را Sample می کند
و Frame نهایی را تولید می کند.

در Compute و AI،
حجم بزرگی از عملیات موازی
را روی داده ها اجرا می کند.

اما سرعت واقعی GPU
به تعادل میان
Compute،
Memory،
Scheduling،
Software
و Workload
وابسته است.

GPU را به عنوان یک سیستم ببینید


Application

      │
      ▼

API / Driver

      │
      ▼

Command Processing

      │
      ▼

GPU Front-End

      │
      ▼

┌────────────────────────────────────┐
│                                    │
│   Programmable Compute Units       │
│                                    │
│   Texture Units                    │
│                                    │
│   Rasterization Hardware           │
│                                    │
│   Ray Tracing Hardware             │
│                                    │
│   Matrix / AI Hardware             │
│                                    │
│   Render Output                    │
│                                    │
│   Cache + Memory System            │
│                                    │
└────────────────────────────────────┘

      │
      ▼

VRAM

      │
      ▼

Result / Frame / Compute Output

هیچ کدام از این بخش ها
به تنهایی
نماینده کل GPU نیستند.

ایده بنیادی GPU چیست؟

GPU برای این ساخته شده است
که حجم بزرگی از کار
را به بخش های کوچک تر تقسیم کند
و تعداد زیادی از آنها را
به صورت هم زمان یا هم پوشان اجرا کند.


Huge Workload

      │
      ▼

Split into Many Threads

      │
      ▼

Group Threads

      │
      ▼

Schedule Ready Work

      │
      ▼

Execute in Parallel

      │
      ▼

High Throughput

مدل ذهنی نهایی CPU و GPU

CPU GPU
تعداد کمتر Coreهای پیچیده تر Parallel Execution Resources بسیار بیشتر
تمرکز بیشتر روی Latency و General-Purpose Execution تمرکز بیشتر روی Throughput
مناسب برای Control-heavy Work مناسب برای Data-Parallel Work
Branching پیچیده را بهتر تحمل می کند از Coherent Parallel Work بیشتر سود می برد

این مقایسه مطلق نیست،
اما برای درک معماری
مدل ذهنی مناسبی است.

Execution Model

برنامه GPU
تعداد زیادی Thread تولید می کند.

سخت افزار
این Threadها را
در گروه های اجرایی
مانند Warp یا Wave
مدیریت می کند.


Threads

   │
   ▼

Workgroups / Blocks

   │
   ▼

Warps / Waves

   │
   ▼

Resident Work

   │
   ▼

Ready Work

   │
   ▼

Scheduler

   │
   ▼

Execution Units

هدف Scheduler
این است که
تا حد امکان
کار آماده برای اجرا وجود داشته باشد.

یکی از رازهای GPU: Latency Hiding

وقتی یک Warp
منتظر Memory است،
GPU می تواند
Warp دیگری را اجرا کند.


Warp A

Memory Wait
──────────────


Warp B

      Execute
      ─────────


Warp C

               Execute
               ─────────

GPU همیشه Latency را حذف نمی کند؛
اغلب آن را
با Parallel Work پنهان می کند.

Occupancy مهم است، اما هدف نهایی نیست

Occupancy بالا
می تواند تعداد بیشتری Warp
برای Scheduling فراهم کند.

اما اگر Workload
به اندازه کافی کار آماده داشته باشد،
افزایش بیشتر Occupancy
الزاما Performance بیشتری ایجاد نمی کند.


Occupancy

      │
      ▼

More Resident Work

      │
      ▼

Potentially More Scheduling Options

      │
      ▼

Not Automatically
More Performance

Memory Hierarchy چرا حیاتی است؟

Compute Unitها
بدون داده
کاری نمی توانند انجام دهند.


Registers

   │
   ▼

Local / Shared Memory

   │
   ▼

Caches

   │
   ▼

VRAM

   │
   ▼

System Memory

هرچه داده
به محل اجرا نزدیک تر باشد،
معمولا دسترسی سریع تر است
اما ظرفیت کمتر می شود.

VRAM چه چیزی را تعیین می کند؟

VRAM
فضای محلی GPU
برای نگهداری Resourceها است.

می تواند شامل:

  • Textureها،
  • Buffers،
  • Frame Buffers،
  • Depth Data،
  • Acceleration Structures،
  • Model Weights،
  • و Intermediate Results

باشد.

VRAM بیشتر
ظرفیت بیشتری می دهد،
نه لزوما سرعت بیشتر.

Memory Capacity و Memory Bandwidth را جدا کنید

Metric سوال
Capacity چه مقدار داده می توان نگهداری کرد؟
Bandwidth داده با چه نرخ نظری قابل انتقال است؟
Latency دسترسی به داده چقدر زمان می برد؟

یک GPU
می تواند حافظه زیاد
ولی Bandwidth محدود داشته باشد،
یا برعکس.

Graphics Pipeline در یک نگاه


Geometry

   │
   ▼

Vertex Processing

   │
   ▼

Primitive Processing

   │
   ▼

Rasterization

   │
   ▼

Fragments

   │
   ▼

Pixel / Fragment Shader

   │
   ▼

Depth / Stencil

   │
   ▼

Blending

   │
   ▼

Render Target

   │
   ▼

Frame

Graphics Pipeline
ترکیبی از
Programmable Stages
و Fixed-Function Hardware است.

چرا GPU فقط Shader Core نیست؟

بعضی عملیات
آن قدر پرتکرار هستند
که سخت افزار تخصصی
برای آنها موثرتر است.

Rasterizer

Geometry را به Screen Coverage تبدیل می کند.

Texture Unit

Texture Sampling و Filtering را انجام می دهد.

Render Output

Depth، Stencil، Blending و Output را مدیریت می کند.

Display Engine

Frame نهایی را برای Display آماده می کند.

Texture Sampling در یک نگاه


UV Coordinate

      │
      ▼

Texture Unit

      │
      ├── Address
      ├── Mip Selection
      ├── Fetch
      └── Filtering

      │
      ▼

Sample Result

      │
      ▼

Shader

Mipmapping،
Bilinear،
Trilinear
و Anisotropic Filtering
همگی برای انتخاب و ترکیب بهتر
Texture Data استفاده می شوند.

Ray Tracing در یک نگاه


Generate Ray

     │
     ▼

Traverse Acceleration Structure

     │
     ▼

Intersection

     │
     ▼

Hit / Miss

     │
     ▼

Shading

     │
     ▼

Possible New Rays

Acceleration Structure
مانند BVH
کمک می کند
GPU مجبور نباشد
هر Ray را با تمام Geometry
مقایسه کند.

Path Tracing چرا سنگین است؟

Path Tracing
می تواند برای هر Pixel
چند Sample
و برای هر Sample
چند Bounce ایجاد کند.


Pixels

   ×

Samples

   ×

Ray Bounces

   ×

Intersection + Shading

   │
   ▼

Very Large Workload

Denoising
و Temporal Reconstruction
کمک می کنند
با تعداد محدودتری Sample
نتیجه قابل استفاده تری تولید شود.

AI Acceleration در GPU

AI Workloadها
اغلب حجم بزرگی از
Matrix Operationها دارند.


Tensor Data

    │
    ▼

Matrix Operations

    │
    ▼

General Compute
+
Specialized Matrix Hardware

    │
    ▼

Results

اما AI Performance
فقط به Matrix Hardware وابسته نیست.

VRAM Capacity،
Memory Bandwidth،
Precision،
Software Stack
و مدل مورد استفاده
نیز اهمیت دارند.

چگونه مشخصات GPU را بخوانیم؟

مشخصه چه چیزی را تقریبا توصیف می کند؟
Core Count مقدار منابع اجرایی در یک معماری مشخص
Clock نرخ فعالیت مدار
TFLOPS Peak Floating-Point Throughput
VRAM ظرفیت حافظه محلی GPU
Memory Bandwidth Peak Data Transfer Rate
Texture Rate ظرفیت نظری Texture Processing
Pixel Rate ظرفیت نظری Render Output

هیچ کدام
به تنهایی
FPS واقعی
یا Performance نهایی را تعیین نمی کنند.

TFLOPS را چگونه تفسیر کنیم؟

TFLOPS
یک Peak Compute Metric است.

برای مقایسه
باید حداقل موارد زیر مشخص باشند:

  • Precision،
  • Architecture،
  • Instruction Type،
  • و Workload.

TFLOPS درباره ظرفیت محاسباتی است؛
Benchmark درباره نتیجه واقعی.

مدل ساده Performance


Real Performance

      │
      ▼

min(

Compute Capability,

Memory Capability,

Texture Capability,

Geometry Capability,

Render Output Capability,

Ray / AI Capability,

CPU Submission,

Software Efficiency

)

این یک فرمول ریاضی دقیق نیست؛
بلکه مدل ذهنی Bottleneck است.

سریع ترین بخش سیستم
Performance را تعیین نمی کند.

بخشی که Workload
بیشتر به آن محدود شده،
اهمیت بیشتری دارد.

Bottleneck مهم ترین مفهوم Performance Analysis است

ممکن است GPU:

  • Compute-Bound،
  • Memory-Bound،
  • Texture-Bound،
  • Geometry-Bound،
  • Pixel-Bound،
  • Ray-Tracing-Bound،
  • یا حتی CPU-Bound

باشد.


Slow Performance

      │
      ▼

Measure

      │
      ▼

Find Limiting Resource

      │
      ▼

Optimize That Resource

      │
      ▼

Measure Again

Bottleneck حرکت می کند

اگر یک Bottleneck
بهینه شود،
بخش دیگری
می تواند محدودکننده جدید شود.


Before

Memory Limited


After Memory Optimization

Compute Limited


After Compute Optimization

Maybe CPU Limited

این رفتار طبیعی
یک سیستم پیچیده است.

Performance واقعی به Power و Cooling نیز وابسته است


Workload

   │
   ▼

Power Demand

   │
   ▼

Heat

   │
   ▼

Cooling

   │
   ▼

Operating Temperature

   │
   ▼

Sustained Clock

   │
   ▼

Sustained Performance

Peak Clock
اگر فقط برای مدت کوتاه حفظ شود،
Performance طولانی مدت
را به تنهایی توصیف نمی کند.

PCIe چه نقشی دارد؟

PCIe
مسیر ارتباط GPU
با سیستم است.


CPU / RAM

    │
    ▼

PCIe

    │
    ▼

GPU

    │
    ▼

Local VRAM

PCIe Bandwidth
و VRAM Bandwidth
دو مسیر متفاوت هستند.

اگر داده
یک بار به VRAM منتقل
و بارها استفاده شود،
PCIe اهمیت کمتری
در Inner Loop محاسبات دارد.

Frame چگونه به نمایشگر می رسد؟


Rendered Frame

      │
      ▼

Swap Chain / Present

      │
      ▼

Display Engine

      │
      ▼

HDMI / DisplayPort

      │
      ▼

Display

      │
      ▼

Visible Frame

Rendering Speed
و Display Refresh Rate
یک مفهوم نیستند.

FPS، Frame Time و Hz

Metric معنا
FPS تعداد Frameهای تولید شده در ثانیه
Frame Time مدت زمان ساخت هر Frame
Hz تعداد Refreshهای Display در ثانیه

برای تجربه روان،
فقط Average FPS مهم نیست؛
ثبات Frame Time
نیز اهمیت زیادی دارد.

Software Stack بخش واقعی معماری Performance است


Application

      │
      ▼

Graphics / Compute API

      │
      ▼

Runtime / Driver

      │
      ▼

Compiler

      │
      ▼

Command Submission

      │
      ▼

GPU

Shader Compilation،
Memory Management،
Command Submission،
Synchronization
و Driver Optimization
همگی می توانند
روی Performance واقعی اثر بگذارند.

Hardware بدون Software کافی نیست

دو برنامه
روی یک GPU یکسان
می توانند
Performance کاملا متفاوتی داشته باشند.


Same GPU

    │
    ├── Efficient Software
    │       │
    │       ▼
    │   High Utilization
    │
    └── Poor Software
            │
            ▼
        Stalls / Waste

به همین دلیل
معماری GPU
و معماری Software
باید در کنار هم دیده شوند.

چگونه دو GPU را درست مقایسه کنیم؟


1. Define Workload

        │
        ▼

2. Define Resolution / Settings

        │
        ▼

3. Check Required Features

        │
        ▼

4. Check VRAM Requirement

        │
        ▼

5. Compare Real Benchmarks

        │
        ▼

6. Check Power / Noise / Price

        │
        ▼

7. Use Specifications
   to Explain Differences

این روش
بسیار قابل اعتمادتر
از مقایسه یک عدد مشخصات است.

مدل ساده انتخاب GPU

Gaming

Benchmark در بازی،
Resolution،
VRAM،
Ray Tracing،
Frame Time
و قیمت.

Rendering

Software Support،
VRAM،
Compute Performance
و Renderer Compatibility.

AI

VRAM Capacity،
Memory Bandwidth،
Supported Precision،
Matrix Performance
و Software Ecosystem.

Professional Work

Application Certification،
Driver Stability،
Memory Requirement
و Workflow Performance.

این مفاهیم را با هم اشتباه نکنید

مفهوم اول مفهوم دوم
VRAM Capacity Memory Bandwidth
PCIe Bandwidth VRAM Bandwidth
Occupancy Utilization
Latency Throughput
TFLOPS Gaming FPS
FPS Refresh Rate
Shader Stage Physical Shader Core
Texel Pixel
Ray Tracing Path Tracing
Power Limit Thermal Limit

Under the Hood — اصل مشترک تقریبا تمام GPU Architecture

از Shader Execution
تا AI،
Ray Tracing
و Graphics،
یک مفهوم بارها تکرار شد:

داده را نزدیک نگه دار،
کار آماده زیاد داشته باش،
و واحدهای اجرایی را بیکار نگذار.


Enough Parallel Work

        +

Good Data Locality

        +

Efficient Scheduling

        +

Balanced Memory System

        │
        ▼

High GPU Efficiency

بخش بزرگی از Optimization GPU
در نهایت
به همین چهار ایده برمی گردد.

Performance Impact — سریع ترین GPU روی کاغذ همیشه سریع ترین GPU برای شما نیست

Workload شما
ممکن است
به ویژگی خاصی
بیشتر از سایر ویژگی ها نیاز داشته باشد.

برای مثال:

  • یک بازی ممکن است بیشتر Shader-Bound باشد،
  • یک Renderer ممکن است VRAM بیشتری بخواهد،
  • یک AI Model ممکن است Memory Capacity را محدود کند،
  • یک Compute Kernel ممکن است Memory-Bound باشد،
  • و یک Laptop ممکن است توسط Power Budget محدود شود.

بهترین GPU،
GPU متناسب با Workload شماست.

Engineering Insight — Balance مهم تر از بزرگ ترین عدد است

یک GPU قوی
نیازمند تعادل میان:

  • Compute،
  • Memory،
  • Cache،
  • Scheduling،
  • Fixed-Function Units،
  • Power،
  • Cooling،
  • و Software

است.


Balanced GPU

Compute
   ↕
Memory
   ↕
Scheduling
   ↕
Specialized Units
   ↕
Power
   ↕
Software

Performance واقعی
حاصل تعادل معماری است،
نه رکورد زدن در یک Specification.

اگر فقط یک Checklist از کل کتاب یادتان بماند

  • ابتدا Workload را مشخص کنید.
  • Benchmark همان Workload را بررسی کنید.
  • VRAM Capacity را متناسب با نیاز انتخاب کنید.
  • Memory Bandwidth را با VRAM Capacity اشتباه نگیرید.
  • Core Count را فقط داخل Context معماری تفسیر کنید.
  • TFLOPS را معادل FPS ندانید.
  • Average FPS را همراه Frame Time بررسی کنید.
  • Power و Cooling را برای Sustained Performance در نظر بگیرید.
  • PCIe را جدا از VRAM Interface تحلیل کنید.
  • در Performance Problem ابتدا Bottleneck را پیدا کنید.
  • هر بار فقط یک Variable را تغییر دهید.
  • Profiling را جایگزین حدس زدن کنید.
  • Driver و Software را بخشی از Performance بدانید.
  • برای خرید، Performance واقعی را با قیمت و مصرف توان کنار هم ببینید.

سوالات نهایی درباره GPU

GPU چیست؟

GPU
پردازنده ای بسیار موازی است
که برای پردازش حجم بزرگی
از کارهای قابل Parallelization
با Throughput بالا طراحی شده است.

مهم ترین بخش GPU چیست؟

یک بخش واحد وجود ندارد.

Compute،
Memory،
Scheduling،
Cache،
Fixed-Function Hardware
و Software
همگی بخشی از سیستم هستند.

آیا Core بیشتر یعنی GPU سریع تر؟

نه لزوما.

Core Count
باید در Context همان معماری،
Clock،
Memory
و Workload بررسی شود.

آیا VRAM بیشتر یعنی FPS بیشتر؟

نه.

VRAM بیشتر
ظرفیت حافظه بیشتری ایجاد می کند.

اگر Workload
از قبل در VRAM موجود جا شود،
افزایش ظرفیت
الزاما FPS را افزایش نمی دهد.

مهم ترین مشخصه برای Gaming چیست؟

یک مشخصه واحد وجود ندارد.

Benchmark واقعی
در بازی،
Resolution
و تنظیمات مورد نظر
بهترین نقطه شروع است.

مهم ترین مشخصه برای AI چیست؟

بسته به مدل،
VRAM Capacity،
Memory Bandwidth،
Matrix Throughput،
Precision Support
و Software Ecosystem
می توانند مهم باشند.

چرا دو GPU با TFLOPS مشابه Performance متفاوت دارند؟

چون معماری،
Memory System،
Cache،
Instruction Behavior،
Fixed-Function Units
و Software
می توانند متفاوت باشند.

چرا GPU Usage بالا ولی FPS پایین است؟

زیرا GPU ممکن است
واقعا توسط Workload محدود شده باشد،
اما Metric عمومی Usage
نوع Bottleneck را مشخص نمی کند.

برای تشخیص دقیق تر
باید Frame Time
و Profiling بررسی شوند.

Ray Tracing فقط به RT Hardware وابسته است؟

خیر.

Shader Units،
Memory،
Cache،
Acceleration Structure،
Denoising
و Software نیز
در Performance نقش دارند.

آیا Driver واقعا روی Performance اثر دارد؟

بله.

Compiler،
Scheduling،
Compatibility،
Command Handling
و Optimizationهای Driver
می توانند روی رفتار واقعی Workload
اثر بگذارند.

چطور بفهمیم چه چیزی Bottleneck است؟

اندازه گیری کنید،
یک Variable را تغییر دهید،
Metricهای مرتبط را بررسی کنید
و از Profiler مناسب استفاده کنید.

حدس زدن
جای Profiling را نمی گیرد.

برای انتخاب GPU از کجا شروع کنیم؟

از Workload.

ابتدا مشخص کنید
GPU را برای Gaming،
Rendering،
AI،
Compute
یا کاربرد دیگری می خواهید.

سپس Benchmark
و نیازهای همان Workload
را بررسی کنید.

خلاصه نهایی کل کتاب GPU

  • GPU برای Parallel Throughput بالا طراحی شده است.
  • Threadها در گروه های اجرایی مانند Warp یا Wave مدیریت می شوند.
  • Scheduler تلاش می کند همیشه کار آماده برای اجرا داشته باشد.
  • Latency Hiding یکی از مکانیزم های بنیادی Performance GPU است.
  • Occupancy ابزار ایجاد Parallelism است، نه هدف نهایی Performance.
  • Registers، Shared Memory، Cache و VRAM یک Memory Hierarchy می سازند.
  • VRAM Capacity و Memory Bandwidth دو مفهوم متفاوت هستند.
  • Graphics Pipeline Geometry را به Frame تبدیل می کند.
  • Rasterizer، Texture Unit و Render Output نمونه های Fixed-Function Hardware هستند.
  • Shader Stageها الزاما Coreهای فیزیکی جداگانه نیستند.
  • Ray Tracing از Acceleration Structure برای کاهش Intersection Work استفاده می کند.
  • Path Tracing با Sampling مسیرهای نور را تخمین می زند.
  • AI Workloadها از Parallelism و Matrix Hardware GPU استفاده می کنند.
  • TFLOPS فقط Peak Compute را توصیف می کند.
  • Core Count میان معماری های مختلف قابل مقایسه مستقیم نیست.
  • Benchmark واقعی برای Workload مشخص مهم تر از یک Specification منفرد است.
  • Bottleneck می تواند در Compute، Memory، CPU، Texture، Geometry یا سایر مراحل باشد.
  • رفع یک Bottleneck می تواند Bottleneck دیگری را آشکار کند.
  • Power و Cooling روی Clock و Performance پایدار اثر دارند.
  • PCIe مسیر ارتباط GPU با سیستم است و با VRAM Bandwidth تفاوت دارد.
  • FPS، Frame Time و Refresh Rate سه Metric متفاوت هستند.
  • Driver، Compiler و Software Stack بخشی واقعی از Performance هستند.
  • GPU خوب یک مجموعه متعادل از Compute، Memory، Scheduling و Specialized Hardware است.
  • بهترین GPU محصولی است که برای Workload مورد نظر بهترین تعادل Performance، Capacity، Power و Price را ارائه کند.

نقشه نهایی دانش GPU


GPU

├── Architecture
│   ├── Compute Units
│   ├── Scheduling
│   ├── Execution Model
│   └── Specialized Hardware
│
├── Memory
│   ├── Registers
│   ├── Shared / Local Memory
│   ├── Cache
│   ├── VRAM
│   └── Bandwidth / Latency
│
├── Graphics
│   ├── Vertex Processing
│   ├── Rasterization
│   ├── Pixel Shading
│   ├── Texture Sampling
│   └── Render Output
│
├── Ray Tracing
│   ├── Rays
│   ├── BVH
│   ├── Traversal
│   ├── Intersection
│   └── Path Tracing
│
├── AI
│   ├── Matrix Operations
│   ├── Precision
│   ├── Training
│   └── Inference
│
├── Performance
│   ├── Throughput
│   ├── Latency
│   ├── Occupancy
│   ├── Utilization
│   └── Bottlenecks
│
├── Physical Design
│   ├── Power
│   ├── Temperature
│   ├── Cooling
│   └── Form Factor
│
└── Software
    ├── API
    ├── Driver
    ├── Compiler
    ├── Command Submission
    └── Profiling

اگر این کتاب را کامل خوانده باشید…

اکنون باید بتوانید
وقتی مشخصات یک GPU،
Benchmark،
بازی،
AI Accelerator
یا Performance Report
را می بینید،
فقط به اعداد نگاه نکنید.

باید بتوانید بپرسید:

  • Workload چیست؟
  • کدام بخش GPU درگیر است؟
  • داده کجا قرار دارد؟
  • چه چیزی محدودکننده Throughput است؟
  • Memory یا Compute کدام مهم تر است؟
  • آیا Bottleneck در GPU است یا خارج از GPU؟
  • Metric مورد استفاده دقیقا چه چیزی را اندازه می گیرد؟
  • آیا Benchmark با کاربرد واقعی من مرتبط است؟

اگر بتوانید
به این سوال ها پاسخ دهید،
دیگر GPU
برای شما فقط یک جدول Specification نیست؛
بلکه یک سیستم قابل تحلیل است.


سطح: مرجع سریع

پیش نیاز:
ندارد

موضوع:
GPU Glossary & Terminology

کاربرد:
مرور سریع اصطلاحات کلیدی کتاب


GPU MASTER GLOSSARY

واژه نامه جامع GPU

در دنیای GPU
بسیاری از اصطلاحات
به ظاهر مشابه هستند،
اما معنای فنی متفاوتی دارند.

این واژه نامه
مهم ترین اصطلاحات معماری،
حافظه،
Graphics،
Ray Tracing،
AI،
Performance،
Display
و Software Stack
را در یک مرجع واحد
جمع آوری می کند.

A

Acceleration Structure

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

BVH
یکی از رایج ترین نمونه هاست.

ALU — Arithmetic Logic Unit

واحدی برای اجرای
عملیات محاسباتی
مانند Arithmetic
و برخی عملیات منطقی.

Anisotropic Filtering

روش Texture Filtering
برای بهبود کیفیت Textureهایی
که با زاویه زیاد
یا Perspective شدید
دیده می شوند.

API — Application Programming Interface

رابطی که Application
از طریق آن
عملیات Graphics یا Compute
را تعریف می کند.

Direct3D،
Vulkan
و OpenGL
نمونه هایی از Graphics API هستند.

Async Compute

اجرای یا هم پوشانی
Compute Work
با انواع دیگر GPU Work
در صورت پشتیبانی معماری
و وجود شرایط مناسب.

B

Back Buffer

Bufferی که Frame جدید
در آن آماده می شود
پیش از اینکه برای نمایش
Present شود.

Bandwidth

مقدار داده ای
که در واحد زمان
می تواند از یک مسیر
منتقل شود.

Barrier

مکانیزمی برای
Synchronization
و کنترل ترتیب
دسترسی یا اجرای عملیات.

Bilinear Filtering

روش Texture Filtering
که معمولا چند Texel مجاور
را برای محاسبه Sample
ترکیب می کند.

Blend / Blending

ترکیب نتیجه Fragment جدید
با مقدار موجود
در Render Target
بر اساس Blend State.

Block

در برخی Compute Modelها
گروهی از Threadها
که می توانند
Resourceهای محلی مشخصی
را به اشتراک بگذارند.

Bottleneck

بخشی از سیستم
که در یک Workload مشخص
Performance را محدود می کند.

BVH — Bounding Volume Hierarchy

ساختار سلسله مراتبی
از Bounding Volumeها
برای کاهش جستجوی لازم
در Ray Traversal.

C

Cache

حافظه سریع تر
برای نگهداری موقت
داده های پرکاربرد
و کاهش دسترسی
به حافظه دورتر.

Cache Hit

حالتی که داده مورد نیاز
در Cache پیدا می شود.

Cache Miss

حالتی که داده
در Cache موجود نیست
و باید از سطح دیگری
در Memory Hierarchy
خوانده شود.

Clock

نرخ فعالیت
بخش های زمان بندی شده مدار.

Clock بالاتر
به تنهایی
معادل Performance بالاتر نیست.

Coalescing

سازمان دهی مناسب
Memory Accessهای Threadهای مجاور
به شکلی که
تراکنش های حافظه
کارآمدتر شوند.

Command Buffer

ساختاری شامل مجموعه ای
از Commandهای GPU
که برای اجرا
آماده و Submit می شوند.

Command Queue

صفی که GPU Work
برای اجرا
به آن Submit می شود.

Compute-Bound

شرایطی که Performance
بیشتر توسط ظرفیت محاسباتی GPU
محدود شده است.

Compute Shader

Shader قابل برنامه ریزی
برای اجرای General-Purpose
Data-Parallel Work
در Graphics APIها.

CUDA

Platform و Programming Model
شرکت NVIDIA
برای General-Purpose GPU Computing.

D

Denoising

فرایند کاهش Noise
از تصویر،
خصوصا در Renderingهایی
که تعداد Sample محدود دارند.

Depth Buffer

Bufferی برای نگهداری
اطلاعات Depth
و تعیین Visibility
در Rendering.

Depth Test

آزمایشی برای تعیین اینکه
Fragment جدید
از نظر Depth
باید پذیرفته شود یا خیر.

Dispatch

دستور آغاز
یک Compute Workload
روی GPU.

Display Engine

بخشی از GPU
برای مدیریت
Display Pipeline،
Scanout
و خروجی تصویر.

DisplayPort

رابط دیجیتال
برای انتقال
Display Data.

Divergence

حالتی که Threadهای
یک گروه اجرایی
مسیرهای کنترلی متفاوتی
را دنبال می کنند.

Double Buffering

استفاده از دو Buffer
برای جدا کردن
Frame در حال نمایش
از Frame در حال آماده سازی.

Draw Call

دستوری برای اجرای
یک عملیات Rendering
با Geometry،
Pipeline State
و Resourceهای مشخص.

F

Fence

مکانیزم Synchronization
برای مشخص کردن
پیشرفت یا تکمیل
GPU Work.

Fragment

داده ای که
در Rasterization
برای یک Sample Location
یا Pixel Candidate
تولید می شود
و می تواند وارد
Fragment Processing شود.

Fragment Shader

نام رایج Shader Stage
برای محاسبه اطلاعات Fragment،
خصوصا در OpenGL و Vulkan.

Frame

یک تصویر کامل
در زنجیره Rendering
و Presentation.

Frame Buffer

ناحیه ای از حافظه
برای نگهداری
اطلاعات مرتبط
با Frame.

Frame Time

زمان لازم
برای تولید یا پردازش
یک Frame
در Context اندازه گیری مورد نظر.

FPS — Frames Per Second

تعداد Frameهای تولید شده
در یک ثانیه.

Front Buffer

به صورت مفهومی،
Bufferی که تصویر
در حال نمایش
از آن گرفته می شود.

G

Geometry

داده های هندسی
مانند Vertexها،
Triangleها
و Primitiveهای یک Scene.

Global Memory

در Compute Programming،
حافظه ای با Scope گسترده
که Threadهای مختلف
می توانند به آن دسترسی داشته باشند.

در GPUهای مجزا
این داده ها معمولا
در Memory System
متصل به GPU قرار می گیرند.

GPU — Graphics Processing Unit

پردازنده ای با Parallelism گسترده
که برای Graphics
و بسیاری از Compute Workloadها
استفاده می شود.

H

HDMI

رابط دیجیتال
برای انتقال تصویر
و در بسیاری از کاربردها
صدا.

HDR — High Dynamic Range

مجموعه ای از فناوری ها
برای نمایش دامنه گسترده تر
روشنایی و رنگ
در یک زنجیره سازگار.

HLSL

High-Level Shader Language
برای نوشتن Shaderها
در اکوسیستم DirectX
و برخی Toolchainهای دیگر.

I

Inference

مرحله استفاده
از مدل آموزش دیده
برای تولید Prediction
یا Output.

Instruction

عملیات قابل اجرا
توسط واحدهای پردازشی GPU.

Intersection

در Ray Tracing،
بررسی برخورد Ray
با Primitive
یا Bounding Volume.

L

Latency

زمان لازم
برای تکمیل
یک عملیات مشخص.

Latency Hiding

پنهان کردن زمان انتظار
یک گروه کاری
با اجرای Work آماده دیگر.

LOD — Level of Detail

استفاده از سطح جزئیات متفاوت
بر اساس نیاز Rendering،
فاصله
یا شرایط Scene.

M

Memory Bandwidth

حداکثر نرخ نظری
انتقال داده
میان GPU
و حافظه متصل به آن
در شرایط تعریف شده.

Memory-Bound

حالتی که Performance
بیشتر توسط
Memory System
محدود می شود
تا ظرفیت محاسباتی.

Memory Bus Width

عرض رابط داده
میان Memory Controller
و Memory Devices.

Memory Controller

بخشی از GPU
برای مدیریت
تراکنش های حافظه.

Memory Hierarchy

مجموعه سطوح مختلف حافظه
با تفاوت در
Capacity،
Latency،
Bandwidth
و Scope.

Mip / Mipmap

نسخه های از پیش محاسبه شده
یک Texture
در Resolutionهای مختلف
برای Sampling مناسب تر.

O

Occupancy

معیاری مرتبط با
مقدار Work مقیم
روی منابع اجرایی GPU
نسبت به ظرفیت معماری.

Occupancy بالا
الزاما به معنی
Performance بالاتر نیست.

OpenCL

Framework و API
برای Parallel Computing
روی انواع مختلف
Compute Deviceها.

OpenGL

Graphics API
برای Rendering
که در پلتفرم های مختلف
استفاده شده است.

P

Path Tracing

روش Rendering
مبتنی بر نمونه برداری
از مسیرهای انتقال نور.

PCI Express — PCIe

رابط ارتباطی پرسرعت
برای اتصال GPU
و سایر Deviceها
به سیستم.

Pixel

واحد تصویری
در فضای نهایی Display
یا Image.

Pixel Shader

نام رایج Fragment Processing Shader
در Direct3D.

Pipeline

مجموعه ای از مراحل
که داده
به ترتیب یا با هم پوشانی
از آنها عبور می کند.

Pipeline State

مجموعه تنظیمات
و Shaderهایی
که رفتار Graphics Pipeline
را مشخص می کنند.

Power Limit

محدودیتی مرتبط با
توان قابل استفاده GPU
که می تواند
بر Clock و Performance
اثر بگذارد.

Primitive

واحد هندسی
مانند Triangle،
Line
یا Point
در Graphics Pipeline.

Profiler

ابزار اندازه گیری
و تحلیل Performance
برای پیدا کردن
Bottleneckها
و رفتار Workload.

R

Rasterization

فرایند تبدیل Primitiveهای هندسی
به Coverage
و Fragmentهای مرتبط
با فضای تصویر.

Rasterizer

بخش Fixed-Function
برای انجام
Rasterization.

Ray

در Ray Tracing،
یک مسیر ریاضی
با Origin
و Direction
برای بررسی Scene.

Ray Tracing

روش Rendering
بر پایه دنبال کردن Rayها
و بررسی تعامل آنها
با Scene.

Register

حافظه بسیار سریع
نزدیک به Execution Units
برای نگهداری مقادیر موقت
Threadها.

Register Pressure

میزان تقاضای Shader
برای Registerها.

مصرف زیاد Register
می تواند
تعداد Workهای مقیم
را محدود کند.

Render Target

Resourceی که
خروجی Rendering
در آن نوشته می شود.

Resolution

تعداد Pixelهای تصویر
در ابعاد افقی و عمودی.

ROP / Render Output

سخت افزار مرتبط با
مراحل نهایی
نوشتن Pixel،
Depth،
Stencil
و Blending.

Runtime

لایه نرم افزاری
که بخشی از مدیریت
اجرای API یا Compute Framework
را انجام می دهد.

S

Sample

یک نقطه یا نمونه
برای ارزیابی
رنگ،
Texture،
Lighting
یا سایر داده ها.

Scheduler

منطق سخت افزاری یا نرم افزاری
برای انتخاب و زمان بندی
Work قابل اجرا.

Scanout

فرایند خواندن
اطلاعات Frame
برای ارسال به Display.

Semaphore

مکانیزم Synchronization
برای هماهنگی
میان عملیات یا Queueها.

Shader

برنامه ای
که روی GPU
برای پردازش داده های Graphics
یا Compute اجرا می شود.

Shader Cache

محلی برای نگهداری
نتایج Compilation
به منظور کاهش
Compilation تکراری.

Shader Compilation

فرایند تبدیل Shader Code
به Representation
یا Machine Code مناسب
برای اجرا.

Shared Memory

حافظه سریع On-Chip
که گروهی از Threadها
می توانند برای
Data Sharing
و Data Reuse
استفاده کنند.

SIMD

Single Instruction,
Multiple Data.

مدلی که یک Instruction
روی چند Data Element
اعمال می شود.

SIMT

Single Instruction,
Multiple Threads.

مدل مفهومی رایج
برای توضیح اجرای
گروهی Threadها
در GPU.

Stencil Buffer

Bufferی برای نگهداری
Stencil Valueها
و کنترل برخی عملیات
Rendering.

Stutter

وقفه یا ناهماهنگی محسوس
در تحویل Frameها
که معمولا
با Frame-Time Spike
همراه است.

Swap Chain

مجموعه Bufferها
و سازوکار Presentation
برای تحویل Frameها
به Display System.

Synchronization

هماهنگ سازی
ترتیب و Dependency
میان Workهای مختلف.

T

Tensor

ساختار داده چندبعدی
که در Machine Learning
و عملیات عددی
به طور گسترده استفاده می شود.

Texel

عنصر داده
در Texture.

Texel
الزاما معادل Pixel صفحه نیست.

Texture

Resource داده ای
که معمولا
برای ذخیره اطلاعات تصویری
یا داده های قابل Sampling
استفاده می شود.

Texture Filtering

روش محاسبه Sample
از Texture
هنگامی که Coordinate
دقیقا روی یک Texel
قرار ندارد
یا مقیاس تصویر تغییر کرده است.

Texture Unit

سخت افزار تخصصی
برای Texture Addressing،
Sampling
و Filtering.

TFLOPS

Trillion Floating-Point Operations
Per Second.

یک Metric نظری
برای Peak Floating-Point Throughput
در Precision و شرایط مشخص.

Thermal Throttling

کاهش Clock
یا Performance
برای نگه داشتن سیستم
در محدوده حرارتی مجاز.

Thread

یک واحد منطقی
از اجرای برنامه
در Programming Model.

Throughput

مقدار کاری
که در واحد زمان
قابل پردازش است.

Tile

بخشی از تصویر
یا فضای داده
که برای پردازش
به یک Region کوچک تر
تقسیم شده است.

Trilinear Filtering

Texture Filtering
که معمولا
نتایج Bilinear Sampling
از دو Mip Level
را ترکیب می کند.

Triple Buffering

استفاده از Buffer اضافی
در Presentation Pipeline
برای ایجاد انعطاف بیشتر
میان Rendering
و Display Timing.

U

Utilization

میزان استفاده
از یک Resource
در بازه زمانی مشخص.

Utilization
با Occupancy
یک مفهوم نیست.

V

Vertex

نقطه ای از Geometry
که می تواند
اطلاعاتی مانند Position،
Normal،
Color
و Texture Coordinate
داشته باشد.

Vertex Shader

Shader Stage
برای پردازش Vertexها
در Graphics Pipeline.

VRAM — Video Memory

حافظه محلی
مورد استفاده GPU
برای نگهداری Resourceها،
Textureها،
Buffers
و داده های محاسباتی.

VRR — Variable Refresh Rate

قابلیتی که
Refresh Timing نمایشگر
را در محدوده پشتیبانی شده
با زمان تحویل Frameها
هماهنگ تر می کند.

V-Sync

Vertical Synchronization.

مکانیزمی برای هماهنگی
Presentation
با Timing نمایشگر
با هدف کاهش Tearing.

Vulkan

Graphics و Compute API
با کنترل نسبتا صریح
روی Resource Management،
Synchronization
و Command Submission.

W

Warp

نام NVIDIA
برای یک گروه
از Threadها
که به صورت گروهی
توسط سخت افزار
Schedule و اجرا می شوند.

Wave / Wavefront

اصطلاحی برای
گروه اجرایی Threadها
در برخی معماری ها
و APIها.

Workgroup

گروهی از Threadها
در Compute Programming Model
که می توانند
Resourceها و Synchronization
در سطح گروه
داشته باشند.

Workload

مجموعه کاری
که GPU
در یک Application
یا Benchmark
باید انجام دهد.

تفاوت اصطلاحاتی که بیشتر با هم اشتباه می شوند

اصطلاح اول اصطلاح دوم تفاوت اصلی
VRAM Capacity Memory Bandwidth Capacity مقدار فضای ذخیره سازی است؛ Bandwidth نرخ انتقال داده.
Latency Throughput Latency زمان یک عملیات است؛ Throughput حجم کار در واحد زمان.
Occupancy Utilization Occupancy به Work مقیم مرتبط است؛ Utilization میزان استفاده واقعی از Resource را توصیف می کند.
Pixel Texel Pixel عنصر تصویر است؛ Texel عنصر Texture.
FPS Hz FPS نرخ تولید Frame است؛ Hz نرخ Refresh نمایشگر.
Frame Time Input Latency Frame Time زمان مرتبط با تولید Frame است؛ Input Latency زنجیره بزرگ تری از Input تا نتیجه قابل مشاهده را دربر می گیرد.
Shader Shader Core Shader برنامه است؛ Shader Core اصطلاح عمومی برای Hardware Execution Resource است.
Ray Tracing Path Tracing Path Tracing یک روش Rendering مبتنی بر دنبال کردن مسیرهای نور و نمونه برداری است؛ Ray Tracing مفهوم گسترده تری است.
PCIe Bandwidth VRAM Bandwidth اولی ارتباط GPU با سیستم است؛ دومی مسیر Memory System محلی GPU.
Power Limit Thermal Limit یکی محدودیت توان است؛ دیگری محدودیت ناشی از شرایط حرارتی.
Peak Performance Real Performance Peak ظرفیت نظری است؛ Real Performance نتیجه Workload واقعی.
Core Count Performance Core Count یک مشخصه معماری است و به تنهایی نتیجه Performance را تعیین نمی کند.

اختصارات مهم GPU

اختصار معنا
GPU Graphics Processing Unit
VRAM Video Random Access Memory / Video Memory
ALU Arithmetic Logic Unit
SIMD Single Instruction, Multiple Data
SIMT Single Instruction, Multiple Threads
BVH Bounding Volume Hierarchy
ROP Raster Operations / Render Output terminology depending on architecture and context
TMU Texture Mapping Unit
LOD Level of Detail
FPS Frames Per Second
VRR Variable Refresh Rate
HDR High Dynamic Range
API Application Programming Interface
PCIe Peripheral Component Interconnect Express
HLSL High-Level Shader Language
GLSL OpenGL Shading Language
TFLOPS Trillion Floating-Point Operations Per Second

نقشه ذهنی اصطلاحات


GPU

├── Execution
│   ├── Thread
│   ├── Warp / Wave
│   ├── Scheduler
│   ├── Register
│   ├── Occupancy
│   └── Divergence
│
├── Memory
│   ├── Cache
│   ├── Shared Memory
│   ├── VRAM
│   ├── Bandwidth
│   └── Latency
│
├── Graphics
│   ├── Vertex
│   ├── Primitive
│   ├── Rasterization
│   ├── Fragment
│   ├── Texture
│   ├── Depth
│   └── Blending
│
├── Ray Tracing
│   ├── Ray
│   ├── BVH
│   ├── Traversal
│   ├── Intersection
│   ├── Path Tracing
│   └── Denoising
│
├── AI
│   ├── Tensor
│   ├── Matrix Operations
│   ├── Training
│   └── Inference
│
├── Performance
│   ├── FPS
│   ├── Frame Time
│   ├── Throughput
│   ├── Utilization
│   └── Bottleneck
│
├── Display
│   ├── Frame Buffer
│   ├── Swap Chain
│   ├── V-Sync
│   ├── VRR
│   ├── HDMI
│   └── DisplayPort
│
└── Software
    ├── API
    ├── Driver
    ├── Compiler
    ├── Command Buffer
    ├── Queue
    └── Synchronization

نکته پایانی

هدف این واژه نامه
حفظ کردن مجموعه ای از کلمات نیست.

هدف این است
که هنگام خواندن
Specification،
Benchmark،
مقاله فنی،
Driver Documentation
یا GPU Architecture Diagram،
بتوانید تشخیص دهید
هر اصطلاح
به کدام بخش سیستم اشاره می کند.

وقتی واژه ها را درست از هم جدا کنیم،
تحلیل GPU بسیار ساده تر می شود.

سطح: مرجع نهایی

پیش نیاز:
تمام فصل های کتاب GPU

موضوع:
GPU Master Index

کاربرد:
دسترسی سریع به تمام مفاهیم اصلی کتاب


GPU MASTER INDEX

Master Index و نقشه کامل کتاب GPU

این بخش
نقشه نهایی کل کتاب است.

هدف آن
این است که خواننده
بعد از مطالعه کتاب
بتواند هر مفهوم را
در جای درست خود
در معماری GPU قرار دهد
و برای مرور دوباره
سریع به موضوع مورد نظر برسد.


نقشه سریع

کل مباحث GPU
را می توان
در چند خانواده بزرگ قرار داد:

  • معماری پایه GPU،
  • Execution Architecture،
  • Memory Architecture،
  • Graphics Pipeline،
  • Ray Tracing،
  • AI Acceleration،
  • Performance Analysis،
  • Power و Cooling،
  • System Interface،
  • Display Pipeline،
  • و Software Stack.

نقشه کامل GPU


GPU KNOWLEDGE MAP

GPU
│
├── 1. Core Architecture
│   │
│   ├── Parallel Processing
│   ├── Compute Units
│   ├── Execution Units
│   ├── ALU
│   ├── Specialized Units
│   └── Fixed-Function Hardware
│
├── 2. Execution Architecture
│   │
│   ├── Thread
│   ├── Workgroup / Block
│   ├── Warp / Wave
│   ├── Scheduler
│   ├── Occupancy
│   ├── Divergence
│   ├── Register Pressure
│   ├── Latency Hiding
│   └── Throughput
│
├── 3. Memory Architecture
│   │
│   ├── Register
│   ├── Shared / Local Memory
│   ├── Cache
│   ├── VRAM
│   ├── Memory Controller
│   ├── Memory Bus
│   ├── Memory Bandwidth
│   ├── Latency
│   ├── Memory Access Pattern
│   └── HBM / GDDR
│
├── 4. Graphics Pipeline
│   │
│   ├── Vertex
│   ├── Vertex Shader
│   ├── Primitive
│   ├── Geometry Processing
│   ├── Tessellation
│   ├── Geometry Shader
│   ├── Mesh Shader
│   ├── Rasterization
│   ├── Fragment
│   ├── Pixel Shader
│   ├── Texture Unit
│   ├── Mipmap
│   ├── Filtering
│   ├── Depth
│   ├── Stencil
│   ├── Blending
│   └── ROP / Render Output
│
├── 5. Ray Tracing
│   │
│   ├── Ray
│   ├── Intersection
│   ├── Acceleration Structure
│   ├── BVH
│   ├── Traversal
│   ├── Closest Hit
│   ├── Miss
│   ├── Shadow Ray
│   ├── Reflection
│   ├── Refraction
│   ├── Bounce
│   ├── Denoising
│   └── Path Tracing
│
├── 6. AI Acceleration
│   │
│   ├── Tensor
│   ├── Matrix Multiplication
│   ├── Multiply-Accumulate
│   ├── Matrix Hardware
│   ├── Precision
│   ├── Mixed Precision
│   ├── Training
│   ├── Inference
│   └── AI Reconstruction
│
├── 7. Performance
│   │
│   ├── FLOPS / TFLOPS
│   ├── Clock
│   ├── Core Count
│   ├── Texture Rate
│   ├── Pixel Rate
│   ├── FPS
│   ├── Frame Time
│   ├── Utilization
│   ├── Occupancy
│   ├── Performance per Watt
│   └── Benchmarking
│
├── 8. Bottlenecks
│   │
│   ├── CPU-Bound
│   ├── GPU-Bound
│   ├── Compute-Bound
│   ├── Memory-Bound
│   ├── Texture-Bound
│   ├── Geometry-Bound
│   ├── Pixel-Bound
│   ├── VRAM Capacity
│   ├── PCIe Transfer
│   └── Software Bottleneck
│
├── 9. Power & Thermal
│   │
│   ├── Power Consumption
│   ├── Voltage
│   ├── Clock
│   ├── Power Limit
│   ├── Thermal Limit
│   ├── Throttling
│   ├── Boost
│   ├── Undervolting
│   ├── Overclocking
│   └── Performance per Watt
│
├── 10. Physical Design
│   │
│   ├── PCB
│   ├── VRM
│   ├── Heatsink
│   ├── Heatpipe
│   ├── Vapor Chamber
│   ├── Open-Air Cooler
│   ├── Blower
│   ├── Liquid Cooling
│   ├── Slot Width
│   └── Case Airflow
│
├── 11. System Interface
│   │
│   ├── PCIe
│   ├── PCIe Lane
│   ├── PCIe Generation
│   ├── x16 / x8 / x4
│   ├── Resizable BAR
│   ├── CPU-GPU Transfer
│   └── System Memory
│
├── 12. Display
│   │
│   ├── Frame Buffer
│   ├── Back Buffer
│   ├── Swap Chain
│   ├── Presentation
│   ├── Scanout
│   ├── Refresh Rate
│   ├── V-Sync
│   ├── VRR
│   ├── HDMI
│   ├── DisplayPort
│   └── HDR
│
└── 13. Software Stack
    │
    ├── Application
    ├── Graphics API
    ├── Compute API
    ├── Driver
    ├── Runtime
    ├── Compiler
    ├── Shader Compilation
    ├── Command Buffer
    ├── Command Queue
    ├── Synchronization
    └── Profiler

1. Core Architecture

  • GPU چیست و چرا برای Parallel Processing مناسب است.
  • تفاوت معماری کلی CPU و GPU.
  • Compute Unitها چگونه منابع GPU را سازمان دهی می کنند.
  • Execution Unitها چه کاری انجام می دهند.
  • Fixed-Function Hardware چرا در کنار Shader Hardware وجود دارد.
  • چرا GPU یک سیستم Hybrid است.

2. Execution Architecture

Thread

واحد منطقی اجرای Work.

Warp / Wave

گروه اجرایی Threadها.

Scheduler

انتخاب Work آماده برای اجرا.

Occupancy

مقدار Work مقیم نسبت به ظرفیت.

Divergence

تفاوت مسیر کنترلی Threadهای یک گروه.

Latency Hiding

اجرای Work دیگر هنگام انتظار یک Warp.

3. Memory Architecture


Fast / Small

Registers

   │
   ▼

Shared / Local Memory

   │
   ▼

Cache

   │
   ▼

VRAM

   │
   ▼

System Memory

Slow / Large
  • Register سریع ترین فضای کاری Thread است.
  • Shared Memory برای Data Sharing و Reuse مفید است.
  • Cache فاصله میان Compute و VRAM را کاهش می دهد.
  • VRAM حافظه محلی اصلی GPU است.
  • Memory Bandwidth و Capacity دو مفهوم متفاوت هستند.
  • Access Pattern روی استفاده موثر از حافظه اثر دارد.
  • Cache Hit و Cache Miss می توانند رفتار Performance را تغییر دهند.

4. Graphics Pipeline


Vertex Data

   │
   ▼

Vertex Processing

   │
   ▼

Primitive Processing

   │
   ▼

Rasterization

   │
   ▼

Fragment Processing

   │
   ▼

Texture Sampling

   │
   ▼

Depth / Stencil

   │
   ▼

Blending

   │
   ▼

Render Output

   │
   ▼

Frame

5. Ray Tracing


Ray

 │
 ▼

BVH Traversal

 │
 ▼

Intersection

 │
 ▼

Hit / Miss

 │
 ▼

Shading

 │
 ├── Reflection
 │
 ├── Shadow
 │
 └── Refraction

 │
 ▼

Possible New Rays

مفهوم مرکزی Ray Tracing
کاهش تعداد تست های غیرضروری
با استفاده از
Acceleration Structure
است.

6. AI Acceleration


Tensor Data

    │
    ▼

Matrix Operations

    │
    ▼

Compute / Matrix Hardware

    │
    ▼

Memory System

    │
    ▼

Next Layer
  • AI Workloadها اغلب Matrix-heavy هستند.
  • Precision روی Throughput و Memory Usage اثر دارد.
  • Training و Inference نیازهای متفاوتی دارند.
  • VRAM Capacity برای Model Working Set اهمیت دارد.
  • Memory Bandwidth برای تغذیه Matrix Hardware مهم است.

7. Performance Metrics

Metric پرسش اصلی
TFLOPS Peak Compute چقدر است؟
Memory Bandwidth داده با چه نرخ نظری منتقل می شود؟
VRAM Capacity چه مقدار داده می تواند محلی نگهداری شود؟
FPS چند Frame در ثانیه تولید می شود؟
Frame Time هر Frame چقدر زمان نیاز دارد؟
Utilization Resource چقدر مشغول بوده است؟
Occupancy چه مقدار Work می تواند هم زمان مقیم باشد؟
Performance per Watt در برابر توان مصرفی چه Performanceای تولید می شود؟

8. Bottleneck Analysis


Performance Problem

        │
        ▼

Measure

        │
        ▼

CPU or GPU?

        │
        ▼

Which GPU Resource?

        │
        ├── Compute
        ├── Memory
        ├── Texture
        ├── Geometry
        ├── Pixel
        ├── Ray Tracing
        └── Transfer

        │
        ▼

Optimize

        │
        ▼

Measure Again

9. Power، Temperature و Cooling


Voltage
   +
Clock
   +
Activity

   │
   ▼

Power

   │
   ▼

Heat

   │
   ▼

Cooling

   │
   ▼

Temperature

   │
   ▼

Boost / Throttling

   │
   ▼

Sustained Performance

10. اتصال GPU به سیستم


CPU

 │
 ▼

System Memory

 │
 ▼

PCIe

 │
 ▼

GPU

 │
 ▼

VRAM

PCIe
برای ارتباط GPU با سیستم است.

VRAM Interface
برای ارتباط GPU
با حافظه محلی خود است.

این دو
نباید با یکدیگر اشتباه شوند.

11. Display Pipeline


Rendered Frame

      │
      ▼

Swap Chain

      │
      ▼

Present

      │
      ▼

Display Engine

      │
      ▼

Scanout

      │
      ▼

HDMI / DisplayPort

      │
      ▼

Monitor

12. Software Stack


Application

      │
      ▼

Engine

      │
      ▼

Graphics / Compute API

      │
      ▼

Runtime

      │
      ▼

Driver

      │
      ▼

Compiler / Command Submission

      │
      ▼

GPU Hardware

اگر سوال شما این است، به کدام بخش نگاه کنیم؟

سوال بخش مرتبط
چرا GPU این قدر Parallel است؟ Execution Architecture
چرا Branch می تواند Performance را کاهش دهد؟ Divergence
چرا Register زیاد مشکل ایجاد می کند؟ Register Pressure / Occupancy
چرا Memory Access کند است؟ Memory Hierarchy / Cache / Latency
چرا VRAM بیشتر همیشه FPS را زیاد نمی کند؟ Capacity vs Performance
چرا Resolution بالا FPS را کم می کند؟ Pixel Work / Memory Traffic
چرا Texture Filtering هزینه دارد؟ Texture Units
چرا Ray Tracing سنگین است؟ Traversal / Intersection / Shading
چرا Path Tracing Noise دارد؟ Sampling / Denoising
چرا AI به VRAM زیاد نیاز دارد؟ Weights / Activations / Working Set
چرا TFLOPS دو GPU نتیجه یکسانی نمی دهد؟ Architecture / Bottleneck / Workload
چرا GPU Usage صد درصد است؟ Utilization / Bottleneck Analysis
چرا GPU با گذشت زمان کندتر می شود؟ Power / Thermal / Sustained Clock
چرا دو کارت با Chip یکسان دمای متفاوت دارند؟ Cooling / PCB / Power Limit
چرا PCIe x16 همیشه x16 واقعی نیست؟ Physical vs Electrical Lanes
چرا 144 Hz همان 144 FPS نیست؟ Display Pipeline
چرا Driver روی Performance اثر دارد؟ Software Stack
چرا Shader Compilation باعث Stutter می شود؟ Compiler / Shader Cache

ارتباط بخش های اصلی با یکدیگر


                 SOFTWARE
                    │
                    ▼
               COMMANDS
                    │
                    ▼
              GPU SCHEDULING
                    │
          ┌─────────┴─────────┐
          ▼                   ▼
       COMPUTE             GRAPHICS
          │                   │
          │                   ▼
          │              RASTERIZATION
          │                   │
          │                   ▼
          │              PIXEL SHADING
          │                   │
          └─────────┬─────────┘
                    ▼
                  MEMORY
                    │
                    ▼
                   VRAM
                    │
          ┌─────────┴─────────┐
          ▼                   ▼
      RAY TRACING             AI
          │                   │
          └─────────┬─────────┘
                    ▼
                PERFORMANCE
                    │
                    ▼
              POWER / THERMAL
                    │
                    ▼
              REAL BEHAVIOR

مسیرهای پیشنهادی مرور کتاب

مسیر Gaming

GPU Basics
→ Graphics Pipeline
→ Texture Units
→ ROP
→ VRAM
→ Performance Metrics
→ Bottleneck Analysis
→ Display Pipeline

مسیر GPU Architecture

GPU Basics
→ Execution Architecture
→ Scheduler
→ Warp / Wave
→ Occupancy
→ Registers
→ Cache
→ Memory Architecture

مسیر Ray Tracing

Graphics Pipeline
→ Ray Tracing
→ BVH
→ Traversal
→ Intersection
→ Path Tracing
→ Denoising
→ Performance Analysis

مسیر AI

Execution Architecture
→ Memory Architecture
→ Matrix Operations
→ Precision
→ AI Acceleration
→ VRAM Capacity
→ Memory Bandwidth
→ AI Bottlenecks

مسیر خرید GPU

Performance Metrics
→ VRAM
→ Benchmarks
→ Bottlenecks
→ Power
→ Cooling
→ PCIe
→ Display
→ Workload-Based Selection

مسیر Performance Engineering

Execution
→ Memory
→ Occupancy
→ Divergence
→ Register Pressure
→ Profiling
→ Bottleneck Analysis
→ Software Stack

Master Rules — قواعدی که تقریبا در تمام کتاب تکرار شدند

  1. یک عدد را جدا از معماری تفسیر نکنید.

    Core Count،
    TFLOPS،
    Clock
    و Bandwidth
    فقط در Context درست معنی پیدا می کنند.


  2. Capacity و Speed را از یکدیگر جدا کنید.

    VRAM بیشتر
    به معنی Bandwidth بیشتر نیست.


  3. Peak و Real Performance را یکی ندانید.

    Peak Specification
    ظرفیت نظری است.

    Benchmark
    رفتار واقعی Workload را نشان می دهد.


  4. Latency و Throughput را جدا کنید.

    GPU معمولا Latency را
    با Parallelism
    پنهان می کند.


  5. Bottleneck را پیدا کنید.

    بهینه سازی بخشی
    که Bottleneck نیست
    ممکن است تاثیر کمی داشته باشد.


  6. Memory بخشی از Compute است.

    واحد محاسباتی سریع
    بدون Data Feed مناسب
    نمی تواند Peak Performance را حفظ کند.


  7. Hardware و Software را جدا تحلیل نکنید.

    Driver،
    Compiler،
    API
    و Application
    می توانند استفاده واقعی از GPU
    را تغییر دهند.


  8. Workload قبل از Specification می آید.

    ابتدا مشخص کنید
    چه کاری می خواهید انجام دهید،
    بعد Hardware را مقایسه کنید.

مدل نهایی تحلیل Performance


WORKLOAD

   │
   ▼

What Work Is Required?

   │
   ├── Compute?
   ├── Memory?
   ├── Texture?
   ├── Geometry?
   ├── Ray Tracing?
   ├── AI?
   └── Transfer?

   │
   ▼

Which Resource Is Most Pressured?

   │
   ▼

BOTTLENECK

   │
   ▼

MEASURE

   │
   ▼

OPTIMIZE

   │
   ▼

MEASURE AGAIN

جدول مرجع نهایی

اگر این مورد افزایش پیدا کند… معمولا چه چیزی بیشتر تحت فشار قرار می گیرد؟
Resolution Pixel Shading، Render Output، Memory Traffic
Texture Resolution VRAM Capacity، Cache، Memory Traffic
Geometry Detail Vertex / Primitive Processing
Shader Complexity Compute Resources
Texture Samples Texture Units، Cache، Memory
Ray Count Traversal، Intersection، Shader Work
Path Tracing Samples Ray Workload و Denoising
AI Model Size VRAM Capacity و Memory Traffic
Precision Size Memory Footprint و Compute Throughput
Draw Calls CPU / Driver / Submission
PCIe Transfers System-to-GPU Communication
Clock Potential Performance + Power + Heat

آزمون نهایی درک GPU

اگر بتوانید
بدون مراجعه به کتاب
برای سوال های زیر
پاسخ مفهومی بدهید،
ساختار اصلی GPU را
به خوبی فهمیده اید:

  1. چرا GPU تعداد زیادی Thread اجرا می کند؟
  2. Warp یا Wave چیست؟
  3. Latency Hiding چگونه کار می کند؟
  4. Occupancy چه چیزی را نشان می دهد؟
  5. چرا Register Pressure مهم است؟
  6. Cache چرا برای GPU ضروری است؟
  7. VRAM Capacity و Bandwidth چه تفاوتی دارند؟
  8. Rasterization چه کاری انجام می دهد؟
  9. Texture Unit چه تفاوتی با Shader Unit دارد؟
  10. ROP چه نقشی دارد؟
  11. BVH چرا Ray Tracing را سریع تر می کند؟
  12. Path Tracing چرا Noise ایجاد می کند؟
  13. چرا Matrix Hardware برای AI مفید است؟
  14. چرا TFLOPS معادل FPS نیست؟
  15. چگونه CPU-Bound را از GPU-Bound تشخیص می دهیم؟
  16. چرا Power و Cooling روی Performance اثر دارند؟
  17. PCIe Bandwidth و VRAM Bandwidth چه تفاوتی دارند؟
  18. FPS و Refresh Rate چه تفاوتی دارند؟
  19. Driver چگونه روی Performance اثر می گذارد؟
  20. چرا Bottleneck بعد از Optimization می تواند تغییر کند؟

اصل نهایی مطالعه GPU

وقتی درباره یک GPU
یک عدد،
یک Feature
یا یک Benchmark می بینید،
سه سوال بپرسید:


1.

What Does This Metric
Actually Measure?


2.

Which Part of the GPU
Does It Describe?


3.

Does My Workload
Actually Depend on It?

این سه سوال
بخش بزرگی از اشتباهات رایج
در مقایسه GPUها
را حذف می کنند.

خلاصه Master Index

  • GPU باید به صورت یک سیستم کامل دیده شود.
  • Execution Architecture نحوه اجرای Parallel Work را توضیح می دهد.
  • Memory Architecture نحوه رساندن داده به Compute Units را توضیح می دهد.
  • Graphics Pipeline مسیر تبدیل Geometry به Frame است.
  • Ray Tracing مسیر Rayها را در Scene دنبال می کند.
  • AI Acceleration از Parallelism و Matrix Operations استفاده می کند.
  • Performance Metrics فقط ظرفیت بخش های مختلف را توصیف می کنند.
  • Bottleneck مشخص می کند کدام Resource محدودکننده واقعی است.
  • Power و Cooling روی Sustained Performance اثر دارند.
  • PCIe ارتباط GPU با سیستم را فراهم می کند.
  • Display Pipeline Frame نهایی را به مانیتور می رساند.
  • Driver و Software Stack بخشی واقعی از رفتار GPU هستند.
  • Benchmark باید متناسب با Workload انتخاب شود.
  • بهترین تحلیل از ترکیب Architecture، Measurement و Workload به دست می آید.

پایان مسیر اصلی کتاب GPU

با رسیدن به این بخش،
مسیر اصلی محتوای کتاب GPU
از معماری پایه
تا Execution،
Memory،
Graphics،
Ray Tracing،
AI،
Performance،
Power،
Cooling،
PCIe،
Display
و Software Stack
کامل شده است.

از این نقطه
کتاب وارد بخش های مرجع،
ویرایشی
و تکمیلی می شود
و فصل اصلی معماری جدیدی
به مسیر آموزشی اضافه نمی شود.


مرحله:
بازبینی نهایی

نوع:
Editorial QA + Technical QA + Structural QA

کاربرد:
کنترل نسخه نهایی پیش از انتشار


GPU BOOK FINAL QA

بازبینی نهایی و کنترل کیفیت کتاب GPU

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

اکنون باید مطمئن شویم
فصل ها فقط به صورت جداگانه درست نیستند،
بلکه کل کتاب
به عنوان یک ساختار واحد
از نظر علمی،
آموزشی،
اصطلاحات،
Cross Reference،
HTML
و تجربه مطالعه
هماهنگ است.

مدل نهایی کنترل کیفیت


Complete Draft

      │
      ▼

Technical Review

      │
      ▼

Terminology Review

      │
      ▼

Structure Review

      │
      ▼

Cross-Reference Review

      │
      ▼

HTML Validation

      │
      ▼

Duplication Review

      │
      ▼

Reading Flow Review

      │
      ▼

Final Publishable Version

1. کنترل دقت فنی

در بازبینی فنی،
هر ادعا باید
در یکی از سه گروه قرار بگیرد:

نوع ادعا رفتار مناسب
مفهوم معماری عمومی با تعریف روشن و مستقل از Vendor بیان شود.
رفتار وابسته به معماری با عبارت هایی مانند «بسته به معماری» محدود شود.
عدد یا Specification مشخص فقط با Source معتبر و Context دقیق استفاده شود.

2. کنترل ادعاهای عددی

تمام عددهای کتاب
باید دوباره بررسی شوند.

  • آیا عدد یک رابطه ریاضی عمومی است؟
  • آیا عدد به یک استاندارد مشخص مربوط است؟
  • آیا عدد به Architecture یا Product خاص مربوط است؟
  • آیا Precision مشخص شده است؟
  • آیا واحد درست نوشته شده است؟
  • آیا عدد Approximate است یا Exact؟
  • آیا Source برای عدد Architecture-Specific لازم است؟


قاعده

عدد Architecture-Specific
نباید از روی حافظه،
حدس
یا تعمیم یک GPU
به تمام GPUها
وارد متن شود.

3. یکسان سازی اصطلاحات

اصطلاحات باید
در کل کتاب
با یک الگوی ثابت
استفاده شوند.

مفهوم فرم پیشنهادی ثابت
حافظه گرافیکی VRAM
پهنای باند حافظه Memory Bandwidth
تاخیر Latency
توان عملیاتی Throughput
گروه اجرایی Warp / Wave
پردازشگر Fragment Pixel / Fragment Shader
واحد Texture Texture Unit
مسیر خروجی Rendering Render Output
ساختار شتاب دهنده Acceleration Structure
گلوگاه Bottleneck

در اولین استفاده
می توان توضیح فارسی داد،
اما بعد از آن
اصطلاح اصلی
باید ثابت بماند.

4. تفکیک مفهوم عمومی از نام تجاری

کتاب باید تا حد ممکن
معماری را
Vendor-Neutral آموزش دهد.

مفهوم عمومی نمونه نام معماری / Vendor
Thread Group Execution Warp / Wavefront / Wave
Matrix Acceleration Vendor-Specific Matrix / Tensor Hardware
Ray Tracing Acceleration Vendor-Specific RT Hardware
Compute Unit SM / CU / Xe Core terminology depending on vendor

نام Vendor
باید مثال باشد،
نه تعریف خود مفهوم.

5. حذف تکرارهای غیرضروری

در کتاب آموزشی بزرگ،
تکرار کنترل شده مفید است،
اما تکرار کامل
حجم متن را زیاد می کند.

هر بخش تکراری
باید یکی از این نقش ها را داشته باشد:

  • مرور کوتاه،
  • اتصال فصل جدید به فصل قبلی،
  • تغییر زاویه نگاه،
  • یا Reinforcement آموزشی.

اگر هیچ یک از این نقش ها وجود ندارد،
بخش احتمالا باید
کوتاه،
ادغام
یا حذف شود.

تست ساده تکرار


Paragraph Exists Earlier?

        │
        ▼

Yes

        │
        ▼

Does This Version Add
New Context or Insight?

      /   
    Yes    No
     │      │
     ▼      ▼

Keep     Shorten /
         Remove /
         Link Back

6. کنترل Chapter Contract

هر فصل اصلی
باید تا حد امکان
ساختار مشترک کتاب را رعایت کند.

  • Chapter Meta
  • Section Kicker
  • عنوان اصلی
  • Lead
  • Quick Answer
  • Learning Objectives
  • بدنه آموزشی
  • Diagram در صورت نیاز
  • Under the Hood در صورت ارزش واقعی
  • Performance Impact در صورت مرتبط بودن
  • Engineering Insight
  • Common Mistakes
  • FAQ
  • Summary
  • Cross References
  • Navigation

اما Contract
نباید باعث شود
کامپوننتی
بدون نیاز آموزشی
به فصل تحمیل شود.

7. فقط کامپوننت های تایید شده

در نسخه نهایی
نباید Class یا Component جدیدی
صرفا برای یک فصل
بدون تعریف در Framework
ایجاد شده باشد.

نمونه Componentهای فعلی کتاب:


ss-section

ss-subsection

ss-chapter-meta

ss-chapter-header

ss-section-kicker

ss-lead

ss-info

ss-card

ss-card-grid

ss-table-wrapper

ss-table

ss-code-diagram

ss-under-hood

ss-performance-impact

ss-engineering-insight

ss-common-mistakes

ss-faq

ss-faq-item

ss-summary

ss-check-list

ss-chapter-nav

8. کنترل ساختار HTML

  • تمام Tagها بسته شده باشند.
  • Sectionها داخل Section اشتباه بسته نشده باشند.
  • Table دارای thead و tbody صحیح باشد.
  • هر tr تعداد Cell سازگار داشته باشد.
  • details و summary ساختار صحیح داشته باشند.
  • pre و code به درستی بسته شوند.
  • Block Componentها داخل p قرار نگرفته باشند.
  • ID تکراری وجود نداشته باشد.
  • aria-labelledby به ID موجود اشاره کند.
  • Navigation Linkها مقصد واقعی داشته باشند.


قاعده مهم HTML

عناصر Block
نباید داخل
<p>
قرار بگیرند.

برای مثال:


Bad

<p>
    Text

    <div class="ss-card">
        ...
    </div>
</p>


Good

<p>
    Text
</p>

<div class="ss-card">
    ...
</div>

این خطا
یکی از عواملی است
که می تواند باعث شود
متن یا Box
در مرورگر
خارج از محل مورد انتظار
Render شود.

9. کنترل IDها

هر ID
باید در کل Document
Unique باشد.


Good

gpu-ray-tracing-architecture

gpu-path-tracing

gpu-ai-acceleration


Bad

gpu-memory

gpu-memory
gpu-memory

ID تکراری
می تواند:

  • Anchor Link را خراب کند،
  • aria-labelledby را مبهم کند،
  • JavaScript Selector را اشتباه کند،
  • و Navigation را غیرقابل اعتماد کند.

10. کنترل Cross Referenceها

تمام Linkهای داخلی
باید بررسی شوند.


href="#gpu-bvh"

        │
        ▼

Does id="gpu-bvh-scs-2" exist?

      /   
    Yes    No
     │      │
     ▼      ▼

Valid   Fix Link

نباید Linkی
به فصلی که تغییر نام داده،
حذف شده
یا ID آن عوض شده
باقی بماند.

11. کنترل Navigation فصل ها

مسیر Previous و Next
باید در تمام کتاب
یک زنجیره پیوسته بسازد.


Chapter 01
   │
   ▼
Chapter 02
   │
   ▼
Chapter 03
   │
   ▼
...
   │
   ▼
Final Review

هیچ Chapter
نباید:

  • به خودش Link شود،
  • یک فصل را Skip کند،
  • یا Next / Previous ناسازگار داشته باشد.

12. کنترل Table of Contents

Table of Contents نهایی
باید با ساختار واقعی کتاب
یکسان باشد.

  • تمام فصل های اصلی در TOC باشند.
  • فصل حذف شده در TOC باقی نمانده باشد.
  • ترتیب TOC با ترتیب Document یکی باشد.
  • Anchorها صحیح باشند.
  • عنوان TOC با عنوان واقعی فصل یکی باشد.
  • فصل های مرجع از فصل های آموزشی قابل تشخیص باشند.

13. کنترل FAQها

FAQ
نباید فقط Summary فصل
را با قالب دیگری تکرار کند.

FAQ خوب
باید سوالی را جواب دهد
که واقعا ممکن است
در ذهن خواننده ایجاد شود.


Good FAQ

"آیا VRAM بیشتر همیشه FPS را زیاد می کند؟"


Weak FAQ

"VRAM چیست؟"

when the whole chapter
already defines it repeatedly

14. کنترل Diagramها

هر Diagram
باید یک مسئله را
ساده تر از متن توضیح دهد.

  • Diagram فقط تکرار Text نباشد.
  • جهت Flow واضح باشد.
  • LTR برای Diagramهای انگلیسی رعایت شود.
  • Alignment داخل pre حفظ شود.
  • از Line بسیار طولانی جلوگیری شود.
  • Diagram در Mobile قابل فهم باقی بماند.
  • ASCII Art معنی فنی اشتباه ایجاد نکند.

15. کنترل Tableها

  • Column Header واضح باشد.
  • Scope برای Headerها در صورت نیاز استفاده شود.
  • Cellها متن بیش از حد طولانی نداشته باشند.
  • Comparisonها هم سطح باشند.
  • Vendor-Specific Metricها با Metric عمومی مخلوط نشوند.
  • عددها Unit داشته باشند.
  • Table در عرض محدود قابل Scroll باشد.

16. کنترل جریان آموزشی

هر فصل
باید از سوال ساده
به مدل ذهنی
و سپس جزئیات
حرکت کند.


Question

   │
   ▼

Simple Definition

   │
   ▼

Mental Model

   │
   ▼

How It Works

   │
   ▼

Why It Matters

   │
   ▼

Performance Impact

   │
   ▼

Common Mistakes

   │
   ▼

Summary

نباید خواننده
قبل از تعریف مفهوم
با جزئیات داخلی آن
مواجه شود.

17. کنترل عمق مطالب

نسخه نهایی کتاب
قرار نیست
Documentation Microarchitecture
یا راهنمای طراحی Silicon باشد.

تمرکز نهایی باید روی:

  • درک معماری،
  • درک Performance،
  • تشخیص Bottleneck،
  • خواندن Specification،
  • و ارتباط بخش های GPU

باقی بماند.

جزئیات مهندسی بسیار عمیق
فقط زمانی باقی بمانند
که برای فهم مفهوم اصلی
ضروری باشند.

18. کنترل سطح خواننده

متن نهایی باید
برای خواننده کنجکاو و فنی
قابل فهم باشد،
بدون اینکه
پیش نیاز طراحی تراشه داشته باشد.

سطح هدف

از کاربر علاقه مند به Hardware
تا توسعه دهنده ای که می خواهد
GPU Architecture
را به شکل مفهومی
و کاربردی بفهمد.

19. کنترل زبان و نگارش

  • جمله ها بیش از حد شکسته نباشند.
  • فارسی و انگلیسی خوانایی خود را حفظ کنند.
  • اصطلاح انگلیسی در جای مناسب قرار گیرد.
  • از ترجمه های چندگانه برای یک اصطلاح جلوگیری شود.
  • جملات تبلیغاتی حذف شوند.
  • ادعاهای مطلق غیرضروری حذف شوند.
  • «همیشه»، «هرگز» و «قطعا» فقط در جای درست استفاده شوند.
  • عبارت های وابسته به معماری با Qualifier مناسب نوشته شوند.

20. زبان مناسب برای ادعاهای فنی

به جای بهتر است
GPU همیشه… در بسیاری از GPUهای مدرن…
این واحد دقیقا… در یک مدل مفهومی، این واحد…
این کار قطعا سریع تر است. این روش در Workload مناسب می تواند Performance را بهبود دهد.
تمام GPUها… جزئیات دقیق به معماری بستگی دارد.

21. سیاست Source برای نسخه نهایی

Source برای همه جمله های آموزشی
ضروری نیست.

اما برای موارد زیر
باید Source معتبر وجود داشته باشد:

  • Specification عددی Product،
  • Latency عددی،
  • Throughput عددی،
  • رفتار Architecture-Specific،
  • ادعای Vendor-Specific،
  • محدودیت Standard،
  • Feature Support مشخص،
  • و داده Benchmark.

اولویت Source:


Official Architecture Documentation

            │
            ▼

Official Programming Guide

            │
            ▼

Standards / API Documentation

            │
            ▼

Peer-Reviewed / Technical Research

            │
            ▼

High-Quality Independent Analysis

22. کنترل مطالب وابسته به زمان

کتاب باید تا حد ممکن
Evergreen باقی بماند.

بنابراین بهتر است
به جای تمرکز زیاد بر:

  • یک نسل خاص GPU،
  • یک Product Line خاص،
  • یک Driver Version خاص،
  • یا Benchmark موقتی بازار

روی مفاهیم پایدار معماری
تمرکز شود.

اطلاعات Product-Specific
در صورت نیاز
می توانند در Example،
Case Study
یا Reference Box
جدا شوند.

23. کنترل Accessibility

  • Heading Hierarchy منطقی باشد.
  • aria-labelledby به Heading صحیح وصل باشد.
  • Table Headerها مشخص باشند.
  • Navigation دارای aria-label مناسب باشد.
  • Link Text معنی دار باشد.
  • معنا فقط با Color منتقل نشود.
  • FAQ با details / summary قابل استفاده باشد.
  • Diagramهای مهم فقط به شکل تصویری وابسته نباشند و Text توضیحی داشته باشند.

24. کنترل نمایش Mobile

  • Tableها از Container بیرون نزنند.
  • Code Diagramها Horizontal Overflow کنترل شده داشته باشند.
  • Long English Terms باعث شکستن Layout نشوند.
  • Card Grid در عرض کم به یک Column تبدیل شود.
  • Navigation Linkها روی هم نیفتند.
  • Padding Boxها در Mobile بیش از حد بزرگ نباشد.
  • Font Size Diagram قابل خواندن باشد.

ترتیب پیشنهادی بازبینی نسخه نهایی


PASS 1
HTML Structure


PASS 2
IDs + Anchors


PASS 3
Terminology


PASS 4
Technical Claims


PASS 5
Numeric Claims + Sources


PASS 6
Duplication


PASS 7
Chapter Flow


PASS 8
FAQ + Summary


PASS 9
Mobile + Accessibility


PASS 10
Full Book Reading

Release Checklist

  • هیچ ID تکراری وجود ندارد.
  • هیچ Anchor شکسته وجود ندارد.
  • تمام Tagها صحیح بسته شده اند.
  • هیچ Component تعریف نشده ای استفاده نشده است.
  • Chapter Contract در فصل های اصلی رعایت شده است.
  • اصطلاحات در کل کتاب یکسان هستند.
  • اعداد Architecture-Specific بدون Source باقی نمانده اند.
  • ادعاهای وابسته به Vendor به عنوان مفهوم عمومی نوشته نشده اند.
  • تکرارهای بزرگ حذف یا ادغام شده اند.
  • FAQها ارزش مستقل دارند.
  • Summaryها واقعا خلاصه هستند.
  • Cross Referenceها معتبر هستند.
  • TOC با Document هماهنگ است.
  • Previous / Next Navigation کامل است.
  • Tableها در Mobile قابل استفاده هستند.
  • Diagramها از Container خارج نمی شوند.
  • Heading Hierarchy صحیح است.
  • Accessibility پایه رعایت شده است.
  • نسخه کامل یک بار از ابتدا تا انتها خوانده شده است.

Final Quality Gate

یک فصل
فقط زمانی آماده انتشار است
که بتواند
هر چهار آزمون زیر را
هم زمان پاس کند:


Is It Correct?

      │
      ▼

Is It Clear?

      │
      ▼

Is It Necessary?

      │
      ▼

Is It Consistent
with the Rest of the Book?

      │
      ▼

Publish

اصل نهایی ویرایش

نسخه نهایی
نباید صرفا
بیشترین حجم اطلاعات را داشته باشد.

باید بیشترین مقدار

اطلاعات مفید، درست و قابل فهم

را
با کمترین تکرار غیرضروری
ارائه کند.

هر چیزی که حذف می شود
نباید فهم را کم کند؛
و هر چیزی که باقی می ماند
باید دلیلی برای حضور داشته باشد.

خلاصه مرحله Final QA

  • محتوای اصلی GPU در این مرحله کامل است.
  • اکنون تمرکز روی صحت، هماهنگی و کیفیت نسخه نهایی است.
  • ادعاهای عددی و معماری محور باید جداگانه بررسی شوند.
  • اصطلاحات باید در تمام کتاب یکسان باشند.
  • Vendor-Specific Terminology نباید جای مفهوم عمومی را بگیرد.
  • تکرار باید فقط با هدف آموزشی باقی بماند.
  • Chapter Contract باید بدون تحمیل Component غیرضروری رعایت شود.
  • ساختار HTML، IDها و Anchorها باید Validate شوند.
  • Cross Reference و Navigation باید یک زنجیره کامل بسازند.
  • FAQ، Diagram و Table باید ارزش آموزشی واقعی داشته باشند.
  • نسخه نهایی باید روی Mobile و از نظر Accessibility بررسی شود.
  • آخرین مرحله یک Full Read از ابتدا تا انتهای کتاب است.


مرحله:
آماده سازی انتشار

نوع:
Publication Checklist

کاربرد:
کنترل نهایی نسخه قابل انتشار


GPU PUBLICATION READY

چک لیست نهایی آماده سازی کتاب GPU برای انتشار

پس از پایان تولید محتوا
و انجام بازبینی فنی و ساختاری،
نسخه کتاب باید
برای انتشار واقعی آماده شود.

در این مرحله
تمرکز دیگر روی اضافه کردن مطالب جدید نیست.

هدف این است
که نسخه نهایی
از نظر ساختار،
لینک ها،
Metadata،
خوانایی،
Performance صفحه
و تجربه کاربر
آماده انتشار باشد.

مسیر نهایی انتشار


Final Content

      │
      ▼

Technical QA

      │
      ▼

HTML QA

      │
      ▼

Internal Links QA

      │
      ▼

SEO / Metadata

      │
      ▼

Performance Check

      │
      ▼

Mobile Check

      │
      ▼

Accessibility Check

      │
      ▼

Final Proofreading

      │
      ▼

Publish

1. عنوان اصلی صفحه

Title نهایی صفحه
باید روشن،
کوتاه
و مرتبط با محتوای اصلی کتاب باشد.


Example

GPU چیست؟
راهنمای جامع معماری،
حافظه،
رندرینگ
و عملکرد کارت گرافیک

عنوان نباید
فقط شامل عبارت های تبلیغاتی
یا Keywordهای تکراری باشد.

2. Meta Description

Meta Description
باید در چند جمله کوتاه
مشخص کند
خواننده در این صفحه
چه چیزی یاد می گیرد.


موضوعات اصلی

GPU Architecture
Memory
VRAM
Graphics Pipeline
Ray Tracing
AI
Performance
Cooling
PCIe
Display
Driver

Meta Description
نباید خلاصه تمام کتاب باشد؛
فقط باید موضوع و ارزش صفحه
را روشن کند.

3. Canonical URL

اگر نسخه های مختلف
از یک مقاله یا کتاب
در URLهای مختلف وجود داشته باشند،
باید URL اصلی
به صورت Canonical
مشخص شود.


Multiple URLs

/page?ref=1
/page?source=x
/page

      │
      ▼

Canonical

/page

4. Heading Hierarchy

Headingهای صفحه
باید ساختار واقعی محتوا
را منعکس کنند.


H1
Book / Page Title

   │
   ├── H2
   │   Main Chapter
   │
   │   ├── H3
   │   │   Subsection
   │   │
   │   └── H3
   │
   └── H2
       Next Chapter

Heading نباید
فقط برای بزرگ کردن Font
استفاده شود.

5. Table of Contents نهایی

TOC
باید دقیقا مطابق
ساختار واقعی نسخه منتشر شده باشد.

  • هیچ فصل حذف شده ای در TOC باقی نمانده باشد.
  • هیچ فصل جدیدی بدون لینک در TOC نباشد.
  • Anchor تمام آیتم ها کار کند.
  • عنوان TOC با Heading واقعی هماهنگ باشد.
  • ترتیب فصل ها درست باشد.
  • Glossary و بخش های مرجع مشخص باشند.

6. Anchor URLها باید قابل اعتماد باشند

Reader
ممکن است مستقیما
به یک بخش خاص کتاب
Link بدهد.


example.com/gpu-guide

        +

#gpu-ray-tracing-architecture

        │
        ▼

Direct Link
to Ray Tracing Chapter

به همین دلیل
IDهای اصلی
بعد از انتشار
نباید بدون دلیل
تغییر کنند.

9. محل Sourceها

Source
باید نزدیک به ادعایی باشد
که از آن پشتیبانی می کند.


Specific Technical Claim

        │
        ▼

Relevant Source

        ✓


Whole Chapter

        │
        ▼

Huge Unstructured Link List

        ✗

Reader
باید بتواند بفهمد
هر Source
برای کدام ادعا استفاده شده است.

10. HTML Validation نهایی

  • Tagهای باز بدون Tag بسته وجود نداشته باشند.
  • Closing Tag اضافی وجود نداشته باشد.
  • Block Element داخل p قرار نگرفته باشد.
  • ID Duplicate وجود نداشته باشد.
  • aria-labelledby شکسته وجود نداشته باشد.
  • Table Structure صحیح باشد.
  • details / summary صحیح باشند.
  • Navigation Structure معتبر باشد.

11. کنترل Overflow

نسخه نهایی
نباید در Mobile
باعث Horizontal Scroll
کل صفحه شود.

موارد حساس:

  • Table،
  • pre،
  • code،
  • Long URL،
  • Long English Terms،
  • Diagram،
  • و Card Grid.


Page Width

|--------------------|


Bad Element

|---------------------------------------|


Preferred

Scrollable Inner Component

|--------------------|
| component  → scroll|
|--------------------|

12. Diagramها از Container بیرون نزنند

ASCII Diagramها
باید داخل Component مخصوص
قرار بگیرند
تا Overflow
در همان بخش مدیریت شود.


<div
    class="ss-code-diagram ss-code-diagram--framed"
    dir="ltr"
>

    <pre><code>
        ...
    </code></pre>

</div>

Diagram نباید
داخل Paragraph
یا Table Cell نامناسب
قرار بگیرد.

13. Tableهای Mobile

تمام Tableها
باید داخل
Table Wrapper
قرار داشته باشند.


ss-table-wrapper

      │
      ▼

ss-table

      │
      ▼

Horizontal Scroll
when necessary

نباید برای جا شدن Table
Font آن قدر کوچک شود
که خوانایی از بین برود.

14. کنترل Imageها

اگر در نسخه نهایی
Diagram،
Screenshot
یا Illustration تصویری استفاده شود،
باید موارد زیر بررسی شوند:

  • تصویر واقعا به فهم مطلب کمک کند.
  • Resolution بیش از نیاز بزرگ نباشد.
  • Aspect Ratio صحیح باشد.
  • Alt Text مناسب داشته باشد.
  • Caption در صورت نیاز اضافه شود.
  • تصویر Layout Shift ایجاد نکند.
  • File Size بهینه باشد.
  • نسخه Mobile مناسب باشد.

15. Lazy Loading

برای صفحه ای به بزرگی این کتاب،
نباید تمام Imageها
هم زمان و بدون نیاز
بارگذاری شوند.


Top of Page Images

Load Normally


Far Below Viewport Images

Load Later
when needed

این کار
می تواند Initial Page Load
را سبک تر کند.

16. وزن نهایی صفحه

کتاب طولانی است،
اما حجم HTML Text
معمولا مشکل اصلی نیست.

مواردی که بیشتر
Page Weight را افزایش می دهند:

  • Imageهای بزرگ،
  • Fontهای زیاد،
  • JavaScript اضافی،
  • CSS تکراری،
  • Video،
  • و Third-Party Scriptها.

هدف
حذف Featureهای مفید نیست؛
بلکه حذف Load غیرضروری است.

17. JavaScript باید حداقل لازم باشد

بخش بزرگی از کتاب
با HTML و CSS
قابل استفاده است.

برای Featureهایی مانند:

  • TOC Active State،
  • Search،
  • Progress Indicator،
  • یا Interactive Navigation

ممکن است JavaScript لازم باشد.

اما محتوای اصلی
نباید برای خوانده شدن
کاملا به JavaScript وابسته باشد.

18. نسخه Print

برای یک کتاب آموزشی طولانی،
Print Styles
می توانند بسیار مفید باشند.

در Print Mode
می توان:

  • Navigationهای غیرضروری را مخفی کرد،
  • Backgroundهای سنگین را حذف کرد،
  • Contrast را بهبود داد،
  • Page Breakها را کنترل کرد،
  • و Tableها را خواناتر کرد.

20. Reading Progress

برای محتوای بسیار بلند،
نمایش Progress مطالعه
می تواند مفید باشد.


Start

████░░░░░░░░░░░░

25%


Middle

████████░░░░░░░░

50%


Near End

██████████████░░

88%

این Feature
نباید فضای زیادی
از UI را اشغال کند.

21. Sticky Table of Contents

در Desktop،
یک TOC جانبی
می تواند
Navigation کتاب را سریع تر کند.

اما باید:

  • عرض Content را بیش از حد کم نکند،
  • روی Mobile مخفی یا تبدیل شود،
  • Active Chapter را واضح نشان دهد،
  • و Scroll مستقل نامناسب ایجاد نکند.

23. استفاده از Glossary

برای اصطلاحات تخصصی
می توان در اولین استفاده
Link داخلی
به Glossary ایجاد کرد.


Occupancy

     │
     ▼

Glossary Definition

اما نباید
هر بار که اصطلاح تکرار می شود
Link اضافه شود؛
این کار متن را شلوغ می کند.

24. FAQ Structure

FAQها
باید از نظر محتوایی
واقعی و مستقل باشند.

اگر Structured Data
برای FAQ استفاده شود،
محتوای Markup
باید با FAQ قابل مشاهده
روی صفحه
هماهنگ باشد.

نباید سوال یا پاسخ مخفی
فقط برای Search Engine
اضافه شود.

25. تاریخ آخرین بازبینی

برای محتوای فنی
نمایش تاریخ آخرین بازبینی
می تواند مفید باشد.


Published

Original Date


Reviewed / Updated

Latest Technical Review

اما Update Date
فقط زمانی تغییر کند
که واقعا محتوا
بازبینی یا اصلاح شده باشد.

26. Versioning داخلی

برای پروژه ای با این حجم،
داشتن Version داخلی
می تواند مدیریت Updateها را ساده کند.


GPU Book

v1.0
Initial Publication


v1.1
Corrections


v1.2
New Architecture Notes

این Version
الزاما لازم نیست
به Reader نمایش داده شود،
اما برای مدیریت Editorial
مفید است.

27. Change Log

برای Updateهای مهم
می توان Change Log داخلی نگهداری کرد.


2026-08

Initial GPU Architecture Release


Later

Corrected Terminology

Updated PCIe Section

Added Architecture Example

این کار
به جلوگیری از
بازگشت اشتباهات قبلی
کمک می کند.

28. تست دستی قبل از انتشار

  • صفحه را از ابتدا تا انتها Scroll کنید.
  • تمام Navigationهای اصلی را تست کنید.
  • TOC را تست کنید.
  • چند Link عمیق را مستقیما در Browser باز کنید.
  • FAQها را باز و بسته کنید.
  • Tableها را در Mobile بررسی کنید.
  • Diagramهای بزرگ را در Mobile بررسی کنید.
  • صفحه را با Font Scaling بررسی کنید.
  • Print Preview را بررسی کنید.
  • صفحه را بدون Cache یک بار Load کنید.

29. تست Desktop

حداقل چند عرض مختلف
بررسی شود.


Small Laptop

      │
      ▼

Standard Desktop

      │
      ▼

Large Desktop

تمرکز اصلی:

  • Line Length،
  • TOC Position،
  • Card Grid،
  • Table Width،
  • و Diagram Alignment.

30. تست Mobile

در Mobile
باید بررسی شود:

  • هیچ Box خارج صفحه نباشد.
  • هیچ Text مخفی یا بریده نشود.
  • Code Diagram قابل Scroll باشد.
  • Table قابل Scroll باشد.
  • Font خوانا باشد.
  • Tap Targetها کافی باشند.
  • Navigation چند خطی خراب نشود.
  • Cardها به ترتیب منطقی نمایش داده شوند.

31. Accessibility نهایی

  • Keyboard Navigation کار کند.
  • Focus قابل مشاهده باشد.
  • Contrast کافی باشد.
  • Heading Structure صحیح باشد.
  • Link Text واضح باشد.
  • Table Headerها درست تعریف شوند.
  • Imageها Alt مناسب داشته باشند.
  • Interactive Componentها بدون Mouse قابل استفاده باشند.

32. Content Freeze

بعد از شروع QA نهایی،
بهتر است
فصل جدید
یا Rewrite بزرگ
به نسخه اضافه نشود.


Content Complete

      │
      ▼

Content Freeze

      │
      ▼

QA Only

      │
      ▼

Release

در این مرحله
فقط:

  • Bug Fix،
  • Technical Correction،
  • Broken Link Fix،
  • Typo Fix،
  • و Layout Correction

انجام شود.

33. Release Candidate

قبل از انتشار عمومی،
یک نسخه
Release Candidate
ساخته شود.


Draft

   │
   ▼

QA

   │
   ▼

Release Candidate

   │
   ▼

Final Check

   │
   ▼

Public Release

Release Candidate
باید همان نسخه ای باشد
که در صورت پیدا نشدن مشکل
منتشر خواهد شد.

34. بعد از انتشار

انتشار پایان عمر کتاب نیست.

بعد از انتشار
باید خطاهای گزارش شده،
تغییرات مهم استانداردها
و نیاز به Update
بررسی شوند.


Publish

   │
   ▼

Reader Feedback

   │
   ▼

Technical Changes

   │
   ▼

Review

   │
   ▼

Update When Necessary

Publication Gate

نسخه نهایی
فقط زمانی منتشر شود
که پاسخ تمام سوال های زیر
«بله» باشد:

  • آیا محتوا از نظر فنی قابل اعتماد است؟
  • آیا ساختار HTML سالم است؟
  • آیا هیچ Link شکسته ای باقی نمانده است؟
  • آیا نسخه Mobile قابل استفاده است؟
  • آیا Navigation کل کتاب کار می کند؟
  • آیا Reader می تواند موضوع مورد نظر خود را پیدا کند؟
  • آیا ادعاهای خاص Source مناسب دارند؟
  • آیا متن از تکرارهای غیرضروری پاک شده است؟
  • آیا Terminology در کل کتاب هماهنگ است؟
  • آیا هیچ مشکل شناخته شده مهمی عمدا باقی نمانده است؟

Master Publication Checklist

  • Content Freeze انجام شده است.
  • Technical QA کامل شده است.
  • Numeric Claims بررسی شده اند.
  • Sourceها بررسی شده اند.
  • Terminology یکسان شده است.
  • HTML Validate شده است.
  • ID Duplicate حذف شده است.
  • Anchorها بررسی شده اند.
  • TOC نهایی شده است.
  • Previous / Next Navigation صحیح است.
  • Cross Referenceها تست شده اند.
  • Tableها Responsive هستند.
  • Code Diagramها Responsive هستند.
  • Imageها Optimize شده اند.
  • Alt Textها اضافه شده اند.
  • Mobile QA انجام شده است.
  • Desktop QA انجام شده است.
  • Accessibility QA انجام شده است.
  • Metadata نهایی شده است.
  • Canonical بررسی شده است.
  • Print View بررسی شده است.
  • Page Performance بررسی شده است.
  • Full Read نهایی انجام شده است.
  • Release Candidate تایید شده است.

وضعیت نهایی پروژه

از نظر ساختار آموزشی،
کتاب GPU
در این نقطه
فصل جدید دیگری نیاز ندارد.

مسیر اصلی:


Architecture

   │
   ▼

Execution

   │
   ▼

Memory

   │
   ▼

Graphics

   │
   ▼

Ray Tracing

   │
   ▼

AI

   │
   ▼

Performance

   │
   ▼

Power / Cooling

   │
   ▼

PCIe

   │
   ▼

Display

   │
   ▼

Software

   │
   ▼

Glossary / Index

   │
   ▼

QA

   │
   ▼

Publication

کامل شده است.

از این مرحله به بعد
کار درست
اضافه کردن فصل بیشتر نیست؛
بلکه تبدیل همین مجموعه
به یک نسخه
تمیز،
هماهنگ،
قابل اعتماد
و آماده انتشار است.


STOKSHOP GPU ENCYCLOPEDIA

نسخه محتوایی کتاب GPU تکمیل شد

از این نقطه
فصل آموزشی جدیدی
به کتاب اضافه نمی شود.

مرحله بعد
بازبینی یکپارچه کل HTML،
اصلاح ID و Linkها،
حذف تکرارها،
کنترل Sourceها
و ساخت نسخه نهایی انتشار است.


مرحله:
نگهداری پس از انتشار

نوع:
Maintenance & Update Policy

کاربرد:
حفظ دقت، انسجام و تازگی کتاب در نسخه های آینده


GPU BOOK MAINTENANCE

سیاست نگهداری و به روزرسانی کتاب GPU

انتشار نسخه اول
پایان کار یک کتاب فنی نیست.

معماری های جدید معرفی می شوند،
APIها تغییر می کنند،
استانداردهای Display و PCIe توسعه پیدا می کنند
و اصطلاحات جدیدی
وارد صنعت می شوند.

اما هر تغییر جدیدی
نباید باعث Rewrite کل کتاب شود.

هدف این بخش
تعریف روشی است
که کتاب در آینده
بدون از دست دادن ساختار،
دقت
و خوانایی خود
به روز باقی بماند.


اصل اصلی نگهداری

مفاهیم پایدار معماری
باید هسته کتاب باقی بمانند.

تغییرات وابسته به نسل،
Vendor،
Product
یا Standard
باید فقط در بخشی که واقعا تحت تاثیر قرار گرفته
به روز شوند.

Update باید دانش کتاب را دقیق تر کند،
نه اینکه با هر نسل جدید GPU
کل ساختار آموزشی را دوباره بسازد.

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

لایه نوع محتوا نیاز به Update
Core Concepts مفاهیم بنیادی مانند Parallelism، Cache، Bandwidth، Rasterization و Bottleneck کم
Architecture-Specific رفتار یا قابلیت وابسته به معماری مشخص متوسط
Product / Standard Specific نسخه PCIe، Display Standard، Product Specification، Driver Behavior بیشتر

هسته Evergreen کتاب

بخش هایی مانند:

  • Parallel Processing،
  • Thread و Workgroup،
  • Latency و Throughput،
  • Memory Hierarchy،
  • Cache،
  • VRAM Capacity در برابر Bandwidth،
  • Rasterization،
  • Texture Sampling،
  • Ray Traversal،
  • Matrix Operations،
  • و Bottleneck Analysis

مفاهیم پایه هستند
و نباید فقط به دلیل عرضه یک نسل جدید GPU
دوباره نوشته شوند.

چه چیزی واقعا نیاز به Update ایجاد می کند؟

  • اشتباه فنی تایید شده.
  • تغییر مهم در یک Standard.
  • معرفی مفهوم معماری جدید و عمومی.
  • منسوخ شدن اصطلاح یا تعریف قبلی.
  • تغییر رفتار مهم API یا Software Stack.
  • وجود Source معتبر جدید که ادعای قبلی را اصلاح کند.
  • ابهام مکرر گزارش شده توسط خوانندگان.
  • وجود Sectionی که با معماری های جدید دیگر گمراه کننده شده باشد.

چه چیزهایی به تنهایی دلیل Rewrite نیستند؟

  • عرضه یک کارت گرافیک جدید،
  • افزایش Core Count یک نسل،
  • افزایش VRAM یک Product،
  • یک Benchmark جدید،
  • یک Driver Update معمولی،
  • یا تغییر قیمت بازار.

این موارد
ممکن است برای مقاله محصول
یا Comparison مهم باشند،
اما لزوما
ساختار کتاب معماری GPU را تغییر نمی دهند.

درخت تصمیم برای Update


New Information

      │
      ▼

Does It Change
a Core Concept?

     / 
   Yes  No
   │     │
   ▼     ▼

Review Core     Is It Architecture /
Chapter         Product Specific?
                  / 
                Yes  No
                │     │
                ▼     ▼

Update Local    Probably No
Section         Book Update Needed

سطح بندی اصلاحات

سطح نوع تغییر
Level 1 Typo، Formatting، Link یا ID Fix
Level 2 بهبود توضیح بدون تغییر مفهوم
Level 3 Technical Correction در یک Section
Level 4 تغییر مهم در ساختار یک Chapter
Level 5 تغییر Framework یا Master Structure

Level 5
باید بسیار نادر باشد،
زیرا روی کل کتاب
اثر زنجیره ای ایجاد می کند.

Sourceها نیز باید دوباره بررسی شوند

در Updateهای فنی،
فقط متن جدید بررسی نمی شود.

Sourceهای قبلی نیز ممکن است:

  • جابجا شده باشند،
  • نسخه جدید گرفته باشند،
  • Deprecated شده باشند،
  • یا Documentation دقیق تری جایگزین آنها شده باشد.


Existing Claim

     │
     ▼

Existing Source

     │
     ▼

Still Valid?

   /    
 Yes     No
  │       │
  ▼       ▼

Keep    Replace /
        Correct Claim

Exampleها باید از Concept جدا بمانند

اگر برای توضیح یک مفهوم
از معماری خاصی مثال زده شود،
باید روشن باشد
که Example
خود تعریف مفهوم نیست.


Core Concept

"Threads execute in groups"

        │
        ▼

Examples

Warp
Wave
Wavefront

با این ساختار
معرفی اصطلاح جدید
باعث Rewrite
تعریف پایه نمی شود.

Version Control برای کتاب

هر تغییر مهم
باید قابل ردیابی باشد.


v1.0

Initial Release


v1.0.1

Typo + Broken Link Fixes


v1.1

Technical Corrections


v1.2

Updated Architecture Notes


v2.0

Major Structural Revision

Change Log چه اطلاعاتی داشته باشد؟

  • تاریخ تغییر،
  • نسخه،
  • Section یا Chapter تغییر یافته،
  • نوع تغییر،
  • دلیل تغییر،
  • Source جدید در صورت وجود،
  • و اینکه تغییر روی Cross Referenceهای دیگر اثر داشته یا نه.

اگر یک Section دیگر معتبر نبود چه کنیم؟

نباید همیشه
بلافاصله Section را حذف کرد.

ابتدا مشخص شود:


Old Section

    │
    ▼

Still Historically Useful?

   /   
 Yes    No
  │      │
  ▼      ▼

Mark Context   Remove or
Clearly        Redirect

اگر موضوع
صرفا مربوط به معماری قدیمی است
اما هنوز ارزش آموزشی دارد،
می تواند با Context تاریخی
حفظ شود.

Glossary باید همراه کتاب Update شود

اگر اصطلاح جدیدی
به فصل های اصلی اضافه شود،
باید بررسی شود
آیا Glossary نیز
به تعریف آن نیاز دارد.


New Technical Term

       │
       ▼

Used Repeatedly?

    /     
  Yes      No
   │        │
   ▼        ▼

Add to      Definition in
Glossary    Local Context May Be Enough

Master Index نیز باید هماهنگ بماند

اضافه کردن یک Chapter
یا تغییر ساختار یک موضوع
ممکن است
روی Master Index،
Learning Path
و Question Map
اثر داشته باشد.

  • Knowledge Map را بررسی کنید.
  • Learning Pathها را بررسی کنید.
  • Question Map را بررسی کنید.
  • Cross Referenceها را بررسی کنید.
  • Navigation را بررسی کنید.

FAQها از رفتار واقعی Reader تغذیه شوند

پس از انتشار،
سوال هایی که واقعا
توسط Readerها تکرار می شوند
می توانند برای بهبود FAQ
ارزشمند باشند.


Repeated Reader Question

        │
        ▼

Is Answer Already Clear?

      /    
    Yes     No
     │       │
     ▼       ▼

No Change   Improve Main Text
            or FAQ

اگر یک سوال
بارها پرسیده شود،
ممکن است مشکل
فقط نبود FAQ نباشد؛
شاید متن اصلی
به اندازه کافی روشن نیست.

Feedback را دسته بندی کنید

نوع Feedback اقدام
اشتباه فنی بررسی فوری
ابهام آموزشی بررسی متن و Example
Typo اصلاح مستقیم
درخواست موضوع جدید بررسی ارتباط با Scope کتاب
نظر شخصی درباره Style بررسی در سطح Editorial، نه تغییر فوری

از Scope کتاب محافظت کنید

یک کتاب جامع
می تواند به راحتی
به مجموعه ای بی پایان
از موضوعات جانبی تبدیل شود.

قبل از اضافه کردن موضوع جدید
سه سوال بپرسید:

  1. آیا این موضوع برای فهم GPU ضروری است؟
  2. آیا در ساختار فعلی جای مشخصی دارد؟
  3. آیا نبود آن یک Gap واقعی ایجاد می کند؟

اگر پاسخ
به این سوال ها منفی باشد،
موضوع احتمالا
مقاله مستقل بهتری است.

هر چیزی نباید داخل کتاب اصلی قرار بگیرد

موضوعاتی مانند:

  • مقایسه دو GPU مشخص،
  • راهنمای خرید فصلی،
  • Benchmark یک Game،
  • بررسی یک Driver،
  • Overclocking یک Product خاص،
  • یا تحلیل یک Architecture تازه منتشر شده

می توانند
به صورت مقاله مستقل منتشر شوند
و از کتاب اصلی
Cross Reference بگیرند.


GPU Encyclopedia

      │
      ├── Stable Concepts
      │
      └── Internal References
             │
             ▼
       Specialized Articles

هر Update دوباره QA می خواهد

حتی یک تغییر کوچک
می تواند
Cross Reference
یا HTML Structure
را خراب کند.


Edit

 │
 ▼

Technical Check

 │
 ▼

HTML Check

 │
 ▼

Links Check

 │
 ▼

Affected Sections Check

 │
 ▼

Publish Update

Regression چیست؟

گاهی یک اصلاح
مشکل جدیدی
در بخش دیگری ایجاد می کند.

برای مثال:


Rename Section ID

       │
       ▼

Section Works

       │
       ▼

But Old Links Break

       │
       ▼

Regression

به همین دلیل
بعد از Update
فقط بخش ویرایش شده
نباید بررسی شود.

بازبینی دوره ای چه چیزهایی را بررسی کند؟

  • Broken Linkها.
  • Sourceهای قدیمی.
  • Terminologyهای منسوخ.
  • Standardهای تغییر یافته.
  • Sectionهای دارای ادعای زمان محور.
  • FAQهای کم ارزش یا تکراری.
  • Cross Referenceهای شکسته.
  • مشکلات Mobile.
  • Accessibility Regression.
  • Performance صفحه.

تاریخ بازبینی چه زمانی تغییر کند؟

تاریخ
«آخرین بازبینی»
نباید فقط به دلیل
اصلاح Typo
به روز شود.

بهتر است زمانی تغییر کند
که:

  • Technical Review واقعی انجام شده باشد،
  • Sourceها دوباره بررسی شده باشند،
  • یا بخش قابل توجهی از محتوا Update شده باشد.

Framework را برای هر Update تغییر ندهید

Framework
باید مانند Interface پایدار عمل کند.


Stable Framework

      │
      ├── New Chapter
      ├── Correction
      ├── New Example
      └── New Reference

without

Rebuilding Everything

کامپوننت جدید
فقط زمانی اضافه شود
که یک نیاز تکرارشونده
در چند بخش کتاب
وجود داشته باشد.

قانون اضافه کردن Component جدید

قبل از ساخت Component جدید:

  1. بررسی شود آیا Component موجود همین کار را انجام می دهد.
  2. مشخص شود نیاز فقط مربوط به یک Section نیست.
  3. نام Component با Naming Convention هماهنگ باشد.
  4. رفتار Mobile تعریف شود.
  5. Accessibility آن مشخص باشد.
  6. در Framework ثبت شود.

Component جدید باید یک Pattern واقعی را حل کند،
نه یک مشکل موقت در یک Paragraph.

Master Update Flow


New Information / Correction

          │
          ▼

Verify Source

          │
          ▼

Determine Scope

          │
          ▼

Core Concept
or
Local Update?

          │
          ▼

Edit Minimum Necessary Area

          │
          ▼

Check Terminology

          │
          ▼

Check Cross References

          │
          ▼

Check Glossary / Index

          │
          ▼

HTML + Mobile QA

          │
          ▼

Regression Check

          │
          ▼

Update Change Log

          │
          ▼

Publish

Maintenance Priority — چه چیزی زودتر اصلاح شود؟
اولویت نوع مشکل
Critical اشتباه فنی جدی یا اطلاعات گمراه کننده
High Source نادرست، Link اصلی شکسته، HTML Structure خراب
Medium ابهام آموزشی، Terminology ناسازگار، مشکل Mobile
Low Typo جزئی، تغییر Style، بهبود اختیاری

Engineering Insight — کتاب پایدار بهتر از کتاب همیشه در حال بازنویسی است

اگر هر معماری جدید
باعث تغییر ساختار اصلی کتاب شود،
کتاب به مرور
انسجام خود را از دست می دهد.

طراحی بهتر این است:


Stable Conceptual Core

        +

Replaceable Examples

        +

Updatable References

        +

Local Architecture Notes

        │
        ▼

Long-Lived Technical Book

Common Mistakes — اشتباهات رایج در نگهداری کتاب
  • برای هر GPU جدید فصل جدید نسازید.
  • Example یک Vendor را به تعریف عمومی تبدیل نکنید.
  • ID منتشر شده را بدون نیاز تغییر ندهید.
  • بعد از اصلاح یک Chapter، Cross Referenceها را فراموش نکنید.
  • Glossary را از Updateهای اصلی جدا نگه ندارید.
  • Change Log را فقط به حافظه تیم نسپارید.
  • Typo Fix را Technical Review کامل حساب نکنید.
  • Feedback خواننده را بدون Verification وارد متن نکنید.
  • هر موضوع جالبی را وارد Scope کتاب اصلی نکنید.
  • Framework را برای حل یک مشکل محلی تغییر ندهید.

Checklist هر Update

  • دلیل Update مشخص است.
  • Source معتبر بررسی شده است.
  • Scope تغییر مشخص شده است.
  • کمترین بخش لازم ویرایش شده است.
  • Terminology با Framework هماهنگ است.
  • ادعای عددی جدید Source دارد.
  • Cross Referenceهای مرتبط بررسی شده اند.
  • Glossary در صورت نیاز Update شده است.
  • Master Index در صورت نیاز Update شده است.
  • TOC در صورت تغییر Chapter بررسی شده است.
  • IDهای منتشر شده حفظ شده اند.
  • HTML Validate شده است.
  • Mobile Layout بررسی شده است.
  • Regression Check انجام شده است.
  • Change Log ثبت شده است.

چرخه عمر کتاب GPU


Research

   │
   ▼

Framework

   │
   ▼

Writing

   │
   ▼

Technical Review

   │
   ▼

Editorial QA

   │
   ▼

Publication

   │
   ▼

Reader Feedback

   │
   ▼

Periodic Technical Review

   │
   ▼

Controlled Updates

   │
   ▼

New Stable Version

خلاصه سیاست نگهداری

  • هسته مفهومی کتاب باید پایدار بماند.
  • اطلاعات Architecture-Specific به صورت محلی Update شوند.
  • Product Launch به تنهایی دلیل Rewrite کتاب نیست.
  • هر اصلاح فنی باید بر Source معتبر تکیه داشته باشد.
  • IDهای منتشر شده تا حد ممکن ثابت بمانند.
  • Glossary، Index و Cross Referenceها بخشی از هر Update هستند.
  • هر Update نیازمند Regression Check است.
  • Framework فقط برای نیاز ساختاری واقعی تغییر کند.
  • موضوعات Product-Specific بهتر است در مقاله های مستقل قرار گیرند.
  • Feedback خوانندگان باید Verification شود.
  • Change Log باید تاریخچه تغییرات را حفظ کند.
  • هدف Update افزایش دقت و وضوح است، نه افزایش بی پایان حجم کتاب.

وضعیت نهایی

با اضافه شدن سیاست نگهداری،
چرخه کامل کتاب
از تولید محتوا
تا انتشار
و Updateهای آینده
تعریف شده است.


CONTENT

   ✓

REFERENCE

   ✓

FINAL REVIEW

   ✓

TECHNICAL QA

   ✓

PUBLICATION QA

   ✓

MAINTENANCE POLICY

   ✓

از این مرحله به بعد
دیگر ادامه منطقی پروژه
تولید بخش جدید نیست.

مرحله مفید بعدی
اجرای بازبینی یکپارچه
روی HTML کامل کتاب
و پیدا کردن
IDهای تکراری،
Linkهای شکسته،
ساختارهای ناسالم،
تکرارها
و ناسازگاری های Framework
در خود فایل نهایی است.


مرحله:
ممیزی نهایی

نوع:
Final Audit Runbook

کاربرد:
اجرای بازبینی یکپارچه روی نسخه کامل کتاب


GPU BOOK FINAL AUDIT

Runbook نهایی برای بررسی نسخه کامل کتاب GPU

در این مرحله
دیگر فصل آموزشی جدیدی
به کتاب اضافه نمی شود.

هدف
اجرای یک Audit واقعی
روی نسخه کامل HTML است.

یعنی کتاب
از ابتدا تا انتها
به عنوان یک Document واحد
بررسی شود
تا مشکلاتی که هنگام نوشتن فصل های جداگانه
قابل مشاهده نبودند
پیدا و اصلاح شوند.


هدف Final Audit

Final Audit
باید مشخص کند
آیا نسخه کامل کتاب
از نظر:

  • ساختار،
  • دقت فنی،
  • Framework،
  • Navigation،
  • Cross Reference،
  • Terminology،
  • تکرار،
  • و Rendering

به عنوان یک مجموعه واحد
سالم است یا نه.

اصل Audit: ابتدا مشکل را پیدا کن، بعد اصلاح کن

ویرایش مستقیم
بدون داشتن تصویر کامل
می تواند
مشکل جدید ایجاد کند.


Full Document

      │
      ▼

Scan

      │
      ▼

Find Problems

      │
      ▼

Classify

      │
      ▼

Prioritize

      │
      ▼

Fix

      │
      ▼

Validate Again

این روش
از اصلاح پراکنده
و بازگشت مکرر مشکلات
جلوگیری می کند.

Audit را به چند گروه تقسیم کنید

Structure Audit

HTML،
Sectionها،
Tagها
و Nesting.

ID Audit

IDهای تکراری،
نام گذاری
و Anchorها.

Previous،
Next،
TOC
و Cross Referenceها.

Content Audit

تکرار،
ترتیب،
Depth
و کیفیت آموزشی.

Technical Audit

ادعاها،
عددها،
اصطلاحات
و معماری.

Rendering Audit

Boxها،
Tableها،
Diagramها
و Mobile Layout.

1. Structure Audit

در اولین Pass
فقط ساختار HTML بررسی شود.

  • هر section بسته شده باشد.
  • Closing Tag اضافی وجود نداشته باشد.
  • divها به شکل صحیح Nest شده باشند.
  • p شامل Block Element نباشد.
  • ul و ol ساختار معتبر داشته باشند.
  • li خارج از List وجود نداشته باشد.
  • table ساختار صحیح داشته باشد.
  • details و summary صحیح Nest شده باشند.
  • pre و code به درستی بسته شده باشند.
  • nav خارج از Container مورد انتظار قرار نگرفته باشد.

2. Paragraph Structure Audit

این بخش
به طور خاص
برای جلوگیری از همان نوع مشکل Rendering
که Box یا متن
از Container مورد انتظار خارج می شود
مهم است.


Check for

<p>

    Text

    <div>
    <table>
    <section>
    <pre>
    <ul>

</p>

اگر Block Element
درون Paragraph باشد،
Browser ممکن است
به صورت خودکار
Paragraph را قبل از آن ببندد.

در نتیجه
ساختار Render شده
می تواند با HTML ظاهری
متفاوت شود.

3. ID Audit

تمام IDها
باید در یک لیست
استخراج شوند.


Extract All IDs

      │
      ▼

Sort

      │
      ▼

Find Duplicates

      │
      ▼

Check Naming

      │
      ▼

Check References

سه نوع مشکل
باید پیدا شود:

  • ID تکراری،
  • ID بدون استفاده در Navigation مهم،
  • و Link به ID ناموجود.

4. Naming Convention IDها

IDها
باید معنی دار
و قابل پیش بینی باشند.


Preferred

gpu-memory-bandwidth

gpu-ray-tracing-bvh

gpu-ai-acceleration


Avoid

section-22

box-final-x

random-id-4

اما اگر یک ID
قبلا منتشر شده باشد،
پایداری Link
از زیباتر شدن نام
مهم تر است.

5. aria-labelledby Audit

برای هر:


aria-labelledby="some-title"

باید بررسی شود
که:


id="some-title"

واقعا در Document وجود دارد.

همچنین بهتر است
ID مورد اشاره
روی Heading مرتبط
قرار گرفته باشد.

6. Table of Contents Audit

TOC
باید از روی نسخه نهایی Document
بررسی شود،
نه از روی برنامه اولیه کتاب.

  • تمام Chapterهای اصلی وجود دارند.
  • ترتیب Chapterها صحیح است.
  • عنوان ها با Heading واقعی یکسان هستند.
  • تمام hrefها مقصد معتبر دارند.
  • Chapter حذف شده باقی نمانده است.
  • Chapter جدید فراموش نشده است.

7. Previous / Next Audit

هر Chapter اصلی
باید به Chapter قبل
و بعد صحیح
متصل باشد.


Chapter A

Next → Chapter B


Chapter B

Previous → Chapter A
Next → Chapter C


Chapter C

Previous → Chapter B

اگر Chapter B
در Next فصل A باشد،
Previous فصل B
نیز باید به A برگردد.

8. Cross Reference Audit

Cross Referenceها
باید دو شرط داشته باشند:

  1. مقصد واقعی وجود داشته باشد.
  2. ارتباط مفهومی واقعی وجود داشته باشد.

وجود Link
فقط برای افزایش تعداد Internal Link
ارزش آموزشی ندارد.

9. Terminology Audit

برای اصطلاحات مهم
یک Canonical Form
انتخاب شود.

مفهوم فرم ثابت
Memory Bandwidth Memory Bandwidth
Video Memory VRAM
Execution Group Warp / Wave
Pixel Processing Pixel / Fragment Shader
Render Backend Render Output
Performance Limiter Bottleneck

فرم های جایگزین
فقط وقتی استفاده شوند
که تفاوت معماری یا Context
واقعا وجود دارد.

10. Vendor Language Audit

متن باید بررسی شود
تا نام یک Vendor
به عنوان تعریف عمومی
استفاده نشده باشد.


General Concept

Execution Group


Examples

Warp
Wave
Wavefront

در بخش های عمومی
ابتدا Concept گفته شود
و سپس
Vendor Terminology
به عنوان Example معرفی شود.

11. Duplication Audit

در نسخه کامل
باید بخش هایی که
تقریبا یک متن مشابه
را چند بار تکرار می کنند
پیدا شوند.

تکرارها
در چهار گروه قرار گیرند:

نوع اقدام
مرور ضروری حفظ
تکرار با Context جدید حفظ یا کوتاه سازی
تکرار تقریبا کامل ادغام
تکرار بدون ارزش آموزشی حذف

12. Summaryها را جداگانه بررسی کنید

Summary
نباید دوباره
کل فصل را بازنویسی کند.

یک Summary خوب
فقط نقاطی را نگه می دارد
که Reader
باید بعد از ترک Chapter
به خاطر داشته باشد.


Chapter

100% Detail

      │
      ▼

Summary

10–20%
Most Important Ideas

13. FAQ Audit

برای هر FAQ بپرسید:

  • آیا این سوال واقعا ممکن است پرسیده شود؟
  • آیا جواب آن در متن اصلی مبهم بوده است؟
  • آیا جواب FAQ فقط Copy از Summary است؟
  • آیا FAQ مفهوم اشتباه رایجی را اصلاح می کند؟

FAQهای کم ارزش
می توانند حذف شوند
تا پایان Chapter
سنگین نشود.

14. Depth Audit

هر Chapter
از نظر عمق
با هدف نهایی کتاب
مقایسه شود.


Too Shallow

No Real Understanding


Target

Conceptual
+
Technical
+
Practical


Too Deep

Microarchitecture Detail
without Reader Value

جزئیات عمیق
اگر برای فهم
یا Performance Analysis
ارزش مستقیمی ندارند،
می توانند حذف شوند.

15. Numeric Claim Audit

در کل Document
موارد زیر جستجو شوند:


%

GHz

MHz

GB/s

TB/s

ms

ns

cycles

TFLOPS

TOPS

Watts

°C

x16 / x8 / x4

Gen 3 / Gen 4 / Gen 5

هر عدد
باید مشخص شود:

  • عمومی است؟
  • مثال آموزشی است؟
  • Specification است؟
  • Architecture-Specific است؟
  • Source لازم دارد؟

16. Formula Audit

فرمول های کتاب
باید از دو نظر بررسی شوند:

  • درستی ریاضی،
  • و Context استفاده.

برای مثال:


Frame Time

=

1000 / FPS

وقتی FPS
به صورت Frame در Second
و Frame Time
به Millisecond بیان می شود،
رابطه درست است.

اما باید روشن باشد
که این رابطه
بر اساس Average Rate
یک مدل ساده است
و Frame-Time Variance
را نشان نمی دهد.

17. Diagram Audit

هر Diagram
باید یکی از این کارها را انجام دهد:

  • Flow را نشان دهد،
  • Hierarchy را نشان دهد،
  • Comparison را ساده کند،
  • یا Relationship را توضیح دهد.

اگر Diagram
فقط همان Paragraph را
با فلش تکرار کرده است،
ممکن است ارزش کافی نداشته باشد.

18. Table Audit

Tableها
باید برای Comparison واقعی
استفاده شوند.

اگر Table
فقط یک لیست دو ستونه طولانی است
که روی Mobile
خوانایی را کاهش می دهد،
ممکن است Card
یا List
انتخاب بهتری باشد.

19. Component Audit

تمام Classهای دارای Prefix:


ss-

استخراج شوند
و با Componentهای Framework
مقایسه شوند.

هدف:

  • پیدا کردن Componentهای تعریف نشده،
  • نام های اشتباه،
  • Variantهای تکراری،
  • و Classهایی که فقط یک بار استفاده شده اند.

20. Class Typo Audit

حتی یک Character اشتباه
در Class
می تواند باعث شود
Box بدون Style نمایش داده شود.


Correct

ss-engineering-insight


Possible Typo

ss-enginering-insight

ss-engineering-insights

این خطاها
در Document بسیار بلند
به صورت دستی
به راحتی دیده نمی شوند.

21. Rendering Audit

نسخه نهایی
باید در Browser واقعی
از ابتدا تا انتها
بررسی شود.

به طور خاص
به دنبال این موارد باشید:

  • متن خارج Box،
  • Box شکسته،
  • فاصله غیرعادی،
  • Table خارج Container،
  • Diagram بریده شده،
  • Heading بدون Style،
  • FAQ بازشونده خراب،
  • و Navigation نامرتب.

22. Responsive Audit

حداقل این حالت ها
بررسی شوند:


Mobile Portrait

Mobile Landscape

Tablet

Laptop

Desktop

تمرکز اصلی
روی Sectionهایی باشد
که:

  • Table بزرگ دارند،
  • Diagram طولانی دارند،
  • Card Grid دارند،
  • یا متن انگلیسی طولانی دارند.

23. Reading Continuity Audit

کتاب
یک بار بدون ویرایش
از ابتدا تا انتها
خوانده شود.

در این Pass
به جای Syntax
روی تجربه Reader تمرکز شود:

  • آیا موضوعی زودتر از پیش نیازش آمده است؟
  • آیا Chapter Transition طبیعی است؟
  • آیا یک مفهوم بیش از حد دیر تعریف شده است؟
  • آیا بخش هایی حس تکرار شدید دارند؟
  • آیا بخش هایی بیش از حد طولانی شده اند؟
  • آیا ناگهان سطح متن خیلی تخصصی می شود؟

24. مشکلات را Prioritize کنید

اولویت نمونه
P0 اشتباه فنی جدی یا HTML خراب کننده صفحه
P1 Link شکسته، ID Duplicate، Box Rendering مشکل دار
P2 Terminology ناسازگار، تکرار زیاد، Mobile Issue
P3 بهبود نگارشی، فاصله، Style جزئی

ابتدا P0 و P1
رفع شوند.

ویرایش Style
قبل از رفع مشکل ساختاری
اولویت ندارد.

25. اصلاحات مشابه را گروهی انجام دهید

به جای اصلاح
هر خطا در لحظه کشف،
مشکلات مشابه
در یک Batch قرار بگیرند.


Batch A

Broken IDs


Batch B

Invalid Paragraph Nesting


Batch C

Terminology


Batch D

Cross References


Batch E

Duplicate Content

این روش
Consistency اصلاحات
را بیشتر می کند.

26. بعد از اصلاح، Regression Pass اجرا شود

پس از هر Batch مهم:


Fix

 │
 ▼

Validate

 │
 ▼

Check Neighboring Sections

 │
 ▼

Check Related Links

 │
 ▼

Render Again

هیچ Fix مهمی
بدون Validation مجدد
تمام شده محسوب نشود.

ترتیب کامل Final Audit


PASS 01
HTML Structure

      │
      ▼

PASS 02
Paragraph / Block Nesting

      │
      ▼

PASS 03
IDs

      │
      ▼

PASS 04
aria-labelledby

      │
      ▼

PASS 05
TOC

      │
      ▼

PASS 06
Previous / Next

      │
      ▼

PASS 07
Cross References

      │
      ▼

PASS 08
Framework Components

      │
      ▼

PASS 09
Terminology

      │
      ▼

PASS 10
Vendor Neutrality

      │
      ▼

PASS 11
Numeric Claims

      │
      ▼

PASS 12
Technical Claims

      │
      ▼

PASS 13
Duplication

      │
      ▼

PASS 14
FAQ / Summary

      │
      ▼

PASS 15
Tables / Diagrams

      │
      ▼

PASS 16
Mobile Rendering

      │
      ▼

PASS 17
Accessibility

      │
      ▼

PASS 18
Full Reading

      │
      ▼

PASS 19
Regression

      │
      ▼

PASS 20
Release Candidate

Master Audit Checklist

  • HTML Structure بررسی شد.
  • Paragraph Nesting بررسی شد.
  • Block Element داخل p باقی نمانده است.
  • ID Duplicate وجود ندارد.
  • aria-labelledbyها معتبر هستند.
  • TOC با Document نهایی هماهنگ است.
  • Previous / Next Navigation درست است.
  • Cross Reference شکسته وجود ندارد.
  • تمام ss-* Classها متعلق به Framework هستند.
  • Class Typo وجود ندارد.
  • Terminology یکسان شده است.
  • Vendor Terminology در Context درست استفاده شده است.
  • ادعاهای عددی بررسی شده اند.
  • Sourceهای لازم مشخص شده اند.
  • فرمول ها بررسی شده اند.
  • تکرارهای غیرضروری حذف شده اند.
  • Summaryها کوتاه و مفید هستند.
  • FAQها ارزش مستقل دارند.
  • Diagramها ارزش آموزشی دارند.
  • Tableها برای Comparison واقعی استفاده شده اند.
  • Mobile Layout سالم است.
  • Desktop Layout سالم است.
  • Accessibility پایه بررسی شده است.
  • Full Reading انجام شده است.
  • Regression Pass انجام شده است.

Final Audit Principle

در نسخه نهایی
مهم نیست
چند Chapter نوشته شده است.

مهم این است
که Reader
یک کتاب واحد
و منسجم ببیند.

اگر مرز میان فصل هایی که در زمان های مختلف نوشته شده اند
برای Reader قابل تشخیص باشد،
ویرایش نهایی هنوز تمام نشده است.

مرحله بعدی عملی پروژه

ساختار،
محتوا،
Glossary،
Index،
Final Review،
Publication Policy
و Maintenance Policy
اکنون تعریف شده اند.

از این نقطه
مرحله مفید بعدی
نوشتن متن جدید نیست.

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

HTML کامل کتاب
به صورت یک فایل واحد
بررسی شود.


Complete GPU HTML

        │
        ▼

Automated Structural Scan

        │
        ▼

Duplicate ID Report

        │
        ▼

Broken Anchor Report

        │
        ▼

Invalid Nesting Report

        │
        ▼

Framework Class Report

        │
        ▼

Manual Technical Review

        │
        ▼

Clean Final Version

در آن مرحله
به جای اضافه کردن Chapter،
خود Document
تمیز و اصلاح می شود.

مرحله:
ابزار کنترل نهایی

نوع:
Automated HTML Audit

کاربرد:
پیدا کردن خطاهای ساختاری نسخه کامل کتاب


GPU BOOK AUTOMATED AUDIT

اسکریپت خودکار برای پیدا کردن خطاهای HTML کتاب GPU

در یک Document بسیار بزرگ،
بررسی دستی تمام IDها،
Anchorها،
Classها
و ساختارهای HTML
هم زمان بر است
و هم احتمال خطا دارد.

بنابراین قبل از بازبینی چشمی،
می توان یک Audit خودکار
روی فایل نهایی اجرا کرد
تا بخش بزرگی از مشکلات ساختاری
به صورت یک Report
استخراج شوند.


این ابزار چه چیزهایی را پیدا می کند؟

  • Duplicate IDها،
  • Anchorهای شکسته،
  • aria-labelledbyهای نامعتبر،
  • Classهای ss-* استفاده شده در Document،
  • Classهای مشکوک یا دارای Typo،
  • Headingهای بدون ID،
  • Navigation Linkهای خراب،
  • Imageهای بدون alt،
  • Tableهای خارج از ss-table-wrapper،
  • Code Diagramهای خارج از Component استاندارد،
  • و بعضی الگوهای مشکوک ساختاری.


این ابزار جای HTML Validator را نمی گیرد

Browser
در بعضی HTMLهای نامعتبر
ساختار DOM را به صورت خودکار اصلاح می کند.

بنابراین
Audit Script
برای پیدا کردن مشکلات پروژه بسیار مفید است،
اما برای Validation کامل HTML
باید در کنار Validator استاندارد
و بررسی DOM واقعی مرورگر استفاده شود.

لیست Componentهای تایید شده Framework

در Script
ابتدا Classهای اصلی Framework
تعریف می شوند.


const approvedClasses = new Set([
    "ss-section",
    "ss-subsection",
    "ss-chapter-meta",
    "ss-chapter-header",
    "ss-section-kicker",
    "ss-lead",

    "ss-info",
    "ss-info--definition",
    "ss-info--note",
    "ss-info--warning",

    "ss-card",
    "ss-card-grid",

    "ss-table-wrapper",
    "ss-table",

    "ss-code-block",
    "ss-code-diagram",
    "ss-code-diagram--framed",

    "ss-under-hood",
    "ss-under-hood__header",
    "ss-under-hood__body",

    "ss-performance-impact",
    "ss-performance-impact__title",

    "ss-engineering-insight",
    "ss-engineering-insight__title",

    "ss-common-mistakes",
    "ss-common-mistakes__title",

    "ss-faq",
    "ss-faq__list",
    "ss-faq-item",
    "ss-faq-item__question",
    "ss-faq-item__answer",

    "ss-summary",
    "ss-check-list",
    "ss-quote",
    "ss-chapter-nav"
]);

اسکریپت اصلی Audit

پس از باز کردن نسخه کامل کتاب
در Browser،
این Script را می توان
در Developer Tools → Console
اجرا کرد.


(() => {

    const report = {
        duplicateIds: [],
        brokenAnchors: [],
        brokenAriaLabelledby: [],
        headingsWithoutId: [],
        unknownSSClasses: [],
        allSSClasses: [],
        imagesWithoutAlt: [],
        tablesWithoutWrapper: [],
        codeDiagramsWithoutWrapper: [],
        suspiciousParagraphs: [],
        chapterNavigationIssues: []
    };


    /* =====================================================
       APPROVED FRAMEWORK CLASSES
    ===================================================== */

    const approvedClasses = new Set([

        "ss-section",
        "ss-subsection",

        "ss-chapter-meta",
        "ss-chapter-header",
        "ss-section-kicker",
        "ss-lead",

        "ss-info",
        "ss-info--definition",
        "ss-info--note",
        "ss-info--warning",

        "ss-card",
        "ss-card-grid",

        "ss-table-wrapper",
        "ss-table",

        "ss-code-block",

        "ss-code-diagram",
        "ss-code-diagram--framed",

        "ss-under-hood",
        "ss-under-hood__header",
        "ss-under-hood__body",

        "ss-performance-impact",
        "ss-performance-impact__title",

        "ss-engineering-insight",
        "ss-engineering-insight__title",

        "ss-common-mistakes",
        "ss-common-mistakes__title",

        "ss-faq",
        "ss-faq__list",

        "ss-faq-item",
        "ss-faq-item__question",
        "ss-faq-item__answer",

        "ss-summary",

        "ss-check-list",

        "ss-quote",

        "ss-chapter-nav"

    ]);


    /* =====================================================
       1 — DUPLICATE IDs
    ===================================================== */

    const idMap = new Map();

    document.querySelectorAll("[id]").forEach(element => {

        const id = element.id;

        if (!idMap.has(id)) {
            idMap.set(id, []);
        }

        idMap.get(id).push(element);

    });

    idMap.forEach((elements, id) => {

        if (elements.length > 1) {

            report.duplicateIds.push({
                id,
                count: elements.length,
                elements
            });

        }

    });


    /* =====================================================
       2 — BROKEN INTERNAL ANCHORS
    ===================================================== */

    document.querySelectorAll('a[href^="#"]').forEach(link => {

        const href = link.getAttribute("href");

        if (!href || href === "#") {
            return;
        }

        const id = decodeURIComponent(href.slice(1));

        if (!document.getElementById(id)) {

            report.brokenAnchors.push({
                href,
                text: link.textContent.trim(),
                element: link
            });

        }

    });


    /* =====================================================
       3 — BROKEN ARIA-LABELLEDBY
    ===================================================== */

    document.querySelectorAll("[aria-labelledby]").forEach(element => {

        const ids = element
            .getAttribute("aria-labelledby")
            .trim()
            .split(/s+/);

        const missing = ids.filter(
            id => !document.getElementById(id)
        );

        if (missing.length) {

            report.brokenAriaLabelledby.push({
                element,
                missing
            });

        }

    });


    /* =====================================================
       4 — HEADINGS WITHOUT IDs
    ===================================================== */

    document
        .querySelectorAll("h1, h2, h3, h4, h5, h6")
        .forEach(heading => {

            if (!heading.id) {

                report.headingsWithoutId.push({
                    tag: heading.tagName,
                    text: heading.textContent.trim(),
                    element: heading
                });

            }

        });


    /* =====================================================
       5 — FRAMEWORK CLASS AUDIT
    ===================================================== */

    const allSSClasses = new Set();

    document.querySelectorAll('[class*="ss-"]').forEach(element => {

        element.classList.forEach(className => {

            if (className.startsWith("ss-")) {
                allSSClasses.add(className);
            }

        });

    });

    report.allSSClasses = [...allSSClasses].sort();

    report.unknownSSClasses = [...allSSClasses]
        .filter(className => !approvedClasses.has(className))
        .sort();


    /* =====================================================
       6 — IMAGES WITHOUT ALT
    ===================================================== */

    document.querySelectorAll("img").forEach(img => {

        if (!img.hasAttribute("alt")) {

            report.imagesWithoutAlt.push({
                src: img.getAttribute("src"),
                element: img
            });

        }

    });


    /* =====================================================
       7 — TABLE WRAPPER AUDIT
    ===================================================== */

    document.querySelectorAll("table.ss-table").forEach(table => {

        if (!table.closest(".ss-table-wrapper")) {

            report.tablesWithoutWrapper.push({
                element: table
            });

        }

    });


    /* =====================================================
       8 — CODE / PRE WRAPPER AUDIT
    ===================================================== */

    document.querySelectorAll("pre").forEach(pre => {

        const validParent =
            pre.closest(".ss-code-diagram") ||
            pre.closest(".ss-code-block");

        if (!validParent) {

            report.codeDiagramsWithoutWrapper.push({
                text: pre.textContent.trim().slice(0, 120),
                element: pre
            });

        }

    });


    /* =====================================================
       9 — SUSPICIOUS PARAGRAPH STRUCTURE
    ===================================================== */

    document.querySelectorAll("p").forEach(p => {

        const blockChildren = p.querySelectorAll(
            [
                "div",
                "section",
                "article",
                "table",
                "ul",
                "ol",
                "pre",
                "blockquote",
                "nav",
                "details"
            ].join(",")
        );

        if (blockChildren.length) {

            report.suspiciousParagraphs.push({
                text: p.textContent.trim().slice(0, 150),
                children: [...blockChildren],
                element: p
            });

        }

    });


    /* =====================================================
       10 — CHAPTER NAVIGATION
    ===================================================== */

    document
        .querySelectorAll(".ss-chapter-nav")
        .forEach(nav => {

            const links = [
                ...nav.querySelectorAll('a[href^="#"]')
            ];

            const broken = links.filter(link => {

                const href = link.getAttribute("href");

                if (!href || href === "#") {
                    return true;
                }

                return !document.getElementById(
                    decodeURIComponent(href.slice(1))
                );

            });

            if (broken.length) {

                report.chapterNavigationIssues.push({
                    navigation: nav,
                    brokenLinks: broken.map(link => ({
                        text: link.textContent.trim(),
                        href: link.getAttribute("href")
                    }))
                });

            }

        });


    /* =====================================================
       OUTPUT
    ===================================================== */

    const summary = {

        duplicateIds:
            report.duplicateIds.length,

        brokenAnchors:
            report.brokenAnchors.length,

        brokenAriaLabelledby:
            report.brokenAriaLabelledby.length,

        headingsWithoutId:
            report.headingsWithoutId.length,

        unknownSSClasses:
            report.unknownSSClasses.length,

        imagesWithoutAlt:
            report.imagesWithoutAlt.length,

        tablesWithoutWrapper:
            report.tablesWithoutWrapper.length,

        codeWithoutApprovedWrapper:
            report.codeDiagramsWithoutWrapper.length,

        suspiciousParagraphs:
            report.suspiciousParagraphs.length,

        chapterNavigationIssues:
            report.chapterNavigationIssues.length

    };


    console.log(
        "%cSTOKSHOP GPU BOOK AUDIT",
        "font-size:18px;font-weight:bold;"
    );

    console.table(summary);

    console.log(
        "Full report:",
        report
    );

    window.STOKSHOP_GPU_AUDIT = report;

})();

چگونه Report کامل را ببینیم؟

پس از اجرای Script،
Report در این Variable
قرار می گیرد:


STOKSHOP_GPU_AUDIT

برای مثال:


STOKSHOP_GPU_AUDIT.duplicateIds

Duplicate IDها را نشان می دهد.


STOKSHOP_GPU_AUDIT.brokenAnchors

Anchorهای شکسته را نشان می دهد.


STOKSHOP_GPU_AUDIT.unknownSSClasses

تمام Classهای
ss-*
که در لیست Framework
شناخته نشده اند
را نشان می دهد.

پیدا کردن Duplicate IDها


console.table(
    STOKSHOP_GPU_AUDIT.duplicateIds.map(item => ({
        id: item.id,
        count: item.count
    }))
);

اگر خروجی خالی باشد،
Duplicate ID
پیدا نشده است.

پیدا کردن Broken Anchorها


console.table(
    STOKSHOP_GPU_AUDIT.brokenAnchors.map(item => ({
        text: item.text,
        href: item.href
    }))
);

این بخش
به خصوص برای:

  • Table of Contents،
  • Cross Reference،
  • Previous / Next،
  • و Glossary Linkها

مهم است.

پیدا کردن Classهای خارج از Framework


console.table(
    STOKSHOP_GPU_AUDIT.unknownSSClasses
);

وجود یک Class
در این لیست
الزاما به معنی خطا نیست.

ممکن است:

  • Component معتبر جدیدی باشد که باید به Framework اضافه شود،
  • Class Variant معتبر باشد،
  • یا Typo باشد.

اما تمام آنها
باید دستی بررسی شوند.

چگونه Element مشکل دار را سریع پیدا کنیم؟

Chrome DevTools
امکان Inspect مستقیم
Element ذخیره شده در Report
را می دهد.

مثلا:


STOKSHOP_GPU_AUDIT.brokenAnchors[0].element

یا:


STOKSHOP_GPU_AUDIT.tablesWithoutWrapper[0].element

روی Element خروجی
می توان Right Click
و سپس
Reveal in Elements Panel
را انتخاب کرد.

بررسی زنجیره Navigation

این Script
تمام Navigationهای فصل ها
را به صورت جدول نمایش می دهد:


console.table(

    [...document.querySelectorAll(".ss-chapter-nav")]

    .map((nav, index) => {

        const section = nav.closest("section[id]");

        const links =
            [...nav.querySelectorAll("a")];

        return {

            index: index + 1,

            chapter:
                section?.id || "NO_SECTION_ID",

            previous:
                links[0]?.getAttribute("href") || "",

            toc:
                links[1]?.getAttribute("href") || "",

            next:
                links[2]?.getAttribute("href") || ""

        };

    })

);

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

استخراج تمام IDهای کتاب


copy(

    [...document.querySelectorAll("[id]")]

    .map(element => element.id)

    .sort()

    .join("n")

);

این دستور
تمام IDها را
در Clipboard قرار می دهد.

برای بررسی:

  • Naming،
  • موضوعات تکراری،
  • و ساختار Anchorها

بسیار مفید است.

استخراج تمام Classهای ss-* واقعی کتاب


copy(

    [...new Set(

        [...document.querySelectorAll('[class*="ss-"]')]

        .flatMap(element =>
            [...element.classList]
            .filter(className =>
                className.startsWith("ss-")
            )
        )

    )]

    .sort()

    .join("n")

);

این خروجی
برای مقایسه
با Framework اصلی
بسیار مهم است.

بررسی Tableها


console.table(

    [...document.querySelectorAll("table")]

    .map((table, index) => ({

        index: index + 1,

        class:
            table.className,

        wrapped:
            !!table.closest(".ss-table-wrapper"),

        rows:
            table.rows.length,

        chapter:
            table.closest("section[id]")?.id || ""

    }))

);

پیدا کردن Paragraphهای بیش از حد طولانی

برای کنترل Reading Flow
می توان Paragraphهای بسیار بزرگ
را جدا کرد.


console.table(

    [...document.querySelectorAll("p")]

    .map((p, index) => ({

        index,

        length:
            p.textContent.trim().length,

        preview:
            p.textContent
            .trim()
            .replace(/s+/g, " ")
            .slice(0, 100),

        chapter:
            p.closest("section[id]")?.id || ""

    }))

    .filter(item =>
        item.length > 500
    )

    .sort((a, b) =>
        b.length - a.length
    )

);

این خروجی
به معنی الزام برای کوتاه کردن نیست،
اما محل های نیازمند بررسی
را مشخص می کند.

پیدا کردن Headingهای تکراری


(() => {

    const map = new Map();

    document
        .querySelectorAll("h2, h3")
        .forEach(h => {

            const text =
                h.textContent
                .trim()
                .replace(/s+/g, " ");

            if (!map.has(text)) {
                map.set(text, []);
            }

            map.get(text).push(h);

        });

    console.table(

        [...map.entries()]

        .filter(([text, elements]) =>
            elements.length > 1
        )

        .map(([text, elements]) => ({

            heading: text,

            count:
                elements.length

        }))

    );

})();

تکرار Heading
همیشه خطا نیست.

برای مثال
«خلاصه فصل»
طبیعتا تکرار می شود.

اما Headingهای موضوعی تکراری
می توانند نشان دهنده
Sectionهای Duplicate باشند.

استخراج فهرست واقعی فصل ها از خود HTML


console.table(

    [...document.querySelectorAll(
        "section.ss-section[id]"
    )]

    .map((section, index) => ({

        index: index + 1,

        id:
            section.id,

        title:
            section.querySelector("h2, h3")
            ?.textContent
            .trim()
            .replace(/s+/g, " ")
            || "NO TITLE"

    }))

);

این Table
مرجع خوبی برای ساخت
Table of Contents نهایی
است.

پیدا کردن Elementهای خالی مشکوک


console.log(

    [...document.querySelectorAll(
        "p, div.ss-card, section.ss-subsection, li"
    )]

    .filter(element =>
        !element.textContent.trim() &&
        !element.querySelector("img, video, svg, canvas")
    )

);

گاهی Element خالی
فقط فاصله غیرعادی
در صفحه ایجاد می کند.

بررسی Imageها


console.table(

    [...document.images]

    .map((img, index) => ({

        index: index + 1,

        src:
            img.currentSrc || img.src,

        alt:
            img.getAttribute("alt"),

        width:
            img.naturalWidth,

        height:
            img.naturalHeight,

        loading:
            img.getAttribute("loading"),

        chapter:
            img.closest("section[id]")?.id || ""

    }))

);

خروجی مطلوب Audit

در حالت ایده آل
Report اصلی
باید تقریبا به این شکل برسد:


duplicateIds
0


brokenAnchors
0


brokenAriaLabelledby
0


unknownSSClasses
0
or reviewed exceptions


tablesWithoutWrapper
0


codeWithoutApprovedWrapper
0


chapterNavigationIssues
0

Headingهای بدون ID
یا Imageهای بدون alt
بسته به نوع Element
ممکن است نیازمند بررسی دستی باشند.

Under the Hood — Script فقط Structure را می بیند، نه معنی را

Automated Audit
می تواند بگوید:

  • Link وجود ندارد،
  • ID تکراری است،
  • Class ناشناخته است،
  • یا Table Wrapper ندارد.

اما نمی تواند
به تنهایی تشخیص دهد:

  • تعریف Ray Tracing علمی و دقیق است یا نه،
  • یک مثال گمراه کننده است یا نه،
  • یک Paragraph بیش از حد عمیق است یا نه،
  • یا یک Chapter باید ادغام شود یا نه.


Automated Audit

Structure


        +


Human / Technical Review

Meaning


        │
        ▼

Reliable Final Book

Workflow پیشنهادی برای فایل نهایی


STEP 1

Merge Complete HTML


STEP 2

Open in Browser


STEP 3

Run Automated Audit


STEP 4

Fix P0 / P1 Problems


STEP 5

Run Audit Again


STEP 6

Technical Review


STEP 7

Terminology / Duplication Review


STEP 8

Mobile Rendering Review


STEP 9

Final Regression Audit


STEP 10

Release Candidate

Automated Audit Checklist

  • نسخه کامل HTML در Browser باز شده است.
  • Audit Script اجرا شده است.
  • Duplicate IDها بررسی شده اند.
  • Broken Anchorها بررسی شده اند.
  • aria-labelledbyها بررسی شده اند.
  • Framework Classها استخراج شده اند.
  • Classهای ناشناخته بررسی شده اند.
  • Table Wrapperها بررسی شده اند.
  • Code Diagram Wrapperها بررسی شده اند.
  • Navigation فصل ها بررسی شده است.
  • فهرست واقعی Chapterها استخراج شده است.
  • Headingهای تکراری بررسی شده اند.
  • Paragraphهای بسیار طولانی بررسی شده اند.
  • Imageها و Alt Textها بررسی شده اند.
  • پس از Fixها Script دوباره اجرا شده است.

نقطه تحویل نهایی

در این مرحله
تمام ابزارهای لازم
برای تبدیل نسخه کامل کتاب
به یک Document تمیز
تعریف شده اند.

گام بعدی دیگر
تولید Section جدید نیست.

گام بعدی
اجرای همین Audit
روی

HTML واقعی و کامل کتاب GPU

است.


Full GPU HTML

       │
       ▼

Run Audit

       │
       ▼

Generate Problem List

       │
       ▼

Fix Document

       │
       ▼

Re-Audit

       │
       ▼

Technical Review

       │
       ▼

Final Clean HTML

مرحله:
ممیزی منابع

نوع:
Source & Citation Audit

کاربرد:
بررسی صحت و محل استفاده منابع در نسخه نهایی کتاب


GPU BOOK SOURCE AUDIT

ممیزی نهایی Sourceها و ادعاهای فنی کتاب GPU

یک کتاب فنی
فقط با متن روان
قابل اعتماد نمی شود.

هر جا
ادعای دقیق،
عدد مشخص،
رفتار وابسته به معماری،
Standard،
Feature
یا محدودیت Hardware
بیان شده است،
باید مشخص باشد
این اطلاعات
از کجا آمده اند
و در چه Contextی معتبر هستند.

هدف این بخش
ساخت یک روش یکپارچه
برای کنترل Sourceها
در نسخه نهایی کتاب است.


قاعده اصلی

مفاهیم عمومی و پایدار
نیازی به Source بعد از هر جمله ندارند.

اما ادعاهای:

  • عددی،
  • Vendor-Specific،
  • Architecture-Specific،
  • Standard-Specific،
  • Product-Specific،
  • و Benchmark-Specific

باید
به Source مناسب متصل باشند.

Sourceها را به چند گروه تقسیم کنید

نوع Source بهترین کاربرد
Official Architecture Documentation جزئیات معماری، واحدهای اجرایی، رفتار سخت افزار و اصطلاحات Vendor
Official Programming Guide Execution Model، Memory Model، Warp / Wave Behavior، Synchronization و Programming Details
Official API Documentation Graphics API، Compute API، Resource، Pipeline و Synchronization
Official Standard PCIe، HDMI، DisplayPort و سایر استانداردهای فنی
Technical Paper روش های الگوریتمی، Rendering Technique، Denoising و Research
Independent Technical Analysis Measurement، Benchmark و تحلیل رفتاری Hardware

اولویت Source


For Architecture Claim

Official Architecture Documentation

                │
                ▼

Official Programming Guide

                │
                ▼

Official Developer Documentation

                │
                ▼

Technical Paper

                │
                ▼

Independent Technical Analysis

Source ثانویه
نباید جای Source اصلی
را بگیرد
وقتی Documentation رسمی
برای همان ادعا وجود دارد.

ابتدا نوع Claim را مشخص کنید

Claim Type نمونه Source لازم؟
General Concept GPU برای Parallel Throughput طراحی شده است. معمولا خیر
Mathematical Relation Frame Time ≈ 1000 / FPS معمولا خیر
Architecture-Specific یک معماری مشخص Warp Size معینی دارد. بله
Product-Specific یک GPU مشخص مقدار معینی VRAM دارد. بله
Measured Result یک Benchmark مقدار معینی Performance نشان داده است. بله
Standard Limit یک نسخه رابط از Data Rate مشخصی پشتیبانی می کند. بله

ادعاهای عددی باید Context کامل داشته باشند

یک عدد
بدون Context
می تواند
حتی اگر خودش درست باشد،
گمراه کننده باشد.


Weak

Latency = 300 cycles


Better

On Architecture X
for Operation Y
under documented conditions,
latency is reported as ...

Source:
Official Architecture Guide

در یک کتاب عمومی
اگر Context دقیق
ارزش آموزشی زیادی ایجاد نمی کند،
گاهی حذف عدد
بهتر از ارائه عدد
بدون محدوده اعتبار است.

Architecture-Specific Claim چگونه نوشته شود؟

نامناسب مناسب تر
GPUها Warpهای 32 Thread دارند. در معماری های NVIDIA مورد نظر، Warp از تعداد مشخصی Thread تشکیل می شود؛ سایر معماری ها ممکن است گروه اجرایی متفاوتی داشته باشند.
Shared Memory همیشه 64 KB است. ظرفیت Shared / Local Memory به معماری و پیکربندی Compute Unit بستگی دارد.
Memory Latency برابر X Cycle است. Memory Latency به سطح حافظه، معماری، Access Pattern و شرایط اجرا وابسته است.

Vendor Terminology را با Source رسمی کنترل کنید

اصطلاحاتی مانند:

  • SM،
  • CUDA Core،
  • Tensor Core،
  • RT Core،
  • Compute Unit،
  • Wavefront،
  • Xe Core

تعاریف Vendor-Specific هستند.

اگر کتاب
رفتار دقیق یکی از آنها
را توضیح می دهد،
باید از Documentation همان Vendor
استفاده شود.

Standardها از Documentation رسمی بررسی شوند

برای موضوعاتی مانند:

  • PCI Express،
  • DisplayPort،
  • HDMI،
  • HDR Signaling،
  • و Display Timing

نباید فقط
به جدول های پراکنده اینترنتی
تکیه شود.


Standard Claim

      │
      ▼

Official Specification
or
Official Standard Documentation

Benchmark بدون Test Condition کامل نیست

اگر عدد Benchmark
در کتاب استفاده شود،
حداقل باید مشخص باشد:

  • GPU،
  • CPU،
  • Resolution،
  • Quality Setting،
  • Driver،
  • Benchmark Version،
  • و Metric

چه بوده است.


Benchmark Number

      +

Test Conditions

      +

Source

      │
      ▼

Meaningful Result

Metric باید همراه تعریف خود استفاده شود

اعدادی مانند:

  • TFLOPS،
  • TOPS،
  • Memory Bandwidth،
  • Texture Rate،
  • Pixel Rate

بدون تعریف Operation،
Precision
یا شرایط محاسبه
می توانند گمراه کننده باشند.

Source باید مشخص کند
Metric دقیقا
چگونه تعریف شده است.

عدد محاسبه شده را از عدد Source جدا کنید

گاهی کتاب
از Specification رسمی
یک مقدار جدید محاسبه می کند.


Official Values

Bus Width
Data Rate

      │
      ▼

Derived Calculation

Theoretical Memory Bandwidth

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

Derived

است
و مستقیما
از Source نقل نشده است.

Approximation را مشخص کنید

اگر یک مقدار
تقریبی است،
در متن
با عبارت هایی مانند:

  • تقریبا،
  • حدود،
  • در یک مدل ساده،
  • در حد مرتبه بزرگی،
  • یا بسته به معماری

مشخص شود.

Precision زبانی
بخشی از Precision فنی است.

Source را نزدیک Claim نگه دارید


Claim A
Source A

Claim B
Source B

Claim C
Source C


Preferred


Not


Many Claims

...

Huge Reference List

with unclear mapping

Reader
باید بتواند
بدون حدس زدن
رابطه Claim و Source
را تشخیص دهد.

یک Source را برای چند Claim نامرتبط استفاده نکنید

یک Documentation
ممکن است
برای Memory Behavior مناسب باشد
اما
برای Display Standard
هیچ ارزشی نداشته باشد.

Source
باید دقیقا
با Claim مربوط باشد.

Secondary Source چه زمانی مفید است؟

Source ثانویه
برای:

  • Benchmark،
  • تحلیل Cross-Architecture،
  • Measurement،
  • توضیح رفتار واقعی Hardware،
  • و مقایسه Implementationها

ارزش زیادی دارد.

اما برای تعریف رسمی
Feature یک Vendor،
Source رسمی
معمولا اولویت بالاتری دارد.

اگر دو Source با هم اختلاف داشتند


Source A

      │
      ▼

Different Result

      ▲
      │

Source B

      │
      ▼

Check

Definition
Version
Architecture
Test Condition
Measurement Method

اختلاف Sourceها
اغلب
به دلیل تفاوت Context است،
نه لزوما اشتباه یکی از آنها.

Source قدیمی همیشه Source اشتباه نیست

یک Documentation قدیمی
ممکن است
برای توضیح معماری همان نسل
کاملا معتبر باشد.

اما نباید
رفتار معماری قدیمی
بدون Qualification
به GPUهای جدید
تعمیم داده شود.


Old Source

      │
      ▼

Valid for
Old Architecture

      │
      ▼

Not Automatically Valid
for New Architecture

برای Sourceها Status تعریف کنید

Status معنا
Verified Source بررسی شده و Claim را مستقیما پشتیبانی می کند.
Context-Limited Source معتبر است اما فقط برای Architecture یا Version خاص.
Needs Review رابطه Source و Claim باید دوباره بررسی شود.
Replace Source بهتر یا رسمی تر باید جایگزین شود.
Remove Source به Claim مرتبط نیست یا اعتبار کافی ندارد.

Source Register برای پروژه

برای پروژه ای با این حجم
بهتر است
یک Source Register جداگانه وجود داشته باشد.

Field نمونه محتوا
Source ID GPU-SRC-001
Title Document Title
Publisher Vendor / Standards Body
Type Architecture Guide
Applies To Architecture / Standard Version
Used In Chapter / Section ID
Status Verified
Review Date YYYY-MM-DD

برای Claimهای حساس Claim Register بسازید

لازم نیست
تمام جمله های کتاب
در Claim Register باشند.

فقط Claimهای حساس:

  • اعداد،
  • Latency،
  • Throughput،
  • Architecture Behavior،
  • Feature Support،
  • و Standard Limitها

ثبت شوند.

Claim ID Section Claim Source Status
GPU-CLM-001 gpu-example-section Architecture-specific technical claim GPU-SRC-001 Verified

مسیر کامل Source Audit


Find Sensitive Claim

        │
        ▼

Classify Claim

        │
        ▼

Find Best Source Type

        │
        ▼

Verify Claim Against Source

        │
        ▼

Check Context

        │
        ▼

Check Architecture / Version

        │
        ▼

Add or Correct Citation

        │
        ▼

Record in Claim Register

        │
        ▼

Final Review

در Audit چه الگوهایی را جستجو کنیم؟

در HTML کامل
این Tokenها
می توانند نقاط حساس را پیدا کنند:


cycles

ns

ms

GHz

MHz

GB/s

TB/s

TFLOPS

TOPS

W

°C

%

x16

x8

x4

Gen 3

Gen 4

Gen 5

always

never

exactly

up to

وجود این کلمات
به معنی خطا نیست،
اما Section را
برای Source Review
کاندید می کند.

ادعاهای مطلق را جداگانه بررسی کنید

کلمات مطلق مانند:

  • همیشه،
  • هرگز،
  • تمام،
  • دقیقا،
  • حتما،
  • و بدون استثنا

در متن معماری
ریسک بالایی دارند.

اگر واقعا ضروری نیستند،
بهتر است با عبارت دقیق تر
جایگزین شوند.

برای هر Source پنج سوال بپرسید

  1. آیا Source معتبر است؟
  2. آیا دقیقا همین Claim را پشتیبانی می کند؟
  3. آیا نسخه یا Architecture درست است؟
  4. آیا Source هنوز معتبر و قابل دسترسی است؟
  5. آیا Source رسمی یا دقیق تری وجود دارد؟

کتاب را به دیوار Citation تبدیل نکنید

Source زیاد
همیشه
به معنی کتاب معتبرتر نیست.


Too Few Sources

Unverifiable Claims


Too Many Sources

Poor Reading Flow


Target

Sources
Where Verification Matters

مفاهیم پایه
می توانند روان باقی بمانند
و Sourceها
روی نقاط حساس متمرکز شوند.


اگر Source ادعای فعلی را پشتیبانی نکرد

Source را برای تطبیق با متن
تفسیر نکنید.

در این حالت
یکی از این کارها انجام شود:

  • Claim اصلاح شود،
  • Claim محدودتر شود،
  • Source مناسب تری پیدا شود،
  • یا Claim حذف شود.

Source باید Claim را پشتیبانی کند؛
Claim نباید به زور با Source هماهنگ شود.

Final Source Checklist

  • تمام Claimهای عددی پیدا شده اند.
  • تمام Claimهای Architecture-Specific پیدا شده اند.
  • Vendor-Specific Claimها بررسی شده اند.
  • Standard-Specific Claimها بررسی شده اند.
  • Benchmarkهای دارای عدد Context کامل دارند.
  • عددهای Derived از Source اصلی جدا مشخص شده اند.
  • Approximationها مشخص شده اند.
  • Source رسمی در صورت وجود در اولویت قرار گرفته است.
  • Sourceهای قدیمی از نظر Scope بررسی شده اند.
  • Source و Claim از نظر Architecture هماهنگ هستند.
  • Source و Claim از نظر Version هماهنگ هستند.
  • Citation نزدیک Claim قرار دارد.
  • Source نامرتبط حذف شده است.
  • Claim بدون Source لازم باقی نمانده است.
  • ادعاهای مطلق دوباره بررسی شده اند.
  • Claim Register به روز شده است.

مدل نهایی اعتماد فنی


Clear Claim

     +

Correct Context

     +

Reliable Source

     +

Correct Architecture / Version

     │
     ▼

Reliable Technical Statement

اگر یکی از این چهار بخش
وجود نداشته باشد،
ادعا باید
دوباره بررسی شود.

خلاصه Source Audit

  • همه جمله های کتاب به Citation نیاز ندارند.
  • Claimهای حساس باید Source معتبر داشته باشند.
  • Source رسمی برای تعریف رفتار Vendor و Standard در اولویت است.
  • Architecture-Specific Claim باید Architecture خود را مشخص کند.
  • عدد بدون Context می تواند گمراه کننده باشد.
  • Benchmark بدون Test Condition کامل نیست.
  • Metric باید با تعریف صحیح خود استفاده شود.
  • Derived Value باید از مقدار مستقیم Source جدا شود.
  • Approximation باید در زبان متن مشخص باشد.
  • Source باید نزدیک Claim قرار بگیرد.
  • Source قدیمی می تواند معتبر باشد اما Scope آن باید روشن باشد.
  • ادعاهای مطلق نیازمند بررسی دقیق تر هستند.
  • Claim Register برای ادعاهای حساس مدیریت نسخه های آینده را ساده می کند.
  • اگر Source Claim را پشتیبانی نمی کند، Claim باید اصلاح شود.

وضعیت بعد از Source Audit

بعد از اجرای این مرحله،
نسخه نهایی کتاب
از سه جهت اصلی
قابل ارزیابی خواهد بود:


HTML / Structural Audit

          ✓

Technical Content Audit

          ✓

Source / Citation Audit

          ✓

          │
          ▼

Final Release Candidate

از این مرحله به بعد
کار اصلی
اجرای این Auditها
روی فایل کامل کتاب
و اصلاح موارد پیدا شده است،
نه اضافه کردن محتوای آموزشی جدید.


مرحله:
بازبینی نسخه کاندید انتشار

نوع:
Release Candidate Review

کاربرد:
تصمیم نهایی برای انتشار یا بازگشت به اصلاح


GPU RELEASE CANDIDATE

بازبینی نهایی Release Candidate کتاب GPU

Release Candidate
نسخه ای است
که از نظر محتوا،
ساختار،
Source،
Navigation
و Rendering
تقریبا آماده انتشار است.

در این مرحله
دیگر هدف
بهبود بی پایان متن نیست.

هدف این است
که بررسی کنیم
آیا هیچ مشکل مهمی
برای انتشار باقی مانده است یا نه.


قاعده Release Candidate

Release Candidate
باید همان نسخه ای باشد
که اگر هیچ مشکل جدیدی پیدا نشود،
بدون تغییر محتوایی بزرگ
منتشر خواهد شد.

Release Candidate
نسخه آزمایشی محتوا نیست؛
نسخه تقریبا نهایی انتشار است.

چه زمانی وارد Release Candidate می شویم؟

  • محتوای آموزشی اصلی کامل شده باشد.
  • Content Freeze انجام شده باشد.
  • HTML Audit اجرا شده باشد.
  • Duplicate IDها رفع شده باشند.
  • Broken Anchorهای اصلی رفع شده باشند.
  • Technical Review انجام شده باشد.
  • Source Audit انجام شده باشد.
  • Terminology اصلی یکسان شده باشد.
  • Navigation زنجیره ای بررسی شده باشد.
  • نسخه Mobile حداقل یک بار تست شده باشد.

اگر هنوز
فصل اصلی در حال بازنویسی است،
نسخه هنوز Release Candidate نیست.

مدل نهایی Review


Release Candidate

       │
       ▼

Structural Check

       │
       ▼

Technical Check

       │
       ▼

Source Check

       │
       ▼

Visual Check

       │
       ▼

Navigation Check

       │
       ▼

Regression Check

       │
       ▼

Go / No-Go Decision

Go / No-Go یعنی چه؟

وضعیت معنا
GO هیچ مشکل مهمی که مانع انتشار باشد باقی نمانده است.
GO WITH MINOR FIX فقط اصلاحات کوچک و کم ریسک مانند Typo یا Label باقی مانده است.
NO-GO حداقل یک مشکل مهم فنی، ساختاری یا Rendering وجود دارد.

چه مشکلاتی باید انتشار را متوقف کنند؟

  • اشتباه فنی مهم،
  • Claim حساس بدون Source معتبر،
  • Duplicate ID تاثیرگذار،
  • Navigation اصلی شکسته،
  • TOC با مقصد ناموجود،
  • Section اصلی که در Browser خراب Render می شود،
  • Table یا Diagram غیرقابل استفاده در Mobile،
  • HTML Structure خراب کننده DOM،
  • یا بخش مهمی که معنای گمراه کننده دارد.


قاعده

اگر مشکل
می تواند فهم Reader،
اعتماد فنی
یا Navigation کتاب را خراب کند،
Release باید متوقف شود.

چه چیزهایی معمولا Blocker نیستند؟

  • Typo محدود،
  • فاصله کوچک Style،
  • یک جمله که می تواند کمی روان تر شود،
  • یک Cross Reference اختیاری،
  • یا بهبود جزئی در Caption.

این موارد
در صورت کم ریسک بودن
می توانند
در همان RC اصلاح شوند
یا به Update کوچک بعدی منتقل شوند.

Pass اول: Structure

  • تمام Sectionهای اصلی باز و بسته صحیح دارند.
  • Block Element داخل p باقی نمانده است.
  • ID Duplicate وجود ندارد.
  • aria-labelledby شکسته وجود ندارد.
  • Tableها Wrapper مناسب دارند.
  • pre و code داخل Component تایید شده هستند.
  • details و summary ساختار صحیح دارند.
  • Navigation Markup معتبر است.

Pass دوم: Technical Accuracy

در RC
قرار نیست
کل کتاب دوباره از صفر Research شود.

اما Sectionهای حساس
باید یک بار دیگر
مرور شوند.

تمرکز اصلی:

  • اعداد،
  • Latency،
  • Clock،
  • Bandwidth،
  • Power،
  • Architecture-Specific Behavior،
  • Vendor-Specific Terminology،
  • و Standard Limits.

Pass سوم: Source

  • Claim حساس بدون Source باقی نمانده باشد.
  • Source دقیقا Claim مربوط را پشتیبانی کند.
  • Architecture و Version Source درست باشد.
  • Source رسمی در جای مناسب در اولویت باشد.
  • Citation اشتباه به Section دیگر منتقل نشده باشد.
  • Source حذف شده یا تغییر یافته بررسی شده باشد.

Pass چهارم: Terminology

در این Pass
به جای خواندن Paragraphها
به عنوان متن،
اصطلاحات کلیدی
جستجو شوند.


Search Terms

VRAM
Memory Bandwidth
Latency
Throughput
Warp
Wave
Occupancy
Utilization
Ray Tracing
Path Tracing
Display Engine
PCIe
Driver

هدف
پیدا کردن شکل های ناسازگار
یا تعریف های متناقض است.

Pass پنجم: Table of Contents

TOC نهایی
باید با خود Document
مقایسه شود.


TOC Entry

     │
     ▼

Destination Exists?

     │
     ▼

Correct Title?

     │
     ▼

Correct Order?

     │
     ▼

Valid

Pass ششم: Navigation

  • Previous هر فصل درست است.
  • Next هر فصل درست است.
  • فصل A به B می رود و B به A برمی گردد.
  • بازگشت به TOC کار می کند.
  • Master Index به Sectionهای واقعی اشاره می کند.
  • Glossary Linkهای مهم کار می کنند.

Pass هفتم: Visual Review

این Pass
باید در Browser واقعی انجام شود.

به دنبال:

  • متن خارج از Box،
  • Box بدون Background،
  • Padding غیرعادی،
  • Table شکسته،
  • Diagram بیرون زده،
  • Heading بدون Style،
  • FAQ خراب،
  • و Sectionهای بیش از حد فشرده یا خالی

باشید.

Pass هشتم: Mobile

  • Page Horizontal Scroll ناخواسته ندارد.
  • Table فقط داخل Wrapper خود Scroll می شود.
  • Diagram فقط داخل Wrapper خود Scroll می شود.
  • Card Grid به شکل مناسب Collapse می شود.
  • Long English Term Layout را خراب نمی کند.
  • Navigation خوانا باقی می ماند.
  • FAQ قابل Tap است.
  • Font Size مناسب است.

Pass نهم: Desktop

در Desktop
تمرکز روی:

  • Line Length،
  • Spacing،
  • Sticky TOC در صورت وجود،
  • Card Grid،
  • Diagram Alignment،
  • و عرض Tableها

باشد.

Pass دهم: Accessibility

  • Heading Hierarchy منطقی است.
  • aria-labelها معتبر هستند.
  • aria-labelledbyها معتبر هستند.
  • Link Text معنی دار است.
  • Table Headerها مشخص هستند.
  • Focus Keyboard قابل مشاهده است.
  • Interactive Componentها فقط با Mouse وابسته نیستند.
  • معنای اصلی فقط با Color منتقل نمی شود.

Pass یازدهم: Full Reading

نسخه Release Candidate
باید حداقل یک بار
از ابتدا تا انتها
بدون توقف برای Rewrite
خوانده شود.

فقط موارد زیر Note شوند:

  • تکرار واضح،
  • پرش مفهومی،
  • تعریف دیرهنگام،
  • لحن ناهمگون،
  • Section بیش از حد طولانی،
  • یا تناقض میان فصل ها.

هدف این Pass
حفظ Flow کل کتاب است،
نه بازنویسی سلیقه ای تک تک جمله ها.

Pass دوازدهم: Regression

هر Fix انجام شده در RC
باید دوباره بررسی شود.


Fix ID

   │
   ▼

Check Old Links


Fix HTML

   │
   ▼

Check Neighboring Boxes


Fix Terminology

   │
   ▼

Check Glossary / Index


Fix Chapter Order

   │
   ▼

Check TOC + Navigation

در RC چه تغییرهایی مجازند؟

تغییر وضعیت
Typo Fix مجاز
Broken Link Fix مجاز
Technical Correction مجاز و ضروری
ID Fix مجاز با Regression Check
Layout Bug Fix مجاز
Chapter جدید معمولا غیرمجاز
Rewrite بزرگ نسخه باید از RC خارج شود

Issue Log نهایی

تمام مشکلات RC
بهتر است
در یک Log کوتاه ثبت شوند.

ID Severity Section Problem Status
RC-001 P1 gpu-example Broken internal anchor Fixed
RC-002 P2 gpu-example-2 Terminology mismatch Fixed

Severity در Release Candidate

Severity معنا
P0 Publication Blocker فوری
P1 مشکل مهم که قبل از Release باید اصلاح شود
P2 مشکل قابل مشاهده ولی غیر بحرانی
P3 Polish و بهبود جزئی

شرط مهم انتشار: Zero Known Critical Issues

نسخه نهایی
نباید با این ذهنیت منتشر شود که:

این مشکل مهم هست،
بعدا درستش می کنیم.

اگر مشکل
شناخته شده
و جدی است،
Release باید متوقف شود.


Known P0 / P1

      │
      ▼

NO RELEASE


Zero Known P0 / P1

      │
      ▼

Possible Release

Automated Audit باید دوباره اجرا شود

حتی اگر قبلا Audit اجرا شده باشد،
بعد از Fixهای RC
یک بار دیگر اجرا شود.

خروجی مطلوب:


Duplicate IDs
0

Broken Anchors
0

Broken aria-labelledby
0

Navigation Issues
0

Tables Without Wrapper
0

Code Without Approved Wrapper
0

Exceptionهای باقی مانده
باید عمدی
و Review شده باشند.

Sourceهای حساس را Spot Check کنید

لازم نیست
تمام Source Register
از ابتدا بررسی شود.

اما چند نمونه
از دسته های حساس
Spot Check شوند:

  • یک Claim عددی،
  • یک Claim معماری،
  • یک Standard،
  • یک Vendor Term،
  • و یک Benchmark در صورت وجود.

هدف
اطمینان از این است
که روش Sourceگذاری
در نسخه نهایی
به شکل واقعی رعایت شده است.

Cold Load را بررسی کنید

نسخه RC
یک بار
با Cache خالی
Load شود.

بررسی شود:

  • صفحه بدون خطای ظاهری Load می شود،
  • Font دیرهنگام Layout را به شدت جابه جا نمی کند،
  • Imageها Page Jump شدید ایجاد نمی کنند،
  • JavaScript خطای اصلی ایجاد نمی کند،
  • و Content اصلی سریع قابل خواندن است.

Print Preview را فراموش نکنید

حتی اگر
نسخه چاپی هدف اصلی نیست،
Print Preview
می تواند
مشکلات Structure
را آشکار کند.

مواردی مانند:

  • Heading جدا از Paragraph،
  • Table بریده شده،
  • Background نامناسب،
  • Navigation غیرضروری،
  • و Page Break بد

در Print View
بهتر دیده می شوند.

بعد از تایید RC، Content Freeze کامل شود

پس از تایید Release Candidate
هیچ تغییر غیرضروری
نباید وارد نسخه شود.


Approved RC

    │
    ▼

Freeze

    │
    ▼

Only Emergency Fixes

    │
    ▼

Publish

Final GO Checklist

  • هیچ P0 باز وجود ندارد.
  • هیچ P1 باز وجود ندارد.
  • Automated Audit نهایی اجرا شده است.
  • Duplicate ID برابر صفر است.
  • Broken Internal Anchor برابر صفر است.
  • Navigation Issue برابر صفر است.
  • Technical Spot Check پاس شده است.
  • Source Spot Check پاس شده است.
  • TOC نهایی تایید شده است.
  • Previous / Next تایید شده است.
  • Mobile Review پاس شده است.
  • Desktop Review پاس شده است.
  • Accessibility Review انجام شده است.
  • Full Reading انجام شده است.
  • Regression Check انجام شده است.
  • Issue Log بررسی شده است.
  • Content Freeze نهایی شده است.

اگر یکی از این موارد وجود دارد، NO-GO

  • یک Claim مهم هنوز مشکوک است.
  • یک Source حساس هنوز تایید نشده است.
  • یک Chapter در Mobile خراب است.
  • TOC به مقصد اشتباه می رود.
  • Navigation فصل ها شکسته است.
  • DOM به دلیل HTML نامعتبر رفتار غیرمنتظره دارد.
  • یک مشکل شناخته شده P0 یا P1 عمدا باقی مانده است.

Release Decision


Any P0 / P1 Open?

      /   
    Yes    No
     │      │
     ▼      ▼

NO-GO    Technical + Source
         Checks Passed?

              /   
            No     Yes
            │       │
            ▼       ▼

          NO-GO   Rendering +
                  Navigation Passed?

                       /   
                     No     Yes
                     │       │
                     ▼       ▼

                   NO-GO     GO

Release Record

برای نسخه تایید شده
می توان یک Record داخلی
نگهداری کرد:


Release Version:
v1.0

Release Candidate:
RC1

Technical QA:
PASS

Structural QA:
PASS

Source Audit:
PASS

Mobile QA:
PASS

Accessibility QA:
PASS

Known Critical Issues:
0

Decision:
GO

خلاصه Release Candidate Review

  • Release Candidate باید تقریبا همان نسخه نهایی انتشار باشد.
  • در RC نباید Chapter جدید اضافه شود.
  • مشکلات P0 و P1 مانع انتشار هستند.
  • Structure، Technical Accuracy و Source باید جداگانه بررسی شوند.
  • TOC و Navigation باید روی نسخه واقعی نهایی تست شوند.
  • Visual Review باید در Browser واقعی انجام شود.
  • Mobile و Desktop هر دو نیاز به Review دارند.
  • Fixهای RC باید Regression Check شوند.
  • Automated Audit بعد از Fixها دوباره اجرا شود.
  • Deep Linkها باید مستقیما تست شوند.
  • Cold Load و Print Preview ارزش بررسی دارند.
  • پس از تایید RC باید Content Freeze نهایی انجام شود.
  • انتشار فقط وقتی انجام شود که هیچ مشکل بحرانی شناخته شده ای باقی نمانده باشد.

وضعیت پروژه بعد از این مرحله

با پایان Release Candidate Review،
چرخه مستندسازی،
Audit،
Source Review
و Publication Decision
کامل می شود.


Content Complete

      ✓

Final Audit

      ✓

Source Audit

      ✓

Release Candidate Review

      ✓

      │
      ▼

Publish
or
Fix Remaining Blockers

در این نقطه
دیگر Section آموزشی یا فرآیندی جدید
برای اضافه کردن ضروری نیست.

گام بعدی واقعی
باید روی

خود فایل کامل HTML کتاب

انجام شود:
اجرای Audit،
گرفتن Report،
اصلاح خطاها
و ساخت نسخه تمیز نهایی.



دانشنامه سخت‌افزار استوک‌شاپ

کارت گرافیک GPU چیست؟ راهنمای جامع معماری، عملکرد و کاربردهای GPU

کارت گرافیک GPU
یکی از مهم‌ترین بخش‌های پردازشی سیستم‌های کامپیوتری مدرن است.
GPU برای پردازش موازی حجم بزرگی از داده‌ها طراحی شده و در
اجرای بازی‌ها، رندر سه‌بعدی، تدوین ویدئو، هوش مصنوعی،
پردازش تصویر و بسیاری از محاسبات حرفه‌ای استفاده می‌شود.

معماری GPU
حافظه VRAM
Graphics Pipeline
Performance

تفاوت GPU و CPU چیست؟

CPU و GPU هر دو پردازنده هستند،
اما برای نوع متفاوتی از Workload
بهینه شده‌اند.

CPU معمولاً از تعداد کمتری Core
با قابلیت‌های پیچیده‌تر استفاده می‌کند
و برای اجرای عمومی،
کنترل برنامه،
Branching
و Workloadهایی که Latency اهمیت زیادی دارد
طراحی شده است.

GPU در مقابل،
منابع اجرای موازی بسیار بیشتری دارد
و برای پردازش حجم بزرگی از داده
و اجرای تعداد زیادی عملیات مشابه
به صورت موازی مناسب است.

مقایسه مفهومی CPU و GPU
ویژگی CPU GPU
ساختار کلی تعداد کمتر Coreهای پیچیده‌تر Parallel Execution Resources بسیار بیشتر
تمرکز معماری Latency و General-Purpose Execution Throughput و Parallel Processing
نوع Workload مناسب Control-heavy Work Data-Parallel Work
Branching معمولاً برای جریان‌های کنترلی پیچیده مناسب‌تر است از Work موازی و منسجم بیشتر سود می‌برد
اجرای موازی توان اجرای موازی دارد، اما هدف معماری فقط این نیست یکی از اهداف اصلی طراحی آن پردازش موازی گسترده است

CPU و GPU چگونه با هم کار می‌کنند؟

در بسیاری از برنامه‌های مدرن،
CPU و GPU به جای جایگزین‌کردن یکدیگر،
در کنار هم کار می‌کنند.

۱

CPU

منطق برنامه،
کنترل،
بخش‌هایی از آماده‌سازی داده
و بسیاری از وظایف عمومی سیستم را اجرا می‌کند.

۲

ارسال Work

Application،
API
و Driver
Work مناسب را برای پردازش
به GPU ارسال می‌کنند.

۳

GPU

GPU بخش‌هایی را که از Parallel Processing
سود می‌برند
با منابع اجرایی گسترده خود پردازش می‌کند.

CPU
 │
 ├── Program Logic
 ├── Control
 ├── General-Purpose Work
 │
 ▼
Commands + Data
 │
 ▼
GPU
 │
 ├── Parallel Work
 ├── Graphics
 ├── Compute
 └── High Throughput


CPU و GPU رقیب مطلق یکدیگر نیستند

این مقایسه یک مدل ذهنی برای درک معماری است.
CPU نیز می‌تواند پردازش موازی انجام دهد
و GPU نیز فقط برای یک نوع محاسبه ساخته نشده است.

در یک سیستم واقعی،
Performance مطلوب معمولاً حاصل
همکاری CPU،
GPU،
Memory
و Software Stack است.

کاربردهای کارت گرافیک GPU

GPU فقط برای اجرای بازی استفاده نمی‌شود.
ماهیت پردازش موازی آن باعث شده
در طیف گسترده‌ای از Workloadهای گرافیکی،
رسانه‌ای، مهندسی و محاسباتی
مورد استفاده قرار گیرد.

Gaming

در بازی‌ها GPU بخش بزرگی از پردازش
Geometry، Texture، Shading، Lighting
و تولید Frameهای متوالی را انجام می‌دهد.

تدوین ویدئو

GPU می‌تواند در پردازش Effectها،
Color Processing،
Playback،
Decode و Encode ویدئو
و برخی مراحل Export نقش داشته باشد.

طراحی و مدل‌سازی سه‌بعدی

در نرم‌افزارهای سه‌بعدی،
GPU در نمایش Viewport،
پردازش Geometry،
Material و Texture
و نمایش صحنه نقش مهمی دارد.

Rendering

Rendererهای سازگار می‌توانند
از توان پردازش موازی GPU
برای محاسبات مربوط به تولید تصویر
استفاده کنند.

پردازش تصویر

GPU برای اجرای عملیات موازی
روی حجم بزرگی از Pixelها
و داده‌های تصویری مناسب است.

محاسبات موازی

معماری GPU برای اجرای
تعداد زیادی عملیات مشابه
روی مجموعه‌های بزرگ داده
مناسب است.

هوش مصنوعی

بسیاری از Workloadهای AI
از Parallel Compute،
Matrix Operations
و Memory System GPU
استفاده می‌کنند.

شبیه‌سازی و محاسبات علمی

برخی Workloadهای مهندسی و علمی
که قابلیت تقسیم به عملیات موازی دارند
می‌توانند از GPU Acceleration
استفاده کنند.


همه نرم‌افزارها به یک GPU مشابه نیاز ندارند

نوع Workload تعیین می‌کند
کدام ویژگی GPU اهمیت بیشتری دارد.
برای یک بازی ممکن است
Graphics Performance مهم‌تر باشد،
در حالی که یک Renderer،
نرم‌افزار تدوین
یا Workload هوش مصنوعی
می‌تواند نیاز متفاوتی به
VRAM، Compute Performance
یا قابلیت‌های تخصصی GPU داشته باشد.


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

برای سیستم‌های حرفه‌ای،
بهتر است ابتدا نرم‌افزار،
نوع پروژه
و Workload اصلی مشخص شود
و سپس GPU متناسب با آن انتخاب شود.

انتخاب کارت گرافیک بر اساس نرم‌افزار

یکی از بهترین روش‌ها برای انتخاب GPU،
بررسی نرم‌افزارهایی است
که واقعاً قرار است روی سیستم اجرا شوند.

دو کارت گرافیک ممکن است در Gaming
عملکرد نزدیک به یکدیگر داشته باشند،
اما در Rendering،
Video Editing،
CAD،
AI
یا سایر Workloadهای حرفه‌ای
رفتار کاملاً متفاوتی نشان دهند.

Gaming

برای بازی باید Performance واقعی
در همان بازی‌ها،
Resolution هدف،
تنظیمات گرافیکی
و فناوری‌های مورد استفاده موتور بازی بررسی شود.

3D و Rendering

در نرم‌افزارهای سه‌بعدی باید مشخص شود
Renderer مورد استفاده
از کدام GPU،
API
و قابلیت‌های شتاب‌دهی پشتیبانی می‌کند.
ظرفیت VRAM نیز در پروژه‌های سنگین اهمیت زیادی دارد.

CAD و نرم‌افزارهای مهندسی

در Workstation Software
علاوه بر Performance،
سازگاری Driver،
پایداری
و Certification نرم‌افزار
می‌تواند اهمیت داشته باشد.

تدوین ویدئو

نوع Codec،
Resolution،
Effectها،
Decode و Encode سخت‌افزاری
و نحوه استفاده نرم‌افزار از GPU
باید بررسی شود.

هوش مصنوعی

در AI،
علاوه بر Compute Performance،
ظرفیت VRAM،
Memory Bandwidth
و پشتیبانی Software Stack
از اهمیت بالایی برخوردار است.

استفاده عمومی

برای وب،
Office،
پخش ویدئو
و بسیاری از کارهای سبک،
ممکن است Integrated Graphics
نیاز کاربر را کاملاً پوشش دهد
و GPU مجزای قدرتمند ضرورتی نداشته باشد.

روش انتخاب GPU برای یک نرم‌افزار

۱
نرم‌افزار را مشخص کنید

نام نرم‌افزار،
نسخه
و موتور پردازشی یا Renderer مورد استفاده را مشخص کنید.

۲
نوع پروژه را مشخص کنید

حجم پروژه،
Resolution،
پیچیدگی Scene،
حجم Dataset
یا سایر ویژگی‌های Workload را بررسی کنید.

۳
سازگاری را بررسی کنید

پشتیبانی GPU،
Driver،
API
و قابلیت‌های موردنیاز نرم‌افزار
باید بررسی شود.

۴
Benchmark مرتبط را ببینید

به جای تکیه بر Benchmark عمومی،
نتایج همان نرم‌افزار
و Workload مشابه پروژه خود را مقایسه کنید.


بهترین روش مقایسه کارت‌های گرافیک

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

نتایج یک کارت در بازی
لزوماً نشان‌دهنده عملکرد آن
در رندر،
هوش مصنوعی
یا نرم‌افزار مهندسی نیست.

مرکز ارتباط
ارتباط با استوک شاپ
🔵بله🟠ایتا📸اینستاگرام☎️+982186035145♥علاقه‌مندی‌ها 0
پیام به استوک شاپ
دستیار خرید و فروش استوک شاپ
برای شروع گفتگو فقط شماره موبایل خود را تایید کنید.
ورود / ثبت‌نام