prime offloading performance

joeyalbo007 · 2020-03-24 01:27:29

Hello everybody,
Just converted to the arch world on my HP pavilion. Loving the distro so far but I'm having an issue with prime offloading.

I'm running an Intel cpu with an amd radeon 530 discrete graphics card. I went through the wiki page on setting everything up and everything on the wiki worked. The issue is when I launch a graphics intensive application such as supertuxkart, my frame rate is awful. I know it runs better on my hardware as it ran fine on ubuntu.

When I run glxinfo with DRI_PRIME=1 it does say the renderer is the amd graphics card but the game does not act like it. In fact I got better performance without DRI_PRIME set.

Thanks in advance.

Edit: corrected graphics card model

Last edited by joeyalbo007 (2020-03-24 18:04:58)

jonno2002 · 2020-03-24 02:55:53

which R7 gpu do you have

lspci -v |grep 3D

joeyalbo007 · 2020-03-24 03:12:45

 lspci |grep Display
01:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Topaz XT [Radeon R7 M260/M265 / M340/M360 / M440/M445 / 530/535 / 620/625 Mobile] (rev 83)

grepping 3D doesn't find anything but this is what I was able to get. it's a 530.

joeyalbo007 · 2020-03-24 03:41:19

Just did a test with

vblank_mode=0 DRI_PRIME=1 glxgears

. Got about 1100 fps.
With

vblank_mode=0 DRI_PRIME=0 glxgears

i got 2000 fps.

ran both of these with the

-info

flag and I can confirm that

 DRI_PRIME=1

is with the radeon card and

 DRI_PRIME=0

is with the intel graphics.

jonno2002 · 2020-03-24 04:03:12

can you post your xorg log ?

joeyalbo007 · 2020-03-24 04:14:00

jonno2002 wrote:

can you post your xorg log ?

Here she be https://pastebin.com/3Ds6wdqd

jonno2002 · 2020-03-24 04:29:30

try removing the xf86-video-intel driver and see what happens

seth · 2020-03-24 07:24:06

glamor X acceleration enabled on AMD Radeon (TM) R7 M340 (ICELAND, DRM 3.36.0, 5.5.11-arch1-1, LLVM 9.0.1)

What exactly is "aweful"? Can you disable vsync in supertuxkart?

glxgears isn't necessarily a meaningful test. There's an overhead for copying the frames from the GPU to the IGP and on very high FPS this can easily outweigh the benefit of the GPU (ie. glxgears is sooo trivial, that rendering it on the intel chip is faster than rendering it (slightly faster) on the AMD chip and copying it (slowely) over)

Please post your complete lspci so we can see what the intel chip is exactly, but the M340 is not very fast - many UHDs can actually outperform it.
Are you *sure* that you ran supertuxkart on the AMD gpu on ubuntu?

joeyalbo007 · 2020-03-24 15:57:45

jonno2002 wrote:

try removing the xf86-video-intel driver and see what happens

No noticeable difference of any sort.

joeyalbo007 · 2020-03-24 16:03:17

seth wrote:

glamor X acceleration enabled on AMD Radeon (TM) R7 M340 (ICELAND, DRM 3.36.0, 5.5.11-arch1-1, LLVM 9.0.1)
What exactly is "aweful"? Can you disable vsync in supertuxkart?
glxgears isn't necessarily a meaningful test. There's an overhead for copying the frames from the GPU to the IGP and on very high FPS this can easily outweigh the benefit of the GPU (ie. glxgears is sooo trivial, that rendering it on the intel chip is faster than rendering it (slightly faster) on the AMD chip and copying it (slowely) over)
Please post your complete lspci so we can see what the intel chip is exactly, but the M340 is not very fast - many UHDs can actually outperform it.
Are you *sure* that you ran supertuxkart on the AMD gpu on ubuntu?

