Automatisch aus dem Artikelinhalt als redaktionelle, sichtbare Inhaltsübersicht erzeugt.

Benchmarks gibt es inzwischen für praktisch alles, vom klassischen CPU-Rendering über Spiele bis zum Speicher und trotzdem bleibt zwischen diesen bekannten Disziplinen eine interessante Lücke. Eine moderne CPU oder GPU besteht schließlich nicht nur aus der Fähigkeit, eine bestimmte Szene besonders schnell zu rendern oder in einem ausgewählten Spiel möglichst viele Bilder pro Sekunde auszugeben. Dahinter sitzen Recheneinheiten, Cache-Hierarchien, Speichercontroller, Treiber, Compiler und Scheduler, die bei anderen Aufgaben plötzlich ein ganz anderes Bild ergeben können. Genau an dieser Stelle setzt der MrH OpenCL Benchmark an, denn anstatt eine reale Anwendung nachzustellen, schickt er mehrere bewusst unterschiedliche Compute-Workloads über dieselbe OpenCL-Schnittstelle auf CPU und GPU und macht damit sichtbar, wie unterschiedlich Architekturen mit mathematischer Last, Bildoperationen, Speicherzugriffen und parallelem Scheduling umgehen.

Interessant wird das Ganze vor allem deshalb, weil Version 2.0e nicht aus dem Nichts entstanden ist. Hinter dem Tool steht MisterH, der das Projekt seit Jahren in verschiedenen Hardware-Communities entwickelt, pflegt und mit Ergebnissen aus zahlreichen Systemen füttert. Der öffentliche Entwicklungsfaden lässt sich mindestens bis 2019 zurückverfolgen, später kamen ComputerBase, Hardwareluxx, PC Games Hardware und auch das Igor’sLAB-Forum hinzu. Das Tool wurde dabei nicht nur optisch modernisiert, sondern immer wieder in seiner Messlogik verändert, beispielsweise durch neue Memory-Tests, Async Compute, Extreme und Godmode, neue Ergebnisberechnungen und zuletzt auch durch Verbesserungen bei Geräteerkennung und Stabilitätskontrolle.  Dabei ist gerade die Entstehungsgeschichte wichtig, denn ein Community-Benchmark lebt nicht davon, dass irgendein Hersteller einmal eine schöne Demo programmiert und danach zehn Jahre lang dieselbe Binärdatei verteilt. Hier sind aus realen Ergebnissen Probleme aufgefallen und anschließend teilweise bis zum Treiberhersteller zurückgespielt worden. Bei Intel Arc zeigte der HDR-Test beispielsweise ein reproduzierbares Problem, das Intel später mit Treiber 32.0.101.8974 behoben hat. Auch für Async Compute wurde ein Performance-Fix gemeldet. Damit hat der Benchmark längst einen zweiten Nutzen bekommen, denn ein auffälliger Wert kann nicht nur auf eine Hardwareeigenschaft hinweisen, sondern ebenso auf den OpenCL-Treiber oder den Compilerpfad dahinter.

OpenCL ist im Kern eine Abstraktionsschicht für parallele Berechnungen. Eine Anwendung formuliert einen Kernel und dieser wird über die OpenCL-Runtime auf einem geeigneten Gerät ausgeführt. Das kann eine CPU, eine GPU oder ein anderer unterstützter Beschleuniger sein. Die Arbeit wird dabei in Work-Items zerlegt, mehrere Work-Items bilden eine Work-Group und die Runtime verteilt diese wiederum auf die Recheneinheiten des jeweiligen Gerätes. Genau dadurch kann dieselbe grundsätzliche Rechenaufgabe auf sehr unterschiedliche Hardware losgelassen werden. Das heißt natürlich nicht, dass dadurch plötzlich jede Architektur gleich behandelt wird. Im Gegenteil, genau die Unterschiede werden interessant. Eine CPU besitzt wenige sehr komplexe Kerne mit großen Caches und aggressiver Out-of-Order-Ausführung, während eine GPU sehr viele schmalere Recheneinheiten parallel beschäftigen kann. Hinzu kommen völlig unterschiedliche Speicherhierarchien und vor allem unterschiedliche Compiler. Selbst wenn zwei Geräte denselben OpenCL-Kernel erhalten, entscheidet die jeweilige Runtime darüber, wie daraus Maschinenbefehle werden und wie gut diese zur Architektur passen. Deshalb misst der MrH Benchmark auch nicht einfach nur „die CPU“ oder „die GPU“. Er misst die gesamte Rechenkette aus Hardware, OpenCL-Runtime, Treiber, Compiler und Betriebssystem. Das ist zunächst ein Nachteil, wenn man unbedingt eine völlig isolierte Rohleistung messen möchte. Für den Alltag ist es aber gleichzeitig sehr interessant, denn genau diese Kette entscheidet am Ende darüber, wie schnell eine reale OpenCL-Anwendung tatsächlich läuft.

