قابلیت موتورهای سخت افزاری nvidia و AMD جهت کارایی در DX 12

[hd5870 9458]

به نام خدا

درود بر تمام دوستان لیونی

بنده یک مقاله تقریبا کامل در مورد تمامی قابلتهای سخت افزاری هر دو شرکت انودیا و AMD با هزار جستجو و گشت و گذار در نت بالاخره تونستم پیدا کنم تا این قضیه کدون پردازنده دو شرکت میتونن به خوبی DX 12 رو پوشش بدن روشن بشه و هیچ شک و شبه ای برای کسی نباشه البته با این حال هم فکر نکنم تقریبا طرفداری هر دو شرکت کاملا راضی بشن چون این مقاله بیشتر نگفته های پنهان معماری سخت افزاری هر دو شرکت رو توضیح داده که تا به این لحظه هر دو شرکت اطلاعات مفیدی راجع به اینها منتشر نکردن و فقط در حد و اندازه انتشار یک عکس بوده

خوب حالا میرم سر اصل قضیه :

طبق گفته های هر دو شرکت انودیا و AMD در گفته های اخیرشون در اجرای قابلتهای DX 12 پردازنده های هر دو شرکت دارای multi engine جهت پشتیبانی از DX 12 هستند که در معماری AMD پردازنده هایی با معماری GCN 1.0 و 1.1 و 1.2 و در معماری انودیا سری کپلر و ماکسول V.1 و ماکسول V.2 و طبق برخی یافته ها معماری فرمی هم تحت پوشش چنین قابلیتی قرار گرفته اند که طبق گفته انودیا که به صراحت هم گفته مکسول V.2 بهترین پشتیبانی رو از این قابلت میبره

 

حالا میرم سر توضیحات این قابلیتها :

 

موتور و صف چیست :

در رابطهای برنامه نویس قبل از DX 12 رابطهای کلاسیک مانند OPEN GL تنها دارای صف 3D معرض بود همه دستورات ارائه شده به یک صف که توسط نقطه هماهنگ سازی محدود میشد وجود داشت دستورات در بین دو نقطه هماهنگ سازی به شکل دسته ای سفارشی بودند که در صف تعریف نشده میتوانستند برخی از همزمانی بین دستورات با توجه به راه اندازی خط لوله و معماری فوق العاده اسکالر که باید با نظم پردازش نمایند  این دستورات به صورت نردبانی در یک صف واحد برای پردازش باید منتظر میماند این عملیات نردبانی داده ها معمولا برای همزمان سازی کار بر رویه GPU با عملیات دیگر مانند ارسال دستورات از سمت CPU یا منابع انتقالی در بین داده های CPU و GPU باعث مسدود شدن این انتقالات در پردازش GPU مانند تغییر دسترسی به حافظه گرافیکی یا انتظار برای دستورات دسته ای که در صف برای پردازش میشد

 

 

شکل بالا نحوه انتظار دستورات برای پرازش رو نشون میده

 

اما در dx 12 و با پوشش او صف محاسبه اضافی جدیدی جهت استفاده در برنامه های 3d اضافه شده هر کدام از این صفهای اضافی دستورات را به طور غیر همزمان اما در کنار یکدیگر اجرا میکنند این قابلیت با نام asynchronously یا غیر همزمانی هم نامیده میشود منظور از asynchronously یا پردازش ناهمزمان اشاره به این موضوع دارد که داده ها در ارتباط با یکدیگر تعریف نشده اند کارهای محول شده به صف های مختلف ممکن است از شروع تا کامل شدن داده ها در جهت متفاوت با یکدیگر صادرشوند هنگامی که یک صف به طور مثال توسط یک حصار مسدود شده باشد صفهای دیگر ممکن است بدون توجه و در نظر گرفتن نقاط همزمانی و موانعی بر سر راه داده ها انها را پردازش کنند

این ویژگیها از قبل در open cl و cuda وجود داشتند اما هیچ یک از انها دارای صف های اضافی (که در dx 12 وجود دارند ) نیستند و پشتیبانی نمیشوند زیرا شرایط انتظار اضافی برای داده ها نیازمند یک بافر قوی برای ارسال دستورات اضافی هستند و open cl و cuda فاقد چنین شرایطی هستند

 

در تصویر فوق شاهد ارسال دستورات به صورت غیر همزمان ولی پردازش دستورات به صورت همزمان هستید

 

