NVIDIA LDAT - Latency Display Analysis Tool vorgestellt und ziemlich exklusiv getestet | Seite 2

Wie entstehen eigentlich Latenzen?

Um den Sinn zu verstehen, muss man natürlich auch erst einmal etwas tiefer uns System abtauchen. Betrachten wir deshalb erst einmal die Maus und den verschlungenen Weg vom eigentlichen Klick des Spielers bis hin zum fertig gerenderten Pixel auf dem Bildschirm. Im Gegensatz zum PS/2 hängen aktuelle Mäuse ja meist am USB, mit allen Vor- aber auch Nachteilen bei Zugriff und Transferrate. Da der USB im sogenannten Polling-Modus betrieben wird, gibt es im Gegensatz zu PS/2 keine eigentlichen Interrupts für ein Gerät.

Eine angeschlossene USB-Maus kann jedoch, wenn sie eine Aktion melden möchte, ein Interrupt-Paket bereitlegen, welches sofort nach dem Erhalt eines IN-Tokens an den Host zurückgegeben wird. Der Host antwortet darauf mit einem ACK und führt den Interrupt aus. Soll kein Interrupt ausgeführt werden, so legt die Funktion ein NAK bereit. Das Problem entsteht nun beim Auftreten sehr vieler solcher Pakete in kürzester Zeit, also wenn z.B. ein geübter Spieler dem Extrem-Klickmatismus verfällt.

Theoretisch kann der USB zusätzlich noch unter Geschwindigkeitsproblemen leiden, wenn viele Geräte gleichzeitig angeschlossen sind. Wenn also z.B. Tastatur, Drucker, Scanner und Webcam am gleichen USB-Controller hängen und gleichzeitig Daten übertragen wollen, dann wird es schon mal recht eng und es kommt zu ersten Wartezeiten. Denn diese Geräte müssen sich nun mal die mögliche Bandbreite teilen. Die Verbindung (pipe) zu einem Gerät kennt vier Arten der Datenübertragung:

– Die Kontroll-Transfers (Fehlerkorrektur)
– Bulk-Transfers (Große Datenmengen beim Scannen, Drucken, Dateikopieren, Busauslastung bis zu 100%)
– Interrupt-Transfers (z.B. Tastatur, Maus)
– Isochrone Transfers (Sprache, Video, Multimedia, Busauslastung maximal 80%)

Rein technisch wäre es zwar möglich, exklusive Bandbreitenreserven und minimalste Latenzen für die Interrupt-Transfers auf dem Bus zu garantieren, leider geben dies normale USB-Controller in dieser Form für einzelne Anschlüsse oder Geräte nicht her. Hier müsste eine spezielle Lösung entwickelt werden, die sicher nicht wirklich billig wäre und auch in keinem Verhältnis zum Aufwand stünde. Seit Win32 schlängelt sich jede Tastaturinformation durch einen Wust von Ebenen und Treibern, leider:

Doch der USB samt angeschlossener Maus (Rot) allein ist nicht der ganze Vorgang, wie das nachfolgende Block-Schema zeigt. Denn neben der sogenannten „Peripheral Latency“ spielen auch der eigene Computer mit der „PC Latency“ und die „Display Latency“ eine wichtige Rolle in dieser kausalen Kette des Verzögerns, die man auch als „End-to-End System Latency“ bezeichnen könnte. Auch hier möchte ich für den Rest noch die wichtigsten Bereiche für all diejenigen erklären, die mit den Abkürzungen und Bezeichnungen des Schemas nicht auf Anhieb klarkommen.

Einige der im Schema erkenntlichen Bereiche, in denen eine Latenz auftritt, sind wichtiger als andere. Die Render-Warteschlange und die GPU bilden einen dieser Bereiche, der als „Render-Latenz“ bezeichnet wird. Während die Reduzierung der Bildschirmauflösung und/oder der Spielgrafik-Einstellungen die Render-Latenzzeit durchaus senken kann (nicht unbedingt bevorzugt), ist eine schnellere GPU dann wohl doch eher das Mittel der Wahl. Und wer jetzt noch die kommenden Launches für Grafikkarten und Prozessoren vor Augen hat, weiß auch, warum ich etwas darauf herumhacke.

