||1

ATI 라데온 HD 2000 시리즈, 특히 그중에서도 이번에 출시된 라데온 HD 2900XT의 아키텍처를 설명하고 그 성능을 알아보는 www.pcpop.com의 리뷰글입니다만, 주객이 전도되어 3D 기술에 대한 전반적인 설명을 한 부분이 훨씬 더 많은 글입니다.

따라서 좀 어렵고 전문적인 내용이긴 합니다만, 그만큼 도움이 되는 글이기에 무리를 해서 번역하게 됐습니다. 원 출처는 www.pcpop.com이고 번역/편집은 기글 하드웨어입니다.


라데온 HD 2000 시리즈

라데온 브랜드가 처음 사용된 이후로, ATI는 GPU의 해당 세대에 따라 숫자를 붙여왔습니다.(7세대 ATI GPU는 라데온 7000, 8세대는 라데온 8000, 9세대는 라데온 9000) 9 다음에는 10을 의미하는 X를 붙였습니다만(X000, X1000), 이번 R600, RV630, RV610 등의 R6xx 시리즈 제품부터는 X가 빠지고 그 대신 High Demand를 의미하는 HD가 붙어 라데온 HD 2000 시리즈가 되었습니다.




현재 라데온 HD 2000 시리즈의 고급형 제품은 아직까지 R600 코어를 사용하는 라데온 HD 2900XT 하나밖에 없습니다.(그리고, 지금 유일하게 출시된 제품이기도 합니다) TSMC 80나노 공정으로 제조되었으며, 7억개의 트랜지스터와 320개의 스트림 프로세서, 양방향 512비트 메모리버스, 네이티브 크로스파이어, 128비트 HDR 랜더링, 하드웨어 물리가속, HDMI 출력, 5.1채널 사운드 출력 등을 지원합니다.




라데온 HD 2900XT GDDR3


라데온 HD 2600은 TSMC 65나노 공정으로 제조되었으며, 3.9억개의 트랜지스터, 120개의 스트림 프로세서, 128비트 메모리버스를 사용하는 RV630 코어를 탑재한 중급형 제품입니다. 라데온 HD 2600은 XT와 Pro의 두가지 버전이 있는데 각기 다른 스펙의 메모리를 사용합니다. 또한 Avivo HD를 지원하여 블루레이와 HD-DVD(H.264, VC-1)의 하드웨어 코딩을 지원, CPU의 부하를 낮춰줍니다.




라데온 HD 2600XT GDDR4


라데온 HD 2600XT GDDR3


라데온 HD 2600Pro GDDR3


저가형 RV610 코어를 사용한 라데온 HD 2400은 XT와 Pro의 2가지 제품이 있습니다. 1.8억개의 트랜지스터가 내장되어 있으며 40개의 스트림프로세서, 64비트 메모리버스를 사용하며, 저가형이지만 UVD와 Avivo HD를 지원하고 HDMI와 5.1채널 사운드를 사용할 수 있습니다. 또한 전력 소모량이 25W밖에 안되기 때문에 LP 타입으로 만들거나 패시브 쿨러만으로도 쿨링을 해결할 수 있습니다.




라데온 HD 2400 GDDR2


라데온 HD 2400 GDDR2 패시브 쿨링



각 시리즈의 가격은 보시는 대로입니다. 99$ 이하의 저가형인 라데온 HD 2400, 99~199$의 중급형인 라데온 HD 2600, 399$의 고급형인 라데온 HD 2900XT(하프라이프2 에피소드2, 팀 포트리스2, 포탈을 번들로 제공합니다)


라데온 HD 2000 시리즈의 특징

라데온 HD 2000 시리즈는 HDCP(High-Bandwidth Digital content Protection)을 지원합니다. 즉, 고해상도 동영상(HD-DVD나 블루레이)의 판권을 보호하기 위해 소프트웨어/하드웨어 제조사들이 만든 보호 규약으로서, 이들 영상을 재생하기 위해서는 해당 기기가 반드시 HDCP를 지원해야만 합니다.



라데온 X1000 시리즈부터 ATI는 중고급형 그래픽카드에서 HDCP의 지원을 시작했지만, 당시에는 제조 원가 때문에 지원 제품이 그리 많이 출시되진 않았습니다. 하지만 시간이 흐를수록 고해상도 동영상의 보급이 빨라지면서, 결국 ATI는 라데온 HD 2000 시리즈의 모든 제품에서 HDCP를 지원하게 되었습니다.


초창기 그래픽카드 중에는 사운드 카드의 기능을 같이 지닌 멀티미디어 카드도 제법 있었습니다만, 3D 성능에 중시하게 되면서 그래픽카드와 사운드카드는 완전히 갈라지게 되었습니다. 허나 HDTV의 보급과 응용이 늘어나면서 사운드카드와 그래픽카드가 다시 하나로 합쳐지게 되었습니다.



라데온 HD 2000의 코어에는 완벽한 사운드카드 기능이 내장되어 있습니다. 물론 이것이 크레에이티브 사운드블래스터 X-Fi 같은 카드와 경쟁하게 된다는 의미는 아닙니다. 라데온 HD 2000 시리즈의 사운드는 HDMI 출력을 위한 것으로서, HDMI를 사용하는 텔레비전에 영상과 사운드를 더 간편하게 출력할 수 있게 해줍니다.



DVI-HDMI 젠더를 통한 라데온 HD 2000 시리즈는 풀 HD 5.1 사운드 데이터를 출력할 수 있다고 합니다. 자세한 내용은 나중에 다시 다루겠습니다.


고급형인 R600(라데온 HD 2900XT)는 여전히 80나노 공정으로 제조되었지만 그 외의 2가지 제품인 RV630(라데온 HD 2600), RV610(라데온 HD 2400)은 TSMC 65나노 공정을 사용합니다. 세계 최초의 65나노 공정 GPU라고 할 수 있겠습니다.

개선된 제조 공정 덕분에 RV630과 RV610의 다이 크기는 기존의 RV5xx 시리즈보다 더 줄어들어, 제조 원가가 저렴해졌을 뿐만 아니라, 소모 전력과 발열이 크게 개선되었습니다.


R6xx 시리즈는 사운드카드를 내장하고 HDMI와 HDCP를 내장한 것 외에도, 차세대 동영상 가속 엔진인 UVD를 사용하고 있습니다. Avivo의 업그레이드 버전으로서 UVD 엔진은 HDTV에 연결하여 동영상을 재생할때 뛰어난 성능을 보여줍니다.

기존의 영상 처리에서 CPU와 GPU가 같이 작업을 했던 것과는 달리, UVD는 블루레이나 HD-DVD 등의 H.264와 VC-1 코덱을 쓰는 고해상도 동영상의 모든 코딩 과정을 혼자서 처리, CPU의 부하를 크게 줄여줍니다.


3D의 기본적인 처리 과정

R600 아키텍처의 제일 큰 특징은 역시 2세대 슈퍼스칼라 통합 쉐이더 아키텍처(Superscalar Unified Shader Architecture)를 사용한다는 것입니다. XBOX360에서 사용된 Xenos GPU를 기반으로 하여 만들어진 것인데, R600의 이 통합 쉐이더 아키텍처를 설명하기에 앞서 3D 그래픽과 프로그램의 원리에 대해 먼저 설명하고자 합니다.

1. 응용 프로그램의 로드/장면 구축
일단 배경/지오메트리 데이터베이스의 움직임, 오브젝트의 운동, 관찰 시점의 이동과 줌 인/아웃, 모델의 움직임, 3D 화면 내용의 묘사, 화면에서 보이지 않는 부분의 삭제, 세부 레이어의 선택 등을 먼저 처리합니다. 간단하게 말해서, 게임 중에 어떤 오브젝트가 있고, 그 오브젝트가 사용하는 모델과 텍스처, 프레임, 위치, 시점의 위치와 방향 등을 결정합니다.

