[테크노아] - Digital Community Techno@

3차원 그래픽 게임 성능 측정 부분은 다른 측정 항목에 비하여 민감하고 주위의 영향을 많이 받게 되며, 최초의 측정 결과와 이어서 실시되는 측정의 결과가 현저하게 달라진다. 1∼3회의 측정 결과가 일치하게 되면 그 데이터를 그대로 사용할 수 있으며 만약, 데이터가 계속 변화되는 경우에는 측정되는 결과가 특정 값으로 근접되는 경우의 값이 정상적인 값이 될 수 있다.

게임 프로그램은 필요에 따라서 지원되는 기능과 지원되지 않는 기능을 구분하여 최적의 조건을 찾도록 되어 있다. 또한, 3차원 그래픽 기능 중에서 게임의 진행을 위해서 필요한 가장 기본적이고 필수 기능만을 이용하여 동작하며, 비슷한 기능을 지원하는 2가지 이상의 함수에 대해서는 가장 많이 지원되고 최적의 성능을 얻을 수 있는 기능을 따르게 된다.


	API	Mapping	Filtering	Polygon	Special Effect	Advantage	Disadvantage
Forsaken98	DirectX	Blending	Bi-linear	3∼5K		Quick test	High derviation between test
Incoming	DirectX	Blending	Tri-linear	3∼5K		Quick test
Trurok II	DirectX	Blending	Bi/Tri-linear	4∼8K		Various functions	Too high CPU dependency
Decent III	DirectX	Blending	Bi/Tri-linear	4∼8K		Various functions	User specific demo required
Expandable	DirectX	Dual	Tri-linear	4∼8K	Bump mapping	Various functions
Unreal	DirectX Glide OpenGL MCD	Dual	Tri-linear	4∼8K		Various API	User specific demo required
Quake II	Glide OpenGL MCD	Dual	Bi-linear	4∼8K		Quick test S3 special mode
Quake III	OpenGL ICD	Dual	Bi/Tri-linear	6∼12K	H/W T&L	Various functions	Incomplete OpenGL ICD
DMZG	OpenGL ICD	Dual	Tri-linear	10∼30K	H/W T&L	High polygon count	GeForce256 optimized Too high CPU dependency
3차원 그래픽 게임의 경우에 프로그램 버전에 따라서 성능이 달라지게 되며, 게임에서의 각종 기능 설정 항목에 따라서도 차이가 있으므로 이에 따른 설정 결과를 반드시 기재해야 한다.

측정 결과의 정리는 해상도/컬러모드 별로 얻어지며, Vsync 설정 상태에 따라서 다르게 기록한다. Quake III와 같이 별도의 기능 설정이 다른 경우나 Unreal과 같이 여러 종류의 API를 지원하는 경우에는 API의 종류에 따라서 측정 시트에 결과를 정리하여 기록한다.

게임을 시작한 후, 게임 화면에서 게임 데모를 실행시킨다. 데모가 끝나면 다시 게임 메뉴 화면이 나타나며, 데모를 다시 선택하면 이전에 실행했던 데모의 프레임 속도가 기록되어 있다. 이것을 기록하면 된다. 단순 이중 필터링 모드를 사용하며, 단순한 알파 블렌딩 모드를 사용하기 때문에 일반 게임들에 비하여 그래픽 보드의 의존도가 무척 높다. 반면에 그래픽 보드의 성능이 높아지게 되면 정확한 그래픽 보드의 성능에 대한 선형 비례 관계를 얻지 못한다.

(1) 특정 게임 해상도에서 데모를 실행하고 다시 다음에 측정할 해상도로 변환한 후에 데모 화면으로 들어가서 이전에 실행한 기록을 다른 곳에 메모를 하고 데모를 계속 진행하면 메뉴 선택 횟수를 최소화하고 빠르게 측정할 수 있다.

(2) 데모는 1회 측정 시에 5분이 소요가 되며, 게임 데모 속도를 100∼500% 까지 변경이 가능하며, 기본적으로 기본 100% 상태에서 측정을 권장한다.

