Profilowanie aplikacji DirectX

Pokazuje to, jak zmierzyć niektóre z najważniejszych pomiarów czasu wydajności dla aplikacji DirectX przy użyciu narzędzi XPerf i GPUView , które są dostarczane jako część zestawu narzędzi Windows Performance Toolkit. Nie jest to kompleksowy przewodnik po zrozumieniu narzędzi, a raczej ich specyficznego zastosowania do analizowania wydajności aplikacji DirectX. Chociaż większość omówionych tutaj technik jest istotna dla wszystkich aplikacji DirectX, jest to najbardziej istotne dla aplikacji korzystających z łańcuchów wymiany, a nie do aplikacji DirectX opartych na języku XAML korzystających z animacji SIS/VSIS i XAML. Przeprowadzimy Cię przez kluczowe pomiary czasu wydajności, sposób uzyskiwania i instalowania narzędzi oraz analizowania śladów pomiarów wydajności, a następnie analizowania ich w celu zrozumienia wąskich gardeł aplikacji.

Informacje o narzędziach

XPerf

XPerf to zestaw narzędzi do analizy wydajności opartych na śledzeniu zdarzeń dla systemu Windows (ETW) przeznaczonym do mierzenia i analizowania szczegółowego systemu oraz wydajności aplikacji i użycia zasobów. Począwszy od systemu Windows 8 to narzędzie wiersza polecenia ma graficzny interfejs użytkownika i jest nazywany Windows Performance Recorder (WPR) i Windows Performance Analyzer (WPA). Więcej informacji na temat tych narzędzi można znaleźć na stronie internetowej zestawu narzędzi Windows Performance Toolkit (WPT): Windows Performance Toolkit.

EtW zbiera żądane zdarzenia jądra i zapisuje je w pliku nazywanym plikiem dziennika śledzenia zdarzeń (ETL). Te zdarzenia jądra dostarczają obszerne informacje o charakterystykach aplikacji i systemu podczas uruchamiania aplikacji. Dane są zbierane przez włączenie zapisu śladu, wykonanie żądanego scenariusza aplikacji, który ma być analizowany, zatrzymanie zapisu, co powoduje zapisanie danych w pliku ETL. Następnie możesz przeanalizować plik na tej samej lub innej maszynie przy użyciu narzędzia wiersza polecenia xperf.exe lub narzędzia do analizy śledzenia wizualnego xperfview.exe.

Widok procesora GPU

GPUView to narzędzie programistyczne służące do określania wydajności procesora graficznego (GPU) i procesora CPU. Analizuje wydajność w odniesieniu do przetwarzania buforu bezpośredniego dostępu do pamięci (DMA) i wszystkich innych procesów przetwarzania wideo w sprzęcie wideo.

W przypadku aplikacji DirectX , które intensywnie korzystają z procesora GPU, funkcja GPUView to zaawansowane narzędzie do zrozumienia relacji między pracą wykonywaną na procesorze CPU a procesorem GPU. Aby uzyskać więcej informacji o GPUView, zobacz Korzystanie z GPUView.

Podobnie jak XPerf, ślad ETW jest najpierw rejestrowany przez uruchomienie usługi śledzenia, realizując scenariusz, który wymaga analizy w danej aplikacji, a następnie zatrzymanie usługi i zapisanie informacji w pliku ETL. Element GPUView przedstawia dane obecne w pliku ETL w formacie graficznym.

Po zainstalowaniu narzędzia GPUView zalecamy przeczytanie tematu "Główny wyświetlacz gpuView" w menu "GpuView Pomoc". Zawiera przydatne informacje na temat interpretowania interfejsu użytkownika GPUView.

Instalowanie narzędzi

Zarówno XPerf , jak i GPUView są zawarte w zestawie narzędzi Windows Performance Toolkit (WPT).

Narzędzie XPerf jest dostarczane jako część zestawu Windows Software Development Kit (SDK) dla systemu Windows. Pobierz zestaw Windows SDK.

GPUView jest dostępny w zestawie Windows Assessment and Deployment Kit (Windows ADK). Pobierz zestaw Windows ADK.

Po zakończeniu instalacji należy dodać katalogi zawierające XPerf i GPUView do zmiennej systemowej "Path".

