Lade Inhalt...

Digitale Bildverarbeitung auf Cell-Prozessoren

©2008 Diplomarbeit 60 Seiten

Zusammenfassung

Inhaltsangabe:Einleitung:
Betrachtet man die Entwicklung der Prozessoren in den letzten drei Jahrzehnten, so stellt man fest, dass sich deren Leistung beachtlich gesteigert hat. Die moderne Auslegung des Mooreschen Gesetzes, nach der sich die Anzahl der Transistoren eines Prozessors alle 18 Monate verdoppelt, ist bis heute gültig. Die damit einhergehende Verkleinerung der Transistoren bringt diverse Vorteile mit sich. Verkleinert man einen Transistor, so verringert sich dessen Stromverbrauch, und es kann mit einer geringeren Spannung gearbeitet werden. Des weiteren verringert sich seine Schaltzeit, was eine höhere Betriebsfrequenz des gesamten Schaltnetzes mit sich bringt. Allerdings führt diese Miniaturisierung auch zu einigen Problemen. Durch die hohe Anzahl von Transistoren pro Fläche wird es zunehmend schwieriger, die entstehende Wärme abzuleiten. Außerdem treten bei Schaltnetzen im kleinen Maßstab Leckströme und ungewollte Tunneleffekte auf. Aus diesen Gründen ist ein Ende dieser Steigerung zu erwarten, da die Miniaturisierung der Transistoren über kurz oder lang an diese physikalischen Grenzen stoßen wird. Die Entwicklungspläne der Prozessorenhersteller werden die Einhaltung des Mooreschen Gesetzes noch eine ganze Zeit lang sicherstellen.
Es ist aber natürlich sinnvoll, sich schon wesentlich früher über Alternativen zur Leistungssteigerung Gedanken zu machen. Aus diesem Grund verfolgt man schon seit längerem das Konzept der Parallelisierung. Es soll dazu beitragen, den Bedarf an Rechenleistung auch weiterhin decken zu können. Die Idee ist sowohl nahe liegend als auch simpel. Man teilt das zu lösende Problem in Teilprobleme auf und verteilt diese system-intern oder über ein Netzwerk an mehrere eigenständige Prozessoren, die dann gleichzeitig die Teillösungen berechnen. Die Teillösungen werden dann wieder zu einer Gesamtlösung zusammen gesetzt. Im Idealfall ist die resultierende Rechenleistung gleich der Summe der Rechenleistung der eingesetzten Prozessoren. Dieses Konzept des parallelen Rechnens findet seit langem bei Supercomputern und Rechenzentren Anwendung. Der Massenmarkt der ‘Consumer-PCs’ bot bis vor kurzem allerdings ausschließlich Computer mit Singlecore-Prozessoren.
Seit im Januar 2006 die Hersteller AMD und Intel die ersten Dualcore-Prozessoren auf den Markt brachten, hat sich dies geändert. Damit einhergehend wurden Multicore-Prozessoren in großen Stückzahlen gefertigt, was deren Preis stark sinken ließ. Diese Diplomarbeit steht […]

Leseprobe

Inhaltsverzeichnis


Philipp Brüll
Digitale Bildverarbeitung auf Cell-Prozessoren
ISBN: 978-3-8366-1707-9
Herstellung: Diplomica® Verlag GmbH, Hamburg, 2008
Zugl. Technische Universität Berlin, Berlin, Deutschland, Diplomarbeit, 2008
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden und der Verlag, die Autoren oder
Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für evtl.
verbliebene fehlerhafte Angaben und deren Folgen.
© Diplomica Verlag GmbH
http://www.diplomica.de, Hamburg 2008

