Talisman fue un proyecto de Microsoft para construir una nueva arquitectura de gráficos 3D basada en la composición rápida de "subimágenes" 2D en la pantalla, una adaptación de la representación en mosaico . En teoría, este enfoque reduciría drásticamente la cantidad de ancho de banda de memoria requerido para los juegos 3D y, por lo tanto, conduciría a aceleradores de gráficos de menor costo . El proyecto se llevó a cabo durante la introducción de los primeros aceleradores 3D de alto rendimiento, y estos rápidamente superaron a Talisman tanto en rendimiento como en precio. Nunca se lanzó comercialmente ningún sistema basado en Talisman, y el proyecto finalmente se canceló a fines de la década de 1990.
Descripción
3D convencional
La creación de una imagen 3D para su visualización consta de una serie de pasos. Primero, los objetos que se mostrarán se cargan en la memoria desde modelos individuales . Luego, el sistema de visualización aplica funciones matemáticas para transformar los modelos en un sistema de coordenadas común, la visión del mundo . Desde esta visión del mundo, se crea una serie de polígonos (típicamente triángulos) que se aproxima a los modelos originales como se ve desde un punto de vista particular, la cámara . A continuación, un sistema de composición produce una imagen renderizando los triángulos y aplicando texturas al exterior. Las texturas son pequeñas imágenes que se pintan sobre los triángulos para producir realismo. Luego, la imagen resultante se combina con varios efectos especiales y se mueve a los búferes de visualización. Este diseño conceptual básico se conoce como canalización de visualización .
En términos generales, la pantalla cambia poco de un fotograma a otro; Por lo general, para cualquier transición de cuadro a cuadro, es probable que los objetos de la pantalla se muevan ligeramente, pero es poco probable que su forma y texturas cambien en absoluto. Cambiar la geometría es una operación relativamente liviana para la CPU , cargar las texturas de la memoria considerablemente más caro y luego enviar el marco renderizado resultante al framebuffer, la operación más costosa de todas.
Por ejemplo, considere la configuración de renderizado de la época con color de 24 bits, con composición 3D básica con filtrado trilineal y sin anti-aliasing : a una resolución de 640 x 480, requeriría 1,900 Mbit / s de ancho de banda de memoria; a una resolución de 1024 x 768, requeriría 4900 Mbit / s. Se esperaría que incluso el anti-aliasing básico duplicara aproximadamente esas cifras. [1] Como referencia, las máquinas RealityEngine2 de SGI en ese momento presentaban un ancho de banda de memoria alto en ese momento de aproximadamente 10,000 Mbit / s, que fue la razón por la que estas máquinas se usaban ampliamente en gráficos 3D. Una PC típica de la época que usara AGP 2X podía ofrecer solo 508 Mbit / s.
El primer ataque a este problema fue la introducción de aceleradores de gráficos que manejaban el almacenamiento y el mapeo de texturas. Estas tarjetas, como las Voodoo Graphics originales , hicieron que la CPU volviera a calcular la geometría de cada fotograma y luego enviara la serie de coordenadas resultante a la tarjeta. La tarjeta luego manejó el resto de la operación; aplicar las texturas a la geometría, renderizar el marco, aplicar filtrado o suavizado y enviar los resultados a un búfer de marco local. Las necesidades de ancho de banda en un sistema de este tipo se redujeron drásticamente; una escena con 10,000 triángulos puede necesitar de 500 a 1000 kbit / s, dependiendo de cuántos de los puntos geométricos se puedan compartir entre los triángulos.
Renderizado en mosaico
A medida que aumentaba la complejidad de la escena, la necesidad de volver a generar la geometría de lo que era esencialmente un conjunto fijo de objetos comenzó a convertirse en un cuello de botella por sí solo. Se podrían obtener mejoras mucho mayores en el rendimiento si la tarjeta gráfica también almacenara y manipulara los polígonos. En un sistema de este tipo, todo el canal de visualización podría ejecutarse en la tarjeta, lo que requiere interacciones mínimas con la CPU. Esto requeriría que la tarjeta gráfica fuera mucho más "inteligente"; a diferencia de las operaciones muy simples involucradas en la aplicación de texturas, la tarjeta ahora tendría que tener un procesador completo capaz de calcular las funciones utilizadas en el modelado 3D. En ese momento, varias empresas estaban explorando este camino, las llamadas tarjetas de " transformación e iluminación " o T&L, pero la complejidad y el costo de los sistemas parecían considerables.
Una solución que se estudió durante este período fue el concepto de revestimiento de azulejos . Esto se basó en la observación de que se podían simular pequeños cambios en la posición de la cámara manipulando pequeñas imágenes 2D, los "mosaicos". Por ejemplo, el movimiento de la cámara en la escena se puede simular tomando cada mosaico y haciéndolo un poco más grande. Asimismo, se pueden simular otros movimientos en la escena con la aplicación de la transformación afín apropiada . Sin embargo, este proceso es solo aproximado, a medida que aumenta el movimiento, la fidelidad visual disminuirá. Un sistema de este tipo puede reducir la necesidad de volver a calcular la geometría a cada dos o tres fotogramas en promedio.
El problema con este enfoque es que no todos los mosaicos necesariamente tienen que volver a renderizarse cada vez, solo aquellos que contienen objetos cerca de la cámara. Si toda la geometría se envía a la tarjeta, esta tarea se puede manejar completamente en la tarjeta, pero esto requiere tarjetas de complejidad similar a los sistemas T&L. Si la geometría se mantiene bajo el control de la CPU, lo ideal es que la tarjeta pueda pedirle a la CPU que vuelva a renderizar solo los objetos en mosaicos que están desactualizados. En muchos casos, esto requeriría que se cambiara la canalización de procesamiento de la CPU. En cualquier caso, la tarjeta y / o los controladores necesitan conocer el orden y la posición de los objetos, algo que normalmente se esconde en el código.
Talismán
Talisman era un conjunto completo de software y hardware que intentaba resolver el problema de la representación en mosaico. El sistema compartió información sobre los mosaicos y los objetos dentro de ellos para descubrir qué mosaicos estaban desactualizados. Si un mosaico quedaba desactualizado, se le pedía a la CPU que volviera a renderizar los objetos en ese mosaico y enviara los resultados al controlador y luego a la tarjeta. Una vez que se renderizó un mosaico en particular en la tarjeta, se almacenó en la tarjeta en formato comprimido para que pudiera reutilizarse en marcos futuros. Microsoft calculó que cada mosaico podría reutilizarse durante aproximadamente cuatro fotogramas en promedio, reduciendo así la carga en la CPU aproximadamente cuatro veces.
En Talisman, los búferes de imagen se dividieron en "trozos" de 32 x 32 píxeles que se renderizaron individualmente utilizando los objetos y texturas 3D proporcionados por la CPU. Luego, los punteros a los fragmentos se almacenaron en una lista ordenada en z (de adelante hacia atrás) para cada 32 líneas de escaneo en la pantalla. Una preocupación es que los trozos no se pueden "unir" limpiamente, un problema que a veces ha sido visible en varios videojuegos que utilizan renderizado por software . Para evitar esto, Talisman también almacenó un "búfer de borde" separado para cada fragmento que almacenaba un área de "desbordamiento" que cubriría los espacios en el mapeo.
Canalización de renderizado
En un sistema 3D convencional, la geometría se genera periódicamente, se envía a la tarjeta para su composición, se compone en un búfer de fotogramas y, finalmente, el hardware de vídeo la recoge para su visualización. Los sistemas de talismán esencialmente invirtieron este proceso; la pantalla estaba dividida en tiras de 32 líneas de alto, y mientras el hardware de video dibujaba una de estas tiras, el hardware llamaba al lado de Talisman y le decía que preparara los detalles para la siguiente tira.
El sistema respondería recuperando cualquier fragmento que fuera visible en esa franja dada la ubicación actual de la cámara. En el caso típico, muchos de los fragmentos quedarían ocultos por otros fragmentos y podrían ignorarse durante la composición, lo que ahorraría tiempo. Esta es la razón de la clasificación z de los fragmentos, lo que permite recuperarlos de manera eficiente en "orden de visibilidad". Si los fragmentos se podían modificar sin distorsión, se llamaba a la transformación afín adecuada para actualizar el fragmento en el lugar. Si no podía, digamos porque la cámara se había movido demasiado desde la última actualización completa, se le pidió a la CPU que proporcionara una nueva geometría para ese fragmento, que luego la tarjeta procesó y colocó nuevamente en el almacenamiento.
Talisman no tenía un análogo de un framebuffer, renderizando fragmentos bajo demanda directamente en la pantalla a medida que la línea de escaneo del monitor avanzaba hacia abajo en la pantalla. Este es un análogo interesante con el Atari 2600 , que usa un sistema similar para renderizar imágenes 2D en la pantalla, un método conocido como "correr el rayo". En ambos casos, esto redujo la cantidad de memoria necesaria y el ancho de banda de memoria que se usa entre el sistema de visualización y el hardware de video. En ambos casos, esto también requirió una integración mucho más estrecha entre el sistema de video y los programas que lo ejecutan. En el caso de Talisman, los programas debían almacenar sus objetos en un formato particular que los controladores del software Talisman entendían, lo que permitía que se recuperaran rápidamente de la memoria durante las interrupciones .
Historia
Introducción
El esfuerzo de Talisman fue el intento de Microsoft de comercializar conceptos con los que se había experimentado durante algún tiempo. En particular, el sistema PixelFlow desarrollado en un laboratorio de investigación de Hewlett-Packard en la Universidad de Carolina del Norte en Chapel Hill puede considerarse el padre directo de Talisman. [2]
Cuando Talisman se hizo público por primera vez en la reunión SIGGRAPH de 1996 , prometieron una reducción drástica en el costo de implementación de un subsistema de gráficos. [3] Planearon trabajar con proveedores para vender el concepto de Talisman para su inclusión en los sistemas de visualización de otras empresas. Es decir, se esperaba que Talisman fuera parte de un chip de medios más grande, a diferencia de un sistema 3D completo que estaría solo en un sistema. Su sistema básico admitiría entre 20 y 30 000 polígonos en una pantalla de 1024 x 768 a 32 bits / píxel, con una tasa de reproducción de polígonos de 40 megapíxeles / sy una tasa de composición de capa de imagen de 320 megapíxeles / s.
Escalante
En ese momento, Microsoft estaba trabajando con varios proveedores para desarrollar una implementación de referencia conocida como Escalante . Samsung y 3DO estaban trabajando juntos para diseñar un "Procesador de señales multimedia" (MSP) similar a un DSP de un solo chip , que combinaba la funcionalidad Talisman con la funcionalidad multimedia adicional. Cirrus Logic proporcionaría un chip VLSI que recuperaría los datos colocados en la memoria por el MSP, aplicaría efectos y los enviaría para su visualización. Conocido como el "Procesador de objetos poligonales" (POP), este chip era periódicamente sondeado por otro chip Cirrus Logic, el "Compositor de capas de imágenes" (ILC), que estaba vinculado a los circuitos de video. Además, Escalante tenía la intención de presentar 4 MB de RDRAM en dos canales de 8 bits a 600 MHz, ofreciendo un rendimiento de 1.2 GB / s. [4] Más tarde, Philips entró en juego con una nueva versión planificada de su procesador TriMedia , que implementó la mayor parte de Talisman en una sola CPU, y Trident Microsystems , con planes similares.
Fue en medio del proyecto Talisman cuando el género de disparos en primera persona comenzó a destacar en los videojuegos. Esto creó una demanda en el mercado de aceleradores que pudieran usarse con juegos existentes con cambios mínimos. Para cuando el diseño de referencia de Escalante estuvo listo para la producción, las fuerzas del mercado ya habían dado como resultado una serie de diseños de tarjetas más nuevos con un rendimiento tan mejorado que las tarjetas Talisman simplemente no podían competir. Las tarjetas con grandes cantidades de RAM dispuestas para permitir velocidades extremadamente altas resolvieron el problema del ancho de banda, simplemente forzando el problema en lugar de intentar resolverlo mediante una implementación inteligente.
Además, el concepto de Talisman requería una estrecha integración entre el sistema de visualización y el software que lo utiliza. A diferencia de las nuevas tarjetas 3D que llegaron al mercado en ese momento, los sistemas Talisman tendrían que poder pedirle a la CPU que vuelva a renderizar partes de la imagen para actualizar sus fragmentos. Esto requería que los juegos tuvieran una organización específica en la memoria para poder responder a estas solicitudes. Con el fin de ayudar a los desarrolladores en esta tarea, Direct3D se cambió para ajustarse más a las necesidades de Talisman. Sin embargo, para cualquier juego que ya había sido escrito, o aquellos que no querían estar vinculados a Talisman, esto hacía que el sistema D3D fuera más lento y considerablemente menos interesante.
Desaparición
Como resultado de estos cambios, Talisman nunca se convirtió en un producto comercial. Cirrus Logic y Samsung abandonaron el sistema en algún momento de 1997, lo que llevó a Microsoft a abandonar los planes de lanzar Escalante en 1997, y para los observadores externos parecía que todo el proyecto estaba muerto. [5]
Sin embargo, hubo un breve renacimiento poco después, cuando Fujitsu afirmó estar trabajando en una implementación de un solo chip que estaría disponible en 1998, con rumores de proyectos similares en S3 Graphics y ATI Technologies . [6] Ninguno de estos sistemas se envió nunca y Talisman murió silenciosamente. Esto fue para el deleite de los proveedores de aceleradores de gráficos de terceros, así como de las personas de Microsoft que los apoyaron en el mercado con DirectX .
Legado
Sin embargo, varias de las ideas pioneras en el sistema Talisman se han vuelto comunes en la mayoría de los aceleradores. En particular, la compresión de texturas ahora se usa ampliamente. En tarjetas más recientes, la compresión también se ha utilizado en los búferes z para reducir las demandas de memoria al ordenar la pantalla. La idea de usar "trozos" para ordenar la pantalla también se ha utilizado en una pequeña cantidad de tarjetas, lo que se conoce como representación basada en mosaicos , pero solo se volvió competitiva en el espacio de escritorio mucho más tarde, con el lanzamiento de las GPU basadas en Maxwell de NVidia. en 2014. Muchos procesadores gráficos diseñados específicamente para dispositivos móviles (como teléfonos móviles) emplean un enfoque basado en mosaicos. Desde entonces, sólo la idea clave de Talisman, que solicita actualizaciones de la geometría "cuando sea necesario", no se ha intentado.
Referencias
- ^ Allen Ballman, "¿Qué es Talisman?" Archivado el 13 de septiembre de 2006 en Wayback Machine , Microsoft Research, SIGGRAPH 1996
- ^ Problema combinado: concepto de Chapel Hill "Reempaquetados" de Microsoft Talisman
- ^ Jay Torborg y James Kajiya, "Talismán: gráficos 3D en tiempo real de productos básicos para PC", SIGGRAPH 1996
- ^ Francis Vale, Intel MMX contra Microsoft Talisman: Abbott y Costello Do Multimedia , 21; La red VXM, 1997
- ^ Francis Vale, Talisman, Parte II: Microsoft todavía no obtiene la imagen en 3D , 21; La red VXM, 1997
- ^ Mark Hachman, F "ujitsu para dar vida al talismán de Microsoft" , Electronic Buyer's News , 16 de septiembre de 1998
enlaces externos
- Chicken Crossing , cortometraje renderizado en tiempo real utilizando conceptos de Talisman, presentado en SIGGRAPH '96