Kliknij przycisk Start i wpisz "Zmienne systemowe". Zostanie otwarte okno Właściwości systemu. Kliknij pozycję "Edytuj zmienne środowiskowe systemu". Wybierz pozycję "Zmienne środowiskowe" w oknie dialogowym "Właściwości systemu". Zmienna "Path" znajduje się w obszarze "Zmienne systemowe". Dołącz katalog zawierający xperf.exe i GPUView.exe do ścieżki. Te pliki wykonywalne znajdują się w katalogu "Windows Performance Toolkit" w "Zestawach Windows". Lokalizacja domyślna to : C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit.

Pomiary czasu wydajności

Większość aplikacji oczekuje bezproblemowego działania i odpowiada na dane wejściowe użytkownika. Jednak w zależności od scenariusza, który chcesz, jeden aspekt wydajności może być ważniejszy niż inny. Na przykład w przypadku aplikacji czytnika wiadomości działającej na komputerze z tabletem dotykowym najważniejszym aspektem jest wyświetlenie pojedynczego artykułu naraz i przesuwanie/powiększanie/przewijanie tego samego lub innego artykułu. W tym scenariuszu możliwość renderowania całej zawartości każdej ramki nie jest konieczna. Jednak możliwość płynnego przewijania artykułu za pomocą gestu dotykowego jest niezwykle ważna.

W innym przypadku gra lub aplikacja do renderowania wideo, która używa wielu animacji, miewa usterki, jeśli zgubione są ramki. W takim przypadku możliwość prezentowania treści na ekranie bez zakłóceń spowodowanych przez dane wejściowe użytkownika jest niezwykle ważna.

Aby zrozumieć, która część aplikacji jest problematyczna, pierwszym krokiem jest podjęcie decyzji o najważniejszych scenariuszach. Gdy podstawowe aspekty aplikacji zostaną zrozumiane i jak będą wykonywane, wyszukiwanie problemów przy użyciu narzędzi staje się łatwiejsze.

Oto niektóre z najbardziej typowych metryk czasu wydajności:

Czas uruchamiania

Czas mierzony od uruchomienia procesu do pierwszego wyświetlenia ekranu. Ta miara jest bardziej przydatna, gdy system jest ciepły, co oznacza, że pomiar jest wykonywany po uruchomieniu aplikacji kilka razy.

Czas CPU na ramkę

Czas, w którym CPU aktywnie procesuje obciążenie aplikacji dla jednej klatki. Jeśli aplikacja działa płynnie, całe przetwarzanie wymagane dla jednej ramki odbywa się w ramach jednego interwału v-sync. Przy częstotliwości odświeżania monitora wynoszącego 60Hz jest to 16 ms na ramkę. Jeśli czas procesora na klatkę jest większy niż 16 ms, mogą być konieczne optymalizacje procesora, aby zapewnić płynne działanie aplikacji.

Czas procesora GPU na ramkę

Czas, w którym procesor graficzny (GPU) aktywnie przetwarza obciążenie pracą aplikacji dla jednej klatki. Aplikacja jest ograniczona przez GPU, gdy czas potrzebny na przetworzenie ramki danych wynosi ponad 16 ms.

Możliwość zrozumienia, czy aplikacja jest powiązana z procesorem CPU, czy procesorem GPU, zawęzi problematyczną część kodu.

Śledzenie pomiaru czasu wydajności

Wykonaj następujące kroki, aby uzyskać śledzenie:

1. Otwórz okno polecenia jako administrator.
2. Zamknij aplikację, jeśli jest już uruchomiona.
3. Zmień katalogi na katalog gpuview w folderze Windows Performance Toolkit.
4. Wpisz "log.cmd", aby rozpocząć śledzenie zdarzeń. Ta opcja rejestruje najbardziej interesujące zdarzenia. Inne dostępne opcje rejestrują inny zakres zdarzeń. Na przykład tryb 'v' lub tryb szczegółowego logowania przechwytuje wszystkie zdarzenia, które są rozpoznawane przez GPUView.
5. Uruchom próbkę i przećwicz próbkę w sposób, który obejmuje ścieżkę wydajności, którą należy przeanalizować.
6. Wróć do okien poleceń i ponownie wpisz "log.cmd", aby zatrzymać rejestrowanie.
7. Spowoduje to utworzenie pliku o nazwie "merged.etl" w folderze gpuview . Możesz zapisać ten plik w innej lokalizacji i przeanalizować go na tej samej lub innej maszynie. Aby wyświetlić szczegóły przechwytywania stosu, zapisz plik symboli (.pdb) skojarzony z aplikacją.