Inhaltsverzeichnis
Inhaltsverzeichnis
1
Einf¨
uhrung
1
2
Cell Prozessor
4
2.1
Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.1.1
Power Processing Element . . . . . . . . . . . . . . . . . . . . . . .
6
2.1.2
Synergistic Processing Element . . . . . . . . . . . . . . . . . . . .
7
2.1.3
Element Interconnect Bus, Memory Interface Controller und Bus
Interface Controller
. . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.2
Leistung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3
Digitale Bildverarbeitung
14
3.1
Faltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.1.1
Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.2
Fast Fourier Transformation . . . . . . . . . . . . . . . . . . . . . . . . . .
21
4
Realisierung der Bildverarbeitungsoperationen
25
4.1
Betriebsumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.1.1
Betriebssystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.1.2
Verwendete Bibliotheken und Compiler
. . . . . . . . . . . . . . .
26
4.2
Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.2.1
Funktionsumfang . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.2.2
Verwaltung der SPUs
. . . . . . . . . . . . . . . . . . . . . . . . .
29
4.2.3
Puffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
5
Experimentelle Ergebnisse
33
5.1
Versuchsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
5.2
Messergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
5.3
Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
6
Zusammenfassung
47
7
Ausblick
49
A Interface
51
A.1 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
A.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
B Literaturverzeichnis
59
0

1 Einf¨
uhrung
1 Einf¨
uhrung
Betrachtet man die Entwicklung der Prozessoren in den letzten drei Jahrzehnten, so stellt
man fest, dass sich deren Leistung beachtlich gesteigert hat. Die moderne Auslegung des
Mooreschen Gesetzes[6], nach der sich die Anzahl der Transistoren eines Prozessors alle
18 Monate verdoppelt, ist bis heute g¨
ultig. Die damit einhergehende Verkleinerung der
Transistoren bringt diverse Vorteile mit sich. Verkleinert man einen Transistor, so verrin-
gert sich dessen Stromverbrauch, und es kann mit einer geringeren Spannung gearbeitet
werden. Desweiteren verringert sich seine Schaltzeit, was eine h¨
ohere Betriebsfrequenz
des gesamten Schaltnetzes mit sich bringt. Allerdings f¨
uhrt diese Miniaturisierung auch
zu einigen Problemen. Durch die hohe Anzahl von Transistoren pro Fl¨
ache wird es zuneh-
mend schwieriger, die entstehende W¨
arme abzuleiten. Außerdem treten bei Schaltnetzen
im kleinen Maßstab Leckstr¨
ome und ungewollte Tunneleffekte auf. Aus diesen Gr¨
unden
ist ein Ende dieser Steigerung zu erwarten, da die Miniaturisierung der Transistoren ¨
uber
kurz oder lang an diese physikalischen Grenzen stoßen wird. Die Entwicklungspl¨
ane der
Prozessorenhersteller werden die Einhaltung des Mooreschen Gesetzes noch eine ganze
Zeit lang sicherstellen. Es ist aber nat¨
urlich sinnvoll, sich schon wesentlich fr¨
uher ¨
uber
Alternativen zur Leistungssteigerung Gedanken zu machen.
Aus diesem Grund verfolgt man schon seit l¨
angerem das Konzept der Parallelisie-
rung. Es soll dazu beitragen, den Bedarf an Rechenleistung auch weiterhin decken zu
onnen. Die Idee ist sowohl naheliegend als auch simpel. Man teilt das zu l¨
osende Pro-
blem in Teilprobleme auf und verteilt diese system-intern oder ¨
uber ein Netzwerk an
mehrere eigenst¨
andige Prozessoren, die dann gleichzeitig die Teill¨
osungen berechnen.
Die Teill¨
osungen werden dann wieder zu einer Gesamtl¨
osung zusammen gesetzt. Im
Idealfall ist die resultierende Rechenleistung gleich der Summe der Rechenleistung der
eingesetzten Prozessoren. Dieses Konzept des parallelen Rechnens findet seit langem bei
Supercomputern und Rechenzentren Anwendung. Der Massenmarkt der "Consumer-
PCs" bot bis vor kurzem allerdings ausschließlich Computer mit Singlecore-Prozessoren.
Seit im Januar 2006 die Hersteller AMD und Intel die ersten Dualcore-Prozessoren auf
den Markt brachten, hat sich dies ge¨
andert. Damit einhergehend wurden Multicore-
Prozessoren in großen St¨
uckzahlen gefertigt, was deren Preis stark sinken ließ.
Diese Diplomarbeit steht im Zusammenhang mit dem Projekt 3D Rekonstruktion mit-
tels Trifokalsensor [14]. Bei diesem Projekt werden f¨
ur die 3D Rekonstruktion drei hoch-
aufl¨
osende Kameras als Datenquelle verwendet. Diese erzeugen sehr große Datenmengen,
auf denen dann zum Teil recht komplexe Operationen ausgef¨
uhrt werden. F¨
uhrt man
diese auf herk¨
ommlichen Prozessoren aus, kann das - auf Grund der großen Datenmenge
- sehr viel Zeit in Anspruch nehmen.
Nun gibt es bereits verschiedene Ans¨
atze, die Arbeit zu beschleunigen. Als erstes
Mittel der Wahl bietet es nat¨
urlich an, den Algorithmus, mit dem die Berechnung aus-
1

