News AMD GPUOpen: Direkte Kontrolle der Radeon-Hardware für Spieleentwickler

[Unnu]

Na so stimmt das ja nun auch wieder nicht. Natürlich hat AMD Support gegeben, genauso wie es Code Beispiele, Tutorials etc gibt.

AMD hat aber nicht die Arbeit für andere übernommen oder ihr eigenes Personal für lau an Projekte Dritter abgestellt. (Was ich durchaus nachvollziehen kann)
Nvidia hat dagegen Geld an Entwickler gezahlt ihre proprietären Lösungen einzusetzen und zusätzlich kostenlos Entwickler mitarbeiten lassen. Für die Entwickler/Publisher gut, weil finanzielle und personelle Entlastung. Für die Kunden so mittelprächtig.

Okay, das war Plakativ.
Und ich kann das auch - so wie Du- nachvollziehen, denn das kostet halt Geld. Dumm nur dass es der ärgste Konkurrent eben gemacht hat, während sich AMD Sympathisanten halt selbst drum kümmern mussten. Und entsprechend "viel" ist dann am Markt angekommen.
Und das ist schade. Denn letztlich hat sich AMD mit dieser NICHT-Unterstützung mit selbst in diese prekäre Lage gebracht, in der sie sich heute befinden. Nvidia mag man mögen oder nicht, jedoch in der Unterstützung der "Kunden" und in der langfristigen Strategie und vor allem im Marketing haben sie vieles richtig gemacht.

Und deswegen begrüße ich den jetzigen Schritt von AMD, mal eine technische Initiative auch mit Marketing zu begleiten.
Ich hoffe auf eine wieder erstarkte Konkurrenz. Sowohl bei den GPUs als auch bei den CPUs (halt ab 2016/17)

 

[Zehkul]

Gut, sagen wir "optimieren"

Und wo ist da das Problem für AMD? Ist doch schön, wenn jemand andres die eigene Software verbessert.

Die Forderung die immer in solchen Forendiskussionen gestellt wird ist "Einblick in den Source Code". Von Verwenden oder Ändern spricht so gut wie nie jemend. Wüßte auch nicht wozu der GPU-Teil unbedingt offen sein muss. Bringt doch nichts, weil die Hardwarearchitekturen jeweils unterschiedlich sind.

Wenn das nichts bringen würde, würde AMD keine Zeit mit dem Cuda Übersetzer verschwenden. GPUs haben schon seit längerem alle dieselben Features. Und nein, die Lizenz ist ein essenzieller Teil von Open Source. Nicht umsonst gibt es Glaubenskriege zwischen der BSD und der GPL Fraktion. Eine Lizenz, bei der du selbst schon für Verwendung bei Nvidia betteln gehen musst, ist nicht FOSS.

 

[athenemedia]

Na hoffentlich ist das nicht so ne schnelle Mark wie MANTLE!

 

[Unnu]

Na hoffentlich ist das nicht so ne schnelle Mark wie MANTLE!

Was war an MANTLE jetzt schlecht?

 

[Conceptions]

Mantle ist in der Vulkan API aufgegangen, indem es das Grundgerüst zur Verfügung gestellt hat und eine breite Plattform-, Herstellerübergreifende API ermöglicht hat.
Kann nur gut für den Kunden sein.

 

[Mextli]

Na hoffentlich ist das nicht so ne schnelle Mark wie MANTLE!

Ohne Mantle kein Druck auf MS endlich mal DX auf Vorderman zu bringen. Also besser mal die Füße still halten.

 

[athenemedia]

Nach meinen Infos hat AMD die Weiterentwicklung dieser API eingestellt. Ja gut, sie haben damit MS zum Handeln gezwungen, aber die eigene unmittelbar danach eingestellt. DAS meinte ich mit "schneller Mark..."

 

[Mr.Kaijudo]

Mantle ist in der Vulkan API aufgegangen, indem es das Grundgerüst zur Verfügung gestellt hat und eine breite Plattform-, Herstellerübergreifende API ermöglicht hat.
Kann nur gut für den Kunden sein.

Und wo bleibt diese API?

 

[Wadenbeisser]

Warum fragst du das nicht die Khronos Group?

Ergänzung (16. Dezember 2015)

Nach meinen Infos hat AMD die Weiterentwicklung dieser API eingestellt. Ja gut, sie haben damit MS zum Handeln gezwungen, aber die eigene unmittelbar danach eingestellt. DAS meinte ich mit "schneller Mark..."

