3D Card의 발목을 쥐는 대역폭 문제 - 파트 2

 Virtual Texturing이란 무엇인가?

 대역폭 문제를 해결하기 위한 모든 방법들은 결국 이미지 Quality의 손실 혹은 추가적인 비용 부담 문제를 필연적으로 앉게 된다.(하지만 누차 이야기 했듯이 PowerVR 아키텍쳐는 예외다.) 따라서 스무스한 텍스쳐 처리나 대역폭의 문제를 극복하고자 한다면 결국 지능적인 메모리의 관리 같은 고급 기법들이 필요하게 된다.

다시 기본적인 문제로 돌아가서, 우리가 처해 있는 문제들은 무엇인가? 우선 가장 골치 아픈 것이 바로 대역폭의 문제이다. 그 다음은 메모리 용량이 부족하다는 것이다. 물론 우리는 64MB 혹은 128MB의 메모리를 가진 비디오 카드를 가지고 있고, 이것만 가지고 있으면 충분하지 않냐?라고 반문할 것이다. 물론 그것이 지금 당장은 먹혀 들어갈수 있을지 모른다. 그러나 당신이 재 사용하지 않는 최소 512*512*32나 1024*1024*32의 텍스쳐링 엔진을 가지고 있다면 그것은 충분하지 않다.(왜 텍스쳐를 재 사용하지 않아야 하는지는 이미 전문에서 설명을 했다.)

존 카멕은 자신의 플랜 파일에서 이와 같은 문제를 명백하게 이야기 하고 있다. 그것은 대한 증거자료로 아래에 존 카멕 플랜 파일의 일부분을 직접소개하고자 한다.

 만약 당신이 현실세계 전체를 표현할 수 있는 텍스쳐의 양을 가지고 있다면 각각의 프레임을 표현하기 위한 텍스쳐 메모리는 얼마나 있어야 할까?

 이것을 단순히 눈에 보여지는 텍스쳐의 관점에서 본다면 mip mapping은 하나에서 부터 한 규모의 처리된 픽셀 사이에 관련된 텍셀을 유지하게 된다. 만일 다양한 각도의 뷰잉과 고수준 클램핑(clamping)이 고려된다고 한다면, 그 전제적인 양은 대략 안정적으로 잡아도 1/3 수준으로 줄어들 수 있다.

 여섯개의 텍스쳐가 화면 전체에 뿌려진다고 가정한다면 텍셀의 전체양은 적어도 픽셀양의 2배 이상이 필요하게 되는 이치이다. 1024x768 해상도에서 잘 처리된 200백만개의 텍셀이 처리된다고 가정할 때, 최고의 디테일을 고려하지 않은 최악의 경우를 보더라도 텍스쳐를 재 사용하지 않는 가정이 필요하다면 적어도 100백만개 이상의 텍셀이 명백하게 필요하게 된다.

 누군가가 Quake 3를 8MB 혹은 16MB카드로 높은 수준의 텍스쳐링을 이용해서 돌린다고 가정한다면 도저히 돌릴 수가 없다는 것이다. 게임에서 이미 고정되어 되어 버리는 부분과 그것을 돌리는데 있어 가장 기초적인 부분부터 텍스쳐 메모리 부족 현상을 겪게 되는 것이다.

 이 고정된 부분에 필요한 메모리는 대부분 드라이버들이 사용하는 LRU(least recently used - 메모리 캐쉬 알고리즘) 기능 때문에 필요한 것이며, 이것은 메모리카드에 로드된 텍스쳐가 주어진 프레임에 끼워맞추어지기 위한 텍스쳐의 총량을 고려한다면 적절한 것으로 간주 되어야 한다. 하지만 이것으로 끝이 아니다. 사용자는 곧 텍스쳐 메모리 이외의 추가적인 소규모의 메모리가 필요하게 되며 이것은 곧 성능의 저하로 직결된다. 만일 단일 프레임을 랜더링 하기 위해서 14메가의 텍스쳐 메모리가 사용된다고 가정하고 그래픽 카드가 텍스쳐 메모리를 위한 버퍼를 할당하기 위해 단지 12메가의 추가적인 메모리만 가지고 있다고 가정하자. 그렇다면 매 프레임당 버스를 통해서 14메가의 새로운 텍스쳐를 로딩해야 한다. 하지만 이것은 메모리가 2메가 부족하게 되는 결과에 직결된다. 그렇다고 한들 12메가를 먼저 로딩해서 쓰고 나중에 2메가를 로딩하는 단일 유닛 텍스쳐의 특성한 불가능한 일이다. 그렇다면 결국 별도의 방법(가령 AGP 메모리를 사용하는 것 따위)이 강구되어야 하고 그래픽 카드의 성능은 땅바닥으로 곤두박질 치게 되는 것이다.

 또한 가장 기본적인 문제중의 하나는 텍스쳐들이 하나의 완벽한 덩어리로 로딩되어야 한다는 것이다. 그것은 밉맵으로 조작할 수 있는 최소 수준의 텍스쳐부터 2048x2048 크기의 최고 퀼리티 텍스쳐를 모두 포함하고 있다. 겨우 16 pixels로 이루어진 텍스쳐를 볼려고 해도 당신은 12메가 메모리 플랫 전부를 사용해야 한다!

 그렇다고 문제가 여기서 또 끝나느냐? 그것도 아니다. 단순히 텍스쳐의 크기만이 문제가 아닌 것이다. 여기에는 비디오 카드를 위한 드라이버를 만드는 방법 역시 하나의 부담으로 작용할 수 있다.

