QQuickGraphicsConfiguration Class

Descripción Detallada

La clase QQuickGraphicsConfiguration es un contenedor para configuraciones gráficas de bajo nivel que pueden afectar a cómo la API gráfica subyacente, como Vulkan, es inicializada por el gráfico de escena Qt Quick. También puede controlar ciertos aspectos del renderizador del gráfico de escena.

Configuración para motores de renderizado externos o API XR

Cuando se construye y muestra un QQuickWindow que utiliza Vulkan para renderizar, una instancia Vulkan (VkInstance), un dispositivo físico (VkPhysicalDevice), un dispositivo (VkDevice) y los objetos asociados (colas, pools) se inicializan a través de la API Vulkan. Lo mismo ocurre cuando se utiliza QQuickRenderControl para redirigir el renderizado a un objetivo de renderizado personalizado, como una textura. Mientras que la construcción de QVulkanInstance está entonces bajo el control de la aplicación, la inicialización de otros objetos gráficos ocurre de la misma manera en QQuickRenderControl::initialize() que con un QQuickWindow en pantalla.

Para la mayoría de las aplicaciones no es necesaria ninguna configuración adicional porque Qt Quick proporciona valores predeterminados razonables para muchos ajustes gráficos de bajo nivel, por ejemplo, qué extensiones de dispositivo habilitar.

Sin embargo, esto no siempre será suficiente. En casos de uso avanzado, cuando se integra directamente Vulkan u otro contenido de API de gráficos, o cuando se integra con un motor 3D o VR externo, como OpenXR, la aplicación querrá especificar su propio conjunto de ajustes cuando se trata de detalles, como qué extensiones de dispositivo habilitar.

Esto es lo que permite esta clase. Permite especificar, por ejemplo, una lista de extensiones de dispositivo que luego es recogida por el gráfico de escena cuando se utiliza Vulkan, o APIs gráficas donde el concepto es aplicable. Cuando algunos conceptos no son aplicables, los ajustes relacionados simplemente se ignoran.

Ejemplos de funciones en esta categoría son setDeviceExtensions() y preferredInstanceExtensions(). Esta última es útil cuando la aplicación gestiona su propio QVulkanInstance que luego se asocia con el QQuickWindow a través de QWindow::setVulkanInstance().

Qt Quick Configuración del renderizador de gráficos de escena

Otra clase de configuraciones están relacionadas con el renderizador del gráfico de escena. En algunos casos las aplicaciones pueden querer controlar cierto comportamiento, como el uso del buffer de profundidad cuando se renderiza contenido 2D. En Qt 5 tales ajustes no eran controlables en absoluto, o se gestionaban a través de variables de entorno. En Qt 6, QQuickGraphicsConfiguration proporciona un nuevo hogar para estos ajustes, manteniendo el soporte para las variables de entorno heredadas, cuando sea aplicable.

Un ejemplo en esta categoría es setDepthBufferFor2D().

Configuración de dispositivos gráficos

Cuando la instancia gráfica y los objetos de dispositivo (por ejemplo, el VkInstance y VkDevice con Vulkan, el ID3D11Device con Direct 3D, etc.) son creados por Qt al inicializar un QQuickWindow, hay ajustes que las aplicaciones o librerías querrán controlar bajo ciertas circunstancias.

Antes de Qt 6.5, algunos de estos ajustes estaban disponibles para ser controlados mediante variables de entorno. Por ejemplo, QSG_RHI_DEBUG_LAYER o QSG_RHI_PREFER_SOFTWARE_RENDERER. Éstas todavía están disponibles y continúan funcionando como antes. QQuickGraphicsConfiguration proporciona además setters en C++.

Por ejemplo, la siguiente función main() abre un QQuickView mientras especifica que la validación Vulkan o la capa de depuración Direct3D deben estar habilitadas:

int main(int argc, char *argv[])
{
    QGuiApplication app(argc, argv);

    QQuickGraphicsConfiguration config;
    config.setDebugLayer(true);

    QQuickView *view = new QQuickView;
    view->setGraphicsConfiguration(config);

    view->setSource(QUrl::fromLocalFile("myqmlfile.qml"));
    view->show();
    return app.exec();
}

Almacenamiento y carga de caché de tuberías

Qt Quick soporta el almacenamiento de la caché del pipeline gráfico/computacional en disco, y su recarga en posteriores ejecuciones de una aplicación. Qué contiene exactamente la caché de canalización, cómo funcionan las búsquedas y qué se acelera exactamente depende del backend RHI de Qt y de la API gráfica nativa subyacente que se utilice en tiempo de ejecución. Diferentes APIs 3D tienen diferentes conceptos cuando se trata de shaders, programas y objetos de estado de canalización, y los correspondientes mecanismos de caché. El concepto de caché de canalización de alto nivel abstrae todo esto al almacenamiento y recuperación de un único blob binario desde y hacia un archivo.

