Auch hier im Artikel fehlt etwas...

[mete01]

Nämlich dass dieser binäre Blob nicht in den Kernel geladen wird, sondern die Firmware für die GPU ist. Auch bei anderen GPUs bekommt man die Firmware sourcen nicht ausgehändigt.

Der unterschied bei der Raspberry Pi ist aber, dass die GPU Firmware sehr viel mehr Sachen erledigt als das eine GPU Firmware normalerweise tut.

So stellt die Firmware dem Treiber einen sehr high-level Zugriff auf die Hardware zur Verfügung, sogar ganze OpenGL Aufrufe werden unverändert zur Firmware durchgereicht.

Dennoch ermöglicht es dieser Code Treiber für andere Betriebsysteme zu entwickeln, er kann auf neue Kernel Versionen geupdated werden, falls der Hersteller dies nicht mehr für Nötig erachtet, und vor allem kann er in den mainline Linux tree gemerged werden.

[hippo_crit]

> Dennoch ermöglicht es dieser Code Treiber für andere Betriebsysteme zu
> entwickeln, er kann auf neue Kernel Versionen geupdated werden, falls der
> Hersteller dies nicht mehr für Nötig erachtet, und vor allem kann er in den
> mainline Linux tree gemerged werden.

In allem bist du 100% korrekt. Bis auf: es könnte sein, dass die Kernel-Maintainer sich trotzdem dagegen entscheiden. Die Argumentation, die bereits in einem Phoronix-Artikel aufgebracht wurde: die Firmware könnte aufgrund ihrer Komplexität erhebliche Qualitätsmängel aufweisen. Ähnlich sieht es wohl bei diversen Netzwerkkarten aus, die größere Teile des Netzwerkstacks selber implementieren und zu Problemen geführt haben.

Nicht, dass ich das genauso sehen würde. Aber es gibt da wohl unterschiedliche Ansichten.

[scroogie]

Die Frage ist ja, ob es sich hierbei überhaupt um einen Treiber handelt, und da kann man durchaus unterschiedlicher Meinung sein. Ein Grund dafür ist auch die unterschiedliche Verwendung des Begriffs "Firmware".

Broadcom benutzt ja eigentlich Trick. Der Pi hat mehrere Chips, den Hauptchip und einen DSP für die Grafik. Als Grafiktreiber würde man jetzt Code erwarten, der Befehle auf dem DSP ausführt. Stattdessen bootet die CPU den DSP mit einer speziellen (geschlossenen austauschbaren) Software, die statt low-level Instruktionen high-level Prozeduren über bekannte Applikations-APIs statt hardware-APIs annimmt. Wie ja oben schon gesagt, die Software bekommt z.B. fertige OpenGL Aufrufe. Als Treiber tituliert man jetzt einfach ein Stückchen Code, was Bibliotheksaufrufe an die auf dem anderen Chip laufende Software weitergibt. Kein Wunder das es da Diskussionen gibt, ob der Treiber tatsächlich offen ist. KMS/Mesa/DRI etc. ist ja alles unmöglich damit, da man nur eine "Applikationslevel" API hat.



1 mal bearbeitet, zuletzt am 26.10.12 14:26 durch scroogie.