پچ‌های جدید لینوکس مانع از کرش بازی‌ها هنگام کمبود VRAM شدند

دیگر کمبود حافظهٔ ویدیویی (VRAM) به معنای پرتاب شدن فوری کاربر از محیط بازی به دسکتاپ و کرش کردن سیستم نیست. این وعدهٔ مجموعه‌ای از پچ‌های حیاتی هسته لینوکس است که طبق اعلام توسعه‌دهندگان در ۱۷ اوت ۲۰۲۶ ادغام شده و برای نسخه ۷.۳ آماده شده‌اند تا نحوه مدیریت حافظهٔ بیش از حد (Overcommitment) را به‌طور بنیادین تغییر دهند.

سال‌هاست که گیمرهای لینوکس با یک وضعیت دوتایی روبرو بوده‌اند: یا بازی در حافظه جا می‌شود، یا فریم‌ریت به شدت سقوط کرده و سیستم کرش می‌کند. این اتفاق زمانی رخ می‌دهد که واحد پردازش گرافیکی (GPU) با کمبود حافظه مواجه شده و مجبور می‌شود داده‌ها را به حافظهٔ کندتر CPU منتقل کند (Eviction). اگرچه این موضوع در تئوری فقط باید روی عملکرد اثر بگذارد، اما در عمل به یک کابوس پایداری تبدیل شده بود.

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

تئوری مدیریت بیش از حد (Overcommitment)

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

جریمهٔ عملکردی این فرآیند توسط گلوگاه سخت‌افزاری گذرگاه PCI تعیین می‌شود. برای یک GPU که از اتصال PCIe 4.0x16 استفاده می‌کند، پهنای باند کمی کمتر از ۳۲ گیگابایت بر ثانیه است. این یعنی گذرگاه می‌تواند تقریباً ۳۲.۲ مگابایت داده را در هر میلی‌ثانیه منتقل کند.

برای حفظ حداقل ۳۰ فریم بر ثانیه (که ۳۳.۳ میلی‌ثانیه برای هر فریم زمان می‌دهد)، حداکثر مقدار داده‌ای که GPU می‌تواند از حافظهٔ تخلیه شده (Evicted) بازیابی کند حدود ۱,۰۷۵.۵ مگابایت است. اگر GPU نیاز داشته باشد در یک فریم واحد، بیش از حدود ۱ گیگابایت داده از RAM سیستم بخواند، رسیدن به ۳۰ فریم بر ثانیه از نظر فیزیکی غیرممکن می‌شود.

همه حافظه‌ها یکسان نیستند

جالب است بدانید دسترسی به حافظهٔ CPU همیشه به معنای مرگ عملکرد نیست. درایورهای GPU اغلب داده‌های بافر دستورات (Command Buffer) را حتی زمانی که VRAM در دسترس است در RAM سیستم قرار می‌دهند و بازی‌ها همچنان به‌خوبی اجرا می‌شوند. تفاوت در اینجا به نحوه کشینگ (Caching) و الگوهای دسترسی برمی‌گردد.

• اصابت در کش (Cache Hits): اگر داده‌ها در کش L2 جا شوند، تأخیر دسترسی فارغ از اینکه حافظه توسط RAM یا VRAM پشتیبانی شود، یکسان است. دلیل این امر آن است که هزینه بالای اولیهٔ واکشی داده از طریق گذرگاه PCI می‌تواند توسط اصابت‌های متوالی در کش جبران شود.

• شکاف‌های تأخیر: در سخت‌افزارهای RDNA3، به محض اینکه یک بافر از اندازه ۶ مگابایتی کش L2 فراتر رود، تأخیرهای حافظه CPU به حدود ۲۴۰۰ چرخه در هر دسترسی می‌پرد، در حالی که تأخیرهای حافظه دستگاه (Device Memory) در همان محدوده قبلی باقی می‌مانند.

• عامل Infinity Cache: دسترسی‌های VRAM از Infinity Cache استفاده می‌کنند، اما دسترسی‌های حافظه CPU در صورت عدم اصابت در L2، مستقیماً به گذرگاه PCIe می‌روند. احتمالاً به این دلیل است که Infinity Cache مستقیماً روی VRAM قرار دارد؛ هر دسترسی که در VRAM شکست بخورد، در Infinity Cache نیز شکست می‌خورد. واکشی‌های PCIe تقریباً ۷.۳ برابر تأخیر بیشتری نسبت به اصابت در Infinity Cache و ۴.۶ برابر تأخیر بیشتری نسبت به واکشی VRAM دارند.

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

دیوار پایداری: بن‌بست‌ها و کرش‌ها

