Thema: SMP und die damit verbundenen Probleme

[erik.vikinger]

Hallo,


auf Plattformen außerhalb des x86-PC auf gute (3D-)Grafik zu treffen ist nahezu ausgeschlossen. Entweder hat man was proprietäres (manchmal direkt integriert wie beim OMAP4430 und manchmal als eigenständiger Chip) oder es gibt alle Infos aber das Ding taugt nichts (jedenfalls nicht viel mehr als ein einfacher Framebuffer). Ich hab selber mal nach eigenständigen Grafikchips mit offener Doku und guter Performance gesucht und eigentlich nichts gefunden. Theoretisch sollte es möglich sein eine PC-Grafikkarte in einem nicht x86-System zu betreiben (es gibt z.B. ARM-SoC mit PCI-Express-Root-Ports die man prinzipiell auf einen Slot führen könnte) aber dort hat man normalerweise keine I/O-Ports und auch das BIOS auf der Grafikkarte kann nicht laufen um diese zu initialisieren (hier könnte EFI endlich für Abhilfe sorgen), denn selbst wenn man alle Infos hat wie man einen Grafikchip zum Arbeiten benutzt so fehlt oft die Info zu Inbetriebnahme (das ich dieses Problem mal mit einem AHCI-SATA-Controller von JMicron hatte (für den man mir bzw. meinem Arbeitgeber trotz NDA nicht verraten hat wie man den nun in den AHCI-Modus schaltet) habe ich ja schon mal berichtet).

und bestimmte Hersteller müssen ja an die Specs kommen. Ob die die nicht mal leaken könnten

Diese Hersteller sind damit raus aus dem Geschäft, selbst die Konkurrenz macht mit denen keine Geschäft mehr. Geheimnisse, die dem Enduser nützen würden und eventuell gar den Verkauf ankurbeln könnten, aus zu plaudern ist in der IT-Branche eine Todsünde!


Grüße
Erik

[Svenska]

Hallo,

in den OMAP-Chips sind soweit ich weiß PowerVR-Steine für 3D drin, ansonsten findet man auch andere 3D-Beschleuniger. Allerdings nicht mit den PC-Lösungen vergleichbar, das ist wahr. Andererseits haben die ARM-Geräte meist nur geringe Auflösungen (320x240 bis 800x480, von Tablets mal abgesehen), da braucht man die Leistung selbst eh nicht.

Durch die Möglichkeit sekundärer PCI-Videokarten sind viele Treiber heutzutage in der Lage, auch ohne Hilfe von BIOS und Video-BIOS die Grafik zu initialisieren (z.B. parst der radeon-Treiber das AtomBIOS selbst), da beim Systemstart nur die primäre Videoschnittstelle initialisiert wird. Wenn Hardware oder Treiber das nicht unterstützen, dann können die Karten nur als Primärkarten laufen (ich weiß es von der S3 Trio64) - auf ARM-Systemen stellt sich die Frage eh nicht.

PowerVR war übrigens mit der Kyro und der Kyro II auch mal im PC-Markt aktiv, aber der Linux-Support ist ähnlich wie der von heute. Hab so ein Teil mal gefunden und ausprobiert... für Kernel 2.4 gibt es Binärtreiber (wenn man sie findet, die Originalseite gibt es nicht mehr), ansonsten garkeinen Support.

Außerdem basieren heute ja so gut wie alle auf dem Markt erhältlichen Grafikkarten auf den Referenzdesigns, die Treiber sind identisch mit neuem Logo und gut ist. Der Hersteller muss keine Informationen über die Chips mehr haben, solange er mit den Daten werben und den Chip einbauen kann.

Schade.

Gruß,
Svenska

[erik.vikinger]

Hallo,


ich hab mir mal das "System Reference Manual" des PandaBoards durchgelesen und denke das der Energiebedarf wohl so eher bei 4 Watt anzusiedeln ist (für CPU mit allem was drin ist und dem RAM, die ganzen Zusatzchips auf dem Board dürften nicht all zu viel benötigen aber das hängt sehr von deren Benutzung ab).
Dieses Board würde mich interessieren um daraus einen Streaming-Client für nen Fernseher zu machen aber dafür wird man wohl Infos benötigen die mindestens einen NDA erfordern.
Schade ist auf jeden Fall das kein echter LAN-Chip drauf ist, dieser USB-LAN-Chip ist eventuell nicht gerade berauschend schnell und dürfte auch einiges an CPU-Last (wegen dem ganzen USB-Kram) erzeugen. Irgendein ordentlicher GBit-LAN-Chip mit richtigem Busmastering wäre mir persönlich deutlich lieber, aber das gibt der OMAP 4 nicht her (für den RAM ist nur er der Master und nen BUS gibt es auch nicht) und integriert ist sowas leider auch nicht.

