برامج تشغيل API للشبكات العصبية

توفر هذه الصفحة نظرة عامة حول كيفية تنفيذ برنامج تشغيل Neural Networks API (NNAPI). لمزيد من التفاصيل، راجع الوثائق الموجودة في ملفات تعريف HAL ​​في hardware/interfaces/neuralnetworks . يوجد نموذج لتطبيق برنامج التشغيل في frameworks/ml/nn/driver/sample .

لمزيد من المعلومات حول Neural Networks API، راجع Neural Networks API .

الشبكات العصبية هال

تحدد الشبكات العصبية (NN) HAL تجريدًا للأجهزة المختلفة، مثل وحدات معالجة الرسومات (GPUs) ومعالجات الإشارات الرقمية (DSPs)، الموجودة في المنتج (على سبيل المثال، الهاتف أو الجهاز اللوحي). يجب أن تتوافق برامج تشغيل هذه الأجهزة مع NN HAL. يتم تحديد الواجهة في ملفات تعريف HAL ​​في hardware/interfaces/neuralnetworks .

يظهر الشكل 1 التدفق العام للواجهة بين الإطار والسائق.

تدفق الشبكات العصبية

الشكل 1. تدفق الشبكات العصبية

التهيئة

عند التهيئة، يستعلم إطار العمل عن برنامج التشغيل لإمكانياته باستخدام IDevice::getCapabilities_1_3 . تتضمن بنية @1.3::Capabilities جميع أنواع البيانات وتمثل أداءً غير مريح باستخدام المتجه.

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

لتحديد القيم التي يقوم برنامج التشغيل بإرجاعها استجابةً لـ IDevice::getCapabilities_1_3 ، استخدم تطبيق NNAPI Benchmark لقياس أداء أنواع البيانات المقابلة. يوصى باستخدام نماذج MobileNet v1 وv2 و asr_float و tts_float لقياس الأداء لقيم الفاصلة العائمة 32 بت، ويوصى بنماذج MobileNet v1 وv2 الكمية للقيم الكمية 8 بت. لمزيد من المعلومات، راجع مجموعة اختبار التعلم الآلي لنظام Android .

في Android 9 والإصدارات الأقدم، تتضمن بنية Capabilities معلومات أداء برنامج التشغيل فقط للنقطة العائمة والموترات الكمية ولا تتضمن أنواع البيانات العددية.

كجزء من عملية التهيئة، قد يستعلم إطار العمل عن مزيد من المعلومات، باستخدام IDevice::getType و IDevice::getVersionString و IDevice:getSupportedExtensions و IDevice::getNumberOfCacheFilesNeeded .

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

التحويل البرمجي

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

في وقت تجميع النموذج، يرسل إطار العمل النموذج إلى كل برنامج تشغيل مرشح عن طريق استدعاء IDevice::getSupportedOperations_1_3 . يُرجع كل برنامج تشغيل مجموعة من القيم المنطقية التي تشير إلى عمليات النموذج المدعومة. يمكن للسائق تحديد أنه لا يمكنه دعم عملية معينة لعدد من الأسباب. على سبيل المثال:

  • برنامج التشغيل لا يدعم نوع البيانات.
  • يدعم برنامج التشغيل العمليات ذات معلمات الإدخال المحددة فقط. على سبيل المثال، قد يدعم برنامج التشغيل 3x3 و5x5، ولكن ليس عمليات الالتواء 7x7.
  • لدى برنامج التشغيل قيود في الذاكرة تمنعه ​​من التعامل مع الرسوم البيانية أو المدخلات الكبيرة.

أثناء التجميع، يمكن أن يكون للمدخلات والمخرجات والمعاملات الداخلية للنموذج، كما هو موضح في OperandLifeTime ، أبعاد أو رتبة غير معروفة. لمزيد من المعلومات، راجع شكل الإخراج .

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

عند النجاح، يقوم برنامج التشغيل بإرجاع مؤشر @1.3::IPreparedModel . إذا قام برنامج التشغيل بإرجاع رمز فشل عند إعداد مجموعته الفرعية من النموذج، فسيقوم إطار العمل بتشغيل النموذج بأكمله على وحدة المعالجة المركزية.

لتقليل الوقت المستخدم للتجميع عند بدء تشغيل التطبيق، يمكن للسائق تخزين عناصر التجميع مؤقتًا. لمزيد من المعلومات، راجع التخزين المؤقت للتجميع .

تنفيذ

عندما يطلب أحد التطبيقات من إطار العمل تنفيذ طلب، يستدعي إطار العمل أسلوب HAL IPreparedModel::executeSynchronously_1_3 بشكل افتراضي لتنفيذ تنفيذ متزامن على نموذج مُجهز. يمكن أيضًا تنفيذ الطلب بشكل غير متزامن باستخدام طريقة execute_1_3 ، أو طريقة executeFenced (راجع التنفيذ المسيّج )، أو تنفيذه باستخدام تنفيذ الاندفاع .

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

