GPGPU

General-purpose computing on graphics processing units.

1 개요

'GPU를 이용한 범용연산'의 머릿글자. GPU를 CPU가 맡았던 연산에 사용해 연산 속도를 향상시키는 기술이다.
본격 노가다와 사무직의 분리 컴퓨터판 하청

2 상세

GPU는 대량 계산에 용이하게 설계되므로 잘 이용하면 연산력을 향상시킬 수 있다. 예를 들어 BOINC 중 몇몇 프로젝트는 CPU만으로는 10시간 이상이 걸리는 반면, GPGPU를 사용하면 2시간에서 3시간만에 프로젝트가 완료되는 모습을 볼 수 있다. 3ds max를 비롯한 3D 프로그램에서도 CPU를 사용하면 5시간 이상 걸리는 인테리어 렌더링을 GPGPU로 연산을 시키면 약 20배 더 빨리 연산한다. GPGPU 코어가 많을수록 속도는 배가 된다. 레이트레이싱(라디오서티)등의 샘플 수를 늘려도 CPU 보다 빠르다. 자연스럽게 슈퍼컴퓨터가 생각날 텐데, 실제로 2013년 현재 가장 빠른 중국의 텐허 슈퍼컴퓨터가 GPU 하이브리드 아키텍처를 사용하고 있다. 실은 여러분이 좀 비싼 그래픽 카드를 샀다 싶으면 GPGPU없던 시절의 초 고성능 워크스테이션이나 조금 더 옛날의 슈퍼컴퓨터와 동급의 괴물을 집안에 한 대 모셔둔 셈이다. CPU가 날고 기어도 300GFLOPS대이다. 이게 무려 Core i7 5960X의 속도다. 18코어 하스웰-EP 제온은 1.3TFLOPS 이다. 다만 처음부터 특수 목적으로 설계된 CPU이며 이마저도 연산속도는 GPU보다 못할 때도 있다. 프로그래밍의 편의성 때문에 쓰는 셈. 그러므로 엄연히 말하자면 GPGPU도 아닌 CPU연산이다.

2015년 기준 10만원대의 GPU는 거의 대부분 1TFLOPS[1]를 넘어가고 AMD의 R9 Fury X는 이미 8.6TFLOPS, 그리고 더 나아가 R9 295x2는 11.2TFLOPS로 최초로 10TFLOPS를 돌파, 2016년 4월 26일 출시된 PRODUO는 16TFLOPS를 돌파했다! 더구나 CPU 성능은 MMX이후 18년 가량 발전한 SIMD 명령어의 최신판인 AVX2 사용을 전제로 멀티코어 성능을 다 끌어다 썼을 때 기준이라 어느 정도는 GPGPU에 가까운 병렬화 프로그래밍 최적화를 전제로 한 것이다. 이런 기반 없이 단순 무식하게 짜면 15년도 하이엔드 CPU로 100GFLOPS 뽑기가 어려울 수가 있다! 14년도 자료긴 하지만 실제 싱글 스레드 성능측정 데이터를 봐도 그렇다.

GPU는 구조가 CPU하고는 전혀 다르다. CPU는 다양한 환경에서의 작업을 빠르게 수행하기 위해 실제 연산을 수행하는 부분(ALU라고 한다)의 구조가 복잡하고 명령어 하나로 처리할 수 있는 기능도 많으며 각종 제어 처리를 위한 부분이 매우 많다. CPU에 계속 추가되고 있는 확장 명령어(SSE 등)을 보면 명령어 하나로 계산 여러 개를 한꺼번에 하거나 복잡한 수식 처리를 하기 위한 것이 많다. 예를 들어 곱하기 8개나 벡터곱 연산을 한번에 한다거나... 반면 GPU는 특화된 연산을 빠른 속도로 수행하기 위해 그런 부분을 과감히 삭제하고 비교적 단순한 다수의 ALU에 몰빵하는 구조로 만들어졌다. 공학용 전자 계산기 수백대를 때려 넣었다고 보면 좋다. 때문에 GPU 단독으로는 어떤 작업도 처리할 수 없다. GPU를 제어하는 건 여전히 CPU의 역할이다. APU 완전체가 되면 CPU와 GPU가 동등해져서, GPU가 CPU에게 일을 시키는 것도 가능해지게 되지만 APU 자체가 기존 CPU나 GPU와는 다른 새로운 물건으로 봐야 되는지라...

