स्मृति पूल

यह पृष्ठ ड्राइवर और फ्रेमवर्क के बीच ऑपरेंड बफ़र्स को कुशलतापूर्वक संचार करने के लिए उपयोग की जाने वाली डेटा संरचनाओं और विधियों का वर्णन करता है।

मॉडल संकलन समय पर, फ्रेमवर्क ड्राइवर को स्थिर ऑपरेंड के मान प्रदान करता है। स्थिर ऑपरेंड के जीवनकाल के आधार पर, इसके मान या तो HIDL वेक्टर या साझा मेमोरी पूल में स्थित होते हैं।

• यदि जीवनकाल CONSTANT_COPY है, तो मान मॉडल संरचना के operandValues फ़ील्ड में स्थित होते हैं। क्योंकि HIDL वेक्टर में मानों को इंटरप्रोसेस कम्युनिकेशन (IPC) के दौरान कॉपी किया जाता है, इसका उपयोग आमतौर पर केवल थोड़ी मात्रा में डेटा रखने के लिए किया जाता है जैसे कि स्केलर ऑपरेंड (उदाहरण के लिए, ADD में सक्रियण स्केलर) और छोटे टेंसर पैरामीटर (उदाहरण के लिए, RESHAPE में आकार टेंसर)।
• यदि जीवनकाल CONSTANT_REFERENCE है, तो मान मॉडल संरचना के pools फ़ील्ड में स्थित हैं। आईपीसी के दौरान कच्चे मूल्यों की प्रतिलिपि बनाने के बजाय केवल साझा मेमोरी पूल के हैंडल को डुप्लिकेट किया जाता है। इसलिए, एचआईडीएल वैक्टर की तुलना में साझा मेमोरी पूल का उपयोग करके बड़ी मात्रा में डेटा (उदाहरण के लिए, कनवल्शन में वजन पैरामीटर) रखना अधिक कुशल है।

मॉडल निष्पादन समय पर, फ्रेमवर्क ड्राइवर को इनपुट और आउटपुट ऑपरेंड के बफ़र्स प्रदान करता है। एचआईडीएल वेक्टर में भेजे जा सकने वाले संकलन-समय स्थिरांक के विपरीत, निष्पादन का इनपुट और आउटपुट डेटा हमेशा मेमोरी पूल के संग्रह के माध्यम से संचारित होता है।

HIDL डेटा प्रकार hidl_memory उपयोग अनमैप्ड साझा मेमोरी पूल का प्रतिनिधित्व करने के लिए संकलन और निष्पादन दोनों में किया जाता है। ड्राइवर को मेमोरी को hidl_memory डेटा प्रकार के नाम के आधार पर उपयोग योग्य बनाने के लिए तदनुसार मैप करना चाहिए। समर्थित मेमोरी नाम हैं:

• ashmem : एंड्रॉइड साझा मेमोरी। अधिक विवरण के लिए, मेमोरी देखें।
• mmap_fd : mmap के माध्यम से फ़ाइल डिस्क्रिप्टर द्वारा समर्थित साझा मेमोरी।
• hardware_buffer_blob : AHARDWARE_BUFFER_FORMAT_BLOB प्रारूप के साथ AHardwareBuffer द्वारा समर्थित साझा मेमोरी। न्यूरल नेटवर्क्स (एनएन) एचएएल 1.2 से उपलब्ध है। अधिक विवरण के लिए, AHardwareBuffer देखें।
• hardware_buffer : साझा मेमोरी एक सामान्य AHardwareBuffer द्वारा समर्थित है जो AHARDWARE_BUFFER_FORMAT_BLOB प्रारूप का उपयोग नहीं करता है। गैर-बीएलओबी मोड हार्डवेयर बफ़र केवल मॉडल निष्पादन में समर्थित है। एनएन एचएएल 1.2 से उपलब्ध है। अधिक विवरण के लिए, AHardwareBuffer देखें।

एनएन एचएएल 1.3 से, एनएनएपीआई मेमोरी डोमेन का समर्थन करता है जो ड्राइवर-प्रबंधित बफ़र्स के लिए एलोकेटर इंटरफ़ेस प्रदान करता है। ड्राइवर-प्रबंधित बफ़र्स का उपयोग निष्पादन इनपुट या आउटपुट के रूप में भी किया जा सकता है। अधिक विवरण के लिए, मेमोरी डोमेन देखें।

एनएनएपीआई ड्राइवरों को ashmem और mmap_fd मेमोरी नामों की मैपिंग का समर्थन करना चाहिए। एनएन एचएएल 1.3 से, ड्राइवरों को hardware_buffer_blob की मैपिंग का भी समर्थन करना चाहिए। सामान्य गैर-बीएलओबी मोड hardware_buffer और मेमोरी डोमेन के लिए समर्थन वैकल्पिक है।

