Anfängerfragen - Linux Neuling? Hier ist der richtige Platz für deine Fragen (2)

  • Ersteller Gelöschtes Mitglied 45455
  • Erstellt am
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich teste derzeit unter Fedora Möglichkeiten, per I2C-Zugriff RDNA4-Spannungen auf den zwei Controllern zu verändern, vielleicht hat man mitbekommen, dass es dafür funktionierende Befehle gibt. Allerdings noch nicht mit endgültiger Sicherheit für alle vier Spannungen, denn ein Datenblatt des neuen MP2868A-Controllers ist noch nicht verfügbar. Es bleibt also Restunsicherheit. Ungünstig, wenn ohne Netz und doppelten Boden mit GPU-Voltages hantiert wird, hab mir schon ein paar Freezes eingefangen.

Um nicht im Blindflug testen zu müssen, ist ein Monitoring der vier relevanten Spannungen unabdingbar. Dies sind sie:

110PL_stock_cut.png

Es gibt für Linux leider nichts, was so umfassend informiert wie HWiNFO, so weit bin ich schon. Die vier Spannungen brauche ich live, dann wird es womöglich bald ein Tool für detailliertes VID-Tuning von RDNA 4 geben. Wer hat eine Idee oder fühlt sich berufen, einen Minimonitor für die vier Werte zu bauen?
 
Zuletzt bearbeitet:
Kann das OCCT nicht anzeigen?
Hatte das mal kurz installiert, weiß aber nicht mehr ob es so detailliert ist im monitoring.
 
Leider nur GFX, wie es aussieht.

1748117399148.png
 
@ShirKhan eventuell musst du gar kein Programm schreiben (lassen).
Wenn die Werte mit dem neuen Kernel irgendwo in den Tiefen von zum Bsp. /proc stehen kannst du mit "watch cat /pfad/zur/Angabe" das bequem tracken.

Ich hab mir vor einiger Zeit das hier aus dem Arch Wiki ausgeliehen um meiner CPU am Tower auf die Finger zu schauen :

Code: 
watch cat /sys/devices/system/cpu/cpu[0-9]*/cpufreq/scaling_cur_freq

Zum Kernel:
Ich bin die letzten Monate an meinen ARM Systemen am bauen und hatte gehofft das einiges mit 6.15 in den Linux Kernel kommt.
Bspw. HDMI out am Orange Pi 5plus für den vendor Kernel -veraltet und verbastelt- kein Problem, für normale Kernel Releases noch eine Hürde.
Die Community macht hier mangels Unterstützung durch Rockchip alles selbst.

Hat sich wohl auf 6.16 verschoben, mal schauen :).
gitlab.collabora.com

mainline-status.md · main · hardware-enablement / Rockchip upstream enablement efforts / Notes for Rockchip 3588 · GitLab

Collabora GitLab
gitlab.collabora.com gitlab.collabora.com
 
www.pcgameshardware.de

Linux-Spieler feiern: AMD geht all-in beim Radeon-Grafiktreiber

AMD geht bei seinem Grafiktreiber für Linux jetzt all-in und setzt ganz auf RADV, den Vulkan-Treiber aus dem freien Mesa-Grafikstack.
www.pcgameshardware.de www.pcgameshardware.de

www.pcgameshardware.de

CachyOS: Gaming-Distribution mit FSR 4 und Proton 10

CachyOS, eine Gaming-Distribution aus Deutschland, adressiert speziell Linux-Spieler. Das Mai-Release kommt mit FSR 4 für RDNA 4 und Proton 10.
www.pcgameshardware.de www.pcgameshardware.de

@L_uk_e

discuss.cachyos.org

How to use FSR4 on RDNA4 GPUs

FSR4 Enablement in Linux You must install Mesa-git sudo pacman -S mesa-git lib32-mesa-git Download amdxcffx64 (attched) or with command 2a. cd ~/Downloads 2b. wget --referer https://support.amd.com...
discuss.cachyos.org discuss.cachyos.org
Beitrag automatisch zusammengeführt:

und wie es Aussieht geht sogar FSR4 auf älteren Karten.
 
Geilo! Später mal genauer nachlesen wenn ich zu Hause bin!
Aber ich nehme mal an, dass ich die .dll nicht in Online Spielen nutzen sollte. Zumindest könnte ich mir das gut vorstellen.
 
Das ist eine gute Frage. Aber ich glaube schon das MP geht. Man ändert ja im Prinzip nichts an den Spieldateien und kopiert nur eine Datei in den System Ordner von Wine ( Windows ). Mehr als kicken wird da nicht passieren wenn doch was sein sollte. Ich wurde schon so oft bei Hunt gekickt wegen irgend was :d Also nicht wegen Cheaten aber damals wegen Reshade ( nur zur Bildverbesserung genutzt ) oder damals auch mal wegen Linux.
Und bei CoD habe ich sogar mit dem DLSS Swapper direkt im Spielordner DLL Dateien getauscht und es ist nichts passiert obwohl das Anticheat noch Agressiver ist.
ich würde auch bald behaupten das die Anticheat Software Online eine Datenbank hat welche Dateien auf der schwarzen Liste stehen.
 
