게임프로젝트에 적용하는 GPGPU

유영천

프리랜서

Twitter:@dgtman

GPGPU(General-Purpose computing on GPU

• GPU를 사용하여 CPU가 젂통적으로 취급했던 응용프로그램들의 계산을 수행하는 기술

• GPU 코어 1개의 효율은 CPU 코어 1개에 비해 많이떨어지지만 코어의 개수가 엄청나게 많다.

• 많은 수의 코어를 사용하면 산술술 연산성능(Throughput)은 CPU의 성능보다 훨씬 뛰어나다.

GPU H/W

GK110의 블럭다이어그램 – 15 core CPU에 상응

SM CPU Core

SM CPU Core

2인 3각경기를연상하시라~

GPGPU의 특징

강점

• 엄청난 수의 스레드를 사용할수 있다.

• 부동소수점 연산이 엄청빠르다.

• 컨텍스트 스위칭이 엄청빠르다.

• 그래서 충분히 병렬화된산술처리에는 짱.

약점

• 흐름제어가 per SM으로이루어진다.(2인3각 경기)

• 흐름제어 성능이 CPU에 비해많이 떨어진다.

• 프로그래밍 기법의제약(재귀호출불가)

• Core당 클럭이 CPU에 비해 많이느리다(1/4 – 1/3수준)

적용분야

• Physics Simulation

• Video Processing

• Image Processing

• Astrophysics

• Medical Imaging

• More…

적용분야(for 일반인)

• Video Encoding/Decoding

• Game

– PhysX

– Megatexturing

– Compute Shader를 이용한 렌더링 보조

사용가능한 S/W제품들

• nvidia CUDA

• Microsoft AMP C++

• Open CL

• Direct X Direct Compute Shader

2885x4102크기의 이미지에 5x5 Gaussian Blur를 3회 적용

Image Processing 예제

참고)

이미지 필터링 코드는 CUDA, CPU 완젂 동일.

알고리즘상의 최적화는 없음.

병렬처리 효율의 비교를 위한 테스트임.

성능비교Device Time(ms)

1Threads - Intel i7 2600K @3.8GHz 10054.3

8Threads - Intel i7 2600K @3.7GHz 2247.8

CUDA - GTX480 (15 SM x 32 Core = 480 Cores) 80.50

CUDA – GTX TITAN (14 SM x 192 Core = 2688 Cores) 59.92

GPGPU + 게임 프로젝트

+

GPGPU를 게임 프로젝트에 적용할 수없을까?

• GPU의 엄청난 성능을 썩히고 싶지 않아!!!

• 병렬처리가 가능하면 좋을 것 같다는 느낌이 올때가 있다.

– Light map 구우면서 꾸벅꾸벅 졸 때.

– 서버에서 충돌처리를 하는데 CPU점유율이 98%

– Xeon 8 core CPU는 너무 비싸!!!

게임 프로젝트 적용의 난점

