"프랩스(Fraps)로 측정한 프레임은 정확하지 않다" 라고 하면 놀라는 사람들이 있을 것입니다. 프랩스는 PC의 3D 그래픽에서 프레임 속도를 측정하는 툴로, 사실상 표준 툴의 하나이기 때문입니다. 여러 벤치마크 사이트에서 자주 사용하는 툴이며, 이 프랩스가 정확하지 않다면 업계 전체에 충격을 주는 일이겠습니다.

 

 

프랩스를 이용한 프레임 속도 측정. PC 게임의 성능 테스트에선 낯익은 광경이라 말할 수 있겠습니다.

 

그런데 프랩스로 측정한 프레임이 잘못됐다는 말을 누가 했냐 하면, PC의 GPU를 제조하는 두 회사 중 하나인 NVIDIA입니다. NVIDIA는 프랩스로 측정한 데이터를 100% 믿을 수 없다고 주장하며, 새로운 프레임 측정 툴인 Frame Capture Analysis Tool, 줄여서 FCAT을 직접 개발하고, 실제로 드라이버 업데이트와 신제품을 발표할 때 성능 향상률을 표시할 때 이 프로그램을 사용하고 있습니다.

 

이것은 완전히 NVIDIA의 사내 유틸리티이며, 이것을 이것을 일반 사용자에게 공개하거나 판매할 계획은 없습니다. 그런데 이걸 입수해서 4Gamer에서 테스트했네요.

 

 

프랩스는 어떻게 프레임 속도를 측정하는가? 그리고 그 함정

 

 

프랩스의 메뉴

 

프랩스는 오스트레일리아의 Beepa에서 개발한 쉐어웨어로, 프레임 측정과 스크린샷, 동영상 촬영 기능도 있습니다. 이건 다들 알고 계시겠지요. 하지만 프랩스가 어떻게 프레임을 측정하는가. 라고 말하면 이를 설명할 수 있는 사람은 그리 많지 않을 것입니다.

 

Beepa는 프랩스의 소스 코드를 공개하지 않았지만 다이렉트 X API의 일부를 가로채는-후킹- 방법을 쓸 것이라는 짐작이 가능합니다. 이유는 간단합니다. 소프트웨어적으로 프레임을 측정할 방법이 이것 외엔 없기 때문입니다. 프랩스 외의 프레임 측정 툴은 다이렉트 X를 통해 출력되는 화면에 임의의 문자를 오버레이시켜 API를 가로채는 방법을 쓰며, 프랩스도 이럴 것으로 보입니다.

 

이 방법을 쓰는 대표적인 것이 EndScene나 Present 메소드를 후킹하는 것입니다.

 

좀 더 알기 쉽게 설명하죠. 다이렉트 X를 사용하는 프로그램, 예를 들어 게임 엔진은-

 

1. BeginScene 메소드를 호출해 렌더링을 시작하며

2. 다이렉트 X API를 사용해 1 프레임의 렌더링 처리를 하고

3. EndScene 메소드를 호출해 렌더링 처리 종료를 다이렉트 X에 알려주며

4. Present 메소드를 호출하여 프레임 버퍼에 1프레임의 렌더링 씬을 보내는

 

-식으로 1프레임을 그려냅니다.

 

여기서 Scene(신)이라는 말이 나오는데 이것은 3D 업계의 전문 용어입니다. 다이렉트 X에서는 "BeginScene을 호출하고 EndScene을 호출할 때까지 게임 엔진이 렌더링 처리를 실행해 그려내는 이미지"를 Scene이라고 부릅니다. 쉽게 말해서 "1프레임에 해당하는 렌더링 내용"이 곧 Scene이라고 할 수 있습니다.

 

BeginScene~EndScene 사이에 렌더링 되는 이미지는 디스플레이에 표시되지 않고 '오프라인 버퍼'에 저장됩니다. 그리고 게임 엔진이 Present 메소드를 호출하면 오프라인 버퍼에 저장했던 데이터를 실제로 화면을 표시하는 프레임 버퍼로 다이렉트 X가 전송하는 구조입니다. "화면을 그려내는 과정"을 사용자에게 보여주지 않기 위해, 이미 그려낸 완전한 이미지를 프레임 버퍼로 보내는 것입니다.

 

또 알아둬야 할 것은 게임의 그래픽 설정이나 3D 그래픽 속성에 포함된 "수직 동기"를 설정하면 "Present 메소드의 호출에 따라 다이렉트 X가 이미지를 프레임 버퍼로 전송하는 타이밍"이 수직 동기화(리프레시율)되는 것입니다.

 

그러니까 EndScene과 Present 메소드를 인터럽트하면 렌더링이 끝난 시점이나 1프레임을 그리고 프레임 버퍼로 전송한 시점을 알 수 있습니다. 따라서 EndScene과 Present 메소드가 1초에 몇 번 호출됐는지를 세면 프레임 속도가 나오는 것입니다.

 

물론 GPU는 짧은 시간에 한 장면의 렌더링을 마칠 수 있으니 EndScene 메소드나 Present 메소드가 자주 호출되며 그 결과 프레임 레이트는 높아집니다. 이렇게 보면 프랩스의 방법은 알맞는 것처럼 보입니다.

 

 

파크라이 3

 

그럼 NVIDIA는 프랩스의 어떤 부분을 문제로 지적하는 것일까요. 그것은 "장면-씬-의 렌더링 속도가 일정하지 않다"는 점입니다.

 

부하가 낮은 장면이라면 렌더링을 1ms 안에 끝낼 수 있을지도 모릅니다. 렌더링 부하가 높다면 화면을 그려내는 데 20ms가 걸릴지도 모릅니다. 장면을 그려내는 부하에 따라 그 차이는 몇십배에서 수백배가 될 수 있지만, 실제 디스플레이에 표시되는 타이밍은 리프레시율에 맞춰 고정되어 있습니다.

 

