OpenGL - OpenCL Interaktion [gelöst]
-
Andreas XXL schrieb:
Das Coole-Neue was ich in den 3 Tagen der Suche entdeckt habe ist, dass bei CPU OpenCL Implementationen direkte printf Ausgaben aus dem Kernel heraus möglich sind. Das kann man gut für das Debuggen verwenden.
deswegen hab ich immer opencl+cuda, bei cuda funzt printf auch
ich habe auch mit meiner 560/580 probleme mit opencl, auf 460/480 laeuft es problemlos. auch der opencl 1.1 beta treiber im developer forum scheint nur fur die alte generation ausgelegt zu sein
Dravere schrieb:
In kürze wird man lachen über Crysis. Sah zwar toll aus aber selbst dort war die Umgebung immer noch statisch. Gut man kann Bäume umholzen und manchmal rennt auch nen Krebs am Strand rum. Aber in Zukunft können Landschaften richtig "lebendig" werden.
bist also noch nicht mit nem panzer durch die ganzen huetten dort gefahren, eh?
Angefangen von hunderten Fischen im Wasser bis zum Ameisenhaufen mit tausenden von animierten Insekten. Ja ganze Ökosysteme: Ganze Rinderherden die von Löwen gejagt werden, Städte mit Personen in jedem Raum, die einen richtigen Tagesablauf simulieren, Blattschneiderameisen, die ganze Bäume entblättern und die Stücke zum Nest tragen, Fledermausschwärme am Nachthimmel bei dem sogar die Positionen der Sterne simuliert werden. Die Möglichkeiten sind endlos.
lol, es waere wohl guenstiger jedem den joint dafuer mitzuliefern, statt das wirklich in ein spiel einzubauen. Content ist heutzutage das problem, nicht technik!
Auch sind die Streamprozessoren sehr beschränkt in ihrem Befehlssatz.
wie meinst du das? hast du ein beispiel? an sich hat man alle moeglichkeiten von c++
-
@rapso,
Du solltest deine Zitate etwas korrigieren, da kam wohl einiges durcheinander
Zudem wäre mir neu, dass die CryEngine bereits OpenCL oder CUDA verwendet. Ich dachte, die hätten das erst für die nächste Version in Planung.rapso schrieb:
wie meinst du das? hast du ein beispiel? an sich hat man alle moeglichkeiten von c++
Die OpenCL C Programmiersprache für die Kernel basiert auf einer eingeschränkten Version von C99. C++ kannst du in keinen der Kernel packen. Siehe dazu auf Seite 193 (6.8 Restrictions):
http://www.khronos.org/registry/cl/specs/opencl-1.1.pdfStreamprozessoren können lesen, rechnen, schreiben und das ist alles.
Grüssli
-
Dravere schrieb:
Die OpenCL C Programmiersprache für die Kernel basiert auf einer eingeschränkten Version von C99. C++ kannst du in keinen der Kernel packen. Siehe dazu auf Seite 193 (6.8 Restrictions):
http://www.khronos.org/registry/cl/specs/opencl-1.1.pdfDas ist aber eine Frage des Compilers. Der CUDA C Compiler unterstützt mittlerweile weite Teile von C++, inkl. templates, Vererbung, new/delete, virtuelle Methoden, ...
Natürlich unterscheidet sich die Art und Weise wie man GPUs programmiert stark davon, wie man CPUs programmiert. Es handelt sich eben um zwei ziemlich orthogonale Programmiermodelle. Aber rein prinzipiell braucht es nicht wirklich mehr als lesen, schreiben, rechnen und den ein oder anderen Jump, um C++ zu supporten (wenn wir mal von der Standardlibrary absehen, Dinge wie Dateizugriff machen auf der GPU natürlich keinen Sinn)
-
@dot,
Naja, man kann ja C++ eigentlich komplett in C übersetzen und von daher auch kompilieren lassen. Ist mir allerdings neu, dass CUDA C++ in den Kernels versteht. Dies könnte noch zu einem Problem für mich werden.*
Was mich aber schon etwas stutzig macht, ist die Unterstützung von new/delete. Bist du dir da sicher? Gerade bei der Speicherverwaltung, dachte ich, lägen verschiedene Einschränkungen vor.Hast du womöglich ein Dokument dazu?
Ich arbeite mich nämlich seit ein paar Wochen in OpenCL und CUDA ein. Ich nehme alles was ich lesen kann: Deutsch, Französisch, Englisch
Wobei eigentlich habe ich bereits eine riesige Sammlung von Dokumenten, welche ich endlich sortieren sollte. Ich suche immer noch das Dokument, wo drin stand, wie sich Streamprozessoren im Vergleich zu normalen CPUs unterscheiden. Irgendwo hatte ich dies doch im Detail gelesen ... bloss wo?
Edit zu *:
Ich korrigiere, es ist ein Problem. Mist!
Und sehe nun auch, dass danew
unddelete
verwendet werden. Das wird schwieriger als erwartet. Obermist!Grüssli
-
Dravere schrieb:
Gerade bei der Speicherverwaltung, dachte ich, lägen verschiedene Einschränkungen vor.
Natürlich ist so ein new oder delete, vor allem in einer derart hochparallelen Umgebung, jetzt nicht unbedingt die effizienteste aller möglichen Operationen. Aber machbar ist es.
Dravere schrieb:
Hast du womöglich ein Dokument dazu?
Wie wärs mit dem aktuellen CUDA Prgoramming Guide
Dravere schrieb:
Ich suche immer noch das Dokument, wo drin stand, wie sich Streamprozessoren im Vergleich zu normalen CPUs unterscheiden. Irgendwo hatte ich dies doch im Detail gelesen ... bloss wo?
Vermutlich im aktuellen CUDA Programming Guide
Dass sich die Architektur so einer GPU fundamental von der einer CPU unterscheidet, zweifelt ja auch niemand an. Trotzdem gibt es keinen Grund, wieso man nicht beide in C++ bzw. zumindest einem Subset von C++ programmieren könnteDravere schrieb:
Ich korrigiere, es ist ein Problem. Mist!
Und sehe nun auch, dass danew
unddelete
verwendet werden. Das wird schwieriger als erwartet. Obermist!Was genau ist denn an new und delete so kompliziert? Es gibt natürlich auch malloc() und free() :p
-
dot schrieb:
Was genau ist denn an new und delete so kompliziert? Es gibt natürlich auch malloc() und free() :p
malloc
undfree
stehen in einem Kernel in OpenCL nicht zur Verfügung. Siehe dazu den Punkt f unter Restrictions:f. The library functions defined in the C99 standard headers assert.h, ctype.h, complex.h, errno.h, fenv.h, float.h, inttypes.h, limits.h, locale.h, setjmp.h, signal.h, stdarg.h, stdio.h, stdlib.h, string.h, tgmath.h, time.h, wchar.h and wctype.h are not available and cannot be included by a program.
Ich muss eine CUDA Bibliothek nach OpenCL portieren. Hatte gestern Abend etwas Panik geschoben, als ich von euch erfahren habe, dass in CUDA C++ verwendet werden kann. Es gab leider die letzten paar Tage etwas Verwirrung über den CUDA Quellcode und habe erst vor kurzem nun den endgültigen Code erhalten. Hatte noch nicht viel Zeit den zu analysieren. In den bisher gelieferten Quellcodes wurde nur C im Kernel verwendet. Wie ich nun aber festgestellt habe, hat sich daran nichts verändert. Dafür habe ich erneut einen Unterschied zwischen CUDA und OpenCL gelernt. In CUDA tut man Host-Code und Device-Code mischen; der Kompiler wird die Trennung vornehmen. In OpenCL trennt man den Host- und Device-Code in separate Dateien auf.
Und nein, ich habe es ganz sicher nicht im CUDA Programming Guide gelesen. Bisher habe ich mich hauptsächlich mit OpenCL auseinander gesetzt. CUDA kam bisher nur am Rande zum Zug.
Grüssli
PS: Sorry für das Off-Topic hier
Aber solche Diskussionen finde ich immer wieder gut, dann kann ich mein Wissen testen und dabei etwas lernen.
-
Dravere schrieb:
@rapso,
Du solltest deine Zitate etwas korrigieren, da kam wohl einiges durcheinandersehe nichts falsches
Zudem wäre mir neu, dass die CryEngine bereits OpenCL oder CUDA verwendet. Ich dachte, die hätten das erst für die nächste Version in Planung.
hab ich auch nicht behauptet. ich sagte lediglich, dass deine auffassung nicht nachvollziehen kann, in crysis kann man sehr viel kaputt machen, nicht nur baeume.
rapso schrieb:
wie meinst du das? hast du ein beispiel? an sich hat man alle moeglichkeiten von c++
Die OpenCL C Programmiersprache für die Kernel basiert auf einer eingeschränkten Version von C99. C++ kannst du in keinen der Kernel packen.
du sprachst vom befehlssatz der streamprozessoren, nicht vom sprachumfang von opencl.
opencl ist sehr limitiert, die hardware kann weit aus mehr, wie mit cuda zu sehen ist. jeder bereich hat einen addressraum (also auch konstanten und local store), du kannst function pointer nutzen, exceptions werfen usw.Streamprozessoren können lesen, rechnen, schreiben und das ist alles.
sie koennen genau das, was die cpu deines rechners auf user ebene auch kann. du kannst dir den PTX assembler anschauen (gibt eine documentation von nvidia, leicht zu ergooglen), da wirst du nichts vermissen, denke ich.
-
Dravere schrieb:
Dafür habe ich erneut einen Unterschied zwischen CUDA und OpenCL gelernt. In CUDA tut man Host-Code und Device-Code mischen; der Kompiler wird die Trennung vornehmen. In OpenCL trennt man den Host- und Device-Code in separate Dateien auf.
du kannst auch in cuda explicit arbeiten, wie bei opencl. aber cuda bietet dir dennoch die anderen moeglichkeiten weiterhin an.
cuda 4.0 erlaubt auch eine art MPI/cluster umgebung zu nutzen, das heisst, dass du auf einer karte irgendwo im netzwerk auf die daten von einer ganz anderen zugreifen kannst, einfach ueber einen pointer, und die cuda runtime kuemmert sich um den ganzen daten sync. es ist schon ziemlich genial, man arbeitet am ende wie auf einem rechner, hat aber ein cluster versklavtUnd nein, ich habe es ganz sicher nicht im CUDA Programming Guide gelesen. Bisher habe ich mich hauptsächlich mit OpenCL auseinander gesetzt. CUDA kam bisher nur am Rande zum Zug.
lohnt sich CUDA zu lesen, opencl ist zwar hinterher, wird aber auch die moeglichkeiten bieten wie cuda (vielleicht nicht ganz vom sprachumfang, wegen kompatibilitaet, aber was addressraum usw angeht).
PS: Sorry für das Off-Topic hier
ich druecke dir die daumen dass das kein mod sieht
-
rapso schrieb:
Dravere schrieb:
@rapso,
Du solltest deine Zitate etwas korrigieren, da kam wohl einiges durcheinandersehe nichts falsches
Wirklich nicht? Ich helf dir mal auf die Sprünge: Nur das letzte Zitat war von mir, der Rest ist von Andreas XXL. Du hast zwei Zitate mir zugeordnet, obwohl sie das nicht sind.
Zum Beispiel:
ich sagte lediglich, dass deine auffassung nicht nachvollziehen kann, in crysis kann man sehr viel kaputt machen, nicht nur baeume.
Ich habe nie etwas darüber ausgesagt, was man in Crysis kaputt machen kann. Diese Aussage kam von Andreas XXL. Zudem weiss ich selber zu genüge was man alles kaputt machen kann. Mir hat die Demo mit dem Editor damals schon fast gereicht. Da hatte ich zum Teil manchmal schon ein paar Zweifel an meiner psychischen Verfassung
rapso schrieb:
lohnt sich CUDA zu lesen, opencl ist zwar hinterher, wird aber auch die moeglichkeiten bieten wie cuda (vielleicht nicht ganz vom sprachumfang, wegen kompatibilitaet, aber was addressraum usw angeht).
Werde ich definitiv machen, sobald dieses Projekt durch ist. Aber aktuell liegt der Schwerpunkt auf OpenCL.
rapso schrieb:
ich druecke dir die daumen dass das kein mod sieht
Danke. Immer diese bösen Mods von denen man sich in acht nehmen muss. Schon schlimm
Grüssli
-
Kann man CUDA und OpenCL gemischt einsetzen?
Wenn ja, wie?
-
Inwiefern willst du es denn mischen?
-
dot schrieb:
Inwiefern willst du es denn mischen?
Das prinf wäre als Debug-Ausgabe schön ^^
(Ich habe es so verstanden, das es bei CUDA auch bei GPUs funktioniert und nicht nur bei CPUs wie bei OpenCL)
-
Du kannst natürlich CUDA und OpenCL in der selben Anwendung verwenden, sind ja am Ende nur zwei Libraries. Wobei gleichzeitig CUDA und OpenCL verwenden normalerweise eher sinnlos wäre. Du kannst nicht einfach CUDA Code mit OpenCL Code mischen. CUDA läuft auch nur auf NVIDIA Karten...