باستخدام طريقة execute_1_3 غير المتزامنة، يعود التحكم إلى عملية التطبيق بعد بدء التنفيذ، ويجب على السائق إخطار إطار العمل عند اكتمال التنفيذ، باستخدام @1.3::IExecutionCallback .

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

بالنسبة لبرامج التشغيل NN HAL 1.2 أو أعلى، عند اكتمال الطلب، يتم إرجاع حالة الخطأ وشكل الإخراج ومعلومات التوقيت إلى إطار العمل. أثناء التنفيذ، يمكن أن يكون للمخرجات أو المعاملات الداخلية للنموذج بُعدًا غير معروف أو أكثر أو رتبة غير معروفة. عندما يكون لمعامل إخراج واحد على الأقل بُعد أو رتبة غير معروفة، يجب على برنامج التشغيل إرجاع معلومات الإخراج ذات الحجم الديناميكي.

بالنسبة للسائقين الذين يستخدمون NN HAL 1.1 أو أقل، يتم إرجاع حالة الخطأ فقط عند اكتمال الطلب. يجب تحديد أبعاد معاملات الإدخال والإخراج بالكامل حتى يكتمل التنفيذ بنجاح. يمكن أن تحتوي المعاملات الداخلية على بُعد واحد أو أكثر غير معروف، لكن يجب أن يكون لها رتبة محددة.

بالنسبة لطلبات المستخدم التي تشمل برامج تشغيل متعددة، يكون إطار العمل مسؤولاً عن حجز الذاكرة المتوسطة وتسلسل المكالمات لكل برنامج تشغيل.

يمكن بدء طلبات متعددة بالتوازي على نفس @1.3::IPreparedModel . يمكن للسائق تنفيذ الطلبات بالتوازي أو إجراء تسلسل لعمليات التنفيذ.

يمكن أن يطلب الإطار من السائق الاحتفاظ بأكثر من نموذج جاهز. على سبيل المثال، قم بإعداد النموذج m1 ، وإعداد m2 ، وتنفيذ الطلب r1 على m1 ، وتنفيذ r2 على m2 ، وتنفيذ r3 على m1 ، وتنفيذ r4 على m2 ، والتحرير (الموصوف في التنظيف ) m1 ، وتحرير m2 .

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

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

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

شكل الإخراج

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

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

توقيت

في Android 10، يمكن للتطبيق أن يطلب وقت التنفيذ إذا كان التطبيق قد حدد جهازًا واحدًا لاستخدامه أثناء عملية التجميع. للحصول على التفاصيل، راجع MeasureTiming واكتشاف الجهاز وتعيينه . في هذه الحالة، يجب على برنامج تشغيل NN HAL 1.2 قياس مدة التنفيذ أو الإبلاغ عن UINT64_MAX (للإشارة إلى أن المدة غير متوفرة) عند تنفيذ الطلب. يجب على السائق تقليل أي عقوبة أداء ناتجة عن قياس مدة التنفيذ.

يقوم السائق بالإبلاغ عن الفترات التالية بالميكروثانية في بنية Timing :

  • وقت التنفيذ على الجهاز: لا يشمل وقت التنفيذ في برنامج التشغيل الذي يعمل على المعالج المضيف.
  • وقت التنفيذ في برنامج التشغيل: يشمل وقت التنفيذ على الجهاز.

يجب أن تتضمن هذه الفترات الوقت الذي يتم فيه تعليق التنفيذ، على سبيل المثال، عندما يتم استباق التنفيذ بواسطة مهام أخرى أو عند انتظار توفر المورد.

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

إعدام مسور

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

في التنفيذ المُسيج، يستدعي إطار العمل الأسلوب IPreparedModel::executeFenced لبدء تنفيذ مُسيج وغير متزامن على نموذج مُجهز مع متجه لأسوار المزامنة للانتظار. إذا انتهت المهمة غير المتزامنة قبل عودة المكالمة، فيمكن إرجاع مقبض فارغ لـ sync_fence . يجب أيضًا إرجاع كائن IFencedExecutionCallback للسماح لإطار العمل بالاستعلام عن حالة الخطأ ومعلومات المدة.

بعد اكتمال التنفيذ، يمكن الاستعلام عن قيمتي التوقيت التاليتين اللتين تقيسان مدة التنفيذ من خلال IFencedExecutionCallback::getExecutionInfo .

  • timingLaunched : المدة من وقت استدعاء executeFenced عندما يشير executeFenced إلى syncFence الذي تم إرجاعه.
  • timingFenced : المدة التي تبدأ من اللحظة التي يتم فيها الإشارة إلى كافة أسوار المزامنة التي ينتظرها التنفيذ عندما يشير executeFenced إلى syncFence الذي تم إرجاعه.

