Navi 1X (7nm, RDNA1, 2019) & Navi 2X (7nm, RDNA2, 2020)

[gedi]

N80 doch mit HBM? https://coreteks.tech/articles/index.php/2020/10/01/radeon-6900xt-specs-leak-competes-with-rtx-3090/

[dargo]

Wo liest du da was von HBM? Perf/W größer 50% vs. RDNA 1 wäre schon mal geil. (y)

Edit:
Also ich lese dort HBM nicht ausgeschlossen, aber eher unwahrscheinlich.

btw.
2,2Ghz Boosttakt angeblich. Dann sage ich schon mal das Ding boostet bei hoher GPU-Last irgendwo bei ~2Ghz rum.

[gedi]

Wo liest du da was von HBM?

Ist nur seine Annahme. Aus dem Tweet eines Anderen ist ein 512-Bit SI ausgeschlossen (warum eigentlich) ...
Für mich macht das große SI am meisten Sinn, da ich hier relativ variabel verfahren kann und zudem die 505mm^2 gefüllt werden müssen.

[ianm]

N80 doch mit HBM? https://coreteks.tech/articles/index.php/2020/10/01/radeon-6900xt-specs-leak-competes-with-rtx-3090/
Der Typ ist einer dieser gruseligen YouTuber, die auch keine Ahnung haben. Momentan ziehen sich alle was aus dem Arsch um Content zu generieren. Da wird zu jedem Furz ein Video gemacht.

Selbst Moores Law, der noch die besten Infos haben dürfte, wird nur mit dem gefüttert, was AMD zulässt. Am 28. sind alle schlauer.

[gedi]

Da hast du wahrscheinlich recht

[dargo]

Momentan ziehen sich alle was aus dem Arsch um Content zu generieren. Da wird zu jedem Furz ein Video gemacht.

:biggrin:

Stimmt aber, das werden noch sehr anstrengende 4 Wochen. :tongue:

[Berniyh]

Ja, das klingt schon sehr fragwürdig.

Ich denke beim Speicher ist das einzige was man als gesichert ansehen kann, dass die kleineren Navi 21 Versionen auf jeden Fall GDDR6 Speicher haben.
Eine reine HBM2 Bestückung wie bei Vega 10 wird es bei Navi 21 nicht geben.
(Evtl. für eine einzelne Ausführung, aber nicht durch die Bank.)

Edit: da es Patches zu GDDR6 Memory Training bei Sienna Cichlid gab.
Ob das HBM2 (Teil-)Versionen ausschließt kann ich nicht sagen.

[Zergra]

Das Problem bei 512bit sind eben die 16 Chips die auf der Vorderseite im gleichen Abstand zum Chip positioniert werden müssen. (Die Chips auf der Rückseite gespiegelt zu verbauen ist dann unkritisch.)
Sonst gibt es eben einen starken Einfluss auf die Geschwindigkeit. Das wird AMD definitiv nicht verbauen, dann schon eher HBM.

[gedi]

Das Problem bei 512bit sind eben die 16 Chips die auf der Vorderseite im gleichen Abstand zum Chip positioniert werden müssen. (Die Chips auf der Rückseite gespiegelt zu verbauen ist dann unkritisch.)
Sonst gibt es eben einen starken Einfluss auf die Geschwindigkeit. Das wird AMD definitiv nicht verbauen, dann schon eher HBM.

Der Abstand ist doch durch die Front quasi gekennzeichnet. Und wenn man sich die Backplate anschaut, dann muss da etwas darunter sein, Wärmeleitpads z.B.

[unl34shed]

@Berniyh: Hast du einen Link zu dem Patch?

An den gleichen Chip sowohl mit HBM als auch GDDR will ich nicht wirklich glauben, das macht nur sinn, wenn man mit einer Mischbestückung plant um den Speicher feiner abstufen zu können. Aber ansonsten sind es nur zusätzliche Kosten ohne Mehrwert.

[Berniyh]

@Berniyh: Hast du einen Link zu dem Patch?
https://cgit.freedesktop.org/~agd5f/linux/commit?h=amd-staging-drm-next&id=8b41903a2b18c2a3fc829c2e042f0484cb51ad7e

atom_vram_module_v11 wurde hier hinzugefügt:
https://cgit.freedesktop.org/~agd5f/linux/commit/drivers/gpu/drm/amd/include/atomfirmware.h?h=amd-staging-drm-next&id=9d3708169f4494bdccc4f8b89a8f866767c563b7

Ich denke der Bezug zu GDDR6 ist klar, oder? ;)

Von HBM ist da nicht die Rede, allerdings muss das kein zwangsläufiges Aus für HBM bedeuten, da bei Navi 1x das auch nicht spezifisch erwähnt wird, aber Navi 12 ja definitiv HBM nutzt.

Nur HBM-only kann man eben ausschließen, sonst würde es wohl eher wie bei v9 (Vega) aussehen.

An den gleichen Chip sowohl mit HBM als auch GDDR will ich nicht wirklich glauben, das macht nur sinn, wenn man mit einer Mischbestückung plant um den Speicher feiner abstufen zu können. Aber ansonsten sind es nur zusätzliche Kosten ohne Mehrwert.
Seh ich prinzipiell ähnlich, allerdings gibt es auch dafür mehrere Anzeichen, unter anderem in dem hier schon häufiger verlinkten Reddit Post.
Dort sagt er, dass laut Firmware Navi 21 HBM und GDDR6 unterstützt, sagt aber selbst auch, dass er keine Ahnung hat was das wirklich bedeutet.
Wie wir eben alle auch. ;)

Edit: Bezug von Navy Flounder zu GDDR6:
https://cgit.freedesktop.org/~agd5f/linux/commit/drivers/gpu/drm/amd/amdgpu?h=amd-staging-drm-next&id=ac0b5ce6684089cacc3968ce8647a87df01e9d85

Aber ich denke an GDDR6 bei Navy Flounder hat eh niemand gezweifelt, insofern eher eine Randbemerkung.

[Iscaran]

atom_vram_module_v11 wurde hier hinzugefügt:
https://cgit.freedesktop.org/~agd5f/linux/commit/drivers/gpu/drm/amd/include/atomfirmware.h?h=amd-staging-drm-next&id=9d3708169f4494bdccc4f8b89a8f866767c563b7

Ich denke der Bezug zu GDDR6 ist klar, oder? ;)


Wieso wird die Funktion hier als "remap" bezeichnet ?

