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

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

यहाँ आधुनिक pbrt के साथ एक दृश्य को प्रस्तुत करने का परिणाम कैसा दिखता है:


मोआना से एक द्वीप 2048x858 के संकल्प पर pbrt-v3 द्वारा प्रति पिक्सेल 256 नमूनों के साथ प्रदान किया गया। Pbrt-v3 के नवीनतम संस्करण के साथ 2 GHz की आवृत्ति के साथ Google कंप्यूट इंजन के 12-कोर / 24-थ्रेड उदाहरण पर कुल रेंडरिंग समय 1 घंटे 44 मिनट 45 सेकेंड था।

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

इस दृश्य ने मुझे पहले से ही बहुत कुछ सिखाया है और मुझे pbrt रेंडरर में सुधार करने की अनुमति दी है, लेकिन इससे पहले कि हम इस पर विचार करें, मैं संदर्भ को समझने के लिए एक छोटी कहानी बताऊंगा।

वह हैश जो नहीं था

कई साल पहले, पिक्सर रेंडरिंग टीम में इंटर्नशिप करते समय, मैंने एक जिज्ञासु सबक सीखा: "दिलचस्प" चीजें लगभग हमेशा दिखाई देती हैं जब इनपुट डेटा प्रोग्राम सिस्टम को पास किया जाता है जो कि उस सब से अलग है जो पहले था। यहां तक ​​कि अच्छी तरह से लिखित और परिपक्व सॉफ्टवेयर सिस्टम में, नए प्रकार के इनपुट लगभग हमेशा एक मौजूदा कार्यान्वयन में अज्ञात दोषों की खोज की ओर ले जाते हैं।

मैंने पहली बार टॉय स्टोरी 2 के निर्माण के दौरान यह सबक सीखा था। एक दिन, किसी ने देखा कि आरआईबी दृश्य विवरण फ़ाइलों को पार्स करने के लिए समय की एक अद्भुत राशि खर्च की गई थी। रेंडरिंग टीम से किसी और (मुझे लगता है कि यह क्रेग कोलब था) ने प्रोफाइलर को लॉन्च किया और यह पता लगाना शुरू कर दिया।

यह पता चला कि स्ट्रिंग इंटर्निंग के लिए उपयोग की जाने वाली हैश तालिका में खोजों में अधिकांश पार्सिंग समय का कब्जा था। हैश टेबल छोटा था, शायद 256 तत्व, और जब कई मान एक सेल में हैश किए गए थे, तो इसने एक श्रृंखला का आयोजन किया। हैश टेबल के पहले कार्यान्वयन के बाद, बहुत समय बीत गया और दृश्यों में अब दसियों हजार वस्तुएं थीं, इसलिए इतनी छोटी मेज जल्दी से आबाद हो गई और अप्रभावी हो गई।

यह केवल तालिका के आकार को बढ़ाने के लिए सबसे अधिक उचित था - यह सब वर्कफ़्लो की ऊंचाई पर हुआ, इसलिए किसी प्रकार के सुरुचिपूर्ण समाधान के लिए समय नहीं था, उदाहरण के लिए, इसे भरने पर तालिका के आकार का विस्तार करना। हम एक लाइन में बदलाव करते हैं, एप्लिकेशन का पुनर्निर्माण करते हैं, कमिट करने से पहले एक त्वरित परीक्षण करते हैं और ... कोई गति में सुधार नहीं होता है। हैश टेबल सर्च करने में उतना ही समय लगता है। बहुत खूब!

आगे के अध्ययन के बाद, हमने पाया कि इस्तेमाल किया गया हैश टेबल फ़ंक्शन निम्न के समान था:

int hash(const char *str) { return str[0]; } 

(मुझे माफ कर दो, पिक्सर, अगर मैंने तुम्हारे टॉप-सीक्रेट रेंडरमैन सोर्स कोड का खुलासा किया।)

"हैश" फ़ंक्शन को 1980 के दशक में वापस लागू किया गया था। उस समय, प्रोग्रामर ने संभवतः माना कि हैश मान पर स्ट्रिंग में सभी वर्णों के प्रभाव की जांच करने की कम्प्यूटेशनल लागत बहुत अधिक होगी और इसके लायक नहीं होगी। (मुझे लगता है कि अगर दृश्य में हैश तालिका में केवल कुछ ऑब्जेक्ट और 256 तत्व थे, तो वह था)।

