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

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

मैंने अंतर्निहित आँकड़ों के साथ रनटाइम जांच शुरू की; pbrt में मेमोरी उपयोग को ट्रैक करने के लिए महत्वपूर्ण मेमोरी एलोकेशन के लिए मैन्युअल सेटिंग है, और रेंडरिंग पूरी होने के बाद, मेमोरी आवंटन रिपोर्ट प्रदर्शित की जाती है। मूल रूप से इस दृश्य के लिए मेमोरी आवंटन रिपोर्ट क्या है:


BVH- 9,01
1,44
MIP- 2,00
11,02

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

यह समझने के लिए कि हम क्या याद कर रहे हैं (और यह सुनिश्चित करने के लिए कि हमने सही तरीके से ट्रैक किया है), मैंने गतिशील मेमोरी के वास्तविक आवंटन का पता लगाने के लिए मासिफ का उपयोग किया। यह धीमा है, लेकिन कम से कम यह अच्छी तरह से काम करता है।

पुरातन

जब मैंने द्रव्यमान का पता लगाया तो पहली चीज़ कोड की दो पंक्तियाँ थी जो बेस क्लास Primitive उदाहरणों को आवंटित की गई थी, जो कि आंकड़ों में ध्यान में नहीं लिया गया है। एक छोटा सा निरीक्षण जिसे ठीक करना बहुत आसान है । उसके बाद, हम निम्नलिखित देखते हैं:

Primitives 24,67

ओह-वह। तो एक आदिम क्या है, और यह सब स्मृति क्यों है?

pbrt Shape बीच अंतर करता है, जो शुद्ध ज्यामिति (गोला, त्रिभुज, आदि) और Primitive , जो ज्यामिति, सामग्री, कभी-कभी विकिरण का कार्य और ज्यामिति की सतह के अंदर और बाहर शामिल माध्यम का संयोजन है।

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

जियोमेट्रिकप्रिमेटिक: 50% अतिरिक्त स्थान

नोट: इस विश्लेषण में कुछ गलत धारणाएं बनी हैं; उन्हें श्रृंखला के चौथे पद में संशोधित किया गया है।

4.3 जीबी का इस्तेमाल GeometricPrimitive पर किया जाता GeometricPrimitive । यह एक ऐसी दुनिया में रहने के लिए मज़ेदार है जहाँ 4.3 जीबी की रैम का इस्तेमाल आपकी सबसे बड़ी समस्या नहीं है, लेकिन फिर भी देखते हैं कि हमें 4.3 जीबी का GeometricPrimitive कहां से मिला। यहाँ वर्ग परिभाषा के प्रासंगिक भाग दिए गए हैं:

 class GeometricPrimitive : public Primitive { std::shared_ptr<Shape> shape; std::shared_ptr<Material> material; std::shared_ptr<AreaLight> areaLight; MediumInterface mediumInterface; }; 

हमारे पास MediumInterface लिए एक पॉइंटर है , तीन और पॉइंटर्स हैं, और फिर एक MediumInterface जिसमें 48 बाइट्स के कुल आकार के साथ दो और पॉइंटर्स हैं। इस दृश्य में केवल कुछ प्रकाश उत्सर्जक मेष हैं, इसलिए areaLight लगभग हमेशा एक अशक्त सूचक है, और दृश्य को प्रभावित करने वाला कोई वातावरण नहीं है, इसलिए दोनों mediumInterface सूचक mediumInterface भी अशक्त हैं। इस प्रकार, अगर हमारे पास Primitive वर्ग का एक विशेष कार्यान्वयन था, जिसका उपयोग विकिरण और मध्यम कार्यों की अनुपस्थिति में किया जा सकता था, तो हम लगभग 2 GB - GeometricPrimitive द्वारा कब्जा की गई डिस्क स्थान को बचाएंगे - हमारे मामले में, लगभग 2 जीबी।

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

आगे बढ़ने से पहले, आइए एक परीक्षण प्रस्तुत करें:


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

ट्रांसफ़ॉर्मप्रैटिव: 95% बर्बाद अंतरिक्ष

4.3 जीबी GeometricPrimitive तहत आवंटित मेमोरी काफी दर्दनाक हिट थी, लेकिन TransformedPrimitive तहत 17.4 जीबी के बारे में क्या?

जैसा कि ऊपर उल्लेख किया गया है, TransformedPrimitive उपयोग समय में परिवर्तन के साथ परिवर्तन और वस्तुओं के उदाहरणों के लिए दोनों किया जाता है। दोनों ही मामलों में, हमें मौजूदा Primitive एक अतिरिक्त परिवर्तन लागू करने की आवश्यकता है। TransformedPrimitive वर्ग में केवल दो सदस्य हैं:

  std::shared_ptr<Primitive> primitive; const AnimatedTransform PrimitiveToWorld; 

अब तक बहुत अच्छा है: एक आदिम के लिए एक सूचक और एक परिवर्तन जो समय के साथ बदलता है। लेकिन वास्तव में AnimatedTransform में क्या संग्रहीत है?

  const Transform *startTransform, *endTransform; const Float startTime, endTime; const bool actuallyAnimated; Vector3f T[2]; Quaternion R[2]; Matrix4x4 S[2]; bool hasRotation; struct DerivativeTerm { // ... Float kc, kx, ky, kz; }; DerivativeTerm c1[3], c2[3], c3[3], c4[3], c5[3]; 

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

लेकिन इस सीन में कुछ नहीं चलता है। वस्तुओं के उदाहरणों के लिए परिवर्तनों के दृष्टिकोण से, हमें रूपांतरण के लिए एक सूचक की आवश्यकता होती है, और अपघटन और जंगम बाउंडिंग बॉक्स के मूल्यों की आवश्यकता नहीं होती है। (वह है, केवल 8 बाइट्स की आवश्यकता है)। यदि आप वस्तुओं के निश्चित उदाहरणों के लिए एक अलग Primitive कार्यान्वयन बनाते हैं, तो 17.4 जीबी कुल 900 एमबी (!) में संकुचित होते हैं।

GeometricPrimitive रूप में, इसे ठीक करना एक गैर-तुच्छ परिवर्तन है जो पुस्तक में वर्णित है, इसलिए हम इसे अगले संस्करण के लिए भी स्थगित कर देंगे। कम से कम अब हम समझते हैं कि 24.7 जीबी की Primitive मेमोरी के अराजकता के साथ क्या हो रहा है।

रूपांतरण कैश के साथ परेशानी

मासिफ द्वारा परिभाषित बेहिसाब मेमोरी का अगला सबसे बड़ा ब्लॉक TransformCache था, जिसने लगभग 16 जीबी का कब्जा किया था। (यहां मूल कार्यान्वयन की एक कड़ी है।) यह विचार है कि एक ही परिवर्तन मैट्रिक्स का उपयोग अक्सर दृश्य में कई बार किया जाता है, इसलिए इसे मेमोरी में इसकी एक प्रति रखना सबसे अच्छा है, ताकि इसका उपयोग करने वाले सभी तत्व एक ही चीज़ के लिए एक पॉइंटर स्टोर करें रूपांतरण।

TransformCache ने कैश को स्टोर करने के लिए std::map का उपयोग किया और मासिफ ने बताया कि 16 GB में से 6 का उपयोग std::map में ब्लैक-रेड ट्री नोड्स के लिए किया गया था। यह एक बहुत ही भयानक है: इस मात्रा का 60% स्वयं परिवर्तनों के लिए उपयोग किया जाता है। आइए इस वितरण की घोषणा को देखें:

 std::map<Transform, std::pair<Transform *, Transform *>> cache; 

यहां, काम पूरी तरह से किया जाता है: Transform पूरी तरह से वितरण के लिए कुंजी के रूप में उपयोग किया जाता है। इससे भी बेहतर, pbrt Transform दो 4x4 मैट्रिसेस (ट्रांसफॉर्मेशन मैट्रिक्स और इसके उल्टे मैट्रिक्स) को स्टोर करता है, जिसके परिणामस्वरूप पेड़ के प्रत्येक नोड में 128 बाइट्स जमा हो जाते हैं। यह सब उसके लिए संग्रहीत मूल्य के लिए बिल्कुल अनावश्यक है।

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

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

और अंतिम, इससे पहले कि हम आरंभ करें: Lookup() पद्धति के हस्ताक्षर की जांच करने के बाद, एक और समस्या स्पष्ट हो जाती है:

 void Lookup(const Transform &t, Transform **tCached, Transform **tCachedInverse) 

जब कॉलिंग फ़ंक्शन Transform प्रदान करता है, तो कैश सहेजता है और रूपांतरण बिंदु को एक पास के बराबर देता है, लेकिन उलटा मैट्रिक्स भी पास करता है। यह संभव बनाने के लिए, मूल कार्यान्वयन में, जब कैश में परिवर्तन जोड़ते हैं, तो व्युत्क्रम मैट्रिक्स हमेशा गणना और संग्रहीत किया जाता है ताकि इसे वापस किया जा सके।

यहाँ बेवकूफी की बात यह है कि अधिकांश डायल पीयर जो ट्रांसफ़ॉर्म कैश का उपयोग करते हैं, उलटा मैट्रिक्स को क्वेरी या उपयोग नहीं करते हैं। यही है, विभिन्न प्रकार की स्मृति अनुचित व्युत्क्रम परिवर्तनों पर बर्बाद हो जाती है।

नए कार्यान्वयन में , निम्नलिखित सुधार जोड़े गए हैं:

• यह खोज को गति देने के लिए हैश टेबल का उपयोग करता है और इसके लिए Transform * एरे के अलावा किसी अन्य चीज के स्टोरेज की आवश्यकता नहीं होती है, जो संक्षेप में, सभी Transform को स्टोर करने के लिए आवश्यक मूल्य में उपयोग की जाने वाली मेमोरी की मात्रा को कम कर देता है।
• खोज विधि का हस्ताक्षर अब Transform *Lookup(const Transform
&t) जैसा दिखता है Transform *Lookup(const Transform
&t) Transform *Lookup(const Transform
&t) ; एक जगह जहां कॉलिंग फ़ंक्शन कैश से उलटा मैट्रिक्स प्राप्त करना चाहता है, यह सिर्फ Lookup() दो बार कॉल करता है।

हैशिंग के लिए, मैंने हैश फ़ंक्शन FNV1a का उपयोग किया। इसके कार्यान्वयन के बाद, मुझे हैश कार्यों पर अरास का पद मिला; शायद मुझे सिर्फ xxHash या CityHash का उपयोग करना चाहिए था क्योंकि उनका प्रदर्शन बेहतर है; शायद किसी दिन मेरी शर्म जीत जाएगी और मैं इसे ठीक कर दूंगा।

नए TransformCache कार्यान्वयन के लिए धन्यवाद, कुल सिस्टम स्टार्टअप समय में काफी कमी आई है - 21 मिनट 42 एस तक। यही है, हमने एक और 5 मिनट 7 सेकंड बचाया, या 1.27 बार त्वरित किया। इसके अलावा, मेमोरी के अधिक कुशल उपयोग ने ट्रांसफॉर्मेशन मैट्रिसेस द्वारा कब्जा किए गए स्थान को 16 से 5.7 जीबी तक कम कर दिया है, जो संग्रहीत डेटा की मात्रा के लगभग बराबर है। इसने हमें इस तथ्य का फायदा उठाने की कोशिश नहीं करने की अनुमति दी कि वे वास्तव में अनुमानित नहीं हैं, और 4x4 के बजाय 3x4 मैट्रिसेस को स्टोर करने के लिए। (सामान्य स्थिति में, मुझे इस तरह के अनुकूलन के महत्व पर संदेह होगा, लेकिन यहां यह हमें गीगाबाइट से अधिक बचाएगा - बहुत सारी मेमोरी! यह उत्पादन रेंडरर में निश्चित रूप से करने योग्य है।)

पूरा करने के लिए छोटे प्रदर्शन अनुकूलन

एक बहुत ही सामान्यीकृत TransformedPrimitive संरचना हमें स्मृति और समय दोनों की लागत देती है: प्रोफाइलर ने कहा कि स्टार्टअप में समय का एक महत्वपूर्ण हिस्सा AnimatedTransform::Decompose() फ़ंक्शन में खर्च किया गया था, जो मैट्रिक्स के परिवर्तन को क्वाटरनियन रोटेशन, ट्रांसफर और स्केल में बदल देता है। चूँकि इस दृश्य में कुछ भी नहीं चल रहा है, यह कार्य अनावश्यक है, और एनिमेटट्रांसफॉर्म के कार्यान्वयन की गहन जाँच से पता चला है कि इन परिवर्तनों में से कोई भी एक्सेस नहीं किया गया है यदि दो परिवर्तन मैट्रिक्स वास्तव में समान हैं।

कंस्ट्रक्टर में दो पंक्तियों को जोड़ना ताकि रूपांतरणों के विघटन का प्रदर्शन तब न हो जब उनकी आवश्यकता न हो, हमने प्रारंभ समय से एक और 1 मिनट 31 बचा लिया: नतीजतन, हम 20 मिनट 9 सेकेंड पर आ गए, अर्थात सामान्य रूप से उन्होंने 1.73 गुना वृद्धि की।

अगले लेख में, हम गंभीरता से पार्सर को उठाएंगे और विश्लेषण करेंगे कि क्या महत्वपूर्ण हो गया जब हमने अन्य भागों के काम में तेजी लाई।