최근 수정 시각 : 2022-06-29 17:36:03

GPGPU

GPU 가속에서 넘어옴

1. 개요2. 그래픽카드가 GPU가 된 이유3. CPU와 GPU의 차이4. 현황5. APU 혹은 내장 그래픽이 탑재된 CPU6. 관련 문서

1. 개요

General-Purpose computing on Graphics Processing Units의 머릿글자로, 직역하면 'GPU의 범용 연산'. CPU가 맡았던 연산을 GPU에도 사용해 연산 속도를 향상 시키는 기술이다. 흔히 '하드웨어 가속'이라고 하면 GPU를 가리키는 경우가 많다.

2. 그래픽카드가 GPU가 된 이유

극초기의 컴퓨터는 CPU가 화면에 출력할 정보를 계산하는 것은 물론 디스플레이에 보낼 전기 신호까지도 직접 생성했으며, 이 때문에 화면 출력을 하는 것 자체가 CPU의 연산을 소모하는 행동이었다. 이 때는 아예 CPU가 연동된 시스템 클럭이 디스플레이와의 통신 프로토콜과 연동되어 있을 정도로 얽혀 있었으며, 화면 상하좌우에 테두리(!) 를 넣어 테두리 때문에 절약된 면적만큼 CPU가 디스플레이 출력 대신 다른 계산을 더 하도록 하는 고도의(...) 테크닉이 존재할 정도였다.

이후 16비트 컴퓨터의 시대가 오면서 화면 출력의 역할은 메인보드 안에 있는 디스플레이 전용 회로를 거쳐 별도로 판매되는 그래픽카드가 전담하게 되었지만, 이때까지도 그래픽카드의 역할은 메모리(RAM)에 표현된 이미지를 충실하게 화면으로 옮기는 역할에 지나지 않았다. 이 시대의 모든 디스플레이는 순수하게 글자만 표시하는 텍스트 모드 아니면 2D 화면을 표시하는 그래픽 모드, 두 가지 뿐이었기 때문에, 화면에 표시되는 정보가 담긴 RAM의 주소가 아예 하드웨어에 예약이 되어있었고, 그래픽 카드는 직접 메인보드를 거쳐 RAM의 해당 구간을 읽어 디스플레이에 뿌려주는 역할을 담당했다.

그래픽카드의 역할이 본격적으로 커지기 시작한 것은 슈퍼 VGA(SVGA)의 등장과 3D 그래픽의 부상과 맞물려 있다.

VGA 그래픽 시절까지는 화면 전체를 표시하기 위한 메모리 용량이 기본적으로 시스템의 하드웨어 기본 메모리인 1MB의 일부(수백 킬로바이트)를 예약해서 쓰는 것만으로 충분했지만, 해상도와 색상 가짓수가 늘어나면서 화면을 담기 위한 메모리 공간이 기하급수적으로 늘어나기 시작했다. 당시에도 1MB가 넘는 메모리는 있었지만 그것은 어디까지나 기본 메모리에 확장되는 구조였고, 아예 하드웨어에 고정된 수치로 박아놓아야 하는 그래픽 메모리를 늘리기 위해서는 컴퓨터의 호환성 자체를 부수고 새로 규정을 정해야 했다. 이랬다간 지금까지 판매된 모든 하드웨어 및 시스템과 전혀 호환이 되지 않기 때문에 PC 표준을 바꾸겠다고 먼저 나서는 것은 사실상 사업적인 자살이나 다름없었다. 그래픽카드 제조사들은 목마른 사람이 직접 우물을 판다는 형국으로, 자신들이 제조하는 카드 안에 보조 메모리를 집어넣고 그 사용법을 프로그래머들에게 배포하기 시작했다. 이때부터 내부 메모리를 제어하는 등 그래픽카드 안에 점점 복잡한 처리회로가 추가되기 시작했다.

흔히 잘 알려지지 않은 당시 SVGA들의 특화기능으로, '2D 가속기능' 이 있다. 이것은 윈도우 (3, 3.1 등) 등의 GUI 프로그램들이 점점 많아지고 윈도우 그래픽 환경에서 구동되는 사무, 전문 프로그램들이 늘어나자 2D 윈도우의 화면 처리속도를 높이고 갱신을 빠릿하게 하기 위한 가속기능이었다. 실제로 그 이전까지 게임이 아닌[1] 사무에서 2D 그래픽은 '좀 기다리더라도 표시가 되면 그만' 에 가까운 개념이었지만, 윈도우 사무환경에서는 사용자의 입력이나 데이터 처리 표시 등이 모두 그래픽으로 즉각 반응해야 했기 때문에 윈도우 화면 응답속도를 높이는 기능은 486~펜티엄 시절의 그래픽카드에서 꽤 중요하게 사용된 마케팅 포인트였다.

