آنچه باید در مورد DirectX12 بدانید

در سال ۲۰۱۴ مایکروسافت از نسخه جدید API گرافیکی DirectX که با نام DirectX12 شناخته می‌شود رونمایی کرد و قرار شد که با عرضه ویندوز ۱۰، DirectX12 نیز رسماً عرضه شود. حال با عرضه ویندوز ۱۰، DirectX12 رسماً عرضه شده است و هرچند هنوز از آن استفاده چندانی نشده است ولی ازاین‌پس قدرت آن قابل‌استفاده خواهد بود و به‌زودی شاهد عناوینی خواهیم بود که از این API گرافیکی پشتیبانی کنند. ازاین‌رو در ادامه نگاهی می‌اندازیم به DirectX12 و این API گرافیکی و تأثیر آن بر گیمرها را بررسی خواهیم کرد…

تذکر: بخش اعظم این مقاله بر اساس سایت PC Gamer باکمی تغییرات نوشته شده است.

زمان عرضه ویندوز ۱۰، اولین زمانی است که عموم جامعه PC Gaming به نسخه جدید DirectX که یک API گرافیکی Low-Level است، دسترسی خواهند داشت (توجه کنید که Low-Level یا سطح پایین به معنی سطح پایین کیفی نیست و به معنی دسترسی به جزییات بالاتر در کار با مؤلفه‌های مختلف گرافیکی و سطوح پایین‌تر و عمیق‌تر کار است). حتی از زمانی که Mantel که API گرافیکی شرکت AMD است معرفی شده، صحبت‌های زیادی پیرامون این موضوع وجود دارد که تا چه حد قابل‌توجهی دستاوردهای API های سطح پایین واقعاً مربوط به بازیبازها می‌شود. نظرات گسترده‌ای پیرامون این موضوع داده شد، ازنظراتی در مورد این‌که Mantel انقلابی در پردازش‌های گرافیکی است گرفته تا نظراتی که Mantel را کمی بیش‌تر از یک کمپین تبلیغاتی می‌دانستند. این مطلب، دورنمای هوشمندانه‌ای ازآنچه DirectX12 واقعاً به بازیبازها عرضه خواهد کرد، ارائه داده و در مورد این‌که در چه شرایطی و زمانی ما می‌توانیم این تأثیرات را مشاهده کنیم، صحبت خواهد شد.

نگاهی به گذشته

برای توضیح چرایی و دلیل استفاده از DirectX12 و نه‌فقط چیستی آن، ما در این مقاله به موضوعاتی که منجر به تصمیم‌گیری‌هایی در مورد API های گرافیکی شدند و همچنین رشد آن‌ها تا رسیدن به سطح کنونی صحبت خواهیم کرد؛ ازاین‌رو بخش زیادی از این مطلب جنبه فنی خواهد داشت. اگر شما در درجه اول می‌خواهید بدانید که این تغییرات چه تأثیری بر روی شما به‌عنوان یک گیمر خواهد داشت و باید انتظار چه چیزی را بعد از آپگرید به ویندوز ۱۰ در زمان حال و آینده نزدیک داشته باشید، می‌توانید بخش‌های تخصصی این مقاله را مطالعه نکنید و صرفاً بخش‌های پایانی آن که بر روی تأثیر آن بر روی گیمرها و نکات مهم صحبت می‌کند و خیلی تخصصی نیست را مطالعه کنید. دقت کنید که این مقاله در مورد “ویژگی‌های گرافیکی جدید انگشت‌شماری نیست که از طریق DirectX12 در اختیار سخت‌افزارها قرار خواهد گرفت “، نیست. هر نسخه جدیدی از یک API، پشتیبانی از یک سری از قابلیت‌های سخت‌افزاری را به لیست ویژگی‌های خود اضافه می‌کند و این موضوع که مثلاً شما می‌توانید از ویژگی گرافیکی Order-independent Transparency بر روی DirectX12 به‌صورت بهینه‌تر استفاده کنید مستقل از صحبت در مورد API های سطح پایین و یا سطح بالا است. جدایی این موضوعات ازآنجا ناشی می‌شود که این ویژگی‌ها به DirectX 11.3 نیز اضافه شده‌اند تا سازندگانی که نمی‌خواهند از DirectX 12 استفاده کنند، از این قابلیت‌ها بی‌بهره نباشند. انتظار می‌رود که در سال‌های آینده استفاده از این ویژگی‌های سخت‌افزاری اهمیت بیش‌تری پیدا کند ولی این مسائل اثر حداقلی بر روی موج اول بازی‌هایی خواهند داشت که با استفاده از Direct3D 12 عرضه خواهند شد.

