लिनक्स ग्राफिक्स ढेर

(मूल - जैस्पर सेंट पियरे, गनोम शेल डेवलपर, यहां से लिया गया )

यह लिनक्स ग्राफिक्स स्टैक के घटकों के बारे में एक अवलोकन लेख है और वे एक साथ कैसे मिलते हैं। प्रारंभ में, मैंने ओवेन टेलर, रे स्ट्राउड और ईडन जैक्सन ( ओवेन टेलर - मेन्टेनर ऑफ ग्नोम शेल; मेनस्ट्रीमर ऑफ़ द रेडर समुदाय) के बड़ी संख्या में डेस्कटॉप पैकेजों के साथ इस स्टैक के बारे में बात करने के बाद इसे लिखा ; एडम जैक्सन - ग्राफिक स्टैक ग्नोम शेल और ग्राफिक स्टैक के डेवलपर के साथ एकीकरण। XOrg; अनुवादक की टिप्पणी) ।

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

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

यदि आपके कोई प्रश्न हैं, या यह आपको लगता है कि कुछ विवरण पर्याप्त रूप से स्पष्ट नहीं हैं (ठीक है, या तो मैं बहुत, बहुत गलत हूं या मैं किसी तरह भ्रमित हूं) - कृपया टिप्पणियों में इसके बारे में लिखने में संकोच न करें।

इसके साथ शुरू करने के लिए, यहाँ मैं संक्षेप में स्टैक के सभी घटकों को सूचीबद्ध करूँगा। खैर, आप के लिए आम तौर पर आगे के विवरण के दौरान उन्हें उन्मुख होना चाहिए।

सामान्य तौर पर, सटीक होने के लिए, आपके द्वारा चुने गए रेंडरिंग के प्रकार के आधार पर, स्टैक के अंदर घटनाओं के विकास के लिए दो अलग-अलग परिदृश्य होते हैं:

ओपन के साथ 3 डी प्रतिपादन

1. कार्यक्रम प्रतिपादन के लिए OpenGL का उपयोग करना शुरू करता है;
2. मेसा लाइब्रेरी आपको यह बहुत ओपनजीएल एपीआई प्रदान करती है। यह OpenGL कॉल को वीडियो कार्ड स्वीकार्य प्रारूप में बदलने के लिए आपके वीडियो कार्ड के विशिष्ट ड्राइवरों का उपयोग करता है। यदि गैलियम का उपयोग ड्राइवर के अंदर किया जाता है, तो एक साझा घटक भी जुड़ा हुआ है, जो ओपनजीएल कॉल को एक सामान्य मध्यवर्ती प्रतिनिधित्व, टीजीएसआई में बदल देता है। गैलियम के अंदर कॉल परिवर्तित करने के बाद, निम्न-स्तरीय ड्राइवर केवल TGSI को ऐसे हार्डवेयर कमांड में ट्रांसलेट कर सकता है जो हार्डवेयर के टुकड़े के लिए स्पष्ट हैं;
3. libdrm लिनक्स कर्नेल के साथ संचार करने के लिए विशेष ioctl का उपयोग करता है;
4. लिनक्स कर्नेल (जैसा कि ऐसा करने का अधिकार है) एक वीडियो कार्ड के लिए मेमोरी कार्ड को सीधे वीडियो कार्ड और सिस्टम मेमोरी दोनों में आवंटित कर सकता है;
5. इस सब के बाद, मीसा अपने स्तर पर DRI2 का उपयोग Xorg के साथ संवाद करने के लिए करता है, ताकि यह सुनिश्चित हो सके कि बफर स्विच हो गया है, और विंडोज़ की स्थिति, आदि। - सिंक्रनाइज़।

कैरो का उपयोग करते हुए 2 डी प्रतिपादन

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

खैर, स्क्रीन पर तैयार होने के लिए, एक्सएमएस खुद केएमएस और वीडियो कार्ड ड्राइवरों की मदद से एक फ्रेम बफर तैयार करता है।

X विंडो सिस्टम, X11, Xlib, Xorg

X11 ग्राफिक्स सिस्टम से सीधे संबंधित नहीं है - इसमें एक संदेश वितरण प्रणाली, खिड़की के गुणों का विवरण और बहुत कुछ शामिल है। इसके अलावा, X11 के शीर्ष पर, चीजों का एक गुच्छा लागू किया जाता है जो ग्राफिक्स के लिए पूरी तरह से अप्रासंगिक हैं (उदाहरण के लिए, क्लिपबोर्ड और ड्रैग-एंड-ड्रॉप समर्थन)। मैं X11 के बारे में यहां केवल X विंडो सिस्टम के अंदर अपनी जगह की सामान्य समझ के लिए लिख रहा हूं। उम्मीद है कि किसी दिन मैं एक्स विंडो सिस्टम, एक्स 11 और उनकी अजीब वास्तुकला के बारे में एक अलग पोस्ट लिख सकता हूं।