این صف های  اضافی با صف های 3D کلاسیک (منظور OPEN GL ) متفاوت است در صف های کلاسیک تغذیه محاسبات و کپی و رسم دستورات همگی با هم انجام میشد اما در صفهای اضافی جدید فقط میتوانند محاسبات و کپی دستورات را قبول و انها را پردازش کنند به همین دلیل انها را به نام compute queues شناسایی میکنند در سخت افزار، این صف توسط موتورهای اختصاص داده شده از نوع مربوطه گرفته شده است موتور مربوطه مسئول صف 3D است که معمولا با نام graphics command processor توسط سازندگان سخت افزار نامیده میشود ویا موتور 3D در اصطلاحات مایکروسافت یاد میشود در سخت افزار شرکت AMD از این قابلیت با نام Async Compute Engines یا به اختصار ACE نام برده شده

در موتور بازیهای مدرن امروزی کار محاسبه از اهمیت ویژه ای برخوردار شده است در موتورهای بازی قدیمی تر offload work از CPU به GPU انجام میشدند مانند پردازش فیزیک ذرات به طور یکسان که این کار موجب استفاده بصری کمتر از شیدرهای محاسبه  در رندر میشد در این روش در نسل geometry and classic draw calls ها تنها جند بافر 2D درگیر بودند ولی در نسل جدید و با موتور محاسبات جدید بسیاری از عملیات 2D با شیدرهای محاسبه به خوبی انجام میشود که این کار باعث کاهش استفاده از منابع و به دست اوردن سرعت بیشتر برای استفاده از ویژگی های خاص محاسبه میشود

 

با این حال یک صف محاسبه ممکن است سودی را در بر نداشته باشد زیرا در انتظار نگه داشتن GPU با استفاده از کار یک صف یک مسئله بدون اهمیت به شمار میرود زیرا در حالی که کارهای زمانبندی شده در صف های مختلف هنوز برای ورود در انتظار هستند ممکن است مشکلاتی را برای سخت افزار در گیر برای اجرای کار محاسبه به وجود اورد این در حالی است که فقط یک صف برای محاسبه داده ها فعال است این عملیات نمیتواند به طورمنظم در داخل یک صف رخ دهد به همین دلیل سخت افزار نیازمند پیچیده گی هایی جهت اجرای موازی دستورات است استفاده از قابلیت موازی نیازمند سخت افزار و درایور میباشد این تفاوتها در تمامی سخت افزارها با استفاده از DX 12 قابل مشاهده نیستند فقط حمایت از صف محاسبه به طور کلی نشان داده شده است. با استفاده از درایور و سیستم عاملهای مختلف سخت افزار میتواند با همان نوع از حجم کاربه انها واکنش نشان دهد این کار جزئ ویژگیهای اضافی در مورد هسته گرافیکی هستند که قدرت و انعطاف پذیری هسته گرافیکی را نشان میدهد و باعث نهایت بهره وری از ان خواهد شد

 

1 صف اضافی در نرم افزار برنامه ریزی شده. تنها محدودیت حافظه اعمال می شود.

2 موتور یکی 3D به علاوه تا 8 موتور محاسبات در حال اجرا به صورت همزمان.

3 از آنجا که GCN 1.1، هر موتور محاسبه یکپارچه می تواند دستورات را از 8 صف ناهمزمان در حین پردازش

4 محاسبه و موتور 3D می تواند در همان زمان فعال باشد عنوان استفاده از آنها یک واحد تابع تک.
رابط کاربری بیش از حد Q مورد استفاده برای CUDA در واقع حمایت از اجرای همزمان است، اما آن را سازگار با API DX12 نیست.
اگر از آن استفاده شد، می تواند یک حد سخت افزار 32 صف محاسبه ناهمزمان در علاوه بر این به موتور 3D وجود اورد

5 اسلات اجرای پویا بین تمام انواع دستور به اشتراک گذاشته.

6 اسلات اجرای دستورات محاسباتی

7 Execution slotsبرای استفاده توسط پردازنده دستور گرافیک محفوظ شده
با توجه به کارت گرافیک Nvidia، تراشه GM20x باید قادر به بلند کردن رزرو به صورت پویا باشد. این رفتار به نظر می رسد به CUDA و Hyper-Q محدود شود.

8 اسلات اجرای به صورت پویا بین هر 8 صف محاسبه از GCN 1.1 به اشتراک گذاشته.

