Поделиться через


Обнаружение и восстановление времени ожидания (TDR)

В этой статье описывается обнаружение времени ожидания и восстановление (TDR) для разработчиков драйверов. Дополнительные сведения см. в разделе TDR в Windows 8 и более поздних версий.

Общие сведения

Одна из наиболее распространенных проблем стабильности в графике возникает, когда компьютер кажется "зависшим" или полностью "заморожен", когда он фактически обрабатывает команду или операцию конечного пользователя. Многие пользователи подождите несколько секунд, а затем решили перезагрузить компьютер. Зависший внешний вид компьютера часто возникает из-за того, что GPU занят обработкой интенсивных графических операций, обычно во время игры, и поэтому не обновляет экран дисплея. TDR позволяют операционной системе обнаруживать, что пользовательский интерфейс не отвечает.

На следующем рисунке показан процесс TDR.

Схема, показывающая процесс обнаружения и восстановления времени ожидания (TDR) gpu через WDDM.

ОПЕРАЦИОННая система пытается обнаружить ситуации, в которых компьютеры кажутся "замороженными". Затем ОС пытается динамически восстанавливаться после замороженных ситуаций, чтобы рабочие столы снова реагировали, устранимая ситуацию, когда конечные пользователи без необходимости перезагружают свои системы.

По умолчанию, если ОС обнаруживает, что пять (5) или более GPU зависает (0x117) и последующие операции восстановления происходят в течение одной (1) минуты, операционная система проверяет, что компьютер на следующем (шестом или более) GPU зависает. Дополнительные сведения см. в разделах TdrLimitCount и TdrLimitTime.

Обратите внимание, что время ожидания двигателя (0x141) не влияет на количество зависаний GPU, хотя ОС может повысить время ожидания двигателя до зависания GPU, если время ожидания двигателя не выполнено. Для тайм-аутов подсистемы (0x141) максимальное число меньше времени ожидания адаптера (0x117). Процесс сброса подсистемы блокирует доступ gpu для процесса, который вызывает такие превышения времени ожидания, и системные журналы 0x142 , чтобы указать на этот факт. Таким образом, неисправный процесс не проверка системе.

Обнаружение времени ожидания в WDDM

Планировщик GPU, который является частью подсистемы ядра графики DirectX (Dxgkrnl.sys), обнаруживает, что GPU занимает больше разрешенного времени для выполнения определенной задачи. Затем планировщик GPU пытается вытеснять эту конкретную задачу. Операция preempt имеет время ожидания, которое является фактическим тайм-аутом TDR. Время ожидания по умолчанию в Операционных системах Windows Vista и более поздних версий составляет 2 секунды. Если GPU не может завершить или вытеснять текущую задачу в течение времени ожидания TDR, операционная система диагностирует, что GPU заморожен.

Чтобы предотвратить обнаружение времени ожидания, поставщики оборудования должны убедиться, что графические операции (т. е. завершение буфера DMA) занимают не более 2 секунд в сценариях конечных пользователей, таких как производительность и игры.

Подготовка к восстановлению

Планировщик GPU вызывает функцию DxgkDdiResetFromTimeout драйвера мини-порта дисплея, чтобы сообщить драйверу о том, что ОС обнаружила время ожидания. Затем драйвер должен повторно инициализировать себя и сбросить GPU. Кроме того, драйвер должен прекратить доступ к памяти и не должен обращаться к оборудованию. Ос и драйвер собирают сведения об оборудовании и других состояниях, которые могут быть полезны для диагностики после восстановления.

Дополнительные сведения см. в разделе TDR в Windows 8 и более поздних версий.

Восстановление рабочего стола

ОС сбрасывает соответствующее состояние графического стека. Диспетчер видеопамять, который также является частью Dxgkrnl.sys, очищает все выделения из видеопамять. Драйвер мини-порта дисплея сбрасывает состояние оборудования GPU. Графический стек выполняет окончательные действия и восстанавливает рабочий стол в адаптивном состоянии.

Единственным видимым артефактом от обнаружения зависания до восстановления является мерцание экрана. Это мерцание возникает, когда ОС сбрасывает некоторые части графического стека, что приводит к перерисовке экрана. Драйвер мини-порта дисплея может устранить эту перерисовку, если он соответствует WDDM 1.2 и более поздних версий (см. раздел Обеспечение простого перехода состояния в WDDM 1.2 и более поздних версий).

После успешного восстановления рабочего стола ОС выполняет следующие действия:

  • Отображает информационное сообщение для конечного пользователя с сообщением "Драйвер дисплея перестал отвечать и восстановлен".
  • Регистрирует предыдущее сообщение в приложении Просмотр событий и собирает диагностические сведения в виде отчета об отладке. Если пользователь согласился на отправку отзывов, ОПЕРАЦИОННая система возвращает этот отчет об отладке в корпорацию Майкрософт с помощью механизма анализа сбоев в сети (OCA).

Некоторые устаревшие приложения DirectX могут просто отображаться черным цветом в конце этого восстановления, что требует от пользователя перезапуска этих приложений. Хорошо написанные приложения DirectX 9Ex и DirectX 10 и более поздних версий, которые обрабатывают технологию удаления устройств, продолжают работать правильно. Приложение должно освободить, а затем повторно создать устройство Microsoft Direct3D и все его объекты.

Синхронизация потоков и TDR

Дополнительные сведения см. в разделе Синхронизация потоков и TDR .

Тестирование и отладка TDR

Дополнительные сведения см. в разделе Тестирование и отладка TDR .