GetUniqueColors

  • Man sieht: Die Intel HD620 ist ähnlich schnell wie eine Nvidia 630GT^^

    :D...wart mal auf die integrierte Grafik bei den Ryzens, die kommen sicherlich schon zur nächsten Cebit...da wird der Markt der Grakas bis 100 Euro komplett zusammenbrechen!


    Übrigens sieht man aber auch, was die GTX1060 trotz des Speichergeschiebes und des "langsamen" AutoIt reißt! Und diese Graka ist definitiv nicht dafür bekannt, bei OpenCL die Wurst vom Brot zu ziehen :o)

    https://browser.geekbench.com/opencl-benchmarks

  • Von Intel gibts auch integrierte Grafikchips die anständig Leistung haben, die werden aber irgendwie nie verbaut (z.B. Iris 650 die etwa so stark wie 50-60€ Grakas ist, also ca. 2x so schnell wie die 620). Wenn das Teil allerdings nur auf einem einzigen Prozessor der von Schamanen in einem heiligen Ritual unterwasser am Nordpol um 12 Uhr Mittags geweiht wurde verbaut wird kann man damit nix reißen.

    Wenn AMD da angreift und integrierte Chips rausbringt die wie eine 1050 laufen muss Intel liefern, sonst sind sie geliefert.

  • Wenn AMD da angreift und integrierte Chips rausbringt die wie eine 1050 laufen muss Intel liefern, sonst sind sie geliefert.

    Zwar etwas OT aber:

    Intel wird dann auch liefern. AMD hat nach langer Zeit endlich mit Ryzen wieder ordentlich Druck gemacht und Intel hat mit der 8000er Generation endlich den Arsch hochbekommen.
    Schau dir mal die PassMark Scores zwischen der 6000er (7226) 7000er (8091) und 8000er (11687) Serie an.

    Die 8000er war die erste wirkliche Antwort auf Ryzen, davor wurde einfach nur rebrandet oder geringfügig an der Architektur geschraubt und bisschen die IPC erhöht, weil eben AMD nichts zu bieten hatte.

    Man kann also ziemlich sicher sagen, dass Intel bald ebenfalls was liefern wird.

    AMD hat mit Ryzen schön den Markt angezogen und hoffentlich werden sie am Ball bleiben und ein schönes Follow-Up (unter anderem die iGPUs) bieten.

  • Noch etwas zum Thema OpenCL-Code GPU vs CPU:

    Der in den Treibern integrierte OpenCL-Compiler erstellt aus dem CL-Kernel Code spezifisch für das verwendete Device. Es wird also für eine GPU der entsprechende Maschinencode generiert, der natürlich "anders" aussieht wie der Code für eine CPU.

    Dabei hat der Compiler das grundlegende Problem, aus dem Quellcode für die jeweilige CPU das schnellstmögliche Ergebnis rauszuholen. Was dazu führt, dass je nach Quellcode auf der CPU(!!!) ein mit einer anderen Programmiersprache bzw. Compiler erstellter Code etwas schneller sein kann. OpenCL hat den großen Vorteil, dass man sich nicht um Multithreading kümmern muss, der Compiler nutzt idR. alle verfügbaren Cores! Dann noch SIMD, und das obere Ende der Fahnenstange ist erreicht!

    Die Verwendung von lokalem Speicher (Cache) und anderen Beschleunigungsmechanismen sollte man allerdings immer im Auge behalten.

    Auch auf der GPU ist bspw. durch die Verwendung von lokalem Speicher und anderen Tricks noch reichlich Optimierungspotenzial vorhanden.

    Kein Wunder, dass CUDA im rechenintensiven Bereich so stark verbreitet ist....

  • Bei mir sieht das so aus:

    Also das Ergebnis der GPU ist ja schon nicht schlecht, aber das Ergebnis von der CPU ist dann ja doch schlechter als mein ASM-Code zum sortieren.

  • Also das Ergebnis der GPU ist ja schon nicht schlecht, aber das Ergebnis von der CPU ist dann ja doch schlechter als mein ASM-Code zum sortieren.

    Wie bereits gesagt, dein ASM-Code ist handoptimiert :thumbup:und läuft "in einem Rutsch" durch.

    Algorithmusbedingt wird aus AutoIt 300x der OpenCL-Kernel aufgerufen incl. allen Speichergedöns. Selbst in der SIMD-Variante ist da nicht mehr viel zu holen....


    Das schöne ist, man kann sich den vom Compiler erstellten (ASM-) Code ausgeben lassen. Erfahrungsgemäß ist der vom Compiler erstellte Code für die CPU sooo schlecht aber nicht. Da noch die beiden Schleifen drumrum und man hat noch was zum rumspielen:saint:


    Ggf. findet sich ja ein Sortier-Kernel, welcher nicht mehrfach aufgerufen werden muss, dann verbessert sich das Ergebnis sicher massiv, selbst wenn der Algorithmus als "langsamer" eingeordnet wird!

    Oder einer der hier im Forum reichlich vorhandenen C/C++-Programmierer hat ein erbarmen und schreibt uns fix nen Kernel....schaumamal...:theke:

    Wobei dann lediglich die Frage ist, inwieweit die Sortierfunktion von der GPU profitiert. auf der CPU ist ja mit MT und SIMD sowieso alles erreichbare ausgenutzt.

  • AspirinJunkie

    Ich bekomme den "simplen" Radix-Sort nicht zum laufen. Zwar habe ich unter AutoIt den Kernel in einigen Minuten zum Laufen gebracht, aber die Sortierergebnisse sind falsch....

    Leider kann ich mangels passendem C++-Compiler nicht verifizieren, ob das C++-Programm überhaupt funktioniert.

    Könnte das mal jemand prüfen?

  • Ich schau mal wann ich wieder bisschen mehr Zeit finde.

    Dann bastel ich auch noch was mit OpenCL dazu.

    Ein Radix-Sort sollte man auch noch selbst in OpenCL implementieren können.
    Momentan sehe ich aber noch keine Luft dafür - kommt aber noch - ganz sicher. ;)


    Zum Thema passender C++ - Compiler:
    MSYS2 wäre ein All-In-One-Paket für den gcc für Windows.

    Alternativ gibt es den Visual C++ Compiler auch ohne Visual Studio: https://blogs.msdn.microsoft.c…isual-studio-build-tools/

    Mit den Build-Tools hab ich auch die DLLs von dem Thread hier gemacht.

    Bei Fragen zur Config - gerne. Ist wie immer erst dann total simpel wenn man weiß wie.

  • Ein Radix-Sort sollte man auch noch selbst in OpenCL implementieren können.

    hehe, da bin ich gerade dabei...und zwar den vorliegenden Kernel zu debuggen. Ich sehe da aber schon großes Potenzial in einer etwas anderen Umsetzung. Wenn man auf der GPU schon viele WorkUnits hat, dann muss man die auch ALLE gefälligst arbeiten lassen...und nicht nur zweien VIEL Arbeit aufhalsen!

  • Hi zusammen,

    nach einigen Stunden experimentieren habe ich den Grund gefunden, wieso der von mir heruntergeladene vorliegende OpenCL-Kernel ab einer bestimmten Menge zu sortierender Daten fehlerhaft (genauer gesagt, gar nicht mehr) sortiert.

    Die GPU hat viele kleine Prozessoren (Work-Units), welche dafür ausgelegt sind, GLEICHZEITIG ein Problem zu lösen.

    Der vorliegende OpenCL-Kernel für RadixSort ist gewissermaßen "nur" eine Umsetzung eines Standard C(++)-Codes für die CPU. Ergo viele ineinander verschachtelte For/To-Loops. Die Laufzeit auf einer einzelnen GPU-WorkUnit dauert irgendwann recht lange (bei mir ca. 3-4 Sekunden) , und der OpenCl-Treiber bricht daraufhin die Berechnung ab!

    Dieses Abbrechen durch den Treiber hatte ich bisher noch nie feststellen können, idR. laufen die Kernel ja in einigen Mikrosekunden bzw. noch kürzer. IdR. dauert der Transfer von bspw. Bilddaten aus dem RAM zur GPU länger als die Berechnung bspw. eines Filters auf der GPU!

    Läuft der Kernel auf einer CPU mit "wenigen", d.h. 4-8 Kernen, dann ist Algorithmusbedingt die Laufzeit sowieso SEHR lange, d.h. bis zu mehreren Minuten. Der Treiber bricht auf den von mir getesteten CPU´s den Lauf allerdings NICHT ab!


    Es wird also ein Kernel gesucht, welcher die GPU bestimmungsgemäß auslastet....

    Etliche im Netz verfügbare Kernel haben genau das oben beschriebene Problem.