디스플레이는 화면의 리프레시율에 따라 화면을 업데이트합니다.한다. 리프레시율이 60Hz이라면 장면의 렌더링 속도가 어떻건 간에 사용자가 보게 되는 영상은 어디까지나 1초당 60프레임이 됩니다. 즉 장면의 렌더링 속도와 사용자가 보는 영상 사이에는 큰 차이가 있습니다. NVIDIA가 문제로 삼는 것도 바로 이 부분입니다.

 

앞에서 말한 것처럼 게임이나 그래픽 드라이버에서 수직 동기화를 활성화하면 장면의 렌더링 속도와 리프레쉬율의 타이밍을 맞추니까, 사용자가 보는 프레임 레이트는 장면의 렌더링 속도와 같게 됩니다. 하지만 프랩스에서 프레임 속도를 측정할 때에는 수직 동기화를 꺼야 합니다. 이유는 간단합니다. EndScene 메소드나 Present 메소드의 수를 측정하는 프랩스는 수직 동기화를 켰을 때 프레임 속도의 상한선이 리프레시율로 고정되기 때문입니다.

 

그러나 수직 동기화를 끄면 장면을 그려내는 렌더링 속도와 사용자가 보는 영상 사이에 차이가 생깁니다. 수직동기화를 해제했을 때 디스플레이에 표시되는 화면은 어떨까요?

 

리프레시율을 60Hz로 설정했을 때를 생각해 봅시다..GPU 내부의 영상 출력 회로는 약 16.7ms의 간격에 따라 일정하게 프레임 버퍼를 스캔해 디스플레이 신호로 변환하고 디스플레이로 보냅니다. 이때 수직 동기화를 껐다면 영상 출력 회로가 프레임 버퍼를 검색하고 있는 중에도 프레임 버퍼의 내용이 갱신됩니다.

 

 

NVIDIA의 자료를 봅시다. 수직 동기화를 껐을 때를 상정한 것입니다. 왼쪽은 '장면을 렌더링해 프레임 버퍼로 보내는 시간"이고 오른쪽은 "프레임 버퍼의 내용을 디스플레이에 보내는 시간(영상 출력 회로가 프레임 버퍼를 검색해 영상 신호로 바꾸는 리프레시 타이밍)"입니다. 두 작업의 타이밍이 다르기 때문에 화면에서 1프레임마다 표시되는 내용은 비디오 버퍼에 있는 여러 프레임으로 구성되어 있습니다. 이 이미지는 왼쪽이 일정한 타이밍으로 된 것처럼 나와 있으나 실제로는 일정하지 않습니다. 이것까지 고려하면 더욱 까다로워지지요.

 

이런 구조에서 무엇이 문제가 될까요. NVIDIA는 "프랩스로 표시하는 프레임 레이트와 플레이어가 보는 프레임은 항상 일치하지 않는다"고 지적합니다.

 

다만 "프랩스에서 표시하는 프레임 레이트와 플레이어가 보는 프레임이 일치하지 않는다"는 건 게이머에게 별 문제가 아닙니다. 게임을 플레이할 때 수직 동기화를 켜면 플레이어가 보는 프레임과 렌더링된 프레임은 일치하기 때문입니다. 즉 문제가 되는 건 "프랩스에서 프레임을 측정할 때 뿐"입니다.

 

 

"프랩스가 무엇을 측정하는지"를 나타낸 그림입니다. 가로 축은 시간입니다. 프랩스는 게임 엔진이 호출하는 EndScene나 Present 메소드의 수를 세고 있습니다. TPresent라고 적혀 있는 부분이 그것입니다. 그러나 디스플레이에 장면이 표시되려면 다이렉트 X API가 GPU 드라이버를 불러내 GPU 하드웨어를 구동시켜 렌더링을 한 다음 GPU 내부의 영상 회로가 프레임 버퍼를 수직 동기화에 맞춰 스캔해 디스플레이로 신호를 보내야 합니다.

 

프랩스로 프레임 속도를 측정하면 구체적으로 어떤 문제가 있을까요? NVIDIA는 아래 그림대로 그 문제를 설명하고 있습니다. 수직 동기화를 해제하면 특정 프레임이 디스플레이에 표시되지 않거나(삭제되거나) 불완전하게 표시되는 일이 발생할 수 있습니다.

 

 

프레임의 렌더링이 순조롭게 일정 시간마다 실행되는 동안 사용자가 보게 될 프레임입니다. 속도가 빠른 GPU라면 대게 수직 동기화를 했을 경우보다 더 빠르게 프레임을 그려내기 때문에 프랩스로 측정하는 프레임은 한개의 장면에 맞아 떨어지고 누락되는 프레임은 없습니다.

 

 

GPU 성능이 떨어지거나 다른 이유로 프레임을 렌더링하는데 시간이 걸리면 프레임 하락 현상이 나타납니다. 이 그림에선 화면에 출력되는 첫 프레임의 다음 프레임이 저장되어 있습니다. 하지만 게임 엔진에서 이미 EndScene과 Present 메소드는 호출이 된 상태기 때문에 프랩스에선 저장된 프레임도 프레임에 포함합니다.

 

 

프레임 드롭과 마찬가지 이유로 특정 프레임이 거의 표시도지 않는 현상도 나타날 수 있습니다. NVIDIA의 자료에선 20라인 이하에 표시되지 않는 프레임을 Runt Frame이라 부릅니다. Runt는 "대수롭지 않을 만큼 작다"는 뜻인데 여기서는 '불완전한 프레임'이라 합니다. 이런 프레임도 프랩스는 카운트합니다.

 

NVIDIA가 지적하는 현상이 왜 생기는지 장담할 순 없지만 추측은 가능합니다. 예를 들어 "어떤 이유로 정상적으로 장면의 렌더링을 마치지 못했다"는 것입니다. GPU나 드라이버 오류 때문에 렌더링이 제대로 마치지 못한 채로 Present 메소드가 호출되는 것입니다.

 

