Pirate Islands: Bermuda, Fiji, Treasure | mobile: Strato, Litho - 2015

[Sunrise]

Das es früher oder später kommt sollte aber klar sein.
Schon klar, nur wird hier von Mai/Juni geredet, was ja schon in 3-4 Monaten ist. Die müssten also eigentlich zwingend jetzt schon verfügbar sein, wenn das funktionieren soll. Zudem müsste Fiji bereits komplett finalisiert und zur Massenproduktion freigegeben sein.

Keine Ahnung ob ein Clamshell mode wie bei GDDR5 vorgesehen ist, aber wenn dann wären auch 8GB mit 8 Stacks bei "nur" 4096 bit möglich.
Ja, meine Betrachtung ging eher ausgehend von HBM1 (also 1024bit pro Modul). OK, dann passt das mit den 8192bit (was ich für zu teuer für Fiji und generell im derzeitigen Stadium halte).

Wenn Hynix übrigens HBM2 für NV und etliche andere Kunden sowieso hochfahren muss, dann können wir uns auch wieder über den Preis unterhalten. Aber bei diesen Mengen, die anfänglich produziert werden, wird HBM (man erinnere sich an die damaligen GDDR5-Preise) so früh kein Sonderangebot. Und das weiß auch AMD.

[fondness]

Schon klar, nur wird hier von Mai/Juni geredet, was ja schon in 3-4 Monaten ist. Die müssten also eigentlich zwingend jetzt schon verfügbar sein, wenn das funktionieren soll. Zudem müsste Fiji bereits komplett finalisiert und zur Massenproduktion freigegeben sein.

Mag sein das es zu beginn nicht verfügbar ist, dann kommt eben ein paar Monate später ein Refresh, auch kein Beinbruch.


Wenn Hynix übrigens HBM2 für NV und etliche andere Kunden sowieso hochfahren muss, dann können wir uns auch wieder über den Preis unterhalten. Aber bei diesen Mengen, die anfänglich produziert werden, wird HBM (man erinnere sich an die damaligen GDDR5-Preise) so früh kein Sonderangebot. Und das weiß auch AMD.

Die 4870 wurde jetzt auch nicht so teuer verkauft, genau genommen hat sie NV zu eine drastischen Preissenkungen gezwungen. Bei GDDR5 wurde auch am Anfang viel geredet wie teuer das nicht sei, im Endeffekt war es ein voller Erfolg darauf zu setzen.

[StefanV]

Schon klar, nur wird hier von Mai/Juni geredet, was ja schon in 3-4 Monaten ist. Die müssten also eigentlich zwingend jetzt schon verfügbar sein, wenn das funktionieren soll. Zudem müsste Fiji bereits komplett finalisiert und zur Massenproduktion freigegeben sein.
Nur weil etwas nicht in Datenblättern/Produktlisten auftaucht, heißt das nicht, dass es das nicht trotzdem gibt.

Es ist ja auch nicht auszuschließen, dass AMD die entsprechenden Produkte nicht trotzdem von Hynix bekommen könnte, auch wenn sie nirgends aufgeführt werden...

Ist halt, wie meistens, eine Frage der MoQ und des Preises...

[Nakai]

Ich halte es praktisch für ausgeschlossen, dass SKhynix für AMD 4Gb Slices anbietet. 4Gb Dies kommen erst mit HBM2 bzw. mit der nächsten Iteration. Ich vermute, dass AMD für Fiji HBM IP von Cadence verwendet, welche gleich für HBM2 kompatibel ist. Ergo muss AMD nur auf HBM2 mit größeren Dies warten und schon geht das Speichervolumen hoch.

[Dural]

Von mir Ausgesehen ist es so wie so noch zu früh für HBM. Und deswegen ist AMD auch wohl ziemlich still was das 4GB Problem der 970 betrifft, weil sie im High-End Bereich selber nur 4GB bieten werden.

[Botcruscher]

HBM kommt sicher. Die Frage ist ob 4 oder schon 8GB.
Gibt es irgendwo passenden Lesestoff?

[Raff]

Von mir Ausgesehen ist es so wie so noch zu früh für HBM. Und deswegen ist AMD auch wohl ziemlich still was das 4GB Problem der 970 betrifft, weil sie im High-End Bereich selber nur 4GB bieten werden.

Als wenn es das jetzige Marketing interessieren würde, was in 3 Wochen ist. ;) Hier gilt fast immer das Motto "Was juckt mich mein Geschwätz von gestern?", man dreht die Dinge, wie man sie braucht.

MfG,
Raff

[N0Thing]

Von mir Ausgesehen ist es so wie so noch zu früh für HBM. Und deswegen ist AMD auch wohl ziemlich still was das 4GB Problem der 970 betrifft, weil sie im High-End Bereich selber nur 4GB bieten werden.

Deine Aussage würde nur dann Sinn ergeben, wenn die GTX 970 4GB voll nutzbaren Speicher hätte. AMD kann immer noch auf "echte" 4GB verweisen, wenn sie keine Karten mir mehr als 4GB bringen sollten.

[robbitop]

Mir ist der Sinn von HBM zum jetzigen Zeitpunkt auch noch nicht so klar. Unnötig hohes Risiko und Bandbreite hätte man sicher auch mit GDDR5 noch genug. GM204 ist dank Delta FB Kompression nicht all zu Bandbreitenlimitiert. 50 % mehr Leistung bräuchte 384 bit GDDR5. Mit 512 Bit hätte man sogar noch Luft nach oben. Und man könnte super einfach 8 GiB raufpacken.

Wenn es nicht noch irgendeinen anderen großen Vorteil bringt (so viel Leistungsaufnahme haben 8 GiB VRAM nun auch wieder nicht), muss es noch einen anderen Vorteil bringen.

Ich tippe mal ganz spekulativ auf Bermuda - das könnte etwas mehr als 2x Fijii @AFR sein. Interposer bräuchte man für HBM sowieso - warum nicht 2x Fliegen mit einer Klappe? Transparent funktionierendes mGPU ggf. vieleicht in Fijii schon implementiert und in Bermuda benutzt? :)

In dem Zusammenhang könnte man die 2x 4 GiB auch nicht-redundant ausnutzen und hätte effektiv 8 GiB VRAM zur Verfügung.

Indiz: Bermuda kommt laut aktuellen Infos erst viele Monate nach Fijii - eine einfache x2 Karte bräuchte wohl nicht so viel mehr Zeit...

[Botcruscher]

Der ganze Speichercontroller samt Zwischenspeichern dürfte deutlich einfacher ausfallen. Zusätzlich sollte es jede Menge Strom sparen.

[tm0975]

Und deswegen ist AMD auch wohl ziemlich still was das 4GB Problem der 970 betrifft, weil sie im High-End Bereich selber nur 4GB bieten werden.

Das "nur 4 GB" in Zusammenhang mit einer 970 hat mir gefallen. ;D;D;D

4 GB reichen fürs erste locker aus. wenn dann 8 gb in 2. hj folgen, ist das doch völlig zufriedenstellend. solln sie das ganze erstmal bugfrei und kostengünstig in massenproduktion bringen.

[fondness]

Dieselbe Diskussion gab es bei GDDR5 auch, genauso bei GDDR3, etc. Ja man könnte auch mit GDDR3 und einem 2048bit SI dieselbe Bandbreite erreichen - nur deshalb muss es noch lange nicht sinnvoll(er) sein. Die Vorteile von HBM überwiegen die Nachteile offenbar so deutlich, dass AMD ein überschaubares Risiko eingegangen ist, nicht mehr und nicht weniger.

Und ja bis zu 50W Leistungsaufnahmeersparnis, sehr hohe Bandbreite und sehr niedrige Latenz, dazu ein wesentlich einfacheres PCB sind nicht zu verachtende Vorteile, für die man wohl ein paar Monate Verzögerung für eine 8Gb Version in Kauf genommen hat. Nvidia hätte DP bei GM200 sicher nicht ohne Druck gestrichen.

[john carmack]

HBM kommt sicher. Die Frage ist ob 4 oder schon 8GB.
Gibt es irgendwo passenden Lesestoff?

Kann schon sein das 4GB standard sind und eine 8GB Version von Sapphire als TOXIC kommt ;)

[Gipsel]

Wenn es nicht noch irgendeinen anderen großen Vorteil bringt (so viel Leistungsaufnahme haben 8 GiB VRAM nun auch wieder nicht), muss es noch einen anderen Vorteil bringen.Auch 20W sind schon etwas, das man in mehr Takt für den Chip investieren kann (man sollte nicht vergessen, daß nicht nur die RAM-Chips selber Energie ziehen, sondern die PHYs im Chip praktisch nochmal die gleiche Menge). Und bei einem High-End-Chip sind es mehr als das. Dazu kommt Flächenersparnis für die PHYs/Pad-Area. Die nimmt bei einem High-End-Chip schon mal so 50-60mm² für das GDDR5-Interface ein. Wenn man da die Hälfte spart, könnte AMD z.B. 5-6 CUs mehr in die gleiche Gesamtfläche quetschen. Und wie schon von anderen erwähnt, man spart Kosten beim PCB, langfristig dann vielleicht sogar mal Kosten insgesamt (wenn das Stacking kein Risiko mehr ist und somit der Preis für HBM sinkt [perspektivisch dürfte das irgendwann sogar mal billiger werden als GDDR5]). Und irgendwer muß mal damit anfangen.
Und ja bis zu 50W Leistungsaufnahmeersparnis, sehr hohe Bandbreite und sehr niedrige Latenz, dazu ein wesentlich einfacheres PCB sind nicht zu verachtende VorteileBis auf die Latenz stimmt das. Die ändert sich auch bei HBM nicht wesentlich gegenüber allen anderen DRAM-Techniken.

[HOT]

Ich halte es praktisch für ausgeschlossen, dass SKhynix für AMD 4Gb Slices anbietet. 4Gb Dies kommen erst mit HBM2 bzw. mit der nächsten Iteration. Ich vermute, dass AMD für Fiji HBM IP von Cadence verwendet, welche gleich für HBM2 kompatibel ist. Ergo muss AMD nur auf HBM2 mit größeren Dies warten und schon geht das Speichervolumen hoch.
Warum sollte das hinderlich sein? Wenn man entsprechend größere Chips anbieten kann, wäre es doch ein Leichtes, die zu nutzen. Das kommt doch nicht wirklich auf die Kapazität der Chips an. Wenn es höhere Kapazitäten gibt, kann man die sicherlich auch verbauen. HBM1 heißt doch nur Anbindung+Takt. Derzeit gibts eben nur 2Gb-Speicher.

Mir ist der Sinn von HBM zum jetzigen Zeitpunkt auch noch nicht so klar. Unnötig hohes Risiko und Bandbreite hätte man sicher auch mit GDDR5 noch genug. GM204 ist dank Delta FB Kompression nicht all zu Bandbreitenlimitiert. 50 % mehr Leistung bräuchte 384 bit GDDR5. Mit 512 Bit hätte man sogar noch Luft nach oben. Und man könnte super einfach 8 GiB raufpacken.

Wenn es nicht noch irgendeinen anderen großen Vorteil bringt (so viel Leistungsaufnahme haben 8 GiB VRAM nun auch wieder nicht), muss es noch einen anderen Vorteil bringen.

Ich tippe mal ganz spekulativ auf Bermuda - das könnte etwas mehr als 2x Fijii @AFR sein. Interposer bräuchte man für HBM sowieso - warum nicht 2x Fliegen mit einer Klappe? Transparent funktionierendes mGPU ggf. vieleicht in Fijii schon implementiert und in Bermuda benutzt? :)

In dem Zusammenhang könnte man die 2x 4 GiB auch nicht-redundant ausnutzen und hätte effektiv 8 GiB VRAM zur Verfügung.

Indiz: Bermuda kommt laut aktuellen Infos erst viele Monate nach Fijii - eine einfache x2 Karte bräuchte wohl nicht so viel mehr Zeit...

Bermuda wird schon ein neuer Chip sein. Da der Chip aufgrund des neuen Prozesses eh länger dauert als die PCB-Entwicklung wird man sich einfach entschlossen haben, das X2-PCB gleich mitzuentwickeln und beides (395X und 395X2) auf den Markt zu werfen.
Da man ja offenbar schon seit spätestens Mitte 2014 am Silizium arbeitet, wird es nur noch auf den Prozess drauf ankommen, wann der released wird. Ich würde mal tippen, dass Bermuda sowas wie ein Tahiti-Nachfolger wird. Neuer Prozess, nicht übertrieben gross, eben als Pionierchip gedacht. Lineup kommt dann deutlich später.

Ich nehme an, dass AMD nur Tonga 1:1 bei TSMC und GloFo gleichzeitig produzieren wird, also ähnlich wie bei Kabini geschehen. Grenada und Trinidad wird man schon auf Kostenoptimierung getrimmt haben. Also:

R9 360(X) Trinidad => 1280 SPs, GCN 1.3/2.0, 128Bit GDDR5 nativ (2 und 4GB)
R9 370(X) Tonga (GloFo) => 2048 SPs, GCN 1.2, 256Bit GDDR5 nativ (4GB)
R9 380(X) Granada (!= Maui/Hawaii) => 3072 SPs, GCN 1.3/2.0, 384Bit GDDR5 nativ (6GB)
R9 390(X) Fiji => 4096 SPs, GCN 1.3/2.0, 4096Bit HBM
R9 395(X(2)) Bermuda => 4096SPs, GCN2.x, 14nm, HBM/2

Alle 28nm Chip sind nicht DP, für professionell behält man einfach Kleinserie bei TSMC für Tahiti und Hawaii bei und fertig. Alle anderen Chips gehen sicherlich EOL.

[fondness]

Bis auf die Latenz stimmt das. Die ändert sich auch bei HBM nicht wesentlich gegenüber allen anderen DRAM-Techniken.

Sollte diese nicht schon alleine aufgrund des wesentlich kürzeren Signallaufwege sinken?

[Nakai]

Nein, ich meinte nicht die Slices, sondern wenn man 8Hi stackt. Ich gehe davon aus, dass es in einem Package mit Heatspreader ausgeliefert wird. Der Unterschied zwischen 4Hi -> 8Hi müsste schon ein anderes Package benötigen.

Wenn man 4Gb Slices anbietet -> no prob.

Naja 4Gb Slices werden noch nirgends erwähnt. HBM 2 hat 8Gb Slices und 2/4/8-Hi Stacks.

[Dural]

Wer sagt das die 3,5GB für die 970 zu wenig sind, der muss auch sagen das die 4GB für Fiji zu wenig sind.

Ich hätte da jetzt lieber wieder ein 512Bit und 8GB gesehen als eben HBM und 4GB. Eventuell ging das mit den 512Bit / GDDR5 halt nicht mehr.

[Blediator16]

Wer sagt das die 3,5GB für die 970 zu wenig sind, der muss auch sagen das die 4GB für Fiji zu wenig sind.

Ich hätte da jetzt lieber wieder ein 512Bit und 8GB gesehen als eben HBM und 4GB. Eventuell ging das mit den 512Bit / GDDR5 halt nicht mehr.

Seit Generationen gibt man sich mit dem mindesten an vram bei nvidia zufrieden, lässt sich bei der 970 verarschen und plötzlich sind 4gb nicht mehr genug

[fondness]

Vor allem gab es jetzt mal durch die neuen Konsolen einen Sprung beim VRAM-Bedarf, das wird aber natürlich nicht so weiter gehen, denn die Konsolen bleiben stehen.

[Lard]

Sollte diese nicht schon alleine aufgrund des wesentlich kürzeren Signallaufwege sinken?
Im Vergleich zu meiner HD 7970 (http://www.sisoftware.eu/rank2011d/show_system.php?q=cea598ad94a395b3d4e9dde8cebc81b197fec3f3d5bd80b096eed3e1c7a2c7 facaec9fa292&l=de), mit einer optimierten Latenz von 205ns:
http://www.sisoftware.eu/rank2011d/show_run.php?q=c2ffcbfed8b9d8e5d6eedbeaccbe83b395f095a898becdf0c8&l=de

:biggrin:

[Gipsel]

Sollte diese nicht schon alleine aufgrund des wesentlich kürzeren Signallaufwege sinken?Nein. Die Lichtgeschwindigkeit (okay, in Leiterbahnen bewegen sich Signale je nach genauem Aufbau der Leitungen nur mit etwa der halben) ist schon ziemlich hoch ;). Da spielen ein paar Zentimeter mehr oder weniger keine wesentliche Rolle bei Latenzen von etlichen Nanosekunden (1ns=30cm bei Lichtgeschwindigkeit oder eben ~15cm bei halber).
Die Signallaufwege haben zusammen mit der Frequenz vor allem Einfluß auf die Größe der benötigten Treiber, mit denen man die Signale über die Leitungen schickt, also vor allem den für eine bestimmte Entfernung bei einer bestimmten Geschwindigkeit nötigen Energieaufwand (Stromverbrauch).