التحكم في التدفق

بالنسبة للأجهزة التي تعمل بنظام التشغيل Android 11 أو أعلى، يتضمن NNAPI عمليتين لتدفق التحكم، IF و WHILE ، اللتين تأخذان نماذج أخرى كوسيطات وتنفذها بشكل مشروط ( IF ) أو بشكل متكرر ( WHILE ). لمزيد من المعلومات حول كيفية تنفيذ ذلك، راجع التحكم في التدفق .

جودة الخدمة

في Android 11، يتضمن NNAPI جودة خدمة محسنة (QoS) من خلال السماح للتطبيق بالإشارة إلى الأولويات النسبية لنماذجه، والحد الأقصى من الوقت المتوقع لإعداد النموذج، والحد الأقصى من الوقت المتوقع للتنفيذ أن يكتمل. لمزيد من المعلومات، راجع جودة الخدمة .

تنظيف

عند الانتهاء من تطبيق ما باستخدام نموذج مُجهز، يطلق إطار العمل مرجعه إلى كائن @1.3::IPreparedModel . عندما لا تتم الإشارة إلى كائن IPreparedModel ، يتم إتلافه تلقائيًا في خدمة برنامج التشغيل التي قامت بإنشائه. يمكن استعادة الموارد الخاصة بالنموذج في هذا الوقت أثناء تنفيذ برنامج التشغيل للأداة المدمرة. إذا أرادت خدمة برنامج التشغيل تدمير كائن IPreparedModel تلقائيًا عندما لم يعد العميل بحاجة إليه، فيجب ألا تحتوي على أي مراجع إلى كائن IPreparedModel بعد إرجاع كائن IPreparedeModel من خلال IPreparedModelCallback::notify_1_3 .

استخدام المعالج

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

يوفر إطار العمل تطبيق وحدة المعالجة المركزية (CPU) لجميع عمليات NNAPI باستثناء العمليات المحددة من قبل البائع. لمزيد من المعلومات، راجع ملحقات البائع .

العمليات المقدمة في Android 10 (مستوى API 29) تحتوي فقط على تطبيق مرجعي لوحدة المعالجة المركزية للتحقق من صحة اختبارات CTS وVTS. تُفضل التطبيقات المحسنة المضمنة في أطر تعلم الآلة المحمولة على تطبيق NNAPI CPU.

وظائف المرافق

تتضمن قاعدة بيانات NNAPI وظائف الأداة المساعدة التي يمكن استخدامها بواسطة خدمات برنامج التشغيل.

يحتوي الملف frameworks/ml/nn/common/include/Utils.h على وظائف مساعدة متنوعة، مثل تلك المستخدمة للتسجيل والتحويل بين إصدارات NN HAL المختلفة.

  • VLogging: VLOG عبارة عن ماكرو مجمّع حول LOG Android الذي يسجل الرسالة فقط إذا تم تعيين العلامة المناسبة في خاصية debug.nn.vlog . يجب استدعاء initVLogMask() قبل أي استدعاءات لـ VLOG . يمكن استخدام الماكرو VLOG_IS_ON للتحقق مما إذا كان VLOG ممكّنًا حاليًا، مما يتيح تخطي رمز التسجيل المعقد إذا لم تكن هناك حاجة إليه. يجب أن تكون قيمة العقار واحدة مما يلي:

    • سلسلة فارغة، تشير إلى عدم إجراء أي تسجيل.
    • الرمز المميز 1 أو all ، يشير إلى أنه يجب إجراء كافة عمليات التسجيل.
    • قائمة من العلامات، مفصولة بمسافات أو فواصل أو نقطتين، تشير إلى التسجيل الذي يجب القيام به. العلامات هي compilation ، cpuexe ، driver ، execution ، manager ، model .

  • compliantWithV1_* : إرجاع true إذا كان من الممكن تحويل كائن NN HAL إلى نفس النوع من إصدار HAL مختلف دون فقدان المعلومات. على سبيل المثال، يؤدي استدعاء compliantWithV1_0 على V1_2::Model إلى إرجاع false إذا كان النموذج يتضمن أنواع العمليات المقدمة في NN HAL 1.1 أو NN HAL 1.2.

  • convertToV1_* : يحول كائن NN HAL من إصدار إلى آخر. يتم تسجيل تحذير إذا أدى التحويل إلى فقدان المعلومات (أي إذا كان الإصدار الجديد من النوع لا يمكن أن يمثل القيمة بشكل كامل).

  • القدرات: يمكن استخدام وظائف nonExtensionOperandPerformance update للمساعدة في إنشاء حقل Capabilities::operandPerformance .

  • خصائص الاستعلام عن الأنواع: isExtensionOperandType و isExtensionOperationType و nonExtensionSizeOfData و nonExtensionOperandSizeOfData و nonExtensionOperandTypeIsScalar و tensorHasUnspecifiedDimensions .

