R700 im Q1 2008, multicore und 55 nm?

[Kladderadatsch]

wird ati mit dem r700 besser machen, was sie mit dem r650 hoffentlich wieder gut machen?;)

laut fudzilla (http://www.fudzilla.com/index.php?option=com_content&task=view&id=1028&Itemid=1) wird die gpu in 55nm gefertigt. am interessantesten dürfte aber sein, dass nun auch die gpus mehrere kerne, "multi core unified architecture" getauft, besitzen sollen.


sollte sich das bewahrheiten- wann erwarten uns programme, die das ausnutzen? ich meine, die gpus haben nicht das 'glück' wie die cpus, wenigstens den treiber auf den ungenutzen core verschieben zu können, wenn schon die anwendungen nicht auf multi core ausgelegt sind..

[AnarchX]

GPUs sind doch jetzt schon Multicores!

In der Zukunft trennt man sie eben nur auf einzelne Dies auf um Vorteile bei Yields, Wärmeabgabe und Skalierbarkeit zu haben.

Natürlich stehen dem dann auch einige Herausforderungen gegenüber.

[Hamster]

schon mal was von sli oder crossfire gehört? ;)


(wobei multicore bei einer gpu kein sinn macht, durch ihre pipelines kann sie schon heute massiv parallel berechnen. den einzigen grund den ich mir vorstellen könnte ist, dass es ist fertigungstechnisch einfacher ist 2x700 millionen transistoren zu fertigen als 1x 1.4milliarden).

[PCGH_Carsten]

Dem allgemeinen Trend zu "multi-X" folgend, läßt sich eine Multi-Core-GPU natürlich auch viel besser vermarkten. :)

[Kladderadatsch]

schon mal was von sli oder crossfire gehört? ;)

so wie man vor x2 und core duo auch schon von server-boards mit 2 sockeln gehört hat? jo.


In der Zukunft trennt man sie eben nur auf einzelne Dies
ist es wirklich nicht mehr als 'nur'?..

[Gast]

Vor allem sind sie schön stromsparend, besonders im Idle Modus, wo man dann beispielsweise einen spromsparenden Core laufen lässt.

Wird dann eine 3D Anwendung gestartet, schalten sich die anderen Cores hinzu und man kann die volle Leistung auskosten. :)

[Hamster]

so wie man vor x2 und core duo auch schon von server-boards mit 2 sockeln gehört hat? jo.




was ich damit sagen wollte, bildberechnungen kannst du wunderbar paralellisieren. und zwar immer.
"cpu-code" ist da komplexer, da hier sehr oft hintereinander berechnet werden muß, da viele berechnungen aufeinander aufbauen.

[d2kx]

Ohne Experte zu sein, glaube ich nicht, dass sie schon im Q1 2008 erscheint, eher Q2 und dann evtl. erst in 65nm und evtl. im Refresh als 55nm.

[Simon Moon]

so wie man vor x2 und core duo auch schon von server-boards mit 2 sockeln gehört hat? jo.


Die Intention hinter seiner Aussage war grundlegend anders. SLI und Crossfire sind bereits Multi GPU Systeme.

Nun ist es aber so, dass sich die Bildberechnung wesentlich leichter parallelisieren lässt, als es bei Aufgaben der CPU der Fall ist. Einfach gesagt, kann ich einem Grafikchip die obere Hälfte und dem anderen die untere Hälfte des Bildschirms zuweisen. Oder ich teile es so auf, dass sie abwechselnd Bilder rendern. In beiden Fälle sind die GPUs nicht in einer Abhängigkeit zu einander und können ungestört rechnen.

Bei der CPU laufen die Berechnungen aber meist seriell ab, d.h. es bestehen gewisse Abhängigkeiten zu vorher berechneten Ergebnissen und solange man die nicht hat, kann man nicht weiter rechnen.

[Kladderadatsch]

was ich damit sagen wollte, bildberechnungen kannst du wunderbar paralellisieren. und zwar immer.
"cpu-code" ist da komplexer, da hier sehr oft hintereinander berechnet werden muß, da viele berechnungen aufeinander aufbauen.
achso. danke auch an simon moon für die aufklärung.


anwendungen müssen also lediglich treiber-seitig angepasst werden, um kompatibel zu sein? prima=)

[reunion]

schon mal was von sli oder crossfire gehört? ;)


Das ist nicht wirklich vergleichbar. Bei SLi/CF hat jede GPU weiterhin sein eigenes Package, VRAM, etc. und die beiden berechnen meist abwechselnd ein Bild. Bei einer Multi-Core-GPU müssten faktisch die einzelnen Einheiten einer GPU aufgesplittet werden, und auf dem Package mit mehreren 100GB/s und extrem kurzen Latenzen verbunden werden, sodass sich die Dice wie eine einzelnen GPU verhalten können. Mit den Vorteilen, dass man die Leistung auch noch sehr kurzfristig beliebig skalieren kann (bsw. einfach ein "Shaderdie" dazuhängen), den Stromverbauch wesentlich besser skalieren könnte (der 2D-Core sollte in einem extra Die stecken, wodurch man alles andere in 2D vollständig abschalten kann, und dann in 3D je nach benötigter Leistung nach und nach die anderen Dice aktiviert), und natürlich wesentlich bessere Yields erreicht, da man nicht mehr ein "Mosterdie" fertigen muss, sondern viele kleine.

[_seBIGbos_]

Hätte diese Multicore Architektur nicht massive Vorteile beim Stromsparen?

Wenn zB im 2D Betrieb zwei von vier Cores komplett ausgeschalten werden können, sollte es da doch in Sachen Stromverbrauch kaum besser gehen, oder nicht?

[=Floi=]

dafür müssten in 3D erst mal die mehrern cores unterstützt werden
siehe aktuell CF ;D ...
ich glaube da nicht dran oder es wird ein weiteres desaster

[reunion]

dafür müssten in 3D erst mal die mehrern cores unterstützt werden
siehe aktuell CF ;D ...

Eben nicht. So eine GPU müsste sich genauso verhalten wie ein einzelnes Die, sonst würde es keine Sinn machen.

[Gast]

Ich sehe da keinen Sinn 2x einen R600 parallel zu schalten, das ganze kann ich doch auch in einen Package verwirklichen. Nur müssen die IHVs jetzt endlich in die Gänge kommen und mal richtige Stromsparfunktionen verbauen die nicht komplett am Treiber kleben.

Wenn man einen echten 2D Modus einbauen würde der 3 von 4 "Pipelines" abschaltet, wäre man einen Schritt weiter dazu Spannungsveringerung ähnlich der CPUs.

Aber 2 GPUs mit einander zu verdrahten... vieleicht meint das Marketing auch etwas das dem G80 ähnelt. Da könnte man theoretisch auch davon sprechen das die Unterschiedlichen Taktdomänen MultiCores sind. Ein Modularer aufbau, der keine ausbremsenden Abhänigkeiten hat.
AMD will sicher die Marge erhöhen und das geht nicht wenn die Yields schlecht sind weil ich meine GPUs höher als geplant takten muss.

[Fetza]

Aber ihr glaubt doch nicht ernsthaft ans erste quartal des jahres 2008?:biggrin:

[san.salvador]

Hätte diese Multicore Architektur nicht massive Vorteile beim Stromsparen?

Wenn zB im 2D Betrieb zwei von vier Cores komplett ausgeschalten werden können, sollte es da doch in Sachen Stromverbrauch kaum besser gehen, oder nicht?
Glaub ich nicht.
Werden bei unseren Multicore-CPUs ungebrauchte Cores abgedreht? Nein.
Ich weiß nicht wieso das so ist, aber es scheint doch schwieriger umzusetzen zu sein, als wir uns das vorstellen.

[Hamster]

Das ist nicht wirklich vergleichbar. Bei SLi/CF hat jede GPU weiterhin sein eigenes Package, VRAM, etc. und die beiden berechnen meist abwechselnd ein Bild. Bei einer Multi-Core-GPU müssten faktisch die einzelnen Einheiten einer GPU aufgesplittet werden, und auf dem Package mit mehreren 100GB/s und extrem kurzen Latenzen verbunden werden, sodass sich die Dice wie eine einzelnen GPU verhalten können. Mit den Vorteilen, dass man die Leistung auch noch sehr kurzfristig beliebig skalieren kann (bsw. einfach ein "Shaderdie" dazuhängen), den Stromverbauch wesentlich besser skalieren könnte (der 2D-Core sollte in einem extra Die stecken, wodurch man alles andere in 2D vollständig abschalten kann, und dann in 3D je nach benötigter Leistung nach und nach die anderen Dice aktiviert), und natürlich wesentlich bessere Yields erreicht, da man nicht mehr ein "Mosterdie" fertigen muss, sondern viele kleine.


das habe ich ja nie bestritten, nur interessieren diese details an dieser stelle nicht. es ging dabei um seine anzweiflung, ob "multi-gpu-cores" die leistung auch umsetzen können. sli/cf war hierzu nur ein beispiel um ihn darauf zu bringen, daß es dies heute schon gibt.

das ergibt sich aber ganz klar aus dem gesamtkontext. vielleicht solltest du dir das nochmal in aller gesamtheit durchlesen, und dir nicht nur ein stichwort herauspicken.

[Coda]

Boa wie oft kommt der scheiß mit den Multicores noch...

Werden bei unseren Multicore-CPUs ungebrauchte Cores abgedreht? Nein.
Der AMD Phenom wird das können, hat dafür aber zwei unterschiedliche Stromversorgungen.

[Kladderadatsch]

Boa wie oft kommt der scheiß mit den Multicores noch...

leo konnte es sich in den heutigen news auch nicht verkneifen;)

im ernst: warum 'scheiß'? erkläre es mir bitte:)

[Iwan]

scheiß deshalb weil einige immer noch nicht verstehn wie gpus aufgebaut sind, daraus folgt das die leute dann auch nicht verstehn was "multicore" bei gpus eigentlich bringt.

[deekey777]

Wie oft hatten wir das Thema eigentlich? :biggrin:
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=190680
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=233432
Und natürlich: http://www.forum-3dcenter.org/vbulletin/showthread.php?t=313605

[WEGA]

GPUs sind doch jetzt schon Multicores!

In der Zukunft trennt man sie eben nur auf einzelne Dies auf um Vorteile bei Yields, Wärmeabgabe und Skalierbarkeit zu haben.

Natürlich stehen dem dann auch einige Herausforderungen gegenüber.
nö, zwischen multy-GPU und multy-core ist ein unterschied ;)

[AnarchX]

nö, zwischen multy-GPU und multy-core ist ein unterschied ;)

Wer sagt, dass es sich um Multi-GPUs handeln wird?

Ich könnte mir durchaus vorstellen, dass einen Core gibt der die Verwaltung übernimmt und dann eine andere Core-Art die nur Recheneinheiten enthält.

Könnte man nicht den Ringbus auf solche Cores verteilen?

[Nakai]

Der G80 hat das schon schön dargestellt.

Dadurch kann man Kosten sparen, wenn der Chip in 2 Hälften zerlegt wird.

mfg Nakai

[AnarchX]

Der G80 hat das schon schön dargestellt.

Dadurch kann man Kosten sparen, wenn der Chip in 2 Hälften zerlegt wird.


Hmm? :|

Ich glaube NV wäre es doch lieber gewesen, wenn sie den IO-Part beim G80 hätten integrieren können, was aber wohl wegen der großen Shaderdomain und ihren Auswirkungen nicht funktioniert hat.

Ich bezweifele doch stark, dass man hier durch das zusätzliche Package/Verbindungen im PCB etwas gespart hat.

[reunion]

Ganz im gegenteil, NVIO braucht immerhin 49mm² Die-Fläche, obwohl nur 1/4 Logik ist, der Rest ist blank.

[WEGA]

Wer sagt, dass es sich um Multi-GPUs handeln wird?

Ich könnte mir durchaus vorstellen, dass einen Core gibt der die Verwaltung übernimmt und dann eine andere Core-Art die nur Recheneinheiten enthält.

Könnte man nicht den Ringbus auf solche Cores verteilen?
wer redet von "wird". du schriebst "GPUs sind doch jetzt schon multicores"

[AnarchX]

wer redet von "wird". du schriebst "GPUs sind doch jetzt schon multicores"

:rolleyes:

Wenn du etwas mehr den Kontext beachten würde, dann wäre es offensichtlich dass ich hier von einzelnen Dies rede. ;)

[deekey777]

Werft doch mal einen Blick auf den Xenos: Aktuell besteht dieser aus zwei Kernen (Parent und Daughter). Mit dem Übergang auf 65 nm wird es nur einen Kern geben, da dies günstiger ist.
Warum sollte es beim R700 jetzt anders sein? Zwei Dice auf einem Package kostet eher mehr.

Was aber extrem wichtig ist: Von wem kommt noch die Info, dass der R700 ein Mehr-Kern-Grafikchip sein wird außer Fudo?

[AnarchX]

Was aber extrem wichtig ist: Von wem kommt noch die Info, dass der R700 ein Mehr-Kern-Grafikchip sein wird außer Fudo?

Von AMD/ATi und nein nicht aus den alten Interviews. ;)

[deekey777]

Von AMD/ATi und nein nicht aus den alten Interviews. ;)
Das Fusion-Zeug zählt nicht.

[AnarchX]

Das Fusion-Zeug zählt nicht.

Fusion? Hier geht es doch um den R700?

Was Fuad da schreibt und noch einige andere Dinge werden in einem internen Dokument genannt, auf welches wohl er durch seine Quellen auch Zugriff hat.

[reunion]

Warum sollte es beim R700 jetzt anders sein? Zwei Dice auf einem Package kostet eher mehr.


Genau das Gegenteil ist der Fall. Zwei kleine Dice sind wesentlich billiger als ein großes, und zehn kleine sind erst recht billiger als ein großes. Von den ganzen anderen Vorteilen mal ganz zu schweigen. Die Kunst ist es dann eben, dass dabei die Leistung nicht leidet.

[Coda]

Das kannst du so nicht pauschalisieren. Es gibt auch beim Auflöten auf das Packaging Produktionsfehler. Und zwar auch nicht unerheblich. Bei zwei Dies ist das zwar noch zu verschmerzen, aber mit der Anzahl der Dies multipliziert sich die Fehlerwahrscheinlichkeit.

"Multicore" kann auch einfach übliches Marketing-Geblubber sein, weil das jeder Grafikchip ist.

Werft doch mal einen Blick auf den Xenos: Aktuell besteht dieser aus zwei Kernen (Parent und Daughter). Mit dem Übergang auf 65 nm wird es nur einen Kern geben, da dies günstiger ist.
I don't think so. Dann müsste NEC den ganzen Chip fertigen, weil TSMC kein eDRAM hat.

[Nakai]

Naja 2 kleine gleiche Dies sind billiger, weil man dadurch Ausfälle und schlechte Yields umgehen kann.

mfg Nakai

[AnarchX]

Das kannst du so nicht pauschalisieren. Es gibt auch beim Auflöten auf das Packaging Produktionsfehler. Und zwar auch nicht unerheblich. Bei zwei Dies ist das zwar noch zu verschmerzen, aber mit der Anzahl der Dies multipliziert sich die Fehlerwahrscheinlichkeit.

Aber das Ausmerzen von möglichen Fehlern im Package dürfte doch weniger Kosten als die Respins die bei den immer größer, komplexer werdenden HighEnd-GPUs anfallen?

Zudem würde ja das Risiko bei den kleineren Modellen mit sinkender Die-Zahl ja auch fallen.


"Multicore" kann auch einfach übliches Marketing-Geblubber sein, weil das jeder Grafikchip ist.


Fragt sich nur warum man es so betont.

[Coda]

Aber das Ausmerzen von möglichen Fehlern im Package dürfte doch weniger Kosten als die Respins die bei den immer größer, komplexer werdenden HighEnd-GPUs anfallen?
Das hat doch nix mit der Die-Größe zu tun, wenn ATI teilweise so blöd ist zu vergessen die Output-Pins zu verbinden ;)

Fragt sich nur warum man es so betont.
Weil's "in" ist. Überall.

Ich glaub nicht dran, aber ich bin bei so Sachen ja immer sehr skeptisch...

[deekey777]

I don't think so. Dann müsste NEC den ganzen Chip fertigen, weil TSMC kein eDRAM hat.
http://www.beyond3d.com/content/articles/18/
Hm, dazu kommt, dass das eDRAM in 55 nm und der Rest in 65 nm gefertigt werden.
Dann steigen sie auf ZRAM um. :biggrin:
Genau das Gegenteil ist der Fall. Zwei kleine Dice sind wesentlich billiger als ein großes, und zehn kleine sind erst recht billiger als ein großes. Von den ganzen anderen Vorteilen mal ganz zu schweigen. Die Kunst ist es dann eben, dass dabei die Leistung nicht leidet.
Das Packaging ist das weitere Problem, schließlich braucht dieses auch deutlich mehr Leitungen. Man darf auch nicht vergessen, dass der R700 womöglich ein neues Design haben wird (und nicht mehr das Versager-Design). Dh die Entwicklung begann im Jahr 2005 oder gar 2004, als man an die Umwelt nicht denken musste (Sprich Verbrauch).

[robbitop]