(3) DirectX에서 지원하는 16/32비트 컬러 모드의 모든 해상도를 선택할 수 있다.

데모 프로그램의 경우에 별도의 벤치마크 프로그램을 제공한다. 정품 프로그램에서는 별도의 벤치 마크 프로그램이 제공되지 않으므로 반드시 데모 프로그램을 설치하여야 한다. 각종 알파 블렌딩과 텍스쳐 모듈레이션을 사용하기 때문에 텍스쳐 관련 기능을 측정하기에 적합하다. 단점은 최대로 지원가능한 해상도가 1024x768 이기 때문에 최근에 출시되고 있는 고성능 그래픽 보드에는 적합하지 못하다. 일반적으로 저가의 저렴한 그래픽 보드의 성능 평가에 이용된다.

(1) 벤치 마크 프로그램에 -screenmode 옵션을 추가해 두면 프로그램 실행시 화면 해상도와 컬러 모드를 선택할 수 있다.

(2) 게임의 실행 속도가 수직 주파수의 1/2로 제한이 되기 때문에 반드시 Vsync 옵션은 disabled로 설정해야 한다.

프로그램을 실행할 때, 뒷부분에 -benchmark 옵션을 붙여서 실행하면 Turok Mark가 측정되어지며, 실시간으로 화면에 최대/최소/평균 프레임 속도가 표시되어 진다.

(1) 이전에 게임에서 설정한 옵션과 해상도에 따라서 벤치마크가 실행되며, 옵션을 추가한 벤치마크용 단축 아이콘과 일반 아이콘을 만들어 놓고 번갈아 가면서 해상도를 조절하면서 측정해야 한다.

(2) 3Dfx 그래픽 카드는 기본적으로 Glide API가 선택되며 해상도의 선택이 자유롭지 못하게 된다. 이때는 Turok 게임이 설치된 목록에서 Glide 드라이버를 제거하면 DirectX 모드가 선택된다.

(3) CPU의 의존도가 높기 때문에 높은 시스템 성능에서 성능을 평가해야 높은 그래픽 보드 의존도를 갖는 측정 결과를 얻을 수 있다.

프로그램을 실행할 때, 뒷부분에 -timedemo 옵션을 붙여서 실행하면 벤치 마크가 실행되고 최종적으로 프레임 결과가 윈도우 창으로 출력된다.

(2) CPU의 의존도가 높기 때문에 높은 시스템 성능에서 성능을 평가해야 높은 그래픽 보드 의존도를 갖는 측정 결과를 얻을 수 있다.

(3) 프로그램 설치 목록에 있는 프로그램 설치 정보 파일을 백업하고 이것을 수정하면, 별도의 프로그램에서의 설정이 없이도 간편에 설정 내용을 변환할 수 있다.

(4) Environment Bump Mapping을 지원하는 최초의 프로그램으로 실제 벤치에서는 본 기능을 Off로 측정해야 하며, 이외에 S3TC 모드의 지원 여부고 결정해야 한다.

빠르게 측정하여 결과를 얻을 수 있고 창/전체화면 모드 및 다양한 해상도의 지원이 가능하다. 하지만, 메모리 용량에 따라서 측정 결과가 너무 크게 변하기 때문에 최소한 3회의 연속 측정결과를 얻어서 평균 처리가 필요하다.

(1) 게임 실행시에 "~" 키를 누르면 명령어 입력 창이 나타난다.

(3) demomap demo1.dm2 명령어를 실행한다. 이때, demo1.dm2 이외에 demo2.dm2 명령어를 기본적으로 제공되며 다른 명령어 슈트를 실행한다. 사용자가 특별히 고안된 massive, crusher demo가 있다.

(5) 해상도 변경을 위해서는 아무 화면에서나 [ESC] 키를 누르면 시스템 메뉴가 나타난다. 이 화면에서 VIDEO 항목을 선택하고 이곳에서 게임 화면 해상도/출력 모드 그리고 세부 기능을 세부적으로 조절할 수 있다.