EDIT: Hier z.B.: struct atom_gddr6_bit_byte_remap {
oder hier: struct atom_gddr6_dram_data_remap {
/EDIT:

So etwas findet sich doch üblicherweise wenn man eine Art "Kompatibilität" herstellen will...

Also z.B. wenn HBM2 dann wie oben, sonst bei GDDR6 "remap" wie hier beschreiben ?

Nur so eine Gedanke.

[Complicated]

+struct atom_gddr6_bit_byte_remap { + uint32_t dphy_byteremap;
//mmUMC_DPHY_ByteRemap + uint32_t dphy_bitremap0;
//mmUMC_DPHY_BitRemap0 + uint32_t dphy_bitremap1;
//mmUMC_DPHY_BitRemap1 + uint32_t dphy_bitremap2;
//mmUMC_DPHY_BitRemap2 + uint32_t aphy_bitremap0;
//mmUMC_APHY_BitRemap0 + uint32_t aphy_bitremap1;
//mmUMC_APHY_BitRemap1 + uint32_t phy_dram;
//mmUMC_PHY_DRAM +};Ein paar Details...hmmmm

[dargo]

Hast du auch gleich den passenden Übersetzer dafür? :D

[cipoint]

Kann "UMC" Unified Memory Controller bedeuten? Also doch Technologie aus dem Chiplet-Design?

[gedi]

Kann "UMC" Unified Memory Controller bedeuten? Also doch Technologie aus dem Chiplet-Design?

Gehört jetzt zwar nicht unbedingt hierher, aber 5700+XT gehen EOL

Deutet für mich auf eine andere Art/Erweiterung des Vrams hin. Kann z.B. Mischbestückung, Megacache oder ganz einfach nen String, der auf ne kompatible SSD hindeutet, welche ähnlich der Konsolen, manche Dinge beschleunigt.

[Berniyh]

Wieso wird die Funktion hier als "remap" bezeichnet ?

EDIT: Hier z.B.: struct atom_gddr6_bit_byte_remap {
oder hier: struct atom_gddr6_dram_data_remap {
/EDIT:

So etwas findet sich doch üblicherweise wenn man eine Art "Kompatibilität" herstellen will...

Also z.B. wenn HBM2 dann wie oben, sonst bei GDDR6 "remap" wie hier beschreiben ?

Nur so eine Gedanke.

Also zunächst einmal:
In dieser Datei und in diesen Funktionen geht es – soweit mir bekannt – um das Auslesen des GPU BIOS.
d.h. hier werden dann die eigentlichen Eckdaten der Grafikkarte für den Treiber bestimmt.
Das bedeutet aber insbesondere auch, dass hier keine wirklichen Daten drin stehen, sondern es wird die Struktur der Daten aus dem BIOS beschrieben.
Ohne das BIOS selbst hat man demnach auch keinen Zugriff auf die eigentlichen Daten (und vieles bleibt daher Spekulation).
Über dieses BIOS wird dann z.B. auch wesentich bestimmt ob es sich um eine 5700 XT oder eine 5600 XT handelt, welche ja durchaus unterschiedliche Taktraten, Anzahl Speicherkanäle etc. haben.

Was nun diese remap Funktion genau macht kann ich auch nicht genau sagen, aber es ist in der Tat ein guter Einwand und möglicherweise ein Hinweis darauf, dass bei Sienna Cichlid (oder evtl. auch Navi 2x im Allgemeinen) tatsächlich irgendwas anders läuft als bei den bisherigen Chips.
Zunächst einmal gab es in den atom_vram_info_header_v2_x schon immer ein Feld, welches bisher nicht verwendet wurde, sowohl für Vega als auch Navi 1x:
struct atom_vram_info_header_v2_3 {
struct atom_common_table_header table_header;
uint16_t mem_adjust_tbloffset; // offset of atom_umc_init_reg_block structure for memory vendor specific UMC adjust setting
uint16_t mem_clk_patch_tbloffset; // offset of atom_umc_init_reg_block structure for memory clock specific UMC setting
uint16_t mc_adjust_pertile_tbloffset; // offset of atom_umc_init_reg_block structure for Per Byte Offset Preset Settings
uint16_t mc_phyinit_tbloffset; // offset of atom_umc_init_reg_block structure for MC phy init set
uint16_t dram_data_remap_tbloffset; // reserved for now
[...]
struct atom_vram_info_header_v2_4 {
struct atom_common_table_header table_header;
uint16_t mem_adjust_tbloffset; // offset of atom_umc_init_reg_block structure for memory vendor specific UMC adjust setting
uint16_t mem_clk_patch_tbloffset; // offset of atom_umc_init_reg_block structure for memory clock specific UMC setting
uint16_t mc_adjust_pertile_tbloffset; // offset of atom_umc_init_reg_block structure for Per Byte Offset Preset Settings
uint16_t mc_phyinit_tbloffset; // offset of atom_umc_init_reg_block structure for MC phy init set
uint16_t dram_data_remap_tbloffset; // reserved for now
[...]

Dieses Datenfeld wird nun mit Sienna Cichlid erstmals genutzt (so zumindest verstehe ich den Kommentar):
struct atom_vram_info_header_v2_5 {
»···struct atom_common_table_header table_header;
»···uint16_t mem_adjust_tbloffset; // offset of atom_umc_init_reg_block structure for memory vendor specific UMC adjust settings
»···uint16_t gddr6_ac_timing_offset; // offset of atom_gddr6_ac_timing_v2_5 structure for memory clock specific UMC settings
»···uint16_t mc_adjust_pertile_tbloffset; // offset of atom_umc_init_reg_block structure for Per Byte Offset Preset Settings
»···uint16_t mc_phyinit_tbloffset; // offset of atom_umc_init_reg_block structure for MC phy init set
»···uint16_t dram_data_remap_tbloffset; // offset of atom_gddr6_dram_data_remap array to indicate DRAM data lane to GPU mapping
[...]
Insbesondere der Kommentar ist hier interessant. Es scheint dabei also um die Zuordnung von Datenleitungen (also wahrscheinlich Speicherkanäle) zwischen Speicher und GPU zu gehen.
Bislang schien man das nicht gebraucht zu haben, aber jetzt evtl. schon? Evtl. weil das Speicherinterface von Sienna Cichlid flexiblere Konfigurationen ermöglicht?
Ist so natürlich nicht aufzulösen, aber interessant ist es allemal, dass man diesen Parameter neu eingeführt hat.
Dafür spricht auch das hier:
struct atom_gddr6_dram_data_remap {
»···uint32_t table_size;
»···uint8_t phyintf_ck_inverted[8]; //UMC_PHY_PHYINTF_CNTL.INV_CK
»···struct atom_gddr6_bit_byte_remap bit_byte_remap[16];
};
d.h. es geht wohl wirklich um die Zuordnung der PHYs.

Ob das nun was mit der ominösen HBM + GDDR6 Geschichte zu tun hat?
Möglich, aber ein Beweis ist das nicht. Könnte ja auch sein, dass man aus irgendeinem Grund sowas bei einem reinen GDDR6 Interface einführt.

[Berniyh]

Interessant ist übrigens auch das hier:
uint32_t usb_pwrlimit_mw; // power limit when USB is enable in unit of m-watt

Weil doch neulich die Frage war, ob ein Monitor über den USB-C Anschluss (den die Karten ja angeblich mitbringen) betrieben werden kann.
Gibt natürlich auch keine Antwort darauf, aber zumindest scheint es eine Stromversorgung per USB zu geben.
Wie hoch das Limit sein wird muss man abwarten.

[gedi]

Also zunächst einmal:
In dieser Datei und in diesen Funktionen geht es – soweit mir bekannt – um das Auslesen des GPU BIOS.
d.h. hier werden dann die eigentlichen Eckdaten der Grafikkarte für den Treiber bestimmt.
Das bedeutet aber insbesondere auch, dass hier keine wirklichen Daten drin stehen, sondern es wird die Struktur der Daten aus dem BIOS beschrieben.
Ohne das BIOS selbst hat man demnach auch keinen Zugriff auf die eigentlichen Daten (und vieles bleibt daher Spekulation).
Über dieses BIOS wird dann z.B. auch wesentich bestimmt ob es sich um eine 5700 XT oder eine 5600 XT handelt, welche ja durchaus unterschiedliche Taktraten, Anzahl Speicherkanäle etc. haben.

Was nun diese remap Funktion genau macht kann ich auch nicht genau sagen, aber es ist in der Tat ein guter Einwand und möglicherweise ein Hinweis darauf, dass bei Sienna Cichlid (oder evtl. auch Navi 2x im Allgemeinen) tatsächlich irgendwas anders läuft als bei den bisherigen Chips.
Zunächst einmal gab es in den atom_vram_info_header_v2_x schon immer ein Feld, welches bisher nicht verwendet wurde, sowohl für Vega als auch Navi 1x:
struct atom_vram_info_header_v2_3 {
struct atom_common_table_header table_header;
uint16_t mem_adjust_tbloffset; // offset of atom_umc_init_reg_block structure for memory vendor specific UMC adjust setting
uint16_t mem_clk_patch_tbloffset; // offset of atom_umc_init_reg_block structure for memory clock specific UMC setting
uint16_t mc_adjust_pertile_tbloffset; // offset of atom_umc_init_reg_block structure for Per Byte Offset Preset Settings
uint16_t mc_phyinit_tbloffset; // offset of atom_umc_init_reg_block structure for MC phy init set
uint16_t dram_data_remap_tbloffset; // reserved for now
[...]
struct atom_vram_info_header_v2_4 {
struct atom_common_table_header table_header;
uint16_t mem_adjust_tbloffset; // offset of atom_umc_init_reg_block structure for memory vendor specific UMC adjust setting
uint16_t mem_clk_patch_tbloffset; // offset of atom_umc_init_reg_block structure for memory clock specific UMC setting
uint16_t mc_adjust_pertile_tbloffset; // offset of atom_umc_init_reg_block structure for Per Byte Offset Preset Settings
uint16_t mc_phyinit_tbloffset; // offset of atom_umc_init_reg_block structure for MC phy init set
uint16_t dram_data_remap_tbloffset; // reserved for now
[...]

Dieses Datenfeld wird nun mit Sienna Cichlid erstmals genutzt (so zumindest verstehe ich den Kommentar):
struct atom_vram_info_header_v2_5 {
»···struct atom_common_table_header table_header;
»···uint16_t mem_adjust_tbloffset; // offset of atom_umc_init_reg_block structure for memory vendor specific UMC adjust settings
»···uint16_t gddr6_ac_timing_offset; // offset of atom_gddr6_ac_timing_v2_5 structure for memory clock specific UMC settings
»···uint16_t mc_adjust_pertile_tbloffset; // offset of atom_umc_init_reg_block structure for Per Byte Offset Preset Settings
»···uint16_t mc_phyinit_tbloffset; // offset of atom_umc_init_reg_block structure for MC phy init set
»···uint16_t dram_data_remap_tbloffset; // offset of atom_gddr6_dram_data_remap array to indicate DRAM data lane to GPU mapping
[...]
Insbesondere der Kommentar ist hier interessant. Es scheint dabei also um die Zuordnung von Datenleitungen (also wahrscheinlich Speicherkanäle) zwischen Speicher und GPU zu gehen.
Bislang schien man das nicht gebraucht zu haben, aber jetzt evtl. schon? Evtl. weil das Speicherinterface von Sienna Cichlid flexiblere Konfigurationen ermöglicht?
Ist so natürlich nicht aufzulösen, aber interessant ist es allemal, dass man diesen Parameter neu eingeführt hat.
Dafür spricht auch das hier:
struct atom_gddr6_dram_data_remap {
»···uint32_t table_size;
»···uint8_t phyintf_ck_inverted[8]; //UMC_PHY_PHYINTF_CNTL.INV_CK
»···struct atom_gddr6_bit_byte_remap bit_byte_remap[16];
};
d.h. es geht wohl wirklich um die Zuordnung der PHYs.

Ob das nun was mit der ominösen HBM + GDDR6 Geschichte zu tun hat?
Möglich, aber ein Beweis ist das nicht. Könnte ja auch sein, dass man aus irgendeinem Grund sowas bei einem reinen GDDR6 Interface einführt.

Wie sieht es mit dem ominösen HBM ohne Interposer aus?

[JVC]

Ich kenn mich da nicht so aus, aber...

Wäre es möglich ein DDR Speicherinterface und ein HBM-Interface
"ineinander zu schieben" ?
Was alles ist von einem zum anderen RAM "im Anschluss" kompatibel?

Oder ist da absolut nichts doppelt verwendbar oder ähnlich genug?
(und man müsste beide, getrennt und komplett ohne Ersparnis, einbauen)

M.f.G. JVC

[gedi]

Interessant ist übrigens auch das hier:
uint32_t usb_pwrlimit_mw; // power limit when USB is enable in unit of m-watt

Weil doch neulich die Frage war, ob ein Monitor über den USB-C Anschluss (den die Karten ja angeblich mitbringen) betrieben werden kann.
Gibt natürlich auch keine Antwort darauf, aber zumindest scheint es eine Stromversorgung per USB zu geben.
Wie hoch das Limit sein wird muss man abwarten.

Wenn er voll funktionell sein soll, dann up to 27w

[Berniyh]

Wie sieht es mit dem ominösen HBM ohne Interposer aus?
Das steht da nicht, also: keine Ahnung

Es ist auch gut möglich, dass sich – im Vergleich zu Navi 10 – nichts geändert hat.
Also ganz normales GDDR6 Speicherinterface wie bisher und alles bzgl. HBM einfach nur Träumerei.

Dass man diese remap Funktionalität hinzugefügt hat ist halt "interessant", mehr kann man dazu derzeit leider wirklich nicht sagen.
Kann alles oder nichts heißen.

[amdfanuwe]

Ich kenn mich da nicht so aus, aber...

Der wesentlichste Unterschied dürften die Leistungstransistoren für die Ansteuerung der Pins sein.
GDDR hat längere Leitungen und braucht mehr Power um die Daten auszutauschen.
HBM ist stromsparender ausgelegt und kommt mit kleineren Pins (Balls) aus.
Daher braucht das GDDR Interface so eine große Fläche bzw. ist ein HBM Interface mit >1000 Datenleitungen dagegen relativ klein.
Die Ansteuerlogik sollte von der Fläche da nicht das Problem sein.

Man kann es auch so sagen:
Ein Transistor kann nur einen bestimmten Strom bereitstellen. Braucht man mehr Strom auf der Leitung, schaltet man mehrere Transistoren Parallel.
Doppelter Stromverbrauch -> doppelte Transistoranzahl -> doppelte Fläche.
Längere Leitung -> mehr Strombedarf.
Mehr Strombedarf -> größere Kontakte (Pins, Balls)

Da kommt auch der Spareffekt bei HBM her:
Kurze Leitung, geringe Kontaktfläche -> weniger Strombedarf für Datenaustausch -> kleineres Interface.

[Berniyh]

Das mit den AMD Codenamen wird echt albern langsam. Der nächste ist … "Green Sardine"
https://lists.freedesktop.org/archives/amd-gfx/2020-October/054441.html

Angeblich Lucienne.
https://lists.freedesktop.org/archives/amd-gfx/2020-October/054442.html

case CHIP_RENOIR:
- chip_name = "renoir";
+ if (adev->apu_flags & AMD_APU_IS_RENOIR)
+ chip_name = "renoir";
+ else
+ chip_name = "green_sardine";

https://lists.freedesktop.org/archives/amd-gfx/2020-October/054443.html
- adev->apu_flags |= AMD_APU_IS_RENOIR;
+ if (adev->pdev->device == 0x1636)
+ adev->apu_flags |= AMD_APU_IS_RENOIR;
+ else
+ adev->apu_flags |= AMD_APU_IS_GREEN_SARDINE;
+
+ if (adev->apu_flags & AMD_APU_IS_RENOIR)
+ adev->external_rev_id = adev->rev_id + 0x91;
+ else
+ adev->external_rev_id = adev->rev_id + 0xa1;

Da Lucienne wohl ein Refresh von Renoir ist dürfte das wahrscheinlich sein.
Hätte man nicht wenigstens bei den APUs bei den richtigen Codenamen bleiben können?

[JVC]

@amdfanuwe
Also stünde einem "GDDR Interface" welches auch HBM kann nicht wirklich was im Wege?
(außer das es etwas größer wird und das natürlich nicht gleichzeitig kann)

Wäre halt ein Vorteil für AMD flexibler sein zu können.
(und ich finde HBM einfach geil ;))

Der "Infinity-Cash" kann ja trotzdem für eine Bandbreiteneinsparung da sein.

M.f.G. JVC

[Berniyh]

@amdfanuwe
Also stünde einem "GDDR Interface" welches auch HBM kann nicht wirklich was im Wege?
Also ganz so simpel wird es am Ende nicht sein, denn sonst hätte Nvidia das sicherlich umgesetzt.
Kann mir doch keiner erzählen, dass die auch bei einer 3090 unbedingt auf GDDR6 setzen wollen, wenn ohne viel Aufwand möglich wäre da ein Kombi-Interface unterzubringen. ;)

[gedi]

Das mit den AMD Codenamen wird echt albern langsam. Der nächste ist … "Green Sardine"
https://lists.freedesktop.org/archives/amd-gfx/2020-October/054441.html

Angeblich Lucienne.

Ich glaube die nehmen uns alle hoch. Zuerst das Bild von der Testplatine, dann diverse Einträge in Linux ... Ich denke, wir wissen noch überhaupt nichts von N2x, außer dem einen Bild, was auf ne kompetente GPU schließen lässt. Mehr wissen wir leider nicht.

[dargo]

Also ganz so simpel wird es am Ende nicht sein, denn sonst hätte Nvidia das sicherlich umgesetzt.
Kann mir doch keiner erzählen, dass die auch bei einer 3090 unbedingt auf GDDR6 setzen wollen, wenn ohne viel Aufwand möglich wäre da ein Kombi-Interface unterzubringen. ;)
Möglich, dass irgendwelches Patent im Wege steht?

[gedi]

Möglich, dass irgendwelches Patent im Wege steht?

Der nächste Eintrag ist dann wahrscheinlich Silberfisch. Patent eher weniger, da NV kommuniziert hat, dass HBM für den Consumer-Markt nicht profitabel (genug) ist.

[Berniyh]

Ich glaube die nehmen uns alle hoch. Zuerst das Bild von der Testplatine, dann diverse Einträge in Linux ... Ich denke, wir wissen noch überhaupt nichts von N2x, außer dem einen Bild, was auf ne kompetente GPU schließen lässt. Mehr wissen wir leider nicht.
Doch, eins wissen wir nun mit absoluter Sicherheit, und zwar, dass Sienna Cichlid = Navi 21.
Hat sich wohl einer bei AMD verschrieben … :D
Erst das hier geschickt:
https://lists.freedesktop.org/archives/amd-gfx/2020-September/053491.html

Und 40min später das hier:
https://lists.freedesktop.org/archives/amd-gfx/2020-September/053492.html

[WedgeAntilles]

Möglich, dass irgendwelches Patent im Wege steht?

Wenn etwas sehr simpel ist, ist es meist schwierig das patentrechtlich zu schützen.
Bzw. gibt es dann häufig ja auch Möglichkeiten das Problem etwas anders zu lösen und so ein eventuel doch vorhandes Patent zu umgehen.

Spontan denke ich daher nicht, dass ein Patent der Grund ist, lasse mich aber natürlich gerne belehren :)

[JVC]

Also ganz so simpel wird es am Ende nicht sein, denn sonst hätte Nvidia das sicherlich umgesetzt.
Kann mir doch keiner erzählen, dass die auch bei einer 3090 unbedingt auf GDDR6 setzen wollen, wenn ohne viel Aufwand möglich wäre da ein Kombi-Interface unterzubringen. ;)
Gutes Argument :)

Möglich, dass irgendwelches Patent im Wege steht?
Könnte ich mir auch vorstellen.

Ich halte den GDDR6X RAM aber für ziemlich misslungen. Zu heiß, zu teuer, zu durstig.
Was ist eigentlich mit dem Nachfolger GDDR7, wann kommt der? (find dazu nix)

M.f.G. JVC

[y33H@]

GDDR6X ist effizienter als GDDR6.

[Complicated]

Effizienter wobei genau? Wie bewertest du das?

[dargo]

Doch, eins wissen wir nun mit absoluter Sicherheit, und zwar, dass Sienna Cichlid = Navi 21.
Hat sich wohl einer bei AMD verschrieben … :D
Erst das hier geschickt:
https://lists.freedesktop.org/archives/amd-gfx/2020-September/053491.html

Und 40min später das hier:
https://lists.freedesktop.org/archives/amd-gfx/2020-September/053492.html
Scroll mal im ersten Link nach ganz unten, das steht auch schon "CHIP_SIENNA_CICHLID". ;)


Ich halte den GDDR6X RAM aber für ziemlich misslungen. Zu heiß, zu teuer, zu durstig.
Was ist eigentlich mit dem Nachfolger GDDR7, wann kommt der? (find dazu nix)

Ich frage mich eher ob GDDR überhaupt noch eine Zukunft hat? Vielleicht noch GDDR7, aber danach?

[gedi]

GDDR6X ist effizienter als GDDR6.

Japp, vor allem in der Jahreszeit.

Mal ne ganz dumme Frage: Warum benennt AMD nur Süßwasserfische? Macht doch anhand des Standorts 0.0 Sinn. Warum nicht Kofferfisch, Wal, Hai ...

[Berniyh]

Wenn er voll funktionell sein soll, dann up to 27w
Wieso 27W? USB Powerdelivery spezifiziert bis zu 100W.
100W wird die Karte aber wohl nicht liefern, denn das wären 20V bei 5A.
Da wäre dann also noch eine aufwändigere Spannungswandlung auf dem Board nötig, da weder die 8 Pin Anschlüsse noch der Slot 20V bereitstellen.
12V hingegen wären problemlos machbar (gibt's sowohl über den Slot als auch über die Anschlüsse), das wären dann 60W (die nächste Stufe darunter).
Und es gibt hier zumindest einen Monitor der mehr als 27W frisst:
https://geizhals.de/asus-proart-pq22uc-90lm047e-b01370-a1970091.html

Ob das Limit dann auch bei 60W liegt oder weniger (geht ja alles von dem ab was die Grafikkarte maximale selbst verbrauchen darf) ist natürlich wieder eine andere Frage.

[Berniyh]

Japp, vor allem in der Jahreszeit.

Mal ne ganz dumme Frage: Warum benennt AMD nur Süßwasserfische? Macht doch anhand des Standorts 0.0 Sinn. Warum nicht Kofferfisch, Wal, Hai ...
Eine Sardine ist doch kein Süßwasserfisch?

Edit: ein Wal ist übrigens auch kein Fisch. :P

[y33H@]

Effizienter wobei genau? Wie bewertest du das?Picojoule pro Bit bei 21 Gbps vs 14 Gbps, hier 15% sparsamer bei signifikant mehr Bandbreite - laut Micron.

[gedi]

Kuck dir die Specs seitens des Ports nochmals an.

@Bernieh

Sardinen gibt es auch im Gardasee und der Wal ist, wie jeder wissen sollte, kein Fisch! Lebt trotzdem im Salzwasser. Okay, dann nehme ich ebend den Anemonenfisch (Nemo und so), den Doktorfisch. Ich habe selbst nen Meerwasseraquarium gehabt, von daher, lass es

[decimad2]

Man kann es auch so sagen:
Ein Transistor kann nur einen bestimmten Strom bereitstellen. Braucht man mehr Strom auf der Leitung, schaltet man mehrere Transistoren Parallel.
Doppelter Stromverbrauch -> doppelte Transistoranzahl -> doppelte Fläche.
Längere Leitung -> mehr Strombedarf.
Mehr Strombedarf -> größere Kontakte (Pins, Balls)

Da kommt auch der Spareffekt bei HBM her:
Kurze Leitung, geringe Kontaktfläche -> weniger Strombedarf für Datenaustausch -> kleineres Interface.

Unter der Voraussetzung, die Logik des MCs geht heutzutage gegen die Fläche der DRAM-PHYs unter, wäre es nicht denkbar gewissermaßen z.B. mit 4 Transistoren parallelgeschaltet eine DRAM-Leitung mit hohem Takt und "großer Länge" zu treiben bzw. eben einzeln 4 HBM-Leitungen? Nur so dahergesponnen, ich weiß ja nicht, wie die Verhältnisse da so sind.

[dargo]

Picojoule pro Bit bei 21 Gbps vs 14 Gbps, hier 15% sparsamer bei signifikant mehr Bandbreite - laut Micron.
Beim Chip alleine nehme ich an? Den Speichercontroller sollte man dabei aber nicht aus den Augen lassen. Das wäre so als wenn man auf einem Auge blind wäre. Der dürfte das dank höheren Frequenzen wieder locker auffressen.

[Complicated]

Ja nur ist hier das SI nicht mit betrachtet - gilt das auch für die benötigten PHYs?

Edit: zu langsam :)

Edit2:
This is further backed up by Micron's second brief, which offers a power comparison that's normalized to GDDR6. There, Micron states that 21Gbps GDDR6X requires 15% less power per transferred bit than GDDR6 at 14Gbps. But as with Micron's first brief, this is efficiency per byte/bit, not total power consumption. So either way, it's clear that the total power consumption of GDDR6X is going to be higher than today's 14Gbps GDDR6, with Micron projecting 25-27% more power required for 21Gbps GDDR6X memory.
https://www.anandtech.com/show/15978/micron-spills-on-gddr6x-pam4-signaling-for-higher-rates-coming-to-nvidias-rtx-3090

Effizienter ja - nur steigt der Verbrauch trotzdem deutlich.

[gedi]

Ich sag doch, in der Jahreszeit...

[Complicated]

lol

[gedi]

Ne 3080 mit 20G braucht vermutlich annähernd das Gleiche wie ne 3090. Echt kurios und spannender finde ich dann y33hs Aussage, dass der Krempel effizient ablaufen soll.

Obwohl, ne 3080 und ne 3090 trennt ja praktisch nix. Von daher....

[RitterRost]

Wer hatte sich hier die Sardine gewünscht?

https://www.phoronix.com/scan.php?page=news_item&px=AMD-Green-Sardine

Anscheinend eine APU - vermutlich Cezanne.

Edit: Upps, mit VEGA Grafik. Darf hier also nicht in den Thread :-)

[BlacKi]

Ne 3080 mit 20G braucht vermutlich annähernd das Gleiche wie ne 3090.
sry, aber warum? denk nach und spar dir die antwort...

[gedi]

Okay, du willst nicht antworten: Aufgrund Bernieh Ausführungen, kann doch ein MCM-Design möglich sein mit je 80CUs/Chip möglich sein. Der stinknormale Interposer inbegriffen und Performance weitab von 3090 bei identischer Leistungssufnahme . Sprich ein Halo-Produkt. Wolltest du das hören?

Natürlich kompletter Blödsinn, aber wenn man keine Antwort bekommt....

[bbott]

Ist zum Thema AI Upscaling bei Videos schon bei bei NAVI 2x Durchgesickert? Ich habe bisher dazu nichts gelesen.

[amdfanuwe]

Unter der Voraussetzung, die Logik des MCs geht heutzutage gegen die Fläche der DRAM-PHYs unter, wäre es nicht denkbar gewissermaßen z.B. mit 4 Transistoren parallelgeschaltet eine DRAM-Leitung mit hohem Takt und "großer Länge" zu treiben bzw. eben einzeln 4 HBM-Leitungen? Nur so dahergesponnen, ich weiß ja nicht, wie die Verhältnisse da so sind.
Mein Studium liegt auch schon 20 Jahre zurück, aber ich denke, das lohnt nicht, wenn es überhaupt machbar wäre. Brauchst ja zusätzliche Transistoren zum umschalten.

[gedi]

Ist zum Thema AI Upscaling bei Videos schon bei bei NAVI 2x Durchgesickert? Ich habe bisher dazu nichts gelesen.

Primär gibt es den Upscaler bereits im Treiber per Turbo. Den ssaa Anteil kannst du dir in nachfolgenden Reviews anschauen, maybe

[gedi]

Mein Studium liegt auch schon 20 Jahre zurück, aber ich denke, das lohnt nicht, wenn es überhaupt machbar wäre. Brauchst ja zusätzliche Transistoren zum umschalten.

Meines auch, zumal bei uns die Hardware nicht Kompliment war.

[davidzo]

Ne 3080 mit 20G braucht vermutlich annähernd das Gleiche wie ne 3090. Echt kurios und spannender finde ich dann y33hs Aussage, dass der Krempel effizient ablaufen soll.

Obwohl, ne 3080 und ne 3090 trennt ja praktisch nix. Von daher....
Ja, 3080 und 3090 liegen echt nah beieinander, auch beim verbrauch, da macht die auswahl des jeweiigen partnerdesigns beinahe genau soviel aus.
Aber wie kommst du darauf dass die 20gb 3080 signifikant mehr verbraucht als die 10gb? Physikalisch gesehen ändert sich vielleicht der Idle bzw. Teillastbetrieb geringfügig, unter Last sollte es jedoch keine Änderungen geben, da sich die Interfacebreite und damit Bandbreite bzw. übertragene Bits nicht ändern mit einfach nur mehr Speicherchips.

Gutes Argument :)


Könnte ich mir auch vorstellen.

Ich halte den GDDR6X RAM aber für ziemlich misslungen. Zu heiß, zu teuer, zu durstig.
Was ist eigentlich mit dem Nachfolger GDDR7, wann kommt der? (find dazu nix)

M.f.G. JVC
Es ist nicht der GDDR bei Ampere der viel zieht. Es ist der PHY im Chip selbst der soviel zieht. Was meinst du denn wieso nvidia einfach mal so eben eine eigene Voltage Domäne für den Speichercontroller eingeführt hat die es bei Turing, Volta und Pascal nicht gegeben hat?
Da ist was gehörig schief gelaufen, der ausgewählte PHY brachte auf Samsungs 8nm nicht die nötigen Taktraten und deshalb musste man da eben mit der Brechstange ran. Eigentlich war Micron ja schon vor monaten herausgerutscht dass man 21gbps Ram für nvidia liefern wollte, aber vermutlich schafft das der Ampere PHY gar nicht, wäre also verlorene Müh.

Effizienter wobei genau? Wie bewertest du das?
Effizienz ist doch ganz einfach, erziehlte Bandbeite pro eingesetztem Watt. Und dabei ist GDDR6x tatsächlich besser als normaler GDDR6.
Wenn du ein SI von 256bit auf 512 skalierst, ist der Stromverbrauch pro übertragenem bit ersteinmal derselbe, weil derselbe Speicher. Das bisschen Energie für Pagerefresh bei mehr Speicherchips fällt nur im Idle ins Gewicht, nicht unter Spielelast. Wenn du aber auch doppelt soviele Daten überträgst also die doppelte Speicherbandbreite auslastest, skaliert der Energieverbrauch direkt linear mit.
Ein breiteres Interface skaliert also linear mit dem Energieverbrauch. Wenn du stattdessen Speicherchips einsetzt die weniger Joule pro übertragenem Bit benötigen, dann ist das Effizienter, unabhängig davon wie breit das SI oder ob es ein Hochtaktdesign oder nicht ist.

[gedi]

Es wäre mir neu ein 256-Bit Si auf die doppelte Bandbreite skalieren zu lassen.

Okay, ich habe den mcache, Allerdings funkt der nur temporär

[BlacKi]

Ja, 3080 und 3090 liegen echt nah beieinander, auch beim verbrauch, da macht die auswahl des jeweiigen partnerdesigns beinahe genau soviel aus.
Aber wie kommst du darauf dass die 20gb 3080 signifikant mehr verbraucht als die 10gb? Physikalisch gesehen ändert sich vielleicht der Idle bzw. Teillastbetrieb geringfügig, unter Last sollte es jedoch keine Änderungen geben, da sich die Interfacebreite und damit Bandbreite bzw. übertragene Bits nicht ändern mit einfach nur mehr Speicherchips.
die 10/20gb version teilen sich dasselbe PT. die 20gb version wird nur etwas langsamer... der verbrauch ist identisch.

[gedi]

die 10/20gb version teilen sich dasselbe PT. die 20gb version wird nur etwas langsamer... der verbrauch ist identisch.

Sprich ich muss mir die 20GB-Version antun, um annähernd im Sweetspot zu landen :freak:

Wie dargo bereits angemerkt hat, werden es ziemlich harte 4 Wochen. Ich glaube das war der sinnvollste Post hier in diesem Thread, da wir alle so gar nix wissen!

[BlacKi]

Sprich ich muss mir die 20GB-Version antun, um annähernd im Sweetspot zu landen :freak:
edit: mein gesabbel bezog sich auf die doppelte/beidseitige speicherbelegung. das wird die 20gb version nicht haben. aber dennoch wird die 20gb version etwas langsamer.

[gedi]

oder du tust dir die 10gb version an und senkst den verbrauch auf ein geünschtes maß.

naja, oder du wartest einfach mal ab.

ich frag mich wie man auf die idee kommt dass das PT bei der 20gb version anders sein sollte. troy hat schon erwähnt, das die hohen PT wegen des doppelten speichers so hoch angelegt wurden.

auf einen test wieviel 10gb mehr verbraucht (und damit vom PT stiehlt) müssen wir wohl noch etwas warten.

Sorry, aber das ist ne Milchmädchenrechnung, da Ampere für sich durchaus effizient erscheint, der Krempel rund um die ASIC allerdings so gar nicht

[Complicated]

Effizienz ist doch ganz einfach, erziehlte Bandbeite pro eingesetztem Watt. Ist es das?
Nur die GPU gerechnet+Speicher? Nur den Speicher (Wie Micron das macht +15%)? Das Gesamtprodukt mit PCB? Ohne Kontext ist es halt auch ohne Inhalt und Aussage. Daher meine Nachfrage. Du hast die PHYs ja beschrieben die diese Rechnung schon anders aussehen lassen.

Es gibt auch andere Effizienz-Merkmale wie Flächenverbrauch oder wirtschaftlich effizient. Frag mal wo HBM bleibt... ;)

[gedi]

Ist es das?
Nur die GPU gerechnet+Speicher? Nur den Speicher (Wie Micron das macht +15%)? Das Gesamtprodukt mit PCB? Ohne Kontext ist es halt auch ohne Inhalt und Aussage. Daher meine Nachfrage. Du hast die PHYs ja beschrieben die diese Rechnung schon anders aussehen lassen.

Es gibt auch andere Effizienz-Merkmale wie Flächenverbrauch oder wirtschaftlich effizient. Frag mal wo HBM bleibt... ;)

