چگونه SSD پلی استیشن 5 و ایکس باکس سری ایکس نوید عصری جدید را می‌دهد؟

نسل جدید کنسول‌های بازی قرار است در پایانِ امسال به بازار عرضه شوند و چرخه‌ی هیجاناتِ ناشی از انتظار برای رسیدنِ ایکس‌باکس سری ایکس و پلی‌استیشن 5 برای بیش از یک سال در جریان بوده است. مشخصاتِ فنیِ واقعی (برخلافِ شایعاتِ صرف) با کندیِ بیشتری اعلام شده‌اند و در مورد کنسول‌های جدید هنوز هم اطلاعات بسیار کمتری می‌دانیم، نسبت به آنچه که معمولا در موردِ پلتفرم‌های پی‌سی و اجزای آن در طی زمانِ بعد از معرفی و قبل از موجود شدن در بازار در اختیار داریم. درواقع برخی آمار سطح بالای راندمانی و اطلاعات عمومیِ معماری از مایکروسافت و سونی را در دست داریم، اما نه آنچه که به‌عنوان مشخصاتِ کاملِ سیستم شناخته می‌شود.

نسل جدیدِ کنسول‌ها افزایشِ بزرگی در توانایی‌های CPU و GPU به ارمغان خواهند آورد، اما ما با هر نسلِ جدید چنین بهبودی داریم و جای تعجب نیست وقتی تراشه‌های کنسولی هم همان بروز رسانی‌های ریزمعماری پردازنده‌ها و تراشه‌های گرافیکی AMD را که از آن‌ها مشتق شده‌اند به‌دست می‌آورند. آنچه که مخصوصِ این نسل محسوب می‌شود تغییراتِ ذخیره‌ساز است: کنسول‌ها به پیروی از بازارِ پی‌سی، از هارد درایوهای مکانیکی به ذخیره‌ساز‌های حالت‌ جامد یا همان SSD-ها روی آورده‌اند، اما یک قدم از بازارِ پی‌سی هم فراتر رفته‌اند تا بیشترین بهره‌ی ممکن را از ذخیره‌سازهای حالتِ جامد به‌دست آورند.

بخش‌های داخلی ایکس‌باکس سری ایکس

درواقع SSD-ها انقلابی در تجارتِ پی‌سی بودند که بهبود‌های عظیمی را در پاسخ‌گوییِ کلیِ سیستم ایجاد کردند. بازی‌ها بیشتر به شکلِ نصبِ سریع‌تر و بارگذاریِ مراحل سریع‌تر از آن بهره‌مند شدند، اما ذخیره‌سازِ سریع به کاهشِ واماندگی‌های سیستمی (Stall) و وقفه (stutter) در هنگامی که بازی نیاز به بارگذاریِ داده‌ها در حینِ اجرا دارد هم کمکِ شایانی کرد. در سال‌های اخیر، SSD های NVMe سرعت‌هایی را فرآهم کردند که در روی کاغذ چندین برابر سریع‌تر بود از آنچه که قبلا با SSD-های SATA مقدور شده بود، اما برای گیمرها فوایدِ آن در بهترین حالت آنچنان محسوس نبود.

دانشِ متعارف برآورد دارد که دو دلیلِ اصلی برای این ناکارآمدی وجود دارد: اول اینکه تقریبا تمامِ بازی‌ها و موتورهای بازی هنوز هم برای قابلِ اجرا بودن از هارد درایوها طراحی می‌شوند و دوم اینکه SSD-های SATA هنوز آنقدر سریع هستند که گلوگاه را به‌جای دیگری از سیستم منتقل کنند که اغلب در فرمِ فشرده‌ سازیِ داده‌ها است. قبل از اینکه بازی‌ها به خوبی بتوانند از مزایای راندمانِ NVMe برخوردار شوند، چیزی به جز SSD-ها هست که باید ارتقای سرعت پیدا کند.

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

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

منبع اصلی اطلاعات فنیِ رسمی در مورد PS5 و مخصوصا SSD آن، طراحِ ارشد، مارک سِرنی است. او در ماه‌ مارس معرفیِ تکنیکی یک ساعته‌ای در رابطه با PS5 داشت و حدودا یک سومِ آن را به تمرکز روی ذخیره‌ساز اختصاص داد. سونی به‌صورتِ غیررسمی‌تر ثبت اختراعات متعددی داشته که به نظر مرتبط به PS5 بوده و شامل موردی می‌شده که با آنچه که در موردِ فناوری ذخیره‌سازِ سونی تایید شده به خوبی همخوانی دارد. آن ثبتِ اختراع شاملِ تعدادی ایده هست که سونی در طیِ توسعه‌ی PS5 پیاده‌سازی و آزمایش کرده و بسیاری از آن‌ها احتمالا در طراحیِ نهایی نیز پیاده‌سازی شده‌اند.

مایکروسافت هم کمابیش رویکردِ قطره‌ چکانی را برای رونمایی از جزئیاتِ فنی در طی پست‌های وبلاگِ پراکنده و برخی گفتگوها در پیش گرفته است، مخصوصا گفتگویی که با دیجیتال فاندری داشت (که آن‌ها هم پوشش خوبی از PS5 داشتند). آن‌ها برندهای بسیاری از فناوری‌های مرتبط با ذخیره‌سازشان را معرفی کرده‌اند (مثل معماری Xbox Velocity)، اما در مواردِ بسیاری هم هنوز چیزی در رابطه با قابلیتِ مورد نظر به جز نامِ آن نمی‌دانیم.

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

در مورد SSD کنسول‌ها چه می‌دانیم؟

مایکروسافت و سونی هر یک SSD اختصاصی از نوع NVMe را برای کنسول‌هایشان - البته با تعریفِ متفاوتی از "اختصاصی" - استفاده می‌کنند. راهکارِ سونی دو برابر راندمانِ بیشتر را نسبت به راهکارِ مایکروسافت هدفگذاری کرده است و با وجود ظرفیتِ کمتر، قطعا هزینه‌ی بیشتری می‌برد. SSD ساختِ سونی راندمانی مشابه با SSD-های رده بالای NVMe با استانداردِ PCIe 4.0 ارائه می‌کند که انتظار داریم در بازارِ خرده‌فروشی در پایانِ سال موجود شود. در سوی دیگر SSD مایکروسافت بیشتر با مدل‌های رده پایینِ NVMe قابل مقایسه است. هر دو نسبت به هارد درایوهای مکانیکی و حتی SSD-های SATA قدم بزرگی رو به جلو محسوب می‌شوند.

مهم‌ترین و تاثیرگذارترین معیارِ راندمان در SSD-های کنسولی، سرعتِ خواندنِ ترتیبی در آنهاست. سرعتِ نوشتنِ SSD-ها تقریبا به‌طور کامل در راندمانِ بازی‌‌های ویدیویی بی‌تاثیر است و حتی زمانی‌که بازی‌ها عملیاتِ خواندنِ تصادفی را انجام می‌دهند، معمولا برای تکه‌های داده‌ا‌یِ بزرگتر از بلاک‌های ۴ کیلوبایتی که معیار راندمانِ تصادفیِ SSD-ها است خواهد بود. سرعتِ خواندنِ ۲.۴ گیگابایتیِ SSD مایکروسافت بین ۱۰ تا ۲۰ برابر سریع‌تر است از آنچه که هارد درایوِ مکانیکی قادر به ارائه است، اما در عین حال نسبت به استانداردِ کنونیِ SSD-های رده بالای مصرف‌کننده که می‌توانند گذرگاهِ PCIe 3.0 x4 را اشباع کرده و حداقل به سرعتِ خواندنِ ۳.۵ گیگابایت بر ثانیه برسند، کندتر به نظر می‌رسد.

سرعتِ خواندنِ ۵.۵ گیگابایتیِ سونی هم به شکل قابل توجهی سریع‌تر از SSD-های موجودِ PCIe 4.0 براساسِ کنترلرِ Phison E16 است، اما هر سازنده‌ای که در زمینه‌ی SSD-های رده بالای مصرف‌کننده رقابت می‌کند، راهکارِ پیشرفته‌تری در راهِ عرضه به بازار دارد. با این اوصاف زمانی‌که PS5 در پایان سال عرضه شود، راندمانِ خواندن SSD آن بی‌رقیب نخواهد بود و با SSD-های رده بالای دیگر همتراز خواهد شد.

