🛠️ TDR Debugging – Zaawansowany przewodnik ekspercki
1. Czym jest TDR?
TDR (Timeout Detection and Recovery) to mechanizm wprowadzony w Windows Vista i rozwijany dalej w WDDM, który wykrywa, gdy GPU lub sterownik graficzny przestaje odpowiadać (zwykle po 2 s), resetuje sterownik i odzyskuje responsywność systemu bez konieczności restartu komputera.
Proces:
- GPU od wykonania zadania przekroczy limit czasu (domyślnie 2 s).
- Dxgkrnl sys próbuje preemption, po czym resets GPU – informuje miniport driver (
DxgkDdiResetFromTimeout). - Desktop jest przywracany; widoczna jest jedynie chwilowa migawka ekranu.
Domyślnie po pięciu TDR w ciągu jednej minuty system wykonuje BSOD, by zapobiec niestabilności .
2. Rejestry i debugging (dla twórców sterowników)
Kluczowe klucze rejestru :
- TdrDelay – czas oczekiwania GPU (sekundy, domyślnie 2 s).
- TdrDdiDelay – czas, przez jaki procesy mogą się znajdować w sterowniku przed bugcheckiem (domyślnie 5 s).
- TdrLevel – poziom reakcji (Off, Bugcheck, RecoverVGA, Recover).
Zmiana tych wartości (np. TdrDelay = 60 s) umożliwia testowanie długich operacji GPU bez resetu.
WHLK i debugowanie :
Windows Hardware Lab Kit oferuje testy symulacji GPU TDR, np. SimulatePreemption, co pozwala sprawdzić poprawność obsługi resetu przez sterownik.

3. Techniczne podłoże WDDM
- WDDM 1.2+ wspiera bardziej granularne preemption i szybszy TDR.
DxgkDdiResetFromTimeoutto metoda KMD, która powinna zregenerować GPU bez pozostawiania niekompatybilnego stanu.- Należy wyłączyć optymalizację FPO, by umożliwić dokładny backtrace i diagnostykę.
- TDR można także tymczasowo wyłączyć w debugerach GPU (NVIDIA Nsight – np. opóźnić do 10 s, lub całkowicie wyłączyć przy pracy wielogpu/remotely) .
4. Praktyczne techniki debugowania
A) Lokalny debug:
- Podnieś TdrDelay do min. 10 s lub wyłącz TDR w narzędziach typu Nsight.
- Debuguj intensywne kernely GPU bez przerywania.
B) Śledzenie w ETW/GPUView:
- Włącz logowanie UMD i UTW (Event Tracing), użyj GPUView do analizy ścieżek GPU-CPU.
- Obserwuj czasy preemption i resetów.
C) Testy stresowe:
- Użyj WHLK testów TDR, albo własnych kernel loopów, by symulować długie zadania.
- Zmodyfikuj TdrDelay i TdrDdiDelay podczas testów.
D) Środowiska domowe:
- Ręczna zmiana rejestru:
regedit → HKLM\System\CurrentControlSet\Control\GraphicsDrivers TdrDelay (DWORD, 10-60) TdrDdiDelay (DWORD, 10-60) reboot.
5. Najczęstsze problemy i rozwiązania
- Długie kernely powodują TDR – dziel zadanie na mniejsze (10 ms lub mniej), co pozwala uniknąć watchdoga.
- Stabilność sterownika – Błędy w
ResetFromTimeoutmogą spowodować niestabilność; wymagane kompletnie przetestowane ścieżki resetu. - Optymalizacje FPO – wyłącz dla sterowników WDDM ≥ 1.2, by uzyskać dokładny backtrace.
- Nowe GPU i zaktualizowane sterowniki – mogą zmienić domyślne wartości rejestru, więc warto je sprawdzać po update’ach .
6. Praktyczne zalecenia
Dla programistów sterowników:
- Implementuj wywołania
DxgkDdiResetFromTimeout, kompleksowe czyszczenie stanu i informowanie diagnostycznych logów. - Testuj w różnych scenariuszach: długie zadania, presja pamięci, współbieżność.
Dla deweloperów GPU(kernel):
- Dziel obciążenie na mniejsze fragmenty (<2 s, idealnie ~10 ms).
- Upewnij się, że ścieżka renderingu regularnie wykonuje Present lub Flush.
Dla użytkowników / inżynierów QA:
- Wydłuż TdrDelay podczas testów dużych scen lub długotrwałych renderów (np. Substance Painter, D5 Render).
- Monitoruj błędy «Display driver stopped responding and has recovered» w EventViewer.
7. Podsumowanie
TDR zapewnia stabilność systemu, ale może przeszkadzać w długich zadaniach GPU. Debugging TDR obejmuje:
- Wydłużenie
TdrDelay,TdrDdiDelay, - Wyłączenie optymalizacji FPO,
- Korzystanie z narzędzi debugowania (WHLK, Nsight, GPUView),
- Rozbicie ciężkich zadań na mniejsze fragmenty.
Dla twórców sterowników i deweloperów GPU to kluczowe: zapewnienie niezawodnej reakcji systemu, utrzymanie responsywności, jednocześnie umożliwiając wykonywanie wymagających obliczeń bez resetu sprzętu.






