Integrierte Grafik: Merkt man den Speicherbandbreitenverlust unter 2D?

[Wolfram]

Hallo allerseits,

wenn integrierte Grafikkarten der CPU nutzbare Speicherbandbreite rauben- kann man das auch schon zB im Office-Betrieb- also unter 2D- merken?

Ich habe hier zB einen X2 3600+ auf einem nVidia 6150/430-Board. Er taktet per RMClock zwischen 1,2 GHz (Speicher 240 MHz) und 2,28 GHz (Speicher 380 MHz). Ich habe nur einen DDR2-Speicherriegel drin, also 64bit-Single-Channel.

Nutzungsprofil jetzt gerade: Opera (51 Tabs in mehreren Fenstern), Outlook (mehrere Fenster), Word, FritzFax, zwei Downloads per µTorrent. CPU-Auslastung ca 50 und 70 Prozent (bei 2,28 GHz).

Was schätzt Ihr?

TIA,

Wolfram

[Gast]

ich glaube du solltest, weniger tabs öffnen

bei normaler anwendung merkt mans kaum (128bit eh nicht mehr)

glaub ich^^

[Zool]

Bei 2D merkt man keine Nachteile von Onboard-GFX. Selbst 200 Fenster machen keine Problem. Es sei denn, die werden alle gleichzeitig bewegt...

[Wolfram]

Bei 2D merkt man keine Nachteile von Onboard-GFX. Selbst 200 Fenster machen keine Problem. Es sei denn, die werden alle gleichzeitig bewegt...
Das schaff' ich dann doch nicht...:biggrin:

Die hohe CPU-Last erklärte sich übrigens, wie ich gerade feststellte, durch einen hängengebliebenen Quicktime-Prozess. Jetzt habe ich bei o.g. Profil noch je 10-15 Prozent Last bei 1,2 GHz.

Aber wenn man's eh nicht merkt...

[BlackArchon]

ich glaube du solltest, weniger tabs öffnen

bei normaler anwendung merkt mans kaum (128bit eh nicht mehr)

