mkl1 schrieb:
Jemand schreibt seine Gedanken auf Twitter nieder und schon wird es als Quelle angesehen, AMD Gerüchte sind immer wieder ein Lacher wert. Die 1,1 Ghz machen überhaupt kein Sinn so niedrig, das wäre ja dann langsamer als ADL-S (max 1,55 Ghz). RDNA2 ist viel taktfreudiger als Xe LP.
Bei den 1,1 GHz bin ich auch ins Grübeln gekommen.
Ich würde die Linuxtreiber für das Auslesen von zukünftigen GPUs nicht mehr als Quelle verwenden. Hier hat sich schon bei Rembrandt gezeigt, dass die Treiber nicht das ganze Bild bzw ein verzerrtes Bild gezeigt haben.
AMD hat die Art und Weise wie der Treiber initialisiert wird geändert. Damit entfallen die umständlichen Konfigurationen über die PCI-ID der Chiptypen und das verstecken Chiptypen in Codenamen die zuletzt auf Fischen basiert sind. Der Code wird damit massiv aufgeräumt, flexibler und wartungsfreundlicher. Ein Nebeneffekt ist, dass Konfigurationsinforamtionen im Treiber komplett entfallen.
Alles was diese Diskusion losgetreten hat ist folgender Code in .../smu_v13/smu_v13_0_5_ppt.h
(Das ist der komplette Code in der Datei, der Rest sind Kommentare):
#ifndef SMU_V13_0_5_PPT_H
#define SMU_V13_0_5_PPT_H
extern void smu_v13_0_5_set_ppt_funcs(struct smu_context *smu);
#define SMU_13_0_5_UMD_PSTATE_GFXCLK 1100
#endif
Noch eine Anmerkung: Der Eintrag mit GFXCLK kam nachträglich hinzu und wirkt für mich wie ein Fremdkörper.
Bei den alten GPUs z. B. in .../smu11/sienna_cichlid_ppt.h sieht die Datei ganz anders aus:
#ifndef SIENNA_CICHLID_PPT_H
#define SIENNA_CICHLID_PPT_H
typedef enum {
POWER_SOURCE_AC,
POWER_SOURCE_DC,
POWER_SOURCE_COUNT,
} POWER_SOURCE_e;
#define SIENNA_CICHLID_UMD_PSTATE_PROFILING_GFXCLK 1825
#define SIENNA_CICHLID_UMD_PSTATE_PROFILING_SOCCLK 960
#define SIENNA_CICHLID_UMD_PSTATE_PROFILING_MEMCLK 1000
#define DIMGREY_CAVEFISH_UMD_PSTATE_PROFILING_GFXCLK 1950
#define DIMGREY_CAVEFISH_UMD_PSTATE_PROFILING_SOCCLK 960
#define DIMGREY_CAVEFISH_UMD_PSTATE_PROFILING_MEMCLK 676
#define BEIGE_GOBY_UMD_PSTATE_PROFILING_GFXCLK 2200
#define BEIGE_GOBY_UMD_PSTATE_PROFILING_SOCCLK 960
#define BEIGE_GOBY_UMD_PSTATE_PROFILING_MEMCLK 1000
extern void sienna_cichlid_set_ppt_funcs(struct smu_context *smu);
#endif
Sienna CiCHLID = Navi 21 = RX6900XT/RX6800(XT)
Dimgrey Cavefish = Navi 23 = RX 6600(XT)
Beige Goby = Navi 24 = RX6500XT
Also ich sehe jetzt keinen Grund mir über die genaue Bedeutung von
SMU_13_0_5_UMD_PSTATE_GFXCLK Gedanken zu machen.
Es gibt keinen Anlass anzunehmen das SMU_13_0_5 ausschließlich für die iGPU im ION von Zen 4 gilt.
Ich denke
nicht dass
SMU_13_0_5_UMD_PSTATE_GFXCLK eine maximale Frequenz definiert.
Nitschi66 schrieb:
Ja, wenn man den bisherigen Leaks glauben möchte.
Es ergibt keinen Sinn wenn AMD die iGPU in das CCD packen würde.
- Was ist mit dem Fall von 2 CCDs?
- Was ist bei EPYC mit 8 CCDs?
Nitschi66 schrieb:
Desweiteren können die 1,1 Ghz sehr wohl stimmen.
Sie können aber etwas ganz anderes bedeuten.
Abwarten und Tee trinken.
Nitschi66 schrieb:
Wieso könnten die Takraten niedriger ausfallen? Der IO-Die ist ein eigener Chip. Stand jetzt ist er gar noch in 14/12nm von Golbalfoundries gefertigt.
AMD hat bei allen Folien zum Chiplet-Ansatz erklärt, dass das IOD immer im nächst älteren Node als das CCD gefertigt wird. Also ist davon auszugehen dass AMD wenn das CCD auf 5 nm wechselt mit dem IOD auf 6 nm wechselt (Niemand macht z. Z. bei TSMC ein neues Design in N7).
N6 für das IOD entspricht der Gerüchtelage. Ich kenne kein aktuelles Leak das bei Zen 4 von einem IOD in 14 nm bei GF ausgeht.
Durch den Wechsel auf N6 hat AMD die Option eine iGPU im IOD zu integrieren. Es ist zu erwarten, dass AMD auch das Packaging ändert. Damit gibt es Raum für die Grafik-IO.
Nitschi66 schrieb:
Wenn ich es richtig in Erinnerung habe ist das eine Samsung-Fertigungstechnik. Lizenziert bei/von Globalfoundries.
Ja.
Nitschi66 schrieb:
Zenario 2 ist, dass die Fertigung vom IO-Die auch ein update erfährt. In der Gerüchteküche sind auch wieder 7nm von TSMC im Spiel. Neben der Grafikeinheit ist aber auch memorycontroller und das ganze andere gedöns im chip. Das beeinflusst ja auch das Design und alles.
Du hast recht. Aber das alles ist bei den APUs auch enthalten.
Also sollte es auch bei der iGPU keine grundsätzlichen Probleme geben.
mkl1 schrieb:
Und nein ich glaube nicht, dass 1,1 Ghz stimmen können, wenn schon die schlecht taktende Xe LP deutlich höher taktet und AMD sicherlich nicht gegen die ADL-S iGPU verlieren möchte - das wäre ein PR Fiasko.
Die Gaming-Leistung dieser iGPUs interessiert niemanden.
Was zählt sind die Anzahl der unterstützen Monitore, deren maximale Auflösung, die in Hardware umgesetzten Videocodecs.
Davon abgesehen gebe ich Dir recht, dass die Annahme, dass die iGPU mit 1,1 GHz läuft, auf keinen soliden Füßen steht.
mkl1 schrieb:
Also wird AMD eine Taktfrequenz wählen, wo sie mindestens ein wenig drüber liegen.
Kernthemen für das Zen-4-IOD sind Infinity Fabric 3.0, DDR 5 und PCIe 5. Diese müssen zu 100 % performen damit Zen 4 funktioniert.
Die iGPU behebt nur ein fehlenden Häkchen in der Anforderungsliste der OEMs.
AMD wird die iGPU so auslegen, dass sie die Mindestanforderungen an eine iGPU erfüllt.
Falls darüber hinaus von Chipfläche und Power-Budget frei ist,
könnte AMD mehr machen.
Wichtig ist aber auch, ob AMD die iGPU komplett stilllegen kann, wenn sie nicht gebraucht wird.
