Servo: 몰입 모드가 60fps에 도달하지 않음

밝혀진 몇 가지 정보:

• xrWaitFrame과 xrBeginFrame 사이에 긴 대기 시간이 있습니다.
  
  
  
  • 데모 앱 에서는 순차적으로 발생합니다.
  
  
  • Servo의 모델에서 우리 는 장치 프레임을 기다린 다음 webgl 스레드에서 렌더링을 받으면
  
  

OpenXR API용 마커가 있는 페인트 데모 의 흔적은 요즘 재현되며 그 기간 동안에도 표시됩니다.

• webgl 스레드는 가장 많은 CPU를 사용합니다(그 시간의 대부분은 gl::Finish에서 사용되며 이는 surfman의 Device::bind_surface_to_context에서 호출됨)
• 주 스레드는 두 번째로 많이 사용되며 eglCreatePbufferFromClientBuffer에서 사용량이 가장 많고 TLS에서 Egl 객체를 가져오는 데 거의 같은 시간이 소요됩니다.
  
  
  
  • webrender의 렌더링도 이 스택에 나타납니다.
  
  
  • winrt::servo::flush가 여기에도 나타나며 몰입 모드에 있는 동안 주 응용 프로그램의 GL 버퍼를 실제로 교체해야 하는지 여부가 명확하지 않습니다.
  
  
• 세 번째로 높은 CPU 사용량은 JIT 코드 내에서 많은 시간을 보내는 스크립트 스레드입니다.
• 그 스레드 후 CPU 사용량은 일반적으로 꽤 낮지만 레이아웃이 발생하고 있음을 나타내는 스타일 상자의 일부 기호가 표시됩니다.

이러한 데이터 포인트가 주어지면 시작하기 위해 두 가지 접근 방식을 시도할 것입니다.

• 장치 프레임을 기다린 후 가능한 빨리 다음 XR 프레임을 시작하십시오.
• gl::Finish(webgl 스레드), 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를 gl::Flush로 변경하면 프레임 속도가 ~15->30으로 향상되지만 실제로 사용자의 머리 움직임을 반영하는 프레임 내용에 매우 눈에 띄는 지연이 있어 현재 프레임이 사용자의 머리를 따라갑니다. 그동안.

