Beiträge von Andy

  • CSV Datei aufteilen

    Hi,
    ich schätze, so sollte es sein...

    Spoiler anzeigen
    [autoit]

    #include <File.au3>
    #include <Array.au3>

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

    $array=stringsplit(fileread("test.csv"),";",3)
    $dim=int((ubound($array)-1)/3)+1

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

    dim $a[$dim][3]

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

    for $i=0 to $dim-1
    $a[$i][0]=$array[$i*3+0]
    $a[$i][1]=$array[$i*3+1]
    $a[$i][2]=$array[$i*3+2]
    next
    _arraydisplay($a)

    [/autoit]

  • DeskStream 2 Release Candidate 1.8

    Wieso dll´s?
    In Scite F1 drücken um die Hilfe aufzumachen, mit ALT+s den Reiter "Suchen" aktivieren, dort *mouse* ins Inputfeld eingeben, unten den Haken bei "nur Titel suchen" reinmachen und dann auf den "Themen Auflisten"-Button klicken.....
    Die dann erscheinenden Maus-Befehle geben alles her, was du brauchst, sowohl auf Server, als auch auf Client-Seite!

  • Pseudo Aero Look (Glas Effekt) für WindowsXP Build 2011-12-02

    Coole Sache das, wobei meine Frau fragte, wer diesen Effekt überhaupt braucht....
    Ich darauf:"Grafischer (langsamer) Schnickschnack, um neue (schnelle) Hardware verkaufen zu können!"
    Sie:"Ist dieses AERO beim neuen Windows abzuschalten?" (wir bekommen bald 2 neue Win7/Win8-Laptops)
    Ich:"Na klar!"
    Sie:"Das erste Fenster mit diesem wischiwaschi, und es wird XP draufgespielt, Ende der Diskussion.....(überlegt kurz)....was kosten die Rechner ohne Betriebssystem weniger?"
    (Abgang der Darsteller)

    ;( umpft :huh:

    Ich werde mich trotzdem mal am Wochenende hinsetzen, um den "Blur" von 25ms auf unter eine halbe Millisekunde zu drücken....bissl was geht immer....aber verratet das nicht meiner Frau^^

  • OpenCl goes AutoIt Update 31.Dezember 2016

    Zitat

    Da gibt es noch andere Dinge, z.B. vernünftiger inline-Assembler und einfachere struct's.

    Für das, wozu AutoIt gedacht ist, reicht es imho völlig aus und ist auch schnell genug!
    Wer wirklich um jede Millisekunde kämpfen muss, der investiert z.B. in den Intel-C++-Compiler, jagt seinen Code durch den Profiler und schreibt die "inner loops" dann in Assembler (oder Instrincs, was dasselbe ist, nur "aufgehübscht"). Damit ist auf der CPU das Ende der Fahnenstange erreicht!

    Die Kombination OpenCl/OpenGL ist auf Grafikkarten von KEINER der zur Zeit angebotenen CPU´s zu schlagen, passende Algorithmen vorrausgesetzt.
    Wobei man allerdings durch die "Hintertür" auch ohne Grafikkarte alle Cores der CPU ohne Threadmanagement benutzen kann!
    GPGPU bzw. OpenCl läuft sowieso über die API-Funktionen, da ist der "Unterbau", also AutoIt oder Basic oder C/C++ völlig irrelevant!
    Natürlich kann man sich beim Nasebohren den Finger brechen, die Frage ist, ob man das wirklich machen MUSS!
    Inline-Assembler ist zwar gut und schön, aber genausogut schreibt man eine DLL in Assembler/C/C++ und ruft die Funktionen einfachst in AutoIt über DLL-Calls auf. Die DLL in den AutoIt-Code z.B. mit UEZ´s Base64 eingebunden und gut ists....

  • DeskStream 2 Release Candidate 1.8

    Zitat

    man is das ding schnell...

    für "normale" Desktops mit einigen Fenstern und überwiegend statischem Inhalt reicht die Lauflängenkodierung und meine gebastelte "Kompression" völlig aus.
    Auf einem 08/15-Rechner läuft die Analyse auf Bildunterschiede und Kompression in nicht mal 5 Millisekunden, der Rest ist der Datenübertragung geschuldet, im internen Gigabit-Netz merkt man absolut keine Verzögerung.
    Bei Internet mit DSL 6000 kann man von 10MBit ausgehen, auch dafür reicht es aus, bei Video-Übertragung muss man einfach extrem große Datenmengen bewegen, da kommt man schnell ans Limit.

    Zitat

    habs mal mit tcp geschrieben... viel zu lahm..
    dann udp... schneller, aber hatte keine vergleich- oder zoom-funktion drin...

    Wir verwenden die Standard-AutoIt-TCP-Funktionen, da gibts auch nicht viel zu beschleunigen. Was in AutoIt Zeit kostet, also die Bild-Unterschied-Analyse und Kompression dieser Daten ist ja in einer Handvoll Bytes in Assembler implementiert. DAS kostet in AutoIt ziemlich viel Zeit :D

    Zitat

    Es wäre geil, wenn du es irgendwie schaffen könntest, dass man den mauszeiger sieht...
    Und: Maustaste gedrückt halten und dann "ziehen"... Markiert er dann mehrere Dateien..?

    Keine Ahnung^^. Kommt auf die Geschwindigkeit der Übertragung an....da ich viele verschiedene Features und Versionen von Deskstream habe, aber mit Sprenger120 zusammen nur einige davon released habe, kann es sein, daß "klickziehen" funktioniert. ?(
    Aber das Protokoll ist ja einfach aufgebaut, das sollte jeder schnell erweitern können:
    Gehaltene Maustaste auf dem Server registrieren, Koordinaten an den Klient übertragen und per Mausfunktionen anwenden.
    Genauso überträgt man Tastaturanschläge und alles andere, was man auf Clientseite braucht, z.B. Ton für Voice-Übertragung oder Video-Ton (da würde ich aber eine "dicke" Leitung vorraussetzen, bzw. erstmal wie z.B. bei Youtube o.ä. die ersten 10 Sekunden vorpuffern)

  • Schnellste 2d Grafikengine

    Hi GtaSpider,
    man müsste die Daten einfach mal auswerten, ich vermute, daß Zeit/Amplitudenpaare angegeben sind.
    Die Frequenz sind 1000 Hertz, könnte sein, daß nicht die Daten (Amplituden) einer einzigen Schwingung, sondern fortlaufend alle x Milli(micro)sekunden im Verlauf ausgegeben werden.
    Probier mal 1 Hertz als Frequenz, als Ausgabe sollte dann die Sinuskurve erfolgen
    Kann auch sein, daß man durch 5 aufeinanderfolgende Punkte eine Funktion 5. Ordnung legen muß 8o . Das wäre dann aber nur Fleißarbeit :thumbup:


    Bezüglich Geschwindigkeit:
    Wie viele Datenpaare werden pro Sekunde maximal vom Oszilloskop geliefert?
    Gibt es eine API um direkt auf den Speicherbereich der ausgelesenen Daten zuzugreifen oder werden die in eine Datei geschrieben?

    Zitat

    Das schnellste ist denk ich Prospeed für AutoIt

    Prospeed nutzt die GDI-Funktionen zur Darstellung, lediglich die Filter/Spritebewegungen sind von Frank Abbing in Assembbler programmiert.
    Gehen wir mal von 1280 Pixeln in x-Richtung aus, 3 uberlagerte einzelne Frequenzen gibt über den dicken Daumen ca 4000 "Pixel", die pro Frame zu setzen sind.
    Bei gewünschten 30 FPS bleiben pro Frame 33 Millisekunden fürs Auslesen der Daten und Darstellung auf dem Bildschirm.
    Das sind 8,3 µ-Sekunden pro Pixel....da wird ein GDI+-"Setpixel()" schon Schwierigkeiten bekommen^^.
    AutoIt fällt damit aus....
    Ich würde, wenn die Daten im Speicher (Puffer) stehen, entweder eine einfache selbstgeschriebene Assembler- oder C- Dll fürs schreiben der "Pixel" in den Grafikpuffer nehmen und diesen dann per GDI "blitten" oder mit den GDI+-Funktionen weiterverarbeiten, smoothing usw. lässt grüßen.
    Somit könntest du die GUI und ggf das Datenloggen per USB mit AutoIt machen und müsstest nur noch 30x pro Sekunde die Dll-Funktion für die Darstellung der Frames aufrufen.

    /EDIT/ Gerade eukalyptus´ Post gelesen^^

    [autoit]

    Global $iPnt = 20

    [/autoit]

    Ist natürlich geschönt^^, aber selbst bei 200 Punkten erreicht man noch 30-40FPS
    Die Frage ist, ob Bezier-splines gewünscht sind^^

  • [Fraktal] Mandelbrot-Menge

    Habe mal einen einfachen OpenCl-Kernel gebastelt....

    Gedrückte linke Maustaste zoomt rein an der Mauscursorposition
    Gedrückte rechte Maustaste zoomt raus an der Mauscursorposition

    Wer mag, kann diesen Kernel stark beschleunigen (vor allem für die CPU), wenn er die SIMD-Variante (SSE) benutzt, siehe Tunnelflug-Script
    Mit den Farben spielen ist erlaubt^^

    Da ich nur einfache Genauigkeit (float) verwende, wird es beim reinzoomen schon schnell pixelig...wird Zeit für double!

    Spoiler anzeigen
    [autoit]

    #include <opencl_easy.au3>
    #include <GUIConstantsEx.au3>
    #include <WinAPI.au3>
    #include <GDIConstants.au3>
    #include <Misc.au3>

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

    ;Apfelmännchen einfachst in OpenCl

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

    ;ich bin nicht der C-Freak, bitte also um Nachsicht mit meinen Kernels, Verbesserungsvorschläge werden selbstverständlich umgesetzt^^
    ;wer mag, kann den Kernel auch gerne als SIMD-Variante machen, das beschleunigt die Berechnung auf der CPU enorm!
    Global $KernelSource = "__kernel void tunnelflug( __global int* output, const unsigned int width,const unsigned int height,const float centerx,const float centery,const uint maxiter,const float apfelbreite)" & @CRLF & _
    "{" & @CRLF & _
    "uint iter;" & @CRLF & _;lokale variablen
    "float xtemp;" & @CRLF & _
    "uint threadid = get_global_id(0);" & @CRLF & _ ;thread-id, d.h. jedes pixel von 1 bis b*h
    "float py = threadid/height;" & @CRLF & _ ;pixelkoordinaten
    "float px = threadid%width;" & @CRLF & _ ;pixelkoordinaten
    "float x0 = (centerx-apfelbreite*0.5f)+px*apfelbreite/width;" & @CRLF & _ ;...Berechnungen
    "float y0 = (centery-apfelbreite*0.5f)+py*apfelbreite/height;" & @CRLF & _ ;...Berechnungen
    "float x = x0;" & @CRLF & _
    "float y = y0;" & @CRLF & _
    "for (iter=0;iter<maxiter;iter++)" & @CRLF & _ ;...Berechnungen
    "{" & @CRLF & _ ;...Berechnungen
    "xtemp = x*x -y*y + x0;" & @CRLF & _
    "y = 2 * x * y + y0;" & @CRLF & _
    "x = xtemp;" & @CRLF & _
    "if ((x * x + y * y) > 4) break;" & @CRLF & _
    "}" & @CRLF & _ ;...Berechnungen
    "output[threadid] = 0x0008002* native_log2(native_log2((float) iter+1));" & @CRLF & _ ;Pixel schreiben 0xFFBBGGRR, BB=GG=RR=t native_powr(iter,2)
    "}"
    ;mit den farbfunktionen kann man endlos spielen^^

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

    ;pow(iter + 1 - log2 (log2 (x*x+y*y)/log(4))/log(2),3)
    ;

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

    ;Daten
    global $width = 256 * 3 ;breite und höhe der gui/grafik, die Anzahl der "Threads" sollte ein Vielfaches von 16 sein!
    global $height = 256 * 3
    Global $dll = DllOpen("user32.dll")
    Global $mouseflag = 1
    global $fps = 0

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

    Opt("GUIOnEventMode", 1)
    Opt("MouseCoordMode", 2)

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

    $hgui = GUICreate("Apfelmännchen", $width, $height, 1, 1) ;GUI erstellen
    $hdc_gui = _WinAPI_GetDC($hgui) ;HDC holen zum blitten
    GUISetState()
    GUISetOnEvent($GUI_EVENT_CLOSE, "_Exit")
    GUISetOnEvent($GUI_EVENT_PRIMARYDOWN, "_mousedown")
    GUISetOnEvent($GUI_EVENT_SECONDARYDOWN, "_mousedown")
    AdlibRegister("_fps", 1000) ;FramesPerSecond

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

    ;bitmap erzeugen, in $ptr_bitmap steht nach dem Funktionsaufruf der Pointer auf die Pixeldaten
    Local $ptr_bitmap, $hbmp_bitmap ;byref
    $hDC_bitmap = _CreateNewBmp32($width, $height, $ptr_bitmap, $hbmp_bitmap) ;DC, Pointer auf die Bitmapdaten und ein Handle für GDI+....eine eierlegende Wollmilchsau

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

    Global $DATA_SIZE = $width * $height ;bildgröße=anzahl pixel (rgba)
    Global $NULL = 0

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

    ;ab hier gehts mit OpenCl los
    ;was wird gebraucht?
    ;Buffer für Output der Daten in der Größe der Bitmap, also

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

    ;Zunächst werden die verfügbaren Geräte(Devices) gesucht.
    _CL_GetDevice("ALL") ;..oder CPU oder GPU, ermittelt das Gerät, auf dem die Berechnungen durchgeführt werden.

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

    ;Puffer für die Bitmap
    $output_buffer = DllStructCreate("dword[" & $DATA_SIZE & "]", $ptr_bitmap);halleluja! bitmaps werden immer 16byte-aligned!
    $CL_buffer_out = _CL_CreateBuffer($output_buffer)

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

    Global $maxiteration = 89 ;maximale iterationen
    Global $centerx = -.5 ;mitte Bild in x-richtung
    Global $centery = 0 ;mitte bild in y-richtung
    Global $apfelbreite = 3 ;breite des Bildinhalts x-richtung

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

    ;Parameter an den Kernel übergeben
    _CL_SetArg(0, "ptr*", $CL_buffer_out)
    _CL_SetArg(1, "uint*", $width)
    _CL_SetArg(2, "uint*", $height)
    _CL_SetArg(3, "float*", $centerx)
    _CL_SetArg(4, "float*", $centery)
    _CL_SetArg(5, "uint*", $maxiteration)
    _CL_SetArg(6, "float*", $apfelbreite)

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

    $CL_DEBUGFLAG = 0 ;Debug-Ausgabe ausschalten, um Geschwindigkeit zu erhöhen
    ;Schleife zur Anzeige für den Flug
    While 1 ;endless loop...
    _steuerung()
    _CL_SetArg(3, "float*", $centerx)
    _CL_SetArg(4, "float*", $centery)
    _CL_SetArg(5, "uint*", $maxiteration)
    _CL_SetArg(6, "float*", $apfelbreite)
    _CL_RunKernel($DATA_SIZE, 0) ;Kernel ausführen, da im Kernel SIMD verwendet wird, nur 1/4 der Threads nötig!
    _CL_ReadBuffer($CL_buffer_out, $output_buffer);Puffer(alle Pixel) lesen
    _WinAPI_BitBlt($hdc_gui, 0, 0, $width, $height, $hDC_bitmap, 0, 0, $srccopy) ;Bitmap in die GUI blitten
    $fps += 1 ;Frames pro Sekunde zählen
    WEnd

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

    ;...das wars schon^^

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

    Func _CreateNewBmp32($iwidth, $iheight, ByRef $ptr, ByRef $hbmp) ;erstellt leere 32-bit-Bitmap; Rückgabe DC und ptr und handle auf die Bitmapdaten
    ;by Andy
    Local $hcdc = _WinAPI_CreateCompatibleDC(0) ;Desktop-Kompatiblen DeviceContext erstellen lassen
    Local $tBMI = DllStructCreate($tagBITMAPINFO) ;Struktur der Bitmapinfo erstellen und Daten eintragen
    DllStructSetData($tBMI, "Size", DllStructGetSize($tBMI) - 4) ;Structgröße abzüglich der Daten für die Palette
    DllStructSetData($tBMI, "Width", $iwidth)
    DllStructSetData($tBMI, "Height", -$iheight) ;minus =standard = bottomup
    DllStructSetData($tBMI, "Planes", 1)
    DllStructSetData($tBMI, "BitCount", 32) ;32 Bit = 4 Bytes => AABBGGRR
    Local $adib = DllCall('gdi32.dll', 'ptr', 'CreateDIBSection', 'hwnd', 0, 'ptr', DllStructGetPtr($tBMI), 'uint', $DIB_RGB_COLORS, 'ptr*', 0, 'ptr', 0, 'uint', 0)
    $hbmp = $adib[0] ;hbitmap handle auf die Bitmap, auch per GDI+ zu verwenden
    $ptr = $adib[4] ;pointer auf den Anfang der Bitmapdaten, vom Assembler verwendet
    _WinAPI_SelectObject($hcdc, $hbmp) ;objekt hbitmap in DC
    Return $hcdc ;DC der Bitmap zurückgeben
    EndFunc ;==>_CreateNewBmp32

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

    Func _fps()
    WinSetTitle($hgui, "", "Apfelmännchen " & $fps & " FPS")
    $fps = 0
    EndFunc ;==>_fps

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

    Func _Exit()
    Exit
    EndFunc ;==>_Exit

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

    Func _mousedown()
    $mouseflag = 1
    EndFunc ;==>_mousedown

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

    Func _steuerung()
    If WinActive("Apfelmännchen") Then
    If _IsPressed("01", $dll) Then _leftmouse()
    If _IsPressed("02", $dll) Then _rightmouse()
    EndIf
    EndFunc ;==>_steuerung

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

    Func _leftmouse() ;zoom in
    If $mouseflag Then ;neues center
    $posx = MouseGetPos(0)
    $posy = MouseGetPos(1)
    $centerx = ($centerx - $apfelbreite / 2) + $posx * $apfelbreite / $width
    $centery = ($centery - $apfelbreite / 2) + $posy * $apfelbreite / $height
    $mouseflag = 0
    EndIf
    $maxiteration /= 0.99785 ;Iterationen erhöhen
    $apfelbreite *= 0.985
    EndFunc ;==>_leftmouse

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

    Func _rightmouse() ;zoom out
    If $mouseflag Then ;neues center
    $posx = MouseGetPos(0)
    $posy = MouseGetPos(1)
    $centerx = ($centerx - $apfelbreite / 2) + $posx * $apfelbreite / $width
    $centery = ($centery - $apfelbreite / 2) + $posy * $apfelbreite / $height
    $mouseflag = 0
    EndIf
    $maxiteration *= 0.99785 ;Iterationen erhöhen
    $apfelbreite /= 0.985
    EndFunc ;==>_rightmouse

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

  • [OpenCL] Einfaches Rechnen auf GPU

    Zitat von Techmix

    So wie ich das rausgelesen habe könnte man viel von dem WinAPI und GDI+ Krams doch tatsächlich beschleunigen... Ich bin mal gespannt wie sich das mit OpenCL weiter entwickelt!

    Beschleunigen nur im Sinne von ersetzen!

    Zitat von Marsi

    Wahrscheinlich müsste man eine komplett neue UDF herstellen, die die GDI+ Befehle (oder äquivalente) beinhaltet, diese aber komplett per OpenCL/GL ausführt.

    Genau so siehts aus....
    WinAPI / GDI "emuliert" ja auf unterstem Level die BIOS-"Grafik"-Funktionen. Jeder noch so simple Kram wird komplett von der CPU ausgeführt.
    Man müsste es mal testen, aber ich bin überzeugt, ein XP würde auf einem 80386 (nicht sx, der konnte nur 24 Bit^^) mit integrierter VGA (640x480x16) starten und laufen...
    Sämtliche "Grafik" (d.h. alles ausser dem Textmode) wird auf der CPU berechnet und als Bytes in den Speicher (RAM) geschrieben, drei Digital/Analogwandler (DA) wandeln (Converieren) die Bytes im Speicher zu Rot-Grün-Blau-Monitorsignalen. Den dafür zuständigen Chip nennt man daher RAMDAC (für analoge Monitore)

    Zitat von Marsi

    Funktionen wie z.B. ein Rechteck füllen oä traue ich mir schon zu

    hehe, ich traue dir da noch wesentlich mehr zu^^, aber das Beispiel ist gut!
    Ein Rechteck ist ein Haufen Pixel, nehmen wir mal der Einfachheit halber an, 1000x1000 Pixel sollen ROT dargestellt werden (0x000000FF weil ABGR).

    - Vorgehen "Rechteck füllen" per GDI (seit Windows 1.0):
    Die CPU arbeitet eine Schleife ab, startet am Anfang des für die Grafik reservierten Speichers und rast durch das RAM. Mindestens eine Million (1000x1000) mal nacheinander wird geprüft, ob sich das "Pixel", also die zzt. aktuelle Speicherstelle im RAM, im Rechteck befindet, wenn ja, dann wird 0x000000FF an die Speicherstelle geschrieben, ansonsten bleibt die Speicherstelle unverändert. Ist der Speicher beschrieben, weist das GDI wiederum über die CPU den Treiber der Grafikkarte an, bitteschön die komplette Grafik über den PCI-Bus ins RAM der Grafikkarte zu "kopieren", damit dort der RAMDAC....na das wisst ihr ja jetzt schon^^
    Aufwand für die CPU, niedrig geschätzte 3-5 Millionen Takte....pro Frame, bei "flimmerfreien" 30FPS muss die CPU pro Sekunde gewaltig ackern...

    - Vorgehen "Rechteck füllen" per OpenGl, DirectX (D3D) oder anderen hardwarebeschleunigten Funktionen:
    Die CPU sendet an den Treiber der Grafikkarte den Befehl: "Fülle Rechteck von x0,y0 bis x1,y1 mit 0x000000FF". Geschätzter Aufwand für die CPU, 2000 Takte (1000fach schneller!)
    Die moderne Grafikkarte hat nicht nur ein winziges eigenes RAM und einen RAMDAC, sondern eine gewaltig großes RAM und mehrere hundert Prozessoren neben Recheneinheiten (in Hardware), welche ausschliesslich für u.a. den Befehl "Fülle Rechteck von x0,y0 bis x1,y1" oder "Zeichne Linie von x0,y0 bis x1,y1 " oder "Fülle Kreis mit Mittelpunkt x0,y0 und Radius r" gebaut wurden! Da in Hardware realisiert, dauert die Ausführung solcher Befehle nur eine Handvoll Takte. Dank des großen Speichers wird auch nichts mehr kopiert, sondern einfach der zzt. darzustellene Bildschirmbereich im RAM gemapped, also die Startadresse innerhalb des Grafikrams geändert.
    Für spezielle, nicht in Hardware gegossene Funktionen bleiben die vielen parallel arbeitenden, programmierbaren Prozessoren, die sog. Shader. Es wird unterschieden in Pixelshader um Bildpunkte in der Farbe zu ändern, Vertexshader um komplexe Objekte zu berechnen bzw in der Grafik zu verändern und neuerdings auch Geometrieshader, um Objekte und Geometrien der Grafik hinzuzufügen. Alle diese Shader können parallel arbeiten, um also beispielsweise 50 Dreiecke auf den Bildschirm zu zeichnen wären genauso viele Takte nötig wie für 2 Dreiecke.

    OpenCl benutzt weitere Recheneinheiten der GPU, die Processing Units.
    Z.B. komplexe Filter werden blitzschnell berechnet, da die Grafikdaten nicht mehr aus bzw in den Hauptspeicher kopiert werden müssen, sondern das RAM der Grafikkarte nicht mehr verlassen. Sämtliche Berechnungen laufen komplett auf den Prozessoren der Grafikkarte, für rechen- und speicherintensive Kernel steht jedem Shader bzw Processing Unit eigenes lokales (ultraschnelles) RAM zur Verfügung. Die CPU hat somit weniger zu tun und es bleiben Kapazitäten frei für bspw. aufwendige Berechnungen, die sich schlecht parallelisieren lassen.

    Zitat

    Aber einen Grafikpuffer (analog zu GDI+Graphicscreatefromhwnd) oder Ähnliches werde ich nicht hinbekommen...

    brauchst du auch nicht, denn OpenGl stellt diese Funktionen alle schon zur Verfügung.

    Zitat

    Mal sehen zu was das langsame AutoIt noch so befähigt wird

    hehe, AutoIt bleibt das einfache Interface für schnelle und kurze Scripte. Man hat nun die Möglichkeit, Funktionen bzw Berechnungen extrem zu beschleunigen, ohne auf hochoptimierten C++- oder Assemblercode zurückgreifen zu müssen.
    Der Haken dabei ist, nur selten wird man ohne "knowhow" diese Geschwindigkeit erreichen. Beispiel Arraysort(). Da definitiv kein Zugriff über Pointer auf die Datem im "Array" möglich ist, wird man zwangsläufig sein Script auf DllStructs aufbauen müssen um OpenCl zu nutzen. Das macht den Code unleserlich und "schwerfällig". Der Vorteil von AutoIt ist dahin....
    Ob man nun unleserlichen AutoItcode debuggen muss oder unleserlichen C++-Code, ist egal^^, aber die gängigen Compiler haben schon sauschnelle hochoptimierte CPU-Bibliotheken, damit wird der Abstand zu GPU-OpenCl wesentlich geringer!

  • [OpenCL] Einfaches Rechnen auf GPU

    Zitat von marsi

    - Funktion ähnlich wie _WinAPI_AlphaBlend aber mit (bi)kubischer Interpolation.
    - Blur (Gaussche Unschärfe)
    Ich denke diese Funktionen würden stark profitieren, da im Prinzip eine Schleife durchläuft und alle Pixel abzählt (in beiden Fällen) und bearbeitet. Das lässt sich bestimmt gut paralellisieren.
    Und man könnte (sofern der Alphablendersatz schnell ist) vllt auch mal größere/mehr Grafiken nutzen ohne direkt auf 100% Programmauslastung zu kommen.

    Sorry marsi, hatte deinen Post glatt überlesen...ja, sämtliche gängigen Grafikfilter lassen sich durch die Parallelisierung extrem beschleunigen.
    Mit dem netten Nebeneffekt, daß die CPU sich in den "Schlafmodus" begibt, und daraufhin das Programm langsamer wird! Kein Witz, wenn ich auf meinem AMD-Prozessor QnQ aktiviere und per AMD Power Monitor die Aktivität der Kerne überwache stelle ich z.B. beim Tunnelflug fest, daß der Prozessor (CPU) sich von 3200 auf 800 Mhz runtertaktet und somit die FPS um ca. 20-30% einbrechen...
    Die CPU schiebt die Daten zur Graka, legt sich schlafen, wird per Aktivität auf dem PCI-Bus durchs zurückschreiben ins RAM wieder geweckt, usw usf.
    Deaktiviere ich QnQ läuft die CPU permanent mit "Vollgas" und die FPS stellen das obere Limit dar.
    Das ist natürlich nur, weil ich für das Beispiel das blödsinnige blitten verwende, d.h. die Graka schiebt die Ergebnisse der Berechnung ins RAM und die CPU schiebt per "Blit" die Grafik wieder zur Graka....
    Ergo kommen wir zu deiner nächsten Frage^^

    Zitat

    Kommt man irgendwie an den Grafikpuffer für das Ausgabebild welches auf den Schirm gelangt ?
    Dann könnte man vllt sowas wie eine Bitmap im Grafikram anlegen die dann extrem schnell bearbeitet und angezeigt/skaliert usw. werden kann.
    Am besten wären alle Verwendeten Grafiken in einem Spiel komplett im Grafikram.

    Yepp, SEHR einfach über OpenGl.
    Erstellst du die Grafik bzw. das Fenster in OpenGl, kannst du diese Daten (Grafiken) entweder direkt über die Shader per OpenGl oder aber ohne weiteres direkt mit OpenCl bearbeiten.

    Zitat

    Dann müsste nicht mehr so viel über den Bus.

    hehe, dann geht NICHTS mehr über den Bus bis auf die Handvoll Steuerbytes vom Treiber....also kein Blitten mehr, kein GDI-Gedöns und natürlich auch schnarchlangsame Grafik, wenn z.B. auf Netbooks die Grafik"hardware" emuliert werden muss.....aber einen Tod muss man immer sterben^^

    Ich würde gerne das passende Beispiel OpenGL & OpenCl in AutoIt vorstellen, der Tunnelflug sollte dann 1000 FPS locker erreichen. Die reinen Ausführungszeiten des Tunnelflug-Kernels auf der Graka sind 0.0irgendwas Millisekunden. Die Schieberei der Daten über den Bus ins RAM und von dort wieder zur Graka (blitten) dauert 100x bis 1000x so lange!!!
    Leider kann ich zzt. nur extrem wenig in Sachen AutoIt machen, der Tag hat nun mal nur 28h :D
    Aber ich bleibe am Ball 8o (ausserdem hat mein Datenkompressions-Kernel erste Priorität, da kombiniere ich einige der gängigen Verfahren mit eigenen Ideen)

  • [OpenCL] Einfaches Rechnen auf GPU

    Zitat von progandy

    Andy: _ArraySort oder _ArraySearch wäre ein perfekter Kandidat, wenn man keine DLLStructs erstellen müsste (BitonicSort)


    ja, aber das müsste man einfach mal ausprobieren. Letztendlich ist einfach nur die Frage, ab welcher Listengröße sich der overhead von der Konvertierung des Arrays in eine Struct, die anschließende Sortierung und das Zurückschreiben in ein Array lohnt...
    Um Arrays ganz zu vermeiden, hatte ich aus genau dafür mal eine Funktion geschrieben, die bestehenden "Array"-Code in "DllStruct"-Code umwandelt, d.h. den kompletten AutoIt-Quellcode von Array nach Struct umschreibt. Das war eigentlich recht simpel und hatte gut funktioniert. Ich wollte einfach mal die Geschwindigkeit vergleichen, und die war in einem "normalen" AutoIt-Programm in etwa gleich, daher habe ich mich nicht weiter hineingekniet.
    Mit Hinblick auf OpenCl sieht das natürlich schon anders aus....
    Gerade bei Programmen, welche große Arrays oft sortieren bzw. im Array suchen müssen, wäre der Geschwindigkeitsvorteil eklatant!

  • Neue AMD "Bulldozer"-Architektur - was haltet ihr davon?

    Zitat

    Andy, die von dir erwähntes Bibliotheken: kommen die sicher und was denkst du wann?

    Die werden sicher kommen, die Frage ist wann...
    AMD ist nicht gerade bekannt dafür, Produktvorteile in der Hardware auch in dementsprechender Software (Treiber, Bibliotheken usw.) SCHNELL bzw. frühzeitig umzusetzen!
    Daher habe ich in meinen Favoriten im Browser schon diese Seite gebookmarkt.

    Bestes Beispiel ist wieder einmal der Launch des Bulldozers. Anstatt mit einem "modifizierten" Benchmark die neuen Features vorzuführen und schon bei der Produktvorstellung mit der Leistung zu protzen (wie alle anderen Prozessorhersteller das auch machen) wird ein Chip auf den Markt geworfen und den Programmierern gesagt:"Seht her, was der Neue alles kann, aber die Features benutzen könnt ihr....äääähmmm irgendwann einmal....".
    Wieso wird nicht ein Softwarepaket vorgestellt, daß die Leistung des Prozessors ausnutzt...und wenn es nur ein billiges ZIP-Progrämmchen gewesen wäre, oder 2-3 Photoshop-Filter, oder ein AES-En/Decoder, ein Browser-Plugin oder oder oder :huh:
    Wenn Intel eine neue Generation Prozessoren vorstellt, ist die Bapco-Suite bereits darauf "vorbereitet" :rolleyes:

  • [OpenCL] Einfaches Rechnen auf GPU

    Hi!
    :thumbup:
    Genau SO fängt es an, erst spielt man bissl damit (Opencl) rum um mal ein Gefühl für die Sache zu bekommen, und später führt die Grafikkarte schnelle Funktionen aus...

    Wer hat Ideen, welche bestehende (langsame) AutoIt-Funktion bzw. UDF eine "Optimierung" vertragen könnte?