9 واحد SMX / SMM تنها می توانید هر نوع جبهه موج را اجرا کند. L1 کامل، محلی به اشتراک گذاشته حافظه و زمانبندی خیط و پیت کردن مورد نیاز است به حالت دیگر تغییر دهید. این به احتمال زیاد به دلیل استفاده از یک حافظه سفال تنها به ارائه L1 و LSHM در حالت محاسبه.

 

بررسی معماری هر دو شرکت در استفاده از قابلیت صف های محاسباتی اضافه یا همان Compute engines :

 

AMD :

موتور محاسبات می توان برای اهداف مختلف و متعدد بر روی معماری GCN استفاده  شود کار محاسبات طولانی در حال اجرا را می تواند به یک صف محاسبه جدید واگذار کند اگر یک کار شناخته شده باشد احتمال هدر رفت زمان جهت نگه داری داده ها پایین تر است این در دست یابی به بالاترین بهره برداری از سایه زن ها به عنوان 3D و محاسبه حجم کار در هر سطح از سخت افزار و اجرای واقعی در واحد محاسبه لایه موثر است و این اولویت انجام کاررا میتوان به یک صف محاسبه اختصاصی برنامه ریزی شده واگذار کرد

تمامی این عملیات در معماری GCN به واحد ACE واگذار شده است که با استفاده از توان SHADER ها وبا استفاده مناسب از تنظیمات صف محاسبه باعث به وجود امدن شکل بهینه در انجام محاسبات پیچیده شده است این شیدرهای محاسباتی همراه با شبکه های کوچک حداقل دارای 64 رشته در هر گروه و استفاده شده در یک انجین GPU است  با استفاده از تمام 8 واحد ACE موجود در معماری GCN همراه با موتور 3D، شما می توانید به 640 شبکه های فعال در فیجی دستیابی پیدا کنید

 با ارائه کار اضافی بر روی یک موتور محاسباتی، تاثیر موانع مسدود کردن در دیگر صف ها می تواند اجتناب شود. موانع و یا نرده ها قرار داده شده در دیگر صف باعث هر گونه دخالت  نمیشوند

معماری GCN در ایده ال ترین حالت در قبول دستورات محاسباتی  در صف 3D :

در اینجا هیچ گونه وقتی برای مخلوط شدن draw calls ها و دستورات محاسبه در صف 3D وجود ندارد در واقع دستورات محاسباتی تقریبا عملکردی مشابه proxy geometry10 دارند دستورات محاسبه هنوز هم باید برای هر گونه عملیات غیر هندسه مربوط به دلایل عملی، مانند استفاده از حافظه داخلی مشترک و افزایش همزمانی ممکن ترجیح داده شود.واگذاری دستورات محاسباتی  به صف محاسبه یک فرصت خوب برای افزایش بهره برداری از GPU است

( 10 Proxy geometry یک تکنیک که در آن شما با استفاده از یک هندسه ساده، مانند یک مربع برای پر کردن صفحه نمایش، اعمال جلوه های پردازشی و به طور یکسان به بافر 2D اشاره دارد)

 

 

 

 

NVIDIA :

 

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

 چندین نقطه برای در نظر گرفتن زمانی که انجام این کار وجود دارد:

حجم کار بر روی یک صف واحد همیشه نیازمنددستورات به اندازه کافی و به طور کامل استفاده موثر از GPU است.
    هیچ محاسبه  موازی بین 3D و موتور محاسبه COMPUT ENGIN وجود ندارد، بنابراین  بایدراهی برای  تقسیم حجم کار بین تماس draw calls با موتور COMPUT به طور منظم و محاسبه دستورات خودسرانه وجود داشته باشد. مطمئنن همیشه به درستی دسته ای برای هر دو رسم تماس و دستورات محاسباتی تعبیه شده است
    توجه نزدیک احتمالی GPU با شغل محاسبه انفرادی محدود به نرخ نمونه بافت، زمان تاخیر حافظه و یا هر چیزی به طور یکسان نیست. دیگر صف می توانند به فعالیت خود تا زمانی که چنین فرمان در حال اجرا است ادامه دهند