2. 지오메트리 처리
다음으로 지오메트리(기하학) 처리를 합니다. 기존의 Transforms & Lighting(형태 변형과 광원 처리, T&L)이라고 할 수 있겠습니다. 몇개 기하 모델의 변환(회전, 이동, 수축, 확대)을 통해 가상 모델 공간을 다이렉트 3D 공간으로 옳겨오고, 관찰 공간의 변환, 투영, 세부 처리, 뒷면 삭제(즉, 화면에서 보이지 않는 부분), 광원 처리, 투시 분할등의 작업으로 화면에 나타나게 되는 부분을 잘라내게 됩니다.


3D 골격 모델

이 과정 중에서는 텍스처나 질감 처리가 포함되지 않고, 오직 골격 구조의 위치와 형상을 정하게 되는데, 이 모델을 기본으로 하여 버텍스(삼각형의 꼭지점) 데이터를 사용하게 됩니다. 2개의 점은 하나의 선을 만들 수 있고, 3개의 점은 하나의 면, 즉 삼각형을 만들 수 있습니다. 여러개의 삼각형은 하나의 다각형(폴리곤)을 만들 수 있고, 이러한 다각형들이 여러개 모여서 하나의 지오메트리 모델을 완성시키는 것입니다.


골격에 폴리곤을 씌운 그림

뿐만 아니라 3D 화면에서는 어떤 버텍스이건 모두 하나의 좌표를 사용합니다. 물체가 운동하는것은 곧 버텍스 좌표가 변하는 것이며 이는 곧 지오메트리 모델의 변환을 뜻합니다. 이러한 절차 가운데에서 모든 모델은 1개 1개의 버텍스의 위치를 전부 다시 설정하게 됩니다.



그 후에는 관찰 투영(Projection)을 합니다. 3D 기하 모델로 이루어진 3D 상태의 화면을 2D 상태로 바꿔주는 것입니다. 구체적인 방법은 3D 기하 모델의 모든 버텍스의 3차원 좌표를 투영-프로젝션-을 통하 2차원 좌표로 전환하는 것인데, 이 과정중에 전환되는 평면값은 사용자가 게임(3D 프로그램)에서 위치한 방향과 시야에 따라 결정됩니다. 이 과정에서도 컴퓨터는 텍스처 맵핑 등의 조작을 하지 않으며, 모든 버텍스는 여전히 독립되어 있을 뿐, 서로 아무런 관계가 없습니다.


투영. Projection

이 단계에서는 HSR이 포함됩니다. 실제로 보이지 않는 부분을 잘라내어 효율을 높이는 것입니다. 3D 기술이 사용되던 초창기에는 모든 3D 장면에 포함된 버텍스의 좌표를 전부 변환하였으며, 결국 화면에 실제로 표시되지 않는 모델도 처리되게 되었습니다. 그래서 개발자들이 Z 버퍼라는 개념을 도입, 먼저 Z 축을 기준으로 모든 버텍스의 전후 관계를 판단하여 어떤 부분이 화면에 표시되고 표시되지 않는지를 결정하게 됩니다. 나중에는 스캔 라인 Z 버퍼가 도입되어 초창기 z 버퍼가 대량의 메모리를 사용하던 결점을 보완하게 됐습니다.


HSR

3D 프로그램에는 배경과 오브젝트 외에도 수많은 광원이 있습니다. 광원이 없다면 3D 오브젝트 역시 보이지 않습니다. 3D 게임이건 3D 영상이건 광원을 더한 3D 랜더링에는 대량의 수학 계산이 필요합니다. 하드웨어 T&L을 지원하기 전에는 이 작업을 CPU가 담당했지만, NVIDIA의 지포스 256부터 하드웨어 T&L을 지원하기 시작, CPU가 무거운 수학 연산 부담에서 벗어나게 됩니다. 나중에 하드웨어 T&L 유닛은 버텍스 랜더러 유닛으로 바뀌게 되며, 이번의 라데온 HD 2900XT는 통합 쉐이더 아키텍처에서 64개 5D 통합 쉐이더 연산 유닛 이론을 사용, 버텍스 연산 성능이 크게 개선되었습니다.

3. 폴리곤 생성
그 다음은 폴리곤의 생성입니다. 이 과정은 이미 2차원 좌표로 바뀐 점과 점 사이의 관계를 근거로 하여 삼각형을 만드는 것으로, 골격 모델에 폴리곤 네트워크를 만드는 것이라고 할 수도 있습니다. 이렇게 모델 위에 씌운 폴리곤 껍질은 다음 단계에서 텍스처를 씌우기 위한 준비 작업이기도 합니다. 이 과정은 보통 연산이나 벡터 계산이 필요합니다.


5천개의 폴리곤으로 만든 모델


2백만개의 폴리곤으로 만든 모델

폴리곤을 만드는 이 과정은 Setup으로 불리기도 하며, 지포스 256이 발표될 당시에는 이 폴리곤 생성 능력이야말로 그래픽카드의 성능을 결정하는 제일 중요한 기준이 되기도 했습니다.

4. 랜더링/래스터 처리
먼저 원시적인 텍스처 랜더링과 맵핑, 질감 처리등을 합니다. 대부분의 상황에서는 텍스처가 비스듬하게 보이기 때문에 이 역시 그림의 형태를 변형하는 과정이 필요하며, 이 중에 자주 듣게되는 텍스처 필터링(Texture Filtering, 이선형, 삼선형, 이등방성 등의 각종 필터링) 처리를 하게 됩니다.


텍스처 필터링의 종류

응용 프로그램은 기하학적 모델에 텍스처를 맵핑하여 붙일때 텍셀을 이용하여 화면의 점에 직접 투영합니다. 예를 들자면 텍스처의 글을 선명하게 표시하기 위해, 응용 프로그램은 모종의 방식으로 지오메트리 모델의 텍셀이 텍스처 필터링의 영향을 받지 않고 확실하게 영사할 수 있습니다.

만약 이렇게 하지 못한다면 텍스처가 상당히 모호하게 보이게 될 것이고, 텍스처 필터링을 할 때 가장 가까운 점을 이용한다면 계단 현상이 생기게 될 것입니다. 픽셀과 텍스터를 같이 샘플링하고, 동시에 텍스처 필터링을 지원하기 위해 다이렉트 3D의 픽셀과 텍스처 샘플링은 상당히 자세하게 정의되어 있습니다. 그러나 이것은 텍스처 중의 텍셀이 직접 화면에 영사하는 점을 만드는데 상당히 어렵게 만드는 일이기도 합니다.

이 과정은 프로그래밍이 가능한 픽셀 유닛이 나오자 더욱 복잡했졌습니다. 실시간 음영, 광원 계산, 심지어 맵핑 필터링의 3D 맵핑 기술까지 모두 픽셀 쉐이더가 처리하는 것이며, 따라서 픽셀 쉐이더는 그래픽카드 성능에 제일 큰 영향을 주는 한 부분이 되었습니다. 기존의 R580 GPU는 48개의 4D 픽셀 쉐이더 유닛이 내장되어 있지만, R600에서는 응용 범위가 넓은 통합 쉐이더 아키텍처를 사용, 이론적으로 픽셀 쉐이더 처리를 할때 최대 64개의 5D 통합 쉐이더 유닛을 사용할 수 있습니다.

두번째로 폴리곤의 픽셀을 채웁니다. 모든 픽셀을 삼각형 안에 채워 넣는데 구체적인 실행 과정은 픽셀 쉐이더가 픽셀의 계산을 동기화하여 실행합니다. 먼저 픽셀을 처리하고 그걸 채운 다음 다시 픽셀 쉐이더가 픽셀을 처리하는 식입니다.

