KGC 2014 프로파일러를 이용한 게임 클라이언트 최적화

프로파일러를 이용한 게임 클라이언트 최적화

김종원 NCSOFT/GP Team

Who’s talking?

• 엔씨소프트 NCSOFT (2004~) – 현재 GP team (2014.6~) – Technical director, Lineage Eternal (2007~2013)

• 모코코 Mococo (2000~2004) – Mobile Department Director

• ForByte (1999~2000) – Startup for mobile Java VM, embedded systems

• 한글과컴퓨터 Hangul & Computer (1994~1997) – 윈도우용 버전 HWP 3.0 series, HWP 96 etc.

• 한메소프트 Hanme soft (1992) – 파피루스

• 컬럼 ‘망치와 모루＇ ZDNet 컬럼 연재 (2000~2004)

2014-11-05 Game client optimization with the profiler 2

누구를 위한 강의인가?

• 대상 – 게임 클라이언트 프로그래머 – 프로그래머 – 게임 개발에 관심 있는 분들

• 난이도

– 초급, 중급


최적화 Optimization

• 수학에서의 정의 – 제약조건(constraint)에서 함수의 최대치와 최소치를 찾는 것 – 예) 자원들이 어떤 한계를 넘지 않는 한도 내에서 직면하는 요구사항을 대부분 만족하면서 요구되는 이익을 최대화 하기 위한 것

• 컴퓨터에서의 정의 – 실행속도, 네트웍 대역폭 등을 증가 시키고 메모리 요구량을 감소시키는 방향 등으로 시스템을 개선하는 과정

– 최적화의 제약 조건들 • CPU load, FPS, 메모리 사용량, 네트워크 패킷 수, 디스크 억세스 횟수

• 명칭과는 달리 최적화가 문제에 대한 최적의 답을 찾는 것을 의미하지 않음


Finding local minimum

• 최적화는 global minimum을 찾는 것이 아니라 주어진 조건에서 local minimum을 찾는 과정

• 다양한 조건에 따라 local minimum은 달라지기 때문에 어떤 조건을 선택하는 가도 무척 중요한 결정

• 게임 개발에서 제약 조건은 주류 플레이 환경에 맞추는 것이 최우선 – 기술력을 자랑하기 위한 flagship game은 최신 HW에 최적화 가능

• 예) Unreal 4 Engine 발표 데모에서 최신 그래픽카드 3개를 사용

Optimization


게임 개발에서의 최적화 항목 예시

• 클라이언트 – 클라이언트 로딩 또는 맵 이동 시 로딩 속도 – 초당 출력하는 화면 수 FPS (frames per second) – 메인 메모리 사용량

• 서버 – 서버 당 최대 동시 접속자 수 – 네트워크 패킷 수 및 패킷 데이터 양 – DB 트랜잭션 횟수

• 다운로드 서비스 – 패키지 전체 다운로드 양 – 컨텐츠 패치 양

Optimization


Game client optimization

• Console game client – 클라이언트가 실행할 HW의 성능이 정해져 있어 최적화를 위한 제약 조건이 모든 플레이어에 있어 동일하다

– 하지만 Xbox 360, Xbox One, PS3, PS4를 지원하려면?

• Mobile game client – 매우 다양한 모바일 하드웨어로 인해 최적화 타겟 선정이 중요 – 국내는 안드로이드가 메인 타겟, 북미 및 유럽은 iOS 가 메인

• PC game client – CPU : Intel CPU와 32bit 애플리케이션이 타겟. – GPU : nvidia가 메인, 하지만 Intel 내장 GPU가 가장 많이 팔림 – OS : 여전히 지원해야 하는 Windows XP

Optimization


CPU

• Intel – 경쟁사인 AMD를 따돌리고 독주 중 – 최소 두 개 이상의 core 제품을 출시 – Hyper threading 이라는 core 수 늘리기 마케팅 중

• AMD – 64비트 컴퓨팅의 선구자였지만 – 더 이상 시장을 선도하는 모습을 볼 수 없음 – 인텔의 HT보다는 낫지만 여전히 애매한 코어 성능

