[SOLVED] Game issues - framerate oddity, CPU overload, GPU driver questions.

lawnm0wer · 12-05-2017, 07:05 PM

I am having some strange issues with my steam games. it seems as if for some reason the game is wanting to run the games' graphics through my CPU instead of my GPU. I was thinking a change in drivers should fix that problem.

KSysGuard shows all games having massive amounts of CPU usage (starbound in particular shows at least 90% usage on all cores!), and incredibly slow framerates ingame. However when I move the mouse out of the game screen, the cursor in XFCE works smooth as butter. I was thinking of changing my GPU driver, but when I found the page for the RX 480, it showed no option for a non-specific linux- just RHEL and Ubuntu. I'm leery at using drivers for another distro, for that matter, I don't know how to acquire the open source AMDGPU drivers, or if I'm even using them right now. Are the AMDGPU drivers a package or are they part of the kernel itself?

Also, in my attempt to optimize my gaming prowess, I have downloaded the latest stable source of the linux kernel, but I have an EFI system and thus, Elilo installed. what kind of differences and gotchas are there when installing a kernel in EFI vs a regular boot partition as listed here?

is it just as simple as changing "/boot" to "/boot/efi/EFI/Slackware/"?

dugan · 12-05-2017, 07:15 PM

Quote:

it seems as if for some reason the game is wanting to run the games' graphics through my CPU instead of my GPU.

You can check that with:

Code:

glxinfo | grep direct

If you see:

Code:

direct rendering: no

Then your drivers are using a CPU-based OpenGL implementation.

bassmadrigal · 12-05-2017, 07:40 PM

Quote:

Originally Posted by lawnm0wer

I was thinking of changing my GPU driver, but when I found the page for the RX 480, it showed no option for a non-specific linux- just RHEL and Ubuntu. I'm leery at using drivers for another distro, for that matter, I don't know how to acquire the open source AMDGPU drivers, or if I'm even using them right now. Are the AMDGPU drivers a package or are they part of the kernel itself?

The opensource amdgpu drivers are already included in Slackware, however, due to the age of 14.2, they aren't the newest versions. And unfortunately, AFAIK, the opensource drivers don't include proper support for your card until the 4.15 series kernel, which is in RC status now (I think it's speculated to be released in Jan).

That being said, if you want to be a little adventurous, I have a SlackBuild to repackage the pro driver from Ubuntu. Unfortunately, I don't have the hardware to test it, so I fixed what was reported by other users. It *should* also uninstall cleanly, so if it doesn't work, it shouldn't jack up your install.

Quote:

Originally Posted by lawnm0wer

Also, in my attempt to optimize my gaming prowess, I have downloaded the latest stable source of the linux kernel, but I have an EFI system and thus, Elilo installed. what kind of differences and gotchas are there when installing a kernel in EFI vs a regular boot partition [url=https://docs.slackware.com/slackbook:linux_kernel]as listed here?/url]

is it just as simple as changing "/boot" to "/boot/efi/EFI/Slackware/"?

If you place your kernel (and possibly initrd) in /boot/ and then run eliloconfig, it should copy them automatically. However, I personally don't like that because it clears your old elilo.conf and generates a new one, so if you had any options (or multiple kernels), it clears it all.

What I do is copy my kernels and initrds to /boot/ with the kernel version in their names, then I'll mount my EFI partition (it's not normally mounted on boot) and copy those files to /boot/efi/EFI?Slackware/ and then I'll modify the elilo.conf in there to add the extra entries. If you're semi-familiar with editing the lilo.conf file, you shouldn't have any issues here since the syntax is very similar.

After that, you don't need to do anything special to save it. Just reboot and you should be in your new kernel

lawnm0wer · 12-05-2017, 08:24 PM

thank you for the answers! ok, so direct rendering works, that said, I will build the kernel first and see if that helps my framerate issue.

If my problems persist, I will download bassmadrigal's slackbuild and cross my fingers! either way, I'll try to provide updates of my progress when possible!

lawnm0wer · 12-06-2017, 07:27 PM

ok, so my adventures in kernel compiling have resulted in a compiled alternate kernel that shuts my computer off the moment I try to boot it...

Well, sudden spectacular failures aside, upon following the steps to reinstate the generic kernel's config as listed here have shown me something- that the amdgpu driver apparently is already in the generic kernel- just as a module.

I'm a neophyte when it comes to kernel wizardry, as such, I don't know to enable this module, let alone through elilo.

the hopeful in me says something like this will work...

Code:

# Elilo.conf secondary boot entry using the generic kernel
image=vmlinuz       
        label=vmlinuz-amd   
        read-only
        append="root=/dev/sda1 vga=amdgpu ro"

...but the pessimist in me says "something will fall apart and give me no response whatsoever".

what must I append to load the amdgpu module during boot?

bassmadrigal · 12-06-2017, 08:38 PM

The amdgpu driver has been a part of the kernel for quite some time. However, it has seen significant changes over the years with more cards being supported and adding new features for already supported cards. You might already be loading the amdgpu driver. You can check that with the following command:

Code:

lspci -k | grep -iA3 vga

The vga= parameter is not used to load the driver, but to set the resolution and color depth of the computer during bootup.

lawnm0wer · 12-07-2017, 11:13 PM

Quote:

Originally Posted by bassmadrigal

The amdgpu driver has been a part of the kernel for quite some time. However, it has seen significant changes over the years with more cards being supported and adding new features for already supported cards. You might already be loading the amdgpu driver. You can check that with the following command:

Code:

lspci -k | grep -iA3 vga

The vga= parameter is not used to load the driver, but to set the resolution and color depth of the computer during bootup.

running that command shows me this:

Code:

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Device 67df (rev c7)
	Subsystem: PC Partner Limited / Sapphire Technology Device e347
01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Device aaf0
	Subsystem: PC Partner Limited / Sapphire Technology Device aaf0

the only thing I understand about it is that the GPU exists, and it's got an audio device- one that I'm not physically using.
is it really loading the module? for that matter, how would I load it upon boot?

bassmadrigal · 12-08-2017, 07:01 AM

It doesn't look like it's loading a module. If it did, it should show something like below:

Code:

00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09)
        Subsystem: Lenovo 2nd Generation Core Processor Family Integrated Graphics Controller [17aa:21d1]
        Kernel driver in use: i915
        Kernel modules: i915

