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

Очередь перевернутого оборудования

В этой статье описывается функция аппаратной очереди flip, которая поддерживается в Windows 11 (WDDM 3.0). Аппаратная очередь flip позволяет отправлять несколько будущих кадров в очередь дисплейного контроллера. Центральный процессор и части графического процессора могут переходить на более низкие уровни состояния питания, в то время как контроллер дисплея обрабатывает несколько очередных кадров, повышая эффективность воспроизведения видео по сценариям при наличии соответствующего оборудования.

Модель очереди flip до WDDM 3.0

Многие современные контроллеры отображения поддерживают возможность очереди нескольких кадров, которые должны отображаться в последовательности. Начиная с версии WDDM 2.1, операционная система поддерживает множество запросов флип-перезаписи, которые должны быть представлены при следующей вертикальной синхронизации VSync. Драйвер минипорта отображения (KMD) указывает на эту поддержку через значение MaxQueuedMultiPlaneOverlayFlipVSync в DXGK_DRIVERCAPS. Эта возможность полезна для уменьшения задержки в игровых сценариях высокой частоты кадров, в которых несколько кадров последовательно отрисовываются с интервалом 0, с намерением отображать только последний кадр.

В сценариях воспроизведения видео содержимое нескольких будущих кадров, которые будут последовательно отображаться, известно заранее и может быть помещено в очередь в GPU. Эта предварительная очередь позволяет ЦП входить в состояние низкой мощности во время обработки очередных кадров, что приводит к значительной экономии энергии. Однако до WDDM 3.0 не было механизма отправки ОС нескольких кадров, которые должны оставаться на экране по крайней мере для одного интервала VSync без дальнейшего вмешательства ЦП. В разделе "Очередь базового переключения оборудования " представлено решение, которое позволяет ЦП перейти в состояние низкого энергопотребления и передать обработку очереди кадров на GPU.

В игровых сценариях до WDDM 3.0 после завершения отрисовки сцены в обратный буфер цепочки обмена происходит возврат к ЦП для отправки запроса на вывод содержимого кадра на экран. Для тяжелых графических нагрузок GPU, которые завершаются близко к моменту VSync, это возвращение может привести к задержке кадров и пропустить целевое время, что в результате вызывает заметные сбои кадров. В разделе "Расширенная очередь перевернутого оборудования " представлен механизм, который позволяет избежать обхода ЦП и представления завершенных кадров на экране с низкой задержкой. Для расширенной очереди аппаратного переворота требуется наличие как базовой очереди аппаратного переворота, так и функциональности аппаратного планирования GPU второго этапа.

Базовая очередь перевернутого оборудования

На следующей схеме показано, как представить три кадра, каждый из которых остается на экране для одного интервала VSync.

Схема, демонстрирующая три кадра, остающихся на экране для одного интервала VSync.

Шаблон заливки на схеме показывает время, когда происходит обработка очереди переключения программного обеспечения Dxgkrnl и потоки приложений должны проснуться и выполнить работу процессора. На каждом VSync контроллер отображения должен выдавать уведомление ЦП для завершённого переворота, а ОС должна отправить следующий запрос на переворот. Приложение также должно просыпаться на каждой VSync и запрашивать данные статистики отображения, чтобы в конечном итоге определить, когда отображается последний кадр в пакете из трех.

Интерфейсы аппаратной очереди flip, которые могут отправлять несколько будущих кадров в очередь контроллера отображения, доступны начиная с WDDM 3.0. Как уже упоминалось ранее, этот механизм позволяет ЦП и частям GPU переходить на более низкие состояния питания, а контроллер дисплея обрабатывает несколько очередных кадров. Этот переход повышает производительность сценариев воспроизведения видео на оборудовании с поддержкой.

На следующей схеме показана предлагаемая архитектура.

Схема, демонстрирующая базовый механизм очереди смены кадров.

При подходе с аппаратным управлением обе компоненты, приложение и Dxgkrnl, находятся в полностью неактивном состоянии в течение двух интервалов VSync между моментами v2 и v4, что позволяет ЦП переходить в состояние низкой мощности. ЦП уведомляется только тогда, когда кадр N+2, для которого приложение запросило ожидание, завершается.

Расширенная очередь аппаратной смены кадров

