다음을 통해 공유

DirectX 앱 프로파일링

  • 아티클

Windows 성능 도구 키트의 일부로 제공되는 XPerf 및 GPUView 도구를 사용하여 DirectX 앱에 대한 가장 중요한 성능 시간 측정을 측정하는 방법을 보여 줍니다. 이는 도구를 이해하기 위한 포괄적인 가이드가 아니라 DirectX 앱 성능을 분석하기 위한 구체적인 적용 가능성입니다. 여기서 설명하는 대부분의 기술은 모든 DirectX 앱과 관련이 있지만 SIS/VSIS 및 XAML 애니메이션을 사용하는 XAML 기반 DirectX 애플리케이션이 아니라 스왑 체인을 사용하는 앱과 가장 관련이 있습니다. 주요 성능 시간 측정, 도구를 획득 및 설치하는 방법, 성능 측정 추적을 수행한 다음, 분석하여 앱 병목 상태를 이해하는 방법을 안내합니다.

도구 정보

Xperf

XPerf 는 자세한 시스템 및 앱 성능 및 리소스 사용량을 측정하고 분석하도록 설계된 ETW(Windows용 이벤트 추적)를 기반으로 빌드된 성능 분석 도구 집합입니다. Windows 8 이 명령줄 도구에는 그래픽 사용자 인터페이스가 있으며 WPR(Windows Performance Recorder) 및 WPA(Windows 성능 분석기)라고 합니다. 이러한 도구에 대한 자세한 내용은 WPT( Windows Performance Toolkit ): Windows Performance Toolkit 웹 페이지에서 찾을 수 있습니다.

ETW는 요청된 커널 이벤트를 수집하고 ETL(이벤트 추적 로그) 파일이라는 파일에 저장합니다. 이러한 커널 이벤트는 앱을 실행할 때 앱 및 시스템 특성에 대한 광범위한 정보를 제공합니다. 데이터는 추적 캡처를 사용하도록 설정하고, 분석이 필요한 원하는 앱 시나리오를 수행하고, ETL 파일에 데이터를 저장하는 캡처를 중지하여 수집됩니다. 그런 다음 명령줄 도구xperf.exe또는 시각적 추적 분석 도구 xperfview.exe 사용하여 동일하거나 다른 컴퓨터에서 파일을 분석할 수 있습니다 .

GPUView

GPUView는 GPU (그래픽 처리 장치) 및 CPU의 성능을 결정하는 개발 도구입니다. DMA(직접 메모리 액세스) 버퍼 처리 및 비디오 하드웨어의 다른 모든 비디오 처리와 관련된 성능을 살펴봅니다.

GPU에 크게 의존하는 DirectX 앱의 경우 GPUView 는 CPU와 GPU에서 수행된 작업 간의 관계를 이해하는 강력한 도구입니다. GPUView에 대한 자세한 내용은 GPUView 사용을 참조하세요.

XPerf와 마찬가지로 ETW 추적은 먼저 추적 서비스를 시작하고, 고려 중인 앱에 대한 분석이 필요한 시나리오를 실행하고, 서비스를 중지하고, 정보를 ETL 파일에 저장하여 수행됩니다. GPUView 는 ETL 파일에 있는 데이터를 그래픽 형식으로 표시합니다.

GPUView 도구를 설치한 후에는 "GPUView 도움말" 메뉴에서 "GPUView의 기본 디스플레이" 항목을 읽는 것이 좋습니다. 여기에는 GPUView UI를 해석하는 방법에 대한 유용한 정보가 포함되어 있습니다.

도구 설치

XPerf와 GPUView는 모두 WPT(Windows Performance Toolkit)에 포함됩니다.

XPerf는 Windows용 Windows SDK(소프트웨어 개발 키트)의 일부로 제공됩니다. Windows SDK를 다운로드합니다.

GPUView 는 Windows ADK(Windows 평가 및 배포 키트)에서 사용할 수 있습니다. Windows ADK를 다운로드합니다.

설치 후 XPerf 및 GPUView 가 포함된 디렉터리를 시스템 "경로" 변수에 추가해야 합니다.

시작 단추를 클릭하고 "시스템 변수"를 입력합니다. 시스템 속성 창 열립니다. "시스템 환경 변수 편집"을 클릭합니다. "시스템 속성" 대화 상자에서 "환경 변수"를 선택합니다. "Path" 변수는 "시스템 변수" 아래에 있습니다. xperf.exe 포함하는 디렉터리를 추가하고 경로에 GPUView.exe. 이러한 실행 파일은 "Windows 키트" 내의 "Windows 성능 도구 키트" 디렉터리에 있습니다. 기본 위치는 C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit입니다.