Gerade auf der CPU-Seite hat MisterH deshalb eine ziemlich strikte Vorgabe eingeführt. Für gültige CPU-Ergebnisse muss die Intel OpenCL Runtime 2021.2.0.616 installiert sein, die im Tool zusätzlich unter der Kennung 2021.11.3.0.17_160000 erscheint. Andere Runtime-Versionen werden für die Rangliste nicht akzeptiert. Außerdem setzt diese Runtime SSE4.2 voraus. Das klingt zunächst etwas seltsam, wenn beispielsweise eine AMD-CPU getestet wird und trotzdem eine Intel-Runtime installiert werden muss. Methodisch ist es aber durchaus nachvollziehbar, denn andernfalls würden Intel- und AMD-Prozessoren unter Umständen nicht nur unterschiedliche Hardware verwenden, sondern auch völlig unterschiedliche OpenCL-Compiler und Runtime-Implementierungen. Dann ließe sich kaum noch unterscheiden, welcher Teil des Ergebnisses von der CPU stammt und welcher vom Softwarestack. Unter Windows on ARM64 wird die CPU-Seite über die x64-Emulation ausgeführt. Das macht einen solchen Wert nicht zu einem nativen ARM-CPU-Benchmark, ermöglicht aber trotzdem interessante Plattformvergleiche. Bei der GPU sieht die Sache anders aus, denn dort kommt der OpenCL-Support des jeweiligen Herstellertreibers zum Einsatz. Qualcomm bietet diesen Pfad auf entsprechenden Windows-on-ARM-Systemen an und genau deshalb können solche Plattformen besonders spannend sein, weil CPU- und GPU-Pfad auf völlig unterschiedlichen Softwareebenen laufen.

HDR gehört zu den ältesten Tests der Suite und wurde im Laufe der Entwicklung mehrfach angepasst. Aus dem Changelog ist bekannt, dass MisterH die Arbeitsgrößen verändert hat, beispielsweise frühere große 8192er-Dimensionen auf 4096, 2048 und 1024 zurückgenommen hat und damit die Lastcharakteristik neu abstimmte. Was öffentlich nicht vorliegt, ist der vollständige aktuelle OpenCL-Kernel. Deshalb wäre es unseriös, eine ganz konkrete Tonemapping-Gleichung oder Anzahl mathematischer Operationen zu behaupten. Die technische Lastklasse lässt sich trotzdem gut einordnen. HDR ist ein bildorientierter Compute-Workload mit vielen parallelen Berechnungen auf zweidimensionalen Daten. Solche Aufgaben lassen sich sehr gut in Work-Items zerlegen und profitieren deshalb grundsätzlich von hoher Parallelität. Gleichzeitig müssen Bilddaten gelesen, verarbeitet und wieder geschrieben werden, wodurch Rechenleistung und Speicherpfade zusammenspielen. Dass genau dieser Test einen Fehler in Intels Arc-OpenCL-Pfad sichtbar machte ist deshalb kein Zufall. Der HDR-Bug wurde mit Treiber 32.0.101.8974 behoben und nach Angaben des Entwicklers unter anderem auf einer Arc A770 sowie der iGPU eines Core Ultra 9 285K bestätigt. Der vorher notwendige spezielle HDR-Workaround für Arc A-Series ist ab diesem Treiber damit nicht mehr erforderlich.