تاریخچه مختصری از DirectX و API ها

قبل از این‌که ما در مورد تغییراتی که DirectX12 ایجاد خواهد کرد صحبت کنیم، باید یک سری موارد پایه‌ای را توضیح دهیم. اول‌ازهمه، یک 3D API واقعاً چیست؟ هنگامی‌که برای اولین بار سخت‌افزارهای شتاب‌دهنده سه‌بعدی (3D Accelerator Hardware) عرضه شدند، نیاز به ارائه یک رابط کاربری بود تا برنامه‌نویسان بتوانند از ظرفیت‌های آن استفاده کنند. یک رابط برنامه‌نویسی نرم‌افزار (Application Programming Interface یا به‌اختصار API) همان چیزی است که قرار بود امکان این کار را فراهم کند. درحالی‌که Glide API توسط شرکت 3dfx Interactive عرضه شده بود، توانست برای مدتی نیازها را برطرف کند، اما واضح بود که برای ادامه یافتن رشد این بازار، ارائه یک رابط کاربری خلاصه و مستقل از سخت‌افزار ضروری است. این رابط کاربری قرار بود که توسط DirectX و OpenGL ارائه شود.

واحدهای پردازش گرافیکی (Graphic Processing Unit یا GPU) در آن زمان نسبت به الآن وسایلی بسیار ساده‌تر بودند. درنهایت در آن زمان API ها فقط قرار بود که به سازنده امکان ایجاد بافت و شاید روشن کردن و نورپردازی روی مثلث‌ها را بدهند زیرا سخت‌افزار –هم فقط- این کار را انجام می‌داد. توانایی‌های سخت‌افزاری از آن موقع تابه‌حال سریعاً تکامل یافته‌اند و API ها نیز به‌تدریج با توجه به این موضوع تنظیم شدند و یکسری از ویژگی‌ها در API ها ارائه شد و بعضی دیگر در ساختمان کلی و کار در سخت‌افزار. این مطلب ازاین‌جهت گفته نشده است که بگوییم درزمینه‌ی API ها تغییرات چشمگیری صورت نگرفته است، به‌عنوان مثلاً تغییر و دور شدن از نسل Immediate Mode Geometry (هندسه آنی) برای DirectX و OpenGL یک تغییر بسیار چشمگیر بود.

بااین‌حال، عملکرد API های سطح بالا در PC همچنان بر اساس این اصل است که از برنامه‌نویس در مقابل نگرانی درباره‌ی جزئیات سخت‌افزاری محافظت کند. این موضوع می‌تواند ویژگی راحت و مناسبی باشد ولی گاهی درک کامل از اتفاقاتی که درون سخت‌افزار می‌افتد –که این موضوع قاعده کلی API های سطح پایین نیز هست- می‌تواند در مورد کارایی برنامه نقش حیاتی ایفا کند.

API Overhead Feature Test

چرا از API سطح پایین استفاده کنیم؟

API های سطح پایین تغییر بزرگی درزمینه‌ی برنامه‌نویسی سه‌بعدی بودند و معرفی آن‌ها نیاز به تلاش‌های زیادی درزمینه‌ی طراحی و مهندسی از سمت ارائه‌دهندگان پلتفرم‌ها و سخت‌افزار و همچنین سازندگان بازی‌ها و میان‌افزارها دارد. تابه‌حال و برای حدود دو دهه، API های سطح بالا “به‌اندازه کافی خوب ” بوده‌اند که بتوانند باعث پیشرفت رندرینگ سه‌بعدی در PC در سطحی که هیچ پلتفرم دیگری به آن دست نیافته است بشوند. پس چرا این تلاش‌ها برای API های سطح پایین انجام می‌شود؟ به اعتقاد بسیاری دلیل این امر ترکیب و اجتماع سازندگان مختلف با یکدیگر است که باعث می‌شود کفه ترازو به سمتی که باعث تلاش برای انجام این تغییرات می‌شود، سنگینی بکند.

دلایل سخت‌افزاری

