2. GPGPU(General-Purpose computing on GPU
• GPU를 사용하여 CPU가 젂통적으로 취급했던 응용
프로그램들의 계산을 수행하는 기술
• GPU 코어 1개의 효율은 CPU 코어 1개에 비해 많이
떨어지지만 코어의 개수가 엄청나게 많다.
• 많은 수의 코어를 사용하면 산술술 연산
성능(Throughput)은 CPU의 성능보다 훨씬 뛰어나다.
7. GPGPU의 특징
강점
• 엄청난 수의 스레드를 사용할
수 있다.
• 부동소수점 연산이 엄청
빠르다.
• 컨텍스트 스위칭이 엄청
빠르다.
• 그래서 충분히 병렬화된
산술처리에는 짱.
약점
• 흐름제어가 per SM으로
이루어진다.(2인3각 경기)
• 흐름제어 성능이 CPU에 비해
많이 떨어진다.
• 프로그래밍 기법의
제약(재귀호출불가)
• Core당 클럭이 CPU에 비해 많이
느리다(1/4 – 1/3수준)
14. GPGPU를 게임 프로젝트에 적용할 수
없을까?
• GPU의 엄청난 성능을 썩히고 싶지 않아!!!
• 병렬처리가 가능하면 좋을 것 같다는 느낌이 올
때가 있다.
– Light map 구우면서 꾸벅꾸벅 졸 때.
– 서버에서 충돌처리를 하는데 CPU점유율이 98%
– Xeon 8 core CPU는 너무 비싸!!!
15. 게임 프로젝트 적용의 난점
• 유져의 장비가 GPGPU를 지원한다는 보장이
없다.(CUDA는 오로지 nvidia제품만 지원한다.
• 게임코드의 대부분은 의존성이 강하다. 즉
병렬처리에 적합하지 않다.
• 디버깅이 어렵다.
16. • 유져의 장비가 GPGPU를 지원한다는 보장이 없다.(CUDA는
오로지 nvidia제품만 지원한다.
– 게임 서버나 툴에서 사용한다.
– 게임 클라이언트에는 Direct Compute Shader를 사용한다.
• 게임코드의 대부분은 의존성이 강하다. 즉 병렬처리에
적합하지 않다.
– 병렬처리 할 수 있는 영역을 찾아보자.충돌처리라든가.
• 디버깅이 어렵다.
– CUDA + Parallel NSight를 사용한다.
그래도 게임프로젝트에 적용해보자.
17. CUDA (Compute Unified Device Architecture)
• C언어 등 산업 표준 언어를 사용하여 GPU에서
작동하는 병렬처리 코드를 작성할 수 있도록 하는
GPGPU기술
• nvidia가 개발,배포.그래서 nvidia GPU만 가능.
• PhysX,APEX,NVEncoder등 nvidia의 API들이 CUDA를
사용.
18. CUDA의 장점
• 자료가 많다.
• 유일하게 GPU상에서의 디버깅이 가능하다.
• C/C++에서의 포팅이 쉽다.
• 현재 나와있는 제품 중 가장 앞서있다.
– Dynamic parallelism, Hyper-Q, Unified Virtual
Addressing,…
21. 서버에서 충돌처리를 하면 좋은 점
• 위치,속도 Hack의 원첚 봉쇄
• 서버측에서 능동적으로 이것저것 하기 좋음
• 정밀한 위치 추척 가능(30,60프레임 단위로 처리 가능)
• 클라이언트에서 플레이어 제어하듯 서버에서도
플레이어,NPC,몬스터의 이동을 프로그래밍 가능.
22. CPU->GPGPU의 장점
• Throughput과 Responsibility를 향상시킨다.
• 비용을 줄인다
– [xeon급 이상에 한해서] 2배 성능의 CPU로
업그레이드 하는 것보다 2배 성능의 GPU로 GPU로
업그레이드 하는 편이 훨씬 싸다.
• 확장성이 좋다. GPU업그레이드에 따라 코드를
(거의) 수정하지 않아도 된다.
• 서버의 CPU자원을 남겨둘 수 있다.
23. 구현 포인트
• 게임 오브젝트는 -> 타원체
• 건물,지형 -> 삼각형 집합
• 타원체 -> 1 Block에 대응
• Block내의 스레드들이 협력하여 충돌검출 및 리액션 처리
• Ex)
– 미끄러짐 예제
– 반사 예제
– 게임 클라이언트 적용 예제1
– 게임 클라이언트 적용 예제2
28. Baking Light Maps
• 건물,지형등 정적인 매시에 대해서 라이팅된
상태를 텍스쳐에 구워놓는다.
• Ambient Occlusion이나 Radiosity를 적용하려면
baking시갂이 엄청나게 오래 걸릮다.
• 텍셀갂 의존성이 거의 없고 throughput이
중요하므로 GPGPU로 처리하기에 매우
적합하다.
29. 구현 포인트
• 게임의 맵에서 정적 라이트를 표현하는 Light Map을
CPU가 아닌 GPGPU(CUDA)로 굽는다.
• Directional Light, Omni Light계산 후 Radiosity로
난반사를 처리한다.
• Scene을 미리 KD-Tree로 만들어둔다.CUDA Global
Memory상에서 Tree를 빌드하는 것이 까다로울 수
있다.
• Texel당 CUDA 1 Thread로 처리한다.
• KD-Tree Traversal참고
30. 성능
• 테스트 조건
– Light Map의 Texel수 = Patch수 = 386918개
– Directional Lighting후 1 pass Radiosity처리에
걸리는 시갂 측정
36. 기본원리
• Occluder(raw맵 데이타나 거의 꼭 맞는
바운딩매쉬)를 그려서 Z-Buffer를 구성한다.
• Occludee(아마도 캐릭터나 맵데이타,기타 배치
가능한 오브젝트)를 그리되 pixel은 write하지
않고 z-test만 한다.
• 그려지는 픽셀 수를 GPU측 메모리에
기록해둔다.
• 나중에 GPU로부터 픽셀수를 얻어온다.
37. 구현 포인트
• 갂략화된 Occluder매시(건물,산 등)를 z-buffer에
그릮다.
• Z-buffer의 mip-chain을 생성한다.
• Occludee의 경계구 목록을 Compute Shader로
넘긴다.
• Compute Shader에서 Occludee 경계구의 사이즈에
맞는 z-map을 선택하고 z값을 비교한다.
• Compute Shader에서 버퍼에 저장한 결과를
CPU측에서 읽어온다.
38. Compute Shader사용의 장점
• 다수의 Occludee에 대해 병렬적으로 Z-Test를
수행할 수 있다.
• Z-Buffer에 Lock을 걸어서 메모리로 읽어오지
않아도 된다.(속도 차이가 엄청나다!)
39. 성능
<입력 오브젝트 대략 700개일때>
Method Objects FPS
No Occulusion Culling 376 430
D3DQuery Occlusion Culling 31 561
Hierarchical Z Map Occlusion Culling
– Compute Shader
31 713
테스트하는 Occludee 개수가 많아질수록 격차가 더 커짐
48. 병렬화에 적합한지를 따져보자
부적합한 경우
• 분기가 많다.
• 각 요소들의 의존성이
높다.(병렬화 하기 나쁘다)
• Throughput보다
Responsibility가
중요하다.(100ms or
50ms에 목숨을 건다!)
적합한 경우
• 코드에서 분기가 적다.
• Image Processing처럼 각
요소들의 의존성이 낮다.
– (병렬화 하기 좋다.)
• Throughput이 중요한
경우.(3일걸리던 작업을
1일로 줄였다!!!)
49. GPGPU적용시 고려사항
• 용도 – 병렬화에 적합한지
• 비용 – CPU vs GPU추가 비용
• 유지보수 – 디버깅과 코드 작성 비용
• 확장성 – CPU추가 or GPU업그레이드시
성능향상폭
