News FirePro S9170: 32 GB Speicher für AMDs neue Server-Grafikkarte

Hito

Das sind Server Karten und keine Workstation oder Gaming-Karte, da sind passive Kühlkörper die Norm.
Desweiteren geht es hier nun mal um DP-Performance und das benötigt im Vergleich zu SP schon mal mehr Speicher. Da sind die AMD schneller. Vorteil NV ist Cuda, da AMD nur mit OpenCL funktioniert. Aber wenn es um die reine Rohleisting geht, ist offensichtlich Hawaii aktuell die effizienteste GPU was DP Performance angeht und scheinbar der Grund, wieso Hawaii in der R9 300 Serie weiter verwendet wird. Btw was hat die R9 290x oder Nano mit Server Karten zu tun ?
 
Zuletzt bearbeitet:
Die Sache mit CUDA sehe ich ähnlich. AMD hat in den 10 Jahren, seitdem GPGPU am aufkommen ist, es nicht fertig gebracht etwas vergleichbares zu CUDA aufzubauen. Denn im Vergleich zu CUDA programmiert sich OpenCL einfach nur grauenhaft (ist m.E. so eine einmal und nie wieder Erfahrung OpenCL zu programmieren). Selbst das weitgehend unbekannte CPP-AMP ist im Vergleich zu OpenCL deutlich besser. Aber das "scheint" auch weitgehend tot zu sein. Deshalb ist m.E. auch die schlechte Verbreitung von AMD im GPGPU-Markt vor allem dem Nicht-Vorhandensein einer wirklich guten GPGPU-API für AMD-GPUs geschuldet.
 
sdwaroc schrieb:
Das ist leider wahr. Aktuell ist OpenCL 2.0 noch nicht Konkurrenzfähig. Mit OpenCL 2.1 und der C++14 Kernel Language wird hier aber deutlich nachgelegt und CUDA hat einen ernsthaften Konkurrenten.

Wo hapert es denn noch bei OpenCL? Ich hatte nur mal ein wenig mit OpenCL 1.2 experimentiert und da ist man von der Hardware sehr weit entfernt. Was hat sich mit OpenCL 2.0 geändert und was wird für 2.1 erwartet?
 
Chesterfield schrieb:
sorry jetzt habe ichs verwechselt. kommando und kritik zurück das es "uralt" ist :D
Hawaii ist trotzdem uralt verglichen mit früheren Produktzyklen. Auch wenn das Kind Grenada heißt.

Aber so ist das eben, wenn es bei der Strukturbreite keinen Wechsel mehr gibt. So schnell wird das Ding auch nicht abgelöst, erstmal kommen die kleinen schlanken 14/16nm GPUs.
 
Hmm da wir das VGPU Konzept von vmware mit der Version 6 immer interessanter.
 
Mich würde ja mal interessieren wie die das technisch gelöst haben. 8 Gbit Chips wären mir nämlich neu.
 
Zuletzt bearbeitet:
Hito schrieb:
"Die erste und schnellste Servergrafikkarte mit 32GB."

einfach peinlich. Klar ist die erste 32GB GPU auch gleichzeitig die schnellste GPU mit 32GB....

Immerhin wird niemand belogen. Also kein flasches Versprechen...
Somit positiv sehen!
 
Hito schrieb:
"Die erste und schnellste Servergrafikkarte mit 32GB."

einfach peinlich. Klar ist die erste 32GB GPU auch gleichzeitig die schnellste GPU mit 32GB....

Und wieso regst du dich auf? Wenn du ein Auto baust, das mit 1000 PS, 600km/h fährt, weshalb sollst du nicht damit angeben? Du willst dein Produkt doch verkaufen? :freak:
 
Wie üblich in diesem Bereich werden Preise nicht offiziell kommuniziert. Das Schwestermodell FirePro S9150 wird im Preisvergleich für über 3.200 Euro gehandelt, die schnellere S9170 dürfte somit mehr kosten.

Kein Wunder, dass diese Preise nicht offiziell kommuniziert werden. Der unausweichliche Schluss ist hier ja, dass man hier etwas um ein paar tausend € verkauft, das es im Desktop Bereich in fast exakt der gleichen Form um ein paar hundert € gibt.
 
Ist doch primär eine Umverteilung Entwicklungskosten unter den unterschiedlichen Endkunden in Abhängigkeit von derer Zahlungsbereitschaft in Kombination mit mangelnder Konkurrenz in diesem Bereich. Denn die Wirtschaft und die Rechenzentrenen können sich auch problemlos die professionellen Graphikkarten für mehrere 1000 € leisten, während der durchschnittliche Spieler nur wenige 100 € zahlen will. Dadurch generieren diese professionellen Graphikkarten abzüglich Produktionskosten mehr Gewinn, durch welchen der Hersteller wiederum die Entwicklung der GPUs, die auch in Spieler-Graphikkarten verwendet werden, finanziert. Auf diese Weise muss der GPU-Hersteller wiederum nur einen deutlich kleineren Anteil an Entwicklungskosten durch die Spieler-Graphikkarten eintreiben.
 
stoneeh schrieb:
Kein Wunder, dass diese Preise nicht offiziell kommuniziert werden. Der unausweichliche Schluss ist hier ja, dass man hier etwas um ein paar tausend € verkauft, das es im Desktop Bereich in fast exakt der gleichen Form um ein paar hundert € gibt.

So ein paar Gamer die keinen Plan von der Materie haben sind auch wirklich nicht die Zielgruppe dieser Karten. Einige vergessen anscheinend, dass Preis und Leistung nicht linear korrelieren.
 
