News FirePro W4300: AMDs schnellste Low-Profile-Grafikkarte für Designer

[MichaG]

Vornehmlich zum Einsatz im Bereich Computer-Aided Design (CAD) konzipiert, stellt AMD die Profigrafikkarte FirePro W4300 vor. Mit der Bonaire-GPU ist die W4300 technisch mit der W5100 verwandt. Leistungsaufnahme und Formfaktor fallen aber kleiner aus.

Zur News: FirePro W4300: AMDs schnellste Low-Profile-Grafikkarte für Designer

 

[pipip]

Mit GCN 1.1 und 768 Shader wäre das ja auch mal eine interessante Grafikkarte für den Desktop Markt. Die schnellste Low Profile Karte AMDs ist aktuell die R7 250E die eine 7750 mit 512 Shader und GCN 1.0 ist.

Die Performance dürfte der 750 GTX sehr nahe sein.

Wobei wohlgemerkt:
https://geizhals.at/msi-r7-260-1gd5-oc-v293-026r-a1058914.html
https://geizhals.at/msi-r7-360-2gd5-oc-v809-1673r-a1282106.html
Eigentlich ist es nur eine R7 260 bzw 360 mit etwas niedrigeren Takt. Wieso findet man hier keine Low Profile Karte ?

 

[thokra2008]

@pipip: Warum vergleichst du Äpfel mit Birnen?? Ne FirePro mit einer R7 250E vergleichen. Echt schwachsinnig.

Die W4300 hat doch GCN 1.1 und 768 ALUs. Zu wenig? Da nimm eine höhere Graka zu Programmieren. Aber hör mit den dämlichen Vergleichen auf.

 

[[F]L4SH]

Ich glaube da hat gerade jemand nicht verstanden, was Pipip sagen wollte und hat einfach mal so geflamed

Ansonsten kann man nur Erfolg wünschen. Der Preis kann die Karte auch für einige Amateure und kleine Unternehmen interessant machen.
Auch wenn sie über die Wegelager... Distributoren eher wieder für 600€ im PC landet

 

[D0m1n4t0r]

Ganz ehrlich, bei dem Preis holt man sich einfach eine R9 390 oder GTX 970 wenn CUDA von der Software unterstützt wird sowie ein größeres Gehäuse wenn man sich selbst eine Workstation zusammenbaut.
Die Karte ist dann zwar nicht unbedingt für die jeweils eingesetzte CAD Software zertifiziert, aber damit lässt sich genausogut arbeiten.
Und die Kosten für das mehr an Stromverbrauch holt man durch die mittels stärkerer Karte eingesparte Arbeitszeit locker wieder rein.

Und wer wirklich professionell damit arbeitet der holt sich direkt eine komplette zertifizierte Workstation, z.b. von HP oder anderen großen Herstellern.

 

[pipip]

thokra2008

Mit GCN 1.1 und 768 Shader wäre das ja auch mal eine interessante Grafikkarte für den Desktop Markt

Bitte nächstes mal genauer lesen. Klar ist das eine Karte für den professionellen Markt, aber es spricht nichts dagegen, wenn es ein Modell für den Desktop Markt als "Gaming" Karte gäbe, sprich eine "R7 355" low profil.

Oder besser gesagt, es fehlt mir eine aktuellere low profile Karte von AMD und die Karte ist der Beweis, dass für ein Bonaire PRO auch ein low profile Kühlung reichen kann. Die Performance müsste nicht viel weit schlechter als jeder einer 260 sein und somit sprühbar höher als jene einer 250E.

BTW, schockiere dich nicht, wenn die GPUs die für Desktop und Profi Markt verwendet werden die selben sind.

 

[r4yn3]

Zumindest wenn ich das im Kopf so überschlage, wäre die W4300 effizienter gegenüber dem Nvidia Pendant. Zum selben Preis und beinaher selber TDP, warum nicht. Hoffentlich schafft es AMD über kurz oder lang mal wieder mit FirePros Fuß zu fassen.

 

[thokra2008]

@[F]L4SH: Kann durchaus sein. Nur bei Pipip kann man nie wissen, wie er es meint.

 

[pipip]

r4yn3