يحتوي الملف frameworks/ml/nn/common/include/ValidateHal.h على وظائف مساعدة للتحقق من صحة كائن NN HAL وفقًا لمواصفات إصدار HAL الخاص به.

  • validate* : إرجاع true إذا كان كائن NN HAL صالحًا وفقًا لمواصفات إصدار HAL الخاص به. لا يتم التحقق من صحة أنواع OEM وأنواع الامتدادات. على سبيل المثال، تقوم validateModel بإرجاع false إذا كان النموذج يحتوي على عملية تشير إلى فهرس معامل غير موجود، أو عملية غير مدعومة في إصدار HAL هذا.

يحتوي الملف frameworks/ml/nn/common/include/Tracing.h على وحدات ماكرو لتبسيط إضافة معلومات النظام إلى كود الشبكات العصبية. على سبيل المثال، راجع استدعاءات الماكرو NNTRACE_* في برنامج التشغيل النموذجي .

يحتوي الملف frameworks/ml/nn/common/include/GraphDump.h على وظيفة مساعدة لتفريغ محتوى Model في شكل رسومي لأغراض تصحيح الأخطاء.

  • graphDump : يكتب تمثيلاً للنموذج بتنسيق Graphviz ( .dot ) إلى الدفق المحدد (إذا تم توفيره) أو إلى logcat (إذا لم يتم توفير دفق).

تصديق

لاختبار تنفيذك لـ NNAPI، استخدم اختبارات VTS وCTS المضمنة في إطار عمل Android. يقوم VTS بتدريب برامج التشغيل لديك بشكل مباشر (دون استخدام إطار العمل)، بينما يقوم CTS بتدريبها بشكل غير مباشر من خلال إطار العمل. تقوم هذه باختبار كل طريقة من طرق واجهة برمجة التطبيقات (API) والتحقق من أن جميع العمليات التي تدعمها برامج التشغيل تعمل بشكل صحيح وتوفر نتائج تلبي متطلبات الدقة.

متطلبات الدقة في CTS وVTS لـ NNAPI هي كما يلي:

  • النقطة العائمة: القيمة المطلقة (المتوقع - الفعلي) <= atol + rtol * القيمة المطلقة (المتوقع)؛ أين:

    • بالنسبة إلى fp32، atol = 1e-5f، rtol = 5.0f * 1.1920928955078125e-7
    • بالنسبة إلى fp16، atol = rtol = 5.0f * 0.0009765625f

  • مكمَّمة: متوقفة بمقدار واحد (باستثناء mobilenet_quantized ، وهي متوقفة بمقدار ثلاثة)

  • منطقية: تطابق تام

إحدى الطرق التي تختبر بها CTS NNAPI هي إنشاء رسوم بيانية عشوائية زائفة ثابتة تستخدم لاختبار ومقارنة نتائج التنفيذ من كل برنامج تشغيل مع تطبيق NNAPI المرجعي. بالنسبة للسائقين الذين لديهم NN HAL 1.2 أو أعلى، إذا كانت النتائج لا تفي بمعايير الدقة، فإن CTS يبلغ عن خطأ ويقوم بتفريغ ملف مواصفات للنموذج الفاشل ضمن /data/local/tmp لتصحيح الأخطاء. لمزيد من التفاصيل حول معايير الدقة، راجع TestRandomGraph.cpp و TestHarness.h .

اختبار الزغب

الغرض من اختبار الضبابية هو العثور على الأعطال أو التأكيدات أو انتهاكات الذاكرة أو السلوك العام غير المحدد في التعليمات البرمجية قيد الاختبار بسبب عوامل مثل المدخلات غير المتوقعة. بالنسبة لاختبار NNAPI fuzz، يستخدم Android اختبارات تعتمد على libFuzzer ، والتي تتسم بالكفاءة في التشويش لأنها تستخدم تغطية الخط لحالات الاختبار السابقة لإنشاء مدخلات عشوائية جديدة. على سبيل المثال، يفضل libFuzzer حالات الاختبار التي تعمل على أسطر جديدة من التعليمات البرمجية. وهذا يقلل بشكل كبير من مقدار الوقت الذي تستغرقه الاختبارات للعثور على التعليمات البرمجية التي بها مشكلات.