एक और अप्रचलित कार्यान्वयन ने योगदान दिया: जब से पिक्सर ने अपनी फिल्में बनाना शुरू किया, तब से दृश्यों में वस्तुओं के नाम काफी बढ़ गए हैं, उदाहरण के लिए, "बज़लाइट / लेयरअरम / हैंड / इंडेक्सफ़िंगर / नॉकल 2"। हालांकि, पाइपलाइन के कुछ प्रारंभिक चरण ने वस्तुओं के नामों को संग्रहीत करने के लिए एक निश्चित-लंबाई वाले बफर का उपयोग किया और सभी लंबे नामों को छोटा किया, केवल अंत को बनाए रखा, और, भाग्य के साथ, शुरुआत में एक दीर्घवृत्त जोड़ा, जिससे यह स्पष्ट हो गया कि नाम का हिस्सा खो गया था: "... वर्ष / वामप्रेम / हाथ / IndexFinger / Knuckle2 "।

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

गहन नवाचार

यह सबक मुझे पिछले साल तब याद आया जब डब्ल्यूडीएएस से हीदर प्रिट्चेट और रासमस टमस्टॉर्फ ने मुझसे संपर्क किया और पूछा कि क्या मैं मयूर से दृश्य ¹ में दृश्य प्रस्तुत करने की संभावित गुणवत्ता की जांच करने में दिलचस्पी लूंगा । स्वाभाविक रूप से, मैं सहमत था। मुझे मदद करने में खुशी हुई और मैं सोच रहा था कि सब कुछ कैसे बदल जाएगा।

मेरे अंदर के भोले आशावादी ने आशा व्यक्त की कि कोई बड़ा आश्चर्य नहीं होगा - अंत में, लगभग 15 साल पहले मलबे का पहला संस्करण जारी किया गया था, और कई लोगों ने कई वर्षों तक इसके कोड का इस्तेमाल किया और इसका अध्ययन किया। आप यह सुनिश्चित कर सकते हैं कि रेंडरमैन के पुराने हैश फ़ंक्शन की तरह कोई हस्तक्षेप नहीं होगा, है ना?

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

पहले रेंडरिंग

दृश्य को एक्सेस करने के बाद, मैंने तुरंत इसे डाउनलोड कर लिया (इसमें मेरे घर के इंटरनेट कनेक्शन के साथ कई घंटे लग गए) और इसे टार से अनपैक कर दिया, जिसमें 29 जीबी की Pbrt फाइलें और 38 GB की ptex ² बनावट के नक्शे प्राप्त हुए। मैंने स्पष्ट रूप से अपने होम सिस्टम (16 जीबी रैम और 4-कोर सीपीयू के साथ) पर दृश्य को प्रस्तुत करने की कोशिश की। कुछ समय बाद कंप्यूटर पर लौटने के बाद, मैंने देखा कि यह जमी हुई थी, सभी रैम भरी हुई थी, और पब्रेट अभी भी दृश्य विवरण के पार्सिंग को पूरा करने की कोशिश कर रहा था। OS ने वर्चुअल मेमोरी का उपयोग करके कार्य का सामना करने की कोशिश की, लेकिन यह निराशाजनक था। प्रक्रिया को पीटने के बाद, मुझे अपने कार्यों का जवाब देने के लिए प्रणाली शुरू होने से पहले लगभग एक मिनट इंतजार करना पड़ा।

अगला प्रयास Google कंप्यूट इंजन का एक उदाहरण था, जो आपको अधिक रैम (120 जीबी) और अधिक सीपीयू (16 सीपीयू पर 32 धागे) का उपयोग करने की अनुमति देता है। अच्छी खबर यह थी कि pbrt सफलतापूर्वक दृश्य को प्रस्तुत करने में सक्षम था (हीथ और रैसमस के काम के लिए धन्यवाद इसे pbrt प्रारूप में बदलने के लिए)। यह देखना बहुत रोमांचक था कि उच्च गुणवत्ता वाली फिल्म सामग्री के लिए pbrt अपेक्षाकृत अच्छे पिक्सेल उत्पन्न कर सकता है, लेकिन यह गति इतनी आश्चर्यजनक नहीं थी: केवल दृश्य विवरण को पार्स करने के लिए 34 मिनट 58 सेकंड, और रेंडरिंग के दौरान 70 जीबी रैम तक खर्च की गई प्रणाली।

