OpenGL BMP Viewer inkl. OpenCL "Morpher"

[Skysnake]

Sodele Leute, ich hab die Woche mit diesem Projekt hier zu getragen, wobei die meiste Zeit eigentlich aufs Debuggen des OpenCL Teils drauf gegangen ist...

OpenCL hat halt so seine Stopelfallen, in die man sehr gern rein tritt und dann erst mal ne Stunde oder länger nicht sieht, wo das Problem liegt. Naja, seid rum.

Hier mal ein kleiner Bild des im Titel beschriebenen Programms.

Auslastung der 5870@stock mit einem E8400@4GHz beträgt ~40%, mit >100 FPS. Sieht man ja im Afterburner

Falls mehr interesse daran besteht, meldet euch einfach

Das Ganze ist schon recht modular aufgebaut, ich werd aber noch weiter dran basteln, damit man vorm Start noch die Pfade für die Bilder angeben kann, die Geschwindigkeit, mit der zwischen den Bildern gewechselt werden soll usw. Das meist ist schon im Code drin, nur atm noch als #define implementiert. Ist also relativ schnell zu ersetzen.

EDIT:
Sodele hier die neuste Version, jetzt mit der Möglichkeit, den Morpher an/ab zu schalten mittels der Taste 'c'. Btw. Falls es noch nicht aufgefallen war, mittels 'awsd' kann man unter Windows das Bild verschieben, und unter Linux mit den Pfeiltasten. Windows zickt da irgendwie rum... Und mit + - kann man zoomen

EDIT2:
Und noch ne neuere Version. Das Bild wird nun nicht mehr kleiner, wenn man den "Morpher" laufen lässt. Ursache war, wie vielleicht schon gesagt, dass die Randwerte nicht initialisiert wurden und somit Werte >1.0 erreicht wurrden. Da alles was >=1.0 ist, als Weiß dargestellt wird, wurde das Bild immer kleiner.
Durch drücken von 'r' kann nun fortlaufend das aktuell dargestellt Bild als BMP abgespeichert werden. Erneutes drücken von 'r' deaktiviert die Funktion wieder. Im Moment ist das alles noch SEHR unperformant, also extrem langsam. Man brauch ca 1s pro BMP. Wenn ich Zeit habe, muss ich mich noch daran machen, die ganze Sache performanter zu schreiben.

EDIT3:
Mich hat die Performance so geärgert, das ich mich doch gleich dran gemacht hab. Das schreiben der BMPs ist jetzt etwa um einen Faktor 5 schneller, wenn nicht mehr. Sollte jetzt nicht mehr all zu stark stören

EDIT4:
Den "BurnIn Viewer" hinzugefügt
Benutzung auf EIGENE GEFAHR! Ich übernehme keine Haftung für Schäden an eurer Hardware! Achtet auf die Temperaturen usw.!

EDIT5:
Ich möchte nochmal ausdrücklich darauf hinweisen, dass das Programm ein extremer Stresstest ist. Ich empfehle jedem, die Lüfterdrehzahl vorher manuell etwas hoch zu ziehen, wenn ihr das Programm einige Minuten laufen lassen wollt. Ich hab kurz vor der Notabschaltung wegen überhitzung die Lüfterdrehzahl hoch gezogen. Achtet also bitte darauf. Nicht das sich noch jemand die GPU schrottet.

EDIT6:
Ok, ich hab jetzt das halbe Programm umgeschrieben, um von glDrawPixels weg zu kommen. Bis jetzt waren ja so ca 100 FPS drin. Eigentlich genug, nur war es eben ziemlich umständlich die ganzen Sachen hin und her zu kopieren. Also hab ich mich entschlossen jetzt Texturen zu verwenden, und siehe da, es ist "geringfügig" schneller So 8k FPS sind jetzt mit einer 5870 drin, wenn nichts berechnet wird. Sobald der Morpher angeschlatet wird, gehen die FPS natürlich ziemlich in den Keller, aber auch weniger als bisher. Ich hoffe euch freut diese "kleine" Performanceverbesserung, und nehmt was für eure eigenen Projekte mit. glDrawPixels ist SAUUUU langsam

