سربار فراخوانی ترسیم: سنجش هزینه پردازنده در دایرکت‌ایکس ۱۲، ولکان و متال در برابر دایرکت‌ایکس ۱۱

گذر از پردازنده‌های تک‌هسته‌ای به معماری چندهسته‌ای، نحوه اجرای نرم‌افزارها را از اساس دگرگون کرد، اما یک گلوگاه عظیم را دست‌نخورده باقی گذاشت: گفتگوی بین پردازنده مرکزی (CPU) و کارت گرافیک. در دایرکت‌ایکس ۱۱ و اوپن‌جی‌ال، این گفتگو باید در یک صف تک‌نفره انجام می‌شد. مهم نبود پردازنده چند هسته دارد، تنها یک هسته می‌توانست به طور مؤثر فراخوانی‌های ترسیم (Draw Calls) — دستوراتی که به پردازنده گرافیکی (GPU) می‌گویند چه چیزی را رندر کند — را ارسال کند و این امر سقف سختی برای پیچیدگی بصری ایجاد می‌کرد. معرفی دایرکت‌ایکس ۱۲، ولکان و متالِ اپل، این صف را در هم شکست.[3]

تمام خطرات و چالش‌های توسعه بازی‌های مدرن بر سر همین گلوگاه است. فراخوانی ترسیم فقط یک دستور ساده برای کشیدن یک چندضلعی نیست؛ بلکه بسته پیچیده‌ای از تغییرات وضعیت، اتصالات شیدر و اشاره‌گرهای حافظه است. وقتی یک موتور بازی می‌خواهد یک جنگل انبوه را رندر کند، ممکن است نیاز داشته باشد ده‌ها هزار از این فراخوانی‌ها را در هر فریم صادر کند. اگر پردازنده نتواند آن‌ها را با سرعت کافی ارسال کند، کارت گرافیک بیکار می‌ماند و منتظر دستورات می‌شود. به همین دلیل است که سیستمی با یک کارت گرافیک رده‌بالا همچنان ممکن است در یک محیط شلوغ شهری روی ۴۵ فریم بر ثانیه لگ بزند.[1]

برای درک این هزینه، باید به معماری دایرکت‌ایکس ۱۱ نگاهی بیندازیم. دایرکت‌ایکس ۱۱ برای رندرینگ به یک «بستر فوری» (Immediate Context) متکی است. این یعنی در حالی که یک بازی ممکن است فیزیک خود را روی هسته دوم و صدای خود را روی هسته سوم اجرا کند، تمام دستورات گرافیکی باید به یک رشته پردازشی اصلی بازگردانده شوند تا توسط درایور گرافیک ترجمه شوند. درایور به عنوان یک لایه محافظ و سنگین عمل می‌کند که دائماً در حال بررسی خطاها و مدیریت در لحظه حافظه است.

دیوار عملکردی که این ساختار ایجاد می‌کند، مطلق و غیرقابل نفوذ است. در مارس ۲۰۱۵، رسانه PC Perspective دقیقاً همین محدودیت را با استفاده از تست ویژگی سربار رابط برنامه‌نویسی 3DMark آزمایش کرد. با اجرای این تست روی سخت‌افزار رده‌بالای آن زمان، رابط برنامه‌نویسی دایرکت‌ایکس ۱۱ در حدود ۱.۵ میلیون فراخوانی ترسیم در ثانیه به یک سقف سخت برخورد کرد. رشته پردازشی اصلی پردازنده کاملاً اشباع شده و روی استفاده ۱۰۰ درصدی قفل شده بود، در حالی که بقیه هسته‌ها عمدتاً بیکار بودند و کارت گرافیک منتظر کار مانده بود.[1]

تغییر همان سخت‌افزار به پیاده‌سازی اولیه دایرکت‌ایکس ۱۲، جهشی خیره‌کننده در اعداد ایجاد کرد. توان عملیاتی فراخوانی ترسیم به بیش از ۱۵ میلیون فراخوانی در ثانیه پرواز کرد. بار کاری به طور مساوی در تمام هسته‌های در دسترس پردازنده توزیع شد و به سیستم اجازه داد تا در همان بازه زمانی، ده برابر هندسه و تغییرات وضعیت بیشتری را به کارت گرافیک تزریق کند.[1]