성능 시간 측정

대부분의 앱은 원활하게 실행되고 사용자 입력에 응답할 것으로 예상합니다. 그러나 원하는 시나리오에 따라 성능의 한 측면이 다른 측면보다 더 중요할 수 있습니다. instance 경우 터치 태블릿 PC에서 실행되는 뉴스 판독기 앱의 경우 가장 중요한 측면은 한 번에 하나의 기사를 보고 동일하거나 다른 아티클을 이동/확대/스크롤하는 것입니다. 이 시나리오에서는 모든 프레임의 모든 콘텐츠를 렌더링하는 기능이 필요하지 않습니다. 그러나 터치 제스처에 따라 문서를 원활하게 스크롤하는 기능은 매우 중요합니다.

다른 instance 프레임이 삭제될 경우 많은 애니메이션 결함을 사용하는 게임 또는 비디오 렌더링 앱입니다. 이 경우 사용자 입력에서 상호 작용하지 않고 화면에 콘텐츠를 표시하는 기능이 매우 중요합니다.

앱의 어느 부분이 문제가 있는지 이해하기 위해 첫 번째 단계는 가장 중요한 시나리오를 결정하는 것입니다. 앱의 핵심 측면과 앱이 어떻게 행사되는지 이해되면 도구를 사용하여 문제를 찾는 것이 더 쉬워집니다.

가장 일반적인 성능 시간 메트릭 중 일부는 다음과 같습니다.

시작 시간

프로세스 시작부터 화면을 처음 치는 시점까지 측정된 시간입니다. 이 측정은 시스템이 웜일 때 더 유용합니다. 즉, 앱이 몇 번 실행된 후 측정이 수행됩니다.

프레임당 CPU 시간

CPU가 한 프레임 동안 앱 워크로드를 적극적으로 처리하는 시간입니다. 앱이 원활하게 실행되는 경우 한 프레임에 필요한 모든 처리가 하나의 v 동기화 간격 내에서 발생합니다. 모니터 새로 고침 속도가 60Hz이면 프레임당 16ms가 됩니다. CPU 시간/프레임이 16ms보다 큰 경우 결함이 없는 앱 환경을 생성하려면 CPU 최적화가 필요할 수 있습니다.

프레임당 GPU 시간

GPU가 한 프레임 동안 앱 워크로드를 적극적으로 처리하는 시간입니다. 데이터 프레임을 처리하는 데 걸리는 시간이 16ms를 초과하면 앱이 GPU에 바인딩됩니다.

앱이 CPU 또는 GPU 바인딩되어 있는지 여부를 이해할 수 있으면 코드의 문제가 있는 부분이 좁아집니다.

성능 시간 측정 추적

추적을 수행하려면 다음 단계를 수행합니다.

  1. 관리자 권한으로 명령 창을 엽니다.
  2. 이미 실행 중인 경우 앱을 닫습니다.
  3. 디렉터리를 Windows Performance Toolkit 폴더 내의 gpuview 디렉터리로 변경합니다.
  4. 이벤트 추적을 시작하려면 "log.cmd"를 입력합니다. 이 옵션은 가장 흥미로운 이벤트를 기록합니다. 사용 가능한 다른 옵션은 이벤트의 다른 scope 기록합니다. instance 'v' 또는 자세한 로그 모드의 경우 GPUView에서 알고 있는 모든 이벤트를 캡처합니다.
  5. 샘플을 시작하고 분석해야 하는 성능 경로를 다루는 방식으로 샘플을 연습합니다.
  6. 명령 창에 돌아가기 "log.cmd"를 다시 입력하여 로깅을 중지합니다.
  7. 그러면 gpuview 폴더에 "merged.etl"이라는 파일이 출력됩니다. 이 파일을 다른 위치에 저장할 수 있으며 동일하거나 다른 컴퓨터에서 분석할 수 있습니다. 스택 캡처 세부 정보를 보려면 앱과 연결된 기호 파일(.pdb)을 저장합니다.

측정

참고

기하 도형 실현 샘플에 대한 측정값은 통합 DirectX11 그래픽 카드 있는 Quad Core 컴퓨터에서 수행됩니다. 측정값은 컴퓨터 구성에 따라 달라집니다.

 

이 섹션에서는 프레임 단위당 시작 시간, CPU 및 GPU 시간을 측정하는 방법을 보여 줍니다. 컴퓨터에서 동일한 샘플에 대한 성능 추적을 캡처하고 다양한 측정값의 차이점을 확인할 수 있습니다.