Es kommt noch hinzu, dass AMD durch das Boltzmann Initiative Programm auch an Compiler arbeitet, die CUDA in HSA (unterstützt weiterhin auch OpenCL) übersetzt, somit kann man durchaus hoffen, dass sich für AMD die Karten eventuell bessert, wenn Entwickler, falls sie CUDA nützten wollen, dann nicht mehr AMD grundsätzlich als Hardware ausschließen müssen.

and the Heterogeneous-compute Interface for Portability (HIP) tool for porting CUDA-based applications to a common C++ programming model.

 

[strex]

r4yn3

Es kommt noch hinzu, dass AMD durch das Boltzmann Initiative Programm auch an Compiler arbeitet, die CUDA in HSA (unterstützt weiterhin auch OpenCL) übersetzt, somit kann man durchaus hoffen, dass sich für AMD die Karten eventuell bessert, wenn Entwickler, falls sie CUDA nützten wollen, dann nicht mehr AMD grundsätzlich als Hardware ausschließen müssen.

Da werden wir sehen was dabei raus kommt. Wenn das wieder so ein Grütze wird wie alle Konverter die Programmiersprachen konvertieren und kompilieren, dann vergiss es. Das wird keiner verwenden..und total Mist rauskommen. Entweder total langsam, da Sprachen + Architektur eben Ihre Eigenheiten haben oder erst einmal ewiges Debugging braucht. Da dann doch eine Funktion nicht das macht was es soll. Parallel dazu muss dann auch AMD immer daran Änderungen vornehmen, wenn NVIDIA an Cuda etwas ändert oder hinzufügt. Supi. Da reicht es ein paar Funktionen die AMDs Plattform nicht in Hardware abdecken können und in Software läuft, schon ist die Performance im Arsch. Nichts mit HPC..

Sehr ersichtlich ist das doch schon an Java und C++. Gab es da wirklich funktionsfähig Konverter, nicht. Das einzig was das ist, dass Eingeständnis von AMD das man mit OpenCl nicht weit kommt und deshalb keiner kauft.

 

[pipip]

strex

To bring applications written for CUDA onto AMD platforms, AMD announces the new HIP tool. AMD testing shows that in many cases 90 percent or more of CUDA code can be automatically converted into C++ by HIP with the final 10 percent converted manually in the widely popular C++ language. This greatly expands the installed hardware base available to run what were formerly exclusively CUDA-based applications. At SC15, AMD is demonstrating the potential for HIP, running the CUDA-generated Rodinia benchmark suite on AMD GPUs.

HSA soll ja nicht nur AMD spezifisch bleiben. Man arbeitet an Standards und gemeinsame Plattformen und es arbeiteten mehre an dem HSA Compiler.
Ziel ist es, nicht OpenCL zu ersetzten, sondern den Entwickler so gut wie es geht nahe zukommen. CUDA hat sich nun mal in vielen Bereichen durchgesetzt und wurde lange verwendet. Allein deshalb werden auch viele Entwickler nicht auf einmal Abstand davon nehmen.

BTW C++ hat bekanntlich mehr mit CUDA gemeinsam als JAVA.

 

[strex]

Wow 10% Code Debugging. Wer hat da Lust? Keiner, dass heißt dann immer noch nicht das der schnell läuft. Schau dir einfach Konverter gängiger Sprachen an, alles Grütze und da arbeitet man schon seit Jahren. Also investiere ich erst ziemlich viel Zeit für die Optimierung meines Codes in Cuda und dann muss ich nochmals alles bearbeiten weil ich 10% fixen muss. Dann heißt es aber immer noch nicht das es schnell läuft. Grütze hoch 10.

HSA hier HSA dort. Das betest du schon seit Jahren. Was kam bis jetzt brauchbares. Nichts. Das ist bis jetzt eine Luftnummer und die HSA Foundation wie du sie immer bezeichnest scheint selbst bis auf AMD kein Interesse zu haben. Warum, keiner der Founder (ausgenommen Qualcomm mit ihrem vielleicht zukünftigen Server ARM - steht aber auch in den Sternen) hat im HPC Markt etwas zu schaffen. Selbst AMD mit 3 Systemen nicht.

Alle anderen kommen mit NVIDIA bestens aus. Das ist und bleibt der krampfhafte Versuch doch ein paar Dollar im HPC Markt zu tätigen. Selbst Intel hat da AMD alle Ränge abgelaufen.

