Technical Notes

XR - 모바일 AR/VR에서 Motion to Photon

태후아빠 2019. 8. 8. 00:59

  이 글은 medium.com 이라는 사이트에 올라온 글을 번역한 것입니다.

  원문글(영문)은 여기있습니다. 링크를 따라가 보세요.

DAQRI라는 실력있는 AR device 업체의 엔지니어가 작성한 글로, MTP(Motion to Photon)라는 AR/VR 성능 평가의 중요한 항목에 대한 A to Z를 설명하였습니다.

  의역하려 노력했으나 직역에 더 가까운...
한글로 바꾸기 어렵거나 바꾸었을 때 의미 전달에 무리가 있을 것으로 판단되는 경우, 영어를 직접사용했습니다.


  최근까지, AR/VR 고품질 경험은 비싸거나 연구실의 개별적인 솔루션 혹은 상업적 설치로만 가능했지만 현대 AR/VR 시스템들이 집에서 사용 가능하게 만들었다. AR, VR의 새로운 바람은 Oculus와 HTC가 Rift와 Vive 상품을 출시한 2016년에 시작되었다. 한 때 엄청 비쌌던 기술이, 갑자기 좀 더 흔하게 접근 가능해져, 어떤 사용자들은 집에서 이 시스템들을 사용할 수 있게 되었다. 아직, 이 테더드 시스템은 고사양 컴퓨터에 의존하고 있고 "outside-in tracking"을 사용한다. 이는 사용자의 위치와 방향 측정을 위한 트래킹 설비를 꾸리기 위해  고정된 장치가 이 환경에 설치되어야만 한다는 의미다.

 

  이후로, Microsoft 혼합현실(Mixed Reality), Oculus Go, 그리고 HTC Vive Focus 같은 새로운 시스템이 "indise-out tracking"을 발전 시켰다. 이 새로운 시스템들은 미리 설치된 환경에 의존하지 않는다. 그래서 환경을 준비하는데 드는 불편함을 줄이고 있다. 비슷하게, AR 쪽에서는 DAQRI Smart Glasses나 Microsoft Hololens같은 시스템들이 진정한 이동성을 가능하게 하는 indise-out tracking을 활용하고 있다. 이 모든 시스템들은 사람이 대체로 느끼지 못할 정도의 latency를 달성하기 위해 여러 형태의 visual-inertial fusion을 사용한다.

 

  이 글에서는 이 AR, VR 시스템에서 사용되는 기술에 대하여 깊이 들어가 이야기 할 것이다. 그리고 이 세 주요 컴포넌트들(관성측정장치, 예측, 사후 수정)이 어떻게 수 밀리초정도의 latency를 갖는 파이프 라인에 접목되는지 볼것이다.  고정된 VR 시스템과 비교해서 모바일 AR 시스템이 극복해야하는 것이 꽤 고수준의 도전이기 때문에 우리는 전적으로 모바일 AR 시스템에 집중할 것이다.

 

LATENCY

 

  Latency 혹은 "Motion to photon latency"는 모든 AR, VR 시스템에 있어서 결정적인 속성이다. 이것은 사용자가 어떤 동작(고개를 돌리는 동작들)을 할 때부터 이 동작에 의한  컨텐트의 변화(사용자고 고개를 오른쪽으로 돌리면 VR 세계는 왼쪽으로 돌아가야 한다)가 화면에 보이기 까지의 시간 간격이다. "Photon"이라는 말은 디스플레이 시스템의 전체가 이 과정에 관여되어 있는데 디스플레이에서 포톤이 반짝하는 시점을 말한다.

 

  인간은 이 latency를 아주 잘 지각한다. VR에서 사용자는 가상 컨텐츠만을 보고 있기 때문에, 근육의 움직임과 전정기관으로부터 불일치감(perception of misalignment)이 유래된다. 이런 시스템들에서는 최고 20ms의 지연은 사용자가 알아채지 못한다. AR에서는 투명한 광학장치가 가상 컨텐츠를 실세계상에 덧입히기위해 사용된다. 실세계에는 지연이라는게 없기 때문에 이런 AR 시스템에서의 latency는 실세계와 가상 컨텐츠사이의 밀림(misregistration, 오등록)의 형태로 시각적으로 보여지게 된다. 사람의 시각 기관은 극히 민감해서 사용자들에게 이 지연이 보여지지 않게 하기 위해 5ms의 latency 혹은 그보다 적은 latency가 요구된다.

 

  이렇게 낮은 latency를 달성하는것은 보통 생각하는 것보다 복잡하다. 특히 시스템이 동작하는 각 단계가 전체 latench에 기여하기 때문이다. 높은 레벨에서, 동작을 측정하고 디스플레이에 컨텐트를 보여주기까지의 파이프라인은 다음의 주요 블럭을로 구성된다.

  • Sensor(camera 와 IMU)
  • Tracking(동작 추정)
  • Rendering(이미지 생성)
  • Display(이미지 제출)

