Archiv verlassen und diese Seite im Standarddesign anzeigen : Wann kommen Grafikkarten mit 512Bit Speicherinterface?
GUNDAM
2004-10-29, 20:58:20
Ist schon bekannt wann es Grafikkarten mit 512Bit Speicherinterface geben wird? Da es 256Bit ja schon ziemlich lange gibt, währe es doch langsam mal Zeit wieder das Speicherinterface ein wenig zu beschleunigen und den Datendurchsatz zu erhöhen. Und würde sich eine solche Bandbreite heutzutage überhaupt lohnen, oder würde ein solches Interface nicht ausgelastet werden?
Das Problem sind die immensen Boardkosten, die dadurch entstehen, selbst bei 256 bit wollte nVidia damals ja nicht so recht mitziehen (5800).
Vorerst gibt es ja noch Taktreserven bei GDDR3 und Verbesserungen bei der Kompression/Speicherinterface. Die Hersteller werden so lange auf dieser Schiene fahren wie möglich.
Funky Bob
2004-10-30, 00:26:58
Das Problem sind die immensen Boardkosten, die dadurch entstehen, selbst bei 256 bit wollte nVidia damals ja nicht so recht mitziehen (5800).
Vorerst gibt es ja noch Taktreserven bei GDDR3 und Verbesserungen bei der Kompression/Speicherinterface. Die Hersteller werden so lange auf dieser Schiene fahren wie möglich.
Und das ist auch gut so...
Stellt euch mal nen perfekt optimiertes (dank der Vorarbeit bei 256Bit breiten Speicherinterface) 512Bit breites Speicherinterface vor *lechz*
Ailuros
2004-10-30, 02:12:10
Und das ist auch gut so...
Stellt euch mal nen perfekt optimiertes (dank der Vorarbeit bei 256Bit breiten Speicherinterface) 512Bit breites Speicherinterface vor *lechz*
Ich sehe momentan nur bekloppt schlechte Lese-Effizienz und ergo mehr Bandbreiten-Verschwendung.
Es wird noch einige Zeit dauern bis wir 512bit Busbreite sehen werden und es gibt noch einiges das IHVs an Effizienz in der Zwischenzeit ausschoepfen koennen.
Ich sehe momentan nur bekloppt schlechte Lese-Effizienz und ergo mehr Bandbreiten-Verschwendung.
Du kannst ja 8-fach statt 4-fach unterteilen :rolleyes:
tdexwjgb
2004-10-30, 11:57:41
Hatte nicht die Matrox Parhelia512 ein 512bit-Speicherinterface?
Daher auch der Name !?
Oder war das irgendein anderes Interface?
Wenns so ist, dann wirds wohl der Grund gewesen sein, warum sie so teuer war für die Leistung, die sie geleifert hat.
Hatte nicht die Matrox Parhelia512 ein 512bit-Speicherinterface?
Daher auch der Name !?
Oder war das irgendein anderes Interface?
Wenns so ist, dann wirds wohl der Grund gewesen sein, warum sie so teuer war für die Leistung, die sie geleifert hat.
parhelia war meines wissens die erste gpu mit 256-Bit Speicherinterface, intern konnte der Chip mit 512 Bit arbeiten.
Das Speicherinterface der Parhelia ist aber so ineffektiv, dass herkömliche (unterteilte) 128-Bit Interfaces schneller arbeiteten.
MechWOLLIer
2004-10-30, 13:49:12
Ich glaube, dass es noch ein paar Jahre dauern wird, bis wir ein 512Bit breites Speicherinterface sehen werden.
Dagegen halte ich ein 384Bit Speicherinterface für bald realisierbar und imo wird der Zwischenschritt auch kommen. So kann man diue Taktraten etwas niedriger halten und das interface wird nicht direkt doppelt so komplex.
AnarchX
2004-10-30, 14:18:33
eine matrox g400 hatte doch schon 256bit.
Die 1Gb Karten sollten das schon mitbringen um es mit der Unreal-Engine 4 aufzunehmen oder die 3er mit AA spielbar zu machen :biggrin:
MechWOLLIer
2004-10-30, 14:30:57
eine matrox g400 hatte doch schon 256bit.
Wie kommst du dadrauf? Imo hatte die G400 ein 128Bit breites Speicherinterface.
Leonidas
2004-10-30, 14:35:55
eine matrox g400 hatte doch schon 256bit.
Nein, sie hatte ein 128 Bit Interface für eingehende Daten und ein 128 Bit Interface für ausgehende Daten. Heute wird aber niemand mehr so etwas als 256 Bit bezeichnen, einfach weil Du in keine Situation dazu kommst, die volle Bandbreite auch nur annähernd auszunutzen. Es ist wohl allerhöchstens ein 128+ Interface.
Spasstiger
2004-10-30, 15:51:56
Für R500/NV50 halte ich ein 512 Bit Interface für denkbar. Durch die Vergrößerung des Speicherbuses kann man ja auch die Taktraten senken und trotzdem bessere Performance erreichen. Interessant ist dies insofern, als dass man so die Bildung von Hotspots beim Grafikspeicher verhindern kann. Bereits jetzt werden ja schon viele Karten serienmäßig mit Speicherkühler ausgeliefert. Bei der R500/NV50 Generation könnte sich dieses Problem noch mehr verschärfen, wenn man beim 256 Bit Interface bleibt.
Ich halte es also nicht für unwahrscheinlich, dass Mitte bis Ende 2005 High-End-Karten ein 512 Bit Speicherinterface besitzen (mit aktuell gängigen Speichertaktungen).
Asmodeus
2004-10-30, 16:34:46
Auch wenn es nicht in den Bereich Mainstreamgrafikkarte fällt, aber so viel ich weiß hat eine Wildcat Realizm 800 bereits ein 512 Bit breites Speicherinterface und verwendet GDDR3 Speicher.
Gruss, Carsten.
Auch wenn es nicht in den Bereich Mainstreamgrafikkarte fällt, aber so viel ich weiß hat eine Wildcat Realizm 800 bereits ein 512 Bit breites Speicherinterface und verwendet GDDR3 Speicher.Das sind afaik 2 256-Bit-Interfaces.
Das sind afaik 2 256-Bit-Interfaces.
Plus eins mit 128 Bit. Die Karte hat ja auch 640MiB RAM.
parhelia war meines wissens die erste gpu mit 256-Bit Speicherinterface, intern konnte der Chip mit 512 Bit arbeiten.
Das Speicherinterface der Parhelia ist aber so ineffektiv, dass herkömliche (unterteilte) 128-Bit Interfaces schneller arbeiteten.
Stimmt so nicht, es ist war zwar nicht annähernd so effizient wie ein mehrfach splitted interface marke Radeon 9700, aber schneller als daß herkömmliche 128 bit Interface einer Gf4 beispielsweise... und die Parhelia 8x hat auch nen neuen Speichercontroller bekommen, der effizienter arbeitet.
eine matrox g400 hatte doch schon 256bit.
Die 1Gb Karten sollten das schon mitbringen um es mit der Unreal-Engine 4 aufzunehmen oder die 3er mit AA spielbar zu machen :biggrin:Wie schon erwähnt wurde: nein. Dafür hatte aber zb. Neomagic mit der MagicMedia Reihe 1998 in ihren Grafikchips schon ein 256 bit breites Speicherinterface.
-f
Ein Speicherinterace mit 512 Bit wird auch höllisch zum Layouten. (Und wird mehr lagen Brauchen.) Beides macht einen Print einiges teurer. Ich denke damit werden die Hersteller noch möglichst lange warten. Momentan gibt es jedenfals günstigere Möglichkeiten um mehr herauszuholen.
wieviel euro sind eigentlich "einiges teurer" ??
mapel110
2004-10-31, 18:01:28
lässt sich wohl nicht genau beziffern.
Aber wohl zu teuer um den Nutzen zu rechtfertigen, vorallem im Vergleich zu einem effizienterem 256bit interface, dessen Verbesserungen dann auch einem späteren 512bit interface zugutekommen würden.
Ailuros
2004-11-01, 04:51:30
Du kannst ja 8-fach statt 4-fach unterteilen :rolleyes:
Nette "Loesung" :| . Mal sehen ob HW-Designer in der absehbaren Zukunft die gleiche Meinung haben werden.
robbitop
2004-11-01, 10:42:33
ein 8 fach unterteiler SC würde die PCB Kosten sehr stark erhöhen. Der Verschnitt bei 4x64bit ist nicht groß genug, um das zu rechtfertigen. Hier spielt eben das Gesetz des sinkenden Grenzertrages mit hinein.
zum G400
2x128bit beim G400 sollten zumindist für den Z Traffic etwas bringen. Denn hier wird gelesen UND geschrieben. Und der G400 hatte noch keine Z-Compression insofern konnte das schon recht hilfreich sein.
@AiL
kannst du das mit der schlechten Leseeffizienz etwas näher ausführen? :)
für ein 512bit Interface wäre die interne Chipverdratung auch deutlich komplexer. Aber irgendwann wird sowas kommen müssen.
Ich kann mir auch irgendwann eDRAM für den Z+ StencilBuffer vorstellen.
Wenn der Z Traffic über das Speicherinterface entfällt, bringt das schonmal etwas.
nur so am rande:
ne voodoo2 hat 3* 64bit -> 192bit
ne voodoo2 sli hat 6* 64bit -> 384bit ;)
robbitop
2004-11-01, 13:44:21
nur so am rande:
ne voodoo2 hat 3* 64bit -> 192bit
ne voodoo2 sli hat 6* 64bit -> 384bit ;)
die bandbreite skalliert bei SLI von 3dfx nicht.
die bandbreite skalliert bei SLI von 3dfx nicht.
Natürlich tut sie das. Nur müssen beim V2-SLI einige Texturdaten doppelt gelesen werden.
Aber das ist natürlich auch kein DDR-Interface.
Nette "Loesung" . Mal sehen ob HW-Designer in der absehbaren Zukunft die gleiche Meinung haben werden.
Ich sehe da kein Problem. Was findest du daran so schlecht?
Ailuros
2004-11-02, 00:08:36
Ich sehe da kein Problem. Was findest du daran so schlecht?
=/>WGF timeframe und nicht frueher.
Das Thema wurde schon etliche Male besprochen und nicht nur hier und so wie es aussieht wird kein IHV in absehbarer Zukunft auf einen 512bit bus springen.
GP Dokument 1999:
The Memory Bottleneck
There are two ways to build memory subsystems with higher throughput. The first is to increase the clock rate. The
problem with this is that signal integrity issues quickly become a problem. Packaging costs rise exponentially.
Sometimes this is done via a more complex protocol (such as Rambus), which normally has high throughput, but
also higher latencies—problematic for classical graphics architectures. The second method is to build a wider
interface. This also causes packaging, board and system costs to rise dramatically as you go from 256 bits to 512 bits
to 1024 bits, etc. Widening the memory interface leads to inefficiencies for small primitives when, for example,
1024 bits must be read and written to update one sample of a tall-thin triangle.
Mit einem burst von 4 und einem 256bit bus hat man die 1024bits schon erreicht, mit einfachem PS2.0 Rauschen als Beispiel. Von dem was ich bis jetzt gelesen habe werden Texturzugriffe zunehmend "zufaelliger" sein, was genauso gegen einen breiteren Bus momentan spricht. Wie dem auch sei bei 512bits haut es gleich auf 2048bits von unnoetigem Quatsch das eine GPU auslesen muss.
Ich bezweifle dass IHVs sich andere Unterteilungen des memory controllers oder andere Tricks noch nicht ausgedacht oder damit experimentiert haben. Nur rechnest Du hier wohl auch nicht mit den Unkosten mit und ueberhaupt wenn es schon so knapp wird mit steigender Komplexitaet.
robbitop
2004-11-02, 10:23:38
Mit einem burst von 4 und einem 256bit bus hat man die 1024bits schon erreicht, mit einfachem PS2.0 Rauschen als Beispiel. Von dem was ich bis jetzt gelesen habe werden Texturzugriffe zunehmend "zufaelliger" sein, was genauso gegen einen breiteren Bus momentan spricht. Wie dem auch sei bei 512bits haut es gleich auf 2048bits von unnoetigem Quatsch das eine GPU auslesen muss.
Ich bezweifle dass IHVs sich andere Unterteilungen des memory controllers oder andere Tricks noch nicht ausgedacht oder damit experimentiert haben. Nur rechnest Du hier wohl auch nicht mit den Unkosten mit und ueberhaupt wenn es schon so knapp wird mit steigender Komplexitaet.
Bei einem 512bit DDR (1024bit) Interface wäre ein 8 fach unterteilter Memorycontroller Pflicht, um die Effizienz nicht zu stark sinken zu lassen.
Zusätzlich kann man einen kleinen Burst Cache vor die Memorycontroller setzen. Das funktioniert zwar nicht für den Z-Traffic aber für Colortraffic geht das. Leider verursacht das etwas Latenz, die man verstecken müsste. Bei aktueller Unterteilung haben wir 128bit/ Controller (64bit DDR).
Somit brauchen wir ein Dreieck von mind 4 Pixeln a 32bit, um 100%ige Effizienz zu gewährleisten. Allerdings kommt noch der Z/Stenci Trafic dazu (24bit lesen und schreiben). Somit sind wir mit einer Unterteilung von 128bit pro Controller eigentlich noch recht effizient.
Allerdings wäre ein 8 fach unterteilter 512bit DDR Bus extrem teuer, aber nicht weniger effizient als ein 4 fach unterteilter 256bit Bus.
Ailuros
2004-11-03, 04:13:34
Bei einem 512bit DDR (1024bit) Interface wäre ein 8 fach unterteilter Memorycontroller Pflicht, um die Effizienz nicht zu stark sinken zu lassen.
Zusätzlich kann man einen kleinen Burst Cache vor die Memorycontroller setzen. Das funktioniert zwar nicht für den Z-Traffic aber für Colortraffic geht das. Leider verursacht das etwas Latenz, die man verstecken müsste. Bei aktueller Unterteilung haben wir 128bit/ Controller (64bit DDR).
Somit brauchen wir ein Dreieck von mind 4 Pixeln a 32bit, um 100%ige Effizienz zu gewährleisten. Allerdings kommt noch der Z/Stenci Trafic dazu (24bit lesen und schreiben). Somit sind wir mit einer Unterteilung von 128bit pro Controller eigentlich noch recht effizient.
Allerdings wäre ein 8 fach unterteilter 512bit DDR Bus extrem teuer, aber nicht weniger effizient als ein 4 fach unterteilter 256bit Bus.
Seit mir bitte vorsichtig mit der wahren Unterteilung heutiger chips intern. Ihr kommt IMHO nur zur Haelfte der Realitaet mit solchen Berechnungen.
Andersrum gefragt: wieso ist die Shader-Leistung der 128bit mainstream Teile besser als viele erwartet haetten? Eben nur weil selbst ein 256bit bus nicht in allen Faellen Vorteile hat. Auf was genau will man sich nun konzentrieren? Auf die Zukunft oder die Vergangenheit mit einer neuen Generation?
robbitop
2004-11-03, 08:58:27
Seit mir bitte vorsichtig mit der wahren Unterteilung heutiger chips intern. Ihr kommt IMHO nur zur Haelfte der Realitaet mit solchen Berechnungen.
Andersrum gefragt: wieso ist die Shader-Leistung der 128bit mainstream Teile besser als viele erwartet haetten? Eben nur weil selbst ein 256bit bus nicht in allen Faellen Vorteile hat. Auf was genau will man sich nun konzentrieren? Auf die Zukunft oder die Vergangenheit mit einer neuen Generation?
zumindist aritmetische Shader sind nicht bandbreitenlimitiert.
Ausserdem gibt es immer eine BurstCacheline vor dem Speicherinterface. Das verringert den Verschnitt.
Das verringert den Verschnitt.Aber nicht, wenn wirklich nur ein einzelnes Pixel modifiziert werden muss.
Ail, bei virtualisiertem Speicher (mit WGF) sollte es möglich sein, generelle Caches zu verwenden, um die Schreib-Lese-Effizienz zu steigern.
robbitop
2004-11-03, 13:49:32
Aber nicht, wenn wirklich nur ein einzelnes Pixel modifiziert werden muss.
Ail, bei virtualisiertem Speicher (mit WGF) sollte es möglich sein, generelle Caches zu verwenden, um die Schreib-Lese-Effizienz zu steigern.
in solchen Fällen würde nur eine Granularitätsverbesserung helfen.
Ob die Kosten den Nutzen in der Praxis rechtfertigen hängt von der Situation ab. Wenn es einen signifikanten Schub bringen würde (also viele einzelne auszulesene Pixel ohne Burst), dann würde man das mittelfristig auch realisieren.
http://www.3dcenter.org/artikel/glaze3d_avalanche/Grob kann man das Glaze3D/Avalanche-Projekt dabei in drei große Zeitphasen unterteilen:
Mai 1998 bis September 1999:
Ur-Glaze3D mit Vertex Shader und RAMBUS-Speicher
Oktober 1999 bis Februar 2001:
moderner Glaze3D mit Vertex Shader und XBA-Speichertechnologie mit 9 MB eDRAM-Speicher an einem 512 Bit Interface
März 2001 bis September 2002:
Avalanche mit Vertex und Pixel Shader nach DirectX 8.1 und XBA-Speichertechnologie mit 12 MB eDRAM-Speicher an einem 1024 Bit Interface
Ailuros
2004-11-04, 02:53:31
Aber nicht, wenn wirklich nur ein einzelnes Pixel modifiziert werden muss.
Ail, bei virtualisiertem Speicher (mit WGF) sollte es möglich sein, generelle Caches zu verwenden, um die Schreib-Lese-Effizienz zu steigern.
Ich sagte ja in einem vorigen Post dass ich 512bit erst =/>WGF erwarte.
Ailuros
2004-11-04, 02:57:35
http://www.3dcenter.org/artikel/glaze3d_avalanche/
Nur fuer eDRAM; schau Dir nochmal genau die externe Busbreite an und dann koennen wir weiterreden.
Hier bitte aus dem selben Artikel:
http://www.3dcenter.org/artikel/glaze3d_avalanche/index7.php
Ich sagte ja in einem vorigen Post dass ich 512bit erst =/>WGF erwarte.Da sind wir also einer Meinung :)
Ailuros
2004-11-04, 13:06:14
Da sind wir also einer Meinung :)
Man koennte der Sache leicht schon Namen geben: NV60/R6xx und eben =/>2006 und das ist selbst noch keine Garantie, da WGF etwa genauso lange halten soll wie dx9.0 (~4 Jahre).
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.