GPU बाध्य। वीडियो कार्ड और थोड़ा और सब कुछ कैसे स्थानांतरित किया जाए। एनिमेशन

एक बार, यह एक बड़ी घटना थी जब एक मल्टीटेक्स्चर यूनिट या हार्डवेयर परिवर्तन और प्रकाश व्यवस्था (टी एंड एल) जीपीयू पर दिखाई दी। फिक्स्ड फंक्शन पाइपलाइन की स्थापना जादुई शर्मिंदगी थी। और जो लोग जानते थे कि डी 3 डी 9 एपीआई हैक्स के माध्यम से विशिष्ट चिप्स की उन्नत सुविधाओं को कैसे सक्षम और उपयोग करना है, उन्होंने खुद को ज़ेन सीखा है। लेकिन समय बीतता गया, शेड्स दिखाई दिए। सबसे पहले, कार्यक्षमता और लंबाई दोनों में दृढ़ता से सीमित। इसके अलावा, अधिक से अधिक सुविधाओं, अधिक निर्देश, अधिक गति। कम्प्यूट (CUDA, OpenCL, DirectCompute) दिखाई दिया, और वीडियो कार्ड कैपेसिटी का दायरा तेजी से विस्तार करने लगा।

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

Oooo, फिर से एनीमेशन। इसके बारे में सौ बार पहले ही लिखा और वर्णित किया जा चुका है। इतना जटिल क्या है? हम हड्डियों के मैट्रिक्स को बफर / बनावट में पैक करते हैं, और इसे वर्टेक्स शेल्डर में स्किनिंग के लिए उपयोग करते हैं। इसे GPU रत्न 3 (अध्याय 2. एनिमेटेड क्राउड रेंडरिंग) में वापस वर्णित किया गया है। और हाल ही में एकजुट टेक प्रस्तुति में कार्यान्वित किया गया। क्या यह दूसरे तरीके से संभव है?

एकता से टेक्नोडेमका

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

बड़े पैमाने पर लड़ाई में, दो सेनाएँ लड़ती हैं, जिनमें से प्रत्येक में एक प्रकार की इकाई होती है। बाईं ओर कंकाल, दाईं ओर शूरवीर। विविधता इतनी है। प्रत्येक इकाई में 3 LODs (~ 300, ~ 1000, ~ 4000 कोने प्रत्येक) होते हैं, और केवल 2 हड्डियां शीर्ष को प्रभावित करती हैं। एनीमेशन प्रणाली में प्रत्येक प्रकार की इकाई के लिए केवल 7 एनिमेशन होते हैं (मुझे याद है कि उनमें से 2 पहले से ही हैं)। एनिमेशन में मिश्रण नहीं है, लेकिन नौकरी कोड में निष्पादित सरल कोड से विवेकपूर्वक स्विच करें, जो प्रस्तुति में जोर दिया गया है। कोई राज्य मशीन नहीं है। जब हमारे पास दो प्रकार की जाली होती है, तो आप इस पूरी भीड़ को दो इंस्टेंट ड्रॉ कॉल में आकर्षित कर सकते हैं। कंकाल एनीमेशन, जैसा कि मैंने पहले ही लिखा था, 2009 में वापस वर्णित तकनीक पर आधारित है।
Innovatively? हम्म ... एक सफलता? उम ... आधुनिक खेलों के लिए उपयुक्त है? खैर, शायद, एफपीएस का अनुपात इकाइयों की संख्या में घमंड करता है।

इस दृष्टिकोण के मुख्य नुकसान (बनावट में प्री-मैट्रिक्स):

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

GPAs

GPU संचालित एनीमेशन सिस्टम। बस नाम आ गया।
नई एनीमेशन प्रणाली में कई आवश्यकताएं थीं:

1. तेजी से काम करें (अच्छी तरह से, समझने योग्य)। आपको हजारों विभिन्न इकाइयों के दसियों को चेतन करने की आवश्यकता है।
2. एकता एनीमेशन प्रणाली का एक पूर्ण (या लगभग) एनालॉग होना। यदि एनीमेशन इस तरह दिखता है, तो नए सिस्टम में यह बिल्कुल वैसा ही दिखना चाहिए। अंतर्निहित सीपीयू और जीपीयू सिस्टम के बीच स्विच करने की क्षमता। डिबगिंग के लिए यह अक्सर आवश्यक होता है। जब एनिमेशन "छोटी गाड़ी" हैं, तो क्लासिक एनिमेटर पर स्विच करके आप समझ सकते हैं: ये नई प्रणाली के ग्लिच हैं, या राज्य मशीन / एनीमेशन ही हैं।
3. सभी एनिमेशन एकता एनिमेटर में अनुकूलन योग्य हैं। एक सुविधाजनक, परीक्षण किया हुआ, और सबसे महत्वपूर्ण रूप से तैयार-टू-यूज़ टूल। हम कहीं और बाइक बनाएंगे।

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

आइए एनीमेशन एनीमेशन में एनीमेशन का एक उदाहरण देखें:



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

