www.mikrocontroller.net

Forum: Digitale Signalverarbeitung / DSP Blackfin Pipeline


Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Morgen,

ich hab eine Algorithmus, der ein 640*480px großes Bild debayern [1] 
soll.

Die erste Version war in C und erreichte um die 30ms. Nach tagelangem 
hinbauen - bin noch Blackfin Anfänger - hab ich eine Assemblerroutine 
gebaut, die 18ms benötigt. Die Assemblerroutine verwendet Vektor-Befehle 
und berechnet nichts zweimal.

Trotzdem erscheint mir das auf einem 500MHz DSP noch reichlich lahm.

Meine Vermutung ist, dass ich keine Ahnung von der internen 10stufigen 
Pipeline-Struktur hab und ich mich daher selbst massiv ausbremse. 
Source-Code hab ich leider nicht da, der sieht aber in etwa so aus:
r0 = [p0];
(r1,r0) = byteunpack r1:r0;
r0 = [p0+640];
(r3,r2) = byteunpack r1:r0;

// mittelwert aus r0 und r2, bzw r1 und r3 berechnen
r4 = r0 +|+ r2;
r5 = r1 +|+ r3;
r6 = r4 >> 1;
r7 = r5 >> 1;

// mittelwert aus 4 pixel berechnen
r0 = r4 +|+ r5;
r0 = r0 >> 1;

usw ...

Ich glaub, dass ich da viele Datenabhängigkeiten reinkrieg, weil die 
Ergebnisse der Berechnungen zu früh gebraucht werden.

Hat jemand Literatur als PDF oder als Buchempfehlung, die auf 
Datenkonflikte innerhalb der Blackfin-Pipeline eingeht? Oder 
Vorlesungsunterlagen oder irgendwas?

Oder sieht jemand auf den ersten Blick einen grundsätzlichen Fehler?

Es scheint da sooo wenig zu geben ...

Grüße
Thomas



[1]: http://de.wikipedia.org/wiki/Bayer-Sensor

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beispiel oben ist natürlich nicht ganz richtig ... nur mal eben aus der 
Erinnerung hingeschrieben ... zB "r6 = r4 >> 1;" sollte "r6 = r4 >> 1 
(v);" heißen usw ...

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

Betreffend Pipelining scheint mir nichts 'Boeses' in deinem Code, das 
sollte der Blackfin soweit effizient abarbeiten.
Aber ein paar andere Fragen/Bemerkungen
- Laeuft dein Code auch im L1 Prog SRAM? (0xffa0xxxx)
- Wenn die Daten im SDRAM liegen, werden auch da wieder Wartezyklen 
fällig
- Cache enabled, und CPLBs entsprechend deiner Bildgroesse / dem 
Speicherbereich konfiguriert?
- Falls eh alles unter uClinux laeuft: Da wird dir immer wieder ein 
Interrupt die Pipeline versauen. Das Cache macht wieder was wett, aber 
wenn Du da optimale Performancekontrolle haben wolltest, muesstest Du 
das ganze in einen Kernel-Treiber (ev. sogar Realtime-Treiber) packen.

Habe unter uClinux einen Debayer im Blackfin ('billig', also C) laufen, 
duerfte in etwa auch bei 50ms gelegen haben (bei hoeherer Aufloesung).
Das koennte also hinkommen.

Zur Pipeline: Es gab mal irgendwo einige Folien als PDF, auf der die 
Pipeline-Struktur lose skizziert war. Aber die ganzen Details gibts 
leider nur gegen furchtbar dicke NDAs (soweit ich weiss, und das bei 
Intel).
Google mal nach "Blackfin seminar pdf" oder so. Wenn ich's finde, sag 
ich Bescheid.

Gruss,

- Strubi

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> - Laeuft dein Code auch im L1 Prog SRAM? (0xffa0xxxx)

Ööööh ... Wenn ucLinux den da nicht hingeladen hat, dann nicht. Aber wie 
hat man unter ucLinux da Kontroller darüber?

> - Wenn die Daten im SDRAM liegen, werden auch da wieder Wartezyklen
> fällig

Ja, die Daten liegen aufgrund der Größe dort. Ich hab mal versucht alle 
8 32Bit-Wörter vorab zu laden und in Register zu packen, damit sie 
irgendwann sofort verfügbar sind und damit evtl die Latenz beim 
Datentransfer verschleiert wird - es ist aber nur noch langsamer 
geworden. Scheint recht gut gecached zu sein ...

> - Cache enabled, und CPLBs entsprechend deiner Bildgroesse / dem
> Speicherbereich konfiguriert?

Ah ... keine Ahnung. Was ist ein CPLB? Cache funktioniert aber 
prinzipiell schon, weil ich hab einen Speicherbenchmark ausprobiert, den 
ich irgendwo gefunden habe und erreichte das praktische Maximum, wenn 
Cache aktiviert ist.

Okay, werd mal nach den PDFs gurgeln ...

Danke!

Grüße
Thomas

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Thomas,

Vergiss CPLB in dem Fall :-) uClinux macht das alles (meist) richtig. 
Handelt sich dabei um die Cache-Konfiguration, man kann gewisse 
Speicherbereiche (Pages) unterschiedlich cachen lassen.
Ich denke, viel mehr Performance holst Du nicht mehr raus. Ich hab die 
Rechnung zur Anzahl Zyklen noch nicht gemacht, waere mal interessant zu 
sehen, was uClinux fuer so eine grosse 'Schleife' noch fuer Overhead 
einfuehrt.

Viel Erfolg,

- Strubi

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas: Hab das PDF gefunden, ist etwas in die Jahre gekommen (2004). 
Lass mir doch mal deine Adresse zukommen (z.b. via 
http://www.section5.ch/order.php) dann schicke ich Dir das Ding. Steht 
allerdings sehr wenig zur Pfeifenlinie drin..

Gruss,

- Strubi

Autor: Joern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, bloede Anmerkung und sicherlich schon bedacht, aber gerade bei 
Schleifen mit wenigen Befehlen wird sich der zero-overhead-Hardware-loop 
eignen, das ganze noch zu beschleunigen. Wenngleich nicht weiter 
recherchiert koennte ich mir naemlich vorstellen, dass der Blackfin 
sonst bei einem Sprung immer die komplette Pipeline verwirft, mit 
diesem, weil der Sprung vorhersehbar ist, aber nicht. Sollte ich mit der 
Hoffnung falsch liegen, bitte ich um Korrektur.

Gruss, Joern

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Joern,

Nur noch ne Anmerkung:
LSETUP-Hardware-Schleifen sollten ansich vom Compiler ausgegeben werden, 
wenn keine Abbruch-Bedingungen existieren. Sonst gibt's auch die (BP) 
('branch prediction') Option fuer vorhersehbare Spruenge. Allerdings 
muss man dabei teils die Spruenge an ganz paradoxen Orten plazieren, 
damit die Berechnung wirklich effizient wird, z.B., so spaet wie 
moeglich (die Pipeline hat 10 stages). In C erschiene das als 
ineffizienter Overhead, aber fuer die Pipeline ist es so optimaler.
Da das Know-How des Blackfin ja von Intel kommt, kann man sich das 
Verhalten und die Coding-Techniken bestimmt von den Pentium-Prozessoren 
abgucken..

Gast: Hast Du schon weiteres rausoptimieren koennen? Wuerde mich noch 
interessieren..

Gruss,

- Strubi

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.