Aus R&D Sicht, macht ein solches Konzept durchaus Sinn. Man braucht fuer alle Produktfamilien nur einen Core zu designen und skaliert dann ueber die Anzahl. Die Umsetzung hingegen ist holpriger. Die Bus-Topologie und -breite, um externe Dice zu verbinden, wird sicher nicht einfach zu realisieren sein.
Wieviel Redundanz wird vorhanden sein? Wie viel teurer wird das Packaging? Ect.pp...

[Coda]

http://www.beyond3d.com/content/articles/18/
Hm, dazu kommt, dass das eDRAM in 55 nm und der Rest in 65 nm gefertigt werden.
Dann steigen sie auf ZRAM um. :biggrin:
Das sind Spekulationen. TSMC hat kein eDRAM. Wie gesagt müsste NEC den ganzen Chip dann fertigen. Kaum eine Option meiner Meinung nach.

[reunion]

Das Packaging ist das weitere Problem, schließlich braucht dieses auch deutlich mehr Leitungen.


Ja, das Package wird komplexer, dem ggü. stehen aber erhebliche Vorteile, von Stromverbauch über Flexibilität, bis hin zu den Kosten sowohl finalziell, als auch in punkto R&D. Im übrigen hat man ja mit Xenos schonmal Erfahrungen in dieser Hinsicht gemacht, die beides Dics sind immerhin auch mit 32GB/s verbunden, bis zu R700 wird man das sicherlich noch deutlich aufbohren können.


Man darf auch nicht vergessen, dass der R700 womöglich ein neues Design haben wird (und nicht mehr das Versager-Design). Dh die Entwicklung begann im Jahr 2005 oder gar 2004, als man an die Umwelt nicht denken musste (Sprich Verbrauch).

Der Verbrauch soll ein ganz wesentlicher Teil bei R700 sein, das hört man durch die Blume immer wieder vin verschiedenen AMD-Leuten. Ich schaue mal, ob ich da noch was finde...

[Coda]

Ja, das Package wird komplexer, dem ggü. stehen aber erhebliche Vorteile, von Stromverbauch über Flexibilität, bis hin zu den Kosten sowohl finalziell, als auch in punkto R&D. Im übrigen hat man ja mit Xenos schonmal Erfahrungen in dieser Hinsicht gemacht, die beides Dics sind immerhin auch mit 32GB/s verbunden, bis zu R700 wird man das sicherlich noch deutlich aufbohren können.
Wieso Stromverbrauch? Und das eDRAM ist was ganz anderes als echtes Multichip. Xenos hat vor allem das eDRAM auf nem seperaten Chip, weil es TSMC eben nicht fertigen kann.

[reunion]

Wieso Stromverbrauch?


Naja, da ich nicht annehme, dass jeder Core einen extra 2D-Kern hat, könnte man diesen mittels eines extra Chips realisieren, was natürlich dem 2D-Stromverbrauch stark zu gute kommen würde.


Und das eDRAM ist was ganz anderes als echtes Multichip. Xenos hat vor allem das eDRAM auf nem seperaten Chip, weil es TSMC eben nicht fertigen kann.

Natürlich, mir ging es ja auch nur um die grundsätzliche Möglichkeit einer schnellen Verbindung zwischen den Kernen, die ROPs sind ja immerhin auch im Parent-Die.


Hier DK777 der versprochene Hinweis:

"Da lief definitiv etwas in die falsche Richtung" urteilte auch ATIs Europa-Chef Peter Edinger im Gespräch mit Golem.de. Folglich will sein Unternehmen in kommenden GPU-Generationen den Stromverbrauch deutlicher im Auge behalten, und dazu auch auf mehrere Kerne in einem Grafikchip setzen. Aber, so Edinger "das ist nichts, was sie gleich in der nächsten Generation sehen werden - aber in der übernächsten."

http://www.golem.de/showhigh2.php?file=/0608/47044.html&wort

Ich denke es ist offensichtlich, dass er sich hier auf R700 bezieht, denn als das Interview durchgeführt wurde, war R600 noch nicht veröffentlicht. Dabei sagt er im übrigen auch klipp und klar, dass ATi an Multicore Grafikchips arbeitet.

[Ailuros]

R700 im Q1 2008, multi core und 55nm?

errrr.........

R700 im Q1 2008, multi chip und 55nm?

Hmmm.....;)

[Coda]

, könnte man diesen mittels eines extra Chips realisieren, was natürlich dem 2D-Stromverbrauch stark zu gute kommen würde.
So wie bei G80? Wo bringt das da viel?

[deekey777]

Unter "2D-Core" würde ich einen einfachen Aero-fähigen Chip samt Videoprozessor usw. Ich tippe mal, dass reunion das gleiche meint.

[reunion]

Unter "2D-Core" würde ich einen einfachen Aero-fähigen Chip samt Videoprozessor usw. Ich tippe mal, dass reunion das gleiche meint.

Genau, die ganzen anderen Kerne könnte man dann am Desktop faktisch komplett deaktivieren, und nur bei bedarf nach und nach zuschalten.

[Coda]

Ich weiß nicht ob das überhaupt geht, da Vista-Treiber vom Interface garantieren, dass man alle D3D-Resourcen (also auch Aero) sharen kann. Aus dem genau gleichen Grund müsste der "einfache" Chip für Aero dann auch das gleiche Featureset wie die anderen Chips haben.

[reunion]

Ich weiß nicht ob das überhaupt geht, da Vista-Treiber vom Interface garantieren, dass man alle D3D-Resourcen (also auch Aero) sharen kann. Aus dem genau gleichen Grund müsste der "einfache" Chip für Aero dann auch das gleiche Featureset wie die anderen Chips haben.

Dann wird eben noch zusätzlich ein "Shadercore" zugeschaltet, wenn dieser benötigt wird. Trotzdem noch deutlich besser, als wenn der gesamte Chip ständig sinnlos herumidelt. Ob das wirklich so toll funktionieren würde, bleibt natürlich abzuwarten.

[AnarchX]

Oder der Master-Core entspricht dem RV710?
Und dann gibt es noch einen andere Chip-Art über die dann die Leistung skaliert wird -> +3 = R700, +2 = RV770 und +1 RV730.

[reunion]

Auch eine sehr gute Idee. In 2D hat man dann mit allen Chips die gleiche niedrige Leistungsaufnahme.

[AnarchX]

AMD/ATi ist ja zudem nicht der einzige mit solchen Plänen:
http://img208.imageshack.us/my.php?image=6d1eqn8m1897nf2.jpg
Auch wenn in diesem Fall, wohl die Umsetzung fraglich ist... :biggrin:

Hier hat auch mal jemand bei Chiphell etwas zum R700 phantasiert:
http://img219.imageshack.us/img219/8041/20070430e7be84e0e9828b2ao7.png

Und hier auch noch eine nicht ganz uninteressante Betrachtung von Jawed@B3D:
http://forum.beyond3d.com/showpost.php?p=1007968&postcount=15

[deekey777]

Hier hat auch mal jemand bei Chiphell etwas zum R700 phantasiert:
http://img219.imageshack.us/img219/8041/20070430e7be84e0e9828b2ao7.png

Aber irgendwie ist NVIO2 dort störend.

[AnarchX]

Aber irgendwie ist NVIO2 dort störend.

Jo, "ATIIO" oder "AMDIO" wäre wohl besser, aber am Fragezeichen sieht man ja das er nicht recht wusste wie er es bezeichnen sollte.

[Coda]

Und XDR ist ebenso störend...

[AnarchX]

Wie schon gesagt ist es eine Phantasie.

War eigentlich nicht in dem Material zu D3D10.1 die Rede, dass man den Multi-Core/Chip-Support verbessern wollte?

edit:
Performance enhancements
- Enable applications to further exploit multicore for rendering
http://download.microsoft.com/download/5/b/9/5b97017b-e28a-4bae-ba48-174cf47d23cd/PRI022_WH06.ppt

[Liszca]

GPUs sind doch jetzt schon Multicores!

In der Zukunft trennt man sie eben nur auf einzelne Dies auf um Vorteile bei Yields, Wärmeabgabe und Skalierbarkeit zu haben.

Natürlich stehen dem dann auch einige Herausforderungen gegenüber.

also multicore? nicht multichip?

multicore hiesse doch für uns das alles beim alten bleibt oder? wozu also die freude, wird nichts besonderes mehr sein wenn es kommt.

[Gast]

Performance enhancements
- Enable applications to further exploit multicore for renderingSicher, dass da nicht CPUs gemeint sind? ;)

[Gast]

interessant wird auch sein, wieviel cores dann zusammen geschaltet werden!?

da ich ein absoluter noob in diesem bereich bin drück ich es auch mal ganz laienhaft aus:
wenn es nur 2 cores sind, ist man ja recht unflexibel. bei bis zu 4 cores könnte man schon etwas mehr marktsegmente abdecken. aber wenn es sogar max 8-16 (kleine) cores werden, könnte man mit denen ja die komplette palette abdecken, vom ultra low-end bis zum ultra higend.
eigentlich müssten sie einen core als "komplette recheneinheit" bauen und diese dann nur noch paralell schalten. also quasi ein "quad" (so wie das mal war) ist dann ein eigenständiger core, bei denen man dann "beliebig" viele paralle schalten kann. dazu dann noch einen "vewaltungscore", der auf jeder karte nur 1 mal vorkommt und dann noch nen 2D core der auch noch die restlichen aufgaben übernimmt. z.b.

low end, 4 cores:
1 für verwaltung, 1 für 2D und 2 "quads"

midrange, 8 cores:
1 für verwaltung, 1 für 2D und 6 "quads"

hig end, 16 cores:
1 für verwaltung, 1 für 2D und 14 "quads"

keine ahnung wie das mim speicher ist aber eventuell kann man jedem "quad" ja einen speicherchip zuweisen oder man macht halt nen "pool" auf den alle zugreifen können...

sorry wenn ich noob so laienhaft daher rede aber ich denke mal ihr wisst was ich meine...

[SavageX]

Ich möchte einfach mal einstreuen, dass es sowas wie einen "2D Core" nicht (mehr) gibt. Bereits jetzt wickeln aktuellen Grafikchips die 2D Operationen intern mit den 3D Funktionseinheiten ab. Und selbst wenn noch irgendwo separate 2D-Logik existiert: Für die paar Transistoren wird man wohl keinen extra Kern herstellen wollen. Zumal ja im Endeffekt mit Aero, QuartzExtreme und Compiz/Beryl/whatever der "richtige" 2D-only Desktop ja sowieso in den letzten Zügen liegt und somit immer 3D-Funktionalität aktiv sein muss.

[Gmax]

