NVIDIA의 VR SDK, VR 다이렉트. AMD 리퀴드 VR과 무엇이 다른가?

 

 

VR을 위한 HMD는 최근 관심이 점점 높아지고 있으나, VR 컨텐츠의 경우 일부 게임 타이틀이 VR 지원을 발표하는 게 고작이며, 분위기가 뜨겁다고는 하기 어렵습니다. 대부분의 게임 개발자는 VR 컨텐츠의 개발 경험을 축적하는 단계이니 당연한 것이겠지만요.

 

이러한 VR 컨텐츠 개발자에게 VR 컨텐츠 개발에 필요한 기본적인 기능을 라이브러리나 소프트웨어 개발 키트(SDK), API 식으로 제공하려는 움직임이 보이고 있습니다. 그 중 하나가 GDC 2015에 맞춰 AMD가 발표한 VR 컨텐츠 개발용 SDK인 리퀴드 VR입니다.

 

또 경쟁 상대인 NVIDIA도 VR 다이렉트라는 VR 컨텐츠 개발용 sDK를 발표했습니다. VR 다이렉트는 VR 컨텐츠의 영상을 렌더링할 때 NVIDIA GPU의 성능을 최대한 활용할 수 있도록 해주는 SDK와 API의 총칭입니다.

GTC 2015에서는 이 VR 다이렉트에 대한 기술 해설 세션인 VR Direct: How NVIDIA Technology is Improving the VR Experience이 열렸는데 그 내용이 어떤지 간단히 소개하겠습니다.

 

 

강연은 NVIDIA에서 Developer Technology Engineer를 맡은 Nathan Reed입니다. inFamous 시리즈를 만들었던 Sucker Punch에서 그래픽 프로그래머를 맡은 경력을 갖고 있지요.

 

 

 

 

VR 컨텐츠 표시 지연의 기본 해결책. 프레임 대기 비활성화와 타임 워프

 

VR 체험에서 가장 조심해야 하는 것은 HMD를 쓴 머리의 움직임을 영상 표시가 따라가지 못해 지연이 생기는 것입니다. 일반적인 PC의 3D 게임 그래픽에선 CPU와 GPU가 각각 최대의 성능을 발휘할 수 있도록 프레임 큐잉(Frame Queuing)이란 시스템을 도입해 CPU와 GPU의 병렬 동작을 높입니다.

GPU는 CPU로부터 전송된 렌더링 명령어 배열에 따라 구동되는데, 이 렌더링 명령어 배열을 조합하는 건 CPU의 몫입니다. CPU는 각 프레임 단위로 게임 처리와 렌더링 명령을 생성하며 GPU는 그 렌더링 명령어를 바탕으로 각각의 프레임을 렌더링합니다.

 

그러나 정해진 프레임 레이트를 실현하는 데 필요한 시간 안에 항상 모든 처리를 끝내진 못합니다. 그래서 들쑥날숙한 처리 시간을 평균화하고 CPU와 GPU을 풀 가동시키기 위한 방법이 프레임 큐잉입니다. 이를 백 버퍼링과 같은 것이라고 보기도 하네요.

 

 

프레임 큐잉의 개념. 가로 축은 시간의 흐름을 나타냅니다. 프레임 큐를 다수 도입해서 프레임 N을 처리한 후 몇프레임이 지나면 영상이 표시됩니다.

 

다이렉트 X에선 백 버퍼의 수가 기본적으로 3개입니다. 이것은 입력된 데이터가 실질적인 영상 표시로 되기까지 3프레임의 지연이 생긴다는 이야기입니다. 지연은 일반적인 게임에서도 문제가 되겠지만 VR 컨텐츠에선 3D 멀미의 직접적인 원인이 됩니다.

 

사용자의 입력이나 머리의 움직임을 포함한 인터렉션 처리의 지연은 적으면 적을수록 좋습니다. 따라서 프레임 큐잉을 취소할 필요가 생깁니다. 오큘러스 VR의 HMD인 리프트용 SDK에선 프레임 큐잉이 기본적으로 취소되는데 다이렉트 X에선 컨텐츠 개발자가 IDXGIDevice1::SetMaximumFrameLatency라는 API을 사용해 취소해야 합니다.

 

 

VR 컨텐츠를 표시할 땐 프레임 큐잉을 취소할 필요가 있습니다. 프레임 큐잉을 취소하면 렌더링 파이프 라인에서 지연은 최소화할 수 있으나 이것 외에도 VR용 HMD에만 존재하는 문제도 있습니다. 사용자가 계속해서 머리를 움직이면 렌더링 시작 전에 판정한 머리 방향과 렌더링이 끝났을 때 방향이 변하는 경우가 있습니다. 이 상태에서 영상을 그대로 표시하면 HMD에 지연된 컨텐츠가 표시됩니다.

 

 

