از کپلر تا ماکسول | بررسی تخصصی مبحث زمان بندی در معماری های انویدیا

معماری های انویدیا

معماری های انویدیا

[su_note note_color=”#f5f7f7″]درود به همراهان همیشگی سایت. اول اینکه مطلب فعلی سنگین ترین بررسی فنی و تخصصی معماری انویدیا در سایت است. دوم اینکه مطمئنیم خیلی ها همین اول مطلب را که ببینند عطایش را به لقایش میسپارند! سوم اینکه مطمئن باشید با خواندن تحلیل و بررسی زیر درک عمیقی از چرایی کوچ انویدیا از معماری «کپلر» به معماری «ماکسول» پیدا خواهید کرد و در آخر هم بگوییم همانند این مطلب در وب فارسی وجود ندارد و این مطلب برای اولین بار در سایت «گارد۳دی/Guard3d.com» منتشر میشود. [/su_note]

اگر خبرهای سخت افزاری را دنبال کرده باشید احتمالاً نام پاسکال (Pascal) را شنیده اید. Pascal Architecture نام معماری جدید کمپانی انویدیا است که گفته میشود اواسط سال ۲۰۱۶ میلادی جانشین نسل دوم معماری ماکسول خواهد شد. معماری پاسکال در مرحله TAPE-OUT است و به گفته انویدیا از ۲ برابر بازدهی بیشتر به نسبت نسل دوم ماکسول برخوردار است. پاسکال از نسل دوم فناوری حافظه HBM استفاده میکند و میتواند از پهنای باند عظیمی معادل ۱ ترابایت بر ثانیه پشتیبانی کند.

مرحله TAPE-OUT مرحله ای است که پس از سنتزهای سنگین مداری توسط سیستم های EDA مثل پالادیوم XP2 شرکت های مطرحی همچون Cadence قرار می گیرد و وبعد از این مرحله مدار طراحی شده به شکل PHOTO MASK برای شرکت های لیتوگراف کننده ای مثل TSMC، UMC یا گلوفو فرستاده میشوند تا توسط آنها ابتدا با Yield پایین و در آینده با بهینه سازی های خود سازنده با Yieldهای قابل قبول روی ویفر های (Wafer) سیلیکونی +۱۶nm FFحک شوند. (این پروسه در آینده با توضیحات مفصل به صورت یک مقاله جدا خدمت شما عزیزان  قرار خواهد گرفت )

به گفته Jen-hsun Huang مدیر عامل انویدیا معماری پاسکال میتواند تا ۱۰ برابر سریعتر از نسل دوم معماری ماکسول در محاسباتی با نیاز به دقت محاسباتی کمتر با توجه به Mixed precision بودن تراشه عمل کند . با پشتیبانی از فن‌آوری‌های NVLink  و ۳D Memory میتواند تا ۳ برابر حافظه بیشتر به نسبت چیزی که در حال حاضر در Fury X وجود دارد  را در اختیار مخاطبش قرار دهد.  به عبارتی دیگر ۴۰۰ درصد راندمان کاری بیشتر در پردازش محاسبات اعشاری ترکیبی را در پاسکال خواهیم داشت. فن‌آوری NVLink  قرار است جای استاندارد PCI Express کنونی بگیرد و این یعنی ۵ برابر پهنای باند بیشتر در معماری پاسکال!

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

ما برای اینکه تحلیل درستی در مورد دومین نسل از معماری ماکسول داشته باشیم نیاز داریم تا ابتدا معماری کپلر را بررسی کنیم و ببینیم چرا در تئوری و روی کاغذ از ماکسول قویتر است، اما در عمل تا ۵۰ درصد هم از ماکسول ضعیف تر است!؟ این موارد به بهینه سازی های انویدیا و روش های این کمپانی در طراحی معماری مربوط میشود که قرار است در زیر به برسری آن بپردازیم. بنابراین در مقاله از کپلر تا ماکسول | بررسی تخصصی زمانبندی در معماری های انویدیا به بررسی این موارد میپردازیم. پس ما باشید.

شروعی بر بهینه سازی های انویدیا

نکته مشترکی که در بین معماری های انویدیا وجود دارد و بسیار هم مهم است، حرکت انویدیا از HWS به SWS و قوی تر شدن دیتا شیت های SW های موجود در معماری ماکسول دو است. «HWS» مخفف «Hardware scheduling» یا همان برنامه ریزی سخت افزاری است که از زمان معماری فرمی به بعد در تمامی کارت های انویدیا به صورتی جدی در معماری این کارت ها دیده میشود. Hardware scheduling یا همان برنامه ریزی سخت افزاری یعنی سخت افزار در داخل GPU فقط کار زمان بندی «Scheduling» را انجام میدهد که شامل خوبی ها و بدی هایی است که در ادامه مقاله ابتدا توضیح کوتاهی در باره آن میدهیم و در ادامه برای درک معماری ماکسول ابتدا کپلر را بررسی میکنیم تا در این مسیر به ماکسول برسیم.

زمانی که زمان بندی «Scheduling» دستورات درون تراشه گرافیکی (GPU) انجام شود موجب میشود Thread ها از سرعت بسیار بیشتری برخوردار شوند که البته این سرعت هم شرایطی دارد. مثلا اگر مکانیزم ترد بندی دستورات چک Ilp مخفف Instruction Level Parralisim (یا موازی گرایی/پاراللیسم) را داشته باشیم، بهتر است که برای جوگیری از تاخیرات مختلف، پردازش اطلاعات از طریق نرم افزار و پردازنده صورت گیرد، اما اگر مکانیزم رده بندی دستورات یا مبنای پردازشی آنها بر اساس تکنیک TLP مخفف «Thread Level Parallelism» باشد با شرایط بهتری مواجه میشویم، چون دیگر نیازی به روش دستورات چک Ilp نیست و همین مورد یکی از مهمترین دلایل استفاده بیشتر ابر کامپیوترهای جهان از تراشه های گرافیکی است که در آنها از HWS استفاده شده است.

مثلاً در معماری فرمی «Fermi Architecture» تمام تراشه های گرافیکی (GU) از HWS استفاده میکنند و این مورد در تمامی کارت های مبتنی بر معماری GCN هم دیده میشود که البته مدل های انویدیا پیچیده تر و Catch Coherency بالاتری نسبت به GCN داشته اند. بههمین دلیل است که بسیاری از ابر کامپیوترهای جهان در حال حاضر از معماری ۷-۸ سال پیش شتاب دهنده های فرمی استفاده میکنند. اما همین مقدار برای ابر رایانه هایی که از تراشه های گرافیکی مبتنی بر GCN استفاده میکنند بسیار کمتر است. این در حالی است که کمپانی انویدیا از شتاب دهنده های کپلر و معماری GT200 تسلا هم استفاده میکند.

روش HWS ایراداتی هم دارد که شامل اشغال حجم زیادی از سطح مساحت تراشه (یعنی ترانزیستور زیادی برای این بخش ها مصرف میشود)، مصرف برق زیاد به خاطر استفاده از واحدهای پر شارژ گیت یا حتی دائم الشارژ زمانبندی، اتصالات بسیار زیاد بخش های مدیریت داده (کل بخش های زمانبندی و مدیریت) که موجب افزایش مصرف برق تراشه میشوند و همچنین طراحی پیچیده و اتصالات زیاد بین گیت ها که باعث ایجاد نشتی الکترون بیشتر ( Leakage) که نتیجه آن افزایش دما است، میباشد.

اما SWS چیست!؟ این کلمه مخفف «Software Scheduling» یا زمان بندی نرم افزاری است و همانطور که از نامش پیداست، زمان بندی برای پردازش اطلاعات به صورت نرم افزاری انجام میشود. در مورد معماری کارت های انویدیا تو پرانتز بگویم که هنوز هم بسیاری از کارت های انویدیا از روش HWS استفاده میکنند که دلایل تکنیکی خاص خودش را دارد. مثلا در معماری های چک دائم ILP حدوداً ۹۰ درصد پردازش ها توسط نرم افزار (پردازنده) انجام میشود، چون میزان تاخیر را به  توان عملیاتی «Throughput» ترجیح میدهند. مثل دو معماری VLIW-4-5 و کمتر از آن هم دو معماری کپلر «Kepler» و نسل دوم معماری ماسکول (Maxwell) که تاخیر بسیار کمی دارند.

در واقع نسل دوم معماری ماسکول (Maxwell) یکجور بالانس بین معماری کپلر «Kepler» و معماری فرمی «Fermi» است که البته به معماری کپلر نزدیک تر است و ما هم به همین دلیل این مبحث را شروع کردیم تا به شاهکار ماسکول (Maxwell) ای برسیم که تمامی کارت هایش بر روی کاغذ از کارت نسل قبلی ضعیف تر، امادر عمل قویتر و توان پردازشی بهتری دارند. مزایا و معایب SWS هم دقیقا معکوس روش HWS است. مثلا اگر مدیریت ترد ها تاخیر داشته باشد، بهتر است تعداد هسته ها زیاد باشد تا تاخیر جبران شود، دقیقا شبیه همان روشی که AMD روی معماری VLIW5 های خودش به طور گسترده استفاده کرده است. (مثل تراشه CYPRESS در HD5870 )

اگر بخواهیم مثالی بیاوریم میتوانیم به دو کارت HD 5870 با ۱۶۰۰ هسته و GTX 480 با فقط ۴۸۰ اشاره کنیم. در این مثال هسته های ۵۸۷۰ نیازمند چک عدم وابستگی دستورات یا همان ILP هستند و به همین دلیل با هسته های بسیار کندی مواجه ایم که تعداشان زیاد است، بنابراین نیازی نیست که دستورات خیلی سریع به هسته ها برسند، پس دستورات با سرعت کمتر و الویت بندی به هسته ها میرسند و تراشه گرافیکی هم با بازدهی خوب کارش را انجام میدهد.

در مقام مقایسه به GTX 480 میرسیم که هسته های سریع تری دارند (با دو برابر رفکانس کلی تراشه) و به چک عدم وابستگی دستورات یا همان ILP هم نیازی ندارند. بنابراین دستورات با سرعت بیشتری هسته ها را تغذیه میکنند و در صورت بیکاری،  فاکتور اشغال هسته ها یا همان عنصر کلیدی «نسبت اشغال/Occupancy Rate» کاهش میابد و این امر موجب کاهش قدرت کلی تراشه میشود که دقیقاً در کارت گرافیک HD 5870 شاهدش بودیم. در واقع درکارت HD 5870 باید حجم زیادی دستورات موازی فرستاده شود که مشکل تاخیر حل شود.

صفحه بندی

اما Ilp و TLP چیست!؟

در توضیح کلی این مطلب اول باید اشاره کنیم که صحبت ما در مورد GPU ها است و اینکه داریم در مورد SIMD یا حتی به نوعی MIMD ها صحبت میکنیم. ساده بگوییم؛ داده های گرافیکی از یک سری دستورات تشکیل شده اند که باید بر روی حجم بسیار زیادی از داده ها اعمال شوند. یک (thread ) ترد گرافیکی را میتوانیم به صورت ۱ دستورالعمل تصور کنیم (جمع و ضرب و تقسیم یا باقی عملگر های ریاضی یا دستور ذخیره سازی و بارگذاری و …. هر چیزی که بشود آن را دستور خواند، instruction مینامیم) که قرار است بر روی چندین دیتا یا داده اعمال شود (منظور از دیتا اعداد و ارقامی است که قرار است یا بر روی آنها اعمال جمع وضرب و…  انجام شود و یا ذخیره سازی/فراخوانی بشوند  که به آنها DATA گفته میشود).

به صورت عمومی ترد های گرافیکی به شکل یک دستورالعمل هستند که باید بر روی ۱۶ داده اعمال شوند. اما انویدیا و AMD هر یک به شیوه خود با این ترد ها رفتار میکنند که در بخش اول بررسی تخصصی معماری GCN رفتار AMD را توضیح دادیم و اینجا قرار است بیشتر از انویدیا صحبت کنیم. توضیح اینکه معماری Vliw برند AMD هم ببه درک بهتر معماری کپلر و فرایندی که درنهایت موجب تولد ماکسول شد کمک میکند، پس از معماری AMD Vilw هم برای فهم و درک بهتر موضوع مهم زمان بندی کمک می گیریم. ما برای شروع از ساده ترین بلاک یعنی حالت SISD یا یک دستور از یک داده شروع میکنیم و همزمان به توضیح SIMD میرسیم. چنین چیزی به این صورت است که در تصویر شماتیک زیر میبینید:

در SISD سمت چپ، شما دستورات را به شکل مربع های مشکی کاملی میبینید که بعد از اعمال روی DATA های خام (مربع سفید) در پردازنده SISD به صورت مربع های خاکستری و داده های نتیجه برای اجرای دستورات در می آیند. مکانیزم SIMD مشابه SISD است، با این تفاوت که به جای اعمال دستور روی یک دیتا، روی چند دیتا (در شکل بالا ۴ دیتا) اعمال می گردد. حال میتوانیم با کنار هم قراردادن چند SIMD و ترکیب آنها یک MIMD ایجاد کنیم. به این صورت چند دستور به طور همزمان رو تعداد زیادی داده اعمال میشود. چینش و مکانیزم قرار دادن این SIMD ها منجر به اختلاف عمیق بین معماری های داخل خود انویدیا و AMD در نسل ها مختلف آنها بوده که خودش مبحث مفصلی را میطلبد.

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

روش A) قراردادن SIMD ها کنار هم و همراه با اشتراک کلی منابع و اجرای دستورات به طور پیوسته که مزایای این روش به شرح زیر است:

معایب:

روش B) قرار دادن SIMD ها در کنار هم با منابع مستقل و غیر پیوسته که مزایای این روش به شرح زیر است:

معایب:

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

حال میرسیم به توضیح ILP وچرا توضیحات بالا مورد نیاز بود؟؟

instruction level parallelism یا ILP به این معنا هست که در یک MIMD یا مجموعه SIMD ها که دارای منابع اشتراکی زیادی هستند، اگر قرار است دستورات به طور پیوسته با هم ارسال شوند و اگر نتیجه دستوری وابسته به دستوری باشد که هنوز انجام نشده یا در حال انجام است، سیستم باید چگونه متوجه این مورد شود و ایا این دستور وابسته را نباید در سری دستورات قرار دهد!؟ (سخت بود نه؟! بگذارید بیشتر توضیح دهیم!)

برای توضیح طرح سوال دشوار که درک اون قدری سخت هست یک مثال مطرح میکنیم: پس به دستورات زیر دقت کنید:

در ۳ خط بالا، ما ۳ سه ترد داریم. اگر به ترد M نگاه کنید متوجه می شوید انجام ترد شماره ۳ که M می باشد به نتیجه تردهای E و F بستگی دارد. حالا فرض کنید ما یک MIMD داریم با پهنای ۳ هسته ۳-WIDE سری که باید به صورت سریالی عمل کنند، یعنی شبیه به SIMD هر ۳ هسته بتوانند ۳ ترد سری و متفاوت را با هم اجرا کنند. پس اگر ما بخواهیم هر سه این ترد ها را با هم اجرا کنیم عملاً نمیتوانیم. چون ترد شماره ۳ یا M باید زمانی اجرا شود که نتایج تردهای E و F مشخص شده باشد.  اینجا مسئله استخراج ILP مطرح میشود، یعنی به این صورت که سیستم مشخص کند کدام دستورات به نتایج دستورات قبلی یا در حال اجرا وابسته اند که آنها را اجرا نکند و به بهترین شکل ممکن و در بهترین زمان ممکن آنهارو به هسته ارسال کند (بعد از انجام دستورات وابسته).

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