لإجراء اختبار ضبابي للتحقق من صحة تنفيذ برنامج التشغيل الخاص بك، قم بتعديل frameworks/ml/nn/runtime/test/android_fuzzing/DriverFuzzTest.cpp في أداة اختبار libneuralnetworks_driver_fuzzer الموجودة في AOSP لتضمين رمز برنامج التشغيل الخاص بك. لمزيد من المعلومات حول اختبار NNAPI Fuzz، راجع frameworks/ml/nn/runtime/test/android_fuzzing/README.md .

حماية

نظرًا لأن عمليات التطبيق تتواصل مباشرة مع عملية السائق، فيجب على السائقين التحقق من صحة وسيطات المكالمات التي يتلقونها. يتم التحقق من صحة هذا التحقق بواسطة VTS. رمز التحقق موجود في frameworks/ml/nn/common/include/ValidateHal.h .

يجب على السائقين أيضًا التأكد من عدم تداخل التطبيقات مع التطبيقات الأخرى عند استخدام نفس الجهاز.

مجموعة اختبار التعلم الآلي لنظام Android

يعد Android Machine Learning Test Suite (MLTS) أحد معايير NNAPI المضمنة في CTS وVTS للتحقق من دقة النماذج الحقيقية على أجهزة البائعين. يقوم المعيار بتقييم زمن الوصول والدقة، ويقارن نتائج برامج التشغيل مع النتائج باستخدام TF Lite الذي يعمل على وحدة المعالجة المركزية، لنفس النموذج ومجموعات البيانات. وهذا يضمن أن دقة برنامج التشغيل ليست أسوأ من التنفيذ المرجعي لوحدة المعالجة المركزية.

يستخدم مطورو نظام Android الأساسي أيضًا MLTS لتقييم زمن الوصول ودقة برامج التشغيل.

يمكن العثور على معيار NNAPI في مشروعين في AOSP:

النماذج ومجموعات البيانات

يستخدم معيار NNAPI النماذج ومجموعات البيانات التالية.

  • MobileNetV1 float وu8 مكممان بأحجام مختلفة، ويتم تشغيلهما مقابل مجموعة فرعية صغيرة (1500 صورة) من Open Images Dataset v4.
  • MobileNetV2 float وu8 مكممان بأحجام مختلفة، ويتم تشغيلهما مقابل مجموعة فرعية صغيرة (1500 صورة) من Open Images Dataset v4.
  • نموذج صوتي قائم على الذاكرة الطويلة قصيرة المدى (LSTM) لتحويل النص إلى كلام، يعمل مقابل مجموعة فرعية صغيرة من مجموعة CMU Arctic.
  • النموذج الصوتي القائم على LSTM للتعرف التلقائي على الكلام، يعمل مقابل مجموعة فرعية صغيرة من مجموعة بيانات LibriSpeech.

لمزيد من المعلومات، راجع platform/test/mlts/models .

اختبار الإجهاد

يتضمن Android Machine Learning Test Suite سلسلة من اختبارات الأعطال للتحقق من مرونة برامج التشغيل في ظل ظروف الاستخدام المكثف أو في الحالات الزاوية لسلوك العملاء.

توفر جميع اختبارات التصادم الميزات التالية:

  • اكتشاف التعليق: إذا توقف عميل NNAPI أثناء الاختبار، فسيفشل الاختبار مع سبب الفشل HANG وستنتقل مجموعة الاختبار إلى الاختبار التالي.
  • اكتشاف أعطال عميل NNAPI: تنجو الاختبارات من أعطال العميل وتفشل الاختبارات بسبب سبب الفشل CRASH .
  • اكتشاف تعطل برنامج التشغيل: يمكن للاختبارات اكتشاف تعطل برنامج التشغيل الذي يتسبب في حدوث فشل في استدعاء NNAPI. لاحظ أنه قد تكون هناك أعطال في عمليات برنامج التشغيل لا تتسبب في فشل NNAPI ولا تتسبب في فشل الاختبار. لتغطية هذا النوع من الفشل، يوصى بتشغيل الأمر tail في سجل النظام للأخطاء أو الأعطال المتعلقة ببرنامج التشغيل.
  • استهداف جميع المسرعات المتاحة: يتم إجراء الاختبارات على كافة برامج التشغيل المتوفرة.

جميع اختبارات التصادم لها النتائج الأربع المحتملة التالية:

  • SUCCESS : اكتمل التنفيذ بدون خطأ.
  • FAILURE : فشل التنفيذ. يحدث عادةً بسبب فشل عند اختبار النموذج، مما يشير إلى فشل برنامج التشغيل في ترجمة النموذج أو تنفيذه.
  • HANG : أصبحت عملية الاختبار غير مستجيبة.
  • CRASH : تعطلت عملية الاختبار.