This is likely because your card is new enough that the older module doesn't recognize it. So, because it doesn't recognize the device, it probably uses the generic VGA output, which leads to horrible performance.

Based on some research, it looks like basic support for your card was added in the 4.7 series kernel, so if you use any kernel from there on, it should hopefully have a module that supports your device.

You could grab the kernel from -current, which is the 4.9 series. I would suggest installing it using installpkg rather than upgradepkg, this way it will keep your old kernels around in case you run into booting issues. You'll also need to modify your bootloader to ensure both kernels are available to boot from. Do you know what bootloader you're using? lilo, grub, elilo?

For the kernels, I'd recommend grabbing kernel-genereic, kernel-huge, kernel-modules, kernel-firmware, and kernel-source packages. Don't worry about the kernel-headers package.

lawnm0wer · 12-08-2017, 05:48 PM

I use Elilo.

I managed to download the slackware-current kernel files that you suggested. I copied the "*-generic-4.9.67" files from /boot to /boot/efi/EFI/slackware, set up a boot entry, rebooted and got a kernel panic.

Code:

kernel panic-not syncing: VFS: unable to mount root fs on unknown block(8,2)

removing the system.map file & doing "ln -s System.map-vanilla-4.9.67 System.map" afterwards did not change anything. here is my elilo.conf.

Code:

default=vmlinuz
prompt
chooser=simple
delay=30
timeout=30
#
image=vmlinuz
        label=vmlinuz
        read-only
        append="root=/dev/sda2 vga=normal ro"
# generic
image=vmlinuz-generic-4.9.67
	root=/dev/sda2
	label=vmlinuz-amd
	read-only
	append="vga=normal ro"
	description = "slackware 64 Generic-4.9.67

I don't understand what I'm missing, I don't know if or why I would need an initrd, because I boot the current install fine without one...

bassmadrigal · 12-08-2017, 06:06 PM

If you load a generic kernel you need to generate an initrd for it. generic kernels don't contain drivers for the filesystems (and sometimes the motherboard components to read the drives). They are provided as separate modules, so you need to use an initrd to load those modules so it can actually read the harddrive.

To generate an initrd for the new kernel, you can use /usr/share/mkinitrd/mkinitrd_command_generator.sh -k 4.9.67 and then run the resulting command (although, I typically recommend adjusting the output file to contain the kernel version in it). Then, copy the resulting initrd to your /boot/efi/EFI/Slackware/ and add a reference to it in your elilo.conf using initrd=initrd-4.9.67.gz under the new entry.

