R900 - 28nm, DX11-nativ, 2010 - "Radeon 100" - Northern Islands

[AnarchX]

Our source was certain that they won't be troubled with nVidia, because they're expecting to see terrible yields for the GT300. "40nm is headache for both them [nVidia] and us". "We don't care, since it won't be long now". I asked what that was all about, and our doubts were confirmed. According to this source, AMD will switch its GPU production to GlobalFoundries in H1 2010, most notably with the launch of 28nm Bulk silicon process. This will be followed with the release of first "native" DirectX 11 architecture by AMD, not the "Radeon HD 4890 with DirectX 11".
http://www.brightsideofnews.com/news/2009/5/29/ati-to-be-a-28nm-launch-customer-at-globalfoundries.aspx

Also kann man nach RV800, der wie schon abzusehen mehr einem RV700 mit DX11-Kompatiblität entsprechen sollte, bei ATI endlich wieder eine größere Architekturänderung erwarten.

Was kann man wohl bei einer auf das DX11-Featureset optimierten Architektur erwarten?
Bei R600 überschätzte man ja damals den Einsatz der neuen Shadertypen und auch den Einsatz von HDR-Texturen.

[dargo]

Was meinen die mit nativ DX11? Kein Fallback zu DX10/9 wäre wohl ziemlich dämlich und auch unlogisch.

[AffenJack]

Wie AnarchX es schon geschrieben hat, ne neue Architektur die auf die Anforderungen von dx11 optimiert ist im Gegensatz zu rv870 der noch auf r600 basiert und nur auf dx11 erweitert wird. Allerdings ist H1 2010 für 28nm doch arg optimistisch, in dem Zeitraum erwarte ich gerade 32nm Produkte. Würde mich sehr überraschen, wenn 28nm Produkte vor H2 2010 kommen.

[Spasstiger]

Allerdings ist H1 2010 für 28nm doch arg optimistisch
Der 28-nm-Prozess wurde von Globalfoundries aber für Anfang 2010 angekündigt. 32 nm läuft anscheinend bereits.

[reunion]

Globalfoundries hat einiges an Kohle von ATIC bekommen. 6Mrd Dollar AFAIK. Man will den Rückstand auf Intel bei 32nm bis auf ein Quartal verkürzen. Siehe: http://www.forum-3dcenter.org/vbulletin/showthread.php?p=7330898#post7330898

[V2.0]

Es war nie ein gutes Zeichen wenn eine IHV über die übernächste Generation spricht bevor die nächste auf dem Markt ist.

[Spasstiger]

Es war nie ein gutes Zeichen wenn eine IHV über die übernächste Generation spricht bevor die nächste auf dem Markt ist.
Andererseits macht ein früher R900 auch die Spekulationen über den RV870 glaubwürdiger, d.h. nur 1200 SPs, 48 TMUs und ein 256-Bit-SI, sprich ein eher günstiger Performance-Chip. Leidtragend ist in jedem Fall Nvidia, denn die setzen alles auf den riesigen GT300 im problematischen 40-nm-Prozess bei TSMC.

[mapel110]

Für mich klingt die Meldung unlogisch. Man weiß während der Entwicklung eines Chips doch gar nicht, wie der entsprechende Fertigungsprozess laufen wird (4 Jahre Entwicklungszeit). Also bastelt man auch Verbesserungen mit rein und arbeitet nicht bloß ne Feature-Checkliste ab und bringt dann noch einen Chip mit einem halben Jahr Verzögerung, der dann wunderbar nativ zur API ist und tolle Verbesserungen mitbringt.

Vorallem hat AMD/ATI doch gar nicht die Kohle für solch einen Aufwand. Aber klar, man bastelt Mid Range Chips, geht weg von High End, um dann gleich zwei Mid Range Chips nebeneinander zu entwickeln. Die Meldung macht einfach überhaupt keinen Sinn.

[reunion]

Für mich klingt die Meldung unlogisch. Man weiß während der Entwicklung eines Chips doch gar nicht, wie der entsprechende Fertigungsprozess laufen wird (4 Jahre Entwicklungszeit).

Der Fertigungsprozess ist so ziemlich das erste was man festlegt.


Vorallem hat AMD/ATI doch gar nicht die Kohle für solch einen Aufwand. Aber klar, man bastelt Mid Range Chips, geht weg von High End, um dann gleich zwei Mid Range Chips nebeneinander zu entwickeln. Die Meldung macht einfach überhaupt keinen Sinn.

AMD entwickelt locker fünf oder mehr Chips nebeneinander. Und AMD hat schon vor langem bekannt gegeben alle sechs Monate einen neuen Performancechip herstellen zu wollen.

[mapel110]

Der Fertigungsprozess ist so ziemlich das erste was man festlegt.


Und?! Man weiß nicht, wie sich der Fertigungsprozess verhalten wird und ob er gut laufen wird in den Fabriken.

AMD entwickelt locker fünf oder mehr Chips nebeneinander.
Aber es macht keinen Sinn, fürs selbe Segment zwei Chips zu entwickeln. Eigentlich hat das noch nie ein IHV gemacht. Das einzige was es gab, waren kleinere Feinheiten ein halbes Jahr später. Aber keine neue Architektur.
Und AMD hat schon vor langem bekannt gegeben alle sechs Monate einen neuen Performancechip herstellen zu wollen.
Gibts dafür eine Quelle?

[AnarchX]

Absolutes High-End ist natürlich für AMD nicht mehr relevant, jedenfalls nicht Single-GPU, nichtsdestotrotz benötigt man für >2010 eine leistungsfähige und effiziente DX11+ Architektur.
Ersteres im Bezug auf den GPGPU-Push durch OCL und CS, letzeres im Bezug auf Fusion in 2011.


AMD entwickelt locker fünf oder mehr Chips nebeneinander.
Und je nach Situation wird ein Design eben auch erstmal auf Eis gelegt und zu einem späteren Zeitpunkt wiederbelebt, wie eben der ursprüngliche R400, der dann als Basis für R600 diente.

[mapel110]

Es wäre jedenfalls ein Novum, wenn ein IHV innerhalb so kurzer Zeit zwei so unterschiedliche Design bringen würde.

[reunion]

Es wäre jedenfalls ein Novum, wenn ein IHV innerhalb so kurzer Zeit zwei so unterschiedliche Design bringen würde.

RV670, RV770.

Und?! Man weiß nicht, wie sich der Fertigungsprozess verhalten wird und ob er gut laufen wird in den Fabriken.


Auf was willst du hinaus? Das weiß man nie. Zu Verzögerungen kann es immer kommen.


Gibts dafür eine Quelle?

http://www.forum-3dcenter.org/vbulletin/showthread.php?t=374644&highlight=ati+strategie

Dass das korrekt ist sieht man auch deutlich an der Vergangenheit:
RV670, RV770, RV790, RV870 und wohl dann wieder sechs Monate später RV970.

[mapel110]

RV790 soll was Neues sein?! Die Liste hinkt...

Und wenn man sich die Infos in dem Thread anschaut, ist alles doch ein wenig anders gekommen.

Und bei RV670 vs RV770 sehe ich auch keinen großen Architektur-Unterschied. Man hat Anzahl der Einheiten erhöht und 300 Mio Transistoren mehr verballlert.

[reunion]

RV790 soll was Neues sein?! Die Liste hinkt...


Ja, älter als RV770 ist er jedenfalls nicht. Niemand spricht davon dass jedesmal eine neue Architektur kommen muss.


Und wenn man sich die Infos in dem Thread anschaut, ist alles doch ein wenig anders gekommen.

Die Strategie hat sich bewahrheitet. Alles andere war Interpretationssache.


Und bei RV670 vs RV770 sehe ich auch keinen großen Architektur-Unterschied. Man hat Anzahl der Einheiten erhöht und 300 Mio Transistoren mehr verballlert.

Dann schau dir den Chip mal genauer an. Aber um deinen Satz zu korrigieren: Man hat Anzahl der Einheiten um Faktor 2.5 erhöht und dafür 40% mehr Transistoren verballert. Darüberhinaus gab es noch erhebliche Verbesserungen bei GPGPU und Änderungen beim MC und bei den TMUs und ROPs.

[The_Silent_One]

Aber es macht keinen Sinn, fürs selbe Segment zwei Chips zu entwickeln. Eigentlich hat das noch nie ein IHV gemacht. Das einzige was es gab, waren kleinere Feinheiten ein halbes Jahr später. Aber keine neue Architektur.


war es nicht bei der X1xxx serie so? neben der x1800 kam doch noch die x1600 mit leicht abweichender architektur und dann erschien die x1900 auf basis der x1600 nur "kurze zeit" später. da kann man schon sagen, dass mehr oder weniger gleichzeitig an zwei chips entwickelt wurde, die das selbe segment anpeilen.
bitte korrigiert mich, wenn ich falsch liege.

[darkvader]

war es nicht bei der X1xxx serie so? neben der x1800 kam doch noch die x1600 mit leicht abweichender architektur und dann erschien die x1900 auf basis der x1600 nur "kurze zeit" später. da kann man schon sagen, dass mehr oder weniger gleichzeitig an zwei chips entwickelt wurde, die das selbe segment anpeilen.
bitte korrigiert mich, wenn ich falsch liege.

ALso ich meine mich zu erinnern, das der R580 (x19xx) eine Entwicklung auf Basis des R520 (x18xx) war, und er kam etwa ein halbes Jahr später, also im Rahmen der Refreshs....

[=Floi=]

imho verspätete sich schon die X800 dann kam die X1800 zu spät und bei der X1900 brachte man die karte zum angedachten zeitpunkt. deshalb liegen X1800 und X1900 so nahe beieinander.

[Coda]

Andererseits macht ein früher R900 auch die Spekulationen über den RV870 glaubwürdiger, d.h. nur 1200 SPs, 48 TMUs und ein 256-Bit-SI, sprich ein eher günstiger Performance-Chip. Leidtragend ist in jedem Fall Nvidia, denn die setzen alles auf den riesigen GT300 im problematischen 40-nm-Prozess bei TSMC.
G300 hat eher die Größe von G80. Von riesig würde ich da nicht sprechen.

[AnarchX]

G300 hat eher die Größe von G80. Von riesig würde ich da nicht sprechen.
Wobei G80s 90nm aber auch entsprechend reifer waren, als, momentan und wohl auch noch im H2, 40nm.

Was gibt es denn ausser Intels 500-700mm² MP-Server-CPUs noch an größeren ICs auf modernen Prozessen?

[deekey777]

imho verspätete sich schon die X800 dann kam die X1800 zu spät und bei der X1900 brachte man die karte zum angedachten zeitpunkt. deshalb liegen X1800 und X1900 so nahe beieinander.
Dass der R420 sich verspätet hat, bezweifle ich sehr stark.

[Spasstiger]

G300 hat eher die Größe von G80. Von riesig würde ich da nicht sprechen.
Wenn für AMD ein RV740 @ 40 nm mit <140 mm² in 40 nm fast so teuer ist wie ein RV770 @ 55 nm mit 256 mm², dann ist ein GT300 mit knapp 500 mm² in 40 nm auf jeden Fall riesig. Man kann davon ausgehen, dass er sogar teurer wird als ein GT200 in 65 nm. Und NV hat offenbar schon einen Gang runtergeschalten, denn anfangs war von knapp 3 Mrd. Transistoren die Rede (jetzt sollen es nur noch 2,4 Mrd. sein).

[reunion]

494mm² in einem nagelneuen und offensichtlich alles andere als ausgereiften 40nm Prozess sind sicherlich nicht wenig. Das macht vielleicht 120 Dice auf einer 300mm² Wafer, und wenn AMD schon Probleme hat ihren winzigen RV740 in ausreichenden Mengen zu fertigen braucht man kein Prophet zu sein um zu wissen, dass so etwas bei einem derart großem Die momentan in einen Desaster enden würde. Ein RV870 mit vielleicht <250mm² hat da natürlich auch erhebliche Vorteile was die Yieldraten betrifft.

[Coda]

Wobei G80s 90nm aber auch entsprechend reifer waren, als, momentan und wohl auch noch im H2, 40nm.
Hört doch mal mit der Schwarzmalerei auf. Nur weil der Prozess etwas hinterherhinkt heißt dass noch lange nicht dass es unlösbare Probleme waren. Intel hat ja auch schon länger Immersion-Litho am laufen.

[reunion]

Schon länger? Immersion-Lithographie kommt bei Intel mit 32nm.

[Spasstiger]

Hört doch mal mit der Schwarzmalerei auf. Nur weil der Prozess etwas hinterherhinkt heißt dass noch lange nicht dass es unlösbare Probleme waren.
Der Prozess funktioniert ja auch und es kommen auch GPUs bei raus. Aber die Yieldraten sind halt nicht das, was man sich in den Chefetagen so vorstellt.
NV wird aber wohl den Vorteil haben, dass der GT300 alleine das High-End-Segment besetzt und der RV870 nur den RV770 ablöst. Somit kann NV den Preis für GT300-Karten fast beliebig wählen - zumindest bis der R900 kommt.

[V2.0]

RV740 ist deutlich früher dran als G300.
Anpassung oder Abspeckungen zu erahnen, weil sich Gerüchte konkretisieren ist sehr gewagt.
Manche Quellen berichten von erheblichen Leckströmen, die es schwer machen hohe Taktraten zu erreichen. Allerdings sollen konservative Taktungen wohl funktionieren.
Ich denke ATI ist von Taktproblemem härter getroffen.

[Ailuros]

Wenn für AMD ein RV740 @ 40 nm mit <140 mm² in 40 nm fast so teuer ist wie ein RV770 @ 55 nm mit 256 mm², dann ist ein GT300 mit knapp 500 mm² in 40 nm auf jeden Fall riesig. Man kann davon ausgehen, dass er sogar teurer wird als ein GT200 in 65 nm. Und NV hat offenbar schon einen Gang runtergeschalten, denn anfangs war von knapp 3 Mrd. Transistoren die Rede (jetzt sollen es nur noch 2,4 Mrd. sein).

NV hat gar nichts heruntergeschalten und man aendert hochkomplezierte chips nicht in ein paar Monaten.

Es war vor geraumer Zeit hinter den Kulissen bekannt dass der G300 die in etwa so gross sein wird wie GT200 und ich warnte schon damals dass keiner weiss ob damit GT200 oder GT200b gemeint war. Anders fuer 2.4B Transistoren hasst Du logischerweise GT200b 40nm die area und fuer 3.0B Transistoren GT200 40nm die area.

Teurer koennte G300 durchaus werden aber dann auch eher wegen 2GB GDDR5@1100MHz.

Der Prozess funktioniert ja auch und es kommen auch GPUs bei raus. Aber die Yieldraten sind halt nicht das, was man sich in den Chefetagen so vorstellt.
NV wird aber wohl den Vorteil haben, dass der GT300 alleine das High-End-Segment besetzt und der RV870 nur den RV770 ablöst. Somit kann NV den Preis für GT300-Karten fast beliebig wählen - zumindest bis der R900 kommt.


Absolut gar nichts ist problemlos bei der RV740 Herstellung und dass die Anfrage keinesfalls gedeckt werden kann ist genug dass dafuer spricht. Anders gefragt wo zum Henker ist RV870 wenn 40nm bei TSMC schon "laufen" soll? Und bevor Du es sagst ja das Ding ist ebenso produktionsreif.

[reunion]

Manche Quellen berichten von erheblichen Leckströmen, die es schwer machen hohe Taktraten zu erreichen. Allerdings sollen konservative Taktungen wohl funktionieren.
Ich denke ATI ist von Taktproblemem härter getroffen.

Das kann aber nur BS sein wenn man sich RV740 ansieht.

[Gast]

Dann schau dir den Chip mal genauer an. Aber um deinen Satz zu korrigieren: Man hat Anzahl der Einheiten um Faktor 2.5 erhöht und dafür 40% mehr Transistoren verballert. Darüberhinaus gab es noch erhebliche Verbesserungen bei GPGPU und Änderungen beim MC und bei den TMUs und ROPs.
Du meinst 16 vs 16 ROPs,; 16 vs 16 TMUs; (512bit vs 256bit)?


Dass das korrekt ist sieht man auch deutlich an der Vergangenheit:
RV670, RV770, RV790, RV870 und wohl dann wieder sechs Monate später RV970.
RV790?
Bleib auf dem Teppich, jetzt jubelst du wegen 10% Mehrtakt dank größerem Chip. AMD hats diesmal nicht geschafft, RV870 kommt über ein Jahr nach RV770.

[reunion]

Du meinst 16 vs 16 ROPs,; 16 vs 16 TMUs; (512bit vs 256bit)?


Wen das wenigstens richtig wäre. Aber es sind 40 vs. 16 TMUs, die ROPs haben doppelt so viele Z-Tester, und schaffen doppelt so hohe MSAA-Sufen pro Takt.


RV790?
Bleib auf dem Teppich, jetzt jubelst du wegen 10% Mehrtakt dank größerem Chip. AMD hats diesmal nicht geschafft, RV870 kommt über ein Jahr nach RV770.

Lerne lesen, das habe ich oben schon geschrieben. Es ist ein neuer Chip, nicht mehr und nicht weniger. Und genau das hat AMD erwähnt, das es nicht jedes mal zu fundamentalen Änderungen kommt sollte klar sein.

[AnarchX]

Und dazu bietet RV790 in der maximalen Ausbaustufe gegenüber der maximalen Ausbaustufe von RV770 immerhin 25% mehr Takt - 1000 vs 800MHz.
Für einen Refresh nicht so schlecht, wenn auch RV790 etwas eher hätte erscheinen können, aber da RV770s Marktposition über den Erwartungen war, hat man hier wohl etwas gebremst.

Dann gab es ja noch den ursprünglichen R700, der wohl auf dem nicht in Produktion gegangenen 45nm Prozess mit MGPU-Verbesserungen erscheinen sollte.

[Coda]

Schon länger? Immersion-Lithographie kommt bei Intel mit 32nm.
Sorry, ich meinte natürlich AMD.

Wie auch immer. Das Problem mit TSMC haben derzeit beide zu verkraften.

[Gast]

Wen das wenigstens richtig wäre. Aber es sind 40 vs. 16 TMUs, die ROPs haben doppelt so viele Z-Tester, und schaffen doppelt so hohe MSAA-Sufen pro Takt.

Lerne lesen oder höre auf zu lügen. RV670 hat 16 TMUs, der Rest gehört auch zu RV770.

Und dazu bietet RV790 in der maximalen Ausbaustufe gegenüber der maximalen Ausbaustufe von RV770 immerhin 25% mehr Takt - 1000 vs 800MHz.
Käuflich erwerbar/lagernd sind nur 950Mhz. Ergibt 19%.
Bzw 13% für den Defaulttakt.