سونی عنوان کرده که SSD آن‌ها از یک کنترلر اختصاصی دارای رابط ۱۲ کاناله متصل به حافظه‌های NAND-Flash استفاده می‌کند. به نظر می‌رسد این مهم‌ترین شیوه‌ای است که طراحیِ آن‌ها را از SSD‌-های مرسومِ مصرف‌کننده متمایز می‌کند. SSD-های رده بالای موجود معمولا از کنترلرهای ۸ کاناله و SSD-های رده پایین از کنترلرهای ۴ کاناله استفاده می‌کنند. کانال‌های تعداد بالاتر بیشتر برای SSD-های سروری متداول هستند، مخصوصا آنهایی که نیاز دارند ظرفیت‌های بسیار بالایی را پشتیبانی کنند. کنترلرهای ۱۶ کاناله برای این مدل‌ها معمول هستند و طراحی‌های ۱۲ یا ۱۸ کاناله هم ناشناخته نیستند.

استفاده‌ی سونی از تعداد کانال‌های بیشتر نسبت به هر SSD رده مصرف‌کننده‌ی اخیر به این معنی است که کنترلر SSD آن‌ها به شکلِ غیر معمولی بزرگ و گران‌قیمت خواهد بود، اما از سوی دیگر هم نیازی به راندمانِ آنچنان بالا در هر کانال برای رسیدن به سرعت ۵.۵ گیگابایت بر ثانیه نخواهند داشت. آن‌ها می‌توانند هر مدلی از NAND-Flash با ساختار ۶۴ لایه یا مدل‌های جدیدتر TLC را استفاده کنند و راندمانِ کافی به‌دست آورند، درحالی‌که SSD-های رده مصرف‌کننده برای ارائه‌ی این سطح از راندمان یا بیشتر از آن با استفاده از کنترلرهای ۸ کاناله، باید با حافظه‌های جدیدتر و سریع‌ترِ NAND-Fash همراه شوند.

همچنین استفاده از کنترلر ۱۲ کاناله به مجموعِ ظرفیت‌های نامتعارف هم منجر می‌شود. یک SSD کنسولی نیاز به میزانِ بیشتری از overprovisioning (قابلیتی برای افزایشِ طولِ عمرِ SSD) نسبت به SSD-های معمولی ندارد، بنابراین ۵۰ درصد افزایش در تعداد کانال‌ها باید به ۵۰ درصد ظرفیتِ قابلِ استفاده‌ی بیشتر تعبیر شود. پلی‌استیشن 5 با ۸۲۵ گیگابایت فضای SSD به فروش خواهد رسید که به این معنی است که باید هر یک از ۱۲ کانال را مجهز به ۶۴ گیگابایت از حافظه‌ی NAND ببینیم که یا به شکل یک تراشه‌ی ۵۱۲ گیگابیت (۶۴ گیگابایت) به ازای هر کانال یا به شکل دو تراشه‌ی ۲۵۶ گیگابیتی (۳۲ گیگابایتی) در هر کانال خواهد بود. و این یعنی اینکه ظرفیتِ خامِ خالص برابر با ۷۶۸ گیگابایت (با معیار هر گیگابایت برابر با ۱۰۲۴ مگابایت) یا حدودِ ۸۲۴.۶ گیگابایت (با معیار هر گیگابایت برابر با ۱۰۰۰ مگابایت) خواهد بود.

ظرفیتِ قابل استفاده بعد از احتسابِ فضای رزرو شده توسطِ درایو، احتمالا به‌عنوانِ درایو ۷۵۰ گیگابایتی توسطِ سازنده اسم‌گذاری خواهد شد، بنابراین ۸۲۵ گیگابایتِ اعلام شده توسط سونی چیزی در حدودِ ۱۰ درصد بالاتر از حد نرمالِ صنعتِ ذخیره‌سازی است. این موضوعی است که ممکن است برخی حقوق‌دانان را به واکنش وادار کند. شاید لازم به ذکر باشد که بگوییم منطقی نیست سونی تنها به اتکای خود کنترلر SSD سرعت بالای خود را ساخته باشد، همانگونه که خودشان به‌تنهایی نمی‌توانند CPU یا GPU را طراحی کنند. سونی باید با یک سازنده‌ی معتبر کنترلر SSD موجود شراکت کند که هنوز نمی‌دانیم آن شریک کدام است.

SSD مایکروسافت راندمان را هرگز به سطحی بالاتر از پی‌سی‌های جدیدِ معمولی که اکنون سازندگانشان به فراتر از مدل‌های SATA مهاجرت کرده‌اند، ارتقا نخواهد داد، اما یک ترابایت کامل در پی‌سی قیمتی مشابه به کنسول‌ها دارد که هنوز برگ برنده‌ی بزرگی برای مشتریان خواهد بود. منابعِ مختلف برآورند می‌کنند که مایکروسافت از یک کنترلر SSD موجود در بازار از یکی از مدل‌های معمول (شاید کنترلر Phison E19T) استفاده می‌کند و خودِ درایو هم توسطِ یک سازنده‌ی عمده‌ی SSD ساخته خواهد شد. هر چند که آن‌ها هنوز هم می‌توانند ادعای ابعادِ اختصاصی یا احتمالا firmware اختصاصی خودشان را داشته باشند. باتوجه‌به سرعت‌های هدفگذاری شده‌، به نظر می‌رسد که سونی به استفاده از تراشه‌های TLC متعهد باشد، اما مایکروسافت گزینه‌ای برای استفاده از تراشه‌های QLC هم در اختیار دارد.

کنترلر بدون حافظه‌ی DRAM، آیا کافی است؟

بدون داشتن مشخصات مربوط‌به خواندن یا نوشتن تصادفی نمی‌توانیم در موردِ امکان اینکه SSD هر یک از دو کنسول از کنترلر بدون حافظه‌ی DRAM استفاده می‌کنند یا خیر قضاوت کنیم. گنجاندن حافظه‌ی کش با اندازه‌ی کامل برای جداولِ لایه‌ی ترجمه‌ی فلش (flash translation layer یا به اختصار FTL) در SSD قبل از همه به دو شیوه در بهبودِ راندمان کمک می‌کند: اولی سرعت نوشتن پایدارِ بهتر در هنگامی که درایو آنقدر پر شده باشد که نیاز به کارِ پس‌زمینه‌ی زیادی برای جابجایی داده‌ها داشته باشد و دوم هم سرعت دسترسی تصادفیِ بهتر وقتی که داده‌ها در طولِ کل درایو خوانده می‌شوند.

البته هیچ یک از این دو در الگوی کارکردِ کنسول‌ها صدق نمی‌کند: الگوی به‌شدت سنگینِ خواندنی محور که فقط به یک دیتاستِ بازی در هر زمان دسترسی پیدا می‌کند. حتی اگر اندازه‌ی نصب بازی در محدوده‌ی ۱۰۰ تا ۲۰۰ گیگابایت هم باشد، میزان داده‌ای که در هر لحظه توسط بازی استفاده می‌شود، بیشتر از چند ده گیگابایت نخواهد بود و این میزان به‌سادگی توسط SSD-های بدونِ DRAM و با ظرفیت متنابهی از SRAM تعبیه شده در داخلِ کنترلر قابلِ کنترل خواهد بود. بکار نبردن DRAM در SSD مایکروسافت به نظر خیلی محتمل خواهد بود، اما در مورد SSD سونی با اینکه عجیب خواهد بود اگر یک کنترلر ۱۲ کاناله‌ی بدون DRAM را ببینیم، اما این گزینه برای سونی هم قابل تصور خواهد بود و هزینه‌ی تعبیه‌ی کانال‌های تعداد بالا را تا حدودی جبران خواهد کرد.

قابلیت توسعه

مایکروسافت و سونی هر دو قابلیت توسعه را برای ذخیره‌ساز NVMe در کنسول‌های در راهِ خود فرآهم کرده‌اند. راهکارِ مایکروسافت بسته‌بندی مجدد SSD داخلی در ابعاد یک حافظه‌ی قابلِ جابجایی اختصاصی به شکل کارت‌های حافظه‌ی قدیمی در زمانی است که ظرفیت‌ها بر حسبِ مگابایت به‌جای گیگابایت اندازه‌ گیری می‌شد. از آنجایی که تمامِ اجزای آن مشابه‌ی نمونه‌ی داخلی است، کارتِ حافظه‌ی اضافه شونده هم عملکردی مشابه با ذخیره‌سازِ داخلی خواهد داشت. نکته‌ی منفی اینجا است که خود مایکروسافت عرضه و احتمالا قیمت‌گذاریِ این کارت‌ها را کنترل خواهد کرد. فعلا شرکتِ Seagate تنها شریکِ تایید شده‌ برای فروشِ این کارت‌های اضافه شونده است.

