Nvidia의 14억개 트랜지스터 GPU : GT200이 Geforce GTX 280과 260으로 우리에게 다가오다.

14억개. 트랜지스터의 예술.

이 칩은 코드명 GT200이며 이것은 Nvidia의 G80과 G92 제품군의 뒤를 잇는 제품이다. 왜 이름 짓는 방법을 바꿨을까? GT는 "Graphics Tesla"를 의미하며 이것은 2세대 Graphics Tesla인데, 첫번째는 G80이다. 이 GT200은 2가지 종류로 오늘 발매되는데, 아래 사진으로 큰 다이가 그려져있다.

음...그래. 오늘 우리는 이것을 리뷰한다.
(이 다이 비교는 크기를 비교하기 위한 것이며 대조군은 듀얼코어 Penryn이다.) 

잠시 중요한 것들은 옆으로 밀어넣고, 약간은 쓸데없는 것들을 다루어 보자. Intel의 Montecito 프로세서 (그들의 듀얼코어 Itanium 2) 는 17억개가 넘는 트랜지스터를 갖고 있지만, 대부분은 L3 캐시에 들어가있다. (15억개의 트랜지스터가 24MB의 온다이 메모리를 위해 있다.) 이와는 대조적으로, Nvidia의 GT200 칩 상의 트랜지스터의 대부분은 연산력을 위해 쓰인다. 어찌됐든 간에 Nvidia는 이 트랜지스터들을 적절하게 사용하여 중점적으로 고려하는 사용자층에 특히 알맞다고 하지만, 이렇다고 우리가 하드웨어의 순전한 위력을 측정하지 말라는 법도 없다. 이 칩은 완전한 회로의 집합체이며 거대하다. 

TSMC에서의 300mm 65nm 웨이퍼 한장에서 94개의 Nvidia GT200 다이가 생산될 수 있다. 반면 극과 극으로, Intel은 300mm 웨이퍼에서 45nm Atom프로세서를 2500개 정도 생산할 수 있다.

이 하드웨어가 들어있는 저녁 접시 만한 웨이퍼에 트랜지스터 숫자가 그렇게 많아 보이지 않는다면, 그 이유는 이것이 65nm 공정에서 제조 되어서 그렇다는 것이 가장 큰 이유이다. 현재의 CPU는 45nm이며 GPU시장에서 Nvidia의 주된 경쟁자인, AMD는, 현재 7달 넘게 55nm 그래픽 칩을 제조하고 있다. 작은 제조 공정은 속도에 관한것과 칩의 온도가 낮아지는 이점만을 제공하는 것이 아니라, 또한 GPU 자체 생산 단가를 줄이는 데에도 확실히 일조를 한다. 왜냐면 제조 단가는 (ramping 생산 후) 웨이퍼에 기반하기 때문에, 한개 웨이퍼에 더 많은 다이를 집적할 수 있을 경우, 각기 다이 단가는 더 적어지게 된다. Nvidia는 제조 공정을 이번 주기에 변경할 시에 나오는 어떠한 연기 가능성도 원하지 않는 듯 보이지만, 이런 경우에는 차라리 위험을 감수하는 것이 나아보인다.

대신, GT200은 TSMC에서 현재까지 제조하였던 것 중 가장 큰 다이이다. 아주 불명예스럽게도, 나는 Nvidia가 이것을 아주 자랑스럽게 여길 것이라 생각치 않는다. 당연히, 이것이 이 엄청나게 큰 괴물에 대해 인상적인 느낌을 받지 않았다는 것은 아니다.

우리는 이 트랜지스터들에게서 무엇을 얻을 수 있을까? 오리지널 G80의 6억 9천만개 트랜지스터와 G92의 7억 5천 4백만개의 트랜지스터에서 14억개의 GT200으로의 변화는 적은 변화가 아니다. 한가지 주된 기능은 하드웨어 내에서 2배 정수 부동소수 연산 능력이다. (GT200에는 30개의 64비트 FP유닛이 있다.) 각기 SP 배열의 레지스터 파일의 크기는 2배가 되었다. MAD와 MUL을 동시 수행 연산할 때의 SP의 성능 향상을 약속 하였던 것도 대부분의 상황에서 이루어졌다. (G80은 이 작업이 가능할 것이라 추측 됐지만, 이런 작업이 작동했던 경우는 광고 했던 것보다는 훨씬 제한되어 있었다.) 그리고 SP의 숫자 또한 G80의 128개에서 GT200에서는 240개로 증가되었다. 이것이 의미하는 것이 무엇인지 더 이해를 잘 하기 위해, 우리는 G80과 GT200에 대한 차이점을 심도있게 다룰 것이지만, 그보다 먼저, 카드를 보아야 한다.

클럭 속도, 가격, 그리고 HDMI 정보

Nvidia는 2개의 GT200 부문을 오늘 발표 하였는데 제품명이 약간 다를 뿐이다. 새로운 제품명은 Geforce GTX로 부르며, 첫 두 카드는 GTX 280과 GTX260이다.

이것이 제품이다.

Geforce GTX 280

이것은 또한 자매품도 있다.

Geforce GTX 260

Geforce GTX 280은 240개의 1.3Ghz로 동작하는 스트림 프로세서를 장착하였다. 이것은 2.2Ghz(1107Mhz 코어클럭) 로 동작하는 1GB의 GDDR3 512비트 메모리 인터페이스를 가졌다. 나머지론 코어가 602Mhz로 동작한다는 것이다.

카드 자체로 236W까지 전송할 수 있는 파워 서플라이가 필요하며 6핀과 8핀 PCIe 전력 커넥터 모두 필요하다. (보드가 2개의 6핀 커넥터로 작동하지 않을 것이다.)

Geforce GTX280은 소매가로 650달러이며 7월 17일부터 구매 가능하게 계획을 짠 상태이다.

GTX260은 GPU상에서 2개의 텍스쳐/연산 클러스터를 사용불능으로 만듦으로써 총 코어 갯수가 192개로 줄어들었다.(그러나 여전히 G80/G92 기반의 어떠한 카드보다 많은 코어갯수를 유지한다.) SP들은 GTX260에서는 약간 느리게 동작하는데,(1242MHz vs. 1296MHz로, Nvidia는 27Mhz의 크리스타를 사용하였기 때문에 이런 웃긴 클럭이 나온다.)메모리는 대략 2Ghz에서 동작한다.(999Mhz 메모리 클럭, 1998Mhz 데이터 레이트) 이 GTX260은 또한 8개의 64비트 메모리 컨트롤러 중 한개를 잃어버려, 총 메모리 버스는 448 비트로 줄어들며 총 메모리 크기도 896MB로 떨어졌다.

GTX260은 최대 183W를 소비하며 2개의 6핀 전력 커넥터만을 필요로한다. Geforce GTX260은 400달러까지 내려서 설정되며 6월 26일에 구매가능하다.

이 GTX 280의 겉모양은, 비록 9800GX2에서 암시를 받았다 하더라도, IO 포트 옆의 큰 통풍구를 통해 열 방출이 잘 되게 설계되었다. 이 9800GX2는 열을 제거 하기 위한 곳에서 바깥 세계와의 소통이 넓게 되지 않았었다. 우리는 케이스가 없는 시스템을 동작시켜서 이것에 대한 문제는 테스트 중 보지 못했지만, 이 글을 읽는 독자가 우리에게 지적해줄 문제점을 말해 준다면 감사하겠다.

GTX 260과 280 모두 2개의 듀얼링크 DVI 출력을 가지고 있는데, 이것들은 당신이 원한다면 어댑터를 통해 HDMI로 변환시킬 수 있는 것이다. 카드의 위에 있는 커넥터를 이용하여 SPDIF를 통과 시킬 수 있어, 이것은 DVI-HDMI 어댑터를 사용할 때에 HDMI 출력으로 통과될 수 있다. HTPC 매니아들을 위해, GTX 280과 260은 아래 오디오 포맷을 HDMI를 통해 출력시킬 수 있다.

2채널 LPCM
6채널 DD 비트스트림
6채널 DTS 비트스트림 

애석하게도 8채널 LPCM이나 Dolby TryHD나 DTS HD-MA를 지원하지는 않는다. 

