Lista de visualización

Una lista de visualización , también llamada lista de comandos en Direct3D 12 y búfer de comandos en Vulkan , es una serie de comandos gráficos para que puedan ejecutarse más tarde cuando se ejecuta la lista. ^[1] Los sistemas que hacen uso de la funcionalidad de lista de visualización se denominan sistemas de modo retenido , mientras que los sistemas que no lo hacen se oponen a los sistemas de modo inmediato . En OpenGL, las listas de visualización son útiles para volver a dibujar la misma geometría o aplicar un conjunto de cambios de estado varias veces. ^{[2] [3]} Este beneficio también se utiliza con las listas de comandos del paquete de Direct3D 12. En Direct3D 12 y Vulkan, las listas de visualización se utilizan regularmente para la grabación y ejecución por cuadro.

Los monitores vectoriales o pantallas caligráficas de los años 1960 y 1970 utilizaban la deflexión del haz de electrones para dibujar segmentos de línea , puntos y, a veces, curvas directamente en una pantalla CRT . Debido a que la imagen se desvanecía inmediatamente, era necesario volver a dibujarla muchas veces por segundo ( los CRT con tubo de almacenamiento retenían la imagen hasta que se borraba, pero no eran adecuados para gráficos interactivos). Para actualizar la pantalla, se utilizaba una CPU dedicada llamada Procesador de Pantalla o Unidad de Procesamiento de Pantalla (DPU), que tenía un búfer de memoria para una "lista de visualización", "archivo de visualización" o "programa de visualización" que contenía coordenadas de segmentos de línea y otra información. Los procesadores de pantalla avanzados también admitían instrucciones de flujo de control , que eran útiles para dibujar gráficos repetitivos como texto, y algunos podían realizar transformaciones de coordenadas como la proyección 3D . ^{[4] [5]}

Uno de los primeros sistemas con una lista de visualización real fueron los ordenadores Atari de 8 bits . La lista de visualización (de hecho, llamada así en la terminología de Atari) es una serie de instrucciones para ANTIC , el coprocesador de vídeo utilizado en estas máquinas. Este programa, almacenado en la memoria del ordenador y ejecutado por ANTIC en tiempo real, puede especificar líneas en blanco, cualquiera de los seis modos de texto y ocho modos gráficos, qué secciones de la pantalla pueden desplazarse horizontal o verticalmente con precisión y activar interrupciones de la lista de visualización (llamadas interrupciones de trama o HBI en otros sistemas). ^[6]

La familia Amstrad PCW contiene una función de lista de visualización llamada "Roller RAM". Se trata de un área de RAM de 512 bytes que consta de 256 punteros de 16 bits en RAM, uno para cada línea de la pantalla de 720 × 256 píxeles. Cada puntero identifica la ubicación de 90 bytes de píxeles monocromos que contienen los 720 estados de píxeles de la línea. Los 90 bytes de los 8 estados de píxeles están espaciados a intervalos de 8 bytes, por lo que hay 7 bytes sin usar entre cada byte de datos de píxeles. Esto se adapta a la forma en que el PCW orientado a texto construye un búfer de pantalla típico en RAM, donde las 8 filas del primer carácter se almacenan en los primeros 8 bytes, las filas del segundo carácter en los siguientes 8 bytes, y así sucesivamente. La RAM Roller se implementó para acelerar el desplazamiento de la pantalla, ya que hubiera sido inaceptablemente lento para su Z80 de 3,4 MHz desplazarse hacia arriba en el búfer de pantalla de 23 KB "a mano", es decir, mediante software. La entrada inicial de la RAM Roller que se utiliza al comienzo de una actualización de pantalla está controlada por un registro de E/S escribible por el Z80. Por lo tanto, la pantalla se puede desplazar simplemente modificando este registro de E/S. ^{[ cita requerida ]}

Otro sistema que utiliza una característica similar a Display List en el hardware es el Amiga , que, no por casualidad, también fue diseñado por algunas de las mismas personas que desarrollaron el hardware personalizado para las computadoras Atari de 8 bits. Una vez que se le ordenaba que produjera un modo de visualización, continuaría haciéndolo automáticamente para cada línea de escaneo siguiente. La computadora también incluía un coprocesador dedicado, llamado " Copper ", que ejecutaba un programa simple o "Copper List" destinado a modificar los registros del hardware en sincronía con la pantalla. Las instrucciones de Copper List podían indicarle al Copper que esperara a que la pantalla alcanzara una posición específica en la pantalla y luego cambiara el contenido de los registros del hardware. En efecto, era un procesador dedicado a dar servicio a las interrupciones de trama . El Copper fue utilizado por Workbench para mezclar múltiples modos de visualización (múltiples resoluciones y paletas de colores en el monitor al mismo tiempo), y por numerosos programas para crear efectos de arco iris y degradados en la pantalla. El Amiga Copper también era capaz de reconfigurar el motor de sprites a mitad de cuadro, con solo una línea de escaneo de retraso. Esto permitió que el Amiga dibujara más de sus 8 sprites de hardware, siempre y cuando los sprites adicionales no compartieran líneas de escaneo (o el espacio entre líneas de escaneo) con más de otros 7 sprites, es decir, siempre que al menos un sprite hubiera terminado de dibujarse, se podía agregar otro sprite debajo de él en la pantalla. Además, el chipset AGA de 32 bits posterior permitió el dibujo de sprites más grandes (más píxeles por fila) mientras se conservaba la misma multiplexación. El Amiga también tenía un hardware dedicado para desplazar bloques ("blitter"), que podía dibujar objetos más grandes en un búfer de cuadros. Esto se usaba a menudo en lugar de, o además de, los sprites. ^{[ cita requerida ]}

