Render-Warteschlangen-Latenz, NVIDIA Reflex und AMD Anti-Lag: Beseitigung von GPU-gebundenem Input-Lag

Das Latenz-Paradoxon bei hohen Bildraten

Ein weit verbreiteter Irrglaube im PC-Gaming besagt, dass eine hohe Bildrate (Frames per Second, FPS) automatisch eine minimale Eingabelatenz garantiert. Viele wettbewerbsorientierte Spieler investieren beträchtliche Summen in High-End-Grafikkarten, reduzieren Details auf kompetitive Mindestwerte und beobachten zufrieden Bildraten zwischen 140 und 240 FPS – nur um bei schnellen Mausbewegungen ein schwammiges, verzögertes Reaktionsgefühl beim Zielen festzustellen.

Diese Diskrepanz beruht auf der Verwechslung von Durchsatz (Throughput) und Reaktionsgeschwindigkeit (Responsiveness):

+--------------------------------------------------------------------------+
|                  DURCHSATZ (Throughput) vs. REAKTIONSZEIT (Responsiveness)|
+--------------------------------------------------------------------------+
|  BILDRATE (Throughput / Durchsatz)                                       |
|  - Anzahl vollständiger Einzelbilder, die pro Sekunde ausgegeben werden. |
|  - Messgröße: FPS oder Frame-Dauer (Frametime, ms = 1000 / FPS).         |
|  - Bestimmt Bewegungskontinuität, Kantenklarheit und Flimmerfreiheit.     |
+--------------------------------------------------------------------------+
|  SYSTEMLATENZ (Responsiveness / Reaktionszeit)                           |
|  - Zeitspanne von der physischen Eingabe (Mausklick/-bewegung) bis zur   |
|    zugehörigen Lichtabstrahlung auf dem Monitor.                         |
|  - Messgröße: Ende-zu-Ende-Latenz (Millisekunden, ms).                   |
|  - Kann drastisch ansteigen, selbst wenn die durchschnittliche FPS hoch ist.|
+--------------------------------------------------------------------------+

Befindet sich ein Gaming-System im GPU-Limit (GPU-bound) – wenn die Grafikkartenauslastung permanent zwischen 98% und 100% verweilt –, verlagert sich der entscheidende Flaschenhals in die Software-Render-Warteschlange (Render Queue). Die CPU, entlastet von aufwendiger Grafikberechnung, simuliert die Spielwelt und generiert Render-Befehle (Draw Calls) wesentlich schneller, als die ausgelastete GPU diese abarbeiten kann. Um zu verhindern, dass die GPU mangels Befehlen in Leerlaufzyklen verfällt (Starvation), legen Grafik-APIs und Grafiktreiber überzählige Frames in einem Puffer ab.

Dieser Puffer stellt zwar sicher, dass die GPU stets voll ausgelastet bleibt und maximale Durchschnitts-FPS erzielt werden, verursacht jedoch erhebliche Latenzkosten: Die Spiel-Engine tastet die Mausposition in der CPU-Simulationsphase ab, doch das resultierende Frame muss in der Warteschlange hinter zwei bis drei vorangehenden Bildern ausharren, bis die GPU für dessen Berechnung bereit ist. Das Fadenkreuz auf dem Monitor spiegelt folglich Aktionen wider, die bereits zig Millisekunden zurückliegen.

Anatomie der Ende-zu-Ende-Latenzkette

Um den Ursprung der Warteschlangenlatenz zu lokalisieren, muss die gesamte Verarbeitungsstrecke von der physischen Betätigung bis zur Bildschirmanzeige nachvollzogen werden:

[ Eingabegeräte (Maus / Tastatur) ]
        |
        | 1. Peripherie-Latenz (Entprellzeit, MCU-Verarbeitung, USB-Polling)
        v
[ Betriebssystem & Engine-Hauptschleife ]
        |
        | 2. Eingabe-Abtastung & Simulation (CPU berechnet Physik, Kamera und Logik)
        v