Der Bicubic-Test ist die Disziplin, bei der Overclocker die Warnung des Entwicklers tatsächlich ernst nehmen sollten. MisterH weist ausdrücklich darauf hin, mit angehobenen Powerlimits, Spannungen und MPT-Einstellungen langsam vorzugehen und genau dieselbe Warnung wurde später auch auf Texture ausgeweitet. Bikubische Interpolation wird normalerweise verwendet, um aus mehreren benachbarten Bildpunkten einen neuen Wert zu berechnen. Bei einer klassischen zweidimensionalen bikubischen Interpolation fließt typischerweise eine 4×4-Nachbarschaft in das Ergebnis ein. OpenCL stellt von Haus aus nearest und lineare Filterung bereit, jedoch keinen universellen eingebauten Bicubic-Modus. Eine echte bikubische Berechnung muss daher aus mehreren Samples und eigener Gewichtung aufgebaut werden. Ob der aktuelle MrH-Kernel exakt dieses klassische 4×4-Verfahren implementiert kann ohne offenen Kernelcode nicht verifiziert werden. Sicher ist jedoch, dass die Kombination aus vielen Datenzugriffen und arithmetischer Arbeit eine Last erzeugt, die GPUs ausgesprochen hart treffen kann. Das erklärt auch, warum Bicubic beim Overclocking schnell zu einer anderen Kategorie gehört als ein normaler Spielebenchmark. Ein Setting, das eine Stunde in einem Spiel funktioniert, muss unter einer solchen Compute-Last noch lange nicht stabil sein.

Texture klingt zunächst sehr nach klassischem 3D-Rendering und trotzdem handelt es sich nicht um einen Spielebenchmark. OpenCL besitzt eigene Image-Objekte und Sampler, über die strukturierte Bilddaten gelesen werden können. Die Spezifikation kennt dafür verschiedene Filter- und Adressierungsmodi und gerade solche Zugriffe können auf einer GPU spezielle Caches und Datenpfade nutzen. Der Texture-Test wurde während der Entwicklung mehrfach verändert. Auf der CPU-Seite wurde die Extreme-Arbeitsgröße beispielsweise zeitweise auf 4096 × 4096 erhöht. Außerdem experimentierte MisterH vorübergehend mit UINT16 und kehrte später wieder zu UINT8 zurück. Diese Änderungen zeigen sehr schön, dass Texture nicht nur ein hübscher Name für eine fest eingefrorene Schleife ist, sondern gezielt auf seine Lastcharakteristik abgestimmt wurde. Genau deshalb können hier auch Architekturen nach vorne kommen, die im PI-Test weniger spektakulär aussehen. Ein hoher theoretischer Compute-Durchsatz reicht nämlich nicht automatisch aus, wenn der Datenzugriff nicht mithalten kann. Cache-Struktur, Texturpfade, Speicherlatenz und Compiler spielen hier deutlich stärker zusammen.

PI ist innerhalb der Suite der Test, der am ehesten in Richtung klassischer mathematischer Rechenlast geht. Der genaue Algorithmus, mit dem π in Version 2.0e berechnet beziehungsweise angenähert wird, ist öffentlich nicht dokumentiert. Damit lässt sich weder eine genaue Instruktionszahl ableiten noch sollte man den Wert direkt als FLOPS interpretieren. Was der Test aber sehr gut liefert ist eine vergleichsweise rechenzentrierte Gegenprobe zu den bildorientierten Disziplinen. Wenn beispielsweise eine GPU in Texture hervorragend abschneidet und bei PI deutlich zurückfällt, spricht das dafür, dass ihr Vorteil nicht ausschließlich aus der rohen Rechenleistung kommt. Bei CPUs kann wiederum sichtbar werden, wie gut Takt, Kernzahl und OpenCL-Compiler zusammenarbeiten. Gerade zusammen mit den anderen Tests wird PI deshalb interessant. Isoliert ist es nur eine Zahl. Im Profil mit HDR, Texture, Memory und Async Compute bekommt diese Zahl einen Kontext.

