نظرة عامة موجزة عن Vulkan API

إذن ، ما هي الصفقة الكبيرة مع Vulkan API الجديدة على أي حال ، ولماذا يجب أن نهتم؟

ها هي Vulkan API في مائة كلمة أو أقل: إنها واجهة برمجة تطبيقات منخفضة التكلفة وقريبة من المعدن للرسومات ثلاثية الأبعاد وتطبيقات الحوسبة. Vulkan هو في الأساس تابع لبرنامج OpenGL. كان يشار إليها في الأصل باسم "مبادرة الجيل التالي من OpenGL" ، وهي تتضمن عددًا قليلاً من البتات والقطع من Mantle API من AMD. من المفترض أن تقدم Vulkan مزايا عديدة على واجهات برمجة التطبيقات GPU الأخرى ، مما يتيح دعمًا فائقًا عبر الأنظمة الأساسية ، ودعمًا أفضل للمعالجات متعددة مؤشرات الترابط ، وحمل أقل لوحدة المعالجة المركزية ، وقليلًا من حيادية نظام التشغيل. كما يجب أن يجعل تطوير السائق أسهل ، ويسمح بالتجميع المسبق للسائقين ، بما في ذلك استخدام أدوات التظليل المكتوبة بلغات مختلفة.

هذه 93 كلمة ، لذا إذا لم تكن مهتمًا ، يمكنك تخطي 3500 كلمة التالية. من ناحية أخرى ، إذا كنت تريد معرفة المزيد عن واجهة برمجة تطبيقات الرسومات القادمة التي ستكون معنا لسنوات قادمة ، فسأبدأ في الأساسيات.

كيف ظهرت Vulkan API في الوجود

تم الإعلان عن Vulkan في الأصل من قبل مجموعة Khronos Group في مارس 2015 ، مع تاريخ إطلاق مبدئي محدد في أواخر عام 2015. في حال لم تكن على دراية بـ Khronos ، فهو اتحاد صناعي غير هادف للربح تأسس قبل خمسة عشر عامًا من قبل بعض أكبر الأسماء في صناعة الرسومات ، بما في ذلك ATI (أصبحت الآن جزءًا من AMD) و Nvidia و Intel و Silicon Graphics و Discrete و Sun Microsystems. حتى إذا لم تكن قد سمعت عن Khronos ، فمن المحتمل أنك سمعت عن بعض معاييرها ، مثل: OpenGL و OpenGL ES و WebGL و OpenCL و SPIR و SYCL و WebCL و OpenVX و EGL و OpenMAX و OpenVG و OpenSL ES و StreamInput و COLLADA و glTF.

الآن ، ربما تفكر في "آه ، هؤلاء الرجال" ، لذا يمكنني تخطي بقية المقدمة والتركيز على واجهة برمجة التطبيقات نفسها.

على عكس سابقتها ، أو سابقاتها ، تم تصميم Vulkan من الألف إلى الياء للعمل على منصات متنوعة ، بدءًا من الهواتف المحمولة والأجهزة اللوحية ، إلى وحدات التحكم في الألعاب وأجهزة الكمبيوتر المكتبية المتطورة. يتألف التصميم الأساسي لواجهة برمجة التطبيقات من طبقات ، أو ينبغي أن نقول نمطيًا ، لذلك فهو يتيح إنشاء بنية مشتركة قابلة للتوسيع للتحقق من صحة التعليمات البرمجية وتصحيح الأخطاء والتنميط ، دون التأثير على الأداء. يدعي Krhonos أن النهج متعدد الطبقات سيوفر قدرًا أكبر من المرونة ، ويحفز الابتكار القوي في أدوات GPU متعددة البائعين ، ويوفر تحكمًا مباشرًا في GPU تتطلبه محركات الألعاب المتطورة.

الآن ، أفهم أن الكثير من عشاق التكنولوجيا لديهم تحفظاتهم حول مصطلحات التسويق مثل "مرن" و "قابل للتوسيع" و "معياري" ، لكن هذه المرة نتعامل مع ماكوي الحقيقي. في الواقع ، هذه هي الفكرة الأساسية وراء Vulkan: تم تصورها كواجهة برمجة تطبيقات للجماهير ، من ألعاب الأطفال على الهواتف الذكية ، إلى آبائهم الذين يصممون المباني والألعاب على محطات العمل.