Das ist ein "Ultra/XT PE" Modell, keine neue Performancekarte. Solche Karten zeichnen sich dadurch aus, das sie deutlich später eintreffen, ein paar % mehr Takt mitbringen und dann noch Preis/Leistungsmäßig mieser dastehen.

Nur weil AMD dazu RV770 nicht selbst höher taktet, sondern etwas aufbläst ändert nichts an der Stellung dieses Produktes "4890".

[LovesuckZ]

RV670, RV770.


Wieso rv670? Das müsste wohl eher r600 heißen.

[reunion]

Lerne lesen oder höre auf zu lügen. RV670 hat 16 TMUs, der Rest gehört auch zu RV770.

Es ging auch von Anfang an um RV770 vs. RV670. Dein Problem wenn du nicht in der Lage bist richtig zu interpretieren.

Wieso rv670? Das müsste wohl eher r600 heißen.

R600 war der letzt "Riesenchip". Mit RV670 begann die jetzige Strategie.

[LovesuckZ]

R600 war der letzt "Riesenchip". Mit RV670 begann die jetzige Strategie.

Falsch, denn hätte der rv670 deutlich kleiner sein müssen. Der erste Chip aus dieser Strategie ist der rv770. Der rv670 ist nur ein "einfacher" Shrink gewesen und stellte natürlich keine Strategieänderung dar. Ist Vergleichbar mit g70 -> g71 -> g80 oder auch g80 -> g92(b) -> GT200.
Statt also den normalen Weg zu gehen hat man bei AMD eben die Strategie angepasst.

[Nakai]

Falsch, denn hätte der rv670 deutlich kleiner sein müssen.

Der war 192mm² groß. Wie klein hätte er denn nach deiner Meinung sein sollen?


mfg Nakai


€: Ein einfacher Shrink war der RV670 garantiert nicht! Kein 512Bit Ringbus, DX10.1.

[LovesuckZ]

Der war 192mm² groß. Wie klein hätte er denn nach deiner Meinung sein sollen?
mfg Nakai

Es war ein "enfacher" Shrink einer vorhandenen Architektur. Der G71 war auch nur 19xmm^2 groß - und hat nVidia ihre Strategie geändert? :rolleyes:
Auch der G92b (55nm Prozeß zu bleiben) ist mit 27xmm^2 deutlich kleiner als der G80 und ist mit durchschnittlich ca. 65% Mehrleistung gegenüber dem rv670 doppelt so schnell wie er prozentual größer ist. Der rv670 ist kein Anzeichen für eine Strategieänderung.

[reunion]

Falsch, denn hätte der rv670 deutlich kleiner sein müssen. Der erste Chip aus dieser Strategie ist der rv770. Der rv670 ist nur ein "einfacher" Shrink gewesen und stellte natürlich keine Strategieänderung dar. Ist Vergleichbar mit g70 -> g71 -> g80 oder auch g80 -> g92(b) -> GT200.
Statt also den normalen Weg zu gehen hat man bei AMD eben die Strategie angepasst.

So einen "einfachen Shrink" gab es bei ATi aber vorher noch nie. Im übrigen ist RV670 auch mehr wie ein einfacher Shrink. Das Ding hat weniger Transistoren als R600 und bekam u.a D3D10.1 und DoublePrecision FP. Was du hier als normale Strategie ansiehst gibt es bei NV auch erst seit G71 und war wohl mehr aus der Not heraus geboren etwas gegen R580 zu haben. Bis dahin war es üblich das High-End-Segment ausschließlich mit großen Chips zu bedienen.

Es war ein "enfacher" Shrink einer vorhandenen Architektur. Der G71 war auch nur 19xmm^2 groß - und hat nVidia ihre Strategie geändert? :rolleyes:

Ja. Von ausschließlich großen Single-Chips auf großen Single-Chip und anschließenden Shrink.

[LovesuckZ]

So einen "einfachen Shrink" gab es bei ATi aber vorher noch nie.

g71 Vorgang auch nicht. Trotzdem kam 6 1/2 Monate später ein Chip, der 2,5 fach so groß war. :rolleyes:

Was du hier als normale Strategie ansiehst gibt es bei NV auch erst seit G71 und war wohl mehr aus der Not heraus geboren etwas gegen R580 zu haben.

Das hat jetzt genau welchen Bezug auf die Aussage, dass rv670 eine neue Strategie eingeläutert hätte? Der rv670 ist ein normaler Shrinkvorgang mit kleinen Veränderung an der Architkur gewesen. Sowie es beim g71 war. Und auch beim g92.

[Nakai]

Was du hier als normale Strategie ansiehst gibt es bei NV auch erst seit G71 und war wohl mehr aus der Not heraus geboren etwas gegen R580 zu haben.

Das denke ich nicht. G71 war zuerst eine Verkleinerung des G70 mit 90nm. Die Takterhöhung war dadurch ja gegeben und gegen den R580 nötig.

Es war ein "enfacher" Shrink einer vorhandenen Architektur. Der G71 war auch nur 19xmm^2 groß - und hat nVidia ihre Strategie geändert?

Es war kein einfacher Shrink. Schon allein wegen der moderneren Fertigung.
Man hat ja eine GX2 auf Basis des G71 gebracht, weil man mit dem G71 alleine nicht genug Leistung liefern konnte. Das hat man wohl Anfang 2006 gemerkt.


mfg Nakai

€: Das hat jetzt genau welchen Bezug auf die Aussage, dass rv670 eine neue Strategie eingeläutert hätte? Der rv670 ist ein normaler Shrinkvorgang mit kleinen Veränderung an der Architkur gewesen. Sowie es beim g71 war. Und auch beim g92.

Ich denke nicht, dass man einen Chip mit einer Fertigungs und Verkaufstaktik gleichsetzen kann. Der RV670 hat die Kriterien für diese Taktik erfüllt.
Der RV670X2 kam ja auch erst deutlich später, was wohl für einen Taktikswechsel in dem Zeitraum spricht. Der RV770 war auf diese Taktik vollkommen ausgelegt, das stimmt.

[reunion]

g71 Vorgang auch nicht. Trotzdem kam 6 1/2 Monate später ein Chip, der 2,5 fach so groß war. :rolleyes:

Und weiter? NV hat eben die Strategie geändert von ausschließlich großen Single-Chips auf große Single-Chips mit anschließendem Shrink. AMD hat das dann wenn man so will ausgebaut.


Das hat jetzt genau welchen Bezug auf die Aussage, dass rv670 eine neue Strategie eingeläutert hätte? Der rv670 ist ein normaler Shrinkvorgang mit kleinen Veränderung an der Architkur gewesen. Sowie es beim g71 war. Und auch beim g92.

Willst du dich jetzt wirklich über solchen Mist streiten? Du bist doch perplex. RV670 war ATis erster kleiner Chip mit anschließender X2 im High-End. Es gab sogar haufenweise geleakte ATi-Folien zum RV670-Launch wo dieser neue Strategie mit RV670 ausführlich dargelegt wurde. Also manchmal. Aber glaube doch was du willst.

[LovesuckZ]

Und weiter? Vorher gab es soetwas nie. Nv hat die Strategie geändert.

Und der G80 war also nur ca. 265mm^2 groß - soso.


Willst du dich jetzt wirklich über solchen Mist streiten? Du bist doch perplex. RV670 war ATis erster kleiner Chip mit anschließender X2 im High-End. Es gab sogar haufenweise geleakte ATi-Folien zum RV670-Launch wo dieser neue Strategie ausführlich dargelegt wurde. Also manchmal. Aber glaube doch was du willst.

Du verstehst es nicht, oder? Der rv670 war ein normaler Shrinkvorgang, wie es nVidia mit g71 getan und mit dem g92 wiederholt hat. Nur weil AMD bei zukünftigen Entwicklungen auf kleinere Chips setzte, ist der rv670 kein Anzeichen dafür. Und wenn man also gleichzeitige GPU Entwicklungslinien verfolgt, dann wohl eher r600 und rv770.
Und Bezug auf Mapel's Aussage: Der rv670 und der rv770 sind natürlich nicht zusammen zuvergleichen, wenn es um "zwei unterschiedliche Architekturen mit nahem Zeitabständen geht". Der erste ist ein Shrink und der andere eine "neue Architektur". Also genau das selbe wie beim g71 -> g80 oder g92 -> gt200.

[V2.0]

Das kann aber nur BS sein wenn man sich RV740 ansieht.

Das ist halt die Frage. Was ist wenn viele RV740 anfallen die mit 450-500mhz laufen würden. Bei dem Preis eines 40nm Waffers und der theoretischen Leistung eines solchen Chips sind die ziemlich uninteressant. Wir wissen nicht wo im Vertrag zwischen TSMC und AMD/ATI die garantierte Mindesttaktung liegt.
Eher gegen Taktprobleme spricht, dass selbst die kleinen NV-Chips auf sich warten lassen.

[reunion]

28nm Bulk SRAM Wafer von Globalfoundries:

http://img189.imageshack.us/img189/80/28nm2765084.jpg (http://img189.imageshack.us/my.php?image=28nm2765084.jpg)

http://www.fudzilla.com/content/view/13968/1/

28nm chips in early 2011:
http://www.fudzilla.com/content/view/13969/1/

[reunion]

Und der G80 war also nur ca. 265mm^2 groß - soso.

Du willst es nicht verstehe oder?


Du verstehst es nicht, oder? Der rv670 war ein normaler Shrinkvorgang, wie es nVidia mit g71 getan und mit dem g92 wiederholt hat. Nur weil AMD bei zukünftigen Entwicklungen auf kleinere Chips setzte, ist der rv670 kein Anzeichen dafür. Und wenn man also gleichzeitige GPU Entwicklungslinien verfolgt, dann wohl eher r600 und rv770.

RV670 war wie schon dargelegt weit mehr wie ein Shrink und vorallem der erste kleine High-End-Chip von AMD, welche klar eine Strategieänderung darstellte.


Und Bezug auf Mapel's Aussage: Der rv670 und der rv770 sind natürlich nicht zusammen zuvergleichen, wenn es um "zwei unterschiedliche Architekturen mit nahem Zeitabständen geht". Der erste ist ein Shrink und der andere eine "neue Architektur". Also genau das selbe wie beim g71 -> g80 oder g92 -> gt200.

Ansichssache. RV870 könnte ich genau so gut als aufgebohrten RV770 ansehen, dann würde man bei RV900 auch nicht von "zwei unterschiedliche Architekturen mit nahem Zeitabständen" sprechen. Letztendlich sind die Übergänge ohnehin fließend.

[Ailuros]

Angenommen das Geblubber bei Bright Side of News ist echt, klingt das Ganze zumindest merkwuerdig.

RV870 ist also eher ein 4890 + D3D11 und der 28nm Nachfolger eine "native D3D11 Architektur" oder wie soll ich das Ganze verstehen?

Falls dieses stimmen sollte ist es tatsaechlich eine vorzeitige Warnung dass es erst wieder mit 28nm bergauf geht.

[AffenJack]

28nm chips in early 2011:
http://www.fudzilla.com/content/view/13969/1/

Dem ist deutlich mehr glauben zu schenken als der BSN News mit 28nm in H1 2010. Das zeigt dann aber auch, dass die News an sich keinen Sinn macht, denn zumindest nen Refresh wird man 2010 brauchen, wenn mit 28nm ne neue Architektur 2011 kommen sollte.

[deekey777]

http://www.pcper.com/comments.php?nid=7237
32nm SOI technology will be shipping in 2010 in an AMD design though GF does have a 32nm bulk technology that they will begin accepting orders for in the second half of this year.
...
After the introduction of the 32nm technology, GlobalFoundries will release a 28nm technology tested and ready to go for taking orders in early 2010 with full-scale production later in the year. Compared to the 32nm process, GF expects to see some significant power and size reductions on 28nm that could potentially really spotlight that particular process as the target for GPU architectures going forward. 28nm technology will also be the 3rd generation of immersion lithography and 2nd generation High-K metal gate design.
...
Klingt irgendwie anders.

[LovesuckZ]

RV670 war wie schon dargelegt weit mehr wie ein Shrink und vorallem der erste kleine High-End-Chip von AMD, welche klar eine Strategieänderung darstellte.

Soso - ein paar Veränderungen reichen also für dich aus um ihr "mehr als ein Shrink" zu nennen. Was war dann der G71? Auch "mehr als ein Shrink"? Und der G92? Eine komplett neue Architektur?
Sehe es ein - deine Aussage ist falsch. Wenn man schon AMD Architekturen vergleichen will, dann bitte r600 und rv770. Und hier liegen 1 Jahr und 2 Monate dazwischen.

Letztendlich sind die Übergänge ohnehin fließend.

Die Übergänge sind in keinster Weise "fließend". Weder der G71 noch der rv670 sind näher am G80/rv770 als an ihrem großen Bruder.

[deekey777]

Schluss mit dieser sinnlosen Diskussion. Wenn ihr noch was auszudiskutieren habt, macht das per PN.

[AffenJack]

http://www.pcper.com/comments.php?nid=7237

Klingt irgendwie anders.

Ok, bei Produkten sindwa dann eh in H2 2010. Aber dann würdes doch gehen.

[reunion]

Dem ist deutlich mehr glauben zu schenken als der BSN News mit 28nm in H1 2010. Das zeigt dann aber auch, dass die News an sich keinen Sinn macht, denn zumindest nen Refresh wird man 2010 brauchen, wenn mit 28nm ne neue Architektur 2011 kommen sollte.

Genau lesen. BSN bezieht sich nicht auf den Launch. Vor Ende 2010 wird man kaum Produkte im Handel sehen. AMD plant auf der aktuellen Roadmap auch nicht mit 32nm CPUs vor 2011.

[Ailuros]

Gibt es jemand der in den sauren Apfel native vs. non-native DX11 beissen will? Irgend etwas stimmt hier nicht.......

[reunion]

Gibt es jemand der in den sauren Apfel native vs. non-native DX11 beissen will? Irgend etwas stimmt hier nicht.......

Ich würde mich daran nicht aufhängen. Das ist ja nur eine Floskel für die zweite DX11-Generation. Der Begriff native ist halt gerade "in", aber hier ohnehin Blödsinn, entweder man unterstützt DX11 oder nicht.

[Ailuros]

Ich würde mich daran nicht aufhängen. Das ist ja nur eine Floskel für die zweite DX11-Generation. Der Begriff native ist halt gerade "in", aber hier ohnehin Blödsinn, entweder man unterstützt DX11 oder nicht.

Ich dachte bis gestern dass RV7x0 naeher an X11 als alles andere :P ROFL :biggrin:

Spass beiseite (und ja natuerlich kann es sich auch um erfundenen Unsinn handeln) schau mal her Wort fuer Wort:

This will be followed with the release of first "native" DirectX 11 architecture by AMD, not the "Radeon HD 4890 with DirectX 11".

Selbst wenn ich "native" uebersehen will kann ich das zweite fettgedruckte schwer uebersehen. Und ja alle bisherigen Indizien deuten fuer RV870 in die Richtung RV7x0 + D3D11. Von fundamentalen Aenderungen war nie die Rede.

Und ja es ist tatsaechlich Bloedsinn ueber die uebernaechste Generation zu blubbern ausser es stimmt etwas nicht mit dem kommenden Zeug.

[Gaestle]

Dx11 via Treiber?

[The_Silent_One]

Du meinst, es steckt mehr hinter dem RV790 als bisher bekannt? Das bezweifle ich, aber es hat sich ja auch schon beim RV770 entpuppt, dass er mehr Shader hat, als genutzt werden. Nur, dass ein ganzes Featureset mit dabei ist(, bevor die finale Spezifikation von DX11 bekannt ist?) oder treiberseitig simuliert werden kann? Naja...

[Gaestle]

Ich wollte eigentlich fragen, ob es mit den vorhanden R790 Einheiten möglich wäre, die Notwendigen DX11-Funktionen über den Treiber zu emulieren. Larabee wird ja angeblich auch keine dedizierte Hardware haben.
Das würde bedeuten, dass ein solcher RV870 technisch sehr sehr nahe am RV790/770 wäre und auf eine gewissde Art auch "non-native" weil die dedizierte HW fehlt. Dann wäre aber auch LRB "non-native".

[HOT]

>= Q1 2010 - 32nm Bulk Produkte
>= Q3 2010 - 32nm SOI Produkte
>= Q1 2011 - 28nm Bulk Produkte
(>= 2011 - 28nm SOI Produkte für NV?)

Was soll daran so schwer zu verstehen sein? Der RV870 ist eine native DX11-GPU. Mehr nativ geht nicht :D.
Die Meldung ist schlicht und ergreifend BS, mehr nicht.
Einen RV890 in 32nm Bulk in Q2 2010 könnt ich mir viel eher vorstellen.

[Coda]

Ich wollte eigentlich fragen, ob es mit den vorhanden R790 Einheiten möglich wäre, die Notwendigen DX11-Funktionen über den Treiber zu emulieren.
Nein.

[Triskaine]

Nein.

Was ist der Grund dafür? Wäre es nicht theoretisch möglich einen Wrapper zu schreiben der alle DX11 Befehle abfängt und sie entsprechende DX10 Befehle übersetzt und die nicht vorhandenen Funktionaliäten über die Shader emuliert? Klar, das wäre ziehmlich lahm und man könnte nur Dinge emulieren die auch im Bereich der Fähigkeiten der entsprechenden GPU liegen, aber es müsste doch möglich sein?

[mapel110]

Was ist der Grund dafür? Wäre es nicht theoretisch möglich einen Wrapper zu schreiben der alle DX11 Befehle abfängt und sie entsprechende DX10 Befehle übersetzt und die nicht vorhandenen Funktionaliäten über die Shader emuliert? Klar, das wäre ziehmlich lahm und man könnte nur Dinge emulieren die auch im Bereich der Fähigkeiten der entsprechenden GPU liegen, aber es müsste doch möglich sein?
Directx-Spezifikationen schreiben auch eine Mindestgeschwindigkeit vor, wie schnell eine Funktion sein muss.

[Ailuros]

Dx11 via Treiber?

Nein so war es nicht gemeint. Eben nur "eingeborenes" DX11 anstatt "dazugestecktes". Ich finde es zwar unwahrscheinlich denn der Satz macht auch nicht besonders Sinn. Ich frage mich nur ob jemand sich darueber was ausdenken koennte.

[Gaestle]

Danke allerseits für die Aufklärung.

[Gast]

Nein.
Sicher geht DX11 -> IL, sinvoll ist es natürlich nicht. (Stichwort Performance und hoher Aufwand)

