वल्कन लागू करें

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

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

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

यदि किसी डिवाइस में वल्कन ड्राइवर शामिल है, तो डिवाइस को 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

एंड्रॉइड 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( vkGetInstanceProcAddr() को कॉल करके अन्य सभी VkInstance() , VkPhysicalDevice() , और vkGetDeviceProcAddr() फ़ंक्शन ढूंढ सकता है।

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

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

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

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

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

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

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

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

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

निम्न तालिका कई एंड्रॉइड रिलीज़ के लिए वल्कन एपीआई संस्करणों को सूचीबद्ध करती है।
एंड्रॉइड संस्करण वल्कन संस्करण
एंड्रॉइड 13 वल्कन 1.3
एंड्रॉइड 9 वल्कन 1.1
एंड्रॉइड 7 वल्कन 1.0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

वल्कन समर्थन चुनें

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

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

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

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

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

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

  1. एंड्रॉइड संस्करण की अतिरिक्त सीडीडी आवश्यकताओं के साथ एक वल्कन ड्राइवर जोड़ें जो रुचि के वल्कन संस्करण का समर्थन करता है (यह वल्कन संस्करण 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) .
    पैकेज प्रबंधक एक उपयुक्त device.mk फ़ाइल में निम्नानुसार दिखाए गए एक नियम को जोड़कर वल्कन 1.3 और वल्कन 1.1 के लिए 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
      

एंड्रॉइड बेसलाइन प्रोफ़ाइल (एबीपी)

हम सभी एंड्रॉइड डिवाइसों को एंड्रॉइड बेसलाइन प्रोफाइल गाइड में उल्लिखित नवीनतम एंड्रॉइड बेसलाइन 2022 प्रोफाइल के अनुरूप होने के लिए प्रोत्साहित करते हैं।

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

  • एएसटीसी और ईटीसी के माध्यम से संपीड़ित बनावट।
  • VK_EXT_swapchain_colorspace के माध्यम से परिवर्तनीय कलरस्पेस।
  • sampleRateShading के माध्यम से सैंपल शेडिंग और मल्टीसैंपल इंटरपोलेशन।

विंडो सिस्टम एकीकरण (डब्ल्यूएसआई)

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

  • VK_KHR_surface
  • VK_KHR_android_surface
  • VK_KHR_swapchain
  • VK_KHR_driver_properties , केवल एंड्रॉइड 10 में वल्कन 1.1 के लिए लागू किया गया
  • VK_GOOGLE_display_timing , एंड्रॉइड 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 संरचना से लिए गए हैं। ड्राइवर को प्रारूप और उपयोग के लिए आवश्यक Gralloc उपयोग फ़्लैग के साथ *grallocConsumerUsage और *grallocProducerUsage भरना चाहिए। बफ़र्स आवंटित करते समय ड्राइवर द्वारा लौटाए गए उपयोग फ़्लैग को स्वैपचेन उपभोक्ता द्वारा अनुरोध किए गए उपयोग फ़्लैग के साथ जोड़ दिया जाता है।

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

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

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

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

VkNativeBufferANDROID Gralloc बफर द्वारा समर्थित छवि बनाने के लिए एक vkCreateImage एक्सटेंशन संरचना है। VkNativeBufferANDROID VkImageCreateInfo संरचना श्रृंखला में vkCreateImage() को प्रदान किया जाता है। VkNativeBufferANDROID के साथ vkCreateImage() पर कॉल vkCreateSwapchainKHR पर कॉल के दौरान होती है। 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;

Gralloc-समर्थित छवि बनाते समय, 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 को प्रदान की जाती है जब स्वैपचैन के लिए किसी भी स्वैपचैन छवि उपयोग झंडे की आवश्यकता होती है। विस्तार संरचना में स्वैपचेन छवि उपयोग झंडे शामिल हैं:

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 बनाने में सक्षम है। ऐप सबसे पहले VkImageSwapchainCreateInfoKHR संरचना के साथ vkCreateImage कॉल करता है जो VkImageCreateInfo संरचना से जुड़ी होती है। फिर ऐप vkBindImageMemory2(KHR) को VkBindImageMemorySwapchainInfoKHR संरचना के साथ कॉल करता है जो VkBindImageMemoryInfo संरचना से जुड़ी होती है। VkBindImageMemorySwapchainInfoKHR संरचना में निर्दिष्ट imageIndex एक वैध स्वैपचैन छवि सूचकांक होना चाहिए। इस बीच, प्लेटफ़ॉर्म VkBindImageMemoryInfo श्रृंखला के लिए संबंधित Gralloc बफर जानकारी के साथ एक VkNativeBufferANDROID एक्सटेंशन संरचना प्रदान करता है, ताकि ड्राइवर को पता चले कि VkImage को किस Gralloc बफर के साथ बांधना है।

छवियाँ प्राप्त करें

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

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

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

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

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

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

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

यदि ड्राइवर Vulkan 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 से मेल खाता है, जो एंड्रॉइड 10 के लिए वल्कन dEQP परीक्षणों से जुड़ी तारीख है। यदि फ़ीचर फ़्लैग कम से कम यह मान है, तो डिवाइस का दावा है सभी Android 10 Vulkan dEQP परीक्षण पास करें।

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

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

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

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