سونی رویکردِ معکوسی در پیش گرفته و به کاربران اجازه‌ی دسترسی به اسلاتِ استاندارد M.2 و گذرگاه PCIe 4.0 را می‌دهد که می‌تواند ارتقاهای قطعات ثانویه از برندهای مختلف را بپذیرد. البته ملزومات هنوز کاملا روشن نیست: سونی تستِ سازگاری با درایوهای ثانویه را برای انتشارِ فهرستِ سازگاری انجام خواهد داد، اما آن‌ها نگفته‌اند که درایوهایی که در فهرستِ تایید شده‌ی آن‌ها نباشند در صورت اتصال به کنسول رد خواهند شد یا خیر. برای جای گرفتن در فهرست سازگاری سونی، نیاز است که درایو به‌صورت مکانیکی و از نظرِ ابعاد، قابلیت جای گیری در اسلات را داشته باشد (از هیت سینک بزرگ استفاده نکرده باشد) و حداقل راندمانی به اندازه‌ی SSD داخلیِ سونی را داشته باشد. ملزومات راندمانی به این معنی است که هنوز هیچ درایو موجود در خرده‌فروشی‌ بازار قابلِ تایید نخواهد بود، اما شرایط در سال آینده بسیار متفاوت خواهد شد.

متعادل سازی سیستم با قابلیت‌های سخت‌افزاریِ دیگر

بزرگ‌ترین مزیتِ تکنیکیِ کنسول‌ها دربرابر پی‌سی این است که کنسول‌ها پلتفرمِ ثابت کاملا یکپارچه‌ای هستند که توسطِ یک سازنده ارائه شده‌اند. در تئوری، سازندگان می‌توانند مطمئن شوند که سیستم برای کاربردِ مدنظر به درستی بالانس شده است، امری که سازندگانِ بزرگِ PC در آن بدسابقه هستند.

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

تا به امروز، بازی‌های پی‌سی کاملا اثبات کرده‌اند که افزایشِ سرعتِ SSD تاثیرِ ناچیز یا خنثی روی راندمانِ بازی دارد. SSD-های NVMe در روی کاغذ چندین برابر سریع‌تر از SSD-های SATA هستند، اما تقریبا برای تمامِ بازی‌های پی‌سی این راندمانِ اضافه، تا حدِ زیادی بلااستفاده می‌ماند. بخشی از این امر به علتِ گلوگاه شدن در بخش‌های دیگر سیستم است که تنها وقتی بروز می‌کند که راندمانِ ذخیره‌ساز آنقدر سریع باشد که دیگر یک محدودیتِ جدی محسوب نشود. کنسول‌های آینده تعدادی از قابلیت‌های سخت‌افزاری را در خود دارا هستند که برای سهولتِ بهره‌گیری از ذخیره‌سازِ سریع در بازی‌ها طراحی شده‌اند و همچنین برای کاستن از گلوگاه‌هایی که در یک پلتفرم پی‌سی استاندارد مشکل ساز خواهند بود. اینجا جایی است که فناوری ذخیره‌ساز کنسول واقعا جالب به نظر می‌رسد، چرا که SSD-ها به خودی خود دیگر قابل اعتنا نیستند.

فشرده سازی: تقویتِ راندمان SSD

مهم‌ترین قابلیت سخت‌افزاری کنسول‌ها که به‌عنوانِ مکملِ راندمانِ ذخیره‌ساز لحاظ خواهند شد، سخت‌افزارِ اختصاصیِ غیرفشرده‌ سازی (decompression) است. متعلقات بازی باید به فرمی فشرده روی دیسک ذخیره شوند تا ملزوماتِ ذخیره‌سازی را در حدِ معقول نگه دارند. بازی‌ها معمولا به روش‌های فشرده ‌سازیِ چندگانه‌ای متکی هستند – برخی روش‌های فشرده سازی ضایع کننده (lossy compression) اختصاصا برای نوع مشخصی از داده‌ها (مثل صدا و تصاویر) است و برخی هم از الگوریتم‌های همه منظوره‌ی بدونِ افت کیفیت (lossless) استفاده می‌کنند، اما تقریبا همگی حداقل یک روش فشرده سازی دارند که محاسبات نسبتا پیچیده‌ای دارد. معماری تراشه‌های گرافیکی از مدت‌ها پیش سخت‌افزار مخصوصی برای رمزگشایی فرمت‌هایی ویدیویی و پشتیبانی از روش‌های ساده و سریع فشرده سازی بافت‌ها مثل S3TC داشتند، اما این امر داده‌های زیادی را برای غیر فشرده سازی به عهده‌ی پردازنده‌ی اصلی می‌گذارد.

پردازنده‌های دسکتاپ، دستورها یا موتورهای اختصاصی برای غیر فشرده سازی ندارند، هر چند که بسیاری از دستورالعمل‌ها شاملِ ملحقاتِ SIMD قرار است به بهبودِ پردازشِ این‌گونه وظایف در CPU کمک کند. بااین‌حال غیر فشرده سازیِ جریانی از داده‌ها در حجمِ چندین گیگابایت بر ثانیه راحت نیست و سخت‌افزارِ تک منظوره می‌تواند این کار را بهینه‌تر انجام دهد و در عینِ حال زمانِ CPU را برای وظایفِ دیگر آزاد کند. سخت‌افزارِ مخصوصِ غیر فشرده سازی در کنسول‌های آینده در تراشه‌ی اصلیِ سیستم (SoC) تعبیه شده‌اند و بنابراین قادر هستند داده‌ها را پس از دریافت ازطریق گذرگاهِ PCIe از SSD بازگشایی کرده و در حافظه‌ی اصلی RAM که برای CPU و GPU به اشتراک‌گذاری شده قرار دهند.

سخت‌افزارِ مخصوصِ غیر فشرده سازی مانند این در پلتفرم‌های رایج پی‌سی پیدا نمی‌شود، اما به سختی یک ایده‌ی جدید محسوب می‌شود. کنسول‌های قبلی هم دارای سخت‌افزارِ غیر فشرده سازی بودند، اما نه آن‌گونه که بتوانند به سرعت SSD-های NVMe برسند. پلتفرم‌های سروری اغلب از شتاب‌دهنده‌های فشرده سازی بهره می‌گیرند و معمولا با شتاب‌دهنده‌های رمزنگاری درکنار هم استفاده می‌شوند. اینتل قبلا چنین شتاب‌دهنده‌ای را، هم به‌عنوان ابزارِ جانبی مستقل و هم به‌صورت مجتمع با برخی تراشه‌های سروری داشته است و پردازنده Power9 ساخت شرکت IBM و مدل‌های جدیدتر آن هم واحدهای شتاب‌دهنده‌ی مشابه‌ای دارند. این شتاب‌دهنده‌های سروری با آنچه که کنسول‌های جدید نیاز دارند بیشتر قابلِ قیاس هستند.

مایکروسافت و سونی هر کدام واحدهای غیر ‌فشرده‌ سازِ خودشان را برای راندمانی که از آن انتظار دارند بهینه‌سازی کرده‌اند و هر یک از الگوریتم‌های اختصاصی متفاوتی برای این کار استفاده می‌کنند: سونی از الگوریتمِ Kraken ساخت RAD استفاده می‌کند که یک الگوریتمِ چند منظوره است که در اصل برای استفاده در کنسول‌های فعلی با پردازنده‌ی نسبتا ضعیف، اما با ملزومات خروجیِ بسیار پایین‌تر طراحی شده بود. اما مایکروسافت به‌صورت خاص روی فشرده سازی بافت‌ها تمرکز کرده و به همین دلیل هم بافت‌ها بیشترین حجم از داده‌های بازی را که نیاز به خوانده شدن و فشرده سازی دارند تشکیل می‌دهند. آن‌ها یک الگوریتم فشرده سازیِ بافت توسعه دادند که BCPack خوانده می‌شود.

سونی اظهار می‌کند که سخت‌افزار غیر فشرده سازی مبتنی بر Kraken آن‌ها می‌تواند ۵.۵ گیگابایت بر ثانیه جریان داده از SSD را بازگشایی کرده و به‌طور معمول به ۸ تا ۹ گیگابایت بر ثانیه داده‌ی غیر فشرده شده تبدیل کند، اما در تئوری می‌تواند تا ۲۲ گیگابایت بر ثانیه هم برسد، اگر داده‌ها برای فشرده‌ سازیِ سطحِ بالا به اندازه‌ی کافی منعطف باشند. مایکروسافت هم می‌گوید خروجی ۴.۸ گیگابایت بر ثانیه را از ورودیِ ۲.۴ گیگابایت بر ثانیه‌ی SSD به‌دست می‌آورد. به نظر می‌رسد که سخت‌افزار غیر فشرده سازی مایکروسافت صرفا برای داده‌های بافت کار می‌کند.