स्थिति - वेक्टर 3, चतुर्धातुक - वेक्टर 4, स्केल - वेक्टर 3। कीफ़्रेम संरचना में एक चीज़ सामान्य (सरलीकरण के लिए) होगी, इसलिए हमें उपरोक्त में से किसी भी प्रकार को फिट करने के लिए 4 फ्लोट की आवश्यकता है। हमें वक्रता के अनुसार keyframes के बीच सही प्रक्षेप के लिए InTangent और OutTangent की भी आवश्यकता होती है। अरे हाँ, और सामान्यीकृत समय नहीं भूलता:

struct KeyFrame { float4 v; float4 inTan, outTan; float time; }; 

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

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

अब दिलचस्प है। GPU कंकाल एनीमेशन।

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

प्रत्येक कीफ़्रेम, चाहे वह किसी भी आकार का हो (अनुवाद, रोटेशन, स्केल), एक ही तरीके से प्रक्षेपित होता है (रैखिक खोज द्वारा खोज, मुझे माफ़ करें नथ):

 void InterpolateKeyFrame(inout float4 rv, int startIdx, int endIdx, float t) { for (int i = startIdx; i < endIdx; ++i) { KeyFrame k0 = keyFrames[i + 0]; KeyFrame k1 = keyFrames[i + 1]; float lerpFactor = (t - k0.time) / (k1.time - k0.time); if (lerpFactor < 0 || lerpFactor > 1) continue; rv = CurveInterpoate(k0, k1, lerpFactor); break; } } 

वक्र एक घन बेज़ियर वक्र है, इसलिए प्रक्षेप समारोह इस प्रकार होगा:

 float4 CurveInterpoate(KeyFrame v0, KeyFrame v1, float t) { float dt = v1.time - v0.time; float4 m0 = v0.outTan * dt; float4 m1 = v1.inTan * dt; float t2 = t * t; float t3 = t2 * t; float a = 2 * t3 - 3 * t2 + 1; float b = t3 - 2 * t2 + t; float c = t3 - t2; float d = -2 * t3 + 3 * t2; float4 rv = a * v0.v + b * m0 + c * m1 + d * v1.v; return rv; } 

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



ब्लेंडट्री वॉक का वजन 0.35, रन - 0.65 होगा। तदनुसार, हड्डियों की अंतिम स्थिति 4 एनिमेशन द्वारा निर्धारित की जानी चाहिए: वॉक 1, वॉक 2, रन 1 और रन 2। उनके वजन में क्रमशः मान (0.35 * 0.92, 0.35 * 0.08, 0.65 * 0.92, 0.65 * 0.08) = (0.322, 0.028, 0.598, 0.052) होगा। यह ध्यान दिया जाना चाहिए कि वजन का योग हमेशा एक के बराबर होना चाहिए, या जादू कीड़े प्रदान किए जाते हैं।

सम्मिश्रण समारोह के "दिल":

 float bw = animDef.blendWeight; BoneXForm boneToBlend = animatedBones[srcBoneIndex]; float4 q = boneToBlend.quat; float3 t = boneToBlend.translate; float3 s = boneToBlend.scale; if (dot(resultBone.quat, q) < 0) q = -q; resultBone.translate += t * bw; resultBone.quat += q * bw; resultBone.scale += s * bw; 

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

एक उदाहरण:

 float4x4 animMat = IdentityMatrix(); float4x4 mat = initialPoses[boneId]; while (boneId >= 0) { BoneXForm b = blendedBones[boneId]; float4x4 xform = MakeTransformMatrix(b.translate, b.quat, b.scale); animMat = mul(animMat, xform); boneId = bonesHierarchyIndices[boneId]; } mat = mul(mat, animMat); resultSkeletons[id] = mat; 

यहाँ, सिद्धांत रूप में, एनिमेशन और सम्मिश्रण के सभी मुख्य बिंदु।

GPSM

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

बेकिंग चरण

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

राज्य मशीन की मुख्य संरचनाएं:

 struct State { float speed; int firstTransition; int numTransitions; int animDefId; }; struct Transition { float exitTime; float duration; int sourceStateId; int targetStateId; int firstCondition; int endCondition; uint properties; }; struct StateData { int id; float timeInState; float animationLoop; }; struct TransitionData { int id; float timeInTransition; }; struct CurrentState { StateData srcState, dstState; TransitionData transition; }; struct AnimationDef { uint animId; int nextAnimInTree; int parameterIdx; float lengthInSec; uint numBones; uint loop; }; struct ParameterDef { float2 line0ab, line1ab; int runtimeParamId; int nextParameterId; }; struct Condition { int checkMode; int runtimeParamIndex; float referenceValue; }; 