그리고 SGI 등에서 만드는 값비싼 전용 하드웨어가 아닌, 개인용 PC에서 3D 그래픽으로 게임을 하게 되면서 그래픽 카드에 대한 요구가 점점 증가했다. 초기만 하더라도 3D 그래픽을 계산하기 위해서는 CPU로 3차원 공간 상의 점 하나하나를 계산해서 화면의 픽셀 좌표로 변환해 줘야 했다. 따라서 물리, 그림자 따위는 언감생심이고 심지어 텍스처나 음영의 표시조차 사치였던 시절이었다. 극초기의 3D 게임들이 직선만으로 구성된 와이어프레임(wireframe)이었던 것은 각 모서리마다 1픽셀 좌표만 계산한 다음 그것을 선으로 이어주는 것만으로도 CPU가 과로사할 지경이었기 때문. 따라서 3D 그래픽은 아예 전용 연산장치를 탑재할 수 있는 아케이드/콘솔 분야에서 더 빨리 발전했다.

컴퓨터는 고정된 게임을 읽어서 실행하기 위한 기계가 아니었으므로, 3D 그래픽을 처리하기 위해서는 프로그램별로 3D 처리 기능을 내장시켜 줘야 했다. 초기의 프로그램들은 몇몇 천재적인 프로그래머에 의해 위에 제시된 예처럼 수학적으로 3차원 공간의 좌표를 직접 계산해서 처리했지만 이것은 어려울 뿐만 아니라 성능이 거지같다는 치명적인 단점이 있었다. 따라서 당시에도 이미 (2D 가속기능, SVGA 고해상도 처리기능 등) 사용자 니즈에 맞춰 제품과 그 사용 솔루션을 함께 개발해서 팔아오던 각 그래픽카드 제조사들은 게임 개발자들을 위해 당시 많이 사용되던 3D 계산기능들을 정리해 하드웨어에 내장시키고, 그것을 사용하기 위한 라이브러리/엔진을 프로그래머들에게 제공하기 시작했다. 이 때 등장한 것이 GLIDE와 같은 하드웨어 가속 API였으며, 본래 전문가 전용 하드웨어 라이브러리였으나 같은 명령어를 일반 PC 그래픽카드에서도 쓸 수 있게 포팅작업을 거친 OpenGL, 윈도우의 게임 지원을 본격적으로 하고자 마음먹고 운영체제 단계에서 그래픽카드 제조사의 차이에 관계없이 사용할 수 있도록 설계된 DirectX 등이 등장했다.

초기의 그래픽 API들과 그것을 지원하는 그래픽카드 하드웨어의 기능들은 기껏해야 3차원 공간에서 점을 찍고, 점을 이어서 선을 그려주는 것에서 출발했다. 그러나 일단 선을 이어 삼각형 이상의 면을 만들게 되고 나자 이것에 색을 채워줄 필요성이 생겼다. 처음에야 그냥 앞을 보면 밝은색으로 바르고, 옆을 보면 좀 어둡게 발라주고, 아래를 보면 컴컴한 색으로 발라주는 등 단순한 구조였지만 점차 하드웨어가 발달하고 게이머들의 눈높이가 올라가면서 텍스처를 발라준다거나, 각도에 따라 조명의 비율에 따라 색의 계조를 넣어주는 등 점점 계산해야 할 거리가 늘어나기 시작했다.

이것은 결국 픽셀 하나하나마다 그 위치의 텍스처 색상, 그 위치에 비치는 빛, 사용자 시점과의 각도 등을 계산하여 정확한 RGB 컬러를 계산해야 하는 단계까지 도달했고, 이것이 픽셀 셰이더의 시작이다. 이렇게 되자 그래픽카드는 화면에 있는 모든 픽셀에 대한 거의 동일한 계산작업을 매 프레임마다 해야하는 상황이 되었고, 이러한 처리를 하기 위해서는 무식하게 처리속도만을 올려 작업을 반복하는 것보다 해당 처리회로의 갯수를 늘려 한꺼번에 여러 픽셀씩 해치우는 것이 보다 효과적인 상황이 되었다. 그래서 이 시기부터 그래픽카드는 병렬처리 능력을 높여갔고, 보다 더 많은 병렬처리 능력으로 한번에 많은 양의 픽셀을 처리하는 것을 내세우게 되었다.