من الناحية النظرية ، يمكن استخدام Vulkan في أجهزة الحوسبة المتوازية ، للتحكم في عشرات المليارات من نوى GPU ، في الأجهزة الصغيرة القابلة للارتداء وطائرات بدون طيار ، والطابعات ثلاثية الأبعاد ، والسيارات ، ومجموعة أدوات الواقع الافتراضي ، وأي شيء آخر يحتوي على وحدة معالجة رسومات متوافقة بالداخل.

لمزيد من التفاصيل ، أقترح عليك إلقاء نظرة على نظرة عامة على Vulkan الرسمية في ملف PDF.

AMD Mantle DNA

إذا كان نهج الاقتراب من المعدن يبدو مألوفًا بشكل غريب ، فربما تكون قد تابعت إعلانات وحدة معالجة الرسومات AMD على مدار العامين الماضيين أو نحو ذلك. فاجأت AMD مراقبي الصناعة عندما أعلنت عن Mantle API في عام 2013 ، وفاجأتهم مرة أخرى عندما قررت سحب القابس على API ، معلنة في مارس 2015 أنها لن تصدر Mantle 1.0 كحزمة SDK عامة. باختصار ، وعد Mantle بتقديم تحسينات كبيرة في الأداء والكفاءة في بعض المواقف ، خاصة على واجهة وحدة المعالجة المركزية نظرًا لأنه سيقلل من تكاليف المعالجة. بدت فكرة جيدة ، حيث يمكن للاعبين تجميع أجهزة كمبيوتر مخصصة مع معالجات أبطأ إلى حد ما واستثمار المزيد من الأموال في بطاقات الرسومات من الدرجة الأولى. بدا الأمر مناسبًا جدًا لـ AMD أيضًا ، لأن الشركة لم يكن لديها وحدة معالجة مركزية متطورة تنافسية منذ سنوات ، على الرغم من أنها لا تزال تمتلك منتجات GPU جيدة.

بينما اجتمع معجبو AMD الباكين حدادًا على وفاة منقذهم ، تم إحياء Mantle بأعجوبة. جاءت الأخبار السارة في شكل مشاركة مدونة ، صاغها رجا كودوري ، نائب رئيس AMD للحوسبة المرئية والإدراكية. من قبيل الصدفة ، تماشياً مع الموضوع الديني ، أقام كودوري في إحدى المناسبات خطبة على جبل ، خلال حدث إطلاق AMD في هاواي في عام 2013 ، لكني استطعت.

وبغض النظر عن المزاح ، قام فريق كودوري بعمل جيد. بينما لم يصبح Mantle معيارًا صناعيًا جديدًا ، فقد أصبح أساسًا لـ Vulkan. الاختلاف الأكبر هو أن Vulkan لن يقتصر على أجهزة AMD GCN ؛ ستعمل على الكثير من وحدات معالجة الرسومات من بائعين مختلفين. ربما يمكنك أن ترى إلى أين أذهب مع هذا ؛ من الأفضل قليلاً أن يكون لديك واجهة برمجة تطبيقات رسومية واحدة منخفضة التكلفة تعمل على أنظمة تشغيل وأنظمة أجهزة مختلفة بدلاً من امتلاك واجهات برمجة تطبيقات مملوكة لبنى GPU وأنظمة تشغيل مختلفة وما إلى ذلك.

تأخذ Vulkan API جزءًا كبيرًا من فطيرة Mantle وتشاركها مع الجميع ، بغض النظر عن نظام التشغيل أو الأجهزة أو العرق أو الدين.

أوه ، وهناك شيء آخر: أجبر Mantle في النهاية Microsoft و Khronos أخيرًا على فعل شيء حيال DirectX و OpenGL bloat وعدم الكفاءة. لقد كانت ركلة لطيفة وودية في المؤخرة ، أو "badonkadonk" ، كما يحب أحد زملائه Toptaler وصفها.

كيف يقارن Vulkan بـ OpenGL؟

من الواضح أنني بحاجة إلى تحديد الاختلافات الأساسية بين Vulkan و OpenGL. توصل Khronos إلى رسم توضيحي بسيط يوضح مقدار سخام السائق الذي يمكن التخلص منه باستخدام واجهة برمجة التطبيقات الجديدة.

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

لكن انتظر ، أليس هذا مجرد تفريغ المزيد من العمل لمطوري الألعاب؟ بالتأكيد ، سيكونون قادرين على استخدام الأجهزة بشكل أكثر كفاءة ، ولكن ماذا عن ساعات العمل الخاصة بهم؟ هذا هو المكان الذي يدخل فيه نهج النظام البيئي متعدد الطبقات في المعركة.

