AMD/ATI - Volcanic Islands (VI) - Hawaii, Maui, Iceland, Tonga - 2013/2014 [Archiv] - Seite 29

PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : AMD/ATI - Volcanic Islands (VI) - Hawaii, Maui, Iceland, Tonga - 2013/2014

Seiten : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 [29] 30 31 32 33 34 35 36

OBrian

2014-08-14, 08:34:05

Also das höhere Verhältnis ACEs zu CUs (was mit Bonaire und Hawaii gekommen ist) ist sicher eine Änderung am GCN-Bereich, ist aber auch praktisch das einzige, was man überhaupt sieht. Und da das eigentlich nur billigstes copy&paste von Funktionsblöcken ist, tue ich mich schwer, das als Architekturupgrade anzuerkennen, es ist einfach nur ein anderes Balancing der vorhandenen Teile. Dazu müßte einer dieser Blöcke (eine ACE oder eine ROP oder was weiß ich) irgendwie verändert worden sein.

Das Vorhandensein von TrueAudio macht den Chip zwar moderner, aber das ist ja wohl kein GCN-Bestandteil, sondern ein (korrigiert mich, wenn ich falsch liege) völlig unabhängiger Zusatzprozessor. Ebenso wie ein verbesserter UVD/VCE. Diese Extra-DSPs sollten also einen GCN "1.0" weder auf "1.1" noch auf sonst eine aus den Finger gesogene Versionsnummer heben können. Das gleiche gilt auch für Fertigungsverbesserung, andere Transistorenformen, Stromsparmechanismen usw., die sind ja alle nicht definierend für die Architektur, sondern sollen "nur" Taktbarkeit, Energieeffizienz, Flächenverbrauch usw. verbessern.

Abgesehen davon wäre mit eine Benennung "Generation 1, 2, 3" usw. eigentlich lieber, weil es einfach nur die Veränderung der GCN-Kerne andeutet, aber ohne Wertung. Bei GCN "1.1" und "2.0" dagegen lege ich die Maßstäbe üblicher Softwareversionierung an (nicht solcher inflationärer Scheiße wie die Firefox-Versionen), d.h. 1.0 ist die erste Releaseversion, 1.1. dann ein kleinere Upgrade und 2.0 ein größerer, grundlegender Umbau. Da stellt sich dann also mir automatisch die Frage, wieso ist GCN 2.0 eben 2.0 und nicht 1.2? Wenn sie die CUs so umgestrickt hätten wie Nvidia von Kepler auf Maxwell, dann würde ich 2.0 für gerechtfertigt halten. Aber wenn z.B. wirklich nur die mehr ACEs dazugekommen sind bei Bonaire, ist es meiner Auffassung nach nicht mal 1.1 gewesen, sondern 1.0.1, also nur eine kleinere Anpassung.

Also wie schon gesagt, das ist totaler Marketingbullshit und vor allem total irreführend. Ich kann mich an eine AMD-Aussage erinnern, wo es hieß, man wolle in nächster Zukunft möglichst wenig an der Architektur ändern, um den Mantle-Programmierern eine möglichst langzeitstabile Hardwarebasis bieten zu können. Ist ja auch einleuchtend, je näher die Grafikkarten technisch an den Konsolen-GPUs dran sind, desto einfacher sind Portierungen. Früher hat der Treiber die Unterschiede abgefangen, aber mit Mantle ist diese Arbeit ja vom Chiphersteller auf den Spieleentwickler übergegangen.

Also wenn ich das versionieren müßte, würde ich die GCN-Kerne in Tahiti als GCN 1.0.0 bezeichnen, die in Pitcairn mit 1.0.1 usw., eben für jeden neuen Chip die dritte Stelle um eins erhöhen. Das träfe es wahrscheinlich noch am ehesten; wahrscheinlich gibt es einige Evolutions-Snapshots, die es nicht in den Markt geschafft haben, weil der Chip damit frühzeitig wieder gecancelt wurde. Also ist Tonga irgendwie GCN 1.0.8 oder sowas.

Das würde jedenfalls die Erwartungshaltung auf ein vernünftiges Niveau runterregeln. Bei "GCN 2.0" erwartet ja jeder die doppelte Leistung von Tahiti mit halbem Stromverbrauch und dazu DX14-Features und noch die Fähigkeit, nebenher einen leckeren Espresso zubereiten zu können.

ndrs

2014-08-14, 09:56:11

Das würde jedenfalls die Erwartungshaltung auf ein vernünftiges Niveau runterregeln. Bei "GCN 2.0" erwartet ja jeder die doppelte Leistung von Tahiti mit halbem Stromverbrauch und dazu DX14-Features und noch die Fähigkeit, nebenher einen leckeren Espresso zubereiten zu können.
Da AMD nie eine GCN-Versionsnummer o.ä. nach außen kommuniziert, geschweige denn als Marketing-Instrument verwendet hat, solltest du die gesamte vorstehende Kritik an die Erfinder dieser Bezeichnungen, die wohl irgendwo in diversen Presseredaktionen oder Foren sitzen wenden.
AMD dafür zu kritisieren halte ich für fehl am Platz. Von denen bekommst du einen Namen mit Generationsnummer mit Leistungseinordnung sowie ein paar kleine Buzzword-Features. Sonst nichts. Und das ist auch gut so, da Otto-Normalo damit eh nichts anfangen könnte.

M4xw0lf

2014-08-14, 10:10:11

Hatte AMD nicht gestern noch eine interessante SIGGRAPH-Präsentation? Advanced Micro Devices, Inc. (AMD): Mantle and the Next-Gen Renderers With FirePro Graphic Core Next 2

WEDNESDAY, 13 AUGUST | 9:45 - 10:45 am

Warum gibts nirgendwo Slides und auch sonst nix dazu? :uconf3:

Askingar

2014-08-14, 11:20:29

Und das ist auch gut so, da Otto-Normalo damit eh nichts anfangen könnte.
Glaubst du, letztendlich kann man damit sogar das Gegenteil erreichen, nämlich den potentiellen Kunden für blöd hinstellen, weil er weiss es ja soweiso nicht. Pustekuchen, die Leute gehen mittlerweile in den Laden und gucken sich genau an, was sie für was brauchen/kaufen und wieviel das kostet. Solche weiterentwickelten Feature werden dann garnicht wahrgenommen. Es geht nicht mal darum etwas GCN 25 zu nennen sondern einfach nur auf die inneren Werte seitens AMD hinzuweisen.

Wenn ich jetzt auf die AMD-Seite gehe um mich ggf. zu erkundigen, werde ich befragt wie alt ich bin und solchen Firlefans, dass interessiert mich nicht die Bohne und ich klicke es weg. Ich will nichts preisgeben was zum Bereich der persönlichen (auch informationellen) Selbstbestimmung gehört. Wie alt ich bin schon garnicht.

Ich würde aber DX12 auf den Karton drucken, openGL4.4, Mantle, besonders stromsparend (super silent steht ja drauf, aber was hat das mit AMD zu tun, wenns kein Referenzkühler ist) und GCN Gen 3, oder eine höhere Generation kostet auch nix oder etwas dergleichen, ein schönes großes AMD Logo (da sind die von den Partner größer) und und und...Es geht zuweilen unter, dass der wertigste Teil des Angebots als Produkt von AMD kommt. Gerade im GPU Segment steht man doch immer noch gut da und diesen Vorteil sollte man dann auch nutzen, zudem könnte man auch andere Produkte bewerben, wie "zur Verwendung mit AMD APUs optimiert" etc..

Ich will den Marktingheinis da aber nichts vorschreiben. Aber zu meinen, "wissen die eh nicht" und "schlichtes Marketing ist in", ist genau der falsche Weg, mit Tonga-IP kann kein Mensch was anfangen, da geht man gelangweilt weiter, zunmal alles im selben Karton der Vorgängerversion verpackt, gleich aussieht und die Leute mittlerweile vom umlabeln genervt sind. AMD wundern sich, dass sie am Markt nicht wahrgenommen werden obwohl sie gute bis sehr gute Produkte liefern, aber vllt. sollte man mal darüber nachdenken was man da falsch macht. Aber gut passt hier vllt. nicht.

Ihr tut ja so als wüssten alle, wie ihr hier, grundlegend über alle Dinge Bescheid, dass ist absolut nicht so. Trotzdem werden beworbene Feature sehr sicher wahrgenommen. Da kaufen die Leute zuweilen sogar teurer als es sein müsste. Es ist auch kein Betrug oder dergleichen auf innere Werte hinzuweisen und sie dem Käufer auch schmackhaft zu machen und wenn es eben nur für die Zukunft wäre. Billig und preiswert bedeutet schon seit längerem nicht immer gut (auch wenns so ist)...da wenden sich viele ab und gehen eher von Zweitklasse aus.

Wo bleiben Feature wie das hier?
vllt. in Gen3 oder so:
Partially Resident Textures
Improved Anisotropic Filtering
Improved DirectX® Tesselation
AMD Efficiency
AMD ZeroCore Power Technology
AMD Catalyst™ Technologie with User-Overdrive
AMD Crossfire™ Technology XDMA
AMD HD3D Technology (wo sind die Logos?)
AMD TressFX Hair
Vllt. sogar
HSA
hUMA etc. soweit es unterstützt wird und im Zusammenhang mit der Verwendung von APUs. Viele Dinge davon werden sehr wohl wahrgenommen und sind auch gewünscht. zu sagen wissen die eh nicht ist...kontraproduktiv.

Die Liste ist so lang..., nix zu sehen davon, in Microschrift irgendwo in der Verpackung wenn man Glück hat und der Partner es beigelegt hat. Naja gut, die werden schon wissen was die machen. Das ist auch nicht böse oder abwertend gemeint, ich finde es einfach traurig dass sowas untergeht.

Pick

2014-08-14, 12:41:24

GCN 1.1 1CU=64SP
GCN 2.0 1CU=128SP (Tonga XT - 16CU)

Es ist möglich.

Nakai

2014-08-14, 14:41:09

http://semiaccurate.com/2014/08/14/amds-fiji-gpu-not-arriving-soon-enough/

Paywall...

Ansonsten vermute ich bei Fiji(550mm2+) eine Kombination von HBM und normalen GDDR5-RAM. Eventuell sehen wir sequentielle Processoreinheiten auf Fiji. H1 2015?

Zu Tonga IMO:

Tonga Pro ~ HD7870-Verbrauch
Tonga XT ~ HD7950-Verbrauch

HD7950 < Tonga Pro < HD7970 < Tonga XT < R9 290

€: Tonga wird imo eher Tahiti-kompatibel sein, als Pitcairn-kompatibel.

Akkarin

2014-08-14, 14:53:13

Will der Typ tatsächlich 1000$/100$ für stunden pro Jahr :freak: ?

edit: Der "Studenten" Vertrag ist nicht mal für studenten, sondern ist für jeden offen und bietet weniger inhalt :freak:

Und ich frag mich wieso es nie "leaks" von den Artikeln hinter der Paywall gibt. Vermutlich hat er grad mal n paar dutzend subscribers.

Unicous

2014-08-14, 14:58:32

@Nakai

Was soll ein HBM/GDDR5 Hybrid genau bringen? Hört sich nach viel Aufwand und wenig Nutzen an. Und nach Halbgarem. Ich schätze es ist doch etwas "Interessanteres".

Hmm. Andererseits steht da 3 Jahre Verspätung...

http://s22.postimg.org/pw6knfy41/AMD_roadmap_tiran.jpg

Stacked die confirmed.

http://i.imgur.com/vwMin.gif

:wink:

Zu Tonga XT. Ich denke, das Ding wird sich im Verbrauch etwas unterhalb der HD7950 ansiedeln, denn sonst haben sie nicht viel gekonnt (185 Watt, Tahiti LE anyone). Auch die Leistung über der HD7970 sehe ich irgendwie nicht. Dementsprechend sehe ich die PRO eher bei 160-175 Watt.

@Akkarin

Es gab doch gerade erst einen "Leak". Da wurde der paywall Artikel zugespielt und es wurde schön abgeschrieben.

Und ein paar Dutzend Subscriber die 1000 Euro bezahlen ist nichts oder wie?
Charlie und Co. sind IT-Analysten. Und Menschen die in die Branche investieren möchten gerne darüber informiert werden. Solche Insider-Gerüchte sind da Gold wert und tausend Euro dann Peanuts. Die Leute bekommen ja nicht nur einen polemischen Artikel sondern auch eine (Branchen-)Analyse mitgeliefert. Ich verstehe wirklich nicht wie man sich da immer und immer wieder aufregen muss. Ignorieren wenn es einem nicht gefällt.

Akkarin

2014-08-14, 15:01:53

HBM könnte als art LLC dienen ?

Ich glaubs nicht, aber das wäre das einzige was mir in den Kopf kommt wo ein HBM/GDDR5 Hybrid ein wenig sinn machen würde.

Unicous

2014-08-14, 15:09:57

Was hatte sushiwarrior gesagt?

Fiji will be something new and different, with respects to memory config. Big die.

By different memory config I don't mean HBM necessarily. I said BIG die. 550mm^2 doesn't hold a candle to it.

Leonidas

2014-08-14, 15:24:55

Wurde HBM nicht immer und immer wieder verschoben? Ich glaub kaum, das das bei einem Chip in absehbarer Nähe kommt.

Askingar

2014-08-14, 15:43:11

Gipsel

2014-08-14, 15:59:27

Müsste man dann an den PCBs zuviel ändern, wenn man schon Pincombatibilität oder ähnliches anstrebt? HBM lief ja mit 1,2v nicht mit 1,5v, vllt. dann beim nächsten mal. (was ich aber noch nicht mal glaube)
Auf dem PCB fehlt bei einer HBM-only Lösung schlicht der RAM. Das wird also billiger und kleiner. Pinkompatibilität ist bei HBM aber nicht drin. Der Speicher bekommt zwar sowieso seine eigene Versorgungsspannung, ob der mit auf dem Package bzw. Interposer sitzt oder nicht ist dafür erstmal vollkommen egal, bei einer HBM-Lösung muß die Versorgung aber auf's Package geführt werden, bei einer normalen GDDR5-Lösung natürlich nicht.
HBM+GDDR5 wäre wirklich eine irgendwie halbgare Lösung. Es sollte kein wirkliches Problem sein, HBM mit der benötigten Kapazität herzustellen, wenn man denn will. Immerhin sind die Stacks momentan 4 Dies hoch (später sollen es 8 werden), also bereits bei 2 Stacks hat man im Prinzip 8 Speicherchips (und bei 4 Stacks dann 16, genauso viele wie am 512bit Interface von Hawaii). Stapelt man 2 GBit-Chips (der Standard beim momentanen GDDR5, 4 GBit ist allerdings auch schon seit mehr als einem Jahr verfügbar), wären das also 1 GB pro Stack (mit 128GB/s pro Stack, wenn ich das noch richtig im Kopf habe).

Leonidas

2014-08-14, 16:12:23

Nakai

2014-08-14, 16:22:09

Was hatte sushiwarrior gesagt?

Er sprach von Memory Config, was mich dazu verleitet hat beides gleichzeitig anzunehmen. Selbst Intels neuer XEON Phi hat HBM + DDR4. Eventuell sieht man das gleiche oder ähnliches bei AMD. Caches sind für Streaming-Architekturen, wie GPUs eher wenig vorteilig, da Datenwiederverwendung beim Rendering weniger gut ausgeprägt ist. Beim Compute ist es natürlich wieder was anderes. Oder so, umso mehr Daten wiederverwendet wird, umso besser ist ein Cache.

Ein größerer HBM-Speicher als Cache sollte auch bei Grafikberechnungen einen Vorteil bringen und Energie sparen.

Die Aussage von sushiwarrior kann vieles bedeuten. Großer Cache, HBM, verschiedene Speicherkonfigs, sekundäre Dies, etc.

Was sushiwarrior auch mit BIG Die meint, ist etwas kryptisch. Eventuell ist die gesamte Diesize abartig hoch (600mm²), aber wenn mehrere Dies mit Stacking zusammengeschaltet werden, heißt das nicht, dass die einzelne Teile so groß sind. Aber ich sehe Die-Stacking bei Logikdies noch weit entfernt, vorher mit HBM.

€:

HBM+GDDR5 wäre wirklich eine irgendwie halbgare Lösung. Es sollte kein wirkliches Problem sein, HBM mit der benötigten Kapazität herzustellen, wenn man denn will. Immerhin sind die Stacks momentan 4 Dies hoch (später sollen es 8 werden), also bereits bei 2 Stacks hat man im Prinzip 8 Speicherchips (und bei 4 Stacks dann 16, genauso viele wie am 512bit Interface von Hawaii). Stapelt man 2 GBit-Chips (der Standard beim momentanen GDDR5, 4 GBit ist allerdings auch schon seit mehr als einem Jahr verfügbar), wären das also 1 GB pro Stack (mit 128GB/s pro Stack, wenn ich das noch richtig im Kopf habe).

Ja, stimmt GDDR5 ist ja eigentlich nicht viel langsamer als HBM. Pro Stack sind es 128GB/s. Bei 4 Stacks sind das schon 512GB/s. Hawaii schafft schon 300GB/s+. Mit 7Ghz GDDR5 sind es schon über 400GB/s, also kein wirklicher Vorteil, welcher nicht durch andere Sachen eventuell ausgeglichen werden kann.

Was würde denn HBM bringen bei gleichen Speicherinterfaces - wie beispielsweise 512 Bit DDR bei Hawaii? Wenn, dann geht dann doch nur über mehr Takt, richtig? Hat HBM mehr Takt? Oder läuft es darüber, daß wegen der Nähe Chip zu Speicher größere Interfaces möglich werden?

Ich bin mir nicht sicher. Im Endeffekt müssten die PHYs dazu in der Lage sein. Ein HBM-Stack hat 1024Bit, diese sind aber über einem Interposer verbunden, ergo sollten die PHYs anders aufgebaut sein, vor allem wenn noch GDDR5-Unterstützung angestrebt wäre.

Nakai

2014-08-14, 16:28:58

---> Inhalt moved

ndrs

2014-08-14, 16:37:20

Der Speicher bekommt zwar sowieso seine eigene Versorgungsspannung, ob der mit auf dem Package bzw. Interposer sitzt oder nicht ist dafür erstmal vollkommen egal, bei einer HBM-Lösung muß die Versorgung aber auf's Package geführt werden, bei einer normalen GDDR5-Lösung natürlich nicht.
Läuft der Speichercontroller der GPU (zumindest der PHY-Bereich) nicht mit der selben Spannung, wie die Speicherchips? Irgendwie muss man sich doch auf einen Signalpegel einigen oder?

@Leo
Da HBM viel näher an der GPU ist, kann das Speicherinterface je Bit viel kleiner designt werden. Auf dem Platz von Hawaii's 512er SI könnte man wohl wenigstens ein 2048er HBM SI unterbringen.

Pick

2014-08-14, 16:39:11

4 Stacks (4GB) - 512GB/s und 4096Bit, 8 Stacks (8GB) - 1024GB/s und 8192Bit. :cool::biggrin:

Gipsel

2014-08-14, 16:41:16

Was würde denn HBM bringen bei gleichen Speicherinterfaces - wie beispielsweise 512 Bit DDR bei Hawaii? Wenn, dann geht dann doch nur über mehr Takt, richtig? Hat HBM mehr Takt? Oder läuft es darüber, daß wegen der Nähe Chip zu Speicher größere Interfaces möglich werden?
Ja, stimmt GDDR5 ist ja eigentlich nicht viel langsamer als HBM. Pro Stack sind es 128GB/s. Bei 4 Stacks sind das schon 512GB/s. Hawaii schafft schon 300GB/s+. Mit 7Ghz GDDR5 sind es schon über 400GB/s, also kein wirklicher Vorteil, welcher nicht durch andere Sachen eventuell ausgeglichen werden kann.

Ich bin mir nicht sicher. Im Endeffekt müssten die PHYs dazu in der Lage sein. Ein HBM-Stack hat 1024Bit, diese sind aber über einem Interposer verbunden, ergo sollten die PHYs anders aufgebaut sein, vor allem wenn noch GDDR5-Unterstützung angestrebt wäre.
Wie Nakai schon sagt, nutzt HBM ein deutlich anderes Konzept: sehr breite und niedriger getaktete Interfaces, die zusätzlich durch die direkte, kurze Anbindung (sehr kleine Kapazität der Leitungen) deutlich weniger Leistung für die gleiche Bandbreite verbraten. Bei HBM heißt das also 1024Bit-Anbindung mit 500MHz, 1 GT/s double-data-Rate-Transfers (spezifiziert sind auch noch 0,8 GT/s und[das war wohl WideIO2] später kommt auch noch bis 2GT/s). Die PHYs sollten nicht mehr, bzw. tendentiell weniger Platz fressen als die für z.B. für ein 128Bit-7GBps GDDR5-Interface (bis 112GB/s verglichen mit den 128GB/s für einen HBM-Stack) und zusätzlich Strom sparen (Verbrauch nur grob nur halb soviel wird glaube ich öfter mal genannt).

Die Abbildung auf der ersten Folie im folgenden Post von Unicous hat nV schamlos aus der HBM-Spec geklaut. ;)

Beim Nachlesen der HBM-Specs fiel mir auf, daß die JEDEC 1GBit, 2GBit und 4 GBit pro Channel spezifiziert hat. Da jeder normale Stack acht 128Bit-Channels besitzt (egal wie hoch er ist), ergibt sich also eine Mindestkapazität von 1 GB pro Stack, kleiner geht gar nicht. Momentan spezifizierter Maximalausbau wären 4GB pro Stack.

