वल्कन को लागू करना

वल्कन उच्च-प्रदर्शन 3D ग्राफिक्स के लिए एक कम-ओवरहेड, क्रॉस-प्लेटफ़ॉर्म API है। OpenGL ES (GLES) की तरह, वल्कन ऐप्स में उच्च-गुणवत्ता, रीयल-टाइम ग्राफ़िक्स बनाने के लिए टूल प्रदान करता है। वल्कन का उपयोग करने के लाभों में सीपीयू ओवरहेड में कमी और एसपीआईआर-वी बाइनरी इंटरमीडिएट भाषा के लिए समर्थन शामिल है।

नोट: यह खंड वल्कन कार्यान्वयन का वर्णन करता है; वल्कन आर्किटेक्चर, फायदे, एपीआई और अन्य संसाधनों के विवरण के लिए, वल्कन आर्किटेक्चर देखें।

वल्कन को सफलतापूर्वक लागू करने के लिए, एक उपकरण में शामिल होना चाहिए:

• Android द्वारा प्रदान किया गया वल्कन लोडर।
• GPU IHVs जैसे SoCs द्वारा प्रदान किया गया एक Vulkan ड्राइवर, जो Vulkan API को लागू करता है। वल्कन कार्यक्षमता का समर्थन करने के लिए, एंड्रॉइड डिवाइस को वल्कन-सक्षम जीपीयू हार्डवेयर और संबंधित ड्राइवर की आवश्यकता होती है। GPU को GLES 3.1 और उच्चतर का भी समर्थन करना चाहिए। ड्राइवर समर्थन का अनुरोध करने के लिए अपने एसओसी विक्रेता से परामर्श लें।

यदि किसी उपकरण में वल्कन ड्राइवर शामिल है, तो डिवाइस को डिवाइस की क्षमताओं को सटीक रूप से प्रतिबिंबित करने वाले संस्करणों के साथ FEATURE_VULKAN_HARDWARE_LEVEL और FEATURE_VULKAN_HARDWARE_VERSION सिस्टम सुविधाओं की घोषणा करने की आवश्यकता है। यह सुनिश्चित करने में मदद करता है कि डिवाइस संगतता परिभाषा दस्तावेज़ (सीडीडी) के अनुपालन में है।

वल्कन लोडर

वल्कन लोडर platform/frameworks/native/vulkan वल्कन वल्कन ऐप्स और डिवाइस के वल्कन ड्राइवर के बीच प्राथमिक इंटरफ़ेस है। वल्कन लोडर /system/lib[64]/libvulkan.so पर स्थापित है। लोडर कोर वल्कन एपीआई प्रवेश बिंदु, एंड्रॉइड सीडीडी द्वारा आवश्यक एक्सटेंशन के प्रवेश बिंदु और कई अतिरिक्त वैकल्पिक एक्सटेंशन प्रदान करता है। विंडो सिस्टम इंटीग्रेशन (WSI) एक्सटेंशन लोडर द्वारा निर्यात किए जाते हैं और मुख्य रूप से ड्राइवर के बजाय लोडर में लागू किए जाते हैं। लोडर एन्यूमरेटिंग और लोडिंग लेयर्स का भी समर्थन करता है जो अतिरिक्त एक्सटेंशन को उजागर कर सकते हैं और ड्राइवर के रास्ते में कोर एपीआई कॉल को इंटरसेप्ट कर सकते हैं।

एनडीके में लिंक करने के लिए एक स्टब libvulkan.so लाइब्रेरी शामिल है। पुस्तकालय लोडर के समान प्रतीकों का निर्यात करता है। ऐप्स लोडर में ट्रैम्पोलिन फ़ंक्शन दर्ज करने के लिए वास्तविक libvulkan.so लाइब्रेरी से निर्यात किए गए फ़ंक्शन को कॉल करते हैं, जो उनके पहले तर्क के आधार पर उपयुक्त परत या ड्राइवर को भेजते हैं। vkGet*ProcAddr() कॉल फ़ंक्शन पॉइंटर्स को लौटाता है, जिस पर ट्रैम्पोलिन प्रेषण (अर्थात, यह सीधे कोर एपीआई कोड में कॉल करता है)। निर्यात किए गए प्रतीकों के बजाय फ़ंक्शन पॉइंटर्स के माध्यम से कॉल करना अधिक कुशल है क्योंकि यह ट्रैम्पोलिन और प्रेषण को छोड़ देता है।

चालक गणना और लोडिंग

