SlideShare a Scribd company logo
TBR
21.01.09
조광민
참고1 : 그냥그런블로그
https://lifeisforu.tistory.com/525?category=837815
참고2 : 오즈라엘 블로그
https://ozlael.tistory.com/23
참고3 : 오페라 브라우저 비공식 블로그
https://youngjr.tistory.com/44
참고4 : 박창현님_언리얼 엔진4 모바일 렌더링 개요
https://docsplayer.org/105324380-R201-2_3_%EB%B0%95%EC%B0%BD%ED%98%84_%EC%96%B8%EB%A6%AC%EC%96%BC-%EC%97%94%EC%A7%84-4-%EB%AA%A8%EB%B0%94%EC%9D%BC-%EB%A0%8C%EB%8D%94%EB%A7%81-
%EA%B0%9C%EC%9A%94.html
Mobile AP (Mobile Application Processor)
● 스마트폰의 심장
● 데스크탑과는 달리 모바일 디바이스는 칩 안에 여러가지 기능을 넣어놓은
AP가 사용된다. (CPU와 GPU가 하나의 칩에 포함된 형태)
Mobile AP
● Unified Shader Architecture (DirectX10 ~)
- 모든 Shader Processing Unit이 어떤 타입의 셰이딩 연산이든 처리 // 테슬라 // 쿠다 API
<Mobile AP 구조> <통합 셰이더 아키택쳐>
Mobile AP
● 발열이 심해지면 하드웨어를 보호하기 위해 자동으로 성능을 줄이는 스로틀링
을 진행한다. (쿨링)
모바일 성능
1. Memory Bandwidth
a. 메모리 대역폭 : 프로세서가 데이터를 읽거나 반도체 메모리에 저장할 수 있는 속도
b. 메모리 사용이 많으면 배터리 소모도 크다.
2. pixel Fillrate
a. GPU가 1초 안에 화면에 렌더링하고 GPU 메모리에 쓸 수 있는 픽셀의 수가 다른 디바이스에
비해 적다.
3. GFLOPS
a. 1초에 연산할 수 있는 소수점 연산 수가 다른 디바이스에 비해 낮은 편이다.
모바일 성능을 올리기 위한 방법
1. Early Z Testing
2. Tile Based Rendering
Early Z Testing
1. 일반적인 Depth(Z) Test
○ Pixel Shading 후 렌더링 결과물을 타겟에 블렌딩할 지 결정
○ Test 실패 시 스킵한다.
2. Early Z Test
1. Pixcel Shading 전에 미리 스킵 여부를 판단
2. 아키텍쳐 마다 다른 처리
■ Mali GPU : Forward Pixel Kill
■ PowerVR GPU : Hidden Surface Removal
1. 순서
1. 컬러 write를 비활성화하고 깊이 write만 활성화
2. depth를 clear하지 않은 상태에서 정상적인 렌더링
3. 1번에서 기록된 depth buffer 값은 2번 단계를 거치며
깊이 비교에 실패한 픽셀들을 자동으로 연산에서 제외
(픽셀 셰이더를 타지않아 렌더링 속도가 향상된다.)
TBR (Tile Based Rendering)
● 한 장면을 그리기 위해 필요한 리소스를 전부 GPU 메모리에 올리는 게 아닌,
모든 렌더링을 타일 단위로 진행하는 것
● 장점 : 셰이더 코어와 GPU 메모리간 대역폭의 사용을 줄일 수 있다.
● 단점 : 타일을 나누고 관리하기 위해 추가적인 관리 비용이 발생한다.
기본 렌더링 과정
매번 프레임 버퍼 영역 전체가 갱신되는 방식
각 프리미티브 -> 다음 프리미티브
셰이딩 된 프래그먼트들은 외부 프레임 버퍼 워킹셋에 손대게 되고,
고해상도의 프래그먼트에 대해 읽기-수정-쓰기 연산 시 높은 메모리 대역폭을 소비
외부 프레임 버퍼는
칩 바깥 DRAM 에 있다.
DRAM, SRAM
● DRAM(Dynamic Random Access Memory) // 흔히 아는 RAM
○ 1개의 트랜지스터와 1개의 캐패시터로 구성
○ 백만분의 n초마다 리플래쉬를 해줘야 내용이 유지된다.
● SRAM(Static Random Access Memory) // Mobile AP 안의 L2 Cache
○ 4개의 트랜지스터와 2개의 저항 또는 6개의 트랜지스터로 구성
○ 전원이 차단되지 않으면 데이터가 지워지지 않는다.
○ 리플래쉬 없이도 그 내용이 유지가 되기때문에 반응속도가 DRAM보다 빠르다.
TBR (The Mali Approach)
● 전체를 갱신하는 것이 아닌 타일 단위로 쪼개서 갱신
● 외부 메모리 접근과 전력 소비량을 최소화 하기 위해 설계
● 두 개의 패스 렌더링(Two Pass Rendering) 알고리즘을 사용
-> 디퍼드 렌더링 얘기가 아니라
타일 과정이 추가되었기 때문에 투 패스 렌더링이다.
TBR (The Mali Approach)
● 지오메트리 처리를 모두 실행한 다음 프래그먼트 처리를 실행
● Mali GPU는 지오메트리 처리 동안 화면을 16x16(256) 프래그먼트(픽셀) 타일
들로 쪼개고, 렌더링 중인 프리미티브들이 어떤 타일에 그려지는 지에 대한 리
스트를 만든다.
● GPU 프래그먼트(픽셀) 셰이딩 단계에서 각 셰이더 코어는 한 번에 하나의
16x16 픽셀 타일을 처리한다. (Unified Shader Architecture)
16*16 의 크기가 작아 칩 형태 SRAM(L2 Cache) 에 저장
TBR 특징
● 칩 외부 DRAM에 대한 읽기나 쓰기에 필요한 전력 소모가 낮다.
● 블렌딩 처리가 빠르다.
데스크탑 : 알파블렌딩 < 알파테스트
모바일 : 알파블렌딩 > 알파테스트
1. 알파 블렌딩 과정은 출력 내부적으로 대상 버퍼(DRAM에 저장된 버퍼)의 읽기/쓰기가 발생하는데,
TBR에서는 이 처리가 타일 처리로 이루어지고, 칩 내부(SRAM)에 존재하는 메모리에서 연산하기
때문에 고속으로 처리된다.
2. 알파 테스트를 처리하기 위해 픽셀셰이더에서 동적분기(if)문이 사용되는데,
모바일은 동적 분기 성능이 취약하다.
(if문을 사용하면 최적화가 깨지기 때문)
참고 : https://ozlael.tistory.com/24
TBR 특징
● 단, 알파 블렌딩 처리 자체가 빠르지만 오버드로우에서는 자유롭지 못함
● 오버드로우 : 겹치는 부분의 픽셀을 다시 그리는 것
-> 큰 영역을 차지하는 물체를 먼저 그리도록
참고 : https://ozlael.tistory.com/24
TBR 특징
● Mali는 타일 작업 후 메모리에 단일 타일을 위한 컬러버퍼만을 써야하기 때문
에 이 시점에 최종 상태를 알 수 있어 CRC(cyclic redundancy check) 를 통해
메인 메모리에 있는 현재 데이터와 블록의 컬러를 비교할 수 있다.
(Transaction Elimination)
-> 타일이 동일하다면 쓰기를 취소해 전력을 절약할 수 있다.
(앵그리버드)
분홍색 타일-> GPU에 의해 쓰여진 것
TBR아니.. 모바일의 단점
● 포워드 셰이딩을 사용한다.
(디퍼드 셰이딩일 경우 G-Buffer 사용 시 많은 메모리 대역폭을 요구하기 때문)

