News 28-Kern-Prozessor: X599-Plattform soll die Grundlage für A-Serie bilden

[MK one]

wir reden hier ja auch nur von einer Übergangszeit =12-15 Monate , in 7 nm wird der TR3 mit 32 Kernen wieder nur 2 aktive Dies haben

 

[rg88]

in 7 nm wird der TR3 mit 32 Kernen wieder nur 2 aktive Dies haben

Sehr viel Spekulation. Wir wissen doch gar nicht wie die neuen Dice ausschauen? 16 Kerne? Glaub ich eher weniger. 12 halte ich für realistischer. Ist ja auch eine Sache der Ausbeute. Nur 16er herzustellen und dann den großteil für den Massenmarkt abschalten ist doch recht unsinnig.

Außer wir sehen doch mal mehr verschiedene Masken als wie bisher zwei (APU und CPU)

Ergänzung (15. August 2018)

Woher kennst Du die Ausbeute? Gibt es dazu Quellen? Immerhin werden alle 18 Kern (also HCC) Chips auch für die 12, 14 und 16 Kerner verwendet, man kann also teildefekte Dies immer noch nutzen und zwar für LGA 2066 und LGA 3647 CPUs.

Ich muss dir doch sicherlich jetzt nicht erklären, dass die Ausbeute bei einem größeren Die entsprechend schlechter ist, oder?

 

[Holt]

Da Threadripper und Epyc quasi vom selben Band laufen

Trotzdem haben beide schon immer unterschiedliche Platinen, also das Teil wo die Dies drauf sitzen, denn die haben ein unterschiedliches Pinout und damit wäre es kein Staatsakt diese für TR2 zu ändern, wenn das nicht sowieso wegen der Anschlüsse auf dem Die gemacht wurde.

 

[Hill Ridge]

Warum kann man dann einen Epyc in einem TR4 Brett betreiben?

 

[Holt]

Wo gibt es einen Beleg das ein EPYC auf einem Board für ThreadRipper (also X399) läuft? Zwar dürften die Sockel von TR und EPYC mit je 4094 mechanisch gleich sein, vermutlich bis auf ein paar Nasen um nicht die falsche CPU dort einbauen zu können, aber der Sockel für EPYC nennt sich SP3 und der für ThreadRipper SP3r2 oder auch TR4.

 

[Hill Ridge]

Der8auer hat es mal getestet.

Es gibt keine Nasen, die etwas verhindern würden...

 

[Holt]

Da hat er aber was abkleben müssen und mehr als Booten und das dann rote LEDs angingen, ist aber meine ich nicht dabei rausgekommen. Ohnehin sind auf den Boards dann nur die 4 RAM Kanäle verbunden die TR hat und auch die Pins im Sockel für die zusätzlichen PCIe Lanes dürfte nicht verbunden sein. Damit gewinnt man also nichts, warum sollte man also den teureren EPYC statt des billigeren TR in so ein Board setzen? Das der Pinout durchaus ähnlich oder gar identisch ist, kann ja durchaus sein, interessanter wäre es damit dann aber die beiden WX TR2 in einem EPYC Board zu betreiben, wenn man damit alle 8 RAM Channels nutzen kann, aber die anderen 4 dürften schon auf der Platine gar nicht mit dem Die verbunden sein, eben um AMD das Geschäft mit den EPYC nicht zu kanibalisieren.

 

[rg88]

Trotzdem haben beide schon immer unterschiedliche Platinen, also das Teil wo die Dies drauf sitzen, denn die haben ein unterschiedliches Pinout

Das der Pinout durchaus ähnlich oder gar identisch ist, kann ja durchaus sein,

Also was jetzt nun?
Du stellst immer wieder so absolute Behauptungen auf, ohne im Geringsten etwas darüber zu wissen. Warum eigentlich? Dann sie doch wenigstens deinen Fehler ein.
Dass du eine Intel-Fan bist, der an jedem TR oder Epyc ein Haar aus der Suppe zieht, wissen wir doch eh alle..
Warum agierst du umgekehrt nicht genauso?

 

[Smartcom5]

…
Intel hat einen riesigen Die, der schlechte Ausbeute und damit enorm hohe Herstellungskosten bedingt.
…

Woher kennst Du die Ausbeute? Gibt es dazu Quellen? Immerhin werden alle 18 Kern (also HCC) Chips auch für die 12, 14 und 16 Kerner verwendet, man kann also teildefekte Dies immer noch nutzen und zwar für LGA 2066 und LGA 3647 CPUs.

Was hat bitte das Eine mit dem Anderen zu tun?! Es erklärt sich von selbst, daß ein derart großer Die nun einmal die physikalisch bedingte Ausnahme als Regel und damit im wahrsten Sinne des Wortes die absolute Speerspitze der Yield und das Barrenbold des jeweiligen Fertigungsprozesses darstellt.

