[[컴퓨터공학|컴퓨터 과학 & 공학
Computer Science & Engineering
]]- [ 펼치기 · 접기 ]
- ||<tablebgcolor=#fff,#1c1d1f><tablecolor=#373a3c,#ddd><colbgcolor=#0066DC><colcolor=white> 기반 학문 ||수학(해석학 · 이산수학 · 수리논리학 · 선형대수학 · 미적분학 · 미분방정식 · 대수학(환론 · 범주론) · 정수론) · 이론 컴퓨터 과학 · 암호학 · 전자공학 · 언어학(형태론 · 통사론 · 의미론 · 화용론 · 음운론) · 인지과학 ||
하드웨어 구성 SoC · CPU · GPU(그래픽 카드 · GPGPU) · ROM · RAM · SSD · HDD · 참조: 틀:컴퓨터 부품 기술 기계어 · 어셈블리어 · C/C++ · C# · Java · Python · BIOS · 절차적 프로그래밍 · 객체 지향 프로그래밍 · 해킹 · ROT13 · 일회용 비밀번호 · 사물인터넷 · 와이파이 · GPS · 임베디드 · 인공신경망 · OpenGL · EXIF · 마이크로아키텍처 · ACPI · UEFI · NERF · gRPC · 리버스 엔지니어링 · HCI · UI · UX · 대역폭 · DBMS · NoSQL · 해시(SHA · 브루트 포스 · 레인보우 테이블 · salt · 암호화폐) · RSA 암호화 · 하드웨어 가속 연구
및
기타논리 회로(보수기 · 가산기 · 논리 연산 · 불 대수 · 플립플롭) · 정보이론 · 임베디드 시스템 · 운영 체제 · 데이터베이스 · 프로그래밍 언어{컴파일러(어셈블러 · JIT) · 인터프리터 · 유형 이론 · 파싱 · 링커 · 난해한 프로그래밍 언어} · 메타데이터 · 기계학습 · 빅데이터 · 폰노이만 구조 · 양자컴퓨터 · 행위자 모델 · 인코딩(유니코드 · MBCS) · 네트워크 · 컴퓨터 보안 · OCR · 슈퍼컴퓨터 · 튜링 머신 · FPGA · 딥러닝 · 컴퓨터 구조론 · 컴퓨터 비전 · 컴퓨터 그래픽스 · 인공지능 · 시간 복잡도(최적화) · 소프트웨어 개발 방법론 · 디자인 패턴 · 정보처리이론 · 재귀 이론 · 자연어 처리(기계 번역 · 음성인식) · 버전 (버전 관리 시스템 · Git · GitHub)
1. 개요
General-Purpose computing on Graphics Processing Units의 머릿글자로, 직역하면 'GPU의 범용 연산'. CPU가 맡았던 연산을 GPU에도 사용해 연산 속도를 향상 시키는 기술이다.2. 그래픽카드가 GPU가 된 이유
극초기의 컴퓨터는 CPU가 화면에 출력할 정보를 계산하는 것은 물론 디스플레이에 보낼 전기 신호까지도 직접 생성했으며, 이 때문에 화면 출력을 하는 것 자체가 CPU의 연산을 소모하는 행동이었다. 이 때는 아예 CPU가 연동된 시스템 클럭이 디스플레이와의 통신 프로토콜과 연동되어 있을 정도로 얽혀 있었으며, 화면 상하좌우에 테두리를 넣어 테두리 때문에 절약된 면적만큼 CPU가 디스플레이 출력 대신 다른 계산을 더 하도록 하는 테크닉이 존재할 정도였다.이후 1980년대에 16비트 컴퓨터의 시대가 오면서 화면 출력의 역할은 메인보드 안에 있는 디스플레이 전용 회로를 포함하는 CPU와 별도의 그래픽카드가 전담하게 되었지만, 이때까지도 그래픽카드의 역할은 메모리에 표현된 이미지를 충실하게 화면으로 옮기는 역할에 지나지 않았다. 이 시대의 모든 디스플레이는 순수하게 글자만 표시하는 문자 모드 아니면 2D 화면을 표시하는 그래픽 모드, 두 가지 뿐이었기 때문에, 화면에 표시되는 정보가 담긴 RAM의 주소가 아예 하드웨어에 예약이 되어있었고, 그래픽 카드는 직접 메인보드를 거쳐 RAM의 해당 구간을 읽어 디스플레이에 뿌려주는 역할을 담당했다.
그래픽카드의 역할이 본격적으로 커지기 시작한 것은 슈퍼 VGA(SVGA)의 등장과 3D 그래픽의 부상과 맞물려 있다.
VGA 그래픽 시절까지는 화면 전체를 표시하기 위한 메모리 용량이 기본적으로 시스템의 하드웨어 기본 메모리인 1MB의 일부(수백 킬로바이트)를 예약해서 쓰는 것만으로 충분했지만, 해상도와 색상 가짓수가 늘어나면서 화면을 담기 위한 메모리 공간이 기하급수적으로 늘어나기 시작했다. 당시에도 1MB가 넘는 메모리는 있었지만 그것은 어디까지나 기본 메모리에 확장되는 구조였고, 아예 하드웨어에 고정된 수치로 박아놓아야 하는 그래픽 메모리를 늘리기 위해서는 컴퓨터의 호환성 자체를 부수고 새로 규정을 정해야 했다. 이랬다간 하드웨어 및 시스템과 전혀 호환이 되지 않기 때문에 PC 표준을 바꾸겠다고 먼저 나서는 것은 사실상 사업적인 자살이나 다름없었다. 그래픽카드 제조사들은 목마른 사람이 직접 우물을 판다는 형국으로, 자신들이 제조하는 카드 안에 보조 메모리를 집어넣고 그 사용법을 프로그래머들에게 배포하기 시작했다. 이때부터 내부 메모리를 제어하는 등 그래픽카드 안에 점점 복잡한 처리회로가 추가되기 시작했다.
흔히 잘 알려지지 않은 당시 SVGA들의 특화기능으로, '2D 가속기능' 이 있다. 이것은 GUI 프로그램들이 점점 많아지고 윈도우 그래픽 환경에서 구동되는 사무, 전문 프로그램들이 늘어나자 2D 윈도우의 화면 처리속도를 높이고 갱신을 빠릿하게 하기 위한 가속기능이었다. 실제로 그 이전까지 비디오 게임이 아닌[1] 사무에서 2D 그래픽은 '좀 기다리더라도 표시가 되면 그만' 에 가까운 개념이었지만, 윈도우 사무환경에서는 사용자의 입력이나 데이터 처리 표시 등이 모두 그래픽으로 즉각 반응해야 했기 때문에 윈도우 화면 응답속도를 높이는 기능은 486~펜티엄 시절의 그래픽카드에서 꽤 중요한 포인트였다.
그리고 SGI 등에서 만드는 값비싼 전용 하드웨어가 아닌, 개인용 컴퓨터에서 3D 그래픽으로 게임을 하게 되면서 그래픽 카드에 대한 요구가 점점 증가했다. 초기만 하더라도 3D 그래픽을 계산하기 위해서는 CPU로 3차원 공간 상의 점 하나하나를 계산해서 화면의 픽셀 좌표로 변환해 줘야 했다. 따라서 물리, 그림자 따위는 언감생심이고 심지어 텍스처나 음영의 표시조차 사치였던 시절이었다. 극초기의 3D 게임들이 직선만으로 구성된 와이어프레임(wireframe)이었던 것은 각 모서리마다 1픽셀 좌표만 계산한 다음 그것을 선으로 이어주는 것만으로도 CPU가 과로사할 지경이었기 때문. 따라서 3D 그래픽은 아예 전용 연산장치를 탑재할 수 있는 아케이드/콘솔 분야에서 더 빨리 발전했다.
컴퓨터는 고정된 게임을 읽어서 실행하기 위한 기계가 아니었으므로, 3D 그래픽을 처리하기 위해서는 프로그램별로 3D 처리 기능을 내장시켜 줘야 했다. 초기의 프로그램들은 몇몇 천재적인 프로그래머들에 의해 위에 제시된 예처럼 수학적으로 3차원 공간의 좌표를 직접 계산해서 처리했지만 이것은 수행하기 어려울 뿐만 아니라 성능이 낮다는 치명적인 단점이 있었다. 따라서 당시에도 이미 (2D 가속기능, SVGA 고해상도 처리기능 등) 사용자 니즈에 맞춰 제품과 그 사용 솔루션을 함께 개발해서 팔아오던 각 그래픽카드 제조사들은 게임 개발자들을 위해 당시 많이 사용되던 3D 계산기능들을 정리해 하드웨어에 내장시키고, 그것을 사용하기 위한 라이브러리/엔진을 프로그래머들에게 제공하기 시작했다. 이 때 등장한 것이 GLIDE와 같은 하드웨어 가속 API였으며, 본래 전문가 전용 하드웨어 라이브러리였으나 같은 명령어를 일반 PC 그래픽카드에서도 쓸 수 있게 포팅작업을 거친 OpenGL, 윈도우의 게임 지원을 본격적으로 하고자 마음먹고 운영체제 단계에서 그래픽카드 제조사의 차이에 관계없이 사용할 수 있도록 설계된 DirectX 등이 등장했다.
초기의 그래픽 API들과 그것을 지원하는 그래픽카드 하드웨어의 기능들은 기껏해야 3차원 공간에서 점을 찍고, 점을 이어서 선을 그려주는 것에서 출발했다. 그러나 일단 선을 이어 삼각형 이상의 면을 만들게 되고 나자 이것에 색을 채워줄 필요성이 생겼다. 처음에야 그냥 앞을 보면 밝은색으로 바르고, 옆을 보면 좀 어둡게 발라주고, 아래를 보면 컴컴한 색으로 발라주는 등 단순한 구조였지만 점차 하드웨어가 발달하고 게이머들의 눈높이가 올라가면서 텍스처를 발라준다거나, 각도에 따라 조명의 비율에 따라 색의 계조를 넣어주는 등 점점 계산해야 할 거리가 늘어나기 시작했다.
이것은 결국 픽셀 하나하나마다 그 위치의 텍스처 색상, 그 위치에 비치는 빛, 사용자 시점과의 각도 등을 계산하여 정확한 RGB 컬러를 계산해야 하는 단계까지 도달했고, 이것이 픽셀 셰이더의 시작이다. 이렇게 되자 그래픽카드는 화면에 있는 모든 픽셀에 대한 거의 동일한 계산작업을 매 프레임마다 해야하는 상황이 되었고, 이러한 처리를 하기 위해서는 무식하게 처리속도만을 올려 작업을 반복하는 것보다 해당 처리회로의 갯수를 늘려 한꺼번에 여러 픽셀씩 해치우는 것이 보다 효과적인 상황이 되었다. 그래서 이 시기부터 그래픽카드는 병렬처리 능력을 높여갔고, 보다 더 많은 병렬처리 능력으로 한번에 많은 양의 픽셀을 처리하는 것을 내세우게 되었다.
그래픽 카드의 화면 연산에 대한 처리방식이라는 것이 어느정도 표준화되고, 어느 입력값을 넣고 무슨 파라미터를 넣으면 무슨무슨 이미지를 뽑아준다는 것이 대체적으로 모든 제조사의 API에서 동일하게 써먹을 수 있게 되자, 프로그래머들이 창의력을 발휘하기 시작했다. 텍스처를 넣고->내가 커스텀한 그림자/셰이더/기타연산 코드를 먹이면->결과 텍스처가 나온다? 이거 입력값->함수->결과값 이랑 동일한거 아닌가? 100×100픽셀 이미지를 쓰면 1만개 연산이 한큐에 나오겠네?
이러한 발상에서 시작된 것이 셰이더를 이용한 병렬 컴퓨팅이었고, 초기에는 말 그대로 그래픽카드의 기능을 꼼수로 사용한 창의적인 아이디어에 지나지 않았지만 2006년 엔비디아에서 G80 아키텍처를 내놓으면서 시대의 흐름이 바뀌었다. 그 이전까지의 GPU 컴퓨팅이라는 것이 어디까지나 주 기능에 덧붙여진 보조적인 기능이었고, 그래픽카드 제조사에서도 알고는 있었지만 딱 그 정도의 중요도밖에 두지 않았던 데 반해, Nvidia CEO 젠슨 황은 아예 미래의 그래픽카드는 '연산 전용 장치'로서 역할이 바뀔 것이라는 비전을 제시하고 아예 원하는 연산을 병렬로 처리하는 기능 을 중심에 놓고 그것을 확장해서 그래픽 연산기능을 제공하는 아키텍처를 출시했다. 이 때 아예 병렬처리 기능 전용으로 처음 제공된 API가 CUDA이며, 이 때부터 최적화하고 프로그래머들과 교류하면서 성능 및 편의성을 개선한 탓에 아직까지 GPGPU API의 최강자 지위를 차지하고 있을 뿐더러 인공지능 가속기 영역에서도 ASIC 제품들을 제치고 대부분의 점유율을 차지하고 있다. 후발주자들은 컨소시엄을 만들어 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에 놀고 있으며 23년도에 출시된 4090은 82TFLOPS 7900XTX는 61TFLOPS로 CPU로는 더이상 따라가기 힘든 수준의 연산 능력을 보인다.
연산 유닛의 확장보다는 다른 영역에서(분기 예측, 프리페치, 마이크로 옵 캐시, 재정렬 버퍼, 연산 스케줄러 등) 개선시켜 연산 성능 효율을 높이는 쪽으로 성능을 꾀하려는 CPU로써는 연산 유닛이 계속 확장되는 그래픽 카드와의 격차를 앞으로도 좁히기 힘들 것이다.
자연스럽게 슈퍼컴퓨터가 생각날 텐데, 2018년 기준 15만 원 정도 가격으로 '1997~2000년 세계 1위 슈퍼컴퓨터'를 사용하고 있으며 160만 원대 가격으로 '2000~2002년 세계 1위 슈퍼컴퓨터'를 사용하고 있다고 보면 되겠다. 실제로 2013년 현재 가장 빠른 중국의 텐허 슈퍼컴퓨터가 GPU 하이브리드 아키텍처를 사용하고 있다.
▲ 간략한 CPU와 GPU 구조. 여기에서 ALU가 '계산'을 담당한다.
CPU는 커다란 코어를 4개 넣지만 GPU는 작은 코어를 몇백 개씩 넣은 모습이다. 싱글 코어 성능은 CPU가 빠르지만 GPU는 병렬 연산이 훨씬 중요하므로 싱글 코어 성능이 높아봤자 병렬 연산 성능이 떨어지고 전력 소모량이 증가한다. 따라서 CPU와는 다르게 GPU의 설계 목표는 "가능한 한 많은 코어를 집적해라"이다. 애초에 CPU 대신 GPGPU를 쓰려는 이유가 싱글코어 성능을 높이는 데 한계가 왔기 때문이다. 대표적인 현상인 4 GHz의 벽 참조. 따라서 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 마이크로아키텍처로 나타나게 되었다.
또한 현재의 컴퓨터의 구조적으로 CPU 대비 GPU에게 여러 여건이 넉넉한 점 역시 그 급격한 발달의 한 이유로서 무시할 수 없다. CPU의 경우 메인보드에 매우 가깝게 결합되고, 수많은 접점(핀)들을 통해 고속통신을 추구해 왔지만 그 때문에 실리콘 다이의 면적이 어느 정도 규정되고, 발열 해소 역시 한정적인 위치에 고정되어 왔다. 추가로 전력 공급을 온전히 메인보드의 접점으로만 받아야 하는 것은 덤. 한때 CPU 역시 슬롯형 카드를 도입하여 이러한 제약에서 벗어나려고 한 적이 있었지만 핀 갯수의 제약과 기타 이유 때문에 원래대로 회귀한 데 반해, 처음부터 슬롯을 기반으로 발달한 GPU는 점점 더 큰 실리콘 다이와 강력한 쿨링 시스템, 추가 전원 단자를 추가하며 발달해 왔다. 동시대의 CPU와 GPU를 분해해서 실리콘 다이의 크기를 비교해 보면 보통 GPU가 거의 4배 가까이 면적이 넓다. 여기에 히트스프레더 같은 소비자용 보호도구 없이 쿨러 일체형으로 처음부터 조립 생산되기 때문에, GPU의 반도체가 버틸 수 있는 전력의 총량은 CPU보다 훨씬 높다. CPU가 열관리를 하기 위해 TDP가 100W 근처에 묶인 채로 짧은 시간 동안 클럭을 부스트하면서 노력하는 와중에, GPU는 보조전원을 입력받는 케이블을 하나씩 늘려 가다가 아예 전용 고전압 고전류 단자를 도입하기에 이른 것을 보아도 CPU의 전력관리보다 GPU의 전력관리가 훨씬 더 급격하게 성장했음을 알 수 있을 것이다. 과거에는 CPU가 '머리' 이가 '가장 강력한 연산장치' 로서 전체 시스템에서 차지하는 가격 역시 가장 높았다면, 지금은 GPU의 가격, 트랜지스터 숫자, 소비전력 모두가 더 높다.
4. 현황
GPU에게 연산을 시키려면 몇 가지 하드웨어 요구 사항을 충족해야 한다. 먼저 프로그램 가능한 셰이더가 있어야 한다. 이렇게 프로그램 가능한 셰이더는 그래픽 카드가 기본 지원하지 않는 셰이더도 그릴 수 있어 더 많은 표현(렌즈 효과, 변위 매핑, 필드 깊이 등)을 할 수 있다. 이 부분을 이용하여 연산을 하게 된다. 또한, 데이터 자료형의 추가도 필요하다. 일반 그래픽 응용프로그램처럼 모든 계산이 행렬식으로 처리되지는 않기 때문이다. 특수한 그래픽 카드 뿐 아니라 시중에서 거의 모든 그래픽 카드가 GPGPU를 지원한다. 내장 그래픽도 샌디브릿지부터 Directcompute를 지원한다. APU들은 말할 것도 없고.GPU는 이런 계산을 빨리빨리 처리할 수 있도록 병렬로 처리하며 처리 속도도 빠르게 올라가는 추세다. 그러나, CPU와 GPU가 처리하는 방식은 여러모로 다르기에 이를 해결하기 위해 여러 방식들이 속속들이 개발되고 있다. GPGPU로 CPU 한 개에 비해 최대 100배~250배의 속도 향상을 이룰 수 있지만, 병렬도가 지극히 높은 응용 프로그램에서만 이 정도의 혜택을 볼 수 있다. 연산의 병렬도가 거의 없고 연산식과 데이터가 함께 바뀌는 응용에서는 오히려 CPU가 압도적으로 빠르다. CPU 터보 부스트 클럭이 6GHz까지 도달할 동안 GPU 코어의 부스트 클럭은 2023년도에서도 3GHz를 넘지 못 하고 있기도 하지만.
게다가 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가 나온 이유도 이렇게 멀리 떼 놓고 왔다 갔다 할 거면 차라리 하나로 합치지 그래?라는 발상으로 나온 것이라고도 할 수 있다. Apple의 M1 칩이 놀라운 성능을 자랑하는 이유 중 큰 부분도, 무슨 외계기술이 있어서 같은 공간의 회로에서 몇 배의 성능을 뽑아낼 수 있어서라기보다 기존에 수cm~수십cm 까지 서로 떨어져 있는 CPU, GPU, RAM을 하나의 실리콘 다이 안에 초집적시켜 최적의 레이턴시를 뽑아낸 과감한 선택이다.
따라서 GPU 연산 프로그래밍은 일반적인 CPU 프로그래밍처럼 데이터를 가져옴 -> 로직에 넣음 -> 결과를 사용함 이 아니라, 데이터를 가져옴 -> GPU에 전송할 데이터를 준비 -> GPU로 데이터 전송 -> 결과를 기다림 -> GPU에서 결과 데이터를 수신 -> 수신한 데이터에서 사용할 결과를 추출 식으로 이루어진다. CPU 입장에서 보면 전송 및 수신 단계만 해도 상당한 시간이 소요된다. 이 때문에 초당 수십번 이상의 처리가 필요한 게임에서는 매 프레임마다 GPU로 함부로 뭘 과하게 하려고 했다간 혹 떼려다 혹 붙이는 격이 될 수도 있다.
GPGPU를 돌리기 위해서는 저런 프로그램 가능한 GPU뿐만 아니라, 소프트웨어 적으로 변환시키는 레이어 혹은 라이브러리가 필요한데, CUDA와 OpenCL이 많이 알려져 있다. 그 외에 Microsoft에서 만든 DirectCompute와 머신러닝용 DirectML가 있다. DXVA를 비롯한 그래픽 카드 기반 동영상 가속은 그래픽 카드에 내장된 비디오 처리 엔진 및 GPGPU를 사용하며, 윈도우 환경에서는 DirectCompute를 사용한다. CUDA는 회사 차원에서의 빵빵한 지원과 쉬운 개발 난이도, 빠른 속도가 장점이지만 NVIDIA 그래픽카드에서밖에 작동하지 않는 게 단점이고, OpenCL은 AMD, NVIDIA, 인텔 가릴 것 없이 작동하고 오픈 소스 친화적이기 때문에 플랫폼에 구애받지 않는 높은 호환성이 장점이지만 CUDA보다 높은 개발 난이도와 느린 속도가 단점이다. DirectCompute와 DirectML는 DirectX API를 거치기에 OS만 윈도우즈라면 거의모든 게이밍 GPU, 더나아가 그 게이밍 GPU와 동일한 칩셋을 사용한 모든 GPU에서 작동하나 오버헤드가 매우커서 OpenCL보다도 못하다.
개발 환경또한 상당히 파편화 되어 있다.
CPU쪽 연산은 OpenMP나 OpenMPI 같은것들이 존재하고 기본적으로 프로세서의 기계어로 컴파일되는 특성상 별 문제 없이 쓰던것과 달리 GPGPU는 개발사마다 ISA가 다르다보니 GPGPU 개념이 등장한 초창기에도 각종 독자 API들이 존재하다 엔비디아를 제외하고 플랫폼에 구애받지 않는 API로 등장한 OpenCL로 통일되어 가는 분위기였으나 2015년을 전후로 SYCL[7]이 등장하기 시작하더니 AMD에서 HIP이 나오고 Intel에서 oneAPI[8]가 등장하는 등 다시 파편화 되고 있는 상황이다. 그리고 이런 코드들은 당연히 지원하는 하드웨어가 한정된다.
당연하지만, GPGPU를 가동할 때 그래픽 카드에 부하가 많이 걸린다. 게임 돌리는 중에는 그 성능의 반도 안 쓰는 경우가 많지만 GPGPU 돌리고 있는 와중에는 소프트웨어가 제대로 GPGPU를 구현했다는 전제 하에 그 계산 끝날 때까지 100%를 유지하기 때문. 대부분 계산 특성상 CPU도 100%를 유지하기 때문에 전기도 평소보다 훨씬 많이 쳐먹는다. 매뉴얼에 적혀있는 바로 그만큼의 전력을 진짜로 쓴다고 보면 된다. 그래서 묻지마 파워같이 부실한 놈을 쓰면 이거 돌리다가 컴퓨터 통째로 말아먹는 수도 있다.
리얼타임 파티클, 리얼타임 레이트레이싱, 리얼타임 렌더링, 전문가용 프로그램에서도 절찬리에 도입되고 있다. 제대로 된 GPU 기반의 프로그램으로 렌더링을 할 경우 CPU보다 몇배~몇십배 빠른 렌더링이 가능하다. V-ray RT나 Octane Render 참고. 뿐만 아니라 게임에서도 유체 계산, 물리 연산 등을 CPU보다 빨리 처리할 수 있어 차세대 게임 프로세싱 엔진으로 주목되고 있는 분야기도 하다. 위에서 언급했듯이 게임 중 오브젝트 수가 비교적 적은 경우에는 GPU가 절반 이상 놀고 있으므로 남는 자원을 파티클 처리에 더 투자한다던가 하는 식이다. 이미 피직스 등에서 GPU를 이용한 처리가 가능하다. 피직스는 원래 별도의 물리 가속 카드에서 출발했지만, 엔비디아 인수 후 가속 카드는 단종되고 그래픽 카드의 가속 기능으로만 남게 되었다. SLI 환경에서는 아예 그래픽 카드 하나를 피직스 용으로 이용할 수도 있다. 비공식적으로 라데온 그래픽 카드에 지포스 그래픽 카드를 덤으로 끼워서 피직스를 구현하는 하이브리드 피직스의 경우 화면 출력은 라데온이, 피직스 계산은 지포스 쪽에서 처리 시키는 구조다. 물론 이 쪽은 엔비디아의 정책 때문인지 현재는 막혔다.
한편 2010년대 후반기부터 GPGPU의 사용률이 폭증했는데, 다름아닌 암호화폐 채굴기 때문. 그래서 그래픽 카드가 품귀 현상을 보이고 가격이 폭등하기도 했다. 다만 요즘 게임용 카드 같은 경우엔 게이머 수요층이 잠식되고 정작 그런 용도로 왕창 팔려야 하는 쿼드로 같은 작업용 제품군들은 동급 지포스보다 훨씬 비싸서 안 팔리니 지포스 계열에서 GPGPU 기능을 최대한 거세하려는 듯 하다. 이미 GeForce 900부터 드라이버 단에서 CUDA 가속을 막아버려서 사용을 위해서는 별도의 작업을 해줘야 한다. 물론, CUDA나 OpenCL 등의 라이브러리 지원을 안 한다고 해서 GPGPU 자체가 완전히 막히는 것이 아니다. 애초에 GPGPU 개념이 처음 나왔을 때는 저런 라이브러리가 없었기 때문에, 셰이더 코딩으로 간접적인 방법(텍스처 같은 객체를 I/O 데이터로 사용하는 등)을 이용해서 구현하였다. 지금도 하려면 얼마든지 할 수는 있는 방법이고, 몇 가지 제약 외에 차이는 없다.[9] 애초에 CUDA/OpenCL/DirectCompute 등의 라이브러리도 결국 근본적으로는 이런 방식으로 셰이더를 사용해서 연산을 하는 것이기 때문이다. 당연하지만 셰이더를 막지 않는 한 GPGPU 자체를 막을 수는 없다. 물론 셰이더는 이미 고정 파이프라인이 사장되어 연산 위주로 밀고 있는 현재에는 그냥 셰이더 = 그래픽카드 그 자체이기 때문에 막는다는 개념은 존재하지 않는다.
하지만 NVIDIA는 GeForce 20에 와서는 지포스는 어디까지나 게임용이라고 보란 듯이 쿠다 코어와 텐서 코어의 개수를 하드웨어적으로 제한하는 강수를 두면서 채굴 기능을 사용하는 데에 있어서는 불편하고 인코딩에 있어서는 빠른 성능으로 사용할 수 있도록 게이밍 성능에 더욱 초점을 맞춰서 출시되었다. 결국 지포스 GPU를 사용하려면 게이밍 용도로만 사용하고 병렬 컴퓨팅 기능은 오직 동영상 인코딩이나 포토샵 용도로만 사용하라는 것.
그런데 그 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년에 진작에 품귀 현상을 겪었다.
인텔또한 자체 GPU로는 고성능 연산작업이 힘들어서 자사의 CPU를 GPU와 동일한 규모로 구성하는 인텔 제온 파이등을 만든적이 있으나 구조적인 문제로 버려졌으며 2020년대 라자 코두리등을 영입하고 Xe 코어를 개발함으로써 본격적인 GPGPU시장에 뛰어들어 인텔 Arc등의 고성능 GPU를 출시하고 엔비디아의 CUDA에 대응 가능한 ONE API를 출시하고 데이터센터,서버에도 판촉함으로써 본격적인 GPGPU시장 경쟁에 뛰어들었다.
이렇게 경쟁자들이 속속 늘어남에도 불구하고 2023년 기준으로도 GPGPU시장은 사실상 엔비디아 독점인데 이는 기존에 깔린 인프라가 죄다 CUDA기반인 점이 주요하며 또한 단순 연산성능으로 따져도 엔비디아를 따라잡을 만한 경쟁사가 없기 때문이라는 문제가 있기 때문이다. 이 때문에 엔비디아가 소비자 시장을 사실상 방기하는 수준의 정책을 펼쳐도 엔비디아의 매출은 날개달린듯이 상승하고 있다.
5. APU 혹은 내장 그래픽이 탑재된 CPU
APU 완전체가 되면 CPU와 GPU가 동등해져서, GPU가 CPU에게 일을 시키는 것도 가능해지게 되지만인텔도 APU라고 부르진 않더라도 비슷한 개념의 프로세서에 대한 투자는 꾸준히 하고 있다. 제온 파이는 슈퍼컴퓨터 등 HPC 용이지 데스크탑이나 노트북에 쓰기에는 전기를 많이 잡아 먹는 괴물이기 때문이다. 애초에 라라비를 내놓지 못 한 이유 중 하나가 양쪽 다 간 보다가 '이게 아닌가벼' 하고 방향 전환하다가 시기를 놓쳐서... 스카이레이크 부터는 OpenCL 2.0을 통해 HSA도 지원하는 등 AMD의 HSA 지원에 뒤지지 않는 하드웨어를 들고 나왔다.[11] 더구나 캐시 구조를 생각하면 AMD보다도 앞서는 모습을 보인다. AMD는 브리스톨 릿지까지도 CPU와 GPU가 공유하는 L3 캐시 메모리가 없었다.[12] 그래서 해당 기능이 필요한 AMD 후원 HSA 성능 연구는 HSA와 L3 캐시 메모리를 모두 가진 가상의 APU를 시뮬레이션 해서 쓰기도 한다. (연구 당시 인텔 CPU가 HSA 미지원인 시절) 근데 인텔은 이제 HSA + L3 캐시 메모리 공유에, Iris 탑재 모델 한정 eDRAM[13]까지...
6. 개발에 사용되는 언어
특정 하드웨어에서 동작되는 특성상 하드웨어 제조사마다 다른 언어가 사용된다.- OpenCL - 역사가 오래된(2009년) 다른 그래픽카드에서 병렬 연산을 시킬 수 있는 라이브러리다. 인텔, AMD, ARM 등에서는 NVIDIA를 견제하기 위해 이 프로그램을 밀고 있다. 다만, 이쪽은 출시한지 꽤 되었음에도 불구하고 멱살잡고 이끌어 가는 조장이 없어서 아직 불안정하며, 성능이 영 좋지 못하다. 애초에 일개 프로젝트로 커버하려는 범위가 너무 넓은 것이 흠이며, CUDA와 문법이나 메모리 모델은 비슷한데 코딩하기는 조금 더 난해하고 (소위 "Boilerplate Code"라고 하는 구동에 필요한 코드가 매우 많고 Verbose 하다.) 추상화가 덜 된 느낌이라서 현재 시점에서는 최후의 보루 아니면 추천되지도 않는 형편이다. 역사가 오래된만큼 관련 자료도 대부분 오래된 편이며 아래의 대체 언어들이 CPU 코드에 커널 오프로딩 코드들을 자연스럽게 끼워 넣을 수 있는것에 비해 (CUDA의
<<<Triple Chevron>>>()과 같은) 커널 코드가 따로 놀아 개발도 불편한 편이다.
보통 여력이 되는 회사들의 경우 아래와 같이 독자적인 언어와 스택을 제공하지만 그럴 여력이 안 되는 경우 범용 규격인 OpenCL을 사용하는 편이다. 이러한 특성으로 FPGA등을 OpenCL 표준에 맞춰 사용하는 것도 가능하다.
OpenCL이 가지고 있는 문제는 OpenGL이 가지고 있는 문제들을 상당수 공유하고 있는데, 참여 회사가 많아 전용 확장이 난립하고 있고 결과적으로 프로그램(커널)을 실행하려면 하드웨어에 맞게 컴파일이 되어야 하는 특성상 실행시간 직전에 OpenCL 코드를 컴파일하게 되는데 이러한 문제로 첫 실행시 순간 반응성을 기대하기 어려우며, 하드웨어에 대한 최적화에 한계가 있고 컴파일러의 구현이 제조사에 따라 달라 버그나 성능 문제가 있다는 점이 꼽힌다. - CUDA - NVIDIA 이외의 그래픽카드에서 작동하지 않는다. 인공지능이 21세기 IT산업의 핵심 키워드로 떠오르고 개별 노드들도 간단한 추론 수준은 할 수 있도록 인공지능 가속기가 보편화됨에 따라 그 중요성도 수직상승했지만, 대부분 CUDA 사용을 전제로 개발되었기에 다른 회사의 그래픽카드 내지는 내장그래픽카드로는 아래와 같은 기술들이 대안으로 거론되고 있긴 하지만 사실상 인공지능 가속을 쓰기 어렵다. CUDA코드는 최종적으로 PTX어셈블리로 변환되어 하드웨어에서 실행되게 된다.
- MSL - Apple이 2014년 발표한 그래픽/컴퓨트 API인 Metal(API) (OpenCL+OpenGL) 에서 사용되는 언어이다. 이 기점으로 OpenCL 지원을 끊었다.
- HIP - AMD가 2016년 OpenCL의 답 없는 상황을 보고 독자적으로 만든 언어이다. OpenCL와 비교하여 언어만 다른것이 아닌 ROCm이라는 풀 소프트웨어 스택을 제공하고 있는것이 가장 큰 차이다. 다만 해당 스택이 등장하고 한동안 Linux만 지원해서 오히려 더 답이 없는 상황이었고, 2023년 겨우 Windows가 지원되었다. 소프트웨어 스택과 언어가 CUDA와 매우 유사한데 이는 의도한 것으로 아예 CUDA-HIP 코드 트랜스 컴파일러인 HIPIFY를 제공하고 있다.
- SYCL - Intel이 OpenCL을 밀어주다 OpenCL만 가지고는 안되겠다고 판단했는지 크로노스 그룹등과의 협력으로 자사의 모든 하드웨어 가속 프레임워크와 언어를 선보였다.[14] 마찬가지로 oneAPI 라는 소프트웨어 스택을 제공한다. SYCL는 다른 GPGPU용 언어와 달리 의존성 없는 네이티브 CPU코드를 생성하는것이 가능하고 백엔드에 따라 여러 하드웨어에서 실행하는 코드를 생성하는 것도 가능하다. (PTX, amdgcn, SPIR-V 등)
- GLSL/HLSL - 각각 Vulkan Compute와 DirectCompute에서 사용한다. 3D 그래픽에서 사용하는 셰이더 언어를 사용하고 런타임이 돌아가는 환경은 셰이더를 사용하는 3D 그래픽과 사실상 같으므로 실시간 연산에서 3D와 함께 사용하는 경우 오버헤드가 가장 적지만 반대로 보면 연산 부분만 떼서 순수 GPGPU용으로 사용하는 경우 다른 GPGPU전용 언어들에 비해 불필요한 요소가 딸려오는 등의 제약이 있다.
어쨌든 결과적으로 NVIDIA 외에 다른 GPU에서도 병렬 연산이 가능한 환경을 제공하기 위한 시도는 여러번 있었으나, 그냥 CUDA가 제일 성능이 좋고 호환성과 범용성이 뛰어나다 볼 수 있다. 사용자 입장에서 볼 땐 인공지능 연산(가속) 작업을 진지하게 하고 싶다면, 현 시점에서는 그냥 NVIDIA 그래픽카드를 사는게 여러모로 이롭다. 머신 러닝 쪽 연구도 이미 NVIDIA 기준으로 데이터가 쌓여버렸기 때문에 기타 GPU로 작업을 하려면 정보량과 적응성에서부터 유의미하게 차이가 난다.
7. 관련 문서
[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] SYCL 기반[9] 다만 CUDA/OpenCL과 같은 전용 셋에 비해 GLSL/HLSL과 같은 컴퓨트 셰이더의 경우 연산의 정밀도를 보증하지 못하고 메모리 접근도 한정적이지만 게임과 같은 곳에서는 별 문제가 되지 않기 때문에 이런 컴퓨트 셰이더를 사용해 파티클 등을 구현하는데는 아무런 지장이 없다.[10] GPU 8이라는 것은 GPU가 8개라는 의미가 아니라, GPU의 연산부가 구성되는 컴퓨트 유닛(CU)이 8개라는 뜻이다.[11] 단, OpenCL 2.0을 통한 HSA 사용은, 정식 지원이라기 보다는, 꼼수에 가깝고 제약도 심하다고 한다.[12] APU에서 L3 캐시 메모리가 들어간 건 라이젠 세대부터다.[13] 일명 L4 캐시 메모리라고도 부르지만, L3 캐시 메모리까지 사용되는 SRAM이 아니다.[14] 단 앞서 언급한것처럼 One API는 CUDA랑 목적이 같을 뿐이지 인텔의 모든 제품군을 다뤄야 하기 때문에 구조적으로 다르다.