차를 적게 다니게 할 것인가, 도로를 넓힐 것인가?

잠시 앞으로 돌아가자. 길의 넓이에 비해 차가 많아서 교통체증이 심각해질 경우 두 가지 다른 방향에서 문제 해결을 위한 접근이 가능하다.

첫 번째 접근 방향은 도로를 운행하는 차의 숫자를 줄이는 것에서 출발한다. 독재국가라면 차량 운행 정지 법령을 만들어 차의 숫자를 줄일 수 있을 것이다. 하지만 이런 방법은 독재국가 같은 비정상적인 체제하에서나 가능한 이야기이지, 정상적인 체제하에서는 꿈도 꾸지 못할 방법이다.
조금 정상적인 방법으로 도로를 운행하는 차의 숫자를 줄이는 방법 중 가장 대표적인 것이 바로 대중교통을 활성화하는 방법이다. 대중교통수단은 자가용에 비해 적은 차량의 수로도 많은 사람을 수송할 수 있기 때문에 효율적으로 차의 숫자를 줄일 수 있다. (하지만... 국내 실정을 보면... 도로를 꽉 채운 나홀로 차량과 텅텅 빈 시내버스의 오묘한 조화가 거의 매일같이... -_-)
이러한 접근 방법은 큰 비용을 들이지 않고 문제를 해결할 수 있다는 장점은 있지만 효율적인 차량 운행 억제 대책이 없는 한 큰 효과를 기대할 수 없다는 단점이 있다.

두 번째 접근 방향은 도로를 넓히는 것에서 출발한다. 도로를 확장하고, 새로운 도로를 건설하는 방법은 가장 확실한 대책일 것이다. (차량의 숫자가 일정 수준에 도달할 때 까지는...)
하지만 도로를 넓히는 것은 심각한 문제가 있는데, 바로 건설 비용이 상당히 높다는 것이다. 비싼 토지 매입 비용, 도로 설계 및 건설비용은 상상을 초월하는 금액을 요구한다는 단점이 있다.

AGP 버스 문제로 돌아가서, AGP 버스의 대역폭 부족--AGP 버스가 제공하는 최대 대역폭에 비해 전송해야 할 데이터의 양이 더 큰 문제--을 해결하는 방법은 앞의 도로 문제와 마찬가지로 두 방향에서 접근을 할 수 있다. 전송해야 할 데이터를 줄이는 접근 방법이 한가지이고, AGP 버스의 대역폭을 늘리는 것이 다른 한가지다. 두 접근 방법은 서로 다른 장단점이 존재한다.

먼저 전송해야 할 데이터의 양을 줄이는 방법을 보도록 하자. 이 아이디어는 이미 상용화가 된 방법이다. 이제는 추억의 이름이 된 S3의 Savage 칩에서 사용된 S3TC(S3 Texture Compression)가 이 아이디어를 적극적으로 활용한 기술이다.

AGP 버스를 통해 호스트(일반적인 PC에서는 CPU와 메모리, 그리고 메인보드의 칩셋이 된다)에서 AGP 버스상의 그래픽 카드로 데이터를 전송할 때, 데이터를 압축해서 전송하면 데이터의 크기가 작아지고, 동일한 버스의 대역폭에서도 압축을 하지 않았을 때에 비해 더 많은 양의 데이터를 전송할 수 있다는 아주 단순하면서 상식적인 아이디어에서 출발하는 이 방식은 AGP 버스의 구조를 변경하지 않고도 AGP 버스의 대역폭을 향상시킬 수 있다는 장점이 있다.

하지만 이 방식은 치명적인 문제를 안고 있는데, 바로 '압축(Compression)'이라는 과정을 호스트(PC라면 CPU)에서, '압축 해제(Decompression)'라는 과정을 그래픽 카드의 칩셋(GPU)에서 수행해야 한다는 점이다. 일반적인 압축 알고리즘은 압축의 효율성과 계산 시간간에 기하급수적 관계를 가지고 있다. 압축도를 높이기 위해서 필요한 계산 시간의 증가는 압축도의 향상을 언제나 넘어서는 수준이다.

거기에 CPU는 다른 연산 작업으로도 쉴 틍미 없다는 문제가 있다. 대부분의 3D 어플리케이션은 일반적으로 수행중에 CPU를 100% 활용하는 특징이 있다. 3D 오버젝트들의 움직임을 연산하는 것은 매우 복잡한 과정으로, AGP 버스를 통해 그래픽 카드로 전송될 데이터를 압축하는 일을 CPU가 담당한다는 것은 그만큼의 시간동안 3D 오버젝트의 움직임을 연산할 수 없다는 것을 의미한다. 그만큼 3D 오버젝트의 움직임이 멈추던지, 아니면 압축에 의해 잃어 버린 시간에 의한 멈춤을 막기 위해 3D 오버젝트의 움직임을 정밀하지 못하게 연산해야 한다. 이는 물체의 이동이 중간중간 멈추거나 물체의 움직임이 부자연스러운 등의 부작용을 발생시킨다.

CPU의 발달에 의해 이런 문제는 사라질 것으로 예상되지만, CPU의 발달보다 더 빠른 3D 어플리케이션의 필요 연산 처리량을 생각한다면 영원히 해결되지 않을 문제라고 할 수 있다.

버스의 대역폭을 확장하는 방법은 일단 문제의 근본에 근접하는 해결 방법이다. 하지만 이 방법도 상당한 문제점을 안고 있다. 대역폭을 확장한다는 것은 다음 두가지 방법 중 한가지 이상을 사용한다는 것을 의미한다.

     1. Data 버스의 폭을 확장한다.
     2. 버스의 동작 속도를 끌어올린다.

두가지 방식 모두 문제가 있다. 먼저 데이터 버스의 폭을 확장한다는 것은 버스의 아키텍쳐 자체를 바꾼다는 것을 의미한다. 만약 기존 버스의 아키텍쳐 설계가 잘 되어 있고, 확장된 버스의 설계를 잘 한다면 하위호환성을 유지할 수 있지만 대부분의 경우 하위호환성을 유지하기 매우 어려운 문제가 있다. 하위호환성을 위해 신 규격의 버스가 성능이 떨어지거나 새로 설계한 버스를 실제 시장에 적용할 때 가격이 급격하게 상승하는 문제가 발생할 가능성이 높다. (가장 대표적인 예가 USB 2.0인데, 하위 규격인 USB 1.1과의 호환성 유지를 하려니 설계가 너무 복잡해져서 이 문제를 해결하기 위해 업체간에 상당히 많은 마찰이 있었다고 한다.)

버스의 동작 속도를 끌어올리는 방법은 버스의 폭을 확장하는 것에 비해서는 상대적으로 쉬운 방법이다. 하지만 이 방법도 한계가 있는데, 주파수가 높아지면 높아질수록 데이터의 안정성이 낮아진다는 것이다. 즉, 안정성을 해치지 않는 한도 내에서 데이터의 전송 속도를 끌어올릴 수 있다는 것을 의미한다. 만약 이 한도보다 더 높은 전송 속도를 요구한다면 추가적인 안전 장치를 요구하게 되며, 이는 비용 증가와 함께 경우에 따라서는 하위 호환성을 포기해야 하는 문제를 야기하기도 한다.