문제의 해결 : Virtual Texturing

 이제 3Dlabs의 기술 백서를 통해서 VT에 대한 이야기를 좀더 논의해 보자. VT는 쉽게 이야기 하자면 메모리카드나 메인보드의 AGP의 텍스쳐 메모리의 물리적인 주소를 논리적 주소로 매핑하는 것이 그 골자이다. 논리 어드레스의 최대 단위는 256MB의 크기를 가지고 있으며 4KB의 주소 페이지로 관리가 된다. 아래의 그림을 보면 알겠지만 그래픽코어에 의해서 텍셀이 요구될때 VT 엔진은 룩업테이블을 통해서 필요한 텍스쳐가 어느 메모리 영역에 있는지를 찾는다. 만일 텍스쳐가 비디오 카드 메모리상에 없다면 VT 엔진은 DMA 채널을 통해서 AGP 버스를 통해서 메인보드 상의 메모리에서 그러한 텍스쳐를 가져온다. 즉 이 기술의 핵심은 VT 콘트롤러와 DMA를 이용해서 메모리 플랫을 투명하게 논리적 주소로 바라보고자 하는 기술이다. 게임에서는 텍스쳐 메모리가 어디에 있는지 관심을 가질 필요도 없고, 그래서도 않된다. 이렇게 되면 개발자의 입장에서도 더 이상 복잡한 텍스쳐 메모리 관리를 위한 인터페이스의 설계나 드라이버 설계를 고려할 필요도 없다.

 아래의 그림은 VT 엔진이 관여하지 않은 일반적인 아키텍쳐를 설명하는 그림이다. 우선 게임이 OS를 통해서 텍스쳐를 요구하게 되면 AGP 버스를 통해서 시스템 메모리나 그래픽 카드에서 텍스쳐를 가져오는 일반적인 구조를 설명하고 있다. 이 경우는 대부분의 텍스쳐 메모리는 그래픽 카드에서 나오게 된다.

VT 엔진이 없는 일반적인 경우

 다음의 그림은 VT 엔진이 도입 되었을 경우를 설명하고 있다. 즉 다른 부분은 같지만 텍스쳐의 공급은 모두 VT 엔진이 도 맡는다.

VT 엔진이 도입된 경우

 자 이제 VT 엔진에 대한 가능성의 일부를 예상하실 것이다. 일반적으로 대부분의 텍스쳐는 텍셀이 랜더링되기 이전에 모든 텍스쳐들이 메모리에 로드되어야 하는데 반해서 VT 프로세싱은 그 텍스쳐가 필요할 때만 로딩되는 이점도 있다. 이것은 결국 텍스쳐 로딩의 부하를 줄이게 된다. 이 프로세싱의 결과를 아래에서 그래프를 통해서 알아보자.