Die Vorlage seitens NV war trotzdem enorm. The Game has changed. Zumal es dieses Mal keinen Treiber geben wird, der alles richtet.

[dargo]

die 10/20gb version teilen sich dasselbe PT. die 20gb version wird nur etwas langsamer... der verbrauch ist identisch.
:confused:

Erstens gibt es keine 20GB Version und zweitens ist es fraglich ob eine mögliche 20GB Version überhaupt von einem GA102 kommen wird. ;)

[decimad2]

Mein Studium liegt auch schon 20 Jahre zurück, aber ich denke, das lohnt nicht, wenn es überhaupt machbar wäre. Brauchst ja zusätzliche Transistoren zum umschalten.

Das Umschalten des Leistungsteils dachte ich, würde man halt einfach über die äußere Verdahtung regeln, man muss das ja nicht dynamisch machen. Der Gedanke wäre, günstige Salvages mit ebenso "günstigem" DRAM auszurüsten und die Freiheit zu haben soundsoviele MCs auf HBM zu verdrahten um die Leistung auf den Golden Samples in die zusätzlichen Einheiten zu verbraten, einen Mischbetrieb aus dem gleichen Silizium zu bauen, oder so ähnlich für den Halo-Wums ;)

[davidzo]

Ist es das?
Nur die GPU gerechnet+Speicher? Nur den Speicher (Wie Micron das macht +15%)? Das Gesamtprodukt mit PCB? Ohne Kontext ist es halt auch ohne Inhalt und Aussage. Daher meine Nachfrage. Du hast die PHYs ja beschrieben die diese Rechnung schon anders aussehen lassen.

Es gibt auch andere Effizienz-Merkmale wie Flächenverbrauch oder wirtschaftlich effizient. Frag mal wo HBM bleibt... ;)

Den Kontext hattest du gegeben, das war die aussage von micron, schon vergessen?

Bezog sich natürlich nur auf den DRAM selbst. Dass NV jetzt beim Controller oder bei der Umsetzung dessen durch die foundry ins Klo gegriffen hat ändert ja nichts an den technischen Daten des Rams von Micron.

[davidzo]

die 10/20gb version teilen sich dasselbe PT. die 20gb version wird nur etwas langsamer... der verbrauch ist identisch.

wie kommst du darauf dass die 20gb version langsamer wird, kannst du mir das mal vorrechnen?

Die 3080 hat 760 GB/s. Wenn diese voll ausgelastet werden, werden pro sekunde also 6,8e+12 bytes übertragen. Das kostet laut Micron 7.25pj/bit, also bei 760gb 49.3 Watt wenn ich mich nicht verrechnet habe*. Und das ist völlig unabhängig davon ob ich das mit 10 Modulen oder mit 20 mache, die relevante Kenngröße für den Lastverbrauch sind die übertragenen Bits.
Der Idle- bzw. Teillastverbrauch wird durch den Pagerefresh bei mehr speicherchips auch größer sein, aber das fällt bei Vollast eben nicht wirklich ins Gewicht, da geht es um aktiv übertragene bits und die Hängen nun mal an der Breite und Takt des Interfaces, nicht an der Menge der Speicherchips.

Erst bei 128gb-512gb LRdimms in servern etc. wird der idle und teillastverbrauch von mehr DRAM interessant, bei GDDR ist er beinahe vernachlässigbar.


*Immerhin interessant das Micron nun offiziell nur noch von 7.25pj/byte spricht gegenüber 7.5 bei normalem GDDR6. Das sind nicht mehr die versprochenen 15%, das müssten ja 6.5pj/byte sein. 7.25, das ist schon beinahe Messungenauigkeit und locker der unterschied der z.B. zwischen samsungs oder microns Speicherfertigung schon existieren kann.
https://www.micron.com/products/ultra-bandwidth-solutions/gddr6x?utm_source=youtube&utm_medium=video2&utm_campaign=gddr6x_phase1

[BlacKi]

Erst bei 128gb-512gb LRdimms in servern etc. wird der idle und teillastverbrauch von mehr DRAM interessant, bei GDDR ist er beinahe vernachlässigbar.

ich hab nicht weiter ausgeführt wieviel langsamer. theoretisch stimmt es aber und wieviel das sein wird werden wir erst mit der 20gb version sehen. zwischen der rx 5500 xt mit 4 und 8gb sinds ja angeblich auch 2-3 watt. obwohl die anzahl der module gleich ist.

aber ich weiß nicht warum wir hier darüber noch reden, denn das ist total ot.

[Complicated]

Den Kontext hattest du gegeben, das war die aussage von micron, schon vergessen?
Ich habe meinen Kontext nicht vergessen. Ich frage nach in welchem Kontext ein andere Poster einen Einzeiler rein wirft ;)
Ich verstehe auch nicht was dich daran stört, wenn ich in einem Forum verstehen will was der andere genau meint und was du mir jetzt langatmig erklären willst.

[Neurosphere]

Fe1xycgVVyM

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

Wenn das stimmt sieht es nicht nach HBM aus, wobei er sagt es wäre nicht die XTX Variante sonder XT/XL.

Laut seinen Aussagen sind das ca. 536mm²...

[BUG]

Wenn ich das richtig verstanden habe, dann hat er ja auch nur den BigNavi DIE auf den RX5700 Chip übertragen.

Edit: habe mir aber nur die ersten zwei Minuten angesehen.

Gruß
BUG

[Der_Korken]

536mm² wären ein Monster-Chip, von der Transistorzahl fast an GA102 dran, wenn die Packdichte verbessert wurde. Das klingt nicht plausibel, angesichts dessen, dass nur 80CUs und 256bit SI drin sind. Ein N10 mit diesen Specs käme irgendwo bei 380mm² raus* und da müssten dann nochmal 40% (!) zusätzlich für einen Infinity Cache (oder was auch immer) draufgehen. Nein, auf so eine riesige Fläche hätte AMD mehr CUs untergebracht oder einfach 384bit und sich 150mm² Chipfläche gespart. Irgendwelche riesigen "Super-CUs" kann man auch ausschließen, da wir bereits den Xbox-Chip mit RDNA2-CUs gesehen haben.

* CP+Frontend+CUs verdoppelt -> +130mm². Vergrößerung der CUs nicht eingerechnet, aber die dürfte man durch Verbesserung der Packdichte mehr als ausgleichen. Schließlich hat GA102 im ach so unterlegenen 8nm-Prozess schon 12,5% mehr Packdichte als N10 (45M vs 40M/mm²). Sehe keinen Grund warum N2x da nicht >50M/mm² schaffen sollte, wo Renoir und A100 >60M schaffen).

[Linmoum]

Da ist natürlich irgendwo Coreteks sein Co-Prozessor versteckt. Er hat nur Ampere und RDNA2 verwechselt.

[Ravenhearth]

Was er zur Fury X sagt, ist auch kompletter Unsinn. Er meint Big Navi wäre AMDs größte GPU jemals, weil in Fijis Die-Size noch der HBM mit drin wäre :freak:

[[MK2]Mythos]

Aber wenn das tatsächlich ein Navi21 Dieshot ist, dann spricht doch vieles bei der Größe dafür, dass das mit dem mega Cache wirklich stimmt. Halte ich durch die Leaklage sowieso am plausibelsten.

[Complicated]

Da ist doch ein Heatspreader und/oder WLP drauf zu sehen - daher keine Bestätigung für fehlendes HBM.
Laut seinen Aussagen sind das ca. 536mm²...
Packagegröße inkl HMB? Also anhahnd des Bildes kann man es IMHO noch nicht ausschließen.

So sah Fiji auch aus:
https://cdn.wccftech.com/wp-content/uploads/2015/03/Intel-Knights-Landing-Processor_Die_2.jpg

[BoMbY]

Das Bild was er da gebastelt hat ist leider ziemlich wertlos.

Es gibt keinerlei Möglichkeit irgendwas davon zu verifizieren was er erzählt. Angeblich hat er ein Bild der ganzen Karte, sagt aber nicht was für Speicher darauf ist, und alles was er macht ist ein Bild welches die angebliche Größte des Chips zeigt, und damit ein 11 Minuten Video.

[Mangel76]

Ist tatsächlich fragwürdig. Aber nur mal angenommen, es wäre echt. 536mm^2 wären echt fett und es müssten mehr als 80 CUs sein. Aber ich meine da rechts und links 2 helle Punkte an den Rändern auf gleicher Höhe zu erkennen. Könnte das eine HBM-Fuge sein? Der Rest ist natürlich durch die Paste verdeckt. Könnte das größentechnisch hinkommen?

[Berniyh]

536mm² wären ein Monster-Chip, von der Transistorzahl fast an GA102 dran, wenn die Packdichte verbessert wurde. Das klingt nicht plausibel, angesichts dessen, dass nur 80CUs und 256bit SI drin sind. Ein N10 mit diesen Specs käme irgendwo bei 380mm² raus* und da müssten dann nochmal 40% (!) zusätzlich für einen Infinity Cache (oder was auch immer) draufgehen. Nein, auf so eine riesige Fläche hätte AMD mehr CUs untergebracht oder einfach 384bit und sich 150mm² Chipfläche gespart. Irgendwelche riesigen "Super-CUs" kann man auch ausschließen, da wir bereits den Xbox-Chip mit RDNA2-CUs gesehen haben.
Also bei 150 mm2 bekommt man ja schon nen kompletten HBM2 Stack unter, in 7nm TSMC gefertigt vermutlich sogar noch mehr.

Edit: bei Navi 12 ist ein Stack etwa 92 mm2. d.h. in 150 mm2 wären schon 1.5 Stacks HBM2 flächenmäßig drin …

Kann mir einfach keiner erzählen, dass man dann so einen monströsen Chip baut statt lieber gleich auf HBM2 zu setzen.
Selbst mit einem 512 Bit GDDR6 Interface kann man die Fläche kaum erklären.

[dargo]

Ganze 536mm²? Da lag aber Nvidia mit ihren 427mm² weit daneben. :freak:

Mythos;12448322']Aber wenn das tatsächlich ein Navi21 Dieshot ist, dann spricht doch vieles bei der Größe dafür, dass das mit dem mega Cache wirklich stimmt. Halte ich durch die Leaklage sowieso am plausibelsten.
Entweder das oder N21 wird doch ein 512Bit SI bekommen. Jedenfalls würde die Form vom Die (lang/schmal) gut dazu passen. Hawaii/Grenada hatten auch so eine Form. Tonga/Tahiti mit ihren 384Bit SI waren schon näher am Quadrat dran als an diesem Rechteck welches angeblich N21 sein soll. Aktuell tendiere ich zum 256Bit SI + diesen "Wunder Cache" wenn ich bedenke wohin AMD mit RDNA 3 hin möchte. Lässt sich eigentlich Cache sehr gut shrinken?

Da ist doch ein Heatspreader und WLP drauf zu sehen - daher keine Bestätigung für fehlendes HBM.

Bei der Die-Form eigentlich schon. Vega 10 ist inkl. HBM quadratisch.
https://tpucdn.com/gpu-specs/images/g/800-default.jpg

Vega 20 auch.
https://images.anandtech.com/doci/13923/vega%2020%20gpu%20sensors.png

AMD könnte theoretisch oben zwei HBM-Stacks plazieren was die längliche Form dann erklärt. Meiner groben Einschätzung nach wäre der Platz oben aber für zwei HBM Stacks zu klein. Was passen würde wäre 1 HBM Stack womit wir wieder bei der Mischbestückung mit GDDR6 wären. :D


Packagegröße inkl HMB? Also anhahnd des Bildes kann man es IMHO noch nicht ausschließen.

Ja lol... gar nicht dran gedacht. ;D Wenn unter dem HS sich HBM versteckt liegt der Typ mit seinen 536mm² wiederum komplett daneben. :ulol:

[dargo]

dp

[Neurosphere]

Tja, kein Plan.

Laut Coreteks soll es sich ja um XT/XL handeln, laut Avery werden evtl. die XTX aber hauptsächlich Profi Derivate HBM bekommen.

Würde heißen das der Chip kein HBM hat.

Keine Ahnung was man daraus macht. 536mm² sind jedenfalls ziemlich groß.

[Complicated]

Es steht ja noch immer dass Gerücht im Raum, dass AMD auch den Speicher an die OEMs mit liefert und nicht nur den ASIC, wie das bei GDDR üblich ist bisher. Also wäre ein onPackage Speicher vorgegeben in dem Fall, wie auch immer der aussieht.

Edit: Vielleicht auch ein Indikator, warum so wenige Informationen verfügbar sind. Das Assembling für die OEMs bei HBM benötigt weniger Zeit, da das PCB deutlich simpler sein darf ohne die Speicherbestückung mit GDDR.

[Piefkee]

536mm² wären ein Monster-Chip, von der Transistorzahl fast an GA102 dran, wenn die Packdichte verbessert wurde. Das klingt nicht plausibel, angesichts dessen, dass nur 80CUs und 256bit SI drin sind. Ein N10 mit diesen Specs käme irgendwo bei 380mm² raus* und da müssten dann nochmal 40% (!) zusätzlich für einen Infinity Cache (oder was auch immer) draufgehen. Nein, auf so eine riesige Fläche hätte AMD mehr CUs untergebracht oder einfach 384bit und sich 150mm² Chipfläche gespart. Irgendwelche riesigen "Super-CUs" kann man auch ausschließen, da wir bereits den Xbox-Chip mit RDNA2-CUs gesehen haben.

* CP+Frontend+CUs verdoppelt -> +130mm². Vergrößerung der CUs nicht eingerechnet, aber die dürfte man durch Verbesserung der Packdichte mehr als ausgleichen. Schließlich hat GA102 im ach so unterlegenen 8nm-Prozess schon 12,5% mehr Packdichte als N10 (45M vs 40M/mm²). Sehe keinen Grund warum N2x da nicht >50M/mm² schaffen sollte, wo Renoir und A100 >60M schaffen).


505^2mm standen doch das ganze Jahr schon im Raum von aquriusZ aus dem PTT Forum ?

[Berniyh]

505^2mm standen doch das ganze Jahr schon im Raum von aquriusZ aus dem PTT Forum ?
Da ging man davon aus, dass das Arcturus mit seinen 128 CU ist und nicht Big Navi.
Bei Big Navi ging man eher von 400-450 mm2 aus.
(Laut einem Gerücht 427mm2 um genau zu sein.)
500 mm2 ist ja auch glaube ich das was TSMC als Limit angibt, iirc?

In meinen Augen spricht auch der große Abstand zwischen Navi 21 und 22 bei den CUs ganz klar gegen einen so massiv großen Chip.
d.h. man müsste den Bereich um 400-600€ rum mit so einem monströsen Chip bedienen, was ja immense Kosten verursacht.
Kann ich mir schlicht und einfach nicht vorstellen.
In dem Fall hätte man doch lieber 2 Chips designed um das abzufedern.

Edit: je mehr ich darüber nachdenke: auf mich wirkt das Video auch wieder einfach nur auf Klicks ausgelegt. Inkl. dem absurd verpixelten Bild wo er ja noch teilweise Navi 10 untergebracht hat.
Und natürlich wieder dieses ganze Getue "Ich hab die Infos, ich hab die Bilder, aber sorry, kann es nicht zeigen, weil Quellenschutz"
Yeah … right …

[woodsdog]

die 10/20gb version teilen sich dasselbe PT. die 20gb version wird nur etwas langsamer... der verbrauch ist identisch.

Du tust hier so als wäre das das ein Fakt der bereits offiziell ist, dabei hat keiner ne Ahnung von irgendwas weil noch nicht mal sicher feststeht OB überhaupt die 20GB Version kommt. Reine Speku deinerseits und dann sollte man auch irgendwie die Formulierung im Auge behalten.

[HOT]

Eine so große Die-Größe würde ich als Bestätigung für den Infinity-Cache sehen.

[Piefkee]

Da ging man davon aus, dass das Arcturus mit seinen 128 CU ist und nicht Big Navi.
Bei Big Navi ging man eher von 400-450 mm2 aus.
(Laut einem Gerücht 427mm2 um genau zu sein.)
500 mm2 ist ja auch glaube ich das was TSMC als Limit angibt, iirc?

In meinen Augen spricht auch der große Abstand zwischen Navi 21 und 22 bei den CUs ganz klar gegen einen so massiv großen Chip.
d.h. man müsste den Bereich um 400-600€ rum mit so einem monströsen Chip bedienen, was ja immense Kosten verursacht.
Kann ich mir schlicht und einfach nicht vorstellen.
In dem Fall hätte man doch lieber 2 Chips designed um das abzufedern.

Edit: je mehr ich darüber nachdenke: auf mich wirkt das Video auch wieder einfach nur auf Klicks ausgelegt. Inkl. dem absurd verpixelten Bild wo er ja noch teilweise Navi 10 untergebracht hat.
Und natürlich wieder dieses ganze Getue "Ich hab die Infos, ich hab die Bilder, aber sorry, kann es nicht zeigen, weil Quellenschutz"
Yeah … right …


Sorry aber das ist nicht richtig. AquriusZ hat ebenfalls etwas zu Acturus gepostet und HBM2.
Der lleak bezog sich auf Navi21,Navi22 und 23

Edit: auch Charlie von Semiacuarte hat was von >500mm^2 in seinen Artikel gesagt (Paywall)

[dargo]

Apropo Flächenkosten bei 7nm TSMC. Kann es sein, dass wir diese Kosten überschätzen? Ich bin mir mittlerweile nicht sicher ob das alles heute so extrem teuer ist. Mal als Beispiel Zen 2. Beim R7 3700X bekommen wir mittlerweile ohne Märchensteuer 161,5mm² (2x knapp 81mm²) für ~235€ (wie hoch ist dann der Einkaufswert?). Und so ein Zen 2 besteht ja nicht nur alleine aus den beiden Chiplets. Da kommen noch ~118mm² 14(?)nm Fläche dazu und das ganze Package.
https://abload.de/img/cpu44bekbf.jpg

Den Salvage R5 3600 mit gleichen Flächendaten gibts schon ab ~150€ ohne Märchensteuer. Die ganze XBSX wird es für 499€ geben bei 360mm² Die (inkl. recht kostspieligen SSD!). Ich weiß... die Marge bei den Konsolen wird einiges niedriger sein als bei Desktop-Hardware, aber dennoch.

[HOT]

Arcturus hatte ich ganz am Anfang, also noch 2019, mit 505mm² ins Verhältnis gebracht, weil ein abgespeckter Vega dazu passen würde. Allerdings ist Arcturus ganz sicher nicht abgespeckt. Ich würd eher davon ausgehen, dass das ein noch viel größeres Monster wird, 600mm²+. Die CUs werden ja nicht weniger können als bei Vega, ganz im Gegenteil.


