R9 퓨리의 문제점에 대한 고찰

 

 

290x가 출시된지 1년 반 이상을 지나서야 차세대 GPU가 출시되었는데, 그 주인공이 바로 R9 퓨리입니다. 퓨리는 타이탄 X를 겨냥하기 위해서 만든 제품이고 AMD의 플래그쉽이라고 할 수 있어서, 무엇보다 중요한 핵심은 HBM을 최초로 도입된 GPU라고 할수 있습니다.

 

HBM은 한마디로 말하자면 적층형 메모리 구조로 구성되어 있으며 스택당 4~8층으로 구성되는 방식입니다. GDDR5로는 메모리 대역폭을 향상 시키는데 한계가 있어서, GPU에서는 대역폭이 상당히 요구한다는 점입니다. HBM은 그 문제점을 해결하기 위해서이고, 앞으로 나올 차세대 콘솔, APU, GPU, HPC 등에 적용할 수 있다는 점입니다. 퓨리에 연산 유닛이 늘어남에 따라 대역폭을 받쳐줘야 되는 것도 이러한 이유입니다.

 

 

GDDR5는 GPU에서만 적용되었고(PS4 에서도 적용했었음) 무엇보다도 기판의 면적이 차지한다는 단점이 생긴다는 점입니다. 위의 사진을 보면 아시겠지만, HBM을 적용하면 GPU 코어 옆에 바로 붙어있어서 기판의 면적을 줄일수 있는 장점이 생깁니다.

 

일단 본론대로 말하자면 980이 출시되고 9개월 후에 R9 퓨리가 등장을 했지만, 벤치 결과에서는 타이탄 X 보다 낮은 성능으로 인해 실망한 유저들이 많을실겁니다. 특히 4K 쪽에서는 타이탄 X와 대등한 성능을 보이는데 이는 높은 대역폭 및 연산 유닛 덕분이라고 할수 있죠. 그러나 여전히 실망스러운 성능이 여전히 존재해서, 퓨리의 문제점이 뭔지 그리고 왜 그렇게 되었는지를 짚어보도록 하겠습니다.

 

- 첫 번째 문제점, 연산 면적에 편중으로 인한 저용량 L2 캐시 및 고정기능 부족

 

1. 픽셀 성능 문제
2900XT 벤치 결과에서 실망스러운 성능이 나왔는데 바로 AA 걸때 극심한 성능 하락입니다. 원인을 알고보니 처음에는 세이더에서 처리하는줄 알았는데 나중에 알고보니까 Render Back-end 쪽에 문제가 있다는 점입니다. 무슨 문제냐 하면 AA 유닛의 연산 성능이 안좋고 Z/Stencil 유닛이 적다는 점인데, Z Fillrate + AA 연산에서는 R6xx 계열에서는 G8x 계열보다 처참하게 낮은 성능으로 나왔습니다.

 

 

이러한 문제로 인해서 R7xx 아키텍쳐에 Render Back-end를 대폭 개선하게 됩니다. 개선점은 Alpha Fog 유닛을 없애고 AA 유닛의 연산 성능 향상 및 Z/Stencil 유닛이 2배로 증가했다는 점입니다. 왜냐하면 AA는 Z 버퍼와 뗄래야 뗄 수 없는 관계이기 때문이죠. 그 결과 AA 걸때 성능이 향상되었고 하락을 줄였습니다. 또한 FP16 컬러 포멧을 풀스피드로 FP32 컬러 포멧을 1/2로 동작했다는 점입니다.

 

그런데 문제점이 존재하는데 바로 블랜딩 효율입니다. G8x 계열은 블랜딩 효율이 높지만 1/2로 동작하게 되지만, GT2xx 계열부터 최근의 GPU 까지 블랜딩을 풀스피드로 동작하게 됩니다. 라데온은 여기서부터 문제점이 존재하는데, 바로 대역폭에 의존한 블랜딩 성능입니다. GCN 1.1때부터는 뒤늦게 블랜딩 효율을 강화된건 뭔가 아쉬움이 느껴집니다.

 

그리고 ROP 수 증가로 인한 대역폭 제약 문제인데, 라데온 5870에서 ROP 유닛을 2배로 증가함으로서 문제가 발생하게 됩니다. 무슨 문제냐 하면 아래 사진을 보시면 8bit 정수 컬러 포멧이 아닌 풀스피드로 동작하는 FP16부터 대역폭 부족으로 인해 제성능이 나오지 않는다는 점입니다.

 

 

페르미부터 델타 컬러 압축을 도입함으로서, 5870보다 픽셀 필레이트가 낮아도 대역폭 효율이 향상됩니다. 이로 인해 결과가 드러나게 되는데, 3DMark의 Color Fill 벤치결과에서 7970이 580보다 높지만 컬러 압축이 없어서 대역폭 만큼 나왔지만, 680은 컬러 압축이 들어가 있어서 Color Fill에서 7970과 대등하게 나오는 결과가 나오게 되죠. R9 285도 역시 컬러 압축 도입으로 Color Fill에서 780Ti보다 앞서게 됩니다. 그렇지만 단순히 픽셀 필레이트 수치만 봐서는 안되는 이유가 바로 컬러 압축 성능이 다르기 때문에 그런겁니다. 그래서 Techreport 사이트에서 텍스쳐 메모리 성능을 측정하는 이유가 컬러 압축 성능과 관련이 있어서 그런것 같습니다.

 

 

실제로 제가 560Ti로 3DMark의 Color Fill을 측정해봤는데, 위의 그림을 보면 알 수 있듯이, 코어 클럭이 대역폭 만큼 나와줘야 제성능이 나온다는 사실을 알게됩니다. 동일한 대역폭인데 코어 클럭만 높여서 FPS가 올라가는 현상이 생긴건 바로 컬러 압축이 들어갔다는걸 의미합니다. 대역폭이 낮을때 코어 클럭을 높여도 FPS가 올라가지 않는건 필레이트가 받쳐줄만한 대역폭이 부족하기 때문에 그런겁니다.

 

 

원래 픽셀 필레이트가 요구하는 대역폭(Z 및 텍스쳐 필레이트도 똑같이 포함됨)은 ROP 수 x 코어클럭 x 컬러 포멧의 버퍼로 계산해서 나옵니다. 예를 들면 8bit(R8G8B8A8) 정수 컬러에서 ROP 32 x 1000MHz x 4Byte로 계산하면 128GB/s 대역폭이 필요하다는 뜻입니다. 즉 FP16(R16G16B16A16)으로 계산하면 256GB/s로 나오고, FP32(R32G32B32A32)로 계산하면 512GB/s로 나옵니다. 이렇게 되면 1 세대 HBM 조차도 부족해지는데, ROP 64개일때 FP32로 곱해서 계산하면 무려 1TB/s에 달하는 살인적인 대역폭이 필요하게 됩니다. 이렇게 되면 2 세대 HBM 조차도 모자라게 되고, 특히 정밀도가 높은 컬러 포멧일 경우 ROP 64개 이상으로 가면 효율 문제가 생기기 때문에 '델타 컬러 압축'이 반드시 필요하게 됩니다.

 

 

290x가 64개 ROP를 가졌음에도 불구하고 컬러 압축이 없기 때문에 픽셀 필레이트가 요구하는 대역폭 부족으로 극심한 병목현상 및 텍스쳐 메모리 엑세스 성능이 악화 되는게 주 원인입니다. 즉 병목현상이 원인이 되죠. 한마디로 말하자면 픽셀 필레이트는 대역폭과의 싸움입니다.

2. 지오메트리 성능 문제
지오메트리 성능은 원래 전통적으로 라데온이 강세였습니다. 트라이앵글 셋업 및 래스터라이저 효율은 지포스 보다 뛰어나고 지오메트리 세이더도 역시 뛰어난 성능으로 나왔다는 점입니다.

 

그런데 페르미때부터는 지오메트리 성능을 대폭 개선했는데, 바로 트라이앵글 셋업, 테셀레이션 및 지오메트리 세이더 성능이 라데온 보다 대폭 향상되었다는 점입니다. 또한 래스터라이저 효율을 라데온 보다 2배로 높여서 4개로 늘렸다는 점인데, 삼각형을 그리는 픽셀수가 8픽셀로 향상하게 되죠. 라데온의 지오메트리 성능 부족은 5xxx 시절때부터 시작해서 GCN까지 이어지게 됩니다.

 

 

래스터라이저 효율은 테셀레이션 및 폴리곤이 상당히 많을때 제일 중요한 부분인데, 사이프레스에 듀얼 래스터라이저를 탑재하게 됩니다. 래스터라이저를 다중화 시키는 이유가 바로 '테셀레이션' 때문입니다. 특히 테셀레이션 팩터 수가 높아질수록 문제가 생기는데, 삼각형이 점점 작아지게 되는 현상을 말합니다. 밑의 그림에서 나왔듯이 테셀레이션 성능에서 팩터 수가 낮을때 7970이 압도적으로 높지만 팩터 수가 높아지면 560Ti 수준 그 이하로 떨어지게 나옵니다. 그 이유는 래스터라이저 효율 및 테셀레이션 연산 부족 때문일 수도 있습니다. R9 285의 테셀레이션 성능이 거의 670 수준쯤으로 끌어 올라갔지만 980에 비해 2배 정도 쳐지는건 여전합니다.

 

 

문제점을 알 수 있듯이 라데온의 래스터라이저는 밑의 사진을 보시면 알겠지만 16 픽셀에서 효율을 낼 수 있는 구조로 설계를 했기 때문에 8 픽셀로 삼각형을 처리할 경우 효율이 50%로 떨어지고, 4 픽셀로 삼각형을 처리할 경우 25%로 떨어지고, 1 픽셀로 삼각형을 처리할 경우 6%까지 급격히 떨어지게 됩니다. 반면 지포스의 래스터라이저 효율은 8 픽셀에서 효율을 낼 수 있는 구조로 설계했기 때문에 테셀레이션 팩터 수가 높아질수록 라데온 보다 유리할 수 밖에 없기 때문입니다.

 

 

그러므로 래스터라이저의 다중화가 되어야 되는 이유가 존재하는데, 삼각형이 작아질때 효율이 떨어지는걸 줄이기 위해서 입니다. 지오메트리 세이더는 연산 및 대역폭과의 싸움이고, 테셀레이션은 대역폭, 연산 및 래스터라이저 효율과의 싸움이니까요.

 

3. 양사의 GPU 연산의 발전 과정
라데온의 연산 성능이 좋은건 R3xx부터 거슬러 올라가는데, 지포스 FX의 낮은 연산이 주 원인이기 때문입니다. 그 후에 R5xx 계열이 지포스 7xxx 계열보다 성능이 좋게 나오는건 바로 픽셀 세이더 파이프 라인이 많아서 그런겁니다. 그래서 라데온 19xx 계열이 시간이 지날수록 발휘가 된건 세이더 연산에 비중을 차지한 게임이기 때문이죠. 이렇게 된건 ATI가 아키텍쳐를 설계할때 앞으로 텍스쳐보다 세이더 비중을 차지할 것을 염두해두고 있었기 때문일지도 모릅니다.

 

그리고 R600과 G80을 비교하면 확실히 다른점이 존재하는데, 전통적인 세이더 연산을 추구하는 R600 과 통용 계산을 추구하는 G80을 들수 있죠. R600은 제어 유닛, 명령어 및 상수 캐시가 단일로 구성되어 있으며 5D VLIW를 채택한 구조입니다. 반면 G80은 SM 마다 공유 메모리, 명령어 캐시 및 상수 캐시가 탑재되어 있고 제어 유닛이 SM 마다 구성되어 있으며 스칼라 MIMD를 채택한 구조입니다.

 

바로 여기서 갈리는데 G80은 SP 수가 적다는 단점으로 인해 플롭스가 낮죠. 그래서 비동기 클럭으로 작동해서 플롭스를 높이는 구조가 됩니다. 반면 R600은 SP 수가 G80 보다 훨씬 많아서 플롭스가 높죠. 그래서 SP 유닛이 상대적으로 더 많기 때문에 비동기 클럭이 필요가 없죠. 즉 SP 수가 많을때 코어 클럭으로 작동해도 문제가 없다는 점입니다. 왜냐하면 비동기 클럭(배수)은 SP 수가 상당히 적고 연산 면적이 상당히 작을때 적합한 구조이기 때문이니까요.

 

연산 성능에서 본격적으로 차이가 나게 되는건 R6xx 기반으로 확장한 RV770과 G8x 기반으로 확장한 GT200을 들수 있는데, 이때부터 플롭스 성능이 압도적으로 RV770이 더 앞서게 됩니다. 이는 SP 수를 대폭 확장했기 때문이지만, GT200은 SP 수가 너무 적지만 문제는 비동기 클럭으로 동작해도 플롭스가 낮다는 점입니다. Cypress와 GF100의 격차가 벌어지는데 여기서는 Cypress가 압도적으로 연산에서 앞서게 됩니다.

 

여기서 확실히 갈리는데 Nvidia의 설계 사상을 보니 통용 계산 위주로 가고 있는 듯한 느낌이고, AMD의 설계 사상을 보니 전통적인 그래픽 연산 위주로 가고 있는 느낌이 듭니다.

 

그런데 GCN때부터는 전통적인 그래픽 연산 위주가 깨지면서 VLIW 방식에서 벗어나 통용 계산을 강화한 아키텍쳐가 됩니다. GCN의 개선점은 CU 마다 스케쥴러가 존재하고, 명령어 및 스칼라 캐시가 3~4개를 공유하는 형태로 구성하고, 공유 메모리 용량 및 버스폭을 2배로 늘리게 됩니다. VLIW 방식에서 벗어나서 SP 효율이 향상되는게 중요한 변수 중에 하나입니다. VLIW는 원래 멀티미디어에 적합한 구조라서 단순하고 반복적인 계산에 유용하죠. 그러나 명령어 패키징 방식 및 컴파일러에 의존적인 방식이기 때문에 상황에 따라서 효율이 낮아지게 되는 단점이 생깁니다. 7970의 GPGPU에서는 확실히 뛰어났지만 게임에서 580을 비교해서 성능 차이가 많이 나지 않았다는 점입니다. 여기서부터 문제가 생기는데, 연산 면적이 커졌다는 것이고 고정 기능 부족으로 이르게 됩니다.

 

반면 Nvidia는 페르미의 교훈을 삼아 SM 부분에 불필요한 것들을 버리고 그래픽 연산 위주에 촛점을 둔 아키텍쳐가 나왔는데 바로 캐플러입니다. 캐플러의 SM 부분에서 개선점이 있는데, 복잡한 스케쥴러를 간소화된 스케쥴러로 바뀌고 프리 스케쥴러를 드라이버에서 맡기게 됩니다. SP 유닛의 파이프라인을 절반으로 줄여서 유닛을 대폭 확장하고, 전력 개선을 위해 배수를 폐지하게 됩니다. 왜냐하면 SP 수가 대폭 확장했기 때문에 배수 동작을 할 필요성이 없어지게 된거죠. SP를 확장한건 전통적인 세이더 연산을 대폭 증가하기 위해서입니다. 그외 공유 메모리 버스폭 128B로 증가 및 L2 캐시 성능 개선, 테셀레이션 강화 등 개선점이 존재합니다. 이렇게 개선함으로서 지포스의 플롭스가 높아졌지만 SP 효율이 좋지 못한다는 점입니다.

 

그 문제를 개선하기 위해 전력대 성능비를 개선한 맥스웰 아키텍쳐가 나오게 됩니다. 맥스웰의 SMM을 보면 GCN과 유사점이 있고, 기존의 캐플러보다 SP 수가 줄어들었지만 대신 스케쥴러 분산으로 인해 효율이 향상했다는 점입니다. 그리고 L1 캐시와 텍스쳐 캐시를 하나로 통합해서 메모리 계층이 정리되었고, 공유 메모리 및 레지스터 파일이 오히려 늘어났으며 무엇보다도 연산 면적이 줄어듬으로 인한 대용량 L2 캐시가 탑재했다는 점입니다. 이는 컴퓨팅 성능을 강화시키기 위해서 입니다. 밑의 그림을 보면 알수 있겠지만 980의 부동소수연산 성능은 타이탄보다 유닛 수가 적어도 고클럭과 SP 효율 증가로 대폭 향상했으니까요. 맥스웰의 이러한 설계는 공정이 늦어지고 무어의 법칙이 둔화되었기 때문에 모바일과 데스크탑을 통합하기 위해서 만든건 아닐까 합니다. 좀더 전력을 낮춰서 성능을 최대한 높이고 불필요한 유닛을 줄여서 대역폭 효율을 향상시킨게 주 핵심입니다.

 

 

이렇게 됨으로서 지포스의 연산 성능은 이제 라데온과 거의 다다른 수준으로 올라왔으니 양사의 평준화가 될수 밖에 없는 실정입니다. 공정이 발전하면 더욱 그러하니까요.

4. 공유 메모리
R6xx 계열에서는 공유 메모리가 없는 반면 G8x 계열에서는 공유 메모리가 존재한다는 점입니다. R7xx 계열부터 공유 메모리가 탑재 되어있었으니, SIMD 코어당 16KB 공유 메모리를 가지고 있고 버스폭은 32B나 됩니다. 반면 G8xx 및 GT2xx의 SM에 있는 공유 메모리 용량은 역시 16KB로 구성되어 있고 버스폭은 32B나 됩니다. 공유 메모리 전체 용량은 RV770이 160KB이라서 GT200 보다 훨씬 적지만, GT200이 훨씬 더 많은 공유 메모리 용량을 가지고 있다는 점입니다. 공유 메모리는 쓰레드들 중에 데이터를 재사용하기 위해서 입니다. 그래서 라데온의 적은 공유 메모리란 단점으로 인해 공정 미세화로 공유 메모리 및 버스 폭을 2배씩 증가시켜 왔는데, 그 결과 GCN이 압도적으로 캐플러를 압도하게 되는 결과가 됩니다. 그 후에 맥스웰은 SM 당 공유 메모리를 더 늘렸지만 여전히 차이가 존재한다는 점입니다.

5. 캐시

전통적인 GPU의 캐시는 텍스쳐 용도로 쓰여왔고 읽기만 가능했습니다. 원래 VRAM의 특성상 직렬로 엑세스하는 방식이기 때문에 용량이 매우 적은 텍스쳐를 불러오는데 채널당 대역폭이 너무 낮아서 대용량 텍스쳐를 불러올때 좀더 고속으로 처리하기 위해서 캐시를 도입한 것입니다.

L1 캐시는 텍스쳐 필터링 처리에 적합하고, L2 캐시는 큰 텍스쳐 범위(고해상도 텍스쳐 필터링) 및 컴퓨팅 연산 강화에 쓰입니다. 세월이 흘러 텍스쳐 연산에만 국한되어 있었던 캐시가 읽기/쓰기가 가능하며 컴퓨팅 처리가 가능하게 됩니다. 이는 페르미의 캐시쪽에서 근본적인 변화에서 비롯된 것입니다. 통용 계산에서는 캐시가 상당히 중요한 요소이기 때문이니까요.

그렇지만 문제점이 존재하는데, 캐시 용량이 너무 적다는 것입니다. 특히 대용량 텍스쳐는 캐시로 처리하기에는 적합한 구조가 아니기 때문입니다. 그러므로 대용량 텍스쳐, 인코딩, 대용량 데이터 처리 및 데이터 압축 등도 높은 메모리 대역폭이 필요하기 때문이죠. 밑의 그림(GPU가 아닌 CPU 기준임)을 보시면 알겠지만, 캐시의 특성상 데이터 크기가 커질 수록 캐시 대역폭이 대폭 떨어지게 되어서 결국 메모리 대역폭을 끌여다 쓰게되는 것 입니다. 캐시 성능을 개선한다고 해도 용량의 한계로 캐시 대역폭이 조금 높거나 대폭 깎일수 밖에 없으니까요. 한마디로 말하자면 캐시는 제어 및 용량과의 싸움이죠. 게다가 텍스쳐 유닛의 대폭 증가로 인한 높은 필레이트를 받쳐줄만한 대역폭이 상당히 고속으로 처리하는 캐시 밖에 없다는 점입니다. 대용량 텍스쳐는 VRAM에 매우 적합하지만 채널당 대역폭이 너무 낮아서 텍스쳐 필레이트를 받쳐줄만한 대역폭이 부족하기 때문입니다. 그 문제를 해결하기 위해 텍스쳐 압축이 존재하게 되죠.

 

 

퓨리는 64개 CU로 구성될 만큼 L1 캐시 전체 용량이 1MB 까지 늘어났죠. 원래 R7xx에서 GCN까지의 L1 캐시 버스는 64B로 되어있어서 퓨리의 L1 캐시 대역폭이 무려 4TB/s나 달합니다. 그런데 문제는 L2 캐시가 너무 적다는 점인데, 이는 공정의 한계로 인해 연산 유닛의 면적의 비중을 두다보니 여유 면적이 없기 때문에 그럴지도 모릅니다. 그러므로 대용량 L2 캐시 탑재는 그만큼 여유 면적이 많아야 하고 연산 유닛의 면적을 대폭 줄여야 실현이 가능하니까요.

 

양사가 일부 캐시 용량 및 버스폭을 공개되지 않는건 경쟁사 보다 캐시 용량 및 대역폭이 적을까봐 일부로 공개를 하지 않는게 비롯된 것일지도 모릅니다. 통가와 퓨리의 L2 캐시 용량을 공개하지 않는 것과 맥스웰의 명령어 및 L1 캐시 용량 및 버스폭을 공개하지 않는 것도 이러한 이유이기 때문이긴 합니다.

6. 레지스터 파일
R600의 레지스터 파일 전체 용량은 1024KB로 구성 되어있고, G80의 레지스터 파일 전체 용량은 1024KB로 구성 되어 있어서 양사가 동일하게 나왔다는 점입니다.

 

그 후, 레지스터 파일 용량이 압도적으로 RV770이 앞서는데 이는 SIMD(CU) 코어당 256KB 레지스터 파일이 장착되어 있어서 10개를 곱하면 2560KB 레지스터 파일이 나옵니다. 반면 GT200이 레지스터 파일 용량이 적다는 점인데, SM 코어당 64KB가 탑재되어 있어서 30개를 곱하면 1920KB 레지스터 파일이 나옵니다. 그 때부터 레지스터 파일 전체 용량이 라데온이 앞지르게 됩니다.

 

GF100과 사이프레스를 비교해본 결과 레지스터 파일 전체 용량에서 2배 정도 벌어지게 됩니다. 사이프레스가 압도적으로 GF100의 2배나 되는 레지스터 파일 전체 용량을 가지게 됩니다. GF100과 GT200을 비교하면 차이가 전혀 없는데, 그 이유는 고정 기능을 늘리기 위한 여유 면적을 두는 것 같습니다. 이러한 대용량 레지스터 파일은 SFU 및 DP 전용 유닛이 필요 없다는게 이점이 생기죠. 좀 더 범용적으로 처리할 수 있도록 하기 위해서 입니다. 그러다가 타히티와 GK104를 비교하면 차이가 더욱 벌어지는데 레지스터 파일 전체 용량은 타히티가 GK104의 4배입니다. 그런데 여기서 부터 문제점이 존재하는데 대용량 레지스터 파일은 다이 면적이 차지 한다는 점입니다. 이로 인해서 라데온의 고정 기능의 적음으로 그래픽 연산이 약화될 수 밖에 없겠죠.

 

 

- 두 번째 문제점, GCN 아키텍쳐 구조적 문제로 인한 확장의 어려움과 미세 공정의 지연

 

2011년 12월에 28nm를 적용한 GPU가 나오고 지금까지 신공정이 나오지 않았다는 점인데, 20nm는 원래 SoC 공정이며 저전력 모바일 칩을 만들기 위해서 쓰입니다. 그리고 무엇보다 GPU는 배선층이 많이 필요해서 비용이 많이 드는 문제점이 존재하기 때문이니까요. 그래서 양사가 28nm에 머무를 수 밖에 없는 상황이 된겁니다. 공정 미세화가 될 수록 단가가 비싸지고 어려움이 생기기 때문에 공정의 주기가 더 길어질 수 밖에 없는 실정입니다. 그러므로 아키텍쳐 효율 개선에 촛점을 두지 않으면 안되는 이유가 존재하니까요.

 

Nvidia는 20nm 설계를 포기하고 28nm로 유지했는데, 그 주인공이 바로 맥스웰입니다. 맥스웰의 핵심은 대용량 L2 캐시를 탑재하고 고정 기능을 늘렸다는 점이고, SM을 재구성해서 면적 효율을 높였다는 점입니다. 그로 인해 공유 메모리 및 레지스터 파일 용량을 대폭 증가하고, 제어 부분을 여러개로 분산시켜 SP 효율을 높이게 됩니다. 그 결과 SP 연산이 기존의 캐플러보다 향상되었죠.

 

맥스웰의 SM 면적이 작기 때문에 28nm에서 L2 캐시 및 ROP 유닛 등이 들어갈수 여유 면적이 생겨서 그렇습니다.  반면 GCN은 CU 면적이 상대적으로 큰데, 이는 대용량 레지스터 파일 및 공유 메모리, L1 캐시 등이 탑재되어 있어서 그렇습니다. 이로 인해 CU 면적이 커짐으로 인해 확장할 수 있는 여유 면적이 적어지게 되죠. 이렇게 되면 대용량 L2 캐시 및 고정 기능 탑재가 어려워지게 됩니다.

 

 

GCN 아키텍쳐의 구조적 문제점의 원인은 위의 사진을 보았듯이 바로 CU 면적이 크기 때문입니다. GCN은 28nm에 적합하지 않기 때문에 공정 미세화로 CU 면적을 줄여야 되는 이유가 생기는데요. 이렇게 되면 여유 면적이 생기게 되고 그 자리에 대용량 L2 캐시 및 ROP 및 지오메트리 유닛을 대폭 확장할 수 있으니까요. 연산 유닛에서 전력이 높기 때문에 연산 유닛의 면적을 줄여서 높은 전력대 성능비를 미세 공정으로 실현해야 되는 이유가 분명히 존재합니다.

 

- 세 번째 문제점, ROP의 대역폭 효율

 

원래 ROP 안에 캐시가 있고 AA 및 Z/Stencil, Color 유닛이 구성되어 있습니다. 지포스에서는 ROP 라고 부르고 라데온은 Render Back-end라고 부르는데 일반적으로 ROP라고 부릅니다.

 

ROP는 최종적인 픽셀을 화면을 뿌려주기 위한 역할을 해서 주로 프레임 버퍼를 저장하는 용도에 쓰기 위해서죠. 그런데 단순히 프레임 버퍼를 저장하기 위해서가 아니라 거기에 텍스쳐, 알파 블랜딩, AA, Z/Stencil를 처리하기 위한 용도로도 쓰인다는 점입니다. ROP는 메모리 컨트롤러와 1:1로 연결하여 병렬로 구성하고 있다는 점입니다. 그리고 ROP에 캐시가 존재하는데 주로 압축을 담당하는 역할을 합니다. 주로 AA 및 Z/Stencil에서 쓰이는데, 컬러 압축은 이때부터 존재했다고 할수 있죠. 컬러 압축은 주로 AA 연산에 쓰이고 프레임 버퍼 압축 기능이 당시에는 없었습니다.

 

ROP 수가 늘어나면 문제점이 존재하는데, 바로 메모리 대역폭(픽셀 필레이트가 요구하는 대역폭 덩어리)에 얽혀져 있고 픽셀 필레이트가 높아질 만큼 높은 대역폭이 필요하기 때문입니다. XBOX 360의 eDRAM이 존재한 것도 Z 및 픽셀 필레이트에서 높은 대역폭이 필요하기 때문입니다. 컬러 압축이 없었을 당시에는 이러한 무식한 방식을 사용할 수 밖에 없었으니까요. XBOX 기술자의 인터뷰를 보면 알듯이 필레이트에 필요한 대역폭을 제공하지 않으면 안된다고 했으니까요. Z 필레이트도 역시 마찬가지로 읽기/쓰기를 동시에 사용하기 때문에 높은 대역폭이 필요로 합니다.(Z 버퍼는 4Bytes가 필요해서 읽기/쓰기 조합시 8Bytes가 필요) 그래서 도입한게 '델타 컬러 압축' 및 'AFBC' 기술이 그 주인공입니다.

 

 

그 기술은 이미 페르미부터 탑재되어 있었고 압축비는 2:1 방식이었습니다. 그러다가 2 세대 맥스웰에 3 세대 델타 컬러 압축이 탑재됨으로서 압축비는 8:1로 늘리게 됩니다. 라데온도 역시 델타 컬러 압축 기술을 도입하였는데, 그건 통가때부터 존재하고 있었고 퓨리도 역시 그 기술이 존재합니다. 위의 그림에서 분홍색 픽셀로 되어있는게 바로 압축된 픽셀입니다. 분홍색이 아닌 픽셀은 압축되지 않는 픽셀이며, 압축율에 따라서 대역폭 효율이 달라집니다.

 

컬러 압축의 이점은 유효 대역폭을 높일수 있다는 점과 픽셀 필레이트가 요구하는 대역폭을 대폭 줄일 수 있다는 점입니다. 특히 대역폭을 상당히 요구하는 FP16 및 FP32 컬러 포멧 같은 경우는 컬러 압축이 더욱더 중요한데, 이는 살인적인 대역폭을 요구하기 때문에 그렇습니다. 만약 컬러 압축이 없이 FP32 컬러 포멧을 처리할 경우, 2 세대 HBM 조차도 부족하기 때문에 컬러 압축의 도입은 필수 불가결이 되죠. 그러므로 픽셀 필레이트의 대역폭 제약에서 벗어나기 위해서 '델타 컬러 압축'이 존재합니다.

 

컬러 압축에서 상당히 도움이 되는게 바로 텍스쳐 메모리 엑세스 성능 개선입니다. 텍스쳐 필레이트도 역시 대역폭을 요구하기 때문에 그 문제를 해결하기 위해 캐시 및 텍스쳐 압축이 존재합니다. 그런데 문제점이 존재하는데 높은 대역폭으로 처리하는 고속의 캐시가 있지만, 용량이 너무 적다는 단점으로 인해 대용량 텍스쳐 처리에 적합하지 않고 텍스쳐 필터링 처리에 적합합니다. 대용량 텍스쳐는 VRAM 처리에 아주 적합하지만, 여기서 문제점이 존재하는데, VRAM 대역폭이 상당히 낮다는 점입니다.

 

 

VRAM 대역폭에서 많이 차지하는게 ROP 및 텍스쳐이기 때문에 ROP와 텍스쳐끼리 VRAM 대역폭을 점유하기 위해서 서로 다투게 된다는 것입니다. ROP가 컬러 데이터 압축을 해서 VRAM 대역폭 소모가 대폭 줄어들게 됨으로서 VRAM 대역폭 점유는 텍스쳐가 차지하게된 것이죠. 그 결과 텍스쳐 메모리 엑세스 성능 향상과 동시에 VRAM에 저장한 대용량 텍스쳐에서 필레이트 향상에 득이 됩니다. 텍스쳐 필레이트만 높다고 해서 다 좋은건 아니라는건 텍스쳐 유닛이 780Ti보다 적은 980을 통해서 깨닫게 됩니다. 왜냐하면 텍스쳐 데이터 크기가 커질 수록 캐시 및 대역폭이 깎이고 결국 VRAM 대역폭까지 끌여다 사용함으로 인해 텍스쳐 필레이트 성능이 대폭 깎이게 됩니다. 텍스쳐 필레이트에서 5870과 470을 알 수 있는 것도 밑의 그림에서 답이 나와 있죠. 결국 5870의 높은 텍스쳐 필레이트가 텍스쳐 해상도가 커질수록 470과 동급이 된것도 캐시 및 대역폭 문제가 더 크니까요. 그러므로 텍스쳐 필레이트는 용량과 대역폭과의 싸움입니다.

 

 

그러므로 대역폭 효율에 좌우가 되는게 '압축'이며, 압축은 연산 성능이 받쳐줘야지 대역폭 효율이 높아지게 됩니다. 한마디로 말하자면 압축은 연산과의 싸움입니다.

 

 

- 결론

퓨리는 사실상 28nm 공정에서 연산 유닛만 왕창 때려박고 L2 캐시 용량이 적으며 ROP의 낮은 대역폭 효율 및 고정 기능 부족 등으로 인해서 HBM을 탑재해도 타이탄 X보다 못하는 성능으로 나왔다는 점입니다. 그러므로 퓨리는 실제 성능 위주에 동떨어진 아키텍쳐로 전락을 하게 되죠. 라데온의 제일 아쉬운게 그래픽 연산 부족이고요. 그리고 문제점이 더 있는데 라데온 드라이버의 기존의 DX 오버헤드가 지포스 드라이버 보다 높다는 점입니다. 맨틀의 등장 이후 Nvidia가 드라이버 최적화로 기존의 DX에 오버헤드를 줄였기 때문이죠. 퓨리의 강점은 DX12쪽에서 위력이 발휘되는데, 로우 레벨 API 기반으로 오버헤드가 낮고, 라데온에서 지원하는 비동기 컴퓨트를 사용할 수 있습니다.

 

그래도 라데온의 좋은 점은 연산에 대한 뼈대를 어느 정도 갖췄다는 점입니다. 왜냐하면 명령어 캐시 및 스케쥴러를 CU 마다 탑재 하는건 연산을 강화하기 위해 필연적이기 때문에 더 중요합니다. 지포스는 이제 연산에 대한 뼈대를 짓고 있는 단계로 왔으니까요. 지포스에 비해 뒤쳐졌던 공유 메모리 및 버스폭을 공정 미세화로 꾸준히 증가하여 마침내 지포스를 압도하게 됩니다. 공유 메모리는 주로 테셀레이션 및 지오메트리 세이더 등을 처리하기 때문에 중요한 부분 중에 하나입니다. 그리고 지포스 보다 많은 대용량 레지스터 파일인데, R6xx부터 GCN까지 CU(SIMD) 당 256KB(64KBx4)로 쭉 유지를 해왔다는 점입니다. GCN은 지포스와 다르게 아키텍쳐적으로 성능을 꽤 유지했다는 점입니다. 다만 연산 면적의 커짐으로 인한 여유 면적이 적어짐으로서 대용량 L2 캐시 탑재의 어려움 및 고정 기능 확장이 어려운 구조가 된것도 아쉬운 부분입니다. 전부 공정 미세화 상당히 늦어진게 결국 퓨리의 성능이 이렇게 만든거니까요.

 

대부분 유저들이 필레이트 및 유닛수를 보고 성능을 판단하는 경우가 있는데, 저는 그렇지 않습니다. 왜냐하면 유닛수를 곱한 클럭 만큼 나오는 대역폭 소모(대역폭 덩어리)를 줄이기 위한 압축 성능을 보고 평가를 하기 때문입니다. 그리고 데이터 크기에 따른 캐시 성능도 실제 성능과 좌우가 되기 때문에 더욱 중요하다고 생각합니다. 대부분 유저들이 유닛 수가 많으면 성능이 더 좋아진다는 환상을 가지는 경우가 많기 때문에 그렇습니다.

 

앞으로 아키텍쳐를 설계할때 무조건 유닛수 및 필레이트 수치만 내세운것 보다 실제 성능 위주에 촛점을 맞춰야 합니다. 실제 성능 위주란 연산 유닛, 고정 기능, 채널당 대역폭, 데이터 크기에 따른 캐시 성능, 압축 성능으로 인한 대역폭 효율 등 모든게 균형을 이루어서 병목 현상을 최소화를 시킨다는 의미입니다. 프로세서에서 모든게 조화를 이루는 성능으로 병목 현상을 최소화 시키는데 촛점을 둔 아키텍쳐가 나오는게 저의 바램입니다.