M3 및 A17 Pro를 위한 새로운 Metal 도구 살펴보기

안녕하세요, 저는 Ruiwei이고 Metal 개발자 도구 담당 소프트웨어 엔지니어입니다 오늘은 제 동료 Irfan과 함께 최신 Metal 프로파일링 도구를 보여 드리겠습니다

M3 및 A17 Pro의 Apple Family 9 GPU는 완전히 새로운 셰이더 코어 아키텍처를 특징으로 합니다

Apple은 이를 기회로 프로파일링 도구를 재구상하고 최신 워크플로를 구축했습니다

이 새 아키텍처를 자세히 알아보려면 ‘M3 및 A17 Pro의 GPU 개선 사항 알아보기’를 시청하세요

이 세션에서는 Xcode 15의 새 도구를 소개하며 시작하겠습니다

다음으로, 탁월한 성능 달성을 위해 점유율 관리가 매우 중요한 만큼 Irfan이 새 성능 카운터 세트를 사용하여 점유율을 프로파일링하는 방법을 보여드릴 것입니다

마지막으로 이 새로운 아키텍처에서 레이 트레이싱을 프로파일링하는 방법을 알아봅니다

새로운 프로파일링 도구부터 시작해 보겠습니다

저는 지금 최신 GPU 기반 파이프라인으로 거리를 렌더링하고 있습니다

렌더링된 이미지는 근사해 보이지만 성능 문제가 좀 있습니다

이러한 앱 성능 병목 현상을 해결하기 위한 두 가지 주요 접근 방식이 있습니다

첫 번째는 가장 비효율적인 셰이더를 식별하고 거기에서 비효율을 유발하는 함수와 코드 라인을 파악하는 것입니다

또 다른 접근 방식은 비효율적인 객체나 픽셀을 찾는 것부터 시작하는 것입니다 셰이더의 경우 프래그먼트 위치나 스레드 ID에 따라 동작이 달라질 수 있습니다

M3 및 A17 Pro의 새로운 프로파일링 아키텍처는 Xcode 15에 이러한 작업을 단순화하는 여러 새로운 도구를 제공합니다 이 세션에서는 이러한 새 도구를 사용하여 워크로드의 성능 문제를 진단하는 방법을 알아봅니다

먼저 셰이더 코스트 그래프를 소개하겠습니다 이는 메모리를 소모하는 셰이더를 찾고 분류하는 데 유용한 새로운 도구입니다

이것은 방금 Xcode 15에서 프로파일링한 워크로드의 GPU 캡처입니다 성능 뷰로 이동하면 GPU 타임라인에 워크로드의 실행 및 성능 카운터가 표시됩니다

셰이더 코스트 그래프를 보려면 새로운 ‘Shader’ 탭으로 탭으로 이동합니다

왼쪽의 성능 탐색기에는 패스와 파이프라인의 상태 목록이 코스트별로 정렬되어 표시됩니다

GBuffer Pass가 총 코스트의 약 50%로 보이는데, 이는 제 예상보다 높습니다

먼저 GBuffer Pass에 사용되는, 코스트가 높은 파이프라인의 상태를 조사해 보겠습니다

탐색기에서 파이프라인 상태를 선택하면 셰이더 비용 그래프가 표시됩니다

무작위 파이프라인의 경우 프래그먼트 셰이더가 기본적으로 선택됩니다

셰이더 코스트 그래프는 2가지 주요 부분으로 나뉩니다 맨 위에는 코스트가 가장 높은 셰이더 함수를 시각화한 Flame 그래프가 있습니다

그래프 아래에는 셰이더의 소스 코드가 있습니다

Metal 셰이더에 Flame 그래프를 도입한 건 이번이 처음입니다 Flame 그래프를 보면 프래그먼트 셰이더에서 코스트가 가장 높은 함수를 쉽게 찾을 수 있습니다 그래프에서 함수를 선택하면 소스 편집기의 해당 위치로 바로 이동합니다

소스 코드에는 왼쪽 사이드바에 성능 주석이 있어 라인별 코스트를 보여 줍니다

이것은 이미지의 모든 픽셀에 조명을 적용하는 전체 화면 셰이더입니다