이 과정중에 처리하게되는 데이터의 양은 비교적 많습니다. 만약 FPS가 정해져있고 해상도가 일정하다면 데이터의 양 역시 정해져 있습니다. 만약 안티 에얼라이싱 처리를 한다면 처리해야 하는 픽셀 데이터의 양은 배로 늘어나게 됩니다. 이 부분은 3D 가속 카드가 등장한 이후로 지금까지 그래픽카드 성능의 제일 중요한 기준이며, 게임의 표시 속도를 직접적으로 결정하는 부분이게도 합니다. 우리는 보통 이것을 Fill Rate(필 레이트)로 표기합니다.


3D마크의 픽셀 필 레이트 테스트

화면의 보이지 않는 부분을 삭제하는 방법이 나오기 전까지는, 이 역시 Z 버퍼의 데이터를 바탕으로 Z 버퍼가 판단하여, 어떤 픽셀을 화면에 표시하고 어떤 픽셀을 화면에 표시하지 않을 것인지를 결정했습니다. 하지만 이런 방식은 효율이 매우 떨어지기 때문에 지금은 사용되지 않습니다.



알파 블랜드 프로세스 처리 전과 후.

마지막으로 래스터 처리를 하고 버퍼를 통해 출력하게 됩니다. 이 과정중에는 이미 랜더링이 완료된 픽셀에 투명도(알파 Alpha) 혼합(블랜드) 처리를 하는데, 이 과정 중에 마지막으로 우리게 보게 되는 화면을 결정하게 됩니다. 이 부분은 대량의 계산이 필요하며 따라서 여러개의 ROP 유닛이 동시에 실행되도록 설계되어 있습니다.

ROP 처리를 거친 데이터는 모니터의 화면에 표시되기 위해 그래픽카드의 버퍼에 저장되고, 그 후에 출력됩니다. 이 버퍼의 속도는 매우 빠르기 때문에 우리는 느끼지 못합니다.

이렇게 해서 모든 그래픽카드의 파이프라인 처리 과정 계산이 끝나게 됩니다. 마지막으로 램댁(RAMDAC)을 통해 신호를 아날로그로 바꿔 D-sub 단자를 통해 모니터에 출력하거나, 아니면 TMDS를 통해 TMDS 신호로 바뀌어 DVI 포트를 통해 모니터에 출력하게 됩니다.


기존 쉐이더 아키텍처와 통합 쉐이더 아키텍처의 비교

R600의 통합 쉐이더 아키텍처에 대해 설명하기 전에, 일단 기존 쉐이더 아키텍처에 대해 간단히 알아보도록 하겠습니다. 그래야 어떤 점이 바뀐 것인지를 비교할 수 있겠지요.

3D 그래픽은 일종의 순서에 따라 처리되는데, 이 처리 과정 아키텍처가 마치 하나의 파이프와 같으며, 각종 데이터가 파이프에 들어가는 것이 파이프 안의 액체처럼 멈추지 않고 계속 다음 단계로 내려가는 방식입니다. 이것이 곧 '파이프라인'이라는 말이 여기서 쓰이게 된 이유이기도 합니다.


기존의 전통적인 3D 처리 파이프라인

그러나 지금 사용되는 GPU들은 여러 종류의 파이프라인을 사용합니다. 픽셀 쉐이더 파이프라인이라던가, 버텍스 쉐이더 파이프라인이라던가, 픽셀 랜더러 파이프라인이라던가... 이중 픽셀 랜더러 파이프라인은 GPU에 계속 존재하며 폴리곤의 생성 능력처럼 초창기 GPU 코어 성능의 판단 기준이 되었으며, 지금은 ROP 유닛으로 바뀌었습니다.

픽셀 쉐이더 파이프라인과 버텍스 쉐이더 파이프라인은 다이렉트 X 8부터 등장한 것으로 프로그래밍이 가능한 특징을 지니고 있습니다. 나중에 픽셀 랜더러 파이프라인을 제치고 상대적으로 중요한 위치에 올라서게 되면서 그래픽카드의 성능을 판단하는 중요한 부분이 되었습니다.(조금만 그래픽카드에 관심이 많으신 분이시라면 이들 파이프라인이 몇개니 운운하는 소리를 본 적이 있으실 것입니다)


여기서 한가지 눈여겨 볼만한 것은, 지금까지의 그래픽카드들에서 버텍스 파이프라인과 픽셀 파이프라인의 수가 다르다는 것입니다. 픽셀 쉐이더 파이프라인의 수가 더 많고, 버텍스 쉐이더 파이프라인의 수가 더 적지요. 그렇다면 왜 이렇게 한 것일까요? 그 이유는 이러한 비율의 구조가 대다수의 게임에 잘 맞기 때문입니다.

세상에는 다양한 게임이 존재하고, 제각각 다른 방식으로 설계되었습니다. 어떤 게임은 매우 간단하지만 어떤 게임의 구조는 매우 복잡하지요. 게다가 사용하는 자원의 양이 일정하게 정해져 있지 않습니다. 이는 그래픽카드 제조사들에게 상당한 골치거리입니다.

구체적인 예를 들어보면, 복잡한 3D 모델을 사용하여 버텍스의 수가 특히 많은 게임이 있습니다. 이런 게임은 대량의 버텍스 쉐이더 파이프라인 자원을 사용하게 됩니다. 반면, 픽셀 단위의 특수 효과에 더 많은 처리를 한 게임도 있습니다. 이런 게임은 대량의 픽셀 쉐이더 파이프라인 자원을 소모하게 되겠지요.


픽셀 쉐이더와 버텍스 쉐이더 작업량의 불균형

위의 그림대로 상어가 나오는 장면이 표시된다고 가정합시다. 이 장면은 상어를 표시하기 위해 대량의 폴리곤이 사용되기 때문에 버텍스 쉐이더의 연산량이 아주 높은 반면, 픽셀 쉐이더는 거의 사용되지 않습니다.

그러나 두번째 장면에서 상어가 사라지고 물의 움직임이 표시되는 장면으로 바뀐었을 경우라면, 대량의 광원 특수효과를 위해 픽셀 쉐이더 유닛을 많이 사용하게 되지만 버텍스 쉐이더 유닛은 작업할 것이 별로 없습니다.

결국 특정 장면에서는 특정 쉐이더만 사용하고 다른 쉐이더는 놀게 되는, 쉐이더 잡업량의 불균형이 초래되는 것이며, 이것은 GPU 전체 성능이 심각하게 낭비되고 있다고 봐도 무방하겠습니다.


버텍스 쉐이더와 픽셀 쉐이더의 실제 평균 작업량

따라서 GPU 제조사는 대다수의 게임에서 자주 사용하는 방식에 맞춰서 픽셀 쉐이더와 버텍스 쉐이더의 비율을 결정하게 된 것입니다. 이렇게 되자 게임 개발사들도 마음대로 게임을 만들지 못하고, GPU의 픽셀/버텍스 비율에 맞춰서 부하량을 조절하가며 게임을 개발하게 되는 모순이 생겨난 것입니다.

이러한 문제를 해결하는 방법이 바로 통합 쉐이더인 것입니다. 통합 쉐이더의 모든 프로세스 유닛은 버텍스 쉐이더 연산과 픽셀 쉐이더 연산(그리고 다이렉트 X 10에서 추가된 지오메트리 쉐이더 연산)을 할 수 있습니다. 따라서 어떤 게임이건, 어떤 상황에서건 그래픽카드의 자원을 전부 활용할 수 있으며, 그만큼 더 우수한 성능과 뛰어난 그래픽을 표시할 수 있습니다.

대량의 버텍스 연산을 해야 하는 장면에서는 통합 쉐이더가 전부 버텍스 연산을, 버텍스 연산이 끝나고 픽셀 쉐이더로 특수 효과를 처리해야 하는 부분에서는 통합 쉐이더가 전부 픽셀 쉐이더 연산을 하면 되는 것입니다. 이러한 동적인 처리 방식은 여러개의 유닛의 병렬 실행을 가능하게 하기 때문에 기존의 직선 형태의 아키텍처처럼 순서대로 실행할 필요가 사라져 효율을 더 높일 수 있게 됩니다.