سيتمكن المطورون من اختيار ثلاثة مستويات أو مستويات مختلفة من نظام Vulkan البيئي.

• استخدم Vulkan مباشرة لتحقيق أقصى قدر من المرونة والتحكم.
• استخدم مكتبات وطبقات Vulkan لتسريع التطوير.
• استخدم Vulkan عبر محركات ألعاب جاهزة محسّنة بالكامل عبر واجهة برمجة التطبيقات الجديدة.

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

ربما يكون الخيار الأخير هو الأكثر إغراءً لأن الرفع الثقيل تم بواسطة شركات صناعية ثقيلة مثل Unity و Oxide و Blizzard و Epic و EA و Valve وغيرها.

هنا جدول OpenGL مقابل Vulkan سريع:

بصراحة ، لا أعتقد أنه من العدل المقارنة بين الاثنين. Vulkan هو مشتق من Mantle ، في حين أن OpenGL هو أحد الصناع مع 20 عامًا من الأمتعة. من المفترض أن يتخلى فولكان عن الكثير من الأشياء القديمة ؛ هذا هو بيت القصيد. من المفترض أن يقوم Vulkan بتبسيط الاختبار والتنفيذ ، وجعل السائقين أصغر حجماً ، وتحسين إمكانية نقل برنامج shader عبر لغة SPIR-V الوسيطة.

هذا يقودنا إلى السؤال التالي. ماذا يعني Vulkan حقًا للمطورين؟

من المتوقع أن يقوم SPIR-V بتحويل نظام اللغة الإيكولوجي

إذن ، أين يأتي دور SPIR-V ، وماذا يحدث لـ GLSL القديمة الجيدة؟

ستبقى GSLS على قيد الحياة في الوقت الحالي ، وستكون أول لغة تظليل مدعومة من قبل Vulkan. سوف يقوم مترجم GLSL إلى SPIR-V بالرفع الثقيل ، وفويلا! ، ستحصل على SPIR-V جاهزًا لإطعام وقت تشغيل Vulkan الجائع. سيكون مطورو اللعبة قادرين على استخدام نهايات SPIR-V و Vulkan الخلفية ، وربما يعتمدون على الواجهات الأمامية للمجمع مفتوح المصدر. بالإضافة إلى GLSL ، يمكن لـ Vulkan دعم نواة OpenCL C ، بينما يتقدم العمل على إضافة دعم لـ C ++. اللغات والأطر والأدوات المستقبلية الخاصة بالمجال هي خيار آخر. يذكر Khronos إمكانية تطوير لغات تجريبية جديدة.

مهما كان ما يختار المطورون القيام به ، فإن جميع الطرق تؤدي إلى Vulkan ، عبر SPIR-V ، ثم إلى العديد من الأجهزة المختلفة.

من المفترض أن يعمل SPIR-V على تحسين قابلية النقل بثلاث طرق:

• أدوات مشتركة
• مجموعة أدوات واحدة ل ISV واحد
• بساطة

نظرًا لأنه لن تكون هناك حاجة إلى أن تتميز كل منصة أجهزة بمترجم لغة عالي المستوى ، فسوف يتعامل المطورون مع عدد أقل منهم.

يمكن لـ ISV الفردي إنشاء SPIR-V باستخدام مجموعة أدوات واحدة ، وبالتالي القضاء على مشكلات قابلية النقل للغة عالية المستوى.

تعد SPIR-V أبسط من لغة نموذجية عالية المستوى ، مما يجعل التنفيذ والمعالجة أسهل.

سيتم تحسين الأداء بعدة طرق ، اعتمادًا على كيفية تنفيذ Vulkan:

• لا مزيد من الواجهة الأمامية للمترجم ، يمكن إجراء الكثير من المعالجة في وضع عدم الاتصال
• يمكن تسوية تصاريح التحسين بشكل أسرع ، ويتم تنفيذ التحسينات في وضع عدم الاتصال
• يتم تقليل تظليل المصادر المتعددة إلى نفس دفق تعليمات اللغة الوسيطة

لم يحدد Khronos أي أرقام أداء ويلاحظ أن "المسافة المقطوعة بالأميال ستختلف بالتأكيد". سيعتمد كل هذا على كيفية استخدام Vulkan. إذا كنت ترغب في التحقق من التفاصيل الدقيقة ، فتأكد من إطلاعك على الورقة البيضاء SPIR-V.