왼쪽 사이드바의 성능 주석에서 코스트가 가장 높은 셰이더 소스 라인을 빠르게 찾을 수 있습니다

원형 차트 위로 마우스를 가져가면 성능 팝오버가 표시됩니다

팝오버는 GPU에서 실행된 명령어 수 다양한 명령어 카테고리의 코스트 등, 라인의

세부 정보를 제공합니다

전체 화면 셰이더이므로 프래그먼트 위치에 따라 동작이 다를 수 있으며 특정 영역이나 픽셀별로 성능 병목 현상이 발생할 수 있습니다 문제를 완전히 파악하려면 코스트가 더 높은 픽셀을 찾아야 하며 이것은 새 도구인 성능 히트 맵을 활용할 기회입니다

성능 히트 맵은 픽셀 또는 컴퓨팅 스레드 정보와 성능 지표를 시각화하는 도구입니다 이 도구는 프래그먼트 위치나 GPU 스레드의 컴퓨트 스레드 ID로 빌드합니다

GBuffer Pass에서 다양한 유형의 성능 히트 맵을 살펴보겠습니다

첫 번째는 셰이더 실행 코스트 히트 맵입니다 코스트는 실행 시간과 GPU 스레드의 지연 숨김으로 계산됩니다

이 이미지의 우반부에 있는 픽셀은 빨간색으로 표시되어 코스트가 더 높다는 것을 쉽게 알 수 있습니다

다음은 스레드 분기 히트 맵입니다 이것은 SIMD 그룹에 있는 GPU 스레드 분기의 양을 시각화합니다

발산은 스레드 사이의 제어 흐름 차이에 따라 증가하는데, 이는 조건 분기 또는 지오메트리의 모양 때문에 비활성화된 스레드에서 발생합니다

오버드로우 히트 맵은 2개 이상의 GPU 스레드로 렌더링된 픽셀을 시각화합니다

이는 1개 이상의 렌더링 명령에서 블렌딩이 활성화됐을 때 지오메트리가 겹쳐서 발생할 수 있습니다 Apple GPU에서 최적의 성능을 얻으려면 불투명 객체가 먼저 렌더링된 다음 투명 객체가 렌더링 될 수 있도록 GPU 명령을 그룹화해야 합니다

명령어 수 히트 맵은 각 픽셀 또는 SIMD 그룹에 대해 GPU에서 실행된 명령어의 수를 보여 줍니다

마지막으로 드로우 ID 히트 맵은 다양한 GPU 명령을 색상으로 구분합니다 이 예에서는 워크로드의 대부분이 단일 명령으로 렌더링된 것을 볼 수 있습니다 오직 투명한 창문 부분만 구분됩니다

히트 맵의 역할과 모습을 보셨으니, 이제 히트 맵을 Xcode 15에서 찾는 방법을 알아보겠습니다

성능 히트 맵에 액세스하려면 상단 막대의 Heat Map 탭을 클릭합니다

기본적으로 셰이더 실행 비용 히트 맵과 첫 번째 첨부가 표시됩니다

장면의 거리 부분은 실행 코스트가 훨씬 더 높은 것이 보입니다 더 자세히 보기 위해 히트 맵을 추가하겠습니다

하단 막대의 더하기 버튼을 클릭하면 히트 맵 팝오버가 표시됩니다

여기에서 다양한 유형의 히트 맵을 손쉽게 활성화 또는 비활성화할 수 있습니다

명령어 수 히트 맵을 보니 GPU가 거리의 픽셀에서 더 많은 명령어를 실행하고 있어 높은 코스트가 설명되네요

포인터를 픽셀 위로 이동하여 코스트의 백분위수 명령어 수와 같은 세부 정보를 볼 수 있습니다

저는 히트 맵을 보면서 이미 이 픽셀들의 코스트가 높은 이유를 파악하고 있습니다

또한 새 도구인 셰이더 실행 기록을 사용하면 셰이더가 해당 픽셀을 어떻게 렌더링하는지 정확하게 확인할 수 있습니다

성능 히트 맵에서 픽셀을 클릭하면 기본 SIMD 그룹이 선택됩니다

그러면 히트 맵 아래에 SIMD 그룹의 셰이더 실행 기록이 표시됩니다

셰이더 실행 기록에는 2가지 주요 부분이 있습니다 위쪽의 타임라인과 아래의 셰이더 소스 코드입니다