이 네가지 주요 블럭이 잘 디자인되고 구현된 AR,VR 시스템에 적용되어있다고 가정하자. 그리고 OS레벨에서 의 복사나 버퍼 라킹 그리고 큐잉 등의 외부 펙터는 불필요한 latency를 더하지 않는다고 가정하다.

  각 블럭을 조사한 후, 우리는 이 파이프라인에 대한 순진한(naive) 구현이 쉽게 100ms 이상의 latency를 초래하게 되는 것을 볼 수 있을 것이다. 각 블럭의 latency를 분리 검토하고나면 5ms의 AR 시스템 요구사항을 만족시키기 위해 어떻게 단대단 latency를 줄일 수 있는지 논할 것이다. 

 



SENSOR

 

  오늘날 대부분의 모바일 AR, VR 기기들은 동작 추정(motion estimation)을 위해 카메라와 IMU를 조합하여 사용한다(inside-out pose tracking). 우리는 IMU가 견고한 포즈(기기의 위치와 방향) 추정과 단대단 latency 모두에 중요하다는 것을 보게 될 것이다.

 

  AR, VR 시스템은 보통 트래킹 카메라를 30Hz로 운용한다. 이것은 33ms 마다 이미지를 읽고 처리를 위해 넘겨진다는 의미다. 게다가 30Hz frame rate는 노출시간을 프레임당 33ms로 제한한다.

 

  노출 시간이 20ms로 고정되어 있다고 가정하자. 사후 처리를 위해서는 우선 timestamp를 센서 측정시마다 할당해야한다. 실질적인 노출을 위해 시작과 끝시간이 결정 요소이다. 하지만, 처리의 관점에서 본다면, 노출의 정중앙 시간을 사용하는게 편리하다. 그러므로, 노출이 끝나면 이미지는 이미 노출 시간의 절반 만큼 지난 시점이 된다. 따라서 우리의 예제에서 이미지는 이미 10ms 이전의 것이 된다. 노출이 끝나는 순간 이미지가 읽혀지고 이미지 처리 시스템으로 전달되어야 한다. 우리 시스템에서는 5ms가 더 소요된다. 트래커가 이미지 처리를 즉시 시작한다고 해도 이 시점의 이미지는 15ms가 지난것이다.

 

  카메라가 30~60Hz로 동작하는 한편, IMU는 수백, 수천Hz의 훨씬 빠른 속도로 동작한다. 우리 시스템에서는 IMU가 1000Hz로 동작하고 매 ms마다 새로운 sample을 연속적으로 생성한다고 가정하자. IMU 데이터는 매우 작고 latency가 낮아서 가장 최근 IMU 값은 대략적으로 1ms정도 지난것이라고 해도 무방하다.

 


 

TRACKING

 

  트래킹은 센서 데이터를 사용하여 6DoF 포즈 추정을 계산하고 이는 기기가 어떻게 이동하고 회전 했는지를 설명한다. 위에서 말했듯이, 트래킹 시스템에 도착한 카메라 이미지는 적어도 15ms 이전의 것이다. 한편, IMU는 1ms 이전의 데이터를 즉시 사용 가능할 정도로 latency가 낮다. 그러나 카메라 프레임보다 더 최신인 IMU 데이터는 보통 이 단계에서 사용되지 않는다.

  우리 예제는 카메라가 30Hz로 동작한다는 가정을 했기 때문에, 트래킹 시스템도 같은 속도로 동작해야 하고 처리하는데 33ms의 여유를 제공한다. 물론 각 프레임에 처리 시간을 좀 더 주기 위해 연속된 카메라 프레임을 병렬로 처리하는 것도 가능하지만, 이런 방법은 추가적인 latency를 발생시키기 때문에 여기서는 사용되지 않을 것이다. 대신, 카메라 이미지와 IMU 데이터 처리를 끝내는데 25ms를 소비한다고 가정할 것이다.


  카메라 프레임 처리는 트래커가 프레임을 처리 할수 있게되자마자 시작할 수 있기 때문에, 센서 데이터를 얻어오는 시간과 트래킹이 모두 추가되어서 결국 15ms + 25ms = 40ms의 latency가 동작추정값을 가지게 되는 시간이다. 이 동작 추정값은 랜더링을 위해 어플리케이션으로 보내진다.

 