• राज्य में वह गति होती है जिस पर राज्य खेला जाता है, और राज्य मशीन के अनुसार दूसरों को संक्रमण के लिए शर्तों के सूचकांकों को।
• संक्रमण में राज्य के सूचकांक "से" और "से" होते हैं। संक्रमण समय, निकास समय और इस स्थिति में प्रवेश करने के लिए शर्तों की एक सरणी के लिए एक कड़ी।
• करंटस्टैट एक रनटाइम डेटा ब्लॉक है जो राज्य मशीन की वर्तमान स्थिति के डेटा के साथ है।
• एनिमेशनडिफ में ब्लेंडट्री द्वारा इससे संबंधित अन्य लोगों के लिंक के साथ एनीमेशन का वर्णन है।
• ParameterDef पैरामीटर का वर्णन है जो राज्य मशीनों के व्यवहार को नियंत्रित करता है। Line0ab और Line1ab पैरामीटर के मान द्वारा एनीमेशन के वजन को निर्धारित करने के लिए लाइनों के समीकरण के गुणांक हैं। यहाँ से:
  
  
  
• शर्त - पैरामीटर के रनटाइम मूल्य और संदर्भ मूल्य की तुलना करने के लिए स्थिति का एक विनिर्देश।

रनटाइम चरण

प्रत्येक राज्य मशीन का मुख्य चक्र निम्नलिखित एल्गोरिदम का उपयोग करके प्रदर्शित किया जा सकता है:



यूनिटी एनिमेटर में 4 प्रकार के पैरामीटर हैं: फ्लोट, इंट, बूल और ट्रिगर (जो बूल है)। हम उन सभी को फ्लोट के रूप में पेश करेंगे। शर्तों को स्थापित करते समय, छह प्रकार की तुलनाओं में से एक को चुनना संभव है। अगर == बराबर है। IfNot == NotEqual। तो हम केवल 4 का उपयोग करेंगे। ऑपरेटर संरचना को हालत संरचना के चेकमोड क्षेत्र में पास किया गया है।

 for (int i = t.firstCondition; i < t.endCondition; ++i) { Condition c = allConditions[i]; float paramValue = runtimeParameters[c.runtimeParamIndex]; switch (c.checkMode) { case 3: if (paramValue < c.referenceValue) return false; case 4: if (paramValue > c.referenceValue) return false; case 6: if (abs(paramValue - c.referenceValue) > 0.001f) return false; case 7: if (abs(paramValue - c.referenceValue) < 0.001f) return false; } } return true; 

संक्रमण शुरू करने के लिए, सभी शर्तें सही होनी चाहिए। अजीब केस लेबल सिर्फ (int) एनिमेटरकंडिशनमोड हैं। रुकावट का तर्क रुकावट और पीछे के संक्रमण को लुढ़काने के लिए एक मुश्किल तर्क है।

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

यूनिट कंट्रोल पैरामीटर यूनिट कंट्रोल लॉजिक से आते हैं। उदाहरण के लिए, आपको रनिंग को सक्षम करने की आवश्यकता है, चारस्पीड पैरामीटर सेट करें, और सही ढंग से कॉन्फ़िगर की गई स्टेट मशीन आसानी से "चल" से "रनिंग" में संक्रमण एनिमेशन को मिश्रित करती है।

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

प्रस्तुत करना

इकाई प्रतिपादन उदाहरण के माध्यम से किया जाता है। SV_InstanceID के अनुसार, शीर्ष छाया में, हमें सभी हड्डियों के मैट्रिक्स मिलते हैं जो शीर्ष को प्रभावित करते हैं, और इसे रूपांतरित करते हैं। बिल्कुल असामान्य कुछ भी नहीं:

 float4 ApplySkin(float3 v, uint vertexID, uint instanceID) { BoneInfoPacked bip = boneInfos[vertexID]; BoneInfo bi = UnpackBoneInfo(bip); SkeletonInstance skelInst = skeletonInstances[instanceID]; int bonesOffset = skelInst.boneOffset; float4x4 animMat = 0; for (int i = 0; i < 4; ++i) { float bw = bi.boneWeights[i]; if (bw > 0) { uint boneId = bi.boneIDs[i]; float4x4 boneMat = boneMatrices[boneId + bonesOffset]; animMat += boneMat * bw; } } float4 rv = float4(v, 1); rv = mul(rv, animMat); return rv; } 

परिणाम

क्या यह खेत तेजी से काम करता है? मैट्रिसेस के साथ बनावट का नमूना लेने की तुलना में स्पष्ट रूप से धीमा है, लेकिन फिर भी, मैं कुछ नंबर (जीटीएक्स 970) दिखा सकता हूं।

यहां 50,000 राज्य मशीनें हैं:



यहां 280,000 एनिमेटेड हड्डियां हैं:



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

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



पीपीएस हर समय, खेल मुख्य रूप से सीपीयू बाध्य थे, अर्थात्। सीपीयू ने GPU के साथ नहीं रखा। बहुत तर्क और भौतिकी। CPU से गेम लॉजिक का हिस्सा GPU में स्थानांतरित करते हुए, हम पहले को लोड करते हैं और दूसरे को लोड करते हैं, अर्थात। जीपीयू की स्थिति को और अधिक बाध्य कर सकता है इसलिए लेख का शीर्षक।