News Erscheint das ATI Stream SDK 2.2 nächste Woche?
- Ersteller Dr@
- Erstellt am
Dr@
Grand Admiral Special
<div class="newsfloatleft"><a href="http://www.amd.com/US/PRODUCTS/TECHNOLOGIES/STREAM-TECHNOLOGY/Pages/stream-technology.aspx"><img src="http://www.planet3dnow.de/photoplog/images/54308/1_ATI-STREAM_Logo.jpg" border="1" alt="ATI STREAM Logo"></a></div>Auf der Website von AMD ist ein neuer Beta-Treiber aufgetaucht, der die Unterstützung für das noch nicht erschienene ATI Stream SDK 2.2 und damit für <a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=381944" target="b">OpenCL 1.1</a> mit sich bringt. Laut der <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1278322413">aufgetauchten Roadmap</a> für die Weiterentwicklung des ATI Stream SDKs soll die Version 2.2 noch im August erscheinen. Dass bereits jetzt der Update-Treiber verfügbar ist, deutet auf ein Erscheinen des ATI Stream SDKs 2.2 in den nächsten Tagen hin. Der Treiber trägt keine WHQL-Zertifizierung und hat noch nicht das volle Testprogramm bei AMD hinter sich gebracht.
Der „ATI Catalyst 10.7 Update Driver for OpenCL 1.1 Support” steht für sämtliche Windows-Betriebssysteme und Linux zum Download bereit. Vom Treiber werden folgende Grafikkarten und Beschleunigerkarten unterstützt:
<p style="clear:left">
<blockquote><b>Hardware</b><ul><li>ATI Radeon HD 5xxx and ATI Radeon Mobility equivalent series of products</li><li>ATI Radeon HD 4xxx and ATI Radeon Mobility equivalent series of products</li><li>ATI FirePro V8xxx Professional series of products</li><li>ATI FirePro V7xxx Professional series of products</li><li>ATI FirePro V5xxx Professional series of products</li><li>ATI FirePro V4xxx Professional series of products</li><li>ATI FirePro V38xx Professional series of products</li><li>ATI FirePro V3750 Professional Graphics</li><li>AMD FireStream 92xx series of products</li><li>ATI Radeon Embedded E4690 Discrete GPU</li></ul>
<b>Operating System</b><ul><li>Windows 7 32-bit Edition</li><li>Windows 7 64-bit Edition</li><li>Windows Vista 32-bit Edition</li><li>Windows Vista 64-bit Edition</li><li>Windows XP Professional / Home (32-bit/64-bit)</li><li>Windows XP Media Center Edition (32-bit/64-bit)</li><li>Linux x86</li><li>Linux x86_64</li></ul></blockquote>
<b>Quelle mit Download:</b><ul><li><a href="http://support.amd.com/us/kbarticles/Pages/OpenCL11ATICat107UpdateDriver.aspx" target="b">ATI Catalyst 10.7 Update Driver for OpenCL 1.1 Support </a></li></ul>
<b>Links zum Thema:</b><ul><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1280134314">Erster OpenGL ES 2.0 fähiger Grafiktreiber von AMD</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1279613880">ATI Catalyst Software Q2 2010 Newsletter aufgetaucht</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1278322413">ATI Stream SDK Roadmap aufgetaucht</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1272989740">ATI Stream Software Development Kit (SDK) v2.1</a></li>
<li><a href="http://developer.amd.com/gpu/ATIStreamSDK/Pages/default.aspx" target="b">ATI Stream Software Development Kit (SDK)</a></li><li><a href="http://developer.amd.com/zones/OpenCLZone/Pages/default.aspx" target="b">OpenCL Zone </a></li><li><a href="http://developer.amd.com/pages/default.aspx" target="b">AMD Developer Central</a></li></ul></p>
Der „ATI Catalyst 10.7 Update Driver for OpenCL 1.1 Support” steht für sämtliche Windows-Betriebssysteme und Linux zum Download bereit. Vom Treiber werden folgende Grafikkarten und Beschleunigerkarten unterstützt:
<p style="clear:left">
<blockquote><b>Hardware</b><ul><li>ATI Radeon HD 5xxx and ATI Radeon Mobility equivalent series of products</li><li>ATI Radeon HD 4xxx and ATI Radeon Mobility equivalent series of products</li><li>ATI FirePro V8xxx Professional series of products</li><li>ATI FirePro V7xxx Professional series of products</li><li>ATI FirePro V5xxx Professional series of products</li><li>ATI FirePro V4xxx Professional series of products</li><li>ATI FirePro V38xx Professional series of products</li><li>ATI FirePro V3750 Professional Graphics</li><li>AMD FireStream 92xx series of products</li><li>ATI Radeon Embedded E4690 Discrete GPU</li></ul>
<b>Operating System</b><ul><li>Windows 7 32-bit Edition</li><li>Windows 7 64-bit Edition</li><li>Windows Vista 32-bit Edition</li><li>Windows Vista 64-bit Edition</li><li>Windows XP Professional / Home (32-bit/64-bit)</li><li>Windows XP Media Center Edition (32-bit/64-bit)</li><li>Linux x86</li><li>Linux x86_64</li></ul></blockquote>
<b>Quelle mit Download:</b><ul><li><a href="http://support.amd.com/us/kbarticles/Pages/OpenCL11ATICat107UpdateDriver.aspx" target="b">ATI Catalyst 10.7 Update Driver for OpenCL 1.1 Support </a></li></ul>
<b>Links zum Thema:</b><ul><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1280134314">Erster OpenGL ES 2.0 fähiger Grafiktreiber von AMD</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1279613880">ATI Catalyst Software Q2 2010 Newsletter aufgetaucht</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1278322413">ATI Stream SDK Roadmap aufgetaucht</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1272989740">ATI Stream Software Development Kit (SDK) v2.1</a></li>
<li><a href="http://developer.amd.com/gpu/ATIStreamSDK/Pages/default.aspx" target="b">ATI Stream Software Development Kit (SDK)</a></li><li><a href="http://developer.amd.com/zones/OpenCLZone/Pages/default.aspx" target="b">OpenCL Zone </a></li><li><a href="http://developer.amd.com/pages/default.aspx" target="b">AMD Developer Central</a></li></ul></p>
Morrich
Vice Admiral Special
- Mitglied seit
- 25.01.2010
- Beiträge
- 525
- Renomée
- 1
Wie schlägt sich denn Stream aktuell überhaupt gegen CUDA?
Wird Stream überhaupt von den Anwendern genutzt, oder fristet es eher ein Nischendasein?
Und was ist mit PhysX? Hat ATi dazu denn schon ein konkurrenzfähiges Pendant, das evtl. auch mal großflächiger einzusetzen ist, oder darf man Physikeffekte weiterhin nur mit Nvidia Karten erwarten?
Wird Stream überhaupt von den Anwendern genutzt, oder fristet es eher ein Nischendasein?
Und was ist mit PhysX? Hat ATi dazu denn schon ein konkurrenzfähiges Pendant, das evtl. auch mal großflächiger einzusetzen ist, oder darf man Physikeffekte weiterhin nur mit Nvidia Karten erwarten?
Nach meiner Erfahung ist OpenCL Mist. Das ganze Konzept ist schon daneben. Alles Hardware mit einem Programm zu unterstützen.
Alle Anwendungen für ati-gpus die ich kenne sind mit cal programmiert. ati hätte bei brook bleiben sollen. das war gar nicht so schlecht, finde ich... auch wenn es natürlich noch viele Fehler hatte. Aber OpenCL ist einfach nur ein schlechter CUDA-Abklatsch der nie das erreicht wofür CUDA genutzt wird nämlich die Leistung der GPU ausschöpfen. Das heißt vor allem Optimierung. Und das geht nicht hardwareunabhängig.
ex-sell
Alle Anwendungen für ati-gpus die ich kenne sind mit cal programmiert. ati hätte bei brook bleiben sollen. das war gar nicht so schlecht, finde ich... auch wenn es natürlich noch viele Fehler hatte. Aber OpenCL ist einfach nur ein schlechter CUDA-Abklatsch der nie das erreicht wofür CUDA genutzt wird nämlich die Leistung der GPU ausschöpfen. Das heißt vor allem Optimierung. Und das geht nicht hardwareunabhängig.
ex-sell
Die hardwareabhängige Optimierung muss halt der Treiber machen. Klar, der Programmiercode wird dann im Zweifel nicht unbedingt auf die Hardwarebasis ausgelegt, aber was machst du wenn sich die ändert?
Das ist nämlich für AMD viel wichtiger, nicht unbedingt weil man an der Grafikarchitektur rumspielt (das natürlich auch!), sondern weil man Software haben will, die man auf CPU und GPU ausführen kann. Das interessiert Nvidia natürlich nicht, aber für AMD ist es wichtig - und vermutlich kann man durch ne geschickte Aufteilung da deutlich mehr Performance herausholen - eins der Hauptziele von Fusion. Dafür muss man aber hardwareunabhängig programmieren.
Das ist nämlich für AMD viel wichtiger, nicht unbedingt weil man an der Grafikarchitektur rumspielt (das natürlich auch!), sondern weil man Software haben will, die man auf CPU und GPU ausführen kann. Das interessiert Nvidia natürlich nicht, aber für AMD ist es wichtig - und vermutlich kann man durch ne geschickte Aufteilung da deutlich mehr Performance herausholen - eins der Hauptziele von Fusion. Dafür muss man aber hardwareunabhängig programmieren.
Das ist sicherlich wahr, dass AMD gerne möchte, dass man ein Programm schreib das dann überall schnell läuft. Aber wahrscheilich hätte AMD auch gerne einen Esel der Gold sheißt... geht aber beides nicht. Und deswegen ist auch OpenCL zum Scheitern verurteilt. Man muss Problem einfach ganz anders angehen jenachdem welche Hardware man nutzt. Und da kann kein Treiber oder Compiler was dran ändern.
Also bleibt nur, dass man doch wieder alles für jede Zielhardware neu/anders/etxra schreibt. Aber das muss man sowieso machen, wenn man kein OpenSource-Programm erzeugen will. Denn das compilieren für die Zielhardware wird zur Laufzeit gemacht. Und das geht natürlich nur wenn zur Laufzeit der Programmcode zur Verfügung steht. Und den wollen nicht alle raus geben...
Also kurz um: OpenCL will zu viel und das wird so nix. AMD hätte sich lieber mit NVIDIA einigen sollen für einen eigenen Standard und vielleicht noch Intel mit ins Boot geholt. Dann hätte man wahrscheilich auch noch verschiedenen Versionen für die jeweiligen GPU schreiben müssen aber man hätte wenigstens CUDA als brauchbare Grundlage... Und hätte auch funktioniert, denn CUDA und Stream/brook++ haben sich ja aus dem gleichen Projekt heraus entwickelt...
ex-sell
Also bleibt nur, dass man doch wieder alles für jede Zielhardware neu/anders/etxra schreibt. Aber das muss man sowieso machen, wenn man kein OpenSource-Programm erzeugen will. Denn das compilieren für die Zielhardware wird zur Laufzeit gemacht. Und das geht natürlich nur wenn zur Laufzeit der Programmcode zur Verfügung steht. Und den wollen nicht alle raus geben...
Also kurz um: OpenCL will zu viel und das wird so nix. AMD hätte sich lieber mit NVIDIA einigen sollen für einen eigenen Standard und vielleicht noch Intel mit ins Boot geholt. Dann hätte man wahrscheilich auch noch verschiedenen Versionen für die jeweiligen GPU schreiben müssen aber man hätte wenigstens CUDA als brauchbare Grundlage... Und hätte auch funktioniert, denn CUDA und Stream/brook++ haben sich ja aus dem gleichen Projekt heraus entwickelt...
ex-sell
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Öhh .. genau die Firmen sind bei OpenCL doch dabei
Bobo_Oberon
Grand Admiral Special
- Mitglied seit
- 18.01.2007
- Beiträge
- 5.045
- Renomée
- 190
->
Dr@
Grand Admiral Special
ups
Ist gefixt.
Danke für den Hinweis!
Ist aber interessant, wie lange es niemand bemerkt hat.
@Opteron & Bob
beron: Ihr habt natürlich recht, dass AMD, NVIDIA und Intel bei OpenCL mitmischen. Aber das sagt zum einen noch nix über die Motivation aus. Ich denke, dass z.B. NVIDIA nicht so schrecklich großes INteresse daran hat, dass sich OpenCL durchsetzt. Und auch Intel wäre es bestimmt lieber wenn Grafikkarte auch in Zukunft nicht für Dinge benutz werden für die man sonst viele CPUs kaufen müsste... Was ich aber meinte war, dass sich vorallem NVIDIA und AMD auf einen Standard für die Programmierung von GPUs einigen. Und dann am besten ein bisschen mit INtel abstimmen, damit das ganz auch auf deren GPUs läuft. Auf einer Intel-GPU wären dann die meisten Programme wahrscheilich nicht schneller als auf einer ordentlichen CPU aber man hätte damit (fast) alle Computer abgedeckt und bräuchte nicht mit irgendwelchem CPU-Emulations-Krams anfangen.
@Muku-Muku: Ich habe nix gegen OpenGL/Direct3D
Und ich bin der Meinung man kann das nicht ganz vergleichen. Will ich gleich voraus schicken, dass ich mich mit OpenGL und Direct3D nicht auskenne. Aber es ist doch so, dass bei OGL und D3D erstmal das Ziel Grundsätzlich ist das Ganze auf einer GPU auszuführen. Und auch wenn AMD und NVIDIA nicht viel verraten wie ihre Hardware funktioniert so gibt es zwischen den Funktionsweisen sicher viele Parallelen. Somit ist die grundsätzlichen Problemlösungsansätze für GPUs jedes Herstellers gleich. Nun gibt es auch bei D3D und OGL die Möglichkeit das ganze auf der CPU zu berechnen. Aber das ist dann wahrscheilich doch eher so gedacht, dass man das für die Entwicklung und das Debugging nutzen kann (was auch Sinn macht und zum Glück gibt es auch bei CUDA einen CPU-Emulationsmodus).
Bei OpenCL ist der Ansatz aber, dass man ein Programm schreib und das dann überall SCHNELL läuft. Ich kann natürlich ein Programm für die Grafikkarte schreiben und das läuft dann auch auf der CPU. Die Frage ist nur wie schnell... Und andersrum geht es eventuell auch. Nur wird da das Ergebnis noch enttäuschender sein. Denn was auf der CPU schnell ist, ist auf der GPU eventuell langsam und umgekehrt. Um mal ein wenig konkreter zu werden ein einfaches Beispiel:
Wenn man ein Algorithmus wie etwa DES (Data Encryption Standard, zwar nicht mehr ganz aktuell aber dennoch im Einsatz) für die CPU implemetiert kann man schön die Sboxes als Lookuptable im L2-Cache, mit etwas Glück auch zum Teil im L1-Cache vorhalten. Ne Lookup-Table ist auf einer GPU aber eine ganz schlechte Idee. Denn im besten Fall kann man die Tabelle im Constant-Cache vorhalten. Dann braucht jeder Zugriff zwar nur einen/wenige Takt(e) aber es kann immer nur ein Thread gleichzeitig darauf zugrifen. Damit hat man dann einen Thread der sein Look-up macht und n-1 thread tun nix. Für DES gibt es aber eine sehr schöne Lösung, und zwar eine so genannte Bit-Slice-Implementierung. Dabei werden die Sboxes durch eine Reihe von Bitoperationen dargestellt. Dadurch kann man das look-up durch Rechenoperationen ersetzen. Und diese Rechenoperationen können auf der GPU von allen Thread parallel ausgeführt werden. Nun funktioniert dieser Bitslice-Ansatz auch auf der CPU aber dort ist die look-up-table in der Regel schneller.
Also wenn das Ziel von OpenCL wirklich ist, dass man ein Programm schreibt und der Compiler/Treiber optimiert dann für die Zielhardware dann müsste er in dem Beispiel von eben erkennen, dass die Folge von Bitoperatinen gleichwertig ist mit einer Look-up-table. Und das ist doch etwas viel verlangt. Außerdem ist das nur eines von vielen Beispielen.
Also meine Kritik an OpenCL ist nicht, dass man die Grafikkartenprogrammierung vereinheitlichen will. Das sollte mit etwas guten Willen seitens NVIDIA funktionieren. Was ich unrealistisch finde ist der Anspruch OpenCL auch auf x86-CPU und auf sonstigen Platformen ausführen zu können. Und eben wegen dieses "etwas" zu hoch gestecken Ziels glaube ich, dass sich OpenCL sehr schwer tun wird bzw. sich anderes entwickelt/benutzwird als ursprünglich gedacht. Also doch wieder ein Programm für jede Zielhardware (mit mehr oder weniger viel Gemeinsamkeiten). Aber das würde bedeuten, dass OpenCL gescheitert ist da ja das Ziel war genau das zu verhindern...
ex-sell
beron: Ihr habt natürlich recht, dass AMD, NVIDIA und Intel bei OpenCL mitmischen. Aber das sagt zum einen noch nix über die Motivation aus. Ich denke, dass z.B. NVIDIA nicht so schrecklich großes INteresse daran hat, dass sich OpenCL durchsetzt. Und auch Intel wäre es bestimmt lieber wenn Grafikkarte auch in Zukunft nicht für Dinge benutz werden für die man sonst viele CPUs kaufen müsste... Was ich aber meinte war, dass sich vorallem NVIDIA und AMD auf einen Standard für die Programmierung von GPUs einigen. Und dann am besten ein bisschen mit INtel abstimmen, damit das ganz auch auf deren GPUs läuft. Auf einer Intel-GPU wären dann die meisten Programme wahrscheilich nicht schneller als auf einer ordentlichen CPU aber man hätte damit (fast) alle Computer abgedeckt und bräuchte nicht mit irgendwelchem CPU-Emulations-Krams anfangen.@Muku-Muku: Ich habe nix gegen OpenGL/Direct3D
Und ich bin der Meinung man kann das nicht ganz vergleichen. Will ich gleich voraus schicken, dass ich mich mit OpenGL und Direct3D nicht auskenne. Aber es ist doch so, dass bei OGL und D3D erstmal das Ziel Grundsätzlich ist das Ganze auf einer GPU auszuführen. Und auch wenn AMD und NVIDIA nicht viel verraten wie ihre Hardware funktioniert so gibt es zwischen den Funktionsweisen sicher viele Parallelen. Somit ist die grundsätzlichen Problemlösungsansätze für GPUs jedes Herstellers gleich. Nun gibt es auch bei D3D und OGL die Möglichkeit das ganze auf der CPU zu berechnen. Aber das ist dann wahrscheilich doch eher so gedacht, dass man das für die Entwicklung und das Debugging nutzen kann (was auch Sinn macht und zum Glück gibt es auch bei CUDA einen CPU-Emulationsmodus).Bei OpenCL ist der Ansatz aber, dass man ein Programm schreib und das dann überall SCHNELL läuft. Ich kann natürlich ein Programm für die Grafikkarte schreiben und das läuft dann auch auf der CPU. Die Frage ist nur wie schnell... Und andersrum geht es eventuell auch. Nur wird da das Ergebnis noch enttäuschender sein. Denn was auf der CPU schnell ist, ist auf der GPU eventuell langsam und umgekehrt. Um mal ein wenig konkreter zu werden ein einfaches Beispiel:
Wenn man ein Algorithmus wie etwa DES (Data Encryption Standard, zwar nicht mehr ganz aktuell aber dennoch im Einsatz) für die CPU implemetiert kann man schön die Sboxes als Lookuptable im L2-Cache, mit etwas Glück auch zum Teil im L1-Cache vorhalten. Ne Lookup-Table ist auf einer GPU aber eine ganz schlechte Idee. Denn im besten Fall kann man die Tabelle im Constant-Cache vorhalten. Dann braucht jeder Zugriff zwar nur einen/wenige Takt(e) aber es kann immer nur ein Thread gleichzeitig darauf zugrifen. Damit hat man dann einen Thread der sein Look-up macht und n-1 thread tun nix. Für DES gibt es aber eine sehr schöne Lösung, und zwar eine so genannte Bit-Slice-Implementierung. Dabei werden die Sboxes durch eine Reihe von Bitoperationen dargestellt. Dadurch kann man das look-up durch Rechenoperationen ersetzen. Und diese Rechenoperationen können auf der GPU von allen Thread parallel ausgeführt werden. Nun funktioniert dieser Bitslice-Ansatz auch auf der CPU aber dort ist die look-up-table in der Regel schneller.
Also wenn das Ziel von OpenCL wirklich ist, dass man ein Programm schreibt und der Compiler/Treiber optimiert dann für die Zielhardware dann müsste er in dem Beispiel von eben erkennen, dass die Folge von Bitoperatinen gleichwertig ist mit einer Look-up-table. Und das ist doch etwas viel verlangt. Außerdem ist das nur eines von vielen Beispielen.
Also meine Kritik an OpenCL ist nicht, dass man die Grafikkartenprogrammierung vereinheitlichen will. Das sollte mit etwas guten Willen seitens NVIDIA funktionieren. Was ich unrealistisch finde ist der Anspruch OpenCL auch auf x86-CPU und auf sonstigen Platformen ausführen zu können. Und eben wegen dieses "etwas" zu hoch gestecken Ziels glaube ich, dass sich OpenCL sehr schwer tun wird bzw. sich anderes entwickelt/benutzwird als ursprünglich gedacht. Also doch wieder ein Programm für jede Zielhardware (mit mehr oder weniger viel Gemeinsamkeiten). Aber das würde bedeuten, dass OpenCL gescheitert ist da ja das Ziel war genau das zu verhindern...
ex-sell
Bobo_Oberon
Grand Admiral Special
- Mitglied seit
- 18.01.2007
- Beiträge
- 5.045
- Renomée
- 190
1. Ist Khronos genau diese industrieübergreifende Plattform.
2. OpenCL ist keine Emulation, sondern eine Laufzeitumgebung und API. Richtig programmiert, dient es auch als Plattform für High Performance Rechner. Eine Emulation taugt für diesen Einsatzzweck mangels Effizienz nicht.
3. CUDA und OpenCL sind sich in vielerlei Hinsicht ähnlich. Mag sein, dass der grüne Grafikgigant nicht mit vollem Herzen bei OpenCL dabei ist. Dank Apple mussten sich die Kalifornier aber auch hier anstrengen.
Im High Performance Bereich für GPU-Computing wird aber nach wie vor gerne CUDA verwendet und ist daher auch in der Regel derzeit performanter. Dafür hat man sich aber auch auf eine proprietäre Lösung festgelegt.
MFG Bobo(2010)
Ja, es ist ein industieübergreifende Plattform. Und ich denke genau das ist das Problem. Denn den meisten Firmen dort wird es nicht gefallen wenn es einen Standard nur für GPUs gibt. Oder anders: Nur weil AMD und NVIDIA da auch dabei sind ist das nicht das gleiche wie wenn sich AMD und NVIDIA zusammen tun und einen Standard für ihre Krafikkarten entwickeln.
Ja, OpenCL will keine Emulation auf der CPU. Aber genau das ist schwierig. Denn wenn man nicht emuliert dann muss man halt doch wieder für die CPU ein eigenes Programm schreiben.
Aber letztlich ist das eigentlich auch egal. Denn es ist doch so, dass es Probleme gibt die nicht für die Grafikkarte geeignet sind. Dafür schreibt man dann sowieso ein CPU-Programm und lässte die GPU außen vor. Und dann gibt es Probleme die sich gut mit der Grafikkarte lösen lassen. Und da ist dann die CPU doch nur die "Notlösung" um das Programm auch auf Rechnern ohne passende Grafikkarte laufen zu lassen. Aber ich glaube in den aller meisten Fällen ist das wirklich nur eine Notlösung. Denn wenn man das Problem mit der CPU schnell genug lösen kann braucht man auch gar nicht erst mit der GPU anfangen. Wenn die CPU eh zu langsam ist, dann hilft einem auch eine nicht emulierte Variante für die CPU nicht weiter.
Also entweder man braucht die GPU um das Problem (schnell genug) lösen zu können. Dann kann man für die GPU programmieren und ein kaufen wenn man noch keine hat oder die CPU "reicht" für das Problem, dann brauch ich keinen Gedanken an die GPU verschwenden.
Deswegen glaube ich, dass es nicht wirlich relevant ist ein GPU-Programm auch auf der CPU laufen zu lassen (außer natürlich für Debugging usw.)
Ja, das stimmt. OpenCL hat vieles kopiert (wenn nicht alles). Aber es wird schlecht umgesetzt. Ich weiß nicht ob du schon mal ein OpenCL-Programm geschrieben hast. Aber man braucht erstmal 1000 Zeilen Code nur um an den Punkt zu kommen wo das Programm auf der Grafikkarte aufgerufen wird. Bei Nvidia geht das mit fünf Zeilen. Da recht sich einfach dieser "wir wollen alles unterstützen"-Ansatz wieder...
Das ist sicher richtig und ich denke das bleibt auch so. Und das ist auch das was ich oben meinte. Man hat ein Problem und will es lösen. Dann überlegt man ob dafür GPUs geeignet sind. Wenn ja kauft man soviel wie man braucht und schreibt das Programm. Und das natürlich so, dass es mit den GPUs läuft die man gekauft hat. Aber es wird wohl kauf einer auf die Idee kommen und sagen wir haben jetzt hier ein paar tausend CUDA-Cores, aber irgendwie mag ich lieber CPUs also kaufen wir mal schnell entsprechend viele CPUs und wollen dann das Programm ohne Änderungen laufen lassen. Das könnte nicht mal mit OpenCL funktionieren, es sei denn OpenCL kann plötzlich Threads übers Netzwerk verteilen.
Also meine Kernaussage ist: OpenCL hat sein Ziel zu hoch gesteckt (Programm auf jeder Hardware performant ausführen) und selbst wenn es irgendwann mal irgendwie funktionieren sollte bezweifel ich, dass man oft davon profitieren kann (da auch ein für die CPU optimiertes Programm langsamer ist als die entsprechende GPU-Variante - natürlich nur wenn es sich um ein Problem handelt das für eine Lösung mittels GPU geeignet ist.)
Bobo_Oberon
Grand Admiral Special
- Mitglied seit
- 18.01.2007
- Beiträge
- 5.045
- Renomée
- 190
Nur mal so zur Info. Da ist IBM ebenso dabei mit dem Cell, als auch Intel und AMD mit ihren x86-Multicore-Prozessoren. Auch dafür ist Unterstützung bei OpenCL enthalten.
Ich wunderte mich nicht, wenn da noch andere Multicore-Exoten berücksichtigt werden (Stichwort Tilera). Heutzutage ist der Übergang von GPU-Computing zu CPU-Computing fließend, weil bestimmte Chips die Vorteile des Einen mit dem Anderen vereinen.
Ein SDK, also ein Software Developer Kit, will darüber hinaus den Entwicklern etwas zur Hand reichen, damit sie schneller, übersichtlicher und effizienter (für bestimmte Chips) programmieren können.
Zeitweilig legte AMD ATIs OpenCL SDK nur für Prozessoren aus ... schauen wir mal was mit der neuen Version möglich ist.
MFG Bobo(2010)
Zuletzt bearbeitet:
Ähnliche Themen
