Compartir a través de

Cola de prerenderización de hardware

En este artículo se describe la característica de cola de volteo de hardware que se admite a partir de Windows 11 (WDDM 3.0). Una cola de volteo de hardware permite enviar varios fotogramas futuros a la cola del controlador de pantalla. La CPU y las partes de la GPU pueden pasar a estados de bajo consumo mientras el controlador de pantalla está procesando varios fotogramas en cola, lo que mejora la eficiencia energética de los escenarios de reproducción de vídeo en hardware compatible.

Modelo de cola de alternancia anterior a WDDM 3.0

Muchos controladores de pantalla modernos admiten la capacidad de poner en cola varios fotogramas que se van a mostrar en una secuencia. A partir de WDDM 2.1, el sistema operativo admite múltiples solicitudes pendientes de 'flip overwrite' que se presentarán en el próximo VSync. El controlador de minipuerto de pantalla (KMD) indica esta compatibilidad a través del valor MaxQueuedMultiPlaneOverlayFlipVSync en DXGK_DRIVERCAPS. Esta funcionalidad es útil para reducir la latencia en escenarios de juegos de alta velocidad de fotogramas en los que varios fotogramas se representan secuencialmente con el intervalo 0, con la intención de mostrar solo el fotograma más reciente.

En escenarios de reproducción de vídeo, el contenido de los varios fotogramas futuros que se mostrarán secuencialmente se conoce de antemano y se puede poner en cola en la GPU. Este sistema de cola avanzado permite que la CPU entre en un estado de baja potencia mientras se procesan los fotogramas en cola, lo que da lugar a un considerable ahorro de energía. Sin embargo, antes de WDDM 3.0 no había ningún mecanismo para que el sistema operativo enviara más de un fotograma que necesita permanecer en la pantalla durante al menos un intervalo de VSync sin intervención adicional de la CPU. La sección Cola de volteo de hardware básico presenta una solución que permite a la CPU entrar en un estado de baja potencia y descargar el procesamiento de fotogramas en cola en la GPU.

En escenarios de juegos anteriores a WDDM 3.0, después de que la GPU termine de representar la escena en el búfer de retroceso de la cadena de intercambio, hay un recorrido de ida y vuelta a la CPU para enviar la solicitud para presentar el contenido del fotograma a la pantalla. En el caso de cargas de trabajo de GPU pesadas que terminan cerca de la sincronización vertical (VSync), esta operación de ida y vuelta puede provocar que los fotogramas se retrasen y pierdan el tiempo de destino previsto, lo que da lugar a fallos de fotograma visibles. La sección Cola de volteo de hardware avanzada presenta un mecanismo para evitar este recorrido de ida y vuelta de CPU y presentar fotogramas completados a la pantalla con baja latencia. La cola de volteo de hardware avanzada requiere que estén presentes tanto la cola básica de volteo de hardware como la funcionalidad de programación de hardware de GPU de etapa 2.

Cola de volteo de hardware básica

En el diagrama siguiente se muestra el caso de la presentación de tres fotogramas, cada uno de los cuales permanece en la pantalla durante un intervalo de VSync.

Diagrama que ilustra tres fotogramas que permanecen en la pantalla para un intervalo de VSync cada uno.

El patrón de relleno del diagrama muestra los momentos en los que los subprocesos de cola de volteo de software Dxgkrnl y los subprocesos de aplicación tienen que reactivarse y realizar el trabajo de CPU. En cada VSync, el controlador de pantalla debe enviar una notificación de la CPU al sistema operativo por el cambio de imagen completado, y el sistema operativo debe enviar la siguiente solicitud de cambio de imagen. La aplicación también tiene que despertarse en cada VSync y consultar las estadísticas actuales para eventualmente aprender cuándo se muestra el último fotograma del lote de tres.

Los Interfaces de Programación de Dispositivos (DDIs) de cola de intercambio de hardware, que pueden enviar varios fotogramas futuros a la cola del controlador de visualización, están disponibles a partir de WDDM 3.0. Como se indicó anteriormente, este mecanismo permite que la CPU y las partes de la GPU pasen a estados de menor potencia mientras el controlador de pantalla está procesando varios fotogramas en cola. Esta transición mejora la eficacia energética de los escenarios de reproducción de vídeo en hardware compatible.

En el diagrama siguiente se muestra la arquitectura propuesta.

Diagrama que demuestra el mecanismo básico de fila de intercambio de hardware.

Con el enfoque de cola de intercambio de hardware, tanto la aplicación como los componentes de CPU Dxgkrnl están totalmente inactivos durante dos intervalos de VSync entre las veces v2 y v4, lo que permite que la CPU entre en un estado de baja potencia. Solo se notifica a la CPU cuando se completa el fotograma N+2 por el que la aplicación solicitó esperar.

Cola de intercambio de hardware avanzada

En escenarios de juegos anteriores a WDDM 3.0, después de que la GPU termine de representar la escena en el búfer de retroceso de la cadena de intercambio, hay un recorrido de ida y vuelta a la CPU para enviar la solicitud para presentar el contenido del fotograma a la pantalla. En el diagrama siguiente se muestra este escenario.

Diagrama que muestra la finalización de fotogramas que requiere un recorrido de ida y vuelta de CPU.

El costo de este recorrido de ida y vuelta puede hacer que los fotogramas pierdan su destino si la representación ha finalizado demasiado cerca de la VSync, como se muestra en el diagrama siguiente.

Diagrama que ilustra un fotograma perdido debido al recorrido de ida y vuelta de CPU necesario.

Algunos controladores de pantalla admiten de forma nativa las condiciones de espera que permiten que la pantalla envíe la solicitud de volteo una vez que la GPU haya terminado de representar el marco sin el recorrido de ida y vuelta de CPU. Dado que la cola de volteo de hardware puede enviar el marco N completado a la pantalla sin un recorrido de ida y vuelta de CPU, podría evitar fotogramas perdidos, como se muestra en el diagrama siguiente.

Diagrama que muestra la finalización de fotogramas sin necesidad de un recorrido de ida y vuelta de CPU.

En el resto de este artículo se describe la característica básica de cola de volteo de hardware.

Compatibilidad con DDI

Se agregaron las siguientes DDIs para admitir la funcionalidad de cola de cambios de hardware.

Comprobación de la disponibilidad de características

La cola de cambio de hardware requiere la negociación de habilitación/deshabilitación del sistema operativo. Un KMD que admita cola de volteo de hardware debe llamar primero a DXGKCB_QUERYFEATURESUPPORT durante el inicio del dispositivo con un FeatureId de DXGK_FEATURE_HWFLIPQUEUE para determinar si el sistema operativo permite habilitar la cola de volteo de hardware.

La cola de volteo de hardware solo se puede usar si la devolución de llamada es exitosa y Enable se establece en TRUE.

Un KMD puede usar el código de ejemplo siguiente durante las fases experimentales y de puesta en cola de volteo de hardware.


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.
}

Durante la inicialización del controlador, aunque es posible habilitar la cola de intercambio de hardware sin activar la programación de la GPU, esta combinación no está oficialmente soportada. Actualmente, Windows requiere que la programación de hardware de GPU esté habilitada para habilitar la cola de volteo de hardware básica en controladores publicados oficialmente.

Indica las funcionalidades de puesta en cola de hardware

MaxHwQueuedFlips se agregó a DXGK_DRIVERCAPS para indicar la compatibilidad con colas de cambio de hardware. Si el sistema operativo permitía compatibilidad con colas de volteo de hardware como se describió anteriormente, un KMD que admita una cola de volteo de hardware debe establecer MaxHwQueuedFlips en un valor mayor que 1. Cuando MaxHwQueuedFlips es mayor que 1, KMD indica que el hardware de pantalla admite hasta MaxHwQueuedFlips fotogramas futuros que se pueden poner en cola para que se muestren para un determinado VidPnSource en la GPU. El sistema operativo respeta las restricciones proporcionadas por el controlador sobre el tipo de volteos que se pueden poner en cola de antemano.

HwQueuedFlipCaps también se agregó a DXGK_DRIVERCAPS. Este miembro está reservado actualmente para uso del sistema; los controladores no deben usarlo.

Voltear la hora de destino y el formato de marca de tiempo de destino

Cuando el sistema operativo envía una solicitud invertida a la cola de volteo de hardware, también envía el tiempo de volteo de destino. Una vez que se haya alcanzado el tiempo objetivo para el cambio, el giro puede hacerse visible para el usuario.

El sistema operativo utiliza las unidades de contador del reloj de la CPU, obtenidas de KeQueryPerformanceCounter, para calcular el tiempo de fotograma objetivo e interpretar el tiempo de fotograma real.

Envío de giros en cola

La estructura DXGKARG_SETVIDPNSOURCEADDRESSWITHMULTIPLANEOVERLAY3 , que se pasa a la función de devolución de llamada DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3 de KMD, se modificó de la siguiente manera para habilitar el envío de volteos en cola:

  • Los tres miembros siguientes se agregaron a la estructura DXGK_SETVIDPNSOURCEADDRESS_OUTPUT_FLAGS de OutputFlags. Consulte los casos de reintento y fallo de DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3 para obtener más información sobre estos miembros.

    • HwFlipQueueDrainNeeded
    • HwFlipQueueDrainAllPlanes
    • HwFlipQueueDrainAllSources

  • Se agregó un miembro TargetFlipTime . TargetFlipTime describe el tiempo de volteo de destino en unidades QPC. Cuando el reloj alcanza este valor, el fotograma se puede enviar a la pantalla mientras se respetan las marcas VSync y desgarrado. En presencia de flips pendientes previamente en cola, el sistema operativo garantiza que para cada plano MPO al que hace referencia la solicitud de flip, TargetFlipTime es mayor o igual que cualquiera de los tiempos de destino de flips pendientes para dicho plano. En otras palabras, puede haber una secuencia de cambios con las mismas marcas de tiempo o en aumento, pero no puede haber una secuencia que retroceda en el tiempo.

Casos de reintento y error dxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3

Error al poner en cola la solicitud al hardware debido a cambios pendientes

Hay varios casos especiales que podrían impedir que KMD coloque en cola una solicitud de volteo mientras que otras solicitudes de volteo están pendientes. En tales casos, KMD debe devolver STATUS_RETRY de DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3 y establecer HwFlipQueueDrainNeeded igual a 1. El sistema operativo intentará volver a enviar la solicitud de volteo después de que se terminen todos los volteos pendientes en los planos afectados por el volteo y una vez alcanzado el tiempo de destino.

En algunos casos, el hardware de visualización puede requerir la finalización de volteos pendientes en todos los planos, no solo los a los que hace referencia la solicitud de volteo entrante. En este caso, las banderas HwFlipQueueDrainNeeded y HwFlipQueueDrainAllPlanes deben ser establecidas en 1 y KMD debe devolver STATUS_RETRY.

Del mismo modo, el hardware de visualización puede requerir la finalización de cambios pendientes en todos los orígenes VidPn para reasignar los recursos internos; en ese caso, se deben establecer las banderas HwFlipQueueDrainAllSources y HwFlipQueueDrainNeeded, y KMD debe devolver STATUS_RETRY.

Además, KMD puede indicar al sistema operativo si el reenvío debe realizarse en el IRQL del dispositivo con PrePresentNeeded establecido en 0, o si el sistema operativo debe realizar la llamada en PASSIVE_LEVEL con PrePresentNeeded establecido en 1. Si KMD sigue devolviendo STATUS_RETRY, aunque ya no hay más volteos pendientes en el VidPnSourceId, esta condición se trata como un error de parámetro no válido.

Es importante que el valor de MaxHwQueuedFlips siga reflejando el número máximo de cambios simples que solo afectan la dirección y que se pueden poner en cola en un plano MPO. El mecanismo de STATUS_RETRY debe usarse para solicitudes de volteo más complejas que no se pueden poner en cola profundamente, como los cambios de configuración del plano.

Error de parámetro no válido

En el modelo de cola de volteo de hardware, el control del sistema operativo de las solicitudes de volteo con errores se reprocesó para permitir una mejor depuración. Cuando KMD no puede procesar una solicitud invertida, debe devolver STATUS_INVALID_PARAMETER de DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3. En función de la configuración del sistema operativo, el sistema operativo realiza una de las siguientes acciones:

  • Interrupción y comprobación de errores del depurador del kernel: Este comportamiento suele habilitarse en compilaciones de desarrollo o versiones preliminares para mejorar la capacidad de depuración justo cuando ocurre la condición de fallo.
  • Volcado de kernel activo seguido de un TDR: el comportamiento del usuario final comercial.

Especificación del comportamiento de interrupción de VSync

Para lograr un ahorro de energía en escenarios de intercambio en cola, el sistema operativo suele suspender interrupciones periódicas de VSync para mantener la CPU en un estado de bajo consumo. Sin embargo, algunos volteos se marcan como la necesidad de que se genere una interrupción para que la aplicación observe el lote de los regalos completados y poner en cola más trabajo. También hay casos en los que las aplicaciones solicitan reactivarse en cada interrupción de VSync, independientemente de si hay solicitudes de cambio pendientes. Por el contrario, en un sistema completamente inactivo, las interrupciones de VSync se suspenden hasta que aparezcan nuevas actividades de presentación o agentes de escucha VSync.

Para manejar todos estos casos, se introdujeron la siguiente devolución de llamada del controlador y la estructura de devolución de llamada.

KMD proporciona un puntero a su función DxgkDdiSetInterruptTargetPresentId en DRIVER_INITIALIZATION_DATA

El sistema operativo llama a DxgkDdiSetInterruptTargetPresentId para especificar el PresentId de destino que debe dar lugar a una interrupción de VSync que se genera cuando se completa el volteo correspondiente. Esta función se invoca al nivel de interrupción del dispositivo (DIRQL) para sincronizarse con DxgkDdiSetVidPnSourceAddress y la interrupción de VSync.

Interacción con DxgkDdiControlInterrupt

Cuando las interrupciones de VSync se deshabilitan completamente a través de DxgkDdiControlInterrupt/DxgkDdiControlInterrupt2/DxgkDdiControlInterrupt3, permanecen deshabilitados independientemente del valor presentId de destino de interrupción. Se requiere que KMD almacene el identificador del destino de interrupción más reciente de modo que pueda respetarse cuando VSync se habilite de nuevo.

Cuando las interrupciones de VSync están habilitadas a través de DxgkDdiControlInterruptXxx, el identificador actual de destino de interrupción (pSetInterruptTargetPresentId) proporciona un control más específico de la siguiente manera:

  • Cuando el identificador actual de destino se establece en UINT64_MAX, no se requiere ninguna interrupción de VSync hasta que el identificador actual de destino vuelva a cambiar. Las interrupciones de VSync están deshabilitadas, pero KMD debe implementar el comportamiento DXGK_VSYNC_DISABLE_KEEP_PHASE para volver a habilitar las interrupciones.

  • Cuando el identificador actual de destino está establecido en 0, se requieren interrupciones para cada VSync.

  • Para cualquier otro valor de identificador presente, se generan interrupciones si el PresentId >examinado actualmente = InterruptTargetPresentId.

Cuando hay varios planos MPO disponibles, se debe elevar la interrupción de VSync si alguno de los planos lo requiere.

Desactivación de VSync en dos etapas con DxgkDdiSetInterruptTargetPresentId

Si la llamada del sistema operativo a DxgkDdiSetInterruptTargetPresentId establece un InterruptTargetPresentId en un plano que conduciría a deshabilitar completamente VSync en este VidPnSource, es decir, este plano era el último que mantenía VSync habilitado y ahora también deshabilita VSync. KMD debe deshabilitar las interrupciones de VSync, pero mantener la fase de VSync en el hardware habilitada (DXGK_VSYNC_DISABLE_KEEP_PHASE). Después de un período de tiempo determinado (normalmente equivalente a dos períodos de VSync), el sistema operativo seguirá con una llamada a DxgkDdiControlInterruptXxx con DXGK_VSYNC_DISABLE_NO_PHASE. Esta llamada garantiza que KMD tenga la oportunidad de deshabilitar la fase de VSync y los ciclos de reloj de VSync para lograr el máximo ahorro de energía y mantener la paridad de rendimiento con los sistemas sin cola de cambio por hardware.

Cancelación de volteo en cola

En casos como las transiciones de estado de pantalla completa o las salidas de la aplicación, es posible que sea necesario cancelar los volteos en cola futuros. Para controlar estos casos, se introdujeron las siguientes estructuras relacionadas y la devolución de llamada del controlador:

KMD proporciona un puntero a su función DxgkDdiCancelFlips en DRIVER_INITIALIZATION_DATA.

El sistema operativo especifica el intervalo de volteos en cola para cancelar cuando llama a DxgkDdiCancelFlips y KMD informa de nuevo al sistema operativo el intervalo de volteos que pudo cancelar de forma sincrónica.

En el ejemplo siguiente se muestran los mecanismos y el caso sincrónico de cancelación de volteo en un solo plano. (El sistema operativo no admite la cancelación asincrónica en Windows 11, versión 22H2). Imagine que los siguientes volteos se ponen en cola en la cola de volteo de hardware:

  • PresentId N
  • time t0 PresentId N+1
  • time t1 PresentId N+2
  • time t2 PresentId N+3
  • time t3 PresentId N+4
  • tiempo t4

A continuación, el sistema operativo decide cancelar los volteos N+2, N+3 y N+4, por lo que llama a DxgkDdiCancelFlips con PresentIdCancelRequested establecido en N+2.

Cuando KMD inspecciona el estado de la cola de volteo de hardware, determina lo siguiente:

  • Flip N+2 ya se ha enviado al hardware de visualización y no se puede cancelar en el momento de efectuar la llamada.
  • Los volteos N+3 y N+4 se pueden quitar sincrónicamente de la cola de volteo de hardware sin efectos secundarios.

Como resultado, KMD establece PresentIdCancelled en N+3 y completa N+2 como de costumbre.

El sistema operativo marca N+3 y N+4 como cancelado, y trata N, N+1, N+2 como en vuelo. Cuando se generen las siguientes interrupciones de VSync, el registro de cola invertida indicará las marcas de tiempo de N, N+1, N+2 como de costumbre.

El intervalo de volteos cancelados sincrónicamente debe ser continuo y, cuando no cero, se supone que incluye el último identificador presente enviado a KMD. En otras palabras, no puede haber huecos dentro de ambos intervalos de volteo cancelados sincrónicos.

Cancelación de volteos interbloqueados en varios planos

Un volteo interbloqueado se envía llamando a DxgkDdiSetVidPnSourceAddress con varios planos y PresentIds. El contrato entre el sistema operativo y el KMD sigue:

  • El conjunto de planos debe estar visible en la misma VSync.
  • El hardware de visualización no tiene permitido mostrar solo un subconjunto de estos planos en una sincronización vertical y el resto en la siguiente sincronización vertical.

En el modelo de cola de volteo de hardware, estos volteos interbloqueados se cancelan pasando un array de planos y PresentIds en la llamada a DxgkDdiCancelFlips. El conjunto de planos pasados en tales casos debe corresponder a una solicitud de volteo interbloqueada pendiente y la decisión de KMD con respecto a todos los PresentId interbloqueados debe ser la misma:

  • No cancele o
  • Cancelar sincrónicamente

DxgkDdiCancelFlips se llama en el nivel de interrupción del dispositivo (DIRQL) para sincronizar con DxgkDdiSetVidPnSourceAddress y la interrupción VSync.

Obtención de estadísticas actuales para operaciones en cola

Dado que el enfoque de cola de volteo de hardware es evitar despertar la CPU en cada VSync, debe haber un mecanismo para conservar los tiempos de visualización de fotogramas para los últimos volteos en cola.

Los controladores gráficos que admiten la cola de volteo por hardware deben escribir información en el búfer de registro de la cola de volteo proporcionado por el sistema operativo para cada volteo completado o cancelado en un plano MPO determinado para cada VidPnSource activo.

El sistema operativo garantiza proporcionar el puntero de registro de cola invertida (en una llamada a DxgkDdiSetFlipQueueLogBuffer) antes de la primera llamada de DxgkDdiSetVidPnSourceAddress para un plano MPO determinado para cada VidPnSource activo. El sistema operativo puede destruir el búfer del log de la cola de intercambio cuando la cola de intercambio no tiene solicitudes pendientes. En este caso, proporcionará un nuevo puntero del registro antes de la siguiente llamada a DxgkDdiSetVidPnSourceAddress. El registro de cola invertida es circular. Una vez escrita la entrada [NumberOfEntries-1], la siguiente entrada de registro es [0].

Una vez completado un lote de volteos en cola, KMD tiene que garantizar que el registro de cola de volteos completados se actualice a la menor de estos dos puntos en el tiempo:

  • Un controlador de interrupción de VSync para un volteo que requería que se genere una interrupción.
  • En respuesta a una solicitud dxgkDdiUpdateFlipQueueLog explícita del sistema operativo.

DDIs de registro de colas de volteo

Se agregaron las siguientes devoluciones de llamada relacionadas con el registro de cola invertida y las estructuras asociadas:

KMD proporciona un puntero a sus funciones en DRIVER_INITIALIZATION_DATA.

Actualizaciones de la estructura de interrupción de VSync

Se realizaron los siguientes cambios en la estructura DXGKARGCB_NOTIFY_INTERRUPT_DATA para implementar interrupciones VSync para el modelo de cola de cambio de hardware.

  • El valor de enumeración DXGK_INTERRUPT_CRTC_VSYNC_WITH_MULTIPLANE_OVERLAY3 se agregó como InterruptType.
  • La estructura CrtcVSyncWithMultiPlaneOverlay3 se agregó a la unión. La semántica de CrtcVSyncWithMultiPlaneOverlay3 es similar a la estructura CrtcVSyncWithMultiPlaneOverlay2 existente, excepto que, en lugar de un único presentId completado por última vez para cada plano, CrtcVSyncWithMultiPlaneOverlay3.pMultiPlaneOverlayVSyncInfo apunta al intervalo de PresentIds no notificados previamente desde el registro de cola de volteo.
  • La estructura DXGK_MULTIPLANE_OVERLAY_VSYNC_INFO3 se agregó para el miembro pMultiPlaneOverlayVSyncInfo de CrtcVSyncWithMultiPlaneOverlay3.

Vuelva a usar el diagrama de ejemplo de cola de volteo de hardware básico :

Diagrama que muestra el mecanismo básico de cola de volteo de hardware.

Supongamos que FirstFreeFlipQueueLogEntryIndex se estableció en 40 en el momento en que se envió el flip N y, a continuación, se completaron las presentaciones N, N+1 y N+2.

Después de que una configuración de un solo plano completa tres PresentIds N, N+1 y N+2 en los momentos respectivos v2, v3, v4, KMD ha escrito tres entradas nuevas en su buffer de registros de cola de inversión con índices 40, 41 y 42. KMD informa de un valor FirstFreeFlipQueueLogEntryIndex de 43 en la estructura CrtcVSyncWithMultiPlaneOverlay3. El sistema operativo observa que FirstFreeFlipQueueLogEntryIndex cambió de 40 a 43 y lee de las entradas de registro 40, 41 y 42. KMD debe establecer los siguientes valores del búfer de registro de flip queue como se indica a continuación:

  • VidPnTargetId: el mismo significado que en CrtcVSyncWithMultiPlaneOverlay2

  • PhysicalAdapterMask: el mismo significado que en 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

Solicitud explícita de actualización del registro de cola de volteo

Hay casos en los que el sistema operativo necesita obtener información sobre el último lote completado de volteos sin tener que esperar a la interrupción de VSync. En tales casos, el sistema operativo realiza una llamada explícita a DxgkDdiUpdateFlipQueueLog para solicitar que KMD lea de su estructura de datos de hardware propietaria y escriba información de cambios anteriores en el registro de la cola de cambios. La semántica del registro es la misma que se ha descrito anteriormente; el único cambio es que FirstFreeFlipQueueLogEntryIndex se devuelve al sistema operativo fuera de la interrupción de VSync.

DxgkDdiUpdateFlipQueueLog se llama en el nivel de interrupción del dispositivo (DIRQL) y se encuentra en la misma clase de sincronización que DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3 DDI.

Mostrar cambios en el modo y transiciones de energía en presencia de un volteo en cola en la cola de volteo de hardware

Dxgkrnl garantiza que los volteos ya en cola en la cola de volteo de hardware se completan o cancelan antes de iniciar un cambio de modo o apagar el monitor.

Asignación de solicitudes presentes a marcas de tiempo de cola invertida de hardware

Cuando la cola de intercambio de hardware está habilitada en un adaptador determinado, una marca de tiempo acompaña a todas las llamadas de intercambio. En otras palabras, KMD no necesita gestionar una combinación de semánticas antiguas y nuevas de DxgkDdiSetVidPnSourceAddress.

El sistema operativo convierte automáticamente las solicitudes de present API basadas en intervalos existentes en llamadas de volteo basadas en marca de tiempo a KMD. En las secciones siguientes se describen varios casos y cómo se asignan a una combinación de Duración, banderas y marcas de tiempo recibidas por KMD.

Semántica de desgarro y desenlazamiento

La semántica de volteos de desgarro es conceptualmente la misma cuando se habilita la cola de volteo de hardware. Una vez alcanzado TargetFlipTime , KMD debe enviar el volteo para mostrarse mientras sigue respetando marcas como FlipImmediate, FlipImmediateNoTeAring y FlipOnNextVSync. En otras palabras, KMD debe comportarse como si el sistema operativo le hubiera enviado el volteo exactamente a TargetFlipTime con las mismas banderas de volteo y los mismos parámetros de volteo.

Por ejemplo, si FlipOnNextVSync está establecido en 1 y TargetFlipTime está en medio del fotograma, el cambio solo debería mostrarse en el siguiente VSync.

Compatibilidad con FlipOverwrite y cola de volteo de hardware

La cola de volteo de hardware es un superconjunto estricto de la característica de sobrescritura de volteo controlada por el valor MaxQueuedMultiPlaneOverlayFlipVSync en DXGK_DRIVERCAPS.

Por lo tanto, el sistema operativo omite el valor maxQueuedMultiPlaneOverlayFlipVSync si el controlador opta por la cola de volteo de hardware estableciendo MaxHwQueuedFlips en un valor mayor que 1.

Volteos múltiples con un TargetFlipTime expirado

Cuando hay varios volteos en lista de espera con un TargetFlipTime expirado para un plano MPO determinado, la cola de visualización de hardware debe seleccionar el volteo expirado en lista de espera más reciente y enviarlo a la pantalla. El resto de los flips expirados deben tratarse como cancelados y las entradas correspondientes del registro de cola de flips deben contener DXGK_HWFLIPQUEUE_TIMESTAMP_CANCELLED como los valores de PresentTimestamp.

Interacción entre Duration y TargetFlipTime

El parámetro Duration de la estructura DXGKARG_SETVIDPNSOURCEADDRESSWITHMULTIPLANEOVERLAY3 debe surtir efecto cuando el volteo especificado en esta estructura se muestra en la pantalla. Especifica el nuevo comportamiento de frecuencia de actualización de visualización deseada para la salida especificada por VidPnSourceId en todos los planos. En las versiones WDDM 3.1 y Windows Server 2022, con el fin de simplificar la implementación del controlador para el hardware que no admite cambios personalizados en la cola, el sistema operativo solo envía solicitudes de cambio con un parámetro nuevo de Duration una vez que se completen las solicitudes de cambio anteriores.

Asignación de intervalos presentes a TargetFlipTime

Mapeo de intervalos cuando la frecuencia de actualización es fija

Para conservar la semántica del intervalo presente, el sistema operativo debe calcular el tiempo objetivo de cambio utilizando el intervalo presente y la frecuencia de actualización. Sin embargo, establecer el tiempo de volteo de destino exactamente en el momento de la sincronización de VSync previsto en el que el volteo debería alcanzar la pantalla da lugar a errores frecuentes. Estos fallos se deben a la pérdida de VSync cuando el tiempo de VSync real se desajusta ligeramente. Para protegerse contra fallos, el sistema operativo resta la mitad del intervalo de VSync del tiempo de volteo objetivo calculado.

Esta es una fórmula simplificada para asignar el intervalo actual al tiempo de volteo de destino:

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

Mapeo de intervalos cuando está presente la característica de frecuencia de actualización virtual WDDM 2.9

La característica de frecuencia de actualización virtual podría aumentar temporalmente la frecuencia de actualización de pantalla a un número entero múltiplo de la frecuencia de actualización actual (es decir, 24 Hz se puede aumentar a 144 Hz o 192 Hz). Para los dispositivos que son capaces de admitir este aumento, la fórmula de la sección anterior se modifica para usar el múltiplo más rápido de la frecuencia de actualización actual:

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

Mapeo de intervalos cuando la frecuencia de actualización se cambia a una que no es múltiplo.

Cuando la frecuencia de actualización cambia a una nomultipla de una frecuencia de actualización actual (por ejemplo, de 24 Hz a 60 Hz), el sistema operativo debe inspeccionar las colas para ver si su tiempo de destino calculado sigue siendo válido para la nueva frecuencia de actualización. Si es necesario cambiar el tiempo objetivo, el sistema operativo cancela los volteos en cola y los recoloca con los tiempos objetivo recién calculados.