Läuft der Speichercontroller der GPU (zumindest der PHY-Bereich) nicht mit der selben Spannung, wie die Speicherchips? Irgendwie muss man sich doch auf einen Signalpegel einigen oder?
Die PHYs haben ja gerade die Aufgabe, die Signale vom Speichercontroller auf den Signalpegel der Speicherchips umzusetzen und über die Leitungen zu treiben, sie stellen das physische Interface dar.

Unicous

2014-08-14, 16:42:36

Skysnake

2014-08-14, 16:47:01

Da kann man ja gleich mal weiterfragen:

Was würde denn HBM bringen bei gleichen Speicherinterfaces - wie beispielsweise 512 Bit DDR bei Hawaii? Wenn, dann geht dann doch nur über mehr Takt, richtig? Hat HBM mehr Takt? Oder läuft es darüber, daß wegen der Nähe Chip zu Speicher größere Interfaces möglich werden?
Man ist in jeder Beziehung besser.

Breitere interfaces bei gleichen Kosten
Höhere Taktraten bei gleichem Energieverbrauch pro Bit
bzw. weniger Energieverbrauch pro Bit bei gleicher Taktrate

Daher kann man die SerDes auch kleiner bauen.

Nakai

2014-08-14, 16:51:03

@Nakai

Ich wollte eigentlich nur aufzeigen, dass AMD mit Fiji anscheinend etwas Interessantes (Großes) vorhat und Charlie das ja auch noch mal mit seinem Anriss bestätigt. Und es hat mE nichts mit HBM zu tun. Ich hatte mich bloß an die roadmap erinnert mit Tiran und dem "(stacked die)" Zusatz. Und der Chip wäre ja laut AMD Ende 2011 gekommen.

War also eher ein Spaß.

Naja, Tiran wurde schon mit Stacked Die aufgelistet. Solche Entwicklungen werden niemals einfach so verworfen, wenn eine Technologie bei gegebenen Kosten etwas bringt oder sogar Kosten senkt, wird es verwendet, wenn möglich.

Kann jemand hinter die SA-Paywall gucken?

€:

GCN 1.1 1CU=64SP
GCN 2.0 1CU=128SP (Tonga XT - 16CU)

Es ist möglich.

Mhh, da müsste einiges geändert werden. Eine CU bekommt immer 256 Threads zugewiesen(Wavefront). Die wird in 4 Takten abgearbeitet(pro Zyklus 64 Threads, da 64SPs). Mehr SPs heißt schonmal nur zwei Zyklen, ergo müssten andere Faktoren einbezogen werden, da eine CU alle zwei Zyklen eine neue Wavefront dann bekommen müsste. Ich denke da muss deutlich mehr verändert werden, wenn sich die Latenz halbiert.

Eher werden es 16 SIMD4, als doppelt so große CUs. Mit SIMD4-Einheiten hätte man ein paar Fliegen mit einer Klatsche erschlagen. Deutlich höhere Effizienz, vor allem bei Branches und trotzdem ähnlicher Energieverbrauch. Bei Branches ist eine SIMD trotzdem zu 100% ausgelastet, da alle Slots die gleiche Instruktion ausführen. Bei kleineren SIMDs arbeiten weniger Slots leer.

Unicous

2014-08-14, 16:57:46

AMD forscht aktiv an HBM, keine Frage. Wohin das führt ist eher das Mysterium. 2014/2015 werden wir kein HBM in Consumerprodukten sehen, behaupte ich. Ich lasse mir aber ein Fenster fürs 2H 2015.:tongue:

Wenn Fiji doch deus ex machina mäßig mit HBM kommt, bin ich mit meiner Behauptung ganz schön am Popo.

Für die FirePro-Sparte könnte HBM in Zukunft sehr, sehr wichtig werden, genauso wie bei Pascal. Ich denke AMD wird da Nvidia in nichts nachstehen wollen. Aber in 28nm sehe ich das noch nicht. Wo auch immer die Reise prozesstechnisch hingeht, ich denke frühestens mit der nächsten Generation 2015/2016 werden wir HBM sehen.

fondness

2014-08-14, 17:14:22

Würde mich nicht wundern wenn man diese Gelegenheit nützt um Tonga vorzustellen.

AMD to Celebrate 30 Years of Graphics and Gaming in Live Webcast
http://ir.amd.com/phoenix.zhtml?c=74093&p=irol-newsArticle&ID=1958496&highlight=

Festivities to Be Commemorated With Special Guests, Never-Before-Heard Stories and New Product Announcements

SUNNYVALE, CA -- (Marketwired) -- 08/14/14 -- AMD (NYSE: AMD) today announced that it will webcast its 30 Years of Graphics and Gaming commemoration, hosted by AMD's Chief Gaming Scientist, Richard Huddy on Saturday, Aug. 23, 2014 at 10:00 AM EDT (9:00 AM CDT/7:00 AM PDT).

Leonidas

2014-08-14, 17:20:30

Schon verstanden. Der eigentliche Effekt liegt darin, auf dem Platz eines 512 Bit GDDR5-Interfaces ein dickes, sagen wir 2048 Bit HBM-Interface unterbringen zu können. Das Interface ist so breit, daß es für GDDR5 aus Platzgründen und aus Stromverbrauchs-Gründen nie gebaut werden würde. Das geht nur mit HBM. Zudem soll die Sache auch noch Strom sparen, was beim Verbrauchslimit von Enthusiasten-Lösungen Vorteile bringt.

Unicous

2014-08-14, 17:33:21

Das kratzt ja nur an der Fassade. Jeder Stack als auch die einzelnen Dies können separat und unabhängig angesprochen werden und das ist ja auch eine sehr interessante Entwicklung.

Wenn ich das richtig verstehe, könnte also ein Die Daten speichern bis zum Umfallen, während die anderen feucht fröhlich Read/Write machen und sicherlich könnten die auch die Daten auslesen, abgleichen whatever. Im professionellen Bereich lechzen sie bestimmt danach.

ndrs

2014-08-14, 17:36:44

Die PHYs haben ja gerade die Aufgabe, die Signale vom Speichercontroller auf den Signalpegel der Speicherchips umzusetzen und über die Leitungen zu treiben, sie stellen das physische Interface dar.
Ja, schon klar. Ich meinte nur, weil du schriebst:
bei einer HBM-Lösung muß die Versorgung aber auf's Package geführt werden, bei einer normalen GDDR5-Lösung natürlich nicht.
Demnach liegt die Versorgungsspannung also immer auf dem Package. Ok, zumindest der Spannungspegel, ob die Stromstärke dafür reicht ist natürlich die zweite Frage :D Vielleicht hast du ja das gemeint.

Gipsel

2014-08-14, 17:39:58

Mhh, da müsste einiges geändert werden. Eine CU bekommt immer 256 Threads zugewiesen(Wavefront).Nee, das stimmt so nicht. Jeder CU werden je nach Abhängigkeit der Auslastung der anderen CUs und dem Resourcenverbrauch der Shaderprogramme (auf einer CU können gleichzeitig mehrere verschiedene laufen) bis maximal 40 Wavefronts zugewiesen, maximal 10 pro SIMD. Jede Wavefront besteht aus 64 Elementen. Die einzelnen SIMDs (je vec16) bearbeiten "ihre" bis zu 10 Wavefronts weitgehend unabhängig voneinander ab (solange man sie nicht manuell synchronisiert), nur bestimmte Resourcen der CU (LDS, TMUs, Skalar- und Brancheinheit) werden dabei geteilt.

Mehr SIMDs pro CU würde bedeuten, daß man auch mehr TMUs reinpacken müßte und bestimmte Sachen einfach nicht mehr elegant funktionieren (wie z.B. das round robin Scheduling der 4 SIMDs alle 4 Zyklen, wobei die Skalareinheit jeden Takt eine andere Instruktion eines anderen SIMDs bekommen kann). Und größere SIMDs (vec32 statt vec16) bedeutet entweder wirklich kürzere Latenz (schwierig) oder 2 wavefronts in flight in jedem SIMD, was wiederum bestimmte Dinge (result forwarding und Scheduling) verkompliziert.
Aber schauen wir erst einmal auf die vorhandenen Hardwareresourcen in einer CU und generellen Ablauf des Schedulings bei GCN, bevor wir darauf zurückkommen.

http://www.abload.de/img/gcn_cu2rcve.png
Abb. 1: Aufbau einer Compute Unit von AMDs GCN
Erklärung für verschiedenfarbige Pfeile???

Ähnlich den beiden Arbitern und Thread-Sequencern innerhalb des UTDP für die "odd" und "even" Threads in den VLIW-Architekturen enthält jede CU gleich vier sogenannte "Instruction Buffer", für jede Vektor-ALU einen. Diese funktionieren nicht nur wie kleine L0-Instruktions-Caches (sie puffern die nächsten paar Instruktionen für die Threads, die auf der zugehörigen Vec-ALU laufen), die von 32kB L1-Instruktions-Cache (zwischen 4 CUs geteilt) beliefert werden, sondern in diesen Blöcken wird auch der Zustand der einzelnen Threads (Instruction Pointer/Program Counter als Zeiger auf die nächste auszuführende Instruktion, ausstehende Speicheroperationen, Priorität und Privilege-Level, WaveIDs usw.) verwaltet und es befindet sich auch ein Großteil der Scheduling-Logik dort. Die Entscheidungen, welche Instruktion aus welchem Thread an die Issue-Ports weitergegeben wird, fallen hier. Die Instruction Buffer liefern die zur Ausführung ausgewählten Befehle an die insgesamt 6 (oder 9, je nachdem wie man zählt) Issue-Ports in einer CU. Dies wären die Ports für die 4 Vektor-ALUs, für die skalare ALU (inklusive scalar memory), das local Memory (LDS), Vector Memory (global/Texture), den Export/global Datashare (GDS) sowie als letztes die Branch/Message-Einheit. Der lokale Speicher wurde in der Größe verdoppelt (jetzt 64kB) und kann ein paar neue Tricks, auf die wir später noch zurückkommen. Er bleibt auf jeden Fall eine separate Einheit.
Das Umkrempeln der Speicherhierarchie mit GCN spiegelt sich allerdings auch bei den TMUs wieder. AMD hat sich dafür entschieden, den globalen und den Textur-Speicher (in OpenCL und von AMD Image-Speicher genannt) über die gleichen Datenpfade anzusprechen (AMD nennt dies die "Vector Memory" Pipeline), sie teilen sich also auch den gemeinsamen L1 (anders als bei Fermi, wo lokaler und globaler Speicher im L1 vereint sind und der Texturspeicher einen eigenen Cache besitzt). Die Größe des (Vektor-) L1 beträgt 16 kB und erlaubt eine durch das Programm steuerbare Kohärenz bei Schreibzugriffen. Typischerweise verhält er sich wie ein Cache mit "delayed Write-Through", die von einem Thread geschriebenen Werte werden spätestens beim Beenden des Threads in den L2 geschrieben, damit sie global sichtbar werden. Durch die Vereinigung mit dem Texturspeicher ist es übrigens möglich, Atomics nicht nur im globalen Speicher durchzuführen, sondern die exakt gleiche Funktionalität steht auch für Texturen zur Verfügung. Die Bandbreite des L1 zu den ALUs beträgt wie bei den VLIW-Architekturen 64 Byte pro Takt, es sind also wieder vier TMUs.
Shaderexports (z.B. an die ROPs, an den L1/L2 Caches vorbei) besitzen übrigens eine eigene Pipeline, offenbar um die Caches nicht mit diesem Datenverkehr "zu verschmutzen". Die ROPs besitzen für diesen Zweck ja sowieso spezialisierte Caches. Wahrscheinlich kann aber hierüber auch in den globalen Speicher (über einen Write Combining Puffer) an den Caches vorbei gestreamt werden. Diese Pipeline wird auch von Zugriffen auf den 64kB großen "Global Data Share" (eine AMD-Besonderheit, die eine alternative Möglichkeit zum GPU-globalen Datenaustausch bzw. Synchronisation zwischen verschiedenen CUs außer über global Atomics erlaubt, in GCN wohl hauptsächlich aus Kompatibilitätsgründen, oder es ist schneller als die global Atomics über den L2/Speicher) genutzt.

Die Vektor-ALUs haben wie gehabt 16 Lanes, die jetzt (wie bei nVidia) nur noch eine Operation auf einmal ausführen können, dafür gibt es in einer CU vier davon. Die maximale Anzahl der (Vektor-)Operationen/Takt in einer CU bleibt also im Vergleich zu Cayman unverändert. Ebenso wie bei Cayman werden die transzendenten Funktionen auf den Vektor-ALUs berechnet. Jeder Vektor-ALU stehen ingesamt 64 kB (Vektor-)Register zur Verfügung, in einer CU insgesamt also 256kB, genau so viel wie bei VLIW-Architekturen.
Vollkommen neu ist dagegen die Skalar-Einheit. Sie hat ein eigenes Registerfile mit insgesamt 8kB-Größe (4 x 2kB, 2 kB pro Instruction Buffer) und ist für die Operationen zuständig, die für alle Elemente eines Vektors identisch sind bzw. zusammen erfolgen. Die Skalareinheit ist eine reine Integer-ALU und erfüllt zusammen mit der Branch-Einheit die Funktion der Handhabung des Kontrollflusses oder der Ausführungsmasken. Deshalb hat sie ein paar Erweiterungen, um auch 64Bit-Felder effizient zu bearbeiten. Diese Funktionalität existierte natürlich im Prinzip auch schon in vorherigen Architekturen. Die Möglichkeit, diese Skalareinheit explizit anzusprechen und zu programmieren, erlaubt allerdings eine erhöhte Flexibilität und hoffentlich auch erhöhte Performance dabei. Der Skalareinheit steht dabei ein unabhängiger Pfad zum Speicher zur Verfügung inklusive separatem (scalar data) L1-Cache (16kB, read-only, hängt auch am L2), der mit drei anderen CUs geteilt wird. Dieser erfüllt auch die Funktion des Konstanten-Caches, bei den vorherigen VLIW-Architekturen gab es genau einen Konstanten-Cache global für alle CUs zusammen.
Als Letztes verbleibt noch die Branch-/Message-Einheit. Diese führt (oft nach Vorarbeit durch die Skalareinheit) Sprünge und Verzweigungen dann letztendlich aus (updated also den Programm Counter entsprechend). Weiterhin können hier Interrupt-Messages für die CPU oder grafikspezifische Synchronisationsnachrichten generiert werden. Außerdem sitzt hier die Funktionalität für das Debug- und Performance-Monitoring. Keine eigene Einheit aber auf jeden Fall erwähnenswert ist weiterhin, daß bestimmte Instruktionen direkt in den Instruction-Buffern verarbeitet werden. Dies betrifft insbesondere Instruktionen, die das Scheduling beeinflussen. Das wird an entsprechender Stelle näher erläutert.

-Abbildung zum Scheduling bei GCN

Aber kommen wir sozusagen zum Herzstück der Neuerungen mit GCN: dem Scheduling der Instruktionen in der CU.
Wird einer CU von der WorkDistribution ein neuer Thread zugewiesen, erfolgt auch eine Zuteilung zu einem der vier Instruction Buffer und damit auch zu genau einer der vier Vektor-ALUs (basierend auf dem Füllgrad/Priorität usw.). Ein Thread kann nicht (zumindest nicht einfach so) zwischen den Vektor-ALUs hin- und hergeschoben werden. Die Zuteilung ist fest, alle Vektor-Instruktionen eines Threads werden auf genau einer Vektor-ALU ausgeführt (dies vereinfacht den Zugriff auf die Registerfiles). Jeder Instruction Buffer hat Platz für (AMD sagt mindestens) 10 Threads. Es gibt praktisch 10 FIFOs mit den nächsten Instruktionen jedes Threads und auch 10 Zeiger auf die jeweils nächste Instruktion. Für die In-Order-Ausführung bei GCN gibt es damit in jedem Instruction Buffer/Scheduler also genau so viele Instruktionen zu betrachten, wie es dort Threads gibt. Die Auswahl der Instruktionen, die zum Issue kommen, folgt ein paar einfachen Regeln:
- nur maximal eine Instruktion pro Thread
- maximal eine Instruktion pro Issue-Port (Vektor-ALU, skalare ALU, lokaler Speicher, Vektor-Speicher, Export/GDS, Branch/Message)
- maximal 5 Instruktionen in der Summe (eventuell eine Beschränkung durch endliche Anzahl der Register-Ports)

Kommen mehrere Threads für einen Issue-Port (z.B. die Vektor-ALU) in Frage, wird die Auswahl anhand der jedem Thread zugeordneten (und durch den Code wählbaren) Priorität getroffen. Nachfolgend durchlaufen die ausgewählten Instruktionen noch eine (recht simple) Decode-Stufe (die Instruktionen sind deutlich kleiner als bei den VLIW-Architekturen, die Instruktionen der GCN-ISA sind ein wenig komplexer enkodiert), bevor sie an die Ausführungseinheiten gegeben werden.

