PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Diskussion zu: Hardware- und Nachrichten-Links des 17. Juli 2020

Leonidas
2020-07-18, 09:04:57
Link zur News:
https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-17-juli-2020
Lowkey
2020-07-18, 09:42:46
Was anderes:

https://www.heise.de/news/Intel-Core-i9-10850K-Guenstigerer-Zehnkern-Prozessor-zeigt-sich-4846786.html

Intel kommt mit dem Aussortieren der Kerne für den 10900k nicht hinterher. Laut den Foren waren die Reviewsamples durchschnittlich, die ersten Retail-CPUs super, dann kamen CPU, die gerade so die Specs erreichten und nun seit 2-3 Wochen gibt es gar nichts mehr.
Gast
2020-07-18, 09:59:15
Mal eine technische Frage zum Thema Tape Out: Warum dauert bei CPUs die Phase von Tape Out zu Produktreife im Vergleich zu GPUs so viel länger? Bei GPUs spricht man ja von ungefähr einem halben Jahr (s. z.B. aktuell beim Ampere Tape Out). Bei CPUs ist es hingegen Gang und Gäbe, dass es dann noch eineinhalb Jahre braucht, bis das Produkt tatsächlich auf den Markt kommt.

Ist ein CPU-Design schlichtweg so viel komplexer aufgebaut als eine GPU (die ja im Wesentlichen aus identischen, massiv parallelisierten Funktionsblöcken besteht), dass die ganze Verifizierungsphase einfach so viel länger braucht? Oder gibt's da noch andere Gründe dafür?
Leonidas
2020-07-18, 10:37:52
Ich vermute die Abhängigkeiten sind größer und benötigen daher mehr Testzeit. Eine GPU stellt letztlich nur eine Anwendung dar, einen CPU ist der Master des Systems, da läuft die Top-Level-Software drauf, die innersten Zugriff hat. Da kann viel schiefgehen - und Rücknahmen kann man sich in dem Business einfach nicht leisten. Im Gegensatz zu einem Auto kann man bei einem echten Fehler nicht einfach reparieren.

Ergo: Extrem viel höherer Validierungs-Bedarf.
Benutzername
2020-07-18, 12:10:12
Schönes Detail, wie Du kleine +8C bei Alder Lake aufgeführt hast in der Tabelle. :D
danarcho
2020-07-18, 12:16:27
Bei GPUs können Bugs leicht durch den Treiber a.k.a Compiler ausgeglichen werden. Beispiel: Navi hat einen Branch-Bug, wenn das Jump-target genau 0x3f dwords entfernt liegt. Der Treiber fügt einfach ein NOP ein, um die Adresse zu ändern. Bei x86 soll aber jeglicher legacy Code funktionieren, das kann man sich also nicht erlauben.

Zu Death Stranding:
Proton 5.0.10 RC is now available for testing, with DEATH STRANDING now playable! (https://twitter.com/Plagman2/status/1283538305397579776)
Day-1 support bei einem DX12 Titel unter Linux. Wollts nur mal erwähnen.
Leonidas
2020-07-18, 13:57:08
Schönes Detail, wie Du kleine +8C bei Alder Lake aufgeführt hast in der Tabelle. :D


Ironischerweise entstanden als Notlösung, weil dort nicht viel Platz für große Erklärungen ist.
Korvaun
2020-07-18, 16:36:57
Die Tabelle zeigt mal wieder sehr schön wie unglaublich Intel abgekackt hat was Fertigung angeht. 6 "Generationen" in 14nm.... davon 5 mit Skylake Architektur. Anders hat das AMD genug Luft gegeben um aufzuholen. Verrrückt das 2015 als Skylake eingeführt wurde bei AMD noch Bulldozer aktuell war ;)
Gast
2020-07-18, 23:10:42
Beispiel: Navi hat einen Branch-Bug, wenn das Jump-target genau 0x3f dwords entfernt liegt.
Hast du da mehr Infors/Quellen zu? Sowas interessiert mich.
Gast
2020-07-19, 11:45:10
Mal eine technische Frage zum Thema Tape Out: Warum dauert bei CPUs die Phase von Tape Out zu Produktreife im Vergleich zu GPUs so viel länger? Bei GPUs spricht man ja von ungefähr einem halben Jahr (s. z.B. aktuell beim Ampere Tape Out). Bei CPUs ist es hingegen Gang und Gäbe, dass es dann noch eineinhalb Jahre braucht, bis das Produkt tatsächlich auf den Markt kommt.


