वल्कन उच्च-प्रदर्शन 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
एंड्रॉइड 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 डिवाइस वल्कन संस्करण का समर्थन करता है:
- Android संस्करण की अतिरिक्त सीडीडी आवश्यकताओं के साथ एक वल्कन ड्राइवर जोड़ें जो रुचि के वल्कन संस्करण का समर्थन करता है (यह वल्कन संस्करण 1.3, 1.1, या 1.0 में से एक होना चाहिए)। वैकल्पिक रूप से, कम वल्कन संस्करण संख्या के मौजूदा वल्कन ड्राइवर को अपडेट करें।
- वल्कन 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
फ़ाइल में निम्नानुसार दिखाए गए नियम को जोड़कर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.3 के लिए यह सुविधा है
विंडो सिस्टम इंटीग्रेशन (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 परीक्षणों को छोड़ देता है जो - इस फ़ीचर फ़्लैग के अनुसार - डिवाइस समर्थन का दावा नहीं करता है। इस तरह के परीक्षणों को तुच्छ रूप से पारित होने की सूचना दी जाती है।