Im Prinzip hat jeder Instruction Buffer bzw. der damit verbundene Scheduler nur einen privaten Issue-Port (zur zugeordneten Vektor-ALU), die fünf anderen teilen sich alle vier. Um hier Konflikte zu vermeiden, arbeitet das Scheduling von den Instruction-Buffern nach einem einfachen "Round Robin"-Schema. Das heißt im ersten Takt ist der erste Instruction Buffer dran, im zweiten der zweite, im dritten der dritte, im vierten der vierte und im fünften geht es mit dem ersten Instruction Buffer wieder von vorne los. Jeder Instruction Buffer kommt also genau alle 4 Takte dran, was bekanntermaßen der benötigten Dauer zum Issue einer Vektor-ALU-Instruktion entspricht. Die anderen (zwischen allen Instruction Buffern geteilten) Issue-Ports können offenbar jeden Takt einen neuen Befehl entgegennehmen. Auf diese Weise können im Peak ganze 5 Instruktionen pro Takt zum Issue kommen (dauerhaft sind wegen Bandbreitenbeschränkungen theoretisch wohl maximal vier Instruktionen pro Takt möglich, über vier Takte verteilt wären das: 4 x Vektor-ALU, 4 x Skalar-ALU, 4 x Branch, 2 x LDS, 1 x Vector-Memory [mit 32bit Zugriffen], 1 x Export/GDS). Das für die Performance Interessante an dem Schema ist, daß die Vektor-ALUs von den ganzen anderen Aufgaben befreit ist und gewissermaßen auch teilweise entkoppelt. Sobald ein paar Threads auf jeder Vektor-ALU laufen, gibt es durch LDS-Zugriffe, skalare Operationen und Branches praktisch kaum einen Performanceverlust (also Leerlauf der Vektor-ALUs) mehr, da sie parallel zu den Vektor-ALUs laufen können (siehe hier für ein Beispiel (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=8819122#post8819122); Beispiel ist nicht so gut, da es wohl eine vector->scalar turnaround penalty von 4 Takten gibt). GCN erreicht das über deutlich mehr Issue-Kapazität als z.B. ein Fermi-SM aufweist. Dies dürfte auch helfen zu kompensieren, daß ein Thread anders als bei Fermi nicht zwischen den verschiedenen Vektor-ALUs wechseln kann, also kein Load-Balancing zwischen den Vektor-ALUs möglich ist.

Wie erwähnt wird mit GCN das Instruktionsscheduling deutlich flexibler. Aber wie schafft man es, trotz Scheduling auf Basis einzelner Instruktionen den Aufwand minimal zu halten? Die Verwendung eines klassischen Scoreboarding-Systems (wie bei nVidia) kann da nicht die Lösung sein. Das ist zwar ein universeller Ansatz, allerdings kostet Universalität ganz allgemein gesprochen oft auch etwas Aufwand. Bei einem Zuschnitt auf spezifische Anforderungen können meist günstigere Lösungen gefunden werden. Im konkreten Fall ergibt sich also die Aufgabe, einen Kompromiß zwischen Funktionseinschränkungen und Performance zu finden, der sehr nahe an der optimalen Performance bei allerdings schon stark reduziertem Scheduling-Aufwand liegt.

Der Ansatz dazu liegt wie schon bei den VLIW-Architekturen in vorhandenen regelmäßigen, fest definierten Strukturen, wie Ausführungslatenzen und Durchsatz. Scoreboarding funktioniert für beliebige Kombinationen, aber benötigt man das überhaupt? Ein Scoreboard erlaubt die Beachtung aller Abhängigkeiten der Befehle untereinander, so daß das Programm korrekt ausgeführt wird (und nicht voneinander abhängige Befehle zur gleichen Zeit in die Pipeline geschickt werden).
Betrachten wir zuerst nur ALU-Instruktionen und keine Speicherzugriffe. Für den ganz einfachen Fall einer nicht pipelined Einheit, kann man sofort einsehen, daß ein Scoreboard vollkommen überflüssig ist, da es gar keine Abhängigkeiten geben kann. Oder etwas allgemeiner ist jegliche Betrachtung von Abhängigkeiten immer dann unnötig, wenn der Durchsatz der Einheit identisch zur Latenz ist. Dies trifft im Prinzip auch fast auf AMDs VLIW-Architekturen zu. Ein Befehl eines Threads hat eine Latenz von 8 Takten und auch nur alle 8 Takte kann eine neuer (potentiell abhängiger) Befehl abgesetzt werden. Durch die abwechselnde Ausführung zweier (per Definition unabhängiger) Threads, wird die Nötigkeit zur Beachtung der Abhängigkeiten umgangen. Allgemein kann man sagen, daß ein Scoreboard für ALU-Instruktionen auf einer in-order ALU für die korrekte Ausführung unnötig ist. Ist die Latenz größer als der Durchsatz (hat man also eine pipelined Einheit), reicht ein einziger Zähler für den Thread (der mit der Differenz zwischen Latenz und Durchsatz initialisiert wird), der jeden Takt um eins vermindert wird und den Instruktions-Issue für diesen Thread verhindert, solange er ungleich Null ist. Dies vermindert natürlich die Performance im Zweifelsfall enorm. Falls die Einheit Multithreading unterstützt, kann diese Zeit mit anderen Threads überbrückt werden. Ein Scoreboarding-System ermöglicht zusätzlich die Ausführung unabhängiger Instruktionen des gleichen Threads.
Ob das also ein gangbarer Weg ist oder nicht, hängt vom typischen Szenario ab: Wie groß ist der Unterschied zwischen Latenz und Durchsatz und wie wahrscheinlich ist es, daß (genügend) andere Threads zur Ausführung zuer Verfügung stehen? Je größer die Latenz im Verhältnis zum Durchsatz, desto mehr Threads benötigt man für eine einfache in-order Ausführung (die AMD für GCN explizit erwähnt hat), also desto mehr wäre ein Scoreboarding-Scheduler im Vorteil (nVidia arbeitet in diesem Bereich: Durchsatz 2 Takte, Latenz 18 Takte für normale SP-Instruktionen, also ein Faktor 9). Das andere Extrem wäre wieder identische Latenz und Durchsatz, so daß der Verzicht auf ein Scoreboard überhaupt keine negative Auswirkung hat. Sollte AMD bei 8 Takten Latenz wie bei den VLIW-Architekturen bleiben, so würde das durch den Issue eines Befehls über 4 Takte lediglich in einem Faktor 2 resultieren, also jeder Thread müßte nach dem Issue eines Befehls genau ein Mal aussetzen, das Äquivalent zu der interleaved Ausführung zweier Threads bisher. Dies erscheint erstmal als gangbarer Weg ohne übermäßige Performance-Verluste (die Steigerung der Auslastung durch Aufgabe der VLIW-Gruppierung hat man ja trotzdem).
Allerdings ist da noch mehr zu beachten. Benötigt nVidias Fermi 18 Threads zu je 32 Vektor-Elementen pro SM, um die Vektor-ALUs ohne Vorhandensein von ILP auszulasten, würde so eine GCN-CU 8 Threads zu je 64 Vektor-Elementen benötigen, also im Prinzip eine vergleichbare Menge. Nachteilig würden sich Fälle auswirken, in denen ILP vorliegt, allerdings nicht viele Threads vorhanden sind. Die Vektor-ALUs eines GF100-SM können dank des Scoreboarding im Prinzip auch bereits mit nur 4 bis 5 Threads voll ausgelastet werden (weniger geht nicht, da offenbar die Scoreboards nicht groß genug sind, um ILP>4 zu nutzen). Gerade für Fälle mit "fetten" Threads, also wenn viele Register genutzt werden, was die Anzahl der gleichzeitig laufenden Threads limitiert, ist dies ein nicht zu unterschätzender Vorteil. Pro Vektor-ALU besitzen GF100 und GCN die identische Registermenge, allerdings benötigt ein GCN-Thread auch die doppelte Menge an Registern (da die Vektoren doppelt so groß sind). Optimalerweise sollte also eine GCN-CU möglichst mit der Hälfte der gleichzeitig laufenden Threads im Vergleich zu einem GF100-SM zurechtkommen (ohne ILP ist das sicher der Fall), da ansonsten die Registerzahl schnell zu einem limitierendem Faktor werden kann (insbesondere auch bei den "fetten" Threads, die auf AMDs VLIW-Architektur optimierter Code häufig aufweist). Auf den zweiten Blick erscheint es also recht vorteilhaft, falls AMD die Latenz im Vergleich zu den VLIW-Architekturen auf vier Takte senken kann. Dies würde jegliche Komplikationen durch Abhängigkeiten der ALU-Befehle untereinander eliminieren. Außerdem erhöht es im Prinzip auch leicht die effektive Anzahl der Threads, die zum Verstecken der Speicherlatenzen zur Verfügung stehen. Sind diese vier Takte Latenz realistisch? Um das zu beantworten, muß man sich die eigentliche Ausführung der Instruktionen ansehen.

Mit der GCN-Architektur eröffnen sich durch die Kombination von Vektor-ALUs mit einer Skalar-ALU im Prinzip interessante Optionen. Um diese auch nutzen zu können, muß natürlich die Möglichkeit eines Datenaustausches zwischen den Vektor-Einheiten und der Skalar-Einheit existieren. Dazu gibt es mehrere Verknüpfungen zwischen ihnen. So können Vergleiche in einer Vektor-ALU nicht nur die Ausführungsmaske für den Vektor direkt setzen, sondern auf das 64Bit breite Bitfeld mit den Ergebnissen der Vergleiche (Vector Condition Code, VCC) kann von der Skalar-ALU wie auf ein normales Skalar-Register zugegriffen werden. Es kann dann beliebig manipuliert und zum Setzen der Ausführungsmaske oder für beliebige andere Operationen durch die Skalar-ALU benutzt werden. Weiterhin ist es möglich ein Element eines Vektorregisters in ein Skalar-Register zu kopieren. Die wahrscheinlich interessanteste Option ist aber, daß die Vektor-ALUs auch direkt ein Skalar-Register als Operand für eine Vektor-ALU Operation nutzen können. Sprich, statt eines Vektorregister kann ein Skalarregister als ein Quelloperand angegeben werden. Dies ermöglicht als Nebeneffekt übrigens auch eine leicht Verminderung des Bedarfs an Vektor-Registern, da gemeinsame Werte für alle Elemente eines Vekors nicht unbedingt in einem Vektorregister liegen müssen. Der skalare L1-D-Cache übernimmt offenbar auch die Funktion des separaten Konstanten-Caches bisheriger GPUs.
Genauso wie ein Skalarregister können die Vektor-ALUs auch einen Operanden direkt aus dem lokalen Speicher verwenden. Ein einziger 32Bit-Wert kann natürlich immer ohne Bankkonflikt geladen werden. Dieser wird dann per Broadcast an alle Lanes verteilt. Damit es dabei zu keinen Verzögerungen kommt, haben diese direkten Adressierungen als Operand Vorrang gegenüber den normalen LDS-Zugriffen.
Eher werden es 16 SIMD4, als doppelt so große CUs.Das wären doch auch nur 64ALUs, genau wie bisher?
Mit SIMD4-Einheiten hätte man ein paar Fliegen mit einer Klatsche erschlagen. Deutlich höhere Effizienz, vor allem bei Branches und trotzdem ähnlicher Energieverbrauch. Bei Branches ist eine SIMD trotzdem zu 100% ausgelastet, da alle Slots die gleiche Instruktion ausführen. Bei kleineren SIMDs arbeiten weniger Slots leer.Dafür muß man deutlich mehr unabhängige Instruktionen Schedulen, das würde schon Energie kosten, die man gerne sparen würde. Ein flexiblerer Ansatz (der diesen Overhead nur leistet, wenn es wirklich Divergenz gibt und sonst mit größeren Vektoren arbeitet) wie von nVidia mal für die Exaflop-Supercomputer-Zukunft avisiert, wäre da sicherlich besser.

AffenJack

2014-08-14, 18:06:59

AMD forscht aktiv an HBM, keine Frage. Wohin das führt ist eher das Mysterium. 2014/2015 werden wir kein HBM in Consumerprodukten sehen, behaupte ich. Ich lasse mir aber ein Fenster fürs 2H 2015.:tongue:

Gerade weil sie so aktiv daran forschen, wie man an den verschiedenen Slides immer sieht denke ich, dass wir HBM in naher Zukunft von AMD sehen. H2 2015 wäre gerade mal kurz vor Nvidia mit Pascal schätzungsweise H1 2016. AMD sollte aber deutlich mehr Knowhow haben um das früher zu bringen, also eher Fiji H1 2015.

Wenn Fiji doch deus ex machina mäßig mit HBM kommt, bin ich mit meiner Behauptung ganz schön am Popo.

Das ist eher meine Vermutung, HBM passt einfach zu gut zu den Big Die, bzw vll einfach Big Package Gerüchten.

Nightspider

2014-08-14, 22:03:55

Kommt Fiji in 28nm oder 20nm?

dargo

2014-08-14, 22:09:51

28nm.

Pick

2014-08-14, 22:36:06

Carrizo APU hat 8CU GCN Gen3 (GCN 2.0)
http://cdn.overclock.net/9/95/95862d91_3af69f4c-b1e4-491d-9074-857d51412eb6.jpeg

Gen3 1CU = 128SP
8CU = 1024SP

mczak

2014-08-14, 22:54:10

Carrizo APU hat 8CU GCN Gen3 (GCN 2.0)
http://cdn.overclock.net/9/95/95862d91_3af69f4c-b1e4-491d-9074-857d51412eb6.jpeg

Gen3 1CU = 128SP

Dafür sehe ich schlicht keine Anzeichen.
Auch wenn's dieselbe Anzahl SPs wie bei Kaveri sind kann theoretisch die Performance stark zunehmen - abhängig davon wie's denn mit der "higher memory efficiency" aussieht. Bei Kaveri sind eigentlich die 8 CUs Overkill der Performancegewinn gegenüber 6 CUs ist (ausser bei ein paar synthetischen Benches) quasi vernachlässigbar wegen mangelnder Speicherbandbreite (bzw. Bandbreiteneffizienz).

Askingar

2014-08-14, 23:39:52

Tonga setzt imho nicht auf HBM, die GPU soll als Erstes mal zu teures Mid-Range Zeugs ersetzen. Da machen solche Neuerungen keinen Sinn, Stromsparmechanismen in Hardware schon, um effizient zu sein.

Ich glaube ursprünglich wars mal in Q4 geplant, ich glaube dieses Jahr trotzdem eher nicht mehr. Eigentlich sollte HBM ab der 20nm Generation Verwendung finden. Obs so kommt, wer weiß das schon.

M4xw0lf

2014-08-15, 08:37:25

Tonga setzt imho nicht auf HBM
Natürlich nicht, die Bandbreite der W7100 mit mageren 160 GB/s sagt ja wohl schon alles.

Hübie

2014-08-15, 08:44:16

M4xw0lf

2014-08-15, 08:49:30

Also ich weiß nicht was der Einzelne unter Effizienz versteht, aber für mich ists per Definition mit wenig viel erreichen. Wenn Tonga also mit wenig Bandbreite und weniger SPs sowie geringerer Leistungsaufnahme gleich viel oder mehr als Tahiti leistet ist DAS effizient.
Daran besteht kein Zweifel. Nur ist Tahiti selber schon im Vergleich zu seinen ersten Ablegern der Pitcairn-Familie nicht so wahnsinnig effizient.

robbitop

2014-08-15, 10:12:22

Das liegt aber auch nur daran, dass Tahiti den DP Kram mit herumschleppen muss und etwas unbalanciert ist (zu schmales Front-End). Wenn das Teil außerhalb des Geometrieflaschenhalses fährt (aufwändige Shader, hohe Auflösung) zieht es nahezu linear an Pitcairn vorbei (also im Verhältnis der Ausführungseinheiten).

Das liegt nicht an GCN sondern nur an der Balance der Ausführung.

Käsetoast

2014-08-15, 11:39:21

Wenn das Teil außerhalb des Geometrieflaschenhalses fährt (aufwändige Shader, hohe Auflösung) zieht es nahezu linear an Pitcairn vorbei (also im Verhältnis der Ausführungseinheiten).
Wobei das mit der Auflösung ein problematisches Argument ist, denn je nachdem hat Tahiti da einfach aufgrund der 3GB Speicher gegenüber Pitcairn Vorteile...

Kann man denn eigentlich von einer 4GB Tonga XT träumen, die Speichertakte wie Tahiti XT fährt? Gibt's da entsprechende Chips?

dargo

2014-08-15, 13:59:03

Das liegt aber auch nur daran, dass Tahiti den DP Kram mit herumschleppen muss und etwas unbalanciert ist (zu schmales Front-End).
Ihr übertreibt es imo mit dem Front-End. Hawaii hat ein vierfaches Front-End. Jetzt rechne mal die Alu-Leistung runter auf das Niveau von Tahiti und schaue was dir von diesem vierfach Front-End in Spielen an Mehrleistung übrig bleibt. ;)

marc-05

2014-08-15, 16:15:06

Spannend wirds ob AMD bei Tonga mal bischen mehr L2Cache zur verfügung stellt, bisher warens 128kb pro Speichercontoller.
Bei Geforce 750Ti mit satten 2048kb L2 Cache könne man das schmalle
128Bit SI damit sehr gut kompensieren.

Nakai

2014-08-15, 16:53:22

Ihr übertreibt es imo mit dem Front-End. Hawaii hat ein vierfaches Front-End. Jetzt rechne mal die Alu-Leistung runter auf das Niveau von Tahiti und schaue was dir von diesem vierfach Front-End in Spielen an Mehrleistung übrig bleibt. ;)

Was bleibt dir von der Rohleistung übrig? Tahiti und Hawaii müssten schneller sein, anhand ihrer Leistungsdaten. Sind sie aber nicht! Tonga muss die Effizienz steigern, dann erreicht man eine performance zwischen Hawaii und tahiti.

dargo

2014-08-15, 18:22:27

Was bleibt dir von der Rohleistung übrig? Tahiti und Hawaii müssten schneller sein, anhand ihrer Leistungsdaten. Sind sie aber nicht! Tonga muss die Effizienz steigern, dann erreicht man eine performance zwischen Hawaii und tahiti.
Zusammenhang? :confused:

OBrian

2014-08-15, 18:23:58

ach, jetzt sind wir schon bei Tonga-Leistung über Tahiti? alle zehn Seiten wird es gefühlt mehr. Hinterher werdet Ihr alle total enttäuscht sein, wenn der Chip wie ursprünglich anhand der bekannten Daten angenommen nur zwischen Pitcairn und Tahiti liegt. Also ich lasse mich lieber positiv überraschen als negativ.

Askingar

2014-08-15, 19:42:07

Das müsste die GPU nicht mal allein allein bewerkstelligen, erinnern wir uns das AMD den Speichertakt unter bestimmten Anwendungen immer ziemlich hoch hält. Wenn man jetzt Möglichkeiten findet den Takt und damit auch die VCore zu senken, dürfte das schon mal etwas Effizienz mitbringen, die nicht mal allein von der GPU abhängt (hier wären wohl 20-30w drin). Hier sollte man "in Hardware" womöglich Feature erwarten die mit einer nochmals überarbeiteten Powertune-Treiberweiterentwicklung effizienter zusammenarbeiten "könnte".

Ich habe etwas Zweifel das AMD ggf. zu effizient wird und die Leistungcharakteristik nach oben hin kappt (das war ein geniales Feature des Tahiti Pro, OC konnte das Teil jedenfalls ziemlich gut verkraften, sogar bis 1,2Ghz stabil), der gesenkte Takt könnte darauf hinweisen. Soweit dies mit dem größeren Frontend kompensiert werden kann, umso besser.

Selbst wenn Tonga Pro die Leistung der Tahiti XTX nicht erreicht, muss das nicht bedeuten das spätere "Auflagen" nicht doch schneller sein können. Die Tahiti GPU allein ist nicht so inefizient wie hier immer dargestelt wird, und so'n dicker Speicherausbau mit hohem Takt will eben auch bedient werden.

Wenn Tonga Pro sich zwichen Tahiti Pro und XT einsortiert und bei leichtem OC bei 25-30% Energier spart ist alles gut. Ich kann mir nicht vortstellen das Sapphire eine Kühlkonstruktion ala DUAL X auf einem neuen PCB-Layout sinnlos verschwendet. Dann hätten die eine Heatpipe weniger verbaut, ist bisher alles offen, vllt. kann Tonga sogar höher als Tahiti Pro.

Meine persönliche Meinung zählt da sicherlich wenig.

dargo

2014-08-16, 13:02:45

Keine rosigen Aussichten. :usad:
http://www.3dcenter.org/news/hardware-und-nachrichten-links-des-15-august-2014

PS: betrifft natürlich nicht nur AMD.

Hübie

2014-08-16, 13:10:50

Das war schon beim Wechsel von 40 auf 28 nm absehbar. Und bis andere Materialien und Fertigungstechniken nicht wirtschaftlich werden bleibts erst mal so.

HOT

2014-08-16, 13:24:41

Na ja, das heißt eigentlich doch nur, dass Grafikchips in Zukunft kleiner und energieeffizienter werden und dass die Innovation eher aus der Architektur heraus entsteht und nicht platt durch bessere Fertigung. Finde ich eine eher positive Entwicklung wenn ich ehrlich bin. Fiji und GM200 sind sicherlich die Spitze des Eisberges mit 300-350W TDP. Wenn die Chips kleiner und kälter werden und dann aber nicht mehr 80% sonder nur noch 40% mehr bringen ist das ok.

dargo

2014-08-16, 13:25:30

Das war schon beim Wechsel von 40 auf 28 nm absehbar. Und bis andere Materialien und Fertigungstechniken nicht wirtschaftlich werden bleibts erst mal so.
Ja leider. ;(

Ich warte jetzt nur noch ab bis es endlich eine GPU mit der doppelten Leistung von Tahiti XT GE gibt und dann kann man wohl auch etwas tiefer in die Tasche greifen. Denn bis die Leistung der neuen Grafikkarte wieder verdoppelt wird für einen angemessenen Preis vergehen wohl nicht mehr ~3 sondern eher 5 Jahre. :freak:

Nightspider

2014-08-16, 13:28:12

Was meint ihr ob Fiji das Potential hat mehr als 50% schneller zu werden als Hawaii?

Falls AMD wirklich stacked memory verbaut, sollte das locker drin sein oder?

dargo

2014-08-16, 13:32:19

Was meint ihr ob Fiji das Potential hat mehr als 50% schneller zu werden als Hawaii?

Träum weiter. :tongue:

Falls AMD wirklich stacked memory verbaut, sollte das locker drin sein oder?
Für stacked Ram ist es imo noch zu früh. Und selbst wenn es so weit wäre würde wieder die Rohleistung, ähm... Fertigungsgröße limitieren.

Nakai

2014-08-16, 13:39:06

Zusammenhang? :confused:

Hawaii ist kaum stärker als Tahiti, obwohl der Chip teilweise das Doppelte an Leistungsdaten hat. Wohin geht die Leistung? Ich bin mir nicht sicher, dass das Frontend nur alleine daran schuld war. Irgendwas verhindert an der Architektur, dass die Skalierung weniger gut ausfällt.

OBrian

2014-08-16, 13:48:30

Gerade das Frontend ist ja bei Hawaii ggü. Tahiti deutlich stärker geworden, jedenfalls sieht es auf den Schemata so aus. Es hängt wohl irgendwo anders dran.

Kann man nicht mit speziellen Tests sowas mal rauskriegen? z.B. eine 3D-Szene konstruieren, die entweder total übermäßig stark die ROPS belastet, dann mal total extrem die Shader auf mehrere verschiedene Arten, dann mal das Frontend, mal die Speicherbandbreite total überfordert usw., und dann damit mehrere Karten durchtesten und schauen, wie stark die tatsächliche Skalierung von Karte zu Karte abweicht von den theoretisch zu erwartenden Daten.

Duplex

2014-08-16, 14:03:51

Hawaii ist kaum stärker als Tahiti, obwohl der Chip teilweise das Doppelte an Leistungsdaten hat.
Hawaii hat 40% mehr Shader als Tahiti und ist in FullHD mit 4AA/16AF ca. 35% schneller, deine Aussage mit "kaum stärker" ist total daneben.
Für ein Refresh finde ich die 35% mehr Performance vollkommen ausreichend, für große Sprünge (z.b. +100%) braucht man 16/14nm.

Was wird den hier erwartet? Ein Hawaii mit 4096 Shader in 16nm bei 250mm² wäre auch locker 80% schneller als Tahiti, die Einheiten skalieren doch ganz gut.

dargo

2014-08-16, 14:26:56

Hawaii ist kaum stärker als Tahiti, obwohl der Chip teilweise das Doppelte an Leistungsdaten hat. Wohin geht die Leistung? Ich bin mir nicht sicher, dass das Frontend nur alleine daran schuld war. Irgendwas verhindert an der Architektur, dass die Skalierung weniger gut ausfällt.
Ich habe doch nichts anderes behauptet. :confused:

Es wurde schon früher von einigen gemutmaßt, dass das Front-End bei Tahiti stark limitieren würde. An Hawaii sehe ich nicht was diese These bestärkt. Dass man bei Hawaii das Front-End dann aufbohren musste ist natürlich klar denn irgendwann wird es zum störenden Flaschenhals. Aber wo soll Hawaii von den Leistungsdaten her doppelt so stark sein als Tahiti? :confused:

Tesseract

2014-08-16, 14:34:59

M4xw0lf

2014-08-16, 14:49:42

Nakai

2014-08-16, 14:51:05

Hawaii hat 40% mehr Shader als Tahiti und ist in FullHD mit 4AA/16AF ca. 35% schneller, deine Aussage mit "kaum stärker" ist total daneben.
Für ein Refresh finde ich die 35% mehr Performance vollkommen ausreichend, für große Sprünge (z.b. +100%) braucht man 16/14nm.

Was wird den hier erwartet? Ein Hawaii mit 4096 Shader in 16nm bei 250mm² wäre auch locker 80% schneller als Tahiti, die Einheiten skalieren doch ganz gut.

Es ist klar, dass bei hohen Settings und hohen Auflösungen die Bandbreite und vor allem die Größe des VRAM wichtiger wird. Und da skaliert Hawaii dann langsam so, wie der Chip sollte. Abseits davon sehe ich kaum mehr als 25% gegenüber Tahiti bei Perf-Bios. Gegenüber Pitcairn ~80%. Ich schaue vor allem bei gängige Auflösungen eingeschlossen 2560x1440 aber vor allem unterhalb, weil hier andere Karten nicht in ihrem VRAM-Limit landen. Und sicherlich gibt es Spiele, wo Hawaii gut skaliert(zB Crysis 3). Es gibt aber genug Spiele, wo Hawaii unverhältnismäßig schneller ist als Tahiti.

Aber wo soll Hawaii von den Leistungsdaten her doppelt so stark sein als Tahiti?

Das Frontend ist doppelt so breit. Es gibt doppelt soviele ROPs. Ich sage nicht, dass Hawaii doppelt so schnell ist, wie Tahiti unter gewissen Bedingungen, sondern, dass es Fälle geben müsste(wenn dort der Chip limitieren würde), dass Hawaii eine gewisse Performance trotzdem auf die Straße bringt. Das passiert meistens nicht so.

M4xw0lf

2014-08-16, 14:56:45

Das Frontend ist doppelt so breit. Es gibt doppelt soviele ROPs. Ich sage nicht, dass Hawaii doppelt so schnell ist, wie Tahiti unter gewissen Bedingungen, sondern, dass es Fälle geben müsste(wenn dort der Chip limitieren würde), dass Hawaii eine gewisse Performance trotzdem auf die Straße bringt. Das passiert meistens nicht so.
Es passiert in Sniper Elite 3. http://www.pcgameshardware.de/Sniper-Elite-3-PC-257042/Specials/Technikanalyse-und-Benchmarks-1127251/
Hawaii liegt in FHD an die 80% vor Tahiti, durch die Tesselationslast, die Hawaii besser wegsteckt. Pro Takt und SP ist Hawaii da ~30% schneller.

Nakai

2014-08-16, 15:08:28

Es passiert in Sniper Elite 3. http://www.pcgameshardware.de/Sniper-Elite-3-PC-257042/Specials/Technikanalyse-und-Benchmarks-1127251/
Hawaii liegt in FHD an die 80% vor Tahiti, durch die Tesselationslast, die Hawaii besser wegsteckt. Pro Takt und SP ist Hawaii da ~30% schneller.

Definitiv beeindruckend, vor allem weil ich genau diesen Bench so nicht berücksichtigt habe. Viel beeindruckender finde ich aber, wie sich Hawaii vor Pitcairn platziert, obwohl Pitcairn reinher von den Specs ziemlich genau ein halber Hawaii ist.
Da muss ich wirklich sagen: Das hätte ich so nicht erwartet.

€: Um mal wieder Benzin in die Diskussion zu kippen und zweifelhafte Quellen zu nennen. Hier der WCCF-Artikel, welcher den gesperrten Sem-Artikel wohl zitiert.
http://wccftech.com/amd-fiji-gpu-stacked-dram-hbm/

dargo

2014-08-16, 15:11:37

bei hawaii pro ist das verhältnis von fps/shaderleistung sogar noch besser. bei +25% theoretischer shaderleistung gegenüber tahiti kommen am ende stellenweise sogar (taktbereinigt) mehr als 25% mehrleistung raus.
auch ist der unterschied zwischen tahiti und hawaii in spielen verhältnismäßig größer als in vielen GPGPU-szenarien.
Welchen Tahiti XT nimmst du hier muss ich fragen denn es gibt einfach zu viele verschiedene Modelle was die Taktraten angeht. Hawaii Pro hat bsw. gegenüber Tahiti XT GE nur ~18% mehr Aluleistung.

Definitiv beeindruckend, vor allem weil ich genau diesen Bench so nicht berücksichtigt habe. Viel beeindruckender finde ich aber, wie sich Hawaii vor Pitcairn platziert, obwohl Pitcairn reinher von den Specs ziemlich genau ein halber Hawaii ist.
Da muss ich wirklich sagen: Das hätte ich so nicht erwartet.

Warum nicht wenn der Tessellator bei Tahiti/Pitcairn limitiert? In Sniper Elite 3 hat man sich bewußt für einen Tessfaktor entschieden der Hawaii bestens schmeckt. Wie das wohl aussehen würde wenn das Game von NV gesponsert wäre? ;)

