Wayland 1.0

Eine 1:1 Implementierung von WDDM wird auf einem unixoiden System nicht möglich sein. Dafür sind die Konzepte sowohl nach oben, als auch nach unten im Geräte-Stack zu unterschiedlich. Das beginnt halt damit, dass Windows in allen 4 Ringen der x86-CPU läuft, die Unix-Familie aber nur zwei nutzt. Dann ist dort die sehr enge Verzahnung mit DirectX und seinen Brüdern zu nennen, nach oben integriert WDDM eng mit der Desktopumgebung bis hin zum Windows Manager. So gut WDDM auch sein mag, es ist halt eine Lösung, die speziell für die Windows-Familie entwickelt wurde. Und selbst wenn man es implementieren könnte, zumindest eine Teilmenge davon auf unixoide Systeme portieren, ist dort noch immer das Problem mit dem Urheberrecht, Patenten und so weiter. Microsoft wird zu recht kaum ruhig zuschauen, wenn ihnen jemand an die Kronjuwelen möchte.

Was ich in dem Originalthread sagen wollte war, dass das viel gescholtene Microsoft einfach mal seine Hausaufgaben gemacht und ein Problem auf professionelle Weise gelöst hat. WDDM gibt es in ausgelieferten Produkten seit 2006. Seitdem hat es lediglich 2 Erweiterungen der API gegeben, sowohl WDDM 1.1 als auch 1.2 fügen lediglich Dinge ein, die es damals noch nicht gab oder nicht relevant waren. Wie oft wurde seitdem der freie Grafikstack umgefrickelt? Wie viele zueinander inkompatible und dennoch murksige APIs hat das KMS-Projekt seitdem hervorgebracht? Wer den freien Grafikstack ernsthaft auf ein solides Fundament stellen will, muss so ehrlich sein und sich mindestens WDDM unvoreingenommen anschauen.

Was man allerdings machen könnte, wäre eine API zu designen, die sich an WDDM orientiert und dem nahe genug ist, um Portierungen einfach zu machen. Ich glaube, es wäre schon eine sehr große Hilfe, wenn nicht ein die kompletten unteren Ebenen eines Grafiktreiber für die freien Systeme neugeschrieben werden muss, stattdessen der vorhandene Windows-Code angepasst werden kann. Aber sind wir ehrlich, sowas wird nicht passieren. Im BSD-Lager hat niemand ein ernsthaftes Interesse, ein solches Projekt zu starten. Und im Linuxlager wird aus ideologischen Gründen alles verhindert, was auch nur in 100 Kilometer Entfernung nach stabiler API riecht. Und daher ist es leider nicht unrealistisch, dass wir irgendwann alle WDDM nutzen werden. Mit einem Metro oben drauf.

Es muss ja kein WDDM sein.

Mir reicht es schon das ich ein Desktop System zusammen suchen muss anhand der Grafikkarte damit ich FBSD nutzen kann.
Das versetzt einen so ziemlich in die 1980/90er Jahre zurück. Nur das man heute keine Speicheradressen mehr kennen muss. Aber die Hardware muss immer noch passen, sonst kann ich den FBSD Desktop vergessen.
Gerade im Ultra/Netbook bereich ist die Luft ziemlich dünn für FBSD.
Sollte Nvidia mal den Support für FBSD einstellen, dann frage ich mich was man dann macht ? Den User Linux zu empfehlen halte ich für keine gute Strategie. Ich nutze ja FBSD nicht aus Spass, sondern weil ich damit Arbeite und ein Stabiles und Sicheres System haben will.
OK, man könnte auch andere Unixe nehmen, aber warum sollte man sich immer der Konkurrenz beugen ?

Ich brauche ja nicht umbedingt vollen 3D Support. Mir reicht ein Desktop mit dem ich noch anständig arbeiten kann.
2D Beschleunigung sollte zwecks Video verarbeitung schon drin sein. Stabil sollte das ganze auch sein.
Das sollte doch wenigsten in Zukunft mit allen Mainstream Hersteller Karten möglich sein.

Ich versteh auch nicht, warum die Linuxer immer mehr ihr Inselleben wollen. Ich würde es besser finden wenn die
Entwickler wieder mehr zusammen arbeiten würden und eine EINHEITLICHE Api bauen die für BSD und Linux Kernel funktionieren. Zumindest was den 2D Support angeht.
 
