본문 바로가기

Papyrus/Dizzy Report

After Bulldozer : 업체들의 만화경(萬華鏡)

10월 12일로 출시가 결정된 AMD 불도저 8150P의 성능은 대략적으로 i5 2500에 근접하는 것 같다. 안타깝지만 불도저는 애초에 기대했던 성능과는 다소 거리가 있으며, 가격 대 성능비로 승부해야 할 것 같다. AMD는 초기 불도저는 확실히 기대 이하라고 판단하고 있으며, 가급적 빨리 불도저 아키텍처를 개선한 파일드라이버(piledriver) 아키텍처로 넘어가려는 듯 하다. 즉, 시장에는 8150P와 같은 플래그쉽 모델만 풀릴 가능성이 높으며, 메인스트림급은 파일드라이버 아키텍처가 처음 적용되는 APU 트리니티(Trinity)에 집중할 가능성이 높다. 여기에 몇 가지 변수가 더해져 기대해 볼만한 부분이 생겼다.

무엇보다, AMD는 전통적으로 소프트웨어 지원이 만족스럽지 못했지만, 트리니티에 이르러서는 더 이상 이 문제가 AMD의 발목을 잡을 것 같지 않다. 며칠 전 MS의 빌드 컨퍼런스(build conference)에서 허브 서터(Hurb Sutter)는 C++ AMP(Accelerated Massive Parallelism) 라이브러리를 발표했는데, C++ AMP는 이종 병렬 코어를 사용하기 위해 DirectX, OpenGL, OpenCL과 같은 완전히 별도의 프로그램을 작성할 필요가 없다. Native C++과 유사한 형태로 하나의 호스트 코드에서 이들 디바이스 가속 성능을 최대한 활용할 수 있으며, APU는 이 환경에 가장 잘 어울리는 물건이다.

특히, 초기 APU인 라노의 경우 어느 환경에서도 그럭저럭 쓸만한 CPU 성능과 GPU 성능을 제공했는데, 풀로드 전력이 125 ~ 150W로 매우 경쟁력 있는 물건이었다. 그러나 외장형 GPU와 비교해 볼 때 아무래도 처지는 성능은 아쉬운 점이었다. 트리니티는 불도저 코어 확장판인 파일드라이버 아키텍처에 Radeon 7000 코어를 탑재하며, 병렬 벡터 유닛은 GPU를 사용하여(CPU-GPU 따로 국밥식 통합보다 한층 진보한 것이다) 훨씬 뛰어난 병렬 계산 가속 성능을 보일 것으로 예상된다. 특히, 트리니티는 2012년 1사분기에 등장이 예정되어 있는데 이것은 비주얼 스튜디오 2012 릴리즈에 맞추어 C++ AMP와 PPL의 수혜를 직접적으로 받을 수 있다는 뜻이다. AMD는 트리니티의 Windows 8 전용 드라이버가 준비되었다고 발표했는데, 이것은 단순히 카탈리스트 드라이버만을 의미하는게 아니다. 즉, C++ AMP와 같은 라이브러리에 맞춰 전방위적으로 활용 가능한 병렬 연산을 지원한다는 뜻이다(CUDA처럼).

AMD는 트리니티는 기존 라노 대비 최소 50% 정도의 GPU 성능 향상이 있을거라 주장하고 있는데, APU 부분에 있어서는 그간의 약속을 지켜온 AMD 행보로 봤을 때 기대되는 부분이다. 라노에서 50% 이상의 GPU 성능 향상이면 왠만한 3D 게임을 중간 옵션 이상으로 구동할 수 있다는 것이며, 특히 상대적으로 적은 전력 소모는 상당한 장점이 된다. 그리고, 가장 큰 골칫거리였던 소프트웨어 지원 문제는 MS C++ AMP라는 천군만마를 얻게 되었다. 물론, AMP는 꼭 트리니티만 대상으로 하는 것은 아니다.


그렇다면, 이쯤에서 CPU-GPU 융합이라는 궁극의 목적을 향해 달려가는 벤더들의 입장을 정리해봐야 한다.

인텔은 라라비 프로젝트를 나이츠 페리(Knights Ferry)에 이어 나이츠 코너(Knights Corner)로 현실화 시켰으며, 확실히 이것은 일반 시장이 아닌 HPC(High Performance Computing) 시장을 노린 것이다. 50개의 P5 기반 코어를 사용한 나이츠 코너는 울펜스타인 3D를 실시간으로 레이 트레이싱하는 놀라운 모습을 보여줬지만 이것은 일반 사용자를 대상으로 하는 것이 아니다. 나이츠 코너는 PCIe 인터페이스를 사용하는 애드온 카드로 선보였지만, 나이츠 코너가 NVIDIA나 AMD의 GPU 솔루션 같이 10 ~ 30만원대로 팔릴 일은 없을 것이다. 더구나 억지로 일반 사용자용으로 판매가 된다고 하더라도 코어 수는 반토막 날 것이며, 이를 지원하는(= 다수의 x86 병렬 코어를 제대로 사용하는) 소프트웨어가 없기 때문에 매우 불리하다. 뒤에 다시 이야기하겠지만, 라라비 유전자 코어의 장점으로 내세웠던 '궁극의 프로그래밍 모델'이 결국 인텔 패러렐 솔루션으로 수렴하는 것이라면, MS의 PPL, AMP와 비교해서 우위에 있다고 말하기 힘들다. 결국 라라비 프로젝트는 인텔 입장에서는 기술적인 실험으로 끝난 모양새고, 일반 사용자들 입장에서는 취소된 것과 다를 바 없다. 즉, 인텔은 그간 신경을 별로 쓰지 않았던 GMA 파생 코어를 거의 새롭게 디자인해야 하는 부담감을 안게 되었다. 물론, 그렇다고 하더라도 백지 상태에서의 출발은 아니다. 라라비 프로젝트를 진행하면서 얻은 경험이 있고, TBB(Threading Building Block)와 ArBB(Array Building Block)라는, PPL과 AMP에 대응하는 훌륭한 라이브러리도 존재한다. 아마도 GMA 파생 코어는 MS C++ AMP와 ArBB 모두에 대응 가능한 형태로 진화할 것이다.

그렇지만, 처지가 궁색해진 것은 사실이다. 더 이상 '궁극의 프로그래밍 모델'을 제시하며 호기롭게 '우리가 원할 때 출시한다'라고 말할 수 없게 되었다. 시간이 너무 지체되었고, 경쟁사들의 합종연횡을 너무 얕잡아 봤다. 아무리 인텔이라도 당장 GPU스러운 부분에서는 NVIDIA나 AMD에 비해 한심한 수준이며, 아이비브릿지 이후를 장담하기 힘들어졌다. 당장 AMD의 APU가 턱 밑까지 추격해 오고 있으며, 약속했던 일반 소비자용 x86 병렬 하드웨어가 없는 상황에서 다수의 x86 병렬 코어 대신 GPU를 활용하는 추세를 어떻게 되돌릴 것인가? 또, IPC를 언제까지 끌어올릴 수 있을 것인가?




AMD는 초기 불도저가 망작에 가까운 취급을 받고 있지만 AMD에 대한 전망은 나쁘지 않다. 특히 차기 APU인 트리니티는 매우 매력적이다. 인텔의 ArBB는 x86 코어만을 대상으로 하기 때문에, 크로스 플랫폼이라는 장점에도 불구하고 일반 사용자가 쓸 수 있는 하드웨어가 없는 이상 C++ AMP에 비해 활용도가 떨어진다. C++ AMP와 APU나 기존 GPU들의 조합에 인텔이 할 수 있는 일이라고는 GMA 파생 코어의 DirectX, OpenGL, OpenCL 지원을 크게 확장하는 것인데, 이것은 상대방의 홈 그라운드에서 경기를 하는 것과 같다. 특히 MS가 x86 코어가 아닌 GPU들의 병렬 연산 능력을 기반으로 C++ AMP를 개발했다는 것은 매우 의미심장하다. 즉, 적당한 CPU와 커스터마이즈 확장될 GPU의 바닥에서부터의 융합과 원칩화, 그리고 상대적으로 적절한 전력 소모는 차세대 XBOX를 겨냥했다고 밖에 볼 수 없다. 이변이 없는 한 차세대 XBOX는 APU를 기반으로 제작될 것이다. C++ AMP가 당장 차기 비주얼 스튜디오에서부터 지원된다는 것은 이런 예상을 뒷받침하는 요소 중 하나다. 2 ~ 4 코어 기반의 현 세대 소프트웨어을 구동할 때 성능이 시원치 않더라도, 쉬워진 병렬 프로그래밍으로 얻게 되는 소프트웨어들의 최종적인 성능은 APU를 더욱 매력적으로 보이게 만든다. 차세대 하드웨어가 통합 메모리 어드레싱을 지원하지 않는다면 대안은 보다 강력한 GPGPU 능력이며 디바이스 메모리와 메인 메모리 사이의 높은 대역폭이 필수적이다. 다시 말해, GPU는 AMP를 통해 드디어 쉐이더라는 족쇄에서 풀려났으며, 소프트웨어의 병렬화를 폭발시킬 것이다. 특히, 이런 부분을 적극적으로 활용하겠다고 공언한 Windows 8은 새로운 시대에 적응하지 못하면 도태될 수 밖에 없다는 선포다. 다만, AMP는 MS가 만든 것이기 때문에, AMD만을 위한 것은 아니라는 점이 불안 요소다. 인텔, NVIDIA 모두 AMP의 수혜 대상이지만 각자의 광산을 채굴하느라 정신 없을 뿐이다.

마지막으로, NVIDIA는 인텔의 라라비가 결국 일반 사용자와 거리가 먼 형태로 좌초되어 가는 만큼, 약속했던 통합 메모리 어드레싱 기능을 케플러나 맥스웰에서 현실화 시켜야 한다. CUDA의 더러운 프로그래밍 모델은 벌써 종말을 맞고 있으며, 인텔이나 MS의 병렬 라이브러리 정도의 지원이 없다면 NVIDIA는 새판짜기에서 한 발 물러나 MS나 인텔이 제공하는 강력한 병렬화 라이브러리에 자신들의 하드웨어가 지원되기를(혹은 드라이버나 제공하는 정도로) 기다려야 하는 신세로 전락할 것이다. NVIDIA는 이종 컴파일러 - 복잡한 메모리 모델이라는 짐을 지고 있는 CUDA가 자신들의 발목을 잡을 수도 있다는 사실을 인지해야 하며, Native 언어 차원에서 디바이스 프로그래밍 모델을 통합하지 못한다면 미래가 없다는 사실 또한 인지해야 한다. NVIDIA가 차세대 게임 콘솔 및 개발 플랫폼에서 주도적인 위치를 차지하며 살아남기 위해서는 이 방법 밖에 없다.