[번역] 언리얼 렌더링 시스템 해부하기 (12) - 모바일 파트 2 (UE 모바일 렌더링 분석)

파트1 엮어보기.
[번역] 언리얼 렌더링 시스템 해부하기 (12) - 모바일 파트 1 (UE 모바일 렌더링 분석) (tistory.com)

[번역] 언리얼 렌더링 시스템 해부하기 (12) - 모바일 파트 1 (UE 모바일 렌더링 분석)

 

역자의 말: 이 전 언리얼 렌더링 시스템 해부하기 12 파트 1에 이어서 장선생의 멋진 모바일 렌더링 기술 하이라이트 기사를 소개합니다. 대부분의 단어들은 아티스트 및 테크니컬 아티스트들에게도 생소한 것들이 많을 만큼 이해하기에는 무리가 있고 주로 그래픽스 프로그래머들에게 더 친숙한 내용일 겁니다. 그렇더라도 몇 번을 읽어보고 궁금한 단어는 찾아 본다면 나중에는 분명히 도움이 될 내용들이 참 많이 포함되어 있는 기사 입니다. 이런 멋진 기사를 정리해주신 장선생에게 다시한번 감사 드립니다.

 

---

저자:  그래픽 렌더링, 게임 엔진、GPU。知乎：http://www.zhihu.com/people/timlly-chang。UE技术群：943549515
 

12.4 모바일 렌더링 기술 하이라이트

최근 몇 년 동안 모바일에 관한 시그래프, GDC 논문, 퀄컴, Arm, PowerVR 및 기타 모바일 GPU 공급업체와 일부 모바일 기기 제조업체의 개발 가이드를 읽었으며, 이 장에서는 현재 모바일 공통 전용 렌더링 기술을 요약합니다.

자세한 내용은 다음 참조 목록을 참조하세요.

12.4.1 Tile-based (Deferred) Rendering

TBR의 정식 명칭은 타일 기반 렌더링으로, 청크 기반 렌더링으로 번역됩니다.렌더링을 가속화하고 대역폭과 에너지 소비를 줄이기 위해 현재 모바일 GPU 아키텍처에서 매우 널리 사용되는 기술입니다.
타일 기반 지연 렌더링으로 알려진 TBDR은 청크 기반 지연 렌더링을 의미하는 TBR의 개선된 버전으로, PowerVR에서 GPU 칩에 처음 적용했습니다.가장 큰 차이점은 Early-Z 테스트를 통과한 픽셀은 픽셀 셰이더에 의해 즉시 실행되지 않고 먼저 어느 픽셀 요소에 속하는지 레이블이 지정된다는 것입니다.타일이 모든 튜플(씬의 모든 오브젝트)을 처리한 후 타일에 표시된 모든 픽셀을 그리면 TBDR은 하드웨어 수준의 오클루전 픽셀 컬링을 수행하여 오버드로우, 대역폭 및 메모리 액세스를 줄입니다.
PowerVR의 TBDR은 렌더링을 시작하기 전에 전체 장면을 캡처하므로 가려진 픽셀을 식별하여 픽셀 셰이딩 전에 제거할 수 있습니다.각 타일은 래스터화되어 개별적으로 처리되며 렌더링의 크기가 작기 때문에 모든 데이터를 매우 빠른 타일 메모리에 보관할 수 있습니다.
TB(D)R에 대응하는 모드로는 PC용 즉시 렌더링(IMR) 모드가 있으며, IMR, TBR, TBDR 아키텍처의 비교 표는 아래와 같습니다:

IMR, TBR 및 TBDR 아키텍처 작동 도식.여기서 빨간색 타원은 높은 대역폭을 나타내며, 이는 성능 병목 현상을 유발할 수 있습니다.
IMR 모드 GPU의 경우 병렬 처리 로직이 무시된 경우 실행되는 의사 코드는 아래와 같습니다:

for draw in renderPass:
    for primitive in draw:
        for vertex in primitive:
            execute_vertex_shader(vertex)
        if primitive not culled:
            for fragment in primitive:
                execute_fragment_shader(fragment)

IMR의 GPU 하드웨어 아키텍처는 아래와 같습니다:

하드웨어 데이터 흐름과 메모리 상호 작용 다이어그램은 다음과 같습니다:

IMR 모드 GPU의 장점은 버텍스 셰이더 및 기타 지오메트리 관련 셰이더의 출력을 GPU 내의 칩에 유지할 수 있다는 것입니다.이러한 셰이더의 출력은 파이프라인의 다음 단계에서 데이터를 사용할 준비가 될 때까지 FIFO 버퍼(선입선출 버퍼)에 저장할 수 있으며, GPU는 중간 지오메트리 결과를 저장하고 검색하는 데 매우 적은 외부 메모리 대역폭을 사용할 수 있습니다.
IMR 모드 GPU의 단점은 삼각형이 그려진 순서대로 처리되고 데이터 스트림의 모든 삼각형이 화면의 모든 부분을 덮을 수 있기 때문에 픽셀 셰이딩이 화면에서 점프한다는 것입니다(아래).
즉, 활성 작업 세트는 전체 프레임버퍼의 크기입니다.예를 들어 해상도가 1440p인 디바이스에서 픽셀당 32비트(BPP) 색상, 픽셀 채움 깊이/템플릿당 32비트를 사용하면 총 작업 세트가 30MB가 되는데, 이 데이터는 온칩에 모두 저장하기에는 너무 많으므로 DRAM의 오프칩 외부에 저장해야 합니다.

 
전체 화면에 걸쳐 랜덤 액세스가 분산되어 캐시 적중률이 훨씬 낮은 IMR의 병렬 렌더링 도식.
고해상도 프레임을 처리할 때는 픽셀당 여러 번의 읽기-수정-쓰기 작업으로 인해 메모리에 가해지는 대역폭 부하가 매우 높을 수 있습니다.프레임버퍼의 가장 최근에 액세스한 부분을 GPU에 가깝게 유지하면 높은 대역폭 부하를 완화할 수 있습니다.
반면 TB(D)R용 GPU는 먼저 화면을 여러 개의 고정 크기 영역으로 나눈 다음 셰이딩 계산을 수행한다는 점에서 IMR GPU와 다릅니다.아래는 TBR의 실행 의사 코드입니다:

# Pass one
for draw in renderPass:
    for primitive in draw:
        for vertex in primitive:
            execute_vertex_shader(vertex)
        if primitive not culled:
            append_tile_list(primitive)

# Pass two
for tile in renderPass:
    for primitive in tile:
        for fragment in primitive:
            execute_fragment_shader(fragment)

TB(D)R GPU의 하드웨어 아키텍처는 아래와 같습니다:

하드웨어 데이터 흐름과 메모리 상호 작용 다이어그램은 다음과 같습니다:

TB(D)R의 장점은 타일이 전체 프레임버퍼의 극히 일부만 차지한다는 점입니다. 결과적으로 색상, 깊이 및 스텐실의 전체 작업 세트는 GPU 셰이더 코어에 긴밀하게 연결된 고속 온칩 RAM에 저장할 수 있으며, 투명 픽셀의 깊이 테스트 및 혼합에 필요한 프레임버퍼 데이터를 외부 메모리 액세스 없이 얻을 수 있으므로 범용 프레임버퍼 연산에 필요한 GPU의 외부 메모리 액세스 횟수를 줄여 픽셀 집약적인 콘텐츠의 에너지 효율성을 크게 개선할 수 있습니다.
수에 따라 픽셀 집약적인 콘텐츠의 에너지 효율을 크게 개선할 수 있습니다.또한 대부분의 경우 깊이 및 템플릿 버퍼가 존재하며, 이는 일시적인 것으로 셰이딩 프로세스 중에만 존재하면 됩니다.
GPU 드라이버에 첨부 파일을 저장할 필요가 없다고 명시적으로 알려주면 드라이버는 첨부 파일을 주 메모리에 다시 쓰지 않습니다.

다음 그래픽 API는 드라이버에 첨부 파일을 삭제하도록 지시할 수 있습니다.

OpenGL ES 2.0：glDiscardFramebufferEXT

OpenGL ES 3.0：glInvalidateFramebuffer

Vulkan：적절한 렌더링 채널 storeOp

각 타일의 크기가 일반적으로 그리 크지 않기 때문에 GPU 컴퓨팅 유닛이 좋은 이웃을 가진 단일 타일 내의 데이터에 액세스할 수 있어 캐시 적중률을 향상시킬 수 있다는 점을 언급할 가치가 있습니다.
물론 공짜 점심은 없으며 TB(D)R에도 몇 가지 단점이 있습니다.예를 들어 지오메트리 채널의 출력(각 버텍스의 변경 데이터와 타일의 중간 상태)을 GPU가 메인 메모리에 저장해야 하며, 셰이딩 채널은 이를 읽습니다.따라서 지오메트리와 관련된 추가 대역폭 비용과 프레임버퍼 데이터를 위해 절약되는 대역폭 간에 균형을 맞춰야 합니다.
또한 표면 세분화와 같은 일부 렌더링 작업은 TBR을 과도하게 많이 소비한다는 점도 고려해야 합니다.표면 세분화와 같은 작업은 폭발적으로 증가하는 지오메트리 데이터를 메인 메모리에 다시 기록하는 대신 온칩 FIFO 버퍼에 버퍼링할 수 있으므로 IMR 모드 아키텍처의 이점을 수용하도록 설계되었습니다.
아래에서는 퀄컴 아드레노 시리즈 GPU를 사용하여 TB(D)R의 아키텍처, 작동, 관련 렌더링 기술 및 최적화 기법을 설명합니다.

TB(D)R의 렌더링은 드로잉 프로세스가 비닝 패스, 렌더링 패스, 리졸브 패스의 세 단계로 나뉜다는 점에서 IMR 모드와 다릅니다.
비닝(Binning) 패스 프로세스는 대략 다음과 같습니다:

