Author : Daeguen Lee

(Any action violating either copyright laws or CCL policy of the original source is strictly prohibited)

 

 

 

지난 금요일(3.27), AMD에서 가상현실 기술 <LiquidVR> 및 자사의 다양한 소프트웨어 기술 업데이트를 설명하는 자리가 있었습니다. 글로벌 마케팅담당 이사인 사사 마린코비치(Sasa Marinkovic) 및 소프트웨어 전략총괄 테리 마케돈(Terry Makedon)이 방한하여 LiquidVR, FreeSync, Async Shader 등 여러 토픽에 관한 프리젠테이션을 진행했는데, 거기서 공유된 내용을 독자 여러분께도 자세히 소개해 드리려 합니다.

 

 

 

우선 요즘 뜨거운 감자로 부상하고 있는 AMD의 프리싱크입니다.

아시다시피 프리싱크는 VESA 표준인 <Adaptive Sync> 라는 기술로 표준화되어, 모든 모니터 제조사가 자유로이 채택할 수 있게 되었습니다.

Adaptive Sync와 프리싱크는 본질적으로 동의어로, Adaptive Sync 표준을 채택하고 AMD가 이를 '확인'한 제품에 프리싱크 타이틀을 달아 주는 시스템입니다.

 

 

 

테어링(tearing : 찢어짐)이 발생하는 원인과 이를 방지하기 위한 수직동기화(VSync 또는 Vertical Sync)의 메커니즘을 설명하고 있습니다.

수직동기화는 일정한 주사율에 맞춰 프레임 출력을 고정하는데, 프레임의 렌더 시간이 한 주사주기를 초과하는 경우 한 주기를 더 쉬어야 하는 문제가 있습니다.

이러한 경우가 반복될 경우 사람은 '버벅거린다'고 느끼게 되며, 이를 스터터링(stuttering)이라 합니다.

 

본질적으로 테어링이나 스터터링이 발생하는 원인은, 그래픽카드가 프레임을 렌더하는 것과 모니터가 화면 정보를 갱신하는 것이 완벽히 일치하지 않기 때문입니다.

따라서 모니터의 갱신 주기를 그래픽카드의 프레임 렌더 완료시점에 일치기시키 위한 그래픽카드 제조사의 시도가 최근 여러 각도에서 있어 왔으며,

큰 틀에서 엔비디아의 G-Sync와 AMD의 프리싱크 역시 이러한 "같은 목표"를 이루기 위한 다른 접근법이라 할 수 있겠습니다.

 

 

 

프리싱크의 원리를 간단히 설명한 것입니다. 기존의 디스플레이에서 주사(refresh) 주기가 일정한 간격으로 고정된 반면, 프리싱크를 지원하는 디스플레이는 프레임이 완성되는 시점에 맞춰 주사를 갱신하도록 되어 있습니다. G-Sync는 이를 별도의 모듈이 관장한다는 점과, 프리싱크는 별도의 모듈 없이 구현된다는 점이 차이점입니다.

 

 

 

별도의 하드웨어도, 폐쇄적인 표준도, 라이선스 비용도 들지 않는다는 프리싱크의 특징을 설명하고 있습니다.

 

 

 

 

 

 

 

프리싱크를 지원하는 디스플레이들입니다. 삼성과 LG가 가담했으니 곧 상당수의 디스플레이가 프리싱크를 지원하게 될 것으로 보입니다.

 

 

디스플레이쪽보다도, 오히려 지원하는 그래픽 하드웨어가 다소 한정되었단 느낌이 듭니다. GCN 1.1 이후의 그래픽카드 및 카베리 이후의 APU들만 지원하며, 따라서 GCN 1.0인 '타히티' / '핏케언' 등은 프리싱크를 지원하지 못합니다.

 

 

G-Sync와 주요한 차이점을 나열해 둔 것입니다. 라이선스 비용 유무 및 퍼포먼스 패널티가 가장 큰 차이라 할 수 있겠습니다.

 

 

 

사실 G-Sync의 퍼포먼스 패널티도 큰 편은 아니나, 오버헤드가 있고/없고의 차이가 중요한 것이라는 마린코비치 이사의 설명이 덧붙었습니다.

 

 

또한 G-Sync는 디스플레이의 수직동기화 기술과 상호대체적인 관계로, G-Sync가 수직동기화를 '대신해' 적용되게 되는 반면 프리싱크는 수직동기화와 별도로 적용되거나 서로 중첩되어 적용하는 것이 가능합니다. 위 슬라이드는 수직동기화와 함께 선택적으로 적용했을 때 얻을 수 있는 이득을 설명하고 있습니다.

 

 

