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

GrooveXT schrieb:
Wenn sie jetzt noch ne OpenSource-Physikengine für GPUs bringen muss Nvidia sich schon verdammt viel einfallen lassen um ihre überteuerte Hardware zu verkaufen. Jetzt können sie sich noch hinter PhysiX und anderen Buzzwords verstecken, aber der Ast wird immer kürzer.

Wozu, es kommen ja jetzt sowieso physikbasierte Engine, welche PhysX obsolet macht. Aber wenn du sowas wünscht, kannst ja gern mal ein Branch machen und losprogrammieren :D

strex schrieb:
Den Cuda Konverter ist aber das schlechteste was angekündigt wurde. Alles andere kann nett werden, der Konverter ist aber nicht wirklich nutzbar. Wie AMD selbst schon angibt müssen 10% des Codes manuell aufwendig angepasst werden. Kostet also locker 10% und mehr an Arbeitszeit für jede einzelne Software die im HPC laufen soll. Und dann ist das noch nicht halbwegs optimiert. Sprich ich konvertiere mir mein optimiertes Cuda Programm, muss 10% ändern und dann nochmals aufwendig per Hand optimieren. Dafür kann ich mir viel Hardware von NV kaufen.

Das hatten wir schon mal. Die 10% sind wesentlich geringer, als dass die Entwickler eine komplett neue Sprache anlernen müssten. Außerdem gibt es eine Chance, dass sich eine relativ große Community aufbaut, die immer mehr Bibliotheken bereitstellt. Da das dann openSorce ist, hat AMD dadurch schon komplett andere Vorteile gegenüber deinen 10% Nachteilen. Da hat AMD mit GitHub schon den richtigen Schritt gemacht.
Fazit ist, die Barriere zum Umsteigen schwindet, speziell, falls man wirklich mit C++ programmieren kann.
 
Zuletzt bearbeitet:
Krautmaster schrieb:
Open Source ist ja nichts neues, und dennoch sind die meisten führenden Produkte nun mal nicht "Open Source".

Doch, sind sie eigentlich schon. Endnutzerprogramme sind selten open source, ja, aber alles, wo Entwickler ihre Finger im Spiel haben, ist eigentlich weitestgehend offen. Auch Sony hat zum Beispiel nen Haufen Änderungen fürs PS4 Compilen im normalen LLVM Upstream. Warum auch nicht? Heimlichtuerei mit Code bringt nicht allzu viel und sagt höchstens, dass du was zu verbergen hast. FOSS gewinnt auch ohne GPL schon.
 
joa ich bin zu wenig in dieser Ebene unterwegs um da jetzt wirklich reinzureden... das wäre (vermutet, korrigiert mich...) eher so als wenn Sony mit der PS4 ne Opensource Code Basis hierfür geschaffen hätte, wohl gemerkt dass es hier aber auch nur auf der Sony PS4 laufen muss / soll. Klar - wer da jetzt Games für die PS4 coden will, nur her mit dieser Plattform.
Der Gaming PC Markt besteht halt leider nicht nur aus AMD Karten. Ich zweifle ja weniger an der Sinnhaftigkeit oder an der Sache als solches, eher an der Chance die sich dem Entwickler offenbart bzw. dass diese das Langzeit Potential einer offenen Plattform (für alle GPU Typen) eröffnen würden. (dann müsste wohl Open Source Krams Windows und co längst abgelöst haben)

Wie gesagt, jetzt baut Nvidia noch das selbe in grün auf... (rein mal vorstellen), dann kann der Entwickler aus fertigen OpenSource Bausteinen ein und dasselbe Game aus AMD spezifischen OpenSource Code und Nvidia spezifischem Opensource Code aufbauen - oder alle Bausteine wieder nach DX12 portieren. Vielleicht denk ich da aber auch falsch. Klar können die fertigen Konstrukte über Vulkan, DX12 usw auch auf anderen Karten laufen, man muss aber aufpassen dass es am Ende wie gesagt nicht mehr Aufwand ist als heute ;)
 