VT 엔진이 도입된 경우

 위의 표에서 일반적인 엔진과 VT를 쓰는 경우를 비교하고 있는데, 다소 과장이 있을지는 모르겠지만 그 부하의 정도를 비교하기조차 힘들다. 그 만큼 비디오 카드상의 텍스쳐 메모리의 로딩 부하가 작다.

 물론 이것이 과연 진짜 솔류션이 될 수 있느냐는 질문이 있겠지만, 현재로서는 그렇다이다. 엔비디아의 지포스2 카드는 현재 다들 알다시피 막대한 대역폭 문제를 앉고 있다. 퀘이크 3 아레나를 실행할 경우 텍스쳐를 압축하고 지포스 GTS 2 하드웨어를 기준으로 한 막대 그래프가 아래에 예시되어 있다. 이 그래프의 테스트 환경은 Guillemot 3D Prophet GTS 32MB를 사용했고 오버클럭된 P3 600의 720MHZ CPU 클럭을 사용했다.

 HQ는 Q3A(1.17)에서 하이 퀄리티를 의미하며 이것은 텍스쳐 압축이 켜져있고 텍스쳐 퀼리티 슬라이더를 끝까지 밀어올린 상태에서 테스트 된 것이다. 텍스쳐는 32비트 칼러를 사용하고 있고 소스 역시 32비트이다. 지오메트리 디테일은 2/3 수준으로 맞추었다.

 HQU는 텍스쳐 압축을 끄고 32비트 칼러, 32비트 풀 사이즈 텍스쳐를 사용했으며 지오메트리 디테일은 High 상태로 맞춘 것이다. 물론 오버클럭은 안정적으로 동작했음이 확인한 상태에서 테스트 되었다.

Q3A에서의 GTS 하드웨어의 퍼포먼스

 위의 그래프에서도 보듯이 640*480의 해상도는 램의 동작속도와 관련해서 크게 문제가 되지 않고 있다. 모든 셋팅에서 대략 95 - 102FPS 성능을 보여주며 그 차이가 크지 않기 때문이다. GTS의 코어의 클럭은 200/333Mhz에서 부터 최고 210/360Mhz까지 오버된 것이다. 800*600 해상도 역시 640*480 해상도와 크게 다르지 않다. 하지만 해상도가 1024*768이 되기 시작하는 시점에서 문제가 들어나기 시작한다. HQ와 HQU 사이에 성능상의 갭이 확연하게 들어나는 것이다. 이것은 코어의 메모리 클럭을 오버해도 그 차이는 별 다르지 않다. 해상도가 더 커져서 1280까지 올라가게 되면 눈 뜨고 못 볼 일이 벌어지기 시작한다. HQ와 HQU의 차이는 점점더 벌어지는 것이다.

 또 중요한 점 하나는 해상도가 높아질 수록 메모리 클럭에 대한 증가분이 성능 향상과 곧바로 직결되지 않고 그 증가의 추세가 점점 둔화된다는 것이다. 물론 HQU보다는 HQ가 그나마 나은 결과를 보여주고 있는 것은 바로 텍스쳐 압축 때문이라는 것을 눈치 채신 분들도 있으실 것이다.

 우리는 결국 보다 빠른 메모리를 장착하는 것이 도움이 될 지언정 그게 가장 완벽하지 않다라는 결론을 내릴 수 있는 것이다. 여기에서 VT 아키텍쳐는 대역 문제를 효과적으로 줄이면서 보다 높은 프레임 레이트를 유지할 수 있는 열쇠를 쥐고 있다. 해상도가 높아지고 텍스쳐 크기가 커지고, 칼러수가 증가한다는 이야기는 프레임 레이트 관점에서 본다면 거의 사약과 같은 이야기이다.

