들어가기에 앞서..

드디어 28나노의 오랜 집권을 깨뜨리고 등장한 16나노의 엔비디아 차세대 아키텍쳐 파스칼이 등장했습니다

이번에도 맥스웰과 마찬가지로 GP 104의 칩을 가지고 GTX 1080, 1070을 먼저 출격 시켰습니다.

성능이야 발표회를 통해서 밝혀 졌지만 아직 엔비디아에겐 해결 못한 숙제가 남아 있죠

바로 DX12 와 밀접히 관련되어 있는 "비동기식 쉐이더 (Async Shaders) 를 완벽히 지원 하느냐?" 입니다.

최근, DX12게임이 서서히 나오면서 엔비디아의 맥스웰 카드를 대표로 DX12 옵션을 켰을때 오히려 프레임이 떨어지는

이슈가 등장하기 시작했으며 이는 비동기식 쉐이더의 지원 여부 문제까지 접근하게 되었습니다.

해당 관련 기사 : AMD, "엔비디아 맥스웰은 비동기연산 성능에 무능" (링크)

이번 파스칼 출시전에도 비동기식 쉐이더 지원 여부가 불투명하다는 루머성 기사가 있었습니다

해당 관련기사 : "Pascal in-trouble with asyncronous compute code" (링크)

하지만 루머성 추측에 기반한 기사인데다 이번 보도자료에서 파스칼은 새로운 비동기 연산을 지원한다고

공식적으로 언급했기에 두고 봐야 할 문제입니다. (언급 관련 링크)

이에 많은 분들이 다소 생소한 비동기 쉐이더 (Async Shaders) 에서 궁금해 하시기에

저도 완벽히는 잘 모르지만 원리를 중심으로 간단하게 설명드리고자 합니다

다소 부족한점 있겠지만 너그럽게 봐주시면 감사하겠습니다 ^^

※ Asyncronous Shaders (비동기식 쉐이더가 옳은 표현이나 편의상 비동기 쉐이더로 하겠습니다 양해 바랍니다)

GPU WORK 의 과정

비동기 쉐이더를 알아보기전에 GPU 작업과정에 대해 알아 볼 필요가 있습니다

우리가 보는 3D게임의 화면은 GPU에서 "Work Queue (워크 큐, 워크 로드)" 들을 통해 보여 줍니다.

주요 Work Queue 들로는 "Graphics Queue", "Compute Queue", "Copy Queue" 가 있습니다

이들은 렌더링을 맡고 있는 워크 큐들인데 하나 하나 간단하게 언급 드리자면,

"Graphics Queue" : 그래픽큐, 실질적인 렌더링을 맡고 있습니다 ( EX: 광원효과, 물리연산 등 )

"Compute Queue" : 컴퓨트큐, 포스트 프로세싱 (후처리), 을 맡고 있습니다 ( EX : 피사계심도, FXAA 등)

"Copy Queue" : 카피큐, 단순한 데이터 전송을 맡고 있습니다

오늘날의 게임엔진은 보통 이러한 워크 큐들이 복합적으로 작동하게 끔 되어 있습니다

이러한 워크큐들에 따라 GPU가 일하게 되고, 매우 당연하게도 일하는 방식에 따라 GPU가 합리적으로

일해서 최대성능을 내거나, 비효율적인 작업 방식 때문에 GPU 병목이 올 수 있습니다

이제 그 작업 방식에 대해 알아 보겠습니다.

Async Shaders, 성공적

앞서의 설명에 이어서 다음은 GPU가 일하는 방식에 대해서 알아 보겠습니다

GPU가 워크 큐를 처리하는 방식으로는 크게 " 멀티 쓰레드 " (Multi thread), " 프리 엠션 " (Pre Emption)

" 비동기 쉐이더 " (Async Shaders) 3 가지가 있는데 이들을 간단하고 투박하게 설명을 하면 다음과 같습니다.

멀티 쓰레드 (Multi thread)

먼저, GPU가 처리 해야할 워크 큐가 "그래픽 큐" 일 경우 "G" 라고 하고 " 컴퓨트 큐"를 "C" 라고 해봅시다

GPU가 게임화면을 처리해야 할 워크 큐들을 보낼 때 멀티쓰레드에선 그 처리 방식이 순차적입니다

예를 들어서 게임이 GPU에게 " 야 G 10개! C 3개! 빨리 처리 좀!" 이라고 신호를 보내면..

