AMD Interposer Strategie - Zen, Fiji, HBM und Logic ICs

Anders: Interposer maximal 858mm² dabei musste aber noch einiges für HBM abziehen biste bei den oft genannten:

~550-570mm² ca der DIE selbst... bleibt nicht viel übrig für weitere (mehr als 4) Stacks

Die Stacks komplett anders montieren ( länge ) würden 6 drauf passen ( vielleicht )

UMC macht die Teile. Schau was deren Maschine max kann. Ist zwar nur simples Silizium, muss aber auch belichtet werden.

Auch nannte AMD selbst Reticle Limit in Bezug zu HBM. Von daher klare Sache ^^
 
Zuletzt bearbeitet:
Außerdem bedeutet eine Erhöhung der Stack-Anzahl auch eine weitere Verkomplizierung der Verdrahtung, auch der Memorycontroller im Hauptdie muß fetter werden und verbrät damit mehr Energie. Wenn man die zusätzliche Bandbreite, die man dadurch gewinnt, nicht braucht, dann ist das nicht nur sinnlos, sondern so kontraproduktiv wie damals die 512 bit bei der 2900XT. Mit den 4 Stacks jetzt gibt es doch schon mehr als genug Bandbreite bis zum Abwinken.

Nee, für mehr Kapazität muß man einfach auf größere Stacks warten, so bitter es ist (gerade im professionellen Segment wären z.B. 16 GB oder mehr bei einer GPU wie Fiji bestimmt sehr willkommen), aber alle anderen Varianten wären nicht sinnvoll.
 
Fiji mit HBM auf Interposer:

4w7WRSA.jpg


Von der AMD Pressekonferenz heute morgen.

Edit: Also da würden auch 8 HBM Stacks drauf passen, so wie das aussieht. Das Problem ist halt, dass Fiji auf vier beschränkt ist - der hat halt nicht mehr Anschlüsse.
 
Zuletzt bearbeitet:
Fiji ist schon ein kleines Monster..

Die HBM Stacks sind denke ich nicht ohne Grund so angeordnet. Da kann man ohne Mühe noch 4 weitere drauf packen.
Das Bild ist aber so unscharf, dass man nicht erkennt, ob da die freien Flächen schon kontaktiert sind.
 
Hier ist noch ein anderes Bild:

k3khUFH.jpg


Von VideoCardz.
 
Hier eine Abhandlung von AMD zu den kommenden Speicherarchitekturen und deren Anbindung:
http://www.amd.com/Documents/AMD-Research-Report-2014-1776.pdf

Öha ... das PDF von 2014 war noch nicht auf meinem Radar .. interessantes Schema dort ... ein Quad-MCM mit 4x2 Speicherkanälen ... zwar nur ein Schema und auch nur im Kontext zu HBM, aber die dort beschriebenen Features dürten die sein, die sie zu Hypertransport hinzugefügt haben.

Sieht auf alle Fälle interessant aus. Trotz aller Schematik bekommt die Quad-MCM-Spekulation plus Octochannel dadurch nen Glaubwürdigkeitsbonus (bleibt nur zu hoffen, dass die Gerüchte nicht wg. des Papers entstanden ^^)
 
Die HBM Stacks scheinen ein Stück weit größer als angekündigt zu sein. Ob das (Dual-Link) Stacks mit 2GB das Stück sind?
 
Außerdem bedeutet eine Erhöhung der Stack-Anzahl auch eine weitere Verkomplizierung der Verdrahtung, auch der Memorycontroller im Hauptdie muß fetter werden und verbrät damit mehr Energie. Wenn man die zusätzliche Bandbreite, die man dadurch gewinnt, nicht braucht, dann ist das nicht nur sinnlos, sondern so kontraproduktiv wie damals die 512 bit bei der 2900XT.
So ist dies aber nicht mehr konzipiert bei HBM. Die Interfaces sitzen auf dem HBM Stack und die GPU benötigt keine Änderung wenn mehr Speicher verbaut wird. Auch der Interposer bleibt wie er ist, da derzeit lediglich 10-50% Auslastung erreicht werden mit CPU/GPU/APU<->HBM Kommunilation.