Der Name Async Compute lädt gerade bei Grafikkarten zu einem Missverständnis ein, denn viele verbinden damit sofort DirectX 12 oder Vulkan und das parallele Abarbeiten von Grafik- und Compute-Queues. Genau darum geht es hier nicht. Der MrH-Test arbeitet innerhalb von OpenCL und untersucht damit eine andere Form paralleler Compute-Arbeit. OpenCL selbst besitzt Mechanismen, mit denen beispielsweise Datenbewegungen zwischen globalem und lokalem Speicher asynchron organisiert und über Events synchronisiert werden können. Welche dieser Mechanismen MisterH im aktuellen Kernel genau verwendet ist öffentlich nicht vollständig dokumentiert. Die Wirkung des Tests als Scheduling- und Parallelitätsprüfung ist allerdings gut sichtbar. Besonders interessant ist auch hier der Intel-Fall. Der Entwickler meldete eine auffällige Async-Compute-Performance auf Arc und Intel bestätigte später einen Fix im Compute-Stack. Genau solche Fälle zeigen, weshalb ein Community-Benchmark mehr sein kann als ein Wettbewerb um die höchste Zahl. Ein reproduzierbarer Ausreißer kann einen Treiberfehler offenlegen und damit irgendwann sogar die Performance anderer Programme verbessern.

Beim Memory-Test lohnt sich ein genauerer Blick, weil dieser Bereich während der Entwicklung besonders häufig verändert wurde. Aus einem einfachen Memory-Test wurde schließlich Memory R-W-C und damit eine kombinierte Betrachtung aus Read, Write und Copy. Version 1.52 brachte zusätzliche Varianten wie Read-Write, Read-Copy, Write-Copy sowie die Einzeltests Read, Write und Copy. Mit Version 1.95 wurde der Memory-Algorithmus erneut verändert und das device-lokale Clearing korrigiert. Das ist sinnvoll, denn Speicherleistung ist keine einzelne Zahl. Eine CPU kann beim Lesen hervorragend aussehen und beim Schreiben deutlich anders skalieren. Copy beansprucht gleichzeitig Quelle und Ziel und erzeugt dadurch wieder ein anderes Lastprofil. Bei einer diskreten GPU betrifft das in erster Linie VRAM, Caches und Speichercontroller. Auf einer CPU läuft dieselbe logische Aufgabe dagegen durch private Caches, gemeinsame Cache-Ebenen und schließlich den System-RAM. OpenCL unterscheidet dabei unter anderem zwischen globalem, lokalem, konstantem und privatem Speicher. Wie diese logischen Bereiche physisch umgesetzt werden hängt vom jeweiligen Gerät ab. 

Gerade für RAM-Tuning ist Memory R-W-C deshalb ausgesprochen interessant. In einem Hardwareluxx-Vergleich wurde der Godmode-Memory-Wert gegen AIDA64 und MaxxMem gestellt. Dort korrelierte der MrH-Wert sehr stark mit AIDA Read, Write und Copy, wobei die angegebenen Korrelationswerte bei 0,90, 0,97 und 0,95 lagen. Gleichzeitig reagierte MrH in diesem konkreten Datensatz weniger empfindlich auf feine Timingänderungen als AIDA. Das ist kein allgemeingültiger wissenschaftlicher Beweis, zeigt aber ziemlich schön, welchen Charakter der Test besitzt: Er reagiert auf Speicherleistung, bildet sie aber nicht identisch zu einem klassischen RAM-Benchmark ab.

Genau hier sollte man mit der Interpretation auf dem Teppich bleiben. Ein hoher MrH-Wert bedeutet nicht automatisch mehr FPS in einem Spiel und ein niedriger Wert bedeutet nicht, dass eine CPU oder GPU schlecht ist. Der Benchmark untersucht OpenCL-Workloads und damit eine sehr konkrete Art paralleler Berechnung. Sein eigentlicher Nutzen entsteht aus dem Muster über mehrere Tests. Wenn ein RAM-OC ausschließlich Memory deutlich verbessert und PI praktisch unverändert bleibt, weiß man recht schnell, wo der Gewinn herkommt. Wenn ein höheres GPU-Powerlimit Bicubic massiv beschleunigt und Texture kaum verändert, lässt sich ebenfalls etwas über die Limitierung der Architektur lernen. Wenn nach einem Treiberupdate plötzlich nur Async Compute einbricht, ist das wiederum ein ziemlich guter Hinweis darauf, dass nicht plötzlich das Silizium langsamer geworden ist. Gerade deshalb ist die Chartsauswertung für dieses Projekt wichtiger als ein einzelner Sieger. Die Charts sollen nicht einfach zeigen, wer auf Platz eins steht, sondern unterschiedliche Architekturen und Einstellungen nebeneinander sichtbar machen. Ergebnisse werden nach CPU und GPU sowie Extreme und Godmode getrennt und anschließend noch einmal pro Workload aufgeschlüsselt. Damit lassen sich beispielsweise CPUs derselben Familie miteinander vergleichen, Unterschiede zwischen Stock und OC erkennen oder Generationen verschiedener Hersteller direkt gegenüberstellen.