Zuletzt bearbeitet:
pipip schrieb:
Das hatten wir schon mal. Die 10% sind wesentlich geringer, als dass die Entwickler eine komplett neue Sprache anlernen müssten.

Das ist und bleibt aber kompletter Humbug und hat erst einmal nichts mit der Sprache selbst zu tun. Aber scheinbar ist dir das noch immer nicht klar. Arbeitszeit bleibt es trotzdem und somit dementsprechend sind die Kosten weit größer. 10% sind bei 10 Zeilen zwar wenig, aber wenn das Programm einmal aus 50.000 und mehr besteht doch signifikant. Dann heißt es natürlich nicht, dass ich da nur eine Funktion austauschen muss sondern dann fängt das Debugging erst richtig an. Ich muss bei diesen 10% erst analysieren was gemacht werden muss, damit der Cuda Code in OpenCL läuft und das dann entsprechend anpassen. Dann muss ich nicht nur Cuda können sondern auch den Unterbau von OpenCL. Das werden natürlich dann nicht die einfach Stellenen im Code sein, sondern die welche der Konverter überhaupt nichts anfangen kann. Entsprechend komplex wird die Anpassung bei diesen Stellen.

pipip schrieb:
Außerdem gibt es eine Chance, dass sich eine relativ große Community aufbaut, die immer mehr Bibliotheken bereitstellt. Da das dann openSorce ist, hat AMD dadurch schon komplett andere Vorteile gegenüber deinen 10% Nachteilen.

Was sollen die die Community da machen? Im HPC Markt wo viel Software per Hand extra optimiert und geschrieben wurde und viele die Software auch nur intern handhaben dürfen? Das sind ja nicht immer dieselben Programme. Es sind unendlich möglich Kombination an Code und Algorithmen möglich. Dazu müsste die Community unendlich Menge an Workarounds zur Verfügung stellen. Zweitens sind das oft Programm die nicht veröffentlich werden, was soll die Community denn machen, wenn man kein Code nach außen tragen darf. Richtig, wieder selbst 10% Code anpassen. Wie man sieht lässt sich das nicht über die Community lösen.

pipip schrieb:
Fazit ist, die Barriere zum Umsteigen schwindet, speziell, falls man wirklich mit C++ programmieren kann.

Dein Fazit ist jetzt wie auch vorher falsch. Es geht nämlich in diesem Fall nicht um die Sprache sondern die 10% Code welcher angepasst werden muss und das von Hand. Das sind Mannstunden die bezahlt werden möchten. Die Leute sind ja schon da, entsprechende Umschulung ziemlich teuer. Dafür kann ich weit mehr Hardware kaufen als das ich Kosten sparen täte durch die Verwendung einer günstigeren AMD Lösung. Dein Fazit würde nur Sinn machen, wenn jetzt alle anfangen statt Cuda etwas anderes zu programmieren oder alle Cuda Entwickler zu entlassen. Das wird aber nicht der Fall sein, denn die Leute sind ja schon da die Programme schreiben und haben eine entsprechende Expertise in Cuda. Die müssten so ja jeweils 10% mehr Arbeiten, weil der Cuda Code nach der Programmierung erst angepasst werden muss.

Der rechtliche Aspekt ist bis dato immer noch nicht geklärt. Da ist auch Google mit dem Nachbau ordentlich auf die Fresse gefallen. Bestätigt sich das, hat man eine schöne Grundsatzentscheidung die NV nur aufgreifen muss. Mit den anfallenden Kosten kann AMD, mit den begrenzt zur Verfügung stehenden Mitteln, ordentlich auf die Fresse fallen. US Gerichte sind ja da nicht sonderlich zimperlich.


AMD ist jetzt in der Position wo Intel mit 64 Bit war. Zu spät am Markt, wo bereits eine breite Durchdringung des Marktes vorhanden war. Den Ausgang haben wir auch gesehen, mit der Übernahme der AMD64 Lösung. Intel hätte da auch schön etwas basteln können mit viel Aufwand, um ein Kapsel um die eigene Lösung zu bauen. Das hat man aber nicht gemacht, weil das nur Nachteil mit sich bringt und schließlich zum scheitern verurteilt ist.