Ich hätte schon gerne OpenCL und 3-D Unterstützung. Wir sind da vollkommen außen vor und das schmeckt mir nicht.
 
Och, Nvidia beweist doch, dass man sehr portablen Treibercode schreiben kann, indem an allem anderen vorbeiprogrammiert und sein eigenes Ding macht...
Ich würde mal behaupten das Nvidia das nicht aus Spaß macht, sondern die Leute dort werden wahrscheinlich mehr Erfahrung mit solchen Dingen haben wie ein Freak der im Keller ein paar Zeilen zusammen schreibt. Außerdem wissen die ganz genau was sie brauchen und haben auch die Kontrolle darüber. Wenn man sich auf eine Kernel Funktion unter Linux verlässt kann es sein das man in der kommenden Kernel von allen verlassen ist und nichts mehr geht. Dann ist doch die eigene Schnittstelle besser.

Grüße
 
Reichlich OT:
Zahlt denn Oracle immer noch dafür, dass Nvidia einen Treiber anbietet?
Solange das der Fall ist, wirds wohl auch ein FreeBSD Treiber geben.
Wie ist eigentlich der Streit um DMA-BUF ausgegangen?
 
nVidia ist ein gutes Beispiel für Portabilität, aber nicht unbedingt ein Ersatz für WDDI. Es ist halt auf der Kernelseite ein mehr oder minder platformagnostischer Kern, der mit einem Wrapper in die umgebende Plattform eingebunden wird. Unter Windows geschieht das sicher mit WDDI, unter Linux und FreeBSD mit den dort verfügbaren Interfaces. Es liegt also eine Ebene über der Schnittstelle.

Auf Linux hat Nvidia natürlich auch eine Art Sonderstellung. Sie gehen ihren eigenen Weg und sind damit sehr erfolgreich, auch wenn die GPL-Krakeler es anders sehen mögen, kann man dagegen nur schlecht an argumentieren. Die Sache ist halt ganz einfach: "Kein Nvidia-Blob bedeutet, dass Linux für jede ernsthafte Grafikanwendung ungeeignet wird. Und dazu gehören teilweise auch aktuelle Spiele." Und anders AMD/ ATI - von deren Hardware ich immer noch sehr viel halte - hat Nvidia es geschafft, einen absoluten Großteil des Codes platformunabhängig zu implementieren und dennoch Qualität und Performance zu halten. D.h. die Arbeit wird einmal für Windows gemacht, kann dann recht problemlos für Linux übernommen werden. Die Unterschiede zwischen Linux, FreeBSD und Solaris dürften gering sein und sich hauptsächlich auf den Opensource-Wrapper um das Kernelmodul beschränken.

Und meine ganze bescheidene Meinung ist, dass man endlich akzeptieren sollte, dass Grafiktreiber zu komplex sind, um sie komplett als Opensource-Projekt zu realisieren. Und das sowohl AMD als auch Nvidia in ihrem Treiber sicher größere Mengen Code von Drittanbietern haben, sowie dort so viel Know-How (der Treiber ist die GPU!) drinsteckt, dass sie den niemals opensourcen werden. Also, hört auf die Blobs auszubremsen. Das hilft niemanden, schadet aber allen. Punkt. Man kann ja gleichzeitig einen freien Treiber schreiben, wie z.B. es AMD macht. Und wer partout keinen Blob will oder nur rudimentäres 3D will, kann den nehmen. Und wenn die Hersteller den Support alter Hardware durch den Blob einstellen, dürfte der freie Treiber weit genug sein, um ihn ersetzen zu können. Und selbst wenn nicht. Jemand, der ernsthaft in 3D macht, wird keine 5 Jahre alte Karte einsetzen.
 
Ich würde mal behaupten das Nvidia das nicht aus Spaß macht, sondern die Leute dort werden wahrscheinlich mehr Erfahrung mit solchen Dingen haben wie ein Freak der im Keller ein paar Zeilen zusammen schreibt.

Das Resultat - die Abstraktionsschicht im Treiber - ist in der Tat eine beeindruckende Leistung.

Wie ist eigentlich der Streit um DMA-BUF ausgegangen?

Der läuft anscheinend noch.

Und meine ganze bescheidene Meinung ist, dass man endlich akzeptieren sollte, dass Grafiktreiber zu komplex sind, um sie komplett als Opensource-Projekt zu realisieren.