دستورات محاسبه باید در صف 3D برنامه ریزی شود.
    انجام این کار به عملکرد هسته گرافیکی به میزان قابل لطمه خواهد زد. موتور 3D نه تنها در اجرای متوالی،بلکه پیکر بندی دوباره از واحد SMM عملکرد و حتی بیشتر را مختل  میکنند.
    استفاده از یک تماسDRAW CALL با هندسه پروکسی به جای  تخلیه دستورات  گزینه مناسبی به حساب نمی اید. این را هنوز در چند میکروثانیه ذخیره دستورات به عنوان  Interleaving در یک فرمان محاسبه به اندازه کافی به نظر نمی اید

    سوئیچینگ بین محاسبه و صف 3D نتیجه ان استفاده کامل از تمام خطوط لوله است. GPU باید زمان کافی در یک حالت  برای توجیه سوئیچینگ بین دو حالت محاسبه و 3D داشته باشد
 هیچ پیش دستی فعال، سایه زن طولانی در حال اجرا در هر دو موتور انتقال وجود نخواهد داشت

با وجود این محدودیت، استفاده از shader های محاسباتی هنوز هم باید در نظر گرفته شود. با این حال هنوز هم میتوان از قابلیت proxy geometry به طور موثر و بالاتری از همزمانی نسبت به نمونه کلاسیک سود بردکه این خود نیازمند مراقبت های اضافی و دسته های جداگانه برای خط لوله های عملیات رندرینگ است 

 محاسبه async  باید با پشتیبانی ازکارها با اولویت بالا و برنامه ریزی مستقل توسط سخت افزار صورت گیرد، مانند در نظر گرفتن استفاده از CUDA برای جایگیزینی از API DX12.

معماری GK110 و بعد از ان، CUDA وظیفه پردازندش دستورات گرافیکی است و توسط یک واحد تابع اختصاص داده شده در سخت افزار اجرا می شود که uncoupled از محاسبه و یا موتور گرافیکی به طور منظم انجام می شود. این حتی پشتیبانی از صف ناهمزمان چند IIN سخت افزار شما را به وجود می اورد
 

 

 

ادامه دارد .......

 

نکته ای هم بگم :

بنده از رویه فن بازی این مقاله رو ننوشتم اگر فکر میکنید از این بهتر میتونید ترجمه کنید لینکهای تمام مطالبی رو بهتون میدم زحمت بکشید ترجمه کنید وبزارید

 

 

دوستان بنده به خاطر این از عکسهای انتشاری AMD استفاده کردم چون از معماری انودیا عکس پیدا نکردم کسی اگر لینک عکس با توضیحات داره دریغ نکنه و به بنده ادرسش رو بده تا قرار بدهم

ویرایش شده فوریه 27, 2016 توسط hd5870

[7alireza7 188]

خوبه ممنونم لطفا ادامه بدید @};- @};- @};- @};- @};- @};- @};- @};- @};- :x

ویرایش شده فوریه 27, 2016 توسط 7alireza7

[THE-BLACK-CAPTAIN 1462]

بسیار عالی جای تشکر داره

[ZEN R780 18]

بسیار عالی خسته نباشید @};-  @};-  

[Ali_amani 353]

عالی بود مرسی موفق باشید

[ℛ𝒪𝒩ℐ𝒩 1185]

عنوان تاپیک اشتباه هست این مطالبی که ذکر کردید در مورد مبحث DX12 Multi engine هست نه کلیت DX 12، رابط مورد نظر کلی زیر شاخه داره! DX 12 دو تا مبحث به اسم Conservative rasterization و Rasterizer Ordered Views داره که معماری GCN عملا در پردازش این بخش ناتوان هست!

 

 

مطالبی که هم عنوان شده فقط در مورد پردازش Async Compute می باشد، یعنی اگر مسیر بار کاری یا Workloads توسط توسعه دهنده بازی تغییر کنه عملا مزیت پردازشی همزمان AMD یعنی باد هوا!

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

خب کار سختی نیست یه آمار بگیرید در چند سال گذشته چندتا کمپانی و استدیو با انویدیا همکاری داشتند، حتی همین Oxide هم مزه پول به دهنش رسیده در عرض یک هفته رنگ عوض کرد و گفت در حال همکاری با انویدیا هستیم.

خیلی ساده براتون بگم سرانجام این Async Compute، دقیقا مشابه Mantle خواهد شد، تنها مزیتی هم که معماری GCN این وسط داره توانایی انجام پردازش همزمان چند دستور بدون اتکا به پردازنده هست (به دلیل داشتن انجین های ACE)، برخلاف اون معماری مکسول برای پردازش همزمان این مؤلفه به قدرت پردازنده اندکی وابسته است که همانطور که گفتم اگر توسعه دهنده مسیر کد نویسی رو تغییر بده اون مزیت تبدیل میشه به ضرری اساسی!

