👩🏾‍🎤 👨🏻‍🎓 📧 डिज्नी कार्टून "मोआना" से एक दृश्य के प्रतिपादन का अनुकूलन। भाग 3 🤟🏼 💸 ↔️

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

पार्सर अनुकूलन

पिछले लेख में पेश किए गए प्रदर्शन सुधारों के बाद, पोबर पार्सर में बिताए समय का अनुपात और शुरुआत से ही इतना महत्वपूर्ण, स्वाभाविक रूप से और भी अधिक बढ़ गया। वर्तमान में, स्टार्टअप में पार्सर अधिकांश समय बिताया जाता है।

मैंने आखिरकार अपनी ताकत इकट्ठी की और खुद को पाइब्रेट दृश्यों के लिए एक लिखित टोकन और पार्सर के रूप में लागू किया । Pbrt दृश्य फ़ाइलों का प्रारूप पार्स करने के लिए बहुत सरल है: यदि आप उद्धृत पंक्तियों को ध्यान में नहीं रखते हैं, तो टोकन रिक्त स्थान से अलग हो जाते हैं, और व्याकरण बहुत सीधा है (एक टोकन के लिए आगे देखने की आवश्यकता कभी नहीं होती है), लेकिन आपका स्वयं का पार्सर कोड की एक हजार पंक्तियाँ हैं जिनकी आपको आवश्यकता है लिखना और डीबग करना। इसने मेरी मदद की कि इसे कई दृश्यों पर परखा जा सकता है; स्पष्ट glitches फिक्स करने के बाद, मैंने तब तक काम करना जारी रखा जब तक कि मैं पहले की तरह ही छवियों को प्रस्तुत करने में कामयाब नहीं हुआ: पार्सर की जगह लेने के कारण पिक्सेल में कोई अंतर नहीं होना चाहिए। इस स्तर पर, मुझे पूरा यकीन था कि सब कुछ सही ढंग से किया गया था।

मैंने संभव के रूप में जितना संभव हो सके नए संस्करण को बनाने की कोशिश की, इनपुट फ़ाइलों को mmap() जितना संभव हो सके और फ़ाइल के तार की प्रतियों के निर्माण को कम करने के लिए C ++ 17 से std::string_view के नए कार्यान्वयन का उपयोग किया। इसके अलावा, चूंकि strtod() ने पिछले ट्रैस में बहुत समय लिया, मैंने विशेष ध्यान के साथ parseNumber() लिखा: एकल-अंक पूर्णांक और नियमित पूर्णांकों को अलग-अलग संसाधित किया जाता है, और मानक मामले में जब 32-बिट फ्लोट का उपयोग करने के लिए संकलित किया जाता है , strtof() बजाय strtod() ^{1 का उपयोग किया} ।

नए पार्सर के कार्यान्वयन को बनाने की प्रक्रिया में, मुझे थोड़ा डर था कि पुराने पार्सर तेजी से होगा: अंत में, फ्लेक्स और बाइसन कई वर्षों से विकसित और अनुकूलित किए गए हैं। मैं पहले से पता नहीं लगा सका कि क्या नया संस्करण लिखने में हर समय बर्बाद हो जाएगा जब तक कि मैंने इसे पूरा नहीं किया और इसे ठीक से काम कर पाया।

मेरी खुशी के लिए, हमारे अपने पार्सर एक बड़ी जीत बन गए: फ्लेक्स और बाइसन के सामान्यीकरण ने प्रदर्शन को इतना कम कर दिया कि नया संस्करण आसानी से उनसे आगे निकल गया। नए पार्सर के लिए धन्यवाद, लॉन्च का समय घटकर 13 मिनट 21 एस हो गया, अर्थात, यह एक और 1.5 गुना तेज हो गया! एक अतिरिक्त बोनस यह था कि अब pbrt बिल्ड सिस्टम से सभी फ्लेक्स और बाइसन समर्थन को हटाना संभव था। यह हमेशा सिरदर्द रहा है, खासकर विंडोज के तहत, जहां ज्यादातर लोग इसे डिफ़ॉल्ट रूप से स्थापित नहीं करते हैं।