R700 supports DirectX 10.1 (http://www.fudzilla.com/index.php?option=com_content&task=view&id=1072&Itemid=1)

[Ailuros]

R700 supports DirectX 10.1 (http://www.fudzilla.com/index.php?option=com_content&task=view&id=1072&Itemid=1)

Eine Umbennenung in Bullshitzilla koennte vielleicht die Seite noch retten.

Erstens braucht R700 nichts besonders fundamentales im Vergleich zu R600 fuer D3D10.1, zweitens ist R700 nicht wirklich eine "neue Generation" im strengen Sinn, drittens wird dessen Gegner auch D3D10.1 meistern und viertens gehoert die Tesselation in "D3D11" (oder wie es auch immer genannt wird) und sollte nicht vor irgendwo 2009 erwartet werden und selbst das ist optimistisch.

Das dumme ist eben dass M$ genau weiss dass sie mit Vista nicht besonders das Publikum ueberreden werden und deshalb wird hoechstwahrscheinlich "Vienna" frueher kommen als erwartet.

[Die gelbe Eule]

Ich wäre vorsichtig mit Zeitangaben wann ATi GPUs erscheinen, da kann schnell Q2/3 stehen.

[deekey777]

Eine Umbennenung in Bullshitzilla koennte vielleicht die Seite noch retten.

Erstens braucht R700 nichts besonders fundamentales im Vergleich zu R600 fuer D3D10.1, zweitens ist R700 nicht wirklich eine "neue Generation" im strengen Sinn, drittens wird dessen Gegner auch D3D10.1 meistern und viertens gehoert die Tesselation in "D3D11" (oder wie es auch immer genannt wird) und sollte nicht vor irgendwo 2009 erwartet werden und selbst das ist optimistisch.

Das dumme ist eben dass M$ genau weiss dass sie mit Vista nicht besonders das Publikum ueberreden werden und deshalb wird hoechstwahrscheinlich "Vienna" frueher kommen als erwartet.
Vielleicht liege ich da falsch, aber gab es nicht im letzten Jahr eine Präsentation, wo sich eine Tesselationseinheit mitten in die D3D10-Pipeline dazwischen fummelte?

[Godmode]

Vielleicht liege ich da falsch, aber gab es nicht im letzten Jahr eine Präsentation, wo sich eine Tesselationseinheit mitten in die D3D10-Pipeline dazwischen fummelte?

Ja die gab es! Wurde auf der WinHEC 2005 vorgestellt. Aber keine Ahnung warum die Tesselationseinheit dann wieder rausgeflogen ist?:confused:

[Gast]

Ja die gab es! Wurde auf der WinHEC 2005 vorgestellt. Aber keine Ahnung warum die Tesselationseinheit dann wieder rausgeflogen ist?:confused:

Weil sie Nvidia nicht unterstützen könnte.

[laser114]

http://www.sapphiretech.com/us/productfiles/matrix-vga-1.xls

Bestätigt noch mal bereits genannte Daten.
Interessant: Eine passive HD 2600 XT (GDDR3, AGP)...
Und die HD 2600 XT PCIe brauchen auch nach der Liste keinen Stromanschluss.


Edit: Äh - falschen Thread erwischt...

[Gmax]

Nochmal für Ailuros: R700 to focus on tessellation (http://www.fudzilla.com/index.php?option=com_content&task=view&id=1094&Itemid=1) :weg:

[Coda]

Vielleicht liege ich da falsch, aber gab es nicht im letzten Jahr eine Präsentation, wo sich eine Tesselationseinheit mitten in die D3D10-Pipeline dazwischen fummelte?
Die Tesselationseinheit ist vor den anderen Pipelinestages und ersetzt quasi den Input-Assembler. Ob's die allerdings mit 10.1 schon geben wird weiß ich nicht. Das hängt stark davon ab ob es nVIDIA bis dahin auch schon implementiert hat oder nicht.

[Gast]

Die Tesselationseinheit ist vor den anderen Pipelinestages und ersetzt quasi den Input-Assembler. Ob's die allerdings mit 10.1 schon geben wird weiß ich nicht. Das hängt stark davon ab ob es nVIDIA bis dahin auch schon implementiert hat oder nicht.Und was soll das bringen?

Mathematisch präzise gekrümmte Flächen, die einfach nur unnatürlich sind?
Braucht man doch nicht den Quatsch!

[Coda]

Troll?

Das Ding ist programmierbar und somit für ziemlich vieles zu gebrauchen.

[Gast]

Ich mache mir echt Sorgen, dass immer mehr in Firlefanz investiert wird.

Was nützen mir GS, HDR usw. wenn ich immer nicht z.B. einen anständig aussehenden Wald mit 30 Hz und ohne erhebliches z-fighting darstellen kann?
Füllrate, Geometriedurchsatz/-Genauigkeit - DAS waren und sind immernoch die mit Abstand größten Einflußparameter für die Grafikqualität.
Alles andere ist kaum mehr als ein Bild in Photoshop nachzubearbeiten.

[Gast]

Troll?Troll?

Das Ding ist programmierbar und somit für ziemlich vieles zu gebrauchen.Mir fällt auf Anhieb nichts ein, wozu ich dies gebrauchen könnte.

Das einzigste sinnvolle (also außer irgendwelchen Demospielkram) Anwendungsbiet ist Bewegunsanimation für Gesichter usw.
Allerdings braucht man dazu keine großartige Programmierbarkeit der Hardware.
Ein paar simple Vertex-Programme reichen da vollkommen aus.

[dargo]

http://www.pcgameshardware.de/?article_id=617895

Was soll der Blödsinn wieder mit dem eDRam? :|
Und dann noch die lächerlichen 20MB. Außerdem 1024Bit SI? :confused: :|

Der GDDR5 mit 0,5ns dürfte wohl mit ca. 2Ghz takten. Wer braucht dann noch eDRam???

[4711]

lasse ma mache dann kommt NV endlich wieder in die Pötte...langsam wird witzlos mit dem DX10 Gelumpe.

[laser114]

Die möglichen Produktnamen zeigen doch schon genug Merkwürdigkeiten. ;D

Das ist so seriös wie eine in drei Minuten zusammengestellte Erfindung.

[ESAD]

http://www.pcgameshardware.de/?article_id=617895

Was soll der Blödsinn wieder mit dem eDRam? :|
Und dann noch die lächerlichen 20MB. Außerdem 1024Bit SI? :confused: :|

Der GDDR5 mit 0,5ns dürfte wohl mit ca. 2Ghz takten. Wer braucht dann noch eDRam???

das ist sicher ein fake der edram ist zu klein um vernünftig arbeiten zu können und eine platine mit 1024bit si wäre selbstmord

[AnarchX]

Vorallem dann noch ein Package mit 8 Kernen oder 8 einzelne Packages. :ugly:

Wenn dann denke ich wird ATi bei R7xx wohl höchstens wieder im High-End auf Dual-Chip gehen um hier den Problemen aus dem Weg zu gehen, die sie in der Vergangenheit mit großen Dies hatten und eben im auf den neuesten Prozess aufzuspringen.

Vielleicht kommt ja schon eine erweiterte Multi-GPU-Technologie zum Einsatz, wo sie auch entsprechende Patente haben, aber da wäre Mitte 2008 wohlmöglich noch etwas früh.

[Gast]

Egal wie es im Detail aussieht, für Crysis wird sowas schon benötigt um in paar Jahren das Spiel mit ähnlichen Settings zu spielen wie wir heute für FarCry verwenden.

[VivaLaHarry]

Und dann noch die lächerlichen 20MB. Außerdem 1024Bit SI? :confused: :|

Der GDDR5 mit 0,5ns dürfte wohl mit ca. 2Ghz takten. Wer braucht dann noch eDRam???moin zusammen,

vielleicht sind die lächerlichen 20MB eDRAM ja mit 1024Bit angebunden. Könnte mich an die Zahl in Verbindung mit eDRAM noch gut erinnern.
Glaube jedoch kaum, dass man einen 2GHz taktenden Speicher noch mit 1024Bit-Speicherinterface anbinden würde. Man sieht ja jetzt schon, dass es bei der HD2900 komplett überdimensioniert ist. 2GHz @512Bit wären wohl eher denkbar.

MfG,
VivaLaHarry

[][immy]

das ist sicher ein fake der edram ist zu klein um vernünftig arbeiten zu können und eine platine mit 1024bit si wäre selbstmord

nunja, ati wollte ja zu vielen kleinen chips hin. und wenn jeder kleine chip ein 128 Bit speicherinterface hat und seinen eigenen kleinen speicherbereich (siehe voodoo 5) dann könnte das mit den 1024 Bit insgesamt zusammenaddiert schon hinkommen.
das wäre dann sozusagen Crossfire on a chip.

ein crossfire gespann von 2 2900 XT karten hat auch jetzt schon zusammengerechnet ein 1024 Bit speicherinterface, und so rechnet das marketing numal gerne.

ich denke schond das diese zahlen (wenn auch ein wenig verwirrend) stimmen könnten. schließlich wollte man ja zu einer multi-gpu lösung hin damit man mit einem chip alle märkte bedienen kann.

warum sehen immer alle eDRAM als lächerlich an. auch wenn es 20 MB sind, als kurzzeitiger schneller puffer kann der immer gut sein, könnte man dann mit dem cache in ner cpu vergleichen, auch wenn der cache noch nen stück schneller sein dürfte.

[Nakai]

nunja, ati wollte ja zu vielen kleinen chips hin. und wenn jeder kleine chip ein 128 Bit speicherinterface hat und seinen eigenen kleinen speicherbereich (siehe voodoo 5) dann könnte das mit den 1024 Bit insgesamt zusammenaddiert schon hinkommen.
das wäre dann sozusagen Crossfire on a chip.

Was eine totale Verschwendung wäre.

mfg Nakai

[laser114]

[immy;5973168']nunja, ati wollte ja zu vielen kleinen chips hin. und wenn jeder kleine chip ein 128 Bit speicherinterface hat und seinen eigenen kleinen speicherbereich (siehe voodoo 5) dann könnte das mit den 1024 Bit insgesamt zusammenaddiert schon hinkommen.
das wäre dann sozusagen Crossfire on a chip.

Da wären heutzutage aber wohl 64-Bit-Cluster sinnvoller.

[Gast]

[immy;5973168']
warum sehen immer alle eDRAM als lächerlich an. auch wenn es 20 MB sind, als kurzzeitiger schneller puffer kann der immer gut sein, könnte man dann mit dem cache in ner cpu vergleichen, auch wenn der cache noch nen stück schneller sein dürfte.

1. wie willste es denn anbinden? wir haben schon 384/512Bit Interface gesehen, GDDR4 erlaubt wieder höhere Taktraten so das Bandbreiten jenseitz von 100GB/sec im Highend nächstes Jahr Standard sein werden.

2. 20MiB Cache?
Heutige GPUs haben intern schon Caches an wichtigen Stellen, es wurde mal gemutmaßt das es ca. 512KB atm sind.
eDRAM als Cache is viel zu umständlich anzubinden und eher ein "Klotz am Bein" als Hilfreich (evtl als 2. bzw. 3. LvL Cache denkbar). Denn für Framebuffer oder ähnliches taugt er nicht, da am PC verschiedene Auflösungen +AA mehr RAM beanspruchen werden als eDRAM für 1 Frame beinhalten kann. Da kann man auch gleich "echten" Cache verbauen, der aber zuviel Platz frisst, man will in einer GPU ja ordentlich Rechenwerke verbauen ;)

[dargo]

[immy;5973168']nunja, ati wollte ja zu vielen kleinen chips hin. und wenn jeder kleine chip ein 128 Bit speicherinterface hat und seinen eigenen kleinen speicherbereich (siehe voodoo 5) dann könnte das mit den 1024 Bit insgesamt zusammenaddiert schon hinkommen.
das wäre dann sozusagen Crossfire on a chip.

Kannst du mir erklären wie das funktionieren soll? Das wären 8 einzelne "GPUs". Es gibt bei Quad-SLI schon einen extremen Lag, wie soll dann denn erst bei 8 GPUs aussehen? X-D

[reunion]

Kannst du mir erklären wie das funktionieren soll? Das wären 8 einzelne "GPUs". Es gibt bei Quad-SLI schon einen extremen Lag, wie soll dann denn erst bei 8 GPUs aussehen? X-D

Das geht natürlich nur, wenn die Interconnections direkt auf dem Package sind und sich die acht Dies wie ein Chip verhalten. Dann habe ich die Vorteile der kleinen Dies ohne die Nachteile von SLi/CF, allderdings wäre das wohl extrem teuer, man bräuchte sicherlich mehrere 100GB/s um den Chip nicht auszubremsen.

[Gast]

Tja, 8 kleine Hotspots oder doch ein MegaRechenwerk-Verband. Durch den Aufbau sind doch GPUs eigentlich in viele kleine GPUs schon aufgeteilt oder.
Quad/Cluster Räumlich von einander zu trennen... dazu noch das Problem das man ordentliches Tiling einbauen müsste, oder wie will man mit 8 Mini GPUs den Framebuffer vollmachen?

[Nakai]

Wie mans nach meiner Meinung machen sollte:

Ein Chip ist das SI mit den ROPs, ähnlich dem Xenos

Und dann noch bis zu 4 Chips, die extra auf das Package gebracht werden.

Dadurch würde man sich die Extra-Speicherchips für jeden Chip und ordentlich Platz.


mfg Nakai

[reunion]

Tja, 8 kleine Hotspots oder doch ein MegaRechenwerk-Verband. Durch den Aufbau sind doch GPUs eigentlich in viele kleine GPUs schon aufgeteilt oder.
Quad/Cluster Räumlich von einander zu trennen... dazu noch das Problem das man ordentliches Tiling einbauen müsste, oder wie will man mit 8 Mini GPUs den Framebuffer vollmachen?

Genau so wie mit einer große GPU, der Chip sollte sich genauso verhalten, als würde er aus nur einem Die bestehen. Sonst macht das ganze wenig Sinn.

Wie mans nach meiner Meinung machen sollte:

Ein Chip ist das SI mit den ROPs, ähnlich dem Xenos

Und dann noch bis zu 4 Chips, die extra auf das Package gebracht werden.

Dadurch würde man sich die Extra-Speicherchips für jeden Chip und ordentlich Platz.


mfg Nakai

Umso mehr unterschiedliche Chips, umso mehr Tapeouts, umso mehr Fertigungsstraßen, umso teurer. Die extra Speicherchips würde man sich auch so ersparen, wenn die Chips die interne Kommunikation einfach über das Package machen. Ob das allerdings in naher Zukunft realistisch ist, ist eine andere Frage, da die Latenz und die Bandbreite natürlich extrem hoch bzw. gering sein müsste.

[AnarchX]

Viel wichtiger als die Frage der Realisierung der Multi-GPU-Technologie ist imo doch eher was sich an den Einheiten bei R7xx tun wird.

Eine völlig neue Architektur, wie CineFX->G8x, erwarte ich eher weniger, wichtige Schritte, die NV erst mit G8x tat, wurden ja bei ATi schon mit R520/R580 und Xenos vollzogen.

Im Endeffekt wird man wohl auf der Basis von R600 oder vielleicht doch etwas weiter zurück auf Basis der oben genannten GPUs entwickelt haben.

Die wichtigsten Kritikpunkte am R6xx sind imo:

zu schwache ROPs(2 Z, SC-2xMSAA), die wohl auch Eric Demers als ein Flaschenhals sieht
zu wenig Texelleistung (auch wenn deren Bedeutung in Zukunft abnehmen sollte, aber HQ-AF wird ja auch noch gefordert und vielleicht kommt einer der IHVs mal auf die Idee >16x AF einzuführen ;))
Vector-Architektur mit niedrigerer Effizienz im Vergleich zu skalaren Architektur bei G8x/G9x


zu 1.:
Da zeigt ja schon Xenos, das es deutlich besser geht, welcher SC-4xMSAA und 8 Z pro Takt (http://www.beyond3d.com/content/articles/4/4) schaffen soll.
16 ROPs mit diesen Fähigkeiten wäre für einen RV770 bzw. Teil-Chip doch schonmal eine deutliche Steigerung.

zu 2.:
Hier scheint wohl ATi auf Optimierungen zu setzen, welche aber dann hoffentlich nicht auffällig sind.
Aber man wird wohl nicht herumkommen die Filterleistung zu erhöhen, wobei hier wohl etwas in den Clustern getan werden sollte, anstatt diese einfach zu erhöhen, da dies ja dann eine Erhöhung von 20SPs x SIMD-Zahl nach sich ziehen würde.

zu 3.:
An sich ist ja die Vektor-Architektur bei R6xx schon sehr weit, im Endeffekt wäre wohl hier der nächste sinnvolle Schritt auch zu skalaren SPs, aber ob das so einfach für ATi realisierbar wäre, ist natürlich eine andere Frage.

Und zu guter letzt, wird sich ATi hoffentlich auch in Richtung verschiedener Taktdomainen für die Funktionseinheiten im G8x-Maßstab bewegen, da man ja hierdurch deutlich an Transistoren als auch an Verlustleistung sparen kann.

[][immy]

Kannst du mir erklären wie das funktionieren soll? Das wären 8 einzelne "GPUs". Es gibt bei Quad-SLI schon einen extremen Lag, wie soll dann denn erst bei 8 GPUs aussehen? X-D

ich sag nur Voodoo 5 ;)
und die entwicklung sollte ja wohl inzwischen ein wenig fortgeschritten sein.
grafik lässt sich herlich parallelisieren, von daher sehe ich bei 8 GPUs kein problem. wenn von anfang an so entwickelt wird und es quasi einen steuerchip gibt sollte es kein problem geben wie derzeit mit crossfire und sli.
der vorteil für ati ist ja einfach, das die entwicklung einfach günstiger ist. intel will ja quasi bei den prozessoren auch in die richtung. lieber viele kleine chips als ein einzelner großer. solange die grundleistung eines einzelnen chips in etwa an die letzte mainstream-generation herankommt sehe ich da kein problem.

Wenn 3Dfx das damals geschafft hat, sollten nvidia und ATi wohl auch in der lage sein ein ähnlich effizientes design auf die beine zu stellen (bzw durch die zeit wohl um einiges effizienter)

[dargo]

[immy;5973547']ich sag nur Voodoo 5 ;)

Schau dir nochmal eine Voodoo 5 an und dann wie komplex heutige GPUs und vorallem PCBs für diese sind. ;)
Wie lang soll deiner Meinung nach die Karte werden, 1m? :D

[laser114]

Und Voodoo ist u. a. auch an der Voodoo 5 gescheitert...

(Auch wenn von dieser nicht alles abhängt.)

[Ailuros]

Zum eDRAM Zeug:

http://forum.beyond3d.com/showpost.php?p=1081769&postcount=127

http://forum.beyond3d.com/showpost.php?p=1081773&postcount=128

Zwei kleine Ausschnitte mit denen ich zustimme. Da eDRAM in groesseren Mengen ziemlich teuer ist (ie erhoeht das transistor-budget zu stark), muesste es einen sehr guten Grund und in der Mehrzahl nur Vorteile von der Implementierung geben.

In Maerkten wo ein Prozessor zu begrenzt ist was z.B. die Bandbreite betrifft (siehe PDA/mobiles oder Consolen z.B.) koennte eDRAM Sinn machen. Hingegen im PC Markt muss man entweder alle Faelle abdecken (z.B. Faelle wo keine Kompression angewendet wird) was aber zusaetzliche Kompressions-Logik bedeutet und ergo die Unkosten noch weiter steigert, sonst gewinnt man nur in einer begrenzten Anzahl von Faellen etwas dazu.

Ich persoenlich kann selbst bei Xenos keinen besonderen Grund fuer das eDRAM Modul sehen, denn ich sehe keinen Entwickler der ueber das extra macro-tiling wirklich verrueckt ist. Was jetzt den PDA/mobile Markt betrifft, wuerde es mich nicht wundern wenn NV tatsaechlich hier eine kleine Portion von eDRAM einbaut fuer die OGL_ES2.x Generation (und ich hab keine Ahnung was AMD's "mini-Xenos" genau ist) aber ich hab sehr guten Grund an Imagionation's SGX im Gegensatz zu glauben.

Wer hier eDRAM anwendet hat sofort einen fetteren chip zur Hand als SGX, wenn man auch alle Features des letzteren einbauen will bei vergleichbarer Leistung.

Da zeigt ja schon Xenos, das es deutlich besser geht, welcher SC-4xMSAA und 8 Z pro Takt schaffen soll.
16 ROPs mit diesen Fähigkeiten wäre für einen RV770 bzw. Teil-Chip doch schonmal eine deutliche Steigerung.

Es ist wohl offensichtlich dass irgendein Depp wieder ein paar tolle Zahlen zusammengewuerfelt hat. Sowohl fuer R600 als jetzt fuer G92 wurden angeblich eDRAM spekuliert. ROP Anzahl ist natuerlich nicht direkt mit der eDRAM Menge verbunden, aber nur ein Idiot koennte sich 64 ROPs IMHLO fuer einen angeblichen high end chip ausdenken.

Angenommen es sind single cycle 4xMSAA ROPs und der chip taktet bei moderaten 600MHz:

64 * 600 * 4 = 153.6 GPixels/s

Das ist dreimal die Z-Fuellrate einer 8800GTX; hat man jetzt dafuer 20MB eDRAM haben wohl die Designer eher etwas in Richtung 1600*wasauchimmer oder sogar 1920*wasauchimmer als Ziel-Aufloesunge im Hinterkopf. Und fuer diese Aufloesungen braucht man eine solche Uebermenge an Z-Fuellrate?

Zur weiteren Ernuechterung mit ein paar Optimierungen hat die 8800GT 38.4 GPixels/s und die scheinen selbst in 1920 mit 4xAA keine Bremse darzustellen.

IMHLO sind 4 gesunde 4xMSAA ROPs vollkommen ausreichend fuer ultra low end selbst der naechsten Generation und eDRAM kann man vergessen weil keiner der IHVs Bock darauf hat die Unkosten jeglichen desktop chips unnoetig zu vergroessern.

[robbitop]

Das eDRAM in der X360 hat schon einen Grund. Die bandbreitenlastigstige Anwendung, nämlich Framebufferzugriffe, belasten den RAM nicht. Der ist nur für Texturzugriffe, Vertexbuffer und als RAM für die CPUs da. Dafür reicht der auch gerade so noch.

[Coda]

[immy;5973547']ich sag nur Voodoo 5 ;)
und die entwicklung sollte ja wohl inzwischen ein wenig fortgeschritten sein.
Im Gegenteil. Heutige Multi-GPU-Techniken haben viel mehr Probleme als damals.

[immy;5973547']grafik lässt sich herlich parallelisieren, von daher sehe ich bei 8 GPUs kein problem. wenn von anfang an so entwickelt wird und es quasi einen steuerchip gibt sollte es kein problem geben wie derzeit mit crossfire und sli.
Das Problem ist, dass eigentlich ein Speichercontroller verwendet werden muss für alle Chips und dann Interconnects die die 100GiB/s Bandbreite schaufeln können. Das gibt's aber quasi nicht. Zumindest nicht bezahlbar.

[AnarchX]

Es ist wohl offensichtlich dass irgendein Depp wieder ein paar tolle Zahlen zusammengewuerfelt hat. Sowohl fuer R600 als jetzt fuer G92 wurden angeblich eDRAM spekuliert. ROP Anzahl ist natuerlich nicht direkt mit der eDRAM Menge verbunden, aber nur ein Idiot koennte sich 64 ROPs IMHLO fuer einen angeblichen high end chip ausdenken.

Warum beziehst du das auf mein Posting, ich dachte ja eher in folgende Richtung:

High-End: 2x16 ROPs
Performance: 16 ROPs
Mainstream: 8 ROPs
Low-End: 4 ROPs

Sind es "Xenos-ROPs", bei einem Takt von vielleicht 800-900MHz,wären das ja dann bei High-End:
AA-Fill: 100 - 115 GPix/s (vs 8800Ultra 59GPix/s bzw. imaginäre "8900GTX" ~80GPix/s)
Z-Fill: 200-230 GZix/s (vs 8800Ultra 115GZix/s bzw. imaginäre "8900GTX" 150GZix/s)

Für eine High-End-SKU, die Mitte 2008 kommen soll und vielleicht nicht 100%ig effizient arbeite auf Grund des Dual-Die-Aufbaus, doch gar nicht mal so unrealistisch.

Mal noch etwas weiter gesponnen:

2x24 TMUs (mit optimierten AF-Algorithmus ~30% gegenüber R600)
-> ~40GTex/s (~50GTex/s in der Relation zu R600)

2x480SPs(MADD)
-> 1.6TFLOPs

2x256Bit mit 1.7-2GHz GDDR4/5
-> ~230GB/s

2x ~250mm² @ 55nm auf einem Package

[Ailuros]

Das eDRAM in der X360 hat schon einen Grund. Die bandbreitenlastigstige Anwendung, nämlich Framebufferzugriffe, belasten den RAM nicht. Der ist nur für Texturzugriffe, Vertexbuffer und als RAM für die CPUs da. Dafür reicht der auch gerade so noch.

Eines der toll vermarkteten Ziele naehmlich nahezu "AA4free" erreichte aber Xenos nie. Und afaik wurde das eDRAM Dingsbums auch fuer dieses u.a. entwickelt. Die meisten Entwickler haben eben wohl keine Lust sich mit zusaetzlichem macro tiling den Kopf zu zerbrechen und dazu IMO gerechtfertigt.

Ja natuerlich hat es seinen Nutzen aber ich will den Aufwand fuer Entwicklung des Tochter-dies und die dafuer verschwendeten Transistoren bei seiner reinen heutigen Endnutzung am Ende bezweifeln (minus stets die ROPs natuerlich).

[robbitop]

Auch ohne AA macht eDRAM bei Konsolen sehr viel Sinn.
So entlastet man mit wenig aber dafür schnellen RAM auf lange Sicht billig (shrinks) die Kosten für den RAM. Denn man kann nun ein dünneres SI verbauen. Denn ein SI wird ja nicht billiger (PCB Kosten, Layer ect).
Ein 128 bit SI mit 700 MHz GDDR3 hätten niemals gereicht, um auch noch den Framebuffer zu beherbergen, ohne Xenos dauernd zu limitieren. Ein 256 bit SI wäre teurer geworden und die Kosten hätten sich auch durch Shrinks und neue Revisionen nicht reduziert über die Jahre.
Ich halte sehr viel von eDRAM in Konsolen.

[Ailuros]

Warum beziehst du das auf mein Posting, ich dachte ja eher in folgende Richtung:

Ich hab mich auf die BS-specs bezogen, die ja offensichtlich nicht von Dir stammen.

High-End: 2x16 ROPs
Performance: 16 ROPs
Mainstream: 8 ROPs
Low-End: 4 ROPs

Es wird so langsam Zeit dass ROPs gleich ganz verschwinden; ueberhaupt fuer AMD. Egal aus welchem Grund sie shader resolve fuer R6x0 gewaehlt haben, waere dieses der naechste logische Schritt fuer eine neue Generation von chips.

Ist R700 nur ein moderater Refresh dann hatten sie zwar Zeit fuer Aenderungen in den ROPs, aber wie sehr gut oben gewuerfelt so wie die R6x0 Architektur ausgelegt ist, wird es wohl schwer mehr als 16 ROPs pro chip geben.

Sind es "Xenos-ROPs", bei einem Takt von vielleicht 800-900MHz,wären das ja dann bei High-End:
AA-Fill: 100 - 115 GPix/s (vs 8800Ultra 59GPix/s bzw. imaginäre "8900GTX" ~80GPix/s)
Z-Fill: 200-230 GZix/s (vs 8800Ultra 115GZix/s bzw. imaginäre "8900GTX" 150GZix/s)

Für eine High-End-SKU, die Mitte 2008 kommen soll und vielleicht nicht 100%ig effizient arbeite auf Grund des Dual-Die-Aufbaus, doch gar nicht mal so unrealistisch.

Unrealistisch durchaus nicht; aber auch nichts besonderes. Man bekommt heutzutage hoehere Raten von einem 2*8800GTX@SLi Gespann.

Mal noch etwas weiter gesponnen:

2x24 TMUs (mit optimierten AF-Algorithmus ~30% gegenüber R600)
-> ~40GTex/s (~50GTex/s in der Relation zu R600)

2x480SPs(MADD)
-> 1.6TFLOPs

2x256Bit mit 1.7-2GHz GDDR4/5
-> ~230GB/s

2x ~250mm² @ 55nm auf einem Package

Siehe oben. AMD muss sich um einiges mehr anstrengen als mit all dem obrigen, ausser man verkauft mal wieder die jeweiligen Resultate mit Ausverkauf-Preisen.

[Gmax]

Kann man März-Juni mit dem R7oo rechnen? Oder soll etwa die HD387o X2 bis Herbst 08 Atis Spitzenprodukt bleiben??

[malle]

Kann man März-Juni mit dem R7oo Karte rechnen? Oder soll etwa die HD387o X2 bis Herbst 08 Atis Spitzenprodukt bleiben??

HD3880 und HD3890 wären noch möglich bis dahin oder?

[Gmax]

Auch falls es diese geben sollte, es wird wohl nicht reichen.

[laser114]

HD3880 und HD3890 wären noch möglich bis dahin oder?

Was soll das sein? Ein höher getakteter RV670?

Irgendwann muss dann schon mal ein neuer Chip her...

[malle]

Ich rede nicht von schneller oder besser als NV gegenstück sondern das die Zahlen es zulassen. Das ein neuer Chip nötig ist, das 55nm nötig ist ect. spielt bei meiner Überlegung keine Rolle. Ich sage nur, das nach Markenbezeichnung noch Platz nach oben offen ist. Nicht mehr und nicht weniger und ich bezog mich auf einen User und dessen Frage und nicht auf den Strang allg.

[GeneralHanno]

Kann man März-Juni mit dem R7oo rechnen? Oder soll etwa die HD387o X2 bis Herbst 08 Atis Spitzenprodukt bleiben??

gute frage, wann der R700 kommt. ich tippe auf frühestens Q2 eher anfang Q3. mit dem neuen namen (3xxx) macht ATi klar, dass es sich um eine "neue" serie handelt und keinen kurzfristigen lückenfüller.

die 3000er reihe wird wird eine komplettes packet von lowend-bis highest-end bieten. der RV670 deckt das performencesekment ab. im Jan kommt die 3870X2 als flagg-schiff. im Feb dürften dann die umsatztträchtigen 3600 und 3400 kommen (mit dice unter 100mm2 !).

und einen neuen high-end chip (singelchip) wird es eh nicht geben. der schwerpunkt im bereich "enthusiast" liegt auf quad- (und octo-) CF.

außerdem lagen bei ATi zwischen neuen high-end generationen (800xt -> 1800xt -> 2900xt) jeweils etwa 1,5 jahre. selbst wenn man ATis urspünglichen launchtermin im Jan07 für die 2900xt nimmt, dann kommt der R700 frühestens ende Q2/08.

[w0mbat]

R700 is indeed a multi core device (http://www.fudzilla.com/index.php?option=com_content&task=view&id=4327&Itemid=1)


That is why R680 makes sense


It looks like ATI wants to go multi core and this time it can put more smaller cores on a single chip. You can expect that the high end R700 might end up with more than four smaller cores that will shape up this card.

This is why R680, Radeon 3870 X2 is extremely important for ATI’s future as it looks like that the future looks really multicore. We still don’t know if G100 uses the same approach but we would not be surprised.

R700XT the high end version of the chip will use four or more smaller cores to reach the performance crown and in this case you need an excellent crossfire, multichip driver.

R680 is actually a warm up product as ATI will test the crossfire X with two, three and four cores and this will give them predictions about the future. R700 is still scheduled for middle of 2008.

[GeneralHanno]

so könnte der R700 dann aussehen: BILD (http://www.3dcenter.org/artikel/voodoo5-6000/pic_karte.php)

es fällt aber auf, dass ausdrücklich von multi CORE und NICHT GPU gesprochen wird. d.h. es wird wohl zu 95% ein multi-dice package werden.

was mich noch interessieren würde, ob es sowas wie einen "mastercore" gibt (so wie bei cell prozessoren), der z.b. die ROPs, den speicherkontroler oder die scheduler enthält. denn bei 4+ cores ist das quasi pflicht. ansonsten würde der vrambedarf (gemäß normalem CF braucht jeder core einen gleich großen vram, der nicht addiert werden darf) ja ins unermässliche schießen.

[AnarchX]

Ich bezweifele, dass man mehr als 2 Dies verbauen wird bzw. dass es spezielle Dies geben wird.

Eher wird man wohl 2 Dies/GPUs per Ringbus verbinden, wozu man aber immernoch >100GB/s Datenpfade auf dem Package benötigt.

[GeneralHanno]

wenn man aber 4 oder mehr dice auf einem PCB verbauen will, dann muss es eine tiefere verbindung untereinder geben, als aktuell mit CF. alles andere wäre doch ein enormes effiziensproblem (rendermodus afr, sfr, ? , vrambeadrf, bandbreitenbedarf)

[Gast]

Eher wird man wohl 2 Dies/GPUs per Ringbus verbinden, wozu man aber immernoch >100GB/s Datenpfade auf dem Package benötigt.
ist das denn technisch so schwierig?

[dargo]

wenn man aber 4 oder mehr dice auf einem PCB verbauen will, dann muss es eine tiefere verbindung untereinder geben, als aktuell mit CF. alles andere wäre doch ein enormes effiziensproblem (rendermodus afr, sfr, ? , vrambeadrf, bandbreitenbedarf)
Wenn du die Speicherbandbreite meinst - die addiert sich bei SLI/CF.

[GeneralHanno]

die speicherbandbreite addiert sich, das weis ich. aber bisher musste für jede GPU eigene speicherleitungen gelegt werden, und bei 4 oder mehr GPUs würde das 4 speicherbahnen bedeuten, was das PCB design sehr complex machen würde.

[PCGH_Carsten]

Wenn du die Speicherbandbreite meinst - die addiert sich bei SLI/CF.
Leider nur teilweise. Die Lese/Schreibzugriffe für Texturen bleiben redundant, ebenso Z-R/W bei AFR.

Wenn die Applikation "gut" (im Sinne von passend für SLI/CF) gebalanced ist, könnte natürlich die eine Karte den Z-First-Pass machen und die andere das restliche Rendering. Da würde man sicherlich auch eine Menge Datentransfers sparen.

Dummerweise braucht der Z-Pass meist deutlich weniger Zeit als der Rest des Shadings - bei Crossfire ist's derzeit wohl etwas ausgeglichener, da das Verhältnis Z/ALU ein anderes ist.

[up¦²]

R700 is indeed a multi core device (http://www.fudzilla.com/index.php?option=com_content&task=view&id=4327&Itemid=1)
Hat Ati eigentlich noch die zwei Teams (Marlborough/Silicon Valley) seit AMD?

[w0mbat]

kA, aber ich frage mich ob der R700 eine ganz neue GPU ist, wie G71 -> G90 bei nVidia, oder ob er Ähnlichkeiten mit dem R600 hat (z.B. die 5D Shader).

[reunion]

kA, aber ich frage mich ob der R700 eine ganz neue GPU ist, wie G71 -> G90 bei nVidia, oder ob er Ähnlichkeiten mit dem R600 hat (z.B. die 5D Shader).

Da sich am Tech-Level nichts ändern wird, macht es keinen Sinn, hier eine völlig neue Architektur zu entwickeln. Das wäre reine Ressourcenverschwendung. R700 wird ein an den entscheidenden Stellen optimierter R600 sein. Was ja nicht schlecht sein muss, wenn man die richtigen Schlüsse zieht.

[Hvoralek]

Hat Ati eigentlich noch die zwei Teams (Marlborough/Silicon Valley) seit AMD?Ailuros meinte mal, erst bei R800 hätte man nur noch ein einzelnes Team.

[AnarchX]

R700 mini core is 72 sq mm
Put a lot of them together (http://www.fudzilla.com/index.php?option=com_content&task=view&id=4346&Itemid=34)

Fragt sich nur wie das mit der Verbindung funktionieren soll und erst recht zu welchen Kosten? :|

[Gast]

R700 mini core is 72 sq mm
Put a lot of them together (http://www.fudzilla.com/index.php?option=com_content&task=view&id=4346&Itemid=34)

Fragt sich nur wie das mit der Verbindung funktionieren soll und erst recht zu welchen Kosten? :|

AMD ist nicht blöd. Würde sich das nicht lohnen, würde man kaum darauf zurückgreifen. IMHO werden die Kosten hier von so machen Pseudo-Experten deutlich überschätzt. Man kann so mit nur einem (sehr kleinen) Die die gesamte Produktpalette von Low- bis High-End abdecken, das spart ungemein R&D, Tapeoutkosten, reduziert die Fertigungsrisiken immens, und ermöglicht eine enome Flexibiltät, da man auch noch sehr kurzfristig auf die Konkurrenz reagieren kann.

reunion

[g0ldmund]

R700 is a 45 nanometre chip (http://www.fudzilla.com/index.php?option=com_content&task=view&id=4348&Itemid=34)

[dargo]

Huch - 45nm, 72mm² Die, nur 300 Millionen Transistorcount je Die. Das dürfte ziemlich günstig in der Produktion sein. Ich frage mich aber immer noch wie man daraus High-End realisieren will? Ich meine - einfach 2, 3 oder gar 4 solcher GPUs auf ein PCB draufklatschen geht ja auch nicht. Oder etwa doch?

Hat man vielleicht doch endlich was besseres als SLI/CF zu bieten? :confused:

[AnarchX]

Ich meine - einfach 2, 3 oder gar 4 solcher GPUs auf ein PCB draufklatschen geht ja auch nicht. Oder etwa doch?

Hat man vielleicht doch endlich was besseres als SLI/CF zu bieten? :confused:

Darauf würde es ja hinauslaufen. ;)

Am sinnvollsten wäre wohl wirklich den Ringbus als Verbindung zwischen den einzelnen Dies zu nutzen.

[Gast]

Huch - 45nm, 72mm² Die, nur 300 Millionen Transistorcount je Die. Das dürfte ziemlich günstig in der Produktion sein. Ich frage mich aber immer noch wie man daraus High-End realisieren will? Ich meine - einfach 2, 3 oder gar 4 solcher GPUs auf ein PCB draufklatschen geht ja auch nicht. Oder etwa doch?


Laut Fudzilla:
1 Die Lowend
2 Die Midrage
4 Die High-End


Hat man vielleicht doch endlich was besseres als SLI/CF zu bieten? :confused:

Man hat defintiv was besseres zu bieten, wenn das tatsächlich stimmen sollte. Man kann schlecht viermal das SI und den Speicher verbauen. Die einzige Möglichkeit ist eine schnelle Verbindung untereinander.

reunion

[Gast]

Ich frage mich aber immer noch wie man daraus High-End realisieren will?

Wer sagt denn das sie das wollen oder überhaupt können? IMO wird AMD aus dem High-End Markt aussteigen und nur noch billige Grafiklösungen anbieten.

[Gast]

Wer sagt denn das sie das wollen oder überhaupt können? IMO wird AMD aus dem High-End Markt aussteigen und nur noch billige Grafiklösungen anbieten.

Das sieht AMD zum Glück anders.

[dargo]

Wer sagt denn das sie das wollen oder überhaupt können? IMO wird AMD aus dem High-End Markt aussteigen und nur noch billige Grafiklösungen anbieten.
R700 passt wohl kaum zu einer 72mm² GPU. :|

[aylano]

Mal sehen, wann die R(V)700-Serie kommt.

Ob sie es schaffen, die R700-Mobil gleichzeitig mit er neuen AMD-Notebook-Plattform a la Puma rauszubringen???

RS780-mobil soll ja Mai 2008 rauskommen.

[dargo]

Man hat defintiv was besseres zu bieten, wenn das tatsächlich stimmen sollte. Man kann schlecht viermal das SI und den Speicher verbauen. Die einzige Möglichkeit ist eine schnelle Verbindung untereinander.

reunion
Ich hoffe nur, diese neue Lösung ist nicht mit Lags verbunden.

[AnarchX]

Ich hoffe nur, diese neue Lösung ist nicht mit Lags verbunden.

Ich glaube, dass wären die kleinsten Probleme die bei so einem Konstrukt auftretten könnten. :D

Aber irgendwie passen 4x 300 Mio. Tr. Kerne nicht ganz zu den Leistungsdaten, die ich vorliegen habe. :uponder:

Naja, mal sehen was demnächst noch so herauskommt.

[Gast]

Ich hoffe nur, diese neue Lösung ist nicht mit Lags verbunden.

Wenn die Kerne untereinander Verbunden sind, hast du natürlich auch keine Lags. Es gibt ja dann nur noch ein SI, und einen VRAM. Die Bilder können also nicht nacheinander berechnet werden, sondern die Dice müssen wie ein Chip gemeinsam an einem Bild rendern.

reunion

[HOT]

Gedankenspiel: Wenn man CPU Technik verbaut und die 2-4 Chips über einem XBar mit einem RAM Interface verbindet wirds wohl gehen.
Der R700 würde dann aus 3 Chips bestehen: Ein SingleCore für Lowend (da sind 72mm² verdammt gut), einen Mainstreambeschleuniger mit 2 Cores und einen High-End Beschleuniger mit 4 Cores.

[Gast]

Aber irgendwie passen 4x 300 Mio. Tr. Kerne nicht ganz zu den Leistungsdaten, die ich vorliegen habe. :uponder:


Leistungsdaten - jetzt schon? Die wurden sowieso nur erfunden. Aktuell hat sicher noch kein R700 das Labor verlassen.

reunion

[Gast]

Gedankenspiel: Wenn man CPU Technik verbaut und die 2-4 Chips über einem XBar mit einem RAM Interface verbindet wirds wohl gehen.


Wie breit stellst du dir denn das RAM-Interface eines einzelnen Core vor?

[AnarchX]

Leistungsdaten - jetzt schon? Die wurden sowieso nur erfunden. Aktuell hat sicher noch kein R700 das Labor verlassen.

Sicher, wird wohl eher eine Projektion sein, was man anzielt.(ich meinte theoretische Rohleistungsdaten ;))

Aber wenn man R7xx Mitte 2008 launchen will, sollten doch bald Samples in Silizium existieren.

[dargo]

Wenn die Kerne untereinander Verbunden sind, hast du natürlich auch keine Lags. Es gibt ja dann nur noch ein SI, und einen VRAM. Die Bilder können also nicht nacheinander berechnet werden, sondern die Dice müssen wie ein Chip gemeinsam an einem Bild rendern.

reunion
Mehrere GPUs die sich wie Eine verhalten und immer 1:1 skalieren? *träum*

[ESAD]

bei graffikarten ist das deutlich realistischer als bei cpus ... die sind sowieso auf paraleles rechnen ausgelegt.... wenn man alle direkt untereinander anbindet auf einem pvc sollte sich schon eine 90% effizienz herausholen lassen

[deekey777]

Wie ist eigentlich der Tochter-Kern mit dem Eltern-Kern beim Xenos verbunden?

[Godmode]

Ich kann mir vorstellen warum Splitframe-Rendering über 2 Karten nicht sehr effizient ist (lange Signallaufzeiten), aber warum es auf einer Karte oder Package mit mehrere Kernen nicht effizient möglich ist, noch nicht verstanden. Wenn so eine Lösung wirklich effizent wäre, würde dies die Herstellung von starken GPUs viel wirtschaftlicher machen.

[HOT]

Wie breit stellst du dir denn das RAM-Interface eines einzelnen Core vor?
Garnicht. Das RAM Interface würde dann im XBar sitzen und wäre in beliebiger Breite anbindbar. Im Prinzip wäre das ein Phenom mit 4 Grafikkernen statt K10 Kernen :D.

[AnarchX]

Nur gibt es bei >R6xx aber kein XBar mehr:
http://img258.imageshack.us/img258/1290/ringbusii1fw7.jpg

Wenn dann wird man wohl die Ringstops auf die einzelnen Chips verteilen, worauf man auch im B3D spekuliert.

[Gast]

Garnicht. Das RAM Interface würde dann im XBar sitzen und wäre in beliebiger Breite anbindbar. Im Prinzip wäre das ein Phenom mit 4 Grafikkernen statt K10 Kernen :D.

Und wie willst du die Kerne an den XBar anbinden?

[Gast]

Nur gibt es bei >R6xx aber kein XBar mehr:
http://img258.imageshack.us/img258/1290/ringbusii1fw7.jpg

Wenn dann wird man wohl die Ringstops auf die einzelnen Chips verteilen, worauf man auch im B3D spekuliert.

Ja, ist für mich auch am wahrscheinlichsten. Umsonst wird man den Ringbus ja nicht verbaut haben. Und so erspart man sich jeden Kern mit jedem zu verbinden, sondern muss immer nur zu den "Nachbarchips" eine Verbindung herstellen.

reunion

[Gast]

Für mich extrem unwahrscheinlich, weil der Ringbus 512Bit breit ist und man sicher die Dice nicht mit 1024Bit untereinander verbindet.

[HOT]

Nur gibt es bei >R6xx aber kein XBar mehr:
http://img258.imageshack.us/img258/1290/ringbusii1fw7.jpg

Wenn dann wird man wohl die Ringstops auf die einzelnen Chips verteilen, worauf man auch im B3D spekuliert.
Das ist irgendwie ein bisschen anders gemeint... nicht die Anbindung der Speicherchips (die kann weiterhin so laufen, das spielt doch keine Rolle), sondern die Anbindung der einzelnen Kerne. Die B3D Version klingt auch nicht schlecht.

[GeneralHanno]

Für mich extrem unwahrscheinlich, weil der Ringbus 512Bit breit ist und man sicher die Dice nicht mit 1024Bit untereinander verbindet.

begründung?

[Gast]

Zu teuer, falls überhaupt technisch machbar.

[GeneralHanno]

ein RingBus 512bit SI bedeutet, das man nur die anbindung 1024 pins auf dem package braucht, richtig ?

[4 Vitamins]

Am sinnvollsten wäre wohl wirklich den Ringbus als Verbindung zwischen den einzelnen Dies zu nutzen.

Ist das "deine vermutung"?:rolleyes:

gruss

[4 Vitamins]

[QUOTE=AnarchX;6049326]

Aber irgendwie passen 4x 300 Mio. Tr. Kerne nicht ganz zu den Leistungsdaten, die ich vorliegen habe. :uponder:

QUOTE]

kann sein, die stimmen aber mit daten die ich vorliegen habe:cool:

gruss

[Gast]

und, teilst du diese Daten auch mit uns?

[Gast]

[QUOTE=AnarchX;6049326]

Aber irgendwie passen 4x 300 Mio. Tr. Kerne nicht ganz zu den Leistungsdaten, die ich vorliegen habe. :uponder:

QUOTE]

kann sein, die stimmen aber mit daten die ich vorliegen habe:cool:

gruss

lol

[Gast]

kann sein, die stimmen aber mit daten die ich vorliegen habe:cool:

gruss
Taucht in deinen Specs auch eDRAM?

[AnarchX]

Auch ohne Specs gibt es da ein logisches Problem:

3870 X2: 2x666M = 1333M für $399/499 vs R7xx High-End: 4x300M = 1200M für wohl >=$399

Dazu sollen ja die Einzelkerne weiterhin eigenständige GPUs sein laut Fuad, wodurch bei der 4-Kern-Lösung die Anzahl der redundanten Transistoren durch UVD/IO/Kontroll-Logik noch höher ist.

Ich bezweifele, dass der 4-Kern-Cluster viel schneller wäre als die 3870 X2 und somit High-End sein soll.

Aber das wird vielleicht Fuad demnächst klar stellen.

Auf jeden Fall scheint es 2008 wieder um einiges mehr Bewegung auf dem GraKa-Markt zu geben, nachdem es 2007 eher ruhig war... ;)

[laser114]

Also wenn enerell mit mehreren Chips geplant wird, dann hat man sich sicherlich auch eine Problemlösung zur Verringerung der Redundanz überlegt. Das gilt ja nicht nur für Chip-Teile sondern auch für z. B. den Speicher. Ein Steuerchip ist beim Low-End sicherlich zu teuer.

Vielleicht gibts zwei Dies, eins mit kompletten Features und ein weiteres mit möglichst wenig Redundanz, die man dann zusammenschalten kann - so dass man einmal das voll Die und sonst das andere braucht?

[w0mbat]

UVD ist NICHT in einem Core enthalten.

[Nakai]

Wieso macht mans nicht wie beim Xenos?

IO, UVD, SI und Onboardgrafik in einem Extrachip auf dem Package. Dann kann man nohc zusätzlich weitere andere Cores draufhaun.

mfg Nakai

[AnarchX]

IO, UVD, SI und Onboardgrafik in einem Extrachip auf dem Package. Dann kann man nohc zusätzlich weitere andere Cores draufhaun.

Da braucht wieder jeder Chip sein eigenes Tape-Out und man benötigt noch mehr wohl teure High-Speed-Pfade auf dem Package. Ich sehe da keinen wirklichen Sinn drin.

[Hvoralek]

ein RingBus 512bit SI bedeutet, das man nur die anbindung 1024 pins auf dem package braucht, richtig ?Du bräuchtest 2 512- bit- Anschlüsse an jedem einzelnen Chip (+ nochmal je 64 oder 128 bit, weil der VRAM ja auch irgendwo angeschlossen werden muss). > 1000 Datenleitungen an einen 70- mm²- Chip wären wohl technisch nicht machbar. Vorausgesetzt, der Chip ist halbwegs quadratisch. Wenn die R700er- Chips eher Stäbchenform haben sollten, könnte die Außenfläche natürlich reichen :D

[robbitop]

Im Gegensatz zum Speicher brauchts bei sowas jedoch keine Steuerleitungen. Mit einigermaßen brauchbaren Taktraten würden auch schon 256 Datenleitungen pro Richtung genügen.

Ich kann mir denoch schwer vorstellen, dass das ganze 4x auf einem Package passieren soll.

[AnarchX]

Ich kann mir denoch schwer vorstellen, dass das ganze 4x auf einem Package passieren soll.
4x (von dem was Fuad da beschreibt) dürfte bei dem, was man sich erhofft für die High-End-SKU, wohl nichtmal ausreichen. :|

Was gäbe es denn sonst noch für halbwegs brauchbare Konzepte um >=4 GPUs/Kerne bei entsprechender Skalierung zusammenarbeiten zu lassen, ohne eben alles auf einem Package zu haben und mit fetten Buses zu verbinden?

[reunion]

Was gäbe es denn sonst noch für halbwegs brauchbare Konzepte um >=4 GPUs/Kerne bei entsprechender Skalierung zusammenarbeiten zu lassen, ohne eben alles auf einem Package zu haben und mit fetten Buses zu verbinden?

Naja, die Kapazitäten auf dem Package werden sehr gering sein, das dürfte sehr hohe Taktraten erlauben. Wäre interessant zu wissen, wie viele bit die Verbindung bei Xenos hat.

Was ich auch noch erwähnen wollte:

http://img215.imageshack.us/img215/3589/filesh8.jpg (http://imageshack.us)

Falls sich daran nichts geändert hat, wird R700 wohl nicht in 45nm, sondern in 55nm kommen.

[AnarchX]

Naja, die Kapazitäten auf dem Package werden sehr gering sein, das dürfte sehr hohe Taktraten erlauben.
Möglich, aber hoffentlich setzt man nicht schon wieder alles auf die "Taktraten-Karte".


Wäre interessant zu wissen, wie viele bit die Verbindung bei Xenos hat.
http://img147.imageshack.us/img147/1927/bandwidthszo2.gif (http://www.beyond3d.com/content/articles/4/3)

Bei 32GB/s und wenn der IC auch mit den 500MHz von beiden Dies läuft, müsste es ja ein 256Bit IC sein oder?


Für 512 Bit bräuchte man, wenn man das Konzept des Ringbus von R6xx aufgreift aber wohl 1024Bit ICs auf dem Package:
http://img410.imageshack.us/img410/396/ringbusii2yw0.jpg

[laser114]

Falls sich daran nichts geändert hat, wird R700 wohl nicht in 45nm, sondern in 55nm kommen.

Schon Spider hat sich ja geändert. Auch das ist DX 10+ und die Produktbezeichnung passt auch nicht mehr. ;)

[w0mbat]

[...]
Falls sich daran nichts geändert hat, wird R700 wohl nicht in 45nm, sondern in 55nm kommen.

Auf dieser Folie wird noch die HD2900er für 2007 angegeben und mit Spider verbunden. Wie wir jetzt aber wissen ist die GPU bei Spider eine HD3800er. Also ist diese Folie nicht ganz korrekt und könnte also auch im Hinblick auf den R700 falsche Infos aufzeigen.

/edit: Zwei Dumme, ein Gedanke =)

[reunion]

Möglich, aber hoffentlich setzt man nicht schon wieder alles auf die "Taktraten-Karte".


:)
Bei entsprechend geringen Kapazitäten ist es keine Kunst, einen Bus sehr hoch zu taken, das kann man wohl kaum mit hohen Taktraten bei einem Siliziumchip vergleichen.



Bei 32GB/s und wenn der IC auch mit den 500MHz von beiden Dies läuft, müsste es ja ein 256Bit IC sein oder?

Wenn, dann ja. Nur sollte es IMO durchaus möglich sein den Bus zB mit 2Ghz zu takten und dadurch mit 64bit auszukommen. Ob das bei Xenos gemacht wurde, keine Ahnung.

[MadManniMan]

Der R700 würde dann aus 3 Chips bestehen: Ein SingleCore für Lowend (da sind 72mm² verdammt gut), einen Mainstreambeschleuniger mit 2 Cores und einen High-End Beschleuniger mit 4 Cores.

Inzwischen hat sich wohl eingebürgert, dass High-End ~2x Mainstream entspricht und wir von einer 4-Teilung ausgehen können: 1 Core Value, 2 Cores Mainstream, 3 Cores Performance, 4 Cores High-End ... wobei natürlich immer abzuwägen gilt, in wie fern bei einer jeweiligen Einheiten Verdopplung (1*2=2 ...*2=4) noch Platz für 3 Cores wäre, wo man doch auch viel über Taktraten machen kann.

Jedenfalls denke ich, dass High-End mit weniger als 2*Mainstream-Einheiten unwahrscheinlich ist.


Dass das Ganze weitaus effizienter als die aktuellen Dual-Chip-Konfigurationen sein wird, das steht für mich ausser Frage.

[BlackBirdSR]

UVD ist NICHT in einem Core enthalten.

Wäre eigentlich auch meine Vorstellung. Die einzelnen Kerne besitze zwar das Nötigste und relativ hohe Leistung, alle zusätzlichen Extras erledigt aber ein weiter Chip. Dieser ist dann egal wieviele Cores immer nur einmal auf dem Package enthalten.

Es macht wenig Sinn, 4 Kerne mit über 30% Redundanz auf den Träger zu knallen. SUN ging sogar so weit, eine FPU zwischen allen Niagara-Kernen zu teilen.

Jetzt stellt sich nur die Frage ob es wirtschaftlicher ist den zusätzlichen Chip zu entwickeln und zu fertigen.

[SavageX]

Die einzelnen Kerne besitze zwar das Nötigste und relativ hohe Leistung, alle zusätzlichen Extras erledigt aber ein weiter Chip. Dieser ist dann egal wieviele Cores immer nur einmal auf dem Package enthalten.


Die Frage ist, ob "das Nötigste" nicht bereits ausreicht. Mich würde es nicht wundern, wenn für die ganze Videobeschleunigung einfach ein Satz Shaderprogramme erstellt wird, statt noch eine eigene Einheit in Silizium zu gießen.

[2B-Maverick]

Wäre eigentlich auch meine Vorstellung. Die einzelnen Kerne besitze zwar das Nötigste und relativ hohe Leistung, alle zusätzlichen Extras erledigt aber ein weiter Chip. Dieser ist dann egal wieviele Cores immer nur einmal auf dem Package enthalten.

Es macht wenig Sinn, 4 Kerne mit über 30% Redundanz auf den Träger zu knallen. SUN ging sogar so weit, eine FPU zwischen allen Niagara-Kernen zu teilen.

Jetzt stellt sich nur die Frage ob es wirtschaftlicher ist den zusätzlichen Chip zu entwickeln und zu fertigen.

Ich denke mal es ist besser 2 Chips zu fertigen (1x kompletter Chip mit UVD und 2D Schnick-Schnack und 1x 3D-Zusatz Chip nur mit Shadern etc.) als 3 Chips (RV 610/630/670 plus evtl. 680).
Zumal hierbei evtl. ja bei einer neuen Generation nur der 3D-Chip erneuert werden müsste.

[MadManniMan]

Die Frage ist, ob "das Nötigste" nicht bereits ausreicht. Mich würde es nicht wundern, wenn für die ganze Videobeschleunigung einfach ein Satz Shaderprogramme erstellt wird, statt noch eine eigene Einheit in Silizium zu gießen.

Ich kann mir auch vorstellen, dass diese Herangehensweise eine neue Flexibilität mit sich bringen könnte - so dass aufm Desktop quasi ein Core per Shader Videos beschleunig etc. ...

[SavageX]

Mein Tipp für die "wie verbinde ich die einzelnen Chips breitbandig untereinander":

Man belichte gleich 4 Cores als einen Chip - passend mit den Verbindungen. Und dann säge man sich die kleineren Cores aus dem größeren Stück heraus, wenn z.B. einer der Cores defekt ist.

Natürlich müssen die Cores allerdings dann auch so entworfen sein, dass man die siamesischen Vierlinge funktionstüchtig trennen kann.

[GeneralHanno]

man will doch WEG von den riesendice und eine riesendie mit all ihren nachteilen zu fertigen, um sie dann zu zerschneiden halte ich für unwahrscheinlich.

[Coda]

Gibt's doch schon Ewigkeiten. Den defekten Teil lässt man zwar dran, aber ansonsten ist das deaktivieren von Funktionsblöcken genau das gleiche.

[Henroldus]

Mein Tipp für die "wie verbinde ich die einzelnen Chips breitbandig untereinander":

Man belichte gleich 4 Cores als einen Chip - passend mit den Verbindungen. Und dann säge man sich die kleineren Cores aus dem größeren Stück heraus, wenn z.B. einer der Cores defekt ist.
Natürlich müssen die Cores allerdings dann auch so entworfen sein, dass man die siamesischen Vierlinge funktionstüchtig trennen kann.
es ist nicht möglich EINEN chip aus einer 2x2 DIE Matrix herauszusägen ;)
es wird immer der komplette wafer entlang der chipzwischenräume gesägt

[AnarchX]

Wenn dann gäbe es wohl nur Dies mit 2*n Kernen, Fuad erzählt in der neuesten Meldung auch etwas von 6 Kernen für High-End.

An sich schon eine interessante Idee, aber so recht glaube ich eher nicht daran.

[OBrian]

Wäre ein UVD auf allen Chip wirklich eine überflüssige Redundanz? Bzw. könnte man deren Funktion ebenfalls über CF (oder wie auch immer) koppeln, so daß z.B. eine R700-Einzelkarte für "klein"formatige HD-Wiedergabe reicht, für große Formate dann die R700-Doppelkarte her muß? Und könnte man den UVD auch für etwas anderes nutzen, im 3D- oder GPGPU-Bereich?

Nimmt der überhaupt so viel Platz weg? Immerhin wurde RV670 ggü. R600 deutlich kleiner trotz hinzugefügtem UVD, weggefallen ist ja "nur" die Hälfte des Speicherinterfaces. Wenn das kaum ins Gewicht fällt, wären die ungenutzten Transistoren vielleicht tatsächlich ökonomisch sinnvoller als zwei verschiedene Chips (einer mit und einer ohne UVD).

[AnarchX]

Imo macht UVD mit sein 4.7mm² @65nm wohl eher nicht viel aus, das sind Sheduler und Co. wohl eher ein Problem bei der Redundanz.

[GeneralHanno]

Wenn ATi es hinkriegt einen Treadprozessor bzw. Scheduler zu designen, die VIER Kerne (genauer dice) gleichmäßig auslastet, dann haben sie meinen Respekt.

hier nochmal die Links zu den Fudzi News:
http://www.fudzilla.com/index.php?option=com_content&task=view&id=4369&Itemid=34
http://www.fudzilla.com/index.php?option=com_content&task=view&id=4368&Itemid=34
http://www.fudzilla.com/index.php?option=com_content&task=view&id=4365&Itemid=34
http://www.fudzilla.com/index.php?option=com_content&task=view&id=4367&Itemid=34

Leistung 2 Tera-Flop

[Gast]

ich hoffe auf 50% mehr FPS in akt. Spielen gegenüber der 8800gtx.Mehr wirds wohl kaum werden

[AnarchX]

ich hoffe auf 50% mehr FPS in akt. Spielen gegenüber der 8800gtx.Mehr wirds wohl kaum werden

Auf jeden Fall scheint es 2008 wieder um einiges mehr Bewegung auf dem GraKa-Markt zu geben, nachdem es 2007 eher ruhig war... ;)
:D

Ailuros deutete ja auch schonmal darauf hin, dass wohl 1 TFLOPs für NVs nächste richtige High-End-SKU nicht ganz/bei weitem nicht ausreichen und diese ist auch 2008 zu erwarten.

Ob wohl beide sich fürchten, was Intel Ende 2008 loslassen könnte? ;)

[Gast]

Ob wohl beide sich fürchten, was Intel Ende 2008 loslassen könnte? ;)


http://www.forum-3dcenter.org/vbulletin/images/icons/icon10.gif

[Aquaschaf]

Ob wohl beide sich fürchten, was Intel Ende 2008 loslassen könnte? ;)

