GPU Caching not working properly on Linux?

[p2r3]

Hello, I have just joined the forum, so I have no idea where to post this. I originally thought just posting on the Steam forums, but everyone there seems to have no idea that something other than Windows even exists, let alone how a GPU works. If you know a better place, please tell me.

 

I have an AMD Radeon R7 240 graphics card, i3-6100 CPU and 4 Gigs of RAM (planning on upgrading that very soon)

I'm running Linux (Ubuntu 18.04) and for some reason my PC is struggling to run CS:GO after the panorama update. Disabling the HUD helps, so I'm guessing that's what's been broken. For instance, when I press Tab to open up the scoreboard, the game freezes for more than a second, and then finally loads the scoreboard. One of the interesting things I recently figured out is that spamming the key after It's been loaded once doesn't cause any slowdown, but if I wait for more than 3 seconds, the cache for the scoreboard has been seemingly wiped. I enjoy playing CSGO, but this frequent stuttering is seriously killing my interest. I can't even play the new battle royale game mode. It runs at 30 fps, where this setup should be getting ~200 on my current settings.

[Screaming Doggo]

4 minutes ago, p2r3 said:

Hello, I have just joined the forum, so I have no idea where to post this. I originally thought just posting on the Steam forums, but everyone there seems to have no idea that something other than Windows even exists, let alone how a GPU works. If you know a better place, please tell me.

 

I have an AMD Radeon R7 240 graphics card, i3-6100 CPU and 4 Gigs of RAM (planning on upgrading that very soon)

I'm running Linux (Ubuntu 18.04) and for some reason my PC is struggling to run CS:GO after the panorama update. Disabling the HUD helps, so I'm guessing that's what's been broken. For instance, when I press Tab to open up the scoreboard, the game freezes for more than a second, and then finally loads the scoreboard. One of the interesting things I recently figured out is that spamming the key after It's been loaded once doesn't cause any slowdown, but if I wait for more than 3 seconds, the cache for the scoreboard has been seemingly wiped. I enjoy playing CSGO, but this frequent stuttering is seriously killing my interest. I can't even play the new battle royale game mode. It runs at 30 fps, where this setup should be getting ~200 on my current settings.

Well. I'm sad to tell you that CSGO updates as of now are quite buggy and there are a lot of people who are reporting this issue of  dropped frames and laggy ui performance. Although for some reason it is not happening with Nvidia users and occurs only with AMD users. Im a Nvidia user and i have not experienced it. But the people who are using AMD GPUs are experiencing this issue. This narrows down that the game has some bugs related to GPU

[Radium_Angel]

4 minutes ago, p2r3 said:

settings

Linux user here, although I use 14.04 LTS.

You have several things working against you:

 

AMD under Linux is....spotty at best

