News GPUOpen: AMD startet Plattform „von Entwicklern, für Entwickler“

[DocWindows]

Auch ist es völlig schwachsinnig zu behaupten, dass OpenGPU eine Vorstufe zu einem Gameworks Gegenstück ist. Das würde bedeuten, dass AMD die Treiber bei einem gewissen Status wieder völlig schließt.

Wieso das denn? Niemand zwingt AMD eine geschlossene Gameworks-ähnliche Lösung anzubieten. Kann genausogut offen sein. Außerdem behauptet niemand, dass es eine Vorstufe ist, sondern dass es als Basis für so etwas dienen könnte. Konjunktiv. Das würde aber vorauseetzen, dass AMD ein Interesse daran hätte sowas zu bauen, zu warten, Integrationstools bereitzustellen und bei der Implementierung zu helfen. Und wenn nicht AMD, dann jemand anders.

 

[Shoryuken94]

Ich finde es traurig, dass viele das Konzept von Opensource nicht verstehen und es mit einer Abgabe von Entwicklungsarbeit und schlechterer Software gleichsetzen. Aber alles wo keine riesen Firma hintersteht, die nichts Preisgibt muss ja schlecht sein ^^ sieht man ja schließlich bei Linux / BSD und Windows

 

[Piktogramm]

@Hardware_Hoshi

Wir haben unteschiedliche Ausgangspunkte. Für mich ist bedeutend, was Hardwareanbieter X in Compiler einbringt. Da werfen ARM, AMD und Intel gerade sehr viel Zeug in GCC und LLVM hinein. Unter bei AMD gerade das ganze HSA Geraffel mit Ziel der Produktivität unter GCC 6 (aktuell 5). Mit dem entsprechendem Ziel, dass der Code mit möglichst wenig Aufwand für den Entwickler auf CPU und GPU läuft bzw. diese am besten parallel nutzt. Wobei wenn ich es richtig verstanden habe, AMD den Ansatz geht, dass die kleinen Anpassungne im Code unter AMD und anderer Hardware möglich ist (vor allem auf Hardware der Anbieter, die in der HSA Foundation aktiv sind). Das wäre dann wirklich ein guter Grund für den Spaß. Einmal Code schreiben, GCC drüber laufen für verschiedene Zielplattformen -> Gut performande Multiplattform Software.

Do-It-Yourself bewertest du anscheinend auch aus der Sicht der propritären Projekte und ich hab die OpenSourcler Brille auf. Als OpenSource Anhänger erwarte ich ein brauchbares Framework, welches dann durchaus zusammen weiter entwickelt werden kann. Wenn sichergestellt ist, dass das erste Release taugt und danach das Projekt ordentlich verwaltet wird, stehen alle Signale so, dass man hoffen darf .



@Shoryuken94

Naja, die Software von Seiten AMD war im Bereich Linux bisher wirklich kein Glanzstück. Ein bisschen fühlte sich da immer wieder wirklich mal etwas so an, als solle man es bitte selber fertigstellen. Genauso wie AMD auf Einträge im Bugtracker so unglaublich träge reagierte -.-. Zuletzt bei der Inkompatibilität von Catalyst mit dem GCC5. Da tat sich seitens AMD nichts, die Hotfixes wurden von Externen angeflanscht...

 

[DocWindows]

@Piktogramm: Ist ja alles schön und gut wenn man Open Source Code zur Verfügung stellt usw. Man muss es sich aber auch leisten können, und ich denke hier liegt die Sorge von Hardware_Hoshi.
Es wäre eben gut, wenn AMD etwas aus dem ganzen Code basteln, und es dann an Firmen lizenzieren würde. Stattdessen "verschenkt" man alles, in welcher Form auch immer. Wäre AMD auf Rosen gebettet mit einem dicken Finanzpolster im Rücken, würde keiner etwas zu solchen Entscheidungen sagen.
Es ist aber schon lange so, dass AMD Dinge verschenkt statt Geld damit zu verdienen, und angesichts der Finanzlage kann man da schon mal wütend werden wenn einem was an der Firma liegt. Das hat im Grunde gar nichts mit Open Source zu tun. Wenns der Firma gut geht, kanns einem maximal egal sein in welcher Form Technologien zur Verfügung gestellt werden.
Ich bin auch schon länger besorgt wenn ich sehe wie die Firma vom Management her Stück für Stück kaputtgemacht wird.

 

[Piktogramm]

@DocWindows

Das Problem ist, Intel verschenkt ihre Toolsets zum Großteil an Entwickler und das Zeug was Intel anbietet ist mächtig. Wenn AMD nun für vergleichbare Werkzeuge Geld verlangt heißt das für Entwickler nur, dass die Einstiegshürde gesteigert wird um Software auf AMD Hardware zu optimieren. Mit Software die auf Intel optimiert wird, steht AMD Hardware aber scheiße da und kann sie entsprechend nicht verkaufen. Kauft keiner AMD Hardware, braucht aber erst recht Niemand Software von AMD um für AMD Hardware Optimierung zu erreichen.
In Zeiten wo Intel mit den CPUs und XeonPhi Karten den markt der Server, Großrechner und Desktops dominiert, kann man sich als Mitbewerber nicht leisten, zum Entwicklern Hürden jedweder Form aufzuerlegen um auf die eigenen Produkte zu optimieren.

