ETI1120 schrieb:
AFAIU zählen die Field Engineers nicht zur Entwicklung sondern zum Marketing
Sehe ich auch so.
Nein. So läuft es nicht. Bei Linux sind die Hersteller dafür verantwortlich, dass ihre Hardware anständige Treiber hat. Das ist doch Eurer Thema, dass sich hier Qualcomm nicht ausreichend genug engagiert hat.
Urspruenglich wurden die Treiber von den Linux-Kernel-Entwicklern fuer die Hardware entwickelt, die sie halt hatten, und die dokumentierte Interfaces hatte (das war damals allerdings normal). Dabei gab's zwangsweise eine Verzoegerung zwischen Marktstart und dem Erscheinen des Linux-Treibers (und fuer speziellere Hardware wurden gar keine Treiber entwickelt). Als Linux-Support fuer gewisse Hardware zu einem wichtigen Thema im Marketing wurde, haben halt die Hardware-Hersteller angefangen, selbst Treiber zu entwickeln, damit sie zum Marktstart vorhanden ist. Gleichzeitig gab's eine Entwicklung, dass die Hardware-Interfaces immer komplizierter wurden und die Hardware-Hersteller dazu uebergegangen sind, die Treiber statt der Doku herauszugeben. Und da lag dann fuer entsprechend geneigte Hersteller (eigentlich alle) die Idee nahe, den Code proprietaer als binary herauszugeben, um es anderen noch etwas schwerer zu machen, etwas ueber das Interface herauszufinden. In Windows ist das ohnehin der Normalfall, in Linux ist das unerwuenscht, und wird schwer gemacht.
[edit]Zum Qualcomm-Aspekt: Die geben ja weder Doku fuer die Hardware her, die sie verkaufen, noch Linux-Treiber. Als Ergebnis gibt es weder Linux-Treiber von ihnen noch von sonst jemandem.[/edit]
Was Softwareerstellung angeht ist funktionierender Code die Basis jeder brauchbaren Dokumentation.
Das ist etwas anderes als Du urspruenglich behauptet hast ("keine bessere Dokumentation als gut geschriebener Source code"), aber selbst das stimmt nicht. Code, von dem der Autor meint, dass er funktiniert, kann einfach ein mistiges Interface haben, wie man beim Schreiben der Doku erkennt. Dann aendert man den Code so, dass er ein sauberes Interface hat. Umgekehrt kann man auch zuerst die Doku schreiben, und kommt dann beim Schreiben des Codes drauf, dass man's besser doch anders macht (und aendert dann die Dokumentation). Code und Dokumentation sind symbiotisch miteinander verbunden.
Du erkennst eine schlechte Softwarereferenz daran, dass keine Codeschnipsel enthalten sind.
Eigentlich erkenne ich eine schlechte Dokumentation daran, dass ich nach Codeschnipseln suche, die das ergaenzen, was im Text fehlt. Codeschnipsel koennen zwar als Abkuerzung hilfreich sein, sind aber kein Ersatz fuer eine vollstaendige Doku.
Das musste AMD machen, da AMD keinen Zugriff auf die Befehlssatzerweiterungen von Intel hatte und Intel über die Befehlssatzerweiterungen die Konkurrenz distanzieren wollte.
Wieso meinst Du, dass sie diesen Zugriff nicht hatten? Sie haben im K6 (1997-04-02) jedenfall MMX implementiert (eine Intel-Erweiterung, eingefuehrt mit dem Pentium MMX (1997-01-08)). Sie haben im K6-2 (1998-05-28) zusaetzlich noch ihr eigenes 3DNow implementiert; zu dem Zeitpunkt hatte Intel keine SIMD-Erweiterung fuer FP. Intel brachte dann mit dem Pentium-III (1999-02-28 eingefuehrt) SSE und mit dem Pentium 4 (2000-11-20) SSE2. AMD hat dann im Athlon XP (2001-10-09) SSE implementiert und im Opteron (2003-04-22) SSE2. Es schaut fuer mich nicht danach aus, als haetten sie irgendwelche Hindernisse gehabt, die verhindert haben, dass sie Intel-Befehlssatzerweiterungen implementieren.
AMD hat 3DNow implementiert, weil Intel damals in dem Bereich nichts hatte und weil es dieselbe Einschraenkung einhielt wie MMX (kein zusaetzlicher Zustand, den das Betriebssystem beim context switch abspeichern muss). Intel hat diese Einschraenkung bei SSE nicht mehr eingehalten und hat die Betriebssystemhersteller auf anderem Weg dazu gebracht, den zusaetzlichen Zustand zu speichern.
Und mit SSE war 3DNow dann erst recht uninteressant. Davor war es uninteressant, weil AMD so eine schwache Stellung im Markt hatte.
Aber eben auch hier gilt, einfach eine Befehlssatzerweiterung zu machen und dann keine Field Engineers bereitstellen, die helfen diese Befehlssatzerweiterung in den gängigsten Programmen implementieren, scheitert. Vor allem wenn man der kleinere Wettbewerber ist.
Ich glaube nicht, dass Field Engineers viel geholfen haetten, dafuer war der Marktanteil des K6-2 und von AMD allgemein zu klein, und SSE kam zu schnell (9 Monate nach 3DNow).
3DNow wurde unnötig weil AMD durch das Patenttauschabkommen Zugriff auf SSE etc. bekommen hat.
Wie man an MMX sieht, hatte AMD solche Abkommen und solchen Zugriff auch davor.
Es wird von Seiten AMD besser, aber es ist IMO nicht angemessen. Und hier ist nicht Nvidia der Massstab sondern Intel. Nvidia hat zwar lange auf dem Blob beharrt, hatte aber im Gegensatz zu AMD immer gute Treiber für Linux.
Das kann mein Kollege, der Linux auf einem PowerBook (Nvidia-Grafik) laufen lassen wollte, nicht bestaetigen. Ich hatte dagegen ein iBook mit ATI-Grafik, da lief Linux samt grafischer Oberflaeche. Und ich denke, mein Kollege war nicht der einzige.