• 계산 위주나 멀티 쓰레딩 컴파일 등에서는 높은 성능을 냄 – 동급의 Intel CPU에 비교해서 단일 쓰레드 성능이 20% 이상 낮음 – CPU 가 병목인 게임에는 매우 취약

Optimization


PC OS • Windows XP

– MS에서 판매 및 업데이트가 중단되었지만 중국을 포함한 아시아 권에서는 여전히 높은 점유율

– DirectX 9 만 지원. (지원을 포기할 수 없는 애증의 버전) • Windows Vista • Windows 7

– 내년 초 판매 중단 예정 – 가장 안정적인 버전과 인기 (앞으로 Windows XP의 인기를 넘겨 받을) – 모든 DirectX 버전 지원

• Windows 8.x , 10 – 아직까진 윈도우 7과 같이 취급하면 됨

• Mac OS – 특히 국내에서는 판매가 많이 되지 않아 고려 대상 제외 – 그래픽 드라이버 성능이 좋지 않아 최적화가 추가로 요구 됨

Optimization


32 vs 64

• 64 bit OS를 써야 하는 이유 – 성능 향상 – RAM

• 4GB 이상의 RAM을 사용하려면 64비트 OS 필수 – 고급 그래픽 카드 사용 시

• 1GB 이상의 메모리가 있는 비디오 카드를 사용한다면 애플리케이션 주소 공간부족 때문에 3GB 주소 공간 스위치 켜야 함

• 하지만 여전히 32bit 클라이언트 필요 – 시장에는 많은 수의 32비트 OS가 설치되어 있음 – 노트북, PC에 여전히 4GB 이하의 램과 32비트 OS가 설치 및 판매

Optimization


Graphic cards

• Nvidia – 게임 개발 시 메인 타겟 – 높은 성능과 꾸준한 드라이버 개선 및 개발 지원

• AMD(ATI) – 북미나 유럽에선 여전히 상당히 높은 점유율 – 엔비디아와 성능 경쟁에서 앞서거니 뒤서거니 하고 있음

• Intel – 시장에서 가장 많이 팔리는 그래픽 칩 (50%) – 앞의 두 회사에 비해 성능이 낮지만 계속해서 성능이 높아지고 있음 – 주로 저전력 노트북이나 업무용 PC서 쓰임 – 게임 개발 시 메인 타겟은 아니지만 메인 타겟으로 부상 중

Optimization


클라이언트 성능 최적화

• 보통 게임에서 최적화라 한다면 성능의 최적화를 의미 • 성능의 지표

– CPU load – FPS (frames per second)

• 1초에 표시되는 화면의 수 • 게임 내 프레임 표시 기능 또는 화면 캡쳐 프로그램

– 순간적인 FPS 저하 • 게임 프레임 중 갑작스런 화면 멈춤(frame rate drop)이나 애니메이션 등이 멈칫거리는 현상

• 게임 플레이에 나쁜 경험을 주지만 정량화 하기는 어려움


FPS(frame rate)

• 시각적 자극의 인지 속도와 관련 – 어두운 공간에서 빛을 인지하는데 걸리는 시간 > 16ms – 연속적 사진 중에서 다른 사진의 인지 시간 > 13ms – 아주 짧은 시각적 자극에 반응하는 시간 100 ~ 400 ms

• 디지털 비디오와 미디어에서의 frame rate – 24p 비디오를 film으로 옮길 때 사용. 애니메이션 등 – 30p 필름에서 비디오로 옮길 때 사용. 동영상 촬영 등 – 60i NTSC 방송 규격(29.97) – 60p HDTV 방송 규격, HD 동영상 촬영 등 – 120p UHDTV 방송 규격, 초고속 동영상 촬영 포맷


FPS는 얼마가 되어야 하나

• 빠르면 빠를 수록 좋다 70 ~ 90 FPS

• Oculus rift 와 같은 3D HUD 장치에서 울렁거림을 막기 위한 수치 > 60 FPS

• 빠른 화면 전환이 요구되는 FPS류의 게임, 격투 게임 > 45 FPS

