Rechnen mit der GPU

[Rociel]

Hi,

ich hab im Netz schon gesucht, aber nicht wirklich was gefunden. Ich suche zur Zeit eine Möglichkeit mathematische Probleme in Delphi schneller zu lösen, und zwar mit der GPU. Nun wollte ich gern wissen, ob jemand von euch eine Möglichkeit kennt über eine Unit/DLL parallelisierbare Berechnungen auf die GPU auszulagern und zwar ohne dass man sich selber um die Parallelisierung kümmern muss. Sprich zum Bleistift:

Teile jedes Item eines Arrays durch die Zahl 2.

Ich hoffe jemand von euch kann mir n paar Tipps geben.

Vielen Dank schonmal im Vorraus!

[blackfin]

Mhm, hast du dir schon OpenCL angesehen?
Da gabs auch ein Delphi-Beispiel im Emba-Forum:

https://forums.embarcadero.com/threa...threadID=22455

nVidia hat z.B. eine OpenCL-Implementierung in ihren aktuellen Treibern drin, die wrappen das dann intern auf deren CUDA.

Es gibt auch ein Projekt dazu, Delphi-OpenCL:
https://code.google.com/p/delphi-opencl/downloads/list

[himitsu]

Zitat:

Teile jedes Item eines Arrays durch die Zahl 2

shr 1 in der CPU wäre wohl ausreichend und vielleicht sogar schneller :lol:

(Tschuldschung, aber ich konnte grade nicht anders)

[rollstuhlfahrer]

Vielleicht noch ein kleiner Hinweis für die Benutzung der GPU: Eine GPU Recheneinheit kann sehr sehr viele Threads verwalten. Aber alle Threads teilen sich den gesamten GraKa-Speicher. Wenn du also eine GraKa mit 512 MB Speicher hast und 1024 Threads dann hat jeder Thread nur 512 KB an Speicher benutzen. Da in der Praxis die Threadanzahlen weit höher liegen, wird der Speicher pro Thread immer kleiner. Selbst die MD5 von sehr vielen Strings zu berechnen läuft auf einer CPU schneller, da der Berechnungsthread immer auf die Ergebnisse der vorherigen Operation warten muss.

Grundsätzlich ist für die GPU nur geeignet, was viel Rechenleistung braucht, aber nicht viel Speicher dazu. Und da die GPU sehr viele Threads unterstützt sollte der Code auch besonders gut multithreadfähig sein.

Bernhard

[Micha88]

Zitat:

Es gibt auch ein Projekt dazu, Delphi-OpenCL:
https://code.google.com/p/delphi-opencl/downloads/list

Bei mir ist die Datei "Direct3D10.pas" nicht vorhanden, wird aber benötigt.

Also generell kann man das nicht kompilieren,. da hier eine Datei fwehlt, da eine DPR kaputt ist usw.

Gibt es kein e sehr sehr einfache Demo? Eine Demo, auf das Minimum reduziert? ohne unnötige Uses-Einträge.

Sprich: "Rechnen mit der GPU"? Einfach das, was vorher die CPU machte nun auf die GPU bringen.

[blackfin]

Die Direct3D10.pas dürfte nur ein DirectX-Header sein (wobei ich nicht verstehe, warum gerade OpenCL DirectX brauchen sollte..)
Schau mal auf dein System, ob du evtl. eine D3DX10.pas hast, die dürfte evtl. passen (ausprobieren).

Zitat:

Einfach das, was vorher die CPU machte nun auf die GPU bringen

Das geht per se nicht, da eine GPU schonmal ganz anders aufgebaut ist und die Routinen nur dann wirklich gut skalieren, wenn sie massiv parallelisierbar sind. Sprich: Einfach einen CPU-Code 1:1 auf die GPU mappen geht nicht.

[Micha88]

Delphi-Quellcode:

Schau mal auf dein System, ob du evtl. eine D3DX10.pas hast, die dürfte evtl. passen (ausprobieren).

Die existiert nicht. Hatte ich vorher schon gecheckt.

1:1 möchte ich den Code nicht portieren. Dass ich den anpassen und erweitern muss, ist mir klar. Aber mit der Demo vom Emba-Forum komme ich nicht klar. Es hagelt gerade zu nur Exceptions (ich habe eine ATI).

[divBy0]

Schau dir doch das hier mal an. Link! Vielleicht hilft es dir ja weiter.

[Micha88]

Genau das nutze ich im Moment.

http://www.delphipraxis.net/164435-f...ml#post1135854

[Sougetsu]

moin,

wollt mal hören ob sich in der Richtung hier was getan hat in den letzten 2 Jahren.

Wäre über das berechnen über die GPU auch interessiert, vorallem ob man damit gut Dateien ver/entschlüsseln kann.
Mit gut meine ich natürlich zuverlässlich und schnell.

Die GPU kommt auf wesentlich mehr Gigaflops als eine CPU.
Dafür ist der Speicher eine Graka eher begrenzt.

Wär toll wenn hier einer damit schon Erfahrungen sammeln konnte.

LG
Sougetsu

[Der schöne Günther]

Wer hier im Forum regelmäßig Zahlen mit CUDA oder OpenCL cruncht weiß ich nicht, aber die "OpenCL for Delphi"-Seite der Brno-Universität ist doch praktisch brandaktuell?

http://lab4.fme.vutbr.cz/heatlab/OpenCLforDelphi.html