زمان صرفه‌جویی شده‌ی CPU توسطِ این واحدهای غیر فشرده سازی حیرت انگیز است: مترادف با حدودِ ۹ هسته‌ی پردازنده‌ی Zen 2 برای PS5 و حدود ۵ هسته‌ی پردازنده هم برای Xbox Series X. به خاطر داشته باشید که اینها اعدادِ حداکثری هستند که با فرضِ استفاده‌ی کامل از پهنای باند SSD عنوان شده‌اند. بازی‌های واقعی نخواهند توانست این SSD-ها را  به میزانِ ۱۰۰ درصدی مشغول نگه دارند، بنابراین تا این حد از توان پردازنده را هم برای غیر فشرده سازی نیاز نخواهند داشت.

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

موتورهای DMA

دسترسی مستقیم به حافظه (Direct Memory Access یا DMA) اشاره به قابلیتی دارد که به یک دستگاه‌ِ جانبی، توانایی خواندن و نوشتن در حافظه‌ی RAM را بدون درگیر کردنِ پردازنده‌ی اصلی می‌دهد. تمام دستگاه‌های جانبیِ پرسرعتِ مدرن از DMA برای اغلبِ ارتباطاتشان با CPU استفاده می‌کنند، اما این تنها استفاده‌ی DMA نیست. یک DMA Engine دستگاهی جانبی است که موجود است تا فقط برای جابجایی داده‌ها استفاده شود و معمولا هیچ کاری روی خودِ آن داده‌ها انجام نمی‌دهد. پردازنده می‌تواند به موتورِ DMA بگوید که یک عملیات کپی را از قسمتی از RAM به قسمت دیگر انجام دهد و موتور DMA هم کارِ تکراریِ کپیِ گیگابایت‌ها داده را انجام می‌دهد، بدون اینکه CPU مجبور به اجرای دستورهاِ mov به ازای هر بخش از داده‌ها باشد و بدون اینکه حافظه‌های کشِ پردازنده آلوده‌ی این کار شوند.

موتورهای DMA همچنین اغلب می‌توانند بیشتر از یک عملیاتِ کپیِ ساده را بر عهده بگیرند: آن‌ها عموما عملیاتِ Scatter/gather برای سازماندهی داده‌ها را هم در حینِ جابجایی آن‌ها انجام می‌دهند. هم‌اکنون هم NVMe قابلیت‌هایی مثل فهرست‌های Scatter/gather را داراست که می‌تواند نیاز به موتور DMA جداگانه را برطرف کند، اما دستورهاِ NVMe در این کنسول‌ها بیشتر روی داده‌های "فشرده شده" کار می‌کنند.

کمک پردازنده‌ی I/O

مجموعه‌ی ورودی/خروجی در تراشه‌ی اصلی PS5 یک پردازنده‌ی دو هسته‌ای را هم شامل می‌شود که حافظه‌ی SRAM مخصوص به خود را دارا است. سونی تقریبا هیچ چیزی راجع به بخش‌های داخلیِ این قسمت نگفته است: مارک سرنی یکی از هسته‌ها را مختص به عملیاتِ ورودی/خروجی SSD تشریح کرده که به بازی‌ها اجازه‌ی "دور زدنِ عملیاتِ سنتی I/O برای فایل" را می‌دهد. هسته‌ی دیگر هم به‌عنوان کمک کننده به عملیاتِ "نگاشتِ حافظه" (memory mapping) معرفی شده است. برای جزئیات بیشتر، باید به حقِ ثبت اختراعی که سونی سال‌های گذشته داده سری بزنیم.

کمک پردازنده‌ای که در ثبت اختراع سونی تشریح شده، بخشی از کاری را به عهده دارد که به‌صورت نرمال در درایورهای ذخیره‌سازِ سیستم‌عامل انجام می‌شود. یکی از مهم‌ترین کارهای این بخش ترجمه و تبدیل بین فضاهای آدرس دهی مختلف است. وقتی یک بازی محدوده‌ی مشخصی از بایت‌ها را از یکی از فایل‌هایش درخواست می‌کند، درواقع بازی به‌دنبال داده‌های غیر فشرده است. کمک پردازنده‌ی I/O تعیین می‌کند که کدام بخش از داده‌های فشرده شده نیاز است و سپس دستورهاِ خواندنِ NVMe را به SSD ارسال می‌کند. زمانی‌که SSD داده‌های خواسته شده را ارجاع کرد، کمک پردازنده‌ی I/O واحدِ غیرِ فشرده سازی را برای پردازشِ داده‌ها و موتورِ DMA را هم برای تحویلِ داده‌های غیر فشرده شده به مکان‌های خواسته شده در حافظه‌ی بازی مهیا می‌کند.

از آنجایی که دو هسته‌ی کمک پردازنده‌ی I/O هر کدام بسیار کم قدرت‌تر از یک هسته‌ی پردازنده‌ی Zen 2 هستند، نمی‌توانند مسئولِ تمامِ فعل و انفعالات با SSD باشند. کمک پردازنده معمول‌ترین موارد خواندنِ داده‌ها را کنترل می‌کند و سیستم برای انجام مابقیِ کارها به سیستم عاملی که روی هسته‌های Zen 2 در حال اجرا است مراجعه می‌کند. حافظه‌ی SRAM در کمک پردازنده هم فقط جداولِ نگاشتِ حافظه‌ی مختلف را نگه‌داری می‌کند و کارِ آن با کنترلر SSD متفاوت است. به همین جهت هنگام کار با SSD-های ثالث از برندهای دیگر هم مثمرِ ثمر خواهد بود.

انسجامِ حافظه‌ی کش

آخرین قابلیتِ سخت‌افزاری وابسته به ذخیره‌ساز که سونی عنوان کرده، مجموعه‌ای از موتورهای انسجامِ حافظه‌ی پنهان (cache coherency engines) است. CPU و GPU در تراشه‌ی PS5، حافظه‌ی اصلیِ ۱۶ گیگابایتیِ مشترکی دارند که نیاز به کپی متعلقات بازی از حافظه‌ی اصلی به VRAM یا همان حافظه‌ی گرافیکی را وقتی که از SSD خوانده و غیر فشرده سازی می‌شوند رفع می‌کند. اما برای گرفتنِ بیشترین بهره از حافظه‌ی مشترک، سخت‌افزار باید از انسجامِ حافظه‌ی کش، نه فقط بین هسته‌های مختلف پردازنده، بلکه بین حافظه‌های کشِ‌ مختلف GPU نیز مطمئن شود. اینها همه فعالیت‌های عادی یک APU هستند، اما آنچه که در مورد PS5 جدید است، این است که مجموعه‌ی I/O هم در این انسجام مشارکت می‌کند. وقتی متعلقات گرافیکی جدید ازطریق مجموعه‌ی I/O به حافظه بارگذاری شده و داده‌های قدیمی را بازنویسی می‌کنند، سیگنال‌های باطل شدنِ کش را به تمامِ حافظه‌های کش ارسال می‌کند تا فقط داده‌های قدیمی دور انداخته شوند، به‌جای اینکه کل حافظه‌های کشِ واحدِ گرافیکی پاک‌ سازی شود.

در مورد ایکس‌باکس سری ایکس

اطلاعات زیادی در مورد مجموعه‌ی ورودی خروجی اختصاصیِ پلی‌استیشن 5 موجود است و طبیعی است تعجب کنید اگر Xbox SX هم قابلیت‌های مشابهی داشته باشد یا فقط به یک سخت‌افزارِ غیر فشرده ساز محدود باشد. مایکروسافت فناوری‌های مرتبط با ذخیره‌ساز را تحتِ عنوانِ  "Xbox Velocity Architecture" آشکار کرده است.

مایکروسافت این بخش را با ۴ جزء معرفی کرده است: خود SSD، موتورِ فشرده سازی، یک واسط نرم‌افزاری یا API جدید برای دسترسی به ذخیره‌ساز و سرانجام یک امکان سخت‌افزاری با نام Sampler Feedback Streaming. آخرین گزینه به سختی به ذخیره‌ساز مربوط است، چرا که یک قابلیتِ GPU است که بافت‌های بعضا مقیم در حافظه را قابل استفاده‌تر می‌کند. از آن‌جا که مایکروسافت برخلاف سونی اطلاعاتِ زیادی در مورد بخشِ I/O و ذخیره‌ساز نداده، معقول است که تصور کنیم ایکس‌باکس سری ایکس از آن قابلیت‌های اختصاصی برخوردار نیست و بیشتر عملیاتِ I/O توسط هسته‌های پردازنده انجام می‌شود. اما خیلی هم متعجب نخواهیم شد اگر دریابیم که سری X هم موتورهای DMA مشابه دارد، چرا که این‌گونه قابلیت‌ها به‌صورتِ تاریخی در معماری‌های کنسولیِ زیادی نشان داده شده‌اند.