에러 등의 문제 때문에 GPU에서 렌더링이 끝까지 실행되지 않으면 BeginScene에서 EndScene까지 처리가 초고속으로 끝날 수도 있습니다. 그럼 오류가 생긴 프레임이 표시되지 않거나 렌더링이 불완전할 수도 있습니다(이 프레임이 존재해서 프랩스에서 측정한 프렘 속도가 맞지 않게 됨).

 

또 게임 엔진 내 처리에 문제가 있어 렌더링이 불완전해지는 경우도 생각할 수 있을 것입니다. 게임의 버그나 게임 프로그램 내부의 시간 관리에 문제가 있고 렌더링을 도중에 그만두는 경우입니다. 수직동기화를 무효화해 그런 문제가 표면화하는 게임 프로그램이 있을 수도 있ㅅㅂ니다.

 

결국 API의 호출 횟수를 측정하는 프랩스는 드롭되거나 정상적으로 표시되지 않는 프레임까지 계산합니다. 이게 문제라고 NVIDIA가 지적하는 것입니다.

 

 

디스플레이에 표시된 프레임을 측정하는 FCAT

 

이제 본론인 FCAT입니다. 프랩스가 이런 문제를 가지고 있다는 걸 인지한 NVIDIA가 개발한 측정 시스템입니다. 몇년 전에 완성해서 회사 내부에서 프레임 속도를 측정할 때는 FCAT을 사용해 왔다고 합니다.

 

그럼 왜 지금 NVIDIA는 이 프로그램의 존재를 공개한 것일까요. 그건 사람들과 지식을 나누기 위해서라고 합니다. 결코 자사 제품에 유리한 자료를 내기 위해서가 아니라요.

 

NVIDIA에서 만든 것이니 공정하지 않다고 말할 수도 있겠지만, 결론부터 말하면 FCAT 자체에 큰 비밀은 없고 또 그런 것이 존재할 여지도 없습니다.

 

FCAT는 간단히 말하면 실제로 화면에 표시된 프레임을 조사하기 위한 시스템입니다. 구조는 매우 단순한데, 벤치마크용 PC에서 출력한 영상을 다른 PC에 장착한 고성능 동영상 캡처 카드를 써서 비압축데이터 그대로를 녹화하고 이를 분석해 저장된 프레임이나 불완전하게 표시된 프레임의 존재를 파악하고, 실제 사용자가 보는 프레임 속도나 저장된 프레임이나 불완전한 프레임 수를 조사하는 것입니다.

 

 

FCAT 시스템의 개요에서 왼쪽 PC가 벤치마크용입니다. 디스플레이 출력을 DVI 스플리터를 써서 2개로 나누고 메인을 디스플레이에, 보조를 녹화용 PC에 연결합니다.

 

 

NVIDIA에서 받은 비전 DVI-DL. PCI-E x4에 연결하고 듀얼링크 DVI-D 입력을 갖춘 카드입니다.

 

 

Gefen의 듀얼링크 DVI 스플리터.

 

캡처 카드를 NVIDIA에서 만든 거라면 어떤 조작이 있을지도 모른다고 의심할 수 있지만, FCAT 캡처 카드는 영국 Detapath에서 만든 비전 DVI-DL이며, 주문 제작한 제품이 아닌 일반 제품입니다. NVIDIA도 Detapath에서 구입해 사용하는 것입니다. 듀얼링크 DVI 스플리터는 Gefen의 2 DVI DL 스플리터(제품 번호 EXT-DVI-142DL)입니다.

 

비전 DVI-DL은 큰 특징이 없는 캡처 카드이며, 충분한 속도를 내는 스토리지에 저장한다는 전제 조건 하에 최대 2560x1440, 리프레시율 60Hz의 영상을 끊김 없이 녹화할 수 있습니다. 즉 테스트할 수 있는 해상도는 2560×1440이 최대라고 할 수 있지만 NVIDIA 서라운드나 AMD의 아이피니티를 활용한 멀티 디스플레이 기반 고해상도에선 기본 디스플레이 출력을 비전 DVI-DL로 돌려 테스트할 수 있습니다.

 

또 싱글 디스플레이에서도 해상도 2560×1440, 리프레시율 60Hz를 넘는 해상도를 써서 FCAT 시스템에서 분석하려면 비전 DVI-DL 이상의 성능을 가진 동영상 캡처 카드가 필요합니다.

 

하지만 이렇게 저장한 동영상 데이터를 그냥 보는 것만으론 불완전하게 표시되는 프레임이 뭔지 알 수 없습니다. 그래서 NVIDIA는 FCAT의 벤치마크 대상 기기에서 오버레이라는 도구를 작동시키게 됩니다.

 

 

오버레이를 띄운 상태에서 게임을 실행합니다. 다이렉트 X API를 인터럽트해서 프레임마다 다른 색상의 막대를 오버레이 표시합니다.

 

이 오버레이도 특별한 건 아니고 화면 왼쪽에 컬러 바를 오버레이 표시하는 도구입니다. 다이렉트 X API를 가로채 프레임마다 다른 색의 막대를 오버레이 표시하는 구조입니다. 프랩스가 계산한 프레임을 화면의 4곳에 표시한다면, 오버레이는 프레임마다 다른 색상의 막대를 표시하는 것입니다.

 

아래 동영상은 오버레이를 상주시킨 상태에서 게임을 실행해, 카시오의 고속 카메라인 하이스피드 엑슬레임 EX-FH100을 써서 일반 디스플레의 리프레시율보다 4배 빠른 240fps로 촬영한 것입니다. 보통 속도로 촬영하면 왼쪽의 컬러 바에 어떻게 표시되는지 알 수 없으니, 4배속으로 촬영해서 표준 속도로 재생하는 것입니다.

 

그래서 동영상을 보면 그래픽 렌더링 쪽이 화면 주사율보다 빨라, 1개의 화면에 여러 프레임이 존재하고 그 때문에 오버레이에 따라 겹쳐진 칼라 바도 하나의 화면에 여러 색깔이 존재한다는 것을 확인할 수 있습니다.

 

 

