Intel-CPU mit AMD-Grafik (Kaby-Lake-G)

[unl34shed]

-EMIB sind kleine Interposer. Du brauchst trotzdem auf dem Chip ein Interface das den EMIB anbindet. Wie du meinen Grafiken entnehmen kannst (und auch den verlinkten noch umfangreicheren Quellen). Niemand sagt EMIB wäre ein Interface - der Chip braucht dennoch ein Interface um EMIB anzubinden.

Von Interface spicht keiner, aber in jedem Post heißt es EMIB Interface :confused:
Pinout wäre wohl der passendere Terminus anstelle von Interface.

EMIB ist wie "Draht" eine Elektrische Verbindung zwischen zwei Chips, mehr nicht. Ein Ethernet-Kabel wird ja auch nicht Interface genannt ;)

-Flipchips gibt es schon lange. Mit und ohne TSV, das hängt nicht von Flipchip ab. TSV dienen bei Interposer Designs auch zur Wärmeableitung. Siehe Grafik.


Das eine hat mit dem anderen nichts zu tun. Ja die TSVs mögen evtl. zur Kühlung vorhanden sein, aber es macht keinen Unterschied, ob der Chip auf EMIB/Interposer oder direct auf dem Substrat sitzt, so wie du es in #245 behauptet hast.

Die TSVs werden im Interposer gebraucht um auf die andere Seite zu kommen (Chip -> Substrat) darunter zählen externe Signale (PCIe, HDMI, DP, ...), sowie die Versorgungsspannung, etc. Das entfällt bei EMIB, da der Chip für diese Signale direkten Kontakt zum Substrat hat.

Ein Chip mit GDDR5 Interface kann weder über einen Interposer noch über ein EMIB an HBM angebunden werden. Ein Chip mit HBM/Interposer Interface kann nicht über EMIB angebunden werden.

Könnte er auch nicht mit Draht, da GDDR5 und HBM komplett verschiedene Signale sind :confused:
Es spräche aber nichts dagegen GDDR5 auf einen Interposer zu packen, außer die benötigte Fläche ;)
Oder GDDR5 extern als Speichererweiterung neben HBM zu nutzen, trotz Interposer. Man setzt in dem Fall aber wohl eher auf einen weiteren HBM Stack.

E: Übrigens: Embedded Multi-Die Interconnect Bridge (EMIB)

[Complicated]

Von Interface spicht keiner, aber in jedem Post heißt es EMIB Interface :confused:
Pinout wäre wohl der passendere Terminus anstelle von Interface.

Also wenn du GDDR5, HBM und EMIB Anbindungen generell bezeichnen willst ist das "Interface auf dem Chip" nach wie vor das richtige. Und wenn ich EMIB-Interface schreibe kannst du es dir ja zu "Pinout" übersetzen - es bleibt das selbe.

Deiner Argumentation zu folgen würde bedeuten, dass Fiji kein HBM-Interface besitzt? Das kannst du nicht ernsthaft behaupten. Ebenso wird die dGPU für EMIB ein Interface besitzen um den HBM anzubinden. Dieses wird sich unterscheiden von den in Polaris verbauten Interfaces und von den in Vega verbauten Interfaces - niemand nennt das dort "Pinout".

Alle deine Ausführungen sind nicht falsch, gehen aber an dieser Aussage vorbei. Auch widerspricht sich das nicht. Du redest vom Package und ich rede ausschließlich vom ASIC. Und da sage ich, dass ein Chip der für Interposer vorgesehen ist nicht über EMIB angebunden werden kann mit HBM.

[unl34shed]

Also wenn du GDDR5, HBM und EMIB Anbindungen generell bezeichnen willst ist das "Interface auf dem Chip" nach wie vor das richtige. Und wenn ich EMIB-Interface schreibe kannst du es dir ja zu "Pinout" übersetzen - es bleibt das selbe.

Immer noch nicht, du schmeißt alles in einen Topf:
GDDR5, HBM -> Datenbus oder Layer 1-4 im ISO-Schichten-Model
EMIB, Interposer(passiv) -> "Draht" oder Layer 0 im ISO-Schichten-Model

Für einen Bus gibt es ein Interface, für Draht nicht. Das der Bus eben über diesen Draht geführt werden kann, macht kein Interface daraus.

Und da sage ich, dass ein Chip der für Interposer vorgesehen ist nicht über EMIB angebunden werden kann mit HBM.

Kann er schon, wenn beim Design entsprechend nachgedacht wurde.
Der Unterschied zwischen EMIB und Interposer ist, dass die Balls entsprechend anders angeordnet werden müssen. Ein Chip, der auf EMIB passt, passt auch auf einen Interposer, umgekehrt jedoch nicht (zwingend).

Alle deine Ausführungen sind nicht falsch, gehen aber an dieser Aussage vorbei. Auch widerspricht sich das nicht. Du redest vom Package und ich rede ausschließlich vom ASIC.

Ist jetzt die Frage wo man die oberen Metal-Layer dazu zählt, beim BGA (eigentlich CSP) als Package oder schon zum ASIC. Aber die groben Layer sind keine teuren Masken.

[Windi]

Ich habe EMIB auch so verstanden, das es sich nur um eine neue Art von Leiterbahnen handelt. Bei allen News über EMIB habe ich weiterhin von HBM- und DDR-Speicher gelesen. Nie wurde etwas von eigenständigen EMIB Interfaces geschrieben.

Man braucht vielleicht einen Adapter-Layer, damit die "Kontakte" an der richtigen Stelle aus dem Chip kommen. Aber man kann weiterhin die bestehenden Speicherkontroller/Interfaces auf dem Chip nutzen.
Wer keinen Adapter haben will, der muss halt die letzte(n) ein oder zwei Metall-Layer anpassen. Dafür benötigt man aber nur die primitivsten/gröbsten Belichtungsmasken aus dem gesamten Produktionsprozess. Das ist nur eine minimale Anpassung und für mich noch kein komplett neu entwickelter Chip.

[Complicated]

Immer noch nicht, du schmeißt alles in einen Topf:
GDDR5, HBM -> Datenbus oder Layer 1-4 im ISO-Schichten-Model
EMIB, Interposer(passiv) -> "Draht" oder Layer 0 im ISO-Schichten-Model

Ich schmeiß überhaupt nichts in einen Topf. Du siehst doch dass du hier verschiedene Layer miteinander vergleichst. Und nun erkläre mir bitte auf der Grundlage deines Modells wie die Daten auf den EMIB kommen. Auch EMIB funktioniert nicht ohne Datenbus (28 gbps). Das was bei der Nutzung eines Interposer auf einer GPU (HBM-Interface) verbaut werden muss verschwindet nicht im Nichts wenn man einen EMIB anstatt eines Interposers nutzt. Auch hier muss auf dem ASIC ein Interface vorhanden sein, je nachdem was angebunden wird. Nur können die Interfaces nicht die selben sein wie bei einem Interposer Design.

Schau mal hier:
http://www.tomshardware.com/news/intel-emib-interconnect-fpga-chiplet,35316.html
https://img.purch.com/x9999-png/o/aHR0cDovL21lZGlhLmJlc3RvZm1pY3JvLmNvbS9BL0wvNzA1NDA1L29yaWdpbmFsL3g5OTk5LlBORw==

Intel is working with partners to develop chiplets, which are small re-usable IP building blocks that can be processors, transceivers, memory, or other types of components. Intel can mix and match the chiplets, much like Lego blocks, and connect them to the FPGA to create custom designs for different application use-cases.

Chiplets are a great idea, but a standardized SiP interface between components is important, especially if other companies are involved in the effort. The AIB and UIB interface IP blocks we see on the Stratix 10 die are the key. UIB connections are a general-purpose SiP interface for HBM and ASICs, while AIB supports transceiver connections and other generalpurpose components.

Intel subdivides the AIB PHY into 25 logical channels, with 24 exposed to the user and one dedicated to handshaking operations. We can also see the standard EMIB interface, with the smaller microbumps dedicated to the digital interface while the larger connections handle analog.
Dieses "Chiplet" (ASIC) mit EMIB-Interface kannst du auf einem Interposer nicht nutzen, sondern nur EMIB als Interconnect verwenden. Die 55um pitch bumps binden das Interface des Chips an das EMIB an.

Noch eine direkte Vergleichsgrafik aus der selben Quelle:
https://img.purch.com/x1-png/w/755/aHR0cDovL21lZGlhLmJlc3RvZm1pY3JvLmNvbS9BL0ovNzA1NDAzL29yaWdpbmFsL3gxLlBORw==

[unl34shed]

Ich schmeiß überhaupt nichts in einen Topf. Du siehst doch dass du hier verschiedene Layer miteinander vergleichst. Und nun erkläre mir bitte auf der Grundlage deines Modells wie die Daten auf den EMIB kommen. Auch EMIB funktioniert nicht ohne Datenbus (28 gbps).

Ich wollte dir mit den Layern nur aufzeigen, das du das Medium als Interface bezeichnest. Du stellst hier die verschiedenen Layer als gleich dar. EMIB kann nichts, das ist nur eine simple Verbindung zwischen zwei Chips.

Woher kommen die 28gbps? THW spricht von 2gbps pro Pin, wohl das physikalische Limit.

Das was bei der Nutzung eines Interposer auf einer GPU (HBM-Interface) verbaut werden muss verschwindet nicht im Nichts wenn man einen EMIB anstatt eines Interposers nutzt. Auch hier muss auf dem ASIC ein Interface vorhanden sein, je nachdem was angebunden wird. Nur können die Interfaces nicht die selben sein wie bei einem Interposer Design.

<snip>

Die 55um pitch bumps binden das Interface des Chips an das EMIB an.

Das HBM-Interface sind 1024 Pins (plus Kleinvieh) auf der Unterseite des Chips, wüsste nicht, wo ich geschrieben habe, das das wegfallen sollte? Das einzige was sich ggf. ändert ist, wie schon geschrieben, die Anordnung der Pins, um auf den EMIB zu passen, allerdings sollten diese eh schon am GPU-Rand liegen. Was eben nur die letzten Metal-Layer betreffen sollte.
Auch frage ich mich, warum ein 55µm Pitch nicht auf einem Interposer möglich sein sollte, der in 60 oder 130nm gefertigt ist.


Wie gesagt EMIB ist nur der "Draht" oder das Medium, der die beiden Chips verbindet und kein Spezielles Interface braucht. Ja Intel hat mit AIB und UIB wie du ja selbst zitiert und fett markiert hast zwei Interfaces standardisiert für EMIB, diese sind aber nicht Pflicht! Sie erleichtern nur Partnern Chips zu liefern, die einheitlich eingebunden werden können.

Du kannst auch gerne dein zweites Bild anschauen, ganz unten wird EMIB auch nur Interconnect bezeichnet.

[Complicated]

Die 28 Gbps kommen von Intel.
Folgende Versionen sollen 56 gbps können.
Die Werte stehen pro EMIB-Brücke.

Du schriebst so etwas wie ein EMIB-Interface existiere nicht.
Du beharrst darauf was EMIB ist und ich sage, das dies keine Rolle spielt, dass der Chip ein Interface benötigt dafür. Das ist als ob ich dir erklären würde HBM wäre Speicher und kein Interface weil du HBM-Interface geschrieben hast.

2 gbps mit bis zu 20.000 Leitungen pro Chip sind ein theoretischer maximalwert.

[unl34shed]

Ok, glaub doch was du willst, ich geb auf.

[Complicated]

Ok, glaub doch was du willst, ich geb auf.

Das hat doch nichts mit glauben zu tun. EMIB benötigt ein Interface auf dem Chip. Dass du das abstreitest ist äusserst rätselhaft. Dass du es damit begründest EMIB sei ein Interconnect ist noch schräger. PCIe ist ebenfalls ein Interconnect und auf Chips gibt es Interfaces.

Hier noch die Quelle zur 28gbps und den verwendeten Interface Serdes beim stratix 10
http://www.linleygroup.com/newsletters/newsletter_detail.php?num=5607

[unl34shed]

PCIe definiert aber das gesamte Protokoll, also Layer 1-4 und wird idr. über Kupferleiterbahnen verdrahtet (Layer 0). Anstelle Von Kupfer werden aber auch teilweise Interposer verwendet (Vega, Fiji) und genauso ist es auch denkbar EMIB dafür zu nutzen. Denn EMIB ist wie die Leiterbahnen nur das Medium!

Und die 28gbps sind eine Implementierung bei dem FPGA, kein Limit oder Besonderheit von EMIB.

[Complicated]

PCIe definiert aber das gesamte Protokoll, also Layer 1-4 und wird idr. über Kupferleiterbahnen verdrahtet (Layer 0). Anstelle Von Kupfer werden aber auch teilweise Interposer verwendet (Vega, Fiji) und genauso ist es auch denkbar EMIB dafür zu nutzen. Denn EMIB ist wie die Leiterbahnen nur das Medium!und was hat das nun damit zu tun, dass auf den Chips ein Interface für PCIe und EMIB vorhanden sein muss um diese Leiterbahnen anzubinden und Daten darüber zu übertragen?
Welches Protokoll wird denn über EMIB übertragen deiner Auffassung nach?

Also langsam bekomme ich den Eindruck du willst mich absichtlich falsch verstehen, oder du versuchst auf Teufel komm raus den Unsinn den du geschrieben hast rabulistisch zu verwässern.

Ich schrieb selber dass dies die aktuelle Implementierung ist und dass die theoretische Leistung höher liegt:
2 gbps mit bis zu 20.000 Leitungen pro Chip sind ein theoretischer maximalwert.
Folgende Versionen sollen 56 gbps können.
Was verstehst du daran nicht?

Auch frage ich mich, warum ein 55µm Pitch nicht auf einem Interposer möglich sein sollte, der in 60 oder 130nm gefertigt ist..Zitiere bitte mal wo ich das geschrieben haben soll - hier ist wohl eher dein Textverständnis das Problem. Und wenn du nun 100 mal wiederholst EMIB sei eine Leiterbahn, so ändert das nichts daran, dass diese Leiterbahn die Daten von einem Chip bekommt der mittels spezifischem Interface an der EMIB Leiterbahn angeschlossen ist. Das nennt man dann EMIB-Interface wie dir nun auch die Quellen belegt haben. Eine AMD GPU die für Interposer-Einsatz designed wurde hat ein solches Interface nicht, da sie keine 55um pitch bumps besitzt, die spezifisch bei EMIB zum Einsatz kommen. Niemand nutzt sie derzeit bei Interposern - warum auch da sie teurer herzustellen sind und die Standard 100um bumps alle Zwecke erfüllen. Zumal man für EMIB zwei bump Größen implementieren muss anstatt nur eine.
Denn EMIB ist wie die Leiterbahnen nur das Medium!So wie ein Interposer auch - wozu also HBM-Interfaces auf Fiji und Vega? Und wieso keine mehr auf Kabylake-G?

[Kriton]

Mir scheint Ihr solltet erst einmal eure Definitionen vereinheitlichen bevor ihr auf deren Basis diskutiert.

[unl34shed]

und was hat das nun damit zu tun, dass auf den Chips ein Interface für PCIe und EMIB vorhanden sein muss um diese Leiterbahnen anzubinden und Daten darüber zu übertragen?

Und noch mal EMIB ist kein Interface.


Welches Protokoll wird denn über EMIB übertragen deiner Auffassung nach?


Da es nur das Medium ist, ist kein spezifisches Protokoll notwendig. Wird ein HBM chip angebunden, dann laufen da die HBM Signale drüber, ist es PCIe, dann halt PCIe.... oder im Fall von Intels FPGA SiPs AIB und UIB.
Ein EMIB-Protokoll, das ein spezielles Interface bräuchte gibt es nicht.

Und wenn du nun 100 mal wiederholst EMIB sei eine Leiterbahn, so ändert das nichts daran, dass diese Leiterbahn die Daten von einem Chip bekommt der mittels spezifischem Interface an der EMIB Leiterbahn angeschlossen ist. Das nennt man dann EMIB-Interface wie dir nun auch die Quellen belegt haben.

Die Pins des Chips werden mit Lötkugeln auf dem Substrat (das auch den EMIB beinhaltet), in einer nicht spezifizierten Anordnung angebunden. Willst du das wirklich Interface nennen?

Deine Quelle hat da einfach etwas falsch zusammengefasst. Auf der Intel Seite zu EMIB sucht man das Wort Interface vergeblich (https://www.intel.com/content/www/us/en/foundry/emib.html)

Eine AMD GPU die für Interposer-Einsatz designed wurde hat ein solches Interface nicht, da sie keine 55um pitch bumps besitzt, die spezifisch bei EMIB zum Einsatz kommen. Niemand nutzt sie derzeit bei Interposern - warum auch da sie teurer herzustellen sind und die Standard 100um bumps alle Zwecke erfüllen. Zumal man für EMIB zwei bump Größen implementieren muss anstatt nur eine.


Sie hat ein anderes Package, ja. Aber EMIB ist deshalb immer noch kein Interface.

Des weiteren wären auch 55µm bumps auf einem Interposer möglich. Man macht es nicht (wie du richtig sagst) weil man es nicht muss, möglich wäre es aber auch.
Umgekehrt würde EMIB auch mit 100µm bumps funktionieren. Dann wird das ganze halt etwas größer.

So wie ein Interposer auch - wozu also HBM-Interfaces auf Fiji und Vega? Und wieso keine mehr auf Kabylake-G?

Ist doch ganz einfach, das HBM-Interface gibt es um mit dem HBM zu kommunizieren.
Da Kabylake-G auch auf HBM setzt, wird er auch ein HBM Interface besitzen. Das hat aber weder etwas mit Interposer noch mit EMIB zu tun.

Sorry für das verstümmeln deines Posts. Ist keine gute Art, aber hier ging es leider nicht anders.

[Complicated]

Und noch mal EMIB ist kein Interface.Und ich habe das nicht behauptet - zu keinem Zeitpunkt. Daher ist das ein Argument wofür?

Und doch kann man einen Chip nicht an ein EMIB anbinden ohne ihm ein Interface für EMIB zu geben. Das Standard-Interface für EMIB geht aus den Quellen hervor.

Natürlich wäre 55um bumps auf Interposer möglich. Nur benutzt es niemand. Und es hat auch niemand behauptet es wäre nicht möglich. Ebenso wenig wie 70um, 80 um oder 120 um bumps. Wo ist das Argument?

Derzeit benutzt AMD für sein GPUs >100um Bumps für Interposer. Damit lassen sich keine EMIB Brücken anbinden. Es werden 55um bumps benötigt, was die Spezifikation der EMIB Anbindung ist.
Da Kabylake-G auch auf HBM setzt, wird er auch ein HBM Interface besitzen. Das hat aber weder etwas mit Interposer noch mit EMIB zu tun.Und dieses wird anders sein als das Interface, welches für Interposer-Designs verwendet wird. Daher auch meine Bezeichnung als "EMIB-Interface" (Das Interface beschreibt/bezeichnet den EMIB Interconnect ebenso wenig wie ein Speicherinterface den Speicher beschreibt/bezeichnet). Die Unterscheidung zwischen 100 um bumps (Interposer) und 55 um bumps (EMIB und nur an den Stellen wo das EMIB angeschlossen wird an den Die) alleine macht das schon nötig und zudem auch die Geschwindigkeit die bei EMIB mit 28 gbps angegeben ist in der derzeitigen Implementierung (möglich wären auch die nächste Ausbaustufe mit 56 gbps)
Deine Quelle hat da einfach etwas falsch zusammengefasst. Auf der Intel Seite zu EMIB sucht man das Wort Interface vergeblich (https://www.intel.com/content/www/us/en/foundry/emib.html)Wenn du so etwas behauptest, biete mir eine Alternative Quelle an wo das richtig zusammengefasst ist. Anhand von nicht erwähnen eines technischen Details auf einer Marketingseite jedenfalls wird daraus keine valide Argumentation. Solange gilt die Quelle als Referenz und als valide wenn du nichts anderes hast. Die von dir verlinkte Seite erwähnt viele Details nicht, die wir deswegen nicht als unwahr erachten.

/Ironie Um deine Art der Argumentation "gegen dich" zu verwenden:
Ist doch ganz einfach, das HBM-Interface gibt es um mit dem HBM zu kommunizieren.
HBM ist keine Interface es ist ein Speicher, daher gibt es kein HBM Interface. /Ironi off
Da steckt doch keinerlei Logik dahinter ;)

[maguumo]

HBM ist keine Interface es ist ein Speicher, daher gibt es kein HBM Interface. /Ironi off
Da steckt doch keinerlei Logik dahinter ;)
Die Spezifikation von HBM (oder irgendeinem GDDR Typ, schau mal auf der JEDEC Homepage vorbei) bestimmt aber nicht nur wie man den Speicher zu basteln hat. Auch Kommunikationsprotokoll und Anbindung sind spezifiziert. Erinnerst du dich noch an die PHY Diskussion? Die sind Teil eines Interfaces. Das Interface meint den ganzen Logikhaufen der dafür sorgt das der Datenaustausch zwischen Chip und in diesem Fall Speicher läuft. Ob die Daten jetzt über Interposer, EMIB oder tausend per Hand gezogene Golddrähte laufen macht für das Interface keinen Unterschied (solange die Signale noch vernünftig ankommen).

[Complicated]

Und inwiefern benötigt jetzt deswegen EMIB kein Interface auf dem angebundenen Chip?
Das hat unl34shed behauptet.

Zumal die 55um bumps ja EMIB spezifisch sind. AMD hat bisher keine Chips gefertigt die mit diesen bumps ausgestattet waren. Erst das Semi-Custom Produkt für Intel ist EMIB-fähig.

[Screemer]

Weil emib nur der physische Layer für die Anbindung ist. Ist quasi wie die Specs für den pcie-Bus in der Speck für pcie. Darüber kann man aber auch andere Protokolle routen. Die phys in der gpu befeuern über die emib Anbindung den hbm. Solange die das können ist der physikalische Layer völlig wurst. Emib ist kein Protokoll sondern nur die physikalische Anbindung bzw. die technische Umsetzung derer.

[Complicated]

Wie schon zuvor zitiert aus toms Hardware von der Hot Chips 2017:
http://www.tomshardware.com/news/intel-emib-interconnect-fpga-chiplet,35316.html
Intel subdivides the AIB PHY into 25 logical channels, with 24 exposed to the user and one dedicated to handshaking operations. We can also see the standard EMIB interface, with the smaller microbumps dedicated to the digital interface while the larger connections handle analog.