RENDERING

 

  렌더링은 2D 이미지를 생성하는 단계이고 이어서 프레임 버퍼의 형태로 디스플레이에 전달된다. 이 이미지를 생성하기 위해 렌더러는 몇가지 입력을 필요로 하는데, 사용자에게 보여질 3D 컨텐츠와 렌더링할 영역(view port)이다. 랜더링은 포즈 추정과 다른 속도로 동작한다(보통 60, 75, 혹은 90Hz). 그래서 랜더링은 트래킹과 비동기적으로 수행되는것이 적당하다. 이를 명심하고, 랜더링이 60Hz로 동작한다고 가정하자.

  새로운 프레임이 생성될 때, 랜더라는 트래커가 추정한 가장 최근의 카메라 포즈를 사용한다고 가정할 수 있다. 트래커가 30Hz로 동작하기 때문에 최대 33ms 이전의 것일 수 있다. 60Hz에서는 랜더러가 새로운 프레임을 대략 16.7ms마다 생상 한다. 그 16.7ms 기간 중 끝부분에서만 이스플레이로의 프레임 전송과정이 사작한다. 이것은 랜더링 시작부터 프레임 버퍼 읽기를 시작할 때까지 16.7ms가 걸린다는 뜻이다.



  종합하면, 랜더링 블럭이 이전 블럭의 40ms에 추가로 17~50ms가 더해져서 총 57~90ms의 latency가 되고 5ms의 요구사항과는 아주 멀어진다.

 

DISPLAY

 

  대부분의 컴퓨터 과학자들은 GPU가 랜더링을 끝내고나서 프레임 버페에 무슨 일이 일어나는지 생각하는데 많은 시간을 소비하지 않는다. 그러나 AR, VR을 위해서는 디스플레이 동작방식이 매우 결정적이고 이는 해결되어야 할, 쉽게 보이는 추가 latency의 많은 분량을 추가하기 때문이다. 따라서 디스플레이 동작방식을 이해하는 것은 낮은 latency를 얻기 위한 기본이다.

  프레임 버퍼 스캔아웃이 시작될 때, 데이터는 픽셀 마다 그리고 라인마다 디스플레이에 전송된다. 특별한 디스플레이 프로토콜(HMDI, DP, MIPI-DSI)은 이 논의에서 중요한게 아니다. 이런 모든 프로토콜은 프레임버퍼를 주어진 프레임 레이트에 맞최 최대한 빨리 전달하도록 비슷하게 동작하기 때문이다. 디스플레이가 60Hz로 동작하기 때문에 프레임을 디스플레이에 전달하는데 1/60초가 걸리고 추가로 17ms의 latency가 추가된다.

  지금까지 얘기해온 AR과 VR 파이프라인은 꽤 일반적이었다. 그러나 디스플레이 타입은 구별해야한다. Line-sequential(LCD, OLED) 디스플레이와 color-sequential(LCOS) 디스플레이에 대하여 얘기해보자.

 

LINE SEQUENTIAL DISPLAYS

 

  Line-sequential 디스플레이는 PC 모니터, TV 그리고 VR 헤드셋에 들어간다. 그리고 오늘날 가장 일반적인 디스플레이 타입이다. 이 시스템들에서 각 픽셀은 주요 3색을 저장하고 프레인 데이터들은 다음과 같이 보인다. RGBRGBRGB…

  이 패턴은 프레임이 스캔라인으로 구성되었다는 것을 말하고, 각 스캔라인은 픽셀로 구성되며 또 이 픽셀은 적, 녹, 청 요소를 포함하고 있다는 것을 말해준다. OLED와 LCD 디스플레이는 전통적으로, 크기변형(rescaling)같은 추가 작업을 수행하지 않는한 수신된 픽셀 데이터를 임시 버퍼에 저장하지 않는다. 대신, 데이터가 도착하면 해당 픽셀을 직접 업데이트 한다. 그러므로, 디스플레이의 가장 위에 있는 스캔라인은 같은 프레임에서 가장 아래에 있는 스캔라인 보다 대략 16ms정도 먼저 업데이트 된다.

  비슷하게 프레임에서 가장 아래에 있는 스캔라인은 다음 프레임의 가장 위에 있는 스캔라인 바로 전에 업데이트 된다. 그러므로, 가장 위의 스캔라인의 latency는 아주 적다(대략 1ms라고 가정하자). 그에 비해 가장 마지막 스캔라인의 latency는 프레임 타임 전체시간(16.7ms)의 길이가 된다. 아래 그림은 line sequential 이스플레이의 롤링 업데이트 메커니즘 타이밍을 설명한다.

 