हां, उस डिस्क पर 29 गीगाबाइट का पब्रेट फॉर्मेट सीन डिस्क्रिप्शन फाइल था, जिसे स्पार्स करने की जरूरत थी, इसलिए मुझे पहले चरण में कुछ सेकंड की उम्मीद नहीं थी। लेकिन किरणों को ट्रेस करने से पहले ही आधे घंटे का समय दें? यह दृश्य के साथ काम को बहुत जटिल करता है।

दूसरी ओर, इस गति ने हमें बताया कि कोड में बहुत कुछ बेईमानी-महक आ रही थी; न केवल "मैट्रिक्स उलटा 10% तेजी से प्रदर्शन किया जा सकता है"; बल्कि, "ओह के स्तर पर कुछ, हम 100 हजार तत्वों की एक सूची से गुजर रहे हैं"। मैं आशावादी था और आशा करता था कि इसका पता लगाकर मैं इस प्रक्रिया में काफी तेजी ला सकता हूं।

आंकड़े मदद नहीं करते

पहली जगह मैंने सुराग की तलाश शुरू की थी, प्रतिपादन के बाद मवाद डंप आँकड़े थे। Pbrt निष्पादन के मुख्य चरणों को कॉन्फ़िगर किया गया है ताकि आप प्रतिपादन प्रक्रिया के दौरान आवधिक अवरोधों के साथ संचालन को ठीक करके अनुमानित रूपरेखा डेटा एकत्र कर सकें। दुर्भाग्य से, आँकड़ों ने हमारी बहुत मदद नहीं की: रिपोर्टों के अनुसार, प्रतिपादन की शुरुआत से लगभग 35 मिनट पहले, 4 मिनट 22 सेकंड बीवीएच के निर्माण में बिताए गए थे, लेकिन बाकी समय के बारे में कोई विवरण नहीं दिया गया था।

बीवीएच का निर्माण एकमात्र महत्वपूर्ण कम्प्यूटेशनल कार्य है जो दृश्य पार्सिंग के दौरान किया जाता है; बाकी सब कुछ अनिवार्य रूप से ज्यामिति और सामग्री के विवरण का एक वर्णन है। यह जानते हुए कि बीवीएच बनाने में कितना समय व्यतीत हुआ, इस बात की समझ दी कि कैसे (संयुक्त राष्ट्र) प्रभावी प्रणाली थी: शेष समय, अर्थात् लगभग 30 मिनट, 29 जीबी डेटा पार्स किया गया, यानी गति 16.5 एमबी / सेकेंड थी। अच्छी तरह से अनुकूलित JSON पार्सर, अनिवार्य रूप से एक ही कार्य कर रहे हैं, 50-200 एमबी / एस की गति से काम करते हैं। जाहिर है, अभी भी सुधार की गुंजाइश है।

यह समझने के लिए कि क्या समय बर्बाद हो रहा है, मैंने एक लिनक्स परफ़ॉर्म टूल के साथ pbrt लॉन्च किया, जिसका मैंने पहले कभी इस्तेमाल नहीं किया था। लेकिन, ऐसा लगता है, वह कार्य के साथ मुकाबला किया। मैंने उन्हें फ़ंक्शन नाम ( --call-graph dwarf ) प्राप्त करने के लिए DWARF वर्णों की खोज करने का निर्देश दिया, और एक सौ गीगाबाइट ट्रेस फ़ाइलों को प्राप्त नहीं करने के लिए, मुझे नमूना दर 4000 से 100 नमूनों प्रति सेकंड ( -F 100 ) को कम करना पड़ा। लेकिन इन मापदंडों के साथ सब कुछ ठीक हो गया, और मुझे सुखद आश्चर्य हुआ कि पूर्ण perf report टूल में अच्छा शाप के साथ एक इंटरफ़ेस है।

यहाँ वह है जो मुझे pbrt से शुरू करने के बाद बता सकता है:


जब मैंने "अच्छे शाप के साथ इंटरफ़ेस" के बारे में बात की तो मैं मजाक नहीं कर रहा था।