• 유져의 장비가 GPGPU를 지원한다는 보장이없다.(CUDA는 오로지 nvidia제품만 지원한다.

• 게임코드의 대부분은 의존성이 강하다. 즉병렬처리에 적합하지 않다.

• 디버깅이 어렵다.

• 유져의 장비가 GPGPU를 지원한다는 보장이 없다.(CUDA는오로지 nvidia제품만 지원한다.

– 게임 서버나 툴에서 사용한다.

– 게임 클라이언트에는 Direct Compute Shader를 사용한다.

• 게임코드의 대부분은 의존성이 강하다. 즉 병렬처리에적합하지 않다.

– 병렬처리 할 수 있는 영역을 찾아보자.충돌처리라든가.

• 디버깅이 어렵다.

– CUDA + Parallel NSight를 사용한다.

그래도 게임프로젝트에 적용해보자.

CUDA (Compute Unified Device Architecture)

• C언어 등 산업 표준 언어를 사용하여 GPU에서작동하는 병렬처리 코드를 작성할 수 있도록 하는GPGPU기술

• nvidia가 개발,배포.그래서 nvidia GPU만 가능.

• PhysX,APEX,NVEncoder등 nvidia의 API들이 CUDA를사용.

CUDA의 장점

• 자료가 많다.

• 유일하게 GPU상에서의 디버깅이 가능하다.

• C/C++에서의 포팅이 쉽다.

• 현재 나와있는 제품 중 가장 앞서있다.

– Dynamic parallelism, Hyper-Q, Unified Virtual Addressing,…

실제로 적용하기

Server-Based 충돌처리

서버에서 충돌처리를 하면 좋은 점

• 위치,속도 Hack의 원첚 봉쇄

• 서버측에서 능동적으로 이것저것 하기 좋음

• 정밀한 위치 추척 가능(30,60프레임 단위로 처리 가능)

• 클라이언트에서 플레이어 제어하듯 서버에서도플레이어,NPC,몬스터의 이동을 프로그래밍 가능.

CPU->GPGPU의 장점

• Throughput과 Responsibility를 향상시킨다.• 비용을 줄인다

– [xeon급 이상에 한해서] 2배 성능의 CPU로업그레이드 하는 것보다 2배 성능의 GPU로 GPU로업그레이드 하는 편이 훨씬 싸다.

• 확장성이 좋다. GPU업그레이드에 따라 코드를(거의) 수정하지 않아도 된다.

• 서버의 CPU자원을 남겨둘 수 있다.

구현 포인트

• 게임 오브젝트는 -> 타원체• 건물,지형 -> 삼각형 집합• 타원체 -> 1 Block에 대응• Block내의 스레드들이 협력하여 충돌검출 및 리액션 처리• Ex)

– 미끄러짐 예제– 반사 예제– 게임 클라이언트 적용 예제1– 게임 클라이언트 적용 예제2

Thread

Thread

Thread

Thread

Thread

Thread

Thread

Thread

Thread

Thread

Thread

Thread

Thread

Thread

Thread

Thread

Thread

Thread

Thread

Thread

Thread

Thread

Thread

Thread

Thread

Thread

Thread

Thread

Thread

Thread

1

2

3

4

5

6

7

1

2

3

4

5

1

2

3

1

7

5

3

1

1 Obj -> 1 Block

Block Block Block Block

1

2

3

4

5

5

1

2

3

4

5

6

1

2

3

성능

• 테스트 조건

– 타원체 약 8000개

– 삼각형 77760개

– 타원체 VS 타원체, 타원체 VS 삼각형

– 유휴시갂 없이 최대프레임으로 충돌처리를수행. 한벆 충돌처리에 걸리는 시갂 측정.

CPU i7 2600K (8Threads @3.7GHz) – 120msCUDA GTX480 – 40ms (CPU대비 약 3배)

Baking Light Maps

Baking Light Maps

• 건물,지형등 정적인 매시에 대해서 라이팅된상태를 텍스쳐에 구워놓는다.

• Ambient Occlusion이나 Radiosity를 적용하려면baking시갂이 엄청나게 오래 걸릮다.

• 텍셀갂 의존성이 거의 없고 throughput이중요하므로 GPGPU로 처리하기에 매우적합하다.

구현 포인트

• 게임의 맵에서 정적 라이트를 표현하는 Light Map을CPU가 아닌 GPGPU(CUDA)로 굽는다.

• Directional Light, Omni Light계산 후 Radiosity로난반사를 처리한다.

• Scene을 미리 KD-Tree로 만들어둔다.CUDA Global Memory상에서 Tree를 빌드하는 것이 까다로울 수있다.

• Texel당 CUDA 1 Thread로 처리한다.• KD-Tree Traversal참고

성능

• 테스트 조건

– Light Map의 Texel수 = Patch수 = 386918개

– Directional Lighting후 1 pass Radiosity처리에걸리는 시갂 측정

Device Time(ms)

GTX TITAN 17656ms

GTX 480 18297ms

GTX 460 35219ms

CPU i7 2600K 8 threads@3.7GHz 3513564ms추정(1/3처리에1171188ms소요)

시연

H/W Occlusion Culling – Compute Shader

Occludee

Occludee

Occluder

Occlusion Culling

• 가려진 물체를 그리지 말자.

• Occluder가 Occludee를 가림

• 건물 벽에 가려서 안보이는 캐릭터..라든가.

Occludee

Occludee

Occluder

기본원리

• Occluder(raw맵 데이타나 거의 꼭 맞는바운딩매쉬)를 그려서 Z-Buffer를 구성한다.

• Occludee(아마도 캐릭터나 맵데이타,기타 배치가능한 오브젝트)를 그리되 pixel은 write하지않고 z-test만 한다.

• 그려지는 픽셀 수를 GPU측 메모리에기록해둔다.

• 나중에 GPU로부터 픽셀수를 얻어온다.

구현 포인트

• 갂략화된 Occluder매시(건물,산 등)를 z-buffer에그릮다.

• Z-buffer의 mip-chain을 생성한다.• Occludee의 경계구 목록을 Compute Shader로

넘긴다.• Compute Shader에서 Occludee 경계구의 사이즈에

맞는 z-map을 선택하고 z값을 비교한다.• Compute Shader에서 버퍼에 저장한 결과를

CPU측에서 읽어온다.

Compute Shader사용의 장점

• 다수의 Occludee에 대해 병렬적으로 Z-Test를수행할 수 있다.

• Z-Buffer에 Lock을 걸어서 메모리로 읽어오지않아도 된다.(속도 차이가 엄청나다!)

성능

<입력 오브젝트 대략 700개일때>

Method Objects FPS

No Occulusion Culling 376 430

D3DQuery Occlusion Culling 31 561

Hierarchical Z Map Occlusion Culling – Compute Shader

31 713

테스트하는 Occludee 개수가 많아질수록 격차가 더 커짐

시연

A* 길찾기

길찾기 서버를 만들면 어떨까?

구현 포인트

• 8방향 길찾기에서 8방향에 대해 각각 8 threads씩 대응.

• 각 thread는 F,G,H값을 구하고 Open List와Closed List에 넣고 빼는 작업을 병렬로 처리

성능

• CPU와 비슷하거나 더 느림.

• 망한 사례(T_T)

• 성능 향상의 여지는 있으므로 연구 가치 있음.

• 길찾기 서버로 사용한다면 서버의 CPU자원을확보할 수 있다.

기타응용

• NVEncoder를이용한 실시갂h264인코딩

• Voxelization

결론

GPU랑 CPU랑 어느게 빨라요?

그때 그때 달라요~

병렬화에 적합한지를 따져보자

부적합한 경우

• 분기가 많다.

• 각 요소들의 의존성이높다.(병렬화 하기 나쁘다)

• Throughput보다Responsibility가중요하다.(100ms or 50ms에 목숨을 건다!)

적합한 경우

• 코드에서 분기가 적다.

• Image Processing처럼 각요소들의 의존성이 낮다. – (병렬화 하기 좋다.)

• Throughput이 중요한경우.(3일걸리던 작업을1일로 줄였다!!!)

GPGPU적용시 고려사항

• 용도 – 병렬화에 적합한지

• 비용 – CPU vs GPU추가 비용

• 유지보수 – 디버깅과 코드 작성 비용

• 확장성 – CPU추가 or GPU업그레이드시성능향상폭

참고문헌

• CUDA– Programming Massively Parallel Processors (David

B.Kirk , Wen-mei W. Hwu)

– nvidia GPU Computing SDK 5.0 Documents

• H/W Occlusion Culling– http://www.nickdarnell.com/2010/06/hierarchical

-z-buffer-occlusion-culling/

Q/A