2페이지

Nvidia의 GT200 설계

이것이 Nvidia가 SP라고 불리우는 스트리밍 프로세서이다.

Nvidia는 각개 SP를 1개의 연산 코어로 부르는데, 실제상으로 맞는 말이다. 이것은 완전히 파이프라인화되어 있으며, 싱글 이슈에, 인 오더 마이크로 프로세서로 모두 2개의 ALU와 FPU로 이루어져 있다. 1개의 SP는 캐시를 갖고 있지 않아, 엄청난 수학 연산을 통한 동작이 아니라면 특별하게 엄청난 성능이 아니다. SP는 픽셀이나 버텍스 데이터에 대해 작업 하는 것에 대부분의 시간을 소비하기 때문에, 캐시가 없다는 것은 그렇게 큰 문제가 되지 않는다. 이름의 유사성을 배제 하고서, 1개의 Nvidia의 SP는 Cell 마이크로 프로세서의 SPE의 단순화한 버젼과 아주 유사하다. (또는 SPE는 Nvidia의 SM들 중 하나를 아주 단순하게 한 버젼과 비슷한데, 나중에 다룰 것이다.) Cell 안의 1개의 SPE가 7개의 실행 유닛을 가지고 있는데 반해, 1개의 Nvidia SP는 3개만을 갖고 있다.

SP 자체로는 확실히 쓸모가 없지만, Nvidia는 GPU를 제조하였으며 충분한 수의 이 작은 괴물들을 합친다면 높은 병렬화 작업으로 인해 주어진 그래픽 렌더링에 대해 생산적인 일을 시작할 수 있을 것이다.

이것이 Nvidia가 SM이라고 줄여 부르는 Streaming Multiprocessor이다.

SM은 SP의 배열이며, 8개가 들어가있는데, 2개 더 들어가 있는 프로세서는 Special Function Unit(SFU) 라고 부른다. 각각의 SFU는 4개의 FP 곱셈 유닛을 내장하고 있어 (사인, 코사인 같은) 추상적 연산과 보간법에 쓰이는데, 후자는 이등방성 필터링 같은 계산에 쓰인다. 비록 Nvidia의 언급에 특별한 것이 없더라도, 우리는 각각의 SFU가 또한 완전히 파이프라인 되어 있고, 싱글 이슈인 인 오더 마이크로 프로세서라는 것을 추론해낼 수 있다. 여기 있는 MT Issue 유닛은 그룹 내의 모든 SP와 SFU에게 명령을 전달한다. 

게다가 SM 내의 프로세서 코어는, 아주 작은 명령어 캐시를 갖고 있어, 읽기만 가능한 데이터 캐시와 16KB의 읽기/쓰기를 하는 공유 메모리를 갖고 있다. 이 캐시 크기는 목적에 맞게 아주 작은데 왜냐면 현대의 데스크탑 마이크로 프로세서와는 다르게, 이 캐시에 들어가는 데이터 셋이 작기 때문이다. 각각의 SP는 32비트 부동소수 값으로 옮겨가더라도 각개 픽셀에서 작업하는데, 한개 픽셀에 관련된 데이터도 엄청나게 많다. 16KB 메모리는 Cell의 로컬 저장소와 비슷한데 이것은 캐시가 아니지만, 소프트웨어적으로 관리하는 데이터 저장소로 이것의 지연시간은 항상 예측이 가능하다. 1개 SM에서 이렇게 많은 코어에서는, 제어와 예측성이 모든 작업을 효율적으로 만듦에 있어 아주 중요하다.

한발 뒤로 물러서면 Texture/Processor Cluster (TPC)를 보게된다.

G80/G92 TPC (왼쪽) vs. GT200 TPC (오른쪽) 

Nvidia는 그들의 GPU 아키텍쳐를 모듈러 방식으로 하려는 목적이 뚜렷하게 설계하여서, 1개 TPC는 몇개의 SM으로도 구성이 가능하다. G80 아키텍쳐에서는 2개의 SM으로 구성되었지만 GT200 아키텍쳐에서는 3개의 SM으로 구성되었다. 

그러나 TPC의 구성 요소는 바뀌지 않았다.; TPC는 SM으로 구성되어 있고, 약간의 제어 회로와 텍스쳐 블록이 다이다. SM은 8개의 SP와 2개의 SFU로 구성되었다는 것을 기억한다면, 이것은 전체 24개의 SP와 6개의 SFU로 (SFTU가 아닌) 이루어진 클러스터가 GT200에 있다는 것이다. (G80에서는 16개의 SP와 4개의 SFU) 텍스쳐 블럭은 텍스쳐 어드레싱과 필터링 회로, 그리고 L1 텍스쳐 캐시를 포함한다. 

모듈러 정책은 Streaming Processor Array (SPA)에서도 계속되는데 이것은 TPC들로 조합된 것이다. 

GT200 SPA는, 240개의 SP가 있다.

 G80에서 SPA는 8TPC로 구성되어 있었지만, GT200에서는 10개로 증가되었다. 각각의 TPC는 현재 2개에서 3개로 올라갔으므로, GT200의 최종 연산력 증가분은 G80의 87.5%가 되었다. 

그리고 이것이 G80/G92 인데, TPC당 2개의 SM과 8TPC의 영향으로 128SP만 있다.

GPU의 앞부분에서 프로세싱 코어의 전체 배열에 대한 부하 량을 평준화 시키는 스케쥴러와 제어 회로를 볼 수 있다. 또 다른 끝부분에서 L2 텍스쳐 캐시와 최종 필터링 제어와 프레임 버퍼로의 데이터 출력을 담당하는 래스터라이제이션 프로세서를 볼 수 있다. 

이 모든 것의 완성체가 새로운 GT200 GPU이며, 240개의 SP들과, 160KB의 로컬 메모리, 더욱 작아진 캐시 양으로 TSMC의 65nm 공정을 이용하여 만든 14억개의 트랜지스터가 Geforce GTX 280과 260의 심장이다.

14억 개의 트랜지스터들.

7억 5천 4백만개의 트랜지스터들

중국인구보다 많은 트랜지스터가 칩 안에 있으며, 우리가 리뷰 했던 어느 칩보다도 크고, 컴퓨팅 성능이 뛰어난 칩이다.

3페이지 

훨씬 많은 연산, 약간 많은 텍스쳐링 

Nvidia의 GT200 GPU는 240개의 스트리밍 프로세서 덕에 이전의 G80 설계에서의 128개 디자인보다 확실히 연산력이 증가하였다. 그 결과, Nvidia의 GT200 GPU는 이것의 이전 세대 설계보다 트랜지스터 숫자의 엄청난 증가를 시연하게 되었다. (G80에서의 6억 8천 6백만개에서 14억개로)

GT200의 연산력 증가는 텍스쳐 연산력의 증가와 직접적으로 연관되지는 않는다. 이전 페이지에서 우리는 텍스쳐/프로세싱 클러스터가 2개 쉐이더 멀티프로세서에서 3개로 늘어났고, 또한 현재 칩 내의 총 TPC가 Geforce 8800GTX의 8개에서 10개로 늘어났는지를 강조하였었다.

Geforce 8800GTX에서 쓰인 오리지널 G80 코어에서, Nvidia의 텍스쳐 블록은 이렇게 생겼다.

각기 블럭 안에서 4개의 텍스쳐 어드레싱 유닛과 8개의 텍스쳐 필터링 유닛을 가졌었다.

Geforce 8800GT, 8800GTS 512와 9800GTX가 썼던 G92로 옮겨가면서, Nvidia는 텍스쳐 어드레스 유닛을 2배로 늘림으로써 어드레스/필터링 유닛 비율을 1:1로 실현하였다.

Geforce GTX 280/260에서 쓰인 GT200은, Nvidia는 어드레스와 필터링 비율을 1:1로 유지하였지만 SP대 텍스쳐 프로세서의 비율은 늘리게 되었다.

이전 세대 설계에서 TPC당 (16 스트리밍 프로세서이거나) 8어드레스와 8필터링 유닛을 가졌었는데, GT200에서는 같은 8어드레스, 8 필터링 유닛을 갖지만 24SP들로 더 커진 TPC를 가지게 된다. 