BTW C++ hat bekanntlich mehr mit CUDA gemeinsam als JAVA.

Sprechen aber nicht nur syntaktische und semantische Unterschied an, sondern auch der Architektur im besondern der Low Level API.

Außerdem, wie anandtech auch beleuchtet könnte das in einem Rechtstreit zwischen AMD und NVIDIA ausbrechen wie bei Google und Oracle. Denn die bauen auch die API nach.

 

[pipip]

strex
Oder man beweißt Eier und passt sich bei den Code an, wo es im reinen CUDA Code zu Problemen kommt und schon vermeidet man die 10%.
Ein bisschen Initiative kann man schon erwarten oder machst du dein Leben lang gern nur das selbe.

Was HSA selbst angeht. Intel ist hier schon weiter als NV und Samsung, Qualcom, ebenso MediaTek haben ihre SoC mit HSA vorgestellt.
Und auch wenn ich für dich wieder zu viel "spekuliere", weil man selbst es ja nie macht, laut Gerüchten, dessen Quellen ARM selbst sein soll, ist K12 übrigens so breit wie Zen (4 Decoder) und besitzt ebenso Hyperthreading.

Alle anderen kommen mit NVIDIA bestens aus.

Klar, weil wenn man nicht NV will, soll man direkt zu MIC greifen. Am besten von einem Monopol in das nächste

Cuda basiert auf C und C++ basiert auf C. Java war von anfang an eine reine objektorientierte Sprache. Somit hat C++ mit Cuda mehr gemeinsam, weil ich in C++ auch wie C Programmieren kann. Bei Java hindert mich immer die JavaMachine. Aber wahrscheinlich kennst du dich besser aus.

 

[strex]

strex
Oder man beweißt Eier und passt sich bei den Code an, wo es im reinen CUDA Code zu Problemen kommt und schon vermeidet man die 10%.
Ein bisschen Initiative kann man schon erwarten oder machst du dein Leben lang gern nur das selbe.

Vielleicht im Kindergarten. Aber da wo man keine Präferenz für einen Hersteller hat, beleuchtet man das rein wirtschaftlich. Da spielen Emotionen zu einem Hersteller keine Rolle. Warum mehr Zeit investieren nur das es dann läuft. Warum dann noch mehr Zeit investieren zum Optimieren. Warum noch mehr Zeit investieren um auf AMD zu warten weil die gerade das Tool anpassen müssen weil NVIDIA wieder was geändert hat.

Das alles kostet jede Menge Geld und wie man weiß ist genau das auf das die gesamte Industrie achtet. Anders sähe es aus, wenn AMD daher kommt und sagt. Gebt uns euren Cuda Code, wir schreiben den für unsere Hardware kostenlos um und optimieren ihn. So das dann dieselbe oder schnelle Performance erreicht wird. Da wird aber nie kommen.

Was HSA selbst angeht. Intel ist hier schon weiter als NV und Samsung, Qualcom, ebenso MediaTek haben ihre SoC mit HSA vorgestellt.
Und auch wenn ich für dich wieder zu viel "spekuliere", weil man selbst es ja nie macht, laut Gerüchten, dessen Quellen ARM selbst sein soll, ist K12 übrigens so breit wie Zen (4 Decoder) und besitzt ebenso Hyperthreading.
.

Zum K12 ist bereits alles gesagt. Das darf Simon gern nochmals ausführen wenn er will. Das Ding ist bereits tot bevor es erscheint. Er kam jetzt schon min. ein Jahr zu spät. Xeon-D (geht man von laufenden X-Gene 1 und 2 aus und interpoliert die bessere Fertigung dazu) dreht Kreis um ihn. Selbst X-Gene kommt nicht gegen c2700 Atom an also wird für den K12 schwer. Wenn K12 erscheint, dürfte der Nachfolger von c2700 kommen, was die P/W weiter erhöht. Das wird schwer.

Und dann bleibt und ist immer noch das Problem das es ARM ist. Das lässt sich auch so nicht beheben.

 

[pipip]

strex