Die fehlenden FP Einheiten werden dann in Software emuliert.
Wie gut oder schlecht dann FSR4 auf einer Vega 56 laufen wird... ich bin gespannt wie es auf meiner 6900XT laufen wird.

Und -ohne Klugscheißen zu wollen- auf Phoronix gab es die News schon länger ;)
 
Zyxx schrieb:
Und -ohne Klugscheißen zu wollen- auf Phoronix gab es die News schon länger ;)
Zum Vergrößern anklicken....
Deshalb bitte nicht aufhören, so was hier zu posten bitte – ich weiß nicht mal, was Phoronix ist.
 
Ok, guter Einwand :)

https://www.phoronix.com/ ist für mich eine meiner Lieblingsanlaufstellen, neben old.reddit.com/r/linux_gaming um immer einigermaßen im Flow zu bleiben.
Dazu noch das Discord von Glorious Eggroll dem Macher der GE Proton Versionen und Nobara... und man stellt fest wie viel da im Hintergrund geklotzt wird :).

Ohh, GE Proton 10-4 ist fertig.
Damit kann man dann FSR 3.1 Spiele auf 4.0 bringen (sofern die Hardware es erlaubt meine ich).
github.com

Release GE-Proton10-4 Released · GloriousEggroll/proton-ge-custom

Proton: Fixed broken cursor issue with DOOM Eternal, DOOM Dark Ages, and Rocket League in winewayland (Thanks OOOOOF123/Etaash) Added a stub implementation for amdxc64.dll to enable FSR4. Use FSR4...
github.com github.com

Zum Vergrößern anklicken....
 
Zuletzt bearbeitet:
hmm, man kann sich nirgendwo einblenden lassen ob FSR4 aktiv ist, aber ich hab gerade mal die gleiche Stelle in Hunt Showdown in der Shooting Range verglichen. Scheint zu klappen.

Bei dem Dune Awakening Benchmark scheint es aber nicht zu funktionieren. Da hat man schon übles ghosting bei Alphaeffekten und Partikeln.
 
Zuletzt bearbeitet:
ShirKhan schrieb:
Ich teste derzeit unter Fedora Möglichkeiten, per I2C-Zugriff RDNA4-Spannungen auf den zwei Controllern zu verändern, vielleicht hat man mitbekommen, dass es dafür funktionierende Befehle gibt. Allerdings noch nicht mit endgültiger Sicherheit für alle vier Spannungen, denn ein Datenblatt des neuen MP2868A-Controllers ist noch nicht verfügbar. Es bleibt also Restunsicherheit. Ungünstig, wenn ohne Netz und doppelten Boden mit GPU-Voltages hantiert wird, hab mir schon ein paar Freezes eingefangen.

Um nicht im Blindflug testen zu müssen, ist ein Monitoring der vier relevanten Spannungen unabdingbar. Dies sind sie:

Anhang anzeigen 1111492

Es gibt für Linux leider nichts, was so umfassend informiert wie HWiNFO, so weit bin ich schon. Die vier Spannungen brauche ich live, dann wird es womöglich bald ein Tool für detailliertes VID-Tuning von RDNA 4 geben. Wer hat eine Idee oder fühlt sich berufen, einen Minimonitor für die vier Werte zu bauen?
Zum Vergrößern anklicken....
Zyxx schrieb:
@ShirKhan eventuell musst du gar kein Programm schreiben (lassen).
Wenn die Werte mit dem neuen Kernel irgendwo in den Tiefen von zum Bsp. /proc stehen kannst du mit "watch cat /pfad/zur/Angabe" das bequem tracken.
Zum Vergrößern anklicken....
In Textform Über das hwmon interface (/sys/class/drm/card*/device/hwmon/hwmon1/in*) gibt es leider nur vddgfx (und für ältere? APUs die Northbridge Spannung).
Das wird auch der Grund sein, warum OCCT nur diese Spannung anzeigt.

Wenn ich das richtig sehe und "RDNA4" smu v14_0_2 verwendet sollten über gpu_metrics 3 Spannungen verfügbar sein. Keine Ahnung, ob voltage_mem dabei jetzt VDDIO, VDDCI_MEM oder was ganz anderes ist. Bei mir (RX 6900 XT) sind es wohl gerade 1250 mV.

@ShirKhan du könntest hier ja mal eine Kopie von /sys/class/drm/card1/device/gpu_metrics hochladen (card1 könnte je nach Distro auch z.B. card0 sein).
 