Ich denke dazu haben sie keinen Grund. Überraschen lasse ich mich aber gerne ;)

[Ailuros]

Wenn ATi es hinkriegt einen Treadprozessor bzw. Scheduler zu designen, die VIER Kerne (genauer dice) gleichmäßig auslastet, dann haben sie meinen Respekt.


Leistung 2 Tera-Flop

Damit das Ganze aber auch wirklich Sinn macht, muesste jegliches multi-threading bzw. scheduling in jedem einzelnen chip naeher am Optimum liegen.

Ich moechte ja gerne zu 100% falsch liegen aber R700 klingt mir bis jetzt nicht nach irgend einem besonderem Resourcen-Aufwand.

[Ailuros]

:D

Ailuros deutete ja auch schonmal darauf hin, dass wohl 1 TFLOPs für NVs nächste richtige High-End-SKU nicht ganz/bei weitem nicht ausreichen und diese ist auch 2008 zu erwarten.

Ob wohl beide sich fürchten, was Intel Ende 2008 loslassen könnte? ;)

IMHLO: keine Ahnung was Intel fuer eigen-entwickelte Bananen loslaesst, aber ausser sehr speziellen Maerkten wird Intel keine besondere Bedrohung fuer beide sein.

Benutzt aber Intel letztendes irgend etwas aus dem IMG Beutel fuer IGPs oder sogar billigscheiss standalone wasauchimmer, muessen sich dann doch beide wohl Sorgen machen was das Preis-/Leistungs-/Stromverbrauch- Verhaeltnis betrifft.