Edit:
Im Vergleich zu meiner HD 7970 (http://www.sisoftware.eu/rank2011d/show_system.php?q=cea598ad94a395b3d4e9dde8cebc81b197fec3f3d5bd80b096eed3e1c7a2c7 facaec9fa292&l=de), mit einer optimierten Latenz von 205ns:
http://www.sisoftware.eu/rank2011d/show_run.php?q=c2ffcbfed8b9d8e5d6eedbeaccbe83b395f095a898becdf0c8&l=deDie eigentliche DRAM-Latenz ist niedriger. SiSoft mißt oft Schrott oder nicht das, was sie behaupten.

[AnarchX]

Im Rahmen der Codenamen-Nennung ausgehend vom 3DC, nennt TPU Tobago (http://www.techpowerup.com/gpudb/2661/radeon-r7-350x.html)für einen Bonaire-Rebrand/Refresh.

[HOT]

Dann wären das ja dann alle:
340 Samoa (PI) 6CUs -> Oland Refresh
350 Tobago (CI) 14CUs -> Bonaire Refresh
360 Trinidad (CI) 20CUs -> Pitcairn Refresh
370 Tonga (VI) 32CUs -> Tahiti Refresh
380 Grenada (CI) 44CUs -> Hawaii Refresh
390 Fiji (PI) 64CUs
395 Bermuda (PI) 64CUs


komplettes Lineup
und klar, wo ein Trinidad ist, ist ein Tobago nicht weit :D.
Dann sind Caribbean Islands einfach GloFo-Refreshes der bisheringen TSMC-Linien. Sind auch sicherlich alle auf aktuellen GCN-Stand gebracht worden, glaub nicht, dass man jetzt noch neue GCN1.0/1-Chips auflegt.

Erhalten bleiben bei TSMC in Kleinserie:
Cap-Verde (Matrox/FirePro)
Tahiti (FirePro)
Tonga (Apple/FirePro)
Hawaii (FirePro)

[Hübie]

Bis auf Fiji <-> Bermuda sieht das konsistent aus. 56 CUs gingen auch. AMD hat ja ne fette crossbar oder hab ich was verpasst?

[HPVD]

Alle 28nm Chip sind nicht DP, für professionell behält man einfach Kleinserie bei TSMC für Tahiti und Hawaii bei und fertig. Alle anderen Chips gehen sicherlich EOL.

hmm meinste wirklich? gerade bei (DP-)Berechnungen könnte man deutlich von der Bandbreite durch HBM profitieren.
Und AMD wollte strategisch in dem Bereich HPC stärker werden und machen entsprechendes Marketing...
http://fireuser.com/blog/category/hpc/

[Käsetoast]

hmm meinste wirklich? gerade bei (DP-)Berechnungen könnte man deutlich von der Bandbreite durch HBM profitieren.
Wahrscheinlich wäre es aber nicht dumm damit auf HBM2 zu warten, denn wenn derzeit tatsächlich 4 GB das Ende der Fahnenstange wären, wäre das für HPC zu wenig und selbst wenn 8 GB jetzt schon möglich wären, dann könnte man damit durchaus noch bis HBM2 warten um auch Speicher jenseits der 8 GB anbieten zu können. Generell macht Hawaii HPC technisch ja auch keine schlechte Figur, so dass ich da keinen allzu großen Druck sehe so schnell wie möglich was Neues zu bringen...

[Hübie]

Technisch nicht, aber in Hinblick auf Perf/Watt, und da widerspricht nicht mal AMD, muss man etwas bringen.

[horn 12]

Zwar Nichts Neues, aber Zusammenfassung.

http://www.guru3d.com/news-story/amd-radeon-r300-grenada-is-380xfiji-is-390x-and-bermuda-is-395x2.html

[HOT]

Das Die ist ein ganz normaler TSMC Hawaii. Steht wohl nur exemplarisch da drin.

[horn 12]

Ja, gerade selbst gesehen.
Sorry Allseits!

[Nakai]

Um mal wieder auf das Thema zu kommen. Selbst Hawaii hing teilweise an der Bandbreite. Von 2500Mhz auf 3000Mhz RAM Takt, kamen so im Schnitt 5% raus. Mit einem besseren Frontend, siehe Tonga, wären nochmal 5~10% drin. Hawaii könnte im Schnitt so 10% ohne Limitierungen gutmachen. Eventuell skaliert man mit dem verbessertem Frontend endlich besser. Tonga ist ja eigentlich teilweise, wegen der grundsätzlichen Konfig, meistens in den Benches nicht sonderliche vor einem Tahiti PRO gelandet. Das geht besser.

Wie es aussieht, will AMD GM204 und GM200 mit Fiji bekämpfen. Ein Fiji PRO ein gutes Stück vor GM204 und Fiji XT mit 300W. Eventuell gibt es nur einen Fiji und der skaliert von 200 bis 300W.

[Schnitzl]

Dann wären das ja dann alle:
340 Samoa (PI) 6CUs -> Oland Refresh
350 Tobago (CI) 14CUs -> Bonaire Refresh
360 Trinidad (CI) 20CUs -> Pitcairn Refresh
370 Tonga (VI) 32CUs -> Tahiti Refresh
380 Grenada (CI) 44CUs -> Hawaii Refresh
390 Fiji (PI) 64CUs
395 Bermuda (PI) 64CUs


komplettes Lineup
und klar, wo ein Trinidad ist, ist ein Tobago nicht weit :D.
Dann sind Caribbean Islands einfach GloFo-Refreshes der bisheringen TSMC-Linien. Sind auch sicherlich alle auf aktuellen GCN-Stand gebracht worden, glaub nicht, dass man jetzt noch neue GCN1.0/1-Chips auflegt. (...)
Alles wird refreshed? Da hab ich so meine Bedenken ^^
Das würde für mich heissen danach kommt erstmal lange nichts mehr. (1 Jahr +)
Andere Möglichkeit wäre Hawaii Refresh, Tonga weiterhin bei TSMC, Pitcarin Refresh. Alles andere bleibt bis zur 400 Serie, welche von unten nach oben refreshed wird in (20nm oder) 14nm

Wie wahrscheinlich kann es sein dass Bermuda Fiji in 20nm ist? (Ende des Jahres)

Schon interessante Situation.... kommt HBM, in welchen Chips... was wird refreshed was nicht...
Irgendwie ist alles möglich - von fettes Lineup bis "der letzte Sargnagel für AMD" :|
Ich hoffe auf FETT. =)

[Ailuros]

Afaik HBM fuer jetzt nur ab Fiji und ja 28nm.

[-/\-CruNcher-/\-]

TrueAudio und Co wird jetzt aber vollumfänglich integriert sein bei der 3xx serie oder wird es wieder die selben differenzierungen geben wie bei der 2xx serie ?
So gesehen ist ja nix mehr rebranded und sollte nun endlich auf einer linie stehen oder ?

[Thunder99]

Was ist denn eigentlich nochmal das Delta zwischen GCN 1.0 und 1.1 sowie 1.2?

Weiter wäre es natürlich Bombe wen der Hawaii Refresh bei gleicher CU Anzahl sagen wir 30% schneller wäre. Ist das so in etwas geplant oder kommt der Chip als reiner Refresh ohne Optimierungen?

[robbitop]

R9 360(X) Trinidad => 1280 SPs, GCN 1.3/2.0, 128Bit GDDR5 nativ (2 und 4GB)
R9 370(X) Tonga (GloFo) => 2048 SPs, GCN 1.2, 256Bit GDDR5 nativ (4GB)
R9 380(X) Granada (!= Maui/Hawaii) => 3072 SPs, GCN 1.3/2.0, 384Bit GDDR5 nativ (6GB)
R9 390(X) Fiji => 4096 SPs, GCN 1.3/2.0, 4096Bit HBM
R9 395(X(2)) Bermuda => 4096SPs, GCN2.x, 14nm, HBM/2

Alle 28nm Chip sind nicht DP, für professionell behält man einfach Kleinserie bei TSMC für Tahiti und Hawaii bei und fertig. Alle anderen Chips gehen sicherlich EOL.
Wozu Fijii einfach nur als Bermuda shrinken? Sowas kam in der GPU Historie selten vor.

[reaperrr]

Was ist denn eigentlich nochmal das Delta zwischen GCN 1.0 und 1.1
Leicht verbesserte Tesselation-Performance, etwas bessere Mantle-Unterstützung (wobei das auch ne reine Treiber-Sache sein kann), ansonsten nur zusätzliche Features (TrueAudio, XDMA-Crossfire, neuere UVD/VCE-Revisionen, mehr und leistungsfähigere ACEs).

und 1.1 sowie 1.2
Etwas deutlicher verbesserte Tesselation-Performance, Delta-Color-Compression, ansonsten nur neuere UVD/VCE-Revisionen, flexiblerer Display-Controller (FreeSync, DSR) und eventuell bessere/vollständigere Unterstützung für DX12/11.3.

Weiter wäre es natürlich Bombe wen der Hawaii Refresh bei gleicher CU Anzahl sagen wir 30% schneller wäre. Ist das so in etwas geplant oder kommt der Chip als reiner Refresh ohne Optimierungen?
Halte ich für extrem unrealistisch. Mehr als etwas höhere Taktraten und durch bessere Kühlung/niedrigere Spannung reduziertes Throttling würde ich nicht erwarten ggü. den 290(X).

[fondness]

Technisch nicht, aber in Hinblick auf Perf/Watt, und da widerspricht nicht mal AMD, muss man etwas bringen.

Da nv bei Maxwell dp auch streichen musste, steht AMD mit Hawaii gegen gk110 sicher nicht schlecht da.

[Hübie]

Dann erkläre mir trotz starker Überlegenheit bei DP-Berechnungen seitens AMD deren Quartalszahlen :rolleyes:

Edit: Ähm. Glaub ich hab das falsch aufgefasst. So gesehen hast du nicht Unrecht, nur ist DP halt wenig relevant.

[tm0975]

Dann erkläre mir trotz starker Überlegenheit bei DP-Berechnungen seitens AMD deren Quartalszahlen :rolleyes:

Edit: Ähm. Glaub ich hab das falsch aufgefasst. So gesehen hast du nicht Unrecht, nur ist DP halt wenig relevant.

die erklärt doch AMD selbst. hast du dich denn schonmal etwas dazu belesen?! und der rest kommt dann im conference call. der verlust stammt größtenteils aus abschreibungen auf alte apus und auf eigene aktien.

[Thunder99]

Hinzu kommt das ein Wechsel nicht so geht wie wir unsere Unterwäsche wechseln.

Naja zu 1.1 und 1.2 hoffe ich doch das VSR und FreeSync ja noch verbessert werden damit diese relativ unabhängig von dem GNC Stand laufen :)

Sonst muss es echt halt Fiji mit 1.3 bringen :(

[Kriton]

TrueAudio und Co wird jetzt aber vollumfänglich integriert sein bei der 3xx serie oder wird es wieder die selben differenzierungen geben wie bei der 2xx serie ?
So gesehen ist ja nix mehr rebranded und sollte nun endlich auf einer linie stehen oder ?

Ich glaube auch nicht an einen reinen rebrand.
Wenn sie im Q2/Q3 neue Karten bringen und MS Win 10 im Juni RTM geht, dann haben wir in Q4 DX12 auf dem Desktop. Wer kauft denn unter dieser Maßgabe zu dem Zeitpunkt noch Karten, die kein DX 12 (in HW) voll unterstützen?
Es sei denn, da kommen doch keine neuen HW-Features.

[HOT]

Wenn diese Chips von GloFo kommen, wär das ja auch ne völlige Ausnahmesituation. Man musste dann ja eh alle Chips neu auflegen, da wird man alle auf den neuesten Stand gebracht haben.

[Kriton]

Unter einem rebrand verstehe ich aber im Wesentlichen: Bezeichnung im Bios ändern und neuer Karton.

[Unicous]

Hilfe, wie dämlich ist eigentlich F(u)ad Abazovic?

http://www.fudzilla.com/news/graphics/36995-amd-fiji-hbm-limited-to-4gb-stacked-memory

Seine Quellen sind natürlich die Mikroben in seinem Mastdarm, aber so einen Schwachsinn kann man sich wirklich nicht ausdenken:

AMD is using what is calls a 2.5D-IC silicon interposer, which means that there will be two separate chips on the same silicon interposer and package substrate. Fiji in 28nm will be one of these chips, and the second batch of chips will be the High Bandwidth Memory (HBM) memory designs. However, there is a catch with AMD's approach.


Nvidia on the other hand is using what is called Vertical stacking 3D, or on-package stacked DRAM for its Pascal 2016 GPUs. Nvidia gives a straightforward explanation of the meaning of 3D memory on Pascal: "3D memory: Stacks DRAM chips into dense modules with wide interfaces, and brings them inside the same package as the GPU."


Es ist das Gleiche, aber nicht das Gleiche, sondern fast dasselbe, oder so ähnlich.

Und das man derzeit nicht mehr als 4 Stacks und ne fette GPU auf einen Interposer bekommt, weiß wohl außer ihm auch nur der Rest der (IT-)Welt.

"our sources".:freak:

[Nakai]

http://www.sisoftware.eu/rank2011d/show_device.php?q=c9a598d994d0f0a2c3a7c2adc3e3a4d6b7c7afc6a5d6f097aa87b690e2dfef c9a09dac8ae2dfeaccb489b89efb9ea393b5c6fbc3&l=de

Nur neue Ergebnisse, sonst nix. Ahja interessant, wie man den HBM-Speicher bei 470MHz betreibt, was einer Bandbreite von 235GB/s entspricht.

[horn 12]

@Nakai

Könnte Fiji XT und Pro echt gar vorgezogen werden.
Laut diversen Gerüchten sollte gar eine Vorstellung Ende März, Mitte April NICHT MEHR ganz ausgeschlossen werden.
NUR Fiji soll wohl Freesync komplett unterstützen (DP 1.3)
und die Neuen Mittelklasse Ableger
----> Hawai Refresh wohl auch DP 1.3 kompatibel.

[y33H@]

Sagen welche "Gerüchte"?

[Duplex]

Geheime Quellen :D

[Unicous]

Sagen welche "Gerüchte"?

Das sind die Stimmen in hornys Kopf die je nach Tagesstimmung entweder die aktuelle Preislage der 290er Serie in Italien herunterbeten, oder "neue" Exklusiv-Infospekulationen über die 300er Series haben. Je nach Windrichtung und Sonnenstand wird auch Abverkauf der 200 Series ausgerufen sowie tagesaktuell die exakten Lagerbestände bei italienischen IT-Händlern veröffentlicht.

Und das so gut wie jeden Tag.

[N0Thing]

Es kommt auch bestimmt bald ein neuer Treiber, der die aktuellen AMD-Karten vor die GTX 980 hievt.

[Ailuros]

Hilfe, wie dämlich ist eigentlich F(u)ad Abazovic?

So schlimm wie Theo zwar nicht, aber trotzdem :freak:

Das sind die Stimmen in hornys Kopf die je nach Tagesstimmung entweder die aktuelle Preislage der 290er Serie in Italien herunterbeten, oder "neue" Exklusiv-Infospekulationen über die 300er Series haben. Je nach Windrichtung und Sonnenstand wird auch Abverkauf der 200 Series ausgerufen sowie tagesaktuell die exakten Lagerbestände bei italienischen IT-Händlern veröffentlicht.

Und das so gut wie jeden Tag.

Na dann schick ihn bitte mal aufs Dach damit das Wetter endlich besser wird :P

Sonst kommt Fiji nach meinem Geburtstag.

[Spasstiger]

http://www.sisoftware.eu/rank2011d/show_device.php?q=c9a598d994d0f0a2c3a7c2adc3e3a4d6b7c7afc6a5d6f097aa87b690e2dfef c9a09dac8ae2dfeaccb489b89efb9ea393b5c6fbc3&l=de

Nur neue Ergebnisse, sonst nix. Ahja interessant, wie man den HBM-Speicher bei 470MHz betreibt, was einer Bandbreite von 235GB/s entspricht.
HBM-DRAM arbeitet doch auch nach dem DDR-Verfahren, ich komme auf 481 GB/s.

[Nightspider]

Sonst kommt Fiji nach meinem Geburtstag.

Willst du dir etwa Fiji holen? Zockst du überhaupt? ^^

[iuno]

HBM-DRAM arbeitet doch auch nach dem DDR-Verfahren, ich komme auf 481 GB/s.
Bei SiSoft ist die DDR-Verdopplung mit drin. Habe aber auch erst gestutzt, jedoch gibt es dort auch Einträge mit 1,25 GHz (also 625 MHz)

[mironicus]

Willst du dir etwa Fiji holen? Zockst du überhaupt? ^^

Eine Karte zu besitzen und mit anderen Menschen darüber zu sprechen reicht den meisten hier im Forum doch aus. :freak:

Wir gehören alle zu einer grooooooßen Familie. ;D

[john carmack]

Eine Karte zu besitzen und mit anderen Menschen darüber zu sprechen reicht den meisten hier im Forum doch aus. :freak:

Wir gehören alle zu einer grooooooßen Familie. ;D


Dann kauf ich mir auch 4 überteuerte Titanen nur um hier mitsprechen zu können und entsprechend tolle Messergebnisse präsentieren zu können ;D:freak:

[Dural]

Er meint wohl einfach das Datum wann die Karten im Laden stehen.


Einige hier haben so wie so sehr grosse Wunsch Vorstellung, ich sage nur Refresh Refresh Refresh
Am ende wird die hälfte einfach Umgeklebt und gut ist.

[Spasstiger]

Bei SiSoft ist die DDR-Verdopplung mit drin. Habe aber auch erst gestutzt, jedoch gibt es dort auch Einträge mit 1,25 GHz (also 625 MHz)
Die erste Generation HMB ist für max. 1,2 "Gigatransfers/s" (600 MHz) spezifiziert, das wären bei 4 HBM-Stacks dann max. 614,4 GB/s. Das ist die 3,5-fache Speicherbandbreite einer Radeon R9 285 bei nur bestenfalls der 2,5-fachen Rechenleistung. Ich denke nicht, dass AMD wirklich ans Limit geht, man braucht ja auch Luft nach oben für die nächste GPU-Generation. ;)
512 GB/s bzw. 1 Gigatransfers/s oder 500 MHz klingen für mich realistisch, das ist genau die Mitte der 1st-Generation-HBM-Spezifikation und reicht aus, um die 4096 SPs zu befeuern.

[iuno]

Darum geht es überhaupt nicht, hast du überhaupt gelesen, was ich geschrieben habe?
Bei SiSoft werden etwa für die R9 290X 5 GHz Speichertakt angegeben, also der effektive Takt inklusive 'DDR-Verdoppelung'. Die eingetragenen 470 MHz entsprächen demnach 240.640 MB/s und nicht etwa 481.280 MB/s. Also so wie Nakai geschrieben hat, auf den du dich bezogen hast, nur hat er einen kleinen Fehler gemacht und durch 1024 geteilt.
Als ich gesehen habe, dass es einige Einträge mit 470 MHz gibt, dachte ich auch, dass vielleicht wegen der neuen Technik falsch ausgelesen wird und anders als sonst üblich nicht der effektive Takt angegeben wird, weil 500 MHz realistisch und eben 470 nah dran sind. Das macht aber keinen Sinn, wenn man sieht dass es dort auch Einträge mit 1250 MHz gibt.

[Botcruscher]

Wenn Speicher und Chip synchron laufen passt das schon. Dann hat die Karte nicht hoch getaktet.

[Skysnake]

Weil ich gerade auf THG wieder was von GDDR5 zusätzlich zum HBM lesen musste, muss ich doch hier nochmal meinen Senf dazu ablassen.

Wenn die 4GB HBM wirklich ein absolutes NoGo wären, dann würde man eher DDR3/4 drauf packen, und nicht GDDR5. DDR3/4 ist einfacher zu routen und hat viel viel viel höhere Speicherkapazitäten. Ein Single-Channel würde da schon völlig ausreichen, um jedwedes Speicherproblem zu lösen. Wenn man nen DIMM Slot auf die Rückseite packen würde, könnte man sogar die Kosten richtig schön tief halten, und für Compute wäre es halt sehr sehr fett.

Intel macht mit KNL ja nichts anderes.

[y33H@]

Intel packt aber auch 16 GB HMC auf die Xeon Phi :ulove:

[OBrian]

@Skysnake: kann man das denn auch sinnvoll nutzen, oder hat man dann so einen Einbruch an der Speichergrenze wie bei der 970?

Ich würde mir das unbedarfterweise so vorstellen, daß man die Daten in kleinstmöglichen Stückchen gleichmäßig auf beide RAM-Arten aufteilt. Allerdings würde dann für alles die Bandbreite runtergehen, also auf den Durchschnitt. Würde bei total übermäßiger Bandbreite durch HBM ja durchaus noch eine ordentliche Geschwindigkeit ergeben, zumindest wenn man zu 4 GB HBM-RAM nur 4 GB hinzufügt, dann trifft man sich auf der Hälfte. bei zusätzlichen 12 GB wäre dann von der HBM-Bandbreite nur noch ein Viertel übrig (die Bandbreite von 1-Kanal DDR3 geht ja gerundet gegen Null^^).

Oder sehe ich das ganz falsch?

[Botcruscher]

~20GB/s für Zusatzspeicher?!? Wird die 970 jetzt zum Vorbild? Da kann man gleich 6GB mit HBM anbinden.

[iuno]

Wenn Speicher und Chip synchron laufen passt das schon. Dann hat die Karte nicht hoch getaktet.

Was soll da bitte synchron sein? Chip auf 800(/1000?) MHz, Speicher auf 235(/500?) MHz

Erklär mal wie du 6 GB HBM anbinden willst an einem 4096 Bit Interface

[Botcruscher]

DDR3/4 braucht zusätzlich auch ein Interface. Solchen quatsch baut einfach keiner. Dann würde man besser mit 6144 anbinden.

Synchron könnte auch ein Teiler von 2 sein. Falls die ausgelesen Daten überhaupt stimmen.

[OBrian]

Wahrscheinlich läuft es darauf hinaus, daß einfach gewartet wird, bis größere Stacks verfügbar werden, dann gibt es auch 8 GB-Karten. Soll ja nur ein gutes halbes Jahr oder so dauern. Alles andere wäre zusätzlicher Aufwand für viel zu wenig Effekt.

[horn 12]

Dies würde die Karte weiter verzögern, ein NOGO das sich AMD nicht leisten darf.
Man kommt sonst schon um knapp 7 bis 8 Monate nach GTX 970/980 auf den Markt.

[Unicous]

Wahrscheinlich läuft es darauf hinaus, daß einfach gewartet wird, bis größere Stacks verfügbar werden, dann gibt es auch 8 GB-Karten. Soll ja nur ein gutes halbes Jahr oder so dauern. Alles andere wäre zusätzlicher Aufwand für viel zu wenig Effekt.

Quark, sie warten, weil sie hoff(t)en ihre Inventar-Probleme in den Griff zu bekommen.

Sie haben anscheinend Anfang letzten Jahres zu wenig auf Lager gehabt während die Bitcoin-Säcke versucht haben einen schnellen Taler zu machen und die gebrauchten Karten dann wieder zurückgeschickt haben und dann Ende letzten Jahres bei Maxwell 2.0 Release viel zu viele.

Das rächt sich jetzt, sodass die OEMs sogar gebettelt haben, nicht mehr mit Chips beliefert zu werden, weil sie noch volle Lager mit Karten haben und AMD dem zähneknirschend nachkommt.

http://www.channelregister.co.uk/2015/02/12/amd_stops_chip_shipments/

Um sich keinen "reverse-Osborn" zu erleiden, sitzen sie das Ganze jetzt für eins, zwei, drei Quartale aus. Das ist äußerst schlecht für den Umsatz, aber volle Lager zu haben ist mindestens genauso schlimm.

[Skysnake]

Intel packt aber auch 16 GB HMC auf die Xeon Phi :ulove:
Und in wie fern macht jetzt weniger Speicher die Konstellation unwahrscheinlicher? ;)