از بازی‌های نسل بعد چه انتظاری داشته باشیم؟

SSD‌-های NVMe به‌سادگی می‌توانند ۵۰ برابر سریع‌تر از هارد درایوها در عملیاتِ خواندنِ ترتیبی و هزاران برابر سریع‌تر در خواندنِ تصادفی باشند. این استدلالی است که بازی‌سازان باید قادر باشند کارها را متفاوت انجام دهند، وقتی که دیگر نیازی به هدف‌گذاری برای هارد درایوهای کند ندارند و می‌توانند به ذخیره‌سازِ سریع اتکا کنند. راهکارهای مربوط‌به راندمانِ هارد دیسک‌های کند می‌توانند کنار گذاشته شوند و ایده‌ها و قابلیت‌های جدید که هرگز قبل از این روی هارد درایوها جوابگو نبود را می‌توان آزمایش کرد. مایکروسافت و سونی در مورد آنچه که این موضوع برای نسل آینده‌ی کنسول‌ها درپی خواهد داشت، توافق نزدیکی دارند و بیشترِ مزایای مشابه را هم برای کاربران نهایی تشریح کرده‌ا‌ند.

بیشترین تغییرات در طراحی بازی‌ها که با رهایی از هارد درایوها میسر شده، تاثیرِ کمی در تجربه‌ی بازی از یک ثانیه به ثانیه‌ی بعد خواهد داشت: برچیدنِ راهکارهای مربوط‌به ذخیره‌سازهای کند کمکِ زیادی به نرخِ فریم در ثانیه نخواهد کرد، اما برخی از نقاط ضعفِ دیگر در تجربه‌ی کلی کنسول را از بین خواهد برد. برای مبتدیان شایانِ ذکر است که درایوهای حالت جامد یا همان SSD-ها می‌توانند سطحِ بالایی از تفرق یا پراکندگی را بدون تاثیرِ محسوس در راندمان تحمل کنند، بنابراین نیاز نیست که فایل‌های بازی بعد از آپدیت‌ها تفرق زدایی (defragment) شوند. تفرق زدایی چیزی است که بیشتر کاربرانِ پی‌سی دیگر حتی نیازی به فکر کردن به آن ندارند، اما هنوز هم هر از گاهی به‌صورتِ خودکار لازم است.

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

از آنجایی که دیگر نیاز نیست توسعه‌دهندگانِ بازی نگرانِ حفظ موقعیتِ مکانی داده‌ها روی دیسک باشند، دیگر لزومی هم نخواهد بود که داده‌هایی که در بخش‌های مختلف بازی بازاستفاده می‌شوند، روی بخش‌های مختلف دیسک تکرار شوند. کافی است که صداهای بیشتر مورد استفاده، بافت‌ها و مدل‌ها فقط یک بار در فایل‌های بازی گنجانده شوند. این امر حداقل تاثیرِ کوچکی در کند کردنِ رشدِ حجمِ نصبِ بازی‌ها خواهد داشت، اما احتمالاً این روند را معکوس نمی‌کند، مگر جایی که یک استودیو از ویرایشگرهای مرحله (level editors) و ویژگی‌های کپی و چسباندنِ آن شدیدا سوءاستفاده کرده باشد.

سوءاستعمالِ ابزار کپی در طراحی مراحل

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

چگونه یک پورتِ کنسولیِ ناقص برای پی‌سی را بشناسیم

اما SSD-های NVMe سرعت‌های نوشتنی دارند که حتی از این ملزومات هم فراتر می‌رود و امکانِ ایجاد تغییراتی را در نحوه‌ی ذخیره‌‌ی بازی‌ها می‌دهد. به‌جای جمع‌بندیِ میزانِ پیشرفت بازیکن در یک فایل که فقط چند مگابایت است، کنسول‌های جدید برای خالی کردنِ گیگابایت‌ها داده روی دیسک، آزادی عمل خواهند داشت. تمامِ حافظه‌ی RAM که توسط بازی استفاده شده، می‌تواند در عرضِ چند ثانیه روی یک SSD پر سرعت NVMe ذخیره شود. اما اکنون فایلِ ذخیره و متعلقاتِ در حال استفاده‌ی بازی از آخرین باری که در حال اجرا بوده به‌سادگی می‌تواند خوانده شده و دوباره در RAM بارگذاری شود تا کلِ موقعیتِ بازی تنها در یک یا دو ثانیه از سرگرفته شود (Resume) و تمام صفحاتِ شروع و عملیاتِ بارگذاری در بازی‌ها را دور بزند.

قابلیت quick resume در Xbox Series X 

عدم تکرار داده‌های بازی در کنسول‌های جدید مزیتی است که به‌صورت پیش فرض به پورت‌های نسخه‌ی پی‌سی هم منتقل خواهد شد و عدمِ وجود تفرق چیزی است که پی‌سی گیمرها برای سال‌ها است از آن لذت می‌برند. هیچ یک از این تغییرات (ذخیره‌ی آنی و از سرگیری آنی بازی) به SSD پیشرفته‌ای نیاز ندارند و هر دو می‌توانند حتی روی SSD-های SATA هم درست کار کنند (البته نه خیلی آنی)، اما پیاده‌سازیِ آن نیاز به کمی کمک توسط سیستم‌عامل دارد و به همین جهت شاید عادی شدنِ این قابلیت روی پی‌سی کمی زمان‌بر باشد. (سیستم‌های عاملِ دسکتاپی مدت‌ها است از قابلیتِ hibernate و فراخوانیِ تصویر کلِ سیستم‌عامل پشتیبانی می‌کنند، اما انجام این کار برای هر برنامه غیرِ معمول است)

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

طراحی مرحله برای دستگاهی تنها با ۶۴ مگابایت RAM

بازی‌های جهان باز هم برای کاستن از المان‌های طراحی، به کم کردن از جزئیاتِ محیط و محدود کردنِ حرکاتِ بازی می‌پردازند. بنابراین مهم نیست که بازیکن انتخاب کند که به کجا برود، متعلقاتِ بازی می‌توانند در پس زمینه به داخلِ حافظه استریم شده و بارگذاری شوند. با SSD-های سریع بازی‌سازان و بازیکنان هر دو آزادی عمل بیشتری خواند داشت، اما برخی از توالی‌های حرکت هنوز هم برای تغییر صحنه‌های عمده مورد نیاز خواهد بود. کنسول‌ها نمی‌توانند تمامِ محتویاتِ RAM از یک فریم به فریمِ بعدی را دوباره بارگذاری کنند; این کار هنوز چندین ثانیه زمان خواهد برد.

SSD به‌عنوانِ RAM

سرانجام به چیزی می‌رسیم که شاید قابل‌توجه‌ترین نتیجه‌ی استانداردسازیِ SSD-ها و مورد نیاز بودن آن‌ها برای بازی‌ها باشد، اما در عینِ حال اغراق‌آمیز‌ترین قابلیت آن است: مایکروسافت و سونی هر دو در طی گفته‌های خود اظهار داشته‌اند که SSD را تقریبا می‌توان مانند حافظه‌ی اصلی استفاده کرد. اجازه دهید در اینجا با صراحت بگوییم که SSD-های کنسولی جایگزینی برای RAM نیستند. SSD استفاده شده در PS5 تنها می‌تواند ۵.۵ گیگابایت داده را تأمین کند. اما حافظه‌ی RAM در ۴۴۸ گیگابایت بر ثانیه کار می‌کند، و این یعنی ۸۱ برابر سریع‌تر. کنسول‌ها ۱۶ گیگابایت حافظه‌ی اصلی از نوعِ GDDR6 دارند. اگر یک بازی نیاز به استفاده‌ی بیش از ۱۶ گیگابایت برای رندرِ یک صحنه داشته باشد، نرخِ فریم به رده‌های پایینی سقوط خواهد کرد، چرا که SSD-ها به اندازه‌ی کافی سریع نیستند. SSD-ها در هر دو زمینه‌ی توانِ عملیاتی و تأخیر ناکافی هستند.