COLOR SEQUENTIAL DISPLAYS

 

  오늘날, LCOS는 가전 기기에서 덜 일반적이다. 하지만 모바일 AR기기에서는 아주 일반적이다. 예를 들면 DAQRI 스마트 글라스와 MS Hololens가 LCOS이다. LCOS는 한번에 하나의 색만 보여줄 수 있다. 전체 RGB 프레임을 보여주기 위해 LCOS 디스플레이 메트릭스는 붉은 색 이미지를 실제로 보여주기 위해 붉은색 LED를 켜기 전에 모든 픽셀의 붉은 컴포넌트를 먼저 업데이트 한다. 그리고나서 붉은 색 LED가 꺼지고, 녹색 컴포넌트를 위해 디스플레이 매트릭스가 재설정된다. 그리고 녹색 LED가 활성화되고 녹색 이미지가 표시된다. 이 프로세스는 파란색과 녹색(옵션)을 위해서 다시 반복된다.

 


 

  이런 방식이 동작은 두 가지 중요한 결과를 초래한다. 첫째는 LCOS로 보내진 데이터는 RGB 프레임으로 합성되어 있으면 안되고 서로 다른 색의 서브 프레임으로 구성되어 있어야 한다. GPU는 기본적으로 합성된 RGB 프레임을 생성한다. 그리고 디스플레이 표준도 이렇게 조합된 RGB 프레임으로 동작한다. 그래서 서브 프레임이 LCOS에 전달되기 전에 색 분리 단계가 주가로 필요하다.(보통 하드웨어 블럭의 형태) 그러나, 색 별 서브프레임은 완전한 RGB 프레임을 수신하기 전까지는 만들 수 없어서, 이 분리 단계의 영향으로 한 프레임의 latency가 추가된다. 단일 서브프레임이 표시되기 전에도.

  HDMI와 DP가 표준 프로토콜로 느린 한편, LCOS응 빠른 정용 프로토콜을 사용한다. 예를 들면, 분리된 서브프레임을 LCOS까지 전달하는데 일반적으로 1ms 이하가 소모된다. 서브프레임을 사용하므로써, 각 색이 분리되어 표시되고 이는 latency가 색별로 다르다는 의미가 된다. 전통적인 서브프레임 시퀀스는 적, 녹, 청, 녹으로 각각 4ms의 오프셋이 있다. 전체적으로 60Hz에서 GPU부터 색 분리기까지 RGB 프레임을 보내는데 17ms까지 걸리고, 색 분리기부터 LCOS까지 첫 서브 프레임을 보내는데 1ms정도 걸린다. 각 이어지는 서브프레임은 추가적인 오프셋으로 인해 지연된다. 이는 거의 4ms로 가정할 수 있다. 그래서, 붉은색 18ms, 녹색 22ms, 청색 26ms 그리고 옵션으로 녹색 30ms의 지연이 발생한다.

 

OVERALL LATENCY OF A NAIVE AR/VR PIPELINE

 

  이제 우리는 모든 4가지 블럭을 다루었고 그 latency를 더하면 어떻게 되는지 보자.


 

  OLED든 LCOS든 AR이나 VR 시스템에는 latency가 충분하지 않다는 것은 분명하다. 사실 각 블럭이 AR 시스템을 위한 5ms보다 더 길게 차지한다. 더구나 LCOS 시스템의 latency는 15~24배 정도까지 된다. 어떻게 이것을 고칠 수 있을까?

 

  위 테이블의 증거들로 부터, 랜더링과 디스플레이가 전체 latency의 50%이상을 차지한다는 것을 알 수 있다. 좀 더 도전적인 것은, 이 변동 가능한 latency가 아주 불편한 영향을 만들것이라는 것이다. 에를 들면 트래킹이나 애니메이션이 덜컹거리게 한다.

  latency를 줄이는 세개의 주요 기술에는 IMU, 예측(prediction), 사후 수정(late correction)가 포함된다. 이 세 기술이 랜더링과 디스플레이 단계에서 역할을 한다. 위 과정에서 40ms의 latency가 이미 누적되어왔기 때문에 이상하게 보이지만, 우리는 어떻게 이 latency가 여러 번 취소될 수 있는지 그래서 우리의 목표인 5ms를 달성하도록 하는지 볼 것이다.

 