@Skysnake: kann man das denn auch sinnvoll nutzen, oder hat man dann so einen Einbruch an der Speichergrenze wie bei der 970?

Du nutzt es "einfach" als "Cache" nicht mehr aber auch nicht weniger. So lange du niedrigere Latenzen als PCI-E und ne höhere Bandbreite hast, haste schon einen Vorteil.


Ich würde mir das unbedarfterweise so vorstellen, daß man die Daten in kleinstmöglichen Stückchen gleichmäßig auf beide RAM-Arten aufteilt. Allerdings würde dann für alles die Bandbreite runtergehen, also auf den Durchschnitt. Würde bei total übermäßiger Bandbreite durch HBM ja durchaus noch eine ordentliche Geschwindigkeit ergeben, zumindest wenn man zu 4 GB HBM-RAM nur 4 GB hinzufügt, dann trifft man sich auf der Hälfte. bei zusätzlichen 12 GB wäre dann von der HBM-Bandbreite nur noch ein Viertel übrig (die Bandbreite von 1-Kanal DDR3 geht ja gerundet gegen Null^^).

Oder sehe ich das ganz falsch?
Nein, gleichmäßig aufteilen ist das dümmste was man machen könnte. Daten haben meist eine gewisse Datenlokalität, das ist ja auch der Grund, warum Caches überhaupt funktionieren ;) Also nutzt man das auch da aus.

DDR3/4 braucht zusätzlich auch ein Interface. Solchen quatsch baut einfach keiner. Dann würde man besser mit 6144 anbinden.

Synchron könnte auch ein Teiler von 2 sein. Falls die ausgelesen Daten überhaupt stimmen.
Dann ist also Intel ne Dummbatzfirma oder wie?

Bei KNL machen Sie nämlich genau das. Einen "kleinen" extrem schnellen HMC Memory, ok 16GB sind nicht wirklich richtig klein, aber im Vergleich zu den hunderten GB, dass das DDR4 Interface noch liefert ist es dann doch winzig ;)
Selbst der "langsame" DDR4 Ram ist halt noch immer deutlich schneller als das PCI-E Interface, vor allem wenn man ein Dualchannel nimmt.

[OBrian]

nein ich meine, erst kommt Fiji mit 4 GB und dann später mit 8. Ist dann zuerst nicht so sonderlich attraktiv, aber dann ist die Verfügbarkeit wenigsten kein Problem. Und später kann man dann mit den doppelt so großen Stacks marketingtechnisch praktisch einen Refresh machen.

Das Zurückhalten von Karten wegen Lagerbeständen alter Karte betrifft ja hauptsächlich Tonga, ggf. auch Hawaii (je nachdem, wie unterschiedlich der Hawaii-Refresh ist). Oder wer kauft jetzt noch eine 280X oder zwei, weil Fiji noch nicht da ist?^^

[Botcruscher]

Dann ist also Intel ne Dummbatzfirma oder wie?

Bei KNL machen Sie nämlich genau das. Einen "kleinen" extrem schnellen HMC Memory, ok 16GB sind nicht wirklich richtig klein, aber im Vergleich zu den hunderten GB, dass das DDR4 Interface noch liefert ist es dann doch winzig ;)
Selbst der "langsame" DDR4 Ram ist halt noch immer deutlich schneller als das PCI-E Interface, vor allem wenn man ein Dualchannel nimmt.

Ist KNL ein Grafikkarte? Nein? Gut.

[Unicous]

@OBrian

Wieso Tonga? Tonga ist davon eher nicht betroffen, wegen dem iMac Retina. Eher sind es Hawaii und der Rest der 200 Series (wahrscheinlich auch Tahiti, denn Tonga Pro hat die 280 nocht nicht abgelöst). Und da Tonga Pro weiterhin auf 280X Preislevel ist dürfte klar werden, dass die Lagerbestände für die 280er SKUs noch mehr als ausreichend sind.

Die 2. HBM "Generation" kommt erst 2016, hat Bryan Black erst vor Kurzem wieder bestätigt, und der muss es ja schon irgendwie wissen.

https://twitter.com/EUTSVSummit/status/557490125333348352

[OBrian]

das sind ja auch ganz andere Mengen an RAM. Es geht doch darum, ob Fiji mit 4 GB genug RAM hat, um verkauft werden zu können, oder unbedingt 8 GB nötig sind. Daß die besser wären, ist eh klar. Aber 16 GB auf der Karte würden nur im professionellen Bereich Sinn machen.

Für den professionellen Bereich könnte man auch einen größeren Interposer nehmen und mehr Stacks verbauen. Ist ja sicherlich nicht so extrem viel aufwändiger/teurer.

@OBrian

Wieso Tonga? Tonga ist davon eher nicht betroffen, wegen dem iMac Retina. nein, ich meine, Tonga kommt deswegen extra nur so künstlich ausgebremst auf den Markt: Nur die teildeaktivierte Version, nur 2 GB, überhöhter Preis. Die Karten, die Tonga mit Leichtigkeit ersetzen könnte, sind noch zuhauf im Channel.

[Unicous]

Es gibt (momentatn) keinen "größeren" Interposer. Es ist schon jetzt ein Problem so einen großen Interposer überhaupt herzustellen. Das hatten wir vor ein paar Wochen schon besprochen. Ab einer Schwelle nimmt der Yield rapide ab und die 800+mm² Interposer ist im Moment das höchste der Gefühle.

Auch im professionellen Bereich kann man diese Problem nicht umgehen, sondern maximal eine zweiten, externen Speicherbereich anbinden, mit den entsprechenden Nachteilen, die hier ja schon besprochen wurden.

Es besteht aber natürlich noch die theoretische Möglichkeit, dass hynix speziell für AMD die Stack-Kapazität verdoppelt hat. Das hat ja nichts mit HBM 2 an sich zu tun. Bei HBM 2 geht es ja speziell um die Verdoppelung der RAM Stacks von maximal 4 auf maximal 8 und damit einhergehend Verdoppelung der Bandbreite pro Stack.

Intel nutze ja anscheinend auch eine proprietäre Version von HMC.

Aber allem Anschein sieht es nicht so aus. Daher wird sich FirePro-Fiji(x2) offenbar unter einer W9100 ansiedeln, bezogen auf Speicherkapazität.

Edit: Letzteres ist natürlich Blödsinn, die W9100 ist ja gar keine Dual-GPU. Ich meinte eigentlich die FirePro S10000 und da macht es sogar sehr viel Sinn. Denn hier ist immer noch Tahiti(x2) verbaut und auch nur 6 GB.

[Skysnake]

Ist KNL ein Grafikkarte? Nein? Gut.
Sie bedienen den gleichen Markt, sind also direkte Konkurrenten, und du kannst auch bei AMD darauf warten, dass die GPUs ohne Host funktionieren.

Ich kann dazu gerade nicht mehr sagen, aber schau einfach mal, ob in den nächsten Wochen/Monaten folgendes Paper verfügbar wird:"Scalable Communication Architecture for Network-Attached Accelerators"

das sind ja auch ganz andere Mengen an RAM. Es geht doch darum, ob Fiji mit 4 GB genug RAM hat, um verkauft werden zu können, oder unbedingt 8 GB nötig sind. Daß die besser wären, ist eh klar. Aber 16 GB auf der Karte würden nur im professionellen Bereich Sinn machen.

Man hätte wie gesagt auch nichts dagegen, 128GB+ zu haben. Mit GDDR5 ist das nur nicht machbar. Wenn man aber mit HMC/HBM eh relativ wenig RAM hat, und gerne mehr hätte, nutzt man gleich DDR3/4, die eben richtig auf die Kacke hauen können. Im Consumerbereich wird ja auch DDR3/4 genutzt, obwohl der maximale Ausbau mehrere hundert GB erlaubt pro CPU. Das ist dann eben auch dementsprechend teuer.


Für den professionellen Bereich könnte man auch einen größeren Interposer nehmen und mehr Stacks verbauen. Ist ja sicherlich nicht so extrem viel aufwändiger/teurer.

DOCH IST ES!

Du musst den Interposer komplett neu designen, das Speicherinterface, die gesamten Toplvl vom Power Delivery Network, das Pinlayout, usw usw usw. Das sind immense Kosten, die einem da entstehen können.

Es gibt (momentatn) keinen "größeren" Interposer. Es ist schon jetzt ein Problem so einen großen Interposer überhaupt herzustellen. Das hatten wir vor ein paar Wochen schon besprochen. Ab einer Schwelle nimmt der Yield rapide ab und die 800+mm² Interposer ist im Moment das höchste der Gefühle.

Man könnte das durchaus auch auf Waferlvl machen. Es gibt ja auch Waferlvl-Chips (Btw. sieht echt krank aus ;D). Man müsste halt mit deutlich größeren Pitches usw usf leben, aber machbar wäre es durchaus. Ob es Wirtschaftlich ist, ist wirklich die spannendere Frage. Vor allem will man sich ja auch für die Zukunft noch Luft lassen ;)


Auch im professionellen Bereich kann man diese Problem nicht umgehen, sondern maximal eine zweiten, externen Speicherbereich anbinden, mit den entsprechenden Nachteilen, die hier ja schon besprochen wurden.

Naja, theoretisch schon, aber wird nicht gemacht im Allgemeinen. Wenn dann für Spezialchips aus der Forschung.

[Pick]

AMD C880 PRINTED CIRCUIT BOARD ASSEMBLY (VIDEO GRAPHIC CARD)WITH COOLER MASTER HEATSINK P/N.102-C88001-00 (FOC)
https://www.zauba.com/import-102-c88001-00-hs-code.html

[y33H@]

WaKü kam bisher von Asetek ...

[Unicous]

War es nicht so, dass einige Hersteller Asetek-Lösungen nutzen und lediglich ihr Logo draufklatschen?

[Skysnake]

CoolerMaster nicht. Zumindest haben Sie AUCH eine Eigenentwicklung

[Pick]

800MHz Core/470MHz HBM - Cooler Master Heatsink
1GHz Core/1250MHz HBM - Asetek Liquid Cooler

es kann sein :biggrin:

[iuno]

@pick: seriously? Fiji mit 240.640 MB/s? Das ist so viel wie eine 280 hat. Und zusätzlich eine Version mit 640.000 MB/s, die soll man nutzen können?

[Korvaun]

Sofern Fiji fertig und in Massenproduktion ist sehe ich keinen Grund einen Release zu verzögern. 4GB reichen aktuell aus, auch preistechnisch gesehen ist das wohl die einzig vernünftige Speichergröße die machbar ist. Eine 8GB Version zu Weihnachten für die "Verrückten" könnte ich mit aber vorstellen. Da 2016 eh die richtigen Brummer kommen (in 14/16nm), die dann höchtwahrscheinlich von den meisten potenziellen Fiji-Kunden wieder gekauft werden ist auch die Zukunftssicherheit ok.

Das Preissegmet oberhalb von 400€ ist völlig frei für AMD, ich denke "small-Fiji" als 980er-Gegner könnte so ca. 450€ kosten, der "top-Fiji" dann entsprechend ca. 550-600€ Listenpreis.

Alos hophop AMD, ich will euch Geld geben für ne Fiji, macht hinne ;)

[Thunderburne]

Wie kommst du auf Brummer in 2016 .
Das werden zu Beginn bestimmt wieder kleine chips mit um die 300mm2 sein.

[horn 12]

Zwar erneut Fuad, Fudzilla, udg. aber sollte da was dran sein, kann man die 1,5 Monate auch noch warten.
Würde sich mit dem GTA 5 Release knapp decken.

http://wccftech.com/amd-fiji-xt-r9-390x-cooler-master-liquid/

Fiji Pro wohl dann auf gutem GTX 980 Level (+15 bis 20%) mit Luftkühlung und Preislich attraktiver als der große Bruder!
Man will Fiji wohl komplett ausreizen und wäre somit um die 40% über einer GTX 980.
Meinerseits ein Fail, so eine AIO Wasserkühlung,- dies könnte nach hinnten losgehen.
Außer man weiss im Vorfeld dass sich Fiji Pro weitaus besser verkauft und bringt mit jener Karte einen Verkaufsschlager.
Somit soll(te) Fiji XT nur ein Prestige Produkt werden, ähnlich der R9 295X2.
Jene Karte würde dann 300 Watt brauchen und in 4K so ziemlich alles abziehen was möglich ist.

[Nightspider]

Ist für 2016 eigentlich schon eine neue Architektur geplant oder wird AMD Fiji nur shrinken?

14nm würde immerin recht kurz nach Fiji schon wieder einen großen Sprung ermöglichen.
2016 dürften Fiji + mind. 60% locker drin sein oder?
Also 2,5 bis 3 fache fache Hawaii-Power. Und bei einem eher kleinen 14nm Chip wenigstens 2,2 fache Hawaii Leistung imo.

Oder geht ihr immer noch davon aus das Bermuda ein 14nm Chip ist? Wenn dem so wäre, wäre das aber bestimmt auch nur ein kleiner Chip in 14nm und 2016 könnte noch ein großer (>380mm²) kommen.

[Skysnake]

BOAH könnt ihr mal diese "wann bringt AMD mal ne neue Architektur"-Scheise sein lassen? Wie oft muss man das an sich noch durchkauen? GCN ist von Grund auf neu gemacht und hat die ganzen Altlasten über Bord geschmissen. Da gibts nichts wirklich dran zu ändern rein von der Architektur her. Daher sollte auch niemand in den nächsten Jahren irgendetwas Neues erwarten. Es gibt schlicht nichts, was aktuell dafür sorgen würde, das es einen Punkt in GCN gibt, wo man denkt, dass das aber suboptimal gelöst ist vom Konzept her.

Was AMD machen muss ist an der Implementierung zu arbeiten, und insbesondere am Commandprozessor, und wie man eben mit dem Tesselator umgeht usw usf. Das hat aber alles NICHTS mit GCN an sich zu tun, sondern nur mit der Implementierung....

Können wir also das Thema ENDLICH mal beerdigen?

[Hübie]

Ich glaub die meinen einfach eine neue Version der Architektur, Skysnake. Reg dich nicht so auf ;) Ausser Gefasel und Wunschvorstellungen kommt hier seit ein paar Seiten nix produktives.
Mich interessiert mal die Cache Hierarchie und das Subsystem. Mit HBM und fettem L2 Cache sollte echt einiges machbar sein.
Edit: unter der Prämisse es kommen "nur" 4 GB. Was eigentlich völlig ausreichend ist. Leider wissen das die Studios nicht (alle).

[Korvaun]

Die "neue Architektur" geht wohl auch bei GPUs mittlerweile eher Richtung Intel-CPU-Updates, immer 5-10% Prozent Verbesserung pro neuer Generation und das war es. Ich zumindest erwarte keine wirklich neuen Wunderarchitekturen in den nächsten Jahren...

[Skysnake]

Ja, ein fetterer L2 würde wohl schon einiges bringen, aber nvidia scheint allgemein die Arbeit einfach besser auf ihre Ressourcen zu mappen als AMD. Da sieht man wohl die vielen Jahre an Treiber/Firmware entwicklung.

Leider werden wir nie so tiefe Einblicke bekommen, um verstehen zu können, warum AMD so performt wie sie performen im Vergleich zu nvidia.

[Hübie]

Also bei nVidia kann ich dir sagen dass es an deutlich weniger Datentransfer liegt. Seit Tesla hat sich da ne Menge geändert. Cache Hits/Misses, Cached Caches und solche Spielchen. Die lösen das einfach besser auf. Ist wohl auch viel compiler-Arbeit oder Treiber-Arbeit. Weiß nicht in wie weit man das in Hardware löst/lösen sollte.
Auf der GTC gabs da eins, zwei interessante Vorträge zum Thema. Vielleicht spuckt google was aus :smile:

ps: Hast meine letzte PN nicht mehr beantwortet :P

[Agent117]

Weiß nicht in wie weit man das in Hardware löst/lösen sollte.


Hmh seit Tesla oder wars Fermi? hat man doppelt so geringe latenzen wie AMD und nutzt das auch für eine nur halb so große Wavefrontsize. Das bringt theoretisch weniger Verschnitt. Ob es viel an Effizienz bringt kann ich nicht sagen.

GCN könnte man da auch umbauen. Mit Latenzen von 2 (wie NV) statt bisher 4 ließe sich eine Wavefrontsize von 32 realisieren. Dann würden nur zwei SIMD-16 Blöcke die Wavefront abarbeiten.
Nachteil wäre aber aber eine deutlich aufwendigere Kontroll- und Cachelogik.
Ein biszchen einfacher wären 4 SIMD-8 Einheiten, die wie die bisherigen SIMD-16 Einheiten arbeiten.
Aber auch hier hätte man dann doppelt so viele Cluster und mehr Cache- und Kontrollogik.

[Hübie]

Ich glaube bei AMD ists einfach die fette Crossbar die für Compute zwar vorteilhaft sein kann, aber eben ne Menge Energie verbrät. Obwohl ich zugegebenermaßen gar nicht weiß ob die im Hawaii immer noch so ist wie ichs vom Tahiti kenne.

Edit: Ich meine natürlich die crossbar oder den interconnect zwischen den Caches (L1, GDS, LDS L2, const, blah, blubb).

[fondness]

Sieht für mich so aus als hätte AMD die Abteilung für kühler weitgehend eingestellt /outgesourced. Die 285 hatte gar kein ref-design, im high-end kauft man die kühler extern zu.

[Knuddelbearli]

naja 960 und 970 haben auch kein referenzdesign

[Sunrise]

Sieht für mich so aus als hätte AMD die Abteilung für kühler weitgehend eingestellt /outgesourced. Die 285 hatte gar kein ref-design, im high-end kauft man die kühler extern zu.
Warum auch nicht, so nen Arctic Xtreme würd ich mir wahrscheinlich sowieso draufschnallen, da kann ich gerne auf die minderwertigen Kühler der IHVs verzichten.

[Hübie]

Die sind / waren eh unfähig also kann es nur besser werden. Wüsste jetzt auch keinen wirklichen Nachteil einer AiO-Wakü. Alle die ich kenne (inklsuive meiner Wenigkeit) konnte bisher über keine Ausfälle Defekte klagen. Manche haben sowas schon seit 5 Jahren im Einsatz.

[fondness]

Das war auch keine Kritik falls es jemand so verstanden haben sollte. Ich frage mich ganz im Gegenteil warum sich AMD & nv nicht schon länger Hilfe von kühlerherstellern holen. Von daher halte ich das für eine gute Entscheidung wo man auch gut einsparen kann ohne Substanz zu verlieren und hoffentlich auch bessere kühler zustande bringt. Es drückt aber natürlich zu Beginn auf die Marge keine Frage.

[Sunrise]

Das war auch keine Kritik falls es jemand so verstanden haben sollte. Ich frage mich ganz im Gegenteil warum sich AMD & nv nicht schon länger Hilfe von kühlerherstellern holen. Von daher halte ich das für eine gute Entscheidung wo man auch gut einsparen kann ohne Substanz zu verlieren.
Mittlerweile liefert ja fast jeder AIB eigenentwickelte Designs, die sich immer recht ähnlich (je nach TDP der Karte leichte Anpassungen) sind. Da war generell das Know-How wohl nicht vorhanden oder so verbreitet, das eigene Designs der IHVs evtl. sogar billiger waren.

Notfalls werden die Kühler zugekauft, so wie es AMD jetzt wohl auch wieder machen wird. Ich finde das einen sehr guten Schritt, allerdings bin ich etwas skeptisch bzgl. Cooler Master. Die machen gute Gehäuse, aber eher schlechte Luftkühler.

Die Wasser- bzw. AiO-Kühler scheinen allerdings gut zu sein, weshalb ich glaube, dass AMD eher an denen Interesse hat.

Im Endeffekt bräuchte man sowohl eine Single- als auch eine gute AiO-Dual-Lösung, dann könnte Fiji bzw. Bermuda auch problemlos gekühlt werden. Mehr als zwei Karten hat sowieso fast niemand.

[fondness]

Coolermaster hatte in der Vergangenheit durchaus auch hochwertige Graka Hybrid-Kühler, das aber wohl mangels Erfolg eingestellt: https://www.caseking.de/shop/catalog/::10825.html?belboon=00030000030100a05800259b,1880605,at102799_a102740_m12_p3434 _cAT%20&fp=00030000030100a05800259b