Eine Rangliste mit fünf RTX-5090-Systemen kann sehr unterhaltsam sein, beantwortet aber nur einen kleinen Teil der interessanten Fragen. Richtig spannend wird es, wenn gleichzeitig eine Arc, eine Radeon, ältere GeForce-Generationen, Notebook-GPUs, integrierte Grafik und Windows-on-ARM-Systeme auftauchen. Dasselbe gilt bei CPUs. Ein Core Ultra 9 285K ist interessant, ein alter Ryzen, ein X3D-Modell, eine Notebook-CPU oder eine emulierte ARM-Ausführung können für die Analyse jedoch mindestens genauso wertvoll sein. Genau deshalb wird die neue Auswertung nicht nur als statische Tabelle gedacht. Die über das Online-Formular eingesandten Daten bilden die Grundlage für Charts, in denen jede Testdisziplin separat ausgewertet werden kann. Weil CPU und GPU sowie Extreme und Godmode getrennt bleiben, können insgesamt 24 klar voneinander abgegrenzte Benchmarkbereiche dargestellt werden. Dadurch lässt sich beispielsweise herausfiltern, ob eine GPU nur in Texture weit vorne liegt oder durchgehend stark ist und ob sich Godmode gegenüber Extreme bei bestimmten Architekturen auffällig anders skaliert. 

Die Charts werden mit wachsender Datenbasis automatisch interessanter. Ein einzelner Ausreißer kann dabei zunächst ein besonders gutes OC, einen Treibereffekt oder schlicht einen fehlerhaften Lauf bedeuten.

Sobald jedoch mehrere ähnliche Systeme auftauchen wird daraus ein Trend. Genau deshalb gehören Screenshots und möglichst genaue Hardwareangaben zwingend dazu, denn nur so lässt sich später unterscheiden, ob zwei vermeintlich gleiche CPUs tatsächlich mit denselben Einstellungen liefen.

Wenn der Benchmark gar nicht startet fehlen häufig die Microsoft Visual-C++-Laufzeitkomponenten. Für die aktuelle Version sollten die Visual-C++-2015–2022-Runtimes sowohl in x86 als auch x64 installiert sein. In älteren beziehungsweise ergänzenden Hinweisen taucht außerdem Visual C++ 2013 auf. Wer ein System mit langer Windows-Historie besitzt und trotz aktueller Runtime keinen Start hinbekommt sollte das deshalb ebenfalls im Hinterkopf behalten. Für CPU-Tests gilt weiterhin die feste Intel-OpenCL-Runtime 2021.2.0.616. Werden CPUs im Tool doppelt aufgeführt gibt es einen separat angebotenen CPU List Fix. Bei GPU-Tests entscheidet der jeweilige Herstellertreiber darüber, ob OpenCL verfügbar ist. Bei Intel Arc A-Series gab es historisch eine besondere Vorgehensweise für den HDR-Test. Früher musste zunächst HDR einmal gestartet, der Lauf beendet und anschließend erneut ausgeführt werden bevor die übrigen fünf Tests für einen gültigen Ranglisteneintrag folgten. Seit Intels Treiber 32.0.101.8974 ist der zugrunde liegende HDR-Fehler nach Angaben des Entwicklers behoben und dieser Workaround ist damit für entsprechend aktuelle Treiber nicht mehr nötig. Systeme mit gleichzeitig aktiver iGPU und dedizierter GPU können ebenfalls Ärger machen. Falls das Tool trotz vorhandener Runtimes nicht öffnet empfiehlt der Entwickler, die integrierte GPU testweise im BIOS oder Geräte-Manager zu deaktivieren. Das ist kein schöner Dauerzustand, aber als Diagnose ziemlich eindeutig. Und schließlich gibt es noch einen sehr eigentümlichen Fehler nach einem harten Crash; Wenn das System während des Benchmarks mit Bluescreen oder Absturz aussteigt und die Anwendung beim nächsten Start plötzlich leer bleibt reicht es laut Ranglistenhinweis aus, den Programmordner umzubenennen. Aus „2.0e“ wird beispielsweise „2.0ex“ und das Tool startet anschließend wieder normal.