لمزيد من المعلومات حول اختبار التحمل وقائمة كاملة باختبارات الأعطال، راجع platform/test/mlts/benchmark/README.txt .

استخدم MLTS

لاستخدام MLTS:

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

  2. cd في الدليل المصدر عالي المستوى لنظام Android.

    source build/envsetup.sh
lunch aosp_arm-userdebug # Or aosp_arm64-userdebug if available.
./test/mlts/benchmark/build_and_run_benchmark.sh

    في نهاية اختبار الأداء، يتم عرض النتائج كصفحة HTML وتمريرها إلى xdg-open .

لمزيد من المعلومات، راجع platform/test/mlts/benchmark/README.txt .

إصدارات HAL للشبكات العصبية

يصف هذا القسم التغييرات التي تم إدخالها في إصدارات Android وNeural Networks HAL.

أندرويد 11

يقدم Android 11 NN HAL 1.3، والذي يتضمن التغييرات الملحوظة التالية.

  • دعم تكميم 8 بت الموقعة في NNAPI. يضيف نوع المعامل TENSOR_QUANT8_ASYMM_SIGNED . يجب أن تدعم برامج التشغيل المزودة بـ NN HAL 1.3 والتي تدعم العمليات ذات القياس الكمي غير الموقعة أيضًا المتغيرات الموقعة لتلك العمليات. عند تشغيل الإصدارات الموقعة وغير الموقعة لمعظم العمليات الكمية، يجب أن تنتج برامج التشغيل نفس النتائج حتى إزاحة 128. هناك خمسة استثناءات لهذا المطلب: CAST و HASHTABLE_LOOKUP و LSH_PROJECTION و PAD_V2 و QUANTIZED_16BIT_LSTM . لا تدعم عملية QUANTIZED_16BIT_LSTM المعاملات الموقعة والعمليات الأربع الأخرى تدعم التكميم الموقع ولكنها لا تتطلب أن تكون النتائج هي نفسها.
  • دعم عمليات التنفيذ المسيجة حيث يستدعي إطار العمل أسلوب IPreparedModel::executeFenced لبدء تنفيذ مسيَّج وغير متزامن على نموذج مُجهز مع متجه لأسوار المزامنة للانتظار. لمزيد من المعلومات، راجع إعدام مسور .
  • دعم للتحكم في التدفق. إضافة عمليات IF و WHILE ، التي تأخذ نماذج أخرى كوسيطات وتنفذها بشكل مشروط ( IF ) أو بشكل متكرر ( WHILE ). لمزيد من المعلومات، راجع التحكم في التدفق .
  • تحسين جودة الخدمة (QoS) حيث يمكن للتطبيقات الإشارة إلى الأولويات النسبية لنماذجها، والحد الأقصى من الوقت المتوقع لإعداد النموذج، والحد الأقصى من الوقت المتوقع لإكمال التنفيذ. لمزيد من المعلومات، راجع جودة الخدمة .
  • دعم مجالات الذاكرة التي توفر واجهات المخصص للمخازن المؤقتة التي يديرها برنامج التشغيل. يسمح ذلك بتمرير الذكريات الأصلية للجهاز عبر عمليات التنفيذ، مما يمنع نسخ البيانات غير الضرورية وتحويلها بين عمليات التنفيذ المتتالية على نفس برنامج التشغيل. لمزيد من المعلومات، راجع مجالات الذاكرة .

أندرويد 10

يقدم Android 10 NN HAL 1.2، والذي يتضمن التغييرات الملحوظة التالية.

  • تتضمن بنية Capabilities جميع أنواع البيانات بما في ذلك أنواع البيانات العددية، وتمثل أداءً غير مريح باستخدام متجه بدلاً من الحقول المسماة.
  • تسمح أساليب getVersionString و getType لإطار العمل باسترداد نوع الجهاز ( DeviceType ) ومعلومات الإصدار. راجع اكتشاف الجهاز وتعيينه .
  • يتم استدعاء الأسلوب executeSynchronously بشكل افتراضي لتنفيذ التنفيذ بشكل متزامن. تخبر طريقة execute_1_2 إطار العمل بتنفيذ التنفيذ بشكل غير متزامن. انظر التنفيذ .
  • تحدد المعلمة MeasureTiming للتنفيذ executeSynchronously execute_1_2 وتنفيذ الاندفاع ما إذا كان برنامج التشغيل سيقيس مدة التنفيذ. يتم الإبلاغ عن النتائج في هيكل Timing . انظر التوقيت .
  • دعم عمليات التنفيذ حيث يكون لواحد أو أكثر من معاملات الإخراج بُعد أو رتبة غير معروفة. انظر شكل الإخراج .
  • دعم ملحقات البائعين، وهي عبارة عن مجموعات من العمليات وأنواع البيانات المحددة من قبل البائع. يقوم برنامج التشغيل بالإبلاغ عن الملحقات المدعومة من خلال طريقة IDevice::getSupportedExtensions . راجع ملحقات البائع .
  • قدرة كائن الاندفاع على التحكم في مجموعة من عمليات تنفيذ الاندفاع باستخدام قوائم انتظار الرسائل السريعة (FMQs) للتواصل بين عمليات التطبيق وبرنامج التشغيل، مما يقلل من زمن الوصول. راجع عمليات التنفيذ المتتابعة وقوائم انتظار الرسائل السريعة .
  • دعم AhardwareBuffer للسماح للسائق بتنفيذ عمليات التنفيذ دون نسخ البيانات. راجع AHardwareBuffer .
  • تحسين الدعم للتخزين المؤقت لعناصر التجميع لتقليل الوقت المستخدم للتجميع عند بدء تشغيل التطبيق. راجع التخزين المؤقت للتجميع .