این Workload ها می توانند مسیر آدرس دهیشون کاملا تغییر کنه و مزیت AMD به بلای جانش تبدیل بشه!

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

http://ext3h.makegames.de/DX12_Compute.html

شاد باشید @};-

ویرایش شده فوریه 27, 2016 توسط RONIN021

[ZEN R780 18]

...

ویرایش شده فوریه 27, 2016 توسط amir1378

[HeX 11135]

واقعا متاسفم این انجمن یک ناظر نداره برای تشکر کردن از فردی که وقت گذاشته این متن را نوشته هم منفی میدن هر چقدر میخواهی منفی بده عقده ای

 

درود

 

دوست من جای این قبیل بحث ها داخل تاپیک و در بین مباحث تخصصی نیست.

شما به راحتی میتونید ریپورت کنید تا رسیدگی بشه... مطمئنا با متخلف برخورد میشه.

ویرایش شده فوریه 27, 2016 توسط HeX

[satsuki 69]

مقاله خوبی بود ممنون

[ZEN R780 18]

درود شما درست میفرمایید ولی من نمیدونم کی بهم منفی داده که ریپورت کنم؟ واقعا نمیدونم چی بگم

[EVGA OC 241]

خیلی زحمت  کشیدید دوست من

[hd5870 9458]

عنوان تاپیک اشتباه هست این مطالبی که ذکر کردید در مورد مبحث DX12 Multi engine هست نه کلیت DX 12، رابط مورد نظر کلی زیر شاخه داره! DX 12 دو تا مبحث به اسم Conservative rasterization و Rasterizer Ordered Views داره که معماری GCN عملا در پردازش این بخش ناتوان هست!

 

 

مطالبی که هم عنوان شده فقط در مورد پردازش Async Compute می باشد، یعنی اگر مسیر بار کاری یا Workloads توسط توسعه دهنده بازی تغییر کنه عملا مزیت پردازشی همزمان AMD یعنی باد هوا!

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

خب کار سختی نیست یه آمار بگیرید در چند سال گذشته چندتا کمپانی و استدیو با انویدیا همکاری داشتند، حتی همین Oxide هم مزه پول به دهنش رسیده در عرض یک هفته رنگ عوض کرد و گفت در حال همکاری با انویدیا هستیم.

خیلی ساده براتون بگم سرانجام این Async Compute، دقیقا مشابه Mantle خواهد شد، تنها مزیتی هم که معماری GCN این وسط داره توانایی انجام پردازش همزمان چند دستور بدون اتکا به پردازنده هست (به دلیل داشتن انجین های ACE)، برخلاف اون معماری مکسول برای پردازش همزمان این مؤلفه به قدرت پردازنده اندکی وابسته است که همانطور که گفتم اگر توسعه دهنده مسیر کد نویسی رو تغییر بده اون مزیت تبدیل میشه به ضرری اساسی!

این Workload ها می توانند مسیر آدرس دهیشون کاملا تغییر کنه و مزیت AMD به بلای جانش تبدیل بشه!

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

http://ext3h.makegames.de/DX12_Compute.html

شاد باشید @};-

درود

دوست عزیز عنوان تاپیک اشتباه نیست برادر.. داخل مقاله هم بنده ذکر کردم مقاله مربوط به قابلتهای سخت افزاری تعبیه شده در پردازنده های گرافیکی هر دو شرکته انودیا و AMD هست نه بحث در مورد dx 12 و قابلیتها و تفاوتهاش در مورد  DX 11 

بنده خوشحال میشم اگر مایل باشید همون لینکی که گذاشتید رو به زبان ساده ترجمه بفرمایید و از اول یک مقاله کامل راجع به اون در یک تاپیک جدا بنویسید تا همه فیض ببرن

بنده هیچ ابزار ترجمه خصوصی یا حرفه ای ندارم که باهاش ترجمه کنم بیشتر ترجمه یا کلمه به کلمه بوده یا از گوگل ترنسلیت کمک گرفتم و با هزار بد بختی جمله بندی اون رو درست کردم تا به اندازه کافی قابل تفهیم باشه

[Hossein.E 323]

خیلی ممنون جناب 5870. @};- @};- @};-

امیدوارم AMD به روزهای اوجش برگرده. :x

[RAMIN VAMP 603]

خیلی ممنون جناب 5870 واقعا زحمت کشیدین @};-  @};-  @};-

[hd5870 9458]

به نام خدا

دنباله مقاله ....

روشهای امن :