OpenGL ICD에 가장 근접해 있고 간단한 측정이 가능하다. 다양한 해상도를 프로그램 내에서 변경 시켜가면서 지원이 가능하다. 그래픽 시스템의 세부적인 설정이 가능하기 때문에 다양한 그래픽 보드의 성능을 평가할 수 있다. 반면에 측정 방법이 다소 복잡하고 정확한 이해가 필요하다.

측정 방법은 Quake II의 경우와 비슷하다. 게임 실행시에 "~" 키를 누르면 명령어 입력 창이 나타난다.

(2) demo demo001.dm3 명령어를 실행한다. demo001.dm3 이외에 demo002.dm3를 기본으로 제공한다.

(4) 해상도 변경을 위해서는 아무 화면에서나 [ESC] 키를 누르면 시스템 메뉴가 나타난다. 이 화면에서 SETUP->SYSTEM->GRAPHIC 항목을 선택하고 이곳에서 게임 화면 해상도/출력 모드 그리고 세부 기능을 세부적으로 조절할 수 있다.

DMZG 프로그램을 설치하고 나면, DMZG 데모 프로그램과 벤치 마크 아이콘이 생성되며, 벤치 프로그램을 설치하고 나면 측정된 결과가 fps.txt 파일로 저장된다. 이곳엣 평균/최대/최소 프레임 속도가 기록된다. 해상도나 기능을 별도로 조절할 수 없으며, GeForce256 그래픽 카드에 최적화되어 있기 때문에 일반 그래픽 카드에서는 성능이 정상적으로 얻어질 수 없으며 실행 자체가 불가능한 경우가 발생할 수 있다.

성능을 측정하기 위해서는 재현성을 확보해야 하고 이를 위해서는 표준화된 소프트웨어/하드웨어 환경이 필요하다. 기본적으로 운용 시스템은 Clean Booting을 원칙으로 하고 자동 실행 프로그램이나 램상주 프로그램은 모두 제거해야 한다. 더불어 측정 하드웨어의 변화시에 시스템을 재현성을 갖도록 초기화해야 한다. 이를 위해서 Norton Ghost 등의 프로그램을 이용하는 경우가 있다.

* 성능 측정 이전에 범용화된 시스템 정보 확인 프로그램을 이용하여, 시스템에 설치된 모든 소프트웨어/하드웨어에 대한 기본 정보를 확보하여, 벤치 결과와 함께 제시해야 한다. 단, 테스트를 의뢰한 업체/개인의 요청시에 별도로 제공한다. 더불어 제시된 시스템 환경과 상이한 시스템에서의 동일한 결과는 보장할 수 없으며, 동일 시스템에서 1% 이내의 측정 오차를 보장할 수 있다.

벤치마크 테스트 전에 표준화된 각종 시스템 정보 프로그램을 이용하여 프로세서의 정상적인 동작 온도/클럭/전압을 확인해야 한다. 이때, 프로세서의 속도는 범용화된 유틸리티를 통해서 얻은 결과들을 모두 제시한다. 실제 측정 결과는 모두 다르기 때문이다.

메모리 용량과 그래픽 보드의 성능은 무척 관계가 깊다. 그래픽 처리 작업에서는 상대적으로 무척 많은 메모리 용량을 사용하기 때문이다. 따라서 성능 측정을 위해서는 반드시 128MB 이상의 시스템 메모리를 확보해야 한다. 이 메모리 용량이 일반 컴퓨터 사용자들의 용량에 비하여 많은 경우라 하더라도 이하의 메모리를 가지는 경우에는 시스템 버스와 하드 드라이브의 의존성이 높아지게 되며, 시스템 메모리의 운용 조건이 불완전해지기 때문에 상당한 성능의 차이를 보일 수 있다. 즉, 시스템에 대한 전체 의존도를 낮추고 그래픽 카드의 순수한 성능에 대한 의존도를 높이기 위해서는 128MB 이상의 시스템 메모리가 필수적으로 필요하며, 일반적으로 256MB 메모리를 권장한다.