Danke!

YCbCr schrieb:
Wenn ich das richtig sehe und "RDNA4" smu v14_0_2 verwendet sollten über gpu_metrics 3 Spannungen verfügbar sein. Keine Ahnung, ob voltage_mem dabei jetzt VDDIO, VDDCI_MEM oder was ganz anderes ist. Bei mir (RX 6900 XT) sind es wohl gerade 1250 mV.
Zum Vergrößern anklicken....

Das kann eigentlich nur VDDIO sein, also die Memory-Voltage. RDNA 2, 3 und 4 sind alle auf GDDR6, da wird sich spannungsseitig nicht viel getan haben.

YCbCr schrieb:
eine Kopie von /sys/class/drm/card1/device/gpu_metrics hochladen (card1 könnte je nach Distro auch z.B. card0 sein).
Zum Vergrößern anklicken....

Code: 
hexdump -C /sys/class/drm/card1/device/gpu_metrics
00000000  78 00 01 03 1e 00 20 00  37 00 20 00 21 00 24 00  |x..... .7. .!.$.|
00000010  01 00 01 00 00 00 13 00  00 00 00 00 00 00 00 00  |................|
00000020  ef c1 82 82 26 00 00 00  12 00 ff ff 76 02 19 00  |....&.......v...|
00000030  19 00 00 00 00 00 12 00  00 05 60 00 19 00 19 00  |..........`.....|
00000040  19 00 19 00 00 00 00 00  00 00 10 00 19 00 ff ff  |................|
00000050  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000060  ff ff ff ff ff ff ff ff  32 03 9e 00 e2 04 ff ff  |........2.......|
00000070  00 00 00 00 00 00 00 00                           |........|
00000078

So? card0 findet nichts.
 
Zuletzt bearbeitet:
ShirKhan schrieb:
Code: 
hexdump -C /sys/class/drm/card1/device/gpu_metrics
00000000  78 00 01 03 1e 00 20 00  37 00 20 00 21 00 24 00  |x..... .7. .!.$.|
00000010  01 00 01 00 00 00 13 00  00 00 00 00 00 00 00 00  |................|
00000020  ef c1 82 82 26 00 00 00  12 00 ff ff 76 02 19 00  |....&.......v...|
00000030  19 00 00 00 00 00 12 00  00 05 60 00 19 00 19 00  |..........`.....|
00000040  19 00 19 00 00 00 00 00  00 00 10 00 19 00 ff ff  |................|
00000050  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000060  ff ff ff ff ff ff ff ff  32 03 9e 00 e2 04 ff ff  |........2.......|
00000070  00 00 00 00 00 00 00 00                           |........|
00000078

So? card0 findet nichts.
Zum Vergrößern anklicken....
Jup, das ist definitiv ein gpu_metrics_v1_3 Struct. voltage_soc wäre 818 mV, voltage_gpu 158 mV und voltage_mem 1250 mV. Das scheint ja ungefähr zu deinem Screenshot oben zu passen.

ShirKhan schrieb:
Das kann eigentlich nur VDDIO sein, also die Memory-Voltage.
Zum Vergrößern anklicken....
Das bestätigt sich auch im Treiber-Code:
gpu_metrics->voltage_mem = metrics->AvgVoltage[SVI_PLANE_VDDIO_MEM];

In dem SVI_PLANE_e enum gibt es auch einen SVI_PLANE_VDDCI_MEM Member, der allerdings im kompletten Kernel nicht verwendet wird. Diese Spannung bekommt man also (ohne Patch) leider nicht vom Kerneltreiber.

ShirKhan schrieb:
Wer hat eine Idee oder fühlt sich berufen, einen Minimonitor für die vier Werte zu bauen?
Zum Vergrößern anklicken....
Bevor ich mich an die Arbeit mache: Eine kurze Recherche nach Tools, die die gpu_metrics im sysfs interpretieren können hat amdgpu_top zutage gefördert.
1749064041451.png

Das sieht allgemein recht praktisch aus (wertet viele Daten aus, die in anderen „sysfs UIs“ fehlen) und kommt mit CLI, TUI und GUI. Für Fedora gibt er fertige rpms oder AppImages.
 
Ja super, vielen Dank! amdgpu_top habe ich wohl installiert, bisher aber nur selektiv per CLI angesprochen.

YCbCr schrieb:
In dem SVI_PLANE_e enum gibt es auch einen SVI_PLANE_VDDCI_MEM Member, der allerdings im kompletten Kernel nicht verwendet wird. Diese Spannung bekommt man also (ohne Patch) leider nicht vom Kerneltreiber.
Zum Vergrößern anklicken....

Hm. Bedeutet das, man muss auf einen neuen Kernel warten, der das (vielleicht) unterstützt? Oder gibt es für Kenner Möglichkeiten, da selbst Hand anzulegen?
 