Also, looking at your elilo.conf, you need to have your desired kernel as the first entry, so I'd change it so your 4.9.67 kernel is the first entry.

As an alternate to generating an initrd, you could also use the huge kernel, but Pat recommends only using the huge kernel for installation and switching to the generic with an initrd after installation is complete.

lawnm0wer · 12-08-2017, 06:42 PM

darn it all.
I've got the new generic kernel running, I've got the driver running, but my games' performance is still the same. they run terribly, it feels like the only thing that happened was that proper screen resolutions were recognized and that was it.

Code:

##insert angry rambling here.
bash-4.3# lspci -k | grep -iA3 vga
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Device 67df (rev c7)
	Subsystem: PC Partner Limited / Sapphire Technology Device e347
	Kernel driver in use: amdgpu
	Kernel modules: amdgpu

I don't know what to do, I don't get it, what did I miss?!

enorbet · 12-08-2017, 07:52 PM

lawnm0wer - With a card as sweet as many RX 480s are I recommend you try the AMD provided Pro driver asap. FWIW the open source seems a wee bit better than it's counterpart, nouveau is for nvidia, but still the manufacturer's own driver is simply needed for any serious gaming. Bassmadrigal has been a great help to so many slackers, including me with almost 20 years of slack use, that it is with zero reservation that I recommend you try his slackbuild. As he stated there should be no risk and you have a great deal to gain. I think you need to experience it for yourself first before venturing "whole hog" into kernel customization. Expertise in that area comes with time and experience and perhaps a visit --- HERE ---

bassmadrigal · 12-08-2017, 10:26 PM

Quote:

Originally Posted by lawnm0wer

darn it all.
I've got the new generic kernel running, I've got the driver running, but my games' performance is still the same. they run terribly, it feels like the only thing that happened was that proper screen resolutions were recognized and that was it.

Code:

##insert angry rambling here.
bash-4.3# lspci -k | grep -iA3 vga
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Device 67df (rev c7)
	Subsystem: PC Partner Limited / Sapphire Technology Device e347
	Kernel driver in use: amdgpu
	Kernel modules: amdgpu

I don't know what to do, I don't get it, what did I miss?!

That card is still relatively new and I don't know how well supported it was in the 4.9.x kernel. I think you also might be limited due to Slackware 14.2 only using mesa 11.2. Based on research, it sounds like support was added to mesa 12. So, -current would probably have much better support for your card using the open source drivers, but it is also a development branch and can frequently break 3rd-party programs as it develops to be the next stable release, so I don't know if that is a better option for you.

But the first thing to check now that we know it is using the amdgpu module is to ensure direct rendering is enabled and that it is not using software rendering. Can you post the output of the following? I have a feeling it isn't using proper hardware rendering because I think mesa in 14.2 is too old.

Code:

glxinfo | grep render

If you don't want to move to -current, the amdgpu-pro driver might be a better option because it uses a lot of its own binaries, overriding older/limited versions included in Slackware to hopefully provide you better support. Hopefully it builds fine with a 4.9 kernel, because it was still pretty new when I put together the SlackBuild. Looking at the 17.10 SlackBuild, I had commented out the kernel patches, so hopefully that means it builds without issue. But if it doesn't, I can look into it and see if I can find patches other distros are using. Or you could switch back to the 4.4 kernel, since I know that it builds the module without issue using that.

https://github.com/bassmadrigal/slac...ver.SlackBuild

orbea · 12-08-2017, 10:34 PM

No need to change to current to get a more modern graphics stack. Use Pat's slackbuilds in current to build a newer libdrm and then mesa, next build a newer kernel.

enorbet · 12-09-2017, 09:52 AM

Just FTR - While I haven't bought an AMD/ATi video card since the time when they nestled in ISA slots, I strongly suspect there are important parallels to graphics drivers for nVidia in that they know what works best for hardware they created. That is likely especially true in high midrange cards like the RX 480 which averages around $400.00 USD. Whether one is a gamer or into 3D creation and editing, 3D is the area in which Open Source graphics drivers tend to be far less effective.

Unfortunately this is often not understood or given far less concern than it deserves by those satisfied with onboard or under $100 addon cards. My point is if you care enough to spend ~400 smackers (I do... just bought an EVGA GTX 1070 Ti for 500) it is just a waste to persist with OSS. I love and respect OSS but in this area, graphics drivers, they can never truly compare so I say honor the fact that the GPL honors both OSS and Proprietary. OSS is a preference and rightly so but $400 isn't Free. Get what fits.