표시되는 컬러 바의 색은 16가지. 16프레임마다 색이 원래대로 돌아오는 것입니다. 그러니까 프레임 드롭이 연속해서 발생해도 16프레임 연속으로 드롭되지 않는 한 저장된 프레임을 알 수 있습니다. 16프레임 연속으로 드롭되는 경우는 없을 것이니까 이렇게 테스트해도 괜찮겠지요.

 

이 컬러 바를 띄운 게임 영상을 벤치마크용 PC에서 출력, 스플리터를 통해 분할하고 비전 DVI-DL에서 PC에 비디오 데이터로 입력을 받는데, 여기에는 오픈소스 소프트웨어인 버추얼덥을 사용합니다.

 

 

버추얼덥 1.9.11.

 

비압축 AVI 포맷에서 각각의 프레임을 분석하는 방법의 자세한 설명은 생략합니다. 기본적으로는 60프레임에서 드롭 없이 비압축 AVI 포맷으로 하도록 정했다고 보면 됩니다.

 

입력된 데이터는 FCAT용으로 NVIDIA가 쓰는 도구인 Extractor로 읽어 냅니다. 이것은 프레임마다 컬러 바를 분석해 통계 데이터를 내는 것입니다.

 

 

프레임마다 컬러 버를 분석해 통계 데이터로 내보내는 Extractor. 동영상 데이터를 분석해 CSV 형식의 통계 데이터를 만드는 도구이기도 합니다.

 

 

gnuplot은 명령과 수식을 통해 차트를 만드는 프로그램입니다. FCAT은 gnuplot 스크립트에서 명령을 받아 자동으로 차트 데이터를 만들어내니까, FCAT로 테스트하는 사람이 일일이 gnuplot을 조작할 필요는 없습니다.

 

Extractor가 출력된 통계 데이터를 NVIDIA의 Perl 스크립트(fcat.pl과 3개의 유틸리티 스크립트가 포함된 것)에서 처리해, 프레임 레이트의 변화, 불완전한 프레임과 드롭된 프레임이 포함된 비율을 계산해 내 알아보기 쉬운 테이블이나 차트로 바꿉니다.

 

여기서 사용하는 그래프 프로그램은 gnuplot. 오픈 소스입니다.

 

여기까지가 FCAT의 개요입니다. 그럼 FCAT에서 어떤 데이터를 얻을 수 있을까요? 이제 데이터가 어떤 의미를 가지고 있는지를 설명하고 실제 게임 프로그램을 이용해 테스트하도록 하겠습니다.

 

 

4개의 게임 타이틀을 FCAT에서 본다면?

 

그래서 준비한 것이 아래 게임들입니다. 모두 자체 벤치마크를 가지고 있는 것들이지요.

 

파 크라이 3

크라시스 3

엘더 스크롤 5: 스카이림

심시티

 

테스트에서 준비한 그래픽카드는 2개, 지포스 GTX 680 레퍼런스와 라데온 HD 7970 GHz 에디션입니다. 드라이버는 모두 테스트 당시의 최신 버전. 지포스 320.18과 카탈리스트 13.5 베타2입니다.

 

 

코어 i7-3770K

 

그 밖의 PC 구성은 아래 표대로입니다. 해상도는 1920×1080과 2560×1440, 4x AA와 16x AF를 적용한 고화질 설정(스카이림만 4x AA가 아닌 8x AA를 적용하는 울트라 옵션, 심시티는 AA&AF 설정)으로 테스트했습니다.

 

코어 i7-3770K 3.5GHz는 테스트에 영향을 줄 수 있으니 터보 부스트 기능을 뺐습니다.

 

 

벤치마크용 PC에서 DVI 스플리터를 통해 비디오 신호를 비전 DVI-DL로 입력할 때는 이 표에 나온 구성의 PC를 썼습니다.

 

 

 

SSD 840 프로 256GB

 

비전 DVI-DL을 실행하는 캡쳐용 PC는 스토리지가 빠룰스록 좋고 레이드 0이 필수라고 조언했기 때문에, 삼성 SSD 840 프로 256GB를 2개 썼습니다. ASUS의 막시무스 IV 익스트림-Z 메인보드에 칩셋 내부 SATA 6GBps 포트에 연결해 레이드 0으로 구성, 캡처한 데이터를 저장하도록 했습니다.

 

 

FCAT와 프랩스를 비교하면? 큰 차이는 없음

 

그럼 게임 타이틀별로 어떤 결과가 나는지를 봅시다. 크라이시스 3는 가장 말이 많은 타이틀 중 하나이니 크라이시스 3부터.

 

 

크라이시스 3

 

프랩스에선 측정 시간을 지정할 수 있지만 FCAT은 '프로그램 시작 후 몇 초 동안 자동 측정"이라는 옵션이 없습니다. 그래서 동`10초 정도 더 걸렸습니다.

 

여러분이 제일 궁금하는 것은 NVIDIA의 주장대로 '불완전한 프레임'이 과연 어느 정도냐 되냐는 것입니다. 이를 나타내는 것이 아래 그래프입니다. 가로 축이 시간(초), 세로 축이 프레임 속도, 즉 프레임 속도의 변화를 나타낸 그래프입니다. 위가 지포스 GTX 680, 아래가 라데온 HD 7970 GHz 에디션이며 모두 1920x1080 해상도입니다.

 

그래프에도 표시했지만 프랩스의 데이터는 검은색 선으로 표시했습니다. 다만 '진짜' 프랩스를 이용해 측정한 프레임 레이트는 아닙니다. 아트에 검은색 선으로 나타낸 건 '오버레이에 의해 표시된 컬러 바의 색을 사용해 계산한' '프랩스가 잡아내는 프레임 레이트'라는 뜻입니다.

 

오버레이는 프랩스와 마찬가지로 다이렉트 X API를 후킹해서 컬러 바를 오버레이하니까, 컬러 바의 색을 보면 프랩스가 측정하는 프레임 속도 그대로를 알 수 있는 것입니다.

 