타임라인은 선택한 SIMD 그룹의 진행 상황을 왼쪽에서 오른쪽으로 보여 줍니다 위에서 아래로는 전체 셰이더 호출 스택이 각 실행 지점에 표시됩니다

Apple GPU에서 SIMD 그룹의 실행 상황을 정확하게 표시한 것은, 이 강력한 시각화 도구가 처음입니다

타임라인을 검사하면 많은 실행 시간을 차지하는 셰이더 함수를 즉시 찾을 수 있습니다 또한 Metal 디버거는 루프를 자동으로 감지하여 진행 상황을 파악하는 데 도움을 줍니다

예제의 셰이더 함수에는 12번 반복되는 루프가 있으며 전체 SIMD 그룹 실행 시간의 79%를 차지합니다

각 반복에서 applySpotLight가 호출되고 있습니다 이 함수 호출에는 텍스처를 샘플링하는 루프가 더 있습니다

이상하죠, 거리의 픽셀에 조명을 비추는 스포트라이트가 12개나 있으면 안 되거든요

워크로드를 확인하니 구성이 잘못되어 스포트라이트가 중복되고 있었습니다 불필요한 조명을 제거한 후 GBuffer Pass의 성능이 훨씬 좋아졌습니다

즉, 셰이더 실행 기록은 GPU에서 SIMD 그룹이 실행되는 상황을 시각화합니다

여기에는 스레드 상태 함수 호출 스택 루프가 포함됩니다

이는 셰이더 실행 상황에 대한 완전히 새로운 이해를 제공합니다

M3 및 A17 Pro에서 사용할 수 있는 Xcode 15의 새로운 프로파일링 도구였습니다 여러분의 프로젝트에 이 도구를 활용해 보세요

이제 제 동료 Irfan이 점유율 프로파일링에 대해 설명해 드리겠습니다

고마워요, Ruiwei M3 and A17 Pro의 GPU를 위한 새 도구와 워크플로우에 대해 잘 봤습니다 안녕하세요, Irfan입니다 저는 점유율 프로파일링이 새로운 GPU 아키텍처에서 작동하는 방식과 하드웨어 레이 트레이싱 워크로드 프로파일링에 도움이 되는 새로운 카운터를 소개하겠습니다

점유율을 프로파일링하는 방법을 보여드리기 전에 ‘M3 및 A17 Pro의 GPU 개선 사항 알아보기’를 시청해 보시기 바랍니다 그러면 제가 다룰 내용을 더 잘 이해하는 데 도움이 될 것입니다 먼저 이 섹션과 관련이 있는 주요 개념을 몇 개를 요약해 보겠습니다

Apple Family 9 GPU는 M3 및 A17 Pro를 포함합니다

두 칩의 GPU에는 다양한 구성 요소가 있습니다 각 셰이더 코어는 FP32, FP16등 다양한 유형의 명령어를 실행하는 여러 실행 파이프라인이 있으며 텍스처 및 버퍼 리소스에 읽기 및 쓰기를 실행합니다

또한 셰이더 프로그램이 사용하는 여러 유형의 데이터를 저장하는 온칩 메모리가 있습니다 레지스터는 변수 값을 저장하며 스레드 그룹 및 타일 메모리는 컴퓨트 스레드 그룹에서 공유하는 데이터 또는 타일에서 공유하는 색상 첨부 데이터를 저장합니다

이러한 온칩 메모리는 L1 캐시를 공유하며 GPU 손실 레벨 캐시 기기 메모리가 이를 백업합니다

이제 GPU 성능과 점유율에 어떤 관계가 있는지 알아보겠습니다

Metal 셰이더가 ALU 실행 파이프라인을 사용한 일부 수학 연산의 실행 후 버퍼를 읽고 그 결과가 즉시 사용된다고 가정하겠습니다

버퍼에 액세스하려면 기기 메모리까지 갔다 와야 할 수 있는데 이는 지연 시간이 긴 작업입니다 이 시간 동안 SIMD 그룹은 다른 작업을 실행할 수 없게 되고 ALU 파이프라인은 가동되지 않습니다

이를 완화하기 위해 셰이더 코어는 자체 ALU 명령어가 있는 다른 SIMD 그룹의 명령을 실행할 수 있습니다

