Dual-Prozessoren und Linux


EvilDragon

Administrator
Staff member
Joined
Mar 4, 2003
Messages
29,986
Age
46
Location
Ingolstadt
Nur kurz zur Info:
Squidge hat ein bisschen rumprobiert.
So wie's ausschaut, kann man den 2. Prozessor ohne Probleme mit dem SDK unter Linux programmieren :)

Also hat man wirklich 2 Prozessoren zur Verfügung :)
 
peinlich naja nich ganz
weil soll ja nur video co prozessor eigentlich darstellen

das es so einfach ist, hätt ja keiner wissen können, aber das ist super
 
Das war vornerein klar :) die linux kernel unterstützen schon lange SMP.
Ich offe das bald mal jemand richtig mit den Muskeln von diesem süßen Ding spielt und endlich die Saus aus BEIDEN prozzis rausholt.
 
nibel said:
Das war vornerein klar :) die linux kernel unterstützen schon lange SMP.
Ich offe das bald mal jemand richtig mit den Muskeln von diesem süßen Ding spielt und endlich die Saus aus BEIDEN prozzis rausholt.

nein war leider nicht von vornerein klar
gph hat diese cpu in den freigegebenen specs als video co prozessor angegeben

also quasi als gpu
und inwiefern man jetzt ne gpu frei programmieren kann beispielsweise für ne sound engine kannst du dir ausmalen ;)
 
ARM stellt afaik keine GPUs her, war in meinen Augen von anfang an klar dass es eine CPU ist. Der ARM940T ist allerdings keine vollwertige CPU sondern eine Co-CPU. Insofern kann man nicht sagen:

200mhz + 200mhz = 400mhz :) -was man so oder so auch nicht könnte, stimmt ;)

Die Entwickler müssen eben dem Haupt CPU wichtige Aufgaben zukommen lassen und die Co CPU kümmert sich derweil zB. um den Sound.
 
Und SMP wird wohl auf keinen Fall funktionieren, da ich nicht glaube, das Linux auf zwei unterschiedlichen CPUs läuft im SMP mode...

Und selbst wenn er das täte: Ich glaube es wäre dann doof, wenn der Scheduler entscheidet, den Main Thread auf der "langsameren" CPU laufen zu lassen...
 
Schade, dass es kein Echtzeitbetriebssystem ist. Da koennte man dann evtl. in Abstimmung mit den Geschwindigkeiten der Cores und der gesetzten Deadline / Arbeitsaufwand die Threads entsprechend auf die Prozessoren verteilen (spaete Deadline / geringer Arbeitsaufwand -> langsamerer Core). Naja, aber Echtzeit waere sowieso nix. Da wuerde man sicherlich etwas an Performance verlieren, aber man koennte z.B. 25fps bei einem Spiel garantieren ;-).
Evtl. koennte man den Scheduler in Linux entsprechend anpassen, aber ich glaube, dass das keine so einfache Aufgabe waere..
 
Es gibt Patches für Linux und auch einen "surrounding Ring" für den Kernel, der Echtzeitfähigkeit mit geringer Latenz realisiert - sollen wohl schon fast so schnell sein wie QNX...
 
Naja 200mhz+irgendwas ist immer noch besser als 200mhz+nichts.
Da wird man schon irgendetwas mit anzufangen wissen.
Und ARMs sind definitiv keine GPUs.
Also lasst uns alle vor Aufregung durchdrehen bis endlich die ersten dicken Apps erscheinen, ich werde das auf jeden Fall tun.
 
kilroy said:
Es gibt Patches für Linux und auch einen "surrounding Ring" für den Kernel, der Echtzeitfähigkeit mit geringer Latenz realisiert - sollen wohl schon fast so schnell sein wie QNX...
gibts die auch fuer was anderes als x86? wie siehts mit overhead durch das system aus?
und wieso dann immer noch linux, wenn man auf solchen kisten relativ leicht auch ohne OS klarkommt, aufm gp32 ging es ja auch?
 
weil ein os toll ist *nop*
Es bringt viele Vorteile (acuh ein paar Nachteile),
so sind z.B.: schon viele Funktionen in Linux implentiert und muss sie nicht mehr selbst schreiben.
 
nibel said:
weil ein os toll ist *nop*
Es bringt viele Vorteile (acuh ein paar Nachteile),
so sind z.B.: schon viele Funktionen in Linux implentiert und muss sie nicht mehr selbst schreiben.
wenn man nicht grad preemptive multitasking will (wofuer will man das auf so ner kiste?) kann man so ziemlich jede funktion die von linux angeboten wird auch ueber libraries bekommen.

ich mein, welche services brauchts denn? posix lib (newlib)? filesystem (fat support libraries gibts zuhauf)?

das erkauft man sich bei linux mit dem nachteil, dass man jede speichernutzung erstmal beim betriebssystem anmelden, jeden hardwarezugriff ueber nen SWI (linux) oder ne mmu fault trap (win CE) abwickeln muss.

fuer quickies sicher nett, fuer echte ports, die die eigenheiten dieser hardware nutzen wollen (zB coprozessor, der nicht von linux gemanaged wird, oder videoprozessor mit klar definiertem featureset) eher hinderlich.
 
das wird sicher noch verbessert (sollte ohne große probleme auf die hälfte reduziert werden können), aber erstmal gibt es wichtigere sachen zu fixen ;)
 
Back
Top