그래픽 카드의 화면 연산에 대한 처리방식이라는 것이 어느정도 표준화되고, 어느 입력값을 넣고 무슨 파라미터를 넣으면 무슨무슨 이미지를 뽑아준다는 것이 대체적으로 모든 제조사의 API에서 동일하게 써먹을 수 있게 되자, 프로그래머들이 창의력을 발휘하기 시작했다. 텍스처를 넣고->내가 커스텀한 그림자/셰이더/기타연산 코드를 먹이면->결과 텍스처가 나온다? 이거 입력값->함수->결과값 이랑 동일한거 아님? 100x100픽셀 이미지를 쓰면 1만개 연산이 한큐에 나오겠네??

이러한 발상에서 시작된 것이 셰이더를 이용한 병렬 컴퓨팅이었고, 초기에는 말 그대로 그래픽카드의 기능을 꼼수로 사용한 창의적인 아이디어에 지나지 않았지만 2006년 엔비디아에서 G80 아키텍처를 내놓으면서 시대의 흐름이 바뀌었다. 그 이전까지의 GPU 컴퓨팅이라는 것이 어디까지나 주 기능에 덧붙여진 보조적인 기능이었고, 그래픽카드 제조사에서도 알고는 있었지만 딱 그 정도의 중요도밖에 두지 않았던 데 반해, Nvidia CEO 젠슨 황은 아예 미래의 그래픽카드는 '연산 전용 장치'로서 역할이 바뀔 것이라는 비전을 제시하고 아예 원하는 연산을 병렬로 처리하는 기능 을 중심에 놓고 그것을 확장해서 그래픽 연산기능을 제공하는 아키텍처를 출시했다. 이 때 아예 병렬처리기능 전용으로 처음 제공된 API가 CUDA이며, 이 때부터 최적화하고 프로그래머들과 교류하면서 성능 및 편의성을 개선한 탓에 아직까지 GPGPU API의 최강자 지위를 차지하고 있다. 후발주자들은 컨소시엄을 만들어 OpenCL 등으로 범용성을 추구하는 등으로 우회한 장점을 추구했지만 파편화로 인한 최적화 성능의 부족 및 개발자 친화성 부족 등이 발목을 잡아 밀리고 있는 실정이다. 게다가 사공이 많은 탓에 버전업을 하면서 표준을 넣었다 뺐다 혼란스럽기까지 한 상태.

3. CPU와 GPU의 차이

GPU는 구조가 CPU하고는 전혀 다르다. CPU는 다양한 환경에서의 작업을 빠르게 수행하기 위해 복잡한 ALU(산술 논리 유닛)와 FPU(부동 소수점 유닛) 구조를 가지고 있고, 명령어 하나로 처리할 수 있는 기능( SIMD)도 많으며, 각종 제어 처리를 위한 부분이 매우 많다. CPU에 계속 추가되고 있는 확장 명령어 셋들을(SSE, AVX, FMA 등) 보면 명령어 하나로 계산 여러 개를 한꺼번에 하거나 복잡한 수식 처리를 하기 위한 것이 많다. 예를 들어 곱하기 8개나 벡터곱 연산을 한번에 한다거나... 반면 GPU는 특화된 연산을 빠른 속도로 수행하기 위해 그런 부분을 과감히 삭제하고 비교적 단순한 다수(수백 개)의 ALU와 FPU에 몰빵하는 구조로 만들어졌다. 때문에 GPU 단독으로는 어떤 작업도 처리할 수 없다. GPU라는 계산기를 두드리며 제어하고 명령하는 것은 여전히 CPU이다.

GPU는 대량 계산에 용이하게 설계되므로 잘 이용하면 연산 성능을 향상시킬 수 있다. 예를 들어 BOINC 중 몇몇 프로젝트는 CPU만으로는 10시간 이상이 걸리는 반면, GPU를 사용하면 2시간에서 3시간만에 프로젝트가 완료된다. 3ds Max를 비롯한 3D 그래픽 툴 렌더러에서도 CPU를 사용하면 5시간 이상 걸리는 인테리어 렌더링을 GPGPU로 처리하면 약 20배 더 빨리 연산할 수 있다. GPU의 연산 유닛이 많을수록 속도는 배가 된다. 글로벌 일루미네이션(Global Illumintion)등에서 많은 샘플 수를 사용할 때 CPU보다 빠르게 연산할 수 있다.

위의 설명을 비유로 풀어보자면 CPU는 '최고급 엔지니어 몇 명이 모인 설계, 시공사'이고 GPU는 '현장 노동자들이 모인 인력 시장'이라고 보면 된다. 엔지니어 몇 명에게 자재와 공구 쥐어주면 간단한 건물 정도는 몇 년 걸려서 지을 수 있겠지만[2] 마천루 같은 건 다음 세기 즈음에나 지을 수 있을 것이다. 반대로 현장 노동자 백만 명이 있어도 그들은 스스로 설계도를 만들 능력도 그들을 통솔하는 역할도 없으므로 아무것도 못 짓는다. 여기서 엔지니어들과 현장 노동자 수천 명이 서로의 역할대로 힘을 합친다면 마천루도 똑같이 몇 년 만에 지을 수 있을 것이다. 이것이 바로 GPGPU.

