Nachdem wir im letzten Artikel uns das Herz des Smartphones, also den Prozessor angeschaut haben, schauen wir in diesem Teil einzelne Chips, oder Bestandteile von Prozessorchip (der ein sogenanntes System On a Chip, SoC ist) an, die den Hauptprozessor entlasten. Eines der bekanntesten davon ist Grafikcore, also ein SoC-Bestandteil, der für die Grafikberechnung zuständig ist.
Andere wären Digital Signal Processors (DSP), Field Programmable Gate Arrays (FPGA) und Application Specific Integrated Circuits (ASIC).
Warum werden diese Chips integriert, obwohl sie die Kosten der Herstellung in die Höhe treiben und die Programmierung verkomplizieren (dazu später mehr)? Neben den ständig wachsenden Ansprüchen, was ein Smartphone leisten muss, ist der Hauptgrund Strombedarf. Ein Chip, der für eine bestimmte Ausgabe optimiert ist, verbraucht viel weniger Strom als ein general purpose Prozessor.
Ein Strom aus Bits
Ein DSP ist ein Prozessor, der besonders für die Verarbeitung von digitalisierten Signalen geeignet ist. Alle analogen Signale, wie Funkwellen, Sprache, Photo und Video, Musik müssen direkt nach der Umwandlung von analog zu digital oder umgekehrt, aufbereitet werden, also gefiltert, normalisiert, transformiert. DSPs sind darauf spezialisiert auf einen kontinuierlichen Strom von digitalen Informationen einprogrammierte Formeln anzuwenden und so die Signale zu verändern, damit sie dann vom Hauptprozessor weiterverarbeitet werden können.
Ein modernes LTE-Smartphone braucht ein gutes Dutzend DSPs alleine für die Verarbeitung von LTE, UMTS und GSM Protokollen. Aber auch Sprachverarbeitung und besonders Spracherkennung braucht leistungsfähige DSPs, die Umgebungsgeräusche herausfiltern können.
Transistorfelder
FPGAs sind Felder von Transistoren, die frei programmiert werden können. Die Programmierung erfolgt in Hardware Description Languages (HDL), wo Transistorgruppen individuell miteinander verschaltet werden können, so dass aus einem Chip ein Prozessor und mit einem Software-Update ein DSP werden kann. Natürlich ist ein FPGA nicht so energieeffizient, wie ein speziell designter Prozessor und noch sind sie nicht so häufig in Smartphones zu finden.
Doch wenn es darum geht, nachträglich neue Funktionalität hinzufügen, dann sind zumindest in SoC integrierte GateArrays eine sinnvolle Ergänzung. Denkbar wäre ein schneller Kryptoprozessor, der per Softwareupdate neue Verschlüsselungsalgorithmen beherrschen kann, oder ein Videodecoder, der die neuesten Codecs abspielen kann, ohne den Hauptprozessor zu belasten.
ASICs und IP-Cores
ASICs im Gegensatz zu FPGAs sind Chips, die nur für eine bestimmte Funktion ausgelegt sind, die sie aber besonders effizient ausführen können. Als Beispiel wären Bildstabilisatorenchips genannt, die Wackelbilder vermeiden helfen. Im Zuge der immer dichteren Integrierung, wandern mehr und mehr dieser Zusatzchips als sogenannte IP-cores in den Prozessor-SoC. Moderner SoC hat also neben den eigentlichen Prozessor-Cores (üblich sind heute 2-4), noch ein Grafikcore und sehr viel Zusatzfunktionalität.
Es gibt Firmen, deren Geschäftsmodel besteht darin, unterschiedliche IP-Cores an die SoC-Designer zu lizensieren. Die bekanntesten Firmen sind ARM, Synopsys, Cadence, Imagination Technologies, CEVA. Der Grafikchiphersteller NVIDIA hat angekündigt, den neuen Grafik-core Kepler an andere SoC-Hersteller zu lizensieren.
Wie programmiert man das?
Die Frage, die sich spätestens jetzt stellt, wie diese ganze zusätzliche Funktionalität genutzt wird und nutzbar gemacht werden kann. Als Beispiel für die Nutzung von zusätzlichen Chips kann die Spracherkennung vom Moto X, dem ersten Smartphone von Motorola als Google-Tochter betrachtet werden. Das Smartphone hört ständig die Umgebung ab und kann mit einem Sprachbefehl aktiviert werden.
Wenn immer der Hauptprozessor auf die Umgebung lauschen würde, wäre der Akkumulator sehr schnell leer, deswegen erfolgt die Erkennung in drei Stufen: zuerst filtert ein DSP die Umgebungsgeräusche weg, sollte dann eine Stimme erkannt worden sein, schaltet sich ein MSP430 ein, ein Ultra-Low Power Prozessor von Texas Instruments, und analysiert die Stimme.
Sollte die Stimme vom Besitzer kommen und das Signalwort enthalten, springt der Hauptprozessor an und fängt an das kommende Befehl zu verarbeiten. So wird garantiert, dass die Hauptenergieverbraucher nur dann und solange eingeschaltet werden, wie notwendig ist. Natürlich muss diese gesamte Kette von Betriebssystem unterstützt werden, aber bei Moto X sitzt man an der Quelle.
Die Frage nach der Nutzung durch Apps ist komplizierter. Sowohl JAVA als auch C Objective stossen hier auf ihre Grenzen Beide Sprachen sind dafür gedacht, den Hauptprozessor zu programmieren, aber nicht den DSP. Ein anderes Problem ist die Vielfalt der Smartphones, es kann nicht vorausgesetzt werden, dass alle Smartphones DSPs für Videoverarbeitung besitzen, oder die Grafikkarte bestimmte Leistungskenndaten hat.
Die Lösung wäre eine Zwischensprache, die sowohl vom Prozessor, als auch von der Grafikkarte, als auch vom DSP verstanden und ausgeführt wird, natürlich mit unterschiedlicher Geschwindigkeit, abhängig von der Hardware-Ausstattung des Smartphones. Die Sprache gibt es, sie nennt sich OpenCL, sie wurde ursprünglich von Firma Apple entwickelt und wurde dann an die Khronos Group zur Standardisierung eingereicht.
Khronos Group ist denjenigen ein Begriff, die mit OpenGL arbeiten, sie ist auch für die Weiterentwicklung diesen Standards zuständig. Mit OpenCL was eine Erweiterung der Sprache C ist, kann man Code an verschiedene Hosts schicken, die entsprechende Treiber dafür zur Verfügung stellen, ein Host kann eine CPU sein, eine GPU oder ein DSP, der Programmierer braucht nicht zu wissen auf welcher Hardware sein Programm laufen wird. Wenn er das weiss, kann er zusätzliche Optimierungen einbauen.
OpenCL und Mobile
Wie ist der Stand von OpenCL auf den mobilen Geräten? Momentan noch recht düster. Trotz der Erfindung von OpenCL durch Apple, kann iOS mit OpenCL noch nichts anfangen, eventuell ändert sich das mit iOS7.
Die Situation bei Android ist recht verzwickt. Grundsätzlich gibt es für in Android-Smartphones verbaute Chips OpenCL-Treiber, in der Standardkonfiguration von Android, wie sie von Google ausgeliefert wurde sind sie zu finden. Doch ab Android 4.3 weigert sich der Compiler für Android OpenCL-Programme zu erzeugen. Bereits erzeugte Programme scheinen zu funktionieren. Statt OpenCL schlägt Google eine eigene Lösung namens RenderScript vor, eine Sprache, die interessanterweise auf OpenCL basiert, aber nicht so viele Freiheiten wie OpenCL erlaubt. Google begründet das mit Zersplitterung von Android, RenderScript-Programme sollen auf allen Smartphones lauffähig sein, da man gar nicht auf eine bestimmte Architektur optimieren kann, was zwangsläufig zu Performance-Einbußen führt.
Doch Android ist ein freies System, das heisst, die Sourcen können verändert werden, die Sperre kann aufgehoben werden. Das gilt natürlich auch für Ubuntu-on-ARM, also einer Linuxdistribution für Smartphones. Ein OpenCL-Treiber für den Mali-Grafikcore von ARM ist verfügbar.
Insgesamt kann man sagen, dass die Ausnutzung von heterogenem Computing auf dem Smartphone noch in Kinderschuhen steckt, aber bei der Geschwindigkeit der Entwicklungen in der mobilen Welt, kann man erwarten, dass heterogenes Computing bald eine größere Rolle spielen wird. Dafür sprechen sowohl die neuesten Hardware-Entwicklungen, die immer mächtigere Ausführungseinheiten auf einen SoC quetschen, als auch die rasche Verbreitung von Programmierungsmöglichkeiten, um diese Hardware auszureizen. Der App-Programmierer sollte sich jetzt schon Gedanken machen, wie die zusätzliche Rechenkraft ihm nützlich werden kann und der Konsument darf sich bald auf noch intelligentere Geräte freuen.
Kommentar hinterlassen