1 Einf¨
uhrung
gef¨
uhrt wird, zu optimieren. Hat man dabei das Maximum erreicht, bleibt als n¨
achstes,
die Hardware zu verbessern. Eine M¨
oglichkeit ist hier der Einsatz einer GPU (Graphics
Processing Unit). Dabei handelt es sich um einen auf 2D- und 3D-Grafik spezialisierten
Prozessor, der auf jeder modernen Grafikkarte zu finden ist. Eigentlich sind diese GPUs
ur die Darstellung eines 3D-Modells auf einem 2D-Bild (dem Monitor) ausgelegt, al-
lerdings l¨
aßt sich auch eine Untermenge von deren bereitgestellten Funktionen f¨
ur die
3D-Rekonstruktion nutzen. Es gibt bereits einige Projekte im Bereich Computer Vision,
die diesen Ansatz verfolgen[13][11]. Ein Nachteil dabei ist allerdings, dass man zwar ge-
gen¨
uber einer herk¨
ommlichen CPU eine deutliche Beschleunigung erreicht, es sich aber
bei den meisten Ans¨
atzen weiterhin um Singlecore-L¨
osungen handelt, die ¨
uber kurz oder
lang an die oben genannten Grenzen stoßen werden.
So entstand die Idee, die Berechnungen des Projektes zu parallelisieren und auf einem
Multicore-System berechnen zu lassen. Der Cell-Prozessor ist so ein Multicore-Prozessor,
der dazu noch in der PlayStation 3 verbaut und damit kosteng¨
unstig verf¨
ugbar ist. Er
besitzt ein heterogenes Design mit insgesamt neun Kernen. F¨
ur den Einsatz im Bereich
Computer Vision ist er sehr interessant, da er eine sehr hohe Rechenleistung bietet und
acht der neun Kerne sogenannte Vektor-Prozessoren sind. Diese sind speziell f¨
ur Ope-
rationen mit Vektoren und Matrizen ausgelegt. Sie arbeiten nach dem SIMD (Single
Instruction Multiple Data)-Prinzip[10] und k¨
onnen damit pro Rechenoperation mehrere
Werte (z.B. einen ganzen Vektor) miteinander verrechnen. Die Leistung des Prozessors
bei optimaler Ausnutzung wird vom Hersteller mit ¨
uber 200 GFlop/s (Floating-point
operations per second) angegeben. Das ist gerade mal "nur" um den Faktor 2391 lang-
samer als der derzeit (Stand November 2007) schnellste Computer der Welt BlueGe-
ne/L[18]. Wirklich interessant wird dieser Vergleich allerdings erst, wenn man den Preis
pro GFlop betrachtet. Legt man den derzeitigen (Stand M¨
arz 2008) Preis von 400 Eu-
ro zu Grunde, so kommt man auf ca. 2 Euro pro GFlop. Verglichen mit dem derzeit
zweitschnellsten Supercomputer JUGENE vom Forschungszentrum J¨
ulich, der bei ei-
ner peak-Leistung von 222822 GFlop/s[18] mindestens 13 Millionen Euro gekostet[5]
hat (also 58 Euro pro GFlop), ist das relativ g¨
unstig. Nat¨
urlich ist zu bedenken, dass
bei einem Zusammenschluss von entsprechend vielen PlayStation 3 zus¨
atzliche Kosten
anfallen w¨
urden.
Ziel dieser Diplomarbeit ist es, auf Basis der PlayStation 3 ein kosteng¨
unstiges Sys-
tem zu entwickeln, mit dem sich die aufwendigen Berechnungen des Computer Vision
Projektes relativ schnell durchf¨
uhren lassen.
Im ersten Kapitel dieser Arbeit soll nun die Architektur und Leistung des Cell-
Prozessors untersucht werden. Dabei werden M¨
oglichkeiten und Grenzen des Prozessors
deutlich, und es k¨
onnen Hinweise f¨
ur eine optimale Architektur der Software abgeleitet
werden. Im zweiten Kapitel werden dann die zu implementierenden Operationen auf
ihre Parallelisierbarkeit hin untersucht. Anhand von Faltung und Fourier Transforma-
tion wird aufgezeigt, welche Mehraufwendungen f¨
ur eine parallele Berechnung gemacht
werden m¨
ussen. Im Kapitel drei werden dann Aufbau und Funktionsweise der Software
genauer erkl¨
art sowie bei der Entwicklung aufgetretene Probleme erl¨
autert. Anschlie-
ßend werden dann im Experiment Messungen zur Laufzeitgeschwindigkeit der Software
gemacht. Im letzten Kapitel geht es dann um die experimentellen Ergebnisse. Außerdem
2