يقدم Android 10 أنواع المعاملات والعمليات التالية.

  • أنواع المعامل

    • ANEURALNETWORKS_BOOL
    • ANEURALNETWORKS_FLOAT16
    • ANEURALNETWORKS_TENSOR_BOOL8
    • ANEURALNETWORKS_TENSOR_FLOAT16
    • ANEURALNETWORKS_TENSOR_QUANT16_ASYMM
    • ANEURALNETWORKS_TENSOR_QUANT16_SYMM
    • ANEURALNETWORKS_TENSOR_QUANT8_SYMM
    • ANEURALNETWORKS_TENSOR_QUANT8_SYMM_PER_CHANNEL

  • عمليات

    • ANEURALNETWORKS_ABS
    • ANEURALNETWORKS_ARGMAX
    • ANEURALNETWORKS_ARGMIN
    • ANEURALNETWORKS_AXIS_ALIGNED_BBOX_TRANSFORM
    • ANEURALNETWORKS_BIDIRECTIONAL_SEQUENCE_LSTM
    • ANEURALNETWORKS_BIDIRECTIONAL_SEQUENCE_RNN
    • ANEURALNETWORKS_BOX_WITH_NMS_LIMIT
    • ANEURALNETWORKS_CAST
    • ANEURALNETWORKS_CHANNEL_SHUFFLE
    • ANEURALNETWORKS_DETECTION_POSTPROCESSING
    • ANEURALNETWORKS_EQUAL
    • ANEURALNETWORKS_EXP
    • ANEURALNETWORKS_EXPAND_DIMS
    • ANEURALNETWORKS_GATHER
    • ANEURALNETWORKS_GENERATE_PROPOSALS
    • ANEURALNETWORKS_GREATER
    • ANEURALNETWORKS_GREATER_EQUAL
    • ANEURALNETWORKS_GROUPED_CONV_2D
    • ANEURALNETWORKS_HEATMAP_MAX_KEYPOINT
    • ANEURALNETWORKS_INSTANCE_NORMALIZATION
    • ANEURALNETWORKS_LESS
    • ANEURALNETWORKS_LESS_EQUAL
    • ANEURALNETWORKS_LOG
    • ANEURALNETWORKS_LOGICAL_AND
    • ANEURALNETWORKS_LOGICAL_NOT
    • ANEURALNETWORKS_LOGICAL_OR
    • ANEURALNETWORKS_LOG_SOFTMAX
    • ANEURALNETWORKS_MAXIMUM
    • ANEURALNETWORKS_MINIMUM
    • ANEURALNETWORKS_NEG
    • ANEURALNETWORKS_NOT_EQUAL
    • ANEURALNETWORKS_PAD_V2
    • ANEURALNETWORKS_POW
    • ANEURALNETWORKS_PRELU
    • ANEURALNETWORKS_QUANTIZE
    • ANEURALNETWORKS_QUANTIZED_16BIT_LSTM
    • ANEURALNETWORKS_RANDOM_MULTINOMIAL
    • ANEURALNETWORKS_REDUCE_ALL
    • ANEURALNETWORKS_REDUCE_ANY
    • ANEURALNETWORKS_REDUCE_MAX
    • ANEURALNETWORKS_REDUCE_MIN
    • ANEURALNETWORKS_REDUCE_PROD
    • ANEURALNETWORKS_REDUCE_SUM
    • ANEURALNETWORKS_RESIZE_NEAREST_NEIGHBOR
    • ANEURALNETWORKS_ROI_ALIGN
    • ANEURALNETWORKS_ROI_POOLING
    • ANEURALNETWORKS_RSQRT
    • ANEURALNETWORKS_SELECT
    • ANEURALNETWORKS_SIN
    • ANEURALNETWORKS_SLICE
    • ANEURALNETWORKS_SPLIT
    • ANEURALNETWORKS_SQRT
    • ANEURALNETWORKS_TILE
    • ANEURALNETWORKS_TOPK_V2
    • ANEURALNETWORKS_TRANSPOSE_CONV_2D
    • ANEURALNETWORKS_UNIDIRECTIONAL_SEQUENCE_LSTM
    • ANEURALNETWORKS_UNIDIRECTIONAL_SEQUENCE_RNN