Die haben garnichts eingestellt sondern für Vulcan freigegeben und nutzen es offenbar weiter für interne Zwecke.
Vielleicht sind Teile der Weiterentwicklung gar im GPUOpen Programm enthalten.

Ergänzung (16. Dezember 2015)

Bevor es wieder Geschrei gibt, hier noch die entsprechende Passage aus ner alten Nachricht:

AMD will die hauseigene API jedoch nicht auslaufen lassen, sondern stattdessen weiterentwickeln. Mantle soll mehr werden, als ausschließlich auf viele Draw Calls optimiert zu sein und damit mehr sein als Mantle 1.0, DirectX 12 und GLnext aktuell hauptsächlich sind. Die API soll AMD weiterhin als „Innovationsplattform“ dienen und für Entwickler mit speziellen Ansprüchen gedacht sein.

https://www.computerbase.de/2015-03/amd-streicht-oeffentliches-sdk-der-mantle-api/

Dieses "will mehr sein" passt doch wie die Faust aufs Auge zu GPUOpen.

 

[strex]

Naja die Frage ist doch, kauf ich irgendwann wenn ich aufruesten muss, wieder cuda karten, mit der man die neue software die man fuer programmieren will umstaendlicher zeitaufwendiger (da grafikkarten programmieren bisher aufwendiger war wie cpus) oder kann ichs maximal effizient mit c++ coden.

Wenn man das macht und alle Cuda Entwickler entlässt, steigt man nicht auf AMD um. Wenn ich nur C++ schreiben möchte, ohne Geschwurbel mit Cuda oder OpenCL gehe ich zu Intel. Da schreibe ich ein Programm für die Xeon und den Xeon Phis ohne Änderung oder Anpassung. Das ist auch der Grund warum Intel so viele Systeme in kurzer Zeit mit Phis absetzen konnte. Und genau das ist das Problem welches NV und AMD in den nächsten Jahren dort bekommt. Dann brauche ich keine GPUs oder zusätzliche Server mehr sondern, auf den Beschleunigern läuft das OS und die Berechnungen mit Standard C++ Code. Das ist die effizienteste Lösung die machbar ist, denn die GPUs brauchen immer Anpassungen und extra Code und brauchen immer einen extra Server der sie mit Daten füttert und die Anbindung zur Außenwelt darstellt.

Ich spare also viel mehr Zeit als 10% beim coden in c++ von neuem code, dann schluck ich vielleicht die 10% umcodungsaufwand von altem code, waehrend ich 100% nicht geschluckt haette.

Na dann muss ich ja auch alle Cuda Entwickler entlassen und neue einstellen. Bis sich das rentiert und eventuelle Streitereien gibt lasse ich das doch ohne Probleme in Cuda schreiben. Denn mit dem C++ Code läuft ja dann wieder nur auf einem System.

Aber das ist ja gar nicht AMDs Ziel. Sie wollen die Cuda Code-syntax verwenden und per Konvertierung auf C++ umwandeln damit die eigenen Karten dies fressen. Das hat den Grund, da es in diesem Bereich hauptsächlich Cuda Entwickler gibt und da wird nichts so schnell umgestellt.

 

[Wadenbeisser]

Wer redet denn davon das alle Entwickler entlassen und neue eingestellt werden müßten? Schonmal was von Umschulung und Weiterbildung gehört?

Wo stand zudem geschrieben das der umgewandelte Code nicht auch auf den Geforce Modellen bzw. anderen OpenCL/HSA kompatiblen GPUs läuft?

 

[strex]

Wer redet denn davon das alle Entwickler entlassen und neue eingestellt werden müßten? Schonmal was von Umschulung und Weiterbildung gehört?

Das bezahlt wer? Für Umschulung und Weiterbildung der ganzen Entwickler kann ich einiges an Hardware kaufen. Da sind Hardware-Kosten das geringste. Jahrelanges Know How lässt sich nicht in einigen Tagen oder Wochen umbauen. Wie man sieht macht es betriebswirtschaftlich keinen großen Sinn.

Es ist lediglich der Versuch von AMD irgendwie etwas vom HPC-Markt abzugreifen. Bis dato ist man dort mit den FirePro Modellen vollends gescheitert.

