# OpenGL BMP Viewer inkl. OpenCL "Morpher"



## Skysnake (24. März 2012)

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 




			Dieser Inhalt steht nur eingeloggten Mitgliedern zur Verfügung.
        


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 (26. März 2012)

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 (26. März 2012)

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 (26. März 2012)

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 (26. März 2012)

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 (26. März 2012)

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 (26. März 2012)

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 (26. März 2012)

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 (26. März 2012)

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 (26. März 2012)

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 (26. März 2012)

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


----------



## Skysnake (28. März 2012)

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 (29. März 2012)

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 (29. März 2012)

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 (21. April 2012)

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 (21. April 2012)

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 (21. April 2012)

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


			Dieser Inhalt steht nur eingeloggten Mitgliedern zur Verfügung.
        



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


----------



## Skysnake (21. April 2012)

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 (24. April 2012)

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 (24. April 2012)

Muss ich wohl mal machen.

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


----------



## Skysnake (27. April 2012)

Sodele es gab jetzt einige Neuerungen, und eine Version 1.0 des Viewers  

Wäre cool wenn ihrs mal testen könntet.

@Crymes:
Schau mal ob der Fehler noch immer auftaucht. Hab jetzt so viel umgestellt, keine Ahnung, ob ich das Problem dabei beheben konnte oder nicht.


----------



## Crymes (27. April 2012)

Das wird dich bestimmt nicht freuen, aber segh selbst: 


			Dieser Inhalt steht nur eingeloggten Mitgliedern zur Verfügung.
        



Ich verwende den Catalyst 12.4.


----------



## Skysnake (27. April 2012)

GANhjfa+#fnshj 

Alter ich bekomm gleich noch einen zu viel!

Bei mir läuft das Zeug doch ohne Probleme...... 

Was für ein Windows verwendest du denn?

Und installier vielleicht mal das AMD SDK für OpenCL. Vielleicht liegts ja daran. Ich verstehs echt nicht, warum nen Speicherfehler bei dir auftritt.... Das kann doch echt nicht sein. Bei mir läufts doch ohne Probleme....

EDIT:
Hast du Multimonitor?

EDIT2:
Cool, wenn ich das Archiv von hier runter lade, dann funktionierts soweit bei mir, aber die Ausgabe des Morphers erfolgt nicht


----------



## Crymes (27. April 2012)

Ich hab ein Netbook mit AMD Fusion (C60).  Ich habe kein Multi Monitor und benutze Win7 64Bit.
Ich werde das mit dem SDK mal probieren, werde es hoffentlich  auch selbst ma benutzen 

Kann es sein, dass es daran liegt, dass die APU keinen eigenen Speicher hat und Arbeitsspeicher benutzt?

Du könntest auch mal an AMD schreiben......


----------



## Skysnake (27. April 2012)

Ja, daran kann es liegen 

Eigentlich sollte es kein Problem sein, da die Sachen gleich funktionieren sollten, aber ich weiß es nicht genau. Ich werd mal das Problem ins AMD-Developer-Forum rein stellen, vielleicht weiß ja jemand ne Lösug. 

So, ich hab jetzt nochmal die glut.dll ersetzt. Ich hoffe jetzt funktionierts.... Zumindest kann ich es selbst jetzt überall starten... Vielleicht löst das ja auch dein Problem, auch wenn ich nicht dran glaube.

Aber ich muss jetzt auch mit dir schimpfen 

Warum sagst du nicht fürher, dass du ne APU hast  Ich seh immer nur deine 5770 in der Sig, und denk mir so: "DAS KANN DOCH NICHT WAHR SEIN!" 

Ist jetzt auf jeden Fall ein ganz anderes Ausgangspunkt, um das Problem zu lösen 

EDIT:
Ja es lag wohl an der glut.dll, warum ich bei mir keine Darstellung des Morpher-Effekts hatte 

Das wäre also auch gelöst puh


----------



## Crymes (27. April 2012)

Also ich hatte es ganz oben geschrieben, dass ich es auf einer APU teste. Es wird Sommer, da is so nen Netbook geschickter.

Ich installier grad das SDK, werd gleich berichten


----------



## Skysnake (27. April 2012)

Dann hab ichs gekonnt überlesen


----------



## Crymes (27. April 2012)