The gfx card you have is....modest (and that's being polite)

Gaming under Linux can also be spotty as well

Then you throw in updates.

 

I'd start with an nVidia card, that might help you to begin with

[Ralphred]

2 hours ago, Radium_Angel said:

AMD under Linux is....spotty at best

This is not really true anymore, there have been massive efforts recently at all levels along the driver chain, I've seen continious improvements even from my old bonaire chipset machine throughout the 4.x development cycle. I've used nvidia in the past and the commercial driver, apart from needing re-compiling for every new kernel (including failing to do so sometimes), had a list of use case caveats that was so long I'd never go back until nouveau works comparably. I can understand how using something like ubuntu where someone does all the work for you it's pretty easy.

 

OP: First off make sure any desktop compositing is disabled when the game is active, Steam tends to do this for me, but YMMV depending on which environment you use; if unsure just disable it entirely or run twm/dwm session for testing. I run this game at 75fps (vsyncd) at ~25% gpu load, allthough the newer scoreboard is pretty, and opening it does cause a gpu usage spike (about 5%), what you are reporting doesn't seem reasonable for your hardware.

 

Check your kernel is up to date, there were improvements that would effect your chipset at late as 4.18.x.

Other aspects of the drivers need to be up to date too, mostly mesa (should be around version 18.x) and libdrm*, but it's also worth checking the firmware.

I don't know how well these LTS versions are at keeping up with driver development backports, but if kernel.org is anything to go by (which is 4.14 atm iirc, pre dc even...) it's not great.

 

The last thing to check that you are using all the parts you should be and in the right way, dmesg** output will give you feedback on firmware loading, drm errors at driver initialisation time, kernel parameters passed to the amdgpu driver at load time and driver errors during runtime***. lspci -v lets you check you are using the right driver. Users of distro's like Arch and Gentoo have to set all these things up manually, as is intended, this means that thier wiki pages are well maintained and contain lots of information about the kernel settings/firmware for each chipset the amdgpu driver supports, just google amdgpu arch or amdgpu gentoo (from memory arch has the module settings info for si/cik cards like yours)

Also, your xorg config, I know it does it for you now, but out of my 5 machines, it only does one of them 100% right without intervention.

 

If all else fails the csgo.sh script that initates the game is in the root of the Counter-Strike directory, it's pretty trivial to export extra environment variables to enable the gallium hud and debugging options, you can check your shader cache and stuff like that from here too, though mesa debugging is not for the faint hearted and the hud is ugly as it gets.

 

*libdrm had some horrible bugs at older versions, I don't remember info on which versions though, sry.

**If you want help interpreting any dmesg output pastebin it and link it.

***There have been some amdgpu regressions of late (say last 6 months) that you may be affected by, yet to meet any unfixed in the latest stable kernel tho.

[Radium_Angel]

2 minutes ago, Ralphred said:

This is not really true anymore

I will take your word for it, I started with AMD under Ubuntu 14.04LTS for my neural network system, and quickly switched when I found nVidia gear was better supported and gave me better results. 

[Ralphred]

26 minutes ago, Radium_Angel said:

Ubuntu

That's code for "linux for windows users".

It's easy to see why people think NV has better support, because the drivers come direct from NV, but AMD supporting devs who officialy work for other projects, or just having thier own devs commit to kernel.org, that goes un-noticed...

 

But this is an inappropriate place for this discussion, we are trying to help the OP diagnose and fix a specfifc issue...

[p2r3]

10 hours ago, Ralphred said:

**If you want help interpreting any dmesg output pastebin it and link it.

Hey, thank you for the reply!

 

Yeah, I'd much rather leave reading this to someone who has prior experience.

Output of dmesg

Output of lspci -v

 

Anything obvious you can spot?

[Madgemade]

One thing that I notice in dmesg is this:

[    0.944747] amdgpu 0000:01:00.0: SI support provided by radeon.
[    0.944748] amdgpu 0000:01:00.0: Use radeon.si_support=0 amdgpu.si_support=1 to override.

This means that you are using the old "radeon" gpu driver (supports all ati/amd from 2005ish up to R7 and R9, i.e. Nothing newer than 2015), the new driver called "amdgpu" can be used instead. This driver is known to offer better performance and supports only the newer GPUs that AMD supports on windows. There are instructions on enabling it here. The amdgpu driver is not enabled by default because it didn't used to support your card, but then AMD added the support later on so you can use it now.

 

Using the newer driver will give you some optimizations and hopefully improve the situation for you.

I see you are probably on Ubuntu 18.04 so that's fine no reason to upgrade that.

 

Edit:

For future reference "amdgpu" is NOT the same as "amdgpu-pro". DO NOT install "amdgpu-pro" there is no need, the gaming driver is the non pro "amdgpu" and is built in (pre-installed) in Ubuntu.

Edited December 22, 2018 by Madgemade
dont use amdgpu-pro. plz

[p2r3]

57 minutes ago, Madgemade said:

One thing that I notice in dmesg is this:

[    0.944747] amdgpu 0000:01:00.0: SI support provided by radeon.
[    0.944748] amdgpu 0000:01:00.0: Use radeon.si_support=0 amdgpu.si_support=1 to override.

This means that you are using the old "radeon" gpu driver (supports all ati/amd from 2005ish up to R7 and R9, i.e. Nothing newer than 2015), the new driver called "amdgpu" can be used instead. This driver is known to offer better performance and supports only the newer GPUs that AMD supports on windows. There are instructions on enabling it here. The amdgpu driver is not enabled by default because it didn't used to support your card, but then AMD added the support later on so you can use it now.

 

Using the newer driver will give you some optimizations and hopefully improve the situation for you.

I see you are probably on Ubuntu 18.04 so that's fine no reason to upgrade that.

Just did the driver upgrade, but this seems to have broken something. Even Steam won't launch.

dmesg announces some sort of segfault when opening Steam, but I have no idea what this means and what's causing it.

[Madgemade]

That's strange. It should have worked ok. From the log I can see that amdgpu is working but it's possible there is a problem with Xorg or with the actual mesa that is installed. Could you post up the /var/log/Xorg.log in case that has any problems.

 

I'm assuming all you did was adding the kernel parameters:

radeon.cik_support=0 amdgpu.cik_support=1

That's that needs to be done to use the newer driver. To switch back to the "radeon" driver just remove those parameters.

[p2r3]

1 hour ago, Madgemade said:

Could you post up the /var/log/Xorg.log in case that has any problems.

 

I'm assuming all you did was adding the kernel parameters

 

1. Sure thing: https://pastebin.com/Ng0M4VRF

2. I installed it through the amdgpu-pro-install tool, and the install was seemingly successful.

 

[Madgemade]

1 hour ago, p2r3 said:

I installed it through the amdgpu-pro-install tool, and the install was seemingly successful.

I was afraid you might have done that, that's the problem. There is nothing to install. You don't want "amdgpu-pro" it isn't for gaming and performs poorly at it. It is also difficult to install and often buggy as you have found.

 

Sadly googling amdgpu often brings up amdgpu-pro instructions and people get misled. AMDGPU-PRO is hard to install and you don't want it unless you really need it. Your install has not been successful and you will need to remove it to fix your installation. That "-pro" means a lot, it's a a completely different driver, not open source and doesn't have any gaming optimizations or anything like that, also has a lot of compatibility issues.

 

Looking at your Xorg log, I can see that installing amdgpu-pro has broken your system and the safe-mode like drivers are being used instead of "radoen" or "amdgpu". You can't use any 3d programs games etc. until you fix this by removing amdgpu-pro.

 

Remove AMDGPU-PRO first and once you are back to where you were before; follow these instructions to add "radeon.cik_support=0 amdgpu.cik_support=1" (instead of foo=bar in the link). That will tell ubuntu to use the newer amd driver "amdgpu".

 

It's counter intuitive on Linux but for AMD you don't need to install any GPU drivers at all they are included in the Linux kernel. For Pro stuff like opencl and compute you do need to install the pro drivers but they are not for gaming. For Nvidia though you do have to install drivers because the included ones don't work for gaming.

[p2r3]

1 hour ago, Madgemade said:

Remove AMDGPU-PRO first and once you are back to where you were before; follow these instructions to add "radeon.cik_support=0 amdgpu.cik_support=1" (instead of foo=bar in the link). That will tell ubuntu to use the newer amd driver "amdgpu".

Did what you said, but my game is still lagging the same way.

dmesg output again

[Madgemade]

From that log I can see that you have added the kernel parameters but for some reason the "radeon" driver is still being used. Which is why you can't see any difference in game. I didn't think you needed the other two parameters but it looks like you might. Try adding

radeon.si_support=0 amdgpu.si_support=1

instead of what you already did. It's a very similar option but notice it says si and not cik. It looks like your GPU is Southern Islands and not Sea Islands. It actually said to do this in the log I forgot when I typed it out. You could try keeping what you have already and add those two after so you have a total of four options added, that's what I use on my system for my R9 290. It should only need the two above but all four doesn't do any harm.

 

In the pastebin it mentions this at line 654. At line 653 it says "support provided by radeon" which means you are using the older driver.

With the parameter above it should instead use "amdgpu" and that message will be gone. Also post up your Xorg lof after trying this as that log is only for Graphics and not everything and will confirm that you (hopefully) have the newer driver enabled this time.

[Ralphred]

An R7 240 is Southern Isles OLAND chip set, so kernel module parameters ending .si is correct (it was with this setting that OP's dmesg showed the firmware being loaded correctly), but that is no guarantee it'll still use the correct module, best to blacklist the radeon module (I'll let someone else suggest the best way on *buntu, 'cos I don't use modules as a rule.)

It was kernel 4.15.9 that added amdgpu.dc support for si cards, so if you can push up to or newer than this (4.18.x is pretty stable with amdgpu where x is over 10 or so) and add amdgpu.dc=1 the same way you did with the other kernel parameters that would be a plus.

 

A certain amount of the DRI is still referred to as radeon (it's the radeonsi mesa modules iirc) so you may well still see radeonsi in the xorg log, this is normal.

 

But get lspci -v showing "Kernel driver in use: amdgpu" for the gfx card and we can deal with xorg.conf later if needed. 
 

[p2r3]

On 12/22/2018 at 8:21 PM, Madgemade said:

Try adding

radeon.si_support=0 amdgpu.si_support=1

instead of what you already did.

I changed it to that...

23 hours ago, Ralphred said:

It was kernel 4.15.9 that added amdgpu.dc support for si cards, so if you can push up to or newer than this (4.18.x is pretty stable with amdgpu where x is over 10 or so) and add amdgpu.dc=1 the same way you did with the other kernel parameters that would be a plus.

 

... upgraded kernel to 4.19.11 and added this, but this time lspci -v doesn't even have a "Driver in use:" line anymore. Even watching Youtube is laggy now, and switching tabs in Firefox makes my screen go black for a second.

 

Thank you all for helping so far!

[Ralphred]

Link a new dmesg pls

[p2r3]

1 hour ago, Ralphred said:

Link a new dmesg pls

https://pastebin.com/q8yR3L3v

 

Edit: Just checked it out myself and looks like the driver is incompatible with my system? What does this mean? Is this on the hardware level or do I just need some software update?

[Ralphred]

 

[    1.255033] [drm] initializing kernel modesetting (OLAND 0x1002:0x6613 0x1458:0x22B0 0x00).
[    1.255041] [drm] register mmio base: 0xEFE00000
[    1.255041] [drm] register mmio size: 262144
[    1.255045] [drm] add ip block number 0 <si_common>
[    1.255046] [drm] add ip block number 1 <gmc_v6_0>
[    1.255046] [drm] add ip block number 2 <si_ih>
[    1.255047] [drm] add ip block number 3 <si_dpm>
[    1.255048] [drm] add ip block number 4 <dce_v6_0>
[    1.255048] [drm] add ip block number 5 <gfx_v6_0>
[    1.255049] [drm] add ip block number 6 <si_dma>
[    1.255050] amdgpu 0000:01:00.0: kfd not supported on this ASIC
[    1.259724] [drm] BIOS signature incorrect 0 0
[    1.259730] amdgpu 0000:01:00.0: No more image in the PCI ROM
[    1.259756] ATOM BIOS: xxx-xxx-xxx
[    1.260231] [drm] vm size is 64 GB, 2 levels, block size is 10-bit, fragment size is 9-bit
[    1.260244] amdgpu 0000:01:00.0: Direct firmware load for amdgpu/oland_mc.bin failed with error -2
[    1.260246] amdgpu 0000:01:00.0: si_mc: Failed to load firmware "amdgpu/oland_mc.bin"
[    1.260250] amdgpu 0000:01:00.0: Failed to load mc firmware!
[    1.260306] [drm:amdgpu_device_init.cold.28 [amdgpu]] *ERROR* sw_init of IP block <gmc_v6_0> failed -2
[    1.260309] amdgpu 0000:01:00.0: amdgpu_device_ip_init failed
[    1.260311] amdgpu 0000:01:00.0: Fatal error during GPU init
[    1.260312] [drm] amdgpu: finishing device.

[    1.260658] amdgpu: probe of 0000:01:00.0 failed with error -2

The kernel loaded the driver module for the card but failed to load the firmware properly. First point of call would be to make sure your firmware is up to date, like from October or November this year. I don't know how *buntu packages it's firmware, there may be a specific amd-firmware package or just a generic linux-firmware.

If there is like a ubuntu irc or similar someone there should know. It's expected for things to not work properly when the driver fails like this, don't worry just yet...

[Madgemade]

Make sure you have xserver-xorg-video-amdgpu and linux-firmware installed. BTW I don't see any reason to update to an unsupported non ubuntu style kernel, that could introduce problems of it's own depending on how it has been installed.

 

Check the /lib/firmware folder. It should have an amdgpu folder and that should have the oland_mc.bin file inside it. Full path would be /lib/firmware/amdgpu/oland_mc.bin.

[p2r3]

1 hour ago, Madgemade said:

Check the /lib/firmware folder. It should have an amdgpu folder and that should have the oland_mc.bin file inside it. Full path would be /lib/firmware/amdgpu/oland_mc.bin.

Yeah that file doesn't exist... What now?

 

The firmware is up to date, as far as apt is concerned.

[Ralphred]

The Oland firmware is in the /lib/firmware/radeon/ directory along with the other SI and CIK cards, it switched sometime later to amdgpu for backwards compatibility for cards supported by the radeon module as well. If an appropriate version isn't packaged you can get it from kernel.org, it's just a bunch of files, no real "installation" just dump 'em in the /lib/firmware folder. That said, you should get an up to date version from the same repo that game you the kernel, you kinda need both, the bin files are either referenced at build time for static drivers or load time for modules.

Some firmware is installed 'cos you can see the microcode updates happening at the start of dmesg on the cpu, anyone got a link to a base buntu repo where you can browse the .debs?

 

These "it just works" things are so much harder to make work when they don't work than the "just do it yourself from scratch" variety. Every time I think it would be easier to move to a distro like this, something happens to remind me why I don't...

 

EDIT: Well, this is inconsistent, the radeon module pulls the oland firmware exclusively from the radeon folder, amdgpu pulls it from both amdgpu and radeon

[Madgemade]

This patch is likely why. It is also causing problems with AMDs Rocm open source compute. The fix is just copy across the file from the radeon folder to the amdgpu folder to fix it.

 

You got this problem because you installed a newer kernel which looks in a different place. The latest Ubuntu kernel in repo is 4.15 and the change which causes this problem was introduced in 4.19.

If you try to do your own thing on a "it just works"  distro then you will run into issue like this.

When the official 'ubuntu flavor' kernel is released then this will hopefully be fixed.

 

Instead of moving files you could just go back to the official kernel and the problem should be gone. I would also recommend that because now that you have a custom kernel you will no longer receive any kernel updates through apt and this may mess up your system if you try to update to Ubuntu 19.04 or whatever later on.

When you get involved with the kernel, modules, initrd, firmware etc. it makes xorg.conf look so easy, it's a steep learning curve and I tend to advise to keep with the default and not install stuff outside of apt, then you can be relatively sure it will work!

[Ralphred]

14 minutes ago, Madgemade said:

Apparently you can just copy across the file from the radeon folder.

Yeah, I wouldn't they are different sizes here between the folders. Changes were added to the firmware between 4.15* and now, to cope with the DC driver.

Considering it's working, and just missing the firmware, and booting via vmlinuz and not an initrd, just copying the firmware from kernel.org is easiest for now, then just revert to an ubuntu sanctioned kernel when they eventually catch up, is there really not a kernel packaged over 4.15, 4.14 I could understand, that's the latest LTS, but 4.15 is just odd...

 

*Tho that may have been 4.9, too many machines, too much to remember.

 

EDIT:Yeah, amdgpu/oland*.bin was updated July this year, radeon/oland*.bin wasn't. Some advancements in the amdgpu driver require the correct firmware, radeon seems stale.

[p2r3]

47 minutes ago, Madgemade said:

Instead of moving files you could just go back to the official kernel and the problem should be gone. I would also recommend that because now that you have a custom kernel you will no longer receive any kernel updates through apt and this may mess up your system if you try to update to Ubuntu 19.04 or whatever later on.

Yeah, I'll just go back to 4.15 and wait until Ubuntu finally has a fix for this. Thanks for the help anyway.