GPUView에서 추적을 분석하려면 GPUView.exe사용하여 "merged.elt" 파일을 엽니다.

시작 시간

시작 시간은 콘텐츠가 화면에 처음 나타날 때까지 앱 시작에서 소요된 총 시간으로 측정됩니다.

시작 시간 측정은 다음 변형을 사용하여 이전 섹션에 나열된 단계에 따라 수행하는 것이 가장 좋습니다.

  • 앱을 처음 시작할 때 시작 측정을 수행하는 경우 콜드 시작이라고 합니다. 이는 짧은 시간 동안 앱을 몇 번 실행한 후 수행된 측정값과 다를 수 있습니다. 이를 웜 시작이라고 합니다. 앱이 시작할 때 만드는 리소스 수에 따라 두 시작 시간 사이에 큰 차이가 있을 수 있습니다. 앱 목표에 따라 하나 또는 다른 것을 측정하는 것이 바람직할 수 있습니다.
  • 성능 정보를 기록할 때 첫 번째 프레임이 화면에 표시되는 즉시 앱을 종료합니다.

GPUView를 사용하여 시작 시간 계산

  1. GPUView에서 관련 프로세스까지 아래로 스크롤합니다. 이 경우 GeometryRealization.exe.

    GPUView의 프로세스 예제를 보여 주는 스크린샷

  2. 컨텍스트 CPU 큐는 하드웨어에 큐에 대기 중인 그래픽 워크로드를 나타내지만 반드시 하드웨어에서 처리되는 것은 아닙니다. 추적 파일이 열리면 추적이 수행된 시간 사이에 기록된 모든 이벤트가 표시됩니다. 시작 시간을 계산하려면 Ctrl +Z를 사용하여 관심 영역을 선택하고 첫 번째 컨텍스트 CPU 큐의 초기 부분(활동을 표시하는 큐)으로 확대합니다. GPUView 컨트롤에 대한 자세한 내용은 GPUView 도움말 파일 섹션 "GPUView 컨트롤 요약"에서 찾을 수 있습니다. 아래 그림은 컨텍스트 CPU 큐의 첫 번째 부분으로 확대된 GeometryRealization.exe 프로세스만 보여줍니다. 컨텍스트 CPU 큐의 색은 큐 바로 아래의 사각형으로 표시되며 큐의 동일한 색 데이터 패킷은 하드웨어에서 대기 중인 GPU 작업을 표시합니다. 컨텍스트 큐의 해치 패턴 패킷은 현재 패킷을 보여 줍니다. 즉, 앱은 하드웨어가 화면에 콘텐츠를 표시하려고 합니다.

    '컨텍스트 C P U 큐'의 예를 보여 주는 스크린샷

  3. 시작 시간은 컨텍스트가 처음 나타날 때까지(이 경우 UI 스레드 진입점 모듈 SHCORE.dll) 앱을 처음 시작하는 시간입니다(해치 패킷으로 표시됨). 이 그림에서는 관심 영역을 강조 표시합니다.

    참고

    실제 현재 정보는 대칭 이동 큐에 표시되므로 현재 패킷이 실제로 대칭 이동 큐에서 완료될 때까지 시간이 연장됩니다.

     

    전체 상태 표시줄은 강조 표시된 부분 간의 경과 시간도 보여 주어 아래 그림에 표시되지 않습니다. 앱의 시작 시간입니다. 이 경우 위에서 언급 한 기계의 경우 약 240ms로 나왔습니다.

    '컨텍스트 CP U 큐'의 시작 시간과 관련된 관심 영역을 보여 주는 스크린샷

프레임당 CPU 및 GPU 시간

CPU 시간을 측정할 때 고려해야 할 몇 가지 사항이 있습니다. 분석할 시나리오를 연습한 추적의 영역을 찾습니다. instance 기하 도형 실현 샘플에서 분석된 시나리오 중 하나는 렌더링 2048과 8192 기본 형식 간의 전환이며, 모두 실현되지 않았습니다(있는 것처럼 기하 도형은 모든 프레임에 테셀레이션되지 않음). 추적은 기본 형식 수의 전환 전후 CPU 및 GPU 작업의 차이를 명확하게 보여 줍니다.

프레임당 CPU 및 GPU 시간을 계산하기 위해 두 가지 시나리오를 분석하고 있습니다. 다음과 같습니다.

  • 렌더링 2048 미실현 기본 형식에서 8192개의 실현되지 않은 기본 형식으로 전환.
  • 렌더링 8192 실현된 기본 형식에서 8192개의 실현되지 않은 기본 형식으로 전환.