Ist ja auch egal, Fakt ist, dass es trotz SDK immer noch nicht geht. Es kommt der gleiche Fehler.


----------



## Skysnake (27. April 2012)

so ein rotz...


----------



## Crymes (28. April 2012)

Du hast es ja auch für dedizierte Karten geschrieben, ich denke einen Leistungsgewinn wird meine billige Grafik eh nicht bringen.


----------



## Skysnake (28. April 2012)

das sollte völlig bumse sein. Das SOLL sogar auch auf APUs laufen können. Ist ja als Testprogramm gedacht, um die Vorteile von GCN zu finden bei Programmen, welche der VLIW-Architektur bzw. GPUs allgemein nicht so liegen, weil zu wenig Rechenaufwand. Bis jetzt waren meine analysen aber ziemlich bescheide... Alles was ich versucht habe hat weniger Performance gebracht  Positiv kann man damit nur sehen, das man wohl scheinbar deutlich mehr Rohleistung erhält ohne großes rum machen als bisher.


----------



## Skysnake (1. Mai 2012)

Sodele Crymes probier mal die Version hier aus.

Ich bin mal komplett weg von NET. Ich hatte das erst bei einigen Änderungen festgestellt, dass das alles auf NET basiert. Hoffentlich funktionierts jetzt 

Ansonsten sind jetzt wieder ein paar Funktionen enthalten. Folgende Sachen gehen wieder:



Zoomen (+/-)
verschieden des Bilds (awsd)
Ansonsten gibt es im Moment nichts neues. Eventuell gibt es heute dann aber noch die 1.3, welche für die Profile-Funktion noch eine grafische Ausgabe hinzufügt. Das braucht aber noch einiges an Code. Von dem Kraftakt, den Code mal wieder auf zu räumen und Sachen wieder zu kapseln, bekommt ihr leider/zum Glück nichts mit. Dafür ist nämlich der gesamte gestrige Tag draufgegangen 




			Dieser Inhalt steht nur eingeloggten Mitgliedern zur Verfügung.
        



BTW hier mal noch ein kleines Vergleichsbild bzgl. der Bildqualität. Unten sieht man den Windows-Fotoviewer und oben den BurnInViewer 


Spoiler






			Dieser Inhalt steht nur eingeloggten Mitgliedern zur Verfügung.
        


Ich denke mehr muss man dazu nicht sagen


----------



## Crymes (1. Mai 2012)

Fill Device Buffer with new Image Data: Da kommt bei mir die Meldung, dass das Programm nicht mehr funktioniert.

Was macht dein Algorythmus eigentlich, damit das Bild besser aussieht?
Legst du da eine Art Anti Aliasing drauf?


----------



## Skysnake (1. Mai 2012)

Ne, ich nutze "einfach" nur die Interpolationsfunktion der Hardware. Die scheint halt verdammt gut zu funktionieren auf den Texturen 

Ich versteh aber echt nicht, warum das jetzt wieder bei dir rumspackt 

Es ist doch echt zum Mäuse melken. Ich hab ja echt gehofft, dass der Umstieg auf reines C++ das Problem behebt, aber denkste...

Ich glaub ich muss mal ne extra Debuggingversion nur für dich und diese Stelle raus hauen. Ansonsten wird das nichts.

Btw. haste ne decidierte GPU noch mit verbaut?

Ich nutz nämlich das GPU define von OpenCL. Vielleicht muss ich da für APUs was anderes nutzen. Ist mir grad so eingefallen. 

Muss ich mal gleich schauen.


----------



## Crymes (1. Mai 2012)

Sag einfach, wenn ich was testen soll


----------



## Skysnake (1. Mai 2012)

Mach ich 

Leider hat sich meine Idee als falsch herausgestellt. Da scheint es nichts zu geben  Ich werd wohl demnächst mal in der Uni bei unserem OpenCL Chiefmaster vorbeischauen, und den fragen, ob er eine Idee hat.

Ansonsten gibt es bald V1.3. Eventuell hau ich die heute noch raus. Ansonsten gibts die Morgen 

Da gibts dann auch ne spezielle Version NUR für dich, damit wir mal bischen das Debugging angehen können.


----------



## Skysnake (5. Mai 2012)

Sodele, die V1.3 ist jetzt da zum Testen.