जब सिस्टम छवि बनाई जाती है, तो एंड्रॉइड सिस्टम को यह जानने की उम्मीद करता है कि कौन से जीपीयू उपलब्ध हैं। लोडर ड्राइवर को खोजने और लोड करने के लिए hardware.h में मौजूदा एचएएल तंत्र का उपयोग करता है। 32-बिट और 64-बिट वल्कन ड्राइवरों के लिए पसंदीदा पथ हैं:

/vendor/lib/hw/vulkan.<ro.hardware.vulkan>.so
/vendor/lib/hw/vulkan.<ro.product.platform>.so
/vendor/lib64/hw/vulkan.<ro.hardware.vulkan>.so
/vendor/lib64/hw/vulkan.<ro.product.platform>.so

नोट: <ro.hardware.vulkan> और <ro.product.platform> को उस नाम के सिस्टम गुण के मान से बदल दिया जाता है। विवरण और समर्थित वैकल्पिक स्थानों के लिए, libhardware/hardware.c देखें।

एंड्रॉइड 7.0 और उच्चतर में, वल्कन hw_module_t व्युत्पन्न एक एकल hw_module_t संरचना को लपेटता है; केवल एक ड्राइवर समर्थित है और निरंतर स्ट्रिंग HWVULKAN_DEVICE_0 को open() पर पास किया जाता है।

वल्कन hw_device_t व्युत्पन्न एक एकल ड्राइवर से मेल खाता है जो कई भौतिक उपकरणों का समर्थन कर सकता है। hw_device_t संरचना vkGetGlobalExtensionProperties() , vkCreateInstance() , और vkGetInstanceProcAddr() फ़ंक्शंस को निर्यात करने के लिए विस्तारित हो सकती है। लोडर hw_device_t संरचना के vkGetInstanceProcAddr() को कॉल करके अन्य सभी VkInstance() , VkPhysicalDevice() , और vkGetDeviceProcAddr() फ़ंक्शन ढूंढ सकता है।

परत की खोज और लोडिंग

वल्कन लोडर एन्यूमरेटिंग और लोडिंग लेयर्स का समर्थन करता है जो अतिरिक्त एक्सटेंशन को उजागर कर सकता है और ड्राइवर के रास्ते में कोर एपीआई कॉल को इंटरसेप्ट कर सकता है। Android में सिस्टम छवि पर परतें शामिल नहीं हैं; हालांकि, ऐप्स में उनके APK में परतें शामिल हो सकती हैं।

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

परतों के लिए उपयोग के मामलों में शामिल हैं:

• डेवलपमेंट-टाइम लेयर्स — प्रोडक्शन डिवाइसेज की सिस्टम इमेज पर ट्रेसिंग/प्रोफाइलिंग/डिबगिंग टूल्स के लिए वैलिडेशन लेयर्स और शिम इंस्टाल नहीं किया जाना चाहिए। ट्रेसिंग/प्रोफाइलिंग/डिबगिंग टूल के लिए सत्यापन परतें और शिम सिस्टम छवि के बिना अद्यतन करने योग्य होना चाहिए। डेवलपर जो विकास के दौरान इनमें से किसी एक परत का उपयोग करना चाहते हैं, उदाहरण के लिए, अपनी मूल लाइब्रेरी निर्देशिका में फ़ाइल जोड़कर ऐप पैकेज को संशोधित कर सकते हैं। IHV और OEM इंजीनियर जो अपरिवर्तनीय ऐप्स शिपिंग में विफलताओं का निदान करना चाहते हैं, उन्हें सिस्टम छवि के गैर-उत्पादन (रूट) बिल्ड तक पहुंच माना जाता है, जब तक कि वे ऐप्स डीबग करने योग्य न हों। अधिक जानकारी के लिए Android पर Vulkan सत्यापन परतें देखें।
• उपयोगिता परतें - ये परतें एक्सटेंशन को उजागर करती हैं, जैसे कि एक परत जो डिवाइस मेमोरी के लिए मेमोरी मैनेजर को लागू करती है। डेवलपर अपने ऐप में उपयोग करने के लिए परतें, और उन परतों के संस्करण चुनते हैं; एक ही परत का उपयोग करने वाले विभिन्न ऐप्स अभी भी विभिन्न संस्करणों का उपयोग कर सकते हैं। डेवलपर चुनते हैं कि इनमें से कौन सी परत उनके ऐप पैकेज में शिप की जाए।
• इंजेक्ट की गई (अंतर्निहित) परतें — इसमें फ्रेम दर, सोशल नेटवर्क और गेम लॉन्चर ओवरले जैसी परतें शामिल हैं जो उपयोगकर्ता या किसी अन्य ऐप द्वारा ऐप की जानकारी या सहमति के बिना प्रदान की जाती हैं। ये Android की सुरक्षा नीतियों का उल्लंघन करते हैं और समर्थित नहीं हैं।

