Talisman fue un proyecto de Microsoft para crear una nueva arquitectura de gráficos 3D basada en la composición rápida de "subimágenes" 2D en la pantalla, una adaptación del renderizado en mosaico . En teoría, este enfoque reduciría drásticamente la cantidad de ancho de banda de memoria necesario para los juegos 3D y, por lo tanto, conduciría a aceleradores gráficos de menor costo . El proyecto tuvo lugar durante la introducción de los primeros aceleradores 3D de alto rendimiento, y estos superaron rápidamente 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.
La creación de una imagen 3D para su visualización consta de una serie de pasos. En primer lugar, los objetos que se van a visualizar se cargan en la memoria a partir de modelos individuales . A continuación, el sistema de visualización aplica funciones matemáticas para transformar los modelos en un sistema de coordenadas común, la vista del mundo . A partir de esta vista del mundo, se crea una serie de polígonos (normalmente triángulos) que se aproximan a los modelos originales tal como se ven desde un punto de vista particular, la cámara . A continuación, un sistema de composición produce una imagen mediante la representación de los triángulos y la aplicación de texturas en el exterior. Las texturas son pequeñas imágenes que se pintan sobre los triángulos para producir realismo. A continuación, la imagen resultante se combina con varios efectos especiales y se traslada 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 fotograma a fotograma, es probable que los objetos en 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 desde la memoria es considerablemente más costoso y luego enviar el fotograma renderizado resultante al búfer de fotogramas es 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 : con una resolución de 640 x 480, requeriría 1.900 Mbit/s de ancho de banda de memoria; con una resolución de 1024 x 768, requeriría 4.900 Mbit/s. Incluso se esperaría que 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 de aproximadamente 10.000 Mbit/s, que era la razón por la que estas máquinas se usaban ampliamente en gráficos 3D. Una PC típica de la época que usaba AGP 2X podía ofrecer solo 508 Mbit/s.
El primer ataque a este problema fue la introducción de aceleradores gráficos que manejaban el almacenamiento y mapeo de texturas. Estas tarjetas, como la Voodoo Graphics original , hacían que la CPU recalculara la geometría para cada cuadro y luego enviaba la serie de coordenadas resultante a la tarjeta. La tarjeta luego manejaba el resto de la operación: aplicaba las texturas a la geometría, renderizaba el cuadro, aplicaba filtros o anti-aliasing y enviaba los resultados a un framebuffer local. Las necesidades de ancho de banda en un sistema de este tipo se redujeron drásticamente; una escena con 10.000 triángulos podría necesitar de 500 a 1000 kbit/s, dependiendo de cuántos puntos de geometría pudieran compartirse entre triángulos.
A medida que la complejidad de la escena aumentaba, 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. Se podrían lograr 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 flujo de visualización podría ejecutarse en la tarjeta, requiriendo 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 " transform and illumination " 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 representación en mosaico . Se basaba 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, las "mosaicos". Por ejemplo, el movimiento de la cámara en la escena se puede simular tomando cada mosaico y haciéndolo ligeramente más grande. Del mismo modo, se pueden simular otros movimientos en la escena con la aplicación de la transformación afín adecuada . Sin embargo, este proceso es solo aproximado, ya que 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 ser renderizados nuevamente cada vez, solo aquellos que contienen objetos cercanos a la cámara. Si toda la geometría se envía a la tarjeta, esta tarea puede ser manejada 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, entonces idealmente la tarjeta debería poder pedirle a la CPU que vuelva a renderizar solo aquellos objetos en mosaicos que están desactualizados. En muchos casos, esto requeriría cambiar el flujo de renderizado de la CPU. En cualquier caso, la tarjeta y/o los controladores necesitan saber sobre el orden y la posición de los objetos, algo que normalmente está oculto en el código.
Talisman era un conjunto completo de software y hardware que intentaba resolver el problema de la representación en mosaico. El sistema compartía información sobre los mosaicos y los objetos que contenían para averiguar cuáles estaban desactualizados. Si un mosaico se volvía obsoleto, se le pedía a la CPU que volviera a renderizar los objetos que contenía y enviara los resultados al controlador y luego a la tarjeta. Una vez que se renderizaba un mosaico en particular en la tarjeta, se almacenaba en la tarjeta en formato comprimido para poder reutilizarlo en fotogramas futuros. Microsoft calculó que cada mosaico podía reutilizarse durante unos cuatro fotogramas en promedio, lo que reducía la carga de la CPU unas cuatro veces.
En Talisman, los buffers de imagen se dividían en "fragmentos" de 32 x 32 píxeles que se renderizaban individualmente utilizando los objetos 3D y las texturas proporcionadas por la CPU. Los punteros a los fragmentos se almacenaban en una lista ordenada en z (de adelante hacia atrás) por cada 32 líneas de escaneo en la pantalla. Una preocupación es que los fragmentos no se pueden "unir" de forma limpia, un problema que a veces ha sido visible en varios videojuegos que utilizan renderizado por software . Para evitar esto, Talisman también almacenó un "buffer de borde" separado para cada fragmento que almacenaba un área de "desbordamiento" que cubriría los espacios vacíos en el mapeo.
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 cuadros y, finalmente, el hardware de video la recoge para su visualización. Los sistemas Talisman básicamente invirtieron este proceso; la pantalla se dividió 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 indicaba que preparara los detalles para la siguiente tira.
El sistema respondería recuperando todos los fragmentos que fueran visibles 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, ahorrando tiempo. Esta es la razón de la clasificación z de los fragmentos, que permite recuperarlos de manera eficiente en "orden de visibilidad". Si los fragmentos se podían modificar sin distorsión, se invocaba la transformación afín adecuada para actualizar el fragmento en el lugar. Si no se podía, por ejemplo, porque la cámara se había movido demasiado desde la última actualización completa, se le pedía a la CPU que proporcionara una nueva geometría para ese fragmento, que luego la tarjeta renderizaba y volvía a colocar en el almacenamiento.
Talisman no tenía un análogo de un framebuffer, y reproducía fragmentos a demanda directamente en la pantalla a medida que la línea de escaneo del monitor avanzaba por la pantalla. Esta es una analogía interesante con el Atari 2600 , que utiliza un sistema similar para reproducir imágenes 2D en la pantalla, un método conocido como "racing the beam". En ambos casos, esto redujo la cantidad de memoria necesaria y el ancho de banda de memoria que se utiliza 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 ejecutaban. En el caso de Talisman, los programas debían almacenar sus objetos en un formato particular que los controladores de software de Talisman entendían, lo que permitía que se los recuperara rápidamente de la memoria durante las interrupciones .
El proyecto Talisman fue un intento de Microsoft de comercializar conceptos con los que se había estado experimentando 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] Planeaban 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 multimedia más grande, en lugar de un sistema 3D completo que funcionarí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 renderizado de polígonos de 40 Mpixeles/s y una tasa de composición de capas de imagen de 320 Mpixeles/s.
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 "Media Signal Processor" (MSP) similar a un DSP de un solo chip , que combinaba la funcionalidad de Talisman con una 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 "Polygon Object Processor" (POP), este chip era sondeado periódicamente por otro chip de Cirrus Logic, el "Image Layer Compositor" (ILC), que estaba vinculado a los circuitos de vídeo. 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 la contienda con una nueva versión planificada de su procesador TriMedia , que implementaba 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 los juegos de disparos en primera persona comenzó a cobrar protagonismo en el mundo de los videojuegos. Esto creó una demanda en el mercado de aceleradores que pudieran utilizarse con juegos existentes con cambios mínimos. Cuando el diseño de referencia de Escalante estuvo listo para producción, las fuerzas del mercado ya habían dado lugar a 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 organizadas para permitir velocidades extremadamente altas resolvieron el problema del ancho de banda, simplemente aplicando la fuerza bruta al 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 utilizaba. A diferencia de las nuevas tarjetas 3D que salían al mercado en ese momento, los sistemas Talisman tenían que poder pedirle a la CPU que volviera 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. Para ayudar a los desarrolladores en esta tarea, se modificó Direct3D para que se ajustara mejor a las necesidades de Talisman. Sin embargo, para cualquier juego que ya se hubiera escrito, o para aquellos que no querían estar atados a Talisman, esto hizo que el sistema D3D fuera más lento y considerablemente menos interesante.
Como resultado de estos cambios, Talisman nunca llegó a ser 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, poco después se produjo un breve renacimiento, 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 llegó a comercializarse y Talisman fue abandonado en silencio. Esto fue para el deleite de los proveedores de aceleradores gráficos de terceros, así como de la gente dentro de Microsoft que los apoyaba en el mercado con DirectX .
Sin embargo, varias de las ideas introducidas 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, también se ha usado compresión en los búferes z para reducir las demandas de memoria mientras se ordena la pantalla. La idea de usar "fragmentos" para ordenar la pantalla también se ha usado en una pequeña cantidad de tarjetas, lo que se conoce como renderizado basado en mosaicos . Muchos procesadores gráficos diseñados específicamente para dispositivos móviles (como teléfonos celulares) emplean un enfoque basado en mosaicos. Solo la idea clave de Talisman, solicitar actualizaciones de la geometría solo "cuando sea necesario", no se ha intentado desde entonces.