CPU는 이론적인 FP32 연산 기준 인텔, AMD 양사 일반 데스크톱용 제품군 중 최상위 라인인 i9-10900K가 1.5 TFLOPS,[3] 라이젠 9 5950X가 1.95 TFLOPS이고,[4] 현존 최다 코어 개수의 서버 및 워크스테이션용 CPU라 해도 제온 플래티넘 8380이 3.75 TFLOPS,[5] 라이젠 스레드리퍼 3990X가 6 TFLOPS에[6] 불과하다. 프로그래밍의 편의성 때문에 쓰는 셈. 그러므로 엄연히 말하자면 GPGPU도 아닌 CPU 연산이다. 더구나 CPU 성능은 1997년 초부터 도입된 MMX부터 발전되어 16년 후에 등장한 SIMD 명령어 셋인 AVX2 사용을 전제로 멀티코어 성능을 다 끌어다 썼을 때 기준이라 어느 정도는 GPGPU에 가까운 병렬화 프로그래밍 최적화를 전제로 한 것이다. 특정 명령어 셋 없이 단순 무식하게 짜면 이론적인 연산 성능에 가깝기는 커녕 반토막 혹은 그 이하로 뽑을 수도 있다! 2014년 자료긴 하지만 실제 싱글 스레드 성능측정 데이터를 봐도 그렇다.
이렇게 일반 데스크톱용 CPU가 2018년에 들어서야 라이젠 7 2700X, 코어 i9-9900K에서 겨우 1 TFLOPS대에 진입하고, 서버용 CPU라도 최대 수 TFLOPS에 그치고 있는데, 그래픽 카드는 똑같이 일반 데스크톱용인 지포스 RTX 2080 Ti가 약 14 TFLOPS, RTX 3090이 약 35 TFLOPS, 라데온 VII가 약 13 TFLOPS, RX 6900 XT가 약 23 TFLOPS로 수십 TFLOPS에 놀고 있으니, 연산 유닛의 확장보다는 다른 영역에서(분기 예측, 프리페치, 마이크로 옵 캐시, 재정렬 버퍼, 연산 스케줄러 등) 개선시켜 연산 성능 효율을 높이는 쪽으로 성능을 꾀하려는 CPU로써는 연산 유닛이 계속 확장되는 그래픽 카드와의 격차를 당분간 좁힐 수 없을 것이다.

자연스럽게 슈퍼컴퓨터가 생각날 텐데, 2018년 기준 15만 원 정도 가격으로 '1997~2000년 세계 1위 슈퍼컴퓨터'를 사용하고 있으며 160만 원대 가격으로 '2000~2002년 세계 1위 슈퍼컴퓨터'를 사용하고 있다고 보면 되겠다. 실제로 2013년 현재 가장 빠른 중국의 텐허 슈퍼컴퓨터가 GPU 하이브리드 아키텍처를 사용하고 있다.

파일:attachment/GPGPU/cpu_and_gpu_architecture_comparison.png
▲ 간략한 CPU와 GPU 구조. 여기에서 ALU가 '계산'을 담당한다.

CPU 커다란 코어를 4개 넣지만 GPU 작은 코어를 몇백 개씩 넣은 모습이다. 싱글 코어 성능은 CPU가 빠르지만 GPU는 병렬 연산이 훨씬 중요하므로 싱글 코어 성능이 높아봤자 병렬 연산 성능이 떨어지고 전력 소모량이 증가한다. 따라서 CPU와는 다르게 GPU의 설계 목표는 "가능한 한 많은 코어를 집적해라"이다. 애초에 CPU 대신 GPGPU를 쓰려는 이유가 싱글코어 성능을 높이는 데 한계가 왔기 때문이다. 대표적인 현상인 4GHz의 벽 참조. 따라서 GPGPU 프로그래밍 시에는 CPU에서 프로그래밍할 때의 상식 하나를 정반대로 적용해야 한다. 바로 스레드를 가능한 한 많이 만들라는 것.

