Udostępnij przez


Wparcie dla WDDM w zakresie wykrywania i odzyskiwania po przekroczeniu limitu czasu

W tym artykule opisano, jak model sterownika wyświetlania systemu Windows (WDDM) obsługuje wykrywanie przekroczenia limitu czasu i odzyskiwanie (TDR). Zawiera omówienie procesu TDR, objaśnia, jak działa wykrywanie przekroczenia limitu czasu w WDDM, oraz opisuje kroki podejmowane w celu odzyskiwania po przekroczeniu limitu czasu.

Odbiorcami tego artykułu są deweloperzy sterowników wyświetlania i grafiki.

Aby uzyskać więcej informacji na temat TDR w WDDM, zobacz następujące artykuły:

Przegląd

TDR to funkcja w systemie Windows, która wykrywa, kiedy karta graficzna trwa dłużej niż oczekiwano, aby ukończyć operację. Następnie resetuje kartę graficzną, aby zapobiec utracie odpowiedzi całego systemu.

Jednym z najczęstszych problemów ze stabilnością grafiki występuje, gdy komputer wydaje się "zawieszać się" lub być całkowicie "zamrożony", podczas gdy w rzeczywistości przetwarza polecenie lub operację użytkownika końcowego. Wielu użytkowników czeka kilka sekund, a następnie podejmuje decyzję o ponownym uruchomieniu komputera. Zamrożony wygląd komputera często występuje, ponieważ procesor GPU jest zajęty przetwarzaniem intensywnych operacji graficznych, zwykle podczas gry, a tym samym nie aktualizuje ekranu ekranu. TDRs umożliwiają systemowi operacyjnemu wykrywanie, że interfejs użytkownika nie odpowiada.

Na poniższej ilustracji przedstawiono proces TDR.

Diagram przedstawiający proces wykrywania przekroczenia limitu czasu i odzyskiwania (TDR) układów GPU w ramach WDDM.

System operacyjny próbuje wykryć sytuacje, w których komputery wydają się być "zamrożone". System operacyjny próbuje następnie dynamicznie odzyskać sprawność po zamrożonych sytuacjach, tak aby komputery stacjonarne odpowiadały ponownie, co złagodziło sytuację, w której użytkownicy końcowi niepotrzebnie ponownie uruchamiają swoje systemy.

Domyślnie system operacyjny wywołuje sprawdzenie błędów komputera po szóstym (lub więcej) zawieszeniu GPU, gdy wykryje, że pięć (5) lub więcej zawieszeń GPU (0x117) i kolejne próby odzyskiwania występują w ciągu jednej (1) minuty. Aby uzyskać więcej informacji, zobacz TdrLimitCount i TdrLimitTime.

Na marginesie, limity czasu silnika (0x141) nie przyczyniają się do liczby zawieszeń GPU, choć system operacyjny może przekształcić limit czasu silnika do zawieszenia GPU, jeśli limit czasu okaże się nieskuteczny. W przypadku limitów czasu aparatu (0x141) maksymalna liczba jest o jeden mniejsza niż dla limitów czasu adaptera (0x117). Proces resetowania silnika blokuje dostęp do GPU dla procesu, który powoduje takie przekroczenia limitu czasu, a dzienniki systemowe 0x142 wskazują na ten fakt. W ten sposób proces awarii nie sprawdza błędów systemu.

Wykrywanie limitu czasu w programie WDDM

Harmonogram procesora GPU, który jest częścią podsystemu jądra grafiki DirectX (Dxgkrnl.sys), wykrywa, kiedy procesor GPU zajmuje więcej niż dozwolony czas wykonywania określonego zadania. Następnie harmonogram GPU próbuje przerwać to konkretne zadanie. Operacja wywłaszczenia ma limit czasu "wait", czyli rzeczywisty limit czasu TDR. Domyślny limit czasu w systemie Windows to dwie sekundy. Jeśli procesor GPU nie może ukończyć lub przerwać bieżącego zadania w okresie limitu czasu TDR, system operacyjny diagnozuje, że procesor GPU jest zamrożony.

Aby zapobiec wykryciu przekroczenia limitu czasu, dostawcy sprzętu powinni upewnić się, że operacje graficzne (czyli ukończenie buforu DMA) zajmują nie więcej niż dwie sekundy w scenariuszach użytkowania przez użytkownika końcowego, takich jak produktywność i gry komputerowe.

Przygotowanie do odzyskiwania

Harmonogram procesora GPU wywołuje funkcję DxgkDdiResetFromTimeout sterownika miniportu, aby poinformować sterownik, że system operacyjny wykrył przekroczenie limitu czasu. Sterownik musi następnie ponownie zainicjować się i zresetować GPU. Ponadto sterownik musi zatrzymać dostęp do pamięci i nie powinien uzyskiwać dostępu do sprzętu. System operacyjny i sterownik zbierają informacje o sprzęcie i innych stanach, które mogą być przydatne podczas diagnostyki po odzyskiwaniu.

Aby uzyskać więcej informacji, zobacz TDR w systemie Windows 8 lub nowszym.

Odzyskiwanie pulpitu

System operacyjny resetuje odpowiedni stan stosu grafiki. Menedżer pamięci wideo, który jest również częścią Dxgkrnl.sys, czyści wszystkie alokacje z pamięci wideo. Sterownik miniportu wyświetlacza resetuje stan sprzętu procesora GPU. Stos graficzny wykonuje końcowe czynności i przywraca pulpit do stanu reaktywnego i funkcjonalnego.

Jedynym widocznym artefaktem wykrywania i odzyskiwania z zawieszenia jest migotanie ekranu. Migotanie to występuje, gdy system operacyjny resetuje niektóre części stosu graficznego, co powoduje ponowne rysowanie ekranu. Sterownik miniportu wyświetlacza może wyeliminować to ponowne rysowanie, gdy jest zgodny z programem WDDM 1.2 lub nowszym (zobacz Zapewnianie bezproblemowych przejść stanu w programie WDDM 1.2 lub nowszym).

Po pomyślnym odzyskaniu pulpitu przez system operacyjny wykonuje następujące akcje:

  • Wyświetla komunikat informacyjny dla użytkownika końcowego: "Sterownik wyświetlania przestał odpowiadać i został przywrócony".
  • Rejestruje powyższy komunikat w aplikacji Podgląd zdarzeń i zbiera informacje diagnostyczne w postaci raportu debugowania. Jeśli użytkownik końcowy wyrazi zgodę na przekazywanie opinii, system operacyjny zwraca ten raport debugowania do firmy Microsoft za pośrednictwem mechanizmu analizy awarii online (OCA).

Niektóre starsze aplikacje DirectX mogą wyświetlać tylko czarne tło na końcu tego procesu odzyskiwania, co wymusza od użytkownika końcowego ponowne uruchomienie tych aplikacji. Dobrze napisane aplikacje DirectX 9Ex i DirectX 10 i nowsze, które obsługują technologię Device Remove, nadal działają poprawnie. Aplikacja musi zwolnić, a następnie ponownie utworzyć swoje urządzenie Direct3D firmy Microsoft i wszystkie obiekty tego urządzenia.

Synchronizacja wątków i TDR

Aby uzyskać szczegółowe informacje, zobacz Synchronizacja wątków i TDR .

Testowanie i debugowanie TDR

Aby uzyskać więcej informacji, zobacz Testowanie i debugowanie TDR.