باوجود تفاسیر مقدمه گونه بالا قصد داریم در مقاله از کپلر تا ماکسول ابتدا نگاهی به معماری کپلر «Kepler» بیندازیم تا به این معماری بیشتر آشنا شویم تا از این رهگذر و طبق مواردی که در بالا توضیح دادیم به شاهکاری همچون نسل دوم معماری ماسکول (Maxwell) برسیم.

واحد های اجرایی Execution unit Hotclock در کپلر ۱۰۴ 

تغییرات اصلی در هسته های اجرایی تراشه کپلر ۱۰۴ یا (kepler GK104) نهفته شده است. جایی که با اضافه شدن سه برابری هسته های GTX 580 فقط شاهد ۱۶ درصد ترانزیستور بودیم که در آن زمان سوالات بی شماری در بین اهالی فن ایجاد کرد. این مقدار ترانزیتسور یعنی عملاً اتفاقی نیفتاده! به عبارتی تفاوتی بین GTX 480 و GTX 580 نبود و حالا قصد داریم با موشکافی این موارد به معماری جدید ماکسول دو برسیم.

مهمترین علتی که در آن زمان عامل این اتفاق بود، تعداد بسیار کم SM هایی بود که نتیجه آن کاهش تعداد Front End ها و FFU های موجود در تراشه کپلر ۱۰۴ بود. اما یکی از شبهات مهمی که در آن زمان مطرح بود این بود که انویدیا با از بین بردن hotclock ها به بهره وری (efficiency) بسیار بالایی رسیده است!! اما اجازه دهید ببینیم شایعه آن زمان که از سوی انویدیا پخش شده بود، در معماری کپلر ۱۰۴ درست بود یا شعاری تبلیغاتی!؟

برای درک این سوال باید بازگردیم به تئوری ساخت نیمه هادی ها و و این سوال را بپرسیم که چرا تراشه های دارای اجزائ اسنکرون داخلی ( یا Multiple Clock/البته در اینجا Pumped Cclock که بعداً دلیلش را عرض میکنیم) بر خلاف جریان داده (Data Flow) در سطح تراشه با فرکانسی متفاوت از کل تراشه عمل میکنند؟!

یکی از تئوری ها و مسائل اصلی طراحی های انودیا از سری G80 یا GT200 با اسم رمز تراشه تسلا تا همین فرمی دو نسل گذشته، استفاده از واحد های اجرایی در فرکانسی بسیار بالاتر از کل تراشه با یک ضریب خاص بود. انودیا پیش تر اسم این روش را Shader Clock گذاشته بود و واحد های اجرایی Execution Unite ها با ضریب ثابتی مثلاً در فرمی به صورت ۲x یا در نسل های پیشتر با رقم بیشتری در حدود ۲.۵x نسبت به فرکانس کل تراشه در معماری های مختلف به کار گرفته میشد.

در واقع این سیستم که با نام Double Pumped شناخته میشود برای یک Execution Unit به منظور ۲ برابر کردن فرکانس هسته های اجرایی توسط اینتل از زمان Net Burst Architecture شروع به کار کرده (همان  معماری ای که در هسته های Pentium 4 مورد استفاده قرار گرفته بود) و توسط انویدیا از زمان تسلا تا همین فرمی ادامه داشته است. ما برای آزمایش این موضوع از تست اختصاصی زیر استفاده کردیم.