마지막으로 요약해 봅시다. 게임이 부드럽게 출력되며 / 저렴하고(=라이선스 비용, 별도의 하드웨어 등이 없으므로), 표준규격이 열려 있고 당장 사용할 수 있습니다.

 

다음으로 AMD의 가상현실 기술인 LiquidVR에 관해 알아봅시다.

 

 

 

 

LiquidVR의 구호는 'Pursuit of Presence'. 존재로의 추구, 현실로의 추구 등으로 생각할 수 있겠습니다. 이러한 추구 자체는 오래 전부터 컴퓨터가 지향해 오던 것이기도 하죠. 과거로부터 현재에 이르기까지, '존재' 또는 '현실'을 가상으로 구현하기 위해 어떤 방편들이 취해졌는지 간단히 짚어 주고 있습니다. 기초적인 2D/3D 렌더링에서부터 쉐이더 개념의 도입, 물리엔진에 기반한 렌더링을 거쳐 오늘날의 VR에 이르고 있습니다.

 

 

더 나아가서는, 극사실적인 화질이 뒷받췸되는 상위 계층의 VR을 거쳐 '모든 감각'을 재현할 수 있는 형태로까지 나아가려 합니다.

 

 

모든 감각의 구현을 위해서는 결국 확장성 있는 GPU, CPU, 가속기를 필요로 하게 됩니다.

 

 

 

제가 하고 싶은 말이 슬라이드에 쓰여 있군요.

"그래서, 어떻게 할 수 있죠?"

 

AMD는 VR 구현을 위해 몇 가지 규칙을 제시합니다.

 

 

그 첫번째는 현실을 방해하지 않을 것. 다시 말해 레이턴시가 낮은 것은 물론, 3D멀미 등 여러 '불편한' 요소들을 제거하는 것입니다.

 

 

불편한 요소 제거를 위해 위와 같은 수단 & 절차가 동원됩니다.

 

 

 

그리하여, AMD의 가상현실 기술인 LiquidVR은 다음과 같은 3가지 목표를 지향합니다 : 편안함(위에서 말한 '불편함' 요소들의 제거를 의미합니다), 호환성, 그리고 매력적인 컨텐츠. 첫번째 목표인 편안함은 낮은 레이턴시 등을 통해 3D멀미를 예방하는 것에 가장 큰 초점이 맞춰져 있고, 직관적이고 편리한 사용법을 통해 두번째 목표를 충족하며 고성능 렌더링 솔루션을 갖춤으로써 매력적인 (여기서 매력이란, 콘솔의 '킬러 타이틀' 같은 매력적인 내러티브라기보다도 그래픽이 매력적이라는 뜻으로 생각해야 할 듯 합니다.) 컨텐츠를 구동할 힘을 예비하게 됩니다.

 

 

LiquidVR 1.0 SDK는 다음과 같은 특징들을 포함합니다. 나머지는 가볍게 보시되, 두번째의 Asyncronous Shader는 특별히 중요한 내용이니 뒤에 다시 설명하겠습니다.

 

 

 

 

 

 

 

(이상은 Async Shader를 제외한 나머지 세 특징에 관한 설명들입니다. 곧 업데이트하도록 하겠습니다)

 

 

오늘의 숨겨진 주인공 격인 Async Shader.

 

 

오늘날의 GPU들은 사실 자신들의 완전한 성능을 다 발휘하지 못하고 있다는 문제의식에서 출발합니다.

 

 

Synchronous한 작업과 Asynchronous한 작업이 어떻게 다른지를 설명하고 있습니다. 싱크로너스 작업은 "모든 작업이 하나의 큐에 축적되어, 미리 정해진 순서에 따라 수행되는" 종류를 일컫고 어싱크로너스 작업은 복수의 큐, 순서 상관없이 수행할 수 있는 유형을 의미합니다. 아주 러프하게 보아 in-order와 out-of-order의 차이라 볼 수 있겠습니다.

 

 

오늘날의 게임 엔진에 사용되는 작업 '큐'의 예시입니다. 간단히 보아도 3개의 큐가 동원되어 있으니, '싱크로너스'한 연산장치만으로 여기 대응하기 어려운 것은 명약관화합니다.

 

 

 

여기서 갑자기 튀어나온 하와이의 블럭 다이어그램. 보통은 CU(컴퓨트 유닛)가 몇 개, ROP가 몇 개 정도만 생각했을 위 그림에서, 오늘의 주인공은 바로 맨 윗줄에 자그마하게 자리잡은 'ACE', 어싱크로너스 컴퓨트 엔진입니다.

 