Viele sprechen die durchaus herausragende Leistung in all den Foren mit an , aber es läuft gegen die Wand. Die Karten von AMD haben die Leistung , was auch bei den meisten bekannt sein sollte. Für das Gefühl ein starkes Stück Rechenleistung im PC zu haben , wenn man die gamerkarten kauft sollte das eigentlich ausreichen. Keine Ahnung, warum man in diesem Bereich immer mehr Geld für NVIDIA ausgibt und sich freut. Wenn man die Rechenleistung im Vergleich zur stromaufnahme sieht, frage ich: warum zum Geier ist man nicht in der Lage, das mit der Software bei Otto normal zu nutzen?
 
Unyu schrieb:
Hawaii ist trotzdem uralt verglichen mit früheren Produktzyklen. Auch wenn das Kind Grenada heißt.

Das ist wahr. Bei Nvidia sieht es in dem Segment noch viel schlimmer aus. Da Maxwell in DP-Leistung stark beschnitten ist, ist immer noch die GM110-GPU das Flagschiff bei den Tesla/Quadro-Karten. Auf Profikarten und Supercomputer-Komponenten kam die schon Mitte/Ende 2012 raus.

Es geht einfach immer langsamer vorran. Ein großer Teil der Schuld liegt aber wohl weniger bei AMD und Nvidia, sondern bei TSMC, die seit Jahren keinen neuen, für GPUs geeigneten Fertiggungsprozess hinbekommen haben.
 
Einen Punkt versteh ich nicht ganz:
Wenn diese Karte für Server gemacht ist und diese ja fast immer auf irgendein UNIX Betriebssystem laufen, AMD aber gleichzeitig bei Treibern in diesem Bereich kaum Aufwand betreibt, wer verwendet diese Karten dann?
 
Herdware schrieb:
Es geht einfach immer langsamer vorran. Ein großer Teil der Schuld liegt aber wohl weniger bei AMD und Nvidia, sondern bei TSMC, die seit Jahren keinen neuen, für GPUs geeigneten Fertiggungsprozess hinbekommen haben.
Da sehe ich selbst TSMC nicht zwangsläufig als Schuld an. Niemand hat AMD oder nvidia gewzungen alles auf TSMC zu setzen. Wenn es seit einigen Jahren keine Konkurrenz zu TMSC gab, ist doch offensichtlich wo der Fehler lag. Die Konkurrenz hat auf ganzer Linie versagt.

Jetzt sind wir in der Situation, das alle auf TSMC warten, die aber lieber Kunden wie Apple bedienen. Jetzt bitte nicht Apple als Schuldigen auswählen, man kann Apple doch nicht vorwerfen, das sie so erfolgreich sind und dank ihrer Preise auch die Kapazitäten bekommen. AMD und nvidia haben sich hier ganz klar verrant und mit AMDs Wechsel zu Globalfoundries kommt seit Jahren endlich mal Bewegung in diese festgefahrene Situation. Bzw. der ganze Markt hat sich verrant, in dem er zugelassen hat, das TSMC diese Monopolstellung einnehmen konnte, man kann nur hoffen, das andere Fertiger wieder aufholen.
 
Zuletzt bearbeitet:
Wo hapert es denn noch bei OpenCL? Ich hatte nur mal ein wenig mit OpenCL 1.2 experimentiert und da ist man von der Hardware sehr weit entfernt. Was hat sich mit OpenCL 2.0 geändert und was wird für 2.1 erwartet?

Grundsätzlich habe ich das ja geschrieben:
Das Erxecution Modell bleibt natürlich das gleiche: kernelbasiert.

Seit 2.0 (die passende HW vorausgesetzt: Broadwell+, Fiji+, Kaveri+) gibts es Shared Virtual Memory, also einen geteilten Speicherbereich von (i)GPU und CPU was Berechnungen auf der GPU erlaubt ohne Daten kopieren zu müssen.
Die Kernel und Devices innerhalb einen Context können nun auch untereinander Kommunizieren (Pipes).

Ab 2.1 kannst du dann deine ganz normalen C++ Klassen (inkl. Templates, ohne "new" und "virtual" -> logisch) als Kernel nutzen. Damit ist der bisher CPU-fähige Code ohne größeren Aufwand portierbar.

Und zu guter letzt benutzen OpenGl, Vulkan und OpenCL (und wer weiß welche APIs noch)nutzen SPIR-V als binary intermediate Language, d.h. ob OpenCL-Kernel oder OpenGL-Shader: Nach dem Kompillieren sind sie alle einer Sprache und sollten so mehr oder weniger kompatibel sein. Gleichsam erlaubt das natürlich auch eine vielbessere Wartbarkeit weil ich nicht für jede API eine eigene Intermediate Language beherrschen muss wenns ans Feintuning geht..
 
Sparta8 schrieb:
Wenn diese Karte für Server gemacht ist und diese ja fast immer auf irgendein UNIX Betriebssystem laufen, AMD aber gleichzeitig bei Treibern in diesem Bereich kaum Aufwand betreibt, wer verwendet diese Karten dann?
Huh? AMD betreibt sowohl OpenSource als auch proprietäre Treiber für Linux. Weiterhin sind hier nicht Grafiktreiber wichtig, sondern OpenCL.

http://developer.amd.com/tools-and-sdks/open-source/
http://support.amd.com/en-us/download/desktop?os=Linux+x86
 
Huh? AMD betreibt sowohl OpenSource als auch proprietäre Treiber für Linux. Weiterhin sind hier nicht Grafiktreiber wichtig, sondern OpenCL.

Und die AMD APP SDK ist mit Abstand der beste aber OpenCL-Treiber der verfügbar ist.
 
Zurück
Oben