Zehkul schrieb:
Warum auch nicht? Heimlichtuerei mit Code bringt nicht allzu viel und sagt höchstens, dass du was zu verbergen hast. FOSS gewinnt auch ohne GPL schon.

Dann stell dir mal vor BMW oder ein anderer stellt seine Software zur Berechnung der Strömungen und co. als Open Source zur Verfügung. Das geschieht nicht, denn das kann der Wettbewerbsvorteil sein. Die Investieren ja kein Millionen in die Entwicklung um sie der Konkurrenz zur Verfügung zu stellen. Und genau solche Software findet man auch im HPC Bereich. Sony stellt die zur Verfügung da sie keinerlei Wettbewerbsvorteil für andere hat. Die wird nur zur Verfügung gestellt, um den Entwicklern auf der PS4 zu unterstützen, was wiederum eine höhere Anzahl an Spiele bedeuten kann. Das wiederum steigert den Verkauf auf dem Markt den Sony bearbeitet. Auch AMD stellt die Software zur Verfügung, um die eigenen Verkäufe zu erhöhen und nicht damit das die Konkurrenten weniger arbeiten müssen. Wäre ja ganz schön blöd.
 
Zuletzt bearbeitet:
auch die Community muss man managen, schnell hat man da Wildwuchs der in Chaos endet ;) persönliche Erfahrung. Community ist erstmal gut und kann auch funktionieren, zb Kodi is n super Projekt das ich auch gern wieder durchbauen lasse und auf Github gehostet is.

Wie sich das in diesem GPU Segment behaupten kann... wird sich zeigen müssen. Das fällt oft mit der Akzeptanz und der Einsicht das sich der Mehraufwand erst spät und bei anderen/folgenden Projekten auszahlen kann, andernfalls hat man den Mehraufwand in Form von Barem in den Sand gesetzt.

Cyanogenmod wäre auch so ein positives Beispiel, auch wenn ich wieder zurück auf Stock bin ;)
 
Zuletzt bearbeitet:
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.
 
Kasmopaya schrieb:
Leicht spät wenn du mich fragst. Für mich war der Drops gelutscht bei Gothic II 2001. Während NV User das Game super zocken konnten mit theoretisch weniger GPU Power unter dem Hintern(GF5), war bei AMD teils gar kein spielen möglich mit der brand neuen legendären 9700Pro.

Schon eigenartig das ausgerechnet die Serie die sonst im direkten Vergleich eher ein Rohrkrepierer war auf einmal so gut sein soll.
Noch verwunderlicher ist aber wie du 2001 mit einer Karte getestet haben willst die erst Ende 2002 erschien. Vielleicht lief sie ja deshalb so schlecht. Aber wie will dann ne Karte der Geforce FX Serie laufen die erst 2003 raus kam? Warum vergleichst du mit der 9700 obwohl 2003 bereits die 9800er Modelle raus waren?
Und was für Modelle vergleichst du überhaupt?
Fragen über Fragen.


Zum Thema:
Eine erfreuliche Entwicklung die die GPU Sparte von AMD vollzieht.
Wie lange wird es wohl dauern bis jemand auf die Idee Kommt das Physx mal durch den Compiler zu jagen? Wenn ich mich recht erinnere baut das doch auch auf Cuda auf.

Edit:
Wo ich mal auf der erfolglosen Suche zu Gothic 2 Benchmarks war...lustig...dafür gibt es nen DX11 Mod:
http://www.pcgameshardware.de/Gothic-2-Spiel-4360/Tests/Tuning-per-Mod-1157495/
 
Zuletzt bearbeitet von einem Moderator:
Manmanman mir gefällt diese Entwicklung, die AMD seit der Gründung der Radeon Technologies Group macht, sehr gut ;)
Ich freue mich auf DX12 und neue 14/16nm GPUs.
 