아래 표는 세대간의 사양 차이를 나타낸다.

연산으로는 87.5%의 향상이 있지만, 텍스쳐 프로세싱 파워는 25%정도의 향상이 있다. 이 비율은 몇년간 Nvidia가 설교한 것에 상응한다. : 시간이 지날수록 게임들은 더욱 복잡한 쉐이더를 구동시키며 이로인해 텍스쳐 연산력에 발목을 잡히지는 않게 될 것이다. 이것이 거짓이었다면 우리는 GT200이 G80과 동일 클럭에서 25%정도의 성능 향상만을 보았을 것이다. 

또한 (Geforce 9800GTX같은) G80이나 G92 기반 설계를 넘는 GT200의 성능상의 이점은 우리가 테스팅하는 게임들이 연산력에 얼마나 제한을 거느냐에 따라 검증될 것이다. 

GT200에서의 증가하는 연산/텍스쳐 능력의 비율은 몇년 동안 Nvidia의 아키텍쳐에서 명확히 드러났는데, 운이 없는 Geforce FX시절때부터이다. Nvidia는 Geforce FX에서 메모리 대역폭을 희생하여, (ATi의 Radeon 9700pro에서는 256비트의 버스를 쓴 것에 반해) 좁은 128비트 메모리 버스를 장착하였으며 훨씬 더 위력적인 연산 엔진을 제조하는데 초점을 맞췄다. 불행하게도, 이 도박은 그 당시에는 잘못된 것이었으며 (메모리 대역폭의 부족 말고도 많은 이유로 인해) Geforce FX는 힘겹게 경쟁하였지만, 오늘날 우리는 아주 다른 세상에 살고 있다. 오늘날 GPU들에게는 화면 상의 각기 픽셀에서 동작하는 복잡한 쉐이더 프로그램과 일정량의 연산력을 필요로 한다. 

래스터라이제이션 처리량의 증가 

GT200의 텍스쳐 연산 능력의 25% 증가에는, Nvidia가 GPU에 2개의 ROP 부문을 추가라는 이유가 있었다. Geforce 8800GTX가 6개의 ROP 부문을 갖고 있었는데, 각기 ROP는 클럭당 최대 4픽셀을 출력할 수 있는 능력이 있었는데, GT200은 2개의 ROP 부문을 추가하였다.

Geforce 8800 GTX와 9800GTX에서 클럭당 최대 24픽셀을 출력할 수 있었던 것에 반해 8개의 ROP 부문으로 인해 GT200은 클럭당 최대 32픽셀의 출력을 낼 수 있게 되었다. 

G80/G92의 픽셀 혼합 속도는 1/2 이었는데, 이것은 클럭당 24픽셀을 출력할 수 있다면, 혼합은 클럭당 12픽셀만 가능하다는 것을 뜻하였다. 65nm로 줄어듦과 동시에 재 설계로 인해, GT200은 픽셀의 출력과 혼합을 동일한 속도로 할 수 있게 되었다. - 각기 클럭 당 32픽셀이라는 것이다. 

이것으로 GT200이 AA에서의 모든 상황과 불 효과 그림자에서 비선형적 성능 향상을 냈다. 이것은 혁명적인 변화이지만, 이것은 실제로 G80/G92를 넘은 GT200의 여러가지 향상이 더해진 것이다.

4페이지

Derek이 기술적으로 - 15세기 베틀 기술이 귀환하였다.

왜냐면 이것이 멀티스레드 였으니까...

이것이 무시무시하지만, Nvidia는 그들의 아키텍쳐를 우리에게 좀 심도있게 설명하였으며 그들은 제직기술에서 전문용어를 갖고 온 것이 괜찮다고 생각한다. 그러나 그만큼 당신은 동작하는 것을 당신의 눈으로 보고 싶을텐데, 이것의 동작하는 과정을 설명하는 것도 그만큼의 가치가 있다.

옷을 짤 때, 날실은 병렬 스레드의 수직 그룹으로 씨실이 이것들을 통과하여 지나갈 때 잡아주는 역할을 한다. 내가 보기엔 아주 합리적인 것이며, Nvidia는 SM에서 실행되는 페러럴 스레드의 묶음을 날실로 결정하였다.

이 방직기 꼭대기에 달려있는 스레드의 그룹이 보이는가? 그것이 날실(warp)이라고 불리우는 것이다.

각기 SM은 8개의 SP를 가지고 있으며 G80은 TPC당 2개의 SM을 가지고 있어(총 16개의 SP) 이 16개의 스칼라 유닛을 통해 4개씩 연산되는 것이 자연스럽게 맞아 떨어진다. 우리는 이것이 일반적인 경우가 아니라는 것을 알지만, GT200의 TPC당 3개의 SM의 묶음을 보면 어떻게 Nvidia의 통합 아키텍쳐가 계획되어 있는지를 확실히 배우지 않아도 좀 웃긴 점이 보인다. 각기 SM의 스케쥴러는 모든 클럭 사이클에서 작동하기 위해 새로운 워프를 갖고 오며, 스케쥴러는 반속도로 동작하기 때문에 이 과정은 항상 SM에서의 나머지 퍼스펙티브에서의 다른 클럭 사이클에서 마쳐지게 된다. 각기 날실은 (픽셀 쉐이더 내에서는 8개 쿼드의 그룹) 32스레드의 그룹으로 이루어져 있어 (쉐이더 프로그램이나 GPU 컴퓨팅에서 말하는 커널같은)명령어 흐름을 공유하게 된다.

날실의 32스레드는, 16 스레드의 2 그룹의 흐름이다. - 1개 그룹이 위에 묘사되어 있다.

같은 쉐이더 프로그램을 실행하여 만들어진 각기 다른 워프는 코드경로를 지날 때 완벽히 독립적이지만, 워프 내의 모든 스레드는 같은 명령어를 실행시켜야 한다. 이것은 예측입도가 32스레드라는 것을 의미한다. : 32스레드의 모든 블록은 (모든 워프) 모두 각각 독립적으로 분기될 수 있지만, 1개 이상의 스레드가 나머지에 반하여 다른 방향의 워프 분기를 가진다면 이 안에 있는 모든 다른 싱글 스레드는 양 코드 경로에서 모두 실행해야 한다. 각기 스레드는 경로에서의 결과만을 갖고 있어 이것은 스레드 당 적절한 경로를 동적으로 예측하는 분기 결과를 이용하여 따라가는 것으로 기대된다. 각각 SM은 동작 중 동시에 32개까지의 워프를 가질 수 있다. (G80은 24개) 10개의 TPC는 각각 3개의 SM을 갖고 있어, GTX280에서는 동작 중 최대 3870 스레드까지를 처리할 수 있다.

8개의 SP들과 2개의 SFU로 이루어져 있는 각기 SM은 SP에서는 클럭당 8개의 명령어를 연산할 수 있는 능력이 있고 SFU에서도 클럭당 8개의 명령어를 연산할 수 있다. ((부동소수점 덧셈과 곱셈이 혼합되어 있는)MAD는 가장 복잡하다.) 워프들은 4클럭 이상을 소비하여 (아마 픽셀에 대한 4개의 쿼드로)16 스레드의 2 그룹 안의 SM들에게서 연산된다.

이것이 재밌는 부분이다.

SP와 SFU들은 SM 스케쥴러의 퍼스펙티브의 대체 클럭 사이클로 스케쥴된다. 이들은 독립적인 워프를 실행한다. SP들은 1개 클럭 사이클에서 스케쥴 되며 SFU는 이 다음에 스케쥴된다. 각기 이것들은 이 다음 스케쥴이 되기 전에 모든 워프의 연산을 마칠 수 있는데, 이것은 (SP와 SFU와 연관이 있는데) 마지막 워프에서 스케쥴 되고 4클럭 후에 일어난다.