ATI의 1세대 통합 쉐이더 아키텍처, Xenos


XBOX360

2003년 8월, ATI는 마이크로소프트의 차세대 게임기인 XBOX360의 GPU를 만들게 됩니다. 이때부터 ATI는 1세대 통합 쉐이더 아키텍처 GPU인 Xenos(코드네임 C1)의 개발에 정식으로 착수하게 됩니다. Xenos의 연구-개발-제작은 2005년 말에야 비로서 끝나게 되는데, Xenos는 세계 최초의 통합 쉐이더 아키텍처를 사용한 GPU가 되었습니다.

Xenos는 2개의 코어로 구성되어 있으며, 2억3천2백만개의 트랜지스터가 내장되어 있고, 500Mhz의 클럭으로 작동하며, 48개의 통합 쉐이더가 내장되어 있습니다. NEC 90나노 공정으로 제조된 왼쪽의 작은 코어(Daugther Die)는 1억개의 트랜지스터가 내장되어 있으며, 샘플링, 색상의 읽기/쓰기, 혼합, 멀티 샘플링 AA, Z 버퍼 연산 등을 담당합니다.


Xenos 코어

Xenos 코어의 특징은 다음과 같습니다.
1. 세계 최초의 통합 쉐이더 아키텍처 GPU. 그래픽 연산의 효율이 더 좋고 최적화되어 있다.
2. 하드웨어 스레딩 분기 유닛을 통해 쉐이더 유닛의 이용 효율을 증가, 통합 쉐이더가 코어 쉐이더들에 가해지는 부하의 평형을 유지
3. 지응적인 내장 메모리를 사용, 최고 320M/s 대역폭을 지원. 전문 논리 컨트롤러 유닛과 AA, 알파 블렌딩을 담당.
4. 데이터를 직접 CPU의 캐시에서 읽거나/쓸 수 있음. 더 높은 효율의 프로세스 스트림 명령어.
5. 독자적인 전문 컴파일러




Xenos의 쉐이더 아키텍처

통합 쉐이더 아키텍처는 하드웨적으로 볼 때 버텍스와 픽셀 쉐이더 유닛의 구분이 없습니다. GPU는 서로 다른 쉐이더 유닛에서 각각의 담당 쉐이더를 처리하는 것이 아니고, 통합 쉐이더에서는 2종의 쉐이더 유닛을 하나로 합쳐 통합 쉐이더를 구성, 모든 통합 쉐이더 유닛은 필요한 작업에 따라서 데이터를 처리할 뿐, 버텍스/픽셀 쉐이더같은 식으로 그 종류가 나뉘지 않습니다.


Xenos의 아키텍처

Xenos는 48개의 4D+1D(벡터+스칼라) 통합 쉐이더가 있습니다. ALU 유닛은 SIMD 아키텍처로 16개의 랜더러 유닛이 하나의 배열(Array)을 구성하고 있으며, 여기에 몇개 배열의 쉐이더 유닛이 명령 연산이나 특정 종류의 계산을 담당하게 되는데, 이는 Thread Arviter(스레드 중재기)를 통해 조절됩니다.

하지만 Zenos의 배열에 포함된 유닛은 1사이클에 같은 종류의 명령만 처리할 수 있습니다. 1 사이클에서는 픽셀 쉐이더, 다음 사이클에서는 버텍스 쉐이더, 이런 식으로 말이지요. 융통성이 그리 좋은 편은 아니지만 어쨌건 통합 쉐이더라고 할 수 있으며, 쉐이더 유닛의 부하 평형을 이루는데 큰 개선을 한 것도 사실입니다.




Shader array. 쉐이더 배열

Xenos는 3개의 배열 컨트롤러가 있으며 최대 64개의 병행 스레드를 지원하여, 쉐이더 유닛의 이용 효율을 높이고 랜더러 파이프라인의 딜레이 문제를 개선하였습니다. 통합 쉐이더의 3개 배열 쉐이더 유닛(하나의 쉐이더 유닛 배열에는 16개의 쉐이더 유닛이 있으니 쉐이더 유닛의 수는 모두 48개)은 하나의 배열 쉐이더 유닛이 각각 독립된 스레드 컨트롤러가 있다는 뜻이며, 스레드 아비터의 수가 더 늘어날수록 쉐이더 명령어의 분기를 더 효율적으로 처리할 수 있다는 의미이기도 합니다. Xenos의 쉐이더 어레이는 통용 그래픽 계산에서  95%의 효율을 보여주었다고 합니다.




Geometry Tessellation Unit

지오메트리 쉐이더는 없지만 지오메트리 테셀레이션 유닛이 증가되어, 삼각형, 직사각형, 정방형 등의 도형을 입력받아 분할 처리할 수 있습니다. 하지만 Xenos의 테셀레이션 유닛은 고정 기능 유닛이어서 프로그래밍이 불가능하기 때문에 지오메트리 쉐이더의 초기 모델이라고 볼 수 있겠습니다.

테셀레이션은 나중에 다이렉트 X 10의 지오메트리 쉐이더의 기능이 되며, Xenos는 지오메트리 쉐이더가 없기 때문에 폴리곤을 스스로 만들어 낼 수는 없지만, Xenos의 Memexport와 CPU Streaming 기술은 나중에 다이렉트 X 10의 스트림 아웃(Stream-Out) 기능으로 실현되게 됩니다. 따라서 Xenos는 데이터를 직접 CPU의 캐시에 보내서, 여러 용도로 쓸 수 있는 폴리곤을 만들 수 있습니다. Memexport는 시스템 메모리의 벡터 데이터를 직접 교환함으로서 Xenos의 통용 계산 성능과 쉐이더 프로그램의 길이를 확장시키게 됩니다.



동시에 Xenos의 데이터 스트림 컨트롤러의 효율은 더욱 좋아졌고, 버텍스와 픽셀 계산을 통일된 명령어 세트에 포함시켜 더 복잡한 그래픽 계산을 더 빠르게 처리할 수 있게 되었습니다.



텍스처 취합 유닛

Xenos에는 16개의 텍스처 취합 유닛(LOD가 포함된 텍스처 필터링 유닛)과 16개의 버텍스 취합 유닛(필터링을 거치지 않음/픽셀 샘플링 유닛)이 있습니다. 만약 약간의 부속 텍스처 유닛을 늘리려고 한다면, 이러한 모든 요소들이 텍스처 처리 배열에 의해 조절될 뿐더러 모든 텍스처 유닛은 자신만의 텍스처 어드레스 프로세서가 있습니다. 모든 필터링 텍스처 유닛은 이중 선형(bilinear) 샘플링이 가능하고 삼선형이나 더 높은 배열 필터링 기술(Anisotropic Filtering 이등방성 필터링)도 지원합니다.

XBOX360은 UMA 컨트롤러를 사용하며 모든 램 시스템에서 텍스처 필터링을 지원합니다. 10MB eDRAM이 AA 작업을 할 때 용량 문제를 해결해주며, Xenos는 타일 랜더링 방식으로 FSAA를 사용할 수 있습니다. 그 밖에도 Xenos는 Multiple Render Targets, Hierarchical Stencil Buffer, Alpha-to-Mask 등의 기술을 지원합니다.


다이렉트 X의 소개

다이렉트 X는 마이크로소프트가 개발한 윈도우즈 플랫홈용 API로, 빠른 실시간 동화상 랜더링과 음악 환경, 사운드 효과등을 처리하기 위해 개발된 서비스입니다.

지난 10년동안 다이렉트 X는 윈도우즈 운영체제에서 게임 개발에 제일 많이 사용되는 API가 되었으며, 새로운 버전의 다이렉트 X가 새로운 하드웨어 기능들을 지원하면서 게임 개발자들이 더 화려한 효과를 사용할 수 있게 해주었습니다.