lspci
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers (rev 08)
00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 (rev 07)
00:04.0 Signal processing controller: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem (rev 08)
00:13.0 Non-VGA unclassified device: Intel Corporation Sunrise Point-LP Integrated Sensor Hub (rev 21)
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21)
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP Thermal subsystem (rev 21)
00:15.0 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #0 (rev 21)
00:15.1 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #1 (rev 21)
00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME HECI #1 (rev 21)
00:17.0 SATA controller: Intel Corporation Sunrise Point-LP SATA Controller [AHCI mode] (rev 21)
00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #1 (rev f1)
00:1d.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #9 (rev f1)
00:1d.1 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #10 (rev f1)
00:1f.0 ISA bridge: Intel Corporation Sunrise Point LPC Controller/eSPI Controller (rev 21)
00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21)
00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21)
00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)
01:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Topaz XT [Radeon R7 M260/M265 / M340/M360 / M440/M445 / 530/535 / 620/625 Mobile] (rev 83)
02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS522A PCI Express Card Reader (rev 01)
03:00.0 Network controller: Intel Corporation Dual Band Wireless-AC 3168NGW [Stone Peak] (rev 10)

I am pretty damn sure. Regardless though I got much better performance on ubuntu with DRI_PRIME=1. I am positive it wasn't this bad.

by "aweful" (gotta love proper spelling) I'm talking 2-3 fps. Really god awful performance. Granted, I am running on high (same as when I did it on ubuntu)

Last edited by joeyalbo007 (2020-03-24 16:19:41)

seth · 2020-03-24 17:00:41

https://www.notebookcheck.com/Radeon-R7 … 532.0.html

Unrelated to the issue at hand, I'd say to disable the m340 and save battery.

2-3fps is however unreasonably slow - what desktop environment do you use? Get any compositor out of the equation (ie. try running on openbox or so) and/or disable vsync in supertuxkart and see what happens.

joeyalbo007 · 2020-03-24 17:12:51

seth wrote:

https://www.notebookcheck.com/Radeon-R7 … 532.0.html
Unrelated to the issue at hand, I'd say to disable the m340 and save battery.
2-3fps is however unreasonably slow - what desktop environment do you use? Get any compositor out of the equation (ie. try running on openbox or so) and/or disable vsync in supertuxkart and see what happens.

I've tried with and without vsync with no real difference. I was running awesome which, if i'm not mistaken should take compositor out of the equation. I downloaded xfce to test and it's the same on both.

Edit: also my graphics card is a radeon 530 not an r7 m340. I must have been mistaken when I wrote my original post

Last edited by joeyalbo007 (2020-03-24 18:04:20)

seth · 2020-03-24 21:15:07

Edit: also my graphics card is a radeon 530 not an r7 m340. I must have been mistaken when I wrote my original post

The amdgpu driver disagrees:

[   962.668] (--) AMDGPU(G0): Chipset: "AMD Radeon (TM) R7 M340" (ChipID = 0x6900)

(This was the base of my assertion all along)

Many ppl. use compton/picom along awesome/i3 (and xfce has a compositor as well), but we'll assume this isn't the case here.
Does the GPU enter higher power states?
=> Check /sys/class/drm/card0/device/pp_dpm_*
Maybe errors in dmesg?

joeyalbo007 · 2020-03-24 21:50:41

seth wrote:

Edit: also my graphics card is a radeon 530 not an r7 m340. I must have been mistaken when I wrote my original post
The amdgpu driver disagrees:
[   962.668] (--) AMDGPU(G0): Chipset: "AMD Radeon (TM) R7 M340" (ChipID = 0x6900)
(This was the base of my assertion all along)

Many ppl. use compton/picom along awesome/i3 (and xfce has a compositor as well), but we'll assume this isn't the case here.
Does the GPU enter higher power states?
=> Check /sys/class/drm/card0/device/pp_dpm_*
Maybe errors in dmesg?

that file doesn't exist but I assume card1 is the amd one anyway and it does for that. here's the output:

 cat /sys/class/drm/card1/device/pp_dpm_mclk  
0: 300Mhz 
1: 600Mhz 
2: 1000Mhz

 cat /sys/class/drm/card1/device/pp_dpm_pcie 
0: 2.5GT/s, x8 
1: 2.5GT/s, x8 
2: 8.0GT/s, x16 
3: 8.0GT/s, x16 
4: 8.0GT/s, x16 
5: 8.0GT/s, x16

 cat /sys/class/drm/card1/device/pp_dpm_sclk 
