على مدى الخمسة عشر عامًا الماضية ، اتخذ تطور حوسبة GPU – والآن على نطاق أوسع ، أشكال مختلفة من الحوسبة المتوازية للغاية – مسارًا مثيرًا للاهتمام. في حين أن استخدام وحدات معالجة الرسومات على نطاق واسع كمسرعات للأغراض العامة كان متوقعًا على نطاق واسع وقد هبطت على الهدف بشكل كبير ، إلا أن كيفية وصولنا إلى هنا كانت مسارًا مثيرًا للاهتمام. لقد تعثر تقدم وحدة المعالجة المركزية ، وارتفعت البنى المتوازية وشهدت الشركات بأكملها وسقطت ، وأصبحت أقوى الحواسيب الفائقة في العالم الآن تضم وحدات معالجة الرسومات باعتبارها جوهر إنتاجها الحسابي ، ولم ير أحد ثورة التعلم العميقة القادمة حتى وصلت إلينا بالفعل.
من خلال الوقوف على هذا المشهد خلال معظم العقد ونصف العقد الماضيين مثل OpenCL ، إطار عمل Khronos المفتوح لبرمجة وحدات معالجة الرسوميات ومسرعات الحوسبة الأخرى. ولد في الأصل بواسطة Apple واعتمدت على نطاق واسع من قبل الصناعة ككل ، كان OpenCL أول جهد (ولا يزال أكثر تماسكًا) لإنشاء واجهة برمجة تطبيقات مشتركة للبرمجة المتوازية. من خلال أخذ الدروس من جهود الملكية المبكرة للموردين وتجميع معيار أوسع يمكن للجميع استخدامه ، تم اعتماد OpenCL لكل شيء من المعالجات المدمجة و DSPs إلى وحدات معالجة الرسوم التي تدفع نصف كيلو واط في استهلاك الطاقة.
بشكل عام ، نجحت OpenCL على نطاق واسع في تحقيق أهداف الإطار لمنصة برمجة حاسوبية مشتركة (ومحمولة إلى حد كبير). لا يتم دعمه فقط على مجموعة واسعة من الأجهزة ، ولكنه ملائم بشكل لا يصدق حتى للأحداث الحالية: إنه API المعجل الذي يستخدمه مشروع Folding @ Home ، أقوى مجموعة حوسبة في العالم ، والذي يتم استخدامه بشكل مكثف للبحث عن خيارات العلاج من أجل جائحة COVID-19.
ومع ذلك ، وفي نفس الوقت ، تمامًا كما لا يستطيع أحد أن يتنبأ تمامًا بتطور سوق الحوسبة المتوازية ، لم تسر الأمور دائمًا وفقًا لخطة Khronos ومجموعة عمل OpenCL التي تقود تطورها. كما تطرقنا عدة مرات خلال العام الماضي في مقالات مختلفة ، فإن OpenCL في حالة غير مستقرة على سطح مكتب الكمبيوتر ، وهو موطنه الأصلي. على مدى عقد من الزمن منذ بدايته ، فإن النظام البيئي للحوسبة GPU يتكسر: لقد خفف اهتمام NVIDIA من حقيقة أن لديهم بالفعل CUDA API الناجحة للغاية ، فإن محركات AMD's OpenCL فوضى ، Apple قامت بإيقاف OpenCL وتنتقل إلى واجهة برمجة التطبيقات المعدنية الخاصة بها. البائع الوحيد الذي يبدو أنه لديه اهتمام حقيقي بـ OpenCL في الوقت الحالي هو من الغريب بما فيه الكفاية Intel. وفي الوقت نفسه ، لم يتم استخدام OpenCL أبدًا على الإطلاق في الأجهزة المحمولة ، على الرغم من استخدامه غير المنتظم وحقيقة أن هذه تزداد قوة GPU وكتل المعالجة المتوازية الأخرى.
لذلك تقوم Khronos اليوم بشيء لست متأكدًا من وجود أي موازٍ له في صناعة الحوسبة – وبالتأكيد ، لم يكن هناك أي شيء من هذا القبيل في النظام البيئي للحوسبة GPU: الإطار يأخذ خطوة كبيرة إلى الوراء. تتطلع إلى إعادة تعيين النظام البيئي ، كما تحب المجموعة تسميته ، تكشف Khronos اليوم عن OpenCL 3.0 ، أحدث إصدار من واجهة برمجة تطبيقات الحوسبة الخاصة بهم. بعد أخذ بعض الدروس المكتسبة بشق الأنفس (والتي تم تعلمها بجد) ، تعيد المجموعة عقارب الساعة إلى الوراء على OpenCL ، وتعيد واجهة برمجة التطبيقات الأساسية إلى شوكة OpenCL 1.2.
ونتيجة لذلك ، أصبح كل شيء تم تطويره كجزء من OpenCL 2.x اختياريًا الآن: يمكن للبائعين (وسوف يستمرون عمومًا) في دعم هذه الميزات ، ولكن هذه الميزات لم تعد مطلوبة للامتثال للمواصفات الأساسية. بدلاً من الاضطرار إلى دعم كل ميزة OpenCL ، بغض النظر عن مدى فائدتها أو عدم جدواها لمنصة معينة ، فإن مستقبل واجهة برمجة التطبيقات سيكون حول الموردين الذين يختارون الميزات الاختيارية التي يرغبون في دعمها على رأس الصفحة ، مواصفات OpenCL 1.2 المحذوفة.
السياسة وأخذ اللعق
بشكل عام ، يجلب إعلان OpenCL 3.0 الكثير لتفريغه. ولكن ربما يكون أفضل مكان للبدء هو فهم عملية تطوير OpenCL ، ومن هم مستخدمي OpenCL. للتذكير ، تعتبر Khronos كونسورتيوم صناعة. لا تملك المنظمة نفسها قوة حقيقية – إنها مجرد مجموعة من الشركات – ولأنها ليست حامل منصة مثل Microsoft أو Apple، لا يمكن للمجموعة فرض التغيير التكنولوجي على أي شخص. بدلاً من ذلك ، فإن قوة جهود Khronos هي أنها تحصل على دعم صناعي واسع لمعاييرها ، وتضمين خبرة ومخاوف العديد من البائعين عبر النظام البيئي.
ولكن التحدي في النهج التعاوني هو أنه يتطلب على الأقل درجة معينة من الانسجام والاتفاق بين الشركات المشاركة. إذا لم يتم التوصل إلى اتفاق بشأن ما يجب فعله بعد ذلك ، فلا يمكن للمشروع المضي قدمًا. أو إذا لم يكن أي شخص سعيدًا بالمنتج الناتج ، فقد يتم تخطي المنتج بالكامل. يعد وضع معايير الصناعة في النهاية مسألة سياسية ، حتى لو كان ذلك لمعيار التكنولوجيا.
هذه ، بطريقة ما ، هي المشكلة التي واجهتها OpenCL. تم إصدار أحدث إصدار من المواصفات ، OpenCL 2.2 ، في عام 2017. والأهم من ذلك ، قدم لغة نواة OpenCL C ++ ، وأخيرًا جلب دعمًا للغة أكثر حداثة وموجهة إلى واجهة برمجة التطبيقات التي كانت في الأصل تعتمد على C. حرج ومع ذلك ، بعد ثلاث سنوات لا أحد قد تبنى OpenCL 2.2. ليس NVIDIA ، ولا AMD ، ولا Intel ، وبالتأكيد ليس أي مصنع للجهاز.
بالنسبة لأهمية خطوة إلى الأمام مثلما كان OpenCL 2.2 (و 2.1 قبله) ، فإن حقيقة الأمر هي أنه لم ينتهي أحد بسعادة خاصة بحالة OpenCL بعد 1.2 و 2.0. ونتيجة لذلك ، فقد أهميته ، ولم يعد يحقق أهداف المشروع. حاول مشروع OpenCL إرضاء الجميع باستخدام 2.x ، وبدلاً من ذلك انتهى به الأمر إلى إرضاء أي شخص.
OpenCL 3.0: التقدم للأمام بالرجوع للخلف
لذا إذا تم تجاهل OpenCL 2.x إلى حد كبير ، فما الحل لجعل OpenCL ذا صلة مرة أخرى؟ بالنسبة لخرونوس ومجموعة عمل OpenCL ، فإن الجواب هو العودة إلى ما نجح. وأفضل ما نجح هو OpenCL 1.2.
تم تقديم OpenCL 1.2 لأول مرة في عام 2011 ، وكان آخر إصدارات OpenCL 1.x. وفقًا لمعايير واجهة برمجة التطبيقات الحديثة ، فإن هذه هي مجردة للغاية: فهي تستند إلى C النقي وتفتقر إلى الدعم لأشياء مثل الذاكرة الافتراضية المشتركة أو لغة التمثيل المتوسط SPIR-V. ولكن في الوقت نفسه ، فهو أيضًا الإصدار الأخير من واجهة برمجة التطبيقات الذي لا يتضمن مجموعة من الكلمات التي لا يريدها شخص ما ، في مكان ما. إنها واجهة برمجة تطبيقات حوسبة متوازية نقية منخفضة المستوى إلى حد ما للمطورين عبر الطيف ، بدءًا من الأجهزة المضمنة ووصولاً إلى وحدات معالجة الرسوميات (GPU).
في النهاية ، ما تمكنت مجموعة عمل OpenCL من الاتفاق عليه هو أن OpenCL 1.2 يجب أن يكون جوهر المواصفات الجديدة – أي شيء آخر تم إصداره بعده ، بغض النظر عن مدى فائدته في بعض الحالات ، ليس مفيدًا بما فيه الكفاية بحيث يجب أن يكون مطلوب في جميع التطبيقات. وهذا ما يحدث بالضبط في OpenCL 3.0. الإصدار الأحدث من OpenCL يرث 1.2 ويجعلها المواصفات الأساسية الجديدة ، في حين يتم نقل جميع الميزات الأخرى خارج تلك المواصفات الأساسية ويتم جعلها اختيارية.
هذه هي إعادة الضبط التي يعتزم Khronos ومجموعة العمل منح OpenCL مسارًا جديدًا إلى الأمام. على الرغم من إعادة عقارب الساعة إلى الوراء بما يقرب من تسع سنوات ، فإن OpenCL ليس قريبًا من التطور. لكن طبيعتها الصلبة المتجانسة السابقة حالت دون تطورها ، لأنه لم يكن هناك سوى مسار واحد إلى الأمام. إذا كان المورد سعيدًا بـ OpenCL 1.2 ولكنه أراد بعض الميزات الإضافية 2.1 ، على سبيل المثال ، لكي يكون متوافقًا مع المواصفات التي سيحتاجها لتطبيق المواصفات الأساسية 2.1 الكاملة ؛ OpenCL 1.x / 2.x ليس لديه آلية للامتثال الجزئي. كان كل شيء أو لا شيء ، واختار عدد من البائعين "لا شيء".
على النقيض من ذلك ، تم تصميم OpenCL 3.0 خصيصًا بطريقة تسمح للبائعين باستخدام الأجزاء التي يحتاجون إليها ، وهذه الأجزاء فقط. كما ذكرنا سابقًا ، فإن جوهر المواصفات هو OpenCL 1.2 بشكل أساسي ، مع دعم الاستعلام عن ميزة الإضافة ، بالإضافة إلى بعض "نقاط الدخول الثانوية لتحسين إمكانية نقل التطبيقات". بالإضافة إلى ذلك ، فإن كل ما هو جديد ، هو كل شيء آخر: كل ميزات OpenCL 2.x ، بالإضافة إلى ميزات OpenCL 3.0 الجديدة. جميع هذه الميزات الإضافية اختيارية ، مما يسمح لموردي النظام الأساسي باختيار الميزات الإضافية التي يرغبون في دعمها واختيارها ، إن وجدت.
على سبيل المثال ، قد يلتزم البائع المضمن بقرب ما كان OpenCL 1.2 ، ثم يتبنى بعض الميزات مثل ملحقات DMA غير المتزامنة والذاكرة الافتراضية المشتركة. وفي الوقت نفسه ، قد يعتمد مطور GPU الكبير المنفصل الأخضر معظم OpenCL 2.x ، ولكنه يستبعد دعم تلك الذاكرة الافتراضية المشتركة ، وهو أمر غير مفيد جدًا لمسرع منفصل. ثم قد يرغب بائع ثالث في الوسط في اعتماده عند إرسال الجهاز ، ولكن ليس SPIR-V. في نهاية المطاف ، يمنح OpenCL 3.0 موردي الأنظمة الأساسية القدرة على تحديد تلك الميزات التي يحتاجون إليها ، في جوهره ، مما يجعل OpenCL يناسب رغباتهم المحددة.
هذا ، كما اتضح ، يشبه إلى حد كبير الطريقة التي تعامل بها خرونوس مع فولكان ، والتي كانت أكثر نجاحًا بكثير في السنوات الأخيرة. لقد أتاح منح البائعين بعض المرونة فيما تنفذه واجهات برمجة التطبيقات الخاصة بهم مما سمح لـ Vulkan بالامتداد من الأجهزة المحمولة إلى سطح المكتب ، لذلك هناك بعض الأدلة الواقعية الواضحة جدًا على أن هذه البنية يمكن أن تعمل. وهذا هو نوع النجاح الذي ترغب مجموعة عمل OpenCL في رؤيته أيضًا.
في نهاية المطاف ، كما يراه خرونوس ، فإن صراعات OpenCL خلال نصف العقد الماضي أو ما شابه جاءت من محاولة جعلها كل شيء للجميع مع الحفاظ على طبيعتها المتجانسة في نفس الوقت. ما يحتاجه الرجال المضمنون مختلف عن رجال CPU / APU ، وما يحتاجه هؤلاء الرجال لا يزال مختلفًا عن رجال dGPU – وما زلنا لم نصل إلى أشياء مثل FPGAs والمزيد من الاستخدامات الباطنية لـ OpenCL. لذا ، من أجل تأمين مستقبلها الخاص ، يحتاج OpenCL إلى الابتعاد عن كونه تصميمًا مترابطًا ، وبدلاً من أن يكون قابلاً للتكيف مع مجموعة واسعة من الأجهزة والأسواق التي تم تصميم الإطار لتقديمها.
السير في الطريق إلى الأمام
الغوص بعمق أكبر قليلاً ، دعنا نلقي نظرة سريعة على ما يعنيه OpenCL 3.0 للمطورين وبائعي المنصات والمستخدمين فيما يتعلق بتطوير البرامج والتوافق.
على الرغم من التغيير الكبير في فلسفة التطوير ، تم تصميم OpenCL 3.0 ليكون متوافقًا مع الإصدارات السابقة كما هو معقول. بالنسبة للمطورين والمستخدمين ، نظرًا لأن المواصفات الأساسية تستند إلى OpenCL 1.2 ، سيتم تشغيل 1.2 تطبيق دون تغيير على أي جهاز OpenCL 3.0. وفي الوقت نفسه بالنسبة لتطبيقات OpenCL 2.x ، سيتم تشغيل هذه التطبيقات أيضًا دون تغيير على أجهزة OpenCL 3.0 طالما أن هذه الأجهزة تدعم أي ميزات تستخدم 2.x. وهذا ، بالتأكيد ، لا يعني أنك ستشغل تطبيق OpenCL 2.1 على نظام مضمن في أي وقت قريب ؛ ولكن على أجهزة الكمبيوتر والأنظمة الأخرى حيث تعمل تطبيقات OpenCL 2.1 بالفعل ، لا يُتوقع أن تتوقف عن العمل تحت OpenCL 3.0.
يعود سبب هذا التمييز مرة أخرى إلى التضمين الاختياري للميزات. لا يحتاج موردو الأنظمة الأساسية الذين يطورون وقت تشغيل OpenCL 3.0 إلى دعم ميزات 2.x ، لكنهم أيضًا لا يحتاجون إلى إسقاطها ؛ يمكنهم (مواصلة) دعم الميزات الاختيارية كما يرون مناسبًا. في الواقع ، تتطلب المواصفات الجديدة القليل نسبيًا من مالكي المنصات فيما يتعلق بالامتثال الأساسي. تحتاج برامج تشغيل OpenCL 1.2 و 2.x إلى بعض التغييرات للوفاء بالامتثال 3.x ، ولكن هذا يتمحور بشكل أساسي حول دعم استعلامات الميزات الجديدة لـ OpenCL. لذا سيتمكن البائعون من إطلاق 3.0 برامج تشغيل في وقت قصير.
ومن الآن فصاعدًا ، سيكون التركيز على مطوري التطبيقات الذين يستخدمون استعلامات الميزات بشكل صحيح. نظرًا لأن ميزات OpenCL 2.x اختيارية ، يتم تشجيع جميع التطبيقات التي تستخدم الميزات الاختيارية 2.x / 3.0 بشدة على استخدام استعلامات الميزات للتأكد أولاً من توفر الميزات الضرورية ؛ كحد أدنى يمكن أن يفشل التطبيق بأمان ، بدلاً من الفشل الأصعب في استدعاء ميزة غير موجودة. لذلك ، بينما سيستمر برنامج OpenCL 2.x في العمل كما هو ، يتم تشجيع المطورين على تحديث تطبيقاتهم لتشغيل استعلامات الميزات.
الآن مع كل ما قيل ، يجب ملاحظة أنه نظرًا لأن مجموعة من ميزات OpenCL 2.x المطلوبة مسبقًا قد تم جعلها اختيارية ، فهذا يعني أنه يُسمح لبائعي الأنظمة الأساسية بإسقاطها إذا رغبوا في ذلك. بالتحدث إلى Khronos ، لا يبدو أن هذا سيحدث – على الأقل ، ليس مع موردي أجهزة الكمبيوتر – ولكنه خيار لا يقل عن ذلك ، وهو خيار يعترفون به. حيثما يكون من المرجح رؤيته (إن وجد) سيكون الفضاء المضمن وما إلى ذلك ، حيث كان البائعون يسحبون بالفعل أحذيةهم على ميزات مثل SPIR-V.
أخيرًا ، في حين أن تأثير هذا الواقع سيكون صفريًا ، تجدر الإشارة أيضًا إلى أنه نظرًا لعدم اعتماد OpenCL 2.2 مطلقًا ، فإن معيار OpenCL 3.0 يترك شيئًا من الناحية الفنية. OpenCL C ++ ، الذي تم تقديمه في 2.2 ، لم يتم تضمينه في مواصفات OpenCL 3.0 ، حتى كميزة اختيارية. بدلاً من ذلك ، يتجاهلها فريق عمل OpenCL تمامًا.
استبدال OpenCL C ++ هو C ++ لمشروع OpenCL ، والذي ، على الرغم من تشابه التسمية ، هو مشروع منفصل تمامًا. الاختلافات صغيرة إلى حد ما من منظور البرمجة ، ولكن بشكل أساسي يتم بناء C ++ لـ OpenCL باستخدام نهج متعدد الطبقات. في هذه الحالة ، استخدام Clang / LLVM لترجمة الشفرة إلى SPIR-V ، والتي يمكن تشغيلها بعد ذلك على المستويات الدنيا من مكدس تنفيذ OpenCL مثل التعليمات البرمجية الأخرى. وبالطبع ، لا تزال SYCL من Khronos أيضًا تقدم برمجة C ++ أحادية المصدر للحوسبة المتوازية. تجدر الإشارة إلى أن SYCL يستند إلى أعلى OpenCL 1.2 ، لذلك يجعل هذا الانتقال غير منزعج إلى حد ما.
ما الجديد في OpenCL 3.0: ملحقات DMA غير المتزامنة و SPIR-V 1.3
إلى جانب العودة الرئيسية إلى المواصفات الأساسية ، فإن OpenCL يتضمن أيضًا بعض الميزات الجديدة الاختيارية لموردي الأنظمة الأساسية والمطورين لحفر أسنانهم. ومن أهم هذه الإضافات ملحقات DMA غير المتزامنة ، والتي ستنتهي في النهاية بكونها جزرة لذيذة بشكل خاص لبائعي المنصات الذين ظلوا يلتزمون بـ OpenCL 1.2 حتى الآن.
تهدف إلى كشف عمليات الوصول المباشر للذاكرة في OpenCL للأجهزة التي تحتوي على أجهزة DMA ، DMA غير المتزامن هو بالضبط ما يقوله الاسم على العلبة: دعم تنفيذ عمليات نقل DMA بشكل غير متزامن. يسمح هذا بتشغيل معاملات DMA بشكل متزامن مع نواة الحوسبة ، على عكس العمليات المتزامنة التي يمكن تنفيذها بشكل عام فقط بين عمليات نواة الحوسبة الأخرى. يتضمن ذلك القدرة على تشغيل عدة عمليات DMA متزامنة مع بعضها البعض أيضًا.
هذه الميزة ملحوظة بشكل خاص لتمكين نقل الذاكرة ثنائية الأبعاد وثلاثية الأبعاد – أي هياكل الذاكرة المعقدة الأكثر تقدمًا من هياكل الذاكرة البسيطة ثنائية الأبعاد (الخطية). كما قد تتوقع ، الغرض من هذا أن يكون مفيدًا للصور والبيانات المماثلة ، والتي هي في الأصل هياكل ثنائية / ثلاثية الأبعاد للبدء بها.
وفي الوقت نفسه ، يقدم OpenCL 3.0 أيضًا دعم SPIR-V 1.3 لـ OpenCL. هذه مرة أخرى ميزة اختيارية لحاملي النظام الأساسي ، وتجلب OpenCL إلى حد ما إلى حد ما في دعم SPIR-V ، مع SPIR-V الرئيسي الآن في الإصدار 1.5. يقال الحقيقة ، لست متأكدًا من مدى ملاءمة خيار دعم 1.3 في الوقت الحالي ، ومع ذلك لأنه جزء من مواصفات Vulkan 1.1 – والواقع أن الكثير من التطورات فيه أكثر من 1.2 تركز على الرسومات – ستلعب دورًا أكبر في تعزيز قابلية التشغيل البيني بين Vulkan و OpenCL.
ما هي الخطوة التالية في OpenCL؟
أخيرًا ، كجزء من الإصلاح الشامل لـ OpenCL لـ 3.0 ، يقوم Khronos ومجموعة عمل OpenCL أيضًا بوضع خططهم للتطوير المستقبلي لـ OpenCL. من خلال مسح اللوحة ونقل العديد من الميزات إلى اختياري ، فإنه يمنح مجموعة العمل حرية جديدة للإضافة إلى OpenCL كما تراه قاعدة المستخدمين مناسبًا. واتباع فلسفتهم الجديدة بطريقة مجزأة أكثر.
جزء كبير ، كما هو الحال دائمًا ، سيكون التطور المستمر لمواصفات OpenCL الأساسية. في حين أن 3.0 تعيد الأشياء إلى الوراء ، فإن الخطة ليست الحفاظ على المواصفات الأساسية 1.2-eque إلى الأبد. بدلاً من ذلك ، مثل مشاريع Khronos الأخرى ، لا يزال هدف مجموعة العمل هو نقل الإضافات المعتمدة على نطاق واسع والمُختبرة جيدًا إلى القلب. لإضافة طبقات أخرى إلى البصل مرة أخرى ، كما كانت ، ولكن بطريقة أكثر ذكاءً وقياسًا من تطوير OpenCL 2.x.
في غضون ذلك ، ستكون إحدى الميزات ذات الأولوية العالية للإصدارات المستقبلية هي ما تطلق عليه المجموعة ملف تعريف مرن ، وهي ميزة أخرى تركز على المضمنة. من المثير للاهتمام ، في بعض النواحي ، هذه نسخة أكثر تجريدًا من OpenCL ، مما يسمح للبائعين باستئصال المزيد من الميزات لمطابقة ما يمكن أن تقوم به أجهزتهم. على سبيل المثال ، يمكن إزالة أوضاع الدقة الفاصلة العائمة مثل الدقة الفردية IEEE ، والتي تكون مطلوبة عادةً في OpenCL 1.2 / 3.0 ، بالإضافة إلى بعض مكالمات API. إلى جانب زيادة تبسيط الأمور لبعض المطورين ، سيجعل OpenCL مناسبًا بشكل أفضل للبيئات التي تتطلب متطلبات صارمة لشهادة السلامة (فكر في السيارات) ، حيث سيكون من السهل التحقق من مجموعة ميزات OpenCL الأصغر والحصول على الشهادة.
في هذه الأثناء ، على الطرف الآخر من الطيف ، يبحث Khronos مرة أخرى في فكرة مجموعات الميزات لـ OpenCL ، لمساعدة مطوري البرامج على تجاوز الاختلافات بين المنصات الرئيسية بشكل أفضل. في حين أن الطبيعة الثقيلة للخيار OpenCL 3.0 تجعله دقيقًا نسبيًا ، إلا أنه يضر أيضًا قابلية النقل إلى حد ما – لا يمكن للمطور الاعتماد على تطبيق OpenCL 3.0 آخر لضرورة الحصول على أي شيء أكثر مما تتطلبه المواصفات الأساسية 1.2-eqsue . لذلك ، على عكس مجموعات ميزات الرسومات لوحدات معالجة الرسومات ، فإن مجموعات ميزات OpenCL ستسمح للصناعة بالانخراط في بعض التوحيد القياسي – على سبيل المثال ، ملف تعريف للكمبيوتر الشخصي يحتوي على العديد من الميزات الحديثة ، ثم ملف تعريف التعلم الآلي مع دعم عدد أقل من الميزات الأكثر صلة بالعمق عمليات التعلم.
تبحث المجموعة أيضًا في الفرص المستمرة للنهج متعددة الطبقات ، حيث لا يكون دعم OpenCL (وربما لن يكون أبدًا) جزءًا أصليًا من النظام الأساسي. هذا مفهوم آخر مأخوذ من كتاب التشغيل Vulkan ، حيث توجد طبقات متاحة لتشغيل Vulkan على منصات مثل Appleمعدن. لدى OpenCL بالفعل مشروع نشط ليتم تشغيله فوق Vulkan – clspv و clvk – والذي تم استخدامه في الهاتف المحمول لمساعدة منفذ Adobe وإعادة استخدام كود OpenCL الخاص به من deskto0p Premiere إلى Premiere Rush دون الحاجة إلى إعادة كتابة شاملة. وفي الوقت نفسه ، تدعم Microsoft مشروع OpenCL أيضًا ، (Open) CLOn12 ، والذي سينفذ دعم OpenCL 1.2 على رأس DirectX 12.
لكن السؤال الطبقي الكبير الذي يطرحه خرونوس الآن يدور حول OpenCL Appleمنصات. المؤلف الأصلي لـ OpenCL لم يجعله أبعد من دعم OpenCL 1.2 ، وقد وضعوا علامة على ميزة الإيقاف. لذا إذا كانت OpenCL ستستمر في العمل عليها Apple المنصات – بغض النظر عن دعم الميزات الجديدة 2.x و 3.x – عندها يجب إضافة دعم جديد كطبقة مستوى أعلى. لذلك في حين لا يوجد حاليًا مشروع OpenCL حول مشروع المعادن ، يبدو أنها مسألة وقت فقط حتى تبدأ واحدة ، إذا كان بإمكان Khronos بالطبع العثور على الأطراف المهتمة الكافية للمشروع. لقد حققت المجموعة نجاحًا كبيرًا مع طبقة MoltenVK ، طبقة Vulkan-over-Metal الخاصة بها ، لذا فإن مشروع OpenCL يتناسب تمامًا مع ذلك.
أخيرًا ، حتى فولكان نفسها مشروع محتمل من نوع ما لمجموعة عمل OpenCL. وتعني الانعكاسات على المواصفات الأساسية أن قابلية التشغيل البيني Vulkan / OpenCL قد تراجعت خطوة إلى الوراء ، وتود مجموعة العمل دفع ذلك إلى الأمام. من الناحية المثالية ، يجب أن يكون OpenCL قادرًا على العمل في نفس مجموعة الذاكرة مثل Vulkan ، بالإضافة إلى استيراد وتصدير الإشارات ، وكل ذلك بطريقة صريحة.
OpenCL 3.0: مؤقت اليوم ، إضفاء الطابع الرسمي في غضون أشهر قليلة؟
ولكن قبل أن يحدث أي من هذا رسميًا ، سيتم قطع عمل Khronos ومجموعة عمل OpenCL من أجل إخراج OpenCL 3.0. بينما تقدم المجموعة OpenCL 3.0 اليوم ، لا يزال المعيار مؤقتًا – يتم الكشف عنه للمطورين والجمهور الأوسع للحصول على تعليقات قبل إضفاء الطابع الرسمي الكامل. وبالنظر إلى حالة الاخرق الحالية لـ OpenCL 2.x ، فإن المجموعة حريصة على الانتهاء من OpenCL 3.0 عاجلاً وليس آجلاً.
بعد كل ما قيل ، يأمل خرونوس أن يتمكنوا من الحصول على التصديق على المعيار في غضون بضعة أشهر. جنبًا إلى جنب مع الحصول على اشتراك الأعضاء والمطورين ، سيتطلب وضع اللمسات الأخيرة أيضًا إكمال اختبارات توافق OpenCL 3.0 (والتي هي قيد التطوير أيضًا) ، بحيث يمكن للمجموعة الموافقة رسميًا على تطبيقات OpenCL 3.0. كونها الجزء التقني ، قد ينتهي الأمر بهذه المهمة الأسهل ؛ مع إلغاء مواصفات OpenCL 3.0 الأساسية للعديد من الميزات وإضافة القليل منها في المقابل ، يجب ألا يواجه البائعون الذين لديهم بالفعل تطبيقات OpenCL صلبة الكثير من الصعوبة في تجهيز برامج تشغيل OpenCL 3.0.