그러나 잠시만. SM들이 듀얼이슈 MAD+MUL을 지원한다고 하지 않았었나? 음, G80 발매때로 돌아가보면, Beyond3d는 이 상황의 실상을 탐구 하는 것을 아주 멋지게 하였다. SFU가 “듀얼 이슈” MUL을 조종할 수 있고 삼각함수 계산과 속성 보간법 같은 다른 역할에 대해 시간을 할애 한다는 사실로 보아, 실제적으로 가속하는 경우의 하드웨어의 능력이 있더라도 듀얼 이슈의 장점은 확실히 감소될 것이다. 그러나 이 스케쥴링 사실은 이 문제가 훨씬 더 복잡해지게 만든다.

G80이나 GT20에서의 장점을 이용하여 듀얼이슈 하드웨어에서의 이점을 받는 코드를 쓰기 위해, 워프는 MAD에 대한 SP 상에서 스케쥴 되어야 하며 이때 이것은 SP에서 다시 실행하기 전에 SFU에서 재 스케쥴 되어야 한다. SFU가 속성 보간법이나 기하학 연산 같은 작업중이라면, 워프는 SP에서 MUL을 연산하기 위해 재스케쥴 되며 우리는 이 때 듀얼 이슈의 속도를 체감할 수 없게 된다.

Nvidia는 우리에게 “클럭 당 일관성 있는 작업을 하려고 SFU에서 MUL을 수행할 때 약간의 스케쥴링/이슈 문제가 있다. 우리는 GT200에서 이것을 고쳤다.” 라고 말해주었다. 이것은 G80/GT200 상에서의 우리가 알고 있는 스케쥴링에 대한 지식에 비추어 보면 아주 당위성 있는 것이다. MAD+MUL 듀얼이슈인 경우 그들의 하드웨어 성능에 대한 속도 향상을 이루기 위해 필요한 것은 SFU 상에서 실행될 때 이런 경우에 대한 우선순위를 확실히 하는 것이 도움이 될 것이다. 코드마다 MAD+MUL이 들어가지는 않으므로, 이런 경우 다른 작업보다 이런 것에 높은 우선순위를 줌으로 하여서 하드웨어의 사용률을 최적화 하는 데에 도움이 될 것이다. SFU 상에서 무작위 MUL들을 무작정 시작하는 우를 범하지 말아야 하는데, 이들 특별 함수도 완료는 시켜야 하지만, SFU 상에서 선택한 MUL의 부분을 밀어부치는 것은 (SP에서 방금 실행된 MAD가 바로 따라오는) 특정한 경우에서만 제한적으로 도움이 될 것이기 때문이다.

확실히 Nvidia의 주된 초점은 적절한 사용과 우선순위이다. 어떠한 프레임이든 언젠가는 완료를 해야되기 때문에, “듀얼이슈”를 구현하는 것은 다음 프레임 완료에 있어 더 중요한 것을 넘는 중요도를 갖지 않아야 한다. 그러나 어떻게 이것을 조종하는가를 구성하는 것은 아주 중요한 일이다. 실시간 컴파일러들은 이것의 큰 부분이지만, 아키텍쳐 내에서 내부 스레드 관리와 스케쥴링 또한 무시할 수 없는 것이다. Nvidia는 현재 자체 테스트에서 그들의 “듀얼이슈”를 도입한 이후 93~94%의 효율을 가졌다고 말하는데 이것은 G80보다 확실히 높은 수치이다. 실사용 상에서 결과는 낮아질테지만, 이것의 목표는 사용 가능한 하드웨어의 최대 효율을 낸다는 것을 잊어버리면 안된다. SFU는 MAD+MUL을 매 클럭마다 도와주지 않기 때문인데 이것이 중요하지 않다는 것도 아니다.

이 모든 상황 자체가 우리에게는 복잡한 감정을 남기게 된다. 하드웨어는 아키텍쳐만 보고 이해한다면 자체적으로 “듀얼 이슈”의 능력을 갖지 못한다. 경쟁적인 업계에서의 그래픽 하드웨어 기술의 혼란은 지난 몇 세대동안 일반적이었으며, 우리는 이것을 수용할 수 있다. 우리는 하드웨어가 실제로 무엇을 하는가에 대해 알고 싶긴 하지만, 우리는 하드웨어 특징 같은, 하드웨어가 그저 특정한 아키텍쳐 설계를 가지고 효과를 구현하는 것을 설명하는 것에 대해 더 기쁨을 느낀다. 그러나 이런 하드웨어에 도입한 기능이 실제적으로 비슷한 방법으로 성능을 내지 않는 경우, 비교를 적당히 할 수가 없어 약간은 실망스러워진다.

그리고 이것에 대해 우리는 약간 갈등을 겪는데 Nvidia의 설계는 실제적으로 아주 멋지기 때문이다. 속성 보간법은 항상 완료 되어야 하며, 복소수학을 위한 하드웨어 확보 또한 아주 유용하다. 그러나 SP들 상에서 이런 분리된 고정 함수 보간자나 복소수학의 테일러 확장을 하는 것보다는, Nvidia는 2가지 목적을 모두 수행할 수 있는 하드웨어를 제조하였으며 이것으로 인해 작동하는 프로그램의 명령어 스트림에서는 안성맞춤으로 되어진 MUL들로 인해 약간의 시간 절감 효과를 볼 수 있다.

Nvidia가 그들의 아키텍쳐를 Intel의 CPU 설계 같이 공개 했다면, 도움은 주지 못해도 이것에 대해 감동 받을 것이다. 이 “사라진 MUL”은 Nvidia의 듀얼이슈 “하드웨어” 같은 문제점을 보이지 않았다. ; 우리는 이때까지 Nvidia가 그들의 SM들의 사용률을 향상시키기 위해 각기 다른 유닛에서의 스케쥴과 멀티태스킹의 능력을 치하하곤 했다.

5페이지

GT 200에서의 성능 향상

Nvidia는 우리에게, 기능과 기술상에 있어 주된 향상점과 추가된 유닛 수가 명확한, G80에서 GT200까지의 이런 주된 변경점이 있는 리스트를 제공하였다. 이 분명하지 않은 변화는 G80에서 진화한 2세대 Tesla 아키텍쳐를 만들게 되었다. 첫번째로, G80에서 GT200으로의 발전을 퍼센트로 빠르게 보도록 해보자.

 

드라이버와 프론트 엔드 하드웨어 간의 통신은 통신 프로토콜의 변화를 겪으면서 향상되어왔다. 이들 변화는 드라이버와 하드웨어 간의 더욱 향상된 데이터 이동을 촉진시키는 것을 돕도록 설계되는 방향이었다. G80/G92에서는, 프론트 엔드는 색인되어 있는 초기 페치를 수행하고 전(全)속도로 강제로 하드웨어를 동작 시킬 때 “데이터 어셈블러”로 인해 충돌이 일어나게 된다. 이것은 GT200에서는 어셈블러와 프레임 버퍼 간의 메모리 크로스바에 대한 몇몇 최적화를 통하여 고쳐지게 되었다.

전(前)-변형 캐시 크기는 늘어났다. 이 캐시는 viewport clip/cull stage를 위해 준비된 변형된 버텍스와 지오메트리 데이터를 저장하기 위해서이며, 크기를 늘린 결과 몇몇 파이프라인의 성능 저하와 더 빠른 통신도 가능하게 되었다. 겉보이게 셋업 속도는 G80과 비슷해 클럭 당 1개의 데이터까지 처리하지만, 셋업 엔진에 부여하는 것들은 큰 캐시로 인해 더욱 효율적이 되었다.

Z-Cull 성능도 향상되었는데, Early-Z 거부 속도비율이 ROP의 추가로 인해 늘어나게 되어서, GT200은 클럭당 32개 픽셀을 제거할 수 있다.(8xAA에서는 256샘플까지)

가장 막연한 향상이 바로 이것이다. : “레지스터 할당, 명령어 스케쥴링, 명령어 이슈에서 확실한 미세 공정으로 인한 향상이 되었다.” 이것들은 겉보기에는 GT200 상에서의 “듀얼 이슈”를 더 좋게 만든 향상처럼 보이지만, 여전히 실제로 무엇이 다른가에 대해서는 모호하기만 하다. 이것은 TPC 또한 향상되어 텍스쳐 유닛과 SM간의 스케쥴링에 대해 언급한 것이다. 다시한번 말하지만, 더욱 자세한 사항이 나와야 가치를 판단하겠지만, 최소한 이 영역에서는 그렇게 도움이 될 만한 부분이 현재로써는 없다.