Im CPU-Bereich fertig man noch immer einige brauchbare Kühler, mal sehen was dabei raus kommt.

[Dural]

coolermaster ist eine feste grösse in diesem bereich, die haben auch schon kühler für nv gemacht.

[fondness]

Im Endeffekt bräuchte man sowohl eine Single- als auch eine gute AiO-Dual-Lösung, dann könnte Fiji bzw. Bermuda auch problemlos gekühlt werden. Mehr als zwei Karten hat sowieso fast niemand.

Da sehe ich kein Problem, ich denke man ist mit zwei einzelnen 120mm Radiatoren wesentlich flexibler und deshalb halte ich das auch für normale Gehäuse für die bessere Option als einen Doppelradiator den man aufwändig extra anbieten müsste. Kühlungstechnisch hat man da sicher auch kein Problem, selbst die ~550W der 295X2 kühlt das Ding von Asutek halbwegs leise weg, das sollte bei ~300W fast schon flüsterleise möglich sein. Und die warme Luft wandern auch noch aus dem Gehäuse.

[Nakai]

Ich glaube bei AMD ists einfach die fette Crossbar die für Compute zwar vorteilhaft sein kann, aber eben ne Menge Energie verbrät. Obwohl ich zugegebenermaßen gar nicht weiß ob die im Hawaii immer noch so ist wie ichs vom Tahiti kenne.

Edit: Ich meine natürlich die crossbar oder den interconnect zwischen den Caches (L1, GDS, LDS L2, const, blah, blubb).

Ich kann mir sehr schwer vorstellen, dass sich da vieles geändert hat.

http://i.neoseeker.com/a/AMD_HD_7950/Cache%20Hierarchy.png

AMD hat wirklich einen ziemlich fetten Crossbar verbaut. :freak:

Wenn man bedenkt, dass jede CU am Crossbar angeschlossen ist, sowie der ICache und skalare DCache, als auch der Vector DCache, ebenfalls die Command Processors(ACEs?), dann bekommt man eine Vorstellung, wie fett die Crossbar sein müsste. Puh, da hat NV ein einfacheres Design gewählt, imo. Wobei das schwierig zu beurteilen ist, da NV nicht viel rauslässt.

Aber ja, so ein großer Crossbar wird sicherlich mehr Energie schlucken und das Design komplizierter machen. Reinher von den Folien seitens Hawaii, sollte sich da nicht soviel geändert haben, aber man kann sich irren.

[fondness]

Glaubt hier wirklich jemand NV braucht keine Kommunikation zwischen den Caches oder zwischen Cache und ALUs? Nur weil NV null Infos raus lässt heißt das nicht das sie zaubern können.

[Nakai]

Glaubt hier wirklich jemand NV braucht keine Kommunikation zwischen den Caches oder zwischen Cache und ALUs? Nur weil NV null Infos raus lässt heißt das nicht das sie zaubern können.

Eine CU ist so ziemlich äquivalent mit einem SM seitens NV. Reinher von der Anzahl der SMs hat man bei NV schonmal deutlich weniger Verdrahtungsaufwand. Tahiti hatte 32CUs und GK104 "nur" 8 SMs. Bei AMD teilen sich 4 CUs einen ICache und skalaren DCache, welche zusätzlich verdrahtet sind. Jede CU ist zum GDS angebunden, jeder L1-Cache der CUs ist mit dem L2-Cache verbunden.

€: Aus meiner Laiensicht sieht das alles ziemlich "fett" aus.

[horn 12]

@Naki

Wie sicher ist eine Vorstellung, sprich Release in 4 bis 6 Wochen der R9 390X inkl. dem kleinen Bruder, bzw. weiterer Karten sowie R9 290 Refresh Vorstellung.
Dies mit ENDE MAI sollte somit nicht mehr aktuell sein und die Termine wurde echt um 2 Monate vorverlegt.
Da kam wohl das Fiasko der GTX 970 dem Abverkauf der R9 2x0 mehr als nur gelegen.
Daher die Kehrtwende.

[Skysnake]

nVidia hat sowas wie den GDS aber nicht in ihrer Architektur drin, auch nichts vergleichbares. Das Problem bei AMD ist "nur", dass Sie das NOCH IMMER NICHT! verfügbar machen über ne API....

Das Design ist halt wohl darauf ausgelegt auch Preemption usw zu unterstützen, warum zumindest die Synchronisation zwischen Workgroups noch nicht eingeführt wurde ist mir schleierhaft. Das wird aber natürlich deutlich mehr Komplexität zur Folge haben.

Vom Grundsatz her ist das auch alles gut und schön/geil für Compute, aber leider für Graphics wohl ziemlich überflüssig. Es müsste nur endlich mal auch wirklich verwendet werden... Naja, vielleicht mit Fiji.

Sollte Fiji nicht zumindest sowas ähnliches wie preemption unterstützen?

[Nakai]

@Naki

Wie sicher ist eine Vorstellung, sprich Release in 4 bis 6 Wochen der R9 390X inkl. dem kleinen Bruder, bzw. weiterer Karten sowie R9 290 Refresh Vorstellung.
Dies mit ENDE MAI sollte somit nicht mehr aktuell sein und die Termine wurde echt um 2 Monate vorverlegt.
Da kam wohl das Fiasko der GTX 970 dem Abverkauf der R9 2x0 mehr als nur gelegen.
Daher die Kehrtwende.

Keine Ahnung, aber auf Zauba sind erstmals seit anfang Februar größere Mengen von Fiji und Co. zu sehen. Wenn dadurch Lager für AMDs Highend-Boliden frei geworden sind, wieso auch nicht.

AMD hat eh andere Probleme. Deren Architektur schluckt zuviel Strom. Eventuell bringen Tonga und Fiji etwas Milderung. Fiji scheint im unteren Bereich ja nicht soviel zu schlucken.

nVidia hat sowas wie den GDS aber nicht in ihrer Architektur drin, auch nichts vergleichbares. Das Problem bei AMD ist "nur", dass Sie das NOCH IMMER NICHT! verfügbar machen über ne API....

Das Design ist halt wohl darauf ausgelegt auch Preemption usw zu unterstützen, warum zumindest die Synchronisation zwischen Workgroups noch nicht eingeführt wurde ist mir schleierhaft. Das wird aber natürlich deutlich mehr Komplexität zur Folge haben.

Vom Grundsatz her ist das auch alles gut und schön/geil für Compute, aber leider für Graphics wohl ziemlich überflüssig. Es müsste nur endlich mal auch wirklich verwendet werden... Naja, vielleicht mit Fiji.

Sollte Fiji nicht zumindest sowas ähnliches wie preemption unterstützen?

Sollte Tonga das nicht schon unterstützen? GCN ist eine Compute-Architektur. Reinher von der Compute-Performance platziert sich GM204 in etwa zwischen Tahiti und Hawaii. Ich kann mir kaum vorstellen, dass Fiji keine starke DP-Unterstützung liefert.

[del_4901]

nVidia hat sowas wie den GDS aber nicht in ihrer Architektur drin, auch nichts vergleichbares. Das Problem bei AMD ist "nur", dass Sie das NOCH IMMER NICHT! verfügbar machen über ne API....
GDS ist ueberbewertet, wenn es nach mir gehen wuerde, dann koennen sie den GDS komplett entfernen und dann als naechstes den LDS.

[fondness]

Würde er das wirklich so sagen, wenn es bei Fiji nicht zumindest eine nahe Option auf 8GB gäbe?

Rashid Sayed: You guys do a fantastic job at getting high end GPUs at decent budgets but I wanted to ask about the silent, ongoing war between AMD and Nvidia for the ‘most power graphics card’. Although both companies have done an admirable joul in raising the bar higher, I am wondering if there is a practical implementation to these cards. Except the enthusiasts, whose numbers are extremely, do you see 12GB GPUs being the standard in the immediate future?

Robert Hallock: I personally do not envision 12GB being the standard, though lately we are seeing 8GB cards being advantaged. Reviewer data for games like Shadows of Mordor, for example, suggests that a game’s performance can improve by as much as about 15% on an 8GB card vs. a 4GB model. There are several 8GB AMD Radeon R9 290X GPUs entering the market from our partners to meet that challenge.


http://gamingbolt.com/the-big-interview-amds-robert-hallock-on-mantle-directx-12-ps4xbox-one-free-sync-and-more

[Sunrise]

@Naki

Wie sicher ist eine Vorstellung, sprich Release in 4 bis 6 Wochen der R9 390X inkl. dem kleinen Bruder, bzw. weiterer Karten sowie R9 290 Refresh Vorstellung.
Dies mit ENDE MAI sollte somit nicht mehr aktuell sein und die Termine wurde echt um 2 Monate vorverlegt.
Da kam wohl das Fiasko der GTX 970 dem Abverkauf der R9 2x0 mehr als nur gelegen.
Daher die Kehrtwende.
In 4-6 Wochen kannst du vergessen.

Fiji und das PCB scheint anhand der Zauba-Infos wohl fertig zu sein, man ist jetzt dabei die komplette Karte (inkl. Kühler) zu validieren und erst wenn alles passt, dann kannst du nochmals min. 2-3 Monate für die Verfügbarkeit rechnen. Das passt auch zu AMDs Aussage, dass sie noch "finishing touches" durchführen müssen.

Das heißt irgendwann im Mai bzw. Anfang Juni ist überhaupt die früheste Möglichkeit an Fiji zu kommen, wenn AMD nicht eher noch länger Zeit benötigt.

Und jetzt bitte frage nicht jede Seite erneut nach. Wenn ein Produkt nicht fertig (in Masse verfügbar) ist, dann wird es auch nicht früher vorgestellt werden können.

[Schaffe89]

@ horn 12

Markiere dir mal den 21 April, an diesem Tag dürfte Release sein.

[Sunrise]

@ horn 12

Markiere dir mal den 21 April, an diesem Tag dürfte Release sein.
Was ist am 21. April?

[Nightspider]

BOAH könnt ihr mal diese "wann bringt AMD mal ne neue Architektur"-Scheise sein lassen? Wie oft muss man das an sich noch durchkauen? GCN ist von Grund auf neu gemacht und hat die ganzen Altlasten über Bord geschmissen. Da gibts nichts wirklich dran zu ändern rein von der Architektur her. Daher sollte auch niemand in den nächsten Jahren irgendetwas Neues erwarten. Es gibt schlicht nichts, was aktuell dafür sorgen würde, das es einen Punkt in GCN gibt, wo man denkt, dass das aber suboptimal gelöst ist vom Konzept her.

Was AMD machen muss ist an der Implementierung zu arbeiten, und insbesondere am Commandprozessor, und wie man eben mit dem Tesselator umgeht usw usf. Das hat aber alles NICHTS mit GCN an sich zu tun, sondern nur mit der Implementierung....

Können wir also das Thema ENDLICH mal beerdigen?

Chill mal ey!
Ich meinte es genau wie Hütte sagte. Neue Architektur im Sinne von Upgrade GCN1.3 auf 1.4 -> (kleine Verbesserung) -> neuer Chip. Denn im Endeffekt gab es bei AMD in letzter Zeit mit einem neuen highend Chip auch eine "neue" Architektur. Also im Grunde war meine Frage ob es schon Aussagen zu einem neuen Chip in 2016 gibt bzw. Andeutungen / fundierte Vermutungen?

Ich nehme mal an nicht, da wir ja selbst noch bei Bermuda rumrätseln.

[Locuza]

Ich spekuliere im Augenblick so:

Uns fehlen noch einige Volcanic Islands Vertreter (IP v8).
Neben Tonga war nur Iceland als IP v8 gesichert, vom letzteren hört man leider nicht mehr viel.
Sollte er nicht tot sein, dann erwarte ich eine Flotte bestehend aus Iceland, Carrizo iGPU, Tonga und Fiji. (Der Rest vom Line-Up wird vermutlich leider von alten IP-Versionen gefüllt werden.)

2016 mit 14nm erscheint dann ein IP v9 Upgrade, aka Pirate Islands.

Man rätselt sogar noch über Tonga und ein ISA PDF zu Volcanic Islands ist auch noch nicht erschienen.

[Gipsel]

Hmh seit Tesla oder wars Fermi? hat man doppelt so geringe latenzen wie AMD und nutzt das auch für eine nur halb so große Wavefrontsize. Das bringt theoretisch weniger Verschnitt. Ob es viel an Effizienz bringt kann ich nicht sagen.

GCN könnte man da auch umbauen. Mit Latenzen von 2 (wie NV) statt bisher 4 ließe sich eine Wavefrontsize von 32 realisieren. Dann würden nur zwei SIMD-16 Blöcke die Wavefront abarbeiten.Da hast Du was mißverstanden. Die Latenzen bei AMD sind traditionell niedriger als bei nV. Man sollte Throughput nicht mit Latenz verwechseln. Der Throughput von 1 Warp/2 Takte von nV vs. 1 Wavefront/4 Takte bei AMD ist einfach eine Funktion der Größe der Warps/Wavefronts (32 vs. 64 Items) und SIMD-Einheiten (bei nV früher nur Breite 8, deswegen damals auch 4 Takte Throughput). Die Latenz war bei den VLIW-Architekturen von AMD 8 Takte, bei GCN für einfache Instruktionen sind es nur noch 4 Takte. NV hatte bei Fermi dagegen noch ~20 Takte Latenz, bei Kepler waren es dann 10-12 Takte (Maxwell weiß ich gerade nicht aus der hohlen Hand).

[mksn7]

Wozu ist denn der GDS gut? Für Global Memory Atomics?

[del_4901]

Wozu ist denn der GDS gut? Für Global Memory Atomics? GDS hat ein bissel weniger Latenz als L2 ist aber auch weniger Bandbreite. Summa summarum lohnt es sich nicht GDS zu verwenden.

[Hübie]

Der ist afaik für sync von wavefronts zuständig und wird vermehrt bei compute-Geschichten verwendet.
@nightspider: HÜTTE? :biggrin: Danke!

[Nightspider]

Das war die Autokorrektur von meinem neuen Spielzeug. :biggrin:

[Hübie]

Hahahaa. Gute "Korrektur". Wenn das n Android phone is probier mal SwiftKey Tastatur. :up: Sorry for OT!

Nimms Skysnake nicht krumm er hat vielleicht einfach n miesen Tag ;)

[Skysnake]

GDS ist ueberbewertet, wenn es nach mir gehen wuerde, dann koennen sie den GDS komplett entfernen und dann als naechstes den LDS.
Aus Sicht eines Graphik-Entwicklers auch völlig verständlich. Für compute wäre es aber schon teilweise ziemlich geil.

Man könnte damit ja endlich mal davon wegkommen, effektiv jedes mal einen Kernel neu starten zu müssen, wenn man eine globale Synchronisation braucht.

Würde er das wirklich so sagen, wenn es bei Fiji nicht zumindest eine nahe Option auf 8GB gäbe?
http://gamingbolt.com/the-big-interview-amds-robert-hallock-on-mantle-directx-12-ps4xbox-one-free-sync-and-more
Ja, ganz sicher. Heute ist heute und morgen ist morgen.

GDS hat ein bissel weniger Latenz als L2 ist aber auch weniger Bandbreite. Summa summarum lohnt es sich nicht GDS zu verwenden.
GDS soll vor allem halt einen cohärenten Datenzugriff ermöglichen. Das ist beim L2 meines Wissens nach nicht der Fall. Da kann es zu beliebigen Read-after-Write Problemen kommen.

Wegen der Bandbreite oder Latenz ist der GDS völlig uninteressant aus meinen Augen. Ich seh ihn als globales Scratchpad.

[del_4901]

Aus Sicht eines Graphik-Entwicklers auch völlig verständlich. Für compute wäre es aber schon teilweise ziemlich geil. Man könnte damit ja endlich mal davon wegkommen, effektiv jedes mal einen Kernel neu starten zu müssen, wenn man eine globale Synchronisation braucht. Mach einfach nen Atomic auf ein beliebiges Buffer element und ne memory barrier und gut ist. Das ist meisst schneller als GDS.
GDS soll vor allem halt einen cohärenten Datenzugriff ermöglichen. Das ist beim L2 meines Wissens nach nicht der Fall. Da kann es zu beliebigen Read-after-Write Problemen kommen.
Nope L2 (memory) ist genauso cohärent

[Hübie]

Also is der völlig bedeutungslos? :|

[Skysnake]

Und wie soll das funktionieren? Ich habe doch eben keine barrier über eine Workgroupe hinausgehend. Erst mit der Einführung vom GDS und den ISA Erweiterungen soll es doch auch globale Barriers geben/möglich werden.

Das Problem ist doch, das man kein preemption hat, man also in einen Livelock kommen kann. Soweit ich das aus der ISA-Doku verstanden habe, sollte man sich aber mit GCN alles zusammenschustern können, um eben einen Livelock verhindern zu können, egal wieviele Workitems man benutzt.

(und ja, ich kenne den Ansatz auch, der mal auf nVidia Karten gezeigt wurde, das man halt maximal 1 Workitem/Alu hat. Das ist aber im Allgemeinen völlig nutzlos, weil der Neustart des Kernels weniger leistungsverlust verursacht, als durch die reduzierte Anzahl an Workitems.)

@L2 cohärenz:
Meinste damit jetzt cohärent zum RAM? Wenn ja, dann ist das schon klar, ich meinte aber zu den CUs. Das wäre mir neu, und vom Programmiermodell her ja auch gar nicht gefordert.

[del_4901]

Und wie soll das funktionieren? Ich habe doch eben keine barrier über eine Workgroupe hinausgehend. Erst mit der Einführung vom GDS und den ISA Erweiterungen soll es doch auch globale Barriers geben/möglich werden.

Das Problem ist doch, das man kein preemption hat, man also in einen Livelock kommen kann. Soweit ich das aus der ISA-Doku verstanden habe, sollte man sich aber mit GCN alles zusammenschustern können, um eben einen Livelock verhindern zu können, egal wieviele Workitems man benutzt.

(und ja, ich kenne den Ansatz auch, der mal auf nVidia Karten gezeigt wurde, das man halt maximal 1 Workitem/Alu hat. Das ist aber im Allgemeinen völlig nutzlos, weil der Neustart des Kernels weniger leistungsverlust verursacht, als durch die reduzierte Anzahl an Workitems.)

@L2 cohärenz:
Meinste damit jetzt cohärent zum RAM? Wenn ja, dann ist das schon klar, ich meinte aber zu den CUs. Das wäre mir neu, und vom Programmiermodell her ja auch gar nicht gefordert. Nun laber doch nicht rum natuerlich hat L2 cohärent zu sein, gerade mit atomics sonst macht das ganze doch keinen Sinn.

https://msdn.microsoft.com/en-us/library/windows/desktop/ff471409(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/ff471350(v=vs.85).aspx

Und wenn man effizient ne neue Wave starten will dann macht man das im CP, da braucht es keinen GDS fuer L2 reicht vollkommen aus.

[Skysnake]

Das ist aber wie gesagt nur auf eine Workgroup (OpenCL-Sprech) bezogen, nicht Workgroupe übergreifend. Die Cohärenz ist auch nur auf Workgroups bezogen. Workgroupübergreifend haste gar keine Sicherheit darüber, was am Ende im RAM steht, wenn mehrere Workitems aus unterschiedlichen Workgroups auf das gleiche Datum lesend+schreibend zugreifen.

Mit DX brauchste da auch nicht kommen, da spielt das keine Rolle. Ich rede rein von Compute.

Bestes Beispiel ist doch immer wieder die 2D-Hitzeverteilung. Da gibt es keine Möglichkeit die Iterationsschritte zu synchen, es sei denn du startest den Kernel neu (Die ziemlich nutzlose Ausnahme hab ich ja oben erwähnt)

[Gipsel]

Sollte das nicht mit OpenCL 2.0 gehen, also global atomics mit memory_scope_device (statt nur workgroup) und gleichzeitig sequentially consistent memory order (memory_order_seq_cst)? Keine Ahnung, habe damit keine Erfahrung und mir das auch nie näher angesehen, aber gegenüber OpenCL 1.x haben die doch das Konsistenzmodell deutlich geändert.

@Alphatier:
Die von Dir verlinkte AllMemoryBarrier function synchronisiert nur innerhalb einer Threadgroup (Workgroup in OpenCL-Sprech), nicht über alle. Und Atomizität alleine sichert noch kein Ordering. Da kann man sich bestimmt Situationen überlegen, in denen das scheitert.

[Nakai]

Wegen der Bandbreite oder Latenz ist der GDS völlig uninteressant aus meinen Augen. Ich seh ihn als globales Scratchpad.