3 CPU와 GPU의 차이

430px
▲ 간략한 CPU와 GPU 구조

CPU는 커다란 코어를 4개 넣지만 GPU는 작은 코어를 몇백개씩 넣은 모습이다. 싱글 코어 성능은 CPU가 빠르지만 GPU는 병렬 연산이 훨씬 중요하므로 싱글 코어 성능이 높아봤자 병렬 연산 성능이 떨어지고 전력 소모량이 증가한다. 따라서 CPU와는 다르게 GPU의 설계 목표는 가능한 한 많은 코어를 집적해라이다. 애초에 CPU 대신 GPGPU를 쓰려는 이유가 싱글코어 성능을 높이는데 한계가 왔기 때문이다. 대표적인 현상인 4GHz의 벽 참조. 따라서 GPGPU 프로그래밍 시에는 CPU에서 프로그래밍할 때의 상식 하나를 정반대로 적용해야 한다. 바로 스레드를 가능한 한 많이 만들라.
(다만, 16년도 현재는 이미 GPU도 한계 이상으로 때려박은 수준이기 때문에 점점 제어부를 늘리고 클럭을 높여서 연산 코어당 효율 향상을 꾀하고 있다. 이미 NVIDIA는 케플러 → 맥스웰에서 효율 증가를 최우선으로 아키텍쳐를 변경했는데, 심지어 780Ti → 980은 연산 유닛 감소가 클럭 증가폭을 넘어서기에, 단순 플롭스 수치로만 보면 오히려 8~9% 정도 성능이 떨어진다! [2]. 이에 멈추지 않고 맥스웰 → 파스칼에서는 더한 변화를 보이고 있다.[3] AMD도 980Ti (연산 유닛 2천8백여개)가 퓨리X (연산 유닛 4천여개)를 선방하는 것을 보고 다음 세대에는 효율 증가를 꾀하고 있다 카더라)

GPU에게 연산을 시키려면 몇 가지 하드웨어 요구 사항을 충족해야 한다. 첫번째로는 프로그램 가능한 셰이더가 있어야 한다. 이렇게 프로그램 가능한 셰이더는 그래픽 카드가 기본 지원하지 않는 셰이더도 그릴 수 있어 더 많은 표현(렌즈 효과, 변위 매핑, 필드 깊이 등)을 할 수 있다. 이 부분을 이용하여 연산을 하게 된다. 또한, 데이터 자료형의 추가도 필요하다. 일반 그래픽 응용프로그램처럼 모든 계산이 행렬식으로 처리되지는 않기 때문이다. 특수한 그래픽 카드 뿐 아니라 시중에서 거의 모든 그래픽 카드가 GPGPU를 지원한다. 내장 그래픽도 샌디브릿지부터 Directcompute를 지원한다. APU들은 말할 것도 없고.

4 현황

GPU는 이런 계산을 빨리빨리 처리할 수 있도록 병렬로 처리하며 처리 속도도 빠르게 올라가는 추세다. 그러나, CPU와 GPU가 처리하는 방식은 여러모로 다르기에 이를 해결하기 위해 여러 방식들이 속속들이 개발되고 있다. GPGPU로 CPU 한 개에 비해 최대 100배~250배의 속도 향상을 이룰 수 있지만, 병렬도가 지극히 높은 응용 프로그램에서만 이 정도의 혜택을 볼 수 있다. 연산의 병렬도가 거의 없고 연산식과 데이터가 함께 바뀌는 응용에서는 오히려 CPU가 압도적으로 빠르다. 샌디브릿지 CPU가 터보부스트 모드일 때의 클럭은 4GHz에 육박할 정도가 되지만 GPU 코어 클럭은 14~15년도에야 1GHz에 도달한 정도에 불과하다.