Der Grund ist einfach, weil es durchaus auch die Hardware-Bestückung und Lizenzen Rollen spielen und es darauf ankommt, wie groß der "Unterschied" bei der Programmierung ausfällt.
Wenn der Unterschied so ausfällt, dass im Endeffekt nur einige Sachen anders aber ähnlich geschrieben werden muss, sodass es quasi wie ein "Dialekt" von CUDA sein könnte, dann ist der Aufwand somit minimal.
Und besonders Lizenzen können interessant sein, wenn HSA Open CL ect unterstützt oder darauf aufbaut.

BTW, das was ich hier jetzt schreibe ist nicht weniger Spekulation was du betreibst, also bitte weniger spekulieren Strex.


K12 ist hier auch Offtopic. XGene ist kein Vergleich und ihr beide geht bei K12 von einem aktuellen A53 oder A72 Core aus.

Da K12 laut Gerüchten offensichtlich mindestens genauso breit, wenn nicht breiter als Cyclone wird und zusätzlich noch SMT hat, ist man was die IPC allein angeht, schon sehr nahe an der Core I Serie, denn der A-Prozessor von Apple ist nicht mehr weit weg.
Für AMD bietet sich dann der 22nm FD-SoI Prozess an, der dann durchaus Prozessoren mit relativ hoher Taktrate bei wenig Verbrauch aber bei deutlich günstigeren Herstellungs-Verfahren anbieten könnte und das 2017, wo Intel, Samsung und TSMC selbst noch auf deren 14nm FinFet Verfahren setzten.
(Ich spreche hier aber von einer Konkurrenz von eher Multi-Core Prozessoren mit einer niedrigen TDP, wie sie Intel erst neulich vorgestellt hat)


Aber ja, ob ARM sich durchsetzten wird ? Das wird sich zeigen, zuerst muss mal Zen zeigen, wie gut die Architektur ist oder ob es ein flopp ist, dann kann man über Zen Gedanken machen. Aber wir sehen mit IBM Power, dass es nicht zwingend X86 im HPC Markt sein muss.
Und K12 kann AMD dann an alle weiteren lizenzieren. Macht ja Qualcom nicht anders.

 

[Nai]

Dass man im Endeffekt eine zeigerbasierte Sprache wie CUDA auf eine bufferbasierte Sprache wie OpenCL abbilden will macht mich auch etwas skeptisch.

 

[pipip]

Nai
http://www.hsafoundation.com/hsa-developer-tools/

Compilers
Khronos Group OpenCL™
Microsoft C++ AMP
CLANG based C++ AMP
LLVM HSAIL Code Generator
HSAIL Assembler and Dissembler
Fabric Engine KL Language and Run time for Python
HSAIL Finalizer
GCC-HSA branch

AMD hat ja erst begonnen, das vorzustellen, da werden sicherlich noch mehr Infos in der Zukunft folgen, außer es ist eine Sackgasse, wie Strex beschreibt. Das kann man natürlich nicht ausschließen.

Aber bei der Initiative soll es ja darum gehen, quasi CUDA kompatibel zu sein. Du kennst dich ja bei CUDA gut aus. Ich habe mir von wem sagen lassen, dass CUDA AMD Hardware nicht direkt ausschließt, sondern durch aus auch Fragmente vorhanden sein sollen, die AMD kompatibel sind.
Was das genau bedeutet, kann ich aber nicht deuten, aber ich habe mir sagen lassen, theoretisch wäre Cuda auch auf AMD Karten möglich. Somit müsste ein Anpassung nicht unmöglich sein.
Aber hier bist du bekanntlich der Forum-Experte, bzw, jener der sich zu mindestens äußert.

Hinzukommt eigentlich die Aussagen von NV, dass sie selbst mit Pascal ein mixed Precision Architektur ähnlich wie GCN einführen wollen. Muss aber kein Vorteil sein

 

[alxtraxxx]

Aber da wo man keine Präferenz für einen Hersteller hat, beleuchtet man das rein wirtschaftlich. Da spielen Emotionen zu einem Hersteller keine Rolle

Verstehe ich nicht, wieso nimmt man dann Bibliotheken, die nur auf einem System funktionieren? Ich hab sowas das letzte mal gemacht zu Dos-Zeiten, weil ich einfach keine Lust hatte für noch die 2 anderen Soundkartenhersteller alles programmieren zu müssen.
Wenn man wirtschaftlich denkt nimmt man immer Bibliotheken mit denen man den größeren Markt beliefern kann (Monopole mal nicht betrachtet), da haut man sich nicht normal vorsätzlich noch Kunden weg.

 