이렇게 하면 ALU의 미사용 시간이 줄어들고 SIMD 그룹이 병렬로 실행되도록 하여 성능이 향상됩니다

추가 SIMD 그룹이 셰이더 코어에서 실행 중인 경우 ALU 및 기타 실행 파이프라인에 스타베이션(Starvation)이 없을 때까지 이 작업을 여러 번 반복할 수 있습니다

셰이더에서 동시에 실행 중인 SIMD 그룹의 수를 점유율이라고 합니다 최적의 성능을 얻으려면 셰이더 코어의 ALU 사용량이 최대한 늘어날 때까지 점유율을 늘려야 합니다

Apple Family 9 GPU에서 점유율 관리가 중요한 이유를 간략하게 설명하겠습니다

레지스터, 스레드 그룹 타일 스택 기타 셰이더 코어 메모리 유형은 L1 캐시에서 동적으로 할당되며 GPU 손실 레벨 캐시와 기기 메모리가 이를 백업합니다

각 SIMD 그룹은 대량의 다양한 온칩 셰이더 프로그램 메모리를 사용할 수 있습니다 SIMD 그룹 수가 증가하면 워크로드가 사용 가능한 온칩 스토리지보다 더 많은 메모리를 사용하는 시점이 올 수 있으며 그러면 다음 캐시 레벨로 메모리가 유출됩니다

셰이더 코어는 스레드 점유율과 캐시 활용률 사이 균형을 맞춰 메모리 캐시 스레싱을 방지합니다

이로 인해 셰이더 데이터가 온칩으로 유지되고 실행 파이프라인이 계속 가동되어 셰이더 성능이 향상됩니다

Xcode 15에는 워크로드 점유율이 낮은 원인을 쉽게 찾아 해결하고 뛰어난 성능을 달성하는 데 도움이 되는 새로운 성능 카운터 세트가 있습니다

다음으로, 점유율을 늘려 워크로드 성능 목표를 달성하는 데 도움이 되는 워크플로우를 보여 드리겠습니다

먼저 확인해야 할 것은 Metal 워크로드가 GPU에서 어떻게 실행되고있는지 실행 전반에 걸쳐 점유율이 어떻게 되는지입니다 Metal 디버거로 이 작업을 수행하는 방법을 보여 드리겠습니다 Timeline 탭을 선택하면 GPU 워크로드 실행이 표시됩니다

각 셰이더 단계에 대한 모든 워크로드 인코더의 기간이 표시됩니다 각 셰이더 단계 섹션에서 셰이더 파이프라인의 실행을 볼 수도 있습니다

인코더 섹션 아래에는 카운터 섹션이 있는데 여기서 최상위 성능 제한 요인과 사용률, 그리고 점유율 등 기타 유용한 성능 카운터를 볼 수 있습니다

이러한 카운터는 워크로드가 GPU에서 실행되는 동안 주기적으로 수집됩니다

저는 성능 활용률과 제한 요인을 자주 언급할 것이므로

그 의미를 간략하게 설명하겠습니다

작업은 ALU의 산술 명령어 MMU의 주소 변환 요청 등, 하드웨어 블록에서 처리되는 항목의 수입니다 중단은 사용 가능한 항목이 다운스트림 블록에 의해 보류되는 횟수입니다 예를 들면 캐시에 의해 메모리 명령어 요청이 중단되어 다음 레벨 캐시 또는 기기 메모리에서 요청이 돌아오기를 기다리는 경우 등입니다 하드웨어 블록의 활용률과 제한 요인을 계산하는 수학 방정식은 이러합니다 활용률은 샘플 기간에 하드웨어 블록이 수행한 작업을 의미하며 샘플 기간에 하드웨어 블록의 최대 처리 속도를 퍼센티지로 나타낸 것입니다 제한 요인도 비슷하게 계산되며 샘플 기간의 작업과 중단을 모두 포함됩니다

이제 낮은 점유율을 분류하는 방법을 보여 드리겠습니다

카운터 트랙을 보겠습니다

총 점유율이 낮아 보이는데요 점유율이 낮을 때의 다른 성능 제한 요인도 살펴보겠습니다

