नई GPU ट्रैकिंग एल्गोरिथम: वेवफ्रंट पाथ ट्रेसिंग

इस लेख में, हम हाल ही में जारी किए गए लाइटहाउस 2 प्लेटफ़ॉर्म में उपयोग की जाने वाली महत्वपूर्ण अवधारणा का पता लगाते हैं। वेवफ्रंट पाथ ट्रेसिंग , क्योंकि इसे NVIDIA से लेन, कर्रास और आइला कहा जाता है, या पथ अनुरेखण स्ट्रीमिंग, क्योंकि इसे मूल रूप से वान एंटवर्प के मास्टर थीसिस में कहा जाता है, एक महत्वपूर्ण भूमिका निभाता है। GPU पर कुशल पथ ट्रेलरों का विकास, और CPU पर संभावित पथ ट्रेलरों का विकास। हालांकि, यह काफी उलट है, इसलिए, इसे समझने के लिए, रे ट्रेसिंग एल्गोरिदम को पुनर्विचार करना आवश्यक है।

अधिभोग

पथ अनुरेखण एल्गोरिथ्म आश्चर्यजनक रूप से सरल है और इसे केवल छद्मकोड की कुछ पंक्तियों में वर्णित किया जा सकता है:

vec3 Trace( vec3 O, vec3 D ) IntersectionData i = Scene::Intersect( O, D ) if (i == NoHit) return vec3( 0 ) // ray left the scene if (i == Light) return i.material.color // lights do not reflect vec3 R, pdf = RandomDirectionOnHemisphere( i.normal ), 1 / 2PI return Trace( i.position, R ) * i.BRDF * dot( i.normal, R ) / pdf 

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

GPU को इस कार्य को बहु-थ्रेडेड मोड में करने के लिए डिज़ाइन किया गया है। सबसे पहले यह लग सकता है कि किरण अनुरेखण इसके लिए आदर्श है। इसलिए, हम पिक्सेल के लिए एक स्ट्रीम बनाने के लिए OpenCL या CUDA का उपयोग करते हैं, प्रत्येक स्ट्रीम एक एल्गोरिथ्म का प्रदर्शन करता है जो वास्तव में उद्देश्य के रूप में काम करता है, और बहुत तेज़ है: बस यह समझने के लिए ShaderToy के साथ कुछ उदाहरण देखें कि कितनी तेजी से रे ट्रेसिंग हो सकती है GPU पर। लेकिन जैसा कि यह हो सकता है, सवाल अलग है: क्या ये किरण के निशान वास्तव में उतने ही तेज़ हैं ?


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

रोजगार की समस्या SIMT GPU उपकरणों के निष्पादन मॉडल पर लागू होती है। धाराओं को समूहों में व्यवस्थित किया जाता है, उदाहरण के लिए, पास्कल जीपीयू (एनवीडिया उपकरण वर्ग 10xx) में 32 धागे एक ताना में जोड़े जाते हैं । ताना के थ्रेड्स में एक सामान्य प्रोग्राम काउंटर होता है: उन्हें एक निश्चित चरण के साथ निष्पादित किया जाता है, इसलिए प्रत्येक प्रोग्राम निर्देश को एक साथ 32 थ्रेड्स द्वारा निष्पादित किया जाता है। SIMT का मतलब सिंगल इंस्ट्रक्शन मल्टिपल थ्रेड है , जो कॉन्सेप्ट का अच्छी तरह से वर्णन करता है। SIMT प्रोसेसर के लिए, शर्तों वाला एक कोड जटिल है। यह आधिकारिक वोल्टा प्रलेखन में स्पष्ट रूप से दिखाया गया है:


SIMT में शर्तों के साथ कोड निष्पादन।

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

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

पथ अनुरेखण स्ट्रीमिंग