다이렉트 X의 매커니즘

마이크로소프트는 다이렉트 X 표준을 만들었을 뿐만 아니라, 하드웨어 제조사와 게임 개발사들과 같이 다이렉트 X 표준을 업데이트했습니다. 하드웨어 제조사들은 이 표준에 맞춰 더 좋은 제품을 만들고, 게임 개발사들은 이 표준에 맞춰 게임을 개발합니다. 게임 개발자들이 다이렉트 X 표준에 맞춰 특정 효과가 들어간 게임을 개발하고, 그 게임을 해당 하드웨어에서 실행하면, 다이렉트 X 표준에 맞춰 드라이버에서 해당 기능을 찾아서, 특정 효과를 지원하면 표시하는 것이고 그렇지 않으면 그냥 넘어가게 됩니다. 즉, 하드웨어 장치와 상관 없이 작동한다는 것이 다이렉트 X의 진정한 존재 의의입니다. 


다이렉트 X 아키텍처

윈도우즈는 하드웨어 엑세스 관리가 매우 엄격하게 제한되어 있습니다. 하지만 다이렉트 X는 HAL을 통해 게임 개발자들이 하드웨어에 접근할 수 있도록 해주며, 하드웨어 호환성 문제를 해결합니다. 따라서 개발자들은 하드웨어 가속을 충분히 이용하여 프로그램 성능을 최적화 시킬 수 있게 됩니다.

다이렉트 X에는 Direct3D, DirectDraw, DirectInput, DirectMusic, DirectPlay, DirectSound, DirectDraw, DirectVoice,  DirectVideo, DirectShow가 포함되어 있습니다.


다이렉트 X의 발전사

마이크로소프트에서 발표한 다이렉트 X 10은 프로그래밍 가능한 쉐이더를 통해 3D API의 거대한 발전을 이루었습니다. 이번 다이렉트 X 10 버전은 다이렉트 X의 탄생 이후로 철저하게 기본부터 다시 설계한 것이며, 다이렉트 X 10에는 여러가지 매혹적인 새 기능들-고도의 실행 최적화, 강력한 지오메트리 쉐이더, 텍스처 배열 등등-이 포함되어 있습니다.

다이렉트 X 버전	대표적인 기술	대표적인 하드웨어	대표적인 효과	대표적인 게임
1.0
2.0	D2D의 성숙	트라이언트 9680, S3	동적인 2D 효과	레드얼랏, 디아블로
3.0	D3D의 기초	리바 128, i740	간단한 3D 효과	모토레이서, 니드포3
5.0	기본적인 3D 기술	리바 TNT	연기, 혼합 효과	툼 레이더 3
6.0	성숙된 3D 기술	리바 TNT2	이선형/삼선형 필터링	니드포5, 카스
7.0	T&L	지포스 256, 라데온	요철 효과	모토레이서3, 디아블로2
8.0	PS, VS	지포스 3, 라데온 8500	수면 파문 효과	3D마크01
8.1	PS, VS의 업그레이드	지포스 4, 라데온 9700	큰 텍스처의 수면 파문	니드포 핫퍼슈트2
9.0	높은 버전의 PS, VS	지포스 FX, 라데온 9800	털과 머리카락 효과	툼레이더 6

다이렉트 X 1.0

1995년 9월, 윈도우즈 95의 발표와 맞춰 다이렉트 X 1.0이 발표됩니다. ATI의 개발팀들이 다이렉트 X의 제일 기조척인 그래픽 기술을 만들었습니다만, 다이렉트 X 1.0은 지원하는 하드웨어가 별로 없었고, 당시에는 오픈GL의 인기가 매우 좋았기 때문에 별로 성공하지 못했습니다. 다이렉트 X 1.0은 처음으로 하드웨어 데이터를 직접 읽고/쓸 수 있는 프로그램이었고, 기본적인 사운드 입/출력 기능과 2차원 그래픽 가속을 지원했습니다. 이때에는 아직 다이렉트 3D가 포함되지 않았습니다.



다이렉트 X 2.0/2.0a

1996년 윈도우즈 95의 성공을 바탕으로, 마이크로소프트는 윈도우즈 95에서 더 많은 3D 게임을 실행할수 있도록 하기 위해 영국 Rendermorphics,Ltd.을 인수, 이 회사가 개발한 RealityLab의 3D API를 다듬어서 다이렉트 3D로 명명, 다이렉트 X 2.0에 포함시킵니다.

다이렉트 X 2.0의 최대 개선점은 다이렉트 드로우입니다. 당시 인기를 끌었던 게임인 레드얼랏 윈도우즈 버전과 디아블로는 모두 이 다이렉트 X 2.0을 바탕으로 개발된 것입니다. 2D를 제외한 3D 부분은 기초적인 형태가 완성되어 있었지만, 당시 3D 게임은 그 수가 아주 적었고 대다수의 게임이 여전히 도스 기반으로 개발되고 있었습니다.

다이렉트 X 2.0에서는 가상 평면과 가상 RGB를 사용, 3차원 그래픽 계산 속도를 높였고, 여러가지 문제들을 수정했습니다. 다이렉트 X 2.0 시대에 전체 다이렉트 X의 설계 아키텍처가 기본적으로 완성된 셈입니다. 다만 이때 3D 게임은 3DFX의 글라이드와 ID의 퀘이크(오픈 GL)이 대다수였으며, 세가의 버추어파이터 PC 버전 정도가 다이렉트 2.0으로 개발되어 출시된 당시의 유명 3D 게임일 것입니다.


다이렉트 X 3.0/3.0a

1996년 후기에 다이렉트 X 3.0이 발표됩니다. 3.0은 2.0의 마이너 업그레이드 버전으로, 2.0에서 바뀐 부분이 그리 많지 않습니다. 다이렉트 사운드(3D 사운드 기능), 다이렉트 플레이(게임/네트워크)가 일부 업그레이드 되었으며, 여전히 간단한 3D 기능만을 지원하고 있었습니다.

이 버전부터 많은 게이머들이 다이렉트 X의 존재를 알게 되었으며, 다이렉트 3D를 지원하는 가속 카드들이 출시되게 됩니다. NVIDIA의 리바 128이라던가 인텔의 i740 같은 카드들이 그것입니다.

다이렉트 3D의 확장은 그리 순조롭지만은 않았습니다. 당시 마이크로소프트는 윈도우즈 95에서 오픈GL의 MCD 드라이버의 지원을 거절했으며, 존 카멕(둠, 퀘이크의 개발자)은 다이렉트 3D의 사용을 공개적으로 거부하고, 56명의 게임 개발자들과 연대하여 오픈GL MCD 드라이버의 지원을 촉구하는 편지를 보내기도 합니다. 당시 저명한 게임 제작자인 Chris Hecker는 게임 개발 잡지에 2개의 API를 비교한 글을 실어, D3D를 공격하기도 했습니다.

하지만 마이크로소프트는 끝까지 자신들의 입장을 고수했습니다. 즉, 다이렉트 3D는 통용 고성능 API이고, 오픈GL은 CAD 등의 작업 전문이라는 것이지요. 그래서 마이크로소프트는 다이렉트 3D의 지원을 더더욱 늘리게 됩니다.(결과는 여러분들께서 지금 보시는대로...)


다이렉트 X 5.0/5.1/5.2

1997년 6월, 마이크로소프트는 다이렉트 X 4.0을 건너뛰고 다이렉트 X 5.0을 출시합니다. 다이렉트 X 5.0의 다이렉트 3D는 스모크 효과와 알파 블렌딩을 추가하는 등의 대규모 개선을 통해 3D 게임에서의 현실감을 극대화시켰으며, S3의 텍스처 압축 기술이 추가되었습니다.


다이렉트 X 5.0의 아키텍처