Tesseract

2014-08-16, 15:47:44

Welchen Tahiti XT nimmst du hier muss ich fragen denn es gibt einfach zu viele verschiedene Modelle was die Taktraten angeht. Hawaii Pro hat bsw. gegenüber Tahiti XT GE nur ~18% mehr Aluleistung.
auf GPU-seite taktbereinigt (z.B. beide mit konstanten 1GHz) und vor allem kein referenzkühlungs-throttle-bullshit. dass vom vorsprung nix übtrig bleibt wenn hawaii 20% oder mehr throttelt ist klar.

dargo

2014-08-16, 15:54:54

auf GPU-seite taktbereinigt (z.B. beide mit konstanten 1GHz)
Da wird es aber verdammt schwer entsprechende Spieletests zu finden wo beide Karten mit exakt 1Ghz getestet werden.

M4xw0lf

2014-08-16, 15:58:23

Da wird es aber verdammt schwer entsprechende Spieletests zu finden wo beide Karten mit exakt 1Ghz getestet werden.
Ich denke Tesseract beherrscht die schwarze Magiethematik der Normierung... ;)

Tesseract

2014-08-16, 16:08:57

Da wird es aber verdammt schwer entsprechende Spieletests zu finden wo beide Karten mit exakt 1Ghz getestet werden.

ich habe es selbst getestet als ich die gelegenheit hatte. es gibt aber tests wie den hier (http://ht4u.net/reviews/2013/nvidia_geforce_gtx_780_ti_gk110_complete_review/index42.php) wo man es zumindest erahnen kann weil mehrere versionen von verschiedenen karten mit drin sind.

dargo

2014-08-16, 16:20:18

Da komme ich nicht ganz mit. Was meinen die mit "gemittelter Takt" bei der R9 290?

Unicous

2014-08-16, 16:24:19

@Nakai

Da wird nichts zitiert, da wird nur spekuliert auf Basis des Teasers . Verstehe doch bitte dass WTF-TEch keine ernst zunehmende Seite ist und sich der eigene Content bzw. Quellen und Leaks im tiefstelligen Promille-Bereich befinden. Da stößt halt alles Schlechte der Gerüchte-Branche zusammen. Schreiberlinge die keine Ahnung haben, dafür aber wie besessen die Foren und IT-Seiten durchstöbern daraus schlecht recherchierte und geschriebene Artikel zimmern und dann nur äußerst sporadisch credit geben (*hust wobei sie da deutlich vorbildlicher sind, als so manche deutsche Seite:freak: hust*)

WTF-Tech ist das Buzzfeed/Huffington Post der IT-Seiten und schlimmer als FUDzilla. Und das will schon was heißen.

Tesseract

2014-08-16, 16:29:55

Da komme ich nicht ganz mit. Was meinen die mit "gemittelter Takt" bei der R9 290?
mit dem referenzkühler taktet die karte ständig rauf und runter um nicht in flammen aufzugehen. der unterschied zwischen dem quiet- und dem performance-bios auf der 290X beispielweise kommt nur durch dieses throttling zu stande (das setzt die maximale drehzahl um ein paar % höher afaik). der gemittelte takt liegt also in der regel leicht bis deutlich unter dem eigentlichen takt. mit einem ordentlichen kühler hingegen klebt die taktrate oben fest und dementsprechend höher ist auch die performance.

Duplex

2014-08-17, 13:49:14

Ich schaue vor allem bei gängige Auflösungen eingeschlossen 2560x1440 aber vor allem unterhalb, weil hier andere Karten nicht in ihrem VRAM-Limit landen. Und sicherlich gibt es Spiele, wo Hawaii gut skaliert(zB Crysis 3). Es gibt aber genug Spiele, wo Hawaii unverhältnismäßig schneller ist als Tahiti.
90% der Gamer spielen in FullHD mit 4AA und hier ist Hawaii >35% schneller gegenüber Tahiti, alles andere ist irrelevant.

Nicht vergessen, Hawaii ist trotz Quad Frontend nur 22,5% größer als Tahiti, die skalierung gegenüber Tahiti ist ganz gut.

dargo

2014-08-17, 14:01:08

90% der Gamer spielen in FullHD mit 4AA und hier ist Hawaii >35% schneller gegenüber Tahiti, alles andere ist irrelevant.

Das ist aber ein ziemlich falscher Ansatz. Je nach Game/Testszene/Details und CPU kann in dieser Auflösung bereits die CPU zum kleinen Flaschenhals werden. Und so hast du ein verfälschtes Bild was die Mehrleistung der Grafikkarte angeht.

Duplex

2014-08-17, 14:10:27

Fast alle Leute haben heute ein i5 oder i7 mit 4 Physische Kerne, da gibt es kaum noch Unterschiede bei der CPU skalierung.

M4xw0lf

2014-08-17, 14:12:57

dargo

2014-08-17, 14:15:34

Fast alle Leute haben heute ein i5 oder i7 mit 4 Physische Kerne, da gibt es kaum noch Unterschiede bei der CPU skalierung.
Das ist kein Grund um nicht im CPU-Limit unter Full-HD mit Hawaii zu landen.

Tesseract

2014-08-17, 14:24:34

Hier im 3dcenter vielleicht (und selbst hier gibts noch 20% AMD-Nutzer), aber das trifft doch lange nicht auf alle Spielerechner da draußen zu.

auf diejenigen, die eine graka in der performanceklasse ab tahiti haben wahrscheinlich schon.

M4xw0lf

2014-08-17, 14:33:58

auf diejenigen, die eine graka in der performanceklasse ab tahiti haben wahrscheinlich schon.
Schon eher, ja. Wobei es da sicher auch Phenom II- und FX-User gibt.

Leonidas

2014-08-17, 17:01:41

Fast alle Leute haben heute ein i5 oder i7 mit 4 Physische Kerne, da gibt es kaum noch Unterschiede bei der CPU skalierung.

Hier im 3dcenter vielleicht (und selbst hier gibts noch 20% AMD-Nutzer), aber das trifft doch lange nicht auf alle Spielerechner da draußen zu.

Was schadet es bei dieser Frage, auch mal auf die Hauptseite zu schauen ...
http://www.3dcenter.org/artikel/steam-survey-und-3dcenter-umfragen-im-vergleich

2 CPU-Rechenkerne oder mehr
Steam: 93,62%
3DC: 98,8%

4 CPU-Rechenkerne oder mehr
Steam: 45,84%
3DC: 86,0%

M4xw0lf

2014-08-17, 17:07:30

Was schadet es bei dieser Frage, auch mal auf die Hauptseite zu schauen ...
http://www.3dcenter.org/artikel/steam-survey-und-3dcenter-umfragen-im-vergleich

2 CPU-Rechenkerne oder mehr
Steam: 93,62%
3DC: 98,8%

4 CPU-Rechenkerne oder mehr
Steam: 45,84%
3DC: 86,0%

Genau das hatte ich dabei ja im Kopf, ich kenne die Hauptseite durchaus :tongue:

Leonidas

2014-08-18, 01:59:33

Wie Nakai schon sagt, nutzt HBM ein deutlich anderes Konzept: sehr breite und niedriger getaktete Interfaces, die zusätzlich durch die direkte, kurze Anbindung (sehr kleine Kapazität der Leitungen) deutlich weniger Leistung für die gleiche Bandbreite verbraten. Bei HBM heißt das also 1024Bit-Anbindung mit 500MHz, 1 GT/s double-data-Rate-Transfers (spezifiziert sind auch noch 0,8 GT/s und[das war wohl WideIO2] später kommt auch noch bis 2GT/s). Die PHYs sollten nicht mehr, bzw. tendentiell weniger Platz fressen als die für z.B. für ein 128Bit-7GBps GDDR5-Interface (bis 112GB/s verglichen mit den 128GB/s für einen HBM-Stack) und zusätzlich Strom sparen (Verbrauch nur grob nur halb soviel wird glaube ich öfter mal genannt).

Da muß ich nochmal nachhaken:

1024 Bit DDR mit 500 MHz sind *deutlich* weniger Bandbreite als 384 Bit DDR mit 3500 MHz: 128 GB/sec vs. 336 GB/sec. Ohne klar höhere Taktraten oder deutlich breitere Interfaces sehe ich den Sinn der Aktion (noch) nicht.

ndrs

2014-08-18, 02:10:56

Da muß ich nochmal nachhaken:

1024 Bit DDR mit 500 MHz sind *deutlich* weniger Bandbreite als 384 Bit DDR mit 3500 MHz: 128 GB/sec vs. 336 GB/sec. Ohne klar höhere Taktraten oder deutlich breitere Interfaces sehe ich den Sinn der Aktion (noch) nicht.
1024 Bit je Kanal bzw Speicherchip.
Das meiste müsste auch hier schonmal irgendwo erwähnt worden sein: http://www.forum-3dcenter.org/vbulletin/showthread.php?t=506896

Käsetoast

2014-08-18, 08:48:23

Also ich bin da der Meinung, dass die ganze HBM Diskussion müßig ist - bevor wir da irgendwelche abgefahrenen 4GB auf dem Chip mit hohem Takt Sachen sehen, wird man zuerst wohl APUs mit 512MB bis 1GB HBM Speicher sehen - die werden davon enorm profitieren und haben das eigentlich auch nötiger als Grafikkarten, zumal da eben nicht direkt Unmengen von hochgetaktetem Zeugs auf einen Chip klatschen muss wie bei einer High-End-GPU der Fall und solche kleineren Speichermengen sind dann auch nicht so exorbitant teuer...

Gipsel

2014-08-18, 10:27:43

Also ich bin da der Meinung, dass die ganze HBM Diskussion müßig ist - bevor wir da irgendwelche abgefahrenen 4GB auf dem Chip mit hohem Takt Sachen sehen, wird man zuerst wohl APUs mit 512MB bis 1GB HBM Speicher sehenWie schon mal geschrieben, ist die kleinste spezifiziert Größe 1 GB pro Stack. 512MB wären außerhalb des Standards.

HOT

2014-08-18, 12:31:25

Fiji kann nur dann HBM bekommen, wenn beispielsweise 4x4 Stacks verbaut sind. Weniger als 16GB sind für den Profimarkt schlicht inakzeptabel. Auch als Endnutzer möchte ich gerne 8 GB auf einer Fiji-Karte haben.

Nightspider

2014-08-18, 13:03:32

8GB werden wir auf jeden Fall bei Fiji sehen, da durch Mantle schon die 4GB oft komplett gefüllt sind.

Dural

2014-08-18, 13:13:17

OBrian

2014-08-18, 13:16:11

wie sieht das überhaupt mit den Kosten aus, die spielen ja üblicherweise die Hauptrolle, ob irgendwas Tolles eingeführt wird oder eben nicht.

Beim normalen DDR4 z.B. sind zwar jetzt die anfänglichen Kosten wie üblich etwas höher, aber längerfristig sind dort Kosteneinsparungen zu erwarten (einfacheres Routing, weniger Timingschwierigkeiten, weil die Parallelität wegfällt), gewisse Performancesteigerungen für APUs also relativ günstig.

Wenn man nun RAM auf den Chip stapelt, dann ist das sicher unbestreitbar technisch viel eleganter und verspricht großartige Performancesteigerungen, aber ist das auch sinnvoll bezahlbar? AMD wird ja einen Kaveri-Nachfolger mit HBM nicht für das doppelte verkaufen können, nur weil die integrierte GPU doppelt so schnell wird, das gäbe der Markt einfach nicht her. Oder kann man davon ausgehen, daß sich die Kosten praktisch gar nicht erhöhen (was an stacked RAM verbaut wird, muß man ja nicht als Steckmodul dazukaufen)?

Bei Grafikkarten könnte ich mir sogar vorstellen, daß die Produktion billiger wird, weil die Platine viel einfacher aufgebaut ist (es sind ja praktisch nur noch die PCIe-Lanes und die Stromversorgung auf der Platine, halbe Bauhöhe und nicht länger als der Slot würde auch für High-End-Karten ausreichen, wenn man da den Kühler befestigt bekäme).

Aber falls HBM hier nur ein Thema ist, weil es in dem bescheuerten WCF-Spekulatius-Artikel vermutet wurde: Die Zeile "was Lustiges, was interessante Zahlen produziert" bei Semiaccurate halte ich eher für die Andeutung irgendeines Features wie TressFX oder so, oder wild-dynamische Taktanpassungen, die das Benchmarketing noch realitätsferner machen, oder sowas. Muß nicht unbedingt eine Hardware-Sensation sein.

Akkarin

2014-08-18, 14:22:39

Nakai

2014-08-18, 22:09:42

Das absolute theoretische Limit bei ASML-Belichtern (wie von TSMC und Globalfoundries benutzt) liegt bei ~850mm² (26mm x 33mm reticle field size). Das wird aber wohl nie genutzt werden. Etwas über 700mm² ist praktisch gesehen vermutlich ziemlich das Ende der Fahnenstange.

Um mal darauf hier zu antworten.

sushiwarrior meinte zu Fiji (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=10314583#post10314583):

Fiji will be something new and different, with respects to memory config. Big die.

By different memory config I don't mean HBM necessarily. I said BIG die. 550mm^2 doesn't hold a candle to it.

Deutlich größer als 550mm². Eher schon 650mm²+.
Nicht unbedingt HBM, aber ein anderes Speichersystem.

Also kein klassisches GDDR5-System, wie bei Hawaii.

Ich zähl mal auf, was es sein könnte:
- Hybrid zwischen HBM und GDDR5/DDR4 (mein Favorit)
- fette Caches (8MB L2-Cache+)
- EDRAM (extrem unwahrscheinlich)
- Daughter Die für MCs (!?)

Hat jemand noch irgendwelchen wirren, aber machbaren, Ideen? :freak:

Hübie

2014-08-18, 22:15:48

Einfach zwei memory-pads ;)

Akkarin

2014-08-18, 22:29:17

Auf SA wurde afaik ein Vortrag zu PIM geposted bei dem CUs in den logic die unter den HBMs eingebaut waren. Das wäre sowohl "big die" (obwohl eigentlich eher mehrere), eine sehr ungewöhnliche speicherarch die nicht unbedingt das selbe wie HBM ist.

Hübie

2014-08-18, 22:48:11

Ein link wäre nicht schlecht gewesen ;)

Akkarin

2014-08-18, 23:37:28

Ka, irgendwo im SA forum, da muss ich auch erst rumkramen

edit: ok, war doch relativ einfach zu finden: http://www.dongpingzhang.com/wordpress/wp-content/uploads/2012/04/TOP-PIM_v6_public.pdf

Hübie

2014-08-18, 23:38:38

:P Also hier am Blödphone machts keinen Spaß. Wäre also wirklich freundlich von dir ;)

Unicous

2014-08-19, 00:00:35

Da gehts um Exascale (High Performance) Computing und das steht sicherlich im Zusammenhang mit der Fastforward/DesignForward Initiative.

Einigermaßen passend zum Zeitrahmen habe ich das hier gefunden:

https://www.nersc.gov/research-and-development/design-forward/design-forward-july-22-24-2014/

Ende Juli gab es ein Treffen der üblichen Verdächtigen im Lawrence Berkeley National Laboratory und man hat sich über Exascale Computing und das Gedöns drumherum ausgetauscht.

Schöner Gedanke, hat aber eher nichts mit Fiji zu tun.

OBrian

2014-08-19, 00:36:23

Mit "big die" meint er ja bestimmt das Teil, was er sieht (er hat wohl auf ein ES geguckt), das muß aber nicht das Logic-Die sein, sondern evtl. der Interposer, siehe http://www.hardwareluxx.de/images/stories/newsbilder/tfreres/HBM-Memory.JPG
wie man sieht, ist da ein ziemlicher Flächenbedarf, um die RAM-Stacks NEBEN die normale GPU zu kleben (deswegen "2.5D"). Der Interposer ist ja auch aus Silizium, und wenn die das Stacken nach unten machen (flip chip eben), dann sieht man nur die riesige Unterseite.

So ein "fetter Die" wäre ja gar nicht so teuer, weil man erstens wohl schlechtere Wafer nehmen kann (keine mit abgereichertem SI-28 usw.), es sind ja keine hochgetakteten Transistoren darin verbaut, sondern nur Leitungen, und zweitens ist auch der Fertigungsaufwand für diesen Wafer nicht hoch, man kommt wohl mit wenigen billigen Schichten hin, womit der Quadratmillimeter Interposer relativ billig ist und man somit auch problemlos mit der Fläche aasen kann, brauchbare Ausbeute liegt wohl trotzdem bei praktisch 100%. Wird wahrscheinlich in deutlich älterer Fertigungstechnik hergestellt, 180 nm täten es wohl locker.

Nur die kleineren "Unter-Dies" müssen in der schweineteuren High-End-Technik gefertigt werden: eine GPU mit 400mm² oder so und 2 oder 4 RAM-Stacks.

Die Präsentation zu PIM ist auch interessant, aber das könnte auch erst der zweite Schritt sein. Die Stacks mit Logik drunter muß man ja weiterhin irgendwie zusammenkleben, braucht also auch einen Interposer. Außerdem sieht das mehr nach APU-Ausrichtung aus, bei 10W pro PIM könnte man die GPU eines Kaveri zerteilen auf einige Stacks, aber keine größer-als-Hawaii-GPU mit 200-300 W auf eine halbe Handvoll Stacks verteilen.

