An einem Tisch mit Mister Doom: Ein Interview mit John Carmack von id Software

Doom, Quake und Wolfenstein gehen alle auf sein Konto: Wir hatten Gelegenheit, uns mit John Carmack an einen Tisch zu setzen und sprachen mit ihm über den PC als Spieleplattform, Konsolen, iOS, Android - und mehr!

id Software feierte dieses Jahr sein zwanzigjähriges Firmenjubiläum, und so wie es aussieht, wird 2011 wieder ein Rekordjahr für den Spieleentwickler in Dallas. In ein paar Monaten wird Rage released, ebenso id Tech 5, die allerneueste Game-Engine von John Carmack. Beide Produkte sind die wichtigsten Releases seit Doom 3 (Mitte 2004), wenn man von Re-Releases und Produkten für Smartphones einmal absieht. Unseren Lesern müssen wir wahrscheinlich nicht erklären, wer John Carmack ist und was er, seit er 1991 zusammen mit drei Freunden id Software gegründet hat, alles geleistet hat.

Die Original-Releases und Fortsetzungen von Wolfenstein, Doom und Quake gelten nach wie vor als bahnbrechende PC Spiele und haben die Kategorie Ego-Shooter überhaupt erst geschaffen. Auch die Game Engines, auf denen diese Spiele basieren, gelten als innovativ, um nicht zu sagen revolutionär. Mittlerweile ist es wahrscheinlich klar geworden, dass der Autor dieser Zeilen ein “Fanboy” von id Software und ein großer Bewunderer des Werks von John Carmack ist, und so gesehen war es mir eine große Ehre, vor ein paar Wochen bei der Quakecon 2011 die Möglichkeit zu erhalten, den “Master of Doom” höchstpersönlich zu interviewen. Da das Thema “Rage” sowieso schon online zu Tode diskutiert wird, haben wir uns mehr über Computerhardware, Spielkonsolen und Smartphone-Games unterhalten – viel Spaß beim Lesen!

Devin Connors: Was hältst du von der neuesten Hardware von Intel und AMD?

John Carmack: Beim Kauf einer High-End Grafikkarte kann man mittlerweile fast nichts mehr falsch machen, denn die Hardware ist mittlerweile wahnsinnig schnell geworden. Es ist aber viel spannender, was sich derzeit am Low-End tut. Die integrierten Grafikeinheiten von Intel waren jahrelang nur ein schlechter Scherz – für Spiele völlig unbrauchbar. Aber jetzt seit der “Sandy Bridge”-Generation hat die integrierte Grafikeinheit plötzlich jene Hardwarefeatures und Programmierbarkeit, auf die wir immer gewartet haben. Man kann mit ihr zwar immer noch keine Frameraten-Rekorde aufstellen, aber zumindest ist jetzt eine gewisse Basisperformance da und auch alle benötigten Features, und sie ist jetzt für viele Spiele geeignet, wenn man z.B. die Auflösung herunterdreht.

Ich denke, bald landen wir in einer Welt, wo ich ein und dasselbe Spiel zu Hause mit einer High-End Karte auf dem 30-Zöller mit 2560x1600 und 16X MSAA spielen kann und dann im Flieger auf dem Notebook mit der integrierten Grafikeinheit halt mit 720p Auflösung. Spieleentwickler sollten beide Situationen im Auge behalten, die Grafikbandbreite sollte skalieren. Um ehrlich zu sein, wenn das Spiel viel Geometrie enthält, ist das natürlich viel schwieriger, denn Geometrie skaliert nicht so herunter wie Pixels.

DC: Du hast bei deiner Quakecon-Eröffnungsrede gesagt, dass Rage bereits auf Intels aktueller integrierter Grafikhardware läuft.

JC: Rage läuft auf den Intel IGPs, ja, aber noch nicht ganz mit der idealen Framerate. Wir liegen derzeit so um die 30 Frames pro Sekunde, aber das Spiel braucht an sich so an die 60. Und technisch gesehen gibt es keinen Grund, warum es bei niedrigeren Auflösungen nicht die 60 Frames erreichen könnte, aber leider hat Intel den Grafiktreiber nicht so optimiert wie Nvidia und AMD.

DC: Ist die Treiber-Situation der wunde Punkt der integrierten Intel-Grafik?

