Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье описывается, как Модель драйвера отображения для Windows (WDDM) поддерживает обнаружение тайм-аута и устранение (TDR). В ней представлен обзор процесса TDR, объясняется, как работает обнаружение времени ожидания в WDDM и описывает шаги, которые необходимо выполнить для восстановления после ожидания.
Аудитория этой статьи — разработчики драйверов отображения и графики.
Дополнительные сведения о TDR в WDDM см. в следующих статьях:
- Изменения TDR в Windows 8 и более поздних версиях
- Синхронизация потоков и TDR
- Тестирование и отладка TDR
Обзор
TDR — это функция в Windows, которая обнаруживает, когда графические карты занимают больше времени, чем ожидалось, чтобы завершить операцию. Затем он сбрасывает графическую карту, чтобы предотвратить зависание всей системы.
Одна из наиболее распространенных проблем стабильности в графике возникает, когда компьютер, как представляется, зависает или полностью зависает, когда он фактически обрабатывает команду или операцию конечного пользователя. Многие пользователи ждут несколько секунд, а затем решают перезагрузить компьютер. Замороженный внешний вид компьютера часто возникает, так как GPU занят обработкой интенсивных графических операций, как правило, во время игры, и поэтому не обновляет экран отображения. Средства TDR позволяют операционной системе обнаруживать, что пользовательский интерфейс не отвечает.
На следующем рисунке показан процесс TDR.
ОС пытается обнаружить ситуации, в которых компьютеры, как представляется, "заморожены". Затем операционная система пытается динамически восстановиться после зависания, чтобы рабочие столы снова стали отзывчивыми, избегая ситуации, в которой конечные пользователи без необходимости перезагружают свои системы.
По умолчанию ОС выполняет проверку ошибок компьютера на шестом (или более) возникновении проблем с зависаниями GPU, когда обнаруживает, что пять (5) или более зависаний GPU (0x117) и последующее восстановление системы происходят в течение одной минуты. Дополнительные сведения см. в разделе TdrLimitCount и TdrLimitTime.
Следует отметить, что время ожидания процессорного двигателя (0x141) не способствует увеличению количества зависаний GPU, хотя ОС может повысить его до зависания GPU, если оно не будет успешно. Максимальное количество для таймаутов двигателя (0x141) на единицу меньше, чем для таймаутов адаптера (0x117). Процесс сброса механизма блокирует доступ к GPU для процесса, вызывающего такие тайм-ауты, и факт этого регистрируется в системных журналах с кодом 0x142. Таким образом, неисправный процесс не инициирует проверку на наличие ошибок в системе.
Обнаружение времени ожидания в WDDM
Планировщик GPU, являющийся частью подсистемы ядра графики DirectX (Dxgkrnl.sys), обнаруживает, что GPU занимает больше допустимого времени для выполнения определенной задачи. Затем планировщик GPU пытается вытеснить эту конкретную задачу. Операция предварительного ожидания имеет время ожидания, которое является фактическим временем ожидания TDR. Период времени ожидания по умолчанию в Windows Vista и более поздних операционных системах составляет 2 секунды. Если GPU не может завершить или прекратить текущую задачу в течение периода ожидания TDR, ОС диагностирует, что GPU заморожен.
Чтобы предотвратить обнаружение времени ожидания, поставщики оборудования должны гарантировать, что графические операции (т. е. завершение буфера DMA) занимают не более 2 секунд в сценариях конечных пользователей, таких как производительность и игра в игру.
Подготовка к восстановлению
Планировщик GPU вызывает функцию DxgkDdiResetFromTimeout драйвера минипорта дисплея, чтобы сообщить драйверу, что ОС обнаружила превышение тайм-аута. Затем драйвер должен заново инициализировать себя и перезагрузить графический процессор. Кроме того, драйвер должен прекратить доступ к памяти и не должен получать доступ к оборудованию. ОС и драйвер собирают аппаратные и другие сведения о состоянии, которые могут быть полезны для диагностики после восстановления.
Дополнительные сведения см. в статье TDR в Windows 8 и более поздних версиях.
Восстановление рабочего стола
ОС сбрасывает соответствующее состояние графической подсистемы. Диспетчер видеопамяти, который также является частью Dxgkrnl.sys, очищает все выделенные ресурсы из видеопамяти. Драйвер мини-порта дисплея сбрасывает состояние оборудования GPU. Стек графики выполняет окончательные действия и восстанавливает рабочий стол в ответное состояние.
Единственным видимым артефактом от обнаружения зависания до восстановления является мерцание экрана. Мерцание возникает, когда ОС сбрасывает часть графического стека, вызывая перерисовку экрана. Минипорт драйвера дисплея может устранить эту перерисовку при соответствии требованиям WDDM 1.2 и более поздних версий (см. раздел "Обеспечение плавного перехода состояния в WDDM 1.2 и более поздних версиях").
После успешного восстановления операционной системы рабочий стол выполняет следующие действия:
- Отображает информационное сообщение для конечного пользователя, сказав: "Драйвер отображения перестал отвечать и восстановлен".
- Записывает предыдущее сообщение в приложение средства просмотра событий и собирает сведения о диагностике в виде отчета отладки. Если конечный пользователь согласился предоставить отзыв, ОС возвращает этот отчет об отладке в Microsoft через механизм Онлайн-анализа аварийных сбоев (OCA).
Некоторые устаревшие приложения DirectX могут просто отображать черный цвет в конце этого восстановления, что требует перезапуска этих приложений конечным пользователем. Хорошо написанные приложения DirectX 9Ex и DirectX 10 и более поздних версий, которые обрабатывают технологию удаления устройств, продолжают работать правильно. Приложение должно освободить и повторно создать свое устройство Microsoft Direct3D и все объекты устройства.
Синхронизация потоков и TDR
Дополнительные сведения см. в разделе "Синхронизация потоков" и "TDR ".
Тестирование и отладка TDR
Дополнительные сведения см. в разделе "Тестирование и отладка TDR ".