그래픽 벤치마크 프로그램이 각 Scene를 처리할 때, 하드 드라이브의 버퍼에서 시스템으로 전달되는 중간 타이밍과 IRQ Release 타이밍의 차이로 인하여 초기 프로그램 구동 시간에 차이를 발생시킨다. 이 지연 시간은 하드 드라이브의 종류와 버퍼 그리고 IDE 규격과 시스템 메모리 등에 의해서 복합적으로 차이를 발생시키게 된다. 메모리의 용량이 증가될수록 상대적인 차이점을 막을 수 있지만 궁극적인 해결책은 없다. 단지, 2회 이상 벤치마크를 실행하고 대용량 메모리를 설치하여 메모리로 캐쉬율을 높이는 방법이 최선의 방책이다.

게임 프로그램에서는 사운드 처리를 위해서 10% 수준의 CPU 리소스를 사용하게 된다. 특히, 3차원 사운드를 소프트웨어로 지원하는 경우나 MP3와 같은 오디오 압축 코덱을 사용하는 경우에 심하게 나타난다. 시스템의 성능을 측정하는 과정이 아니라면 사운드의 드라이버는 시스템에서 완전히 제거하여 DirectSound 드라이버에서 사운드 카드를 인식하지 않도록 설정해야 한다. 소프트웨어 3차원 코덱을 사용하는 게임에서는 사운드 카드의 버퍼링 규격과 사운드 지원 방식 그리고 체널에 따라서 현저한 성능의 변화를 보이기 때문이다.

네트워크는 시스템의 동작 중에 비규칙적으로 인터럽트를 발생시킬 수 있다. 윈도우즈 시스템이 네트웍을 기반으로 하고 있기 때문이다. 따라서 네트워크는 반드시 제거해야할 항목이다. 네트워크 카드와 드라이버의 종류에 따라서 인터럽트의 규칙성과 지연 타이밍에 차이가 있다.

모뎀은 전화 접속 네트워크 드라이버를 이용하여 일반 네트워크 카드와 동일하게 동작한다.

측정 항목과 프로그램에 따라서 다소간에 차이가 있지만 다음의 측정 원칙에 따라서 측정/수집한다.

- 최초의 3회 측정 결과가 10% 이상이 오차를 갖는다면, 벤치마크의 결과를 신뢰할 수 없다.

- 최초의 3회 측정 결과가 1% 이내의 오차를 갖는다면, 3회의 평균값을 이용한다.

- 이외의 경우는 최대/소 값을 제외한 3개의 데이터를 평균한다.

[단, 측정 결과의 차이가 10% 이상인 경우에 결과를 무시한다.]

- Batch 반복시 중간에 배치 항목의 개수/순서/사양의 변화가 없어야 한다.

- 원칙적으로 Auto Scrip을 이용하여 측정된 결과는 신용할 수 없다.

* 직/간접적으로 Auto Scrip 프로그램은 시스템 리소스의 사용량에 영향을 주게 된다.

측정 항목에 따라서 다소간에 차이가 있지만 다음의 측정 원칙에 따라서 측정/수집한다.

- 각종 벤치마크 프로그램에서 생성되는 결과 파일을 그대로 제공한다.

* 내용과 결과 파일의 생성/수정 날짜가 편집되어서는 안된다.

* 측정 원시 파일은 관련 업체/개인의 요청시 해당 내용만을 제공한다.

* 결과 파일이 없는 테스트는 Excel을 이용하여 테이블로 정리한다.

- 그래프로 표현이 가능하나, 공식적인 데이터는 반드시 숫자와 단위를 명시해야 한다.

* 원칙적으로 측정에 사용된 모든 제품에 대하여 한번에 평가가 이루어져야 하며,

* 결과 정리 파일에는 정리자의 개인 코드가 반드시 기재되어야 한다.

* 결과 파일의 최초 생성일과 수정일, 사유에 명기되어야 한다.