여기서 드롭하거나 불완전한 프레임을 프랩스의 프레임 레이트에서 빼고 남은 프레임 레이트-NVIDIA는 이를 네이티브 FPS(NFPS)라 부르지만 그래프에는 그냥 FPS라고만 표기-는 파란색 선으로 표시했습니다.

 

다만 이 그래프에선 검은색 선에 파란색 선이 겹쳐져 있기 때문에 검은색 선은 보이지 않습니다. 그러니까 네이티브 FPS와 프랩스의 측정 데이터는 일치하며, 드롭되거나 불완전한 프레임은 없었다는 것입니다. 즉 이 테스트 조건으로 프랩스에서 프레임을  측정하면 의심할 여지가 없이 정확하다고 말할 수 있습니다.

 

 

크라이시스 3의 프레임 레이트 변화. 지포스 GTX 680(1920x1080의 고화질 설정)

 

 

크라이시스 3의 프레임 레이트 변화. 라데온 HD 7970 GHz 에디션(1920x1080의 고화질 설정)

 

그럼 2560x1440에선 어떨까요? 그 결과를 정리한 것이 아래 그래프입니다. 여기서도 네이티브 FPS와 프랩스의 측정 값은 일치합니다. 1920x1080이나 2560x1440에 고화질 설정에서 싱글 카드를 사용할 경우...라는 조건이 붙긴 하지만, 이 때 프랩스의 데이터는 믿어도 좋다는 결론이 나온 셈입니다.

 

 

크라이시스 3의 프레임 레이트 변화. 지포스 GTX 680(2560x1440의 고화질 설정)

 

 

크라이시스 3의 프레임 레이트 변화. 라데온 HD 7970 GHz 에디션(2560x1440의 고화질 설정)

 

그 외에 FCAT에선 2개의 재밌는 그래프를 볼 수 있었습니다. 하나는 퍼센타일, 다른 하나는 프레임 타임입니다.

 

퍼센타일(percentile)이라는 말은 낯선 단어처럼 보이지만 간단히 설명하면 이렇습니다. 데이터가 어떻게 변하는지를 측정한 것입니다.

 

아래 차트는 퍼센타일 데이터를 정리한 것입니다. 먼저 말한대로 딱 1분-3600프레임-을 지키진 못했지만 대충 1분 정도 됩니다. 이 3600프레임 중에서 3600개의 프레임 속도가 전체에서 어느 정도의 비율을 차지하는지를 이 차트를 통해 알 수 있습니다.

 

그래프 세로는 최소 프레임, 가로는 백분율이니까 이대로 보면, 지포스 GTX 680은 세로에서 20번째 줄에 약 80퍼센타일이 나옵니다. 이 말은 지포스 GTX 680이 내는 프레임 속도 중 80%는 20프레임 이상이라는 소리가 됩니다.

 

 

크라이시스 3의 퍼센타일. 지포스 GTX 680과 라데온 HD 7970. 2560x1440 고품질 설정

 

최소 프레임 속도를 높게 잡을수록 데이터의 수가 줄어드니까, 뭔가 특별한 일이 없다면 그래프는 왼쪽이 치우친 형태를 보입니다. 한편 그래프의 오른쪽 가장자리를 보면 최소 프레임 레이트의 불균형을 볼 수 있습니다. 즉 그래프의 모양을 보면 GPU의 특성이라고 해야 할까요. 프레임 레이트의 불균형을 확인할 수 있는 것입니다. 다만 여기서는 두 제품 사이에 그리 큰 차이점은 보이지 않습니다.

 

또 위에 나온 그래프는 2560x1440 해상도였지만, 1920x1080에서도 같은 결과가 나왔습니다.

 

다른 프레임 기록을 정리한 것이 아래 그래프입니다. 여기서는 가로축이 시간의 흐름, 세로축이 해당 프레임을 그리는 데 필요한 시간을 나타냅니다. 즉 프레임을 렌더링해내는 데 시간이 어떻게 변하는지를 추적한 것입니다.

 

여기선 지포스 GTX 680이나 라데온 HD 7970 GHz 에디션 모두 일정 범위 안에서 띠 모양의 그래프를 그리고 있습니다. 이것은 프레임의 렌덜이 시간에 변동이 생겼다는 의미입니다. 그래프가 크게 요동하는 것은, 특정 이유로 해당 프레임을 그리는 데 비정상적일만큼 긴 시간이 걸렸다는 이야기입니다.

 

 

크라이시스 3의 프레임 타임. 지포스 GTX 680과 라데온 HD 7970. 2560x1440 고품질 설정

 

 

파 크라이 3

 

FCAT가 만들어내는 그래프의 의미를 염두에 뒀을 때, 프레임 레이트의 변화를 보고 재밌는 특징이 있는 데이터에선 퍼센타일의 차트도 보는 식으로 가도록 합시다.

 

다음은 파 크라이 3입니다. 1분 간 프레임 속도를 측정하는데, 크라이시스 3와 달리 사용자가 게임 조작을 할 필요는 없습니다. 다만 측정 시간이 몇 초 정도 오차가 있는 건 염두에 두시고.

 

프레임 레이트의 변화는 아래에 나온대로, 1920x1080과 2560x1440에서 FCAT와 프랩스의 측정 데이터는 일치했습니다. 퍼센타일과 프레임 타임도 지포스 GTX 680과 라데온 HD GHz 에디션에서 큰 차이는 없었습니다. 즉, 크라이시스 3와 마찬가지로 프랩스의 데이터를 믿을 수 있습니다.

 

 

파크라이 3의 프레임 레이트 변화. 지포스 GTX 680, 1920x1080 고부하

 

 

파크라이 3의 프레임 레이트 변화. 라데온 HD 7970 GHz 에디션, 1920x1080 고부하

 

 

 

파크라이 3의 프레임 레이트 변화. 지포스 GTX 680, 1920x1080 고부하

 

 