مطمئناً برای یک مرحله در بازی امکان استفاده از بیش از ۱۶ گیگابایت متعلقات (Assets) وجود دارد ، اما همه‌ی آن‌ها به یکباره نمایش داده نمی‌شوند. اصطلاح فنی در اینجا Working set است: مقداری از حافظه که واقعا به‌صورت فعال در یک زمان استفاده می‌شود. آنچه که SSD تا حدی تغییر می‌دهد، آستانه‌ی چیزی است که می‌تواند به‌عنوانِ فعال در نظر گرفته شود.

با یک SSD سریع، متعلقاتی که نیاز است در حافظه نگه داشته شوند بیش از آنچه که اکنون روی صفحه (on-screen) نمایش داده می‌شود نخواهند بود و بازی نیاز ندارد که صحنه‌های خیلی جلوتر را پیش بارگذاری یا واکشی (prefetch) کند. بافت‌های جسمی که در همان اتاق ولی فعلا خارج از صفحه است، می‌تواند روی دیسک باقی بماند تا زمانی‌که دوربین شروع به چرخیدنِ به آن سمت کند. این در حالی است که یک سیستمِ متکی به هارد درایو احتمالا نیاز خواهد داشت که متعلقات تمامِ اتاق و حتی اتاق‌های مجاور را در حافظه نگه دارد تا از وقفه (Stutter) اجتناب شود. این تفاوت به این معنی است که یک کنسول مبتنی بر SSD (مخصوصا با راندمانِ NVMe) می‌تواند مقداری از حافظه‌ی گرافیکیِ VRAM را آزاد کند و اجازه‌ دهد تعدادی از متعلقات با رزلوشنِ بالاتر استفاده شوند.

البته این کار تحولِ بزرگی نیست: مانند این نیست که SSD حافظه‌ی گرافیکیِ موثر را به میزانِ ده‌ها گیگابایت افزایش داده باشد، اما بسیار محتمل است که به بازی‌ها امکان دهد که از چند گیگابایتِ اضافیِ خالی شده از RAM، برای محتویاتِ روی صفحه استفاده کنند، به‌جای اینکه بخواهند متعلقاتِ خارج از صفحه را پیش بارگذاری کنند. مارک سرنی آن را با این گفته برآورد کرده که اکنون باز‌ی‌ها فقط نیاز به پیش بارگذاریِ یک ثانیه جلوتر را دارند، به‌جای اینکه بخواهند حدودِ ۳۰ ثانیه جلوتر را بارگذاری کنند.

لایه‌ی دیگری هم در این مزیت وجود دارد: ایجاد بافت‌های نیمه مقیم در پلتفرم‌های دیگر هم امکان‌پذیر بوده است، اما اکنون قدرتمندتر می‌شوند. آنچه در ابتدا برای بافت‌های زمینیِ چند هکتاری ایجاد شده بود، اکنون می‌تواند به‌طور مؤثر در اشیاء بسیار کوچکتر مورد استفاده قرار گیرد. واحدِ بازخوردِ نمونه (sampler feedback) به GPU امکان می‌دهد که اطلاعاتِ دقیق‌تر و با جزئیاتِ بیشتری را در رابطه با اینکه کدام بخش از بافت واقعا در حال نمایش است، برای اپلیکیشن فرآهم کند. بازی هم می‌تواند از آن اطلاعات برای ارسالِ درخواست خواندن به SSD فقط برای همان بخش‌های فایل استفاده کند.

این کار می‌تواند با بلاک‌های کوچک ۱۲۸ کیلوبایتی از بافت (فشرده نشده) انجام شود که آنقدر کوچک است که می‌تواند با بارگذاری نکردنِ چندضلعی‌هایی که استفاده نمی‌شود، صرفه‌جوییِ معنی‌داری را در RAM به ارمغان آورد و در عینِ حال هنوز دستورهاِ خواندنی از SSD صادر کند که آنقدر بزرگند که برای ویژگی‌های عملکردیِ SSD مناسب باشند.

مایکروسافت اظهار داشته که این قابلیت‌ها ۲ تا ۳ برابر به ظرفیتِ RAM و پهنای باندِ SSD می‌افزایند که البته قانع‌کننده نیست. اما به‌طور حتم، پهنای باند زیادی در SSD-ها می‌تواند در محدوده‌های زمانیِ کوتاه توسطِ بارگذاریِ تدریجیِ صحنه‌ها صرفه‌جویی شود. اما شک داریم که این ویژگی‌ها به سری ایکس با حدودِ ۱۰ گیگابایت حافظه‌ی VRAM اجازه دهد که مناظرِ پر جزئیاتی را که می‌توان در یک کارت گرافیکیِ PC با ۲۴ گیگابایت حافظه‌ی گرافیک ترسیم کرد، مدیریت کند. هر چند که خوشحال می‌شویم اگر آن‌ها خلافِ این را ثابت کنند.

چه چیزهایی برای به‌دست آوردن راندمان کامل از درایو SSD لازم است؟

سخت‌افزارِ ذخیره‌ساز در کنسول‌های جدید غیرممکن‌های زیادی را ممکن می‌کنند، اما فقط به اتکای سخت‌افزارشان نمی‌توانند در گیمینگ انقلاب ایجاد کنند. پیاده‌سازی قابلیت‌های جدید که توسطِ SSD-های سریع ممکن شده، هنوز نیازمندِ کارِ نرم‌افزاری از سوی فروشندگانِ کنسول و توسعه‌دهندگانِ بازی‌هاست. استخراج راندمانِ کامل از یک SSD رده بالای NVMe نیاز به رویکردی متفاوت به مقوله‌ی ورودی/خروجی یا همان I/O نسبت به روش‌هایی دارد که برای هارد درایوها و دیسک‌های نوری کار می‌کنند.

هنوز هیچ SSD کنسولیِ نسل بعدی در اختیار نداریم که آزمایش کنیم، اما براساس مشخصات معدودی که تا به حال منتشر شده، می‌توانیم پیش‌بینی‌های خوبی در مورد ویژگی‌های عملکردی آن‌ها داشته باشیم. اولین و مهم‌ترین مورد اینکه رسیدن به سرعت‌های خواندنِ ترتیبیِ تبلیغ شده، نیاز به مشغول نگه داشتنِ SSD-ها با تعدادِ زیادی درخواست برای داده خواهد داشت. یکی از سریع‌ترین SSD-هایی که تاکنون تست کرده‌ایم -PM1725a ساخت سامسونگ- را در نظر بگیرید. این مدل قادر است به سرعت بیش از ۶.۲ گیگابایت در ثانیه در عملیاتِ خواندنِ ترتیبی در بلاک‌های ۱۲۸ کیلوبایتی برسد.

اما درخواستِ این بلاک‌ها با تعدادِ یکی در هر زمان (Q1T1) سرعت را به ۶۸۰ مگابایت در ثانیه تقلیل می‌دهد. این درایو نیاز به عمق صف (queue depth) حداقل به میزان ۱۶ دارد تا به سرعت ۵ گیگابایت بر ثانیه برسد و عمق صف ۳۲ (QD32) را لازم دارد تا به سرعت ۶ گیگابایت در ثانیه برسد. SSD-های جدیدتر با حافظه‌های فلشِ سریع‌تر ممکن است به این عمق صف‌های بالا نیاز نداشته باشند، اما بازی‌ها قطعا نیاز دارند که چیزی بیش از چند درخواست در یک زمان ارسال کنند تا SSD کنسول را مشغول نگه دارند.

کنسول‌ها توانایی این را ندارند که میزانِ زیادی از قدرتِ پردازنده را برای رد و بدل کردن اطلاعات با SSD-ها هدر دهند، بنابراین به راهی نیاز دارند که فقط یک یا دو رشته‌ی پردازشی بتوانند تمام درخواست‌های I/O را مدیریت کنند و زمانِ باقیمانده‌ی CPU از هسته‌هایش را هم برای انجامِ کاری سودمند روی داده‌ها در اختیار داشته باشند. این یعنی کنسول‌ها باید با استفاده از API-های نامتقارن برنامه‌ریزی شوند، جایی که یک رشته، یک درخواستِ خواندن به سیستم‌عامل یا کمک پردازنده‌ی I/O می‌دهد، اما به کار خودش بازمی‌گردد تا زمانی‌که درخواست پردازش شده باشد. و رشته‌ی پردازشی بعدا دوباره باید چک کند که درخواستش انجام شده است یا خیر. در دورانِ هارد درایوها، چنین رشته‌ای باید زمانی‌که منتظر کامل شدنِ عملیاتِ خواندن بود، خاموش می‌شد و تعدادی از وظایفِ غیر مرتبط با ذخیره‌ساز را انجام می‌داد. اما حالا، آن رشته می‌تواند آن زمان را به ارسال درخواست‌های بسیار بیشتر به ذخیره‌ساز اختصاص دهد.