Dai6oro schrieb:
Was der Entwickler möchte ist dass man ihm den Bauch pinselt am besten noch vollen Support für diverse Grafikeffekte möglichst billig. Und genau deswegen wird diese Initiative scheitern auch wenn ich gerne das Gegenteil sehen würde. Solange Mehraufwand vom Kunden nicht honoriert wird, wird sich daran auch nichts ändern.

Ja bei spielen werden wir sehen, die Innitiative richtet sich aber soweit ich das verstehe nicht nur an Spieleentwickler, und gpucpu oder wie die sparte heisst ist ja gerade ausserhalb von spielen wichtig.


strex schrieb:
Den Cuda Konverter ist aber das schlechteste was angekündigt wurde. Alles andere kann nett werden, der Konverter ist aber nicht wirklich nutzbar. Wie AMD selbst schon angibt müssen 10% des Codes manuell aufwendig angepasst werden. Kostet also locker 10% und mehr an Arbeitszeit für jede einzelne Software die im HPC laufen soll.

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.

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.

Die vorteile von der direkten C++ entwicklung sind natuerlich gross, und dann mildert man eben die Nachteile auch ab, waer besser wenn man die Nachteile ganz auf heben koennte aber fuer den einen oder anderen duerften daher die Vorteile uebewiegen.

Zum generell zeitaufwendigeren Coden in Cuda statt in C++ kommt wie schon gesagt noch dazu das das mehr Leute schon koennen, daher kann man ihnen logischerweise auch weniger bezahlen wie leuten mit seltenem spezialwissen.
 
Seitdem es die Radeon Technologie Group gibt, gehts ja bei AMD in der GPU Richtung richtig ab.
Kann man nur begrüßen und diese News hört sich auch mehr als Vielversprechend an!
Go AMD drückt es durch :)
 
Ohne groß zu schwafeln: Sehr schön, AMD. :daumen:
Finde ich doch sehr interessant zu lesen. Bin schon gespannt, wie es dann tatsächlich wird.
 
karamba schrieb:
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.

Du vergisst die Konsolen. Aufgrund der verhältnismäßig geringen Hardwareleistung der Konsolen wird da sehr stark optimiert. Die bisherigen Schnittstellen (DX11, OpenGL4) haben aber bisher größten Teils verhindert dass viele dieser Optimierungen auf den PC übernommen werden konnten, weil sie keinen vergleichbaren Low-Level Zugriff erlaubten. Mit DX12 und noch mehr mit den neuen Tools wird man diese Optimerungen hingegen auch auf dem PC nutzen können, evtl. kann man sie sogar teilweise 1 zu 1 von den Konsolen übernehmen.


karamba schrieb:
Dein Fazit würde nur Sinn machen, wenn jetzt alle anfangen statt Cuda etwas anderes zu programmieren
Genau das ist wohl das Ziel, dass AMD verfolgt. Bisher war es so, dass die Zeit und Kosten für die Neuimplementierung bestehenden Codes viele davon abgehalten hat von Cuda auf z.B. OpenCL zu wechseln. Wenn diese Kosten nun um 90% reduziert werden, werden sich viele sicherlich nochmal überlegen ob der Umstieg auf einen Industrie-Standard mit deutlich mehr Hardware-Auswahl nicht den Aufwand wert ist.

karamba schrieb:
oder alle Cuda Entwickler zu entlassen.
Man muss es ja nicht gleich übertreiben. Wer Cuda beherrscht kann auch relativ schnell OpenCL lernen.

karamba schrieb:
Die müssten so ja jeweils 10% mehr Arbeiten, weil der Cuda Code nach der Programmierung erst angepasst werden muss.
Das ist in der Tat vollkommen unsinnig, aber wieso sollte man, nachdem man den bestehen Cuda-Code konvertiert hat, anschließend in Cuda weiterentwickeln? Natürlich würde man anschließend in OpenCL oder C(++) weiterentwickeln.