Außerdem ist die Präsentation von diesem Sommer, aber üblicherweise kommen Produkte mit Technologien, die in Folien vorkommen, erst 1-2 Jahre später auf den Markt (frühestens). Da steht ja auch "bei 22nm 27% weniger Performance, bei 16nm 7% mehr", also ist das wohl was für 16nm.

Leonidas

2014-08-19, 08:15:13

1024 Bit je Kanal bzw Speicherchip.
Das meiste müsste auch hier schonmal irgendwo erwähnt worden sein: http://www.forum-3dcenter.org/vbulletin/showthread.php?t=506896

Dies ändert das ganze natürlich. Das würde aber auch bedeuten, daß auf dem Grafikchip dann beispielsweise ein 4096-Bit-Interface rumgurken müsste. Kann man das wirklich kleiner hinbekommen als ein 384 Bit GDDR5 Interface?

Hübie

2014-08-19, 08:33:44

Also ich sage entweder mehr LLC (vielleicht sogar eine dritte Stufe, aber das macht bei streaming afaik nicht soviel Sinn) oder halt 2*512 Bit Interface. HBM und so ist noch eher Spielkram ausm Labor. Vor allem dass Hitzeproblem bei PIM (long term) ist noch in den Griff zu bekommen.

Skysnake

2014-08-19, 09:08:43

Braucht es den im Moment mehr Bandbreite?

Mit 512Bit und GDDR5 1750MHz sind immerhin schon 450GB/s möglich.
Zudem zeigt Maxwell ganz klar das man auf der Chip Seite AMD noch massives potential haben sollte.
Von mir ausgesehen ist das in 28nm Spielzeug, ab 16nm könnte das sicher interessant werden.
Man hat NIE genug Bandbreite zum Speicher ;)

Seit den ersten Tagen des Computers entwickelt sich die Speicherbandbreite langsamer als die Rechenperformance. Das hat ja unter anderem zum Aussterben der Vektorrechner usw geführt.

Speicherbandbreite ist nur durch eins zu ersetzen, mehr Speicherbandbreite :D

Damit kann man eben immer seine Performance abrufen. Bei Caches hat man immer so ein kleine Lotterie. Entweder es funktioniert, oder eben nicht. Die Probleme müssen sich fürs Caching eigenen, was sehr viele tun, aber eben nicht alle.

wie sieht das überhaupt mit den Kosten aus, die spielen ja üblicherweise die Hauptrolle, ob irgendwas Tolles eingeführt wird oder eben nicht.

Beim normalen DDR4 z.B. sind zwar jetzt die anfänglichen Kosten wie üblich etwas höher, aber längerfristig sind dort Kosteneinsparungen zu erwarten (einfacheres Routing, weniger Timingschwierigkeiten, weil die Parallelität wegfällt), gewisse Performancesteigerungen für APUs also relativ günstig.

Wenn man nun RAM auf den Chip stapelt, dann ist das sicher unbestreitbar technisch viel eleganter und verspricht großartige Performancesteigerungen, aber ist das auch sinnvoll bezahlbar? AMD wird ja einen Kaveri-Nachfolger mit HBM nicht für das doppelte verkaufen können, nur weil die integrierte GPU doppelt so schnell wird, das gäbe der Markt einfach nicht her. Oder kann man davon ausgehen, daß sich die Kosten praktisch gar nicht erhöhen (was an stacked RAM verbaut wird, muß man ja nicht als Steckmodul dazukaufen)?

Der Punkt ist hier einfach, das keiner so etwas produziert, also weiß man nie 100% genau, wie sich das in der Massenfertigung dann wirklich schlägt. Xilinx musste mit Interposer ja einige bittere Erfahrungen machen. Da wird ja jetzt bald 2 Jahre schon mit gearbeitet. Man kann also an sich immer sicherer sein, das endlich auch andere die Technologie nutzen, da man die Sache immer besser in den Griff bekommen wird.

Bei Interposer ist DER Kostenfaktor halt das Packaging. Da kannste noch alles kaputt machen. Wenn das schief gehst, kann die ganze Packung in die Tonne treten.... Das muss also sehr gut kontrollierbar sein. Wie gut das aber am Ende wirklich geht, kann dir wohl keiner sagen außer Xilinx.

Der Punkt ist ja auch, dass das eigentliche organische Package deutlich einfacher wird! Und da wird ja auch einiges an Ausschuss produziert. Also alles nicht so einfach zu beantworten, was da jetzt wo und wie mehr oder weniger Geld kostet.

Bei Grafikkarten könnte ich mir sogar vorstellen, daß die Produktion billiger wird, weil die Platine viel einfacher aufgebaut ist (es sind ja praktisch nur noch die PCIe-Lanes und die Stromversorgung auf der Platine, halbe Bauhöhe und nicht länger als der Slot würde auch für High-End-Karten ausreichen, wenn man da den Kühler befestigt bekäme).

Ja, das ist so. Das PCB und wie gesagt sogar das Package werden extrem viel einfacher. Das schnellste Signal, was da dann noch drüber geht ist PCI-E und eben Display, das wars dann aber auch schon, und wirklich viele Leitungen sind das dann nicht mehr im Vergleich zu nem fetten 256+Bit GDDR5 Interface.

Um mal darauf hier zu antworten.

sushiwarrior meinte zu Fiji (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=10314583#post10314583):

Deutlich größer als 550mm². Eher schon 650mm²+.
Nicht unbedingt HBM, aber ein anderes Speichersystem.

Also kein klassisches GDDR5-System, wie bei Hawaii.

Ich zähl mal auf, was es sein könnte:
- Hybrid zwischen HBM und GDDR5/DDR4 (mein Favorit)
- fette Caches (8MB L2-Cache+)
- EDRAM (extrem unwahrscheinlich)
- Daughter Die für MCs (!?)

Hat jemand noch irgendwelchen wirren, aber machbaren, Ideen? :freak:
Interposer wäre noch eine Möglichkeit, die aber auch schon genannt wurde.

Was allerdings auch noch möglich wäre, wovon ich aber nicht ausgehe, ist ein 600mm²+ DIE. Ich habe neulich einen Vortrag gehört, in dem ein Wafersize DIE produziert/genutzt wird.

Da wird ganz normal der Wafer belichtet usw, dann am Ende aber nicht alles auseinanderegsägt, sondern nochmals durch eine FabLine geschickt, die dann die einzelnen DIEs auf dem Wafer durch eine Metallage miteinander verbindet. Man hat dann am Ende wirklich EINEN Chip von der größe eines Wafers :eek::biggrin:

Das man so groß wird, glaub ich nicht, wäre ja auch verdammt unhandlich, aber 2-4 "normale" DIEs könnte man schon miteinander verbinden.

So Recht dran glauben kann und will ich aber nicht, weil man dann eben noch kein Speicherinterface hat, und wenn dann eben eDRAM oder SRAM nutzen müsste in Massen, und das beim teuren Logik Prozess..

Also wenn, dann eher eine Interposerlösung.

Da gehts um Exascale (High Performance) Computing und das steht sicherlich im Zusammenhang mit der Fastforward/DesignForward Initiative.

Einigermaßen passend zum Zeitrahmen habe ich das hier gefunden:

https://www.nersc.gov/research-and-development/design-forward/design-forward-july-22-24-2014/

Ende Juli gab es ein Treffen der üblichen Verdächtigen im Lawrence Berkeley National Laboratory und man hat sich über Exascale Computing und das Gedöns drumherum ausgetauscht.

Schöner Gedanke, hat aber eher nichts mit Fiji zu tun.
Ja, daran musste ich auch denken, wobei das nochmal etwas abweicht von dem anderen forward Sachen.

Dort wurde inMemory Computing ja auch erwähnt, das man also quasi die CUs in den Speicher packt, und nicht den Speicher über den Compute Part.

Die inMemory Sache ist auch durchaus interessant. Man würde halt die Daten möglichst nicht mehr zu den Compute-Einheiten schicken, sondern die Compute-Einheiten zu den Daten. Man würde also z.B. 100 CUs implementieren, aber eben im Normalfall nur 40-80 laufen lassen, weil die Daten einfach verteilt sind.

Das ist ein interessanter Ansatz, weil eben das hin und her schicken teurer ist als die eigentliche Berechnung, und Power-/Clock-Gateing hat man heute gut drauf. Man würde also massiv Fläche für meist nicht genutzte Einheiten raus ballern, um die Effizienz massiv zu steigern.

Dies ändert das ganze natürlich. Das würde aber auch bedeuten, daß auf dem Grafikchip dann beispielsweise ein 4096-Bit-Interface rumgurken müsste. Kann man das wirklich kleiner hinbekommen als ein 384 Bit GDDR5 Interface?
Ja, kann man davon ausgehen, weil man im Optimalfall eigentlich gar keine fetten Ausgangstreiber mehr braucht.

Das SI würde damit quasi komplett wegfallen Das ist schon sehr sexy

Dural

2014-08-19, 09:24:27

sehe ich etwas anders, gerade im Spiele Bereich gibt es so gut wie bei jeder Karte eine Schwelle wo mehr Bandbreite kaum noch was bringt, und wenn man über dieses geht ist doch jedes GB/s zu schade (Kosten, Verbrauch)

Im Profibereich mag das anderes Aussehen, die meisten Chips werden aber immer noch im Gamer-Markt Verkauft. :wink:

Skysnake

2014-08-19, 10:12:22

Man darf hier Ursache und Wirkung nicht miteinander wechseln.

Die Software die man hat, wird ja immer! um die bestehenden Limitierungen drum herum gestrickt. Hätten wir mehr Bandbreite und auch mehr Speicher, würden die Auflösungen von Texturen usw tendenziell hoch gehen.

Klar kann man jetzt sagen, dass das nicht passieren wird, weil das Artdesign zu teuer werden würde, aber dem kann ich nur bedingt zustimmen.

Schaut euch doch mal an, was auf der einen Voxelengine gemacht wurde, oder auch diesem einen Spiel, das "einfach" Räume/Gebiete digitalisiert. Das ist doch an sich nur nicht umsetzbar, weil man eben zu wenig Speicher und Bandbreite hat.

Wenn man alles abfilmt, wäre Artdesign für realistische Welten gut machbar. Nur würde das eben nur auf großen Cluster mit 1 FPS laufen ;)

fondness

2014-08-19, 12:36:42

Videochardz bestätigt das am 23. Tonga vorgestellt wird, und vielleicht auch ein bisschen mehr ;)

AMD to unveil Radeon R9 285 on August 23rd
http://videocardz.com/51246/amd-unveil-radeon-r9-285-august-23rd

http://s15.postimg.org/dyt9zb8dn/evolution_of_amd_gpus.jpg (http://postimg.org/image/pnx9n9zc7/full/)

Dural

2014-08-19, 13:03:59

lustiger Stammbaum :wink:

4890 erste 1GHz GPU, ehm ja :freak:

Unicous

2014-08-19, 13:18:10

Ach Dural. Die HD 4890 war die erste GPU von der es reguläre 1 GHz SKUs gab. Ich wüsste nicht was es da Abschätziges zu zu sagen gibt.

Es geht da nicht um OC sondern um eine käuflich zu erwerbende Grafikkarte.

Hauptsache wieder gemeckert, was?

Nakai

2014-08-19, 13:22:48

lustiger Stammbaum :wink:

4890 erste 1GHz GPU, ehm ja :freak:

http://www.tweakpc.de/hardware/tests/grafikkarten/xfx_radeon_hd_4890_black_edition_1_ghz_gpu/s01.php

http://www.pcgameshardware.de/Grafikkarten-Grafikkarte-97980/Tests/Grafikkarten-Test-auf-PC-Games-Hardware-688430/

Es gab 1 GHz Partnermodelle, mehr aber auch nicht. 1 GHz wurde imo erst mit HD7xxx-Serie vollständig geknackt.

Ich hoffe ja auf ein neues GPU-Triplet/Triumvirat. GCN Ver1 hat das ja mit Capeverde, Pitcairn und Tahiti gebracht. Pitcairn und Tahiti fliegen raus. Hawaii ist nur ein Refresh, ergo muss da ein bisschen was kommen. Auch Bonaire und Capeverde müssten ersetzt werden, da ineffektiv. Mal gucken wie Island aussieht.

Fiji
Bermuda/Maui
Tonga
Island

Ahja, zur Timeline:
Was gut dazu passen würde, wäre, wenn sich AMD als Erster im HBM- oder StackedRAM-Bereich profiliert. Würde gut hierzu passen.

Hübie

2014-08-19, 13:23:14

Wo hat er gemeckert? Lesen wir unterschiedliche Texte? :| Die HD 4890 gab's afaik nur von Dritten mit 1000 Mhz. ATi spezifizierte die auf 993 oder so. Okay is Korinthenkackerei...

fondness

2014-08-19, 13:24:09

Ahja, zur Timeline:
Was gut dazu passen würde, wäre, wenn sich AMD als Erster im HBM- oder StackedRAM-Bereich profiliert. Würde gut hierzu passen.

Ich hoffe das am 23. auch ein Sneak Peak in die Zukunft oder vielleicht sogar eine kleine Roadmap drin ist...

Dural

2014-08-19, 13:36:37

die 4890 hatte 850MHz ;) zudem gibt es noch andere Sachen die nicht wirklich stimmen.

Was OC Karten gemacht haben tut wohl nichts zur Sache, den ich hatte selber mit der 3870 schon über 1GHz Takt :P

Unicous

2014-08-19, 13:39:06

Wo hat er gemeckert? Lesen wir unterschiedliche Texte? :| Die HD 4890 gab's afaik nur von Dritten mit 1000 Mhz. ATi spezifizierte die auf 993 oder so. Okay is Korinthenkackerei...

Dafür, dass AMD damit nichts zu tun hatte, haben sie damit aber ganz schön angegeben.

AMD Delivers the World's First 1 GHz Graphics Processor (http://ir.amd.com/phoenix.zhtml?c=74093&p=irol-newsArticle&ID=1304747&highlight=)

With this product, AMD achieves a notable engineering milestone as the first graphics company to break the 1 GHz barrier.

This new version of the ATI Radeon™ HD 4890 marks the latest addition to the award-winning ATI Radeon™ HD 4000 series delivered by AMD technology partners Sapphire, XFX, Asus and TUL.

Vllt. aber nur vllt. hatte ja AMD doch etwas damit zu tun.

@Dural

:facepalm:

Natürlich tut OC nichts zur Sache. Wenn wir danach gehen hat AMD eine 8794 Ghz CPU.

Und erleuchte uns. Was stimmt denn laut DIR noch so alles nicht.

Nakai

2014-08-19, 14:40:42

Ich hoffe das am 23. auch ein Sneak Peak in die Zukunft oder vielleicht sogar eine kleine Roadmap drin ist...

Wenn HMC oder HBM kommt, dann kann man mit mindestens 500GB/s rechnen, sonst macht ein solcher Aufwand keinen Sinn.

Hynix liefert pro Stack ~128GB/s und 1GB RAM. Bei 4 Stacks wären das 4GB und ~512GB/s.

Micron liefert HMCs mit 4 GB Volumen bei einer Bandbreite von 120~160GB/s.

Da AMD aber mit Hynix zusammenarbeitet, kann man eigentlich nur 2 Optionen vermuten:
HBM oder 3DS

Interessant bei 3DS ist, dass anscheinend die bestehende Infrastruktur bestehen bleibt und kein TSV benötigt wird, da der RAM auf den Chip kommt.

ndrs

2014-08-19, 15:40:19

Wofüs soll die Abkürzung 3DS stehen? Und wie wird der RAM auf dem Chip dann verbunden? (Ehrlich gemeinte Fragen)

Nakai

2014-08-19, 15:43:53

Wofüs soll die Abkürzung 3DS stehen? Und wie wird der RAM auf dem Chip dann verbunden? (Ehrlich gemeinte Fragen)

Hups, mein Fehler. Mit 3DS meinte ich Stacked RAM, also direkt auf den Chip gestacked.

HBM kann über ein TSV laufen, ergo es wird noch ein weiterer Siliziumträger benötigt.

Mit 3DS meinte ich das:
http://electroiq.com/blog/2013/12/amd-and-hynix-announce-joint-development-of-hbm-memory-stacks/

Ob das für GPUs nutzbar wäre, wäre interessant. Für HBM wird direkt Graphics erwähnt.

Unicous

2014-08-19, 16:46:32

Interessante Überlegung, und ich glaube wir hatten schon einmal darüber gesprochen aber eine Sache macht es für mich eher unwahrscheinlich. Wie willst du das ganze kühlen ohne den RAM zu schmelzen.

Auch sehr, sehr unwahrscheinlich aber nachdem von einem großen Die gesprochen wird und neuer Memory Config werfe ich das mal in den Ring

49338
49337

Aus den AMD "Die Stacking is happening" slides von Bryan Black

All similar technology components have been integrated such as Cache, FPU, Multi-Media, NB,
GPU, SB, etc…
Only disparate technologies such as DRAM, MEMS, True IVR, Storage, Optics are left
Process scaling will to stop supporting diverse functionalities on a single die such as fast logic,
low power logic, analog, and cache
The single die will want to break into specialized components to maximize the value of new and existing process nodes
Process complexity is increasing and yield is dropping as mask count increases
Large die sizes will continue to have yield challenges

49339

http://www.microarch.org/micro46/files/keynote1.pdf

Ein "großer" Interposer mit kleineren Dies um den Yield zu verbessern und dadurch Kosten zu verringern und dennoch eine größere Bandbreite erreichen indem man den RAM in welcher Art auch immer auf dem Interposer platziert denn:

And... BW is limited by the off die interface which doesn’t scale quickly
But… off die BW demand increases with transistor density

Aber das ist schon sehr weit hergeholt.:tongue:

Nakai

2014-08-19, 17:04:09

Interessante Überlegung, und ich glaube wir hatten schon einmal darüber gesprochen aber eine Sache macht es für mich eher unwahrscheinlich. Wie willst du das ganze kühlen ohne den RAM zu schmelzen.

Das habe ich absichtlich nicht erwähnt. Über den RAM mach ich mir weniger Sorgen, der ist ganz oben. Die GPU hingegen liegt in einem kleinem Sandwich und da befürchte ich eher Probleme. Ahja, ich geh eher davon aus, dass maximal eine RAM-Schicht darüber gestackt ist, weswegen ein großer Die nicht nachteilig wäre. Um die Kühlungsproblematik, wegen "Irregular Shapes" zu negieren, müssten der StackedRAM die gleiche Fläche, wie Fiji besitzen.
Hierzu könnte man sich zwei Packages überlegen. Ein Package mit 512Bit GDDR5 für StandardRAM und ein Package mit zusätzlichem StackedRAM auf der Haube, als "Cache" oder schnellen Speicher.

Derzeitige GDDR5-Größe ist bei 384Bit bei 12GB und bei 512Bit bei 16GB beschränkt(afaik, da ein GDDR5-Chip in 16Bit bzw 32Bit angesprochen werden kann). GDDR5-Chip gibt es derzeit in 4Gb und 2Gb-Versionen.
Hawaii hat zB 8mal 2x32Bit MCs, ergo 16 GDDR5-Chips -> 4GB(2Gb) o. 8GB(4Gb). Laufen die GDDR5-Chips im 16Bit-Modus sind sogar 16GB möglich(vorne 16 Chips, hinten auch).

Für die nächste Gen sind definitiv mehr als DAS notwendig, aber mit GDDR5 wird das nicht mehr möglich sein. Wenn AMD eine Lösung bringt, den Speicher weiter hochzuskalieren, wäre das ein immenser Vorteil. NV hat derzeit max 12GB wegen ihrem 384Bit SI.

Auch sehr, sehr unwahrscheinlich aber nachdem von einem großen Die gesprochen wird und neuer Memory Config werfe ich das mal in den Ring

Das macht aber nur Sinn, wenn es nicht nur eine GPU benötigt bzw. nicht nur ein Modell gibt. Damit wäre es möglich, mit einem Die bzw. wenigen Dies über die gesamte Produktlinie zu skalieren. Hinsichlich dieser Sache, werden neuere Herstellungsverfahren erwähnt und kein 28nm.
Das könnte in Zukunft sehr interessant sein, aber zuerst sollte Memory-Stacking kommen. Logic-Stacking wird noch ein ganz anderes Kaliber sein.

Unicous

2014-08-19, 17:09:02

Da steht "new and existing", nur mal so als Korinthenkackerei.:tongue:

Leonidas

2014-08-19, 17:32:40

Ja, kann man davon ausgehen, weil man im Optimalfall eigentlich gar keine fetten Ausgangstreiber mehr braucht.

Das SI würde damit quasi komplett wegfallen Das ist schon sehr sexy

In eine andere Formulierung übersetzt: Ein HBM-Interface benötigt kein eigentliches Speicherinterface mehr, sondern faktisch nur noch die Anschlüsse (Pins) selber. Der ganze komplizierte, stromfressende Teil des Interfaces würde wegfallen.

Richtig formuliert?

Videochardz bestätigt das am 23. Tonga vorgestellt wird, und vielleicht auch ein bisschen mehr ;)

AMD to unveil Radeon R9 285 on August 23rd
http://videocardz.com/51246/amd-unveil-radeon-r9-285-august-23rd

Videocardz spekuliert es. AMD hat keinen Ton hierzu gesagt. Und wahrscheinlich ist es auch nicht gerade - nicht am Ende einer 4h-Veranstaltung.

Distroia

2014-08-19, 18:02:46

Mal ne ganz doofe Frage: Mit HBM ist der Hybrid Memory Cube gemeint? Ich wundere mich, weil der eigentlich HMC abgekürzt wird. HBM steht laut Google für alles mögliche, aber nicht für den Hybrid Memory Cube.

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

M4xw0lf

2014-08-19, 18:03:59

Distroia

2014-08-19, 18:07:20