그래서 (물리적으로 정확하진 않아도) 렌더링된 영상을 머리 방향에 맞는 위치에 표시하면 머리의 움직임에 따라 앞뒤가 맞는 것처럼 보이는 영상을 표시할 수 있습니다.

 

 

예를 들어 오른쪽을 보도록 고개를 움직인다면 영상이 렌더링된 후에 목의 회전 각도만큼 영상을 왼쪽으로 돌려 HMD에 표시하는 것입니다. 영상이 왼쪽으로 스크롤하니 목의 회전 방향에 있는 화면은 제대로 표시되지 않지만, 매우 짧은 시간과 분량이라 크게 티가 나진 않을 것이라 설명합니다.

 

 

이러한 처리를 오큘러스 VR은 타임 워프라 부르며 VR 업계에서도 이 호칭을 쓰는 분위기입니다. 다만 타임 워프만으로 움직임을 추적하는 데 문제가 없는 건 아닙니다. 머리의 방향에 맞는 정확한 영상이 아니고 게임 처리에 모순이 일어날 가능성도 있기 때문입니다. 특히 GPU 렌더링이 길어지고 수직 동기화를 놓칠 경우 별도의 대처 방법을 생각하지 않으면 안 됩니다.

 

 

렌더링이 Vsync보다 늦을 경우 타임 워프는 어떻게 처리해야 하는가

 

VR 컨텐츠의 그래픽 렌더링 파이프라인을 정리하면, 머리의 방향을 검출해 GPU에서 영상을 렌더링한 후 머리 방향을 다시 검출해 타임 워프를 처리하는 식입니다.

 

영상 표시를 수직 동기화에 맞추는 게 철칙이지만 렌더링이 길어지고 수직 동기화를 놓치면 렌더링한 영상을 표시할 타이밍도 놓쳐 프레임 드롭과 함깨 Stutter 현상을 일으키게 됩니다. VR 컨텐츠는 최소한 60fps, 오큘러스트 리프트는 90fps의 프레임을 요구하기에 상당한 고성능 GPU가 아니면 현실적으로 이걸 지키긴 어렵습니다.

 

 

그래서 수직동기화의 시점에 늦지 않도록 방법을 도입해야 합니다. 그 중 하나는 Space Multiplexing의 이용입니다. 60fps에서 1프레임에 해당하는 시간은 16.67ms며 이걸 10개의 서브 프레임으로 분할하면 서브 프레임 한개의 분량은 16.67ms의 1/10분인 1.667ms입니다.

 

렌더링을 시작할 땐 해당 시점에서 머리 방향으로 3D 오브젝트를 렌더링합니다. 그리고 서브 프레임 1개 분량인 1.667ms가 지난 다음엔 1.667ms에 해당하는 타임 워프 처리를 더해 3D 오브젝트를 렌더링합니다. 그리고 1.667ms가 지날 때마다 다음 수직 동기화가 올 때까지 같은 작업을 반복합니다. 이것이 스페이스 멀티플렉싱 렌더링 개념입니다.

 

이렇게 보면 괜찮은 방법 같습니다. 그러나 그래픽을 렌더링하는 족족 바로 표시할 수 있는 디스플레이라면 몰라도 영상을 표시하는 타이밍이 Vsync에 따라 정해지는 지금의 디스플레이 디바이스(VR HMD도 포함)에선 맞지 않다는 게 NVIDIA의 견해입니다.

 

 

그래서 나온 다른 방법이 Time Multiplexing입니다. GPU를 최대한 사용해 영상을 렌더링하고 Vsync 직전에 렌더링을 마친 영상을 대상으로 GPU에서 타임 워프 처리를 적용한다는 발상입니다.

 

현재 진행 중인 렌더링이 끝나지 않았을 경우 지금 표시된 프레임을 대상으로 타임 워프 처리를 적용한다는 것이 포인트입니다. 영상 내용은 이전 프레임과 변하지 않지만 타임 워프 처리가 적용되니 시간축의 흐름에 따라 앞뒤가 맞을 것이고 명확한 딜레이가 노출되는 것보다는 낫다는 논리입니다.

 

 

