Zurück zum Benchmark

Methodik

Wie dieser Benchmark Signale erzeugt

Diese Seite dokumentiert, wie WebGPUStress Last erzeugt, Framedaten erfasst, Metriken ableitet und Ergebnisse in praktische Interpretationen übersetzt.

Methodik-Version: M-2026.03

1. Kontrollierte Workload-Erzeugung

Eine dauerhafte WebGL-Shader-Last läuft mit gewählter Auflösung, Qualität und Ziel-FPS-Profil.

2. Kontinuierliches Frame-Sampling

Während des Laufs erfasst jedes Sample Framerate, Frame-Time-Verteilung und Verhalten unter Ziel-FPS.

3. Ableitung der Metriken

Durchschnitts-FPS, 1% Low FPS, Frame-Time-Spread und Drop-Rate werden aus dem Sample-Stream berechnet.

4. Stabilitätsbewertung

Ein normalisierter Stabilitätswert (0-100) fasst Pacing-Qualität und anhaltende Unterschreitungen zusammen.

5. Lesbare Bewertung

Schwellenwertlogik ordnet Rohmetriken praktischen Kategorien zu: Stabil, Genau beobachten oder Instabil.

Metrikdefinitionen

MetrikWas sie darstelltInterpretationshinweis
Durchschnitts-FPSDauerhafter Durchsatz für das gewählte Profil.Ein hoher Durchschnitt allein garantiert kein glattes Pacing.
1% Low FPSLeistung in den langsamsten dauerhaften Momenten.Großer Abstand zum Durchschnitt deutet auf Stotterrisiko hin.
Frame-Time-Spread (P95-P50)Konsistenzfenster für Frame-Auslieferung.Steigende Streuung weist oft auf Instabilität unter Last hin.
Drop-Frame-RateZeitanteil unter der gewählten Ziel-FPS.Hohe Rate bedeutet meist Profilüberlastung oder Throttling.
Stabilitätswert (0-100)Kombinierter Konsistenzindikator über den Lauf.Immer mit Profileinstellungen und Laufdauer interpretieren.

Checkliste für Reproduzierbarkeit

  • Browser-Version, GPU-Treiber-Version und Energiemodus konstant halten.
  • Vor Hardware-Vergleichen mindestens zwei identische Profile ausführen.
  • Benchmark-Tab während des gesamten Laufs im Fokus halten.
  • Scores unterschiedlicher Browser nicht als gleichwertig vergleichen.
  • Desktop-Telemetrie (MSI Afterburner oder GPU-Z) für Temperaturen und Taktraten nutzen.

So berechnet dieser FPS-Test seine Ergebnisse

Durchschnittliche FPS = 1.000 × Intervallanzahl / gemessene Millisekunden. Quantile werden bei (N − 1) × p linear interpoliert. 1%-Low = 1.000 / Mittelwert der längsten ceil(N × 0,01) Intervalle, nicht 1.000/P99.

Leichten FPS-Test ausführen

Grafikprüfung, Berichte und faire Vergleiche

GPU-Erkennung und Beschleunigungsprüfung verwenden dieselben WebGPU- und WebGL-Validatoren. WebGPU prüft sicheren Kontext, API, Adapter- und Gerätezugriff, WGSL-Kompilierung, ein Dreieck mit 64 × 64 Pixeln samt Rücklesung sowie eine Berechnung mit vier Zahlen. WebGL 2 und WebGL 1 zeichnen jeweils ein Dreieck mit 4 × 4 Pixeln und prüfen den Mittelpunkt. API-Verfügbarkeit oder ein erstellter Kontext gelten als „Unterstützt“; nur eine ausgeführte Aufgabe mit erwartetem Ergebnis als „Bestanden“. Übersprungene Schritte sind „Nicht ausgeführt“, fehlende Belege „Unbekannt“.

WebGPU adapter.info und WebGL WEBGL_debug_renderer_info bleiben getrennte Quellen. Modellangaben können verborgen sein. Ein bekannter Software-Renderer ist ein Hinweis auf einen Softwarepfad; niedrige FPS oder ein Herstellername allein sind es nicht. Kleine erfolgreiche Aufgaben bestätigen weder Hardwaregesundheit noch browserweite Beschleunigung. Puffer- und Texturlimits sind keine Messwerte für gesamten VRAM, Temperatur oder Takt.

