OpenCL meets OpenGL in AutoIt

  • Nochmal getestet:

    AMD Athlon 64 4000+ (2,4GHz SingleCore)
    auf einem 939NFG-VSTA Mobo.

    Mit der integrierten geht OpenGL, aber nicht CL.
    Mit einer Radeon 5450 mit Eyefinity geht alles ohne Änderung und auch ohne zu kompilieren.

    Anscheinend läuft das auf AMD wirklich besser *duck*

  • Die Frage ist, wieso bei einigen Usern mit Nvidia-Karte die CL- und auch die GL-Beispiele jeweils einzeln einwandfrei funktionieren, aber in Zusammenarbeit (Interoperability) dann Probleme auftreten...

    Die Kombination OpenCL auf CPU und OpenGL auf (wie auch immer GPU) ist sowieso schwierig. Ich vermute da einfach weniger Probleme in der API, als fehlerhafte oder komplett fehlende Unterstützung in den Treibern! Siehe auch diverse Forenbeiträge zu diesem Thema bei den Linuxern, dort wird die Kombination CL/GL sehr gerne verwendet!

  • Bei mir funktionieren Minx Beispiele auch. Hier die Ausgabe deines Scripts aus Beitrag #19:

    Spoiler anzeigen
  • Also ich hatte mir den Code von hier nicht mehr geladen, sondern mir eine eigene SDK zusammengezimmert, da Andy mir immer nur Bruchteile geschickt hat :D .

    Jedenfalls hatte ich mir mal eine GTX ausgeliehen. Mit den neuen NVIDIA Treibern funktioniert auch alles. Allerdings nur kompiliert.

    Die neuen Treiber lassen sich hier laden: http://www.geeks3d.com/
    Ein andere OpenGL/CL Benchmark lässt sich dort auch laden. Ich empfehle mit GPU Caps Viewer zu überprüfen ob die Karte bereit für OpenCL ist und dann einen Benchmark zu starten: http://clbenchmark.com/

  • Andy: die OpenGL Beispiele von minx funzen bei mir und hier der Output zu Post#19:

    Spoiler anzeigen

    Gruß,
    UEZ

    Auch am Arsch geht ein Weg vorbei...

    ¯\_(ツ)_/¯

  • Zitat

    Also ich hatte mir den Code von hier nicht mehr geladen, sondern mir eine eigene SDK zusammengezimmert, da Andy mir immer nur Bruchteile geschickt hat .

    was heisst Bruchteile, das war alles....mehr braucht man auch nicht.
    Und wenn man jetzt einen x-beliebigen Benchmark startet, der im Fehlerfall einfach abbricht bzw. "geht nicht" anzeigt, dann kommt man auch nicht wirklich weiter...

    Zitat

    Die neuen Treiber lassen sich hier laden: http://www.geeks3d.com/

    DAS ist genau der allergrößte Fehler!!!
    IdR empfehle ich auch die neuesten Treiber, allerdings ist das bei der Interoperability von OpenCL und GL (gerade bei AMD) nicht immer vorteilhaft. Die neuesten Treiber sind IMMER schnell zusammengestrickte, auf die letzte Rille fertig gewordene Konstrukte bei denen man HOFFT (nicht weiß ! ), dass die allerneuesten Features der allerneuesten Grafikkarten unterstützt werden.
    Jedenfalls habe ich mir schon mit neuen Treibern auf dem Laptop massiven Ärger, und nicht nur in der Grafikdarstellung, sondern auch mit Blackscreens nach dem Aufwachen aus dem Standby/S3+4 eingehandelt. Mit dem alten Treiber lief alles wunderbar, nur bekomm mal einer den neuen Treiber komplett aus dem System geschmissen...
    Wenn jemand eine 3 Jahre alte Grafikkarte hat und mit dem damals aktuellen Treiber der Rechner problemlos läuft, dann besteht auch kein Grund, ohne Not den Treiber zu updaten!
    Übrigens ist die verwendete CL/GL Version bzw. deren SDK sehr eng mit den Treibern verknüpft, wenn, dann sollte man schauen, dass beides zusammenpasst, siehe Seite (Text auch mal durchlesen ^^ ) hier ganz unten!

    Trotz allem sollte man die bei minx´s geposteten CL-Benchmark-Link auf der rechten Seite die Hinweise beachten!

    //EDIT// Ich spreche solche "Kleinigkeiten" an, wie die unter den Tisch gekehrte Mitteilung von bspw. AMD, dass mit Runterladen der allerneuesten Treiber und CL (Version 1.2 )-SDK´s keine 32-Bit-Betriebssysteme mehr unterstützt werden!
    Wer also Open CL und GL zusammen auf z.B. XP32 benutzen möchte (was einwandfrei funktioniert! ) muss die passenden Treiber und das CL-SDK Version 1.1 installieren!
    Wie das Bei Nvidia/Intel aussieht sollte man dort abgleichen!

    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 (28. April 2013 um 14:24)

  • Hey Andy, das mit dem $num.. in Zeile 107 hat ein wenig bei der einzigen Datei die GLCL_easy.au3 included geholfen. Die MsgBoxen kommen da nicht mehr, die Kerneltime erhöht sich (von 0.3 auf 16, er macht endlich was), aber es kommt trotzdem kein Tunnelflug auf dem Bildschirm an. Vielleicht wegen dem defekten Buffer. (Wieso benutzt du GLCL_easy nicht bei den Würfeln? Da hatte ich die ganze Zeit getestet ^^)
    Nachm Compilen kommt der gleiche Error wie schon erwähnt, nachdem das Fenster inaktiv war ist die Kerneltime auch wieder runter auf 0.3 und bleibt da.

    Console:

    Spoiler anzeigen

    Screenshot (das Bild bleibt exakt so, keine Bewegung):
    autoit.de/wcf/attachment/20897/


    mfg

  • Hi,
    TheShadowAE,
    lt. deiner Console müsste es durchlaufen, sowohl GL als auch CL werfen keine Fehler....

    Zitat

    Wieso benutzt du GLCL_easy nicht bei den Würfeln? Da hatte ich die ganze Zeit getestet )

    weil ich ein fauler Sack bin....
    Nein, ich dachte mir schon, dass es bestimmt nicht auf Anhieb glatt läuft (Intel/Nvidea), dafür habe ich mich zu lange mit dem Dreck beschäftigt :huh:
    Also CL läuft nun auf deiner Grafikkarte, das ist schon mal gut, nun müssen wir das nur noch hinbekommen mit der "richtigen" Grafikausgabe im Fenster.
    Die Würfel scheint es ja schon mal zu zeichnen^^, ggf kann minx mit dem Bild was anfangen....

    Hmmm, anhand der FPS und der Kerneltime könnte es sein, dass doch deine CPU verwendet wird^^
    Probier mal in Zeile 66 testhalber von setGLCLautokernel() in

    [autoit]

    setGLCLautokernel("CPU")

    [/autoit]

    und wenn das nicht funzt dann nochmal in Zeile 107 zurück zu $num....=1

    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 (28. April 2013 um 21:44)

  • Hier mein Egebnis von der "wuerfel_GLCL_mandelbrot.au3" :

    Spoiler anzeigen

    Nach den Fehlermeldungen die auch schon name22 in Post 6 hat, kommt dann das Bild.:D
    Die Würfel bewegen sich auch.

    Um Missverständnisse zu vermeiden, mein Name rührt vom Sternenbild und nicht vom Shop her :D


    Rainbow Dash :rock:

    "Das, wobei unsere Berechnungen versagen, nennen wir Zufall." (Albert Einstein)

  • Bei ("CPU") und $num..=1 gibts:
    Error in Function clCreateContextFromType
    Returncode: CL_DEVICE_NOT_FOUND
    Danach erscheint das Bild im letzten Post (was keine Würfel sind eigentlich. Beim ersten Versuch von Mandelbrot würfel hatte ich das gleiche Bild wie Orion nur dass die Würfeltextur komplett weiß war.)

    Bei ("CPU") und $num..=2 gibts (beef):
    Error in Function clGetDeviceIDs
    Returncode: CL_INVALID_PLATFORM
    und danach ein saftiges "Autoit funktioniert nicht mehr"

    Bei $num=1 und ("GPU"):
    Error in Function clCreateFromGLBuffer
    Returncode: CL_INVALID_CONTEXT
    Und dann bereits erähnte Bild (Screenshot)

    Bei ("GPU") und $num=2 sinnvollerweise das gleiche wie im letzten Post (also keine MsgBox)


    EDIT:
    Wenn in der Mandelbrot-Würfel in Zeile 247 ebenfalls auf $num=2 mache, dann gibts auch keinen Fehler mehr, aber schwarzen Bildschirm. Der bereits bekannte glewBufferData Fehler ist der erste Fehler in der Console.

    EDIT 2:
    In GLCL mandelbrot flug das gleiche Spiel, keinn Error mehr, allerdings den gleichen Screenshot wie im letzten Post beim Tunnelflug.

    Einmal editiert, zuletzt von TheShadowAE (29. April 2013 um 18:01)

  • Orion,
    Alda, dem is ULTRAKRASS! :D
    Sehr cool, was eure Grakas alle so darstellen....wenn ich das richtig sehe, ist das ein Teil des Hintergrundes, der auf die Würfeloberflächen projeziert wird?!
    Welche Hardware hast du?

    TheShadowAE,
    danke fürs Testen!
    Ich werde wohl nicht drumrum kommen, alle verfügbaren Platforms abzuklappern und dort nach einem Device zu suchen, welches eine GPU ist....
    Dann wäre das zumindest schon einmal geklärt.
    Solange die sich drehenden Würfel dargestellt werden ist es ja schonmal halb fertig^^

  • Öhmm Ja :whistling::D:D

    Bei den anderen Beispielen kommt das gleiche wie bei TheShadowAE in Post 27.
    Nur mit den Texturen, welche übrigens aus dem autoIt.de Forum kommen kein Plan wieso :D:whistling:
    //Edit: Ok die kommen auch, wenn ich autoIt.de minimiere oder schließe :D

    Graka: NVIDIA GeForce 8400GS Aktueller Treiber

    Um Missverständnisse zu vermeiden, mein Name rührt vom Sternenbild und nicht vom Shop her :D


    Rainbow Dash :rock:

    "Das, wobei unsere Berechnungen versagen, nennen wir Zufall." (Albert Einstein)

    2 Mal editiert, zuletzt von Orion (29. April 2013 um 23:46) aus folgendem Grund: WoW :D

  • Ich habe übrigens das selbe Phänomen wir Orion, vielleicht erkennt man das nicht so gut auf dem Screenshot. ;)
    Meine Hardware kennst du ja, und mein Treiber ist auch immer aktuell.
    Mich würde wirklich interessieren wie das zustande kommt, wenn du es rausfindest behalt es nicht für dich :D.

  • Durch die Verknüpfung mit der DC wird eine eindeutige Verbindung mit der Oberfläche oder dem Hintergrund hergestellt, irgendwie schleicht sich dann der Hintergrund in den Buffer der Texturen ein ^^ (oder die falsche Textur wird um übertragen / zeichnen verwendet ^^)

    Mein Treiber ist übrigens auch aktuell

  • Hi,
    sehr gut, das hilft weiter! Die Buffer werden nicht richtig initialisiert.
    Es sieht dann wohl so aus, als ob das Problem nicht bei CL, sondern (wie ich schon seit einem Jahr vermute) bei GL liegt!
    Also eher weniger bei GL direkt, sondern bei AutoIt, das irgendetwas im Hintergrund macht, was nicht so astrein ist.
    Ich habe auf dem WIN7-Laptop teilweise nämlich sehr seltsame "Kamm-Artefakte", die ab und zu , wenn das Script kompiliert wird, nicht auftreten.
    Denn wenn ich die CL/GL-Beispiele der SDK´s mit C++ kompiliere (VS2010) läuft alles einwandfrei. Ich habe die Beispiele, welche ja auch nur die GL-API aufrufen, 1:1 nach AutoIt portiert und dort gibt es teilweise Anzeigefehler...