News AMD veröffentlicht Stream SDK Beta v2.0 mit OpenCL Unterstützung

@Bobo_Oberon
Augen aufmachen! AMD hatte bereits Anfang August das erste SDK mit vollem Sprachumfang am Start. ...
Augen aufmachen: Unterstützt wurden anfangs nur AMDs PROZESSOREN, keine eigenen GPUs.
Das konnte erst die Stream SDK Beta Nr. 4, welche erst seit wenigen Tagen in der freien öffentlichen Entwickler-Wildnis genutzt werden kann.

Khronos.org bekam am 12. Mai 2009 die ersten offiziellen Nvidia-OpenCL Grafikkarten-Treiber zur Zertifizierung zu Gesicht, während AMD erst am 21. September ihren ersten offiziellen GPU-Treiber für die Multicore-API einreichten.
Erst mit Treibern ist überhaupt erst eine OpenCL-Nutzung gegeben und die SDKs kamen teilweise sogar noch später heraus.

Und wir sehen weiter, dass es eben mithin NICHT ausreicht eine SDK mit "vollem Sprachumfang" am Start zu haben, wenn die Entwicklersoftware nicht die Eigenheiten der eigenen GPU-Produkte kennt und es noch gar keine entsprechenden Grafikkartentreiber gab.

Mitglied Dr@ war so freundlich uns auf diese GPU-Unpässlichkeit der Stream SDK (im August 2009) hinzuweisen. Du siehst ... wir drehen uns im Kreis.

Und auch hier drehen wir uns im Kreis, weil auch das schon zwischen uns kontrovers diskutiert wurde.

MFG Bobo(2009)
 
Zuletzt bearbeitet:
Ähm... nur um dazu mal was loszuwerden... Kritik und Polemik sind zwei Paar Schuhe.
die Quintessenz aus der ganzen Diskussion hier ist doch dass 1. AMD an seinen Tools noch arbeiten muss, und IMHO gut daran täte das Entwicklerteam etwas zu vergrößern damit zukünftig sowas keine mittlere Ewigkeit dauert. (und dass sie in Sachen software verbeserungspotential haben, wollen wir doch nicht bestreiten, oder?)
und zweitens, dass OpenCL noch nicht der einzig seligmachende Messias und CUDA-Killer für AMD ist, wie man anfangs hätte vermuten können.
Für AMD ist OpenCL deutlich wichtiger als für Nvidia, da AMDs Stream-Technologie nicht so weit verbreitet ist wie CUDA. Was also bedeutet, AMD hat erst jetzt, mit OpenCL die chance Nvidias Dominanz im GPGPU-sektor massiv anzugreifen und sollte deswegen was OpenCL betrifft klotzen statt kleckern und massiv nachlegen!
Das mal als Zusammenfassung...
Puck hat es dahingehend auf dne Punkt gebracht, dass es im Moment für Entwickler z.B. von BOINC-clients noch keinen sinn macht auf OpenCL zu setzen. Abgesehen davon dass das bei Projekten die auf Double Precision-Berechnungen angewiesen sind, momentan noch gar nicht geht.

mfg.
Ge0rgy

P.S. Können wir es bitte seinlassen Kritiker beim ersten Argument das uns nicht in den Kram passt als Fanboys der anderen Seite abzustempeln? - danke.
 
Und jetzt mal eine vollkommen ernst gemeinte Frage. Was wollt ihr mit solcher Polemik hier eigentlich erreichen? Kommt ihr euch mit diesem Kindergarten Niveau nicht ein bisschen lächerlich vor? Toll, Unternehmen bringen SDKs zu unterschiedlichen Zeitpunkten heraus. Was für eine Überraschung. Neue Software Schnittstellen brauchen Zeit für ihre Reife. Wer hätte das gedacht. :]
Nehmt es mir nicht übel, aber was ihr hier veranstaltet braucht kein Mensch. Ich will so etwas nicht lesen. Und das trifft auf andere sicherlich genauso zu. Also überlegt es euch bitte, diesen Unsinn JETZT zu beenden oder hier weiter einen auf Polemiker zu machen.