전체 점유율은 낮지만 ALU 하위 유닛인 FP16의 성능 제한

요인이 100%인 것을 볼 수 있습니다 FP16이 이 간격 동안 사용 중이었다는 뜻입니다 이 시나리오에서 점유율을 늘리려고 할 때 새로 추가된 SIMD 그룹이 FP16 작업을 의도했다면 성능이 향상되지 않을 것입니다

셰이더에서 FP16 명령어를 줄이면 전체 셰이더 성능이 향상될 것입니다

이 워크로드에서는 점유율과 모든 ALU 제한 요인이 모두 낮은 것을 볼 수 있습니다 이는 ALU 스타베이션을 방지할 만큼 점유율이 충분하지 않다는 것을 의미합니다 점유율이 ALU 유닛에 스타베이션을 일으켜 ALU 가동을 통한 최적화를 방해한다는 것을 설명하고

낮은 점유율의 원인을 구분하는 방법과 ALU 또는 메모리 대역폭으로 워크로드를 제한하여 점유율을 높이는 방법을 알려드리겠습니다

셰이더 실행 제한 요인 카운터에는 셰이더 코어에서 스레드를 실행하기 위해 수행된 작업과 배압으로 인해 스레드를 시작할 수 없을 때 발생하는 중단이 모두 포함됩니다 이 카운터 값이 낮으면 워크로드 크기가 작아 스레드가 충분히 실행되지 않는다는 의미입니다 높은 값은 반대의 의미입니다

먼저, 카운터 트랙에서 이 카운터 값을 검사하여 충분한 셰이더 스레드가 셰이더 코어로 실행되고 있는지 확인하겠습니다 컴퓨트 셰이더 실행 제한 요인은 0.07%에 불과합니다 앞서 언급했듯이 작은 카운터 값은 워크로드가 GPU를 채울 만큼 크지 않아 셰이더 코어에 스타베이션이 일어나고 있다는 뜻입니다

제가 프로파일링한 다른 워크로드를 보겠습니다

셰이더 실행 제한 요인이 높은 것을 볼 수 있습니다 이는 스레드가 충분히 실행되고 있거나 배압으로 인해 스레드 실행이 중단되고 있다는 뜻입니다 스레드에 필요한 메모리 리소스가 부족해서 그럴 수도 있습니다

조사를 계속 하려면 무엇이 필요한지 알아보겠습니다

셰이더 실행 제한 요인 카운터가 높은 경우 낮은 점유율에는 이유가 몇 개 있습니다 먼저 이 시간 동안 실행 중인 컴퓨트 디스패치 중에 대량의 스레드 그룹 메모리를 사용하는 게 있는지 확인하겠습니다 이게 맞다면 셰이더 코어가 스레드 그룹 메모리를 사용할 수 없기 때문에 새 스레드 실행을 중단하여 점유율이 낮아진 것입니다

여기에서는 단 하나의 컴퓨트 패스로 구성된 간단한 워크로드를 별도로 프로파일링했습니다 GPU 타임라인에서는 특정 시간에 실행 중이던 디스패치를 ​ 확인할 수 있습니다 GPU 타임라인에서 컴퓨트 인코더를 선택하면 인코더의 각 디스패치에 얼마나 많은 스레드 그룹 메모리가 설정되는지 볼 수 있습니다 디스패치의 스레드 그룹 메모리 사용량은 2KB에 불과하므로 스레드 그룹 메모리를 셰이더 실행 지연 원인에서 배제할 수 있습니다 점유율 매니저를 사용하여 스레드 활용률과 캐시 스레싱 균형을 맞추기 위해 셰이더 코어의 최대 점유율 목표를 설정할 수 있습니다

현재 워크로드의 경우 점유율 매니저 목표 카운터로 GPU가 점유율을 제한하고 있는지 확인해야 합니다

이는 레지스터 스레드 그룹 타일, 스택 메모리를 칩에 유지하기 위한 것입니다 타임라인 카운터 트랙에서 점유율 매니저 목표 카운터를 볼 수 있습니다 보시다시피 점유율 매니저 목표 카운터가 100%보다 낮습니다 GPU가 점유율 매니저를 통해 다양한 셰이더 데이터 메모리 유형을 온칩으로 유지하고 있다는 뜻입니다 그게 아니라면 GPU, 손실 레벨 캐시, 심지어는 기기 메모리로 유출되었을 것입니다