Wer seine Hardware übertaktet sollte ausgerechnet bei Bicubic und Texture ein wenig Vernunft walten lassen. MisterH warnt selbst davor, MPT, Powerlimit und Spannung langsam zu erhöhen und nicht einfach alles nach rechts zu ziehen. Das ist nicht bloß ein Haftungssatz im Kleingedruckten, sondern technisch sinnvoll, denn synthetische Compute-Kernel können Lastzustände erzeugen, die ein Spiel nie erreicht. Ein stabiles Gaming-OC ist deshalb noch lange kein stabiles OpenCL-Compute-OC. Genau das macht den Benchmark übrigens ebenfalls nützlich. Wenn ein Setting in Spielen problemlos läuft und bei Bicubic sofort zusammenbricht hat man nicht automatisch ein schlechtes System, sondern schlicht einen anderen Belastungstyp gefunden. Wer mitmachen möchte muss deshalb keineswegs übertakten. Stock-Ergebnisse sind für eine Chartdatenbank sogar ausgesprochen wertvoll, weil sie eine saubere Referenz bilden. Je mehr Standardwerte vorhanden sind desto besser lässt sich später erkennen, was ein bestimmtes Tuning tatsächlich bringt.

Der MrH OpenCL Benchmark 2.0e ist kein universeller Performance-Wahrheitsautomat und versucht auch gar nicht, einer zu sein. Er sagt nicht voraus, wie viele FPS ein Spiel liefert und ersetzt weder Blender noch Cinebench oder einen klassischen Speicherbenchmark. Seine Stärke liegt genau darin, dass er etwas anderes macht. Er schickt mehrere unterschiedliche Compute-Lasten über dieselbe Programmierschnittstelle auf CPUs und GPUs und legt damit Unterschiede offen, die in großen Anwendungen oft untergehen. Speicherverhalten, mathematische Rechenleistung, Bildzugriffe, Scheduling und Treiberqualität werden nicht vollständig voneinander isoliert, aber sie zeigen in den verschiedenen Teiltests jeweils ein anderes Gewicht. Durch die Community-Auswertung bekommt das Ganze eine zweite Ebene. Ein Wert allein sagt wenig. Hunderte Werte über mehrere Architekturen hinweg können dagegen zeigen, welche Hardware in welchem Lasttyp gut funktioniert, wie stark Godmode gegenüber Extreme skaliert, was RAM-Tuning tatsächlich verändert und ob ein Treiber plötzlich etwas besser oder schlechter macht. Genau deshalb lohnt sich die Teilnahme auch dann, wenn kein Rekord zu erwarten ist. Gerade die unspektakulären Stock-Systeme, älteren GPUs und ungewöhnlichen Plattformen füllen die Lücken, aus denen später eine wirklich interessante Chartlandschaft entsteht.

Damit die Daten nicht wieder mühsam aus Dutzenden Forenbeiträgen per Hand zusammengesucht werden müssen gibt es für diese Community-Aktion ein zentrales Online-Formular. Dort werden die Ergebnisse strukturiert eingetragen und können anschließend wesentlich einfacher in die Chartsauswertung übernommen werden. Es ist ausdrücklich nicht nötig, sämtliche sechs Tests in beiden Modi und für CPU wie GPU durchlaufen zu lassen. Mindestens ein Test muss aber vollständig abgeschlossen worden sein, damit eine Einsendung sinnvoll ist. Wer nur seine GPU unter Extreme testen möchte kann das tun. Wer dagegen CPU und GPU in Extreme und Godmode komplett laufen lässt liefert natürlich das deutlich umfangreichere Profil. Zu jeder Einsendung gehören Screenshots als Nachweis im Forum. Je nach Umfang des eigenen Tests können das bis zu vier Bilder sein, getrennt nach CPU Extreme, CPU Godmode, GPU Extreme und GPU Godmode. Die Hardwareluxx- und ComputerBase-Ranglisten verwenden zusätzlich ein recht sinnvolles Kurzformat mit Modell, Einstellungen, Temperatur beziehungsweise Luft- oder Wasserkühlung und Nutzername. Maximaltemperaturen und Leistungsaufnahme lassen sich beispielsweise mit HWiNFO oder GPU-Z dokumentieren. Das klingt vielleicht im ersten Moment etwas bürokratisch, spart später aber enorm viel Ärger. Bei Community-Benchmarks ist nichts unbrauchbarer als ein Rekordwert ohne Information darüber, ob die GPU Stock lief oder mit 800 Watt unter Wasser, ob der Prozessor bei Standard-Powerlimits betrieben wurde oder ob Speicher und Fabric auf Anschlag standen.