Ok, also dann mal zum Programm. Wie ihr sicherlich sofort seht, haben die Bilder jetzt einen schwarzen Rand. Dieser rührt daher, dass ich die gesamte textur zeichne, aber eben einen Rand für die Randwerte benötige, um die Berechnungen durchführen zu können. Die Berechnung wurde jetzt auch flexibel gestaltet, sodass jedes Bild in seiner nativen Auflösung berechnet wird ohne einen Überstand. Ich denke der Rand stört niemanden, und ist sogar ganz nützlich, da man so sieht von wo bis wo das Bild geht. Falls gewünscht könne ich dies aber auch noch recht einfach umstellen, oder ein op_out/in daraus machen.

Im Moment müsst ihr leider darauf verzichten das Bild hin und her zu schieben, sowie zu zoomen, das wird aber in einer späteren Version wieder einzug halten.
'r' für Bilder abspeichern ist im Moment leider ohne Funktion, werde ich später aber wahrscheinlich wieder implementieren, im Moment habe ich dafür aber keine Zeit.

Ansonsten gibt es aber auch ein paar tolle Neuerugen
1. Mit ',' und '.' könnt ihr die Anzahl Iterationen erhöhen bzw. verringern.
2. Mit 'i' könnt ihr einen wert eingeben über die console. Hierfür müsst ihr die Console leider seperat anklicken, ansonsten nimmt diese die Eingaben nicht an.
3. Mit 'n' und 'b' könnt ihr durch die Bilder schalten
4. Mit 'v' könnt ihr den Morpher zurücksetzen.
5. Mit 'p' könnt ihr den Profile Modus anschalten, bei dem es sich praktisch um einen Benchmark handelt

Ihr könnt ja mal ein bischen rum spielen, und schauen, wie ihr die besten Ergebnisse erreicht.

Ich sag mal so viel dazu. Die Größe des Bildes spielt eine entscheide Rolle

EDIT 7:
Wegen Problemen mal gleich V1.1 nachgeschoben

 

[Skysnake]

Wäre nett, wenn mal jemand bei sich das Programm testen würde. Statisches Linken geht leider nicht wegen irgendwelchen blöden Abhängigkeiten.. Bekomm dann ne ellen lange Liste an Fehlern. Wäre also gut, wenn jemand das mal so testen könnte.

Wenns so funktioniert, passts ja auch, falls nicht, bitte sagen.

Also hier das Programm:

Die 24Bit BMPs einfach in den selben Ordner kopieren, wie die Exe. Ihr könnt n Bilder angeben. Bitte die Bilder beginnend von x= 0 bis n-1 durchnummerieren und mit dem Namen BMP_0.bmp bis BMP_x.bmp versehen.

 

[AMD]

Du solltest vllt. noch die glut32.dll mit in dein zip-Archiv packen^^ Aber ich hatte die auch so auf dem PC.

Was mir jetzt auffällt:
1. Ich habe eine Datei in den Ordner mit der exe getan (BMP_0.bmp) und bei dem Start des Programmes, habe ich eine 0 eingegeben.
Dann kommt: "FAIL Input buffer with new image data"
Gebe ich eine 1 ein, dann wird das Bild geladen aber die Meldung kommt trotzdem, weil bei 1 scheinbar 2 Bilder geladen werden sollen?!

2. Ist es normal, dass das Bild automatisch immer weiter verarbeitet wird? Also bei mir wird es immer etwas kleiner und unschärfer, bis es irgendwann komplett grau ist.


Edit// Was mir noch auffällt: Du solltest das Fenster, in dem die Bitmap Datei angezeigt wird, nach der größe der Bitmap anpassen.
Wenn man eine große BMP Datei läd, dann muss man das erst per Hand machen und das muss ja nicht sein Sollte ja mit glut keine Probleme sein.

 

[Skysnake]

Hm...

Also das mit der 0 und 1 stimmt schon. Die Namensgebung beginnt bei 0 und die Anzahl beginnt halt mit 1. Das stimmt so. Es sollte aber nicht zu dem Fehler kommen. Das muss ich dann nochmal nach schauen, was da schief läuft. DANKE für die Info

Die glut32.dll pack ich dann in Zukunft auch mal mit dazu Musstest du die einfach nur zur Exe kopieren oder an einen speziellen Ort?

Zu 2.
Ja, das ist normal Da läuft ein OpenCL Programm auf der GPU noch drüber, welches auf Grundlage der RGB-Channels für jeden Channel eine Hitzeverteilung berechnet. Die Randwerte passen allerdings noch nicht. Daher wird das Bild immer kleiner, wobei das auch eine legitieme Lösung ist. Ansonsten würde es halt mit der Zeit Schwarz statt weiß. Alles >1.0 wird halt als Weiß angezeigt und alles <= 0 als Schwarz. Soweit klar oder?