Chiplet designers don't have to worry about specialized programming to leverage the interface--Intel claimed it abstracts away the complexity so the designer can focus on IP design. Intel didn't share details on the ostensibly more complex UIB interface, but we do know that both interfaces support up to 2Gbps per physical line (programmable).

[unl34shed]

Verdreh bitte nicht die Tatsachen, die Diskussion ging mit Post #245 los, als du behauptet hast AMD habe kein EMIB Interface. Da habe ich nur angemerkt, dass es so etwas wie ein EMIB-Interface nicht gibt, da es nur das Medium ist, durch das die Daten transportiert werden.


Wie schon zuvor zitiert aus toms Hardware von der Hot Chips 2017:
http://www.tomshardware.com/news/intel-emib-interconnect-fpga-chiplet,35316.html

Dann liegt Toms Hardware da vllt. falsch. Ich habe gehört, dass kann in einigen wenigen Fällen auch mal im Internet passieren. :eek:

In deinem Zitat ist AIB der Bus, für diesen gibt es ein Interface, für EMIB aber nicht. Für EMIB gibt es ein angepasstes Pin-out, damit das AIB Interface im EMIB geroutet werden kann.

Auch von dem THG Artikel:
http://c-7npsfqifvt34x24jnhx2eqvsdix2edpn.g00.tomshardware.com/g00/3_c-7x78x78x78.upntibsex78bsf.dpn_/c-7NPSFQIFVT34x24iuuqtx3ax2fx2fjnh.qvsdi.dpnx2fsx2f711y561x2fbIS1dEpwM32mAHmiMnKmd 4SwAn2qZ4KwMnOwcT0CM15wOaB2OEB4M30zbXeqcnGtMaB5MlqRSx78x3dx3dx3fj21d.nbsl.jnbhf. uzqf_$/$/$/$
Wie du siehst, hat der FPGA ein AIB Interface (PHY) dieser geht über die EMIB zum zweiten Chip, der ebenfalls ein AIB PHY besitzt.

[Complicated]

Ach und ich habe dir gezeigt, dass es ebenso gültig ist EMIB-Interface zu schreiben (wie es ja auch in dem Bericht passiert) wie HBM-Interface zu schreiben. Du willst lediglich den Begriff nicht anerkennen aus keinem sinnvollen Grund und startest eine Diskussion.

Ich schrieb AMD habe derzeit keine GPUs mit einem solchen EMIB-Interface (55 um bumps, AIB PHY, UIB PHY mit entsprechenden Spezifikationen). Es sind Custom-Designs und Fiji und Vega oder Polaris können nicht mit EMIB genutzt werden ohne Anpassungen am Die.
Ich sehe also nicht den geringsten Grund, warum man für diesen Chip plötzlich ein eigenes DIE auflegen müsste.
Das EMIB Interface ist auf keinem anderem Die vorhanden von AMD.GPU

- EMIB ist nur ein kleinerer Interposer, der in der Leiterplatte eingebettet wird und kein Spezielles Interface.
-EMIB sind kleine Interposer. Du brauchst trotzdem auf dem Chip ein Interface das den EMIB anbindet.


Dann liegt Toms Hardware da vllt. falsch. Ich habe gehört, dass kann in einigen wenigen Fällen auch mal im Internet passieren.
Weil es nicht in deinen Informationsstand passt?

Edit Zweite Quelle:
https://www.heise.de/newsticker/meldung/Hot-Chips-EMIB-statt-Interposer-fuer-Multi-Chip-Packages-3810319.html?hg=1&hgi=4&hgf=false

EMIB sieht zwei Arten von Schnittstellen vor. UIB ist für "dumme" Zusatzbausteine wie etwa HBM-Speicherstapel gedacht, die als Slave angesprochen werden. Für komplexere Bausteine mit eigenen Taktdomänen ist die flexiblere und leistungsfähigere AIB gedacht.Schnittstelle=Interface

[unl34shed]

Ach und ich habe dir gezeigt, dass es ebenso gültig ist EMIB-Interface zu schreiben (wie es ja auch in dem Bericht passiert) wie HBM-Interface zu schreiben. Du willst lediglich den Begriff nicht anerkennen aus keinem sinnvollen Grund und startest eine Diskussion.

Ist es in der Telefondose dann auch ein Draht-Interface, wenn ich die Telefonleitung da auflege?

Ich schrieb AMD habe derzeit keine GPUs mit einem solchen EMIB-Interface (55 um bumps, AIB PHY, UIB PHY mit entsprechenden Spezifikationen). Es sind Custom-Designs und Fiji und Vega oder Polaris können nicht mit EMIB genutzt werden ohne Anpassungen am Die.

Nur braucht AMD keinen AIB oder UIB um den HBM via EMIB mit der GPU zu verbinden. Das nutzt immer noch den selben 1024bit Bus (HBM-Interface) wie mit einem Interposer.

Ohne Scheiß, bei dir ist dein Name Programm, warum so kompliziert? :confused:

Weil es nicht in deinen Informationsstand passt?

Nein, es ist einfach falsch, das Interface zu nennen.
Bzgl. Informationsstand: Ich komme aus der Halbleiter Branche.

Edit Zweite Quelle:
https://www.heise.de/newsticker/meld...gi=4&hgf=false
Zitat:
EMIB sieht zwei Arten von Schnittstellen vor. UIB ist für "dumme" Zusatzbausteine wie etwa HBM-Speicherstapel gedacht, die als Slave angesprochen werden. Für komplexere Bausteine mit eigenen Taktdomänen ist die flexiblere und leistungsfähigere AIB gedacht.
Schnittstelle=Interface

Ja, die Interfaces sind AIB und UIB nicht EMIB.

[Complicated]

AIB und UIB sind EMIB-Interfaces (Schnittstellen)

[Complicated]

Bzgl. Informationsstand: Ich komme aus der Halbleiter Branche.

Ja, die Interfaces sind AIB und UIB nicht EMIB.Dann ist deine Verwirrung wohl eindeutig sprachlicher Natur, da ich nirgendwo behauptet habe EMIB sei ein Interface.
Nur braucht AMD keinen AIB oder UIB um den HBM via EMIB mit der GPU zu verbinden. Das nutzt immer noch den selben 1024bit Bus (HBM-Interface) wie mit einem Interposer.
Das ist genau das was ich nicht so sehe. Das Interface muss angepasst werden für EMIB, da AMD bisher keine 55um bumps auf ihren Chips hatte. Auf welchem Layer nun diese Anpassung stattfindet spielt keine Rolle, doch es muss eben ein neuer Die gemacht werden, da die bisher für Interposer benutzten Dies kein 55um bumps haben.

Übrigens hat AMD keinen 1024bit Bus, sondern ein 1024-bit Interface. Der Datenbus ist der Interposer.

[unl34shed]

Nein. AIB und UIB sind von Intel standardtisierte Schnittstellen für die Chip zu Chip Kommunikation. Ähnlich wie PCIe oder Infinite Fabric.
Und die Chips sprechen das AIB bzw. UIB Protokoll und sind mittels EMIB verbunden (EMIB ist hier nur die Leiterbahn zwischen den Chips).

Wenn dritte einen Chip an Intels FPGAs anschließen wollen, dann müssen diese ein bestimmtes Package haben um aufgelötet werden zu können und entweder ein AIB oder UIB Interface haben. EMIB ist aber nicht nur auf diese beiden Schnittstellen limitiert, HBM geht da z.B. auch. Auch die 55µm sind sehr sicher nicht fixe werte. Das ist Marketing blabla um zu sagen, "wir sind halb so groß wie Interposer" (oder viertel, mir egal). Wenn man nicht so kleine Strukturen benötigt, wird man diese auch vermeiden wollen.

Und nein, der Datenbus ist nicht der Interposer. Der Interposer ist passiv und nur die Leiterbahn zwischen den Chips.


Und jetzt noch einmal, AMD hat eventuell nicht das richtige Package/Pinout unterm Chip und müsste da eventuell anpassungen am Metal layer vornehmen. Aber das ist wie schon mehrfach gesagt, kein Interface.

[TGKlaus]

Nur braucht AMD keinen AIB oder UIB um den HBM via EMIB mit der GPU zu verbinden.


Und die Chips sprechen das AIB bzw. UIB Protokoll und sind mittels EMIB verbunden (EMIB ist hier nur die Leiterbahn zwischen den Chips).


Du merkst doch hoffentlich selber, das du dir andauernd direkt selbst widersprichst?! Und das was du schreibst gar nicht stimmen kann!

Besonders weil INTEL selbst angibt, UIB u.a. als Schnittstelle für HBM-Speicher gedacht ist.
Wenn EMIB dann wird UIB oder AIB benötigt. Ohne geht nicht.

[maguumo]

Was glaubst du denn was der UIB IP Baustein macht was die HBM Interfaces die AMD bis jetzt verwendet nicht können? Wenn man die Zitate nicht aus dem Kontext reißt sehe ich da auch keine Widersprüche.

[TGKlaus]

Mit EMIB umgehen können .....
Es sollte ja mittlerweile jeder mitbekommen haben, das das keine "1:1 Verdrahtung" ist

Kannst mir aber gerne zeigen wo INTEL (er)klärt wie EMIB ohne UIB/AIB nutzbar sein soll.


Bis dahin EOD.

[maguumo]

Doch, EMIB ist einfache 1:1 Verdrahtung, wie Interposer und organische/keramische Packages auch. Was sollte es denn sonst sein?

[TGKlaus]

Doch, EMIB ist einfache 1:1 Verdrahtung, wie Interposer

:facepalm:

Das kann man nur noch vorsätzliches getrolle ansehen.

Das ist schon so dumm, das könnte man schon als Signatur nehmen.


EOD

[unl34shed]

Beantworte doch die Frage, was es sonst sein soll, bevor du andere als dumm bezeichnest.

[gravitationsfeld]

EMIB ist die Chipverbindung, Protokolle sind ein anderer Layer. Man kann durchaus PCIe ueber EMIB fuehren. Ob es sinnvoll ist, ist eine andere Frage.

[Windi]

Da habe ich ja was ausgelöst.

Es wird zwar immer UIB angegeben, aber auch der HBM-Speicherkontroller und HBM-Speicher.
Das wirkt irgendwie komisch, als ob man ein Signal erzeugt und dann 2 Mal umgewandelt.

Für mich als Laien macht das keinen Sinn. Wenn ich speziellen EMIB-Speicher bräuchte, dann würde ich ihn auch so nennen. Und warum die alten HBM-Interfaces drin lassen und dann UIB dazwischen schalten?
Auch heißt das ganze UIB: Universal Interface Bus
Eine Logik, die alle möglichen Signale annimmt, in EMIB-Signale umwandelt und dann später wieder zurück wandelt, halte ich für nahezu unmöglich. Nicht das man Signale nicht wandeln könnte, aber dieses "Universal" halte ich für problematisch.

Für mich würde es am meisten Sinn ergeben, wenn UIB nur dafür steht das man das Pin-Out anpasst und nicht noch weitere Logik hinzugefügt.

[TGKlaus]

Was soll ich denn auf so einen falschen Quatsch noch antworten?

Es gibt recht ordentliche technische Beschreibungen von INTEL selbst (in English) und es gibt mit dem Stratix 10 MX eine erste praktische Umsetzung. Zugegebener Maßen nicht ausführlich dokumentiert, aber trotzdem informativ.

Und jetzt soll ich mit jemanden diskutieren, der das alles ignoriert und genau das Gegenteil behauptet was selbst die Basics von EMIB betrifft?

Warum?
Und bezahlst du mir die Zeit in der ich den "Lehrauftrag" erfülle?


Edit:

Man kann durchaus PCIe ueber EMIB fuehren.

Ja, aber das ist ja gerade einer der Punkte die man vermeiden will.

[Windi]

Wo kann man denn gescheite Informationen über EMIB finden?

Selbst in den PDFs zu dem Stratx 10 wird eigentlich nichts darüber geschrieben, was UIB überhaupt ist.

[maguumo]

Und jetzt soll ich mit jemanden diskutieren, der das alles ignoriert und genau das Gegenteil behauptet was selbst die Basics von EMIB betrifft?

Na was ignoriere ich denn? Kann ja nicht so schwer sein das aufzuzeigen wenn es so offensichtlich ist.

[Complicated]

Doch, EMIB ist einfache 1:1 Verdrahtung, wie Interposer und organische/keramische Packages auch. Was sollte es denn sonst sein?
Und haben Fiji und Vega deswegen kein Interface um an den interposer angebunden zu werden und den HBM ansprechen zu können? Niemand behauptet EMIB sei ein Interface. Ich weiss gar nicht wie oft ich das jetzt schon geschrieben habe.

Das selbe Interface auf dem Chip, welches auf den Interposer angebunden wird benötigt bumps die größer als 100 um sind. Für EMIB müssen die bumps am Rand des Chips 55um groß sein wo die AIB mit EMIB verbunden werden (Schnittstelle!=Interface).

Warum ist das für manche trotz Bebilderung und ausführlicher multipler Quellen nicht zu begreifen? Vega, Polaris und Fiji haben keine solchen 55um bumps. Selbst die HBM stacks, welche bei Vega zum Einsatz kommen können kein EMIB, da es keine Schnittstelle gibt mit UIB und 55um bumps. Hier muss der unterste Logic-Layer angepasst werden da sonst Inkompatibel mit EMIB.

Es wird eine EMIB spezifische Schnittstelle benötigt um EMIB anzubinden.

[y33H@]

Es wäre schon, mal zum eigentlichen Thema zurückzukehren. Bald ist CES, da wird's dann wohl neue Infos geben, wie bereits angemerkt.

Und vor allem erste Geräte, sprich vor Ort in Las Vegas ggf auch die Option auf ein Hands-on.

[maguumo]

Das was du "Interface" nennst wird gewöhnlich glaube ich als "Ballout" bezeichnet.. Fiji/Vega bzw. der HBM logic die haben ein HBM Interface, eine Anpassung des Ballouts erfordert kein neues Speicherinterface. AIB/UIB sind Interface IP Blöcke die die komplette Kommunikation zwischen Chip und Chip/Speicher übernehmen und sicherlich auch über einen normalen Interposer funktionieren würden.

[Complicated]

Nun dann nenn das Interface halt Ballout während es bei der Hotchips 2017 ein EMIB Standard Interface für Chiplets genannt wurde. Es bleibt eine Schnittstelle und es bleibt Fakt dass neue GPU Dies benutzt werden müssen um diese umzusetzen.

Niemand bezweifelt dass AIB/UIB auch auf Interposern funktionieren würden. Für EMIB sind sie vorgeschrieben durch Intel in Kombination mit 55um (Ballout) bumps werden sie zum Standard EMIB Interface.

[maguumo]

AIB/UIB sind die Standardinterfaces, nicht weil nichts anderes mit EMIB funktioniert sondern weil man so nicht für jedes 3rd Party Chiplet das Intel in eventuelle SiP Produkte integrieren möchte ein neues Interface entwickeln/integrieren muss. EMIB wird in diesem Produkt nur für die Verbindung zwischen GPU und HBM genutzt. Statt einfach ein paar bumps mit entsprechendem pitch zu verbauen soll AMD jetzt sein komplettes Speicherinterface gegen UIB austauschen? Viel mehr Arbeit und solange UIB nicht besser als die HBM Interfaces ist die AMD schon nutzt komplett sinnfrei.

EDIT: Du versuchst wirklich "standard EMIB Interface" bis auf's Blut zu verteidigen, oder? Gibt es ein standard Interposer Interface? Es ist für EMIB völlig gleich was für Interfaces da an beiden Seiten hängen. Das da in irgendwelchen Artikeln "standard EMIB Interface" steht ist eine Ungenauigkeit die darauf beruht das EMIB momentan Alleinstellungsmerkmal von Intel ist. Richtig wäre irgendwas in Richtung "Standardinterface für Intels SiP Projekte" oder so.

[mboeller]

Nun dann nenn das Interface halt Ballout während es bei der Hotchips 2017 ein EMIB Standard Interface für Chiplets genannt wurde. Es bleibt eine Schnittstelle und es bleibt Fakt dass neue GPU Dies benutzt werden müssen um diese umzusetzen.

Niemand bezweifelt dass AIB/UIB auch auf Interposern funktionieren würden. Für EMIB sind sie vorgeschrieben durch Intel in Kombination mit 55um (Ballout) bumps werden sie zum Standard EMIB Interface.

sehe ich, nachdem ich mir die Präsentation angeschaut habe anders.

AIB+UIB sind die programmierbaren Interfaces des Stratix10 FPGA, mehr nicht. An diesen FPGA können per UIB CPU's und HBM-Speicher angebunden werden. Das UIB-Interface ist aber nur auf der FPGA-Seite vorhanden. Das hat mit EMIB nichts zu tun.

[Complicated]

sehe ich, nachdem ich mir die Präsentation angeschaut habe anders.

AIB+UIB sind die programmierbaren Interfaces des Stratix10 FPGA, mehr nicht. An diesen FPGA können per UIB CPU's und HBM-Speicher angebunden werden. Das UIB-Interface ist aber nur auf der FPGA-Seite vorhanden. Das hat mit EMIB nichts zu tun.
Ohne diese Interfaces kannst du EMIB nicht nutzen.

UIB ist für Speicher vorgesehen und kann auf aktiven Chiplets nicht genutzt werden. Dort muss AIB genutzt werden. Siehe den link zu heise einige Beiträge zuvor.

Ich wiederhole das jetzt wirklich zum letzten mal damit der Kontext erhalten bleibt: AMD hat bisher keine GPUs die man an EMIB anschließen kann. Die GPU-(chiplets) müssen mit 55um bumps und AIB vesehen sein damit EMIB genutzt werden kann. Dies bedeutet nicht dass 55um bumps und AIB nicht auch überall anders benutzt werden können wo auch immer es jemand für sinnvoll erachtet. Auch die HBM stacks müssen 55um bumps und UIB erhalten um mit EMIB angebunden werden zu können.

Das schreibe ich weil die Frage aufkam warum AMD neue Dies benötigen würde. Deshalb weil sie bisher kein EMIB Standard Interface verbaut hatten wie Intel es spezifiziert hatte. Das hat die Semi-Custom Unit nun für Intel erledigt.

[gravitationsfeld]

HBM wird garantiert, mit absoluter Sicherheit nicht mit UIB angesprochen. Das ergibt null Sinn.

[unl34shed]

@Complicated: Nein.

[Complicated]

EDIT: Du versuchst wirklich "standard EMIB Interface" bis auf's Blut zu verteidigen, oder? Gibt es ein standard Interposer Interface? Es ist für EMIB völlig gleich was für Interfaces da an beiden Seiten hängen. Das da in irgendwelchen Artikeln "standard EMIB Interface" steht ist eine Ungenauigkeit die darauf beruht das EMIB momentan Alleinstellungsmerkmal von Intel ist. Richtig wäre irgendwas in Richtung "Standardinterface für Intels SiP Projekte" oder so.
Ich versuche einfach den Begriff zu verwenden den auch die Quellen verwenden: EMIB Standard Interface - was ist dein Problem damit? Soll jetzt jeder sich selber einen Begriff ausdenken? Ich hab mir das doch nicht ausgedacht so wie du "Standardinterface für Intels SiP Projekte". Vor allem wenn alle SiPs von Intel EMIB verwenden macht das ja richtig Sinn was du da vorschlägst.

[Complicated]

HBM wird garantiert, mit absoluter Sicherheit nicht mit UIB angesprochen. Das ergibt null Sinn.
Na dann erkläre das bitte heise. Ich berufe mich auf deren Artikel:
https://www.heise.de/newsticker/meldung/Hot-Chips-EMIB-statt-Interposer-fuer-Multi-Chip-Packages-3810319.html?hg=1&hgi=4&hgf=false
EMIB sieht zwei Arten von Schnittstellen vor. UIB ist für "dumme" Zusatzbausteine wie etwa HBM-Speicherstapel gedacht, die als Slave angesprochen werden. Für komplexere Bausteine mit eigenen Taktdomänen ist die flexiblere und leistungsfähigere AIB gedacht.

Es wäre hilfreich zuerst alle Beiträge im Thread zu lesen, damit man sich nicht dauernd wiederholen muss.
@Complicated: Nein.
Was soll dieses getrolle.

[maguumo]

Ich versuche einfach den Begriff zu verwenden den auch die Quellen verwenden: EMIB Standard Interface - was ist dein Problem damit? Soll jetzt jeder sich selber einen Begriff ausdenken? Ich hab mir das doch nicht ausgedacht so wie du "Standardinterface für Intels SiP Projekte". Vor allem wenn alle SiPs von Intel EMIB verwenden macht das ja richtig Sinn was du da vorschlägst.
Es ist für das Interface irrelevant wie die Signale ans Ziel kommen. Würde Intel seine SiP Projekte über einen Interposer verwirklichen bräuchten sie immer noch standardisierte Interfaces um einfache Kombination von Chiplets zu ermöglichen. EMIB ändert nichts daran, es macht das ganze nur billiger und entfernt das Limit das die maximale Größe eines Interposers setzt.
Mein "Problem" mit der Bezeichnung ist das sie im besten Fall nicht eindeutig ist und so manche Leute falsche Schlüsse daraus ziehen könnten. An einer derart kleinen und unwichtigen Ungenauigkeit müsste man sich nicht so hochziehen wenn wir nicht seit zwei Seiten darüber diskutieren würden.

[unl34shed]

Das UIB ist ein General purpose interface des FPGAs, nur weil es beim FPGA für den HBM genutzt wird, muss AMD nicht die GPU redesignen und den Speichercontroller mit UIB ersetzten. Wieso auch? Sie habe ja schon HBM Support.

[Complicated]

Oh man - hat AMD denn bisher GPUs die mit EMIB verbunden werden können? Es reicht nicht eine GPU mit dem Interposer verbinden zu können um Kaby-Lake G zu bauen. Da gibt es keinen Interposer. Vielleicht schaust du mal in welchem Kontext wir hier sind.