[Nai]

Aber bei der Initiative soll es ja darum gehen, quasi CUDA kompatibel zu sein. Du kennst dich ja bei CUDA gut aus. Ich habe mir von wem sagen lassen, dass CUDA AMD Hardware nicht direkt ausschließt, sondern durch aus auch Fragmente vorhanden sein sollen, die AMD kompatibel sind.

Ohne näheren Kontext schwer zu sagen, was gemeint war und auf welchen Teil von CUDA es überhaupt bezogen war. Da moderne GPUs anundflüssig recht ähnlich sind, wären CUDA C/C++ und die CUDA-Runtime-API bzw die CUDA-Treiber-API prinzipiell auch auf AMD-Karten lauffähig, sogar wenn man hier und da wahrscheinlich kleinere Einschränkungen in Performance und Funktionalität in Kauf nehmen müsste. Beim PTX-Zwischencode ebenfalls. Wo eben AMD-GPUs "ausgeschlossen" werden ist bei der NVIDIA-IDE, der SASS-Codeerstellung und bei der Anbindung des AMD-Treibers an die CUDA-DLLs und so weiter. Mixed-Precision hat damit nur wenig zu tun, da es wenn überhaupt nur auf einer niedrigen Ebene der Codeerstellung , nämlich wenn PTX nach SASS konvertiert wird, eine Rolle spielt.

Die Ursache bei meiner Skepsis war aber, dass AMD in dem Boltzmann-Projekt versucht eine niedrigere Abstraktionebene (Zeiger) auf eine höhere Abstraktionsebene (Buffer) abzubilden, wobei beide nicht wirklich miteinander kompatibel sind. Da hilft AMD die Verwendung von C++ AMP auch wenig, weil es afaik ebenfalls bufferbasiert ist. Wie es mit HSAIL intern aussieht weiß ich nicht. Bei einfacheren Fällen mag in Blotzmann die automatische Konvertierung von Zeigern nach Buffern im Hostcode durch den Compiler noch funktionieren, aber bei komplexeren? Als Beispiel ein einfacher CUDA-Code der dir bereits Probleme bei automatischer Konvertierung bereiten wird, weil du ihn in OpenCL auf ähnliche Weise nur schlecht darstellen kannst:

struct GPUDaten
{
float* MyPointers[256];
};
//.....
GPUDaten D;
D.Init();//Alloziert Speicher auf der GPU und setzt Zeiger dementsprechend
MyGPUKernel<<<1,1>>>(D);

Wie sieht die Struct nach einer Konvertierung nun aus? Beinhaltet sie OpenCL-Memobjekts, wie sie es nach einer Konvertierung hostseitig müsste, oder Zeiger, wie sie es GPU-seitig müsste? Und das war nur eins von vielen Problemen dabei, das mir gerade so einfällt.

Edit: Aah sie wollen gar CUDA nicht nach OpenCL umtransformieren. K.a. wo ich das die letzte Zeit aufgeschnappt habe.

 

[strex]

strex
BTW, das was ich hier jetzt schreibe ist nicht weniger Spekulation was du betreibst, also bitte weniger spekulieren Strex.

Viel spekulieren muss ich da nicht. Die Zahlen lieferst du ja selbst. 10% vom Code müssen erneut angefasst und angepasst werden. Bei jeder Konvertierung. Das bedeutet ich habe hohe extra Kosten im Gegensatz zu nvidia wo es gleich läuft. Das bedeutet dann auch, dass die Software mal 10% oder mehr kostet und das bei Änderungen wieder 10% dazu kommen. Wer mal Debugging betrieben hat, weiß dass da schnell mehr Zeit drauf geht als den kaputten Teil neu zu programmieren.

Für die 10% wovon wir sprechen kann ich zig Karten kaufen. Warum sollte ich das dann tun? Wirtschaftlich macht das keinen Sinn. Denn ich zahle 10% oder mehr für die Programmierung nur das es auf AMD läuft und das für jedes einzelne Programm das ich habe.

K12 ist hier auch Offtopic. XGene ist kein Vergleich und ihr beide geht bei K12 von einem aktuellen A53 oder A72 Core aus.