Berichte nutzen Schema-Version 1 und trennen Diagnose von Leistung. Die Metrikdefinition bleibt legacy-1; bestehende Wertungen ändern sich nicht. Stress-FPS sind gerenderte Frames geteilt durch verstrichene Sekunden; der angezeigte Score ist der gerundete FPS-Mittelwert. Die Standardabweichung der Frame-Zeit nutzt die Stichprobenvarianz. P50/P95/P99 stammen aus den bisherigen 0,5-ms-Histogrammklassen mit Obergrenze 200 ms; 1%-Low-FPS sind 1.000 / P99. Die Drop-Rate zählt Intervalle oberhalb des Ziel-Frame-Budgets plus max(1 ms, 8 % des Budgets), geteilt durch alle Intervalle. Stabilität = round(0,45 × consistency + 0,35 × drop score + 0,20 × spread score). Dabei gilt consistency = clamp(low1Fps / avgFps, 0, 1) × 100, drop score = clamp(1 − drop ratio, 0, 1) × 100 und spread score = clamp(1 − (P95−P50) / (1,5 × Ziel-Frame-Budget), 0, 1) × 100.

Das bisherige Stressprotokoll hat kein separates Aufwärmfenster; es wird ausdrücklich mit null erfasst. Der Shader-Test misst drei Szenen für jeweils zehn Sekunden bei 1280 × 720 und lässt die ersten drei Frame-Intervalle jeder Szene aus. Tatsächlich ausgeschlossene Aufwärmzeit und verbleibende Messzeit werden erfasst. Mittlere Shader-FPS sind 1.000 geteilt durch die mittlere Frame-Zeit; 1%-Low verwendet den Mittelwert des langsamsten Prozents der behaltenen Intervalle. Der Score ist das gerundete geometrische Mittel der drei Szenen-FPS mal 100. Shader-Stabilität ist der Mittelwert der Low-FPS-/Durchschnitts-FPS-Verhältnisse pro Szene, auf 0–1 begrenzt und mit 100 multipliziert. Der bisherige Filter behält Intervalle über null und unter 1.000 ms. Läufe mit ausgeschlossenen abnormalen Messintervallen gelten jetzt als ungültig; die Formel bleibt unverändert.

Der FPS-Abfall der Stabilitätsseite vergleicht die Mittelwerte der ersten und letzten 20 % der Stichproben, aufgerundet: (Anfang − Ende) / Anfang × 100. Stress-Stichproben entstehen normalerweise alle 500 ms plus einer abschließenden Probe. Exportkurven mitteln tatsächliche Sekunden und FPS in nicht überlappenden Gruppen gleicher Stichprobenzahl, mit höchstens 120 Punkten. Vergleichsdiagramme verwenden eine gemeinsame Echtzeitachse; kurze Läufe werden nicht gestreckt.

Ausgeblendete Seiten, Kontext- oder Geräteverlust, Messfehler und abgebrochene Läufe zählen nicht als Leistungsverbesserung. requestAnimationFrame hängt von Bildwiederholrate und Browserplanung ab: 60 FPS belegen keine volle GPU-Auslastung; ein höheres Ziel übersteuert kein Display-Timing. FPS-Abfall ist eine Beobachtung, keine Diagnose von Überhitzung oder Leistungsdrosselung.

Bis zu 20 Berichte liegen im localStorage dieses Browsers. Der begrenzte Verlauf nutzt die bestehende lokale Speicherung; ein fixiertes Ausgangsergebnis übersteht die automatische Kürzung. Automatisches Speichern und Notizen bleiben lokal. Bei Speicherfehlern bleiben sichtbare Ergebnisse und JSON-Export verfügbar. Das frühere Shader-Ergebnis bleibt unverändert und kann ausdrücklich mit unbekannter Gültigkeit in den Verlauf kopiert werden. Unbekannte Verlaufs- oder Schemaversionen werden nicht überschrieben. „Verlauf löschen“ entfernt vereinheitlichte Berichte, nicht den erhaltenen Altbestand.

JSON-Importe sind auf 1 MiB begrenzt. Verschachtelte Felder, Einheiten, endliche Zahlen und Arrays werden streng geprüft. Identische IDs mit gleichem Inhalt ändern nichts; widersprüchliche Inhalte werden abgewiesen. Importe behalten den ursprünglichen Testzeitpunkt und gelten als extern, nicht erneut ausgeführt oder unabhängig geprüft. Notizen und importierte Inhalte erscheinen als Text. Kopie und JSON-Download enthalten nur die Felder des jeweiligen Berichts.

Direkte Leistungsvergleiche erfordern gleiche Test- und Metrikversionen, API, Aufgabe und Messkonfiguration sowie abgeschlossene gültige Läufe. Abweichende Umgebungen oder Notizen sperren Prozentvergleiche; die Hardwareidentität lässt sich nicht unabhängig prüfen. Fehlende oder nullwertige Ausgangswerte ergeben keine relative Änderung. Verhältnisänderungen werden in Prozentpunkten angegeben. Diagnoseberichte vergleichen Prüfungen, Funktionen, Limits und Geräte, keine Leistungsprozente. Wiederholen Sie kleine Unterschiede unter gleichen Bedingungen. Veränderungen nach Treiberupdates oder Reinigung belegen keine Ursache.

Vom Browser erkannte GPU prüfen · Beschleunigungsprobleme eingrenzen