Q100188: Mari और विशिष्ट परियोजनाओं में प्रदर्शन में सुधार

सर्वोत्तम प्रदर्शन के लिए MARI स्थापना

परियोजना स्थान

यह पुरजोर अनुशंसा की जाती है कि प्रोजेक्ट कैश को SSD (सॉलिड-स्टेट ड्राइव) पर रखा जाए। प्रोजेक्ट स्थान को संपादन > प्राथमिकताएँ > डेटा > प्रोजेक्ट > प्रोजेक्ट स्थान में बदला जा सकता है।

व्यूपोर्ट

व्यूपोर्ट को बहुत बड़ा करने से बचें: रेंडर करने के लिए जितने अधिक पिक्सेल होंगे, व्यूपोर्ट उतना ही धीमा होगा। चरम मामलों में, कुछ ज्यामिति छिपाने से फ़्रेमरेट में सुधार हो सकता है।

निगरानी करना

4K मॉनिटर्स : यदि आप 4k मॉनिटर पर काम कर रहे हैं, Mari पारंपरिक एचडी मॉनिटर की तुलना में व्यूपोर्ट में अधिक पिक्सेल प्रस्तुत करना होगा। कम पिक्सेल वाले मॉनिटर का उपयोग करने की तुलना में व्यूपोर्ट में रेंडरिंग समय धीमा हो सकता है।

एकाधिक मॉनिटर्स : यदि आपका व्यूपोर्ट कई मॉनिटरों तक फैला हुआ है, तो प्रदर्शन थोड़ा प्रभावित होगा क्योंकि GPU को एक साथ दो डिस्प्ले से गुजरना होगा।

संपादित करें > प्राथमिकताएँ > GPU टैब

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

बेकिंग और प्रोजेक्शन > मिप-मैप जेनरेशन - "फास्ट"

कोई रैखिककरण नहीं किया जाता है और छवि के मूल रंगस्थान में डाउनसैंपलिंग की जाती है।
यह बफर से कैनवास तक पेंट पकाने जैसी चीजों की प्रक्रिया को गति देता है, लेकिन गणित के गैर-रेखीय होने के कारण त्रुटियां हो सकती हैं।

छाया मानचित्र > अनुमति - अक्षम

व्यूपोर्ट में अधिक सटीक छाया उत्पन्न करने के लिए शैडो मैप्स को सक्षम किया जा सकता है, लेकिन इसे अक्षम करने से सिस्टम संसाधन खाली हो जाते हैं।

आभासी बनावट > प्रकार - "बाइट"

प्रदर्शन के लिए कैश्ड चैनल डेटा के डेटा प्रकार को नियंत्रित करता है। इसे बढ़ाने से GPU मेमोरी की अधिक लागत पर प्रदर्शित मूल्यों की सटीकता में सुधार होगा।

आभासी बनावट > परत गणना - कम मान

2डी बनावट परतों की संख्या को नियंत्रित करता है।

इसे बढ़ाने से झिलमिलाती बनावट के साथ समस्याएं हल हो सकती हैं, और मॉडल को गिराने की गति बढ़ सकती है।

वर्चुअल टेक्सचर में प्रत्येक 2D टेक्सचर परत आपके GPU पर 2GB मेमोरी के बराबर होती है। आपकी GPU मेमोरी सीमा से अधिक होने पर समस्याएँ उत्पन्न होंगी।

शेडर्स > संकलन मोड - "स्वचालित"

हालाँकि अधिकांश Mari सत्रों के लिए डिफ़ॉल्ट स्वचालित मोड आदर्श है, विशिष्ट कार्यों के लिए अन्य मोड तेज़ हो सकते हैं। अधिक जानकारी के लिए, कृपया निम्नलिखित लेख देखें: Q100308: Mari के शेडर संकलन मोड

विंडोज़ - TdrDelay और TdrDdiDelay

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

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

टीडीआर रजिस्ट्री कुंजियों के बारे में अधिक जानकारी के लिए कृपया निम्नलिखित देखें माइक्रोसॉफ्ट आलेख.

लिनक्स - अनुशंसित फ़ाइल सिस्टम

लिनक्स पर उपयोगकर्ताओं को लग सकता है कि यदि वे EXT3 या EXT4 फ़ाइल सिस्टम का उपयोग करते हैं तो वे प्रदर्शन में उल्लेखनीय वृद्धि कर सकते हैं, क्योंकि यह स्वाभाविक रूप से Mari प्रोजेक्ट पढ़ने और लिखने के तरीके के अनुकूल है।

किसी प्रोजेक्ट को खोलते या सहेजते समय, Mari अपनी कैश निर्देशिका में बहुत बड़ी संख्या में छोटी फ़ाइलों का उपयोग करती है, जिन्हें प्रोजेक्ट लोकेशन कहा जाता है। उदाहरण के लिए, पुराने ब्लैकस्मिथ बॉडी उदाहरण में प्रत्येक 10-90 केबी की 75000 फ़ाइलें थीं।

हमारे आंतरिक परीक्षणों से संकेत मिलता है कि जब बड़ी संख्या में छोटी फ़ाइलों को प्रबंधित करने की बात आती है तो EXT3 या NTFS जैसी फ़ाइल प्रणालियाँ सर्वोत्तम प्रदर्शन प्रदान करती हैं। XFS फ़ाइल सिस्टम उतने पर्याप्त नहीं हैं और हमारे पास उपयोगकर्ताओं की रिपोर्ट है कि वे EXT की तुलना में धीमे हो सकते हैं। यही कारण है कि Mari वर्तमान में XFS फ़ाइल सिस्टम का उपयोग करते समय एक चेतावनी दिखाती है।