Eiskaltmacher.de
Software => Programmieren und Coding => Thema gestartet von: IceCube am 02. Oktober 2006, 06:59:33
-
Hallo Leute,
Spätestens seit ich einen Conroe hab, bin ich auf den Geschmack gekommen und programmiere mit echtem Multitasking. Das ist nicht so schwer, Windows stellt alles nötige seit über 10 Jahren, seit der Einführung von Win32 zur Verfügung: Threads starten, Semaphoren, Mutexe, Warten auf Threads. Soweit so gut, kalter Kaffee für alle die sich auskennen.
Der Gag ist der Test eines neuen Programms (Giotto 2.06) auf meinem alten Win98SE-Rechner: Läuft ! Und profitiert auch vom Multithreading, obwohl Win98 ausdrücklich nur einen Core kennt. Na ja, die CPU kann ja schon mal was anderes tun, wenn woanders Daten auf die alten lahme Klapperplatte geschoben werden ...
Erkenntnis 2: Warum dieses Gehype um die neuen Dual oder sogar um die Quad cores ? Was mich erstaunt, wenn ich kleiner Hinterzimmerprogrammierer das nutzbringend hinbekomme, warum nicht dann die echten Entwicklerfirmen ? Schon jetzt gibts eine ganze Menge Standardsoftware, die von Dual core massiv profitiert: Adobe Photoshop z.B. Sogar mein alter Drucker zieht sich mit seinem verquasten Treiber (typisch HP - nie vor Einstellung des Produkts zu Ende entwickelt ...) schmollend auf einen Core zurück und stürzt dort alleine ab, ohne mich und den Rest der Software zu behelligen. Goil :nut:
Gibts hier noch andere Multithreading-programmierer, mit denen man sich mal austauschen kann ?
Gerade jetzt am Wochenende bin ich zwischen dem ganzen Quadcore-Getröte noch auf eine kleine News gestoßen, die mal sehr interessant werden könnte: ATI macht was, um GPUs, die ja nichts anders als hochparallele Einfach-Prozzies sind, allgemeine Rechenaufgaben (Vektormathe z.B.) zuzuweisen: Streaming computing nennen die das. Eine erste Anwendung gibts bereits für uns kleine Daddler: Auf ATI-Karten läuft Folding@home bis zu 30mal schneller als auf der CPU :wow:
Gibts da schon ein SDK dazu oder komme ich auch über OpenGL/DirectX dahin ?
Ich selber vermute mal eher nicht, denn DirectX ist allzusehr auf Spiele optimiert (Die Welt besteht nicht nur aus (Baller)spielen) und steht im Verdacht, eher erstmal die MMX und SSE-Befehlssätze der CPU zu nutzen und nur auf die hochparallelen GPU-Resourcen zuzugreifen, wenn ganz spezielle Outputfunktionen gefragt sind ...
Weiß hier jemand mehr ?
Stay tuned, IceCube
-
Hallo Leute, einen Brückentag Recherche und schon ist man schlauer - was ich über eine kleine unscheinbare HeiseTickermeldung http://www.heise.de/newsticker/meldung/78948 (http://www.heise.de/newsticker/meldung/78948) erfuhr, ist mehr als einen edit meines Anfangsposts wert gewesen !
... Zuerst erfuhr man in der Tickermeldung, daß nVidia-Chips Programme von maximal 64k Länge abarbeiten können (etwas, was in den einschlägigen Ballerspielen natürlich nicht erreicht wird, aber echte Rechenanwendungen sehr schnell begrenzt ...), ATi kennt hier keine Grenzen ...
Hier gibt es das ersehnte SDK zur GPU-Programmierung aus eigenen Programmen heraus, eine spezielle C-Spracherweiterung namens Brook: http://graphics.stanford.edu/projects/brookgpu/index.html (http://graphics.stanford.edu/projects/brookgpu/index.html). Brook wird mit einem Art Linux-Aufsatz namens cygwin auf Windows verwaltet und erzeugt dann C++ Code, der mit VisualC++ 6 oder besser 7 in Code umgesetzt wird und per DirectX bzw OpenGL direkt an die GPU geht - Also doch !
Das schöne an Brook ist das sehr klare und einfache Konzept. Ebenso gut ist auch die Beschreibung, wie das alles funktioniert und die einem alles Schritt für Schritt erklärt und nach der man (im Gegensatz zu dem irre überladenen und ziemlich wirren DirectX) sehr straight forward abarbeiten kann. :thumbup:
Grundlage von Brook sind Datenstreams, die man von C aus lädt die Streams dann an Operationen namens kernel vergibt und sich dort dann das Ergebnis wieder abholt, die GPU als klassischer Coprozessor. Die Daten sind dabei Vektoren, Vektorarrays (3D-Objekte z.B.) oder ganze Felder (Bilder zum Beispiel). Ums Parallelisieren braucht man sich nicht zu kümmern, das erledigt Brook für einen. Damit haben wir einen ganz entscheideneden Unterschied zur klassischen Multitaskingprogrammierung in der CPU: dort muß alles von Hand geschehen, aber dafür sind auch die Daten universell. ... aber das braucht man ja eigentlich eher selten, zumeist sind die Daten zwar Massenhaft, aber vom Typ völlig gleich ....
So neben bei gibts auch ne Menge Beispielcode, der mal echt wertvoll werden kann wie FFT und so. Und alles ist OpenSorce und unterliegt der GNU Public License. Ich brenne schon drauf, mit ein paar zeilen Probiercode meiner GPU was zu tun zu geben und bin auch echt mal auf die tatsächlichen Unterschiede zwischen ATi und nVidia aus Programmierersicht gespannt.
Begeistert und sehr auf die ersten Resultate gespannt, euer IceCube :cool:
-
Bin auch gespannt über die Resultate.
Ich hätte übrigens nach dem Lesen des ersten Postings geschrieben, dass OpenGL sowas nicht kann. Ok, ist natürlich Quatsch wie aus dem 2. Posting hervor geht, micht interessiert aber wirklich in welcher Geschwindigkeit das geht, denn Grafikkarten sind eigentlich nur One-Way und vor dem anderen Weg wird immer gewarnt.
... Zuerst erfuhr man in der Tickermeldung, daß nVidia-Chips Programme von maximal 64k Länge abarbeiten können (etwas, was in den einschlägigen Ballerspielen natürlich nicht erreicht wird, aber echte Rechenanwendungen sehr schnell begrenzt ...), ATi kennt hier keine Grenzen ...
Ok, du redest hier von der X1900-Reihe, ansonsten wäre ich schon etwas erstaunt, da alleine bei Shader 2.0 ne Grenze existiert, die manche Shaderentwickler anscheinend schon durchbrechen, ansonsten sehe ich nämlich keinen Vorteil für Shader 3.0 :|
Aber lass was hören IceCube!
Das Thema Threading interessiert mich total, einfach weil ich leider nie weiss was ich in Threads "abschieben" kann :(
-
Bei der Multythread Programmierung werden schon lange Forschungen betreiben. Wie man sehen kann beherrschen dies Technik schon seit Ewigkeiten Video bearbeitungs- oder Rander- Software.
Bei diesen Anwendung kann man technisch unendlich viel Threads Parallel abarbeiten.
Bei Spielen jedoch gibt es im Klassischen Sin ein gewaltiges Problem die Abhängigkeiten zueinander. Da bei Spielen alles in Echtzeit stattfindet muss jede Parallelisierte Aufgabe Synchronisiert werden. Dabei entsteht na menge abglich arbeit.
Derweil sind momentan Ansetze einzelnen Abläufe in der Simulation auf 2 oder 4Cores vorzubereiten, jedoch werden bei der Programmierung, bei einer 8 Kern CPUS wider 4 brachliegen. Vorteil der Code ist von 1 Kern CPU´s noch normal abarbeitbar.
Die Lösungen bestechen schon zur Unendlichen Threads in einer Simulation. Grob Friert man die Simulation ein arbeitet Parallel alles ab und fährt fort mit dem Ergebnis. Problem momentan würde die Simulation jede 1 Sekunde stehen bleiben. Dieser alten standard müsste man aushebeln. Weiters Problem 1 Kern Chips währen mit dieser Aufgabe überfordert. Deswegen scheuen noch die Software Firmen diesen Sprung da momentan noch zu wenig echte Multythread Chips auf dem Markt sind.
Sobald der Grosteil der Zocker 2oder mehr Kern Chips zuhause hat, werden wohl die Spiel Firmen den Sprung wagen.
-
Derweil sind momentan Ansetze einzelnen Abläufe in der Simulation auf 2 oder 4Cores vorzubereiten, jedoch werden bei der Programmierung, bei einer 8 Kern CPUS wieder 4 brachliegen. Vorteil der Code ist von 1 Kern CPU´s noch normal abarbeitbar.
Hi, ich kann dich beruhigen ... keine Cores werden brachliegen, denn ...
... es sollte völlig wurscht sein, wieviele Cores da arbeiten. Die Kunst ist eher die, die Aufgabe so zu zerlegen, daß möglichst viele parallele Prozesse entstehen, die aber während der Abarbeitung möglichst wenig mit einander reden müssen. Etliche Probleme lassen sich ganz wunderbar zerlegen wie z.B. Codecs, Bildbearbeitung, Rendering, weil hier millionenfach dasselbe zu tun ist.
Bei Spielen ist das anders: Hier gibt es sehr unterschiedliche Aufgaben wie die Szenen nachladen, die 3D-Figuren berechnen, die Physik und das Bildrendering. Diese Einzelaufgaben müssen sehr stark miteinander kommunizieren, daher lassen sie sich nicht beliebig zerlegen (noch ...) Man kann davon ausgehen, daß Spieleprogrammierer sehr erfahrene Leute sind, die das sehr genau wissen: Es ist halt noch einiges an Forschungsarbeit nötig, weil es erst seit ganz kurzer Zeit Multicore-CPUs und damit überhaupt Bedarf für echtes Multithreading gibt.
Aber einerlei, die CPU-Zahl ist beim Multithreading erstmal egal.
Wenn sehr viele parallele Cores (wenn auch nur für sehr einfache Brerechnungen) wie beim R580 zur Verfügung stehen, dann muß man sich natürlich Gedanken machen, allen diesen Cores in etwa gleichzeitig und gleichlang was zu tun zugeben.
Was uns zu ein paar Grundregeln des Multithreading führt:
A) Zerlege ein Problem so, daß die Abarbeitung eines Teils in etwa gleich lange wie die anderen Teile dauert und daß während der Abarbeitung keine Teile Informationen von anderen brauchen.
B) Das geht entweder ganz oben, wenn zwei Programme parrallel laufen (Multitasking, es müssen soviele parallele Programme wie CPUs da sein, was etwas unrealistisch ist ...) oder wesentliche Teilbereiche von Programmen einzelnen CPUs zugeordnet werden wie z.B. bei Spielen angedacht (Vorsicht: skaliert sehr inflexibel, hier wär dein Verdacht, zusätzliche CPUs liegen brach, berechtigt)
C) Das geht ganz unten, wenn man wirklich eine Berechnung in viele winzige Partikel zerlegt wie z.B. beim Bild berechnen: da werden alle Pixel gleich behandelt, es skaliert somit solange bis ein Core pro Pixel zur Verfügung steht. Hier sehe ich für die Spieleentwicklung (wenns denn sein muß, ich habe mit den derzeitigen Spielen nix am Hut ...) genügend Ansatzpunkte, soviele in etwa gleichdauernde Teilprobleme zu erzeugen, daß die Anzahl der realen CPUs bei weitem überschritten wird.
D) Multithreading erfordert ein neues Denken wie man eigentlich vorgeht, das ist eigentlich das einzig wirklich schwierige (oder besser neue )daran: Es ist wie auf dem Bau: Früher mit einer CPU hat man mutterseelenalleine vor sich hin gebaut, heute ist man die Bauleitung, die zig Gewerke parallel synchronisieren muß.
Fangen wir mal gaaaaaanz einfach an: Eine R580 GPU z.B. enthält 48 sehr primitive Single Precision Cores, die 48 mal dasselbe ganz parallel erledigen kann... Und dafür genau ist die C-Erweiterung Brook gut. Ich hab jetzt die Chance, wirklich rattenschnell nach Mustern in Bildern zu suchen oder Bilder gleichzeitig zu drehen und zu entzerren (ja ja, das verdammte Prob mit den rechteckigen Pixeln ...) Und zwar so, daß ich das auch noch verstehe ... :think:
-
Fangen wir mal gaaaaaanz einfach an: Eine R580 GPU z.B. enthält 48 sehr primitive Single Precision Cores, die 48 mal dasselbe ganz parallel erledigen kann... Und dafür genau ist die C-Erweiterung Brook gut. Ich hab jetzt die Chance, wirklich rattenschnell nach Mustern in Bildern zu suchen oder Bilder gleichzeitig zu drehen und zu entzerren (ja ja, das verdammte Prob mit den rechteckigen Pixeln ...) Und zwar so, daß ich das auch noch verstehe ... :think:
Das mit dem verschiedenen "Cores" war ja 'schon immer' so. Einem Pixelshader ist es egal wie die anderen Pixel aussehen bzw. ob an denen schon gerechnet wurde. Sowas kann man natürlich sehr einfach parallelisieren.
Beim Vertexshader sieht es zwar wieder anders aus, aber wenn man grob genug rastert bekommt man keine Probleme wegen Überschneidungen.
Bei der Mustersuche musst du mir aber erklären, wieso das auf der GPU schneller ist. Skalieren bzw. Rotieren ist ja eine standardaufgabe bei Spielen, nur sind die Algorithmen auf Geschwindigkeit und nicht Qualität optimiert.
-
Hi i0n0s
Man muß sich von der Vorstellung lösen, daß die GPU einer Grafikkarte alleine für die Grafik gebauit ist, gut dafür ist sie im wesentlichen programmiert, aber 32-Bit-Floatingpoint bleibt dasselbe, ob nun Pixel, Vektoren (Vertexe sind Flächennormalen, also auch Vektoren, die senkrecht auf Flächen stehen) oder sonstwas inhaltlich dahintersteht. Der Gag am Streaming ist, parallele FP-einheiten wie Pixelshader halt für allgemeine Aufgaben rechnen zu lassen.
Speziell bei der Mustererkennung kommt dazu eigentlich nur Multiplikation und Addition von Zahlen, hier aber extrem massenhaft in Frage: für jede Bildkoordinate muß die 2D-Korrelation mit dem Muster berechnet werden - das ist ein 4dimensionales Prob: 2 für x und y-Koordinate im Bild und dann Höhe und breite vom Paßmuster. Man kann den Stream zur GPU so konfigurieren, daß jedes Streamelement halt ein Ausschnitt aus dem Bild an verschiedenen Koordinaten ist, die dann von einander unabhängig parallel mit dem festen Paßmuster verglichen werden. Jeder Pixelshader rechnet statt Pixel dann halt die Korrelation aus - soviele gleichzeitig parallel, wie halt Shader da sind. Weil hier nur simple Grundrechenarten gebraucht werden, kann das jeder Shader nach Shadermodell 3.0 (ab dann werden 32-Bit-Floatingpoints unterstützt) erledigen.
Wichtig ist, daß Brook die Interfaces von DirectX und OpenGL so verallgemeinert, daß man einheitlich programmieren kann - eben in der C-Erweiterung Brook ...
-
So, der nächste Erfahrungsbericht ist mal fällig:
Ich habe mit Müh und Not endlich Brook auf meinem Rechner installiert - aber so recht laufen will es nicht.
Die Doku, die mit dem Download kommt, ist mehr als dürftig, aber es gibt ein recht reges Forum, wo einem dann die elementarsten Klippen und den dazu passenden Work around erklärt werden: http://www.gpgpu.org/forums/
Ein Besuch dieses Forums, insbesondere des Anfängerteils, ist absolut notwendig, denn ich habe so ziemlich jeden Fehler gemacht, den man als Newbee in Brook machen kann. Erfahrung 1: Brook ist etwas, was auf speziell konfigurierten Rechnern mit einem bestimmten C-Compiler (Visual studio.NET 2003) dann funktioniert, wenn man sich auch in Linux ziemlich gut auskennt und etliches selbstverständlich ist.
Ich habe nur sehr krumpelige Linuxkenntnisse und mit Visual Studio 2005 einen zu modernen Compiler. Was ich mit bis jetzt andauernden Inkompatibilitäten in irgendwelchen völlig zweit- und drittrangigen Headerdateien habe, die mit dem eigentlichen Streaming nichts, aber auch rein garnichts zu tun haben.
Na ja, wenigstens kann ich die Beispiele aus dem sehr knappen und völlig mangelhaften Tutorial wenigstens kompilieren und linken, aber nicht ohne Zwang, wie doppelte Defines ignorieren und so - und somit stürzen etwa 2/3 der Beispiele ab ... :nixweiss:
Brook zum laufen zu bekommen, ist ausgesprochen mühsam, weil es völlig unterdokumentiert ist und auch niemand Zeit hatte, es hinreichend plattformunabhängig zu machen - es macht noch einen sehr neuen, unreifen Eindruck ...
Und das isses ! Das ist vergleichbar wie in den Zeiten der 0.x Kernel von Linux ! Wer Pioniergeist hat, etwas Ausdauer und wenn man hinreichend Englisch kann fürs Forum, dann kommt man weiter und kann mitforschen. Im GPGPU-Furum herrscht jedenfalls ein wirklich sehr hilfbereiter und freundlicher Ton vor, das ist sehr angenehm. :prost:
So allmählich packt mich der Ehrgeiz. Zu prüfen ist allerdings, ob man mit der direkten DirectX-Programmierung nicht genauso ans Ziel kommt, DirectX lief bei mir fast auf Anhieb :D Wer glaubt, DirectX sei nur zur Grafikprogrammierung da: Mintnichten, dazu wird es nur genutzt, aber z.B. eine Vierermatrixmultiplikation (ausgeführt in den Vertexshadern ...) ist ganz allgemein einsetzbar, denn das Ergebnis landet ja zunächst wieder in der CPU.
stay tuned, IceCube
Edit: gerade eben entdeckte ich weiter oben iOnOs berechtigte Frage nach den Shadermodellen: Natürlich muß es Shadermodell 3.x sein, das bedeutet 32 Bit-Floatingpointmathe in den Pixel- und Vertexshadern. Es gab vorher auch schon 24 und 16Bit-Floats, aber da ist der Wertebereich und die Auflösung zu stark eingeschränkt, als daß so alte GPUs sinnvoll allgemeine Ergebnisse liefern könnten.
-
ih DirectX :P
/me versucht sich lieber an OpenGL, hat aber auch andere Ansprüche ;)
Zu der Dokumentation kann man leider sagen, dass das bei vielen Projekten der Fall ist. Ich selber kenne kaum ein nicht kommerzielles Projekt, dass eine gute Dokumentation hat oder selbsterklärend ist.
Meistens hilft da wirklich nur ein Forum oder die Maillinglist.
Die Ursache des Problemes kenne ich aber auch :redface:
Als Programmierer läuft es bei einem und dann wird es auch bei anderen laufen ;)
-
icecube, hast du mitlerweile schon erste erfolgserlebnisse? es hört sich ja spannend an, massiv-parallele Programme laufen zu lassen, und sogesehen mit einem 300Euro-Prozessor jeden c2duo um faktor 10 und mehr wegstecken zu können
-
Hallöle, da bin ich wieder ...
Es geht sehr langsam vorran, aber ich habe ja auch nicht immer Zeit.
Das ganze GPGPU-Geraffel habe ich erstmal in eine DLL ausgelagert, die jetzt schon sehr schön läuft und DirectX 9.x meldet sich auch brav und zickenfrei.
Ich habe mir daraufhin erst mal nen halben Kubikmeter Fachliteratur über 3D-Grafik zugelegt und angelesen. Es gibt nämlich 3 Wege, zu GPGPU zu kommen:
1) per Brook wie kurz mit nicht so prallem Erfolg angetestet: Brook ist sehr unreif und enthält zuviele Versionstücken, die mit dem eigentlichen "streaming computing" eigentlich nichts zu tun haben, nämlich sich beißende Headerdateien und den unnötigen Zwang, unglaublich viel Zusatzgeraffel aus der Linuxwelt auf einen Windoof-Rechner zu zwängen.
2) per OpenGL direkt. Brook setzt seinen allgemeinen Code ja nur per Precompiler in ganz normales C um, das dann wieder über Cg, Open GL und DirectX die GPU anspricht. Also warum OpenGL nicht direkt von Hand ?
3) per DirectX direkt (siehe unter 2) )
Eigentlich bin ich ja eher für OpenGL, aber es wird gemunkelt, Vista würde kein OpenGL mehr unterstützen, was ich wiederum nicht so glaube, denn da steht die mächtige CAD-Lobby hinter und deren Knete nehmen die Borg auch gerne. Erfreulicherweise ist aber DirectX sinngemäß praktisch dasselbe, denn die Grafik-Mathe ist ja unabhängig davon. Nur mußich jetzt so die Kurve kriegen, die eigentliche Operation in OpenGL bzw. DirectX so zu begreifen, daß sie auch mit Daten rechnet, die eigentlich garkeine Grafik ist.
Ein Beispiel: Man bekommt z.B. eine Mustererkennung per Korrelation so hin, indem man die Berechnung der Korrelation geschickt in viele, sehr einfache Shaderbefehle zerlegt, die dann affenschnell (weil hochparallel) in der GPU abgearbeitet werden. Daher die viele Literatur, damit ich diese Op-Mosaiksteinchen kennenlernen kann.
Ach wenn Brook nicht dermaßen kratzbürstig wär :roll:
Ach ja: Seit wenigen Tagen hab ich zum Testen eine ATI X1950XTX mit standesgemäßer WaKü. geht ab wie Schmitz Katze, eine Wucht :thumbup:
stay tuned, IceCube
-
Hi Loidz
Wieder ein statusbericht meiner Experimente ...
... aber vorher erstmal einen ganz herzlichen Dank an die Eiskaltmacher vom Treffen in Babtown. Das ist wirklich toll, wie ihr mir Mut zu sprecht: "Du bist der einzige, der eine HighEnd-Grafikkarte kauft, um nicht damit zu spielen !" :redface:
Die Leute die da waren, wissen, warum es derzeit etwas langsamer geht ... aber ganz stillstehen tut das Projekt GPGPU denn auch nicht. Den Weg über DirectX/OpenGL zu gehen und auf das wesentlich allgemeinere Brook zu verzichten, ist auch nicht so prall: Beide, DirectX und OpenGL, sind eben doch sehr auf 3D-Grafik getrimmt, eine Verallgemeinerung ist nur sehr mühsam möglich.
Das führt in eine Zwickmühle: Ich könnte mir mal Cg anschauen, aber da weiß ich schon, das stammt von nVidia, läuft also weniger gut bis garnicht mit ATI-Karten. Und das ATI SDK macht meine Weichware halt rein ATI-abhängig - Diesen Weg sind übrigens die Treiberprogrammierer gegangen, irgendwie ist die ForceWare und der Catalyst ja auch mal programmiert worden.
Aha, so bekomme ich also so langsam Einblick in die (Un)Tiefen der Grafiktreiberindustrie.
Da will ich aber nicht so wirklich hin. Mir schwebt eher was allgemeines vor, das dann auf einen hardwareunabhängigen Layer aufsitzt und dem's dann wurscht ist, ob da ne ATi oder 'ne nVidia bullert. Schade, daß Brook so miserabel läuft ...
Fürs erste gehe ich aber weiter den zähen Weg, wenigstens einige Fetzchen DirectX/OpenGL für meine allgemeinen Zwecke umzubiegen.
Hmm, dabei ist die Zukunft doch eher rosig ! Zumindest AMD/ATI denken schon sehr laut über GPGPU nach, da wär dann schon mal ein SDK zu erwarten ... Ich kann mir vorstellen, daß nVidia da sich nicht lumpen läßt. Immerhin bietet die Chipschmiede aus Kalifornien schon ein registrierungspflichtiges SDK für die neuen G80-Chips an, aber das ist mir dann doch zu speziell. Genau wie der Weg über AGEIA, die mir doch recht schnell Zugang zu ihrem SDK gewährt haben, aber wo man halt ne teure PhysX braucht, die sonst eher weniger Nutzen zeigt ... Irgendwie kommt mir das vor, daß man sehr gerne über GPGPU spricht, aber es gibt einfach noch keine Standards.
So, jetzt fehlt eigentlich mal, das ich irgend ein laufendes Codefetzchen präsentieren kann :roll:
Schaun wer mal, euer GPGPU-IceCube
-
*subscribe*
-
Hallo ClaasM, Hallo alle !
Na bitte, wenn man lange genug sucht: Es gibt eine Alternative zu Brook, nämlich Sh.
Brook als spezielle Metasprache zu C++ läuft ja derzeit nur in einer ganz speziellen Konfiguration aus einem Wust von Compilern, Linux-Tools (unter Cygwin), das alles wieder unter Windows usw und stürzt bei 2/3 aller Beispiele ab, weil sich irgendwelche Header aus dem C++ System versionsweise beißen, die garnichts mit der GPU-Programmierung zu tun haben. Kurz: Brook sux.
Bei Sh scheint das alles ganz anders zu sein. Sh ist nichts anderes als eine plattformunabhängige Library für C++, die als DLL unter Windows zur Vefügung steht und die etliche GPU-Streamingfunktionen für normales C++ verfügbar macht. Da Sh nur eine Library ist, dürfte das Chaos wie bei Brook erst garnicht aufkommen. Erfreulicherweise ist eine DLL nämlich völlig compilerunabhängig.
Nähe Infos in Form einer FAQ-Wiki gibts hier: http://libsh.org/wiki/index.php/Frequently_Asked_Questions
Ich werd' mir mal Sh downloaden, mir eine Testinstallation machen und die Doku gemütlich reinziehen, Brook schmeiße ich von der Platte, eh ich mich damit noch weiter abmühe. Weshalb ich Sh plötzlich interessant finde: Es nimmt mir die Verallgemeinerung von OpenGL und DirectX ab. (Beides läuft in meiner Programmierumgebung übrigens geräuschlos glatt)
Na bitte, ich hatte es geahnt, das Brook als UNI-Labor-Gestricke doch einigen Praktikern, die wie ich mal zum Ziel kommen wollen, zu wirr war ...
Sh hat für nichtkomerzielle Programmierer den Vorteil, OpenSource zu sein ... :biggrin:
Also weiter auf dem kurvenreichen Weg zu GPGPU, :prost: IceCube
-
echt respekt IceCube :respekt:
ich hab mir alles doppelt und dreifach durchgelesen...und zu 50% versteh ich nur :blabla:
ich beschäftige mich aber mehr damit, weil schon allein der gedanke seinen rechner zu "tunen" (ohne OC) sehr interessant ist!
-
Doch von mir auch.. so software tüfteleien liegen mir garnicht, aber mein technisches Verständnis schafft es immerhin da die Brücke zu schlagen. Hab mir schon öfters Gedanken in der Richtung gemacht, und nach dem entdecken dieses Threads weiß ich nun auch, dass ich mit eben diesen garnicht so falsch lag.. auf alle Fälle ist das sauinteressant, und ich bin echt gespannt auf die ersten Proggis von Dir die GPGPU richtig nutzen ..
-
http://www.heise.de/newsticker/meldung/85475 (http://www.heise.de/newsticker/meldung/85475)
Sieht aus als würde Nvidia dir zuvorkommen und schon etwas entsprechendes veröffentlichen.
-
Zu CUDA (siehe Link im vorherigen Posting) ist ein Tutorial erschienen:
http://www.opengl.org/news/permalink/cuda_opengl_tutorials/ (http://www.opengl.org/news/permalink/cuda_opengl_tutorials/)
-
Hi Leute,
CUDA kenne ich seit es das gibt. Ist aber uninteressant, weil zu hardwarespezifisch. CUDA läuft nur mit den G80 Chips von nVidia.
Aus demselben Grund ist auch das ATI-SDK uninterresant. Ich will ja keine Software für ATI oder nVidia entwickeln, sondern für Grafikkarten.
... ich bin aber fündig geworden: Sh ist der Weg
Problem ist nur, daß mir Familie (Zuwachs im Anmarsch), Hausbau und die Endphase meiner beruflichen Sasion (im Fortissimo) mir wenig bis garkeine Zeit lassen, mich mal in Ruhe mit Sh zu beschäftigen. Sh sieht aber sehr straight forward aus und ist sehr schön verständlich. Zudem noch Open Source, also auch gut gepflegt.
Stay tuned but be patient :D Euer IceCube
-
Dann gratulieren wir euch schonmal für den Familiennachwuchs und hoffen auf ruhigere Zeiten ;)
-
Dürfen wir Namensvorschläge posten?
-
Dann gratulieren wir euch schonmal für den Familiennachwuchs und hoffen auf ruhigere Zeiten ;)
Ich schließe mich dem an! Gratulation! :thumbup:
Zu den Namesvoraschlägen:
Junge: Max, Tom, Robert :D
Mädchen: Maria, Anna, Maya
Hmm, die fallen mir spontan ein und gefallen mir ;)
mfg Robert
-
Congratulations..
Soweit sind wir noch nicht ..
aber alles gute^^
-
Hallo Leute,
Ich bins tatsächlich, der IceCube, der wieder aus den Nebeln des Nichts entsteigt und die Babypause so langsam beendet.
Mittlerweile ist ja ein Jahr ins Land gegangen und es hat sich auf dem Gebiet der GPGPU etwas getan, das Thema ist in aller Munde. Meine Experimente haben bislang wenig bzw. frustrierendes erbracht: "Brook" habe ich zwar zum Laufen gebracht, aber 2/3 der Beispiele stürzten ab, das ganze war wohl eine Stand Alone-Lösung einer Uni, wo die Protagonisten fertig mit ihrem Doc und damit verschwunden sind und keiner mehr den Ball auffängt.
Das selbe mit Sh, das als großes open source-Projekt begann und dann mit dem Schritt zur Komerzialisierung lautlos unterging. Schade, der Ansatz war genial.
Bleibt CUDA von nVidia, was verständlicherweise nur auf nVidia GPUs läuft, dafür aber gut dokumentiert und verfügbar und auch (einigermaßen) universell ist.
Der Riese aus Redmond ist allerdings aufgewacht und gedenkt, eine weitere Idee, wie immer etwas spät, unter seine nimmersatten Fittiche zu nehmen: Es gehen immer wieder Gerüchte, daß DirectX11 Elemente für den allgemeinen, hochparallelen Gebrauch der Shader in einer GPU enthält.
Einerseits liebe ich M$ nicht wirklich, andererseits wär das schon toll: M$ ist es nämlich egal, ob das alles auf ATI oder nVidia läuft, die absolut notwendige Hardwareneutralität wär hergestellt. Natürlich ist zu erwarten, das dazu das eklige Vista Mindestvorraussetzung ist (was wiederum den erfolg in Frage stellt), na ja, warten wir auf Windows 7, vll. macht M$ ja mal Hausaufgaben und erweist sich als lernfähig, denn der Stern sinkt schon ...
Die informatischen Ansätze von DirectX11 sind den Gerüchten nach dieselben wie bei meinem leider verflossenen Favoriten Sh: Sh war so genial programmiert, daß allgemeine Aufgabe in Shadersequenzen umgeformt wurden, eine sehr abstrakte Sache, aber sie wurde im einzigen brauchbaren Buch zu Sh erläutert. Dennoch, wegen der Komerzialisierung (Bitte zahlen Sie 2500,- $$$$) ein Selbstabschuß. Denn wegen der relativen Unbekanntheit von Sh hat das natürlich niemand getan.
Soweit der Status, ich bleib hat dran, denn GPUs als hochparallele Coprozessoren einzusetzen, ist einfach sexy
Viele Grüße, euer IceCube