• 핵&슬래시 게임 같이 액션성이 높은 게임 들 > 25 FPS

• 게임 플레에서 요구되는 하한선

Frames per second


기준 해상도는 무엇으로?

• 누구나 자신의 모니터의 최대 해상도로 게임하기 바란다 – 1024x768에서 5K 모니터까지 다양한 범위의 모니터가 존재 – 많은 개발자들은 1920x1200 해상도의 모니터에서 게임을 만들고 있으나 대중적인 컴퓨터 환경인 노트북 화면은 훨씬 낮은 해상도

• 그래서 기준이 뭔가요? – 게임의 출시 시기와 출시 국가에 맞춰 최적화 해야 – 요즘은 Full HD(1920*1080)가 기준 – 이젠 UHD 4K 해상도 플레이 테스트 및 최적화 범위에 포함 – UHD 8K는 아니지만 Retina 5K는 테스트는 해야 할지도?

Resolution


최적화를 위한 선행 작업

• 프로파일링 profiling – 다음과 같은 프로그램의 특징을 측정하여 분석하는 작업

• 메모리 사용량, 프로그램의 시간 복잡도, 특정 명령의 빈도, 특정 함수의 수행 횟수나 실행 시간

– 소스코드를 분석하거나 실행파일로 만들어 계측

• 프로파일링 기법 – 이벤트 수집 – 통계학적 방법 – Instrumentation 기법 – 시뮬레이션 기법


프로파일러 역사 • History

– 1970대 초 IBM/360, IBM/370 플랫폼에서부터 타이머 인터럽트로 PSW를 샘플링하는 방법을 사용하여 핫스팟을 찾는 프로그램 존재

– Unix 에서는 1980년대 초에 prof이나 call graph를 활용한 gprof – 1994년 DEC의 ATOM에서 컴파일 과정 중에 소스코드에 추가 코드를 삽입하여 컴파일 하는 방법으로 프로파일링하는 기법 발표

• 데이터 수집 방법 – 하드웨어 인터럽트 – 코드 인스트루먼트 code instrument – 명령 세트 시뮬레이션 – OS 시스템 후킹 – 성능 카운터 (타이머)

Profiler


http://docs.freebsd.org/44doc/psd/18.gprof/paper.pdf

http://www.ece.cmu.edu/~ece548/tools/atom/man/wrl_94_2.pdf

프로파일러 타입

• 이벤트 기법 – 함수 호출 시점, 클래스 로드, 쓰레드 전환 등의 이벤트를 기록하여 분석하는 기법으로 Java나 .NET, Python, Ruby 등의 언어에서 사용

• 통계적 기법 – OS의 타이머 인터럽트를 이용하여 샘플링 측정 – 타겟 프로그램의 속도에 영향을 끼치지 않아 전체 실행 구조를 파악하기에 매우 좋은 방법

– 실행 시간이 매우 짧은 코드에 영향을 받지 않는 장점이 있음 – 측정 횟수의 제곱근에 비례한 에러가 생길 수 있다는 단점 – ARM이나 MIPS CPU에서는 PC를 샘플링하는 PCSAMPLE 레지스터가 있어 프로그램에 전혀 영향을 주지 않는 HW가 제공됨

– AMD, Intel, Apple의 프로파일러나 Linux의 oprofile 은 모두 샘플링 기법에 기반한 통계적 기법으로 구현

Profiler


프로파일러 타입(2)

• Instrumentation – 코드에 추가적인 명령을 삽입하여 원하는 정보를 얻는 방법 – 프로그램 속도가 변함에 따라 결과에 오류가 있을 수 있고 성능 저하에 따른 예상하지 못한 부작용이 발생

– 성능 저하 정도는 데이터의 종류나 상세 정도에 따라 달라짐 • 각 라인의 실행 횟수를 측정하는 것 vs 함수의 실행 횟수

– 방식 • 프로그래머가 수작업으로 코드 삽입 • 자동 코드 삽입 툴 • 컴파일러의 도움을 받아 코드를 삽입하는 방식 • 코드가 아닌 최종 바이너리를 변환 • 실행 직전에 바이너리를 수정 • 실행 중에 인젝션 하는 방식 등