تست اختصاصی ما

این مورد باعث افزایش حجم کلی تراشه و در نتیجه استفاده از ترانزیستور بیشتر و نهایتاً مصرف برق بیشتر میشود. برای درک این سوال بیاید وارد یک مسئله تخصصی در علم سخت افزار شویم. یعنی افزایش حجم یک واحد محاسباتی ALU بر روی تراشه  ASIC یا FPGA که قرار است این مورد را با هم بررسی کنیم. ما موفق شدیم تست مدار سنتز را پیاده کنیم، اما متاسفانه در آخرین لحظاتبه شمکل فنی خوردیم و نتایج را از دست دادیم.

فقط بگوییم که در این تست یک عدد Integer ALU را طراحی کردیم و با سنتز برنامه VHDL توسط Xilinx ISE یک مدار با ضریب کلاک کل Data Flow (به این معنا که ضریب ALU با کل تراشه یکی هست) و یک مدار با ضریب کلاک خارج از data flow (در انودیا به صورت Pumped Clock) ایجاد کردیم تا نتایج حاصله را بر حجم کلی Integer ALU بسنیجم. سپس با زبان VHDL یک ALU با مشخصه ۸ دستور منطقی (Logic) و ۸ دستور محاسبه (Arithmetic) همراه با ورودی های ۸bit BUS جهت ورودی و خروجی و البته یک Selector 4bit را برای سوئیچ روی دستورات دو بخش منطق و محاسبه ایجاد کردیم.

در ما موفق شدیم با برنامه فوق  سنتز XST شده یک برنامه VHDL برای یک ALU با ۱۶ دستورالعمل را ایجاد کنیم. یعنی دو تصویر با تنها یک اختلاف یک کلاک اضافی برای ALU طراحی کردیم که تقریباً ابعاد تراشه را به مقدار ۴۵ درصد افزایش داده بود. این نتیجه و طراحی ما نشان میدهد با انجام بهینه سازی های مختلف میشود Pipline Stage ها را کاهش داد. اما طبق آزمایشی که انجام دادیم متوجه شدیم ایجاد یک کلاک خارج از جریان داده تراشه موجب افزایش شدید حجم Integrated Circuit های مدار و افزایش بی مورد Pipline Stage ها برای ردگیری کلاک توسعه یافته میشود.

توضیحات فوق کاملاً اضافی و در حد آکادمیک بوده و در هیچ بررسی سخت افزاری به آنها اشاره نشده و متاسفانه همانطور که گفتیم به دلیل مشکل فنی ناشی از ویندوز های کرک شده نتوانستیم خروجی مربوطه به نتایج را در سایت بگذاریم و حس و حال تست مجدد این فرآیند را هم نداشتیم. چون این موارد در سطح دانشگاهی و Embedded Chip Designer های سازنده های تراشه بررسی میشود. بنابراین اگر تعریف از خود نباشد ما کار بزرگی انجام دادیم که فقط اهالی فن ارزشش را میدانند و بس!

با معماری کپلر «Kepler» آشنا شوید

اگر نگاهی به GK104 یا حتی Die shot آن بیندازیم متوجه شباهت های بسیار بسیار زیادش با معماری فرمی میشویم. در واقع اگر بخوایم منصفانه نگاه کنیم، بر خلاف معماری فرمی (Fermi architecture) و معماری GCN که از طراحی جدیدی استفاده میکردند، تراشه کپلر معماری جدیدی نداشت و همان فرمی با قابلیت های جدید بود.

اگر از دید Multi processor Level (سطح بالا) به تراشه نگاه کنیم، میتوانیم بگوییم به لحاظ عملکرد معماری های فرمی و کپلر بسیار به هم شبیه هستند. اگر این موضوع را با هسته های GF100/110 مقایسه کنیم باید بگوییم که از آنجایی که SM درون هسته ها در متد ILP کاربردی ندارد، پس با تفاوت های بسیار بیشتری رو به رو خواهیم بود. بنابراین بهترین حالت این است که اگر در آینده میخواهیم از دید ML به تراشه نگاه کنیم، بهتر است SM های موجود در هسته های GF104/114 را بررسی کنیم.

برای درک بهتر عملکرد تراشه بهتر است از ریز ترین و کوچک ترین قطعه آن شروع کنیم تا پله پله به ساختار بزرگتر تراشه برسیم. سری GF100 برای اولین بار توسط آقای Jonah Alben در تاریخ ۲۰۱۰/۴/۱۲ (معادل دوشنبه ۲۳ فروردین ۱۳۸۹) برای رسانه های خبری تشریح شد. GF100 نام رمزی بود برای تراشه هایی که مبتنی بر معماری فرمی (Fermi) بودند و با نام هایی همچون GF100 / GF104 / GF106 / GF108 / GF114 تولید میشدند.

نکته جالب توجه  در مورد تراشه های گرافیکی مبتنی بر معماری فرمی (Fermi) که تحت قالب کارت های سری GTX 400 به بازار عرضه شدند این است که از کتابخانه Direct3D 11.0 و Direct3D 12 پشتیبانی میکنند و این یعنی سطوح قابلیت های feature level 11_0 در این معماری پشتیبانی شده و فعال است. برای درک بهتر feature level های Direct3D میتوانید به مقاله «نگاهی به قابلیت های رندرینگ موجود در Direct3D 11.3 و Direct3D 12»رجوع کنید که پیش تر در سایت منتشر کرده بودیم.

این معماری در سه مدل مختلف معرفی شده بود که شامل تراشه های نو سازی شده نسل قبل از کپلر به نام تراشه های فرمی (Fermi) با اسم رمز (GF)، تراشه های مبتنی بر نسل اول معماری ماکسول (Maxwell) با اسم رمز (GM) و در نهایت تراشه های جدید مبتنی بر معماری کپلر (Kepler) با اسم رمز (GK) از این جمله اند. در واقع مهمترین کارت های تولید شده «جدید» سری کپلر را میتوان با دو اسم رمز (GK104) و (GK110) شناخت که به ترتیب با کارت هایی همچون GeForce GTX 760، GeForce GTX 770، GeForce GTX 760 Ti و در GeForce GTX 780، GeForce GTX 780 Ti و سه کارت قدرتمند و گران قیمت GeForce GTX Titan، GTX Titan Black و کارت GTX Titan Z معرفی شدند.

