GPUOpen: Gameworks in frei von AMD.

AMD hat eine Toolsammlung angekündigt, mit der Spielentwickler direkteren Zugriff auf GPUs haben, als dies selbst mit DX12/Vulkan möglich ist. Außerdem soll es Samples und Demos geben.
Das ganze wird über GitHub veröffentlicht und ist komplett öffentlich. Auch Modifikationen und Verbreitung des Quellcodes sind erlaubt.
GPUOpen richtet sich an Spieleentwickler und auch den professionellen Compute-Bereich.

GPUOpen Gaming

Zu denn Spezialfunktionen für Spieleentwickler zählen TressFX 3.0, „ShadowFX“ (Schatten), „GeometryFX“ (Geometrie) und „AOFX“ (Ambient Occlusion).
Die Samples werden erstmal für DX11 vorliegen und später auch auf DX12 portiert werden können.

Neben den Effekten wird GPUOpen auch Tools für die Entwicklung von Spielen beinhalten. AMD benennt CodeXL (inklusive DirectX-12-Plug-In) sowie Tootle (Triangle Order Optimization Tool).
Zusätzlich kommen SDK wie u.a. LiquidVR, FireRender sowie RapidFire. zudem werden AMD-eigene Entwicklertools für Compute bereitgestellt sowie zahlreiche weitere Samples für allgemeine DirectX-11- und DirectX-12-Effekte. Sämtliche Tools und Effekte will AMD von Zeit zu Zeit aktualisieren und auch ausbauen.

GPUOpen Compute

Außerdem wird der HPC bereich ausgebaut, wozu schon die Boltzmann-Initiative zählt.

In der Kurzfassung setzt sich diese aus dem HCC-Compiler (Heterogeneous Compute Compiler), HIP und einem angepassten 64-Bit-Treiber für Linux zusammen – alles ist optimiert für HSA und ebenfalls Open Source.

Die Boltzmann-Tools sollen im ersten Quartal 2016 erstmal als Early-Access starten.

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

Warum aufeinmal diese Entwicklungen? Das muss doch einen Grund haben, da hat wohl irgendwer Schiss bekommen. Ich find´s prima Nur leider zu spät

Finde nicht das es zuspät ist. Mit DX12 werden die Karten ja neu gemischt. Der neue Crimson-Treiber war ja schon der 1. Schritt.

Zumal es eben nicht wie bei Gameworks den faden Beigeschmack gibt, dass die Konkurrenz ausgebremst wird.

Und vorallem, für Entwickler voll einsehbar ist
Aber wie es genutzt wird und es sich auswirken wird, werden wir wohl noch abwarten müssen :/

Kerkilabro schrieb:

Warum aufeinmal diese Entwicklungen? Das muss doch einen Grund haben, da hat wohl irgendwer Schiss bekommen. Ich find´s prima Nur leider zu spät

Zum Vergrößern anklicken....

Weil AMD die Grafikkartensparte seit September wieder sich selbst leiten und Grafikkarten entwickeln lässt. Als Radeon Technologies Group.

Und da haben wohl zur Abwechslung Leute die Zügel in der Hand, die ein besseres Marketing betreiben können, als ein 13 jähriger auf Youtube.

Totgeburt von AMD #4. Die Entwickler haben ihre Tools und Plattformen, Bibliotheken und Assets. Kein cleverer Mensch macht eine Neuentwicklung damit, weil die Probleme damit nicht abgeschätzt werden können. DX12 ist eine API die schon mehr zulässt und darauf freuen sie sich auch sicherlich irgendwann. Vulkan ist schon die erste Nische die sicherlich kaum bedient wird. Jetzt noch so ein Gedöns? Das ist dass was mich an AMD auch nervt. Sie schaffen es nicht eine Sache konsequent durch zuziehen. Kommt Gegenwind, drehen sich die Wendehälse wieder in die andere Richtung. Was machen, dazu stehen und entwickeln. Und nicht tausend Baustellen und nichts richtiges.

Soll nicht heißen dass ich diesen Ansatz nicht gut empfinde. Aber DX12 und/oder Vulkan sollten erstmal reichen. Und mit Portierungen zu werben ist immer ganz ganz heikel. Da passt dann meistens vorne und hinten nichts.

Dafür ist es aber frei, es kann also auch von der Community weiterentwickelt werden. Und mit den Beispielen sollte man (auch als Neueinsteiger) da ganz gut durchblicken.
Wenn einem etwas fehlt oder man etwas ändern möchte, kann man eben auch einfach in den Code und hat nicht einfach nur eine geschlossene Bibliothek mit einem Interface.

@ oldsql.Triso:
Du hast ja voll den Durchblick. Allein Deiner Logik nach würde Gamesworks von NVidia nicht benutzt werden. Zähl mal die Gameworks-Titel!