بخش اولیه کار مربوط به تحولات سخت‌افزاری می‌شود؛ هم در GPU و شاید بیش‌تر از آن در CPU. شاید این موضوع خلاف شواهد به نظر برسد که تغییرات در سخت‌افزار CPU منجر به تحول در API های گرافیکی شده است ولی ازآنجایی‌که API به‌عنوان یک پل میان “نرم‌افزاری که بر روی CPU اجرا می‌شود” و “توانایی رندر کردن GPU” محسوب می‌شود، این موضوع خیلی هم تعجب‌آور نیست.

خط نارنجی، پیشرفت پردازش های پیوسته و خط آبی پیشرفت در پردازش های موازی را نشان می دهد

همان‌طور که پیش‌تر نیز اشاره شد، API های سطح بالا در مدت زمان دو دهه از اوایل دهه ۸۰ میلادی، درزمینه‌ی توسعه گرافیکی به‌اندازه کافی خوب به نظر می‌رسیدند. نمودار بالا عملکرد و پرفرمنس (Performance) در CPU های دسکتاپِ فوق‌العاده قوی (High-end) را در مدتِ زمانی یکسان نشان می‌دهد و به شما دلیل این امر را که چرا مفاهیم عملکردی CPU و موازی‌سازی و استفاده از سیستم موازی برای API ها در دهه ۹۰ و ۲۰۰۰ میلادی در اولویت اول افکار طراحان CPU ها نبوده است را نشان می‌دهد. خط آبی عملکرد موازی (Parallel) را نشان می‌دهد؛ درحالی‌که عملکرد کاملاً پیوسته (Sequential) با رنگ نارنجی نشان داده‌شده است. تا سال ۲۰۰۴ این دو به یکدیگر نزدیک بودند ولی بعدازآن افزایش عملکرد درزمینه‌ی پیوسته کاهش داشته است؛ بنابراین، یکی از اهداف مهم تغییر چشم‌انداز API ها در حال حاضر بهبود موازی‌سازی است که قبلاً در اولویت نبوده است.

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

دلایل نرم‌افزاری

باوجود این‌که بخش سخت‌افزاری معادله‌ی تغییرات API ها، احتمالاً مهم‌ترین و قطعاً علنی‌ترین مورد است ولی مجموعه دلایل دیگری نیز وجود دارند تا استفاده از API های (سطح بالای) موجود را متوقف کنیم و از API های دیگر (و سطح پایین‌تر) استفاده کنیم و این مجموعه دلایل کاملاً مربوط به نرم‌افزارها هستند. هر PC Gamer ـی باید با این روند وقایع آشنا باشد: یک بازی خیلی مورد انتظار AAA منتشر می‌شود و تقریباً در یک‌زمان هر دو شرکت سازنده GPU درایورهای جدیدی که برای آن عنوان “بهینه ” شده‌اند را منتشر می‌کنند. این درایور ممکن است باعث اجرای سریع‌تر آن عنوان بشود و یا حتی برای اجرای آن ضروری باشد.

دلیل این امر این نیست که سازندگان بازی یا مهندسان ساخت درایور نالایق هستند؛ این موضوع مربوط به “‌اندازه‌ی API های گرافیکی سطح بالای مدرن که بعدازاین همه سال تغییرات و اضافه شدن موارد مختلف عرضه شده‌اند” و “همچنین پیچیدگی سرسام‌آور درایورهای گرافیکی” می‌شود که باید به‌نوعی این API های خلاصه شده را به مجموعه‌ای از راهنمایی‌ها و سازوکارها تبدیل کنند که GPU بتواند آن را متوجه بشود و به‌طور بهینه‌ای اجرا کند. کاهش مسئولیت‌های درایورها به نظر در افزایش میزان قابل‌اطمینان بودن آن‌ها نقش مثبت دارد. سازندگانی که با هر دو مقوله آشنا هستند، ادعا می‌کنند که DirectX12 در وضعیت بسیار بهتری نسبت به DirectX11 در شرایط زمانی مشابه قرار دارد و یعنی وضعیت DirectX12 از وضعیت DirectX11 در زمان عرضه خود بسیار بهتر است و این مورد باوجود تغییرات عظیم‌تری که توسط API تحمیل شده، به وقوع پیوسته است.

کدهای بازی و API بخش هایی هستند که سازندگان می توانند آن ها را اشکال زدایی کنند

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

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