[ Render-Thread (Render Thread) ]
        |
        | 3. Render-Übergabe (CPU erstellt Draw Calls und leitet sie an die Grafik-API weiter)
        v
+==========================================================================+
| 4. TREIBER- & API-RENDER-WARTESCHLANGE (Der Latenz-Flaschenhals)         |
|    - Staut sich an, wenn die GPU bei 99% - 100% Auslastung arbeitet      |
|    - Warteschlangentiefe: üblicherweise 1 bis 3 vorgerenderte Frames     |
|    - Zusätzliche Latenz: Puffer-Tiefe * Frametime                        |
+==========================================================================+
        |
        v
[ Grafikprozessor (GPU) ]
        |
        | 5. GPU-Ausführung (Geometrie, Rasterisierung, Pixel-Shading, Post-Processing)
        v
[ Anzeige-Pipeline ]
        |
        | 6. Frame-Präsentation (Present), V-Sync und Panel-Scanout
        v
[ Photonen erreichen das Auge des Spielers ]

Quantifizierung der Warteschlangenverzögerung

Betrachtet man einen Titel bei stabilen 60 FPS ($16,67\text{ ms}$ Frametime), so bewirkt ein Treiberpuffer von zwei vorgerenderten Frames:

$$\text{Warteschlangen-Latenz} = 2 \times 16,67\text{ ms} = 33,34\text{ ms}$$

Addiert man die Verarbeitungszeiten von Peripherie, Engine und GPU-Shading (angenommen $25\text{ ms}$), steigt die wahrnehmbare Gesamt-Latenz auf knapp $60\text{ ms}$.

Selbst bei 144 FPS ($6,94\text{ ms}$ Frametime) verursacht eine zweistufige Warteschlange noch rund $14\text{ ms}$ reine Wartezeit. In kompetitiven Gefechten, in denen Sekundenbruchteile über Treffer entscheiden, untergräbt diese schwankende Verzögerung das Muskelgedächtnis und führt zu spürbaren Zielungenauigkeiten.

Treiberbasierte Low-Latency-Modi vs. integrierte SDKs

Zur Beseitigung der Warteschlange setzten GPU-Hersteller anfangs auf reine Treibereingriffe. Mit dem Vormarsch moderner Low-Level-Grafik-APIs stießen diese Lösungen jedoch an architektonische Grenzen, was die direkte Integration in Spiel-Engines erforderte.

1. Treiber-Lösungen: NVIDIA Ultra-Low Latency und AMD Radeon Anti-Lag 1

Optionen in den GPU-Treiberpanels – etwa NVIDIAs „Modus für geringe Latenz“ (Aus, Ein, Ultra) oder AMDs ursprüngliches „Radeon Anti-Lag“ – greifen von außerhalb des Spielprozesses ein:

• Modus „Ein“ (On): Beschränkt die maximale Anzahl vorgerenderter Frames im Treiber von standardmäßig 2–3 auf strikt 1 Frame.
• Modus „Ultra“: Versucht, die Übergabe von Render-Befehlen zeitlich möglichst nah an den vertikalen Bildwechsel des Displays anzunähern (Just-In-Time).

Grenzen unter DirectX 12 und Vulkan

Treibereingriffe wurden für klassische APIs (DirectX 9 und DirectX 11) entwickelt, in denen der Grafiktreiber die vollständige Befehlsgewalt über Warteschlangen und Backbuffer besaß.

In modernen APIs wie DirectX 12 und Vulkan wurden die Zuweisung von Swapchains, Frame-Warteobjekten (wie DXGI_SWAP_CHAIN_FLAG_FRAME_LATENCY_WAITABLE_OBJECT) und das Befehls-Scheduling bewusst aus dem Treiber herausgenommen und der Engine anvertraut.

Da der Treiber Befehlslisten der Anwendung nicht eigenmächtig blockieren kann, ohne Abstürze (Deadlocks) oder heftiges Ruckeln (Micro-Stuttering) hervorzurufen, bleiben Treiber-Einstellungen für geringe Latenz in nativen DX12- und Vulkan-Spielen praktisch wirkungslos.

