Macwelt: Was ist der Grund, dass Mac-OS X in OpenGL im Vergleich zu PCs so schlechte Leistung erbringt wenn der "Immediate Mode" statt Displaylisten/Vertex Arrays (siehe Glossar) genutzt wird, was beispielsweise deutlich wird wenn man Cinema 4D oder den Spec-Viewperf OpenGL-Benchmark laufen lässt? Manche Programmierer vermuten, dass es ein Little/Big-Endian-Problem ist, können Sie hier Licht ins Dunkel bringen?

Bruno Fernandes: Dieses Verhalten ist nicht aufgrund eines Endian-Problems, es ist vielmehr Teil der momentanen Treiberarchitektur. Wir arbeiten intensiv mit Apple zusammen um hier die Performance zu verbessern. Es gibt auch eine wachsene Anzahl an professionellen Anwendungen wie Modo, Final Touch, RealViz, Hash Animator, Motion und vielen mehr welche auf Display Listen und Vertex Arrays umstellen, dies ist also durchaus eine praktikable Alternative.

Macwelt: In einem anderen Interview erwähnten Sie, dass ATI einen Weg gefunden hat, Treiber zu entwickeln, die mit sehr wenig Aufwand auf Windows und Mac-OS portierbar sind. Angesichts der Leistung von neueren ATI-Chips seit dem Radeon 9600 ist ein Performancezuwachs messbar. Wie konnten Sie den großen Unterschied zwischen Windows und Mac-OS mit einem plattformübergreifenden Treiber überbrücken? Werden Sie diesen Entwicklungsansatz beibehalten?

Bruno Fernandes: Eigentlich sind nur spezifische Teile, der Kern des 3D-Treibers plattformübergreifend. Die übrige Infrastruktur ist Apple-spezifisch und wird massiv optimiert. Ganz speziell sind es die State- und Shader-Kompilations-Module die plattformübergreifend sind. Deren Code ist relativ Plattform-agnostisch und kann leicht auf den Mac portiert werden.

Andererseits sind das gesamte Vertex-Rendering, der Textur-Download und der Pixel-Kopier-Code Mac-spezifisch und auf die Mac-OS X Treiberarchitektur optimiert. Aller Wahrscheinlichkeit nach werden wir diese Entwicklungstrategie in absehbarer Zukunft beibehalten, denn durch diesen Ansatz können wir das Beste beider Welten nutzen: Wir können auf dem Mac sehr nahe an den Features der PC-Treiber bleiben und wir haben die Möglichkeit Mac-spezifische Optimierungen einzubauen wo immer wir können. Das Endresultat ist eine schnellere Entwicklung und höhere Performance.

Macwelt: Wie sehen Sie die Zukunft des Mac in Sachen OpenGL 2.0? Gibt es bereits APIs hierfür oder setzt Mac-OS X immer noch auf OpenGL-Erweiterungen um neue Grafikchip-Features zu nutzen?

Bruno Fernandes: Im allgemeinen setzt Apple auf öffentlich einsehbare OpenGL-Extensions (ARB, EXP und Apple-spezifisch) um ihre OS-Features zu implementieren. Fortschrittliche Tiger-Features wie Core Image, Core Video, Quartz Extreme 2D und Quartz Composer beispielsweise sind ausschließlich mittels öffentlicher OpenGL-Extensions implementiert. Zusätzliche GPU-Funktionen bietet Apple üblicherweise via OpenGL oder über eine andere offene API an. ATI arbeitet sehr eng mit Apple zusammen damit unsere Produkte und Treiber verfügbare und kommende APIs immer voll nutzen können. In Hinblick auf OpenGL 2.0 im Speziellen können wir keinen Kommentar abgeben bezüglich Apples Strategie.

Macwelt: Was ist ihrer Meinung nach der größte Fortschritt in Tiger? Ändern sich die Grafik- und 3D-APIs massiv? Wird PCI Express - wenn es einmal in Macs verfügbar ist - für Core Image/Video und Apples Motion ein Segen sein?

Bruno Fernandes: Der größte Fortschritt in Tiger ist, dass Apple von nur dem hardwarebeschleunigten Compositing in Panther auf voll hardwarebeschleunigtes Rendern aller Fenster-Inhalte umstellt. Core Image und Core Video sind auch bahnbrechend, da Apple das volle Potential der GPU-Programmierung den Usern in einer einfach zu programierenden Systembibliothek zur Verfügung stellt. Entwickler werden in der Lage sein GPU-basierte Shader-Effekte zu kreieren ohne eine einzige Zeile Shader-Code schreiben zu müssen. Diese können sie dann in ihre eigenen Anwendungen integrieren mithilfe von Apple-Werkzeugen wie Interface Builder und Quartz Composer. Für GPU-Hersteller ist Mac-OS X "the place to be". Damit dies in Tiger funktioniert musste das OpenGL-Interface für die Treiber nur sehr wenig verändert werden, aber es musste für neue Situationen optimiert werden und wir mussten viele Bugs beheben (lacht).

