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

تبلیغات ۷۲۰ در ۹۰

1080p با دایرکت ایکس 11

بنچ‌مارک Ashes، دایرکت ایکس 11 و مقایسه‌ی R9 Fury X و GTX 980 Ti

بنچ‌مارک Ashes، دایرکت ایکس 11 و مقایسه‌ی R9 Fury X و GTX 980 Ti

4K با دایرکت ایکس11

بنچ‌مارک Ashes، دایرکت ایکس 11 و مقایسه‌ی R9 Fury X و GTX 980 Ti

بنچ‌مارک Ashes، دایرکت ایکس 11 و مقایسه‌ی R9 Fury X و GTX 980 Ti

1080p با دایرکت ایکس 12

بنچ‌مارک Ashes، دایرکت ایکس 12 و مقایسه‌ی R9 Fury X و GTX 980 Ti

بنچ‌مارک Ashes، دایرکت ایکس 12 و مقایسه‌ی R9 Fury X و GTX 980 Ti

4K با دایرکت ایکس 12

بنچ‌مارک Ashes، دایرکت ایکس 12 و مقایسه‌ی R9 Fury X و GTX 980 Ti

بنچ‌مارک Ashes، دایرکت ایکس 12 و مقایسه‌ی R9 Fury X و GTX 980 Ti

همان‌طور که قبلاً در مقاله‌ای مطرح کردم، شاید ضعف کارت گرافیک قدرتمند انویدیا نبودن ACE باشد.

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

انویدیا و بهانه‌های عجیب

انویدیا به بازی Ashes of the Singularity توجه نشان نداده و مدعی است که این بازی عملکرد کلی دایرکت ایکس 12 را آشکار نمی‌کند. انویدیا آنتی-الیاسینگ با الگوریتم MSAA در این بازی را ضعیف و پر از باگ گزارش کرده و معتقد است که باید آن را غیرفعال کرد.

آکسید گیمز ادعای انویدیا را رد کرده و معتقد است MSAA در این بازی مشکل خاصی ندارد. کدهای بازی توسط مایکروسافت، انویدیا و AMD بررسی شده و مایکروسافت مهر تأیید بر آن زده است. MSAA در دایرکت ایکس 11 و 12 از مسیر یکسانی دنبال می‌‎شود. بنابراین ادعای انویدیا قویاً رد می‌شود.

گزارش باگ و بهانه‌جویی به جای پذیرفتن تفاوت معماری تراشه‌ها!

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

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

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

و بخشی دیگر از حقایق و اصرار انویدیا برای اضافه کردن کدهای خاص

و اطلاعات جدیدی که توسط یکی از کارمندان آکسید گیم به دست آمده:

انویدیا درخواست حذف برخی تنظیمات بنچ‌مارک را کرده بود و زمانی که آکسید گیمز این درخواست را رد کرد، متهم به برخورد شخصی با انویدیا شد! ترافیک ایمیل‌های رد و بدل شده بین آکسید گیمز و انویدیا بیش از AMD است و این موضوع نشان می‌دهد که انویدیا با این کمپانی هم مثل دیگر کمپانی‌های ساخت بازی و بنچ‌مارک، همکاری نزدیکی داشته است و در حقیقت اگر بهینه‌سازی خاصی صورت گرفته باشد، برای محصولات انویدیاست و نه AMD!

تنها کدی که ویژه‌ی یکی از سازندگان کارت گرافیک به بنچ‌مارک Ashes of the Singularity اضافه شده، مربوط به انویدیاست و چیزی نیست جز مقوله‌ی بحث‌برانگیز محاسبه‌ی آسنکرون یا غیر‌هم‌زمان. فعال کردن این قابلیت ویژه که موجب افزایش سرعت رندر می‌شود، مفید است ولیکن در مورد محصولات انویدیا اثر بسیار بدی روی عملکرد می‌گذارد!

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

دایرکت ایکس 12 و برتری GCN ای‌ام‌دی به کمک ACE زیر ذره‌بین

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

مشکلات روش مالتی ترد در دایرکت ایکس 11

قبل از هر چیز بهتر است به مفهوم شیدر اشاره کنم:

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

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

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

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

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

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

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

پیش‌خالی‌سازی و اولویت‌بندی دستورات صفوف دستور
روش جدید مدیریت صفوف و دستورات در دایرکت ایکس 12
مشکلات موردبحث در دایرکت ایکس 12 با استفاده از روش ترکیب دستور جدید به اسم شیدرهای آسنکرون حل می‌شود. در معماری GCN ای‌ام‌دی موتور محاسباتی آسنکرون (غیرهم‌زمان) می‌توان دستورات را جاسازی کند، فضای خالی در یک صف با دستورات صفوف دیگر پر می‌شود، فرآیندی شبیه ترکیب ترافیک دو جاده. برتری دیگر ACE یا همان موتور محاسباتی آسنکرون در این است که صف در حال اجرا را در زمان لازم، تغییر می‌دهد. مثلاً اگر صفی شامل دستورات مهم فرا برسد، سریعاً آن را به صف اصلی که در حال اجراست، تبدیل می‌کند. روشن است که این روش موجب افزایش کارایی می‌شود.

معماری GCN در اغلب کارت گرافیک‌های سری 7000 (به جز تغییر نام یافته‌های سری قبل) و نسل‌هدی بعدی استفاده شده است. هر یک از ACEها می‌توان 8 صف دستور را با شیدرهای مربوط به خود مدیریت کند. ساده‌ترین پردازنده‌های گرافیکی دارای 2 موتور محاسباتی آسنکرون هستند و پردازنده‌های گرافیکی سریع‌تر، 8 موتور را در خود جای داده‌اند.