2. Native Engine-Integration: NVIDIA Reflex und AMD Radeon Anti-Lag 2

Um Warteschlangen in modernen Render-Pipelines zuverlässig zu eliminieren, wurde die Latenzsteuerung direkt in den Engine-Kern verlegt. Das NVIDIA Reflex SDK und das AMD Radeon Anti-Lag 2 SDK klinken sich direkt in die Simulations- und Renderschleifen ein:

TRADITIONELLE PIPELINE (GPU-Limitiert):
CPU: [ Sim 1 ][ Render 1 ][ Sim 2 ][ Render 2 ][ Sim 3 ][ Render 3 ]
GPU:                      [------- GPU-Render 1 -------][------- GPU-Render 2 -------]
Puffer:                   | Frame 2 wartet im RAM       | Frame 3 wartet im RAM
Latenz: Sehr hoch (Eingabe zu früh erfasst, liegt ungenutzt in der Warteschlange)

ENGINE-SYNCHRONISATION (Reflex / Anti-Lag 2 aktiv):
CPU:          [ Sim 1 ][ Render 1 ]         [ Sim 2 ][ Render 2 ]         [ Sim 3 ]
GPU:                               [-- GPU-Render 1 --]          [-- GPU-Render 2 --]
Puffer:                            | Keine Frames in Warteschlange| Keine Frames in Warteschlange
Latenz: Minimal (CPU wartet gezielt, bis die GPU frei wird; tastet Eingabe erst dann ab)

Mithilfe gezielter Synchronisationsmarkierungen im Quellcode (SetLatencyMarker(SIMULATION_START) und SetLatencyMarker(RENDERSUBMIT_START)) fragt die Engine den Abarbeitungsstatus der GPU kontinuierlich ab.

Erkennt das System eine GPU-Sättigung, generiert die CPU nicht vorschnell weitere Frames, sondern pausiert gezielt (Sleep). Sie verzögert die Abfrage von Maus und Tastatur bis zur letzten Millisekunde, bevor die GPU für neue Zeichenbefehle aufnahmebereit ist.

Dies bewirkt zwei wesentliche Verbesserungen:

1. Auflösung der Warteschlange: Die Warteschlangentiefe sinkt von mehreren Frames auf praktisch null.
2. Unmittelbar frische Eingaben: Steuerbefehle werden ohne Zwischenspeicherung direkt an die GPU übergeben, was die Reaktionszeit spürbar verkürzt, ohne Grafikdetails oder Durchschnitts-FPS zu opfern.

NVIDIA Reflex im Detail: „On“ vs. „On + Boost“

Spiele mit Reflex-Unterstützung bieten üblicherweise die Stufen On (Ein) und On + Boost (Ein + Boost). Die hardwareseitigen Unterschiede verdeutlichen, wann welche Option zweckmäßig ist:

+-------------------------------------------------------------------------------+
|                       NVIDIA REFLEX BETRIEBSMODI                              |
+-------------------------------------------------------------------------------+
|  Reflex Aus (Off)                                                             |
|  - Keine Synchronisation; Render-Warteschlange läuft bei GPU-Last voll.       |
|  - Höchster Brutto-Durchsatz, aber spürbar erhöhte und volatile Latenz.       |
+-------------------------------------------------------------------------------+
|  Reflex Ein (On)                                                              |
|  - Stimmt CPU-Simulation und GPU-Ausführung dynamisch aufeinander ab.         |
|  - Beseitigt Warteschlangen-Puffer bei GPU-Auslastung vollständig.            |
|  - Standardmäßige Taktsenkung und Energiesparmodi der GPU bleiben aktiv.      |
+-------------------------------------------------------------------------------+
|  Reflex Ein + Boost (On + Boost)                                              |
|  - Beinhaltet sämtliche Synchronisationsfunktionen von „Reflex On“.           |
|  - Verhindert das dynamische Heruntertakten der GPU (überschreibt P-States).  |
|  - Hält Kern- und Speichertakte auf Höchstniveau, selbst bei kurzem CPU-Limit.|
+-------------------------------------------------------------------------------+