[Ailuros]

Relevante Debatte bei B3D fuer diejenigen die sie noch nicht gelesen haben:

http://forum.beyond3d.com/showthread.php?t=41377&page=7

[StefanV]

Momentmal:

Braucht man die 'Inter Die' Communikation überhaupt oder reicht nicht auch 'nen schnellen, schmalen Bus zu haben, der die Aufgaben Verteilt und das ganze am Ende wieder zurückholt??

Soo viel Komunikation dürft man also auch nicht brauchen, nur das zu berechnende und das Ergebnis, da sollt 'nen HT Link oder so ausreichend sein...

[Ailuros]

Momentmal:

Braucht man die 'Inter Die' Communikation überhaupt oder reicht nicht auch 'nen schnellen, schmalen Bus zu haben, der die Aufgaben Verteilt und das ganze am Ende wieder zurückholt??

....und die Daten wandern im einen Fall mit X Durchbruch "off chip" und mit =/>X*100 Durchbruch "on chip"?

Anders gefragt: wenn es so einfach waere warum haben wir heute nicht zich zusammengeschleusste cores auf einem die, sondern stattdessen eine hohe Anzahl von clusters?

Soo viel Komunikation dürft man also auch nicht brauchen, nur das zu berechnende und das Ergebnis, da sollt 'nen HT Link oder so ausreichend sein...

