Raytracing in Spielen IV: Ray-Tracing in der Cloud

Performance

Hier sind einige Beispielsszenen und Angaben zur Performance von unserem Cloud-basierten Setup.

78 fps		53 fps
66 fps		70 fps
62 fps		38 fps

Latenz

Zwei Begriffe, die im Bereich der Netzwerktechnologie häufig verwendet werden, sind Bandbreite und Latenz. Wir wollen beide und ihre Bedeutung für Cloud-basiertes Ray-Tracing an dieser Stelle noch etwas näher erläutern.

Bandbreite: Die Menge an Daten, die über ein Netzwerk von einer bestimmten Quelle zu einem bestimmten Ziel in einer gegeben Zeit transportiert werden kann. Das können z.B. 6 Mbit pro Sekunde bei DSL sein, oder 1000 Mbit pro Sekunde bei einem Gigabit-Ethernet. Bandbreite wird oft mit einer Autobahn verglichen und der Anzahl an Spuren: Doch auch wenn es zwischen Würzburg und Frankfurt 1000 Spuren gäbe, so würde ein einzelnes Auto deswegen auch nicht 1000-mal schneller ankommen – das ist Latenz.

Latenz: Beschreibt die zeitliche Verzögerung beim Senden eines Netzwerkpakets von einer Quelle zum Ziel. Latenz hat einen hohen Einfluss auf das Erlebnis von Cloud-basierten Spielen. Die Latenz von einer Maschine zu einer anderen und zurück kann über den Ping-Befehl ermittelt werden.

Unter der Annahme, dass die Bandbreite nicht der limitierende Faktor ist, kommt die Latenz von der physikalischen Limitierung der Geschwindigkeit des Lichts und von den Verzögerungen durch verschiedene Sprünge (hops), die ein Netzwerkpaket von einer physikalischen Verbindung zu einer anderen (über Router, Switches etc.) zurücklegt, und durch die (Software-)Schichten, die es überqueren muss, um ins Betriebssystem und letztendlich zur Anwendung zu gelangen.

Die Bandbreite beeinflusst hingegen die Qualität der Bilder, die der Spieler im Cloud-basierten Setup erhält. Diese stieg in den letzten Jahren bei den heimischen Internet-Anschlüssen kontinuierlich und man kann erwarten, dass dies auch weiterhin der Fall sein wird.

Die (gesamte) Latenz beeinflusst, wie lange es dauert, dass nach einer Mausbewegung das passende Update dazu auf dem Monitor erscheint. Man mag dabei zuerst vermuten, dass dies nur von der Netzwerk-Latenz abhängt, jedoch gibt es dabei viele andere Faktoren zu berücksichtigen, um ein gutes Spieleerlebnis zu ermöglichen. In den folgenden Schritten, die den Prozess vom Eingabegerät bis zur Aktualisierung auf dem Bildschirm bei einem Cloud-basierten Spiel zeigen, wird die Annahme einer Zielframerate von 60 Hz gemacht. Dies bedeutet, dass auf jedes Bild 16,66 ms entfallen, was wir der Einfachheit halber auf 17 ms runden. Es wird eine Netzwerk-Latenz von 80 ms für einen Rundtripp (40 ms pro Richtung) angenommen.

Der Weg vom Eingabegerät zum Update auf dem Monitor.