More Related Content

What's hot

認識網路傳播
認識網路傳播認識網路傳播
認識網路傳播基欽 劉
 
331 Ch
331 Ch331 Ch
331 Chanjaan
 
Google 2
Google 2Google 2
Google 2semi06
 
2021년 1월 3일 개발자 이야기
2021년 1월 3일 개발자 이야기2021년 1월 3일 개발자 이야기
2021년 1월 3일 개발자 이야기
Jay Park
 
1242982622API2 upload
1242982622API2 upload1242982622API2 upload
1242982622API2 upload51 lecture
 
Hyperledger Meetup Korea #28 - HTS(Hedera Token Service), DeFi 스왑 및 유동성 프로토콜
Hyperledger Meetup Korea #28 - HTS(Hedera Token Service), DeFi 스왑 및 유동성 프로토콜Hyperledger Meetup Korea #28 - HTS(Hedera Token Service), DeFi 스왑 및 유동성 프로토콜
Hyperledger Meetup Korea #28 - HTS(Hedera Token Service), DeFi 스왑 및 유동성 프로토콜
Hyperledger Korea User Group
 
整合檔案1 簡報1
整合檔案1 簡報1整合檔案1 簡報1
整合檔案1 簡報1guestb2f9ad
 
벤치마킹
벤치마킹벤치마킹
벤치마킹oros83
 