[Coda]

Sicher geht DX11 -> IL, sinvoll ist es natürlich nicht. (Stichwort Performance und hoher Aufwand)
Nein, weil du die FP16-Compressed-Formate und die zusätzlichen Shader-Stages auch nicht mit "IL" emulieren kannst. Da würde mir mehr als ein guter Grund einfallen.

[Gast]

Ich meinte mit DX11->IL nur eine Abbildung. Geschehen müsste dies über einen Softwarerenderer der (mit CPU-Unterstützung natürlich) auf der GPU läuft.
Praktikabel ist das natürlich nicht, geht aber theoretisch problemlos.

[Gast]

Nein, weil du die FP16-Compressed-Formate und die zusätzlichen Shader-Stages auch nicht mit "IL" emulieren kannst. Da würde mir mehr als ein guter Grund einfallen.
Erzähl mal... HS und DS sind emulierbar, wenn auch langsam, der Tesselator ist drin. Texturen kann man komplett in den ALUs machen, wenn es wirklich sein muss (und wäre wahrscheinlich immer noch schneller als MS' WARP10).

[Tarkin]

http://www.nordichardware.com/news,9997.html

... While we expect AMD to introduce a refresh this Spring, we have learned the next generation is slated for launch in Q3 2010.
Just like with the just launched Radeon HD 5800 series, the name has not been set at this point and the name right now is Radeon 100, which is subject to change though as the product materializes. Three ASICs are in the works that we know of. We're awaiting confirmation on the names, but they sound a bit Greek to us (think gargantuan). ...

Los geht's... ;)

[AnarchX]

Da finde ich doch interessanter, was Gipsel dem Treiber entlockt hat:
Was er zu den Codenamen schreibt, stimmt aber ziemlich sicher nicht. Intern benutzt ATI schon noch die RV8xx Namen, zumindest für Cypress und Juniper, und Juniper ist definitiv RV830. Das tauchte afaik erstmals im Dezember letzten Jahres in den Treibern auf (RV870 und RV830 im Cat8.12). In den neueren Versionen sind dann für die kleineren Versionen noch Codenamen dazugekommen, die nicht dem RV-Schema entsprechen, die heißen intern also vielleicht wirklich anders. Im Cat 9.9 stehen sie zumindest so drin: "CEDAR REDWOOD RV830 RV870".

Wenn man ein wenig sucht, findet man da in auch Namen wie "COZUMEL" oder "IBIZA", was in neuen Cats noch durch "KAUAI" ergänzt wird, waren das etwa die Namen, bevor man sich die Evergreen-Bäume ausgesucht hat, oder sind diese Inseln schon die Codenamen für die nächste Generation? ;)

Und vielleicht auch noch ganz interessant, bei den Tags für die Fähigkeiten der einzelnen Chips, gibt es auch einen, der "ASIC_ALU_REORDER" heißt, wofür steht der denn? Befindet sich übrigens direkt hinter "ASIC_R9XX", heißt das also R9xx wird eine MIMD oder eine out-of-order GPU? Vielleicht sollte ich das mal lieber im R900 Speku-Thread schreiben. :rolleyes:

[Coda]

Erzähl mal... HS und DS sind emulierbar, wenn auch langsam, der Tesselator ist drin. Texturen kann man komplett in den ALUs machen, wenn es wirklich sein muss (und wäre wahrscheinlich immer noch schneller als MS' WARP10).
Ich habe schon "Texturen in den ALUs gemacht" und ich kann dir sagen, dass das pro Texture-Load mehrere hundert Takte braucht mit AF.

Ganz zu schweigen davon, dass man dann statt einer Load-Instruction bis zu 32 braucht.

[Gipsel]

Da finde ich doch interessanter, was Gipsel dem Treiber entlockt hat:
Nun, daß R9xx schon jetzt im Treiber aufgetaucht ist, spricht eventuell wirklich dafür, daß der für Q3/10 geplant ist. RV8xx ist auch ein knappes Jahr vor dem Release aufgetaucht. Das heißt also, das Design wurde bereits finalisiert, so daß die Treiberteam mit der Arbeit anfangen konnte.

Und um das mal zu präzisieren, was ich da zu den Insel-Codenamen geschrieben habe, ich bin ziemlich überzeugt, daß es die alten (wirklichen) Codenamen für die Evergreen-Reihe waren, zumindest paßt der Zeitrahmen und sie wurden ja teilweise durch die Evergreens ersetzt. Cedar, Redwood, Juniper und Cypress sind wahrscheinlich eher die "Marketing-Codenamen" und nicht die wirklichen, die ATI-intern ursprünglich benutzt wurden. In dem Bereich sind die Treiberprogrammierer scheinbar auch ein wenig schlampig, z.B. wird an einer Stelle RV770 auch immer noch als Wekiva bezeichnet (das war der Original-Codename dafür).

Aber Namen sind Schall und Rauch. Was bleibt ist die Frage, was ALU_REORDER wohl für eine Fähigkeit bezeichnen könnte ;)

[Ailuros]

1. Es gibt keine Radeon 100 sondern etwas dass einen ziemlich aehnlichen Codenamen hat.

2. Es hat weder mit RV9x0 etwas zu tun noch mit 28nm.

3. Es handelt sich offensichtlich nur um einen refresh.

:rolleyes:

[deekey777]

1. Es gibt keine Radeon 100 sondern etwas dass einen ziemlich aehnlichen Codenamen hat.

2. Es hat weder mit RV9x0 etwas zu tun noch mit 28nm.

3. Es handelt sich offensichtlich nur um einen refresh.

:rolleyes:
Radeon Centurio. :biggrin:

[S940]

Radeon Centurio. :biggrin:
Radeon 101 ;D

[AnarchX]

Hecatoncheires (http://www.fudzilla.com/content/view/15891/1/)

http://img47.imageshack.us/img47/8117/hecatoncheiresci6.jpg

Vielleicht ein Hinweis auf hunderte von schlagkräftigeren Shaderprozessoren?
Oder 50 neue Cluster?

[w0mbat]

Jetzt passt "Radeon 100" auch ins Bild. NH hat ja auch von Griechischen Codenamen gesprochen (in der Meldung bevor sie die Inseln reingemischt haben).

[Gipsel]

Vielleicht ein Hinweis auf hunderte von schlagkräftigeren Shaderprozessoren?Oder 50 neue Cluster?
ALU Reorder ;)

[Gipsel]

Jetzt passt "Radeon 100" auch ins Bild. NH hat ja auch von Griechischen Codenamen gesprochen (in der Meldung bevor sie die Inseln reingemischt haben).
Die Inseln sind alt, allerhöchstens der Refresh, aber nie und nimmer die neue R9XX Generation.

[Ailuros]

Die Inseln sind alt, allerhöchstens der Refresh, aber nie und nimmer die neue R9XX Generation.

Wie schon angedeutet die neue Generation kommt in 28nm.

[2B-Maverick]

ALU Reorder ;)

Please elaborate! Was soll das sein, was bringts?

Und zu den "100" - warum nicht gleich "300"? (Spartaaaaaa!)

[Gipsel]

ALU Reorder ;)Please elaborate!
Kann ich nicht.
Und zu den "100" - warum nicht gleich "300"? (Spartaaaaaa!)Das hätten sie auch genauso gut Hydra nennen können. Aber der Name ist wohl schon belegt :rolleyes:
Hauptsache viele Köpfe und Arme. Die werden einfach nicht weniger ;)

[AnarchX]

ALU Reorder ;)

Mal eine wilde Spekulation, wenn an den "50 Köpfen" vielleicht doch mehr dran ist:
50 Cluster je 4 TMUs, 16 MIMD SP-FMAs(DP half-rate) @hot clock , 384-Bit GDDR5 >6Gbps.

[Ailuros]

Gott im Himmel dann haetten sie es auch Legion oder etwas aehnliches nennen koennen. Fuer mich als Grieche ist es leicht Hecatoncheires auszusprechen und sich auch zu merken, aber fuer alle anderen ist es ein Zungenbrecher.

Und zu den "100" - warum nicht gleich "300"? (Spartaaaaaa!)

Weil Hecatoncheires eine militaerische Menge darstellt wie eben auch Legion. Wenn man schon zu Leonidas und seinen 300 greifen wuerde, waere der bestmoegliche Codename Efialtis. Der Name des Verraeters der den Persen den Zugang auf die Rueckflanken der 300 verriet und seither nennt man in neugriechisch efialtis = Albtraum ;)

Mal eine wilde Spekulation, wenn an den "50 Köpfen" vielleicht doch mehr dran ist:
50 Cluster je 4 TMUs, 16 MIMD SP-FMAs(DP half-rate) @hot clock , 384-Bit GDDR5 >6Gbps.

Nochmal es handelt sich um einen refresh.

[reunion]

Nochmal es handelt sich um einen refresh.

Ich dachte R9xx soll eine neue Architektur werden?

[S940]

Ich dachte R9xx soll eine neue Architektur werden?
Das sagen ein paar Leute, die Wissen deswegen aber auch nicht mehr ...

Mir würde eh nicht einleuchten, was man an der 4+1 ALU Architektur verbessern sollte.

Maximal bastelt man an den Gruppierungen herum. Die 5000er Serie hat ja jetzt durch die 2 Gruppen a 800 Shader hat eine Hierarchiestufe zugelegt.

Möglich, dass sie das jetzt besser aufteilen wollen / können kA.

Auf alle Fälle ist, bei - sagen wir mal ~4000 SPUs - eine neue Speicherverwaltung nötig. Also größere Umbauten, wobei die einzelne 4+1 SPU aber wohl erhalten bleibt. Das ist meine Privatspekulation zu dem Thema.

ciao

Alex

[Ailuros]

Ich dachte R9xx soll eine neue Architektur werden?

Ich rede offensichtlich von RV9x0/28nm=2011 und nicht von 2010 Material ;)

[AnarchX]

Was dann heißt, das wir hier über 40nm reden oder 32nm@TSMC?
Bei ersterem würde ich nicht wirklich Sinn sehen, wenn vielleicht ein halbes Jahr später eine neue Architektur@28nm am Start ist, außer es sind ein paar taktoptimierte Evergreen mit der Unterstützung von 6Gbps+ GDDR5.

[Ailuros]

Ein jeglicher Refresh ist nichts anderes als ein Zwischenschieber. Warum Resourcen dick verplempern wenn man sehr leicht mit hoeheren Frequenzen eine Loesung bekommen kann die wie jeder Refresh etwas schneller ist als der Vorgaenger?

[reunion]

Ich rede offensichtlich von RV9x0/28nm=2011 und nicht von 2010 Material ;)

Und wenn R9xx doch noch 2010 kommt? :)

[Ailuros]

Und wenn R9xx doch noch 2010 kommt? :)

Dann waere es eins der wenige Male wo ich NICHT ueber den zu optimistischen Threadtitel haette lachen sollen *kicher*

http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6524641&postcount=3

[reunion]

Zumindest taucht ein "ASIC_R9XX" ja schon mal im Treiber auf:
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=7573205#post7573205

[Ailuros]

Zumindest taucht ein "ASIC_R9XX" ja schon mal im Treiber auf:
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=7573205#post7573205

Kann ich nicht wissen. Ich weiss lediglich dass irgendwo H1 10' ein refresh vorliegt und dann die naechste "Generation" wenn immer 28nm verfuegbar sein wird.

[w0mbat]