다만, NVIDIA는 한때 2010년대 중반~말에 점점 제어부를 늘리고 클럭을 높여서 연산 코어당 효율 향상을 꾀하고 있었다. 케플러 → 맥스웰에서 효율 증가를 최우선으로 아키텍처를 변경한 것이 그 시작으로, 심지어 GTX 780 Ti → GTX 980은 연산 유닛 감소가 클럭 증가폭을 넘어서서, 단순 플롭스 수치로만 보면 오히려 8~9% 정도 성능이 떨어진다! (GTX 780 Ti의 FP32 연산 성능은 약 5 TFLOPS, GTX 980의 FP32 연산 성능은 약 4.6 TFLOPS) 이에 멈추지 않고 맥스웰 → 파스칼에서도 성능 효율은 물론이고 공정 미세화에 힘 입어 더 높은 클럭으로 연산 성능이 극대화하는 방향까지 보여주었다. ( 출처 3번째 댓글 참조) AMD도 연산 성능 위주로 출발했던 GCN 마이크로아키텍처의 성능 효율이 점점 한계에 부딪히면서 2019년 7월부터 NVIDIA 맥스웰~튜링 아키텍처와 비슷한 방향성으로 선회함으로써 그 결과가 RDNA 마이크로아키텍처로 나타나게 되었다.

4. 현황

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

GPU는 이런 계산을 빨리빨리 처리할 수 있도록 병렬로 처리하며 처리 속도도 빠르게 올라가는 추세다. 그러나, CPU와 GPU가 처리하는 방식은 여러모로 다르기에 이를 해결하기 위해 여러 방식들이 속속들이 개발되고 있다. GPGPU로 CPU 한 개에 비해 최대 100배~250배의 속도 향상을 이룰 수 있지만, 병렬도가 지극히 높은 응용 프로그램에서만 이 정도의 혜택을 볼 수 있다. 연산의 병렬도가 거의 없고 연산식과 데이터가 함께 바뀌는 응용에서는 오히려 CPU가 압도적으로 빠르다. 커피레이크 CPU가 터보 부스트 클럭이 5GHz 언저리까지 도달할 동안 GPU 코어의 부스트 클럭은 2020년도에서야 겨우 2GHz에 턱걸이를 하고 있기도 하지만.

게다가 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를 통해 왔다 갔다 하다 보면 여기서 성능을 다 까먹는다. 20년 최신 정보에 따르면 심지어 엑세스도 제한적이라도 대역폭과는 별개로 또 게임 성능에 영향을 미칠 정도라고 한다. #) 실제로 현재 GPGPU 프로그램 중에서는 CPU도 GPU도 아닌 PCI-E에 의해 성능 병목이 결정되는 경우도 많다. TPU가 GPGPU를 압도적으로 쳐바르는 성능도 저 병목 현상 기준으로 측정해서 나온 것이고. APU가 나온 이유도 이렇게 멀리 떼 놓고 왔다 갔다 할 거면 차라리 하나로 합치지 그래?라는 발상으로 나온 것이라고도 할 수 있다.

따라서 GPU 연산 프로그래밍은 일반적인 CPU 프로그래밍처럼 데이터를 가져옴 -> 로직에 넣음 -> 결과를 사용함 이 아니라, 데이터를 가져옴 -> GPU에 전송할 데이터를 준비 -> GPU로 데이터 전송 -> 결과를 기다림 -> GPU에서 결과 데이터를 수신 -> 수신한 데이터에서 사용할 결과를 추출 식으로 이루어진다. CPU 입장에서 보면 전송 및 수신 단계만 해도 상당한 시간이 소요된다. 이 때문에 초당 수십번 이상의 처리가 필요한 게임에서는 매 프레임마다 GPU로 함부로 뭘 과하게 하려고 했다간 혹 떼려다 혹 붙이는 격이 될 수도 있다.

GPGPU를 돌리기 위해서는 저런 프로그램 가능한 GPU뿐만 아니라, 소프트웨어 적으로 변환시키는 레이어 혹은 라이브러리가 필요한데, CUDA OpenCL이 많이 알려져 있다. 그 외에 마이크로소프트에서 만든 DirectCompute가 있다. DXVA를 비롯한 그래픽 카드 기반 동영상 가속은 그래픽 카드에 내장된 비디오 처리 엔진 및 GPGPU를 사용하며, 윈도우 환경에서는 DirectCompute를 사용한다. CUDA는 회사 차원에서의 빵빵한 지원과 쉬운 개발 난이도, 빠른 속도가 장점이지만 NVIDIA 그래픽카드에서밖에 작동하지 않는 게 단점이고, OpenCL은 AMD, NVIDIA, 인텔 가릴 것 없이 작동하고 오픈 소스 친화적이기 때문에 플랫폼에 구애받지 않는 높은 호환성이 장점이지만 CUDA보다 높은 개발 난이도와 느린 속도가 단점이다.