키가 있는 뮤텍스는 ANGLE에서 기본적으로 비활성화되어 있지만, mozangle은 명시적으로 활성화합니다(https://github.com/servo/mozangle/blob/706a9baaf8026c1a3cb6c67ba63aa5f4734264d0/build_data.rs#L175로 테스트). . 나는 그것들을 가능하게 하는 ANGLE 빌드를 만들 것이고 그것이 gl::Finish 호출을 피하기에 충분한지 확인할 것입니다.

확인했습니다! ANGLE에서 키 지정 뮤텍스를 강제 실행하면 gl::Finish 호출을 변경할 때 발생하는 지연 문제 없이 페인트 데모에서 25-30FPS를 얻을 수 있습니다.

아, 그리고 라스의 조사에 따른 또 다른 정보:

• w/ dom.ion.enabled가 false로 설정되면 JIT 시간이 사라집니다. 초기 로드는 훨씬 느리지만 일단 실행되면 꽤 좋습니다.
  
  
  
  • 여전히 환상적이지는 않습니다. 해당 babylon.js 예제에서 메모리 사용량이 상당히 높습니다(기본적으로 사용 가능한 모든 메모리).
  
  
  • 안드로이드 기기에서 FxR에 대해 발생했던 arm64 관련 최적화를 가져오기 위해 또 다른 스파이더몽키 업그레이드를 수행해야 합니다.
  
  

프로필에 std::thread::local::LocalKey<surfman::egll::Egl> 가 있다는 것을 잘못 이해한 것 같습니다. TLS 읽기는 이에 부과된 시간의 아주 작은 부분일 뿐이며 eglCreatePbufferFromClientBuffer와 같은 TLS 블록 내부에서 호출되는 함수입니다. DXGIAcquireSync는 _실제로_ 시간이 걸립니다.

슬프게도 js.ion.enabled를 비활성화하면 페인트 데모의 FPS가 손상되어 20-25로 줄어듭니다.

매 프레임마다 Device::create_surface_texture_from_texture를 두 번(각 눈의 각 d3d 텍스처에 대해 한 번씩) 호출하는 대신 openxr webxr 장치가 생성될 때 모든 스왑체인 텍스처에 대한 표면 텍스처를 생성하는 것이 가능할 수 있습니다. 이것이 작동하면 몰입 모드 동안 메인 스레드에서 두 번째로 큰 CPU 사용자를 제거합니다.

메모리 사용량을 줄이기 위한 또 다른 아이디어: bfcache를 매우 낮은 숫자로 설정하여 데모 중 하나로 이동할 때 원래 HL 홈페이지 파이프라인이 제거되는 경우 영향이 있습니까?

다음 webxr 패치는 FPS를 명확하게 향상시키지는 않지만 이미지 안정성을 향상시킬 수 있습니다. 확인하기 위해 연속적으로 실행할 수 있는 두 개의 개별 빌드를 만들어야 합니다.

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에도 눈에 띄는 영향을 미치지 않아 추구하지 않았습니다. 지금은 너무 많이. 안정성만 높인다면 굿!

핵심 발견에 대해 정말 기쁩니다! Surfman 호출은 실제로 많은 프레임 예산을 차지하지만 무엇이 필요하고 무엇이 필요하지 않은지 결정하기가 약간 어렵습니다.

예, 다시: js.ion.enabled 비활성화하면 RAM이 부족하고 스래싱이 대부분의 시간을 GC'하고 기능을 다시 컴파일하는 데 보낼 때만 이점이 있습니다. 그리고 그것은 새로운 SM으로 개선되어야 합니다. IIRC, 66-시대 ARM64 백엔드 또한 상대적으로 낮은 기준 JIT 및 인터프리터 성능을 보였습니다. 업데이트를 통해 전반적으로 속도가 향상되지만 특히 RAM 집약적인 애플리케이션에서 속도가 향상되는 것을 볼 수 있습니다.

키 지정 뮤텍스가 활성화된 새 ANGLE 패키지를 게시했습니다. 나중에 업그레이드하기 위해 풀 리퀘스트를 생성하겠습니다.

XR 장치 초기화 중에 모든 openxr 스왑체인 이미지에 대한 표면 텍스처를 생성하려고 시도했지만 각 프레임마다 webgl 스레드에서 수신하는 표면에서 eglCreatePbufferFromClientBuffer를 호출하는 데 메인 스레드에 많은 시간이 소요되었습니다. 같은 표면을 받으면 다시 사용할 수 있도록 해당 표면 텍스처를 캐시하는 방법이 있을 수 있습니다.

가장 큰 메인 스레드 CPU 사용량은 render_animation_frame에서 발생하며 대부분은 OpenXR 런타임에서 발생하지만 BlitFramebuffer 및 FramebufferTexture2D에 대한 호출은 프로필에도 분명히 나타납니다. 두 눈을 한 번에 하나의 텍스처로 블렛하는 것이 개선이 될지 궁금합니다. https://github.com/microsoft/OpenXR-SDK-VisualStudio/#render -with-texture-array-and-vprt에서 논의된 텍스처 배열과 관련이 있을 수 있습니다.

우리는 한 번에 두 눈을 블리딩할 수 있지만 내 이해는 런타임이
그런 다음 자체 blit을 수행할 수 있습니다. 텍스처 배열이 가장 빠른 방법입니다. 하지만
가치가 있는 프로젝션 뷰 API는 이 작업을 지원합니다.

메인 스레드 ANGLE 트래픽은 RAF 루프를 중지합니다.
캔버스 도움말을 더럽히나요? 지금까지 이것은 아무 것도 하지 않았지만 가치가 있습니다.
샷, 이상적으로는 메인에서 레이아웃/렌더링을 해서는 안 됩니다.
실.

2020년 1월 6일 월요일 오후 11:49 Josh Matthews [email protected]
썼다:

가장 큰 메인 스레드 CPU 사용량은 render_animation_frame에서 옵니다.
대부분은 OpenXR 런타임에 있지만 BlitFramebuffer 및
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=AAMK6SBRH72JGZMXTUKOXETQ4NY37A5CNFSM4KCRI6AKYY20EGOZODNVHJODNVHJJ3TUL52HSLODFVEXG43VMVBW63LN
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AAMK6SECM6MDNZZ6Y7VL7SDQ4NY37ANCNFSM4KCRI6AA
.

더러워진 캔버스를 제거하면 프로필만 정리됩니다. 의미있는 FPS 증가로 이어지지 않은 것으로 보입니다.

webgl 스레드와 openxr swapchain 텍스처에서 표면에 대한 표면 텍스처 캐시를 생성하려고 시도했으며 eglCreatePbufferFromClientBuffer 시간이 완전히 사라지는 동안 의미 있는 FPS 변경을 눈치채지 못했습니다.

몰입형 파이프라인의 다양한 작업에 대한 몇 가지 타이밍 정보(모든 측정은 ms 단위):

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 : XR 스레드에서 전송된 XR 프레임 정보부터 IPC 라우터가 수신하기까지의 시간
queued : 프레임 정보를 수신한 IPC 라우터로부터 XRSession::raf_callback이 호출될 때까지의 시간
execute : XRSession::raf_callback이 호출된 후 메서드에서 반환될 때까지의 시간
transmitted : 스크립트 스레드에서 새 rAF에 대한 요청을 보낸 후 XR 스레드가 수신할 때까지의 시간
render : render_animation_frame 을 호출하고 표면을 재활용하는 데 걸리는 시간
wait : wait_for_animation_frame 소요 시간(이 문제의 앞부분에서 렌더링해서는 안 되는 프레임을 반복하는 패치 사용)

각 항목 아래에는 세션이 진행되는 동안 값의 분포가 있습니다.

해당 타이밍 정보의 흥미로운 데이터 포인트 - transmitted 범주는 예상보다 훨씬 높은 것 같습니다. 이는 rAF 콜백 실행과 XR 스레드가 완료된 프레임을 Openxr의 텍스처로 분할하는 메시지를 수신하는 사이의 지연입니다. 메인 쓰레드가 다른 일을 하고 있거나 그것을 처리하기 위해 깨어나야 한다는 것을 암시하는 약간의 변형이 있습니다.

이전 데이터가 주어지면 내일 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) webgl 스레드에서 처리될 때까지 스왑 버퍼 메시지를 보내는 데 걸리는 지연, 2) 버퍼를 스왑하는 데 걸리는 시간, 3) 스와핑이 완료되었음을 나타내는 메시지를 보낼 때까지 받은 지연과 관련된 타이밍입니다. 스크립트 스레드. 여기서 놀라운 것은 없지만( swap request 범주의 이상한 이상값을 제외하고는 설정이 진행되는 동안 몰입형 세션의 맨 처음에 발생함) 실제 버퍼 스와핑은 일관되게 1-4ms가 걸립니다.