Profiler


윈도우용 프로파일러

• 목적에 맞는 성능 측정 툴을 사용해야 – 무료 툴

• Windows performance toolkit (이벤트, 샘플링) • Visual studio performance profiler, free profiler (샘플링,인스트루먼트) • NVIDIA Nsight Visual studio edition, PerfHud (샘플링, 인스트루먼트) • AMD CodeXL (CPU, GPU – AMD only), CodeAnalyst (샘플링) • Very Sleepy (샘플링)

– 유료 툴 • Intel Vtune Amplifier (샘플링) • Boland, DevPartner (인스트루먼트)

(예전 Nu-mega의 Truetimes, Boundchecker) • RAD Game Tools의 Telemetry (인스트루먼트)

Profiler


http://msdn.microsoft.com/ko-kr/library/ms182372.aspx

http://www.codeproject.com/Articles/144643/Profiling-of-C-Applications-in-Visual-Studio-for-F

https://developer.nvidia.com/nvidia-nsight-visual-studio-edition

https://developer.nvidia.com/nvidia-perfhud

http://developer.amd.com/tools-and-sdks/archive/amd-codeanalyst-performance-analyzer/

http://www.codersnotes.com/sleepy

https://software.intel.com/en-us/intel-vtune-amplifier-xe

http://www.borland.com/products/devpartner/

http://www.radgametools.com/telemetry.htm





프로파일러는 진단 도구

• 몸이 아프면 다양한 진단 방법으로 원인을 파악 – 초음파, X-ray, MRI, CT scan – 각 방법마다 측정 방식도 다르고 측정 가능한 범위도 다르다 – 특정 방법 하나가 절대적 우위를 가지지 않고 환자의 상황에 따라 복합적으로 적용하여 최종 판단

• 프로파일러도 다양하게 적용 필요 – Visual studio의 퍼포먼스 프로파일러로 최적화 포인트 파악 – Windows performance toolkit으로 이벤트나 샘플링 데이터로 특정 시점의 CPU 및 GPU의 동작을 세밀하게 기록

– 마지막으로 인스트루먼트 방식의 프로파일러로 장시간의 변동 상황을 기록하고 분석하여 문제를 개선

Profiler


http://www.youtube.com/watch?v=jAeWN5UNKog



Visual studio performance profiler

• Ultimate 및 Premium 버전에서 제공 – Professional 버전에는 없기 때문에 간단하게 샘플링 방식의 프로파일러를 사용하려면 Code Project에 올라와 있는 툴을 이용

• 샘플링 및 인스트루먼트 방식의 프로파일링 기법 제공 – 테스트 목적에 맞게 선택하고 최적화 포인트 지점 파악

• 자세한 사항은 MSDN 참조


http://www.codeproject.com/Articles/144643/Profiling-of-C-Applications-in-Visual-Studio-for-F

Windows performance toolkit

• 윈도우 시스템의 이벤트들을 기록하고 분석할 수 있는 툴 – Windows Performance Recorder – Windows Performance Analyzer

• 윈도우의 거의 모든 상황을 기록할 수 있으나 성능 저하가 크고 기록되는 이벤트 파일도 커서 특정 상황에서 분석을 주로 함

• 그래픽 드라이버들의 CPU 로드까지 같이 볼 수 있어서 게임 클라이언트만의 성능 측정으로 볼 수 없는 데이터를 볼 수 있음 – 동작 화면 http://www.youtube.com/watch?v=WeZazyXsp7o – 사용법

http://nvidia.custhelp.com/app/answers/detail/a_id/3507/~/generating-an-event-trace-log-for-gpuview

– MSDN http://msdn.microsoft.com/en-us/library/windows/desktop/jj585574(v=vs.85).aspx

Profiler


http://www.youtube.com/watch?v=WeZazyXsp7o



http://msdn.microsoft.com/en-us/library/windows/desktop/jj585574(v=vs.85).aspx