روشهای امن توصیه شده برای بهترین حالت در سخت افزار انودیا :

در روش انودیا SHADER ها میتوانند دسته های بزرگ داده هارا برای پردازش انتخاب کنند اما این شیدر های طولانی پردازشی در حال اجرا در زمانبندی های متفاوت میتواند کار سخت افزار را پیچیده کند هر دو پردازنده AMD و انودیا میتوانند تا پایان کار هردسته این عملیات را به خوبی انجام دهند و با انها تطابق کامل داشته باشند استفاده از موتور محاسبات متعدد در هنگام اجرا که به صورت یک زنجیره میتواندکار محاسبه را انجام دهد این روش را برای اولین بار AMD در معماری GCN 1.0 از ان بهره برد ولی این معماری تنها میتوانست دو موتور محاسبه را به ان اختصاص دهد در حالی که انودیا شانس بیشتری برای ارسال دستورات چند رشته ای به همراه دارد انودیا قادر است تنها با به روز رسانی نرده ها و تقویت سیگنالها دستورات فرماندهی کند اما در سخت افزار AMD این کار خیلی سریعتر انجام میشود این در سخت افزار AMD با استفاده از سیگنالهای اضافی موتور محاسبه می تواند شروع به رفت و بر گشت سریعتر داده ها کند هماهنگ سازی محاسبات هم توسط همین موتورها انجام میشود اما یک جای نگرانی وجود دارد اینکه ایا  fences ها یا همون نرده ها جهت مقاصد هماهنگ سازی شده سر بار خواهد شد ؟ در اینجا انتظار برای ارسال چند سیگنال به همان اندازه انتظار برای ارسال یک سیگنال واحد است این سیگنالها به صورت محافظه کارانه ای در هر نقطه هماهنگ سازی اضافی در انتظار خواهند ماند (cost11 )

 

 

 

در نظر بگیرید که AMD نیاز به یک سطح بالاتر از همزمانی، و بسیاری از کارهای خود را که در واقع مستقل هستند داشته باشد ولی این نقطه عطفی در انتظاردستورات برای رندرنیست در این مرحله CPU از کد های ارسالی خود اطمینان حاصل میکند اما ممکن است سیگنالها در جهات متفاوتی به پردازنده گرافیکی ارسال شوند این رویکرد یک محور کلاسیک است که روند ان تا پایان کار ان ادامه خواهد یافت

حفظ عملیات 3D مرکزی که به ویژه جهت کارمحاسباتی مورد نیاز است در اینجا شیدرها با استفاده از قابلتهای درایورها عملیاتهای محاسباتی سنگین را با توجه به کارهای محاسباتی محول شده به انها میتوانند به بهترین شکل برنامه ریزی کنند

ممکن است سوال شود اینجا هزینه هایی واقعی که برای انجام این کارها صرف شده ایا با قابلتهای سخت افزاری متفاوت است یا خیر برای مثال در معماری GCN یک نقطه هماهنگ سازی در یک صف سخت افزار اختصاص داده شده توسط ACE ارزان تر از یک  موتور محاسبه 3D است

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

 

این ممکن است برای شما در نگاه اول بهترین حالت ممکن به نظر بیاید بهترین حالت مطلق برای AMD و در بد ترین حالت ممکن برای انودیا و بالعکس اگر شما برای استفاده از CUDA حساب کنید نتیجه کاملا عکس خواهد شد

هر دو سازنده سخت افزار طبق معماری های مربوط به خود از موتور های اختصاصی محاسباتی در پردازنده های خود سود میبرند اما اهداف این دو شرکت برای رسیدن هدفشان کاملا از یکدیگر متفاوت است اما منافع بالقوه ان برای هر دو شرکت حائز اهمیت است

در حال حاضر شرکت انودیا از عملکرد معماری خود احساس رضایت میکند به گفته انودیا سخت افزارهای کنونی قابل مقایسه با سخت افزار 5 سال قبل نیست مجموعه ای از ویژگیهای ارائه شده که به وضوح شاهد کاهش مصرف انرژی بوده اند

در حال حاضر هر دوسازنده سخت افزار گرافیکی مسیر پیشرفت به سوی کارایی بالای api دایرکت 12 را میپیمایند هر دو شرکت همتراز با یکدیگر در تلاش برای ارائه موتورهای اختصاصی محاسباتی با روشهای خاص برای کمک به توسعه دهندگان هستند

 

 

 