이런식으로 처리하게 되는데, 마치 대기선이 있듯이 선행 작업큐가 끝나야 다음 큐로 넘어가게 되는 방식입니다

그림으로도 봐도 이 방식은 굉장히 비효율적인 것 처럼 보입니다 멀티쓰레드 방식의 단점으로는

1. 앞선 작업이 완료 되기 까지 작업큐들이 대기하거나 전환되는 과정에서 시간차가 발생

2. 순차적으로 진행 되기에 작업의 우선순위를 정하지 못함

더 쉽게 설명을 드리자면 병원에 일반환자, 응급환자등이 있는데 이 병원에선 접수된 순서대로 진행이 되며,

간혹 응급환자 (급한 작업, 시간이 오래 걸리는 작업)가 들어와도 무시하는 병원이라고 할 수 있겠습니다.

프리 엠션 (Pre Emption)

프리엠션 방식은 위의 멀티쓰레드의 단점을 극복하기 위해 나온 방식입니다

Pre Emption 이란 뜻은 "선점하다" 의 뜻인데 말 그대로 작업에 우선순위를 정할 수 있는 방법입니다

이러한 과정을 그림으로 간략하게 보면..

프리엠션 방식에서는 그림과 같이 "보라색 표시"로 되어 있는 빨리 처리해야할 작업큐를 위해

우선순위를 지정하여 기존 작업중이던 큐들을 멈추고 먼저 처리 시킬수 있도록 재배정 시킬 수 있습니다.

이러한 "선점"의 방식은 멀티 쓰레드의 단점을 극복할 수 있지만, 우선 순위재배정 때문에 일단은 일시에 다른 작업들이

멈춰야 하고 결국 작업속도는 지연이 생기게 되기 때문에 근본적인 문제는 여전히 해결되지는 않습니다.

비동기 쉐이더 (Async Shaders)

드디어 등장하게 되는 비동기 쉐이더는 위에서 언급된 문제들을 근본적으로 해결하기 위한 방법입니다

아예 애초에 처음 부터 작업 종류에 따라 워크큐들을 분류한 후 이를 동시에 처리하는 식인데

위의 방법들이 신호가 있는 일반 차선이었다면, 비동기 쉐이더는 신호가 없는 고속도로 에 해당합니다.

사진과 같이 비동기 쉐이더 방식은 GPU가 미리 필요한 작업큐들을 병렬적으로 처리하기에

다른 작업의 완료를 기다릴 필요 없는 구조라 계속해서 작업 큐들을 보낼 수 있습니다.

(사진은 막힌 것 처럼 보이지만 실제론 막힘 없이 진행되는 모습입니다 ^^;)

이러한 방식은 복잡한 다중 소스에서 전달된 작업큐들을 대량으로 동시에 처리할 수 있게 됩니다

물론, 이미 작업에 필요한 "워크 스케쥴링" 이 끝난 상태이기에 작업 우선순위도 맞춰져 있습니다.

이로써 "비동기 쉐이더" 의 방식은 멀티 쓰레드, 프리엠션의 문제점을 모두 보완한 방법이며,

GPU 효율을 가장 극도로 뽑아낼 수 있는 가장 성공적인 방법이 비동기 쉐이더라고 할 수 있으며

비동기 쉐이더는 VR에서도 중요시 되는 기술이기에 앞으로도 강조될 기술이라고 생각 됩니다.

DX12와 비동기 쉐이더

이번 차세대 그래픽카드는 "DX12를 완벽히 지원하느냐"에 따라 그 성패가 달려 있다고 해도 무방합니다

그리고 이 말은 "DX12와 밀접한 관련이 있는 비동기 쉐이더를 완벽히 지원하느냐" 와도 직결되는 문제입니다.

DX12에서는 여러가지 기능이 있지만 그 중에서 특기할 점으로는 DX11 대비 코어 활용도가 매우 높아 졌다는 점입니다

DX11에선 하나의 프레임을 처리 하기 위해 게임코드, 런타임, 드라이버등을 하나의 CPU 코어가 처리합니다

다른 코어에도 할당이 되기는 하지만 대부분 작업이 하나의 코어에서 이루어 지게 됩니다.

반면, DX12에선 게임코드, 런타임, 드라이버 등을 다른 코어에도 할당이 가능하게 되었습니다

즉, DX11에서 지적 되어왔던 다중 CPU 코어 활용문제 해결을 기대할 수 있게 된거죠.