در معماری کپلر ۱۰۴ که با نام های رمز GK104, GK106, GK107 برای کارت های سری ۶۰۰ عرضه شده، به جای دو برابر کردن هسته های اجرایی برای بازدهی بالاتر، برای راندمان بیشتر هسته های اجرایی را افزایش دادند و در نتیجه کل warp ها با سیستم زمان بندی جدیدی در کل هسته ها Issue پخش میشوند و بدون انجام کار اضافی و با سرعتی دو برابر، Front End های همگام با آن منتظر روال بعدی Warp ها میشوند که نتیجه آن افزایش بازدهی دو برابر تراشه گرافیکی است. تصویر زیر قیاس کلی و بهبود های Elimination Hotclock در دو معماری کپلر و فرمی است:

بیاید با هم مفهوم عناصر موجود در تصویر را مرور کنیم: 

۱: هر دو هسته کپلر با Pipline Instruction مشابه بدون ۲x clock تنها ۱.۸ برابر ۱ هسته فرمی است. یعنی  هر هسته کپلر حدود ۱۰ درصد کوچکتر از هر هسته فرمی است. بنابراین ۲x clock موجب افزایش روال Pipline Instruction ها شده و همین موجب افزایش ۱۰ درصدی هسته های کودا موجود در معماری فرمی میشود. (بنده در تست اختصاصی مدار سنتز هم به نتیجه ۴۵ درصد افزایش رسیدم که البته بدون بهینه سازی مدار بود.)

۲: هر دو هسته موجود در کپلر به اندازه ۹۰ درصد توان مصرفی یک هسته فرمی انرژی مصرف میکنند. این یعنی اینکه انویدیا دوره Shader Clock ها را تمام کرده و وارد مرحله جدید از معماری سخت افزاری بهینه شده با افزایش کارایی شده است.

۳: اگر به سرعت کلاک دو معماری نگاه کنیم با اختلاف زیادی مواجه میشویم. یعنی هر دو هسته کپلر ۵۰ درصد یک هسته انویدیا در کلاک مشابه مصرف انرژی دارند که رقم زیادی است.

سه مورد ذکر شده تنها گوشه ای از تغییرات مهندسی سخت افزار موجود در معماری کپلر بود. اما مورد مهمتر که در ابتدای بررسی هم به آن اشاره کردیم، روال زمان بندی بخش Front End ها است که در ادامه آن را تشریح و بررسی میکنیم. توضیح اینکه معماری کپلر (Kepler) با کد رمز GK در سری GeForce 600 و GeForce 700 مورد استفاده قرار گرفته اند و از این جهت اهمیت زیادی دارند. GeForce 700 برای اولین بار با دو کارت قدرت مند و رده بالای GeForce GTX Titan و GeForce GTX 780 با نام رمز سیلیکون GK110 در سال ۲۰۱۳ معرفی شد و هنوز هم جزو کارت های مبتنی بر معماری کپلر در بازار از فروش بالایی برخوردراند.

با این حال سوال مهم این بخش که در نهایت منجر به طرحی معماری ماکسول ۲ شد این است که چرا در معماری کپلر افزایش ۳ برابری هسته ها به صورت خطی موجب افزایش ۳ برابری کارایی نشده است!؟ برای پاسخ به این سوال باید وارد مبحث زمانبندی (SW scheduling Front End) شویم که میتوانید پاسخ این سوال را در صفحه دوم دنبال کنید.

بررسی و تشریح روال زمان بندی در بخش Front End

زمان بندی بخش front End ها یا (SW scheduling Front End)  مبحث بسیار مهمی در علوم کامپیوتری و معماری تراشه ها و میکروپروسسور ها است که از دو زاویه زیر قابل بررسی است که سعی میکنیم تا جایی ممکن آن را تشریح کنیم.

الف: بخش اجرایی تراشه

این بخش برای کنترل و اعمال داده برای هسته های مستقل است که میتوانیم آن را Front End یا حتی در موارد ساده تر Control Unite بنامیم. یعنی بخشی که میتوانیم مراحل زیر را برای پردازش درست تراشه در آن متصور شویم.

ب: بخش اجرایی تراشه

وظیفه این بخش Excute دستورات ارسالی از طرف Front End ها است و کارآمد ترین بخش یک تراشه در معماری مربوط به آن است. این بخش باید بتواند به بهترین روش و بهینه ترین حالت ممکن وظایف ارسالی از طرف CU ها را انجام دهد. تمامی تراشه ها و پردازنده های موجود در جهان از همین مبنای ساده برای اجرای دستورات استفاده میکنند. هر چند در برخی موارد طراحی تراشه قسمت هایی حذف یا اضافه میشود، اما روال کار یکی است.

یعنی اصل کار طراحی تراشه ها همیشه یک جور است و تنها تفاوت در جزئیات آنها رخ میدهد. مثل فناروی های ابتکاری اینتل در پردازنده های خودی برای به حداکثر رساندن میزان بهروری از IPC های موجود در معماری که در این مبحث مجال توضیحش نیست. در منطق زمان بندی دستورالعمل ها برای اجرا در تراشه های قدیم و جدید ( مراحل ۲ و ۳  بخش ب ) مهندسین طراح همیشه دو راه در پیش داشتند.

راه اول Static Scheduling و راه دوم هم HardWare Scheduling بود که به ترتیب به بررسی این دو مبحث مهم میپردازیم.

راه اول: روش Static Scheduling

در این متد زمان بندی دستورات و طبقه بندی و اسال آنها طبق یک جدول از پیش تایین شده (اطلاعات دستورالعمل ها/Instruction Info) توسط نرم افزاری مخصوص همراه با اطلاعات عملیات ها و دستور العمل ها (Operand و instruction) به تراشه ارسال میشود و عملاً front end تنها وظیفه ورپ سازی و ارسال آنها به واحد های اجرایی (Execution Units) را بر عهده دارد. در این حالت تراشه بشدت شکل Intensively Compiler به خود میگیرد و در واقع توان Autonomously Processing خود را بشدت از دست میدهد و اینجاست که برنامه نویسان با مشکل عدم بهینه سازی زمان بندی دستورات تراشه مواجه میشوند.

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

