• Hallo Gast, du kaufst gerne günstig ein und erfährst oft vor deinen Freunden von interessanten Angeboten? Dann kannst du dein Talent als Schnäppchenjäger jetzt zu Geld machen und anderen PCGH-Lesern beim Sparen helfen! Schau einfach mal rein - beim Test der Community Deals!

OpenGL BMP Viewer inkl. OpenCL "Morpher"

Skysnake

Lötkolbengott/-göttin
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 :daumen:

OpenCL_OpenGL_Simulation.png

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 :daumen:

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 :daumen:

EDIT4:
Den "BurnIn Viewer" hinzugefügt :ugly:
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 :D 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 :lol:

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 :daumen:

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 :ugly:
 

Anhänge

  • Heatblade.zip
    1,2 MB · Aufrufe: 35
  • BurnIn_Viewer.zip
    1,2 MB · Aufrufe: 20
  • BurnIn_ViewerV1.1.zip
    1,2 MB · Aufrufe: 37
Zuletzt bearbeitet:
  • Like
Reaktionen: AMD
TE
Skysnake

Skysnake

Lötkolbengott/-göttin
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.
 
Zuletzt bearbeitet:

AMD

Software-Overclocker(in)
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 :D Sollte ja mit glut keine Probleme sein.
 
Zuletzt bearbeitet:
TE
Skysnake

Skysnake

Lötkolbengott/-göttin
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 :daumen:

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

Software-Overclocker(in)
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.
 
TE
Skysnake

Skysnake

Lötkolbengott/-göttin
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

Software-Overclocker(in)
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 :ugly:
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 ^^
 
TE
Skysnake

Skysnake

Lötkolbengott/-göttin
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

Software-Overclocker(in)
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?!).
 
TE
Skysnake

Skysnake

Lötkolbengott/-göttin
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 :lol:

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.
 
TE
Skysnake

Skysnake

Lötkolbengott/-göttin
Sodele, man kann die Anzeige auf dem Bildschirm jetzt auch als BMP raus schreiben. :daumen:

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

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 :daumen:
 
TE
Skysnake

Skysnake

Lötkolbengott/-göttin
Ok Leute, ich hab mal noch ein paar kleine Optimierungen vor genommen, die wirklich einen "Durchschlagenden" Erfolg gezeigt haben :devil:

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! :wow:

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 :ugly:

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 :ugly:

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

Skysnake

Lötkolbengott/-göttin
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 :wow: Da die GPU beim BrunIn-Viewer ca 10°C kühler war, als beim Felldonut, sind die 20-40W Unterschied fast nichts.:ugly: 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.
 
Zuletzt bearbeitet:
TE
Skysnake

Skysnake

Lötkolbengott/-göttin
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 :daumen:

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. :daumen:

Euer Sky
 
C

Crymes

Guest
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 :daumen:
 
C

Crymes

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

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

Skysnake

Lötkolbengott/-göttin
Danke Crymes für das Feedback!!! :daumen:

Bzgl der Fehlermeldung bin ich im Moment aber ziemlich Verwirrt :what: 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... :wall:

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....:schief:)

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.
 
C

Crymes

Guest
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!
 
TE
Skysnake

Skysnake

Lötkolbengott/-göttin
Muss ich wohl mal machen.

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

Skysnake

Lötkolbengott/-göttin
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.
 
C

Crymes

Guest
Das wird dich bestimmt nicht freuen, aber segh selbst: Fehle.PNG

Ich verwende den Catalyst 12.4.
 
TE
Skysnake

Skysnake

Lötkolbengott/-göttin
GANhjfa+#fnshj :motz::motz::motz:

Alter ich bekomm gleich noch einen zu viel!

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

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 :ugly:
 
Zuletzt bearbeitet:
C

Crymes

Guest
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......
 
TE
Skysnake

Skysnake

Lötkolbengott/-göttin
Ja, daran kann es liegen :ugly:

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. :daumen:

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 :P

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

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

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

Das wäre also auch gelöst puh :D
 
C

Crymes

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

Ich installier grad das SDK, werd gleich berichten :daumen:
 
C

Crymes

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

Crymes

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

Skysnake

Lötkolbengott/-göttin
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 :ugly: Positiv kann man damit nur sehen, das man wohl scheinbar deutlich mehr Rohleistung erhält ohne großes rum machen als bisher.
 
TE
Skysnake

Skysnake

Lötkolbengott/-göttin
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 :daumen:

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 :ugly:

Anhang anzeigen BurnIn_ViewerV1.2.zip

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

Ich denke mehr muss man dazu nicht sagen :D
 
Zuletzt bearbeitet:
C

Crymes

Guest
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?
 
TE
Skysnake

Skysnake

Lötkolbengott/-göttin
Ne, ich nutze "einfach" nur die Interpolationsfunktion der Hardware. Die scheint halt verdammt gut zu funktionieren auf den Texturen :ugly:

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

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. :D

Muss ich mal gleich schauen.
 
TE
Skysnake

Skysnake

Lötkolbengott/-göttin
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.
 
TE
Skysnake

Skysnake

Lötkolbengott/-göttin
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. :daumen:

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

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

Anhang anzeigen BurnIn_ViewerV1.3.zip
 
C

Crymes

Guest
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.
 
TE
Skysnake

Skysnake

Lötkolbengott/-göttin
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;)
 
C

Crymes

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