게다가 DX12는 드라이버 등의 의존도가 낮아 졌기에 "로우레벨 API" 로써 GPU와 접근성이 더욱 높아 졌습니다

그러한 예로 아래 사진과 같은 "3D 마크 API 오버헤드 벤치마크" 결과를 들 수가 있습니다.

3D 마크 API 오버헤드 벤치는 프레임이 30프레임으로 떨어질 때까지 GPU에게 특정 오브젝트를

무수히 그리게 하여 성능을 테스트 합니다

위 사진은 I7 과 290X의 테스트 장면이며 아직 끝나지 않은 상태입니다. (40.2 FPS)

DX11 으로 동일한 환경에서의 30프레임으로 떨어져 테스트가 끝난 벤치마크의 결과 입니다

위 의 DX12 와 비교하면 오브젝트의 수가 확연히 적습니다. (30.5 FPS)

이 때 이를 받쳐줄 GPU 처리방식으로써 앞서 설명한 비동기쉐이더가 필요한 것입니다

오버헤드가 적은 "DX12" 와 대량의 드로우 콜을 처리할 수 있는 "비동기쉐이더" 를 통해 서로의 시너지가 발휘하게 됩니다

차세대 GPU에서 비동기 쉐이더를 위한 "비동기 연산 능력" 이 주목되는 이유가 바로 여기에 있습니다.

파스칼 VS 폴라리스 (끝 마치며..)

결국 귀결되는 문제는 바로 암당 VS 엔당의 차세대 그래픽카드의 DX12 대결입니다만

정답은 "나와봐야 안다" 입니다 좋아하는 말은 아니지만 사실입니다..

정말 나와봐야 아는 문제입니다 아직 제품이 출시가 안되었기에 어떻게 될지는 그때 가서 까봐야 아는 문제죠.

현재 까지의 상황으로는 일단 엔비디아의 맥스웰 카드의 "비동기연산" 의 문제는 확연해 보입니다

여러 벤치들이 이를 증명해 주고 있는 상황이고 해외웹진에서도 공공연히 인정하고 있습니다

엔비디아는 이러한 이슈에 공식적으로 언급하거나 해명하지 않았습니다만, 최근의 발표에서 공식 언론보도로

“New asynchronous compute advances improve efficiency and gaming performance.”

다음과 같은 말을 하며 파스칼에서 "새로운 비동기 연산 을 보여줄 것" 이라고 한 상황입니다

분명 엔비디아는 전세대 맥스웰에서 비동기 연산에 대한 문제를 인지하고 있을 것이며, 차세대 아키텍쳐에서

이를 해결하는데 주력했을 것입니다 (아마도..)

하지만 900번대 맥스웰 카드 비동기 연산 문제의 경우, 이대로 묻혀질 가능성도 적잖아 보입니다.

AMD의 폴라리스는 글쎄요..DX12와 비동기연산에 관해서는 걱정할 필요가 있나 싶습니다

모두들 아시는 사실이겠지만 "로우레벨 API" 라던가 "비동기 연산" 은 모두 AMD 가 선구한 것입니다

지금은 사라진 "맨틀"이 바로 로우 레벨 API의 아버지이며 이를 고려해서 GCN 1.0 부터 연산 능력에 주력해 왔습니다

즉, 이 분야에선 AMD가 엔비디아 보단 성숙하다고 말할 수 있습니다.

다만, 당시에는 비동기연산을 지원하지 않는 DX11 시대였고, 지원하지 않는 게임이 많지 않은데다가

엔비디아에 비해 그래픽 능력 보단 연산능력에 치중했기에 실게이밍 퍼포먼스에서 밀려 왔습니다

최근에 와서야 DX12 게임이 하나씩 나오면서 AMD의 GCN이 재평가 받고 있습니다만 좀 늦은 감이 있죠.

이제, DX12 라는 동등한 판이 펼쳐 졌습니다

양사 모두 신공정인데다가 DX12 게임이 본격적으로 나오기 시작하는 올해 부터 어떻게 나올지 매우 궁금해 지네요

(한 가지 걸리는 점은 올해 엔비디아는 하이엔드, AMD는 메인스트림이라 시장 나눠먹는 구도일지도..)

짧게 쓰려 했는데 길어 지고 말았네요

부족한 글 읽어 주시느라 고생 하셨습니다 ^^