High Bandwidth Memory - http://www.jedec.org/standards-documents/docs/jesd235

Achso, danke. Dann muss ich wohl die letzten Seiten nochmal lesen. :freak:

OBrian

2014-08-19, 18:14:21

Gipsel

2014-08-19, 18:41:52

In eine andere Formulierung übersetzt: Ein HBM-Interface benötigt kein eigentliches Speicherinterface mehr, sondern faktisch nur noch die Anschlüsse (Pins) selber. Der ganze komplizierte, stromfressende Teil des Interfaces würde wegfallen.

Richtig formuliert?Na vielleicht nicht gleich komplett wegfallen (irgend etwas muß ja die an die Speicherstacks geschickten Signale noch erzeugen, das ist schon noch etwas mehr als gerade mal den benachbarten Transistor zu schalten), aber signifikant kleiner und stromsparender werden. Man braucht keine "fetten Ausgangstreiber" mehr, wie Skysnake sagte, sondern nur sehr kleine Treiber, ganz grob vergleichbar mit denen, die Signale von einem Ende des Dies zum anderen Ende schicken müssen. Bei einer HBM-Interposer-Lösung muß man ja nur durch die TSVs auf den Si-Interposer (die Leitungen da verhalten sich ja praktisch identisch wie auf dem eigentlichen Logikchip, es bleibt in diesem Sinne on die) und von dort wieder zum DRAM-Stack. Die Wegstrecke beträgt also insgesamt vielleicht 10-15mm maximal, dazu kommen noch die Mikrobumps (die kleinen Lötstellen mit 50µm Abstand oder was gerade aktuell ist) und TSVs als Barrieren. Das ist elektrisch gesehen bei 1-2 GBps deutlich günstiger als Speicherchips irgendwo auf dem PCB (Die=>Bumps=>Package-PCB=>Bumps=>Karten-PCB=>Bumps=>Speicherchip) bei 7GBps.

Das Problem ist einfach, daß der Energie- und Platzaufwand (für die Treiber auf dem Die) für höhere Geschwindigkeiten pro Datenleitung sehr stark nichtlinear ansteigt. Die ungünstigen Eigenschaften der Kontakte auf dem Weg machen es nur schlimmer. Für HBM/TSV können µBumps genutzt, die nicht nur deutlich kleiner sind, sondern auch geringere Kapazitäten aufweisen. Momentan limitiert schlicht, wie klein man die µBumps technisch machen kann, nicht die Treibergröße (wie bei GDDR5) die benötigte Kontaktfläche.

Um mal ein paar Zahlen zu nennen:
Für HBM spezifiziert die JEDEC (bei den Speicherstacks; auf dem Logikdie kann das Layout natürlich anders/enger sein, wenn man die Fertigung beherrscht, die JEDEC hat sicher konservative Vorgaben für die Stacks gemacht, die jeder locker schafft) ein Layout der µBumps mit einer Dichte von 379 Kontakten pro mm². Die Treiber für ein 6-7GBps-GDDR5-Interface nehmen etwa 7-8mm² pro 64Bit-Anbindung (bei Tahiti sind es gar ~10mm²) ein (davon natürlich 64 Highspeed-Datenleitungen, dazu einer Handvoll Taktsignale, der Rest ist etwas langsamer und benötigt demzufolge auch weniger Platz). Auf 8mm² bekommt man aber etwas mehr als 3000 Kontakte im HBM-Layout unter. Für das Interface auf dem Logikdie für einen Stack benötigt man aber keine 1500 (habe jetzt keine Lust, die in der Spezifikation nachzuzählen, um die genaue Anzahl rauszubekommen, am HBM-Stack gibt es natürlich mehr, allein für die Stromversorgung). Das heißt also im Prinzip, daß man vermutlich die Kontakte für 2 HBM-Stacks (mit 256 bis 512 GB/s Bandbreite) auf der Fläche eines 64Bit-GDDR5-Interfaces (mit um die 50GB/s Bandbreite) unterbekommen dürfte.

Nightspider

2014-08-19, 18:47:09

HBM bzw. HMC kann man immer noch auf die Unterseite des DIEs packen, wenn oben zu wenig Wärme durchkommt.

Intels Core M hat auch auf der Unterseite des Packages weitere Chips und nur am Rand des Packes die Pins, welche gezwungenermaßen enger beieinander liegen müssen.

Bei einem großen ~500-600mm² Chip wäre die Fläche groß genug den RAM auf die Unterseite der GPU zu verfrachten und außen daneben die Pins. Schließlich gibt es durch HBM/HMC auch weniger Pins zur Platine selbst.

Leonidas

2014-08-19, 18:53:56

Na vielleicht nicht gleich komplett wegfallen (irgend etwas muß ja die an die Speicherstacks geschickten Signale noch erzeugen, das ist schon noch etwas mehr als gerade mal den benachbarten Transistor zu schalten), aber signifikant kleiner und stromsparender werden.

...

Das heißt also im Prinzip, daß man vermutlich die Kontakte für 2 HBM-Stacks (mit 256 bis 512 GB/s Bandbreite) auf der Fläche eines 64Bit-GDDR5-Interfaces (mit um die 50GB/s Bandbreite) unterbekommen dürfte.

Danke, das ist doch mal Klartext.

Faktisch bekommt man also das 5fache bis 10fache an Speicherbandbreite auf gleicher Die-Fläche unter (wenn nicht so viel benötigt wird, sinkt die Chipfläche entsprechend). Zudem sinkt der Stromverbrauch des Speicherinterfaces selbst bei gleicher Chipfläche.

OBrian: Ich meinte es eher auf den Grafikchip selber bezogen. Das das Board massiv einfacher wird, ist klar.

OBrian

2014-08-19, 19:07:27

naja, die Chipfläche steigt schon deutlich, jedenfalls wenn man den Interposer betrachtet bei einer "2.5D"-Lösung, d.h. wenn der RAM neben die GPU gepackt wird. Aber das muß nicht unbedingt schlimm sein, denn die Teile werden ja einzeln produziert, in wahrscheinlich auch verschiedenen Fertigungsverfahren, und dann erst zusammenge"klebt", d.h. die Ausbeute kann durchaus hoch sein.

Also mal spekuliert, ein 400-mm²-Chip wird vielleicht nur noch 380 mm² groß (in einer GPU sind ja die Speichercontroller nur ein kleiner Teil der Gesamtfläche, d.h. den auf ein Zehntel zu schrumpfen, halbiert nicht gleich den ganzen Chip), aber daneben muß man die RAM-Stacks addieren. Keine Ahnung, wie groß die werden, aber da könnte durchaus nochmal die gleiche Fläche dazukommen wie die GPU selber.

Gipsel

2014-08-19, 19:11:44

Faktisch bekommt man also das 5fache bis 10fache an Speicherbandbreite auf gleicher Die-Fläche unter (wenn nicht so viel benötigt wird, sinkt die Chipfläche entsprechend).Das ist jetzt etwas zu simplifiziert, weil es nur für die Fläche der PHYs stimmt.
Allerdings gibt es ja auch noch einen Logikteil des Speichercontrollers, der anders skaliert. Grund ist, daß es mit HBM einfach relativ gesehen mehr Speicherkanäle gibt, die irgendwie angesteuert werden wollen (bzw. in etwa gleich viele bei konstanter Bandbreite). Ein HBM-Stack besitzt ja acht unabhängige Kanäle, die jeweils 256Bit (128Bit breit, Prefetch 2 da DDR) pro logischem Transfer übertragen, das entspricht also exakt acht 32bit GDDR5 (prefetch 8bit) Chips, mithin einem 256Bit GDDR5-Interface. Der Teil des Speichercontrollers dürfte also bei gleicher Bandbreite in etwa gleich groß bleiben. Allerdings ist das bei GDDR5 der deutlich kleinere Teil, er gewinnt aber mit HBM merklich an Bedeutung.

@OBrian:
Die Die-Fläche für die RAM-Chips mußt Du immer irgendwie bezahlen, egal ob die auf dem Interposer sitzen oder separat auf dem PCB in eigenen Packages. Statt GDDR5-Chips kauft man halt HBM-Stacks von den Speicherherstellern ;).

Wirklich als Kostenpunkt dazukommen tut der Interposer (der zwar groß ist, aber in alten Nodes [etwa 90nm] produziert werden kann, die nur einen Bruchteil der Kosten wie z.B. der 20nm-Prozeß aufweisen, zumal ist da außer ein paar Leitungen kaum was drauf, Yield geht also in Richtung 100%) und die Kosten für die Herstellung der TSVs und auch das deutlich kompliziertere Assembling mit den µBumps zum Kontaktieren durch die TSVs. Letzteres war bisher der bremsende Kostenfaktor (niedrige Yields, es ist halt nicht so einfach tausende, nur wenige zehn µm voneinander entfernte Lötkontakte zuverlässig herzustellen).

ndrs

2014-08-19, 20:03:38

Bei einem großen ~500-600mm² Chip wäre die Fläche groß genug den RAM auf die Unterseite der GPU zu verfrachten und außen daneben die Pins. Schließlich gibt es durch HBM/HMC auch weniger Pins zur Platine selbst.
Dann müsstest du aber die >1024 Datenleitungen eines HBM durch das Package führen und nicht wie geplant über den Si-Interposer. Das wird wohl kaum machbar sein. Und dann willst du ja nicht nur einen HBM.
HBM kann über ein TSV laufen, ergo es wird noch ein weiterer Siliziumträger benötigt.

Mit 3DS meinte ich das:
http://electroiq.com/blog/2013/12/amd-and-hynix-announce-joint-development-of-hbm-memory-stacks/

Ah, danke für den Link. Den hatte ich schonwieder ganz vergessen :)
Du verwexelst aber glaube ich grad TSV (Through Silicon Via, also das was du so ziemlich immer beim stacking brauchst) mit dem Si-Interposer.

Ob das für GPUs nutzbar wäre, wäre interessant. Für HBM wird direkt Graphics erwähnt.
Ich glaube da geht es eher darum, die Dinger auf normale RAM-Riegel zu pflanzen, also eher nix für GPUs.

Askingar

2014-08-19, 20:08:07

Zudem sinkt der Stromverbrauch des Speicherinterfaces selbst bei gleicher Chipfläche.
Wobei die Temps steigen. Gerade bei höheren Speichertaktraten wird das Die wohl zusätzlich aufgeheizt.

HBM macht eher im Bereich hochkomplexer GPGPU-Berechnungen Sinn und dann wenn riesige Speicherkapazitäten benötigt werden. Sehe ich bei den Desktops GPUs nicht, dort düften auf Dauer erstmal 8GB VRam reichen. Da könnte daher auch ala GDDR6 womöglich ausreichen. HBM dann eher als high-bandwidth-cache.

Skysnake

2014-08-19, 20:08:28

OBrian

2014-08-19, 20:11:03

Die Die-Fläche für die RAM-Chips mußt Du immer irgendwie bezahlenja klar, ich meinte das aber bzgl. Ausbeute. Bei 100% Ausbeute wäre ja ein Chip relativ güsntig, aber wenn man solche Ausbeute hat wie bei irgendeinem monstergroßen Nvidia-Chip mal kolportiert wurden (7 Stück insgesamt von zig Wafern), dann schießen die Stückkosten natürlich in die Höhe.

Aber bei HBM kann man ja die einzelnen Teile für sich fertigen und hat da eben genau die gleiche Größe und damit Ausbeute wie sonst auch. Nur der Interposer kommt noch dazu, dessen Ausbeute aber sowieso gut ist, weil er so unkompliziert ist. Beim Zusammenlöten könnte natürlich noch was schief gehen, aber auch das sind ja eher makroskopische Vorgänge.

Soll heißen, bei 400 mm² GPU + 4x 50 mm² RAM auf einem 600 mm² Interposer wird man bestimmt eine bessere Ausbeute und damit geringere Stückkosten pro fertigen Chip haben als mit einem 600 mm² großen herkömmlichen Chip, auch wenn man insgesamt doppelt so viel Siliziumfläche verbraucht.

Tesseract

2014-08-19, 20:14:01

aber wenn man solche Ausbeute hat wie bei irgendeinem monstergroßen Nvidia-Chip mal kolportiert wurden (7 Stück insgesamt von zig Wafern), dann schießen die Stückkosten natürlich in die Höhe.
sowas gibt es nur in den testläufen. einen serienchip könnte man mit so einem yield nicht verkaufen.

Nightspider

2014-08-19, 20:15:54

Wieso? Man kann in das Package vorher genauso ein Loch für den DRAM machen wie es Intel in das Mainboard macht für den Core M.

Intel setzt quasi 2 Subplatinen unter das Package:
http://pics.computerbase.de/5/9/1/7/3/17.png

AMD könnte eben den DRAM in das "Package-Loch" packen während dieser mit der Unterseite der GPU verlötet ist.

ndrs

2014-08-19, 20:15:54

Wobei die Temps steigen.
Warum?

Gerade bei höheren Speichertaktraten wird das Die wohl zusätzlich aufgeheizt.
Aber gerade durch die kürze der Verbindung und die damit gesparten PHYs sparst du überdeutlich. Heutzutage sind die größten Energiefresser nicht die eigentlichen Recheneinheiten, sondern die Datenbewegungen.

OBrian

2014-08-19, 20:16:30

@Tesseract: ja klar, war auch nur ein Extrembeispiel. 50% Ausbeute wäre wohl auch schon sehr ärgerlich.

fondness

2014-08-19, 20:44:27

Videocardz spekuliert es. AMD hat keinen Ton hierzu gesagt. Und wahrscheinlich ist es auch nicht gerade - nicht am Ende einer 4h-Veranstaltung.

AMD hat "new product announcements" bestätigt, was sollte das sonst sein wenn nicht Tonga?
Videochards tut so als hätten sie eine zusätzliche Quelle aber mal sehen.

Leonidas

2014-08-19, 21:46:00

AMD hat "new product announcements" bestätigt, was sollte das sonst sein wenn nicht Tonga?

Wo kann ich dies finden?

fondness

2014-08-19, 21:48:17

Wo kann ich dies finden?

"Festivities to Be Commemorated With Special Guests, Never-Before-Heard Stories and New Product Announcements"

http://ir.amd.com/phoenix.zhtml?c=74093&p=irol-newsArticle&ID=1958496&highlight=

john carmack

2014-08-19, 22:53:57

Ich lese hier überall HBM/HMC...

Ich dachte immer das soll erst frühestens übernächste Generation kommen also 2016/2017 ??
Bei Nvidia doch auch erst frühestens mit "Pascal"... Oder?

Nightspider

2014-08-19, 22:56:19

AMD könnte durch 2 Vorteile die Technik schneller adaptieren.

Zum einen forschen sie zusammen mit anderen Firmen seit Jahren an der Technik und zum anderen benötigt AMD nicht so hohe Stückzahlen davon wie Nvidia.

Askingar

2014-08-19, 22:56:53

Warum?
http://abload.de/img/stacked7xj3m.jpg
@IC:TechSearchInc.

ndrs

2014-08-19, 23:17:08

Ein Bild mit den Bondverbindungen von gestapelten Chips, was kaum was mit echtem Die-Stacking zu tun hat. Schön. Kenne ich. Sieht unterm Mikroskop recht lustig aus. Und wo sehe ich jetzt die Temperatur? Ein wenig Text wäre vielleicht hilfreich.

mczak

2014-08-19, 23:21:06

AMD hat "new product announcements" bestätigt, was sollte das sonst sein wenn nicht Tonga?
Das könnten ja auch bloss z.B. neue OCZ-SSDs sein, ahh meinte natürlich Radeon SSDs!

Skysnake

2014-08-20, 00:13:47

Wer macht denn heute noch wirebonding außer für irgend nen lowend Furz

Wieso? Man kann in das Package vorher genauso ein Loch für den DRAM machen wie es Intel in das Mainboard macht für den Core M.

Intel setzt quasi 2 Subplatinen unter das Package:
http://pics.computerbase.de/5/9/1/7/3/17.png

AMD könnte eben den DRAM in das "Package-Loch" packen während dieser mit der Unterseite der GPU verlötet ist.
Du musst dann immer! zwingend durchs Package! Der Witz ist doch gerade, das du maximal durch den Interposer musst, aber durch kein Package und kein PCB.

Wenn du durchs Package musst, haste schon viel verloren.

Askingar

2014-08-20, 00:32:39

Ein wenig Text wäre vielleicht hilfreich.
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=9504616#post9504616
Silizium hat ne Wärmeleitfähigkeit von 150W/(m*K) Kupfer von 400W/(m*K) Das ist schon ganz ordentlich. Das ist auch nicht so weit weg von den 235W/(m*K) von Alu. Von daher würde ich schon gleich dicke DIEs erwarten, ohne Stufen. Das macht einfach keinen Sinn.

Du musst aber bedenken, das man keine Lücke hat, sondern eine verschmolzene Verbindung. Das kannste nicht mit dem Übergang zwischen DIE<->Heatspreader<->Kühler vergleichen.Nicht so ganz. Die Dies sind ja erstmal nur über die absolut mickrigen TSVs-Bumps (und die sind nicht aus Kupfer ;)) verbunden. Der Wärmeübergang zwischen den gestackten Dies ist also erstmal ziemlich mies, weil eben gerade kein flächiger Kontakt da ist. IBM hat das deswegen ja wie eine Offenbarung gefeiert, daß sie es geschafft haben, irgendein halbwegs wärmeleitendes (aber natürlich noch elektrisch isolierendes) Füllmaterial zwischen die Dies zu packen (damit meine ich nicht den normalen "Underfill", der nur zur mechanischen Stabilisierung da ist, aber bei dem es auch Probleme bei der Verteilung duch sehr kleine [wir reden hier von 40µm und kleiner] TSVs gibt). Aber ob das schon serienreif ist, wage ich noch zu bezweifeln.

Edit:
Nur mal so ein paar Zahlen:
Die TSVs haben typischerweise nur 20µm Durchmesser (man will die ja möglichst klein machen) und die Bumps untendrunter sind kleiner als 50µm (je nach TSV-Größe, können auch <30µm sein). Die Wärmeleitfähigkeit des Lots an den TSV-Bumps beträgt typischerweise ~50 W/mK, die des Underfills zwischen den Dies (macht 95%+ der Fläche aus) nur 0,3 bis 0,4 W/mK. Das ist locker eine Größenordnung schlechter als jede Wärmeleitpaste (die gehen bis knapp 10 W/mK), aber in etwa genau so dick (20µm). Und in einem DRAM-Stack hat man das ja gleich noch mehrfach.

ndrs

2014-08-20, 00:36:13

Wer macht denn heute noch wirebonding außer für irgend nen lowend Furz

Beim Praktikumsversuch unterm Mikroskop und von Hand war das ganz lustig. :)

Du musst dann immer! zwingend durchs Package! Der Witz ist doch gerade, das du maximal durch den Interposer musst, aber durch kein Package und kein PCB.
Er meint das, glaube ich, etwas anders. Das Package selber soll ausgeschnitten werden, so dass du direkt auf die oberste Kupferlage deines Chips guckst. Da drauf soll dann der Speicherchip gepflanzt werden. Ob das technisch realisierbar ist, darüber bin ich mir noch nicht ganz sicher.
http://www.forum-3dcenter.org/vbulletin/archive/index.php/t-516431.html
Wenn du nicht mit mir reden willst, zitiere mich bitte nicht. Danke. :rolleyes:

Askingar

2014-08-20, 00:47:43

Wenn du nicht mit mir reden willst, zitiere mich bitte nicht. Danke. :rolleyes:
Habt ihr doch schon durchgekaut, Spekulieren ist ja schön und gut, aber zig mal das Gleiche? Hynix ist bisher nicht viel weiter. Dann kann AMD es auch nicht sein.

Nakai

2014-08-20, 00:53:59

Mehr als 4 Stacks kann ich mir nicht vorstellen. Ergo maximal 16GB, was kein Fortschritt ist. Außerdem ist die Bandbreite auch nur 512GB/s. Auch nicht soviel mehr, was man mit einem GDDR5-Interface schaffen könnte. Vorteil Stromersparnis. Dafür ist HBM wohl erstmal da.

Askingar

2014-08-20, 01:04:12

Scheint aber so als könnte man Stromverbrauch und Bandbreitenfehl im "Normalen" Segment mit anderen Techniken vorerst kompensieren und trotzdem Leistung hinzugewinnen.

ndrs

2014-08-20, 01:46:14

Habt ihr doch schon durchgekaut, Spekulieren ist ja schön und gut, aber zig mal das Gleiche? Hynix ist bisher nicht viel weiter. Dann kann AMD es auch nicht sein.
Vorsicht. Das, was du zitiert hast, ist nur dann ein Problem, wenn der Speicher auf stromfressender Logik gestapelt ist. Der Plan bei HBM ist aber die ganze Sache den Speicherstack neben den Logik-Die zu packen und das ganze per Interposer zu verbinden (Stichwort 2,5D).
Dadurch hast du halt keine abgedeckte Hitzequelle (der Speicher selber verbraucht nicht viel). Das ist ein ziemlicher Unterschied und sollte nicht verwechselt werden, auch wenn die Diskussion aktuell recht vermischt ist :) Ich musste selbst zurückblättern um zu sehen, worum es überhaupt ging.
Ich hoffe damit ist klar, warum ich etwas verdutzt nachgefragt habe :D

Also:
- Wärmeleitung bei 2,5D mit Interposer und gestapeltem Speicher: recht unproblematisch
- Wärmeleitung bei 3D mit Speicher auf der Logik gestapelt: ohne Lösung für das Leitfähigkeitsproblem wohl eher nur für Low-Power-Sachen geeignet.