• 각 빈(타일이라고도 함)에 대해 고정 크기(2의 N제곱, 일반적으로 길이와 폭은 동일, 정확한 크기는 GPU 제조사마다 다름(예: 16x16, 32x32, 64x64)를 설정하고 프레임 버퍼 크기에 따라 표시되는 데이터 흐름을 설정합니다.

• 튜플 좌표를 변환합니다.이 단계에서는 인덱스 및 버텍스 데이터를 처리하며, 일부 GPU(예: Adreno)는 대역폭과 에너지 소비를 줄이기 위해 전체 버텍스 셰이더 대신 특수 단순화 셰이더를 사용하여 좌표를 처리합니다.
  이 단계에서는 일반적으로 버텍스의 위치만 유효하며, 다른 모든 버텍스 데이터(텍스처 좌표, 노멀, 탄젠트, 버텍스 색상)는 무시됩니다.
• 모든 튜플을 반복하고, 튜플이 커버하는 모든 블록을 표시한 다음, 커버된 블록 데이터 스트림에 가시성 데이터를 씁니다.
• 가시성 데이터 스트림을 시스템 명시적 메모리에 다시 씁니다.

비닝(Binning) 작업 단계는 아래와 같습니다:

렌더링 패스 프로세스는 대략 다음과 같습니다:

• 렌더링 패스를 초기화합니다.
• 모든 청크를 반복하고 각 청크에 대해 다음 작업을 수행합니다:
  
  • 청크화된 가시성 데이터 스트림을 사용하여 그리기 호출을 실행합니다.
  • 래스터화된 튜플.
  • 픽셀 조작(픽셀 셰이더, 뎁스 템플릿 테스트, 알파 테스트, 블렌딩).
  • 픽셀 데이터(색상, 깊이, 템플릿 등)를 청크 칩의 버퍼(온칩 메모리, GMEM, 타일 메모리라고도 함)에 기록합니다.

렌더링 단계는 아래와 같이 실행됩니다:

Resolve pass 단계 프로세스는 다음과 같습니다:

• MSAA가 켜져 있으면 GMEM의 해상도, 심도 등의 데이터가 평균화됩니다. 이후 단계에서 GMEM이 시스템 비디오 메모리로 전송하는 총 데이터 양을 줄일 수 있습니다.

• 청크의 모든 픽셀 데이터(색상, 깊이, 템플릿 등)를 시스템 그래픽 메모리에 씁니다.
• 프레임 버퍼의 마지막 청크가 아닌 경우 다음 청크로 진행합니다.
• 프레임 버퍼의 마지막 청크인 인터랙티브 버퍼는 다음 프레임에 대한 비닝 패스를 수행합니다.

파싱 단계는 다음과 같이 실행됩니다(타일 내의 픽셀에는 들쭉날쭉한 부분이 있으며, 아래의 큰 이미지는 MSAA를 파싱한 후 앤티 앨리어싱이 적용된 픽셀입니다):

비닝(Binning) 패스와 렌더링 패스는 일반적으로 별도의 프레임에서 처리되므로 렌더링 패스가 비닝 패스보다 한 프레임 늦게 처리되어 스톨을 줄이고 처리량을 개선하며 렌더링 효율을 높입니다.
TB(D)R GPU 아키텍처를 기반으로 하는 더 많은 최적화와 기술이 있으며, 이 내용은 나중에 다룰 예정입니다.

12.4.2 Hierarchical Tiling

계층적 청킹으로 번역되는 계층적 타일링은 이름에서 알 수 있듯이 계층적 기반으로 청킹을 구현하는 Arm Midgard 칩 제품군에서 사용되는 최초의 청킹 기법입니다.
이 경우 계층적 타일링을 사용하면 청크 복잡도가 원하는 크기에 도달할 때까지(또는 최소 청크 복잡도에 도달할 때까지) 청크를 계층을 따라 더 세분화한다는 아이디어에 따라 Midgard는 가변 청크 크기를 사용할 수 있습니다(아래 참조). 이 기술을 통해 미드가르는 필요한 경우에만 작은 청크 크기를 사용하고, 복잡도가 낮은 시나리오에는 큰 청크 크기를 사용하여 리소스를 절약할 수 있습니다.

좀 더 구체적으로 설명하자면, Arm은 일반적으로 다양한 레벨의 청크(빈)를 다음과 같은 크기로 설정합니다:

• Hierarchy Level  0은 16x16 픽셀로 설정됩니다;
• Hierarchy Level 1은32x32픽셀로 설정합니다;
• Hierarchy Level 2는 64x64 픽셀로 설정합니다;
• Hierarchy Level 3은 128x128픽셀로 설정합니다;
• ......

이 시스템의 목표는 각 그래프 요소가 포함하는 청크를 찾아내고 청크의 구조 정보를 업데이트하는 것입니다.

작은 영역 튜플(위 그림의 회색 삼각형과 같이)의 경우, 영향을 받는 청크 수가 적으므로 읽기 대역폭을 절약하기 위해 낮은 수준의 블록을 사용합니다.

큰 영역 튜플(위 그림의 파란색 삼각형)의 경우 더 많은 블록이 영향을 받으므로 상위 수준 블록을 사용하여 쓰기 대역폭을 절약합니다.

복잡한 튜플의 경우, GPU는 일루미네이팅 전략을 사용하여 자동으로 최적의 분포를 결정합니다.

조명 전략이 어떻게 생겼는지에 대한 구체적인 내용은 아직 이에 대한 정보나 문헌을 찾지 못했으며 나중에 찾으면(또는 동급생이 제공하면) 추가할 예정입니다.

12.4.3 Early-Z

Early-Z는 원치 않는 렌더링 패스가 있는 오브젝트(화면 공간에서 해당 위치에서 보이지 않는 픽셀)를 컬링하는 빠른 마스킹 방법을 제공하는 고급 깊이 테스트입니다. Adreno GPU는 드로 픽셀 필 레이트의 4배로 마스킹된 픽셀을 컬링할 수 있습니다.
Early-Z는 일반적으로 렌더링 패스 단계에서 래스터화 후 픽셀 셰이딩 전에 발생합니다. (아래 그림)

Early-Z 기법은 유효하지 않은 많은 픽셀을 미리 컬링하여 픽셀 셰이더를 많이 사용하는 픽셀에 들어가는 것을 방지하며, Early-Z 컬링의 가장 작은 단위는 1픽셀이 아니라 픽셀 쿼드입니다. 다음은 이러한 실행 중 하나의 예시입니다.

Early-Z 실행의 모식도. 왼쪽은 깊이 버퍼에 이미 렌더링된 값으로 모두 1이고, 가운데는 렌더링할 준비가 된 깊이 값이 2인 모든 영역이며, 오른쪽은 Early-Z 기법을 사용하여 깊이 버퍼보다 큰 픽셀이 제거된 영역입니다.
Early-Z  기법을 극대화하기 위해 렌더링 엔진(예: UE)은 렌더링 프로세스 초기에 특수 패스(예: UE의 프리패스)를 사용하여 모든 불투명 오브젝트의 깊이를 렌더링하며, 이는 TBR 아키텍처의 조기-Z 기법과 함께 재생됩니다. 이 단계는 TBDR 아키텍처를 지원하는 GPU에는 필요하지 않습니다.
그러나 다음과 같은 조건에서는 Early-Z가 실패할 수 있습니다:

• 알파 테스트 켜기: 알파 테스트는 픽셀 셰이더 뒤의 알파 테스트 단계에서 비교해야 하므로 픽셀 셰이더 이전에는 픽셀 컬링 여부를 결정할 수 없습니다.
• Tex Kill 켜기：즉, 셰이더 코드에 픽셀 폐기 명령이 있습니다(DX의 경우 폐기, OpenGL의 경우 클립).
• 깊이 테스트 비활성화: Early-Z는 깊이 테스트가 켜져 있는 상태를 기준으로 하며, 깊이 테스트가 꺼져 있으면 Early-Z 기술을 활성화할 수 없습니다.
• Alpha To Coverage 켜기：알파 투 커버리지는 주변 픽셀에 영향을 주는 멀티샘플링을 켜고, 초기 Z 단계에서는 주변 픽셀이 잘랐는지 여부를 알 수 없으므로 미리 컬링할 수 없습니다.
• 및 그 뒤에 색상을 혼합해야 하는 다른 작업을 수행합니다.

12.4.4 Transaction Elimination

TE(트랜잭션 제거)는 시스템 온 칩(SoC)에서 상당한 에너지 절감 효과를 제공하는 Mali GPU 아키텍처의 핵심 대역폭 절약 기능입니다.
TE를 실행할 때 GPU는 현재 프레임 버퍼를 이전에 렌더링된 프레임과 비교하여 수정된 특정 부분만 부분적으로 업데이트하므로 프레임당 외부 메모리로 전송되는 데이터의 양이 크게 줄어듭니다. 비교는 타일 단위로 수행되며, CRC(순환 중복 검사) 서명을 사용하여 타일이 수정되었는지 여부를 판단합니다(CRC 서명이 동일한 타일은 동일한 것으로 판단하여 해당 타일의 데이터 전송을 무시합니다).
 

Graphics Technologies | Transaction Elimination – Arm®

 

순환 중복 검사(CRC)는 네트워크 패킷, 컴퓨터 파일, 메모리 데이터 스트림 등의 데이터를 기반으로 짧은 고정 비트 체크섬 코드를 생성하는 해시 함수로, 주로 데이터 전송 또는 저장 후 발생할 수 있는 오류를 감지하거나 검사하는 데 사용됩니다. 여기서는 Mali GPU에서 이 프레임의 타일 데이터가 이전 프레임 버퍼 데이터와 동일한지 여부를 감지하는 데 사용됩니다.

TE(트랜잭션 제거) 기술 동작 요약. 현재 프레임은 각 청크에 대해 CRC 키 값을 계산하여 다음 프레임에서 각 청크를 비교하여 데이터 변경이 있는지 확인하고 변경 사항이 없는 청크에 대해서는 데이터 전송을 취소합니다. 그림 오른쪽 하단의 녹색 청크는 이전 프레임과 일치하므로 프레임 버퍼에 데이터를 전송할 필요가 없으므로 인터랙티브 게임의 경우 평균 20% 이상 대역폭이 감소합니다.
TE 기법을 수행해도 최종 이미지 품질에는 영향을 미치지 않으며 프레임 버퍼 정확도 요구 사항에 관계없이 GPU에서 지원하는 모든 프레임 버퍼 형식의 모든 애플리케이션에 사용할 수 있습니다. 또한 TE는 시스템 메모리(프레임 버퍼)에 타일 쓰기(아래 그림의 왼쪽 하단) 중에 발생한다는 점에 유의해야 합니다.

12.4.5 Forward Pixel Kill

Forward Pixel Kill(FPK)은 Mali-T62X 및 T678 이상 칩에 내장된 오버드로 감소 기술입니다.
FPK 지원 GPU에서는 픽셀 셰이딩 스레드가 시작되더라도 되돌릴 수 없게 완료되지 않습니다. 렌더링 파이프라인에서 이후 스레드가 동일한 픽셀 위치에 불투명 데이터를 쓰는 것을 발견하면 진행 중인 계산이 언제든지 종료될 수 있습니다. 각 스레드는 완료하는 데 한정된 시간이 걸리기 때문에 이미 파이프라인에 있는 픽셀을 종료하는 데 악용할 수 있는 시간 창이 있습니다. 사실상 파이프라인의 깊이는 미래를 예측하는 효과를 시뮬레이션하는 데 사용됩니다.
FPK 지원 GPU에는 Early-Z 테스트를 통과하고 픽셀 셰이딩 계산에 들어가려는 쿼드를 저장하는 데 사용되는 FIFO(First In First Out) 버퍼(Early Z 테스트와 픽셀 셰이더 사이, 아래 참조)가 있습니다.

FPK의 작동 메커니즘을 구체적으로 설명하기 위해 다음 그림을 예로 들어보겠습니다:

위 그림에서 새로운 Quad(위치 10, 깊이 0)가 EarlyZ 테스트를 통과하고 FPK FIFO 버퍼로 들어가려고 하는데, 위치 10 깊이 10이 이미 FIFO에 존재한다는 사실을 알게 되고, 새로 들어오는 Quad가 FIFO 큐의 Quad를 대체합니다(새 깊이가 화면에 더 가깝기 때문). 즉, FPK FIFO에 있는 쿼드는 새로 들어오는 쿼드로 대체되고 위치는 같고 깊이는 더 작아집니다(더 가까워집니다).

FIFO Buffer : 선입선출형 버퍼

FPK에 대해 몇 가지 참고 사항을 추가해야 합니다:
 

• FPK 컬링 세분성은 쿼드(2x2 픽셀 블록)입니다.
• FPK는 불투명 오브젝트에만 유효합니다.
• 깊이 테스트가 작동하려면 FPK가 켜져 있어야 합니다.

12.4.6 Hidden Surface Removal

HSR(숨겨진 표면 제거)은 숨겨진 표면 제거를 의미하며, PowerVR 칩에 특화된 기술입니다. HSR 기술을 사용하면 그리기 순서와 관계없이 오버드로를 제로로 만들 수 있습니다.

왼쪽 아래는 가려진 픽셀의 컬링을 수행하지 않는 기존 GPU이고, 오른쪽 아래는 PowerVR이 HSR을 사용하여 수행할 수 있는 픽셀 수준 컬링을 보여줍니다.

Early-Z 테스트가 포함된 아키텍처에서 애플리케이션은 드로우 호출을 앞뒤로 제출하여 일부 오버드로를 피할 수 있으며, 이 순서대로 제출하면 깊이 버퍼가 생성되므로 카메라에서 가려진 픽셀을 가능한 한 빨리 컬링할 수 있습니다. 하지만 카메라나 씬의 오브젝트가 움직일 때마다 그리기 순서를 지정해야 하므로 애플리케이션에 추가적인 부담이 됩니다. 또한 그리기별 정렬은 매우 거칠기 때문에 모든 오버드로를 제거할 수 없습니다. 예를 들어 오브젝트 교차로 인해 발생하는 오버드로를 해결할 수 없습니다. 또한 애플리케이션이 그래픽 API 상태 변경을 최소화하기 위해 그리기 호출을 정렬하지 못하도록 합니다.

PowerVR의 TBDR을 사용하면 오브젝트가 제출되는 순서(정렬 없음)에 관계없이 오버드로우를 완전히 방지할 수 있으며, 특히 픽셀을 래스터화하여 어느 픽셀에 속하는지 표시(삼각형)하고 태그 버퍼에 저장한 후 장면의 모든 픽셀이 처리될 때까지 기다리는 방식으로 순차적 그리기에 의존하지 않는 픽셀 수준 컬링이 가능합니다. HSR 단계는 래스터화 후 픽셀 셰이딩 전에 이루어집니다:

12.4.7 Low Resolution Z pass

저해상도 Z 패스, 줄여서 LRZ는 TBR이 조기 Z 컬링을 수행할 때 Adreno A5X 이상 칩에 최적화하는 기술입니다.
비닝 패스 단계에서 GPU는 비닝 단계의 성능을 향상시키기 위해 가려진 영역을 컬링하기 위해 LRZ-Tile(빈 타일이 아님)의 세분성을 가진 저해상도 Z 버퍼를 구성합니다(참고: 빈 타일이 아님). 이 LRZ는 렌더링 패스에서 전체 해상도 Z 버퍼를 테스트하기 전에 픽셀을 효과적으로 컬링하는 데에도 사용할 수 있습니다.
이 기능의 장점은 메모리 액세스 및 대역폭 감소, 애플리케이션이 앞뒤로 그릴 필요가 없는 렌더링된 튜플 수 감소, 프레임 속도 향상입니다.
그러나 다음과 같은 조건에서는 LRZ 기법이 효과가 없을 수 있습니다:

• 픽셀 셰이더에 깊이 값을 씁니다.
• 그래픽 API(Vulkan)의 보조 명령 버퍼를 사용합니다.
• IMR 직접 렌더링이 필요한 모든 조건.

12.4.8 FlexRender

Adreno 칩의 고유 기술인 FlexRender는 TBR(비닝)과 IMR(다이렉트 렌더링) 모드를 혼합하여 두 모드를 동적으로 전환함으로써 성능을 극대화하는 렌더링 기술입니다.

직접 렌더링 모드에서는 GPU가 GMEM을 우회하여 시스템 메모리와 직접 상호 작용하고, 비닝 모드에서는 GPU가 GMEM을 통해 시스템 메모리와 상호 작용합니다.
드라이버와 GPU는 주어진 렌더링 대상의 렌더링 파라미터를 분석하여 자동으로 모드를 선택합니다. 예를 들어 렌더링 대상 크기가 매우 작은 경우 렌더링 소비를 줄이기 위해 IMR 모드로 적극적으로 전환하고(TBR에는 기본 소비가 있음), 오클루전 컬링을 수행해야 하는 경우 IMR 모드로도 전환합니다(이전에 TBR 모드였던 경우에도).
일반적으로 IMR 모드는 TBR 모드보다 더 많은 에너지를 소비합니다:

GFXBench 맨해튼 3.0에서 모니터링하는 다이렉트 모드와 비닝 모드에서 스냅드래곤 SoC의 에너지 소비를 비교한 결과, 후자는 약 20%를 절약할 수 있습니다.

12.4.9 Universal Bandwidth Compression

Adreno A5x 이상 칩에 추가된 범용 대역폭 압축 기술인 UBWC(Universal Bandwidth Compression) 는 데이터 대역폭을 최소화하여 시스템 메모리의 유효 처리량을 개선하고 상당한에너지 절약.
GPU 칩 외에도 디스플레이, 비디오, 카메라 등 스냅드래곤 CPU의 여러 구성 요소에 UBWC 기술이 적용되고 있습니다.압축은 YUV 및 RGB 형식을 모두 지원하여 메모리 병목 현상을 줄여줍니다.

UBWC는 Qualcomm의 칩에서 사용되지만, 구글 개발자, Freedreno 드라이버에 범용 대역폭 압축 기여에 따르면 이 기술은 실제로 Freedreno 오픈 소스 드라이버에서 제공되고 있음을 알 수 있습니다.이 문서에서는 UBWC에서 사용하는 정확한 압축 알고리즘은 언급되지 않았습니다.

12.4.10 Arm Frame Buffer Compression

Arm 프레임 버퍼 압축(AFBC)은 Arm 설계 GPU 전용으로, 모바일 기기의 열 제약 내에서 점점 더 복잡해지는 디자인을 제작해야 하는 어려움을 해결합니다.가장 중요한 애플리케이션은 비디오 포스트 프로세싱으로, 많은 사용 사례에서 GPU는 비디오 스트림을 2D 또는 3D 장면의 텍스처로 사용할 때 비디오를 읽고 특수 효과를 적용해야 합니다.이러한 경우 AFBC는 공간적으로 조정된 이미지 데이터를 전송하는 데 필요한 전체 시스템 수준의 대역폭과 전력 비용을 최대 50%까지 절감할 수 있습니다.

AFBC 작동의 개략도.
무손실 압축 프로토콜 및 포맷인 AFBC는 SoC의 IP 블록 간 데이터 전송량을 최소화합니다. 구체적으로 AFBC에는 다음과 같은 기능이 있습니다:

• 무손실 압축 포맷. 이 압축 형식은 다른 무손실 압축 표준에 비해 원본 이미지의 정확도와 압축률을 유지합니다.
• Mali GPU에서 완벽하게 지원됩니다.
• 에너지 소비 감소. 주로 대역폭 감소로 인한 이점이 있습니다.
• 면적 효율이 높은 SoC 설계. AFBC는 면적 비용 없이 설계에 추가할 수 있습니다.
• 최악의 압축률 제한. 최악의 경우(랜덤 액세스) 효율이 4x4 수준으로 떨어집니다.
• YUV 및 RGB 형식을 모두 지원하며, YUV 압축 비율은 일반적으로 50%입니다.

12.4.11 Index-Driven Vertex Shading

인덱스 기반 버텍스 셰이딩(IDVS)은 각 렌더 패스의 버텍스 처리 단계에서 발생하는 Mali GPU 내 버텍스 처리 최적화 기술입니다.
IDVS의 주요 특징은 기존 버텍스 셰이더를 두 단계로 나눈다는 점입니다:

• 첫 번째 단계는 모든 종류의 버텍스 컬링 전에 발생하는 포지션 셰이딩으로, 이 단계에서는 버텍스에 다른 연산을 수행하지 않고 버텍스 위치만 변환합니다.
• 두 번째 단계는 다양한 유형의 버텍스 컬링 이후에 발생하는 가변 셰이딩으로, 다양한 유형의 컬링을 통과한 버텍스만 처리하며 버텍스의 위치 변환 이외의 연산을 수행합니다.

IDVS는 버텍스 셰이더를 위치 셰이딩과 가변 셰이딩의 두 단계로 분할합니다.
IDVS 기술의 장점은 다음과 같습니다:

• 대부분의 경우 베리잉 셰이딩은 포지션 셰이딩보다 퍼포먼스를 더 많이 소모합니다. 유효하지 않은 버텍스는 다양한 유형의 버텍스 컬링 단계를 통해 제거하여, 퍼포먼스를 소모하는 베리잉 셰이딩에 들어가지 않도록 합니다.
• IDVS 기술의 버텍스 속성 레이아웃을 일치시킴으로써 데이터 읽기 양을 줄이고, 캐시 적중률을 개선하며, 성능을 향상시키고, 전력 소비를 줄일 수 있습니다. IDVS 기술 매칭을 위한 버텍스 속성 레이아웃은 다음과 같습니다:
  
  • 정점의 위치는 별도의 데이터 스트림으로 분리되어 다음과 같이 배치됩니다:
  • xyz | xyz | xyz | ...
  • 예를 들어, 위치 이외의 정점의 속성을 배열의 구조(SoA)에 따라 배치합니다(예: 배열의 구조):
  • color,uv,normal | color,uv,normal | color,uv,normal | ...

IDVS 버텍스 데이터 흐름 분할 최적화 및 상호 작용의 개략도.

12.4.12 Pixel Local Storage

픽셀 로컬 스토리지(PLS)는 OpenGL ES의 데이터 액세스 방법입니다. PLS로 선언된 데이터는 GPU의 타일 버퍼(아래)에 저장됩니다.

PLS가 활성화되면 렌더링 파이프라인에서 색상 작업, 블렌딩 등을 효율적으로 수행할 수 있습니다. GLSL은 다음 표에 설명된 대로 세 가지 유형의 PLS 데이터 키워드를 선언합니다:
키워드 역할

키워드	작용
__pixel_localEXT	읽기 및 쓰기 가능한 데이터.
__pixel_local_inEXT	읽기 전용 데이터.
__pixel_local_outEXT	데이터 쓰기만 가능합니다.

디퍼드 렌더링을 예로 들어 PLS를 적용하는 경우 의사 코드는 아래와 같습니다:

// ------GBuffer 생성------
__pixel_local_outEXT FragData // 데이터 쓰기 전용
{
    layout(rgba8) highp vec4 Color;
    layout(rg16f) highp vec2 NormalXY;
    layout(rg16f) highp vec2 NormalZ_LightingB;
    layout(rg16f) highp vec2 LightingRG;
}gbuf;

void main()
{
    gbuf.Color = CalcDiffuseColor();
    vec3 Normal = CalcNormal();
    gbuf.NormalXY = Normal.xy;
    gbuf.NormalZ_LightingB.x = Normal.Z;
}

// ------빛 축적------
__pixel_localEXT FragData // 데이터 읽기/쓰기
{
    layout(rgba8) highp vec4 Color;
    layout(rg16f) highp vec2 NormalXY;
    layout(rg16f) highp vec2 NormalZ_LightingB;
    layout(rg16f) highp vec2 LightingRG;
}gbuf;

void main()
{
    vec3 Lighting = CalcLighting(gbuf.NormalXY, gbuf.NormalZ_LightingB.x);
    gbuf.LightingRG += Lighting.xy;
    gbuf.NormalZ_LightingB.y += Lighting.z;
}

// ------파이널 컬러------
__pixel_local_inEXT FragData // 읽기 전용 데이터
{
    layout(rgba8) highp vec4 Color;
    layout(rg16f) highp vec2 NormalXY;
    layout(rg16f) highp vec2 NormalZ_LightingB;
    layout(rg16f) highp vec2 LightingRG;
}gbuf;

out highp vec4 FragColor;

void main()
{
    FragColor = resolve(gbuf.Color, gbuf.LightingRG, gbuf.NormalZ_LightingB.y);
}

PLS를 사용하여 지연 렌더링을 수행하는 실행 도식은 아래와 같습니다(오른쪽 상단의 작은 사각형의 빨간색은 렌더링 지오메트리 데이터 단계를, 초록색은 렌더링 조명 단계를 나타냅니다):
 

OpenGL ES 외에도 Metal, Vulkan, D3D 등의 그래픽 API는 GPU 타일에서 데이터 조작을 지원하기 위해 해당 인터페이스, 키워드 또는 플래그를 제공합니다.
위의 코드는 지연된 셰이딩에 필요한 GBuffer 데이터가 항상 PLS에 있으며, 시스템 메모리에 GBuffer를 다시 쓰지 않고 최종 색상을 반환하기 위해 가장 잘 파싱된다는 것을 보여줍니다(아래).

PLS는 성능을 약 22% 향상시킬 수 있습니다:

UE4는 또한 파티클의 효율적인 소프트 믹싱을 위해 PLS를 활용합니다:

왼쪽: 파티클 일반 블렌딩 모드, 오른쪽: 파티클 소프트 블렌딩 모드.
벌칸에도 서브패스라는 비슷한 메커니즘이 있습니다(이후 챕터 참조).

12.4.13 subpass

서브패스는 TB(D)R 하드웨어 아키텍처의 산물이며 Vulkan, DX12, Metal 등과 같은 최신 그래픽 API에 적합합니다. 기본 원리는 픽셀 로컬 스토리지와 유사합니다.
서브패스를 사용하기 위한 몇 가지 특별한 요구 사항이 있습니다:

• 모든 서브패스는 동일한 렌더 패스에 있어야 합니다.
• 주변 이웃 픽셀을 샘플링할 필요가 없습니다.(그렇지 않으면 데이터가 여러 타일에 걸쳐 액세스되고 모든 데이터 액세스를 동일한 타일 내에 유지할 수 없습니다.)
• GPU는 TB(D)R 하드웨어 아키텍처를 지원합니다.
• 벌칸, DX12, 메탈 및 기타 최신 그래픽 API를 지원합니다.

각 렌더패스와 서브패스는 각 어태치먼트에 대해 로드옵과 스토어옵을 지정하여 액세스 동작을 정밀하게 제어할 수 있습니다:

서브패스용 로드옵 마커에는 3가지 유형이 있습니다:

• LOAD_OP_LOAD：글로벌 메모리에서 타일에 첨부 파일을 로드합니다.
• LOAD_OP_CLEAR：타일 버퍼에서 데이터를 지웁니다.
• LOAD_OP_DONT_CARE：타일 버퍼의 데이터에는 아무 작업도 하지 않으며, 일반적으로 타일 내의 데이터를 전체적으로 재할당하는 데 사용되므로 LOAD_OP_CLEAR보다 더 효율적입니다.

위의 3가지 마커 실행의 효율성：LOAD_OP_DONT_CARE > LOAD_OP_CLEAR > LOAD_OP_LOAD。벌칸 사용 예시 코드:

VkAttachmentDescription colorAttachment = {};
colorAttachment.format = VK_FORMAT_B8G8R8A8_SRGB;
colorAttachment.samples = VK_SAMPLE_COUNT_1_BIT;
// loadOp에 DONT_CARE 레이블을 지정합니다.
colorAttachment.loadOp = VK_ATTACHMENT_LOAD_OP_DONT_CARE;

서브패스용 storeOp 태그에는 두 가지 유형이 있습니다:

• STORE_OP_STORE：타일 내의 데이터를 전역 메모리에 저장합니다.
• STORE_OP_DONT_CARE：타일 버퍼의 데이터에 대한 저장 작업을 수행하지 않습니다.

위 두 플래그의 실행 효율성: STORE_OP_DONT_CARE > STORE_OP_STORE.Vulkan 사용 예시 코드:

VkAttachmentDescription colorAttachment = {};
colorAttachment.format = VK_FORMAT_B8G8R8A8_SRGB;
colorAttachment.samples = VK_SAMPLE_COUNT_1_BIT;
// 标明loadOp为DONT_CARE.
colorAttachment.loadOp = VK_ATTACHMENT_LOAD_OP_DONT_CARE;
// 标明storeOp为DONT_CARE.
colorAttachment.storeOp = VK_ATTACHMENT_STORE_OP_DONT_CARE;

셰이더에 명시적 키워드(__pixel_localEXT, __pixel_local_inEXT, __pixel_local_outEXT)를 사용하여 타일 내 변수를 선언하는 OpenGL ES와 달리, Vulkan은 타일 내에 어태치먼트를 저장하기 위해 플래그 TRANSIENT_ATTACHMENT 및LAZILY_ALLOCATED 플래그를 사용해야 합니다:

VkImageCreateInfo imageInfo{VK_STRUCTURE_TYPE_IMAGE_CREATE_INFO};
imageInfo.flags		= flags;
imageInfo.imageType	= type;
imageInfo.format	= format;
imageInfo.extent	= extent;
imageInfo.samples	= sampleCount;
// 이미지는 TRANSIENT_ATTACHMENT 태그를 사용합니다.
imageInfo.usage		= VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT;

VmaAllocation memory;
VmaAllocationCreateInfo memoryInfo{};
memoryInfo.usage		  = memoryUsage;
// 이미지가 저장된 메모리는 LAZILY_ALLOCATED로 표시됩니다.
memoryInfo.preferredFlags = VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT;

// 이미지 만들기.
auto result = vmaCreateImage(device.get_memory_allocator(), &imageInfo, memoryInfo, &handle, &memory, nullptr);

서브패스의 로드옵과 스토어옵으로 최적화한 후 Vulkan의 공식 테스트 예시에서는 글로벌 메모리 읽기 36%, 글로벌 메모리 쓰기 62%, 슬라이스 실행 주기 7%가 감소한 것으로 나타났습니다:
 

또한 아래에 설명된 대로 올바른 storeOp 및 loadOp을 사용하여 타일 내에서 MSAA 데이터를 효율적으로 구문 분석할 수 있습니다:

• MSAA가 포함된 이미지(또는 첨부 파일)는 일시적이어야 하며, 렌더 패스가 끝날 때 다음 마커를 통해 MSAA를 파싱한 후 데이터를 얻을 수 있습니다:
  • loadOp = LOAD_OP_CLEAR；
  • storeOp = STORE_OP_DONT_CARE；
  • LAZILY_ALLOCATED 메모리 태그를 사용합니다;
  • 서브패스에서 pResolveAttachments 태그를 사용합니다.
• 딥 템플릿이 있는 첨부 파일에서도 비슷한 효과를 얻을 수 있습니다:
  • VK_KHR_depth_stencil_resolve 태그를 사용합니다;
  • 벌칸 1.2 이상 API만 지원됩니다.

위의 접근 방식을 사용하면 MSAA 데이터를 전역 메모리로 전송하지 않고도 타일 내에서 MSAA 데이터를 효율적으로 파싱할 수 있습니다.또한 MSAA를 해결하기 위해 vkCmdResolveImage 인터페이스를 사용하지 않도록 해야 합니다:

위: vkCmdResolveImage를 사용한 잘못된 MSAA 구문 분석 데모, 아래: in-Tile을 사용한 올바른 MSAA 구문 분석 데모.
서브패스의 로드옵과 스토어옵을 사용하여 MSAA 구문 분석을 최적화한 후 Vulkan의 공식 테스트 예시에서는 전역 메모리 읽기가 261% 감소하고 전역 메모리 쓰기가 440% 감소한 것으로 나타났습니다!

최적화 결과가 보입니다!무엇을 망설이고 계십니까? 서브패스라는 유리한 무기를 사용하여 애플리케이션을 최적화하세요!
자세한 지침은 공식 벌칸 단체인 크로노스그룹의 깃허브를 참고하세요: 렌더 패스 어태치먼트의 적절한 사용.
UE의 서브패스 래핑에 대한 자세한 내용은 10.4.4.2 서브패스 렌더링을 참조하세요.

12.4.14 Adaptive Scalable Texture Compression

적응형 확장 가능 텍스처 압축(ASTC)은 Arm과 AMD가 공동 개발한 텍스처 압축 포맷입니다. 고정 블록 크기(4x4)인 ETC 및 ETC2와 달리 ASTC는 가변 블록 크기 압축을 지원하여 텍스처 데이터의 유연하고 큰 압축 비율을 제공하며, 감소된GPU 대역폭과 에너지 소비를 줄일 수 있습니다.
ASTC는 아직 OpenGL의 표준 형식은 아니며 확장 형태로만 존재하지만, 현재 메인스트림 GPU에서 널리 지원되며 표준이 아닌 것을 표준으로 확장한 것으로 간주할 수 있습니다.하지만 벌칸에서 ASTC는 이미 표준 기능입니다.구체적으로 ASTC는 다음과 같은 기능을 지원합니다:

• 포맷 유연성.ASTC는 RGB+A(상관된 RGB, 상관되지 않은 알파)와 같은 비연관 채널을 포함해 1~4채널의 데이터를 압축할 수 있습니다.또한 블록 크기는 4x4, 5x4, 6x5, 10X5 등 가변적입니다.
• Adreno A5X 이상 GPU 칩은 ASTC보다 다양한 블록 크기 형식(2D 및 3D 모두)을 지원합니다:
  • ASTC_4X4
  • ASTC_5X4
  • ASTC_5X5
  • ASTC_6X5
  • ASTC_6X6
  • ASTC_8X5
  • ASTC_8X6
  • ASTC_8X8
  • ASTC_10X5
  • ASTC_10X6
  • ASTC_10X8
  • ASTC_10X10
  • ASTC_12X10
  • ASTC_12X12
  • ASTC_3X3X3
  • ASTC_4X3X3
  • ASTC_4X4X3
  • ASTC_4X4X4
  • ASTC_5X4X4
  • ASTC_5X5X4
  • ASTC_5X5X5
  • ASTC_6X5X5
  • ASTC_6X6X5
  • ASTC_6X6X6
• 유연한 비트 전송률.ASTC는 이미지를 압축할 때 텍셀당 0.89비트에서 8비트(bpt) 사이의 다양한 비트 전송률을 제공합니다.비트 전송률 선택은 컬러 포맷 선택과 무관합니다.반면, ETC와 같은 기존 포맷은 정수의 비트 전송률로 제한됩니다.
• 고급 포맷 지원.ASTC는 저다이나믹 레인지(LDR), LDR sRGB, 하이 다이나믹 레인지(HDR) 색 공간과 3D 볼류메트릭 텍스처로 이미지를 압축할 수 있습니다.
• 향상된 이미지 품질.높은 수준의 포맷 유연성에도 불구하고 ASTC는 동일한 비트 전송률에서 이미지 품질 측면에서 거의 모든 기존 텍스처 압축 포맷(ETC2, PVRCT, BC 등)보다 뛰어난 성능을 발휘합니다.
• 포맷 매트릭스의 전체 범위.ASTC가 출시되기 전의 기존 텍스처 압축 포맷은 다음 그림과 같이 상대적으로 적은 수의 색상 포맷과 비트 전송률 조합을 지원했습니다:

위의 포맷은 그래픽 API 또는 운영 체제에 의해 제한되므로 단일 플랫폼의 압축 옵션은 매우 제한적입니다. ASTC의 출현으로 필요한 포맷 매트릭스를 거의 완벽하게 커버하여 콘텐츠 제작자에게 광범위한 비트레이트 옵션을 제공함으로써 위의 문제를 해결했습니다.아래 차트는 사용 가능한 포맷과 비트레이트를 보여줍니다:

ASTC는 어떻게 위의 목표를 달성할 수 있을까요?그 해답은 ASTC가 특별한 압축 알고리즘과 데이터 구조를 사용한다는 사실에 있으며, ASTC 알고리즘의 기술적 포인트는 다음과 같습니다:

• 블록 압축
  
  • 하나의 샘플링 좌표만 주어지면 메모리에 있는 데이터의 주소가 계산됩니다.
  • 주변 데이터를 너무 많이 압축 해제하지 않고 무작위 샘플의 압축을 해제하는 기능.
  ASTC를 포함한 모든 최신 실시간 압축 포맷에서 사용하는 표준 솔루션은 이미지를 고정된 크기의 픽셀 블록으로 분할한 다음 각 블록을 고정된 수의 출력 비트로 압축하는 것입니다.이렇게 하면 셰이더가 어떤 순서로든 텍셀에 빠르게 액세스할 수 있고 압축 해제 비용도 저렴합니다.
• ASTC의 2D 블록 풋프린트는 4x4 텍셀에서 12x12 텍셀까지 다양하며, 128비트 출력 블록으로 압축됩니다.포맷 비트레이트는 128비트를 점유 공간의 픽셀 수로 나누어 구하며, 이 비트레이트의 범위는 8bpt ( 128/ (</a12>4⋅4) 128/(4⋅4)</a21> ) ~ 0.89 bpt ( 128/ (</a33>12⋅12) 128/(12⋅12)</a42> ).아래는 다양한 비트레이트에서의 화질 비교 차트입니다:
• 실시간 그래픽의 압축 포맷은 무작위 샘플을 텍스처로 빠르고 효율적으로 변환할 수 있어야 하므로 압축 기술에는 다음 사항이 충족되어야 합니다.

• 컬러 엔드포인트
  
  • 색상 채널 수입니다. 예: 휘도, 휘도+알파, RGB 또는 RGBA.
  • 코딩 방법. 예를 들면 직접, 베이스 + 오프셋, 베이스 + 스케일 또는 정량화 수준 등이 있습니다.
  • 데이터 범위. 예를 들어 낮은 동적 범위 또는 높은 동적 범위입니다.
  블록 단위로 다양한 엔드포인트 모드와 엔드포인트 색상 BISE 양자화 수준을 선택할 수 있습니다.
• 블록의 색상 데이터는 두 색상 엔드포인트 사이의 그라데이션으로 인코딩됩니다.각 텍셀은 그라데이션을 따라 위치를 선택한 다음 압축 해제 중에 보간되며, ASTC는 엔드포인트 모드라고 하는 16색 엔드포인트 인코딩 체계를 지원합니다.엔드포인트 모드 옵션을 통해 다음을 변경할 수 있습니다:
• 컬러 파티션
• 블록 내의 색상은 종종 복잡하며 단일 색상 그라데이션으로는 블록 내의 모든 색상을 정확하게 포착할 수 없습니다.예를 들어, 녹색 잔디 위에 놓인 빨간색 공은 아래와 같이 두 가지 색상으로 구분해야 합니다:

ASTC에서는 단일 블록이 파티션이라고 하는 최대 4개의 색상 그라데이션을 참조할 수 있습니다.압축 해제를 위해 각 텍셀은 별도의 파티션에 할당됩니다.
각 텍셀에 대한 파티션 할당을 직접 저장하려면 모든 블록 크기를 저장하기 위해 상당한 양의 압축 해제 하드웨어가 필요합니다. 대신, ASTC는 파티션 인덱스를 SEED 값으로 사용해 일련의 패턴을 알고리즘적으로 생성합니다.압축 프로세스는 각 블록에 대해 가장 잘 일치하는 패턴을 선택한 다음, 블록은 가장 잘 일치하는 패턴의 인덱스만 저장하면 됩니다.다음 그림은 8×8 블록 크기의 2(이미지 상단), 3(이미지 중간), 4(이미지 하단) 파티션에 대해 생성된 패턴을 보여줍니다.

• 파티션 수와 파티션 인덱스는 블록 단위로 선택할 수 있으며, 각 파티션마다 다른 색상의 엔드포인트 패턴을 선택할 수 있습니다.
• 색상 코딩
• ASTC는 그라데이션을 사용해 각 픽셀의 색상 값을 지정합니다.각 압축 블록은 그라데이션의 끝점 색상과 각 픽셀에 대한 보간된 가중치를 저장합니다.압축 해제 시 각 픽셀의 색상 값은 각 픽셀의 가중치에 따라 두 엔드포인트 색상 사이에서 보간하여 생성됩니다.아래 그림은 다양한 픽셀 가중치에 대한 보간을 보여줍니다:

사각형에는 녹색 잔디 위에 빨간색 공이 놓여 있는 것처럼 복잡한 색상 분포가 포함되는 경우가 많습니다.이러한 경우 단일 색상 그라데이션으로는 다양한 텍셀 색상 값을 모두 정확하게 표현할 수 없습니다. ASTC를 사용하면 블록에 파티션이라고 하는 최대 4개의 서로 다른 색상 그라데이션을 정의할 수 있으며, 각 텍셀을 별도의 파티션에 할당할 수 있습니다.다음 그림은 파티션 인덱스가 각 텍셀에 색상 그라데이션을 할당하는 방법을 보여줍니다(빨간색 공 픽셀과 녹색 잔디 픽셀에 각각 하나씩, 총 2개의 파티션).

알파벳 저장
각 픽셀의 색상 및 가중치 값은 이론적으로 부동 소수점 값이지만, 실제 값을 직접 저장하기에는 사용 가능한 비트 수가 너무 적습니다.저장 크기를 줄이려면 압축 중에 이러한 값을 양자화해야 합니다.예를 들어 각 텍셀에 0.0~1.0 범위의 부동 소수점 가중치가 있는 경우 0.0, 0.25, 0.5, 0.75, 1.0의 다섯 가지 값으로 양자화하도록 선택한 다음 0~4 정수를 사용하여 저장소에서 이 다섯 가지 양자화된 값을 나타낼 수 있습니다.
일반적으로 N 레벨을 양자화하려면 N개의 기호를 포함하는 문자 테이블에 문자를 효율적으로 저장할 수 있어야 합니다.N개의 기호로 구성된 문자 테이블은 각 문자에 대해 log2(N) 비트의 정보를 포함합니다.5개의 가능한 기호로 구성된 문자 테이블이 있는 경우 각 문자는 약 2.32비트의 정보를 포함하지만 단순 이진 저장 시 3비트로 반올림해야 하므로 저장 용량의 22.3%가 낭비됩니다.다음 차트는 단순 이진 인코딩을 사용하여 N개의 기호로 구성된 문자 테이블을 저장할 때 낭비되는 비트 공간의 비율을 보여줍니다.

위의 차트는 대부분의 문자 크기에서 문자당 정수 비트를 사용하면 저장 용량이 많이 낭비된다는 것을 보여줍니다. 압축 포맷의 경우 효율성이 매우 중요하므로 이 문제는 ASTC가 해결해야 할 문제입니다.

한 가지 해결책은 양자화 레벨을 2의 거듭제곱으로 반올림하여 여분의 비트가 낭비되지 않도록 하는 것입니다. 그러나 이 솔루션은 인코더가 더 큰 이득을 위해 다른 곳에서 사용할 수 있는 비트를 소비하게 되므로 이미지 품질이 저하되고 최적이 아닙니다.

• 퀸트 및 트릿 숫자( Quint and trit )
  5원자를 3비트로 결합하는 것보다 5원자 3개를 결합하는 것이 더 효율적인 해결책입니다.한 퀸트에는 5³= 125개의 문자 조합이 있으며, 6.97비트의 정보가 들어 있습니다.이 세 개의 퀸트 문자를 7비트 형태로 저장하면 0.5%의 저장 공간만 낭비할 수 있습니다.비슷한 방식으로 3그룹이라고 하는 세 개의 기호 알파벳을 구성하고 세 개의 문자 그룹으로 이루어진 다섯 개의 그룹을 결합할 수도 있습니다.각 문자 그룹에는 3⁵=243개의 조합으로 7.92비트의 정보를 담고 있습니다.이 5개의 트릿 문자를 8비트 형태로 저장하면 1%의 저장 공간만 낭비할 수 있습니다.
• 바운드 정수 시퀀스 인코딩(BISE)
  
  • 최대 2ⁿ- 1개를 포함하는 기호의 알파벳은 문자당 n비트를 사용하여 인코딩할 수 있습니다.
  • 최대 3⋅(2𝑛-1) 기호화된 알파벳은 각 문자를 n비트(m)와 트릿(t)으로 사용하고 다음 방정식 (𝑡⋅2^𝑛)+𝑚 재구성.
  • 최대 5⋅(2^𝑛-1) 기호화된 알파벳은 각 문자를 n비트(m)와 퀸트(q)로 사용하고 다음 방정식(𝑞⋅2^𝑛)+𝑚 을 사용하여 인코딩할 수 있습니다.
  시퀀스의 문자 수가 3 또는 5의 배수가 아닌 경우 시퀀스 끝에서 저장 공간을 낭비하지 않도록 하는 것이 중요하므로 인코딩에 또 다른 제약 조건이 추가됩니다.시퀀스에서 인코딩할 마지막 몇 개의 값이 0인 경우 인코딩된 비트 문자열의 마지막 몇 비트도 0이어야 합니다.이상적으로는 0이 아닌 비트의 수를 계산하기 쉽고 이전에 인코딩된 값의 크기에 의존하지 않는 것이 좋습니다.이 문제는 압축 중에 제대로 처리하기 어렵지만 해결 방법이 있습니다.즉, 비트 시퀀스 끝에 패딩을 저장할 필요가 없는데, 이는 0비트라고 안전하게 가정할 수 있기 때문입니다.
  • S의 최대값은2^N-12𝑁-1 이며, 𝑁⋅𝑆 비트 활용.
  • S의 최대값은3⋅ 2^𝑁-1이며,  𝑁⋅𝑆+ceil(8𝑆/5) 비트 활용.
  • S의 최대 값은 5⋅2^𝑁-1 이며,  𝑁⋅𝑆+ceil(7𝑆/3) 비트 활용.
  압축기는 저장되는 문자의 크기에 대해 가장 작은 저장 공간을 제공하는 옵션을 선택합니다.일부는 바이너리를, 일부는 비트와 트릿을, 일부는 비트와 퀸트를 사용합니다. 다음 그림은 바이너리 스토리지에 비해 BISE 스토리지의 효율성 이득을 보여줍니다:
• 이 제약 조건으로 비트, 트릿, 퀸트의 지능적인 패킹을 통해 BISE는 고정된 비트 수를 사용하여 N 기호 알파벳에서 S 문자열을 인코딩합니다.
• ASTC에서 사용하는 바운드 정수 시퀀스 인코딩(BISE) 은 최대 256개의 기호로 구성된 임의의 문자를 사용하여 문자 시퀀스를 저장할 수 있습니다.각 문자 크기는 공간 효율이 가장 높은 비트, 달러, 5를 사용하여 인코딩됩니다.

또한 압축 과정에서 각 블록에 대해 최적의 인코딩이 선택되며, 텍셀 가중치 값을 계산할 때 위에서 언급한 BISE 외에도 이중 평면 가중치(Dual-plane weights) 알고리즘이 있습니다.
ASTC는 무료로 사용할 수 있고 통합이 쉬우며 많은 주요 시스템과 하드웨어에서 지원됩니다.ASTC를 지원하려면 다음 OpenGL 확장이 필요합니다:

GL_AMD_compressed_ATC_texture
GL_ANDROID_extension_pack_es31a

기존의 텍스처 압축 포맷(ETC, BC, PVRTC 등)에 비해 ASTC를 사용한 압축 효과는 원본 이미지에 가까운 화질과 높은 압축률로 매우 눈에 띄게 나타납니다:

왼쪽: 원본 노멀 매핑, 가운데: ETC로 압축한 효과, 오른쪽: ASTC로 압축한 효과.
이를 통해 직관적으로 얻을 수 있는 이점은 메모리와 대역폭을 덜 차지하고 프레임당 대역폭을 약 24.4% 절감할 수 있다는 것입니다:

ASTC에 대한 자세한 내용은 적응형 확장형 텍스처 압축에서 확인할 수 있습니다.

12.4.15 big.LITTLE Core

모바일 CPU(퀄컴 키요 CPU의 경우처럼 GPU가 아닌)에는 Arm에서 처음 제안한 big.LITTLE 결합 아키텍처가 있습니다.이 아키텍처에는 빅 코어와 리틀 코어가 모두 있으며, 빅 코어는 고성능에 최적화되고 리틀 코어는 전력 소비에 최적화되어 있습니다.

퀄컴 키요 CPU의 big.LITTLE 아키텍처.왼쪽의 4개는 실행 성능은 높지만 전력 소비가 많은 빅 코어이고, 오른쪽의 4개는 실행 성능은 낮지만 전력 효율이 더 높은 리틀 코어입니다.
big.LITTLE 아키텍처의 특징은 다음과 같습니다:

• 서로 다른 두 개의 프로세서를 단일 SoC에 결합하여 성능 측면에서 변화하는 스마트 기기의 요구 사항에 대응할 수 있습니다.
• 크고 작은 소프트웨어는 적절한 CPU 코어에 작업을 할당하는 작업을 자동으로 처리합니다.운영 체제는 시스템의 고성능 및 고효율 코어를 직접 감지하고 성능 요구 사항에 따라 각 작업을 적절한 코어에 동적으로 할당할 수 있습니다.

이 아키텍처의 특성을 이해하고 활용하는 방법은 성능과 전력 효율을 최적화하는 데 매우 중요하며, 이를 잘 최적화하면 게임 플레이 시간이 길어지고 열을 더 많이 방출할 수 있습니다.
큰 코어의 효율성을 높이려면 작은 코어의 우선 순위를 정하십시오. 프레임 기대 시간이 16ms(60FPS)라고 가정하면 개발자는 Snapdragon 프로파일러와 같은 도구를 사용하여 작은 코어로 이동할 작업을 식별할 수 있습니다. 예를 들어 큰 코어에서 실행하는 데 3밀리초가 걸리는 직물 시뮬레이션이 있는 게임에서 실행하는 데 3밀리초가 걸리는 반면, 리틀 코어에서 실행하는 데 10밀리초가 걸릴 수 있습니다.이 실행 시간이 허용 가능한 수준(이 경우 프레임 예산은 16밀리초)이라면 리틀 코어로 이동하여 빅 코어의 사용률을 낮추고 전력 효율을 높여야 합니다.
모바일 SoC 제조업체(예: Qualcomm, Arm)는 일반적으로 개발자가 작업을 실행할 CPU 코어 유형을 지정할 수 있도록 관련 SDK 및 API를 제공합니다( 작업 실행 제어 참조).

12.4.16 기타 기술적 사항

위의 하위 섹션에서 다룬 기술적 사항 외에도 실제로 모바일 칩이나 그래픽 API에는 SIMD, SIMT, 통합 셰이더 아키텍처(아래 참조), 스칼라 아키텍처, 트리파이프(아래 참조) 등 다양한 기술이 있습니다.등이 있습니다.더 자세한 기술적인 내용은 저자가 작성한 GPU에 관한 다른 글인 심층적인 GPU 하드웨어 아키텍처 및 작동 메커니즘을 참조하세요.

왼쪽: 별도의 셰이더 처리 장치, 오른쪽: 통합 셰이더 처리 장치.후자의 프로세서가 기본적으로 최대 용량으로 실행되므로 대기 및 유휴 부하가 줄어들고 전반적인 컴퓨팅 성능이 향상되는 것을 볼 수 있습니다.

3개의 연산 유닛, 1개의 액세스 유닛, 1개의 텍스처 유닛, 128비트 대역폭, 2x FP64, 4x FP32, 8x FP16의 연산 효율을 가진 말리 GPU의 트리파이프 구조 개략도.
또한 OpenGL ES에는 텍스처 하위 영역 읽기 및 쓰기 작업과 같은 성능 향상을 위한 여러 확장 기능이 있습니다:

KHR_partial_update
EXT_buffer_age

이 확장 기능을 사용하면 호출자가 백버퍼의 시간을 사용하여 여러 상자를 지정하여 프레임의 내용을 그릴 수 있습니다.이 기술은 TE와 유사하지만 타일 버퍼에 데이터를 쓰지 않습니다.
 

12.5 모바일 GPU 아키텍처 및 메커니즘

이 장에서는 모바일 GPU의 하드웨어 아키텍처와 작동 메커니즘에 대해 설명합니다.

12.5.1 모바일 GPU 개요

모바일 GPU는 휴대성 때문에 세 가지 PPA 지표를 고려해야 하므로 고성능 GPU를 설계하는 것은 매우 어렵고 매우 까다롭습니다.현재 주로 퀄컴, Arm, 이매지네이션 테크 등 GPU 제조업체가 있으며, 이들의 대표적인 작품으로는 아드레노, 말리, 파워VR 등이 있습니다. 모바일 GPU는 일반적으로 SoC에 통합되어 CPU, 메모리 및 기타 장치와 유기적인 하드웨어 아키텍처 시스템을 형성합니다.

스냅드래곤 프레임워크 다이어그램.CPU, Adreno GPU, 메모리 등의 구성 요소와 버스, 네트워크 등을 통한 데이터 상호 작용을 포함합니다.
시간이 지남에 따라 모바일 하드웨어도 함께 발전해 왔으며, 특히 점점 더 많은 새로운 그래픽 API와 렌더링 기능이 모바일로 마이그레이션되고 있습니다:

• 메인스트림 GPU는 DX12, 벌칸 1.2, OpenGL ES 3.2와 같은 그래픽 API와 VRS, 메시 셰이딩, 레이 트레이싱, WaveMath와 같은 새로운 렌더링 기능을 지원합니다.
• ALU, 텍스처, 메모리 등을 포함한 GPU 처리량과 연산 능력이 크게 향상되었습니다:

• 오른쪽에 Xbox One 성능 수치가 표시된 퀄컴 아드레노 640 GPU의 성능을 살펴보세요.
• 메모리 대역폭이 증가하고 에너지 비율이 향상됩니다.

• 절전 기능이 확산되고 있습니다.
  • Render Target Compression, FP16 math ops, ASTC, Vulkan Subpasses。
  • UBWC、AFBC、IDVS、PLS等。
• 모바일 SOC는 VR 애플리케이션에 널리 사용되며 다양한 전용 최적화 기술을 제공합니다.
• 컴퓨트 셰이더 기능이 세분화되고 개선되었으며 OpenCL 라이브러리에 대한 지원이 세분화되었습니다.
• 평행선 수 증가 및 처리량 증가.

• CPU 및 GPU 작동 회로도를 보면 GPU의 캐시는 작지만 스레드 수가 많다는 것을 알 수 있습니다.

모바일 GPU 아키텍처의 관련 개념과 용어는 아래에 설명되어 있습니다:

개념	전체 이름	설명
AMBA	Advanced Microcontroller Bus Architecture	고급 마이크로컨트롤러 버스 아키텍처
AXI	AMBA Advanced eXtensible Interface	AMBA 고급 확장형 인터페이스
APB	AMBA Advanced Peripherial Bus	AMBA 고급 주변 장치 버스
ACE	AMBA AXI Coherency Extensions	AMBA AXI 적합성 확장
GPU	Graphics Processing Unit	그래픽 처리 장치
VPU	Video Processing Unit	비디오 처리 장치
DPU	Display Processing Unit	디스플레이 처리 장치
ISA	Instruction Set Architecture	명령어 집합 아키텍처(ISA)
SIMD	Single Instruction Multiple Data	단일 명령어, 많은 데이터
ISP	Image Synthesis Processor	합성 이미지 프로세서
TSP	Texture and Shading Processor	텍스처 및 셰이딩 프로세서

12.5.2 모바일 GPU 작동 메커니즘

각 GPU 제조업체, 각 시리즈 및 각 세대별 제품의 작동 메커니즘이 다를 수 있으므로 이 섹션에서는 모바일 GPU의 작동 메커니즘을 설명하기 위해 Mali GPU를 예로 들어 설명합니다.먼저 Arm Mali T880 GPU 하드웨어 아키텍처의 파라미터를 다음과 같이 설명합니다:

• 16个Shader Core（SC).
• 타일 크기는 16x16(내부 4x4~32x32)입니다.

