Microsoft Talisman

Aus UnrealWiki

Hinweis: Historisches Projekt: Microsoft Talisman wurde 1996 öffentlich vorgestellt, erreichte jedoch nie den Markt. Der Begriff „Hybrid“ bezeichnet hier die Verbindung aus klassischer 3D-Berechnung, wiederverwendeten 2D-Bildebenen und Multimedia-Verarbeitung – nicht ein heutiges Notebook-System aus iGPU und dGPU.

Microsoft Talisman war der Codename einer experimentellen 3D-Grafik- und Multimedia-Architektur von Microsoft Research aus der Mitte der 1990er-Jahre. Microsoft wollte hochwertige Echtzeitgrafik auf bezahlbaren PCs ermöglichen, obwohl damalige Prozessoren, Grafikspeicher und Speicherbusse für komplexe 3D-Szenen noch sehr begrenzt waren.

Talisman sollte dieses Problem nicht allein mit mehr Rechenleistung lösen. Statt eine vollständige Szene in jedem Bild neu zu rendern, zerlegte das System sie in unabhängig aktualisierbare Bildebenen – vergleichbar mit Sprites oder Folien. Bereits berechnete Objektbilder konnten über mehrere Frames gespeichert, verschoben, skaliert, gedreht, verzerrt und anschließend wieder zur fertigen Szene zusammengesetzt werden. Nur sichtbar veränderte Inhalte mussten erneut als echte 3D-Geometrie gerendert werden.

Damit war Talisman ein ungewöhnlicher Hybrid aus 3D-Rendering, bildbasierter Darstellung, 2D-Compositing und programmierbarer Medienverarbeitung. Das Projekt beeinflusste Forschung und Diskussionen über bandbreiteneffiziente Grafik, setzte sich gegen die schnell besser werdenden konventionellen 3D-Beschleuniger jedoch nicht durch.

Ausgangslage und Ziel

Mitte der 1990er-Jahre waren Echtzeit-3D-Grafik und Multimedia auf dem PC teuer. Ein konventioneller Renderer musste Geometrie transformieren, Polygone rasterisieren, Texturen lesen, Tiefentests ausführen und ein vollständiges Framebuffer-Bild schreiben. Speicherbandbreite war knapp, dedizierter Grafikspeicher teuer und viele Arbeitsschritte lagen noch auf der CPU.

Microsofts Ziel war deshalb eine Grafiklösung im Bereich von ungefähr 200 bis 300 US-Dollar, deren wahrgenommene Bildqualität und Komplexität an damalige 3D-Workstations heranreichen sollte. Die Architektur sollte außerdem nicht nur Spiele beschleunigen, sondern mehrere zuvor getrennte PC-Komponenten zusammenführen: 2D- und 3D-Grafik, Audio, MPEG-Wiedergabe, Videokonferenzen und sogar Modemfunktionen.

Die grundlegende Idee lautete: 

3D-Objekte nur bei Bedarf neu rendern
             ↓
Objektbilder als komprimierte Ebenen speichern
             ↓
Ebenen pro Bild günstig transformieren
             ↓
Ebenen mit Transparenz zum Ausgabebild zusammensetzen

Talisman nutzte damit sowohl räumliche Kohärenz – benachbarte Bildbereiche ähneln sich – als auch zeitliche Kohärenz – viele Inhalte verändern sich zwischen zwei Frames nur wenig.

Das Ebenenprinzip

Bei Talisman wurde ein bewegliches Objekt zunächst aus Polygonen in eine eigene zweidimensionale Bildebene gerendert. Zu dieser Ebene gehörten Farb-, Transparenz- und Tiefeninformationen. Solange sich Form, Beleuchtung oder Blickwinkel nicht zu stark änderten, konnte das gespeicherte Bild weiterverwendet werden.

Der Image Layer Compositor setzte die Ebenen mit hoher Rate zum sichtbaren Bild zusammen. Eine affine Transformation erlaubte dabei:

  • Verschieben,
  • Skalieren,
  • Rotation innerhalb der Bildebene,
  • Spiegeln und Scheren,
  • Filtern und Alpha-Compositing.

Eine solche Transformation kann bestimmte Bewegungen überzeugend vortäuschen, ohne alle Polygone erneut zu berechnen. Dreht sich ein dreidimensionales Objekt stark, werden zuvor verdeckte Flächen sichtbar oder verändert sich seine Beleuchtung, muss seine Ebene dagegen neu gerendert werden.

Microsofts Forschungsarbeiten ergänzten das Konzept um Qualitätsmaße, sogenannte Fiducials. Sie sollten abschätzen, wann eine wiederverwendete Ebene sichtbar vom korrekten Ergebnis abweicht. Auf dieser Grundlage konnten Aktualisierungsrate, Auflösung und andere Qualitätsparameter je Ebene angepasst werden. Wichtige Objekte ließen sich häufiger oder höher aufgelöst aktualisieren als kleine Hintergrundelements.

