News AMD veröffentlicht Stream SDK Beta v2.0 mit OpenCL Unterstützung
- Ersteller Opteron
- Erstellt am
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Naja, das muss man qualitativ entscheiden, nicht quantitativ.
Wenn man "viele" Threads, also parallelen Code hat -> GPU, wenn seriell und nur 1-2 Threads, dann CPU. Z.B. optimal für ne ne master/worker thread architektur, ähnlich wie bei Cell. Da verwaltet/füttert ja auch ein Power Kern die 8 SPUs bzw. rechnet deren Einzelergebnisse zusammen.
Wobei die Frage ist, ob man dazu OpenCL braucht, oder dazu nicht einfach ein Stück x86 Fertigcompilat mitlaufen läßt.
ciao
Alex
Wenn man "viele" Threads, also parallelen Code hat -> GPU, wenn seriell und nur 1-2 Threads, dann CPU. Z.B. optimal für ne ne master/worker thread architektur, ähnlich wie bei Cell. Da verwaltet/füttert ja auch ein Power Kern die 8 SPUs bzw. rechnet deren Einzelergebnisse zusammen.
Wobei die Frage ist, ob man dazu OpenCL braucht, oder dazu nicht einfach ein Stück x86 Fertigcompilat mitlaufen läßt.
ciao
Alex
Zuletzt bearbeitet:
Bobo_Oberon
Grand Admiral Special
- Mitglied seit
- 18.01.2007
- Beiträge
- 5.045
- Renomée
- 190
Da kann man nur hoffen, dass die Switch-Kriterien ausreichen und dass der Programmierer seinen Code tatsächlich so feinteilig einteilt, dass damit die verschiedenen Stärken von Architekturen auch ausgenutzt werden.
MFG Bobo(2009)
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
PuckPoltergeist
Grand Admiral Special
Beta4 vom Stream SDK ist raus:
http://developer.amd.com/GPU/ATISTREAMSDKBETAPROGRAM/Pages/default.aspx
die Neuigkeiten:
http://developer.amd.com/GPU/ATISTREAMSDKBETAPROGRAM/Pages/default.aspx
die Neuigkeiten:
- First beta release of ATI Stream SDK with OpenCL™ GPU support.
- ATI Stream SDK v2.0 OpenCL™ is certified OpenCL™ 1.0 conformant by Khronos.
- Added Microsoft® Windows® 7 support.
- Added native Microsoft® Windows® 64-bit support.
- Float comparisons in kernels no longer produce a runtime error.
- Various other issues from previous v2.0 beta releases have been resolved
Dr@
Grand Admiral Special
keine Ahnung obs schon gefixt ist, aber scheinbar hat die aktuell runterladbare Version für Windows XP einen Fehler (falsche md5sum).
Für interessierte gibts hier die richtige Version.
Thread im AMD Developer Forum
MfG @
Edit:
Der Fehler ist behoben:
Für interessierte gibts hier die richtige Version.
Thread im AMD Developer Forum
MfG @
Edit:
Der Fehler ist behoben:
QuelleDriver update: Just got word from the web team in India that it's all up again! (thank goodness!) Test downloaded them just to be sure and got all 3 on my home machine AND the XP drivers are all good as well this time!
Sorry for the delay! Just happened to hit the particular time when my key folks are out and I had to wait for the folks in India to get to the fix.
Carry on as you were...
Michael.
Zuletzt bearbeitet:
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Aktuelle OpenCL Problemchen:
Beta4, GPU performance is like "ultra slow"
Any ideas when image support will be available ?
Sieht so aus, als wäre der kohärente Modus von Fermi nicht das schlechteste für OpenCL ...
Beta4, GPU performance is like "ultra slow"
Any ideas when image support will be available ?
Sieht so aus, als wäre der kohärente Modus von Fermi nicht das schlechteste für OpenCL ...
Bobo_Oberon
Grand Admiral Special
- Mitglied seit
- 18.01.2007
- Beiträge
- 5.045
- Renomée
- 190
Wenn ich die Forendiskussion bei Developer AMD betrachte und die Aussage von Mitglied Gruffi in der Seitenzweigdiskussion "News NVIDIA: DirectX 11 ist nicht so wichtig" im Posting#75:
Von "uneingeschränkt" kann hier eben nicht die Rede sein. Da muss zur Zeit bei den ATI-Karten tapfer immer vom Hauptspeicher zugegriffen werden, während offenbar Nvidia auch die Texturspeicher der Karte als Zwischenspeicher für GPGPU-Computing (unter OpenCL wohlgemerkt) nutzt.
Ach und noch was. OpenCL erst ab der ATI 7xx-Serie. Bei Nvidia gehts seit der ersten eigenen DirectX-10 GPU.
Wie gesagt, unter "Vollständigkeit der eigenen OpenCL SDK" verstehe ich da etwas anderes, auch wenn die Syntax vollständig verstanden wird.
Da gehört auch dazu, dass je nach Anwendung mal der globale Speicher, als auch der schnelle Texturspeicher auf der Karte genutzt wird ... und ja, das ist eine auf Hardware fixierte Sichtweise. Das ist ja der Grund aktuelle Chips auf dem neusten Stand zu entwickeln und zu verkaufen.
Das nutzt aber alles nichts, wenn die Treiber, eigene SDK die Produkte halbherzig unterstützen.
Die Worte sind zwar von mir harsch gewählt, weil OpenCL ein Pointer basiertes Modell nutzt, wo der Texturspeicher der Grafikkarte nicht (so ohne weiteres aktuell bei ATI) nutzbar ist.
Mir scheint, dass der Hype um OpenCL zu früh ist, als dass die vorherigen Methoden mit CAL und Brook+ (Streaming) und PTX & CUDA schnell verdrängt werden.
MFG Bobo(2009)
dann sehe ich meine Vermutung bestätigt, dass es doch Unterschiede zu beachten gibt, wenn man auf ATI- oder Nvidia-GPUs für OpenCL programmiert.
Von "uneingeschränkt" kann hier eben nicht die Rede sein. Da muss zur Zeit bei den ATI-Karten tapfer immer vom Hauptspeicher zugegriffen werden, während offenbar Nvidia auch die Texturspeicher der Karte als Zwischenspeicher für GPGPU-Computing (unter OpenCL wohlgemerkt) nutzt.
Ach und noch was. OpenCL erst ab der ATI 7xx-Serie. Bei Nvidia gehts seit der ersten eigenen DirectX-10 GPU.
Wie gesagt, unter "Vollständigkeit der eigenen OpenCL SDK" verstehe ich da etwas anderes, auch wenn die Syntax vollständig verstanden wird.
Da gehört auch dazu, dass je nach Anwendung mal der globale Speicher, als auch der schnelle Texturspeicher auf der Karte genutzt wird ... und ja, das ist eine auf Hardware fixierte Sichtweise. Das ist ja der Grund aktuelle Chips auf dem neusten Stand zu entwickeln und zu verkaufen.
Das nutzt aber alles nichts, wenn die Treiber, eigene SDK die Produkte halbherzig unterstützen.
Die Worte sind zwar von mir harsch gewählt, weil OpenCL ein Pointer basiertes Modell nutzt, wo der Texturspeicher der Grafikkarte nicht (so ohne weiteres aktuell bei ATI) nutzbar ist.
Mir scheint, dass der Hype um OpenCL zu früh ist, als dass die vorherigen Methoden mit CAL und Brook+ (Streaming) und PTX & CUDA schnell verdrängt werden.
MFG Bobo(2009)
Zuletzt bearbeitet:
Das mit dem Speicher ist aber eigentlich ein Hardwareproblem, und keines von OpenCL.
OpenCL kann auch auf CPU laufen, dann ist der Speicherzugriff kein Thema, und wenn man GPU-Designs wie Fermi anschaut, zeigt sich dass es auch machbar ist eine GPU so zu bauen dass das kein Drama ist. Das ist aktuell eher eine Limitierung der Hardware. Es ist zwar richtig dass das Ponter-Basierte Modell für streaming-Engines, wie es GPUs nunmal per Definition sind, suboptimal ist, aber OpenCL ist ja auch nicht nur für Grafikkarten entwickelt worden sondern allgemein für Parallelrechner (Cell zum Beispiel). Dass die Grakas in dieser Form da eine sehr eingeschränkte Form von Parallelrechner darstellen bzw. von der Art her auf diesem Wege nicht effizient ausgenutzt werden können ist kein Problem von OpenCL an sich. Zumal ja auch diverse Möglichkeiten im Developer-forum genannt wurden diesen Sachverhalt zu verbessern, mit const z.b. zu arbeiten etc. Möglicherweise muss da noch etwas tuning am Compiler geleistet werden. Einen effizienten, optimierenden Compiler zu bauen ist schließlich nicht mal eben eine Fleißarbeit für die Mittagspause.
Das Problem bei OpenCL ist schlicht, dass es zu viele Plattformen über einen Kamm zu scheren versucht, und es ist nunmal ein unterschied zwischen x86-CPU, Cell und Grafikkarte, auch wenn sich alle zum rechnen eignen und mehr oder weniger parallel arbeiten können.
Ich denke im laufe der Zeit wird sich das aufeinander zubewegen, die GPUs werden "CPUiger" und die OpenCL-Implementationen werden von den Herstellern besser auf Ihre Grakas und deren Eigenheiten optimiert werden. Es hat doch auch niemand ernsthaft angenommen dass OpenCL mal eben so über ancht zur Lösung all unser Rechenprobleme avanciert, oder?
OpenCL kann auch auf CPU laufen, dann ist der Speicherzugriff kein Thema, und wenn man GPU-Designs wie Fermi anschaut, zeigt sich dass es auch machbar ist eine GPU so zu bauen dass das kein Drama ist. Das ist aktuell eher eine Limitierung der Hardware. Es ist zwar richtig dass das Ponter-Basierte Modell für streaming-Engines, wie es GPUs nunmal per Definition sind, suboptimal ist, aber OpenCL ist ja auch nicht nur für Grafikkarten entwickelt worden sondern allgemein für Parallelrechner (Cell zum Beispiel). Dass die Grakas in dieser Form da eine sehr eingeschränkte Form von Parallelrechner darstellen bzw. von der Art her auf diesem Wege nicht effizient ausgenutzt werden können ist kein Problem von OpenCL an sich. Zumal ja auch diverse Möglichkeiten im Developer-forum genannt wurden diesen Sachverhalt zu verbessern, mit const z.b. zu arbeiten etc. Möglicherweise muss da noch etwas tuning am Compiler geleistet werden. Einen effizienten, optimierenden Compiler zu bauen ist schließlich nicht mal eben eine Fleißarbeit für die Mittagspause.
Das Problem bei OpenCL ist schlicht, dass es zu viele Plattformen über einen Kamm zu scheren versucht, und es ist nunmal ein unterschied zwischen x86-CPU, Cell und Grafikkarte, auch wenn sich alle zum rechnen eignen und mehr oder weniger parallel arbeiten können.
Ich denke im laufe der Zeit wird sich das aufeinander zubewegen, die GPUs werden "CPUiger" und die OpenCL-Implementationen werden von den Herstellern besser auf Ihre Grakas und deren Eigenheiten optimiert werden. Es hat doch auch niemand ernsthaft angenommen dass OpenCL mal eben so über ancht zur Lösung all unser Rechenprobleme avanciert, oder?
Bobo_Oberon
Grand Admiral Special
- Mitglied seit
- 18.01.2007
- Beiträge
- 5.045
- Renomée
- 190
Dann schau dir mal das positive Meinungsbild über OpenCL auf ATI-Karten im P3D-Forum an ... das passt zur Zeit (Stand Mitte Oktober 2009) hinten und vorne nicht zusammen.
Es ist irgendwie bezeichnend, dass AMD eine Physik-Engine wie Bullet unter OpenCL zum Start der ersten DirectX-11 ATI-Karten erwähnt ... aber die Entwickler dieser PPU-Engine zur Zeit nur mit Nvidia-Systemen unter OpenCL daran entwickelt haben.
Immerhin, NUN gibt es offenbar in der eigenen Beta Nr. 4 ATI Stream SDK* Unterstützung für eigene GPUs ... und nicht nur CPUs
MFG Bobo(2009)
* = Ursprünglich eine Entwicklerumgebung für eigene Grafikchipprodukte für CAL und Brook+
Zuletzt bearbeitet:
Ist mir schon bewusst... und auch irgendwie pervers, ich frage mich nur, was soll der ganze Zirkus?
Wenn Radeons für OpenCL suboptimal sind, wegen nicht-kohärentem Speichersystem dann hätte ATI das doch vorher wissen müssen... also wieso konzentrieren die sich derartig auf OpenCL, wenn sie genau wissen dass ihre eigene HW dafür unpraktisch ist?
Damit treibt man die Kundschaft ja noch mehr in die Hände von nvidia...!?
Angenommen Fermi rockt total ab bei OpenCL-Apps wegen sauberer pointerverwaltung, kohärentem, gecachetem Speicher etc. Dann wäre alles was AMD nun mit OpenCL veranstaltet doch Wasser auf die Mühlen von Nvidia!?
Also WTF?
OpenCL mag eine tolle Sache sein, technisch gesehen, und es freut jeden Entwickler wenn er eine breite Hardwarebasis targetten (achtung, neudeutsch! ) ) kann ohne x Kompilate dafür zu brauchen oder gr verschiedene Sourcen zu pflegen....
Aber angesichts der beschriebenen Probleme in den Threas die Opteron verlinkt hat, frage ich mich allen ernstes was das werden soll wenns fertig ist?
Die paar gigaFlops der OpenCL-Beispielapp die da gepostet wurden... das müsste ja sogar ne PS3 loscker leisten können...
Aber doch keine Graka mit über 1 TFlop an Rechenleistung... und die Frage ist, können die Evergreens das besser? In dem Thread redet ein AMDianer davon dass die evergreens "with OpenCL in Mind" designt wurden... aber was genau bedeutet das!? - das grundsätzliche Problem, dass OpenCL eigentlich aufgrund der Pointersemantik nicht kompatible mit dme Streaming-Ansatz (auf der einen Seite nur lesepuffer und auf der anderen Seite Write-combining) nicht wirklich kompatible ist, ändert das doch auch nix, oder?
Also so wies aussieht hat sich nichts geändert, wenn man performance auf einer Radeon will führt nichts an Brook/CAL vorbei. OpenCL hin oder her.
Hab ich das eignetlich richtig verstanden, dass zur Laufzeit zuerst OpenCL in IL JITed wird, nur um dann IL in Maschinencode für die Radeon zu JITen? Oo
Wenn Radeons für OpenCL suboptimal sind, wegen nicht-kohärentem Speichersystem dann hätte ATI das doch vorher wissen müssen... also wieso konzentrieren die sich derartig auf OpenCL, wenn sie genau wissen dass ihre eigene HW dafür unpraktisch ist?
Damit treibt man die Kundschaft ja noch mehr in die Hände von nvidia...!?
Angenommen Fermi rockt total ab bei OpenCL-Apps wegen sauberer pointerverwaltung, kohärentem, gecachetem Speicher etc. Dann wäre alles was AMD nun mit OpenCL veranstaltet doch Wasser auf die Mühlen von Nvidia!?
Also WTF?
OpenCL mag eine tolle Sache sein, technisch gesehen, und es freut jeden Entwickler wenn er eine breite Hardwarebasis targetten (achtung, neudeutsch! ) ) kann ohne x Kompilate dafür zu brauchen oder gr verschiedene Sourcen zu pflegen....
Aber angesichts der beschriebenen Probleme in den Threas die Opteron verlinkt hat, frage ich mich allen ernstes was das werden soll wenns fertig ist?
Die paar gigaFlops der OpenCL-Beispielapp die da gepostet wurden... das müsste ja sogar ne PS3 loscker leisten können...
Aber doch keine Graka mit über 1 TFlop an Rechenleistung... und die Frage ist, können die Evergreens das besser? In dem Thread redet ein AMDianer davon dass die evergreens "with OpenCL in Mind" designt wurden... aber was genau bedeutet das!? - das grundsätzliche Problem, dass OpenCL eigentlich aufgrund der Pointersemantik nicht kompatible mit dme Streaming-Ansatz (auf der einen Seite nur lesepuffer und auf der anderen Seite Write-combining) nicht wirklich kompatible ist, ändert das doch auch nix, oder?
Also so wies aussieht hat sich nichts geändert, wenn man performance auf einer Radeon will führt nichts an Brook/CAL vorbei. OpenCL hin oder her.
Hab ich das eignetlich richtig verstanden, dass zur Laufzeit zuerst OpenCL in IL JITed wird, nur um dann IL in Maschinencode für die Radeon zu JITen? Oo
gruffi
Grand Admiral Special
Nein. Du hast nur immer noch nicht verstanden, wovon die Rede war. Nämlich von der Sprachspezifikation und nicht von der Runtime.
![:]](https://www.planet3dnow.de/vbulletin/images/smilies/rolleyes.gif "Augen rollen (sarkastisch) :]")
Schon peinlich, wie du hier ständig gegen OpenCL und ATI bashst. Nimm es mir nicht übel, aber beschäftige dich erstmal wirklich mit Softwareprogrammierung. Und damit meine ich, lerne eine Sprache, C wäre schon mal ein guter Anfang, studiere viele Beispiele, lasse dir von erfahrenen Leuten Ratschläge geben (c-plusplus.de empfehle ich an dieser Stelle) und erstelle die ersten kleinen Programme.
Alles andere hat keinen Zweck. Wer die Materie nicht kennt, verbreitet nur zu viel Halbwissen. Und genau DAS tust du schon seit etlichen Beiträgen.
Ich denke auch nicht, dass Kohärenz hier irgendeine Rolle spielt. Zumal die bei ATI ebenfalls gegeben zu sein scheint (RV8xx, nicht RV7xx). Es ist eher die Implementierung der Runtime bzw des Compilers, die maximal noch nicht zureichend ist. Es geht hier um Zugriffsebenen. Mit Direct3D kannst du zB auch explizit RAM und Grafikspeicher ansprechen. Das sollte mit OpenCL daher auch kein Problem sein. Die aktuelle OpenCL Implementierung von AMD unterstützt letzteres momentan wohl noch nicht.
Und wenn ich mir den Thread im AMD Forum durchlese, stellt es sich auch anders dar, als du es hier zu kolportieren versuchst. So wird OpenCL generell nicht die maximale Performance eingeräumt. Genauso bei der Konkurrenz. Was ich aber erstmal als temporär betrachte. Denn wie Ge0rgy schon sagte, es müssen zu viele Plattformen berücksichtigt werden, was Kompromisse bedeutet.
@gruffi
den Zahlen nach ist "suboptimal" noch untertrieben.. brook war schon nicht schnell...
Du hast wohl recht, die Runtime muss verbessert werden, Die Kohärenz ist da ein problem, wo man "CPUig" zu programmieren versucht. D.h. man muss explizit bei der GPU-Programmierung darauf achten wo (in welchen Speicher) man was hinpackt. Das ist bei CPU nicht so wild und wird bei Fermi auch weniger eine Rolle spielen.
Das caching etc. mag auch wichtig werden. Sonst kostet die ganze Geschichte flugs jede Menge performance und der Aufwand lohnt sich eigentlich gar nicht mehr...
Jedenfalls schön dass AMD endlich openCL auf grafikkarten abliefert, aber wenn sie wirklich Bullet damit implementieren wollen, haben sie erstmal noch mächtig Arbeit an der Runtime als solchen vor sich um ordentliche Performance abzuliefern... sonst kann man gleich Havok nehmen und die CPU die Physik rechnen lassen....
Ich hoffe dass die Jungs es irgendwann auch schaffen werden, OpenCl direkt in Radeon-Maschinencode zu kompilieren, ohne umweg über IL.
Sonst wird bei OpenCl zweimal Just-in-time - Kompiliert. Und den overhead muss man sich ja nun wirklich nicht unbedingt antun...
den Zahlen nach ist "suboptimal" noch untertrieben.. brook war schon nicht schnell...
Du hast wohl recht, die Runtime muss verbessert werden, Die Kohärenz ist da ein problem, wo man "CPUig" zu programmieren versucht. D.h. man muss explizit bei der GPU-Programmierung darauf achten wo (in welchen Speicher) man was hinpackt. Das ist bei CPU nicht so wild und wird bei Fermi auch weniger eine Rolle spielen.
Das caching etc. mag auch wichtig werden. Sonst kostet die ganze Geschichte flugs jede Menge performance und der Aufwand lohnt sich eigentlich gar nicht mehr...
Jedenfalls schön dass AMD endlich openCL auf grafikkarten abliefert, aber wenn sie wirklich Bullet damit implementieren wollen, haben sie erstmal noch mächtig Arbeit an der Runtime als solchen vor sich um ordentliche Performance abzuliefern... sonst kann man gleich Havok nehmen und die CPU die Physik rechnen lassen....
Ich hoffe dass die Jungs es irgendwann auch schaffen werden, OpenCl direkt in Radeon-Maschinencode zu kompilieren, ohne umweg über IL.
Sonst wird bei OpenCl zweimal Just-in-time - Kompiliert. Und den overhead muss man sich ja nun wirklich nicht unbedingt antun...
Bobo_Oberon
Grand Admiral Special
- Mitglied seit
- 18.01.2007
- Beiträge
- 5.045
- Renomée
- 190
@gruffi
Also eine Runtime, die nur noch auf ein Fünftel der Geschwindigkeit läuft, gegenüber der eigenen API, IST eine Einschränkung.
Wenn darüber hinaus erst Grafikchips ab der HD 4000-Serien für OpenCL berücksichtigt werden, dann haben wir noch eine weitere Einschränkung gegenüber gleich alten Konkurrenzprodukten.
Mir ist aber klar, dass du diese Grenzen nicht sehen willst ...
Für Entwickler ist es sicherlich reizvoll plattformübergreifend zu arbeiten ... nur das mit der Geschwindigkeit ist zur Zeit noch nicht praxisreif gegenüber den firmeneigenen Schnittstellen/Runtimes.
Was du als ATI-Bashen empfindest, das ist der merkwürdige AMD-Gegensatz von fertiger DX11-Hardware und halbfertigen Rohfassungen eigener Softwaretools für OpenCL.
An anderen Stellen haben ich sehr wohl die frühen Fortschritte von AMDs Grafiksilizium gelobt. Bietet es doch dem kleinen x86-Giganten endlich mal die Chance schwarze Zahlen zu schreiben.
Die Konkurrenz hat gegenwärtig anscheinend eine völlig gegensätzliche Produktplanung. Dort konnten die grünen Grafikexperten aus Kalifornien schon früh erste OpenCL-Treiber und eine entsprechende Erweiterung ihrer Softwaretools vorzeigen ... nur mit dem realen DX11-Silizium haben sie massive Schwierigkeiten.
Und was das Bashen angeht ... ginge es mir darum Nvidia permanent ins Glanzlicht zu rücken ... dann hätte ich deren Schwierigkeiten mit Bonding-Problemen nie erwähnt ... habe ich aber.
Und was sagt das aus?
Im Profilager kommt ATI nicht so schnell rein, wie sie es in den Konsumermarkt offenbar schaffen. Dort haben die firmeneigenen APIs immer noch eine Daseinsberechtigung, wenn es um performante Lösungen geht.
Aber dort ist Nvidia zur Zeit immer noch stark mit CUDA (im Sinne deren weiten Definition) und ist zur Zeit deren einziger Lichtblick was hohe Stückpreise und Gewinn pro Karte angeht.
Die Qualitätsprobleme mit bröselnden GPUs auf Karten und Mainboards hingegen erschweren zusätzlich noch die Probleme der Kalifornier im Konsummarkt.
Und was sagt das zu OpenCL?
AMD hat noch einen weiten Weg zu beschreiten und ist derzeit noch kein "Must Have", um hochperformante IT-Lösungen damit zu ermöglichen.
MFG Bobo(2009)
Also eine Runtime, die nur noch auf ein Fünftel der Geschwindigkeit läuft, gegenüber der eigenen API, IST eine Einschränkung.
Wenn darüber hinaus erst Grafikchips ab der HD 4000-Serien für OpenCL berücksichtigt werden, dann haben wir noch eine weitere Einschränkung gegenüber gleich alten Konkurrenzprodukten.
Mir ist aber klar, dass du diese Grenzen nicht sehen willst ...
Für Entwickler ist es sicherlich reizvoll plattformübergreifend zu arbeiten ... nur das mit der Geschwindigkeit ist zur Zeit noch nicht praxisreif gegenüber den firmeneigenen Schnittstellen/Runtimes.
Was du als ATI-Bashen empfindest, das ist der merkwürdige AMD-Gegensatz von fertiger DX11-Hardware und halbfertigen Rohfassungen eigener Softwaretools für OpenCL.
An anderen Stellen haben ich sehr wohl die frühen Fortschritte von AMDs Grafiksilizium gelobt. Bietet es doch dem kleinen x86-Giganten endlich mal die Chance schwarze Zahlen zu schreiben.
Die Konkurrenz hat gegenwärtig anscheinend eine völlig gegensätzliche Produktplanung. Dort konnten die grünen Grafikexperten aus Kalifornien schon früh erste OpenCL-Treiber und eine entsprechende Erweiterung ihrer Softwaretools vorzeigen ... nur mit dem realen DX11-Silizium haben sie massive Schwierigkeiten.
Und was das Bashen angeht ... ginge es mir darum Nvidia permanent ins Glanzlicht zu rücken ... dann hätte ich deren Schwierigkeiten mit Bonding-Problemen nie erwähnt ... habe ich aber.
Und was sagt das aus?
Im Profilager kommt ATI nicht so schnell rein, wie sie es in den Konsumermarkt offenbar schaffen. Dort haben die firmeneigenen APIs immer noch eine Daseinsberechtigung, wenn es um performante Lösungen geht.
Aber dort ist Nvidia zur Zeit immer noch stark mit CUDA (im Sinne deren weiten Definition) und ist zur Zeit deren einziger Lichtblick was hohe Stückpreise und Gewinn pro Karte angeht.
Die Qualitätsprobleme mit bröselnden GPUs auf Karten und Mainboards hingegen erschweren zusätzlich noch die Probleme der Kalifornier im Konsummarkt.
Und was sagt das zu OpenCL?
AMD hat noch einen weiten Weg zu beschreiten und ist derzeit noch kein "Must Have", um hochperformante IT-Lösungen damit zu ermöglichen.
MFG Bobo(2009)
Zuletzt bearbeitet:
Für Entwickler ist das Dilemma noch schlimmer...
Unterstütz ich nun eine proprietäre (und vergleichsweise komplizierte, weil Brook ja offiziell nicht mehr dazugehört, also bleibt nur direkt IL) API, oder nutz ich einen vermeintlich Plattformübergreifenden Standard und hab dafür das Problem dass die Performance auf absehbare Zeit bescheiden ausfällt...
Ergo-> Der entwickler nimmt lieber gleich CUDA.
Unterstütz ich nun eine proprietäre (und vergleichsweise komplizierte, weil Brook ja offiziell nicht mehr dazugehört, also bleibt nur direkt IL) API, oder nutz ich einen vermeintlich Plattformübergreifenden Standard und hab dafür das Problem dass die Performance auf absehbare Zeit bescheiden ausfällt...
Ergo-> Der entwickler nimmt lieber gleich CUDA.
PuckPoltergeist
Grand Admiral Special
Nein. Du hast nur immer noch nicht verstanden, wovon die Rede war. Nämlich von der Sprachspezifikation und nicht von der Runtime.
Schon peinlich, wie du hier ständig gegen OpenCL und ATI bashst. Nimm es mir nicht übel, aber beschäftige dich erstmal wirklich mit Softwareprogrammierung. Und damit meine ich, lerne eine Sprache, C wäre schon mal ein guter Anfang, studiere viele Beispiele, lasse dir von erfahrenen Leuten Ratschläge geben (c-plusplus.de empfehle ich an dieser Stelle) und erstelle die ersten kleinen Programme.
Alles andere hat keinen Zweck. Wer die Materie nicht kennt, verbreitet nur zu viel Halbwissen. Und genau DAS tust du schon seit etlichen Beiträgen.
Nein, er hat Recht. Was nützt mir ein unterstützter Sprachstandard, wenn ich bei der Implementierung den Bits beim durch die Gegend Rollen zusehen kann? Ein Standard ist für die Tonne, wenn seine Implementierung praxisfern ist.
gruffi
Grand Admiral Special
Du musst immer darauf achten, wo du Daten hinpackst und wie diese allokiert/deallokiert werden. Das ist bei der CPU nicht anders. Stichwort Stack und Heap. Ich kann dir problemlos ein Beispiel für die CPU programmieren, was durch falsches Speichermanagement x-fach langsamer läuft. Das sind alles alte Hüte. Mich wundert daher, was hier für ein Drama daraus gemacht wird. Aber das scheint wohl an Bob
beron zu liegen, der auf OpenCL basht, wo es nur geht. Ich frage mich, was er damit erreichen will. Ich hoffe nur, dass die Leser seine Aussagen nicht zu ernst nehmen. OpenCL ist das beste, was aus Sicht der Programmierung passieren konnte. Selbst wenn es am Ende minimal langsamer als proprietäre Lösungen wie Stream oder CUDA laufen sollte, spielt das keine Rolle. So wild wie C/C++ vs Java wird es sehr wahrscheinlich nicht sein. Und Java hat sich mittlerweile durchgesetzt. Auch wenn der Vergleich etwas hinkt.
@Bob
beron & PuckPoltergeistIch kann nur nochmal sagen, was ich bereits gesagt habe. Die bisherige Sachlage ist rein temporär. Also versucht hier nicht irgendwelche Polemik rein zu interpretieren. Das ist weder sachlich noch konstruktiv.
@gruffi
natürlich muss man aufpassen wo man was hinpackt, aber der stack einer intel CPU funktioniert kaum anders als der auf AMD.
Wenn aber z.b. fermi rauskommt und aufgrund seiner cpu-artigen cachestruktur "schlampiges" programmieren fördert, also dass der entwickler nur minimale leistungseinbußen zu befürchten hat wenn er in der Hinsicht zuwenig nachdenkt, dann wird es am ende heißen "ati ist langsam", wenn die App ausgebremst wird etc. Du weißt doch, man sucht die schuld immer bei der HW.
d.h. ordentliches, performantes Programmieren fordert dem Entwickler einiges an sorgfalt ab...
Und da Programmierer faule leute sind, die sich spätestens seit Visua studio gerne jede Menge arbeit abnehmen lassen, werde die einfach den "leichten" weg gehen... undi hren kunden ggf. raten eben nvidia grakas zu kaufen....
Und da gpgpu grade deswegen so bekannt ist wegen seinr hohen geschwindigkeit, schmerzt eine lahme implementation dort noch viel mehr als wenn ein algorithmus auf der CPU eben 200ms länger braucht...
Befrag mal einen Python-Programmierr zu stack und heap...
Sogar bei Java wirst du eingie Finden die die Frage nicht beantworten können... von .net, wo man auch Wertetypen auf dem stack mit "new" instanziert mal ganz zu schweigen...
natürlich muss man aufpassen wo man was hinpackt, aber der stack einer intel CPU funktioniert kaum anders als der auf AMD.
Wenn aber z.b. fermi rauskommt und aufgrund seiner cpu-artigen cachestruktur "schlampiges" programmieren fördert, also dass der entwickler nur minimale leistungseinbußen zu befürchten hat wenn er in der Hinsicht zuwenig nachdenkt, dann wird es am ende heißen "ati ist langsam", wenn die App ausgebremst wird etc. Du weißt doch, man sucht die schuld immer bei der HW.
d.h. ordentliches, performantes Programmieren fordert dem Entwickler einiges an sorgfalt ab...
Und da Programmierer faule leute sind, die sich spätestens seit Visua studio gerne jede Menge arbeit abnehmen lassen, werde die einfach den "leichten" weg gehen... undi hren kunden ggf. raten eben nvidia grakas zu kaufen....
Und da gpgpu grade deswegen so bekannt ist wegen seinr hohen geschwindigkeit, schmerzt eine lahme implementation dort noch viel mehr als wenn ein algorithmus auf der CPU eben 200ms länger braucht...
Befrag mal einen Python-Programmierr zu stack und heap...
Sogar bei Java wirst du eingie Finden die die Frage nicht beantworten können... von .net, wo man auch Wertetypen auf dem stack mit "new" instanziert mal ganz zu schweigen...
Bobo_Oberon
Grand Admiral Special
- Mitglied seit
- 18.01.2007
- Beiträge
- 5.045
- Renomée
- 190
Nochmal:... Aber das scheint wohl an Bob
Das was ich mache ist kein Bashen. Es ist eine zeitweilige Kritik an Baustellen/Hausaufgaben, die AMD/ATI noch zu erledigen haben:
Die Idee, welche hinter OpenCL steht, finde ich auf jeden Fall unterstützenswert. Es ist faszinierend damit unterschiedliche Chips/Architekturen unter einem Hut zu bringen, die bislang kaum zusammengefunden haben.
Ein Cell, oder ein MIPS-Octacore mit OpenCL zusammen mit einem x86-Prozessor zu betreiben ist eine hochinteressante Geschichte. Bis es aber rund läuft sind aber noch einige Hausaufgaben zu erledigen.
Was die Software/Tool-Seite angeht, da hat Nvidia vorgelegt.
Und auch bei der Hardware scheint Nvidia zur Zeit etwas runder in der Hand der Entwickler zu liegen.
Ich denke, so langsam sickert die Erkenntnis ins P3D-Forum hinein, dass zur Zeit OpenCL mehr Hoffnung, als Gegenwart ist, um AMD einen kräftigen Wachstumsschub zu geben. Genau das war beabsichtigt und sogar du räumst ein, dass es performanter sein könnte.
MFG Bobo(2009)
gruffi
Grand Admiral Special
Schön, wenn du das so siehst. Auf mich wirkt das aber ganz anders. Sachliche Kritik sieht jedenfalls anderes aus.
Eben nicht. Schau dir doch den Thread bei AMD an. Die Problematik mit OpenCL gibt es dort genauso bei nVidia.
Siehst du, genau solche Polemik meine ich. Das hat hier nichts verloren. Und wenn du das nicht bleiben lässt, wirst du auch immer wieder Kritik von mir zu hören bekommen. Programmierung hat nichts mit Hoffnung zu tun. Hier geht es um pure Pragmatik.
Eingeräumt habe ich gar nichts. Ich habe lediglich die Möglichkeit in Betracht gezogen. Bisher gibt es zu wenige Fakten, um konkrete Schlüsse ziehen zu können. Da helfen auch die 2 Beispiele mit der alten Generation im besagten Thread nichts.
Bobo_Oberon
Grand Admiral Special
- Mitglied seit
- 18.01.2007
- Beiträge
- 5.045
- Renomée
- 190
Schau dir mal an WANN Nvdia erste OpenCL taugliche Treiber veröffentlicht hat.
Schau dir an, WANN sie ihre CUDA-Suite für die neue API OpenCL fit gemacht haben.
Apple-Jünger konnten mit Snow-Leopard nativ mit OpenCL erste Erfahrungen sammeln. Das sagt zwar nichts über die Leistungsfähigkeit der Nvidia-Karten aus, aber zumindest konnten schon deutlich früher erste Erfahrungen gesammelt werden.
MFG Bobo(2009)
gruffi
Grand Admiral Special
nVidia hat nur geringfügig früher als ATI ein erstes OpenCL SDK veröffentlicht. Und das hat, soweit mir bekannt ist, auch noch nicht den vollen Sprachumfang unterstützt.
So langsam habe ich das Gefühl, in dir steckt ein kleiner nVidia F*****. Um wirklich konstruktive Diskussionen scheint es dir offenbar nicht zu gehen. Stattdessen werden immer nur solche Pseudo Argumente hervor gezaubert.
So langsam habe ich das Gefühl, in dir steckt ein kleiner nVidia F*****. Um wirklich konstruktive Diskussionen scheint es dir offenbar nicht zu gehen. Stattdessen werden immer nur solche Pseudo Argumente hervor gezaubert.
Bobo_Oberon
Grand Admiral Special
- Mitglied seit
- 18.01.2007
- Beiträge
- 5.045
- Renomée
- 190
Das musste ja von dir kommen. Ich bedanke mich für die Einteilung in die Fanboykiste.nVidia hat nur geringfügig früher als ATI ein erstes OpenCL SDK veröffentlicht. Und das hat, soweit mir bekannt ist, auch noch nicht den vollen Sprachumfang unterstützt.
So langsam habe ich das Gefühl, in dir steckt ein kleiner nVidia F*****. Um wirklich konstruktive Diskussionen scheint es dir offenbar nicht zu gehen. Stattdessen werden immer nur solche Pseudo Argumente hervor gezaubert.
Mir wäre es lieber gewesen, wenn du die Zeitpunkte mal auch genannt hättest ... dann kann jeder für sich selber entscheiden, was denn "geringfügig" ist. Und dann kann jeder für sich selbst abschätzen, ob es denn ein "Pseudo-Argument ist":
Quelle
Was die OpenCL-Unterstützung in der eigenen SDK angeht, so fingen die Kalifornier schon im letzten Jahr offiziell damit am 9. Dezember 2008 an. Wie war das noch mal mit Stream und der ersten Unterstützung der ersten Prozessoren ... genau, einige Monate später und GPUs folgten noch später.
Debugger und Profiling-Tools folgten am 8. April 2009 bei den grünen Grafikexperten.
Und erste Treiber wurden etwas später am 20. April 2009 für Entwickler nachgeschoben.
Mag ja sein, dass Treiber und Tools der Geforce-Erfinder nicht das Gelbe vom Ei sind. Sie waren aber zeitlich deutlich früher dran. AMD/ATI lieferte erst deutlich später entsprechende Konkurrenz-Tools und Treiber mit OpenCL-Unterstütung ab (siehe die User-News vom Opteron seit dem 5. August 2009).
So viel zur Einstufung von "geringfügig", "unerheblich", "unwichtig" ...
MFG Bobo(2009)
PuckPoltergeist
Grand Admiral Special
Siehst du, genau solche Polemik meine ich. Das hat hier nichts verloren. Und wenn du das nicht bleiben lässt, wirst du auch immer wieder Kritik von mir zu hören bekommen. Programmierung hat nichts mit Hoffnung zu tun. Hier geht es um pure Pragmatik.
Merkst du eigentlich, wie du dir widersprichst? Ich zitiere mich mal selbst:
Mir nützt OpenCL gar nichts, wenn die Programme, dich ich damit schreibe, nicht mal ansatzweise an die Geschwindigkeit einer proprietären Lösung heran kommen. Die pragmatische Lösung ist ganz einfach, ich lasse OpenCL links liegen, und greife z.B. zu Cuda. Dann läuft mein Programm zwar nicht auf AMD-GPUs, aber es ist schnell auf der Architektur, für die es geschrieben wurde. Mir nützt Interoperabilität nichts, wenn ich diese mit deutlich schlechterer Performance erkaufen muss.
gruffi
Grand Admiral Special
@Bobberon
Augen aufmachen! AMD hatte bereits Anfang August das erste SDK mit vollem Sprachumfang am Start. Nix Ende September. Und was nVidia davor gemacht hat, IST unerheblich. Mag ja sein, dass man damit schon etwas früher rumspielen konnte. Hier geht es aber um seriöse Entwicklungen. Und dafür war das nVidia SDK Anfang des Jahres noch nicht verwendbar. So viel zum Thema geringfügig.
@PuckPoltergeist
Wie wäre es, wenn du dir mal die diversen Threads zum Thema durchlesen würdest? Was du hier unterstellst, nämlich dass OpenCL per se deutlich langsamer ist, ist noch lange kein Fakt. Und widersprochen habe ich mir genauso wenig. Nicht so viel Interpretieren.
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.
beronAugen aufmachen! AMD hatte bereits Anfang August das erste SDK mit vollem Sprachumfang am Start. Nix Ende September. Und was nVidia davor gemacht hat, IST unerheblich. Mag ja sein, dass man damit schon etwas früher rumspielen konnte. Hier geht es aber um seriöse Entwicklungen. Und dafür war das nVidia SDK Anfang des Jahres noch nicht verwendbar. So viel zum Thema geringfügig.
@PuckPoltergeist
Wie wäre es, wenn du dir mal die diversen Threads zum Thema durchlesen würdest? Was du hier unterstellst, nämlich dass OpenCL per se deutlich langsamer ist, ist noch lange kein Fakt. Und widersprochen habe ich mir genauso wenig. Nicht so viel Interpretieren.
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.
Ähnliche Themen