Vulkan تبدو واعدة من منظور المطور

لقد حددت عددًا من الميزات التي من شأنها أن تجعل Vulkan و SPIR-V شائعين في مجتمع التطوير ، ويحرص Khronos على إيصال هذه النقطة أيضًا. يبدو أن احتمال استخدام نفس الأدوات والمهارات للتطوير لمنصات متعددة مثير للفضول ، خاصة الآن بعد إغلاق فجوة الأداء بين مختلف المنصات.

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

يوضح Khronos المزايا التالية التي أتاحتها SPIR-V:

• يمكن للمطورين استخدام نفس برنامج التحويل البرمجي للواجهة الأمامية عبر أنظمة أساسية متعددة للتخلص من مشكلات قابلية النقل بين البائعين
• سيتم تقليل وقت تجميع وقت التشغيل shader / kernel نظرًا لأن السائق يجب عليه فقط معالجة SPIR-V
• لا يتعين على المطورين توزيع كود مصدر shader / kernel ، لذلك يتمتعون بمستوى إضافي من حماية IP
• تعد برامج التشغيل أبسط وأكثر موثوقية نظرًا لعدم وجود حاجة لتضمين برامج التحويل البرمجي للواجهة الأمامية
• يمتلك المطورون صورة أفضل لتخصيص الذاكرة ويمكنهم تعديل نهج تخصيص الذاكرة وفقًا لذلك

أنا متأكد من أنك ستوافق على أن هذا يبدو جيدًا ، ولكن لا يزال هناك طريق طويل لنقطعه.

فولكان: إنه يعمل ، لكنه عمل مستمر

كما قلت ، لا يزال Vulkan إلى حد كبير قيد التنفيذ ، ويجب أن يكون لدينا المواصفات الكاملة بحلول نهاية العام. ومع ذلك ، مما رأيناه حتى الآن ، يمكن لواجهة برمجة التطبيقات الجديدة أن تطلق الكثير من الأداء حتى مع أجهزة الجيل الحالي.

أفضل رسم توضيحي لـ Vulkan رأيته حتى الآن يأتي من Imagination Technologies ، واحدة من تجهيزات GPU المحمولة الرائدة الموجودة هناك. يتم استخدام Imagination Technologies GPU IP في جميع أدوات iOS ، جنبًا إلى جنب مع العديد من تصميمات System-on-Chip الأخرى المستندة إلى ARM ، وحتى في بعض شرائح Intel x86 منخفضة الجهد.

نشرت Imagination الأسبوع الماضي منشورًا على مدونة يوضح بالتفصيل مكاسب الأداء التي حققها Vulkan. كان اختياره للأجهزة غير عادي إلى حد ما: Google Nexus Player ، استنادًا إلى معالج Intel رباعي النواة نادر الاستخدام مع وحدة معالجة الرسومات PowerVR G6430. تم اختبار الجهاز باستخدام أحدث برنامج تشغيل Vulkan API لوحدات معالجة الرسومات PowerVR ، بينما تم إجراء التشغيل المرجعي على OpenGL ES 3.0. كانت فجوة الأداء مذهلة.

يتضمن المشهد إجمالي 400000 كائن ، بمستويات مختلفة من التفاصيل ، تتراوح من 13000 إلى 300 رأس. تُظهر اللقطة الواسعة ما يقدر بمليون مثلثات ، وبعضها ألفا على النباتات وحوالي عشرة مواد مختلفة للتماثيل والنباتات. يستخدم كل نوع كائن تظليلًا مختلفًا ولا يتم تثبيت التماثيل ، ويمكن أن تكون كل استدعاء رسم كائنًا مختلفًا تمامًا ، مع مواد مختلفة ، ولكن النتيجة النهائية ستكون متشابهة.

ومع ذلك ، هناك تحذير كبير: هذا ليس نوع تعزيز الأداء الذي يمكن أن تتوقعه في الحياة الواقعية. استخدم فريق Imagination Technologies سيناريو مبالغًا فيه لتسليط الضوء على تفوق Vulkan ، لدفعه إلى أقصى حدوده ، وفي هذا السيناريو بالذات ، يكون الحد لصالح Vulkan مقابل OpenGL ES. أيضًا ، ضع في اعتبارك أن هذا الاختبار مرتبط بوحدة معالجة الرسومات ، لكنه لا يزال توضيحًا جيدًا لاستخدام Vulkan الفائق لوحدة المعالجة المركزية.