두 경우 모두 프레임 속도가 급격히 떨어지는 것으로 관찰되었습니다. CPU 및 GPU 시간을 측정하면 두 패턴 간의 관계와 추적의 몇 가지 다른 패턴이 앱의 문제가 있는 영역에 대한 유용한 정보를 제공할 수 있습니다.

2048 기본 형식이 실현되지 않은 상태로 렌더링되는 CPU 및 GPU 시간 계산

  1. GPUView.exe사용하여 추적 파일을 엽니다.

  2. GeometryRealization.exe 프로세스까지 아래로 스크롤합니다.

  3. CPU 시간을 계산할 영역을 선택하고 CTRL + Z를 사용하여 확대합니다.

    '컨텍스트 CPU 큐'에서 CP U 시간을 계산하기 위해 선택한 영역을 보여 주는 스크린샷

  4. F8 간에 전환하여 V 동기화 정보를 표시합니다. 한 대 동기화 수준의 데이터를 명확하게 볼 수 있도록 확대를 유지합니다. 파란색 선은 v 동기화 시간이 있는 위치입니다. 일반적으로 16ms(60fps)에 한 번씩 발생하지만 DWM에 성능 문제가 발생하면 속도가 느려지므로 32ms(30fps)에 한 번씩 발생합니다. 시간을 파악하려면 한 파란색 막대에서 다음 막대로 선택한 다음 GPUView 창의 오른쪽 아래 모서리에 보고된 ms 수를 확인합니다.

    V 동기화 시간의 예를 보여 주는 스크린샷

  5. 프레임당 CPU 시간을 측정하려면 렌더링과 관련된 모든 스레드에서 소요된 시간을 측정합니다. 성능 관점에서 가장 관련성이 있을 것으로 예상되는 스레드의 범위를 좁히는 것이 좋습니다. 기하 도형 실현 샘플의 instance 콘텐츠는 애니메이션 효과를 주므로 UI 스레드가 중요한 프레임마다 화면에 렌더링되어야 합니다. 살펴볼 스레드가 결정되면 이 스레드의 막대 길이를 측정합니다. 이러한 중 몇 가지를 평균화하면 프레임당 CPU 시간이 생성됩니다. 아래 그림은 UI 스레드에서 소요된 시간을 보여줍니다. 또한 이번에는 60FPS에 도달한다는 것을 의미하는 두 개의 연속된 v 동기화 사이에 잘 맞는 것을 보여 줍니다.

    U I 스레드에서 소요된 시간을 보여 주는 스크린샷

    DWM이 모든 프레임을 표시할 수 있음을 보여 주는 해당 시간 프레임에 대한 대칭 이동 큐를 확인하여 확인할 수도 있습니다.

    '대칭 이동 큐'의 예를 보여 주는 스크린샷

  6. GPU 시간은 CPU 시간과 동일한 방식으로 측정할 수 있습니다. CPU 시간을 측정하는 경우와 같이 관련 영역을 확대합니다. 컨텍스트 CPU 큐의 색과 동일한 색으로 GPU 하드웨어 큐의 막대 길이를 측정합니다. 막대가 연속 V 동기화 내에 맞는 한 앱은 60FPS에서 원활하게 실행됩니다.

    앱이 60FP S에서 실행되고 있는 정보를 표시하는 'GPU 하드웨어 큐'의 예를 보여 주는 스크린샷