اکوسیستم مدرن ساخت و توسعه بازی

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

برخلاف دهه ۹۰ و ۲۰۰۰ میلادی، این روزها خیلی به‌ندرت می‌شود بازی را پیدا کرد که صرفاً با یک موتور بازی‌سازی که بر روی یکی از API های مشخص بنا شده است، ساخته شده باشد. بسیاری از ناشران، موتورهای بازی‌سازی مخصوص خود را داشته و تیم‌هایی به‌طور کامل مسئول به‌روز نگه‌داشتن تکنولوژی آن‌ها هستند و حتی سازندگان مستقل نیز تعداد زیادی موتور باکیفیت دارند که به‌طور حرفه‌ای از آن‌ها نگه‌داری می‌شود و می‌توانند یکی از آن‌ها را انتخاب کنند. بسیاری از پیچیدگی‌های API های سطح پایین توسط سازندگان میان‌افزارها –که منابع و تخصص کافی برای برخورد با این چالش‌ها را دارند- برطرف می‌شود و نیازی به دخالت سازندگان بازی‌ها نیست.

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

در ضمن، این موضوع که برای یک API، لازم نیست که صحیح بودن “چیزی را که از او درخواست شده انجام دهد و می‌تواند درزمینه‌ی عملکرد و پرفرمنس مشکل‌ساز باشد”، چک کند، بدین معنی نیست که API اجازه انجام این کار را ندارد. همه‌ی API های سطح پایین، لایه‌های اعتبارسنجی (Validation Layer) اختیاری را در دسترس سازندگان قرار می‌دهند تا مسئولیت‌های افزایش یافته سازندگان را کاهش دهند.

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

API های سطح پایین چگونه کار می‌کنند؟

به‌وضوح، دلایل سخت‌افزاری و نرم‌افزاری زیادی وجود دارند که ما از جنبه سطح پایین با طراحی API های گرافیکی برخورد کنیم و اکوسیستم کنونی موتورهای گرافیکی نیز این اجازه را به ما می‌دهد؛ اما دقیقاً “سطح پایین ” شامل چه چیزهایی است؟ DirectX12 تغییرات زیادی را در دورنمای API ها ایجاد می‌کند و بازدهی اصلی‌ای که می‌توانیم انتظار بدست آوردنش را داشته باشیم از سه مقوله‌ی زیر حاصل می‌شود:

• سیستم ساخت کار و ارائه و تسلیم آن (Work Creation and Submission)
• مدیریت حالت خط لوله (Pipeline State Management)
• ناهم‌زمانی در مدیریت منابع و حافظه (Asynchronicity in Memory and Resource Management)

همه‌ی این تغییرات به‌طور گسترده به یکدیگر مرتبط هستند و برای کاهش هزینه‌های کلی، با یکدیگر کار می‌کنند ولی ما اینجا برای وضوح بیش‌تر، هر یک را به‌طور جداگانه بررسی می‌کنیم.

سیستم ساخت کار و ارائه و تسلیم آن (Work Creation and Submission)

هدف اصلی یک API گرافیکی این است که برنامه با استفاده از آن، یک سری از سازوکارهایی را فراهم کند که GPU بتواند از آن‌ها استفاده کند و آن‌ها را پیگیری نماید که به این مورد معمولاً یک لیست فرمان (Command List) می‌گویند. در API های سطح بالا، پردازش‌های این مورد خلاصه‌تر است درحالی‌که API ای مانند DirectX12 این پردازش‌ها به‌صورت مستقیم‌تر انجام می‌شود. تصویر زیر مقایسه‌ای است میان نحوه برخورد یک API سطح بالای “کلاسیک ” یعنی DirectX9، با سیستم امکان‌پذیر ساختن موازی‌سازی در DirectX11 و درنهایت پردازش مستقیم در DirectX12.

مقایسه میان D3D9 و D3D11 و D3D12