Die tatsächliche Funktion des Boost-Modus

• Kein Overclocking: Boost hebt weder die maximalen Taktraten an noch hebelt es Temperatur- oder Leistungsgrenzen (TDP) aus.
• Vermeidung temporärer Taktabsenkungen: Im Spielverlauf wechseln offene Areale (GPU-Limit) und dichte Nahkämpfe mit vielen Spielermodellen (CPU-Limit mit sinkender GPU-Last) stetig. Sinkt die GPU-Auslastung kurzzeitig, senkt der Treiber zur Energieeinsparung die Taktraten auf niedrigere P-States ab.
• Wenn Sekundenbruchteile später eine Rauchgranate oder ein aufwendiger Partikeleffekt detoniert, benötigt die Grafikkarte einige Zyklen, um wieder voll hochzutakten – was Mikroruckler und Latenzspitzen zur Folge hat.
• Volle Taktbereitschaft: Reflex Boost unterbindet diese Taktruhezustände und hält die GPU permanent auf Höchstfrequenz, damit Lastspitzen verzögerungsfrei verarbeitet werden.

Empfehlung zur Moduswahl

• Desktop-PCs: Da Desktop-Rechner über ausreichende Kühlreserven verfügen, empfiehlt sich in Wettkampftiteln standardmäßig „On + Boost“.
• Gaming-Notebooks: Laptops nutzen zumeist gemeinsame Heatpipes für Prozessor und Grafikchip. Ein dauerhaft maximaler GPU-Takt kann das Kühlsystem überfordern und thermisches Throttling der CPU auslösen. Auf Notebooks ist daher das reguläre „Reflex On“ meist die stabilere Wahl.

Technischer Systemvergleich

Zusammenspiel mit G-SYNC, FreeSync und Frame-Limitern

Bei Bildschirmen mit variabler Bildwiederholrate (VRR) erfüllen integrierte SDKs eine essenzielle Sicherungsfunktion.

Viele Spieler aktivieren G-SYNC / FreeSync in Verbindung mit treiberseitigem V-Sync, um Tearing (Bildzerreißen) restlos zu unterbinden. Dabei droht eine Latenzfalle: Steigt die Bildrate über die maximale Bildwiederholfrequenz des Monitors, muss der Treiber Frames zurückhalten, um auf die vertikale Austastlücke zu warten. Dies erzeugt Rückstau im Anzeigepuffer und treibt die Latenz massiv in die Höhe.

Um dem entgegenzuwirken:

1. Automatischer Schutz-Cap: Registriert NVIDIA Reflex, dass G-SYNC und V-Sync parallel aktiviert sind, setzt es automatisch ein FPS-Limit knapp unterhalb der Monitorfrequenz.
   • Bei 144Hz regelt Reflex auf etwa 138 FPS ab.
   • Bei 240Hz regelt es auf etwa 225 FPS ab.
   • Bei 360Hz regelt es auf etwa 338 FPS ab.
2. Dadurch verbleibt die Darstellung dauerhaft im wirksamen VRR-Fenster: Bildzerreißen bleibt ausgeschlossen, während der gefürchtete V-Sync-Pufferstau gar nicht erst entstehen kann.

Praktischer Leitfaden zur Latenz-Optimierung

Je nach API und technischer Unterstützung des jeweiligen Titels empfiehlt sich folgende Vorgehensweise:

[ Spielunterstützung für Low-Latency prüfen ]
           |
           +-------------------------------------+
           |                                     |
           v                                     v
[ Spiel unterstützt Reflex / Anti-Lag 2 ]  [ Spiel ohne integriertes SDK ]
           |                                     |
           |                                     |
           v                                     v
1. Im Spiel aktivieren:                1. Grafik-API ermitteln:
   - NVIDIA: Reflex auf „On“             - Bei DX9 / DX11:
     (auf Desktops: „On + Boost“)          NVIDIA-Systemsteuerung ->
   - AMD: Anti-Lag 2 auf „Aktiviert“       Modus für geringe Latenz auf „Ultra“