레지스터 파일들? 2배로! 

이들 하찮은 SP들은 개개가 싱글코어 마이크로 프로세서이며, 이것들은 또한 그들 고유의 레지스터 파일을 가지고 있다. 우리의 CPU 아키텍쳐 기사를 기억할지 모르겠는데, 레지스터들은 CPU 코어 내의 실행 유닛에 직접적으로 제공하기 위해 쓰이는 저장 영역이다. 프로세서의 레지스터 파일은 레지스터들의 모음이며 G80의 SP에 정확히 얼마만큼의 숫자가 있었는지 모르더라도, GT200에서는 이 수가 2배가 되었다는 사실에 주목할 필요가 있다.

Nvidia의 데이터가 커진 레지스터 파일 크기로 인해 10%의 성능 향상이 된다는 것을 시연하고 있다.
(출처 : Nvidia)

Nvidia가 계속적으로 연산량이 많아지는 이 추세에 계속 투자한다면, 레지스터 파일 사용률도 또한 올라갈 것이다. 많은 연산은 많은 레지스터의 사용을 뜻하는데, 이것은 또한 레지스터의 고갈이라는 큰 가능성을 시사하기도 한다. 프로세서의 레지스터가 고갈된다면, 아주 느린 메모리로부터 데이터를 뒤바꾸기 시작할 것이며 성능은 엄청나게 저하될 것이다.

당신이 아직 Nvidia의 GT200의 연산력에 대해 그렇게 인상을 받지 못했다면, SP당 2배로 늘어난 레지스터의 크기는 (칩 내에서는 240SP들로 곱해야한다.) 당신으로 하여금 인상을 받도록 할 것이다.

2배 정확도 향상, 1/8의 성능

GT200 GPU와 이 기반 카드의 또다른 주된 특징은 2배 정밀도 부동소수 연산에 대한 하드웨어적 지원이 되겠다. 배정밀도 부동소수 연산은 64비트 폭으로 단정밀도 부동소수 연산의 32비트와 대비된다.

GT200 내의 240SP들은 현재는 단정밀도만 가능하므로, 이등른 64비트 연산을 수용할 수 없다. 하드웨어 레벨에서 배정밀도를 추가해야 하는데 Nvidia는 실제적으로 1개의 배정밀도 유닛을 쉐이딩 멀티프로세서마다 포함하여, 전체 칩 안에 도합 30개의 배정밀도 유닛을 추가하였다.

GT200에서 단정밀도 하드웨어에 비한 배정밀도 유닛의 비율은 어이없을 정도로 낮은데, 여기서 알리고자 하는 것은 이것들은 그래픽 래스터라이제이션에서는 대부분 쓸모가 없다는 것이다. 그러나, 이것은 과학 연산이나 GPGPU 어플리케이션 같은것에서는 아주 쓸모있다.

3D게임이 배정밀도 부동소수 연산으로 확장할 것이라는 것은 말도 안되는 생각인데, 특히 오늘날 아직도 많은 쉐이더들이 8비트 정수와 16비트 부동소수 작업을 많이 하는 것을 보면 더욱 그렇다. 뭔가 있다면, 우리는 배정밀도 부동소수 연산의 사용을 지오메트리와 버텍스 연산에서 처음 사용하는 것을 볼 것인데, 이것은 색 정밀도보다 우선되어 필요한 부분이다. – 결국 3D 파이프라인 전체에 지원하기 전 마침내 버텍스 쉐이더에서 단정밀도 부동소수가 처음 시작된 것과 비슷하다.

지오메트리 전쟁 

ATi의 R600은 지오메트리 쉐이딩이 아주 양호하다. RV670도 마찬가지이다. G80은 이 영역을 확실히 휘어잡진 못하였다. 물론, 게임은 지오메트리 쉐이더의 광범위한 사용을 하지 않았는데, AMD나 Nvidia 모두 강력한 성능을 제공하지 않았으며 다른 기술이 하드웨어의 사용을 훨씬 효율적으로 만들었기 때문이다. 이것은 Nvidia에게는 아주 호재였으나, 그들은 이 문제를 영원히 무시하지는 못하였다.

GT200은 G80을 상회하는 향상된 지오메트리 쉐이딩을 가졌으며 현재는 작년에 우리가 바랬던 것과 동등한 정도이다. 우리는 Nvidia을 그렇게 탓할 수는 없는데, 이런 새로운 기능에 대해 계속적으로 시행착오를 거치며 개발자들이 계속적으로 흥미를 가지고 사용할만한 모델을 예견하기 때문이다. 현재 우리는 개발자가 지오메트리 쉐이딩으로 무엇을 할지를 지켜보는데, 이런 노력을 지원하기 위해 하드웨어 개발을 이런 방향으로 하는 것은 아주 적절하다.

GT200은 G80에 비해 확실히 지오메트리 성능이 향상되었다.
(출처 : Nvidia)

버텍스 데이터 생성은 Nvidia의 G80에서 특히 약한 부분인데, 그리하여 GT200은 G80의 데이터 스트리밍 출력 능력의 6배 성능을 가진다. 물론 스케쥴링 향상이 이 모든 것에 영향을 끼치겠지만, 그들의 지오메트리 가용성을 향상시키기 위해 그들의 내장 출력 버퍼를 6배 늘리는 것 외에 다른 것을 했는지에 대한 여부는 불투명하다. 확실히 이것은 이전에 비해 부족하지만, 이것은 지오메트리 쉐이더 사용을 중요시하게 여기며 이것으로 장점을 얻으려는 개발자들에게는 아주 희망적인 이야기이다.

6페이지

Derek의 SP 파이프라이닝과 TMT에 대한 추측
임시적인 멀티스레딩

우리는 각기 SP 내의 명령어의 실행이 파이프라인화 되어 있다는 것을 안다. 우리는 SP가 클럭 사이클당 1개의 명령을 수행하는 처리량을 가졌다는 것과 Tesla 아키텍쳐가 보통 실행을 대비하고 있는 또다른 스레드를 갖고 있을 확률이 많기 때문에 연산 결과나 메모리 수행을 기다리는 시간이 필요치 않아 파이프라인의 성능 저하가 없다는 것을 알고 있다. 이러한 상황은 SM과 함께 SP들의 퍼스펙티브에서 매번 4클럭마다 스위칭이 일어나며, 이 4 클럭에서 32스레드에는 현재 활성화 되어 있는 것과 실행되는 워프가 주어질 것이다.

실행중인 스레드의 구성은 SM의 프로세스 워프가 16스레드의 두 묶음으로 나뉘어 진다는 것 외에는 알려진 것이 없다. 이것은 가능성을 만들어내지만, 어떻게 그들이 그룹 안의 16개 스레드가 있는 8개의 물리적 SP에 명령어를 발행하는 지에 대해 직접적인 추측을 하기에는 너무나 많은 가능성이 있다. 즉흥적으로 SP들이 Hyperthreading같은 하드웨어 레벨의 SMT(동시 멀티스레딩)을 지원하는지 물어본다면, 우리는 좀 이상스러운 답변이 나올 것이다. : “…이것들은 파이프라인화된 프로세서이며 파이프라인 내에서 많은 스레드의 동시 실행을 지원한다.” 이것은 전등이 켜지는 것 같이 우리에게 이 아키텍쳐의 수많은 잠재적인 장점을 깨우치게 하는 것이었다. 

처리량이 SP에서 클럭당 명령어 한 개를 처리할 수 있는 것이라면, 그리고 각기 SP가 4클럭 사이클 동안 워프에서 4스레드를 조종할 수 있다면, 이 때 파이프라인은 실제적으로 파이프라인 내의 각기 다른 스레드에서는 모든 스테이지마다 1개의 명령어를 실행하는 데에 작동하는 것이다.