파크라이 3의 프레임 레이트 변화. 라데온 HD 7970 GHz 에디션, 1920x1080 고부하

 

 

엘더 스크롤 5: 스카이림

 

앞의 두 테스트에션 FCAT와 프랩스의 차이가 없었지만, 엘더 스크롤 5: 스카이림에서 드디어 차이가 나타났습니다.

 

앞서 말한대로, FCAT은 동영상을 캡처해 Extractor로 통계 데이터를 보낸 다음 스크립트로 처리하는 순서를 밟게 됩니다. 스카이림에서도 정상적으로 영상이 캡쳐되고 VirtualDub을 사용한 검사에서는 영상에서 드롭된 부분이 없다는 것도 확인할 수 있었지만, 마지막 스크립트 처리에선 '저장된 프레임이 있다'는 오류가 떴습니다.

 

몇 번이나 도전했지만 결국 지포스 GTX 680에서는 2560x1440 해상도의 데이터를 얻어내지 못했습니다. 그래서 여기선 그 데이터를 뺐으며, 원인은 아직 파악하지 못했으나 나중에 알게 되면 다시 추가하겠다고 하네요.

 

그 외에 스카이림의 테스트 조건은 앞서 말한대로. 측정 시간은 약간씩 차이가 납니다.

 

 

스크립트 실행이 순조롭게 끝난 것처럼 보이지만-

 

 

스카이림에선 동영상에 드롭된 프레임이 없는데도 불구하고 프레임 검출에서 오류가 나는 경우가 있습니다. 사실 이 오류는 다른 타이틀에서도 발생했으나 스카이림에선 특히 많이 발생했습니다.

 

그래서 이번에는 지포스 GTX 680과 라데온 HD 7970 GHz 에디션을 제대로 비교할 수 있는 1920x1080 해상도에서 스카이림의 결과를 봤습니다.

 

우선 지포스 GTX 680. 46초와 50초에서 파란색 선과 검은색 선이 서로 엇갈린 것을 볼 수 있습니다. 통계 데이터를 조사하면 지포스 GTX 680에선 총 3개의 Runt 프레임이 생긴 것으로 나타났습니다. 앞서 말한대로 Runt 프레임은 20라인 이하로 렌더링된 불완전한 프레임입니다.

 

 

스카이림의 프레임 레이트 변화. 지포스 GTX 680, 1920x1080, 울트라

 

한편 라데온 HD 7970 GHz 에디션에선 테스트 시작 직후-3~5초-에 파란색 선과 검은색 선이 큰 차이를 보이는 것을 확인했습니다. 또 15초, 35초, 46초에서도 작은 편차가 있었습니다.

 

통계를 보면 테스트 모두 불완전한 프레임이 12개, 드롭된 프레임은 없었습니다.

 

 

스카이림의 프레임 레이트 변화. 라데온 HD 7970 Ghz 에디션, 1920x1080, 울트라

 

 

통계 데이터를 엑셀에서 확인했습니다. OFPS가 프레임 측정 결과, NFPS가 네이티브 FPS.

 

기본적으로 스카이림의 1920x1080 해상도 울트라 옵션에선 Runt 프레임-불완전한 프레임이 존재하며, 이를 빼면 프랩스에서 측정한 점수에 비해 실제 프레임은 다소 낮다는 결론이 나옵니다. 다만 이 정도 차이는 오차 범위라고 해도 좋을 정도입니다.

 

이것은 FCAT에서 얻은 CSV 데이터를 통해 프랩스의 프레임 속도와 네이티브 FPS를 알 수 있기 때문입니다. 여기에 표시된 화면은 스카이림인데 불완전한 프레임 수는 매우 적어 프레임 레이트 전체에 큰 영향을 미칠 정도는 아니었습니다.

 

스카이림에선 지포스 GTX 680과 라데온 HD 7970 GHz 에디션의 퍼센타일에서도 비슷한 차이가 나타났습니다. 그게 바로 아래 그래프입니다. 지포스 GTX 680은 프레임 레이트의 변동폭이 크지 않지만 라데온 HD 7970GHz 에디션에선 적은 표본 수에 극단적으로 높은 프레임 레이트가 나타나고 있습니다.

 

극단적으로 높은 프레임 레이트가 기록되면서, 차트 오른쪽이 지포스 GTX 680보다 낮다는 건, 낮은 프레임 레이트도 다수 섞여 있다는 것을 의미합니다. 즉 라데온 HD 7970 GHz 에디션이 프레임 레이트의 변동폭이 커서, 렌더링이 안정되지 않았다는 이야기입니다.

 

 

스카이림의 퍼센타일. 지포스 GTX 680과 라데온 HD 7970 GHz 에디션. 1920x1080, 울트라

 

앞서 말한대로 2560x1440에선 라데온 HD 7970 GHz 에디션의 점수가 나오지 않았지만, 프레임 레이트는 쉽게 알 수 있습니다. 파란색과 검은색 선 사이에 격차가 나며, 불완전한 프레임 발생과 프레임 드랍이 골고루 발생할 수 있습니다. 통계를 보면 불완전한 프레임은 232개, 드롭된 프레임은 137개입니다.

 

프랩스 측정 값은 84.62fps니까 불완전한 프레임이나 드롭된 프레임을 뺀 네이티브 FPS는 77.24fps로 꽤 차이가 납니다.

 

 

불행히도 지포스 GTX 680과 비교할 수 없었으니 불완전한 프레임이나 드롭된 프레임이 많았던 이유는 짐작할 수 없지만, 지포스 GTX 680과 라데온 HD 7970GHz 에디션 같은 고급형 GPU에서 스카이림의 렌더링 부하가 낮았던 것이 그 원인일지도 모릅니다. 라데온 HD 7970 GHz 에디션에서 프레임 속도가 매우 커졌기 때문에 60Hz로 영상을 내보낼 때 표시되는 프레임이 안정되지 않았다는 이야기도 가능할 것입니다.

 

 

심시티

 

