Diagnostyka grafiki — Przegląd

Diagnostyka grafiki pomaga debugować błędy renderowania w grach i aplikacjach DirectX.

Visual Studio 2013 wymagania

Aby skorzystać z diagnostyki grafiki w Visual Studio 2013, użytkownik musi mieć jeden z tych wersji:

• Visual Studio 2013 Ultimate

• Visual Studio 2013 Premium

• Visual Studio 2013 Professional

• Visual Studio 2013 Express dla systemu Windows

[!UWAGA]

Visual Studio 2013 Express do pulpitu systemu Windows nie obsługuje funkcji Diagnostyka grafiki.

Wymagania systemu operacyjnego i zestawu SDK

Windows Software Development Kit (SDK) Dla Windows 8,1 instaluje składniki wykonawcze, wymagane przez diagnostyki grafiki, a nie obsługuje tworzenia aplikacji dla Windows 8,1 i Windows 8.Do korzystania z diagnostyki grafiki w Windows 7 i Windows Vista, należy zainstalować jedną z następujących zestawy SDK:

• Windows SDK (w wersji 7.1)

• Zestaw SDK programu DirectX (czerwiec 2010)

Zgodność wersji programu DirectX

Program Graphics Diagnostics obsługuje aplikacje, które używają programów Direct3D 10, Direct3D 10.1, Direct3D 11, Direct3D 11.1 i Direct3D 11.2, i zapewnia ograniczoną obsługę aplikacji, które używają Direct2D.Nie obsługuje aplikacji, które używają starszych wersji Direct3D, DirectDraw lub innych graficznych interfejsów API.

Windows 8.1 i Direct3D 11.2

W Windows 8,1, DirectX 11.2 wprowadzono nowe funkcje, które obsługują przechwytywanie informacji grafiki za pośrednictwem jego czasu wykonywania.Windows 8,1 używa nowego środowiska wykonawczego na podstawie przechwytywania — znane jako niezawodne Przechwytywanie— wyłącznie dla wszystkich wersji programu DirectX który Windows 8,1 obsługuje.Niezawodne Przechwytywanie obsługuje także nowe funkcje Direct3D 11.2.

Obsługa systemu Windows 8 i Windows 7

Ponieważ poprzednich wersjach systemu Windows nie obsługuje technologii DirectX 11.2, niezawodne Przechwytywanie jest niedostępna na tych platformach.Zamiast tego, aplikacji uruchomionych na Windows 8 lub Windows 7 należy użyć metody poprzedniego, na podstawie funkcji przechwytywania znane jako starszego przechwytywania.Ponieważ nie istnieje potrzeba do jego obsługi na Windows 8,1, starszego przechwytywania jest przestarzały, jednak jest nadal dostępna do obsługi aplikacji uruchomionych na Windows 8 lub Windows 7.

Ograniczona obsługa Direct2D

Ponieważ Direct2D to API trybu użytkownika, który jest zbudowany na bazie Direct3D, możesz skorzystać z Graphics Diagnostics, aby debugować problemy z renderowaniem w aplikacjach, które używają Direct2D.Jednak ponieważ rejestrowane są tylko podstawowe zdarzenia Direct3D, a nie zdarzenia Direct2D wyższego poziomu, zdarzenia Direct2D nie pojawią się na liście zdarzeń grafiki.Ponadto, ponieważ relacja między zdarzeniami Direct2D i wynikowymi zdarzeniami Direct3D nie jest zawsze jasna, używanie Graphics Diagnostics do debugowania problemów z renderowaniem w aplikacjach, które używają Direct2D, nie jest proste.Nadal można korzystać z Graphics Diagnostics, aby uzyskać informacje dotyczące problemów renderowania niskiego poziomu w aplikacjach, które korzystają z Direct2D.

Interfejs użytkownika zmiany w programie Visual Studio 2013 z aktualizacją 3