karamba schrieb:
Der rechtliche Aspekt ist bis dato immer noch nicht geklärt. Da ist auch Google mit dem Nachbau ordentlich auf die Fresse gefallen.
Wovon redest du? Meinst du etwa Davik? Das ist nämlich ein ganz anderer Sachverhalt. Google hat dabei die Java-API in Teilen 1 zu 1 nachgebaut. In Europa wäre das afaik kein Problem, in den USA evtl. schon. Vergleichbar ist die Situation eher mit der von Transmeta. Deren CPUs haben x86-Befehle in einen eigenen Befehlssatz "übersetzt" und anschließend abgearbeitet. Dafür haben sie keine x86-Lizenz gebraucht.

karamba schrieb:
AMD ist jetzt in der Position wo Intel mit 64 Bit war. Zu spät am Markt, wo bereits eine breite Durchdringung des Marktes vorhanden war. Den Ausgang haben wir auch gesehen, mit der Übernahme der AMD64 Lösung. Intel hätte da auch schön etwas basteln können mit viel Aufwand, um ein Kapsel um die eigene Lösung zu bauen. Das hat man aber nicht gemacht, weil das nur Nachteil mit sich bringt und schließlich zum scheitern verurteilt ist.
Die Situation ist nicht vergleichbar. Intel hatte bereits vor AMD einen 64-Bit Befehlssatz, nämlich den, der beim Itanium eingesetzt wurde. Der Grund, warum der sich nicht durchgesetzt hat war die mangelnde Abwärtskompatibilität auf die vor allem Microsoft viel Wert legte. AMD hatte genau das im Angebot und MS hat deutlich gemacht, dass sie keine andere 64-Bit x86 Erweiterung unterstützen würde. Damit war die Sache für Intel erledigt, denn MS saß in dem Fall am längeren Hebel, selbst gegenüber Intel.
 
strex schrieb:
Dann stell dir mal vor BMW oder ein anderer stellt seine Software zur Berechnung der Strömungen und co. als Open Source zur Verfügung. Das geschieht nicht, denn das kann der Wettbewerbsvorteil sein. Die Investieren ja kein Millionen in die Entwicklung um sie der Konkurrenz zur Verfügung zu stellen. Und genau solche Software findet man auch im HPC Bereich.

Natürlich ist Software selten FOSS, die selbst als Produkt vermarktet wird. Das ist aber abgesehen von einigen speziellen Bereichen wirklich selten der Fall. Auch Spiele profitieren eigentlich nicht unbedingt viel davon, die Konkurrenz, die die Engine schon geschrieben hat, von der eigenen Engine fernzuhalten. Verkauft werden am Ende ja die Assets. Ich wünschte, da würde man weniger wie Gollum über dem eigenen Schatz sitzen … Und es gibt ja auch immer wieder Engines, die geöffnet werden. Kein einziges Mal hatte je ein direkter Konkurrent irgendeinen bedeutenden Vorteil dadurch.

strex schrieb:
Sony stellt die zur Verfügung da sie keinerlei Wettbewerbsvorteil für andere hat. Die wird nur zur Verfügung gestellt, um den Entwicklern auf der PS4 zu unterstützen, was wiederum eine höhere Anzahl an Spiele bedeuten kann.

Und weil Code Upstream haben auch weniger Merge Aufwand bedeutet.

karamba schrieb:
Grundsätzlich keine schlechte Sache, gerade weil OpenSource. Aber kein Entwickler macht sich den Aufwand, direkt auf die Hardware zuzugreifen.

Stimmt nicht, eine Menge Hobbybastler und auch Profis, die ihre eigene Engine mehr aus Spaß schmeißen (denn seien wir ehrlich, heutzutage ist einfach Unity nehmen in 99% aller Fälle billiger und Updates kriegt man auch noch frei Haus), haben sehr viel Interesse daran. Und das sind im Zweifelsfall auch die, die mal hier und dort etwas open sourcen. (Godot Engine wäre da das neueste Beispiel, oder gleich FOSS Projekte wie Open Scene Graph, bgfx, …)

Und die großen Engines selbst haben jedes Interesse daran, den Treiber möglichst zu umgehen. Je komplizierter, je mehr Vorteil man gegenüber Heimbau Engines hat, desto besser.