एहार्डवेयरबफ़र

AHardwareBuffer एक प्रकार की साझा मेमोरी है जो Gralloc बफ़र को लपेटती है। एंड्रॉइड 10 में, न्यूरल नेटवर्क एपीआई (एनएनपीआई) एहार्डवेयरबफ़र का उपयोग करने का समर्थन करता है, जिससे ड्राइवर को डेटा कॉपी किए बिना निष्पादन करने की अनुमति मिलती है, जो ऐप्स के प्रदर्शन और बिजली की खपत में सुधार करती है। उदाहरण के लिए, एक कैमरा एचएएल स्टैक कैमरा एनडीके और मीडिया एनडीके एपीआई द्वारा उत्पन्न एहार्डवेयरबफर हैंडल का उपयोग करके मशीन लर्निंग वर्कलोड के लिए एहार्डवेयरबफर ऑब्जेक्ट को एनएनएपीआई में पास कर सकता है। अधिक जानकारी के लिए, ANeuralNetworksMemory_createFromAHardwareBuffer देखें।

एनएनएपीआई में प्रयुक्त एहार्डवेयरबफ़र ऑब्जेक्ट को hardware_buffer या hardware_buffer_blob नामक hidl_memory संरचना के माध्यम से ड्राइवर को पास किया जाता है। hidl_memory संरचना hardware_buffer_blob केवल AHARDWAREBUFFER_FORMAT_BLOB प्रारूप के साथ AHardwareBuffer ऑब्जेक्ट का प्रतिनिधित्व करता है।

फ़्रेमवर्क द्वारा आवश्यक जानकारी hidl_memory संरचना के hidl_handle फ़ील्ड में एन्कोड की गई है। hidl_handle फ़ील्ड native_handle लपेटता है, जो AHardwareBuffer या Gralloc बफर के बारे में सभी आवश्यक मेटाडेटा को एन्कोड करता है।

ड्राइवर को दिए गए hidl_handle फ़ील्ड को ठीक से डीकोड करना होगा और hidl_handle द्वारा वर्णित मेमोरी तक पहुंचना होगा। जब getSupportedOperations_1_2 , getSupportedOperations_1_1 , या getSupportedOperations विधि को कॉल किया जाता है, तो ड्राइवर को यह पता लगाना चाहिए कि क्या वह प्रदान किए गए hidl_handle डीकोड कर सकता है और hidl_handle द्वारा वर्णित मेमोरी तक पहुंच सकता है। यदि स्थिर ऑपरेंड के लिए उपयोग किया जाने वाला hidl_handle फ़ील्ड समर्थित नहीं है, तो मॉडल की तैयारी विफल होनी चाहिए। यदि निष्पादन के इनपुट या आउटपुट ऑपरेंड के लिए उपयोग किया जाने वाला hidl_handle फ़ील्ड समर्थित नहीं है, तो निष्पादन विफल होना चाहिए। यदि मॉडल तैयार करना या निष्पादन विफल हो जाता है, तो ड्राइवर को GENERAL_FAILURE त्रुटि कोड वापस करने की अनुशंसा की जाती है।

मेमोरी डोमेन

एंड्रॉइड 11 या उच्चतर चलाने वाले उपकरणों के लिए, एनएनएपीआई मेमोरी डोमेन का समर्थन करता है जो ड्राइवर-प्रबंधित बफ़र्स के लिए आवंटन इंटरफ़ेस प्रदान करता है। यह निष्पादन के दौरान डिवाइस की मूल यादों को पारित करने, अनावश्यक डेटा प्रतिलिपि को दबाने और एक ही ड्राइवर पर लगातार निष्पादन के बीच परिवर्तन की अनुमति देता है। यह प्रवाह चित्र 1 में दर्शाया गया है।

चित्र 1. मेमोरी डोमेन का उपयोग करके बफर डेटा प्रवाह

मेमोरी डोमेन सुविधा उन टेंसरों के लिए है जो अधिकतर ड्राइवर के लिए आंतरिक होते हैं और उन्हें क्लाइंट साइड पर बार-बार पहुंच की आवश्यकता नहीं होती है। ऐसे टेंसर के उदाहरणों में अनुक्रम मॉडल में राज्य टेंसर शामिल हैं। उन टेंसरों के लिए जिन्हें क्लाइंट साइड पर बार-बार सीपीयू एक्सेस की आवश्यकता होती है, साझा मेमोरी पूल का उपयोग करना बेहतर होता है।

मेमोरी डोमेन सुविधा का समर्थन करने के लिए, फ्रेमवर्क को ड्राइवर-प्रबंधित बफर आवंटन के लिए अनुरोध करने की अनुमति देने के लिए IDevice::allocate लागू करें। आवंटन के दौरान, फ्रेमवर्क बफ़र के लिए निम्नलिखित गुण और उपयोग पैटर्न प्रदान करता है:

