Cola de prerenderización de hardware
En este artículo se describe la característica de cola de prerenderización 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 menor consumo de energía mientras el controlador de pantalla está procesando varios fotogramas en cola, lo que mejora la eficacia energética cuando se reproduce vídeo en hardware compatible.
Modelo de cola de prerenderización de WDDM 3.0 anterior
Muchos controladores de pantalla modernos admiten la opción de poner en cola varios fotogramas que se van a mostrar en una secuencia. A partir de WDDM 2.1, el sistema operativo admite varias solicitudes de sobreescritura pendientes que se van a presentar en la siguiente VSync. El controlador 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 juegos con fotogramas muy rápidos en los que varios fotogramas se renderizan secuencialmente con el intervalo 0, con la intención de mostrar solo el fotograma más reciente.
Cuando se reproduce vídeo, el contenido de varios futuros fotogramas que se vayan a mostrar secuencialmente se conoce de antemano y se puede poner en cola en la GPU. Esta sistema avanzado de puesta en cola permite que la CPU active un estado de bajo consumo de energía mientras se procesan los fotogramas en cola, lo que da lugar a un ahorro considerable 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 prerenderización básica de hardware presenta una solución que permite a la CPU entrar en un estado de bajo consumo de energía y descargar el procesamiento de fotogramas en cola en la GPU.
Cuando se ejecutaban juegos antes de salir WDDM 3.0, después de que la GPU terminara de renderizar la escena en el búfer de reserva de cadena de intercambio, se producía un ciclo de ida y vuelta en la CPU para enviar la solicitud para presentar el contenido del fotograma en pantalla. En el caso de cargas de trabajo de GPU pesadas que terminan cerca de la VSync, este recorrido de ida y vuelta puede provocar que los fotogramas se retrasen y pierdan el tiempo de destino previsto, lo que da lugar a problemas de fotogramas observables. 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. Para la cola de prerenderización avanzada de hardware se necesita que estén presentes tanto la cola de prerenderización básica de hardware como la funcionalidad de fase 2 de programación de hardware de la GPU.
Cola de prerenderización básica de hardware
En el diagrama siguiente se muestra un ejemplo de presentación de tres fotogramas, cada una de los cuales permanece en pantalla en el intervalo de VSync.
El patrón de relleno del diagrama muestra las veces en que el procesamiento de cola de prerenderización de software de Dxgkrnl y los subprocesos de aplicación tienen que activarse y realizar el trabajo de la CPU. En cada VSync, el controlador de pantalla tiene que enviar una notificación de la CPU al sistema operativo cuando se completa la prerenderización y el sistema operativo tiene que enviar la siguiente solicitud de prerenderización. La aplicación también tiene que activarse en cada VSync y consultar las estadísticas presentes para conocer después cuando aparece el último fotograma del lote de tres.
Las DDI de cola de prerenderización de hardware que pueden enviar varios fotogramas futuros a la cola del controlador de pantalla 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.
Con el método de cola de prerenderización de hardware, tanto la aplicación como los componentes de CPU de Dxgkrnl están totalmente inactivos en dos intervalos de VSync entre espacios de tiempo de v2 y v4, lo que permite que la CPU entre en un estado de bajo consumo de energía. A la CPU solo se le informa del momento en que se completa el fotograma N+2 que la aplicación solicitó en una tarea de espera.
Cola de prerenderización avanzada de hardware
Cuando se ejecutaban juegos antes de salir WDDM 3.0, después de que la GPU terminara de renderizar la escena en el búfer de reserva de cadena de intercambio, se producía un ciclo de ida y vuelta en la CPU para enviar la solicitud para presentar el contenido del fotograma en pantalla. El siguiente diagrama refleja este escenario.
El coste de este ciclo de ida y vuelta puede hacer que los fotogramas se pierdan si la prerenderización ha finalizado demasiado cerca de la VSync, tal como se muestra en el diagrama siguiente.
Algunos controladores de pantalla admiten de forma nativa las condiciones de espera que permiten que la pantalla envíe la solicitud de prerenderización una vez que la GPU ha terminado de renderizar el fotograma sin el ciclo de ida y vuelta de la 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.
En los últimos puntos de este artículo se habla sobre la característica de cola de prerenderización básica de hardware.
Soporte técnico de DDI
Se han agregado las siguientes DDI para admitir la característica de cola de prerenderización de hardware.
Comprobación de disponibilidad de la característica
Para la cola de prerenderización de hardware, se necesita que el sistema operativo habilite o deshabilite la negociación. El KMD que admita la cola de prerenderización de hardware debe llamar primero a DXGKCB_QUERYFEATURESUPPORT durante el momento de inicio del dispositivo con un FeatureId de DXGK_FEATURE_HWFLIPQUEUE para determinar si el sistema operativo permite habilitar la cola de prerenderización de hardware.
La cola de prerenderización de hardware solo se puede usar si la devolución de llamada se realiza correctamente y Enable tiene el valor TRUE.
El KMD puede usar el código de ejemplo siguiente durante las fases experimentales y de activación de la cola de prerenderización 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 activación del controlador, aunque es posible habilitar la cola de prerenderización de hardware sin habilitar la programación de hardware de GPU, esta combinación no se acepta oficialmente. Actualmente, Windows necesita que la programación de hardware de GPU esté habilitada para activar la cola de prerenderización básica de hardware en controladores publicados oficialmente.
Indicaciones de funcionalidades de puesta en cola de hardware
MaxHwQueuedFlips se ha agregado a DXGK_DRIVERCAPS para indicar la compatibilidad con colas de prerenderización de hardware. Si el sistema operativo permitía compatibilidad con colas invertidas de hardware como se ha descrito 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, el KMD indicará que el hardware de pantalla admite hasta MaxHwQueuedFlips fotogramas futuros que se pueden poner en cola para que aparezcan en 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 ha agregado a DXGK_DRIVERCAPS. Este miembro está reservado actualmente para uso del sistema; los controladores no deben usarlo.
Tiempo de destino de prerenderización y formato de marca de tiempo de destino
Cuando el sistema operativo envía una solicitud de prerenderización a la cola de prerenderización de hardware, también envía el tiempo de destino de prerenderización. El volteo se puede hacer visible al usuario después de alcanzar el tiempo de volteo de destino.
El sistema operativo usa las unidades de contador del reloj de la CPU, obtenidas de KeQueryPerformanceCounter, para pasar el tiempo de destino del fotograma e interpretar el tiempo real del fotograma.
Envío de prerenderizaciones en cola
La estructura DXGKARG_SETVIDPNSOURCEADDRESSWITHMULTIPLANEOVERLAY3, que se pasa a la función de devolución de llamada DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3, de KMD se ha modificado de la siguiente manera para habilitar el envío de prerenderizaciones en cola:
Los tres miembros siguientes se han agregado en OutputFlags a la estructura DXGK_SETVIDPNSOURCEADDRESS_OUTPUT_FLAGS. Consulte Casos de reintento y error de DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3 para saber más sobre estos miembros.
- HwFlipQueueDrainNeeded
- HwFlipQueueDrainAllPlanes
- HwFlipQueueDrainAllSources
Se ha agregado un miembro TargetFlipTime. TargetFlipTime describe el tiempo de destino de prerenderización en unidades QPC. Cuando el reloj alcanza este valor, el fotograma se puede enviar a la pantalla mientras se respeten el VSync y los avisos de rasgado de imagen. En presencia de prerenderizaciones pendientes previamente en cola, el sistema operativo garantiza que para cada plano de MPO al que hace referencia la solicitud de prerenderización, TargetFlipTime es mayor o igual que cualquiera de los tiempos de destino de prerenderizaciones pendientes en este plano. En otras palabras, puede haber una secuencia de prerenderizaciones con las mismas marcas de tiempo o mayores, pero no puede haber una secuencia que vaya atrás en el tiempo.
Casos de reintento y error de DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3
Error al poner en cola la solicitud dirigida al hardware debido a prerenderizaciones 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, el KMD debe devolver STATUS_RETRY de DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3 y cambiar HwFlipQueueDrainNeeded a un valor 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, los indicadores HwFlipQueueDrainNeeded y HwFlipQueueDrainAllPlanes deben cambiarse a 1 y el KMD debe devolver STATUS_RETRY.
Del mismo modo, el hardware de visualización puede requerir la finalización de volteos pendientes en todos los orígenes vidPn con el fin de reasignar los recursos internos, en cuyo caso se deben establecer las marcas HwFlipQueueDrainAllSources y HwFlipQueueDrainNeeded , y KMD debe devolver STATUS_RETRY.
Además, el KMD puede indicar al sistema operativo si el reenvío debe realizarse en el IRQL del dispositivo (PrePresentNeeded con valor 0), o si el sistema operativo debe realizar esta llamada en PASSIVE_LEVEL (PrePresentNeeded con valor 1). Si KMD sigue devuelve STATUS_RETRY aunque no haya más volteos pendientes en ese VidPnSourceId, esta condición se trata como un error de parámetro no válido.
Es importante que el valor de MaxHwQueuedFlips refleje el número máximo de prerenderizaciones sencilla con solo cambio de dirección que se pueden poner en cola en un plano de MPO. El mecanismo de STATUS_RETRY debe usarse para solicitudes de prerenderización más complejas que no se puedan poner en cola más abajo, como los cambios de configuración de planos.
Error de parámetro no válido
En el modelo de cola de prerenderización de hardware, se ha modificado el control del sistema operativo sobre las solicitudes de prerenderización con errores para permitir una mejor depuración. Cuando el KMD no puede procesar una solicitud de prerenderización, 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:
- Comprobación de errores y interrupción del depurador de kernel: este comportamiento suele habilitarse en compilaciones de desarrollo o versión preliminar para mejorar la depuración a medida que se produce la condición de error.
- Volcado de kernel activo seguido de un TDR: la acción del usuario final comercial.
Especificación del proceso de interrupción de VSync
Para lograr ahorros de energía en escenarios de volteo en cola, el sistema operativo suele suspender interrupciones normales 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 volteo pendientes. Por el contrario, en un sistema completamente inactivo, las interrupciones de VSync se suspenden hasta que aparezcan nuevas operaciones de presentación o agentes de escucha de VSync.
Para hacer frente a todas estas situaciones, se ha incorporado la siguiente estructura de devolución de llamada y devolución de llamada del controlador:
KMD genera un puntero a la 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 la prerenderización correspondiente. Esta función se llama en el nivel de interrupción del dispositivo (DIRQL) para sincronizar 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, sea cual sea el valor de PresentId de destino de la interrupción. Se necesita el KMD para almacenar el último Presentid actual de destino de la interrupción para que se aplique una vez que el VSync se vuelva a habilitar.
Cuando las interrupciones de VSync se habilitan a través de DxgkDdiControlInterruptXxx, el Presentid actual de destino de la interrupción (pSetInterruptTargetPresentId) permite tener un control más riguroso de la siguiente manera:
Cuando el ID de presentación actual de destino cambia a UINT64_MAX, no se requiere ninguna interrupción de VSync hasta que el ID de presentación actual de destino vuelva a cambiar. Las interrupciones de VSync están deshabilitadas, pero se necesita el KMD para implementar la operación DXGK_VSYNC_DISABLE_KEEP_PHASE para volver a habilitar las interrupciones.
Cuando el ID de presentación actual de destino está en 0, son necesarias las interrupciones en cada VSync.
Con cualquier otro valor de ID de presentación, se generan interrupciones si el PresentId examinado en ese momento es >= InterruptTargetPresentId.
Cuando hay varios planos de MPO disponibles, se debe generar la interrupción de VSync si alguno de los planos lo requiere.
Deshabilitación de VSync en 2 fases con DxgkDdiSetInterruptTargetPresentId
Si la llamada del sistema operativo a DxgkDdiSetInterruptTargetPresentId establece un Objeto InterruptTargetPresentId en un plano que provocaría deshabilitar VSync completamente en este VidPnSource (es decir, este plano era el último plano que mantuvo habilitado VSync y ahora este plano también está deshabilitando VSync), KMD debe deshabilitar las interrupciones de VSync, pero mantener la fase VSync en hardware habilitado (DXGK_VSYNC_DISABLE_KEEP_PHASE). Tras un espacio de tiempo determinado (normalmente equivalente a dos períodos de VSync), el sistema operativo seguirá esto con una llamada a DxgkDdiControlInterruptXxx con DXGK_VSYNC_DISABLE_NO_PHASE. Esta llamada garantiza que KMD tenga la oportunidad de deshabilitar las fases de VSync y los relojes VSync para ahorrar potencia máxima y mantener la paridad de rendimiento con sistemas de cola invertida sin particiones.
Cancelación de prerenderizaciones 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 las futuras prerenderizaciones en cola. Para estos casos, se han incluido la siguiente devolución de llamada del controlador y sus estructuras relacionadas:
KMD genera un puntero a la función DxgkDdiCancelFlips en DRIVER_INITIALIZATION_DATA.
El sistema operativo indica el intervalo de prerenderizaciones en cola que se van a cancelar cuando llama a DxgkDdiCancelFlips y el KMD informa de nuevo al sistema operativo el rango de prerenderizaciones que pudo cancelar de forma sincrónica.
En el ejemplo siguiente se muestran los mecanismos y el caso sincrónico de cancelación de prerenderizaciones en un solo plano. (El sistema operativo no admite la cancelación asincrónica en la versión 22H2 de Windows 11). Imagine que las siguientes prerenderizaciones se ponen en cola en la cola de prerenderización de hardware:
- PresentId N
- time t0 PresentId N+1
- time t1 PresentId N+2
- time t2 PresentId N+3
- time t3 PresentId N+4
- time t4
A continuación, el sistema operativo decide cancelar las prerenderizaciones N+2, N+3 y N+4, para que llame a DxgkDdiCancelFlips con PresentIdCancelRequested con valor 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 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 de prerenderización indicará las marcas de tiempo de N, N+1, N+2 como siempre.
El rango de prerenderizaciones canceladas sincrónicamente debe ser continuo y, cuando no es cero, se supone que incluye el último ID de presentación enviado a KMD. En otras palabras, no puede haber huecos dentro de ambos rangos de prerenderizaciones canceladas de forma sincrónica.
Cancelación de prerenderizaciones interbloqueadas en varios planos
Una prerenderización interbloqueada se envía llamando a DxgkDdiSetVidPnSourceAddress con varios planos y PresentIds. El contrato entre el sistema operativo y el KMD es el siguiente:
- El conjunto de planos debe estar visible en la misma VSync.
- El hardware de pantalla no solo puede mostrar un subconjunto de estos planos en una VSync y el resto en la siguiente VSync.
En el modelo de cola de prerenderización de hardware, estas prerenderizaciones interbloqueadas se cancelan pasando varios planos y PresentIds en la llamada a DxgkDdiCancelFlips. El conjunto de planos pasados en tales casos debe corresponderse con una solicitud de prerenderización interbloqueada pendiente y la decisión del KMD con respecto a todos los PresentId interbloqueados debe ser la misma:
- No cancelar o
- Cancelar sincrónicamente
Se llama a DxgkDdiCancelFlips en la interrupción del dispositivo (DIRQL) para sincronizarlo con DxgkDdiSetVidPnSourceAddress y la interrupción de VSync.
Obtención de estadísticas presentes para prerenderizaciones en cola
Como lo que se pretende con las colas de prerenderización de hardware es evitar reactivar la CPU en cada VSync, debe haber un mecanismo para conservar los tiempos de visualización de fotogramas para las últimas prerenderizaciones en cola.
Los controladores gráficos que admiten cola de volteo de hardware deben escribir información en el búfer de registro de cola de volteo proporcionado por el sistema operativo para cada volteo completado o cancelado para 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 registro de cola de prerenderización cuando la cola de prerenderización no tiene solicitudes pendientes. En este caso, proporcionará un nuevo puntero de registro antes de la siguiente llamada a DxgkDdiSetVidPnSourceAddress . El registro de cola de prerenderización es circular. Una vez escrita la entrada [NumberOfEntries-1], la siguiente entrada de registro es [0].
Una vez completado un lote de prerenderizaciones en cola, el KMD tiene que garantizar que el registro de cola de prerenderización de las prerenderizaciones completadas se actualice al principio de estos dos momentos en el tiempo:
- Un controlador de interrupción de VSync para una prerenderización que requiere que se genere una interrupción.
- En respuesta a una solicitud explícita DxgkDdiUpdateFlipQueueLog del sistema operativo.
DDI de registro de colas de prerenderización
Se han agregado las siguientes devoluciones de llamada relacionadas con el registro de cola de prerenderización y las estructuras asociadas:
El KMD incluye un puntero a sus funciones en DRIVER_INITIALIZATION_DATA.
Cambios en la estructura de interrupción de VSync
Se han realizado los siguientes cambios en la estructura DXGKARGCB_NOTIFY_INTERRUPT_DATA para implementar interrupciones de VSync en el modelo de cola de prerenderización de hardware:
- El valor de enumeración DXGK_INTERRUPT_CRTC_VSYNC_WITH_MULTIPLANE_OVERLAY3 se ha agregado como InterruptType.
- La estructura CrtcVSyncWithMultiPlaneOverlay3 se ha agregado 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 en cada plano, CrtcVSyncWithMultiPlaneOverlay3.pMultiPlaneOverlayVSyncInfo apunta al rango de PresentIds no constatados previamente en el registro de cola de prerenderización.
- La estructura DXGK_MULTIPLANE_OVERLAY_VSYNC_INFO3 se ha agregado para CrtcVSyncWithMultiPlaneOverlay3 en el miembro pMultiPlaneOverlayVSyncInfo.
Uso del diagrama de ejemplo de Cola de prerenderización de hardware básica:
Supongamos que FirstFreeFlipQueueLogEntryIndex se ha cambiado a 40 en el momento en que se envió la prerenderización N y se completaran luego los N, N+1, N+2 presentes.
Después de completar una configuración de un solo plano, tres PresentIds N, N+1 y N+2 en las respectivas veces v2, v3, v4, KMD ha escrito tres entradas nuevas en su búfer de registro de cola invertida con índices 40, 41 y 42. El KMD informa del valor 43 de FirstFreeFlipQueueLogEntryIndex 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. El KMD debe ajustar los siguientes valores de búfer de registro de cola de prerenderización, tal 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 cambio del registro de cola de prerenderización
Hay casos en los que el sistema operativo necesita obtener información sobre el último lote completado de prerenderizaciones 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 el KMD lea en su estructura de datos de hardware propia y escriba la información anterior de la prerenderización en el registro de colas de prerenderización. 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.
Se llama a DxgkDdiUpdateFlipQueueLog en la interrupción del dispositivo (DIRQL) y se encuentra en la misma clase de sincronización que la DDI DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3.
Cambios en el modo de pantalla y transiciones de consumo de energía en presencia de una prerenderización en cola en la cola de prerenderización 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 de prerenderización de hardware
Cuando la cola de volteo de hardware está habilitada en un adaptador determinado, una marca de tiempo acompaña a todas las llamadas de volteo. En otras palabras, KMD no necesita controlar una combinación de la semántica de DxgkDdiSetVidPnSourceAddress antiguas y nuevas.
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 varios indicadores, Duration y marcas de tiempo recibidas por el KMD.
Semántica de desgarro y desenlazamiento
La semántica de prerenderizaciones de desgarros es conceptualmente la misma cuando se habilita la cola de prerenderización de hardware. Una vez alcanzado el TargetFlipTime, el KMD debe enviar la prerenderización a la pantalla mientras sigue respetando indicadores como FlipImmediate, FlipImmediateNoTearing y FlipOnNextVSync. En otras palabras, el KMD debe comportarse como si el sistema operativo enviara la prerenderización exactamente en TargetFlipTime con los mismos indicadores y parámetros de prerenderización.
Por ejemplo, si FlipOnNextVSync está establecido en 1 y TargetFlipTime está en medio del marco, el volteo solo debe mostrarse en la siguiente VSync.
Compatibilidad con FlipOverwrite y cola de prerenderización de hardware
La cola de prerenderización de hardware es un superconjunto estricto de la función de sobreescritura de prerenderizaciones controlada por el valor MaxQueuedMultiPlaneOverlayFlipVSync en DXGK_DRIVERCAPS.
Por tanto, el sistema operativo omite el valor MaxQueuedMultiPlaneOverlayFlipVSync si el controlador entra en la cola de prerenderización de hardware cambiando MaxHwQueuedFlips a un valor mayor que 1.
Varias prerenderizaciones con un TargetFlipTime vencido
Cuando hay varias prerenderizaciones en cola con un TargetFlipTime vencido en un plano de MPO determinado, la cola de visualización de hardware debe seleccionar la prerenderización en cola vencida más reciente y enviarla para mostrarla. El resto de las prerenderizaciones vencidas deben considerarse canceladas y las entradas correspondientes del registro de cola de prerenderización deben incluir DXGK_HWFLIPQUEUE_TIMESTAMP_CANCELLED como los valores de PresentTimestamp.
Interacción entre Duration y TargetFlipTime
El parámetro Duration en la estructura DXGKARG_SETVIDPNSOURCEADDRESSWITHMULTIPLANEOVERLAY3 debe surtir efecto cuando la prerenderización especificada en esta estructura se muestra en pantalla. Señala el nuevo modo de frecuencia de actualización de pantalla deseado para la salida indicada 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 cola, el sistema operativo solo envía solicitudes de volteo con un nuevo parámetro Duration después de que se completen las solicitudes de volteo anteriores.
Asignación de intervalos presentes a TargetFlipTime
Asignación de intervalos cuando se fija la frecuencia de actualización
Para conservar la semántica del intervalo actual, el sistema operativo debe calcular el tiempo de prerenderización de destino mediante el intervalo actual 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 problemas se deben a la sincronización virtual perdida cuando el tiempo de sincronización de VSync real se desfase un poco. Para protegerse contra errores, el sistema operativo resta la mitad del intervalo de VSync del tiempo de prerenderización de destino calculado.
Esta es una fórmula simplificada para asignar el intervalo actual al tiempo de prerenderización de destino:
TargetFlipTime = PreviousFlipStartVSyncTime + (PreviousFlipPresentInterval * FixedRefreshRate) - (FixedRefreshRate / 2)
Asignación de intervalos cuando la funcionalidad WDDM 2.9 de frecuencia de actualización virtual está presente
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 aceptar este incremento, 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)
Intervalos de asignación cuando se cambia la frecuencia de actualización a una nomultiple
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 de volteo de destino, el sistema operativo cancela los volteos en cola y los vuelve a poner en cola con los tiempos de volteo de destino recién calculados.