Ich lese Polemik einzig und alleine von dir hier. Jeder, der sich deinem Lob nicht anschließt, wird niedergemacht. Erstmal an die eigene Nase fassen.
 
Ich lese Polemik einzig und alleine von dir hier. Jeder, der sich deinem Lob nicht anschließt, wird niedergemacht. Erstmal an die eigene Nase fassen.

Hier hat wohl jeder eine gewisse Schuld an der aktuellen Stimmung im Thread.
Also schaltet bitte einen Gang zurück und bleibt sachlich, sonst ist hier zu...
 
Augen aufmachen: Unterstützt wurden anfangs nur AMDs PROZESSOREN, keine eigenen GPUs.
Irgendwie hatte ich das geahnt. Du hast es leider immer noch nicht verstanden. Das ist für den Kontext jedenfalls erstmal VOLLKOMMEN IRRELEVANT. Das Thema hatten wir nun mehrere Seiten ausführlich besprochen. Bitte, tue mir den Gefallen und beschäftige dich erstmal mit der Standardisierung von Sprachspezifikationen. Du bringst immer wieder das gleiche Halbwissen und lernst nicht daraus, wenn man dir etwas sagt. So hat eine Diskussion absolut keinen Sinn.

Ich lese Polemik einzig und alleine von dir hier. Jeder, der sich deinem Lob nicht anschließt, wird niedergemacht. Erstmal an die eigene Nase fassen.
Tja, dann scheinst du absolut kein Textverständnis zu haben. Ich lobe hier gar nichts, weder von AMD noch von nVidia. Ich komme ja auch gar nicht dazu bei eurer permanenten Polemik. :]
 
Zuletzt bearbeitet:
Ich glaube wir reden alle aneinander vorbei...
gruffi redet von Sprachspezifikationen und Bobo_Oberon und ich beziehen uns speziell auf die momentane Version & Qualität von AMDY Stream SDK Beta 4.
Das sind zwei paar Schuhe.
OpenCL mag als Sprache ja toll sein und einwandfrei spezifiziert...
Das ändert aber nichts an der Tatsache dass es in der momentanten Implementation unattraktiv ist für Entwickelr z.b. für BOINC-Projekte um ihre Clients zu portieren, weil die bestehenden, nativen Implementationen deutlich schneller sind.
also haben alle irgendwie Recht, nur zu verschiedenen Themen... :)
Belasst es dabei und beruhigt euch wieder...

grüßchen
ich
 
Das ändert aber nichts an der Tatsache dass es in der momentanten Implementation unattraktiv ist für Entwickelr
Auch das stimmt so nicht. Das mag auf den einen oder anderen Fall sicherlich zutreffen, aber es ist nicht zu verallgemeinern. Hier bemessen zu viele der Hardware eine zu hohe Bedeutung bei. Softwareentwickler ticken aber auf einem anderen Level. Natürlich können Entwickler auch jetzt schon ihre Anwendung für OpenCL portieren oder neue für OpenCL designen. Ganz im Gegenteil, das jetzt zu tun, kann nur von Vorteil sein. Umso früher erkennt man, wo Fallstricke liegen und wo eventuell auch Änderungen an der Spezifikation notwendig sind.
 
Die Spezifikation ist doch final?
Selbst wenn sagen wir das Collatz Conjecture - Projekt nun feststellen würde dass OpenCL aktuell "suboptimal" ist, würde Khronos deswegen kaum die Spezifikation der Sprache ändern (und sämliche Entwickler womöglich zwingen nachzuziehen)
Es mag zwar korrekt sein dass Hardware nicht alles ist, aber gerade bei einem Feature wie OpenCL, dessen hauptsächlciher Zweck es ist, eine breitere Basis an (teilweise speziellerer und vor allem performanterer) Hardware möglichst einheitlich zugänglich zu machen, spielt die HW definitv eine Rolle.
Gerade für AMD, die sehr auf OpenCL gesetzt haben, ist es wichtig dessen Vorzüge schnellstmöglich sichtbar machen zu können, nur dann hat man ein Gegengewicht zu CUDA. Sowohl für BOINC, als auch für die Bullet-Portierung contra PhysX usw.
Wenn die HW und die Performance egal dabei ist, kann mans gleich in X86 Coden und auf der CPU laufen lassen.
Du magst zwar Recht haben damit dass es für Entwickler vorteilhaft sein kann sich mit der Materie vertraut zu machen... aber das konnten sie auch schon mit der OpenCL-Version für die CPU.
Einen Grund nun plötzlich alles was bisher auf CUDA lief auf OpenCL zu portieren um endlic hauch von der Power der Radeons profitieren zu können (und AMD verkäufe zu bringen) gibt es dennoch größtenteils noch nicht.
Also, ranklotzen AMD!
 