그리고 다이렉트 X 5.0은 각종 부품들의 성능도 강화시켰습니다. 사운드카드나 게임 컨트롤러등의 지원이 개선되어 더 많은 장치를 사용할 수 있게 되었습니다. 다이렉트 X는 5.0이 되서야 성숙 단계에 들어서게 되었고, 이때의 다이렉트 X 성능은 다른 3D API에 뒤지지 않는 수준에 이르르게 되었습니다.

이때 유명한 게임들-툼 레이더 2나 니드 포 스피드 2는 처음에 글라이드로 개발되었지만 나중에 다이렉트 3D API의 지원을 추가하게 됩니다. 비(非) 부두 계열의 그래픽카드였던 리바 128은 다이렉트 3D를 통해 게임을 완벽하게 실행할 수 있었습니다.


다이렉트 X 6/6.1




1998년 7월에 다이렉트 X 6이 정식으로 발표됩니다. 그 특징은 지오메트리 모델의 버텍스 포멧을 더 유동적으로 할 수 있게 되었고, 지오메트리 모델의 버텍스 버퍼 캐시, 멀티 텍스처 랜더링 지원, 자동 텍스처 관리, depth(깊이) 버퍼의 선택(Z 버퍼와 W 버퍼의 사용), 범프 맵핑(ENV Bump ENVMAP, 당시 매트록스 G400만 지원), 반사광과 수면 특수 효과의 픽셀 랜더링과 맵핑 능력 등이 추가되었습니다. 다이렉트 X 6의 3D 기능은 매우 풍부하였고 하드웨어의 성능이 뒷받침되면서 고해상도 32비트 컬러 효과를 사용할 수 있게 됩니다. 이때부터 다이렉트 X의 기능은 글라이드를 점점 앞서가게 됩니다.


다이렉트 X 7/7.1

1999년 9월, 마이크로소프트는 다이렉트 X 7.0을 출시합니다. 다이렉트 X 7의 제일 큰 특징은 하드웨어 T&L(Transforms & Lighting)을 지원한다는 것입니다.(앞에서 설명했으니 다시 소개하진 않습니다)



다이렉트 X 7의 다른 특징은 입체 표면의 환경 맵핑, 지오메트리 랜더링, 개선된 텍스처 랜더링, 자동 텍스처 좌표 생선, 텍스처 전환, 텍스처 프로젝션과 임의 면적 잘라내기, D3DX 실용 데이터베이스 등입니다.

다이렉트 X 7은 글라이드에게 엄청난 타격을 입히게 됩니다. 이 사태를 벗어나기 위해 3DFX는 글라이드의 코드를 공개하기까지 하지만, 기울어진 상황을 어떻게 하진 못하고 결국 글라이드의 3DFX는 NVIDIA에게 인수되게 됩니다.


다이렉트 X 8/8.1

2000년 9월에는 다이렉트 X 8이 등장합니다. 프로그래밍이 가능한 쉐이더 파이프라인 개념이 GPU에 처음으로 도입됩니다. 이러한 새로운 쉐이더 데이터 처리 방식은 다이렉트 X 8의 제일 중요한 특징으로서, 쉐이더는 새로운 데이터 처리 어플리케이션 모델을 사용, 지금까지와 다른 방식의 모델을 사용하게 됩니다. 이러한 모델은 데이터를 가상 머신을 통해 특별하게 편집된 Pre-Arranged(배열이 완료된) 프로그램을 통해 처리하며, 프로그래머가 이러한 과정을 직접 편집할 수 있습니다.



프로그래밍이 가능한 지오메트리 파이프라인과 픽셀 파이프라인은 지오메트리와 픽셀의 코드 설계를 자유롭게 조절할 수 있게 합니다. 이를 통해 그래픽 개발자들은 지금까지 없었던 방식으로 새로운 효과를 만들어 낼 수 있게 되었습니다. 프로그래밍이 가능한 파이프라인이라는 개념은 GPU의 발전 역사에 새로운 장을 열었으며, GPU도 SIMD 프로세서의 방향으로 발전하고 더 강력한 병행 처리 능력을 보유, 각종 통용 계산에도 사용할 수 있게 됩니다.


다이렉트 X 8.0 아키텍처

다이렉트 X 8의 다른 특징으로는, 편집이 가능한 하드웨어 쉐이더, 통용 텍스처 조합 공식, 픽셀 광원 추적(범프 맵핑), 다양한 샘플링 랜더링, 고성능 파티클 시스템, 3D 공간 텍스처, 다이렉트 3D의 네트워크에 3차원 내용을 삼입할 수 있는 도구, 등이 있습니다. 

2001년 말에는 다이렉트 X 8.1이 나옵니다. 주요 개선점은 픽셀 쉐이더 1.2/1.3/1.4의 추가입니다. 8.1 이전까지는 1년에 한번 꼴로 새 다이렉트 X가 나왔지만 이때부터는 그 속도가 느려지게 됩니다. 그 원인은 다이렉트 X 7 이후로 메이저 릴리즈 버전에 따라 새 GPU가 개발되면서 하드웨어의 갱신 주기가 다이렉트 X에 맞춰졌기 때문입니다. 그리고 게임 개발사들도 갈수록 복잡한 프로그램을 만들게 되면서 개발 기간이 길어지게 된 원인도 있습니다.


다이렉트 X 9.0/9.0b/9.0c



2002년 말에 다이렉트 X 9.0이 등장합니다. 다이렉트 X 9의 쉐이더 정확도는 부동 소수점 정확도 수준에 도달했으며, GPU를 통용 계산에 사용하는 부분에서 큰 발전이 있었습니다. 새로운 버텍스 쉐이더 엔진은 전보다 더욱 복잡해졌지만 더 많은 데이터를 처리할 수 있게 됩니다.



픽셀 쉐이더 2.0은 완벽한 프로그래밍이 가능한 구조를 사용, 텍스처 효과를 즉시 연산하고, 다이나믹 텍스처 맵핑을 지원하며, 비디오 메모리 점유율을 낮췄습니다. 그리고 최대 처리 가능한 명령어와 텍스처 맵의 수가 늘어났습니다. 버텍스 쉐이더 2.0도 버텍스 프로그램의 유연성이 늘어났으며, 순환 조작 명령의 추가, 작동 시간의 감소, 처리 클럭의 증가로 그 효율이 몇배로 늘어났습니다.

다이렉트 X 9의 등장으로 오픈GL API는 그 사용이 현격하게 줄어들었습니다. ID 소프트웨어의 둠과 퀘이크를 비롯, 오픈GL API를 사용하는 게임은 얼마 남지 않았으며, 이렇게 되자 오픈 GL API를 전문 작업용에만 사용하도록 하겠다는 마이크로프트의 계획은 그 목표를 달성하게 됩니다.



다이렉트 X 9는 9.0b와 9.0c도 있지만 지면 관계상 자세한 소개는 하지 않습니다.(...이렇게까지 해놓고 지면 관계상?)


다이렉트 X 10의 특징

다이렉트 X는 수많은 개발자들이 사용하게 되었고, 사용이 간단하고 풍부한 기능을 가지고 있다는 특징도 있습니다만, 피할 수 없는 단점도 있으니 그것은 바로 CPU에 걸리는 부담이 많다는 것입니다.

그래픽 API가 등장하기 전에는 3차원 프로그램이 직접 그래픽 하드웨어에 그래픽 명령을 보내 작업을 완성했습니다. 이 방식은 그 효율이 아주 높지만 프로그램이 각양 각색의 하드웨어마다 다른 명령을 사용해야 하기 때문에 개발이 매우 오려웠으며, 에러나 버그가 쉽게 발생하는 문제도 있었습니다.