ग्राफिक्स स्थिति प्रबंधन

पार्सर को काफी तेज करने के बाद, एक नया कष्टप्रद विवरण सामने आया: इस स्तर पर, सेटअप का लगभग 10% समय कार्यों pbrtAttributeBegin() और pbrtAttributeEnd() पर बिताया गया था, और इस समय का अधिकांश हिस्सा आवंटित किया गया था और गतिशील मेमोरी जारी की गई थी। पहले रन के दौरान, जिसमें 35 मिनट लगे, इन कार्यों को निष्पादन समय का लगभग 3% ही लिया गया, इसलिए उन्हें अनदेखा किया जा सकता है। लेकिन अनुकूलन के साथ यह हमेशा ऐसा होता है: जब आप बड़ी समस्याओं से छुटकारा पाने लगते हैं, तो छोटे महत्वपूर्ण हो जाते हैं।

Pbrt दृश्य विवरण ग्राफिक के पदानुक्रमित स्थिति पर आधारित है, जो वर्तमान परिवर्तन, वर्तमान सामग्री, और इसी तरह से इंगित करता है। इसमें, आप वर्तमान स्थिति ( pbrtAttributeBegin() ) के स्नैपशॉट बना सकते हैं, दृश्य में नई ज्यामिति जोड़ने से पहले उसमें परिवर्तन कर सकते हैं और फिर मूल स्थिति ( pbrtAttributeEnd() ) पर वापस आ सकते हैं।