Chunking, Kompression und Mehrfachdurchläufe

Talisman verarbeitete Ebenen nicht nur als große rechteckige Bilder. Sie wurden in kleinere Bereiche oder Chunks zerlegt. Dadurch musste das System nur jene Teile lesen und bearbeiten, die für den aktuellen Bildausschnitt tatsächlich benötigt wurden.

Bild- und Texturdaten sollten breit komprimiert werden, um Speicherbedarf und Bandbreite zu senken. Die geplante Hardware konnte diese Daten während der Ausgabe wieder entpacken. Das war entscheidend, weil Talisman zwischen gespeicherten Ebenen, Texturen und dem Compositor große Datenmengen bewegen musste.

Außerdem setzte die Architektur auf Multi-Pass-Rendering. Komplexe Material- und Beleuchtungseffekte konnten in mehreren Durchläufen berechnet und anschließend kombiniert werden. Dieser Ansatz war für die damalige PC-Hardware ungewöhnlich ambitioniert, erhöhte allerdings auch die Anforderungen an Software, Speicherverwaltung und Synchronisation.

Geplante Referenzhardware

Microsoft entwickelte Talisman als Architektur und Referenzentwurf, nicht als eigene serienreife Microsoft-Grafikkarte. Mehrere Halbleiterhersteller sollten Komponenten oder kompatible Umsetzungen liefern.

Eine frühe Referenzimplementierung war als PCI-Erweiterungskarte vorgesehen. Dokumentiert sind unter anderem:

  • ein Media Signal Processor von Samsung mit einem ARM-RISC-Kern und einem programmierbaren Vektor-Coprozessor,
  • spezialisierte Logik für Polygon- beziehungsweise Bildverarbeitung,
  • ein Image Layer Compositor für Transformation, Filterung und Zusammensetzen der Ebenen,
  • lokaler Speicher für Grafik- und Mediendaten,
  • ein kleines Betriebssystem auf der Karte, das Module und Treiber vom Windows-PC laden konnte.

Der ARM-Kern übernahm Steuerungs- und Betriebssystemaufgaben. Der SIMD-artige Vektorprozessor war für rechenintensive Medienoperationen vorgesehen. Microsoft Research untersuchte sogar ein asymmetrisches Scheduling: Der ARM-Kern konnte normal präemptiv zwischen Threads wechseln, während der große Zustand des Vektorprozessors nur an vorbereiteten Kontrollpunkten gewechselt wurde.

Die geplante Karte war daher mehr als ein reiner 3D-Beschleuniger. In heutiger Sprache ähnelte sie teilweise einer Mischung aus GPU, programmierbarem Medienprozessor, Audio-DSP und eigenständigem Subsystem.

Software und DirectX

Talisman benötigte eine enge Zusammenarbeit zwischen Anwendung, Grafiktreiber und Hardware. Eine Engine musste Objekte sinnvoll in Ebenen zerlegen, deren Gültigkeit bewerten und entscheiden, wann echtes Neurendern erforderlich war. Ohne diese Informationen konnte die Hardware ihren wichtigsten Vorteil – die Wiederverwendung bereits berechneter Bilder – nur eingeschränkt ausspielen.

Microsoft wollte Talisman-Funktionen über seine Windows-Grafikschnittstellen zugänglich machen und verband dabei Ideen aus DirectDraw und Direct3D. Für bestehende Spiele blieb jedoch ein Kompatibilitätspfad nötig. Wenn eine Anwendung nur eine gewöhnliche unmittelbare 3D-Pipeline erwartete, konnte sie die spezielle Layer-Architektur nicht automatisch optimal nutzen.

Genau darin lag ein strategisches Problem: Talisman versprach den größten Gewinn bei speziell angepassten Anwendungen, während Entwickler gleichzeitig bereits Direct3D, OpenGL und herstellerspezifische APIs bedienen mussten.

Demonstration „Chicken Crossing“

Auf der SIGGRAPH 1996 zeigte Microsoft den animierten Kurzfilm Chicken Crossing. Er demonstrierte Talisman-Techniken in einer für damalige PCs aufwendigen Szene und sollte zeigen, dass die Kombination aus Ebenen, Wiederverwendung und Compositing workstationähnliche Darstellung zu deutlich geringeren Kosten ermöglichen könnte.

Die Vorführung belegte, dass das Grundprinzip funktionierte. Sie war jedoch kein Nachweis für eine allgemein verfügbare Grafikkarte oder dafür, dass beliebige Spiele ohne Anpassung gleich gut profitiert hätten.

Warum Talisman scheiterte

