News Effizienter AMD „Tonga“ erscheint am 2. September
- Ersteller Jan
- Erstellt am
- Zur News: Effizienter AMD „Tonga“ erscheint am 2. September
Nai
Lt. Commander
- Registriert
- Aug. 2012
- Beiträge
- 1.579
Bezüglich der Diskussion der GPGPU-Performance und wegen:
Es gibt keine "GPGPU-Performance" in dem Sinne. GPGPU ist ein extrem großes Anwendungsgebiet mit extrem unterschiedlichen Algorithmen und fließenden Grenzen zur traditionellen Rastergraphik. Deshalb kann man auch bei vielen meist post-processing Effekten, welche in Spielen traditionell mit OpenGL oder Direct3D geschrieben werden, problemlos und mit selber Performance eine beliebige GPGPU-API wie OpenCL oder CUDA verwenden. Des Weiteren gibt es auch Anwendungsfälle für GPGPU, bei welchen man die Rasterpipeline von OpenGL oder Direct3D sehr gut ausnutzen kann oder sogar zwingend benötigt.
Diese verschwimmenden Grenzen äußern sich auch im Aufbau der GPU. Ein Großteil der beim Rasterisierungsprozess benötigten GPU-Hardware - eigentlich alles außer die Rasterpipeline - kann man auch mit den GPGPU-APIs verwenden; ebenfalls kann man beim Rasterisierungsprozess nur sehr wenige GPGPU-Bestandteile der GPU nicht verwenden. Hierunter sind hauptsächlich Funktionen welche mit der Threaderstellung auf der GPU zu tun haben, da diese in der Rasterpipeline automatisch erstellt werden, und auch der Scratchpadspeicher bzw. der On-DIE-SRam (in CUDA auch Shared-Memory genannt), welcher meines Wissens nach ebenfalls implizit über die Rasterpipeline verwendet wird.
Des Weiteren hat NVIDIA zwischen dem GF-100 und dem GK-110 /GK-104 nichts "ersatzlos gestrichen", sondern eben versucht den Aufbau der GPU anders zu optimieren, um durch Streichungen an einer Stelle an einer anderen Stelle mehr Platz für etwas anderes zu haben.
So dachten sich die Ingenieure bei NVIDIA, dass sie in den meisten Anwendungsfällen hauptsächlich Floating-Point berechnungen durchführen, dh Ganzzahl Multiplikationen kommen selten vor. Deshalb können bei der Keppler Serie nur 32 der 192 CUDA-Kerne pro Multiprozessor Integer-Multiplikationen durchführen, und nur 160 CUDA-Kerne Integer Addition, wodurch der Integer Durchsatz insgesamt im Vergleich zum Fermi reduziert ist. Ähnlich verhält es sich bei der DP-Performance des GK-104s, welche hauptsächlich für SP designt worden ist und DP mehr oder weniger nur aus Kompabilitätsgründen anbietet.
Zudem hat NVIDIA die einzelnen Multiprozessorkerne der GK-110 und GK-104 wesentlich größer gemacht, statts viele kleinere Kerne einzubauen. Dies hat tendentiell den Vorteil, dass die Ressourcen in einem Kern besser ausgenutzt werden können. Allerdings hat es auch den Nachteil, dass es den Kern bzw. Teile davon überlinear größer und komplexer macht, und einige Sachen eben mit der Größe nur relativ schlecht skalieren (wie der On-DIE-SRam / CUDA-Shared-Memory). Dadurch besitzt ein GK-110 bei 4 Byte Ladeoperationen eine niedrige On-DIE-SD-Ram-Bandbreite als ein GF-100. Erst bei 8-Byte Ladeoperationen ist er schneller, welche man aber bei der Programmierung mehr oder weniger explizit verwenden muss.
Das Caching hat NVIDIA auch von Version zu Version überarbeitet, wobei jedes Caching seine Vor- und Nachteile besitzt. Fermi hatte einen L1-Cache für globale Variablen (meist Eingangsdaten und Ausgangsdaten) und automatische Variablen (temporäre Zwischenergebnisse), welcher beim GK-104 und GK-110 nur noch für automatische Variablen funktioniert. Zudem wurde der L1-Cache bezogen auf die Multiprozessorgröße kleiner. Dafür kam dann beim GK-110 noch der Texture-Cache als Read-Only-L1-Cache für globale Variablen hinzu. Diesen muss man aber wegen seiner Read-Only-Natur explizit per speziellem Ladebefehl verwenden, was im Moment nur in CUDA geht.
Wieso schneidet der GK-104 so schlecht in diversen GPGPU Anwendungen ab? Das ist eine gute Frage, auf die ich selbst keine genaue Antwort weiß. Eventuell liegt es zum Teil an einen der oben genannten Umstrukturierungen der GPU, dass der Algorithmus nun etwas macht, was die GPU gar nicht mag. Dies könnte man wahrscheinlich zum Teil durch Optimierung beheben. Allerdings lassen extreme starke Schwankungen zwischen Benchmark zu Benchmark auch vermuten, dass etwas an dem Benchmarks selbst schief läuft. Eine mögliche Ursache hierfür wäre zumindest bei OpenCL, dass NVIDIA OpenCL zwar noch unterstützt, es jedoch es schon seit Fermi nicht mehr weiterentwickelt. So erzeugt der NVIDIA-Compiler immer noch nur Fermi-PTX-Assembly, welcher dann nur noch auf Keppler-Assembly hochkompiliert wird. Bedauerlicherweise schreiben die meisten Hardware-seiten nur "ah ist schlechter" oder "ah ist besser", anstatt sich Gedanken darum zu machen, wieso die Performance so ist wie sie ist. In dieser Hinsicht fände ich das persönlich mal interessant, wenn das jemand ausführlicher untersuchen könnte.
Ich hoffe ich konnte mit diesem leider etwas längeren Beitrag etwas Licht in das dunkle der Diskussion bringen und freue mich gerne über inhaltliche Kritik
Es gibt keine "GPGPU-Performance" in dem Sinne. GPGPU ist ein extrem großes Anwendungsgebiet mit extrem unterschiedlichen Algorithmen und fließenden Grenzen zur traditionellen Rastergraphik. Deshalb kann man auch bei vielen meist post-processing Effekten, welche in Spielen traditionell mit OpenGL oder Direct3D geschrieben werden, problemlos und mit selber Performance eine beliebige GPGPU-API wie OpenCL oder CUDA verwenden. Des Weiteren gibt es auch Anwendungsfälle für GPGPU, bei welchen man die Rasterpipeline von OpenGL oder Direct3D sehr gut ausnutzen kann oder sogar zwingend benötigt.
Diese verschwimmenden Grenzen äußern sich auch im Aufbau der GPU. Ein Großteil der beim Rasterisierungsprozess benötigten GPU-Hardware - eigentlich alles außer die Rasterpipeline - kann man auch mit den GPGPU-APIs verwenden; ebenfalls kann man beim Rasterisierungsprozess nur sehr wenige GPGPU-Bestandteile der GPU nicht verwenden. Hierunter sind hauptsächlich Funktionen welche mit der Threaderstellung auf der GPU zu tun haben, da diese in der Rasterpipeline automatisch erstellt werden, und auch der Scratchpadspeicher bzw. der On-DIE-SRam (in CUDA auch Shared-Memory genannt), welcher meines Wissens nach ebenfalls implizit über die Rasterpipeline verwendet wird.
Des Weiteren hat NVIDIA zwischen dem GF-100 und dem GK-110 /GK-104 nichts "ersatzlos gestrichen", sondern eben versucht den Aufbau der GPU anders zu optimieren, um durch Streichungen an einer Stelle an einer anderen Stelle mehr Platz für etwas anderes zu haben.
So dachten sich die Ingenieure bei NVIDIA, dass sie in den meisten Anwendungsfällen hauptsächlich Floating-Point berechnungen durchführen, dh Ganzzahl Multiplikationen kommen selten vor. Deshalb können bei der Keppler Serie nur 32 der 192 CUDA-Kerne pro Multiprozessor Integer-Multiplikationen durchführen, und nur 160 CUDA-Kerne Integer Addition, wodurch der Integer Durchsatz insgesamt im Vergleich zum Fermi reduziert ist. Ähnlich verhält es sich bei der DP-Performance des GK-104s, welche hauptsächlich für SP designt worden ist und DP mehr oder weniger nur aus Kompabilitätsgründen anbietet.
Zudem hat NVIDIA die einzelnen Multiprozessorkerne der GK-110 und GK-104 wesentlich größer gemacht, statts viele kleinere Kerne einzubauen. Dies hat tendentiell den Vorteil, dass die Ressourcen in einem Kern besser ausgenutzt werden können. Allerdings hat es auch den Nachteil, dass es den Kern bzw. Teile davon überlinear größer und komplexer macht, und einige Sachen eben mit der Größe nur relativ schlecht skalieren (wie der On-DIE-SRam / CUDA-Shared-Memory). Dadurch besitzt ein GK-110 bei 4 Byte Ladeoperationen eine niedrige On-DIE-SD-Ram-Bandbreite als ein GF-100. Erst bei 8-Byte Ladeoperationen ist er schneller, welche man aber bei der Programmierung mehr oder weniger explizit verwenden muss.
Das Caching hat NVIDIA auch von Version zu Version überarbeitet, wobei jedes Caching seine Vor- und Nachteile besitzt. Fermi hatte einen L1-Cache für globale Variablen (meist Eingangsdaten und Ausgangsdaten) und automatische Variablen (temporäre Zwischenergebnisse), welcher beim GK-104 und GK-110 nur noch für automatische Variablen funktioniert. Zudem wurde der L1-Cache bezogen auf die Multiprozessorgröße kleiner. Dafür kam dann beim GK-110 noch der Texture-Cache als Read-Only-L1-Cache für globale Variablen hinzu. Diesen muss man aber wegen seiner Read-Only-Natur explizit per speziellem Ladebefehl verwenden, was im Moment nur in CUDA geht.
Wieso schneidet der GK-104 so schlecht in diversen GPGPU Anwendungen ab? Das ist eine gute Frage, auf die ich selbst keine genaue Antwort weiß. Eventuell liegt es zum Teil an einen der oben genannten Umstrukturierungen der GPU, dass der Algorithmus nun etwas macht, was die GPU gar nicht mag. Dies könnte man wahrscheinlich zum Teil durch Optimierung beheben. Allerdings lassen extreme starke Schwankungen zwischen Benchmark zu Benchmark auch vermuten, dass etwas an dem Benchmarks selbst schief läuft. Eine mögliche Ursache hierfür wäre zumindest bei OpenCL, dass NVIDIA OpenCL zwar noch unterstützt, es jedoch es schon seit Fermi nicht mehr weiterentwickelt. So erzeugt der NVIDIA-Compiler immer noch nur Fermi-PTX-Assembly, welcher dann nur noch auf Keppler-Assembly hochkompiliert wird. Bedauerlicherweise schreiben die meisten Hardware-seiten nur "ah ist schlechter" oder "ah ist besser", anstatt sich Gedanken darum zu machen, wieso die Performance so ist wie sie ist. In dieser Hinsicht fände ich das persönlich mal interessant, wenn das jemand ausführlicher untersuchen könnte.
Ich hoffe ich konnte mit diesem leider etwas längeren Beitrag etwas Licht in das dunkle der Diskussion bringen und freue mich gerne über inhaltliche Kritik
Zuletzt bearbeitet:
Ähnliche Themen