http://msdn.microsoft.com/en-us/library/windows/desktop/jj585574(v=vs.85).aspx

• Windows Performance toolkit에 포함된 뷰어 • 특정 시점의 GPU 및 CPU의 동작 상황을 시각화

– 특정 프로세스 뿐만 아닌 그래픽 카드를 포함한 전체 동작을 캡쳐 – 정보가 너무 많아 각 쓰레드별 디테일 정도를 변경해서 볼 수 있음 – 주기적으로 CPU가 수행 중인 코드의 스택을 샘플링을 해서 어떤 작업 중인지를 파악할 수 있음

• Tip – 5초 정도의 캡쳐에 1GB 넘는 파일 생성 및 머지 작업이 따름 – Windows 7 64bit 에서는 레지스트리에서 DisablePagingExecutive 필드를 1로 설정해야 크래시 발생하지 않음

– 한글윈도우에서는 systeminfo가 출력하는 내용이 한글로 되어 log.cmd를 수정해야 함

GPUView


Context CPU Q vs GPU hardware Q


• Context CPU Queue – GPU에서 처리될 그래픽 작업을 쌓아 둔 곳 – GPU는 여러 프로세스가 동시에 사용하므로 큐에 쌓인 시점과 실제 처리 시점과의 간격이 클 수 있다

– 빗금 패턴이 present 를 처리하는 DMA Packet을 나타냄

GPUView

Context CPU Queue

GPUView


쓰레드 분석

GPUView


Stack trace


• 주기적으로 스택 내용이 저장되어서 그 시점에 어떤 일을 하고 있는 지 알 수 있도록 함

GPUView

GPU가 바빠서 Queue 가득 찬 경우

GPUView


왜 마지막 단계로 인스트루먼트 방식인가? • 샘플링 방식

– 실행 전체 시간 중 병목지점을 파악하기에 간단함 – 소스 코드을 수정하지 않고 쉽게 적용할 수 있음 – 게임의 특성상 전체 동작 수행이 균일하지 않고 컨텐츠나 플레이 동선에 따라 다양한 변화를 보임

– 플레이의 순간적인 병목이나 장시간 플레이 시간 동안의 변화 추이를 파악할 수 없음

• 인스트루먼트 방식 – 모든 것을 샘플링하는 것에 비해 관심 있는 구간만 정확히 측정 가능 – 자동화된 인스트루먼트 툴은 전체 또는 특정 모듈을 계측하기 때문에 관심 구간을 지정하기 적합하지 않음

– 수작업으로 삽입한 매크로나 측정 코드의 결과를 장시간을 통해 추적하는 것이 중요하여 인스트루먼트 방식으로 남긴 로그를 시각화 해주는 상용 프로파일러를 선택


Telemetry 2

• 인스트루먼트 방식의 프로파일러 및 분석 도구 – 개발사 RAD Game Tools – Vink, Miles, Granny engine 등 게임에 특화된 라이브러리를 개발 및 판매하는 SW 개발 회사

• 특징 – 프로파일 데이터를 수집하는 서버와 성능 측정 및 데이터를 서버로 전송하는 클라이언트 측 라이브러리로 구분

– 실제 코드에 성능 측정 구간을 설정하는 함수를 삽입하여 성능 측정 – 수 십 분 이상 플레이 중의 프로파일링 결과를 저장하였다가 시각화하여 분석할 수 있음

– 인스트루먼트 방식의 프로파일링 기법이란 것을 감안하면 성능 저하가 그렇게 크지 않음 (10% 미만)


http://www.radgametools.com/kr/

기능

• 측정 방식 – 측정 구간의 시간을 측정하여 버퍼에 쌓아 두었다가 별도의 쓰레드에서 네트워크를 통해 데이터 수집 서버로 전달

– 같은 문자열을 서버로 반복적으로 보내지 않도록 문자열 관리를 함 – Enter와 Leave의 짝이 맞지 않으면 시각화 툴에서 그래프가 정확하게 나오지 않음

– 짝을 맞추기 어려운 코드에서는 Zone 함수를 사용하여 constructor부터 destructor가 호출되는 시점까지 시간을 측정 가능

