Announcement: there is an English version of this forum on Bei einem aktuellen Problem geht es darum, eine Art von DMA auf einem DDR-Speicher durchzuführen. Die Idee ist dem FPGA die Steuerung des RAMs zu überlassen und mit einem parallelen System auf den FPGA zuzugreifen. Dabei habe ich feststellen müssen, dass FPGAs offenbar(?) nicht an die Bandbreite von PC Controllern herankommen, weil sie kein DDR4 können, einen geringeren Speichertakt verwenden und zudem auch nur mit 8 Bit je DDR-RAM arbeiten, statt mit 64. Ist das richtig? Ich bin jetzt nicht so 100% sicher, wie ich das rechnen muss, habe auch im Internet nachgesehen, um zu vergleichen, mit welchen Bandbreiten man da hinkommen kann. Beim FPGA (Sparten 6 ist eingebaut) ist es offenbar so, dass man bis zu 4 parallele Controller verwenden kann, die ihrerseits 8 und damit wieder 64 Bit wegspeichern können. Das Höchste der Gefühle scheint wohl 200x4 MHz zu sein. Von der Geschwindigkeit her kann ich das intern auch sicher voll ausnutzen. Wie ist das beim PC-RAM? Dort sind pro RAM 64 Bit möglich und dies auch noch im Dual Channel-Modus, oder noch mehr (?). Kann man die dann auch so schnell ansteuern? Wie kann man das mal sauber gegenüberstellen? Ist meine Datentabelle richtig? Wie komme ich an einen DDR-Controller heran, um Daten vorher mit der geringen Geschwindigkeit einzufügen? DSP an den FPGA und dann beide Daten auf einen solchen Controller, nehme ich an. Ist das realistisch, einen PC-DDR4 Controller einzuplanen und den mit einem FPGA anzusteuern? Sind die Werte richtig? FPGA PC-DDR3 PC-DDR4 PC-DDR4 4channel(?) Taktfrequenz 200 266 233 233 DDR-Faktor 8 8 16 16 Speichertakt 1600 2128 3728 3728 Bitbreite 8 64 64 64 MBits /s 12.8 136.2 238.6 238.6 Bits / Byte 8 8 8 8 MBytes /s 1.600 17.0 29.8 29.8 RAMs 4 1 1 1 Channels 1 2 2 4 GBytes /s 6,4 34,0 59,6 119,3 Ist die Rechnung zumindest richtig?
Dagobert schrieb: > Dabei habe ich feststellen müssen, dass FPGAs offenbar(?) nicht an die > Bandbreite von PC Controllern herankommen, weil sie kein DDR4 können, > einen geringeren Speichertakt verwenden und zudem auch nur mit 8 Bit je > DDR-RAM arbeiten, statt mit 64. Ist das richtig? Ob DDR4 schon von einem FPGA unterstützt wird, weiß ich nicht. Dass FPGAs nur mit 8 bit breiten Datenbussen auf den Speicher zugreifen, ist aber ein Gerücht: es sind auch deutlich breite Speicherinterfaces möglich. Das zeigen dir auch schon alle Eval-Boards, bei denen ein DRAM-Modul (mit 64Bit Breite) verbaut ist. Der Spartan 6 ist mit seinen fest eingebauten Speichercontrollern (und deren Beschränkung auf 16Bit) eher die Ausnahme als die Regel. Dagobert schrieb: > Ist meine Datentabelle richtig? Schon die erste Zeile ist für mich nicht eindeutig. Wenn du mit "Taktfrequenz" wirklich den externen Takt des DRAMs meinst, dann geht der von einer Speichergeneration auf die nächste um rund einen Faktor 2 nach oben. (Auf Wikipedia ist etwas verwirrend von verschiedenen Takten die Rede, weil natürlich intern die Array-Zugriffe tatsächlich mit einer langsameren Taktung ablaufen. Der extern anlegbare Takt ist aber eine eindeutige Bezugsgröße, bei Wikipedia heißt der IO-Takt.) Um Missverständnisse zu vermeiden solltest du z.B. auch bei einer Angabe wie "Speichertakt 2133" genau definieren, was du damit meinst. Und bei DDR3 gabe es meiner Erinnerung nach nicht nur 2 Channels sondern bis zu 3. Dagobert schrieb: > Ist das realistisch, einen PC-DDR4 Controller einzuplanen und den mit > einem FPGA anzusteuern? Einen PC-DDR4 Controller findest du in in der CPU eines jeden DDR4-PC. Den kannst du natürlich mit einem FPGA kopplen, das du geeignet an den PC anbindest, bist dann aber durch die Bandbreite der Ankopplung limitiert. Dagobert schrieb: > Wie komme ich an einen DDR-Controller heran, um Daten vorher mit der > geringen Geschwindigkeit einzufügen? Wenn du "vorher langsam Daten einfügst" und das dann auf einen schnellen Speichercontroller gibst, ist die Bandbreite durch das langsame Einfügen beschränkt, nicht durch die Speicherbandbreite. Dann hast du nichts von dem superschnellen DRAM-Controller. Und wenn du vorhast, in einer eigenen FPGA-Schaltung schnell mal einen Teil eines DDR4-PC motherboard mit einzudesignen: nein, das halte ich nur für eine theoretisch denkbare, aber nicht für eine realistisch durchführbare Option. Bei der Gegenüberstellung der Bandbreiten sollte dir außerdem bewusst sein, dass das theoretische Obergrenzen sind, denen du dich nur unter bestimmten Bedingungen annähern kannst. Wenn du große, linear zusammenhängende Speicherblöcke schreibst, dann kommst du halbwegs in Richtung des theoretischen Limits. Wenn du einzelne Bytes an zufällig verteilte Adressen schreiben musst, dann geht die Bandbreite um 1-2 Größenordnungen nach unten. Auch da wird der PC-DDR Controller wieder besser performen, weil er viel Aufwand in eine geschickte Cache-Strategie (und einen großen Cache-Speicher) steckt, die man in einem FPGA-Design nicht so ohne weiteres nachbauen kann.
Dagobert schrieb: > Dabei habe ich feststellen müssen, dass FPGAs offenbar(?) nicht an die > Bandbreite von PC Controllern herankommen, weil sie kein DDR4 können, > einen geringeren Speichertakt verwenden und zudem auch nur mit 8 Bit je > DDR-RAM arbeiten, statt mit 64. Ist das richtig? Das ist in dieser allgemeinen Darstellung falsch. Die Xilinx Kintex/Virtex UltraScale(+) sind durchaus für den Betrieb mit DDR3/DDR4 ausgelegt: http://www.xilinx.com/support/documentation-navigation/design-hubs/dh0061-ultrascale-memory-interface-ddr4-ddr3-hub.html Die Zynq UltraScale+ können DDR4 mit 2667Mbps betreiben, und zwar auch an der PL.
Dagobert schrieb: > Autor: > > Dagobert (Gast) Dagobert Duck? Ich hoffe Dein Geldspeicher ist groß genug ;-) Dann wird auch DDR4 gehen (mit Xilinx Ultrascale)
Andreas S. schrieb: > Das ist in dieser allgemeinen Darstellung falsch. Die Xilinx > Kintex/Virtex UltraScale(+) sind durchaus für den Betrieb mit DDR3/DDR4 > ausgelegt: Es gibt auch umfängliche PCB-Guidelines für DDR4 und FPGA: http://www.xilinx.com/support/documentation/user_guides/ug583-ultrascale-pcb-design.pdf#page=29 Maximale Bandbreite 2400 Mbps http://www.xilinx.com/products/design_resources/mem_corner/ddr4.htm
Ok soweit, dann fassen wir mal zusammen: Es gibt FPGAs, die können DDR3 auch mit mehr, als 8Bit Anbindung. Da komme ich also höher. Beim Spartan hatte ich jetzt so gerechnet, 8Bit x 4 RAM-Controller parallel. Gfs wird es auch ein anderer FPGA, mal sehen. Dann gibt es auch DDR4-fähige FPGAs. Das sehe ich mir an. Eines aber noch: Achim S. schrieb: > Einen PC-DDR4 Controller findest du in in der CPU eines jeden DDR4-PC. Ja, schon, aber nur ausgangsseitig. Ich will ihn eingangsseitig, auf der 233MHz-Seite drankriegen. Achim S. schrieb: > Wenn du "vorher langsam Daten einfügst" und das dann auf einen schnellen > Speichercontroller gibst, ist die Bandbreite durch das langsame Einfügen Eignentlich nicht. Gedacht ist es so, dass die Daten, die momentan über den COntroller laufen zu den FPGA-Daten hinzu kommen. Daher braucht es in beiden Fällen eine summarisch hohe Bandbreite zum RAM. Die Frage ist, wie man einen solchen DDR3/4-Controller hinbekommt. Am Liebsten wäre es mir, man kauft den Chip und setzt den FPGA zwischen DSP und Controller. (Dann braucht der DSP keinen Controller mehr und geht wie ein Memory in FPGA-Blockram).
Dagobert schrieb: > Die Frage ist, wie man einen solchen DDR3/4-Controller hinbekommt. Tja, das frage ich mich auch... > Dann braucht der DSP keinen Controller mehr und geht wie ein Memory in > FPGA-Blockram An welcher Stelle fällt denn dann diese hohe Datenrate an? Mit welcher Busbreite willst du "den DSP" anbinden? > Am Liebsten wäre es mir, man kauft den Chip und setzt den FPGA zwischen > DSP und Controller. Sieh dir mal an, wie die Northbride derzeit im PC angebunden ist: der RAM-Controller ist Teil der CPU, weil nur lokal auf dem Chip die nötigen Taktraten gehandhabt werden können. Du kannst diesen hochperformanten Speichercontroller also gar nicht als Einzelchip kaufen (siehe https://de.wikipedia.org/wiki/Northbridge). Und falls doch, dann hätte er nur einen Bruchteil der Performance...
Lothar M. schrieb: > Du kannst diesen hochperformanten Speichercontroller also gar nicht > als Einzelchip kaufen Genau das war der Punkt und der Grund der Diskussion. Was könnte man denn an DDR-3 Controllern praktisch kaufen? Habe sowas noch nie gemacht. Bisher immer noch Prozzis angeschlossen, anschliessen lassen.
Dagobert schrieb: > Was könnte man denn an DDR-3 Controllern praktisch kaufen? Üblich wäre ein FPGA mit Speichercontroller. Ansonsten kannst du noch einen "historischen" Controller aus der Zeit bekommen, in der der Speicher nicht direkt an der CPU hing. http://ark.intel.com/de/products/35133 http://www.intel.com/content/www/us/en/processors/xeon/4-chipset-family-datasheet.html Dann musst du statt des Speicherbusses im FPGA "nur" den Front Side Bus implementieren um den Controller ansteuern zu können (was aber leider aufwändiger ist als den Speicher direkt anzusteuern). Dagobert schrieb: > Am > Liebsten wäre es mir, man kauft den Chip und setzt den FPGA zwischen DSP > und Controller. Vielleicht beschreibst du mal, was du eigentlich bauen willst. Dann kannst du vielleicht auch hilfreiche Tips bekommen.
Schreib vor allem mal welche Datenrate Du tatsächlich BRAUCHST. Und zwar auch was von aussen ins FPGA rein und wieder raus gehen soll (zum DSP bzw. von der Datenquelle...). Und wie ich schon sagte - das Budget ist auch nicht ganz unwichtig bei sowas ;-)
Es wird ungefähr so laufen, dass in einen Datenstrom, der bisher mit einem DSP gesteuert wird und der einen PC-3200 zu 60% peek auslastet, nochmal 50% Daten hinzukommen. Wären also 90%. Durch Puffern kann man das auf 80% senken. Bleibt noch einen schnelleren Speicher zu nehmen.
Dagobert schrieb: > Es wird ungefähr so laufen, dass in einen Datenstrom, der bisher mit > einem DSP gesteuert wird und der einen PC-3200 zu 60% peek auslastet, > nochmal 50% Daten hinzukommen. Ich lese in deinen Beiträgen immer irgendwelche Bandbreitenangaben, aber ich hab immer noch keinerlei Bild, wie dein System konkret aussieht und in Zukunft aussehen soll. Du hast derzeit einen DSP, der selbst das DRAM-Interface bedient (mit 3,2GByte/s)? Oder was bedeutet die Aussage, dass der Datenstrom vom DSP gesteuert wird. Und du willst "etwas dazwischen schalten", um eine höhere Bandbreite ins DRAM zu bekommen? Über welches Interface soll dein geheimer DSP in Zukunft mit mehr als 3,2GByte/s mit dem Speichercontroller Daten austauschen? Ist wirklich die Bandbreite das Bottleneck? In einem anderen Thread schreibst du etwas von "wahlfreiem Zugriff". Wie groß sind die zusammenhängenden Datenblöcke, die du ins DRAM transferierst? Wie viel Speicher brauchst du insgesamt?
Achim S. schrieb: > Ich lese in deinen Beiträgen immer irgendwelche Bandbreitenangaben, aber > ich hab immer noch keinerlei Bild, wie dein System konkret aussieht und > in Zukunft aussehen soll. Du hast derzeit einen DSP, der selbst das Das ist das Problem heute fast überall. Es wird kompliziert gedacht, irgendwelche Sachen werden durcheinander gebracht, jetzt kommt noch 10-100G Eth dazu, HMC-Controller, vielleicht noch ADAT-Schnittstelle... Anstatt ein Blockschaltbild zu zeichnen: erstens wird ihm selber einiges klar und zweitens, wir können besser helfen. Ich kenne es von mir: man möchte zeigen, dass man sich Gedanken dazu gemacht hat, doch das ist oft eine Sackgasse, falls man sich von vornehereit auf dem Holzweg befand. Nichts für Ungut Kest
Leute, ich will doch nur die Bandbreiten nach unten abschätzen, um auf der sicheren Seite zu liegen, um einen Vorschlag für ein Designkonzept abgeben zu können.
Dagobert schrieb: > ich will doch nur die Bandbreiten nach unten abschätzen Das ist trotzdem schwierig, bei Deinen Angaben. Mir (vielleicht auch Dir?) ist nicht ganz klar, an welcher Stelle das FPGA jetzt dem DSP helfen soll. Im Xilinx-Forum habe ich einen Betrag gefunden, der Dir evtl. weiterhilft: https://forums.xilinx.com/t5/Spartan-Family-FPGAs/DDR3-memory-bandwidth/m-p/43360#M3412 Zitat:
1 | To answer your hypothetical question about maximum bandwidth, consider the following: |
2 | 1) You have a chip with 4 MCBs working in x16 800Mbps mode |
3 | 2) You write to contiguous blocks of memory, no random access whatsoever |
4 | 3) You only write to memory |
5 | |
6 | Then the best case memory bandwidth(upper bound) will be |
7 | 4 x 16 x 800 = 51200 Mbps = 6400 Megabytes per second. |
Duke
Schau dir mal das an: http://www.em.avnet.com/en-us/design/trainingandevents/Documents/X-Tech%202013%20Presentations/General%20Track/04_xtech_memory_2013_03_06.pdf Interessant wirds ab Seite 10.
Also echt. Der RAM am FPGA und im PC ist im Grunde der Selbe. Willst du extrem viel RAM brauchst du einen ectrem grossen FPGA. Natuerlich kannst du den RAM Controller eines PCs einplanen, dann musst du aber auch den Rest des PCs einplanen und den FPGA zB per PCIe anbinden. Die Datenraten des RAMs schwanken um Faktor 100, wenn ein PC mit dran haengt vermutlich mehr. Zugriffszeiten schwanken zwischen "praktisch keine" und "ist mein System abgestuerzt?". Du brauchst einen internen Buffer auf jeden Fall. Ohne genauere Aussage was das System TUN soll kann man dir nicht weiter helfen. Ach uebrigens, du wirst es weder schaffen einen RAM Controller noch einen PCIe Controller zu konfigurieren, noch wirst du das PCB dazu erstellen koennen. Dafuer braucht man naemlich VERDAMMT viel Wissen und Erfahrung....
Dagobert schrieb: > Leute, ich will doch nur die Bandbreiten nach unten abschätzen Nach oben Abschätzen ist einfach (Frequenz mal 2 mal Interfacebreite in Byte mal Anzahl der MCB). Um nach unten abzuschätzen braucht man eine ungefähre Idee, wie die Speicherzugriffe aussehen. Dass da typisch 2 Größenordnungen an Spielraum sind wurde schon zweimal beschrieben (und das verlinkte Dokumten von supachris beschreibt ebenfalls dasselbe). Auch zur Machbarkeit der Idee, einen PC DDR3-Controller selbst einzusetzen und anzusteuern, wurde dir schon mehrfach Feedback gegeben (theoretisch denkbar, aber für dich realistisch ist es nicht). Genauere Aussagen als diese kann man beim bisherigen Detailgrad deiner Beschreibung leider nicht geben. Ein Beispiel: wenn du sehr feingranulare wahlfreie Zugriffe aufs DRAM machst (Byte, Word oder DWord), dann nützt dir die rechnerische Bandbreitenerhöhung durch ein breiteres Interface gar nichts: für solche Zugriffe ist ein 8Bit-Interface exakt gleich schnell wie ein 64Bit-Interface, obwohl das rechnerisch die 8fache Bandbreite haben sollte.
Guest schrieb: > Ach uebrigens, du wirst es weder schaffen einen RAM Controller noch > einen PCIe Controller zu konfigurieren, noch wirst du das PCB dazu > erstellen koennen. Dafuer braucht man naemlich VERDAMMT viel Wissen und > Erfahrung.... Umgekehrt gibt das einige, die das können und sich dessen gar nicht bewusst sind, was das auf dem Markt wert ist - ihnen wird von Selbstinszenierern vorgeflötet dass das heute schon jeder zweite Elektrotechnik-Absolvent hinbekommt und er sich deshalb schnell auf DDR4, DDR5 und DDR6 stürzen soll, um weiter wettbewerbsfähig zu bleiben. Die Selbstinszenierer kennen von der ganzen Technik natürlich nur ein paar Buzzwords... Aber das ist hier OT ;-)
Christian R. schrieb: > Schau dir mal das an: > http://www.em.avnet.com/en-us/design/trainingandevents/Documents/X-Tech%202013%20Presentations/General%20Track/04_xtech_memory_2013_03_06.pdf > Interessant wirds ab Seite 10. Auf Seite 25: Beispiel 16 Kanal Full HD video brauchz 80 Gbps Calculate DDR3 SODIMM performance potential >Worst case is ~1.1 Gbps (totally random) >Best case is ~92 Gbps (totally sequential)
Eigentlich sind das doch zwei unterschiedliche Fragestellungen: 1) Wie gross ist der Unterschied zwischen Random und Streaming? 2) Wie gross ist der Vorteil eines PC-DDR Controllers?
Markus W. schrieb: > 1) Wie gross ist der Unterschied zwischen Random und Streaming? Gigantisch. Wird bestimmt durch tRC, d.h. wie schnell ACTIVATE Commnads aufeinanderfolgen können. bei DDR3 ist laut Micron Datasheets tRC im Bereich 46-52 ns. DDR4 ist nur unwesentlich schneller, 44 ns. Bei Randomzugriffe auf Bytes sind, das mickrige 20 MByte/s. Auf Pixels a 32 Bit sind es 80 MByte/s. Eine breitere Anbindung als 8 Bit lohnt dabei auch erst wenn man mehr als 8 Bytes pro Zugriff übeträgt. (BurstLength = 8) Im Memorycontroller kann man durch Reordering noch etwas herrausholen, insbesondere wenn man mehrere Ports hat, deren Zugriffe unabhängig voneinander erfolgen. > > 2) Wie gross ist der Vorteil eines PC-DDR Controllers? Das kann direkt den Datenblättern entnehmen.
Dagobert schrieb: > Ist die Rechnung zumindest richtig? Nicht ganz, weil der FPGA mehrere Controller parallel fahren kann. Im gelieferten Beispiel z.B. 4, wobei die Bandbreite wieder an die eines RAM-Kanals im PC heranreicht. Anders, als beim PC, kann er aber die jeweiligen Controller-Ports auch jeweils optimal beschicken und gfs parallel lesen, was die CPU so nicht kann. Von daher sind die Vergleiche stark anwendungsabhängig.
Bevor man das RAM auswählt, sollte man genau wissen wie das Zugriffsmuster aussieht oder aussehen kann, und ob das Design kurzzeitig mit verminderter Speicherbandbreite (aufgrund ungünstiger Zugriffsmuster) leben kann. Bei einer CPU z.B. sinkt, je nach Applikation, die Performance etwas, wenn der Speicher langsamer ist. Im Allgemeinen weniger tragisch. Wenn das Design aber eine maximale Latenz vorschreibt, muss man womöglich RLDRAM oder QDR II oder QDR IV SRAM wählen. Was ich sagen will: Die Speicherwahl hängt deutlich von den Anforderungen ab und hat letztlich auch einen deutlichen Einfluss auf die Architektur, weil DRAM mitunter deutliche Einschränkungen in punkto Zugriffsmuster mit sich bringt. Habe selbst mit SDRAM, DDR1,2,3, RLDRAM2, und QDRII gearbeitet, mitunter auch Speichercontroller gebaut.
Lattice User schrieb: > Bei Randomzugriffe auf Bytes sind, das mickrige 20 MByte/s. > Auf Pixels a 32 Bit sind es 80 MByte/s. Die Werte sind irgendwie komisch. Das sind Extreme, wenn man ständig umschaltet und fast nichts anfragt. Nur dann ist die Latzenz entscheidend. Die erzielbare Bandbreite ist schon um einiges höher: Eine aktuelles DDR4-RAM mit Multi-Channeling kann bei den derzeit verfügbaren Modulen theoretisch weit über 400Gbps an Spitzenbandbreite liefern. Infolge der Verwaltung und der Fehlerkorrektur, sowie der Latenzen beim Umschalten bekommt man da aber selbst im streaming mode nicht mehr als 20 GByte/s hin, weil es so schnell keiner liefern oder abholen kann. Mit einem DDR3-Controller an einem FPGA wie dem Spartan 6 schafft man dagegen so rund ein Zehntel, die allerdings sehr leicht abgeholt werden können. Mehr noch: Schaut man sich jetzt an, dass eine CPU noch mehr zu tun hat, oft mehrfach greifen und ablegen muss, während man im FPGA Werte halten kann, sieht das sehr schnell noch anders aus. Besonders bei paralleler Bildverarbeitung löst sich die Bandbreite der Berechungsarchitaktur schnell vom Limit des Speichercontrollers ab, will sagen, es wird im FPGA weniger Speicherlast erzeugt.
:
Bearbeitet durch User
Jürgen S. schrieb: >> Bei Randomzugriffe auf Bytes sind, das mickrige 20 MByte/s. >> Auf Pixels a 32 Bit sind es 80 MByte/s. > Die Werte sind irgendwie komisch. Nicht unbedingt, wenn man z.B. GPU-Controller im Line-Modus betrachtet: Alle Linien "schräg nach Unten" haben idR eine schlechte Performance, es werden ja je Zeile (d.h. hintereinander) nur wenige bis ein Pixel gezeichnet.
https://de.wikipedia.org/wiki/U61000#/media/File:Bundesarchiv_Bild_183-1988-0912-400,_Berlin,_%C3%9Cbergabe_der_1-Megabit-Speicherschaltkreise.jpg Hatten wir da schon FPGAs in der DDR? :) StromTuner
Axel R. schrieb: > Hatten wir da schon FPGAs in der DDR? :) > > StromTuner Hast Du irgendein Problem? Scheint eine Manie mancher Personen zu sein, sich über die DDR lustig zu machen. Ist aber nicht lustig und die Assoziation mit einem RAM-Controller ist so alt, dass es stinkt!
Meine Güte - ist ja gut.
Ja, und n Bart hat der auch. Ich weiß, man man.
>Ist aber nicht lustig
Wohol!!
Sigi schrieb: > Nicht unbedingt, wenn man z.B. GPU-Controller im Line-Modus betrachtet: > Alle Linien "schräg nach Unten" haben idR eine schlechte Performance, > es werden ja je Zeile (d.h. hintereinander) nur wenige bis ein Pixel > gezeichnet. Alles eine Frage der Pixelanordnung. Wenn man brutal Zeilenorientiert speichert, gibt es halt Probleme mit dem Einlesen von Spalten. Bei performance video apps wird aus dem Grund auch ein anderes Speichermodell verwendet. In FPGAs ist sehr viel möglich. Keine Ahnung, was GPUs diesbezüglich an Alternativen anbieten. Ich nehme an, deren Puffer sind fest organisiert, weil es irgendeine Einheit gibt, die linear ausliest, um das Bild zu generieren. Bei dem Grafikspeicher der GPUs ist auch noch zu erwähnen, daß es sich bei den GDDRx-Technologien meist umd DDR2/DDR3 Speicher handelt. Die verwendeten Zahlen sind da oft irreführend.
Weltbester FPGA-Pongo schrieb im Beitrag #4691014: > Bei dem Grafikspeicher > der GPUs ist auch noch zu erwähnen, daß es sich bei den > GDDRx-Technologien meist umd DDR2/DDR3 Speicher handelt. Die verwendeten > Zahlen sind da oft irreführend. Nicht ganz - vom Aufbau und Prinzip her zwar ähnlich, aber für die typischen Zugriffsmuster der GPU zugeschnitten. Andere Spannungen, andere Packages (32 Bit/Package), sind immer fest verlötet - daher andere Treiberstrukturen und takten wesentlich höher, höhere Latenzen als normaler DDRx Speicher. Also Bandbreite super, aber auch vergleichsweise hohe Zugriffszeiten.
Interessant wäre diesbezüglich ein reales Beispiel: Wie lange dauert, es ein komplettes Bild Pixelweise aus dem CPU-DDR-Speicher zu holen und ihn z.B. in der CPU zu invertieren und wieder abzlegen ... ... und wie lange, es in der Grafikkarte zu machen, ... .. bzw ein Bild aus der Grafikkarte zu holen und wieder dahin zu schieben?
Weltbester FPGA-Pongo schrieb im Beitrag #4691014: > Alles eine Frage der Pixelanordnung. Wenn man brutal Zeilenorientiert > speichert, gibt es halt Probleme mit dem Einlesen von Spalten. Bei > performance video apps wird aus dem Grund auch ein anderes > Speichermodell verwendet. In FPGAs ist sehr viel möglich. > > Keine Ahnung, was GPUs diesbezüglich an Alternativen anbieten. Ich bin halt nur von meiner "bescheidenen" Implementierung ausgegangen, da muss noch eine CPU auf die Pixel zugreifen. Mit einem "besseren" Zuschnitt wird nicht sicherlich sondern auf jeden Fall schneller. Es gibt ja z.B. auch GPUs, die Tile-basiert auf die Bitmap zugreifen. Und da wäre es ja Unsinn, die dann zeilenweise zu organisieren. Für eine Implementierung per HDL/FPGA wär das ein Klacks, nur ein wenig Addressgefummel, per Burst wird dann eine komplette Tile eingelesen bzw. geschrieben. Wie's aber eine moderne GPU macht möchte ich aber mal gerne wissen..
Weltbester FPGA-Pongo schrieb im Beitrag #4691129: > Interessant wäre diesbezüglich ein reales Beispiel: > > Wie lange dauert, es ein komplettes Bild Pixelweise aus dem > CPU-DDR-Speicher zu holen und ihn z.B. in der CPU zu invertieren und > wieder abzlegen ... > > ... und wie lange, es in der Grafikkarte zu machen, ... > > .. bzw ein Bild aus der Grafikkarte zu holen und wieder dahin zu > schieben? Per GPU: extrem schnell. Z.B. kannst Du per Direct3D aus einer Texture lesen und in eine andere schreiben. Mittels Framecounter und eine wenig Rechnerei kommt man so auf extrem gute Speicherauslastung (hab's oft genug für Simulationen gemacht). Aber genau dafür sind ja GPUs optimiert. Per CPU: Die Bitmap muss zunächst über den PCIe-Bus in den Hauptspeicher übertragen werden (CPU-Zugriff auf GPU-Speicher ist langsam), dort bearbeitet und dann wieder in den GPU-Speicher geschrieben werden. D.h. mehrere Schreibzugriffe und damit extrem lahm. Bei dieser Übertragung ist das Image im Hauptspeicher zeilenweise aufgebaut, über den GPU-internen Aufbau erfährt man nichts.
Die Tabelle des TE enthält meines Erachtens zwei Fehler: Zum Einen wird einmal für mehrere RAMs gerechnet und ausgerechnet beim PC nur mit einem gearbeitet. Die sind aber parallel ansprechbar, soweit mir bekannt. Dann wird in allen Fällen mit 8 Bit Breite gerechnet. Das ist aber nicht für alle Technologien richtig.
Oben DDR3 mit 64 geht nur mit Modul und nicht mit einem Chip! Frage dazu: Stimmt diese Tabelle? Beitrag "Controller-IF zu DDR4 mit AXI langsam"
Die Rückmeldung war ganz konkret zu diesem thread. Wenn es einer liest und das nicht korrigiert wird, denkt er falsch.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.