प्रॉम्प्ट और उपयोग का मामला (use case)
बैकग्राउंड से फिर से शुरू होने (resume), ड्राइवर अपडेट या रिसोर्स दबाव के बाद एक ब्राउज़र ग्राफ़िक्स ऐप ब्लैक कैनवस दिखाता है। WebGPU डिवाइस-लॉस हैंडलिंग डिज़ाइन करें: GPUDevice.lost को कैसे मॉनिटर करें, जानबूझकर किए गए विनाश (destruction) को अस्थायी नुकसान से कैसे अलग करें, डिवाइस और प्रत्येक GPU रिसोर्स को कैसे फिर से बनाएं, और समवर्ती रिकवरी प्रवाहों को एक-दूसरे पर ओवरराइट करने से कैसे रोकें। असमर्थित ब्राउज़र, स्थायी रूप से अनुपलब्ध एडेप्टर और सुगम रेंडरिंग फ़ॉलबैक को भी कवर करें।
साक्षात्कारकर्ता क्या टेस्ट कर रहा है
lostको एक सामान्य रेंडर त्रुटि के बजाय एक डिवाइस-लाइफ़साइकिल Promise के रूप में समझना।destroyedको ब्राउज़र, ड्राइवर या रिसोर्स प्रबंधन के कारण हुए नुकसान से अलग पहचानना।- एडेप्टर, डिवाइस, पाइपलाइन, बफ़र, टेक्सचर और बाइंड समूहों को फिर से बनाना।
- सिंगल-फ़्लाइट रिकवरी, पुराने-फ़्रेम रद्दीकरण (cancellation) और इडेम्पोटेंट आरंभीकरण डिज़ाइन करना।
- सुरक्षित संदर्भों (secure contexts), Workers, अनुकूलता और अवलोकनीयता (observability) को संभालना।
पहले स्पष्ट करने योग्य प्रश्न
- क्या ऐप एक रीयल-टाइम कैनवस, एडिटर या ऑफ़लाइन कंप्यूट जॉब है, और कौन सा रिकवरी समय स्वीकार्य है?
- क्या CPU-साइड दृश्यों (scenes), उपयोगकर्ता इनपुट और असहेजे गए एडिट्स को जीवित रहना चाहिए?
- कौन से ब्राउज़र, Workers, पावर स्थितियाँ और मेमोरी बजट दायरे में हैं?
- क्या विफलता पर WebGL, एक स्थिर पूर्वावलोकन, या रीलोड प्रॉम्प्ट पर स्विच करना चाहिए?
तीस सेकंड का उत्तर
मैं GPU डिवाइस को एक प्रतिस्थापन योग्य सत्र मानता हूँ: CPU-साइड दृश्य और रिसोर्स विवरण आधिकारिक होते हैं, जबकि GPU ऑब्जेक्ट्स कैश होते हैं। device.lost देखने के बाद, एक सिंगल-फ़्लाइट स्टेट मशीन सबमिशन को रोकती है और GPUDeviceLostInfo.reason को पढ़ती है; जानबूझकर किया गया destroyed सत्र समाप्त करता है, जबकि अन्य कारण एक नए एडेप्टर और डिवाइस, रिसोर्स पुनर्निर्माण और रेंडर-लूप रिकवरी को ट्रिगर करते हैं। बार-बार की विफलता या पहले से खोए हुए डिवाइस लौटाने वाला एडेप्टर एक फ़ॉलबैक पाथ में प्रवेश करता है, जिसमें कारण, रिकवरी समय और विफल रिसोर्स रिकॉर्ड किए जाते हैं।
विस्तृत उत्तर, चरण दर चरण
1. डिवाइस और एप्लिकेशन स्थिति को अलग करें
सीन ग्राफ़, मटीरियल पैरामीटर, ज्योमेट्री डेटा और टेक्सचर स्रोतों को CPU साइड पर रखें। डिवाइस, कतार (queue), बफ़र, टेक्सचर, पाइपलाइन और बाइंड समूह डिस्पोजेबल GPU-सत्र ऑब्जेक्ट हैं, व्यावसायिक सत्य नहीं।
2. लाइफ़साइकिल Promise को मॉनिटर करें
GPUDevice.lost डिवाइस के जीवनकाल के दौरान पेंडिंग रहता है और डिवाइस लॉस के बाद GPUDeviceLostInfo के साथ रिज़ॉल्व होता है। इनिशियलाइज़ेशन के बाद एक श्रोता (listener) पंजीकृत करें और कॉलबैक को एक रिकवरी स्टेट मशीन में भेजें।
3. लॉस के कारणों की व्याख्या करें
एक स्पष्ट GPUDevice.destroy() सामान्य रूप से reason destroyed से मेल खाता है, इसलिए इसे बिना शर्त रीस्टार्ट ट्रिगर नहीं करना चाहिए। ब्राउज़र रिसोर्स प्रबंधन, ड्राइवर अपडेट और अस्थायी डिवाइस त्रुटियां रिकवर हो सकती हैं; अनप्लग या पावर-अक्षम किया गया एडेप्टर पहले से खोए हुए डिवाइस लौटाना जारी रख सकता है।
4. सिंगल-फ़्लाइट रिकवरी गेट का उपयोग करें
प्रत्येक एनीमेशन फ्रेम को इनिशियलाइज़ करने की अनुमति देने के बजाय रिकवरी एंट्री पॉइंट से वही Promise लौटाएँ। सबमिशन रोकें, पुराने कमांड एन्कोडर्स को त्यागें, और पुराने डिवाइस से अतुल्यकालिक (asynchronous) कॉलबैक को अस्वीकार करने के लिए जेनरेशन टोकन का उपयोग करें।
5. विवरणों से रिसोर्सों का पुनर्निर्माण करें
बफ़र उपयोग, टेक्सचर आकार और प्रारूप, सैम्पलर्स, बाइंड-ग्रुप लेआउट, शेडर स्रोत और पाइपलाइन कॉन्फ़िगरेशन को सुरक्षित रखें। नया डिवाइस बनाने के बाद, निर्भरता क्रम में पुनर्निर्माण करें: शेडर्स और लेआउट, पाइपलाइन, बफ़र्स और टेक्सचर्स, व्यूज़, बाइंड ग्रुप्स, फिर कैनवस संदर्भ और रेंडर लूप।
6. CPU डेटा और बजट प्रबंधित करें
बड़े टेक्सचर और ज्योमेट्री फिर से पढ़े जाने योग्य URL, IndexedDB या संपीड़ित कैश से आ सकते हैं। मेमोरी बजट और रद्दीकरण सिग्नल के साथ दृश्यता- और प्राथमिकता-जागरूक बैचों में अपलोड करें, ताकि रिकवरी तुरंत रिसोर्स दबाव दोबारा न बनाए।
7. समवर्तीता (concurrency) और दृश्यता को संभालें
पेज का छिपना (hiding), Worker संदेश और उपयोगकर्ता के पुनः प्रयास सभी रिकवरी का अनुरोध कर सकते हैं। स्टेट मशीन को ready, lost, recovering और degraded तक सीमित रखें; केवल वर्तमान जेनरेशन ही फ़्रेम सबमिट कर सकती है। पेज छिपे होने के दौरान भारी पुनर्निर्माण में देरी करें।
8. फ़ॉलबैक और अवलोकनीयता डिज़ाइन करें
एडेप्टर और डिवाइस का अनुरोध करने से पहले सुरक्षित संदर्भ (secure context) और navigator.gpu की जाँच करें। बार-बार विफलता, स्थायी डिवाइस लॉस या असमर्थित ब्राउज़र के बाद, WebGL, एक स्थिर पूर्वावलोकन, या एक स्पष्ट रीलोड प्रॉम्प्ट पर स्विच करें। उपयोगकर्ताओं को आंतरिक त्रुटियाँ दिखाए बिना कारण, एडेप्टर जानकारी, प्रयास, अवधि, विफल रिसोर्स और फ़ॉलबैक अनुपात रिकॉर्ड करें।
समझौते और सीमाएँ (Trade-offs and boundaries)
एक नए डिवाइस का अनुरोध करने से पुराने बफ़र्स, टेक्सचर्स या पाइपलाइन्स पुनर्स्थापित नहीं होते हैं; उन्हें CPU-साइड विवरणों से फिर से बनाया जाना चाहिए। रिकवरी यह नहीं मान सकती कि प्रत्येक नुकसान अस्थायी है, और इसे अनंत पुनः प्रयासों के बजाय बैकऑफ़ का उपयोग करना चाहिए। WebGPU को एक सुरक्षित संदर्भ की आवश्यकता होती है और इसकी सीमित उपलब्धता बनी रहती है; Workers इस API का उपयोग कर सकते हैं, लेकिन ब्राउज़र और ड्राइवर अंतर रिलीज़ मैट्रिक्स में आते हैं।
रोलआउट योजना और प्रमाण
- एक CPU रिसोर्स मैनिफ़ेस्ट और एक GPU रिसोर्स फ़ैक्टरी बनाएँ जिसके निर्माण चरण दोहराने योग्य हों।
- डिवाइस, एडेप्टर, कैनवस संदर्भ और रेंडर लूप में एक जेनरेशन और सिंगल-फ़्लाइट रिकवरी स्थिति जोड़ें।
- जानबूझकर किए गए विनाश, बैकग्राउंड रिज़्यूमे, ड्राइवर रीसेट, मेमोरी दबाव और पहले से खोए हुए एडेप्टर मामलों को इंजेक्ट करें।
- रिसोर्स क्रम, उपयोगकर्ता-संपादन संरक्षण, फ़्रेम ठहराव और Workers सहित फ़ॉलबैक UI को सत्यापित करें।
- संगतता प्रमाण के रूप में MDN के
lostPromise,GPUDeviceLostInfo, सुरक्षित-संदर्भ और सीमित-उपलब्धता नोट्स का उपयोग करें।
सामान्य गलतियाँ और अनुवर्ती बातें
गलती 1: केवल requestDevice को दोबारा कॉल करना
नए डिवाइस में कोई पुराना रिसोर्स नहीं होता है। CPU विवरणों से पाइपलाइन, बफ़र्स, टेक्सचर्स, व्यूज़ और बाइंड ग्रुप्स को फिर से बनाएँ।
गलती 2: हर कारण को स्वचालित रूप से पुनः प्रयास करना
जानबूझकर किया गया विनाश सामान्य शटडाउन हो सकता है; स्थायी रूप से अनुपलब्ध एडेप्टर का पुनः प्रयास करने से लूप बनता है। बैकऑफ़ के साथ कारण के आधार पर शाखाएँ बनाएँ।
गलती 3: हर एनीमेशन फ़्रेम पर रिकवरी शुरू करना
समवर्ती प्रवाह साझा स्थिति पर प्रतिस्पर्धा करते हैं। एक सिंगल-फ़्लाइट Promise और जेनरेशन गेट एक वर्तमान सत्र सुनिश्चित करते हैं।
गलती 4: GPU ऑब्जेक्ट्स को व्यावसायिक स्थिति के रूप में मानना
डिवाइस लॉस GPU सत्र को साफ़ कर देता है। दृश्यों, उपयोगकर्ता इनपुट और रिसोर्स स्रोतों को डिवाइस से स्वतंत्र रखें।
गलती 5: असमर्थित और फ़ॉलबैक पाथ्स को अनदेखा करना
WebGPU बेसलाइन नहीं है और केवल सुरक्षित संदर्भों में उपलब्ध है। इसे जल्दी पहचानें और WebGL, एक स्थिर पूर्वावलोकन या एक रीलोड योजना प्रदान करें।