استفاده از روش Static Scheduling برای بهینه سازی دستور العمل های پردازشی  موجب کاهش پیچیدگی Front End های میشود که نتیجه آن میتواند کاهش سطح مساحت ویفر (Die Size) واحد کنترلر موجود در تراشه گرافیکی یا پردازنده باشد. همچنین کاهش Autonomously Processing به معنیا از دست دادن بخشی از قدرت محاسباتی Computing Capibility است که البته در پردازش بازی بی تاثیر است. چون تراشه نمیتواند به طیف وسیع و متفاوتی از دستورالعمل ها واکنش مناسبی نشان دهد و نیازی به برنامه ریزی مستقیم تراشه برای کارکرد مناسب به ازای هر دستور متغیر وجود دارد. بنابراین استفاده از این روش برای محاسبات داده های پیچیده مناسب نیست.

راه دوم: روش HardWare scheduling

در این روش بخش Front End های طوری طراحی میشود که حد المکان بتواند به صورت مسقل تمامی وظایف زمانبندی و چک Instruction Dependency و …را به صورت خود مختار انجام دهد. هر چند کار اصلی بر عهده پردازنده است که از طریق درایورهای بهینه شده انجام میشود. اما بیاید به مزایا و معایب این روش هم نگاهی بیندازیم:

در این حالت تراشه خود مختار تر از SW Scheduling میشود. بنابراین برنامه نویسان کار راحت تری برای بهینگی نرم افزار های ساخته شده  روی تراشه دارند. چون عمده کار توسط بخش Front End تراشه انجام میشود. پس در این روش سرعت بهینگی نرم افزار ها اجرا شده روی تراشه بهبود زیادی به نسبت مدل قبلی دارد. چون بخش Front End خودش وظیفه چک وابستگی دستورالعمل ها و ایجاد جدول زمانبدی دستورات را بر عهده دارد، بنابراین Front End ها به کلاک های بیشتری برای ایجاد ریسمان (Warp) های مناسب برای تغذیه Execution Unite ها یا واحد های اجرایی به نسبت روش قبلی دارند.

به عبارتی دیگر  در صورت بهینگی دستورات برای حالت قبلی، عملکرد تراشه با SW Method بسیار چشمگیرتر خواهد بود. نتیجه استفاده از این روش پیچیدگی طراحی مدار های داخلی هر واحد CU است که قرار است به صورت خود مختار (Autonomously) دستورات را Dependency Checking و Scheduling کند. در واقع افزایش تعداد Autonomously Processing به معنای بدست آوردن مقدار زیادی قدرت محاسباتی (Compute) در تراشه است.

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

با توضیحاتی که در بالا دادیم بهتر است ببینیم در معماری کپلر چه اتفاقی افتاده و کپلر از کدام روش برای پردازش اطلاعات استفاده کرده که با وجود افزایش ۳ برابری هسته ها به صورت خطی شاهد افزایش قدرت ۳ برابری هسته های مبتنی بر این معماری نبودیم!

زمانبندی در معماری کپلر ۱۰۴ 

خوب؛ پیش از هر چیزی باید بگوییم که مهندسین انودیا در کپلر تصمیم گرفتند از روش زمانبندی نرم افزاری (SW Scheduling) استفاده کنند. برای درک بهتر این موضوع به تصویر زیر نگاه کنید:

در تصویر بالا شما شاهد نحوه قرار گیری بلاک و سیستم زمانبند در دو معماری فرمی و کپلر هستید. اگر بخواهیم برای توضیح از نسل قبل فرمی شروع کنیم باید بگوییم که روش HW Scheduling  استفاده شده در تراشه ای همچون GF114 برای Front End ها میتواند به خوبی کار های پایه ای همچون زمانبدی Scoreboarding و یا انتخاب و برداشت warp ها از بخش Pool ریسمان ها را انجام دهد. بدین معنا که Front End های فرمی مسئول زمانبندی خود دستورالعمل های موجود در ریسمان ها نیز میباشند.

البته اینجا منظور از Scoreboarding نگاه داری ریسمان Warp هایی است که روی حافظه قرار دارند و در انتظار دسترسی به واحد های اجرایی نگاه داشته میشوند. این مورد برای عملیات هایی که تاخیر زیادی دارند حائز اهمیت است. در واقع این مورد در فرمی موجب میشد که تراشه قادر به انجام اعمال محاسباتی با حد تغییر زیاد دستورالعمل ها به خاطر پیچیدگی FE های موجود در آن باشد. بنابراین پیچیدگی Front End ها برای تراشه ای که تعداد کمی واحد زمانبندی در تراشه خود دارد عامل مهمی محسوب نمیشود.

نکته که باید بگوییم این است که پیچیدگی و کاهش میزان بهره وری (Efficiency) و قدرت برای تراشه هایی که از ۳۲ واحد زمانبندی استفاده میکنند موجب افزایش شدید سطح مساحت تراشه و در نتیجه کاهش بازدهی آن میشود که این مورد در کپلر GK104 وجود داشت و البته امر قابل قبولی هم محسوب میشد. برای همین بود که مهندسین انویدیا در کپلر از روش Static Scheduling استفاده کردند تا به بهره وری و قدرت بالایی از تراشه برسند.

چگونگی کارکرد زمانبندی در تراشه های گرافیکی

به طور سنتی (در نسل فرمی الاخصوص) پردازنده با توجه به دستورات درایور شروع به ساخت یک روال ثابت زمانبندی Static Scheduling میکند و سپس آنها را به واحد های زمانبندی سخت افزاری GPU میفرستد که این امر باعث افزایش پیچیدگی در دو بخش Hardwrae و هم Software میشود. (هرچند بخش software نسبت به حالت تماماً نرم افزاری کار راحت تری در پیش دارد.). به طور کلی Hardware Instruction Scheduling به پردازنده اجازه میدهد به بهترین روش ممکن و با بالاترین بازدهی که اجازه داده میشود به صورت Real Time دستورات را زمانبندی کند که نتیجه آن افزایش کارایی تراشه گرافیکی است.

در حالت تئوری میتوان گفت زمانبندی سخت افزاری (Hardware Scheduling) بسیار بهتر از زمانبندی نرم افزاری (Software Scheduling) است. اما تحقیقات محققان انویدیا نتیجه دیگری را نشان داده است. نتیجه ای که در نسل دوم معماری ماکسول به شدت مورد استفاده قرار گرفته است. در ادامه به بررسی این نتیجه و تحقیق میپردازیم.

شبیه سازی زمانبندی در تحقیقات انویدیا