– 한 함수 내에서 계층을 나누어 측정하고자 한다면 Enter/Leave 함수를 사용한다

– 같은 함수를 다른 쓰레드에서 호출하는 경우에는 해당 실행 정보를 별도의 쓰레드로 분리하여 시각화 한다

Telemetry


구성 팁

• 테스트 클라이언트와 수집 서버의 분리 – 여분의 PC가 없으면 테스트 프로그램을 실행하는 PC와 수집 서버를 같이 실행해도 됨.

– 실행 중에 로컬 HDD에 작은 파일로 데이터를 기록하였다가 종료 후 다시 합치는 작업을 함. 가급적 SSD를 사용할 것을 추천

– HDD 성능이 좋고 용량이 많아 공용 텔레메트리 서버를 띄우면 여러 PC에서 측정한 결과를 한 곳에서 모아서 기록하는 장점이 있음

– 비주얼라이저 툴은 서버의 데이터를 시각화를 할 뿐 프로파일링 데이터에서 특정 데이터를 검색하고 조건에 맞춰 추출하는 것은 서버가 함

Telemetry


실행 • 성능영향

– 샘플링 방식의 프로파일러에 비해서는 실행속도 저하가 있지만 2~10% 정도로 매우 크지 않다. 세밀하게 기록을 남기면 그 만큼 속도 저하가 커진다

– 데이터를 버퍼에 기록했다가 다 차면 별도의 쓰레드가 네트워크를 통해 서버로 데이터를 전달하는 방식이어서 네트워크를 모니터링해야 하는 상황이라면 서버를 같은 PC에서 띄우는 것도 고려해야 한다

• 기록 시간 – 기록하는 양이 적으면 10분 정도 테스트 시간에 2GB 정도의 데이터가 생성된다. 하지만 이 것은 세밀한 정도에 따라 크게 변한다

– 비교적 긴 시간의 프로파일링이 가능하기 때문에 클라이언트 초기화부터 데이터 로딩, 로그인, 맵 이동, 짧은 전투까지 플레이 전반에 대한 프로파일링 결과를 얻을 수 있어 거시적인 관점에서 최적화 포인트를 결정하는데 많은 도움이 된다

Telemetry


Instrument


• 측정하고자 하는 함수 첫머리 또는 구간에 측정 함수 삽입 • 한 프레임 끝을 알리는 함수를 프레임 루프 끝에서 호출

Telemtery

while (!done()) { { TMZONE(“Main loop”); DoWindowMessage(); DoGameUpdate(); DoRendering(); Present(); } TMTICK(); }

특정 구간 측정