게다가 CPU는 처음부터 연산식과 데이터가 지멋대로 튀는 환경을 가정해서 설계했지만 GPU에게 이런 조건을 던져주면 제어부가 CPU에 비해 안습이기 때문에 정작 일을 해야 할 ALU 부 분이 놀고 있다. 대표적으로 GPU에서 돌아갈 코드에 if 문을 하나 사용할 때마다 가용 자원을 절반씩 깎아 먹는다고 봐도 된다. if 문은 코드의 흐름을 두 개로 갈라 놓는 역할을 하기 때문에 이런 건 CPU 쪽에서 가능한 한 처리해주는 게 좋다. 그렇지 않으면 if 문의 반대편 절반에 해당하는 데이터는 처리되지 못하고 대기하다가 앞쪽 절반에 해당하는 데이터가 다 처리된 뒤에야 비로소 계산을 재개한다. 물론 if 문의 한쪽에 데이터의 99%가 몰려 있다거나 데이터 양 자체가 충분히 많아서 절반쯤 나뉘어도 GPU의 자원을 전부 사용하는 경우에는 써도 성능에 큰 지장은 없다.

CPU 쪽에서 GPU 쪽으로 연산할 데이터를 제대로 던져주는 것도 만만한 작업이 아니다. 위에서는 간단한 분기문만을 예시로 들었지만, 데이터 자체를 전달하는 것도 고려할 사항이 많다. GPU에 작은 데이터를 일일이 다 나누어서 던져 주면 GPU에서 아무리 빠르게 처리해 줘도 GPU로 데이터를 보내고 받는 동안 시간을 까먹기 때문에 CPU보다 더 느려지는 경우도 있다. ( CPU와 GPU는 서로 간에 PCI-E를 통해서 통신하는데, 이 대역폭이 VGA의 로컬 메모리 대역폭보다 아직까지는 부족하고 CPU에 물려있는 메인 메모리에 비해서도 넉넉하지 못하다. 대역폭 뿐만 아니라 물리적으로 멀리 떨어져 있는 녀석들이다 보니 레이턴시도 문제가 된다. 그래서 데이터가 PCI-E를 통해 왔다 갔다 하다 보면 여기서 성능을 다 까먹는다. ) 실제로 현재 GPGPU 프로그램 중에서는 CPU도 GPU도 아닌 PCI-E에 의해 성능 병목이 결정되는 경우도 많다. APU가 나온 이유도 이렇게 멀리 떼 놓고 왔다 갔다 할 거면 차라리 하나로 합치지 그래?라는 발상으로 나온 것이라고도 할 수 있다.

GPGPU를 돌리기 위해서는 저런 프로그램 가능한 GPU뿐만 아니라, 소프트웨어 적으로 변환시키는 레이어 혹은 라이브러리가 필요한데, CUDA와 OpenCL이 많이 알려져 있다. 그 외에 마이크로소프트에서 만든 DirectCompute가 있다. DXVA를 비롯한 그래픽 카드 기반 동영상 가속은 그래픽 카드에 내장된 비디오 처리 엔진 및 GPGPU를 사용하며, 윈도우 환경에서는 DirectCompute를 사용한다.

당연하지만, GPGPU를 가동할 때 그래픽 카드에 부하가 많이 걸린다. 게임 돌리는 중에는 그 성능의 반도 안 쓰는 경우가 많지만 GPGPU 돌리고 있는 와중에는 그 계산 끝날 때까지 100%를 유지하기 때문(물론 프로그램이 제대로 된 경우에만). 전기도 평소보다 훨씬 많이 쳐먹는다. 매뉴얼에 적혀있는 바로 그만큼의 전력을 진짜로 쓴다고 보면 된다. 그래서 묻지마 파워같이 부실한 놈을 쓰면 이거 돌리다가 컴퓨터 통째로 말아먹는 수도 있다.