Pomiar

W tej sekcji pokazano, jak mierzyć czas uruchamiania, czas CPU i czas GPU dla pomiarów na klatkę. Możesz przechwycić ślad wydajności dla tej samej próbki na maszynie i zobaczyć różnice w różnych pomiarach.

Aby przeanalizować ślad w widoku GPUView, otwórz plik "merged.elt" przy użyciu GPUView.exe.

Czas uruchamiania

Czas uruchamiania jest mierzony przez całkowity czas spędzony od początku aplikacji do momentu wyświetlenia zawartości na ekranie.

Pomiar czasu uruchamiania najlepiej wykonać, wykonując kroki wymienione w poprzedniej sekcji z następującymi odmianami:

• Jeśli podczas pierwszego uruchomienia aplikacji wykonasz pomiary rozruchu, nazywa się to zimnym startem. Może się to różnić od pomiarów wykonanych po kilkukrotnym uruchomieniu aplikacji w krótkim czasie. Nazywa się to ciepłym rozruchem. W zależności od liczby zasobów tworzonych przez aplikację podczas uruchamiania może istnieć duża różnica między dwoma czasami uruchamiania. W zależności od celów aplikacji pomiar jednego lub drugiego może być pożądany.
• Po zarejestrowaniu informacji o wydajności zakończ działanie aplikacji natychmiast po wyświetleniu pierwszej ramki na ekranie.

Obliczanie czasu uruchamiania przy użyciu widoku GPUView

1. W widoku GPUView przewiń w dół do odpowiedniego procesu, w tym przypadku GeometryRealization.exe.

   

2. Kolejka kontekstu CPU reprezentuje obciążenie grafiki skierowane do sprzętu, ale nie jest koniecznie przetwarzane przez sprzęt. Po otwarciu pliku śledzenia są wyświetlane wszystkie zdarzenia rejestrowane między czasem śledzenia. Aby obliczyć czas uruchamiania, wybierz interesujący go region, powiększ początkową część pierwszej kolejki procesora CPU kontekstu (jest to ten, który pokazuje działanie) za pomocą Ctrl +Z. Więcej informacji na temat kontrolek GPUView można znaleźć w sekcji plik pomocy gpuView "Podsumowanie kontrolek GPUView ". Na poniższej ilustracji przedstawiono tylko proces GeometryRealization.exe zawężony do pierwszej części kolejki CPU w kontekście. Kolor kolejki procesora CPU w kontekście jest oznaczony prostokątem bezpośrednio poniżej kolejki, a pakiety danych w tym samym kolorze w kolejce pokazują, że praca procesora GPU znajduje się w kolejce na sprzęcie. Pakiet wzorca kreskowania w kolejce kontekstowej pokazuje obecny pakiet, co oznacza, że aplikacja chce, aby sprzęt prezentował zawartość na ekranie.

   

3. Czas uruchamiania to czas od pierwszego uruchomienia aplikacji (w tym przypadku moduł wejściowy wątku interfejsu użytkownika SHCORE.dll) do momentu, gdy kontekst pojawi się po raz pierwszy (oznaczony przez pakiet hatch). Na rysunku wyróżniono obszar zainteresowania.

   Uwaga / Notatka

   Aktualne informacje obecne są reprezentowane w kolejce przerzucania, co przedłuża czas, aż obecny pakiet faktycznie zakończy działanie w kolejce przerzucania.

    

   Pełny pasek stanu nie jest widoczny na poniższej ilustracji, który pokazuje również czas, jaki upłynął między wyróżnionymi częściami. Jest to czas uruchamiania aplikacji. W przypadku wspomnianej maszyny czas wyniósł około 240 ms.

   

Czas CPU i GPU na ramkę

Istnieje kilka kwestii, które należy wziąć pod uwagę podczas mierzenia czasu procesora CPU. Poszukaj obszarów w śladzie, w którym wykonano ćwiczenie scenariusza do przeanalizowania. Na przykład w przykładowej realizacji geometrii jednym ze scenariuszy, które zostały przeanalizowane, jest przejście między renderowaniem 2048 oraz 8192 prymitywów, wszystkie niezrealizowane (co oznacza, że geometria nie jest teselowana w każdej klatce). Ślad wyraźnie pokazuje różnicę w aktywności CPU i GPU przed i po zmianie liczby prymitywów.

