opengl es 스터디를 진행하면서 타일 베이스 렌더링에 대한 이야기가 나와서 해당 렌더링이 어떤 방식인지 정리해 보려고 한다.
1. 목적
* 원래 그래픽 카드의 발전 방향 : 더 용량이 큰 그래픽을 얼마나 고속으로 처리하는지.
* 모바일 기기의 그래픽 카드 : 가장 큰 이슈는 전력 소모(전원이 항상 연결되어있지 않음)+칩셋의 물리적 크기(휴대 용이)+발열(쿨러 장착 불가)
--> 이러한 모바일 기기의 특징을 반영해서 Tile Based Rendering이란 렌더링 방식을 사용.
2. 데스크탑 렌더링 과정
* opengl에서 드로우콜 날리기
* 지오메트리 데이터가 버텍스 쉐이더를 거쳐 트랜스폼.
* 이후 레스터화된 후 픽셀 쉐이더로 넘어가 픽셀 컬러를 거침.
* 픽셀 쉐이더 결과물 -> 프레임 버퍼로 출력. (선택적 블렌딩 처리)
--> 드로우콜의 명령~프레임버퍼 과정 : 1번의 패스+매번 프레임버퍼 영역 전체가 갱신. = 드로우콜 1번으로 화면 전체 렌더링 가능.
(Immediate Mode Rendering)
3. 모바일 렌더링 과정
* 대역폭 : 전력 소모+물리적 크기 해결 위해 가장 큰 고려 사항.
- 대역폭 넉넉할 경우 : 전력소모 심해짐+물리적 칩셋 크기가 커짐->발열->쿨러 부재.
--> Tile Based Rendering
- 드로우콜마다 프레임버퍼 갱신 : 높은 메모리 대역폭.
-> 프레임버퍼 전체 매번 업데이트가 아닌 타일 단위로 쪼개서 갱신.
--> 드로우콜 발생->칩셋에 내장된 메모리에 존재하는 타일에 렌더링->실제 도형이 그려지는 타일만 렌더링.
3.1. 모바일 렌더링 과정
* 프레임버퍼를 일정 크기의 타일로 영역을 나눔.(타일 크기-칩셋 벤더마다 차이 존재.)
* 드로우콜 발생
* 지오메트리 데이터가 버텍스 쉐이더 거쳐 트랜스폼.
* 이후 레스터화.
* 버텍스 쉐이더의 결과가 픽셀 쉐이더로 넘어가지 않고 타일 선택 과정 추가.
* 픽셀 쉐이더 수행, 칩 내부 버퍼에 존재하는 타일에 그려짐.
* 타일 완성되면 프레임버퍼에 그려짐.
-> 적은 대역폭으로 화면 렌더링 가능.
3.2. Tile Based Deferred Rendering
* TBR에서 파생된 방식.
* 기본은 TBR.
* 버텍스 쉐이더에서 트랜스폼 연산 후 해당 결과를 파라미터 버퍼에 저장.
(파라미터 버퍼는 ImgTec에서만 통용되고, ARM은 폴리곤 리스트인 등 여러 이름 존재.)
* 버퍼에 담고, 매 드로우콜마다 버텍스 쉐이더의 결과를 계속 저장.
* 모든 드로우콜이 끝나면 타일 렌더링 후 프레임 버퍼에 출력.
--> 한 타일에 들어오는 모든 폴리곤 한번에 처리 가능.
--> 픽셀 오버드로우 발생 x. (각 픽셀의 은면제거(앞의 객체/가려진 면 제거, Hidden Surface Removal)가 처리되고 나서 도달하기 때문)
==> TBR을 지연해서 처리.
* TBDR이 많이 사용되고 있지만, 안드로이드는 TBR>TBDR
(모바일에서 전통 렌더링 기법을 쓰는 디바이스는 점유율이 낮음.)
3.3. 모바일 렌더링 방식의 주의사항
3.3.1. 알파블렌딩(Alpha Blending) vs 알파테스트(Alpha Test)
* 전통 데스크톱 게임 : 알파블렌딩<알파테스트.
(불투명한 오브젝트: 불투명해서 비싼 블렌딩 연산보다 알파테스트로 픽셀 연산 절약하자)
* TBR: 알파블렌딩>알파테스트
why?
* 알파테스트 처리 = 픽셀 쉐이더에서 동적분기(if) 사용.
- 데스크탑 : 쉐이더 동적 분기 고속으로 처리 가능.
- 모바일 : 동적 분기 성능 취약.
--> 알파테스트 = 쉐이더 성능 하락.
* TBDR : 픽셀 차폐의 고속 처리 x.
(TBDR : 여러 드로우콜의 버텍스 쉐이더 결과를 모아두었다가 은면제거 후 실제 보이는 픽셀만 처리.
= 알파테스트 사용하지 않는 불투명 메쉬일 때만 적용.)
-> 알파테스트 사용할 경우 : 버텍스 처리 단계에서 해당 폴리곤 차폐 여부 판단 불가 -> Deferred 처리 x.
* 유니티 : 완전 불투명 오브젝트들을 모두 렌더링 처리한 후 알파테스트 오브젝트들 렌더링.
= 알파테스트 제한적 사용은 치명적이지 않음. (TBDR 칩셋의 구조가 알파테스트 처리에 적합하지 않음. 사용하지 않는 것 지향.)
--> 유니티 내장 쉐이더 중 모바일은 알파테스트 쉐이더 존재 x.
* 알파블렌딩=데스크톱에 비해 고속 처리 가능.
- 출력 내부적으로 대상 버퍼의 r/w 발생.
- 데스크탑 : 높은 대역폭 (DRAM에 존재하는 프레임버퍼 전체에 접근하기 때문)
- TBR : 고속 처리 가능(처리가 타일 단위+칩 내부 존재하는 메모리로 이루어지기 때문)
3.3.2. 오버드로우
위 문단의 주의사항 : 알파블렌딩 처리 자체가 빠름. 오버드로우에서 자유로워지진 않음.
ex) 넓은 영역의 파티클을 높은 밀도로 뿌리기 = 성능 저하 직결(오버드로우 문제 일으킴)
* 모바일에서 오버드로우로 쉐이커 사이클 낭비 = 문제. (쉐이더 성능이 기종에 따라 다르기 때문.)
--> 알파블렌딩 오브젝트/파티클 : 오버드로우 최대한 피하기.
3.3.3. 로우 폴리곤
많은 폴리곤 처리 -> 성능 하락.
TBDR : 타일 베이스이므로 폴리곤 처리 부담 증가.
버텍스 쉐이더 결과물 담는 버퍼크기 유한 = 버퍼 넘치면 버퍼 비워줘야 함.
(버퍼 비우기 위해 타일의 픽셀 처리 후 프레임버퍼로 출력 사이클 거쳐야 함.)
* 이론 : TBDR에서 픽셀 오버드로우 발생하지 않음. 현실 : 폴리곤 수와 오버드로우 수 비례.
--> 오브젝트 렌더링 퀄리티 상승 : 버텍스 증가 < 픽셀 연산 증가.
3.3.4. 렌더 텍스쳐
* 렌더 텍스쳐 사용 : 유니티 내부적으로 렌더 타겟 변경.(데스크탑에서도 성능 비효율적.)
- 렌더 타겟 바꾸기 : CPU가 GPU 대기 과정 거치면서 CPU/GPU 병렬 관계 잠시 x.
* TBDR에서 더 비효율적인 이유 :
- 렌더 타겟 변경 : 현재 파라미터 버퍼에 쌓인 데이터 모두 처리 -> 프레임버퍼에 출력 -> 다음 렌더 타겟 위해 파라미터 버퍼 비우기
-> 렌더 타겟 변경시 deferred 사이클 추가 처리 필요.
--> 유니티 카메라에서 타겟 텍츠셔로 렌더 텍스쳐 사용시 TBDR 효율 감소.
3.3.5. 이미지 후처리 효과(Image Post Process Effect)
* 이미지 후처리 남발하면 안되는 이유
- 내부적으로 렌더 타겟 변경.
- 현재 렌더링한 결과를 담은 렌더 타겟을 픽셀 쉐이더의 입력 텍스쳐로 가져옴
(입력받는 텍스쳐 : 칩 내부 타일이 아닌 공용 메모리의 렌더 타겟 -> 메모리 낭비 -> 대역폭 증가)
--> 대역폭 증가를 가져오므로 신중히 사용해야 함.
3.3.6. 카메라 클리어
* 현대 데스크탑 그래픽카드 & TBR : 클리어해줘야 하드웨어 고속 처리 지원받음.
3.3.7. MSAA
* 데스크톱 : 대역폭 때문에 MSAA 부담.
* TBR : 칩 내부 타일에서 이뤄져서 크게 부담되지 않긴 함.
(모바일은 DPI가 높아서 anti-aliasing 필요 여부는 의문.)
3.3.8. 프로파일링
* TBR 칩셋 : 드로우콜 별 GPU 퍼포먼스/세부 상태 확인 어려움 없음.
* TBDR 칩셋 : 콜 별 성능 직관적 처리 불가.
(드로우콜 발생 시 픽셀 쉐이더를 즉시 처리하는 것이 아니라 파라미터 버퍼에 결과를 담아두기 때문.)
3.3.9. 화면 변화율
* TBR 렌더링(칩 내부 타일) : 대역폭 먹지 않음.
* DRAM 영역 프레임버퍼에 타일 출력 : 대역폭 필요.
-> 대역폭 절약 위해 Transaction Elimination 사용.
(타일별로 이전 프레임과 화면 결과가 달라지지 않은 타일의 영역은 프레임 버퍼를 갱신하지 않고 이전 프레임 버퍼 결과 재활용. -> 칩 내부 메모리에서 시스템 메모리로 복사하는 양 감소.)
참고 링크:
https://3dmpengines.tistory.com/2045