Schwarzes Bild

[jokke]

Hallo,

ich bin spät dran, ich weiß..

Ich habe bis jetzt den senkrechten Filter auch in inline assembler geschrieben. Problem: Ich bekomme ein komplett schwarzes Bild, also alle Pixel haben den Wert 0. Nein, ich habe nicht vergessen die berechneten Pixel in das Ergebnisbild zu schreiben. Bekomme auch keinen Fehler.. Tiks sind es bei dem Apfelbild 1500 - 2000.. Kommt mir ein bisschen wenig vor, aber wie gesagt, es ist erst der senkrechte Filter.

Hätte jemand Vorschläge, woran das liegen könnte. Oder noch besser, könnte evt. einer der Tutoren über meinen Code schauen? (Keine Sorge, ich hab viel kommentiert)

[ut53xuco]

Da ca. 100 Mio oder mehr Ticks benötigt werden, scheinst Du hier kaum was zu berechnen, vlt. springst Du nicht in korrekt in deine Berechnung rein und brichst sofort ab.

Was ich hatte, dass meine Variable, die die Anzahl der Pixel beinhaltet zu klein war und ich nur einen Teil des Bildes gesehen habe und der Rest schwarz war, weil durch das Abbruchkriterium zu früh abgebrochen wurde.

[jokke]

Danke für die schnelle Antwort

Hmm.. Ja da wird wohl ein Fehler sein.. Meine Variable wird aber eher zu groß sein.. Ich hab einfach gesagt, solange die Zählvariable (anfangs Null) kleiner als die Größe des Bildes in Bytes (also breite des bildes mal 4 wegen floats mal höhe des bildes) ist, wird gefiltert. Die zählvariable wird nach jedem durchgang um 16 erhöht (wegen den 16 Byte xmm registern, mit denen berechnet wird).

Beim berechnen der Bildgröße in Byte hab ich mal "imull %%ebx, %%ecx" da stehen. Das Ergebnis wird doch dann in %eax sein, oder ist das anders?

[kbraden]

Beim berechnen der Bildgröße in Byte hab ich mal "imull %%ebx, %%ecx" da stehen. Das Ergebnis wird doch dann in %eax sein, oder ist das anders?

imull %ecx:
%edx:%eax := %eax * %ecx (vorzeichenbehaftet)

imull %ecx, %ebx:
%ebx := %ebx * %ecx (vorzeichenbehaftet)

mull %ecx:
%edx:%eax := %eax * %ecx (vorzeichenlos)

=> Dein Ergebnis steht in ecx.

[jokke]

facepalm..

[jokke]

Leider ist das Problem damit immernoch nicht gelöst.. Jetzt habe ich so 2000 - 5000 ticks. Wo ich auch nicht ganz sicher bin, ob das so funktioniert:

die werte 0.5 und 0.25 habe ich in zwei long arrays der länge 4 geschrieben. Also { 0.5, 0.5, 0.5, 0.5 } und das selbe mit 0.25. Diese lese ich im asm teil in xmm3 und xmm4. Ich habe das so gemacht: Unten bei den eingangsvariablen steht ... "m"(quarter), "m"(half) ...
(quarter und half sind meine arrays). Und mit "movaps (%0), %%xmm3\n" "movaps (%1), %%xmm4\n" hole ich die je vier longs in xmm3 und 4.

Stimmt das soweit?

[Thomas Huxhorn]

die werte 0.5 und 0.25 habe ich in zwei long arrays der länge 4 geschrieben.

long, also integer, kann keine Gleitkommazahlen speichern.

[jokke]