NH schreibt ja auch dass die Verfügbarkeit vom Prozess abhängt. Sie schreiben bei GF wird es wohl Q4`10 werden, je nach dem wie es da läuft eben auch später. Der Refresh ist klar, hat NH auch erwähnt, kommt aber wohl noch in 40nm.

[Gipsel]

Zumindest taucht ein "ASIC_R9XX" ja schon mal im Treiber auf:
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=7573205#post7573205
Wurde nicht schon mal gesagt, daß das heißt, der Chip liegt in wesentlichen Zügen als RTL (http://de.wikipedia.org/wiki/Register_Transfer_Level) (z.B. Verilog) modelliert vor? Das kann dann auch noch ein Jahr dauern, bis er funktionsfähig aus der Fab kommt.

[MR2]

http://www.computerbase.de/bildstrecke/27108/1/

Auf AMDs DesktopRoadmap Folie steht zumindest Next-Gen ATI discrete graphics für 2011. Ich schätze mal im 2 Quartal 2010 kommt der Refresh des RV870.

[w0mbat]

Da steht die Scorpius Plattform und da gibt es die neuen DX11er eben schon. Sagt nichts über den Launch der GPUs selber aus.

[Gast]

Zumindest taucht ein "ASIC_R9XX" ja schon mal im Treiber auf:
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=7573205#post7573205

Sorry, dass ich deine Träume stören muss:
http://www.semiaccurate.com/forums/showpost.php?p=7898&postcount=6


–Carsten

[Ailuros]

http://forum.beyond3d.com/showthread.php?t=55313&page=2

[Gipsel]

Sorry, dass ich deine Träume stören muss:
http://www.semiaccurate.com/forums/showpost.php?p=7898&postcount=6

–Carsten
Und? Da habe ich lediglich bezweifelt, daß die Inseln die 28nm Mobil-Chips sind. R9XX steht im Treiber. Genauso wie RV870 und RV830 schon im Cat8.12 drin waren. Und nein, das ist keine Verarsche.

[reunion]

Sorry, dass ich deine Träume stören muss:
http://www.semiaccurate.com/forums/showpost.php?p=7898&postcount=6


–Carsten

Wenn ich schreibe das ein "ASIC_R9XX" im Treiber auftaucht, was Fakt ist, dann zerstörst du mit soetwas meine Träume? Ganz davon abgesehen das du keine Ahnung haben kannst was ich träume weiß ich nicht was du mit diesem Beitrag bezwecken willst außer mich persönlich anzupatzen. Aber es tut mir Leid falls ich deine Träume mit diesem, von dir zitierten Beitrag zerstört haben sollte.

[Gipsel]

http://forum.beyond3d.com/showthread.php?t=55313&page=2
Das hat er beim Update editiert. Ursprünglich hat es da gestanden ;)
Siehe auch hier (http://www.xtremesystems.org/forums/showthread.php?p=4050000#post4050000) und hier (http://www.xtremesystems.org/forums/showthread.php?p=4050497#post4050497). Aus dem Letzteren:
But before the update of that news item it really looked like you would refer to a beta driver for the names. ;)I realized that and changed it since that was not my intent (and lesson learned don't post news late Saunday night) :)

[Ailuros]

Das hat er beim Update editiert. Ursprünglich hat es da gestanden ;)
Siehe auch hier (http://www.xtremesystems.org/forums/showthread.php?p=4050000#post4050000) und hier (http://www.xtremesystems.org/forums/showthread.php?p=4050497#post4050497). Aus dem Letzteren:

Ich hab eigentlich auf neliz und Charlie's Beitraege gedeutet ;)

[Gast]

FUD-zilla spuckt ein paar Namen aus (Briareos, Gyes and Kottos) und sagt etwas von "MIMD-Shaders" - oh wie spannend ;)

http://www.fudzilla.com/content/view/15918/1/

[w0mbat]

MIMD?

[reunion]

SIMD - Single Instruction Multiple Data
MIMD - Multiple Instruction Multiple data

Der Vorteil ggü. heutigen SIMD-Architekturen wäre also das jede Einheit eine andere Funktion ausführen kann.

[Ailuros]

MIMD?

Nicht schon wieder....:rolleyes:

[mboeller]

gerade gesucht und gefunden:

www.engr.colostate.edu/~hj/conferences/133.pdf

Nette Aufzählung der Vor- und Nachteile von SIMD und MIMD

[Ailuros]

Nur weil es gerade passt dass man Beschreibung X oder Y je nach belieben missbraucht heisst es nicht dass die Beschreibung auch der Wahrheit entspricht.

http://forum.beyond3d.com/showpost.php?p=1345892&postcount=757

MIMD, SIMD, etc. are all just relatively vague categorizations from the earlier days of computing. They are basically meaningless as most people use them.

SSE is a SIMD instruction set because you cannot simultaneously execute different operations on different elements of a vector. The same is true of a warp in NV's architecture - you end up predicating.

Fermi itself might be considered MIMD, but then again so is a dual-core P4...

MIMD, SIMD, SISD and MISD are all meaningless unless you specify the granularity.

[seruss]

MIMD im Sinne von jeder Shadercore kann seine eigene Instruktion, oder jeder Shadercluster?

[Gast_mboeller]

http://perilsofparallel.blogspot.com/2008/09/larrabee-vs-nvidia-mimd-vs-simd.html

Ziemlich gute Einführung IMHO

[Ailuros]

MIMD im Sinne von jeder Shadercore kann seine eigene Instruktion, oder jeder Shadercluster?

Bei MIMD geht es theoretisch um mehrere als eine parallele Instruktion pro cluster/SM.

[Ailuros]

http://perilsofparallel.blogspot.com/2008/09/larrabee-vs-nvidia-mimd-vs-simd.html

Ziemlich gute Einführung IMHO

Weder Larabee noch Fermi haben MIMD Einheiten. Hier hast Du einen MIMD core der auch im Herz des SGX liegt:

http://www.audiodesignline.com/183701195;jsessionid=RPJGLFLOGUWYSQSNDLOSKH0CJUNN2JVN?pgno=1

[Gast]

Und? Da habe ich lediglich bezweifelt, daß die Inseln die 28nm Mobil-Chips sind. R9XX steht im Treiber. Genauso wie RV870 und RV830 schon im Cat8.12 drin waren. Und nein, das ist keine Verarsche.
Dann bitte ich vielmals um Entschuldigung, auch reunion, da ich deinen Beitrag dort offenbar mißinterpretiert habe.

–Carsten

[seruss]

Bei MIMD geht es theoretisch um mehrere als eine parallele Instruktion pro cluster/SM.

Was ich meinte war, dass es (wie in deinem beyond3d quote von davor) auf die Granularitaet ankommt. Wenn man es auf Clusterebene anschaut, sagt MIMD etwas anderes aus, als wenn man die Coreebene betrachtet.

[Ailuros]

Was ich meinte war, dass es (wie in deinem beyond3d quote von davor) auf die Granularitaet ankommt. Wenn man es auf Clusterebene anschaut, sagt MIMD etwas anderes aus, als wenn man die Coreebene betrachtet.

Ich hab mich nicht klar genugt ausgedrueckt: wo immer in letzter Zeit (sei es Fermi oder ATI's naechste Generation) MIMD auftaucht ist die clusterebene gemeint. Nur handelt es sich in einem solchen Fall eher um optimierte SIMD Einheiten die unter Umstaenden MIMD Effizienz erreichen koennen gerade da wo SIMDs kraenkeln als alles andere.

Der Abstand zu reinen MIMD Einheiten ist aber trotzdem immer noch gross; es handelt sich nicht um heterogene Prozessoren wo mehr als nur eine Instruktionsfamilie unterstuetzt wird (wie z.B. ein core ist faehig sowohl skalare als auch VLiW Instruktionen auszufuehren) und Instruktionen werden auch nicht in einem Zyklus ausgefuehrt.

Man koennte das Ganze selbstverstaendlich als Haarspalterei nennen, aber irgendwo muss man schon einen Strich ziehen zwischen Marketing-Geblubber die verschiedene Begriffe einfach missbrauchen und wie genau jegliche Aufgaube ausgefuehrt wird und mit welcher Effizienz. Bis jetzt hat uns AMD's Marketing-Abteilung "superskalare" Einheiten verkauft (und es ist auch nicht das erste Mal dass ich es erwaehne...); wenn man jetzt bei einer neuen Generation durch Optimierungen stellenweise MIMD Effizienz erreichen kann dann ist es wohl dann "superscalar with cheese".

Und nein NVIDIA ist mit dem Missbrauch von diversen Bezeichnungen alles andere als unschuldig.

[Gipsel]

Ich hab mich nicht klar genugt ausgedrueckt: wo immer in letzter Zeit (sei es Fermi oder ATI's naechste Generation) MIMD auftaucht ist die clusterebene gemeint. Nur handelt es sich in einem solchen Fall eher um optimierte SIMD Einheiten die unter Umstaenden MIMD Effizienz erreichen koennen gerade da wo SIMDs kraenkeln als alles andere.

Der Abstand zu reinen MIMD Einheiten ist aber trotzdem immer noch gross; es handelt sich nicht um heterogene Prozessoren wo mehr als nur eine Instruktionsfamilie unterstuetzt wird (wie z.B. ein core ist faehig sowohl skalare als auch VLiW Instruktionen auszufuehren) und Instruktionen werden auch nicht in einem Zyklus ausgefuehrt.

Man koennte das Ganze selbstverstaendlich als Haarspalterei nennen, aber irgendwo muss man schon einen Strich ziehen zwischen Marketing-Geblubber die verschiedene Begriffe einfach missbrauchen und wie genau jegliche Aufgaube ausgefuehrt wird und mit welcher Effizienz. Bis jetzt hat uns AMD's Marketing-Abteilung "superskalare" Einheiten verkauft (und es ist auch nicht das erste Mal dass ich es erwaehne...); wenn man jetzt bei einer neuen Generation durch Optimierungen stellenweise MIMD Effizienz erreichen kann dann ist es wohl dann "superscalar with cheese".

Und nein NVIDIA ist mit dem Missbrauch von diversen Bezeichnungen alles andere als unschuldig.
Nun, die ATIs sind in einem gewissen Sinne schon "super" und VLIW ist eigentlich per Definition superskalar. Allerdings paßt für einen SIMD-Cluster der ATIs der Begriff "supervektoriell" eigentlich besser. Im Prinzip sind es ja einfach 5 parallele Vektorpipelines, die entweder unabhängig (normale single precision Anweisungen) oder aber auch teilweise gekoppelt (double precision, dot products) arbeiten können und mit einer VLIW-Anweisung gefüttert werden. Aber wenn nvidia skalare Vektoreinheiten hat (sic!), dann hat ATI auch superskalare SIMD-Einheiten. ;)

Ich bin recht gespannt, was uns da mit R9XX für Änderungen erwartet. Hoffentlich mehr, als von den nvidia MIMD-Gerüchten übriggeblieben ist. Die concurrent Kernels und Predication Support (den gibt es bei ATI schon ewig!) sind zwar sicher gut und hilfreich, aber alles andere als eine Revolution.

[Aquaschaf]

Predication Support (den gibt es bei ATI schon ewig!)

Den gibts bei NVidia auch schon ewig. Einzig neu ist dass predicated instructions nun in der PTX-Zwischensprache sichtbar sind, bis dato wurden die erst beim Schritt PTX -> Binary eingefügt.

[Gipsel]

Den gibts bei NVidia auch schon ewig. Einzig neu ist dass predicated instructions nun in der PTX-Zwischensprache sichtbar sind, bis dato wurden die erst beim Schritt PTX -> Binary eingefügt.
Hmm, also ich habe da was anderes gehört. Bisher wurden wohl explizite Branches ausgeführt, nix mit predication. Das ist auch mit ein Grund, warum nvidia bei kleinen if-then-else Konstrukten im Vergleich zu ATI oft ziemlich mies abschneidet. David Kanter schreibt zum Beispiel (http://www.realworldtech.com/page.cfm?ArticleID=RWT093009110932&p=5):
Fermi introduces full predication for all instructions to improve the instruction fetch by removing bubbles caused by taken branches. In GT200, a divergence would result in a warp executing through and then branching between each control flow path. At each branch, the warp would stall until the branch could be resolved and the next address fetched. With predication, the warp can sequentially execute through all the divergent control flow paths, without branches, and simply mask off the unused vector lanes.
Ich gebe ja zu, daß GT200 laut nvidia angeblich auch schon Predication kann. Aber warum bewirbt es nvidia dann für Fermi? Wahrscheinlich kann bisher nicht der komplette Branch maskiert werden, sondern es gibt im Prinzip nur ein conditional Move am Ende, der das Ergebnis setzt. Das würde ich jetzt aber nicht wirklich als "echte" Predication ansehen.

[Aquaschaf]

Hmm, also ich habe da was anderes gehört. Bisher wurden wohl explizite Branches ausgeführt, nix mit predication.

Einerseits steht im Cuda Programming Guide dass predication verwendet wird bei kurzen Sprüngen. Andererseits hat man im Cuda Profiler einen Counter für Warp-Divergenzen. Und z.B. dieses Stück Code erzeugt laut Profiler keine Divergenzen. Was ohne predicated instructions nicht sein könnte.

for (int j = 0; j < K; j++)
{
if (bst[pos[threadIdx.x] - 1] < element)
pos[threadIdx.x] = (pos[threadIdx.x] << 1) + 1;
else pos[threadIdx.x] <<= 1;
}

Wahrscheinlich kann bisher nicht der komplette Branch maskiert werden, sondern es gibt im Prinzip nur ein conditional Move am Ende, der das Ergebnis setzt. Das würde ich jetzt aber nicht wirklich als "echte" Predication ansehen.

Das ist natürlich möglich. Wo zieht man die Grenze was "echte" Predication ist, muss es alle Instruktionen mit predication bit geben? Ich würde es einfach darüber definieren, dass kein Sprung durchgeführt werden muss wenn der Mechanismus greift. Alles über einen conditional move zu realisieren ist zwar die primitivste Variante, aber dieses Ziel wird damit auch schon erreicht.

[Coda]

Hmm, also ich habe da was anderes gehört. Bisher wurden wohl explizite Branches ausgeführt, nix mit predication.
Predication konnte schon NV40. Ich bitte dich. Das ist so einfach umzusetzen, dass es sich kaum lohnen würde es überhaupt nicht zu machen. Writemask und fertig.

[Gipsel]

Aber warum betont nvidia dann den Support von "full predication for all instructions" als Neuerung für Fermi. Was hat sich denn wirklich geändert? Ist doch bestimmt so eine Geschichte a la "Full HD" und "Half HD" ;D. Oder schlicht Marketing?

[Gipsel]

Wir sind ja hier im R900 Thread, nicht? Und wie es aussieht, stehen mit "Northern Islands" wohl wirklich ein paar umfassendere Änderungen ins Haus. Northern Islands ist wirklich der interne Codename beim Treiberteam, inwiefern da Cozumel, Ibiza und Kauai reinpassen, erschließt sich da nicht sofort, es sei denn, das sollen die Southern Islands werden ;)

Aber zu den Änderungen. Es werden wohl ein paar alte Instruktionen gestrichen und die t-Einheit auch etwas stärker geändert. So kann die t-Einheit in Zukunft nicht mehr alle normalen Instruktionen ebenfalls ausführen. Sie wird wahrscheinlich also eher einer SFU von nvidia ähneln. Der generelle Aufbau der VLIW-Einheiten bleibt aber erhalten.

Zum ominösen "ALU reorder" kann ich jetzt so viel sagen, daß es scheinbar wirklich eine Umordnung der einzelnen VLIW-Bundles ist, also könnte es eine Art einfache out-of-order-Exekution (die Befehle innerhalb eines Bundles umzuordnen würde ja wenig bringen) sein. Damit ist dann statisch (zur Compilezeit) nicht mehr klar, welche Instruktionen in den vorherigen Takten ausgeführt wurden, so daß man die pipelineinternen Register "previous scalar" bzw. "previous vector" in dem Fall nicht mehr benutzen kann. Dieses Feature wird also wahrscheinlich immer nur für kurze Gruppen von VLIW-Anweisungen aktiviert werden (an mehr read-/write-Ports bzw. kürzeren Latenzen zweifle ich).
Alternative Erklärung wäre die zwischenzeitlich für GT300 mal aufgetauchte dynamische Warp-Formation. Hier wird ja praktisch die Zuordnung eines Threads zu einem Slot der Vektor-Pipelines in einem SIMD geändert, womit hier für die jeweils erste Anweisung nach so einer Umordnung ebenfalls die PV bzw. PS-Register nicht verfügbar sind.
Und falls sich einer wundert, warum ich auf den PV bzw. PS-Registern rumreite, der Nebeneffekt von ALU reorder ist gerade, daß man die nicht verwenden kann, wenn das zum Einsatz kommt. Daraus kann man jetzt jeder seine Schlüsse ziehen, zwei mögliche Erklärungen habe ich schon mal angeboten.

[Aquaschaf]

Alternative Erklärung wäre die zwischenzeitlich für GT300 mal aufgetauchte dynamische Warp-Formation. Hier wird ja praktisch die Zuordnung eines Threads zu einem Slot der Vektor-Pipelines in einem SIMD geändert, womit hier für die jeweils erste Anweisung nach so einer Umordnung ebenfalls die PV bzw. PS-Register nicht verfügbar sind.

Wenn ich das noch richtig im Kopf habe ist bei der Geschichte nicht ganz klar ob der zusätzliche Verwaltungsaufwand sich letztendlich rentiert?

[Coda]

Aber warum betont nvidia dann den Support von "full predication for all instructions" als Neuerung für Fermi.
Ich gehe davon aus, dass es bisher ein paar Ausnahmen von der Regel gab. Evtl. mal die Nouveau-Leute fragen.

Edit: Also der Nouveau "NV50"-Treiber emittiert definitiv predication (root/src/gallium/drivers/nv50/nv50_program.c im MESA git-Tree). Es scheint aber tatsächlich ein paar Ausnahmen zu geben.

[Gipsel]

Einerseits steht im Cuda Programming Guide dass predication verwendet wird bei kurzen Sprüngen. Andererseits hat man im Cuda Profiler einen Counter für Warp-Divergenzen. Und z.B. dieses Stück Code erzeugt laut Profiler keine Divergenzen. Was ohne predicated instructions nicht sein könnte.

for (int j = 0; j < K; j++)
{
if (bst[pos[threadIdx.x] - 1] < element)
pos[threadIdx.x] = (pos[threadIdx.x] << 1) + 1;
else pos[threadIdx.x] <<= 1;
}

[Zitat meiner Bemerkung zu Conditional Moves]

Das ist natürlich möglich. Wo zieht man die Grenze was "echte" Predication ist, muss es alle Instruktionen mit predication bit geben? Ich würde es einfach darüber definieren, dass kein Sprung durchgeführt werden muss wenn der Mechanismus greift. Alles über einen conditional move zu realisieren ist zwar die primitivste Variante, aber dieses Ziel wird damit auch schon erreicht.
Das ist ehrlich gesagt ein schlechtes Beispiel, weil hierfür ein Conditional Move meiner Meinung nach sogar das Optimum darstellt (die einzelnen Zweige haben keine Nebeneffekte, es wird nur ein einzelner Wert manipuliert). Auf ATIs würde der Compiler das ziemlich sicher damit lösen (hab's jetzt aber nicht überprüft) und sogar auf einer CPU wäre es wohl das Schnellste. Würde mich fast überraschen, wenn das bei nv anders sein sollte.

Edit: Back to Topic! ;)

[Coda]

Ein CMOV ist auch eine Art conditional instruction. Aber es sind def. nicht nur Movs.

[Ailuros]

Nun, die ATIs sind in einem gewissen Sinne schon "super" und VLIW ist eigentlich per Definition superskalar. Allerdings paßt für einen SIMD-Cluster der ATIs der Begriff "supervektoriell" eigentlich besser. Im Prinzip sind es ja einfach 5 parallele Vektorpipelines, die entweder unabhängig (normale single precision Anweisungen) oder aber auch teilweise gekoppelt (double precision, dot products) arbeiten können und mit einer VLIW-Anweisung gefüttert werden. Aber wenn nvidia skalare Vektoreinheiten hat (sic!), dann hat ATI auch superskalare SIMD-Einheiten. ;)

Ich bin recht gespannt, was uns da mit R9XX für Änderungen erwartet. Hoffentlich mehr, als von den nvidia MIMD-Gerüchten übriggeblieben ist. Die concurrent Kernels und Predication Support (den gibt es bei ATI schon ewig!) sind zwar sicher gut und hilfreich, aber alles andere als eine Revolution.

Ich hab es sowieso schwer NV's Einheiten skalar (stets im strengen Sinn) zu bezeichnen, ergo ist es unter dieser Logik einfacher zu verstehen wie ich zu solchen Bezeichnungen generell stehe.

Du kannst ja auch nachzaehlen wie oft ich die GF100/MIMD Geruechte (vergebens) versucht habe in der Vergangenheit totzuschlagen. Dally hat schon vor dem Fermi launch das Thema auf die richtige Ebene gesetzt in seinem PCGH Interview (MIMD vielleicht in der Zukunft blahblahblah).

Man sollte sich auch fragen (denn MIMD hat offensichtlich sowohl Vor- als auch Nachteile gegenueber optimierten SIMD Einheiten) was das eigentliche Ziel genau ist. Im Fall von IMG sind es ganz andere Ziele. Der META war ein GPP der eine logische Entwicklung vor Jahren war fuer multimedia Schnickschnack (wer ein Bild von der historischen Transputer Technologie hat kann es vielleicht leichter verstehen); bis zum SGX wurde nichts von diesem IP in die GPU IP integriert. Heutzutage braucht man fuer eine jeglichen SoC nicht nur Grafik-Faehigkeiten sondern es tauchen auch links und rechts multimedia only CoProzessoren auf (siehe Creative Zii oder Intel's multimedia SIMD etc) fuer ultra low end multimedia only Zeug. Fuer Geraete die nicht das geringste mit 3D zu tun haben sind dann solche Co-Prozessoren ideal; sie nehmen sehr wenig Platz ein und verdampfen auch viel weniger Strom als selbst der kleinste eingebettete 3D core.

Irgendwo entlang der Linie wird sich auch Fusion bewegen und es wuerde mich auch kein bisschen wundern wenn AMD bei der Fusion/2011 top to bottom Linie zu etwas greifen wuerde dass naeher an der MIMD Bezeichnung liegt als das was wir bei Fermi sehen. Sie muessen aber auch trotz allem vorsichtig sein nicht ihrer Zeit zuweit vorzuentwickeln denn die R600 Fehler moechten sie wohl keinesfalls wiederholen.

Dieses ALU_REORDER dass Du aufgeschnappt hast koennte zwar in die Richtung deuten, aber ich will auch hoffen dass bei jeder context switch auch mit 0 overhead kommen wird. Denn eine Loesung in der Art optimiertes SIMD ich verstecke die Latenz durch X klingt mir dann wieder schon in Fermi Richtung.

[deekey777]

Nur so ein Gedanke: Jetzt nehmen wir an, die Wavefront-Größe ist beim R100 (:biggrin:) aufeinmal ein Quad. Kleiner geht es ja nicht. Ist das jetzt MIMD? Oder SIMD? Oder ist das nicht egal, wie man das definitiert?

[Aquaschaf]

Das ist ehrlich gesagt ein schlechtes Beispiel, weil hierfür ein Conditional Move meiner Meinung nach sogar das Optimum darstellt

Sicher? Verbraucht eine Realisierung per conditional move nicht zumindest ein zusätzliches Register und führt zu einem zusätzlichen Lese- und Schreibzugriff demgegenüber wenn die Befehle alle ein predication bit haben?

[Gipsel]

Sicher? Verbraucht eine Realisierung per conditional move nicht zumindest ein zusätzliches Register und führt zu einem zusätzlichen Lese- und Schreibzugriff demgegenüber wenn die Befehle alle ein predication bit haben?
Nun, wenn Du Befehle per Predication ausblendest, wird ja im Prinzip nur das Schreiben der Register (oder des Speichers) geblockt. Die Instruktionen belegen aber trotzdem Platz im Instruktionsstream und es wird nicht schneller, das hilft also nicht (höchstens dem Stromverbrauch ;)). Für Dein Beispiel-Konstrukt wird ja nicht jedes mal wenn Du pos[threadID.x] schreibst, auch wirklich ein Speicherzugriff ausgeführt, das wäre viel zu langsam. Für sowas legt der Compiler den Wert sowieso in ein Register ab und die Bandbreite auf die Register ist kein Problem. Da hilft predication also überhaupt nicht. Der Vorteil liegt wirklich nur darin, daß der Overhead durch die Branches minimiert wird. Und für Dein Beispiel ist die Lösung mit dem Conditional Move im Prinzip noch etwas günstiger, da man sich zusätzlich das Setzen und Löschen des Predication Bit spart. Im Prinzip deshalb, da das sowieso hart durch die Speicherzugriffe limitiert wird, es also für die Performance in diesem Beispiel ziemlich egal ist, wie man das genau macht.

Habe das übrigens mal in den StreamKernelAnalyzer gehauen und auf ATI erzeugt der Compiler wie vermutet wirklich ein Conditional Move dafür. Die Schleife rundherum wird gnadenlos wegoptimiert (wozu sollte die eigentlich gut sein?), es bleiben 4 ALU-Instruktionen übrig, die insgesamt (inklusive der Adressberechnung für Speicherzugriff) nur 3 Register belegen. Aber limitierend sind wie gesagt sowieso die 3 Speicherzugriffe (2 lesend, 1 schreibend).

Ohne Conditional Move aber dafür mit Predication könnte man vielleicht wirklich noch ein Register sparen. Allerdings ist das auf RV770/RV870 aber auch GT200 selten ein wirkliches Problem und zum anderen kann oft dafür irgendein anderes Register wiederverwendet werden. Insbesondere bei den ATIs geht das meist sehr gut (und der Compiler macht in der Beziehung meist auch einen guten Job).

[Gipsel]

Nur so ein Gedanke: Jetzt nehmen wir an, die Wavefront-Größe ist beim R100 (:biggrin:) aufeinmal ein Quad. Kleiner geht es ja nicht. Ist das jetzt MIMD? Oder SIMD? Oder ist das nicht egal, wie man das definitiert?
Die Quads sind sowieso nur noch für Pixelshader von Belang (der Rasterizer spuckt immer 2x2 Quads aus), für ComputeShader gibt es die jetzt schon nicht mehr.

Die Wavefront-Größe ergibt sich da aus der Anzahl und Gewschwindigkeit der Scheduler im Verhältnis zur Anzahl der Einheiten. Es gibt für einen SIMD bei ATI momentan im Prinzip 2 Scheduler, die beide alle 8 Takte eine komplette Wavefront absetzen (also 2 Wavefronts über 8 Takte verteilt). ATI müßte die Anzahl und/oder Geschwindigkeit der Scheduler massiv steigern, um kleinere Wavefronts zu erhalten. Man könnte also auf 16er Wavefronts gehen ohne zu viel an der internen Struktur der SIMDs ändern zu müssen, falls die Scheduler 4 mal so viele Wavefronts 4 mal so schnell verwalten könnten. Ein ziemlich großes "falls" für meinen Geschmack. Noch kleinere Wavefronts erfordern die Verkleinerung der SIMDs, was noch höheren Verwaltungsaufwand nach sich zieht. Man sieht ja, daß nvidia mit Fermi ihre Vektoreinheiten vergrößert hat (von 8 auf 16 Slots), ich denke nicht wirklich, daß ATI da den umgekehrten Weg geht.

[Coda]

Es gibt für einen SIMD bei ATI momentan im Prinzip 2 Scheduler, die beide alle 8 Takte eine komplette Wavefront absetzen (also 2 Wavefronts über 8 Takte verteilt). ATI müßte die Anzahl und/oder Geschwindigkeit der Scheduler massiv steigern, um kleinere Wavefronts zu erhalten.
Man könnte auch einfach 8er SIMDs verbauen, so wie bei den kleineren Karten. Die haben nämlich tatsächlich auch kleinere Wavefronts. Was effektiv aber auch dazu führt dass man mehr Scheduler verbaut ;)

[Gipsel]

Man könnte auch einfach 8er SIMDs verbauen, so wie bei den kleineren Karten. Die haben nämlich tatsächlich auch kleinere Wavefronts. Was effektiv aber auch dazu führt dass man mehr Scheduler verbaut ;)
Ich weiß (daran habe ich Ailuros schon ein paar mal erinnert ;)), ändert aber nichts daran, daß dann der Verwaltungsaufwand im Verhältnis zur ALU-Leistung größer wird. Bei kleineren SIMDs kann man nämlich an den Schedulern nicht viel sparen. Wenn man die Scheduler-Anzahl nicht erhöhen will, müssten sie schneller werden und mehr Waverfronts in flight halten können, wie ich schon schrieb.

[Aquaschaf]

(wozu sollte die eigentlich gut sein?)

OT: im Array bst liegt ein binärer Suchbaum (an Stelle 0 die Wurzel, an 1, 2 die Kinder von 0, an Stelle 3, 4 die Kinder von 1 usw.). K ist log2 der halben Größe des Suchbaums, und ein Durchlauf der Schleife - die jeder Compiler unrollen dürfte - entspricht einer Traversierung des Suchbaums (siehe auch: http://arxiv.org/abs/0909.5649) ;) Aber ja, auf G200 dürfte die Registerzahl selten ein Problem darstellen.

[Coda]

Zum ominösen "ALU reorder" kann ich jetzt so viel sagen, daß es scheinbar wirklich eine Umordnung der einzelnen VLIW-Bundles ist, also könnte es eine Art einfache out-of-order-Exekution (die Befehle innerhalb eines Bundles umzuordnen würde ja wenig bringen) sein.
Ach genau, dazu wollte ich ja auch noch was sagen.

Halte ich für ziemlich unwahrscheinlich. Davon hab ich es mit dir vor einiger Zeit schonmal gehabt. Das war einer der Punkte in dem ich die VLIW-Architektur zukünftig für problematisch halte.

Das Problem ist, dass man nicht nur eine Abhängigkeit pro VLIW-Instruction haben kann sondern bis zu fünf verschiedene. Die Logik die da irgendwie erkennen kann ob man überhaupt mal was umsortieren kann müsste ziemlich groß sein. In einem Streamprozessor mit hoher Compute-Density hat man eigentlich keinen Platz für solche Späße.

Und um überhaupt Leistung rauszuholen müsste man wohl den Compiler weiter darin einschränken wie er Instructions verteilt.

[Gipsel]

Ach genau, dazu wollte ich ja auch noch was sagen.

Halte ich für ziemlich unwahrscheinlich. Davon hab ich es mit dir vor einiger Zeit schonmal gehabt. Das war einer der Punkte in dem ich die VLIW-Architektur zukünftig für problematisch halte.

Das Problem ist, dass man nicht nur eine Abhängigkeit pro VLIW-Instruction haben kann sondern bis zu fünf verschiedene. Die Logik die da irgendwie erkennen kann ob man überhaupt mal was umsortieren kann müsste ziemlich groß sein. In einem Streamprozessor mit hoher Compute-Density hat man eigentlich keinen Platz für solche Späße.

Und um überhaupt Leistung rauszuholen müsste man wohl den Compiler weiter darin einschränken wie er Instructions verteilt.
Wohl gerade deswegen kann man ja nicht mehr auf die PS/PV-Register zugreifen, wenn ALU reorder aktiv ist ;). Nur über die besteht nämlich eine unmittelbare Abhängigkeit zu den vorhergehenden (oder nachfolgenden) VLIW-Bundles.

Der Compiler legt ja die zu benutzenden Hardware-Register fest (der Scheduler addiert für jede Wavefront noch einen individuellen Offset). Solange die Kausalität durch eine Umordnung nicht zerstört wird (Register xy wird gelesen, bevor eine andere Anweisung dort den nötigen Wert geschrieben hat), ist eine Umordnung überhaupt kein Problem und vom Scheduler vergleichsweise einfach zu handhaben (es gibt ja z.B. kein Register-Renaming, was das ganze ordentlich verkomplizieren würde). Der einzige Unterschied könnte sein, daß die effektive Latenz der VLIW-Bundles auf 2 Instruktionen hochgeht (wegen dem Fehlen der PV/PS-Register), genausogut könnte das Result-Forwarding aber auch aufwendiger gelöst worden sein bzw. die SIMD-Größe wirklich auf 8 Einheiten runtergeschraubt werden (bei weiterhin 64er Wavefronts oder einfach schnelleren Schedulern).

Bei den momentanen Einheiten bringt das allerdings so ziemlich gar nichts, da durch die identischen Latenzen aller Instruktionen das Verhalten statisch zur Compilezeit bekannt ist. Das würde nur Vorteile bieten, wenn das ganze Instruktion-Scheduling dynamisch sein muß, sprich, verschiedene Instruktionen verschiedene Latenzen haben und die Last-Situation eines SIMDs nicht vorhersagbar ist. Das wäre ein ziemlich großer Schritt, weswegen ich auch die dynamische Warp-Formation zu diesem Zeitpunkt keineswegs ausschließen würde.

Allgemein gesehen ist der Job bei einem VLIW-Design schonmal viel einfacher als z.B. bei x86, wo eine prinzipiell skalare inorder ISA auf einem superskalaren out-of-order Kern ausgeführt wird. Die Abhängigkeiten der Instruktionen untereinander werden ja schon vom Compiler analysiert und parallele Instruktionen in ein VLIW-Bundle gepackt. Register-Allocation macht auch schon der Compiler. Da bleibt dann ziemlich wenig übrig, was die Hardware noch beachten muß ;). Wie schon gesagt ist das eigentlich nur der Zugriff auf die Register/Speicher, die in der richtigen Ordnung bleiben müssen. Nvidias Scheduler machen doch jetzt schon sowas in der Art, oder?

Also nochmal zusammengefaßt, es gibt offensichtlich ALU reorder in der zukünftigen GPUs und in einer umgeordneten Instruktion können die PV/PS-Register nicht benutzt werden (ansonsten scheinbar schon). Zusätzlich kann die t-Unit nicht mehr die (alle?) normalen ALU-Instruktionen ausführen, sie wird wohl mehr zu einer SFU wie bei nvidia (andere Latenzen wie dort auch?). Das ist das, was der Treiber momentan hergibt. Der Rest ist Spekulation. Außer Cozumel, Ibiza und Kauai sind mir auch keine weiteren Codenamen (die genannten Inseln gehören wohl schwerlich zu den ebenfalls auftauchenden Northern Islands) aufgefallen.

[Coda]

Wie schon gesagt ist das eigentlich nur der Zugriff auf die Register/Speicher, die in der richtigen Ordnung bleiben müssen.
"Nur" ist gut. Es geht ja nicht nur darum, dass man dafür Hardware braucht, sondern ich glaube dass man kaum mal überhaupt was umsortieren kann. Vor allem die T-Unit wird wohl öfters genau das vorhergehende Ergebnis direkt wieder brauchen. Eben diese Abhängigkeiten (Read-After-Write) werden durch VLIW deutlich erhöht.

Schau dir doch mal ein typisches Kompilat an.

Wenn dann müsste man das so machen wie bei Itanium und von vornherein VLIW-Bündles definieren die vom Compiler so gebaut werden dass innerhalb von diesen die Ausführung beliebig vertauscht werden kann. Das führt aber wie oben geschrieben dazu dass der Compiler auch genötigt wird die Instructions ineffizienter zu verteilen solche Bündles größer zu machen.

Und am Ende bleibt die Frage: Was nützt das ganze überhaupt? Warum sollte ich bei einem Streamprozessor bei dem jede Instruction virtuell den vollen Durchsatz hat und Speicherlatenzen sowieso versteckt werden Instructions umsortieren wollen?

[Coda]

Noch ein paar Gedanken dazu:

Wieso macht man Out-Of-Order überhaupt? Genau, man kann nur Stalls vermeiden, weil man sowieso nur eine Pipeline hat im Falle von einer GPU.

Statische Abhängigkeiten können bei einer GPU vollständig vom Compiler aufgelöst werden, also ist da die Instruction-Order dank JIT sowieso immer optimal. Da braucht man das definitiv also nicht.

Bleibt noch die Möglichkeit, dass man auf Speicherzugriffe warten muss. Wäre eine Möglichkeit, aber ob sich der Aufwand lohnt wenn man diese eigentlich sowieso verstecken kann? Ich denke nicht.

OOO hilft CPUs auch bei Schleifen, da sie dort auch evtl. ihre Einheiten besser auslasten können. Hilft der GPU aber nicht weil es nur eine Pipeline gibt, und spekulative Ausführung gibt es sowieso nicht.

Bleibt die Sache mit der Branch-Divergenz. Da könnte man anfangen Instructions von divergierenden Threads parallel auszuführen. Das nennt sich dann MIMD und erfordert einen eigenen Instruction-Sequenzer pro Thread. Hat hiermit auch nichts zu tun.

Mir gehen echt die Ideen aus was das eigentlich sein soll.

[Gipsel]

Noch ein paar Gedanken dazu:

Wieso macht man Out-Of-Order überhaupt? Genau, man kann nur Stalls vermeiden, weil man sowieso nur eine Pipeline hat im Falle von einer GPU.

Statische Abhängigkeiten können bei einer GPU vollständig vom Compiler aufgelöst werden, also ist da die Instruction-Order dank JIT sowieso immer optimal. Da braucht man das definitiv also nicht.
Ich weiß, ich habe ja auch schon gesagt, daß das bei RV870 z.B. nichts bringen würde. Deswegen müßten auch anderweitig größere Änderungen an den Einheiten erfolgen, z.B. die Sache mit der t-Einheit. Wenn das eine entkoppelte eigene Pipeline wird, die eine höhere Latenz aufweist (und eine andere Einheitenzahl pro SIMD als die ALUs) ähnlich wie nvidias SFUs. Dann ist die Verfügbarkeit dieser Pipeline ja nicht mehr statisch zur Compilezeit vorherzusagen. Nvidia hat deswegen ja auch deutlich aufwendigere Scheduler als ATI, die machen nämlich schon jetzt sowas in der Art.

Bleibt noch die Möglichkeit, dass man auf Speicherzugriffe warten muss. Wäre eine Möglichkeit, aber ob sich der Aufwand lohnt wenn man diese eigentlich sowieso verstecken kann? Ich denke nicht.Dazu kommt, daß Speicherzugriffe sowieso jetzt schon parallel zu ALU-Instruktionen ausgeführt werden können. Der Compiler versucht im Moment einfach die Speicherzugriffe möglichst früh auszuführen und kann dann die ALU-Instruktionen, die nicht vom gelesenen Wert abhängen parallel ausführen. Bei L1-Hits kann das etwas helfen, aber global gesehen ist das eher unerheblich. Eine weitere Umordnung würde da meiner Meinung nach erst recht nicht mehr helfen.

Bleibt die Sache mit der Branch-Divergenz. Da könnte man anfangen Instructions von divergierenden Threads parallel auszuführen. Das nennt sich dann MIMD und erfordert einen eigenen Instruction-Sequenzer pro Thread. Hat hiermit auch nichts zu tun.

Mir gehen echt die Ideen aus was das eigentlich sein soll.
Nun vor MIMD kam ja noch die dynamic warp/wavefront formation, die ich schon angesprochen habe. Hat man eine Threadgroup mit sagen wir mal 512 Threads (8 Wavefronts) und hat einen Branch, bei dem die Wavefronts divergieren. Sagen wir mal 137 Threads gehen in die eine Richtung, 375 Threads in die andere. Ordnet man jetzt die Threads so um, daß man 3 Wavefronts erzeugt (2*64 + 9 Threads), die alle in die eine Richtung gehen und 6 Wavefronts (5*64 + 55 Threads) die den anderen Weg nehmen, so hat man durch die Umordnung wohl erstmal einiges an Mehraufwand. Allerdings dauert die Rechnung dann nicht mehr 8 * (Dauer Weg A + Dauer Weg B) sondern im schlechtesten Fall Umordnungsoverhead + 9 * Maximum(Dauer Weg A oder B). Im besten Fall wird es deutlich weniger als die "traditionelle" Abarbeitung (bis runter zu 10% oder so bei speziell konstruierten Fällen). Mit ein paar Restriktionen (z.B. Threads können in ihrem Vektorslot bleiben, um die Registerfiles nicht umkopieren zu müssen, bei großen Threadgroups ist diese Einschränkung wohl hinnehmbar, wenn die Divergenzen mehr oder wenig zufällig sind) könnte das sogar recht billig von der Implementation werden. Das erfordert dann ein wenig Heuristik vom Compiler/Scheduler um zu entscheiden, wann eine Umordnung sinnvoll ist oder nicht.

[Coda]

Das Paper über "dynamic warp formation" habe ich dir glaube ich gezeigt anfang des Jahres ;)

[Gipsel]

Das Paper über "dynamic warp formation" habe ich dir glaube ich gezeigt anfang des Jahres ;)
Hmm, ein Paper dazu habe ich ehrlich gesagt nie gelesen :rolleyes:

Hattest Du vor dem Edit nicht eine Suche nach "dynamic warp formation" verlinkt? In dem dort als erstem auftauchenden Posting (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=7256798#post7256798) habe ich übrigens gegen Deine Begründung argumentiert, daß mit VLIW eine dynamic wavefront formation deutlich schwieriger wäre ;)

Außerdem ist sowas wie "dynamic warp formation" (also um Blasen zu füllen bei dyn. Branching) mit VLIW fast unmöglich, weil man dann pro Befehl bis zu 5 verschiedene Abhängigkeiten drin hat.Na das kann man so nicht stehen lassen. Es gibt nur maximal einen Branch pro ALU-Clause (eigentlich sogar gar keinen ;)), d.h. auch nur einen pro VLIW-Einheit.
Wenn ich das heute lese, glaube ich zwar Dich damals mißverstanden zu haben (Du hast wohl von abhängigen Instruktionen geschrieben). Da kann ich heute noch hinzufügen, daß die Abhängigkeiten der Instruktionen selber von vorhergehenden eher keine Rolle dafür spielen. Mal abgesehen davon, daß in der ersten Instruktion nach der Umordnung die PV/PS-Register nicht benutzt werden können ;). Das trifft übrigens allgemein auch auf jedes erste VLIW-Bündel in einer ALU-Clause (der Begriff ist bei ATI-doppelt belegt, einmal für ein einzelnes VLIW-Bündel und dann auch mal für eine Folge von diesen, letzteres ist eigentlich konsistenter) genannten Folge von mehreren Instruktionen zu. An diesen Clause-Grenzen findet bisher immer ein Switch zwischen verschiedenen Wavefronts statt (wenn mehr als 2 pro SIMD laufen). Also im Prinzip führt ALU reorder eventuell dies an einer "Sollbruchstelle" dynamisch aus und nicht statisch vom Compiler festgelegt.

Lustig ist auch mein Post direkt darunter zum RV870 (das war April):
Also ich wäre ja für eine glatte Verdopplung, 32 ROPs, 80 TMUs und 1600 SP. Einfach 20 SIMDs rein und fertig ist der Lack.
Also nur mal soviel zu den ganzen Gerüchteseiten, die was anderes gemeldet haben ;).

Edit:
Habe jetzt mal in das Paper reingeschaut (war bei der vormals von Dir verlinkten Suche beim untersten Ergebnis zu finden). Sieht eigentlich genau so aus, wie ich mir das vorgestellt habe. Sogar das mit dem Verbleiben der Threads in ihrem Vektorslot ist da beschrieben ("lane awareness"). Das muß meiner Meinung nach sogar nur physisch der gleiche Slot sein, sprich bei den 64er Wavefronts und den 16er SIMDs der ATIs hat jeder Thread 4 mögliche Offsets in der neu gebildeten Wavefront, an der er sitzen kann. Ist praktisch das Aquivalent zur Assoziativität bei Caches ;).

[PCGH_Carsten]

Ist eigentlich gesichert, dass Alu-reordering nicht schon in Evergreen genutzt wird? Ich habe da so meine Zweifel.

[Gipsel]

Ist eigentlich gesichert, dass Alu-reordering nicht schon in Evergreen genutzt wird? Ich habe da so meine Zweifel.
Hmm, wäre auch eine Möglichkeit. Wobei sich dann aber erst recht die Frage stellt, was es eigentlich ist. Es ist offensichtlich nicht transparent für den Shader-(CAL-)compiler, wegen der Unmöglichkeit die PV/PS-Register für umgeordnete Befehle zu nutzen. Deswegen wurden sehr viele Befehle in der Intermediate Language dupliziert, die einen mit Zugriffsmöglichkeit auf die PV/PS-Register, die anderen ohne (alles noch undokumentiert und momentan wahrscheinlich nicht nutzbar).

Was in RV870 sollte das denn sein? Die einzige entfernte Geschichte, die mir gerade einfällt, könnte dieses Co-Issue von abhängigen MULs and ADDs sein, aber dafür benötigt man doch nicht so einen Aufwand, da das ebenfalls statisch vom Compiler festgelegt weden kann.

Du hast doch bestimmt (im Gegensatz zu mir) einen Cypress rumliegen, oder? Hast Du da die Möglichkeit in irgendeinem Kernel auf der IL-Ebene mal einen Befehl auszutauschen (gegen so einen undokumentierten)? Dann wüßte man, ob Cypress das kann oder nicht ;). Oder ich sollte mal einfach in die Doku vom neuen OpenCL-SDK schauen, vielleicht ist dann ja schon alles geklärt :rolleyes:

[Gipsel]

Oder ich sollte mal einfach in die Doku vom neuen OpenCL-SDK schauen, vielleicht ist dann ja schon alles geklärt :rolleyes:
Das war eine echt gute Idee:

THIS DOCUMENT INTENTIONALLY LEFT BLANK.
IT WILL BE AVAILABLE IN FUTURE RELEASES.;D

Aber eigentlich benötigt man sowieso die R800 Instruction Set Architecture bzw. die IL-Doku dafür. Die ist sowieso gar nicht dabei.

[Coda]

Gipsel das hatten wir alles schon, da war ein Denkfehler meinerseits drin.

Aber was anderes:
Ich weiß, ich habe ja auch schon gesagt, daß das bei RV870 z.B. nichts bringen würde. Deswegen müßten auch anderweitig größere Änderungen an den Einheiten erfolgen, z.B. die Sache mit der t-Einheit. Wenn das eine entkoppelte eigene Pipeline wird, die eine höhere Latenz aufweist (und eine andere Einheitenzahl pro SIMD als die ALUs) ähnlich wie nvidias SFUs. Dann ist die Verfügbarkeit dieser Pipeline ja nicht mehr statisch zur Compilezeit vorherzusagen. Nvidia hat deswegen ja auch deutlich aufwendigere Scheduler als ATI, die machen nämlich schon jetzt sowas in der Art.
Imho läuft die SFU zwar unabhängig hat aber genau 1/4 des Durchsatzes der ALUs. Also weiß der Compiler dort auch schon genau wie er die Instructions sortieren muss.

[Gipsel]

Imho läuft die SFU zwar unabhängig hat aber genau 1/4 des Durchsatzes der ALUs. Also weiß der Compiler dort auch schon genau wie er die Instructions sortieren muss.
Aber da die verschiedenen Warps (oder auch die Wavefronts auf ATI) auf einem SM/SIMD nicht in Lockstep ausgeführt werden (die Patricia Harrel, immerhin "Stream Computing Director" bei AMD, behauptet ja, daß schon RV870 sogar verschiedene Kernel auf einem SIMD mixen kann, GT200/Fermi offiziell nur verschiedene Warps eines Kernels), ist statisch nicht klar, ob denn jetzt z.B. die SFUs frei sind oder nicht (bei Fermi auch die ALUs oder L/S-Einheiten). Für meinen Geschmack würde es jetzt reichen, einfach die nächste Instruktion irgendeines anderes Warps zu nehmen, der nicht eine der bereits belegten Einheiten benötigt. Out-of-Order wäre also eigentlich unnötig. Bei ATI ist es aber wie schon erwähnt bisher so, daß sich eigentlich nur 2 Wavefronts auf einem SIMD abwechseln und diese immer an Clause-Grenzen gegen andere getauscht werden können. Das ist prinzipiell etwas inflexibler aber wegen der identischen Latenz für alle Operationen (auch t-Einheit) keine Einschränkung. Aber es macht die Scheduler einfacher, da nicht einzelne Instruktionen, sondern nur Clauses verwaltet werden müssen. Unter Umständen ist es vielleicht einfacher, out-of order nur innerhalb der Clauses zu machen und global weiterhin nur die Clauses zu verwalten, als von vornherein die einzelnen Instruktionen zu behandeln. Aber das ist jetzt wirklich totale Spekulation.

[PCGH_Carsten]

Du hast doch bestimmt (im Gegensatz zu mir) einen Cypress rumliegen, oder?
PM me :)

[Coda]

Aber da die verschiedenen Warps (oder auch die Wavefronts auf ATI) auf einem SM/SIMD nicht in Lockstep ausgeführt werden (die Patricia Harrel, immerhin "Stream Computing Director" bei AMD, behauptet ja, daß schon RV870 sogar verschiedene Kernel auf einem SIMD mixen kann, GT200/Fermi offiziell nur verschiedene Warps eines Kernels), ist statisch nicht klar, ob denn jetzt z.B. die SFUs frei sind oder nicht
Ja, das stimmt natürlich.

Aber dennoch: Der Compiler wird dann ja eh versuchen den Zugriff auf die von den SFUs berechnete Werte so spät wie möglich zu setzen in den "normalen" ALUs. So wie bei Texturzugriffen auch. Die laufen ja schließlich auch parallel.

Wieso will man dann also noch umsortieren innerhalb eines Warps/Wavefront?

[=Floi=]

für was steht denn das DX11 nativ? ist es jetzt anders? bei ati?

[Ailuros]

für was steht denn das DX11 nativ? ist es jetzt anders? bei ati?

Bloede Bezeichnung die irgend jemand erfunden hat wahrscheinlich. Du kannst auch sagen dass RV8x0 ein Bastard ist und RV9xx ein Eingeborener :P

[Ailuros]

Nicht GPU relevant aber trotzdem interessant:

http://www.xbitlabs.com/news/cpu/display/20091015173531_AMD_s_First_Fusion_Processors_to_Be_Made_Using_32nm_SOI_Process_T echnology_CEO.html

[Gipsel]

PM me :)
Done.

[AnarchX]

Die 32nm Northern Island Familie als offizieller Bestandteil der 2011er Systeme:
http://img691.imageshack.us/img691/2411/019g.jpg
http://img691.imageshack.us/img691/2478/0201.jpg

http://plaza.rakuten.co.jp/moemaid/diary/200910310002/

Wobei das nicht heißen muss, dass diese noch 2010 vorgestellt werden könnten.

[reunion]

Allemal interessant das dort 32nm steht und nicht 28nm.

[w0mbat]

Jupp, also wird 2010 und GF immer wahrscheinlicher.

[reunion]

GF ist sicher, das wurde schon bestätigt. Nur bietet GF auch 28nm an, das man zuerst in 32nm kommt deutet tatsächlich auf einen relativ frühen Termin hin. Vermutlich kommen dann die kleineren Chips in 28nm.

[V2.0]

Ein zeitiger Refesh in 32nm wäre ein unschätzbarer Vorteil.

[reunion]

It looks like ATI’s next generation graphics that could hopefully appear in late 2010 will be developed in the 28nm process.

This might be the first chip developed for both TSMC and Globalfoundries. Globalfoundries hopes to have its 28nm bulk process ready in late 2010, probably in Q4, and ATI will probably be one of the first customers.

If ATI plays it safe it will develop the chip for both TSMC and Globalfoundries and will benchmark which of the two gets the job done better. AMD is yet to announce that it will officially do its GPUs in Dresden bulk part of factory, but this is something that won’t surprise many people.

Just remember that TSMC’s yields with 40nm are not great and considering that this silicon is in the majority of ATi and Nvidia chips, especially new designs, an alternative for the next generation becomes more likely.

http://www.fudzilla.com/content/view/16299/1/

[Botcruscher]

Wenn da aus late 2010 nicht mid oder Herbst 2011 wird. 40nm macht ja immer noch Probleme.

[S940]

40nm macht ja immer noch Probleme.
Bei Globalfoundries ? :freak:

[mapel110]

http://www.golem.de/0911/71000.html
Mit 28 Nanometern will Globalfoundries dann auch AMDs Grafikabteilung für sich gewinnen. Udo Nothelfer, nach Hans Deppe neuer Leiter der Fab 1, sagte in Dresden über den 28nm-Prozess: "Das ist der Grund, warum wir da soviel Druck machen, weil wir damit mit ATI ins Geschäft kommen wollen.". Wann das soweit sein könnte, gab Nothelfer nicht an.

Man findet überhaupt keine Angaben, wann GF mit 28nm ankommen will. Aber vor Mitte 2011 wird das doch wohl eh nichts?!

[reunion]

30 sec Google:

Das Unternehmen wird im ersten Quartal 2010 Kundendesigns und Produktentwicklungen von Dritten für eine kurzfristige und kostenfreundliche Prototypenproduktion in der 28 nm-Generation, die auf Bulk-Silizium-Substraten hergestellt wird, anbieten. Die Produktion ist für die zweite Jahreshälfte 2010 vorgesehen.

http://www.monstersandcritics.de/artikel/200940/article_156586.php/GLOBALFOUNDRIES-unterstreicht-F%C3%BChrungsrolle-bei-32nm-28nm-Technologien?page=2

[mapel110]

Wieso soll auf einmal Intel im Fertigungsprozess hinterher hinken so quasi aus dem Nichts heraus? Das versteh einer...

[reunion]

Wo ist denn Intel hinten? Man wird schon kurz nach dem Jahreswechsel 32nm High-End-CPUs bringen. Das Intel keinen Half-Node hat ist nichts neues.

[S940]

32nm bulk wird ab Ende 09 hochgefahren:
http://pc.watch.impress.co.jp/docs/2009/0323/global_7.jpg

Vielleicht ist der kleine, "besondere" ATi Chip ja doch nicht 32nm SOI sondern 32nm bulk ... nachdem auf den obigen AMD Roadmaps schon 32nm GPUs auftauchten, würde das passen. Im Gegensatz zum 32nm SOI Prozess, der ja verschoben wurde, passt das auch termintechnisch viel besser.

ciao

Alex

[Botcruscher]

Wo ist denn Intel hinten? Man wird schon kurz nach dem Jahreswechsel 32nm High-End-CPUs bringen. Das Intel keinen Half-Node hat ist nichts neues.


http://www.heise.de/newsticker/meldung/IBM-Halbleiter-Allianz-28-Nanometer-Chips-ab-2011-213433.html

Firmen, die mit diesem Kit Chips entwerfen, können mit ersten Produktionsmustern in der zweiten Jahreshälfte 2010 rechnen; die Großserienferigung in den diversen Fabs der Mitglieder der IBM Alliance dürfte dann wohl 2011 voll hochlaufen. Ob und wann auch eine "High-Performance"-Version der 28-nm-Fertigungstechnik erscheint, verraten die Beteiligten derzeit nicht.

Auch nicht so richtig aktuell.

Bei Globalfoundries ? :freak:

Da werden doch noch gar keine Karten gefertigt? TSMC arbeitet auch an 28nm. Optimistisch im Mai klang das von NV so (http://www.pcgameshardware.de/aid,685246/Nvidia-will-fruehestmoeglich-auf-TSMCs-28-Nanometer-Prozess-wechseln/Grafikkarte/News/).

[S940]

[/URL]Da werden doch noch gar keine Karten gefertigt? TSMC arbeitet auch an 28nm. Optimistisch im Mai klang das von NV [URL="http://www.pcgameshardware.de/aid,685246/Nvidia-will-fruehestmoeglich-auf-TSMCs-28-Nanometer-Prozess-wechseln/Grafikkarte/News/"]so (http://www.heise.de/newsticker/meldung/IBM-Halbleiter-Allianz-28-Nanometer-Chips-ab-2011-213433.html).Ja, aber GF eben auch .. und das ist eine komplett andere Firma. TSMCs Probleme bei 40nm interessieren die Leute in Dresden überhaupt nicht, die klingeln im Notfall einfach zu IBM durch ;-)

ciao

Alex

[Szenario21]

Was glaubt ihr... wird ATI weiterhin auf das klassische 256bit Interface setzen oder etwas anderes probieren.
512bit ist wohl zu kostenintensiv, aber ich denke da an 320bit.
Damit schafft man eine größere Bandbreite und kann Karten mit 640, 1280 und 2560 MB anbieten, was etvl. besser zu neuen Spielen passen würde.
Ausserdem hätten dann auch die midrange Garfikkarten mit 160bit Bus eine bessere Performance.

[Der_Korken]

Was glaubt ihr... wird ATI weiterhin auf das klassische 256bit Interface setzen oder etwas anderes probieren.
512bit ist wohl zu kostenintensiv, aber ich denke da an 320bit.
Damit schafft man eine größere Bandbreite und kann Karten mit 640, 1280 und 2560 MB anbieten, was etvl. besser zu neuen Spielen passen würde.
Ausserdem hätten dann auch die midrange Garfikkarten mit 160bit Bus eine bessere Performance.

Das kommt ganz darauf an, wieviel Bandbreite der Chip braucht und wieviel sich lohnt zu investieren. ATI ist, was das angeht, völlig offen. Deswegen ist es auch wenig spannend und ertragreich darüber zu spekulieren. Wenn man den Chip und dessen Leistung kennt, kann man schätzen, ansonsten muss man erstmal mit allem rechnen.

[Ailuros]

http://www.fudzilla.com/content/view/16299/1/

Hab ich jetzt erst gesehen. Was Fudo hier spekuliert dass ein IHV parallel fuer 2 foundries entwickelt ist mehr als nur wahnwitzig. Und ja sicher wird AMD Sicherheitsmassnahmen ziehen und da passt eher in meinen Kopf dass man in den Startloechern nicht unbedingt mit dem kompliziertesten chip von Anfang an anspricht. RV740 ein gutes Beispiel?

[nagus]

Hab ich jetzt erst gesehen. Was Fudo hier spekuliert dass ein IHV parallel fuer 2 foundries entwickelt ist mehr als nur wahnwitzig. Und ja sicher wird AMD Sicherheitsmassnahmen ziehen und da passt eher in meinen Kopf dass man in den Startloechern nicht unbedingt mit dem kompliziertesten chip von Anfang an anspricht. RV740 ein gutes Beispiel?

da hast du sicher recht. aber vielleicht sehen wir ja im (früh)sommer einen kleinen aus der evergreen-familie in 28nm.

[V2.0]

Frühsommer 2011?

[Gast]

Ich glaube nicht, dass wir vor 2011 einen Grafikchip von GF sehen....

Deckt sich auch damit:

http://www.brightsideofnews.com/news/2009/12/14/amd-to-launch-globalfoundries-gpu-production-in-2011.aspx

[Gast]

Vor 2011 sicher nicht.
18 Monate muss die HD5K Serie am Markt bleiben.
Zuvor gibt es maximal irgend einen kleinen Testchip.

[Gast]

und was ist wenn AMD ein neuen Chip noch in 40nm bei TSMC herstellen lässt? vielleicht ein Chip mit über 2000 SPs statt 1600?

[aylano]

Ich glaube nicht, dass wir vor 2011 einen Grafikchip von GF sehen....

Deckt sich auch damit:

http://www.brightsideofnews.com/news/2009/12/14/amd-to-launch-globalfoundries-gpu-production-in-2011.aspx
Dirk Mayer schrieb ja, die Umstellung auf GF über dem Jahr 2010 (=over the coming years year) zur machen.

Also, sollte da schon was kommen.
Ob in 40nm oder 32 oder 28 in Low-End oder mainstream oder Performance ist noch ungewiss.

PS: Ups, wenn es um RV900-GPUs geht, dann wirds knapp mit 2010.

[Gast]

Der RV870 Tape Out war schon im Februar 2009 fertig, also lange Zeit genug um ein neues Design auf R800>R900 Basis zu machen. Ihr glaubt doch nicht das die schlafen?

[Gast]

Der RV870 Tape Out war schon im Februar 2009 fertig, also lange Zeit genug um ein neues Design auf R800>R900 Basis zu machen. Ihr glaubt doch nicht das die schlafen?

Und du glaubst doch nicht das Sie eine neue Architektur auf den Markt bringen, wenn die Alte noch Geld bringt.
Außerdem wird die R900 Architektur für 28nm designed sein und da muss man erstmal abwarten wann man dort ordentliche yields bekommt.

[reunion]

32nm offensichtlich.

[Gast]

Vom 1. Okt. 2009:


GLOBALFOUNDRIES plant die Serienfertigung der 32-nm-SHP-Technologie (Super High Performance) in Fab 1 für das zweite Halbjahr 2010. Diese Technologie wird Silicon-on-Insulator-Substrate (SOI) verwenden .....

„Im Vergleich zu der 45-nm-SHP-Technologie, die wir derzeit in Fab 1 produzieren, erkennen wir bei der 32-nm-Generation Leistungsverbesserungen von bis zu 50 Prozent bei den gleichen Verlustraten wie bei der 45-nm-Generation“, ......



Für die 28-nm-Generation, die auf Basis von Siliziumgrundsubstraten angeboten werden wird, wird das Unternehmen im Rahmen seines Shuttle-Services im ersten Quartal 2010 Eigenkonstruktionen von Kunden und Dritten für kostengünstige Prototypenerstellung annehmen. Die Produktion ist für das zweite Halbjahr 2010 geplant. ....

Darüber hinaus vereinfacht die „Gate First“-Methode für HKMG von GLOBALFOUNDRIES die Umsetzung von 28-nm-Konstruktionen und aufgrund ähnlicher Prozessabläufe und Konstruktionsrichtlinien die IP-Wiederverwendung für Kunden, welche die herkömmliche poly/SiON-basierte Technologie an den 45/40-nm- und 32-nm-Noden verwenden.

Kunden an der 28-nm-Node werden von einem Vorlauf mit großen Volumina technisch führender Technologien an dem 32-nm-Node profitieren, die GLOBALFOUNDRIES direkt in die zweite Generation der HKMG-Implementierung versetzen wird, sobald die 28-nm-Produktion startet. Der 28-nm-Node wird in zwei Varianten verfügbar sein: Die 28-nm-HP-Variante (High Performance) wird für technisch führende Anwendungen in Bereichen wie Grafik, ....


http://www.businesswire.com/portal/site/home/permalink/?ndmViewId=news_view&newsId=20091001005637&newsLang=de


Es könnte also schon früher losgehen mit 28nm.

[Gast]

Ergänzung:

http://www.semiconductor.net/photo/237/237957-GlobalFoundries_will_use_high_k_metal_gate_for_all_of_its_28_nm.jpg


=> Der erste Artikel zusammen mit dieser Grafik zeigt deutlich, das hier jeweils die Serienproduktion gemeint ist. 28nm = Q3/2010.

http://www.semiconductor.net/article/442948-GlobalFoundries_Adds_Qualcomm_Supports_Gate_First_Technology_at_28_nm_Generation .php

[Gast]

shee..
http://www.semiconductor.net/photo/237/237957-GlobalFoundries_will_use_high_k_metal_gate_for_all_of_its_28_nm.jpg

[Gast]

also ist 32 & 28nm schon 2010 bereit zu Produktion, das geht aber schnell, meint ihr das wir ab Q4 2010 eine neue ATI Generation sehen werden? Sollte sich bestimmt umsetzen können, evtl. wird man ein Mainstream Modell vortesten um erfahrungen zu sammeln? Ich denke ATI wird später einen größeren Vorsprung als Nvidia in der fertigung haben.

[Ailuros]

da hast du sicher recht. aber vielleicht sehen wir ja im (früh)sommer einen kleinen aus der evergreen-familie in 28nm.

Es klingt mir eher nach etwas TSMC 40G Ende Mai-Anfang Juni aber was werd ich wohl schon wissen.

[deekey777]

Wie AnarchX es schon geschrieben hat, ne neue Architektur die auf die Anforderungen von dx11 optimiert ist im Gegensatz zu rv870 der noch auf r600 basiert und nur auf dx11 erweitert wird. Allerdings ist H1 2010 für 28nm doch arg optimistisch, in dem Zeitraum erwarte ich gerade 32nm Produkte. Würde mich sehr überraschen, wenn 28nm Produkte vor H2 2010 kommen.
Das ist zwar rein akademisch, aber basiert der RV770 wirklich auf dem R600 bzw. Xenos/C1 bzw. R400? Eigentlich nicht. Denn der R600 und der Xenos/C1 haben etwas, was der RV770 und auch die Immergrünen nicht haben: einen eigenständigen "TMU-Cluster" (und dann eigenständige ALU-Cluster; Dave Baumann meinte nicht umsonst, dass die TMUs einen fünften SIMD-Block darstellen). Das RV700-Design und das Evergreen-Design entsprechen eher den R520/R580, wo die Quad-TMU und die (Pixel-)Shader-ALUs in einem Block zusammengefasst waren.
Egal.

Zwei Sachen:
http://www.anandtech.com/video/showdoc.aspx?i=3469&p=3
The team that I met with in Santa Clara was talking about designs that would be out in 2012, we’re talking 4 TFLOPS of performance here, 4x the speed of RV770.
Na gut, das kann schon der Hemlock. Gemeint ist wohl eine GPU. Und das Jahr 2012 ist doch das Kalenderjahr 2011, oder?

Die zweite Sache ist der RV870-Artikel (http://www.anandtech.com/video/showdoc.aspx?i=3740&p=1).
Unter anderem wird berichtet, wie der RV870 um Features beschnitten wurde. Der "Ur-RV870" sollte die Größe des GT200B haben (http://www.anandtech.com/video/showdoc.aspx?i=3740&p=3), also deutlich größer als der tatsächliche RV870. Verglichen mit dem Fermi wirkt der RV870 schon gewöhnlich, konservativ. Da drängt sich bei mir die Frage auf, ob nicht der "R900" (sofern es sich nicht um einen Refresh des RV870 handelt) genau das sein wird, was für den Evergreen eingeplant war?
Ja, irgendwie wiederholt sich die Geschichte: Der R600 war eigentlich R500 und der R700 hätte das werden sollen, was für den R600 geplant war, also was ganz Neues.
Der RV770 hat zB das GDS, das nicht nutzbar ist. Der RV870 hat es auch, ist auch nicht nutzbar. Nun: Warum hat der RV870 genau 64 KB GDS wie der RV770? Sein LDS-Speicher ist doppelt so groß wie beim RV770 (und dazu viel weiter), aber nur 64 KB GDS? Oder ist es ein eingespartes Feature, wo vorher deutlich mehr Speicher gedacht war (128 KB? 256 KB?) und vielleicht mit mehr Eigenschaften?
Eine weitere Idee: Der RV870 hätte ein zweites Tri-Setup bekommen sollen. Wurde verworfen. Das bekommt jetzt der R900. Und so weiter.

PS: Sollte der richtige Codename für den Evergreen-Nachfolger ein anderer als R900 sein, dann ersetzt gedanklich "R900" durch diesen.

[Gast]

The Northern Islands GPUs, due out later this year, were surely designed before anyone knew how RV870 would play out.

http://www.anandtech.com/video/showdoc.aspx?i=3740&p=11

[Sorkalm]

Na gut, das kann schon der Hemlock. Gemeint ist wohl eine GPU. Und das Jahr 2012 ist doch das Kalenderjahr 2011, oder?

AMDs Geschäftsjahr ist faktisch identisch mit dem Kalenderjahr, maximal ein paar Tage Abweichung. Das Fiskaljahr 2009 ging bei AMD bis zum 26.12.2009.

Und für 2012 sind dann 4 TFlops, bei aktueller Architekturbasis gesehen, nichts besonderes. Wenn sie natürlich irgendwas wesentliches umbasteln, könnts anders aussehen.

[=Floi=]

imho sind diese prozesse zwar verfügbar, aber die grafikkarten- und prozessorhersteller setzen mit ihren komplexen und großen chips erst später darauf. TSMC 40G war auch schon eher verfügbar und man produzierte zuerst FPGA.
http://www.xbitlabs.com/news/other/display/20081117072008_TSMC_Begins_Volume_Manufacturing_of_Products_Using_40nm_Process_T echnology.html

[Ailuros]

Eine weitere Idee: Der RV870 hätte ein zweites Tri-Setup bekommen sollen. Wurde verworfen. Das bekommt jetzt der R900. Und so weiter.

PS: Sollte der richtige Codename für den Evergreen-Nachfolger ein anderer als R900 sein, dann ersetzt gedanklich "R900" durch diesen.

Rasterizer + trisetup nehmen genau wie viel auf solchen GPUs ein? Haetten sie von Anfang an 2 raster + 2 trisetup geplant waere es nicht der Rede wert gewesen das zweite trisetup zu entfernen.

Denk lieber in Richtung Tessellation und wie man hier die Effizienz steigern koennte.

[Gipsel]

Der RV770 hat zB das GDS, das nicht nutzbar ist. Der RV870 hat es auch, ist auch nicht nutzbar.Das würde ich bestreiten wollen. Sicherlich gibt es (noch) keine dokumentierten IL-Befehle für dessen Nutzung, allerdings sind in der Evergreen-ISA-Dokumentation die entsprechenden Befehle bereits beschrieben. Überdies wird der GDS z.B. für die Tesselation-Faktoren in der DX11-Tesselations-Pipeline (Hullshader -> Tesselator -> Domainshader) im Hull-Shader genutzt.

[deekey777]

Das würde ich bestreiten wollen. Sicherlich gibt es (noch) keine dokumentierten IL-Befehle für dessen Nutzung, allerdings sind in der Evergreen-ISA-Dokumentation die entsprechenden Befehle bereits beschrieben. Überdies wird der GDS z.B. für die Tesselation-Faktoren in der DX11-Tesselations-Pipeline (Hullshader -> Tesselator -> Domainshader) im Hull-Shader genutzt.
Du meinst die Seite 25?

PS: Meinen Beitrag habe ich unabhängig von Deinem (http://www.forum-3dcenter.org/vbulletin/showpost.php?p=7843948&postcount=12) geschrieben. Ehrlich.

[Coda]

Denn der R600 und der Xenos/C1 haben etwas, was der RV770 und auch die Immergrünen nicht haben: einen eigenständigen "TMU-Cluster" (und dann eigenständige ALU-Cluster; Dave Baumann meinte nicht umsonst, dass die TMUs einen fünften SIMD-Block darstellen).
Was meinst du damit?

Ich habe bisher nichts gesehen dass darauf hindeutet, dass da zwischen R600 und R700 ein Unterschied sein soll.

[deekey777]

Was meinst du damit?

Ich habe bisher nichts gesehen dass darauf hindeutet, dass da zwischen R600 und R700 ein Unterschied sein soll.
Die Tex-Einheiten des R600 und des Xenos bilden zu vier Quads zusammengefasst einen eigenen Block. Beim Xenos gilt das definitiv, beim R600 wohl auch (es sei denn, kreatives Diagrammzeichnen liegt vor, aber dann müsste Dave Baumann Unsinn erzählt haben, als er den TMU-Block als zusätzliches SIMD bezeichnete).

http://www.behardware.com/articles/782-2/nvidia-geforce-gf100-the-geometry-revolution.html (ab Opting...)

Oder?

[Gipsel]

Du meinst die Seite 25?Im Prinzip schon. Es gibt dann zwar getrennte Befehle zum Lesen/Schreiben von Werten im GDS und für die Tessellations-Faktoren (die sind weiter hinten dokumentiert, das auf Seite 25 ist ja nur die Einleitung für so eine GDS-Clause, in der mehrere Instruktionen zusammengefaßt sein können), aber das beide in einer GDS-Clause stehen müssen deutet schon sehr stark darauf hin, daß da der gleiche Speicher benutzt wird. Mit den unterschiedlichen Befehlen hält man sich aber die Möglichkeit offen, daß in der Hardware später mal zu trennen.
Was meinst du damit?

Ich habe bisher nichts gesehen dass darauf hindeutet, dass da zwischen R600 und R700 ein Unterschied sein soll.
Worauf deekey hinaus will, ist daß im Prinzip bei R600 die TMUs nicht wie später Teil der SIMD-Engines waren, sondern eine eigene "TMU-Engine" bildeten. Das ergibt theoretisch ein besseres Loadbalancing (eine einzige SIMD-Engine kann alle vorhandenen TMUs nutzen), allerdings erhöht es wohl die Latenzen und verkompliziert natürlich das Design. In dem Punkt wurde durchaus etwas kräftiger an der internen Architektur geschraubt.

[Gast]

AMD ATI Northern Islands, next generation GPU


DirectX 11.1
32nm node
Real Fermi Killer
Expected to be out 3rd-4th Quarter 2010

http://vr-zone.com/forums/559828/amd-ati-northern-islands-next-generation-gpu.html

[Coda]

Es gibt kein 11.1

Das kann man also getrost als Hirngespinst abtun.

Worauf deekey hinaus will, ist daß im Prinzip bei R600 die TMUs nicht wie später Teil der SIMD-Engines waren, sondern eine eigene "TMU-Engine" bildeten. Das ergibt theoretisch ein besseres Loadbalancing (eine einzige SIMD-Engine kann alle vorhandenen TMUs nutzen), allerdings erhöht es wohl die Latenzen und verkompliziert natürlich das Design. In dem Punkt wurde durchaus etwas kräftiger an der internen Architektur geschraubt.
War das wirklich so oder waren damals die Blockdiagramme einfach noch "kreativer"? Imho letzteres.

[Sorkalm]

Inzwischen gibts nur noch Killer hier, was? Im Spekuforum gibts nen Thread über den iPad-Killer, Femri wird der Cypress-Killer und ATI entwickelt schon nen Fermi-Killer... :tongue:

[mapel110]

Es wird doch auch kein 32nm für GPUs geben?!

[Gast]

Es gibt kein 11.1

Das kann man also getrost als Hirngespinst abtun.


Das sehen aber so einige Quellen anders:

Getting into 2011, AMD plans to debut Northern Islands, their true next-generation part. This is the part that is being designed with DirectX 11.1 specification in mind [according to sources inside AMD, Evergreen also supports 11.1 specification. Upon our insisting, we were told that is not entirely true - DX11.1 is not finalized and they cannot be sure if Evergreen will support 11.1 or will fall short]. The DirectX 11.1 is currently being worked upon, and among our sources, it is widely expected to debut in the winter of 2010, with hardware following either in 2011. According to information at hand, we are talking about a brand new architecture which follows the prolonged cadence between new architectures [R600 - RV770: May 2007-July 2008, RV770-Evergreen: July 2008 - September 2009, Evergreen-Northern Islands: September 2009-February 2011?].

http://www.brightsideofnews.com/news/2009/11/2/amds-next-gen-gpu-manhattan-and-northern-islands-use-32nm-process.aspx

Es wird doch auch kein 32nm für GPUs geben?!


Northern Islands kommt definitiv in 32nm, steht doch auf der AMD-Roadmap.

[Sorkalm]

Es wird doch auch kein 32nm für GPUs geben?!

Zumindest die Fusion-GPU kommt in 32 nm, wenn auch SOI. :tongue:

Ansonsten steht Northern Island bei AMD für 32 nm auf der Roadmap, und Globalfoundries hat auch mal Websiten und eine News zu 32 nm bulk gehabt (bulk stand nicht direkt drinne, war aber ersichtlich). Das ist jetzt aber komischerweise gelöscht.

[Coda]

Das sehen aber so einige Quellen anders:
Da hätte man schon lange irgendwas im SDK sehen müssen.

Würde mich auch stark wundern nach dem 10.1-Durcheinander wenn sie es wieder so machen.

[deekey777]

Vielleicht Desinformation erster Güte?
"Seht mal, Nvidia hat nicht einmal DX11-Hardware, und wir gewähren schon einen Blick auf unsere DX11.1-Hardware."

Igendjemand hat ja Gerüchte in die Welt gestreut, wonach DX9.1 kommen sollte, womit die damaligen Geforces ein gewaltiges Speedupgrade bekommen.

[Coda]

Ich muss mal schauen was in 11.0 als Kandidat für 11.1 überhaupt in Frage kommen könnte.

10.1 hat nur Restriktionen entfernt von 10.0 (Texture-Arrays auch für Cube-Maps, Subsample-Reads auch auf Z-Buffer, Blend-Mode per Rendertarget, usw.)

11 sah für mich bisher so aus als hätte man solche Dinge schon von vornherein vermieden.

[Gipsel]

War das wirklich so oder waren damals die Blockdiagramme einfach noch "kreativer"? Imho letzteres.
Na ganz sicher kann man sich da nicht sein, allerdings verhalten sich RV670 und RV770 schon etwas unterschiedlich bei Speicherzugriffen. Außerdem spricht bei RV670 der einzelne L1-Cache für alle TMUs zusammen für die Anordnung als "TMU-Engine". Jetzt hat jede SIMD-Engine ja bekanntlich ihren eigenen TMU-Cluster mitsamt separatem L1. Insgesamt paßt das schon mit den oben genannten Aussagen von Dave Baumann oder auch aus dem Artikel von Damien Triolet zusammen.

[LadyWhirlwind]

Die Frage ist doch nicht wann GF bereit ist, sondern ob GF auch Produktion für Nvida machen würde, und wenn nicht, wann TSMC bereit ist. Wenn die Konkurenz Prozesstechnisch voraus ist, kann man nicht wirklich viel tun mit dem Chipdesign.

[mboeller]

Die Frage ist doch nicht wann GF bereit ist, sondern ob GF auch Produktion für Nvida machen würde, und wenn nicht, wann TSMC bereit ist. Wenn die Konkurenz Prozesstechnisch voraus ist, kann man nicht wirklich viel tun mit dem Chipdesign.


IMHO falsch rum. GF wird keine Probleme mit einem neuen Kunden haben, Nvidia dafür Probleme mit einer neuen Foundry. Wenn es Nvidia noch nicht einmal schafft ihre Highend GPUs bei TSMC richtig zum laufen zu bringen; und das obwohl sie seit sehr langer Zeit mit TSMC zusammenarbeiten...
Da werden sie wohl noch größere Probleme haben wenn sich gleichzeitig der Prozess (28nm) und die Foundry ändert. Also viel würde ich mir nicht von einer anderen Foundry erwarten, egal ob GF oder xxxx.

[Gast]

Die Frage ist doch nicht wann GF bereit ist, sondern ob GF auch Produktion für Nvida machen würde, und wenn nicht, wann TSMC bereit ist. Wenn die Konkurenz Prozesstechnisch voraus ist, kann man nicht wirklich viel tun mit dem Chipdesign.
Ich hab jetzt keine Quelle da, aber IIRC hat GF mal gesagt das sie für Nvidia genauso wie jeden anderen zahlenden Kunden produzieren würden.

[Gast]

Wäre ja auch Schwachsinn wenn sie sich dieses Geld entgehen ließen. Denn genau zu diesem Zweck wurden die Produktionsstätten von AMD ausgegliedert, um flexibler und wirtschaftlicher zu operieren.

[S940]

Ich hab jetzt keine Quelle da, aber IIRC hat GF mal gesagt das sie für Nvidia genauso wie jeden anderen zahlenden Kunden produzieren würden.
Jo, und daraufhin hat einer nV gefragt und die meinten, dass das doch die eklig grüne AMD FAB wäre, die nur nen andren Namen hat ^^
(sehr freie Interpretation meinerseits ^^)

Aber vielleicht wirds ja noch mal ...

[Undertaker]

IMHO falsch rum. GF wird keine Probleme mit einem neuen Kunden haben, Nvidia dafür Probleme mit einer neuen Foundry. Wenn es Nvidia noch nicht einmal schafft ihre Highend GPUs bei TSMC richtig zum laufen zu bringen; und das obwohl sie seit sehr langer Zeit mit TSMC zusammenarbeiten...

Inwiefern waren die 40nm Probleme denn jetzt auf Seiten von Nvidia? In erster Linie war da wohl TSMC schuld, auch RV870 Karten sind Monate nach dem Launch nach wie vor noch nichteinmal bei jedem dritten Händler lagernd - und der RV870 ist ein Winzling im Vergleich zum GF100.

Jetzt, wo GF sich auf absehbare Zeit als vollständig eigenständiges Unternehmen präsentiert und AMD keinerlei Anteile mehr halten will, wird aus NVs Sicht das eine Unternehmen so gut wie das andere sein - Qualität und Preise müssen passen.

[mapel110]

http://www.fudzilla.com/content/view/17782/34/
Since ATI’s next generation card codenamed Hecatoncheires, which is the successor of 5xx0 series, should launch this year, our sources are very confident that we are talking about yet another 40nm.

[Ailuros]

http://www.fudzilla.com/content/view/17782/34/
Since ATI’s next generation card codenamed Hecatoncheires, which is the successor of 5xx0 series, should launch this year, our sources are very confident that we are talking about yet another 40nm.

:wink:

[mapel110]

Vor allem ist da mal eine realistische Einschätzung zu 28nm zu lesen. Andere dagegen hypen rum, dass Ende des Jahres High End GPUs auf dem Process kommen. :rolleyes:

[Ailuros]

Vor allem ist da mal eine realistische Einschätzung zu 28nm zu lesen. Andere dagegen hypen rum, dass Ende des Jahres High End GPUs auf dem Process kommen. :rolleyes:

Ich weiss ehrlich nicht mehr wie oft ich schon erwaehnt habe dass man ausserhalb von 40G fuer 2010 nichts erwarten sollte und das egal welcher IHV. Deshalb auch der Wink. Der Unterschied hier ist dass AMD mit groessere die Flaeche spielen wird waehrend NVIDIA nur auf Frequenz-steigerungen begrenzt ist.

[S940]

Vor allem ist da mal eine realistische Einschätzung zu 28nm zu lesen. Andere dagegen hypen rum, dass Ende des Jahres High End GPUs auf dem Process kommen. :rolleyes:
Naja, ich weiss nicht - ist die Vorhersage irgendwie begründet, oder ist das nur seine private Glaskugelaussage ?
Da steht nur:
should be ready
Wenn er wirklich etwas 100% wissen würde, sollte er das anders schreiben ...

Bisher kenn ich nur das:
GlobalFoundries provided a 28nm evaluation kit to select clients in December(2008), and it made the kit available to the "general market" last month. The foundry tell us it plans to start accepting 28nm designs in the second half of next year(H2/10), with production to follow "shortly thereafter." 28nm production will take place at GlobalFoundries' Fab 1 facility in Dresden, Germany.
http://techreport.com/discussions.x/16758
Ist aber halt nicht klar, welcher 28nm Prozess da gemeint war ... HP, oder LP ...

Insgesamt fände ich so ein 40nm Teil merkwürdig. Laut frühen Aussagen von AMD wird GPGPU Zeugs nachgeschoben, quasi dass was nV jetzt mit Fermi bringt, d.h. der Chip wird sicherlich größer werden, aber nicht schneller (bei Games).

Zwar sollte TSMCs 40nm Prozess bis Ende 2010 mal wirklich vernünftige Yields schaffen, aber der Stromverbrauch wird sich nicht großartig verbessern.

Am Ende bliebe noch 32nm übrig, aber da hat GloFo vor Kurzem komischerweise die Infoseiten auf der Webpage gestrichen, d.h. der Prozess wurde vermutlich auch gestrichen.

Bliebe nur 32nm SOI, der Prozess kommt ja garantiert, aber da wurde erst letztens von AMD gesagt, dass man keine dezidierten SOI GPUs bauen würde..

ciao

Alex

[deekey777]

http://www.fudzilla.com/content/view/17782/34/
Since ATI’s next generation card codenamed Hecatoncheires, which is the successor of 5xx0 series, should launch this year, our sources are very confident that we are talking about yet another 40nm.
Der wird bestimmt goß sein.

[Bucklew]

http://www.fudzilla.com/content/view/17782/34/
Since ATI’s next generation card codenamed Hecatoncheires, which is the successor of 5xx0 series, should launch this year, our sources are very confident that we are talking about yet another 40nm.
Das beißt sich allerdings mit dem AMD-Interview, nachdem man 2010 für den Umstieg auf Globalfoundries einplant:

http://www.brightsideofnews.com/news/2009/12/14/amd-to-launch-globalfoundries-gpu-production-in-2011.aspx

Wenn überhaupt also eher ein Refresh, keine neue Architektur o.Ä.

[Triskaine]

Das beißt sich allerdings mit dem AMD-Interview, nachdem man 2010 für den Umstieg auf Globalfoundries einplant:

http://www.brightsideofnews.com/news/2009/12/14/amd-to-launch-globalfoundries-gpu-production-in-2011.aspx

Wenn überhaupt also eher ein Refresh, keine neue Architektur o.Ä.

Ein wagemutiger Schluss, wenn es in der Überschrift schon heißt:

AMD to launch GlobalFoundries GPU production in 2011

[Bucklew]

Oh da bekommt der NV-Fanboy mal wieder kalte Füße.
Da traut sich der ATI-Fanboy mal wieder nicht mit dem richtigen Account zu posten aus Angst vor ner roten Karte :cool:

Gelbe Karte fuer Dich

Ein wagemutiger Schluss, wenn es in der Überschrift schon heißt:
Es hilft oftmals den Text zu lesen, dann nachzudenken und erst dann zu posten:
Just like nVidia skipped 2009 with the introduction of their next-gen graphics architecture, AMD is skipping 2010. However, while nVidia's GT300/Fermi GPU architecture slipped into 2010 due to problems in development - AMD decision to put 2010 on sidelines is "according to plan."

[Triskaine]

Es hilft oftmals den Text zu lesen, dann nachzudenken und erst dann zu posten:

:facepalm:

Sag mal, bist du der Englischen Sprache mächtig? In dem Abschnitt den du zitierst steht was drin? Genau, "skipping 2010" und "put 2010 on sidelines".
Wie passt das jetzt dazu:
Das beißt sich allerdings mit dem AMD-Interview, nachdem man 2010 für den Umstieg auf Globalfoundries einplant

Richtig, gar nicht. :P

[Bucklew]

:facepalm:

Sag mal, bist du der Englischen Sprache mächtig? In dem Abschnitt den du zitierst steht was drin? Genau, "skipping 2010" und "put 2010 on sidelines".
Wie passt das jetzt dazu:


Richtig, gar nicht. :P
"Skipping" bezeichnet hierbei eine neue Grafikkartengeneration. Nicht umsonst steht auch in dem Bild die "Next-Gen ATI discrete Graphics" erst für 2011.

[Triskaine]

Wie stellst du hier einen Zusammenhang zur Fertigung bei Globalfoundries her? Das letzte sinnvolle was in diesem Thread diskutiert wurde, ist das es dieses Jahr keine Umstellung geben wird, wie es schon in der Überschrift des BSN* Artikels heißt. Wenn du eine Quelle hast in der AMD eine Umstellung in 2010 bestätigt, würde ich diese gerne sehen.

[Bucklew]

Wie stellst du hier einen Zusammenhang zur Fertigung bei Globalfoundries her? Das letzte sinnvolle was in diesem Thread diskutiert wurde, ist das es dieses Jahr keine Umstellung geben wird, wie es schon in der Überschrift des BSN* Artikels heißt. Wenn du eine Quelle hast in der AMD eine Umstellung in 2010 bestätigt, würde ich diese gerne sehen.
"keine Umstellung" bedeutet nur, dass man im Jahre 2010 noch keine bei GF gefertigte ATI-GPU kaufen kann. Sehr wohl aber wird 2010 mit der Umstellung begonnen und genau das meint der BSN-Artikel. Keine neue Generation dieses Jahr, aber die Umstellung auf GF um dann 2011 die ersten Karten bei GF in Massenproduktion fertigen zu lassen.

[MR2]

Duplex schrieb heute:
http://www.planet3dnow.de/vbulletin/showthread.php?t=368890&page=11

w0mbat meinte heute

1. Es gibts nichts dass den namen Hecatoncheires hat.
2. Ja, es kommt noch was dieses jahr und nach meinen infos nicht in 40nm.

also doch 32nm RV870 mit mehr Einheiten und großer Chip als RV970?

Das wäre ja super...Ob 32 oder 28nm wird sich zeigen.

[mapel110]

Erstmal kommt im Mai/Juni ein Refresh auf 40nm und der soll wohl schon mehr als nur Takt bringen.

[Nakai]

Duplex schrieb heute:
http://www.planet3dnow.de/vbulletin/showthread.php?t=368890&page=11

w0mbat meinte heute

1. Es gibts nichts dass den namen Hecatoncheires hat.
2. Ja, es kommt noch was dieses jahr und nach meinen infos nicht in 40nm.

also doch 32nm RV870 mit mehr Einheiten und großer Chip als RV970?

Das wäre ja super...Ob 32 oder 28nm wird sich zeigen.

Wenn das wirklich von w0mbat kommt, dann wird es wohl stimmen.


mfg

[N0Thing]

Bei welcher Firma arbeitet w0mbat denn? Bzw. warum kann man davon ausgehen, daß diese Aussagen richtig sind?

[Nakai]

Bei welcher Firma arbeitet w0mbat denn? Bzw. warum kann man davon ausgehen, daß diese Aussagen richtig sind?

Oh, Gott. Diese alte Diskussion über seine Person muss nicht wieder angefacht werden.

Ich weiß warum seine Aussagen höchstwahrscheinlich korrekt sind, ebenso wie ein paar andere. Leider macht es keinen Sinn darüber zu diskutieren, da man ihm entweder glaubt oder nicht glaubt.

Ich wette, es kommt soetwas wie ein RV740 nur in 28nm um den Prozess zu testen. Ein RV870-Shrink auf 28nm?


mfg

[N0Thing]

Diskussion??
Ich habe in keiner Weise in Frage gestellt, ob man ihm glauben kann oder nicht. Ich wollte nur wissen warum er eine gute Quelle ist.
Bei Alurios und Demirug bekommt man das hier im Forum gut mit, aber man kennt nicht unbedingt jeden Nickname gut genug, um sich selber ein Bild machen zu können.

Anstatt davon zu reden, daß du keine Diskussion starten willst (die du mit deinem Beitrag ironischer Weise selber angefangen hast...), hättest du doch kurz schreiben können, warum eine Aussage von w0mbat für dich Gewicht hat. Wäre für uns beide weniger Aufwand gewesen. ;)

[Gast]

Bei welcher Firma arbeitet w0mbat denn? Bzw. warum kann man davon ausgehen, daß diese Aussagen richtig sind?


Wombat behauptete auch damals beim R600, dass der Chip extrem schnell sei und den G80 um Längen schlagen würde, was raus kam wissen wir ja alle. Das gleiche sagte er übrigens auch beim Phenom 1, damals im Jahre 2007. Laut seiner Aussage sollte er wie 2003 der Hammer die Intels wieder massiv einstampfen.......


mfg

[Ailuros]

Jeder "Ailuros" kann genauso falsch liegen wie jeglicher "w0mbat". Behaltet das mal bitte im Hinterkopf denn Infos sind extrem selten vom Maul des Loewen direkt.

[N0Thing]

Ich wollte damit auch nicht sagen, daß man jede Spekulation/Äußerung von dir auf die Goldwaage legen kann. ;)
Ob ich eine Äußerung glaube hängt nicht nur davon ab, wer die entsprechende Äußerung getätigt hat. Wenn man liest: "X sagt dies und jenes" und darauf wird geschrieben "Wenn X das gesagt hat, dann wird es wohl stimmen", dann interessiert es mich einfach, warum X Informationen haben kann, die der normale User nicht hat.
Das hat nichts damit zu tun, ob die Informationen stimmen oder nicht.

[Nakai@Gast]

Jeder "Ailuros" kann genauso falsch liegen wie jeglicher "w0mbat". Behaltet das mal bitte im Hinterkopf denn Infos sind extrem selten vom Maul des Loewen direkt.

Und selbst dann können Infos missinterpretiert werden oder die Infos sind sehr waage. Man muss die Aussagen auch zu interpretieren lernen und nicht alles glauben was man vorgesetzt bekommt.


mfg

[w0mbat]

die noerdlichen inseln haben aktuell mehr als 2 verschiedene decknamen und tauchen in zwei aktualisierten internen roadmaps in verschiedenen fertigungprozessen auf. manno, so macht das keinen spass.

muss... muss naeher an die quelle :D

[V2.0]

Und 2 unterschiedlichen Foundries :D

Und dann macht das alles Sinn.

[Ailuros]

Und 2 unterschiedlichen Foundries :D

Und dann macht das alles Sinn.


Es wird wohl keiner glauben dass AMD zwei chips auf verschiedenen Prozessen und unterschiedlichen libraries ausgelegt hat. Ich kann mir zwar nicht sicher sein, aber ich tippe nach wie vor GF@28nm bulk/Anfang 2011.

[V2.0]

Davon gehe ich aus, aber afaik kusieren in der Tat eine "TSMC-Roadmap" und eine "GF-Roadmap". Eine ist veraltet.

[S940]

Es wird wohl keiner glauben dass AMD zwei chips auf verschiedenen Prozessen und unterschiedlichen libraries ausgelegt hat. Ich kann mir zwar nicht sicher sein, aber ich tippe nach wie vor GF@28nm bulk/Anfang 2011.
Naja, w0mbat redet von nördlichen Inseln, nicht von Chips.
28nm für die großen High End Teile und 40nm TSMC für den (billigen) Rest würde schon Sinn machen.

[Undertaker]

Es wird wohl keiner glauben dass AMD zwei chips auf verschiedenen Prozessen und unterschiedlichen libraries ausgelegt hat. Ich kann mir zwar nicht sicher sein, aber ich tippe nach wie vor GF@28nm bulk/Anfang 2011.

Aber wäre das nicht gerade sinnvoll? Wie auch schon in der Vergangenheit wird ein neuer Prozess bzw. in diesem Fall eine neue Foundry zunächst nicht direkt mit dem kompletten Lineup beglückt, sondern ersteinmal mit einzelnen Chips in der Massenproduktion getestet. Wenn alles glatt läuft, baut man dann nach und nach den Produktionsanteil bei GF weiter aus.

[Ailuros]

Aber wäre das nicht gerade sinnvoll?

Fuer den gleichen chip nicht und so meinte ich es auch (S940 hat es schon richtig verstanden). Nur teile ich seine Meinung auch nicht unbedingt da ich die Teile mit dem groessten Risiko auf Nummer Sicher schleussen wuerde und nicht anders rum.

Wie auch schon in der Vergangenheit wird ein neuer Prozess bzw. in diesem Fall eine neue Foundry zunächst nicht direkt mit dem kompletten Lineup beglückt, sondern ersteinmal mit einzelnen Chips in der Massenproduktion getestet. Wenn alles glatt läuft, baut man dann nach und nach den Produktionsanteil bei GF weiter aus.

Siehe oben.

[S940]

Nur teile ich seine Meinung auch nicht unbedingt da ich die Teile mit dem groessten Risiko auf Nummer Sicher schleussen wuerde und nicht anders rum.
Naja selbst das Risiko schätze ich bei GF geringer ein als bei TSMC ;-)
Selbst bei 28 vs. 40nm, die GF Leute haben schon mehrmals den Preis für die beste FAB erhalten, und im allergrößten Notfall kann man immernoch bei IBM & Co. nachfragen.

TSMC dagegen ist auf sich alleine gestellt.

Abgesehen davon hat man bei ATi seit längerem ja die Designphilosophie neue Prozess möglichst schnell nutzen zu wollen.

ciao

Alex

[Ailuros]

Naja selbst das Risiko schätze ich bei GF geringer ein als bei TSMC ;-)

Ist aber auch nur Dein Bauchgefuehl. Nichts dagegen aber so wie es bei AMD momentan aussieht wuerde ich persoenlich so gut wie moeglich meinen Vorsprung seit RV770 weiterhin zu sichern versuchen.

Dumme Gegenfrage warum benutzte AMD nicht RV790 sondern 740 fuer ihr TSMC 40G Testrennen?

Selbst bei 28 vs. 40nm, die GF Leute haben schon mehrmals den Preis für die beste FAB erhalten, und im allergrößten Notfall kann man immernoch bei IBM & Co. nachfragen.

TSMC dagegen ist auf sich alleine gestellt.

Libraries zu wechseln von hypothetisch TSMC 28nm/bulk zu GF 28nm/bulk geht nicht im Handumdrehen und gleiches gilt auch fuer jegliche foundry.

Abgesehen davon hat man bei ATi seit längerem ja die Designphilosophie neue Prozess möglichst schnell nutzen zu wollen.

ciao

Alex

Ja schon aber sie entwickelten auch in letzten Jahren ausschliesslich auf TSMC Prozessen. Bei einem Foundry-Wechsel spielt ein neuer Faktor mit und alles was ich hier sagen will ist dass AMD IMHO dafuer sorgen wird das kleinstmoegliche Risiko einzugehen hauptsaechlich um keine sehenswerten Verspaetungen zu erlauben und eben auch NVIDIA keinen Luftraum um einzuatmen zu lassen.

Dass AMD mit dem Wechel mit einer neuen und teilweise unbekannten Aufforderung konfrontiert sein werden steht ja auch im Anand/RV870 Artikel.

Es waere wirklich eine Schande wenn AMD nach RV770 und RV870 ihren execution record ploetzlich brechen muss.

[S940]

Dumme Gegenfrage warum benutzte AMD nicht RV790 sondern 740 fuer ihr TSMC 40G Testrennen?
Ok, überzeugt, ich modifiziere meine Aussage auf 28nm high-end plus vorherigen Mini Testchip :)

Norther Island stand auf der einen Roadmap vom letzten Jahr ja zuerst einmal als 32nm mobile Chip drin.

32nm gibts nun nicht mehr, aber dann halt 28nm ...

Im Mobile Bereich würde der relativ teure Prozess auch Sinn machen, da man das Produkt höher einpreisen kann.
Libraries zu wechseln von hypothetisch TSMC 28nm/bulk zu GF 28nm/bulk geht nicht im Handumdrehen und gleiches gilt auch fuer jegliche foundry.
Jo natürlich, aber ist ja nicht so, als ob sie das erst gestern beschlossen hätten ... die Planung geht schon lange, das hat mittlerweile genügend Vorlaufzeit.

ciao

Alex

[Ailuros]

Die Vorlaufzeit fuer jegliche derartige Aenderungen ist wohl schon ausgelaufen.

[Gast]

Wäre es möglich, dass noch ein kleinerer HD 5XXX Chip kommt, der bei GF gefertigt wird? Wie z.b. die 4770? Ich mein jetz nicht unbedingt 32/28nm sonder einfach Erfahrungen mit ner neuen Foudry sammeln..

[LadyWhirlwind]

Die Frage ist doch, ob sich AMD nen wesentlichen Vorteil gegenüber Nvidia bei nem Foundry wechsel verspricht, genug um das Risiko einzugehen?

z.B wesentlich früher mit 28mm aufwarten zu können als NV.

Ausserdem frage ich mich, ob nicht AMD schon bei der Übernähme daran Gedacht hat, die GPU's in der eigenen Foundry zu produzieren. Ev. haben die ja mit 28nm für ihre eigene Fab ursprünglich geplant.

[S940]

Die Vorlaufzeit fuer jegliche derartige Aenderungen ist wohl schon ausgelaufen.
Welche Änderung meinst Du ?
Die auf GF als FAB, oder von 32 -> 28nm ?
Oder was anderes ?