Zum EDIT:
Ja, das muss ich mal noch anpassen. Aber das sind so "Schönheitsfehler" die die Funktionalität erst mal nicht negativ beeinflussen. Das kommt dann mit der Zeit.

Btw. auf wieviel FPS kommst du mit dem Programm? Und welche Aulastung erreicht die GPU? Und was für ne CPU/GPU hast du im Einsatz?

 

[AMD]

Die glut32.dll einfach in den Ordner packen wo die exe ist und es läuft.


Also ich habe mir die FPS Anzahl mit Fraps angeschaut und die liegt ca. bei 100fps (schwankt zwischen 90 und 110). BMP hatte eine Auflösung von 512x512 - CPU: 2500k GPU: HD 5870
Die Grafikkarte wurde eig. garnicht ausgelastet. Beim CPU sah es schon anders aus: ca. 20% Auslastung. Wenn man das jetzt auf 4 Kerne verteilt und auf einen runter rechnet, dann war der CPU schon gut dabei.

 

[Skysnake]

Ja, die muss auch ständig ackern Hab ja keinen framelimiter drin.

Du solltest aber kaum negative Auswirkungen spüren, da die idle Funktion ein Sleep(0) drin hat. damit wird immer sofort das Rechenfenster wieder frei gegeben, laut Internet.

Die GPU sollte aber schon ordentlich ausgelastet werden. Ich hab so ~40% Auslastung, was jetzt gar nicht so schlecht ist für so einen primitiven Kernel.

 

[AMD]

Oh stimmt, ich hab sogar 50% Auslastung bei der GPU!
Ich hab bei mir in der Sidebar eine Anwendung, die die Ausleistung für gewöhnlich anzeigt aber die Daten werden nur alle paaaaaaaar Sekunden erneuert - hätte wohl länger warten sollen
Hab es auch nochmal mit GPU-z überprüft.

Edit// Du könntest auch noch glut gegen freeglut tauschen. Erhöht z.B. auch die Renderperformance ^^

 

[Skysnake]

wirklich?

Btw. ich muss eh noch einen zweiten Renderpfad bauen. Atm verwende ich glDrawPixel. Das ist suboptimal, aber anschaulich klar, was passiert. Die andere Möglichkeit funktioniert über eine Textur, was deutlich performanter sein soll. Das muss ich aber noch implementieren, und mir genau anschauen. Für meinen Fall geht es, aber als visuelle Darstellung von beliebigen Berechnungen, lass ich es wohl eher bei glDrawPixel

 

[AMD]

Jap.


glDrawPixel ist wirklich langsam. Denke mal die Texture auf einem Quad rauf und dann per Shader bearbeiten sollte wesentlich freundlicher sein - zumindest von der Geschwindigkeit her. Ob das nun viel Sinn hat ist die andere Frage. Wenn es mit dem Befehl läuft, dann ist's ja auch okay, zumal bei der Bildbearbeitung ja nicht auf jedes kleine bsschen Leistung geachtet werden muss (denk ich mal?!).

 

[Skysnake]

Die "Bildbearbeitung" ist nur eine Möglichkeit zur Visualisierung von wissenschaftlichen Berechnungen. Für mehr wird Sie nicht benutzt. Das BMP-Format habe ich halt gewählt, weil es leicht zu implementieren ist. Da ist nichts großes bei.

Die Grundlage für das Problem war halt die, das man oft an der Uni irgendwas rechnet, aber keine graphische Ausgabe dazu hat, und man dann halt meist zu QT greift, was dann halt schon ein ziemlicher Overkill ist, und vor allem auch immer wieder Probleme bereitet bei der Implementierung. Daher hab ich mir jetzt mit OpenGL halt was selbst geschrieben, was man auch anderen Studenten mal einfach so in die Hand drücken kann

Wie gesagt, der BMP-Writer muss noch geschrieben werden, damit man sich runs auch Abspeichern kann. Das wird btw echt lustig glaube ich, wenn man da dann mit 100 FPS BMP-Files raus schreibt

Im Prinzip dient es eher zum Debuggen. Man kann das halt auch für ne nBody-Simulation recht einfach nutzen. Dann sieht man auch, ob das Zeug das macht, das es soll oder nicht.