사실 ACE는 그간 GPU 구조를 분석할 때 등한시되어왔던 게 사실입니다. 통상적인 '그래픽 성능' 은 중앙의 그래픽 커맨드 프로세서를 거쳐 발휘되기 때문입니다. 이 대목에서 마린코비치 이사는 그래픽 커맨드 프로세서가 렌더 백엔드를 관장하고, ACE는 연산을 관장한다고 설명했습니다. 즉 지금 논하고자 하는 GPU의 연산에 있어서 ACE의 역할은 매우 중요합니다. GPU의 연산을 여기서 다루는 이유는, 앞에서부터 쭉 언급했지만 가상현실 구현에 많은 연산이 요구되기 때문이죠.

 

 

만약 GPU가 하나의 큐만 다룰 수 있다면, 여러 큐가 입력될 때 마치 신호등처럼, 순차적으로 한 큐씩 교대로 입력받아야 합니다. 이 방식은 가장 느릴 뿐만 아니라, 큐 사이의 상호의존성이 얽힌 경우 (예컨대 A큐 다음에 입력되는 B큐의 연산값에 따라 A큐의 향후 진로가 달라져야 하는 경우라면) 지극히 비효율적인 면모를 보이게 됩니다.

 

 

그래서 임시적으로 이를 해소할 수 있는 것이 Preemption(선점) 입니다. 한 큐가 점유 중인 동안이라도, 긴급한 우선순위를 갖는 큐가 발생할 경우 잠시 순서를 미뤄 두고 급한 큐를 먼저 통과시키는 방식입니다. 그렇지만 이 방식 역시 전체적으로 큐의 움직임이 경직되어 있기는 다를 바가 없습니다.

 

이쯤에서 눈치채셨겠죠. 그래서 전면적인 유연성을 보장하는 Async Shader가 도입됩니다.

 

 

GCN 아키텍처는 ACE 엔진을 통해, 여러 명령어 스트림을 병렬적으로 수행할 수 있습니다. 이러한 병렬 처리의 장점을 극대화시키는 것이 Async Shader의 요지입니다.

 

 

샘플 SDK를 통해 측정해 본 결과, Async Shader를 활성화하자 후처리(주 : 안티알리아싱)의 오버헤드가 거의 없어졌습니다. 수치로 나타내자면 46%가량 된다고 합니다.

 

 

이러한 Async Shader의 잠재력을 사용해 할 수 있는 일들이 열거되어 있습니다.

 

 

 

특히 이러한 장점은 DirectX 12에서 두드러집니다. 많은 분들이 3DMark API Overhead Test에서 GCN 계열의 선전을 지켜보셨을 줄로 압니다.

단순히 '그래픽 코어 갯수가 많다' 차원을 넘어, 이러한 자원이 어떻게 병렬 처리에 효과적으로 이용되는지에 대한 고찰이 Async Shader의 기원이라 하겠습니다.

 

 

현존하는 게임 중 Async Shader를 지원하는 것은 위의 4종입니다.

 

 

DirectX 12, 벌칸에 이 기능이 기본적으로 포함되어 있다고 합니다.

 

 

정리해 봅시다. 높은 fps, 가상현실에 대한 대비, 더 좋은 이미지 퀄리티.

 

 

사실 이 Async Shader 파트는 오늘, 이 시점까지 엠바고가 걸려 있었습니다. 그만큼 AMD가 공들여 이 부분을 준비했다는 것인데...

앞서 잠깐 언급했지만, 3DMark API Overhead Test에서의 GCN의 선전이 예사로 보이지 않는 대목이기도 합니다.

앞으로 현존하는 GCN 계열 그래픽카드 및 다가올 '새' 그래픽카드가 어떤 면모를 보일지 기대해 보며, 브리핑 해설을 마칩니다.

 

긴 글 읽어주셔서 감사합니다 :)

 

//

 

아래 '밀어주기'는 티스토리의 크라우드펀딩 시스템입니다. 100원부터 3000원까지의 범위 내에서 글쓴이에게 소액 기부가 가능합니다. 제가 작성한 글이 후원할만한 가치가 있다고 여기신다면 밀어주기를 통한 후원을 부탁드립니다. 물론 글을 '가치있게' 쓰는 것은 오롯이 저의 몫이며, 설령 제 글이 '후원할 만큼 가치있게' 여겨지지는 못해 결과적으로 후원을 받지 못하더라도 그것이 독자 여러분의 잘못이 아니란 건 너무 당연해 굳이 언급할 필요도 없겠습니다. 저는 후원 여부와 관계없이 제 글을 읽어주시는 모든 독자분께 감사합니다.