zeedy schrieb:
Manmanman mir gefällt diese Entwicklung, die AMD seit der Gründung der Radeon Technologies Group macht, sehr gut ;)

Das alles ist schon deutlich länger in Planung als es die RTG gibt. Der Beschluss, geschlossene Treiber unter Linux vollkommen hinter sich zu lassen, ist nun bald 2 Jahre alt, und schon davor hat AMD lange Stück für Stück an Linuxtreibern gebastelt.
 
Zuletzt bearbeitet:
im PC-Spiele Bereich erwarte ich hier leider keinen Vorteil daraus. Als Engine-Enwickler schaue ich darauf, wie viele NV / AMD Karten bei den Kunden installiert sind und priorisiere dementsprechend meine Optimierungen. Und hier siehts für AMD im PC-Bereich leider schlecht aus.
Um den Low-Level Zugriff der jetzt ermöglicht wird auch effektiv Nutzen zu können müßte man prinzipiell einen eigenen Renderpfad nur für GCN implementieren, und das sehe ich nicht kommen.
 
Wer entwickelt denn Engines rein für den PC?
Die meisten Engines dürften für Multi Plattform ausgelegt werden und entsprechend "offen" gestaltet werden.
Engines wie von StarCraft 2 sind eher CPU als GPU lastig.

Zumal man als vernünftiger Entwickler nicht unbedingt ca. 1/4 des PC GPU Marktes links liegen lassen sollte, und quasi 100% des Konsolenmarktes, wenn dann auch noch Nintendos nächste Konsole auf AMD Hardware setzen sollte.
 
Zehkul schrieb:
Und was soll das bringen? Der Code läuft doch so schon auf Nvidia Karten.

Gut, sagen wir "optimieren"

Zehkul schrieb:
Du machst deinem Namen alle Ehre, von open source verstehst du nix. :)

Das sagt jemand mit einem Satz, der implizit Windows und Open Source gegenseitig ausschließt? Selten so gelacht.

berkeley schrieb:
Naja, wirklich fun ist das nicht. Es handelt sich ausschließlich um den ineffizienten CPU Teil von PhysX und dieser darf dann auch nicht z. B. lizenzfrei in den Konsolen verwendet werden (nur Win, Android, Linux, OsX). Dabei ist der CPU Part aber nicht "Open Source" sondern nur der Source Code wurde veröffentlicht und darf im bestimmten Rahmen verwendet werden (nach Nvidias EULA).

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.
 
Zuletzt bearbeitet:
Unter den Rahmenbedingungen, unter die nvidia ihren CPU PhysX Part "Open Source" gestellt hat, kann auch kein Konkurrent, weder AMD noch Intel, CPU PhysX erweitern und sinnvoll nutzen, weil nvidia sich das Recht beibehält auszuwählen wer eine Lizenz erhält und Erweiterungen des Codes bedeuten Eigentum von nvidia. Sprich jeder Dritte der Code einreicht tritt damit seine Arbeit an nvidia ab.
Auf deutsch: Ihr arbeitet nach Erlaubnis an CPU PhysX Optimierungen, nvidia kriegt diese für lau und ihr habt keine Rechte...

Das da sich keiner drauf stürzt oh Wunder oh Wunder
 
Haldi schrieb:
Also der Heterogeneous Compute Compiler-Compiler? :freak:

Das ist so ähnlich wie mit dem PDF-Format. ;)

... ansonten finde ich das löblich von AMD, dass sie mal eine brauchbare Initiative auch vermarktungstechnisch Begleiten.
Bisher haben sie halt immer so ein technisches Programm aufgelegt, und sind dann so nach dem Moto verfahren "Da habt ihr's und jetzt macht was draus. ... und fragt bloß nicht nach, das müsst ihr schon alleine machen"
... und da hatten dann halt nicht so viele Bock drauf.

Na mal gucken was daraus wird. AMD kann ja Erfolge gut brauchen.
 
Unnu schrieb:
und fragt bloß nicht nach, das müsst ihr schon alleine machen".
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.
 
Zurück
Oben