• 깊이 템플릿 버퍼, 128비트 픽셀 데이터를 저장할 수 있습니다.
• 각 픽셀에는 16바이트의 원시 비트 액세스가 있습니다.
• GLES 3.2, Vulkan 1.0, CL 1.2, DX 11.2를 지원합니다.
• 4배, 8배, 16배 MSAA.

Arm Mali T880 GPU 하드웨어 아키텍처의 개략도 및 기능 설명.
Mali GPU의 경우 드라이버는 작업 관리자를 통해 드로잉 작업을 제출하고, 작업 관리자는 작업을 생성하여 GPU의 드로잉 하드웨어에 제출하며, 내부적으로 연결된 구성 요소를 통해 상호 작용합니다.

애플리케이션, 드라이버, GPU, DPU 등 다양한 계층 간의 상호 작용을 단순화한 도식은 아래와 같습니다:

앱, 드라이버, GPU 등의 상호 작용에 대한 개략도.여기서 eglSwapBuffers는 프레임의 끝을 나타내며, 앱은 그리기 명령을 드라이버에 할당하고, 드라이버는 작업을 GPU에 예약하며, GPU는 그리기가 완료된 후 결과를 DPU에 제출합니다. 다양한 레이어 간에 지연이 있다는 점에 유의하세요.
먼저 애플리케이션과 드라이버 레이어 간의 상호 작용을 살펴봅니다.애플리케이션이 그래픽 API(예: OpenGL ES)를 호출하면 드라이버는 해당 리소스 아키텍처 다이어그램을 생성합니다:

GPU 내에는 다음과 같은 작업 유형이 존재합니다:

작업 이름	요약어	설명
Vertex Job	V	버텍스 세트에 대한 버텍스 셰이더를 실행합니다.
Tiler Job	T	타일링 유닛(청킹 유닛, 고정 기능)은 변환된 튜플을 커버된 청크로 분할합니다.
Fragment Job	F	모든 타일에 대해 단일 렌더링 타깃에서 작업을 실행합니다.
Job Chain	-	운영 체인.

다음은 GPU 잡 체인에 대한 시나리오 중 하나입니다:

작업 체인의 개략도.작업 간에는 종속성이 있으며(화살표로 표시), 이전 작업이 완료되어야만 다음 작업을 실행할 수 있습니다.
CPU와 GPU 간의 상호 작용은 다음과 같으며, CPU는 APB를 통해 GPU에 작업을 제출하고, GPU 내의 잡 매니저는 AXI를 통해 공유 메모리에 액세스하며, CPU도 AXI를 통해 공유 메모리에 액세스할 수 있습니다.

GPU 내의 작업 관리자는 다음과 같이 도식적으로 작업을 생성하고 할당합니다:

작업 관리자 작업의 개략도.이 다이어그램은 3개의 버텍스 작업, 1개의 청킹 작업 및 2개의 채색 작업을 할당합니다.여기서 청킹 잡은 버텍스 잡에 종속됩니다.
셰이더 코어의 경우 말리는 VS 또는 PS를 실행할 수 있는 통합 셰이더 아키텍처인 트리파이프로 구조화되어 있습니다:

또한 버텍스 잡은 다음과 같이 개략적으로 실행됩니다.버텍스 스레드는 타일 버퍼에 쓰지 않고 메인 메모리에 직접 액세스하며, 버텍스 잡에는 4n개의 버텍스가 포함됩니다.

슬라이스 요소 작동의 개략도는 아래와 같습니다:

조각 작업은 프론트 엔드, 트라이파이프, 백엔드의 세 단계로 나뉩니다.래스터화, Early-Z, FPK를 성공적으로 거친 픽셀은 프래그먼트 스레드 생성기(쿼드, 즉 2x2 스레드)에 의해 스레딩되고, 트리파이프 셰이딩에 들어간 다음, Late-Z, 블렌딩, 마지막으로 타일 메모리에 기록됩니다.
하지만 모든 모바일 GPU가 말리와 똑같이 실행되는 것은 아니며, 예를 들어 PowerVR은 많은 차이점이 있습니다:

PowerVR 시리즈 7XT 아키텍처의 개략도.

PowerVR 시리즈 7XT 통합 셰이더 클러스터 그룹 아키텍처 다이어그램.
PowerVR에 대한 자세한 내용은 여기에서 확인할 수 있습니다:

• PowerVR Series5 Architecture Guide for Developers
• PowerVR Graphics - Latest Developments and Future Plans