HT fuer hyperthreading? Hyperthreading ist ja nur ein idiotische Bezeichnung fuer den CPU Markt um das anzuwenden was GPUs schon seit ihrer Geburt eingebaut hatten.

[Stormscud]

Stefan meint wohl eher HyperTransport ;)

[StefanV]

Genau, HT war schon immer Hyper Transport, Hyper Threading war schon immer HTT ;)

[SavageX]

man will doch WEG von den riesendice und eine riesendie mit all ihren nachteilen zu fertigen, um sie dann zu zerschneiden halte ich für unwahrscheinlich.

normale Riesendice kann man nicht zerschneiden. Bei dem Ansatz, gleich vier Kerne als eine Einheit zu belichten (und durchzuverbinden) hat man noch alle Optionen offen.

Im Endeffekt belichtet man ja sowieso einen Riesenflatschen Silizium und es kommt nur darauf an, wie viele Stücke man herausschneiden kann.

es ist nicht möglich EINEN chip aus einer 2x2 DIE Matrix herauszusägen ;)
es wird immer der komplette wafer entlang der chipzwischenräume gesägt

Zumindest aber kannst Du schonmal pro Wafer entscheiden, ob du 2x2, 2x1 oder 1x1 brauchst.

Würde mich nicht schocken, wenn man auch nachträglich noch 2x2 oder 2x1 weiterverkleinern könnte. Dafür bräuchte man allerdings Anlagen, die nicht nur Standardwafer zerschneiden können. Keine Ahnung, ob sowas im Einsatz ist, aber hier könnte es tatsächlich hapern.

[robbitop]

Es braucht richtig fette Busse. Allein schon wegen der gemeinsamen VRAM Nutzung. Dann kommt natürlich noch die Verteilung der Aufgaben hinzu. Ich könnte mir vorstellen, dass erstmal der Treiber das zu rendernde Bild in Segmente aufteilt und von den 4 GPUs rendern läßt. Soetwas wie Supertiling könnte man dann nutzen. Da alle auf den gleichen VRAM zugreifen könnten, wäre die Methode dann extrem kompatibel.
Noch besser wäre, wenn es wie ein einziger Chip fungieren würde. Dann müßte ein Chip den Arbiter/Dispatcher darstellen. Dementsprechend hat man natürlich auch Redundanz in der Fertigung und noch einen höheren Interconnect-Bandbreitenbedarf.

Je höher der Chiptakt und je weiter die Generation, desto mehr steigt der Bedarf an Interconnect-Bandbreite. Verdrahtungen sind keine Halbleiter, können also nicht geshrinkt werden und haben weniger Potenziale (Kostensenkungen, Takterhöhungen) als Halbleiter.
Das könnte ein weiteres Problem sein.

[Gast]

Es braucht richtig fette Busse.

Wie schon mal gesagt IMHO nein. HT3 sollte reichen wenn so ein hypothetisches R700 Design aus max. 4 chips besteht.

Für eine R700-Grafikkarte die aus 4 kleineren Chips mit je einem 128bit Speicherinterface und 2 HT3 Links (pro Chip) besteht reicht das aus.

HT3 arbeitet max. mit 2600MHz + 32bit DDR. Das macht dann pro Chip max. 20.8GB/sec x 2 (da HT gleichzeitig senden und empfangen kann, steht zumindest bei wiki so drin) x 2 ( 2 HT3 Interfaces pro Chip) = 2 x 41,6GB/sec pro Chip. Für eine R700 Grafikkarte mit 4 Chips also max. 2x 83,2 GB/sec ( entspricht also in etwa 2 Ringbussen mit je 512bit und 1300MHz ). Selbst der Ringbus des R600 hatte weniger Leistung.

Das sollte vorerst reichen.


Manfred

[robbitop]

Mit "fett" meine ich nicht die Busbreite sondern die Bandbreite.

Was deine Bandbreitenrechnung angeht:

Sende und Empfangsbandbreite zu addieren ist quatsch. Es wird immer im Burst entweder gelesen oder geschrieben. Da addiert sich pro Takt kaum was.

Was die Leistung des Ringbusses beim R600 angeht: der perifere Ring muss ja bei weitem nicht alles an Kommunikation übernehmen. Das wäre bei einem Multicore anders.
Soweit ich weiß sind das 2 Richtungen mit je 512 bit breite bei 743 MHz. Da komme ich auf knapp 100 GiB/s. Ich hab jetzt mal mit der Nutzung von nur einer Taktflanke gerechnet. Es entzieht sich meiner Kenntnis ob man nicht sogar beide nutzt. Dann kann man die Bandbreite gleich nochmal verdoppeln.

Pro Richtung und Verbindung braucht es mindestens 100 GiB/sek. Also 2 Richtungen x 4 Verbindungen = 8 x 100 GiB/sek.

Und das bei kontinuierlich steigendem Bandbreitenbedarf (mit wechselnden GPU Generationen).
Ich wüßte nicht, dass bei Verdrahtungen ähnliche starke Entwicklungspotentiale wie bei Halbleitern vorliegen. Ergo: wenn es heute noch 100 GiB/s machbar sind, sind es nächstes Jahr denn auch 200 GiB/sek und übernächstes Jahr 400, 800, 1600 ...?

Ja...Diese Verbindungen heute irgendwie (mit viel Aufwand) hinzubekommen, wäre machbar. Keine Frage. Ob das preislich in einem Consumerprodukt geht? Das ist die Frage..
Geht das auch noch bei zukünftigen GPUs mit dem schnellen Wachsum an internen Bandbreitenhunger? das ist die andere Frage..

[Gast]

Diese Verbindungen heute hinzubekommen wäre machbar. Keine Frage. Ob das preislich in einem Consumerprodukt geht? Das ist die Frage..



Ich kann mich an dieselben Diskussionen erinnern bezüglich des 512bit Interface der HD29ooXT ^^

[Gast]

Was meint ihr, wann wird der R700 zu haben sein?

[Gast]

.

HT3 arbeitet max. mit 2600MHz + 32bit DDR. Das macht dann pro Chip max. 20.8GB/sec x 2 (da HT gleichzeitig senden und empfangen kann, steht zumindest bei wiki so drin) x 2 ( 2 HT3 Interfaces pro Chip) = 2 x 41,6GB/sec pro Chip. Für eine R700 Grafikkarte mit 4 Chips also max. 2x 83,2 GB/sec ( entspricht also in etwa 2 Ringbussen mit je 512bit und 1300MHz ). Selbst der Ringbus des R600 hatte weniger Leistung.

Das sollte vorerst reichen.


Manfred

Viel zu wenig, intern erreichen die GPUs weitaus höhere Datentransferraten als zum RAM hin. Generell ist doch das Problem das die Texturen jeder "GPU" zur Verfügung stehen müssen und somit viel RAM unnötig belegen. Der Treiber+Hardware kann sicher nicht ein komplettes Tiling vornehmen.
Ich Frage mich wie das funktionieren soll wenn man 4 kleine RV630 zu einer GPU zusammenschalten will. Wenn alles nur noch durch Arithmetik Einheiten berechnet wird (mit eingebauten TMUs und den rudimentären Funktionen der ROPs) hab ich viele 50mm² große "Die" die alle an einem Crossbar dann angestöpselt werden? Mit nem Ring (dens so ja gar nicht gibt) müssen die Dinger wieder untereinander Kommunizieren...

Riecht mir doch eher nach dem Prinzip den der Cell verfolgt, nur zerstückelt und auf GPU Basis eben.

[Ailuros]

Es braucht richtig fette Busse. Allein schon wegen der gemeinsamen VRAM Nutzung. Dann kommt natürlich noch die Verteilung der Aufgaben hinzu. Ich könnte mir vorstellen, dass erstmal der Treiber das zu rendernde Bild in Segmente aufteilt und von den 4 GPUs rendern läßt. Soetwas wie Supertiling könnte man dann nutzen. Da alle auf den gleichen VRAM zugreifen könnten, wäre die Methode dann extrem kompatibel.


Ich hab ernsthafte Zweifel dass es so einfach sein koennte; die erste Frage die mir in den Schaedel schiesst, ist was man genau mit der Geometrie anstellt wenn man auf hypothetische 4 macro tiles/viewports aufteilt.

http://forum.beyond3d.com/showthread.php?p=342652&highlight=super-tiling#post342652

Die Debatte ist zwar uralt (R4x0 timeframe), aber Du weisst dass arjan ein Falanx engineer ist und er macht ein paar ziemlich gute Punkte. Eric erklaert zwar wie sie bis dahin mit der Entwicklung vorgegangen sind, aber mich kann schwer jemand dazu ueberzeugen dass man mit solch einer Methode langfristig nicht zu einer Sackgasse kommen koennte wenn man zuviel Geometrie stellenweise wieder puffern muss.

Nebenbei wenn ich den ziemlichen alten Text hier nochmal durchlese:

Performance issues are still very texture fetch bound (cache efficiency, memory efficiency, filter types) in modern apps, as well as partially ALU/register allocation bound. There's huge performance differences possible depending on how your deal with texturing and texture fetches.

...frage ich mich ernsthaft auf was genau ATI's Design-Entscheidungen seit R3xx/4xx basiert wurden.

[Ailuros]

Ich kann mich an dieselben Diskussionen erinnern bezüglich des 512bit Interface der HD29ooXT ^^

Welches auch wirklich seine Unkosten wieder hereingeholt haette, wenn alles andere gestimmt haette. Wie ist der Standpunkt nun nach der RV670 Vorstellung?

[sklave_gottes]

Welches auch wirklich seine Unkosten wieder hereingeholt haette, wenn alles andere gestimmt haette. Wie ist der Standpunkt nun nach der RV670 Vorstellung?


Ich bin mal so frech und Frage, wenn was gestimmt Hätte:biggrin:(obwohl ich mir schon denken kann was du jetzt sagen wirst)

Zum Standpunkt: man sieht durch RV670 das ein 256Bit Bus mehr als gereicht hätte. Das hat mir schon von Anfang an gestunken, wieso r600 512bit hat. Zumal nach meiner Theorie: nur mehr TMUs da abhilfe geschaft hätten.

Und was gegen meine Theorie steht:
Das ATI schon vorher wuste das der r600 "nur" 16 TMUs hat, also wieso 512bit? Was haben die sich erhoft? Und nein ich glaube nicht das stärkere ROPs da abhilfe gebracht hätten.;)



Abwarten. Solange niemand Bandbreitenskalierungstest mit AA durchführt, sollten wir vorsichtig sein und das 512bit Speicherinterface zum Teufel zu wünschen.

LovesuckZ

in Re: AMDs 55nm GPUs: R680, RV670, RV660, RV635, RV620
vom 2007-10-19, 10:17:19
@LovesuckZ

http://www.computerbase.de/artikel/hardware/grafikkarten/2007/test_ati_radeon_hd_3870_rv670/5/#abschnitt_aa_und_af_skalierung