Dafür braucht man weder irgendeine tiefer gehende Quellenlage noch explizite Einsicht in die jeweiligen Yield-Rates, daß ist bloß schlußfolgliche Logik – und die kann man auch mit einer blauen Brille noch ganz gut erkennen, meinst Du nicht?

Natürlich wird man teildefekte HCC-Dies als 12-, 14- und 16-Kerner weiter verwenden, das ist ja auch nur logisch und ökonomisch geboten. Was sollen sie denn auch sonst machen? Etwa LCC-Dies benutzen, die ohnehin nur maximal 10 Kerne in der größten Ausbaustufe haben und ›zusammenkleben‹ oder noch teurere XCC-Dies dafür hernehmen, die zwar ohnehin zu kaum etwas anderes zu gebrauchen sind, die entsprechende Anzahl Kerne bieten, aber im Gegensatz dafür mit ausufernder Verlustleistung brillieren?

Das hängt aber sehr von der Nutzung ab, bei vielen Anwendungen ist der 16 Kern 2950X sogar schneller als der 2990WX und bei Spielen sieht der kein Land wenn man den 2990WX nicht in den 16 Kern oder 8 Kern Modus umstellt.

Es hat sich binnen kürzester Zeit bereits herausgestellt, daß das schlechte Abschneiden des 2990WX im Vergleich zum 2950X sehr wahrscheinlich einzig an den verwendeten nVidia-Karten und deren Treiber liegt – und damit sämtliche Reviews für die Katz sind.

Ändert aber nichts an der Tatsache, das kaum Wer nachtesten wird und der 2990WX für immer als „Bandbreiten-Krüppel“ in den Köpfen der Leute wird hängen bleiben. … und ComputerBase scheint solche (aufklärenden) Nachrichten ja offensichtlich aus Prinzip nicht bringen zu wollen.

Nimmt man stattdessen eine AMD-Grafikkarte, erreicht man mit einer Radeon RX Vega 64 plötzlich gar doppelte Frame-Zahlen wie mit einer GTX 1080 Ti!

Lektüre:
Golem.de • 32-Kern-CPU – Threadripper 2990WX läuft mit Radeons besser


In diesem Sinne

Smartcom

 

[Holt]

Vermutlich sorgt bei AMD der Treiber dafür das er immer auf dem Die läuft an dessen PCIe Lanes die Graka auch wirklich hängt. Es wäre auch logisch wenn AMD sowas in seine Treiber einbaut, aber kann man es auch von NVidia erwarten das deren Treiber auf jede CPU einzeln optimiert wird?

 

[rg88]

Du drehst es dir schon wirklich immer so hin, wie es dir gerade am Besten in dein Weltbild passt, oder?

 

[MK one]

ach was , Nvidia schlampt immer wieder mal was den Treiber angeht , sei es der 2990wx oder Ryzen oder nur DX12 ...

 

[Ozmog]

Und obwohl bereits diverse Probleme mit Nvidia auf Ryzen bekannt sind, sind die CPU-Tests ausschließlich mit der 1080Ti...

 

[Smartcom5]

Vermutlich sorgt bei AMD der Treiber dafür das er immer auf dem Die läuft an dessen PCIe Lanes die Graka auch wirklich hängt. Es wäre auch logisch wenn AMD sowas in seine Treiber einbaut, aber kann man es auch von NVidia erwarten das deren Treiber auf jede CPU einzeln optimiert wird?

@Holt, auf einer entsprechenden AMD-Grafikkarte ist ein in Hardware vorhandener Hardware-Scheduler des GCN Command Processors beim Scheduling der Threads auf die jeweiligen Kerne für das jeweilige Multi-Threading verantwortlich, welcher zeitgleich übrigens auch für Asynchronous Computing zuständig ist. nVidia hat diesen Hardware-Scheduler schlicht nicht (mehr) und implementiert diesen in Software. Steht aber ja auch so in den Whitepapers der GCN-µArch von AMD (Seite 11 ff.) …

Pro-Tip: Bei Vollauslastung wird eine Echtzeit-Implementierung in Software prinzipbedingt immer verlangsamen, während eine Hardware-Implementierung nicht von diesem Phänomen betroffen ist (vgl. → Analogie Hardware-Decoder vs. Software-Decoder).

Im Übrigen hat man das Phänomen der einbrechenden FPS dadurch gegenprüfen können, indem man einen einzelnen Kern deaktivierte, siehe Beitrag im 3DCenter-Forum.


In diesem Sinne

Smartcom

