근래의 GPU 중, 가장 뜨거운 감자는 RDNA 3/4의 dual issue는 ampere 이후의 GPU의 그것과 동일하다... 라는 이야기 입니다.

최근 제조사들의 가장 큰 문제점은, 

CPU는 더이상 코어 분석이 의미가 없는데 = 어짜피 컴파일러로 조율하는게 과반이라 의미가 없습니다. 코어 자체를 분석표로 보여주고, 

그래픽은 클러스터 뷰는 볼 필요 없는데 = 대부분 이건 비슷한데 가장 심각하게 봐야할 코어 자체의 변형에 대해선 잘 다뤄주지 않습니다. 

그 덕분에, GPU 코어는 각 제조사 모두 다르며, 이를 위한 드라이버 구현 난이도와 드라이버의 상태는 천차만별인데도 소비자를 납득시킬 수 없으며,

CPU는 소비자 UX를 책임지는 각 다이간 연결을 제대로 다루지 않아 소비자가 이걸 다시 체크해야하는 곤란한 상황이 연출되곤 합니다.

오늘은, 제 얕은 지식을 토대로 GPU 제조사간 변종을 설명하려 합니다.

엔비디아를 먼저, 인텔을 2번째, AMD를 3번째 순서로 설명하겠습니다. (글의 구성이 이렇게 된건 읽어보시면 납득하실거라 생각합니다.)

우선 엔비디아.

1. 가장 CPU에 가깝고, 가장 메모리 컨디션에 허덕이는 아키텍쳐

엔비디아를 대표하는 문구라고 말할 수 있을 것 같습니다. 엔비디아의 현 블랙웰, 그리고 과거까지 뻗어나가면 파스칼/맥스웰 아키텍쳐부터 엔비디아의 GPGPU 코어는 CPU의 그것에 최대한 가깝게 맞춰졌습니다. 그 중에서도 현재의 CPU에 가장 유사하게 변한건 암페어이며, 명령어 갯수 자체는 튜링 때 확립되었다 봐도 과언이 아닙니다.

파스칼 아키텍쳐에서 중점으로 볼 것 :

본격적인 dual issue warp scheduler 도입시기 입니다. 사실, volta는 조금 더 도입된 것들이 존재하나 근본적으론 pascal과 맥스웰이 정립한 상황이라 크게 다르지 않고 (정확히는 해볼 수 있는 종류가 늘어났다지, 버전이 완전히 달라졌다 보긴 어려워서)

버전이 완전히 확립된건 암페어였습니다.

암페어 이전까지의 엔비디아 GPGPU는  streaming multiprocessor (이하 SM) 당 1대 1 처리라고 보통은 알려져 있으나... CUDA를 통한 접근 시 1대 2가 가능은 했습니다. 다만, FP+FP의 쓰루풋이 불가능한 절반의 형태였죠. (볼타에서 좀 더 확장은 됩니다만, 여전히 볼타도 암페어 대비 제한적 조합만 가능했구요)

암페어에서 대놓고 자랑하던 완전한 dual issue WARP 스케쥴러는 2배 확장된 FP32의 디코더 확장에 있었습니다.

생각하기에 단순히 뻥카를 치느라 코어를 뻥튀기했다...라기보다, 근본적으로 쓰루풋이 정말 2배 늘어난 아키텍쳐였고, 이로 인해 싱글 SM의 사이즈는 매우 거대한 형태가 됩니다. 여기서 명령어 가짓수와 최적화가 이뤄진 것이 ada loverace, 블랙웰 입니다.

즉, 쿠다 코어가 2배 늘어났어요! 라고 표기하긴 했는데, SM 당 처리 가능한 싱글 사이클당 명령어가 정말 2배 늘어나서 가능한 표기였죠. CPU 쪽에서 이런 일이 일어나면 굉장히 골아픈 일이 되는데 (= CPU는 아키텍쳐가 좀 복잡합니다. 대표적으로 이런 확대를 실제로 일으킨 Lion Cove는, 대표적으로 128bit라는 메모리 채널 한계로 성능 향상이 5% 남짓이었죠. (192bit이나 256bit이었으면 사용자들은 램을 4채널 모두 채워야하는 번거로움은 있을지언정, 못해도 20%까지는 볼 수 있었습니다.))

GPU는 메모리가 고프면 PCIe 채널의 CPU를 괴롭히면 그만이라 괜찮습니다.

2. 엉거주춤, 그래도 빠르게 따라잡고 있는 인텔 Xe 아키텍쳐

엉거주춤...이란 것이, 정말 엉거주춤 따라잡았던 경향이 커서 그렇습니다. 일단 warp라고 위에서 설명했지만, 이건 NVIDIA에서 쓰는 용어고, 인텔은 SIMD입니다. 인텔 아키텍쳐가 좀 많이 둔하고, 이상하게 연산만 잘하는 경향이 큰건... 사실 정말 연산 처리 하느라 만들어놓고 게임용으로 열심히 팔아먹는 이상한 짓 (이거 왠지 코두리 시절에 본거 같지만)을 저지르는 문제가 큽니다.

한번 설명을 드리자면...

1. 배틀메이지부터는 dual issue를 만들긴 했습니다. 근데, pascal, volta 처럼 구세대의 엔비디아 아키텍쳐에 훨씬 가깝(...)습니다. 정확힌 XMX 엔진 때문에 INT+FP / FP + XMX 의 조합이 우선 구현되다보니 중간의 FP+FP가 안된(...) 구조입니다.

2. heterogeneous dual-issue 라고 보통 표현하는데, 여기에 XVE는 8 스레드로, 32스레드인 NVIDIA 대비 쓰루풋이 매우 적죠. 이걸 라운드로빈으로 처리하느라 구형 그래픽 라이브러리에서 매우 느린 속도를 보여주게 됩니다. 만약 구형 그래픽 라이브러리에 1대1 대응이 될 수 있을 정도의 스레드였다면 라운드로빈 처리로 가도 제 때 처리가 되긴 합니다만... 아쉽게도...

음... 그래서, 전체적으로 크다! 라고 누군가 그러긴 했습니다만, 그 크다란게 매트릭스 유닛이 큽니다. 게임용으론 아직(...)인 셈이죠.

 

vALU의 갯수가 2배가량 늘어났다면 NVIDIA와 동일한 수준의 확장이다! 그러니 2배로 쳐줘도 좋다! 겠으나... 디코더의 숫자는 그대로라 아무리 표기를 늘리고 싶어도, 기술적으로도 마케팅적으로도 거짓말이 되버립니다. 그래서, ALU 확장 대신 co-issue에 matrix를 추가하고...

 

기존의 호평받았던 아키텍쳐로 보수적인 확장을 일으킵니다.

 

그런 이야기죠. 트랜지스터 숫자는 거의 차이가 없는데...