심시티는 원래 120초 동안 프레임을 측정했지만, FCAT로 120초 동안 측정하면 비압축 캡처 데이터의 용량이 매우 커지기 때문에 이번에는 60초 동안 측정했습니다.

 

1920x1080 때의 점수는 아래 나타난 대로입니다. 라데온 HD 7970 GHz 에디션에선 시작한지 8초만에 두 선의 차이가 보입니다. 나머지는 안정되어 있네요.

 

 

심시티의 프레임 레이트 변화. 지포스 GTX 680. 1920x1080, AA&AF

 

 

심시티의 프레임 레이트 변화. 라데온 HD 7970 GHz 에디션. 1920x1080. AA&AF

 

한편 2560x1440에선 두 그래픽카드 모두 골고루 불완전한 프레임이 발생했으며, 라데온 HD 7970 GHz 에디션에선 일부 프레임 드롭도 생겼습니다. GPU와 관계 없이 같은 결과가 나왔으니, 이 불완전한 프레임은 게임 타이틀의 특성이라고 봐야 할 것입니다. 실제 퍼센타일이나 프레임 타임에서 별 특징적인 차이가 없었습니다.

 

 

심시티의 프레임 레이트 변화. 지포스 GTX 680, 2560x1440, AA&AF

 

 

심시티의 프레임 레이트 변화. 라데온 HD 7970 GHz 에디션, 2560x1440, AA&AF

 

통계에 따르면 2560x1440 해상도에서 불완전한 프레임의 수는 지포스 GTX 680이 225개, 라데온 HD 7970 GHz 에디션이 248개. 드롭된 프레임은 지포스 GTX 680에선 없었고 라데온 HD 7970 GHz 에디션에선 17개였습니다.

 

그래서 프랩스 측정값과 네이티브 FPS 사이에는 차이가 발생했으며, 지포스 GTX 680에선 프랩스가 53.94fps였고 네이티브 FPS는 59.53fps가 나왔습니다. 라데온 HD 7970 GHz 에디션에선 프랩스가 72.06fps, 네이티브 FPS가 66.96fps로 약 7%의 차이가 있었습니다.

 

즉 심시티의 2560x1440 옵션에선 프랩스보다 7% 정도 낮은 프레임을 사용자가 체험하게 된다는 이야기가 됩니다.

 

 

멀티 GPU 구성 시 지포스와 라데온 사이에 큰 차이가 있음

 

이어서 멀티 GPU 구성입니다. 여기선 지포스 GTX 680과 라데온 HD 7970 GHz 에디션의 레퍼런스 카드를 더해서 SLI나 크로스파이어 구성을 한 후 테스트했습니다. 그래픽카드의 구성 외에는 아무것도 바꾸지 않았습니다.

 

다만 테스트에 쓰는 타이틀은 크라이시스 3와 파 크라이 3만 골랐습니다. 스카이림에선 단일 카드를 구성했을 때 측정 데이터가 안정되지 않았던 문제가 SLI 구성에선 더욱 악화됐던 것입니다. 심시티는 원래 멀티 GPU 구성에서 프레임 속도의 향상을 기대할 수 없다는 게 그 이유일지도요.

 

 

크라이시스 3

 

그럼 크라이시스 3부터. 크라이시스 3의 다중 GPU 구성에선 1920x1080 해상도에서 매우 흥미로운 데이터가 나왔습니다.

 

아래의 그래프 2개를 보면 라데온 HD 7970의 크로스파이어에서 이상이 생겼다는 것을 알 수 있을 것입니다.

 

불완전하거나 드롭된 프레임 수가 비정상적으로 많지만, 측정을 잘못했을 가능성은 매우 낮습니다. NVIDIA의 자료도 비슷하거든요. NVIDIA는 FCAT을 공개한 이유를 '사람들과 정보를 공유하기 위해서'라고 말하지만, 어쩌면 멀티 GPU 구성 결과를 보여서 '사람들에게 SLI와 크로스파이어는 이렇게 결과의 차이가 난다'라는 정보를 공유하고 싶은 게 아닐까 생각도 듭니다.

 

 

크라이시스 3의 프레임 레이트 변화. 지포스 GTX 680 SLI. 1920x1080. 고부하 설정

 

 

크라이시스 3의 프레임 레이트 변화. 라데온 HD 7970 GHz 에디션 크로스파이어. 1920x1080. 고부하 설정

 

라데온 HD 7970 GHz 에디션의 크로스파이어 구성에서는 프랩스의 평균 프레임 속도와 네이티브 FPS의 차이도 매우 큽니다. 지포스 GTX 680 SLI의 경우 프랩스 점수가 57.15fps, 네이티브 FPS가 57.05fps로 0.2% 차이나지만, 라데온 HD 7970 GHz 에디션의 크로스파이어에선 프랩스 점수가 93.32fps, 네이티브 FPS는 45.05fps, 무려 48.3%밖에 나오지 않습니다.

 

왜 이런 결과가 나왔는지 짐작하긴 어렵지만, 이렇게 극단적인 증상이 나온 건 GPU나 드라이버 오류도 의심할 수 있습니다. 사실 퍼센타일을 보면 라데온 HD 7970 GHz 에디션은 크로스파이어에서 극단적으로 높은 프레임 레이트가 측정되는 등, 불균형이 매우 큽니다. 이것은 어떤 문제가 생긴 결과일지도 모릅니다.

 

 

크라시이스 3의 퍼센타일. 지포스 GTX 680 SLI와 라데온 HD 7970 GHz 에디션 크로스파이어. 1920x1080, 고부하

 

여기서 더 생각해 본다면 AMD의 그래픽 드라이버가 일부 장면의 렌더링을 생략했다고 말할 수 있을지도 모릅니다. 해상도를 높여 그래픽 렌더링의 부하를 높이면 아래 그래프레 나온대로, 라데온 HD 7970 GHz 에디션 크로스파이어에서 발상해는 증상은 상당수 사라지기 때문입니다.

 