به جز بالا نگه داشتنِ میزانِ عمقِ صف، به‌دست آوردن سرعت کامل از SSD مستلزم این است که عملیاتِ I/O در بخش‌های بزرگ انجام شود. تلاش برای رسیدن به ۵.۵ گیگابایت بر ثانیه با درخواست‌های ۴ کیلوبایتی نیاز به مدیریتِ تعدادی حدودِ ۱.۴ میلیون عملیات I/O در ثانیه دارد که ممکن است بسیاری از بخش‌های سیستم را با سربار (overhead) درگیر کند. خوشبختانه بازی‌ها ذاتا تمایل دارند که با بخش‌های بزرگی از داده‌ها سر و کار داشته باشند، بنابراین این مورد مشکل خیلی بزرگی محسوب نمی‌شود و عمدتا به این معنی است که بسیاری از معیارهای سنتی راندمانِ SSD غیر ضروری و نامرتبط هستند.

مایکروسافت بسیار کم در مورد سمت نرم‌افزاریِ پشته‌ی ذخیره‌ساز ایکس‌باکس سری ایکس گفته است. آن‌ها API جدیدی را به نام DirectStorage معرفی کرده‌اند. ما هیچ توضیحی در موردِ شیوه‌ی کارکردِ آن و وجه تمایزش نسبت به API بکار رفته در کنسول‌های فعلی و قبلی در اختیار نداریم، اما این API ساخته شده تا بهینه‌تر باشد:

DirectStorage می‌تواند از سربارِ CPU برای این عملیات‌ I/O بکاهد و آن را از گرفتنِ چندین هسته، به تنها بخشِ کوچکی از یک تک هسته کاهش دهد.

جالب‌ترین قسمت درباره‌ی DirectStorage این است که مایکروسافت قصد دارد آن را به ویندوز بیاورد، بنابراین API جدید نمی‌تواند به هیچ سخت‌افزار اختصاصی در پی‌سی متکی باشد و باید به‌گونه‌ای باشد که در بالای سیستم فایلِ NTFS رایج عمل کند. براساس تجربه‌ای که از آزمونِ SSD-های سریع تحتِ ویندوز داشته‌ایم، آن‌ها قطعا می‌توانند از یک API ذخیره‌سازی با سربارِ کم استفاده کنند، و این گزینه قابل تسری به فراتر از بازی‌های ویدیوییِ صِرف خواهد بود.

طراحیِ API ذخیره‌سازی سونی احتمالا با کمک پردازنده‌های I/O آن‌ها در هم تنیده شده است، اما بعید است که بازی‌سازان باید به‌طور خاص آگاه باشند که پردازشِ درخواست‌های ورودی/خروجی آن‌ها از دوشِ CPU برداشته شده است. مارک سرنی اظهار کرده که بازی‌ها می‌توانند عملیات عادیِ ورودی/ خروجی فایل را دور بزنند که بخشی از آن در گفت‌وگو با دیجیتال فاندری تشریح شده است:

در آن‌جا دسترسی سطح پایین و سطح بالا داریم و بازی‌سازان می‌توانند هر یک را که دوست دارند، انتخاب کنند. اما این یک API جدید است که به توسعه‌دهندگان اجازه می‌دهد به سرعت‌های بی‌نهایت بالای سخت‌افزارِ جدید دسترسی پیدا کنند. ایده‌ی اسامیِ فایل‌ها و مسیرها جایش را به سیستمی براساسِ شناسه‌ (ID) داده که به سیستم می‌گوید دقیقا کجا داده‌هایی را که نیاز دارد به سریع‌ترین شیوه‌ی ممکن پیدا کند. کافی است که سازندگان به‌سادگی فقط ID را معین کنند، موقعیتِ آغاز، پایان و چند میلی‌‌‌‌‌ثانیه بعدتر خود داده هم تحویل می‌شود. دو فهرستِ دستوری به سخت‌افزار ارسال می‌شوند که یکی دارای فهرستِ ID-ها بوده و دیگری با محوریت تخصیص حافظه و تغییر مکان حافظه است تا از خالی شدنِ حافظه برای داده‌های جدید مطمئن شویم.

خلاص شدن از شرِ اسامی فایل‌ها و مسیرهای ذخیره‌سازی به خودیِ خود افزایشِ راندمان را به‌دنبال ندارد، مخصوصا از آن‌جا که سیستم هنوز مجبور است به خاطر کدهای قدیمی از API سیستم فایل سلسله مراتبی هم پشتیبانی کند. پس‌اندازِ واقعی از توانایی معین کردنِ کلِ پروسه‌ی I/O در یک تک مرحله می‌آید، به‌جای اینکه برنامه مجبور باشد بخش‌هایی مانندِ غیر فشرده‌ سازی و تخصیصِ حافظه برای داده‌ها را مدیریت کند. هر دوی این بخش‌ها توسطِ سخت‌افزارِ تک منظوره در PS5 کنترل می‌شوند.

تحت کنترل نگه داشتنِ تأخیر

درحالی‌که توسعه‌دهندگان ملزم به تلاش برای استخراجِ راندمانِ کامل از SSD-های کنسولی هستند، یک هدفِ رقیب نیز وجود دارد. وادار کردنِ SSD به کار در حداکثرِ عملکرد باعثِ افزایشِ قابل‌توجه تأخیر می‌شود، مخصوصا اگر عمقِ صف، بالاتر از میزانی برود که برای اشباعِ درایو نیاز داریم. این تأخیر اضافی درحالی‌که کنسول فقط در حالِ نمایشِ یک صفحه‌ی بارگذاری باشد اهمیتی ندارد، اما بازی‌های نسل بعدی می‌خواهند که همزمان با استریمِ مقادیرِ زیادی از داده‌ها، بازی را در حالتِ اجرای تعاملی و پاسخ‌گو حفظ کنند. سونی نقشه‌اش را برای تعامل با این چالش ترسیم کرده است: SSD آن‌ها قابلیتِ ویژه‌ای دارد که ۶ سطحِ اولویت (priority level) برای دستورهاِ I/O را پشتیبانی می‌کند تا اجازه دهد حجم زیادی از داده‌ها بارگذاری شوند، بدون اینکه برای درخواست‌های خواندن‌ اضطراری‌تر مسیر مسدود باشد یا خللی ایجاد شود. سونی دلایلِ زیادی برای این ویژگی یا نحوه‌ی عملکرد آن توضیح نداده است ، اما راحت می‌توان فهمید که چرا آن‌ها برای اولویت بندیِ I/O به چنین چیزی احتیاج دارند.

بارگذاریِ دنیای جدید در ۲.۲۵ ثانیه درحالی‌که Ratchet & Clank در یک شکافِ میان بُعدی سقوط می‌کند

مارک سرنی یک مثالِ فرضی را از هنگامی که سطوحِ اولویت چندگانه مورد نیاز است مطرح می‌کند: وقتی که بازیکن به موقعیت جدیدی حرکت می‌کند، ممکن است بسیاری بافت‌های جدید در اندازه‌ی چندین گیگابایت بر ثانیه نیاز به بارگذاری داشته باشند. اما از آن‌جا که بازی توسطِ یک صفحه‌ی بارگذاری متوقف نشده، اتفاق‌ها هنوز در بازی در جریان هستند و رخدادهای بازی (مثلا تیر خوردنِ کاراکتر) ممکن است به بارگذاریِ داده‌هایی مانندِ افکت‌های صوتی نیاز داشته باشند. درخواستِ مربوط‌به آن افکت صوتی بعد از درخواستِ چندین گیگابایت بافت صادر خواهد شد، اما لازم است که افکت صوتی قبل از اتمامِ بارگذاری بافت‌ها بارگذاری شود، چرا که صدای متقاطع بسیار قابل‌توجه‌تر و آزاردهنده‌تر از تأخیر جزئی در بارگذاری تدریجیِ داده‌های بافت جدید خواهد بود.

اما استانداردِ NVMe همین حالا هم قابلیتِ اولویت بندی را شامل می‌شود، پس چرا سونی استانداردِ خودش را توسعه داده است؟ SSD سونی ۶ سطحِ اولویت بندی را پشتیبانی خواهد کرد، و مارک سرنی ادعا کرده که استاندارد NVMe فقط ۲ سطحِ اولویتِ واقعی را پشتیبانی می‌کند. نگاهی گذرا به مشخصات NVMe نشان می‌دهد که این اولویت بندی آنقدرها هم ساده نیست:

الگوریتم Round Robin وزن‌دار برای اولویت بندی در درایوهای NVMe