OVERCOMING SENSORS AND TRACKING LATENCY

 

  위에서 언급했다시피, 랜더러가 트래커로부터 가장 최신의 포즈 값을 가져올 때, 이 값은 40ms~73ms 정도 이전의 값일 수 있다. 다행히 이 latnecy를 줄이기 위해 몇가지 다른 방법을이 사용될 수 있다. 하지만, 아래에서 보겠지만, 어떤 해결책들은 그리 좋지 않은 결과를 동반한다.

  첫번째로 카메라 노출 시간을 줄일 수 있고 이는 모션 블러(1)에 긍정적인 효과를 가져온다. 그러나, 작고 값싼 카메라는 보통 적은 노출 시간 때문에 심각한 노이즈라는 부산물이 발생한다. 결과적으로, 20ms 이하의 노출은 보통 야외 같은 좋은 조명 환경에서나 가능하고 따라서 실행가능한 해결책으로서 부적합하게 만든다.

  두번째로 빠른 트래킹 방법 혹은 빠른 처리장치를 사용함으로써, 이미지 처리할 때 트래커에서 소비되는 시간을 줄일 수 있다. 그러나 빠른 트래킹 방법은 일반적으로 정확도와 안정성이 낮다. 그리고 이 두 요소는 우리가 타협할 수 없는 요소다. 게다가 빠른 트래킹 처리장치는 종종 더 많은 전력을 소비한다. 이것은 받아들여질 수도 있고 없을 수도 있다. 이 경우, 트래커를 더 빠르게 돌리기 위한 전력을 쓰지 않는 트래킹을 위해 저전력 CPU(DSP 혹은 ARM CPU)가 사용된다고 추측할 수 있다.

  다행히 IMU가 해결책을 준다. 카메라에 비하여 IMU는 임의의 샘플링 주기로 운영할 수 있다. 여기서 우리는 1000Hz라고 가정한다. 즉, 매 샘플은 최대 1ms 이전 것이 된다. 적절한 시관성 병합(visual inertial fusion)으로, 어떤 순간에서 다음 순간까지의 상대 이동 경로를 계산하기위해 IMU 데이터를 사용할 수 있다. 그 기간동안의 모든 IMU 샘플을 계산에 통합해 넣음으로써 가능하다. 다음 절대위치 계산을 위해 이전 절대 위치에 이 상대 이동이 적용될 수 있다. 그러므로, 트래커로 부터 얻은 마지믹 위치와  그 순간 부터의 모든 IMU 샘플을 이용하여 바로 1ms 이전의 새로운 포즈를 계산할 수 있다. IMU 데이터 통합은 제한사항이 있는데, 노이즈와 누적 드리프트(2)가 그것이다. 그럼에도, 우리의 목적을 위해서 랜더러에 거의 1ms이전의 포즈를 줄 수있는 좋은 해결책이다.

 


 

OVERCOMING RENDERING AND DISPLAY LATENCY

 

  최신의 포즈를 사용하는 것은 의심할 여지 없이 오래된 포즈를 사용하는 것보다 선호된다. 하지만 랜더링 된 프레임이 디스플레이에 표시되는 이 포즈는 순간 다시 예전것이 되기 때문에, 이것만으로는 충분치 않다. 다행히, 디스플레이가  GPU와 동기화되어있기 때문에, 랜더링된 프레임이 화면에 표시될 때까지 얼마나 걸릴지, 랜더링이 시작되는 순간에 제대로 예측할 수 있다. 그래서, 현재 포즈 값을 사용하는 대신 미래 시점의 포즈 값을 사용해야한다. 우리는 미래를 예상할 수 없지만, 등속도, 등가속도 그리고 최신 동작에 기반해 예즉을 하는 고계 모션커브(higher order motion curve)와 같은 모델을 사용할 수 있다.

  동작 예측은 앞으로 예측해야할 기간이 20ms 정도로 짧으면 잘 동작한다. 그러나 기간이 길어지면 빠르게 떨어진다. 그래서 최신의 포즈 예측 값으로 랜더링한 후에 프레임 버퍼를 워핑(warping)함으로써 랜더링 결과물을 사후 수정(post-correct)하는 것이 일반적이다. 이 워핑은 순수한 2D 작업이기 때문에 3D 씬 랜더링보다 매우 빠르고 그 속도는 씬의 복잡도와 무관하다. 결과적으로, 이 작업은 최신 GPU상에서는 화면에  프레임 버퍼가 전송되기 직전, 수 ms 안에 실행된다. 이 늦은 수정(late warping라고불린다)은 90년대부터 VR 연구계에 알려졌다. 하지만 최근 time warping이라는 이름으로 재발명되었다. 개념적으로 간단하지만, 늦은 수정은 매우 정확한 타이밍과 이상적인 GPU preemption이 필요하다. Oculus와 Valve 같은 회사들이 GPU 생산자들과 수년간 함께 작업해서 모든 현대 GPU들은 이 기능을 잘 지원한다. 아래 그림은 랜더링과 워핑이 전위 예측시간(forward prediction times)을 어떻게 다르게 사용하는지 보여준다.

 


 

  이제 우리의 파이프라인의 마지막 단계에 왔다. 이 단계에서는 픽셀 데이터를 GPU 메모리에서 디스플레이로의 전송 최적화에 대해 다룬다. 이 단계는 실제 디스플레이 기술에 달려있다. 이제 모바일 AR과 VR 디스플레이의 두가지 주요 형태인 OLED와 LCOS의 일반적인 솔루션을 얘기해보자.

 

