हैलो प्रिय पाठकों, प्रेमियों और प्रोग्रामिंग ग्राफिक्स के पेशेवरों! हम आपके ध्यान में मोबाइल उपकरणों के लिए रेंडरिंग के अनुकूलन के लिए समर्पित लेखों की एक श्रृंखला लाते हैं: आईओएस और एंड्रॉइड पर आधारित फोन और टैबलेट। चक्र में तीन भाग होंगे। पहले भाग में, हम मोबाइल पर लोकप्रिय जीपीयू टाइल वास्तुकला की विशेषताओं की जांच करेंगे । दूसरे में, हम आधुनिक उपकरणों में प्रस्तुत GPU के मुख्य परिवारों पर जाएंगे, और उनकी ताकत और कमजोरियों पर विचार करेंगे। तीसरे भाग में, हम shader अनुकूलन की विशेषताओं से परिचित होंगे।तो, पहले भाग के लिए नीचे आते हैं।बिजली की खपत पर महत्वपूर्ण प्रतिबंधों की अनुपस्थिति में डेस्कटॉप और कंसोल पर वीडियो कार्ड का विकास हुआ। मोबाइल उपकरणों के लिए वीडियो कार्ड के आगमन के साथ, इंजीनियरों को तुलनीय डेस्कटॉप रिज़ॉल्यूशन पर स्वीकार्य प्रदर्शन सुनिश्चित करने के कार्य के साथ सामना करना पड़ा, जबकि ऐसे वीडियो कार्ड की बिजली खपत परिमाण के 2 क्रम कम होनी चाहिए। टाइल आधारित रेंडरिंग (टीबीआर)
नामक एक विशेष वास्तुकला में समाधान पाया गया था । पीसी विकास में अनुभव वाले ग्राफिक्स प्रोग्रामर के लिए, जब वह मोबाइल विकास से परिचित हो जाता है, तो सब कुछ परिचित लगता है: एक समान OpenGL ES API का उपयोग किया जाता है, ग्राफिक्स पाइपलाइन की समान संरचना। हालाँकि, मोबाइल GPU के टाइल आर्किटेक्चर पीसी / इमीडिएट मोड कंसोल पर इस्तेमाल किए गए से काफी अलग हैं । टीबीआर की ताकत और कमजोरियों को जानने से आपको सही निर्णय लेने और मोबाइल के साथ शानदार प्रदर्शन करने में मदद मिलेगी।नीचे तीसरे दशक के लिए पीसी और कंसोल पर उपयोग किए जाने वाले क्लासिक ग्राफिक्स पाइपलाइन का एक सरल आरेख है।जियोमेट्री प्रोसेसिंग स्टेज पर, GPU वीडियो मेमोरी से वर्टेक्स विशेषताओं को पढ़ा जाता है। विभिन्न परिवर्तनों (वर्टेक्स शेडर) के बाद, मूल क्रम (एफआईएफओ) में रेडी-टू-रेंडर प्राइमेटर्स को रास्टराइज़र को पास किया जाता है, जो प्राइमरी को पिक्सेल में विभाजित करता है। उसके बाद, प्रत्येक पिक्सेल (फ्रैग्मेंट शेडर) का टुकड़ा प्रसंस्करण चरण किया जाता है , और प्राप्त रंग मान स्क्रीन बफर को लिखे जाते हैं, जो वीडियो मेमोरी में भी स्थित है। "तत्काल मोड" की पारंपरिक वास्तुकला की एक विशेषता स्क्रीन ड्रॉपर के मनमाने खंडों में फ्रैगमेंट शैडर के परिणाम की रिकॉर्डिंग है, जब एकल ड्रॉ कॉल की प्रक्रिया होती है। इस प्रकार, प्रत्येक ड्रा कॉल के लिए, पूरे स्क्रीन बफर तक पहुंच की आवश्यकता हो सकती है। मेमोरी के एक बड़े सरणी के साथ काम करने के लिए एक उपयुक्त बस बैंडविड्थ ( बैंडविड्थ ) की आवश्यकता होती है और यह उच्च बिजली की खपत से जुड़ा होता है। इसलिए, मोबाइल GPU ने एक अलग दृष्टिकोण लेना शुरू कर दिया। मोबाइल वीडियो कार्ड के विशिष्ट टाइल आर्किटेक्चर पर, स्क्रीन के भाग के अनुरूप मेमोरी के एक छोटे से टुकड़े में रेंडरिंग किया जाता है - टाइल। टाइल का छोटा आकार (उदा। माली वीडियो कार्ड के लिए 16x16 पिक्सेल, पावरवीआर के लिए 32x32) आपको इसे सीधे वीडियो कार्ड चिप पर रखने की अनुमति देता है, जो पहुंच की गति को शायाल कोर रजिस्टरों तक पहुंच की गति के बराबर बनाता है, अर्थात। बहुत तेज़।हालांकि, चूंकि प्राइमेटिव स्क्रीन बफर के मनमाने खंडों में गिर सकते हैं, और एक टाइल इसके केवल एक छोटे हिस्से को कवर करती है, ग्राफिक्स पाइपलाइन में एक अतिरिक्त कदम की आवश्यकता थी। निम्नलिखित एक सरलीकृत आरेख है कि पाइप लाइन टाइल वास्तुकला के साथ कैसे काम करती है।कोने को संसाधित करने और प्रिमिटिव का निर्माण करने के बाद, बाद में, खंड पाइपलाइन में भेजे जाने के बजाय, तथाकथित बॉयलर में गिर जाते हैं । यहां प्राइमिटिव्स टाइल्स द्वारा वितरित किए जाते हैं, जिनमें से वे गिर जाते हैं। इस तरह के वितरण के बाद, जो, एक नियम के रूप में, एक फ़्रेम बफर ऑब्जेक्ट (उर्फ रेंडर टारगेट ) को निर्देशित सभी ड्रॉ कॉल को कवर करता है , टाइल्स क्रमिक रूप से प्रदान की जाती हैं। प्रत्येक टाइल के लिए, क्रियाओं का निम्नलिखित क्रम किया जाता है:- सिस्टम मेमोरी ( लोड ) से पुरानी FBO सामग्री लोड हो रही है
- इस टाइल में गिरने वाले आदिमों के रेंडर
- सिस्टम मेमोरी ( स्टोर ) में नई FBO सामग्री अपलोड करना
यह ध्यान दिया जाना चाहिए कि लोड ऑपरेशन को संपीड़न के बिना "पूर्ण-स्क्रीन बनावट" का एक अतिरिक्त सुपरपोज़िशन माना जा सकता है। यदि संभव हो, तो इस ऑपरेशन से बचें, अर्थात्। FBO को आगे और पीछे स्विच करने की अनुमति न दें । यदि FBO में रेंडर करने से पहले इसकी सभी सामग्री साफ़ हो जाती है, तो लोड ऑपरेशन नहीं किया जाता है। हालांकि, ड्राइवर को सही संकेत भेजने के लिए, ऐसी सफाई के मापदंडों को कुछ मानदंडों को पूरा करना होगा:- अक्षम होना चाहिए कैंची पंथ
- सभी रंग चैनलों और अल्फा में रिकॉर्डिंग की अनुमति दी जानी चाहिए।
गहराई बफर और स्टेंसिल के लिए लोड ऑपरेशन को रोकने के लिए, उन्हें रेंडरिंग की शुरुआत से पहले साफ करने की भी आवश्यकता होती है। गहराई / स्टैंसिल बफर के लिए स्टोरऑपरेशन से बचना भी संभव है । आखिरकार, इन बफ़र्स की सामग्री को स्क्रीन पर किसी भी तरह से प्रदर्शित नहीं किया जाता है। GlSwapBuffers ऑपरेशन से पहले, आप glDiscardFramebufferEXT या glInvalidateFramebuffer कॉल कर सकते हैंconst GLenum attachments[] = {GL_DEPTH_ATTACHMENT, GL_STENCIL_ATTACHMENT};
glDiscardFramebufferEXT (GL_FRAMEBUFFER, 2, attachments);
const GLenum attachments[] = {GL_DEPTH_ATTACHMENT, GL_STENCIL_ATTACHMENT};
glInvalidateFramebuffer(GL_FRAMEBUFFER, 2, attachments);
ऐसे प्रतिपादन परिदृश्य हैं जिनमें गहराई / स्टेंसिल बफ़र्स की नियुक्ति, साथ ही सिस्टम मेमोरी में MSAA बफ़र्स की आवश्यकता नहीं है। उदाहरण के लिए, यदि गहराई बफ़र के साथ FBO में प्रतिपादन निरंतर है, और पिछले फ्रेम से गहराई की जानकारी का उपयोग नहीं किया जाता है, तो रेंडरिंग के पूरा होने से पहले गहराई बफर को टाइल मेमोरी में लोड करने की आवश्यकता नहीं होती है, या अनलोड होने के बाद। इसलिए, सिस्टम मेमोरी को गहराई बफर के तहत आवंटित नहीं किया जा सकता है। वल्कन और मेटल जैसे आधुनिक चित्रमय एपीआई आपको अपने FBO समकक्षों ( MTLStorageModeMemoryless in Metal, VK_IMAGE_USAGE_TRANSIENT_TACHMENT_BIT + में स्पष्ट रूप से मेमोरी मोड सेट करने की अनुमति देते हैं) VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT में Vulkan )। टाइल आर्किटेक्चर पर MSAAका विशेष रूप से ध्यान देना है । MSAA के लिए उच्च रिज़ॉल्यूशन बफर FBO को अधिक टाइलों में विभाजित करके टाइल मेमोरी को नहीं छोड़ता है । उदाहरण के लिए, MSAA 2x2 के लिए, 16x16 टाइलें स्टोर ऑपरेशन के दौरान 8x8 के रूप में हल की जाएंगी , अर्थात। कुल में, 4 गुना अधिक टाइलों को संसाधित करना आवश्यक होगा। लेकिन MSAA के लिए अतिरिक्त मेमोरी की आवश्यकता नहीं है, और फास्ट टाइल मेमोरी में रेंडरिंग के कारण कोई महत्वपूर्ण बैंडविड्थ प्रतिबंध नहीं होगा । हालाँकि उपयोग करेंMSAA टाइल वास्तुकला पर पर लोड बढ़ Tiler, जो नकारात्मक ज्यामिति का एक बहुत के साथ पर्दे के प्रतिपादन के प्रदर्शन को प्रभावित कर सकते हैं।उपरोक्त संक्षेप में, हम टाइल वास्तुकला पर FBO के साथ काम करने की वांछित योजना प्रस्तुत करते हैं:
glBindFramebuffer(GL_FRAMEBUFFER, auxFBO);
glDisable(GL_SCISSOR);
glColorMask(GL_TRUE, GL_TRUE, GL_TRUE, GL_TRUE);
glDepthMask(GL_TRUE);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT |
GL_STENCIL_BUFFER_BIT);
renderAuxFBO();
glInvalidateFramebuffer(GL_FRAMEBUFFER, 2, depth_and_stencil);
glBindFramebuffer(GL_FRAMEBUFFER, mainFBO);
glDisable(GL_SCISSOR);
glClear(...);
renderMainFBO(auxFBO);
glInvalidateFramebuffer(GL_FRAMEBUFFER, 2, depth_and_stencil);
यदि आप मुख्य एफबीबीओ के गठन के बीच में एसएफएफबीओ रेंडरिंग पर जाते हैं , तो आप अनावश्यक लोड और स्टोर संचालन प्राप्त कर सकते हैं , जो फ्रेम निर्माण समय को काफी बढ़ा सकता है। हमारे व्यवहार में, हमें निष्क्रिय FBO सेटिंग्स के मामले में भी प्रतिपादन में मंदी का सामना करना पड़ा, अर्थात। उनमें वास्तविक रेंडर के बिना। इंजन की वास्तुकला के कारण, हमारा पुराना सर्किट इस तरह दिखता था:
glBindFramebuffer(GL_FRAMEBUFFER, mainFBO);
glBindFramebuffer(GL_FRAMEBUFFER, auxFBO);
renderAuxFBO();
glBindFramebuffer(GL_FRAMEBUFFER, mainFBO);
renderMainFBO(auxFBO);
MainFBO
की पहली स्थापना के बाद ग्ल कॉल की कमी के बावजूद , कुछ उपकरणों पर हमें अतिरिक्त लोड और स्टोर संचालन और बदतर प्रदर्शन मिला। मध्यवर्ती FBOs के उपयोग से ओवरहेडकी हमारी समझ को बेहतर बनाने के लिए , हमने एक सिंथेटिक परीक्षण का उपयोग करके पूर्ण-स्क्रीन FBOs को बदलने के लिए समय की हानि को मापा । तालिका स्टोर ऑपरेशन पर खर्च किए गए समय को एक फ्रेम में कई बार एफबीओ स्विच करते समय दिखाती है (इस तरह के एक ऑपरेशन का समय दिया गया है)। लोड ऑपरेशन glClear के कारण अनुपस्थित है, अर्थात। अधिक अनुकूल परिदृश्य मापा गया। डिवाइस पर उपयोग की गई अनुमति ने योगदान दिया। यह स्थापित GPU की शक्ति के लिए कम या ज्यादा अनुरूप हो सकता है। इसलिए, ये आंकड़े केवल एक सामान्य विचार देते हैं कि विभिन्न पीढ़ियों के मोबाइल वीडियो कार्ड पर लक्ष्यों का स्विचिंग कितना महंगा है।प्राप्त आंकड़ों के आधार पर, हम सिफारिश कर सकते हैं कि वे प्रति फ्रेम एक या दो एफबीओ स्विच का उपयोग न करें, कम से कम किसी भी बच्चे के कार्ड के लिए। यदि गेम में लो-एंड डिवाइस के लिए एक अलग कोड पास है, तो वहां FBO परिवर्तन का उपयोग न करने की सलाह दी जाती है। हालाँकि, लो-एंड पर, रिज़ॉल्यूशन कम करने का मुद्दा अक्सर प्रासंगिक हो जाता है। Android पर, आप SurfaceHolder.setFixedSize () को कॉल करके एक मध्यवर्ती FBO का उपयोग किए बिना रेंडरिंग संकल्प को कम कर सकते हैं :surfaceView.getHolder().setFixedSize(...)
यदि खेल को मुख्य सरफेस एप्लिकेशन (मूल निवासी के साथ काम करने के लिए एक विशिष्ट योजना ) के माध्यम से प्रस्तुत किया जाता है तो यह विधि काम नहीं करेगी । यदि आप मुख्य भूतल का उपयोग करते हैं , तो मूल फ़ंक्शन ANativeWindow_setBuffersGeometry को कॉल करके कम रिज़ॉल्यूशन सेट किया जा सकता है ।JNIEXPORT void JNICALL Java_com_organization_app_AppNativeActivity_setBufferGeometry(JNIEnv *env, jobject thiz, jobject surface, jint width, jint height)
{
ANativeWindow* window = ANativeWindow_fromSurface(env, surface);
ANativeWindow_setBuffersGeometry(window, width, height, AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM);
}
जावा में:private static native void setBufferGeometry(Surface surface, int width , int height );
...
@Override public void surfaceChanged(SurfaceHolder holder, int format, int width, int height)
{
setBufferGeometry(holder.getSurface(), 768, 1366);
...
अंत में, हम एंड्रॉइड पर चयनित सतह बफ़र्स को नियंत्रित करने के लिए सुविधाजनक एडीबी कमांड का उल्लेख करते हैं:adb shell dumpsys surfaceflinger
आप एक समान निष्कर्ष प्राप्त कर सकते हैं जो आपको सतह बफ़र्स के लिए मेमोरी खपत का अनुमान लगाने की अनुमति देता है:स्क्रीनशॉट सिस्टम को दिखाता है कि GLSurfaceView गेम को ट्रिपल बफ़र करने के लिए 3 बफ़र्स को हाइलाइट किया गया है (पीले रंग में हाइलाइट किया गया), साथ ही मुख्य सरफेस के लिए 2 बफ़र्स (लाल रंग में हाइलाइट किया गया)। मूल सतह के माध्यम से प्रतिपादन के मामले में, जो मूल योजना का उपयोग करते हुए मूल निवासी है , अतिरिक्त बफ़र्स के आवंटन से बचा जा सकता है। अभी के लिए इतना ही। निम्नलिखित लेखों में, हम मोबाइल जीपीयू को वर्गीकृत करेंगे, साथ ही उनके लिए शेड का अनुकूलन करने के तरीकों का विश्लेषण करेंगे।