Dwa scenariusze są analizowane w celu obliczenia czasu CPU i GPU na klatkę. Są one następujące.

• Przejście z renderowania 2048 niezrealizowanych elementów pierwotnych na 8192 niezrealizowane elementy pierwotne.
• Przejście z renderowania 8192 zrealizowanych prymitywów do 8192 niezrealizowanych prymitywów.

W obu przypadkach zaobserwowano, że szybkość klatek spadła drastycznie. Mierzenie czasu procesora CPU i procesora GPU, relacja między nimi, a także kilka innych wzorców w śladzie może dać przydatne informacje o problematycznych obszarach w aplikacji.

Obliczanie czasu procesora CPU i procesora GPU, gdy 2048 elementów pierwotnych jest renderowanych w sposób niezrealizowany

1. Otwórz plik śledzenia przy użyciu GPUView.exe.

2. Przewiń w dół do procesu GeometryRealization.exe.

3. Wybierz obszar do obliczania czasu procesora CPU i powiększ go przy użyciu kombinacji CTRL + Z.

   

4. Pokaż informacje o synchronizacji wirtualnej, przełączając się między F8. Powiększaj obraz, aż łatwo zobaczysz wyraźnie jeden vsync danych. Niebieskie linie to czasy synchronizacji pionowej. Zwykle występują one raz na 16 ms (60 kl./s), ale jeśli usługa DWM napotka problem z wydajnością, działa wolniej, więc wystąpią one raz na 32 ms (30 kl./s). Aby uzyskać poczucie czasu, zaznacz obszar od jednego niebieskiego paska do następnego, a następnie przyjrzyj się liczbie ms zgłoszonych w prawym dolnym rogu okna GPUView.

   

5. Aby zmierzyć czas procesora CPU na ramkę, zmierz czas potrzebny wszystkim wątkom zaangażowanym w renderowanie. Warto zawęzić wątek, który ma być najbardziej istotny z punktu widzenia wydajności. Na przykład w przykładzie realizacji geometrii zawartość jest animowana i musi być renderowana na ekranie w każdej klatce, co sprawia, że wątek interfejsu użytkownika jest kluczowy. Po ustaleniu, który wątek ma być oglądany, zmierz długość słupków w tym wątku. Średnia z kilku z tych daje czas CPU na klatkę. Na poniższej ilustracji przedstawiono czas zajmowany na wątku interfejsu użytkownika. Pokazuje również, że ten czas dobrze wpasowuje się między dwoma kolejnymi synchronizacjami pionowymi, co oznacza, że osiąga 60 FPS.

   

   Możesz również sprawdzić, przeglądając kolejkę przerzucania odpowiedniego przedziału czasu, co pokazuje, że usługa DWM może przedstawić każdą ramkę.

   

6. Czas procesora GPU można zmierzyć w taki sam sposób, jak czas procesora CPU. Powiększ odpowiedni obszar, podobnie jak przy pomiarze czasu CPU. Zmierz długość pasków w sprzętowej kolejce GPU, które mają ten sam kolor co paski w kolejce CPU kontekstowej. Tak długo, jak paski mieszczą się w ciągłych synchronizacjach pionowych, aplikacja działa płynnie przy 60 klatkach na sekundę (FPS).

   

Obliczanie czasu CPU i GPU, gdy 8192 prymitywy są renderowane bez realizacji.

1. Jeśli ponownie wykonasz te same kroki, ślad pokazuje, że cała praca procesora CPU dla jednej klatki nie mieści się między jedną synchronizacją pionową a następną. Oznacza to, że aplikacja jest powiązana z procesorem CPU. Wątek interfejsu użytkownika obciąża procesor.

   

   Patrząc na kolejkę przerzucania, widać również, że usługa DWM nie jest w stanie wyświetlić każdej klatki.

   

