Verständnisfrage Speicherbandbreite

[lilgefo~]

Hallo,

kann mir mal jemand erklären wieso genau z.B. bei Grafikkarten derart hohe Speicherbandbreiten von Nöten sind. Wie kommen da Daten zustande die mit über 100GByte/s vershcikt werden und vor allem wohin sprich wo wird das gespeichert? (Oder werden die nicht bzw nur sehr sehr kurz gespeichert also pirnzip sofort wieder verworfen?)
Ebenso beim Cpu Cache in den ja auch dutzende an Gbyte/s geschaufelt werden kann aber der ja nur ein paar hundert oder tausend Kb groß ist. Oder passiert da was ganz anderes? :ugly:
Verstehe das nicht so recht.
thx fürs erklären

[Aquaschaf]

In einer Sekunde passiert sehr viel. Es ist ja nicht so dass tatsächlich hunderte Gigabytes an Daten existieren meistens. Eine CPU greift z.B. in jedem Takt immer wieder auf die selben Daten aus ihrem Cache zu bzw. modifiziert diese. Addiert man diese Zugriffe, dann kommt man auf so hohe Zahlen für den Datenverkehr pro Sekunde.

Bei einer Grafikkarte werden für jeden Frame Textur- und Geometrie-Daten gelesen und (in modernen Spielen) mehrere Puffer geschrieben. Da kommt einiges zusammen. Das multiplizierst du dann mit der gewünschten Framerate, beachtest dass die Bandbreitenangaben Spitzenwerte sind die in der Realität nicht erreicht werden und dann hast du die Antwort ;)

[lilgefo~]

Gut das du noch was dazu editiert hast denn das iwie iwo iwas passiert war mir auch shcon vorher klar. ;)

Das man auch auf die selben Daten mehrmals gleichzeitig zugreifen kann ist mir gar nicht in den Sinn gekommen aber das erklärtschonmal einiges.
thx :)

[Gast]

kann mir mal jemand erklären wieso genau z.B. bei Grafikkarten derart hohe Speicherbandbreiten von Nöten sind. Wie kommen da Daten zustande die mit über 100GByte/s vershcikt werden und vor allem wohin sprich wo wird das gespeichert?

Für einen Pixel der trilinear mit 16xAF gefiltert wird müssen bis zu 128 texel gelesen werden. Das ganze pro Texturschicht, wovon man heute einige hat.
Daraus entsteht dann 1 einzelner Pixel, der in den Speicher geschrieben werden muss. Zusätzlich muss noch für jeden Pixel 1x aus dem Z-Buffer gelesen und falls der neue Pixel vorne liegt auch 1x wieder geschrieben werden.

Sollte der Framebuffer in einem HDR-Format vorliegen und/oder es werden PP-Effekte angewendet muss das gesamte Bild nach dem Rendering nochmal gelesen, bearbeitet und anschließend wieder geschrieben werden.
Bei der Ausgabe muss schließlich jeder Pixel nochmal gelesen werden.

Wie du siehst kommt da eine ganze Menge zusammen.


Ebenso beim Cpu Cache in den ja auch dutzende an Gbyte/s geschaufelt werden kann aber der ja nur ein paar hundert oder tausend Kb groß ist. Oder passiert da was ganz anderes? :ugly:
Verstehe das nicht so recht.
thx fürs erklären

Bei CPUs ist die Bandbreite nicht so wichtig, da zählt die Latenz mehr. Sieht man beispielsweise schön am L3-Cache, der hat kaum mehr Bandbreite als der Hauptspeicher, aber eine deutlich geringere Latenz. Wichtig ist hier nur das genügend Bandbreite im Cache zur Verfügung steht, so dass diese niemals zum Flaschenhals werden kann.

Speicherzugriffe sind verdammt teuer, wenn ein Datum aus dem Hauptspeicher geladen wird braucht es hunderte CPU-Takte bis es endlich verwendet werden kann.
Caches nutzen hier 2 Dinge aus. Zum einen die Datenlokalität. In der Regel wird häufig auf hintereinanderliegende Speicheradressen zugegriffen. Deshalb lädt man bei einem Zugriff immer schon auf Verdacht eine ganze Cacheline in den Cache.
Richtig wertvoll wird der Cache wenn Daten mehrmals benötigt werden, beim nächsten Zugriff liegen sie dann schon im Cache und die Load-Use-Latenz wird deutlich kürzer.

[lilgefo~]

Für einen Pixel der trilinear mit 16xAF gefiltert wird müssen bis zu 128 texel gelesen werden. Das ganze pro Texturschicht, wovon man heute einige hat.
Daraus entsteht dann 1 einzelner Pixel, der in den Speicher geschrieben werden muss. Zusätzlich muss noch für jeden Pixel 1x aus dem Z-Buffer gelesen und falls der neue Pixel vorne liegt auch 1x wieder geschrieben werden.

Sollte der Framebuffer in einem HDR-Format vorliegen und/oder es werden PP-Effekte angewendet muss das gesamte Bild nach dem Rendering nochmal gelesen, bearbeitet und anschließend wieder geschrieben werden.
Bei der Ausgabe muss schließlich jeder Pixel nochmal gelesen werden.

Wie du siehst kommt da eine ganze Menge zusammen.




Bei CPUs ist die Bandbreite nicht so wichtig, da zählt die Latenz mehr. Sieht man beispielsweise schön am L3-Cache, der hat kaum mehr Bandbreite als der Hauptspeicher, aber eine deutlich geringere Latenz. Wichtig ist hier nur das genügend Bandbreite im Cache zur Verfügung steht, so dass diese niemals zum Flaschenhals werden kann.