موتور محاسباتی غیرهم‌زمان کلید حل مشکلات صفوف دستور
از تئوری تا عمل، نتیجه‌ی استفاده از ACE چیست؟
ای‌ام‌دی برای نمایش عملکرد روش جدیدی که در دایرکت ایکس 12 قابل استفاده است، از بسته‌ی توسعه‌ی نرم‌افزاری LiquidVR استفاده کرده است. رندری که با سرعت 245 فریم بر ثانیه اجرا می‌شود، البته بدون شیدرهای غیرهم‌زمان و پس‌پردازش. با اضافه کردن پس‌پردازش سرعت اجرا به 158 فریم بر ثانیه افت می‌کند. اگر شیدرهای غیرهم‌زمان فعال شوند، فریم‌ریت مجدداً افزایش پیدا می‌کند و به 230 فریم بر ثانیه می‌رسد. تقریباً نزدیک به عدد اول. بنابراین در بهترین حالت می‌توان به افزایش سرعت اجرا در حد 50 درصد امیدوار بود.

ممکن است سرعت اجرا بسیار بالا باشد اما در لحظاتی دوربین جا بماند! تجربه‌ی خوشایندی نیست.

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

پشتیبانی کامل از دایرکت ایکس 12 فریبی ظاهری!

دقت کنید که وجود موتور محاسباتی غیرهم‌زمان در حال حاضر جزء هیچ یک از سطح قابلیت‌های دایرکت ایکس 12 نیست! لذا محصولات AMD با پشتیبانی نکردن از سطح قابلیت‌های FL 12_1 ضعیف‌تر و قدیمی‌تر از مکسول انویدیا به نظر می‌رسند اما اگر از ACE به درستی استفاده شود، وضعیت دگرگون می‌شود، همان‌طور که در بنچ‌مارک Ashes شاهد بودیم.

در بنچ‌مارک Ashes تخمین فعلی این است که حدود 20 درصد فرآیند پردازشی به کمک شیدرهای محاسباتی صورت می‌گیرد و قرار است در نسخه‌ یا نسخه‌های بعدی، این رقم به بیش از 50 درصد برسد و حتی ممکن است تا 5 سال بعد، تمام فرآیند توسط شیدرهای محاسباتی انجام شود!

در درایور کارت گرافیک‌های انویدیا، استفاده از ACE مجاز و امکان‌پذیر عنوان شده است و انویدیا اعلام کرده که کارت گرافیک‌های سری 900 با معماری مکسول 2 دارای 1 صف پردازش گرافیک و 31 صف محاسباتی هستند. در معماری GCN هشت واحد ACE وجود دارد و هر یک 8 صف محاسباتی را پردازش می‌کنند. بنابراین در کنار یک صف محاسبه‌ی گرافیک، 64 صف محاسباتی وجود دارد. متأسفانه انویدیا در مورد جزئیات پیاده‌سازی ACE صحبتی نکرده و مشخص نیست که دسترسی به آنها چگونه است و چه مقدار در عملکرد کلی تأثیر می‌گذارد.

مکسول 2 هم از ACE پشتیبانی می‌کند

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

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

اگر ACE به درستی پیاده‌سازی شده باشد، اجرای 31 دستور محاسباتی و 1 دستور گرافیکی به صورت هم‌زمان و بدون تأخیر افزایشی صورت می‌گیرد و اگر ACE در کار نباشد، اضافه کردن هر دستور جدید به صف دستور، موجب افزایش زمان اجرا خواهد شد. فرآیند ایجاد صف بزرگ دستورات، خود به صورت سریال پیاده‌سازی شده و این یکی از اشکالات بنچ‌مارک است.

در محصولات AMD و در حقیقت دو مدل رده اول R9 390X و R9 Fury X انتظار داریم که 64 دستور اول با سرعت یکسان اجرا شوند و پس از آن زمان پایان اجرای دستورات بیشتر می‌شود و پله‌ی دوم شکل می‌گیرد.

GTX 980 Ti

در مکسول 2 و در حقیقت کارت گرافیک قدرتمند GTX 980 Ti تا زمانی که تعداد دستورات کمتر از 31 باشد، زمان اجرای دستورات تقریباً ثابت است، با اضافه شدن تعداد دستورات، زمان اجرا افزایش پیدا کرده و تقریباً تا مرز 62 دستور، پله‌ی دوم را تشکیل می‌دهد. پله‌های بعدی هم نتیجه‌ی اضافه کردن واحدهای 32 تایی دستور هستند:

سرعت اجرای صف دستورات توسط GTX 980 Ti

سرعت اجرای صف دستورات توسط GTX 980 Ti

مدت زمان اجرای دستورات در پله‌ی آخر یعنی 128 دستور، حدود 60 میلی‌ثانیه است و در پله‌ی اول فقط 29 میلی‌ثانیه.

R9 390X و R9 Fury X

کارت گرافیک R9 Fury X دستورات را به صورت موازی و مستقل اجرا کرده و مدت زمان اجرای دستور اول تا دستور 128 تقریباً 50 میلی‌ثانیه و ثابت است.

کارت گرافیک R9 390X هم 128 دستور اول را در زمان 52 میلی‌ثانیه اجرا می‌کند.

افزایش مدت زمان اجرا پس از 64 دستور اول، بسیار کم است.

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