• X11
  संचार प्रोटोकॉल एक्स विंडो सिस्टम;
  
  
• Xlib
  X विंडो सिस्टम के क्लाइंट भाग का लाइब्रेरी कार्यान्वयन और विंडो प्रबंधन के अनुप्रयोग तर्क के लिए आधार। GTK + या Qt जैसे टूलकिट द्वारा उपयोग किया जाता है। वर्तमान अनुप्रयोगों में, यह व्यावहारिक रूप से सीधे उपयोग नहीं किया जाता है;
  
  
• XCB
  एक्स प्रोटोकॉल सी-भाषा बाइंडिंग। कभी-कभी एक्सलिब के विकल्प के रूप में जाना जाता है। अधिकांश X11 प्रोटोकॉल के कार्यान्वयन में शामिल है। XCB प्रोग्रामिंग इंटरफ़ेस उसी Xlib की तुलना में बहुत निचला स्तर है, और XlB के शीर्ष पर आधुनिक Xlib पूरी तरह से बनाया गया है। हम मान लेते हैं कि हमें बस याद है और एक और संक्षिप्त नाम है;
  
  
• Xorg
  एक्स विंडो सिस्टम के सर्वर साइड का लाइब्रेरी कार्यान्वयन।

मैं नामकरण में यथासंभव सटीक होने की कोशिश करता हूं। यदि मैं "एक्स-सर्वर" लिखता हूं, तो मैं अमूर्त सर्वर एक्स के बारे में बात कर रहा हूं - यह एक्सगोर हो सकता है, शायद ऐप्पल से सर्वर एक्स का कार्यान्वयन, या शायद केड्राइव। कोई फर्क नहीं। यदि मैं "X11" या "X विंडो सिस्टम" लिखता हूं, तो इसका मतलब है कि मेरा मतलब है कि प्रोटोकॉल की वास्तुकला और एक पूरे के रूप में सिस्टम। खैर, अगर मैं "Xorg" लिखता हूं, तो यह Xorg के कार्यान्वयन विवरणों के बारे में है, सबसे सामान्य एक्स सर्वर और किसी भी अन्य एक्स सर्वरों के कार्यान्वयन के विवरण के बारे में नहीं है। यदि आप सिर्फ "एक्स" मिलते हैं - यह एक टाइपो या एक जुआरी है।

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

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

हम थोड़ी देर बाद एक्स विंडो सिस्टम और इसके कुछ एक्सटेंशन पर लौट आएंगे।

काहिरा

काहिरा एक सदिश ग्राफिक्स रेंडरिंग लाइब्रेरी है जिसका उपयोग नियमित अनुप्रयोगों (उदाहरण के लिए, फ़ायरफ़ॉक्स) और जीटीके + जैसे विभिन्न टूलकिट दोनों द्वारा किया जाता है। उदाहरण के लिए, GTK + 3 रेंडरिंग मॉडल पूरी तरह से कैरो पर आधारित है। यदि आपने HTML <कैनवास> तत्वों के साथ काम किया है, तो आपको कैरो की पूरी तरह से समझ है, क्योंकि वास्तव में, उनका एपीआई समान है। इस तथ्य के बावजूद कि <कैनवास> मूल रूप से ऐप्पल द्वारा पेश किया गया था, वेक्टर ग्राफिक्स बहुत पहले पैदा हुए थे (यहां तक ​​कि पोस्टस्क्रिप्ट रेंडरिंग मॉडल से भी शुरू हुआ था, जो पीडीएफ, फ्लैश, एसवीजी, डायरेक्ट 2 डी, क्वार्ट्ज 2 डी, ओपनवीजी जैसे मानकों और प्रौद्योगिकियों में परिलक्षित होता था। और इसी तरह, उनमें से हजारों)।

काहिरा एक विशेष Xlib बैकएंड के माध्यम से X11 सतहों पर पेंट कर सकता है।

जीटीके + 2 में, 2.8 संस्करण तक, कैरो का उपयोग वैकल्पिक घटक के रूप में किया गया था। वर्तमान में, GTK + 3 कैरो को अनिवार्य माना जाता है।

एक्सटेंडर एक्सटेंशन

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

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