В игровых сценариях до WDDM 3.0 после завершения отрисовки сцены в обратный буфер цепочки обмена происходит возврат к ЦП для отправки запроса на вывод содержимого кадра на экран. На следующей схеме показан этот сценарий.

Схема, показывающая завершение кадра, требующее обращения к ЦП.

Эта задержка может привести к тому, что кадры пропустят свою цель, если отрисовка закончится слишком близко к VSync, как показано на диаграмме ниже.

Схема, иллюстрирующая пропущенный кадр из-за требуемой круговой передачи ЦП.

Некоторые контроллеры отображения изначально поддерживают условия ожидания, которые позволяют дисплею отправлять запрос на смену кадра после завершения рендеринга кадра ГП без участия ЦП. Так как очередь перевернутого оборудования может отправить завершенный кадр N на дисплей без циклического обхода ЦП, это может избежать пропущенных кадров, как показано на следующей схеме.

Диаграмма, отображающая завершение кадра без необходимости обращения к ЦП.

Оставшаяся часть этой статьи описывает базовую функцию очереди для переключения оборудования.

Поддержка DDI

Следующие DDIs были добавлены для поддержки функции очереди перевернутого оборудования.

Проверка доступности компонентов

Для очереди перевернутого оборудования требуется согласование включения и отключения ОС. KMD, поддерживающий очередь аппаратного переворота, должен сначала вызывать DXGKCB_QUERYFEATURESUPPORT во время начала работы устройства с идентификатором функции DXGK_FEATURE_HWFLIPQUEUE, чтобы определить, разрешает ли ОС включение очереди аппаратного переворота.

Очередь перевернутого оборудования может использоваться только в том случае, если обратный вызов выполнен успешно, и параметр "Включить " имеет значение TRUE.

KMD может использовать следующий пример кода во время переключения на аппаратное обеспечение и на экспериментальной стадии.


DXGKARGCB_QUERYFEATURESUPPORT HwFlipQueueEnabledArgs = {};
HwFlipQueueEnabledArgs.DeviceHandle = DeviceHandle;
HwFlipQueueEnabledArgs.FeatureId = DXGK_FEATURE_HWFLIPQUEUE;
HwFlipQueueEnabledArgs.DriverSupportState = DXGK_FEATURE_SUPPORT_EXPERIMENTAL;

if (!NT_SUCCESS(pDxgkInterface->DxgkCbQueryFeatureSupport(&HwFlipQueueEnabledArgs)) ||
    !HwFlipQueueEnabledArgs.Enabled)
{
    // Disable hardware flip queue because the OS didn't allow it.           
}
else
{
    // Enable hardware flip queue because the OS allowed it.
}

Во время запуска драйвера, даже если можно включить очередь аппаратного флипа без включения аппаратного планирования GPU, эта комбинация официально не поддерживается производителем. В настоящее время Windows требует включения аппаратного планирования GPU, чтобы включить базовую очередь перевернутого оборудования для официально выпущенных драйверов.

Указание возможностей аппаратной очереди

MaxHwQueuedFlips добавлен в DXGK_DRIVERCAPS, чтобы указать поддержку аппаратной очереди переворотов. Если ОС позволяет поддержку очереди аппаратных переключений, как описано ранее, KMD, поддерживающая очереди аппаратных переключений, должна установить MaxHwQueuedFlips на значение больше 1. Если MaxHwQueuedFlips больше 1, KMD указывает, что оборудование отображения поддерживает до MaxHwQueuedFlips будущих кадров, которые могут быть поставлены в очередь на отображение для определенного VidPnSource на GPU. ОС учитывает ограничения, предоставляемые драйвером, для типа переворотов, которые могут быть поставлены в очередь заранее.

HwQueuedFlipCaps также добавлен в DXGK_DRIVERCAPS. Этот элемент в настоящее время зарезервирован для использования системы; драйверы не должны использовать его.

Перевернуть целевое время и формат метки времени

Когда ОС отправляет запрос на переворот в очередь переворачивания аппаратного обеспечения, она также предоставляет целевое время переворота. Переворачивание становится видимым пользователю после истечения целевого времени.

ОС использует единицы счетчика часов ЦП, полученные из KeQueryPerformanceCounter, для передачи целевого времени кадров и интерпретации фактического времени кадров.

Отправка свопов в очереди

Структура DXGKARG_SETVIDPNSOURCEADDRESSWITHMULTIPLANEOVERLAY3 , передаваемая в функцию обратного вызова KMD DXGkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3 , была изменена следующим образом, чтобы включить отправку очередных сверток:

  • Следующие три члена были добавлены в структуру OutputFlagsDXGK_SETVIDPNSOURCEADDRESS_OUTPUT_FLAGS. Дополнительные сведения об этих членах, включая случаи повторных попыток и отказов, см. в статье DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3.

    • HwFlipQueueDrainNeeded
    • HwFlipQueueDrainAllPlanes
    • HwFlipQueueDrainAllSources

  • Добавлен элемент TargetFlipTime . TargetFlipTime описывает время переворачивания целевого объекта в единицах QPC. Когда таймер достигает этого значения, кадр может быть отправлен на экран с учетом VSync и флагов разрыва. В присутствии ранее поставленных ожидающих операций переключения ОС гарантирует, что для каждой плоскости MPO, на которую ссылается запрос на TargetFlipTime, значение времени больше или равно любому из целевых значений времени для ожидающих переключений этой плоскости. Другими словами, может быть последовательность изменений с теми же или увеличивающимися метками времени, но не может быть последовательности, которая возвращается назад во времени.

DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3 повторы и случаи сбоя

Не удалось поставить запрос в очередь для оборудования из-за ожидающих переключений.

Существует несколько особых случаев, которые могут предотвратить KMD от постановки в очередь запроса на переворот, в то время как другие запросы на переворот ожидают. В таких случаях KMD должен возвращать STATUS_RETRY из DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3 и установить HwFlipQueueDrainNeeded равным 1. ОС попытается повторно отправить запрос на смену кадров после завершения всех ожидающих операций на поверхностях, затронутых этой сменой, и после достижения целевого времени.

В некоторых случаях аппаратное обеспечение дисплея может потребовать завершения ожидающих переключений на всех плоскостях, а не только тех, на которые ссылается входящий запрос на переключение. В этом случае флаги HwFlipQueueDrainNeededed и HwFlipQueueDrainAllPlanes должны иметь значение 1, а KMD должны возвращать STATUS_RETRY.

Аналогичным образом, для перераспределения внутренних ресурсов может потребоваться завершение ожидающих переключений для всех источников VidPn, в этом случае необходимо задать флаги HwFlipQueueDrainAllSources и HwFlipQueueDrainNeeded, и KMD должен возвращать STATUS_RETRY.

Кроме того, KMD может указать операционной системе, следует ли выполнить повторную отправку на устройстве IRQL (PrePresentNeeded set 0), или если ОС должна выполнять этот вызов по PASSIVE_LEVEL (PrePresentNeed set 1). Если KMD по-прежнему возвращает STATUS_RETRY, даже если нет дополнительных ожидающих переворотов на этом VidPnSourceId, это условие рассматривается как сбой из-за недопустимого параметра.

Важно, чтобы значение MaxHwQueuedFlips по-прежнему отражало максимальное количество простых изменений, относящихся только к адресам, которые можно поставить в очередь для плоскости MPO. Механизм STATUS_RETRY следует использовать для более сложных запросов на переверку, которые не могут быть глубоко в очереди, например изменения конфигурации плоскости.

Недопустимый сбой параметров

В модели очереди перевернутого оборудования обработка неудачных запросов на переверку ОС была переработана, чтобы обеспечить лучшую отладку. Если KMD не удается обработать запрос на смену кадра, он должен возвращать STATUS_INVALID_PARAMETER из DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3. В зависимости от параметров ОС ОС ос выполняет одно из следующих действий:

  • Остановка отладчика ядра и проверка на ошибки: Это поведение часто включается в сборках разработки или предварительного выпуска для улучшения отладки в момент возникновения условия сбоя.
  • Дамп живого ядра, за которым следует TDR: поведение конечных пользователей в розничной торговле.

Указание поведения прерываний VSync