Die Verbindung von der GPU durch die TSV und die µbumps zum Speicherinterface des HBM-Logic Chips am Boden des Stacks, ist die selbe Verbindung und Kapazität, die von den einzelnen Shadern über den ganzen Die bis an ein Ende geleitet wird wo das 512-SI sitzt. Nur ist es runter durch den Chip->TSV--->Interposer->HBM deutlich kürzer (3-5 mm) als quer über den ganzen Chip der ca. 20x20 mm hat . Deshalb kann man das Speicherinterface sozusagen "Outsourcen" auf einen anderen Die der durch den Interposer die selbe "Verdrahtung" hat als wäre er onDie.
Energy-efficient GPU Design with Reconfigurable In-package Graphics Memory
In this section, we present a reconfigurable memory interface that can dynamically adapt to the demands of various applications based on dynamically observed memory access and performance information. On top of the reconfigurable memory interface hardware, we further propose two reconfiguration mechanisms, EOpt and PerfOpt, that optimize system energy efficiency and performance (in terms of throughput), respectively.
Dort sind auch präzise Strommessungen zu finden im Vergleich zu konventionell angebundenem GDDR.

Ich habe auch gerade den Abschnitt gefunden der die Hardwarenabindung beschreibt:
4.2 Memory Interface Hardware Design
Our reconfigurable memory interface is aware of these different application behaviors, such that the bus width and memory frequency
can be dynamically tuned according to the observed performance and memory access information of each workload.
Hardware implementation:
At the interface between the GPU processor and the in-package graphics memories, we add a central controller, control signals to the bus drivers, and controls for dynamic VF scaling (Figure 2(b)). The central controller is used to collect global information of GPU performance and memory accesses. A vector of counters are maintained in the controller to collect performance and memory access information from either GPU hardware performance counters or memory controllers. A threshold register vector is used to store various thresholds and initial values described in reconfiguration mechanism. The calculator module calculates system energy efficiency based on the collected performance information and the estimated power consumption. The memory intensity is calculated as the memory accesses per 1000 instructions

Overhead:
The reconfigurable memory interface incurs both area and performance overheads. The total storage overhead is 128B, including various counters, registers, and arithmetic logic components shown in Figure 2(b).

The bus transmission lines are routed on the silicon interposer, which has sufficient space for the buses. To estimate the performance overhead, we evaluated the total latency of memory access pattern change detection and reconfiguration from 100 to 1000 cycles, i.e., 300ns to 3?s at 325MHz GPU core clock frequency in our baseline. We measured the execution time of various applications, and the maximum and minimum values are 6,000,000 cycles (18ms) and 40,000 cycles (120?s), respectively. Therefore, the maximum performance overhead is estimated as 3?s/120?s, which is less than 2.5% of total execution time

attachment.php


Öha ... das PDF von 2014 war noch nicht auf meinem Radar .. interessantes Schema dort ...
Ja mir war es auch entgangen bis kürzlich. Doch AMD verbessert derzeit kontinuierlich die Webseite, so dass der Bereich umgestellt wurde. Darunter fiel mir diese Sektion auf, die eine sehr schöne Liste der relevanten "Researches" hat. Es lässt sich sehr gut nach diesen Begriffen recherchieren, doch diesen Link hat AMD selber auch gehostet unter dem Reiter "Research Report"
http://www.amd.com/en-us/who-we-are...#journal-conference-and-workshop-publications

Ich glaube dieses wäre für dich interessant Opteron, aus dem Jahr 2013:
On-Chip Networks for Multicore Systems

Es ist im Prinzip so, dass in 2012/2013 die Technologien publiziert wurden die heute in Produkten teilweise zum Einsatz kommen.
 

Anhänge

  • HBM_Memory Controller_Split.JPG
    HBM_Memory Controller_Split.JPG
    61,6 KB · Aufrufe: 567
Zuletzt bearbeitet:
Ich könnt mir gut Vorstellen das die Geschwindigkeit schon was aus machen könnte.
Erst einmal müssen die Texturen (als größter Posten) ihren Weg in den VRAM finden und dabei ist leider noch PCIe 2.0/3.0 der Flaschenhals.
...über den ganzen Die bis an ein Ende geleitet wird wo das 512-SI sitzt.
Dazu müsste man wissen ob und welches Logic Die (als Bestandteil des HBM Stacks) von AMD bestellt wurde. Zur Zeit ist das noch Spekulation.
 