JC:  Intel arbeitet daran, aber Intel hat da nicht so viele Entwickler und Mittel hineingepumpt. Andererseits muss Intel derzeit auch noch nicht so viele unterschiedliche Modelle unterstützen. Was mir an Intel sehr gefällt ist, dass mehr Architekturdetails dokumentiert werden als bei AMD und Nvidia. Zum Beispiel hat Intel die komplette Chipspezifikation veröffentlicht, sodass Open-Source-Treiber geschrieben werden können. Für uns Spieleentwickler ist das toll, wenn wir in der Spec nachschlagen können: “Hmm – der Grafiktreiber baut hier Mist, aber die Hardware sollte das hier machen.” Wir können dann die Treiberentwickler anrufen und fragen, “Was geht hier schief, wie können wir diese Hardwarefunktion ansprechen?” Die Treiberleute haben jede Menge Arbeit, aber wenn wir die Möglichkeit erhalten würden, dass wir einfach alle Texturen im User-Speicher ablegen können und nicht ständig Textur-Updatefunktionen aufrufen müssen, das wäre schon ein großer Vorteil. Und es ist zweifelsohne denkbar, dass eine sündhaft teure Grafikkarte bei einer hohen Auflösung viel Zeit mit Sachen wie Texture-Transcoding verbrät und sie es dann schwerer beim Erreichen der 60 Hz hat als eine integrierte Grafikkarte, die direkten Zugriff auf den gesamten Hauptspeicher hat.

DC: Was hältst du von den neuen CPUs selbst? Was meinst du zu Entwicklungen wie AMD Fusion, wo die Grafikeinheit jetzt direkt neben der CPU sitzt?

JC: Naja, die Fusion-Chips haben zwar eine GPU neben der CPU auf dem gleichen Siliziumchip, aber noch besser wäre eine nahezu komplette funktionale Integration, wo sich CPU und GPU zumindest den Cache teilen und vielleicht sogar einige Funktionseinheiten.

DC: Bringt euch so ein integriertes Design Vorteile? Oder Nachteile?

JC: Einige Aspekte des bestehenden Designs erzielen schon jetzt ein gutes Preis-Leistungsverhältnis, wenn man per DirectX- oder OpenGL-APIs programmiert. Aber eine weitergehende Integration [in den Cache] wäre natürlich eine gute Sache, anstatt der getrennten Busse. Aber wo die Geschichte wirklich hochinteressant würde, das wäre eine enge Integration der GPU-Hardware in die CPU, wenn man also direkt aus dem CPU-Befehlssatz heraus Grafikoperationen ausführen könnte, genauso wie man derzeit SSE-Code schreibt. Wenn man Fusion-Code inline schreiben könnte, das würde ganz neue Möglichkeiten eröffnen. Aber in der Realität ist natürlich das Entwickeln in einer dreigeteilten Welt aufwändig, wenn man Intel, AMD und Nvidia unterstützen muss. Wir sind durchaus bereit, gewisse Hersteller-spezifische Optimierungen zu machen: Wir versuchen, Intel dazu zu bewegen, uns Direktzugriff auf die Texturen im Hauptspeicher zu geben, mit ATI machen wir multitext sub-image Updates und mit Nvidia haben wir sowieso schon immer zusammengearbeitet. Sollte uns die nächste Generation von Fusion neue, interessante Möglichkeiten bieten - inwieweit zahlt es sich aus, dafür speziellen Code zu schreiben, wenn es sich nur um einen Teil [Fusion] eines Teils [AMD] des Marktes handelt? So einen Aufwand macht man sich im Normalfall nur, wenn die Technologie in einer Spielkonsole verwendet wird.

DC: Hat euch AMD bezüglich Wunsch-Features für die neuen FX-CPUs gefragt?

JC: Wenn es um die optimale Aufteilung der Chipfläche einer neuen CPU in bestimmte Funktionseinheiten geht, halten wir uns als Spieleentwickler da ziemlich heraus. Wie ich schon erwähnt habe, waren neue CPU-Features nur vor vielen Jahren wichtig, zum Beispiel der erste 32-Bit-Adressraum oder die ersten Floating-Point-Units, das hat damals viel ausgemacht. Seither nimmt die Bedeutung von neuen Features eher ab, sogar Intels Übergang von P4 auf Core – die CPU-Architekten haben immer fantastische Arbeit geleistet und wir können uns darauf verlassen, dass eine neue Generation immer Vorteile gegenüber der vorigen haben wird und ausnahmslos auch schneller sein wird. Wir haben ein paar Codestellen für SSE3 optimiert und haben uns AVX angesehen, aber summa summarum wird die Performance eines Spiels von einer neuen Prozessorgeneration nur unwesentlich verbessert.