Zu unser aller Leidwesen befürchte ich, dass du mit dieser Meinung so bescheiden nicht zu sein brauchst. :(

Die Sache ist halt ganz einfach: "Kein Nvidia-Blob bedeutet, dass Linux für jede ernsthafte Grafikanwendung ungeeignet wird. Und dazu gehören teilweise auch aktuelle Spiele."

Vielen Dank für die Ausführungen, Yamagi. Ergänzen möchte in an dieser Stelle nur den Hinweis, dass "ernsthafte Grafikanwendung" abseits des Desktops auch das High Performance Computing umfasst, mit dem Nvidia viel Geld verdient.
 
Last edited:
Und meine ganze bescheidene Meinung ist, dass man endlich akzeptieren sollte, dass Grafiktreiber zu komplex sind, um sie komplett als Opensource-Projekt zu realisieren. Und das sowohl AMD als auch Nvidia in ihrem Treiber sicher größere Mengen Code von Drittanbietern haben, sowie dort so viel Know-How (der Treiber ist die GPU!) drinsteckt, dass sie den niemals opensourcen werden. Also, hört auf die Blobs auszubremsen. Das hilft niemanden, schadet aber allen. Punkt. Man kann ja gleichzeitig einen freien Treiber schreiben, wie z.B. es AMD macht. Und wer partout keinen Blob will oder nur rudimentäres 3D will, kann den nehmen. Und wenn die Hersteller den Support alter Hardware durch den Blob einstellen, dürfte der freie Treiber weit genug sein, um ihn ersetzen zu können. Und selbst wenn nicht. Jemand, der ernsthaft in 3D macht, wird keine 5 Jahre alte Karte einsetzen.

Also mir ist es letztendlich egal ob ich den Treiber vom Hersteller bekomme oder als Open Source vorliegt.

Die Frage ist nur, wie kann die BSD Community genug Druck ausüben, um von Intel, AMD und co einen "BLOB" zu bekommen ?
Eventuell mit Geld von der BSD Foundation ?

Theoretisch würden sich die Hersteller mit FBSD viel leichter tun als mit Linux.
Denn der FBSD Kernel ändert sich ja nicht so massiv an den API's wie es Linux tut.
Theoretisch würde ein FBSD 6.x Kernel Modul auch noch unter 9.x oder 10.x laufen :-)

Mfg,
 
AMD gehts gerade nicht besonders gut, einige Linux Entwickler (für die freien Parts) wurden bereits abgezogen. Das könnte wieder die Position von X stärken, wenn's bei Wayland an brauchbaren Treibern mangelt.
 
Hmm ja, die Rettung von AMD ist auch so ein Thema. Eine Welt ohne AMD ist ziemlich furchteinflößend. Ich habe aber nicht die geringste Ahnung, was man da tun kann.
 
Nichts. Vielleicht wird ARM64 (wo AMD ja auch die Suppe mitkochen will) eine Alternative zu x86. Aber ehrlich gesagt bezweifele ich das sehr, denn außer heißer Luft, Hype und vollmundigen Ankündigungen kam bisher aus dem ARM-Lager nichts, was einer richtig schön dicken CPU auch nur nahe kam. Und genau die wollen wir ja.
 
Also man rühmt sich im ARM-Lager ja gerade eher damit, dass man einen Atom besiegt, der den doppelten Takt hat.

Wenn ich mir aber mal vor Augen halte wie lahm mein Atom Netbook ist, dann sind die ARM-Teile, selbst wenn sie ihre Leistung spontan verfünffachen, immernoch verdammt langsam, gegenüber solchen Schlachtschiffen wie i7 und Co. Ich mein, nicht umsonst läuft auf den Tablets und Co. meist nur >eine< Anwendung.

ARM ist in der jetzigen Fassung einfach nichts für Desktops. Für solche "Einwegtablets" und Telefone mag das ja alles OK sein, aber wenn man im Desktop-Bereich vorankommen will, dürfte sich z.B. das Instruktion-Set nicht alle Nase lang ändern.
 
Joa. Und einen Atom zu schlagen ist in etwa so, als würde man sich freuen auf der Autobahn einen Trabbi überholt zu haben.
 
Die Lösung wird hier wohl eher in Richtig "Many-Core" zu suchen sein. So wie es Intel auch mit seiner Larrabee (GPU) versucht.
 