그래서 등장하게 된 것이 다이렉트 X나 오픈GL 같은 그래픽 API입니다. 이들은 그래픽 하드웨어와 응용 프로그램의 중간에 위치하여, 프로그램이 통일된 그래픽 프로그래밍 언어를 통해 하드웨어에 맞춰 각종 기능을 사용할 수 있게 합니다. 이로서 게임 개발자들은 대량의 그래픽 하드웨어를 해석할 필요없이, 오직 게임 개발에만 집중할 수 있게 되었습니다.

하지만 이걸로 끝난게 아닙니다. 다이렉트 X가 응용 프로그램에서 명령을 받을 때마다, 먼저 해당 명령어의 분석과 처리 작업을 하고 이를 다시 그래픽 하드웨어에 알맞는 명령으로 보내게 됩니다. 이러한 분석과 처리 과정은 CPU에서 완성하게 되는데, 이는 곧 1줄의 3D 그래픽 명령을 실행할 때마다 CPU가 부담하는 부분이 반드시 존재한다는 것입니다. 이러한 부하는 3D 그래픽에 2가지 제한-화면에 동시에 표시할 수 있는 오브젝트 수량의 제한과 한 장면에 사용되는 독립된 특수 효과의 제한-을 만들어 버립니다.

다이렉트 X 10의 주요 목표는 바로 이 CPU의 부하를 줄이는 것입니다. 다이렉트 X 10은 3가지 방법을 통해 이 목적을 실현하게 되는데, 첫번째는 API 코어의 개선, 오브젝트와 특수 효과를 전환하여 그려내는데 소모되는 양을 줄이는 것이고. 두번째는 새로운 매커니즘을 도입, CPU의 의존성을 낮추고 더 많은 연산을 GPU에서 완성하는 것이며. 세번째는 대량의 오브젝트에 1개의 다이렉트 X 명령어만 사용하는 대량 처리 방식입니다.

1.그림 제작 소모량의 감소

제작 소모량의 감소를 제일 잘 보여주는 예라면 다이렉트 X 10의 3차원 데이터 제작 명령 진행 검증 과정의 수정입니다. 3차원 데이터와 명령의 검증은 다이렉트 X의 그래픽 제작 전에 위치하며, 그래픽 데이터와 제작 명령의 진행 포멧과 데이터를 완벽하게 검사하여 그래픽 하드웨어가 하드웨어적인 문제를 일으키지 않도록 해줍니다. 이는 반드시 필요한 과정임이지만 상당한 수준의 성능을 지출해야만 합니다.

다이렉트 X 9의 데이터 검증 과정	다이렉트 X 10의 데이터 검증 과정
응용 프로그램 시작 데이터 자원 구축 게임 순환(1 프레임의 게임마다 한번씩 실행. 따라서 전체 게임 과정 중에 몇백만번 등장) 데이터 검증 검증 완료된 데이터를 3차원 오브젝트로 제작 모니터에 그래픽을 표시 게임 순환 과정 종료	응용 프로그램 시작 데이터 자원 구축 데이터 검증(한번만 실행) 게임 순환(1 프레임의 게임마다 한번씩 실행. 따라서 전체 게임 과정 중에 몇백만번 등장) 검증 완료된 데이터를 3차원 오브젝트로 제작 모니터에 그래픽을 표시 게임 순환 과정 종료

이상의 표에서 볼 수 있듯이, 다이렉트 X 9는 1 프레임의 화면을 그려낼 때마다 관련 데이터의 검증을 거쳤지만, 다이렉트 X 10에서는 데이터를 만들고 난 후 한번만 검증을 합니다. 따라서 게임의 진행 효율을 대폭 개선되었습니다.


2. CPU 의존성의 저하

CPU에 대한 의존성을 낮추기 위해 다이렉트 X 10에는 3가지 중요한 매카니즘이 도입되었습니다. texture arrays, predicated draw, stream out이 바로 그것입니다.

먼저 텍스처 어레이부터 보도록 하겠습니다. 지금까지의 다이렉트 X는 여러장의 텍스처를 잘라 붙이는 작업을 할 때 상당한 CPU 자원을 사용했습니다. 왜냐하면 이러한 작업 하나 하나가 모두 다이렉트 X의 API 함수이기 때문입니다. 거기에 새로운 텍스처를 사용한 오브젝트의 화면을 그릴때에도 역시 이러한 작업을 해야만 합니다. 어떤 때에는 특수한 재질 효과를 처리하게 위해 하나의 오브젝트에 텍스처를 여러번 잘라 붙여야 하는데 이 경우 CPU 자원 소모량은 더욱 커집니다.

따라서 지금까지 게임 그래픽은 대량의 작은 텍스처를 합쳐서 하나의 큰 텍스처로 만들어서, 3 차원 물체에 이 커다란 텍스처의 다른 부분을 나눠 사용함으로서 텍스처를 잘라 붙이는 작업을 줄여, 게임의 실행 효율을 높였습니다. 하지만 이 방법은 상당히 번거로운 작업일 뿐더러, 다이렉트 X 9의 텍스처 크기에는 4048x4048 제한이 존재합니다.

다이렉트 X 10에는 새로운 텍스처 어레이(배열) 방식을 도입하여, 그래픽카드의 배열 중에 512장의 독립 텍스처를 저장할 수 있고, 쉐이더 프로그램이 새로운 명령을 통해 이 배열 중에 임의의 텍스처를 사용할 수 있습니다. 또한 이 쉐이더 명령어는 GPU에서 실행되는 것이기 때문에, 기존 작업에서 소모되던 CPU의 시간과 자원 부담이 많이 줄어들게 되었습니다. 게다가 텍스처는 일반적으로 비디오 메모리에 직접 저장되기 때문에 GPU에서 직접 비디오 메모리를 엑세스하여 연산하는것이 더욱 효율적입니다.

다음은 predicated draw입니다. 일반적인 3차원 장면을 보면, 많은 오브젝트들이 다른 오브젝트에 의해 완전히 가려져 있습니다. 이때 만약 그래픽카드가 이들 오브젝트를 만들어 낸다면 그것은 곧 낭비입니다. 고급 GPU는 하드웨어 계산을 통해 장면 중에서 가려져 안보이는 픽셀(픽셀입니다 픽셀)들을 미리 예측하여 제거합니다만, 일정 수준의 처리 능력을 소모하는건 여전합니다.

예를 들어, 어떤 복잡한 폴리곤 모델이 다른 오브젝트에 의해 완전히 가려졌다고 가정했을 경우, 이 모델의 몇천개에 달하는 버텍스를 연산하고, 여기에 광원 조작을 계산하기 위해 얼마나 많은 자원을 소모했을지는 설명할 필요조차 없습니다. 하지만 GPU는 이러한 작업이 끝나고 픽셀 하나하나를 화면에서 화면으로 옳길때에야 비로소 이 픽셀들이 화면에 표시되는지 표시가 되지 않는지를 판단, 삭제 여부를 결정합니다. 그러니까 픽셀 이전의 버텍스 처리 작업은 전부 쓸모가 없어진다는 소리지요. 이것을 해결하기 위한 것이 바로 predicated draw입니다.

간단히 말하면 특정 복잡한 오브젝트의 간단한 부분을 통해, 이 오브젝트 전체의 화면 표시 여부를 판별하는것이 바로 이 predicated draw입니다. 예전에는 이러한 작업을 CPU에서 하였지만 다이렉트 X 10에서는 완벽하게 GPU가 담당하게 됩니다.

마지막으로 스트림 아웃이 있습니다만, 이것은 나중에 지오메트리 쉐이더의 스트림 아웃 부분에서 별도로 소개합니다.


3. 대량 처리

다이렉트 X 9에서 랜더링 상태의 관리는 항상 CPU의 조작과 시간을 소모하게 됩니다. 랜더링 상태는 그래픽 카드가 장면을 그려낼때 필요한 설정의 각종 데이터와 참고 수치를 가리킵니다. 어떤 사람을 그려낸다고 가정할 경우, 먼저 지오메트리 모델 데이터 포멧, 텍스처 필터링 포멧, 알바 플랜딩 포멧 등등의 설정 값을 모두 다이렉트 X API에서 대량의 CPU 처리 시간을 이용하여 설정하게 됩니다.