Da K12 laut Gerüchten offensichtlich mindestens genauso breit, wenn nicht breiter als Cyclone wird und zusätzlich noch SMT hat, ist man was die IPC allein angeht, schon sehr nahe an der Core I Serie, denn der A-Prozessor von Apple ist nicht mehr weit weg.

Aber auch nur wenn man den Xeon oder Core I nicht mit AVX und co. füttert. Das haben wir aber oft im dem Umfeld und dann sieht der Apple A wieder sehr klein aus. Da zählen dann eben nicht Browserbenchmarks.

Schau dir einfach mal das Design des X-Gene 2 (http://www.hotchips.org/wp-content/...30-X-Gene-Singh-AppMicro-HotChips-2014-v5.pdf) an und vergleichen es mit deinem Wunder K12. Oh, sehr ähnlich. Fast gleiches Konzept. Nur das X-Gene 2 noch in 28nm gefertigt wird. Von den Specs ala Memory, 10GE und co. ist der K12 ein Clone des X-Gene 2. So gar L1, L2 und L3 sind vom X-Gene 2 mit des K12 absolut identisch. Merkwürdig. Was für ein Wunder der X-Gene 2 bietet auch bis zu 8 A57 Kerne, genau so wie der K12.

Und der K12 verwendet A57 Kerne. Wo, steht genau hier. Das schreibt sogar AMD selbst: http://www.golem.de/news/opteron-a1...ke-im-server-markt-ausnutzen-1504-113676.html

Der X-Gene 2 ist genau so ein Abklatsch des A57 mit eigenen Anpassungen/Verbesserungen. Genau das was der K12 auch macht. Von dem X-Gene 2 ist die Leistung bekannt. Ist selbst angegeben. Dann rechnen wir gut gläubig 1 GHz für den K12 drauf (also 3,8GHz) zwecks besser Fertigung und so, dann sieht immer noch Spec2006_rate/W nicht so gut aus. Da muss der X-Gene 2 die über 3 fache Effizienz (Performance/Watt) zu den Atoms aufholen zum X-Gene 1: http://www.cnx-software.com/2015/04...720-vs-applied-micro-x-gene-1-vs-ibm-power-8/ Das gibt selbst apm nicht an (http://www.hotchips.org/wp-content/...30-X-Gene-Singh-AppMicro-HotChips-2014-v5.pdf). Denn der X-Gene 2 ist nur 0,6 fach so Effizient wie der X-Gene 1. Das hole ich auch nicht mit einer besseren Fertigung auf, denn es fehlen noch fast die 2,4 fache Effizienz. Dann habe ich ja erst noch mit den Atoms (Avoton) aufgeschlossen die auch noch in 22nm sind. Vom Xeon-D jetzt nochmals ganz abgesehen der eh ein P/W König ist.


Wenn man sich beide Designs anschaut hat man eher die Vermutung das AMD den X-Gene 2 einfach nachgebaut hat. Features, Design, Memory, Schnittstellen alles gleich.

Edit: Aah sie wollen gar CUDA nicht nach OpenCL umtransformieren. K.a. wo ich das die letzte Zeit aufgeschnappt habe.

Ja genau, die wollen die Cuda Syntax auf OpenCl konvertieren und dann kompilieren. So schreibt es jedenfalls anandtech hier und ist auch schön auf den Bildern zu sehen. Deshalb auch Cuda syntax-like: http://www.anandtech.com/show/9792/...e-announced-c-and-cuda-compilers-for-amd-gpus

Wenn die Funktion X bei Cuda das aufruft, wird jetzt versucht zu schauen was die Funktion macht und wird dann nachgebaut. So da die Cuda Syntax dann später beim kompilieren statt der Cuda Funktion die nachgebaut für OpenCl verwendet. Ähnlich Google Dalvik Virtual Machine zu Java Virtual Machine, wo man die APIs nachgebaut hat. Das ist, wie auch anandtech wieder beschreibt, rechtlich nicht ganz sauber und nvidia könnte da AMD ordentlich in die Suppe spucken. Zudem muss beachtet werden, wenn nvidia neue Funktion einbaut oder Änderungen vornimmt muss AMD erst wieder die gesamten Tools für die Konvertierung anpassen.

Deshalb muss auch 10% vom Programmcode nach der Konvertierung (Angabe von AMD) händisch selbst angepasst werden, weil keine passende Umformung möglich ist.