GCN bietet ja wohl global Synchronisation an...jedenfalls mit der internen ISA. Für alles andere nicht verfügbar. :freak:

Bestes Beispiel ist doch immer wieder die 2D-Hitzeverteilung. Da gibt es keine Möglichkeit die Iterationsschritte zu synchen, es sei denn du startest den Kernel neu (Die ziemlich nutzlose Ausnahme hab ich ja oben erwähnt)

OpenCL 2.0 erlaubt ja, dass Kernels neue Kernels spawnen können. Damit wäre GS schon erreicht. Ich habe derzeit Probleme mit einem iterativen Tiefpassfilter. Ich würde das gerne anderes lösen, aber derzeit weiß ich nicht, wie...

Ich erwarte jetzt nicht, dass Fiji irgendwelche neuartigen Sachen bringt. IMO sollte AMD GCN etwas entrümpeln bzw. keine 1-4er Gruppen erlauben, sondern nur noch in 4*64SP Schritten skalieren. Derzeit gibt es noch einen skalaren Cache, vll wäre es besser, diesen mit dem Vektor-Cache zu kombinieren.

Wie führt NV eigentlich skalare Operationen aus? GCN hat pro CU ja nicht nur Vektoreinheiten sondern auch skalare Einheiten und Ports für eine vielzahl von anderen Operationen(GDS, Export,...). Ich sehe bei Kepler und Maxwell keinerlei Einheiten für skalare Ops...

@Gipsel:
Sollte das nicht mit OpenCL 2.0 gehen, also global atomics mit memory_scope_device (statt nur workgroup) und gleichzeitig sequentially consistent memory order (memory_order_seq_cst)? Keine Ahnung, habe damit keine Erfahrung und mir das auch nie näher angesehen, aber gegenüber OpenCL 1.x haben die doch das Konsistenzmodell deutlich geändert.


Sollte ich mal angucken, aber derzeit wäre ein Wechsel auf OpenCL 2.0 nicht wirklich möglich.

€2: Eine Möglichkeit für global Sync ist ein SpinLock bzw. busy waiting. Aber wie zuverlässig -> kA. Ich habe es meistens vermieden zu benutzen.

[del_4901]

@Alphatier:
Die von Dir verlinkte AllMemoryBarrier function synchronisiert nur innerhalb einer Threadgroup (Workgroup in OpenCL-Sprech), nicht über alle. Und Atomizität alleine sichert noch kein Ordering. Da kann man sich bestimmt Situationen überlegen, in denen das scheitert.
Ordering ist richtig, aber braucht man das denn, wenn man einfach nur ueber eine value im Speicher syncen will? Men weiss doch vorher vieviele Threads in flight sind und dann koennte man einfach spinlocken.

Das ist aber wie gesagt nur auf eine Workgroup (OpenCL-Sprech) bezogen, nicht Workgroupe übergreifend. Die Cohärenz ist auch nur auf Workgroups bezogen. Workgroupübergreifend haste gar keine Sicherheit darüber, was am Ende im RAM steht, wenn mehrere Workitems aus unterschiedlichen Workgroups auf das gleiche Datum lesend+schreibend zugreifen. Wenn man alles in eine Cacheline haemmert dann hat man so oder so schon verloren.

Bestes Beispiel ist doch immer wieder die 2D-Hitzeverteilung. Da gibt es keine Möglichkeit die Iterationsschritte zu synchen, es sei denn du startest den Kernel neu (Die ziemlich nutzlose Ausnahme hab ich ja oben erwähnt)
Das neu starten des Kernels ist nicht der teure part, tuer wird es erst wenn der Treiber/Runtime oversynchronized und die occupancy drunter leidet. Ausserdem weisst du wieviele threads eine Itteration hat, dann kannst du dir das auch einfach im Speicher vermerken, und am Anfang jeder wave entscheiden an welcher Itteration sie arbeiten sollen. Ander wid das AMD auch nicht implementieren. GDS hin oder her hilft einem da nicht viel.

[Agent117]

Da hast Du was mißverstanden. Die Latenzen bei AMD sind traditionell niedriger als bei nV. Man sollte Throughput nicht mit Latenz verwechseln. Der Throughput von 1 Warp/2 Takte von nV vs. 1 Wavefront/4 Takte bei AMD ist einfach eine Funktion der Größe der Warps/Wavefronts (32 vs. 64 Items) und SIMD-Einheiten (bei nV früher nur Breite 8, deswegen damals auch 4 Takte Throughput). Die Latenz war bei den VLIW-Architekturen von AMD 8 Takte, bei GCN für einfache Instruktionen sind es nur noch 4 Takte. NV hatte bei Fermi dagegen noch ~20 Takte Latenz, bei Kepler waren es dann 10-12 Takte (Maxwell weiß ich gerade nicht aus der hohlen Hand).

Ok, danke für die Erklärung. Heißt also, die Anzahl der Takte, die benötigt werden, um eine Wavefront zu verarbeiten haben nichts mit der Latenz zu tun.
Das sah nur bei AMD immer so einfach aus, 4er Latent 4SIMD-16 und 64er Wavefront. Bei der GCN Vorgängerarchitektur hatte ich was mit 2 alternierend arbeitenden Shedulern in Erinnerung bei gleicher Wavefronsize und da klangen die 8er latenzen dann auch wieder logisch.
Gibt es zu Nvidias Aufbau irgendwo Daten im Internet, hab auf die Schnelle nichts vergleichbares zu den GCN Diagrammen gefunden?

[Gipsel]

Ordering ist richtig, aber braucht man das denn, wenn man einfach nur ueber eine value im Speicher syncen will? Men weiss doch vorher vieviele Threads in flight sind und dann koennte man einfach spinlocken.
Das mit dem Spinlock hat Nakai ja auch gerade erwähnt. Bei GCN könnte das prinzipiell sogar halbwegs effizient funktionieren, da man einen Thread (Hardware-Thread, also eine Wavefront) für eine bestimmte Anzahl Takte (z.B. 64) schlafen schicken kann (kommt man afaik bloß nicht ran, wenn man keinen ISA-Code schreibt), so daß eine Wavefront in der Warteschleife nicht die Ausführung der anderen Threads auf der gleichen SIMD-Einheit blockiert.
Ob das für Skysnakes Problem ausreichen würde, keine Ahnung. Aber für irgendwas wird das deutlich aufgebohrte und steuerbare Konsistenzmodell von OpenCL 2.0 vermutlich schon gut sein.

=====================================

Ok, danke für die Erklärung. Heißt also, die Anzahl der Takte, die benötigt werden, um eine Wavefront zu verarbeiten haben nichts mit der Latenz zu tun.
Grob gesprochen ist die Latenz die Anzahl der Takte, die tatsächlich benötigt werden, um eine Wavefront abzuarbeiten, d.h. bis das Ergebnis vorliegt. Das sind typischerweise die Anzahl der Pipelinestufen (im sogenannten critical loop).
Nur hat das nichts mit dem Durchsatz zu tun, der angibt, wie schnell nacheinander man Befehle oben in die Pipeline reinstopfen kann. So konnte Fermi alle 4 Takte einen neuen Befehl für irgendeinen Warp (einen anderen oder die Instruktion mußte unabhängig sein) annehmen. Bis die Ergebnisse in einem davon abhängigen Befehl benutzt werden konnten, vergingen aber 20-22 Takte für die meisten Instruktionen, so lange dauerte das Lesen der Operanden, das eigentliche Rechnen und das Zurückschreiben der Ergebnisse in die Register.
Das sah nur bei AMD immer so einfach aus, 4er Latent 4SIMD-16 und 64er Wavefront. Bei der GCN Vorgängerarchitektur hatte ich was mit 2 alternierend arbeitenden Shedulern in Erinnerung bei gleicher Wavefronsize und da klangen die 8er latenzen dann auch wieder logisch.Ja, bei GCN ist Latenz=Durchsatz für die ALU-Instruktionen (gibt ein paar Spezialfälle z.B. bei der Verwendung von Skalarregistern als Operand für Vektorinstruktionen, die direkt vorher erst gesetzt wurden), das macht es einfach (auch das Scheduling). NV löst(e) es eben deutlich komplizierter (insbesondere bei Fermi mit Scoreboard-Scheduling für alle Instruktionen, IMO völliger Overkill). Das hat nV dann ja bei Kepler (und mehr noch bei Maxwell) umgesetzt, daß man bei Instruktionen mit fester Latenz deutlich effizienter vorgehen kann (nur noch Speicherzugriffe laufen über Scoreboard-Scheduler, nicht die ALU-Instruktionen).
Gibt es zu Nvidias Aufbau irgendwo Daten im Internet, hab auf die Schnelle nichts vergleichbares zu den GCN Diagrammen gefunden?NV macht daraus ein ziemliches Geheimnis und wenn sie was sagen, kommt das oft zur Hälfte vom PR-Department. Da kann man sich also nie drauf verlassen, daß das intern wirklich so funktioniert, wie sie sagen. Bei AMD weiß man diesbezüglich wirklich mehr. Bei Kepler und Maxwell benutzt man wohl Latency-Counter für das Scheduling von abhängigen Befehlen und voneinander abhängige Befehle werden vom Compiler sozusagen markiert, damit der Warp-Scheduler weniger Arbeit hat, diese Abhängigkeiten zu erkennen.

[Nakai]

Das neu starten des Kernels ist nicht der teure part, tuer wird es erst wenn der Treiber/Runtime oversynchronized und die occupancy drunter leidet.

Was meinst du damit genau?

[Skysnake]

Ordering ist richtig, aber braucht man das denn, wenn man einfach nur ueber eine value im Speicher syncen will? Men weiss doch vorher vieviele Threads in flight sind und dann koennte man einfach spinlocken.

Ja braucht man, wie ich schon gesagt habe, da man sonst in einen Livelock rein rennt. Sobald du mehr Workitems als ALUs hast, weiste NIE, welche Threads ausgeführt werden. Das kann ziemlich schnell dazu führen, dass du einen Spinlock auf einigen wenigen Threads hast, und mindestens eine Workgroupe halt "nie" dran kommt. Da biste wirklich sehr schnell in nem Livelock drin, und dann ist aus die Maus.

Mit dem von Gipsel angesprochenen sleep für Workgroups könnte man das zwar theoretisch umgehen, aber man muss 1. direkt über die ISA Befehle gehen, was pfeu bäh ist und 2. Kannste auch nicht wirklich gut vorhersagen, wie lange du genau umbedingt schlafen musst, dass du NIE in einen Livelock rein rennen kannst. Das OS pfuscht dir ja meist auch noch mit rein, es sei denn du nutzt die Zweit-GPU für Compute nur. Kurz um, das ist nicht praktikabel, weil man zu viel Leistung verliert.


Wenn man alles in eine Cacheline haemmert dann hat man so oder so schon verloren.

Hä?
Ich versteh nicht was du meinst. Du kennst doch das 2D-Heatblade Problem sicherlich. Da haste einfach überlappende Speicherbereiche. Ist halt ein finites Elemente Problem mit Austausch zu den Nachbarn. Da haste immer genau die Konstellation/Problemstellung, die eben den NEustart eines Kernels erfordert.


Das neu starten des Kernels ist nicht der teure part, tuer wird es erst wenn der Treiber/Runtime oversynchronized und die occupancy drunter leidet. Ausserdem weisst du wieviele threads eine Itteration hat, dann kannst du dir das auch einfach im Speicher vermerken, und am Anfang jeder wave entscheiden an welcher Itteration sie arbeiten sollen. Ander wid das AMD auch nicht implementieren. GDS hin oder her hilft einem da nicht viel.
Also im Vergleich zu einem sturen durchrennen lassen, ist es schon Sack langsam. Zumindest waren das meine Ergebnisse von damals, als ich mich intensiv damit auseinander gesetzt hatte.

Ansonsten versteh ich gerade nicht, was du meinst mit "im Speicher vermerken...". Alle workitems arbeiten an einem ZEitschritt, und man muss im Endeffekt alle Workitems den Zeitschritt X bearbeiten lassen, bevor man den ZEitschritt X+1 bearbeiten kann. Ansonstne kommt es halt zu fehlern. DA kann man nicht einfach irgendwas aufteilen. Das hat man ja schon gemacht. Die zeitliche Entwicklung ist aber eben vom vorhergehenden Ergebnis abhängig.

@Gipsel:
Ja, an sich hätte da was kommen sollen, aber die Beschreibung von Funktionen in OpenCL 2.0 hat sich meiner Erinnerung nach geändert. Ich hatte mir das mit dem Launch von 2.0 nämlich mal angeschaut, und nichts dementsprechendes mehr gefunden. Habe aber auch nicht Unmengen an Zeit rein gesteckt. Ich versuche aber mal im Sommer, wenn ich ein paar Wochen hoffentlich mal frei habe, mich nochmals intensiv damit zu beschäftigen, und ein paar Beispielprobleme wie N-Body, Heatblade usw. auch zu programmieren. Besonders interessiert mich eigentlich seit längerem eine MPI-Implementierung eines Bucket sort Algorithmus auf GPUs. Mal schauen, ob ich dazu komme. Allerdings wäre für mich aktuell KNC an sich noch interessanter für dieses spezielle Problem.

[Gipsel]

Wie auch immer, ich glaube wir sollten mal wieder etwas näher zum Thema zurück.

[Skysnake]

Ja, das denke ich auch, wobei vielleicht kommt das Zeug ja endlich mit Fiji, hätte dann ja "nur" 3 Generationen gebraucht, bis es dann mal endlich richtig verwendbar ist :ugly:

[mksn7]

Kernel starten dürfte doch im µs-Bereich sein. War deine Domain sehr klein?

Mit temporal blocking kann man bei einem Jacobisolver mehrere Zeitschritte in einem Kernelcall machen. Ich weiß nicht wie sinnvoll das bei GPUs ist. Bei CPUs hat man deutlich mehr Cache pro lane und kann an größeren tiles arbeiten.

[mksn7]

Eher On-Topic: Spekuliert sind ja Speicherbandbreiten von 600Gb/s. Könnte das Memory subsystem von Hawaii soviel überhaupt auslasten? Ich errinnere mich dass z.B. eine K40 auf standard clocks (745 Mhz) selbst für stream workloads ihr Speicherinterface nicht voll auslasten kann, bzw. mit Boost Clocks (875 Mhz) noch mal eine gute Steigerung bei der Bandbreite hat. Oder dass z.B. beim Xeon Phi von 320 GB/s nur ca. 50% nutzbar sind.

[Hübie]

Ich weiß zwar nicht genau was du meinst aber Kepler hat einfach einige Missverhältnisse bzgl Anbindung und Größe jeglicher Speicher. Der L2 is laut diverser Aussagen zu klein um alle ALUs auszulasten. Das hat sich mit Maxwell geändert.

[Gipsel]

Eher On-Topic: Spekuliert sind ja Speicherbandbreiten von 600Gb/s. Könnte das Memory subsystem von Hawaii soviel überhaupt auslasten? Ich errinnere mich dass z.B. eine K40 auf standard clocks (745 Mhz) selbst für stream workloads ihr Speicherinterface nicht voll auslasten kann, bzw. mit Boost Clocks (875 Mhz) noch mal eine gute Steigerung bei der Bandbreite hat. Oder dass z.B. beim Xeon Phi von 320 GB/s nur ca. 50% nutzbar sind.
Schon die 64 Hawaii-ROPs drücken in den Füllratentests bei hardware.fr effektiv bis zu ~560 GB/s durch (was nur wegen Framebufferkompression funktioniert). Selbst bei älteren GPUs ohne diese Technik (Bonaire/HD7790/260X war offenbar die erste damit) konnten AMD-GPUs in solchen Tests regelmäßig über 90% der theoretischen Bandbreite nutzen. Das gilt sogar für Tahiti mit nur 32 ROPs an einem 384Bit-6GBps Interface (264GB/s von 288GB/s in Füllratentests von hardware.fr genutzt). Insofern sehe ich da überhaupt keine Probleme.

Die Füllratentests testen ja außer den ROPs selber hauptsächlich die Export-Bandbreite von den CUs und die Anbindung der spezialisierten ROP-Caches an die Speichercontroller (und natürlich den Speichercontroller selber, da offenbar vorher auf dem Weg nichts limitiert, zumindest mit Blending in einem 4xFP16 Framebuffer). Aber auch die L1<=>L2<=>Speichercontroller-Anbindung sollte ausreichen. Die internen Bandbreiten der Crossbars sind locker hoch genug dafür. Schon der uralte RV770 hatte 384GB/s Bandbreite zwischen den CUs/L1 und den L2-Tiles (an denen dann die Speichercontroller hängen). Und das hat seitdem noch etwas zugenommen (hauptsächlich durch breitere Speicherinterfaces, mehr L2-Tiles und höheren Takt, bei RV770 war es zugebenermaßen etwas Overkill). GCN hat allgemein eine Bandbreite von 64 Byte pro Takt pro L2-Tile (also pro 32Bit GDDR5-Interface), bei Hawaii sind das also 16*64=1024Byte pro Takt, also 1 TB/s bei 1GHz. Mit HBM wird man sehr wahrscheinlich jedem HBM-Channel ein L2-Tile verpassen (1HBM-Stack besitzt 8 Channels, wovon jeder logisch ziemlich gut einem 32Bit-GDDR5-Interface entspricht). Bei 4 HBM-Stacks erwarte ich also 32 L2-Tiles, was dann bei 1GHz 2 TB/s Bandbreite dahin ergibt (bei 800MHz entsprechend ~1,6TB/s).
Diese Crossbar zwischen den Caches ist schon ziemlich fett. Fiji mit 64CUs hätte ja auf einer Seite 96 Clients (64 vL1-D$, 16 sL1-D$, 16 I$) und auf der anderen Seite eben die 32 L2-Tiles. Jeder Client ist dabei mit 512Bit (64Byte/Takt) angebunden. Das sind schon eine Menge Datenleitungen. :freak:

[Skysnake]

Kernel starten dürfte doch im µs-Bereich sein. War deine Domain sehr klein?

Mit temporal blocking kann man bei einem Jacobisolver mehrere Zeitschritte in einem Kernelcall machen. Ich weiß nicht wie sinnvoll das bei GPUs ist. Bei CPUs hat man deutlich mehr Cache pro lane und kann an größeren tiles arbeiten.
Meist haste halt nicht sooo viel zu berechnen pro Iteration. Da macht das schon einen nicht vernachlässigbaren Anteil an der Gesamtlaufzeit aus.

Du bist ja schnell bei zehntausenden/millionen iterationen.

Eher On-Topic: Spekuliert sind ja Speicherbandbreiten von 600Gb/s. Könnte das Memory subsystem von Hawaii soviel überhaupt auslasten? Ich errinnere mich dass z.B. eine K40 auf standard clocks (745 Mhz) selbst für stream workloads ihr Speicherinterface nicht voll auslasten kann, bzw. mit Boost Clocks (875 Mhz) noch mal eine gute Steigerung bei der Bandbreite hat. Oder dass z.B. beim Xeon Phi von 320 GB/s nur ca. 50% nutzbar sind.
Hä? Das wäre mir alles aber sehr neu. Die Speicherinterfaces sind an sich immer komplett ausreizbar. Die Bandbreiten sind ja auch verglichen mit den internen relativ gering.

[mksn7]

Meist haste halt nicht sooo viel zu berechnen pro Iteration. Da macht das schon einen nicht vernachlässigbaren Anteil an der Gesamtlaufzeit aus.

Du bist ja schnell bei zehntausenden/millionen iterationen.

Dann musst du die Wärme Gleichung halt in 3D lösen. Dann kommen schnell viele Gitterpunkte zusammen...



Nur mal so meine ganz naive Beispielrechnung für K40, korrigiert mich wenn das bei AMD/GCN fundamental anders ist als bei nvidia, aber damit kenn ich mich halt grad besser aus:

Ohne ILP mit 1 CL in flight pro Warp, bei 350 cycles latency für den DRAM:
15SM * 64warps * 128B / 350 cyc * 745 Mhz = 243 GB/s