12.5.3 병렬 처리, 지연 및 대기 시간

무어의 법칙이 느려지고 최신 모바일 SoC가 멀티코어와 높은 병렬성으로 이동함에 따라 애플리케이션의 멀티코어 성능을 활용하여 병렬 효율성을 개선하는 능력이 애플리케이션의 품질과 사용자 경험을 크게 결정합니다.
병렬 효율성과는 반대로 지연과 지연 시간은 게임과 같은 실시간 애플리케이션의 천적입니다.끊김 현상은 프레임 속도가 낮고 애플리케이션이 원활하게 실행되지 않는다는 것을 의미하며, 지연 시간은 작업이 제때 응답하지 못해 제품의 사용자 경험이 저하되고 심각한 사용자 손실로 이어질 수 있음을 의미합니다.
PC 단말이든 모바일이든 렌더링 파이프라인은 멀티 스레드의 특성과 함께 점점 더 복잡한 장면을 처리해야 하므로 대기, 지연(스톨) 및 기타 현상이 어느 정도 발생하여 지연(레이턴시)이 발생하게 됩니다.이러한 현상은 특히 TB(D)R이 널리 퍼져 있는 모바일 렌더링 파이프라인에서 두드러집니다.
지연과 지연 시간의 원인은 객관적이기도 하고 주관적이기도 합니다.객관적인 원인은 멀티 스레드 협업 대기, 동기화, 드라이버 최적화, GPU 내부 실행 메커니즘의 양성 최적화 등을 말합니다.주관적인 측면은 특정 렌더링 메커니즘에 부합하는 인터페이스, 플래그, 상태 또는 리소스를 사용하지 않는 경우로, 이를 피하고 최적화할 수 있습니다.