تحقیقات و شبیه سازی های معماری اخیر انودیا نشان  داده که HW Scheduling مصرف انرژی زیادی در قبال فواید کمتر را به همراه دارد. به طور خاص چون Pipeline Math های  معماری کپلر دارای تاخیر های ثابتی هستند، (نسبت به نسل قبل Execution Unit ها در نصف فرکانس کار میکنند پس عملاً این تاخیر موجه است) بنابراین وجود زمانبندی سخت افزاری (HW Scheduling) در سیستم warp ها یا همان ریسمان ها عملاً کار اضافه ای است. چون کامپایلر تراشه میداند زمان تاخیر صدور هر دستور العمل محاسباتی چه قدر است.

به همین دلیل انویدیا تصمیم گرفت به جای زمان بندی های پیچیده سخت افزاری (complex scheduler) آنها را با زمان بندی های ساده ای که هنوز از Scoreboarding و دیگر روش های زمان بندی داخلی ورپ ها استفاده میکردند جایگزین کند. به بیانی ساده تر، زمان بندی ورپ ها توسط کامپایلر به معنای برگشت انویدیا به سیستم زمان بندی قدیمی Static Scheduling محسوب میشد.

توضیح اینکه روش زمانبندی SW Scheduling در برابر HW Scheduling با تمام ویژگی های مفیدش موجب میشود تراشه در مقابله با محاسبات پیچیده برنامه های کاربردی ناتوان باشد که در بالا هم به آن اشاره کردیم. به همین دلیل بود که انویدیا در معماری فرمی با استفاده از Static Scheduling تراشه های مخصوصی برای محسابات (Compute) و پردازش های GPGPU طراحی کرده بود و AMD هم برای عقب نماندن از این قافله با معماری GCN و استفاده از روش HW Scheduling به جنگ انویدیا رفت که البته خیلی هم موفق نشد.

روش زمانبندی SW Scheduling در صورتی که کامپایلر عملکرد مناسبی داشته باشد میتواند به انقلابی عالی در زمینه پردازش محاسبات منجر شود. انویدیا با حرکت به سمت روش زمانبندی SW Scheduling پردازش های GPGPU را هم هدف گرفته و نسل دوم معماری ماکسول نشان میدهد که انویدیا در این راه موفق بوده است. همانطور که در ابتدای مقاله هم گفته بودیم، کپلر GK104 از سه برابر هسته بیشتر به نسبت هسته های GTX 580 استفاده میکند، اما قدرت هسته عملاً به صورت خطی افزایش پیدا نکردند. بنابراین این پتانسیل وجود دارد که در صورت بهینه شدن هسته ها، با افزایش بازدهی بسیار بیشتری مواجه شویم.

مقایسه GK110 و GF114 از دید پردازنده های چند کاره

در صفحه قبلی دو سیلیکون ۱۰۴ و ۲۰۴ را مقایسه کردیم و در این بررسی هم یکی دیگر از سیلیکون های قدرتمند سری کپلر یعنی GK110 را با GF114 مقایسه میکنیم. به تصویر زیر که شمایی از یک SM در GF104/114 هست نگاهی بیندازید:

همانطور که قبلاً  گفتیم، سیستم SM موجود در هسته های GF104 با توجه به اینکه از روش ILP توسط HW scheduling چک میشوند، برخلاف GK104 که از طریق نرم افزار و کامپایلر با جدول زمانبندی به صورت ثابت در ارتباط اند. بنابر این نمیتوانیم بخش Front End های موجود در این تراشه را مستقیماً به GF114 تامیم دهیم. با این حال باز هم مناسب تر از GF100 است. در این SM منابع عملیاتی اجرایی تراشه به ۳ گروه ۱۶ واحدی هسته های کودا تقسیم شدند که فقط یکی از آنها قابلیت اجرای دستورات Fp64 را دارد. ۷ گروه تابع دیگر معماری را در زیر میتوانید ببینید:

۱۶ CUDA cores (#1)i
۱۶ CUDA cores (#2)i
۱۶ CUDA cores, FP64 capable (#3)i
۱۶ Load/Store Units
۱۶ Interpolation SFUs (not on NVIDIA’s diagrams)i
۸ Special Function SFUs
۸ Texture Units

حال به شمایی از یک SMX در GK104 بهتره نگاهی بندازیم:

برخلاف نسل پیش که تنها ۷ بخش اجرایی عملیاتی تابعی Functional Units وجود داشت، در SMX کپلر شاهد ۱۵ بخش Functional Units یا همان توابع عملیاتی هستیم. به این معنا که زمان بند ریسمان ها Warp Cheduler ها میتواند ۱۵ بخش از Functional Units ها را فراخوانی کنند. در واقع دو برابر شدن توابع و منابع اجرایی  کپلر GK104 به نسبت GF104/114 های نسل قبل موجب شده انویدیا بتواند بدون هیچ مشکلی Shader clock های موجود در معماری را حذف کند.

وظیفه Shader clock ها در نسل GF104/114 افزایش منابع اجرایی و توابع عملیاتی در معماری تراشه گرافیکی بود که با این تغییر این مشکل نیز برای همیشه رفع شد. توابع عملیاتی (Functional Units) تراشه GK104 را در زیر ببینید:
۳۲ CUDA cores (#2)i
۳۲ CUDA cores (#3)i
۳۲ CUDA cores (#4)i
۳۲ CUDA cores (#5)i
۳۲ CUDA cores (#6)i
۱۶ Load/Store Units (#1)i
۱۶ Load/Store Units (#2)i
۱۶ Interpolation SFUs (#1)i
۱۶ Interpolation SFUs (#2)i
۱۶ Special Function SFUs (#1)i
۱۶ Special Function SFUs (#2)i
۸ Texture Units (#1)i
۸ Texture Units (#2)i
۸ CUDA FP64 cores

اگر به SMX دقت کنید ۴ زمان بند ریسمان (Warp Schedulers) میبینید که میتواند در هر سیکل ساعت ۲ دستور العمل را در صورت احراز شرایط ILP  (منظور Instruction Level Parallelism است که در آن وابستگی دستورات بر اساس اصل Superscalar چک میشود که یکی از وظایف HW/SW Dependency Checking میباشد) را فراخوانی کنند. بدین معنا که اگر تمام شرایط ILP بر قرار باشد، هر ۴ زمان بندی میتواند ۸ دستورالعمل I-Set Catch را برای ریسمان سازی فراخوانی کنند و مجدداً همان ها را به توابع اجرایی ارسال کنند.

در GK 104 تعداد واحدهای بافت زنی (Texture Unite) به نسبت نسل قبلش دو برابر شده و برای کل تراشه از ۶۴ واحد در نسل قبلی به ۱۲۸ واحد در نسل فعلی رسیده که عملاً خیلی بیشتر از ظرفیت FFU هایی است که باید روال Graphic Pipline را در تراشه اعمال کنند. توجه کندی که منظور از کم بودن FFU ها کم بودن تعداد SM ها است و هر FFU شامل همان Poly Morph انجین هایی است که به ازای هر SM فقط ۱ عدد از آنها وجود دارد. این مورد را در صفحه سوم توضیح دادیم.

به همین دلیل انویدیا سیستم جدیدی را برای واحدهای بافت زنی معرفی کرد که Bindless Textures نام داشت. واحد جدیدی که وظیفه آن تغذیه کامل واحدهای بافت زنی معماری های جدید انویدیا است.

در گذشته و نسل های پیش از کپلر هر SM میتوانست ۱۲۸ عدد واحد بافت زنی را هزمان برای انجام اعمال Graphic Pipline تجمیع کند، اما در روش جدید تراشه فقط میتواند در طول Shader Code ها هر مقدار بافت(بالغ بر ۱ میلیون بافت) را به صورت همزمان ایجاد کند. به قول BSN این مورد یکی از کلیدی ترین دلایلی بود که دموی عظیم Samaritan تنها بر روی یک کارت انویدیا به صورت تریلر تکنیکی به نمایش درآمد.

ما پیش از این در سایت مطالب مفصلی راجع به تریلر تکنیکی سامارتین و موتور آن یعنی Unreal Engine 4 منتشر کردیم که برای مشاهد آنها میتوانید روی «بررسی اجمالی تریلر های تکنیکی موتور Unreal Engine 4» و «با موتور بازی سازی Unreal Engine 4 آشنا شوید» کلیک کنید. همچنین مجموعه ای از چند تریلر تکنیکی قدرتمند از این موتور را گردآوری کردیم که با جستجو درسایت میتوانید میتوانید آنها راببینید.

کمپانی AMD هم در مقابل از سیستم جدید به نام Partially Resident Textures, i.e. MegaTexturing technology با رهبری جان کارمک (JOHN CARMACK) کبیر برای موتور های OpenGL خودش بهره برداری کرد که به نظر Bsn در جای خودش محترم هست اما در برابر سیستم جدید انودیا قدرت چندانی ندارد. مقایسه دو تراشه را در شکل زیر ببینید:

ت ۹

تفاوت ها مشخص است و نیازی به تکرار مکررات نیست. تنها نکته قابل عرض در سطح SM ها، وجود نسل دوم FFU های انودیا برای DX11 یعنی Plymorph Engine 2 است که انویدیا این بخش را برای تراشه های جدید از اول بهینه سازی کرده و همین مورد را در نسل دوم معماری ماکسول به صورتی جدیدتر و بهینه تر میبینیم.

موتور polymorph Engine چیست!؟

PolyMorph Engine یک موتور پردازش گرافیکی است که از پنج بخش مهم Vertex Fetch، Tessellation، Iewport Transform، Attribute Setup و Stream Output تشکیل شده است. این موتور گرافیکی در نسل دوم معماری ماکسول از دو برابر واحدهای Streaming Multi Processor بیشتری به نسبت GM104 استفاده میکند و در واقع قدرتی دو برابر بیشتر از GM104 دارد. در GM104 از نسل دوم این موتور استفاده شده و در GM204 از سویمن نسل اینموتور با بهینه سازی های زیاد استفاده شده است.

کار این بخش ها بدین صورت است که پس از پردازش اولیه تصاویر گرافیکی، نتیجه نهایی هر بخش به یک Streaming Multi Processor فرستاده میشود. اما در صورتی که به این بخش نرود در بخش دیگری به نام Shader Program اجرا میشوند و سپس برای پردازش جلوه های گرافیکی به سایر بخش های PolyMorph Engine فرستاده میشوند. پس از پایان پردازش های لازم روی جلوه های ویژه گرافیکی، نتایج به Raster Engine ها فرستاده میشود.

انودیا سعی کرده با نسل دوم این موتور نیاز اساسی ۳-۴ برابر شدن هسته های هر SM را برای پوشش روال Graphic Pipline فراهم کند. بنابر این این بخش از تراشه هنوز ۵ مرحله Graphic Pipline دارد. یعنی از مرحله Vertex Fetch تا مرحله Stream Output که هر یک از این مراحل توسط هسته های پردازشی SMX پردازش و توسط این Stage ها مرتبط میشوند. در واقع تفاوت اصلی این نسل از Polymorph Enginde ها با نسل گذشته افزایش شدید بازدهی جریان داده Data Stream Efficiency است.

به بیا دیگر نرخ مقادیر اولیه توان عملیاتی (Throughput داده ها (Primitive Rates) در نسل جدید بالغ بر ۲ برابر نسل پیش است که اجازه میدهد Data Through Put های درون هسته ها تا ۴ برابر نسل پیش افزایش پیدا کنند و عملاً کارایی آنها فقط در فناوری مهمی همچون تسلیشن (Tessellation) به چهار برابر نسل فرمی برسد که پیشرفت بزرگ و مهمی در زمینه بهینه سازی معماری های گرافیکی مسحوب میشود. تا زمان عرضه کپلر انویدیا ادعا میکرد بزرگترین نرخ تبادل داده مربوط به معماری خودش است.

در واقع بدون کنترلر حافظه کارآمد، هیچ تراشه ای موفق نیست. این مهم نیست که تراشه شما چقدر سریع باشد، مهم این است که هسته های اجرایی شما گرسنه نمانند. برخلاف پردازنده ها میتوان گفت که کنترلر حافظ یکی از مهمترین بخش های تراشه های گرافیکی «GPU» محسوب میشوند. آنها بدون سرعت کافی Catch Hirarchy نمیتوانند روال خودشان را همگام با سرعت بالای هسته ها پیش ببرند، بنابراین هسته ها دچار معضل گرسنگی میشوند.

سخن پایانی

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

بررسی فوق برگرفته از منابعی همچون bsn, annadtech, hardwarecanucks, hexus و بیوند ۳دی به همراه تحلیل و توضیح و تست اختصاصی مدار سنتز تراشه از خودمان بود تا بررسی کامل و جامعی بر دو معماری قبل از ماکسول ۲ را خدمت شما عزیزان ارائه کنیم.

خروج از نسخه موبایل