[robbitop]

Ich kann mich an dieselben Diskussionen erinnern bezüglich des 512bit Interface der HD29ooXT ^^
Und wie war die Marge auf dem Produkt? Schlecht bis ultra schlecht.

Ich hab ernsthafte Zweifel dass es so einfach sein koennte; die erste Frage die mir in den Schaedel schiesst, ist was man genau mit der Geometrie anstellt wenn man auf hypothetische 4 macro tiles/viewports aufteilt.

http://forum.beyond3d.com/showthread.php?p=342652&highlight=super-tiling#post342652

Die Debatte ist zwar uralt (R4x0 timeframe), aber Du weisst dass arjan ein Falanx engineer ist und er macht ein paar ziemlich gute Punkte. Eric erklaert zwar wie sie bis dahin mit der Entwicklung vorgegangen sind, aber mich kann schwer jemand dazu ueberzeugen dass man mit solch einer Methode langfristig nicht zu einer Sackgasse kommen koennte wenn man zuviel Geometrie stellenweise wieder puffern muss.

Nebenbei wenn ich den ziemlichen alten Text hier nochmal durchlese:



...frage ich mich ernsthaft auf was genau ATI's Design-Entscheidungen seit R3xx/4xx basiert wurden.

Guter Punkt. Das könnte man nur umgehen, wenn einer die GPUs der Arbiter wäre. Das bräuchte noch mehr Interconnect-Bandbreite dann.

[Ailuros]

Ich bin mal so frech und Frage, wenn was gestimmt Hätte:biggrin:(obwohl ich mir schon denken kann was du jetzt sagen wirst)

Die ROPs was sonst? :P

Zum Standpunkt: man sieht durch RV670 das ein 256Bit Bus mehr als gereicht hätte. Das hat mir schon von Anfang an gestunken, wieso r600 512bit hat. Zumal nach meiner Theorie: nur mehr TMUs da abhilfe geschaft hätten.

Bei R6x0/RV6x0 (und ja dazu gehoert auch die RV670) fehlt es nicht nur an TMUs. Bei all diesen sind die Z Fuellraten viel zu karg ausgefallen und natuerlich dass die Dinger praktisch nur auf single cycle 2xMSAA beschraenkt ist (wobei zugegeben ich auf einer G8x/9x oefters das Gefuehl habe dass sie sich genauso wie jegliche single cycle 2xAA HW verhalten, nur dass eben die monstroese Z Fuellrate hier kompensieren koennte).

Haette alles mit den ROPs gestimmt, wuerde der 256bit nicht als "ausreichend" erscheinen und eine R600 haette mit 4xAA eine G80 regelrecht zersaegen koennen.

Sowohl ATI als auch NVIDIA haben jeden TMU block quasi so "verschmelzt" dass dieser sich als weiterer SIMD zu jedem SIMD ALU block "parallelisiert". Wenn ATI einen chip mit 4 clusters aufs Kreideboard kritzelt, dann koennen es auch nie mehr als 4*4 TMU blocks werden. Fuer mehr TMUs haette ATI auch mehr clusters gebraucht, was aber unter der R6x0 Logik einen zu monstroesen chip bedeutet haette. Man haette eben noch mehr Abstand von dem originalen R400 Design nehmen sollen und mehr aber "schlankere" ALUs einzubauen.


Und was gegen meine Theorie steht:
Das ATI schon vorher wuste das der r600 "nur" 16 TMUs hat, also wieso 512bit? Was haben die sich erhoft? Und nein ich glaube nicht das stärkere ROPs da abhilfe gebracht hätten.;)

Man benutzt schon seit einige Jahren auf high end GPUs AF. AF braucht hauptsaechlich Fuellrate und AA hauptsaechlich Bandbreite. Willst Du Dir das Ganze nicht nochmal ueberdenken? ;)

[Gast]

Und wie war die Marge auf dem Produkt? Schlecht bis ultra schlecht.


Offensichtlich gut genug, um die Produkte im Preisbereich von 200-300€ zu verkaufen, sonst hätte man sich das gleich erspart.

reunion

[Gast]

Das ist keine logische Argumentation, denn man hätte noch viel mehr Verluste eingefahren, wenn man die Chips gar nicht verkauft hätte.

[Ailuros]

Offensichtlich gut genug, um die Produkte im Preisbereich von 200-300€ zu verkaufen, sonst hätte man sich das gleich erspart.

reunion

Gut genug um keinen Verlust abzuschreiben heisst die Realitaet und dabei vergisst Du natuerlich dass ATI zu dem Zeitpunkt zu einer gigantischen Mehrzahl immer noch Einnahmen von vorigen Generationen in mehreren Maerkten (Xenos inklusive) mitberechnet hatte.

Natuerlich haette man es sich ersparen koennen und sich ueber ein riesiges Loch in der Kasse von den R6x0 R&D Unkosten stolz zu sein.

[sklave_gottes]

Die ROPs was sonst? :P



Bei R6x0/RV6x0 (und ja dazu gehoert auch die RV670) fehlt es nicht nur an TMUs. Bei all diesen sind die Z Fuellraten viel zu karg ausgefallen und natuerlich dass die Dinger praktisch nur auf single cycle 2xMSAA beschraenkt ist (wobei zugegeben ich auf einer G8x/9x oefters das Gefuehl habe dass sie sich genauso wie jegliche single cycle 2xAA HW verhalten, nur dass eben die monstroese Z Fuellrate hier kompensieren koennte).

Haette alles mit den ROPs gestimmt, wuerde der 256bit nicht als "ausreichend" erscheinen und eine R600 haette mit 4xAA eine G80 regelrecht zersaegen koennen.

Sowohl ATI als auch NVIDIA haben jeden TMU block quasi so "verschmelzt" dass dieser sich als weiterer SIMD zu jedem SIMD ALU block "parallelisiert". Wenn ATI einen chip mit 4 clusters aufs Kreideboard kritzelt, dann koennen es auch nie mehr als 4*4 TMU blocks werden. Fuer mehr TMUs haette ATI auch mehr clusters gebraucht, was aber unter der R6x0 Logik einen zu monstroesen chip bedeutet haette. Man haette eben noch mehr Abstand von dem originalen R400 Design nehmen sollen und mehr aber "schlankere" ALUs einzubauen.




Man benutzt schon seit einige Jahren auf high end GPUs AF. AF braucht hauptsaechlich Fuellrate und AA hauptsaechlich Bandbreite. Willst Du Dir das Ganze nicht nochmal ueberdenken? ;)

Ich wuste doch das wieder die ROPs kommen ;D
nur wie gesagt bin ich da anderer Meinung unteranderem deswegen:

http://www.computerbase.de/artikel/hardware/grafikkarten/2007/test_ati_radeon_hd_3870_rv670/5/#abschnitt_aa_und_af_skalierung

Im schnitt verliert die 8800GTX trotz 86400 MB/s trotz 13800 MPix/s
mehr Leistung durch AA als die HD3870 72000 MB/s 12400 MTex/s
Die Z Fuellrate will ich hier mal absichtlich nicht vergleichen sonnst sieht es noch böser aus für die 8800GTX :wink:

und dabei ist es egal ob 2aa,4aa oder 8aa. Die HD3870 verliert immer weniger.
Mit 8aa ist der unterschied aber am Grösten.

In dem Link sieh man auch ganz deutlich was die HD3870 nicht so gut kann:
AF

@reunion

besser für 140€ verkaufen als wegschmeissen...


Edit
Kann mir das noch einer Erklären:
http://www.hardware.fr/articles/671-4/ati-radeon-hd-2900-xt.html
Ich sehe hier nur singel cycle 2xAA HW bei der X1950XTX oder blicke ich da nicht durch ?

[Ailuros]

Ich wuste doch das wieder die ROPs kommen ;D
nur wie gesagt bin ich da anderer Meinung unteranderem deswegen:

http://www.computerbase.de/artikel/hardware/grafikkarten/2007/test_ati_radeon_hd_3870_rv670/5/#abschnitt_aa_und_af_skalierung

Im schnitt verliert die 8800GTX trotz 86400 MB/s trotz 13800 MPix/s
mehr Leistung durch AA als die HD3870 72000 MB/s 12400 MTex/s
Die Z Fuellrate will ich hier mal absichtlich nicht vergleichen sonnst sieht es noch böser aus für die 8800GTX :wink:

Unter D3D9 und in 1600 mit 4xAA ist die GTX um 36.6% schneller als die 3870 und in D3D10 (1600+4xAA) um 41.6%:

http://www.computerbase.de/artikel/hardware/grafikkarten/2007/test_ati_radeon_hd_3870_rv670/28/#abschnitt_performancerating_qualitaet

Wenn ich mich nicht irre handelt es sich um den gleichen Review und einen Durchschnitt aller getesten Spiele. Ein theoretischer Vorsprung von X Prozent interpretiert sich nie in X Prozent mehr Leistung und schon gar nicht zwischen zwei so verschiedenen Architekturen.

Komischerweise hast Du Deine These nicht auf die AF Prozentuale Deines Links basiert, wobei hier auch die GTX mehr Leistung mit AF als die 3870 zu verlieren scheint. Wenn man alle Optimierungen auf default laesst wundert mich dieses Resultat sowieso kein bisschen. Es waere wohl doch interessanter wenn man auf den Radeons alle AF Optimierungen abschalten koennte ohne dass nicht AF- relevante Optimierungen abgeschaltet werden.

Und nein es geht hier nicht wieder um ein endloses "wer optimiert mehr" Quark sondern eher darum dass es einer jeglichen G8x/9x eigentlich scheissegal sein koennte ob man optimiert oder nicht; und dass natuerlich stets im Vergleich zu jeglicher voriger G7x und auch allen anderen GPUs mit zu wenig TMUs.

Irgend etwas handfesteres um die "R6x0 hat zu wenig TMUs aber genuegend ROPs" These zu unterstuetzen?

Hier nochmal der gleiche Link:

http://www.hardware.fr/articles/671-4/ati-radeon-hd-2900-xt.html

Die resultierende Z fuellraten kannst Du wohl mit und ohne AA sehen; und falls der Groschen endlich faellt ist R5x0 taktnormalisiert staerker mit dem Zeug als R6x0. So und jetzt blaetter mir mal die naechsten Seiten mit echten Leistungszahlen von Spielen mit AA nochmal nach und erklaer mir warum in aelteren Spielen die R600 einen relativ kleinen Abstand von einer R580 hat.



In dem Link sieh man auch ganz deutlich was die HD3870 nicht so gut kann:
AF

Dann bin ich wohl blind :P

Nur in FEAR hat die GTX hier einen Vorsprung. Du benutzt die falschen Mittel mon ami ;)

[sklave_gottes]

Unter D3D9 und in 1600 mit 4xAA ist die GTX um 36.6% schneller als die 3870 und in D3D10 (1600+4xAA) um 41.6%:

http://www.computerbase.de/artikel/hardware/grafikkarten/2007/test_ati_radeon_hd_3870_rv670/28/#abschnitt_performancerating_qualitaet

Wenn ich mich nicht irre handelt es sich um den gleichen Review und einen Durchschnitt aller getesten Spiele. Ein theoretischer Vorsprung von X Prozent interpretiert sich nie in X Prozent mehr Leistung und schon gar nicht zwischen zwei so verschiedenen Architekturen.

Komischerweise hast Du Deine These nicht auf die AF Prozentuale Deines Links basiert, wobei hier auch die GTX mehr Leistung mit AF als die 3870 zu verlieren scheint. Wenn man alle Optimierungen auf default laesst wundert mich dieses Resultat sowieso kein bisschen. Es waere wohl doch interessanter wenn man auf den Radeons alle AF Optimierungen abschalten koennte ohne dass nicht AF- relevante Optimierungen abgeschaltet werden.

Und nein es geht hier nicht wieder um ein endloses "wer optimiert mehr" Quark sondern eher darum dass es einer jeglichen G8x/9x eigentlich scheissegal sein koennte ob man optimiert oder nicht; und dass natuerlich stets im Vergleich zu jeglicher voriger G7x und auch allen anderen GPUs mit zu wenig TMUs.

Irgend etwas handfesteres um die "R6x0 hat zu wenig TMUs aber genuegend ROPs" These zu unterstuetzen?

Hier nochmal der gleiche Link:

http://www.hardware.fr/articles/671-4/ati-radeon-hd-2900-xt.html

Die resultierende Z fuellraten kannst Du wohl mit und ohne AA sehen; und falls der Groschen endlich faellt ist R5x0 taktnormalisiert staerker mit dem Zeug als R6x0. So und jetzt blaetter mir mal die naechsten Seiten mit echten Leistungszahlen von Spielen mit AA nochmal nach und erklaer mir warum in aelteren Spielen die R600 einen relativ kleinen Abstand von einer R580 hat.



Dann bin ich wohl blind :P

Nur in FEAR hat die GTX hier einen Vorsprung. Du benutzt die falschen Mittel mon ami ;)

Ja, nimm den selben CB link und sieh unter 1600+8xAA stadt 1600+4aa nach. Plötzlich wird aus dem Vorsprung der GTX von 37% ein Rückstand von 2%

Und jetzt sag nicht der GTX geht der Ram aus :tongue:

Und um nochmal den vorsprung der GTX bei 1600+4xAA zu klären:
Da wurde auch durchgehend mit 16AF getestet, und da verliert der RV670 seh stark gegenüber dem g80. Zumal bei dem Ratting mit aa/af viele Spiele nur mit AF drin sind da AA oft nicht funktioniert. Gothic 3 oder Stalker z.b.
eher kann man einen Vergleich zwischen 8aa und 4aa machen bei 16AF und da verliert der G80 weit mehr als der RV670. Wie kannst du das erklären ?

Zum thema r580 vs r600 und den Z fuellraten.
Ich sehe nur das der r600 fast doppelt soviel hat bei 1aa wie der r580.
bei 2aa halbieren sich die Z fuellraten beim r600 und beim r580 ist sie annähernd konstand. Somit sind beide etwa gleich auf. Wenn man die Werte Taknormalisiert kommen beide etwa auf die selben Werte meiner meinung nach, mit bissel verschnitt. Ich meine wenn man Die ROH daten der 8800gtx mit 8800gts vergleicht ist die 8800gts bei selber anzahl und Taktnormalisiert auch leicht vorne.

Das der r600 manchmal noch nicht mal seinen 14% taktvorteil ausspielen kann ist allerdings echt Blöde. Aber man muss auch zugeben das der r580@XTX ein sehr Starker Chip ist, dem sogar laut CB der g80@GTS@320 kaum gewachsen ist.

Das im r600 noch etwas ist das nicht ganz so läuft wie man wollte ist klar. Nur sehe ich keinen Grund alles auf die ROPs zu schieben. Denn mit aa geht der r600 sowie der RV670 ab wie schmitz Katz:P

[Gmax]

Angeblich soll der R7oo noch eine Ecke weniger Strom verbrauchen.

AMD Pressekonferenz Video:

http://blip.tv/file/161810

Circa bei 10 Minuten.

[J0ph33]

von wann ist das? kurz vor R600-launch? hab's nur nebenbei laufen lassen...

Orton sitzt nämlich noch da und sieht irgendwie gar nicht glücklich aus...

[Gmax]

Stimmt, vom 5. März.

[J0ph33]

somit glaube ich, dass sie mit dem gequatsche um die 10. Minute wohl auch eher den RV670 meinen...

[Gmax]

somit glaube ich, dass sie mit dem gequatsche um die 5. Minute wohl auch eher den RV670 meinen...

Er erwäht aber genau bei 8min53 sek den 7ooer und dessen verminderten Stromverbrauch :wink:

[AnarchX]

Gegenüber was? Der R600XTX mit 270W TDP?:D

[K4mPFwUr$t]

auf so ein marketing geblubber würde ich keinen wert legen.
beim r600 hieß es ja auch super schnell...

[Gmax]

auf so ein marketing geblubber würde ich keinen wert legen.
beim r600 hieß es ja auch super schnell...

Stimmt ja auch, bei folding@home und 3d Anwendungen wie 3dsmax :biggrin:

[Ailuros]

Ja, nimm den selben CB link und sieh unter 1600+8xAA stadt 1600+4aa nach. Plötzlich wird aus dem Vorsprung der GTX von 37% ein Rückstand von 2%

Und jetzt sag nicht der GTX geht der Ram aus :tongue:

Dass der Speicher auslaeuft ist eher unwahrscheinlich. Wie schon erwaehnt verhalten sich die G8x/9x komischerweise mit AA in etwa wie alle anderen single cycle 2xAA Architekturen. Hier sollten theoretisch 2 cycli vs. 4 cycli keinen Vorsprung fuer den zweiten Fall geben. Haette ich eine Antwort fuer die Frage fuer ueber ein Jahr jetzt schon bekommen wuesste ich auch was los sein koennte. Keine Antwort heisst entweder dass man irgend etwas nicht zugestehen will oder dass das Treiberteam einfach keine zusaetzliche Zeit dafuer opfern will.

Und um nochmal den vorsprung der GTX bei 1600+4xAA zu klären:
Da wurde auch durchgehend mit 16AF getestet, und da verliert der RV670 seh stark gegenüber dem g80.

Bei den 3 AF Skalierungtests:

1600*1200

CoH D3D10:

3870 -57,1%
8800GTX -53,5%

FEAR:

3870 -34%
8800GTX -48%

JERICHO:

3870 -32,6%
8800GTX -32,6%

Entweder Gleichstand oder ein Unterschied bis zu 14% in 3 Tests und so radikal wird sich im Durchschnitt aller verwendeten Spiele auch nichts aendern mit all dem was AMD am Algorithmus getrieben hat.


Zumal bei dem Ratting mit aa/af viele Spiele nur mit AF drin sind da AA oft nicht funktioniert. Gothic 3 oder Stalker z.b.

Gothic und ueberhaupt Stalker sind so verdammt abhaengig von der Z/stencil Fuellrate dass Du es gar nicht erwaehnen solltest.

Ein rein stencil Fuellraten limitierter (synthetischer) Test ist Fablemark:

http://www.computerbase.de/artikel/hardware/grafikkarten/2007/test_ati_radeon_hd_3870_rv670/10/#abschnitt_theoretische_benchmarks


Zum thema r580 vs r600 und den Z fuellraten.
Ich sehe nur das der r600 fast doppelt soviel hat bei 1aa wie der r580.
bei 2aa halbieren sich die Z fuellraten beim r600 und beim r580 ist sie annähernd konstand. Somit sind beide etwa gleich auf. Wenn man die Werte Taknormalisiert kommen beide etwa auf die selben Werte meiner meinung nach, mit bissel verschnitt. Ich meine wenn man Die ROH daten der 8800gtx mit 8800gts vergleicht ist die 8800gts bei selber anzahl und Taktnormalisiert auch leicht vorne.

Schau Dir mal die Fablemark Leistung mit 4xAA genauer an und vergleiche R580 mit R600/RV670.

Das merkwuerdige hier ist die 7900GTX Leistung im Vergleich zu jeglicher G80; zugegeben das demo ist auch ziemlich alt und wollte nur eine Doom3-aehnliche engine quasi nachmachen, aber da hier nur 4z/stencil verwendet wurde, koennte es eventuell den zu kleinen Unterschied zwischen G7x und G8x erklaeren, aber leider nicht zwischen R5x0 und R6x0.

Eine weitere Wahrheit ist aber auch dass Stencil-limitierende Spiele ala Doom3, Stalker und co. langsam am aussterben sind. Wehe aber wenn irgend ein zukuenftiges Spiel auf MRTs beruhen sollte mit einer gesunden Anzahl an Lichtern und Gott Hilf noch MSAA unter =/>D3D10.

Das der r600 manchmal noch nicht mal seinen 14% taktvorteil ausspielen kann ist allerdings echt Blöde. Aber man muss auch zugeben das der r580@XTX ein sehr Starker Chip ist, dem sogar laut CB der g80@GTS@320 kaum gewachsen ist.

Das im r600 noch etwas ist das nicht ganz so läuft wie man wollte ist klar. Nur sehe ich keinen Grund alles auf die ROPs zu schieben. Denn mit aa geht der r600 sowie der RV670 ab wie schmitz Katz:P

Ich schiebe NICHT alles auf die ROPs, da versteht Du mich falsch. Ich sage lediglich dass AMD die fehlende AF Fuellrate durch Optimierungen in der groessten Mehrzahl kompensieren kann, bei AA kann man aber nichts aehnliches anwenden. Und ich komm jetzt auch nicht mit irgend einer doofer These dass AMD bei 8xAA schummelt, denn ich traue zumindest den Seiten die damit getestet haben dass sie das Zeug auch ausfuehrlich getestet haben bevor es zu Leistungsnummern kam.

R6x0/RV6x0 haben sowohl problematische ROPs als auch zu wenig TMUs. Ohne eine handhafte Erklaerung fuer die zu kleinen 8xAA Unterschiede zwischen den beiden Familien die auch Sinn machen wuerde, lass ich die Finger davon weg.

Ganz am Rand hat NVIDIA eine sehr lange Geschichte und sogar gute Erfolge mit einem leichten "Missgebrauch" diverser Einheiten; es wuerde mich kein bisschen wundern wenn sie irgend etwas merkwuerdiges mit der Uebermenge an TMUs im geheimen anstellen. Klingt zwar etwas sci-fi, aber sooo unwahrscheinlich fuer rein arithmetischen Schnickschnack koennte es auch gar nicht sein.

Es waere zumindest interessant wenn sich ein erfahrener Reviewer hinhocken wuerde und etwas tiefer in Qualitaetsvergleiche greifen wuerde. Nur wenn jemand alle AF Optimierungen bei beiden abschalten wuerde (man muss aber den AI Mist wirhabenalleOptimierungenhierdrin im Hinterkopf behalten), wuerde es teilweise klar werden warum man durch die AF Optimierungen keine so grossen Unterschiede verspueren kann. Mit einer rein synthetischen Applikation die ich selber getestet hatte (und da steckt wohl keine nicht AF relevante Optimierung in AI) verliert eine G80 von Q auf HQ knapp 17% und eine R600 fast 50%.

[HOT]

Wobei der AI Off Schalter klammheimlich verändert wurde meiner Meinung nach. Seit 7.9 oder 7.10 kostet AI Off so gut wie keine Performance mehr. Er deaktiviert also höchstens einige AF Optimierungen, aber Spieleoptimierungen z.B. scheinen weiterhin aktiv zu bleiben.
Bin seit Cata7.10 dazu übergegangen AI auf off zu stellen und der Cata7.10 ist dennoch erstaunlicherweise weit schneller bei vielen Games (z.B. FEAR) als die Treiber davor mit meiner X1900XTX.
Wird also echt Zeit, dass sich mal einige Reviewer um die Qualitätskiller kümmern und mal einige Fragen kären ;).

[Gast]

Wobei der AI Off Schalter klammheimlich verändert wurde meiner Meinung nach. Seit 7.9 oder 7.10 kostet AI Off so gut wie keine Performance mehr. Er deaktiviert also höchstens einige AF Optimierungen, aber Spieleoptimierungen z.B. scheinen weiterhin aktiv zu bleiben.


Er deaktiviert leider auch keine AF-"Optimierungen" mehr.

[HOT]

Er deaktiviert leider auch keine AF-"Optimierungen" mehr.
Etwas muss er deaktivieren ;).

[Gast]

Er deaktiviert leider auch keine AF-"Optimierungen" mehr.
Auf R580 und älter schon.

[Ailuros]

Wobei der AI Off Schalter klammheimlich verändert wurde meiner Meinung nach. Seit 7.9 oder 7.10 kostet AI Off so gut wie keine Performance mehr. Er deaktiviert also höchstens einige AF Optimierungen, aber Spieleoptimierungen z.B. scheinen weiterhin aktiv zu bleiben.
Bin seit Cata7.10 dazu übergegangen AI auf off zu stellen und der Cata7.10 ist dennoch erstaunlicherweise weit schneller bei vielen Games (z.B. FEAR) als die Treiber davor mit meiner X1900XTX.
Wird also echt Zeit, dass sich mal einige Reviewer um die Qualitätskiller kümmern und mal einige Fragen kären ;).

Oder jemand hat einfach vergessen den switch im Treiber fuer AI off einzulegen.

[Gast]

Wobei der AI Off Schalter klammheimlich verändert wurde meiner Meinung nach. Seit 7.9 oder 7.10 kostet AI Off so gut wie keine Performance mehr. Er deaktiviert also höchstens einige AF Optimierungen, aber Spieleoptimierungen z.B. scheinen weiterhin aktiv zu bleiben.
Bin seit Cata7.10 dazu übergegangen AI auf off zu stellen und der Cata7.10 ist dennoch erstaunlicherweise weit schneller bei vielen Games (z.B. FEAR) als die Treiber davor mit meiner X1900XTX.
Wird also echt Zeit, dass sich mal einige Reviewer um die Qualitätskiller kümmern und mal einige Fragen kären ;).
Hast du denn auch mal die Bildquali verglichen? AI on ist ja sehr selten das gelbe vom Ei und AI off brachte in den meisten Games eine sichtbare Qualitätsverbesserung, natürlich nur, wenn man auch auf die brisanten Stellen schaut. Da würde mich der so gut wie nichtvorhandene Performanceverlust stutzig machen und mal genauer hinschauen. Sonst verkommt der AI Schalter zu einem psychologischen Moment, nach dem Motto, jetzt gibt's beste Bildqualität und in Wirklichkeit flimmerts trotzdem munter vor sich hin aber Hauptsache AI off, denn das ist gut für das Gewissen. Kann ja nicht Sinn der Sache sein.

[deekey777]

...
Gothic und ueberhaupt Stalker sind so verdammt abhaengig von der Z/stencil Fuellrate dass Du es gar nicht erwaehnen solltest.
...
STALKER?

[AnarchX]

http://img338.imageshack.us/img338/1438/1165556snap11d4614of0.jpg
http://www.pconline.com.cn/diy/guide/scfx/0712/1171897.html

Scheint an den 1.9 TFLOPs wohl doch mehr dran zu sein. ;)

[Gast]

http://img338.imageshack.us/img338/1438/1165556snap11d4614of0.jpg
http://www.pconline.com.cn/diy/guide/scfx/0712/1171897.html

Scheint an den 1.9 TFLOPs wohl doch mehr dran zu sein. ;)

Verstehe nur chinesisch;). Aus welchem Test stammt die Grafik?

[Argoth]

Scheint an den 1.9 TFLOPs wohl doch mehr dran zu sein. ;)

Aye caramba!

Also wenn sich das immer mehr bestätigt, dann wird's bei mir doch kein 3870 CF verbund, sondern nur eine einzelne Karte die dann ausgetauscht wird :rolleyes:

[K4mPFwUr$t]

naja mal schauen was davon in games übrig bleibt. der r600 ist ja laut amd auch ein ganz fixer wenn es um sollche werte geht.

[AnarchX]

naja mal schauen was davon in games übrig bleibt. der r600 ist ja laut amd auch ein ganz fixer wenn es um sollche werte geht.

Momentan sieht es aber eher danach aus, dass AMD diesmal aus weniger mehr machen wird. :D

Fragt sich nur was AMD für die fast 2 TFLOPs verlangen wird...

[Gast]

Ich stell mir eher die Frage wie es um die Texturleistung steht... 2 TFLOP und 16GTexel lol

[Gast]

Naja, wenn die neue Karte vier mal so schnell wird wie die alte, dann kann AMD ja vielleicht doch gegen NV überleben. :)

[J0ph33]

mmmh...schon Quad-CF wird die gleichen TFlop-Zahlen haben...

[Gmax]

Naja, wenn die neue Karte vier mal so schnell wird wie die alte, dann kann AMD ja vielleicht doch gegen NV überleben. :)

Aber nur wenn sie bald kommt, Gerüchten zufolge kommt die nV 9xxx schon im Februar....

Edit: Paßt vielleicht zum R7oo: GPGPU developer Houston recruited by AMD? (http://www.fudzilla.com/index.php?option=com_content&task=view&id=4515&Itemid=1)

[Gast]

Aber nur wenn sie bald kommt, Gerüchten zufolge kommt die nV 9xxx schon im Februar....
Dieser werden aber nur mickrige 1 TFlop nachgesagt. Keine Konkurrenz für eine 2 TFlop Karte. :)

[K4mPFwUr$t]

@gast
nur komisch das eine mickrige (g80) gpu eine nicht mickrige (r600) gpu zersägt hat.
zumal ich da nicht soviel drauf geben.

[Nakai]

@gast
nur komisch das eine mickrige (g80) gpu eine nicht mickrige (r600) gpu zersägt hat.
zumal ich da nicht soviel drauf geben.

Inwiefern mickrig?


mfg Nakai

[Gmax]

Von der Rechenpower soll doch der R6oo schneller gewesen sein als der G8o und totzdem ist dieser in Spielen schneller. Da wir aber mit dem R7oo vielleicht eine völlig neue Architektur serviert bekommen, könnte sich die hohe TFLOP Leistung diesmal auch dort positiv bemerkbar machen . *Daumen drück*

[Nakai]

Von der Rechenpower soll doch der R6oo schneller gewesen sein als der G8o und totzdem ist dieser in Spielen schneller. Da wir aber mit dem R7oo vielleicht eine völlig neue Architektur serviert bekommen, könnte sich die hohe TFLOP Leistung diesmal auch dort positiv bemerkbar machen . *Daumen drück*

Rechenleistung ist mir wurscht. Mir geht es nur um Yields, Diegröße und das was hinten rauskommt.

Der R600 war kleiner als G80, die Yields würd ich für den R600 etwas besser schätzen. Beim hinten rauskommen war der G80 ganz klar besser.


mfg Nakai

[K4mPFwUr$t]

die yield wird beim r700 recht hoch sein. da man statt einer komplexen GPU nur noch sehr viele mini GPUs haben wird. vorteil hiervon ist die hohe yield. nur wie man ein zusammenkoppeln am besten realisieren will. hmm, lassen wir uns überraschen.

[mapel110]

http://img338.imageshack.us/img338/1438/1165556snap11d4614of0.jpg
http://www.pconline.com.cn/diy/guide/scfx/0712/1171897.html

Scheint an den 1.9 TFLOPs wohl doch mehr dran zu sein. ;)
Warum soll es jetzt schon Zahlen dazu geben?! Neues High End dauert doch noch bei ATI, oder?!
Ich hab nix von nem Tapeout mitbekommen.

[reunion]

Warum soll es jetzt schon Zahlen dazu geben?! Neues High End dauert doch noch bei ATI, oder?!
Ich hab nix von nem Tapeout mitbekommen.

R700 kommt laut AMD-Roadmaps Mitte 2008. Also in etwas mehr als sechs Monaten. So lange ist das nicht mehr hin, und falls diese fast 2TFLOPs stimmen sollte, dann drückt AMD ganz schön aufs Tempo.

[Ailuros]

R700 kommt laut AMD-Roadmaps Mitte 2008. Also in etwas mehr als sechs Monaten. So lange ist das nicht mehr hin, und falls diese fast 2TFLOPs stimmen sollte, dann drückt AMD ganz schön aufs Tempo.

Das mit den Roadmap-Projektionen aus der Vergangenheit ist eine Angelegenheit fuer sich.

Was jetzt die 2 TFLOPs betrifft, was besonderes ist es auch nicht wenn man bedenkt fuer was "R700" stehen koennte ;)

[mapel110]

Das mit den Roadmap-Projektionen aus der Vergangenheit ist eine Angelegenheit fuer sich.

Was jetzt die 2 TFLOPs betrifft, was besonderes ist es auch nicht wenn man bedenkt fuer was "R700" stehen koennte ;)
Crossfire dann also höchstwahrscheinlich. Wenn sie eine Möglichkeit gefunden haben, dass es immer funktioniert und der Speicher nicht mehr separat vorhanden sein muss... aber daran glaube ich erst, wenn ich es sehe.

[Ailuros]

Crossfire dann also höchstwahrscheinlich. Wenn sie eine Möglichkeit gefunden haben, dass es immer funktioniert und der Speicher nicht mehr separat vorhanden sein muss... aber daran glaube ich erst, wenn ich es sehe.

So schwer ist es theoretisch gar nicht mit shared memory anzukommen; der groesste Kopfschmerz duerfte nach wie vor das load balancing zwischen den chips sein.

[robbitop]

Das Problem ist die benötigte sehr schnelle Verbindung mehrerer Chips.

[Annihilator]

Das Problem ist die benötigte sehr schnelle Verbindung mehrerer Chips.


naja, auf ner graka wird HT aber sicherlich nicht so langsam angebunden sein wie @ mobo! :wink:

[robbitop]

naja, auf ner graka wird HT aber sicherlich nicht so langsam angebunden sein wie @ mobo! :wink:
Wie einfach sich das so mancher vorstellt. ;)
Die Latenzen kommen als Problem hinzu, wenn der Arbiter Quadbatches verteilt. Die Bandbreiten für die Arbeitsaufteilung und die Speicher und Cachezugriffe müssen enorm breit sein.
Ob das bezahlbar möglich ist, weiß ich nicht. Sowas wurde bisher so noch nie umgesetzt. Es ist jedenfalls ein erhebliches Problem

[Gmax]

http://multipics.net/img_small/1180620,d1c2e785-e872-414b-a.jpg (http://multipics.net/?img=1180620,d1c2e785-e872-414b-a.jpg) http://multipics.net/img_small/1180619,abe3936b-59c2-4fbe-8.jpg (http://multipics.net/?img=1180619,abe3936b-59c2-4fbe-8.jpg)

http://www.hardspell.com/doc/hard/64303.htm

[reunion]

Wie einfach sich das so mancher vorstellt. ;)
Die Latenzen kommen als Problem hinzu, wenn der Arbiter Quadbatches verteilt. Die Bandbreiten für die Arbeitsaufteilung und die Speicher und Cachezugriffe müssen enorm breit sein.
Ob das bezahlbar möglich ist, weiß ich nicht. Sowas wurde bisher so noch nie umgesetzt. Es ist jedenfalls ein erhebliches Problem

Alle Spatzen pfeifen es mittlerweile von den Dächern, und auch AMD-Mitarbeiter geben dazu mehr oder weniger eindeutige Antworten. So groß kann das Problem nicht sein, sonst würde man darauf verzichten. Die Vorteile überwiegen anscheinend.