Crymes, ich hab sogar eine extra Debug-Version für dich gemacht.

Einfach immer 0 oder 1 eintippen. Ich hab nach jedem Funktionsaufruf ein cin<< eingefügt. Damit kann ich dann sehen an welcher Stelle du aussteigst. 

Ich hoffe aber WIRKLICH inständig, das es jetzt funktioniert. Selbst unter Linux läuft das Ding jetzt 

Btw. Ihr müsst den Profile-Modus mal testen, den man mit 'p' aktivieren kann. Gibt paar Neuerungen da 




			Dieser Inhalt steht nur eingeloggten Mitgliedern zur Verfügung.


----------



## Crymes (5. Mai 2012)

Ich kann keine Bilder mehr auswählen, es kommt nach Eingabe: BMP_0.bmp oder BMP_0 sofort ein absturz.
Wenn ich 1 eingebe, kommen genz schnell viele Zeilen und dann beendet sich das Programm.


----------



## Skysnake (6. Mai 2012)

ich hab vergessen eine Textur hinzu zufügen.

Start das Programm unter cmd in der shell. Dann siehst du, das eine Datei Milliteterpapier_Skala.bmp nicht geladen werden kann. Einfach irgend eine bmp Datei entsprechend umbenennen und gut ist. Allgemein bei sowas immer cmd nutzen, dann geht das shell fenster nämlich nicht zu


----------



## Crymes (6. Mai 2012)

Kommt immer der Fhler: Fehler: BMP:BMP_0 konnte nicht geöffnet werden


----------



## Crymes (6. Mai 2012)

Wenn ich in der CMD ne Zahl zwischen 0und 3 (mit eigenen, nummerierten Bildern) eingebe, kann er irgendwas nicht öffnen.
Wenn ich dioe Debug so ausführ, kam jetzt bei folgender Zeilke ne Windows Fehlermeldung: biClrImportant: 1095582055


----------



## Crymes (6. Mai 2012)

Ich seh grad, die Zeile kam schon mal davor, die Reihenfolge ist folgendermaßen:

1.Mal < DEBUF < lese aus Datei < ein paar Zeilen< letzte Zeile zum 2. MAl


----------



## Skysnake (6. Mai 2012)

öffne das programm einfach unter der cmd.

Dann siehst du die ganze Ausgabe und kannst Sie mir mal posten


----------



## Crymes (7. Mai 2012)

In der CMd kommt immer, dass er das Bild nicht öffnen kann.
Wenn ich es in der debug öffne, kommt er bis hier, dann bleibt er einfach stehen, es kommt keinme Meldung, sonst passiert aber auch nichts: 


			Dieser Inhalt steht nur eingeloggten Mitgliedern zur Verfügung.
        


Einml gings weiter, dann kam aber auch sofort ne Fehlermeldung. Ein anderes Mal kam oben beschriebener Fehler.
Scheint irgend ein Treiber Problem zu sein.


----------



## Skysnake (2. März 2013)

Mal ne neue Version


----------



## Skysnake (4. März 2013)

Und mal noch ne neue Version, mit noch nem Versuch die Probleme mit den nVidia Karten zu lösen...

Die Größe der Workgroups wurden auch mal für Kepler auf 192*2 gesetzt. 

AMD Karten sollten aber auch ganz gut damit klar kommen.


----------



## Skysnake (24. März 2013)

Sodele, die Benchsuite ist jetzt Multi-GPU tauglich.

Wenn ich etwas Zeit finde, debugge ich noch den CPU-Part, dann ist die Benchsuite auch CPU fähig. Aktuell wäre ich euch aber SEHR verbunden, wenn ihr das Programm mal mit einer Intel und einer AMD CPU inkl OpenCL fähiger iGPU testen würdet.  Mir fehlt da einfach die Hardware für 

Auch alle nVidia Besitzer sind herzlich dazu eingeladen, das Programm zu testen. Leider wird der Stresstest/Heatblade nicht funktionieren. Da müsste einfach nVidia mal tätig werden 