개발 환경또한 상당히 파편화 되어 있다.
CPU쪽 연산은 OpenMP나 OpenMPI 같은것들이 존재하고 기본적으로 프로세서의 기계어로 컴파일되는 특성상 별 문제 없이 쓰던것과 달리 GPGPU는 개발사마다 ISA가 다르다보니 GPGPU 개념이 등장한 초창기에도 각종 독자 API들이 존재하다 엔비디아를 제외하고 플랫폼에 구애받지 않는 API로 등장한 OpenCL로 통일되어 가는 분위기였으나 2015년을 전후로 SYCL[7]이 등장하기 시작하더니 AMD에서 HIP이 나오고 Intel에서 oneAPI가 등장하는 등 다시 파편화 되고 있는 상황이다. 그리고 이런 코드들은 당연히 지원하는 하드웨어가 한정된다.

당연하지만, GPGPU를 가동할 때 그래픽 카드에 부하가 많이 걸린다. 게임 돌리는 중에는 그 성능의 반도 안 쓰는 경우가 많지만 GPGPU 돌리고 있는 와중에는 소프트웨어가 제대로 GPGPU를 구현했다는 전제 하에 그 계산 끝날 때까지 100%를 유지하기 때문. 대부분 계산 특성상 CPU도 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 코어의 제어를 받기 때문에 그래픽 카드와 구조가 유사하다.[8] 게임에서의 활용도 Wii U처럼 어쩔 수 없는 면도 있는데, 순수 CPU는 싱글 코어라 SPU를 안 쓰고 대충 이식한 멀티플랫폼 게임들에서는 대체로 경쟁기종보다 후져서... 인텔이 CPU 용으로 쓸까 해서 만든 MLAA를 제일 먼저 써먹은 것도 이걸로 SPU를 써먹기 위해서였다. 그전까지만 해도 SRAM 빨로 MSAA를 거의 공짜로 걸던 경쟁기종에 비해 PS3는 AA를 걸기 힘들어서 후달리는 면이 있었다.

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

반면 인텔은 GPU, 특히 NVIDIA 타이탄이나 AMD 퓨리 같은 하이엔드급 이상의 고성능 GPU가 없다 보니 조금 다른 노선을 취하는데, 바로 인텔 아톰 시리즈같은 저전력 저성능 CPU를 수십개 때려 박아 GPU 비슷한 연산 능력을 얻는 것. 이렇게 해서 나온 게 제온 파이 시리즈이다. 1세대인 라라비 시절만 하더라도 내년~내후년 쯤에 1테라플롭스로 나올 예정이라는 발표를 하자, NVIDIA와 AMD가 1테라플롭스 GPU를 판매 개시해서 GPU에 밀리는 연산 수치 비교만 당하다 출시도 못하는 등의 굴욕을 겪었으나, 제온 파이로 출시된 2세대 나이트 페리는 나름 잘 팔렸다.[9] 관련 내용이나 슈퍼컴퓨터 성능 순위 TOP 500등을 보면 알겠지만, 실제로 GPGPU에서 유의미한 점유를 달성했었다. 아무래도 CPU 계열 출신이라 GPGPU보다는 프로그래밍하기 덜 어려운 데다가 인텔의 빵빵한 개발자 지원 덕택인 듯. 지금도 단순 스펙상 성능은 크게 뒤지나[10], 상기된 너무 많은 ALU를 다 컨트롤 못해서 노는 현상이 적어서 실 성능은 그렇게 뒤지지도 않는다고 한다. 그러나 제온 파이는 상업적으로 실패했고 인텔이 10nm 공정에도 난항을 보여 생산을 중단하고 포기했다.

한편 2010년대 후반기부터 GPGPU의 사용률이 폭증했는데, 다름아닌 암호화폐 채굴기 때문. 그래서 그래픽 카드가 품귀 현상을 보이고 가격이 폭등하기도 했다. 다만 요즘 게임용 카드 같은 경우엔 게이머 수요층이 잠식되고 정작 그런 용도로 왕창 팔려야 하는 쿼드로 같은 작업용 제품군들은 동급 지포스보다 훨씬 비싸서 안 팔리니 지포스 계열에서 GPGPU 기능을 최대한 거세하려는 듯 하다. 이미 GeForce 900부터 드라이버 단에서 CUDA 가속을 막아버려서 사용을 위해서는 별도의 작업을 해줘야 한다. 물론, CUDA나 OpenCL 등의 라이브러리 지원을 안 한다고 해서 GPGPU 자체가 완전히 막히는 것이 아니다. 애초에 GPGPU 개념이 처음 나왔을 때는 저런 라이브러리가 없었기 때문에, 셰이더 코딩으로 간접적인 방법(텍스처 같은 객체를 I/O 데이터로 사용하는 등)을 이용해서 구현하였다. 지금도 하려면 얼마든지 할 수는 있는 방법이고, 몇 가지 제약 외에 차이는 없다.[11] 애초에 CUDA/OpenCL/DirectCompute 등의 라이브러리도 결국 근본적으로는 이런 방식으로 셰이더를 사용해서 연산을 하는 것이기 때문이다. 당연하지만 셰이더를 막지 않는 한 GPGPU 자체를 막을 수는 없다. 물론 셰이더는 이미 고정 파이프라인이 사장되어 연산 위주로 밀고 있는 현재에는 그냥 셰이더 == 그래픽카드 그 자체이기 때문에 막는다는 개념은 존재하지 않는다.