Wenn ich mit den Daten irgendwas machen will, hab ich schnell weniger als eine cache line in flight. Der Standardtrick ist ja mit ILP die lines in flight zu erhöhen. Bei Kepler wären das pro SM ungefähr bis zu doppelt so viele, also ca. 480 GB/s. Der texture cache verträgt wohl noch deutlich mehr, damit würde man dann tatsächlich 1 TB/s erreichen. Das Memorysubsystem von Kepler würde also nur in Ausnahmefällen mit einem 1TB/s memory interface was anfangen können. Je nach Code kann die memory parallelität oft auch sehr schlecht sein. Ich arbeite derzeit an einem code mit cpu-freundlichen legacy memory layout, da komm ich nicht über 0.64 CL in flight, womit ich dann auch nur bei 175GB/s bin.

Ich seh nur ganz generell, dass in Zukunft noch mehr als heute schon Codes oft latency bound sein werden, wenn nicht die Architekturen irgendwas ändern.

Hawaii ist aktuell schon deutlich breiter und paralleler als Kepler, richtig? Das hilft natürlich schonmal.

[Skysnake]

Hä?

Was hat das jetzt bitte mit dem Kernelstart zu tun? Das ist ein ganz anderer Stiefel. Du spricht davon, das man die GPU ausgelastet bekommt, aber das ist eh eine Grundvorraussetzung.

Das Problem größer zu machen hilft da natürlich, aber ändert nichts an dem Problem, dass du sehr viele Iterationen im Normalfall hast. Wenn der Kernel insgesamt länger läuft, wird das Prozentual natürlich weniger, aber man hat dennoch X mal den Kernelstart, den man sich gerne auch noch sparen können würde ;)

[mksn7]

Ok, wenn du natürlich nur beispielsweise eine 500x500 Domain hast, dann bist du natürlich nur noch bei ca. 500*500*4B*2 / 250GB/s = 8 µs und damit in der gleichen Größenordnung wie ein Kernellaunch. GPUs sind halt schlecht fürs strong scaling. Vielleicht hilft da wirklich temporal blocking, Rechenleistung hat man ja tendenziell eher über.

Das Synchronisieren bei CPUs ist da aber auch schon in der gleichen Größenordnung.

[Hübie]

Diese Crossbar zwischen den Caches ist schon ziemlich fett. Fiji mit 64CUs hätte ja auf einer Seite 96 Clients (64 vL1-D$, 16 sL1-D$, 16 I$) und auf der anderen Seite eben die 32 L2-Tiles. Jeder Client ist dabei mit 512Bit (64Byte/Takt) angebunden. Das sind schon eine Menge Datenleitungen. :freak:

Was meinst du woher die Einsparungen bei nVidia kommen? :D Aber wo du es mal erwähnst. Mich würde echt mal ein Organigramm von Hawaii diesbezüglich interessieren. Glaube AMD GPUs haben doppelt soviel Caches wie nVidias Kepler und Maxwell-Generation. Also Anzahl der Stufen in der Hierarchie. Hat Hawaii noch einen GDS wie Tahiti? Weiß das aus dem Kopf gar nicht, da ich mich nie so wirklich mit deren Architektur beschäftigt habe.
Wie sieht es denn mit der Assoziation aus? Waren die nicht 2 way?

[del_4901]

Was hat das jetzt bitte mit dem Kernelstart zu tun? Das ist ein ganz anderer Stiefel. Du spricht davon, das man die GPU ausgelastet bekommt, aber das ist eh eine Grundvorraussetzung.
Der Kernel launch ist vernachlaessigbar klein. Was du misst da misst sind die Synchronization und alle Cache flushes. Zumal die Thread IDs geordnet rein kommen, wenn jeder Thread einen Atomic Counter schreibt koennen alle Threads am Start leicht rausfinden ob Sie warten muessen oder nicht. Stichwort: Thread/Wave reconfiguration. Wenn du dann immer noch nicht genug occupancy hast, dann ist einfach deine Problemgroesse zu klein.

[Skysnake]

Nur das Threads eben nicht warten können... Die Threads laufen ja einfach immer durch. Wie gesagt, mir geht es um sync über Workgroupe Grenzen hinweg. Innerhalb einer ist das natürlich absolut kein Ding.

@Kernelstart:
Mag sein, ist im Endeffekt aber auch egal, wie es sich genau aufteilt. Wenn man über einen Kernelstart syncen muss, verschleudert man viel mögliche Leistung.

Ok, wenn du natürlich nur beispielsweise eine 500x500 Domain hast, dann bist du natürlich nur noch bei ca. 500*500*4B*2 / 250GB/s = 8 µs und damit in der gleichen Größenordnung wie ein Kernellaunch. GPUs sind halt schlecht fürs strong scaling. Vielleicht hilft da wirklich temporal blocking, Rechenleistung hat man ja tendenziell eher über.

Das Synchronisieren bei CPUs ist da aber auch schon in der gleichen Größenordnung.
Nein, ich ging schon von einigen kxk aus. Also nicht sooo wenig. Natürlich kann man die Gridsize immer weiter hoch ziehen, was dann, wie ich ja oben schon gesagt habe, den Kernelstart immer unrelevanter macht. Man hat aber dennoch schnell eine Million iterationen und mehr. Da biste dann gleich mal bei Sekunden, die du einfach nur verschenkst. Klar, das ist bei groß genügenden Problemen am Ende immer vernachlässigbar, aber eben ziemlich unschön, weil man quasi ein höheres unteres limit hat für sinnvolle Probleme, was nicht rein von der simulierten Zeit abhängt. Das ist einfach verdammt unschön meiner Meinung nach. Totschlagen kann man natürlich wie fast immer jeder Problem. Das ist aber eben nicht gerade sexy.

[Gipsel]

Glaube AMD GPUs haben doppelt soviel Caches wie nVidias Kepler und Maxwell-Generation. Also Anzahl der Stufen in der Hierarchie.Das denke ich nicht. Beide haben 2 Stufen.
Hat Hawaii noch einen GDS wie Tahiti? Weiß das aus dem Kopf gar nicht, da ich mich nie so wirklich mit deren Architektur beschäftigt habe.Ja, ist immer noch da.
Wie sieht es denn mit der Assoziation aus? Waren die nicht 2 way?Der Caches? LDS oder GDS haben ja keine Cache-Struktur, da direkt adressiert. Die besitzen jeweils 32 Bänke (erlauben also bis zu 32 parallele Zugriffe), zumindest bei den größeren Modellen (bei Entry-Level wird da manchmal gespart).
Die vL1-Caches von GCN sind 64-way assoziativ (die VLIWs waren sogar noch voll assoziativ [was 128way war, in die 8 kB paßten ja nur jeweils 128 Cachelines rein]). L2 weiß ich gerade nicht, müßte ich nachsehen, ob das mal irgendwann erwähnt wurde.

[y33H@]

Hihi, jez kommt Sweclockers (http://www.computerbase.de/2015-02/fiji-einzig-neue-gpu-der-radeon-r9-300-serie/) um die Ecke, alles außer Fiji sind Rebrands ... wie bekannt (http://www.forum-3dcenter.org/vbulletin/showpost.php?p=10511294&postcount=2323) ;D

[Nakai]

Reinher von der Architektur ist GCN gleich GCN gleich GCN, sprich, das bisherige LineUp ist technologisch nicht wirklich veraltet. Deswegen ist Tonga so, wie der Chip eben aussieht -> Tahiti + neuem Featureset. Trinidad könnte ein Pitcairn mit neuem Featureset sein. Hawaii braucht noch kein neues Featureset, Bonaire ebenfalls. Einzig im LowEnd bräuchte es eine neue bessere GPU. Capeverde wird noch hergestellt, vor allem auch als Embedded GPU(oder man räumt die Lager). Bonaire könnte Ersatz für Capeverde in längerer Sicht sein. Also braucht es eine GPU unterhalb Bonaire.

€: Ich habe mir Gedanken gemacht, wie das Layout der HBM-Stacks mit Fiji und dem Kalahari-Interposer-System kollidiert.

http://www.3dincites.com/wp-content/uploads/kahlahari.png

Ein HBM Stack benötigt 9x9mm2, weswegen an einer Seite nicht alle HBM Stacks platziert werden können. Der Kalahari Interposer ist 26x32mm² groß, sind nun jeweils an gegenüberliegende Seiten zwei HBM Stacks platziert(Milchmädchen), dann bleiben 8x32mm² oder 26x14mm² übrig, beides weit entfernt von ~500mm².

Entweder wird ein größerer Interposer genommen(32x32mm²) oder die Stacks sind doch noch etwas kleiner. Quadratische HBM Stacks hat man noch nie gesehen, diese sind eher rechteckig. Die genaue Größe habe ich noch nicht gefunden, aber umso schmäler die Stacks sind, desto größer darf Fiji sein.^^

[reaperrr]

Also braucht es eine GPU unterhalb Bonaire.
Gibt doch schon Iceland, ist nur im Desktop-Bereich noch nicht angekommen.

[Locuza]

Wo gibt es überhaupt Iceland?

[Gipsel]

€: Ich habe mir Gedanken gemacht, wie das Layout der HBM-Stacks mit Fiji und dem Kalahari-Interposer-System kollidiert.

http://www.3dincites.com/wp-content/uploads/kahlahari.png

Ein HBM Stack benötigt 9x9mm2, weswegen an einer Seite nicht alle HBM Stacks platziert werden können. Der Kalahari Interposer ist 26x32mm² groß, sind nun jeweils an gegenüberliegende Seiten zwei HBM Stacks platziert(Milchmädchen), dann bleiben 8x32mm² oder 26x14mm² übrig, beides weit entfernt von ~500mm².

Entweder wird ein größerer Interposer genommen(32x32mm²) oder die Stacks sind doch noch etwas kleiner. Quadratische HBM Stacks hat man noch nie gesehen, diese sind eher rechteckig. Die genaue Größe habe ich noch nicht gefunden, aber umso schmäler die Stacks sind, desto größer darf Fiji sein.^^Die Maße für die HBM-Stacks stimmen so nicht, das sind hauptsächlich Testmuster, mit denen das Packaging getestet wird.
Die 1GB-HBM-Stacks von Hynix messen 5,48 x 7,29 = 40mm² (http://www.hotchips.org/wp-content/uploads/hc_archives/hc26/HC26-11-day1-epub/HC26.11-3-Technology-epub/HC26.11.310-HBM-Bandwidth-Kim-Hynix-Hot%20Chips%20HBM%202014%20v7.pdf) (bereits inclusive sidemold rundherum, die Dies selber sind noch etwas kleiner: nominell 5,1 x 6,91 mm²). Inklusive der möglichen Toleranzen veranschlagt Hynix ~42mm² Flächenbedarf für so einen HBM-Stack. Die 2GB- bzw. 4 GB-Stacks könnten etwas größer sein (vermutlich wird man lieber erst auf 4Hi-Stacks mit 4 Gbit pro Die gehen, bevor man 8 davon stapelt), aber weniger als doppelt so groß (die für die TSVs benötigte Fläche ändert sich ja praktisch nicht). Außerdem dürften Dies mit größeren Speicherdichten auch mit kleineren Strukturen gefertigt werden (sie also wenig bis gar nicht größer werden, wenn die Speichermenge pro Die nur verdoppelt wird [2GBit=>4GBit]).

[Nakai]

@Gipsel:
Ah danke. ;)

Bei so kleinen Stacks gibt es doch die Möglichkeit 4 Stacks auf eine Seite zu quetschen. Baut man die HBMs an die kurze Seite(26mm; hochkant), hat man noch ~26x24,5mm²=637mm² platz. Tut man dies an der langen Seite, sind noch ~20,5x32mm²= 656mm² frei.

Natürlich wird noch ein haufen Verschnitt notwendig sein.

[Gipsel]

@Gipsel:
Ah danke. ;)

Bei so kleinen Stacks gibt es doch die Möglichkeit 4 Stacks auf eine Seite zu quetschen. Baut man die HBMs an die kurze Seite(26mm; hochkant), hat man noch ~26x24,5mm²=637mm² platz. Tut man dies an der langen Seite, sind noch ~20,5x32mm²= 656mm² frei.

Natürlich wird noch ein haufen Verschnitt notwendig sein.
Das ist ein wenig optimistisch. Hier hatte ich schon mal meine Vermutung geschildert (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=10453548#post10453548). Die Stacks auf beide Seiten zu verteilen, ist wegen der kürzeren Signallaufwege besser (kostet aber natürlich auch etwas mehr Platz).
Wenn man vier Stacks auf eine Seite packt, dann vermutlich auf die längere (und das eventuell trotzdem auch noch hochkant, quer würde verdammt eng). Dann müßte der GPU-Die relativ rechteckig werden, da man dann nur noch ~18 x 32 = 576mm² übrig hat (die man nicht komplett mit dem GPU-Die belegen wird). Also best case ist vielleicht, daß man an einer kurzen Seite 4 Stacks hochkant nebeneinander packt. Dann bleiben ~26 x 24 = 624mm² vom Interposer übrig (ich vermute, man wird die einzelnen Teile nicht zu dicht zusammenpacken; 0,5 bis 1mm Platz wird man da schon immer frei lassen).

[Nakai]

Das ist ein wenig optimistisch. Hier hatte ich schon mal meine Vermutung geschildert (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=10453548#post10453548). Die Stacks auf beide Seiten zu verteilen, ist wegen der kürzeren Signallaufwege besser (kostet aber natürlich auch etwas mehr Platz).
Wenn man vier Stacks auf eine Seite packt, dann vermutlich auf die längere (und das eventuell trotzdem auch noch hochkant, quer würde verdammt eng). Dann müßte der GPU-Die relativ rechteckig werden, da man dann nur noch ~18 x 32 = 576mm² übrig hat (die man nicht komplett mit dem GPU-Die belegen wird). Also best case ist vielleicht, daß man an einer kurzen Seite 4 Stacks hochkant nebeneinander packt. Dann bleiben ~26 x 24 = 624mm² vom Interposer übrig (ich vermute, man wird die einzelnen Teile nicht zu dicht zusammenpacken; 0,5 bis 1mm Platz wird man da schon immer frei lassen).

Wenn man sich AMDs Dieshots anguckt, ist das Backend meist um die CUs rumgesetzt. Da würde schon ein Aufbau gemäß Stacks auf beiden Seiten besser sein, aber das hängt vom generellen Chip-Layout und Platzierung der PHYs ab.

Mir ist schon bewusst, dass da viel Redundanz hinzukommt. Generell sollte aber auf dem Kalahari Interposer noch genug Platz für 4 Stacks und einen großen Die(500~550mm²) Platz sein. Mehr als 550mm² für Fiji erwarte ich jetzt nicht. Die PHYs für die Stacks sollte schon ziemlich klein sein, was nicht heißt, dass sie nicht einiges an Platz an der Seite benötigen.

Die 2GB- bzw. 4 GB-Stacks könnten etwas größer sein (vermutlich wird man lieber erst auf 4Hi-Stacks mit 4 Gbit pro Die gehen, bevor man 8 davon stapelt), aber weniger als doppelt so groß (die für die TSVs benötigte Fläche ändert sich ja praktisch nicht). Außerdem dürften Dies mit größeren Speicherdichten auch mit kleineren Strukturen gefertigt werden (sie also wenig bis gar nicht größer werden, wenn die Speichermenge pro Die nur verdoppelt wird [2GBit=>4GBit]).

Auf der Hynix-Seite wird schon eine Schema eines HBM-Stacks mit 4Hi 4Gb Slices dargestellt. Es sieht schon aus, als wären für Gen sogar 4Gb HBM Slices "geplant". Fiji sollte schon irgendwann 8GB Speichervolumen anbieten. Die Frage ist eher, wann dies passiert. Der nächste Schritt wäre bereits 8Gb Slices, welche für HBM Gen2 anstehen(32GB für 8Hi-Stacks; 2xBandbreite).

Fiji kommt aber erst mit 4GB Speichergröße und dann evtl, wenn Hynix so gnädig ist, auch 8GB Speichergröße. Derzeit steht hierbei noch nix fest und man findet hierzu sehr wenig Informationen.

€: Die Größe eines HBM-PHYs(8*128Bit) würde ich auf unter 20mm² schätzen, wurde immer angemerkt, dass HBM kleinere PHYs benötigt. Zur Info ein 128Bit GDDR5-PHY auf Pitcairn/Hawaii ist etwa 10mm² groß. Reinher von der Bandbreite kann man die Bandbreite eines HBM-Stacks gut mit einem 128Bit GDDR5 Interface vergleichen. Dieser bietet 4*32Bit MCs. Ein HBM-Stack hat 8 Channels, welche unabhängig voneinander sind und gut mit einem 32Bit GDDR5-Channel verglichen werden kann. Dadurch wird im Grunde das Backend schon mal verdoppelt, um die Anzahl der Channels gut ansprechen zu können. Zwei 128Bit Channels pro Controller wäre unorthodox und schon gegen das Ziel von HBM jeden Channel individuell anzusprechen. Kurz, wie schon von anderen hier angemerkt, braucht man 32 MemoryController, um 32 x128Bit HBM Channels anzusprechen. Ich weiß nicht genau, wie hoch die ROP-Bandbreite nun ist, damit das augeglichen sein wird, aber pro ROP kann man 4 Pixel schreiben und pro Pixel, je nach Datenformat, sollten schon 32Bit benötigt werden, was wieder bei 128Bit endet, was gut zum Aufbau passt. 32 RBEs sind auch daher nochmal gesichert. Das hatten wir zwar alles schon, klingt aber schonmal ziemlich "fett", wo NV nur mit 96ROPs und 384Bit SI kommt. Wenn AMDs Frontend auf 8fach hochgejagt wird, mit verbessertem Tonga-Frontend, ergibt sich schon eine nicht schwache Konstellation. Pro ShaderEngine sind 4 RBEs, 2x4CUs plus ein stärkeres Frontend verbaut. Wird DCC noch integriert, hat AMD für Spiele eine effektive Bandbreite jenseits von Gut und Böse.

Auch reinher vom Aufbau, ist Fiji teilweise ein doppelter Hawaii. Also 50% auf Hawaii halte ich bei gleichem Takt für gut möglich.

[fondness]

Der Typ von Stardocks hat wohl schon einen Fiji:

https://twitter.com/draginol/status/567428591630426112

Weiter unten spricht er von einem Crossfire-System.

https://twitter.com/draginol/status/567433895604654081

[Gipsel]

€: Die Größe eines HBM-PHYs(8*128Bit) würde ich auf unter 20mm² schätzen, wurde immer angemerkt, dass HBM kleinere PHYs benötigt. Zur Info ein 128Bit GDDR5-PHY auf Pitcairn/Hawaii ist etwa 10mm² groß.Das ist ganz sicher so, denn die Ballouts von HBM sind ja spezifiziert, man kennt also die Abmessungen davon (und die Region ist größer als die PHYs selber). Laut dem bereits verlinkten Hynix-pdf (irgendwann hatte ich das auch mal anhand der HBM-Spec ausgerechnet, aber so ist das bequemer), mißt die Ballout-Area eines HBM-Stacks 6,05 x 3,264 = 19,75mm². Und das beinhaltet auch Stromversorgung und Sonstiges (was man am Speicherinterface der GPU nicht benötigt). Weiterhin hat Hynix da netterweise bestimmte Bereiche des Base-Dies markiert, woraus man ablesen kann, daß die eigentlichen PHYs nur etwa 40% der Ballout-Area einnehmen. Das wären dann so etwa 8mm².

[Hübie]

Das denke ich nicht. Beide haben 2 Stufen. Der Satz sollte "Also Anzahl in den Stufen der Hierarchie." lauten :redface:

Der Caches?
Ja meinte LDS/GDS. Wusste gar nicht dass die nicht so strukturiert sind. Danke für die Erklärung.

[Nakai]

Das ist ganz sicher so, denn die Ballouts von HBM sind ja spezifiziert, man kennt also die Abmessungen davon (und die Region ist größer als die PHYs selber). Laut dem bereits verlinkten Hynix-pdf (irgendwann hatte ich das auch mal anhand der HBM-Spec ausgerechnet, aber so ist das bequemer), mißt die Ballout-Area eines HBM-Stacks 6,05 x 3,264 = 19,75mm². Und das beinhaltet auch Stromversorgung und Sonstiges (was man am Speicherinterface der GPU nicht benötigt). Weiterhin hat Hynix da netterweise bestimmte Bereiche des Base-Dies markiert, woraus man ablesen kann, daß die eigentlichen PHYs nur etwa 40% der Ballout-Area einnehmen. Das wären dann so etwa 8mm².

Mhh, 8mm² klingt gut. Jedenfalls ist das gegenüber Hawaii kein sonderlicher Flächengewinn. Immerhin ist die Bandbreite pro Fläche ist dadurch mal locker verdoppelt worden. Wenn es ein GF-Prozess ist, was derzeit stark vermutet wird, sind Die-Size-Spekulationen anhand Hawaii für Fiji eh hinfällig. GateFirst sollte 10~20% dichtere Packdichte ermöglichen. Selbst Tonga der noch im TSMC-Prozess gefertigt wird, ist für eine Extrapolation nicht zu gebrauchen. Es gibt keinerlei Dieshots und 700 Mio Transistoren für DCC, besserem Frontend und HSA-Support halte ich für vollkommen überdimensioniert. Anscheinend sind auch die CUs von Tonga stark im DP-Support beschnitten, ähnlich Pitcairn.

Jetzt müsste SKHynix nur noch Slices mit 4Gb liefern und Fiji wäre ziemlich gut zu gebrauchen.

Monolog Ende.

[HOT]

Man könnte Tonga einfach bei beiden Foundries aufgelegt haben.

[Nakai]

Man könnte Tonga einfach bei beiden Foundries aufgelegt haben.

Ja, aber GF hat GateFirst, da ist der gesamte Stack genau andersrum und es würde einiges an Geld kosten. Dadurch erreicht man eine höhere Packdichte, in der Theorie, aber TSMC und GF wären hierbei ziemlich inkompatibel.

[fondness]

Tonga kommt laut AMD nicht von GF sondern von TSMC. Wäre der GF-Prozess besser geeignet für GPUs hätte AMD den sicher nicht bei TSMC hergestellt. Damit kommt die Folgefrage warum sollte sich das bei Fiji ändern, so ganz ohne Testlauf eine >500mm² GPU bei GF? Halte ich für sehr unwahrscheinlich. Klar AMD hat mehrmals gesagt das sie GPUs bei GF fertigen, aber das ist wohl nur Kleinkram, ansonsten hätte man doch spätestens bei Tonga umsteigen können/müssen. Auch die Folie weiter hinten spricht klar von TSMC mit einem >500mm² Chip, AMD ist der einzige infrage kommende Kunde soweit ich das verfolgt habe.

[HOT]

So einfach ist das nicht. Man bedenke die Tatsache, dass AMD bei GloFo Mindestmengen abnehmen muss und bei TSMC nicht.
Meine Theorie ist eher, dass man Tonga quasi als Testchip für GloFo mitgebaut hat, also, dass Tonga auch bei GloFo in seiner Form existiert, einfach um ein praktisches Produkt zu haben. Wie sich das mit weiteren Grafikchips verhält wird sich zeigen.
Meiner Ansicht nach ist auch Tinidad kein einfacher Rename. Ich wette, dass Trinidad die verbesserte Framebufferkompression hat und nur noch 128Bit Speicherinterface bietet.

[Duplex]

Werden die Konsolenchips inzwischen nicht auch von beiden Foundrys hergestellt ?

[HOT]

Ab 20nm wird die XBox APU offenbar nur noch bei GloFo gefertigt, ich denk mal im gleichen Prozess wie Nolan/Amur. Für die PS4 ist nichts bekannt.

[Duplex]

Und warum nicht auch in 16nm TSMC oder 14nm Samsung ?

[HOT]

FinFETs werden dafür einfach zu teuer sein. Das sind ja große Chips und der TSMC 20nm-Prozess war offenbar Kosten/Nutzentechnisch zu schlecht. Zu Samsung hat AMD AFAIK gar keine Fertigungskontakte. Ich geh davon aus, dass GloFo Dresden sowohl an einem 20nm-Prozess als auch einem eigenen 14nm Prozess arbeitet. Dass 14XM gecancelt wurde heißt ja nicht, dass man nicht weiterentwickelt.

[Duplex]

Es sind doch aber Custom Chips für Sony & MS, ist doch egal was die kosten, Globalfoundries macht leider nur noch scheiss Prozesse.
Im GPU Markt wird AMD 2016 garantiert auf 16nm TSMC setzen, also die R400 Serie kommt in 16nm, sowie alle anderen GPUs von TSMC kommen.

[HOT]

Blödsinn. GloFo baut Prozesse wie jede andere Foundry auch. Sony und M$ bestimmen nicht den Fertigungsort, AMD verkauft die Chips für einen bestimmten Preis und lässt fertigen, Sony und M$ bezahlen dafür.
AMD fertigt derzeit an 2 Orten, bei TSMC und GloFo Dresden. Da haben die auch Leute und da werden auch künftige Produkte herkommen. Ich glaube nicht, dass AMD irgendwas in Samsungs Prozessen fertigen wird.
Und TSMC hat das Problem, dass 16nm immer weiter verzögert werden und überhaupt nicht in Fahrt kommen.

[R.I.P.]

Blödsinn. GloFo baut Prozesse wie jede andere Foundry auch. Sony und M$ bestimmen nicht den Fertigungsort, AMD verkauft die Chips für einen bestimmten Preis und lässt fertigen, Sony und M$ bezahlen dafür.
AMD fertigt derzeit an 2 Orten, bei TSMC und GloFo Dresden. Da haben die auch Leute und da werden auch künftige Produkte herkommen. Ich glaube nicht, dass AMD irgendwas in Samsungs Prozessen fertigen wird.
Und TSMC hat das Problem, dass 16nm immer weiter verzögert werden und überhaupt nicht in Fahrt kommen.

Hmm, ich glaube eher dass Amd die volle Palette con GloFo ikl. Samsungs 14nm Prozess ausnutzen wird und von Tsmc Abstand nehmen wird.

[Hübie]

Soweit mir bekannt ist macht auch Elpida gestapelte DRAMs. Also muss es ja nicht unbedingt Hynix sein ;)
Was mir eben mal durch den Kopf ging: Wie stehts denn da um yields? Jetzt hat man ja wieder eine potenzielle Fehlerquelle mehr. Ich weiß zwar dass man debonden kann, aber das ist A) teuer und B) aufwändig. Da weiß ich gar nicht ob sich das lohnt. AMD scheint ein recht großes, finanzielles Risiko über einen kurzen Zeitintervall einzugehen. Operativ dürfte sich das negativ auswirken. Ich hoffe die setzen aufs richtige Pferd.
@Gipsel: Wie hast du dir das eigentlich ausgerechnet? So ein µ-Bump hat 0,01-0,05mm als Größenangabe. Oder verwechsel ich da was? :|