결론

 이제 우리는 메모리 대역에 대한 해결책의 한 방법에 대한 조심스러운 결론을 내릴 수 있게 되었다. 하지만 전편에서 이야기한 또 다른 한가지 방법, 즉 PowerVR의 아키텍쳐에 대해서는 아직 살펴보지 못했다. 이것은 또 다음 기회에 살펴보고자 한다. 매드삼디 역시 이러한 부분에 대해서 관심을 가지고 지속적으로 3D 관련 신기술을 알리고자 노력하겠다. Kyro와 Neon250 아키텍쳐는 곧 시간을 마련해서 분석해 보는 시간을 가지겠다고 약속 드린다. 현재 들리는 소문에 의하면 Neon250 칩셋은 GTS 2와 충분히 비교될 만한 성능을 지니고 있다고 한다. 하지만 아직은 그 칩셋이 시장에 나오지는 않았다. 현재 Neon250의 큰 약점은 tri-linear 필터링을 지원하면서 충분한 프레임이 나오지 않고 있다는 점이며 S3TC 압축을 지원하지 않는다는 것이다. 현재 이 아키텍쳐로 16비트 칼라의 환경이나 MiniGL을 이용한 벤치마크는 다른 카드와의 비교는 아직 부적절 한 것으로 보인다.

 병목 현상에 대한 또 다른 대안의 한가지는 메모리의 양을 마구잡이로 늘리는 것이다. 사실 메모리의 증가는 우리도 쉽게 관찰할 수 있다. 이미 시장에는 64MB의 상용 PC 그래픽 카드가 범람하고 있다. 이것은 좋은 방법이긴 하다. 큰 텍스쳐와 FSAA 따위의 효과를 위해서라면 마냥 큰 메모리 역시 충분히 좋은 방법이기 때문이다.

 이제 대충 메모리 대역 문제와 관련된 일반적인 물음들에 대한 해답을 살펴보았다. VT를 너무 띄우는 것은 아니지만 역시 이것은 아주 휼륭한 솔류션이다. 이미지 효과를 고려하지 않는다면 VT는 텍스쳐 압축을 이용하는 것에 대해서 좋은 대안이 될 수 있다. TC가 좋은 기술이긴 하지만 Q3A에서 TC 압축을 끌 경우 그것을 켠 상태와의 차이를 대번에 느낄 수 있을 정도로 이미지에 텍스쳐 압축이 주는 부정적 효과는 크다.(이것은 Q3A에서 CFG 파일을 열어 r_compress_textures값을 0 또는 1로 셋팅하므로써 사용자가 직접 설정을 할 수가 있다.) TC는 단순히 축복만은 아니다. 3D 하드웨어 기술에 있어서 다른 여타의 방책들이 그러하듯이...

 하지만 VT 아키텍쳐는 어떤점에 그 끝을 가늠할 수 있는 기술이다. 점점 더 큰 텍스쳐들을 게임이 요구하게 되면 VT 역시 혼자 그것을 감당할 수는 없을 것이다. 보다 더 빠른 메모리가 VT와 결합하게 된다면 그것은 더욱 좋은 솔류션이 될 것이기 때문이다. 곧 Quad Dram 같은 메모리 기술이 등장하면 그것은 일반적인 SDRAM보다 4X 이상의 밴드폭을 보장해 줄 것이다.

 엔비디아에서 대해서 이야기 하자면 그들도 그 문제를 모르고 있을리가 없다. 엔비디아는 어떤식으로 든지 대안을 찾고자 할 것이다. 이제 빠른 메모리만이 만병통치약이 아니란 것도 알았을 것이다. :) 엔비디아가 찾는 새로운 기술에는 VT 아키텍쳐 같은 것도 충분히 의미가 있을 것이기 때문이다.

 존 카멕이 그의 게임 Q3A를 3Dlabs의 VT 아키텍쳐에서 시연한 것에 대해서 아주 긍정적인 평가를 내렸다. 이제는 우리도 실제의 효과에 대한 진짜 데모를 보는 것 많이 남았다. 자 기다려 보자.

- 자료출처 및 참고자료
http://www.beyond3d.com

출처 : MAD3D.NET