하지만 NVIDIA는 GeForce 20에 와서는 지포스는 어디까지나 게임용이라고 보란 듯이 쿠다 코어와 텐서 코어의 개수를 하드웨어적으로 제한하는 강수를 두면서 채굴 기능을 사용하는 데에 있어서는 불편하고 인코딩에 있어서는 빠른 성능으로 사용할 수 있도록 게이밍 성능에 더욱 초점을 맞춰서 출시되었다. 결국 지포스 GPU를 사용하려면 게이밍 용도로만 사용하고 병렬 컴퓨팅 기능은 오직 동영상 인코딩이나 포토샵 용도로만 사용하라는 것. 황회장 : 꼬우면 TITAN V나 쿼드로 사라고
그런데 그 RT코어를 가지고 채굴을 하려는 시도가 있었고 반쯤 성공했다. 이더리움이나 타 알트코인에선 아직 시도하지 않았지만 비트코인 채굴 프로그램 개발자중 한명이 RT코어를 이용해 채굴하는데 성공은 했다. 채굴 성능 자체는 ASIC에 살짝 밀리지만 기존 GPGPU 채굴보단 몇십배 빠르다고 한다. 이대로 레이 트레이싱 성능 강화를 위해 RT 코어의 성능이 향상된다면 ASIC보다 빠를 수도 있다는 이야기도 된다. 되려 채굴을 피하기 위해 만든 RT 코어가 더 좋은 채굴 유닛이 되는 순간...

AMD도 그래픽 카드 채굴 대란에 GPGPU용인 자사 Radeon Instinct이 아닌 일반 라데온 제품들만 신나게 팔려나가며 NVIDIA와 마찬가지로 시장이 교란되는걸 겪었기에 이러한 움직임에 합류하여 RDNA 아키텍처 부터는 연산 성능을 대폭 커팅시켜서 아키텍처를 내놓기에 이르렀다. 즉 AMD, NVIDIA 양사 다 일반적인 지포스나 라데온 RX 브랜드 네임의 제품에는 GPGPU 가속을 위한 성능들을 대폭 커팅시켜 내놓는 추세로 바뀌어가고 있다. 이는 장기적인 관점으로 보았을때 AMD나 NVIDIA나 둘 다 Instinct나 Quadro 라인업 같이 해당 기술에 특화된 라인업이 존재함에도 라데온 RX나 지포스같이 상대적으로 제조단가 대비 수익이 덜 발생되는 게이밍 라인업이 해당 용도로 갈려나갈 정도로 팔리는게 좋은 상황은 아니기 때문이다.

이에 돈이 걸린 문제다 보니 누구보다 빠르게 움직이는 암호화폐 시장에서는 이미 다른 방식으로 대응하기 시작했는데, 바로 ASIC. GPGPU는 아무래도 암호화폐에 있어서는 범용성에서 강점을 가지므로 새로운 암호화폐가 나와도 빠르게 대응이 가능한 대신 원하는 암호화폐용 채굴 알고리즘에 100% 최적화된 칩이 존재할 수 없기 때문에 전성비에서 손해를 볼 수밖에 없다. 여기에 엎친 데 덮친 격으로 GPU 업계의 방어가 시작됨에 따라 아예 비트코인, 이더리움 같은 메이저 암호화폐의 채굴에만 특화된 전용 칩을 주문생산하여 전성비를 극대화하는 방식으로 전환하는 추세로 들어갔다. GPU 시세는 특정 암호화폐 전용 ASIC 개발에 따른 가격 폭락이 반복되는 상당히 불안정한 상황에 있다. NVIDIA에서는 GPU를 사용하는 매커니즘상 램을 거쳐야 하는데 이 부분에 M.2 같은 고속 스토리지와 직접 연결하여 성능을 괴하였다. GPUDirect 참고.