이것은 실제로 정교하게 짜여진 TMT나 임시 멀티스레딩으로 알려진 멀티스레딩 기술이며 소프트웨어가 아닌 각기 다른 시간 영역에서 프로세스의 다수 스레드를 가상의 병렬 프로세서로 처리 하지 않는 SMT와는 다르다. TMT는 새로 나온 신기술이 아니고 당신이 이것이 나왔을 때를 등한시 했을 뿐이다. : TMT는 싱글 CPU가 많은 스레드로부터 동작할 때 이들을 놀리게 하지 않기 위해 몇세대동안 프로세스에 이용해왔던 방식이다. 데스크탑 CPU에서는 상황에 따른 전환이 일어나 또다른 스레드가 작동을 시작하기 전 싱글 스레드가 잠시동안 서비스되는 course-grained 멀티스레딩에 아주 친숙하다. 이 상황에 따른 전환은 특정 횟수의 사이클이 지난 후나 높은 우선도의 스레드가 IO나 메모리 등을 기다려야 하거나 프로세서를 필요로 할 때 일반적으로 일어난다. 

좀 더 재미있는 것은 fine TMT와 course-grained TMT간의 차이에 있다. (우리가 쓰는) Course-grained 방식에서 프로세서의 모든 파이프라인 스테이지는 1개의 판단에서 오는 명령어 흐름을 서비스하는데, fine-grained에서는 파이프라인이 내려갈수록 모든 스테이지마다 정황상 판단을 하여 다수의 정황상 판단 조건을 가지게 된다. 이런 fine-grained 방식은 아주 다루기가 어렵지만, Nvidia는 몇몇 트릭으로 인해 이것의 관리를 수월하게 만들었다.

G80과 GT200에서는, SP들이 모든 파이프라인 스테이지에서 각기 다른 스레드에 대한 명령상에서 작업하더라도 판단을 워프마다 할 수 있다는 사실로 인해, 그들은 모든 파이프라인 스테이지에서 각기 다른 판단 상의 작동을 하지 않는다. 각기 SP는 같은 워프에서의 열에서는 4개 스레드를 연산하며 이것은 판단 상에서도 동일하게 작용한다. 왜냐면 4파이프라인 스테이지 이상을 가진 SP들이 1.5Ghz라는 엄청난 속도로 동작하기 때문에, 우리는 여전히 파이프라인 그 자신이 1개 이상의 판단 스위치를 갖고 있는 것을 볼 수 있지만, 이것은 여전히 모든 스테이지마다 각기 다른 판단을 갖고 있다는 것을 뜻하는 것은 아니다.

그래서 뭐가 대단하다는건가? 지연시간에 대한 무관련성과 파이프라인 거품과 성능 저하를 최대한으로 피할 수 있다는 것이다.

현대의 CPU 아키텍쳐에서, 우리는 한 개 스레드가 작동되고 나서 또다른 스레드가 작동 될 때 같은 명령어를 쓰는 것을 많이 보아왔다. 모든 것을 작동할 때 가능한한 매끄럽게 하려면 우리는 클럭 사이클 당 발행할 수 있을 만큼의 클럭 사이클 당 명령어 폐기를 해야하지만, 이것은 보증되는 것은 아니다. 데이터 의존성, 메모리 구동, 캐시 미스와 파이프라인 내에서 명령어를 기다리는 것 같은 것으로 인해 클럭 사이클은 작업완료를 할 수 있는 가능성을 없애고 계속적으로 구동되어 버린다.  이런 종류의 지연시간을 많이 줄이기 위해 기술발전이 되고 있다. 파이프라인 스테이지 간의 데이터 이동은 1개의 명령어가 이전 결과에 대해 의존적인 경우를 대비하기 위해 필요하다. 이것은 파이프라인 한 개 스테이지의 결과를 한 개 전의 스테이지로 돌려 놓음으로써 명령어가 데이터를 기다릴 필요가 없게 하는 것이다. Hyperthreading도 또한 더욱 독립적인 명령어를 채워 사용률을 늘리기 위해 1개의 파이프 라인을 2개의 다른 프로세서로 보이게 하여 파이프라인 사용률을 늘리는 데에 도움을 주는 기술이다.

Fine-grained TMT는 데이터 포워딩에 대한 필요성을 불식시켜 버리는데 파이프라인을 내려가면서 명령어간의 의존성이 없기 때문이다. : 판단은 각개 독립 스레드에 대한 1개 명령이 발행되고 난 후 전환되며 Nvidia의 스케쥴러가 적절히 작동한다면 워프는 그들의 데이터가 가용될 때까지 재 스케쥴이 필요치 않게 된다. Hyperthreading 같은 기술들은 필요치가 않은데 파이프라인이 이미 모든 스테이지에서 독립적인 스레드에서의 명령어로 가득 찼기 때문이다.

각기 다른 쉐이더 프로그램과 (버텍스, 지오메트리, 픽셀 같은) 각기 다른 종류의 쉐이더 에서의 워프들의 풀을 관리 한다는 것은 SM으로부터 제공받는 모든 워프에서 같은 데이터에 대해 대기하는 경우는 최소화 되지만, 같은 쉐이더 프로그램으로부터 다수의 워프를 가지는 것은 데이터가 한번 도착 시에 1개 이상의 워프의 연산을 사용가능하게 하는 것으로 괜찮은 생각이라는 것을 뜻한다. 물론, 1개 TPC의 SM은 텍스쳐 주소, 필터와 캐시를 공유하기 때문에, TPC 상의 SM들로 비슷한 워프를 불러 오는 것도 괜찮은 생각으로 이리하여 1개 스레드에 의한 텍스쳐 색인은 다른 스레드에서도 또한 유용할 것이다. 이 균형은 알아 두면 아주 흥미롭겠지만, 우리는 이 멋진 아키텍쳐의 세부 사항에 대한 정보를 확실히 알기  전에 Intel이 그래픽 시장에 들어오는 것을 기다리는 중이다.

SP는 얼마나 깊은가?

파이프라인 깊이에 대해, Nvidia는 이것에 대해 어떠한 도움도 주지 않지만, 몇몇 단서를 토대로 우리가 어떤 것을 유추해 내는지 보라. 아주 무지막지하게, 우리는 Nvidia가 작동 중에 채워야 할 스레드보다 더 긴 파이프라인을 가진 칩을 만들지 않을 것이라는 것은 안다. 우리는 G80과 GT200이 클럭이 아주 유사하여 같은 파이프라인을 가진다고 추측하며 우리는 G80에 기준선을 두어 놓은 것을 토대로 유추할 것이다. G80은 동작 중에 SM마다 24개의 워프를 갖고 있으며 각개 워프는 SP당 4개의 파이프라인 스테이지를 점유하는데, SP들은 96스테이지 이상 갖고 있지를 못하게 된다. 물론, 말도 안되는 방법이지만, 파이프라인 내에서 실행되는 어떠한 워프라도 완료 전까지는 재스케쥴이 되지 않는다고 예측한다면, 우리는 높은 비율을 가지는 워프는 실행하는 것보다는 기다린다는 예상이 가능하다.

이 가정을 토대로 우리는 최소 48스테이지라는 것을 알게 되며, 내 생각으로는 이것이 파이프라인에 있지 않으면서 작동해야 하는 스레드가 2/3 정도로 되기를 원한다고 추측한다면 대충 맞아 떨어지므로, 계산을 하면 32 스테이지 파이프라인의 실제적인 파이프라인이 나타나게 된다. 정리를 해보면, 최소한 이것들은 4개의 스테이지를 갖고 있는데, 만약 더 적다면, 높은 우선도의 워프는 모든 기회에서 판단 변경을 하지 못하기 때문이다. : 첫번째 스레드에서 스케쥴된 명령어는 완료되어서 나가야 한다. 8개 스테이지를 갖는다면 최대의 유연성을 부여하게 되어 워프는 준비만 되지 않았다면 언제나 스케쥴 될 수 있는 기회를 얻게 된다. 이것은 또한 대부분의 3개 판단이 파이프라인의 각기 다른 곳에서 활성화 되게 하며, 이런 종류의 fine-grained TMT가 장점을 제공하는데 반해, 이것은 파이프라인에 접근 시킬 판단의 숫자를 많이 도입시킬 수 없다. 그리고 이것은 단정밀도 부동소수 유닛에 대해 MAD를 1.5Ghz 속도에서 8개 사이클에서 수행할 수 있게 하는 설계를 가능케 하지만, Itanium을 예로 들면 이것은 쓸데없는 낭비로 보이기만 한다.

