Servo: इमर्सिव मोड 60fps तक नहीं पहुंचता

कुछ जानकारी जो उजागर हुई है:

• xrWaitFrame और xrBeginFrame के बीच लंबा इंतजार है
  
  
  
  • डेमो ऐप में ये क्रमिक रूप से होते हैं
  
  
  • सर्वो के मॉडल में, हम एक डिवाइस फ्रेम की प्रतीक्षा करते हैं , फिर एक बार जब हम वेबग्ल थ्रेड से रेंडर प्राप्त कर लेते हैं तो हम
  
  

ओपनएक्सआर एपीआई के लिए मार्करों के साथ पेंट डेमो का एक निशान इन दिनों पुन: पेश करता है, और उस अवधि के दौरान भी दिखाता है:

• वेबजीएल थ्रेड सबसे अधिक सीपीयू का उपयोग करता है (उस समय का एक बड़ा हिस्सा gl::Finish के तहत खर्च किया जाता है, जिसे सर्फमैन के डिवाइस से कहा जाता है::bind_surface_to_context)
• मुख्य धागा दूसरा सबसे व्यस्त है, जिसमें उच्चतम उपयोग eglCreatePbufferFromClientBuffer में खर्च किया गया है और लगभग उतना ही समय TLS से Egl ऑब्जेक्ट को हथियाने में बिताया गया है
  
  
  
  • इस स्टैक में वेबरेंडर का प्रतिपादन भी दिखाई देता है
  
  
  • winrt::servo::flush यहां भी दिखाई देता है, और यह मेरे लिए स्पष्ट नहीं है कि क्या हमें वास्तव में मुख्य एप्लिकेशन के GL बफ़र्स को स्वैप करने की आवश्यकता है, जबकि हम इमर्सिव मोड में हैं
  
  
• तीसरा उच्चतम CPU उपयोग स्क्रिप्ट थ्रेड है, जो JIT कोड के अंदर बहुत समय व्यतीत करता है
• उस थ्रेड के बाद सीपीयू का उपयोग आम तौर पर बहुत कम होता है, लेकिन स्टाइल क्रेट से कुछ प्रतीक दिखाई दे रहे हैं जो दर्शाता है कि लेआउट हो रहा है

उन डेटा बिंदुओं को देखते हुए, मैं शुरू करने के लिए दो दृष्टिकोण आज़माने जा रहा हूँ:

• डिवाइस फ्रेम की प्रतीक्षा करने के बाद जितनी जल्दी हो सके अगला एक्सआर फ्रेम शुरू करें
• gl::Finish (webgl thread), eglCreateBufferFromClientBuffer और TLS (मुख्य थ्रेड) को कॉल करने की संख्या कम करें

https://github.com/servo/servo/pull/25343#issuecomment -567706735 में इंजन में विभिन्न स्थानों पर संदेश भेजने के प्रभाव की अधिक जांच है। यह किसी भी स्पष्ट उंगलियों को इंगित नहीं करता है, लेकिन सुझाव देता है कि अधिक सटीक माप लिया जाना चाहिए।

Gl::Finish उपयोग https://github.com/pcwalton/surfman/blob/6705a9aaa8f33ac1324fdb1913242800e68c7720/surfman/src/platform/windows/angle/context.rs#L259 -L266 से आता है।

Gl::Finish to gl::Flush बदलना ~15->30 से फ्रैमरेट को बढ़ा देता है, लेकिन फ्रेम सामग्री में एक अत्यंत ध्यान देने योग्य अंतराल है जो वास्तव में उपयोगकर्ता के सिर की गति को दर्शाता है, जिससे वर्तमान फ्रेम उपयोगकर्ता के सिर का अनुसरण करता है। इसी बीच।