Und eines ist jetzt sehr offensichtlich: Sollten die 536mm² stimmen, sollte man sich von dem Gedanken verabschieden, dass das Ding irgendwas mit den Konsolen SoCs gemein hat. Das ist was völlig anderes. Die Basisarchitektur ist RDNA2, der Implementation ist jedoch offensichtlich nicht vergleichbar.

Wenn man Renoir als Referenz nimmt, würde ich von 55mio/mm² ausgehen (etwas weniger als Renoir, weil reine GPU), das wären dann ebenfalls 28Mia Transistoren.

[dargo]

Und eines ist jetzt sehr offensichtlich: Sollten die 536mm² stimmen, sollte man sich von dem Gedanken verabschieden, dass das Ding irgendwas mit den Konsolen SoCs gemein hat. Das ist was völlig anderes. Die Basisarchitektur ist RDNA2, der Implementation ist jedoch offensichtlich nicht vergleichbar.

Dafür ist es noch zu früh wenn sich im Die ein großer Cache verbirgt oder unter dem HS ein HBM Stack schlummert. ;)

[Complicated]

Beim R7 3700X bekommen wir mittlerweile ohne Märchensteuer 161,5mm² (2x knapp 81mm²) für ~235€ (wie hoch ist dann der Einkaufswert?). Und so ein Zen 2 besteht ja nicht nur alleine aus den beiden Chiplets. Da kommen noch ~118mm² 14(?)nm Fläche dazu und das ganze Package..Es ist aber nur ein 7nm Chiplet involviert in deinem Beispiel -> 81mm²/7nm, wie auf dem Bild zu sehen ;).
Es sind also 235,- € für 81mm²/7nm + 118mm²/14nm

[reaperrr]

Eine so große Die-Größe würde ich als Bestätigung für den Infinity-Cache sehen.
Jup. Schon die 32 MB auf dem originalen XBO-Chip haben enorm Fläche gebraucht, dass wir jetzt 7nm statt 28nm haben wird durch die 4-fache Menge ausgeglichen.
So sah es beim XBO-Chip aus:
https://www.extremetech.com/gaming/171735-xbox-one-apu-reverse-engineered-reveals-sram-as-the-reason-for-small-gpu

Gab meines Wissens auch Hinweise darauf, dass bei N21 auch Dinge im Frontend verdoppelt wurden, die bis einschl. XSX nur einfach bzw. halb so oft vorlagen. Würde nicht ganz ausschließen, dass N21 schon eine R&D-Vorstufe zu GPU-Chiplets darstellt und quasi 2 "GPU-CCX" hat, wodurch mehr Redundanz als üblich auf dem Chip ist. Ist aber nur Speku.

Da ging man davon aus, dass das Arcturus mit seinen 128 CU ist und nicht Big Navi.
Bei Big Navi ging man eher von 400-450 mm2 aus.
Du meinst, die Leute wollten das mit den >500mm² von Anfang an nicht wahrhaben, weil es nicht zu ihren Milchmädchenrechnungen passte ;)

Dabei gab es zu Arcturus schon längst die Insider-Aussage, dass der "größer" ausfallen würde (also größer als dieser 505mm² Chip).


500 mm2 ist ja auch glaube ich das was TSMC als Limit angibt, iirc?

Nein, 7nm geht noch bis über 800mm². Das verringerte Reticle-Limit gilt m.W. erst ab 5nm.


In meinen Augen spricht auch der große Abstand zwischen Navi 21 und 22 bei den CUs ganz klar gegen einen so massiv großen Chip.

Im Gegenteil. Man will mit dem nächstkleineren Chip ja auch bei deutlich niedrigeren Preisen noch genug Marge haben. Außerdem ist es auch vom Designaufwand einfacher, einen Chip exakt zu halbieren. Man sieht auch bei NV oft, dass die Anzahl der SM je GPC zwischen den GPUs wenig variiert bzw. GPC-Konfiguration "recycelt" wird (TU106 war bis auf das SI genau halbierter TU102, TU116 bis auf SI und uArch-Unterschiede halbierter TU104, TU117 genau 2/3 von TU116).
Zu guter letzt reicht bei 40 CUs @ 192bit wahrscheinlich auch wieder deutlich weniger "InfinityCache" (48MB?) und langsamerer/billigerer 14Gbps G6.


d.h. man müsste den Bereich um 400-600€ rum mit so einem monströsen Chip bedienen, was ja immense Kosten verursacht.
Kann ich mir schlicht und einfach nicht vorstellen.

Ich auch nicht, aber da N21XT im Durchschnitt die 3080 schlagen soll, die mit 10GB 700€ kostet, weiß ich auch nicht, warum du glaubst dass es N21 (selbst den Salvage) für unter 500 geben sollte und das Top-Modell weniger als 700-800 kosten sollte?
Ich rechne mit 799€ Top-Dog, 649€ für 72CU/16GB Salvage, 549€ für 72 CU/192bit/12GB Salvage. Und später noch die Wakü-Version des Top-Dogs mit mehr Takt nah an 3090-Leistung für 999€.


Edit: je mehr ich darüber nachdenke: auf mich wirkt das Video auch wieder einfach nur auf Klicks ausgelegt.
Das sind die im Grunde alle. Heißt nicht automatisch, dass die Infos alle falsch sind.
Und Quellenschutz ist das A und O, wenn du überhaupt Quellen kriegen und v.a. behalten willst.

[unl34shed]

Apropo Flächenkosten bei 7nm TSMC. Kann es sein, dass wir diese Kosten überschätzen?

Was glaubst du denn, was die Chips kosten?
AMD bekommt 650 guter bzw. bis zu 700 brauchbare Compute Dies aus einem 300mm Wafer, bei 10k$ pro Wafer (vermutlich sind es weniger) sind das ~16$ pro Chip. Beim IO Die sind es ~400 pro Wafer bei deutlich geringeren Kosten (~10$/Die). Die CPUs werden mit Packaging etc. wenn es hoch kommt 75$ kosten, vermutlich weniger.

[dargo]

Es ist aber nur ein 7nm Chiplet involviert in deinem Beispiel -> 81mm²/7nm, wie auf dem Bild zu sehen ;).
Es sind also 235,- € für 81mm²/7nm + 118mm²/14nm
Argh.. stimmt ja. Zwei Chiplets gibts ja erst ab R9 3900X. :redface: Dann bleibt nur noch die XBSX als Beispiel. Aber bei den geringen Margen der Konsolen wohl eher weniger passend.

Edit:
Beim Desktop fällt mir nur die RX 5500XT ein. 158mm² 7nm Die für ab 140€ ohne Märchensteuer mit Händlermarge. In diesem Preis hast du noch das ganze PCB inkl. Spannungsversorgung + GDDR6 Speicher und Kühler.

[Zergra]

@dargo

Darfst halt nicht vergessen AMD bei Zen2 eben auch die ganzen Teil defekten verkaufen kann, und falls dann doch ein Chip komplett unbrauchbar ist, fällt das bei dem geringen Flächenanteil nicht auf.

Man hat dadurch keinen linearen Kostenverlauf zwischen kleinen und großen Chips.
Wenn man den 80CU als 60CU cut verkauft, wäre das natürlich eine Möglichkeit die Ausbeute zu erhöhen, gleichzeitig zeigt es eben genau das Problem (Bei den kleinen Chips hat man nur geringfügig gecuttet, jetzt um 1/4 ?)

[Berniyh]

Sorry aber das ist nicht richtig. AquriusZ hat ebenfalls etwas zu Acturus gepostet und HBM2.
Der lleak bezog sich auf Navi21,Navi22 und 23
Link?

Also soweit ich mich erinnere war bei den 505 mm2 nur davon die Rede, dass ein 505 mm2 Chip das Tape-Out hatte, aber ohne Zuordnung.
Der Spekulation hier (und anderswo) war dann, dass das Navi 21 wäre, aber später wurde das eben eher Arcturus zugeordnet.

[HOT]

Dafür ist es noch zu früh wenn sich im Die ein großer Cache verbirgt oder unter dem HS ein HBM Stack schlummert. ;)
Was fürn HS? In Neurosphere Post ist kein HS zu sehen.

Zergra
Es gibt von N21 offenbar 2 salvage-Stufen, das geht damit also auch...

[Berniyh]

Arcturus hatte ich ganz am Anfang, also noch 2019, mit 505mm² ins Verhältnis gebracht, weil ein abgespeckter Vega dazu passen würde. Allerdings ist Arcturus ganz sicher nicht abgespeckt. Ich würd eher davon ausgehen, dass das ein noch viel größeres Monster wird, 600mm²+. Die CUs werden ja nicht weniger können als bei Vega, ganz im Gegenteil.
Also alles was wir bislang wissen ist, dass Arcturus ein doppelter Vega 20 ohne das Zeug was man für die Grafikausgabe benötigt.

Alles darüber hinaus ist pure Spekulation deinerseits.

[dargo]

Was fürn HS?
Nenn es HS, WLP oder einfach nur Retuschieren der Fläche. Ändert nichts daran, dass wir nicht sehen was sich genau darunter versteckt.

@dargo

Darfst halt nicht vergessen AMD bei Zen2 eben auch die ganzen Teil defekten verkaufen kann, und falls dann doch ein Chip komplett unbrauchbar ist, fällt das bei dem geringen Flächenanteil nicht auf.

Teildefekt ist kein Argument. Es wird wie immer auch Salvages bei den jeweiligen Chips geben.

[HOT]

Also alles was wir bislang wissen ist, dass Arcturus ein doppelter Vega 20 ohne das Zeug was man für die Grafikausgabe benötigt.

Alles darüber hinaus ist pure Spekulation deinerseits.
Jo aber ziemlich wahrscheinlich. Ich sag ja nur, dass es mehr wird nicht weniger. Das was man an Grafik einspart wird durch anderes Zeug ziemlich sicher mehr als aufgewogen. Der wird ja optimiert auf Compute-Aufgaben. Wer A sagt und die Grafikbestandteile rausschmeißt wird sicherlich auch B sagen und die CU für Compute so stark und so flexibel wie möglich machen.

Nenn es HS, WLP oder einfach nur Retuschieren der Fläche. Ändert nichts daran, dass wir nicht sehen was sich genau darunter versteckt.


[...]
Noch mal, in Neurospheres Post ist kein HS zu sehen sondern nur das Package ohne HS.

[dargo]

Noch mal, in Neurospheres Post ist kein HS zu sehen sondern nur das Package ohne HS.
Was hast du jetzt an dem retuschierten Bild nicht verstanden? Oder willst du nur das letzte Wort haben? Selbst die Kanten wurden retuschiert damit keiner erkennen kann ob das Bild ein komplettes Die abbildet.

[nairune]

Hört ihr nicht zu?
Bei ~2:30 sagt er, dass er neben dem PCIe-Connector auch die GDDR6-Module auf dem Board zur Größenermittlung verwendet hat. Das macht die HS- und HBM-These nun äußerst unwahrscheinlich, außer es ist eine dieser wilden Varianten mit einem HBM-"Supportstack" oder sowas.

[HOT]

Was hast du jetzt an dem retuschierten Bild nicht verstanden? Oder willst du nur das letzte Wort haben?
Hab mir das Video nicht angeguckt ;).

[dargo]

Brauchst du auch nicht.
https://www.forum-3dcenter.org/vbulletin/showpost.php?p=12448296&postcount=13068

Hört ihr nicht zu?

Ich bei englisch schon mal nicht. ;)

[Cyberfries]

Laut seinen Aussagen sind das ca. 536mm²...

Aus dieser Pixelwüste kann eigentlich nichts abgeleitet werden.
Kann sein dass das N21 ist, kann aber auch ein Taschenrechner oder Gebäude sein.
Ich habe mehrfach gesagt, dass ich nicht an Infinity Cache und 505mm² glaube
und ich tue es auch weiterhin nicht, auch wenn ich möglicherweise in drei Wochen eines besseren belehrt werde.
Als Beleg reicht mir die Behauptung von "Traversal-Coprocessor-Coreteks" nicht.

Apropo Flächenkosten bei 7nm TSMC.

Laut AMD Folien ist ein Chiplet 74mm² groß.

Allerdings ist Arcturus ganz sicher nicht abgespeckt. Ich würd eher davon ausgehen, dass das ein noch viel größeres Monster wird, 600mm²+.

Ausgehend von der A100 Transistordichte wäre Arcturus auf 505mm² bei etwa 2,5x Vega20.
Ohne Grafikausgabe, ohne doppeltes Interface, usw...

[nairune]

Aus dieser Pixelwüste kann eigentlich nichts abgeleitet werden.
Kann sein dass das N21 ist, kann aber auch ein Taschenrechner oder Gebäude sein.


Er leitet ja auch nicht daraus ab, sondern aus dem full res Bild das er hat. Die Pixelwüste hat er angeblich selbst kreiert.
Also entweder ist das komplett ausgedacht, was ihm in Zukunft jegliche Glaubwürdigkeit raubt, oder das ist tatsächlich die Größe von dem Ding.

[dargo]

Laut AMD Folien ist ein Chiplet 74mm² groß.

Das ändert natürlich ne Menge. :freak: Spaß... ;) Nee... ich glaube Navi14 mit seinen 158mm² passt eher besser in die "Rechnung" wie ich vorhin schon schrieb.

Er leitet ja auch nicht daraus ab, sondern aus dem full res Bild das er hat.
Achso... er hat Zugriff auf das nicht retuschierte Bild? Ok.. das ändert natürlich einiges. Dann ist das Ding tatsächlich so groß (sofern der Typ natürlich glaubhaft ist) und der spekulierte HBM-Stack fällt weg. Was bleibt dann noch übrig außer "secret sauce Cache"?

[gedi]

Das ändert natürlich ne Menge. :freak: Spaß... ;) Nee... ich glaube Navi14 mit seinen 158mm² passt eher besser in die "Rechnung" wie ich vorhin schon schrieb.


Achso... er hat Zugriff auf das nicht retuschierte Bild? Ok.. das ändert natürlich einiges. Dann ist das Ding tatsächlich so groß (sofern der Typ natürlich glaubhaft ist) und der spekulierte HBM-Stack fällt weg. Was bleibt dann noch übrig außer "secret sauce Cache"?

128CUs+512-Bit SI z.B.

[dargo]

128CUs+512-Bit SI z.B.
So wenig? :usweet:

[robbitop]

IMO macht das den Cache wahrscheinlicher. Auch reißen die Gerüchte um diesen nicht ab. Das ist idR ein Zeichen, dass was dran sein kann.

Wenn das so ist, spart man auf jeden Fall eine Menge Leistungsaufnahme. Datenübertragung macht den Großteil des Verbrauchs heutiger GPUs aus. On Die kostet jedes bit deutlich weniger Energie.

[Reaping_Ant]

Es steht ja noch immer dass Gerücht im Raum, dass AMD auch den Speicher an die OEMs mit liefert und nicht nur den ASIC, wie das bei GDDR üblich ist bisher. Also wäre ein onPackage Speicher vorgegeben in dem Fall, wie auch immer der aussieht.
Ich meine, irgendwann mal gelesen zu haben, dass NV Bundles aus GPU und Memory an die Boardpartner verkauft hat. Also, dass diese den Speicher auch über NV beziehen müssen, wenn sie GPUs kaufen wollen. Leider finde ich keine Quelle mehr dazu. Von daher würde ich es nicht als zwingendes Indiz für HBM (oder anderen onPackage Speicher) werten, wenn dieser von AMD kommt. Im Gegenteil: Wenn der Speicher auf dem Package ist, dann taucht dieser doch gar nicht als separate Position bei den OEMs auf, da sie ja ohnehin das fertige Package geliefert bekommen.

[dargo]

Jepp... das würde auch zu der AMD-Folie passen.
https://www.igorslab.de/wp-content/uploads/2020/05/RDNA-3.png
"Reduce Complexity and Switching Power"

[Complicated]

Von daher würde ich es nicht als zwingendes Indiz für HBM (oder anderen onPackage Speicher) werten, wenn dieser von AMD kommt. Im Gegenteil: Wenn der Speicher auf dem Package ist, dann taucht dieser doch gar nicht als separate Position bei den OEMs auf, da sie ja ohnehin das fertige Package geliefert bekommen.
Ich würde hier einen Logikfehler verorten. Dass Speicher von AMD geliefert wird oder nicht, kann nicht davon abgeleitet werden auf welche Weise die Buchhaltung/Rechnungsstellung erfolgt. Also wenn AMD die komplette SKU inkl. Speicher in Rechnung stellt, ohne eine Postion für den Speicher, heisst das noch lange nicht, dass AMD den nicht liefert wenn der Speicher als SKU in der Position schon enthalten ist.

@zu dem Nvidia liefert auch Speicher, kann ich nichts sagen. Höre ich zum ersten mal. Allerdings ist das bei exklusivem Speicher wie GDDR6X wohl auch nicht so ungewöhnlich, wenn Micron größere Rabatte gewährt, wenn Nvidia als Großabnehmer auftritt. Das selbe gilt natürlich auch bei AMD, ist aber bei Mainstreamspeicher eher unwahrscheinlich, da der Markt wohl günstigere Preise erlaubt.

[Zergra]

Teildefekt ist kein Argument. Es wird wie immer auch Salvages bei den jeweiligen Chips geben.

Doch ist es, da der komplette defekt bei einem großen Chip eben gravierender ist, als bei einem kleinen. Die defekte kommen aber gleich häufig vor.

[dargo]

Ich habe nirgendwo von komplett defekten Chips gesprochen. Ist eh darüber müßig zu diskutieren wenn man die Yieldrate nicht kennt.

[Der_Korken]

Den 128MB großen Cache bekommt man in der Fläche sicherlich locker unter. Ich frage mich aber, was AMD damit erreichen will:

1. Fläche gespart haben sie auf keinen Fall, denn da wäre selbst ein 512bit SI noch kleiner ausgefallen.
2. Es spart gegenüber 384/512bit mglw. einiges an Strom ein. Aber wenn AMD hätte Strom sparen wollen, um den CUs mehr Saft geben zu können, dann hätten sie gleich HBM2e verwenden können. Ausgehend von N12 wäre der N21 dann kaum größer als der Xbox-SoC geworden, also 30% kleiner als 530mm². So teuer kann HBM doch nicht sein. Massiv Diespace für Effizienz investieren aber dann auf GDDR6 zu setzen, passt nicht so recht zusammen.

Eventuell ist dieser Cache-Aufbau ein Testballon für RDNA3. Dort wird der dann gestackt und vielleicht in 7nm bleiben, während die GPU auf 5nm geshrinkt wird. Weil Stacking aber noch nicht serienreif ist, wählen sie nun eine unwirtschaftlichere Lösung (verglichen mit z.B. HBM), können aber schon mal Erfahrungen sammeln.

Man sollte bei einem Cache nicht vergessen, dass die Latenzen massiv besser sein werden als die des VRAMs. Man braucht also weniger Threads, um die Latenzen für VRAM-Zugriffe zu verstecken. V20 hat damals trotz seiner absurd hohen Bandbreite noch von VRAM-OC profitiert und da wurde auch schon vermutet, dass nicht die Bandbreite, sondern die Speicherlatenzen entscheidend waren.

[dargo]

Eventuell ist dieser Cache-Aufbau ein Testballon für RDNA3. Dort wird der dann gestackt und vielleicht in 7nm bleiben, während die GPU auf 5nm geshrinkt wird. Weil Stacking aber noch nicht serienreif ist, wählen sie nun eine unwirtschaftlichere Lösung (verglichen mit z.B. HBM), können aber schon mal Erfahrungen sammeln.

