एंड्रॉइड वीएसवाईएनसी सिग्नल की आवश्यकता को समझना

Question

मैं एंड्रॉइड डिस्प्ले उपप्रणाली की बेहतर समझ प्राप्त करने की कोशिश कर रहा हूं, लेकिन एक आइटम जो अभी भी मुझे भ्रमित कर रहा है यह है कि वीएसवाईएनसी संकेतों को कैसे संभाला जाता है, और क्यों पहले स्थान पर मौजूद हैं।

एंड्रॉइड को इसके मूल पर वीएसवाईएनसी का उपयोग करने के लिए डिज़ाइन किया गया है, लेकिन इसमें कई वीएसवाईएनसी सिग्नल हैं जो इसे नियोजित करते हैं। "वीएसवाईएनसी ऑफ़सेट" खंड में https://source.android.com/devices/graphics/implement.html के माध्यम से, एक प्रवाह आरेख है जो तीन वीएसवाईएनसी संकेतों को चित्रित करता है: HW_VSYNC_0, VSYNC, और SF-VSYNC। मैं समझता हूं कि HW_VSYNC का उपयोग DispSync में समय को अद्यतन करने के लिए किया जाता है, और यह कि VSYNC और SF-VSYNC ऐप्स और सतहफ्लिंगर द्वारा उपयोग किया जाता है, लेकिन इन व्यक्तिगत संकेतों को बिल्कुल क्यों जरूरी है? इसके अलावा, ऑफ़सेट इन संकेतों को कैसे प्रभावित करते हैं? क्या कोई समय आरेख उपलब्ध है जो बेहतर तरीके से बताता है?

आपकी सहायता के लिए धन्यवाद।

Answer 1

इस चीज को समझने के लिए यह System-Level Graphics Architecture दस्तावेज़ के साथ शुरू करने के लिए, ट्रिपल-बफरिंग अनुभाग और संबद्ध आरेख (जो आदर्श एक एनिमेटेड GIF होगा) की आवश्यकता की विशेष नोट लेने के लिए सबसे अच्छा है। वाक्य जो शुरू होता है, "यदि ऐप VSYNC संकेतों के बीच आधा रास्ते प्रस्तुत करना शुरू करता है" विशेष रूप से DispSync के बारे में बात कर रहा है। एक बार जब आप इसे पढ़ लेंगे, तो उम्मीद है कि डिवाइस ग्राफिक्स दस्तावेज़ का DispSync अनुभाग अधिक समझ में आता है।

अधिकांश डिवाइसों में DispSync ऑफ़सेट कॉन्फ़िगर नहीं है, इसलिए वास्तव में केवल एक VSYNC संकेत है। निम्नानुसार मैं मान रहा हूं कि DispSync सक्षम है।

हार्डवेयर केवल प्राथमिक प्रदर्शन रीफ्रेश के अनुरूप एक VSYNC सिग्नल प्रदान करता है। अन्य लोग SurfaceFlinger DispSync कोड द्वारा सॉफ़्टवेयर में जेनरेट किए जाते हैं, वास्तविक VSYNC से निश्चित ऑफ़सेट पर फायरिंग करते हैं। कुछ चालाक सॉफ़्टवेयर का प्रयोग समय से बाहर निकलने से रोकने के लिए किया जाता है।

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

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

क्या DispSync के लिए है यही कारण है कि। आपके द्वारा लिंक किए गए पृष्ठ पर फीडबैक आरेख में, HW_VSYNC_0 भौतिक प्रदर्शन के लिए हार्डवेयर रीफ्रेश है, VSYNC ऐप को प्रस्तुत करने का कारण बनता है, और SF_VSYNC सतहफ्लिंगर को संरचना करने का कारण बनता है। उन्हें "वीएसवाईएनसी" के रूप में संदर्भित करना एक गलत नाम है, लेकिन एक एलसीडी पैनल पर "वीएसवाईएनसी" के रूप में कुछ भी संदर्भित करना संभवतः एक गलत नाम है।

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

संपादित करें: आप देख सकते हैं कि Nexus 5 boardconfig में मान कैसे कॉन्फ़िगर किए गए हैं। VSYNC_EVENT_PHASE_OFFSET_NS और SF_VSYNC_EVENT_PHASE_OFFSET_NS के लिए सेटिंग्स नोट करें।