glaub ich^^
Und, ich, glaube, du, setzt, Kommas, falsch. ;(

[Wolfram]

Und, ich, glaube, du, setzt, Kommas, falsch. ;(
Dieser Beitrag erreicht 0,6 aths auf der nach oben offenen Klugscheißerskala...:biggrin:

[BlackArchon]

Danke, das war mir jetzt echt einen RL-Lacher wert. :biggrin:

Aber um nicht ganz vom Them abzuschweifen: Der Geschwindigkeitsverlust wird nicht spürbar sein. Schließlich gibt es auch genügend Sockel 754-Boards (also prinzipiell nur Singlechannel) mit Onboard-Grafik, da wäre schon mal was durchgesickert. Aber testweise kannst du ja einfach mal eine Graka einbauen.

[Wolfram]

Um dieses Thema nochmal aus der Versenkung herauszuholen:
Ich habe dazu in de.comp.hardware.graphik später mal eine interessante Antwort von Arno Welzel bekommen:

Message-ID: <479dca1a$0$27206$9b4e6d93@newsspool1.arcor-online.net>


> Arno Welzel wrote:
>> Wolfram Goetz wrote:
>
> Wobei hast Du denn spürbare Performanceverluste gehabt?

C-Compiler bei einem grösseren Projekt. Compile-Zeit für das gesamte
Projekt lag so um die 30 Minuten mit Onboard-Grafik. Nach Einbau einer
Grafikkarte in den betroffnen Maschinen reduzierte sich die Zeit fast
auf die Hälfte. Beobachtet wurde das auf nahezu identischen 5 Geräten
mit 2,8 GHz P4 und je 1 GB RAM, die mit Onboard-Grafik (etwas günstiger,
dafür wurde dann mehr RAM dazugenommen) aber auch passendem Steckplatz
für eine evtl. Nachrüstung mit einer besseren Grafikkarte geordert
wurden. Ich dachte davor auch, dass Onboard-Grafik vollkommen ausreichen
würde, bis ich durch die praktische Anwendung eines Besseren belehrt wurde.

> verfügbaren Speicherbandbreiten sind im Verhältnis zu dem, was für
> 2D-Darstellung benötigt wird, so groß, daß man meines Wissens weder bei der
> Grafikausgabe noch bei der CPU-Leistung irgendeinen Unterschied bemerken
> sollte. Hier hat mal jemand eine Beispielrechnung aufgemacht:
> http://www.forum-3dcenter.org/vbulletin/showthread.php?p=2877236#post2877236
> Selbst bei rund 700 MB/s für 1920x1200 bei 32bit und 75Hz als TFT-Worstcase
> und dem genannten Beispielrechner mit nur 2GB/s Speicherbandbreite ist das
> nur ein Drittel. Na gut, immerhin ein Drittel, hm... wie gesagt: In welchem
> Szenario hast Du es gemerkt?

Siehe oben - ein Drittel kann viel ausmachen, wenn die Anwendung primär
Speicherbandbreite braucht und nur wenig in den Caches machen kann.

Dazu kommt aber, dass die CPU ja nicht einfach nur x Prozent weniger
Bandbreite bekommt, sondern dass durchgängige Bursts einfach nicht
möglich sind, weil immer wieder die GPU dazwischenfunkt. Das kann im
Einzelfall dann deutlich mehr als nur ein Drittel ausmachen.

Bei Anwendungen, die nur selten auf den Speicher zugreifen, weil der
Code grösstenteils im Cache abläuft, ist das aber in der Tat nicht so
kritisch.

[grandmasterw]

Wär interessant, wie schnell der Compiler ist, wenn man das Fenster mit dem Output minimiert.

[Wolfram]

Wär interessant, wie schnell der Compiler ist, wenn man das Fenster mit dem Output minimiert.
Ist das nicht egal? Ich hätte jetzt gedacht, die 2D-Ausgabe benötigte bei gegebener Auflösung/Farbtiefe/Bildwiederholfrquenz permament die gleiche Speicherbandbreite.

[RavenTS]

Ist das nicht egal? Ich hätte jetzt gedacht, die 2D-Ausgabe benötigte bei gegebener Auflösung/Farbtiefe/Bildwiederholfrquenz permament die gleiche Speicherbandbreite.

Wenn es da keine "Bandbreitenspartechniken" gibt und dann einfach nur immer wieder das letzte unveränderte Bild des Framebuffers ausgegeben wird...

Nur dazu müsste wohl vorher irgendwie erkannt werden, daß da nichts passiert, so daß nix berechnet werden muss, was bestimmt schon wieder "zu aufwendig" wär.

Generell hängt die Antwort sicherlich vom konkreten System ab. Wenn man ein bandbreitengesegnetes INTeL-System hat, wo der FSB eh nicht die ganze RAM-Bandbreite einen guten Speichers ausnutzen kann dürfte der Effekt wohl wirklich nahe Null sein. Bei einem lahmen Single-Channel INterface dagegen...

[grandmasterw]

Ich hab unter Linux teilweise große Unterschiede gesehn. Wenn da die Ausgaben schön kantengeglättet im Terminal landen, und da recht viel ausgegeben wird, bremst das schon, wenns Fenster größer wird.
Kommt halt drauf an, welche Beschleunigungen da der Grakachip macht, und was per Software geschieht. Testen sollte mans allerdings.

[sputnik1969]

Kommt halt drauf an, welche Beschleunigungen da der Grakachip macht, und was per Software geschieht. Testen sollte mans allerdings.
Das ist (fast) egal, denn beides bedeutet zusätzliche Speicherbandbreite.

Je mehr Bewegung auf dem Bildschirm ist und je komplexer die Desktopeffekte desto größer der Bandbreitenbedarf. Wenn zusätzlich noch viel CPU-Leistung verbraten wird (Compiler) und Festplattenzugriffe stattfinden (DMA oder schlimmer CPU-Leistung + Speicherbandbreite) ist der Unterschied zwischen Onboardgrafik und Extra-Grafikkarte schon deutlich spürbar.

Auch bei Officeanwendungen kann es zu spürbaren Einbußen kommen, besonders wenn es um komplexe und grafiklastige Dokumente geht.

Bei 128 Bit (Dualchannel) ist der Einbruch weniger stark, aber trotzdem je nach Anwendung trotzdem spür- und messbar.

[Zool]

Wenn der Speicher deutlich mehr Bandbreite liefert als der FSB/Prozi verbraucht, bedarf es bei 2D schon einiger Verrenkungen, um da Einbrüche zu bemerken.

[stickedy]

Also ich arbeite sehr häufig an einem K8M800 (Sockel754) und ich muss sagen, dass der PC der mit am Abstand flotteste PC dieser Leistungsklasse ist, den ich je gesehen/bedient hab. Keine Ahnung Ahnung warum, ist aber so. Irgendwelche Performance-Einbrüche hab ich da auch bei großen PDF und Grafik-Sachen bisher nie erlebt.

Evtl. ist das was da oben beim Kompilieren geschildert wird stark vom verwendeten Chipsatz/Treiber abhängig? Ich mein die nötige Bandbreite für 2D ist doch wirklich selbst für einen Single-Channel-Chipsatz vernachlässigbar.

[tombman]

Dieser Beitrag erreicht 0,6 aths auf der nach oben offenen Klugscheißerskala...:biggrin:
ROFL, der war GUT ;)