این مقیاس‌پذیری ۱۰ برابری، وعده تعیین‌کننده رابط‌های سطح پایینی مانند دایرکت‌ایکس ۱۲، ولکان و متال است. آن‌ها با جایگزین کردن بستر فوریِ منفرد با لیست‌های فرمان چندرشته‌ای به این مهم دست می‌یابند. هر هسته پردازنده می‌تواند به طور همزمان دستورات گرافیکی را در بافر اختصاصی خود ثبت کند. وقتی فریم آماده شد، این بافرها در یک دسته عظیم به کارت گرافیک ارسال می‌شوند.[3]

با این حال، این توان عملیاتی خام با هزینه مهندسی گزافی به دست می‌آید. همان‌طور که گروه کرونوس (Khronos Group) در مقایسه معماری بین ولکان و اوپن‌جی‌ال ای‌اس (OpenGL ES) بیان می‌کند، ماهیت صریح ولکان لایه محافظ درایور را به کلی حذف می‌کند. مستندات اشاره می‌کنند که «ولکان یک رابط برنامه‌نویسی صریح است»، به این معنی که اکنون توسعه‌دهنده مسئول تخصیص حافظه، همگام‌سازی و اعتبارسنجی وضعیت است؛ وظایفی که درایور دایرکت‌ایکس ۱۱ قبلاً به طور خودکار انجام می‌داد.[3]

این تغییر مسئولیت همان چیزی است که وبلاگ Scali's OpenBlog در آگوست ۲۰۱۶ روی آن دست گذاشت و در برابر این هیاهو که رابط‌های سطح پایین یک دکمه جادویی برای افزایش عملکرد هستند، ایستادگی کرد. این وبلاگ استدلال کرد که دایرکت‌ایکس ۱۲ و ولکان ذاتاً سریع‌تر نیستند؛ آن‌ها فقط سربار کمتری دارند. اگر یک بازی محدود به پردازنده گرافیکی (GPU-bound) باشد — یعنی کارت گرافیک از قبل با ظرفیت ۱۰۰ درصد در حال رندر پیکسل‌های پیچیده باشد — تغییر به دایرکت‌ایکس ۱۲ حتی یک رقم هم نرخ فریم را افزایش نخواهد داد.

واقعیت برنامه‌نویسی گرافیکی مدرن این است که سربار درایور از بین نرفته، بلکه فقط جابه‌جا شده است. مقایسه آلن گالوان (Alain Galvan) از رابط‌های گرافیکی مدرن نشان می‌دهد که ولکان، دایرکت‌ایکس ۱۲ و متال همگی در این فلسفه بنیادین مشترک هستند: آن‌ها فلز لخت (Bare Metal) معماری پردازنده گرافیکی را در اختیار برنامه‌نویس قرار می‌دهند. این امر بهینه‌سازی‌های شگفت‌انگیزی را ممکن می‌سازد، اما در عین حال خطر نشت فاجعه‌بار حافظه و باگ‌های همگام‌سازی را در صورت اشتباه توسعه‌دهنده موتور به همراه دارد.

رویکرد اپل با متال، کاربرد عملی این فلسفه را به تصویر می‌کشد. در طول کنفرانس جهانی توسعه‌دهندگان در سال ۲۰۱۸، مهندسان اپل جزئیات بهینه‌سازی عملکرد بازی در متال را شرح دادند و نشان دادند که چگونه حرکت به سمت تولید صریح بافر فرمان می‌تواند زمان فریم پردازنده را در سناریوهایی که به شدت محدود به پردازنده (CPU-bound) هستند، به طور چشمگیری کاهش دهد. متال با پیش‌کامپایل کردن اشیاء وضعیت پایپ‌لاین (PSOs)، از نیاز درایور به کامپایل مجدد شیدرها در لحظه و در طول گیم‌پلی جلوگیری می‌کند.[4]