0: 300Mhz 
1: 551Mhz 
2: 678Mhz 
3: 754Mhz 
4: 810Mhz 
5: 867Mhz 
6: 943Mhz 
7: 1021Mhz

Is this file simply pulling info from the card or is this defining the clockspeed for the card to run at? If i change these numbers will it change the clockspeed of the gpu?

Edit: also my dmesg is up in the thread somewhere. I didn't see anything alarming but then again if i did I prob wouldn't be having issues.

Last edited by joeyalbo007 (2020-03-24 22:04:20)

jonno2002 · 2020-03-25 02:04:00

maybe try LTS kernel if you havent already ?

joeyalbo007 · 2020-03-25 02:59:35

jonno2002 wrote:

maybe try LTS kernel if you havent already ?

Just tried. Same story I'm afraid :-(

seth · 2020-03-25 07:04:11

https://wiki.archlinux.org/index.php/AM … erclocking

Is none of those values indicated with an "*" as being current?

(And yes, should have been card1, sorry - my bad)

joeyalbo007 · 2020-03-25 13:57:13

seth wrote:

https://wiki.archlinux.org/index.php/AM … erclocking
Is none of those values indicated with an "*" as being current?
(And yes, should have been card1, sorry - my bad)

OH MY GOD THAT'S IT!!!

When I'm running a program on that GPU it never gets out of the first P-State!

The asterisk only appears when I run a program with DRI_PRIME=1

seth · 2020-03-25 14:06:19

You could try if any of the parameters in "modinfo amdgpu | grep pm" has impact on this (if you don't want to hand-control the p-state)

joeyalbo007 · 2020-03-25 15:20:47

seth wrote:

You could try if any of the parameters in "modinfo amdgpu | grep pm" has impact on this (if you don't want to hand-control the p-state)

alright so we're making progress. I don't seem to be able to modify the p-states I was going off of this article https://dri.freedesktop.org/docs/drm/gp … monitoring
I changed the

power_dpm_force_performance_mode

to "manual" and tried to force 7 on sclk and 2 on mclk but the asterisk will not move and performance doesn't improve.
This is a real head scratcher

seth · 2020-03-29 21:11:37

Did you pass "amdgpu.ppfeaturemask=0xfffd7fff" to the kernel as pointed out in the wiki linked in comment #17?

joeyalbo007 · 2020-03-29 21:41:00

seth wrote:

Did you pass "amdgpu.ppfeaturemask=0xfffd7fff" to the kernel as pointed out in the wiki linked in comment #17?

I did indeed. I also tried 0xffffffff to avail.

Arch Linux

#1 2020-03-24 01:27:29

prime offloading performance

#2 2020-03-24 02:55:53

Re: prime offloading performance

#3 2020-03-24 03:12:45

Re: prime offloading performance

#4 2020-03-24 03:41:19

Re: prime offloading performance

#5 2020-03-24 04:03:12

Re: prime offloading performance

#6 2020-03-24 04:14:00

Re: prime offloading performance

#7 2020-03-24 04:29:30

Re: prime offloading performance

#8 2020-03-24 07:24:06

Re: prime offloading performance

#9 2020-03-24 15:57:45

Re: prime offloading performance

#10 2020-03-24 16:03:17

Re: prime offloading performance

#11 2020-03-24 17:00:41

Re: prime offloading performance

#12 2020-03-24 17:12:51

Re: prime offloading performance

#13 2020-03-24 21:15:07

Re: prime offloading performance

#14 2020-03-24 21:50:41

Re: prime offloading performance

#15 2020-03-25 02:04:00

Re: prime offloading performance

#16 2020-03-25 02:59:35

Re: prime offloading performance

#17 2020-03-25 07:04:11

Re: prime offloading performance

#18 2020-03-25 13:57:13

Re: prime offloading performance

#19 2020-03-25 14:06:19

Re: prime offloading performance

#20 2020-03-25 15:20:47

Re: prime offloading performance

#21 2020-03-29 21:11:37

Re: prime offloading performance

#22 2020-03-29 21:41:00

Re: prime offloading performance

Board footer