مراجعة البطاقة الرسومية XFX R7970 Core Edition 3G

– معمارية VLIW5 القديمة

كما أشرنا في مقدمة المقال فالسبب الرئيسي لقيام AMD بالتخلي عن معماريتها الشهيرة VLIW هو تحسين أداء المعالج الرسومي في تطبيقات الحوسبة العامة كخطوة في طريق الدمج بين المعالج المركزي والرسومي Fusion، مما يجعل البعض يتساءل؟ وما العيب في المعمارية القديمة وهل هي لا تستطيع الوفاء بهذا الدور؟ للإجابة على هذه التساؤلات سنحتاج للخوض قليلاً في معمارية VLIW لنفهم طريقة عملها و بالتالي نتفهم سبب AMD في التخلي عنها مقابل GCN.

منذ صدور المعالجات الرسومية الداعمة لمكتبة DirectX9 ، كانت التطبيقات الرسومية تعتمد بشكل أساسي على حساب أربع قيم منطقية أو متجهه Vector (مثل XYZW أو RGBA) و قيمة خاصة أو Scalar (مثل الجيب أو الإضاءة)، واستخدمت AMD معمارية VLIW في معالجاتها الرسومية لأنها كانت فعالة جداً في هذا الوقت مع التطبيقات الرسومية، لكن مع صدور مكتبة DirectX10 و مفهوم Unified Shaders (المظلل المعياري يقوم بكافة العمليات الحسابية بدل من معالجات مخصصة لكل من Vertexs, Pixlels) لم تقم الشركة بتغيير  طريقتها ولكنها قامت بتطويع معمارية VLIW لتناسب المفهوم الجديد عن طريق دمج خمس وحدات حسابية Arithmetic and Logic Unitأو ALUs كما الحال في معظم بطاقات AMD أو أربع وحدات كما في عائلة بطاقات HD 6900 لتكون Streaming Processor و الذي يعتبر مظلل معياري Unified Shaders بكامل وظيفته، لكن هذة الوحدات ALUs بمفردها لا تستطيع تأدية وظيفة المظلل المعياري بشكل كامل.

تعتمد الفكرة الأساسية لمعمارية VLIW على تقسيم المهام Tasks إلي مجموعة من الحزم تسمى Wavefront كل منها يحتوي على 64 قيمة / نقطة و مجموعة من التعليمات Instructions ليتم معالجتها داخل Streaming Processors أي أنها تعتمد على مبدأ الحوسبة المتوازية لكن على مستوى التعليمة – لنتذكر هذه الفقرة جيداً.

من التقديم السابق نجد أن معمارية AMD تحتاج لتقسيم المهمات Tasks الي مجموعة من حزم تتكون من بيانات وتعليمات ليتم معالجتها داخل Streaming Processor و هنا (مربط الفرس كما يقال)، هذا التقسيم يتم عن طريق برنامج القيادة الخاص بالبطاقت الرسومية حيث يقوم هو بتقسيم العمل وتوزيعه على وحدات المعالجة Streaming Processor وهذه هي أول نقاط ضعف المعمارية السابقة، ثاني نقاط الضعف هي طبيعة البيانات و التعليمات فحتى تعمل معمارية VLIW بشكل كامل وفعال يجب أن تكون البيانات و التعليمات المرسلة للمعالجة مثالية لبنيتها أي تكون تعليمات متماثلة و مستقلة، لأن عدم توافر هذا الشرط يقلل بشكل كبير من فاعلية المعمارية و يهدر الكثير من طاقة البطاقة بسبب وجود بعض الوحدات المعطلة عن العمل.

كما ذكرنا فأن تقسيم التعليمات يتم عن طريق برنامج القيادة للبطاقات وينشأ هذا بسبب العديد من المشاكل و نقاط الأختناق (كما هو  واضح من الصورة السابقة) لأنه مهما بلغت درجة كفاءة برنامج القيادة وجودته ستظل قدرته ضعيفة و محدودة تجاه تجزئة وتوزيع التعليمات بشكل فعال وديناميكي – لأن هذا يتم بعيداً عن مستوى العتاد، كما أنه على مستوى التطبيقات يجب أن يكون برنامج القيادة متلائم مع كل البرامج والتطبيقات التي قد يتم إستخدام المعالج الرسومي عليها وهذا أمر صعب جدا و شبه مستحيل من التطبيق العملي.

ربما لم تواجه معمارية VLIW هذه الصعوبات بشكل كبير على مستوى التطبيقات الرسومية والألعاب بسبب طبيعة بياناتها الملائمة لطريقة عمل المعمارية بشكل كبير، وهذا واضح من نجاح بطاقات AMD الرسومية خاصة الجيل HD 5000 و الجيل HD 6000، لكنه على مستوى تطبيقات الحوسبة العامة تظهر صعوبة بالغة جداً في تنفيذ التعليمات والمهام الخاصة بها عن طريق برنامج القيادة لأنه يؤدي لفقد طاقة حوسبية كبيرة و يُصعب من مهمة المبرمجين في كتابة البرامج لأنها يجب بأن تتوافق مع برنامج القيادة و هذا أمر من الصعب تنفيذه على أرض الواقع حيث أن المبرمجين يكتبون البرامج لتستخدم بشكل عام على عدة أنواع من العتاد لذا يحتاجون لمعايير موحدة للتعامل مع العتاد في أكواد البرامج و هذا يمثل مشكلة بالنسبة لمعمارية VLIW لإعتمادها على برنامج القيادة بدلاً من عتاد خاص بالتوزيع كما في معالجات Nvidia.

أضف تعليقاً

لن يتم نشر عنوان بريدك الإلكتروني. الحقول الإلزامية مشار إليها بـ *