OLED DISPLAYS

 

  보통 사용자 VR기기의 디스플레이로 OLED가 사용된다. LCD와 비교해서 OLED는 낮은 픽셀 잔존율(lower pixel persistence)을 가진다. 이로인해 latency가 낮고 모션블러가 적다. 이것은 고품질 AR, VR 경험의 필수이다. 요즘, Oculus, HTC 그리고 Sony가 만든 대부분의 사용자용 VR 기기들은 결국 OLED를 쓴다. AR쪽에서는 ODG R9가 OLED 디스플레이를 사용하는 것으로 잘 알려져 있다. 상위 레이어에서 보면 이런 디스플레이들은 보통의 데스크탑 모니터과 비슷하게 동작한다. 픽셀 데이터는 GPU 메모리에서 디스플레이로 가로줄당 전송되고 디스플레이는 추가 버퍼링 없이 픽셀 셀마다 직접 업데이트 한다. 프레임 버퍼 전송은 실시간으로 진행되고 이는 하나의 프레임 버퍼 전송에 한 프레임 만큼의 시간이 걸린다는 의미다. 프레임 버퍼가 위에서 아래까지 전송된다고 가정하면 디스플레이의 맨 위 줄은 read-out이 시작하자 마자 보여지고 마지막 줄은 모든 프레임이 전송될 때까지 안보이게 된다.

  이런 동작은 DP, HDMI 그리고 임베디드 영역의 MIPI-DSI 같은 모든 표준 프로토콜에서 동일하다. 데스크 탑 컴퓨터에서는 문제가 되지 않지만, AR 혹은 VR 시나리오에서 이런 동작은 두드러진 결과를 만든다. 가장 위쪽과 가장 아래쪽 줄 간의 시간차 때문에, 롤링 셔터 카메라처럼, 렌더링 되는 씬에 shearing이 발생하거나 움직이는 동안 다른 현상으로 문제가 발생할 수 있다.

  이 문제에 대한 해결책은 전체 이미지에 대한 warping 처리를 한번만 하지 않고 늦은 warping을 수행하는 것이다. 이미지를 세로 방향의 여러 타일로 나누고 각 타일 별 다른 pose값으로 warping을 하면 된다. 이렇게 조금씩 다른 시간에 진행되는 warping은 프레임버퍼 read-out과 정확하게 동기화되어야 한다. 다음 타일이 read-out하기 직전에, 동일한 타일이 가장 최신 pose값으로 warping된 타일이 생성된다. 개념적으로 이것은 80년대 가정용 컴퓨터와 게임 콘솔에서 유명  했었던 raster interrupt 프로그래밍과 아주 흡사하다.

  예를 들어, 디스플레이가 60Hz로 동작한다고 가정하자. 이는 프레임 전체가 read-out되기까지 16ms가 소요된다는 뜻이다. 만약 프레임버퍼가 16개의 타일로 나뉘어 있다면 각 타일은 이전 타일이 read-out되고 나서 약 1ms 후에 read-out된다는 것이다. 이 기술을 이용해, GPU 메모리에서 디스플레이되기까지 수 ms의 latency를 줄일 수 있다.

 

LCOS DISPLAYS

 

  OLED와 달리, LCOS는 표준 프로토콜이 없다. 그리고 각각 매우 다른 독점 프로토콜을 제공하는 LCOS 제조사들이 있다. DAQRI 스마트 글라스에서 사용되는 HIMAX LCOS를 생각해보자. MS 홀로렌즈에서도 사용 된다고 한다.

  LCOS 디스플레이는 여러 이유에서 OLED와 다르게 동작한다. 첫째로, 픽셀을 업데이트하는 메커니즘은 보통의 LCD나 OLED 디스플레이 보다는 DLP 프로젝터와 더 비슷하게 동작한다. 게다가, LCOS 픽셀 매트릭스는 LED가 꺼져있을 때 업데이트 된다. 그래서 실제 업데이트 하는 단계가 보이지 않는다. 픽셀 매트릭스가 완전히 업데이트 되면 LED가 켜지고 새로운 이미지 전체가 한번에 보여진다.

  두번째로, 전통적인 디스플레이는 모든 RGB 이미지들을 보여주는 반면, LCOS에 기반한 디스플레이들은 색 순서대로 동작한다. 그러니까 한 순간에 하나의 색깔만 보여진다. 보통 빨강, 녹색, 파랑 그리고 다시 녹색의 순서다. 각 색깔이 보여지는 사이에 픽셀 매트릭스가 각 픽셀의 컴포넌트 별로 표현하도록 업데이트 된다. 이런 색다른 모드가 OLED가 하는 롤링 업데이트를 방지하는 장점이다. 그러나 단점이 있는데 예를들면 무지개 효과 같은 색 깨짐(번짐?) 현상이다. 움직이는 동안, 시간에 따라 다른 색깔이 공간 상으로도 분리된 색을 만들게 된다. 그래서 사람들이 쉽게 알아본다. 이것은 색깔별 포즈 예측방법을 적용하여 줄일 수 있지만, 부수적으로 오버헤드를 만들고 색 깨짐(번짐)을 완벽하게 줄일 수 없다. 다행히, 색 순서 계통의 디스플레이는 매우 빠르게 동작한다. 게다가 앞에서 말한 RGBG순서의 동작은 디스플레이의 실제 업데이트 속도가 60FPS라는 말이 아닌 서브 프레임 기준으로 240FPS라는 의미이다. 각 서브 프레임들이 단색 컴포넌트이기 때문에 훨씬 간결하고 풀 RGB 프레임보다 짧은 시간에 디스플레이로 전송 될 수 있다. 어떻게 이 기술이 이렇게 극히 적은 latency를 이룰 수 있는지 논의해 보자.

  HIMAX 같은 데서 만든 LCOS는 HDMI나 DP 같은 표준 프로토콜을 사용하지 않는다. 뒤에 숨어있는 이유는 GPU가 원래부터 색 순서 프레임버퍼를 만들지 않는다는 것이다. 그래서 LCOS가 요구하는 색순서 형식의 프레임 버퍼를 제공하는 추가단계가 있어야 한다. LCOS 제조사들은 보통, 일반 디스플레이 표준을 통해 프레임 버버를 받아 필요한 색 분할 단계를 수행하는 호환 칩을 제공한다. 이 칩은 또, 독점 프로토콜을 사용하여 데이터를 전달한다. 그러나 RGB 프레임이 색별로 나뉘기 전에, 프레임 전체가 호환 칩에 모두 전달되어야 한다. 그리고 이 동작은 전체 프레임 시간을 잡아먹기 때문에 심각한 딜레이를 만든다.

  대신, 색 분할을 호스트 쪽(CPU, GPU)에서 수행하는게 효과적이다. 이 단계는 늦은 warping 단계의 일부분으로 수행된다. 그리고 나서 각 색별 컴포넌트 프레임 버퍼들을 LCOS에 직접 전달한다. 호스트는  RGB 프레임의 빨강 컴포넌트에 대하여 warping을 하고 LCOS가 직접 디스플레이 하도록 전달한다. 정확한 오프셋 시간 만큼 지나서 녹색과 파랑 그리고 다시 녹색에도 같은 작업을 반복한다. 이런 접근법은 GPU와 LCOS를 직접 연결하는 개별화된 실리콘이 필요하고, 다음 프레임을 랜더링 하는동안 현재 프레임을 warping 할 수도 있어야 하기 때문에 쉽지 않다(challenging). 그럼에도 불구하고 이 기술에 대한 최적화된 구현은 GPU에서 부터 표시장치까지 색깔 컴포넌트당 1~2ms의 latency를 달성할 수 있다.

 

