모바일 게임 제작시 메모리 대역폭

1. Mobile Memory 대역폭
2018/10 - Spotlight

2. 목차
• 하드웨어
• 4년간 모바일 하드웨어 변화
• 게임에서 메모리 대역폭이 중요한 이유
• 게임에서 대역폭 사용 전략
• 안드로이드 메모리 구조
• 프로파일링
• 미래 메모리 하드웨어 구조 ( hUMA - HSA )

3. 메모리란?
• 프로세스( CPU / GPU / DSP / ISP )가 연산을 위한 데이터 장소
• 가장 가까운 메모리 L1, L2, L3, 외부 메모리로 접근한다.
• 외부 메모리는 접근 속도(메모리 대역폭)가 느리다.
• 모든 기기설계에서 프로세스 와 메모리대역과 양은 밸런스를 맞춘다.
• 모바일 빼고…. ( 전력문제로 불가능 )

4. PC와 다른점
• 컴퓨터
• 고사양은 별도 GPU + VRAM 을 가진 외장그래픽 장착
• 저사양은 CPU + GPU 통합된 APU (내장형그래픽)
• UMA 구조로 메인램의 일정부분을 미리 나누어서 GPU용으로 정적으로 구분
• CMOS 에서 설정
• 모바일
• 모든 프로세서가 하나의 칩에 존재 ( SOC = CPU + GPU + DSP + ISP )
• UMA구조로 하나의 메모리만 존재하고 모든프로세스들이 동적으로 같이 사용
• 프로세스들은 각자 MMU을 가지고 DMC를 통해 물리적 메모리 접근
• 최근에서 프로세스 MMU와 DMC 의 연결비트폭을 다르게 주어 GPU에 힘을 준다.
MMU : 버추얼 메모리 > 피지컬 메모리 주소 맵핑
DMC : 다이나믹 메모리 컨트롤러

5. 모바일 UMA 메모리 하드웨어 구조
각 프로세스를 하나의 프로그램으로 생각하면 MMU는 각 프로그램의 버추얼 메모리 테이블

6. 하드웨어 변화
2014년 저가 2018년 저가 2014년 중급 2018년 중급 2014년 고가 2018년 고가
SOC Snap 410 Snap 435 Snap 615 Snap 630 Snap 805 Snap 845
GPU Adreno 306
21.6 GF
Adreno 505
48.6 GF
Adreno 405
59.4 GF
Adreno 508
170 GF
Adreno 420
144~172.8 GF
Adreno 630
727 GF
메모리대역폭 Single/32bit/533Mhz/
4.2GB
Single/32bit/667Mhz/
5.33GB
Single/32bit/800Mhz/
6.4GB
Dual/32bit/667Mhz/
10.66GB
Dual/64bit/800Mhz/
25.6GB
Dual/64bit/933Mhz/
29.9GB
• 4년동안 고가형 기준으로 GPU 연산력은 500% 높아졌지만 대역폭은 17%밖에 높아지지 않았다.
• CPU 역시 연산력이 높아져 전보다 메모리를 더 많이 쓴다.
• 비대칭구조로 인한 부족한 대역폭을 해결하는 방향으로 발전
• Tiled 방식, 얼리Z
• 캐시메모리를 증가

7. 게임에서 메모리 대역폭
• 게임은 2~4개의 CPU 코어와 GPU가 동시에 한개의 메모리 버스 이용
• 단순무식한 가정
• 500Mb 의 메모리를 쓰는 게임이 초당 60프레임일때 메모리대역 사용량은?
• 500mb x 60fps = 30 G/s
• 후처리(Post Process) 가볍게 몇개 켜주시면
• 1920 x 1080 x 4 x 60 fps x ??? = ??
• 어제나온 최신기기도 29 G/s 였는데….

8. 게임에서 메모리 대역폭
• 모바일 GPU 연산력은 PS3( 192 GF/s )를 넘어 PS4( 1843 GF/s ) 에 근접
• 하지만 대역폭은 PS4 ( 176 GB/s )가 아니라 PS3 ( CPU전용 약15 GB/s + GPU전용 22.4 GB/s ) 에도 못 미친다.
• 연산을 빛의 속도로 계산해도 이미 램대역폭에서 병목
• CPU/GPU 연산력이 느린건지 메모리대역폭때문인지 개발자가 알 방법이 없다.
• 테스트를 통한 추측과 통계로 최적화
• 위 이유로 모바일에서는 Deferred 가 불가능
• 1920 x 1080 x 8 x 4 Msaa x 60 fps 기본 프레임버퍼
• 1920 x 1080 x 4 x 3장(deferred MRT) x 60 fps ( 엄청난 텍스처 샘플링…즉 대역폭 소모 )
• Tiled 구조에서 쥐약인 반복되는 FBO 스왑 ( 모든 타일버퍼 플러쉬 )