2. Aby przeanalizować, gdzie jest poświęcany czas, otwórz ślad w narzędziu XPerf. Aby przeanalizować czas uruchamiania w środowisku XPerf, najpierw znajdź interwał czasu w widoku GPUView. Umieść wskaźnik myszy po lewej i prawej stronie interwału i zanotuj bezwzględny czas wyświetlany w dolnej części okna GPUView. Następnie otwórz ten sam plik .etl w narzędziu XPerf i przewiń w dół do wykresu "Próbkowanie CPU według CPU", kliknij prawym przyciskiem myszy i wybierz "Wybierz interwał...". Pozwala to na wpisanie interesującego interwału, który został odnaleziony podczas przeglądania śladu GPU.

   

3. Przejdź do menu Śledzenie i upewnij się, że zaznaczono pole wyboru "Załaduj symbole". Przejdź również do opcji Śledzenie —> Konfiguracja ścieżek symboli i wpisz ścieżkę symboli aplikacji. Plik symboli zawiera informacje debugowania o skompilowanym pliku wykonywalnym w oddzielnej bazie danych (.pdb). Ten plik jest często określany jako plik PDB. Więcej informacji na temat plików symboli można znaleźć tutaj: Pliki symboli. Ten plik można znaleźć w folderze "Debuguj" katalogu aplikacji.

4. Aby uzyskać podział czasu spędzonego w aplikacji, kliknij prawym przyciskiem myszy interwał wybrany w poprzednim kroku i kliknij pozycję Tabela podsumowania. Aby zapoznać się z omówieniem ilości czasu spędzonego w każdej dll, usuń zaznaczenie pola wyboru "Stack" z menu "Kolumny". Zwróć uwagę, że tutaj kolumna "Count" ("Liczba") pokazuje, ile próbek znajduje się w danej bibliotece dll/funkcji. Ponieważ około jedna próbka jest pobierana na ms, tej liczby można użyć jako najlepszej oceny, ile czasu spędza się w każdej funkcji dll. Zaznaczenie opcji "Stos" w menu Kolumny pokaże czas inkluzywny spędzony w każdej funkcji w grafie wywołań. Pomoże to jeszcze bardziej rozbić punkty problemu.

5. Informacje o śledzeniu stosu dla 2048 niezrealizowanych prymitywów pokazują, że 30% czasu CPU jest poświęcany na proces realizacji geometrii. Z tego około 36% czasu jest spędzone w tessellation geometrii i głaskanie.

6. Informacje śledzenia stosu dla 8192 niezrealizowane elementy pierwotne pokazują, że około 60% czasu procesora CPU (4 rdzenie) jest poświęcane na realizację geometrii.

   

Obliczanie czasu procesora przy renderowaniu 8192 elementów pierwotnych

Z profilów wynika, że aplikacja jest powiązana z procesorem CPU. Aby skrócić czas pracy procesora, geometrie można utworzyć raz i buforować. Buforowana zawartość może być renderowana w każdej ramce bez ponoszenia nakładów tesselacji geometrii dla każdej ramki. Patrząc na ślad w narzędziu GPUView dla zrealizowanej części aplikacji, jasne jest, że DWM jest w stanie przedstawić każdą klatkę, a czas pracy CPU znacznie się zmniejszył.

Pierwsza część wykresu pokazuje zrealizowane 8192 elementy pierwotne. Czas CPU na ramkę mieści się w dwóch kolejnych synchronizacjach pionowych. W dalszej części grafu nie jest to prawdą.

Przeglądając XPerf, procesor jest bezczynny przez dłuższy czas, a tylko około 25% czasu procesora jest wykorzystywane przez aplikację do realizacji geometrii.

Podsumowanie

Zarówno GPUView, jak i XPerf to zaawansowane narzędzia do analizowania wydajności aplikacji DirectX. Ten artykuł jest podstawowym elementem do korzystania z tych narzędzi i zrozumienia podstawowych pomiarów wydajności i cech aplikacji. Oprócz zrozumienia użycia narzędzi należy najpierw zrozumieć analizowane aplikacje. Zacznij od znalezienia odpowiedzi na pytania, takie jak to, co aplikacja próbuje osiągnąć? Które wątki w systemie są najważniejsze? Jakie kompromisy są gotowe? Podczas analizowania śladów wydajności zacznij od przyjrzenia się oczywistym problematycznym miejscom. Czy aplikacja jest ograniczona przez CPU czy GPU? Czy aplikacja może prezentować każdą ramkę? Narzędzia wraz ze zrozumieniem aplikacji mogą dawać bardzo przydatne informacje w zrozumieniu, znajdowaniu i rozwiązywaniu problemów z wydajnością.