그리고 Vsync 이후에 프레임 렌더링이 끝나면 바로 타임워프 처리해서 일시적으로 Vsync를 쓰지 않는 상태로 표시합니다. 이 때 티어링이 생길 수 있지만 타임워프 처리한 동일 시간 축의 영상이 표시되니 티어링 현상은 최소화할 수 있으며 눈에 잘 띄지 않습니다. 영상의 움직임이 적은 배경의 표시에선 티어링이 거의 보이지 않겠고, 보인다 해도 움직임이 많은 부분에 그칠 것입니다.

 

NVIDIA의 VR 다이렉트는 이 타임 멀티플렉싱을 타임 워프 처리에 사용했습니다. 영상 렌더링은 비동기 방식으로 타임 워프를 처리하기에 정식 명칭은 Asynchronous Timewarp가 됩니다.

 

사실 이는 AMD의 리퀴드 VR이 사용한 방식과 거의 같으며 이름 역시 그러합니다. NVIDIA와 AMD 중 누가 먼저 이 방법을 썼을지는 모르지만, 오큘러스 VR에서 이렇게 타임 워프를 구현해 달라고 요청을 했다 하니 거기에 따른 것일듯 합니다.

 

 

AMD와 NVIDIA가 서로 다른 비동기 타임 워프 처리 구현 방법

 

흥미로운 건 NVIDIA의 VR 다이렉트와 AMD의 리퀴드 VR이 타임 멀티플렉싱 기법에 의한 타임 워프 처리의 구현 기법이 다르다는 겁니다. 리퀴드 VR에선 AMD GCN 라데온이 그래픽 렌더링 태스크와 GPGPU 태스크를 동시에 병렬 처리할 수 있어, 영상 렌더링은 그래픽 렌더링 태스크에서, 타임 워프 처리는 GPGPU 태스크에서 처리합니다.

 

반면 NVIDIA의 GPU는 그래픽 렌더링 태스크와 GPGPU 태스크를 동시에 실행할 수 없다는 제약이 있습니다. 이는 최신인 맥스웰 아키텍처에서도 마찬가지로 모드 변화를 해가며 그래픽 렌더링 태스크와 GPGPU 태스크를 바꾸지 않으면 각각의 태스크를 실행할 수 없습니다. 즉 AMD의 리퀴드VR처럼 쓰진 못합니다.

 

 

그래서 NVIDIA의 VR 다이렉트는 GPGPU 태스크를 활용하지 않고 그래픽 렌더링 모드로 영상 렌더링 태스크와 타임 워프 처리 태스크를 실행합니다. 우선 영상 렌더링 태스크는 평범한 장면 렌더링을 처리합니다. 그리고 그래픽 렌더링 모드에서 Vsync 타이밍이 오면 우선 순위가 높은 타임 워프 작업을 처리합니다. 

 

태스크의 변환 처리인 컨텍스트 스위치에 따라 오버헤드가 있지만 그전까지 하던 영상 렌더링 작업을 일시 중단하고 타임 워프를 처리하는 태스크로 바꿀 수 있습니다. 즉 GPU가 프리엠프티션 멀티 태스킹 처리로 타임 워프를 실행하는 것입니다. 이렇게 실행된 타임 워프 처리 태스크는 프론트 버퍼의 영상을 대상으로 머리 방향 상태를 반영해 타임 워프 처리를 합니다.

 

 

이러한 타임 워프 처리의 실행에는 High-Priority Context라는 기능을 씁니다. 해당 시점에서 GPU가 하던 작업을 중단해서라도, 나중에 시작된 새로운 작업을 우선해서 실행하는 기능이며 이 구조를 사용해 타임 워프 처리를 실행하는 것입니다. 이것이 NVIDIA GPU에서 비동기 타임 워프 처리의 핵심입니다

 

 

이 기능은 페르미 아키텍처 이후의 NVIDIA GPU에 탑재됐으나 지금까지 공개하진 않았다네요. 전환 시점은 렌더링 명령화가 끝난 다음이기에 아직까진 NVIDIA GPU의 한계라고 할 수 있습니다. 렌더링 커맨드 라인이 길 경우 타임 워프 처리를 하는 데 오랜 시간동안 기다려야 하니 적절한 타이밍에 처리할 수 없다는 단점이 있습니다. 앞으로 나올 GPU에선 렌더링 중 아무때나 태스크 전환을 할 수 있을 것이라 하네요.

 

 

High-Priority Context 기능은 현재 출시된 드라이버 소프트웨어에서 시용할 수 있으며 다이렉트 X와 오픈 GL 모두 쓸 수 있습니다.

 

 

