Intel의 Larrabee 아키텍쳐 발표 : 계산된 첫 걸음

1페이지

소개

오오오 이것은 위험하다.

Intel은 (너무 조용하지는 않지만) 조용하게 Larrabee라고 불리우는 것으로 그래픽 시장 진입이라는 그들의 목표를 많은 업계에 알리기 시작하였다.

NVIDIA는 (너무 조용하지는 않지만) 조용하게 Larrabee의 존재가 없음을 비판함으로써 응답하였다.

우리가 지난 몇달간을 봐 온 것에 의하면 서로 주먹을 날렸었는데, NVIDIA는 명백하게 공식적으로 좀 더 휘청거려왔다. 오늘은 대단한 날인데, 아키텍쳐 경쟁에 대한 논쟁을 접어두고, Intel은 처음으로 공식적으로 그들의 Larrabee GPU 아키텍쳐의 기반에 대해 베일을 벗기게 된 날이다.

pic1.jpg

음, 중요하게 고려할 것은 이것은 처음이자 최초로 GPU가 아닌 것이라는 것이다. 이것은 CPU이다. 다수코어의 CPU로 데이터 병렬 처리에 최적화된 것이다. 뭐가 다른 것인가? 음, 여기에는 아주 적은 고정 함수 하드웨어와, 가능한한 쉬운 범용 코드를 돌리는 데에 집중하고 있는 하드웨어가 있다. 밑줄 쳐야 할 것은 Intel은 DirectX와 OpenGL을 조작하기 위한 소프트웨어 라이브러리를 도입한 GPU 같이 보이는 고대역의 다수 코어 CPU를 만들 수 있다는 것이다.

이것은 GPU로 에뮬레이팅 한 것이 아닌데 이것은 보통 분리된 하드웨어로 작업을 완료힐 수 있는 병렬 데이터용 CPU 상에 직접적으로 함수 기능을 도입하였기 때문이다. 그리고 개발자들은 단지 DirectX 와 OpenGL에만 구애되지 않을 것이다. : 이 하드웨어는 순수한 소프트웨어 렌더러를 취할 수 있으며 만약 하드웨어가 이 코드에 특성화 설계가 되어 있을 때 이것들을 동작시키게 된다.

여기에 뭔가 있으니, 이제 속으로 들어가보기로 하자.

2페이지

설계 실험 : Intel이 GPU를 설계할 수 있나?

Larrabee는 일반적으로 현존하는 Intel x86 코어 기술로 만들어졌는데, 이것은 이 칩 설계가 Intel에 대해 이질적이지 않다는 것만을 뜻하는 것이 아니라, 또한 미래의 데스크탑 마이크로 프로세서에 대한 무게 있는 함축적이라는 의미도 있다. 그러나 Larrabee는 Intel이 요즘 한창 써먹고 있는 Core 아키텍쳐에 기초하여 만든 것이 아니라, 대신 Intel은 Larrabee의 기반에 있어 더욱 오래된 아키텍쳐로 전환되었다. : 오리지널 Pentium이 그것이다.

오리지널 Pentium은 0.8 마이크론 공정에서 제조 되었으며, 후에는 0.6 마이크론 공정으로 세밀해졌다. Intel을 괴롭힌 의문이란 이것이었다. : Pentium 코어의 갱신된 버젼이 현대의 공정에서 만들어져 아주 넓은 벡터 유닛과 장착되어, 고급 GPU에 대한 튼튼한 기반을 만들 수 있을까?

이론에 대한 첫 테스트를 위해 Intel은 4MB의 L2 캐시와 공개되지 않은 클럭 속도의 표준 C2D를 선택 하였다. 그리고, Intel은 같은 제조 공정, 거의 같은 다이 면적과 전력 소모면 상으로, 얼마나 변형된 이들 Pentium 코어가 들어갈 수 있는가를 찾았다. 숫자는 10이었다.

그리하여 듀얼코어 C2D의 영역 내로, Intel은 이 가상의 10 코어 칩을 건조해낼 수 있었다. 이제 성능치를 보도록 하자.

  Intel Core 2 Duo 가상의 Larrabee
CPU 코어 갯수 2 개/ 비순차적 10 개/ 순차적
이슈 당 명령 클럭 당 4개 클럭 당 2개
Core당 VPU 레인 4-wide SSE 16-wide
L2 캐시 크기 4MB 4MB
Single-Stream 처리량 클럭 당 4 클럭 당 2
Vector 처리량 클럭 당 8 클럭 당160

보아야 할 것은 우리가 여기서 비교할 것들은 작업 처리량이지, 어느 것을 실제적으로 실행함에 있어 얼마나 빠르게 하느냐를 보는 것이 아니며, 단지 클럭 당 얼마나 많은 작업을 처리할 수 있느냐는 것이다.

(예를 들어 싱글 스레드 어플리케이션 같은) 싱글 스레드 흐름을 구동 시킴에 있어, Core 2는 클럭 당 최대 4개의 명령을 수행할 수 있는데, 왜냐면 이것은 클럭 당 4개의 명령어를 발행할 수 있으며 이것은 실행 유닛에 구속되어 있는 것이 아니기 때문이다. 10 코어 설계는 그러나 클럭 당 2개의 명령만을 발행할 수 있으며 그러므로 단명령 흐름에서의 최대 명령어 실행 비율은 클럭 당 2개 명령이어서, Core 2의 처리량의 반에 해당한다. 어쨌건 당신은 이 코어에서 실제적으로 벡터 연산을 작동 시키고 싶어하고 당신의 Core 2 CPU에서의 싱글 스레드 작업을 어찌됐든 없애 버리고 싶어할 것이기 때문에 이것은 나쁘지 않으며, 여기에서 제한된 아키텍쳐는 그것의 날개를 펼치게 된다.

2개 코어로, 각기 그들의 능력은 클럭 당 4개의 공동 작용하는 SSE 작업을 실행할 수 있는 능력이 있어, 당신은 Core 2 상에서 클럭 당 8개 작업에 대한 처리량을 얻게 된다. 10코어 설계 상에서는? 클럭 당 160개의 작업이며, 이것은 같은 다이 영역과 전력 량에서 거의 20배 정도가 증가하게 된다.

이론적으로 이것은 실제적으로 가능하다. 만약 당신이 이들 코어를 충분히 갖고 있다면, 필요한 벡터 작업량을 얻기 위해 적합한 GPU를 실제적으로 제작할 수 있을 것이다. 물론 여기에는 GPU 내에 사용을 위한 x86 명령어 셋을 접목 시키는 것, 모든 코어들이 각기 다른 것들과 통신을 하게 하는 것과 실제적으로 모든 이들 실행 자원들을 작업 상태로 만드는 것 같은 문제가 있다. - 그러나 이 설계 실험은 이것들이 가능하다는 것을 보여주었다.

그리하여 Larrabee가 태어났다.

3페이지

Pentium 같지도 않고, Atom 같지도 않은 : Larrabee 코어

Intel은 우리에게 사양에 대해 논의를 시작할 정도의 충분한 Larrabee에 대한 정보를 주었으나, 어떠한 결론을 내리기 시작할 정도의 양으로 충분치는 않다. 우리는 이제 우리가 충분히 알고 있는 것으로 시작할 것이다.

Intel의 Larrabee는 몇몇개의 x86 코어들로 만들어져있는데, 아주 개략적으로 본다면, 이런 식으로 나온다. :

pic2.JPG

각기 코어는 dual-issue, in-order 아키텍쳐로 대충 Pentium 마이크로 프로세서에서 파생된 것이다. 이 Pentium 코어는 64비트 작업 지원, x86 명령어 셋 갱신, 커진 캐시들, 4방향 SMT/Hyper Threading과 16-wide 벡터 ALU 들이 변형되었다.

Atom에 대해 작업을 끝낸 팀이 Larrabee 코어 상에서 원래 작업을 했을텐데, 여기에는 Larrabee와 Atom 간의 몇몇 눈에 띌 만한 차이가 있다. Atom은 깊은 파이프라인, 커진 L2 캐시와 범용 데스크탑 성능을 향상시키기 위한 추가적인 마이크로 아키텍쳐적인 트윅으로 더 높은 1개 스레드 성능에 중점을 둔 기기이다.

  Intel Larrabee
Core
Intel Pentium Core (P54C) Intel Atom Core
제조 공정 45nm 0.60µm 45nm
동시 멀티 스레딩 4-방향 1-방향 2-방향
이슈 폭 듀얼 이슈 듀얼 이슈 듀얼 이슈
파이프라인 깊이 5-스테이지 (?) 5-스테이지 16-스테이지
스칼라 실행 자원 2 x 정수 ALUs (?)
1 x FPU (?)
2 x 정수 ALUs
1 x FPU
2 x 정수 ALUs
1 x FPU
벡터 실행 자원 16-wide Vector ALU 없음 1 x SIMD SSE
L1 Cache (명령/데이터) 32KB/32KB 8KB/8KB 32KB/24KB
L2 Cache 256KB 없음 (외부 추가) 512KB
명령어 셋 아키텍쳐(ISA) 64-bit x86
SSEn support?
Parallel/Graphics?
32-bit x86 64-bit x86
완벽히 Merom ISA
 호환