AMD gehts gerade nicht besonders gut, einige Linux Entwickler (für die freien Parts) wurden bereits abgezogen. Das könnte wieder die Position von X stärken, wenn's bei Wayland an brauchbaren Treibern mangelt.

Oder umgekehrt wird ein Schuh daraus - wenn sich Wayland mittelfristig am Linux-Desktop durchsetzt, geht es zu Lasten von X.

Das bringt dir auf einem Desktop nur genau garnichts...

Stimmt. Dort ist die Singlethread-Performance nach wie vor maßgeblich.

Für GUI-Anwendungen ist auch keine Abhilfe in Sicht. Die Implementierung eines Multithreaded-GUI-Toolkits ist ein noch vollkommen ungelöstes Problem; nicht umsonst verwenden sämtliche Toolkits unter der Haube eine Event-Queue.
 
Oder umgekehrt wird ein Schuh daraus - wenn sich Wayland mittelfristig am Linux-Desktop durchsetzt, geht es zu Lasten von X.

Wayland ist wohl noch etwas fricklerfreudiger als X. Und wenn Nvidia keinen Anreiz hat für Wayland zu entwickeln, wird AMD in seiner Talfahrt sicher nicht noch mehr Leute dafür abstellen, damit eine Nische unter den Nischen besser unterstützt wird. AMD wird sicher den Nvidia Weg in Betracht ziehen.
Ich hatte jedenfalls immer meine Probleme mit AMD, auch unter Windows war die gelieferte Qualität nicht zufriendenstellend.
Hinsichtlich Performanz wird sich auch mit Wayland nicht viel tuen.
Und wenn ich olle vom Illumos/Nexenta richtig verstanden haben, wollen die auch auf den Desktop. Viel Spaß beim portieren der Linuxismen.
 
Ist das irgendwie sarkastisch?

Ganz und gar nicht.

Event-Queue ist doch super zum Parallelisieren.

Es gibt schlechtere Lösungen, aber die Event-Queue ist grundsätzlich singlethreaded und damit ein Flaschenhals. Alle Updates der GUI müssen daraus erfolgen - sonst gibt es wahlweise Race Conditions oder Deadlocks - und sind damit durch die Singlethread-Performance des Rechners limitiert.
Leider gibt es (noch) keine bessere Lösung für das Problem.
 
Naja zuzutrauen ist es den Jungs schon.

Der von darktrym verlinkte Vortrag wurde von einer Frau gehalten. ;)

Schliesslich haben sie KVM schon portiert.

KVM ist aber wesentlich überschaubarer (15k Zeilen Quellcode) und hat weniger (vor allem externe) Abhängigkeiten als die ganze Grafik-Mischpoke.

Ich gehe mal davon aus, dass sich das Team eher an der exitierenden Solaris-Infrastruktur denn einer Linux-API-Emulation orientieren wird, allein aus Gründen der verfügbaren Entwicklerkapazität. Weiß jemand Details?
 
Also man rühmt sich im ARM-Lager ja gerade eher damit, dass man einen Atom besiegt, der den doppelten Takt hat.
Ich finde das auch lustig, man ist stolz auf sich weil die stärkste ARM cpu den schwächesten x86 Prozessor schlägt... Das ist so was von toll ich bin mir sicher jetzt wird sich die Welt grundlegend ändern :ugly:

AMD gehts gerade nicht besonders gut, einige Linux Entwickler (für die freien Parts) wurden bereits abgezogen.
Ich denke in Zukunft wird auch Intel weniger aktiv bei Linux sein. Intel ist ja ein Unternehmen das Geld verdienen will und wenn man für Linux irgendwelche freien Treiber entwickelt verdient man kein Geld. Man muss den Grund sehen warum Intel überhaupt bei Linux so aktiv ist. Bis vor einiger Zeit war Linux das einzige System welches im mobilen Bereich mit einer x86 cpu was anfangen konnte. Aber es waren alle Geräte bis auf ein paar Spielzeuge mit einer ARM cpu, man hatte dann auch noch Panik bekommen als Microsoft ankündigte zukünftig eine ARM Version anzubieten. Ich denke Intel hat versucht mit Linux ein eigenes System zu haben auf dem die eigene Hardware gut läuft so als art Notfallplan. Jetzt mit Windows 8 ist diese Einsatz in der Linux Welt im Grunde nicht mehr nötig und wird vermute ich mal auf lange Sicht eingeschränkt.