@maguumo
Aber das macht Intel ja nicht sondern sie nutzen EMIB und dafür braucht man das wie es von Intel vorgeschrieben ist. Was willst du mir eigentlich erklären? Dass man es auch hätte anders machen können? Wen interessiert das in diesem Kontext? Und wenn du ein Problem mit der Bezeichnung hast dann sprich doch mit denen die es so genannt haben. Ich würde auch lieber Apfelkuchen zu einem Interposer sagen - doch was nützt mir das?

Das einzige das hier deutlich wird ist dass einige sich mit der Materie nicht genug beschäftigt haben um darüber eine Diskussion zu starten. "Ich will einen anderen Namen dafür haben" ist nun wirklich nicht das Thema des Threads. Entweder ihr habt Quellen wo das anders benannt ist oder wir nenne es wie es die Quellen die schon verlinkt sind nennen: EMIB Standard Interface.
Das UIB ist ein General purpose interface des FPGAs, nur weil es beim FPGA für den HBM genutzt wird, muss AMD nicht die GPU redesignen und den Speichercontroller mit UIB ersetzten. Wieso auch? Sie habe ja schon HBM Support.
Du hast diesen Link nicht gelesen der dir das erklärt:
https://www.heise.de/newsticker/meldung/Hot-Chips-EMIB-statt-Interposer-fuer-Multi-Chip-Packages-3810319.html?hg=1&hgi=4&hgf=false
Es gibt einen Grund warum ich Quellen verlinke.
Edit: Und das was du schreibst solltest du mal aus einer Quelle zitieren. Ich mach hier eine Wette mit dir, dass du keine Textstelle findest wo das was du schreibst mit UIB und FPGA steht. FPGA nutzt AIB, der Speicher nutzt UIB. Und AMDs GPUs müssten AIB nutzen und nicht UIB.

[TGKlaus]

HBM wird garantiert, mit absoluter Sicherheit nicht mit UIB angesprochen. Das ergibt null Sinn.

Lt. INTEL wird das aber genau das gemacht. UIB für Konnections zu "passive" Chips, AIB zu Chips mit eigener Taktdomäne.

Aber was weiß schon INTEL. :freak:


@mods
Wollt ihr diesen Quatsch hier nicht langsam beenden?


EDIT:

HBM 2 wird als Anwendungsfall ausdrücklich in der EMIB / UIB Dokumentation von INTEL genannt.


Warum seid ihr der Meinung das besser zu wissen als INTEL?

[gravitationsfeld]

Lt. INTEL wird das aber genau das gemacht. UIB für Konnections zu "passive" Chips, AIB zu Chips mit eigener Taktdomäne.
Ueberleg doch mal was du da schreibst. Das wuerde bedeuten das Interface auf Speicherchip-Seite komplett umzustellen. Es waere praktisch eine andere Speicher-Technologie als HBM2. Ausser dem Interface ist auf den Speicherchips nichts ausser DRAM.

Das ist garantiert nicht passiert. HBM2 ist im Moment schon niedriges Volumen und teuer, warum sollten sie fuer diesen Kombi-Chip extra anderen DRAM anfertigen? Und niemand bei Micron/Hynix hat davon geredet?

[Complicated]

Nein nur weil der Logic Die ausgetauscht wird und die Anbindung der Stack einen 55um bump Bereich bekommt muss man nicht den ganzen Speicher neu definieren. Der Logic Die von AMD ist auch nicht JEDEC spezifiziert.

https://cdn.wccftech.com/wp-content/uploads/2015/06/AMD-HBM-Memory.jpg

Hier noch besser zu sehen:

http://www.kitguru.net/wp-content/uploads/2014/11/sk_hynix_hbm_dram_2.jpg

Der PHY wird für EMIB ausgetauscht und die Anbindung mit 55um bumps ermöglicht anstatt 100um bumps wie für den Interposer benötigt.

[TGKlaus]

Es waere praktisch eine andere Speicher-Technologie als HBM2.

Hier gehts reinweg um die Konnektivität. Das hat absolut nichts mit der Speichertechnologie an sich zu tun. Also lass den Mist.


Edit:

Hier gehts um klar definierte Technologien.
Ich antworte nur noch auf Posts, woraus klar wird, wo dieses angebliche Wissen herkommt.
Diese Spinnerein oder vorsätzliches Trollen oder was auch immer ist mir zu blöd.

Hier gehts nicht um Meinung oder Glauben, hier gehts um Fakten.

[Complicated]

Noch besseres Bild mit Details:
https://www.top500.org/static/media/uploads/.thumbnails/hbm-graphic.png/hbm-graphic-687x500.png

Hierbei sei angemerkt, dass es auch HBM Stacks gibt die in echtem 3D auf den ASIC drauf verbaut werden, die haben dann gar keinen Logic/Basic Die.

[maguumo]

Oh man - hat AMD denn bisher GPUs die mit EMIB verbunden werden können? Es reicht nicht eine GPU mit dem Interposer verbinden zu können um Kaby-Lake G zu bauen. Da gibt es keinen Interposer. Vielleicht schaust du mal in welchem Kontext wir hier sind.

@maguumo
Aber das macht Intel ja nicht sondern sie nutzen EMIB und dafür braucht man das wie es von Intel vorgeschrieben ist. Was willst du mir eigentlich erklären? Dass man es auch hätte anders machen können? Wen interessiert das in diesem Kontext? Und wenn du ein Problem mit der Bezeichnung hast dann sprich doch mit denen die es so genannt haben. Ich würde auch lieber Apfelkuchen zu einem Interposer sagen - doch was nützt mir das?

Das einzige das hier deutlich wird ist dass einige sich mit der Materie nicht genug beschäftigt haben um darüber eine Diskussion zu starten. "Ich will einen anderen Namen dafür haben" ist nun wirklich nicht das Thema des Threads. Entweder ihr habt Quellen wo das anders benannt ist oder wir nenne es wie es die Quellen die schon verlinkt sind nennen: EMIB Standard Interface.

Nein, bis jetzt haben sie keine GPUs die mit EMIB verbunden werden können, liegt am Ballout, nicht am Interface. Da waren wir doch schon, oder? Was ich dir erklären will? Das habe ich glaube ich schon mehrmals wiederholt. Es ist für das Interface irrelevant wie die Signale ans Ziel kommen. Nur weil hier EMIB statt Interposer verwendet wird muss AMD nicht die bisher verwendeten HBM Interfaces in die Tonne treten und sich die Arbeit machen das durch UIB zu ersetzen. Sie benötigen lediglich ein EMIB kompatibles Ballout für die Verbindung zum HBM. Kein neues Interface.

Richtig, Intel nutzt EMIB statt Interposer. Macht für die Interfaces nur keinen Unterschied.

Der PHY wird für EMIB ausgetauscht und die Anbindung mit 55um bumps ermöglicht anstatt 100um bumps wie für den Interposer benötigt.
Du musst an der Logik nichts ändern, du brauchst lediglich ein anderes Ballout (zumindest falls EMIB da nicht flexibel ist).

[Gipsel]

Auch die HBM stacks müssen 55um bumps und UIB erhalten um mit EMIB angebunden werden zu können.HBM-Stacks haben per JEDEC-Spec ein einheitliches Interface aus staggered bumps mit 55µm Pitch. Das hat Intel für das UIB Ballout offenbar nur kopiert (es sieht auf den ersten Blick identisch aus). :rolleyes:
Lt. INTEL wird das aber genau das gemacht. UIB für Konnections zu "passive" Chips, AIB zu Chips mit eigener Taktdomäne.

Aber was weiß schon INTEL. :freak:Intel gibt der Soße nur kreative Namen. ;)
HBM 2 wird als Anwendungsfall ausdrücklich in der EMIB / UIB Dokumentation von INTEL genannt.Dann schau auch mal in die Präsentationen und Dokumentation zum Stratix 10 rein und Du wirst erkennen, daß UIB im Prinzip nur eine "dumme" Ballout-Area bezeichnet (lediglich mit standardisierter Anordnung der Bumps), woran man hängen kann, was man will (deswegen "universal" ;)). Um die konkrete Kommunikation darüber darf man sich aber selber kümmern (anders als bei AIB). Konkret hat der Stratix 10 hardwired HBM2 Controller verbaut, deren Ausgangssignale schlicht über die dummen EMIB-Brücken zum Standard-HBM2-Chip (mit Standard-Ballout) geroutet werden. Das funktioniert für die Datenleitungen exakt so wie mit einem Interposer (man könnte auch bei Fiji oder Vega den HBM per EMIB anbinden; das braucht nur ein neues Package, keinen neuen Chip). Da gibt es schlicht kein spezielles Protokoll oder sonstwas. Das ist totaler Standard, weswegen es bei der intel-CPU-AMD-GPU-HBM-Kombo von AMD-Seite auch keinen Extraaufwand erfordert, was das angeht. Die können ihren normalen HBM2-Controller da verbauen und gut ist.
Nein nur weil der Logic Die ausgetauscht wird und die Anbindung der Stack einen 55um bump Bereich bekommt muss man nicht den ganzen Speicher neu definieren. Der Logic Die von AMD ist auch nicht JEDEC spezifiziert.Ähm, HBM-Stacks haben ein JEDEC-spezifiziertes Interface mit einem staggered 55µm Pitch Ballout, genau wie von Intel für ihren UIB-Ballout vorgesehen. Vermutlich sieht das (aus naheliegenden Gründen) ziemlich gleich aus. ;)
Der PHY wird für EMIB ausgetauscht und die Anbindung mit 55um bumps ermöglicht anstatt 100um bumps wie für den Interposer benötigt.Schwachsinn. Die Verbindungen zwischen HBM oder Logikchip und Interposer haben nur selten einen 100µm Pitch. Die sind oft enger und bei HBM sogar mit 55µm fest vorgegeben.
Die EMIB-Brücken zum HBM sind einfach kleine dumme (passive) Mini-Interposer, die ins Substrat eingebettet sind. Funktional oder protokolltechnisch ändert sich gar nichts zum Interposer. Und die PHYs im Chip (oder im HBM, gibt ja auf beiden Seiten der Verbindung welche) sind ganz normale HBM2-PHYs.

[maguumo]

Das UIB selbst nicht auch als HBM Controller verwendet werden kann und das Ballout identisch ist wusste ich nicht. Danke für die Info. Waren die Ballout Dimensionen in JESD235 (mit den Maßen) spezifiziert? Kann ich mich gar nicht dran erinnern.

[Complicated]

HBM-Stacks haben per JEDEC-Spec ein einheitliches Interface aus staggered bumps mit 55µm Pitch. Das hat Intel für das UIB Ballout offenbar nur kopiert (es sieht auf den ersten Blick identisch aus). :rolleyes:
Quelle? Dass HBM ebenfalls 100um bumps nutzen habe ich aus der Nutzung der 100 um bumps bei AMDs GPUs für Interposer geschlossen und lasse mich hier gerne mittels einer validen Quelle verbessern. Dass Intel deshalb dann 55um bumps für EMIB nutzt wäre ein cleverer Schachzug und HBM-Stacks müssten hier keine Anpassungen machen.

Es ändert aber nichts daran, dass AMD 100um bumps nutzt bei Interposern und dies für seine GPUs an EMIB anpassen muss - es bleibt bei der ursprünglichen Aussage, dass AMD einen neuen Die benötigt zur Nutzung des von Intel spezifizierten EMIB und Kaby Lake G. Ausser jemand hat eine Quelle die belegt, dass AMD 55um bumps auf den GPUs verbaut hat und mir erklärt warum dann die Semi-Custom Unit die Produktion übernimmt.

[Gipsel]

Das UIB selbst nicht auch als HBM Controller verwendet werden kann und das Ballout identisch ist wusste ich nicht. Danke für die Info.Also wenn ich das richtig sehe, muß man als Integrator die PHYs selbst einbauen. Der UIB (universal interface bus) definiert im Prinzip nur das Ballout (laut Präsentationen und Fotos ein staggered 55µm pitch, also sehr ähnlich wenn nicht identisch zum spezifizierten HBM-Ballout) und maximal die Schnittstelle (AXI4) zu einem ""UIBSS" (UIB sub system) genannten Block. In diesem UIBSS stecken dann die eigentlichen PHYs. Die EMIB-Brücke kümmert ja nur das eigentliche Ballout des UIBSS. Auf einer AMD-GPU mit HBM-Interface könnte man im Prinzip einen HBM(2)-PHY als UIBSS definieren, falls man das unbedingt will (ist aber irgendwie schwachsinnig). Wie der dann chipintern angebunden ist, interessiert den EMIB oder intel nicht die Bohne. Das AXI4-Zeugs ist ja allerhöchstens wichtig, falls man von intel was semi-custom-mäßig mit eigenem Kram zusammengewürfelt haben will. Und beim Stratix10 wird der UIBSS halt im Prinzip vom HBM2-Controller mitsamt den HBM2-PHYs gebildet (die dort per AXI4 angebunden sind).
Intel® Stratix® 10 MX HBM2 IP User Guide (https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/ug/ug-20031.pdf)
Waren die Ballout Dimensionen in JESD235 (mit den Maßen) spezifiziert? Kann ich mich gar nicht dran erinnern.Ja. Findet sich nicht nur in diversen Präsentationen sondern natürlich auch in der JESD235-Spec selbst:

https://abload.de/img/hbm-balloutukph9.png

[Gipsel]

