테셀레이션 테크 데모

 테셀레이션은 하드웨어 레벨에서 로우폴과 하이폴 간의 전환을 Linear하게 해주는 기술이다. 퍼포먼스를 위해 시야가 넓거나 캐릭터들이 작게 보일 땐 로우폴을, 확대될 땐 하이폴을 쓰는 것은 고전적인 기법이라 할 수 있다. 가장 쉬운 예인 전략 시뮬레이션을 예로 들자. 슈프림 커맨더는 유닛 하나로 화면을 꽉 채울 정도부터, 유닛이 점으로밖에 안 보일 정도까지 축소/확대가 가능하다. 이 경우 과연 하이폴/로우폴의 경계를 어느 정도로 잡을 것인지, 또 하이폴은 어느 정도 수준까지 잡을 것인지와 같은 부분이 개발자들에게 문제가 된다. 하이폴/로우폴 전환은 수동적으로 이루어지고 그 전환의 유연성도 고려해야 하기 때문에, 실제로 보통 게임에서 하이폴/로우폴 단계는 3,4단계를 넘지 않는다. 유닛 1개로 화면을 채울 때와, 20개로 화면을 채울 때 모델의 디테일은 별로 차이가 없다. 실제로는 유닛 1개를 표시하는 쪽이 훨씬 더 자원상의 여유가 있음에도 말이다. 개발자들은 결국 유저들이 가장 빈번하게 사용할 시야범위를 기준으로 폴리곤 량을 계산해 설정할 수밖에 없었다.

 테셀레이션, 정확히는 하드웨어 가속 테셀레이션은 이러한 과정을 DirectX와 드라이버, 하드웨어 레벨에서 자동적으로 처리해주는 기술이다. 개발자가 한 화면에 적정한 수준의 부하량을 결정하면, 게임과 하드웨어는 자동적으로 그에 알맞은 최적의 폴리곤 수를 판단해 하이폴/로우폴을 전환해준다. 이럼으로써 극한으로 들이밀었을 때는 CG 수준의 디테일을 구현하면서도 넓은 장면을 볼 때도 퍼포먼스 저하를 방지할 수 있다. 테셀레이션 자체도 프로세싱파워를 요구하고 리소스를 잡아먹는다는 것은 분명한 사실이다. 그러나 보통 게임을 만들 때 개발자들은 연산량이 너무 많아지지 않도록 일부러 억제하는 경향이 있으며, 이로인해 하드웨어는 다소 놀고있는 경우도 생기게 된다. 테셀레이션 기술은 시점과 표시범위가 고정된 게임에서는 그다지 메리트가 없다고 할 수 있다. 하드웨어 성능 자체를 향상시키는 기술도 아니다. 앞서 말했듯, 전에 쓰지 않던 리소스를 추가로 소모하게 된다. 하지만 그 댓가로 하드웨어가 거의 언제나 100% 효율을 발휘할 수 있도록 만들어주며, 등가교환상 매력적인 거래이다.

 ATi는 8500에서 테셀레이션의 원시적인 형태로 TruForm이란 기술을 선보인 적이 있으며, XBOX360의 Xenos에서 테셀레이션 시험적으로 탑재햐였다. 이후 R600(HD2900, 3800)에도 테셀레이션이 포함되었으며, 테셀레이션 기술 자체는 DX11 이전 모델인 HD 4800 시리즈에도 포함되어 있다. 다만 이것은 DX 레벨에서 구현된 것은 아니며, ATi의 전용 명령어를 사용해야 적용 가능하기 때문에 그동안 실제로 사용된 예는 없다. 마이크로소프트는 ATi의 테셀레이션 연구를 높이 평가하여, ATi의 것을 기반으로 하는 테셀레이션 기술을 DX11에 도입하였다. ATi가 마이크로소프트의 가이드라인을 충실히 따르고 우호적인 협력관계를 꾸준히 유지한 성과라 할 수 있다. 엔비디아가 DX10.1 무용론을 주장하면서 MS의 심기를 건드린데 반해, ATi는 XBOX360용 GPU Xenos의 개발부터 시작하여 MS의 방향성을 적극적으로 지지하고 있기 때문이다.(물론 리눅스 플랫폼에 대해서는 너무 무심하다는 소리를 듣기도 하지만...) 때문에 Fermi(혹은 GF100, GT300)이 거대한 다이 크기에 비해서 DX11 퍼포먼스 효율이 좋지 않더라도 그건 별로 놀랄만한 일은 아닐 것이다. 테셀레이션에 관해 축적된 기술과 노하우에서 분명한 차이가 있기 때문이다.