Die Lösung wird hier wohl eher in Richtig "Many-Core" zu suchen sein. So wie es Intel auch mit seiner Larrabee (GPU) versucht.
Ich vermute mal das zumindest im Desktop Bereich das Ende erreicht ist. Es wird bestimmt noch ein paar Mhz dort und einen Kern da mehr geben, aber große Sprünge wird es denke ich nicht mehr geben mit der aktuellen Technik. Es ist ja schön das fast jede Anwendung ihren eigenen Kern hat auf dem sie sich austoben kann, aber es gibt ja kaum Anwendungen die wirklich mehrere Kerne sinnvoll nutzen. Es gibt immer noch Anwendungen die auf einem Prozessor mit einem Kern und 3,6 Ghz schneller laufen als auf einem Prozessor mit 3 Ghz und 8 Kerne... Also da wäre noch Raum zum optimieren. Nur ob es Sinn macht wie bei GPU's hunderte Kerne zu haben weiß ich nicht. GPU's sind ja im Vergleich zu einer CPU eher simpel aufgebaut. Es gibt Hunderte Kerne aber meist sind diese auf eine Simple Aufgabe ausgelegt und können wirklich nur eine Gleichung rechnen und mehr nicht. Eine CPU muss mit jedem Kern alles können und die Jahre über hat sich auch eine Menge Müll angesammelt der aber noch immer unterstützt werden muss. Außerdem finde ich den Gedanken eines 500 Watt Pentiums etwas erschreckend... Da wäre beim Prozessor wohl neben dem Intel Aufkleber noch ein "Freundliche grüße: Ihr Energieversorger" Logo dabei :D

Bin mal gespannt was nach der x86 Generation kommt.

Grüße
 
Ich finde das auch lustig, man ist stolz auf sich weil die stärkste ARM cpu den schwächesten x86 Prozessor schlägt... Das ist so was von toll ich bin mir sicher jetzt wird sich die Welt grundlegend ändern :ugly:

Es geht hier nicht nur um die Leistung sondern auch um den Stromverbrauch.

Ich denke in Zukunft wird auch Intel weniger aktiv bei Linux sein. Intel ist ja ein Unternehmen das Geld verdienen will und wenn man für Linux irgendwelche freien Treiber entwickelt verdient man kein Geld.
Intel verdient Geld damit, dass ihre Server gekauft werden, weil ihre Treiber so gut funktionieren.


Es wird bestimmt noch ein paar Mhz dort und einen Kern da mehr geben, aber große Sprünge wird es denke ich nicht mehr geben mit der aktuellen Technik. Es ist ja schön das fast jede Anwendung ihren eigenen Kern hat auf dem sie sich austoben kann, aber es gibt ja kaum Anwendungen die wirklich mehrere Kerne sinnvoll nutzen.
Ich rede von "Manycore" nicht "Multicore"! Hier sind mehrere 100 Cores gemeint. z.B. von Intel http://en.wikipedia.org/wiki/Larrabee_(microarchitecture)
 
Naja, die Frage ist halt, was man will. Will man wenige schnelle Kerne oder viele, die dann aber weniger Leistung bringen? Beides mag seinen Sinn haben, je nach Workload. Aber das Eine wird nie das Andere ersetzen können... Und Manycore auf dem Desktop sehe ich noch nicht. Ich sehe es noch nicht einmal auf den meisten Servern. Vielleicht wird es sich ändern, aber im Moment ist es eine kleine Nische. Allerdings eine sehr profitable.

Und da sind wir wieder bei Intel vs. ARM. Hat ARM einen inherenten Vorteil gegenüber x86? Kaum. Zwar wird immer wieder über die "x86-Tax" durch die Decoder diskutiert, aber der Anteil der Decoder an der Chipfläche ist gering, ebenso ihr Stromverbrauch. Man gewinnt durch sie zudem weitere Optimierungsmöglichkeiten. Also unter dem Strich wohl ein Nullsummenspiel. ARM braucht einfach so wenig Strom, da es jahrelang dahin optimiert wurde. x86 wiederum wurde mindestens ebenso lange auf Geschwindigkeit optimiert. Ein schneller ARM-Prozessor wäre sehr wahrscheinlich kaum effizienter als ein moderner x86. Man bräuchte dort ebenfalls große Bussystem, riesige Cache-Hierarchieren, komplexe Uncores, etc. Das säuft Strom ohne Ende, die Kerne selbst verbrauchen da schnell nur noch einen Bruchteil des Powerbudgets. Umgekehrt wäre ein hochgradig verbrauchsoptimierter x86 auch nicht mehr schnell, weil halt vieles was Geschwindigkeit bringt, rausfliegen müsste. Und so dürften sich x86 und ARM nicht viel nehmen, wenn die derzeitige Trennung des Marktes aufgehoben werden sollte.