Das Problem mit den Nicht-PC-Grafikchips ist das diese entweder nur einen simplen Frambuffer anbieten (maximal mit Tripplebuffering) oder eben keine Infos frei verfügbar sind. Einen simplen Framebuffer kann ich in VHDL schneller programmieren als für so einen Chip das Datenblatt zu lesen und ihn ins Platinenlayout ein zu designen. Ich erwarte ja keine 3D-Leistung ich will einfach nur ordentlich und performant einen Desktop mit Fenstern ausgeben können. Dazu gehört für mich z.B. das alle Fensterinhalt bereits im Video-RAM liegen so das ich nur noch die Anzeige-Koordinaten ändern muss wenn der Nutzer ein Fenster verschiebt, es sollen dann auch vorher verdeckte Fenster wieder korrekt angezeigt werden ohne das die CPU auch nur ein Pixel übertragen muss. Toll wäre es auch wenn der Grafikchip sich die Pixel-Daten für die Fenster selber aus dem Hauptspeicher holt, nichts ist für eine aktuelle CPU so frustrierend wie stumpfsinniges Kopieren von Daten (die Hersteller von Ethernet-Controllern haben das bereits erkannt).


So aber das war jetzt wirklich genug Off-Topic in diesem Thread.

@bluecode:
vielleicht schreibst Du Bitte noch ein bisschen On-Topic über die lockfreien Datenstrukturen, würde sicher einige Leute hier interessieren (eventuell kann man das dann auch in einen Wiki-Artikel überführen)


Grüße
Erik

[FlashBurn]

Wieder mal nen OnTopic Beitrag.

Da wir ja in dem anderen Thread mal wieder schön streiten bin ich wieder mal auf ein Problem gestoßen was ich nicht so richtig einordnen kann.

Es geht darum das man erstmal nur einen Bereich im virtuellen Adressraum reserviert und diesen erst später mit physischen Speicher hinterlegt (erst wenn das erste mal auf die Page zugefgriffen wird, gilt also auch für Stacks die dynamisch wachsen können).
Jedes Mal wenn ein solcher PageFault aufgetreten ist und man eine Page gemappt hat, muss man ja auch den TLB-Eintrag invalidieren.
Ich behaupte mal dass das zu tierischen Performance Problemen auf SMP Systemen führen kann, weil da jedes Mal jede CPU unterbrochen wird.

Wie seht ihr das?

Eine andere Sache, ich habe mal irgendwo was gelesen das wenn ein PageFault zwecks aus dem Speicher lesen (und die Page halt noch nicht gemappt ist) erstmal nur eine Page die nur "0" enthält mappt und erst wenn dann auch darauf geschrieben wird, wird ne "normale" Page gemappt.

Was ist davon zu halten bzw. wird sowas die Performance nicht nochmehr kaputt machen und wann wird sowas überhaupt gemacht (das erst gelesen und dann geschrieben wird in einer neuen Page)?

[Svenska]

Das hatte ich im anderen Thread bereits erwähnt:

Pagefaults sind teuer.

Wenn du also das Mapping nicht bereits beim Zuweisen erledigst, dann wird das Programm zwar schnell den Adressraum zugeteilt kriegen, aber bei jedem Zugriff auf diesen "Speicher" einen Pagefault pro Page auslösen. Das kann man mit intelligenten/vorausschauenden Algorithmen abfedern, so man denn möchte (d.h. wenn Pagefaults in Reihe auftreten bereits präventiv mappen) oder man mappt bereits, wenn das Programm den Speicher reserviert.

Letzteres führt zu Speicherverschwendung, wenn die Anwendung diesen Speicher dann nicht nutzt (weil sie nur präventiv "für schlechte Zeiten" etwas bestellt hat). Wobei die Statistik zeigt, dass kleinere Speicherblöcke in der Regel auch direkt benutzt werden, meist aber nur für kurze Zeit vonnöten sind. Darum werden diese meist nicht auf dem Heap alloziiert, sondern auf dem Stack. (Gab mal Streit deswegen, weil MacOSX eher auf dem Heap alloziiert hat als Linux und bei einem Benchmark darum vollkommen versagt hat.)

Das heißt, du brauchst "große" Speicherblöcke nicht direkt mappen, solltest dies bei "kleinen" aber tun, um Pagefaults einzusparen. Oder du alloziierst "kleine" Blöcke woanders. Die Definition von "groß" und "klein" ist Anwendungsabhängig und wird von verschiedenen Betriebssystemen verschieden gehandhabt; allerdings gibt es überall verschiedene Strategien, wenn es performant sein soll.

Was das zweite betrifft, so halte ich es für unsinnig. Wenn du mappst, dann bitte gleich richtig. Außerdem sollte eine Anwendung davon ausgehen, dass frisch alloziierter Speicher nur Unsinn enthält und nichts lesen, was da nicht selbst reingeschrieben wurde. Aus Sicherheitsgründen ist das allerdings sinnvoll, da ein Programm so nicht an im System vorhandene Passwörter etc. herankommen kann; RAM wird in der Regel nicht genullt, bevor er der Anwendung übergeben wird.

Das musst du entscheiden.

Gruß,
Svenska