يقدم Android 10 تحديثات للعديد من العمليات الحالية. تتعلق التحديثات بشكل أساسي بما يلي:

  • دعم تخطيط الذاكرة NCHW
  • دعم الموترات ذات الرتبة المختلفة عن 4 في عمليات softmax والتطبيع
  • دعم التلافيف المتوسعة
  • دعم المدخلات ذات القياس الكمي المختلط في ANEURALNETWORKS_CONCATENATION

تعرض القائمة أدناه العمليات التي تم تعديلها في Android 10. للحصول على التفاصيل الكاملة للتغييرات، راجع OperationCode في الوثائق المرجعية NNAPI.

  • ANEURALNETWORKS_ADD
  • ANEURALNETWORKS_AVERAGE_POOL_2D
  • ANEURALNETWORKS_BATCH_TO_SPACE_ND
  • ANEURALNETWORKS_CONCATENATION
  • ANEURALNETWORKS_CONV_2D
  • ANEURALNETWORKS_DEPTHWISE_CONV_2D
  • ANEURALNETWORKS_DEPTH_TO_SPACE
  • ANEURALNETWORKS_DEQUANTIZE
  • ANEURALNETWORKS_DIV
  • ANEURALNETWORKS_FLOOR
  • ANEURALNETWORKS_FULLY_CONNECTED
  • ANEURALNETWORKS_L2_NORMALIZATION
  • ANEURALNETWORKS_L2_POOL_2D
  • ANEURALNETWORKS_LOCAL_RESPONSE_NORMALIZATION
  • ANEURALNETWORKS_LOGISTIC
  • ANEURALNETWORKS_LSH_PROJECTION
  • ANEURALNETWORKS_LSTM
  • ANEURALNETWORKS_MAX_POOL_2D
  • ANEURALNETWORKS_MEAN
  • ANEURALNETWORKS_MUL
  • ANEURALNETWORKS_PAD
  • ANEURALNETWORKS_RELU
  • ANEURALNETWORKS_RELU1
  • ANEURALNETWORKS_RELU6
  • ANEURALNETWORKS_RESHAPE
  • ANEURALNETWORKS_RESIZE_BILINEAR
  • ANEURALNETWORKS_RNN
  • ANEURALNETWORKS_ROI_ALIGN
  • ANEURALNETWORKS_SOFTMAX
  • ANEURALNETWORKS_SPACE_TO_BATCH_ND
  • ANEURALNETWORKS_SPACE_TO_DEPTH
  • ANEURALNETWORKS_SQUEEZE
  • ANEURALNETWORKS_STRIDED_SLICE
  • ANEURALNETWORKS_SUB
  • ANEURALNETWORKS_SVDF
  • ANEURALNETWORKS_TANH
  • ANEURALNETWORKS_TRANSPOSE

أندرويد 9

تم تقديم NN HAL 1.1 في Android 9 ويتضمن التغييرات الملحوظة التالية.

  • يتضمن IDevice::prepareModel_1_1 معلمة ExecutionPreference . يمكن للسائق استخدام هذا لضبط إعداده، مع العلم أن التطبيق يفضل الحفاظ على البطارية أو أنه سيتم تنفيذ النموذج في مكالمات متتالية سريعة.
  • تمت إضافة تسع عمليات جديدة: BATCH_TO_SPACE_ND , DIV , MEAN , PAD , SPACE_TO_BATCH_ND , SQUEEZE , STRIDED_SLICE , SUB , TRANSPOSE .
  • يمكن للتطبيق تحديد أنه يمكن تشغيل حسابات تعويم 32 بت باستخدام نطاق تعويم 16 بت و/أو الدقة عن طريق تعيين Model.relaxComputationFloat32toFloat16 على true . تحتوي بنية Capabilities على حقل إضافي relaxedFloat32toFloat16Performance بحيث يمكن للسائق الإبلاغ عن أدائه المريح إلى إطار العمل.

أندرويد 8.1

تم إصدار الإصدار الأولي للشبكات العصبية HAL (1.0) في Android 8.1. لمزيد من المعلومات، راجع /neuralnetworks/1.0/ .