در روزهای خوب قدیمی افزایش داخلی فرکانس پردازنده‌ها، چیزی که Direct3D9 ارائه می‌کرد به‌اندازه کافی خوب بود. برنامه از “یک ” متن و Context برای ثبت فرمان فراخوانی دستور رسم (Draw) استفاده می‌کرد و API آن را چک کرده و به درایور می‌فرستاد که درنتیجه یک لیست فرمان برای GPU ساخته می‌شود تا آن را اجرا کند. همه‌ی این‌ها یک پروسه پیوسته هستند. بعدازاین در عصر چیپ های چندهسته‌ای، اقداماتی برای موازی‌سازی فرمان‌ها انجام شد. این مورد در ایده متن‌های معوقه (Deffered Context) که در Direct3D11 استفاده شد، نمود پیدا کرد. این قابلیت به بازی‌ها اجازه می‌دهد که فرمان‌های رسم را به‌طور مستقل در رشته‌های مختلف ثبت کنند. بااین‌حال، همه‌ی آن‌ها درنهایت باید از یک متن آنی (Immediate Context) عبور می‌کردند و درایور زمانی می‌توانست لیست فرمان را بسازد که این عبور نهایی انجام می‌شد. بدین ترتیب شیوه برخورد Direct3D11 درجاتی از موازی‌سازی را امکان‌پذیر می‌کند ولی همچنان باعث ایجاد وزن و فشار سنگینی در رشته‌ای که بخش آخر پروسه را اجرا می‌کند، می‌شود و یک نابرابری ایجاد می‌کند.

Direct3D12 این مشکل را برطرف می‌کند. کدهای بازی می‌توانند به‌صورت موازی تعداد دلخواهی از لیست‌های فرمان را ایجاد کنند. همچنین Direct3D12 زمان ثبت شدن این دستورات به GPU را هم کنترل می‌کند؛ دستوراتی که حالا با هزینه نهایی کمتری اجرا می‌شوند زیرا به فرمتی نزدیک هستند که سخت‌افزار می‌تواند مستقیماً از آن استفاده کند. این موضوع باعث می‌شود که مسئولیت بیش‌تری به دوش کدهای بازی بیفتد؛ مثلاً باید اطمینان حاصل شود که همه‌ی منابعی که در یک لیست فرمان استفاده شده‌اند در کل زمان اجرا در دسترس باقی می‌مانند، البته این موضوع در عوض باعث می‌شود که درزمینه‌ی وزن و فشار کاری بخش‌های موازی، تعادل بیش‌تری برقرار باشد.

مدیریت حالت خط لوله (Pipeline State Management)

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

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

تصویر بالا که خیلی ساده‌سازی شده است، مشکل پایه‌ای را به تصویر می‌کشد. ترسیم‌ها و توصیفات حالت سطح بالای (High Level State Descriptions) زیادی می‌تواند وجود داشته باشد و در شروع هر فرمان رسم، هر زیرمجموعه‌ای از آن‌ها می‌تواند فعال باشد. درایور باید عملاً قبل از شروع به اجرای فرمان رسم، نمایش سخت‌افزاری ترکیب‌های این حالات را بسازد و شاید حتی اعتبار آن‌ها را هم چک کند. شاید ذخیره کردن اطلاعات (Caching) بتواند این مشکل را کم بکند ولی این کار به معنی منتقل کردن پیچیدگی به درایور است که ریسک به وجود آمدن رفتارهای غیرمنتظره که اشکال‌زدایی آن‌ها سخت است می‌شود که قبلاً در مورد آن و تقریباً غیرممکن بودن اشکال‌زدایی مشکلی که از درایور ناشی می‌شود صحبت شد.

در DirectX12، اطلاعات این حالت‌ها در عوض در چیزهایی به نام اشیا حالت خط لوله (Pipeline State Objects) جمع‌آوری می‌شود. این موارد بعد از ایجاد شدن غیرقابل تغییر هستند و ازاین‌رو به درایور این امکان را می‌دهد که تنها یک‌بار وقتی این اشیا به وجود آمدند، آن‌ها را چک کرده و نمایش سخت‌افزاری‌شان را بسازد. استفاده کردن از آن‌ها بعدازاین کار، تنها یک مسئله ساده نظیر کپی کردن توصیفات و اطلاعات مربوط به آن‌ها مستقیماً به مکان درستی در حافظه سخت‌افزار است و بعدازآن امکان رسم کردن آن‌ها وجود دارد.

ناهم‌زمانی در مدیریت منابع و حافظه (Asynchronicity in Memory and Resource Management)