9. 게임에서 메모리 전략
• 프로파일링을 피처 단위로 하지말자.
• 공유자원(램대역)때문에 다른기능 성능에 영향 ( cpu로직/ui/사운드/io/후처리/gpu/네트워크 )
• 개별적 기능 프로파일링이 의미가 PC와 같지 않다. ( ex: 테스트씬에서는 빨랐는데? )
• 메모리 대역을 많이 쓰는 것보다 연산을 많이 쓰는게 오히려 빠를수도 있다. (최신기기일수록)
• 텍스처 스트리밍을 적극 사용
• 2018.2 부터 가능, 밉맵을 작은것부터 로드하여 업로딩을 절약한다. 샘플링은 동일.
• 모바일에서 사용하기위해서는 APK를 LZ4 로 빌드필요
• 너무 작은 버짓을 설정하면 오히려 독이 된다. ( 자주 텍스처를 올리고 내린다. )
• 모바일에서 다이나믹 배칭은 DrawCall 이득보다 램대역폭과 cpu오버로드가 더 클 경우가 많다.

10. 안드로이드 메모리 관리
• 메모리 페이지는 3가지 종류
• Used Pages - 사용되고 있는 메모리
• Cached Pages - 사용되었다가 사용안하고 있어서 캐싱되어있는 페이지
• Free Pages - 사용되고 있지 않는 메모리
• 모든 App 은 3가지의 램사이즈가 존재
• RSS( Resident Set Size ): App에서 사용되는 모든 메모리 사이즈, 다른 App과 공유해서 사용하는 영역포함
• PSS( Proportional Set Size ): RSS에서 다른 App와 공유해서 사용하는 영역을 공유숫자로 나누어서 계산
• USS( Unique Set Size ): App만 쓰는 메모리 영역
• OS는 메모리가 부족해지면 PSS 기준으로 사용량과 중요도를 계산해 앱을 죽이고 메모리 확보

11. 게임의 사용 메모리 보기 ( PSS )

12. 유니티 메모리 프로파일러(simple)
• Total - streaming데이타(Video, FMOD) 와 Profiler를 제외한 총 사용 메모리
• Unity - 유니티 엔진에서 사용하는 메모리(c++)
• Mono - 모노런타임에 할당된 메모리(c#)
• GfxDriver - 렌더타겟을 제외한 텍스처 메모리만 표시
• 그래픽드라이버가 사용하는 비디오램이 아니다. 쉐이더나 다른 버퍼X
• FMOD - 사운드 파일 용량
• Video - 비디오파일로 사용하는 메모리
• Profiler - 프로파일러가 사용하는 메모리
Used / Reserved - 현재 쓰는 / 확보한 메모리 용량 ( OS에 자주 메모리 할당을 하지않기 위해 버퍼를 확보하여 놓는다.)

13. 유니티 메모리 프로파일러 한계
• 코드메모리와 라이브러리 메모리를 표시하지는 않는다.
• 프로파일러는 오직 어플에서 할당한 메모리만 표시한다.
• 컴퓨터의 Editor에서 메모리 프로파일러는 실기기와 다르다.
• 텍스처 압축포맷이 다르다.
• Editor와 플랫폼간의 다른 로직 ( #if UnityEditor )
• 꼭 실기빌드를 가지고 프로파일링 하자

14. 메모리 프로파일러(detail)
• Other - 밑의 항목 들 제외한 모든 사용량
• Assets - Scene/Resources/AssetBundles 등을 통해 로드 된 모든 에셋들
• Builtin Resources - 유니티에서 사용하는 기본 로드되는 리소스 + Editor에서 사용하는 리소스
• Scene Memory - 게임오브젝트와 컴포넌트가 쓰는 메모리
• Not Saved - DontSave 가 설정된 게임오브젝트들

15. 메모리 프로파일러 익스텐션
• 훨씬 강력한 메모리 프로파일러로 모든 레퍼런스 카운트와 오브젝트를 찾아 디테일한 분석
• Version 1
• https://bitbucket.org/Unity-Technologies/memoryprofiler
• 5.6 이상 유니티 버전 필요
• Version 2
• 2018.3 이상 유니티 버전 필요
• 현재(2018.10월) JSON 파일 직접 수정해서
설치해야함
• 위치: 프로젝트폴더/Packages/manifest.json

16. UMA 구조 발전
• hUMA - 각 프로세스가 메모리 주소를 공유하여 메모리사용량과 대역, 큐잉 모두 절약
• hUMA 현재 상황
• AMD와 퀄컴에서 밀고있는 HSA규격이 가장 발전함
• 인텔은 브로드웰부터 Shared Virtual Memory 로 독자 규격 만듬
• Nvidia ???
• CPU < > GPU 간의 메모리 제로 카피가능
• 그래픽드라이버가 버퍼를 생성하고 포인터로 카피

17. HSA
• AMD가 최초 개발하여 퀄컴과 함께 개발하는 표준
http://www.hsafoundation.com
• AMD GCN구조인 Kaveri 가 최초로 PS4/XBOX 에 쓰임
• 2015년에 1.0 ver ( 현재 1.1 ver )
• 삼성칩은 G71 gpu가 달린 Exynos8895 부터 ( 2017년 )
• 스냅드래곤은 아직 정확한 지원여부 확인X
• 하드웨어, 소프트웨어 둘다 지원 필요
• 현재 게임기, OpenCL, CUDA 등을 통해서만
hUMA 이득을 얻음
• 모바일 게임에서는 아직 사용X

18. Reference
• https://www.slideshare.net/linaroorg/hsa-linaro-updatejuly102013 (HSA Overview)
• http://www.hsafoundation.com
• https://www.slideshare.net/InformaticaUCM/programming-models-for-heterogeneous-chips
• https://legacy.iis.ee.ethz.ch/~gmichi/asocd/lecturenotes/Lecture10.pdf

19. Thank you