How Wiki Changes the World?
How Wiki Changes the World?How Wiki Changes the World?
How Wiki Changes the World?
Asadal Lee
 
196 Ch
196 Ch196 Ch
196 Chanjaan
 
『 外掛字幕的製作、播放和問題 』
『 外掛字幕的製作、播放和問題 』『 外掛字幕的製作、播放和問題 』
『 外掛字幕的製作、播放和問題 』Chui-Wen Chiu
 
10 Things you should know about Web 2.0
10 Things you should know about Web 2.010 Things you should know about Web 2.0
10 Things you should know about Web 2.0Charles (XXC) Chen
 
2021년 1월 9일 개발자 이야기
2021년 1월 9일 개발자 이야기2021년 1월 9일 개발자 이야기
2021년 1월 9일 개발자 이야기
Jay Park
 
웹사이트 벤치마킹의 9가지 패턴
웹사이트 벤치마킹의 9가지  패턴웹사이트 벤치마킹의 9가지  패턴
웹사이트 벤치마킹의 9가지 패턴AshleyMoon
 
웹사이트 벤치마킹의 9가지 패턴 04
웹사이트 벤치마킹의 9가지 패턴 04웹사이트 벤치마킹의 9가지 패턴 04
웹사이트 벤치마킹의 9가지 패턴 04Clara_Kim
 
웹사이트 벤치마킹의 9가지 패턴 05
웹사이트 벤치마킹의 9가지 패턴 05웹사이트 벤치마킹의 9가지 패턴 05
웹사이트 벤치마킹의 9가지 패턴 05Clara_Kim
 
웹사이트 벤치마킹
웹사이트 벤치마킹웹사이트 벤치마킹
웹사이트 벤치마킹JooWan
 

What's hot (20)

Keynote Genius
Keynote GeniusKeynote Genius
Keynote Genius
 
認識網路傳播
認識網路傳播認識網路傳播
認識網路傳播
 
331 Ch
331 Ch331 Ch
331 Ch
 
Google 2
Google 2Google 2
Google 2
 
2021년 1월 3일 개발자 이야기
2021년 1월 3일 개발자 이야기2021년 1월 3일 개발자 이야기
2021년 1월 3일 개발자 이야기
 
1242982622API2 upload
1242982622API2 upload1242982622API2 upload
1242982622API2 upload
 
Hyperledger Meetup Korea #28 - HTS(Hedera Token Service), DeFi 스왑 및 유동성 프로토콜
Hyperledger Meetup Korea #28 - HTS(Hedera Token Service), DeFi 스왑 및 유동성 프로토콜Hyperledger Meetup Korea #28 - HTS(Hedera Token Service), DeFi 스왑 및 유동성 프로토콜
Hyperledger Meetup Korea #28 - HTS(Hedera Token Service), DeFi 스왑 및 유동성 프로토콜
 
整合檔案1 簡報1
整合檔案1 簡報1整合檔案1 簡報1
整合檔案1 簡報1
 
中国网络审查
中国网络审查中国网络审查
中国网络审查
 
벤치마킹
벤치마킹벤치마킹
벤치마킹
 
How Wiki Changes the World?
How Wiki Changes the World?How Wiki Changes the World?
How Wiki Changes the World?
 
196 Ch
196 Ch196 Ch
196 Ch
 
『 外掛字幕的製作、播放和問題 』
『 外掛字幕的製作、播放和問題 』『 外掛字幕的製作、播放和問題 』
『 外掛字幕的製作、播放和問題 』
 
10 Things you should know about Web 2.0
10 Things you should know about Web 2.010 Things you should know about Web 2.0
10 Things you should know about Web 2.0
 
2021년 1월 9일 개발자 이야기
2021년 1월 9일 개발자 이야기2021년 1월 9일 개발자 이야기
2021년 1월 9일 개발자 이야기
 
웹사이트 벤치마킹의 9가지 패턴
웹사이트 벤치마킹의 9가지  패턴웹사이트 벤치마킹의 9가지  패턴
웹사이트 벤치마킹의 9가지 패턴
 