1 Einf¨
uhrung
werden die daraus gezogenen Schl¨
usse erl¨
autert. Abschließend folgt eine Zusammenfas-
sung und ein Ausblick, in dem eine m¨
ogliche Weiterentwicklung des Systems skizziert
wird.
3

2 Cell Prozessor
2 Cell Prozessor
Entwickelt wurde der Cell-Prozessor von einer Kollaboration aus SCEI (Sony Computer
Entertainment Incorporated), IBM und Toshiba. Das Projekt wurde von SCEI initiiert,
um einen Prozessor f¨
ur die Nachfolge-Konsole zur PlayStation 2 zu entwickeln. W¨
ahrend
IBM zahlreiche Technologien zum Projekt beisteuerte, stellte Toshiba die Ressourcen zur
Massenfertigung bereit.
Ziel des Projektes, welches im Jahr 2001 vorgestellt wurde, war es, einen Prozessor zu
entwickeln, der diversen Kriterien gen¨
ugen sollte.
· Hohe Performance f¨
ur Spiele und multimediale Anwendungen. Urspr¨
unglich wurde
vorgeschlagen, die Leistung der PlayStation 2 um den Faktor 1000 zu steigern. Man
einigte sich dann allerdings auf den Faktor 100[10].
· Echtzeit-Ansprechbarkeit f¨
ur den Benutzer und das Netzwerk. Sowohl der Benutzer
als auch das Netzwerk sollten zu jeder Zeit eine Reaktion vom System bekommen.
· Kompatibilit¨
at zu einer m¨
oglichst großen Menge von Software.
· Fertigstellung im Jahr 2005.
Der letzte Punkt war dann auch ein Grund, warum man den Prozessor nicht von
Grund auf neu entwickelte, sondern auf die bew¨
ahrte 64-Bit Power Architektur von IBM
zur¨
uckgriff. Das hat außerdem den Vorteil, dass der Prozessor zu dem Befehlssatz des
PowerPCs kompatibel ist und so ein großes Spektrum an bereits bestehender Software
verwendet werden kann. Diese nutzt dann zwar nur einen Bruchteil der Prozessorleistung,
asst sich aber ausf¨
uhren.
2.1 Architektur
Der Cell-Prozessor besitzt eine heterogene Architektur. Das bedeutet, dass die Pro-
zessorkerne auf dem Chip von unterschiedlichem Typ sind. Es gibt eine PPU (Power
Processing Unit), die zusammen mit dem L1- und L2-Cache (first- and second-level ca-
che) das PPE (Power Processing Element) bildet. Desweiteren befinden sich auf dem
Chip acht SPEs (Synergistic Processing Element), in denen jeweils eine SPU (Syner-
gistic Processing Unit) mit lokalem Speicher LS (Local Store) und ein MFC (Memory
Flow Controller) untergebracht ist[10].
Die PPE und die acht SPEs sind ¨
uber den EIB (Element Interface Bus) miteinander
verbunden. Dieser ringf¨
ormige Bus erlaubt sehr hohe Transferraten und verbindet die
PPE und die SPEs zus¨
atzlich mit dem BIC (Bus Interface Controller) und dem MIC
4