Da spielen dann andere Dinge eine Rolle und Intel hat in der Vergangenheit gezeigt, dass sie diese perfekt beherrschen. Es geht schon damit los, dass sich Intel immer weitgehend aus Bereichen herausgehalten hat, mit denen kein Geld zu verdienen ist. Was Intel im Quartal verdient ist gigantisch und vielleicht mehr, als die ganze ARM-Clique zusammen. Trotz einer viel geringen Stückzahl. x86 war nie die meistverkaufteste CPU-Architektur, aber es ist seit Ewigkeiten die profitabelste. Das bringt wiederum Geld in die Kriegskasse, womit man neue Technologien entwickeln kann, die noch mehr Geld bringen. Während die anderen strampeln, kann sich Intel erst einmal zurücklehnen und zuschauen.
Dazu kommen die unschöneren Dinge. AMD zum Beispiel hat sie sehr schmerzhaft lernen müssen. Sobald jemand Intel an die Cash-Cow will, wird die Firma gnadenlos und drängt den Konkurrenten notfalls auch mit klar illegalen Methoden aus dem Markt. Absprachen wie "Du verkaufst nur Intel und bekommst dafür Rabatt" sind nur die Spitze Eisbergs. Intel mögen in den klassischen ARM-Bereichen die Druckmittel fehlen, um diese Tour abziehen zu können, aber sobald ARM in Intels Territorium eindringt, sind sie da. In den ARM-Gefilden bleibt ihnen aber immer noch der Preiskampf, gerade in Märkten bei denen hundertstel Cent eine Rolle spielen, immer ein gutes Argument. Und da kann man mit etlichen Milliarden in der Kriegskasse einen verdammt langen Atem beweisen, sicher länger als fast alle anderen.

Ich sage klar, dass ich Intel nicht mag. Im Gegenteil. Ich habe diesen Verein immer verabscheut. Aber wenn ich wetten sollte, würde ich auf Intel setzen. ARM erinnert mich ein wenig an das AMD der 1990er. Es gab ein paar Achtungserfolge und vielleicht schafft man es nun, den Chipzilla kalt zu erwischen. Der Gegenschlag mag erst einmal auf sich warten lassen und es scheint, als würde Intel den Anschluss verlieren. Aber wenn er kommt, ist er mörderisch und es bleibt nur verbrannte Erde zurück. Man erinnere sich an 2006. Noch im Januar war AMD kurz vor dem Earnings-Crossover, dann kam der Conroe und einige Wochen später wurde die Firma an der Börse förmlich geschlachtet. Die ARM-Clique hat hier natürlich den Vorteil, dass es nicht nur eine Firma ist, sondern ein ganzer Schwarm. Und das ARM mehr als nur ein Produkt hat. Aber auch 300 Mücken bringen ein Pferd nicht um. Und so könnte es sehr gut sein, dass das Gleiche wie schon beim Alpha, beim PowerPC, beim SPARC und so weiter passiert. Das Intel zuletzt lacht und ARM wieder in der Nische verschwindet, aus der sie gekommen sind.

Das ist aber nun echt extrem Offtopic. :)
 
Das Intel zuletzt lacht und ARM wieder in der Nische verschwindet, aus der sie gekommen sind.
Aber man kann sich sicher sein das irgendwann jeder seinen Meister finden wird, auch Intel. Viele Unternehmen die pleite gingen standen einige Monate ganz weit oben und wirkten unantastbar.

Die ARM-Clique hat hier natürlich den Vorteil, dass es nicht nur eine Firma ist, sondern ein ganzer Schwarm.
Wie ist das überhaupt, ARM vergibt doch nur Lizenzen zum bau/nutzung der Technik oder wie war das? ARM baut ja selbst keine Hardware so wie ich das verstanden habe...

Grüße
 
Back
Top