※ 본 아티클은 CMP MEDIA LLC와의 라이선스 계약에 의해 국문으로 제공됩니다.
멀티쓰레드 게임 엔진 아키텍처
멀티코어 프로세서가 피씨용으로 사용된 지 일년을 훌쩍 넘긴 데다 엑스박스360은 이미 수 백만 달러가 판매되었음에도 멀티코어 플랫폼용의 게임엔진 개발에 관한 지식과 개발은 여전히 부족한 실정이다. 이 글에서는 아키텍처 수준에서 게임엔진의 병렬성에 대한 관점을 제공하고자 한다. 갭 앤 레이크[1]가 보여준 바와 같이 각각의 구성요소 수준에 있는 멀티쓰레딩을 살펴보는 것보다 전체 게임루프에 병렬성을 추가하는 것이 더 나을 것 같다. 이제 살펴볼 상이한 세 종류의 모델은 기본 게임루프에 사용되는 쓰레드 지원형 아키텍처 모델로써 이들을 확장성, 예상 성능 같은 특성에 비교할 것이다. 주로 두 가지 방식으로 프로그램을 동시적 발생 부분으로 분해할 수 있다. 그 두 방식이란 함수 병렬성, 즉 프로그램을 동시적 발생 작업으로 나누는 방식과 데이터 병렬성, 즉 병렬로 동일 작업들을 수행할 수 있는 데이터 세트를 찾으려는 방식이다. 비교되는 세 모델 가운데 두 가지는 함수 병렬적이고 한 가지는 데이터 병렬적이다. 동기적 함수 병렬 모델 게임루프에 병렬성을 포함시키는 한 가지 방법은 기존 루프에서 병렬 작업들을 찾는 것이다. 병렬 작업들 간의 통신 필요성을 최소화하기 위해 이 작업들은 서로 독립적인 것이 더 낫다. 이런 예는 애니메이션을 계산하면서 물리작업을 수행하는 것이다. 그림1은 이 기법을 이용해 병렬화 한 게임루프를 나타낸다. 코스타[2]가 제시한 방법은 이런 종류의 아키텍처 확장을 자동화하는 것이다. 말하자면 기능성을 작은 작업들로 나누고 종전의 작업(그림 1의 그래프 같은)들로 이뤄진 그래프를 구축한 후 하나의 프레임워크에 이러한 작업 종속형 그래프를 적용한다. 프레임워크는 돌아갈 적절한 작업들의 스케줄을 짜면서 사용 가능한 프로세서 코어의 양을 고려한다. 그러한 프레임워크를 사용하는 대신 당신이 지원하기로 계획한 각 코어의 양에 맞는 당신의 코드를 재 작성할 수 있다. 두 가지의 함수 병렬 모델에 주로 관심이 가는 부분은 이 두 모델의 지원 가능한 코어의 수에 상한이 있다는 점이다. 이것은 엔진에서 찾을 가능성이 있는 병렬작업이 얼마인지에 대한 한도이다. 의미 있는 작업의 수는 지극히 적은 작업을 쓰레드하면 부정적 결과를 나올 수 있다는 사실로 인해 감소한다. 동기화 함수 병렬 모델에는 또 하나의 한계가 있다. 병렬 작업들은 서로에 대한 의존성이 거의 없어야 한다는 점이다. 예를 들어 만약 렌더링이 물리작업의 물체좌표계를 필요로 한다면 렌더링 작업과 병렬로 물리작업을 실행시키는 것은 현명하지 않다.........................(중략)
* 자세한 내용은 첨부문서(pdf)를 참고하시기 바랍니다.
|