Zuletzt bearbeitet:
ShirKhan schrieb:
Hm. Bedeutet das, man muss auf einen neuen Kernel warten, der das (vielleicht) unterstützt?
Zum Vergrößern anklicken....
Von alleine wird da vermutlich nichts kommen. Der richtige Ort für einen Feature Request wäre https://gitlab.freedesktop.org/drm/amd.
ShirKhan schrieb:
Oder gibt es für Kenner Möglichkeiten, da selbst Hand anzulegen?
Zum Vergrößern anklicken....
Sogar für Nicht-Kenner (mich):
Code: 
From 2fae3800b096916ce159f26223a8252e5fa6b70a Mon Sep 17 00:00:00 2001
From: YCbCr <>
Date: Thu, 5 Jun 2025 18:54:11 +0200
Subject: [PATCH] drm/amd/pm: Export VDDCI_MEM via gpu_metrics on smu v14.0.2/3

---
 drivers/gpu/drm/amd/include/kgd_pp_interface.h       | 3 +--
 drivers/gpu/drm/amd/pm/swsmu/smu14/smu_v14_0_2_ppt.c | 1 +
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/include/kgd_pp_interface.h b/drivers/gpu/drm/amd/include/kgd_pp_interface.h
index 21dc956b5..90e91dd3d 100644
--- a/drivers/gpu/drm/amd/include/kgd_pp_interface.h
+++ b/drivers/gpu/drm/amd/include/kgd_pp_interface.h
@@ -758,8 +758,7 @@ struct gpu_metrics_v1_3 {
     uint16_t            voltage_soc;
     uint16_t            voltage_gfx;
     uint16_t            voltage_mem;
-
-    uint16_t            padding1;
+    uint16_t            voltage_ci_mem;
 
     /* Throttle status (ASIC independent) */
     uint64_t            indep_throttle_status;
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu14/smu_v14_0_2_ppt.c b/drivers/gpu/drm/amd/pm/swsmu/smu14/smu_v14_0_2_ppt.c
index 82c2db972..4799c50e2 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu14/smu_v14_0_2_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu14/smu_v14_0_2_ppt.c
@@ -2247,6 +2247,7 @@ static ssize_t smu_v14_0_2_get_gpu_metrics(struct smu_context *smu,
     gpu_metrics->voltage_gfx = metrics->AvgVoltage[SVI_PLANE_VDD_GFX];
     gpu_metrics->voltage_soc = metrics->AvgVoltage[SVI_PLANE_VDD_SOC];
     gpu_metrics->voltage_mem = metrics->AvgVoltage[SVI_PLANE_VDDIO_MEM];
+    gpu_metrics->voltage_ci_mem = metrics->AvgVoltage[SVI_PLANE_VDDCI_MEM];
 
     *table = (void *)gpu_metrics;
 
--
2.49.0

AvgVoltage[] ist SVI_PLANE_COUNT groß, sollte also auch für SVI_PLANE_VDDCI_MEM einen Wert enthalten. Praktischerweise gibt es in struct gpu_metrics_v1_3 direkt nach den anderen Spannungen 2 Byte Padding, gerade genug um noch einen Wert rein zu quetschen.

Anleitung zum Kernel patchen für Fedora: https://docs.fedoraproject.org/de/quick-docs/kernel-build-custom/

Selbst testen konnte ich mangels passender Hardware leider nicht.

Und dann noch je ein Patch für amdgpu_top:
Code: 
From cd1b0da4e832a689857950b24c13624495227a84 Mon Sep 17 00:00:00 2001
From: YCbCr <>
Date: Thu, 5 Jun 2025 20:21:56 +0200
Subject: [PATCH] tui,gui, json: add support for VDDCI_MEM voltage

---
 crates/amdgpu_top_gui/src/gui_gpu_metrics.rs  | 1 +
 crates/amdgpu_top_json/src/output_json.rs     | 1 +
 crates/amdgpu_top_tui/src/view/gpu_metrics.rs | 1 +
 docs/dump.json                                | 2 ++
 docs/sample.json                              | 2 ++
 5 files changed, 7 insertions(+)

diff --git a/crates/amdgpu_top_gui/src/gui_gpu_metrics.rs b/crates/amdgpu_top_gui/src/gui_gpu_metrics.rs
index 637ce44..4b396d9 100644
--- a/crates/amdgpu_top_gui/src/gui_gpu_metrics.rs
+++ b/crates/amdgpu_top_gui/src/gui_gpu_metrics.rs
@@ -55,6 +55,7 @@ impl GuiGpuMetrics for GpuMetrics {
                 (self.get_voltage_soc(), "SoC"),
                 (self.get_voltage_gfx(), "GFX"),
                 (self.get_voltage_mem(), "Mem"),
+                (self.get_voltage_ci_mem(), "CI"),
             ]);
         });
 
diff --git a/crates/amdgpu_top_json/src/output_json.rs b/crates/amdgpu_top_json/src/output_json.rs
index 5354bde..031beaa 100644
--- a/crates/amdgpu_top_json/src/output_json.rs
+++ b/crates/amdgpu_top_json/src/output_json.rs
@@ -349,6 +349,7 @@ impl OutputJson for GpuMetrics {
             ("voltage_gfx", self.get_voltage_gfx()),
             ("voltage_soc", self.get_voltage_soc()),
             ("voltage_mem", self.get_voltage_mem()),
+            ("voltage_ci_mem", self.get_voltage_ci_mem()),
             ("fan_pwm", self.get_fan_pwm()),
             ("pcie_link_width", self.get_pcie_link_width()),
             ("pcie_link_speed", self.get_pcie_link_speed()),
diff --git a/crates/amdgpu_top_tui/src/view/gpu_metrics.rs b/crates/amdgpu_top_tui/src/view/gpu_metrics.rs
index 48f44c5..ae8ce79 100644
--- a/crates/amdgpu_top_tui/src/view/gpu_metrics.rs
+++ b/crates/amdgpu_top_tui/src/view/gpu_metrics.rs
@@ -57,6 +57,7 @@ impl AppTextView {
             (metrics.get_voltage_soc(), "SoC"),
             (metrics.get_voltage_gfx(), "GFX"),
             (metrics.get_voltage_mem(), "Mem"),
+            (metrics.get_voltage_ci_mem(), "CI"),
         ])?;
 
         for (avg, cur, name) in [
diff --git a/docs/dump.json b/docs/dump.json
index 6e59838..999f19d 100644
--- a/docs/dump.json
+++ b/docs/dump.json
@@ -284,6 +284,7 @@
       "temperature_vrsoc": 0,
       "voltage_gfx": null,
       "voltage_mem": null,
+      "voltage_ci_mem": null,
       "voltage_soc": null
     }
   },
@@ -567,6 +568,7 @@
       "temperature_vrsoc": null,
       "voltage_gfx": null,
       "voltage_mem": null,
+      "voltage_ci_mem": null,
       "voltage_soc": null
     }
   }
diff --git a/docs/sample.json b/docs/sample.json
index 523bfff..79bb982 100644
--- a/docs/sample.json
+++ b/docs/sample.json
@@ -1338,6 +1338,7 @@
         "temperature_vrsoc": 0,
         "voltage_gfx": null,
         "voltage_mem": null,
+        "voltage_ci_mem": null,
         "voltage_soc": null
       },
       "xdna_fdinfo": {}
@@ -1941,6 +1942,7 @@
         "temperature_vrsoc": null,
         "voltage_gfx": null,
         "voltage_mem": null,
+        "voltage_ci_mem": null,
         "voltage_soc": null
       },
       "xdna_fdinfo": {}
--
2.49.0
und die dazugehörige Bibliothek libdrm-amdgpu-sys-rs:
Code: 
From 2a6bbbed3521972d0f3318f6045dd7f32636c7cd Mon Sep 17 00:00:00 2001
From: YCbCr <>
Date: Thu, 5 Jun 2025 20:16:21 +0200
Subject: [PATCH] add support for get_voltage_ci_mem

---
 amdgpu/gpu_metrics/metrics_table/mod.rs    | 2 ++
 amdgpu/gpu_metrics/metrics_table/v1.rs     | 7 +++++++
 amdgpu/gpu_metrics/metrics_table/v1_4_5.rs | 1 +
 amdgpu/gpu_metrics/metrics_table/v2_v3.rs  | 2 ++
 amdgpu/gpu_metrics/mod.rs                  | 1 +
 bindings/drm.rs                            | 6 +++---
 bindings/dyn_drm_amdgpu.rs                 | 6 +++---
 wrapper/wrapper_gpu_metrics.h              | 3 +--
 8 files changed, 20 insertions(+), 8 deletions(-)