• Schritt 1 (Eingabegeräte): In den neuesten Betriebssystemen von Microsoft werden Geräte, die über USB eingesteckt sind, in der Standardeinstellung mit einer Frequenz von 125 Hz abgefragt. Dies kann im schlechtesten Fall zu 8 ms Latenz führen. Es gibt einige Modifikationen und herstellerspezifische Maustreiber, die diese Abtastrate auf z.B. 1000 Hz verändern können. Oft haben schnurlose Tastaturen und Mäuse eine noch höhere Latenz und sollten daher vermieden werden, um Lag zu vermeiden.
• Schritt 2: Nachdem die Bewegungen der Eingabegeräte verarbeitet wurden, kann es etwas dauern, bis der Spiele-Client an der richtigen Stelle des Codes ist, um diese Bewegungen auszuwerten. Beispielsweise könnte der Client momentan noch mit anderen Berechnungen beschäftigt sein (im Falle eines Single-Threaded-Spiele-Clients könnte dieser gerade den letzten Frame empfangen oder ihn gerade auf die Grafikkarte hochladen). Die maximale Verzögerung könnte also einen Frame (17 ms) betragen. Mit Multi-Threading könnte man diese Verzögerung reduzieren.
• Schritt 3: Nachdem alle Bewegungen ausgewertet wurden, wird ein Netzwerkpaket mit Daten wie der aktualisierten Spielerposition an den Server geschickt und benötigt dabei die angenommenen 40 ms. Allgemein trägt es zur Verringerung von Netzwerklatenz bei, wenn Server nahe gelegen sind und Pakete so nur wenige „Hops“ benötigen. Einige Router haben spezielle Optimierungen, um Netzwerkpakete für Online-Gaming zu priorisieren, was für den ersten Hop vom Client zu dem mit dem Internet verbundenen Router helfen könnte.
• Schritt 4: Nun hat der Server die aktualisierten Informationen empfangen. Unter der Annahme, dass dieser mit dem Rendern des vorherigen Bildes bereits fertig ist, können die Daten sofort verwendet werden. Allerdings benutzen Spiele oft eine Methode, bei der mehrere Frames gleichzeitig gerendert werden. Der Vorteil davon ist, dass es zu einer höheren und ausgeglicheneren Performance führt, da die Berechnungen zum Rendern und den Updates der Szene nie ausgehen und es daher immer etwas zu tun gibt. Standardeinstellungen dafür sind in einigen Grafiktreibern bis zu drei Frames zum Vor-Rendern zu erlauben. Dies würde allerdings zu weiteren 50-ms-Latenz (3 x 17 ms) führen. In einem Setup mit mehreren Maschinen, die jeweils ein spezifisches Bild berechnen, gibt es darüber hinaus weitere Latenzen. Wie bereits zuvor erläutert, würde ein kachelbasierter Ansatz helfen, diesen Overhead zu verringern. Nachdem ein Bild gerendert ist, muss es in den Hauptspeicher gebracht werden. Der Frame kann entweder direkt auf dem Gerät, das zum Rendern benutzt wurde, oder auf der CPU komprimiert werden. Nachdem der Server meist sehr leistungsstark ist, benötigt diese Komprimierung nur einen kleinen Zeitaufwand (ca. 2 ms für DXT1 bei 1280x720).
• Schritt 5: Der komprimierte Frame wird zum Client geschickt, was 40 ms benötigt.
• Schritt 6: Zurück beim Client muss das komprimierte Bild dargestellt werden. Entweder kann er direkt auf die Grafikkarte hochgeladen werden (z.B. durch die Unterstützung von DXT1-Texturen), oder er muss manuell dekomprimiert werden. Nachdem der Client meist leistungsschwach ist, kann man diesen Schritt um ein Frame verzögern: während der Client den nächsten Frame über das Netzwerk erhält, kann er den aktuellen dekomprimieren. Dies ergibt weitere 17 ms an Latenz, könnte aber notwendig sein bei kleinen Endgeräten. Das Hochladen der Farbdaten vom Speicher des Clients zur Grafikkarte zum Anzeigen benötigt auch etwas Zeit. Auch dies kann asynchron geschehen, was wieder weitere 17 ms an Latenz hinzufügen würde, aber erneut im Falle eines schwächeren Clients notwendig sein könnte. Sollte das Bild über eine Textur hochgeladen werden und dann auf einem Vollbild-füllenden Quad angezeigt werden, z.B. über DirectX, so sollte man sicherstellen, dass die Grafikkarteneinstellungen des Clients nicht zusätzliche Verzögerungen durch die Anzahl der maximal erlaubten Pre-Renderings hinzufügt.
• Schritt 7: Im letzten Schritt muss das herausgeschickte Bild von der Grafikkarte auf dem Monitor angezeigt werden. Neben der Limitierung, dass die meisten Flachbildschirme eine Limitierung von 60 Hz haben und dadurch weitere Latenz zur korrekten Synchronisation hinzufügen können, gibt es noch einen anderen wichtigen Faktor genannt „Input Lag“: es beschreibt den Zeitunterschied zwischen dem Senden eines Signals zum Monitor bis zu dem Moment, in dem man den neuen Inhalt auf dem Bildschirm sieht. Der Unterschied wird durch die Signalverarbeitung von Flachbildschirmen verursacht. Das könnte beispielsweise die Interpolation auf eine andere Auflösung sein. Es gibt einen sehr detaillierten Test auf Prad.de, der Input Lag zwischen 0 und 45 ms gemessen hat (sogar ohne die Synchronisation auf 60 Hz). Diese Werte sollten nicht mit den Reaktionszeiten verwechselt werden, die Monitorhersteller oft angeben (z.B. 2 ms von Grau zu Grau für einen Spielemonitor).

Die gesamte Latenz ist also nicht nur von der Netzwerk-Latenz abhängig, sondern auch von der Auswahl an Eingabegeräte, Monitoren und den möglichen Softwareimplementierungen in Bezug auf Pufferungen. In verschiedenen Szenarien kann man leicht einen Unterschied der Größe von über 100 ms Latenz feststellen, unabhängig von der Netzwerk-Latenz.

		Beispiels-Szenario 1		Beispiels-Szenario 2
Schritt 1 (Eingabegeräte)		8		1
Schritt 2 (Thin Client)		17		17
Schritt 3 (Netzwerk)		40		40
Schritt 4 (Cloud)		50 (dreifach gepuffert)		17 (einfach gepuffert)
Schritt 5 (Netzwerk)		40		40
Schritt 6 (Thin Client)		17 + 17		17
Schritt 7 (Monitor)		45		0
Total		234		132