Firmen wie Apple mit ihrem Appstore können so etwas bringen. Deren Plattform verspricht Entwicklern so viel Gewinn, dass eine geringe finanzielle Einstiegshürde durchaus hingenommen wird. Bei AMD wäre es fatal, der von dir vorgeschlagene finanzielle Aufwand verspricht Entwicklern kein Benefit.

 

[DocWindows]

@Piktogramm: Ich glaube nicht dass es der richtige Ansatz ist, jetzt schon wieder zu Intel zu schielen. Man muss sich erstmal wieder Schritt für Schritt etablieren, um dann immer näher aufzurücken. Man kann nicht von heute auf morgen wieder zum großen Konkurenten werden. Erstmal muss gescheite Hardware her. Anschließend könnte man versuchen sich mit optimierten Compilern, Bibliotheken und Toolsets eine profitable Nische für diese Hardware zu erarbeiten und sie zu halten. Etwa im Serverbereich, wo man explizit Vorteile in Bezug auf HSA bewerben kann. Von da aus gehts dann vorwärts.

Ich glaube auch nicht, dass größere Entwickler Probleme damit hätten einen Obulus für auf AMD-Hardware hochoptimierte Implementationen von Algorithmen zu bezahlen. Sowas selbst zu entwicklen bindet nämlich die eigenen Ressourcen, was eventuell teuerer wird als einfach X Dollar für ne fertige Library zu löhnen. Reine Kosten-Nutzen Sache.

So wie es die letzten Jahre gelaufen ist, kann es jedenfalls nicht weitergehen. Ob eine weitere kostenfreie Veröffentlichung von Techniken etwas bringen wird, wird man sehen. In den letzten Jahren hat das jedenfalls nichts weiter als Kosten verursacht. Ich bin ziemlich fest davon überzeugt, dass es nicht reichen wird allein über Hardwareverkäufe Geld einzunehmen.

 

[Piktogramm]

Und wie soll AMD die Hardware losbekommen, wenn Niemand die Möglichkeit hat Software für diese Hardware zu optimieren? Wenn der Compiler auf eine CPU-Architektur ordentlich optimiert bedeutet das gern ein Geschwindigkeitszuwachs über 100% gegenüber einem nicht optimiertem Binary. Ohne das AMD also in die Compiler vorab alles an Optimierungen hineinschmeißt was möglich ist, wird die eigene Hardware schlicht beschissen dastehen. Den Fehler haben sie schon zur Einführung von Bulldozer gemacht. Betriebssysteme und Compiler wussten mit der Architektur nicht viel anzufangen und entsprechend bescheiden waren die Ergebnisse meist auch.
Wenn AMD also will, dass die eigene Hardware von Anfang an das volle Potential zeigt, muss die Software her, die dies ermöglicht. Jede Maßnahme, die die Verbreitung der Software verhindert ist schlecht und jede Maßnahme, die die Ausbreitung der Software fördert ist gut!

Die Vorteile von HSA für AMD gibt es nicht! Während AMD von HSA schwärmt hat Intel schlicht Cilk++ übernommen, Cilk Plus draus gemacht und für Produktiveinsatz für GCC, Clang, Microsoft Compiler und den IntelCompiler veröffentlicht. Dabei macht Cilk sehr viel von dem, was bei AMDs HSA Umsetzung Geschwindigkeit bringen sollte. Hier sollte man also weniger AMD im Vorteil sehen als viel mehr in der Pflicht endlich Anschluss zu finden. Da Intel mittlerweile eine brauchbare GPU-Architektur hat, FPGAs in die eigenen CPUs integrieren kann, mit XeonPhi eine extrem mächtige Plattform für massiv parallele Datenverarbeitung hat, HMC Speicher verfügbar ist und das alles über kostenlose, OSS Compiler ansprechbar ist, kann man auch mit AMDs GPU-Sparte nicht mehr argumentieren. An jeder Stelle kann Intel sagen "Ich bin schon (lange) da".

Insofern begrüße ich, dass AMD geschnallt hat, dass sie allen Entwicklern entgegenkommen müssen!

 

[Conceptions]

AMD bringt GPUOpen als Opensource, wird auf der einen Seite gemeckert das sie ja nur die Arbeit auf die Entwickler abwälzen würden, keinen Support geben würden etc., weshalb GPUOpen sich nicht durchsetzen würde.

Gleichzeitig wird dann angemerkt das AMD ja nicht die Marktmacht hätte um GPUOpen als proprietäre Lösung in den Markt zu drücken und sich deshalb nicht durchsetzen kann, weil dann niemand/kaum jemand GPUOpen nutzen würde.

Fazit: Egal was AMD macht, AMD kann es nicht richtig machen und alles grundsätzlich falsch. Zumindestens laut einiger User hier.

Ja also was denn nun?