• BufferDesc बफ़र के आवश्यक गुणों का वर्णन करता है।
• BufferRole एक तैयार मॉडल के इनपुट या आउटपुट के रूप में बफ़र के संभावित उपयोग पैटर्न का वर्णन करता है। बफ़र आवंटन के दौरान एकाधिक भूमिकाएँ निर्दिष्ट की जा सकती हैं, और आवंटित बफ़र का उपयोग केवल उन निर्दिष्ट भूमिकाओं के रूप में किया जा सकता है।

आवंटित बफ़र ड्राइवर के लिए आंतरिक है। ड्राइवर कोई भी बफ़र स्थान या डेटा लेआउट चुन सकता है। जब बफ़र सफलतापूर्वक आवंटित किया जाता है, तो ड्राइवर का क्लाइंट लौटाए गए टोकन या IBuffer ऑब्जेक्ट का उपयोग करके बफ़र को संदर्भित या इंटरैक्ट कर सकता है।

निष्पादन की Request संरचना में MemoryPool ऑब्जेक्ट्स में से एक के रूप में बफर को संदर्भित करते समय IDevice::allocate से टोकन प्रदान किया जाता है। किसी प्रक्रिया को किसी अन्य प्रक्रिया में आवंटित बफ़र तक पहुँचने का प्रयास करने से रोकने के लिए, ड्राइवर को बफ़र के प्रत्येक उपयोग पर उचित सत्यापन लागू करना होगा। ड्राइवर को यह सत्यापित करना होगा कि बफ़र उपयोग आवंटन के दौरान प्रदान की गई BufferRole भूमिकाओं में से एक है और यदि उपयोग अवैध है तो निष्पादन को तुरंत विफल कर देना चाहिए।

IBuffer ऑब्जेक्ट का उपयोग स्पष्ट मेमोरी कॉपी करने के लिए किया जाता है। कुछ स्थितियों में, ड्राइवर के क्लाइंट को साझा मेमोरी पूल से ड्राइवर-प्रबंधित बफ़र को प्रारंभ करना होगा या बफ़र को साझा मेमोरी पूल में कॉपी करना होगा। उदाहरण उपयोग के मामलों में शामिल हैं:

• राज्य टेंसर का आरंभीकरण
• मध्यवर्ती परिणाम कैशिंग
• सीपीयू पर फ़ॉलबैक निष्पादन

इन उपयोग मामलों का समर्थन करने के लिए, ड्राइवर को IBuffer::copyTo और IBuffer::copyFrom ashmem , mmap_fd , और hardware_buffer_blob के साथ लागू करना होगा यदि यह मेमोरी डोमेन आवंटन का समर्थन करता है। ड्राइवर के लिए गैर-बीएलओबी मोड hardware_buffer का समर्थन करना वैकल्पिक है।

बफ़र आवंटन के दौरान, बफ़र के आयामों को BufferRole द्वारा निर्दिष्ट सभी भूमिकाओं के संबंधित मॉडल ऑपरेंड और BufferDesc में प्रदान किए गए आयामों से निकाला जा सकता है। सभी आयामी जानकारी संयुक्त होने पर, बफ़र में अज्ञात आयाम या रैंक हो सकता है। ऐसे मामले में, बफर एक लचीली स्थिति में होता है जहां मॉडल इनपुट के रूप में उपयोग किए जाने पर आयाम तय होते हैं और मॉडल आउटपुट के रूप में उपयोग किए जाने पर गतिशील स्थिति में होते हैं। एक ही बफ़र का उपयोग अलग-अलग निष्पादन में आउटपुट के विभिन्न आकारों के साथ किया जा सकता है और ड्राइवर को बफ़र के आकार को ठीक से संभालना होगा।

मेमोरी डोमेन एक वैकल्पिक सुविधा है. एक ड्राइवर यह निर्धारित कर सकता है कि वह कई कारणों से दिए गए आवंटन अनुरोध का समर्थन नहीं कर सकता है। उदाहरण के लिए:

• अनुरोधित बफ़र का आकार गतिशील है.
• ड्राइवर के पास मेमोरी बाधाएँ हैं जो उसे बड़े बफ़र्स को संभालने से रोकती हैं।

ड्राइवर-प्रबंधित बफ़र से कई अलग-अलग थ्रेड्स को एक साथ पढ़ना संभव है। लिखने या पढ़ने/लिखने के लिए एक साथ बफर तक पहुंच अपरिभाषित है, लेकिन इसे ड्राइवर सेवा को क्रैश नहीं करना चाहिए या कॉलर को अनिश्चित काल तक ब्लॉक नहीं करना चाहिए। ड्राइवर कोई त्रुटि लौटा सकता है या बफ़र की सामग्री को अनिश्चित स्थिति में छोड़ सकता है।