كيف تقلل Vulkan استخدام وحدة المعالجة المركزية؟

تذكر أن جدول OpenGL مقابل Vulkan كان لدينا سابقًا ، أو لنكون أكثر تحديدًا ، بت عرض التجانب هذا؟ ربما لا ، لذا ها هي باختصار: استخدمت Imagination Vulkan لتجميع مكالمات السحب في البلاط وتقديم بلاطة في وقت واحد. اعتمادًا على مكان وجود المربع في اللحظة التي يتم فيها عرض الإطار ، يمكن أن يظهر أو يخرج عن العرض ، ويغير مستوى التفاصيل ، وما إلى ذلك. في OpenGL ES ، تكون جميع مكالمات السحب ديناميكية ، ويتم إرسالها مع كل إطار ، وفقًا لما هو موجود في مجال الرؤية. لا يمكن تخزين مكالمات الرسم التي تم تنفيذها بالفعل مؤقتًا.

نتيجة لذلك ، يحتاج برنامج OpenGL ES إلى العديد من المكالمات في وضع kernel لتغيير حالة برنامج التشغيل والتحقق من صحتها. لا يعتمد Vulkan على الأوامر التي تم إنشاؤها مسبقًا (المخازن المؤقتة للأوامر) لتقليل حمل وحدة المعالجة المركزية والقضاء على الحاجة إلى التحقق من الصحة أو التحويل البرمجي أثناء حلقة العرض. وصف فريق Imagination القدرة على إعادة استخدام مخازن الأوامر المؤقتة بأنها "مفيدة في بعض الظروف" ، ويمكن استخدامها "إلى حد كبير" في العديد من الألعاب والتطبيقات.

المغير الثاني للعبة هو توليد المخزن المؤقت المتوازي ، والذي يمكّن Vulkan من تسخير قوة جميع أنوية وحدة المعالجة المركزية. تم تصميم OpenGL ES قبل ظهور رقائق الهاتف المحمول متعددة النواة ، ولكن على مدار السنوات الثلاث الماضية ، انتقلت الصناعة من اثنين ، إلى أربعة ، إلى ثمانية وعشرة أنوية لوحدة المعالجة المركزية ، مع شرائح SoCs من السلسلة A من Apple و Nvidia Tegra المستندة إلى دنفر الرقائق باعتبارها الاستثناءات الوحيدة الملحوظة. لقد تحدثت عن اتجاهات SoC للجوال في إحدى مقالاتي السابقة في المدونة ، والتي تغطي مترجم Optimizing Android القادم ، حتى تتمكن من التحقق من ذلك للحصول على معلومات إضافية.

لنجرب تشبيهًا: إذا كان فولكان محرك احتراق داخلي ، فسيخزن ويعيد استخدام جزء من قوته ، بالطريقة نفسها التي يستخدمها الشاحن التوربيني والمبرد الداخلي (مخازن الأوامر) ، وسيكون قادرًا على استخدام أربعة ، ستة ، ثمانية أو حتى عشر أسطوانات مع عدم وجود خسارة في الكفاءة (توليد عازلة موازية). تبدو مقارنة Vulkan بـ OpenGL ES أشبه بمقارنة محرك توربو جديد صغير الحجم بمحرك قديم أحادي الأسطوانة على كأس جدك Triumph Trophy.

حسنًا ، على الأقل كان جدي هو الروك المناسب ، وليس مودًا.

والنتيجة النهائية هي بيئة أكثر كفاءة إلى حد كبير ، قادرة على استخدام جميع الأجهزة المتاحة بشكل جيد ، على عكس OpenGL ES ، الذي يرتبط بمعظم السيناريوهات بوحدة المعالجة المركزية. هذا يعني أن Vulkan يمكنها تقديم مستويات مماثلة من الأداء مع الحفاظ على وحدة المعالجة المركزية في ساعات أقل ، وبالتالي تقليل استهلاك الطاقة والاختناق.

الجوانب السلبية المحتملة لـ Vulkan API (تنبيه المفسد: لا يوجد الكثير)

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

• تمت إضافة تعقيد التعليمات البرمجية في سيناريوهات معينة
• حان وقت التسوق
• مستوى دعم الصناعة
• قد لا تكون Vulkan ذات صلة أو فعالة على بعض الأنظمة الأساسية (أجهزة الكمبيوتر المكتبية)
• إقناع المطورين باستخدام Vulkan على بعض الأنظمة الأساسية
• توافق محدود مع الأجهزة القديمة

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