علیرغم تئوری‌های فوق، تمام شدن VRAM در عمل باعث مشکلات پایداری می‌شد. به گزارش pixelcluster.dev، علت اصلی کرش‌ها یک خطای سادهٔ «کمبود حافظه» نبود، بلکه شکست در ارسال دستورات (Command Submission) بود، به‌ویژه خطای: radv/amdgpu: Not enough memory for command submission.

این خطا زمانی رخ می‌دهد که درایور amdgpu اطمینان حاصل می‌کند تمام حافظه‌های مورد ارجاع در دستورات GPU قابل دسترسی هستند. در APIهای گرافیکی مدرن بدون بایند (Bindless)، درایور باید فرض کند که تمام حافظه‌های تخصیص‌یافته ممکن است مورد ارجاع قرار گیرند. اگر تخصیصی که باید در VRAM باشد به RAM سیستم منتقل شده باشد، درایور سعی می‌کند آن را بازگرداند. اگر هیچ فضای خالی در VRAM نباشد، درایور باید چیز دیگری را تخلیه کند تا جا باز شود.

این فرآیند می‌تواند یک «بن‌بست ABBA» (ABBA deadlock condition) کلاسیک را ایجاد کند. این اتفاق زمانی می‌افتد که دو ارسال هم‌زمان سعی می‌کنند تخصیص‌های حافظه یکسانی را با ترتیبی متضاد قفل کنند. اگرچه هسته لینوکس مکانیزمی به نام «wound-abort-retry» برای حل چنین بن‌بست‌هایی از طریق کتابخانه drm_exec دارد، اما لایه TTM (مدیریت جدول ترجمه) که لایه مشترک مدیریت حافظه GPU است، از این کمکی استفاده نمی‌کرد.

در کد TTM، حتی کامنتی وجود داشت که اشاره می‌کرد خطای -EDEADLCK باعث شکست تخلیه حافظه می‌شود. به جای استفاده از کمکی drm_exec_lock_obj برای لغو و شروع مجدد تراکنش، هسته لینوکس به‌سادگی عملیات را رها کرده و ارسال دستور را رد می‌کرد. نویسنده گزارش داده است که یک هفته «رنج شدید» را با بازی‌هایی که به‌طور تصادفی ۳ دقیقه پس از شروع رقابت شدید برای VRAM هنگ می‌کردند، سپری کرد تا این باگ‌ها را رفع کند.

تلهٔ عملکرد: پینگ‌پونگی حافظه

حتی پس از رفع کرش‌ها، نویسنده با مانع دومی روبرو شد: عملکرد بسیار ضعیف. با استفاده از gpuvis برای ردیابی رویدادهای هسته، مشخص شد که سیستم بیشتر زمان خود را صرف جابه‌جایی حافظه به عقب و جلو می‌کند تا رندر کردن فریم‌ها. این پدیده به عنوان «پینگ‌پونگی» (Ping-ponging) شناخته می‌شود. این موضوع نشان می‌دهد که چگونه معیارهای سادهٔ نظارتی ممکن است تصویر دقیقی از فشار واقعی روی سخت‌افزار ندهند، مشابه آنچه در بررسی فریب شاخص Occupancy در ابزارهای نظارتی GPU تحلیل شده است.

این اتفاق زمانی می‌افتد که دو برنامه رقیب — مانند یک بازی و gamescope — مدام حافظه یکدیگر را تخلیه می‌کنند. یک برنامه برای باز کردن فضا، برنامه دیگر را بیرون می‌اندازد و برنامه دوم بلافاصله اولی را بیرون می‌اندازد تا فضای خود را پس بگیرد. این چرخه یک گلوگاه عظیم روی گذرگاه PCIe ایجاد می‌کند، جایی که زمان صرف شده برای جابه‌جایی حافظه (فعالیت sdma0) بسیار بیشتر از زمان صرف شده برای کار واقعی GPU (فعالیت gfx_0.0.0) است.

مشکل داده‌های اسکن‌اوت (Scanout)

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

بافرهای معمولی برنامه‌ها فقط در حافظه مجازی متوالی هستند و می‌توانند از طریق جداول صفحه (Page Tables) در سراسر حافظه فیزیکی پراکنده باشند. برای مثال، اولین صفحه از یک بافر در آدرس مجازی 0x5000 ممکن است به آدرس فیزیکی 0x1234000 متصل شود، در حالی که صفحه دوم در 0x6000 به 0x4321000 متصل است.