LATENCY OF AN OPTIMIZED AR/VR PIPELINE

 

  그래서, 위 모든 기술을 고려했을 때 우리는 얼마나 낮은 MTP latency를 얻을 수 있을까? 이 질문에 답하기 위해 우선 디스플레이 기술을 OLED와 LCOS로 구분해야만 한다. 각각 다른 방법들이 필요하고 다른 결과를 낳기 때문이다. 그리고 우리의 latency에 대한  정의를 재 정비해야한다.

  Motion-to-Photon latency는 두 시점에 관한 것이다. 모션일 발생한 시점과 결과 이미지가 사용자에게 보여지는 시점이다. 모션쪽에서는 측정된 모션을 어떻게 사용할지 고려해야한다. 처음에는 모션을 3D 씬을 랜더링 하기 위한 입력으로 쓰기를 원했다. 하지만 이게 과도하게 높은 latency를 유발한다는 것을 알고 나서 우리는 우리의 시스템에 사후 warping을 적용하여 확장했다. 이 사후 warping이 포즈 입력을 사용하지만, 아주 제한된 만큼의 수정만 수행할 수 있다. 이미 생성된 2D 프레임 버퍼에 적용되기 때문이다. 다행히, 이 제한된 만큼의 수정으로도 실제로는 충분하다. 그래서 모션쪽에서는 warping된 포즈의 타임 스탬프를 고려할 것이다.

  디스플레이 쪽에서, OLED와 LCOS 모두 디스플레이를 업데이트하는 순서 특성때문에 부가적인 latency를 만든다. 우리는 OLED 같은 스캔 라인 순차형 디스플레이의 latency를 줄이기 위해 세로 방향 조각마다 warping을 적용했다. LCOS같은 색 순차형 디스플레이의 latency를 줄이기 위해 색요소별 warping을 적용했다. 흥미로운것은 달성 가능한 latency는 두 경우 다 비슷하다. 하지만 한쪽은 공간영역이가 다른 한쪽은 색 영역이다.

  이 모든 것을 고려하여, LCOS 기반의 디스플레이를 가지고 최적화된 AR 파이프라인을 알아보자. 우리는 위 예제의 값들을 약간 바꾸어서 사용할 것이다. 우리는 랜더러와 디스플레이가 DAQRI smart glass처럼 90Hz에서 동작한다고 가정할 것이다. 또 단순화 하기 위해 RGBG 서브 프레임 보다는 RGB 서브 프레임이라고 가정할 것이다. 마지막으로 LCOS가 GPU에서 서브프레임을 직접 수신하는 방식으로 연결되었다고 가정할 것이다.

  아래 그림은 이 시스템에서 모든 컴포넌트들이 어떻게 함께 동작하는지를 보여준다. 이전에 정한 것처럼 트래커가 카메라 이미지를 찍은 순간, 이미 15ms가 지나간다. 트래커는 추가로 25ms의 latency를 더 잡아먹고 그래서 포즈를 사용할 수 있게 될 때까지 이미 40ms의 latency를 갖게 된다. 랜더러가 트래커가 만든 최신의 포즈값을 가져갈 때, 랜더러는 가용 IMU 샘플을 사용해 카메라 모션을 기반으로 1ms정도의 latency를 갖는 포즈를 계산한다. 랜더러는 17ms정도 앞의(미래의) 순방향 예측 포즈 값을 추가로 예측한다. 이 17ms는 랜더링 시간 11ms와 디스플레이에 중간 서브프레임이 보여지는 시간 6ms를 더한 것이다.

  순방향 예측을 더욱 향상시키기 위해, 시스템은 이런 과정을 사후 wraping 단계에서 반복한다. Warping은 총 세번 수행된다. 매 서브 프레임마다 한번씩 하는것이다. Warping에 2ms와 readout과 LCOS로 전송하는 시간 2ms를 더한다고 가정하면 각 서브 프레임마다 4ms에 대한 순방향 예측을 하면 된다. 이것은 latency를 줄이고 좀더 정확한 예측을 할 수 있게 한다. 그리고 결국 색 깨짐(번짐)을 줄이는 색 채널별 수정이 적용된다.

 



  종합적으로, 이 시스템으로 우리가 달성할 수 있는 최종 latency는 무엇일까? 정담은 그때그때 다르다. 우리가 최신 6DOF 포즈 예측을 완전히 수정된 AR 오브젝트를 생성하는 파이프라인의 마지막 단계로 사용하는 랜더링을 고려하면, 17ms 정도의 latency를 달성하는 것이 최고의 시나리오다.

  그러나 사후 warping은 사람이 알아볼 만한 부산물들을 수정할 수 있기 때문에, 이 파이프라인에 적합한 부분으로 다루는 것이 맞다. 우리의 예제 시스템에서 사후 warping을 위한 순방향 예측 없이 색 채널당 4ms의 물리적인 latency를 달성할 수 있었다. 그러나 4ms는 꽤 짧은 시간이기 때문에, 순방향 예측을 하는 것은 거의 완벽하고 감지된 latency를 0에 가깝게 밀어부칠 수 있다. 게다가 실제로 4ms이상에 대한 예측을 할 수 있어서 latency를 0보다 작게도 만들 수 있다. 그러나 0이하의 latency는 재미 없고 우리 시나리오에서는 맞지 않다.

 