PS: Man verzeihe mir die möglicherweise zwecks Erläuterung erhebliche Simplifizierung der jeweiligen Sachverhalte.

 

[Holt]

auf einer entsprechenden AMD-Grafikkarte ist ein in Hardware vorhandener Hardware-Scheduler des GCN Command Processors beim Scheduling der Threads auf die jeweiligen Kerne für das jeweilige Multi-Threading verantwortlich

Wie soll denn ein HW Controller auf der Graka unter Windows die Verteilung der SW Threads auf die CPU Kerne beeinflussen? Also erst Denken, dann schreiben und das rg88 der Beitrag trotzdem gefällt, sagt alles.

 

[Ozmog]

Hast du überhaupt den verlinkten Beitrag gelesen?

 

[Smartcom5]

Wie soll denn ein HW Controller auf der Graka unter Windows die Verteilung der SW Threads auf die CPU Kerne beeinflussen? Also erst Denken, dann schreiben und das rg88 der Beitrag trotzdem gefällt, sagt alles.

Mhm … Keine Ahnung?!
Aber wenn ich raten müßte, dann würde ich sagen, daß es in der Tat daran liegen könnte, daß AMD‘s Grafik-Treiber den in Hardware vorhandenen Thread-Scheduler der GCN-Grafikkarten in Form des GCN Command Processors dafür nutzt, die Last auf die verschiedenen Prozessor-Kerne zu verteilen.

Kurioserweise steht diese beschriebene Arbeitsweise des GCN Command Processors sogar in den Whitepapers der GCN-Architektur, welche AMD dankenswerterweise so freundlich war, Unwissenden tatsächlich unentgeltlich zur Verfügung zu stellen (auf daß man sich bilden möge, bevor man versucht mitzureden).
Donnerwetter, oder?! Jetzt halt das Netzteil fest!

Ich weiß, daß Dein Einwurf, … naja. Trotzdem eine ebenso grenzdebile Gegenfrage:
„Wie soll denn ein HW Audio-Controller auf der Graka unter Windows die Verteilung der SW Threads Audio-Streams auf die CPU Kerne Ausgabe-Geräte beeinflussen?“

Antwort: Durch den Treiber! *ba dum ts*

Hast du überhaupt den verlinkten Beitrag gelesen?

Nein, hat er natürlich nicht (und wenn, hat er die Quintessenz geflissentlich ignoriert, weil sie ihm nicht schmeckt).
Aber hey, bisschen Polemik ist doch immer toll!


In diesem Sinne

Smartcom

 

[rg88]

Also erst Denken, dann schreiben und das rg88 der Beitrag trotzdem gefällt, sagt alles.

Ach, was sagt es denn?

 

[Holt]

Es besagt das weder du noch Smartcom oder Ozmog die Grundlagen eines Rechner mit einer Graka begriffen haben, denn dieser Hardware-Scheduler des GCN Command Processors sitzt in der GPU, der bearbeitet dann die Befehle die der Treiber ihm schickt, er kann aber eben keinen Einfluss darauf nehmen wie der Task Scheduler von Windows die Threads auf die Kerne der CPU verteilt, dies kann allenfalls der Treiber selbst indem er seine AffinityMask setzt. Ihr wirft mal eben fleißig durcheinander was auf der CPU und was auf der GPU passiert.

 

[MK one]

Vermutlich sorgt bei AMD der Treiber dafür das er immer auf dem Die läuft an dessen PCIe Lanes die Graka auch wirklich hängt. Es wäre auch logisch wenn AMD sowas in seine Treiber einbaut, aber kann man es auch von NVidia erwarten das deren Treiber auf jede CPU einzeln optimiert wird?

Wenn könnte es höchstens der CPU OS Treiber , nicht der Graka Treiber
https://www.hardwareluxx.de/index.p...bric-cpus-und-gpus-miteinander-verbinden.html

Ein externes Anbinden von GPUs als Beschleuniger per Infinity Fabric hingegen wäre ein Schritt, die Bandbreite zu erhöhen und die Latenzen zu verringern, denn gerade letztgenannte sind bei einer Anbindung per PCI-Express ein störender Faktor und ein Hauptgrund für die Entwicklung von NVLink bei NVIDIA

das direkte anbinden an den IF Bus wäre ein logischer Schritt , da müßten jedoch die GraKa Hersteller mitziehen , das würde tatsächlich was bringen , vielleicht klappt es ja mit dem Ryzen 5xxx , derzeit jedoch noch nicht absehbar wann das umgesetzt wird . Freuen . allerdings auch überraschen , würde es mich wenn schon der Ryzen 3xxx die Möglichkeit dazu bietet auf dann B 550 / X 570 Boards , reichen würde mir jedoch auch PCIe 4.0