Direct3D12، به سازندگان این اجازه را می‌دهد –و درواقع آنان را مجبور می‌کند- که به‌طور دستی همه‌ی منابعی را که توسط بازی آنان استفاده می‌شود به‌صورت مستقیم‌تر مدیریت کنند. درحالی‌که API های سطح بالا معمولاً نمای راحت‌تری را در مورد منابعی مانند بافت‌ها ارائه می‌دهند و ممکن است بعضی چیزها را مانند تصویر GPU از لیست فرمان‌ها و بعضی از موارد ذخیره شده در مورد حالت‌ها را به‌طور کامل از سازندگان مخفی کنند، در Direct3D12 تمامی این‌ها می‌توانند و باید توسط سازندگان مدیریت شوند.

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

ناهم زمانی میان CPU و GPU

عکس بالا برای این است که به شما نشان بدهد این امر چگونه می‌تواند باعث به هدر رفتن چشمگیر منابع و پرفرمنس و عملکرد بشود. این تصویر یک مثال ساده از وقوع چنین آسیب‌هایی را نشان می‌دهد. در سمت CPU: فرمان رسم X باعث می‌شود که از دو منبع A و B استفاده شود و سپس B ویرایش شود. بااین‌حال، با توجه به طبیعت ناهم‌زمان و ناهماهنگ CPU و GPU، واحد GPU می‌تواند اجرای عملی فرمان رسم را وقتی آغاز کند که کدهای بازی توسط CPU اجرا شده‌اند و منبع B ویرایش شده است. در چنین شرایطی، درایورها در API های سطح بالا در بدترین شرایط ممکن است مجبور شوند که در فراخوانی اولیه رسم، کپی‌های سایه‌ای کاملی از منابع مورد استفاده ایجاد کنند. در Direct3D12، سازندگان بازی وظیفه دارند که از روی ندادن چنین حالاتی اطمینان حاصل نمایند.

جمع‌بندی

با جمع‌کردن همه‌ی این موارد با یکدیگر، تغییرات ذکر شده می‌تواند باعث به وجود آمدن API ای بشود که این پتانسیل را دارد تا در اجرای بازی‌هایی که به شکل بهتر و مهم‌تر از آن، با ثبات بیش‌تری اجرا می‌شوند، کمک کند.

کنترل در سطح برنامه (Application-level) و سرهم‌بندی لیست‌های فرمان اجازه توزیع کار موازی متعادل‌تری را می‌دهد و درنتیجه باعث بهره‌برداری بهتری از CPU های چندهسته‌ای می‌شود. مدیریت حالت خط لوله به شکلی که بهتر نیازهای سخت‌افزاری را منعکس می‌کند، باعث می‌شود که فشار کلی روی CPU کاهش یابد و باعث توان عملکردی بالاتری برای رسم موارد بیش‌تری بشود. مدیریت دستی منابع، باوجود پیچیدگی‌اش، به سازندگان بازی‌ها اجازه می‌دهد که کاملاً حرکت داده‌ها را در بازی‌شان درک کنند. این دید داخلی کار آن‌ها را برای ساخت یک تجربه باثبات و شاید درنهایت حذف کامل کندی‌ها و Stutter های مربوط به لودینگ و Streaming آسان می‌کند.

این موارد چه تأثیری برای بازیبازها دارد؟

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

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

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

بازی Ashes of Singularity یک عنوان استراتژی هم زمان است که قرار است از یک API سطح پایین یعنی DirectX12 استفاده کند.

بازی‌های جهان باز (Open World) پر جزییات و بسیار قابل تعامل یا عناوین استراتژی که در مقیاس بزرگ هستند و بخش‌های متحرک زیادی دارند معمولاً دچار محدودیت‌های CPU حداقل در بعضی از سناریوها حتی در کامپیوترهای High-end هستند و ازاین‌رو DirectX12 به بهبود آن‌ها کمک بیش‌تری خواهد کرد.