يمثل الوقت المستغرق في السوق مصدر قلق آخر ، وكذلك تنفيذ Vulkan في التطبيقات والألعاب القديمة. لا يزال Vulkan معاينة فنية ؛ من المتوقع أن تكون المواصفات والتطبيقات الأولية متوقعة بحلول نهاية عام 2015 ، لذلك ، من الناحية الواقعية ، ربما لن نرى العديد من تطبيقات العالم الحقيقي قبل منتصف عام 2016.

لا ينبغي أن يكون دعم الصناعة مشكلة ؛ بعد كل شيء ، هذا هو معيار Khronos ، ولكن قد يستغرق بعض الوقت. هذا أحد الأسباب التي جعلتني أركز هذا المنشور على قطاع الهاتف المحمول ؛ تتطور برامج وأجهزة الهاتف المحمول بسرعة أكبر ، وقد يستغرق الأمر بضعة أرباع أخرى قبل أن نرى تأثير Vulkan على منصات سطح المكتب. هذه هي الطريقة التي تعمل بها الصناعة ، هناك الكثير من الأشياء التي يجب أن تقلق بشأنها في مكانة سطح المكتب: دعم التطبيقات الاحترافية ، وجحافل من اللاعبين الذين يستخدمون مذراة يتغلبون على كل إطار ممزق ، وما إلى ذلك. ومع ذلك ، فإن حقيقة أن فولكان مشتق من عباءة AMD أمر مشجع.

بينما يمكن لـ Vulkan فعل العجائب في إعداد مرتبط بوحدة المعالجة المركزية ، خاصة مع SoCs المحمولة متعددة النواة ، فإن مكاسب الأداء هذه ستكون محدودة على منصات سطح المكتب. تتعامل أجهزة سطح المكتب مع المعالجات متعددة النواة بمستوى أعلى من الكفاءة ، ومعظم التطبيقات التي تتطلب رسومًا بيانية مرتبطة بوحدة معالجة الرسومات.

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

قد يكون التوافق مع الأجهزة القديمة مصدر قلق آخر. سيحتاج Vulkan إلى أجهزة OpenGL ES 3.1 أو OpenGL 4.1 مصحوبة ببرامج تشغيل جديدة. على سبيل المثال ، يمكن لوحدات معالجة الرسومات PowerVR series 6 التابعة لشركة Imagination Technologies دعمها ، لكن السلسلة 5 لا يمكنها ذلك. تدعم سلسلة Adreno 400 من Qualcomm برنامج OpenGL ES 3.1 ، لكن السلسلة 300 لا تدعم ذلك. تدعم سلسلة Mali T600 و T700 من ARM برنامج OpenGL ES 3.1 ، لكن الدعم غير موجود في التصميمات الأقدم لسلسلة T400. لحسن الحظ ، بحلول الوقت الذي تصبح فيه Vulkan ذات صلة ، فإن معظم الأجهزة التي تحتوي على وحدات معالجة رسومات غير مدعومة ستكون خارج الصورة. وتشمل هذه الأجهزة iPhone 5 / 5C والجيل الرابع من أجهزة iPad و Samsung القائمة على شرائح Exynos من سلسلة 5000. قد لا تكون الأجهزة القائمة على Qualcomm محظوظة لأن وحدات معالجة الرسومات Adreno 300-series تُستخدم في تصميمات حديثة وغزيرة الإنتاج مثل Snapdragon 410 و Snapdragon 600 و Snapdragon 800 و 801. ومع ذلك ، أظن أن معظمها سيختفي بمرور الوقت يصبح Vulkan وثيق الصلة حقًا.

يعيش طويلا ويجعل

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

في نفس الوقت تقريبًا برامج التشغيل ومحركات الألعاب والألعاب المحسّنة من Vulkan ، سنحصل على أجهزة جديدة للعب بها ، ولا أقصد فقط تعديلات بسيطة على الأجهزة. توقف تطوير Mobile SoC لعدد من الأسباب التي لن أخوض فيها الآن ، ولكن 2016 سيكون عامًا كبيرًا بالنسبة للصناعة ، حيث أصبحت عقد FinFET 14 / 16nm متاحة لمزيد من الشركات المصنعة ، وأصبحت قابلة للتطبيق اقتصاديًا للأجهزة السائدة بدلاً من رقائق الرائد.

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