Speicherzugriffe sind verdammt teuer, wenn ein Datum aus dem Hauptspeicher geladen wird braucht es hunderte CPU-Takte bis es endlich verwendet werden kann.
Caches nutzen hier 2 Dinge aus. Zum einen die Datenlokalität. In der Regel wird häufig auf hintereinanderliegende Speicheradressen zugegriffen. Deshalb lädt man bei einem Zugriff immer schon auf Verdacht eine ganze Cacheline in den Cache.
Richtig wertvoll wird der Cache wenn Daten mehrmals benötigt werden, beim nächsten Zugriff liegen sie dann schon im Cache und die Load-Use-Latenz wird deutlich kürzer.

Danke für die Ausführungen eine Sache ist mir aber immer noch nicht ganz klar: Ich nehme mal an, dass in dem Vram alle Daten die zur Pixel bzw. Bildberechnung nötigen Daten vorliegen. So und wenn die GPU nun anfaengt u rechnen wie du es oben auch beschrieben hast dann müssen diese Ergebnisse doch auch irgendwo gespeichert werden oder wird das dann direkt (quasi Pixel für Pixel) zur Ausgabe bereit gelegt (ich bin jetzt ma so tollkühn und stell mir mal vor das dafür der Frame Buffer da ist. Dort wird dann so wie ich das jetzt grad verstehe das aus den Rohdaten vom Vram berechnete Pixel bzw Bild abgelegt das ist ja auch nicht sehr groß (verglichen mit dem Inhalt vom Vram). Das heißt also, dass der Gbyte/s Durchsatz also tatsächlich nur dadurch zustande kommt, dass die GPU andauernd mehrfach auf alle möglichen Daten im Vram zugreift, ja?
Is das so richtig ca.?
thx

[Gast]

Ich nehme mal an, dass in dem Vram alle Daten die zur Pixel bzw. Bildberechnung nötigen Daten vorliegen. So und wenn die GPU nun anfaengt u rechnen wie du es oben auch beschrieben hast dann müssen diese Ergebnisse doch auch irgendwo gespeichert werden oder wird das dann direkt (quasi Pixel für Pixel) zur Ausgabe bereit gelegt (ich bin jetzt ma so tollkühn und stell mir mal vor das dafür der Frame Buffer da ist.

Genau, würde das Bild schon während der Berechnung ausgegeben hättest du ständig ein halbfertiges Bild am Monitor.
Berechnet wird allerdings nicht Pixel für Pixel sondern sogenannte Quads, also Pixelblöcke aus 2x2 Pixeln gleichzeitig.

Auf der gesamten GPU sind auch zu jedem Zeitpunkt 1000de Pixel gleichzeitig in Bearbeitung, das ist notwendig um Latenzen zu verstecken.

Das heißt also, dass der Gbyte/s Durchsatz also tatsächlich nur dadurch zustande kommt, dass die GPU andauernd mehrfach auf alle möglichen Daten im Vram zugreift, ja?


Klar.

[Spasstiger]

Der Framebuffer ist übrigens nur ein virtuelles Konstrukt, physikalisch wird er einfach über den VRAM umgesetzt.

[Gast]

Der Framebuffer ist übrigens nur ein virtuelles Konstrukt, physikalisch wird er einfach über den VRAM umgesetzt.

ALLES ist ein virtuelles Konstrukt, welches irgendwie physikalisch umgesetzt wird ;)

Auch ein Bit ist ein virtuelles Konstrukt, welches je nach Speicherform beispielsweise als Ladung oder durch Magnetisierung umgesetzt wird.

[Gast]

ALLES ist ein virtuelles Konstrukt, welches irgendwie physikalisch umgesetzt wird ;)

Auch ein Bit ist ein virtuelles Konstrukt, welches je nach Speicherform beispielsweise als Ladung oder durch Magnetisierung umgesetzt wird.

ich glaube eher der tiger hat gemeint, dass es früher durchaus grakas gab, die "echten" framebuffer hatten, der physikalisch anders an die gpu angebunden war als der vrama.
vgl. harvard vs. neumann-architektur: jedes unter win im user mode laufende programm verhält sich so als würde es auf einer harvard-maschine laufen, physikalisch sind x86-systeme aber von neumanns.

mfg,
zgep

[Pinoccio]

sOT/ Zahlen:
Speicherzugriffe sind verdammt teuer, wenn ein Datum aus dem Hauptspeicher geladen wird braucht es hunderte CPU-Takte bis es endlich verwendet werden kann.fefe hat Zahlen:
Memory Access Timings, Linux 2.6.31, Core i7
Page Fault, file on IDE disk 1.000.000.000 cycles
Page Fault, file in buffer cache 10.000 cycles
Page Fault, file on ram disk 5.000 cycles
Page Fault, zero page 3.000 cycles
Main memory access 200 cycles (Intel says 159)
L3 cache hit 52 cycles (Intel says 36)
L1 cache hit 2 cycles

Aus einem Vortrag (PDF), Seite 67 (http://www.linux-kongress.org/2009/slides/compiler_survey_felix_von_leitner.pdf)

mfg

[Nighthawk13]

Die hohe Speicherbandbreite bei Grafikkarte im Vergleich zu CPUs kommt von 2 Dingen:
- kleinere Caches on-Chip
- Durch die vielen Cores ist die Gesamtrechenleistung um Faktor 10+ höher (und dadurch auch der "Datenhunger" des Chips entsprechend höher)

Aus GPU-Programmierersicht hat man sogar vergleichsweise wenig Bandreite zur Verfügung, d.h. oft ist es schneller eine Formel doppelt auszurechnen als das Ergebnis zwischenzuspeichern und wieder auszulesen.