CONCLUSIONS

 

  이 글에서 우리는 요즘 AR, VR 시스템에서의 latency를 다루는데 있어서의 도전과 접근법을 설명했다. 우리는 이런 시스템을 위해 요구되는 HW와 SW 솔루션이, latency를 덜 걱정하는 모니터 게이밍 시스템과 다르다는 것을 알게 되었다. 추가로 모바일 솔루션은 고정형 시스템보다 아주 적은 프로세싱 능력을 가지고 있다. 이 문제는 저전력, 낮은 latency 그리고 높은 처리량이라는 상충되는 요구사항을 성공적으로 해결하기 위해 DSP, FPGA 혹은 ASIC의 형태로 된 특별한 HW 블럭으로 해결된다.

  여기서 보여주고자 하는 오버 뷰는 크게 개념적인것이지만, 실제 상업용 시스템들은 여러 개의 아주 세부적인 것들을 다뤄야 한다. 표준 GPU를 LCOS에 연결하는 것부터 범용 아키텍처상의 타일을 가지고 warping하기 위해 높은 시간 정확도를 달성하는 것까지 다뤄야 한다. 비슷하게, SW쪽에도 우리가 다루지 않은 세부적인 것들이 있다. 예를 들면,

일반 응용프로그램이 낮은 latency 파이프라인의 장점을 사용할 수 있도록 하는것이다.

  필요한 표준이 부족하기 때문에, 이런 세부적인 것들은 보통 독자적인 형태로 구현되고 있다. 디스플레이와 디스플레이 프로토콜 표준화 그룹들이 AR, VR 지원을 향상시키기 위해 어떻게 확장할지를 이미 논의하고 있다. 그러나 이러한 확장이 성숙하고 상품화에 사용되려면 수년이 걸릴 것이다. 비슷하게 OpenVR과 UnityXR 같은 software가 표준화에 대한 노력을 계속하고 있다. 하지만 아직 상품화 수준까지는 미치지 못하고있다. 그때까지는 AR, VR 제조사는 자체 독자 솔루션을 계속 개발하고 향상시킬 것이다.