OpenCl goes AutoIt Update 31.Dezember 2016

  • Hallo!

    Danke für die Hinweise zu dem Kernel und der Paralellisierung!! Hatte mich schon gefragt wieso jedes mal andere Ergebnisse zustande kommen - Der Kernel selber konnte es nicht sein, das gibt es nichts zum falsch machen... Aber es wird jetzt immer besser mit OCL ;)

    >Gibst mir so eine Aufgabe, und wartest nichtmals das Wochenende ab...< Hatte mich extra damit beschäftigt weil ich mich darüber geärgert hatte, Habe 3 weitere Kernel geschrieben und den 4ten spare ich mir jetzt... Ich hänge das Script jetzt aus Trotz an ;)
    Ausserdem habe ich den 2ten Kernel vom vorigen Script lauffähig bekommen :D Es wird endlich richtig gezählt, aber die Auswertung folgt noch in Au3 und benötigt entsprechend viel Zeit. Gibt es vielleicht noch einen besseren (schnelleren) Weg die Daten zu sortieren?
    Ich kläre diese Woche das Kompressionsscript, und prüfe mal welche Teile sich dafür eignen. Das war ja eh in meinem Sinn das Ding Aufzurollen. Die Standartmethode sollte jedoch gut umsetzbar sein, aber ich fände es trotzdem schön so nah an dem Orginal wie möglich zu bleiben...

    Wenn man eine Lastanalyse für einen Kernel auf allen Devices durchführen möchte, dann muß ich doch so vorgehen das der Kernel auf jedem Device einzeln für nur einige Durchläufe ausgeführt werden soll - dabei die Zeit stoppen. Kann ich das z.B. so in etwa machen '_CL_RunKernel(StringLen($sInput) / 100, 0)' oder muß ich den Kernel extra dafür anpassen?
    Theoretisch kann man Kernel im vorraus so Planen, das diese Multi fähig sind. Aber ich würde noch gerne 'Clustern' also alle OCL-Devices nutzen können (CPU/GPU Mix) - ich weiß inzwischen auch wie ich mit diesen umgehen muß :D

    OpenCL Update


    Hatte mich vielleicht undeutlich ausgedrückt ;)
    Vor dem Update:

    Code
    >Device verfügbar= 1;1;2;CPU;Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz;18910080;18975064
    >Device verfügbar= 2;1;4;GPU;GeForce GTX 460;57417256;57417200
    >Device verfügbar= 2;2;4;GPU;GeForce GTX 460;9218672;57417200
    CPU: _CL_GetDevice("cpu", 1,1)
    GPU1: _CL_GetDevice("gpu", 2,1)
    GPU2: _CL_GetDevice("gpu", 2,2)

    Nach Update - Versuch 1:

    Code
    >Device verfügbar= 1;1;4;GPU;GeForce GTX 460;57417256;57417200
    >Device verfügbar= 1;2;4;GPU;GeForce GTX 460;9218672;57417200
    >Device verfügbar= 2;1;2;CPU;Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz;18910080;18975064
    CPU: _CL_GetDevice("cpu", 1,2)
    GPU1: _CL_GetDevice("gpu", 1,1)
    GPU2: _CL_GetDevice("gpu", 2,1)

    Nach Update - Versuch 2:
    Update auf: Nvidia (344.60), Intel (intel_sdk_for_ocl_applications_2014_x64):

    Nach erneuter Neu-Installation aller OpenCL Komponenten, hat sich der Fehler immer noch nicht ganz geklärt...
    So wie ich das sehe, hat das Update die komplette OCL-Installation durcheinander gebracht...
    $num_device_used und $num_platform_used sind vertauscht, deswegen geht kein _cl_GetALLDevice("multi") mehr bei mir!
    Seltsammerweise funktioniert aber _CL_GetALLDevice2("multi") mit $all=1 bei mir, _CL_GetALLDevice2("cpu") und $all=0 jedoch nicht... (aus 'tunnel_forum_ALL2.au3')
    Die Aufrufe für die Grafikkarten muss ich umbedingt wieder so hinbiegen, wie sie zum Anfang waren - Das sorgt für Probleme bei der Multi Verwendung! Kennst du vielleicht irgendwelche Reg-Key´s (oder so) wo ich händisch eintragen kann wie die DeviceID´s auf die Platformen verteilt werden???

    Grüsse!

    P.S:
    Diesmal hänge ich das Script an, zerstört sonst immer die Formatierung... Die Funktion 'CountChar_OCL2()' enthällt den zählenden Kernel, die anderen Funktionen sind experimentell.

  • >Gibst mir so eine Aufgabe, und wartest nichtmals das Wochenende ab...

    Der Standardspruch einer meiner Profs vor 30 Jahren zum Theme "zu wenig Zeit" war: "Was macht ihr nachts?" 8o

    Wenn man eine Lastanalyse für einen Kernel auf allen Devices durchführen möchte, dann muß ich doch so vorgehen das der Kernel auf jedem Device einzeln für nur einige Durchläufe ausgeführt werden soll - dabei die Zeit stoppen.

    Ja, zwei Möglichkeiten: Erstens die Datengröße in "Teilstücke" ändern, dazu muss dem Kernel über einen Parameter der "Teiler" mitgegeben werden, problemlos!
    Zweitens die Anzahl der Workgroups über den zweiten Parameter bei _CL_RunKernel() (ist Standardmäßig null) einstellen. Das ist aber "finetuning", wenn OCL die verwendeten Workgroups festlegt, ist man eigentlich immer nah am Optimum!

    Theoretisch kann man Kernel im vorraus so Planen, das diese Multi fähig sind.

    Das wäre natürlich optimal, macht aber nur dann Sinn, wenn die Kernellaufzeiten (reine Berechnungen auf der GPU) so lange dauern, dass der Overhead durch das weitere Übertragen des Speichers , also _CL_ReadBuffer(), nicht den Gewinn wieder auffrisst! Macht imho nur bei wirklich aufwendigen Berechnungen Sinn!

  • Nabend :D

    Ich war ansatzweise Fleißig und bin vier Baustellen gleichzeitig angegangen... Erstmal habe ich für den Kompressionsalgorythmus die absolute Mindest-Basis geschaffen, diese enthällt eine funktionierende Vorlage in AU3 und eine Interpretation in OpenCL. Dann habe ich die Herkunft des Alogo´s entstaubt und einigermaßen Lauffähig bekommen dazu einen Post verfasst und werde diesen noch aktualisieren. Auch habe ich ein Syntax-Highlighting für OpenCL in SciTE erstellt, damit mir das Arbeiten damit leichter fällt - ist aber farblich nicht so dolle geworden...

    Meine Motivation liegt darin eine OpenCL Interpretation der Kompressionsmethoden aus cHEX zu realisieren, weil ich die Geschwindigkeitsvorteile durchaus zu schätzen weiß! Außerdem bietet sich das Projekt für OCL an, weil ich dort mit Multiprocessing arbeite; in OCL könnten diese jeweils ein Device darstellen, und die Geschwindigkeit maximieren OHNE dabei auf Multi-Kernel zugreifen zu müssen (Die Verwaltung übernimmt das Main-Script).

    Ich habe eine lauffähige Kurzversion, welche das Multiprocessing verwendet, für das Anwendungsbeispiel angefertigt... So bin ich in der Lage innerhalb von AU3 die maximale Threadanzahl zu nutzen und in OpenCL habe ich den Vorteil alle vorhanden Devices als 'Threads' verwalten zu können ^^ <- Durch die Multiprocessing-Methode von cHEX wird der Prozess einmalig kompiliert und mehrfach ausgeführt, dabei wird dieser über TCP mit allen nötigen Parametern versorgt, und das Main-Script übernimmt dabei die Prozess- und Clusterverwaltung. Dann kann ein identischer Kernel auf allen Devices mit den jeweiligen Parametern ausgeführt werden - ohne das ich an den Kernel Anpassungen durchführen muss! (Hoffentlich :D)

    Ich hänge alles an, aber Poste den Kernel noch - vielleicht kann mir ja jemand ja so schon helfen ;)

    Kernel

    Zu der Vorgehensweise, dem Kernel wird ein Datencluster (25KB) übergeben, dieser wird intern in '$iGlobalSize' große Teile geteilt. Ich Teste den Kernel mit '_CL_RunKernel(1, 0)' um nur mit einem Thread zu Arbeiten. Aber wie weise ich jetzt die richtige globale Threadanzahl zu? muß ich '_CL_RunKernel(int(StringLen($sInput) / $iGlobalSize)+1, 0)' verwenden?? Momentan zickt der Kernel noch rum deswegen lässt sich das schlecht testen...
    Erstmal werde ich versuchen diesen Kernel in dieser Weise weiter auszubauen, sobald dieser richtig lauffähig ist möchte ich noch 'get_local_id(0)' integrieren - so wie ich das verstanden habe hat jeder globaler Thread ja noch seine lokalen Einheiten. (Ich hoffe das ist jetzt nicht zu Fantastisch)
    Bei 'atomic_add(&iAnalyse[$i], Local_iAnalyse[$i])' übergebe ich an die Funktion 'atomic_add' den Pointer auf dem Index des 'iAnalyse' Array´s. Ich möchte die Analyse- und die Replacefunktion in 'Void' Funktionen packen und dort eben das gesammte Array übergeben - mache ich das denn so '_OclAnalyse(&iAnalyse)' auf 'void _OclAnalyse(uint *iArray)' ?? <- Dabei wird dieses Array doch 'ByRef' übergeben, oder?

    [Multiprocessing]
    In dem Script 'SimpleCompression_MP.au3' muß man ab Zeile 27 seine entsprechenden OpenCL-Devies eintragen - war die schnellste Lösung... Die Prozesse müssen kompiliert werden, werden als *.exe aufgerufen. Der 'SimpleCompression_AU3' Prozess läuft schonmal wie erwartet, und der 'SimpleCompression_OCL' verwendet den gleichen Kernel wie in 'SimpleCompression.au3' - ist somit noch nicht lauffähig. Aber die Basis des Multiprocessing sollte Lauffähig sein, bei den OCL-Part konnte nicht richtig testen aber es gibt bei mir 3 Rückgaben welcher meinen Devices entspricht.


    Grüsse!

    [EDIT]
    Solltet ihr seltsamme Erscheiningungen in der OpenCL installation haben, wie z.B. mehr als einen Prozessor - obwohl ihr nur einen installiert habt; Dann habt ihr wahrscheinlich bei Intel Systemen erstmal die Runtime und anschliessend das SDK installiert. Ihr müsst einfach nur die Runtime DeInstallieren dann klärt sich das Problem.

    [EDIT2]
    Ich habe vergessen in 'SimpleCompression_MP.au3' die Zeile 101 zu De-Kommentieren, wenn diese Aktiviert wird startet auch das AutoIt Multiprocessing...

    2 Mal editiert, zuletzt von Techmix (15. November 2014 um 16:23)

  • Ich Teste den Kernel mit '_CL_RunKernel(1, 0)' um nur mit einem Thread zu Arbeiten.

    Nicht mit einem Thread, sondern mit einem Workitem! Das ist ein Unterschied!

    Aber wie weise ich jetzt die richtige globale Threadanzahl zu? muß ich '_CL_RunKernel(int(StringLen($sInput) / $iGlobalSize)+1, 0)' verwenden??

    Schau mal in die References zum Thema Speicherverwaltung. Ggf. HIER und HIER die Grafiken.

    Generell ist es aber unnötig, nur "ein" Workitem rechnen zu lassen, der Kernel läuft doch sowieso für alle anderen Workitems parallel. Ich verstehe jedenfalls deinen Ansatz nicht. Das spricht gegen sämtliche Ideen und Grundsätze von OCL!
    "Global" kannst du den Speicherbereich so groß machen wie du willst, problematisch wird es nur mit der Aufteilung auf die Workgroups und die Workitems. Die Aufteilung auf Workgroups und Workitems übernimmt doch sowieso OpenCL (abhängig vonn der Hardware) für dich!
    WENN du lokalen Speicher (innerhalb der Workitems __PRIVATE, innerhalb der Workgroups __LOCAL, Workgroups synchronisieren NUR über __GLOBAL (langsam) oder __CONSTANT) benutzen willst/musst, pass auf, denn je nach Hardware sind dort nur 16 bzw. 32K Speicher vorhanden! (Abfrage bei den Devices)

    Dabei wird dieses Array doch 'ByRef' übergeben, oder?

    Man kann keine Arrays an den OCL-Kernel übergeben. Schreib das Array in die Struct, übergib den Pointer. Ob du dann diesen Speicher überschreibst (das meinst du hoffentlich mit ByRef) oder die Ergebnisse in einem weiteren Speicherbereich zurückgibst, ist unerheblich!
    Du machst dir dein Leben auch dermaßen schwer^^
    Ich würde ganz pragmatisch Stückchen für Stückchen vorgehen. Daten an den Kernel übergeben und mir dann die Zwischenergebnisse zurückgeben lassen.

    Ich habe immer noch das Gefühl, dass du dir viel zu viel Gedanken über die Aufteilung innerhalb der Workitems machst!
    Wie schon in den ersten Posts hier gesagt, schreib EINFACHE Funktionen bzw. Kernel! Ich verstehe ehrlich gesagt dieses gesamte rumgefriemel mit den Kernelparametern und AutoItvariablen nicht! Optimiert wird grundsätzlich erst dann, wenn das Programm läuft! Und dann ist es WESENTLICH effektiver, erst einmal die Optimierungsmöglichkeiten innerhalb von OCL auszuschöpfen, als immer die SLI-Variante im Hinterkopf zu haben.

    Aber wie weise ich jetzt die richtige globale Threadanzahl zu?

    Darauf solltest du dich konzentrieren...
    Ich habe mal Infos zu einer Radeon 7970 gefunden:

    Zitat

    The AMD Radeon HD 7970 is one of the AMD Southern Islands series that also
    adopts the GCN architecture. The HD 7970 contains 32 compute units (CUs).
    All CUs share a 768 KB L2 cache. Each CU has four vector units, a scalar unit,
    a 16 KB read/write L1 cache, and a 64 KB local data share (32 KB is available
    to a single wavefront). Each vector unit consists of 16 processing elements (PEs);
    thus, the HD 7970 is equipped with 2048 (= 32 * 4 * 16) PEs

    Du hast also 32 Compute Units a 4 Vector Units a 16 Processing Elements (das sind die "Workitems").
    Man sollte also schauen, dass möglichst viele dieser Workitems gleichzeitig "Futter" haben. Im Endeffekt ist es kontraproduktiv, wenn du bei der 7970 bspw. 2,2MB Daten in je 1000Bytes großen Blöcken übergeben würdest. Dann würden 2048 Workitems parallel abgearbeitet, und die restlichen 152 "danach". Das heisst, 1896 Processing units laufen LEER und warten darauf, dass die 152 PE´s fertig werden!!!!
    Daher berechnet man entweder anhand seiner Hardware die Blockgröße, oder lässt (wie schon mehrmals gezeigt) einfach verschiedene Blockgrößen durchlaufen und merkt sich diejenige mit der schnellsten Berechnungszeit! Das allerdings ist das LETZTE, was bei der OCL-Programmierung in Angriff genommen werden sollte...

    EDIT Typo!!!!!!! Muss
    $CL_iAnalyse = _CL_CreateBuffer($p_iAnalyse)

    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

    2 Mal editiert, zuletzt von Andy (16. November 2014 um 17:26)

  • Hallo

    Zitat

    ...Ich verstehe jedenfalls deinen Ansatz nicht...


    Das mit dem einen Workitem mache ich nur, damit ich die printf() Ausgaben besser analysieren kann! Ist quasi NUR zu Debbugzwecken gesetzt, wird natürlich noch angepasst...

    Zitat

    ...das meinst du hoffentlich mit ByRef...


    Ich meine das innerhalb des Kernels (der *.cl Datei), wenn ich aus dem Kernel eine eigene Funktion aufrufe und ich eben ein Array als Rückgabe brauche. In anderen Sprachen muss ich "Arrays" ByRef an die Funktion übergeben - weil es nicht möglich ist ein Array aus der Funktion zurückgeben zu lassen ;)

    Zitat

    Du machst dir dein Leben auch dermaßen schwer


    Grins... Ich Denke einfach zu kompliziert, kann mich aber nicht entsprechend äussern/ausdrücken... DAS ist das Problem!

    Zitat

    ...Kernelparameter und AutoItvariablen...


    Ganz einfach, in OpenCL kann ich keine variablen Arrays verwenden - diese müssen eine vordefinierte Größe erhalten. Aber je nach Datengröße müsste ich immer den Kernel händisch anpassen, jetzt nicht mehr! Das übernimmt AU3 für mich... UND ich befinde mich doch in der Lernphase :whistling: dieses Rumgeieiere erleichtert mir einfach den Umgang...


    OK, der Kernel befindet sich noch in der Analyse von dem Input. Ich erstelle in AU3 eine 'uInt' Struct, Nulle diese und übergebe sie mit '__global uint* iAnalyse' an den Kernel. Am Kernel angekommen lasse ich mir dieses mit printf() ausgeben, und es ist nicht mehr 0. Die komischten Werte werden mir ausgespuckt, mal eine Null, sogar negative Zahlen werden ausgespuckt. Dabei erstelle ich die Struct wie alle anderen auch, und übergebe diese auch ganz normal. Alle anderen Structs kann ich mir ebenso mit printf() ausgeben, und da sind die Daten wie erwartet... Liegt das jetzt an einer unachtsammkeit innerhalb meines AU3 Scriptes, oder an meinem Kernel selber ?(

    Ausserdem finde ich meinen Kernel garnicht soooo kompliziert... Der Vorgang liegt ersichtlich im AU3 Source, ist eine einfache Analyse der Eingangsdaten, mit anschliessender Sortierung der Ergebnisse und Austausch mit freien Chars. Anschliessend alles in die Output-Struct schreiben und in AU3 den Buffer auslesen - Und fertig! <- Wo ist das kompliziert :huh:

    Ich habe das Multiprocessing absichtlich eingebaut, das ist auch nicht wirklich aktuell hab das schon vor 2 Jahren verwendet. In manchen Bereichen kann ich damit AutoIt einen richtigen Turbo verpassen. Und dieses lässt sich anhand von dieser Billig-Kompression sehr schön darstellen, im normalen Singleprozess-Betrieb braucht das standart Script 63 Sekunden bei mir um die 'AutoIt.exe' zu komprimieren, im Multiprozess-Betrieb nur noch 18 Sekunden - das ist drei mal schneller als normal. Und wieso nicht mit OpenCL ebenso vorgehen - es bietet sich mit den unterschiedlichen Platformen und Devices doch dafür an :D . Mir geht es auch nicht um SLI oder 'prestige' (hier guck mal, Boahhh...) für mich ist das eine normale Vorgehensweise! Maximierung der Rechenleistung durch Auslagerung in Prozesse oder Threads ^^
    Daher bin ich auch schon so angefressen, das ich mich mit den Fortschritt in OpenCL "etwas" schwer tue! Immer wieder Stolpersteine, die OCL SDK´s lassen sich nicht in die 'Express' Versionen vom VisualStudio integrieren, dann das dumm gelaufene Update, ... Immerhin konnte ich SciTE überreden mir endlich etwas Farbe im Kernel anzeigen zu lassen :D

    Grüsse!

    [Edit]
    Hab jetzt erst dein Edit gelesen... Das ist ja mal peinlich :D Aber Danke!

    Einmal editiert, zuletzt von Techmix (16. November 2014 um 18:38)

  • Die komischten Werte werden mir ausgespuckt, mal eine Null, sogar negative Zahlen werden ausgespuckt.

    Das hat mich bei meiner ersten Initialisierung eines Arrays im lokalen Speicher auch gefrustet. Das Problem war, dass OCL wohl die Arrays nicht "nullt", also mit Nullen füllt! Da wird einfach ein Speicherbereich reserviert, mit allem, was darin steht^^. Also sicherheitshalber das Array "nullen".

    ...Kernelparameter und AutoItvariablen...

    Ganz einfach, in OpenCL kann ich keine variablen Arrays verwenden - diese müssen eine vordefinierte Größe erhalten. Aber je nach Datengröße müsste ich immer den Kernel händisch anpassen, jetzt nicht mehr! Das übernimmt AU3 für mich... UND ich befinde mich doch in der Lernphase dieses Rumgeieiere erleichtert mir einfach den Umgang...

    Die Idee finde ich klasse! Sollten wir weiter ausbauen! Da gibts bestimmt noch weitere "Tricks" die man in die Kernel integrieren könnte.
    Wusstest du übrigens, dass man außerhalb vom Kernel Funktionen schreiben kann?

    Daher bin ich auch schon so angefressen, das ich mich mit den Fortschritt in OpenCL "etwas" schwer tue! Immer wieder Stolpersteine, die OCL SDK´s lassen sich nicht in die 'Express' Versionen vom VisualStudio integrieren, dann das dumm gelaufene Update, ... Immerhin konnte ich SciTE überreden mir endlich etwas Farbe im Kernel anzeigen zu lassen

    Immer schön geschmeidig bleiben... :thumbup:
    Manch anderer wäre froh, wenn er dieses KnowHow hätte!
    Ich selbst bin nur rudimentär in C (und somit den OCL-Kerneln) fit, leider.
    Man müsste sich viel mehr damit beschäftigen.

    Schaumamal wo das hinführt, ich habe ein gutes Gefühl^^. Gerade mit dem Hintergrund, dass eben NICHT dieser Mega-Supertanker Visual Studio für die Arbeit mit OpenCL nötig ist, sondern eine "billige" Scriptsprache :rock:

  • Hy,
    Wie bekomme ich es mit einigen Zeilen so hin, das ich an einem CL-Kernel einen Synaxcheck ausführen kann? Mir geht es um diese SciTE Ausgabe:

    Code
    LOG:
    Compilation started
    1:33:29: error: parameter may not be qualified with an address space
    1:33:73: error: parameter may not be qualified with an address space
    ...


    Ich habe doch noch 'OpenCL4SciTE' erstellt, habe da ein kleines Script für ein Helpfile integriert - Jetzt möchte ich noch den Kernel direkt aus SciTE kompilieren um damit einen Synaxcheck zu integrieren. Es nervt mich das ich andauernd in´s AU3 Script wechseln muss um im Kernel einen Synatax-Check durchführen zu können!
    In der Funktion '_cl_GetDevice()' wird das Logfile erstellt, auf welches ich so scharf bin :D Nur leider wird zum Erstellen des Log´s großes PiPaPo betrieben, und ich bin mir nicht sicher wie oder welche Teile davon ich verwenden soll...

    [OpenCL4SciTE]
    Auch stimmt was nicht in der 'opencl.properties' nicht, wieso wird das API-File nicht verwendet?!
    Mir ist auch nicht entgangen das nicht alle Keywords verwendet werden, habe schon einige manuell zugefügt. Das ist einfach passiert weil ich mir ein Highlighting von einem anderen Editor aus dem Netz geladen habe und diese Daten eben dür SciTE´s Format angepasst.
    Auch hätte ich die Farben in SciTE näher an AU3, also keine roten Funktionsbezeichnungen oder lila Textinhalt - sondern Hellblaue Funktionen und grauer Text, da stimmen sicherlich noch andere Farben nicht aber das ist störend. Ich habe schon mit den 'style' Einstellungen gespielt, muß ich diese wirklich händisch sortieren oder reicht eine richtige 'keywordsNR' Zuweisung - obwohl ich auch hier experimentiret habe. Auch macht es einen riesen Unterschied ob ich bei 'lexer.$(ocl)=cpp' oder einfach was anderes angebe. So viele Möglichkeiten, da steige ich nicht ganz durch...
    Ich hänge noch die aktuelle Datei dazu an, enthällt kleinere Änderungen...

    Grüsse!

  • In der Funktion '_cl_GetDevice()' wird das Logfile erstellt, auf welches ich so scharf bin Nur leider wird zum Erstellen des Log´s großes PiPaPo betrieben, und ich bin mir nicht sicher wie oder welche Teile davon ich verwenden soll...

    Ich nehme das mal in Angriff...
    Übrigens bekomme ich von der AMD/Radeon-Implementierung bspw folgende Fehler/Warnungen

    Zitat

    LOG:
    "C:\Users\Mama\AppData\Local\Temp\OCL966B.tmp.cl", line 6: warning: variable
    "p" was declared but never referenced
    uint i,r,p=divisor;
    ^

    Bekommst du nur die von dir geposteten "Fehlermeldungen"?

  • Ja, diese ist mir fremd. Ausserdem welche Variable p?? Habe diese jedenfalls nicht deklariert...

    [Edit]
    Das sieht mir danach aus, als würde der Compiler dazwischen funken...

    Einmal editiert, zuletzt von Techmix (17. November 2014 um 16:02)

  • nein, die Variable p hatte ICH eingebaut, um die Warnung zu provozieren :rofl:
    Und ja, der Compiler wirft diese Meldungen!
    Sehr aussagekräftig jedenfalls!
    Was hälst du davon, wenn als Rückgabe einer Funktion _CL_CheckKernelSyntax($kernel) das Logfile zurückgegeben wird. Im optimalen Fall (kein Fehler/Warnung) wird ein Leerstring zurückgegeben, ansonsten das Log. Ggf. sollte man drüber nachdenken, die Warnungen auch auszublenden und nur bei "echten" Fehlern das Log zurückzugeben.

  • Das wäre super! Würde den Umgang mit den Kerneln deutlich erleichtern. Ich halte das eh für eine gute Idee das in SciTE zu integrieren weil die meißten AU3 User sowieso den Editor verwenden. Und wie du sagtest, so kann man besser VS umgehen und effizienter Arbeiten.

    Grüsse!

    [Edit]
    Die warnungen haben mich anfangs auch sehr irritiert, habe versucht diese "Wegzuarbeiten"... Können ruhig ausbleiben!

    Einmal editiert, zuletzt von Techmix (17. November 2014 um 21:54)

  • hehe, wie wärs, beim Editieren des Kernels auf die F5-Taste zu hämmern und in der Console steht das Log oder "Kernel ohne Syntax-Fehler compiliert!"

  • Hallo ich hab wieder einen Hängerchen :)

    Es geht voran, aber ich habe gerade ein Problemchen mit einer Poolzuweisung. Obwohl ich im Kernel 'if (Local_NotReplace[j] != i)' verwende wird an dieser Position das Ungleich '!=' völlig übergangen und das resultierende Array wir nicht korreckt aufgebaut. UND ich bin endlich bei der letzten großen Funktion angekommen, den Replacer (ab Zeile 184). Dort benötige ich noch das Pool-Array welches nicht richtig erstellt wird, habe aber noch Probleme die Durchlauflogik richtig umzusetzen - Es soll der Pool überprüft werden, und ein vorhandensein des aktuellen Pool-Chars im 'String' (In AU3 würde ich StringInString() verwenden). Wenn erst das Pool-Array richtig erstellt wird, denke ich das der Rest nicht mehr allzuviel Schwierigkeiten machen wird ;)

    Du erwähntest das man im *.cl Kernel auch Funktionen ausserhalb des __Kernel erstelen und ausführen kann. Ich habe eine Analyse- und eine Replacefunktion bereits in Void Funktionen eingebaut. Die identischen Durchläufe befinden sich jetzt auch noch zusätzlich im __Kernel, weil mir nur Fehlermeldungen ausgespuckt werden egal wie ich in die Funktionen springe, oder wie ich die Parameter übernehme (Zeile 148 bis 162). Deswegen habe ich auch die beiden Funktionen Auskommentiert...

    Grüsse!

    CL-Kernel
  • Funktionen mit #define

    Spoiler anzeigen

    #define ORDERV(x,a,b) { bool swap = reverse ^ (getKey(x[a])<getKey(x[b])); \
    data_t auxa = x[a]; data_t auxb = x[b]; \
    x[a] = (swap)?auxb:auxa; x[b] = (swap)?auxa:auxb; }
    #define B2V(x,a) { ORDERV(x,a,a+1) }
    #define B4V(x,a) { for (int i4=0;i4<2;i4++) { ORDERV(x,a+i4,a+i4+2) } B2V(x,a) B2V(x,a+2) }
    #define B8V(x,a) { for (int i8=0;i8<4;i8++) { ORDERV(x,a+i8,a+i8+4) } B4V(x,a) B4V(x,a+4) }
    #define B16V(x,a) { for (int i16=0;i16<8;i16++) { ORDERV(x,a+i16,a+i16+8) } B8V(x,a) B8V(x,a+8) }

    Obwohl ich im Kernel 'if (Local_NotReplace[j] != i)' verwende wird an dieser Position das Ungleich '!=' völlig übergangen und das resultierende Array wir nicht korreckt aufgebaut.


    Puuuhhh, ich weiss ehrlich gesagt nicht, ob und wie != in OCL verwendet wird^^

  • Hy,
    Das Problem bei den "OpenCL Funktionen" ist, das ich versuchte ein 2D-Array zu übergeben. Hab das jetzt auf 2x1D-Array umgebaut, und ich kann OCL-Source in Funktionen auslagern. :D

    Und ich habe in AU3 das "NotReplace" Array in ein "OnlyReplace" Array umgebaut, und kann dieses jetzt erfolgreich in OCL mit "==" statt "!=" abfragen ;)

    Grüsse!

  • Wenn das mit dem Anhang nicht funktioniert, müsste ich eine neue ZIP bereitstellen.
    Kann ich aber erst am Wochenende machen. Dann bitte nochmal melden

  • Hi zusammen,
    aus aktuellem Anlass habe ich die OpenCL-Funktionen weiter angepasst und aufgefrischt.

    Bitte die Beispielscripte testen, ggf. auch die Ergebnisse der Devices.au3 posten. Danke!

    Es sollten die 64-Bit-Versionen der Scripte problemlos laufen, Geschwindigkeitsunterschiede zu 32Bit sind (bei mir zumindest) keine feststellbar,

    Getestet wurde auf einem Intel-Notebook mit frisch installiertem und auf die neueste Version geupdateten Win10.
    Im Prozessor ist ein Grafikchip integriert, dazu auf dem Board zusätzlich eine Nvidia-GPU. Die Tests liefen ohne Treiberupdates problemlos sowohl auf der CPU als auch auf den GPU´s.

    Ich habe ein "Auswahlmenü" zur Verfügung gestellt, um das Gerät, auf welchem der Code ausgeführt werden soll, auswählen zu können.

    Zwischenablage01.jpg
    Dazu im Vergleich, meine "alte" Kiste