गैर-डिबग करने योग्य ऐप्स के लिए, लोडर केवल ऐप की मूल लाइब्रेरी निर्देशिका में परतों की खोज करता है और किसी विशेष पैटर्न से मेल खाने वाले नाम के साथ किसी भी लाइब्रेरी को लोड करने का प्रयास करता है (उदाहरण के लिए, libVKLayer_foo.so )।

डिबग करने योग्य ऐप्स के लिए, लोडर /data/local/debug/vulkan में परतों की खोज करता है और किसी विशेष पैटर्न से मेल खाने वाली किसी लाइब्रेरी को लोड करने का प्रयास करता है।

एंड्रॉइड परतों को एंड्रॉइड और अन्य प्लेटफार्मों के बीच बिल्ड-एनवायरनमेंट परिवर्तनों के साथ पोर्ट करने में सक्षम बनाता है। लेयर्स और लोडर के बीच इंटरफेस के विवरण के लिए, वल्कन लोडर इंटरफेस का आर्किटेक्चर देखें। ख्रोनोस-रखरखाव सत्यापन परतें वल्कन सत्यापन परतों में होस्ट की जाती हैं।

वल्कन एपीआई संस्करण और क्षमताएं

निम्न तालिका कई Android रिलीज़ के लिए Vulkan API संस्करणों को सूचीबद्ध करती है।

Android संस्करण	वल्कन संस्करण
एंड्रॉइड 13	वल्कन 1.3
एंड्रॉइड 9	वल्कन 1.1
एंड्रॉइड 7	वल्कन 1.0

वल्कन 1.3 कार्यक्षमता अवलोकन

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

Android के लिए सबसे महत्वपूर्ण वल्कन 1.3 विशेषताएं हैं:

• सिंगल-पास रेंडर पास इंस्टेंस के लिए समर्थन
• एक शेडर आमंत्रण को तुरंत समाप्त करने के लिए समर्थन
• पाइपलाइन निर्माण, साझाकरण और नियंत्रण पर बेहतर विवरण

वल्कन 1.3 में कई छोटी विशेषताएं और एपीआई उपयोगिता संवर्द्धन भी शामिल हैं। मामूली संशोधन 1.3 के साथ कोर वल्कन एपीआई में किए गए सभी परिवर्तन कोर संशोधन (वल्कन 1.3) पर पाए जा सकते हैं।

वल्कन 1.2 कार्यक्षमता अवलोकन

वल्कन 1.2 कई विशेषताएं और एक्सटेंशन जोड़ता है जो एपीआई सतह को सरल बनाता है। इसमें एक एकीकृत मेमोरी मॉडल और अतिरिक्त जानकारी शामिल है जिसे डिवाइस ड्राइवर से पूछताछ की जा सकती है। वल्कन 1.2 में वल्कन 1.0 और 1.1 जैसी ही हार्डवेयर आवश्यकताएं हैं; सभी कार्यान्वयन एसओसी-विशिष्ट ग्राफिक्स ड्राइवर में हैं, ढांचे में नहीं।

एंड्रॉइड के लिए सबसे महत्वपूर्ण वल्कन 1.2 फीचर 8-बिट स्टोरेज के लिए सपोर्ट है।

वल्कन 1.2 में कई छोटी विशेषताएं और एपीआई उपयोगिता संवर्द्धन भी शामिल हैं। मामूली संशोधन 1.2 के साथ कोर वल्कन एपीआई में किए गए सभी परिवर्तन कोर संशोधन (वल्कन 1.2) पर पाए जा सकते हैं।

वल्कन 1.1 कार्यक्षमता अवलोकन

वल्कन 1.1 में मेमोरी/सिंक्रनाइज़ेशन इंटरऑप के लिए समर्थन शामिल है, जो ओईएम को उपकरणों पर वल्कन 1.1 का समर्थन करने में सक्षम बनाता है। इसके अतिरिक्त, मेमोरी/सिंक्रनाइज़ेशन इंटरऑप डेवलपर्स को यह निर्धारित करने में सक्षम बनाता है कि क्या वल्कन 1.1 डिवाइस पर समर्थित है, और जब यह है तो इसे प्रभावी ढंग से उपयोग करें। वल्कन 1.1 में वल्कन 1.0 जैसी ही हार्डवेयर आवश्यकताएं हैं, लेकिन अधिकांश कार्यान्वयन एसओसी-विशिष्ट ग्राफिक्स ड्राइवर में है, ढांचे में नहीं।