Unicous

2014-08-20, 02:04:06

[...]
Also:
- Wärmeleitung bei 2,5D mit Interposer und gestapeltem Speicher: recht unproblematisch
- Wärmeleitung bei 3D mit Speicher auf der Logik gestapelt: ohne Lösung für das Leitfähigkeitsproblem wohl eher nur für Low-Power-Sachen geeignet.

Genau. Und deswegen erwarte ich etwas deutlich Exotischeres bei Fiji als die üblichen Verdächtigen, die schon seit Jahren umherschwirren. Etwas, das niemand auf dem Schirm hat und vielleicht nur eine Zwischenlösung ist bis man 2.5D oder 3DS beherrscht, sowohl technologisch als auch finanziell.

(2.5D vergleichsweise unkompliziert aber teuer; 3DS thermisch problematisch und teuer)

Ich werde wohl einen Besen fressen müssen, aber ich denke nicht das Fiji 2.5 HBM oder 3DS implementieren wird. Für eine Alternative fehlt mir aber ein Anhaltspunkt bzw. die Expertise.:freak:

Gipsel

2014-08-20, 02:15:19

Wie schon mal jemand erwähnt hat: 3DS bei Speicher bezeichnet meist Stacks zur herkömmlichen Verwendung z.B. auf normalen DIMMs. Die Dinger kann man sogar schon kaufen (das sind die absurd teuren mit den ganz großen Kapazitäten, z.B. 128GB pro Riegel mit 8GBit-Chips, also 36 Stacks mit je vier 8GBit-Chips [36 statt 32 Stacks wegen ECC], jeder Stack ist ein x4 device [4bit Anbindung], im Clamshell-Modus bekommt man dann im Endeffekt eine x2-Anbindung hin, damit man die 36 Stacks in die 64/72Bit pro DIMM reinquetschen kann [perspektivisch kommen noch 16GBit-Dies und 8 Dies pro Stack, also bis zu 512GB pro Riegel]), die vergrößern erstmal nur die Kapazität. Mit GPUs hat das ganze nicht so viel am Hut.

Nightspider

2014-08-20, 03:31:09

Ich habe nochmal meine Paint-Künste wirken lassen um zu verdeutlichen wie ich das gemeint hatte.

Es müssten nicht 4 Cubes / Stackes sein aber ich habe jetzt einfach mal 4 eingezeichnet:

http://abload.de/img/gpumithmcxmkyj.jpg

Im Grafikkarten PCB wäre also ein quadratisches Loch.

Skysnake

2014-08-20, 08:32:36

Ok, jetzt weiß ich, was du meinst. Quasi das Package komplett weg lassen.

Interessante Idee, aber einfach wird das nicht. Du hast halt nur noch am Rand GND und VDD. Zudem muss der Chip schon ziemlich heftig Fett werden. An sich müsste man eigentlich PCB hier durch Package ersetzen, denn direkt aufs PCB kannste den DIE nicht löten. Das geht nicht.

Und bei nem Package wäre mir nicht bekannt, das man sowas machen könnte, und damit hätte man eben wieder das Problem, das alles durchs Package durchgeroutet werden muss -> PfuiBäh

Und selbst wenn man Packages mit Loch machen könnte, wovon ich nicht ausgehen, auch wegen der thermischen Beanspruchung bzgl Filler usw. Den Packagedesigner würdeste wohl in den Wahnsinn treiben.

M4xw0lf

2014-08-20, 10:09:52

http://www.pcgameshardware.de/AMD-Radeon-Grafikkarte-255597/News/Asetek-neue-AMD-Grafikkarte-1133023/
Das war glaube ich noch nicht hier. Großauftrag für Asetek lässt mich wieder an eine übertaktete 290X + AiO-Wasserkühlung aka 295X denken.

HOT

2014-08-20, 10:38:32

Ich hab irgendwie Zweifel daran, dass es praktikabel ist, ein Die direkt auf das PCB aufzubringen. Es müsste dann trotzdem ein Gehäuse für das Die her.

Ailuros

2014-08-20, 11:53:07

Wenn HMC oder HBM kommt, dann kann man mit mindestens 500GB/s rechnen, sonst macht ein solcher Aufwand keinen Sinn.

Hynix liefert pro Stack ~128GB/s und 1GB RAM. Bei 4 Stacks wären das 4GB und ~512GB/s.

Micron liefert HMCs mit 4 GB Volumen bei einer Bandbreite von 120~160GB/s.

Da AMD aber mit Hynix zusammenarbeitet, kann man eigentlich nur 2 Optionen vermuten:
HBM oder 3DS

Interessant bei 3DS ist, dass anscheinend die bestehende Infrastruktur bestehen bleibt und kein TSV benötigt wird, da der RAM auf den Chip kommt.

Besser spaet als nie (fuer die Antwort hier...), aber wenn Du etwas in Stromverbrauchszahlen herumstoeberst ist es kinderleicht zu sehen was fuer Vorteile ein solcher Anzatz haben kann ohne dass man die eigentlich Bandbreiten-Menge unbedingt aus der Decke sprengt. Sonst damit die Raterei etwas genauer wird: HBM nach dem eigentlichen Hintergrundgefluester.

Nightspider

2014-08-20, 14:32:58

@ Skysnake:

Dann eher so?

http://abload.de/img/gpumithmc2nzdu1.png

Skysnake

2014-08-20, 16:02:24

Knuddelbearli

2014-08-20, 16:52:56

war jetzt 1,5 wochen weg wegen Todesfall in der Familie.

Gab es irgendwas wichtiges neues? denke mal nicht das würde man ja sicher irgenwo als news lesen oder?

Nightspider

2014-08-20, 17:53:27

Schon eher, nur wird das eben nicht funktionieren. Solche Packages bekommste nicht gefertigt. Allein schon wegen der mechanischen Stabilitaet.

Da sind so viele Neuentwicklung und Kopfstaende drin, da wird nen Interposer die einfachere und elegantere Loesung sein.

Naja, nehmen wir mal an da werden wirklich nur 2 Cubes verbaut, dann müsste das Loch auch nicht sehr groß sein und würde nur ~20% der GPU Fläche einnehmen. Stabilität dürfte da noch kein Problem sein. Habe die HMC ja auch recht weit auseinander gezeichnet.

Und wenn die HMCs flach genug sind braucht man nicht mal ein Loch im PCB. In Smartphones kleben ja auch schon manchmal kleine Chips (DRAM) unter anderen Chips ohne das ein Loch in der Platine darunter ist.

war jetzt 1,5 wochen weg wegen Todesfall in der Familie.

Gab es irgendwas wichtiges neues? denke mal nicht das würde man ja sicher irgenwo als news lesen oder?

Herzliches Beileid, falls es eine dir nahe stehende und geliebte Person war!

Nein nicht wirklich, wir spekulieren nur weiter rum.

Hübie

2014-08-20, 18:50:16

war jetzt 1,5 wochen weg wegen Todesfall in der Familie.

Gab es irgendwas wichtiges neues? denke mal nicht das würde man ja sicher irgenwo als news lesen oder?

Mein aufrichtiges Beileid. :(

Aktuell geht es um eine Aussage die (glaub ich) im B3D getätigt wurde wo es hieß "big die" und "something different with memory". Wobei das jetzt nicht wörtlich zitiert ist ;)
Häng dich mit rein, wenns ablenkt :smile: Nightspider hat auch extra auf paint geklickt :biggrin:

@Nightspider: Wie willst du dass mechanisch und physisch stabil bekommen? Und ich weiß gar nicht wie sinnvoll das ist den IMC mittig von Die zu implementieren...

Knuddelbearli

2014-08-20, 19:09:08

Big DIE hält sich ja schon länger in der Gerüchteküche aber glaub einfach nicht daran hmmm ...

Und mein Vater ist bei einem Arbeitsunfall tödlich verunglückt

horn 12

2014-08-20, 19:36:33

Mein aufrichtiges Beileid!
Schwerer Fall, aber dennoch Kopf hoch!
Auch wenns schwer wird und Dein Vater dir sehr sehr fehlen wird.

ndrs

2014-08-20, 20:43:12

Und ich weiß gar nicht wie sinnvoll das ist den IMC mittig von Die zu implementieren...
Ich denke sogar, dass man Speichercontroller und andere Logik wild mischen müsste, da die für die µBumps benötigte Fläche immer noch größer als das eigentliche SI sein könnte. Was noch dazu kommt, ist dass man die komplette Stromversorgung des Speichers durch die GPU leiten müsste. Wie schonmal von Skysnake erwähnt: dann lieber Interposer :)

Nightspider

2014-08-20, 20:54:37

@Nightspider: Wie willst du dass mechanisch und physisch stabil bekommen? Und ich weiß gar nicht wie sinnvoll das ist den IMC mittig von Die zu implementieren...

Wo ist der Unterschied zwischen mechanischer und physischer Stabilität? :ugly:

Was wollt ihr denn für eine Stabilität haben? Wollt ihr ein Auto drauf parken?

Das Die liegt an allen 4 Seiten mind. 1cm auf wodurch die Kraft gut und gleichmäßig verteilt wird, wenn der Kühler Druck auf den Chip/HS ausübt.

Zumal der Druck bei GPU Kühlern bei weitem nicht so hoch ist wie mein manch einem CPU-Kühler, wo mit Federn+Schrauben starke Kräfte ausgeübt werden.

PS: Gib es zu, meine Paint-Künste sind grandios. :biggrin:

Big DIE hält sich ja schon länger in der Gerüchteküche aber glaub einfach nicht daran hmmm ...

Und mein Vater ist bei einem Arbeitsunfall tödlich verunglückt

Oh man. :(

Knuddelbearli

2014-08-20, 20:58:51

im schlimmsten falls kommt in die Mitte des Sockel ein Wärmeleitpad worauf die Unterseite der CPU aufliegt ^^

Monsta

2014-08-20, 21:56:20

Naja etwas unrealistisch.
Das Pcb wird unnötig geschwächt, das Loch zu fräsen kostet Geld.
Und ich kann mir im Moment nicht vorstellen wie du das bestücken und Löten willst.

Nightspider

2014-08-20, 23:25:14

Schwächung des PCBs bei einem 3*3cm² Loch? Da fällt sicherlich gleich der ganze PC auseinander. :ugly:
Loch fräsen dürfte wenige Cent kosten.

Monsta

2014-08-20, 23:32:18

Natürlich fällt der PC nicht auseinander. Aber die meiste Kraft auf dem PCB liegt halt genau auf dem Loch. Da dort der Kühler aufgepresst wird. Bei schweren Kühlern biegt sich schon ohne Loch die Leiterplatte durch. Das ist nicht gerade förderlich für die Lebensdauer.

Käsetoast

2014-08-21, 00:22:34

Löcher sind immer fies, wobei ich nicht weiß wie's so mit thermaler Wechselbeständigkeit aussieht. Ecken die sich ständig aufheizen und abkühlen sind risstechnisch schon äußerst ungünstig...

Aber naja, ich denke zu 99% werden wir irgendwas in der Art sowieso nicht zu sehen bekommen. So langsam dürften aber mal erste ernstzunehmende Leaks kommen... :D

robbitop

2014-08-21, 08:50:41

Dann macht man um das Loch eine Verstärkung in Form eines Metalrahmens. Ob das nötig ist, wage ich zu bezweifeln. PCBs bestehen aus GFK und das hat schon ganz nette Festigkeiten. Zumal der vollflächige Kühlkörper auch noch an anderen Punkten abstützen kann. Intel wird bei Broadwell auch ein Loch unter dem Kern haben.
Das Argument mit dem Preis fürs Sägen ist ein Witz. Das geht extrem billig vollautomatisiert.
Ein Loch kann übrigens auch Radien statt Ecken haben, damit die mechanische Spannung sich nicht so stark konzentriert.

Pick

2014-08-21, 12:13:15

fondness

2014-08-21, 14:02:58

Effizienter AMD „Tonga“ erscheint am 2. September
http://videocardz.com/51251/amd-radeon-r9-285-arrives-september-2nd-preliminary-information-2-days
http://www.computerbase.de/2014-08/amd-tonga-erscheinungstermin/

Und wie erwartet gibt es am 23. erste Details.

Nakai

2014-08-21, 14:10:35

Meine Spekulation:

Maui XT - 295X ----- 24CU/3072SP
Maui Pro - 295 ----- 22CU/2816SP
Tonga XT - 285X ----- 16CU/2048SP
Tonga Pro - 285 ----- 14CU/1792SP
Guam XT - 275X ----- 12CU/1536SP
Guam Pro - 275 ----- 10CU/1280SP
Iceland XT - 255X ----- 8CU/1024SP
Iceland Pro - 255 ----- 6CU/768SP

Platzieren Sie Ihre Einsätze, meine Damen und Herren! :biggrin:

Sagmal, bist du SeronX? ;D

Woher kommt die Geschichte mit den 128SPs-CUs?

Es gibt definitiv zwei Chips von AMD. Einer größer als 550mm² und einer größer als 350mm². Fiji wird der Große sein und wohl auf HBM setzen. Außerdem gibt es noch Iceland im unteren Bereich.

Nochmal, beide IHVs haben viele Codenamen im Treiber stehen. Nicht alle müssen auf den Markt kommen.

Ailuros

2014-08-21, 14:26:10

Ich wollte gerade fragen wie viele salvage CUs der grosse Kern haben soll, aber den Scherz wird auch nicht jeder auf Anhieb verstehen :biggrin:

Unicous

2014-08-21, 14:30:08

Es waren 4 bei Hawaii, ergo sind es jetzt 8 bei Fiji.

Ailuros

2014-08-21, 14:40:23

Es waren 4 bei Hawaii, ergo sind es jetzt 8 bei Fiji.

Ich hab gerade der "8" einen Tritt verpasst und sie auf die Seite gelegt :freak:

Unicous

2014-08-21, 14:42:00

:eek:

*mindblown*

OBrian

2014-08-21, 18:20:07

mal Spaß beiseite: Wer denkt sich solche Sachen denn immer aus? Muß doch von NV-Fans oder besser gesagt AMD-Hassern kommen. Es gibt doch nichts unattraktiveres als einen teildeaktivierten Chip, oder? Vielleicht noch einen umgelabelten alten teildeaktivierten Chip. Wenn man also sagt, der neue Chip käme nicht vollständig auf den Markt, dann ist die suggerierte Reaktion doch, noch mit dem Kauf zu warten, bis es die Vollversion gibt. Oder seh ich das falsch?

fondness

2014-08-21, 18:21:00

Es gibt wohl noch zu viele Tahitis auf Lager die man vorher verkaufen muss. Die 280 kann man schon mal ersetzen da die Yieldrate inzwischen sehr gut sein sollte sodass es weit weniger defekte Chips gibt als man 280er benötigt.

Ailuros

2014-08-21, 18:29:22

Bloede Frage ist das hier eigentlich schon bekannt?

http://users.otenet.gr/~ailuros/AMD250614.pdf

Akkarin

2014-08-21, 18:35:24

Hab ich vor ein paar seiten mal gepostet, allgemeine Meinung war dass das eher nur für exascale gedacht ist und noch etwas in der Zukunft liegt.

Ailuros

2014-08-21, 18:39:08

Hab ich vor ein paar seiten mal gepostet, allgemeine Meinung war dass das eher nur für exascale gedacht ist und noch etwas in der Zukunft liegt.

Generell schon, aber es gibt womoeglich auch hints fuer die naehere Zukunft.

M4xw0lf

2014-08-21, 18:42:26

Passt das nicht gut zu den Gerüchten über Fiji, von wegen Größe und "interessanten" Speichergeschichten?

Ailuros

2014-08-21, 18:43:02

Passt das nicht gut zu den Gerüchten über Fiji, von wegen Größe und "interessanten" Speichergeschichten?

:weg: :D

M4xw0lf

2014-08-21, 18:50:30

:weg: :D
Trollst du mich ahnungslosen Ahnungslosen? :eek:

Hübie

2014-08-21, 19:36:45

Also laut dem slide haben die ja schon Integrationen mit PIM getestet. Simuliert in 16 nm und 20 nm Silizium. Unter 28 nm gibt es also die Möglichkeit das mit kleinen "Dosierungen" zu machen. 2 Stacks sollten jedenfalls gehen. Mehr würde ich nicht erwarten. Takt irgendwas um die 600+ MHz.

Askingar

2014-08-21, 19:53:16

650...

Und wenn man schneller will, nicht vor 3. Quartal 2015, soweit dass überhaupt haltbar ist.

OBrian

2014-08-21, 19:59:33

wie ich schon meinte, diese PIM-Geschichte paßt viel mehr zu APUs als zu dicken GPUs. Da steht ja, so ein Stapel darf maximal 10 Watt aufnehmen (bzw. Abwärme erzeugen). Idee ist also, wenn man z.B. den RAM-Verbrauch auf 5 W drücken kann, die anderen 5 W mit ein paar Grafik-CUs auszufüllen, die man noch unter den RAM quetscht. Das bringt eine bessere Anbindung dieser CUs und eine Entlastung des zentralen Chips. Aber wenn man viermal 5 W an GPU-Power von Chip wegbewegt, dann ist das was Interessantes für einen Chip in der Größenordnung von Kaveri, aber für einen Hawaii wäre das lächerlich.

Und es ist eben ein zweiter Schritt, nachdem man überhaupt mal erst RAM on-Die verbaut hat. Solange das nicht passiert ist, brauchen wir PIM nicht zu erwarten.

Askingar

2014-08-21, 20:13:32

AMD forscht hier bisher eher im Bereich für Exascale computing und der Unterbringung des PIM im Die...was auch Sinn macht. Bei APUs vllt. sowieso. Das Ganze ist aufwendig und kostenintesiv und wird zuerst wohl im Professionellen Bereich zu erwarten sein. Fiji wurde sicherlich längst aufgelegt. Auch wenn GCN frei weiterentwickelt wird, rechne ich nicht mit Vergleichbarem. Vllt. in Gen4. Würde auch zu Nvidias Ansatz passen.

Ich weiss nicht von was hier einige so träumen. Naja, sei ja erlaubt. Mir würde reichen sie bringen etwas, dass in Konkurrenz den Markt beleben kann. Das muss nicht immer superdusitechni Kram sein, sondern muss einfach nur gut funktionieren und schnell sein.

Man muss auch aufpassen was man sich wünscht, unter 600$ kann man dann dafür definitiv vergessen. Ich glaube nicht das sehr viele damit glücklich wären.

ilibilly

2014-08-22, 10:09:58

Kann man aufgrund der gesteigerten effizienz, davon ausgehen das ein tonga mit ca 2000 shadern an die kleine r9 290 rankommt ?
Quasi ähnliche steigerung wie kepler zu maxwell ?

ndrs

2014-08-22, 11:26:34

Kann man aufgrund der gesteigerten effizienz, davon ausgehen das ein tonga mit ca 2000 shadern an die kleine r9 290 rankommt ?
Quasi ähnliche steigerung wie kepler zu maxwell ?
Man kann es vermuten. Fest davon auszugehen würde ich im Sinne der Enttäuschungsreduzierung noch vermeiden.

Oder anders ausgedrückt: Das weiß noch keiner.

Ailuros

2014-08-22, 12:00:07

Trollst du mich ahnungslosen Ahnungslosen? :eek:

Ein KISS Versuch: Hawaii in der groessten FirePRO erreicht wie viel DP FLOPs genau und bei welcher TDP? Stell Dir mal vor Du hast einen Nachfolger wie Fiji der aber auf dem gleichen Prozess hergestellt werden soll der noch mehr DP FLOPs und noch mehr Bandbreite dafuer haben soll. Du wollen TDP aus der Decke sprengen oder fuer einen effektive Loesung suchen weniger zu verbrauchen? :wink:

Screemer

2014-08-22, 12:13:52

Ailuros ist so ein f/teaser-sack ;)

fondness

2014-08-22, 12:33:16

Es ist mittlerweile kein großes Geheimnis mehr das Fiji eben irgend eine Form von HBM verwenden wird.

Unicous

2014-08-22, 12:42:08

@Screemer

Ich glaube eher er hat einen Fetisch.;(

http://de.wikipedia.org/wiki/Tease_and_Denial

:freak:

@fondness

Ich bin immer noch nicht 100% überzeugt.

Dural

2014-08-22, 13:02:05

und ich bin mir zu 99% sicher das es wie gehabt bleiben wird, also nichts spezielles damit kommt ;)

das einzige was mich wundert sind die Wasserkühlungen, ich hoffe mal schwer nicht das AMD schon bei Single GPU Karten mit Wakü daher kommen will! Wenn ja ist das mal kein gutes Zeichen für mich.

Unicous

2014-08-22, 13:09:24

Du hast eine Nvdia-Referenz in deinem Post vergessen.

Nightspider

2014-08-22, 13:11:37

Eine "Extreme Highend" Single GPU Grafikkarte von AMD mit Wasserkühler wäre doch nett.^^

Nur bitte ohne Radiator und Pumpe, dann würde ich das Ding sofort kaufen.

Gibt ja genug Nerds mit Wasserkühlung heutzutage. Habe mittlerweile schon 12 Jahre Wasserkühlung im PC. :O

Dural

2014-08-22, 13:16:06

Meine erste WaKü hatte ich auf Slot A CPUs und das sind schon einige Jahre.

Aber ich werde diesen Trend (von AMD?) sicher nicht mitmachen, wer Stock WaKü verbauen muss hat den knall wohl noch nicht gehört! Zudem mich solche 0815 billig WaKü generell nicht Interessieren.

Screemer

2014-08-22, 13:18:10

ich frag mich obs am 23. dann auch infos zu den großen chips oder nur zu tonga gibt.

