OpenCl goes AutoIt Update 31.Dezember 2016

    Zitat von Blume

    Aber ist etwas komisch ein AMD X6'Kerner hat bei der Speed-Beurteilung nur 25
    Zum Vergleich name's i5 (was doch 4 Kerne sind oder?) hat 111

    Soll ich den Benchmark etwa so umschreiben, dass die "billigen" AMD-CPU´s die i5 schlagen? Kein Problem, aber stell dir dann mal das gequieke vor :rofl:
    Aber im Ernst, in der nächsten Version bekommt man u.a. die reinen Kernel-Laufzeiten angezeigt, das relativiert dann die Ergebnisse wieder 8o

    Jetzt noch die Include-Files anpassen, und die Beispiele sollten bei allen funktionieren...

    Neue Version im Startpost,
    sollte nun auch auf 64Bit laufen,
    nun direkte Auswahl bei mehreren verfügbaren Geräten möglich, s. EDIT v. 26.August 2012 im Startpost

    Btw. wieso bekomme ich bei einer *.ZIP-Datei eine Fehlermeldung beim Upload?

    ciao
    Andy


    "Schlechtes Benehmen halten die Leute doch nur deswegen für eine Art Vorrecht, weil keiner ihnen aufs Maul haut." Klaus Kinski
    "Hint: Write comments after each line. So you can (better) see what your program does and what it not does. And we can see what you're thinking what your program does and we can point to the missunderstandings." A-Jay

    Wie man Fragen richtig stellt... Tutorial: Wie man Script-Fehler findet und beseitigt...X-Y-Problem

    Einmal editiert, zuletzt von Andy (26. August 2012 um 17:30)

    Neue Version im Startpost.

    Bug gefixt!
    Bei Verwendung von

    [autoit]

    _CL_GetDevice()

    [/autoit]

    werden nun die richtigen Geräte verwendet, wenn man "CPU" bzw. "GPU" als Parameter verwendet.
    "ALL" verwendet das nächste erreichbare Device (CPU oder GPU)

    [autoit]

    _CL_SetArg(0, "ptr*", $CL_buffer_in) ;Kernelparameter: __global float* inputbuffer erwartet das Handle des Eingangspuffers
    _CL_SetArg(1, "ptr*", $CL_buffer_out) ;Kernelparameter: __global float* outputbuffer erwartet das Handle des Ausgangspuffers
    _CL_SetArg(2, "uint*", 100) ;Kernelparameter: const unsigned int count kann die Anzahl der zu berechnenden Zahlen begrenzen!
    ...

    [/autoit][autoit][/autoit][autoit][/autoit][autoit]

    Func _CL_SetArg($arg_index, $arg_type, $arg_value)
    Local $struct = DllStructCreate(StringReplace($arg_type, "*", ""))
    MsgBox(0, "hi", StringReplace($arg_type, "*", ""))
    ; ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : DllStructGetSize($struct) = ' & DllStructGetSize($struct) & @crlf & '>Error code: ' & @error & @crlf) ;### Debug Console
    Return clSetKernelArg($kernel, $arg_index, DllStructGetSize($struct), $arg_type, $arg_value)
    EndFunc

    [/autoit]


    Warum dereferenzierst du alles, um anschliessend den Dereferenzoperator zu löschen? Die Zahl 100 sollte eigentlich eh nicht dereferenziert werden^^

    Ansonsten einfach nur eine geniale Idee! Hut ab. Ich kämpfe zwar noch mit ein paar Problemen, aber wenn das erstmal läuft eröffnet diese UDF neue Geschwindigkeitshorizonte [zumindest hoffe ich das :D].

    Hi,

    schön dass sich jemand für diese zukunftsorientierte Technik interessiert^^

    Zitat

    Ich kämpfe zwar noch mit ein paar Problemen, aber wenn das erstmal läuft eröffnet diese UDF neue Geschwindigkeitshorizonte [zumindest hoffe ich das ].

    Wenn du mit Problemen kämpfst, bitte Info in diesen Thread. Ich bin mittlerweile schon wesentlich tiefer in die Materie eingestiegen und kann bei einigen Problemen weiterhelfen...
    Auch sind etliche Funktionen und Möglichkeiten schon weiterentwickelt aber noch nicht hier veröffentlicht...eine "UDF" hänge ich mir noch nicht ans Bein....vielleicht wird das irgendwann im Lauf des Jahres aktuell^^
    Als "Freizeit-Programmerer" mit vielen anderen Prioritäten hat man es nicht leicht :rolleyes:

    Wichtig ist, bei Problemen das "$Debug_Flag=1" zu setzen, und den kompletten Konsolenausdruck anzuhängen. Treiberversion der Grafikkarte, CPU und GPU-Modell usw sollten natürlich auch angegeben werden.
    Erschwerend kommt dazu, dass sich die Entwickler der Treiber + SDK´s SEHR bedeckt halten mit detaillierten Informationen. Dabei ist es egal, ob es sich um INTEL,AMD oder NVIDIA handelt.
    Da kann es dann sein, dass auf aktueller Hardware der neueste Treiber mit dem neuesten SDK nicht funktioniert....."Uups, ach ja, auf der Chipgeneration xyz müssen sie den Treiber blablub mit dem SDK abc verwenden, damit die Beispiele (C++ in den SDK´s) überhaupt kompiliert werden..."
    IMHO sehr unbefriedigend, aber wenn eine funktionierende Kombination Hardware/Software gefunden wurde, stehen wirklich extreme Möglichkeiten zur Verfügung.
    Daher ist allererste Pflicht, CLINFO.EXE (bei jeder CL-Installation vorhanden) aufzurufen und ggf. die Ausgabe in eine Textdatei zu schreiben und diese anzuhängen. Ggf. auch einige der Ausgaben der compilierten Beispieldateien aus den SDK´s.
    Wenn es an der AutoIt-Implementation hängt (hehe, nobody is perfect^^) benötige ich natürlich diese Rückinfo!

    Ich habe zzt. Kontakt zu einem kleinen Programmiererteam, dass sich mit Echtzeitverarbeitung von grossen Datenmengen beschäftigt und im letzten Jahr mehrere hunderttausend Euro an Hardware eingespart hatte, weil sie ihre Software optimieren konnten.
    Dann geht es auch nicht mehr darum, ob OpenCL überhaupt funktioniert, sondern darum, die Kernel weiter zu optimieren. Es ist teilweise sehr interessant, sich mit den Interna der Hardware zu beschäftigen. Da muss man einem langjährigen und von mir sehr geschätzten Programmierer erklären, warum ein Kernel plötzlich 3x schneller läuft, nur weil man irgendwo im Code j[x][y] statt j[y][x] verwendet.
    Auf der CPU sind die Speichertransfers sowieso durch den Bus limitiert, da fällt das weniger ins Gewicht, aber auf der GPU mit wesentlich schnellerer (lokaler) Speicheranbindung muss man einfach alle Möglichkeiten ausschöpfen. Vermeidung von Cache-misses FTW! Aber das ist eine andere Geschichte ;)

    uups, die Hälfte vergessen^^

    Zitat

    Warum dereferenzierst du alles, um anschliessend den Dereferenzoperator zu löschen? Die Zahl 100 sollte eigentlich eh nicht dereferenziert werden


    Um näherzubringen, dass idR. Pointer an den Kernel übergeben werden und einen Parameter "einzusparen"^^

    Du kannst doch auch die Funktion direkt aufrufen, dann sieht das so aus

    [autoit]

    clSetKernelArg($kernel, 4, DllStructGetSize(dllstructcreate("float")), "float*", $stepx)

    [/autoit]


    da finde ich

    [autoit]

    _CL_SetArg(4, "float*", $stepx)

    [/autoit]


    wesentlich kürzer und einfacher....

    Neue Version, bitte Testen!

    FX6300@4Ghz und Radeon 7790 (hat die gleiche GPU wie eine R7 260)
    autoit.de/wcf/attachment/23970/

    Hallo,
    ich wollte mich hier auch mal einklinen.
    Erstmal meine Ergebnisse:
    Cpu: i7 920
    Gfx: 2 x Gtx 460 AMP (SLI)
    (Grafik wollte nicht ...versuche es später nochmal)
    CPU: 75 Speed
    Gfx: 300 & 299 Speed

    Soweit bin ich ganz zufrieden mit dem Ergebniss.

    Aber zu dem Source, ich hatte damit einige Experimente gemacht und bei der Verwendung von '_CL_GetDevice()' ist es irritierend das die Angabe 'ALL' die nächst erreichbare Hardware darstellt - und eben nicht die gesammte Hardware.
    Währe es eigentlich möglich einen Kernel auf CPU & Gfx laufen zu lassen?
    Und wie verhällt sich OpenCL bei einem SLI-System? Werden überhaupt beide Karten angesprochen, oder nur eine davon??

    Wenn ich mir den Mandelbrotflug in OpenCL (über Gfx) anschaue - und anschliessend den Flug in AU3... Das ist so ein gewaltiger Unterschied! Wow!!
    Aber ich habe grad mal vielleicht 20% der Kernel (und dessen Befehle) verstanden... Das soll doch C sein - oder nicht?!? (Ahhhh, sind doch SDK-Befhele...) Da muss man sich wirklich einlesen...
    So wie ich das sehe sollte es doch auch möglich sein den 7zip Algorythmus nach OpenCL zu portieren, dieser Funktioniert eh schon mit Multi-Threading. In OpenCL könnte das doch auch von der GraKa erledigt werden, oder??

    Grüsse!

    [EDIT]
    Mir fiel grade auf das die GraKa von Blume (Geforce 9800 GTX+) einen Speed von 621 hat, meine GTX 460 AMP (toppt eine GTX 470) bekommt nur einen Speed von knapp 300 Punken... Meine Karte ist doch deutlich Leistungsfähiger, ist der Punktevorsprung tatsächlich NUR durch die 'Compute Units' begründet (seine hat 16, meine nur 7)?!?

    Einmal editiert, zuletzt von Techmix (11. März 2014 um 11:25)

    Hi,

    Zitat

    Aber zu dem Source, ich hatte damit einige Experimente gemacht und bei der Verwendung von '_CL_GetDevice()' ist es irritierend das die Angabe 'ALL' die nächst erreichbare Hardware darstellt - und eben nicht die gesammte Hardware.

    Ab OpebCL 1.2 sollte es möglich sein, die komplette Hardware (GPU und CPU) gleichzeitig an einem Kernel rechnen zu lassen. Ich hänge mich da mal dran...

    Zitat

    Und wie verhällt sich OpenCL bei einem SLI-System? Werden überhaupt beide Karten angesprochen, oder nur eine davon??

    Gute Frage ^^, sollte sich bei Khronos im Forum klären lassen.

    Zitat

    Wenn ich mir den Mandelbrotflug in OpenCL (über Gfx) anschaue - und anschliessend den Flug in AU3... Das ist so ein gewaltiger Unterschied! Wow!!
    Aber ich habe grad mal vielleicht 20% der Kernel (und dessen Befehle) verstanden... Das soll doch C sein - oder nicht?!? (Ahhhh, sind doch SDK-Befhele...) Da muss man sich wirklich einlesen...

    Den Kernel für den Mandelbrotflug habe ich einfach mal kopiert, um zu zeigen, dass auch ohne Änderung des Kernels ein AutoIt-Script problemlos davon profitieren kann.
    In der Devices64 verwende ich einen eigenen Mandelbrot-Kernel, der besteht nur aus einigen Zeilen ^^

    Zitat

    So wie ich das sehe sollte es doch auch möglich sein den 7zip Algorythmus nach OpenCL zu portieren, dieser Funktioniert eh schon mit Multi-Threading. In OpenCL könnte das doch auch von der GraKa erledigt werden, oder??

    Es lassen sich alle gut parallelisierbaren Algorithmen durch OpenCL beschleunigen. Leider trifft das für die Mehrzahl der Packer nicht zu :huh: Deren Algorithmen sind eben nicht gut parallelisierbar...

    Zitat

    Mir fiel grade auf das die GraKa von Blume (Geforce 9800 GTX+) einen Speed von 621 hat, meine GTX 460 AMP (toppt eine GTX 470) bekommt nur einen Speed von knapp 300 Punken... Meine Karte ist doch deutlich Leistungsfähiger, ist der Punktevorsprung tatsächlich NUR durch die 'Compute Units' begründet (seine hat 16, meine nur 7)?!?

    Ja, so sieht es aus. Nvidia sieht generell bei OpenCL gegenüber AMD-GPU´s nicht gut aus, das wird umso schlimmer, je weniger Compute-Units verwendet werden.
    Aber Nvidia holt auf^^
    Apple pusht zzt. OpenCL, kein Wunder, die wollen ja auch ihre Mac-Pro´s mit den teuren Grakas verkaufen...

    Ich finde das Ergebnis für meine Hardware wieder mal recht interessant. :whistling:
    Ich glaube den Erkennungsfehler hatte ich schon mit dir in der SB besprochen, Andy. Aus irgendeinem Grund wird meine CPU 2 mal erkannt aber einmal mit der Platform ID der GPU ^^.
    autoit.de/wcf/attachment/24293/
    Meine Hardware: http://www.sysprofile.de/id155685

    Zitat

    Es lassen sich alle gut parallelisierbaren Algorithmen durch OpenCL beschleunigen. Leider trifft das für die Mehrzahl der Packer nicht zu :huh: Deren Algorithmen sind eben nicht gut parallelisierbar...

    Aha...
    Ich Dachte es würde auch so gehen:
    Ich hatte vor einigen Jahren mal eine Kompressionsroutine in AU3 geschrieben, relativ langsamm, mieser Skill, eben alt - diesen habe ich auch in Freebasic portiert, die Kompressionsroutinen verbessert und auf Multithreading umgestellt. Habe mich auch relativ intensiv mit FB & Threading beschäftigt, und mich dafür entschieden das die Threadfunktion 'in sich geschlossen' geschrieben deutlich schneller Arbeiten (brauche keinen Mutex).
    Um es etwas aufzuschlüsseln... Wenn ich eine Datei komprimieren will, zerteile ich diese in z.B. 16KB grosse Stückmengen welche ich in einzelnen Structs lege, ermittel die Threadanzahl, und starte diese. Sobald ein Thread fertig ist wird dieser sofort wieder mit einer anderen Stückmenge gestartet. Sind alle Stückmengen abgearbeitet werden die Structs wieder zusammengefügt. So erreiche ich eine imense Geschwindigkeit, habe aber nicht die 100%ige Kompressionsrate wie im Single-Thread Modus - das ist einfach durch die Zerteilung begründet...
    In OpenCL währe es also nicht möglich, dieses so ähnlich auf der GraKa (sonst kann man ja normales Threading verwenden) zu berrechnen? Ich Denke wenn man seinen Kernel nach einer ähnlichen Weise schreibt (wie eben in FB OHNE Mutex) sollte es doch möglich sein - kenne mich leider viel zu wenig mit OpenCL aus, sonst würde ich es versuchen :D

    Grüsse!

    Es steht nirgends geschrieben, dass man einen Kompressionsalgo nicht portieren kann, nur dass er wahrscheinlich nicht wesentlich schneller läuft als auf einer CPU. Das größte Problem ist die Parallelisierbarkeit. Da du vorhast deine Dateien in 16KB Stücke zu zerhacken und diese einzeln zu komprimieren, ist das aber kein Problem und sollte auch einen großen Temposchub ermöglichen. (z.B. eine 1MB datei -> 64 Teile -> 64 Threads -> Schnell)

    Habe eben kurz den Mandel Test durchlaufen lassen.
    Ohne SLI: 378 Punkte,
    Mit SLI: 379 Punke...

    Also kein SLI mit OpenCL!?! Ich habe erwartet das OpenCL intern die GraKa´s 'Clustert'.

    @Marsi:
    Das ist ja nur ein Beispiel wie ich in FP mit 4 Threads gearbeitet habe - aber die Durchführung ist ja unabhängig voneinander, also gut Paralysierbar, oder habe ich mit der Paralysierbarkeit das total falsch Verstanden?!?
    Gibt es eigentlich unterschiede zwischen den CPU und der GraKa innerhalb der Berechnungen? Ich meine jetzt ob z.B die CPU Stringopperationen grundsätzlich schneller als die GPU ausführt. Weil eine GPU ist ja eigenlich eher für Mathematische Opperationen gebaut...

    Fragen über Fragen ;)

    Seit neustem sind bei mir zwei Radeons im Crossfire verbaut. Die Performance mit OpenCL skaliert sich wunderbar, außer mit Andys Implementation. (Getestet mit OpenCL in div. Raytracern)

    Ok, dann kann es an der OpenCL-Version liegen die Andy verwendet.

    ...also mit Multi-GPU Nutzung noch etwas warten :)

    [EDIT]
    Mars: ...ich habs befürchtet... Muss mich wohl mehr in die OCL Materie einlesen, hatte das mit dem Multithreading schon recht spät für mich entdeckt, und erst jetzt die Paralysierung :D

    2 Mal editiert, zuletzt von Techmix (11. März 2014 um 17:15)

    Hi,

    Zitat von minx

    Seit neustem sind bei mir zwei Radeons im Crossfire verbaut. Die Performance mit OpenCL skaliert sich wunderbar

    BS, OpenCL-Version, Hardware?

    Techmix,
    mit einem "gut parallelisierbaren Algorithmus" gabe ich natürlich den Algorithmus an sich gemeint. LZW ist schlecht zu parallelisieren, trotzdem kann man, wie du es gemacht hast, das "Problem" einfach in Teile zerschneiden und dieses dieser Teile dann mit dem "nicht gut parallelisierbaren Algorithmus" berechnen und danach zusammenfügen. Da würde natürlich auch per OpenCL funktionieren!

    Zitat

    Gibt es eigentlich unterschiede zwischen den CPU und der GraKa innerhalb der Berechnungen? Ich meine jetzt ob z.B die CPU Stringopperationen grundsätzlich schneller als die GPU ausführt. Weil eine GPU ist ja eigenlich eher für Mathematische Opperationen gebaut...

    Die GPU liegt bei den Float-Berechnungen vorne, die CPU bei "großen" Datenmengen im Speicher (Cache haut dann massiv rein, wenn intelligent eingesetzt, siehe Array of Structures / Structures of Arrays) und viel Speichergeschiebe.

    Die GPU legt dann massiv zu, wenn die 16KB (für jedes Workitem innerhalb der Workgroup) als lokaler, von allen Workitems benutzbarer Speicherbereich, verwendet werden kann.
    Dieses "tuning" ist teilweise hardwareabhängig, und wenn clever gemacht, geht die Performance nahe an die theoretischen Möglichkeiten!
    Etwas, das "Multi/Hyper-usw.-Threading" durch den Overhead des BS und dessen dazwischengefunke niemals hinbekommen. Da skaliert der Overhead nämlich doppelt und dreifach^^

    Techmix,
    wenn du also die Daten von deinem Kompressionsalgorithmus in 16KB große "Häppchen" zerlegst, diese in den lokalen Speicher der Workgroups packst und dann dort noch Teilaufgaben auf die einzelnen Workitems verteilen kannst, hast du gute Chancen, auf einer mittelmäßigen GPU auch eine "fette" CPU zu schlagen!