UE에는 게임 스레드, 렌더링 스레드, RHI 스레드가 있으며, 일반적으로 나중에 발생하는 스레드가 앞의 스레드보다 조금 더 지연되며, 스레드 간 동기화 및 대기를 통해 앞의 스레드가 너무 앞서가는 것을 방지합니다.

애플리케이션, 드라이버, GPU, 디스플레이 간의 지연 시간을 나타내는 도식으로, 하위 계층이 상위 계층보다 일정 시간 지연되는 것을 확인할 수 있습니다.

OpenGL의 glFinish 및 glFlush 실행 다이어그램.glFlush는 드라이버의 렌더링 명령 버퍼가 가득 찬 경우에만 호출 직후 렌더링 명령을 GPU로 플러시하지 않으므로 지연이 발생할 수도 있습니다.
모바일 GPU의 경우 병렬 효율성을 높이기 위해 비닝 패스와 렌더링 패스를 서로 다른 프레임에서 처리하는 것이 일반적인 TB(D)R 방식이지만, 지연 시간이 발생할 수도 있습니다:

TBR 아키텍처에서 비닝( Binning ), 렌더링 오류 프레임 처리의 개략도.
위는 완벽한 오류 프레임 처리의 경우이며, 다음 시나리오 중 하나가 존재하는 경우 TBR의 실행 리듬을 방해하여 더 심각한 스톨 및 지연을 초래합니다:

• 비닝(Binning)은 이전 프레임의 데이터 또는 리소스에 의존합니다.

n+1 프레임의 비닝은 n 프레임의 렌더링 렌더링 결과에 의존해야 하므로 n 프레임의 렌더링 패스와 병렬로 처리할 수 없으며 다음 프레임으로만 지연될 수 있습니다.
이 상황은 렌더링 결과의 N-1 프레임을 사용하는 N 프레임 비닝(Binning)과 같이 지연된 사용으로 해결할 수 있습니다.다음 그림은 실시간 환경 스테레오그램에 대한 최적화 예시를 보여줍니다:

• 데이터를 제출한 후 사용하기 위해 렌더링하기 전에 데이터를 수정합니다.예시:
  • 픽셀 셰이더는 데이터를 계산하여 프레임 버퍼 오브젝트에 쓰고, 그 결과를 사용하여 변위를 생성합니다.
  • CPU에서 텍스처를 쓰고 이를 사용하여 렌더링한 다음 다시 텍스처를 업데이트하고 다음 프레임을 렌더링하며, 텍스처 업데이트가 완료될 때까지 픽셀 셰이더가 실행되지 않습니다.

서브패스 메커니즘은 벌칸과 같은 최신 그래픽 API에 존재하며, 서브패스를 병렬로 처리(오버랩)하거나 데이터 종속성을 지정할 수 있습니다:

위: 하위 패스 i의 중첩 메커니즘, 아래: 하위 패스 내 및 하위 패스 간의 데이터 종속성.
Vulkan, Metal, DX12 등과 같은 최신 그래픽 API를 사용하면 렌더링 파이프라인 장벽(배리어)의 대기 단계를 정확하게 지정할 수 있습니다. 예를 들어 아래 이미지에서는 기본 PipelineBarrier를 사용하므로 버텍스 및 프래그먼트 처리 대기 또는 유휴 상태가 많아서 GPU 시간 주기를 낭비합니다:

왜 파이프라인 베리어가 필요 한가요?
일련의 vkCmdxxx() 호출은 "flat-out"을 실행하기 위한 것으로, 즉 벌칸 런타임이 실행할 수 있는 속도만큼 빠릅니다. 그러나 한 명령의 출력이 후속 명령에 대한 입력으로 필요할 수 있기 때문에 바람직하지 않을 때가 많음.
파이프라인 장벽은 이후 vkCmdyy() 호출에서 하드웨어 파이프라인의 어느 단계가 이전 vkCmdxx() 호출에서 어느 단계가 완료될 때까지 기다려야 하는지 선언함으로써 이 문제를 해결합니다.

배리어가 대기해야 하는 소스 및 타깃 페이즈를 수정하면 이러한 유형의 스톨을 완화하고 셰이더 유닛의 활용도를 향상시킬 수 있습니다:

파이프라인 장벽 최적화의 구체적인 예는 아래와 같습니다:

벌칸의 파이프라인 배리어를 사용하여 개별 패스 사이의 대기 단계를 최적화하면 스톨과 지연 시간이 감소합니다.그래프가 28ms에서 22ms로 감소합니다.
PowerVR의 TBDR 아키텍처는 이 프레임의 모든 튜플이 비닝 데이터를 처리한 후에야 렌더링 단계를 시작하므로 지연 시간이 더욱 악화될 수 있으며, 알파 테스트가 켜져 있으면 깊이가 HSR 단계로 다시 기록되어 HSR의 정상적인 흐름이 중단되고 예기치 않은 스톨이 발생할 수 있습니다.
최신 GPU(모바일 포함)는 일반적으로 모든 셰이더 코어가 VS와 PS를 모두 수행할 수 있는 통합 셰이더 아키텍처이며, 향후에는 GS, MS 등도 통합할 수 있습니다. 이를 통해 GPU는 VS 또는 PS 집약적인 작업을 조정하고 균형을 유지하여 모든 코어가 가능한 한 최대 성능을 발휘하도록 하여 대기, 유휴 및 지연 시간을 줄일 수 있습니다:

왼쪽: 별도의 셰이더 처리 장치, 오른쪽: 통합 셰이더 처리 장치.후자의 프로세서는 기본적으로 최대 용량으로 실행되므로 대기 및 유휴 상태가 줄어들고 전반적인 컴퓨팅 성능이 향상되는 것을 볼 수 있습니다.
최신 GPU는 전반적인 병렬 효율성과 처리량을 개선하기 위해 SIMD 및 SIMT 기술을 잘 활용하고 있습니다:

그러나 GPU 명령어 그룹 간에 데이터 종속성이 있는 경우 명령어 그룹 간의 실행 시간이 길어집니다:

왼쪽: GPU 명령어 그룹이 대기 없이 정상적으로 실행됨; 오른쪽: GPU 명령어 그룹이 버블에 추가되어 지연이 발생함.
버블은 GPU 명령어 그룹 간의 데이터 종속성을 해결하기 위해 생성됩니다:

왼쪽: 하위 명령어 집합은 상위 데이터 집합의 쓰기에 따라 달라지며, 처리되지 않은 상태로 두면 이전 데이터를 가져옵니다. 오른쪽: 하위 명령어 집합에 버블이 삽입되고 최신 데이터를 가져오기 위해 한 클록 주기만큼 지연됩니다.
셰이더의 if 및 for와 같은 동적 분기 루프 문은 GPU 컴퓨팅 유닛 사용률을 줄이고 명령어를 실행하는 데 걸리는 시간을 늘립니다:

또한 메모리에 액세스하는 명령은 GPU 연산 장치에 스톨을 발생시켜 연산 시간이 길어집니다:

지연 시간이 짧고 처리량이 적은 CPU와 달리 GPU는 본질적으로 높은 병렬 처리와 높은 처리량을 위해 설계되었지만 동시에 캐시 크기가 작고 캐시 적중률이 낮으며 지연 시간이 높습니다:

결과적으로 잘못 설계된 GPU 데이터 구조는 캐시 적중률을 크게 감소시켜 컴퓨팅 유닛의 지연과 대기 시간을 증가시킬 수 있으며, GPU의 스레드 스케줄은 일반적으로 동일한 캐시 라인에 동일한 스레드 그룹의 스레드를 유지함으로써 데이터 연관성을 고려합니다:

크기 16의 Wave 실행 도식.점선은 스레드 그룹 내에서 액세스되는 데이터의 캐시 적중률을 높이기 위해 스레드 그룹 간 경계를 넘어 데이터에 액세스할 수 없음을 나타냅니다.
위와 더불어 시스템 또는 애플리케이션이 이중 버퍼링, 삼중 버퍼링, 수직 동기화 등과 같은 메커니즘을 사용하는 경우 일정량의 지연 시간도 발생합니다.

트리플 버퍼링 실행 메커니즘의 개략도.
안드로이드 시스템 렌더링 모듈은 멀티 레이어 캡슐화와 트리플 버퍼링 메커니즘을 사용하여 화면이 항상 3프레임씩 지연되도록 합니다:

반대로 비동기 컴퓨트, 복사 엔진, 그래픽 파이프라인 및 시스템의 다른 부분에서 병렬 메커니즘을 잘 활용하고, RDG의 리소스 할당 및 종속성 자동 처리 기능을 활용하고, 서브 리소스 및 에일리어스 리소스, 병합 배리어 및 기타 작업의 특성을 활용하면 다음과 같이 줄일 수 있습니다.패스 간 및 패스 내 대기 및 지연을 줄이고 병렬 효율성을 개선할 수 있습니다.

비동기 컴퓨팅, 복사 엔진, 그래픽 파이프라인을 위한 병렬 실행 사례.

리소스 A와 D가 각각 다른 시간에 동일한 메모리 영역을 점유하는 별칭 리소스 운영 메커니즘의 모식도.RDG를 사용할 때 별칭 리소스는 렌더링 시스템에 리소스 관리 복잡성을 추가하지만 사용되는 리소스 할당 공간의 50% 이상을 절약할 수 있습니다.
즉, 로직 업데이트, 렌더링 명령어 생성, CPU 앱 레이어에서의 그래픽 API 호출 및 제출, 드라이버 레이어, 시스템 레이어, GPU 내부, 최종 디스플레이 렌더링에 이르기까지 다양한 종속성, 대기, 지연 및 지연 시간 문제가 발생할 수 있습니다.따라서 모바일 SoC에서 애플리케이션을 효율적이고 원활하며 즉각적으로 실행하기 위해서는 전체 렌더링 파이프라인의 병목 현상을 파악하고 올바른 해결 방법을 처방해야 합니다.
UE4 공식 문서에서 지연 시간에 대한 몇 가지 제안과 최적화 방법을 확인할 수 있습니다( 저 지연 프레임 동기화 문서를 참고하세요).
 

참고문헌

• Unreal Engine Source
• Rendering and Graphics
• Materials
• Graphics Programming
• Mobile Rendering
• Qualcomm® Adreno™ GPU
• PowerVR Developer Documentation
• Arm Mali GPU Best Practices Developer Guide
• Arm Mali GPU Graphics and Gaming Development
• Moving Mobile Graphics
• GDC Vault
• Siggraph Conference Content
• GameDev Best Practices
• Accelerating Mobile XR
• Frequently Asked Questions
• Google Developer Contributes Universal Bandwidth Compression To Freedreno Driver
• Using pipeline barriers efficiently
• Optimized pixel-projected reflections for planar reflectors
• UE4画面表现移动端较PC端差异及最小化差异的分享
• Deferred Shading in Unity URP
• 移动游戏性能优化通用技法
• 深入GPU硬件架构及运行机制
• Adaptive Performance in Call of Duty Mobile
• Jet Set Vulkan : Reflecting on the move to Vulkan
• Vulkan Best Practices - Memory limits with Vulkan on Mali GPUs
• A Year in a Fortnite
• The Challenges of Porting Traha to Vulkan
• L2M - Binding and Format Optimization
• Adreno Best Practices
• 移动设备GPU架构知识汇总
• Mali GPU Architectures
• Cyclic Redundancy Check
• Arm Guide for Unreal Engine
• Arm Virtual Reality
• Best Practices for VR on Unreal Engine
• Optimizing Assets for Mobile VR
• Arm® Guide for Unreal Engine 4 Optimizing Mobile Gaming Graphics
• Adaptive Scalable Texture Compression
• Tile-Based Rendering
• Understanding Render Passes
• Lighting for Mobile Platforms
• Frame Pacing for Mobile Devices
• ARM Mali GPU. Midgard Architecture
• ARM’s Mali Midgard Architecture Explored
• [Unite Seoul 2019] Mali GPU Architecture and Mobile Studio
• Killing Pixels - A New Optimization for Shading on ARM Mali GPUs
• Qualcomm's Quad-Core Snapdragon S4 (APQ8064/Adreno 320) Performance Preview
• Low Resolution Z Buffer support on Turnip
• Render Graph与现代图形API
• Hidden Surface Removal Efficiency
• Unreal Engine 4: Mobile Graphics on ARM CPU and GPU Architecture
• Low Latency Frame Syncing
• Qualcomm® Snapdragon™ Mobile Platform OpenCL General Programming and Optimization
• Qualcomm Announces Snapdragon 865 and 765(G): 5G For All in 2020, All The Details
• Introduction to PowerVR for Developers
• PowerVR Series5 Architecture Guide for Developers
• PowerVR Graphics - Latest Developments and Future Plans
• PowerVR virtualization: a critical feature for automotive GPUs
• PowerVR Performance Recommendations
• PowerVR Low Level GLSL Optimisation
• Mobile GPU approaches to power efficiency
• Processing Architecture for Power Efficiency and Performance
• opengl: glFlush() vs. glFinish()
• Cramming Software onto Mobile GPUs
• Vulkan on Mobile Done Right
• Triple Buffering
• Asynchronous Shaders
• Why Talking About Render Graphs
• NVIDIA Variable Rate Shading
• Introduction to compute shaders
• Introduction to GPU Architecture
• An Introduction to Modern GPU Architecture
• Understanding GPU caches
• Transitioning from OpenGL to Vulkan
• Next Generation OpenGL Becomes Vulkan: Additional Details Released
• Bringing Fortnite to Mobile with Vulkan and OpenGL ES
• Appropriate use of render pass attachments
• Preparing Android for XR

---

원문
https://www.cnblogs.com/timlly/p/15546797.html

剖析虚幻渲染体系（12）- 移动端专题Part 2（GPU架构和机制） - 0向往0 - 博客园