Od wersji programu Visual Studio 2013 Update 3, diagnostyki grafiki narzędzia windows znajdują się w niezależne kopię powłoki programu Visual Studio do ograniczenia liczby narzędzia windows konkurencyjnych ograniczone miejsce w głównym IDE programu Visual Studio.Dostosowana powłoka tego teraz obsługuje narzędzia diagnostyki grafiki, o nazwie programu Visual Studio grafiki analizy, eliminuje menu i opcje, które nie są wymagane przez diagnostyki grafiki, ale w przeciwnym razie narzędzia diagnostyczne grafiki i przepływy pracy są podobne do diagnostyki grafiki w poprzednich wersjach programu Visual Studio.

Istnieją dwie istotne różnice:

1. Po uruchomieniu aplikacji w diagnostykę grafiki Visual Studio nie jest już wyświetlany live wersji dokumentu dziennika grafiki.Zamiast tego Visual Studio udostępnia nowy interfejs przechwytywania.Oto, jak wygląda nowy interfejs przechwytywania:

   

   W tym interfejsie przechwytywania jednego lub wielu ramek w dzienniku grafiki i wyświetlić w czasie rzeczywistym wykresy, wyświetlających szybkość odtwarzania aplikacji, a także czas (w milisekundach), która przyjmuje każdej ramki do renderowania.

2. Nie można edytować kod w powłoce analizy grafiki; Po otwarciu kodu do edycji w analizy grafiki, zostanie otwarty w głównym IDE programu Visual Studio i fokus.

Ten interfejs jest widoczna w programie Visual Studio.Do uruchomienia programu Visual Studio grafiki analizy, wybierz jedną z ramek, wykonując następujące ramki... łącze powyżej Miniatura obrazu lub dwukrotnie miniatura.

Używanie Graphics Diagnostics do debugowania problemów z renderowaniem

Debugowanie problemów z renderowaniem w aplikacji rozbudowanej graficznie nie jest tak proste, jak uruchomienie debugera i krokowe wykonywanie kodu.W każdej klatce są produkowane setki tysięcy unikatowych pikseli, każdy na podstawie złożonego zestawu stanu, danych, parametrów i kodu — możliwe, że tylko kilka z powyższych pikseli pokaże problem, który próbujesz zdiagnozować.Aby jeszcze bardziej skomplikować sprawy, kod, który generuje każdy piksel, jest wykonywany na wyspecjalizowanym sprzęcie, który przetwarza setki pikseli równolegle.Tradycyjne narzędzia i techniki debugowania, z których trudno się korzysta nawet w kodzie mało skomplikowanym pod względem wątków, są nieskuteczne w obliczu tak dużej ilości danych.

Narzędzia diagnostyki grafiki w Visual Studio są zaprojektowane, aby pomóc Zlokalizuj problemy z renderowaniem uruchamiając z visual artefaktów, które wskazują na problem, a następnie Śledzenie wstecz ze źródłem problemu tylko dotyczące kodu odpowiednich cieniowania, potoku etapy, rysowania wywołań, zasoby i stan urządzenia — w kodzie źródłowym w aplikacji.

Poniżej podano niektóre rodzaje renderowania problemów, które Visual Studio może pomóc w rozwiązaniu.

• Stan urządzenia
  Poprawna konfiguracja urządzenia grafiki jest ważna, ponieważ określa, jak potok graficzny interpretuje dane skojarzone z każdym wywołaniem rysowania i jak dane wyjściowe wywołania rysowania są scalane.Na przykład, jeśli stan urządzenia określa kolejność zakręcania wierzchołków zgodnie z ruchem wskazówek zegara, każdy model, który określa wierzchołki w kolejności przeciwnej do ruchu wskazówek zegara, nie będzie wyświetlany poprawnie.Problemy z stanem urządzenia mogą być trudne do zdiagnozowania, ponieważ źródło problemu w kodzie źródłowym jest często oddalone od obiektów dotkniętych wadami.Za pomocą Graphics Diagnostics możesz wyświetlić bieżący stan urządzenia w dowolnym momencie podczas renderowania.

• Niezainicjowane lub nieprawidłowe stałe bufory i parametry
  Aplikacje grafiki używają stałych buforów i parametrów, aby przekazać dodatkowe dane do wywołania rysowania lub zestawu wywołań rysowania.Na przykład, dane mogą określać różne lokalizacje lub wystąpienia dla różnych obiektów.Gdy te dane nie zostaną zainicjowane lub będą zawierały niepoprawne wartości, odpowiedni obiekt będzie renderowany niepoprawnie, a być może w ogóle nie będzie.Problem tego rodzaju może być trudny do zdiagnozowania, ponieważ nie zawsze jest jasne, czy problem jest w danych, czy w kodzie modułu cieniującego, który ich używa.Może też być trudno określić, które moduły cieniujące, stałe bufory i parametry odpowiadają błędowi.Graphics Diagnostics umożliwia określenie, które moduły cieniujące, stałe bufory i parametry stosuje się do każdego wywołania rysowania, i obejrzenie ich zawartości.

• Błędu modułu cieniującego
  Pomyłki w kodzie aplikacji są prawie nieuniknione, niezależnie od tego, czy kod jest w języku C++, czy High Level Shader Language (HLSL).Jednakże debugowanie kodu języka HLSL tradycyjnie było i jest trudniejsze, ponieważ nie może korzystać z zaawansowanych funkcji debugowania, z których korzysta C++ i inne języki.Graphics Diagnostics udostępnia w HLSL tradycyjne narzędzia debugowania kodu, aby krokowo śledzić wykonywanie kodu, ustawiać punkty przerwania i sprawdzać zawartość zmiennych, parametrów i stałych buforów.

Jak działa Graphics Diagnostics

Aby skorzystać z Graphics Diagnostics, najpierw rejestruje się informacje o tym, w jaki sposób aplikacja używa interfejsu API Direct3D w trakcie działania, a następnie bada się zarejestrowane zachowanie.Dla określonych klatek, rejestrowane informacje obejmują wywołania interfejsu API — takie jak te, które czyszczą ekran, rysują geometrię, wysyłają obliczające moduły cieniowania lub zmieniają stan urządzenia grafiki — wraz z ich argumentami i kopiami buforów oraz obiektów, które są określane w sposób pośredni.Dodatkowo, wywołania API związane z konfiguracją i inicjowaniem są rejestrowane, zanim zostanie zrenderowana jakaś ramka.Informacje, które jest rejestrowany jest zapisywana w grafiki dziennika pliku (.vsglog).

Zachowanie renderowania, zarejestrowane w dzienniku grafiki, powtarza się przez odtworzenie zdarzenia grafiki na komputerze deweloperskim lub na zdalnym komputerze lub urządzeniu.Urządzeniem odtwarzania może być ten sam komputer lub urządzenie, gdzie pierwotnie zarejestrowano dziennik grafiki, lub inne.W przypadku większości funkcji odtwarzania, sprzęt graficzny maszyny odtwarzania jest używany do odtwarzania zdarzenia grafiki, ale gdy używa się debugera HLSL, kod modułu cieniującego jest zawsze odtwarzany za pomocą emulacji GPU wykonywanej przez CPU.Emulacja GPU umożliwia krokowe przechodzenie przez kod modułu cieniującego, sprawdzanie zmiennych i używanie innych typowych funkcji debugowania, bez względu na to, czy sprzęt graficzny w maszynie odtwarzania obsługuje debugowanie sprzętu.

[!UWAGA]

Mimo że dziennik grafiki przechwytuje większość istotnych informacji wewnętrznie, aby w pełni wykorzystać funkcje programu Graphics Diagnostics, wymagane są dodatkowe informacje.Na przykład, aby w pełni wykorzystywać funkcję stosu wywołań grafiki, musisz również mieć plik bazy danych programu (.pdb) i kod źródłowy aplikacji.Aby zdebugować kod źródłowy modułu cieniującego HLSL, musisz też mieć kod źródłowy modułu cieniującego.(Jeśli moduł cieniujący został skompilowany za pomocą kompilatora modułu cieniującego D3D11.1, a informacje debugowania są włączone, to kod źródłowy modułu cieniującego jest osadzony w dzienniku grafiki podczas przechwytywania.)

[!UWAGA]

Ponieważ niektóre interfejsy API nie mogą być dostępne w poprzednich wersjach systemu Windows lub DirectX, nie odtwarzania dzienników grafiki, które przechwycone te wywołania interfejsu API na komputerze odtwarzanie, który nie obsługuje je.