이것은 점유율 매니저 목표 카운터가 낮을 때 낮은 점유율을 분류하는 데 사용할 수 있는 순서도입니다 먼저 L1 축출률 카운터를 살펴보겠습니다 이것은 다음 레벨 캐시로 유출되지 않고 온칩으로 유지될 수 있는 레지스터, 스레드 그룹, 스택 메모리의 양을 알려줍니다 L1 축출률 카운터 트랙에서 카운터가 높게 표시되는 것이 보입니다 과도한 셰이더 액세스로 스레싱이 발생하고 있으며 축출되고 있다는 뜻입니다

이제 셰이더 코어 메모리 중 어떤 게 축출의 원인인지 알아낼 수 있는 방법을 보여 드리겠습니다

L1이 백업하는 온칩 셰이더 코어 메모리 중 어떤 것이 축출을 일으키는지 파악하려면, L1에 가장 자주 액세스하는 메모리 유형과 캐시 라인의 가장 큰 비율을 할당 받은 메모리를 알아야 합니다

GPU 타임라인에서 L1 로드 및 저장 대역폭 카운터 트랙을 검사하면 다양한 온칩 L1 백업 메모리의 L1 대역폭을 볼 수 있습니다 보시다시피 이미지 블록 L1의 L1 메모리 저장 대역폭이 가장 높습니다

마찬가지로 이미지 블록 L1의 L1 로드 대역폭이 가장 높으며 대부분의 L1 축출을 유발하고 있습니다

L1 레지던시 카운터 트랙은 다양한 온칩 메모리의 L1 캐시 할당을 분석해서 보여 주며 여기에서 어떤 셰이더 코어 메모리에 가장 큰 L1이 할당되었는지 볼 수 있습니다

보시듯이 이미지 블록 L1 메모리는 작업 세트 크기가 가장 크므로 높은 L1 축출률의 원인일 가능성이 높습니다

이 경우 최소 픽셀 형식을 사용하여 L1 축출률을 줄일 수 있습니다 MSAA를 사용 중이며 워크로드에 고도로 복잡한 지오메트리가 있는 경우 샘플 수를 줄이는 게 L1 축출률을 줄이는 데 도움이 됩니다

액세스 빈도와 L1 축출을 일으키는 온칩 메모리 할당 크기를 줄인 후에 원하는 효과가 나왔는지 확인이 필요합니다

메모리를 최적화하고 다시 프로파일링한 후 ALU 또는 메모리 대역폭이 워크로드를 제한하는지 확인합니다 먼저 다른 제한 요인부터 확인합니다 제한이 없다면 워크로드가 점유율을 제한하지 않는 것이며 낮은 점유율을 분류하지 않아도 됩니다 ALU 또는 메모리 대역폭이 워크로드를 제한하지 않는 경우 L1 축출률이 낮아질 때까지 점유율 값과 점유율 매니저 목표 카운터를 다시 확인하고 이 프로세스를 반복합니다

여기에서 L1 축출률은 낮습니다 따라서 이 경우 점유율 매니저 목표는 GPU 손실 수준 캐시 또는 MMU 중단과 관련된 것으로 보입니다 이는 기기가 메모리 액세스 스레시 손실 수준 캐시를 수행하거나 TLB 누락을 일으킬 때 발생할 수 있습니다 다른 워크로드에서 이러한 중단을 확인하는 법을 보여 드리겠습니다 GPU 손실 수준 캐시 활용률은 요청을 서비스하고, 읽고 쓰는 동안 걸린 시간을 최대 손실 레벨 캐시 대역폭의 퍼센티지로 계산합니다 손실 수준 캐시 제한 요인에는 사용 시간과 캐시 스레싱 또는 메인 메모리로부터의 배압으로 인한 중단 시간이 포함됩니다 GPU 손실 수준 캐시 제한 요인이 활용률보다 훨씬 높다면 캐시 스레싱 때문에 GPU가 많이 중단되고 있다는 뜻입니다 버퍼 크기를 줄여서 시공간적 지역성을 높여 이러한 중단을 줄일 수 있습니다