Die RAM-Größe ist gar nicht mal so sehr das Problem im Moment - scheinbar. Bei den meisten Spielen in 4K scheint - derzeit jedenfalls - 4 GB vollkommen auszureichen. Manche nutzten nicht mal mehr, selbst wenn sie könnten (da macht ein Vergleich zwischen R9 290X mit 4 und 8 GB zum Beispiel keinen Unterschied). Zusätzlich wird Fiji sicher auch noch die mit Tonga neu eingeführte "lossless delta color compression" nutzten. Und AMD sagte ja schon, dass die bezüglich der RAM-Ausnutzung auch noch etwas Treiberseitig optimieren wollen (wie auch immer das aussieht).
 
Erst einmal müssen die Texturen (als größter Posten) ihren Weg in den VRAM finden und dabei ist leider noch PCIe 2.0/3.0 der Flaschenhals.

Schreibt wer?
Gut möglich das der Unterschied wegen GDDR5 so gering war,aber ich denke da zu werden wir bald einen Vergleich mit HBM haben.....
Auch könnt ich mir vorstellen das mit HBM "weniger"geladen werden muss um aufs gleiche Ergebnis zu kommen.
 
Zumindest verläuft der Ablauf im Vergleich zum GDDR5 " Straffer " ab... wie man das mit den bekannten Methoden noch vergrößern kann, darauf bin ich gespannt @Tests.
 
Texturen belegen mit Texture Streaming einen festen Speicherbereich den sie zugewiesen bekommen. Es werden dann entsprechende MIP-Levels nachgeladen. Das bedeutet hier wird nicht mehr erst mal der VRAM damit geflutet und es bedeutet auch, dass es einige Optimierungen geben wird, die das ganze nicht mehr so simple machen. Konsolen arbeiten schon lange so. Auch Nvidia nutzt dies bei The Witcher 3:
http://www.geforce.com/whats-new/gu...ng-guide#texture-streaming-config-file-tweaks
Texture Streaming Tweaks

Earlier, we revealed that the Ultra Texture Quality setting merely increases the maximum number of textures stored in video memory, minimizing the chance of visible texture streaming. To increase this number, edit TextureMemoryBudget= in the [Rendering] section.

[Rendering]
TextureMemoryBudget= [Ultra Value: 800]

Several other values are also editable, supposedly increasing the distance at which characters, character heads, and general textures are streamed in, though we observed no benefit even with values doubled.

[Rendering]
TextureStreamingCharacterDistanceLimit= [Default Value: 50]
TextureStreamingHeadsDistanceLimit= [Default Value: 10]
TextureStreamingDistanceLimit= [Default Value: 40000]

Tweaking Wrap-Up
 
Das bisher klarste Bild von dem neuen Chip, wie ich finde (von PCPer):

pyMz3yZ.jpg


Edit: Ich komme grob geschätzt auf folgende Maße:

Package (Metallrahmen): 52x52mm
Interposer: 35x27,2mm ~= 952mm²
Fiji: 22x25,55mm ~= 562mm²

Edit2: Ausgehend von HBM gleich ca. 7,3*5,5mm, was in einer Folie von Hynix stand
 
Zuletzt bearbeitet:
Ich hab gerade auch mal nachgerechnet und komme auf ziemlich ähnliche Werte. (etwas kleiner, nämlich ca 26 mm x 20 mm also 520 mm², da ich von den 7 x 5 mm aus AMDs Präsentation ausgegangen war.)
 
Das bisher klarste Bild von dem neuen Chip, wie ich finde (von PCPer):

pyMz3yZ.jpg


Edit: Ich komme grob geschätzt auf folgende Maße:

Package (Metallrahmen): 52x52mm
Interposer: 35x27,2mm ~= 952mm²
Fiji: 22x25,55mm ~= 562mm²

Edit2: Ausgehend von HBM gleich ca. 7,3*5,5mm, was in einer Folie von Hynix stand
Schönes Bild! Hier sieht man schon, dass höchstens noch 2 Stapel hinpassen würden.
 
Zurück
Oben Unten