리얼타임 파티클, 리얼타임 레이트레이싱, 리얼타임 렌더링, 전문가용 프로그램에서도 절찬리에 도입되고 있다. 제대로 된 GPU 기반의 프로그램으로 렌더링을 할 경우 CPU보다 몇배~몇십배 빠른 렌더링이 가능하다. V-ray RT나 Octane Render 참고. 뿐만 아니라 게임에서도 유체 계산, 물리 연산 등을 CPU보다 빨리 처리할 수 있어 차세대 게임 프로세싱 엔진으로 주목되고 있는 분야기도 하다. 위에서 언급했듯이 게임 중 오브젝트 수가 비교적 적은 경우에는 GPU가 절반 이상 놀고 있으므로 남는 자원을 파티클 처리에 더 투자한다던가 하는 식이다. 이미 피직스 등에서 GPU를 이용한 처리가 가능하다. 피직스는 원래 별도의 물리 가속 카드에서 출발했지만, 엔비디아 인수 후 가속 카드는 단종되고 그래픽 카드의 가속 기능으로만 남게 되었다. SLI 환경에서는 아예 그래픽 카드 하나를 피직스 용으로 이용할 수도 있다. 비공식적으로 라데온 그래픽 카드에 지포스 그래픽 카드를 덤으로 끼워서 피직스를 구현하는 하이브리드 피직스의 경우 화면 출력은 라데온이, 피직스 계산은 지포스 쪽에서 처리 시키는 구조다. 물론 이 쪽은 엔비디아의 정책 때문인지 현재는 막혔다.

콘솔에서도 Wii U가 부실한 CPU를 때우기 위해 GPGPU를 지원하고 있고 플레이스테이션 4와 엑스박스 원도 비슷한 기능을 지원할 예정이다. 플레이스테이션 3도 CELL의 SPU를 이용하는 방식이 GPGPU와 유사한 면이 있다. 애초에 플레이스테이션 3은 개발 당시 GPU를 따로 안 쓰고 CELL에서 다 처리하려 했다. CELL 프로세서의 SPU는 특정 연산에 최적화되어 있고, PowerPC 기반 PPU 코어의 제어를 받기 때문에 그래픽 카드와 구조가 유사하다.[4] 게임에서의 활용도 Wii U처럼 어쩔 수 없는 면도 있는데, 순수 CPU는 싱글 코어라 SPU를 안 쓰고 대충 이식한 멀티플랫폼 게임들에서는 대체로 경쟁기종보다 후져서... 인텔이 CPU 용으로 쓸까 해서 만든 MLAA를 제일 먼저 써먹은 것도 이걸로 SPU를 써먹기 위해서였다. 그전까지만 해도 SRAM 빨로 MSAA를 거의 공짜로 걸던 경쟁기종에 비해 PS3는 AA를 걸기 힘들어서 후달리는 면이 있었다.

AMD APU 궁극의 목표는 바로 저 GPGPU를 통해 메인 연산장치 CPU + 보조 연산장치 내장 그래픽 칩의 조합으로 기존의 CPU 아키텍처에서는 상상도 못할 CPU 성능을 뽑아내는 것이다. 그 첫 단계로 적용된 것이 기존의 GPGPU 난이도를 내장 그래픽 칩 한정으로 대폭 줄인다는 목적으로 카베리부터 들어가는 이기종 시스템 아키텍처-HSA. 실제로 첫 HSA 제품인 카베리 A10-7850K의 경우 HSA 환경 구성시 i3와 경쟁하던 성능에서 i5-4670를 제껴 버리는 경이로운 성능 부스트를 보여주며 그 가능성을 증명했다. 그 덕분에 카베리 APU는 코어 수를 표시할 때 아예 그래픽 코어까지 묶어서 컴퓨트 코어라는 단어를 쓴다. A10-7850K의 경우 CPU 4+GPU 8로 12 컴퓨트 코어로 표기한다. 다만 HSA 지원 소프트웨어가 거의 없다는 게 함정. 요즘은 어도비 CC나 Corel, HSA 재단의 소프트웨어 등 점점 늘어나고 있긴 하다.

NVIDIA의 경우는 X86 CPU 관련 라이센스 간보기가 다 물 건너가는 바람에, 아예 GPU에다가 ARM CPU를 내장해 버리면 어떨까? 하고 고민하는 중이다. 그리고 CPU와 GPU의 연결 인터페이스를 고속화시켜서 병목을 해결하는 NVLink라는 녀석도 추진하고 있다.