Wo stand zudem geschrieben das der umgewandelte Code nicht auch auf den Geforce Modellen bzw. anderen OpenCL/HSA kompatiblen GPUs läuft?

Das macht ja erst recht keinen Sinn. Warum sollte ich Cuda Code schreiben, den konvertieren und daraus wieder Cuda Code für NV generieren. Dann spar ich mir den gesamten Overhead und programmiere direkt in Cuda. Es ist ja nicht so das ich im HPC Bereich auf einige Prozent an Performance verzichten kann.

 

[HerrRossi]

Bei den Buzzwords "Treiber, Open Source und Linux" müssten bei Valve doch eigentlich alle vor Freude in Jubel ausbrechen, vllt. kommt SteamOS damit doch noch auf einen roten Zweig

 

[Zehkul]

Wenn man das macht und alle Cuda Entwickler entlässt, steigt man nicht auf AMD um. Wenn ich nur C++ schreiben möchte, ohne Geschwurbel mit Cuda oder OpenCL gehe ich zu Intel.

… oder zu AMD. HC Compiler. Die News hast du schon gelesen?

 

[Wadenbeisser]

Das bezahlt wer? Für Umschulung und Weiterbildung der ganzen Entwickler kann ich einiges an Hardware kaufen. Da sind Hardware-Kosten das geringste. Jahrelanges Know How lässt sich nicht in einigen Tagen oder Wochen umbauen. Wie man sieht macht es betriebswirtschaftlich keinen großen Sinn.

Es ist lediglich der Versuch von AMD irgendwie etwas vom HPC-Markt abzugreifen. Bis dato ist man dort mit den FirePro Modellen vollends gescheitert.



Das macht ja erst recht keinen Sinn. Warum sollte ich Cuda Code schreiben, den konvertieren und daraus wieder Cuda Code für NV generieren. Dann spar ich mir den gesamten Overhead und programmiere direkt in Cuda. Es ist ja nicht so das ich im HPC Bereich auf einige Prozent an Performance verzichten kann.

Vor allem Software Entwicklung dürfte ein Berufsfeld sein in dem man geradezu die Pflicht zur Weiterbildung hat denn sonst ist das bisherige Wissen schnell veraltet und man hat ein Problem. Du kannst ja mal Ärzte frage was die zum Thema Weiterbildung sagen. Betriebswirtschaftlich bereut man fehlende Weiterentwicklung spätestens dann wenn einem wegen veralteter Kenntnisse die Kunden weglaufen.
Und das mit den Hardware Kosten...logisch denn die trägt schließlich der Kunde.

Was du auf den Tisch legst ist ganz einfach das Fehlen langfristiger Investitionen um den kurzfristigen Profit zu steigern und führt nur allso oft in die Insolvenz.

Ergänzung (17. Dezember 2015)

Bei den Buzzwords "Treiber, Open Source und Linux" müssten bei Valve doch eigentlich alle vor Freude in Jubel ausbrechen, vllt. kommt SteamOS damit doch noch auf einen roten Zweig

Das ist eher allgemein etwas für die Linux Gemeinde udnd er Zweig wäre dann grün.

 

[garrulus]

Grundsätzlich keine schlechte Sache, gerade weil OpenSource. Aber kein Entwickler macht sich den Aufwand, direkt auf die Hardware zuzugreifen. Da wird der gemeinsame Nenner benutzt, also die 3D API. Außer es gibt finanzielle Unterstützung von AMD, aber das kann man sich aktuell wohl kaum leisten.

Sehe ich auch so. Gerade als Wald und Wiesenentwickler ist es mir doch egal, was es von Nvidia oder AMD für Hackertools gibt um auf deren Hardware noch irgendetwas zu optimieren. Ich starte in Unity einfach meinen Windows Build (und vielleicht noch einen für Linux, damit ich cool bin) und es läuft. Wie Unity das macht, ist mir wayne.^^
Ich denke bei der UE4 oder CryEngine ist es ähnlich.

Für die wenigen großen Studios, die ihre eigenen Engines haben, ist das mit Sicherheit interessant. Wobei ich mich frage, warum man vom Aufwand her für die kleine Zielgruppe PC Spieler für die noch kleinere Zielgruppe aktuelle AMD Hardware optimieren sollte?

 

[Dai6oro]

GPU-Open ist jetzt online, wenn ich das richtig sehe sogar pünktlich:

http://gpuopen.com/