Dzienniki grafiki

Dziennik grafiki zawiera jedną lub więcej klatek, które zostały przechwycone z działającej aplikacji graficznej DirectX.Ponieważ dziennik grafiki jest niezależny, te klatki można później odtworzyć bez zewnętrznych informacji lub odwołań.Oznacza to, że można współdzielić dzienniki grafiki z innymi deweloperami, badać problemy na różnych komputerach i badać stare dzienniki grafiki, nawet wtedy, gdy w trakcie prac programistycznych zmieniono modele i tekstury.Można też jednocześnie załadować wiele plików dziennika grafiki (.vsglog), aby porównać dane i wyniki renderowania.

Aby otworzyć plik dziennika grafiki (vsglog)

1. W Visual Studio, paska menu, wybierz polecenie pliku, Otwórz, pliku.Pojawi się okno dialogowe Otwórz plik.

2. Określ plik dziennika (.vsglog) grafiki, a następnie wybierz Otwórz przycisku.

[!UWAGA]

Wyodrębnij, modyfikowania i Zapisz kopię siatki i tekstury z dziennika grafiki przy użyciu narzędzia graficzne, które są częścią Visual Studio.Te modyfikacje nie wpływają jednak na zawartość dziennika grafiki.Informacje te narzędzia grafiki, zobacz Praca z obiektami 3-D do gier i aplikacji.

Pasek narzędzi Grafika

Pasek narzędzi Grafika zapewnia szybki dostęp do poleceń Graphics Diagnostics i okien narzędzi.

Rozpocznij diagnostykę przycisk uruchamia aplikację w obszarze grafiki diagnostyki.Gdy aplikacja jest uruchomiona w ramach diagnostyki grafiki Przechwytywanie następnej ramki renderowanych przycisk jest włączony i innych przycisków służy do wyświetlenia innego narzędzia systemu windows.Aby uzyskać więcej informacji na temat uruchamiania aplikacji w diagnostyki grafiki i przechwytywanie informacji grafiki, zobacz Przechwytywanie informacji graficznych.

Okna narzędzi programu Graphics Diagnostics

Poniższa ilustracja przedstawia typowy układ okien narzędzi służących do inspekcji i debugowania przechwyconych klatek.Każde okno udostępnia inną kategorię informacji o przechwyconej klatce, która jest poddawana inspekcji, a nawet dla poszczególnych pikseli w klatce.

• Użyj Dokument dziennika grafiki okno, aby zidentyfikować problemy z renderowaniem, które są Państwo zainteresowani.

• Użyj Lista zdarzeń grafiki do identyfikacji zdarzenia, które są powiązane z problem renderowania.

• Użyj Etapy potoku grafiki okno do identyfikowania etap potoku, gdzie najpierw występuje problem z renderowaniem.

• Użyj Stos wywołań zdarzeń grafiki do zlokalizowania kodu aplikacji, który jest powiązany z problem renderowania.

• Użyj Historia pikseli grafiki Aby sprawdzić szczegóły zdarzenia, które wpływa na końcowym koloru piksela.

• Użyj Tabela obiektów graficznych umożliwia wyświetlenie szczegółów obiektów, które są powiązane z problem renderowania.

Panel sterowania DirectX

Panel sterowania DirectX to składnik DirectX, którego można użyć, aby zmienić sposób zachowania DirectX — na przykład włączyć wersję składników wykonawczych DirectX przeznaczoną do debugowania, wybrać rodzaj komunikatów debugowania, które są raportowane, oraz uniemożliwić korzystanie z niektórych funkcji sprzętowych karty graficznej w celu emulacji mniej zaawansowanego sprzętu.Ten poziom kontroli nad DirectX może pomóc w debugowaniu i testowaniu aplikacji DirectX.Dostęp do panelu sterowania DirectX można uzyskać z Visual Studio.

Aby otworzyć panel sterowania DirectX

• Na pasku menu wybierz polecenie Debugowanie, grafiki, Panelu sterowania DirectX.

Zobacz też

Koncepcje

Debuger HLSL