2 Cell Prozessor
(Memory Interface Controller). Der BIC stellt ¨
uber die FlexIO-Schnittstelle die Verbin-
dung zu anderen Komponenten des Systems, wie z.B. dem Grafikchip her. Der MIC
dient zur Ansteuerung des Systemspeichers.
Dieses Design ist zum einen der Kompatibilit¨
at mit bestehender PowerPC -Software
und zum anderen der relativ kurzen Entwicklungszeit geschuldet. Durch den Einsatz
der PPU musste kein komplett neues Design entworfen werden, und die aufwendige
Umstrukturierung bestehender Software wurde so vermieden.
SPE 0
SPU (mit
128 128 Bit
Registern)
LS
(256 KByte)
51,2 GB/s
Element Interconnect Bus (204,8 GByte/s)
25,6 GB/s
25,6 GB/s
SPE 7
SPU (mit
128 128 Bit
Registern)
LS
(256 KByte)
51,2 GB/s
...
25,6 GB/s
25,6 GB/s
PPE
L1 (32 KByte)
PX / VMX
51,2 GB/s
L2 (512 KByte)
51,2 GB/s
51,2 GB/s
MIC
Memory
I/O
Controller
25,6 GB/s 25,6 GB/s
25,6 GB/s 25,6 GB/s
25,6 GB/s
25,6 GB/s
25,6 GB/s
Abbildung 2.1: Architektur des Cell-Prozessors[16]
5