Edit: Okay ich schau mir gerade das paper an und sehe da die Maße ;D

[Nakai]

Soweit mir bekannt ist macht auch Elpida gestapelte DRAMs. Also muss es ja nicht unbedingt Hynix sein ;)
Was mir eben mal durch den Kopf ging: Wie stehts denn da um yields? Jetzt hat man ja wieder eine potenzielle Fehlerquelle mehr. Ich weiß zwar dass man debonden kann, aber das ist A) teuer und B) aufwändig. Da weiß ich gar nicht ob sich das lohnt. AMD scheint ein recht großes, finanzielles Risiko über einen kurzen Zeitintervall einzugehen. Operativ dürfte sich das negativ auswirken. Ich hoffe die setzen aufs richtige Pferd.
@Gipsel: Wie hast du dir das eigentlich ausgerechnet? So ein µ-Bump hat 0,01-0,05mm als Größenangabe. Oder verwechsel ich da was? :|

Edit: Okay ich schau mir gerade das paper an und sehe da die Maße ;D
Elpida == Micron(mittlerweile) == HMC != HBM

[Unicous]

Nur mal so zur Info: Auch Samsung will HBM herstellen (bzw. hätte/könnte/ müsste schon mit der Produktion begonnen haben).


edit:
Oh, da gibt es sogar ein jüngere Stellungnahme von Samsung bzw. Farhad Tabrizi (Senior Vice President, Strategic Memory Planning Samsung Semiconductor) von der MemCon 2014

Tabrizi showed a picture of a micropillar grid array (MPGA) HBM solution developed by Samsung. There are no pins coming out of the package – the connection to the PCB is done with micro-bumps. Tabrizi announced that “we are ready to begin HBM manufacturing” and said that the ecosystem is in place to begin production. “I want you guys to think about real-time analytics and how you can use this package and this device,” he said.

http://community.cadence.com/cadence_blogs_8/b/ii/archive/2014/10/27/memcon-2014-samsung-keynote-ddr4-tsvs-and-high-bandwidth-memory-hmb-will-transform-drams

[Hübie]

Oh, ach so.

Zum obigen Gedanken ergänzend: natürlich auch deshalb Risiko weil HBM afaik noch keine Fehlerkorrektur "beherrscht" und man somit für einen Markt nicht sonderlich attraktiv sein wird.

[Sunrise]

AMD scheint ein recht großes, finanzielles Risiko über einen kurzen Zeitintervall einzugehen.
Um die 300er Serie zu verkaufen braucht man ein neues Zugpferd. R300 war damals auch recht komplex, wurde relativ günstig verkauft und war finanziell nicht unbedingt der Margenhit. Das reichte aber völlig aus um sich ins Spiel zu bringen und mehrere Generationen abzusetzen.

[Hübie]

Damals war die Ausgangslage nur etwas besser als heute, weißt was ich mein? Ich will einfach nicht das die sich überheben und dann das Kreuz brechen. Lisa fährt imo eine riskante Strategie. Ob die aufgeht werden wir sehen.

Ich persönlich habe Fiji wie gesagt auf dem Wunschzettel. 300 Watt hin oder her -> die Leistung muss stimmen und es muss leise kühlbar sein. Der Rest ist mir Wurscht.

[Sunrise]

Damals war die Ausgangslage nur etwas besser als heute, weißt was ich mein? Ich will einfach nicht das die sich überheben und dann das Kreuz brechen. Lisa fährt imo eine riskante Strategie. Ob die aufgeht werden wir sehen.

Ich persönlich habe Fiji wie gesagt auf dem Wunschzettel. 300 Watt hin oder her -> die Leistung muss stimmen und es muss leise kühlbar sein. Der Rest ist mir Wurscht.
Das Risiko sehe ich begrenzt, weil ich nicht (z.B. im Gegensatz zu HOT) davon ausgehe, dass AMD jetzt durchdreht und x-fach verschiedene neue Produkte vorstellen wird. Sie brauchen nur wieder ein funktionierendes Lineup von "Top to bottom".

Fiji ist auf 28nm und erbt wohl größtenteils von Tonga IP. Das ist also sowieso schon fertig entwickelt und dann sollte man versuchen hier noch das Maximum rauszuholen.

Die richtig schlagkräftigen HBM-Designs kommen sowieso erst mit Pascal bzw. der 400er Serie.

[Hübie]

Ich kenne aber Zahlen und die sagen was anderes ;D

[M4xw0lf]

Ich kenne aber Zahlen und die sagen was anderes ;D
Moar! :uconf3:

[Sunrise]

Ich kenne aber Zahlen und die sagen was anderes ;D
http://www.pamsf.info/images/smilies/e045.gif

[Hübie]

Ich versteh eure beiden Posts nicht :redface:

[M4xw0lf]

Du erwecktest den Anschein von Insiderinformation, du Schuft. :usad:

[Hübie]

Ach so. Hehe. Nein, ich meinte Produktions- und Anschaffungskosten, nicht was AMD anbelangt. :smile: Was AMD denen zahlt kann ich daraus nur so pi mal Daumen erraten.

[robbitop]

Zu Samsung hat AMD AFAIK gar keine Fertigungskontakte. Ich geh davon aus, dass GloFo Dresden sowohl an einem 20nm-Prozess als auch einem eigenen 14nm Prozess arbeitet. Dass 14XM gecancelt wurde heißt ja nicht, dass man nicht weiterentwickelt.
GloFo ist doch in der Fertigungsalianz mit Samsung und darf den 14 nm FinFet Prozess benutzen. Wozu noch was eigenes entwickeln?

[HOT]

Allein um am Ball zu bleiben? Außerdem hat GloFo doch nur 2 FinFET-Prozesse lizenziert, was für ne Fertigungsallianz?

[M4xw0lf]

Allein um am Ball zu bleiben? Außerdem hat GloFo doch nur 2 FinFET-Prozesse lizenziert, was für ne Fertigungsallianz?
U srs? http://www.commonplatform.com/
Und IBM ist jetzt raus aus dem ganzen Fertigungsgeschäft, GloFo und Samsung machen weiter.

[Thunder99]

Defakto fährt AMD schon mega Sparflamme in dem sie nur eine GPU einer neuen Serie entwickeln anstatt die ganze Palette von low end bis high end. Ob das gut geht, auch wegen den OEM Interessen, wird sich zeigen müssen. Feature mäßig waren sie immer vorne mit dabei nur da driften sie gerade ab (HDMI 2.0 + den ganzen Schnickschnak) :(

[Unicous]

IBM ist nicht "raus". Ihre Entwicklungsabteilung haben sie weiterhin.

[HOT]

U srs? http://www.commonplatform.com/
Und IBM ist jetzt raus aus dem ganzen Fertigungsgeschäft, GloFo und Samsung machen weiter.
Das war mir entgangen. Aber ich denke trotzdem, dass man das unabhängig von der Lizenzierung der beiden Prozesse sehen muss. Kooperation heißt ja nur, dass man bei FinFETs zusammenarbeitet, da können trotzdem 3 unterschiedliche Prozesse bei rauskommen. Es ist eben nicht so klar, dass jetzt alle Samsung machen.
Ok sagen wir zwei Prozesse, jetzt wo GloFo East Fishkill gehört, wird man die Entwicklung dort mit der in Dresden "wieder" zusammenlegen (da gab es ja seit 2002 schon enge Kooperationen).
MaltaNY -> Samsung 14nm und GloFo 28nm(LP)
EastFishkill NY -> IBM/GloFo 14nm und IBM 22nm
Dresden -> IBM/GloFo 14nm und GloFo 20/28nm
Singapur -> >28nm

[Skysnake]

Samsung und GloFo wollen multi Fab-Supply ihren Kunden anbieten. Also wird es der gleiche Prozess sein. Ob es zusätzlich noch weitere Eigenentwicklungen gibt, ist ne andere Frage, aber das 0815-Sach ist bei beiden identisch.

[Sunrise]

Das war mir entgangen. Aber ich denke trotzdem, dass man das unabhängig von der Lizenzierung der beiden Prozesse sehen muss. Kooperation heißt ja nur, dass man bei FinFETs zusammenarbeitet, da können trotzdem 3 unterschiedliche Prozesse bei rauskommen. Es ist eben nicht so klar, dass jetzt alle Samsung machen.
Der Sinn dahinter ist doch gerade der, dass GloFo und Samsung theoretisch die Produktion hin und herschieben könnten (z.B. bei Kapazitätsengpässen) und damit auch die jeweils eigenen Fabs möglichst gut auslasten können, was bedingt, dass verwendete Materialien, Prozess Know-How und Tools möglichst identisch sind.

Was GloFo und Samsung da bisher für eigene Süppchen gekocht haben (20nm) ist doch erstmal egal, es geht um die Zukunft.

Und du kannst dir sicher sein, dass die Nachfrage bei Samsung (allein durch SoCs) explodieren wird, wenn Samsung in diesem Tempo weitermachen kann. Was man auch daran erkennen kann, dass Samsung eine Multi-Milliarden-FAB zusätzlich baut, weil man da jetzt schon in Kapazitätsprobleme laufen wird.

Und diese Allianz generell ist für beide Seiten ein gigantischer Gewinn, vor allem kann GloFo endlich mal wieder vorne mitspielen und das sollte auch Investitionen ankurbeln (was glaube ich vor kurzem auch durch die Presse ging).

Daher wurde ja u.a. von mir spekuliert, dass AMD mit der 400er Serie direkt auf 14nm geht, während man bei NV wohl erstmal nur Interesse für SoCs (ab Parker) angemeldet hat. Allerdings bin ich da noch vorsichtig, da man aktuell nichts von Prozessen weiß, außer denen, die für SoCs gedacht sind und wie gesagt schon jetzt eigentlich zuwenig Kapazität für alle da ist.

TSMC wird irgendwann auch am Preis drehen müssen, wenn es weiter so läuft, ansonsten hat man da schweineteure Fabs ausgebaut, die nicht ausgelastet werden.

Das ist im Endeffekt ein Gewinn für alle, weil da endlich mal wieder etwas mehr Konkurrenz reinkommt. TSMC hatte damals die anderen (die noch bei 180 bzw. 150nm im Rennen waren, wie UMC etc.) ja längst abgehängt.

[aufkrawall]

Wie wahrscheinlich sind Preissenkungen für Hawaii in nächster Zeit?
Der Preis war zuletzt gestiegen.

[Ravenhearth]

Mein Würfel sagt 1:5. :D Ganz ehrlich: Das kann dir niemand beantworten. Kurzfristig dürfte der Preis jedoch eher ein wenig steigen. Davon abgesehen gehört das nicht hierhin.

[Hübie]

Also wenn ich so an Tahiti denke... 7970<->280. Da gab's zeitweise eine Tahiti für 180 während Tahiti 2.0 über 200€ lag. Also das Hawaii fällt is wahrscheinlich aber wohl nicht unter 250 für Hawaii XT.

[fondness]

Die Preissteigerungen liegen am EUR-Kurs. Ansonsten bleibt Hawaii der zweitschnellste AMD-Chip, der wohl rebrandet wird, ob der Preis nochmal spürbar sinkt nachdem NV GM204 schon am Markt hat kann durchaus bezweifelt werden.

[Nakai]

Eventuell geht AMD zu GF für Tonga und Hawaii, aber mal gucken.

[Dawn on Titan]

Ich fände Rebrands ziemlich schlimm. Die FPS/W Leistung der "alten" Chips sieht gegen Maxwell sehr schwach aus und wenn ich vorstelle eine Karte mit einem Ladenpreis von weniger als 200 Euro mit Hawaii bauen zu müssen, dann gute Nacht. Die Stromversorgung, die Platine und der Kühler sind für die Preisklasse eigentlich viel zu aufwendig.

[Agent117]

Komplett ausschließen kann man das nicht aber solch eine Neuportierung kostet schon einiges, man sagt so 10 bis 15 Millionen. Bei 2 Chips wären das dann schon 20 bis 30 Millionen, das lohnt sich vermutlich nicht.

Ich würde eher einen niedriger getakteten hawaii so ca. 925 mhz vermuten mit ner leistungaufnahme von ca 190 watt.

[Dural]

also ich kann mir beim besten willen nicht vorstellen das AMD so blöd ist und ein 450mm2 Chip mit 512Bit SI noch mal neu im 250-300.- Markt bringt.

Keine Entwicklungskosten, aber auch fast kein Gewinn, obwohl das ist bei AMD ja üblich :freak: die werden dafür den Tonga XTX nehmen, ziemlich sicher.

[aufkrawall]

Tonga XT als Hawaii-Ersatz? Der Pro kann gerade so mit einer 960 mithalten...

[horn 12]

Tonga XT mit 1100+ Mhz sollte knapp wie eine R9 290 abgehen können.
Dafür könnte man die R9 290 dann in Rente schicken.

[aufkrawall]

Wenn da mal der avg-Verbrauch nicht über Hawaii Pro wäre.

[Datarecovery09]

Hallo 3dCenter-Forum,

bezüglich dieser Sache hätte ich mal eine Frage, von der ich hoffe, dass die Experten hier sie mir beantworten können.
Ich bin gerade ein wenig am rätseln, woher der geringe Durchschnittsverbrauch der Maxwell-Karten eigentlich kommt. Die Artikel von Tomshardware legen jedenfalls ja nahe, dass Nvidia die auch und vor allem über ein extrem schnelles und fein abgestuftes Umschalten der GPU-Spannung erreicht. Einerseits mit der Folge, dass man so im Mittel erheblich weniger Strom für nichts verbrät, andererseits mit der Eigenheit, immer wieder plötzliche Lastspitzen zu erzeugen.

Dabei fällt gleichsam auf, dass die Verbrauchswerte der jeweiligen Karten unter vollständiger Auslastung (z. B. GPGPU) erheblich kleinere Differenzen in der Effizienz offenbaren als die Messungen unter Gaminglast - klingt für mich auch logisch, da bei dauerhafter Volllast nichts mehr hoch- und runtergeregelt werden kann.


Meine Frage ist jetzt: Welche Rolle spielen Architektur und Chipdesign eigentlich noch in dieser Sache? Könnte man als, beispielsweise, AMD nicht einfach einen bestehenden Grafikchip nehmen und die Spannungsversorgung so um-designen, dass sie ebenfalls so aggressiv schaltet? Bzw.: Was hindert AMD daran, exakt das zu tun, bspw. im Zuge eines Rebrands von Hawaii und Tonga in die R300-Reihe? Die verwendeten Herstellungsprozesse müssten ja die gleichen sein, oder habe ich da etwas falsch verstanden?


Vielen Dank schon einmal im Voraus! :-)