Eine Community-Rangliste wird schnell zu einem Wettbewerb um die obersten fünf Plätze und genau das wäre hier eigentlich schade.

Eine RTX 5090 mit massivem OC ist interessant, aber eine Radeon RX 5500 XT, eine alte GeForce, eine integrierte Arc- oder Ryzen-GPU und ein Snapdragon-System können für die technische Einordnung viel wertvoller sein. OpenCL lebt davon, dass dieselbe Schnittstelle auf sehr unterschiedlichen Geräten funktioniert. Genau deshalb ist es spannend zu sehen, wo eine ältere Architektur überraschend gut skaliert oder wo eine neue GPU bei einem bestimmten Workload ungewöhnlich schwach aussieht. Erst mit genügend Datenpunkten lässt sich unterscheiden, ob so etwas ein Einzelfall, ein Treibereffekt oder tatsächlich eine Architektureigenschaft ist. Das gilt auch für CPUs. X3D-Prozessoren, klassische Ryzen-Modelle, Intel P- und E-Core-Designs und Windows-on-ARM-Systeme bringen völlig unterschiedliche Cache- und Scheduling-Eigenschaften mit. Ein breit gefüllter Chart kann daraus deutlich mehr Informationen ziehen als die übliche „wer hat die höchste Zahl“-Rangliste.

Die aktuelle Community-Auswertung trennt zwischen Extreme und Godmode.

Beide Modi verwenden dieselben sechs grundlegenden Tests, erhöhen aber die Arbeitslast unterschiedlich stark und werden deshalb auch getrennt gewertet. Godmode taucht seit Version 1.85 in den Ranglisten auf und ist inzwischen fester Bestandteil der Vergleichsbasis. Das ist wichtiger, als es zunächst klingt. Ein System kann im Extreme-Modus noch vollständig im komfortablen Bereich von Cache, Takt und Powerlimit arbeiten und im Godmode plötzlich ganz anders reagieren. Gerade bei Prozessoren können höhere Arbeitsmengen stärker in den Arbeitsspeicher drücken und bei GPUs steigt die Wahrscheinlichkeit, dass Compute-Ressourcen, Speicherpfade oder das Powerlimit zum dominierenden Faktor werden. Für die neue Chartsauswertung bedeutet das, dass Ergebnisse nicht in einen großen Mischmasch geworfen werden. CPU Extreme, CPU Godmode, GPU Extreme und GPU Godmode werden jeweils separat betrachtet. Innerhalb dieser vier Hauptgruppen gibt es wiederum HDR, Bicubic, Texture, PI, Async Compute und Memory R-W-C. Aus diesen Kombinationen ergeben sich insgesamt 24 getrennte Auswertungsfelder und genau das ist auch sinnvoll, denn eine einzige Gesamtnote würde einen beträchtlichen Teil der Information wieder vernichten.

Das Online-Formular dient dabei als zentraler Eingang für die Werte. Die Screenshots gehören zusätzlich in den Forum-Thread und daraus wächst anschließend die Chartsauswertung mit getrennten Bereichen für CPU und GPU sowie Extreme und Godmode. Wer nur einen einzigen Test schafft darf ihn einreichen. Wer alles durchlaufen lässt ist natürlich ebenfalls willkommen. Am Ende soll hier nicht nur eine weitere Rangliste entstehen, sondern ein möglichst breites Bild davon, wie unterschiedliche CPU- und GPU-Architekturen mit denselben OpenCL-Aufgaben umgehen. Und dafür braucht es vor allem eines: möglichst viele unterschiedliche Rechner.