Quelle?JEDEC HBM Spec (https://www.jedec.org/document_search?search_api_views_fulltext=JESD235)
Gibt auch eine xls-Tabelle mit den Koordinaten (in µm) jedes einzelnen Kontaktes (https://www.jedec.org/sites/default/files/files/JESD235A-HBM_Ballout.xlsx) ;)
Dass HBM ebenfalls 100um bumps nutzen habe ich aus der Nutzung der 100 um bumps bei AMDs GPUs für Interposer geschlossen und lasse mich hier gerne mittels einer validen Quelle verbessern.Wo hast Du das denn her? Da mußt Du Dich verlesen haben. Falls Du die eine hier verlinkte Präsentationsfolie meinst, dort steht, daß bei EMIB die über EMIB verlaufenden Verbindungen diesen 55µm Pitch haben, die normalen Flipchip-C4-Bumps aber >100µm Pitch. Da steht nix von einem anderen Pitch als bei Interposern (dort sind 40-50µm reguläres oder eben 55µm staggered Layout übliche Abstände).
Dass Intel deshalb dann 55um bumps für EMIB nutzt wäre ein cleverer Schachzug und HBM-Stacks müssten hier keine Anpassungen machen.Die nehmen einfach das, was mit hohem Yield herstellbar ist. Warum das Rad zweimal erfinden?
Es ändert aber nichts daran, dass AMD 100um bumps nutzt bei InterposernNa die Verbindungen vom Interposer zu HBM müssen ja 55µm Pitch haben (sowohl bei Fiji als auch Vega), sonst funktioniert es ja wohl nicht. Insofern kollabiert Dein Argument schon da.
und dies für seine GPUs an EMIB anpassen muss - es bleibt bei der ursprünglichen Aussage, dass AMD einen neuen Die benötigt zur Nutzung des von Intel spezifizierten EMIB und Kaby Lake G.Der Chip für Kabylake-G ist so oder so neu. Den kann man aber ungeändert auf einen Interposer setzen. Es gibt also keinen Mehraufwand. Selbst wenn das Ballout minimal anders sein sollte, wäre das keine Herausforderung, da man den 55µm Pitch so oder so beherrschen muß.
Ausser jemand hat eine Quelle die belegt, dass AMD 55um bumps auf den GPUs verbaut hat und mir erklärt warum dann die Semi-Custom Unit die Produktion übernimmt.Weil es Auftragsproduktion für Intel ist? Das ist doch eine reine Management-Entscheidung, unter welcher Rubrik das in der Bilanz verbucht wird. Da muß kein technischer Grund vorliegen.

Achja Quelle. Reicht ein Elektronenmikroskop-Bild der Unterseite von Fiji?
https://abload.de/img/amd-furyx-interposer-g4rj3.jpg

Zu sehen sind sowohl Bereiche mit staggered Layout (benachbarte Reihen mit wahrscheinlich 55µm Pitch sind gegeneinander versetzt) als auch Bereiche mit regulärem Layout. Der Minimalabstand der Bumps beträgt ~45µm.

[Complicated]

Der Chip für Kabylake-G ist so oder so neu.Und um nichts anders geht es hier.

[Gipsel]

Und um nichts anders geht es hier.Somit hast Du kein Argument. EMIB sind kleine, passive Brücken. Da muß man sich nur über das Ballout einigen und dann ist die Sache geritzt. Alles Andere interessiert Niemanden. AMD packt seinen normalen HBM-Controller rein und über EMIB werden Standard-HBM-Stacks (mit standardisiertem Ballout) angebunden. Fertig.

[gravitationsfeld]

Danke Gipsel. Ich hatte die Geduld nicht.

[TGKlaus]

EMIB sind kleine, passive Brücken. Da muß man sich nur über das Ballout einigen und dann ist die Sache geritzt. ... Fertig.

AIB vergessen?

https://abload.de/img/ki7kiy.jpg

Kurzform:

NEIN !!!

[Gipsel]

AIB vergessen?

https://abload.de/img/ki7kiy.jpg

Kurzform:

NEIN !!!Hier im Thread vollkommen irrelevant. Denn es geht ja wohl maximal um die Anbindung des HBM-Stacks per EMIB.

[Complicated]

Somit hast Du kein Argument. EMIB sind kleine, passive Brücken. Da muß man sich nur über das Ballout einigen und dann ist die Sache geritzt. Alles Andere interessiert Niemanden. AMD packt seinen normalen HBM-Controller rein und über EMIB werden Standard-HBM-Stacks (mit standardisiertem Ballout) angebunden. Fertig.
Und das Ballout auf der GPU ist nun keine Schnittstelle. Über nichts anderes schreibe ich hier die ganze Zeit. Schau einfach mal einige Beiträge zurück.

Und wieso denkst du dass AIB nicht zum Einsatz kommen muss auf der GPU? Soweit ich das Dokument verstehe kommen auf den ASICs mit aktiver Talktdomäne AIBs zum Einsatz und die UIBs nur auf den HBM Stacks.
Also HBM (UIB)<EMIB>(AIB) GPU

Genau darüber sprechen wir die ganze Zeit. Wieso also irrelevant? Das einzige das du nun aufgeklärt hast und wofür du noch eine Quelle liefern wolltest ist dass bei HBM sowieso schon UIBs zum Einsatz kommen. Die 55um bumps sind bestätigt und sind wie ich schon schrieb ein cleverer Schachzug von Intel. Allerdings hast du dafür auch keine Quelle vorgelegt, die habe ich selber gefunden.

[unl34shed]

Und das Ballout auf der GPU ist nun keine Schnittstelle. Über nichts anderes schreibe ich hier die ganze Zeit. Schau einfach mal einige Beiträge zurück.

Nein, keine Sau bezeichnet so etwas als Schnittstelle!

Und wieso denkst du dass AIB nicht zum Einsatz kommen muss auf der GPU? Soweit ich das Dokument verstehe kommen auf den ASICs mit aktiver Talktdomäne AIBs zum Einsatz und die UIBs nur auf den HBM Stacks.
Also HBM (UIB)<EMIB>(AIB) GPU

Genau darüber sprechen wir die ganze Zeit. Wieso also irrelevant? Das einzige das du nun aufgeklärt hast und wofür du noch eine Quelle liefern wolltest ist dass bei HBM sowieso schon UIBs zum Einsatz kommen. Die 55um bumps sind bestätigt und sind wie ich schon schrieb ein cleverer Schachzug von Intel. Allerdings hast du dafür auch keine Quelle vorgelegt, die habe ich selber gefunden.

Liest du überhaupt, was die letzten Seiten geschrieben wurde?
EMIB ist einfach nur ein Stück Interposer, das in dem Substrat eingebettet ist, da kann jedes noch so erdenkliche Signal drüber geleitet werden. Nur weil Intel für den FPGA UIB und AIB nutzt, muss es AMD nicht auch tun!

Das du versuchst in deiner Beschreibung, AIB und UIB zu vereinen, zeigt nur Unverständnis. Das ist wie eine AGP Graka mittels passiven Adapter in einen PCIe Slot zu setzen und zu denken es funktioniert. Das sind verschiedene Protokolle, Layouts, etc.

[TGKlaus]

Hier im Thread vollkommen irrelevant.

lol?!

Genau, schreibt weiter den falschen Mist, das ENIB ne "1:1 Verdrahtung" ist oder ne einfache passive Brücke.

Stimmt zwar nicht, aber wen interessiert denn in nem Fachforum schon technische Tatsachen.


Macht euren modgestützen Kindergarten weiter und lügt euch mit euren Nichtwissen die Taschen voll.

Ich bin raus, und werd bei Diskussionen von technisch anspruchsvolleren Aspekten nicht mehr teilnehmen. Ist hier im Forum rein verschwendete Zeit.

:down:

[unl34shed]

Liefer doch mal eine Quelle, die sagt, das EMIB ein aktiver Interposer wäre.

[Complicated]

Nur weil Intel für den FPGA UIB und AIB nutzt, muss es AMD nicht auch tun!
Und das vermutest du auf welcher Basis? Weil es bei AMD GPUs keine aktiven Taktdomänen gibt?

Nochmal der heise Link:
https://www.heise.de/newsticker/meldung/Hot-Chips-EMIB-statt-Interposer-fuer-Multi-Chip-Packages-3810319.html?hg=1&hgi=4&hgf=false
EMIB sieht zwei Arten von Schnittstellen vor. UIB ist für "dumme" Zusatzbausteine wie etwa HBM-Speicherstapel gedacht, die als Slave angesprochen werden. Für komplexere Bausteine mit eigenen Taktdomänen ist die flexiblere und leistungsfähigere AIB gedacht.


Und nun unterlasse es ohne Quelle weiter Schwachsinnige Behauptungen aufzustellen. (Übrigens war Gipsel auch der erste der hier im Thread den Ton mit dem Wort "Schwachsinn" auf einen "sachlichen" Level gebracht hat)

Und übrigens ist der Himmel blau, hör auf anderes zu behaupten (Das bezieht sich auf deine erneute Klarstellung was EMIB ist)
AIB und UIB zu vereinenWo liest du so etwas? Kannst du eine einfach Grafik nicht entschlüsseln?
HBM-Stack verwendet UIB. UIB bindet HBM an den EMIB an. GPU verwendet AIB und bindet diese an den EMIB an. Kurz dargestellt: HBM (UIB)<EMIB>(AIB) GPU

Edit:
Liefer doch mal eine Quelle, die sagt, das EMIB ein aktiver Interposer wäre.
Hä? wo wird denn EMIB aktiv wenn UIB und AIB auf den jeweiligen chiplets verbaut werden? Du scheinst die Materie überhaupt nicht zu begreifen.

Noch detaillierter: HBM->UIB->55um bump->EMIB(völlig inaktiv)->55um bump->AIB->GPU

Ich rede hier ausschließlich über den fett markierten Bereich und zwar von Anfang an (ausser meinem Ausflug zu HBM weil ich dachte das lässt sich dadurch besser erklären mit deren Bebilderung). Du redest die ganze Zeit über den blauen Bereich. Könntest du mal damit aufhören dauernd Dinge zu erklären über die keiner irgendetwas gegenteiliges sagt? Liest du irgendetwas die letzten Seiten?

[unl34shed]

HBM (UIB)<EMIB>(AIB) GPU
da EMIB nur eine stupide 1:1 Verbindung[1] ist, ergibt dein Konstrukt
HBM (UIB)<>(AIB) GPU
Da UIB != AIB geht das nicht.


Und Heise und THW sind fundierte Quellen?



[1] Intels Patent zu EMIB: https://www.google.com/patents/US8064224 -> electrically conductive line (150) and (155)

[Complicated]

Wen das (UIB)<>(AIB) nicht gehen würde, würde der Stratix nicht funktionieren, weil der genau so gebaut ist. Lies die Quellen erneut.

Aus der Patentquelle: Ich rede über (131) und über (132)
A microelectronic package comprises a substrate (110), a silicon patch (120) embedded in the substrate, a first interconnect structure (131) at a first location of the silicon patch and a second interconnect structure (132) at a second location of the silicon patch, and an electrically conductive line (150) in the silicon patch connecting the first interconnect structure and the second interconnect structure to each other.
EMIB ist in dem Patent übrigens (120) und nicht (150) und (155). Die sind in den EMIB eingearbeitet 2 Channels sozusagen.

Die "Interconnect structure" habe ich EMIB-Interface gennant hier im Thread weil Toms Hardware auch "Standard EMIB Interface" schrieb. Es gibt zwei verschiedene davon (AIB und UIB) Daraus machst du so einen unqualifizierten Aufriss.

https://patentimages.storage.googleapis.com/US8064224B2/US08064224-20111122-D00001.png

FIG. 1 depicts die 161 and die 162 as if they were transparent (except for their outlines) so that the underlying detail may be seen. In general terms, location 141 is the area of silicon patch 120 that is under die 161 and location 142 is the area of silicon patch 120 that is under die 162.
Die Bereiche 141 und 142 sind die Interfaces für den EMIB auf den Chips. (Ein Interface besteht aus bumps und AIB oder UIB - was sonst als eine Schnittstelle soll das sein)

[TGKlaus]

Wenn AIB, dann auf beiden Seiten, da (siehe #314) ein extra Channel für den "Handshake" benötigt wird.

UND DESHALB KANN ES AUCH KEINE 1:1 VERDRAHTUNG SEIN.

EOD

[unl34shed]

Auch wenn es für AMDs GPU irrelevant ist, da sie schon ein HBM Interface haben...

Du hast entweder UIB<>UIB oder AIB<>AIB das sind zwei unterschiedliche Schnittstellen.


Übrigens war Gipsel auch der erste der hier im Thread den Ton mit dem Wort "Schwachsinn" auf einen "sachlichen" Level gebracht hat

Ich hab absichtlich versucht es auf eine einfache, bildliche Sprache mit Beispielen zu bekommen in der Hoffnung dich damit nicht zu überfordern. Leider wurde doch eine 4 Seiten Diskussion daraus.

Edit:
Wenn AIB, dann auf beiden Seiten, da (siehe #314) ein extra Channel für den "Handshake" benötigt wird.

UND DESHALB KANN ES AUCH KEINE 1:1 VERDRAHTUNG SEIN.

Ist jetzt nicht dein ernst. Das ist wie zu behaupten PCIe ist keine Punkt-zu-Punkt Verbindung weil ja 16 parallel Lanes genutzt werden.

@Complicated: Wo habe ich behauptet, das EMIB 150/155 wären, das war um dir und TGKlaus zu zeigen, dass es nur eine dumme Verbindung zwischen zwei Dies ist. Die weder aktive ist, noch UIB zu AIB umwandeln kann.

[Gipsel]

Und wieso denkst du dass AIB nicht zum Einsatz kommen muss auf der GPU?Weil es keinen Grund dafür gibt. Warum sollte man etwas unnötig verkomplizieren (und größer und ineffezienter machen)?
Soweit ich das Dokument verstehe kommen auf den ASICs mit aktiver Talktdomäne AIBs zum Einsatz und die UIBs nur auf den HBM Stacks.Nein. Das Problem liegt vermutlich am gefetteten Teil.
Also HBM (UIB)<EMIB>(AIB) GPUDas kann gar nicht funktionieren und steht auch nicht auf den hier im Forum verlinkten Folien und Dokumenten. Wie willst Du denn AIB auf der einen Seite und UIB auf der anderen kommunizieren lassen? Die verstehen sich doch gar nicht.
Genau darüber sprechen wir die ganze Zeit. Wieso also irrelevant?Weil bei einer semi-custom GPU von AMD für Intel sich keine Sau um AIB (und auch nicht um UIB) kümmert. Ein bereits genanntes Einsatzszenario wäre, wenn jemand Intel als semi-custom Fertiger beauftragt, intels FPGA-IP mit eigener IP des Auftraggebers in einer (Multi-Die-)Lösung zu vereinigen (die Teile müssen ja irgendwie kommunizieren). Das haben wir hier aber nicht. Hier geht s lediglich darum, den Standard-HBM2-Stack an einen HBM2-Controller/PHYs von AMD anzubinden. Da hat Intel eigentlich gar nichts mit am Hut, wie das intern auf der GPU organisiert ist. Die müssen nur die HBM2-PHYs auf dem GPU-Die an den HBM2-PHYs im Stack per EMIB-Brücke anbinden. Das geht über ein passives Stück Silizium mit ein paar Leitungen drauf, genau wie bei einem Interposer (nur halt kleiner und man spart die TSVs). Das war's.
Das einzige das du nun aufgeklärt hast und wofür du noch eine Quelle liefern wolltest ist dass bei HBM sowieso schon UIBs zum Einsatz kommen.Da liegt offenbar ein Mißverständnis bei Dir vor. Bei HBM kommt natürlich kein UIB zum Einsatz, solange man keinen Stratix-FPGA mit HBM-Interface hat. UIB stellt ein Interface von Intel dar, mit dem man universell z.B. Speichercontroller (aber wohl auch noch andere Sachen) anbinden kann. Die Speichercontroller (mitsamt PHYs für das Treiben der Signale zum Speicher) haben dann bei den Intel FPGAs eine definierte Schnittstelle zum Rest des Chips. Das ist ein Mittel, damit intel die Sachen wie in einem Baukasten zusammensetzen kann (im Prinzip ein ähnliches Ziel wie AMDs infinity fabric). Von außen betrachtet existiert da ein HBM2-Controller mitsamt HBM2-PHYs, deren Kontakte dann irgendwie mit einem HBM2-Stack verbunden werden müssen Dafür ist es völlig unerheblich, wie der Speichercontroller letztendlich mit dem Rest des Chips verbunden ist (also z.B. UIB/AXI4 oder Infinity Fabric). Die Signale, die zwischen den HBM2-PHYs laufen, sind die nach HBM-JEDEC-Spec. Da muß man nicht groß rumwundern.
Die 55um bumps sind bestätigt und sind wie ich schon schrieb ein cleverer Schachzug von Intel. Allerdings hast du dafür auch keine Quelle vorgelegt, die habe ich selber gefunden.Was? Du hast ewig lang über den 55µm Pitch geredet, als wenn das was Besonderes wäre. Das wird weitflächig genutzt und ist wie von mir verlinkt für standardkompatible HBM-Stacks als Ballout sogar vorgeschrieben. Das ist im Übrigen ebenfalls ziemlich irrelevant, da Intel sicher auch ohne wirklichen Mehraufwand EMIBs mit anderer Anordnung der Kontakte produzieren könnte. EMIB-Brücken sind schlicht kleine, dumme Stückchen Silizium mit ein paar Kontakten und Leitungen drauf. Das ist kein Hexenwerk.
lol?!

Genau, schreibt weiter den falschen Mist, das ENIB ne "1:1 Verdrahtung" ist oder ne einfache passive Brücke.Das ist aber schlicht so. Die EMIB-Brücken sind nur passive Verbinder von Kontakten auf verschiedenen Dies. Und Alles was intel je dazu gesagt hat, paßt dazu. Lies doch einfach mal nach!
Zum Rest des Posts sage ich mal lieber nichts.
Und das vermutest du auf welcher Basis? Weil es bei AMD GPUs keine aktiven Taktdomänen gibt?Das ergibt sich schlicht daraus, daß es unnötig und sogar hinderlich und damit völlig unsinnig wäre.
Nochmal der heise Link:
https://www.heise.de/newsticker/meldung/Hot-Chips-EMIB-statt-Interposer-fuer-Multi-Chip-Packages-3810319.html?hg=1&hgi=4&hgf=falseIch vertraue der offiziellen Dokumentation erheblich mehr als irgendeinem heise-Artikel, der nach einer Presse-Präsentation erstellt wurde, bevor besagte Dokumentation öffentlich war. Bei sowas kommt es erfahrungsgemäß häufig zu Mißverständnissen, insbesondere bei Leuten, die nicht das passende Hintergrundwissen besitzen.
Übrigens war Gipsel auch der erste der hier im Thread den Ton mit dem Wort "Schwachsinn" auf einen "sachlichen" Level gebracht hat.Das war eine objektiv und somit sachlich richtige Klassifikation. ;)
Das von Dir und auch TGKlaus Behauptete ist in wesentlichen Teilen schlicht klar falsch.
Wo liest du so etwas? Kannst du eine einfach Grafik nicht entschlüsseln?
HBM-Stack verwendet UIB. UIB bindet HBM an den EMIB an. GPU verwendet AIB und bindet diese an den EMIB an. Kurz dargestellt: HBM (UIB)<EMIB>(AIB) GPUDas kann gar nicht stimmen und ist den hier im Thread verlinkten Sachen auch nicht zu entnehmen.
Noch detaillierter: HBM->UIB->55um bump->EMIB(völlig inaktiv)->55um bump->AIB->GPUNochmal:
AIB und UIB können nicht direkt miteinander kommunizieren. Und die Bumps sind nur dumme Lötkontakte. Das ist für die Funktionalität im Prinzip völlig egal, wie die Kontakte hergestellt werden. Und AIB hat in der Diskussion schon mal gleich gar nichts zu suchen. Das nutzt Intel noch nicht mal selber bei der Anbindung der HBM2-Controller in ihren FPGAs (siehe im Thread verlinkter Doku dazu). AMD wird das sicher nicht tun.

Edit @Complicated: Der Patentkram (bei dem es um die physische Verbindung der Leitungen per EMIB geht) ist wieder ziemlich irrelevant, wenn es Dir um AIB und UIB geht (und AIB und UIB sind selber bereits ziemlich irrelevant). Aber letztendlich ist nur die physische Verbindung der Leitungen per EMIB hier (also für die HBM-GPU-Verbindung) wichtig. Insofern paßt es fast schon wieder, auch wenn das Patent hier kaum weiterhilft. ;)

[Complicated]

Nochmal:
AIB und UIB können nicht direkt miteinander kommunizieren.
Also DAS wird hier zum ersten mal geschrieben im Thread. Quelle dafür?
ich habe bestimmt 10 mal ausgeführt mittlerweile, dass die Nutzung von AIB auf Chiplets und die Nutzung von UIB auf Speicher erfolgt. TGKlaus ebenfalls mehrfach. Das Zitat aus dem Heise Link implizierte das und bei näherer Betrachtung könnte es durchaus auch anders gemeint sein.

Sollte das stimmen, dass AIB nicht mit UIB kommunizieren kann, dann gebe ich meine falsch Interpretation gerne zu. Um nichts anderes geht es hier die ganze Zeit.
Das nutzt Intel noch nicht mal selber bei der Anbindung der HBM2-Controller in ihren FPGAs (siehe im Thread verlinkter Doku dazu).
Wenn du mir die Stelle nennen könntest wäre das Thema dann auch durch. Ich habe den Patentkram nicht aufgebracht und unl34shed war noch nicht mal in der Lage dort den EMIB zu identifizieren.

[Gipsel]

Also DAS wird hier zum ersten mal geschrieben im Thread. Quelle dafür?Das wurde Dir schon mehrfach entgegnet.
Wenn Du HBM an einen GDDR5-Controller hängst (oder eine PCIe-Lane an USB), geht es ja auch nicht (ohne Weiteres). :rolleyes:
Sollte das stimmen, dass AIB nicht mit UIB kommunizieren kann, dann gebe ich meine falsch Interpretation gerne zu.Das ist eigentlich "self-evident". Ansonsten wäre es ja das Gleiche und nichts Unterschiedliches.

Edit:
Wenn du mir die Stelle nennen könntest wäre das Thema dann auch durch.
Blätter da mal durch (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11588234#post11588234) (inklusive der Stratix 10 Doku zu ihrer HBM-IP)!

[Complicated]

Du sagtest es ist in der Doku - bitte zeigen wo. Ich habe es dort nicht gelesen und es ist ganz sicher nicht self-evident.

Ich habe es gefunden unter dem Abschnitt 5 Intel Stratix 10 MX HBM2 IP Interface
Was ja keine Sau so nennt ^^

Danke für die Info.

Um das zusammen zu fassen:
Also müsste bei Verwendung von UIB auch auf dem Chiplet UIB genutzt werden um die EMIB-Verbindung zu etablieren zum HBM.
AIB hingegen müsste zum Einsatz kommen wenn zwei aktive Chiplets miteinander kommunizieren, wie z.B. CPU und GPU. So wie es Intel in den Grafiken bei Verbindung von mehreren FPGAs verwendet. Hier lag auch das entscheidende Detail bei dem Satz von Heise die sagen AIB kommt bei separaten Taktdomänen zum Einsatz. HBM hat keine separate Taktdomäne, daher benötigt auch der GPU Chip keine AIB sondern es sind einfache UIBs möglich.

[unl34shed]

Ich habe es gefunden unter dem Abschnitt 5 Intel Stratix 10 MX HBM2 IP Interface
Was ja keine Sau so nennt ^^

Da wird ja auch nicht das Ballout als Interface bezeichnet :confused:

[Complicated]

Das wurde Dir schon mehrfach entgegnet.
Schwachsinn. Im ganzen Thread hat das noch keiner geschrieben. Zitat bitte.
Die ganze Zeit wurde behauptet es gäbe keine Interfaces weil EMIB eine Verdrahtung sei wie ein Interposer (unabhängig davon, dass GPUs und HBM auch auf Interposern Interfaces nutzen.)

[Complicated]

Da wird ja auch nicht das Ballout als Interface bezeichnet :confused:Das habe ich auch nicht. Es ist dennoch ein Teil der Schnittstelle. Du hast gesagt es gäbe gar kein Interface an der Stelle. Also Ball flach halten. Du hast noch nicht mal verstanden wovon ich schreibe und beharrst darauf dass EMIB gar keine Interfaces kennt weil es das selbe wie ein Interposer ist. Der Himmel ist übrigens blau, lern das mal.

[Windi]

Ich bedanke mich mal bei Gipsel, der hat hier wohl am meisten Ahnung.
Und auch dafür, das er sich so viel Zeit genommen hat.

AMD kann also einen Grafikchip bauen, der sowohl mit EMIB als auch mit Interposer funktioniert. Darum ging es hier ja.

Weitere Informationen gibt es wohl erst zur CES, dann bin ich hier raus.

[unl34shed]

a) Was ist EMIB anderes als ein Interposer? (In klein, eingebettet im Substrat)

b) Ich hab nur gesagt, es gibt kein ein EMIB-Interface, weil das aus technischer Sicht schwachsinnig ist. Für ein Medium braucht es keine Schnittstelle und genauso ist es Schwachsinn das ballout/pinout/package so zu nennen:

Ausgangpunkt war das:
Das EMIB Interface ....

EMIB ohne eine entsprechendes Interface auf dem Chip bringt nichts. ...

Die Interfaces für GDDR5, HBM und EMIB sind jeweils spezifisch, ...

Lichtblick war 250:
Du brauchst trotzdem auf dem Chip ein Interface das den EMIB anbindet. Wie du meinen Grafiken entnehmen kannst (und auch den verlinkten noch umfangreicheren Quellen). Niemand sagt EMIB wäre ein Interface - der Chip braucht dennoch ein Interface um EMIB anzubinden.

Aber Mein Vorschlag es richtigerweise Pinout oder Package zu nennen war dir aber zu blöd:
Also wenn du GDDR5, HBM und EMIB Anbindungen generell bezeichnen willst ist das "Interface auf dem Chip" nach wie vor das richtige. Und wenn ich EMIB-Interface schreibe kannst du es dir ja zu "Pinout" übersetzen - es bleibt das selbe.

...

Du redest vom Package und ich rede ausschließlich vom ASIC. Und da sage ich, dass ein Chip der für Interposer vorgesehen ist nicht über EMIB angebunden werden kann mit HBM.

...
Du schriebst so etwas wie ein EMIB-Interface existiere nicht.
Du beharrst darauf was EMIB ist und ich sage, das dies keine Rolle spielt, dass der Chip ein Interface benötigt dafür. ...

...
Zitiere bitte mal wo ich das geschrieben haben soll - hier ist wohl eher dein Textverständnis das Problem. Und wenn du nun 100 mal wiederholst EMIB sei eine Leiterbahn, so ändert das nichts daran, dass diese Leiterbahn die Daten von einem Chip bekommt der mittels spezifischem Interface an der EMIB Leiterbahn angeschlossen ist. Das nennt man dann EMIB-Interface wie dir nun auch die Quellen belegt haben. ...

Und inwiefern benötigt jetzt deswegen EMIB kein Interface auf dem angebundenen Chip?...

Ach und ich habe dir gezeigt, dass es ebenso gültig ist EMIB-Interface zu schreiben (wie es ja auch in dem Bericht passiert) ...

Ich schrieb AMD habe derzeit keine GPUs mit einem solchen EMIB-Interface (55 um bumps, AIB PHY, UIB PHY mit entsprechenden Spezifikationen).

usw.

[Gipsel]

Du sagtest es ist in der Doku - bitte zeigen wo. Ich habe es dort nicht gelesen und es ist ganz sicher nicht self-evident.Na ja, es gab hier Folien zum AIB-Interface. Und das sah mir ganz stark danach aus, als wenn das kein HBM-Interface wäre. Insofern schon.
Ich habe es gefunden unter dem Abschnitt 5 Intel Stratix 10 MX HBM2 IP InterfaceBlick in den ersten Abschnitt der Einleitung hätte vielleicht schon gereicht:
https://abload.de/img/hbm_stratix1044rn2.png
Also müsste bei Verwendung von UIB auch auf dem Chiplet UIB genutzt werden um die EMIB-Verbindung zu etablieren zum HBM.Nein.
Bei UIB wird ein Controller und passende PHYs in das UIBSS gepackt. Bisher gibt es dafür von intel offenbar nur die für HBM2 (falls die Signallevel kompatibel sind, gehen ja auch so Multi-Protokoll-Geschichten, man kann das also flexibel gestalten). Aber im Prinzip könnte man da auch was Anderes reinpacken (deswegen wohl das "universal" in UIB). Im Stratix FPGA hat man also AXI4-Ports zum HBM2-Speichercontroller samt PHYs im UIBSS. Alles ab da ist dann der Standard, den man will (bei HBM2 also JEDEC-konformes HBM2). DIE PHYs im UIBSS treiben also HBM2-kompatible Signale über eine EMIB-Brücke, genau wie jeder andere HBM2-PHY das könnte. Der muß dafür nicht von Intel selber sein.
AIB hingegen müsste zum Einsatz kommen wenn zwei aktive Chiplets miteinander kommunizieren, wie z.B. CPU und GPU.Es ist völlig egal, was das ist. Sobald Du zwei Dies hast, die AIB können (also z.B. die Chiplets von intel), kann man die so verbinden. Das ist wie ein Baukastensystem. Hättest Du was Eigenes, was kein AIB kann (und willst auch kein AIB einbauen), dann könntest Du Dir im Prinzip ein UIBSS designen (lassen), der die Umsetzung auf die für Deinen Chip passende Kommunikation erledigt.
Wie gesagt ist das ganze Geraffel mit AIB und UIB nur wichtig, wenn Du semi-custom-Kunde bei Intel bist, die also eine Lösung für Dich basteln und dabei Bausteine von Intel-IP und Deiner IP zusammenbasteln sollen. Und Intel nutzt es eben auch intern, um z.B. die HBM2-Controller mitsamt PHYs an den Chip anzubinden.

[TGKlaus]

Sobald Du zwei Dies hast, die AIB können (also z.B. die Chiplets von intel), kann man die so verbinden.

Ach, jetzt auf einmal?

Erst erklären ich sein dumm.


Dann zu meinen Erkläungen inkl. idiotensicherem Schaubild von INTEL erklären:

Hier im Thread vollkommen irrelevant. Denn es geht ja wohl maximal um die Anbindung des HBM-Stacks per EMIB.

Und dann am ende doch kapieren, das eben für AIB auf beiden Dies ein entsprechender Controllerpart benötigt wird, der speziell mit AIB umgehen kann.

NICHTS EINFACHE BRÜCKE! NICHTS 1:1 VERDRAHTUNG!

[Complicated]

a) Was ist EMIB anderes als ein Interposer? (In klein, eingebettet im Substrat)

b) Ich hab nur gesagt, es gibt kein ein EMIB-Interface, weil das aus technischer Sicht schwachsinnig ist.
a) stand nie zur Debatte. Denk daran der Himmel ist blau auch wenn du etwas anderes sagst. ;D

Da du mit b) falsch liegst ist doch alles geklärt.