نمایی از بخش Grid Management Unit در معماری کپلر

 

 

نقش درایور و ایفای ان:

انودیا برای پوشش این ضعف (منظور موتور محاسبه ) توانسته با استفاده از منابع اضافی موجود در درایور تا حدودی بر این مشکل فائق اید این امر برای نسل دوم معماری مکسول است که برخی ویژگیها هنوز در ان استفاده نشده است با استفاده از واحد مدیریت شبکه برای افزایش تعداد موتورهای 3D  از آنجایی که در معماری  GK110، یا همون کپلر کارت های NVIDIA به بخشی به نام "واحد مدیریت شبکه" یا Grid Management Unit مجهز شده است این بخش تقریبا معادل بخش Asynchronous Compute Engines میباشد اما با چند تفاوت بر خلاف موتور async comput بخش( GMU (Grid Management Unit هسته ها یا صف GMU دارای 32 صف محاسباتی واقعی است اما بنا به دلایل نا معلوم این بخش با DX 12 ناسازگاری دارد قبل از نسل مکسول V 2.0 دسترسی GMU به تمام موتورهای 3D غیرفعال بود و تنها محدود به دسترسی به تک اسلات execution بود این محدودیت دسترسی قرار بود در معماری GM2xx برداشته شود به طوری که تمامی GMU های فعال به دستورات پردازنده گرافیکی دسترسی داشته باشند به منظور جلوگیری از همزمانی کم بین دستورات محاسباتی در موتور 3D، ممکن است برای استخراج دستورات محاسباتی از لیست فرمان و رها کردن و سپردن انها  به GMU وجود داشته باشد این موضوع فقط برای مجموعه های محاسبات فرمانی که توسط موانعی مانع از تقسیم انها میشد به صورت منظم و یا نرده ای از یکدیگر جدا نبودند که این کار نیاز مند هزینه های اضافی بودند 

با کمی دقت و تحلیل متوجه میشوید که در صف های دیگر کار محاسباتی اضافه ای تحمیل می شود این کار اضافی جهت اطمینان حاصل کردن از هماهنگی بین GMU ها و موتورهای 3D بودند به این ترتیب سیگنالهای اضافی و fences13 به موتور 3D با هماهنگ سازی بین CPU به عنوان capabilties محدودیت وارد میشد این موضوعات هیچ کدام مربوط به نحوه محاسبات در ASYNC نمیشوند و صرفا یک روش برای تخلیه دستورات محاسباتی از صف اصلی برای جلوگیری از محدودیت های سخت افزاری است 

GMU به صراحت با موتور 3D توسط سیگنال  ها و نرده ها هماهنگ سازی شده است موتورهای ساخت بازی با استفاده سنگین ازدستورات محاسبات در صف 3D میتواند در زمان رفتار موتور 3D را نسبت به معادل AMD خود نزدیکتر کند این یک بهینه سازی کلی نیست این میتواند به عنوان افزایش بار پردازنده نتیجه معکوس داشته باشد ولی هیچگونه تضمینی هم وجود ندارد که محاسبه دستورات و رسم تماس در همان SMM به اجرا دراید

استفاده از واحد مدیریت شبکه دستورات ازادممکن است با توجه به صف محاسبات با موانعی روبرو شود با توجه به این موانع GMU ها باید داری روش برنامه ریزی امنی باشند این روش با غیر فعال کردن موتور 3D اجازه میدهد تا اندکی با فشار پردازشی بر پردازنده  برای هماهنگ سازی استفاده شود که این موضوع برای هر نرم افزاری قابل اجرا نیست و به عنوان موانع نمیتوان از انها اجتناب کرد

بر اساس شواهدی منابع موجود در صف های محاسبات دارای موانعی است که باعث میشوند نتوان از CUDA که این واحد اصل برای طراحی به شمار می اید توسط موتور 3D پشتیبانی به عمل اورد که این موضوع در DX 12 عملا بلا استفاده خواهد ماند

 

سخن پایانی :

مشخصات سخت افزاری هر دو سازده انودیا و AMD بقدری گمراه کننده هستند که تفسیر هر شخصی بنا به استدلال خود از این موضوع کاملا متفاوت است تمامی این تفسیر ها و استدلال ها با توجه به شواهد و منابع موجود در وبسایتهای سخت افزاری جمع اوری شده است

هر شخص با توجه به هوش و ذکاوت خود خواهد توانست از موضوعات ذکر شده استدلال نماید

 

خوب دوستان این مقاله به اتمام رسید از کلیه دوستان خواهشمندم هر کسی که این مقاله رو خونده یا می خونه هر جا مشکلی میبینه به بنده تذکر بده

صمیمانه از همه دوستان متشکرم بنده ناراحت نمیشم میخوام سطح اطلاعات سخت افزاری دوستان افزایش پیدا کنه  @};-  @};- 

 