हम देखते हैं कि आधे से अधिक समय पार्सिंग यांत्रिकी पर खर्च किया जाता है: yylex() बायसन द्वारा उत्पन्न yylex() , और yylex() फ्लेक्स द्वारा उत्पन्न शाब्दिक विश्लेषक ( yylex() है। yylex() में आधे से अधिक समय yylex() पर खर्च होता है, जो स्ट्रिंग्स को दोहरे मूल्यों में परिवर्तित करता है। हम इस श्रृंखला के तीसरे लेख तक yylex() yyparse() और yylex() पर हमले को yyparse() कर देंगे, लेकिन अब हम पहले से ही समझ सकते हैं कि रेंडर में फेंकने वाले डेटा की मात्रा को कम करना एक अच्छा विचार हो सकता है।

पाठ से PLY तक

पाठ डेटा पार्स करने में कम समय बिताने का एक तरीका यह है कि डेटा को एक ऐसे प्रारूप में परिवर्तित किया जाए जो अधिक कुशलता से पार्स हो। इन दृश्य विवरण फ़ाइलों में से अधिकांश 29 GB त्रिकोण जाल हैं, और pbrt में पहले से ही PLY प्रारूप के लिए देशी समर्थन है, जो बहुभुज मेषों का एक प्रभावी द्विआधारी प्रतिनिधित्व है। इसके अलावा pbrt में एक कमांड लाइन फ्लैग होता है - --toply , जो दृश्य विवरण फ़ाइल pbrt को पार्स करता है, सभी पाए गए ट्रायंगल मेज़ को PLY फ़ाइलों में कनवर्ट करता है और एक नई pbrt फ़ाइल बनाता है जो इन PLY फ़ाइलों को संदर्भित करता है।

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

मैंने बड़े मेषों के लिए PLY का उपयोग करने के लिए सभी *_geometry.pbrt फ़ाइलों को एक फ़ोल्डर में बदलने के लिए एक छोटी कमांड लाइन स्क्रिप्ट लिखी । ध्यान दें कि यह उन रास्तों के बारे में कठोर-कोडित धारणाएं हैं जिन्हें स्क्रिप्ट को कहीं और काम करने के लिए बदलने की आवश्यकता है।

पहली गति को बढ़ावा

सभी बड़ी जालियों को PLY में परिवर्तित करने के बाद, डिस्क पर दृश्य विवरण का आकार 29 से घटकर 22 GB: 16.9 GB pbrt दृश्य फ़ाइलों और 5.1 GB PLY बाइनरी फ़ाइलों का हो जाता है। रूपांतरण के बाद, सिस्टम के पहले चरण का कुल समय घटकर 27 मिनट 35 सेकंड हो गया, और बचत की राशि 7 मिनट 23 सेकंड हो गई, अर्थात, हमने 1.3 गुना ^{3 से} त्वरित किया। PLY फ़ाइल को संसाधित करने की तुलना में एक pbrt पाठ फ़ाइल को संसाधित करने से बहुत अधिक कुशल है: PLY फ़ाइलों को पार्स करने के लिए केवल 40 सेकंड के स्टार्टअप समय बिताया गया था, और हम देखते हैं कि PLY फ़ाइलों को लगभग 130 MB / s की गति से संसाधित किया गया था, या pbrt पाठ प्रारूप की तुलना में लगभग 8% तेज़ी से संसाधित किया गया था ।

यह एक अच्छी आसान जीत थी, लेकिन हमें अभी भी बहुत कुछ करना था।

अगली बार, हम यह पता लगाएंगे कि वास्तव में सभी मेमोरी का उपयोग कहां किया गया है, यहां कुछ त्रुटियों को ठीक करें और प्रक्रिया में और भी अधिक गति प्राप्त करें।

नोट

1. अब आपको मेरी ओर से ptex support को जोड़ने और पिछले साल pbrt को Disney BSDF में परिवर्तित करने की प्रेरणा की बेहतर समझ होनी चाहिए।
2. यहां और उसके बाद के पदों में हर समय डब्ल्यूआईपी संस्करण (वर्क इन प्रोग्रेस) के लिए संकेत दिया गया है, जिसके साथ मैंने आधिकारिक रिलीज से पहले काम किया था। ऐसा लगता है कि अंतिम संस्करण थोड़ा बड़ा है। हम उन परिणामों से चिपके रहेंगे जो मैंने मूल दृश्य के साथ काम करते समय दर्ज किए थे, इस तथ्य के बावजूद कि वे अंतिम संस्करण के परिणामों के अनुरूप नहीं हैं। मुझे संदेह है कि उनसे सबक समान हो सकता है।
3. ध्यान दें कि गति में वृद्धि अनिवार्य रूप से है जो आप पार्सिंग डेटा की मात्रा में लगभग 50 प्रतिशत की कमी के साथ उम्मीद करेंगे। प्रोफाइलर के अनुसार हम जितना समय बिताते हैं वह हमारे विचार की पुष्टि करता है।