반면 Larrabee는 시작부터 훨씬 Pentium에 가까운 것이다. ; Intel이 언급하기를 Larrabee의 실행 파이프라인은 "짧으며" 이어서 이것은 Atom의 16 스테이지 파이프라인 보다 오리지널 Pentium의 5 스테이지 파이프라인에 더 가깝다고 말 하였다. Atom과 Larrabee 모두 SMT를 지원할 때, Larrabee는 동시에 4개 스레드까지 작업하는 데 비교되어 Atom은 2개만 가능하며 Pentium은 1개만 가능하다.

L1 캐시 크기는 Larrabee와 Atom 간에 비슷함이 있지만, Larrabee는 24KB를 갖고 있는 Atom에 반해 전체 32KB 의 데이터 캐시를 갖게 되었다. 만약 Atom 아키텍쳐에 관한 글 (http://gigglehd.com/zbxe/special/91461, http://gigglehd.com/zbxe/special/91473) 을 기억한다면, 더 작은 L1 데이터 캐시는 캐시에 갈 작은 신호 배열이 대신 레지스터 파일로 가게 되는 부작용을 일으킨다고 되어 있다. 다이 크기는 늘어났지만 작동 전압은 줄어들었고, 강제적으로 Atom으로 하여금 작은 L1 데이터 캐시를 갖게 했지만 이것으로 하여금 저전력 목표에 도달이 가능하게 되었다. Larrabee는 아주 적은 제약 뿐이며 그리하여 우리는 전통적인 균형있는 L1캐시를 갖게 되었는데, 오리지널 Pentium에 비해 4배의 크기이다.

Pentium은 다이 상 L2 캐시를 갖고 있지 않은데, 이것은 메인보드 상에 설치된 외부 SRAM에 의존한다. 좋은 데스크탑 성능을 관리하기 위해 Atom은 512KB의 L2 캐시를 장착하게 되었는데, 각기 Larrabee 코어는 256KB의 L2 캐시를 각각 갖게 될 것이다. 당신이 곧 볼 Larrabee의 아키텍쳐는 크기와 속도의 중요함으로 압박을 받는데, 그러나 256KB는 현재 Intel의 설계에서는 알맞은 크기이다. Larrabee의 기본 OpenGL/DirectX 렌더러는 타일 기반이며 이것의 대부분은 32-bit color/32-bit Z의 64*64나 128*128 타일로 밝혀졌는데 이것은 128KB 공간에 딱 맞으며, 나머지 128KB는 추가적인 데이터를 캐싱하는 데에 쓰이게 된다. 그리고 기억할 것은, 이것은 단지 1개 Larrabee 코어이다. - 전체 GPU는 더 많은 코어로 만들어질 것이다.

Larrabee, Pentium, 그리고 Atom 간의 큰 차이점은 벡터 실행 측에 있다. 오리지널 Pentium은 SIMD유닛이 없었고, Atom은 SSE 지원을 추가 하였으며 Larrabee는 거대한 16-wide 벡터 ALU를 추가 함으로써 큰 도약을 취하게 된다. 이 유닛은 16개의 32비트 부동소수 연산을 동시에 할 수 있어, 이전 언급한 어떠한 코어보다 훨씬 넓은 폭으로 만들어졌다. 주어진 어플리케이션의 습성 상 넓은 벡터 유닛 같은 것은 Larrabee가 목표로 할 충분한 이유가 된다.

64비트 x86 지원과, 비록 Atom의 프리페쳐에 어떻게 이것을 비교할지 알려지지는 않았지만 하드웨어 프리페쳐 같은 Pentium 코어에서의 변경사항이 Larrabee로 들어가게 되었다. 프리페칭이 병렬 데이터 상황에서의 최적화를 포함한다는 것은 적절한 추측이 되겠지만, 이것이 다른 프리페치 기술의 추가사항인지 교체 사항인지는 우리가 찾아내야 한다.

4페이지

좀 더 깊게 들어가면서 AMD/NVIDIA와 비교해보자

초기 다이어그램에 속지 말아야 하는데, 이 간단한 x86 코어는 훨씬 복잡하다. 아래 이미지에서, 왼쪽의 블럭은 이전에 우리가 언급한 Larrabee 코어이며, 오른쪽은 우리가 벡터 유닛과 관련 부문을 확대시킨 것이다.

pic3.jpg

벡터 유닛은 핵심이며 이 유닛 내에 엄청난 양의 레지스터를 갖게 될 것이며 아주 넓은 벡터 ALU는, 이것이 우리를 Larrabee의 기본적인 블럭으로 인도할 것이다. NVIDIA의 GT200은 Streaming Processor들 로 이루어져 있고, AMD의 RV770은 Stream Processing Unit들로 이루어져 있으며 Larrabee의 성능은 이들 16-wide 벡터 ALU에서부터 나온다.

pic4.JPG

비록 ATI와 NVIDIA에 비교하여 (Intel이 현 시점에서 발표하지 않아) 동등한 대역폭으로 변환할 필요가 없더라도 이 벡터 ALU는 16-wide 단정밀도 ALU나 8-wide 배정밀도로 행동할 수 있는데, 여기에 기본 실행 유닛 레벨에서의 Larrabee가 어떻게 보이는지가 나와있다.

pic5.jpg

NVIDIA의 SP들은 1개 작업을 하며, AMD는 5개 작업이 가능하며, Larrabee의 벡터 유닛은 16개의 작업이 가능하다. NVIDIA는 수백개의 이들 SP를 그들의 고사양 GPU들에 집적하였으며, AMD는 160개이며 Intel은 아마 Larrabee 내에 16~32 개의 코어들을 넣을 것으로 예상된다. 만약 NVIDIA가 끝까지 이 SP들을 우겨넣게 된다면, Intel은 정확히 이와는 정 반대로 가게 될 것이다.

우리는 이미 AMD의 아키텍쳐가 정확히 스케쥴 하고 그들의 실행 리소스를 5-wide SP들에 최대 사용을 하기 위해 컴파일러에서의 많은 도움이 요구된다는 것을 보여주었었는데, Larrabee에서는 컴파일러의 중요성이란 상상을 초월한다. Larrabee에게는 운이 좋게도, 몇몇 최상의 컴파일러들이 Intel에 의해 만들어졌다. 이런 종류의 아키텍쳐를 해낼 것이라곤 Intel 밖에 없다.

동시에, 우리가 이것의 세부사항을 아직 완전히 이해하지 못하고 있는 반면, 우리는 Larrabee의 벡터 유닛이 카멜레온 같은 것이라는 생각이 들었다. 우리가 갖고 있는 정보로부터, 이들 벡터 유닛은 실행되고 있는 프로그램의 한개 스레드에서 엄청난 16-wide 작업을 실행할 수 있으며 모든 16개 실행 유닛에서의 레지스터 혼합을 조정할 수 있다. 이것은 AMD같은 넓은 무언가를 암시하는 듯 하다. 그러나 또한 이것은 각기 16개의 벡터 연산 유닛 같이 보이기도 하는데, 이것을 이용하여 마스크 레지스터는 분기를 독립적으로 할 수 있다. (이것은 NVIDIA의 솔류션과 아주 유사해 보인다.)

우리는 이미 어떻게 AMD와 NVIDIA의 설계상의 차이점에서 유래한 각기 다르게 나타나는 장점과 단점을 각기 다른 게임에서 보아왔다. 만약 Intel이 특정 상황에 맞게 사용되는 벡터 유닛을 적용하는 방안을 강구할 수 있다면, 그들은 뭔가 엄청난 것을 그들 손에 넣는 것이 된다. 다시 말하건데, 우리는 뭐가 어떻게 되는지에 대한 충분히 자세한 사항을 갖고 있지 않지만, 상황이 아주 재미있게 돌아간다.

5페이지

모두 함께 묶어버려라. - Ring Bus의 귀환

Intel은 Larrabee의 2가지 중요한 세부사항을 아주 조용히 유지하고 있다. : 명령어 셋의 세부사항과 최종 제품의 설정이 그것이다. Larrabee가 2009년이나 2010년까지도 선적을 하지 않을 것이라는 것을 기억한다면, 첫 칩은 아직도 Fab에서 돌아오지도 않았으며, 그러므로 얼마나 많은 코어를 Intel이 한개 Larrabee GPU에 넣을 것인지를 논쟁하는 것 자체를 Intel이 원하지 않을 것이라는 것은 맞는 말이 된다.

최종 제품은 8 Larrabee 코어의 배수로 조립될 것인데, 우리는 원래 24~32 코어 영역 정도를 예상했지만 이것은 목표 다이 크기에 크게 의 존하는 것으로 우리가 곧 설명할 것이다. :

pic6.JPG

Intel의 블럭 다이어그램은 2개의 메모리 컨트롤러 영역을 가리키고 있지만, 이것은 여전히 우리가 여기에서 읽어 낼 수 있는지 아닌지는 불명확하다. AMD와 NVIDIA는 모두 64비트 메모리 컨트롤러를 사용하며 단순히 한개 칩 상의 그룹들을 곱하는 형태를 취한다. Intel의 Larrabee에서 주어진 것으로는 AMD와 NVIDIA가 만들어낸 것보다 더 많은 메모리 대역폭 효율이 이루어질 것인데, 이것은 비록 우리가 아주 보수적인 행동이라고 믿지만 Larrabee가 128비트 메모리 인터페이스를 가질 수 있으므로 아주 가능성이 있는 것이다. (우리는 256비트 인터페이스를 예상한다.) (싸면서도, Larrabee가 나올 시기에 아주 가용성이 높은) GDDR5로 배가 될 수 있지만서도, 어떤것이든 가능하다.

모든 코어들은 (각 방향 당 512비트인) 이방향성 링버스로 연결되는데, 아마 코어 속도로 동작할 것이다. Larrabee가 2Ghz 이상으로 동작할 것이라는 예상을 기반으로, 이것은 또한 아주 높은 대역 버스 중 하나가 될 것이다. 이것은 AMD의 R600/RV670 링버스의 대역폭의 반이지만, 높은 속도는 이 상황을 뒤집어 버리고도 남을 것이다.

AMD는 최근 그들의 링버스 아키텍쳐를 포기 하였는데 다이 면적의 절약과 강한 솔류션의 필요성에서의 역량 부족을 이유로 꼽았다. 링버스는, 메모리 버스가 가는 것이라, 아주 정확하며 다른 선택 사항보다 덜 복잡하다. 단점이란 많은 도선이 필요하며 클라이언트들이 원하든 원하지 않던 높은 대역폭으로 모두에게 전달한다는 것이다. 물론, 모든 메모리 클라이언트들이 필요로 하거나 고대역을 쉽게 사용할 수 있다면 그때는 링버스의 승리가 된다.

Intel은 링버스를 사용함에 있어 AMD보다 더 나은 사용을 할 것이다. : 캐시 일관성이나 내부 코어 통신부문에서. 일관성 유지와 통신 수월화를 위한 L2 분리화와 링버스 사용은 이 엄청난 양의 데이터 이동력에 있어 적절한 사용을 하게 만들 것이다. Cell 또한 내부 통신을 하는데, Intel의 낮은 지연시간, 일관된 L1과 L2 영역의 직접 접속을 제공하는 솔류션일 때 L2 캐시의 뒤에서의 엄청난 대역을 사용함으로 인해, 데이터 공유가 요구될 때 프로그램 아키텍쳐는 훨씬 빠르고 쉽게 되는 결과를 낳게 된다.

6페이지

Larrabee에는 얼마나 많은 코어가 들어갈 것인가?

초기 추정치는 Larrabee 내에 16~32개 코어 정도가 들어갈 것이라 하였는데, 우리는 32코어가 적정할 것으로 보았지만 (이 이상 올라가면 Intel의 차트와 그래프가 보여주듯 32코어가 넘어가면 증가치가 감소하게 된다.) 24코어가 초기 제품에 더욱 더 알맞을 것이다. Intel은 그러나 몇몇 데이터를 공유함으로 우리들이 이 모든것에 대해 의문을 품게 만들었다.

pic7.jpg

설계 실험을 기억하는가? Intel은 C2D 다이의 영역에 10개의 Larrabee를 넣을 수 있을 것이라 하였다. Intel이 사용한 C2D의 주어진 사양으로, 이것은 65nm Conroe/Merom 기반의 C2D - 143 제곱밀리미터 다이 사이즈 일 것이다.

143 제곱밀리미터에서, Intel은 10개의 Larrabe 같은 코어를 넣을 수 있으니 이제 우리는 이것을 2배로 늘려보자. 이제 우리는 286 제곱밀리미터에 20코어가 된다. (여전히 GT 200보다 작으며 AMD의 RV770 정도의 크기가 된다.) 한번 더 2배를 시키면 우리는 40코어를 572 제곱밀리미터 다이에 올리는 것이 되는데, 가상적으로 NVIDIA의 GT200과 같은 크기이지만 65nm 공정이다.

45nm 공정으로 옮겨가면 비율은 거의 50% 정도로 되지만, 우리는 단순히 45nm로 간다면 (이것이 Larrabe가 만들어질 회로 선폭이다.) 다이 사이즈가 60~70%에 근접하게 준 것을 보게 될 것이다. 우리의 40코어 Larrabee는 이제 45nm에서 최대 370 제곱밀리미터가 된다. 만약 Intel이 NVIDIA같은 다이 크기로 밀어부치고 싶어한다면 우리는 고성능 급에서 발매 시에 64코어의 Larrabee를 쉽게 볼 수 있을 것이며, 24나 32코어 버젼은 메인스트림에 초점을 맞추게 될 것이다.

업데이트 : 여기에서 우리가 고려하지 않은 것은 전력 제한이다. 그러므로 Intel이 GT200 정도의 다이 사이즈에 64코어 Larrabee를 개발할 수 있다면, 이런 칩은 물리 전력 제한을 초과해버릴 것이다. 우리는 다이 크기 제한보다 전력 제한으로 인해 45nm 에서 16~32 코어 영역 정도의 제품을 볼 확률이 훨씬 높아지게 된다.

이것은 모두 순전히 추측이지만 이것은 공식성을 가지는 해볼만한 논쟁이다.

7페이지.

캐시와 메모리 서열 : 저지연 작동을 위한 설계

Intel은 초고성능 캐시를 제조함에 있어 아주 많은 경험을 갖고 있다. Intel의 캐시는 AMD가 x86 마이크로 프로세서 전면에 생산해낼 수 있는 것보다 훨씬 밀도가 높으며, 우리가 Nehalem 프리뷰에서 보았듯이, Intel은 또한 경쟁사보다 확실히 낮은 지연시간으로 데이터 전달을 하는 캐시를 만들 수 있다. 그러므로 Larrabee의 강점이 완전히 프로그램 가능한 x86 코어와, 아주 크고, 아주 빠른 밀착 캐시에서 온다는 것으로 놀랄 사람은 아무도 없을 것이다.

각각의 Larrabee 코어는 오리지널 Pentium의 L1 캐시의 4배에 해당하는 캐시를 장착하고 있다. Pentium은 8KB의 L1 데이터 캐시와 8KB의 L1 명령어 캐시를 갖고 있어, 각각의 Larrabee 코어는 32KB/32KB의 L1 D/I 캐시를 갖고 있다. 이유는 각각의 Larrabee 코어는 오리지널 Pentium의 4배에 해당하는 작업이 가능하며 그러므로 4배 큰 L1은 아키텍쳐의 균형을 유지하게 된다. 오리지널 Pentium은 내장 L2 캐시를 갖고 있지 않았지만, 각각의 Larrabee 코어는 그들 고유의 L2 캐시 영역에 접근하게 된다. - 256KB 크기에.

Larrabee의 L2 풀은 각기 코어에서 늘어났다. 8 코어 Larrabee는 총 L2 캐시 용량이 2MB (코어 당 256KB * 8코어) 가 되며, 32 코어 Larrabee는 8MB의 L2 캐시를 가지게 된다. 각기 코어는 그들의 L2 코어 영역에만 접근할 수 있으며, 그들 풀의 256KB 부분에 읽고 쓰기가 가능 하며 이게 끝이다. 다른 Larrabee 코어와의 통신은 링버스를 통해 일어난다. ; 1개 코어는 그것의 L2 캐시에서 데이터를 찾으며, 이곳에서 찾을 수 없다면 이것은 링버스 상에 요청을 하여 결국엔 그것의 L2 에서 데이터를 찾아내게 될 것이다.

Intel은 NVIDIA가 하는 것처럼 지연시간을 숨기려 시도하지 않으며, 대신 그것의 고속으로 인해, 캐시의 저지연시간이 확보된다. 캐시 크기에 대한 연산 자원의 비율은 AMD나 NVIDIA의 아키텍쳐보다 Larrabee가 훨씬 낮다.

  AMD RV770 NVIDIA GT200 Intel Larrabee
L1 캐시 당 스칼라 작업수 80 24 16
L1 캐시 크기 16KB 알려지지 않음 32KB
L2 캐시 당 스칼라 작업수 100 30 16
L2 캐시 크기 알려지지 않음 알려지지 않음 256KB

AMD와 NVIDIA 모두 캐시 크기를 발표함에 있어 꺼렸다 해도, 우리는 RV670이 전체 칩 캐시로 256KB의 L2 캐시를 갖고 있었다는 것을 알고 있으며 RV770은 좀 더 커졌을 것이라는 것으로 예상하지만, Larrabee에 Intel이 집적한 용량에 가깝게 클 정도로 집적하진 않았다. NVIDIA는 AMD보다 연산 대 캐시 비율이 좀 더 근접한데, 훨씬 더 큰 GPU를 설계한다는 것을 전제로 이것은 더욱 신빙성을 얻게 되지만, NVIDIA가 GT200 다이에 Intel의 Larrabee 보다 더 큰 캐시를 갖게 했다고 믿을 어떠한 이유도 없다.

캐시들은 완전히 밀접한데, 멀티코어 데스크탑 CPU 같은 것이다. 완전히 밀접해진 캐시들은 멀티 GPU 설정 시에 몇몇 흥미로운 경우를 만들기도 한다. Intel이 멀티 GPU Larrabee 계획에 있어 선을 긋지 않은 반면, 멀티 GPU Larrabee 설정에 대한 언급으로 Intel은 "AMD/NVIDIA가 겪고 있는 고통 만큼 큰 고통을 예상" 하지는 않고 있다고 하였다.

우리는 다수의 칩에서 캐시 일관성을 관리 하는데에 어떠한 제한이 있는지를 물었으며 답변은 두 칩 사이에 충분한 대역이 있다면 괜찮다는 것이라는 것이었다. NVIDIA와 AMD가 여전히 멀티 GPU 렌더링을 정련하기 위해 비트와 몇몇가지를 추가하는데, Intel은 원한다면 바로 자금을 부어 강력한 솔류션을 만들 수 있다. (한개 프레임에 대해 공유된 프레임 버퍼와 훨씬 더 효율적인 작업 부하 분할을 생각해보라.)

8페이지

Larrabee에서의 프로그래밍

Larrabee의 프로그래밍 모델은 경쟁사들의 셋에 비해 많이 다르다. 경쟁사의 GPU 아키텍쳐는 해가 넘어갈수록 훨씬 프로그램이 가능해지는 반면, Larrabee는 완전히 프로그램이 가능한 위치에서 시작한다. 개발자들에게는, 이것은 정확히 - 완벽히 캐시가 일관적인 x86 마이크로 프로세서의 배열로 표현되는 식으로 보인다. Larrabee의 이런 첫 반향은 그들의 그래픽 드라이버를 통해 OS에서부터 이 사실이 숨겨질 것이나, 칩의 미래의 버젼은 어쩌면 그냥 오늘날 데스크탑용 x86 코어가 하는 것 같이 작업 상황 매니져 같은 일을 할 수도 있다.

Larrabee의 위력을 사용하는 데에는 두가지 선택사항이 존재한다. : 표준 DirectX/OpenGL 코드를 쓰거나, (MS, Intel, GCC, 등등에서의 컴파일러를 사용할 수 있는) 표준 C로 밝혀진, Larrabee C/C++을 사용하여 하드웨어로 직접적으로 쓰거나. 어떤 의미로는, NVIDIA가 제공하는 그들의 GPU와 다른점이 없다고도 할 수 있다. - 그들은 DirectX/OpenGL 코드를 돌릴 수도 있고, 또한 CUDA에서의 C-코드를 돌릴 수도 있다. 차이점이라면 Larrabee에 직접적으로 쓰는 것으로 하여금 당신에게 이 완벽히 동작하는 x86 GPU의 배열인 GPU로 인해 추가적인 프로그래밍의 유연성을 부여 한다는 것이다. x86 아키텍쳐를 위한 프로그램은 소프트웨어 커뮤니티에서는 유행이었는데 이미 써왔었고, 상대적으로 추가적인 학습이 필요 없고, 고려 해야할 새로운 하드웨어 제한이 없으며 새로운 특징을 사용하기 위해 CUDA의 추가적인 되풀이로의 기다림이 없기 때문이다. 당신은 Larrabee를 당신의 호스트 CPU같이 취급할 것이다.

게임 개발자들은 새로운 속임수를 배우는 데에 그렇게 비중을 두지 않으나, Larrabee 같은 입증되지 않고 배포되지 않은 하드웨어 플랫폼에서는 특히 다르다. Larrabee는 다루기 쉽게 꼭 DirectX/OpenGL 코드로 동작해야 하며, 그럼으로 인해 Intel은 DX/OGL과 Larrabee 하드웨어 간의 인터페이스를 위해 그들 고유의 Larrabee 전용 소프트웨어 렌더러를 쓰게 되었다.

AMD/NVIDIA GPU에서는, DirectX/OpenGL 명령어 맵을 실행 시에 내부 GPU 명령어에 매핑하였다. Larrabee에서는 Intel은 이런 매핑을 소프트웨어에 함으로써, DX/OGL 명령어를 그들의 소프트웨어 렌더러에 매핑하며, 그 후 그들의 소프트웨어 렌더러를 Larrabee 하드웨어 상에서 동작시키게 된다.

중간 스테이지는 성능상의 약점으로 위험을 초래할 것인데, Larrabee에 직접적으로 쓰는 것이 항상 빠르게 되기 때문이다. 그러나 Intel은 명백하게 Larrabee에 대해 높은 수준으로 최적화된 소프트웨어 렌더러를 만들어, 이것의 효율은 충분하므로 중간 영역의 소개로 인한 어떠한 성능상의 하락들이라도 이것은 소프트웨어 렌더러의 사용으로 인한 메모리 대역폭의 감소로 이루어진 것이 된다. (우리는 조만간 이것이 어떻게 가능한지 알 수 있을 것이다.)

개발자들은 또한 Larrabee 개발에 대해 hybrid 적인 접근을 사용할 수도 있다. Larrabee는 표준 DX/OGL 코드를 동작시킬 수 있지만 현재 DirectX 버젼 내에서 사용할 수 없는 기능을 개발자가 도입하고 싶다면, 그들은 간단히 Larrabee C/C++에서 원하는 기능을 쓰면 된다.

하드웨어 없이 Larrabee가 어떻게 DirectX/OpenGL 코드에서 잘 동작될 것인지 정확히 말하는 것은 어렵지만, Intel은 이 GPU를 성공적으로 만들기 위해 현재 게임에서의 동작을 아주 멋지게 성공시켜야 한다.

9페이지

Michael Abrash에게 감사 : ISA

몇몇 사람들은 운동에 몰입한다. 다른 사람들은 연예인들에 집착한다. Derek이 영화를 보기 좋아하는 하키 팬이며 음악가일 때, 그의 진정한 열정은 그로 하여금 다른 방향으로 가게 이끌었다. 그리고 그는 또한 이것에 대해 좀 더 많은 것을 얘기 해 주기 위해 얼마간 일인칭 시점으로 말할 것이다.

한 때 나는 고등학생으로 우리의 C++ 프로그래밍 학급에 과목 외의 것을 가르치기 위해 좋은 프로젝트를 필요로 하였었다. (이것은 Jo Adams가 그녀의 학생들에게 부여한 또다른 좋은 프로젝트였다.) 내 좋은 친구 Tom Macloeod와 나는 위험에 처하게 될 정도로 충분한 미적분학과 고등 기하학을 배웠다. : 우리는 학급에 그래픽 프로그래밍을 가르치고 배우기 위해 3D 그래픽 엔진을 쓰기로 결정하였다.

이 노력을 지원하기 위해, 나는 몇몇 그래픽과 게임 프로그래밍 책을 가끔씩 사는데 약간씩의 돈을 쓰게 되었으며, (음, 어쨌거나 내 부모님의 돈이었지만) 그 중 정말 두드러진 것은 (내 삶의 경로를 설정하게 해준 것) Abrash의 Graphics Programming Black Book Special Edition 이었다.이 거대한 큰 책은 코드 최적화와 그래픽 프로그래밍의 예술과 과학에 관한 지혜를 모은 것과 Quake 개발에 대한 몇몇 거대한 세부사항이 포함되어 있었다.

그의 책이 정보의 엄청난 근원과 개인적으로 나를 감명 시킨 것 뿐만이 아니라, x86 기계어에 대한 지도자와 그래픽 프로그래밍의 신이 있어 Larrabee의 모든 특이한 명령어 셋 아키텍쳐의 설계를 취함에 있어 도움을 줄 수 있었는데, 이것이 Michael Abrash였다. 그리고 우리의 정보는 그가 이것을 모두 끝냈다는 것을 가리키는 것이다.

이것은 Larrabee의 팀이 아닌 사람들이 이목을 집중받을 자격이 없다는 것을 말하는 것이 아니다. ; 이것은 단지 나를 (나를 하드웨어에 관심을 갖게 만든) 컴퓨터 그래픽 프로그래밍에 빠져들게 한 사람이 이런 인상적인 그래픽 하드웨어 설계 팀에서 모습을 나타냈다는 것이 흥분될 뿐이다.

Abrash를 우상화 하지 않는 사람들은, 그의 Wikipedia 설명으로 하여금 게임 업계 내에서 그의 천재적 상태를 설명하는 데에 도움을 줄 것이다. :

"Michael Abrash는 기술 집필자로 높은 존경을 받고 있으며, 최고의 최적화와 80x86 기계어 프로그래머이며, 명성은 그의 1990년 책인 Zen of Assembly Language Volume 1: Knowledge로 인해 굳어지게 되었다. 기술적인 집필자가 되기 전에, Abrash는 게임 프로그래머였는데, 1982년에 그의 첫번째 상용 게임을 만들게 되었다. Windows NT 3.1에 대한 그래픽과 기계어 코드를 Microsoft에서 작업한 이후, 그는 id Software 에서 작업하기 위해 1990년 중반에 게임 업계로 돌아가게 된다. Quake에 숨겨진 몇몇 기술들은 Abrash의 Graphics Programming Black Book에 문서화 되어 있다. Quake가 배포된 이후, Abrash는 자연어 연구에 대한 작업을 하기 위해 Microsoft로 돌아갔는데, 이 때 2001년까지 Xbox 팀으로 옮겨졌다. 2002년에, Abrash는 RAD Game Tools에 대한 작업을 위해 갔는데, 여기서 그는 향상된 Pixomatic 소프트웨어 렌더러에 대해 협력 하였는데, 이것은 DirectX 7 레벨 그래픽 카드의 기능을 에뮬레이트 하며 이것은 Unreal Tournament 2004같은 게임에서 소프트웨어 렌더러로 사용되었었다."

Intel은 Larrabee 명령어 셋을 정의하는 데에 도움을 받기 위해 Abrash를 영입하여 고문에 앉히게 되었다. 긴 시간동안, (SSE4 같은) x86 확장은 소프트웨어 커뮤니티의 요청으로 인해 Intel의 엔지니어들이 끝내놓게 되었다. SSE의 계속적인 반복으로 게임 업계는 항상 만족하였으나 Intel이 소개한 x86 확장에 대해서는 절대 진실하게 만족하지 않았다. Intel이 Larrabee에 사용되어 질 x86 확장을 정의하기 시작하자, 이것은 하드웨어 생성과 내부적으로 ISA를 정의하는 것보다 사양을 정의하는 데에 더 도움을 주기 위한 게임 업계 내에서의 허상을 찾아내게 되었다. 우리가 Larrabee에 대해 게임 개발자에게서 일관성있게 듣는 한가지는 ISA가 그들이 ATI나 NVIDIA에서 본 다른 접근 방식보다 훨씬 더 이해가 잘 된다는 것이다. Larrabee의 ISA는 아주 업계 친화적으로 되기 위해, 게임 업계에 의해 설계되었다.

아주 흥미롭게도, 스스로 Larrabee의 ISA에 대한 세부사항으로 파고드는 것을 껄끄러워 하는 반면, Intel은 우리에게 5% 미만의 명령어들만이 그래픽에 한정된 것이라고 말해주었다. 과도하게 특정화된 명령어를 생성하는 것은 항상 더욱 좋은 방안이 아닌데, 그들이 컴파일러를 효율적으로 사용하며 최적화를 시키기 어렵기 때문이라는 것이기 때문이라는 것을 찾아내게 되었다. 대신, 일반적으로 적절하며 강력한 명령어가 훨씬 좋은 방안이라는 좋은 선택을 하게 되었다.

ISA 스스로 병렬 상황에서 컴파일러를 개발하는 것에 대한 장점 중 한가지는 점검과 적용 모두가 쉬쉽다는 것인데 이것은 어떻게 ISA의 균형을 최상으로 맞추느냐에 대한 이해가 필요하기 때문이다. 개발자의 대다수들은 고성능 코드를 생성하기 위해 컴파일러에 의존할 것인데, ISA가 컴파일러에 아주 딱 들어맞는다는 확신이 있어야 한다. 동시에, 소프트웨어 그래픽 엔진인 Larrabee 내의 갱신된 호기심이 실시간 3D 컴퓨터 그래픽의 오래된 보안 프로그램을 자극시키기 때문에, Michael Abrash 같은 대표적 인물이 있는 팀은 ISA가 컴파일러 친화적일 뿐만 아니라 기계어 최적화를 통한 Zen의 명성을 얻고 싶어하는 사람들에게도 또한 매력적인 사항이 될 수 있을 것이다.

이것들이 흥미로운 지점으로 우리를 이끈다.

10페이지

완전 프로그램이 가능한 그래픽의 엄청난 잠재력

확실히 우리는 Larrabee가 어떻게 실제 어플리케이션을 조종하는지를 보기 전 까지는 어플리케이션 수용력과 효과를 판단할 수 없다. 그러나 우리는 Intel이 그들의 칩을 항아리에서 꺼내버렸기 때문에 절대로 이 거인에 대해 쓰지 않을 수가 없다. 몇몇 현재의 그래픽 하드웨어 업체들은 우리에게 Intel은 현재의 개발 커뮤니티에 대해 신경을 쓰지 않고 있는데, 이것은 소프트웨어 렌더러에 대한 왕년의 그래픽 프로그래밍의 향수에 젖은 몇몇 개발자들이 Larrabee의 광대한 저레벨 프로그래밍 가용성에 대해 흥분해 있다는 이유로 인함이라고 넌지시 말하려 하고 있다.

나는 Larrabee가 DirectX와 OpenGL 성능이 시대에 뒤떨어진다는 환상을 가진 사람이 있다고 생각치 않는다. 만약 Intel이 이들 프로그래밍 API를 사용하는 게임이나 어플리케이션 내에서의 가격대 성능비가 동등하거나 뛰어나게 하는 데에 실패 한다면, 얼마나 이 하드웨어가 소프트웨어를 잘 사용하던지 간에 이것은 실패하게 된다. 그러나 렌더링 파이프라인의 모든 부분을 개조할 수 있다는 잠재력에 대해서는, 소프트웨어 렌더러를 지원하는 능력 또한 하드웨어를 개조하는 것 처럼 같은 수준의 성능을 내기에, NVIDIA나 AMD가 현재에 (아니면 가시적인 미래에) 제공할 수 있는 어떠한 것도 지금 해결할 수 있어 개발 사회에서는 가치 수준을 향상시키게 된다.

Tim Sweeney, John Carmack, Michael Abrash, 그리고 3D 그래픽 업계 내의 다른 개척자와 몽상가들에게, GPU에 의해 지금까지 제한되었던 것을 병렬적인 데이터 속도를 제공함으로써, 문자 그대로 그들이 흥미있었던 것들에 대해 그들이 원하는 것 어느것이나 할 수 있게 하는 하드웨어를 취할 수 있는 자유에 대해 다시 한번 문을 열게 되었다. 여느 주어진 코드의 성능에 의한 제한요소들은 하드웨어의 물리적 설계로 인해 아주 적어져 SIGGRAPH(Special Interest Group on Computer Graphics)가 게임으로 옮겨지는 것을 더 수월하게 만들어준다. Larrabee는 실시간 그래픽에 대한 연구, 실험 그리고 기술의 새로운 원천을 생성하는 데에 도움을 주게 되는데, 이것은 1990년 중반부터 후반까지 보지 못한 것이다.

우리는 절대적으로 현재의 그래픽 하드웨어 거구들이 유연성과 프로그램성을 강조하는 쪽으로 옮겨가는 것을 보아왔다. 그러나 만약 Intel이 효율적으로 그들의 느린 걸음을 개구리 뛰듯이 뛰어 DX 버젼으로 인해 진정한 범용 프로그래밍 DX 버젼으로 나아간다면, 우리는 하드웨어에 의해 제한된 기능을 가지는 게임은 없어질 것이라 생각한다. 머지 않아 우리는 새로운 기술과 효과를 가진 새로운 DX 버젼을 조종할 새로운 하드웨어가 필요하지 않을 것이다. : 우리는 새로운 API를 지원하는 것을 추가 하기 위해 단지 드라이버 업데이트만 하면 될 것이다. 미래의 API들을 이용해 게임을 동작시키는 데에 있어 유일한 장애물이라곤 성능 뿐이다. 미래에서의 업그레이드를 하려는 이유는 오직 속도가 될 것이다. 이것은 아주 다른 세계가 될 것인데, 업계가 탄생될 때의 근본과 아주 밀접할 정도인데 우리가 지금까지 알거나 경험했던 것과는 모두 다르게 될 것이다.

이제 컴퓨터 그래픽 분야 내에서의 변화를 볼 재미있는 시간이 왔다.

11페이지

스레드와 데이터 관리 : 이제 당신의 마음가짐을 바꿀 시간.

최근 NVIDIA와 AMD 두 업체의 그래픽 하드웨어 발표에서, 우리는 스레드 관리에 대해 아주 많은 시간동안 대담을 나누었다. Larrabee가 아주 많은 범용 스칼라와 벡터 연산 유닛의 모음으로 설계되었기 때문에, (쉐이더 프로그램과 관련 있는) 점, 초기값, 픽셀 데이터들은 소프트웨어로 관리된다. 우리가 이런 논의를 한 것에 대해 문맥상으로는 AMD와 NVIDIA의 그래픽 하드웨어에 대한 것인데, 실제로는 Larrabee 상에서의 확실히 다른 관리 체계에 대한 논의로 가게 되었다.

우리는 이야기를 시작하기 전에 AMD와 NVIDIA 들이 그들의 아키텍쳐에 물리적으로 도입된 것들이 어떤것인지에 대해 우리에게 실제적으로 말할 도덕적 의무가 없다는 것을 알아 두어야 한다.  하드웨어의 많은 특성들이 실제로는 하드웨어의 특성이 아니라 단순히 얼마나 하드웨어 자원들이 쓰이고 있는지에 대한 반응일 확률도 무시할 수 없다. 이 두 회사와 최근 우리는 그들 하드웨어의 특정한 현실성에 대해 논의 하였는데 여기에서 우리에게 밝혀진 것 중 신용 할만한 것은 만약 시스템이 특정 물리 실행같은 행동을 취한다면 이때 이것은 물리 실행과 똑같은 효과를 나타낸다는 것이다.

물론, 우리는 동의하지 않았다. 그리고 이것은 그들이 주장하는 것보다 NVIDIA와 AMD의 하드웨어 내에서 더욱 유사성을 가지고 있다는 쪽의 신빙성이 더 높다. 그러나 우리는 계속 우리가 갈구하는 지식으로 계속적으로 전진하며, 추측하기로는 Intel이 하고 있는 것이 여기서 갈리어져 나간다는 소리이기도 하다.

(최종 제품에는 8배수의 코어가 들어갈 듯 보이지만) 칩 상의 각기 Larrabee 코어는 4개의 동시 소프트웨어 스레드를 관리할 수 있다. (4 라는 것은 그 당시 활성화가 유지되는 수) 이렇게 되면 심지어 4개의 모든 스레드가 1개의 자원을 공유한다 하더라도, 표면적으로는 4개의 가상 물리 프로세서가 하드웨어 상에서 직접적으로 소프트웨어를 구동시키는 것처럼 보이게 해줄 것이다. 이것의 주 목적은 텍스쳐 데이터 따위로 인해 메모리에 접근할 때의 긴 지연시간을 숨기기 위한 것 처럼 보인다.

pic8.JPG

현재, 그래픽 렌더링의 방법은 Intel의 소프트웨어 렌더링 라이브러리나 DirectX와 OpenGL을 에뮬레이트 하여 사용 하는 것이 있는데, 큰 명령어와 데이터의 그룹 자원을 관리하기 위해 스레드가 설정되는데 Intel은 이것을 "fiber"(섬유) 라고 부른다. 일반적으로 스레드는 한번에 8개의 fiber를 관리한다. 하드웨어 스레드는 fiber를 위한 소프트웨어 내의 상황을 관리하게 된다. fiber의 역할은 (벡터 프로세서가 16-wide 이기 때문에)  16개의 "strands"(타래) 라는 다수 그룹 상의 데이터 병렬 커널 실행을 관리하는 것이다. 이 타래는 다른 그래픽 하드웨어에서 전통적으로 스레드라고 부르는 것이다. 여기에서 문제가 발생하는데 Intel 하드웨어는 실제적으로 어떤 의미로는 다른 아키텍쳐의 하드웨어 특징을 에뮬레이트 하여 스레드를 실행시키는 것도 된다.

이해를 돕기 위해, Intel의 스레드 하나를 NVIDIA의 TPC 하나로, fiber를 SM으로, 그리고 strands를 스레드로 가정해보자. 그래, 이제 좀 단순해졌다. (단순한가?) 그러나 이것은 이것을 봄에 있어 대략적인 종류의 방법이며 왜 이름을 다르게 지었는가를 이해하는 것을 빠르게 할 수 있다.

이제 좀 더 깊이 들어가보자, 코어당 4 스레드로, (최소한 8이며 바라건대 32개 코어까지) 스레드 당 8개의 fiber로, 그리고 fiber당 16개의 strands로, 우리는 종내는 엄청난 양의 strands들이 동시에 관리된다는 것을 볼 수 있게 된다. 우리가 보고 있는 이것은 활성화되어 동작중인 스레드이다. Larrabee가 진정한 의미의 단어로는 CPU이기 때문에, 시분할에 대해 활동중이거나 기다리고 있는 필요한 한 많은 스레드를 가질 수 있게 된다. 일반적인 CPU라는 관계로, 이것은 OS에 의해 관리가 되겠지만, Larrabee는 그래픽 카드로 세상에 빛을 받을 것이므로, OS에서 일반적으로 작동하도록 아마 드라이버가 시분할 이슈를 관리할 것이다.

한번에 코어 당 엄청난 양의 스레드가 동작하는 것이 성능을 저하시키는 반면, 요즘 GPU같지 않게, 자원 가용성은 스레드의 생성을 분열시키지 않는다. 피차일반인가? 그럴수도 있고, 아닐수도 있다. NVIDIA와 AMD 하드웨어에서는 지연시간을 숨기는 핵심으로 데이터가 사용 가능한 활성 스레드의 전후관계 전환을 한다. 충분한 스레드가 활동적으로 관리되지 못한다면, 성능저하가 일어나게 된다. 비슷한 문제가 Intel 쪽에서도 일어날 것인데, 만약 이것이 충분한 양의 데이터 병렬 커널을 관리하는 소프트웨어 관리 스레드를 조종하기 위해 전통적인 CPU 같은 관리 형태로 돌아간다면 다수의 스레드로 바쁜 듀얼 이슈 순차 하드웨어는 훨씬 쉽게 관리될 수 있을 것이다.

12페이지

Larrabee를 위한 최적화된 래스터라이져 만들기

우리는 지연시간에 중점을 두고 이야기를 진행하였다. 우리는 캐시와 내부 메모리 버스에 대해 말을 하였다. 그러나 외부 메모리에 대해서는 어떨까? 솔직히 말해, 우리의 대답은 잘 모른다는 것이다. 그러나 우리는 그들이 가고자 하는 쪽에 대한 것에 대해 의견을 갖고 있다. 이전의 하드웨어보다 낮은 외부 메모리 대역폭과 가능한 적은 프레임 버퍼 크기가 아무래도 목표인듯 싶다. 만약 그들이 좋은 성능을 유지할 수 있다면, 메모리의 용량과 기판 상의 도선 수를 줄이는 것으로 Larrabee 기반 카드를 팔고 싶어하는 카드 제작 벤더들에게 그들의 카드 단가를 낮출 것이다. (그리고 이것은 최종 소비자들에 대한 가격도 줄일 수 있다.)

이런 류들의 추측은 이 하드웨어에 대해 우리가 아는 것에 기반한 것이 아니다. 이것은 그들이 그들의 래스터라이져를 취하는 방법의 결정 방향에 대해 기반한 것이다. : Intel은 DIrectX와 OpenGL을 그들 고유의 소프트웨어 렌더러 같이 타일 기반의 래스터라이져를 도입하였다. 그들의 소프트웨어 렌더러에 대해 말하자면, 개발자들이 사용 가능하게 되어 맨땅에 헤딩하듯 백지에서 시작할 필요가 없을 것이라 언급하였다. 우리가 이것에 대해 이진수 세트로 사용 가능한지 원본 그대로 사용 가능한지를 묻는다면, 우리의 대답은 이것은 여전히 논의중이라는 답을 내놓을 수 있겠다. 우리 생각으로는 원본 그대로 배포하는 것이 올바른 방향인 듯 하다.

어쨌거나, Kyro의 제품군이 데스크탑 상에서 그렇게 흥미를 끌지 못한지라 AnandTech에서는 타일 기반 래스터라이제이션에 관해 충분한 논의를 하지 못하였다. 좀 더 자세히 말하자면, 화면 영역이 타일 같이 쪼개진다. 각기 타일에 대해, 초기 데이터 (삼각형) 가 설정된다. 조각들은 모든 지오메트리 내에서 기반된 타일에서 생성된다. 모든 타일 과정이 마쳐지기 전까지 이들 조각들은 연산되거나 쉐이딩 되지 않기 때문에, 오직 보여지는 조각들만이 쉐이딩 된다. (최소한, 이것은 어떻게 이것이 쓰이는가를 보면 : 몇몇 경우 주변에 늘어 놓기 위해 DX10 이상에서는 보이지 않는 조각들을 요구하는 양상을 보이기도 한다.) 막힌 조각들은 래스터라이제이션 도중 폐기된다. Intel은 또한 지오메트리, 조각과 픽셀 레벨에서 Z culling (버림) 을 지원하는데, 이것은 현실의 래스터라이제이션이나, 혼합 등에서 아주 유용하다. 소프트웨어 상에서도 똑같이 일어나야 함은 두말할 나위 없다. 가능한한 모든 지점에서의 계산량 절감은 그래픽 최적화의 운용 방식이다.

이것은 ATI와 NVIDIA가 지난 세기동안 써왔던 즉각 렌더링을 하는 방식과 완전한 반대가 된다. 즉시 렌더링을 할 때에는 화면 안의 모든 조각들이 연산되어야 하기 때문에 더 많은 메모리 대역폭이 요구되는데, 가끔씩 심지어 (프리쉐이딩 깊이 테스트 기술로써는 쉽게 버려질 수 없는) 보여지지 않는 조각에도 적용이 된다. 즉시 렌더링을 하는 방법에는 어떤 조각이 화면 내에 보여질 것인지를 알 수 있어 작업을 줄여줄 수 있게 하는 속임수가 있지만, 이런 경우는 화면 내에 보여지지 않는 조각들이 연산과 쉐이딩을 필요로 하지 않는 경우 GPU가 추가적인 작업을 할 필요가 없는 경우에 한한다.

즉시 렌더링을 할 때에는 타일 기반 렌더링 보다 더 많은 메모리 대역폭을 요구하지만, 몇몇 알고리즘과 특징은 즉시 렌더링에 쉽게 도입되어 왔다.

STMicro는 Kyro 시리즈로 200년 초 타일 렌더링으로 유명세를 아주 짧은시간 갖게 되었었다. 일너 종류의 렌더링 방법은 셀 폰/ 스마트 폰과 그래픽을 필요로 하는 초저전력 기기에서 여전히 사용되고 있다. 이 하드웨어 상에서의 성능은 아주 낮은 반면, 이런 영역에서 메모리 효율은  아주 중요하여서 그리하여 타일 기반 렌더러가 선호된다.

이 기술이 데스크탑 영역에서 나가 떨어진 이유는 천성적으로 성능을 내기가 불가능 했기 때문이 아니라, 단순히 이 영역에서 위세를 떨치는 제조자들이 이것을 사용하지 않기로 했기 때문이었다. 작은 공정 기술, 더 커진 다이 캐시 크기, 더 커지는 타일 크기, 그리고 (적은 삼각형으로 복수의 타일을 생성하는) 더 작은 지오메트리는, 타일 기반 렌더링이 가진 장점이었다... 음, 기술이 진보할수록 더 많은 장점은 생겨나게 마련이다.

타일 기반 렌더링으로 세부적으로 들어가는 것은 좀 나중에 하기로 하겠다. 그러나 말하려는 요점은 이 기술은 쉐이딩 된 후에 가려진 조각들을 더 적게 렌더링하는 결과를 낳았다는 것이다. 게다가, 타일로 들어가는 조각들의 그룹화는 작업 부하를 낮추어주고 프리페칭과 캐시의 최적화를 도와주어 조각들은 외장 메모리에서 언제나 조금씩만 전송되게 된다. (Larrabee 상에서 타일을 적용한다면 코어당 L2 캐시 영역에 반도 안되는 영역만 차지할 것이다.) 이것들과 다른 특징들은 즉시 렌더링을 사용하는 것에 비교해 필요 대역폭 양을 줄이는 데에 일조하게 된다.

약간 더 깊게 들어가보면, Larrabee에게는 전통적인 그래픽 파이프라인의 모든 단계를 소프트웨어에 도입하는 것이 짐이 될 수도 있고 장점이 될 수 있다. 현대의 GPU들이 지오메트리 설정, 래스터라이제이션, 텍스쳐링, 필터링, 압축, 압축 풀기, 혼합 등등의 기능을 하드웨어로 갖고 있는 반면, Larrabee는 (텍스쳐링과 관련된) 최소한의 고정함수 기능만을 관리한다. 가끔, 특정 목적에서는, 고정 함수 하드웨어가 범용 하드웨어보다 더욱 효율이 높고 빠를 수 있다. 그러나 동시에, 게임 개체에서의 필요로 넘어가서, 더 많거나 적은 자원을 렌더링 파이프라인의 제한된 요소에 집중 시키는 것은 고정 함수 하드웨어에서는 장점이 될 수 있다. 현대의 GPU들은 필요하다 해도 빠른 래스터라이제이션을 위해 자원 이동을 하지 못한다. 그들은 stenciling 이나 혼합의 속도를 올리기 위하여 더 많은 연산량을 할당하지는 못한다.

Larrabee의 유연성으로 하여금 어떠한 게임을 동작시키던 간에 최적의 상태로 동작시킬 수 있다. 그러나 기억해야 할 것은 소프트웨어가 더 좋은 하드웨어의 사용에 대한 큰 잠재력을 갖기 때문이지, 우리는 현재 시중에 나온 하드웨어보다 반드시 좋은 성능을 볼 수 있는 것은 아니다. 현재 나온 것에 대등하거나 뛰어넘는 실제 성능을 제공하는 제품을 만드는 것은 Intel에게 여전히 짐이 되고 있다. 효율과 적응성은 실 성능이 뒷받침 해주지 않을 때에는 필요가 없어진다.

13페이지

Larrabee에서의 타일 쉐이딩 (추가적인 장점까지)

우리는 삼각형에서 타일로 변해가는 과정을 약간 보게 되었다. Intel은 후공정 상에서 그들의 소프트웨어 렌더가 어떻게 이들을 (타일에서 화면으로) 합쳐가는지에 대해 약간 깊은 과정을 공유하였다.

첫번째로, 모든 타일들은 캐시에서 가져오게 된다. 이전으로 돌아가 어떻게 스레드들이 조직되는지를 이해한다면, 우리는 4개의 동시 동작 스레드를 갖고 있어, 이 4개의 스레드들을 같은 데이터 셋에서 작동하도록 만듦으로써 캐시를 갉아먹는 것을 방지하는 데에 일조할 수 있다. Intel은 후공정 과정 도중 소프트웨어 렌더링 스레드를 조직하는 것을 아래 다이어그램으로 그리게 되었다고 알려주었다.

pic9.JPG

우리는 여기 4 스레드 중 1개는 조각 설정 스레드로 활동하여 이것이 타일 내의 지오메트리와 이후 연산을 위한 조각 생성을 담당하고 있는 것을 볼 수 있다. 그리고 나머지 3개는 (아니면 4에서 16개의 그룹이 각기 조각을 담당하는 것도 있지만 -- 지금으로썬 이렇게 생각만 하자.) 이 때 작업 스레드로 준비된 조각을 취하고, 이것들이 보이는 것인지를 확인하여, 조각을 쉐이딩 하고, (텍스쳐를 로드 하며 쉐이더 관련 프로그램을 동작시킨다.) 계단현상 제거와 블렌드 작업 조종을 수행한다. 이것이 모두 소프트웨어 상에서 일어나는 것이라는 것을 기억하라. 이런 방법으로 꼭 해야하지는 않지만, 이것이 바로 Intel이 그들의 소프트웨어 렌더러가 DirectX와 OpenGL을 도입하면 취하는 방법이라며 알려준 것이다.

Larrabee가 제품으로 출시될 시에, 나는 확실히 이 장막 아래에서 진정 어떤것이 일어나는지, 그리고 모든것이 조직되는 것에 대해 깊게 알아볼 수 있을 거라는 희망을 가진다. 나는 Intel이 이것의 소프트웨어 렌더러 원본 코드를 공개하기로 결정한다면 승리를 할 것이라 추측하지만, 그래도 우리가 이것을 구하지 못하더라도 우리는 렌더링 파이프라인 내에서 모든 다른 단계에서 조종되기 위해 유발되는 모든 다른 종류의 스레드들, fiber들, 그리고 strand들에 대한 정보를 얻으려 노력할 것이다.

전통적인 고정 함수 기능과 이것을 소프트웨어 내에서 동작시키는 것의 대담을 나눈 것 말고도, Intel은 현대 하드웨어에서는 어려운 몇몇가지 멋진 것들을 할 수 있다. 작업을 올바르게 하기 위해 계층적인 투명화를 하려면, 게임 개발자들은 뒤에서 앞으로 물체와 폴리곤들을 분류하여야 했다. (멀리 있는 물체에서 화면에 가까운 것 순서로 렌더링을 한다) 이것이 완료되지 않는다면, 우리는 정상적이지 않게 보이는 웃긴 가공물을 얻을 수 있다. 이것들이 모두 소프트웨어 상에서 이루어지기 때문에, Intel은 개발자들을 돕기 위해 몇가지 멋진 일을 할 수 있다. : 투명한 것이 있는 곳에, 그들은 데이터를 혼합하거나 없애는 것을 즉시 하는 것 보다는 z축의 정보를 포함한 화면 위치로 그곳에 조각들의 리스트를 관리할 수 있게 된다. 이 방법으로, 혼합을 하게 되면, 지오메트리에 어떤 것을 그리게 했는지와는 상관 없이 정확하게 작업을 마칠 수 있다.

게다가, 정확하지 않은 Z-버퍼와 (인공물을 피하기 위해 화면 해상도의 그림자 맵을 생성할 수 있게 한다.) 다른 복잡한 데이터 구조물로써 요즘 GPU 하드웨어에 쉽거나 효율적으로 도입되지 못하는 것들도 Larrabee에서는 어렵게 생각하지 않고 쉽게 도입될 수 있게 된다. 모든 어플리케이션 내에서 질과 성능을 향상시키기 위해 이런 몇몇가지들을 Intel은 후공정에서 해낼 수 있다고 하지만, 이들 중 몇몇은 개발자가 새로운 아키텍쳐에 힘을 불어넣기 전에는 달라진 것을 찾기 힘든 것들이다. 게다가 이것은 새로운 것만 하는 것이 아니다. -- 여기에는 아마 계층간 투명도로 씨름할 때 그들의 폴리곤을 분류하는 단계를 모두 건너 뛰는 것을 좋아하는 개발자들에게 이점을 주게 될 것이다.

14페이지

Larrabee의 미래 : 다수 코어 영역

이것이 우리에게 Intel이 보고 있는 그들의 아키텍쳐의 방향을 제시해 주기 때문에 다시 이 슬라이드로 돌아갈 것이다.

pic10.jpg

오늘날 우리는 다수코어 배열의 영역에 있다. 다음해에, Nehalem은 1개 칩에 8코어를 얹어 나올 것이며 고려할 수 있는 것은 다가오는 2년 안에 10과 12코어 버젼을 볼 것이라는 것이다. Larrabee는 이 표에 실제적으로 없지만, 이것은 이종 멀티 스레드 코어가 나올 때까지는 따로 분리식별 될 것이다. (나머지 2개는 개발중)

이것은 미래의 Intel 데스크탑 칩이 많은 작은 Larrabee 같은 코어들에 둘러 싸인 큰 Nehalem 같은 코어의 혼합이 될 듯 하다. 당신의 미래의 CPU들은 그들에게 전통적인 싱글 스레드 데스크탑 어플리케이션이든, 3D 게임이든, 물리연산이나 다른 높은 병렬화 작업이든지 간에 던져 주기만 하면 조종할 능력이 있게 된다. 이것은 또한 미래에 대한 흥미로운 청사진을 그리게 된다. - 적당한 OS 지원으로, 게임 시스템에서 필요한 것이라면 전통적인 x86 CPU가 아닌 1개의 Larrabee 만으로도 가능할 수 있다.

pic11.jpg

이런 미래는 현재로써는 머나멀지만, 오늘날 Intel에서 Pentium M이 결국엔 미래의 데스크탑 마이크로프로세서로 진화한 것을 보면, Larrabee에 시선을 고정 해야 한다는 것인데, 왜냐하면 5년 안에 이것은 당신이 동작시키는 모든 것의 배후에 있을 것이기 때문이다.

GPU들의 발매 방법을 바꾸나?

여기에 아주 흥미로운 고려사항이 있다. Larrabee가 나오는 2009/2010년에, Intel의 45nm 공정은 성숙해질 것이다. Intel이 Larrabee를 CPU와 같은 공정으로 내놓을 가능성은 아주 농후한데, 많은 제품명으로 하여금 넓은 영역의 시장 영역을 덮게 될 것이다. Intel은 (2개 제품군이 그러듯) 1개의 전통적인 GPU 발표와 기술이 메인스트림 급으로 내려오기 전까지 몇달동안 기다리게 하지 않고 199$부터 999$의 라라비 제품을 발매하기로 결정하였다.

Intel은 GPU 업계를 혼란에 빠트릴 수 있으며 그들의 CPU 명령어로 작동하는 Larrabee를 최고 제품부터 최저 제품까지 발매함으로써 바람을 불고 오게 될 것이다.

15페이지

안좋을 상황일 경우

나는 Intel이 지난 몇년간 아주 강하기 때문에 이 페이지를 써야 했는데, 우리는 GPU시장에서도, Intel이 꼭 패배자이지 않으며, 이제 이에 대항하여 무패를 기록하려 하고 있다는 것을 명심해야 한다. 3dfx의 휘하로 제발로 걸어들어가, 그들의 IP를 가지고 다시 나온 NVIDIA는, 계속적으로 ATI에 의해 고성능과 높은 수준의 제조사 이루어진 이 분야에서 독점적으로 떠오르고 있다. 이것이 Intel의 경쟁사인데, 사업 내에서 모든 제조사들은 가장 Intel 같으며, 이것에 대해 아주 고효율을 보이고 있는 회사 중 하나이다.

Intel은 Larrabee를 제조함에 있어 그들의 진보된 제조 시설을 이용함으로 인해 이득을 볼 것이지만, 이것은 또한 그들에게 약점도 되기도 한다. NVIDIA는 GPU를 만들어 왔는데, 좀 크게 만들어도, 그들 고유의 제조 시설 투자에 땡전한푼 보태지 않아왔다. 이것이 Larrabee에 대해 악재인 상황인데, 아래 짧게 리스트를 만든것을 보면 :

제조, 설계와 수율

우리가 GPU에 대한 Larrabee의 걱정을 하기 전에, 이것은 어떤 칩을 만들던 간에 기본적인 사항이라는 것을 알아야 한다. 이것에 대해 결함이 있을 가능성은 언제나 존재하는데, 적당한 클럭 속도를 내지 못하거나, 적당한 성능을 내지 못하거나 가끔씩 충분치 않은 수율을 기록할 때도 있다. Larrabee는 데스크탑 같은 부피의 Intel로써는 가장 큰 다이를 생산할 좋은 기회인데, Intel로써는 우리가 이런 것을 기우로 만들 정도의 좋은 제조 능력을 갖고 있다.

성능

Larrabee 가 그만큼 흥미로우므로, 최소한 이것은 출시 연기가 되진 않을 것이다. NVIDIA는 이때보다 고성능을 내는 제품을 내놓아야 하는데, GT200을 상대적으로 마치 겁쟁이처럼 만들어버려야 하는 제품군이어야 할 것이다. 만약 Intel이 NVIDIA와 AMD를 뛰어 넘는 최고의 성능으로 진정한 장점을 전달하지 못한다면, Larrabee는 개량된 아키텍쳐가 나오기 전에는 이들을 제치지 못할 것이다.

드라이버와 개발자간의 관계

Intel의 드라이버 팀은 현재 그들의 강점을 부각시키려 열심히 일하고 있다. 내장 그래픽 측 상에서 우리는 계속적으로 엄청난 양의 문제를 가지고 있는데, 우리가 지금 시험하고 있는 G45 플랫폼에서도 많은 드라이버 관련 문제들이 부각되며 들려오고 있는 실정인데, 심지어 Intel에서도, IGP 드라이버 팀은 많은 구현되어야 하는 사항을 버리고 있다. 기억해야 할 것은 NVIDIA같은 회사는 대부분이 소프트웨어 엔지니어들로 구성되어 있다는 것이다. - 드라이버는 GPU를 성공적으로 만드는데 절대적이며, Intel은 그들 스스로 이것을 증명하지 않고 있다.

나는 Intel에게 누가 Larrabee의 드라이버에 대해 작업을 하는지 물어봤는데, 감사하게도 현재의 드라이버 팀은 현재의 IGP 플랫폼 상에서 열심히 작업하지 Larrabee에서는 작업하지 않는다고 한다. Intel은 Larrabee의 드라이버에 대해 작업할 그들 고유의 소프트웨어 엔지니어를 많이 갖고 있는데, 3DLabs에서 영입해 온 팀 만한 큰 팀이다. 이것이 좋은 것인지 아닌지, Intel의 능력이 시험적인 관점으로 퇴보 하였는지에 관해, 아키텍쳐로써 논하기에는 너무 빠른데, 드라이버로써는 GPU 싸움에서의 승자를 아주 쉽게 가를 수 있다.

개발자와의 관계 또한 아주 중요하다. NVIDIA/Assassin's Creed/DirectX 10.1 간의 큰 실수를 기억하는가? NVIDIA의 협력 마케팅 캠페인에 가까운 모든 최고 실력의 개발자들은 엄청나게 큰 힘을 갖고 있다. Intel이 게임 개발자들에게 강한 영향력을 행사할 수 있을 때, 우리는 여기에서 2개의 엄청나게 센 알력 싸움이 있어 고래 싸움에 새우등 터질 격이 될 수 있다.

http://anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3367

기글하드웨어(http://gigglehd.com/zbxe)에 올라온 모든 뉴스와 정보 글은 다른 곳으로 퍼가실 때 작성자의 허락을 받아야 합니다. 번역한 뉴스와 정보 글을 작성자 동의 없이 무단 전재와 무단 수정하는 행위를 금지합니다.