Die Spezifikation ist doch final?
Spezifikationen sind nie final. Sie entwickeln sich permanent weiter. Final kann maximal eine bestimmte Version der Spezifikation sein.

Selbst wenn sagen wir das Collatz Conjecture - Projekt nun feststellen würde dass OpenCL aktuell "suboptimal" ist, würde Khronos deswegen kaum die Spezifikation der Sprache ändern
Doch, genauso läuft das aber. An solch einer Spezifikation arbeiten viele verschiedene Unternehmen mit. Und hier werden auch weiterhin Vorschläge für Verbesserung eingereicht und verifiziert. Sollte etwas sinnvoll und realisierbar sein, wird es auch in einer zukünftigen Version enthalten sein.

Es mag zwar korrekt sein dass Hardware nicht alles ist, aber gerade bei einem Feature wie OpenCL, dessen hauptsächlciher Zweck es ist, eine breitere Basis an (teilweise speziellerer und vor allem performanterer) Hardware möglichst einheitlich zugänglich zu machen, spielt die HW definitv eine Rolle.
Grundsätzlich erstmal nicht. Genau deswegen hat man ja eine einheitliche Schnittstelle geschaffen.

Gerade für AMD, die sehr auf OpenCL gesetzt haben, ist es wichtig dessen Vorzüge schnellstmöglich sichtbar machen zu können, nur dann hat man ein Gegengewicht zu CUDA.
Nein. Das Gegenstück zu CUDA ist immer noch Stream. Und daran wird sich auch nichts ändern. OpenCL ist wieder eine ganz andere Baustelle und das sollte man auch nicht alles vermischen.

Wenn die HW und die Performance egal dabei ist, kann mans gleich in X86 Coden und auf der CPU laufen lassen.
Genau deswegen mahne ich immer an, dass hier zu viele Leute zu viel Halbwissen verbreiten wollen. Es geht bei OpenCL nicht um x86 bzw die Hardware ISA, es geht um die Spezifikation einer Hochsprachenerweiterung für parallele Aufgabenverteilung. DAS ist der Sinn und Zweck von OpenCL. Was dahinter steckt, scheinen zu viele Leute nicht zu verstehen.

Du magst zwar Recht haben damit dass es für Entwickler vorteilhaft sein kann sich mit der Materie vertraut zu machen... aber das konnten sie auch schon mit der OpenCL-Version für die CPU.
Genau das habe ich ja Bobo_Oberon auch versucht zu sagen. ;)

Ich empfinde das als sehr spezielle persönliche Auslegung, was "reizvoll" für Entwickler empfunden wird. Die Praxis zeigt, dass genau anders herum "Attraktivität" bewertet und entsprechend entwickelt wird.
Ich sage es gerne nochmal, da du dich nicht mit der Materie auskennst, kannst du es auch nicht beurteilen. Softwareentwicklung beinhaltet völlig pragmatische Entscheidungen. Solche blumigen und naiven Vorstellungen wie "Attraktivität" gibt es dabei nicht.

Später erschienene OpenCL-Grafiktreiber gehören sicher nicht dazu, ganz besonders früh Entwickler zu motivieren OpenCL für ATI GPUs zu programmieren ...
Was sollen denn "OpenCL-Grafiktreiber" sein? Ausserdem haben Treiber mit der Entwicklung selbst erstmal nichts zu tun. Wann lernst du es endlich, solche Polemik bleiben zu lassen? :]
 
Zurück
Oben Unten