दुर्भाग्य से, अभ्यास से पता चला है कि सॉफ़्टवेयर रैस्टिरेशन (काफी अस्पष्ट कारणों के कारण) हार्डवेयर की गति में हीन नहीं है। ओह ठीक है।

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



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



साइकेडेलिक।

pixman

एक्स सर्वर और कैरो दोनों को पिक्सल के साथ काम करने की आवश्यकता है। इससे पहले, काहिरा और Xorg ने विभिन्न बफ़र्स (ARGB32, BGR24, RGB565), ग्रेडिएंट्स, मैट्रिसेस और बाकी सभी तरीकों से अलग-अलग तरीकों से रेखांकन, पिक्सेल-बाय-पिक्सेल पहुंच को लागू किया। अब, कैरो और एक्स सर्वर दोनों अपेक्षाकृत कम स्तर के पिक्समैन लाइब्रेरी के माध्यम से यह सब करते हैं। इस तथ्य के बावजूद कि पिक्समैन एक साझा पुस्तकालय है, इसमें ऑपरेशन के लिए एक सार्वजनिक एपीआई या विशिष्ट एपीआई नहीं है। कड़ाई से बोलते हुए, इसमें एक एपीआई नहीं है - यह पहले से उल्लेख किए गए दो घटकों के बीच इसे काट देने के लिए कोड का सिर्फ एक भंडार है।

ओपेंगल, मीसा, गैलियम

और यह मजेदार हिस्सा है - आधुनिक हार्डवेयर प्रतिपादन त्वरण। मेरा मानना ​​है कि सभी को पहले से ही पता है कि ओपनगेल क्या है। यह एक पुस्तकालय नहीं है, यह libGL.so के निर्माण के लिए स्रोतों का एक विशिष्ट सेट भी नहीं है। प्रत्येक निर्माता का अपना libGL.so है, जो एक तरह से या OpenGL विनिर्देश के साथ संगत है।

उदाहरण के लिए, एनवीडिया अपना ओपेनग्ल कार्यान्वयन और अपना स्वयं का लिबग.लो प्रदान करता है, जो एक ही विंडोज या ओएस एक्स के लिए अलग तरह से लागू किया जाता है।

यदि आप खुले स्रोत ड्राइवरों का उपयोग करते हैं, तो आपका libGL.so कार्यान्वयन मीसा पर आधारित होने की सबसे अधिक संभावना है। मेसा सब कुछ का एक बड़ा गुच्छा है, लेकिन इस ढेर का मुख्य और सबसे प्रसिद्ध हिस्सा खुला स्रोत ओपनजीएल कार्यान्वयन है। OpenGL API के लिए मीसा के अंदर, विभिन्न बैकेंड का उपयोग API को कार्यकारी टीमों में अनुवाद करने के लिए किया जाता है। तीन सॉफ्टवेयर बैकएंड हैं:

• स्वस्तिक - प्राचीन और भयानक। इसे दफनाने में मदद करें और इसका उपयोग कभी न करें;
• सॉफ्टपाइप - धीमा
• lvmpipe तेज है।

सॉफ्टवेयर बैकेंड के अलावा, मीसा हार्डवेयर का समर्थन करती है:

• इंटेल मीसा के साथ काम करता है और इसके हार्डवेयर के लिए मेसा-संगत ड्राइवरों को विकसित करता है, जिन्हें तब मेसा के हिस्से के रूप में आपूर्ति की जाती है। (यह इसके लिए अपने स्वयं के चालक वास्तुकला का उपयोग करता है, जो कि विभिन्न ओपनगैल डेवलपर्स के कई प्रश्न हैं। उदाहरण के लिए, ब्लास्टर) ;
• ओपन-सोर्स रैडॉन और नोवो ड्राइवर, जो सामान्य गैलियम वास्तुकला के शीर्ष पर बने हैं।

वास्तव में, गैलियम घटकों का एक सेट है जिसके शीर्ष पर आप बस एक चालक बना सकते हैं। मुद्दा यह है कि ड्राइवर में निम्न शामिल हैं:

• राज्य मशीनों का एक सेट जो एक विशिष्ट एपीआई (ओपनजीएल, जीएलएसएल, डायरेक्ट 3 डी) को लागू करता है;
• एक मध्यवर्ती प्रतिनिधित्व में एपीआई कन्वर्टर्स का एक सेट (तथाकथित टंगस्टन ग्राफिक्स शेडर इन्फ्रास्ट्रक्चर या टीजीएसआई में (रुचि रखने वालों के लिए, सचमुच, " वुल्फ्राम ग्राफिक शेडर इंफ्रास्ट्रक्चर") ;
• विशिष्ट हार्डवेयर टीमों के लिए TGSI का अनुवाद करने वाले बैकएंड।

दुर्भाग्य से, इंटेल डेवलपर्स गैलियम का उपयोग नहीं करते हैं। मेरे सहकर्मियों का कहना है कि यह इंटेल ड्राइवर डेवलपर्स की अनिच्छा के कारण है कि मेसा और उनके ड्राइवर के बीच कोई परत है।

कुछ कटौती

संकेतन जिसके लिए मैं एक अलग बड़े पैराग्राफ को एकल नहीं करना चाहता, कथा के बाद में मिलेंगे। इसलिए, मैं बस उन्हें यहां सूचीबद्ध करूंगा। उनमें से कई का केवल ऐतिहासिक मूल्य है, लेकिन, फिर भी, मैं उनके बारे में लिखूंगा। ताकि आपको पता चल जाए।

• GLES
  OpenGL के विभिन्न प्लेटफॉर्म कार्यान्वयन के लिए कई अलग-अलग संस्करण हैं। GLES उनमें से एक है। यह "जीएल एंबेडेड सिस्टम" या "जीएल एंबेडेड सबसेट" ("एम्बेडेड सिस्टम / जीएल का सबसेट") के लिए खड़ा है। OpenGL द्वारा एम्बेडेड समाधान बाजार में प्रवेश करने का यह नवीनतम प्रयास है। iPhone GLES संस्करण 2.0 का समर्थन करता है;
  
  
• GLX
  ओपनजीएल के अंदर, विशिष्ट प्लेटफार्मों की सभी प्रकार की परेशानियों और ड्राइंग के लिए सतहों तक पहुंच के कार्यान्वयन (उदाहरण के लिए, एक विंडो इंटरफ़ेस के आयोजन के लिए सिस्टम) निर्दिष्ट नहीं हैं। लेकिन, दुर्भाग्य से, X11 प्रोटोकॉल जैसे दुनिया की वास्तविकताओं के लिए OpenGL API को कॉल करने के परिणाम को परिवर्तित करने के लिए विभिन्न प्लेटफार्मों के लिए बाइंडरों की आवश्यकता होती है। जीएलएक्स - एक्स 11 के साथ ओपनिंग ग्लूइंग के लिए डिज़ाइन की गई एक परत;
  
  
• WGL
  हम पिछले पैराग्राफ को देखते हैं, "X11" को "विंडोज" से बदलें। हां, सब कुछ समान है, लेकिन Microsoft ऑपरेटिंग सिस्टम के लिए;
  
  
• EGL
  संक्षिप्त रूपों की समानता के कारण ईजीएल और जीएलईएस अक्सर भ्रमित होते हैं। ईजीएल एक अन्य एंटी-प्लेटफ़ॉर्म एपीआई सूट है, जिसे क्रोनोस ग्रुप (एक ही समूह जो ओपनजीएल से संबंधित है) द्वारा विकसित किया गया है। ईजीएल एप्लिकेशन को जल्दी से स्थापित करने और उस प्लेटफॉर्म की परवाह किए बिना दृश्य को आरंभ करने के लिए एक बुनियादी ढांचा किट प्रदान करता है, जिस पर यह एप्लिकेशन चलता है। ओपनजीएल की तरह, ईजीएल निर्माता-उन्मुख है। वास्तव में, यह डब्ल्यूजीएल / जीएलएक्स का एक विकल्प है, लेकिन न केवल उनके ऊपर निर्मित एक और बैसाखी (जैसे ग्लूट);
  
  
• नया कर्नेल
  एक बार Fglrx को Xorg के लिए AMD का मालिकाना ओपनग्ल ड्राइवर कहा जाता था। अब इसे "उत्प्रेरक" कहा जाता है। यह X के लिए "FireGL और Radeon" के लिए है। क्योंकि ड्राइवर मालिकाना है, तो उसका अपना, निजी, libGL.so है। मुझे नहीं पता कि यह मेसा पर आधारित है और क्या यह हमारे लिए हितकारी है। वास्तव में, fglrx मैं यहां केवल इसलिए उल्लेख करता हूं क्योंकि यह अक्सर AIGLX या GLX के साथ भ्रमित होता है क्योंकि इस तथ्य के कारण कि इन सभी संक्षिप्त रूपों में "जीएल" और "एक्स" हैं;
  
  
• DIX, DDX
  Xorg ग्राफिक्स सबसिस्टम में दो भाग होते हैं - DIX से, जो "ड्राइवर इंडिपेंडेंट X" के लिए है, और DDX से, जो क्रमशः "ड्राइवर डिपेंडेंट एक्स" ( "ड्राइवर इंडिपेंडेंट एक्स" और "ड्राइवर इंडिपेंडेंट एक्स" के लिए है, क्रमशः) । जब हम Xorg ड्राइवर से मतलब रखते हैं, तो DDX ड्राइवर के बारे में बात करना अधिक सही होगा;

ड्राइवर Xorg, DRM, DRI

इससे पहले, मैंने लिखा था कि Xorg हार्डवेयर-त्वरित रेंडरिंग का उत्पादन कर सकता है। मैं जोड़ता हूं कि यह X11 ड्राइंग कमांड्स को OpenGL API कॉल में अनुवाद करने के माध्यम से महसूस नहीं किया गया है। फिर हार्डवेयर के साथ Xorg कैसे काम करता है यदि हार्डवेयर ड्राइवर mesa और बोर्ग के आंत्र में काम करते हैं और mesa से बंधा नहीं है?

जवाब आसान है। कैसा है? ओपन के कार्यान्वयन के लिए मेसा जिम्मेदार है, X11 X11 कमांड के प्रतिपादन के लिए Xorg जिम्मेदार है, और दोनों को हार्डवेयर पर विशिष्ट हार्डवेयर कमांड का उपयोग करना चाहिए। एक समय में, Xorg और mesa की वास्तुकला में एक अलग घटक पेश किया गया था, जो इन आदेशों को कर्नेल में लोड करता है - तथाकथित "डायरेक्ट रेंडरिंग मैनेजर" या " DRM" ।

लिबड्रम ग्राफिक्स त्वरक के लिए संसाधनों को आवंटित करने और इसे बनावट के साथ कमांड प्रदान करने के लिए मूल बंद कर्नेल ioctls के एक सेट का उपयोग करता है। इन ioctls का सामान्य इंटरफ़ेस (सामान्य तौर पर, दो प्रकार का) हो सकता है:

• इंटेल GEM ;
• टंगस्टन ग्राफिक्स टेक्नोलॉजी सूट (हाँ, गैलियम शामिल है) से TTM ।

उनके बीच कोई महत्वपूर्ण अंतर नहीं हैं। वे दोनों एक ही काम करते हैं, वे कार्यान्वयन में बस थोड़ा भिन्न होते हैं। GEM को इंटेल द्वारा TTM के एक सरल विकल्प के रूप में ऐतिहासिक रूप से पेश किया गया है। कुछ समय बाद, GEM बड़ा हो गया है और "सादगी" TTM के समान हो गई है। ऐसी बातें।

यह सब क्यों? इसके अलावा, उदाहरण के लिए, जब आप ग्लक्सगियर्स जैसी उपयोगिता चलाते हैं, तो यह मेसा लोड करता है। मेसा डाउनलोड libdrm। Libdrm GEM / TTM का उपयोग करके कर्नेल चालक के साथ संचार करता है। हाँ, glxgears कर्नेल के साथ सीधे आपको कुछ कताई गियर दिखाने के लिए काम करता है, इस प्रकार आपको याद दिलाता है कि यह एक बेंचमार्किंग उपयोगिता है।
यदि आप कंसोल में कमांड चलाते हैं (आर्किटेक्चर के आधार पर lib32 / lib64 को प्रतिस्थापित करते हुए):

ls /usr/lib32/libdrm_*

आप देखेंगे कि हार्डवेयर पर निर्भर ड्राइवर हैं। उन मामलों के लिए जब GEM / TTM में एम्बेडेड कार्यक्षमता पर्याप्त नहीं है, मेसा और एक्स-सर्वर ड्राइवर कर्नेल के साथ संचार करने के लिए और भी अधिक बंद ioctls का एक और भी अधिक सेट प्रदान करते हैं, जो वास्तव में, इन डिवाइस-निर्भर ड्राइवरों में स्थित है। Libdrm स्वयं इन ड्राइवरों को लोड नहीं करता है।

एक्स सर्वर को यह जानना होगा कि सिंक्रोनाइज़ेशन को लागू करने के लिए ग्राफिक्स सबसिस्टम के साथ क्या हो रहा है। यह सिंक्रनाइज़ेशन पद्धति (उदाहरण के लिए, आपके द्वारा चलाए जा रहे glxgears के बीच, कर्नेल और X सर्वर) को DRI या, अधिक सही ढंग से DRI2 कहा जाता है। DRI का अर्थ है "डायरेक्ट रेंडरिंग इन्फ्रास्ट्रक्चर"। सामान्य तौर पर, DRI द्वारा दो बातों को समझा जाता है:

• एक परियोजना जो मेसा और Xorg (DRM और इसके चारों ओर पूरे बंधन) का सह-अस्तित्व प्रदान करती है;
• डीआरआई प्रोटोकॉल और संबद्ध पुस्तकालय।

चूंकि हम सख्त शब्दावली का पालन करते हैं, और DRI1 मूर्खतापूर्ण लगता है, हम प्रोटोकॉल और लाइब्रेरी के बारे में बात करेंगे, उन्हें DRI2 कहेंगे।

केएमएस

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

आपको हार्डवेयर को कॉन्फ़िगर करने की आवश्यकता है ताकि यह ग्राफिक्स प्रदर्शित कर सके।

अंदर, libdrm और कर्नेल के पास एक विशेष KMS सबसिस्टम है जो बस करता है। संक्षिप्त KMS "कर्नेल मोड सेटिंग" के लिए है । फिर, ioctl'ey के सेट के माध्यम से यह सबसिस्टम आपको ग्राफ़िक्स मोड सेट करने, फ़्रेम बफर को कॉन्फ़िगर करने और ग्राफिक्स को सीधे TTY में दिखाने के लिए आवश्यक सभी कुछ करने की अनुमति देता है। कर्नेल में KMS के प्रकट होने से पहले, ioctls का एक विविध सेट (और अभी भी कहीं नहीं गया), जिसके प्रतिस्थापन और मानकीकरण के लिए, वास्तव में, उन्होंने एक एकल और प्रलेखित एपीआई के साथ एक साझा libkms लाइब्रेरी बनाई।

सच है, अचानक (लिनक्स दुनिया में प्रथागत है) के बाद libkms, कर्नेल में एक नया एपीआई दिखाई दिया, जिसका शाब्दिक अर्थ है "बेवकूफ ioctls।" इसलिए, वर्तमान में यह अनुशंसा की जाती है कि आप libkms का उपयोग न करें, लेकिन यह ioctls का सेट है।

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

मॉडल, रिडायरेक्शन, टीएफपी, कंपोजिटिंग, एआईजीएलएक्स को बेनकाब करें

आप "रचनाकार विंडो प्रबंधक" शब्द के बारे में बात नहीं कर सकते हैं बिना यह समझे कि "रचना" क्या है और खिड़की प्रबंधक क्या करता है।

सुदूर 80 के दशक में, जब UNIX ऑपरेटिंग सिस्टम के लिए X विंडो सिस्टम आर्किटेक्चर विकसित किया गया था, तो HP, DEC, Sun और SGI जैसी कंपनियों के एक समूह ने X विंडो सिस्टम के आधार पर अपने उत्पादों का विकास किया। उसी समय, X11 प्रोटोकॉल ने विंडोज़ के प्रबंधन के लिए नियमों को विनियमित नहीं किया और उनके व्यवहार के लिए "विंडो मैनेजर" नामक एक अलग प्रक्रिया के लिए जिम्मेदारी सौंप दी।

उदाहरण के लिए, CDE, अपने समय का एक लोकप्रिय विंडोिंग वातावरण है, "ध्यान माउस का अनुसरण करता है" नामक विंडो व्यवहार से लैस है। इसका सार यह है कि इनपुट फ़ोकस को उस विंडो पर स्थानांतरित कर दिया गया था जब उपयोगकर्ता इसके ऊपर मंडराता था। यह विंडोज़ या मैक ओएस एक्स पर खिड़कियों के व्यवहार से भिन्न है, जिसमें क्लिक करके विंडो को फ़ोकस किया जाता है।

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

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



खिड़कियों के ऐसे सेट की कल्पना करें। अब GIMP विंडो को स्थानांतरित करें:



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

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

रचना का विस्तार खिड़कियों के कंपोजिशन मैनेजर (या " कंपोज़िटर ", "कंपोज़र") को तथाकथित कम्पोज़िट ओवरले विंडो ("कंपोज़िशन लेयर की विंडो") या गाय बनाने की अनुमति देता है । उसके बाद, संगीतकार को गाय की खिड़की का मालिक नियुक्त किया जाता है और उसे आकर्षित कर सकता है।

जब आप Compiz या GNOME शेल शुरू करते हैं, तो ये एप्लिकेशन स्क्रीन पर रीडायरेक्ट की गई विंडो प्रदर्शित करने के लिए OpenGL का उपयोग करते हैं। X सर्वर उन्हें GL एक्सटेंशन " Pixmap से बनावट " ("पिक्सेल मैप से बनावट") या TFP का उपयोग करके खिड़कियों की सामग्री का उपयोग करने की अनुमति देता है। यह एक्सटेंशन ओपन 11 एप्लिकेशन को X11 पिक्सेल मैप्स का उपयोग करने की अनुमति देता है जैसे कि वे मूल ओपनग्ल टेक्सचर थे।

सिद्धांत रूप में, समग्र विंडो प्रबंधक, TFP या OpenGL का उपयोग नहीं कर सकते हैं। बस TFP और OpenGL रचना का सबसे आसान तरीका है। कुछ भी नहीं मानक मानकों का उपयोग कर गाय पर बस पिक्सेल पिक्सेल खिड़कियों ड्राइंग से खिड़की प्रबंधक को रोकता है। मुझे बताया गया था कि kwin4 सीधे रचना के लिए Qt का उपयोग करता है।

कम्पोजल विंडो मैनेजर X सर्वर से TFP के माध्यम से एक पिक्सेल मैप प्राप्त करते हैं और इसे ओपनजीएल दृश्य में सही जगह पर खींचते हैं, यह भ्रम पैदा करता है कि आप एक नियमित X11 विंडो के साथ काम कर रहे हैं। यह मूर्खतापूर्ण प्रतीत हो सकता है कि इसे "भ्रम" कहा जा सकता है, लेकिन यदि आप उदाहरण के लिए, GNOME शेल का उपयोग करते हैं, तो आप रचना के "भ्रम" के बारे में सुनिश्चित हो सकते हैं। ऐसा करने के लिए, आप देख रहे ग्लास में GJS कोड दर्ज करके सक्रिय विंडो का आकार और स्थिति बदल सकते हैं:

global.get_window_actors().forEach(function(w) { w.scale_x = w.scale_y = 0.5; });

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

अब जब आप इन सभी विवरणों से अवगत हैं, तो आप एक और संक्षिप्त नाम - एआईजीएलएक्स के बारे में बात कर सकते हैं। AIGLX का अर्थ है "त्वरित अप्रत्यक्ष GLX" (त्वरित पारगमन / अप्रत्यक्ष GLX ) । चूंकि X11 एक नेटवर्क-उन्मुख प्रोटोकॉल है, इसलिए OpenGL को नेटवर्क के माध्यम से काम करने में सक्षम होना चाहिए। जब इस मोड में OpenGL का उपयोग किया जाता है, तो मानक "प्रत्यक्ष संदर्भ" मोड के विपरीत मोड को "अप्रत्यक्ष संदर्भ" कहा जाता है, जिसमें OpenGL का उपयोग उसी मशीन पर किया जाता है। दुखद बात यह है कि पारगमन संदर्भ के लिए नेटवर्क प्रोटोकॉल उचित रूप से अपूर्ण और अस्थिर है।

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

बहुत प्रशंसा और Phoronix के लेख के बावजूद, AIGLX का उपयोग गंभीर चीजों के लिए कभी नहीं किया गया है - सिर्फ इसलिए कि अब हमारे पास एक सामान्य DRI स्टैक है जहां हम TFP को कॉपी किए बिना लागू कर सकते हैं।

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

वेलैंड

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

X विंडो सिस्टम के सही रहने का कारण यह है कि इस बार समुदाय के प्रयासों को प्रतिस्थापित करने के लिए निर्देशित किया गया है। यह प्रतिस्थापन Xorg है, जिसमें कई प्रकार के एक्सटेंशन हैं जो आधुनिक ग्राफिक्स वातावरण के लिए आवश्यक कार्यक्षमता प्रदान करते हैं। आप कह सकते हैं कि क्लासिक एक्स विंडो सिस्टम डिकोडिशनड कचरा है।

हम वायलैंड में ड्राइव करते हैं। वेलैंड X विंडो सिस्टम को बदलने के लिए हमारे द्वारा बनाए गए बुनियादी ढांचे की एक बड़ी मात्रा का पुन: उपयोग कर रहा है। वायलैंड वास्तुकला के बारे में एकमात्र विवादास्पद बात नेटवर्क और प्रतिपादन प्रोटोकॉल की अस्पष्टता है। दूसरी ओर, हमारे समय में, नेटवर्क प्रोटोकॉल का जबरदस्त लचीलापन अनावश्यक हो रहा है, क्योंकि एक्स की कार्यक्षमता का शेर का हिस्सा पहले से ही अन्य सेवाओं में बिखरा हुआ है - उदाहरण के लिए, डीबीस। वास्तव में, यह एक्स विंडो सिस्टम आर्किटेक्चर में उन हैक्स को देखने के लिए शर्म की बात है जो क्लिपबोर्ड या ड्रैग एंड ड्रॉप जैसी चीजों में बने हैं, केवल एक्स के नेटवर्क इतिहास के साथ संगतता के लिए समर्थन करते हैं।

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

हालाँकि, वायलैंड के पास प्रोटोकॉल को लागू करने के लिए एक संदर्भ पुस्तकालय है और यह दृढ़ता से अनुशंसा की जाती है कि इसका उपयोग क्लाइंट और कंपोज़र दोनों के लिए किया जाए, कुछ भी किसी को भी वायलैंड के लिए पूरे संगीतकार को पायथन में लिखने से रोकता है। या रूबी में। और प्रोटोकॉल को शुद्ध Python में लागू करें, बिना libwayland का उपयोग किए।

वायलैंड क्लाइंट संगीतकार के साथ संवाद करते हैं और एक बफर का अनुरोध करते हैं। संगीतकार एक बफर देता है, जिसमें वे कैरो का उपयोग कर सकते हैं, कम से कम ओपनजीएल का उपयोग करके, कम से कम अपने दम पर। संगीतकार तब खुद तय करता है कि इस बफ़र का क्या करना है - बस इसे दिखाएं, आवेदन की दृढ़ता के कारण इसे प्राथमिकता दें, या इसे um को घुमाएं ... क्यूब पर क्योंकि हम YouTube पर एक नया वीडियो डालना चाहते हैं जिसमें लिनक्स विंडो क्यूब पर घूम रही है। खैर, आपको बात समझ में आ गई।

इसके अलावा, इनपुट और इवेंट प्रोसेसिंग के लिए संगीतकार जिम्मेदार है। यदि आपने ग्नोम शेल के लिए जीजेएस कोड का एक टुकड़ा चलाने की कोशिश की, तो आप शायद इस सवाल से हैरान थे - "माउस अनट्रॉन्ड विंडो के साथ क्यों काम करता है"? लेकिन क्योंकि हमने खिड़की के प्रदर्शन पर काम किया था, और X11 के अंदर खिड़की पर ही नहीं। एक्स सर्वर अपने आप खिड़कियों की निगरानी करता है और उम्मीद करता है कि खिड़कियों का कंपोजिशन मैनेजर उसी के अनुसार उन्हें प्रदर्शित करता है। यदि ऐसा नहीं है, तो आपको हैरान होना पड़ेगा, जैसा कि ऊपर के मामले में है।

चूंकि वेलैंड के संगीतकार एवदेव के साथ काम करते हैं और घटनाओं को खिड़कियों तक भेजते हैं, वह ज्यादा बेहतर तरीके से जानता है कि खिड़कियां कहां हैं, वे कैसे प्रदर्शित होती हैं और स्वतंत्र रूप से सभी आवश्यक परिवर्तनों को पूरा कर सकती हैं। इसलिए, ऐसे संगीतकार के साथ काम करते हुए, हम न केवल क्यूब पर खिड़कियों को घुमा सकते हैं, बल्कि उनके साथ सीधे क्यूब पर भी काम कर सकते हैं ।

निष्कर्ष

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

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

इस तथ्य के बावजूद कि मैं संक्षेप में लिनक्स ग्राफिक्स स्टैक की मुख्य चीजों के माध्यम से भागा, आप हमेशा गहरी खुदाई कर सकते हैं यदि आप रुचि रखते हैं। उदाहरण के लिए, आप ज्यामितीय एल्गोरिदम और सिद्धांतों के बारे में पढ़ सकते हैं जो कैरो प्राइमेटिव के विभाजन को चतुष्कोणों में विभाजित करते हैं। या हो सकता है कि आपको इन चतुर्भुजों के तेजी से सॉफ्टवेयर रेखांकन के लिए एल्गोरिथ्म पर एक नज़र डालनी चाहिए और इसकी उच्च गति के कारणों को समझना चाहिए। DRI2 में खुदाई का प्रयास करें। क्या होगा यदि आप स्वयं हार्डवेयर में रुचि रखते हैं और यह कैसे खींचता है, और आप डेटशीट का पता लगा लेंगे और इसे स्वयं प्रोग्राम करने का प्रयास करेंगे? किसी भी मामले में, यदि आप इनमें से किसी भी क्षेत्र में देरी करने का निर्णय लेते हैं, तो ऊपर सूचीबद्ध समुदाय और परियोजनाएं आपको अपने इनपुट के साथ स्वीकार करने में प्रसन्न होंगी।

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

प्रूफरीडिंग के लिए रूज़ो , ट्रॉल्सिड और एक्सआईटीएस के हब उपयोगकर्ताओं के लिए धन्यवाद।