En sistemas más primitivos, los resultados de una lista de visualización se pueden simular, aunque a costa de escrituras intensivas de CPU en ciertos modos de visualización, control de color u otros registros de efectos visuales en el dispositivo de video, en lugar de una serie de comandos de renderización ejecutados por el dispositivo. Por lo tanto, uno debe crear la imagen mostrada utilizando algún otro proceso de renderización, ya sea antes o mientras se ejecuta la generación de visualización controlada por CPU. En muchos casos, la imagen también se modifica o se vuelve a renderizar entre fotogramas . Luego, la imagen se muestra de varias maneras, según la forma exacta en que se implemente el código de visualización controlado por CPU. ^{[ cita requerida ]}

Algunos ejemplos de los resultados posibles en estas máquinas más antiguas que requieren video controlado por CPU incluyen efectos como el modo FLI del Commodore 64/128 o el procesamiento Rainbow en el ZX Spectrum. ^{[ cita requerida ]}

Para delimitar una lista de visualización, se utilizan las funciones glNewListy , y para ejecutar la lista, se utiliza la función . Casi todos los comandos de representación que se producen entre las llamadas de función se almacenan en la lista de visualización. Los comandos que afectan al estado del cliente no se almacenan en las listas de visualización. ^[7] Las listas de visualización se nombran con un valor entero y la creación de una lista de visualización con el mismo nombre que una ya creada anula la primera. ^[8]glEndListglCallList

La glNewListfunción espera dos argumentos: un entero que representa el nombre de la lista y una enumeración para el modo de compilación. Los dos modos incluyen GL_COMPILE_AND_EXECUTE, que compila y ejecuta inmediatamente, y GL_COMPILE, que solo compila la lista. ^[9]

Las listas de visualización permiten el uso del patrón de representación en modo retenido , que es un sistema en el que los comandos gráficos se registran (retienen) para ejecutarse en sucesión en un momento posterior. Esto es contrario al modo inmediato , donde los comandos gráficos se ejecutan inmediatamente en las llamadas del cliente. ^[10]

Las listas de comandos se crean utilizando la ID3D12Device::CreateCommandListfunción. ^[11] Las listas de comandos se pueden crear en varios tipos: directo, paquete, cálculo, copia, decodificación de video, proceso de video y codificación de video. Las listas de comandos directos especifican que una lista de comandos puede ejecutar la GPU y no hereda ningún estado de la GPU. ^[12] Los paquetes se utilizan mejor para almacenar y ejecutar pequeños conjuntos de comandos cualquier cantidad de veces. Esto se usa de manera diferente a las listas de comandos regulares, donde los comandos almacenados en una lista de comandos generalmente se ejecutan solo una vez. ^[11] Las listas de comandos de cálculo se utilizan para cálculos generales, y un uso común es el cálculo de mapas mip . ^[13] Una lista de comandos de copia es estrictamente para copiar y las listas de comandos de decodificación de video y de proceso de video son para decodificación y procesamiento de video respectivamente. ^[12]

Al crearse, las listas de comandos se encuentran en estado de grabación. Las listas de comandos se pueden reutilizar llamando a la ID3D12GraphicsCommandList::Resetfunción. Después de grabar comandos, la lista de comandos debe salir del estado de grabación llamando a ID3D12GraphicsCommandList::Close. Luego, la lista de comandos se ejecuta llamando a ID3D12CommandQueue::ExecuteCommandLists. ^[11]

Las listas de visualización han quedado en desuso en gran medida en las arquitecturas gráficas modernas, ya que representan un conjunto de comandos en la tubería de gráficos de función fija . Las arquitecturas modernas utilizan sombreadores y objetos de búfer de vértices para evitar vincular el rendimiento de los gráficos a la CPU. Debido a la naturaleza de la lista de visualización, debe copiar cada comando y sus datos, lo que puede ser un problema para ciertos entornos donde la memoria es escasa y puede ser ineficiente en general. ^[7] Sin embargo, Vulkan y Direct3D 12 aún practican una funcionalidad similar a la de la lista de visualización en forma de búferes de comandos y listas de comandos.

• Lista de ordenadores domésticos por hardware de vídeo
• Representación de líneas de escaneo

• White, Steven; Danielsson, David; Jenks, Alma; Satran, Michael (8 de marzo de 2023). "Filosofía de diseño de colas de comandos y listas de comandos: aplicaciones Win32". learn.microsoft.com . Consultado el 26 de enero de 2024.