2. Treiber-Overrides deaktivieren          AMD Software -> Anti-Lag auf „Ein“
   (Konflikte zwischen Treiber-Hook      - Bei DX12 / Vulkan:
    und Engine-Scheduler vermeiden)        Treiberseitige Optionen bleiben wirkungslos
3. Bei VRR-Monitoren:                  2. Manuelles FPS-Limit konfigurieren:
   - G-SYNC / FreeSync aktivieren        - In-Game-Limiter oder RTSS nutzen
   - V-Sync im Treiber aktivieren        - Limit 3 bis 5 FPS unterhalb Display-Hz setzen
   - Reflex regelt FPS-Cap automatisch   - Oder FPS so deckeln, dass GPU unter 95% Last bleibt

Wenn analysiert werden muss, ob eine zähe Maussteuerung durch Überlastung der GPU-Render-Warteschlange, Rückstau im V-Sync-Puffer oder Abweichungen der Peripherie-Abtastrate ausgelöst wird, bietet der Abgleich mit den fundierten Hardware- und Display-Diagnosen auf 365Finds verlässliche Orientierung, um Engpässe ohne blindes Experimentieren im Treiber aufzudecken.

Verifikation und Latenz-Telemetrie

Ob die Render-Warteschlange erfolgreich aufgelöst wurde, lässt sich über spieleeigene Leistungsanzeigen nachweisen:

1. Wichtige Telemetriewerte

• Game to Render Latency: Zeit von der Erfassung der Benutzereingabe bis zum Abschluss der Übergabe aller Render-Befehle durch die CPU.
• Render Latency: Zeitspanne, die die GPU benötigt, um das Bild vollständig zu zeichnen.
• PC Latency: Gesamtlaufzeit aus Eingabeabtastung, Simulation, Warteschlangenaufenthalt und GPU-Rendering.

Interpretation der Messwerte:

• Nicht optimierter Zustand (Warteschlange aktiv): $$\text{Render Latency} = 10\text{ ms}, \quad \text{PC Latency} = 38\text{ ms}$$ Die Differenz von $28\text{ ms}$ belegt, dass Frames knapp drei Zyklen lang im Arbeitsspeicher auf die Weiterleitung zur GPU warten.
• Optimierter Zustand (Reflex / Anti-Lag 2 aktiv): $$\text{Render Latency} = 10\text{ ms}, \quad \text{PC Latency} = 13\text{ ms}$$ Der Abstand schrumpft auf den reinen Verarbeitungsaufwand der CPU ($2-3\text{ ms}$), womit die vollständige Beseitigung der Warteschlange nachgewiesen ist.

2. Häufige Fehlerquellen

• Parallele Aktivierung von Treiber- und Engine-Modi vermeiden: Ist Reflex im Spiel aktiv, sollte im Treiberpanel nicht zusätzlich „Ultra“ forciert werden. Das gleichzeitige Eingreifen führt zu Scheduling-Konflikten und unruhigem Bildlauf (Frame Pacing).
• Reflex nicht für marginale FPS-Zuwächse abschalten: Das Deaktivieren von Reflex kann in Benchmarks scheinbar 1 bis 2 FPS mehr anzeigen, weil die GPU ungebremst ausgelastet wird; der Preis dafür ist jedoch eine Vervielfachung der Eingabeverzögerung um 20 bis 40 ms.

Referenzen

• Reflex SDK | NVIDIA Developer
• Introducing NVIDIA Reflex: Optimize and Measure Latency in Competitive Games | GeForce News | NVIDIA
• How To Reduce Lag - A Guide To Better System Latency | GeForce News | NVIDIA
• GitHub - GPUOpen-LibrariesAndSDKs/AntiLag2-SDK: The main repository for the AMD Radeon Anti-Lag 2 SDK. · GitHub
• Reduce latency with DXGI 1.3 swap chains - UWP applications | Microsoft Learn