웹사이트 벤치마킹의 9가지 패턴 04
웹사이트 벤치마킹의 9가지 패턴 04웹사이트 벤치마킹의 9가지 패턴 04
웹사이트 벤치마킹의 9가지 패턴 04
 
웹사이트 벤치마킹의 9가지 패턴 05
웹사이트 벤치마킹의 9가지 패턴 05웹사이트 벤치마킹의 9가지 패턴 05
웹사이트 벤치마킹의 9가지 패턴 05
 
Web3
Web3Web3
Web3
 
웹사이트 벤치마킹
웹사이트 벤치마킹웹사이트 벤치마킹
웹사이트 벤치마킹
 

Tile Based Rendering

  • 1. TBR 21.01.09 조광민 참고1 : 그냥그런블로그 https://lifeisforu.tistory.com/525?category=837815 참고2 : 오즈라엘 블로그 https://ozlael.tistory.com/23 참고3 : 오페라 브라우저 비공식 블로그 https://youngjr.tistory.com/44 참고4 : 박창현님_언리얼 엔진4 모바일 렌더링 개요 https://docsplayer.org/105324380-R201-2_3_%EB%B0%95%EC%B0%BD%ED%98%84_%EC%96%B8%EB%A6%AC%EC%96%BC-%EC%97%94%EC%A7%84-4-%EB%AA%A8%EB%B0%94%EC%9D%BC-%EB%A0%8C%EB%8D%94%EB%A7%81- %EA%B0%9C%EC%9A%94.html
  • 2. Mobile AP (Mobile Application Processor) ● 스마트폰의 심장 ● 데스크탑과는 달리 모바일 디바이스는 칩 안에 여러가지 기능을 넣어놓은 AP가 사용된다. (CPU와 GPU가 하나의 칩에 포함된 형태)
  • 3. Mobile AP ● Unified Shader Architecture (DirectX10 ~) - 모든 Shader Processing Unit이 어떤 타입의 셰이딩 연산이든 처리 // 테슬라 // 쿠다 API <Mobile AP 구조> <통합 셰이더 아키택쳐>
  • 4. Mobile AP ● 발열이 심해지면 하드웨어를 보호하기 위해 자동으로 성능을 줄이는 스로틀링 을 진행한다. (쿨링)
  • 5. 모바일 성능 1. Memory Bandwidth a. 메모리 대역폭 : 프로세서가 데이터를 읽거나 반도체 메모리에 저장할 수 있는 속도 b. 메모리 사용이 많으면 배터리 소모도 크다. 2. pixel Fillrate a. GPU가 1초 안에 화면에 렌더링하고 GPU 메모리에 쓸 수 있는 픽셀의 수가 다른 디바이스에 비해 적다. 3. GFLOPS a. 1초에 연산할 수 있는 소수점 연산 수가 다른 디바이스에 비해 낮은 편이다.
  • 6. 모바일 성능을 올리기 위한 방법 1. Early Z Testing 2. Tile Based Rendering
  • 7. Early Z Testing 1. 일반적인 Depth(Z) Test ○ Pixel Shading 후 렌더링 결과물을 타겟에 블렌딩할 지 결정 ○ Test 실패 시 스킵한다. 2. Early Z Test 1. Pixcel Shading 전에 미리 스킵 여부를 판단 2. 아키텍쳐 마다 다른 처리 ■ Mali GPU : Forward Pixel Kill ■ PowerVR GPU : Hidden Surface Removal 1. 순서 1. 컬러 write를 비활성화하고 깊이 write만 활성화 2. depth를 clear하지 않은 상태에서 정상적인 렌더링 3. 1번에서 기록된 depth buffer 값은 2번 단계를 거치며 깊이 비교에 실패한 픽셀들을 자동으로 연산에서 제외 (픽셀 셰이더를 타지않아 렌더링 속도가 향상된다.)
  • 8. TBR (Tile Based Rendering) ● 한 장면을 그리기 위해 필요한 리소스를 전부 GPU 메모리에 올리는 게 아닌, 모든 렌더링을 타일 단위로 진행하는 것 ● 장점 : 셰이더 코어와 GPU 메모리간 대역폭의 사용을 줄일 수 있다. ● 단점 : 타일을 나누고 관리하기 위해 추가적인 관리 비용이 발생한다.
  • 9. 기본 렌더링 과정 매번 프레임 버퍼 영역 전체가 갱신되는 방식 각 프리미티브 -> 다음 프리미티브 셰이딩 된 프래그먼트들은 외부 프레임 버퍼 워킹셋에 손대게 되고, 고해상도의 프래그먼트에 대해 읽기-수정-쓰기 연산 시 높은 메모리 대역폭을 소비 외부 프레임 버퍼는 칩 바깥 DRAM 에 있다.
  • 10. DRAM, SRAM ● DRAM(Dynamic Random Access Memory) // 흔히 아는 RAM ○ 1개의 트랜지스터와 1개의 캐패시터로 구성 ○ 백만분의 n초마다 리플래쉬를 해줘야 내용이 유지된다. ● SRAM(Static Random Access Memory) // Mobile AP 안의 L2 Cache ○ 4개의 트랜지스터와 2개의 저항 또는 6개의 트랜지스터로 구성 ○ 전원이 차단되지 않으면 데이터가 지워지지 않는다. ○ 리플래쉬 없이도 그 내용이 유지가 되기때문에 반응속도가 DRAM보다 빠르다.
  • 11. TBR (The Mali Approach) ● 전체를 갱신하는 것이 아닌 타일 단위로 쪼개서 갱신 ● 외부 메모리 접근과 전력 소비량을 최소화 하기 위해 설계 ● 두 개의 패스 렌더링(Two Pass Rendering) 알고리즘을 사용 -> 디퍼드 렌더링 얘기가 아니라 타일 과정이 추가되었기 때문에 투 패스 렌더링이다.
  • 12. TBR (The Mali Approach) ● 지오메트리 처리를 모두 실행한 다음 프래그먼트 처리를 실행 ● Mali GPU는 지오메트리 처리 동안 화면을 16x16(256) 프래그먼트(픽셀) 타일 들로 쪼개고, 렌더링 중인 프리미티브들이 어떤 타일에 그려지는 지에 대한 리 스트를 만든다. ● GPU 프래그먼트(픽셀) 셰이딩 단계에서 각 셰이더 코어는 한 번에 하나의 16x16 픽셀 타일을 처리한다. (Unified Shader Architecture) 16*16 의 크기가 작아 칩 형태 SRAM(L2 Cache) 에 저장
  • 13. TBR 특징 ● 칩 외부 DRAM에 대한 읽기나 쓰기에 필요한 전력 소모가 낮다. ● 블렌딩 처리가 빠르다. 데스크탑 : 알파블렌딩 < 알파테스트 모바일 : 알파블렌딩 > 알파테스트 1. 알파 블렌딩 과정은 출력 내부적으로 대상 버퍼(DRAM에 저장된 버퍼)의 읽기/쓰기가 발생하는데, TBR에서는 이 처리가 타일 처리로 이루어지고, 칩 내부(SRAM)에 존재하는 메모리에서 연산하기 때문에 고속으로 처리된다. 2. 알파 테스트를 처리하기 위해 픽셀셰이더에서 동적분기(if)문이 사용되는데, 모바일은 동적 분기 성능이 취약하다. (if문을 사용하면 최적화가 깨지기 때문) 참고 : https://ozlael.tistory.com/24
  • 14. TBR 특징 ● 단, 알파 블렌딩 처리 자체가 빠르지만 오버드로우에서는 자유롭지 못함 ● 오버드로우 : 겹치는 부분의 픽셀을 다시 그리는 것 -> 큰 영역을 차지하는 물체를 먼저 그리도록 참고 : https://ozlael.tistory.com/24
  • 15. TBR 특징 ● Mali는 타일 작업 후 메모리에 단일 타일을 위한 컬러버퍼만을 써야하기 때문 에 이 시점에 최종 상태를 알 수 있어 CRC(cyclic redundancy check) 를 통해 메인 메모리에 있는 현재 데이터와 블록의 컬러를 비교할 수 있다. (Transaction Elimination) -> 타일이 동일하다면 쓰기를 취소해 전력을 절약할 수 있다. (앵그리버드) 분홍색 타일-> GPU에 의해 쓰여진 것
  • 16. TBR아니.. 모바일의 단점 ● 포워드 셰이딩을 사용한다. (디퍼드 셰이딩일 경우 G-Buffer 사용 시 많은 메모리 대역폭을 요구하기 때문)