Nvidia에서의 도움이 없이는 딱 집어 정확한 크기를 알기는 어렵지만, 최소한 8에서 거의 32스테이지까지가 우리가 그들의 아키텍쳐를 볼 때 적절한 정도로 보고 있다. 그러나 전력대 성능비가 Nvidia의 주된 관심사인 것을 알기에 우리는 16 파이프라인 스테이지보다 높을리는 없다고 확신할 수 있다. 모두가 (특히 Prescott과) 일반적으로 Penitum4가 주된 열원인 것을 기억하며, 이것은 무조건 스테이지가 깊으면 전력 효율적이 아니라는 것을 말한다.

현재로써 우리가 확신할 수 있는 숫자는 최소 8스테이지이며 아키텍쳐와 전력 소비면 모두를 고려한다면 16 정도가 우리가 최대로 예상할 수 있는 정도이다. 물론, 이것은 모두 다음 단계로 가는 것에 대한 첫번째 발걸음이다. Anand의 원래 추측은 12~15정도였으나, Derek 은 코어의 단순함 때문에 8스테이지 정도를 적절점으로 단정지을 수 있었다. (SP 내에는 디코드나 스케쥴링 스테이지가 없다.) 그래서 이 모든 파이프라인 스테이지에 대한 추측이 유용한가? 그렇진 않을 것이다. 근데 재밌잖아!

자 이제 모든 SP 수행에 있어 같은 지연시간을 갖는다는 Nvidia의 아키텍쳐 의견에 대한 다른 모든 세부 사항으로 혼합된 의견이 당신을 짜릿하게 할 것이다. 이 방법은 모든 것을 시계같이 딱딱 맞추어 작업하게 한다. : 1개가 들어가면, 1개가 나오고, 아주 적은 오버헤드에, 가능한한 가장 간단히. 모든 오버헤드는 SP의 외부에서 관리되며 연산 코어는 어떻게 해야 최상의 성능을 낼 수 있는지에만 초점을 맞출 뿐이다. (나머지 칩들이 그들의 작업을 하는 동안에도 여전히 데이터를 공급할 것이다.)

업데이트

많은 사람들이, 특히 GT200 발매 기사 같은 엄청난 기사에는, 내가 쓰려고 했던 글자만 많은 페이지들을 피한다. 특히 나는 모두가 즐길수는 없는 저급레벨의 기술적인 세부사항에 민감하다.

이 최근 GPU 아키텍쳐로의 공습에서, 우리는 G80과 GT200 SP 파이프라인 깊이에 대한 추측을 하는 시간을 가졌다. 우리의 추측으로는 이 속도로는 다른 아키텍쳐가 아주 깊은 파이프라인으로 쓸데없는 전력낭비를 하기 때문에 8스테이지 기반의 깊이로 기본을 잡았었다. 우리는 이것에 대해 너무 낮은 숫자로 추측을 했다는 것을 알게 되었다. (Anand 왈 : 에헴, 실제로 누구는 15를 생각 했었다구.)

우리의 독자 중 하나인 Denis Riedijk는, 우리에게 Nvidia의 포럼과 CUDA 프로그래밍 가이드를 알려주었다. 이들 정보원은 적절하게 명령어 지연시간을 숨기기 위해서는 SM마다 6개의 활동 워프가 필요하다고 밝혔다. 이것에 대해 수학적인 계산을 한다면 워프 전의 24사이클의 효율적인 지연시간은 명령어 스트림 내의 다음 명령어를 연산하기에 스케쥴 될 수 있다. 각기 워프는 SM 내에서 연산을 하기 위해 4사이클을 점유하며(워프에서의 4 스레드들은 8개의 SP들에서 각각 연산된다.) 6*4는 24이다. 또한 당신은 6개 워프*32스레드/워프=192스레드가 나오는 것을 볼 수 있으며 192스레드/8개 SP들= SP당 24개의 스레드가 나오는 것을 볼 수 있으며, 사이클 당 1개 명령어의 처리에 24사이클이라는 처리량이 필요하다.

처음엔 이들의 스케쥴링 하드웨어가 몇몇 빠른 워프들의 스케쥴링 조종을 하지 못하거나 로컬 메모리 관리에 있어 읽기 후의 쓰기 의존성을 덮어버리기 위해서 어떠한 이유로 인해 지연시간을 필요로 할 것이라는 생각을 했었다. 그러나 스레드를 통한 읽기에서 Denis는 파이프라인 길이가 이런 지연시간을 부여한다는 그럴싸한 지적을 하였다. Nvidia의 Mark Harris가 쓴 글의 일부에서 :

“(1.35Ghz 클럭을 가진 8800GTX에서) 지연시간은 대략 22클럭 이며, 이것은 (ADD, MUL, MAD 등의) 수학 명령을 실행하기 위해 모든 워프에서 4클럭을 점유한다. “

CUDA 포럼에서는 또한 G80/GT200의 SP 레지스터 파일의 크기 또한 암시하였다. Harris는 ALU 지연시간을 숨기는 방법으로 사용중인 가용 레지스터 공간의 25%정도를 확보하거나, 스레드당 42레지스터를 확보하는 것도 그 중 한가지라고 언급하였다. 이것은 스레드 당 168 레지스터의 G80이나 336 레지스터의 GT200을 말하게 한다.

http://forums.nvidia.com/index.php?showtopic=66238&hl=6+warp
http://forums.nvidia.com/index.php?showtopic=47689&hl=6%20warps&st=40

이것은 우리에게 좀 더 폭넓은 시점을 제공한다. Nvidia는 CUDA 개발자들에게 하드웨어의 효율적인 사용을 위해 더욱 자세한 세부사항을 부여할 것이다. 확실히 우리는 Intel이 그들의 기술적 세부사항을 모두 털어놓을 정도로 자비심이 있으리라 믿지 않는다. : 개발자들은 그들의 코드 대부분을 얻기 위해 세부적인 것을 알기를 원하며, 이것은 Nvidia가 목표로 하고 있는 HPC 마케팅으로 접근해갈수록 실현되고 있다. 연산 클러스터를 위해 몇백만 달러를 지불하는 회사들은 연산력만을 보고 판단하지 않는다. : 그들은 모든 사이클에서의 출력을 원하고, 필요로 한다.

7페이지

Nvidia의 DX10.1과의 더러운 거래와 어떻게 GT200이 이것을 지원하지 않았는가

많은 사람들이 GT200 하드웨어에서의 DX10.1 도입을 보고 싶어한다는 것을 알지만, 실현되지 않았다. Nvidia는 DX 10.1의 몇몇 기능들을 이번 세대 그들의 하드웨어에서는 넘기기로 하였다. DX9에서 SM 2.0을 지원하는 하드웨어 같은 상황에서는 성능이나 효율이 떨어지면서 SM3.0 하드웨어 같이 사용할 수 있었다. DX10.1은 새로운 등급의 그래픽 질이나 성능을 사용가능케 하지는 않지만, 개발자에게 그들의 코드를 단순화 시키는 많은 옵션들을 가능케 하여 특정 효과나 기능을 코딩할 때 성능 향상을 실현시켰다.

이 사실로 인해, 비록 Nvidia가 DX10.1을 지원하지 않아도 DX10도 그렇게 차이나는 지원이 아니라서, Nvidia는 개발자들에게 DX 10.1의 기능들을 그들의 드라이버를 통해 지원할 수 있도록 주문하였다. 그리하여 그들은 멀티샘플 리드백을 지원하며 여타 DX10.1 기능도 이런 방법으로 공개시키도록 하였다. 물론, DX10의 주요점은 개발자들에 대해 다양한 가능성의 필요성을 충족시키기 위해서였지만, 이것이 하드웨어 벤더들에게 다른 방법으로 이런 특징들을 공개하지 못한다는 것을 의미하지는 않았다. DX10.1 지원은 사생결단은 아니라도, DX10을 넘어선 기능의 사용이 DX10.1에서의 부분에서는 가능하였으며, Nvidia는 이것을 멀티샘플 리드백을 통해 수행하였으며 다른 것도 가능하였다.