Mit OpenGL kann man halt sich auch leicht dann bei nBody eine 3D Umgebung bauen mit primitives, die man in den Raum zeichnet. Dann kann man leicht alles drehen und zoomen.

 

[Skysnake]

Sodele, es gab ein Update, siehe EDIT im ersten Post

 

[Skysnake]

Sodele, man kann die Anzeige auf dem Bildschirm jetzt auch als BMP raus schreiben.

Allerdings ist das alles andere als performant! Man schafft so grad mal ~6 FPS, wenn man alle 10 Bilder raus schreibt

Naja, was solls, es funktioniert auf jeden Fall.

Ihr könnt die Funktion durch drücken von 'r' ein/aus schalten.

Wäre nett, wenn noch jemand mit einer nVidia Karte das Programm testen könnte

 

[Skysnake]

Ok Leute, ich hab mal noch ein paar kleine Optimierungen vor genommen, die wirklich einen "Durchschlagenden" Erfolg gezeigt haben

Ein paar Optimierungen bzgl. Größe des Bilds und steigern der Durchläufe von 10 OpenCL Iterationen pro Refresh auf 200 OpenCL Iterationen pro Refresh des Monitorbilds, haben eine Steigerung der Auslastung auf ~90% erzeugt.

Noch viel "geiler" ist allerdings, dass der "BMP-Viewer" jetzt bei mir nur noch 10 Watt weniger aus der Dose zieht, als der "Felldonut" vom MSI Kombustor bei 1920x1080 und extrem burnIn ohne AA!

Ich hab einige Tests gemacht, und musste feststellen, dass die Leistungsaufnahme sowohl vom Felldonut als auch von meinem "BMPViewer" recht stark schwanken. Eventuell hat sich der Kühler nun frei "geblasen", womit die GPU Kühler bleibt und somit weniger Leistung zieht

Naja, wies auch drum sei. Im Direktvergleich im Wechsel der beiden Anwendungen, produziert der "Felldonut" nur 1°C mehr GPU-Temp als meine Anwendung. Also 79 vs 80°C, wobei der Lüfter auf 100% fixiert war. Der fällt also als Variable weg.

Ich möchte darauf hinweisen, dass der Test vom "BurnIn Viewer" auf eigene Gefahr erfolgt

Es wäre SEHR nett, wenn einige Leute mal testen könnten, ob sich die GPU eventuell bei Ihnen runter taktet.

 

[Skysnake]

Ok, habs jetzt mal noch mit ner 7970 getestet. Da besteht im Moment noch ein Auslastungsproblem. Warum auch immer. Daher ist hier der Abstand auch deutlich größer zum Felldonut. Nämlich ~20-40W.

Man sollte dabei allerdings auch bedenken, das atm. nur eine Auslastung von 80% erreicht wird! Hier besteht also das Potenzial den Felldonut sogar im Negativrekord zu schlagen, was die Leistungsaufnahme anbelangt.

Was besonders verblüffend war, war folgendes: Bei der 7970 ist der Verbrauch bei konstanter Last ca um 2 Watt pro °C gestiegen/gefallen Da die GPU beim BrunIn-Viewer ca 10°C kühler war, als beim Felldonut, sind die 20-40W Unterschied fast nichts. Ich bin wirklich verblüfft, welchen Einfluss die Temperatur auf den Verbrauch hat!

EDIT:
Der 12.3er CCC behebt das Auslastungsproblem mit der 7970. Jetzt sind auch hier Werte von 90% drin. Das sind allerdings immer noch gute 5% weniger, als bei der 5870. Der Verbrauch ist im Maximum jetzt auch auf 410 Watt gestiegen im Vergleich zum Felldonut mit 420-425W. Der Verbrauch ist im BurnIn-Viewer auch noch langsam gestiegen. Temps waren noch gute 5-8°C niedriger als beim Felldonut. Die Chancen stehen also gut, das man am Ende auf etwa den gleichen Wert raus kommt. Eventuell sogar leicht mehr.

Ich hab den Test dann aber wegen 103°C GPU VRM Temperatur abgebrochen. Mehr muss man die Karte ja nicht unbedingt quälen, auch wenn die GPU <80°C rum hatte, und das OHNE! OC oder Spannungserhöhung. Gut, der Lüfter ist konservativ mit der stock-Einstellung gelaufen. Die Verbrauchswerte sind wirklich sehr verblüffend.