일부 openxr 샘플 코드를 읽고 Locate_views 호출이 프로필에 표시되는 것을 확인한 후 출원 #117.

아마도 https://github.com/servo/webxr/issues/117

해당 타이밍 정보의 흥미로운 데이터 포인트 - 전송된 범주가 예상보다 훨씬 높은 것 같습니다. 이는 rAF 콜백 실행과 XR 스레드가 완료된 프레임을 Openxr의 텍스처로 분할하는 메시지를 수신하는 사이의 지연입니다. 메인 쓰레드가 다른 일을 하고 있거나 그것을 처리하기 위해 깨어나야 한다는 것을 암시하는 약간의 변형이 있습니다.

transmitted 값의 변형을 다시 살펴보면 세션이 메인 스레드에서 실행될 때 run_one_frame 일부로 사용되는 시간 초과에 연결될 수 있습니다(이 측정값에 해당합니까?) , https://github.com/servo/webxr/blob/c6abf4c60d165ffc978ad2ebd6bcddc3c21698e1/webxr-api/session.rs#L275 참조

RenderAnimationFrame msg(콜백을 실행한 후 스크립트 스레드가 보낸 메시지)가 타임아웃 전에 수신되면 "빠른 경로"를 치고 타임아웃을 놓치면 서보가 다른 perform_updates 반복 및 "다른 프레임 실행"은 compositor.perform_updates 일부로 주기에서 상당히 늦게 발생하며 자체적으로 servo.handle_events 일부로 상당히 늦게 호출됩니다.