Cuando se encuentra el mismo programa de sombreado y/o estado de canalización que en una ejecución anterior, es probable que se omitan una serie de operaciones, lo que lleva a tiempos de inicialización de sombreado y material más rápidos, lo que significa que el inicio puede ser más rápido y que los retardos y "janks" durante el renderizado pueden reducirse o evitarse.

Cuando se ejecuta con una API gráfica en la que la recuperación y recarga de la caché del pipeline (o de los binarios de shaders/programas) no es aplicable o no está soportada, intentar utilizar un archivo para guardar y cargar la caché no tiene ningún efecto.

Hay excepciones al problema de la dependencia del controlador, sobre todo Direct 3D 11, donde la "pipeline cache" se utiliza sólo para almacenar los resultados de la compilación HLSL->DXBC en tiempo de ejecución y, por lo tanto, es independiente del dispositivo y del proveedor.

En algunos casos puede ser deseable mejorar la primera ejecución de la aplicación, "preconfigurando" la caché. Esto es posible enviando el archivo de caché guardado de una ejecución anterior, y referenciándolo en otra máquina o dispositivo. De este modo, la aplicación o el dispositivo dispone de los programas de sombreado y las líneas de comandos que se han encontrado anteriormente en la ejecución que guardó el archivo de caché durante su primera ejecución. Enviar y desplegar el archivo de caché sólo tiene sentido si el dispositivo y los controladores gráficos son los mismos en el sistema de destino; de lo contrario, el archivo de caché se ignora si el dispositivo o la versión del controlador no coinciden (con la excepción de D3D11), como se ha descrito anteriormente.

Una vez cargado el contenido de la caché, sigue existiendo la posibilidad de que la aplicación cree canalizaciones gráficas y de cálculo que no se hayan encontrado en ejecuciones anteriores. En estos casos la caché crece, con los pipelines / programas shader añadidos a ella. Si la aplicación también elige guardar los contenidos (quizás incluso en el mismo archivo), entonces se almacenarán tanto los pipelines antiguos como los nuevos. Cargar desde y guardar en el mismo archivo en cada ejecución permite una caché cada vez mayor que almacena todos los pipelines y programas shader encontrados.

En la práctica, la caché de pipelines de Qt puede corresponderse con las siguientes características de la API gráfica nativa:

• Vulkan - VkPipelineCache - Guardar la caché de pipeline almacena efectivamente el blob recuperado de vkGetPipelineCacheData, con metadatos adicionales para identificar con seguridad el dispositivo y el controlador, ya que el blob de caché de pipeline depende del controlador exacto.
• Metal - MTLBinaryArchive - Con el guardado de caché de canalización activado, Qt almacena todas las canalizaciones de renderizado y cálculo encontradas en un MTLBinaryArchive. Al guardar la caché de tuberías se almacena el blob recuperado del archivo, con metadatos adicionales para identificar el dispositivo. Nota: actualmente el uso de MTLBinaryArchive está deshabilitado en macOS e iOS debido a diversos problemas en algunas versiones de hardware y SO.
• OpenGL - No existe un concepto nativo de pipelines, la "caché de pipelines" almacena una colección de binarios de programa recuperados mediante glGetProgramBinary. Los binarios de programa se empaquetan en un único blob, con metadatos adicionales para identificar el dispositivo, el controlador y la versión desde la que se recuperaron los binarios. La caché persistente de binarios de programa no es nueva en Qt: Qt 5 ya tenía una funcionalidad similar en QOpenGLShaderProgram, ver addCacheableShaderFromSourceCode() por ejemplo. De hecho ese mecanismo está siempre activo en Qt 6 también cuando se usa Qt Quick con OpenGL. Sin embargo, cuando se usa la nueva abstracción de caché de canalización independiente de la API gráfica que se proporciona aquí, la caché binaria del programa de la era Qt 5 se desactiva automáticamente, ya que ahora el mismo contenido se empaqueta en la "caché de canalización".
• Direct 3D 11 - No existe un concepto nativo de pipelines o de recuperación de binarios para la segunda fase de compilación (donde el bytecode intermedio independiente del fabricante se compila en el conjunto de instrucciones específico del dispositivo). Los controladores suelen emplear su propio sistema de caché en ese nivel. En cambio, la "caché de canalización" de Qt Quick se utiliza para acelerar los casos en los que los sombreadores contienen código fuente HLSL que debe compilarse primero en el formato de bytecode intermedio. Esto puede presentar mejoras significativas de rendimiento en aplicaciones y librerías que componen código shader en tiempo de ejecución, porque en ejecuciones posteriores las llamadas potencialmente caras y sin caché a D3DCompile() pueden evitarse si el bytecode ya está disponible para el shader HLSL encontrado. Un buen ejemplo es Qt Quick 3D, donde los shaders generados en tiempo de ejecución para los materiales implican tener que lidiar con el código fuente HLSL. Por tanto, guardar y recargar la caché del pipeline de Qt Quick puede aportar mejoras considerables en escenas que contengan uno o más elementos de View3D. Un contraejemplo puede ser el propio Qt Quick: como la mayoría de los sombreadores incorporados para contenido 2D vienen con bytecode DirectX generado en tiempo de compilación, la caché no va a presentar ninguna mejora significativa.