Besonders interessant wäre der PCI-E Bandwidth Test gleichzeitig! auf mehreren GPUs. Da sieht man nämlich mal, wie gut die Plattform überhaupt die PCI-E Lanes füttern kann. Mein S1366 System schafft es z.B. nicht auf zwei GPUs die volle Bandbreite für 32 Lanes bereit zu stellen, also so 12-18 GB effektve Bandbreite. Um das 100% zu verifizieren, sollte ich aber noch einige kleine Anpassungen vornehmen, so das man die zu testende Größe fixieren kann. 

Wie gesagt, ich wäre euch vor allem für Feedback dankbar. Wurde ja jetzt immerhin 38 mal in relativ kurzer Zeit runter geladen


----------



## Crymes (24. März 2013)

Ich hab das Programm mal auf meinem Netbook (AMd C-60) und meienr HD 5770 ausgeführt, bei beiden wird Die Graka angezeigt.
Das Menü ist bis auf das Umschalten auf das Diagramm, die Zoom Rubrik und quiet funktionslos. Ich kann mit q beenden, mit w,a,s,d das Bild ins Nirvana schieben (mach noch ne einfache Abfrage mit den Fenstermaßen rein) und mit p so nen komischen Profiling Modus aktivieren. Wenn ich v drücke kommt in der Konsole dass irgendwas neu geladen wird.
Auf beiden Rechnern funktioniert der Heatplate Benchmark, auf der HD 5770 wird noch regelmäßig 74 GBits angezeigt und das Diagramm zeichnet sich, auf dem Netbook funktioniert das nicht.

Ist das Menü eigentlich mit Freeglut gemacht?


----------



## Skysnake (24. März 2013)

Ja, ist mit Glut gemacht 

Also mit "c" kannst du ja jeweils die Benches starten. Keine Ahnung, warum nichts gemacht wird, wenn du die anderen Tests ausführst. Denk dran, im "p"rofilmodus musst du schon mit c auch die Tests starten 

PS screens der Ausgabe sind immer gut


----------



## fadade (27. März 2013)

Also die "Menüführung" ist ja noch etwas grausig  

Aber hier mal Ergs für "c" pressed:

GTX260(55nm) @ 680MHz GPU, entsprechend Shader und VRAM @ 1000MHz: Zeit für "Heatblade" etwa immer ~ 745ms und folglich 15.7GFlop/s.
*Wie *kann man sonst auch *was *anderes testen? ^^

--> Profiling @ Millimeterpapier funzt hier, aber ich war beim Umschalten ganz weit reingezoomt und dachte zuerst, das läuft nicht. *änderung_wünsch*


----------



## Skysnake (27. März 2013)

ganz weit reingezoomt?

Es wird halt immer skaliert, damit man den maximalen Ausschlag hat. Also immer die gesamte Größe benutzt. Eventuell hast du vorher mit +/- rumgezoomt, oder mit awsd das Ding verschoben. Schaus dir nochmal an. Ansonsten bitte Bilder zu dem, was du meinst.


----------



## Skysnake (6. März 2014)

Sodele, es gibt nach einem Jahr doch tatsächlich mal wieder ne neue Version mit paar Bugfixes 

Leider habe ich noch immer keine nVidia, womit ich eben immer noch nicht nach Bugs mit nVidia Karten/Treibern suchen kann. Daher bin ich auf euren Input angewiesen, und so lange der nicht kommt, werde ich auch nichts mehr daran machen. 

Ansonsten viel Spaß mit der neuen Version, und denkt bitte daran, der Heatblade Test ist genau so fordernd wie FurMark!!!, wenn man es darauf anlegt. Ich habe es mir extra gerade nochmal angeschaut, da AIDA64 ne neue Version gebracht hat, die auch nochmals mehr Informationen auslesen kann, und zwar den Verbrauch für GPU und Speicher getrennt 

Demnach zieht mein Bench vom RAM 5-10W mehr, und dafür von der GPU ca 10-15W weniger. Macht 0-10W weniger Verbrauch als mit FurMark. Also bitte, denkt dran, dass das wirklich ein heftiger Lasttest ist, und ihr ihn auf eigene! Gefahr hin durchführt. Habt bitte immer die Temperaturen usw im Blick.


----------



## Festplatte (7. März 2014)

Das Programm kann nicht gestartet werden, da MSVCR100D.dll auf dem Computer fehlt.


----------



## Placebo (7. März 2014)

Bei mir läufts, gerade auf einer APU getestet (A6-5200)


----------