마찬가지로 MMU 카운터 트랙에서 MMU 제한 요인이 MMU 활용률보다 훨씬 높다면 기기 버퍼 액세스로 인해 TLB 누락이 생기고 MMU 스레싱이 발생하고 있는 것입니다 버퍼에 대한 비일관적인 메모리 액세스를 줄이면 이러한 중단을 줄이는 데 도움이 될 수 있습니다

기기 메모리 액세스를 최적화하고, 워크로드를 업데이트한 후, 다시 프로파일링합니다

다른 제한 요인이 높다면 이러한 요인을 줄이는 데 집중합니다 더 이상 점유율이 워크로드를 제한하지 않기 때문입니다 다른 제한 요인이 낮으면 낮은 점유율이 워크로드를 제한하지 않을 때까지 앞서 보여 드린 프로세스를 반복합니다

이렇게 새로 추가된 성능 카운터를 사용하면 명령어 실행 파이프라인의 가동을 유지하여 탁월한 셰이더 성능을 얻을 수 있습니다 이제 레이 트레이싱 프로파일링으로 넘어가겠습니다 Apple Family 9 GPU에 내장된 새로운 레이 트레이싱 하드웨어 액셀러레이터를 통해 놀랍도록 현실감 넘치는 장면을 실시간으로 렌더링할 수 있습니다 Xcode의 Metal 디버거로 레이 트레이싱 워크로드의 성능을 최적화하는 방법을 보여 드리겠습니다

저는 이 앱에서 트럭을 렌더링하고 있으며 레이 트레이싱으로 꽤 멋진 반사를 렌더링했습니다 새로운 하드웨어로 이미 놀라울 정도로 빠르게 렌더링되고 있지만 더 빠르게 만들 수 있는지 궁금합니다

따라서 높은 레이 트레이싱 성능 구현에 도움이 되도록 Xcode에는 인기 높은 가속 스트럭처 뷰어 외에도 새로운 레이 트레이싱 카운터 세트가 포함되었습니다 Ruiwei가 앞서 셰이더와 사용자 설정 충돌 함수 분석에 보여 드린 셰이더 코스트 그래프를 사용할 수도 있습니다 카운터부터 시작해 보겠습니다

렌더러의 프레임을 캡처하고 성능 타임라인을 열었습니다 최신 Xcode는 새로운 레이 트레이싱 하드웨어에서 워크로드의 실행 성능을 파악하는 데 도움이 되는 종합 트랙 세트가 포함된 새로운 레이 트레이싱 그룹을 제공합니다

각각 살펴보겠습니다

첫 번째 트랙은 광선의 점유율을 보여 줍니다 하드웨어는 많은 광선을 동시에 실행할 수 있으며 광선 점유율은 활성 광선의 퍼센티지를 보여 줍니다 스레드 점유율과 마찬가지로 Apple Family 9 GPU 셰이더 코어는 광선 점유율도 자동으로 최적화하여 앱이 최대 성능으로 실행되도록 합니다

광선 수로 인해 제 워크로드에 스타베이션이 없다고 가정하고 점유율 관리자 목표를 확인해 보겠습니다

이전과 동일한 프로세스를 따르되 L1 레지던시 및 대역폭에서 레이 트레이싱 스크래치 카테고리를 잘 보세요

레이 트레이싱 유닛은 L1의 일부분을 스크래치 버퍼로 유연하게 사용하므로 페이로드 크기를 줄여 최적화할 수 있습니다

다시 프로파일링하고 지난 섹션에서 보여 드린 분류 프로세스를 반복합니다

다음 트랙 세트는 활성 광선의 작업 내용을 퍼센티지로 표시해 개선이 필요한 영역을 더 잘 파악할 수 있습니다 예를 들어 이 시점에서 활성 광선의 75%는 인스턴스 변환을 하고 있었네요 제 장면에는 트럭 인스턴스 두 개밖에 없는데 너무 높은 것 같습니다

워크로드에서 이와 같은 현상을 발견하면 장면을 점검하여 인스턴스 중복을 최소화하는 것이 좋습니다 나중에 가속 스트럭처 뷰어에서 더 자세히 살펴보겠습니다 지금은 계속 진행하겠습니다

마지막으로 충돌 테스트 트랙은 수행 중인 프리미티브 충돌을 분석하여 퍼센티지로 보여 줍니다