با این حال، کامپایل این PSOها مشکل جدیدی را به وجود می‌آورد: لگ ناشی از کامپایل شیدر. از آنجا که دایرکت‌ایکس ۱۲ و ولکان نیاز دارند وضعیت دقیق پایپ‌لاین گرافیکی از پیش مشخص باشد، بازی‌ها باید این شیدرها را یا در طول یک صفحه بارگذاری طولانی یا به صورت پویا در حین گیم‌پلی کامپایل کنند. وقتی یک بازی گزینه دوم را انتخاب می‌کند، پردازنده دقیقاً در لحظه ظهور یک جلوه بصری جدید برای کامپایل شیدر به شدت درگیر می‌شود و باعث می‌شود بازی برای کسری از ثانیه فریز شود.[3][5]

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

ابتکار GPUOpen از ای‌ام‌دی سال‌ها تلاش کرده تا به توسعه‌دهندگان کمک کند از این میدان مین عبور کنند. در راهنمای سال ۲۰۱۸ آن‌ها برای کاهش سربار فراخوانی رابط ولکان، مهندسان ای‌ام‌دی تأکید کردند که صرفاً چندرشته‌ای کردن بافرهای فرمان کافی نیست. توسعه‌دهندگان باید فعالانه فراخوانی‌های ترسیم خود را دسته‌بندی کرده و تغییرات وضعیت را به حداقل برسانند، درست مانند کاری که در دایرکت‌ایکس ۱۱ می‌کردند، زیرا حتی در ولکان نیز ارسال یک بافر فرمان به صف پردازنده گرافیکی، هزینه پردازشی غیرصفری برای پردازنده مرکزی به همراه دارد.[2]

نرمال‌سازی متقاطع ما از این رفتار مقیاس‌پذیری در رابط‌های مختلف، یک منحنی متمایز را نشان می‌دهد. در حالی که حرکت از یک رشته به چهار رشته، مقیاس‌پذیری تقریباً خطی در توان عملیاتی فراخوانی ترسیم به همراه دارد، بازدهی پس از شش تا هشت رشته به شدت افت می‌کند. فراتر از این نقطه، سربار همگام‌سازی بافرهای فرمان و مدیریت تخصیص‌دهنده‌های حافظه در میان این تعداد هسته، شروع به غلبه بر مزایای ثبت موازی می‌کند.[5]

این افت بازدهی توضیح می‌دهد که چرا پردازنده‌های دسکتاپ رده‌بالای ۱۶ و ۲۴ هسته‌ای، در بارهای کاری گیمینگ، برتری ۲ یا ۳ برابری در نرخ فریم نسبت به یک پردازنده ۸ هسته‌ای ارائه نمی‌دهند. رابط گرافیکی تنها تا حد مشخصی می‌تواند کار را توزیع کند، پیش از آنکه تدارکات هماهنگ‌سازی رشته‌ها به گلوگاه جدید تبدیل شود.[5]

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

برای این تیم‌های کوچک‌تر، رابط‌های سطح بالا یا موتورهای تجاری به شدت انتزاعی همچنان عملی‌ترین مسیر باقی می‌مانند. اعداد خام فراخوانی ترسیم از بنچمارک‌های مصنوعی مانند 3DMark مست‌کننده هستند، اما آن‌ها نشان‌دهنده یک حداکثر نظری در خلأ هستند؛ خالی از هوش مصنوعی، فیزیک و منطق بازی که در یک اپلیکیشن واقعی برای همان چرخه‌های پردازنده رقابت می‌کنند.[1][5]

گذر از دایرکت‌ایکس ۱۱ به عصر مدرن رابط‌های صریح، با موفقیت محدودیت فراخوانی ترسیم تک‌رشته‌ای را از بین برد. اما با این کار ثابت کرد که در علوم کامپیوتر، سربار به ندرت نابود می‌شود؛ بلکه فقط به بخش دیگری از سیستم منتقل می‌گردد.[5]