Die höhere Bandbreite von PCI-Express würde angesichts von PC-Testergebnissen höchstwahrscheinlich ein Segen für Grafik-Geräte sein, wir können jedoch keine Aussage zu PCI-Express-Verfügbarkeit auf der Macintosh-Plattform geben. Einen Schritt zu einer neuen Technologie wie diesen muss Apple selbst diskutieren oder bekanntgeben. Sollte ein solcher Schritt auf dem Mac stattfinden wäre ATI in einer sehr vorteilhaften Position, da wir der erste Hersteller mit einer vollständigen PCI-Express-Lösung waren. Als Firma haben wir eine Fülle an PCI-Express-Mitteln und -Erfahrung.

Macwelt: Sehen sie Potential für Optimierung der Treiber durch CPU-Features wie Altivec, 64 Bit oder anderen G5-spezifischen Charakteristika wie dem breiten Frontsidebus, Befehls-Gruppierung, seiner Hardware-Quadratwurzel und anderem? Da die meisten von ATIs zukünftigen Karten ohnehin nur für den G5 verfügbar sein werden scheint das Feintuning der Treiber speziell auf die stark verbesserte G5-Architektur nur ein logischer Schritt zu sein.

Bruno Fernandes: Wir nutzen bereits gewisse G5-Features und werden auch weiterhin unsere Software optimieren um das Potential der Plattform voll zu nutzen. Wir setzen stark auf Apples Performance-Tools wie Shark und prüfen beziehungsweise nutzen bereits das Befehls-Gruppieren des PowerPC 970, Altivec, Prefetch und so weiter. Apple investiert auch viel Zeit in die Optimierung an ihrem Ende der Treiber-Kette. Diese Optimierungen helfen meistens in CPU-limitierten Fällen, also arbeiten wir auch weiterhin an Füllraten-Optimierungen, von denen viele Spiele und Anwendungen in höheren Auflösungen profitieren können.

Macwelt: Haben sie Pläne ihre FireGL-Karten aus der Profi-3D-Liga auch für den Mac zu veröffentlichen oder gibt es technische Gründe, warum diese in Mac-OS X nicht funktionieren können? Mit der Veröffentlichung von mehr und mehr professioneller 3D-Software auf dem Mac sollte es für solche Karten durchaus einen Markt geben.

Bruno Fernandes: Der Großteil der Mac-Boards sind bereits professionelle Designs und Konfigurationen. Obwohl sie nicht notwendigerweise eine identische Ausstattung wie unsere Retail-FireGL-Karten oder die unserer Partner haben sind sie sehr ähnlich und bieten viele ähnliche Features. Alle aktuellen G5-Boards haben beispielsweise doppelte digitale Ausgänge und die neue Radeon X800 unterstützt auch Dual-Link DVI für sehr hohe Auflösungen wie bei Apples 30-Zoll-Cinemadisplay.

ATI verfolgte auf dem Mac immer eine Einzel-Strategie im Gegensatz zur Welt der Windows-Treiberarchitektur. Wir sehen den Mac als High-End-Plattform. Momentan unterscheiden wir nicht zwischen Consumer- und Workstation-Treibern auf dem Mac - es gibt nur einen Treiber. Wir streben nach höchster Performance sowohl in Profi-Anwendungen wie auch in Spielen. Wir stehen in regelmäßigem Kontakt mit dem Großteil der Profi-Softwarehersteller um ihnen bei der Behebung von Bugs und dem Optimieren der Performance bei unseren Mac-Karten zu helfen. Mac-Enthusiasten und Professionelle sollten sich wegen dem Fehlen der speziellen "Fire GL"-Marke auf ihrer Plattform keine Gedanken machen, denn sie bekommen bereits das beste, was unsere Hard- und Software zu bieten hat. Kurz gesagt bieten unsere Mac-Produkte das beste beider Welten für die gesamte Kundenbasis.

Macwelt: Die Wireframe-Performance war bei ATI-Karten immer schlechter als bei Nvidia-Karten. In Spielen, in denen ATI meistens besser abschneidet ist dies kein Problem, aber professionelle User würden bessere Wireframe-Leistung, am besten noch mit Antialiasing, sehr begrüßen. Sehen Sie hier ein Potential für Verbesserung der Treiber oder ist dies eine Hardware-Limitierung die nur durch das Verwenden der Pro-Versionen der Chips (=FireGL) umgangen werden kann?

Bruno Fernandes: Hier gibt es definitiv Potential für Verbesserung. Es scheint hauptsächlich ein Problem der Treiber-Architektur zu sein das mit neuer Software behoben werden kann, es wird hierzu jedoch mehr brauchen als ein einfaches ATI-Treiberupdate. Das Verbessern unserer Linien-Zeichenperformance wird eine enge Zusammenarbeit mit Apple erfordern - und Apple ist letztendlich verantwortlich dafür, dieser Arbeit Priorität zukommen zu lassen. Wir arbeiten ständig mit Apple um die Treiber zu optimieren und neue "Fast paths" zu implementieren.