स्ट्रीमिंग पथ अनुरेखण एल्गोरिथ्म व्यस्त समस्या के मूल कारण को संबोधित करने के लिए डिज़ाइन किया गया है। स्ट्रीमिंग पथ अनुरेखण पथ अनुरेखण एल्गोरिथ्म को चार चरणों में विभाजित करता है:

1. उत्पन्न
2. विस्तार
3. छाया
4. में शामिल होने के

प्रत्येक चरण को एक अलग कार्यक्रम के रूप में लागू किया जाता है। इसलिए, एक एकल GPU प्रोग्राम ("कर्नेल", कर्नेल) के रूप में एक पूर्ण पथ अनुचर निष्पादित करने के बजाय, हमें चार कोर के साथ काम करना होगा। इसके अलावा, जैसा कि हम जल्द ही देखेंगे, वे एक लूप में निष्पादित होते हैं।

चरण 1 ("उत्पन्न") प्राथमिक किरणों की पीढ़ी के लिए जिम्मेदार है। यह एक सरल कोर है जो पिक्सेल की संख्या के बराबर मात्रा में किरणों के शुरुआती बिंदु और दिशाएं बनाता है। इस चरण का आउटपुट एक बड़ी किरण बफर और एक काउंटर है जो किरणों की संख्या के अगले चरण को सूचित करता है जिसे संसाधित करने की आवश्यकता होती है। प्राथमिक किरणों के लिए, यह मान स्क्रीन की ऊंचाई स्क्रीन की चौड़ाई के बराबर है।

स्टेज 2 ("नवीनीकृत") दूसरा मुख्य है। सभी पिक्सल के लिए चरण 1 पूरा होने के बाद ही इसे निष्पादित किया जाता है। कर्नेल चरण 1 में उत्पन्न बफर को पढ़ता है और प्रत्येक किरण को दृश्य के साथ पार करता है। इस चरण का आउटपुट बफर में संग्रहीत प्रत्येक किरण के लिए प्रतिच्छेदन परिणाम है।

स्टेज 3 ("शैडो") चरण 2 के पूरा होने के बाद किया जाता है। यह चरण 2 से प्रतिच्छेदन का परिणाम प्राप्त करता है और प्रत्येक पथ के लिए छायांकन मॉडल की गणना करता है। यह ऑपरेशन नई किरणों को उत्पन्न कर सकता है या नहीं कर सकता है, यह इस बात पर निर्भर करता है कि क्या पथ पूरा हो गया है। पथ जो नई किरण उत्पन्न करते हैं (पथ "फैली हुई") बफर को नई किरण ("पथ खंड") लिखते हैं। सीधे प्रकाश स्रोतों ("स्पष्ट रूप से नमूना प्रकाश व्यवस्था" या "अगली घटना की गणना करें") के पथ एक दूसरे बफर को छाया बीम लिखते हैं।

स्टेज 4 ("कनेक्ट") चरण 3 में उत्पन्न छाया किरणों का पता लगाता है। यह चरण 2 के समान है, लेकिन एक महत्वपूर्ण अंतर के साथ: छाया की किरणों को किसी भी चौराहे को खोजने की आवश्यकता होती है, जबकि विस्तारित किरणों को निकटतम चौराहे को खोजने की आवश्यकता होती है। इसलिए, इसके लिए एक अलग कोर बनाया गया है।

चरण 4 को पूरा करने के बाद, हमें एक बफर मिलता है जिसमें किरणें होती हैं जो पथ का विस्तार करती हैं। इन किरणों को लेने के बाद, हम चरण 2 में आगे बढ़ते हैं। हम इसे तब तक जारी रखते हैं जब तक कि कोई विस्तार किरणें नहीं होती हैं या जब तक हम पुनरावृत्तियों की अधिकतम संख्या तक नहीं पहुंच जाते हैं।

अक्षमता के स्रोत

प्रदर्शन से संबंधित एक प्रोग्रामर को स्ट्रीमिंग पथ अनुरेखण एल्गोरिदम की ऐसी योजना में बहुत खतरनाक क्षण दिखाई देंगे:

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

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

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

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

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

परिणाम

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

• रे उत्पत्ति: तीन फ्लोट मान, यानी 12 बाइट्स
• रे दिशा: तीन फ्लोट मान, यानी 12 बाइट्स

व्यवहार में, बफर के आकार को बढ़ाने के लिए बेहतर है। यदि आप बीम की शुरुआत और दिशा के लिए 16 बाइट्स स्टोर करते हैं, तो जीपीयू उन्हें 128-बिट रीड ऑपरेशन में पढ़ सकेगा। एक विकल्प 64-बिट रीड ऑपरेशन है जिसके बाद फ्लोट 3 प्राप्त करने के लिए 32-बिट ऑपरेशन होता है, जो लगभग दोगुना है। यही है, 1920 × 1080 की एक स्क्रीन के लिए हमें मिलता है: 1920x1080x32 = ~ 64 एमबी। हमें एक्सटेंड कर्नेल द्वारा बनाए गए चौराहे के परिणाम के लिए एक बफर की भी आवश्यकता है। यह प्रति तत्व एक और 128 बिट्स है, जो कि 32 एमबी है। इसके अलावा, "शैडो" कर्नेल 1920 × 1080 पथ एक्सटेंशन (ऊपरी सीमा) तक बना सकता है, और हम उन्हें उस बफर पर नहीं लिख सकते हैं जिससे हम पढ़ते हैं। यह एक और 64 एमबी है। और अंत में, यदि हमारा पथ अनुचर छाया किरणों का उत्सर्जन करता है, तो यह एक और 64 एमबी बफर है। सब कुछ समेटने के बाद, हमें 224 एमबी डेटा मिलता है, और यह केवल वेवफ्रंट एल्गोरिदम के लिए है। या 4K रेजोल्यूशन में लगभग 1 जीबी।

यहां हमें किसी अन्य सुविधा के लिए उपयोग करने की आवश्यकता है: हमारे पास बहुत सारी मेमोरी है। यह लग सकता है। वह 1 जीबी एक बहुत है, और इस संख्या को कम करने के तरीके हैं, लेकिन अगर आप इस वास्तविक दृष्टिकोण से संपर्क करते हैं, तो तब तक हमें 4K में रास्तों का पता लगाने की आवश्यकता होती है, 8 जीबी के साथ GPU पर 1 जीबी का उपयोग करना हमारी समस्याओं का कम होगा।

मेमोरी आवश्यकताओं की तुलना में अधिक गंभीर है, परिणाम रेंडरिंग एल्गोरिदम के लिए होंगे। अब तक मैंने सुझाव दिया है कि हमें शैडो कोर में प्रत्येक थ्रेड के लिए एक एक्सटेंशन किरण और, संभवतः, एक शैडो रे उत्पन्न करने की आवश्यकता है। लेकिन क्या होगा अगर हम पिक्सेल प्रति 16 किरणों का उपयोग करते हुए परिवेश निर्माण करना चाहते हैं? 16 एओ किरणों को बफर में संग्रहीत करने की आवश्यकता होती है, लेकिन इससे भी बदतर, वे केवल अगले पुनरावृत्ति में दिखाई देंगे। एक समान समस्या तब उत्पन्न होती है जब Witted शैली में किरणों को ट्रेस किया जाता है: कई प्रकाश स्रोतों के लिए एक छाया किरण का उत्सर्जन करना या कांच के साथ टकराव में बीम को विभाजित करना लगभग असंभव है।

दूसरी ओर, वेवफ्रंट पाथ ट्रेसिंग उन समस्याओं को हल करती है, जिन्हें हमने ऑक्यूपेंसी सेक्शन में सूचीबद्ध किया है:

• चरण 1 में, बिना किसी स्थिति के सभी प्रवाह प्राथमिक किरणें बनाते हैं और उन्हें बफर में लिखते हैं।
• चरण 2 में, बिना किसी प्रवाह के सभी दृश्य के साथ किरणों को काटते हैं और बफर को चौराहे के परिणाम लिखते हैं।
• चरण 3 में, हम 100% अधिभोग के साथ प्रतिच्छेदन परिणामों की गणना करना शुरू करते हैं।
• चरण 4 में, हम बिना किसी रिक्त स्थान के साथ छाया किरणों की एक निरंतर सूची की प्रक्रिया करते हैं।

जब तक हम 2 खंडों की लंबाई के साथ जीवित किरणों के साथ चरण 2 पर लौटते हैं, तब तक हमारे पास फिर से एक कॉम्पैक्ट किरण बफर होता है जो कर्नेल शुरू होने पर पूर्ण रोजगार की गारंटी देता है।

इसके अतिरिक्त, एक अतिरिक्त लाभ है जिसे कम करके आंका नहीं जाना चाहिए। कोड को चार अलग-अलग चरणों में अलग किया गया है। प्रत्येक कोर सभी उपलब्ध GPU संसाधनों (कैश, साझा मेमोरी, रजिस्टर) को अन्य कोर को ध्यान में रखे बिना उपयोग कर सकता है। यह GPU को चौराहे कोड को अधिक थ्रेड्स में दृश्य के साथ निष्पादित करने की अनुमति दे सकता है, क्योंकि इस कोड को shader कोड के रूप में कई रजिस्टरों की आवश्यकता नहीं है। अधिक धागे, बेहतर आप देरी को छिपा सकते हैं।

पूर्णकालिक, बेहतर देरी मास्किंग, स्ट्रीमिंग रिकॉर्डिंग: ये सभी लाभ सीधे GPU मंच के उद्भव और प्रकृति से संबंधित हैं। GPU के लिए, वेवफ्रंट पाथ ट्रेसिंग एल्गोरिथ्म बहुत स्वाभाविक है।

क्या यह इसके लायक है?

बेशक, हमारे पास एक सवाल है: क्या अनुकूलित रोजगार बफ़र्स से I / O को औचित्य देता है और अतिरिक्त कोर को लागू करने की लागत?

जवाब हाँ है, लेकिन यह साबित करना इतना आसान नहीं है।

यदि हम एक दूसरे के लिए ShaderToy के साथ पथ के ट्रेसर पर लौटते हैं, तो हम देखेंगे कि उनमें से अधिकांश एक सरल और हार्ड-कोडीन दृश्य का उपयोग करते हैं। पूर्ण-विकसित दृश्य के साथ इसे प्रतिस्थापित करना कोई तुच्छ कार्य नहीं है: लाखों प्राइमरी के लिए, बीम को काटना और दृश्य एक जटिल समस्या बन जाती है, जिसका समाधान अक्सर एनवीडिया ( ऑप्टिक्स ), एएमडी ( Radeon-Rays ) या Intel ( एम्ब्री ) पर छोड़ दिया जाता है। इन विकल्पों में से कोई भी CUDA कृत्रिम किरण अनुरेखक में हार्ड-कोडेड दृश्य को आसानी से बदल नहीं सकता है। CUDA में, निकटतम एनालॉग (Optix) को प्रोग्राम निष्पादन पर नियंत्रण की आवश्यकता होती है। सीपीयू में आलिंगन आपको अपने स्वयं के कोड से व्यक्तिगत बीम का पता लगाने की अनुमति देता है, लेकिन इसकी लागत महत्वपूर्ण प्रदर्शन ओवरहेड है: वह व्यक्तिगत बीम के बजाय बीम के बड़े समूहों का पता लगाना पसंद करता है।


ब्रिगेड 1 के साथ प्रदान की गई समय से स्क्रीन।

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

स्ट्रीमिंग पथ प्रकाशस्तंभ 2 में

लाइटहाउस 2 प्लेटफॉर्म में दो वेवफ्रंट पाथ ट्रेसिंग ट्रैसर हैं। पहला चरण 2 और 4 (किरणों और दृश्यों के प्रतिच्छेदन के चरणों) के कार्यान्वयन के लिए ऑप्टिक्स प्राइम का उपयोग करता है; दूसरे में, Optix का उपयोग सीधे उस कार्यक्षमता को लागू करने के लिए किया जाता है।

ऑप्टिक्स प्राइम ऑप्टिक्स का एक सरलीकृत संस्करण है जो केवल मुस्कराते हुए सेट के चौराहे के साथ एक दृश्य से मिलकर त्रिकोण से संबंधित है। पूर्ण Optix पुस्तकालय के विपरीत, यह कस्टम चौराहे कोड का समर्थन नहीं करता है, और केवल चौराहों त्रिकोण। हालांकि, यह वही है जो तरंग मार्ग के ट्रैसर के लिए आवश्यक है।

ऑप्टिक्स प्राइम बेस्ड rendercore.cpp पाथ ट्रेसर rendercore.cpp प्रोजेक्ट में लागू किया गया है। Optix Prime का rtpContextCreate Init फंक्शन में शुरू होता है और rtpContextCreate का उपयोग करता है। दृश्य rtpModelCreate का उपयोग करके बनाया rtpModelCreate । SetTarget का उपयोग करके rtpBufferDescCreate फ़ंक्शन में विभिन्न किरण बफ़र्स बनाए जाते हैं। ध्यान दें कि इन बफ़र्स के लिए हम सामान्य डिवाइस पॉइंटर्स प्रदान करते हैं: इसका मतलब है कि उन्हें ऑप्टिक्स और नियमित CUDE कोर दोनों में इस्तेमाल किया जा सकता है।

रेंडरिंग विधि में रेंडरिंग शुरू होता है। प्राथमिक किरण बफर को भरने के लिए, एक CUDA कोर, जिसे GenerEyeRays कहा जाता generateEyeRays । बफर भरने के बाद, Optix Prime को rtpQueryExecute का उपयोग करके बुलाया जाता है। इसके साथ, प्रतिच्छेदन परिणाम extensionHitBuffer को लिखे जाते हैं। ध्यान दें कि सभी बफ़र GPU में रहते हैं: कर्नेल कॉल के अपवाद के साथ, CPU और GPU के बीच कोई ट्रैफ़िक नहीं है। "छाया" चरण नियमित CUDA shade कोर में लागू किया गया है। इसका कार्यान्वयन pathtracer.cu ।

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

एक अन्य विवरण विभिन्न काउंटरों का प्रसंस्करण है। "नवीनीकृत" और "छाया" चरणों को पता होना चाहिए कि कितने पथ सक्रिय हैं। इसके लिए काउंटरों को जीपीयू (एटोमिकली) में अपडेट किया जाता है, जिसका अर्थ है कि वे सीपीयू में उपयोग किए जाते हैं, यहां तक ​​कि सीपीयू में वापस आए बिना भी। दुर्भाग्य से, किसी एक मामले में यह असंभव है: ऑप्टिक्स प्राइम लाइब्रेरी को पता लगाया गया है कि किरणों की संख्या कितनी है। ऐसा करने के लिए, हमें एक बार पुनरावृत्ति के बाद काउंटरों की जानकारी वापस करने की आवश्यकता है।

निष्कर्ष

यह आलेख बताता है कि वेवफ्रंट पाथ ट्रेसिंग क्या है और GPU पर पथ अनुरेखण को प्रभावी ढंग से करने के लिए क्यों आवश्यक है। इसका व्यावहारिक कार्यान्वयन लाइटहाउस 2 प्लेटफॉर्म में प्रस्तुत किया गया है, जो खुला स्रोत है और जीथब पर उपलब्ध है ।