2 Cell Prozessor
2.1.1 Power Processing Element
Das Power Processing Element besteht aus einer eigenst¨
andigen PPU (Power Proces-
sing Unit) sowie einem L1-Cache und einem L2-Cache. Die PPU unterst¨
utzt den Po-
werPC -Befehlssatz und zwar sowohl die 32- sowie 64-Bit Befehle. Dadurch l¨
asst sich die
bestehende PowerPC -Software relativ unkompliziert auf das neue System portieren. Es
besteht außerdem ein dual-thread Support, was mit dem Hyperthreading von Intel ver-
gleichbar ist und SMT (simultanes Multithreading) erm¨
oglicht. Das verschafft auch kon-
ventionellen (nicht f¨
ur den Cell-Prozessor konstruierten) PowerPC -Programmen einen
Geschwindigkeitsvorteil, wenn diese mehrere Threads verwenden.
Verarbeitet werden die Daten in zwei 23-stufigen Pipelines. So k¨
onnen zwei Befehle
gleichzeitig von einer PPU ausgef¨
uhrt werden, vorausgesetzt, diese h¨
angen nicht vonein-
ander ab. Die Befehle in den Pipelines werden In-Order ausgef¨
uhrt, was bedeutet, dass
kein Umsortieren der Befehle zur Laufzeit stattfindet. Eine Out-Of-Order-Ausf¨
uhrung
urde bedeuten, dass Befehle auch außerhalb der vom Programm festgelegten Reihen-
folge ausgef¨
uhrt werden k¨
onnen, wenn sich dadurch das Ergebnis der Berechnung nicht
¨
andert. Diese Technik wird bei fast allen modernen x86-Prozessoren (ab Intel's Pentium
Pro bzw. AMD's K6 ) verwendet, um die Pipeline zu entlasten. Die bei dem PPE ver-
wendete In-Order-Ausf¨
uhrung f¨
uhrt allerdings alle Befehle strikt nach der Vorgabe des
Programms aus. Das vereinfacht das Design und erm¨
oglicht die relativ kurze 23-stufige
Pipeline. Zum Vergleich: der Pentium 4-Kern Prescott von Intel besitzt 31 Stufen. Das
hat zur Folge, dass eine falsche Sprungvorhersage weniger "Leerlauf" nach sich zieht und
schneller mit der Programmausf¨
uhrung fortgesetzt werden kann. Wichtig ist dies, weil
die PPE eine statische Sprungvorhersage benutzt, die ausschließlich auf vom Compiler
vorher berechneten Branch-Hints basiert. Bei Branch-Hints handelt es sich um vom Com-
piler in den Bin¨
arcode eingef¨
ugte Hinweise auf im Programmfluss folgende Spr¨
unge. Im
Allgemeinen erzielt diese Art der Vorhersage eine Genauigkeit von 50%-80%. Eine dyna-
mische Sprungvorhersage w¨
urde zwar bis zu 98% erzielen, allerdings wird der durch nicht
vorhergesagte Spr¨
unge bzw. nicht erfolgte vorhergesagte Spr¨
unge entstehende Nachteil
durch die kurze Pipeline zum Teil kompensiert[2].
6

2 Cell Prozessor
Abbildung 2.2: Pipeline der PPU[16]
2.1.2 Synergistic Processing Element
Das Synergistic Processing Element ist die eigentliche Neuerung im Cell-Prozessor. W¨
ahrend
das PPE noch viele Parallelen zur PowerPC -Architektur aufweist, wurde das SPE kom-
plett neu entwickelt. Von diesen Elementen gibt es gleicht acht auf dem Cell-Chip, die
¨
uber den EIB miteinander verbunden sind. In diesem Kontext erschließt sich auch schnell,
warum das Wort "Synergistic" in der Bezeichnung gew¨
ahlt wurde. Es bedeutet so viel
wie "zusammenarbeitend".
Jedes der SPEs besteht aus einem MFC und einer SPU, in der eine SXU (Synergistic
Execution Unit) und eine lokale Speicherbank untergebracht sind. Der MFC ist mit dem
EIB verbunden und stellt die einzige M¨
oglichkeit der SPEs dar, mit den anderen Elemen-
ten auf dem Chip zu kommunizieren. S¨
amtliche Ein- und Ausgaben gehen ¨
uber diesen
Controller. Die lokale Speicherbank - der LS (Local Store) - ist 256 KB groß[8], besitzt
einen Schutz gegen Fehler (es wird hierf¨
ur ein ECC (Error Correction Code) verwendet)
und dient gleichzeitig als Speicher f¨
ur Programmcode und Daten. Pro Takt k¨
onnen 16
Bytes zwischen dem LS und der SXU transferiert werden. Das und die relativ geringe
Gr¨
oße des LS machen die Verwendung eines Caches oder gar einer Cache-Hierarchie wie
bei der PPE ¨
uberfl¨
ussig.
Die SXU ist die eigentliche Recheneinheit der SPEs. Sie hat Zugriff auf ein Register-
File mit 128 Registern, die jeweils 128-Bit breit sind. Programm-Instruktionen werden
¨
uber zwei Pipelines (eine Odd- und eine Even-Pipeline) an eine der sechs Execution Units
geleitet. Durch die Verwendung von zwei Pipelines k¨
onnen zwei Instruktionen gleichzei-
tig ausgef¨
uhrt werden (siehe Abbildung 2.3). In welcher Pipeline eine Instruktion landet,
7

2 Cell Prozessor
angt davon ab, welche Execution Unit f¨
ur das Bearbeiten der Instruktion zustndig ist
(siehe Tabelle 2.1). Daraus folgt dann allerdings auch, dass das gleichzeitige Verarbeiten
von zwei Instruktionen das Optimum darstellt. Soll z.B. im Programmverlauf eine Liste
von Werten addiert werden, so kann der Compiler dies nicht durch paralleles Addie-
ren von zwei Teil-Listen optimieren, da jede add -Instruktion der gleichen Pipeline (der
Even-Pipeline) zugewiesen wird. Zur Beschleunigung des Programmablaufs f¨
uhrt diese
Architektur also nur, wenn zwei unterschiedliche, nicht voneinander abh¨
angige Instruk-
tionen ausgef¨
uhrt werden sollen.
Abbildung 2.3: Funktionaler Aufbau der SPU[8]
8

2 Cell Prozessor
Pipeline
Execution Unit
Funktion
Odd
SFS (SPU Odd Fixed-Point Unit)
uhrt Operationen wie shift, rotate
und shuffle auf quadwords aus.
Odd
SLS (SPU Load and Store Unit)
Zust¨
andig
ur
load -
und
store-
Instruktionen; verarbeitet Branch
Hints und DMA-Anfragen.
Odd
SCN (SPU Control Unit)
Liefert Instruktionen f¨
ur beide Pi-
pelines; f¨
uhrt Spr¨
unge aus und
¨
ubernimmt die Steuerung des Pro-
grammflusses.
Odd
SSC (SPU Channel and DMA Unit)
Zust¨
andig f¨
ur Kommunikation, Da-
tentransfer und s¨
amtliche Ein- und
Ausgaben der SPU; Steuerung des
MFC.
Even
SFX (SPU Even Fixed-Point Unit)
uhrt arithmetische und logische
Operationen aus.
Even
SFP (SPU Floating-Point Unit)
Verarbeitung
von
Gleitkomma-
Operation
mit
einfacher
und
doppelter Genauigkeit; Ganzzahlige
Multiplikation und Konvertierung;
Byte-Operationen.
Tabelle 2.1: Execution Units der beiden SPU-Pipelines[8]
Klasse
Beschreibung
Latenz (Takte)
Pipeline
LS
Load and store
6
Odd
HB
Branch hints
15
Odd
BR
Branch resolution
4
Odd
CH
Channel
interface,
special-
purpose registers
6
Odd
SP
Single-precision floating-point
6
Even
DP
Double-precision
floating-
point
13
Even
FI
Floating-point integer
7
Even
SH
Shuffle
4
Odd
FX
Simple fixed-point
2
Even
WS
Word rotate and shift
4
Even
BO
Byte operations
4
Even
NOP
No operation (execute)
-
Even
LNOP
No operation (load)
-
Odd
Tabelle 2.2: SPU Instruktionslatenz und Pipeline-Zuordnung[9]
9

2 Cell Prozessor
Die Pipeline der SPE ist - genau wie die des PPE - 23 Stufen lang. Diese teilen sich
in 12 Stufen im sog. Frontend und weitere 4 bis 11 Stufen im Backend. Im Frontend
werden Instruktionen geholt, dekodiert und zwischengespeichert. W¨
ahrend des Durch-
laufs des Backends werden die Instruktionen ausgef¨
uhrt und die entstandenen Ergebnisse
zur¨
uckgeschrieben. Wohin diese Ergebnisse geschrieben werden, entscheidet dann auch
¨
uber die genaue Anzahl der zu durchlaufenden Stufen im Backend. Wie das PPE be-
nutzt das SPE eine statische Sprungvorhersage, verl¨
asst sich also ausschließlich auf vom
Compiler eingef¨
ugte Branch Hints. Eine falsche Sprungvorhersage zieht - dank eines
verk¨
urzten Backend-Weges - 18 "Leerlauf"-Takte nach sich.
Die SPEs arbeiten mit SIMD (Single Instruction Multiple Data). Das bedeutet, dass
eine einzelne Instruktion gleich mehrere Daten - wie z.B. die Elemente eines Vektors -
gleichzeitig verarbeiten kann. Um dies zu gew¨
ahrleisten, steht ein sehr großes Register-
File von 128 128-Bit breiten Registern bereit. Jedes dieser Register kann wiederum in
mehrere kleinere Datentypen aufgeteilt werden. M¨
ogliche Aufteilungen sind in Tabel-
le 2.3 aufgelistet. Andere Datentypen, wie z.B. 64-Bit Integer m¨
ussen vom Compiler
simuliert werden.
Die SPE unterst¨
utzt Gleitkomma-Operationen mit einfacher und doppelter Genauig-
keit. Allerdings sind nur rudiment¨
are Operationen mit doppelter Genauigkeit im SIMD-
Instruktionssatz vorhanden. Komplexere Operationen m¨
ussen dann aus den rudiment¨
aren
zusammengesetzt werden. Die Performance der doppelt-genauen Gleitkomma-Operationen
ist im Vergleich zu den einfach-genauen sehr gering. Darum zieht ein Aufruf einer sol-
chen komplexen Operation eine Reihe von rudiment¨
aren Operationen nach sich, die
dann sequentiell von der SFP abgearbeitet werden m¨
ussen. Hinzu kommt die sehr viel
ohere Latenz von doppelt genauen Operationen (siehe Tabelle 2.2), was die Performance
zus¨
atzlich dr¨
uckt.
Anzahl
Datentyp
16
8-Bit Integer
8
16-Bit Integer
4
32-Bit Integer
4
32-Bit Gleitkomma
2
64-Bit Gleitkomma
Tabelle 2.3: M¨
ogliche Aufteilungen eines 128-Bit SPU Registers
10

2 Cell Prozessor
2.1.3 Element Interconnect Bus, Memory Interface Controller und Bus
Interface Controller
Eine kritische Komponente im Design von Multicore-Prozessoren ist die Datenverbin-
dung der einzelnen Chip-Elemente. Eine schnelle und st¨
orungsfreie Kommunikation ist
entscheidend daf¨
ur, ob von der Zusammenarbeit mehrerer Prozessoren profitiert werden
kann. Zur Auswahl stehen mehrere Konzepte, die je nach Anzahl und Art der Elemen-
te verschiedene Vor- und Nachteile bieten. So benutzt z.B. AMD einen Crossbar-Switch
bei seinem Opteron-Prozessor. Dieser erm¨
oglicht eine direkte Verbindung zwischen jedem
beliebigen Element-Paar. Eine solche Verbindung beeintr¨
achtigt die Kommunikation der
¨
ubrigen Elemente nicht. Auf dem Cell-Chip sind allerdings 12 Elemente (8 SPEs + 1
PPE + 1 MIC + 2 BIC) vorhanden, die miteinander kommunizieren m¨
ussen. Das ergibt
12
2
= 66 m¨
ogliche Kombinationen und w¨
urde bei der Realisierung mittels Crossbar-
Switch einen erheblichen Aufwand mit sich bringen.
Statt dieser aufwendigen Vernetzung sind die Elemente des Cell-Chips um einen Ring-
Bus, dem Element Interconnect Bus (EIB), angeordnet (siehe Abbildung 2.4). Die-
ser bietet vier Datenbahnen, je zwei in jede Richtung, und transportiert bis zu 96 Bytes
pro Takt. Sowohl jede der Datenbahnen als auch jeder der beiden Ports, mit denen jedes
der Elemente bidirektional an den Bus angeschlossen ist, sind 128 Bit breit. So kann
jedes Element 16 Bytes (128 Bit = 16 Bytes) pro Port, Richtung und Takt ¨
ubertragen.
Abbildung 2.4: Element Interface Bus[16]
Der von der Firma Rambus designte Memory Interface Controller (MIC) dient
zur Ansteuerung des Systemspeichers. Er ist ebenfalls direkt an den EIB angeschlossen.
Mit dem eigentlichen Speicher ist er ¨
uber zwei 32-Bit breite Kan¨
ale verbunden. Die
Taktung dieser Kan¨
ale ist unabh¨
angig von der des Systems. Bei einer typischen Taktung
von 1,6 GHz (bei der PlayStation 3 der halbe Prozessor-Takt) schafft jeder dieser Kan¨
ale
12,8 GByte/s; da zwei zur Verf¨
ugung stehen, ergibt sich eine Speicherbandbreite von 25,6
GByte/s.
Der ebenfalls von Rambus entworfene Bus Interface Controller (BIC) ist f¨
ur
die Verbindung des Cell-Prozessors mit anderen Systemkomponenten zust¨
andig. Die-
ses auch FlexIO genannte Interface ¨
ubertr¨
agt jedes Bit auf zwei differentiellen Leitun-
gen. Das bedeutet, dass jedes Bit ¨
uber eine normale Signalleitung und eine negierte
geschickt wird. Wirken nun ¨
außere St¨
oreinfl¨
usse auf das Leitungspaar, so ver¨
andern sie
den Signalpegel meist auf beiden Leitungen in gleicher Weise. Die Differenz der bei-
den Signalpegel bleibt allerdings mit relativ hoher Wahrscheinlichkeit unbeeinflusst und
kann dann vom Empf¨
anger ausgewertet werden. Dadurch ist der Datentransfer sehr ro-
11

Details

Seiten
Erscheinungsform
Originalausgabe
Jahr
2008
ISBN (eBook)
9783836617079
DOI
10.3239/9783836617079
Dateigröße
1.8 MB
Sprache
Deutsch
Institution / Hochschule
Technische Universität Berlin – Fakultät IV - Elektrotechnik und Informatik
Erscheinungsdatum
2008 (August)
Note
1,0
Schlagworte
bildverarbeitung parallel computing cell faltung
Zurück

Titel: Digitale Bildverarbeitung auf Cell-Prozessoren
book preview page numper 1
book preview page numper 2
book preview page numper 3
book preview page numper 4
book preview page numper 5
book preview page numper 6
book preview page numper 7
book preview page numper 8
book preview page numper 9
book preview page numper 10
book preview page numper 11
book preview page numper 12
book preview page numper 13
60 Seiten
Cookie-Einstellungen