ग्राफिक्स राज्य एक अप्रत्याशित नाम के साथ एक संरचना में संग्रहीत किया जाता है ... GraphicsState । बचाया ग्राफिक्स राज्यों के ढेर में GraphicsState वस्तुओं की प्रतियां संग्रहीत करने के लिए, std::vector । GraphicsState सदस्यों को देखते हुए, हम समस्याओं के स्रोत को मान सकते हैं - तीन std::map , नाम से लेकर बनावट और सामग्री के उदाहरण:

 struct GraphicsState { // ... std::map<std::string, std::shared_ptr<Texture<Float>>> floatTextures; std::map<std::string, std::shared_ptr<Texture<Spectrum>>> spectrumTextures; std::map<std::string, std::shared_ptr<MaterialInstance>> namedMaterials; };

इन दृश्य फ़ाइलों की जाँच करते हुए, मैंने पाया कि ग्राफिक्स स्टेट्स को सहेजने और पुनर्स्थापित करने के अधिकांश मामले इन पंक्तियों में किए गए हैं:

 AttributeBegin ConcatTransform [0.981262 0.133695 -0.138749 0.000000 -0.067901 0.913846 0.400343 0.000000 0.180319 -0.383420 0.905800 0.000000 11.095301 18.852249 9.481399 1.000000] ObjectInstance "archivebaycedar0001_mod" AttributeEnd

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

मैंने इन मानचित्रों में से प्रत्येक को सूचक std::shared_ptr के साथ मैप में बदल दिया और कॉपी-ऑन-राइट दृष्टिकोण को लागू किया, जिसमें किसी विशेषता के आरंभ / अंत ब्लॉक के अंदर कॉपी करना केवल तब होता है जब इसकी सामग्री को बदलने की आवश्यकता होती है। परिवर्तन विशेष रूप से मुश्किल नहीं था, लेकिन इसने लॉन्च समय को एक मिनट से अधिक कम कर दिया, जिसने हमें 12 मिनट 20 एस प्रसंस्करण शुरू करने से पहले प्रदान किया - फिर से 1.08 बार का त्वरण।

समय प्रतिपादन के बारे में क्या?

एक चौकस पाठक ध्यान देगा कि अभी तक मैंने प्रतिपादन के समय के बारे में कुछ नहीं कहा है। मेरे आश्चर्य करने के लिए, यह बॉक्स से बाहर भी काफी सहनीय निकला: पोट्र दो सौ से तीन घंटे की अवधि में बारह प्रोसेसर कोर पर प्रति पिक्सेल कई सौ नमूनों के साथ सिनेमाई गुणवत्ता के दृश्यों की छवियों को प्रस्तुत कर सकता है। उदाहरण के लिए, यह छवि, सबसे धीमी में से एक, 2 घंटे 51 मिनट 36 सेकंड में प्रस्तुत की गई:

मून से टिब्बा 256 पिक्सेल प्रति पिक्सेल के 2048x858 के संकल्प के साथ pbrt-v3 द्वारा प्रस्तुत किया गया। Google Compute Engine की आवृत्ति पर 12 कोर / 24 थ्रेड्स के साथ 2 GHz की आवृत्ति और pbrt-v3 का नवीनतम संस्करण 2 घंटे 51 मिनट 36 सेकंड था।

मेरी राय में, यह आश्चर्यजनक रूप से उचित संकेतक की तरह लगता है। मुझे यकीन है कि अभी भी सुधार संभव हैं, और जिन स्थानों पर अधिकांश समय बिताया जाता है, उनका सावधानीपूर्वक अध्ययन बहुत सारी "दिलचस्प" चीजों को प्रकट करेगा, लेकिन अभी तक उनके लिए कोई विशेष कारण नहीं हैं।

प्रोफाइलिंग करते समय, यह पता चला कि रेंडरिंग के समय का लगभग 60% समय वस्तुओं के साथ किरणों के चौराहे पर बिताया गया था (अधिकांश ऑपरेशन बीवीएच को दरकिनार करके किए गए थे), और 25% खर्च किया गया था। ये अनुपात सरल दृश्यों के संकेतक के समान हैं, इसलिए पहली नज़र में यहाँ स्पष्ट रूप से समस्याग्रस्त कुछ भी नहीं है। (हालांकि, मुझे यकीन है कि एम्ब्री थोड़ा कम समय में इन किरणों का पता लगाने में सक्षम होगी।)

दुर्भाग्य से, समानांतर मापनीयता इतनी अच्छी नहीं है। मैं आमतौर पर देखता हूं कि 2400% (Google कंप्यूट इंजन में 24 वर्चुअल सीपीयू पर) के आदर्श की तुलना में 1400% सीपीयू संसाधन खर्च किए जाते हैं। ऐसा लगता है कि समस्या पॉक्स में ताले के दौरान संघर्ष से संबंधित है, लेकिन मैंने अभी तक इसकी अधिक विस्तार से जांच नहीं की है। यह बहुत संभावना है कि pbrt-v3 किरण ट्रेसर में अप्रत्यक्ष किरणों के लिए किरण अंतर की गणना नहीं करता है; बदले में, ऐसे बीम हमेशा बनावट के सबसे विस्तृत एमआईपी स्तर तक पहुंच प्राप्त करते हैं, जो बनावट कैशिंग के लिए बहुत उपयोगी नहीं है।

निष्कर्ष (pbrt-v3 के लिए)

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

सामान्य तौर पर, प्रगति गंभीर थी: रेंडरिंग से पहले लॉन्च का समय 35 मिनट से घटकर 12 मिनट 20 सेकंड था, यानी कुल त्वरण 2.83 गुना था। इसके अलावा, रूपांतरण कैश के साथ चतुर काम के लिए धन्यवाद, मेमोरी का उपयोग 80 जीबी से घटकर 69 जीबी हो गया है। ये सभी परिवर्तन अभी उपलब्ध हैं यदि आप pbrt-v3 के नवीनतम संस्करण के साथ सिंक्रनाइज़ कर रहे हैं (या यदि आपने पिछले कुछ महीनों में ऐसा किया है।) और हमें समझ में आता है कि इस दृश्य के लिए Primitive स्मृति कितनी कचरा है; हमने पता लगाया कि एक और 18 जीबी मेमोरी को कैसे बचाया जाए, लेकिन इसे pbrt-v3 में लागू नहीं किया।

यहाँ हमारी सभी अनुकूलन के बाद इन 12 मिनट 20 एस पर खर्च किया जाता है:

समारोह / ऑपरेशन	रंटाइम का प्रतिशत
बीवीएच का निर्माण करें	34%
पार्सिंग ( `strtof()` को छोड़कर)	21%
`strtof()`	20%
रूपांतरण कैश	7%
PLY फ़ाइलें पढ़ना	6%
गतिशील स्मृति आवंटन	5%
रूपांतरण उलटा	2%
ग्राफिक्स स्थिति प्रबंधन	2%
अन्य	3%

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

कुछ बिंदु पर, मैं देखूंगा कि क्या strtof() का तेज़ कार्यान्वयन है; pbrt केवल वही प्रदान करता है जो सिस्टम प्रदान करता है। हालांकि, आपको उन प्रतिस्थापनों की पसंद से सावधान रहना चाहिए जो बहुत अच्छी तरह से परीक्षण नहीं किए गए हैं: फ्लोटिंग मानों को पार्स करना उन पहलुओं में से एक है जो प्रोग्रामर को पूरी तरह से निश्चित होना चाहिए।

यह पार्सर पर लोड को और कम करने के लिए आकर्षक लग रहा है: हमारे पास अभी भी पार्सिंग के लिए 17 जीबी टेक्स्ट इनपुट फाइलें हैं। हम pbrt इनपुट फ़ाइलों के लिए बाइनरी एन्कोडिंग समर्थन जोड़ सकते हैं (संभवतः रेंडरमैन दृष्टिकोण के समान), लेकिन मुझे इस विचार के बारे में मिश्रित भावनाएं हैं; पाठ संपादक में दृश्य विवरण फ़ाइलों को खोलने और संशोधित करने की क्षमता काफी उपयोगी है, और मुझे चिंता है कि कभी-कभी बाइनरी कोडिंग छात्रों को सीखने की प्रक्रिया में pbrt का उपयोग करने के लिए भ्रमित करेगा। यह उन मामलों में से एक है जहां उत्पादन स्तर के वाणिज्यिक रेंडर के लिए pbrt का सही समाधान समाधान से भिन्न हो सकता है।

इन सभी आशाओं पर नज़र रखना और विभिन्न समाधानों को बेहतर ढंग से समझना बहुत दिलचस्प था। यह पता चला कि pbrt में अप्रत्याशित धारणाएं हैं जो इस स्तर की जटिलता के दृश्य के साथ हस्तक्षेप करती हैं। यह सब इस बात का एक बड़ा उदाहरण है कि शोधकर्ताओं के एक विस्तृत समुदाय के लिए यह कितना महत्वपूर्ण है कि उच्च स्तर की जटिलता के साथ वास्तविक उत्पादन दृश्यों तक पहुंच हो; मैं फिर से इस दृश्य को संसाधित करने और इसे सार्वजनिक डोमेन में डालने के लिए डिज़नी को बहुत धन्यवाद देता हूं।

अगले लेख में , हम उन पहलुओं पर ध्यान देंगे जो प्रदर्शन को और बेहतर बना सकते हैं यदि हम और अधिक मौलिक परिवर्तन करने की अनुमति देते हैं।

टिप्पणी

Linux सिस्टम पर मैं परीक्षण कर रहा था, strtof() तेज नहीं है। यह उल्लेखनीय है कि ओएस एक्स strtod() लगभग दो गुना तेज है, जो पूरी तरह से अतार्किक है। व्यावहारिक कारणों से, मैंने strtof() का उपयोग करना जारी रखा।

डिज्नी कार्टून "मोआना" से एक दृश्य के प्रतिपादन का अनुकूलन। भाग 3

पार्सर अनुकूलन

ग्राफिक्स स्थिति प्रबंधन

समय प्रतिपादन के बारे में क्या?

निष्कर्ष (pbrt-v3 के लिए)

टिप्पणी

More articles: