Archiv verlassen und diese Seite im Standarddesign anzeigen : Diskussion zu: AMDs "Navi 21" RDNA2-Grafikchip tritt tatsächlich mit 80 Shader-Cl. an
Leonidas
2020-08-01, 13:48:11
Link zur News:
https://www.3dcenter.org/news/amds-navi-21-rdna2-grafikchip-tritt-tatsaechlich-mit-80-shader-clustern
Abwarten eine 5700XT mampft schon 225w bei humanen Taktraten .
Gleicher Prozess Und damit Nötiger günstigerer betriebspunkt um nicht die 400w zu knacken , keine lineare Skalierung Und schon ist man nurnoch bei +50% , siehe rtx2070 vs 2080ti
Berniyh
2020-08-01, 18:54:28
Wo steht, dass die Infos aus dem Linux Treiber stammen?
Bislang konnte ich nicht sehen wo im Linux Treiber das stehen soll.
Denniss
2020-08-01, 20:39:12
Zu beachten:
Navi 10 -> Navi21
8 -> 4 max backends per se
20 -> 16 max waves per simd
Akkarin
2020-08-01, 20:47:54
Zu beachten:
Navi 10 -> Navi21
8 -> 4 max backends per se
20 -> 16 max waves per simd
Was genau bedeutet das ?
Abwarten eine 5700XT mampft schon 225w bei humanen Taktraten .
Gleicher Prozess Und damit Nötiger günstigerer betriebspunkt um nicht die 400w zu knacken , keine lineare Skalierung Und schon ist man nurnoch bei +50% , siehe rtx2070 vs 2080ti
AMD spricht ja von 50% mehr Energieeffizienz, insofern sollte die doppelte Performance mit 300W schon drinnen sein.
Eldoran
2020-08-02, 00:02:24
Allerdings ist Performance per Watt eine relative Grösse, selbst wenn das tatsächlich den Tests stimmen sollte, ist noch offen, bei welcher Leistung(bzw. Verbrauch) das gilt. Allerdings dürfte ein deutlich grösserer und somit teurer Chip kaum zu höheren Preisen gekauft werden, wenn die Leistung nur unwesentlich über den bisherigen Produkten liegt, einmal von reinen Mobilchips abgesehen.
AMD spricht ja von 50% mehr Energieeffizienz, insofern sollte die doppelte Performance mit 300W schon drinnen sein.
Das kann auch einfach nur günstiger betriebspunkt also geringerer Takt sein .
Allerdings ist Performance per Watt eine relative Grösse, selbst wenn das tatsächlich den Tests stimmen sollte, ist noch offen, bei welcher Leistung(bzw. Verbrauch) das gilt. Allerdings dürfte ein deutlich grösserer und somit teurer Chip kaum zu höheren Preisen gekauft werden, wenn die Leistung nur unwesentlich über den bisherigen Produkten liegt, einmal von reinen Mobilchips abgesehen.
+50% sehe ich nicht als unwesentlich an das sind die Regionen wo man bei NV das 3 fache zu ner 5700xt hinlegt .
Leonidas
2020-08-02, 04:47:07
Wo steht, dass die Infos aus dem Linux Treiber stammen?
Ohh ... mein Fehler. Stammt das nicht alles aus den Linux-Treibern? Diese Auflistungen hatten wir doch vor Monaten schon einmal.
Berniyh
2020-08-02, 09:24:45
Ohh ... mein Fehler. Stammt das nicht alles aus den Linux-Treibern? Diese Auflistungen hatten wir doch vor Monaten schon einmal.
Um ehrlich zu sein, ich hab keine Ahnung. Es sind so viele Zeilen Code in dem Treiber, gut möglich, dass sich die Infos dort irgendwo verstecken, aber ich hab es bislang nicht gesehen und eigentlich hab ich auch die Erfahrung gemacht, dass solche Infos nicht im Treiber hinterlegt werden.
Wahrscheinlich sind derartige Infos eher in den (Binärcode) Firmware Dateien enthalten. Die kann man sicher auch irgendwie auslesen, aber für Navy Flounders und Sienna Cichlid gibt es noch keine derartigen Firmware Dateien für Linux.
(Beim Treiber Code gibt es ein Review und daher eine längere Vorlaufzeit von 2-3 Monaten, die Firmware Dateien kann man relativ kurzfristig aufnehmen lassen, daher gibt es die erst zum Release der Karten oder ggf. auch etwas später. Zu Navi12 haben wir immer noch keine Firmware Dateien.)
Aber vor allem hätte ich erwartet, dass wenn es sich um einen Teil des Linux Treibercodes handeln würde auch ein Link zum entsprechenden Patch oder zum Codeabschnitt gegeben würde, der Post von _rogame ist aber soweit ich sehen kann ohne jegliche Quelle.
Wobei mir natürlich auch klar ist, dass da nicht jeder so sauber arbeitet.
danarcho
2020-08-02, 11:56:16
Zu beachten:
Navi 10 -> Navi21
8 -> 4 max backends per se
20 -> 16 max waves per simd
Was genau bedeutet das ?
Zumindest die max_waves_per_simd bedeuten, dass die maximale occupancy je SIMD jetzt etwas niedriger ist. Da Navi aber im Gegensatz zu GCN ILP (instruction level parallelism) ausnutzen kann, ist so eine hohe occupancy nicht mehr wiklich nötig, bzw. kann sogar schädlich sein, wenn man zu viel cache trashing bekommt. Wahrscheinlich vereinfacht es die CUs auch ein wenig.
Wo steht, dass die Infos aus dem Linux Treiber stammen?
Bislang konnte ich nicht sehen wo im Linux Treiber das stehen soll.
sowas halt (https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c#L1683), aber woher jetzt die GFX10 infos stammen, weiß ich auch nicht wirklich. LLVM (https://github.com/llvm/llvm-project/blob/master/llvm/lib/Target/AMDGPU/Utils/AMDGPUBaseInfo.cpp#L310) und Mesa (https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/amd/common/ac_gpu_info.c#L773) haben teilweise auch entsprechende Einträge.
Leonidas
2020-08-02, 12:36:26
@ Berniyh
Leider finde ich ums verrecken diese ältere Tabelle nicht, die wir hier schon einmal hatten. Sah genauso aus, nur vor-Navi21.
Berniyh
2020-08-02, 12:50:06
sowas halt (https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c#L1683), aber woher jetzt die GFX10 infos stammen, weiß ich auch nicht wirklich. LLVM (https://github.com/llvm/llvm-project/blob/master/llvm/lib/Target/AMDGPU/Utils/AMDGPUBaseInfo.cpp#L310) und Mesa (https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/amd/common/ac_gpu_info.c#L773) haben teilweise auch entsprechende Einträge.
Soweit ich das sehen kann werden für die neueren Karten keine entsprechenden Einträge genannt.
Könnte für die älteren Karten auch was damit zu tun haben, dass der amdgpu Treiber eigentlich für die neueren (ab Vega) Karten erstellt wurde, nur halt auf älteren auch lauffähig ist (ggf. aber die Firmware nicht komplett angepasst wurde).
Prinzipiell scheinen mir das schon (von der Bezeichnung her) Variablen zu sein wie sie im Linux Treiber verwendet werden, aber ich sehe nicht wo man da genaue Zahlen herbekommen sollte. Als Beispiel:
grep -r gs_prim_buffer_depth
amdgpu/amdgpu_atomfirmware.c: adev->gfx.config.gs_prim_buffer_depth =
amdgpu/amdgpu_discovery.c: adev->gfx.config.gs_prim_buffer_depth = le32_to_cpu(gc_info->gc_gsprim_buff_depth);
amdgpu/amdgpu_gfx.h: unsigned gs_prim_buffer_depth;
amdgpu/amdgpu_device.c: adev->gfx.config.gs_prim_buffer_depth = le32_to_cpu(gpu_info_fw->gc_gsprim_buff_depth);
amdgpu/amdgpu_kms.c: dev_info.gs_prim_buffer_depth = adev->gfx.config.gs_prim_buffer_depth;
Das sind alle Erwähnungen von gs_prim_buffer_depth im amdgpu Treiber.
Das wird schlicht aus der Firmware (die meines Wissens noch nicht veröffentlicht wurde) ausgelesen.
Zu max_shader_engines:
grep -r max_shader_engines
amdgpu_atombios.c: adev->gfx.config.max_shader_engines = gfx_info->info.max_shader_engines;
amdgpu_atomfirmware.c: adev->gfx.config.max_shader_engines = gfx_info->v24.max_shader_engines;
amdgpu_discovery.c: adev->gfx.config.max_shader_engines = le32_to_cpu(gc_info->gc_num_se);
amdgpu_gfx.h: unsigned max_shader_engines;
amdgpu_amdkfd.c: cu_info->num_shader_engines = adev->gfx.config.max_shader_engines;
amdgpu_debugfs.c: (se_bank != 0xFFFFFFFF && se_bank >= adev->gfx.config.max_shader_engines)) {
amdgpu_debugfs.c: config[no_regs++] = adev->gfx.config.max_shader_engines;
amdgpu_device.c: adev->gfx.config.max_shader_engines = le32_to_cpu(gpu_info_fw->gc_num_se);
amdgpu_device.c: adev->gfx.config.max_shader_engines,
amdgpu_kms.c: dev_info.num_shader_engines = adev->gfx.config.max_shader_engines;
amdgpu_kms.c: adev->gfx.config.max_shader_engines;
gfx_v10_0.c: for (i = 0; i < adev->gfx.config.max_shader_engines; i++) {
gfx_v10_0.c: num_sc = adev->gfx.config.max_shader_engines * adev->gfx.config.max_sh_per_se *
gfx_v10_0.c: for (i = 0; i < adev->gfx.config.max_shader_engines; i++) {
gfx_v10_0.c: adev->gfx.config.max_shader_engines;
gfx_v10_0.c: for (i = 0; i < adev->gfx.config.max_shader_engines; i++) {
(Die ganzen gfx_v6 bis gfx_9 Einträge habe ich mal gelöscht.)
Die Einträge in _atombios.c und _atomfirmware.c sagen letztendlich, dass das aus der Firmware kommt und dann als gfx.config.max_shader_engines im Treiber weiter verwendet wird. Ansonsten wird das – soweit ich sehen kann – hauptsächlich zur Berechnung von anderen Parametern verwendet.
Fazit: die Benennung der Parameter passt tatsächlich zum Linux Treiber. Allerdings verwendet AMD ja inzwischen zumindest teilweise eine einheitliche Codebase für die Treiber unter Windows und Linux (und vermutlich auch OS X), insofern muss es nicht zwingend der Linux Treiber sein?
Wenn doch, dann ist die einzige Erklärung dafür, die ich hätte, dass er irgendwie Zugang zur Firmware hatte und die dekodieren konnte.
danarcho
2020-08-02, 13:19:57
Wenn doch, dann ist die einzige Erklärung dafür, die ich hätte, dass er irgendwie Zugang zur Firmware hatte und die dekodieren konnte.
Wenn er Zugriff auf eine Karte mit Firmware hat, kann er es auch einfach abfragen. Wäre allerdings wahrscheinlich ein starker Verstoß gegen eine NDA.
Digidi
2020-08-02, 15:44:46
Zu beachten:
Navi 10 -> Navi21
8 -> 4 max backends per se
20 -> 16 max waves per simd
Der Coutdown des backends glaub ich nicht so ganz. Auf 4? Vielleicht auf 6 aber 4 macht keinen Sinn. 64 Rops wären zu wenig für 4k inhalte. Hat die neue Xbox nicht schon 64 rops? Das würde ja hindeuten das es für Navi21 viel zu wenig wären bei fast doppelter shaderanzahl.
Leonidas
2020-08-02, 16:09:25
Das ist so eine Sache. Müssen die ROPs heutzutage noch nach oben skaliert werden? Der Einsatz von MSAA geht arg zurück, ohne MSAA muß es vielleicht nicht mehr so eine hohe ROP-Power sein.
Digidi
2020-08-02, 16:23:08
Das ist so eine Sache. Müssen die ROPs heutzutage noch nach oben skaliert werden? Der Einsatz von MSAA geht arg zurück, ohne MSAA muß es vielleicht nicht mehr so eine hohe ROP-Power sein.
Rops sind auch für die eigentliche Darstellung der Pixel zuständig. Wenn man sieht das Navi21 mit 8 Rasterizern kommt kann das schon einige Pixel erzeugen. Gerade auch wenn man auf 5k oder 8k geht nehmen die Pixel ja auch zu, weshalb man schon alleine Deshalb mehr Rop-Leistung braucht.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.