XR을 자체 스레드로 이동하는 것 외에는 시간 초과 값이 높을수록 평균 값이 향상되는지 확인하는 것이 좋습니다.

https://github.com/servo/webxr/issues/113 의 메인 스레드에서 openxr을 제거하는 과정을 진행했으므로 다음 주에 해당 작업을 기반으로 더 많은 측정을 수행할 것입니다.

장치에서 유용한 프로필을 가져오는 기술:

• rustflags = "-C force-frame-pointers=yes" 가 포함된 .servobuild 사용
• 이 줄의 주석을 제거하십시오
• MS 팀 char Files 탭의 WinXR_Perf.wprp를 HL 장치 포털의 "성능 추적"에서 사용자 정의 추적 프로필로 사용
• --features profilemozjs 빌드

이러한 추적(장치 포털의 "추적 시작"에서 가져옴)은 Windows 성능 분석기 도구 내에서 사용할 수 있습니다. 이 도구는 스레드 이름을 표시하지 않지만 가장 많은 CPU를 사용하는 스레드는 스택을 기반으로 간단하게 식별할 수 있습니다.

특정 openxr 프레임의 시간 분포를 프로파일링하려면:

• WPA에서 "시스템 활동 -> 일반 이벤트" 보기 추가
• Microsoft.Windows.WinXrContinuousProvider 시리즈만 표시하도록 보기를 필터링합니다.
• 짧은 기간으로 확대한 다음 xrBegin 이벤트가 보기의 왼쪽에 있고 xrEnd 이벤트가 보기의 오른쪽에 있도록 확대된 영역을 수정합니다.

CPU 사용량에 대한 가장 유용한 보기:

• CPU 사용량(샘플) -> 프로세스, 스레드, 스택별 활용(서보만 표시하도록 보기를 필터링한 다음 프로세스 열 비활성화)
• 프로세스별 화염, 스택(서보만 표시하도록 보기 필터링)

스크립트 스레드에서 약간 더 적은 작업을 수행할 수 있는 한 가지 가능성:

• XRView::new는 모든 서보 CPU의 0.02%를 소비합니다.
• FrameUpdateEvent::UpdateViews 이벤트(XRSession::UpdateRenderState를 통해 Session::update_clip_planes에서 발생)가 발생하지 않는 한 뷰 개체의 내용이 변경되지 않으므로 XRSession에 XRView 개체를 캐시하고 다음 때까지 계속 사용할 수 있습니다. 렌더링 상태가 업데이트됨
• XRSession에 캐시된 보기 목록의 JS 표현을 유지하고 포즈의 보기 멤버를 설정하여 XRView 개체를 다시 만들고 벡터를 할당하고 JS 값 변환을 수행하는 것을 모두 피할 수도 있습니다.

몰입형 프레임을 렌더링할 때 더 적은 작업을 수행할 수 있는 한 가지 가능성:

• GL 및 d3d에는 반전된 Y 좌표계가 있습니다.
• ANGLE은 배후에서 일부 작업을 수행하여 화면에 표시할 때 이를 암시적으로 숨깁니다.
• 몰입 모드의 경우 GL 텍스처 데이터를 d3d로 blitting할 때 y-inversion을 수행하기 위해 glBlitFramebuffer를 사용합니다.
• ANGLE이 내부적으로 변환을 수행하지 않도록 하는 방법을 알아낼 수 있다면 이 모델을 반전하고 비몰입 웹 페이지를 렌더링할 때 추가 y-invert blit이 필요하도록 할 수 있습니다(webrender 옵션 surface_origin_is_top_left ). 몰입형 모드는 변형 없이 파괴될 수 있습니다.

https://bugzilla.mozilla.org/show_bug.cgi?id=1591346 및 jrmuizel과의 대화를 기반으로 우리가 해야 할 일은 다음과 같습니다.