Du meinst mir erklären zu müssen, dass es keiner Interface nennt, während sich nun herausgestellt hat, dass UIB genau das ist: Universal Interface Block
Ich schrieb nie, dass EMIB ein eigenes ausschließlich für EMIB verwendetes Interface benötigt. Ich schrieb, dass AMD noch kein Interface verbaut hat auf seinen GPUs, welches EMIB nutzen kann. Ich war der Meinung, dass das HBM-Interface auf Vega nicht EMIB-fähig ist. Das schrieb ich mehrmals. So richtig klar ist das auch nach wie vor nicht.

Allerdings hat Gipsel nun geklärt, dass nicht AIB für die Anbindung auf der GPU zuständig ist. Das ändert nichts daran, dass du die ganze Zeit am Thema vorbei redest.

Wie gesagt ist das ganze Geraffel mit AIB und UIB nur wichtig, wenn Du semi-custom-Kunde bei Intel bist, die also eine Lösung für Dich basteln und dabei Bausteine von Intel-IP und Deiner IP zusammenbasteln sollen. Und Intel nutzt es eben auch intern, um z.B. die HBM2-Controller mitsamt PHYs an den Chip anzubinden.Nun ich würde doch mal behaupten, dass genau das hier der Fall ist mit der AMD GPU die auf den Interposer verzichten soll für die Anbindung an HBM. Nur dass AMD die Semi-Custom Produktion ausführt und Intel das mit der CPU dann auf das Package bringt. Wobei noch gar nicht verlautet wurde ob sogar die CPU von AMD angebunden und mit auf das Package gebracht wird und der gesamte SiP an Intel ausgeliefert wird.

[Complicated]

AMD kann also einen Grafikchip bauen, der sowohl mit EMIB als auch mit Interposer funktioniert. Darum ging es hier ja.
Ich würde sagen erstmal Nein - siehe Intel Patent über die Anbindung von EMIB. Das ist wohl auch die Absicht von Intel, einen proprietären Interconnect mit samt den Interfaces und bumps Exklusiv zu behalten. Damit sollen mehr Kunden in die Foundry gelockt werden. Daher müsste wohl Intel dem zustimmen wenn AMD dies auf seinen Interposern nutzen wollte. Ich glaube EMIB ist vom Patentlizenzabkommen ausgeschlossen, wäre aber wohl für AMD eine große Bereicherung. Vielleicht stimmt Intel dem ja auch zu im Gegenzug für die Kaby-Lake G GPU.

[unl34shed]

Da du mit b) falsch liegst ist doch alles geklärt.


Fällt dir eigentlich nicht auf, dass nur DU und TGKlaus von Gipsel gequoted werden und alles als Falsch/Schwachsinn bezeichnet was ihr beiden da schreib und nicht ich? Muss ich da noch mehr sagen? Fass dich mal an die eigene Nase.

[Complicated]

Deine Leseschwäche ist kaum noch zu übersehen. Du hast absolut nichts relevantes Zum eigentlichen Thema beigetragen. Was hätte er denn da von dir quoten sollen? Und zu behaupten Gipsel hätte ALLES als Schwachsinn oder falsch bezeichnet ist genau die Art wie du hier Blödsinn verbreitest.

[mboeller]

AIB vergessen?

https://abload.de/img/ki7kiy.jpg

Kurzform:

NEIN !!!

doch.
AIB ist laut Intel teil vom neuen Stratix10 FPGA, nur "Tiles" für diesen FPGA müssen AIB benutzen.

UIB ist auch nur Teil vom FPGA, HMB2 benötigt keine Anpassungen. Auch CPUs und GPUs (steht aber in der Hotchips-Präsentation nicht drin) werden mit UIB an den FPGA angebunden. Und... nur der FPGA hat bei CPUs (und damit GPUs) UIB an Board. CPU und GPU benötigen keine Anpassungen.

Die Hotchips-Präsentation findest du sicher selbst und die andere Präsentation bzgl. HMB2 hat Gipsel ja bereits verlinkt.

hotchips-Präsentation: HC29.22.523-Hetro-Mod-Platform-Shumanrayev-Intel-Final.pdf (kein direkter Link, weil das ein 135MB zip-file ist) Seite 19 zeigt die Anbindung einer CPU per UIB, wie bei HMB2

[Gipsel]

Ach, jetzt auf einmal?

Erst erklären ich sein dumm.Context is for Kings, um mal den Titel einer aktuellen StarTrek-Folge zu erwähnen.
Hier im Thread geht es um die AMD-GPU-Intel-CPU-Kombo bzw. der Anbindung des HBM-Stacks an die GPU per EMIB. Und dort ist das Baukastensystem für Intels IP mitsamt AIB und UIB irrelevant. Den Bereich, in dem es relevant ist, habe ich genannt.
Dann zu meinen Erkläungen inkl. idiotensicherem Schaubild von INTEL erklären:Ob das Schaubild von Intel so idiotensicher ist, wage ich noch zu bezweifeln. Denn das:
Und dann am ende doch kapieren, das eben für AIB auf beiden Dies ein entsprechender Controllerpart benötigt wird, der speziell mit AIB umgehen kann.ist für die HBM-Anbindung immer noch klar falsch. Irgendein standardkonformer HBM2-PHY auf einer Seite, standardkonforme HBM2-Stacks (mit ihren PHYs) auf der anderen Seite, dazwischen die passiven EMIB-Brücken für die Herstellung der nötigen elektrischen Kontakte und das muß gehen. Elektrisch gesehen besteht ja kein Unterschied zu einem normalen (ebenfalls passivem) Interposer.
NICHTS EINFACHE BRÜCKE! NICHTS 1:1 VERDRAHTUNG!Doch, EMIB bezeichnet genau das, egal wie viel Du hier in All-Caps rumwütest.

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

Ich schrieb, dass AMD noch kein Interface verbaut hat auf seinen GPUs, welches EMIB nutzen kann. Ich war der Meinung, dass das HBM-Interface auf Vega nicht EMIB-fähig ist. Das schrieb ich mehrmals. So richtig klar ist das auch nach wie vor nicht.Da EMIB lediglich elektrische Verbindungen in fast identischer Weise und in identischer Güte wie ein Interposer zur Verfügung stellt (es ist lediglich eine Kostenoptimierung), kann man die Leitungen praktisch jedes HBM2-PHYs über EMIB-Brücken an HBM2-Stacks verbinden, solange man sich über das Ballout geeinigt hat (das muß man für eine Interposer-Verbindung ja auch tun).
Nun ich würde doch mal behaupten, dass genau das hier der Fall ist mit der AMD GPU die auf den Interposer verzichten soll für die Anbindung an HBM. Nur dass AMD die Semi-Custom Produktion ausführt und Intel das mit der CPU dann auf das Package bringt. Ich würde sagen erstmal Nein - siehe Intel Patent über die Anbindung von EMIB.Damit das per EMIB funktioniert, müssen sich AMD und Intel lediglich über die Anordnung der µBumps des HBM2-PHYs auf dem GPU-Teil austauschen, was ja wohl trivial ist.

[mboeller]

hat Gipsel schon beantwortet

[unl34shed]

Deine Leseschwäche ist kaum noch zu übersehen. Du hast absolut nichts relevantes Zum eigentlichen Thema beigetragen. Was hätte er denn da von dir quoten sollen? Und zu behaupten Gipsel hätte ALLES als Schwachsinn oder falsch bezeichnet ist genau die Art wie du hier Blödsinn verbreitest.

Ball flach halten, Gipsel sagt auch nur das, was ich dir schon vor 4 Seiten geschrieben habe:
Nein. AIB und UIB sind von Intel standardtisierte Schnittstellen für die Chip zu Chip Kommunikation. Ähnlich wie PCIe oder Infinite Fabric.
Und die Chips sprechen das AIB bzw. UIB Protokoll und sind mittels EMIB verbunden (EMIB ist hier nur die Leiterbahn zwischen den Chips).

Wenn dritte einen Chip an Intels FPGAs anschließen wollen, dann müssen diese ein bestimmtes Package haben um aufgelötet werden zu können und entweder ein AIB oder UIB Interface haben. EMIB ist aber nicht nur auf diese beiden Schnittstellen limitiert, HBM geht da z.B. auch. Auch die 55µm sind sehr sicher nicht fixe werte. Das ist Marketing blabla um zu sagen, "wir sind halb so groß wie Interposer" (oder viertel, mir egal). Wenn man nicht so kleine Strukturen benötigt, wird man diese auch vermeiden wollen.

Und nein, der Datenbus ist nicht der Interposer. Der Interposer ist passiv und nur die Leiterbahn zwischen den Chips.


Und jetzt noch einmal, AMD hat eventuell nicht das richtige Package/Pinout unterm Chip und müsste da eventuell anpassungen am Metal layer vornehmen. Aber das ist wie schon mehrfach gesagt, kein Interface.

Ich muss Gipsel zu gute halten, er hat mehr Slides/Infos zur Verfügung (Fiji Ballout zB.). Hier noch mal danke dafür.

[mboeller]

noch was. Hotchips-Präsentation Seite 15:

bzgl. des FPGA:

UIB general purpose SiP interface for HBM and ASIC

AIB was created for TRCVer and generalized to other use cases, e.g. analog, RF

eine GPU per AIB anzubinden wäre also ziemlich "seltsam"

[Gipsel]

Wir könnten auch mal aufhören, Intels IP zum Bau von "semi-custom" FPGA-SIPs mittels eines Baukastensystems hier zu diskutieren. Ist hier ja nicht das Thema.

Wirklich spannend wäre übrigens gewesen, falls die GPU und CPU nicht nur über PCIe angebunden wären sondern wenn man da was eigenes (egal ob von Intel oder AMD) integriert hätte. Immerhin könnte man so noch ein wenig Energie sparen. Lohnt aber vermutlich nicht wirklich den Aufwand oder die projektierten Absatzzahlen wären zu niedrig.

[gravitationsfeld]

Vielleicht einfach nur weniger Spannung auf den PHYs?

[Gipsel]

Vielleicht einfach nur weniger Spannung auf den PHYs?Weiß nicht, ob das so optimal wäre und wie viel man da mit der Spannung runtergehen kann.
Die PCIe-PHYs sind ja auch relativ groß und stromfressend, weil sie die Signale mit hohem Takt über merkliche Entfernungen und die Steckverbinder unterstützen müssen (Kapazitäten, Dämpfung und alles was da so mit dranhängt). AMD hat ja nicht umsonst für die Verbindung der Dies in Threadripper und Epyc ein eigenes Interface (GMI, single ended nicht differentiell, breiter und niedriger getaktet) für on-package-Verbindungen zwischen den Dies eingebaut (die PHYs sind im Verhältnis zu den PCIe-PHYs recht klein) und haben in einer Präsentation mal gesagt, wie viel Watt das unter Volllast spart im Vergleich zu den PCIe-PHYs für die xGMI-Verbindungen zwischen den Sockeln von zwei Epyc-CPUs.
Aber wenn man PCIe komplett spart, dann kann man das Die nicht mehr als diskrete Grafikkarte separat verkaufen (falls Intel das nicht sowieso durch die Vertragsgestaltung unterbindet). Ich kann das nicht seriös abwägen, was da wirtschaftlich günstiger wäre. Und falls man die PCIe-Interface auch irgendwie nicht ganz standardmäßig mit verringerten Spannungen treiben könnte (das muß dann aber auch Alles dafür validiert werden, kostet auch), lohnt sich das aus Kosten-Nutzen-Sicht eventuell nicht.

[gravitationsfeld]

Theoretisch koennte man ja auch andere PHYs einbauen und dahinter trotzdem noch PCIe sprechen.

Aber solange nichts offiziell gesagt wird, weiss man nichts.

[Gipsel]

Theoretisch koennte man ja auch andere PHYs einbauen und dahinter trotzdem noch PCIe sprechen.Also das Protokoll beibehalten und nur den physischen Layer tauschen? Wäre vielleicht die beste Variante (sollte ziemlich transparent sein). Aber wie Du sagst, müssen wir wohl mal sehen, ob sowas dann irgendwann kommt (eventuell in zukünftigen Versionen). Falls sich damit tatsächlich ein paar Watt sparen lassen, dürfte aber zumindest ein gewisser Anreiz da sein.

[Complicated]

AIB und UIB sind EMIB-Interfaces (Schnittstellen)
Nein. AIB und UIB sind von Intel standardtisierte Schnittstellen für die Chip zu Chip Kommunikation.
Und in ein und dem selben Beitrag
Nur braucht AMD keinen AIB oder UIB um den HBM via EMIB mit der GPU zu verbinden. Das nutzt immer noch den selben 1024bit Bus (HBM-Interface) wie mit einem Interposer.

Nein, es ist einfach falsch, das Interface zu nennen.
Bzgl. Informationsstand: Ich komme aus der Halbleiter Branche.

Ja, die Interfaces sind AIB und UIB nicht EMIB.
Wenn ich Interface schreibe und du dann im nächsten Beitrag "Nein es sind Schnittstellen" dann hast du mir genau was erklärt? Denk dran der Himmel ist blau, und hör auf das Gegenteil zu behaupten. ^^
Lassen wir das mal sein bitte - es hat zu nichts geführt und wird es auch nicht.

Wirklich spannend wäre übrigens gewesen, falls die GPU und CPU nicht nur über PCIe angebunden wären sondern wenn man da was eigenes (egal ob von Intel oder AMD) integriert hätte.
Es ist ja durchaus noch nicht vom Tisch, dass hier AMDs HBCC auf der GPU sitzt und die CPU mittels Infinity Fabric über PCIe angebunden ist. Wäre ein interessantes Testvehikel für den Serverbereich.

[maguumo]

Der Punkt war das es keine EMIB Interfaces sind sondern Interfaces für Chip zu Chip Kommunikation.

[Complicated]

Das meinst du jetzt aber nicht ernst? Oder? Womit sind denn in diesem Fall die Chips verbunden? Funktioniert denn EMIB ohne Interfaces? Du hast jetzt aber schon die Quellen gelesen die das genau so nennen? Können wir das nun endlich beenden? Ein UIB wird für EMIB benutzt. Damit ist es auch (bitte beachten ich schrieb schön öfter - deswegen aber kein exklusives) ein EMIB Interface. Nein Intel nennt es sogar "Standard EMIB Interface".

[maguumo]

Chip zu Chip Kommunikation funktioniert nicht ohne Interface. Worüber das läuft ist für das Interface irrelevant. Eine spezifizierte Ballout Area ist kein Interface. Das Interface bezeichnet die Logik die Signale verwaltet. Kein Stück Draht oder einen Lotball.

[ndrs]

Wenn ich eine (beliebiges Beispiel) USB-Verbindung herstelle, ist es egal, ob das Kabel grün (Interposer) oder rosa (EMIB) ist. Die Stecker (AIB, UIB, HBM-Interface) legen fest was kompatibel ist. Dazwischen ist nur dummes Kupfer, egal in welcher Form und Farbe.

[unl34shed]

. Nein Intel nennt es sogar "Standard EMIB Interface".

Das war doch Heise :confused:


@ndrs: Wenn man Signale mit Licht durch Vakuum überträgt, gibt es sogar gar kein Medium mehr.

[Complicated]

Eine spezifizierte Ballout Area ist kein Interface. Das Interface bezeichnet die Logik die Signale verwaltet. Kein Stück Draht oder einen Lotball.
Na auf den Unfug habe ich noch gewartet.

Chip<->Interface<->Interconnect<->Interface<->Chip

Wenn du nun die bumps einer der drei beteiligten Komponenten zuordnen müsstest, welche würdest du nehmen? Rot grün oder blau? Es hängt vom Detaillevel ab ob etwas zugeordnet wird oder nicht.
Das war doch Heise Nein das war in dem Dokument zum Stratix das du nicht lesen wolltest. Ich habe es nur 3 mal zitiert.

[Screemer]

Emib ist auch kein Interconnect, denn das ist die Gesamtheit aus z.b. Phys, Protokoll und „Verdrahtung“. Ccix oder infinityfabric wären da ein Beispiel. Emib ist und bleibt ein dummer Leiter der statt Metall eben Halbleiter in organischen Substrat nutzt. Nenn es von mir aus miniinterposer. Mehr ist da nicht dran. Nur weil Intel es für die eigene semicustomsparte mit anderen Phys und Protokollen nutzt ändert das nichts an der Kommunikation für amd mit seinen hbm-Phys und Standard hbm(2). Das ist nur für Intelkunden von Bedeutung, die ihre eigenen Schaltungen mit Intel-ip auf einem Package kombinieren wollen, denn für die Kombination mit diesen hat Intel für unterschiedlich gelagerte Schaltungen eben zwei unterschiedliche Interfaces definiert. Uib oder aib ist dann sowohl im Intel als auch in der vom Kunden gelieferten Schaltung von Nöten. Amd tangiert das für die Kommunikation zwischen gpu und hbm nicht die Bohne.

[Complicated]