Bingo. ;) Und eine Lösung mit Cache muss nicht zwangsläufig teurer sein als eine Lösung mit HBM. Wie gesagt... kann sein, dass wir die 7nm Kosten etwas überschätzen. Man muss sich nur mal überlegen welches Volumen AMD mittlerweile bei TSMC bucht. Zen2, Zen3, RDNA1, RDNA2, die beiden neuen Konsolen. Mich würde es nicht überraschen wenn es da von TSMC auch gute Konditionen bzw. Mengenrabatte gibt.

[mboeller]

So wenig? :usweet:

easy!

128 CU = ca. 256mm²
512bit = 90mm² (basierend auf dem XSX Die Shot)

sogar der große Cache sollte noch rein passen:
128MB Cache = 70mm² (basierend auf dem XBO Die Shot)

bleiben 120mm² für den Uncore etc...

[dargo]

Haben wir überhaupt schon Beweise, dass eine RDNA2 CU gleich groß ist wie eine RDNA1 CU? Ansonsten führt diese Rechnung ins Leere. Oder rechnest du schon anhand der XBSX?

[unl34shed]

Bei der XBOX sind die WGPs ca. 4.1mm² groß, bei N10 sind es 4.5mm²

[reaperrr]

Bei der XBOX sind die WGPs ca. 4.1mm² groß, bei N10 sind es 4.5mm²
Wo hast du das her?

Als ich mal selbst anhand des Dieshots gemessen habe, bin ich auf 4,2 gekommen, nah genug an den 4,1 der XSX dass es wahrscheinlich nur Messungenauigkeit ist.

Wie auch immer, normalisiert auf den gleichen Prozess bezweifle ich, dass sich an den CUs irgendwas relevantes geändert hat. Die Verbesserungen von RDNA2 scheinen aus dem Drumherum zu kommen (Frontend, Backend, Cache, evtl. noch Prozess).

[Cyberfries]

Er leitet ja auch nicht daraus ab, sondern aus dem full res Bild das er hat.

Eben. Ein Bild das er angeblich hat. Amen

easy!

512bit = 132mm²
128CU = 257mm²
128ROP = 21mm²
FE+SE = 43mm²
L2$ = 23mm²
CP+etc = 49mm²
-> 525mm², ziemlich nah an den 526mm²

Und eine Lösung mit Cache muss nicht zwangsläufig teurer sein als eine Lösung mit HBM.

Mit HBM komme ich auf etwa 340mm² und 80$ + 150$ HBM -> 230$.
526mm² wären eher 200$ + 75$ GDDR6 -> 275$.

----
Für alle Rechenbeispiele gilt der Hinweis auf Milchprodukte.
Und möglicherweise abgelaufene/verdorbene Zutaten.

[unl34shed]

Hab einfach nur die Werte von hier genommen für N10.
https://ptpimg.me/4d900c.png

[Complicated]

Mit HBM komme ich auf etwa 340mm² und 80$ + 150$ HBM -> 230$.
526mm² wären eher 200$ + 75$ GDDR6 -> 275$.

Und nimmt man hier noch den letzten Fertigungsschritt der OEMs zur fertigen Grafikkarte dazu, dann werden nochmals Kosten gespart beim PCB mit Einsatz von HBM

Kann jemand diese Kosten Unterschiede beziffern bei der Verwendung von GDDR6 vs HBM? Also grob in der selben Milchmädchen-Weise.

[nairune]

Die Zahlen erscheinen mir zu hoch. Das kannst ja erstmal verdoppeln für AMDs Marge / Entwicklungskosten. Dann kommen Kosten für Board und Kühler für die Partner, sowie deren Marge etc., dann Transport und Großhändlermarge sowie dasselbe nochmal für den Einzelhändler drauf. MwSt lasse ich mal weg, wenn es um Dollarpreise geht.
Also $1000? Naja kann schon sein.

[Berniyh]

Hört ihr nicht zu?
Bei ~2:30 sagt er, dass er neben dem PCIe-Connector auch die GDDR6-Module auf dem Board zur Größenermittlung verwendet hat. Das macht die HS- und HBM-These nun äußerst unwahrscheinlich, außer es ist eine dieser wilden Varianten mit einem HBM-"Supportstack" oder sowas.
HBM für die Salvage Varianten von Navi 21 stand schon lange nicht mehr zur Debatte.

[dargo]

Mit HBM komme ich auf etwa 340mm² und 80$ + 150$ HBM -> 230$.
526mm² wären eher 200$ + 75$ GDDR6 -> 275$.

----
Für alle Rechenbeispiele gilt der Hinweis auf Milchprodukte.
Und möglicherweise abgelaufene/verdorbene Zutaten.
:biggrin:

16GB GDDR6 für 75$ kommt mir sehr sportlich vor. :uponder: Da müsste sich der GDDR6 Preis in den letzten 1,5+ Jahren mehr als halbiert haben.
https://www.guru3d.com/news-story/gddr6-significantly-more-expensive-than-gddr5.html

Edit:
Hier was recht aktuelles zu GDDR6 16Gbps, keine Ahnung wie vertrauenswürdig diese Quelle ist.
https://www.hardwaretimes.com/doubling-graphics-memory-will-cost-nvidia-and-amd-less-than-12-gb-its-very-likely/

btw.
50% Rabatte bei OEMs ist heftig. :eek:

Nach dieser Rechnung müsste AMD wenn im großen Stil gekauft wird für 16GB 16Gbps GDDR6 ca. 80-106$ hinblättern. Ersteres ist dann doch gar nicht mal so weit von den 75$ entfernt. :tongue:

PS: wie ist das eigentlich bei den Konsolen? Besorgt den GDDR6 AMD für Sony und Microsoft oder besorgen sich das die beiden selbst?

[Thunder99]

Ich frage mich gerade ernsthaft, warum AMD nicht 384Bit (was ja getestet worden wurde, laut Gerüchten) setzt. Hätte man 12GB vs 10GB und in der Hinterhand 24GB vs 20, immer gestellt gegen RTX 3080 :confused:.

Zu teuer, nicht schnell genug, zu wenig Vorteile?

[Sunrise]

...Aber wenn AMD hätte Strom sparen wollen, um den CUs mehr Saft geben zu können, dann hätten sie gleich HBM2e verwenden können. Ausgehend von N12 wäre der N21 dann kaum größer als der Xbox-SoC geworden, also 30% kleiner als 530mm². So teuer kann HBM doch nicht sein. Massiv Diespace für Effizienz investieren aber dann auf GDDR6 zu setzen, passt nicht so recht zusammen.
Ich verstehe diesen Absatz von dir nicht. Gerade dann, wenn AMD massiv Strom sparen will und zugleich die Latenzen auf das absolute Minimum reduzieren möchte, ergibt doch der Cache sehr viel Sinn. Cache hat doch quasi nur Vorteile, außer jetzt mal den Platz, der natürlich auf die Die-Kosten und den Yield schlägt. Nur ist Cache ja bzgl. Redundanz (Yield) auch perfekt, bleibt also noch der Preis. Dennoch wären wir bei 500-550mm2 sicher (AMD will den Chip ja für viele Segmente nutzen) nicht zu groß. Wenn das mit dem Cache stimmt, dann braucht man wohl überhaupt kein HBM.

Mal komplett davon ab, dass NV doch perfekt zeigt, was sie für hohe Aufwände und Kompromisse eingegangen sind, nur um HBM bei Gaming- und Workstation-GPUs nicht verwenden zu müssen. Nur der extrem teure GA100 hat überhaupt HBM. Zudem ist GA102 auch wieder verdammt groß geworden, da wäre AMD selbst mit dem gigantischen Cache deutlich drunter und wahrscheinlich gravierend effizienter. Genau das wollte AMD ja wieder erreichen. Die Effizienz stetig enorm zu steigern.

...Eventuell ist dieser Cache-Aufbau ein Testballon für RDNA3. Dort wird der dann gestackt und vielleicht in 7nm bleiben, während die GPU auf 5nm geshrinkt wird. Weil Stacking aber noch nicht serienreif ist, wählen sie nun eine unwirtschaftlichere Lösung (verglichen mit z.B. HBM), können aber schon mal Erfahrungen sammeln.

Man sollte bei einem Cache nicht vergessen, dass die Latenzen massiv besser sein werden als die des VRAMs. Man braucht also weniger Threads, um die Latenzen für VRAM-Zugriffe zu verstecken. V20 hat damals trotz seiner absurd hohen Bandbreite noch von VRAM-OC profitiert und da wurde auch schon vermutet, dass nicht die Bandbreite, sondern die Speicherlatenzen entscheidend waren.
Wir müssen erstmal schauen, ob die Cache-Geschichte stimmt. Allerdings sehe ich nicht, wie man ohne 512bit SI, sehr schnellem Speicher bei 384bit oder HBM die benötigte Bandbreite liefern kann. Und wie gesagt, Cache ist ja quasi das non-plus Ultra, wenn es um Datenlokalität/möglichst geringem Energiebedarf geht und natürlich aufgrund der Lokalität dann auch sehr niedrigen Latenzen.

Bei den hohen Taktraten die bei Big Navi ja schon länger aufgrund PS5-SoC (RDNA2) spekuliert wurden, der hohen CU-Anzahl und dem Durchsatz den man hier erreichen will/muss (min. die 2fache Leistung von N10 auf weiterhin 7nm, wenn auch verbessert...) muss das ja irgendwo auch transportiert werden können, ohne das die Power explodiert wie bei NV.

[mboeller]

Bei der XBOX sind die WGPs ca. 4.1mm² groß, bei N10 sind es 4.5mm²

Jawed im Beyond3D Forum kommt sogar auf geringfügig weniger als 2mm² pro CU:

https://forum.beyond3d.com/threads/amd-navi-speculation-rumours-and-discussion-2019.61042/page-169#post-2160716

Das habe ich dann als Basis für die 256 mm² benutzt

[RLZ]

Ich frage mich gerade ernsthaft, warum AMD nicht 384Bit (was ja getestet worden wurde, laut Gerüchten) setzt. Hätte man 12GB vs 10GB und in der Hinterhand 24GB vs 20, immer gestellt gegen RTX 3080 :confused:
Mit 384 Bit hätte man sogar bei der Bandbreite die 3080 mit 16GBit/s eingeholt und es gäbe bis 512Bit noch Zwischenstufen. Allerdings weiß man auch nicht wie der Bandbreitenbedarf von von RDNA2 vs Ampere aussieht.

Es ist aber kein neues Pattern, dass man eine neue Cache-Stufe hinzufügt, wenn Cachegrößen möglich sind, die für die typischen Workings-Sets groß genug sind. Das wurde ja für GPUs in der Vergangenheit schon ein paar Mal versucht. Kritisch wird es halt, wenn der Cache zu knapp ausgelegt wird und die typischen Zugriffpattern dauerhaft zu Cache Trashing führen. Das könnte dazu führen, dass für manche Applikationen/Spiele die Cache Effizienz massiv zusammenbricht. Da ich die Zugriffspattern nicht kenne, erzeugen die propagierten zu einem mulmigen Gefühl in die Richtung, da es schon für einen 4K GBuffer sehr grenzwertig ist. Hoffen wir mal, dass uns der 8K Irrsinn nicht zu schnell einholt, sonst braucht man möglicherweise nochmal Faktor 4 bei der Cachegröße...

[Der_Korken]

Ich verstehe diesen Absatz von dir nicht. Gerade dann, wenn AMD massiv Strom sparen will und zugleich die Latenzen auf das absolute Minimum reduzieren möchte, ergibt doch der Cache sehr viel Sinn. Cache hat doch quasi nur Vorteile, außer jetzt mal den Platz, der natürlich auf die Die-Kosten und den Yield schlägt. Nur ist Cache ja bzgl. Redundanz (Yield) auch perfekt, bleibt also noch der Preis. Dennoch wären wir bei 500-550mm2 sicher (AMD will den Chip ja für viele Segmente nutzen) nicht zu groß. Wenn das mit dem Cache stimmt, dann braucht man wohl überhaupt kein HBM.

Was ich sagen wollte ist, dass ich den riesigen Cache für unwirtschaftlicher erachte als andere Lösungen. Klassisch würde AMD dafür GDDR6 mit 384bit@18Gbps oder 512bit@14Gbps verwenden. Nun will AMD aber offensichtlich etwas gegen den wachsenden Verbrauch der externen Bandbreite tun und nur 256bit verbauen. Das allein reicht aber nicht für so eine große GPU, also verbaut AMD (auf Basis des Infinity-Cache-Leaks und der 530mm²) einen großen Cache, der den gesamten Chip geschätzt ~35-40% größer werden lässt. Imho wäre HBM aber sowohl billiger als auch sparsamer: Das 256bit SI verbraucht wahrscheinlich schon so viel wie die HBM-Lösung allein und der Cache kommt noch oben drauf. Und 150mm² Waferspace@7nm ist auch ne Hausnummer, wenn man das in die Kalkulation GDDR6 vs HBM2(e) einbezieht.

Das unterstrichene ist etwas, das in Spekulationen kaum Beachtung findet. Es wird eigentlich nur über Speicherbandbreite diskutiert und ob ein Cache genug Zugriffe abfedern kann, um 30-50% externe Bandbreite einzusparen. Wenn Latenzen wirklich ein Flaschenhals sind (besonders bei großen GPUs, weil es schwierig wird genug parallele Arbeit für die ganzen CUs zu generieren), dann verstehe ich die (hypothetische) Entscheidung für den Cache. Das, und die Tatsache dass AMD damit Knowhow für RDNA3 sammeln möchte, sind für mich Argumente für einen Cache. Als reiner "Bandbreiteneinsparer" lohnt er sich imho nicht, da kann man lieber HBM nutzen oder auf dem selben Platz mehr CUs verbauen, die durch niedrigeren Takt auch die Effizienz erhöhen. Dass ein Cache gut für die Yields ist, glaube ich gerne, aber die Yields scheinen bei AMD kein Problem zu sein - eher die Anzahl der Wafer.

[basix]

...Cache Trashing...

...Cache Scrubbers...

Hmm? :uponder::whisper:

[nairune]

HBM für die Salvage Varianten von Navi 21 stand schon lange nicht mehr zur Debatte.

XT ist salvage? XTX war doch bisher nur höher getaktet / selektiert / sonst irgendwie bevorteilt. Selbst wenn der XTX HBM bekäme, so ändert das nichts an der geschätzten Chipgröße, es ging ja darum dass das kein Heatspreader mit verstecktem HBM ist.

[Dural]

Das wurde ja für GPUs in der Vergangenheit schon ein paar Mal versucht.



Und ist immer gnadenlos gescheitert...

Das ganze cache gerücht halte ich für völliger blödsinn.

[Lehdro]

Das ganze cache gerücht halte ich für völliger blödsinn.
Der Trend geht definitiv zu größeren Caches - völlig egal wo man hinschaut, ob nun Intel, AMD oder NV. Lass es so sein das AMD dem ganzen Ding einen fancy Namen ala "Game Cache" wie bei den Zen 2 CPUs gibt und davon kriegt irgendein Leaker Wind und bastelt da den Wundercache draus zusammen. Dann koppelt man das mit dem unbestätigten Memorybus und tada man hat die magic sauce und kann wild rumspekulieren...

So stell ich mir zumindest den Werdegang des Ganzen vor.

[Dural]

Grössere cache ja, aber sicher nicht zig mb gross. Was müsste man aktuell haben das es wirklich was bringt? 100mb aufwärts?

[Korvaun]

Hehe, diese Gen is aber auch echt verzwickt was Ram/Interface angeht. Kosten/Verbrauch/Bandbreite passen in keiner Kombination so zusammen das es die offensichtliche Lösung ist, und das von der 3060ti-Klasse an aufwärts (zumindest wenn man 8GB als nicht mehr zeitgemäß ansieht für Grakas >400€).

[Berniyh]

XT ist salvage? XTX war doch bisher nur höher getaktet / selektiert / sonst irgendwie bevorteilt. Selbst wenn der XTX HBM bekäme, so ändert das nichts an der geschätzten Chipgröße, es ging ja darum dass das kein Heatspreader mit verstecktem HBM ist.
Werden sehen. HBM stand jedenfalls nur für die XTX und evtl. Pro-Produkte wirklich zur Debatte.

Abgesehen davon ist meine Einschätzung, dass der Typ in dem Video keine wirklichen Infos hat, aber auch das werden wir schon noch sehen.
Dieses Bild hätte ich mir genauso zusammenschustern können …

[gedi]

Also wenn HBM zum Einsatz kommt, dann sicher runter bis zum kleinsten N21. Halte ich für komplett unwahrscheinlich. Das Gerücht dass RDNA2 sowohl als auch bedienen kam, wurde direkt von AMD geliefert (obwohl dann wäre es kein Gerücht)?

[Berniyh]

Also wenn HBM zum Einsatz kommt, dann sicher runter bis zum kleinsten N21.
Das können wir anhand des Treibercodes zu 99.9% ausschließen.

Wenn HBM, dann gibt es entweder 2 Speicherinterfaces, oder irgendein fancy Kombiinterface.

Die kleineren Navi 21 Varianten kommen mit GDDR6, das ist ziemlich sicher.

[gedi]

Dachte ich mir schon. Ich denke bis hoch zur XTX gibts stinknormalen GDDR6 mit 16GB/s

[Mortalvision]

Das wäre ein bisschen wenig ;D Die VII hatte ja schon 1 TB/sec

[gedi]

512-Bit an 16GB/s?

[Linmoum]

Das wäre ein bisschen wenig ;D Die VII hatte ja schon 1 TB/secDie VII hatte keinen riesigen Cache. Gewagte These in diesem Fall, dass das zu wenig ist.

[gedi]

Die VII war GCN mit weniger Einheiten als ne normale Vega. Dem Ding hätte man egal was verpassen können, die Performance war halt Meh. War nur ein Machbarkeitsprodukt in 7nM

[gedi]

Um mal den Cache beiseite schieben zu wollen: Wie wäre es mit TC-Cores als Äquivalent zu NV?

[Berniyh]

Die VII hatte im Grunde viel zu viel Bandbreite (für Gaming).
Aber Vega 20 war ja auch nicht als Chip für Consumer gedacht …

[Mortalvision]

512-Bit an 16GB/s?
Ihr alten Spielverderber, lasst mir doch meine sarkastischen Kommentare :freak:

[gedi]

Trotzdem meine Frage: Warum dann den riesigen Cache? Nur um fehlende Bandbreite auszugleichen? Den könnten sie bei den Konsolen eher gebrauchen, aber da gibbet so etwas nicht-nicht mal annähernd! 256-Bit für ein Halo-Produkt, sehr unwahrscheinlich. Die gab es bereits Anno 200x in Form eines R300. Vielleicht ist das SI auch 1024-Bit breit (ein Scherz)

[Cyberfries]

Die VII hatte ja schon 1 TB/sec

Vega 64 hatte 484GB/s und war am Limit.
Die 5700xt ist klar schneller, kommt mit 448GB/s aus und hat massig Reserven,
die 5600 hat dann nur 288GB/s, fast halb so viel wie Vega und leidet nicht wirklich darunter.
Da hat sich bei AMD einiges getan.

Wie wäre es mit TC-Cores als Äquivalent zu NV?

Was willst du damit besser machen? Rt gibts schon ohne, Compute is nicht.

[Linmoum]

Trotzdem meine Frage: Warum dann den riesigen Cache? Nur um fehlende Bandbreite auszugleichen? Den könnten sie bei den Konsolen eher gebrauchen, aber da gibbet so etwas nicht-nicht mal annähernd! 256-Bit für ein Halo-Produkt, sehr unwahrscheinlich. Die gab es bereits Anno 200x in Form eines R300. Vielleicht ist das SI auch 1024-Bit breit (ein Scherz)Siehe u.a. den Beitrag von Sunrise auf der letzten Seite: https://www.forum-3dcenter.org/vbulletin/showpost.php?p=12448691&postcount=13128

Und natürlich gibt's das bei den Konsolen nicht. Wie soll das gehen bei teils $399, die Sony für die Digital PS5 (aber trotzdem ja immer noch derselbe SoC) verlangt? Die Dinger würden durch den Cache fetter werden und mehr in der Herstellung kosten. Das geht bei Konsolen nicht.