Ich finde es klasse, dass AMD soviel offene Standards etabliert. Das ging nicht erst mit der Radeo-Group los, sondern begann schon mit dem HSA-Konzept. Je mehr offene APIs es gibt, desto besser. Nieder mit dem propritärem Mist! Und das Tollste: Die aktuellen Konsolen profitieren direkt davon und somit praktisch auch der PC. Nur weiter so!

Das mit den " offenen Projekten " ist immer so eine Sache , wird es vom Markt angenommen oder nicht.
Welcher Entwickler soll sich jetzt das Risiko und die Mehrarbeit noch antun. Da muss meiner Meinung schon mehr kommen , als den Entwicklern einen riesen Brocken hinzuschmeissen
um dann zu sagen " jetzt macht mal ". Da muss von AMD finanzielle Unterstützung oder Manpower kommen.

Und da ich nicht glaube dass NVIDIA das übernimmt und in Anbetracht des 80% Marktanteils , bin ich der Meinung , dass die Entwickler NVIDIA`s Weg gehen werden.

Gameworks hätte sich genauso wenig durchgesetzt wenn NVIDIA keine Programmierer zu den Entwicklern geschickt hätte. Alles hat seinen Preis

Kerkilabro schrieb:

Warum aufeinmal diese Entwicklungen? Das muss doch einen Grund haben, da hat wohl irgendwer Schiss bekommen. Ich find´s prima Nur leider zu spät

Zum Vergrößern anklicken....

Mit der Idee hat AMD definitiv schon länger gespielt. Davon hab ich schon vor ungefähr anderthalb Jahren gehört, wenn ich mich nicht irre - damals noch Open Fx (oder so ähnlich) genannt. Die Idee finde ich ganz interessant, aber das kann nur funktionieren, wenn da auch entsprechend Engagement dahinter steht und das Ganze auch noch von Entwicklern akzeptiert, genutzt und verbessert wird - ansonsten stagniert's wahrscheinlich. Tress FX und HDAO gibt's immerhin auch als Source-Code, allzu viele Adaptionen habe ich aber noch nicht gesehen... aber vielleicht klappt's mit einer besseren Struktur dahinter.

Gruß,
Phil

Ich finde cool, dass von AMD seit letzter Zeit so viel neues bezüglich Software kommt. Es ist wichtig, dass Firmen nicht nur ein Stück Hardware sondern eine passende Arbeitsumgebung verkaufen. Vielleicht sogar ein Stück Lebensgefühl. Desshalb finde ich es sehr kritisch, dass AMDs Farbe Rot ist. Rot verbindet man sofort mit Hitze und Lautstärke, die Farbe Grün (Nvidia) eher mit Natur und Effizienz. Blau mit Kälte(Intel) und somit indirekt auch mit Effizienz. Wenn der Kunde eine Grafikkarte/Prozessor kauf, darf er nicht an Wärme/Lautstärke denken.

2fastHunter schrieb:

@ oldsql.Triso:
Du hast ja voll den Durchblick. Allein Deiner Logik nach würde Gamesworks von NVidia nicht benutzt werden. Zähl mal die Gameworks-Titel!

Zum Vergrößern anklicken....

Eben nicht. NV bliebt bei der Gameworks-Sache immer am Ball. Verbesserte es, lieferte fertige Sachen zum Implementieren, pushte es durch Werbung und und und... . Was macht AMD mit seinen meisten Ideen? Genau, kündigt das irgendwie so lala an, bringt es mit riesen Verspätung und lässt es dann krepieren....

Rot verbindet man sofort mit Hitze und Lautstärke

Zum Vergrößern anklicken....

Rot ist erstmal eine "Signalfarbe" und somit für uns alle deutlich Wahrnehmbarer als andere Farben. Daher wird die Farbe Rot auch an Ampeln oder Warntafeln verwendet weil wir dies auch unbewusst Wahrnehmen. Daher ist die Farbe Rot für AMD alles andere als schlecht

Und wer bei heutigen AMD Karten (vor allem bei Custom Modellen) gleich an Hitze denkt, der hat schlicht keine Ahnung.

PS:
AMD hatte auch eine Zeitlang die Farbe Grün

oldsql.Triso schrieb:

Totgeburt von AMD #4.

Zum Vergrößern anklicken....

Man möchte meinen, die Vergangenheit hat es ja gezeigt, aber die Initiative beherbergt neue Elemente, dass Spiel hat einen neuen Spin, eine neue Chance.

PS: Was war 1,2 und 3?

Die Entwickler haben ihre Tools und Plattformen, Bibliotheken und Assets. Kein cleverer Mensch macht eine Neuentwicklung damit, weil die Probleme damit nicht abgeschätzt werden können.

Zum Vergrößern anklicken....

Man kann die Probleme bei Open-Source nicht abschätzen?
Bei Projekten kann immer etwas schief gehen, aber AMD hat hier einfach ein offenes Glas aufgestellt und wer Lust hat, kann damit experimentieren und Dinge nach Lust und Laune einfügen.
Die Abschätzung hier ist total offen.

Vulkan ist schon die erste Nische die sicherlich kaum bedient wird.

Zum Vergrößern anklicken....

Nische ist so ein relaxter Begriff.
Ich sage nein zur Nische, die ich als kleine Randerscheinung definiere ohne nennenswerten Support.

Vulkan ist noch nicht draußen, aber die "Pläne", Achtung nichts davon ist bisher real, aber das trifft auf DX12 ebenso an vielen Stellen zu.
Vulkan ist die einzige low-overhead-api unter zukünftigen Android-Versionen, den Mobile-Space hat man insofern gesichert.
Valves kostenlose Source 2 Engine wird ebenso nur Vulkan als high-performance-api unterstützen, DX12 wird es nicht geben.
Die Unreal-Engine 4 wird Vulkan einbetten und damit hat man extrem viel potentiellen Boden gewonnen.
Star Citizen möchte Vulkan umsetzen.

Und einige Dinge mehr.
Sieht etwas mehr, als nach einer simplen Nische aus, jedenfalls nach meiner Definition.

Jetzt noch so ein Gedöns?
Das ist dass was mich an AMD auch nervt. Sie schaffen es nicht eine Sache konsequent durch zuziehen

Zum Vergrößern anklicken....

Welche Sache haben sie bisher nicht konsequent durchgezogen oder fallen gelassen (für eine andere?). (Mir fällt eine ein bzw. zwei.)
GPUOpen stellt eine konsequente Weiterentwicklung bisheriger Bemühungen dar.
In vielen Aspekten genauso wie GameWorks.

Viele Dinge die es früher schon gab, umgesetzt wurden oder als R&D Projekte vorgestellt, bekommen jetzt einfach einen übergreifenden Namen, für einen Software-Schirm.
Natürlich gibt es Weiterentwicklungen und neue Sachen.
Das ist jetzt eine mehr geordnete, übergreifende Initiative.

Kommt Gegenwind, drehen sich die Wendehälse wieder in die andere Richtung. Was machen, dazu stehen und entwickeln. Und nicht tausend Baustellen und nichts richtiges.

Zum Vergrößern anklicken....

AMD ist zu langsam, dass ist ein großes Problem und wo ich zustimmen würde, dass AMD teilweise zu fragmentiert arbeitet und vielleicht etwas fokussierter Projekte anpacken könnte.
Es ist aber wichtig, unter vielen Aspekten passende Angebote bereitzustellen.
Teilweise ist die Verdünnung von Ressourcen notwendig.

Und mit Portierungen zu werben ist immer ganz ganz heikel. Da passt dann meistens vorne und hinten nichts.

Zum Vergrößern anklicken....

Über welche Portierungen sprichst du hier?

Ursprünglich wollte ich mir eine nVidia-Grafikkarte holen, weil ich an GameWorks gedacht hatte. Wenn es nun aber "bald" eine "AMD-Version" davon gibt, die dazu auch noch quelloffen ist, bin ich eigtl. fast schon froh darüber, eine AMD-Karte zu besitzen. Und Vulcan ist sicherlich auch einer der Gründe, warum es letztlich "Team Rot" wurde.

Vulcan wird so ziemlich alle Rahmen sprengen. Man hat jetzt schon mit Mantle etwas bessere Performance, mit Vulcan wird das nochmal besser.
Und hier kann ich Locuza nur zustimmen:
Vulcan ist - im Gegensatz zu DX12 - noch nicht fertig/released und hat definitiv schon mehr "Zusagen" zur Implementierung als DX12.
Gibt es derzeit eigentlich überhaupt ein mehr oder weniger "bekannteres" Spiel, das DX12-Support anbietet? Ich kenne keins. Und dass, obwohl DX12 schon fast ein halbes Jahr "offiziell" released wurde.

Und gerade Microsoft zeigt uns doch gerade, dass das Öffnen des Quellcodes ein wichtiger (und auch der richtige) Schritt zur Entwicklung ist. Was gibt es besseres, als die Unterstützung der Community? Nicht nur, dass es unbezahlte Arbeitskräfte sind, in den Communities finden sich häufig auch talentierte Leute, die so ein Projekt ordentlich aufwerten könn(t)en.

Also: Hier wurde alles richtig gemacht AMD

@Locuza
Welche Sachen sie nicht konsequent durchziehen? Na da wäre VSR (Kompatibilität zu älteren Generationen und Funktion (jedenfalls bei mir)), Mantle, HSA, Vulkan, durchgängige Treiberupdatepolitik (auch in Sachen Linux) und Free-Sync (Wobei das gut gepusht wird, aber bei manchen Umsetzungsfragen fraglich ist.). Das würde mir da spontan einfallen. Natürlich ist es nicht immer alles ganz so einfach zu sehen, aber so ganz rund sind die guten Ansätze meist nie in der Durchführung.

Mit den Portierungen habe ich falsch gelesen auf anderen Seiten. Dachte das Assets/Bibliotheken quasi von DX11 bzw. 12 portiert werden können in GPUOpen.

Versteht mich nicht falsch, ich finde AMDs Sachen die sie teilweise vorstellen super, aber so richtig am Ball bleiben ist immer so eine Sache.

oldsql.Triso schrieb:

Eben nicht. NV bliebt bei der Gameworks-Sache immer am Ball. Verbesserte es, lieferte fertige Sachen zum Implementieren, pushte es durch Werbung und und und... . Was macht AMD mit seinen meisten Ideen? Genau, kündigt das irgendwie so lala an, bringt es mit riesen Verspätung und lässt es dann krepieren....

Zum Vergrößern anklicken....

AMD hat die gleichen Initiativen: Tomb Raider, BF, Civi. Um mal einige AAA-Titel zu nennen. Irgendwie kommt es mir so vor, als seine viele Nutzer auf einem Auge Blind.

oldsql.Triso schrieb:

@Locuza
Welche Sachen sie nicht konsequent durchziehen? Na da wäre VSR (Kompatibilität zu älteren Generationen und Funktion (jedenfalls bei mir)), Mantle, HSA, Vulkan, durchgängige Treiberupdatepolitik (auch in Sachen Linux) und Free-Sync (Wobei das gut gepusht wird, aber bei manchen Umsetzungsfragen fraglich ist.). Das würde mir da spontan einfallen. Natürlich ist es nicht immer alles ganz so einfach zu sehen, aber so ganz rund sind die guten Ansätze meist nie in der Durchführung.

Mit den Portierungen habe ich falsch gelesen auf anderen Seiten. Dachte das Assets/Bibliotheken quasi von DX11 bzw. 12 portiert werden können in GPUOpen.

Versteht mich nicht falsch, ich finde AMDs Sachen die sie teilweise vorstellen super, aber so richtig am Ball bleiben ist immer so eine Sache.

Zum Vergrößern anklicken....

Vulcan wird durchgezogen, allerdings von einer seperaten Workgroup, die auch hinter OpenGL steckt, wenn ich mich richtig erinnere. Und Vulcan basiert letztlich auf Mantle, da gibt es keinen Grund, Mantle selbst noch weiterzuführen.
Zu den anderen Dingen kann ich so nichts sagen, weil ich erst seit dem Wochenende eine AMD-Karte im aktiven Einsatz habe.

Welche Sachen sie nicht konsequent durchziehen? Na da wäre VSR (Kompatibilität zu älteren Generationen und Funktion (jedenfalls bei mir)), Mantle, HSA, Vulkan, durchgängige Treiberupdatepolitik (auch in Sachen Linux) und Free-Sync (Wobei das gut gepusht wird, aber bei manchen Umsetzungsfragen fraglich ist.). Das würde mir da spontan einfallen. Natürlich ist es nicht immer alles ganz so einfach zu sehen, aber so ganz rund sind die guten Ansätze meist nie in der Durchführung.

Zum Vergrößern anklicken....

Also selbst meine alte HD7870ghz unterstützt VSR. Zwar "nur" bis maximal 2560x1440 aber mehr schafft die Karte doch eh nicht...
Zu Mantle bzw Vulkan wurde ja bereits etwas geschrieben und FreeSync ist ja wohl seid dem letzten Update mindestens genau so Gut/schlecht wie Gsync.
Deutlich günstiger und auch noch Vesa Standard. Würde Nvidia mal den Kopf aus dem Hintern ziehen und ebenfalls auf den Vesa Standard setzen, hätten wir alle etwas davon. Adaptive Sync würde sich schneller ausbreiten und es würden deutlich mehr Monitore geben. Stattdessen setzt man auf ihr proprietäres Gsync das auf Adaptive Sync basiert um Kunden zu binden und denen unnötig Geld aus der Tasche zu ziehen...

Aber da auch Intel demnächst auf dem Zug von FreeSync (Adaptive Sync) aufspringt, dürfte die Zukunft für Gsync nicht Rosig aussehen

dbilas schrieb:

Aber da auch Intel demnächst auf dem Zug von FreeSync (Adaptive Sync) aufspringt, dürfte die Zukunft für Gsync nicht Rosig aussehen

Zum Vergrößern anklicken....

Da habe ich etwas nicht mitbekommen ... Sprich die Intel Grafikeinheiten der CPUs bekommen FreeSync-Unterstützung? Oder wie ist das gemeint?