Hello,

I’m adjusting pp_table settings to get most out of my GPU (RX 6800 XT) and it works but every time I restart PC the changes revert back to default. Any idea how I could make them persist?

For me pp_table is located in /sys/class/drm/card1/device/pp_table

I have to use chmod to be able to make changes:

sudo chmod o+w /sys/class/drm/card1/device/pp_table

Then I’m able to write in changes with upp:

upp -p /sys/class/drm/card1/device/pp_table set --write smc_pptable/SocketPowerLimitAc/0=312 smc_pptable/SocketPowerLimitDc/0=293 smc_pptable/TdcLimit/0=300 smc_pptable/FreqTableSocclk/1=1350 smc_pptable/FreqTableFclk/1=2000 smc_pptable/FclkBoostFreq=2000

And just in case you’re wondering if the effort even makes sene, yes it does:

Max OC with LACT with max default limits (left) vs max OC with edited pp_table (right) in the picture.

  • sniggleboots@lemm.ee
    27·
    3 days ago

    For how long do you need to have been in the Linux space before pp table stops being funny? Because I’m new, and hehehehe

  • vole@lemmy.worldEnglish
    9·
    3 days ago

    I’m not familiar with Radeon PowerPlay, so I don’t know if there is a proper way to solve this, but you should be able to make a systemd system service to run the upp command on boot.

    To do so, I think you can use the following:

    [Unit]
Description=Run my_user_script
After=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target


[Service]
Type=oneshot
ExecStart=upp -p /sys/class/drm/card1/device/pp_table set --write smc_pptable/SocketPowerLimitAc/0=312 smc_pptable/SocketPowerLimitDc/0=293 smc_pptable/TdcLimit/0=300 smc_pptable/FreqTableSocclk/1=1350 smc_pptable/FreqTableFclk/1=2000 smc_pptable/FclkBoostFreq=2000

[Install]
WantedBy=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target

    To configure this service:

    • Save the text (using sudo/root) to a new .service file in /etc/systemd/service. (e.g. /etc/systemd/system/my_update_pp.service)
    • run sudo systemctl daemon-reload to tell systemd to re-read the service files
    • run sudo systemctl restart my_update_pp.service to manually run the service
    • run sudo systemctl enable my_update_pp.service to tell systemd to run your service automatically on boot/wake (WantedBy tells systemd when it should include the unit/service, After, Wants, Requires, and Before help systemd decide the order to run all the units/services)

    Notes

    • Usually for simple systemd services, you can omit After and set WantedBy to just WantedBy=multi-user.target, but if you also need to run upp after sleep or hibernate, then you probably need something more complex. I copied the After and WantedBy from a stackexchange answer, but I haven’t tried using those targets before. You might have to add multi-user.target to the WantedBy list.
    • I don’t actually know if you need to run upp after sleep/hibernate. Running on boot might be sufficient.
    • I think you can skip the chmod if you run upp as sudo/root. Systemd system services run as root by default.
    • I don’t know how safe it is to mess with PowerPlay during boot. My gut says it’s probably fine, but it also seems like something that could cause graphics to not work. Tread carefully.

    References:

    • WereCat@lemmy.worldOP
      2·
      3 days ago

      Thanks a lot. I will look into this.

      Reason why I use chmod is because I cant for the life of me figure out why I can’t just use sudo. Even when I set environment variable for the upp.py it refuses to run it. Even when I directly want to run it via sudo it refuses, I can only run it without sudo for whatever reason… but to overwrite pp_table I need sudo privileges and I’ve been only able to get around with chmod.

      Also I’ve tried to make a script that I will just run and will execute the commands… but I get immediately hard lock and black screen and I need to do hard reset. Same when I try to copy and overwrite the pp_table with sudo priviledges with a pre-modified pp_table.

      So I’m kinda hesitant to now run the commands on runtime, it’s possible it will hardlock during boot. I will give it more though tommorrow.

      edit:

      I just found out how to write the pp_table into VBIOS so I will try flashing modified VBIOS on the card and hope it will work. I’ll leave that for tomorrow though.

  • catloaf@lemm.eeEnglish
    5·
    3 days ago

    Writing udev rules would probably be the best. I’ve never done this so I can’t give you a reference, but I’m sure if you search for info on writing udev rules to set sysfs params you’ll find them. Hopefully the contents of pp_table can be specified in text, not binary.

      • pastaq@lemmy.world
        3·
        2 days ago

        Udev is the best way to add persistent values for pretty much everything in the sysfs. That being said, it can be a bit obtuse when first learning about it. Here are some tips

        udevadm test /sys/path/to/device will tell you if your rule is running and what the state is at each step. You’ll want to look at this before you start so you can see when your rule should run

        udevadm info /sys/path/to/device will tell you what the PROPERTIES of a device are. These are usually set by hwdb files to inform userspace programs about the details of a device.

        udevadm info /sys/path/to/device --attribute-walk will tell you about the ATTRIBUTES of a device and all it’s parent devices. These correspond to the character file endpoints you are setting currently. You’ll want to use these to write your match rules and set the values.

        udevadm monitor can be used to watch for udev events to let you know if you should match on add, change, and/or remove.

        Udev rules work as a cascading match system and they run in numerical and directory order. E.g. /usr/lib/udev/rules/60-keyboard.rules will run before /etc/udev/rules.d/62-keyboard.rules but after /etc/udev/rules.d/60-keyboard.rules

        For user defined rules you will want to put them in /etc/udev/rules.d/ and keep in mind any state that needs to be set before or after your rule.

        Matching happens with == or !=, setting attributes is done with =, +=, -=, or :=. := is really cool because you can use that to block changes from downstream rules. E.g. MODE:="666" will make the matched attribute r/w from unprivileged users, even if a later rule tries to set 400.

        Udev rules will run in order in a file, but each rule must be a single line. Each attribute will also be set in order of the rule if setting multiple attributes in a rule. Multiple rules can be useful if you need to set attributes on multiple levels of a device, or in sibling directories.

        For a complete breakdown of everything, see the udev manual: https://man.archlinux.org/man/udev.7

        I also have a guide on one of my (currently out of tree) drivers that has some examples. https://github.com/ShadowBlip/ayn-platform?tab=readme-ov-file#changing-startup-defaults

        Let me know if you have questions.