Todo esto es independiente del procesamiento de shaders realizado por el módulo Qt Shader Tools y sus herramientas de línea de comandos como qsb. Como ejemplo, tomemos Vulkan. Tener el código fuente GLSL compatible con Vulkan compilado a SPIR-V ya sea en tiempo offline o de compilación (directamente vía qsb o CMake) es bueno, porque se evita la costosa compilación desde el código fuente en tiempo de ejecución. Sin embargo, SPIR-V es un formato intermedio independiente del proveedor. En tiempo de ejecución, cuando se construyen pipelines gráficos o de cálculo, es probable que se produzca otra ronda de compilación, esta vez desde el formato intermedio al conjunto de instrucciones específico del fabricante de la GPU (y esto puede depender de cierto estado en el pipeline gráfico y también de los objetivos de renderizado). La caché de canalización ayuda en esta última fase.

Llame a setPipelineCacheSaveFile() y setPipelineCacheLoadFile() para controlar en qué archivos QQuickWindow o QQuickView guarda y carga la caché de canalización.

Para hacerse una idea de los efectos de habilitar el almacenamiento en disco de la caché del pipeline, habilite los registros de scenegraph y gráficos más importantes a través de la variable de entorno QSG_INFO=1, o bien a través de las categorías de registro qt.scenegraph.general y qt.rhi.general. Al cerrar el QQuickWindow, aparece un mensaje de registro como el siguiente:

Total time spent on pipeline creation during the lifetime of the QRhi was 123 ms

Esto da una idea aproximada de cuánto tiempo se ha empleado en la creación de gráficos y pipelines de computación (que puede incluir varias etapas de compilación de shaders) durante el tiempo de vida de la ventana.

Cuando se activa la carga desde un archivo de caché de pipeline, esto se confirma con un mensaje:

Attempting to seed pipeline cache from 'filename'

Del mismo modo, para comprobar si el guardado de la caché se ha activado correctamente, busca un mensaje como este:

Writing pipeline cache contents to 'filename'

La caché automática del pipeline

Cuando no se proporciona ningún nombre de archivo para guardar y cargar, se utiliza la estrategia de almacenamiento automático en caché. Esto implica el almacenamiento de datos en la ubicación de caché específica de la aplicación del sistema (QStandardPaths::CacheLocation).

Esto puede desactivarse por uno de los siguientes medios:

• Establezca el atributo de aplicación Qt::AA_DisableShaderDiskCache. (desactiva completamente el almacenamiento automático)
• Establecer la variable de entorno QT_DISABLE_SHADER_DISK_CACHE a un valor distinto de cero. (desactiva completamente el almacenamiento automático)
• Establecer la variable de entorno QSG_RHI_DISABLE_SHADER_DISK_CACHE en un valor distinto de cero. (desactiva completamente el almacenamiento automático)
• Llamar a setAutomaticPiplineCache() con el argumento enable puesto a false. (desactiva completamente el almacenamiento automático)
• Establecer un nombre de archivo llamando a setPipelineCacheLoadFile(). (sólo desactiva la carga desde el almacenamiento automático, prefiriendo el archivo especificado en su lugar)
• Establezca un nombre de archivo llamando a setPipelineCacheSaveFile(). (sólo desactiva la escritura en el almacenamiento automático, prefiriendo en su lugar el archivo especificado)

Los dos primeros son mecanismos existentes que se usan desde Qt 5.9 para controlar la caché binaria del programa OpenGL. Por compatibilidad y familiaridad el mismo atributo y variable de entorno son soportados para la caché pipeline mejorada de Qt 6.

La caché de canalización automática utiliza un único archivo por aplicación, pero uno diferente para cada backend RHI (API gráfica). Esto significa que el cambio a otra API gráfica en la siguiente ejecución de la aplicación no provocará la pérdida de la caché de canalización generada en la ejecución anterior. Las aplicaciones con múltiples instancias de QQuickWindow mostradas simultáneamente pueden, sin embargo, no beneficiarse al 100% ya que la caché automática sólo puede almacenar los datos recogidos de un objeto RHI a la vez. (y con el bucle de renderizado por defecto threaded cada ventana tiene su propio RHI ya que el renderizado opera independientemente en hilos dedicados). Para beneficiarse plenamente de la caché de disco en aplicaciones con múltiples ventanas, es preferible establecer el nombre de archivo explícitamente, por ventana a través de setPipelineCacheSaveFile().