이 렌더러는 하드웨어가 아무 동작 없이 불투명 삼각 테스트만 실행하고 있는 것으로 보입니다 최적의 성능을 얻으려면 불투명 삼각 테스트를 최대화하고 사용자 설정 충돌 함수는 알파 테스트를 요하는 객체 등 꼭 필요한 지오메트리에만 사용하세요

이렇게 새 레이 트레이싱 카운터를 소개했습니다 하드웨어의 워크로드 실행 상황을 파악하는 데 매우 유용하며, 성능 분류를 시작하기에 좋은 포인트입니다

예제에서 의심스러울 정도로 높은 인스턴스 변환을 발견했는데, 장면에 문제가 있을 수 있다는 뜻입니다

인스턴스 중복 등의 장면 문제를 분류하려면 가속 스트럭처 뷰어를 사용할 수 있습니다 자세히 보겠습니다 먼저 가속 스트럭처를 사용하는 디스패치를 ​ 찾아보겠습니다 타임라인에서 인코더를 클릭한 다음

디스패치를 ​ 선택합니다

마지막으로 인스턴스화된 가속 스트럭처를 이중 클릭합니다

가속 스트럭처 뷰어가 열립니다

왼쪽에서 가속 스트럭처의 세부 내용을 오른쪽에서 미리 보기를 볼 수 있습니다

또한 가속 스트럭처의 다양한 부분을 강조할 수도 있습니다

이제 변환을 조사하고 싶으므로 인스턴스 순회 강조 모드를 켜겠습니다 핫스팟이 파란색으로 표시됩니다 미리 보기를 보면 제가 예상했던 2가지 인스턴스보다 훨씬 더 많은 것 같습니다 이 진한 파란색 영역 위에 마우스를 올려 광선이 순회하는 인스턴스의 수를 정확히 보겠습니다 8개입니다 광선이 가장 가까운 충돌을 찾으려면 8개의 인스턴스를 순회해야 한다는 의미입니다 2개에 비해 너무 많습니다 활성 광선이 대부분 인스턴스 변환에서 실행되는 이유를 알겠습니다, 그런데 왜 이렇게 많아졌을까요?

각 인스턴스에 고유한 색상을 부여하는 인스턴스 강조 모드로 전환하겠습니다

트럭의 각 부품이 서로 다른 인스턴스로 중복되고 있습니다 이 경우 최적의 성능을 위해 이 인스턴스들을 하나의 프리미티브 가속 스트럭처로 결합해야 합니다 하지만 그것이 중심 해결책이 아닐 수 있습니다 이 가속 스트럭처 문제는 애셋 파이프라인 문제의 증상일 수 있습니다

그래서 저는 조사를 통해 트럭 애셋을 새롭게 만들었고

문제를 해결했습니다

인스턴스 순회가 얼마나 개선됐는지 보세요

요약하자면, 새로운 레이 트레이싱 카운터와 가속 스트럭처 뷰어를 사용하여 Apple Family 9 GPU의 놀라운 레이 트레이싱 성능을 최대한 활용할 수 있습니다

또한 화면의 세션에서 다른 레이 트레이싱 모범 사례를

계속 확인하시기 바랍니다

오늘의 내용을 모두 요약해 보겠습니다

Xcode 15는 Apple Family 9 GPU에 사용할 수 있는 새로운 최첨단 GPU 프로파일링 도구를 제공합니다 셰이더 코스트 그래프로 코스트가 높은 셰이더를 즉시 찾고 분류할 수 있습니다

성능 히트 맵을 사용하면 셰이더의 코스트를 올리는 객체나 픽셀을 정확하게 식별할 수 있습니다

셰이더 실행 기록 도구를 사용하면 실행 시간의 대부분을 차지하는 셰이더 함수를 손쉽게 찾을 수 있습니다

Xcode 15에 새로 추가된 성능 카운터로 점유율이 낮은 이유를 분류하고 성능을 개선할 수 있습니다

가속 스트럭처 뷰어를 포함한 새로운 레이 트레이싱 성능 카운트를 사용하여 최적의 레이 트레이싱 성능을 얻을 수 있습니다

시청해 주셔서 감사합니다

(오디오 없음)