while (!done()) { TMENTER(“Messages”); // 1 DoWindowMessage(); TMLEAVE(); // 1 TMENTER(“OnUpdate”); DoGameUpdate(); TMLEAVE(); TMENTER(“OnDraw”); DoRendering(); TMLEAVE(); TMENTER(“Present”); // 4 Present(); TMLEAVE(); // 4 TMTICK(); }

측정 데이터 시각화


Telemetry

구간 설정 방법

• 메인의 최상위 함수들부터 Top-down 방식으로 구간을 나눔 – Zone 객체를 선언하면 선언 시점부터 함수를 벗어날 때까지 시간 측정 – 의미 있는 작업 구간을 나누고자 하면 같은 함수 안에서라도 여러 개의

enter/leave 쌍으로 분리 – Enter로 시작하는 경우 구간을 벗어나는 곳이 여러 곳이면 빠지지 말고 모두 leave를 호출하도록 해야 그래프가 제대로 표시됨

– 루프 안에서 측정 구간을 선언하면 너무 많이 생성되므로 루프를 감싸는 구간을 지정하거나 일정 시간 이내는 결과를 남기지 않도록 지정

– 구간 설명은 짧고 다른 구간과 구별되도록 명칭을 지어야 함. – sprintf와 유사한 방식으로 메시지 출력을 할 수 있으므로 측정할 변수의 값을 같이 표시하는 것도 도움이 됨

– enter/leave 짝이 맞지 않는 것을 디버깅 하기 어려우므로 구간이 깨지면 미루지 말고 최근 수정한 부분 위주로 검토해 바로 해결하는 것이 좋음

Telemetry


분석

• 측정된 프레임들 중에서 대표적인 프레임을 선정 후 분석

Telemetry 2


멀티쓰레딩 프로파일링

• 멀티쓰레드 시각화 – 멀티쓰레드들을 같이 볼 수 있어 쓰레드의 함수에 실행 구간을 설정을 하면 원하는 함수들이 희망하는 순서로 동작했는지 확인 가능

– Wait 하는 함수들을 color:F04040 같은 칼라 태그를 이용해 눈에 띄게 하여 문제 지점을 파악


쓰레드 간의 lock 경쟁 관계 시각화

Telemetry 2


암달의 법칙 Amdahl’s law


• 여기서 복습하는 Amdahl’s law – 시스템에서 P 만큼의 부분을 동시처리를 해서 S 배 빠르게 하였을 때 전체 시스템의 성능 향상을 나타내는 법칙

– 전체 50%의 부분을 4배 빠르 게 하면 전체적으로 1.6배가 빨라진다. 하지만 아무리 빠르게 해도 2배 이상 빨라 질 수 없다

– 병렬화 비율이 전체 성능 향상의 최대 수치를 결정

암달의 저주

대개 CPU 병목인 프로그램들은…


• CPU 병목 프로그램들의 특징 – 멀티쓰레딩을 제대로 활용한 클라이언트 프로그램은 극히 소수. 병렬 프로그래밍이 어렵기 때문

– 대개는 싱글 쓰레드로 구현하고 파일 로딩이나 사운드, 네트워크 관련 부분만 쓰레드로 분리하여 처리

– DirectX 9의 API와 드라이버가 싱글쓰레드에 맞춰 구현되어 있기 때문에 draw 관련 작업은 한 쓰레드에서만 해야 함

– 싱글 쓰레드로 구현하는 것이 멀티 쓰레드로 구현하기는 것보다 쉽다 – 게임 로직 관련 부분과 draw 부분을 별도의 작업으로 분리하지 못하고 해당 객체를 로딩이 되었는지 체크하고 애니메이션 계산하고 바로 draw 하는 방식으로 구현하는 경우가 많음

Draw 쓰레드의 분리


• 한 가지 일만 시켜주세요 – 메인 쓰레드 작업에서 Draw 호출 관련한 부분은 직접 하지 않고 커맨드로 만들어 Draw 작업만 하는 쓰레드에서 처리

– 단순히 메인 쓰레드에서 Draw 작업 구간만 분리하는 것은 별 의미 없는 작업. Draw 쓰레드는 CPU를 최소한으로 사용하고 DirectX 호출만 하여야 한다

작업 구간의 병렬화


• 잘게 쪼개자 – 하지만 현실의 코드는 CPU와 GPU 사용이 잘 섞여 마블링된 상황 – Draw를 하지 않는 CPU 위주의 작업들을 골라 작은 태스크로 분리하고 공유하는 변수에 lock을 걸어서 동시에 접근하지 않도록 변경

같은 함수 두 번 호출하기


• Draw 관련 호출이 많은 코드는 글로벌 변수로 컨트롤을 하여 CPU 작업으로 한 번 호출하고 Draw 할 때 GPU 작업만을 처리 하도록 호출

• CPU 작업은 다른 쓰레드에서 먼저 실행을 하여 결과를 얻고 마지막 Draw 단계에서 다시 한 번 호출하여 그리기만 함

BOOL g_CPUJob = TRUE; HRESULT HardWorkFunction() { while (manyLoops) { if (g_CPUJob) ProcessCPUJobs(); else DrawGPUJobs(); } } Main thread Work thread 1 HardWorkFuction(); … … g_CPUJobs = FALSE; HardWorkFuction();

프레임 변동폭 줄이기

• Present – 직전까지 호출한 그래픽 관련 일들을 GPU가 처리하도록 하는 명령

Casestudy


Present 시간을 아껴보자

• 그래픽 카드에 따라서는 무척 긴 경우도 있다 – 매 프레임 별 작업량이 달라 변동폭이 크다

• Present를 하는 동안 다음 프레임 처리로 넘어가면 어떨까? – Present를 처리하는 동안 그래픽과 관련된 함수 호출을 하지 않고 그래픽 리소스 생성 등의 작업을 하지 않으면 된다.

– 간섭이 일어나면 Present 내부의 lock과 경쟁을 하게 되어 Present가 끝날 때까지 대기하거나 반대로 다른 작업이 끝날 때까지 Present가 길어진다

– 마우스 커서 관련한 함수 호출도 그래픽과 관련된 함수 (DX10+) – present가 끝나면 미뤄둔 그래픽 관련 작업을 처리한다


쓰레드 분리


하지만 AMD 그래픽카드에서는

• AMD 그래픽카드에서는 Present 시간이 1ms 이내(DX11)


AMD on DX9

• AMD 그래픽카드에서 DX9으로 실행하면 4ms 정도까지 변화가 있지만 프레임의 시간은 무척 안정적


DirectX 호출은


• 드라이버는 GPU에 전달하기 전에 많은 계산을 한다 – 별도의 드라이버 쓰레드를 생성하여 백그라운드로 계산을 한 후에

GPU호출을 함 – AMD 드라이버의 경우 코어 수의 1.5배의 쓰레드가 처리. 특히 AMD의 CPU 경우 여러 쓰레드로 실행하는 것이 효율적

– NVIDIA도 1 ~ 1.5배의 쓰레드 생성

• DirectX 호출도 몰아서 하지 말고 전 프레임에 걸쳐 조금씩 분산해 호출하는 것이 드라이버의 CPU 사용에 유리

Present 와 DMA Packet 발생 시점

GPUView


바쁜 그래픽 드라이버


주기적인 프로파일링

• 프로파일링은 반복적으로 해야 – 마일스톤이나 중간 점검 이후에 안정된 리소스를 가지고 프로파일링과 최적화를 진행하는 것이 필요

• 프로파일링 과정 – 프로파일링할 때의 제약 조건의 기준을 세움 – 목적에 맞는 프로파일링 도구 선정 – 프로파일링을 통해 최적화 후보 지점 선정 및 우선 순위 결정 – 최적화가 끝나고 나면 프로파일링을 통해 개선 정도를 측정한다. – 제약 조건들을 바꾸고 프로파일링을 해서 최적화 방향의 적용 범위를 넓힌다


Wrap-up


• 왕도는 없다 – 프로그래머는 ‘방망이 깎던 노인’ – 끝난 것 같아도 주기적으로 테스트하고 분석해 무너진 밸런스를 잡아야 함

– 조그만 코드 수정이나 리소스 구조의 변경, 지형 데이터 수정 등이 병목 지점을 변화 시킴

– 처음부터 구조가 잘 잡혔다면 변화에 강하지만 막바지에 급하게 최적화 작업한 코드들은 변화에 취약.

– 매번 강조하지만 처음부터 잘 설계해야 한다. (하지만 개발 기간이…)

다양한 환경에서 테스트

• 최적화는 일반화의 반대 – 최적화는 제약 조건 하에서 이루어지기 때문에 프로파일링 한 결과를 일반화 시켜서 적용하지 말아야 한다

– 제약 조건이 다른 시스템에서는 다시 프로파일링을 하였을 때 다른 패턴이 나올 수 있음

– 그래픽 카드 회사에 따라 각 벤더에 맞는 최적화 코드를 추가 – 드라이버 버전에 따라서도 크게 동작이 달라질 수 있기 때문에 드라이버 버전 번호 체크를 하여 최적화 기능을 선택적으로 적용

Wrap up


Q&A

• Twitter 망치와 모루 @nvil @jongwonkim


KGC 2014 프로파일러를 이용한 게임 클라이언트 최적화

Software

Transcript of KGC 2014 프로파일러를 이용한 게임 클라이언트 최적화