Чтобы обеспечить экономию энергии в сценариях переворачивания в очереди, ОС часто приостанавливает обычные прерывания VSync, чтобы сохранить ЦП в низком состоянии питания. Однако некоторые переключения помечаются как требующие вызова прерывания, чтобы приложение могло наблюдать за пакетом завершенных операций и ставить в очередь дальнейшие задачи. Существуют также случаи, когда приложения запрашивают пробуждение на каждом прерывании VSync, даже если нет ожидающих запросов на изменения кадров. И наоборот, в полностью неактивной системе прерывания VSync приостанавливаются до появления новой активности презентации или слушателей VSync.

Для обработки всех этих случаев были введены следующие: обратный вызов драйвера и структура обратного вызова.

KMD предоставляет указатель на функцию DxgkDdiSetInterruptTargetPresentId в DRIVER_INITIALIZATION_DATA

ОС вызывает DxgkDdiSetInterruptTargetPresentId, чтобы указать целевой PresentId, который должен приводить к прерыванию VSync, вызываемого при завершении соответствующего переключения. Эта функция вызывается на уровне прерывания устройства (DIRQL), чтобы синхронизироваться с DxgkDdiSetVidPnSourceAddress и прерыванием VSync.

Взаимодействие с DxgkDdiControlInterrupt

Если прерывания VSync полностью отключены через DxgkDdiControlInterrupt, /, /, они остаются отключенными независимо от значения целевого идентификатора объекта прерывания PresentId. KMD необходимо хранить последний ID цели прерывания, чтобы его можно было использовать после повторного включения VSync.

Если прерывания VSync включены через DxgkDdiControlInterruptXxx, интервальное целевое ID прерывания (pSetInterruptTargetPresentId) обеспечивает более точный контроль, как показано ниже:

  • Если для целевого идентификатора задано значение UINT64_MAX, прерывание VSync не требуется, пока целевой идентификатор не будет изменен снова. Прерывания VSync отключены, но KMD необходимо обеспечить реализацию DXGK_VSYNC_DISABLE_KEEP_PHASE поведения для повторного включения прерываний.

  • Если целевой идентификатор установлен на 0, для каждой вертикальной синхронизации требуются прерывания.

  • При наличии любого другого значения идентификатора прерывания возникают, если в данный момент сканированный PresentId >= InterruptTargetPresentId.

При наличии нескольких плоскостей MPO прерывание VSync должно быть поднято, если это требуется какой-либо из плоскостей.

Отключение VSync на 2-й стадии с помощью DxgkDdiSetInterruptTargetPresentId

Если вызов ОС DxgkDdiSetInterruptTargetPresentId задает InterruptTargetPresentId на плоскости, что приведет к отключению VSync полностью на этом VidPnSource (то есть эта плоскость была последней плоскостью, в котором включен VSync, и теперь эта плоскость отключает VSync), KMD должен отключить прерывания VSync, но сохранить этап VSync в аппаратном включении (DXGK_VSYNC_DISABLE_KEEP_PHASE). После определенного периода времени (как правило, эквивалентного двум периодам VSync) ОС выполнит вызов DxgkDdiControlInterruptXxx с DXGK_VSYNC_DISABLE_NO_PHASE. Этот вызов гарантирует, что KMD получает возможность отключить этап VSync и тактирующие импульсы VSync, чтобы сэкономить максимальное количество энергии и обеспечить равномерную производительность по сравнению с системами очереди без аппаратной поддержки.

Отмена переключения в очереди

В таких случаях, как переходы состояния полноэкранного режима или выход приложения, будущие отложенные операции могут быть отменены. Для обработки этих случаев были представлены следующие обратные вызовы драйвера и связанные структуры:

KMD предоставляет указатель на функцию DxgkDdiCancelFlips в DRIVER_INITIALIZATION_DATA.

ОС указывает диапазон очередных кадров для отмены при вызове DxgkDdiCancelFlips, и KMD сообщает обратно в ОС диапазон кадров, которые он смог отменить синхронно.

В приведённом ниже примере показаны механика и синхронный случай отмены переворачивания на одной плоскости. (ОС не поддерживает асинхронную отмену в Windows 11, версии 22H2.) Представьте, что следующие переключения помещаются в аппаратную очередь переключений:

  • PresentId N
  • time t0 PresentId N+1
  • time t1 PresentId N+2
  • time t2 PresentId N+3
  • time t3 PresentId N+4
  • время t4

Затем ОС решает отменить перевернутые фигуры N+2, N+3 и N+4, поэтому он вызывает DxgkDdiCancelFlips с Параметром PresentIdCancelRequested значение N+2.

Когда KMD проверяет состояние очереди перевернутого оборудования, оно определяет, что:

  • Кадр N+2 уже отправлен на аппаратную часть дисплея и не может быть отменён на момент вызова.
  • Перевороты N+3 и N+4 могут быть синхронно удалены из очереди аппаратных переворотов без побочных эффектов.

В результате KMD устанавливает PresentIdCancelled на N+3, а N+2 завершает, как обычно.

ОС помечает N+3 и N+4 как отмененные, и она рассматривает N, N+1, N+2 как в полете. При возникновении следующих прерываний VSync журнал очереди смены, как обычно, будет указывать метки времени для N, N+1, N+2.

Предполагается, что диапазон синхронно отмененных сверток должен быть непрерывным и, если он не равен нулю, включает последний представленный идентификатор, отправленный в KMD. Другими словами, в обоих диапазонах синхронных отмененных перевернутых не может быть пробелов.

Отмена взаимосвязанных переворотов на нескольких плоскостях

Взаимосвязанный флип отправляется путем вызова DxgkDdiSetVidPnSourceAddress с несколькими плоскостями и PresentIds. Контракт между ОС и KMD следующий:

  • Набор плоскостей должен быть видимым на том же вертикальном синхронизаторе.
  • Аппаратное обеспечение дисплея не может отображать только подмножество этих плоскостей на одном VSync, а остальные — на следующем VSync.

В модели аппаратной очереди накладных операций такие взаимосвязанные перевороты отменяются путем передачи нескольких плоскостей и идентификаторов PresentId в вызове DxgkDdiCancelFlips. Набор плоскостей, переданных в таких случаях, должен соответствовать ожидающему взаимоблокирующему запросу на изменение состояния, и решение KMD относительно всех заблокированных PresentIds должно совпадать.

  • Не отменяйте, иначе
  • Синхронная отмена

DxgkDdiCancelFlips вызывается на уровне прерывания устройства (DIRQL), чтобы синхронизироваться с DxgkDdiSetVidPnSourceAddress и прерыванием VSync.

Получение актуальной статистики для запланированных операций переворота

Так как аппаратная очередь смены кадров предназначена для того, чтобы избежать пробуждения ЦП на каждом VSync, необходимо иметь механизм для сохранения времени отображения последних нескольких смен кадров.

Графические драйверы, поддерживающие аппаратную очередь отображения, должны записывать информацию в буфер журнала очереди отображения, предоставляемый операционной системой, для каждого завершенного или отмененного отображения для заданной плоскости MPO для каждого активного VidPnSource.

Ос гарантирует предоставление указателя журнала очереди переверки (при вызове DxgkDdiSetFlipQueueLogBuffer) перед первым вызовом dxgkDdiSetVidPnSourceAddress для заданного уровня MPO для каждого активного VidPnSource. ОС может уничтожить буфер журнала flip-очереди, если flip-очередь не имеет незавершённых запросов. В этом случае он предоставит новый указатель журнала перед следующим вызовом DxgkDdiSetVidPnSourceAddress . Журнал очереди переверки циклический. После записи записи [NumberOfEntries-1] следующая запись журнала — [0].

После завершения пакета запланированных переворотов KMD должен гарантировать, что журнал очереди для завершенных операций обновляется в самые ранние из этих двух точек во времени:

  • Обработчик прерывания VSync для смены экрана, требующей вызова прерывания.
  • В ответ на явный запрос DxgkDdiUpdateFlipQueueLog из ОС.

DDIs журнала управления очередями

Добавлены следующие связанные с журналом flip queue обратные вызовы и связанные структуры.

KMD предоставляет указатель на его функции в DRIVER_INITIALIZATION_DATA.

Обновления структуры прерываний VSync

Следующие изменения были внесены в структуру DXGKARGCB_NOTIFY_INTERRUPT_DATA для реализации прерываний VSync для модели очереди перевернутого оборудования:

  • Значение перечисления DXGK_INTERRUPT_CRTC_VSYNC_WITH_MULTIPLANE_OVERLAY3 было добавлено как тип прерывания.
  • Структура CrtcVSyncWithMultiPlaneOverlay3 была добавлена в объединение. Семантика CrtcVSyncWithMultiPlaneOverlay3 подобна существующей структуре CrtcVSyncWithMultiPlaneOverlay2, за исключением, что вместо одного последнего завершенного PresentId для каждой плоскости, CrtcVSyncWithMultiPlaneOverlay3.pMultiPlaneOverlayVSyncInfo указывает на диапазон ранее неотчитанных PresentId из журнала очереди чередования.
  • Структура DXGK_MULTIPLANE_OVERLAY_VSYNC_INFO3 была добавлена для CrtcVSyncWithMultiPlaneOverlay3 в качестве члена pMultiPlaneOverlayVSyncInfo.

С помощью примера схемы очереди перевернутого оборудования "Базовый" снова выполните следующие действия.

Схема, демонстрирующая базовый механизм очереди смены кадров.

Предположим, FirstFreeFlipQueueLogEntryIndex было установлено значение 40 в момент отправки флипа N, а затем завершились представления N, N+1, N+2.

После того как конфигурация одной плоскости завершила три PresentIds N, N+1 и N+2 в соответствующие времена v2, v3, v4, KMD записал три новые записи в буфер журнала очереди переворота с индексами 40, 41 и 42. KMD сообщает значение FirstFreeFlipQueueLogEntryIndex 43 в структуре CrtcVSyncWithMultiPlaneOverlay3. В ОС отмечается, что FirstFreeFlipQueueLogEntryIndex изменился с 40 на 43 и данные считываются из записей журнала 40, 41 и 42. KMD необходимо задать следующие значения буфера журнала очереди следующим образом:

  • VidPnTargetId: то же значение, что и в CrtcVSyncWithMultiPlaneOverlay2

  • PhysicalAdapterMask: то же значение, что и в CrtcVSyncWithMultiPlaneOverlay2

  • MultiPlaneOverlayVSyncInfoCount = 1

  • pMultiPlaneOverlayVSyncInfo[0]. LayerIndex = 0

  • pMultiPlaneOverlayVSyncInfo[0]. FirstFreeFlipQueueLogEntryIndex = 43

  • LogBufferAddressForPlane0[40]. PresentId = N

  • LogBufferAddressForPlane0[40]. PresentTimestamp = v2

  • LogBufferAddressForPlane0[41]. PresentId = N+1

  • LogBufferAddressForPlane0[41]. PresentTimestamp = v3

  • LogBufferAddressForPlane0[42]. PresentId = N+2

  • LogBufferAddressForPlane0[42]. PresentTimestamp = v4

Явный запрос на обновление журнала очереди ожидания

Бывают случаи, когда ОС должна получить сведения о последней завершенной серии переворотов без ожидания прерывания VSync. В таких случаях операционная система инициирует явный вызов DxgkDdiUpdateFlipQueueLog, чтобы запросить, чтобы KMD считала данные из структуры данных своего оборудования и записывала информацию о последних Flip в журнал очереди. Семантика журнала совпадает с ранее описанным, единственное изменение заключается в том, что FirstFreeFlipQueueLogEntryIndex возвращается в ОС за пределами прерывания VSync.

DxgkDdiUpdateFlipQueueLog вызывается на уровне прерывания устройства (DIRQL), и находится в том же классе синхронизации, что и DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3 DDI.

Изменения режима отображения и переходы состояний питания при наличии очереди операции в аппаратной очереди переключений

Dxgkrnl гарантирует, что уже поставленные в очередь операции переворота в аппаратной очереди завершаются или отменяются перед изменением режима или выключением монитора.

Сопоставление текущих запросов с метками времени аппаратной очереди переворота

Если для определенного адаптера включена очередь аппаратного переворота, метка времени сопровождает все вызовы переключений. Другими словами, KMD не требует обработки семантики старого и нового dxgkDdiSetVidPnSourceAddress .

ОС автоматически преобразует существующие запросы API на основе интервала в вызовы флипов на основе метки времени для KMD. В следующих разделах рассматриваются различные случаи и их сопоставление с сочетанием флагов, длительности и меток времени, полученных KMD.

Семантика разрывающего и неразрывающего преобразований

Семантика флипа с разрывами концептуально одинакова, когда включена очередь аппаратного флипа. После достижения TargetFlipTime KMD должен отправить кадр переворота на отображение, с учетом флагов, таких как FlipImmediate, FlipImmediateNoTearing и FlipOnNextVSync. Иными словами, KMD должен вести себя так, как если бы ОС отправила в нее перевернутый объект точно в TargetFlipTime с теми же флагами и параметрами.

Например, если FlipOnNextVSync установлено в 1 и TargetFlipTime находится в середине кадра, то на следующем VSync должен отображаться только переворот.

Поддержка FlipOverwrite и очередь аппаратного переключения

Аппаратная очередь смены кадров является строгим супермножеством функции перезаписи, которая управляется значением MaxQueuedMultiPlaneOverlayFlipVSync в DXGK_DRIVERCAPS.

Поэтому ОС игнорирует значение MaxQueuedMultiPlaneOverlayFlipVSync, если драйвер выбирает очередь переворотов оборудования, задав для MaxHwQueuedFlips значение больше 1.

Несколько изменений направления с истекшим сроком действия времени переключения цели

При наличии нескольких переворотов в очереди с истекшим сроком действия TargetFlipTime для заданной плоскости MPO аппаратная очередь отображения должна выбрать последний переворот из просроченных и отправить его для отображения. Остальные просроченные перевороты следует считать отмененными, и соответствующие записи журнала очереди переворота должны содержать DXGK_HWFLIPQUEUE_TIMESTAMP_CANCELLED в качестве значения PresentTimestamp.

Взаимодействие между длительностью и целевым временем переключения

Параметр Duration в структуре DXGKARG_SETVIDPNSOURCEADDRESSWITHMULTIPLANEOVERLAY3 должен вступать в действие, когда на экране отображается переключение, указанное в этой структуре. Он задает новое требуемое поведение частоты обновления экрана для выходных данных, указанных VidPnSourceId, на всех уровнях отображения. В выпусках WDDM 3.1 и Windows Server 2022, чтобы упростить процесс внедрения драйвера для оборудования, не поддерживающего пользовательские изменения Длительности в очереди, ОС отправляет только запросы на переключение с новым значением параметра Длительности после завершения предыдущих запросов переключения.

Сопоставление интервалов представления с TargetFlipTime

Интервалы сопоставления при фиксированной частоте обновления

Чтобы сохранить существующую семантику текущего интервала, ОС должна вычислить целевое время переворачивания с помощью текущего интервала и частоты обновления. Однако установка целевого времени смены кадров точно на запланированное время VSync для вывода на экран приводит к частым сбоям. Эти сбои возникают из-за пропущенной виртуальной синхронизации, когда фактическое время VSync смещается немного. Чтобы защититься от сбоев, ОС вычитает половину интервала VSync из вычисляемого целевого времени переворачивания.

Ниже приведена упрощенная формула для сопоставления текущего интервала с целевым временем переворачивания:

TargetFlipTime = PreviousFlipStartVSyncTime + (PreviousFlipPresentInterval * FixedRefreshRate) - (FixedRefreshRate / 2)

Сопоставление интервалов при наличии функции виртуальной частоты обновления WDDM 2.9

Функция виртуальной частоты обновления может временно увеличить частоту обновления дисплея до целого числа, равного кратной текущей частоте обновления (то есть 24 Гц можно увеличить до 144 Гц или 192 Гц). Для устройств, способных поддерживать это ускорение, формула в предыдущем разделе изменяется, чтобы использовать наиболее быстрый множитель текущей частоты обновления.

TargetFlipTime = PreviousFlipStartVSyncTime + (PreviousFlipPresentInterval * FixedRefreshRate) - (FastestRefreshRate / 2)

Интервалы сопоставления при изменении частоты обновления на некратное значение

Если частота обновления изменяется на неумультную частоту текущего обновления (например, с 24 Гц до 60 Гц), ОС должна проверить очередь, чтобы узнать, является ли их вычисляемое целевое время допустимым для новой частоты обновления. Если необходимо изменить целевое время переворачивания, ОС отменяет запланированные перевороты и повторно ставит их в очередь с вновь рассчитанными целевыми временами переворачивания.