Man sollte sich hierbei immer vor Augen führen, dass das von mir geschriebene Programm NICHT auf einen hohen Energieverbrauch hin optimiert wurde, sondern schlichtweg eine recht normale GPGPU-Anwendung darstellt. Im Moment werden noch nicht einmal besondere Tricks angewendet, um die Aulastung der GPU zu verbessern, wie local(CUDA-Sprech:shared)-Memory. Da ist also durchaus noch eine Verbrauchssteigerung zu erwarten. Denkt man hier nun an GF1x0, oder gar die GTX590 oder HD6990, dann wird einem ganz schwindelig. Denn der von nVidia und AMD als "Power-Virus" verschriene Felldonut ist gar kein solcher, sondern zeigt nur, was in GPGPU-Anwendungen durchaus normal sein kann.

 

[Skysnake]

Sodele Leute,

ich hab mich jetzt doch mal dran gemacht, und mit von glDrawPixels hin zur Verwendung von Texturen gemacht. Das war ein ganz schöner Kraftakt, da ein großteil des Programms umgeschrieben werden musste...

Der Performance ist es aber auf jeden Fall zugute gekommen. Die Frameraten liegen jetzt bei rund 300 FPS

Das sollte aber noch weiter gesteigert werden können, da ich im Moment die Texturen bei jedem Refresh neu erstelle, was natürlich ziemlich behämmert ist, solange sich das Bild nicht verändert, gibt aber einen recht guten Eindruck davon, was die maximale FPS-Rate ist, wenn man das Bild immer erneuern muss.

Die nächsten Tage wird das Projekt dann weiter gemacht. Sobald alles läuft, werde ich diese Version online stellen.

PS: Falls ihr noch Ideen habt, welche Veränderungen man mit den Bildern machen könnte, dann meldet euch bitte.

Euer Sky

 

[Crymes]

Ich habe mal ein paar fragen an dich bezüglich OpenCL:

Das kann man doch ganz normal mit Visual Studio schreiben, oder?

Ich habe mir mal von NVidia die NBody Demo und die Ozean Simulation vom Quellcode her angesehen, da ham die per OpenCl hauptsächlich Matrizen und Vektoren auf die Grafikkerne zerlegt.

Gibt es eigentlicgh überhaupt andere Gebiete ausser Arrays, die man mit OpenCL groß beschleunigen könnte, weil mir grad keine einfallen??

PS: Werde das Projekt mal testen, find ich gut

 

[Crymes]

wenn ich das Programm auf meinem AMD Fusion C-60 Netbook laufen lasse, kommt folgende Fehlermeldung:

Hast du vielleicht einige Variablen nicht initialisiert, sodass sie bei meinem langsamen System noch falsch belegt sind?

 

[Skysnake]

Danke Crymes für das Feedback!!!

Bzgl der Fehlermeldung bin ich im Moment aber ziemlich Verwirrt Ich hab keine Ahnug, was das Problem verursachen könnte. Ich werd aber mal schauen, ob ich eine Lösung finde. Könnte allerdings mit der OpenCL-Implementierung/Init zusammen hängen. Hast du den neusten Treiber drauf? Eventuell haperts auch mit der iGPU. Ich hab leider keine da, um solche Sachen zu testen, ob es da Unterschiede gibt...

Kannst du mir eventuell die gesamte Ausgabe mal posten?

So nu zu deiner Frage:

Arrays sind ja apriori nur Behälter um Datenstrukturen zu fassen. Daher hast du eigentlich immer mit arrays zu tun, egal was du machst. (Jaja, ich weiß, es gibt auch Listen und Bäume....)

Man macht halt im Allgemeinen irgendwelche Array-/Matrix-Operationen. Das liegt daran, das eben sich fast alles durch arrays/Matrizen darstellen/lösen lässt. Die Sache ist sozusagen natürlich.

 

[Crymes]

Also mit aktuellem Treiber der gleiche Fehler.
Mit dem Ausgabetext geht nicht, da ich das Programm noch mehr bedienen kann, nur noch per Lösungsmanager schließen.
Vielleicht kannst du die Ausgabe noch in einer Textdatei speichern!

 

[Skysnake]

Muss ich wohl mal machen.

Das ist echt ärgerlich -.- Ich schau mal, das ich so schnell wie möglich dazu komme.