Wenn der Cache ein potentiellies Bandbreiten-Defizit ausgleichen kann, dann ist es auch völlig latte, was da für ein SI bei einem Halo-Produkt verbaut ist. Ganz davon ab, dass so ein riesiger Cache deutlich mehr Halo wäre, als nur ein größeres SI.

[aufkrawall]

Die VII hatte im Grunde viel zu viel Bandbreite (für Gaming).

Sehe ich nicht so, die Bandbreite gabs als Gratis-Beiprodukt durch die Speichermenge und hat immerhin in einzelnen Spielen Achtungserfolge erzielen lassen.

[dargo]

Dann war die Kompression in V20 aber ganz schöner Mist bis nicht vorhanden wenn N10 mit 44% der Bandbreite von V20 auskommt und kaum langsamer ist.

[gedi]

Vega 64 hatte 484GB/s und war am Limit.
Die 5700xt ist klar schneller, kommt mit 448GB/s aus und hat massig Reserven,
die 5600 hat dann nur 288GB/s, fast halb so viel wie Vega und leidet nicht wirklich darunter.
Da hat sich bei AMD einiges getan.



Was willst du damit besser machen? Rt gibts schon ohne, Compute is nicht.

AMD selbst gibt an, dass die Compute-Performance um das 7-fache steigen wird

[horn 12]

https://www.hardwaretimes.com/amd-big-navi-to-pack-80cus-5120-cores-20-cus-to-be-used-for-ray-tracing-20-tflops-of-fp32/

Amd-big-navi-to-pack-80cus-5120-cores-20-cus-to-be-used-for-ray-tracing-20-tflops-of-fp32

[gedi]

Sehe ich nicht so, die Bandbreite gabs als Gratis-Beiprodukt durch die Speichermenge und hat immerhin in einzelnen Spielen Achtungserfolge erzielen lassen.

Klar wenn die Architektur zufällig drauf anspricht. Das mit dem Fine-Wine in bez. auf Vega hätten sie sich schenken sollen

[dargo]

https://www.hardwaretimes.com/amd-big-navi-to-pack-80cus-5120-cores-20-cus-to-be-used-for-ray-tracing-20-tflops-of-fp32/

Amd-big-navi-to-pack-80cus-5120-cores-20-cus-to-be-used-for-ray-tracing-20-tflops-of-fp32
What? Beim Einsatz von RT kümmern sich 20 CUs ausschließlich um RT-Beschleunigung und 60 CUs den Rasterizer? :|

[Cyberfries]

AMD selbst gibt an, dass die Compute-Performance um das 7-fache steigen wird

Quelle?

Amd-big-navi-to-pack-80cus-5120-cores-20-cus-to-be-used-for-ray-tracing-20-tflops-of-fp32

Ich hab mich schon gefragt wann der Blödsinn hier auftaucht.
Die Erfindung eines Twitterers, der zuletzt schonmal negativ aufgefallen ist.

[gedi]

https://www.hardwaretimes.com/amd-big-navi-to-pack-80cus-5120-cores-20-cus-to-be-used-for-ray-tracing-20-tflops-of-fp32/

Amd-big-navi-to-pack-80cus-5120-cores-20-cus-to-be-used-for-ray-tracing-20-tflops-of-fp32

Klingt gut, aber sicher nicht bei lediglich 80CUs

[nairune]

Also kostet RTX ON ~25% Leistung? Kommt hin, das ist bei NVidia ja so ähnlich. Bzw. kommt die Zahl vielleicht auch daher.

[gedi]

Quelle?



Ich hab mich schon gefragt wann der Blödsinn hier auftaucht.
Die Erfindung eines Twitterers, der zuletzt schonmal negativ aufgefallen ist.

Bitte zwinge mich jetzt nicht dazu zu suchen. Ich hocke hier mit nem Handy. Das findest du selbst

[RLZ]

https://www.hardwaretimes.com/amd-big-navi-to-pack-80cus-5120-cores-20-cus-to-be-used-for-ray-tracing-20-tflops-of-fp32/

Amd-big-navi-to-pack-80cus-5120-cores-20-cus-to-be-used-for-ray-tracing-20-tflops-of-fp32
Können die Leute nicht mal kurz in den Algorithmus reinschauen bevor sie sich irgendwas zusammenfantasieren? Das ist schon harter Tobak vom Dichter und wer auch immer das glaubt.

[Gipsel]

https://www.hardwaretimes.com/amd-big-navi-to-pack-80cus-5120-cores-20-cus-to-be-used-for-ray-tracing-20-tflops-of-fp32/

Amd-big-navi-to-pack-80cus-5120-cores-20-cus-to-be-used-for-ray-tracing-20-tflops-of-fp32Bullshit-Tweet und Bullshit-Meldung.

[gedi]

Der Post macht per se keinen Sinn!

[[MK2]Mythos]

Aus dem neusten Redgamingtech Video geht hervor, dass N21 mit 2,2 Ghz boostet und N22 mit 2,5 Ghz. War das vorher schon bekannt bzw spekuliert? Wäre das nicht ein Novum, dass die größte GPU nicht den höchsten Takt bekommt?

[Linmoum]

Das sind einfach nur die Erkenntnisse aus Big Sur, dort sind 2.05/2.2GHz für N21 und 2.5GHz für N22 hinterlegt.

[gedi]

Mythos;12449022']Aus dem neusten Redgamingtech Video geht hervor, dass N21 mit 2,2 Ghz boostet und N22 mit 2,5 Ghz. War das vorher schon bekannt bzw spekuliert? Wäre das nicht ein Novum, dass die größte GPU nicht den höchsten Takt bekommt?

Macht Sinn.

N21=128CUs mit 2.2G (wenn an dem Bild etwas wahres dran sein sollte)
N22=80CUs mit 2.5G
N23=56CUs mit 2.0G
N24=36CUs mit 2.5G

Je die größte Variante

Zu optimistisch? Ich weiß

[Linmoum]

Nur werden es 80/40/32 CUs und das sind Fakten.

[unl34shed]

Bitte zwinge mich jetzt nicht dazu zu suchen. Ich hocke hier mit nem Handy. Das findest du selbst

Da du mal wieder eine Behauptung hier in den Raum wirfst, die wohl vorher keiner gehört hat, ja bitte, verlinke die Quelle!

PS: Und komm nicht schon wieder mit Google...

[gedi]

Nur werden es 80/40/32 CUs und das sind Fakten.

Gestützt auf was?

[gedi]

Da du mal wieder eine Behauptung hier in den Raum wirfst, die wohl vorher keiner gehört hat, ja bitte, verlinke die Quelle!

PS: Und komm nicht schon wieder mit Google...

Ich gebe den Link morgen wenn es recht ist. Mit dem Handy schwierig

[Berniyh]

Die 2.2 und 2.5 GHz kommen aus der gleichen Quelle wie die 80 und 40 CU, nämlich der MacOS und Linux Firmware Dateien.

[dargo]

Nur werden es 80/40/32 CUs und das sind Fakten.
Das sind aber echt merkwürdige CU-Auslegungen je Chip. Den 40CU Chip kann ich noch irgendwie nachvollziehen wenn AMD diesen einiges höher taktet als den 80 CU Chip und der Salvage womöglich mit weniger als 72 CUs kommt und natürlich auch weniger Takt. Aber was zu Teufel will AMD mit einem 32 CU Chip wenn es schon einen 40-er gibt :uconf2: Das werden noch harte 3+ Wochen. :usad:

[Elite_Warrior]

Da würde "Moores Law is Dead" Spekulation tatsächlich etwas Sinn ergeben. Er sagt voraus, dass Big Navi einen großen Cache haben könnte und der N22 einen halb so großen. Der N23 könnte erheblich kleiner ausfallen weil er keinen L3-Cache besitzt und niedriger Taktet um Strom zu sparen.

[Berniyh]

Aber was zu Teufel will AMD mit einem 32 CU Chip wenn es schon einen 40-er gibt :uconf2: Das werden noch harte 3+ Wochen. :usad:
Vermutlich einen stromsparenden Chip bauen für mobile Anwendungen. Dass sich der Weg lohnen kann zeigt Navi 12 (wenngleich der mit HBM2 noch weitere Vorteile hat).

Aber das wird sich in den nächsten 3 Wochen wohl kaum auflösen, denn Navi 23 wird wohl frühestens Anfang 2021 kommen, wahrscheinlich sogar eher später.

[[MK2]Mythos]

Aus dem mlid Stream gerade: Er wirkt absolut sicher dass RDNA2 folgendes bietet:
- großer Hardlaunch mit breiter Verfügbarkeit in der zweiten Novemberwoche
- deutlich bessere Perf/Watt ggü NV
- RDNA2 kann mit jeder RTX30xx konkurrieren
- mehr Ram als in jedem entsprechenden Konkurrenzprodukt
- vernünftige Treiber zum Launch

[aufkrawall]

Dann war die Kompression in V20 aber ganz schöner Mist bis nicht vorhanden wenn N10 mit 44% der Bandbreite von V20 auskommt und kaum langsamer ist.
Du musst schon richtig lesen, ich sprach von "Achtungserfolgen in einzelnen Spielen". Da brauchst du dann nicht mit einem Durchschnittswert ankommen...

[Schnoesel]

Da war wohl der Wunsch der Vater des Gedanken. Ich lasse mich gerne positiv überraschen aber ich bezweifle, dass all diese Punkte zutreffen werden.

[Unicous]

Schon krass wie diese Youtuber immer die besten Quellen haben, die sich am Ende dann irgendwie nicht als so richtig zuverlässig erweisen, aber dennoch immer wieder von der "community" hofiert werden.


Woher weiß er dass es eine breite Verfügbarkeit gibt. Was heißt breite Verfügbarkeit überhaupt? Mehr als Nvidia. Genauso viel wie Nvidia. Etwas mehr als man sonst von AMD gewohnt ist?

bessere Perf/Watt. Wow. Das ist ja mal eine richtig konkrete Aussage.:eek:

RDNA2 kann mit Turing konkurieren. WOW!!!:O

Mehr RAM!!! WOW!!! Wird es auch mehr RAM sein wenn Nvidia mit 20GB VRAM um die Ecke kommt? Hat AMD schon 32GB Karten in petto?

Vernünftige Treiber. NOOOO WAAAAAAYYY :umassa:

Und das weiß er weil... es die Quelle ihm so berichtet hat?

Ich danke dir für die Zusammenfassung und dass du uns erspart hast diese brandheißen Infos nicht über 30 zähe Minuten vorgekaut zu bekommen, aber denkst du nicht selbst, dass das alles aus kompletter Bullshit ist, den er sich aus den Fingern gesogen hat?
Das sind alles Allgemeinplätze die das fanboi-Herz höherschlagen lassen, aber nicht mal entfernt irgendetwas Konkretes. Greifbares.

Nächste Woche heißt es dann wieder ohje RDNA2 ist zwar konkurrenzfähig aber kommt an die 3090 nicht heran. Die Woche darauf. BIG NAVI DESTROYS 3090 AND ITS HALF THE PRICE!!!!!!!1111!!!!!111

Merkt ihr das nicht?:confused:

[[MK2]Mythos]

Schon krass wie diese Youtuber immer die besten Quellen haben, die sich am Ende dann irgendwie nicht als so richtig zuverlässig erweisen, aber dennoch immer wieder von der "community" hofiert werden.


Woher weiß er dass es eine breite Verfügbarkeit gibt. Was heißt breite Verfügbarkeit überhaupt? Mehr als Nvidia. Genauso viel wie Nvidia. Etwas mehr als man sonst von AMD gewohnt ist?

bessere Perf/Watt. Wow. Das ist ja mal eine richtig konkrete Aussage.:eek:

RDNA2 kann mit Turing konkurieren. WOW!!!:O

Mehr RAM!!! WOW!!! Wird es auch mehr RAM sein wenn Nvidia mit 20GB VRAM um die Ecke kommt? Hat AMD schon 32GB Karten in petto?

Vernünftige Treiber. NOOOO WAAAAAAYYY :umassa:

Und das weiß er weil... es die Quelle ihm so berichtet hat?

Ich danke dir für die Zusammenfassung und dass du uns erspart hast diese brandheißen Infos nicht über 30 zähe Minuten vorgekaut zu bekommen, aber denkst du nicht selbst, dass das alles aus kompletter Bullshit ist, den er sich aus den Fingern gesogen hat?
Das sind alles Allgemeinplätze die das fanboi-Herz höherschlagen lassen, aber nicht mal entfernt irgendetwas Konkretes. Greifbares.

Nächste Woche heißt es dann wieder ohje RDNA2 ist zwar konkurrenzfähig aber kommt an die 3090 nicht heran. Die Woche darauf. BIG NAVI DESTROYS 3090 AND ITS HALF THE PRICE!!!!!!!1111!!!!!111

Merkt ihr das nicht?:confused:
Schlaganfall?
Also du musst schon richtig lesen worauf sich die Vergleiche beziehen. Und ich habe nur zusammengefasst, was er erzählt. Ob das stimmt, kann ich nicht beurteilen, genauso wenig, was er für Quellen hat. Grundsätzlich kann ich da aber kein Gehype oder "auf und ab der Gefühle" erkennen, letztendlich werden wir in gut 3 Wochen sehen, was wir von den "Leaks" halten können. Aber mlid kommt mir nicht wie der typische Schwätzer wie die anderen vor.

[Nazar]

Schon krass wie diese Youtuber immer die besten Quellen haben, die sich am Ende dann irgendwie nicht als so richtig zuverlässig erweisen, aber dennoch immer wieder von der "community" hofiert werden.


Woher weiß er dass es eine breite Verfügbarkeit gibt. Was heißt breite Verfügbarkeit überhaupt? Mehr als Nvidia. Genauso viel wie Nvidia. Etwas mehr als man sonst von AMD gewohnt ist?

bessere Perf/Watt. Wow. Das ist ja mal eine richtig konkrete Aussage.:eek:

RDNA2 kann mit Turing konkurieren. WOW!!!:O

Mehr RAM!!! WOW!!! Wird es auch mehr RAM sein wenn Nvidia mit 20GB VRAM um die Ecke kommt? Hat AMD schon 32GB Karten in petto?

Vernünftige Treiber. NOOOO WAAAAAAYYY :umassa:

Und das weiß er weil... es die Quelle ihm so berichtet hat?

Ich danke dir für die Zusammenfassung und dass du uns erspart hast diese brandheißen Infos nicht über 30 zähe Minuten vorgekaut zu bekommen, aber denkst du nicht selbst, dass das alles aus kompletter Bullshit ist, den er sich aus den Fingern gesogen hat?
Das sind alles Allgemeinplätze die das fanboi-Herz höherschlagen lassen, aber nicht mal entfernt irgendetwas Konkretes. Greifbares.

Nächste Woche heißt es dann wieder ohje RDNA2 ist zwar konkurrenzfähig aber kommt an die 3090 nicht heran. Die Woche darauf. BIG NAVI DESTROYS 3090 AND ITS HALF THE PRICE!!!!!!!1111!!!!!111

Merkt ihr das nicht?:confused:

Was ist denn mit dir los?:confused: :freak:

MLID hatte schon mit dem nV Spekus sehr früh das Meiste sehr genau vorhergesagt, als ihn alle als Spinner abtaten. Dass die Leistung der 3090 wohl nur um die 40% besser sein wird als die der 2080TI, die hohen Watt Zahlen und dass das Binning sehr schlecht sein soll. Auch beim Speicher lag er richtig und das erst später die hohen VRAM Varianten folgen sollen.
Ich persönlich sehe das nicht ganz so rosig bei AMD wie er das meint aber ich habe auch gar keine Insider Infos.
Woher du nun aber deinen Ansporn für diesen Rant hernimst, bleibt wohl dein Geheimnis. "Half the Price... " wann hat er das gesagt? :confused:
Einfach mal locker durch die Hose atmen.... ;)

[Unicous]

Ja, ich bekomme jedes Mal einen Schlaganfall wenn ich coreteks, Redgamingtech oder Moore's Law is dead lese. Adored scheint ja als Hypetrain-Conductor vorerst ausgedient zu haben und daher wird der Fokus auf diese Nasen gelegt.

Es gibt ein ständiges Auf und Ab, was RDNA2 "leaks" anbelangt. Und diese Herren tun so als hätten sie die Weisheit mit Löffeln gefressen und wären allwissend. Wenn sie auf offensichtliche Fehler angesprochen werden reagieren sie pampig und lassen gerne mal die ein oder andere Twitter-Tirade los.

Dass echte Leaker/"human webcrawler" sie kaum für voll nehmen sollte eigentlich stutzig machen. Stattdessen wird jedes Video gehypt und für bare Münze genommen.
Dabei haben diese Youtuber überhaupt keinen track record. Selbst unser Märchenonkel und neues Youtube-Sternchen hat den ein oder anderen substantiellen Leak vorzuweisen, auch wenn er in letzter Zeit etwas zu viele Märchen erzählt hat. Diese Typen, afaik: Nichts. Gar nichts.
Und trotzdem werden ihre Videos immer wieder aufs Neue als die letzte Offenbarung gehandelt.

Ich hoffe es kommt als Reaktion auf diesen Schlaganfall eine Liste der eingetretenen! Offenbarungen seitens dieses und/oder der anderen Herren die mich eines Besseren belehren, ich kenne sie nur als Schaumschläger die Gerüchte von anderen klauen aufnehmen und für YT aufschmücken. Zum Beispiel mit der Analyse von irgendeinem willkürlichen Patent, dass jemand bei Twitter ausgegraben hat und darauf folgt dann eine minutenlange Erläuterung, dass dieses Patent nur darauf hindeuten kann, dass die Mondlandung ein hoax war Big Navi HBM2 und GDDR6 gleichzeitig nutzt und dazu noch einen fetten on die Cache hat.

[Linmoum]

MLID hatte schon mit dem nV Spekus sehr früh das Meiste sehr genau vorhergesagt, als ihn alle als Spinner abtaten.Dass man ihn als Spinner abtut, braucht niemanden zu wundern. Was bei Coreteks der Co-Prozessor ist, ist bei ihm der NVCache. Beide komplett mit auf die Fresse geflogen.

Bei deinem Rest braucht es keine Insiderinfos, um das einordnen zu können. Zumal das meiste schon seit Monaten durch die Gerüchteküche ein offenes Geheimnis war.

[Iscaran]

Eine Die-Size von >500mm^2 passt eigentlich nur DANN zu 80 CU wenn das Die ein Package ist und darin der HBM enthalten ist.

Eine 80 CU RDNA2 mit ungefähr vergleichbarem Aufbau wie ein Navi10 wäre eigentlich nur so um die 370 mm^2 groß, wenn wir noch dazu +20% Packdichte in den CUs annehmen (und ein 256-Bit SI). Aber auch mit 512 Bit SI wäre man bei +20% Packdichte bei 430 mm^2 aber eben nicht bei >500mm^2

Aufgrund der Ähnlichkeit in der Treiberstruktur zu anderen HBM-Karten können dann die TCCS Angaben aus dem Treiberleak eigentlich nur auf 2048-Bit HBM hindeuten, was ich als 2-Stacks interpretieren würden

2 stackes zu je 8GB.

Dann passt sowohl die Bandbreite als auch der VRAM Ausbau zu einer GPU die mit 80 CUs vollgepackt ist und mit >2GHz taktet.

Da HBM deutlich Stromsparender ist als GDDR6 würde das auch deutlich helfen die P/W von +50% hinzubekommen.

Ich denke das wird der Große - es sei denn AMD hat den "ganz großen" noch gar nicht im "leak programm" und die 80 CU sind "nur" der RTX3080 Counterpart.
ABER das glaube ich nicht. Schon der Sprung zu 80 CUs bei AMD ist "krass" - nochmehr als realisierbar anzunehmen wäre eigentlich nur Fantasy.