• Beim Immediate Mode werden nur reine Polygondaten an die Karte geschickt, für jeden Frame alle Daten aufs neue. Dies hat den Vorteil, dass es in allen Fällen richtig dargestellt wird, wenig VRAM-Speicher braucht, sehr flexibel/kompatibel ist und die CPU die volle Kontrolle über die Geometrie behält.
• Displaylisten sind der modernere Ansatz, hierbei cached die Karte die Geometriedaten und es werden lediglich die Änderungen übertragen, welche dann auf die entsprechende gecachete (und damit fixe) Geometrie angewendet werden. Gute Beispiele sind etwa die Rotation, Verschiebung oder Skalierung der ganzen Szene oder von einzelnen Objekten.
• Bei Vertex Arrays werden mehrere Vektorpunkte zu einem Objekt zusammengefasst, das dann einfach per Index adressiert und modifiziert werden kann, beispielsweise für eine Transformation der Geometrie. Vertex Arrays sind flexibler als Displaylisten, die lediglich simple Veränderungen wie Rotation, Scheren, Skalieren und Bewegen erlauben. Für eine animierte Spielfigur eignen sich beispielsweise Vertex Arrays besser, für den Hintergrund Displaylisten.
Displaylisten und Vertex Arrays sind bei Spielen der Standard, für 3D-Software sind sie allerdings deutlich schwieriger zu implementieren, da im Gegensatz zu einem Spiel die Geometrie, welche die Engine rendern muss nicht schon bekannt ist, denn der Anwender kann schließlich modellieren was er will. Die Geometrie eines Spiels legen die Entwickler fest, die auf diese dann auch gut optimieren können.
Ist die Anwendung schon im Immediate Mode von der Füllrate der Karte limitiert bringt eine Umstellung auf Display Listen oder Vertex Arrays nichts. Displaylisten und Vertex Arrays bringen nur etwas, wenn die Leistung von der CPU oder dem Bus beschränkt wird

Als Fast path (schneller Pfad) bezeichnet man allgemein den Nutzungsmodus einer Hardware, der stark auf hohe Performance optimiert ist. Viele Features von Grafikkarten werden nur selten genutzt, also konzentriert man sich bei der Treiberentwicklung auf die populärsten Fälle ("Pfade") und versucht diese möglichst schnell zu machen.

Die FireGL-Serie ist ATIs Profi-3D-Beschleuniger-Serie, bei Nvidia heisst diese "Quadro". Beide Hersteller nutzen für ihre Profi-Versionen letztendlich dieselben Chips wie in ihren Consumer-Linien (Radeon/Geforce), die Profi-Versionen haben jedoch eigene Firmware und speziell auf Profi-3D-Anwendungen optimierte Treiber, auch im Chip sind einige zusätzliche Features freigeschaltet, die auf den Consumer-Karten inaktiv sind. Die Profi-Serien zeichnen sich normalerweise durch bessere Wireframe-Performance und höhere Genauigkeit beim Rendern und im Z-Buffer aus, da dies primär im Workstation-Bereich wichtig ist.

Die meisten RISC-CPUs -wie eben die PPC-CPUs- nutzen den "Big Endian"-Modus, in dem Zahlen, die größer sind als ein Byte in der richtigen Reihenfolge dargestellt werden. Das bedeutet: die Zahl 49152 ist in 2-Byte-Darstellung hexadezimal c0 00 und wird auch so im Speicher abgelegt. Little-Endian-CPUs, wie beispielsweise x86-CPUs stellen die Zahl umgekehrt dar, mit dem niedrigeren Byte zuerst (also 00 c0).
Bei Code ist die "Endian-Ness" egal, denn der Compiler generiert das automatisch richtig. Aber bei vielen Dateiformaten und Low-Level-Optimierungen (wie beispielsweise Treibern) spielt die Endian-Ness eine Rolle.
Die Endian-Ness war der Grund, warum Virtual PC auf G5s zuerst nicht funktionierte. Im Gegensatz zum Power4-Derivat G5 sind G3s und G4s nämlich -wie Alpha, ARM, PA-RISC und MIPS- "bi-endian", das heisst sie beherrschen beide Modi. Mittels eines Kommandos kann zwischen beiden Modi umgeschaltet werden. Virtual PC ist allerdings das wohl einzige Programm, das den Little-Endian-Modus der G3s und G4s genutzt hat, da die x86-Emulation logischerweise davon massiv profitiert. Ohne den Little-Endian-Modus müssen Werte nämlich zuerst umgedreht werden, bevor die CPU damit rechnen kann.