하지만, NVIDIA가 2020년 9월에 출시된 GeForce 30 시리즈에서 다시 FP32 연산 성능을 크게 높였다. 게이밍도 2010년대 초중반부터 이미 연산 위주로 가고 있는데다, 2010년대 중반부터 성능 효율 향상을 꾀했던 것도 한계에 봉착했기 때문이다. 재밌는 점은 과거 GCN 마이크로아키텍처 기반의 라데온과 닮아가고 있다는 점. 이 때문에 그래픽 카드 채굴 대란이 다시 나타나고 있다. 반면, AMD는 NVIDIA의 과거 맥스웰~튜링 마이크로아키텍처 시절처럼 RDNA 마이크로아키텍처로 게이밍 성능 효율을 높이는 쪽으로 고수하고 있어서 그래픽 카드 채굴 대란의 영향을 덜 받는 편이지만, 콘솔 게임기의 SoC까지 생산해야 하다 보니 생산된 물량 자체가 너무 적어 소비자 입장에서는 정상적인 가격으로 구하기 힘든 것은 마찬가지였다. 라데온 RX VEGA 시리즈는 VII 대비 FP32 연산 성능이 크게 낮은 RX 5700 시리즈가 가격 대비 채굴 성능이 뛰어나서 대란이 최고조로 심해지고 있는 2021년도 아닌, 대란이 다시 시작될 즈음인 2020년에 진작에 품귀 현상을 겪었다.

5. APU 혹은 내장 그래픽이 탑재된 CPU

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

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

6. 관련 문서


[1] 게임은 해당 프로그램에 철저하게 최적화하고 입력과 출력이 미리 정해져 있으며 다른 프로그램들과의 멀티태스킹이 아무것도 없는 등, 윈도우 프로그램들과는 성격이 많이 달랐다 [2] 64코어 128스레드짜리 라이젠 스레드리퍼로도 그래픽 카드 없이 에뮬레이션 하면 크라이시스 하나 돌리기도 벅차다. [3] 올코어 터보 부스트 클럭 4.8 GHz 기준. [4] 올코어 프리시전 부스트 클럭 3.9 GHz 기준. [5] 올코어 터보 부스트 클럭 3.0 GHz 기준. [6] 올코어 프리시전 부스트 클럭 3.0 GHz 기준. [7] OpenCL의 불편하기 짝이 없는 장치 관리 코드들과 문법을 개선한 API다. SYCL코드는 OpenCL과 달리 네이티브로 실행되는것이 아니라 CUDA나 OpenCL등으로 변환되어 한번의 코드로 여러 디바이스에서 실행되게 된다. [8] 결국 CELL만 쓰는 계획은 실패하여 nVidia의 RSX가 달렸다. 이 때문에 PS3 초창기에는 PS3를 잔뜩 사서 병렬 연결하여 슈퍼컴퓨터를 만드는 곳도 있었다. 소니 입장에선 PS3는 손해 보고 팔고 그걸 산 유저들이 게임을 사야 돈이 벌리는 구조인데 저렇게 PS3 본체만 사서 딴 데다 써버리면 속 터질 일이지만, 저런 사정을 대놓고 티내면서 징징거릴 수는 없다 보니, 저런 걸 가지고 우리 PS3는 이렇게 강력합니다! 식으로 홍보하긴 했다. [9] 라라비를 흑역사 취급하고 실제로 처음 출시된 이 녀석을 1세대로 치는 사람도 있다. 코어 i시리즈 샌디브릿지도 보는 시각에 따라서 3번째로 출시된 세대인데 공식적으로는 2세대인 것과 비슷한 상황. [10] 퓨리X는 이미 8.6테라플롭스를 달성했으나 나이츠랜딩은 6+테라플롭스를 목표로 하고 있다 [11] 다만 CUDA/ OpenCL과 같은 전용 셋에 비해 GLSL/HLSL과 같은 컴퓨트 셰이더의 경우 연산의 정밀도를 보증하지 못하고 메모리 접근도 한정적이지만 게임과 같은 곳에서는 별 문제가 되지 않기 때문에 이런 컴퓨트 셰이더를 사용해 파티클 등을 구현하는데는 아무런 지장이 없다. [12] GPU 8이라는 것은 GPU가 8개라는 의미가 아니라, GPU의 연산부가 구성되는 컴퓨트 유닛(CU)이 8개라는 뜻이다. [13] 단, OpenCL 2.0을 통한 HSA 사용은, 정식 지원이라기 보다는, 꼼수에 가깝고 제약도 심하다고 한다. [14] APU에서 L3 캐시 메모리가 들어간 건 라이젠 세대부터다. [15] 일명 L4 캐시 메모리라고도 부르지만, L3 캐시 메모리까지 사용되는 SRAM이 아니다.