Auch hier hängt es vom Detaillevel ab. Aus Sicht eines SiP sind Interconnects:
Interconnect technologies for system-in-package integration (http://ieeexplore.ieee.org/document/6745798/)
Today, typical interconnects in a SiP toolbox are new technologies like redistribution layers (RDLs), 3D thru-silicon vias (TSVs) and 3D thru-encapsulant vias (TEVs) in addition to innovative variations of flip-chip bonding, wire bonding, and several options for die attach. Such interconnects enable the 3D integration of stacked or embedded chips and other components like passives, shielding or antennas. Scaling trends in component density (Moore's law) and computing efficiency (Koomey's law) allow circuit miniaturization and increased functionality of logic ICs, but also drive the necessary number of external input/output pins of the packaged system (Rent's rule). Often, this results in small ball pitch dimensions enabled by usage of high-density BGA substrates or fan-out packages with adequate redistribution layers.
Es ist immer der Kontext entscheidend. Und hier sprechen wir von einem SiP.

[maguumo]

Emib ist auch kein Interconnect, denn das ist die Gesamtheit aus z.b. Phys, Protokoll und „Verdrahtung“. Ccix oder infinityfabric wären da ein Beispiel. Emib ist und bleibt ein dummer Leiter der statt Metall eben Halbleiter in organischen Substrat nutzt. Nenn es von mir aus miniinterposer. Mehr ist da nicht dran. Nur weil Intel es für die eigene semicustomsparte mit anderen Phys und Protokollen nutzt ändert das nichts an der Kommunikation für amd mit seinen hbm-Phys und Standard hbm(2). Das ist nur für Intelkunden von Bedeutung, die ihre eigenen Schaltungen mit Intel-ip auf einem Package kombinieren wollen, denn für die Kombination mit diesen hat Intel für unterschiedlich gelagerte Schaltungen eben zwei unterschiedliche Interfaces definiert. Uib oder aib ist dann sowohl im Intel als auch in der vom Kunden gelieferten Schaltung von Nöten. Amd tangiert das für die Kommunikation zwischen gpu und hbm nicht die Bohne.
Genau. Abgesehen davon ist das Interface Teil des Chips. Die Bumps sind die physikalische Verbindung zwischen deinem Chip und dem Material durch das du das Signal routest. Die Anordnung dieser (->Ballout) hat keinen Einfluss auf die Logik des Interface.

[Complicated]

Genau. Nö. Siehe Beitrag vor deinem. Die bumps als alleinstehend zu bezeichnen und keiner der drei Komponenten zuzuordnen ist genau das was dich daran hindert das zu verstehen und zu akzeptieren. Auch die bumps sind Teil des Chips und auch dessen Anbindung, denn dort werden sie bei der Fertigung angebracht.

[Screemer]

Nach dieser Definition kann man jede dumme Verdrahtung als interconnect bezeichnen. Die amis nennen auch Verbindungsstraßen als interconnect.

Wegen mir nen emib nen interconnect, wenn’s dir so passt. Das liegt wenigstens je nach Auslegung deutlich näher an der Realität als deine Definition von Interface. Ein solches ist emib deswegen trotzdem nicht.

[Complicated]

Ja denn Interconnect ist ein häufig gebrauchter Begriff den man im Kontext verwendet. Er hat nicht nur eine Definition. Es heisst ja auch lediglich "Verbindung".
Im Prinzip heisst es Leiterbahn: https://books.google.de/books?id=bJaBBwAAQBAJ&pg=PA290&lpg=PA290&dq=Interconnect+Halbleiter&source=bl&ots=Nh2ytAVOWC&sig=W6hyNWRTQdSV4U2Fm7mk9hvi3uM&hl=de&sa=X&ved=0ahUKEwjclZ2nhLDYAhUO6aQKHSdcAxUQ6AEIODAD#v=onepage&q=Interconnect%20Halbleiter&f=false

Das liegt wenigstens je nach Auslegung deutlich näher an der Realität als deine Definition von Interface. Ein solches ist emib deswegen trotzdem nicht.Jetzt fängst du auch noch an - ich habe das nirgends behauptet. Zitier mal bitte die Stelle wo ich sage EMIB sei ein Interface. Nur weil unl34shed das dauernd schreibt habe ich das nicht geschrieben.

[maguumo]

Auch die bumps sind Teil des Chips und auch dessen Anbindung, denn dort werden sie bei der Fertigung angebracht.
Und was ändert deren Anordnung jetzt an der Logik des Chips?

[unl34shed]

Nein das war in dem Dokument zum Stratix das du nicht lesen wolltest. Ich habe es nur 3 mal zitiert.

Sorry waren die Schreiberlinge von Toms Hardware (Hier (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11586900#post11586900)oder Hier (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11587364#post11587364)). Mein Fehler.
Im Stratix Dokument (Wohl dieses, da kein anderes verlinkt wurde (https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/ug/ug-20031.pdf)) steht nichts von standard interface.


Dir fehlt es eindeutig an Grundlagenwissen. Dir würde wohl niemand böse sein, wenn du nachfragen würdest um deine Lücken aufzubessern. Aber es bis aufs Blut zu verteidigen? Und den anderen Unwissenheit zu unterstellen, obwohl alle etwas anderes behaupten und auch belegen! Denen soll es dann auch noch an Textverständnis mangeln, wirklich?

[Complicated]

Ja, sorry war Toms Hardware.

Ich bewege mich in Foren um mein Wissen zu verbessern und aufzufüllen. Doch wenn jemand nicht einmal nach mehrfachem klaren definieren nicht in der Lage ist etwas zusammenhängendes zum Thema beizutragen dann ist das kaum Kompetenter. Noch nicht einmal das Patent hast du richtig gedeutet welches du selber eingebracht hast. Du unterstellst mir Unwissenheit an einem Punkt wo du nicht einmal die Begrifflichkeiten die verwendet wurden nach 10 mal Wiederholung verknüpfen konntest. Dass mir Wissen in manchen Bereichen fehlt ist Tatsache, doch du bist kaum derjenige der hier für Aufklärung gesorgt hat.

[Screemer]

@complicated: du und tgklaus waren also auch nicht die beiden, die aufs Blut verteidigt habe emib halbe es ohne aib oder uib nicht nutzbar oder gar ohne neues Interface nicht nutzbar? :up:

[Complicated]

@Screemer
Ich war der Meinung dass AMD!! ohne Anpassungen an ihrem Interface der GPUs!! nicht mit EMIB verbinden können. Der heise Artikel den ich verlinkt hatte, hat mich dazu verleitet zu denken AMD müsse AIBs verbauen um EMIB zu nutzen. Das habe ich dank Gipsel dann ja zurück genommen.

Es ist auch immer noch nicht geklärt ob AMD nun Anpassungen vornehmen muss oder nicht an ihren GPU Dies (das war die Grundfrage!). Dass der HBM-Stack schon 55um bumps nutzt hat Gipsel ja ausgeführt, doch die GPUs, welche auf Interposern verwendet werden nutzen andere bump-Größen. Fiji waren z.B. 30um (Wie Gipsel ja mit Foto nachgewiesen hat), womit sich auch das EMIB nicht anbinden lässt und dort Anpassungen statt finden müssen auf AMD Seite.

Ich habe das ganze in einem Satz als Interface zusammengefasst (AIB/UIB+55um bumps), woraufhin hier einige meinten mir erzählen zu müssen EMIB sei kein Interface, was ich auch nicht behauptet hatte.

[maguumo]

Einige hier meinten dir erzählen zu müssen das es kein "EMIB Interface" gibt da das Interface lediglich die für die inter Chip Kommunikation benötigte Logik, nicht die physikalische Verbindung oder Komponenten dieser (untere Metal Layer, Bumps, EMIB), bezeichnet. Auf der semantischen Trennung hätte niemand so lange rumgeritten wenn nicht offensichtlich wäre das dein Missverständnis darauf beruht das du annimmst das eine Änderung des Ballouts ein neues Interface erfordern würde bzw. das dies mit bereits vorhandenen Interfaces nicht möglich wäre.

[unl34shed]

Doch wenn jemand nicht einmal nach mehrfachem klaren definieren nicht in der Lage ist etwas zusammenhängendes zum Thema beizutragen dann ist das kaum Kompetenter.

Nur weil deine "klaren Definitionen" einfach komplett falsch sind?!
Das der kleine Hinweis, dass es so etwas wie ein EMIB-Interface nicht gibt etwas ins Off-Topic ausgeartet ist, sehe ich ja ein. Lag aber nicht an mir ;)

Ich hab dir sogar recht früh vorgeschlagen, es Pinout zu nennen. (Ob man es am Ende Pinout, Ballout oder Package nennt, egal). Aber nein, du wolltest es weiter falsch Interface nennen.

Noch nicht einmal das Patent hast du richtig gedeutet welches du selber eingebracht hast.

Was willst du aus dem Patent erklärt haben?
Es veranschaulicht doch super was EMIB ist. Eine 1-zu-1 Verbindung zwischen zwei Chips und dazu hab ich es genutzt. Willst du mir jetzt echt einen Strick draus drehen, dass ich für die elektrische Verbindung auf eben diese konzentriert habe? Wird ja echt lustig.

Auch zeigt das Patent schön, dass man ein speziellen Bereich für das Ballout hat (Nein, dass nennt man immer noch nicht Interface!) und wie das ganze eben aufgebaut ist.

Du unterstellst mir Unwissenheit an einem Punkt wo du nicht einmal die Begrifflichkeiten die verwendet wurden nach 10 mal Wiederholung verknüpfen konntest. Dass mir Wissen in manchen Bereichen fehlt ist Tatsache, doch du bist kaum derjenige der hier für Aufklärung gesorgt hat.

Ich hab dir auf einfachste Weise versucht zu erklären, warum es kein Interface ist. Was du gekonnt ignoriert hast und ich hab nicht zur Aufklärung beigetragen? Ja, so kann man es auch sehen... :uponder:

[Screemer]

Reicht jetzt langsam. Complicatet lag in seinen Augen nicht falsch, ist jetzt aber schlauer und wir können die Diskussion hier abschließen?!

[Complicated]

Ich hab dir auf einfachste Weise versucht zu erklären, warum es kein Interface ist. Was du gekonnt ignoriert hast und ich hab nicht zur Aufklärung beigetragen? Ja, so kann man es auch sehen... :uponder:Du wolltest mir erklären dass EMIB kein Interface ist. Somit hast du noch nicht einmal begriffen worüber ich sprach. Deine Interpretation des Patentes war ebenfalls falsch (150 war nicht das EMIB) und ich habe dir erst einmal die einzelnen Teile in Kontext gebracht. Das begreifst du aber anscheinend immer noch nicht. Daher würde ich es ebenfalls begrüßen wenn wir das nun lassen können.

Wenn es mir an Grundwissen fehlt, dann bist du deshalb noch lange nicht derjenige der mehr weiß.

[Gipsel]

Jetzt reicht es endgültig mit dem Kram. So ein sinnbefreiter Kleinkrieg wird hier nicht mehr geduldet.

[BoMbY]

Jemand bei Intel hat auf den falschen Knopf gedrückt (https://www.intel.in/content/www/in/en/gaming/overclocking-intel-processors.html?iid=subhdr-IN+game_power):

https://i.imgur.com/ILKhCjr.png

[y33H@]

Hihi, das ist fast genau eine Woche zu früh ;D

[Senior Sanchez]

Der Screenshot hat es zu golem.de geschafft :)
https://www.golem.de/news/core-i7-8809g-intel-listet-kaby-lake-g-mit-vega-grafik-1801-131912.html

[Nightspider]

Mal eine dumme Frage aber wird der Grafikchip dann ganz normal mit AMDs Treibern angesprochen oder bastelt Intel dafür jetzt einen Treiber?

Und wieso steht da Intels IGP 630 noch daneben? Hat das Package dann also IGP und "dedizierten" Grafikchip und kann dazwischen wechseln, zum Stromsparen?

Bin auch mal gespannt wie stark die CPU vom HBM2 Speicher profitiert, sofern sie Zugriff darauf hat.

Zum Vega Chip selbst gibts ja noch keine Details, was Größe oder Leistung betrifft oder?

[deekey777]

Die iGPU ist nötig, um den "2D"-Verbrauch gering zu halten.

Der Tabelle nach soll es HD 630 (KBL) sein und nicht UHD 630 (KBL-R). Jetzt stellt sich die Frage, welche GPU die besseren Multimediafähigkeiten aufweist. Ich tippe auf die HD 630.

[basix]

Ich hätte auf CFL gehofft

[deekey777]

Ich hätte auf CFL gehofft

Ich blick da nicht ganz durch, aber aktuell gibt es nur KBL als 45W-Version. Die Decoder-Seite von Intel ist da nicht ganz hilfreich.

[y33H@]

KBL (4C @ 45W) + Vega (28CU)

[Loeschzwerg]

Mal eine dumme Frage aber wird der Grafikchip dann ganz normal mit AMDs Treibern angesprochen oder bastelt Intel dafür jetzt einen Treiber?


Nachdem das ganze Produkt von Intel verkauft wird, dürften die Treiber auch offiziell von Intel gestellt werden.
Die eigentliche Entwicklung liegt sicher weiterhin bei AMD, da lässt man sich doch nicht in die Karten schauen.

[dildo4u]

Bin auf die Preise gespannt,Dell scheint was in dem Bereich für unter 1000€ zu verkaufen.

https://www.notebookcheck.com/Test-Dell-Inspiron-15-7000-7577-i5-7300HQ-GTX-1050-1080p-Laptop.272914.0.html

Das wird brutal ich hätte locker mit 1500 für Vega + Intel gerechnet.

[Thunder99]

Wo siehst du das?

[deekey777]

Ich blick da nicht ganz durch, aber aktuell gibt es nur KBL als 45W-Version. Die Decoder-Seite von Intel ist da nicht ganz hilfreich.


Das ist doch eine Desktop-CPU und CFL ist gerade nicht wirklich lieferbar.
Oder doch nicht, sondern doch eine mobile Lösung?
https://www.notebookcheck.com/Intel-Core-i5-8400H-SoC.275934.0.html

[y33H@]

Unter 1000 USD? wohl kaum.

[deekey777]

Unter 1000 USD? wohl kaum.
Mit dem richtigen TN-Bildschirm (so 1600x900), etwas Akku, damit der Laptop überhaupt starten kann, mieserablem Trackpad, HDD, usw. kann man den Preis unter 1000 US-Dollar drücken.

[y33H@]

Ich gehe davon aus, dass sowas nicht passiert, steht ja Intel drauf :P

[tm0975]

Ich gehe davon aus, dass sowas nicht passiert, steht ja Intel drauf :P

;D;D;D

ich rechne mit 600 bis 700 $ listenpreis für die chip-kombination alleine.

[deekey777]

Ich gehe davon aus, dass sowas nicht passiert, steht ja Intel drauf :P

Es gibt auch mit Intelprozessoren die gleichen Gurken wie mit APUs von AMD. Der Unterschied ist, dass es bessere und deutlich bessere Geräte mit Intel-CPUs gibt.


Wenn man den Preis nachunten drücken will, dann kriegt man das auch hin. So richtig vorstellen kann ich mir das nicht. Vom Gefühl her werden die Geräte preislich an ähnlichen Laptops mit 1050/1050TI orientiert. Und da ist die Bandbreite groß.

[danarcho]

Nachdem das ganze Produkt von Intel verkauft wird, dürften die Treiber auch offiziell von Intel gestellt werden.
Die eigentliche Entwicklung liegt sicher weiterhin bei AMD, da lässt man sich doch nicht in die Karten schauen.
Nachdem das Ding offiziell VEGA heißt, wird meiner Meinung nach auch der offizielle AMD Treiber dafür verwendet werden. (Vielleicht gibt's von Intel noch eine stripped-down Version, die nur mit einem Modell funktioniert...)
Dass Intel den Treiber nicht selbst entwickelt, hat auch nichts mit Karten-Schauen zu tun, sondern nur mit dem Aufwand ohne Nutzen. Seit langem gibt AMD alle notwendigen specs frei verfügbar raus, um selbst einen Treiber schreiben zu können und unter Linux sind die Treiber auch komplett open-source verfügbar.

[Loeschzwerg]

(Vielleicht gibt's von Intel noch eine stripped-down Version, die nur mit einem Modell funktioniert...)

Nur darum geht es doch :) Die erste Anlaufstelle und offizieller Kontakt für dieses Produkt ist Intel.

Die Treiber für das Dell Notebook mit AMD Grafik werden auch offiziell von Dell gestellt und nicht von AMD. Die generischen Treiber von NV/AMD/Intel können funktionieren, müssen aber nicht.

[basix]

Ist das bei mobilen GPUs nicht schon lange so? Ich meinte, dass für meine HD5650M nur der Treiber des Notebook-Herstellers zuverlässig funktioniert.

[deekey777]

Ich kann mir schwer vorstellen, dass sich die Geschichte wiederholt, dass nur die Treiber des Notebookherstellers akzeptiert werden, diese Tage sind eigentlich vorbei.

Auch wenn Intel die AMD-GPU in Eigenregie auf die Welt loslässt, so kann ich mir schwer vorstellen, dass nur das Treiberpaket von Intel funktioniert. Denkbar ist das natürlich (wenn eben nur der Inteltreiber die entsprechenden Einträge enthält).

[y33H@]

Mein Thinkpad X1 Carbon akzeptiert den Standard-Treiber von Intel nicht, sondern nur per Lenovo-Tool ... lässt sich zwar manuell installieren, aber halt nur per Umweg.

[deekey777]

Mein Thinkpad X1 Carbon akzeptiert den Standard-Treiber von Intel nicht, sondern nur per Lenovo-Tool ... lässt sich zwar manuell installieren, aber halt nur per Umweg.
Mir ging es schon um die Radeons, das war ja vor Jahren wirklich Payne in my Ass. Irgendwann kamen die Einträge der mobilen Grafikkarten in den allgemeinen Treiber. Aber das weißt du ja. Blöd ist der aktuelle Zustand bei den APUs, diese werden gern ausgelassen.

Bei meinem Medion-Tablet (x5-8350) ist es zum Glück möglich Inteltreiber zu installieren (NUC).

[gmb]

https://videocardz.com/74631/intel-launches-8th-gen-core-processor-with-radeon-rx-vega-graphics

Falls die gaming Vergleiche von RX Vega M GL vs GTX1050 und Vega M GH vs GTX 1060 Max-Q (6GB) hinkommen, wäre das ziemlich stark. Jedenfalls wenn man bedenkt, dass AMD die deutlich unterlegene GPU Architektur besitzt zu Pascal. Das wäre ohne EMIB und HBM nicht möglich gewesen.

[deekey777]

This post is under embargo until January 7, 2018 at 6:01 PM PDT. Please do not read it before this date.


Muahahaha.

[dildo4u]

https://videocardz.com/74631/intel-launches-8th-gen-core-processor-with-radeon-rx-vega-graphics

Falls die gaming Vergleiche von RX Vega M GL vs GTX1050 und Vega M GH vs GTX 1060 Max-Q (6GB) hinkommen, wäre das ziemlich stark. Jedenfalls wenn man bedenkt, dass AMD die deutlich unterlegene GPU Architektur besitzt zu Pascal. Das wäre ohne EMIB und HBM nicht möglich gewesen.
AMD ist nur kacke wenn man den Takt zu hoch ziehen muss was im Desktop der Fall ist.Die XBox One X ist für das Gebotene z.b ziemlich effizient und leise.

[gmb]

AMD ist nur kacke wenn man den Takt zu hoch ziehen muss was im Desktop der Fall ist.Die XBox One X ist für das Gebotene z.b ziemlich effizient und leise.


Auch für dedizierte GPUs für Notebooks. Pascal ist einfach durchweg viel energieeffizienter.

[y33H@]

Falls die gaming Vergleiche von RX Vega M GL vs GTX1050 und Vega M GH vs GTX 1060 Max-Q (6GB) hinkommen, wäre das ziemlich stark. Jedenfalls wenn man bedenkt, dass AMD die deutlich unterlegene GPU Architektur besitzt zu Pascal. Das wäre ohne EMIB und HBM nicht möglich gewesen.Die Benches sind CPU-limitiert, vor allem vs GTX 1050, von daher wäre ich da etwas vorsichtig.

[mboeller]

Die Benches sind CPU-limitiert, vor allem vs GTX 1050, von daher wäre ich da etwas vorsichtig.

aber doch nicht die letzen mit der i7 7700HQ CPU:

I7-7700HQ w/ GTX1060 Max-Q Graphics vs 8th Gen Intel Core w/ Radeon RX Vega M GH

3DMark 11 – Graphics.............1.07X BETTER
HITMAN.................................1.07X BETTER FPS
DEUS EX: Mankind Divided.......1.13X BETTER FPS
Total War: Warhammer............1.09X BETTER FPS

https://www.notebookcheck.net/NVIDIA-GeForce-GTX-1060-Max-Q-GPU-Benchmarks-and-Specs.224734.0.html


GTX1060 Max-Q Graphics; It is designed for thin and light laptops and about 10-15% slower than a regular GTX 1060 for laptops


die Radeon RX Vega M GH ist also geringfügig langsamer als die reguläre GTX 1060 (Laptop) ... bei ausgesuchten Benchmarks :)

[fondness]

https://videocardz.com/74631/intel-launches-8th-gen-core-processor-with-radeon-rx-vega-graphics

Falls die gaming Vergleiche von RX Vega M GL vs GTX1050 und Vega M GH vs GTX 1060 Max-Q (6GB) hinkommen, wäre das ziemlich stark. Jedenfalls wenn man bedenkt, dass AMD die deutlich unterlegene GPU Architektur besitzt zu Pascal. Das wäre ohne EMIB und HBM nicht möglich gewesen.

Du hast einfach nicht verstanden wie Vega funktioniert. Mit weniger Takt und Spannung ist das Ding äußerst effizient. Das hat sogar Raja bei der Präsi damals erwähnt, dass man nach unter ausgezeichnet skaliert. Die Kehrseite ist, dass die Leistungsaufnahme leider auch sehr stark steigt, wenn man den Takt anhebt.

[gmb]

Du hast einfach nicht verstanden wie Vega funktioniert. Mit weniger Takt und Spannung ist das Ding äußerst effizient.


Dann beweise es, bevor du einen auf dicke Hose hast. Schöngeredet wird sich viel und gerne von AMD Seite. Zu behaupten, Vega wäre so effizient wie Pascal, ist nämlich ein starkes Stück und wäre sensationell. Es gibt nicht den geringsten Hinweis darauf, dass dies bei mobilen GPUs zutreffend wäre.


Das hat sogar Raja bei der Präsi damals erwähnt, dass man nach unter ausgezeichnet skaliert.


Lächerlich, der Typ hat Vega hochgehypt und ist dann gefloppt. Wahrscheinlich mit der Grund, weswegen er gehen musste. Das jetzt als "Beweis" zu erwähnen, LOL.

[deekey777]

Er hat nicht geschrieben, dass Vega die Effizienz von Pascal hat.

Jetzt mal ehrlich: Bist du irgendwie in deinen Gefühlen verletzt, was Intel da macht? Gleiches Beleidigtsein im RR-Thread.

[reaperrr]

Dann beweise es, bevor du einen auf dicke Hose hast. Schöngeredet wird sich viel und gerne von AMD Seite. Zu behaupten, Vega wäre so effizient wie Pascal, ist nämlich ein starkes Stück und wäre sensationell. Es gibt nicht den geringsten Hinweis darauf, dass dies bei mobilen GPUs zutreffend wäre.
Von "so effizient wie Pascal" ist doch gar nicht die Rede (dazu müsste die Architektur in allen Taktbereichen so effizient wie Pascal sein, was natürlich nachweislich nicht der Fall ist), aber dass man in niedrigeren Taktbereichen sehr nah an Pascal rankommen kann ist beileibe nicht abwegig.


Vega10 ist in vergleichbaren Taktbereichen eindeutig wesentlich effizienter als Polaris, für 1.3 GHz braucht Vega10 vielleicht 20-30% mehr Saft als Polaris10, trotz doppelter Chipfläche, ganz grob kann man sagen, Vega braucht für den gleichen Takt bei gleicher Chipgröße dann nur ca. 2/3 der Energie von Polaris. Polaris 12 vs. GP108 (RX550 vs. GTX 1030) ist 50W zu 30W. Zieh von den 50W 1/3 ab, bist du bei 33, also schon bei einem vernachlässigbaren Unterschied.

Rein vom Verbrauch her also schonmal nicht so abwegig.

Zur Performance: Vega10 hängt mMn hauptsächlich an drei Dingen,
- 4fach-Frontend zu schmal (Auslastung, Geometrie-Durchsatz ohne Primitive-Shader)
- Speicherbandbreite/FLOP zu gering
- 64 ROPs zu wenig (vor allem wegen Z/Stencil-Ops)

Wenn die Angaben bei vcardz stimmen, hat die Intel-Vega volles 4fach-Frontend und volle 64 ROPs, und die halbe Bandbreite der V56. Also alle 3 obigen Flaschenhälse beseitigt, dadurch wahrscheinlich DEUTLICH höhere pro-FLOP-Leistung als V64 und V56.

[Locuza]

Einige Intel-Folien mit Specs sind nun zu finden:
https://imgur.com/a/CMWEv

via moKi24.2 unter PCGH:
http://extreme.pcgameshardware.de/news-kommentare-zu-cpus/498352-intel-amd-apu-weitere-leaks-nennen-performance-oberhalb-von-gtx1060-max-q-3.html#post9201416

Die zwei wichtigsten sind hier:
https://i.imgur.com/JVO2NAp.jpg
https://i.imgur.com/vjFx9gI.jpg

[Complicated]

Jetzt sag bloss, Intel schreibt "Dicrete Graphic" für AMD Vega in die offiziellen Slides. Vielleicht übernimmt die Presse und die Foren es ja jetzt einmal und hört mit dem "Intel-APU" Quark mal auf?

[deekey777]

Wenn Intel KBL als 8. Generation verkauft, Respekt.

[Locuza]

Jetzt sag bloss, Intel schreibt "Dicrete Graphic" für AMD Vega in die offiziellen Slides. Vielleicht übernimmt die Presse und die Foren es ja jetzt einmal und hört mit dem "Intel-APU" Quark mal auf?
Beruhigt dich dann die "korrekte" Verwendung eines Marketingbegriffs, welcher nicht klar definiert ist?
AMD hat damals (2015) offiziell eine High Performance Server APU für Datencenter angekündigt bzw. eine HPC APU auf älteren Präsentationsfolien, die in Asien gezeigt worden sind:
https://cdn.wccftech.com/wp-content/uploads/2016/01/AMD-High-Performance-Compute-Platforms.jpg
https://static1.gamespot.com/uploads/original/823/8237367/3057759-0473820062-AMD-F.jpg

Daraus ist bekanntlich nichts geworden, aber laut einer älteren Leak-Folie wäre das ein MCM gewesen, bestehend aus zwei Zeppelin dies und einmal Greenland, praktisch Vega10 mit GMI und 1:2 DP:SP:
http://www.pcgameshardware.de/screenshots/970x546/2016/07/AMD-HPC-APU-Greenland-pcgh.png

[fondness]

Das Ding könnte durchaus noch kommen, aber wohl erst mit Vega20, denn erst der hat xGMI und 1:2 DP.

[Locuza]

In dem Fall geht es mir nur um die Begrifflichkeit.
AMD hätte das Ding oder wird es, als APU bewerben, vermutlich weil es sich immerhin auf einem Package befindet und einen viel stärkeren und kohärenten Interconnect besitzt.
Diskret wären die Chips in dem Fall aber ebenfalls.

[Complicated]

Du wirst doch noch soweit unterscheiden können ob es ein SiP ist oder ein MCM-Package.
Threadripper/EPYC ist mit Sicherheit nicht das selbe Packaging wie Kabylake G hier.
Auch ist die Anbindung zwischen den Chips (Interposer/EMIB oder PCIe im Substrat) zu unterscheiden denke ich, wenn man vom Grad der Integration spricht.

Worum es aber hier ging, ist die Frage ob die AMD GPU integriert ist oder eine normale diskrete GPU ist. Manche hatten ja gesagt das "diskret" nur zutrifft wenn es nicht im Package enthalten ist. Doch Intel sieht das offensichtlich nach wie vor als diskrete GPU - ich bin immer froh wenn solche Begrifflichkeiten exakt geklärt sind und wir dann nächstes Jahr bei den Marktanteilen zu dGPU wissen ob das da mit gezählt wird oder nur AIB als dGPU gezählt werden wenn es darum geht.

[fondness]

Die offiziellen Folien:
https://videocardz.com/74640/intel-8th-gen-core-with-radeon-rx-vega-gpu-presentation-leaked

[robbitop]

Zur Performance: Vega10 hängt mMn hauptsächlich an drei Dingen,
- 4fach-Frontend zu schmal (Auslastung, Geometrie-Durchsatz ohne Primitive-Shader)
- Speicherbandbreite/FLOP zu gering
- 64 ROPs zu wenig (vor allem wegen Z/Stencil-Ops)

Naja und die ALU Auslastung ist auch nicht so toll unter Game Workloads..

[mboeller]

Dann beweise es, bevor du einen auf dicke Hose hast. Schöngeredet wird sich viel und gerne von AMD Seite. Zu behaupten, Vega wäre so effizient wie Pascal, ist nämlich ein starkes Stück und wäre sensationell. Es gibt nicht den geringsten Hinweis darauf, dass dies bei mobilen GPUs zutreffend wäre.


ich weiß wirklich nicht was du hast...

Die Intel "APU" gibt es mit max. 100W TDP. Davon wird die CPU wohl 25-35W benötigen, bleiben also 65-75W für die GPU. Damit ist der Verbrauch der VEGA-GPU in etwa so hoch wie bei der GTX-1600 maxQ und laut den ausgewählten Benchmarks ist sie in etwa gleich schnell (eigentlich sogar ein wenig schneller). Also gleicher Verbrauch wie Pascal bei gleicher Leistung. Schaut doch gut aus für AMD

[mboeller]

Die Benches sind CPU-limitiert, vor allem vs GTX 1050, von daher wäre ich da etwas vorsichtig.

wahrscheinlich ging es Intel bei dem Vergleich um die TDP.

i8550u + GTX 1050 = 55 - 65W

die Intel CPU i7 8705G mit VEGA M GL hat auch 65W TDP ... und ist bis zu 40% schneller in den Benchmarks aus der Präsentation.

[Spasstiger]

Finde ich eine äußerst attraktive Lösung für Allround-Laptops, die auch den Ansprüchen nicht ambitionierter Spieler gut genügt.
Interessant, dass AMD 50% mehr Rechenleistung und die doppelte Speicherbandbreite ggü. der mobilen Radeon RX 560 (Laptop) in eine wohl vergleichbare TDP packen konnte.

[y33H@]

Da isser: https://www.golem.de/news/kaby-lake-g-amd-intel-chip-schlaegt-nvidia-1801-131947.html

https://www.golem.de/1801/131947-151397-i_rc.jpg

[dildo4u]

rOTKgvPUXN8

[Akkarin]

ich weiß wirklich nicht was du hast...

Die Intel "APU" gibt es mit max. 100W TDP. Davon wird die CPU wohl 25-35W benötigen, bleiben also 65-75W für die GPU. Damit ist der Verbrauch der VEGA-GPU in etwa so hoch wie bei der GTX-1600 maxQ und laut den ausgewählten Benchmarks ist sie in etwa gleich schnell (eigentlich sogar ein wenig schneller). Also gleicher Verbrauch wie Pascal bei gleicher Leistung. Schaut doch gut aus für AMD

Wie siehts mit der chipgröße aus ?

[Loeschzwerg]

http://youtu.be/rOTKgvPUXN8

Der Kühler macht einen ordentlich dimensionierten Eindruck.

[vinacis_vivids]

@Akkarin

~200mm²

[deekey777]

Da isser: https://www.golem.de/news/kaby-lake-g-amd-intel-chip-schlaegt-nvidia-1801-131947.html

https://www.golem.de/1801/131947-151397-i_rc.jpg
Was die ROPs angeht, so kann 32 bzw. 16 ROPs nicht stimmen, in der Präsentation steht 64 bzw. 32 Pixel/Takt, also 64 bzw. 32 ROPs (warum die Reduzierung?).

[mboeller]

HP hat das erste Notebook mit Kaby Lake G vorgestellt:

https://www.notebookcheck.com/HP-Spectre-x360-15-2018-gibt-s-auch-mit-Kaby-Lake-G-CPU-und-Vega-Grafik-Hands-On-Bilder.277180.0.html

[mr coffee]

Ist es im Bereich des möglichen, dass so ein Package für die nächsten Konsolen genutzt wird?

[M4xw0lf]

Ist es im Bereich des möglichen, dass so ein Package für die nächsten Konsolen genutzt wird?
Wird sicher aufgrund der Kostenfrage nicht in dieser Form eingesetzt werden. Höchstens eine Art RavenRidge-Derivat + HBM auf einem gemeinsamen Interposer, was gegenüber der Variante Intel-CPU + AMD-GPU + HBM auf EMIB wohl kaum langsamer, dafür aber leichter (weniger fehleranfällig) und günstiger zu fertigen ist.

[HOT]

Konsolen bekommen eh semi-Custom, also ein monolithisches Die mit Zen2+Navi. Termin ist ja offenbar 2021 bei Sony, das passt auch dazu.

[ndrs]

Ist es im Bereich des möglichen, dass so ein Package für die nächsten Konsolen genutzt wird?
Ich glaube nicht, dass man von einem gemeinsamen Speicherpool für CPU und GPU wieder weg geht.

[Bucklew]

Also die Performance klingt nicht sonderlich beeindruckend, wenn das jeder OEM seit einem Jahr mit einer GTX1060 und einem i7 bauen konnte. Noch dazu im nahezu gleichen power envelope.

Da hatte man angesichts des Hypes doch etwas mehr erwartet.

[dildo4u]

Das ist deutlich besser als im Desktop 1060 liegen dort bei 110 Watt 580 bei 190.

https://www.computerbase.de/2017-12/grafikkarten-round-up-2018/3/#diagramm-leistungsaufnahme-der-grafikkarte-spiele-durchschnitt

Sie vergleichen sich ja sogar mit dem Max Q Modell also dem auf Effizienz getrimmten Chip.Wenn der Verbrauch vergleichbar ist,ist es das mit Abstand konkurrenzfähigste AMD GPU Modell zur Zeit.
NV fehlt ein Chip zwischen 1060 und 1070,das wird hier optimal ausgenutzt.

[Bucklew]

Wenn der Verbrauch vergleichbar ist,ist es das mit Abstand konkurrenzfähigste AMD GPU Modell zur Zeit.
Das kannst du leider nicht behaupten, weil wir nur den Verbrauch der Kombilösung (CPU+GPU) kennen und nicht die jeweiligen Verbräuche einzeln.

Der vergleichbare (Single-)Chip von Intel verbraucht nur 15W:
https://ark.intel.com/products/124968/Intel-Core-i7-8650U-Processor-8M-Cache-up-to-4_20-GHz

Somit läge der Verbrauch des GPU-Parts bei 85W. Das ist ein ganzer Brocken mehr, als die GTX1060 maxQ.

NV fehlt ein Chip zwischen 1060 und 1070,das wird hier optimal ausgenutzt.
Der GP104 als maxQ liegt als GTX1070 bei 70-80W. Und ist Leistungstechnisch eine ganz andere Hausnummer. Sind locker mal +30% mehr Leistung.

[dildo4u]

Du hast recht wie immer muss man echte Tests abwarten und nicht nur die Folien glauben.Aber es war imo immer ersichtlich das AMD am Desktop die Chips zu hoch takten muss,Mobile Vega liegt hingegen wohl nur bei 1.1Ghz.

[deekey777]

Das kannst du leider nicht behaupten, weil wir nur den Verbrauch der Kombilösung (CPU+GPU) kennen und nicht die jeweiligen Verbräuche einzeln.

Der vergleichbare (Single-)Chip von Intel verbraucht nur 15W:
https://ark.intel.com/products/124968/Intel-Core-i7-8650U-Processor-8M-Cache-up-to-4_20-GHz

Somit läge der Verbrauch des GPU-Parts bei 85W. Das ist ein ganzer Brocken mehr, als die GTX1060 maxQ.


Der GP104 als maxQ liegt als GTX1070 bei 70-80W. Und ist Leistungstechnisch eine ganz andere Hausnummer. Sind locker mal +30% mehr Leistung.

Schnell den Unsinn sichern, bevor auffällt, dass es sich bei der CPU um einen KBL-H handelt.

[basix]

Das kannst du leider nicht behaupten, weil wir nur den Verbrauch der Kombilösung (CPU+GPU) kennen und nicht die jeweiligen Verbräuche einzeln.

Der vergleichbare (Single-)Chip von Intel verbraucht nur 15W:
https://ark.intel.com/products/124968/Intel-Core-i7-8650U-Processor-8M-Cache-up-to-4_20-GHz

2.1GHz Basistakt vs. 3.1GHz Basistakt würde ich nicht als vergleichbar betiteln. Ausserdem hat die CPU offiziell 45W TDP und wird dementsprechend höher takten und Last. Was wir wirklich nicht kennen, ist wie gut das Loadbalancing zwischen den Chips ausfällt und ob es überhaupt eines gibt. Auf Folien ist was von "Intel Dynamic Tuning" zu lesen. Was genau das macht ist mir aber nicht ganz klar.

[Complicated]

In der ersten Pressemitteilung hat Intel das Load-Balancing gesondert hervorgehoben und den Eindruck erweckt hier würde neues zum Einsatz kommen. Muss man mal abwarten, was sie dazu noch detaillierter verlauten lassen:
https://newsroom.intel.com/editorials/new-intel-core-processor-combine-high-performance-cpu-discrete-graphics-sleek-thin-devices/
Similarly, the power sharing framework is a new connection tailor-made by Intel among the processor, discrete graphics chip and dedicated graphics memory. We’ve added unique software drivers and interfaces to this semi-custom discrete GPU that coordinate information among all three elements of the platform. Not only does it help manage temperature, power delivery and performance state in real time, it also enables system designers to adjust the ratio of power sharing between the processor and graphics based on workloads and usages, like performance gaming. Balancing power between our high-performing processor and the graphics subsystem is critical to achieve great performance across both processors as systems get thinner.

[Mangel76]

Das kannst du leider nicht behaupten, weil wir nur den Verbrauch der Kombilösung (CPU+GPU) kennen und nicht die jeweiligen Verbräuche einzeln.

Der vergleichbare (Single-)Chip von Intel verbraucht nur 15W:
https://ark.intel.com/products/124968/Intel-Core-i7-8650U-Processor-8M-Cache-up-to-4_20-GHz

Somit läge der Verbrauch des GPU-Parts bei 85W. Das ist ein ganzer Brocken mehr, als die GTX1060 maxQ.


Der GP104 als maxQ liegt als GTX1070 bei 70-80W. Und ist Leistungstechnisch eine ganz andere Hausnummer. Sind locker mal +30% mehr Leistung.

Wirklich selten so viel Mist gelesen. Deekey777 hats ja schon festgestellt, hier noch einmal offiziell:

https://pics.computerbase.de/8/1/0/4/4/4-1080.1008610039.png

Das hier ist die vergleichbare CPU: Intel® Core™ i7-7920HQ (https://ark.intel.com/products/97462/Intel-Core-i7-7920HQ-Processor-8M-Cache-up-to-4_10-GHz)

Und eben weil das Powerbudget zwischen CPU und GPU geteilt wird ("First implementation of power sharing across CPU & GPU", siehe Bild) kann man es sowieso nicht direkt vergleichen. Bei CPU-lastigen Workloads kann die CPU sicher ihren Turbo lange halten, bei GPU-lastigen Workloads bekommt Vega halt mehr ab.

[dargo]

Habe ich das richtig verstanden? Es gibt ein Package mit zwei TDPs? Einmal normal @65W und einmal OC @100W?

[fondness]

Habe ich das richtig verstanden? Es gibt ein Package mit zwei TDPs? Einmal normal @65W und einmal OC @100W?

Es gibt fünf Varianten, drei haben 65W und die Vega GL(=Graphics Low) GPU mit 20 CUs und niedrigen Taktraten. Zwei haben 100W TDP und die Vega GH (=Graphics High) GPU mit 24 Cus und höheren Taktraten. Package gibt es sicherlich nur eins, ist ja alles dieselben GPU.

„Vega hatte alles was Intel brauchte“, begann der Hersteller Mitte der letzten Woche bei einem Pressebriefing seine Ausführungen über das neue Produkt mit dem Codenamen Kaby Lake-G. Heraus kommt eines der interessantesten Intel-Produkte seit vielen Jahren – das es ein solches ist, verdeutlichte der Hersteller gleich mehrfach. Durch und durch kommt es von Intel, die Vega-Grafikeinheit ist einzigartig und werde inklusive Support wie dem Intel-Adrenalin-Treiber lediglich eingekauft, das ganze Packaging und Co. übernimmt Intel jedoch selbst.
https://www.computerbase.de/2018-01/intel-kaby-lake-g/

[Grendizer]

Laut Heise unterscheiden sie sich :

https://www.heise.de/newsticker/meldung/Intel-NUC-VR-faehige-Mini-PCs-mit-Intel-AMD-Kombiprozessoren-ab-Maerz-3935799.html

z.B.
I7-8809G = 4x3,1 Ghz (Boost bis 4,2), Vega mit 24 Compute Units (1536 Shadern) mit 1063 - 1190 Mhz und freiem Multiplikator (100 Watt)
I7-8705G = , Vega mit 20 Compute Units (1280 Shadern) mit 931 - 1011 Mhz. (65 Watt)

[y33H@]

Was die ROPs angeht, so kann 32 bzw. 16 ROPs nicht stimmen, in der Präsentation steht 64 bzw. 32 Pixel/Takt, also 64 bzw. 32 ROPs (warum die Reduzierung?).Intel sagt sogar nur 16 ROPs ...

[Locuza]

Intel sagt sogar nur 16 ROPs ...
Nein, Intel sagt bis zu 16 Render-Back-Ends und gibt den Pixel-Durchsatz hinter der Bezeichnung ROPs an.
Jedes RB beinhaltet 4 ROPs, wobei AMD die Bezeichnung vielleicht auch mal anstatt ROPs verwendet hat oder Pixel-Units.
Aber Namen sind dann Schall und Rauch, entscheidend ist der angegebene Durchsatz und der beträgt maximal 64 Pixel pro Takt oder 32 Pix/clock bei den schwächeren Modellen.
Das ist der gleiche Durchsatz wie bei Hawaii/Fiji/Vega, entsprechend sind es 64 ROPs als Back-End.

[deekey777]

Intel sagt sogar nur 16 ROPs ...
Intel sagt 16 RBEs bei dergroßen Version und64 Pixel/Takt, also 64 ROPs, oder?

Wer fertigt eigentlich die Vega-GPU?

[y33H@]

Nein, Intel sagt bis zu 16 Render-Back-Ends und gibt den Pixel-Durchsatz hinter der Bezeichnung ROPs an.
Jedes RB beinhaltet 4 ROPs, wobei AMD die Bezeichnung vielleicht auch mal anstatt ROPs verwendet hat oder Pixel-Units. Aber Namen sind dann Schall und Rauch, entscheidend ist der angegebene Durchsatz und der beträgt maximal 64 Pixel pro Takt oder 32 Pix/clock bei den schwächeren Modellen. Das ist der gleiche Durchsatz wie bei Hawaii/Fiji/Vega, entsprechend sind es 64 ROPs als Back-End.Du hast Recht, habe es korrigiert. Hatte das mit den Quad-RBE falsch im Kopf.

@ deekey777

Wird GloFo/Samsung mit 14LPP sein.

[mczak]

Manche sagen ja schon lange AMD wäre da bei den ROPs unterdimensioniert, kann man bei dem Chip sicher nicht sagen. Das Teil liegt sowohl bei der Rechenleistung wie auch der Bandbreite ja deutlich hinter einer RX 580 zurück, hat aber den doppelten Pixeldurchsatz. Auch eine "Desktop-Konfiguration" mit höheren Taktraten und den vermuteten 28 CUs würde daran nicht wirklich etwas ändern. Ist natürlich auch so im Vergleich zu Vega 56/64. Würde mich interessieren wieviel das am Ende bringt, vielleicht gibt's da ja irgendwann Tests dazu.

[deekey777]

...

@ deekey777

Wird GloFo/Samsung mit 14LPP sein.

Win-Win-Situation für AMD. X-D

[fondness]

Dell XPS 15 2-in-1: Convertible mit vier Kernen und Vega dank Kaby Lake-G
https://www.computerbase.de/2018-01/dell-xps-15-9575-kaby-lake-g/

[Nakai]

RR wurde verschoben. Womöglich kommt GloFo nicht mit der Produktion nach.
Woran liegt das bloß?
Vll wegen der Vega auf dem Intel-Package?
Vll wegen Epyc?
Was frisst die 12nm-Produktionslinie bei GloFo?

[Pirx]

Kommt doch im Februar, aber stimmt schon.
Ich schätze mal, GF hat einfach nicht genug Kapazität.

[CompuJoe]

Wenn man sieht auf wie vielen Hochzeiten AMD tanzt ist es doch logisch das da zu Engpässen kommt.
Und ich glaube das wird sich nicht ändern, im Gegenteil.

Den wird praktisch alles aus den Händen gerissen, das ist der Grund warum bei dem ein oder andern Produkt kaum was im Endkundenmarkt ankommt, zumal das von den Minern abgegriffen wird.

[deekey777]

Intel bekämpft AMD halt auf allen Fronten, jetzt wird sogar die GloFo-Fertigung blockiert. X-D

[Bucklew]

RR wurde verschoben. Womöglich kommt GloFo nicht mit der Produktion nach.
Woran liegt das bloß?
Vll wegen der Vega auf dem Intel-Package?
Das wäre natürlich ein Arsch-Move von Intel, einfach so viele Vega-Chips zu ordern, dass AMD gar keine Chips mehr für ihre eigene APU hätte :eek:

[DinosaurusRex]

Oh nein! AMD hat so viele Aufträge, dass nicht einmal die Chipfertiger hinterherkommen. Management jetzt angespannt. :rolleyes:

Besser kann es für AMD doch gar nicht laufen: Die Kasse klingelt und alleine die Tatsache, dass sich der Marktführer im Desktop-Prozessorsegment gegen die eigenen GPUs, gegen Nvidia und stattdessen für die Lösungen von AMD entschieden hat, ist ein unbezahlbarer Imagegewinn. Intel nutzt AMD GPUs, Apple nutzt AMD GPUs, Tesla nutzt AMD GPUs, PlayStation und XBox nutzen AMD GPUs. Irgendwann kommen vieleicht auch PC Gamer auf den Trichter, dass Marketing nicht alles und AMD nicht komplett unfähig ist.

[Bucklew]

gegen Nvidia
Haben sie? Oder ist NVIDIA vielleicht einfach nicht so blöd, Intel-Produkte zu verbessern? Oder hat NVIDIA kein Problem ihre Chips los zu werden? :uponder:

[deekey777]

Oh nein! AMD hat so viele Aufträge, dass nicht einmal die Chipfertiger hinterherkommen. Management jetzt angespannt. :rolleyes:

Besser kann es für AMD doch gar nicht laufen: Die Kasse klingelt und alleine die Tatsache, dass sich der Marktführer im Desktop-Prozessorsegment gegen die eigenen GPUs, gegen Nvidia und stattdessen für die Lösungen von AMD entschieden hat, ist ein unbezahlbarer Imagegewinn. Intel nutzt AMD GPUs, Apple nutzt AMD GPUs, Tesla nutzt AMD GPUs, PlayStation und XBox nutzen AMD GPUs. Irgendwann kommen vieleicht auch PC Gamer auf den Trichter, dass Marketing nicht alles und AMD nicht komplett unfähig ist.

Der Vorteil dieser unseligen Allianz für AMD ist, dass sie für Intel die GPUs fertigen und diese dann an Intel liefern, ohne sich darum kümmern zu müssen, was danach damit passiert. Denn das ist die Aufgabe von Intel.

[BoMbY]

RR wurde verschoben, oder waren vielleicht einfach nur die Gerüchte mal wieder falsch? Was ist wahrscheinlicher?

[vinacis_vivids]

Manche sagen ja schon lange AMD wäre da bei den ROPs unterdimensioniert, kann man bei dem Chip sicher nicht sagen. Das Teil liegt sowohl bei der Rechenleistung wie auch der Bandbreite ja deutlich hinter einer RX 580 zurück, hat aber den doppelten Pixeldurchsatz. Auch eine "Desktop-Konfiguration" mit höheren Taktraten und den vermuteten 28 CUs würde daran nicht wirklich etwas ändern. Ist natürlich auch so im Vergleich zu Vega 56/64. Würde mich interessieren wieviel das am Ende bringt, vielleicht gibt's da ja irgendwann Tests dazu.

Die dicken 24NCUs von Vega sind anscheinend performancemäßig auf dem Level der schlankeren 32/36CUs von Polaris. Pixel Engine würde ja auch erneuert. 4GB HBC und neue Cache-Struktur gleiche die niedrigere Bandbreite aus.

28/32NCUs wären ideal für AMD eigene inhouse APU oder auch Desktop Ableger. Wäre perfekt.

[deekey777]

Die dicken 24NCUs von Vega sind anscheinend performancemäßig auf dem Level der schlankeren 32/36CUs von Polaris. Pixel Engine würde ja auch erneuert. 4GB HBC und neue Cache-Struktur gleiche die niedrigere Bandbreite aus.

28/32NCUs wären ideal für AMD eigene inhouse APU oder auch Desktop Ableger. Wäre perfekt.
Was genau hat das mit der Anzahl der ROPs zu tun?

[mboeller]

RR wurde verschoben, oder waren vielleicht einfach nur die Gerüchte mal wieder falsch? Was ist wahrscheinlicher?

RR für Laptops kam ein wenig später als die Gerüchte wissen wollten. Ursprünglich ist man von Oktober 2017 ausgegangen.

RR für den Desktop hat aber keine Verspätung. Einige hatten vielleicht auf Januar 2018 gehofft, jetzt ist es aber der Februar... ergo keine Verspätung.

[mboeller]

Der Vorteil dieser unseligen Allianz für AMD ist, dass sie für Intel die GPUs fertigen und diese dann an Intel liefern, ohne sich darum kümmern zu müssen, was danach damit passiert. Denn das ist die Aufgabe von Intel.

welche unselige Allianz?
Für AMD ist das doch ein kompletter WIN. Bei vielen Intel-Laptops, die bisher eine GTX1050 oder gar eine GTX1060 drin hatten wird jetzt eine Vega-GPU verbaut. Der Verlust an APU-Umsatz dürfte sich in sehr engen Grenzen halten. Und die bisherigen AMD-Alternativen RX560 oder gar RX580 kamen für viele Laptop-Hersteller bisher anscheinend nicht in Frage (Verbrauch?).

mal ein kleiner nicht repräsentativer Vergleich:

RX580:
http://www.notebookinfo.de/grafikkarten/gaming-und-highend-grafikkarten/amd-radeon-rx/amd-radeon-rx-580/

RX560:
http://www.notebookinfo.de/grafikkarten/gaming-und-highend-grafikkarten/amd-radeon-rx/amd-radeon-rx-560-notebook/

GTX1050Ti:
http://www.notebookinfo.de/grafikkarten/gaming-und-highend-grafikkarten/nvidia-geforce-gtx-10/nvidia-geforce-gtx-1050-ti/

GTX1060:
http://www.notebookinfo.de/grafikkarten/gaming-und-highend-grafikkarten/nvidia-geforce-gtx-10/nvidia-geforce-gtx-1060/

Der tatsächliche Impact des Deals hängt jetzt nur noch von der Preisgestaltung von Intel ab.

Beim dem Deal gibt es aus meiner Sicht deshalb momentan nur 1 Verlierer: Nvidia

[deekey777]

Natürlich ist es ein Win für AMD. Ein solches Kombo aus RR-APU und dVega hätte der Markt eher ignoriert als zig Geräte dafür angekündigt.

"Unselige Allianz" deswegen, weil eine solche Zusammenarbeit bisher einmalig ist.

Ich frage mich, wie Nvidia darauf reagiert. An sich verkaufen sich ihre mobilen Produkte sehr gut, aber sie sind schon etwas älter und werden gerade mit Intelprozessoren kombiniert.

[basix]

Mit Nvidia Ampere und später 7nm werden die (Grafik-)Karten eh neu gemischt. Aber für AMD ist es sicher ein riesiger Schritt: Viele gut ausgestattete Intel-Notebooks kommen nun mit AMD Grafik daher. Dazu die RR APUs Mobile sowie Desktop. Die Verbreitung von Vega als Grafikarchitektur wird ab jetzt sehr rasant ansteigen (OEM PCs, Notebooks). Solch ein grosser Sprung an Marktanteil wird AMD gut tun.

High-End Notebooks kommen dann evtl. mit 6C Intel und Nvidia Ampere daher, aber der Marktanteil solcher Lösungen ist vergleichsweise gering.

[AffenJack]

Die Frage ist, was das Teil kosten wird. Davon wirds abhängen ob nur High-End Designs damit bestückt werden oder es öfter eingesetzt wird. Bisher haben wir nur das HP und XPS als Ankündigung oder?

Edit: Gerade beim Spectre gesehen, gerade mal 100$ mehr als die MX150 Version, das ist natürlich ein Top Angebot.

[vinacis_vivids]

Was genau hat das mit der Anzahl der ROPs zu tun?

Die ergibt für mich keinen Sinn. 64 für die 24CU und 32 für die 20CU Version. ROP-Leistung wird überbewertet.

[Bucklew]

Bei vielen Intel-Laptops, die bisher eine GTX1050 oder gar eine GTX1060 drin hatten wird jetzt eine Vega-GPU verbaut.
GTX1050/1060 ist defakto EOL. Wir werden im Sommer/Herbst sicherlich Ampere-basierte Notebooks sehen. Dann ist es eben fraglich, wie gut in Sachen Perf/Watt sich die KabyLake-G Geräte gegen die runderneuerten Intel CPUs und NVIDIA GPUs schlagen werden. Wenn die die gleiche Leistung bei sagen wir mal 30% weniger Leistungsaufnahme liefern können, wird KabyLakeG ziemlich uninteressant.

Beim dem Deal gibt es aus meiner Sicht deshalb momentan nur 1 Verlierer: Nvidia
Nein, da NVIDIA einfach keine APUs mit x86 liefert. Ich sehe hier tatsächlich Intel als den großen Gewinner. Deren APUs verdrängen nun die AMD-APUs vollständig. Welchen Grund gibt es denn jetzt noch eine AMD-APU zu kaufen? Vorher war es ja wenigstens der absolut überlegene GPU-Part.

Und Imagemäßig, was hat AMD davon? AMD steht nirgends, tatsächlich steht nur "Radeon" in den Folien. Hat jemand mal den Treiber gesehen?

Wenn genug von den Geräten verkauft werden, glauben die Leute wahrscheinlich eher Radeon wäre eine Intelmarke ;D

[Rancor]

@ Bucklew

Warum sollte man keine RR APUs kaufen?

[spotz]

Neben dem hier schon öfter genannten Grund des Preises und der Verfügbarkeit, denke ich das es auch wesentlich von Intels Willen abhängt dieses Produkt zu vermarkten. In der Vergangenheit reichte Intels Einfluss auf die Hersteller aus, dass diese bessere Lösungen anderer Unternehmen größenteils ignorierten.
Ein weiterer Vorteil von Kaby Lake G scheint ein kleineres Mainboard zu sein. Laut Computerbase (https://www.computerbase.de/2018-01/dell-xps-15-9575-kaby-lake-g/) wies Dell auf diesen Vorzug bei der Vorstellung des XPS 15 2-in1 hin. Der Vorgänger hatte noch eine 1050 Ti mit dabei. Inwieweit ein um 30% verkleinertes Mainboard für die Notebookhersteller ein wichtiges Argument ist, weiß ich nicht. Allerdings bringt Dell auf gleichem Raum statt eines 56Wh Akkus nun einen mit 75Wh unter, der eine Laufzeit von 15 Stunden ermöglichen soll.

Da laut Berichterstattung der Vega M mit 20 CUs nur etwas leistungsfähiger als die 1050 Ti sein soll, könnte selbst ein Nachfolger mit unveränderten 768 Shadern in 12nm oder 10nm Fertigung dank der besseren Energieeffizienz eine gute Alternative zum Kaby Lake G sein.

Wenn Nvidia aber wie in der 3DCenter Jahresvorschau vermutet den GA107 erst im Herbst/Winter 2018 herausbringt, wird es wohl zu spät sein. Bis dahin könnten die Notebookhersteller ihre Produkte schon entsprechend auf Kaby Lake G umgestellt haben. Daher sollte Nvidia - natürlich nur wenn möglich - früher auf diese Intel APU reagieren.

[deekey777]

@ Bucklew

Warum sollte man keine RR APUs kaufen?
Weil AMD Scheiße ist. Und wenn man schon KBL-G mit den APUs von AMD gleich setzt, was will man sonst erwarten?

[dargo]

Hat eigentlich die Vega die hier verbaut wird auch HBCC?

[Loeschzwerg]

Gehe ich schwer davon aus, ist es doch essenzieller Bestandteil von Vega.

[robbitop]

GTX1050/1060 ist defakto EOL.
Naja es dauert idR schon bis eine neue Generation auch voll im mobilen Bereich ausgerollt ist. Vor Q3 ist vermutlich nichts EOL IMO.

[mboeller]

GTX1050/1060 ist defakto EOL. Wir werden im Sommer/Herbst sicherlich Ampere-basierte Notebooks sehen. Dann ist es eben fraglich, wie gut in Sachen Perf/Watt sich die KabyLake-G Geräte gegen die runderneuerten Intel CPUs und NVIDIA GPUs schlagen werden. Wenn die die gleiche Leistung bei sagen wir mal 30% weniger Leistungsaufnahme liefern können, wird KabyLakeG ziemlich uninteressant.


... und AMD bringt 3-6 Monate später Vega in 7nm ... und das Spiel beginnt von vorne. ;D


Nein, da NVIDIA einfach keine APUs mit x86 liefert. Ich sehe hier tatsächlich Intel als den großen Gewinner. Deren APUs verdrängen nun die AMD-APUs vollständig. Welchen Grund gibt es denn jetzt noch eine AMD-APU zu kaufen? Vorher war es ja wenigstens der absolut überlegene GPU-Part.


seit wann ist Kaby-Lake G eine APU???? Komplett anderer Preis/Performance-Bereich. Die Überschneidung ist nahe Null.

[dildo4u]

Naja es dauert idR schon bis eine neue Generation auch voll im mobilen Bereich ausgerollt ist. Vor Q3 ist vermutlich nichts EOL IMO.

Je nach Partner dauert es ewig Surface Book 2 hat z.b noch Maxwell Chips.

https://www.microsoft.com/de-de/surface/devices/surface-book/overview#surfaceconfiguration

[deekey777]

Je nach Partner dauert es ewig Surface Book 2 hat z.b noch Maxwell Chips.

https://www.microsoft.com/de-de/surface/devices/surface-book/overview#surfaceconfiguration

Die Weiterleitung funktioniert nicht, aber egal:

Surface Book 2 hat natürlich Pascals, das erste Surface Book bekam 2016 die Performance Base mit GTX965M, die erst im ersten HJ 2017 nach Deutschland kam. Dein Beispiel ist nicht gelungen.

Aber ja, noch heute werden kleinere Maxwells neben kleinen Pascals verbaut. 920M oder 940M findet man weiterhin.

... und AMD bringt 3-6 Monate später Vega in 7nm ... und das Spiel beginnt von vorne. ;D


Zunächst bringt AMD Vega Mobile. Nach unten ist AMD eigentlich gut aufgestellt, auch wenn die mobilen RR-APUs nicht die Performance einer MX130 bringen. Was fehlt, sind Nachfolger der Polaris-Generation (ab 12 CUs aufwärts). Auf der anderen Seite darf man nicht vergessen, dass Pascal und Polaris in etwa die gleiche Generation sond.

[dildo4u]

Stimmt scheinbar nur Deutschland wird einem das als neu verkauft.

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

[Rancor]

Weil AMD Scheiße ist. Und wenn man schon KBL-G mit den APUs von AMD gleich setzt, was will man sonst erwarten?

Aha :rolleyes:

[Bucklew]

Naja es dauert idR schon bis eine neue Generation auch voll im mobilen Bereich ausgerollt ist. Vor Q3 ist vermutlich nichts EOL IMO.
Denke nicht, NVIDIA wird Ampere Mobile sicherlich mit CannonLake kombinieren, also Herbst '18. Da wird sich NVIDIA nicht mehr viel Inventory auf Lager legen. Die Vorlaufzeiten sind ja deutlich höher, wenn das ganze im Notebook verbaut wird.

... und AMD bringt 3-6 Monate später Vega in 7nm ... und das Spiel beginnt von vorne. ;D
Vega in 7nm ist beschränkt auf AI-Anwendungen mit sampeling in 2018. Da wirst du mit etwas mehr Zeit rechnen müssen. Vor 2019 kommt da nix.

seit wann ist Kaby-Lake G eine APU???? Komplett anderer Preis/Performance-Bereich. Die Überschneidung ist nahe Null.
Nahe Null? Es gibt sowohl eine RR-APU mit 65W TDP, als auch KabyLake-G. Je weiter nach unten du gehst, desto uninteressanter wird die GPU, weil die Aufgabenbereiche sogar eine Intel-GPU schafft.

[deekey777]

Hier geklaut: (https://forum.beyond3d.com/threads/intel-kaby-lake-amd-radeon-product-spin-off.60480/page-14#post-2017983)
https://i.imgur.com/OXj1mO9.jpg

[Complicated]

Hat eigentlich die Vega die hier verbaut wird auch HBCC?
Ja - Intel wirbt auch damit:

https://www.notebookcheck.com/fileadmin/Notebooks/News/_nc3/1079.JPG

Übrigens ist die Anbindung der CPU an die GPU mit x8 PCIe 3.0 umgesetzt:

https://www.notebookcheck.com/fileadmin/Notebooks/News/_nc3/584.JPG

[dargo]

Ja - Intel wirbt auch damit:

https://www.notebookcheck.com/fileadmin/Notebooks/News/_nc3/1079.JPG

Aja... merci.

[y33H@]

Allerdings bringt Dell auf gleichem Raum statt eines 56Wh Akkus nun einen mit 75Wh unter, der eine Laufzeit von 15 Stunden ermöglichen soll.Nope, das XPS 15 (9560) hat 97 Wh mit M.2-SSD ... nur die Version mit zusätzlicher 2,5-Zoll-Festplatte hat 56 Wh. Sprich das neue XPS 15 (9575) hat den deutlich kleineren Akku, aber das Gerät an sich ist halt auch kompakter/schlanker.

[deekey777]

First Hybrid Intel-AMD Chip Benchmarks With Dell XPS 15 Show Vega M Obliterating Intel UHD And MX 150 Graphics (https://hothardware.com/news/intel-core-i7-8705g-benchmarks-dell-xps-15-vega-m-umd-mx-150)

Running at 1920x1080 resolution, the XPS 15 2-in-1 was able to maintain an average frame rate of nearly 35 frames per second with High image quality settings dialed in (29.69 on Very High in the video above). Not bad, for a roughly 4.5 pound machine that measures only 16 mm thick. Compared to a similar 8th generation Core system with Intel's own integrated UHD 620 graphics, it was no contest. Even on Medium quality settings, the Intel UHD 620 was only able to manage about 8 frames per second. In fact, Intel's own 8th Gen IGP can't even run the game on High IQ because it runs out of frame buffer memory.
Wirklich gut.

[mboeller]

First Hybrid Intel-AMD Chip Benchmarks With Dell XPS 15 Show Vega M Obliterating Intel UHD And MX 150 Graphics (https://hothardware.com/news/intel-core-i7-8705g-benchmarks-dell-xps-15-vega-m-umd-mx-150)


Wirklich gut.

Nett! In dem Vergleich fast 50% schneller als eine MX150

in etwa auf dem Niveau einer GTX 1050:
https://www.notebookcheck.com/Mobile-Grafikkarten-Benchmarkliste.735.0.html?type=&sort=&showClassDescription=1&archive=1&perfrating=1&or=0&itemselect_7362=7362&itemselect_8010=8010&itemselect_7503=7503&itemselect_8000=8000&showBars=1&3dmark13_ice_gpu=1&3dmark13_cloud_gpu=1&3dmark13_fire_gpu=1&3dmark11_gpu=1&gpu_fullname=1&architecture=1&pixelshaders=1&vertexshaders=1&corespeed=1&boostspeed=1&memoryspeed=1&memorybus=1&memorytype=1&directx=1

passt doch für die 65W Variante.

[M4xw0lf]

Jo, würd ich nehmen.

[deekey777]

Ich auch, aber mit einem R5 2500U drauf.

Ist schon interessant, dass AMD Intel den Vortritt lässt und die eigene Vega M noch nicht zeigt (nicht zeigen darf?).

[ApuXteu]

Ich finde es ein bisschen schade, dass kaum Produkte mit der CPU angekündigt sind. Mit dem 8809G ist ja ausser dem Intel Teil garnichts angekündigt. Ob da noch ein Notebook kommt? Ich hätte gerne eines mit der stärkeren Variante des Grafikchips.

Mit dem 8509g sind ja mittlerweile auch nur das HP Spectre und das Dell XPS 15 angekündigt. Ich finde das ein bisschen mager. Immerhin dürften die Hersteller schon länger von der CPU wissen, aber keiner anscheinend passiert nicht viel.

Als Alternative hätte ich noch ein Gerät mit Nvidia Max-Q GPU ins Auge gefasst, aber da gibt es ja auch kaum etwas. Bei den Notebooks mit GTX1060 Max-Q gibt es nur Plastikbomber und vom angekündigten 1050TI MaxQ ist überhaupt nichts zu sehen.

Nach Meltdown hätte ich ja eigentlich überhaupt ein AMD Gerät ins Auge gefasst. Aber mit halbwegs leistungsfähiger Grafik und unter 17" scheint es nichts zu geben.

Wie lange dauert es denn erfahrungsgemäß, bis nach der Vorstellung Geräte auf den Markt kommen?

[Pirx]

es kommt angeblich zu Verzögerungen wegen Meltdown/Spectre

[BoMbY]

Fudo hat einen interessanten Artikel über Dell's Kaby Lake G: Dell XPS 15 2in1 looks like a winner (https://www.fudzilla.com/news/notebooks/45559-dell-xps-15-2in1-looks-like-a-winner)

Da ist auch ein Bild von dem Board, mit der neuen Kühllösung (hab das mal gedreht):

https://i.imgur.com/ZpywUQn.jpg

Scheinbar nutzen die tatsächlich auch irgendwas das nach Nano-Graphite, oder ähnlichem, aussieht anstelle von Heatpipes.

[Unicous]

Es kann nur Nano-Graphit sein...


oder eine "angemalte" heat pipe.:rolleyes:


https://www.notebookcheck.net/fileadmin/_migrated/pics/slim3.jpg
https://www.notebookcheck.net/fileadmin/_migrated/pics/IMG_7159_1600_02.jpg
https://www.notebookcheck.net/fileadmin/Notebooks/Lenovo/ThinkPad_T460s-20FA003GGE/g21.jpg

[y33H@]

KBL-G sitzt unter den drei Kupfer-Pipes, nicht unter den beiden schwarzen ... der Chipsatz ist da auch nicht drunter, was dann?

https://abload.de/thumb/20402m9rcg.jpg (http://abload.de/image.php?img=20402m9rcg.jpg)

[Unicous]

The material wrapped around the heat pipes is called Aerogel laminate. The material is a silicon aerogel in a ePTFE liner. The liner from GORE (a really cool company – still family owned and killing it in industries from apparel to aerospace and now computing) was critical, allowing us to thin out the product for feasibility use in the PC industry. Dell is first to launch with this material – it has the lowest conductivity known to man. Launching tomorrow, you’ll see a second product with this material – the first with 0.1mm material thickness (thinnest material). Net-net – this allowed for close to a 3C reduction in skin which equates to close to a 4W increase in overall PL1 level performance at steady state.

https://blog.dell.com/en-us/secrets-dell-xps-13-thermal-engineering/

Mit anderen Worten: Gore-Tex.:wink::wink:

[BoMbY]

Naja, nicht ganz, auch wenn die es wohl herstellen dürfen: Aerogel-Fiber Hybrid Laminate (https://technology.nasa.gov/patent/KSC-TOPS-39)

Aber gut, das macht auch Sinn - die Heatpipe gezielt wärmedämmen.

[Unicous]

:rolleyes:

https://www.google.com/patents/US7868083

[BoMbY]

Ja, was tut man nicht alles dass Du Dich auch mal überlegen fühlen darfst ...

[Unicous]

Ich kann nichts dafür, dass du Quatsch erzählst und denkst es entspräche der Wahrheit. ¯\_(ツ)_/¯

Man sollte eben erst einmal recherchieren bevor man mit voller Inbrunst Behauptungen aufstellt. (Das Ergooglen des Patents hat im Übrigen Sekunden gedauert. Zumal das NASA-Laminat, also ein Material das aus mehreren verschieden Schichten und/oder Materialien besteht, eben keine Beschichtung ist sondern ein... Laminat, wie es ja auch die Beschreibung erklärt. Man muss sie sich nur mal durchlesen bevor man sie postet. :up:)

[mczak]

https://blog.dell.com/en-us/secrets-dell-xps-13-thermal-engineering/
Das tönt ja sehr enthusiastisch. Bei notebookcheck.com (unter anderem) war dieses XPS 13 (nehme doch an das war dieses, 9370?) schon im Test. Das Kühlsystem wurde durchaus gelobt, aber einen derart hohen Wert bei cinebench R15 multi bei Dauerbetrieb hat man da auch nicht (so ueberschlagsmässig müssten das bei 700 Punkten mindestens 30W sein).
https://www.notebookcheck.com/Test-Dell-XPS-13-9370-Core-i5-FHD-Laptop.279864.0.html
Da hat man wohl die TDP zusätzlich raufgesetzt und mit dem Kühlschrank nachgeholfen :tongue:. Oder eine handselektierte CPU verwendet (oder undervolting oder was auch immer).

[Loeschzwerg]

KBL-G sitzt unter den drei Kupfer-Pipes, nicht unter den beiden schwarzen ... der Chipsatz ist da auch nicht drunter, was dann?

https://abload.de/thumb/20402m9rcg.jpg (http://abload.de/image.php?img=20402m9rcg.jpg)

Es geht schon um das Systemboard mit den schwarzen Heatpipes:
https://youtu.be/e7f_WdsqVn4?t=1m15s

Edit: Ach... das sind Systemboards für ein 13" und 15" (KBL-G) XPS.

http://www.tomshardware.com/news/dell-xps-15-cooling-intel-kaby-lake-g-vega-amd,36334.html

[y33H@]

Haha, ja - das Board des 13er liegt auf dem Akku des 15er ;D hab ich gestern völlig verpeilt ;(

[Brillus]

Mal ne ganz andere Frage, wie sieht es bei dem Ding eigentlich bzgl. Linuxtreiber aus schon irgendwas gehört.

[Loeschzwerg]

Die Intel IGP läuft sicher OoB und Vega M ist vermutlich ebenfalls recht unproblematisch mit den freien Treiber bzw. es kommt schnell ein Update. Interessanter könnte die Umschaltung zwischen IGP und Vega M werden.

[Thunder99]

Ab wann gibt es brauchbare Notebooks oder Convertible Gerät?