Was ist nur los mit mir??? Langsam isses mir schon peinlich.. Ok, wenigstens hab ichs in meinem code richtig stehen. Also es sind tatsächlich float arrays. Und ich komme der sache schon näher. Das mit %0 und %1 geht nicht, weil das die ersten zwei Variablen sind. Meine "m"(quarter) und "m"(half) stehen aber an fünfter und sechster stelle. Wenn ich aber jetzt movaps (%4), xmm3 und movaps (%5), xmm4 schreibe, bekomme ich schon beim kompilieren fehler:
Error: missing ')'
und
Error: junk `(%ebp))' after expression
Also ich hab NICHTS anderes getan, als die 0 und die 1 mit einer 4 und einer 5 zu tauschen. Da fehlt definitiv keine Klammer, und was er mit dem junk (%ebp) meint, weiß ich nicht..

[danny]

Wenn du Arrays per Memory übergibst musst du so vorgehen (ohne Gewähr ):

Code: Alles auswählen

"movl %0, %%eax;"
"movups (%%eax), %%xmm0;"

[ut53xuco]

Kleiner Tipp:
Leg dir EINEN Vektor an mit allen Werten drin.
float vek [12] = {0.25, 0.25, 0.25, 0.25, 0.5, 0.5, 0.5, 0.5, -0.5, -0.5, -0.5, -0.5};

Dazu noch einen Pointer:
float *vekp = fak;

Dann liest Du den Pointer in eax ein "a"(vekp)

Und dann kannst du, je nach dem was Du für eine Zahl vor der Klammer wählst, auf die Werte im Vektor zugreifen.
"movups 16(%%eax), %xmm3" würde z.B. 0.5 auf alle Stellen in xmm3 schreiben.

[jokke]

Okay, danke. So bekomme ich jetzt leider einen segfault.. Genau an der stelle "movaps (%%eax), %%xmm3. Liegt wohl daran, dass laut gdb irgendwas negatives in
eax 0xbffff7e8 -1073743896
steht..
Vielleicht stelle ich nochmal die relevanten abschnitte zusammen:
Vor dem asm block:

float mulvek[8] = { 0.25, 0.25, 0.25, 0.25, 0.5, 0.5, 0.5, 0.5 };
float* mulvekP = mulvek;

"nach" dem asm block:
: : "S"(src), "D"(dst), "b"(width), "c"(height), "a"(mulvekP)": "edx");

Im asm block:
"movaps (%%eax), %%xmm3\n" // segfault!
"movaps 16(%%eax), %%xmm4\n"

Bitte sagt, wenn ich hier zu viel "verrate", wobei.. is ja eh alles falsch

EDIT:

Ah, war wegen movaps. War nicht aligned. Also mit movups gehts wieder, Bild ist aber nach wie vor schwarz.. Aber jetzt kann ich weiter debuggen. Danke nochmals. Echt cool wie einem hier so nett geholfen wird.

[ut53xuco]

moment

[skY]

Kann es nicht sein, dass die Loop Anweisung (oder jump halt) einfach falsch ist? Also die Anzahl der Ticks ist für einen Schleifendurchlauf auch bei den beiden kleineren Bildern definitiv viel größer als 5000.
jge/jle oder sowas einfach vertauscht? Oder falsches cmp? Wenn du es nicht eh schon benutzt, tausche die Sprunganweisung mal gegen ein "loop 'marke'\n"
Ist natürlich auch wichtig, dass du ecx nicht vorher irgendwie überschrieben hast oder ähnliches.

[ut53xuco]

Wie sieht es mit deinen Randpixeln aus?
Setzt Du die auf 0? Wenn ja, kann es sein, dass du ein Fehler bei der Randüberprüfung hast und dein ganzes Bild mit nullen auffüllst?

[jokke]

Okay.. Ich habs jetzt so hinbekommen, dass der vertikale filter durchläuft (also auch was macht) nur.. mein Bild ist jetzt einfach eine Kopie des Originals, außer dass oben und unten eine pixelreihe schwarz ist.. Ich hab eigentlich mit allem gerechnet, aber nicht mit sowas..? <ironie>Ich verliebe mich langsam in asm..</ironie>

EDIT: Genau an einem jl anstelle von jg hat's gelegen.
Ich hab die bilder mal ge"difft" und es scheinen schon einige (tausende) unterschiede da zu sein.. Trotzdem komisch, oder übersehe ich hier was.. Eigentlich müsste es doch jetzt schon so ein schwarzes bild mit "schlechten" Kanten sein, oder?

Nochmal EDIT: Ich glaub ich weiß woran's liegt. Wird noch dauern..