Talisman wurde nie als Endkundenprodukt veröffentlicht. Dafür kamen mehrere technische und wirtschaftliche Gründe zusammen:

  • Der Markt entwickelte sich schneller als erwartet: 3dfx, NVIDIA, ATI, S3 und weitere Anbieter steigerten Rasterleistung und Speicherbandbreite konventioneller 3D-Beschleuniger sehr schnell.
  • Spezialbehandlung in Anwendungen: Die besten Ergebnisse erforderten eine bewusste Zerlegung der Szene in wiederverwendbare Ebenen.
  • Begrenzte Wiederverwendbarkeit: Starke Perspektivänderungen, Verdeckungen, dynamische Beleuchtung, Schatten und komplexe Überschneidungen konnten ein Neurendern erzwingen oder sichtbare Näherungsfehler erzeugen.
  • Komplexe Gesamtarchitektur: Programmierbarer Medienprozessor, Spezialchips, Kompression, eigenes Scheduling und neue Softwarepfade mussten gemeinsam zuverlässig funktionieren.
  • Schwieriger Kompatibilitätspfad: Ein gewöhnliches Direct3D-Spiel konnte auf Talisman laufen, nutzte die besonderen Fähigkeiten aber nicht automatisch vollständig aus.
  • Sinkende Preise klassischer GPUs: Als entsprechende Referenzdesigns produktionsnah wurden, boten konventionelle Beschleuniger eine einfachere und zunehmend günstigere Lösung.

Das Scheitern bedeutet daher nicht, dass die technischen Ideen wirkungslos waren. Vielmehr verlor eine stark spezialisierte Architektur ihr wirtschaftliches Zeitfenster, bevor Hardware, Werkzeuge und ein breites Software-Ökosystem gleichzeitig bereitstanden.

Abgrenzung zu heutigen Hybrid-Grafiksystemen

Talisman darf nicht mit modernen Hybrid-GPU-Systemen wie NVIDIA Optimus oder einer Windows-Konfiguration aus integrierter und diskreter GPU verwechselt werden. Dort rendern zwei weitgehend vollständige Grafikprozessoren je nach Leistungs- oder Energiebedarf; häufig erzeugt die dGPU ein Bild, das über die iGPU ausgegeben wird.

Talisman kombinierte dagegen verschiedene Arten der Bildberechnung innerhalb einer neuen Architektur:

System Grundidee Ziel
Microsoft Talisman 3D-Objekte in wiederverwendbare 2D-Bildebenen rendern und per Compositor zusammensetzen Rechen- und Speicheraufwand hochwertiger Grafik senken
Modernes iGPU/dGPU-Hybridsystem Zwischen vollständigen GPUs umschalten oder das fertige Bild zwischen ihnen übertragen Akkulaufzeit und Leistung ausbalancieren
Direct3D-12-Explicit-Multiadapter Eine Anwendung verteilt eigene Aufgaben auf mehrere unabhängige GPUs Mehrere vorhandene Adapter parallel nutzen

Bedeutung aus heutiger Sicht

Talisman war keine Vorstufe moderner GPUs im geradlinigen Sinn. Heutige Grafikprozessoren folgen weiterhin überwiegend einer konventionellen, massiv parallelen Raster- und Compute-Architektur. Mehrere Talisman-Gedanken wirken aus heutiger Sicht dennoch erstaunlich vertraut:

  • temporale Wiederverwendung statt vollständiger Neuberechnung,
  • unterschiedliche Aktualisierungsraten für Bildbestandteile,
  • Rekonstruktion und Transformation bereits gerenderter Informationen,
  • Kachelung und Verarbeitung kleiner Bildbereiche,
  • Kompression zur Verringerung von Speicherbandbreite,
  • Trennung von 3D-Rendering und späterem Compositing,
  • programmierbare Prozessoren für Grafik-, Audio- und Videoaufgaben.

Moderne temporale Upscaler, Frame Generation, reprojizierte VR-Bilder, variable Shading-Raten und komprimierte Renderziele sind keine direkten Talisman-Nachfolger. Sie beruhen jedoch auf einem ähnlichen Grundgedanken: Ein glaubwürdiges neues Bild muss nicht in jedem Teil vollständig von Grund auf neu berechnet werden.

Fazit

Microsoft Talisman war der Versuch, die Grenzen damaliger PC-Hardware mit einer radikal anderen Aufteilung der Grafikarbeit zu umgehen. Echte 3D-Berechnung erzeugte Objektbilder; ein schneller 2D-Compositor verwandelte und kombinierte sie über mehrere Frames hinweg. Ergänzt um Kompression und programmierbare Multimedia-Verarbeitung sollte daraus eine günstige Allzweckkarte für Grafik, Ton und Video entstehen.

Technisch war das Konzept vorausschauend, praktisch aber zu spezialisiert und vom schnellen Fortschritt klassischer 3D-Grafikkarten überholt. Talisman blieb deshalb ein Forschungs- und Referenzprojekt – ein faszinierender Seitenweg der GPU-Geschichte, dessen zentrale Idee der zeitlichen Wiederverwendung heute aktueller wirkt als in den 1990er-Jahren.

Quellen

Abgerufen von „https://wiki.janvolkland.de/index.php?title=Microsoft_Talisman&oldid=155“