از آنجایی که الگوریتم تخلیه هسته لینوکس یک حلقه ساده است — یعنی بافرهای «کمترین استفاده اخیر» (LRU) را تخلیه می‌کند تا زمانی که یک فراخوانی tryAllocate موفق شود — ممکن است مقدار عظیمی از داده‌ها را فقط برای پیدا کردن یک حفره متوالی کوچک برای یک بافر اسکن‌اوت پاک کند. نویسنده مشاهده کرد که تا ۴ گیگابایت از VRAM فقط برای باز کردن جا برای یک تصویر حدود ۳۲ مگابایتی (با فرمت پیکسل R11G11B10) پاک شد که منجر به حدود ۱۳۰ میلی‌ثانیه زمان انتقال روی گذرگاه PCIe شد.

راه حل: اکتشافات (Heuristics) و اولویت‌ها

برای حل این مشکل، پچ‌های جدید یک سیستم کنترل دو مرحله‌ای (Throttling) را معرفی کرده‌اند تا از پینگ‌پونگی تهاجمی جلوگیری کنند:

• کنترل سخت (Hard Throttle): برای چند میلی‌ثانیه پس از تخلیه حافظه یک برنامه، هسته تمام تلاش‌ها برای بازگرداندن حافظه به VRAM برای آن برنامه را متوقف می‌کند، به شرطی که تمام حافظه‌ها همچنان به‌درستی قابل دسترسی باشند.
• کنترل نرم (Soft Throttle): برای چندین ثانیه، سیستم اجازه بازپس‌گیری فضای خالی را با انتقال داده‌ها به VRAM می‌دهد، اما تخلیه حافظه متعلق به برنامه‌های دیگر را ممنوع می‌کند.

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

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

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

در حالی که بازی‌های بومی Vulkan به‌ندرت از این قابلیت استفاده می‌کنند، اما vkd3d-proton در حال حاضر اولویت‌های اقامت D3D12 (از طریق ID3D12Device::MakeResident/Evict و ID3D12Device1::SetResidencyPriority) را به اولویت‌های Vulkan ترجمه می‌کند؛ این بدان معنای این است که اکثر بازی‌های ویندوزی که روی لینوکس اجرا می‌شوند، فوراً از این بهبود بهره‌مند خواهند شد.

نتایج دنیای واقعی

تست‌ها با بازی Indiana Jones: The Great Circle بهبود چشمگیری را نشان داد. این بازی به کاربران اجازه می‌دهد اندازه استریم پول (Streaming Pool) را تغییر دهند تا مصرف VRAM را مستقیماً کنترل کنند. روی سیستمی با ۸ گیگابایت VRAM، بازی مجبور شد ۹ گیگابایت حافظه درخواست کند (۱ گیگابایت Overcommitted). پیش از این، چنین وضعیتی ناپایدار بود؛ اما اکنون، بازی میانگین زمان فریم (Frametime) قابل بازی ۱۹.۶ میلی‌ثانیه را حفظ می‌کند.

حتی در حالت درخواست ۱۰ گیگابایت حافظه (۲ گیگابایت Overcommitted)، بازی همچنان قابل اجرا باقی ماند و میانگین زمان فریم ۲۹.۸ میلی‌ثانیه بود، هرچند نوسانات افزایش یافت و جهش‌های مکرر به بالای ۳۳.۳ میلی‌ثانیه مشاهده شد. در برخی موارد، رعایت اولویت‌های حافظه عملکرد را تا ۳۰٪ نسبت به تخلیه تصادفی افزایش داد، هرچند این موضوع به شدت به این بستگی دارد که کدام بافرها تخلیه شده باشند.

این تغییر، فرض بنیادین مبنی بر اینکه VRAM یک سقف سخت است را تغییر می‌دهد. با تبدیل VRAM به یک کش لایه‌بندی شده به جای یک محدودیت سخت، لینوکس به سمت تجربه گیمینگ منعطف‌تری حرکت می‌کند که در آن «تمام شدن حافظه» به جای یک کرش سخت، منجر به کند شدن تدریجی می‌شود.

کاربران SteamOS در حال حاضر می‌توانند به این بهبودها در شاخه‌های Stable و Preview دسترسی داشته باشند. برای سایرین، این تغییرات در حال ادغام در جریان اصلی جامعه لینوکس هستند و شاخه‌های آزمایشی هسته و Mesa برای کسانی که حاضرند پایداری را فدای مدیریت بهتر VRAM کنند، در دسترس است.

گام بعدی شما

• اگر از SteamOS استفاده می‌کنید، این تغییرات را در شاخه‌های Stable و Preview دنبال کنید.
• برای سایر کاربران لینوکس، نصب نسخه‌های آزمایشی هسته (Experimental Kernel) و درایورهای Mesa توصیه می‌شود.
• در تنظیمات بازی‌های سنگین، مقدار Streaming Pool را کمی افزایش دهید تا اثر مدیریت جدید حافظه را تست کنید.

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