우리는 AMD가 R4xx 하드웨어에서 SM3.0을 채택하기를 원했듯이, Nvidia와 AMD 모두 같은 특징 셋을 도입하는 것을 좋아했는데, 우리는 DX10.1이 요구하는 기능들을 지원하는 것을 배타하기로 한 결정을 이해한다. Nvidia는 DX10.1을 하드웨어에 도입하는 것으로 인한 투자 수익이 보증하는 것만큼 충분하지 않아서 내린 결정이었다. 괜찮은 결정이다.

그러나 PR, 마케팅과 개발자 관련에서는 웃기지도 않는 이런 간단한 공정 결단을 조롱하였다.

우리는 G80과 R600 모두 DX10.1 기능 셋의 일부분을 지원 하였다는 것을 안다. 우리의 목표는 최소한 어떠한 기능이라도 GT200에 들어갔는가를 측정하는 것이었다. 우리는 이상적으로 GT200에서 어떤 DX10.1 기능 사양을 지원하고 하지 않는지를 알고 싶지만, 알 수 있는 데에는 한계가 있다. 우리의 질문을 요청한 뒤로, Nvidia 기술영업부서에서 응답을 얻을 수 있었다. :

“우리는 멀티샘플 리드백을 지원하는데, 이것은 DX10.1 기능에서만 있는 것으로 (몇몇) 개발자들이 이것에 흥미를 가지고 있다. 우리가 무엇을 못하는가를 말해준다면, ATi는 우리가 못하는 것을 하기 위해 개발자들을 쓸 것인데, 이것은 PC게이밍과 매니악 게이머들을 해하는 일 밖에 안된다.”

이 정책 결정으로 우리들을 대하여 매번 이런 종류의 응답은 우리들에게 괘씸한 마음이 들게 한다. 어떠한 경우에서도 뻔뻔한 거짓은 제외 하더라도, 왜 이런 종류의 입장 표명만으로 우리에게 응답을 하는지 궁금증을 자아내게 한다. 자 이제 왜 Nvidia의 공식 위치가 이렇게 빡빡한 자세이며 이 언급이 어떤 뜻을 의미하는지를 알아보자.

멀티샘플 리드백 이 몇몇 개발자들만이 관심을 갖고 있다는 언급은 거짓이다. : 큐브 맵 배열은 다수의 어플리케이션을 단순화하고 가속화 하는데 아주 유용하다. 필요한가? 아니, 그러나 유용한가? 그래. 분리된 per-MRT 블렌드 모드는 지연된 쉐이딩이 계속적으로 발전하는데에 유용하며, 아주 이 기능을 지원해주는 데에 적절한 곳은 개발자와 연구자들이 실험을 하는 곳이다. 많은 개발자들이 int16 블렌드를 쓰지 않는데, 몇몇 DX 10.1 기능들은 흥미로우며, 게다가, AMD와 Nvidia아 모두 이것들을 지원한다면 아주 유용할 것이다.

그 다음, 개발자들이 ATi와 공모하여 능동적으로 PC게이밍과 매니악들을 해한다는 거짓이다. (그리고 쓰레기 같은 망상이다.) 개발자들은 가능한 한 작은 문제로 그들이 얻고 싶어하는 결과를 얻기 위해 가장 빠른 효율적인 것에 흥미 있을 뿐이다. 기술이 괜찮다면, 그들은 그것을 취하거나 버리게 된다. 개발자의 목표는 가능한 한 많은 게이머들을 위해 가능한 한 즐길 수 있는 게임을 만드는 것이며, AMD와 Nvidia 하드웨어 모두에게서 생동감 있는 같은 경험을 느끼게 하는 것이다. 게임은 2개의 주요 GPU 벤더들 중 하나에게로만 정확히 동작하는 게임을 출시할 리 없는데, 이것은 게임에도 좋지 않고 개발자에게도 좋은 게 없기 때문이다.

Nvidia가 DX10.1 기능의 지원에 대한 엔지니어링 결정을 내면서, 모든 게임 개발자들은 특별한 기능이나 특정 기술을 사용함에 있어 도입의 투자 수익률을 고려하게 되었다. DX10.1을 지원하지 않는 Nvidia로, DX10.1 관련 기술을 시도 한다면 개발자에게는 그렇게 매력적으로 보이지 않는데, 왜냐면 그들은 어떻게든 DX10 코드 패스를 써야 하기 때문이다. DX10.1 코드 패스가 도입에 하찮지 않는 한, DX10과 같은 결과를 생산하며, DX10.1을 지원하는 하드웨어 상에서 몇몇 이점을 제공하기에 게임 내에 이것을 계속 적용하지 않을 이유는 없다. 얼마나 많은 게임에 특정 하드웨어 벤더 로고를 넣느냐에 기반하여 특정 공급사가 마케팅 계약으로 금전적인 문제로 개발사와 기술 지원부와 연결되지 않는 한은 말이다.

AMD 또한 세상물정을 모르고 Nvidia는 그들의 하드웨어의 능력을 숨기려 한다. 엑스레이, 전자 현미경과 리버스 엔지니어링을 위한 다른 도구들을 이용한 경쟁들은 첫 번째로 모든 입출력을 찾아내어 시장을 강타한 이 실리콘이 어떻게 작동하는지를 찾아낸다. Nvidia는 AMD가 GT200을 파헤칠 것을 알고 있는데, 왜냐하면 Nvidia 또한 RV670을 분석하지 않는 바보 같은 짓을 하지 않을 것이기 때문이다.

그러면 누가 진정 이런 Nvidia의 오점 투성이의 정책에 소리없이 고통받고 있는가? 첫번째로는 하드웨어를 배우는 데에 있어 아주 흥미로운 매니악이 있겠다. 그 다음으로는 개발자들인데 왜냐면 그들은 Nvidia가 제공하는 기능이 어떤 것인지 모르기 때문이다. 물론, AMD도 그들의 하드웨어의 성능을 좀 더 뽑아낼 수 있게 만드는 기능의 지원을 개발자들에게 제공할 수 없는데, 왜냐하면 Nvidia 하드웨어가 이것을 지원하지 않기 때문이다. (지원해도 마찬가지겠지만.) 마지막으로 게이머들 중 개발자가 쉽게 접근을 하게 만들기 위해 추가한 툴들을 모르는 사람들이 있겠다.

그러면 왜 Nvidia가 이런 떳떳한 길을 가지 않는가? 가능성은 무한대지만, 몇몇 제안을 쓸 수 있는 것을 기쁘게 생각한다. AMD가 그들의 하드웨어에서 게임이 잘 돌아가기 위한 코드를 얻는 것을 단순히 방해 하는 것일 수 있다.(Assassin’s Creed에서 볼 수 있다.) Nvidia가 성능 상에서 엄청난 표준을 제공하는 것일 수도 있다. : 뭔가 할 수 있다는 것이 뭔가를 잘한다는 것은 아니며 지원을 인정하는 것이 부정하는 것보다 더 나빠보일 수 있기 때문에. 기본적인 아키텍쳐가 특정 기본 기능을 수행함에 있어 부적절하며 이것을 DX 10.1 지원을 요구하는 기반에서 재구성을 해야 할 수도 있다.

Nvidia는 이것이 진정한 기능 셋이라고 밝힌다면, AMD는 DX10.1 코드를 지원할 수 있게 돈을 뿌려 개발자들을 매점매석 하여 Nvidia를 고사시킬 것이라 주장한다. 아 잠시, 미안하다, Nvidia는 초단위의 빚을 갖고 있으며 CPU와 GPU측 모두에게 각각 경쟁자가 달라붙어 있는 상황인 AMD보다 2배의 가치가 있다. 그러므로 우리는 물어볼 수밖에 없다. : 개발자들을 돈으로 매수한다면 누가 이 업계에서 손해를 본다고 생각하는가?

출처 : http://www.anandtech.com/video/showdoc.aspx?i=3334
http://www.anandtech.com/video/showdoc.aspx?i=3336