물론 그렇다고 AMD가 특정 해상도에 무리하게 최적화를 했다고 단언할 수는 없습니다. 허나 해상도를 바꾸면 갑자기 문제가 사라진다는 것도 부자연스러운 건 사실입니다.

 

 

크라이시스 3의 프레임 레이트 변화. 지포스 GTX 680 SLI. 2560x1440의 고부하 설정

 

 

크라이시스 3의 프레임 레이트 변화. 라데온 HD 7970 GHz 에디션 크로스파이어. 2560x1440의 고부하 설정

 

 

파 크라이 3

 

파 크라이 3도 1920x1080 해상도로 테스트했습니다.

 

지포스 GTX 680의 SLI에선 총 4개의 불완전한 프레임이 있었습니다. 한편 라데온 HD 7970 GHz 에디션의 크로스파이어에선 드롭된 프레임이 총 45개에 이르렀습니다. 또 불완전한 프레임은 19개였지요. 그래서 네이티브 FPS는 라데온 HD 7970 GHz 에디션 크로스파이어가 약간 낮게 나옵니다.

 

 

파크라이 3의 프레임 레이트 변화. 지포스 GTX 680 SLI. 1920x1080 고부하 설정

 

 

파크라이 3의 프레임 레이트 변화. 라데온 HD 7970 GHz 에디션 크로스파이어. 1920x1080 고부하 설정

 

 

파크라이 3의 퍼센타일. 지포스 GTX 680 SLI와 라데온 HD 7970 GHz 에디션 크로스파이어. 2560x1440 고부하 설정. 라데온 HD 7970 GHz 에디션 크로스파이어에서 낮은 프레임 레이트가 기록되는 비중은 높지만 극단적인 문제는 없었습니다.

 

 

파 크라이 3의 프레임 변화. 지포스 GTX 680 SLI. 2560x1440. 고부하 설정

 

 

파 크라이 3의 프레임 변화. 라데온 HD 7970 GHz 에디션 크로스파이어. 2560x1440. 고부하 설정

  

2560x1440 해상도에선 어떻게 될까요. 두 멀티 GPU 구성 모두에서 불완전한 프레임이나 드롭된 프레임이 늘어나는 추세가 보였습니다. 지포스 GTX 680 SLI에선 불완전한 프레임이 185개, 드롭된 것이 0개였고, 라데온 HD 7970 GHz 에디션 크로스파이어는 각각 325개와 63개였습니다.

 

프랩스의 측정 결과와 비교하면 지포스 GTX 680 SLI의 네이티브 FPS는 약 6% 정도, 라데온 HD 7970 GHz 에디션 크로스파이어의 네이티브 FPS는 약 14.5% 정도 낮게 나왔습니다. 크라이시스 3처럼 이상한 움직임은 없었으니 사용자 체험을 알고 싶다면 이 비율이 기준이 될 것 같습니다. 

 

 

게임 타이틀에 따라 달라지는 경향을 볼 수 있는 FCAT 계측 결과. 프레임 속도 계측에 대해 다시 생각하기

 

이렇게 FCAT를 측정하니 매우 재밌는 데이터를 얻을 수 있었습니다. 크라이시스 3에서 멀티 GPU를 구성했을 때의 결과를 보면, NVIDIA가 프랩스의 측정 결과에 의문을 제기하는 것도 무리는 아니라고 봅니다.

 

사용자 중에도 프랩스에서 프레임 레이트가 높게 나왔는데 실제 게임 체감에선 그렇지 않다고 생각한 사람이 있을 것입니다. 그런 '프랩스와 체감의 차이'가 불완전한 프레임이나 드롭된 프레임에 의한 것이라 생각하면 충분히 일리 있는 이야기입니다.

 

예를 들면 심시티처럼 GPU와 상관 없이 '안정되게' 불완전한 프레임이나 드랍된 프레임을 볼 수 있는 타이틀이라면, FCAT의 데이터는 참고가 된다고 생각됩니다. 프랩스에서 측정 값과 체감 프레임이 7% 정도 차이가 난다고 보이기 때문입니다.

 

그러나 특정 GPU의 멀티 GPU 구성 등, 특정 조건에서 불완전한 프레임이나 드롭된 프레임이 자주 발생하는 경우도 생길 수 있다는 걸 이번 테스트 결과에서 알 수 있습니다. 그리고 이런 특정 조건에서 발생한 전체 프레임이나 드롭된 프레임은 FCAT을 이용해 세밀히 조사해야만 알 수 있습니다.

 

그럼 평소 테스트에서도 FCAT을 쓰면 되지 않을까...라는 주장이 나올 수 있지만. 테스트 기기의 구성은 둘째 치고 이 방법은 시간이 너무 오래 걸리기 때문에 항상 벤치마크를 이런 식으로 할 수는 없습니다.

 

다만 FCAT에서 분명 흥미로운 결과가 나왔고, 실제 사용자에게도 참고가 되는 결과임엔 분명합니다.

 

또 이번에는 테스트를 생략했으나 3D마크 같은 소프트웨어에서 프레임 속도를 측정했을 경우에도, 불완전한 프레임이나 드롭된 프레임이 발생했을 가능성은 분명 있습니다. 소프트웨어적으로 봤을 때 '사용자가 보는 프레임 수'를 조사할 방법은 없으니까, 프랩스를 쓰지 않고 스코어를 매기는 3D 마크 같은 테스트에서도 비슷한 결과가 나왔을 가능성이 있습니다.

 

앞서 말한대로 NVIDIA는 FCAT을 정식 공개할 계획은 없습니다. 그래서 사용자가 테스트할 기회는 없다고 보지만, NVIDIA가 공개하는 벤치마크 그래프는 앞서 설명했던 과정을 거쳐 테스트한 것이라고 볼 수 있습니다. 그럼 NVIDIA가 내놓은 결과를 받아들이는 생각이 달라지게 되겠지요.

 

출처: http://www.4gamer.net/games/032/G003251/20130528026/