이러한 조작을 대량에 처리하기 위해 다이렉트 X 10에는 2가지 새로운 개념- State Object와 Constant Buffers가 도입되게 됐습니다.

스테이트 오브젝트는 기존의 제로 스테이트의 기능을 몇개로 모은 것으로서, 하나의 스테이트마다 매번 다이렉트 X API를 사용하지 않아도 되게 해주고, 오직 한번 그래픽카드에서 설정 값을 가져가게 합니다.

Constant Buffers는 모델을 그리기 전의 준비 작업에서, 랜더링 상태 설정 값의 아주 작은 부분을 저장합니다. 어떤 인물을 그려낼때 광원의 색, 위치, 유형, 범위 등을 고려해야만 하며 이는 전부 그래픽카드에게 주어집니다. 골격에 피부를 덧씌우고 골격의 위치 데이터 등의 매우 많은 정보, 이러한 것들은 모두 GP의 Constant register를 통해 전달됩니다. 다이렉트 X 9에서 이러한 Constant register의 수량은 상당히 제한되어 있으며, 새로운 레지스터를 만들기 위해서는 다이렉트 X API 함수를 사용해야만 합니다. 다이렉트 X 10에서는 Constant buffer를 사용하며, 모든 constant buffer에는 4096개의 상수를 저장할 수 있고, 이를 한번의 API 작업을 통해 새로운 대량의 상수를 만들어 낼 수 있습니다.


마이크로소프트 다이렉트 X 10 SDK에 포함된 장면으로서, Constant Buffer를 사용해 복사해낸 오브젝트입니다.

지금까지는, 어떤 장면에 많은 나무와 잡초가 등장할 경우, '복사'와 비슷한 방법을 사용했습니다. 먼저 몇개의 나무와 풀이 있는 3차원 모델을 만들고, 이를 한 화면에 넣은 다음, 위치와 방향을 비롯한 일부 변수를 바꿔 이를 다시 집어 넣는 것입니다. 다이렉트 X API를 통해 이러한 모델을 그려내면 수많은 나무와 풀을 그려낼 수 있지만, 장면 한번 한번마다 역시 다이렉트 X API 함수를 사용해야 하기 때문에 CPU의 자원을 사용하게 됩니다.

다이렉트 X 10에서는 기본적인 나무와 풀 등의 몇개 모델을 그래픽카드에게 주고, 모든 화면의 나무의 위치와 방향과 크기 등을 Constant buffer에 기록, 이를 다이렉트 X에게 통지합니다. 이렇게 하면 화면에 나오는 모든 나무와 풀을 한번에 그려낼 수 있게 됩니다.


다이렉트 X 9와 10의 CPU 부하량의 비교

결론: 다이렉트 X 10은 CPU의 부하량을 더 줄이기 위해 위에서 나온 이러저러한 기능/기술들을 추하한 것입니다 -_-a


ATI 3Dc 기능

텍스처 맵핑은 3D 오브젝트의 위에 그림을 붙이는 것으로서, 3D 장면의 지오메트리 모델을 그대로 유지하는 전제 하에, 더 자세한 표현 효과를 얻을 수 있습니다. 텍스처 맵핑은 나무결이나 대리석의 복잡한 도형-사람, 건축물, 나무 등등-에서 사용되며, 가상 현실 환경 중의 장면에서는 반드시 대량의 세밀한 텍스처 맵핑이 실현되기 때문에, 상당한 시스템/비디오 메모리를 사용하게 됩니다. 텍스처 압축은 3D 모델에 텍스처를 붙일때 데이터 압축을 통해, 전송 및 점유하는 메모리 대역폭과 용량을 줄이는 것입니다.


압축된 텍스처

최대 4096x4096 크기의 해상도를 가진 텍스처가 32비트 컬러를 사용한다면, 이 텍스처 파일의 용량은 4096X4096X32=536870912비트, 67108864바이트, 67MB가 됩니다. 이대로라면 256MB의 비디오 메모리에는 4장의 텍스처도 제대로 저장할 수 없기 때문에, 텍스처 압축은 아주 중요합니다. 텍스처 압축의 원리는 맵핑 진행 압축후에 비디오 메모리에 저장하는 것으로, 이 방법을 통해 비디오 메모리 점유 용량을 대폭 줄일 수 있습니다.

텍스처 압축 기술을 제일 먼저 사용한 것은 마이크로소프트의 다이렉트 X가 아닙니다. 이 기술의 근원은 5년 전에(5년 전이라고 해봤자 고작 2002년인데 아래 글과 전혀 맥락이 맞지 않습니다. 뭔가 잘못된듯 합니다) S3가 오픈GL에서 제일 먼저 사용한 S3TC라는 기술입니다. 1999년에 마이크로소프트도 이 방법을 사용, 다이렉트 X에서 텍스처 압축 기술을 쓰게 됩니다. 그 이름하여 DXTC(Direct X Texture Compression).


DXTC

텍스처 압축 기술은 간단해 보이지만 압축 후의 데이터를 비디오 메모리에 저장하는 것으로 끝나지 않습니다.중요한 것은 GPU가 이 압축된 데이터를 가져와서 압축을 풀어 3D 모형에 맵핑할 때입니다. 이 과정은 GPU의 하드웨어적인 지원이 필요하며, 만약 지원하지 않으면 압축된 데이터를 식별하지 못해 텍스처 압축을 완성하지 못하고, 텍스처 압축의 장점을 발휘할 수 없게 됩니다.

텍스처 압축 응용 계산은 하드웨어의 복잡성과 압축 해제 효율, 색체 공간 변환 등의 기술적인 문제와 관련되기 때문에, 단순한 압축 텍스처도 많이 복잡합니다. 위에서 언급한 DXTC를 놓고 보면 DXT1부터 DXT5까지 5가지 다른 계산법이 포함되어 있으며, 이 5가지 계산법은 5가지의 상황에 따라 사용되게 됩니다.

당연히 DXTC 텍스처 압축 기술을 사용하면 성능이 향상되지만, 이러한 압축 기술은 유손실 압축입니다. 즉, 압축-저장-압축 해제의 과정 중에서 반드시 일정 부분의 데이터가 손실된다는 것을 의미하는데, 이러한 손실 정도는 그리 크지 않기 때문에 사람의 눈으로는 손실 정도를 구분하기 어렵습니다. 따라서 DXTC 기술은 광범위한 영역에서 응용할 수 있으며, 지금 대부분의 게임에서 이 기술을 사용하고 있습니다.

기술의 발전에 따라 노말 맵핑 기술이 게임 중의 대표적인 맵핑 방식으로 자리잡았습니다. 이 방식은 작은 폴리곤 다각형들을 아주 정밀하게 표현된 텍스처를 이용하여 표현하는 것입니다. 노말 맵핑의 RGB 채널 중에 노말 벡터 데이터를 저장하기 때문에, 전통적인 압축 계산법으로는 어려움이 있습니다.


노말 맵핑

노말 맵핑은 모든 점의 색을 나타내는 각도- 요철(Bump) 데이터라고 할 수도 있겠는데, 만약 이 데이터를 잃어버린다면 음영 효과가 사라지고, 심지어 맵핑 전체가 틀린 결과를 초래할 수도 있습니다. 따라서 ATI가 3Dc를 연구, 노말 맵핑의 압축 문제를 해결하게 됩니다.


제로보드 본문 글자수 제한에 걸리기 때문에 1부는 여기까지 입니다. 다음 내용은 완성하는대로 올리도록 하겠습니다. 지금까지 나온 내용대로라면 아마 5부까지 가지 않을까 생각됩니다.