منابع :http://ext3h.makegames.de/DX12_Compute.html

 

http://wccftech.com/directx-12-async-compute-nvidia-amd/

 

 

ویرایش شده فوریه 28, 2016 توسط hd5870

[ℛ𝒪𝒩ℐ𝒩 1185]

درود

دوست عزیز عنوان تاپیک اشتباه نیست برادر.. داخل مقاله هم بنده ذکر کردم مقاله مربوط به قابلتهای سخت افزاری تعبیه شده در پردازنده های گرافیکی هر دو شرکته انودیا و AMD هست نه بحث در مورد dx 12 و قابلیتها و تفاوتهاش در مورد  DX 11 

بنده خوشحال میشم اگر مایل باشید همون لینکی که گذاشتید رو به زبان ساده ترجمه بفرمایید و از اول یک مقاله کامل راجع به اون در یک تاپیک جدا بنویسید تا همه فیض ببرن

بنده هیچ ابزار ترجمه خصوصی یا حرفه ای ندارم که باهاش ترجمه کنم بیشتر ترجمه یا کلمه به کلمه بوده یا از گوگل ترنسلیت کمک گرفتم و با هزار بد بختی جمله بندی اون رو درست کردم تا به اندازه کافی قابل تفهیم باشه

 

به این دلیل میگم عنوان تاپیک اشتباه هست چون قابلیت موتورهای سخت افزاری nvidia و AMD جهت کارایی در DX 12 تنها به Multi Engine خلاصه نمیشن! مطالب مورد بحث شما هم در رابطه با قابلیت Async Compute هست و در عنوان تاپیک ذکر کردید موتورهای سخت افزاری، این یعنی باید به هر چی شتاب دهنده سخت افزاری در معماری دو کمپانی در رابطه با DX12 هست، رسیدگی بشه که نشده! عنوان مناسب همانطور که گفتم میشه بررسی قابلیت شتاب دهنده های سخت افزاری AMD و NVIDIA در پردازش های ناهمگام DX12 یا به اختصار Async Compute!

سوء برداشت نشه دوست عزیز کار شما بسیار ارزشمند هست و کسی هم منکرش نیست، صحبت من به این دلیل بود که خیلی از مبحث های این بخش در حقیقت معادل فارسی ندارند، در نتیجه کاربران انتظار مطلب بدون عیب و نقصی رو نداشته باشند!

موفق باشید @};-

ویرایش شده فوریه 28, 2016 توسط RONIN021

[hd5870 9458]

به این دلیل میگم عنوان تاپیک اشتباه هست چون قابلیت موتورهای سخت افزاری nvidia و AMD جهت کارایی در DX 12 تنها به Multi Engine خلاصه نمیشن! مطالب مورد بحث شما هم در رابطه با قابلیت Async Compute هست و در عنوان تاپیک ذکر کردید موتورهای سخت افزاری، این یعنی باید به هر چی شتاب دهنده سخت افزاری در معماری دو کمپانی در رابطه با DX12 هست، رسیدگی بشه که نشده! عنوان مناسب همانطور که گفتم میشه بررسی قابلیت شتاب دهنده های سخت افزاری AMD و NVIDIA در پردازش های ناهمگام DX12 یا به اختصار Async Compute!

سوء برداشت نشه دوست عزیز کار شما بسیار ارزشمند هست و کسی هم منکرش نیست، صحبت من به این دلیل بود که خیلی از مبحث های این بخش در حقیقت معادل فارسی ندارند، در نتیجه کاربران انتظار مطلب بدون عیب و نقصی رو نداشته باشند!

موفق باشید @};-

درود

خوب شما خودتون منبعش رو دارید میتونید رجوع کنید به اونجا ببینید غیر از همون بحثهایی که من داخلش نوشتم و اینکه فقط در مورد موتور async comput در اون مقاله بحث شده چیز دیگه ای میتونید پیدا کنید اگر پیدا کردید شما خودتون زحمت ترجمه و تدوین اون رو بکشید و بزارید همین تاپیک تا همه دوستان مطالعه کنن و لذت ببرن