Android के लिए सबसे महत्वपूर्ण वल्कन 1.1 विशेषताएं हैं:

• Vulkan के बाहर से मेमोरी बफ़र्स और सिंक्रोनाइज़ेशन ऑब्जेक्ट्स को आयात और निर्यात करने के लिए समर्थन (कैमरा, कोडेक्स और GLES के साथ इंटरऑप के लिए)
• वाईसीबीसीआर प्रारूपों के लिए समर्थन

वल्कन 1.1 में कई छोटी विशेषताएं और एपीआई उपयोगिता संवर्द्धन भी शामिल हैं। मामूली संशोधन 1.1 के साथ कोर वल्कन एपीआई में किए गए सभी परिवर्तन कोर संशोधन (वल्कन 1.1) पर पाए जा सकते हैं।

वल्कन सपोर्ट चुनना

एंड्रॉइड डिवाइसों को उपलब्ध सबसे उन्नत वल्कन फीचर सेट का समर्थन करना चाहिए, बशर्ते वे 64-बिट एबीआई का समर्थन करें और कम मेमोरी न हों।

Android 13 और इसके बाद के संस्करण के साथ लॉन्च होने वाले उपकरणों को Vulkan 1.3 का समर्थन करना चाहिए।

Android 10 के माध्यम से लॉन्च होने वाले उपकरणों को Vulkan 1.1 का समर्थन करना चाहिए।

अन्य डिवाइस वैकल्पिक रूप से वल्कन 1.3, 1.2 और 1.1 का समर्थन कर सकते हैं।

एक वल्कन संस्करण का समर्थन

यदि निम्न शर्तें पूरी होती हैं, तो Android डिवाइस वल्कन संस्करण का समर्थन करता है:

1. Android संस्करण की अतिरिक्त सीडीडी आवश्यकताओं के साथ एक वल्कन ड्राइवर जोड़ें जो रुचि के वल्कन संस्करण का समर्थन करता है (यह वल्कन संस्करण 1.3, 1.1, या 1.0 में से एक होना चाहिए)। वैकल्पिक रूप से, कम वल्कन संस्करण संख्या के मौजूदा वल्कन ड्राइवर को अपडेट करें।
2. वल्कन 1.3 या 1.1 के लिए, सुनिश्चित करें कि पैकेज मैनेजर द्वारा लौटाया गया सिस्टम फीचर true वल्कन संस्करण के लिए सही है।
   • वल्कन 1.3 के लिए यह सुविधा है PackageManager#hasSystemFeature(PackageManager.FEATURE_VULKAN_HARDWARE_VERSION, 0x403000) ।
   • वल्कन 1.1 के लिए यह सुविधा है PackageManager#hasSystemFeature(PackageManager.FEATURE_VULKAN_HARDWARE_VERSION, 0x401000) ।
   पैकेज मैनेजर वल्कन 1.3 और वल्कन 1.1 के लिए एक उपयुक्त device.mk फ़ाइल में निम्नानुसार दिखाए गए नियम को जोड़कर true लौटाएगा।
   • वल्कन 1.3 के लिए निम्नलिखित जोड़ें:

     PRODUCT_COPY_FILES += frameworks/native/data/etc/android.hardware.vulkan.version-1_3.xml:
     $(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.vulkan.version.xml
     

   • वल्कन 1.1 के लिए निम्नलिखित जोड़ें:

     PRODUCT_COPY_FILES += frameworks/native/data/etc/android.hardware.vulkan.version-1_1.xml:
     $(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.vulkan.version.xml
     

नोट: कुछ ऐप्स डिवाइस पर उपलब्ध की तुलना में अधिक उन्नत वल्कन संस्करण पर निर्भर हो सकते हैं। ऐसे में ये ऐप्स डिवाइस पर नहीं चलेंगे। उदाहरण के लिए, जिन ऐप्स को वल्कन 1.1 की आवश्यकता होती है, वे उन उपकरणों पर नहीं चलेंगे जो केवल वल्कन 1.0 का समर्थन करते हैं। कुछ ऐप्स को नए वल्कन संस्करण की आवश्यकता नहीं हो सकती है, लेकिन डिवाइस पर नया संस्करण मौजूद होने पर अतिरिक्त सुविधाएं या बेहतर प्रदर्शन प्रदान कर सकते हैं।

विंडो सिस्टम इंटीग्रेशन (WSI)

libvulkan.so में, ड्राइवर निम्नलिखित विंडो सिस्टम इंटीग्रेशन (WSI) एक्सटेंशन लागू करता है:

• VK_KHR_surface
• VK_KHR_android_surface
• VK_KHR_swapchain
• VK_KHR_driver_properties , केवल Android 10 में वल्कन 1.1 के लिए लागू किया गया
• VK_GOOGLE_display_timing , Android 10 में किसी भी वल्कन संस्करण के लिए लागू किया गया

VkSurfaceKHR और VkSwapchainKHR ऑब्जेक्ट और ANativeWindow के साथ सभी इंटरैक्शन प्लेटफ़ॉर्म द्वारा नियंत्रित किए जाते हैं और ड्राइवरों के संपर्क में नहीं आते हैं। WSI कार्यान्वयन VK_ANDROID_native_buffer एक्सटेंशन पर निर्भर करता है, जिसे ड्राइवर द्वारा समर्थित होना चाहिए; यह एक्सटेंशन केवल WSI कार्यान्वयन द्वारा उपयोग किया जाता है और ऐप्स के संपर्क में नहीं आता है।

ग्रालोक उपयोग झंडे

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

typedef enum VkSwapchainImageUsageFlagBitsANDROID {
    VK_SWAPCHAIN_IMAGE_USAGE_SHARED_BIT_ANDROID = 0x00000001,
    VK_SWAPCHAIN_IMAGE_USAGE_FLAG_BITS_MAX_ENUM = 0x7FFFFFFF
} VkSwapchainImageUsageFlagBitsANDROID;
typedef VkFlags VkSwapchainImageUsageFlagsANDROID;

VkResult VKAPI vkGetSwapchainGrallocUsage2ANDROID(
    VkDevice                          device,
    VkFormat                          format,
    VkImageUsageFlags                 imageUsage,
    VkSwapchainImageUsageFlagsANDROID swapchainUsage,
    uint64_t*                         grallocConsumerUsage,
    uint64_t*                         grallocProducerUsage
);

format और छवि उपयोग पैरामीटर imageUsage संरचना से लिए VkSwapchainCreateInfoKHR हैं। ड्राइवर को प्रारूप और उपयोग के लिए आवश्यक ग्रेलोक उपयोग झंडे के साथ *grallocConsumerUsage और *grallocProducerUsage भरना चाहिए। ड्राइवर द्वारा लौटाए गए उपयोग झंडे को बफ़र्स आवंटित करते समय स्वैपचैन उपभोक्ता द्वारा अनुरोधित उपयोग झंडे के साथ जोड़ा जाता है।

Android 7.x VkSwapchainImageUsageFlagsANDROID() के पुराने संस्करण को कॉल करता है, जिसका नाम vkGetSwapchainGrallocUsageANDROID() । एंड्रॉइड 8.0 और उच्चतर vkGetSwapchainGrallocUsageANDROID() को हटा देता है लेकिन फिर भी vkGetSwapchainGrallocUsageANDROID() को कॉल करता है यदि vkGetSwapchainGrallocUsage2ANDROID() ड्राइवर द्वारा प्रदान नहीं किया जाता है:

VkResult VKAPI vkGetSwapchainGrallocUsageANDROID(
    VkDevice            device,
    VkFormat            format,
    VkImageUsageFlags   imageUsage,
    int*                grallocUsage
);

vkGetSwapchainGrallocUsageANDROID() स्वैपचैन उपयोग फ़्लैग या विस्तारित ग्रेलोक उपयोग फ़्लैग का समर्थन नहीं करता है।

ग्रैलोक-समर्थित छवियां

VkNativeBufferANDROID एक ग्रेलोक बफर द्वारा समर्थित छवि बनाने के लिए एक vkCreateImage एक्सटेंशन संरचना है। VkNativeBufferANDROID संरचना श्रृंखला में VkImageCreateInfo vkCreateImage() को VkNativeBufferANDROID प्रदान किया जाता है। vkCreateImage() को vkCreateSwapchainKHR के साथ कॉल करने के दौरान कॉल के दौरान VkNativeBufferANDROID होता है। WSI कार्यान्वयन स्वैपचैन के लिए अनुरोधित देशी बफ़र्स की संख्या आवंटित करता है, फिर प्रत्येक के लिए एक VkImage बनाता है:

typedef struct {
    VkStructureType             sType; // must be VK_STRUCTURE_TYPE_NATIVE_BUFFER_ANDROID
    const void*                 pNext;

    // Buffer handle and stride returned from gralloc alloc()
    buffer_handle_t             handle;
    int                         stride;

    // Gralloc format and usage requested when the buffer was allocated.
    int                         format;
    int                         usage;
    // Beginning in Android 8.0, the usage field above is deprecated and the
    // usage2 struct below was added. The usage field is still filled in for
    // compatibility with Android 7.0 drivers. Drivers for Android 8.0
    // should prefer the usage2 struct, especially if the
    // android.hardware.graphics.allocator HAL uses the extended usage bits.
    struct {
        uint64_t                consumer;
        uint64_t                producer;
    } usage2;
} VkNativeBufferANDROID;

ग्रैलोक-समर्थित छवि बनाते समय, VkImageCreateInfo में निम्न डेटा होता है:

  .sType               = VK_STRUCTURE_TYPE_IMAGE_CREATE_INFO
  .pNext               = the above VkNativeBufferANDROID structure
  .imageType           = VK_IMAGE_TYPE_2D
  .format              = a VkFormat matching the format requested for the gralloc buffer
  .extent              = the 2D dimensions requested for the gralloc buffer
  .mipLevels           = 1
  .arraySize           = 1
  .samples             = 1
  .tiling              = VK_IMAGE_TILING_OPTIMAL
  .usage               = VkSwapchainCreateInfoKHR::imageUsage
  .flags               = 0
  .sharingMode         = VkSwapchainCreateInfoKHR::imageSharingMode
  .queueFamilyCount    = VkSwapchainCreateInfoKHR::queueFamilyIndexCount
  .pQueueFamilyIndices = VkSwapchainCreateInfoKHR::pQueueFamilyIndices

एंड्रॉइड 8.0 और उच्चतर में, प्लेटफ़ॉर्म VkImageCreateInfo श्रृंखला में एक VkSwapchainImageCreateInfoKHR एक्सटेंशन संरचना प्रदान करता है, जो vkCreateImage को प्रदान किया जाता है जब vkCreateImage के लिए किसी भी स्वैपचैन छवि उपयोग झंडे की आवश्यकता होती है। विस्तार संरचना में स्वैपचैन छवि उपयोग झंडे शामिल हैं:

typedef struct {
    VkStructureType                        sType; // must be VK_STRUCTURE_TYPE_SWAPCHAIN_IMAGE_CREATE_INFO_ANDROID
    const void*                            pNext;

    VkSwapchainImageUsageFlagsANDROID      usage;
} VkSwapchainImageCreateInfoANDROID;

एंड्रॉइड 10 और उच्चतर में, प्लेटफॉर्म VK_KHR_swapchain v70 का समर्थन करता है, इसलिए वल्कन ऐप स्वैपचैन मेमोरी द्वारा समर्थित VkImage बनाने में सक्षम है। ऐप पहले vkCreateImage को VkImageCreateInfo संरचना के साथ VkImageSwapchainCreateInfoKHR संरचना से जंजीर से कॉल करता है। फिर ऐप VkBindImageMemoryInfo संरचना से बंधे VkBindImageMemorySwapchainInfoKHR संरचना के साथ vkBindImageMemory2(KHR) को कॉल करता है। imageIndex संरचना में निर्दिष्ट VkBindImageMemorySwapchainInfoKHR एक मान्य स्वैपचैन छवि अनुक्रमणिका होना चाहिए। इस बीच, प्लेटफ़ॉर्म VkBindImageMemoryInfo श्रृंखला के लिए संबंधित Gralloc बफर जानकारी के साथ एक VkNativeBufferANDROID एक्सटेंशन संरचना प्रदान करता है, इसलिए ड्राइवर जानता है कि VkImage को किस VkImage बफर से बांधना है।

छवियां प्राप्त करना

vkAcquireImageANDROID एक स्वैपचेन छवि का स्वामित्व प्राप्त करता है और एक मौजूदा VkSemaphore ऑब्जेक्ट और मौजूदा VkFence ऑब्जेक्ट दोनों में बाहरी रूप से संकेतित देशी बाड़ आयात करता है:

VkResult VKAPI vkAcquireImageANDROID(
    VkDevice            device,
    VkImage             image,
    int                 nativeFenceFd,
    VkSemaphore         semaphore,
    VkFence             fence
);

vkAcquireImageANDROID() को vkAcquireNextImageKHR के दौरान ऐप द्वारा प्रदान किए गए VkSemaphore और VkFence ऑब्जेक्ट्स में एक देशी बाड़ आयात करने के लिए कहा जाता है (हालाँकि, इस कॉल में सेमाफोर और फ़ेंस ऑब्जेक्ट दोनों वैकल्पिक हैं)। ड्राइवर इस अवसर का उपयोग ग्रेलोक बफर स्थिति में किसी बाहरी परिवर्तन को पहचानने और संभालने के लिए भी कर सकता है; कई ड्राइवरों को यहां कुछ भी करने की आवश्यकता नहीं होगी। यह कॉल VkSemaphore और VkFence को उसी लंबित स्थिति में रखता है जैसे कि vkQueueSubmit द्वारा संकेत दिया गया हो, इसलिए कतारें सेमाफोर पर प्रतीक्षा कर सकती हैं और ऐप बाड़ पर प्रतीक्षा कर सकता है।

जब अंतर्निहित देशी बाड़ संकेत देता है तो दोनों वस्तुएं संकेतित हो जाती हैं; यदि देशी बाड़ पहले ही संकेत दे चुकी है, तो सेमाफोर संकेतित अवस्था में है जब यह फ़ंक्शन वापस आता है। ड्राइवर फेंस फाइल डिस्क्रिप्टर का स्वामित्व लेता है और जरूरत न होने पर फेंस फाइल डिस्क्रिप्टर को बंद कर देता है। ड्राइवर को ऐसा करना चाहिए, भले ही न तो सेमाफोर या फेंस ऑब्जेक्ट प्रदान किया गया हो, या भले ही vkAcquireImageANDROID विफल हो और कोई त्रुटि लौटाए। यदि fenceFd -1 है, तो ऐसा लगता है कि देशी बाड़ पहले से ही संकेतित थी।

छवियों का विमोचन

vkQueueSignalReleaseImageANDROID बाहरी उपयोग के लिए एक स्वैपचैन छवि तैयार करता है, एक देशी बाड़ बनाता है, और इनपुट सेमाफोर के संकेत के बाद देशी बाड़ को सिग्नल करने के लिए शेड्यूल करता है:

VkResult VKAPI vkQueueSignalReleaseImageANDROID(
    VkQueue             queue,
    uint32_t            waitSemaphoreCount,
    const VkSemaphore*  pWaitSemaphores,
    VkImage             image,
    int*                pNativeFenceFd
);

vkQueuePresentKHR() प्रदान की गई कतार पर vkQueueSignalReleaseImageANDROID() ) को कॉल करता है। ड्राइवर को एक देशी बाड़ का उत्पादन करना चाहिए जो तब तक संकेत नहीं करता जब तक कि pWaitSemaphores सिग्नल में सभी waitSemaphoreCount सेमाफोर्स, और प्रस्तुति के लिए image तैयार करने के लिए आवश्यक कोई अतिरिक्त कार्य पूरा नहीं हो जाता।

यदि प्रतीक्षा सेमाफोर (यदि कोई हो) पहले से ही संकेतित है, और queue पहले से ही निष्क्रिय है, तो ड्राइवर वास्तविक देशी बाड़ फ़ाइल डिस्क्रिप्टर के बजाय *pNativeFenceFd -1 को -1 पर सेट कर सकता है, यह दर्शाता है कि प्रतीक्षा करने के लिए कुछ भी नहीं है। कॉलर *pNativeFenceFd में लौटाए गए फ़ाइल डिस्क्रिप्टर का मालिक है और उसे बंद कर देता है।

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

अगर छवि VK_SWAPCHAIN_IMAGE_USAGE_SHARED_BIT_ANDROID के साथ बनाई गई थी, तो ड्राइवर को vkQueueSignalReleaseImageANDROID() को vkAcquireImageANDROID() () पर कॉल में हस्तक्षेप किए बिना बार-बार कॉल करने की अनुमति देनी चाहिए।

साझा प्रस्तुत करने योग्य छवि समर्थन

विलंबता को कम करने के लिए कुछ डिवाइस डिस्प्ले पाइपलाइन और वल्कन कार्यान्वयन के बीच एकल छवि के स्वामित्व को साझा कर सकते हैं। Android 9 और उच्चतर में, लोडर vkGetPhysicalDeviceProperties2 पर ड्राइवर की प्रतिक्रिया के आधार पर VK_KHR_shared_presentable_image एक्सटेंशन का सशर्त विज्ञापन vkGetPhysicalDeviceProperties2 है।

यदि ड्राइवर वल्कन 1.1 या VK_KHR_physical_device_properties2 एक्सटेंशन का समर्थन नहीं करता है, तो लोडर साझा प्रस्तुत करने योग्य छवियों के लिए समर्थन का विज्ञापन नहीं करता है। अन्यथा, लोडर vkGetPhysicalDeviceProperties2() को कॉल करके और VkPhysicalDeviceProperties2::pNext श्रृंखला में निम्न संरचना को शामिल करके ड्राइवर क्षमताओं पर प्रश्नचिह्न लगाता है:

typedef struct {
    VkStructureType sType; // must be VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRESENTATION_PROPERTIES_ANDROID
    const void*     pNext;
    VkBool32        sharedImage;
} VkPhysicalDevicePresentationPropertiesANDROID;

यदि ड्राइवर किसी छवि के स्वामित्व को डिस्प्ले सिस्टम के साथ साझा कर सकता है, तो यह साझा इमेज सदस्य को sharedImage पर सेट VK_TRUE है।

मान्यकरण

ओईएम सीटीएस का उपयोग करके अपने वल्कन कार्यान्वयन का परीक्षण कर सकते हैं, जिसमें निम्नलिखित शामिल हैं:

• CtsDeqpTestCases मॉड्यूल में ख्रोनोस वल्कन अनुरूपता परीक्षण , जिसमें वल्कन 1.0, 1.1, 1.2 और 1.3 के लिए कार्यात्मक एपीआई परीक्षण शामिल हैं।
• CtsGraphicsTestCases मॉड्यूल, जो परीक्षण करता है कि डिवाइस को समर्थित वल्कन क्षमताओं के लिए सही तरीके से कॉन्फ़िगर किया गया है।

वल्कन फीचर फ्लैग

एक डिवाइस जो एंड्रॉइड 11 या उच्चतर का समर्थन करता है और जो वल्कन एपीआई का समर्थन करता है, को फीचर फ्लैग, android.software.vulkan.deqp.level को उजागर करने की आवश्यकता होती है। इस फ़ीचर फ़्लैग का मान एक दिनांक है, जिसे पूर्णांक मान के रूप में एन्कोड किया गया है। यह वल्कन डीईक्यूपी परीक्षणों से जुड़ी तारीख को निर्दिष्ट करता है जिसे डिवाइस पास करने का दावा करता है।

YYYY-MM-DD फॉर्म की एक तारीख को 32-बिट पूर्णांक के रूप में निम्नानुसार एन्कोड किया गया है:

• बिट्स 0-15 वर्ष स्टोर करें
• बिट्स 16-23 महीने में स्टोर करें
• बिट्स 24-31 दिन स्टोर करें

फ़ीचर फ़्लैग के लिए न्यूनतम अनुमत मान 0x07E30301 है, जो 2019-03-01 की तारीख से मेल खाती है, जो कि Android 10 के लिए वल्कन dEQP परीक्षणों से जुड़ी तारीख है। यदि फ़ीचर फ़्लैग कम से कम यह मान है, तो डिवाइस दावा करता है कि सभी Android 10 Vulkan dEQP परीक्षण पास करें।

मान 0x07E40301 तारीख 2020-03-01 से मेल खाती है, जो कि Android 11 के लिए वल्कन dEQP परीक्षणों से जुड़ी तारीख है। यदि फीचर फ्लैग कम से कम यह मान है, तो डिवाइस सभी Android 11 Vulkan dEQP परीक्षणों को पास करने का दावा करता है।

मान 0x07E60301 दिनांक 2022-03-01 से मेल खाता है, जो कि Android 13 के लिए Vulkan dEQP परीक्षणों से जुड़ी तिथि है। यदि फीचर फ्लैग कम से कम यह मान है, तो डिवाइस सभी Android 13 Vulkan dEQP परीक्षणों को पास करने का दावा करता है।

एक डिवाइस जो एक विशिष्ट फीचर फ्लैग ( यानी 0x07E30301 , 0x07E40301 , 0x07E60301 ) को उजागर करता है, उस फीचर फ्लैग (क्रमशः एंड्रॉइड 10, एंड्रॉइड 11, एंड्रॉइड 13) के सभी एंड्रॉइड वल्कन डीईक्यूपी टेस्ट पास करने का दावा करता है। यह डिवाइस बाद के Android रिलीज़ से Vulkan dEQP परीक्षण पास कर सकता है।

वल्कन डीईक्यूपी एंड्रॉइड सीटीएस का हिस्सा है। Android 11 से, CTS का dEQP टेस्ट रनर घटक android.software.vulkan.deqp.level फ़ीचर फ़्लैग से अवगत है, और किसी भी Vulkan dEQP परीक्षणों को छोड़ देता है जो - इस फ़ीचर फ़्लैग के अनुसार - डिवाइस समर्थन का दावा नहीं करता है। इस तरह के परीक्षणों को तुच्छ रूप से पारित होने की सूचना दी जाती है।