कुंजी वाले म्यूटेक्स डिफ़ॉल्ट रूप से ANGLE में उन कारणों से अक्षम हैं जो मुझे दूर करते हैं, लेकिन mozangle स्पष्ट रूप से उन्हें सक्षम करता है (https://github.com/servo/mozangle/blob/706a9baaf8026c1a3cb6c67ba63aa5f4734264d0/build_data.rs#L175), और यही सर्फमैन के साथ परीक्षण किया जाता है . मैं ANGLE का निर्माण करने जा रहा हूं जो उन्हें सक्षम बनाता है और देखता है कि यह gl::फिनिश कॉल से बचने के लिए पर्याप्त है या नहीं।

की पुष्टि! ANGLE में जबरन बंद म्यूटेक्स मुझे पेंट डेमो में 25-30 FPS देता है बिना किसी अंतराल के मुद्दों के जो gl::Finish कॉल को बदलने के साथ आया था।

ओह, और लार्स की जांच के अनुसार एक और जानकारी:

• w/ dom.ion.enabled गलत पर सेट है, JIT समय गायब हो जाता है। प्रारंभिक भार बहुत धीमे होते हैं, लेकिन एक बार चीजें चलने के बाद वे बहुत अच्छे होते हैं।
  
  
  
  • यह अभी भी शानदार नहीं है - उस babylon.js उदाहरण पर मेमोरी का उपयोग काफी अधिक है (मूल रूप से सभी उपलब्ध मेमोरी)
  
  
  • हमें android उपकरणों पर FxR के लिए हो रहे arm64-संबंधित अनुकूलन में खींचने के लिए एक और स्पाइडरमोनकी अपग्रेड करना चाहिए
  
  

मुझे लगता है कि मैंने प्रोफाइल में std::thread::local::LocalKey<surfman::egll::Egl> की उपस्थिति को गलत समझा - मुझे पूरा यकीन है कि टीएलएस पढ़ा गया समय का केवल एक बहुत छोटा हिस्सा है, और यह टीएलएस ब्लॉक के अंदर बुलाया गया कार्य है जैसे eglCreatePbufferFromClientBuffer और DXGIAcquireSync कि _वास्तव में_ समय लगता है।

अफसोस की बात है कि js.ion.enabled को अक्षम करने से पेंट डेमो के FPS को नुकसान होता है, जो इसे 20-25 तक ले जाता है।

डिवाइस को कॉल करने के बजाय: create_surface_texture_from_texture प्रत्येक फ्रेम में दो बार (प्रत्येक आंख के लिए प्रत्येक d3d बनावट के लिए एक बार), जब openxr webxr डिवाइस बनाया जाता है, तो सभी स्वैपचेन बनावट के लिए सतह बनावट बनाना संभव हो सकता है। यदि यह काम करता है, तो यह इमर्सिव मोड के दौरान सीपीयू के दूसरे सबसे बड़े उपयोगकर्ता को मुख्य थ्रेड से हटा देगा।

स्मृति उपयोग को कम करने के लिए एक और विचार: यदि हम bfcache को बहुत कम संख्या पर सेट करते हैं तो क्या कोई प्रभाव पड़ता है ताकि किसी एक डेमो पर नेविगेट करते समय मूल HL होमपेज पाइपलाइन बेदखल हो जाए?

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

diff --git a/webxr/openxr/mod.rs b/webxr/openxr/mod.rs
index 91c78da..a6866de 100644
--- a/webxr/openxr/mod.rs
+++ b/webxr/openxr/mod.rs
@@ -416,11 +416,30 @@ impl DeviceAPI<Surface> for OpenXrDevice {
     }

     fn wait_for_animation_frame(&mut self) -> Option<Frame> {
-        if !self.handle_openxr_events() {
-            // Session is not running anymore.
-            return None;
+        loop {
+            if !self.handle_openxr_events() {
+                // Session is not running anymore.
+                return None;
+            }
+            self.frame_state = self.frame_waiter.wait().expect("error waiting for frame");
+
+            // XXXManishearth this code should perhaps be in wait_for_animation_frame,
+            // but we then get errors that wait_image was called without a release_image()
+            self.frame_stream
+                .begin()
+                .expect("failed to start frame stream");
+                
+            if self.frame_state.should_render {
+                break;
+            }
+            
+            self.frame_stream.end(
+                self.frame_state.predicted_display_time,
+                EnvironmentBlendMode::ADDITIVE,
+                &[],
+            ).unwrap();
         }
-        self.frame_state = self.frame_waiter.wait().expect("error waiting for frame");
+
         let time_ns = time::precise_time_ns();
         // XXXManishearth should we check frame_state.should_render?
         let (_view_flags, views) = self
@@ -506,12 +525,6 @@ impl DeviceAPI<Surface> for OpenXrDevice {
             0,
         );

-        // XXXManishearth this code should perhaps be in wait_for_animation_frame,
-        // but we then get errors that wait_image was called without a release_image()
-        self.frame_stream
-            .begin()
-            .expect("failed to start frame stream");
-
         self.left_image = self.left_swapchain.acquire_image().unwrap();
         self.left_swapchain
             .wait_image(openxr::Duration::INFINITE)

@manishearth इस पर कोई विचार? यह मेरा प्रयास है कि मैं https://www.khronos.org/registry/OpenXR/specs/1.0/html/xrspec.html#Session द्वारा वर्णित मॉडल के करीब

हाँ, यह अच्छा लग रहा है। मेरा मतलब begin() को waf में ऊपर ले जाने के लिए है, और मेरा मानना ​​है कि टिप्पणी में उल्लिखित त्रुटि अब नहीं होती है, लेकिन इसका FPS पर भी ध्यान देने योग्य प्रभाव नहीं पड़ता है इसलिए मैंने इसका पीछा नहीं किया अभी के लिए बहुत ज्यादा। अगर यह स्थिरता में सुधार करता है तो अच्छा है!

महत्वपूर्ण खोज के बारे में वास्तव में खुश! सर्फमैन कॉल वास्तव में फ्रेम बजट का एक गुच्छा लेती है लेकिन यह निर्धारित करना थोड़ा कठिन है कि क्या आवश्यक है और क्या नहीं।

हां, पुन: अक्षम करना js.ion.enabled , यह केवल एक लाभ होने जा रहा है जब हम रैम भूखे हैं और अपना अधिकांश समय जीसी'इंग और कार्यों को पुन: संकलित करने में खर्च कर रहे हैं। और इसमें एक नए एसएम के साथ सुधार किया जाना चाहिए। IIRC, 66-युग के ARM64 बैकएंड में भी अपेक्षाकृत खराब बेसलाइन JIT और दुभाषिया प्रदर्शन था; हमें अपडेट के साथ बोर्ड भर में स्पीडअप देखना चाहिए, लेकिन विशेष रूप से रैम-गहन अनुप्रयोगों पर।

कुंजी वाले म्यूटेक्स के साथ नया एंगल पैकेज प्रकाशित किया गया। मैं इसे बाद में अपग्रेड करने के लिए एक पुल अनुरोध बनाऊंगा।

मैंने एक्सआर डिवाइस इनिशियलाइज़ेशन के दौरान सभी ओपनएक्सआर स्वैपचैन छवियों के लिए सतह बनावट बनाने की कोशिश की, लेकिन सतह पर eglCreatePbufferFromClientBuffer को कॉल करने में खर्च किए गए मुख्य थ्रेड पर अभी भी समय का एक गुच्छा है जो हमें प्रत्येक फ्रेम में वेबग्ल थ्रेड से प्राप्त होता है। हो सकता है कि उन सतह बनावट को कैश करने का कोई तरीका हो ताकि यदि हम वही सतह प्राप्त करते हैं तो हम उनका पुन: उपयोग कर सकते हैं ...

सबसे बड़ा मुख्य थ्रेड CPU उपयोग render_animation_frame से आता है, जिसमें से अधिकांश OpenXR रनटाइम के अंतर्गत आता है, लेकिन BlitFramebuffer और FramebufferTexture2D को कॉल निश्चित रूप से प्रोफ़ाइल में भी दिखाई देता है। मुझे आश्चर्य है कि क्या एक ही बनावट में दोनों आंखों को एक साथ फहराने में सुधार होगा? हो सकता है कि यह https://github.com/microsoft/OpenXR-SDK-VisualStudio/#render -with-texture-array-and-vprt में चर्चा की गई बनावट सरणी सामग्री से संबंधित है।

हम दोनों आँखें एक साथ फूँक सकते हैं, हालाँकि मेरी समझ यह है कि रनटाइम
तब अपना दोष स्वयं कर सकता है। बनावट सरणी सबसे तेज़ तरीका है। लेकिन
एक शॉट के लायक, प्रोजेक्शन व्यू एपीआई ऐसा करने का समर्थन करता है।

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

सोम, 6 जनवरी, 2020, 11:49 अपराह्न को जोश मैथ्यूज नोटिफिकेशन @github.com
लिखा था:

सबसे बड़ा मुख्य थ्रेड CPU उपयोग render_animation_frame से आता है, के साथ
उनमें से अधिकांश ओपनएक्सआर रनटाइम के तहत लेकिन ब्लिटफ्रेमबफर को कॉल करता है और
FramebufferTexture2D निश्चित रूप से प्रोफ़ाइल में भी दिखाई दे रहा है। मैं सोचता हूं
अगर एक ही बार में दोनों आँखों को फँसाना एक सुधार होगा
बनावट? हो सकता है कि यह चर्चा की गई बनावट सरणी सामग्री से संबंधित हो
में
https://github.com/microsoft/OpenXR-SDK-VisualStudio/#render -with-texture-array-and-vprt
.

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/servo/servo/issues/25425?email_source=notifications&email_token=AAMK6SBRH72JGZMXTUKOXETQ4NY37A5CNFSM4KCRI6AKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJ0204P मुद्दा
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AAMK6SECM6MDNZZ6Y7VL7SDQ4NY37ANCNFSM4KCRI6AA
.

कैनवास को गंदा करने से केवल प्रोफ़ाइल साफ होती है; यह एक सार्थक एफपीएस वृद्धि की ओर नहीं ले गया।

मैंने वेबग्ल थ्रेड के साथ-साथ ओपनएक्सआर स्वैपचेन बनावट से सतहों के लिए सतह बनावट का कैश बनाने की कोशिश की, और जबकि eglCreatePbufferFromClientBuffer समय पूरी तरह से गायब हो गया, मुझे कोई सार्थक एफपीएस परिवर्तन दिखाई नहीं दिया।

इमर्सिव पाइपलाइन में विभिन्न कार्यों के लिए कुछ समय की जानकारी (एमएस में सभी माप):

Name            min             max             avg
raf queued      0.070833        14.010261       0.576834
<1ms: 393
<2ms: 28
<4ms: 5
<8ms: 1
<16ms: 2
<32ms: 0
32+ms: 0

raf transmitted 0.404270        33.649583       7.403302
<1ms: 123
<2ms: 43
<4ms: 48
<8ms: 48
<16ms: 95
<32ms: 69
32+ms: 3

raf wait        1.203500        191.064100      17.513593
<1ms: 0
<2ms: 17
<4ms: 98
<8ms: 95
<16ms: 48
<32ms: 69
32+ms: 101

raf execute     3.375000        128.663200      6.994588
<1ms: 0
<2ms: 0
<4ms: 5
<8ms: 351
<16ms: 70
<32ms: 1
32+ms: 2

raf receive     0.111510        8.564010        0.783503
<1ms: 353
<2ms: 52
<4ms: 18
<8ms: 4
<16ms: 1
<32ms: 0
32+ms: 0

raf render      2.372200        75.944000       4.219310
<1ms: 0
<2ms: 0
<4ms: 253
<8ms: 167
<16ms: 8
<32ms: 0
32+ms: 1

receive : एक्सआर फ्रेम से आईपीसी राउटर द्वारा प्राप्त होने के लिए एक्सआर थ्रेड से भेजी जा रही जानकारी का समय
queued : IPC राउटर से फ्रेम की जानकारी प्राप्त करने का समय XRSession::raf_callback लागू होने तक
execute : XRSession से समय :: raf_callback विधि से लौटने तक लागू किया गया
transmitted : स्क्रिप्ट थ्रेड से नए rAF के लिए अनुरोध भेजने से लेकर XR थ्रेड तक प्राप्त होने तक का समय
render : render_animation_frame पर कॉल करने और सतह को रीसायकल करने में लगने वाला समय
wait : wait_for_animation_frame द्वारा लिया गया समय (इस अंक में पहले से पैच का उपयोग करके जो फ्रेम पर लूप करता है जिसे प्रस्तुत नहीं करना चाहिए)

प्रत्येक प्रविष्टि के अंतर्गत सत्र के दौरान मूल्यों का वितरण होता है।

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

पिछले डेटा को देखते हुए, मैं कल https://github.com/servo/webxr/issues/113 को पुनर्जीवित करने का प्रयास कर सकता हूं, यह देखने के लिए कि क्या यह संचार समय को सकारात्मक रूप से प्रभावित करता है। मैं यह देखने के लिए पहले प्रोफाइलर में मुख्य धागे पर प्रहार कर सकता हूं कि क्या मुझे इस बारे में कोई विचार आ सकता है कि यह कैसे बताया जाए कि धागा अन्य कार्यों में व्यस्त है या सो रहा है।

एक अन्य डेटा बिंदु:

swap buffer     1.105938        28.193698       2.154793
<1ms: 0
<2ms: 273
<4ms: 110
<8ms: 15
<16ms: 2
<32ms: 2
32+ms: 0

swap complete   0.053802        4.337812        0.295064
<1ms: 308
<2ms: 9
<4ms: 6
<8ms: 1
<16ms: 0
<32ms: 0
32+ms: 0

swap request    0.003333        24033027.355364 4662890.724805
<1ms: 268
<2ms: 49
<4ms: 5
<8ms: 0
<16ms: 0
<32ms: 1
32+ms: 79

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

कुछ openxr नमूना कोड के माध्यम से पढ़ने के बाद #117 दायर किया और यह देखते हुए कि प्रोफ़ाइल में लोकेट_व्यू कॉल दिखाई देते हैं।

संभवतः https://github.com/servo/webxr/issues/117

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

transmitted मान में बदलाव फिर से करें, यह run_one_frame हिस्से के रूप में उपयोग किए जाने वाले टाइमआउट में जुड़ सकता है जब सत्र मुख्य-थ्रेड पर चल रहा हो (जो यह उन मापों में है, है ना?) , देखें https://github.com/servo/webxr/blob/c6abf4c60d165ffc978ad2ebd6bcddc3c21698e1/webxr-api/session.rs#L275

मुझे लगता है कि जब RenderAnimationFrame संदेश (कॉलबैक चलाने के बाद स्क्रिप्ट-थ्रेड द्वारा भेजा गया) टाइमआउट से पहले प्राप्त होता है, तो आप "फास्ट पाथ" हिट करते हैं, और यदि टाइमआउट छूट जाता है तो सर्वो दूसरे में चला जाता है perform_updates का पुनरावृत्ति, और "एक और फ्रेम चलाना" चक्र में काफी देर से होता है, compositor.perform_updates हिस्से के रूप में, जिसे servo.handle_events हिस्से के रूप में काफी देर से कहा जाता है।

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

मैंने https://github.com/servo/webxr/issues/113 में मुख्य थ्रेड से openxr प्राप्त करने पर प्रगति की है, इसलिए मैं अगले सप्ताह उस कार्य के आधार पर और माप लेने जा रहा हूं।

डिवाइस से उपयोगी प्रोफाइल प्राप्त करने की तकनीक:

• एक .servobuild का उपयोग करें जिसमें rustflags = "-C force-frame-pointers=yes"
• इन पंक्तियों पर टिप्पणी न करें
• MS टीमों से WinXR_Perf.wprp का उपयोग HL डिवाइस पोर्टल में "प्रदर्शन ट्रेसिंग" के अंतर्गत कस्टम ट्रेसिंग प्रोफ़ाइल के रूप में Files टैब के रूप में करें
• --features profilemozjs साथ निर्माण करें

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

किसी विशेष ओपनएक्सआर फ्रेम के समय वितरण को प्रोफाइल करने के लिए:

• WPA में "सिस्टम गतिविधि -> सामान्य ईवेंट" दृश्य जोड़ें
• केवल Microsoft.Windows.WinXrContinuousProvider श्रृंखला दिखाने के लिए दृश्य को फ़िल्टर करें
• एक छोटी अवधि के लिए ज़ूम इन करें, फिर ज़ूम इन क्षेत्र को परिशोधित करें ताकि एक xrBegin ईवेंट दृश्य के बाईं ओर हो, और एक xrEnd ईवेंट दृश्य के दाईं ओर हो

CPU उपयोग के लिए सबसे उपयोगी विचार:

• CPU उपयोग (नमूना) -> प्रक्रिया, थ्रेड, स्टैक द्वारा उपयोग (केवल सर्वो दिखाने के लिए दृश्य को फ़िल्टर करें, फिर प्रक्रिया कॉलम को अक्षम करें)
• प्रक्रिया द्वारा लौ, ढेर (केवल सर्वो दिखाने के लिए दृश्य को फ़िल्टर करें)

स्क्रिप्ट थ्रेड में थोड़ा कम काम करने की एक संभावना:

• XRView::new सभी सर्वो CPU का 0.02% खपत करता है
• चूंकि दृश्य वस्तुओं की सामग्री तब तक नहीं बदलती है जब तक कि कोई FrameUpdateEvent::UpdateViews ईवेंट (जो सत्र::update_clip_planes से XRSession::UpdateRenderState के माध्यम से आता है) न हो, हम XRSession पर XRView ऑब्जेक्ट्स को कैश कर सकते हैं और उनका उपयोग तब तक जारी रख सकते हैं जब तक रेंडर स्टेट अपडेट किया गया है
• हम XRSession में कैश की गई दृश्य सूची के JS प्रतिनिधित्व को भी रख सकते हैं और पोज़ के दृश्य सदस्य को सेट कर सकते हैं, XRView ऑब्जेक्ट्स को फिर से बनाने और वेक्टर को आवंटित करने और JS वैल्यू रूपांतरण करने से बचते हैं।

इमर्सिव फ्रेम प्रदान करते समय कम काम करने की एक संभावना:

• GL और d3d में उल्टे Y निर्देशांक प्रणालियाँ हैं
• परदे के पीछे कुछ काम करके स्क्रीन पर प्रस्तुत करते समय ANGLE इसे स्पष्ट रूप से छुपाता है
• इमर्सिव मोड के लिए, हम GL टेक्सचर डेटा को d3d पर ब्लिट करते समय y-इनवर्जन करने के लिए glBlitFramebuffer का उपयोग करते हैं
• अगर हम यह पता लगा सकते हैं कि ANGLE को आंतरिक रूप से रूपांतरण नहीं करने के लिए कैसे बनाया जाए, तो इस मॉडल को उल्टा करना संभव हो सकता है और गैर-इमर्सिव वेब पेजों को रेंडर करने के लिए अतिरिक्त y-invert ब्लिट की आवश्यकता होती है (वेबरेन्डर विकल्प surface_origin_is_top_left ) जबकि इमर्सिव मोड को बिना किसी ट्रांसफॉर्मेशन के ब्लिट किया जा सकता है

https://bugzilla.mozilla.org/show_bug.cgi?id=1591346 पर आधारित और jrmuizel के साथ बात करते हुए, हमें यह करना होगा:

• उस विंडो तत्व के लिए एक d3d स्वैपचैन प्राप्त करें जिसमें हम गैर-इमर्सिव पृष्ठों को प्रस्तुत करना चाहते हैं (यह XAML ऐप में SwapChainPanel होगा)
• इसे एक ईजीएल छवि में लपेटें (https://searchfox.org/mozilla-central/rev/c52d5f8025b5c9b2b4487159419ac9012762c40c/gfx/webrender_bindings/RenderCompositorANGLE.cpp#554)
• जब हम मुख्य रेंडरिंग को अपडेट करना चाहते हैं तो स्पष्ट रूप से स्वैपचैन प्रस्तुत करें
• https://github.com/servo/servo/blob/master/support/hololens/ServoApp/ServoControl/OpenGLES.cpp#L205 -L208 में eglCreateWindowSurface और eglSwapBuffers का उपयोग करने से बचें

प्रासंगिक छिपकली कोड: https://searchfox.org/mozilla-central/rev/c52d5f8025b5c9b2b4487159419ac9012762c40c/gfx/webrender_bindings/RenderCompositorANGLE.cpp#192
प्रासंगिक कोण कोड: https://github.com/google/angle/blob/df0203a9ae7a285d885d7bc5c2d4754fe8a59c72/src/libANGLE/renderer/d3d/d3d11/winrt/SwapChainPanelNativeWindow.cpp#L244

वर्तमान वाइप शाखाएं:

• https://github.com/servo/ipc-channel/tree/try-recv-error
• https://github.com/jdm/webxr/tree/oxr
• https://github.com/jdm/rust-offscreen-rendering-context/tree/angle-perf
• https://github.com/jdm/servo/tree/profile

इसमें एक xr-profile सुविधा शामिल है जो मेरे द्वारा पहले बताए गए समय डेटा को जोड़ती है, साथ ही इमर्सिव मोड में y-उलटा परिवर्तन को हटाने के लिए ANGLE परिवर्तनों का प्रारंभिक कार्यान्वयन। नॉन-इमर्सिव मोड सही ढंग से रेंडर कर रहा है, लेकिन इमर्सिव मोड उल्टा है। मेरा मानना ​​​​है कि मुझे जीएल कोड को रेंडर_एनीमेशन_फ्रेम से निकालने की जरूरत है और जीएल सतह से शेयर हैंडल निकालने के द्वारा इसे सीधे कॉपीसबर्ससोर्स रीजन कॉल से बदलना होगा ताकि मैं इसकी डी 3 डी बनावट प्राप्त कर सकूं।

एंगल वाई-इनवर्जन कार्य के लिए https://github.com/servo/servo/issues/25582 फाइल किया गया; उस कार्य के बारे में और अद्यतन उस अंक में होंगे।

अगला बड़ा टिकट आइटम openxr webxr बैकएंड में पूरी तरह से glBlitFramebuffer कॉल से बचने के तरीकों की जांच करेगा। यह आवश्यक है:

• ओपनएक्सआर फ्रेमबफ़र्स बनाना जो आवश्यक अपारदर्शी वेबग्ल फ्रेमबफ़र्स से सटीक रूप से मेल खाते हों
• एक वेबग्ल मोड का समर्थन करना जहां वेबएक्सआर बैकएंड उन्हें बनाने के बजाय सभी स्वैपचेन सतह प्रदान करता है (उदाहरण के लिए https://github.com/asajeffrey/surfman-chains/blob/27a7ab8fec73f19f0c4252ff7ab52e84609e1fa5/surfman-chains/lib.rs#L458 में। और https://github.com/asajeffrey/surfman-chains/blob/27a7ab8fec73f19f0c4252ff7ab52e84609e1fa5/surfman-chains/lib.rs#L111-L118)

यह मुश्किल हो सकता है, क्योंकि सर्फमैन केवल उस संदर्भ तक लेखन पहुंच प्रदान करता है जिसने सतह बनाई है, इसलिए यदि सतह ओपनएक्सआर थ्रेड द्वारा बनाई गई है, तो यह वेबजीएल थ्रेड द्वारा लिखने योग्य नहीं होगा। https://github.com/pcwalton/surfman/blob/a515fb2f5d6b9e9b36ba4e8b498cdb4bea92d330/surfman/src/device.rs#L95 -L96

यह मेरे साथ होता है - अगर हमने वेबग्ल थ्रेड में ओपनएक्सआर रेंडरिंग किया है, तो ओपनएक्सआर के टेक्सचर को सीधे रेंडर करने के आसपास थ्रेडिंग से संबंधित मुद्दों का एक गुच्छा अब कोई समस्या नहीं होगी (यानी। विचार करना:

• अभी भी एक ओपनएक्सआर थ्रेड है जो ओपनएक्सआर घटनाओं के लिए मतदान के लिए जिम्मेदार है, एक एनीमेशन फ्रेम की प्रतीक्षा कर रहा है, एक नया फ्रेम शुरू कर रहा है और वर्तमान फ्रेम स्थिति को पुनः प्राप्त कर रहा है
• फ़्रेम स्थिति को स्क्रिप्ट थ्रेड में भेजा जाता है, जो एनीमेशन कॉलबैक करता है और फिर xr परत के फ़्रेमबफ़र को स्वैप करने के लिए वेबग्ल थ्रेड को एक संदेश भेजता है
• जब यह स्वैप संदेश वेबग्ल थ्रेड में प्राप्त होता है, तो हम अंतिम अधिग्रहीत ओपनएक्सआर स्वैपचैन छवि जारी करते हैं, वर्तमान फ्रेम को समाप्त करने के लिए ओपनएक्सआर थ्रेड को एक संदेश भेजते हैं, और अगले फ्रेम के लिए एक नई स्वैपचैन छवि प्राप्त करते हैं

https://www.khronos.org/registry/OpenXR/specs/1.0/html/xrspec.html#threading -behavior को पढ़ने से पता चलता है कि यह डिज़ाइन व्यावहारिक हो सकता है। चाल यह है कि क्या यह हमारे गैर-ओपनएक्सआर बैकएंड के साथ-साथ ओपनएक्सआर के लिए भी काम कर सकता है।

कल्पना से: "जबकि xrBeginFrame और xrEndFrame को एक ही थ्रेड पर कॉल करने की आवश्यकता नहीं है, एप्लिकेशन को सिंक्रनाइज़ेशन को संभालना चाहिए यदि उन्हें अलग-अलग थ्रेड पर बुलाया जाता है।"

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

पहले के समय के माप के बारे में बातचीत के नोट्स:

* concerns about wait time - why?????
* figure out time spent in JS vs. DOM logic
* when does openxr give us should render=false frames - maybe related to previous frame taking too long
* are threads being scheduled on inappropriate cpus? - on magic leap, main thread (including weber) pinned to big core.
* when one of the measured numbers is large, is there correlation with other large numbers?
* probably should pin openxr thread, running deterministic code
* consider clearing after telling script that the swap is complete - measure if clear is taking significant time in swap operation
* consider a swap chain API operation - “wait until a buffer swap occurs”
  - block waiting on swapchain
  - block waiting on swapchain + timeout
  - async????????
- a gc would look like a spike in script execution time

उन जांचों को ट्रैक करने के लिए #25735 फ़ाइल की गई जिन्हें मैं सीधे openxr बनावट में प्रस्तुत करने के बारे में कर रहा हूं।

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

कुछ नया डेटा। यह एंगल अपग्रेड के साथ है, लेकिन आईपीसी वाला नहीं है।

$ python timing.py raw
Name        min     max     mean
raf queued  0.056198    5.673125    0.694902
<1ms: 335
<2ms: 26
<4ms: 17
<8ms: 7
<16ms: 0
<32ms: 0
32+ms: 0

raf transmitted 0.822917    36.582083   7.658619
<1ms: 1
<2ms: 4
<4ms: 31
<8ms: 181
<16ms: 158
<32ms: 8
32+ms: 1

raf wait    1.196615    39.707709   10.256875
<1ms: 0
<2ms: 32
<4ms: 93
<8ms: 67
<16ms: 107
<32ms: 68
32+ms: 17

raf execute 3.078438    532.205677  7.752839
<1ms: 0
<2ms: 0
<4ms: 37
<8ms: 290
<16ms: 52
<32ms: 2
32+ms: 3

raf receive 0.084375    9.053125    1.024403
<1ms: 276
<2ms: 71
<4ms: 27
<8ms: 9
<16ms: 1
<32ms: 0
32+ms: 0

swap request    0.004115    73.939479   0.611254
<1ms: 369
<2ms: 10
<4ms: 5
<8ms: 0
<16ms: 0
<32ms: 0
32+ms: 2

raf render  5.706198    233.459636  9.241698
<1ms: 0
<2ms: 0
<4ms: 0
<8ms: 183
<16ms: 190
<32ms: 10
32+ms: 1

run_one_frame   7.663333    2631.052969 28.035143
<1ms: 0
<2ms: 0
<4ms: 0
<8ms: 3
<16ms: 157
<32ms: 185
32+ms: 41

swap buffer 0.611927    8.521302    1.580279
<1ms: 127
<2ms: 169
<4ms: 74
<8ms: 15
<16ms: 1
<32ms: 0
32+ms: 0

swap complete   0.046511    2.446302    0.215040
<1ms: 375
<2ms: 6
<4ms: 3
<8ms: 0
<16ms: 0
<32ms: 0
32+ms: 0

समय डेटा: https://gist.github.com/Manishearth/825799a98bf4dca0d9a7e55058574736

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

ध्यान देने योग्य दिलचस्प बातें:

• समय प्रस्तुत करना और निष्पादित करने का समय ज्यादातर स्थिर लगता है, लेकिन जब कुल मिलाकर बड़े स्पाइक्स होते हैं तो स्पाइक्स होते हैं। मुझे संदेह है कि बड़े स्पाइक्स किसी भी कारण से धीमा होने वाली हर चीज से आते हैं
• संचारण समय समग्र आकार के साथ बहुत अच्छी तरह से सहसंबद्ध लगता है
• प्रतीक्षा समय भी कारण का हिस्सा है समग्र आकार ऐसा है, यह _very_ लहरदार . है

वर्तमान स्थिति: IPC सुधारों के साथ, FPS अब 55 के आसपास मँडरा रहा है। यह कभी-कभी एक गुच्छा को हिलाता है, लेकिन आमतौर पर 45 से नीचे नहीं जाता है, _except_ लोड के बाद पहले कुछ सेकंड के दौरान (जहाँ यह 30 तक नीचे जा सकता है), और जब यह पहले एक हाथ देखता है (जब यह नीचे 20 हो जाता है)।

पेंट डेमो के लिए नया हिस्टोग्राम ( कच्चा डेटा ):

Name        min     max     mean
raf queued  0.113854    5.707917    0.441650
<1ms: 352
<2ms: 13
<4ms: 5
<8ms: 1
<16ms: 0
<32ms: 0
32+ms: 0

raf transmitted 0.546667    44.954792   6.886162
<1ms: 4
<2ms: 2
<4ms: 23
<8ms: 279
<16ms: 59
<32ms: 3
32+ms: 1

raf wait    1.611667    37.913177   9.441104
<1ms: 0
<2ms: 6
<4ms: 98
<8ms: 82
<16ms: 135
<32ms: 43
32+ms: 6

raf execute 3.336562    418.198541  7.592147
<1ms: 0
<2ms: 0
<4ms: 11
<8ms: 319
<16ms: 36
<32ms: 2
32+ms: 3

raf receive 0.119323    9.804167    0.806074
<1ms: 324
<2ms: 31
<4ms: 13
<8ms: 1
<16ms: 1
<32ms: 0
32+ms: 0

swap request    0.003646    79.236354   0.761324
<1ms: 357
<2ms: 9
<4ms: 2
<8ms: 0
<16ms: 0
<32ms: 0
32+ms: 3

raf render  5.844687    172.898906  8.131682
<1ms: 0
<2ms: 0
<4ms: 0
<8ms: 283
<16ms: 86
<32ms: 1
32+ms: 1

run_one_frame   8.826198    2577.357604 25.922205
<1ms: 0
<2ms: 0
<4ms: 0
<8ms: 0
<16ms: 176
<32ms: 174
32+ms: 22

swap buffer 0.708177    12.528906   1.415950
<1ms: 164
<2ms: 161
<4ms: 38
<8ms: 4
<16ms: 4
<32ms: 0
32+ms: 0

swap complete   0.042917    1.554740    0.127729
<1ms: 370
<2ms: 1
<4ms: 0
<8ms: 0
<16ms: 0
<32ms: 0
32+ms: 0

रेखांकन:

लंबी दौड़:

छोटा रन:

बड़ा स्पाइक तब होता है जब मैं अपना हाथ सेंसर रेंज में रखता हूं।

इस बार मैंने प्रतीक्षा/run_one_frame बार को ऊपर रखा क्योंकि वे सबसे अधिक दांतेदार हैं, और ऐसा इसलिए है क्योंकि ओएस हमें थ्रॉटलिंग कर रहा है।

ध्यान देने योग्य बातें:

• पेश किए जा रहे हाथों से बड़ा स्पाइक जेएस कोड (तुलसी हरा, "राफ रेंडर") के कारण होता है
• उम्मीद के मुताबिक ट्रांसमिशन का समय आसान हो गया है
• जब मैं ड्राइंग शुरू करता हूं तो एक और जेएस स्पाइक होता है
• रेंडर और ट्रांसमिशन का समय अभी भी बजट का महत्वपूर्ण हिस्सा है। स्क्रिप्ट के प्रदर्शन में भी सुधार किया जा सकता है।
  
  
  
  • मुझे संदेह है कि मुख्य धागा अन्य चीजों को करने में व्यस्त होने के कारण ट्रांसमिशन का समय इतना लंबा लगता है। यह https://github.com/servo/webxr/issues/113 है , @jdm इसे देख रहा है
  
  
  • सर्फमैन अपडेट से रेंडर समय में सुधार हो सकता है। सर्फमैनअप पर @asajeffrey का मापन मेरे से बेहतर लगता है
  
  
  • सतह साझा करने से रेंडर समय में सुधार हो सकता है (सर्फमैनअप पर अवरुद्ध)
  
  
• एक्सआर-प्रोफाइल से मापते समय डिवाइस द्वारा दिखाया गया एफपीएस लगभग आधा हो जाता है। यह सभी IO के कारण हो सकता है।

बॉलशूटर के लिए हाथ देखने और फिर ड्रॉ शुरू करने के कारण प्रदर्शन में कमी आती है। शायद पेंट डेमो बहुत काम कर रहा है जब वह पहली बार हाथ की छवि बनाने का फैसला करता है?

(यह वेबएक्सआर इनपुट लाइब्रेरी के साथ इंटरैक्ट करने का प्रयास करने वाला पेंट डेमो भी हो सकता है)

@ मनीषार्थ क्या आप स्मृति उपयोग को भी ओवरले कर सकते हैं और उन घटनाओं से सहसंबंधित कर सकते हैं? जेएस कोड पहली बार संकलन के अलावा, आप एक टन नए कोड में गलती कर सकते हैं और भौतिक स्मृति सीमाओं के खिलाफ चल रहे हैं और जीसी का एक गुच्छा खर्च कर रहे हैं क्योंकि आप स्मृति दबाव दबाते हैं। मैं इसे ज्यादातर गैर-तुच्छ स्थितियों में देख रहा था। मुझे उम्मीद है कि @nox का SM अपडेट मदद करेगा, क्योंकि यह निश्चित रूप से एक आर्टिफैक्ट था जिसे हमने FxR Android पर इस SM बिल्ड में देखा था।

मेरे पास मेमोरी प्रोफाइलिंग डेटा प्राप्त करने का एक आसान तरीका नहीं है जिसे एक्सआर-प्रोफाइलिंग सामग्री से सहसंबंधित किया जा सकता है।

मैं संभावित रूप से मौजूदा perf टूल का उपयोग कर सकता हूं और यह पता लगा सकता हूं कि आकार समान है या नहीं।

@ मनीषार्थ क्या एक्सआर-प्रोफाइलिंग सामान जेएस जीसी घटनाओं को दिखाता है (या यह दिखा सकता है)? यह एक उचित प्रॉक्सी हो सकता है।

किसी भी तरह, स्टार्टअप स्पाइक्स मेरी प्राथमिक चिंता नहीं है, मैं पहले सब कुछ _else_ 60fps पर प्राप्त करना चाहता हूं। यदि यह स्टार्टअप पर एक या दो सेकंड के लिए जानदार है तो यह कम दबाव वाली चिंता है।

हां, यह दिखा सकता है कि, कुछ बदलावों की आवश्यकता होगी।

@Manishearth प्राथमिकताओं पर पूरी तरह सहमत! मुझे यकीन नहीं था कि आप "किंक को अनकंक" करने की कोशिश कर रहे थे या स्थिर स्थिति में ड्राइव कर रहे थे। बाद में अभी और अधिक महत्वपूर्ण सहमत हैं।

नहीं, मैं ज्यादातर उन सभी विश्लेषणों को नोट कर रहा था जो मैं कर सकता था।

छोटे रन के ग्राफ के अंत के पास वे स्पाइक्स जहां ट्रांसमिशन का समय भी बढ़ता है: यही वह समय था जब मैं अपना सिर और ड्राइंग ले रहा था, और एलन चीजें करते समय एफपीएस में बूंदों को भी देख रहा था, और ओएस को अन्य काम करने के लिए जिम्मेदार ठहराया . IPC द्वारा ट्रांसमिशन टाइम स्पाइक्स पर मेरे कूबड़ को ठीक करने के बाद, वे OS द्वारा अन्य काम करने के कारण होते हैं, इसलिए हो सकता है कि वहां क्या हो रहा हो। एक ऑफ-मेन-थ्रेड दुनिया में मुझे उम्मीद है कि यह बहुत आसान होगा।

अगर इस पर पहले से ही विचार किया गया था, तो मुझे अनदेखा करें, क्या आपने run_one_frame के माप को प्रति-संदेश-संभालने के आधार पर तोड़ने के बारे में सोचा है, और साथ ही thread::sleep() -ing खर्च किए गए समय को भी विभाजित करने के बारे में सोचा है?

यह तीन माप बिंदुओं को जोड़ने लायक हो सकता है:

1. एक रैपिंग https://github.com/servo/webxr/blob/68b024221b8c72b5b33a63441d63803a13eadf03/webxr-api/session.rs#L364

2. और दूसरा रैपिंग https://github.com/servo/webxr/blob/2841497966d87bbd561f18ea66547dde9b13962f/webxr-api/lib.rs#L124 समग्र रूप से,

3. और कॉल को केवल thread::sleep रैप करने वाला भी।

जहां तक recv_timeout , यह पूरी तरह से पुनर्विचार करने के लिए कुछ हो सकता है।

मुझे टाइमआउट की उपयोगिता के बारे में तर्क करना कुछ कठिन लगता है। चूंकि आप रेंडर किए गए फ्रेम की गणना कर रहे हैं, frame_count , यूज़केस "शायद एक या कई संदेश को हैंडल करता है जो फ्रेम को रेंडर नहीं कर रहे हैं, पहले, एक फ्रेम को रेंडर करने के बाद, आगे बढ़ने से बचते हुए मुख्य-धागे का पूरा इवेंट-लूप"?

इसके अलावा, मुझे इसमें प्रयुक्त delay की वास्तविक गणना के बारे में कुछ संदेह हैं, जहां वर्तमान में:

1. यह delay = timeout / 1000 से शुरू होता है, timeout साथ वर्तमान में 5 एमएस . सेट किया जा रहा है
2. यह तब तेजी से बढ़ता है, प्रत्येक पुनरावृत्ति पर delay = delay * 2; पर दोगुना हो जाता है
3. यह लूप के शीर्ष पर while delay < timeout साथ चेक किया गया है।

तो सबसे खराब स्थिति में नींद का क्रम कुछ इस प्रकार है: 5micro -> 10 -> 20 -> 40 -> 80 -> 160 -> 320 -> 640 -> 1.28milli -> 2.56 मिली -> 5.12 मिली

जब यह 5.12 मिलीसेकंड हिट करता है, तो आप लूप से बाहर हो जाएंगे ( delay > timeout ), कुल 5,115 मिली सेकंड प्रतीक्षा करने के बाद, साथ ही प्रत्येक sleep बाद थ्रेड को जगाने के लिए OS पर प्रतीक्षा करने में जो भी अतिरिक्त समय बिताया गया है

तो मुझे लगता है कि समस्या यह है कि आप कुल मिलाकर 5ms से अधिक सो रहे हैं, और मुझे यह भी लगता है कि एक संदेश के बाद से 1 ms से अधिक (और दूसरी बार 2.5 ms से अधिक) के लिए दो बार सोना एक अच्छा विचार नहीं है। उस दौरान अंदर आ सकते हैं और आप नहीं उठेंगे।

मुझे पूरा यकीन नहीं है कि इसे कैसे सुधारें, ऐसा लगता है कि आप एक संभावित संदेश के लिए स्पिन करने की कोशिश कर रहे हैं, और अंत में मुख्य ईवेंट-लूप के अगले पुनरावृत्ति पर आगे बढ़ें यदि कुछ भी उपलब्ध नहीं है (क्यों ब्लॉक नहीं करें आरईवी?)

आप https://doc.rust-lang.org/std/thread/fn.yield_now.html का उपयोग करने के लिए स्विच कर सकते हैं, इस आलेख को ताले पर देखकर, यह हर बार yield कॉल करते समय लगभग 40 बार कताई लगता है , इष्टतम है ("स्पिनिंग" पैराग्राफ देखें, इससे सीधे लिंक नहीं हो सकता)। उसके बाद आपको या तो रिसीवर पर ब्लॉक करना चाहिए, या केवल इवेंट-लूप के वर्तमान पुनरावृत्ति के साथ जारी रखना चाहिए (चूंकि यह मुख्य एम्बेडिंग इवेंट-लूप के अंदर सब-लूप की तरह चल रहा है)।

(जाहिर है, अगर आप के साथ मापने नहीं कर रहे हैं ipc पर ऊपर ओर से कर दिया, recv_timeout , अप्रासंगिक है, हालांकि आप अभी भी करने के लिए CALLL को मापने के लिए चाहते हो सकता है recv_timeout पर mpsc चूंकि थ्रेडेड चैनल कुछ आंतरिक कताई/उपज करेगा जो परिणामों को भी प्रभावित कर सकता है। और चूंकि उपरोक्त कई अवसरों पर एक अज्ञात "आईपीसी फिक्स" का उल्लेख किया गया है, मुझे लगता है कि आप आईपीसी के साथ माप रहे हैं)।

मुझे अनदेखा करें यदि इसे पहले से ही माना गया था, क्या आपने प्रति-संदेश-संभाल के आधार पर run_one_frame के माप को तोड़ने के बारे में सोचा है, और समय व्यतीत करने वाले थ्रेड :: स्लीप () - आईएनजी को भी समय दिया है?

यह पहले ही टूट चुका है, प्रतीक्षा/रेंडर समय ठीक यही है। Run_one_frame की एक एकल टिक एक रेंडर, एक प्रतीक्षा, और घटनाओं की एक अनिश्चित संख्या को संभाला जा रहा है (दुर्लभ)।

recv_timeout माप के लिए एक अच्छा विचार है

अफसोस की बात है कि #25678 में स्पाइडरमोनकी अपग्रेड एक महत्वपूर्ण सुधार नहीं दिखता है - सीमित मेमोरी को छोड़कर हर डेमो का औसत एफपीएस कम हो गया है; हिल वैली डेमो थोड़ा ऊपर चला गया। आरंभीकरण तर्कों में -Z gc-profile साथ सर्वो चलाना मास्टर और स्पाइडरमोनकी अपग्रेड शाखा के बीच जीसी व्यवहार में कोई अंतर नहीं दिखाता है - जीएल सामग्री लोड और प्रदर्शित होने के बाद कोई जीसी रिपोर्ट नहीं की जाती है।

विभिन्न शाखाओं के लिए माप:

master:
- espilit: 14-16 fps
- paint: 39-45 fps
- ball shooter: 30-40 fps
- hill valley: 8 fps, 200mb free mem
- mansion: 10-14fps, 650mb free mem

master + single swapchain:
- espilit: 10-12 fps
- paint: 29-55 fps, 1.2gb free mem
- ball shooter: 25-35 fps, 1.3gb free mem
- hill valley: 6-7 fps, 200mb free mem
- mansion: 10-11 fps, 700mb free mem

texture sharing + ANGLE 2.1.19:
- espilit: 13-15 fps, 670mb free mem
- paint: 39-45 fps
- ball shooter: 30-37 fps, 1.3gb free mem
- hill valley: 9-10 fps, 188mb free mem
- mansion: 13-14 fps, 671mb free mem

smup:
- espilit: 11-13 fps, 730mb free mem
- paint: 25-42 fps, 1.1gb free mem
- ball shooter: 26-30 fps, 1.4gb free mem
- hill valley: 10-11 fps, 145mb
- mansion: 9-11fps, 680mb free mem

स्मप ने प्रदर्शन को और खराब कर दिया ???

https://github.com/servo/servo/pull/25855#issuecomment -594203492 से परिवर्तनों के साथ, दिलचस्प परिणाम यह है कि आयन जेआईटी को अक्षम करना 12 एफपीएस पर शुरू होता है, और फिर कई सेकंड बाद यह अचानक 1 एफपीएस तक टैंक हो जाता है और वहाँ रहता है।

उन पैच के साथ कुछ माप किया।

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

ड्रैगिंग डेमो के लिए मेरे पास यही है। वाई-स्केल समान है। यहाँ यह बहुत अधिक स्पष्ट है कि निष्पादन समय हमें धीमा कर रहा है।

ध्यान देने वाली एक बात यह है कि मैं #25837 के साथ माप ले रहा था, और यह प्रदर्शन को प्रभावित कर सकता है।

मैं नहीं था, हालांकि मुझे आपके समान परिणाम मिल रहे थे

सामग्री को देखते समय उस क्षण के लिए प्रदर्शन टूल ग्राफ़ जहां यह 60FPS से 45FPS तक जाता है:

ऐसा लगता है कि दोष पूरी तरह से xrWaitFrame पर है, अन्य सभी समय एक साथ काफी करीब हैं। xrBeginFrame अभी भी लगभग xrWaitFrame के तुरंत बाद है, xrEndFrame xrBeginFrame (दोनों मामलों में) के बाद 4us है। अगला xrWaitFrame xrEndFrame के लगभग तुरंत बाद है। अंतर के लिए केवल बेहिसाब xrWaitFrame के कारण होता है।

ड्रैगिंग डेमो के साथ, मुझे निम्न ट्रेस मिलता है:

यह उसी पैमाने के साथ पेंट डेमो है:

हम प्रारंभ/समाप्ति फ़्रेम के बीच धीमे हैं (सबसे तेज़ पर 5ms से 38ms तक!), और फिर प्रतीक्षा फ़्रेम थ्रॉटलिंग शुरू हो जाती है। मैंने अभी तक यह नहीं बताया है कि ऐसा क्यों है, मैं इसके लिए कोड के माध्यम से जा रहा हूँ दोनों।

ड्रैगिंग डेमो धीमा हो गया है क्योंकि इसका प्रकाश स्रोत छाया डालता है। छाया सामग्री जीएल पक्ष पर की जाती है, इसलिए मुझे यकीन नहीं है कि क्या हम इसे आसानी से गति दे सकते हैं?

यदि यह पूरी तरह से GLSL के माध्यम से किया जाता है तो हमें कठिनाइयाँ हो सकती हैं; यदि यह वेबजीएल एपीआई के माध्यम से हर फ्रेम में किया जाता है तो अनुकूलित करने के लिए स्थान हो सकते हैं।

हाँ ऐसा लगता है कि सभी जीएलएसएल की तरफ हैं; जब यह आता है कि छाया एपीआई कैसे काम करता है, तो मुझे कोई वेबजीएल कॉल नहीं दिखाई दे रही थी, बस कुछ बिट्स जो शेडर्स को पास हो जाते हैं

मेरा मानना ​​है कि इसे सामान्य रूप से संबोधित किया गया है। हम उन व्यक्तिगत डेमो के लिए समस्याएँ दर्ज कर सकते हैं जिन्हें कार्य की आवश्यकता है।