Viel mehr und intensivere Tests.
CPUs sind quasi das Herzstück des Rechners wenn da etwas nicht funktioniert zerschießt du das komplette System. Man kann zwar per Microcode auch noch einiges fixen, allerdings ist man da deutlich beschränkter als beispielsweise bei einem Grafiktreiber.

Grafikkarten sind zwar auch nicht unwichtig und ein Fehler an der falschen Stelle kann dir hier auch das System zerschießen, aber man kann über den Grafiktreiber sehr viel mehr an Fehlern noch reparieren/umgehen.
Eine CPU wird von der Software direkt über Maschinencode angesprochen und das muss auch funktionieren.

Bei einer GPU ist der interne Befehlssatz nicht für die Software von außen sichtbar. Die Software kommuniziert hier nur mit einer API, diese wiederum mit dem Grafiktreiber, welcher wieder die API-Befehle in den Maschinencode der Grafikkarte übersetzt. An dieser Stelle kann man einiges korrigieren, falls die Hardware einen Fehler hat. Wichtig ist eigentlich nur dass die Karte zuverlässig im VGA-Modus bootet und anschließend den Grafiktreiber laden kann. Wenn das geschehen ist kann man die meisten Hardwarefehler umgehen.
Leonidas
2020-07-19, 13:03:36
Danke für die Erklärung, genauso wird es sein.
Gast
2020-07-19, 13:31:08
Jetzt wär natürlich interessant, was passiert, wenn sie noch Fehler finden? Wird das Design dann doch noch einmal geändert? Und muss dann noch mal alles von vorne validiert werden?
Leonidas
2020-07-19, 14:11:41
Je nach Fehler: Ja. Aber die allermeisten Fehler werden dann einfach per Treiber/BIOS gefixt. Die wirklich schlimmen Fehler zwingen zu einem korrigierten Silizium, womit der gesamte Vorgang von neuem startet. Vielleicht muß nicht jeder Test wiederholt werden, aber bannig Zeit verliert man trotzdem.
Gast
2020-07-19, 18:41:56
Jetzt wär natürlich interessant, was passiert, wenn sie noch Fehler finden? Wird das Design dann doch noch einmal geändert? Und muss dann noch mal alles von vorne validiert werden?

Wenn ein Fehler per Microcode/Treiber fixbar ist nicht, ansonsten muss ein neues Stepping her und das ganze Spiel beginnt von vorne.
Scream
2020-07-20, 13:42:26
Insofern bleibt weiterhin abzuwarten, ob es Alder Lake tatsächlich noch ins Jahr 2022 schafft: Denn selbst bei grundsätzlich funktionierender Technik bleibt weiterhin die 10nm-Fertigung als Stolperstein, schließlich stellt Alder Lake Intels ersten Versuch dar, 10nm-Prozessoren ins breite Consumer-Portfolio zu bringen.
2021?
Leonidas
2020-07-20, 13:56:05
Ohhh ... gefixt.
danarcho
2020-07-21, 13:28:33
Hast du da mehr Infors/Quellen zu? Sowas interessiert mich.
zB hier https://reviews.llvm.org/D63494 (https://reviews.llvm.org/D63494)
Das fällt garantiert in die Kategorie "Erst hinterher gemerkt". Bei Navi gibt es da eine ganze Reihe von "Wenn nach Instruktion X eine Instruktion vom Typ Y folgt, hängt sich die GPU auf" Bugs, die eine Reihe unterschiedlicher Mitigations erfordern (meistens NOPs oder einzelne ALU instruktionen dazwischen packen). Bei Navi2 haben sie die nach aktuellem Stand anscheinend alle behoben.

Wen es interessiert, hier (https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/amd/compiler/README.md#rdna-gfx10-hazards) haben wir mal alle uns bekannten Bugs gelistet.