특히 오픈 GL은 테그라 K1이나 테그라 X1에서도 사용할 수 있습니다. 

 

 

여기서 컨텐츠 개발자가 조심해야 할 점도 설명했습니다. 비동기 타임 워프 처리는 어디까지나 최악의 사태를 피하기 위한 보험이니, 여기에만 의존하지 않고 영상 렌더링을 수직 동기화에 맞춰 설계해야 한다는 것입니다.

 

 

또 비동기 타임 워프 처리는 High-Priority Context 기능의 태스크 전환에 의존하고 있으며 렌더링 명령이 끝난 시점에만 태스크 전환이 가능하니, 렌더링 명령이 정기적으로 종료되는 레이아웃 엔진을 써야 한다는 것도 꼽았습니다. 구체적으로는 1ms마다 렌더링 명령이 끝나는 게 좋다네요. 다만 정기적으로 렌더링 명령이 종료되도록 설계하는 건 현실적으로 어렵습니다. 타일 베이스 렌더링을 쓰는 게임 엔진이라면 쉽겠지만요.

 

 

VR 컨텐츠에서 멀티 GPU를 활용하는 기술. VR SLI

 

AMD의 리퀴드 VR은 VR 컨텐츠의 영상 렌더링을 할 때 멀티 GPU를 효율적으로 활용하기 위한 기능인 Affinity multi-GPU가 탑재됩니다. NVIDIA VR 다이렉트에서 이에 해당하는 기능은 VR SLI입니다. Affinity multi-GPU에 비해 기능이나 특징은 별 차이가 없으니(http://gigglehd.com/zbxe/12658832) 여기선 간단히 소개하겠습니다.

 

 

2D 컨텐츠(게임 포함)의 영상 렌더링에서 가장 효율적인 멀티 GPU 활용법은 여러 GPU가 각각 1프레임의 영상을 렌더링하는 AFR(Alternative Frame Rendering) 방식입니다. 짝수 프레임을 GPU0, 홀수 프레임을 GPU1이 렌더링하는 방식입니다. 그러나 VR 컨텐츠는 지연을 가급적 배제하기 위해 1개의 프레임을 최대한 빨리 렌더링하려 합니다. 그래서 GPU0을 왼쪽 눈, GPU1이 오른쪽 눈을 맡도록 렌더링하는 방법이 등장했습니다.

 

 

다만 각각의 좌우 영상은 같은 장면을 같은 시점에 약간 다른 각도로 보고 있는 것이기에 렌더링해야 하는 장면 정보는 2개의 GPU가 같습니다. 그래서 나온 방법이 렌더링하려는 장면의 정보와 눈의 위치, 방향을 전달해 자동으로 2개의 GPU가 각각의 눈에 따라 영상 렌더링을 하는 방법입니다. 렌더링된 영상은 PCI-E로 전송하고 시각과 상관 없는 처리는 자동으로 복제돼 효율이 높아집니다.

 

 

아직까진 다이렉트 X 11에서만 지원하지만, 앞으론 오픈 GL과 벌칸에서도 지원할 것이라 합니다. 이 역시 지원하는 GPU는 페르미 이후에 나온 것만.

 

 

크라이엔진은 VR 다이렉트도 지원

 

 

다음은 크라이텍의 리드 프로그래머인 Dario Luis Sancho Pradel이 등장해 자사의 게임 엔진인 크라이엔진이 리퀴드VR 외에 VR 다이렉트도 지원한다고 밝혔습니다.

 

 

VR 다이렉트와 리퀴드 VR에는 기능의 구현 방법에 약간의 차이는 있으나 최종적으로는 거의 같은 기능을 제공합니다. 즉 VR 컨텐츠 개발자가 어느 한쪽에만 맞추면 다른 쪽으로 이식도 쉽다고 하네요. 현재 주요 게임 엔진은 이들 두가지를 모두 지원할 것입니다.

 

 

그리고 OpenGL의 표준화를 담당하는 Khronos Group의 대표이자 NVIDIA 모바일 에코시스템 부문의 부사장이기도 한 Neil Trevett에게 VR 컨텐츠용 API의 표준화 계획에 대해 문의한 결과, 아직까진 존재하지 않는다고 답했습니다. 이유는 간단합니다. 아직 이르다는 것.

 

VR 컨텐츠 산업은 아직 충분히 발전하지 않았으며 VR 하드웨어나 VR 컨텐츠의 개발도 활동 실체가 명확하지 않습니다. 또 하드웨어와 소프트웨어의 경험도 축적되지 않아 현 시점에서 API 스펙을 책정해도 의미가 없다는 이야기입니다. Imagination Technologies가 제창한 프로그래머블 레이 트레이싱 API인 OpenRT가 공개 표준으로 삼기에 시기 상조인 것과도 같은 이유입니다. VR은 많은 발전을 이루고 있으나 아직 관련 산업은 시작일 뿐입니다. 

 

 

간단하게 즐길 수 있는 VR 컨텐츠, 360도 비디오를 저렴하게 제작/전달하는 시스템

 

 

이처럼 올해들어 여러 VR 기기가 등장하고 있습니다. 오큘러스 VR의 리프트, 소니의 프로젝트 모피어스, 밸브의 스팀 VR, OSVR 등등. 허나 중요한 건 컨텐츠입니다. GDC 2015에선 여러 업체들이 영화 수준의 품질을 갖춘 VR 컨텐츠를 공개했지만, 이런 VR 컨텐츠를 개발하는 데 상당한 비용이 필요한다면 여러가지로 힘들겠지요.

 

 

물론 그러한 우려와 불안을 줄이기 위한 툴도 제작되고 있습니다. GTC 2015에선 프랑스에서 영상 제작 도구를 개발하는  VideoStitch가 저렴하게 만들 수 있는 VR 컨텐츠인 360도 파노라마 동영상에 대해 설명하는 강연, The Future of Video is VR. And it is Now를 발표했습니다. 강연을 담당한 사람은 CEO인 Nicolas Burtey입니다.

 

 

VR HMD의 완성형은 스마트폰을 장착한 모바일 VR?

 

 

우선 소비자가 VR 컨텐츠를 즐기는데 높은 장벽이 있다고 지적했습니다. 풍부한 VR 컨텐츠를 경험하기 위해선 나름대로 비싼 VR HMD를 구입할 필요가 있고, 여기에 고성능 PC나 게임기까지 이어야 한다는 거지요.

 

 

현재 주류 VR HMD는 액정 패널이나 OLED 디스플레이 패널을 확대 광학계를 통해 들여다보는 구조입니다. 그렇다면 디스플레이를 스마트폰으로 대체해서 광학계를 조합하면 비슷하게 만들 수 있겠지요. 실제로 이 아이디어를 바탕으로 만든 것이 삼성 전자의 기어 VR입니다.

 

 

스마트폰에는 가속도 센서나 자이로스코프가 탑재돼 머리를 중심으로 하는 시점의 이동이나 각도를 검출할 수 있습니다. 정밀한 연산이나 성능은 논외로 쳐도 VR HMD를 구성하는 최저한의 하드웨어 요건은 갖추고 있습니다. VR 컨텐츠를 표시하는 연산 성능도 최신 게임 PC나 콘솔 게임기 수준까진 아니지만 10년 전의 콘솔보다는 고성능이며 절대적인 성능은 나름대로 높습니다.

 

따라서 1년에 12억대가 판매되는 스마트폰이야말로 캐주얼한 VR 컨텐츠를 실행하는 데 최적이며, 앞으로 주류가 될 VR 디바이스는 기어 VR처럼 스마트폰 기반 HMD, 즉 모바일 VR이 될 것이라 보고 있습니다. 이것은 오큘러스 VR의 존 카맥 CTO도 갖고 있는 생각입니다.

 

이런 캐주얼 모바일 VR 디바이스용 VR 컨텐츠로 적합한 것이 주위 360도의 풍경을 촬영한 동영상 컨텐츠, 360도 비디오라는 게 이 강연이 주제입니다. 360도 동영상 자체는 2D 비디오 스트림이라 3D 그래픽에서 머리의 움직임에 따라 렌더링하는 것에 비해 처리 부하는 낮습니다. 영상으로 둘러싸인 VR 체험을 간단히 즐기는 게 목표라면 360도 비디오와 모바일 VR 디바이스는 정말 최적의 조합일지도 모르겠습니다.

 

 

360도 동영상의 제작/배포 솔루션

 

 

360도 동영상에 대한 VR 업계의 기대는 큽니다. 유튜브는 2015년 3월부터 360도 동영상 전송을 시작했습니다. 최근에는 360도 동영상 촬영 솔루션의 발표도 있다르며 360도 동영상에 대한 기대감이 2010년의 3D TV 열기보다 더 크다는 이야기도 있습니다.

 

 

VideoStitch에서는 360도 동영상 제작 소프트웨어인 VideoStitch Studio를 제공합니다. 최대 6부분으로 촬영된 비디오 스트림을 공 안에 투영하는 식의 느낌을 주는360도 비디오 스트림으로 변환하는 도구입니다. 각 비디오 스트림에서 중복 촬영된 부분을 검출해 프레임 단위로 깔끔하게 연결하는 것이 특징입니다. 무료 버전에선 1024x512 해상도의 360도 동영상을 만들 수 있으며 유료 버전은 무제한입니다.

 

촬영 방향이 다르면 화면의 노출이 달라지고 비디오 스트림의 색체와 계조가 달라질 수도 있습니다. 하늘을 향한 카메라는 노출을 줄여 촬영할 것이고 땅을 향한 카메라는 노출을 높이려 하겠지요. 또 움직이는 물체에 설치된 카메라는 영상이 흔들리 수 있으나, 카메라가 향한 방ㅇ향으로 움직인다면 떨림이 덜할 것입니다. VideoStitch Studio는 이러한 영상 스트림의 색감, 그라디에이션, 흔들림 차이를 조절하는 기능도 있습니다.

 

 

또 한가지 동영상의 라이브 스트림에 사용할 수 있는 Vahana VR도 소개했습니다. 이것은 여러 방향을 향한 다수의 카메라로 촬영된 영상을 대상으로 VideoStitch Studio의 색감/계조 보정과 흔들림 조절을 실시간 적용해 바로 인터넷으로 전송하는 프로그램입니다. 이걸 응용하면 지금까지 볼 수 없었던 실시간 영상 컨텐츠를 전송할 수 있다고 설명합니다.

 

 

예를 들어 경기장에 이걸 설치한다고 생각해 봅시다. 운동장 상공에 360도 촬영 카메라를 설치하면 공중에서 경기를 관전할 수 있고, 벤치나 코칭 스텝의 자리에 설치하면 그라운드의 경기를 교체 선수나 감독의 관점에서 볼 수 있습니다.

 

 

콘서트나 극장에 설치하면 무대 위의 출연진과 같이 호흡을 맞추는 느낌도 낼 수 있겠지요. 출연자가 자신에게 말을 거는 느낌을 즐길 수 있을지도 모르죠. 

 

 

360도 촬영 카메라를 자유롭게 이동할 수 있는 로봇에 탑재하면 시점을 움직일 수도 있습니다. 스포츠나 극장/공연 감상에서 돈을 더낸 사람은 자유로운 카메라를 볼 수 있도록 한다면 비즈니스에서 유리할 수도 있겠지요.

 

GTC에서 나온 강연이다보니 NVIDIA의 GPU를 소개하지 않을 수 없겠는데요. Vahana VR 시스템은 지포스 GTX 980을 탑재한 PC에서 실행되며 CUDA를 사용해 60프레임의 풀 HD 비디오 스트림 6개를 처리해서 4096x2048 해상도로 출력하는 파이프라인을 구축했다고 합니다.

 

 

강연 회장에서 선보인 Vahana VR의 데모

 

 

행사장의 모습을 VR로 본다고 해도 별로 재밌진 않겠지만 그래도 Vahana VR이 갖는 잠재력은 전달된 것 같습니다.

 

 

VR체험을 즐길 수 있는 건 아니지만 360도 비디오의 분위기를 웹 브라우저에서 체험할 수 있는 데모가 VideoStitch 공식 웹 사이트(http://www.video-stitch.com/360-video-gallery/)에 있습니다. 영상을 재생하고 마우스로 시각을 움직이며 볼 수 있습니다.

 

 

사용자가 VR 컨텐츠를 쉽게 만들 수 있는 시대가 올까?

 

VR HMD가 3D TV와 다른 건 3D TV가 어디까지나 평면 화면에서 입체감을 표현하는 데 비해, VR HMD는 영상 속에 들어가는 감각을 체험할 수 있는 것입니다. 360도 비디오는 아직까지 인터랙티브란 특징은 없으나 최소한의 VR 하드웨어로 캐주얼하게 즐길 수 있는 VR 컨텐츠라는 게 높은 가치가 있습니다.

VideoStitch Studio와 Vahana VR 같은 소프트웨어를 활용하면 사용자도 360도 비디오 VR 컨텐츠를 비교적 쉽게 만들 수 있으니 앞으로 확대도 기대할 수 있습니다. 보다 수준 높은 데모는 8월에 열리는 SIGGRAPH 2015에서 있을 것이라 합니다.

 

 

또 360도 동영상 촬영이 가능한 카메라도 나오고 있습니다. 기존에는 고프로 같은 소형 카메라를 여러대 사용해 영상을 합쳤지만, 리코가 판매하는 360도 카메라 THETA처럼 한손으로 들 수 있는 크기이면서 360도 동영상 촬영을 할 수 있는 소형 카메라가 등장, 하드웨어와 소프트웨어에서 보급이 촉진되고 있습니다. 앞으로는 사용자들이 VR 컨텐츠를 제작하는 일도 늘어날 것입니다.

 

 

레이턴시가 낮은 클라우드 게임 서비스를 실현하는 NVIDIA GRID

 

 

이번에는 VR 말고 다른걸 봅시다. 최근 서비스 지역을 점점 늘리고 있는 NVIDIA의 게임 스트리밍 서비스 기술, NVIDIA GRID입니다. 여기에선 그리드 자체의 소개보다는 GTC의 강연 내용에 대해 보도록 하겠습니다.

 

 

게임 컨트롤러부터 서버의 인코딩까지 철저하게 낮은 레이턴시를 추구

 

 

Eric Young(Engineering Manager for Developer Technology on GRID, NVIDIA)이 나와 Cloud Gaming and NVIDIA GRID란 이름으로 세션을 열었습니다.

 

 

NVIDIA가 왜 그리드를 사용하는 클라우드 게임 서비스에 공을 들이는 것일까요. 그 이유로 콘솔 게임기보다 3배나 고성능인 PC용 GPU 기반 기술임을 꼽았습니다. 지난 10년 동안 콘솔 게임기의 성능은 PC를 넘어선 적이 없으며, 그리드를 사용하면 높은 수준의 그래픽을 지닌 게임을 저렴하고 편하게 플레이할 수 있다는 게 NVIDIA의 주장입니다.

 

 

또 성능 외에 다른 장점도 꼽았습니다. 게임 업데이트가 쉽고 불법 복제가 없다는 건 게임 개발자와 퍼블리셔에게 있어 큰 장점이 됩니다.

 

 

하지만 인터넷을 통해 플레이하는 클라우드 게임 서비스는 입력에 의한 지연 문제가 존재합니다. 이걸 없애는 것이 그리드의 역할이지요. 예를 들어 NVIDIA의 안드로이드 태블릿인 쉴드 태블릿이나 3월 초에 발표한 안드로이드 TV인 쉴드는 무선 게임 패드인 쉴드 무선 컨트롤러를 연결하는데 블루투스가 아니라 지연이 더 낮은 Wi-Fi 다이렉트를 씁니다. 또 통신 대역폭이 넓어 게임 패드로 사운드를 전송하는 것도 가능하다고.

 

 

쉴드와 NVIDIA 그리드를 조합한 클라우드 게임 서비스라면 눈을 깜박이는 것의 절반 정도밖에 지연이 없다고 설명합니다. 클라우드부터 게임 패드까지 모든 부분에서 지연을 낮춘 것이 NVIDIA 그리드 기반 클라우드 게임 서비스의 특징입니다.

 

 

입력 조작이 화면 표시까지 반영될 때까지의 전체 지연을 콘솔 게임기와 NVIDIA 그리드에서 측정해 비교한 것입니다. 입력 데이터를 받는 시간이 0이고, 네트워크의 지연이 30ms라는 건 이상적인 조건입니다. 거꾸로 말하면 네트워크가 빠를 경우 이 정도로 클라우드 게임이 가능하다는 것입니다. 입력에서 표시까지 8프레임의 지연이 있던 게임이 9+a프레임이 된다고 해도 큰 체감 차이는 없다는 이야기. 또 핑 값 60ms까지 더하면 최악의 경우라 해도 2프레임 미만의 지연이 더해지는 수준으로 끝납니다.

 

 

NVIDIA 그리드는 서버의 GPU에서 게임 영상을 인코딩하는데 여기에도 지연을 낮추는 방법이 들어갑니다. NVIFR이 비디오 메모리에 있는 렌더 타겟을 직접 포착해 하드웨어 인코더인 NVENC가 H.264 스트림으로 인코딩하는 구조입니다.

 

 

낮은 지연 시간을 지원하는 비디오 스트리밍 기술

 

The Technology Behind NVIDIA GRID Game Streaming란 제목의 세션에서는 NVIDIA 그리드에서 쓰이는 네트워크 기술을 소개했습니다. 그 중에서도 Bojan Vukojevic가 설명한 스트리밍 부분을 소개하고자 합니다.

 

 

이 슬라이드는 NVIDIA 그리드와 클라이언트의 접속을 나타낸 그림입니다. 클라이언트와 NVIDIA 그리드가 게임과 스트리밍 세션에서 연결되면 그리드에서 비디오와 오디오 스트림이 송출되고, 클라이언트는 입력 데이터와 함께 QoS(Quality of Service) 데이터를 그리드로 보내는 구조입니다. 비디오와 사운드는 서로 독립된 스트림인데, 이는 딜레이를 낮추는 방법이 달라서 그렇다고 합니다.

 

클라우드 게임 서비스는 네트워크의 상황을 알기 어렵다는 데 문제가 있습니다. 패킷 로스나 대역폭의 갑작스런 변화 때문입니다. 그래서 비디오 스트리밍 기술에는 대역폭에 맞춰 영상의 비트 레이트를 동적으로 변화하는 방법이 있으며 NVIDIA 그리드도 그걸 갖추고 있지만 갑자기 대역폭이 달라지면 비트레이트 변경이 맞지 않아 영상이 끊길 수 있습니다. 그래서 그리드 시스템은 클라이언트에서 대역폭의 변화를 예측해 계산해서 QoS 데이터로 NVIDIA 그리드에 보내는 구조를 씁니다. 다만 어떻게 대역폭을 예측하는지는 자세히 설명하지 않았습니다. 정확도가 높다고만 했네요.

 

 

대역폭 예측을 했을 경우와 그렇지 않았을 경우의 대역폭 변화를 나타낸 그레프입니다. 비트레이트의 변화가 어떻게 이루어지는지를 본 건데요. 하늘쌕이 네트워크 대역폭, 회색이 예측을 하지 않았을 경우, 초록색은 예측했을 경우의 비트레이트입니다. 이 상황에서 네트워크 대역폭이 갑자기 떨어지면 일시적으로 비트레이트가 네트워크 대역폭을 넘어 영상이 버벅거리지만, 예측 계산을 바탕으로 비트레이트를 변화하면 그런 일은 없습니다.

 

 

 

비디오 스트림의 패킷 손실에도 대비했습니다. 드롭된 프레임은 키 프레임을 만들어 중단된 비디오 스트림을 빠르게 복구합니다. 위 슬라이드에서 프레임 2개 패킷 로스로 드롭됐을 경우 클라이언트는 그걸 감지해서 그리드에게 다음 키프레임을 송출하도록 QoS 데이터로 요청합니다. 그리드는 다음 인코딩 타이밍에 해당되는 프레임 6을 새 키 프레임으로 하는 비디오 스트림을 클라이언트로 보냅니다.

 

왜 새로운 키 프레임을 보내나 하면 도중에 빠진 프레임이 있을 경우 프레임 사이의 차이를 나타내는 정보만으론 화면을 구성할 수 없기 때문입니다. 클라이언트 쪽에서 보면 드롭된 프레임 2에서 새로운 키 프레임 사이에 있는 프레임 2, 3, 4, 5까지의 4프레임은 영상이 멈춘 상태이며 프레임 6이 왔을 때 새로운 게임이 진행되는 것처럼 보이지만, 최소한 프레임 6 이후에는 스트림이 정상적으로 흐르게 됩니다.

 

프레임이 스킵된 사이에 공격을 받거나 중요한 아이템을 놓치면 게임하면서 짜증이 나겠지요. 허나 패킷 손실이 생겼을 때 드롭된 프레임을 새로운 키 프레임으로 일일이 재전송하면 게임 진행의 영상 지연이 점점 축적됩니다. 그래서 NVIDIA 그리드는 비디오 스트림을 빠르게 복구하는 걸 중시했습니다.

 

 

오디오의 경우 비디오와 다르게 2가지 방법으로 패킷 로스를 대처합니다. 하나는 클라이언트의 데이터 복구 기능을 사용해 소리를 복원하는 것이며, 다른 하나는 10밀리초 단위로 압축한 사운드 패킷을 Adaptive Jitter Buffer에 저장했다가 거기서 클라이언트에 스트림으로 전송합니다. 클라이언트에서 사운드의 지연이나 끊김을 검출하면 그걸 QoS로 그리드에 보내 Adaptive Jitter Buffer의 크기를 조절합니다.

 

자세한 설명은 없었으나 회선 상황이 나빠 사운드가 끊기거나 품질이 떨어진다면 송신/수신 버퍼를 늘리는 일이 아닌가 보입니다. 통신 상황이 나쁘면 10ms 단위의 지연도 추가됩니다. TCP/IP의 윈도우 컨트롤과 비슷하지 싶습니다.