[RESPONDED] DRI_PRIME not correctly using the dGPU in some games

Yeah, this was my thought as well, but when I force the usage of the iGPU only with DRI_PRIME=0! (after verifying GPU0 is the iGPU), Remnant II still runs with 1FPS. I think this is something specific to this game, as it seems poorly optimized in general. I’m not too worried about it, but would be curious if anyone has further explanation on this.

Hat tip @John_Obscurant. Was able to locate a clear, defined definition here. Same link, but included the page link this time.

TIL. :slight_smile: I’ll add the link into the docs as a FYI for those interested or needing it.

4 Likes

Hey gang, I’m still having trouble here. I just got my FW 16 from batch 4, and it looks like NVTOP reports the iGPU is working at 100% while the dGPU reports minimal usage when I play games with DRI_PRIME=1 or DRI_PRIME=1!.

My screen shot is taken after I closed a Steam game called Crab Champions, which showed the iGPU at 100% while the dGPU was low. The process names both Graphic and Compute on the GPU in position 0, but it should be 1. This is the command line I’m running from Steam for this game: DRI_PRIME=1! DXVK_FILTER_DEVICE_NAME="AMD Radeon RX 7700S (RADV NAVI33)" mangohud %command%

Additional info would be here:

            -```````````                   bhibb@bframework
          `-+/------------.`               ----------------
       .---:mNo---------------.            OS: Solus resilience 4.5 x86_64
     .-----yMMMy:---------------.          Host: Laptop 16 (AMD Ryzen 7040 Series) (AJ)
   `------oMMMMMm/----------------`        Kernel: 6.6.21-280.current
  .------/MMMMMMMN+----------------.       Uptime: 4 hours, 55 mins
 .------/NMMMMMMMMm-+/--------------.      Packages: 1341 (eopkg), 47 (flatpak)
`------/NMMMMMMMMMN-:mh/-------------`     Shell: fish 3.7.0
.-----/NMMMMMMMMMMM:-+MMd//oso/:-----.     Display (eDP-2): 2560x1600 @ 60Hz
-----/NMMMMMMMMMMMM+--mMMMh::smMmyo:--     DE: KDE Plasma 5.27.10
----+NMMMMMMMMMMMMMo--yMMMMNo-:yMMMMd/.    WM: KWin (Wayland)
.--oMMMMMMMMMMMMMMMy--yMMMMMMh:-yMMMy-`    WM Theme: Breeze
`-sMMMMMMMMMMMMMMMMh--dMMMMMMMd:/Ny+y.     Theme: Breeze (SolusDark) [QT], Breeze [GTK2/3]
`-/+osyhhdmmNNMMMMMm-/MMMMMMMmh+/ohm+      Icons: breeze-dark [QT], breeze-dark [GTK2/3/4]
  .------------:://+-/++++++oshddys:       Font: Noto Sans (10pt) [QT], Noto Sans (10pt) [GTK2/3/4]
   -hhhhyyyyyyyyyyyhhhhddddhysssso-        Cursor: breeze (24px)
    `:ossssssyysssssssssssssssso:`         Terminal: konsole 23.8.5
      `:+ssssssssssssssssssss+-            Terminal Font: Hack (12pt)
         `-/+ssssssssssso+/-`              CPU: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics (16) @ 6.23 GHz
              `.-----..`                   GPU 1: AMD Radeon RX 7700S
                                           GPU 2: AMD Phoenix1
                                           Memory: 8.88 GiB / 27.11 GiB (33%)
                                           Swap: 9.00 MiB / 41.61 GiB (0%)
                                           Disk (/): 954.03 GiB / 1.76 TiB (53%) - ext4
                                           Local IP (wlp4s0): 192.168.68.65/22 *
                                           Battery: 60% [Charging]
                                           Locale: en_US.UTF-8

Any help would be appreciated.

First of all @Bryson , love the terminal background.

Could you paste the output of the following command?
vulkaninfo | grep "GPU[0123]" -A 10
Remember, these lists are 0 based, so if it lists the DGPU 7700S first in the list with index 0, you may want to try DRI_PRIME=0! instead.

I think you may have already tried this, but wanted to double check.

I myself do not have a Framework 16 on order yet, as I’m saving the funds for it. That noted, has anyone here tried GloriousEggroll’s Nobara distro on their Framework 16 with dGPU yet? He’s made a bunch of changes in there for GPU switching so I’m wondering if the DRI_PRIME issue was also resolved: https://nobaraproject.org/

For reference, the framework dgpu utility only looks for the environment variable, not if it has had any effect (based on the sourcecode last time I checked). Also I seem to remember reading that DRI_PRIME was only for OpenGL applications (with vulkan allowing applications to select the gpu themselves)

You know, I think I misread this information from nvtop. After a little more digging it seems like this is expected behavior. I’m seeing that the dGPU is in fact ‘in use’ because there’s activity, number one, and that there is another version of the same process running directly on the dGPU (at dev 1) farther down in the list. Still, here’s the output you requested:

the mesa documentation (linked by matt_hartley above) indicates this applies for both opengl and vulkan applications. sure, without the ! it’s just putting the preferred device at the top of the list of devices, and a vulkan app CAN select a different device if it insists, but with ! only the preferred device should be presented to the vulkan app. any other behavior indicates a severe bug in either the documentation or the implementation.

1 Like

Good morning/day/evening/night everyone!

Today, I eventually found the time to game a bit with my Batch 5 FW16.

System
  • CPU: 7840HS
  • GPU: 7700S
  • OS: Manjaro Linux
    • Kernel: 6.6.19-1-MANJARO
    • DE: Budgie

Problem

I am a bit confused by my output of vulkaninfo and the implications on the launch options I have to give to the apps/steam games I want to use.

Output of vulkaninfo
$ vulkaninfo | grep "GPU[0123]" -A 10                                         
GPU0:
VkPhysicalDeviceProperties:
---------------------------
	apiVersion        = 1.3.274 (4206866)
	driverVersion     = 24.0.2 (100663298)
	vendorID          = 0x1002
	deviceID          = 0x7480
	deviceType        = PHYSICAL_DEVICE_TYPE_DISCRETE_GPU
	deviceName        = AMD Radeon RX 7700S (RADV NAVI33)
	pipelineCacheUUID = 0d2f0510-8f8f-6504-4f27-9363d0e5cfea

--
GPU1:
VkPhysicalDeviceProperties:
---------------------------
	apiVersion        = 1.3.274 (4206866)
	driverVersion     = 24.0.2 (100663298)
	vendorID          = 0x1002
	deviceID          = 0x15bf
	deviceType        = PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU
	deviceName        = AMD Radeon Graphics (RADV GFX1103_R1)
	pipelineCacheUUID = 6c9c03dd-f74e-6101-c3d6-15a857a7d326

The dGPU is GPU0.

Following the instructions in the Linux Guide by FW and the tips in this thread, I would have to use DRI_PRIME=0 DXVK_FILTER_DEVICE_NAME="AMD Radeon RX 7700S (RADV NAVI33)" %command% for Steam Games and, in case of other applications, omit the %.
But in fact, it seems that the dGPU is addressed by DRI_PRIME=1. When starting Heaven benchmark from the terminal, I would get 25ish FPS using DRI_PRIME=0. If I use DRI_PRIME=1 instead, I get 120 to 130 FPS.
While most games on steam (native or not) don’t care about this and no matter if I specify DRI_PRIME=1, DRI_PRIME=0, with or without exclamation mark or string, or if I completely omit launch options. At least steam’s FPS counter and radeontop’s output indicate that.
Some games that seem to not care are:

  • Doom (2016) and Doom Eternal (both through Proton)
  • Shadow of the Tomb Raider (native)
  • Hollow Knight (native)
  • Euro Truck Simulator 2 (native)
  • CS2 (native)

One game that does care about if I specify the dGPU is Deponia (through Proton).

I am confused about this inconsistency. Am I doing something wrong?

Some questions now:

  1. Why could it be that my dGPU is GPU0 while for everyone else it is GPU1?
  2. Why do some games ignore the launch options, while others do not and use the dGPU anyway? Is it because it is the first in the list when querying vulkaninfo? Isn’t that in conflict with 1.?

Kind regards :blush:

for vulkan games, DRI_PRIME=x is apparently a suggestion, according to the docs linked up above, and can be disregarded if the app is sure it knows better.

have you tried adding a ! to the number for each scenario? according to aforementioned docs, that’s supposed to restrict the graphics device list to solely what you selected, so that vulkan apps have no choice but to use what you chose.

Yes, I tried adding the ! and yet it yielded the same result everytime.
I wouldn’t bother that much if it wasn’t for the vulkaninfo output indicating it would be GPU0 while the actual data show it should be GPU1

if your dGPU is gpu0, i believe that DRI_PRIME=0 is actually considered invalid, and the number has to be greater than or equal to 1. I imagine that this also holds true with DRI_PRIME=0!

Maybe you could try selecting by the PCI device id? This command (written by myself) should generate the needed environment variable:

sh -c "echo 'DRI_PRIME=pci-0000_'$(lspci | grep 'Navi 33' | sed -E --expression='s/:|\./_/g' | sed --expression='s/\s.*/!/')"

and this command (also written by myself) will generate the needed environment variable and then run a program (replace vulkaninfo --summary with your own command):

sh -c "DRI_PRIME=$(echo 'pci-0000_'$(lspci | grep 'Navi 33' | sed -E --expression='s/:|\./_/g' | sed --expression='s/\s.*/!/')) vulkaninfo --summary"

(see the first note in section 2.1 of this archwiki page for more information on this format of the environment variable)

If you use the environment variable generated with vulkaninfo --summary (or the second command, unmodified) and it only returns your dGPU in the “Devices” section, you have set this up correctly.

Edit to add: DRI_PRIME=0! is indeed not respected (DRI_PRIME=0! vulkaninfo --summary will return information about every GPU in the system, whereas DRI_PRIME=1! vulkaninfo --summary only returns information about one GPU)
Edit also fixed a typo and put code blocks around environment variables

Edit to add (the second): If for whatever reason you want to do this with your integrated GPU, you can replace 'Navi 33' with 'Phoenix1' in either command. I did this to test that I could indeed select the first graphics adapter on the system.

Edit to add (the third): It is probably better to use the DRI_PRIME=vendor_id:device_id syntax in case PCI bus ids change (for example DRI_PRIME=1002:7480!), as documented at Environment Variables — The Mesa 3D Graphics Library latest documentation

1 Like

As a sidenote: For games that use VKD3D you can use VKD3D_VULKAN_DEVICE=1 or VKD3D_VULKAN_DEVICE=0 to force switch between them, as it can too ignore DRI_PRIME= and even DXVK_FILTER[…] options

I’m currently having this same issue with Linux Mint. Except I think it’s more than just Minecraft that isn’t seeing it and I don’t think the DRI_PRIME=1 command worked. Got any wisdom for a Linix noob like me?

Protip: Don’t use the DRI_PRIME command unless you really need to. It’s a lot easier to use switcherooctl launch %command% as that will cause the OS to automatically offload the app to the dGPU

for at least the minecraft case, prism launcher appears to do the right thing when you go into its settings and tell it to try to use the dgpu.