مشخصات NVMe برای تعیین اینکه کدام صف فرمان بعدی را برای دستیابی به درایو فراهم می‌کند ، دو الگوی داوری در مورد دستورهاِ مختلف را تعریف می‌کند. اما الگوی پیش فرض، ایجادِ یک توازن براساسِ الگوریتمِ Round-robin ساده است که با تمام صف‌های I/O به‌طور یکسان رفتار می‌کند و همه‌ی اولویت بندی‌ها را بر عهده‌یِ سیستم میزبان می‌گذارد. درایوها همچنین می‌توانند الگوی Round-robin وزن‌دار را به‌صورت اختیاری پیاده‌سازی کنند، که ۴ سطح اولویت را ارائه می‌دهد (بدونِ احتسابِ دستورهاِ مدیر یا Admin). اما ظاهرا جزئیاتی که سونی با آن‌ها سروکار دارد، در سطحی بالاتر از آن چهار سطح اولویت قرار می‌گیرد، چرا که فقط به کلاس "فوری" نسبت به سایر سطوح اولویت اضطراری داده می‌شود. اولویت بندیِ سخت‌گیرانه ساده‌ترین شکل اولویت بندی برای پیاده‌سازی است، اما چنین روش‌هایی، انتخابی ضعیف برای سیستم‌های چند منظوره هستند. در یک سیستم اختصاصیِ بسته مانند کنسولِ بازی، هماهنگی بینِ تمام نرم افزارهایی که عملیاتِ I/O انجام می‌دهند به منظور جلوگیری از بن بست و بیکار ماندن بسیار ساده‌تر است. بخش اعظمی از عملیاتِ I/O که توسط یک کنسول بازی انجام می‌شود، نیاز به الزامات زمان‌بندیِ مطابق با رخدادهای دنیای واقعی دارند.

سونی می‌گوید عدم وجودِ شش سطح اولویت در درایوهای NVMe موجود در بازار به این معنی است که آن‌ها به عملکرد خام کمی بالاتر نیاز دارند تا با راندمانِ واقعی درایو سونی مطابقت داشته باشند، زیرا سونی باید ۶ سطح از اولویت را با ترکیبی از کارِ پردازنده و کمک پردازنده‌ی I/O در میزبان پیاده‌سازی کند. براساس مشاهدات ما در مورد SSD-های سازمانی (که بیشتر با تمرکز روی QoS نسبت به SSD-های مصرف‌کننده طراحی شده‌اند) ، نگه داشتن ۱۵ تا ۲۰ درصد از عملکرد به‌صورت ذخیره، به‌طور معمول تأخیر را در میزانِ بسیار پایینی (حدود ۲ برابرِ تأخیر SSD در حالتِ بیکار)، بدون استفاده از هیچ مکانیسم اولویت بندی حفظ می‌کند. بنابراین برآورد می‌کنیم درایوهایی که قادر به رسیدن به سرعتِ ۶.۵ گیگابایت در ثانیه یا بیشتر باشند، نباید هیچ مشکلی در این زمینه داشته باشند.

افزایشِ تأخیر در SSD همزمان با رسیدن به سقفِ عملکردِ درایو

هنوز هم کاری که سونی قصد دارد با این تعدادِ بالا از سطوح اولویت انجام دهد، برای ما معماگونه است. مطمئناً می‌توانیم سلسله مراتبی از چندین سطح اولویتی را برای انواع مختلف داده‌ها تصور کنیم: شاید کدِ بازی بالاترین اولویت بارگیری باشد، زیرا حداقل یک رشته‌ی در حالِ اجرا در حین بررسیِ یک خطای صفحه (page fault) کاملاً متوقف خواهد شد، بنابراین به این داده‌ها در سریع‌ترین حالتِ ممکن نیاز خواهد بود (و به شکلِ ایده‌آل باید تمام وقت در RAM نگه داشته شوند، به‌جای اینکه در پس زمینه بارگذاری شوند).

احتمالاً پیش بارگذاریِ بافت‌ها کمترین اولویت را دارد، به‌خصوص واکشیِ mipmap-های با وضوح بالاتر، وقتی که نسخه‌ی رزولوشن پایین آن‌ها از قبل در حافظه‌ی RAM موجود است و موقتا نیز قابل استفاده هستند (mipmap در گرافیک کامپیوتری یک تکنیک بافت‌زنی است که در آن کیفیت‌های متفاوتی از بافت در رزولوشن‌های مختلف استفاده می‌شود). ترسیمِ هندسی ممکن است اولویت بالاتری نسبت به بافت‌ها داشته باشد، چرا که می‌تواند برای تشخیصِ تصادم (collision detection) مورد نیاز باشد و بافت‌ها بدون استفاده از ترسیمِ شکلِ هندسی برای اِعمال به آن‌ها بی فایده خواهند ماند. جلوه‌های صوتی باید در حالت ایده‌آل، حداکثر با تأخیر چند ده میلی ثانیه بارگذاری شوند. ثبت اختراعِ سونی به دادنِ اولویت بالاتر به I/O با استفاده از API جدید اشاره کرده است، بر این اساس که چنین کدی به احتمالِ زیاد در رده‌ی عملکردِ بحرانی (performance-critical) قرار خواهد گرفت.

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

اگر دستورها زیادی در صف منتظر باشند، یک دستور جدید هم که در آخر صف اضافه می‌شود، باید مدتی طولانی در انتظار باشد. اگر یک بازی در PS5 درخواست‌های جدید را با نرخی بیش از مجموعِ ۵.۵ گیگابایت در ثانیه به SSD ارسال کند، یک انبارِ دستوری ایجاد خواهد شد و تأخیر همینطور افزایش می‌یابد، تا زمانی‌که سرعتِ ارسال درخواست‌های داده از سوی بازی، نسبت به سرعتی که SSD قادر به تحویل آن است کاهش یابد. هنگامی که درخواست‌های بازی در سرعتی بسیار کمتر از ۵.۵ گیگابایت بر ثانیه باشد، هر بار که دستور جدیدِ‌ خواندن به SSD ارسال می‌شود، تقریباً بلافاصله پردازشِ آن درخواست شروع خواهد شد. بنابراین مهم‌ترین کار، محدود کردن میزان درخواست‌هایی است که می‌توانند در صف‌های SSD تجمع کنند و پس از حل شدن این مشکل، نیازی به اولویت بندیِ بیشتر نیست.

جمع‌بندی

مهاجرتِ کنسول‌های بازی به ذخیره‌سازهای حالت جامد یا همان SSD-ها، افقِ دیدِ طراحی و توسعه‌ی بازی‌های ویدیویی را تغییر خواهد داد. یک سد در حالِ شکستن است و سازندگان بازی به‌زودی می‌توانند محدودیت‌های هارد درایوها را نادیده بگیرند و شروع به کَند و کاو در مورد امکاناتِ یک ذخیره‌سازِ سریع کنند. ممکن است استفاده‌ی کامل از راندمانِ SSD-های کنسولیِ جدید مقداری زمان ببرد، اما بهبودهای قابل‌توجه زیادی را در شروع عرضه‌ی کنسول‌ها هم شاهد خواهیم بود.

تأثیرات این مهاجرت به بازار بازی‌های رایانه‌ای نیز سرایت خواهد کرد و باعثِ افزایشِ فشار برای کمک به حذفِ هارد دیسک از رایانه‌های رده پایینِ گیمینگ خواهد شد و به گیمرهای دارای پی‌سی‌های پرقدرت اجازه می‌دهد تا از عملکردِ SSD-های سریع ولی بکارگیری نشده‌ی خود لذتِ بیشتری ببرند. و تغییرات در خودِ سیستم‌عاملِ ویندوز به خاطرِ این کنسول‌های جدید همین حالا هم در راهِ انجام گرفتن است.

درنهایت، جالب خواهد بود که ببینیم آیا قطعاتِ جدید در زیرسیستم‌های ذخیره‌سازیِ کنسول‌های جدید، آنچنان به‌عنوان یک مزیت واقعی محسوب خواهند شد که بتوانند بر جهت‌گیریِ توسعه‌ی سخت‌افزار رایانه‌های شخصی تأثیرگذار باشند، یا در پایان فقط تغییراتِ جالبی باشند که در گرد و غبار گم شوند، چرا که سخت‌افزار پی‌سی سرانجام با راندمانِ خامِ برتر، از کنسول‌‌ها پیشی خواهد گرفت. SSD-های NVMe از پنج سال پیش به رده‌های بالای بازار مصرف‌کننده رسیدند. اکنون آن‌ها در حال عبور از یک نقطه‌ی اوج و به خوبی در راه تبدیل شدن به استانداردِ اصلی برای ذخیره‌سازی هستند.