• 비몰입형 페이지를 렌더링하려는 창 요소에 대한 d3d 스왑체인을 가져옵니다(XAML 앱의 SwapChainPanel이 됨).
• EGL 이미지로 래핑하십시오(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/SwapChainPanel#NativeWindow.cpp

현재 wip 분기:

• 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 변경의 초기 구현이 포함됩니다. 비몰입 모드는 올바르게 렌더링되지만 몰입 모드는 거꾸로 되어 있습니다. d3d 텍스처를 얻을 수 있도록 GL 표면에서 공유 핸들을 추출하여 render_animation_frame에서 GL 코드를 제거하고 직접 CopySubresourceRegion 호출로 교체해야 한다고 생각합니다.

ANGLE y-inversion 작업을 위해 https://github.com/servo/servo/issues/25582 에 제출했습니다. 해당 작업에 대한 추가 업데이트는 해당 문제에서 이루어집니다.

다음 큰 티켓 항목은 openxr webxr 백엔드에서 glBlitFramebuffer 호출을 완전히 피하는 방법을 조사하는 것입니다. 이를 위해서는 다음이 필요합니다.

• 필요한 불투명 webgl 프레임 버퍼와 정확하게 일치하는 openxr 프레임 버퍼 생성
• webxr 백엔드가 모든 swapchain 표면을 생성하는 대신 제공하는 webgl 모드 지원(예: https://github.com/asajeffrey/surfman-chains/blob/27a7ab8fec73f19f0c4252ff7ab52e84609e1fa5/surfman-chains458rs 및 https://github.com/asajeffrey/surfman-chains/blob/27a7ab8fec73f19f0c4252ff7ab52e84609e1fa5/surfman-chains/lib.rs#L111-L118)

그것은 어려울 수 있습니다. surfman은 표면을 생성한 컨텍스트에 대한 쓰기 액세스 권한만 제공하므로 표면이 openxr 스레드에 의해 생성된 경우 WebGL 스레드에서 쓸 수 없을 것입니다. https://github.com/pcwalton/surfman/blob/a515fb2f5d6b9e9b36ba4e8b498cdb4bea92d330/surfman/src/device.rs#L95 -L96

저에게 발생합니다. webgl 스레드에서 openxr 렌더링을 수행했다면 openxr의 텍스처에 직접 렌더링하는 것과 관련된 여러 스레딩 관련 문제가 더 이상 문제가 되지 않을 것입니다(예: 여러 d3d 장치 사용을 금지하는 eglCreatePbufferFromClientBuffer 관련 제한 사항). 고려하다:

• 여전히 openxr 이벤트 폴링, 애니메이션 프레임 대기, 새 프레임 시작 및 현재 프레임 상태 검색을 담당하는 openxr 스레드가 있습니다.
• 프레임 상태는 애니메이션 콜백을 수행한 다음 xr 레이어의 프레임 버퍼를 교체하라는 메시지를 webgl 스레드에 보내는 스크립트 스레드로 전송됩니다.
• 이 스왑 메시지가 webgl 스레드에서 수신되면 마지막으로 획득한 openxr 스왑체인 이미지를 해제하고 현재 프레임을 종료하기 위해 openxr 스레드에 메시지를 보내고 다음 프레임에 대한 새 스왑체인 이미지를 획득합니다.

https://www.khronos.org/registry/OpenXR/specs/1.0/html/xrspec.html#threading -behavior에 대한 나의 독서는 이 디자인이 실행 가능할 수 있음을 시사합니다. 비결은 Openxr이 아닌 백엔드와 openxr에서 작동할 수 있는지 여부입니다.

사양에서: "xrBeginFrame 및 xrEndFrame은 동일한 스레드에서 호출할 필요가 없지만 별도의 스레드에서 호출되는 경우 애플리케이션은 동기화를 처리해야 합니다."

현재 XR 장치 스레드와 webgl 사이에는 직접적인 통신이 없으며 모두 스크립트나 공유 스왑 체인을 통해 진행됩니다. 나는 surfman 스왑 체인이나 openxr 스왑 체인 위에 있는 스왑 체인 API를 제공하고 그것을 webgl-to-openxr 통신에 사용하고 싶을 것입니다.

이전 시간 측정에 대한 대화의 참고 사항:

* 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

Openxr 텍스처에 직접 렌더링하는 것에 대해 내가 추구하는 조사를 추적하기 위해 #25735를 제출했습니다.

우리가 해야 할 한 가지는 스파이더몽키가 장치에서 다른 엔진과 비교하는 방법을 좁히는 것입니다. 여기서 데이터를 얻는 가장 쉬운 방법은 Servo가 실행할 수 있는 간단한 JS 벤치마크를 찾고 Servo의 성능을 장치에 설치된 Edge 브라우저와 비교하는 것입니다. 또한 몰입 모드에 들어가지 않고 두 브라우저 모두에서 복잡한 바빌론 데모를 방문하여 상당한 성능 차이가 있는지 확인할 수 있습니다. 이것은 또한 우리에게 곧 출시될 스파이더몽키 업그레이드와 비교할 수 있는 벤치마크를 제공할 것입니다.

새로운 데이터가 있습니다. 이것은 ANGLE 업그레이드와 관련이 있지만 IPC 업그레이드는 아닙니다.

$ 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축을 잘라야 합니다.

흥미로운 점:

• 렌더링 시간과 실행 시간은 대부분 안정적인 것처럼 보이지만 전체적으로 스파이크가 클 때 스파이크가 있습니다. 나는 큰 스파이크가 어떤 이유에서든 속도가 느려지는 모든 것에서 비롯된 것이라고 생각합니다.
• 전송 시간은 전체 모양과 꽤 잘 연관되어 있는 것 같습니다.
• 대기시간도 전체적인 모양이 저렇고 _매우_ 물결

현재 상태: IPC 수정으로 FPS는 이제 55 주변을 맴돌고 있습니다. 때때로 무리하게 흔들리지만 일반적으로 로드 후 처음 몇 초 동안(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

그래프:

장기 실행:

더 짧은 실행:

큰 스파이크는 센서 범위 내에 손을 넣었을 때입니다.

이번에는 wait/run_one_frame 시간이 가장 들쭉날쭉하기 때문에 맨 위에 놓았습니다. 이는 OS가 우리를 제한하기 때문입니다.

참고할 몇 가지 사항:

• 도입되는 손의 큰 스파이크는 JS 코드(basil green, "raf render")로 인해 발생합니다.
• 예상대로 전송 시간이 원활해졌습니다.
• 그리기 시작하면 또 다른 JS 스파이크가 있습니다.
• 렌더링 및 전송 시간은 여전히 ​​상당한 예산 덩어리입니다. 스크립트 성능도 향상될 수 있습니다.
  
  
  
  • 메인 쓰레드가 다른 일을 하느라 바빠서 전송 시간이 너무 오래 걸리는 것 같아요. https://github.com/servo/webxr/issues/113 입니다 . @jdm 이 조사 중입니다.
  
  
  • Surfman 업데이트는 렌더링 시간을 향상시킬 수 있습니다. Surfmanup 에 대한 @asajeffrey의 측정값이 내 것보다 나은 것 같습니다.
  
  
  • 표면 공유를 수행하면 렌더링 시간이 향상될 수 있습니다(surfmanup에서 차단됨)
  
  
• xr-profile로 측정할 때 장치에 표시되는 FPS는 거의 절반입니다. 이것은 모든 IO 때문일 수 있습니다.

손을 보고 그리기 시작하기 때문에 성능이 꼬이는 것은 볼슈터에게 존재하지 않습니다. 아마도 페인트 데모는 처음으로 손 이미지를 그리기로 결정할 때 많은 작업을 수행하고 있습니까?

(이것은 webxr 입력 라이브러리와 상호 작용을 시도하는 페인트 데모일 수도 있습니다.)

@Manishearth 메모리 사용량을 오버레이하고 해당 이벤트와 연관시킬 수도 있습니까? JS 코드 최초 컴파일 외에도 수많은 새 코드에서 오류가 발생하고 물리적 메모리 제한에 도달하고 메모리 부족에 도달하면 많은 GC가 발생할 수 있습니다. 나는 대부분의 사소하지 않은 상황에서 그것을 보았습니다. @nox 의 SM 업데이트가 도움이 되기를 바랍니다. FxR Android의 이 SM 빌드에서 분명히 아티팩트를 보았기 때문입니다.

xr-프로파일링 항목과 상관될 수 있는 방식으로 메모리 프로파일링 데이터를 얻는 쉬운 방법이 없습니다.

잠재적으로 기존 성능 도구를 사용하고 모양이 동일한지 파악할 수 있습니다.

@Manishearth xr- 프로파일링 항목이 JS GC 이벤트를 표시합니까(또는 표시할 수 있습니까)? 합리적인 대리인이 될 수 있습니다.

어느 쪽이든, 시작 스파이크는 나의 주요 관심사가 아닙니다. 먼저 60fps에서 모든 _else_을 얻고 싶습니다. 시작 시 1~2초 동안 버벅거린다면 덜 시급한 문제입니다.

예, 약간의 조정이 필요하다는 것을 보여줄 수 있습니다.

@Manishearth 우선 순위에 완전히 동의했습니다! 나는 당신이 "꼬임 풀기"를 시도하고 있는지 아니면 정상 상태로 운전하려고 하는지 확신할 수 없었습니다. 지금은 후자가 더 중요하다는 데 동의합니다.

아니, 나는 대부분 내가 할 수 있는 모든 분석을 기록하고 있었습니다.

전송 시간이 급증하는 소규모 실행의 그래프 끝 근처에 있는 스파이크: 그때 내가 머리를 움직이며 그림을 그리고 있었고 Alan도 작업을 수행할 때 FPS가 떨어지는 것을 알아차렸고 다른 작업을 하는 OS의 탓으로 돌렸습니다. . 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 는 현재 5ms로 설정되어 있습니다.
2. 그런 다음 delay = delay * 2; 에서 각 반복마다 두 배로 기하급수적으로 증가합니다.
3. while delay < timeout 루프의 맨 위에서 확인됩니다.

따라서 최악의 경우 절전 순서는 5micro -> 10 -> 20 -> 40 -> 80 -> 160 -> 320 -> 640 -> 1.28milli -> 2.56milli -> 5.12milli와 같습니다.

5.12밀리초에 도달하면 루프( delay > timeout 이후)에서 빠져나와 총 5,115밀리초를 대기하고 OS가 각 sleep 후에 스레드를 깨우는 데 소요된 추가 시간을 대기합니다

그래서 제 생각에 문제는 당신이 총 5ms 이상을 자고 있을 수 있다는 것입니다. 또한 메시지 이후 1ms 이상(그리고 두 번째는 2.5ms 이상) 동안 두 번 자는 것은 좋은 생각이 아니라고 생각합니다. 그 시간에 들어올 수 있고 당신은 일어나지 않을 것입니다.

나는 그것을 개선하는 방법을 잘 모르겠습니다. 잠재적인 메시지를 찾으려고 하는 것처럼 들리고, 마지막으로 사용할 수 있는 것이 없으면 기본 이벤트 루프의 다음 반복으로 이동합니다. 수신?).

https://doc.rust-lang.org/std/thread/fn.yield_now.html 을 사용하도록 전환할 수 있습니다 . 잠금에 대한 이 기사를 보면 매번 yield 를 호출하는 동안 약 40번 회전하는 것 같습니다. , 최적입니다("회전" 단락 참조, 직접 연결할 수 없음). 그 후에는 수신기에서 차단하거나 이벤트 루프의 현재 반복을 계속해야 합니다(주 임베딩 이벤트 루프 내에서 하위 루프처럼 실행되기 때문에).

(물론, 당신이 측정하지 않는 경우 ipc 부분에 위 켜져 recv_timeout 여전히에 calll 측정 할 수도 있지만, 관계가 recv_timeout 온을 mpsc 쓰레드 채널은 결과에 영향을 미칠 수 있는 내부 회전/항복을 수행합니다. 그리고 위에서 여러 번 확인되지 않은 "IPC 수정"이 언급되었으므로 ipc로 측정하고 있다고 가정합니다.

이것이 이미 고려되었다면 무시하십시오. run_one_frame의 측정을 메시지 처리 기준으로 분석하고 thread::sleep()-ing에 소요된 시간을 측정할 생각을 했습니까?

이미 분해되어 대기/렌더링 시간이 정확히 이렇습니다. run_one_frame의 단일 틱은 하나의 렌더링, 하나의 대기 및 처리 중인 불확실한 수의 이벤트입니다(희귀).

recv_timeout은 측정에 좋은 아이디어입니다.

슬프게도 #25678의 스파이더몽키 업그레이드는 크게 개선되지 않은 것으로 보입니다. 메모리 제약이 가장 큰 것을 제외한 모든 데모의 평균 FPS가 감소했습니다. Hill Valley 데모가 약간 올라갔습니다. 초기화 인수 에서 -Z gc-profile 를 사용하여 Servo를 실행하면 마스터와 스파이더몽키 업그레이드 분기 간의 GC 동작에 차이가 표시되지 않습니다. GL 콘텐츠가 로드되고 표시된 후에는 GC가 보고되지 않습니다.

다양한 지점에 대한 측정:

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의 변경 사항으로 Ion JIT를 비활성화하면 12FPS에서 시작한 다음 몇 초 후에 갑자기 1FPS로 감소하고 거기에 머문다.

해당 패치로 몇 가지 측정을 수행했습니다.

페인트에서 보기에 콘텐츠가 많지 않을 때 60fps를 얻고 그려진 콘텐츠를 볼 때 50ish fps로 떨어집니다(노란색 스파이크는 내가 그린 콘텐츠를 볼 때 나타납니다). 이유를 말하기는 어렵습니다. 대부분 대기 시간이 openxr 스로틀링의 영향을 받는 것 같지만 다른 것들은 문제를 일으킬 만큼 느리지 않은 것 같습니다. 스왑 요청 타이밍이 약간 느립니다. rAF 실행 시간은 처음에는 느리지만(이것이 초기 "컨트롤러를 처음 볼 때" 속도 저하임) 그 후에는 꽤 일정합니다. openxr이 우리를 제한하는 것처럼 보이지만 다른 곳에서는 이를 야기할 눈에 띄는 속도 저하가 없습니다.

이것은 내가 드래그 데모를 위해 가지고 있는 것입니다. y 스케일은 동일합니다. 여기에서 실행 시간이 우리를 느리게 한다는 것이 훨씬 더 분명합니다.

한 가지 주의할 점은 #25837을 적용한 상태에서 측정을 했으며 성능에 영향을 미칠 수 있다는 것입니다.

나는 아니었지만 나는 당신과 비슷한 결과를 얻었습니다

콘텐츠를 볼 때 60FPS에서 45FPS로 이동하는 순간의 성능 도구 그래프:

비난은 전적으로 xrWaitFrame에 있는 것 같으며 다른 모든 타이밍은 매우 가깝습니다. xrBeginFrame은 여전히 ​​xrWaitFrame 직후에 있고 xrEndFrame은 xrBeginFrame 이후 4us입니다(두 경우 모두). 다음 xrWaitFrame은 xrEndFrame 바로 뒤에 있습니다. 설명되지 않은 유일한 간격은 xrWaitFrame 자체에 의해 발생하는 간격입니다.

드래그 데모를 사용하면 다음과 같은 추적을 얻을 수 있습니다.

다음은 동일한 스케일의 페인트 데모입니다.

우리는 시작/종료 프레임 사이에 느리고(가장 빠른 경우 5ms에서 38ms로!) 대기 프레임 조절이 시작됩니다. 아직 이것이 왜 그런지 설명하지 않았으므로 다음 코드를 살펴보겠습니다. 둘 다.

드래그 데모는 광원이 그림자를 드리우므로 느려집니다. 그림자 작업은 GL 측에서 수행되므로 쉽게 속도를 높일 수 있는지 잘 모르겠습니다.

완전히 GLSL을 통해 완료되면 어려움이 있을 수 있습니다. WebGL API를 통해 모든 프레임이 완료되면 최적화할 위치가 있을 수 있습니다.

네, 모두 GLSL 쪽에 있는 것 같습니다. 섀도우 API가 작동하는 방식과 관련하여 WebGL 호출을 볼 수 없었고 셰이더로 전달되는 일부 비트만 표시되었습니다.

나는 이것이 일반적으로 해결되었다고 생각합니다. 작업이 필요한 개별 데모에 대한 문제를 제출할 수 있습니다.