diff --git a/amdgpu/gpu_metrics/metrics_table/mod.rs b/amdgpu/gpu_metrics/metrics_table/mod.rs
index c7dc649..9722931 100644
--- a/amdgpu/gpu_metrics/metrics_table/mod.rs
+++ b/amdgpu/gpu_metrics/metrics_table/mod.rs
@@ -252,6 +252,8 @@ pub trait MetricsInfo {
     fn get_voltage_gfx(&self) -> Option<u16>;
     /// mV
     fn get_voltage_mem(&self) -> Option<u16>;
+    /// mV
+    fn get_voltage_ci_mem(&self) -> Option<u16>;
 
     /// Average Temperature (unit: centi-Celsius)
     fn get_average_temperature_gfx(&self) -> Option<u16>;
diff --git a/amdgpu/gpu_metrics/metrics_table/v1.rs b/amdgpu/gpu_metrics/metrics_table/v1.rs
index 1c51bc6..ea05d60 100644
--- a/amdgpu/gpu_metrics/metrics_table/v1.rs
+++ b/amdgpu/gpu_metrics/metrics_table/v1.rs
@@ -220,6 +220,7 @@ impl MetricsInfo for gpu_metrics_v1_0 {
     fn get_voltage_soc(&self) -> Option<u16> { None }
     fn get_voltage_gfx(&self) -> Option<u16> { None }
     fn get_voltage_mem(&self) -> Option<u16> { None }
+    fn get_voltage_ci_mem(&self) -> Option<u16> { None }
     fn get_indep_throttle_status(&self) -> Option<u64> { None }
 }
 
@@ -241,6 +242,7 @@ impl MetricsInfo for gpu_metrics_v1_1 {
     fn get_voltage_soc(&self) -> Option<u16> { None }
     fn get_voltage_gfx(&self) -> Option<u16> { None }
     fn get_voltage_mem(&self) -> Option<u16> { None }
+    fn get_voltage_ci_mem(&self) -> Option<u16> { None }
     fn get_indep_throttle_status(&self) -> Option<u64> { None }
 }
 
@@ -262,6 +264,7 @@ impl MetricsInfo for gpu_metrics_v1_2 {
     fn get_voltage_soc(&self) -> Option<u16> { None }
     fn get_voltage_gfx(&self) -> Option<u16> { None }
     fn get_voltage_mem(&self) -> Option<u16> { None }
+    fn get_voltage_ci_mem(&self) -> Option<u16> { None }
     fn get_indep_throttle_status(&self) -> Option<u64> { None }
 }
 
@@ -292,6 +295,10 @@ impl MetricsInfo for gpu_metrics_v1_3 {
         Some(self.voltage_mem)
     }
 
+    fn get_voltage_ci_mem(&self) -> Option<u16> {
+        Some(self.voltage_ci_mem)
+    }
+
     fn get_indep_throttle_status(&self) -> Option<u64> {
         if self.indep_throttle_status == u64::MAX {
             None
diff --git a/amdgpu/gpu_metrics/metrics_table/v1_4_5.rs b/amdgpu/gpu_metrics/metrics_table/v1_4_5.rs
index 970d345..d7fd027 100644
--- a/amdgpu/gpu_metrics/metrics_table/v1_4_5.rs
+++ b/amdgpu/gpu_metrics/metrics_table/v1_4_5.rs
@@ -186,6 +186,7 @@ macro_rules! v1_4_v1_5_impl {
         fn get_voltage_soc(&self) -> Option<u16> { None }
         fn get_voltage_gfx(&self) -> Option<u16> { None }
         fn get_voltage_mem(&self) -> Option<u16> { None }
+        fn get_voltage_ci_mem(&self) -> Option<u16> { None }
         fn get_current_fan_speed(&self) -> Option<u16> { None }
         fn get_fan_pwm(&self) -> Option<u16> { None }
         fn get_throttle_residency_prochot(&self) -> Option<u32> { None }
diff --git a/amdgpu/gpu_metrics/metrics_table/v2_v3.rs b/amdgpu/gpu_metrics/metrics_table/v2_v3.rs
index 1aec127..4ceaaec 100644
--- a/amdgpu/gpu_metrics/metrics_table/v2_v3.rs
+++ b/amdgpu/gpu_metrics/metrics_table/v2_v3.rs
@@ -184,6 +184,7 @@ macro_rules! v2_impl {
         fn get_voltage_soc(&self) -> Option<u16> { None }
         fn get_voltage_gfx(&self) -> Option<u16> { None }
         fn get_voltage_mem(&self) -> Option<u16> { None }
+        fn get_voltage_ci_mem(&self) -> Option<u16> { None }
         fn get_gfxclk_lock_status(&self) -> Option<u32> { None }
         fn get_current_socket_power(&self) -> Option<u16> { None }
         fn get_all_instances_current_gfxclk(&self) -> Option<[u16; MAX_GFX_CLKS as usize]> { None }
@@ -629,6 +630,7 @@ macro_rules! v3_impl {
         fn get_voltage_soc(&self) -> Option<u16> { None }
         fn get_voltage_gfx(&self) -> Option<u16> { None }
         fn get_voltage_mem(&self) -> Option<u16> { None }
+        fn get_voltage_ci_mem(&self) -> Option<u16> { None }
         fn get_current_fan_speed(&self) -> Option<u16> { None }
         fn get_fan_pwm(&self) -> Option<u16> { None }
         fn get_throttle_status(&self) -> Option<u32> { None }
diff --git a/amdgpu/gpu_metrics/mod.rs b/amdgpu/gpu_metrics/mod.rs
index d7f7f47..1d08d22 100644
--- a/amdgpu/gpu_metrics/mod.rs
+++ b/amdgpu/gpu_metrics/mod.rs
@@ -151,6 +151,7 @@ impl MetricsInfo for GpuMetrics {
     impl_metrics!(get_voltage_soc, Option<u16>);
     impl_metrics!(get_voltage_gfx, Option<u16>);
     impl_metrics!(get_voltage_mem, Option<u16>);
+    impl_metrics!(get_voltage_ci_mem, Option<u16>);
     impl_metrics!(get_average_temperature_gfx, Option<u16>);
     impl_metrics!(get_average_temperature_soc, Option<u16>);
     impl_metrics!(get_average_temperature_core, Option<Vec<u16>>);
diff --git a/bindings/drm.rs b/bindings/drm.rs
index 112ef23..f59d450 100644
--- a/bindings/drm.rs
+++ b/bindings/drm.rs
@@ -20383,7 +20383,7 @@ pub struct gpu_metrics_v1_3 {
     pub voltage_soc: u16,
     pub voltage_gfx: u16,
     pub voltage_mem: u16,
-    pub padding1: u16,
+    pub voltage_ci_mem: u16,
     pub indep_throttle_status: u64,
 }
 #[allow(clippy::unnecessary_operation, clippy::identity_op)]
@@ -20468,8 +20468,8 @@ const _: () = {
         [::core::mem::offset_of!(gpu_metrics_v1_3, voltage_gfx) - 106usize];
     ["Offset of field: gpu_metrics_v1_3::voltage_mem"]
         [::core::mem::offset_of!(gpu_metrics_v1_3, voltage_mem) - 108usize];
-    ["Offset of field: gpu_metrics_v1_3::padding1"]
-        [::core::mem::offset_of!(gpu_metrics_v1_3, padding1) - 110usize];
+    ["Offset of field: gpu_metrics_v1_3::voltage_ci_mem"]
+        [::core::mem::offset_of!(gpu_metrics_v1_3, voltage_ci_mem) - 110usize];
     ["Offset of field: gpu_metrics_v1_3::indep_throttle_status"]
         [::core::mem::offset_of!(gpu_metrics_v1_3, indep_throttle_status) - 112usize];
 };
diff --git a/bindings/dyn_drm_amdgpu.rs b/bindings/dyn_drm_amdgpu.rs
index b9fa3f8..6ddfa91 100644
--- a/bindings/dyn_drm_amdgpu.rs
+++ b/bindings/dyn_drm_amdgpu.rs
@@ -17050,7 +17050,7 @@ pub struct gpu_metrics_v1_3 {
     pub voltage_soc: u16,
     pub voltage_gfx: u16,
     pub voltage_mem: u16,
-    pub padding1: u16,
+    pub voltage_ci_mem: u16,
     pub indep_throttle_status: u64,
 }
 #[allow(clippy::unnecessary_operation, clippy::identity_op)]
@@ -17135,8 +17135,8 @@ const _: () = {
         [::core::mem::offset_of!(gpu_metrics_v1_3, voltage_gfx) - 106usize];
     ["Offset of field: gpu_metrics_v1_3::voltage_mem"]
         [::core::mem::offset_of!(gpu_metrics_v1_3, voltage_mem) - 108usize];
-    ["Offset of field: gpu_metrics_v1_3::padding1"]
-        [::core::mem::offset_of!(gpu_metrics_v1_3, padding1) - 110usize];
+    ["Offset of field: gpu_metrics_v1_3::voltage_ci_mem"]
+        [::core::mem::offset_of!(gpu_metrics_v1_3, voltage_ci_mem) - 110usize];
     ["Offset of field: gpu_metrics_v1_3::indep_throttle_status"]
         [::core::mem::offset_of!(gpu_metrics_v1_3, indep_throttle_status) - 112usize];
 };
diff --git a/wrapper/wrapper_gpu_metrics.h b/wrapper/wrapper_gpu_metrics.h
index 18c43f0..22ec2d2 100644
--- a/wrapper/wrapper_gpu_metrics.h
+++ b/wrapper/wrapper_gpu_metrics.h
@@ -278,8 +278,7 @@ struct gpu_metrics_v1_3 {
     uint16_t            voltage_soc;
     uint16_t            voltage_gfx;
     uint16_t            voltage_mem;
-
-    uint16_t            padding1;
+    uint16_t            voltage_ci_mem;
 
     /* Throttle status (ASIC independent) */
     uint64_t            indep_throttle_status;
--
2.49.0

Warnung vorweg: Rust ist definitiv nicht mein Metier. Ich habe nur nach „voltage_mem“ gesucht und dann bereits vorhandenen Code kopiert und angepasst.
Es lässt sich zumindest kompilieren und starten. Mir wird dann als Wert „N/A“ angezeigt, was entweder heißt, dass das Programm schlau genug ist, zu erkennen dass 0xFFFF nicht für 65,535 V VDDCI steht :fresse: (andere GPUs, für die der Treiber das gleiche Struct verwendet aber gar keine Spannungen von der smu bekommt, z.B. Arcturus und Aldebaran benutzen dort den gleichen Platzhalter, würde also Sinn machen), oder irgendwas nicht hingehauen hat.

Um die lokal gepatchte Version von libdrm-amdgpu-sys-rs zu verwenden habe ich mir das Repo ins crates Verzeichnis von amdgpu_top geklont, den in in crates/libamdgpu_top/Cargo.toml in Zeile 19 als rev genannten Commit ausgecheckt und dann die Zeile zu libdrm_amdgpu_sys = { version = "0.8.6", path = "../libdrm-amdgpu-sys-rs", default-features = false } geändert. Keine Ahnung, ob das auch eleganter geht, aber es hat jedenfalls funktioniert…
 
Herzlichen Dank! Ich kapier - nix. Was du gepostet hast, werd ich nächste Woche erst ChatGPT zu fressen geben und dann dem kleinen Team, mit dem ich an dem Thema arbeiten darf. Nochmals danke.
 
Zuletzt bearbeitet:
Nicht chatgpt... damit eskaliert das alles.
 
Es ist anstrengend, ja. An der kurzen Leine gehalten, kommen wir aber klar.
 
Zuletzt bearbeitet:
@YCbCr erste Analyse: vielversprechender Ansatz, wird verfolgt. (y)
 
Hmpf... wenn Rockstar mal GTA V wieder vollumfänglich auf Linux supporten würde (Online) könnte ich endlich Win11 in die Schublade des Vergessens schieben. :shake:
 
Bei mir haben sie durch die Aktion einen GTA VI Kunden verloren. Kann dich voll und ganz verstehen.
Windows kommt mir nicht mehr auf die Platte, weswegen es wohl heißt: Zyxxies müssen draußen bleiben :(.
 
Ist halt eines der wenigen Games was so ziemlich alle Kumpels zocken... das würde mir stark fehlen. Deshalb ist es eben der einzige Anker den Windows bei mir noch hat... Ich kapiers einfach nicht. Den Kopierschutz gibts auch unter Linux, es ging ja früher mal bis die den Stecker gezogen haben.

Völlig unverständlich. :wall:
 
Mit Linux gibt es zu viele Cheater 🙈 :fresse:
Ist doch immer deren Ausrede.
 
Wetten, den ganzen Cheat-Kram gibts nur für Windows? :fresse2:
Zielgruppe und so... :d
 
Ich denke die Spieleschmieden, respektive deren Entscheider haben Angst davor was passiert wenn sie die bequeme Lösung "Kernel Level Anticheat" nicht mehr nutzen können.
Nicht auszudenken wenn man wieder Menschen einstellen müsste welche das Gameplay analysieren und sich mit der Community und deren Reports beschäftigen.
Kostet doch Geld.

Dann lieber der Logik "da läuft kein Anti Cheat, das müssen Cheater sein" folgen und zack hat man ein ruhiges Gewissen / Geld gespart.

Mal schauen was nach Kernel Level Anticheat kommt, so gehyped wie KI momentan ist arbeitet da bestimmt ein Unternehmen dran.
Und zufällig funktioniert das dann nur wenn man den Microsoft Store nebst Copilot installiert hat :fresse2:.
 
Ich habe gestern noch mal CachyOS neben WIndows installiert.
Lief auf anhieb mit der RTX 5080. Performance ist erwartungsgemäß schlechter gegenüber Windows.
Aber was mir bei Hunt Showdown aufgefallen ist. Ich habe ca. 20 Prozent weniger CPU Auslastung im Spiel. Kann doch nicht sein das Windows so viel mehr braucht für das Spiel. Es läuft auch kein anderer Prozess im Hintergrund der da an der CPU Nukkelt. Es ist einfach das Spiel was mehr braucht. Wahnsinn.
 
Anmelden, um zu antworten.

Ähnliche Themen

CrsRoKk
Neuer PC-Unterbau bis 1500,00€
2
Antworten
33
Aufrufe
2K
zog88
zog88
M
[User-Review] Synology DP320 ActiveProtect
Antworten
1
Aufrufe
721
maxblank
M
O
pfSense Hardware - Empfehlungen / Kaufberatung / Erfahrungen
Antworten
0
Aufrufe
2K
OsiMosi
O
Daniel N
[User-Review] MasterLiquid 360 ION
Antworten
5
Aufrufe
619
Daniel N
Daniel N
Burnz84
[User-Review] QNAP 432X 4G mit 8TB Toschiba N300 HDDs
Antworten
3
Aufrufe
1K
Burnz84
Burnz84
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh