निष्पक्ष डायरेक्टएक्स जीपीयू, सीपीयू, और क्लाउड रेंडरिंग

एक रेंडरर कैसे बनाएं जो आपकी दादी के कंप्यूटर पर भी काम करता है? प्रारंभ में, हमारे पास थोड़ा अलग काम था - सभी GPU मॉडल के लिए एक निष्पक्ष रेंडर बनाने के लिए: एनवीडिया, एटीआई, इंटेल।
हालाँकि सभी वीडियो कार्ड के लिए इस तरह के एक रेंडर का विचार लंबे समय से हवा में था, लेकिन यह गुणवत्ता कार्यान्वयन पर नहीं आया, खासकर Direct3D पर। अपने काम में, हम एक बहुत ही जंगली झुंड में आए और आगे हम बताएंगे कि इसके कारण हमें क्या मिला और यह कैसे काम करता है।




निष्पक्ष प्रतिपादन, या मान्यताओं के बिना प्रतिपादन, लेखों की एक श्रृंखला में मार्चेव्स्की द्वारा बहुत अच्छी तरह से वर्णित किया गया था
"GPU पर पथ ट्रेसिंग" भाग 1 , भाग 2 और " निष्पक्ष प्रतिपादन (मान्यताओं के बिना प्रतिपादन) ।"
संक्षेप में: यह एक प्रतिपादन है जो गणना में व्यवस्थित त्रुटियों को पेश नहीं करता है और शारीरिक रूप से सटीक प्रभावों को पुन: पेश करता है

• वैश्विक प्रकाश व्यवस्था
• नरम छाया, यथार्थवादी प्रतिबिंब
• क्षेत्र और गति धब्बा की गहराई
• उपसतह फैलाव और बहुत कुछ

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


1200x600 (क्लिक करने योग्य), AMD Radeon HD 6870, समय प्रस्तुत करना: 9 मिनट

क्यों Direct3D

कई GPGPU प्लेटफॉर्म (OpenCL, CUDA, FireStream, DirectCompute, C ++ AMP, Shaders, आदि) हैं, लेकिन अभी भी इष्टतम विकल्प के बारे में विवाद हैं, और इसका कोई स्पष्ट जवाब नहीं है कि इसका उपयोग करना बेहतर है। Direct3D के पक्ष में मुख्य तर्कों पर विचार करें, जिसके कारण हमें यह API नाम चुनना पड़ा:

• सभी प्रोसेसर मॉडल पर उत्सर्जित वीडियो कार्ड के पूरे स्पेक्ट्रम पर काम करता है: एक ही shader हर जगह काम करता है
• Direct3D विनिर्देशों उपभोक्ता लोहे के विकास की दिशा निर्धारित करते हैं
• हमेशा नवीनतम और सबसे स्थिर ड्राइवरों को पाने के लिए सबसे पहले
• अन्य क्रॉस-वेंडर तकनीक स्थिर या खराब समर्थित नहीं हैं।

ओपनसीएल और डायरेक्ट 3 डी से हमने बुराई को चुना, जिसमें कम से कम, स्थिर ड्राइवर हैं, जो गेमिंग उद्योग के दशकों से सम्मानित हैं, और कई बेंचमार्क में सबसे अच्छा प्रदर्शन किया है। इसके अलावा, कार्य के आधार पर, CUDA को गिरा दिया गया था, सभी उपकरणों के बावजूद, उदाहरणों की एक भरपूर संख्या और डेवलपर्स का एक मजबूत समुदाय। उस समय C ++ AMP की घोषणा अभी तक नहीं की गई थी, लेकिन क्योंकि इसका कार्यान्वयन DirectX के शीर्ष पर बनाया गया है, एक रेंडर को स्थानांतरित करना एक विशेष समस्या नहीं होगी।
OpenGL / GLSL बंडल पर भी विचार किया गया था, लेकिन DirectCompute (द्वि-दिशात्मक पथ अनुरेखण कार्य, आदि) का उपयोग करके DirectX में हल की गई सीमाओं के कारण जल्दी से हटा दिया गया था।

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

Direct3D क्यों नहीं

DirectX 10-11 की सभी घोषणाएं लिखती हैं कि नए शेडर मॉडल रे ट्रेसिंग और कई अन्य GPGPU कार्यों के लिए आदर्श हैं। लेकिन वास्तव में, किसी ने वास्तव में इस अवसर का उपयोग नहीं किया। क्यों?

• कोई उपकरण और समर्थन नहीं थे
• मार्केटिंग मजबूत होने के कारण NVIDIA CUDA की ओर रुख किया
• एक मंच के लिए लिंक

चलो एक साल पहले वापस आ गए। DX SDK का अंतिम अद्यतन जुलाई 2010 में था। VisualStudio के साथ कोई एकीकरण नहीं है, व्यावहारिक रूप से कोई GPGPU डेवलपर समुदाय और सामान्य कंप्यूटिंग कार्यों के उच्च-गुणवत्ता वाले उदाहरण नहीं हैं। खैर, कोई सिंटैक्स हाइलाइटिंग नहीं है! कोई भी डीबग उपकरण नहीं हैं। PIX कोड के 400+ लाइनों में कई नेस्टेड छोरों या shader को झेलने में सक्षम नहीं है। D3DCompiler समय के माध्यम से गिर सकता है और दसियों मिनट के लिए जटिल रंगों को संकलित कर सकता है। नरक।

दूसरी ओर, प्रौद्योगिकी का कमजोर परिचय। अधिकांश वैज्ञानिक लेखों और प्रकाशनों को CUDA का उपयोग करके लिखा गया है, और उन्हें NVIDIA हार्डवेयर के लिए ट्यून किया गया है। NVIDIA OptiX टीम भी विशेष रूप से अन्य विक्रेताओं के लिए अनुसंधान में रुचि नहीं है। जर्मन कंपनी का उल्लेख है, जिसने इस क्षेत्र में दशकों का अनुभव और पेटेंट प्राप्त किया है, अब यह भी NVIDIA के अंतर्गत आता है। यह सब एक विक्रेता के प्रति अस्वस्थ पूर्वाग्रह पैदा करता है, लेकिन बाजार एक बाजार है। हमारे लिए, इसका मतलब यह था कि सभी नए GPGPU ट्रेसिंग और रेंडरिंग तकनीकों को नए सिरे से तलाशने की जरूरत थी, लेकिन केवल DirectX और ATI और Intel हार्डवेयर पर, जिसके कारण अक्सर VLIW5 आर्किटेक्चर पर पूरी तरह से अलग परिणाम सामने आए।

कार्यान्वयन

समस्याओं को ठीक करना
कार्यान्वयन का वर्णन करने से पहले, मैं कुछ उपयोगी सुझाव दूंगा जिससे हमें विकास में मदद मिली:

• यदि संभव हो, तो VisualStudio2012 में अपग्रेड करें। डायरेक्टएक्स के साथ लंबे समय से प्रतीक्षित एकीकरण, बिल्ट-इन डिबग शेड्स, और लो और निहारना, एचएलएसएल सिंटैक्स हाइलाइटिंग आपको बहुत समय बचाएगा।
• यदि VS2012 नहीं है, तो आप NVidia समानांतर एनएसटी जैसे उपकरणों का उपयोग कर सकते हैं, लेकिन फिर से एक प्रकार के GPU के लिए एक बंधन है।
• विंडोज 8.0 एसडीके का उपयोग करें, यह आपका भाई है। भले ही आप Windows Vista / 7 और VisualStudio के पुराने संस्करणों पर विकसित कर रहे हैं, तो आपके पास अपने नवीनतम डी 3 डी लाइब्रेरीज़ सहित नवीनतम डी 3 डी लाइब्रेरीज़ का निपटान होगा, जो कि छाया संकलन समय को 2-4 गुना कम कर देता है और काफी काम करता है। विंडोज 8.0 एसडीके से डायरेक्टएक्स को कॉन्फ़िगर करने के लिए एक विस्तृत मैनुअल है ।
• यदि आप अभी भी डी 3 डीएक्स का उपयोग कर रहे हैं, तो इसे छोड़ने पर विचार करें, यह कोई बड़ी बात नहीं है। विंडोज 8.0 में, एसडीके ने स्पष्ट कारणों से इसका समर्थन करना बंद कर दिया।

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

प्रतिपादन
प्रतिपादन के आयोजन के लिए दो मुख्य दृष्टिकोण हैं:

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

हम GPGPU के लिए शेड्स का उपयोग करते हुए पहले विकल्प पर बसे, लेकिन इससे पहले कि आप कुछ भी रेंडर करें, आपको जियोमेट्री मेमोरी में सही ढंग से रखकर ज्यामिति और दृश्य डेटा तैयार करने की आवश्यकता है।
दृश्य डेटा में शामिल हैं:

• ज्यामिति (कोने, त्रिकोण, मानदंड, बनावट निर्देशांक)
• त्वरित संरचना (नोड्स केडी - एक पेड़ या बीवीएच का)
• सतह सामग्री (प्रकार, रंग, बनावट के संकेत, चिंतनशील प्रदर्शक, और बहुत कुछ)
• सामग्री, सामान्य नक्शे, आदि की बनावट।
• प्रकाश स्रोत (एकवचन और विस्तारित)
• कैमरा स्थिति और पैरामीटर, जैसे डीओएफ, एफओवी, आदि।

प्रतिपादन करते समय कोई शीर्ष और सूचकांक बफ़र्स का उपयोग नहीं किया जाता है। Direct3D11 में, डेटा एकीकृत होता है, सब कुछ एक ही प्रारूप में संग्रहीत किया जाता है, लेकिन आप डिवाइस को उन्हें देखने का तरीका बता सकते हैं: जैसे बफ़र, टेक्सचर 1 डी / 2 डी / ऐरे / सीयूबीई, रेंडरटार्ग इत्यादि। डेटा से अधिक - कम लीनियर एक्सेस बफ़र्स के रूप में संग्रहीत किया जाता है। यादृच्छिक अभिगम के साथ डेटा, उदाहरण के लिए, दृश्य संरचनाओं को तेज करना, एक बनावट में सबसे अच्छा संग्रहीत है, क्योंकि लगातार पहुंच के साथ, डेटा का हिस्सा कैश किया जाता है।
लगातार बदलते बफर में डेटा के तेजी से और छोटे टुकड़ों को स्टोर करना उचित है, ये कैमरा पैरामीटर, प्रकाश स्रोत और सामग्री हैं, अगर उनमें से कई नहीं हैं और वे 4096 x फ्लोट 4 आकार के बफर में फिट होते हैं। इंटरैक्टिव रेंडरिंग में, कैमरे की स्थिति को बदलना, सामग्री और प्रकाश को समायोजित करना सबसे आम ऑपरेशन है। ज्यामिति परिवर्तन कुछ कम आम हैं, लेकिन अभी भी इसे समायोजित करने के लिए पर्याप्त निरंतर स्मृति नहीं है।

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

साटन में पैकिंग बनावट:


परिणामस्वरूप, स्मृति में डेटा का स्थान इस तरह दिखता है:


यह माना जाता है कि प्रकाश और सामग्री का डेटा निरंतर रजिस्टरों में फिट करने में सक्षम होगा। लेकिन अगर दृश्य काफी जटिल है, तो सामग्री और प्रकाश को वैश्विक स्मृति में रखा जाएगा, जहां उनके लिए पर्याप्त जगह होनी चाहिए।



हम रेंडरिंग की ओर मुड़ते हैं: वर्टेक्स शेडर में, स्क्रीन के आकार का एक क्वाड, क्वाड ड्रा करते हैं, और टेक्सल्स को मैप करने की तकनीक का उपयोग करते हैं, ताकि पिक्सेलकरण के दौरान पिक्सेल शेडर के प्रत्येक पिक्सेल में सही टेक्सचर निर्देशांक हो, और इसलिए स्क्रीन पर सही x और y मान हो।

इसके अलावा, shader में प्रत्येक पिक्सेल के लिए, एक किरण पथ अनुरेखण एल्गोरिथ्म की गणना की जाती है। इस तरह, GPGPU गणना पिक्सेल शेड्स पर की जाती हैं। यह दृष्टिकोण सबसे इष्टतम नहीं लग सकता है, और DirectCompute का उपयोग करना अधिक उचित होगा, जिसके लिए आपको किसी भी शीर्ष shaders और स्क्रीन क्वाड को बनाने की आवश्यकता नहीं है। लेकिन कई परीक्षणों से पता चला है कि DirectCompute 10-15% धीमा है। पथ अनुरेखण कार्य में, एल्गोरिथ्म की यादृच्छिक प्रकृति के कारण SharedMemory का उपयोग करने या रे पैकेट का उपयोग करने के सभी लाभ जल्दी से फीका हो जाते हैं।

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

vlado पोस्ट किया गया:

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

बहु - कोर। मल्टी - डिवाइस। बादल।

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

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

डायरेक्टएक्स 11 के आगमन के साथ, अद्भुत तकनीक बचाव में आई - डब्ल्यूएआरपी (विंडोज एडवांस्ड रैस्टराइजेशन प्लेटफ़ॉर्म)। WARP डिवाइस आपके GPU कोड को SSE - अनुकूलित बहु-थ्रेडेड कोड में बदल देता है, जिससे आप सभी CPU कोर पर GPU गणना कर सकते हैं। और बिल्कुल किसी भी सीपीयू: x86, x64 और यहां तक ​​कि एआरएम! प्रोग्रामिंग के दृष्टिकोण से, ऐसा उपकरण GPU डिवाइस से अलग नहीं है। यह WARP के आधार पर विषम गणना C ++ AMP में कार्यान्वित किया जाता है। WARP डिवाइस भी आपका भाई है, WARP डिवाइस का उपयोग करें।


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


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

परिणाम

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



अब यह बंद अल्फा परीक्षण के चरण में है। यदि आप GPU-उत्साही, 3D - कलाकार हैं, तो ATI / NVIDIA क्लस्टर बनाने की योजना बना रहे हैं, आपके पास विभिन्न GPU और CPU या किसी अन्य दिलचस्प कॉन्फ़िगरेशन का एक गुच्छा है, मुझे बताएं कि यह एक साथ काम करना दिलचस्प होगा। मैं इस तरह से कुछ के लिए रेंडर की जांच करना पसंद करूंगा:


इसके अलावा, रेंडर के सी ++ एएमपी संस्करण के सामने, अन्य संपादकों के लिए अधिक गंभीर क्लाउड परीक्षण और प्लग-इन विकास। अब सम्मिलित हों!