8192 기본 형식이 실현되지 않은 상태로 렌더링되는 CPU 및 GPU 시간 계산

  1. 동일한 단계를 다시 수행하면 추적은 한 프레임에 대한 모든 CPU 작업이 한 v 동기화와 다음 프레임 사이에 맞지 않음을 보여 줍니다. 즉, 앱이 CPU에 바인딩됩니다. UI 스레드가 CPU를 포화 상태입니다.

    CP U를 포화시키는 UI 스레드의 예를 보여 주는 스크린샷.

    대칭 이동 큐를 살펴보면 DWM이 모든 프레임을 표시할 수 없다는 것도 분명합니다.

    모든 프레임을 표시할 수 없는 D W M의 예를 보여 주는 스크린샷

  2. 시간이 소요되는 위치를 분석하려면 XPerf에서 추적을 엽니다. XPerf에서 시작 시간을 분석하려면 먼저 GPUView에서 시간 간격을 찾습니다. 간격의 왼쪽과 오른쪽 위에 마우스를 놓고 GPUView 창 아래쪽에 표시된 절대 시간을 기록해 둡다. 그런 다음 XPerf 에서 동일한 .etl 파일을 열고 "CPU별 CPU 샘플링" 그래프까지 아래로 스크롤하고 마우스 오른쪽 단추를 클릭하고 "간격 선택..."을 선택합니다. 이렇게 하면 GPU 추적을 확인하여 검색된 관심 간격을 입력할 수 있습니다.

    'Windows 성능 분석'에서 'CP U별 CP U 샘플링'을 보여 주는 스크린샷

  3. 추적 메뉴로 이동하여 "기호 로드"가 선택되어 있는지 확인합니다. 또한 추적 -> 기호 경로 구성으로 이동하여 앱 기호 경로를 입력합니다. 기호 파일에는 별도의 데이터베이스(.pdb)에서 컴파일된 실행 파일에 대한 디버깅 정보가 포함되어 있습니다. 이 파일은 일반적으로 PDB라고 합니다. 기호 파일에 대한 자세한 내용은 기호 파일에서 찾을 수 있습니다. 이 파일은 앱 디렉터리의 "디버그" 폴더에 있을 수 있습니다.

  4. 앱에서 시간이 소요되는 위치를 분석하려면 이전 단계에서 선택한 간격을 마우스 오른쪽 단추로 클릭하고 요약 테이블을 클릭합니다. 각 dll에서 소요되는 시간에 대한 개요를 보려면 "열" 메뉴에서 "스택"을 선택 취소합니다. 여기의 "개수" 열에는 지정된 dll/함수 내에 있는 샘플 수가 표시됩니다. ms당 약 1개의 샘플이 사용되므로 이 숫자는 각 dll/함수에 소요되는 시간을 가장 잘 추측하는 데 사용할 수 있습니다. 열 메뉴에서 "스택"을 확인하면 호출 그래프의 각 함수에 소요된 포괄 시간이 제공됩니다. 이렇게 하면 문제 지점을 더 세분화할 수 있습니다.

  5. 2048 미실현 기본 형식에 대한 스택 추적 정보는 CPU 시간의 30%가 기하 도형 실현 프로세스에 소요되는 것으로 나타났습니다. 그 중 약 36 %의 시간이 기하 도형 테셀레이션 및 쓰다듬기에서 소비되고 있습니다.

  6. 8192 미실현 기본 형식에 대한 스택 추적 정보는 CPU 시간(4코어)의 약 60%가 기하 도형 실현에 소요되는 것으로 나타났습니다.

    CP U 시간에 대한 스택 추적 정보를 보여 주는 스크린샷

8192 기본 형식이 렌더링되는 CPU 시간 계산 실현

앱이 CPU에 바인딩되어 있다는 것은 프로필에서 분명합니다. CPU에서 소요되는 시간을 줄이기 위해 기하 도형을 한 번 만들어 캐시할 수 있습니다. 캐시된 콘텐츠는 프레임당 기하 도형 분할 비용을 발생시키지 않고 모든 프레임에 렌더링할 수 있습니다. GPUView에서 앱의 실현된 부분에 대한 추적을 살펴보면 DWM이 모든 프레임을 표시할 수 있고 CPU 시간이 크게 단축된 것이 분명합니다.

D W M이 모든 프레임을 표시할 수 있음을 보여 주는 GPUView의 추적 예제를 보여 주는 스크린샷

그래프의 첫 번째 부분에서는 실현된 8192개의 기본 형식을 보여 줍니다. 프레임당 해당 CPU 시간은 두 개의 연속 V 동기화 내에 들어갈 수 있습니다. 그래프의 뒷부분에서 이것은 사실이 아닙니다.

XPerf를 살펴보면 CPU가 기하 도형 실현 앱에 소요되는 CPU 시간의 약 25%만 사용하여 가장 긴 시간 동안 유휴 상태로 유지됩니다.

gpuview 스크린샷.

요약

GPUView와 XPerf 모두 DirectX 앱의 성능을 분석하기 위한 강력한 도구입니다. 이 문서는 이러한 도구를 사용하고 기본 성능 측정 및 앱 특성을 이해하기 위한 입문서입니다. 도구 사용을 이해하는 것 외에도 먼저 분석 중인 앱을 이해하는 것이 중요합니다. 앱이 달성하려는 것과 같은 질문에 대한 답변을 찾는 것부터 시작하세요. 시스템에서 가장 중요한 스레드는 무엇인가요? 어떤 장만을 기꺼이 하시겠습니까? 성능 추적을 분석할 때는 문제가 있는 명백한 위치를 확인하여 시작합니다. 앱 CPU 또는 GPU가 바인딩되어 있나요? 앱이 모든 프레임을 표시할 수 있나요? 앱에 대한 이해와 함께 도구는 성능 문제를 이해하고 찾고 마지막으로 해결하는 데 매우 유용한 정보를 제공할 수 있습니다.