AMD 3D V-Cache Optimizer Driver Headlines The x86 Platform Enhancements In Linux 6.13

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • carguello2
    Phoronix Member
    • Oct 2023
    • 51

    #11
    Originally posted by darkbasic View Post

    Can you please link the source?
    Phoronix: Many AMD CPU Feature Additions Land In Linux 6.13 The in-development Linux 6.13 kernel is bringing a lot of exciting improvements for AMD Linux customers... https://www.phoronix.com/news/Linux-6.13-AMD-CPU

    Comment

    • Teadrinker
      Junior Member
      • Apr 2023
      • 5

      #12
      I can confirm that on newest CachyOS that already has backported this driver, it does NOT work for my 7900X3D. It exists and can be set to cache, but has no effect. I use MangoHud overlay, and see no difference in core utilization between normal/extra cached cores and no improved FPS at all.
      Yet Gamemode Core Parking utility has been working for me perfectly (parking the normal cores like Windows)...
      Last edited by Teadrinker; 24 November 2024, 06:32 AM.

      Comment

      • intelfx
        Senior Member
        • Jun 2018
        • 1083

        #13
        Originally posted by pWe00Iri3e7Z9lHOX2Qx View Post

        Would be great to know if this is accurate.
        It more-or-less is. Not just this part, but the entire thing with the evolution of the amd-pstate driver so far just screams "we throw random code at the wall and see if it sticks". (Source: I've been following the development of this driver and reading every patch series posted on LKML, even if I didn't do any public reviews because I'm pretty much nobody in the kernel community.)

        Comment

        • Scramblejams
          Junior Member
          • Nov 2021
          • 15

          #14
          Originally posted by kalrish View Post

          I've been doing that by restricting the CPU cores a cgroup's processes may run on; for example, on a 7950X3D, cores 0-7 and 16-23 belong to the CCD with 3D V-Cache. In any case, I agree with you: this new driver would be more useful if it offered the interface you describe.
          Are you familiar with any dynamic ways to do this? I set WINE_CPU_TOPOLOGY="16:0,1,2,3,4,5,6,7,16,17,18,19, 20,21,22,23" but that only covers the games I'm running under Proton, and it doesn't cause the OS to leave those cores alone for other processes so it could be better. Would be nice to have a daemon running that automatically manages all this, understands how to see what I'm running under Steam or Heroic, etc. While I'm wishing for magic, how about something that keeps the kernel quiet on thread #0? :-)
          Last edited by Scramblejams; 25 November 2024, 03:39 PM.

          Comment

          • kalrish
            Phoronix Member
            • Feb 2014
            • 96

            #15
            Originally posted by Scramblejams View Post

            Are you familiar with any dynamic ways to do this? I set WINE_CPU_TOPOLOGY="16:0,1,2,3,4,5,6,7,16,17,18,19, 20,21,22,23" but that only covers the games I'm running under Proton, and it doesn't cause the OS to leave those cores alone for other processes so it could be better. Would be nice to have a daemon running that automatically manages all this, understands how to see what I'm running under Steam or Heroic, etc. While I'm wishing for magic, how about something that keeps the kernel quiet on thread #0? :-)
            The only dynamic solution I've heard about is Feral's GameMode. I've never tried it, but it must be popular if the Arch Linux wiki has an article on it, and it should be good if it's popular.

            If that doesn't work and you don't find another dynamic solution, you could try the following static one.

            Desktop systems managed by systemd create a scope unit for each desktop application you run. You can see them with systemctl status (ran as your user). You could move Steam and Heroic –and hopefully games launched through them– to your CPU's cache cores by overriding the option AllowedCPUs on their respective scope units with​ a couple of user drop-ins​ (usually in ~/.config/systemd/user/) as described in this answer.​ Ideally the kernel would move non-game processes out of the cores used by your game. In that case, you wouldn't have to configure anything else and your applications would still benefit from your CPU's cache cores when you're not playing.

            Otherwise, you could force non-game processes onto your CPU's frequency cores. According to systemd.special(7), systemd puts all system services in system.slice. You could override the option AllowedCPUs on that slice unit with a system drop-in​ (one in /etc/systemd/system/).​ Additionally, you could move user services to your CPU's frequency cores with a similar drop-in on user.slice​. Kernel processes would not be affected and might still run on your CPU's cache cores, though. And, in any case, you'd be wasting half of your CPU while not playing.

            Comment

            Working...
            X