Den neben der GPU gibt es auch für die CPU wichtige Aufgaben wie die Spielsimulationsverarbeitung, den Render Submit und den Grafiktreiber, der nun einmal auf der CPU läuft – dies alles wird primär auch durch die Geschwindigkeit der CPU beeinflusst. Wer im Spiel Latenzen feststellt, die nicht ursächlich an der Grafikkarte oder dem Display festzumachen sind, braucht auch eine schnellere CPU. Da wir hier ja aber nicht im Verkaufs-Thread sind, komme ich besser wieder zurück zum Block-Diagramm und den einzelnen Stationen:

Maus HW – Dies ist definiert als der erste elektrische Kontakt, den die Maus erfasst. In der Maus gibt es allerdings bereits einige Routinen (z.B. Entprellen), die die Latenzzeit bis zum gemeldeten Drücken der Maustaste erhöhen können.
Maus USB HW – Die Maus muss auf die nächste Abfrage warten, um die Pakete zu senden. Diese Zeit wird in USB HW wiedergegeben.
Maus USB SW – Maus USB SW ist die Zeit, in der das Betriebssystem und der Maustreiber das USB-Paket verarbeiten (siehe auch erstes Schaltbild für den Signalweg durch die Software-Layer).
Sampling – Dieser Abschnitt kann je nach der Framerate der CPU wachsen oder schrumpfen. Klicks können Betriebssystem-basiert nur mit einer Polling-Rate von maximal 1000 Hz übertragen werden. Dies bedeutet, dass der Klick möglicherweise warten muss, bis er im Spiel erfasst und ausgewertet werden kann. Diese Wartezeit wird Sampling genannt.
Simulation (Sim) – Spiele müssen den Zustand der Welt ständig aktualisieren. Diese Aktualisierung heißt Simulation. Die Simulation umfasst Dinge wie Animationen, den Spielstatus und Änderungen aufgrund von Spielereingaben/Interaktionen. Bei der Simulation werden dann auch die Mauseingaben auf den Spielstatus angewendet.
Render-Submission – Sobald die Simulation herausfindet, wo und wie die Dinge im nächsten Frame platziert werden sollen, beginnt sie mit dem Senden von Render-Jobs an die Grafik-API-Runtime. Die Laufzeitumgebung übergibt dann die eigentlichen Rendering-Befehle an den Grafiktreiber.
Grafiktreiber (Driver) – Der Treiber ist für die Kommunikation mit der GPU und das Senden von Befehlsgruppierungen an die GPU verantwortlich. Je nach Grafik-API übernimmt der Treiber diese Gruppierung (Queue) für die Engine oder diese zeichnet für die Gruppierung von Rendering-Arbeiten selbst verantwortlich.
Render-Warteschlange (Queue) – Sobald der Treiber die Aufgabe erfasst, wird sie in die Render-Warteschlange (Queue) aufgenommen. Die Render-Warteschlange ist so konzipiert, dass der Grafikprozessor ständig mit Arbeit versorgt wird, indem man so viel wie möglich vorhält. Dies geht jedoch stets ein wenig auf Kosten der Latenz, sorgt aber auch für eine gleichmäßigere Abarbeitung.
Rendern – Die Zeit, die der Grafikprozessor benötigt, um die gesamte mit einem einzelnen Frame verbundene Aufgabe zu rendern.
Zusammensetzung (Composite) – Abhängig vom jeweiligen Anzeigemodus (Vollbild, randlos, mit Fenster) muss der Desktop Windows Manager (DWM) einige zusätzliche Rendering-Arbeiten erledigen lassen, um den Rest des Desktops für einen bestimmten Frame zusammenzusetzen. Dies kann ebenfalls zu zusätzlicher Latenz führen. Deshalb ist der (exklusive) Vollbildmodus immer die erste Wahl!
Scanout – schließlich erfolgt der Flip (der aktuell angezeigte Frame-Puffer wird in den neu fertiggestellten Frame-Puffer ausgelagert) und der eigentliche Scanout wird geplant. der Scanout steuert die Anzeige Zeile für Zeile, basierend auf der Bildfrequenz der Anzeige (Monitor-Display).
Display Processing (Anzeigeverarbeitung) – Die Anzeigeverarbeitung ist die Zeit, die die Anzeige benötigt, um die eingehenden Scanzeilen zu verarbeiten und die Pixelantwort zu initiieren.
Pixel Response (Pixelantwort) – Dies ist die Zeit, die von dem Zeitpunkt, an dem das Pixel den neuen Farbwert erhalten hat, bis zur ersten erkennbaren Änderung durch LDAT (und den Spieler als Betrachter) vergeht.