[aufkrawall]

Nicht der ganz passende Thread.

Mit Maxwell hat NV es geschafft, viel mehr von der Netto-Rechenleistung abrufbar zu machen.
Entsprechend ist die Effizienz gerade in Compute-Anwendungen gegenüber Kepler extrem gestiegen und den deutlichsten Anstieg bei Spielen gibt es offenbar auch in stark ALU limitierten Szenarieren (Trine 2 oder Anno 2070, wohl auch AC: U).

[Unicous]

Leider, leider ist Nvidia dahingehend sehr verschlossen. Das einzige was man zu hören bekommt ist: Wir haben die Energieeffizienz von Version 1.0 auf 2.0 gesteigert.

AMD hatte letztes Jahr schon bei den APUs Kaveri und Carrizo Effizienzsteigerungen in Aussicht gestellt. Viele dieser Verbesserungen kommen auch direkt der Grafikeinheit zu Gute und können auch auf eine diskrete GPU angewandt werden.

http://images.anandtech.com/doci/8742/Carrizo%20Efficiency.png

Besonders hervorzuheben sind hier (Voltage) Adapative Clocking, eine Technik die plötzlich auftretende Spannungsveränderungen, insbesondere Spannungsabfälle, erkennen und kompensieren kann und schnell die Frequenz anpasst, sonst würde es nämlich zu kurzen "Ausfällen" bzw. Fehlern kommen und zum Überkompensieren, also kurzzeitig mehr Spannung als nötig anliegt.

Komplementär gibt es dazu das Adaptive Voltage and Frequency Scaling (AVFS), das schon von vielen Firmen (vllt. auch Nvidia?) eingesetzt wird und eine noch feinere Anwendung des Dynamic Voltage and Frequency Scaling (DFVS) ist, das aber eigentlich eher einer Stromsparfunktion bzw. Throttling gleichkommt.

Beim AVFS versucht man abhängig von der Auslastung (workload) die Spannung und Taktfrequenz anzupassen und auch hier muss man Veränderungen genau kontrollieren und darauf schnellstmöglich reagieren.

Beide Verfahren gehen mE Hand in Hand.

Solche und ähnliche Techniken könnte Nvidia bereits implementiert haben um deutlich spezifischer auf verschieden Auslastungsszenarien reagieren zu können. Sagen tut Nvidia es meist nicht.

[y33H@]

VAO als Option dem Vdrop zu begegnen ist spannend und sollte in Steamroller schon drin sein, nun in der Carrizo-GPU und vll auch schon in Fiji. Ansonsten legt man ja idR mehr Spannung an, senkt generell den Takt oder verbaut mehr Caps - kostet alles Strom, Leistung oder Geld.

[Datarecovery09]

Ah, danke - an die Folie kann ich mich erinnern, die habe ich schon mal gesehen... natürlich ohne sie richtig einordnen zu können.^^

Inzwischen sind ja auch einige neue(?) Carrizo-Details geleakt, die dem Ding eine gewisse Effizienzsteigerung bescheinigen sollen - wie zuverlässig das ist, wage ich nicht abzuschätzen; und ebenso wenig, inwieweit das etwas mit den angekündigten Stromspar-Features zu tun haben könnte.

Aber inwieweit hat jetzt die Voltage/Clock Control etwas mit dem eigentlichen Grafikchip zu tun? Sind das Features, die bei der Konzeptionierung der GPU bereits implementiert werden müssen oder kann so etwas auch mit einem bereits vorhandenen Chip gemacht werden?

Nicht, dass sich jemand wundert: Ich frage das schon mit Gedanken an die kommende R300-Reihe; mit anderen Worten: Wäre es möglich, dass AMD z. B. einen Tonga-Chip nimmt und ihnen ähnliche Stromspar-Mechanismen zur Seite stellt wie Nvidia seinen Maxwells oder müsste man den Chip dazu komplett neu designen?

[Käsetoast]

Also solche Stromsparfeatures lassen sich schlecht z.B. einfach nur auf dem PCB der Grafikkarte realisieren. Der Chip muss intern für dieses Feature vorgesehen sein, denn sonst lässt sich das schlecht regulieren bzw. es liegen nicht genug Informationen vor, um die Regelung an den jeweiligen Stellen überhaupt zu ermöglichen. So gesehen müsste das schon im Chip selber gelöst werden und das ist auch kein Feature, das man so "mal eben" umsetzt...

Ich denke es besteht aber eine realistische Chance, dass die kommenden Chips durch die Bank zumindest irgendwas in dieser Richtung bieten werden. Entgegen anderer Vermutungen wie sie ja erst kürzlich wieder herumgeisterten glaube ich eigentlich nicht daran, dass nur Fiji neu wird und der Rest im Endeffekt nur Rebranding wird. Kann mir nicht vorstellen, dass man Pitcairn, also die 7800er / R9 270er Reihe unter neuem Namen immer noch mitschleppen wird. Da sind die bekannten Features wie TrueAudio und vor allem eine bessere Mantle Unterstützung so langsam angesagt. Wenn AMD in ihrer Planung also irgendeine bessere Spannungssteuerung vorgesehen hat, kann ich mir gut vorstellen, dass die dann auch durch die Bank zusammen mit den neueren GCN Features Anwendung finden wird. Interessant dabei ist sicherlich die Frage, ob bei Global Foundries gefertigt wird. Falls ja musste man die Produktion dort ja sowieso neu aufziehen und es würde Sinn machen die alten Chips entsprechend auf einen aktuellen Stand zu bringen. Wenn man bei TSMC bleibt ist die "Gefahr" in meinen Augen deutlich höher, dass man tatsächlich nur Rebranding betreibt...

Ansonsten bin ich immer noch gespannt, ob uns nicht doch noch 20nm Chips erwarten. AMDs Verhalten in Bezug auf Tonga, also der Resteverwertung als 285 ohne X war ja recht merkwürdig. Das schürt halt das Feuer für Spekulationen wie, dass Tonga als 20nm Chip geplant war, aber wegen Veträge mit Apple vorzeitig in 28nm gebracht werden musste. Da man aber wusste, dass da noch was besseres kommen wird (und das verhältnismäßig zügig), brachte man für den Desktop dann nicht mehr als die maue 285 Resteverwertung, die ja durchaus unterhalb ihrer Möglichkeiten operieren sollte, einfach um die ganzen Reste als 285 durchgehen zu lassen. Tonga in 20nm würde den Chip klein genug machen um ein echter 270 Nachfolger zu werden (wenn man sagt Fiji wird 390 und ein Hawaii Ableger 380, dann fiele Tonga die 270er Nachfolge-Rolle als 370 zu, wobei der Chip in 28nm aber irgendwie zu groß ist um auf lange Sicht den angepeilten Preisrahmen zu bedienen - in 20nm hingegen würde das hinhauen). Eine 360er Reihe wäre dann eben auch ein 20nm Pitcairn mit den neuen Features. Kann aber eben auch reine Träumerei sein und die 20nm Prozesse eignen sich dann doch so gar nicht für GPUs, auch wenn es nur die eher kleineren Varianten sind ohne die ganz bösen Stromfresser...

[Agent117]

Nicht, dass sich jemand wundert: Ich frage das schon mit Gedanken an die kommende R300-Reihe; mit anderen Worten: Wäre es möglich, dass AMD z. B. einen Tonga-Chip nimmt und ihnen ähnliche Stromspar-Mechanismen zur Seite stellt wie Nvidia seinen Maxwells oder müsste man den Chip dazu komplett neu designen?

Die Stromsparmechanismen sind in der Hardware implementiert. Man müsste den Chip daher schon weitgehend redesignen. Das geht schon deutlich über einen Respin hinaus. Wie genau das in hardware gelöst ist kann ich leider nicht sagen; würde mich auch interessieren.
Soll aber nicht heißen, dass das nicht auch Treiberarbeit ist.

Beim Spielen wird ständig neu berechnet, was auf dem Bildschirm angezeigt werden muss und was vlt verborgen in der Welt hinter anderen Objekten liegt. Das macht alles die Spielengine. Hinzu kommen diverse Effekte.
Es wird dann ein Bild mit irgendeiner - hoffentlich spielbaren - Framerate ausgegeben. Die chipinternen Vorgänge, also zum Beispiel das Abarbeiten der Wavefronts, verarbeiten der Daten aus den CU-internen Caches usw. geschieht natürlich nochmal um einige Faktoren schneler als die angezeigte Framerate.
Desto schneller mein Powermanagement arbeitet (Umschalten von Powerstates), desto besser kann ich in die chipinternen Vorgänge eingreifen.
Ich kann also im Nanosekundenbereich sagen, wann ein geringerer Datendurchsatz zum Aufrechterhalten der Framerate ausreichend ist und dann schnell Taktrate und Spannung senken.
Das ist mMn daher Hardware und Treiberarbeit. Natürlich spielt auch die Erfahrung, welche Rechenoperationen im Mittel eher Lastspitzen und welche zu einer eher geringeren Belastung führen eine Rolle.

[Skysnake]

VAO als Option dem Vdrop zu begegnen ist spannend und sollte in Steamroller schon drin sein, nun in der Carrizo-GPU und vll auch schon in Fiji. Ansonsten legt man ja idR mehr Spannung an, senkt generell den Takt oder verbaut mehr Caps - kostet alles Strom, Leistung oder Geld.
Caps, also externe auf dem PCB, sind da nicht gemeint. Die sind so weit weg, dass die gegen Spannungseinbrüche im nanosekunden Bereich gar nichts bringen. Da musste denn dann MOM/MIM Caps on Chip haben, und halt allgemein das PowerDeliveryNetwork niederohmig und mit großer Kapazität designen, aber selbst das hilft dir heute nicht mehr, weil die Anforderungen so hoch sind, dass du das gar nicht mehr schaffen kannst. Es ist einfach unmöglich geworden teils.

Da helfen dann nur noch Spannung erhöhen, oder eben aktiv die Spannung regulieren bzw dynamisch takten. Die Sache ist also durchaus aus der Not heraus gebohren.

[y33H@]

Ich meinte MIM-Caps im Chip bzw Package und ja, mag schon sein, dass das heute schon nicht mehr weiter hilft bzw AFAIK Standard ist.

[Ailuros]

http://www.fudzilla.com/news/graphics/37077-bandwidth-might-not-be-everything-hbm-fiji

*tschingderassabumm* :freak: :eek:

[Botcruscher]

Klingt nach Sommerloch.

[Thunder99]

Aber eher für GM200 oder?

[Dimitri Mayakovsky]

http://www.fudzilla.com/news/graphics/37077-bandwidth-might-not-be-everything-hbm-fiji
"Bandwidth might not be everything for HBM Fiji"

Dass man so etwas noch betonen muss. Und dann auch noch anfängt die Anbindung über die Breite im Speicherbus zu definieren, obwohl auch das Quatsch ist. Entweder man vergleich die Bandbreite des Busses, oder man lässt es bleiben.

[Isen]

Der Name ist Programm. Fud für die Futt

[OBrian]

Das Interessante an HBM ist meiner Meinung nach auch eher die Möglichkeit, die benötigte Bandbreite mit relativ wenig Stromverbrauch hinzukriegen. Einfach nur Bandbreite bolzen ist einfach, nur wird das dann zu teuer fürs TDP-Budget. Siehe HD 2900XT im direkten Vergleich mit der HD 3870 als offensichtliches Beispiel. Aber mit HBM werden einige zig Watt frei (ggü. der herkömmlichen RAM-Anbindung), die dann eben in einen stärkeren Chip gesteckt werden können.

Und ein weiterer Punkt sind auch die Kosten, denn HBM sollte eigentlich deutlich einfachere Karten ermöglichen: Stromversorgung wird schlanker, weil nur noch der Chip versorgt werden muß, das PCB wird kleiner und braucht weniger Layers, weil die vielen RAM-Leitungen wegfallen, es bleiben also nur noch die PCIe-Anbindung und Strom. Der Chip selbst wird aufwändiger, aber grundsätzlich sollte das weniger kosten. Vielleicht nicht in der ersten Generation, aber längerfristig sicherlich.

[Thunder99]

Wurde irgendwo mal GDDR6 angekündigt? Beide IHVs haben ja Berechnungen und Prognosen was sie brauchen werden und wenn da weitere Entwicklungen fehlen müssen sie halt nach Alternativen suchen

[Dawn on Titan]

http://www.fudzilla.com/news/graphics/37077-bandwidth-might-not-be-everything-hbm-fiji

*tschingderassabumm* :freak: :eek:

Hat der da einen Artikel veröffentlicht, der nahe legt, dass GM200 Fiji schlagen könnte? Das ist bei der Quelle aber sehr verdächtig...

[aufkrawall]

Artikel nennst du das?
Was ein erbärmliches Geschreibsel das ist.

[Dawn on Titan]

Das ist bei Fuad immer so, allerdings ist auch die Aussage sonst relativ konstant.

rot - everything is awesome
grün - sucks

[aufkrawall]

Wer solche Fehler einbaut, kann doch unmöglich irgendetwas wissen.

[Ailuros]

Das ist bei Fuad immer so, allerdings ist auch die Aussage sonst relativ konstant.

rot - everything is awesome
grün - sucks

Dann lese ich einen anderen Fudo ueber die Jahre. Gruener geht es gar nicht bei ihm. Dass er strohdumm ist gehoert in ein anderes Kapitel :D Ich hab mir gespart im Prozess thread hier auf seinen Samsung 14nm write up zu verlinken weil ich einmal mit etwas lachen kann wie mit dem vorigen HBM link, danach tut er mir dann einfach leid.

[Hübie]

Ich will da nicht draufklicken, aber wenn das einer schon getan hat wäre ein Zitat zum lachen nett. Mein Abend würde dadurch sicher versüßt werden :biggrin:

[Ailuros]

Ich will da nicht draufklicken, aber wenn das einer schon getan hat wäre ein Zitat zum lachen nett. Mein Abend würde dadurch sicher versüßt werden :biggrin:

Es gibt keine free ride; entweder draufklicken oder nichts :P

[aufkrawall]

Er kann auch genau so gut seinen Finger nehmen und...

[Unicous]

...mit Fingermalfarben ein Selbstporträt malen.


Der Artikel ist superlaaaaaangweilig. Es gibt weder krasse Enthüllungen noch interessante Überlegungen. Es ist lediglich geistiger Dünnpfiff der auf längst bekannten Allgemeinplätzen beruht.

[reaperrr]

Dann lese ich einen anderen Fudo ueber die Jahre. Gruener geht es gar nicht bei ihm.
Habe ich auch so empfunden.

Dass er strohdumm ist gehoert in ein anderes Kapitel :D
Ich glaube nicht, dass er in dem Sinne dumm ist, aber er ist meiner Meinung nach stinkfaul, hat gar kein wirkliches Interesse an der Materie und versucht deshalb gar nicht richtig, alles zu verstehen sondern haut die ihm zugetragenen Infos einfach - meistens auch noch bröckchenweise in mehreren Artikeln, wegen der Klicks - raus und schludert dann einfach noch irgendwelchen flüchtig zusammengereimten Käse dazu, um möglichst schnell eine Textmenge zusammenzubekommen, die als Artikel durchgehen kann.

[Dimitri Mayakovsky]

Also ist er nicht dumm, sondern im Gegenteil sehr schlau. Fakten stören ja auch sehr oft, wenn man solche Artikel schreibt.

[Hübie]

Es gibt keine free ride; entweder draufklicken oder nichts :P

http://www.abload.de/thumb/gzsmd.jpg (http://www.abload.de/image.php?img=gzsmd.jpg)

Zufrieden? :P Willst den Laden da am Laufen halten wa? :freak:

Edit: Boah ich kotz gleich. 5 Minuten meines Lebens die mir niemand wieder zurück geben kann.

[Ailuros]

ROFL :D

Tut mir leid aber es fehlt leider an ernsthaftem Material und wenn ich schon das Unglueck habe mir solchen Mist durchzulesen moechte ich es auch mit anderen teilen :weg:

[Dawn on Titan]

Dann lese ich einen anderen Fudo ueber die Jahre. Gruener geht es gar nicht bei ihm. Dass er strohdumm ist gehoert in ein anderes Kapitel :D Ich hab mir gespart im Prozess thread hier auf seinen Samsung 14nm write up zu verlinken weil ich einmal mit etwas lachen kann wie mit dem vorigen HBM link, danach tut er mir dann einfach leid.

Ich dachte eigentlich immer, das er ne gepflegte Abneigung gegen NV pflegt.

[Ailuros]

Ich dachte eigentlich immer, das er ne gepflegte Abneigung gegen NV pflegt.

Da hast Du Dich aber gewaltig angestrengt Dich darueber zu ueberzeugen :biggrin:

[reaperrr]

Ich dachte eigentlich immer, das er ne gepflegte Abneigung gegen NV pflegt.
Du verwechselst Fudo mit Charlie :wink:

[Dawn on Titan]

Du verwechselst Fudo mit Charlie :wink:

Ja, Du hast Recht. Mein Fehler

Okay, dann ist der Artikel noch witzloser.

[Nakai]

Meanwhile in China.. (http://www.chiphell.com/thread-1241851-1-1.html)

Nichts neues, aber die videocardz-Möchtegern-Photoshops der R9 380/390-Serie sind endlich auch in Fernost angekommen.

Bzgl. dem Fudo-Artikel. Da haben schon andere Forengänger geistreicheren Durchfall abgelassen. Fudo muss schon ziemlich umherkriechen, wenn er solche Artikel schon verwurstet. Anscheinend hat er keine guten Quellen mehr, irgendwie kommt von ihm auch nichts mehr.

[mironicus]

Sind Fiji-Samples wohl schon im Umlauf?

Gerade zum Start von FreeSync-Monitoren oder GTA V sollte da da wohl mal langsam etwas kommen. :)

[y33H@]

Ja, schon seit Wochen.

[fondness]

Da könnte sich der Fiji-Kühler wohl den ein oder anderen Trick abschauen:
http://www.guru3d.com/articles_pages/cooler_master_nepton_240m_review,1.html

[aufkrawall]

Wie ist noch gleich der Gerüchtestand zu DP bei Fiji?

[M4xw0lf]

Es gibt imo keinen Stand.

[Datarecovery09]

Unterdessen schießt irgendein Wikipedia-Autor den Vogel ab...^^

http://en.wikipedia.org/wiki/AMD_Radeon_Rx_300_Series


Und WCCF ist übrigens auch wieder wild am fantasieren.

[Locuza]

Von der Wikipedia Tabelle kann man echt Krebs bekommen.

Aber AMDs Fiji oder irgendeine andere Karte wird vermutlich auf der GDC verwendet:
https://twitter.com/draginol/status/569999351365423105

Es gibt vermutlich auch eine neue Demo von Oxide/Stardock.

[horn 12]

@Nakai
@Ailuros

Wie sicher kann man etwas von Fiji XT/ Pro sehen zur Messe am Mittwoch...
Zudem preislich auch schon etwas bekannt ?
Ich für meinen Teil würde von knapp 500 Euro für Fiji Pro (GTX 980 +15%)
und gute 700 Euro für die XT ausgehen (Mindestens +35% auf die GTX 980)

PS:
Da nun die Sapphire R9 290 @1100 Mhz habe kann ich auf die 8GB HBM locker warten.

[Raff]

Von der Wikipedia Tabelle kann man echt Krebs bekommen.

Aber AMDs Fiji oder irgendeine andere Karte wird vermutlich auf der GDC verwendet:
https://twitter.com/draginol/status/569999351365423105

Es gibt vermutlich auch eine neue Demo von Oxide/Stardock.

Hmm, die fette Kiste ist wohl der Kühler? :biggrin:

Im Ernst: Ui, langsam wird's spannend. Hoffentlich zeigen sie tatsächlich etwas und noch hoffentlicher teilt das Ding ordentlich aus (damit der große Kühler eine Daseinsberechtigung hat ;) ;)).

MfG,
Raff

[Isen]

Och... auf so einigen Köpfen wird er seine Wirkung zeigen, versprochen:whistle:

[Hübie]

Was geht denn auf wiki ab? Dem sollte man das editieren verbieten.