• بازی در نرخ فریم‌های بالا روزبه‌روز محبوب‌تر می‌شود و در بعضی موارد حتی اگر شما قدرت لازم برای GPU و مانیتوری با تکنولوژی مناسب برای اجرا در ۱۴۴ فریم بر ثانیه را داشته باشید، در بسیاری از بازی‌ها قبل از همه‌ی این‌ها دچار محدودیت‌های CPU خواهید شد و در این موارد DirectX12 باعث بهبود خواهد شد.
• یکی از موارد جالب که معمولاً نادیده گرفته می‌شود، در مورد Emulator ها است؛ به‌خصوص در پروژه‌هایی نظیر Xenia (شبیه‌ساز کنسول Xbox360) که به دنبال شبیه‌سازی سیستم‌های جدیدتر هستند، باید از دسترسی سطح پایین نفع بسیاری ببرند زیرا به آن‌ها اجازه می‌دهد که مستقیم‌تر رفتار سخت‌افزار موردنظر را مدل‌سازی کنند.
• شبیه مورد قبلی، این موارد در مورد تلاش‌هایی که برای پورت عناوین از روی کنسول به PC انجام می‌گیرد نیز مؤثر خواهد بود؛ زیرا PC درزمینه‌ی خلاصه بودن API به پلتفرم اصلی آن‌ها نزدیک‌تر خواهد بود.
• درنهایت، رندر کردن برای موارد واقعیت مجازی که نیاز به تأخیر فریم بسیار دقیق و سخت و غیرقابل تغییری داشته و علاوه بر آن نیازمند پایداری و ثبات هستند، توسط یک API سطح پایین بهتر انجام خواهد شد.

علاوه بر این موارد که می‌توانیم انتظار یک برتری کلی در عملکرد را داشته باشیم، تقریباً در همه‌ی بازی‌ها ثبات عملکرد بهبود خواهد یافت. آقای Dan Baker از استودیو Oxide Games در صحبت با نویسنده سایت PC Gamer گفته است:

“ما همچنین برتری‌های بزرگی در ثبات فریم را می‌بینیم، [یعنی] نقطه‌ای که ما باور داریم ممکن است در آن در Direct3D12 “هرگز گیر نکنیم ” [و این در صورتی به وقوع می‌پیوندد که] ما به‌اندازه کافی و مناسب در کار با API مهارت پیدا کنیم.”

مخصوصاً باوجود مشکلات کندی و Stuttering که بسیاری از بازی‌های بزرگ اخیر را از بین برده‌اند، می‌توانیم برتری‌های DirectX12 و این ثبات فریم را یک چشم‌انداز بسیار هیجان‌انگیز در نظر بگیریم.

نتیجه‌گیری نهایی:

با DirectX12، دسترسی سطح پایین به گرافیک به‌صورت مجزا از سخت‌افزار به حقیقت مبدل گشته است و البته مدت زیادی طول نخواهد کشید که Vulkan (یک API گرافیکی دیگر متعلق به شرکت Khronos) نیز به جمع این API ها اضافه بشود، هرچند که این API مستقیماً با پلتفرم‌های مایکروسافت کاری ندارد. باوجود مجموعه تغییرات چشمگیری که در نحوه تعامل برنامه‌ها با سخت‌افزارهای مربوط به پردازش ۳ بعدی صورت گرفته است، این API ها فرصت ساخت بازی‌هایی که با درجات بالای موازی‌سازی هماهنگ هستند و از پایداری بالاتری برخوردارند را به سازندگان می‌دهد. کاهش اندازه API و مسئولیت‌های درایور باید باعث بشود تا دیگر شاهد عناوینی AAA ای نباشیم که در روز اول برای آن‌ها درایوری برای هماهنگ‌سازی آن‌ها و افزایش پرفرمنسشان منتشر می‌شود. این مورد علاوه بر این باعث می‌شود که PC در کل به یک پلتفرم مطمئن و همه کاره برای بازی و گیمینگ تبدیل بشود. در صدر همه‌ی این ویژگی‌ها، بزرگ‌ترین ویژگی این است که این برتری‌ها مستقل از قابلیت‌های جدید سخت‌افزاری هستند و امکان استفاده از آن‌ها با بیش‌تر GPU هایی که از DirectX11 پشتیبانی می‌کنند، فراهم است.

آیا این بدین معنی است که شما باید فوراً همه‌ی کارها را رها کنید و مشغول آپدیت به ویندوز ۱۰ شده و انتظار پیشرفت‌های بزرگ را درزمینه‌ی بازی داشته باشید؟ خیر. اولین بازی‌هایی که از DirectX12 پشتیبانی بکنند احتمالاً در تعطیلات میلادی عرضه خواهند شد و به‌احتمال‌زیاد اکثر آن‌ها از API های سطح بالا نیز پشتیبانی خواهند کرد.

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

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

DirectX12