Demnach also : N21, 6900 XT@80CU, @>2GHz (2.2 ?), @2048bit und 16 GB HBM2(oder HBM2e). Konfiguration 4x2x5x2 (Shader Engines, Shader Arrays pro Engine, WGP/Array CU/WGP).

Dazu ein Salvage Chip 6800 blablubb mit 72 oder 76 CU (1 oder 2 deaktivierte CU pro Shader Array) @ >2Ghz und HBM2

Der N22 ist dann der 40CU Chip dann mit 2.5 GHz Takt @ GDDR 6, 16 GB@256 Bit
Ist dann sowas wie eine 6700

der 32 CU ist dann der spritsparende /Mobil chip mit max 75 W (bei niedrigerem Takt). Bzw 150 W bei vollem Takt als 6600 XT mit 8Gb GDDR 6.

[[MK2]Mythos]

Ja, ich bekomme jedes Mal einen Schlaganfall wenn ich coreteks, Redgamingtech oder Moore's Law is dead lese. Adored scheint ja als Hypetrain-Conductor vorerst ausgedient zu haben und daher wird der Fokus auf diese Nasen gelegt.

Es gibt ein ständiges Auf und Ab, was RDNA2 "leaks" anbelangt. Und diese Herren tun so als hätten sie die Weisheit mit Löffeln gefressen und wären allwissend. Wenn sie auf offensichtliche Fehler angesprochen werden reagieren sie pampig und lassen gerne mal die ein oder andere Twitter-Tirade los.

Dass echte Leaker/"human webcrawler" sie kaum für voll nehmen sollte eigentlich stutzig machen. Stattdessen wird jedes Video gehypt und für bare Münze genommen.
Dabei haben diese Youtuber überhaupt keinen track record. Selbst unser Märchenonkel und neues Youtube-Sternchen hat den ein oder anderen substantiellen Leak vorzuweisen, auch wenn er in letzter Zeit etwas zu viele Märchen erzählt hat. Diese Typen, afaik: Nichts. Gar nichts.
Und trotzdem werden ihre Videos immer wieder aufs Neue als die letzte Offenbarung gehandelt.

Ich hoffe es kommt als Reaktion auf diesen Schlaganfall eine Liste der eingetretenen! Offenbarungen seitens dieses und/oder der anderen Herren die mich eines Besseren belehren, ich kenne sie nur als Schaumschläger die Gerüchte von anderen klauen aufnehmen und für YT aufschmücken. Zum Beispiel mit der Analyse von irgendeinem willkürlichen Patent, dass jemand bei Twitter ausgegraben hat und darauf folgt dann eine minutenlange Erläuterung, dass dieses Patent nur darauf hindeuten kann, dass die Mondlandung ein hoax war Big Navi HBM2 und GDDR6 gleichzeitig nutzt und dazu noch einen fetten on die Cache hat.
Wie bereits gesagt, habe ich nur zusammengefasst, was Inhalt des Videos ist. Absolut kein Hype. Ich verstehe deinen Hass überhaupt nicht. Du kannst dich ja gerne in 3 Wochen so richtig hart über ihn (und die anderen) auslassen, wenn sich herausstellt, dass sie Bullshit erzählt haben. Aber diese Aufregung im VORAUS finde ich vollkommen daneben. Es ist ja nicht so, als würde er das Blaue vom Himmel herbeireden.

Wenn N21 stark ist, ist es wahrscheinlich, dass AMD die Karten auf nvidias Performance noch anpassen konnte. Die bessere Performance/Watt dürfte nun auch keine große Überraschung sein und den Rest werden wir einfach sehen müssen.

Ich bin der erste der solche Kanäle abignoriert wenn sich herausstellt, dass sie Quatsch erzählen.

[Dampf]

Mythos;12449156'] Es ist ja nicht so, als würde er das Blaue vom Himmel herbeireden.

Oooh doch. Glaub mir, ich hab gefühlt Stunden damit verbracht, den Leuten logisch zu erklären warum MLID's Ampere Gerüchte wie vierfache Raytracing Leistung und DLSS 3.0 kompletter Unsinn sind. Was solche Youtuber an Fanboy-Wars und Falschinformationen anstacheln, ist echt nicht mehr feierlich.

Wenn die mal richtig liegen, dann nur weil sie von namenhaften Leakern auf Twitter klauen.

[Brillus]

Mythos;12449118']
- deutlich bessere Perf/Watt ggü NV
- mehr Ram als in jedem entsprechenden Konkurrenzprodukt


Bei den beiden Punkten glaub ich nicht.

Ok deutlich ist wohl auch Definitionssache aber ich denke nicht das es soviel besser sein wird, wenn ich die Werte recht im Kopf habe sind es wenn die 50% von AMD stimmen so 10% mehr, wenn man AMD tiefstapeln in letzter Zeit mitbedenkt sind wir vielleicht bei 20%.

Und vor allem ich sah noch keinen halbwegs glaubhaften Leak mit mehr als 16GB und bzgl 3090 müsste es ja aber über 24GB sein.

[Berniyh]

Aufgrund der Ähnlichkeit in der Treiberstruktur zu anderen HBM-Karten können dann die TCCS Angaben aus dem Treiberleak eigentlich nur auf 2048-Bit HBM hindeuten, was ich als 2-Stacks interpretieren würden

2 stackes zu je 8GB.
Ich denke prinzipiell liegst du schon richtig, da ich auch nicht mehr als 2 Stacks erwarten würde, aber …

Auf Grund der TCCS kannst du das nicht ableiten. Warum? Arcturus hat auch 16 TCCS, d.h. genau so viele wie Navi 21.
Und du wirst nun wohl kaum davon ausgehen, dass Arcturus mit "nur" 2 Stacks HBM kommt, oder?
Da HBM deutlich Stromsparender ist als GDDR6 würde das auch deutlich helfen die P/W von +50% hinzubekommen.
Die Frage ist, ob das bei einem Kombi-Interface dann auch noch zutrifft.

[Berniyh]

Wenn die mal richtig liegen, dann nur weil sie von namenhaften Leakern auf Twitter klauen.
Oder halt so viel unterschiedliche Dinge behaupten, dass dann am Ende irgendwas schon zutreffen wird.
Und wie das immer so ist werden am Ende nur die positiven Dinge als Bestätigung genommen und die ganzen falschen Dinge ignoriert.

Eigentlich müsste man einen fact check für derartige Kanäle einführen, wo dargelegt wird wie oft sie richtig und falsch lagen.
So wie er ja auch behauptet seine Quellen zu prüfen, so muss er sich halt auch dieser Prüfung unterziehen. Das ist doch nur sinnvoll.

Aber letztendlich finde es schon ok, wenn man einen Link zu so einem Video hier im Thread postet. Muss ja jeder selbst wissen ob er sich das antut oder nicht.
Zumindest wäre aber eine Zusammenfassung des Inhalts aber noch ganz nett und das hat Mythos ja gemacht, insofern passt das schon. ;)

[dargo]

Vermutlich einen stromsparenden Chip bauen für mobile Anwendungen. Dass sich der Weg lohnen kann zeigt Navi 12 (wenngleich der mit HBM2 noch weitere Vorteile hat).

Aber warum gerade 32 CUs? Da könnte man genau so den 40CU Chip dafür "verwurschteln". Siehe auch Navi 12.

[reaperrr]

wenn wir noch dazu +20% Packdichte in den CUs annehmen
Welche +20% Packdichte?
Die CUs in den Konsolen-APUs sind jedenfalls nicht dichter gepackt als die von N10, und an N7+ (EUV) glaube ich mittlerweile ehrlich gesagt nicht mehr so richtig (und selbst wenn ist fraglich, ob AMD die mögliche höhere Packdichte nutzen würde, statt lieber auf mehr Takt zu optimieren wie bei Zen+/Polaris30).

[Zergra]

Mythos;12449118']Aus dem mlid Stream gerade: Er wirkt absolut sicher dass RDNA2 folgendes bietet:
- großer Hardlaunch mit breiter Verfügbarkeit in der zweiten Novemberwoche
- deutlich bessere Perf/Watt ggü NV
- RDNA2 kann mit jeder RTX30xx konkurrieren
- mehr Ram als in jedem entsprechenden Konkurrenzprodukt
- vernünftige Treiber zum Launch

Ein Punkt davon wäre schon eine große Überraschung.

[basix]

Die CUs in den Konsolen-APUs sind jedenfalls nicht dichter gepackt als die von N10,.

Und das ist eigentlich schon überraschend. RDNA2 bringt alle DX12U Features, Raytracing und vermutlich RPM bis und mit INT4. Dennoch sind die CUs ~10% kleiner als die von Navi 10.

[Der_Korken]

Welche +20% Packdichte?
Die CUs in den Konsolen-APUs sind jedenfalls nicht dichter gepackt als die von N10, und an N7+ (EUV) glaube ich mittlerweile ehrlich gesagt nicht mehr so richtig (und selbst wenn ist fraglich, ob AMD die mögliche höhere Packdichte nutzen würde, statt lieber auf mehr Takt zu optimieren wie bei Zen+/Polaris30).

Ich weiß nicht wie oft es hier schon gesagt wurde, aber wenn es keine bessere Packdichte für N2x geben kann, wie kann es sein, dass Renoir und A100 dann 50% mehr Transistoren pro Fläche im selben Prozess unterkriegen und selbst die GA-Chips 12,5% mehr schaffen trotz schlechterem Prozess? Und es ist ja nicht so als hätte Renoir kein IO und die Taktraten sehen auch super aus (CPU fast genauso hoch wie Matisse und Vega8 taktet besser als V20 und N10 im Nichtmobil-7nm).

[Berniyh]

Aber warum gerade 32 CUs? Da könnte man genau so den 40CU Chip dafür "verwurschteln". Siehe auch Navi 12.
Keine Ahnung. Evtl. langen die 32 CU für den anvisierten Bereich einfach.
Und vermutlich wollte man noch beim Speicherinterface (128 Bit) und evtl. anderen Bereichen weiter Fläche einsparen.
Zudem unterscheidet sich Navi 12 von Navi 10 in mehr als nur dem HBM2 Speicherinterface. Solche Modifikationen könnten hier auch einfließen.

[dargo]

Keine Ahnung. Evtl. langen die 32 CU für den anvisierten Bereich einfach.
Und vermutlich wollte man noch beim Speicherinterface (128 Bit) und evtl. anderen Bereichen weiter Fläche einsparen.
Zudem unterscheidet sich Navi 12 von Navi 10 in mehr als nur dem HBM2 Speicherinterface. Solche Modifikationen könnten hier auch einfließen.
Hmm... ok, das leuchtet ein. Dh. für den Desktop werden am 28 Oktober nur zwei Chips vorgestellt mit min. vier Varianten.

[WedgeAntilles]

Mythos, nicht falsch verstehen!
Das Folgende geht ausschließlich gegen die Youtuber und nicht gegen dich.
Ich bin froh, dass du das Video so schön zusammen gefasst hast.
Vielen Dank dafür :)


Diese Youtuber hauen halt tonnenweise Meldungen raus.
Irgenwas stimmt dann zwangsläufig.

Das ist wie die Bildzeitung bei Transfergerüchten.
Da ist der heiß umworbene Top-Spieler dann "quasi fix" bei ca. 10 Vereinen. Den 10 Größten halt.
Und ja, welch Wunder, die Chance, dass der Spieler tatsächlich bei einem dieser Verein landet ist natürlich groß.

Und dann heißt es: "Bild wusste es als Erstes"
Dabei wurde im Laufe der Wochen einfach so ziemlich jeder realistische Verein ins Spiel gebracht.

Oder Wahrsager. Wenn ich jedes Jahr wahrsage, dass der Papst stirbst - nun, irgendwann werde ich damit recht haben.
Vor allem wenn ich das mache, wenn der Papst schon 75 ist...
Ist das dann der Beweis für meine Hellseherischen Fähigkeiten?


Alleine die Aussage, dass BigNavi 32GB Speicher haben wird, halte ich für - sorry - derartigen Schwachsinn, dass sich der Rest von selber disqualifiziert.
Und falls er die 3090 ausklammert - oh wow, ja, BigNavi wird mehr als die 10GB der 3080 haben. Ja, was für ein "LEAK". Das ist doch schon immer so sicher gewesen, wie das Amen in der Kirche gewesen.

[Berniyh]

Hmm... ok, das leuchtet ein. Dh. für den Desktop werden am 28 Oktober nur zwei Chips vorgestellt mit min. vier Varianten.
Dass die kleineren RDNA2 Varianten dieses Jahr nicht mehr kommen war eigentlich schon länger abzusehen.
Selbst bei Navi 22 gehen viele davon aus, dass die Verfügbarkeit erst nächstes Jahr sein wird.

Gesichert ist ein Release – basierend auf AMD Aussagen – eigentlich nur für Navi 21.

[HOT]

N22 wird im Dezember im Laden stehen. N10 ist EOL und wird bis Dezember ausverkauft sein, dann hätte AMD gar nichts in dem Preisbereich Weihnachten im Laden -> extrem unwahrscheinlich.

N23 wird 32CUs sein, weil man die Mobil am Sweetspot betreiben kann und die 128Bit dazu passen.

[Cyberfries]

32CUs sind an sich keine schlechte Wahl.
N14 leidet an vielen CUs und nur eine Shader Engine, da sind 32CUs an 2SEs viel harmonischer.
Unverständlich ist nur der geringe Sprung zu 40CUs, da hätte ich eher 48 gewählt.

wie kann es sein, dass Renoir und A100 dann 50% mehr Transistoren pro Fläche im selben Prozess unterkriegen und selbst die GA-Chips 12,5% mehr schaffen trotz schlechterem Prozess?

Auslegung auf hohe Dichte und großer Anteil gut skalierender Bestandteile in einem ausgereiften Prozess.
Dass N10 noch nicht ans Limit ging sieht man an der xBox, heute wäre N10 deutlich kleiner.
Besserer Prozess bedeutet nicht, dass jede Eigenschaft besser ist. 8nm ist sehr dicht.

N10 ist EOL und wird bis Dezember ausverkauft sein

Na, nur die 5700. AMD hat bereits die Weiterproduktion von 5700xt und 5600 bestätigt.

[basix]

Alleine die Aussage, dass BigNavi 32GB Speicher haben wird, halte ich für - sorry - derartigen Schwachsinn, dass sich der Rest von selber disqualifiziert.

Die 32 GByte gelten soweit ich es verstanden habe nur für die Profi-Version, nicht für eine Gamer-SKU.

Du, abwarten und Tee trinken. Die Vorstellung ist in knapp 3 Wochen. Schade wurde die 3070 um 2 Wochen nach hinten verschoben. Sonst hätten wir so im Wochenabstand neues Futter bekommen (Zen 3, 3070, RDNA2, XBSX, PS5) :D

[RitterRost]

Wenn die 32CU GPU auf HBM setzt und auf den großen Cache verzichtet, wäre es vermutlich eine viel kleinere GPU.

Was ich an dem N21 Bild noch immer nicht so richtig glauben kann - der Die (falls es nicht ein Deckel ist) ist sehr rechteckig. Das war zwar VEGA20 auch, aber soweit ich mich erinner, wächst der Verschnitt von den runden Wafer stark an. Deshalb will man eigentlich quadratische Chips belichten, um möglichst wenig vom teuren Wafer am Rand wegwerfen zu müssen.

[basix]

Was ich an dem N21 Bild noch immer nicht so richtig glauben kann - der Die (falls es nicht ein Deckel ist) ist sehr rechteckig. Das war zwar VEGA20 auch, aber soweit ich mich erinner, wächst der Verschnitt von den runden Wafer stark an. Deshalb will man eigentlich quadratische Chips belichten, um möglichst wenig vom teuren Wafer am Rand wegwerfen zu müssen.

Ohne entsprechenden Grund wird man immer möglichs quadratische Die bauen wollen, das ist richtig. Bei Vega 20 war der Die vor allem aufgrund der HBM-Stacks eher länglich. Bei allen anderen GPUs ist das Seitenverhältnis eigentlich fast immer <1.33x1.0 (Ausnahme können eher kleine GPUs sein). Einzig die Intel CPUs ab Coffee Lake sind sehr stark länglich, da Intel damit nicht den ganzen CPU-Floorplan auf den Kopf stellen musste.

Solch ein ablänges Die ist somit ausserhalb von HBM eher unwahrscheinlich.

[Complicated]

N10 ist EOL und wird bis Dezember ausverkauft sein, dann hätte AMD gar nichts in dem Preisbereich Weihnachten im Laden -> extrem unwahrscheinlich.Quelle? Das ist wenig glaubwürdig und du schreibst es als Fakt.

[Linmoum]

Das waren Gerüchte, die AMD für die 5700-Serie schon offiziell dementiert hat.

https://www.reddit.com/r/Amd/comments/j48lor/official_statement_from_amd_we_are_continuing_to/

[Zergra]

Das waren Gerüchte, die AMD für die 5700-Serie schon offiziell dementiert hat.

https://www.reddit.com/r/Amd/comments/j48lor/official_statement_from_amd_we_are_continuing_to/

Also kann man davon ausgehen das in dem Performance bereich die nächsten Monate nichts kommt.

Also nur Navi 21, Navi 22 dann Q1 2021.

[dargo]

N14 leidet an vielen CUs und nur eine Shader Engine, da sind 32CUs an 2SEs viel harmonischer.
Wieso sieht man davon in Benchmarks nichts? :confused: Das Ding positioniert sich genau dort wo es mit 22 CUs zu erwarten ist. Eine RX 5700XT ist rund 75-80% schneller. Die RX 5500XT hat dabei sogar noch leicht tiefere Frequenzen.

Also kann man davon ausgehen das in dem Performance bereich die nächsten Monate nichts kommt.

Also nur Navi 21, Navi 22 dann Q1 2021.
Ja... davon würde ich ausgehen. Mit viel Glück vielleicht N22 noch im Dezember, halte ich aber eher für unwahrscheinlich, dass im Laden genug Karten davon stehen.

[mironicus]

Wer tragbar ist eigentlich die Vermutung, daß AMD einen großen Chip baut, der gleichzeitig HBM2 und GDDR6 verwenden kann und sich dadurch den Bau von zwei unterschiedlichen großen Chips erspart?

Sie könnten dann z.B. einen 3080-Konkurrenten bauen mit GDDR6, und einen 3090-artigen Vollausbau mit HBM und 32 GB für einen deutlich höheren Preis.

[Der_Korken]

Unverständlich ist nur der geringe Sprung zu 40CUs, da hätte ich eher 48 gewählt.


Das ist, denk ich, was viele stört. 48CUs für N22 würden auch in Relation zu N21 viel besser ins Bild passen.


Auslegung auf hohe Dichte und großer Anteil gut skalierender Bestandteile in einem ausgereiften Prozess.
Dass N10 noch nicht ans Limit ging sieht man an der xBox, heute wäre N10 deutlich kleiner.

Richtig, man kann nicht von N10 ausgehen und dann annehmen, da tut sich nichts mehr. Renoir hat auch gar nicht mal so wenig IO (2x128bit DDR4, 24xPCIe 3.0, Display-Ausgänge) und ist trotzdem dichter gepackt als ein Matisse mit quasi gar keinem IO. Da kann sich bei N2x einiges tun, vor allem wenn das Interface so klein bleibt wie bei N10.

[basix]

Interessanterwiese ist der XBSX SoC eben nicht dichter gepackt. Dennoch ist die GPU deutlich kompakter geworden. Das ist wohl "reducing logic complexity and switching power" von RDNA2

Die hohe Packdichte von Renoir ist vor allem seiner Low Power Auslegung geschuldet. Denn sind die CPU-Cores, Caches und Vega CUs wirklich kleiner gegenüber Matisse oder Vega 20? Nein sind sie nicht. Aber anscheinend trägt Renoir trotzdem deutlich mehr Transistoren. Eine höhere Packdichte heisst also nicht, dass man mehr Recheneinheiten in der selben Fläche unterbringen kann.