Ich habe irgendwie verpasst, dass nVidia mit auf den OpenCL-Zug gesprungen ist. Ich hätte gedacht, die halten stur an ihrem geschlossenen CUDA fest. Toll, dass sich das geändert hat. Schade nur dass ich privat keine aktuelle Grafikkarte habe. Irgendwie hätte ich auch Lust darauf, nur so zum Spaß 8-)

[rollstuhlfahrer]

Zitat:

Zitat von Sougetsu (Beitrag 1234619)

Wäre über das berechnen über die GPU auch interessiert, vorallem ob man damit gut Dateien ver/entschlüsseln kann.
Mit gut meine ich natürlich zuverlässlich und schnell.

Für die Ver-/Entschlüsselung würde ich eher die AES Erweiterung der CPU verwenden. Die haben ein paar Vorteile: sie sind geprüft und schnell genug, dass man den RAM schneller verarbeiten kann als lesen/schreiben.

Grüße
rollstuhlfahrer

[Sougetsu]

jup ich will das auch eher als sport betreiben, weils halt spannend ist die gpu fürs berechnen zu nutzen.
und was bietet sich da besser an als eine ver/entschlüsselung mal zu programmieren wo byte hin und her berechnet werden.


naja mir schwebt da schon so ne starke verschlüsselung mit rsa 2048bit vor.

LG
Sougetsu

[BUG]

Zitat:

Zitat von Sougetsu (Beitrag 1234630)

jup ich will das auch eher als sport betreiben, weils halt spannend ist die gpu fürs berechnen zu nutzen.
und was bietet sich da besser an als eine ver/entschlüsselung mal zu programmieren wo byte hin und her berechnet werden.

naja mir schwebt da schon so ne starke verschlüsselung mit rsa 2048bit vor.

Ich habe irgendwie den Eindruck, dass du weder mit der GPU noch von Verschlüsselung besonders viel Erfahrung hast :mrgreen: Ich auch nicht.
Insofern finde ich das eine etwas unpraktische Wahl. Es sicher eine spannende Aufgabe, eines der Paper über parallel RSA nach-zu-implementieren; aber als Einstieg vielleicht nicht das Beste.

Als Einstiegsprojekt wäre afaik etwas geeignet, was einfach zu verstehen ist: zelluläre Automaten (zB. Game of Life), einfache Simulationen (Schwärme, Sonnensystem, Partikel).

[Blup]

Wie weiter vorn schon erwähnt, ist Verschlüsselung vom Prinzip eher ungeeignet für die GPU.
Für diesen Anwendungsbereich scheinen mir FPGA interessanter zu sein.

[Sougetsu]

Moin,

naja es ist schon zweckemfremdet, aber gehen sollte es.
Gibt ja auch schon Tools die Hashs über GPU berechnen und wohl auch schon
Tools die AES via OpenCL/GPU berechnen können.

LG
Sougetsu

[Medium]

Das mag durchaus gehen, jedoch sind viele Verfahren (generell gesprochen) oftmals nicht so ganz offensichtlich parallelisierbar, und bedürfen einiger Kniffe und Umformungen des Problems um das überhaupt in merkbarem Umfang nutzen zu können.

Einfach so parallelisierbar sind Probleme, bei denen auf einer größeren Menge von Eingangsdaten gleicher Art, die selbe Operation angewendet werden soll, wobei unbedingt keine Operation auf das Ergebnis einer anderen im selben Schritt angewiesen ist. Dinge, die dieser Form nicht entsprechen, müssen vor brauchbarer Implementierung auf Vektorprozessoren (was GPUs sind) in diese so weit es geht gebracht werden.

Nicht umsonst ist die Heimat dieser Prozessoren in der Grafik: Hier müssen traditionell völlig voneinaner unabhägige Punkte (Vektoren) im 3D Raum transformiert werden. Das kann man getrost mit allen gleichzeitig machen, da die Matrizen für alle die selben sind. Und auch bei Pixel-Orientierten Berechnungen ist es ähnlich trivial, da für die meisten in der Praxis relevanten Filter zwar vielleicht mehr als 1 Pixel in eine Berechnung eingeht, jedoch immer in seiner Eingangswertigkeit, so dass auch hier problemlos alles gleichzeitig gemacht werden kann.

Anderes Beispiel ist das Rechnen mit riesigen Matrizen, die strukturell schon fast einem Bitmap entsprechen, und sich bei den meisten Operationen ähnlich günstig verhalten.

Probleme, die nicht trivial oder leicht umformbar diese Eigenschaften haben, sind zuweilen echt kompliziert umzuformulieren, und erfordern ggf. sogar im Grundsatz schon eine andere Sicht- und Herangehensweise. Manche lassen sich gar nicht anpassen. Da ich kein Krypto-Man bin weiss ich nicht genau welche Algos sich im Detail da wie verhalten, aber vom Prinzip her kann ich mir schon vorstellen, dass das nicht mehr GPGPU für Anfänger ist. Das es das für manche Algos gibt will ich wieder besseren Wissens nicht anfechten, ich möchte nur in Frage stellen, ob das mal so eben aus dem Handgelenk geht, und wie tief die Parallelisierung da überhaupt geht (sprich: Wie viel Vorteil holt man am Ende heraus).

Die Einsetzbarkeit von GPGPU ist hochgradig vom ganz spezifischen Problem abhängig. Da reicht nichtmals "Krypto" als Stichwort, man muss den exakten Algo untersuchen.