किसी विशेष राज्य परिवर्तन की वास्तविक लागत इतने सारे कारकों के साथ भिन्न होती है कि एक सामान्य उत्तर असंभव है।
सबसे पहले, प्रत्येक राज्य परिवर्तन में संभवतः सीपीयू-साइड लागत और जीपीयू-साइड लागत दोनों हो सकते हैं। आपके ड्राइवर और ग्राफिक्स एपीआई के आधार पर सीपीयू की लागत पूरी तरह से मुख्य धागे पर या आंशिक रूप से एक पृष्ठभूमि धागे पर भुगतान की जा सकती है।
दूसरा, GPU की लागत उड़ान में काम की मात्रा पर निर्भर हो सकती है। आधुनिक जीपीयू बहुत ही पाइपलाइनयुक्त हैं और एक ही बार में उड़ान में बहुत सारे काम पाने के लिए प्यार करते हैं, और आपको जो सबसे बड़ी मंदी मिल सकती है वह पाइपलाइन को रोकने से है ताकि राज्य में बदलाव होने से पहले जो कुछ भी उड़ान में हो उसे रिटायर होना चाहिए। क्या एक पाइपलाइन स्टाल का कारण बन सकता है? खैर, यह आपके GPU पर निर्भर करता है!
वास्तव में आपको यहां प्रदर्शन को समझने के लिए जानने की आवश्यकता है: आपके राज्य परिवर्तन को संसाधित करने के लिए ड्राइवर और GPU को क्या करने की आवश्यकता है? यह निश्चित रूप से आपके GPU पर निर्भर करता है, और यह भी कि ISVs अक्सर सार्वजनिक रूप से साझा नहीं करते हैं। हालांकि, कुछ सामान्य सिद्धांत हैं ।
जीपीयू आमतौर पर फ्रंटएंड और बैकएंड में विभाजित होते हैं। सीमांत चालक द्वारा उत्पन्न आदेशों की एक धारा को संभालता है, जबकि बैकेंड सभी वास्तविक कार्य करता है। जैसा कि मैंने पहले कहा, बैकएंड को उड़ान में बहुत काम करना पसंद है, लेकिन उसे उस काम के बारे में जानकारी संग्रहीत करने के लिए कुछ जानकारी की आवश्यकता होती है (शायद फ्रंटेंड द्वारा भरा गया है)। यदि आप पर्याप्त छोटे बैचों को लात मारते हैं और काम के सभी सिलिकॉन कीपिंग का उपयोग करते हैं, तो फ्रंटएड को स्टाल करना होगा, भले ही बहुत सारे अप्रयुक्त हॉर्सपावर बैठे हों। तो यहां एक सिद्धांत: जितना अधिक राज्य बदलता है (और छोटे ड्रा), उतनी ही संभावना है कि आप जीपीयू बैकएंड को भूखा करेंगे ।
जबकि एक ड्रा वास्तव में संसाधित किया जा रहा है, आप मूल रूप से सिर्फ shader प्रोग्राम चला रहे हैं, जो आपकी यूनिफ़ॉर्म, आपके वर्टेक्स बफर डेटा, आपके टेक्सचर, लेकिन साथ ही कंट्रोल स्ट्रक्चर्स को लाने के लिए मेमोरी एक्सेस कर रहे हैं, जो shader यूनिट्स को बताते हैं, जहाँ आपके शीर्ष बफ़र्स हैं। आपकी बनावट हैं और जीपीयू के पास उन मेमोरी एक्सेस के सामने कैश भी है। इसलिए जब भी आप नई वर्दी या नई बुनावट / बफर बाइंडिंग को जीपीयू पर फेंकते हैं, तो संभवत: यह एक कैश की कमी महसूस करता है जब पहली बार उन्हें पढ़ना पड़ता है। एक अन्य सिद्धांत: अधिकांश राज्य परिवर्तनों के कारण GPU कैश मिस होगा। (यह तब सबसे सार्थक होता है जब आप स्वयं निरंतर बफ़र्स का प्रबंधन कर रहे हैं: यदि आप ड्रॉ के बीच निरंतर बफ़र्स को समान रखते हैं, तो वे GPU पर कैश में बने रहने की अधिक संभावना रखते हैं।)
Shader संसाधनों के लिए राज्य परिवर्तनों की लागत का एक बड़ा हिस्सा CPU पक्ष है। जब भी आप एक नया निरंतर बफर सेट करते हैं, चालक सबसे अधिक संभावना है कि उस निरंतर बफर की सामग्री को GPU के लिए कमांड स्ट्रीम में कॉपी करें। यदि आप एक समान वर्दी सेट करते हैं, तो चालक बहुत संभव है कि आपकी पीठ के पीछे एक बड़े स्थिर बफर में बदल जाए, इसलिए इसे निरंतर बफर में उस वर्दी के लिए ऑफसेट को देखना होगा, मूल्य को कॉपी करें, फिर निरंतर बफर को चिह्नित करें के रूप में गंदा तो यह अगले ड्रॉ कॉल से पहले कमांड स्ट्रीम में कॉपी किया जा सकता है। यदि आप एक नई बनावट या शीर्ष बफ़र को बांधते हैं, तो ड्राइवर संभवतः उस संसाधन के लिए नियंत्रण संरचना की प्रतिलिपि बना रहा है। इसके अलावा, यदि आप मल्टीटास्किंग ओएस पर असतत जीपीयू का उपयोग कर रहे हैं, तो ड्राइवर को आपके द्वारा उपयोग किए जाने वाले प्रत्येक संसाधन को ट्रैक करने की आवश्यकता होती है और जब आप इसका उपयोग करना शुरू करते हैं ताकि कर्नेल ' s GPU मेमोरी मैनेजर गारंटी दे सकता है कि ड्रा होने पर उस संसाधन के लिए मेमोरी GPU के VRAM में निवासी हो। सिद्धांत:राज्य परिवर्तन, GPU के लिए एक न्यूनतम कमांड स्ट्रीम उत्पन्न करने के लिए ड्राइवर को फेरबदल मेमोरी बनाते हैं।
जब आप वर्तमान shader को बदलते हैं, तो आप शायद GPU कैश मिस कर रहे हैं (उनके पास अनुदेश कैश भी है!)। सिद्धांत रूप में, सीपीयू कार्य को कमांड स्ट्रीम में एक नया कमांड डालने तक सीमित होना चाहिए, जिसमें कहा गया है कि "शेडर का उपयोग करें।" वास्तविकता में, हालांकि, इससे निपटने के लिए shader संकलन की पूरी गड़बड़ी है। GPU ड्राइवर बहुत बार आलसी संकलन करते हैं, भले ही आपने समय से पहले shader बनाया हो। इस विषय के लिए अधिक प्रासंगिक है, हालांकि, कुछ राज्यों को मूल रूप से GPU हार्डवेयर द्वारा समर्थित नहीं किया जाता है और इसके बजाय shader प्रोग्राम में संकलित किया जाता है। एक लोकप्रिय उदाहरण है वर्टेक्स फॉरमेट: इन्हें चिप पर अलग राज्य होने के बजाय वर्टेक्स शेडर में संकलित किया जा सकता है। इसलिए यदि आप पहले किसी विशेष वर्कट शेडर के साथ उपयोग नहीं किए गए वर्टेक्स फॉर्मेट का उपयोग करते हैं, अब आप shader को पैच करने और shader प्रोग्राम को GPU तक कॉपी करने के लिए CPU लागत का एक गुच्छा दे सकते हैं। इसके अतिरिक्त, ड्राइवर और shader संकलक shader प्रोग्राम के निष्पादन को अनुकूलित करने के लिए सभी प्रकार के काम करने के लिए विश्वास कर सकता है। इसका मतलब यह हो सकता है कि आपकी वर्दी और संसाधन नियंत्रण संरचनाओं की मेमोरी लेआउट को अनुकूलित करना ताकि वे निकटवर्ती स्मृति या छायांकित रजिस्टरों में अच्छी तरह से पैक हो सकें। इसलिए जब आप शेड्स बदलते हैं, तो यह ड्राइवर को आपके द्वारा पहले से ही पाइप लाइन से जुड़ी हर चीज को देखने और नए शेडर के लिए एक पूरी तरह से अलग प्रारूप में वापस लाने का कारण हो सकता है, और फिर कमांड स्ट्रीम में कॉपी कर सकता है। सिद्धांत: इसका मतलब यह हो सकता है कि आपकी वर्दी और संसाधन नियंत्रण संरचनाओं की मेमोरी लेआउट को अनुकूलित करना ताकि वे निकटवर्ती स्मृति या छायांकित रजिस्टरों में अच्छी तरह से पैक हो सकें। इसलिए जब आप शेड्स बदलते हैं, तो यह ड्राइवर को आपके द्वारा पहले से ही पाइप लाइन से जुड़ी हर चीज को देखने और नए शेडर के लिए एक पूरी तरह से अलग प्रारूप में वापस लाने का कारण हो सकता है, और फिर कमांड स्ट्रीम में कॉपी कर सकता है। सिद्धांत: इसका मतलब यह हो सकता है कि आपकी वर्दी और संसाधन नियंत्रण संरचनाओं की मेमोरी लेआउट को अनुकूलित करना ताकि वे निकटवर्ती स्मृति या छायांकित रजिस्टरों में अच्छी तरह से पैक हो सकें। इसलिए जब आप शेड्स बदलते हैं, तो यह ड्राइवर को आपके द्वारा पहले से ही पाइप लाइन से जुड़ी हर चीज को देखने और नए शेडर के लिए एक पूरी तरह से अलग प्रारूप में वापस लाने का कारण हो सकता है, और फिर कमांड स्ट्रीम में कॉपी कर सकता है। सिद्धांत:बदलते शेड्स के कारण CPU मेमोरी में फेरबदल हो सकता है।
फ़्रेम बफ़र परिवर्तन संभवतः सबसे अधिक कार्यान्वयन-निर्भर हैं, लेकिन आमतौर पर GPU पर बहुत महंगा हैं। हो सकता है कि आपका GPU एक ही समय में अलग-अलग रेंडर टारगेट के लिए एक से अधिक ड्रॉ कॉल्स को हैंडल न कर पाए, इसलिए इसे उन दो ड्रॉ कॉल्स के बीच पाइपलाइन को स्टाल करने की आवश्यकता हो सकती है। इसे कैश फ्लश करने की आवश्यकता हो सकती है ताकि रेंडर लक्ष्य को बाद में पढ़ा जा सके। ड्राइंग के दौरान इसे स्थगित करने के लिए काम को हल करने की आवश्यकता हो सकती है। (गहराई बफ़र्स के साथ एक अलग डेटा संरचना जमा करना बहुत आम है, MSAA लक्ष्य प्रदान करता है, और भी बहुत कुछ। आपको उस रेंडर टारगेट से दूर जाने पर इसे अंतिम रूप देने की आवश्यकता हो सकती है। यदि आप एक GPU पर हैं जो टाइल-आधारित है। , कई मोबाइल GPU की तरह, जब आप एक फ्रेम बफर से दूर चले जाते हैं, तो काफी हद तक वास्तविक छायांकन कार्य को फ्लश करने की आवश्यकता हो सकती है।) सिद्धांत:GPU पर रेंडर टारगेट बदलना महंगा है।
मुझे यकीन है कि यह सब बहुत भ्रामक है, और दुर्भाग्य से यह बहुत विशिष्ट होना मुश्किल है क्योंकि विवरण अक्सर सार्वजनिक नहीं होते हैं, लेकिन मैं उम्मीद कर रहा हूं कि यह कुछ चीजों का आधा-सभ्य अवलोकन है जो वास्तव में चल रहे हैं जब आप कुछ राज्य कहते हैं अपने पसंदीदा ग्राफिक्स एपीआई में बदलते समारोह।