반면 인텔은 GPU, 특히 하이엔드급 이상의 고성능 GPU (NVIDIA 타이탄이나 AMD 퓨리 같은거)가 없다 보니 조금 다른 노선을 취하는데, 바로 작은 CPU (아톰급)들을 수십개 때려 박아 GPU 비슷한 연산 능력을 얻는 것. 이렇게 해서 나온 게 제온 파이 시리즈이다. 관련 내용이나 슈퍼컴퓨터 성능 순위 TOP 500등을 보면 알겠지만, 실제로 GPGPU 시장을 먹어 치우며 급성장 중이다. [5] 아무래도 CPU 계열 출신이라 GPGPU보다는 프로그래밍하기 덜 어려운 데다가 인텔의 빵빵한 개발자 지원 덕택인 듯. 지금도 단순 스펙상 성능은 크게 뒤지나(퓨리X는 이미 8.6테라플롭스를 달성했으나 나이츠랜딩은 6+테라플롭스를 목표로 하고 있다), 상기된 너무 많은 ALU를 다 컨트롤 못해서 노는 현상이 적어서 실 성능은 그렇게 뒤지지도 않는다고 한다

다만 인텔도 APU에 대한 투자는 꾸준히 하고 있는데, 제온 파이는 슈퍼컴퓨터 등 HPC 용이지 데스크탑이나 노트북에 쓰기에는 전기를 많이 잡아 먹는 괴물이기 때문이다. 애초에 라라비를 출시 못 한 이유 중 하나가 양쪽 다 간 보다가 이게 아닌가벼 하고 방향 전환하다가 시기를 놓쳐서... 스카이레이크 부터는 OpenCL 2.0을 통해 HSA도 지원하는 등 AMD의 HSA 지원에 뒤지지 않는 HW를 들고 나왔다.[6] 더구나 캐시 구조를 생각하면 AMD보다도 앞서는 모습을 보인다. AMD는 카리조까지도 CPU와 GPU가 공유하는 L3 캐시가 없었다. 그래서 해당 기능이 필요한 AMD 후원 HSA 성능 연구는 HSA와 L3 캐시를 모두 가진 가상의 APU를 시뮬레이션 해서 쓰기도 한다. (연구 당시 인텔 APU는 HSA 미지원인 시절) 근데 인텔은 이제 HSA + L3 캐시 공유에, Iris Pro 탑재 모델 한정 L4캐시까지...밸런스 패치가 시급하다

5 관련 항목

  1. ↑ GTX 750의 연산성능과 비슷하다.
  2. ↑ 780Ti 싱글 5045.7기가, 더블 210.2기가, 980 싱글 4612기가, 더블 144기가
  3. ↑ 출처 3번째 댓글 참조
  4. ↑ 결국 CELL만 쓰는 계획은 실패하여 nVidia의 RSX가 달렸다. 이 때문에 PS3 초창기에는 PS3를 잔뜩 사서 병렬 연결하여 슈퍼컴퓨터를 만드는 곳도 있었다. 소니 입장에선 PS3는 손해 보고 팔고 그걸 산 유저들이 게임을 사야 돈이 벌리는 구조인데 저렇게 PS3 본체만 사서 딴 데다 써버리면 속 터질 일이지만, 저런 사정을 대놓고 티내면서 징징거릴 수는 없다 보니, 저런 걸 가지고 우리 PS3는 이렇게 강력합니다! 식으로 홍보하긴 했다.
  5. ↑ 1세대인 라라비 시절만 하더라도 GPU에 밀리는 연산 수치 비교만 당하다(내년~내후년 쯤에 1테라플롭스로 나올 예정이라는 발표를 하자, NVIDIA와 AMD가 1테라플롭스 GPU를 판매 개시했다(...)) 출시도 못하는 등의 굴욕을 겪었으나, 2세대 나이트 페리가 제온 파이로 출시된 이후로는 탄탄대로이다. 단 라라비를 흑역사 취급하고 실제로 처음 출시된 이 녀석을 1세대로 치는 사람도 있다. 코어 i시리즈 샌디브릿지도 보는 시각에 따라서 3번째로 출시된 세대인데 공식적으로는 2세대인 것과 비슷한 상황.
  6. ↑ 단, OpenCL 2.0을 통한 HSA 사용은, 정식 지원이라기 보다는, 꼼수에 가깝고 제약도 심하다고 한다.