Blediator16

2014-08-22, 13:59:50

Dural

2014-08-22, 14:15:15

schon nur der vergleich LuKü / WaKü :freak: und kann nur von jemanden kommen der nicht viel Ahnung von WaKü hat, mit einer Vernünftigen Kühlung wäre die GPU Temp sicher ca. 30°C (!!!) niedriger.

und nur so als Info, ich kenne etwa die Verkaufszahlen, jedenfalls von hier und von Hosenruterlassen kann keine rede sein. Titan wird gekauft, auch wenn es das doppelte kostet.

Blediator16

2014-08-22, 14:21:21

Askingar

2014-08-22, 14:54:38

Es ist mittlerweile kein großes Geheimnis mehr das Fiji eben irgend eine Form von HBM verwenden wird.
Dann werden wir mit Hawii noch einige Zeit verbringen. Ich glaube nicht das dieser dem GM200 etwas entgegen zu setzen hat, sollte dieser im Desktopsegment erscheinen. Auch nicht als XTX Version.

Zudem dürfte Fiji dann mit 600mm² Die und HBM richtig Kohle kosten, man sollte sich auf Nvidia Preise einstellen.

Kann man aufgrund der gesteigerten effizienz, davon ausgehen das ein tonga mit ca 2000 shadern an die kleine r9 290 rankommt ?
Tonga, ja der dürfte in XT Version (sollte diese erscheinen) an die 290 ranreichen, ggf. diese sogar übertrumpfen. Da gibt es nur zwei Dinge die beachtet werden sollten, er bietet erstmal weniger VRam (ob 4GB Versionen erscheinen, weiss niemand) und AMD wird sicherlich wieder einige "Sperren" einbauen, damit man nicht zu schnell wird.

Falls du eine Graka von AMD suchst, nimm eine Hawaii XT mit Cutsomkühlkonzept. Die sind doch mittlerweile preisgünstig, warten bringt zumeist nichts.

Käsetoast

2014-08-22, 14:55:04

AMD kann ja einfach Sapphires Flüssigmetallkühlungskonzept kaufen, das die vor Jahren mal entwickelt hatten... :D

Nakai

2014-08-22, 15:06:15

Ein KISS Versuch: Hawaii in der groessten FirePRO erreicht wie viel DP FLOPs genau und bei welcher TDP? Stell Dir mal vor Du hast einen Nachfolger wie Fiji der aber auf dem gleichen Prozess hergestellt werden soll der noch mehr DP FLOPs und noch mehr Bandbreite dafuer haben soll. Du wollen TDP aus der Decke sprengen oder fuer einen effektive Loesung suchen weniger zu verbrauchen? :wink:

Also recht viel mehr als Hawaii und Tahiti-unleashed kann eine GPU eigentlich nicht mehr verbrauchen. Maxwell verbraucht wohl durch die kleineren SMMs und dem größeren L2-Cache deutlich weniger. Der L2-Cache ist auch gut für Compute-Sachen, deswegen sollte Fiji/Tonga auch schon mehr L2-Cache besitzen.

Micron hat mit Automata Processing bereits eine Art PIM. Im Endeffekt leistet der Speicher bereits eine Art "Arbeit", welche Speicherzugriffe verbessert. Hierzu wird der Automata Processor mit einer eigenen "API" programmiert, welche eine Automatenlogik in den Prozessor setzt, welche den Speicher für eigene Zwecke analysiert und dementsprechende Rückgaben liefert. Ich habs mal versucht, beim einmaligen Drüberfliegen zu verstehen. Ist jedenfalls sehr interessant, aber inwieweit das für GPUs nutzbar wäre, kA.

Wenn es in irgendeiner Hinsicht Speichezugriffe optimiert bzw. verbessert, um Energie zu sparen, ist das auf jeden Fall hilfreich. Ich weiß auch nicht, wie es mit den Latenzen aussieht, wenn extra Berechnungseinheiten auf dem Speicher liegen. Es werden jedenfalls Caches im Speicher erwähnt, aber größere Caches auf der eigentlichen GPU/CPU wären bestimmt auch hilfreich.

Ahja, das Dokument von AMD liefert eine Möglichkeit, wie es schlussendlich aussehen könnte. Es gibt zwei Arten von Dies. Host-Die, mit abstrakten Speicherinterfaces, und PIM-Dies, mit dem eigentlichen Speicherinterface zum gestakten RAM. Ich erwarte soetwas bestimmt nicht von Fiji, aber eventuell sehen wir in Fiji Speicherlogik für HBM-Speicher.

€: Dann werden wir mit Hawii noch einige Zeit verbringen. Ich glaube nicht das dieser dem GM200 etwas entgegen zu setzen hat, sollte dieser im Desktopsegment erscheinen. Auch nicht als XTX Version.

Hawaii verbraucht eigentlich weniger als Tahiti in Quiet. Nur wenn er wirklich voll aufdreht, ist der Chip eine abartige Stromschleuder.

GM200 wird so ziemlich stark werden. ~50%+GK110 sollte erwarten werden. GM204 sollte leicht über GK110 liegen.

Tonga, ja der dürfte in XT Version (sollte diese erscheinen) an die 290 ranreichen, ggf. diese sogar übertrumpfen. Da gibt es nur zwei Dinge die beachtet werden sollten, er bietet erstmal weniger VRam (ob 4GB Versionen erscheinen, weiss niemand) und AMD wird sicherlich wieder einige "Sperren" einbauen, damit man nicht zu schnell wird.

Tonga muss in erster Linie Pitcairn ersetzen und im Mobile-Bereich eingesetzt werden. AMD hat derzeit keinen Chip im Mobile-Bereich der GM107 was entgegenzusetzen hat.

Askingar

2014-08-22, 15:33:46

1.GM200 wird so ziemlich stark werden...
2.Tonga muss in erster Linie Pitcairn ersetzen
1. Ich weiß.
2.Tonga muss in erster Linie Bonaire und Pitcairn ersetzen...so gesehen ist er 1. Jahr zu früh. Das passt dann zu deinen Aussagen hinsichtlich Maxwell GM107. Das der 860m ein Glücksgriff ist, war abzusehen.

Nakai

2014-08-22, 15:40:54

1. Ich weiß.
2.Tonga muss in erster Linie Bonaire und Pitcairn ersetzen...so gesehen ist er 1. Jahr zu früh. Das passt dann zu deinen Aussagen hinsichtlich Maxwell GM107. Das der 860m ein Glücksgriff ist, war abzusehen.

Bonaire bleibt doch erstmal erhalten.

Es macht auch keinen Sinn mehr, irgendetwas im unteren Bereich anzubieten. APUs sind mittlerweile so stark, reinher von der GPU-Performance, dass soetwas, wie Hainan oder Oland keinen Sinn mehr macht. Iceland muss mindestens 512SPs+ haben, um eine Berechtigung zu haben. CapeVerde ist derzeit noch in diesem Bereich, muss aber auch bald ersetzt werden, ebenso wie Bonaire.

Wie es derzeit für mich aussieht:
- Pitcairn und Tahiti werden durch Tonga ersetzt.
- Capeverde und Bonaire sollten durch Iceland ersetzt werden.
- Hawaii bleibt erstmal bestehen, eventuell gibt es da bald eine Wasserkühlungsversion, welche man gegen GM204 stellen kann(höhere Taktraten bei Quiet-Verbrauch).
-Fiji ist dann gegen GM200 angesetzt.

Hawaii müsste auch mittelfristig ersetzt werden. Gegen GM204 sollte Hawaii ineffizient sein.

Askingar

2014-08-22, 15:52:56

Man kann Tahiti nicht mit Tahiti ersetzen, egal welche GCN Gen er darstellt. Tonga bietet aus meiner Sicht ansich viel Potentail für AMD mehrere Segmentbereiche abzudecken/abzulösen. Es würde aus kostenrelevanter Sicht zumindestens eine Überlegung Wert sein, wenn nicht jetzt, dann zukünftig.

Pick

2014-08-22, 16:44:31

Faraway Islands?
https://translate.google.com/translate?hl=en&sl=es&tl=en&u=http%3A%2F%2Fwww.chw.net%2F2014%2F08%2Famd-trabaja-en-sus-gpus-radeon-r-400-series-faraway-islands-a-20nm%2F

fondness

2014-08-22, 16:53:39

Wäre nice wenn am Samstag wirklich die gesamte Pirate Islands Famailie vorgestellt wird.

AnarchX

2014-08-22, 17:11:22

Wäre nice wenn am Samstag wirklich die gesamte Pirate Islands Famailie vorgestellt wird.
Erwarten wir nicht ein paar Keyfacts zur R9 285?

Ansonsten könnte man sich vielleicht eine Roadmap ähnlich wie die von NV vorstellen, wo grob die Performance per Watt geschätzt wird mit den wichtigsten Features.

Unicous

2014-08-22, 19:38:11

@Pick

No, it's not real. It's an invention by Charlie (SemiAccurate) for one his Article Tags. But just as predicted some foolish writer picked it up and wrote a silly non-factual piece about it.

OBrian

2014-08-22, 23:55:20

speak we now english or what is here loose?

Unicous

2014-08-22, 23:57:32

Da Pick (iirc) nicht deutsch spricht, war ich mal so nett und habe auf Englisch geantwortet.

horn 12

2014-08-23, 10:05:54

In Knapp 6 Stunden geht es los, mal sehen was AMD der Oeffentlichkeit praesentiert und ob man NV Kunden koedern kann, oder es Ihnen diesesmal gelingt :-)

fondness

2014-08-23, 10:29:54

Auf Twitter wird jedenfalls schon fleißig gespoiltert. Scheint ein ähnlich großes Event zu werden wie damals beim Hawaii-Launch. Mal sehen ob man wieder so eine Bombe wie damals Mantle hat. ;)

Chris Roberts wird da sein, ebenso Kyle Bennett, Frank Vitz, Chris Hook, jemand von Firaxis Games, Richard Huddy, Raja Koduri, John Byrne. DICE dürfte wohl wieder ein paar neue Mantle Spiele und Features veröffentlichen.

horn 12

2014-08-23, 10:38:18

Wohl offizielles Downsampling bei Tonga, Fiji Gpu's :-)

Hübie

2014-08-23, 10:57:34

Wenn das kommt rückt AMD für meine Bedürfnisse vor nVidia.

dargo

2014-08-23, 10:58:18

Wohl offizielles Downsampling bei Tonga, Fiji Gpu's :-)
Ganz bestimmt. :freak:

Dieses DS ist langsam völlig uninteressant. Demnächst werden 4k Bildschirme "In". Oder halt ein Zwischenschritt mit bsw. 3440x1440 @21:9.

M4xw0lf

2014-08-23, 10:58:32

Hört auf meinen Hype zu steigern, es wird am Ende ja doch wieder ätsch. :usad:

Hübie

2014-08-23, 11:11:57

Ich zocke momentan nur noch mit DS und PPAA. SGSSAA ist mir mittlerweile zu fummelig und wird auch immer seltener möglich.

fondness

2014-08-23, 11:16:29

Viele Spiele haben mittlerweile eh schon ingame Downsampling, aber zumindest angekündigt wurde es von AMD das stimmt schon.

Hübie

2014-08-23, 11:20:35

Ich kenne nur Battlefield 4. Welche Spiele bieten das denn noch? Bei Risen 3 finde ich es löblich dass das UI mitskaliert.

dargo

2014-08-23, 11:44:37

Ich zocke momentan nur noch mit DS und PPAA.
Ich kanns bei dir noch verstehen. Wohin auch mit der Leistung zweier GK104? :tongue: Mit einer Karte wird DS bei neuen Games aber imho völlig überbewertet. Zumindest wenn man ~60fps anpeilt.

Ich kenne nur Battlefield 4. Welche Spiele bieten das denn noch?
PvZ: GW zb. auch. Möglicherweise alle FB3 Spiele. Ging das auch schon bei NfS: Rivals?

Bei Risen 3 finde ich es löblich dass das UI mitskaliert.
Risen 3 ist doch DX9 oder? Da kann man doch auf Gedosato zurückgreifen.

fondness

2014-08-23, 11:52:23

Die meisten AMD Gaming Evolved Titel haben internes Downsampling, Metro AFAIK auch.

aufkrawall

2014-08-23, 12:10:26

Askingar

2014-08-23, 12:21:59

Ich würde nicht zuviel erwarten, aber wenns losgeht kann man ja mal schauen:http://www.amd.com/en-us/who-we-are/corporate-information/events/amd-30-live?cmpid=social29927316

dargo

2014-08-23, 12:22:44

Dummerweise vergeigen Entwickler selbst so einfache Sachen.
Bei TR oder Thief ist die Glättung schlecht, bei Frostbite verschlechtert es die Frametimes (GW mit Mantle vielleicht ausgenommen, glaub ich aber auch erst, wenn ichs sehe)...
Bei PvZ: GW sind die Frametimes mit Mantle immer absolut sauber. Ich kann dir auch gerne mit internem DS ein Foto anbieten. Man sollte sich langsam von dem kaputten BF4 verabschieden. DICE hats in der Hinsicht verkackt und ich glaube auch nicht mehr, dass es besser wird. Demnächst steht Hardline schon vor der Tür. Ich hoffe bloß, dass sie es endlich bei Hardline vernünftig implementieren.

fondness

2014-08-23, 12:24:11

Ich würde nicht zuviel erwarten, aber wenns losgeht kann man ja mal schauen:http://www.amd.com/en-us/who-we-are/corporate-information/events/amd-30-live?cmpid=social29927316

Das ist im übrigen 16:00 Uhr unserer Zeit.

Dummerweise vergeigen Entwickler selbst so einfache Sachen.
Bei TR oder Thief ist die Glättung schlecht, bei Frostbite verschlechtert es die Frametimes (GW mit Mantle vielleicht ausgenommen, glaub ich aber auch erst, wenn ichs sehe)...

Hm, du findest aber auch immer irgendwas zum kritisieren, wäre mir nicht aufgefallen aber gut. Sniper Elite 3 ist auch so ein Gaming Evolved Kandidat mit internen Downsampling.
Finde es schade das Nvidia hier nicht ebenfalls aktiv wird und internes Downsampling forciert.

aufkrawall

2014-08-23, 12:48:54

Woher willst du wissen, dass das DS in SE auf AMD zurück geht?
Das DS in TR und Thief wurd hier von mehreren bemängelt, also hübsch langsam.

-/\-CruNcher-/\-

2014-08-23, 12:54:06

Ich würde nicht zuviel erwarten, aber wenns losgeht kann man ja mal schauen:http://www.amd.com/en-us/who-we-are/corporate-information/events/amd-30-live?cmpid=social29927316

Bin äusserst gespannt auf Tonga im Zuge von Maxwells Power Efficiency, vor allem bin ich echt gespannt was Huddy zu sagen hat :)

Sowas wie die x60 GTX von AMD das wär schon was die 260X konnte es ja nicht erfüllen und die Refurbished sachen waren ja uninteressant, da hatte ich vor einem jahr schon etwas mehr erwartet, das es jetzt 1 Jahr dauern sollte ist schon heftig vor allem mit Maxwell vor der Tür :)

Askingar

2014-08-23, 13:56:52

Bin äusserst gespannt auf Tonga im Zuge von Maxwells Power Efficiency, vor allem bin ich echt gespannt was Huddy zu sagen hat :)
Nichts...

Der soll sich auf seine Arbeit als Chief Game Scientist konzentrieren und nicht soviel Bullshit (http://www.golem.de/news/richard-huddy-im-interview-amd-verliert-einen-benchmark-den-nvidia-geschrieben-hat-1406-107523.html) verbreiten.

HOT

2014-08-23, 14:20:55

Nichts...

Der soll sich auf seine Arbeit als Chief Game Scientist konzentrieren und nicht soviel Bullshit (http://www.golem.de/news/richard-huddy-im-interview-amd-verliert-einen-benchmark-den-nvidia-geschrieben-hat-1406-107523.html) verbreiten.
Ob das BS ist oder nicht kann man sicherlich streiten. Ich glaube dass da was dran ist, aber das ist jedem selbst überlassen, da man es nicht beweisen kann.
Dass Corps sich gegenseitig bescheissen und anschwärzen ist nichts neues.

Hübie

2014-08-23, 14:22:19

Wenn mit downsampling OGSSAA gemeint ist dann hat Metro LL das auch. BF4 läuft mit Treiberdownsampling schneller wenn ich mich richtig erinnere.
GeDoSaTo hab ich mal probiert aber bin mit Treiberdownsampling schneller als mit der Fummelei. Geht ja alles bis 4k.

Unicous

2014-08-23, 14:44:16

M4xw0lf

2014-08-23, 15:44:04

Ich erwarte jedenfalls keinen "Hawaii" Moment.
Du spielst auf die legendäre Veranstaltung an, die aus 90% Audio, 10% Mantle und 0% Informationen zur Hawaii-GPU bestand? Yay, dann wird das heute gut! :wink:

dildo4u

2014-08-23, 15:49:14

Liveblog

http://videocardz.com/51277/amd-30-years-graphics-gaming-event-live-blog

4GB 285 von Sapphire
http://a.disquscdn.com/uploads/mediaembed/images/1246/109/original.jpg

Wird Heute nur 285 gezeigt?

hardtech

2014-08-23, 15:53:11

gleich geht also die große enttäuschung los? :D

M4xw0lf

2014-08-23, 15:54:02

Möglicherweise auch die neuen FX-Modelle? Oder geht es explizit nur um die Grafiksparte heute?

Unicous

2014-08-23, 15:59:43

Explizit und exklusiv um die GPU-Sparte bzw.29-30 Jahre Ati/AMD. :wink:

Dass da was Superduper Tolles kommt, kann ich mir nicht vorstellen. Nicht bei AMD:freak:

Tonga PRO und das wars. Und Spiele Ati/AMD-Geschichte, Mantle, TrueAudio vllt..

Und ganz viel auf den eigenen Rücken patschen.:tongue:

Askingar

2014-08-23, 16:01:03

Ich gebe euch Allen mal eine Runde Valium aus. Ich denke es wird eine seichte Jubiläums-Veranstaltung mit Tonga-Tease... and Denial.

Es wird viel über Mantle und Co. geredet aber Konkretes gibt es nichts. Hier und da ein paar nette Trailer, Beyond Earth Szenen etc. Es sind mittlerweile schon 76 Entwickler- einer mehr als gestern:rolleyes:, und alles ist kunterbunt und toll.

Ich erwarte jedenfalls keinen "Hawaii" Moment.

Ich würde dennoch gerne mal wissen wie die Leute auf 30 Jahre kommen. Ich bin jetzt keine Mathe-Ass, aber nach Adam Ries sind es 29 Jahre. Aber gut, was weiß ich schon. Vllt. geht es auch um den ersten Furz der zu Ehren von Ati gelassen wurde.
Gib mal lieber den AMD-lern 'ne Valium aus. :) Die hatten wahrscheinlich zuviel! :freak:

Celebrating 30 Years of Graphics & Gaming at AMD
Wie soll ich das ausrechnen? ;) AMD-Graphics=30 Jahre???, wäre nicht Radeon besser gewesen? So ein Schwachsinn, aber naja, denn, geht ja gleich los.

M4xw0lf

2014-08-23, 16:06:30

Huuuh, sie haben flüssigen Stickstoff auf der Bühne. :uup:

hardtech

2014-08-23, 16:06:42

eine fun veranstaltung... "zitat live aus dem stream" :D

Unicous

2014-08-23, 16:11:43

Neue FX-CPUs.

Yay.:uclap:

hardtech

2014-08-23, 16:13:07

also nur tonga wird vorgestellt. boooring.
und wie der name radeon zustande kam.... das ist der name, den eine mutti vorgeschlagen hat. "how cool is that?!"

M4xw0lf

2014-08-23, 16:20:01

AHA; sie stellen DOCH neue FXe vor! Me:1 Unicous:0 :tongue:

Unicous

2014-08-23, 16:25:17

Ich habe deine Frage beantwortet. Es geht exklusiv um Ati/AMD Radeon. Ich habe nichts über FX CPUs gesagt.:tongue:

Beyond Earth hat Day1 Mantle Support.

M4xw0lf

2014-08-23, 16:37:08

Kann jemand die Tonga-Auktion bei ebay finden?

fondness

2014-08-23, 16:38:23

Eigenes AMD Schiff in Star Citizen

Sapphire mit folgenden 285-Karten:

Sapphire is preparing six Radeon R9 285 cards:

SAPPHIRE R9 285 2GB GDDR5 ITX COMPACT OC Edition (UEFI)
SAPPHIRE R9 285 2GB GDDR5 ITX COMPACT Edition (UEFI)
SAPPHIRE DUAL-X R9 285 2GB GDDR5 OC (UEFI)
SAPPHIRE DUAL-X R9 285 2GB GDDR5 (UEFI)
SAPPHIRE DUAL-X R9 285 4GB GDDR5 OC (UEFI)
SAPPHIRE DUAL-X R9 285 4GB GDDR5 (UEFI)

http://www.sapphiretech.com/presentation/product/?cid=1&gid=3&sgid=1227&pid=2442&psn=&lid=1&leg=0

Unicous

2014-08-23, 16:39:25

http://www.ebay.com/itm/Worlds-1st-AMD-Radeon-R9-285-for-AMD30Live-Childs-Play-charity-auction-/121417779452?pt=PCC_Video_TV_Cards&hash=item1c451048fc

fondness

2014-08-23, 16:40:22

Da kommt schon noch was:

AMD Radeon Graphics @AMDRadeon

Aw, I don't want to spoil the surprise. You'll have to tune in to find out: http://amd.com/amd30live . ;) #AMD30Live