CPU- und GPU-Lasten
Auf dieser Seite
PCBenchmarkX startet seine synthetischen Lasten bei jeder Wiederholung mit einem festen Arbeitsumfang, daher lassen sie sich zwischen verschiedenen Systemen vergleichen. In solchen Tests werden keine Spielaufzeichnungen verwendet, und die Endergebnisse sind nicht gleich „FPS in einem konkreten Spiel“. Der vollständige Messzyklus ist in der Methodik beschrieben.
Derzeit werden die Engine 0.5.2 und die Last phase4.6-dev-1 verwendet. Die Version muss man im Auge behalten: Ein Wechsel des Szenarios macht die Ergebnisse verschiedener Releases direkt unvergleichbar.
CPU: Simulation von Objekten
Abschnitt betitelt „CPU: Simulation von Objekten“Im CPU-Block werden 65 536 Objekte mit Koordinaten, Geschwindigkeiten und Flags erzeugt. Bei jedem Schritt werden Bewegung, Abprallen von den Rändern und Sichtbarkeit neu berechnet. Der Hauptthread verarbeitet zunächst 8 192 Objekte nacheinander, übergibt dann den restlichen Teil an die Worker-Threads und erledigt parallel die Vorbereitung. Danach synchronisieren sich die Threads.
Die Anzahl der Worker-Threads wird nach folgender Regel gewählt:
workers = clamp(physical_cores − 1, 1, 6)Ist die Anzahl der physischen Kerne unbekannt, wird eine Schätzung anhand der logischen Prozessoren herangezogen. Kerne für Threads werden nicht manuell festgelegt. Dieser Ansatz imitiert das Modell eines „einen führenden“ Threads mit begrenzter Unterstützung und nicht einen totalen parallelisierten Durchlauf auf jedem Kern.
Der Zustand und die Reihenfolge des Durchlaufens der Objekte sind deterministisch. Vor jeder Messung der CPU-Sektion wird er zurückgesetzt und führt 512 vorbereitende Frames außerhalb der Wertung aus, um keinen Restzustand vom vorherigen Durchlauf in die Serie zu schleppen.
Der Determinismus der Last bedeutet nicht die gleiche Ausführungszeit: Frequenzen, Temperatur, Scheduler und Hintergrundprozesse beeinflussen die Messung weiterhin.
Drei GPU-Lasten
Abschnitt betitelt „Drei GPU-Lasten“Der GPU-Teil arbeitet über Direct3D 12. Die internen Arbeitstexturen haben eine feste Größe von 1920×1080, unabhängig von der Größe des Fensters und des Desktops.
| Last | Rechenarbeit | Was zu unterscheiden hilft |
|---|---|---|
| Geometry | 6 Szenen-Renderings mit je 9 216 Instanzen und 2 Postprocessing-Durchläufe | Verarbeitung der Geometrie und Zufuhr der Grafikarbeit |
| Shader | 1 Szenen-Rendering, 16 Postprocessing-Durchläufe, Shader-Komplexitätsparameter 24 | Pixel- und Texturlast |
| Compute | Gitter 1920×1080, Gruppen 8×8, Ganzzahlberechnungen mit 96 Iterationen | Ausführung des Compute-Shaders |
| Combined | CPU-Simulation und feste Grafikpipeline | Zusammenspiel von CPU, Treiber und GPU |
Dies sind separate Szenarien mit unterschiedlichem Arbeitsumfang. Beispielsweise lassen sich 8 000 bedingte Compute-Frames nicht als 8 000 FPS in einem Spiel lesen oder direkt mit 800 Geometry-Frames vergleichen. Zur Zusammenführung wird die szenariobezogene Normierung verwendet, die in der Punkteberechnung beschrieben ist.
Die Lasten sind auf einer portablen Fähigkeitsstufe geschrieben: Shader Model 5.0 und Feature Level 11_0 ohne Herstellererweiterungen. Derselbe Code läuft auf verschiedenen Generationen und Herstellern von Grafikkarten, ohne separaten Zweig für einen konkreten Hersteller.
Nach den Messungen prüft die Engine die Ausgabe jeder GPU-Last: Für Geometry, Shader, Compute, Combined und den geladenen Latenztest ist eine Kontrollsignatur festgehalten — die erwartete Form eines kleinen Fragments des Ergebnisses. Das nach Abschluss gelesene Fragment wird mit dem erwarteten verglichen; eine Nichtübereinstimmung bedeutet, dass die Last fehlerhaft ausgeführt wurde, und macht den Durchlauf unbrauchbar. Die Prüfung erfolgt nach den gewerteten Messungen und beeinflusst die Zahlen selbst nicht.
Separate Tests für Datenträgergeschwindigkeit und RAM-Durchsatz gibt es in diesem Satz nicht. Speicher und Treiber beeinflussen die Ausführung der Lasten, jedoch berechnet der Benchmark keine separaten Bewertungen für SSD und RAM.
Wiederholung der Blöcke
Abschnitt betitelt „Wiederholung der Blöcke“Die fünf Performance-Lasten werden in drei Runden mit vertauschter Reihenfolge ausgeführt:
| Runde | Reihenfolge |
|---|---|
| 1 | CPU → Geometry → Shader → Compute → Combined |
| 2 | Shader → Compute → Combined → CPU → Geometry |
| 3 | Combined → CPU → Geometry → Shader → Compute |
Der Platz jeder Last in der Sequenz ändert sich von Runde zu Runde. Das verringert seinen Einfluss auf den Vergleich. Die Aufwärmphase kann die Ergebnisse weiterhin verändern, daher werden für die Blöcke zusätzlich die Streuung der Ausführungsgeschwindigkeit und ihre Veränderung vom ersten zum letzten Block gespeichert.
Zur Bewertung eines Szenarios wird das arithmetische Mittel des Throughput seiner drei Blöcke herangezogen. Median und geometrisches Mittel der Blöcke kann man als zusätzliche Diagnostik ansehen, der endgültige Kennwert bleibt jedoch bei diesem Mittel.
Warum eine niedrige Auflösung den Haupttest nicht erleichtert
Abschnitt betitelt „Warum eine niedrige Auflösung den Haupttest nicht erleichtert“Die Lasten CPU, GPU und Combined werden außerhalb des Bildschirmpuffers ausgeführt. Ihr Befehlspfad ruft Present nicht auf und wartet nicht auf die Begrenzung der Präsentationswarteschlange. Die internen Texturen bleiben 1920×1080, selbst wenn der Desktop auf 800×600 umgestellt ist.
Die Oberfläche und der Latenztest arbeiten über einen separaten Ausgabepfad. Daher erleichtert die Änderung der Desktop-Auflösung allein die Last selbst nicht. Dennoch kann man nicht „absolut identische“ Ergebnisse bei jeder Auflösung ablesen: Am Ausgabeabschnitt sind der Treiber und der aktuelle Systemzustand beteiligt.
Eine praktische Prüfung mit 1920×1080, 1280×768 und 800×600 ist im Artikel zur Wiederholbarkeit angeführt.
Geprüft für die beschriebene Implementierung: 2026-09-20.