Hauptspeicher und Swap
- Ersteller ath0
- Erstellt am
Wie ich oben schrieb, es kommt auf den Treiber an. Früher musste X.org den Grafik-RAM auf physikalische Adressen mappen. Solange der Adressraum groß genug war, hatte das keine Auswirkungen, außer das RES hochging. Wenn der Adressraum nicht groß genug war, wurden halt Hauptspeicheradressen überdeckt. Nur irgendwann wurde das unpraktikabel, weil Grafikkarten immer RAM hatten und längst nicht ganze Welt ein AMD64-System einsetzte. Eine der großen Neuerungen nach X.org 7.0 war daher ein neues Speichermanagement, was Treiber nutzen können aber nicht müssen. Dabei werden nur noch die beiden Framebuffer in den physikalischen Adressraum gemappt, ein Framebuffer hat exakt die Größe um einmal den virtuellen Desktop speichern zu können. Kann man bei xf86-video-radeon schön sehen:
1. Diese Karte hat 1024 Megabyte Grafikspeicher.
2. Xorg belegt aktuell 113 Megabyte RES.
3. xrandr(1) sagt "Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 1680 x 1680" -> Der virtuelle Desktop ist 1680x1050 Pixel bei einer Farbtiefe von 24 Bit groß.
Daraus folgt: 1680 * 1050 * 24 = 42336000 Byte = 40 Megabyte. Das ganze mal 2, da es zwei Framebuffer sind: 40 * 2 = 80 Megabyte. X.org benötigt daher 80 Megabyte für die Framebuffer und 113 - 80 = 33 Megabyte für die Primitives und sich selbst.
Wenn X.org nun nachher einige Stunden gelaufen ist, wird der Wert deutlich angestiegen sein. Einmal, da X.org sehr aggressiv cached, allerdings unter Einsatz von Back Pressuring. Sprich, die Caches werden freigegeben, wenn der Rest des System eine gewisse Menge an Speicherbedarf überschreitet. Dann leckt X.org nach wie vor Speicher, auch wenn es zugegeben schon deutlich besser geworden ist. In X.org 7.5 sollen nochmal >50 Speicherlecks geschlossen sein, ich werde es nächste Woche mal ausprobieren und dann mal schauen
1. Diese Karte hat 1024 Megabyte Grafikspeicher.
2. Xorg belegt aktuell 113 Megabyte RES.
3. xrandr(1) sagt "Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 1680 x 1680" -> Der virtuelle Desktop ist 1680x1050 Pixel bei einer Farbtiefe von 24 Bit groß.
Daraus folgt: 1680 * 1050 * 24 = 42336000 Byte = 40 Megabyte. Das ganze mal 2, da es zwei Framebuffer sind: 40 * 2 = 80 Megabyte. X.org benötigt daher 80 Megabyte für die Framebuffer und 113 - 80 = 33 Megabyte für die Primitives und sich selbst.
Wenn X.org nun nachher einige Stunden gelaufen ist, wird der Wert deutlich angestiegen sein. Einmal, da X.org sehr aggressiv cached, allerdings unter Einsatz von Back Pressuring. Sprich, die Caches werden freigegeben, wenn der Rest des System eine gewisse Menge an Speicherbedarf überschreitet. Dann leckt X.org nach wie vor Speicher, auch wenn es zugegeben schon deutlich besser geworden ist. In X.org 7.5 sollen nochmal >50 Speicherlecks geschlossen sein, ich werde es nächste Woche mal ausprobieren und dann mal schauen
h^2
hat ne Keule +1
Hmm wie sind denn aus den Bits Bytes geworden?
Selbst wenn jeder Bit Farbtiefe einen Byte braucht komme ich auf:
2048 * 1152 * 24 * 2 = 113246208 B ~= 110MB
Direkt nach dem Start braucht der XServer bei mir 486M RES, also braucht er für dieselben Dinge wie bei dir 486-110 = 376M, also mehr als das Zehnfache. Kann das stimmen?
surfer
Advocatus Diaboli
Hi,
1024x786 bei 16 Bit Farbtiefe benötigt an Platz halt
1024x786 -> 786.432 Punkte
786.632 Punkte bei 16 verschiedenen Farbewerten die jeder davon haben kann
-> 786.432 * 16 => 12.582.912
==> 12.582.912 Bit werden für die Information bzw Rohdaten benötigt
1 Byte = 8 Bit
-> 12.582.912 Bit / 8 = 1.572.864 Byte
1.572.864 Byte / 1024 = 1.536 KBybte
1.536 KByte / 1024 = 1,5 MByte
Ein Einzelbild mit der Auflösung 1024x786 bei einer Farbtiefe von 16 Bit benötigt demzufolge 1,5 MB RAM auf der Grafikkarte.
1680x1050x24 => 42.336.000 Bit -> 5.292.000 Byte -> ~5.168 kB -> ~5,05MB
Der Rest den Yama geschrieben hat finde ich soweit total logisch, entspricht ja eigentlich einfach dem Prinzip von Memory Mapped IO.
Davon abgesehen benutzen moderne Grafikkarten ja den Grafikkartenspeicher vor allem auch um Informationen entgegen zu nehmen und z.B. für 3D dann selbst wie ein kleiner Computer aufzuarbeiten, die Berrechnung der Bilder findet ja nicht mehr durch die CPU des Systems sondern die GPU der GraKa statt. Vielleicht hat das ja etwas damit zu tun denn:
Im Prinzip komme ich bei 1024MB RAM wenn ich jede Speicherzelle auf eine gleichgroße im RAM umlege auf 1GB RAM bzw besser gesagt 1GB das ich vom maximal adressierbaren RAM abziehen müßte um auf meinen maximal einbaubaren RAM zu kommen. ... Passt auch nicht
Jetzt fange ich mal so richtig an zu spekulieren:
Nehmen wir an das jedes Byte an einem 64Bit Datenbuss also dann einem Byte pro Takt oder so in einem 64 Bit großen Speicherberreich im RAM abgelegt wird, dann wären für
1680x1050x24 => 42.336.000 Bit -> 5.292.000 Byte -> ~5.168 kB -> ~5,05MB nötig.
bei 64 / 8 = 7 also 1680x1050x24 * 7 = ~35,33MB RAM <- klingt schon besser. Macht allerdings auch nicht so wirklich viel Sinn wenn ich mir überlege das das 7-fache vom eigentlich nötigen Speicher belegt wird und ich jetzt auch keinen Vorteil daran finden kann bei ner 64Bit Grafikkarte auf 8Bit und dann zurück auf 64 Bit für ein 64 Bit System zu gehen (grübel waren bei amd64 jetzt nur 48 Pins für die Adressierung rausgelegt? meine Doch der Datenbus hatte volle 64). ... <- das ist jetzt nur mal der zwanghafte versuch von 5MB auf 40 zu kommen.
Naja, ich habe echt toal keinen Plan von GraKas und wie Xorg funktioniert, daher sind diese überlegungne eigentlich nichts Wert. So auf die schnelle kann ich Yamagis rechnung nur wirklich nicht nachvollziehen.
1024x786 bei 16 Bit Farbtiefe benötigt an Platz halt
1024x786 -> 786.432 Punkte
786.632 Punkte bei 16 verschiedenen Farbewerten die jeder davon haben kann
-> 786.432 * 16 => 12.582.912
==> 12.582.912 Bit werden für die Information bzw Rohdaten benötigt
1 Byte = 8 Bit
-> 12.582.912 Bit / 8 = 1.572.864 Byte
1.572.864 Byte / 1024 = 1.536 KBybte
1.536 KByte / 1024 = 1,5 MByte
Ein Einzelbild mit der Auflösung 1024x786 bei einer Farbtiefe von 16 Bit benötigt demzufolge 1,5 MB RAM auf der Grafikkarte.
1680x1050x24 => 42.336.000 Bit -> 5.292.000 Byte -> ~5.168 kB -> ~5,05MB
Der Rest den Yama geschrieben hat finde ich soweit total logisch, entspricht ja eigentlich einfach dem Prinzip von Memory Mapped IO.
Davon abgesehen benutzen moderne Grafikkarten ja den Grafikkartenspeicher vor allem auch um Informationen entgegen zu nehmen und z.B. für 3D dann selbst wie ein kleiner Computer aufzuarbeiten, die Berrechnung der Bilder findet ja nicht mehr durch die CPU des Systems sondern die GPU der GraKa statt. Vielleicht hat das ja etwas damit zu tun denn:
Im Prinzip komme ich bei 1024MB RAM wenn ich jede Speicherzelle auf eine gleichgroße im RAM umlege auf 1GB RAM bzw besser gesagt 1GB das ich vom maximal adressierbaren RAM abziehen müßte um auf meinen maximal einbaubaren RAM zu kommen. ... Passt auch nicht
Jetzt fange ich mal so richtig an zu spekulieren:
Nehmen wir an das jedes Byte an einem 64Bit Datenbuss also dann einem Byte pro Takt oder so in einem 64 Bit großen Speicherberreich im RAM abgelegt wird, dann wären für
1680x1050x24 => 42.336.000 Bit -> 5.292.000 Byte -> ~5.168 kB -> ~5,05MB nötig.
bei 64 / 8 = 7 also 1680x1050x24 * 7 = ~35,33MB RAM <- klingt schon besser. Macht allerdings auch nicht so wirklich viel Sinn wenn ich mir überlege das das 7-fache vom eigentlich nötigen Speicher belegt wird und ich jetzt auch keinen Vorteil daran finden kann bei ner 64Bit Grafikkarte auf 8Bit und dann zurück auf 64 Bit für ein 64 Bit System zu gehen (grübel waren bei amd64 jetzt nur 48 Pins für die Adressierung rausgelegt? meine Doch der Datenbus hatte volle 64). ... <- das ist jetzt nur mal der zwanghafte versuch von 5MB auf 40 zu kommen.
Naja, ich habe echt toal keinen Plan von GraKas und wie Xorg funktioniert, daher sind diese überlegungne eigentlich nichts Wert. So auf die schnelle kann ich Yamagis rechnung nur wirklich nicht nachvollziehen.
Zuletzt bearbeitet:
surfer
Advocatus Diaboli
Ich habe mal schnell bei x.org vorbei eschaut und fand da auf Anhieb folgendes:
http://www.x.org/wiki/Development/Documentation/HowVideoCardsWork
http://www.x.org/wiki/Development/Documentation/Performance#FramebufferLayout
Der Zugriff auf den GraKa-RAM findet dabei wohl (unter anderem wenn ich das richtig gelesen habe ggf. auch) über MMIO statt, wobei halt der Speicher der GraKa im Adressbereich des Systemspeichers gemappt wird.
Ok, mal abgesehen davon, das die ganze Sache wie es wirklich genau funktioniert extrem abhaengig von der verwendeten Hard-/Software ist bedeutet das für mich so weit, das ich bei bestem Willen nicht auf mehr als 5MB (bzw bei 2 FBs 10MB) für den Framebuffer komme.
Meine Spekulation im vorherigen Post ist übrigens totaler Dummfug, ich sollte mir mal angewöhnen das Brainstorming vorm Posten und nicht währenddessen zu machen. xD
Abgesehen davon würde ich behaupten das große Speicherunterschiede wie bei h^2 und Yamagi fast schon normal sind da das verhalten von Xorg bzw den Treibern (wie Yamagi ja schon geschrieben hat) wohl stark von der eingesetzten Hardware/den eingestzten Treibern abhängig ist. 2 Systeme also einfach so vergleichen halte ich für eine schlechte Idee.
Nur wie Yamagi auf die 40 MB kommt lässt mir keine Ruhe, einfach bei der Überlegung ein /8 vergessen oder steckt da mehr hinter? *g*
http://www.x.org/wiki/Development/Documentation/HowVideoCardsWork
http://www.x.org/wiki/Development/Documentation/Performance#FramebufferLayout
Der Zugriff auf den GraKa-RAM findet dabei wohl (unter anderem wenn ich das richtig gelesen habe ggf. auch) über MMIO statt, wobei halt der Speicher der GraKa im Adressbereich des Systemspeichers gemappt wird.
Ok, mal abgesehen davon, das die ganze Sache wie es wirklich genau funktioniert extrem abhaengig von der verwendeten Hard-/Software ist bedeutet das für mich so weit, das ich bei bestem Willen nicht auf mehr als 5MB (bzw bei 2 FBs 10MB) für den Framebuffer komme.
Meine Spekulation im vorherigen Post ist übrigens totaler Dummfug, ich sollte mir mal angewöhnen das Brainstorming vorm Posten und nicht währenddessen zu machen. xD
Abgesehen davon würde ich behaupten das große Speicherunterschiede wie bei h^2 und Yamagi fast schon normal sind da das verhalten von Xorg bzw den Treibern (wie Yamagi ja schon geschrieben hat) wohl stark von der eingesetzten Hardware/den eingestzten Treibern abhängig ist. 2 Systeme also einfach so vergleichen halte ich für eine schlechte Idee.
Nur wie Yamagi auf die 40 MB kommt lässt mir keine Ruhe, einfach bei der Überlegung ein /8 vergessen oder steckt da mehr hinter? *g*
Zuletzt bearbeitet:
h^2
hat ne Keule +1
Na, es bleibt doch trotzdem die Frage, wie total unabhängig von der Auflösung[1], Yamagi mit dem radeon-Treiber (und wie ich den anderen Posts entnehme einer Karte im Bereich r600-r700) auf 113MB RES kommt, und ich mit einer r600 und dem radeon-Treiber auf das 5-fache komme.
Ist das ein Bug, soll ich das reporten?
[1] Da haben wir ja gerade festgestellt, dass der Unterschied nicht so riesig ist.
Ist das ein Bug, soll ich das reporten?
[1] Da haben wir ja gerade festgestellt, dass der Unterschied nicht so riesig ist.
surfer
Advocatus Diaboli
Hi,
wenn ich das aus einem anderen Post richtig in Erinnerrung habe macht Yamagi eine minimale X-Server installation und geht nicht über das komplettpaket xorg. Wenn Treiber und Hardware gleich sind würde ich behaupten die einzige logische erklärung das dein xorg mehr Speicher einnimmt wäre das es mehr laden will.
wenn ich das aus einem anderen Post richtig in Erinnerrung habe macht Yamagi eine minimale X-Server installation und geht nicht über das komplettpaket xorg. Wenn Treiber und Hardware gleich sind würde ich behaupten die einzige logische erklärung das dein xorg mehr Speicher einnimmt wäre das es mehr laden will.
h^2
hat ne Keule +1
Naja, ich meinte ja, dass bei mir *direkt* nach dem Start schon soviel gefressen wird. Da ist KDE4 und eine yakuake-Instanz im Hintergrund, sonst nix.
Genau das ist der Punkt. Ich nutze Openbox, nach dem Start lädt er nur einige sehr kleine Widgets in den Speicher. So ein Openbox-Theme ist im Prinzip nur eine XML-Datei, ein paar Farben und ein paar Verläufe. KDE allerdings hat wesentlich komplexere Themes, richtig schön mit vielen Grafiken, Effekten, etc. Wenn er sie hochlädt, kommt da im X.org-Server schnell eine Menge Kram zusammen, der gecached wird.