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

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

  • Статья

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

Модель очереди перевернутых WDDM 3.0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поддержка DDI

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

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

Для очереди перевернутого оборудования требуется согласование включения и отключения ОС. KMD, поддерживающий очередь переверки оборудования, должен сначала вызывать DXGKCB_QUERYFEATURESUPPORT во время начала устройства с помощью featureId 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 , была изменена следующим образом, чтобы включить отправку очередных перевернутых переверов:

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

    • HwFlipQueueDrainNeed
    • HwFlipQueueDrainAllPlanes
    • HwFlipQueueDrainAllSources

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

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

Сбой очереди запроса на оборудование из-за ожидающих перевернутых изменений

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

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

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

Кроме того, KMD может указать операционной системе, следует ли выполнить повторную отправку на устройстве IRQL (PrePresentNeeded set to 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 DxgkDdiControlInterrupt2//DxgkDdiControlInterrupt3, они остаются отключенными независимо от значения целевого объекта PresentId прерывания. KMD требуется для хранения последнего целевого целевого объекта прерывания, чтобы его можно было учитывать после включения VSync еще раз.

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

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

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

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

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

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

Если вызов ОС dxgkDdiSetInterruptTargetPresentId задает ПрерываниеTargetPresentId на плоскости, что приведет к отключению 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
  • time 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:

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

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

  • Не отменяйте или не отменяйте
  • Отмена синхронно

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

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

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

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

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

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

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

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

Добавлены следующие обратные вызовы, связанные с журналом очередей, и связанные структуры:

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

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

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

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

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

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

Предположим, что 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 считывает из своей собственной структуры данных оборудования и записывает последние сведения о переверке в журнал очереди переверки. Семантика журнала совпадает с ранее описанным; Единственное изменение заключается в том, что FirstFreeFlipQueueLogEntryIndex возвращается в ОС за пределами прерывания VSync.

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

Изменение режима отображения и переходы питания в присутствии очереди перевернутого в очереди перевернутого оборудования

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

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

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

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

Слезоточивая и неуклюговая семантика семантики

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

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

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

Очередь перевернутого оборудования — это строгое супермножество функции перезаписи, управляемой значением MaxQueuedMultiPlaneOverlayFlipVSync в DXGK_DRIVERCAPS.

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

Несколько перевернутых с истекшим сроком действия TargetFlipTime

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

Взаимодействие между длительностью и targetFlipTime

Параметр 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 Гц), ОС должна проверить очередь, чтобы узнать, является ли их вычисляемое целевое время допустимым для новой частоты обновления. Если необходимо изменить целевое время переворачивания, ОС отменяет очереди перевернутые и повторно отправляет их с помощью недавно вычисляемого времени переворачивания целевого объекта.