Diskussion zu: OpenCL-Benchmarks sehen AMDs 28nm-Grafikchips gleichauf mit nVidia ...

[Leonidas]

Link zur News:
http://www.3dcenter.org/news/opencl-benchmarks-sehen-amds-28nm-grafikchips-gleichauf-mit-nvidias-16nm-grafikchips

[MrSpadge]

die unter OpenCL zu erwartende Performance mißt dann der MrH OpenCL-Mark aus
Uiui, vorsichtig! Was würdest du sagen, wenn ich einen Benchmark präsentiere, der die CPU-Geschwindigkeit unter C++ misst? Doch hoffentlich, dass der mit Sicherheit nicht alle Anwendungsfälle und Code-Kombinationen abbildet und damit im schlimmsten Fall gar nichts aussagt. Das gilt für allgemeine Programme noch viel mehr als für Spiele. Würde man dagegen eine mathematische Bibliothek wie die BLAS oder MKL messen, dann hätte man eine brauchbare Aussage.

Was der MrH-Bench misst, sagt er jedoch nirgends auf der Homepage (hab den Foren-Thread jetzt nicht durchgelesen). Zumindest die Unterpunkte "Cache" und "Mem" in der Bewertung deuten auf einen sehr "low-level"-Benchmark hin, der also sehr einfache Operationen ausführt. Hier können die AMD GPUs tatsächlich glänzen, wie sie in der BOINC-Welt unter verschiedenen Projekten mit meist einfachen und hoch regulären Programmen unter Beweis stellen (Collatz, Milkyway, PrimeGrid, Bitcoin etc.). Anders sieht es bei komplexeren Aufgaben aus, in denen zum Teil komplexere Bibliotheken eingebunden werden müssen (SETI, Einstein, POEM). Hier zeigt sich allgemein ein ungefährer Gleichstand zwischen Team Rot und Grün, mit Vorteil bei der Energieeffizienz für nVidia (d.h. geringeren laufenden Kosten - jedes W Verbrauch im 24/7-Betrieb kostet in D ca. 2€/Jahr). Ganz düster sieht es dann bei einigen Projekten wie GPU-Grid aus, welche mehrmals versucht haben, ihre CUDA Algorithmen auf OpenCL zu portieren. In dem konkreten Fall endeten die Versuche mit "lahm und zu viele Bugs". Hier zeigt sich dann deutlich der Vorteil der besseren Entwicklungswerkzeuge für CUDA.

Damit ist es praktisch überhaupt nicht so, dass man davon ausgehen kann, AMD könnte ihre überlegene Rohleistung vernünftig auf die Straße bringen, nur weil sie OpenCL-Reifen aufgezogen haben. Vom Reifenplatzer über's pure Durchdrehen bis hin zum Sieg ist alles drin.

MrS

[Stebs]

Dafür funktionieren SLI und CrossFire unter OpenCL dann wieder blendend – sogar im Mixed-Mode mit Beschleunigern unterschiedlicher Hersteller (!) und Leistungsklassen funktioniert das ganze und wirft sogar performante Ergebnisse ausWobei das ganze ja eigentlich nichts mit SLI/CrossFire zu tun hat, sondern hier nur als Synonym für "ich hab mehr als eine GPU im System" steht. Schließlich werden nur mehrere OpenCL-Devices benutzt, die SLI/CrossFire Bridges sollten komplett funktionslos sein. (Ebenso sollte der Treiber ja nichts extra machen/beachten müssen?) Insofern ist eine fast lineare Skalierung nicht wirklich überraschend.

Interessant klingt die These, OpenCL würde in Zukunft evtl. öfter für Spiele benutzt werden. Gibt es da tatsächlich Hinweise, dass OpenCL den Compute Shadern von DX und OpenGL vermehrt bevorzugt werden könnte?
Nutzt überhaupt schon ein Spiel OpenCL?
Bei Vulkan könnte was dran sein, OpenCL nutzt da ja sogar auch SPIR-V.!?

[Elkinator]

SLI und CrossFire gibt es unter OpenCL nicht.

[Der_Korken]

Irgendwie sind die Ergebnis komisch. Die RX480 ist extrem langsam, 40% hinter einer 390X bei OC vs OC und quasi gleichauf mit der uralten 7970. Das legt den Verdacht nahe, dass hier hauptsächlich die Speicherbandbreite gebencht wird, weil dann die Verhältnisse zwischen den drei genannten Karten stimmen. Auf der anderen Seite ist eine 1060 dafür schon relativ dicht an der 480 dran und die Fury Nano sehr abgeschlagen, obwohl sie die höchste Bandbreite besitzt und von der Rohleistung her selbst mit reduziertem Takt gleichauf mit der 390 sein müsste dank 4096 vs 2816 SPs.

[bbott]

Wieso schneidet die RX 480 so schlecht ab, wegen der Bandbreite?

[Gast]

Ich kann mich gerade an keinen schlechteren Frontseiten-Artikel erinnern.
OpenCL-Performance zukünftig wichtig in Spielen? Wie kommt man darauf?
Und wie kommt man darauf, diesen Benchmark als repräsentativen Querschnitt für die OpenCL-Performance im Allgemeinen heranzuziehen, obwohl dort, wie hier auch schon angemerkt wurde, eine enorme Spannweite zwischen den verschiedenen Anwendungsfällen herrscht?
Das muss weg von der Frontseite, das kann man einfach nicht so bringen.
Unfassbar...

[Expandable]

Wieso sollte OpenCL jemals beim Gaming eine Rolle spielen? Die Integration mit OpenGL/Vulkan/Direct3D ist umständlich, und alle drei APIs bringen eigene Compute-APIs mit, die sich besser integrieren. Also wozu OpenCL?

[Elkinator]

Genau, alles wo AMD gut abschneidet von der Seite entfernen, echt schlimm welche dummen Vorderungen manche stellen...

Die Integration mit OpenGL/Vulkan/Direct3D ist umständlich
Nettes Märchen, mehr ist es aber nicht!

[MrSpadge]

Vische vüttern vordert viel Verstand. Verfressene Viecher, vordern Vutter!

Sorry.. zurück zum Thema. Die Frage, warum ein Spieleprogrammierer OpenCL den "eingebauten" compute APIs vorziehen sollte, muss man sich schon gefallen lassen.

MrS

[Gast]

Ein Grund (der einzige, der mir im Moment einfällt ;)) wäre, dass OpenCL zu SPIR-V "kompiliert", wie Vulkan. Ist für den Treiber sicher simpler zu verarbeiten, als wenn der wiederum die Shader von HLSL/GLSL oder sonstwas kompilieren muss, und die Devs können direkt das SPIR-V ausliefern. Kann also interessante Programme in OpenCL schreiben, und direkt mit Vulkan nutzen.

[Expandable]

Vulkan verwendet doch eh kompiliertes SPIR-V? Und D3D verwendet kompiliertes HLSL, von daher sehe ich da keinen Vorteil. Zumal SPIR-V auch sehr verbose ist, gerade im Vergleich zu D3D Bytecode.