[Berniyh]

Das ist, denk ich, was viele stört. 48CUs für N22 würden auch in Relation zu N21 viel besser ins Bild passen.
Wenn Navi21 relativ klein ist (sagen wir mal grob 400mm2), dann passt das schon, man kann ja die Lücken mit Salvage Lösungen auffüllen.
Aber mal angenommen die 536mm2 stimmen, dann macht die große Lücke tatsächlich nicht so viel Sinn, denn man würde dann ja in einem großen Preisbereich einen riesigen Chip verwenden.
IMO wären dann die Salvage Lösungen unnötig teuer.

Ein Salvage von Navi21 mit 256 Bit und grob 48-60 CU bei 400 mm2 könnte schon gut wirtschaftlich sein, aber auch bei 536 mm2 immer noch? Das ist immerhin ein Drittel mehr Chipfläche.

[jagger]

Warum fängt man eigentlich bei 21 an zu zählen und nicht bei 20... also Navi20?

[Dino-Fossil]

Offenbar verwenden sie kein zero-based numbering (mehr). :ugly:

[davidzo]

Warum fängt man eigentlich bei 21 an zu zählen und nicht bei 20... also Navi20?

Das muss mit Navi10 zusammenhängen, möglicherweise war Navi21 eine HBM-Version von Navi genau wie alle Highend AMD Karten seit Fiji.
In den Launch Zeitraum von Navi10 fällt auch die erste Namensnennung von navi21 und navi23. Da hatte man early silicon von navi10, wusste was man an performance und powerdraw von der Architektur im groben erwarten kann. Wahrscheinlich hatte Navi20 in der Anfangsprojektion einfach eine andere Konfiguration (CUs+Speicher), die für den Markt nun nicht mehr in Frage kam.
Z.B. aufgrund von Nvidias Turing Konkurrenz oder aber den Erfahrungen mit Navi10. Sowas wie z.B. 64CUs und 2 Stacks HBM.

Das ist kein ungewöhnlicher Vorgang, hat nvidia auch schon ein paar male gemacht wie man an GK100 vs GK110 sieht. Wobei ich bei TU102 vermute das man die 100 nur wegen Volta ausgelassen hat, nicht das es mal einen projektierten Tu100 gegeben hätte.
Erste Projektionen wie die Konfiguration des Topmodells aussehen soll werden in der Regel noch vor Projektbeginn, also 3-5 Jahre vor dem Launch angestellt, damit man im groben Simulieren kann was dabei heraus kommt und schon mal gucken kann welcher Prozess dafür in Frage käme. Erst nachher kommen die Architektur-Details dazu. Da weiß man noch nichts über die kompetitive Landschaft und auch prozesstechnisch kann es nochmal zu Änderungen kommen. Es ist also nur logisch dass sich da manchmal noch etwas ändert.

Irgendwann um Navi10 herum muss ja auch die Entscheidung gefallen sein HBM für consumer nicht mehr anzubieten, Navi12 ist ja nur noch eine Verlegenheitslösung geworden da man den bestehenden vertrag mit Apple nicht brechen wollte...

[HOT]

Da würd ich sagen, dass das Chip-Planungen sind, die nicht in die Tat umgesetzt wurden. Würde heißen, Navi 20 war ein Projekt, was es nicht geschafft hat, genau wie Navi 11 und 13 oder Vega 11. Dabei kann N20 auch eine ursprünglich geplanter N10-Refresh gewesen sein.

[LasterCluster]

Die hohe Packdichte von Renoir ist vor allem seiner Low Power Auslegung geschuldet.

Wäre so etwas auch bei N23 möglich? Dann hätte man mit 128 statt 192 bit, fehlendem (vermeintlichem) Wundercache trotzdem noch einen anständigen Größenunterschied zu N22.

[HOT]

Interessanterwiese ist der XBSX SoC eben nicht dichter gepackt. Dennoch ist die GPU deutlich kompakter geworden. Das ist wohl "reducing logic complexity and switching power" von RDNA2

Die hohe Packdichte von Renoir ist vor allem seiner Low Power Auslegung geschuldet. Denn sind die CPU-Cores, Caches und Vega CUs wirklich kleiner gegenüber Matisse oder Vega 20? Nein sind sie nicht. Aber anscheinend trägt Renoir trotzdem deutlich mehr Transistoren. Eine höhere Packdichte heisst also nicht, dass man mehr Recheneinheiten in der selben Fläche unterbringen kann.

Bei den Taktraten? Eher nicht.

[dargo]

Wäre so etwas auch bei N23 möglich? Dann hätte man mit 128 statt 192 bit, fehlendem (vermeintlichem) Wundercache trotzdem noch einen anständigen Größenunterschied zu N22.
Klingt wieder einleuchtend. :) Ich hatte bisher nur auf die CU-Zahl bei N23 geschaut. Apropo 192Bit SI... ich bin echt auf den Stromverbrauch von N22 gespannt sofern das Teil nur mit 192Bit SI (+ dieser Cache) und 40 CUs kommen sollte. Schon die RX 5600XT bleibt unter 150W für die gesamte Karte mit 36 CUs. Man wird dann sicherlich etwas Effizienz mit den höheren Taktraten gegenüber N21 (Gerüchte) opfern. Aber 40 CUs heizen natürlich nicht so stark wie 80 CUs. Spannend... :)

[Gipsel]

Was ich an dem N21 Bild noch immer nicht so richtig glauben kann - der Die (falls es nicht ein Deckel ist) ist sehr rechteckig. Das war zwar VEGA20 auch, aber soweit ich mich erinner, wächst der Verschnitt von den runden Wafer stark an. Deshalb will man eigentlich quadratische Chips belichten, um möglichst wenig vom teuren Wafer am Rand wegwerfen zu müssen.Das ist nie und nimmer ein Heat Spreader. Das ist definitiv ein Die (auch nicht mehrere Dies in einem Mold). Ein IHS sieht aus, wie in diesem Post (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12448348#post12448348) (ist aber natürlich ein Knights Landing von intel; kein Fiji hat jemals so ausgesehen).
Und der Verschnitt ist auch nicht ein soo großes Problem, falls es andere Gründe für das Format gibt. Manchmal ist ein wenig mehr Verschnitt billiger, als ein für den Chip ungünstigeres quadratisches Layout zu generieren.

[HOT]

Hab ja schon vor Seiten gefragt, wie die auf einen HS kommen, da wurd ich wieder bespruckt ;). Die SMD-Bestückung ist im Norden und Süden fast identisch - sind dort die beiden (oder 4) Speichercontroller?

[Gipsel]

Die SMD-Bestückung ist im Norden und Süden fast identisch - sind dort die beiden (oder 4) Speichercontroller?Die Bestückung des Package ist von einem Navi10 drübergelegt (angeblich um die Quelle zu schützen). Genau so ist der Verstärkungsrahmen außen manipuliert.

[HOT]

Ah ok.

[Berniyh]

Letztendlich wurde in dem Bild so viel rumgepfuscht, das könnte praktisch alles gefaked sein.

[amdfanuwe]

Wenn mehrere Chips in TSMCs COWOS zusammengefügt werden, werden die doch je nach COWOS Typ vergossen. Dann sieht man nur noch einen Chip und nicht mehr wieviele darin verarbeitet wurden. Da sagt die Chip Größe nichts mehr aus. Muß man auf Aufklärung des Herstellers warten oder Röntgen, IR Bilder...

[Gipsel]

Wenn mehrere Chips in TSMCs COWOS zusammengefügt werden, werden die doch je nach COWOS Typ vergossen. Dann sieht man nur noch einen Chip und nicht mehr wieviele darin verarbeitet wurden.Na klar sieht man noch die einzelnen Chips. Das Mold-Material hat eine klar andere Farbe als Silizium. Hier mal ein vergossener Vega20 als Beispiel:
https://tpucdn.com/gpu-specs/images/g/848-vega-20-xt.jpg

Oder ein NEC SX Aurora:
https://en.wikichip.org/w/images/e/e0/sx-aurora_chip.png

Die HBM-Chips von nV könnte man hier auch noch aufführen* oder diverse FPGAs. Überall sieht man die Einzeldies. Man will zur Kühlung ja immer noch die Dies direkt kontaktieren und kein Plastik zwischen Die und Kühler haben. Deswegen sieht man von oben natürlich inmmer noch direkt auf die Dies und die Mold-Masse (das ist auch nur fancy Plastik) ist lediglich zwischen den Einzeldies.

* V100:
https://en.wikichip.org/w/images/thumb/a/ad/cowos_ex_v100.jpg/245px-cowos_ex_v100.jpg

[Linmoum]

https://trademarks.justia.com/902/22/amd-infinity-90222772.html

Infinity Cache semi-confirmed? :D

Kudos auf jeden Fall an redgamingtech dafür. Hätte ich nicht gedacht.

[davidzo]

https://trademarks.justia.com/902/22/amd-infinity-90222772.html

Infinity Cache semi-confirmed? :D

Kudos auf jeden Fall an redgamingtech dafür. Hätte ich nicht gedacht.
n1ce one :up:


mal an die RT Profis und Theoretiker hier: Inwieweit sind Ray und path tracing bandbreiten-limitiert, ließe sich da vielleicht ein Bottleneck entfernen oder ist der cache eher für traditionelles Rasterizing von Bedeutung?

[HOT]

Man könnte das auch großräumiger für IA3 sehen, das könnte nicht nur was für die RDNA2/3 GPUs sein sondern auch für Zen4. Ein L4-Stack-Cache für das Zen4 I/O-Die, der die Kohärenz sicher stellen soll über 64 - 80 Kerne?

[Iscaran]

Das Infinity Cache Patent datiert auf den 29.09.2020 bzw. 2.10.2020 - ist also gerade mal ein paar Tage alt !?!

Wäre das nicht ein bisschen Riskant einen Chip quasi komplett fertig zu haben und die Produktion schon laufen zu haben und erst DANN das Patent (für bestimmte Teile) dazu einzureichen ?!?

EDIT: Ach, sorry ist ja nur ein "trademark"...da kann es gut sein, dass AMD einfach die "Gerüchteküche" anheizen will indem man sich einen gutklingenden Trademark sichert.

[dargo]

mal an die RT Profis und Theoretiker hier: Inwieweit sind Ray und path tracing bandbreiten-limitiert, ließe sich da vielleicht ein Bottleneck entfernen oder ist der cache eher für traditionelles Rasterizing von Bedeutung?
RT braucht Bandbreite.

[pixeljetstream]

https://render.otoy.com/octanebench/results.php?v=2020.1.5&sort_by=avg&scale_by=linear&filter=&singleGPU=1&showRTXOff=1

Ampere A100 Deutlich mehr L1 und vor allem L2 Cache und Bandbreite (Kein RT Core) als die Ampere GeForces (mit RT Core, auch ohne RT Core Einsatz liegt die 3090 noch vorne). Bandbreite schadet nie aber man kann es nie auf ein Ding allein reduzieren.

[Dural]

Hat aber auch deutlich mehr FP32 Leistung.

[Complicated]

Dieses 12 min. Video zeigt sehr verdächtig die RDNA2 zugewiesenen Eigenschaften - mit offiziellem AMD Logo :)
Shared L1 Cache und reduzierte Bandbreite auf Architekturebene. Ohne zusätzlich verbauten Cache auf einem Chip.
https://forum.planet3dnow.de/index.php?threads/prognose-board-wie-geht-es-bei-amd-weiter-entwicklungen-strategien-ma%C3%9Fnahmen-die-amd-betreffen-bzw-die-amd-treffen-k%C3%B6nnte.412508/post-5302722

Vorsicht, nehmt euch ein paar Kekse (kein Spekulatius!) zum anschauen dazu ;)

[Der_Korken]

Dieses 12 min. Video zeigt sehr verdächtig die RDNA2 zugewiesenen Eigenschaften - mit offiziellem AMD Logo :)
Shared L1 Cache und reduzierte Bandbreite auf Architekturebene. Ohne zusätzlich verbauten Cache auf einem Chip.
https://forum.planet3dnow.de/index.php?threads/prognose-board-wie-geht-es-bei-amd-weiter-entwicklungen-strategien-ma%C3%9Fnahmen-die-amd-betreffen-bzw-die-amd-treffen-k%C3%B6nnte.412508/post-5302722

Vorsicht, nehmt euch ein paar Kekse (kein Spekulatius!) zum anschauen dazu ;)

Das ist ganz interessant, aber eigentlich eine andere Baustelle als die Frage nach der Speicherbandbreite. Hier wird versucht Bandbreite zwischen L1 und L2 einzusparen, indem redundante Cache-Lines vermieden werden. Das spart natürlich viel Energie innerhalb des Chips ein. Aber daraus folgt noch lange nicht, dass auch Bandbreite zwischen L2 und VRAM gespart wird, denn der L2 ist ja schon shared über alle SEs (und CUs). Um hier die Effektivität des Caches zu erhöhen (ohne ihn zu vergrößern) müsste man schon die Reihenfolge ändern welche Daten wann und wo verarbeitet werden, um die Datenlokalität zu maximieren.

[gedi]

Hmm, die IPC Advantage passt aber so gar nicht zu AMDs offiziellen Aussagen, nämlich 6-8% vielleicht 10%. Mehr wurde nicht versprochen?!

[why_me]

Das ist doch der Vortrag zum gleichnamingen Patent/Pater von vor ein paar Wochen, oder?

[Linmoum]

Hmm, die IPC Advantage passt aber so gar nicht zu AMDs offiziellen Aussagen, nämlich 6-8% vielleicht 10%. Mehr wurde nicht versprochen?!Es wurde gar nichts konkretes versprochen. Nur, dass die IPC höher ausfallen wird.

[gedi]

Natürlich finde ich den Krempel wieder nicht. Aber da stand eindeutig 6-8%

[Der_Korken]

Hmm, die IPC Advantage passt aber so gar nicht zu AMDs offiziellen Aussagen, nämlich 6-8% vielleicht 10%. Mehr wurde nicht versprochen?!

Das ist doch überhaupt nicht zu vergleichen. Wenn AMD etwas zu den GPUs sagt, dann bezieht sich das auf gemessene Performance auf einer real existierenden GPU. Für das Paper haben die aber nicht zwei verschiedene GPUs gebaut mit zwei unterschiedlichen Cache-Designs, um die dann gegeneinander zu benchen. Die haben die GPUs simuliert und ausgerechnet, wieviel % Bandbreite gespart wurde und wieviel weniger Cycles die fiktive GPU gebraucht hat, um die Tests auszuführen.

Interessant ist vielleicht, was dort bei den simulierten Daten steht:
Pro Core (CU):
48KB scratchpad, 32KB register file
16KB L1D, 12KB Texture Cache, 8KB constant cache, 2KB L1I
Shared (L2$):
8x128KB (=1 per memory channel)

Die L2-Werte passen zum L1-Cache eines SAs, während die L1-Werte zum L0-Cache der CUs passen. Wenn AMD das tatsächlich implementiert, wäre die Frage, ob hier innerhalb eines SAs der L0 zwischen den CUs geshared wird oder ob auf SA-Ebene die L1-Caches geshared werden.

Edit: Wobei das Registerfile hier deutlich kleiner als bei GCN und RDNA1-GPUs ist. Da sind es afaik 256KB pro CU, also das achtfache.

[gedi]

Das ist doch überhaupt nicht zu vergleichen. Wenn AMD etwas zu den GPUs sagt, dann bezieht sich das auf gemessene Performance auf einer real existierenden GPU. Für das Paper haben die aber nicht zwei verschiedene GPUs gebaut mit zwei unterschiedlichen Cache-Designs, um die dann gegeneinander zu benchen. Die haben die GPUs simuliert und ausgerechnet, wieviel % Bandbreite gespart wurde und wieviel weniger Cycles die fiktive GPU gebraucht hat, um die Tests auszuführen.

Interessant ist vielleicht, was dort bei den simulierten Daten steht:
Pro Core (CU):
48KB scratchpad, 32KB register file
16KB L1D, 12KB Texture Cache, 8KB constant cache, 2KB L1I
Shared (L2$):
8x128KB (=1 per memory channel)

Die L2-Werte passen zum L1-Cache eines SAs, während die L1-Werte zum L0-Cache der CUs passen. Wenn AMD das tatsächlich implementiert, wäre die Frage, ob hier innerhalb eines SAs der L0 zwischen den CUs geshared wird oder ob auf SA-Ebene die L1-Caches geshared werden.

Natürlich gehe ich hier vom N23 aus, sprich 40CUs an 256-Bit 16GB/s

Wobei die Bandbreite, CUs keine Rolle spielt, denn die IPC ist in dem Fall nicht relativ, sondern ein fester Wert.

[Linmoum]

N23 hat aber 32CU und ein 128bit SI.

[dargo]

Gedi wieder voll in Aktion. :D

[Der_Korken]

Natürlich gehe ich hier vom N23 aus, sprich 40CUs an 256-Bit 16GB/s

Wobei die Bandbreite, CUs keine Rolle spielt, denn die IPC ist in dem Fall nicht relativ, sondern ein fester Wert.

Das spielt keine Rolle. Es wurde keine echte GPU gebencht, sondern nur eine simuliert. Und selbst wenn man es implementiert ist nicht gesagt, dass es in den selben Benches exakt zu den vorhergesagten Performance-Zuwächsen kommt, weil sich in der Praxis die zusätzlich verbaute Logik vielleicht negativ auf den Takt auswirkt und man wieder ein bisschen verliert.

Am Ende haben die auch mal getestet, wie sich die Zuwächse verhalten, wenn man mehr L2/Mem-Partitionen ins Mesh einbaut. Der Vorteil der neuen Strategie ist größer je weniger Speicherbandbreite und L2 verbaut ist (was auch logisch ist). Leider haben sie immer beides gleichzeitig skaliert, nicht L2 und Memory getrennt.

[gedi]

N23 hat aber 32CU und ein 128bit SI.

Und das weißt du woher?

[unl34shed]

Ich gebe den Link morgen wenn es recht ist. Mit dem Handy schwierig

Wenn du schon am suchen bist, von gestern fehlt auch noch das mit der 7x Compute Leistung.

[gedi]

Gedi wieder voll in Aktion. :D

Den Kommentar hättest du dir wieder mal sparen können

@ Korken

Du magst mit allem recht haben, trotzdem danke für die Unterhaltung

[Linmoum]

Und das weißt du woher?Wie irgendjemand bereits gestern zu dir sagte, u.a. aus MacOS Big Sur. Daher braucht man über N21/N22/N23 auch gar nicht mehr spekulieren in der Hinsicht.

[Berniyh]

Wie irgendjemand bereits gestern zu dir sagte, u.a. aus MacOS Big Sur. Daher braucht man über N21/N22/N23 auch gar nicht mehr spekulieren in der Hinsicht.
Die Frage stellt er alle paar Tage wieder. ;)

[gedi]

Wenn du schon am suchen bist, von gestern fehlt auch noch das mit der 7x Compute Leistung.

Auch das habe ich leider nicht mehr gefunden. Vielleicht wurde es auch hier im Forum inclusive eines Bildchens so kommuniziert, ich weiß es wirklich nicht mehr. Twitter kann es aber nicht sein, da ich diesen zweifelhaften Dienst erst relativ kurz in Anspruch nehme. Ich war mir eigentlich relativ sicher das auf THW gelesen zu haben, aber da wurde bez. der Specs alles gelöscht

[unl34shed]

Dann lass doch einfach solche absurden Aussagen ;)


Wenn ich raten dürfte, würde ich auf die Xbox Slides tippen, wo RDNA2 7 Instructions abarbeiten kann, was nichts mit der 7x Compute Leistung zu tun hat. Ansonsten wäre mir mit 7 aktuell nichts zu RDNA bekannt.
E: Misst 7nm natürlich noch :eek: