I purchased a system76 Thelio Mira Elite With a AMD Radeon RX 7900 XT. I kinda regret not going with Nvidia at this point but it is what it is. I primarily use it as a developer workstation, but want to play games on it as well so I can be rid of my windows box.
I didn’t expect it to be able to play the latest and greatest games but I did expect it to be able to play older titles reasonably well. Games launch from steam and seem to work, but I’m getting between 0 and 10 fps on the title screen of Kerbal Space Program. Other games are similarly functional but poorly performing.
Where do I start? How can I ensure my GPU is being leveraged? Is this as good as it gets?
I see the system you got came with a 4070 if was the elite or was custom?, Not sure if you try to reinstall pop is? Unless someone said it all ready. Its very weird that your video card giving you problem should just work.
When I select proton-experimental as the version under force proton runtime, I actually see usage in rocm-smi, however I get a black screen or that weird “see behind my window effect I screenshotted” in another comment. When I let it choose, I can see the game but sit at 0% utilization.
NVTOP - terminal top-like app, works well for AMD GPU stats.
Mission Control - flatpak, windows task manager style process monitoring, shows GPU stats, much like windows.
MangoHUD, in game overlay, showing live fps, CPU and GPU usage
This are the 3 I tend to use to monitor my system performance
(If you running a Wayland powered desktop, that may be a source of issues. I’ve had issues that I dont experience in good old X. But that was some time ago. My 6800XT performs as well as I expect it to under windows. Running NVIDIA on Linux is generally a real chore, AMD has been plug and play for me)
Make sure you have your monitor plugged into the GPU, not the motherboard.
This kinda sounds like that
It’s definitely plugged into the GPU. I’ve had plenty of opportunity to get acquainted with the back of my machine at this point. :,)
I just saw a meme about this, lol
Yup really does sound like that. I had a friend make this mistake when we upgraded some components in his computer last summer I asked him to plug everything back in…
In his case there wasn’t a GPU on the CPU so the computer wasn’t booting to any image.
We spent way too much time in the case second guessing my work only for me to go around to the back of the computer and facepalm.
Now i’m starting to doubt since this these responses have been so ubiquitous, but it’s definitely not plugged into the motherboard’s gpu slot. The motherboard has a single hdmi and displayport port. It, like all the other motherboard ports have a matte-black finish that matches the case. The displays are plugged into the glossy silver PCIE aligned hdmi and display ports, which doesn’t match the rest of the case. The card is doublewide, occupying 2 pcie slots and is labeled “ASROCK”.
I believe you’ve checked this correctly, but I want to clarify something: Even if the display is plugged into the graphics card, it’s still possible that your CPU’s integrated GPU (or even a CPU core) is being used for rendering, before sending the output to the display.
In other words, we’ve been asking where it’s plugged in not because that would definitively pinpoint the problem, but because it could influence what’s going on behind the scenes.
I hope System76 was able to help.
Gotcha, today is the first business day since filing my ticket. They’ve requested logs but no solutions yet.
What’s the point of purchasing from System76 and pay that premium along with their warranty and not utilise it?
Fair point, I should do that.
AMD GPUs are usually the best pick for Linux, and the RX 7900 XT is capable of a lot better performance than 0-10 FPS. (It will vary by game, settings, and resolution, of course. You didn’t mention the latter two.)
It’s possible your games are using the CPU’s integrated GPU instead of your graphics card. (Your iGPU is made for desktop use; it’s not suitable for most gaming.) Do any of your underperforming games have a screen that shows which GPU they are using? Is your monitor plugged into the motherboard’s video port, or one of the graphics card’s ports? Does an overlay appear in the top left of the screen if you put
DXVK_HUD=1 %command%in an underperforming game’s Steam Launch Options?It could also be that you don’t have a recent enough kernel, firmware, or mesa/vulkan drivers installed for that fairly new GPU model.
Since you bought from System76, I would guess that they have support staff who can help make sure these things are set up properly. They even have their own Linux distro, which I think is pretty well regarded. Have you called them?
Is this as good as it gets?
No. Not even close.
EDIT: Added note about DXVK_HUD in Steam Launch Options
Do any of your underperforming games have a screen that shows which GPU they are using?
I haven’t found any that do but I can try launching a few and searching.
Is your monitor plugged into the motherboard’s video port, or one of the graphics card’s ports?
GPU port, 100%
Since you bought from System76, I would guess that they have support staff who can help make sure these things are set up properly. Have you called them?
I had not thought of doing that for whatever reason, but I will in the daytime tomorrow.
Does an overlay appear in the top left of the screen if you put DXVK_HUD=devinfo %command% in an underperforming game’s Steam Launch Options?
For the 3 I’ve checked so far no, I don’t see that.
Do any of your underperforming games have a screen that shows which GPU they are using?
I haven’t found any that do but I can try launching a few and searching.
Take a look in each game’s graphics settings. Not all of them show it, but some do. In Baldur’s Gate 3, it’s shown in Options: Video: General: Display Adapter. In Elite Dangerous, it’s in Options: Graphics: Display: Adapter. There are other ways of trying to determine which GPU is likely to be used by default, but seeing it directly in-game is the best way to be sure.
Does an overlay appear in the top left of the screen if you put
DXVK_HUD=devinfo %command%in an underperforming game’s Steam Launch Options?For the 3 I’ve checked so far no, I don’t see that.
The fact that you see no DXVK overlay when using that launch option suggests that either none of the games you tried use DirectX 9/10/11, or there’s something missing/misconfigured/old in your Vulkan driver stack. I would expect System76 to be able to help with this more efficiently than we can, since they sold you the system for use with Linux and are known for being competent.
EDIT: I just noticed your other comment that shows Pop!_OS 22.04 LTS as your Linux distro. That release predates your GPU model by about a year, I think. It seems likely that you just need to get a newer kernel, firmware, and graphics drivers installed. This stuff is available upstream of your distro, so it shouldn’t be too hard for someone who knows Pop!_OS well, like System76. :)
.
EDIT: I just noticed your other comment that shows Pop!_OS 22.04 LTS as your Linux distro. That release predates your GPU model by about a year, I think. It seems likely that you just need to get a newer kernel, firmware, and graphics drivers installed. This stuff is available upstream of your distro, so it shouldn’t be too hard for someone who knows Pop!_OS well, like System76. :)
Yeah, that’s a good point, but:
-
It sounds like he bought a system with the GPU in there, and that it came with the distro pre-installed. I’m skeptical that System76 is gonna ship something without the software in place.
-
It’s an LTS release. I think that the way Ubuntu works – and presumably PopOS, though I’ve never used it – is that with LTS releases, they only do a major release every couple of years, but do push out updates for time-sensitive software like video drivers that require updates. If this were, like, the regular Ubuntu release, which has a six month release cycle, then I’d agree.
So I’d guess that the most-likely scenario is that whenever he bought the hardware, there was support in the OS, and they shipped the box with the current LTS release and with the necessary updates. That’s just a guess.
Like, when I said “you probably need newer drivers”, I was thinking that he was using some really elderly distro and just hadn’t ever updated it or something.
I would have expected System76 to ship it with all the necessary updates for the GPU, too, yet we haven’t seen any evidence of it, and we are seeing behavior consistent with it not being done. Maybe a human made a mistake somewhere along the line.
-
Take a look in each game’s graphics settings. Not all of them show it, but some do. In Baldur’s Gate 3
KK will do.
I would expect System76 to be able to help with this more efficiently than we can, since they sold you the system for use with Linux.
I will certainly reach out to them, but it hadn’t occurred to me until this post ¯_(ツ)_/¯
BTW, I edited my comments; you might want to re-read them if you didn’t catch the edits.
Don’t worry. This seems more like a software setup problem than faulty or weak hardware.
Good luck!
You can check nvtop (which also works with AMD and intel cards) which GPU is used how much.
A 7900xt is like top 5 consumer graphics cards ever made at the moment, so 10 fps on a 15 year old game is not normal. I have the same card and just beat Control and Space Marines 2 with max settings with ray tracing and it constantly stayed above 100fps, with a vast majority of its time maxed at 144.
The first thing to do is to download CS2 and see where you’re at with max graphics, you should get steady 144fps. If CS2 works, it’s your games you’re playing, check proton db and see if there is some common advice on settings/boot configs. Proton GE and Feral gamemode are two common tricks. There’s also an option to trick games into thinking you’re on a steamdeck that’s becoming more common. If you see something unexpected with those configs, you may need to dig into your bios and make sure your card is behaving there, and there are some profiling tools for GPUs. You may have to update your drivers depending on your distro. Not all 7900 cards are the same, depending on the company designing the card’s case, you may get different behavior on things like fans.
Their are some GUI tools that profile AMD GPUs, but I’ve found they don’t show must more than
sensorsandlsusbshow.Yeah it appears my card isn’t being used at all, which explains the poor performance. Honestly the fact the system runs as well as it does without it is impressive. I’m reaching out to system76 for their diagnostics on why this might be
A simple thing to check is did you plug your HDMI into the card or the motherboard? If it’s in the motherboard, the card won’t be used.
I didn’t expect it to be able to play the latest and greatest games
I have a 6800xt and can play literally all of them. There’s no reason you shouldn’t be able to.
I kinda regret not going with Nvidia at this point
Nooooo that would be a mistake with Linux.
I’m getting between 0 and 10 fps on the title screen of Kerbal Space Program
KSP will run on a RPi. There’s no reason you shouldn’t be able to run the title screen. Something is very wrong.
My advice would be to contact System76.
Being that it’s a pre built and preconfigured there’s very little room for user error.
Did you enable Steam Play in Steam settings, under compatibility?
Yeah I’ve tried several Steam Play options. I get different behavior from crashing to some wonky rendering of the windows behind it, but none work
There’s only one Steam Play option.
What do you mean? There are the following:
Proton experimental Steam Linux runtime 1.0 Legacy runtime 1.0 Proton hotfix Proton 9.0-4 …
If you mean just the global checkbox, yes that’s on
If you mean just the global checkbox
Yes, the option that says “Steam Play”.
I don’t think I have ever been GPU bound on KSP very well could be an issue with something else.
OP, I didn’t see if you’d confirmed that you’d enable Steam Play, see this article: https://support.system76.com/articles/linux-gaming
Kerbal Space Program has a Linux native client and a windows client. By default, Steam will try to install the Linux native client, which is using OpenGL and, apparently, doing software rendering.
You could try to troubleshoot why OpenGL is broken, you probably are missing an environmental variable or something to tell it to use a specific device and so it defaults to software. However, this is kind of a moot point. Development stopped on OpenGL in 2017 and so bugs and weirdness will continue to crop up and fixing it won’t resolve your core issue (Which may be that you’re just not using Proton).
If you’re going to game on this system then you should do what most people do and enable Steam Play and let Steam download the Windows version of KSP and run it through Proton (aka Steam’s version of WINE). Often the Windows versions of games are more supported than the Linux native versions and WINE/Proton do an excellent job of translating the underlying windows system calls into Linux-ese. Proton is the primary reason why gaming on Linux works, because it lets you just play the Windows version of games.
Your logs indicate that your graphics card is the default device for Vulkan and so it should just work as soon as you enable Steam Play. If you have any problems with other games (once you verify that you’re using your graphics card) you can look them up on Protondb (https://www.protondb.com/) and see if you need to make any setting changes. KSP looks to have a Gold rating and appears to work with Proton without any changes.
So steam play was already enabled, it looks like it defaults to "steam Linux runtime 1.0 (scout). When I select different versions of proton runtime I get different behavior dependig on which one I select.
Proton 9 says that it cannot switch to my monitors resolution,
Proton experimental and hot fix launch the game (I can hear it!), but things are … Weird. It only renders the windows behind it and the custom game cursor. When I alt enter to bring it into Windows mode, it’s still just the windows/desktop that would be behind the game but now it’s scaled differently.
EDIT:
It’s hard to tell but the above screenshot is the game window
Stay with experimental for now.
Do other games show a similar behavior or is it limited to KSP?
BG3 should work fine (was just playing it on Linux about 30m ago, but Arch, btw, etc).
You can get some extra logging from steam, if you exit completely and the, in a terminal, run:
steam -dIt’ll start Steam but output a lot of info to the terminal. The bit we’re interested in isn’t the stuff that it generates while Steam is starting. We want the bit that happens when you press play on a game. It’ll output the information about the important bits (like the Vulkan device, driver versions, monitors, etc )
Make sure there’s no obvious account info in the logs (there shouldn’t be, but always check) and post that.
I’m off to bed but I’ll check in with you tomorrow
Well I’ve installed BG3 just for the sake of testing and the DX11 launch results in a black screen. The Vulkan launch options crashing immediately…
Here is my steam logs when launching KSP I think the only thing of interest is this:
pressure-vessel-wrap[42106]: W: "opt/amdgpu/share/libdrm" is unlikely to appear in "/run/host" pressure-vessel-wrap[42106]: W: "opt/amdgpu/share/drirc.d" is unlikely to appear in "/run/host"Adding process 42106 for gameID 220200 Adding process 42107 for gameID 220200 pressure-vessel-wrap[42106]: I: pv_runtime_provide_container_access: Setting up runtime without using bwrap pressure-vessel-wrap[42106]: I: EGL ICD #0 at /usr/share/glvnd/egl_vendor.d/50_mesa.json: libEGL_mesa.so.0 pressure-vessel-wrap[42106]: I: Vulkan ICD #0 at /usr/share/vulkan/icd.d/intel_hasvk_icd.i686.json: /usr/lib/i386-linux-gnu/libvulkan_intel_hasvk.so pressure-vessel-wrap[42106]: I: Vulkan ICD #1 at /usr/share/vulkan/icd.d/radeon_icd.x86_64.json: /usr/lib/x86_64-linux-gnu/libvulkan_radeon.so pressure-vessel-wrap[42106]: I: Vulkan ICD #2 at /usr/share/vulkan/icd.d/intel_icd.x86_64.json: /usr/lib/x86_64-linux-gnu/libvulkan_intel.so pressure-vessel-wrap[42106]: I: Vulkan ICD #3 at /usr/share/vulkan/icd.d/virtio_icd.i686.json: /usr/lib/i386-linux-gnu/libvulkan_virtio.so pressure-vessel-wrap[42106]: I: Vulkan ICD #4 at /usr/share/vulkan/icd.d/intel_icd.i686.json: /usr/lib/i386-linux-gnu/libvulkan_intel.so pressure-vessel-wrap[42106]: I: Vulkan ICD #5 at /usr/share/vulkan/icd.d/radeon_icd.i686.json: /usr/lib/i386-linux-gnu/libvulkan_radeon.so pressure-vessel-wrap[42106]: I: Vulkan ICD #6 at /usr/share/vulkan/icd.d/intel_hasvk_icd.x86_64.json: /usr/lib/x86_64-linux-gnu/libvulkan_intel_hasvk.so pressure-vessel-wrap[42106]: I: Vulkan ICD #7 at /usr/share/vulkan/icd.d/lvp_icd.i686.json: /usr/lib/i386-linux-gnu/libvulkan_lvp.so pressure-vessel-wrap[42106]: I: Vulkan ICD #8 at /usr/share/vulkan/icd.d/virtio_icd.x86_64.json: /usr/lib/x86_64-linux-gnu/libvulkan_virtio.so pressure-vessel-wrap[42106]: I: Vulkan ICD #9 at /usr/share/vulkan/icd.d/lvp_icd.x86_64.json: /usr/lib/x86_64-linux-gnu/libvulkan_lvp.so pressure-vessel-wrap[42106]: I: Vulkan explicit layer #0 at /usr/share/vulkan/explicit_layer.d/VkLayer_INTEL_nullhw.json: libVkLayer_INTEL_nullhw.so pressure-vessel-wrap[42106]: I: Vulkan explicit layer #1 at /usr/share/vulkan/explicit_layer.d/VkLayer_MESA_overlay.json: libVkLayer_MESA_overlay.so pressure-vessel-wrap[42106]: I: Vulkan implicit layer #0 at /home/zamithal/.local/share/vulkan/implicit_layer.d/steamfossilize_i386.json: /home/zamithal/.steam/debian-installation/ubuntu12_32/libVkLayer_steam_fossilize.so pressure-vessel-wrap[42106]: I: Vulkan implicit layer #1 at /home/zamithal/.local/share/vulkan/implicit_layer.d/steamfossilize_x86_64.json: /home/zamithal/.steam/debian-installation/ubuntu12_64/libVkLayer_steam_fossilize.so pressure-vessel-wrap[42106]: I: Vulkan implicit layer #2 at /home/zamithal/.local/share/vulkan/implicit_layer.d/steamoverlay_i386.json: /home/zamithal/.steam/debian-installation/ubuntu12_32/steamoverlayvulkanlayer.so pressure-vessel-wrap[42106]: I: Vulkan implicit layer #3 at /home/zamithal/.local/share/vulkan/implicit_layer.d/steamoverlay_x86_64.json: /home/zamithal/.steam/debian-installation/ubuntu12_64/steamoverlayvulkanlayer.so pressure-vessel-wrap[42106]: I: Vulkan implicit layer #4 at /usr/share/vulkan/implicit_layer.d/VkLayer_MESA_device_select.json: libVkLayer_MESA_device_select.so pressure-vessel-wrap[42106]: I: Capturing glvnd loadable module #0: /usr/share/glvnd/egl_vendor.d/50_mesa.json pressure-vessel-wrap[42106]: I: Checking for implementation on x86_64-linux-gnu: libEGL_mesa.so.0 pressure-vessel-wrap[42106]: I: Captured glvnd loadable module #0: /usr/share/glvnd/egl_vendor.d/50_mesa.json pressure-vessel-wrap[42106]: I: Implementation on x86_64-linux-gnu: SONAME pressure-vessel-wrap[42106]: I: Capturing vulkan loadable module #0: /usr/share/vulkan/icd.d/intel_hasvk_icd.i686.json pressure-vessel-wrap[42106]: I: Checking for implementation on x86_64-linux-gnu: /usr/lib/i386-linux-gnu/libvulkan_intel_hasvk.so pressure-vessel-wrap[42106]: I: Capturing vulkan loadable module #1: /usr/share/vulkan/icd.d/radeon_icd.x86_64.json pressure-vessel-wrap[42106]: I: Checking for implementation on x86_64-linux-gnu: /usr/lib/x86_64-linux-gnu/libvulkan_radeon.so pressure-vessel-wrap[42106]: I: Capturing vulkan loadable module #2: /usr/share/vulkan/icd.d/intel_icd.x86_64.json pressure-vessel-wrap[42106]: I: Checking for implementation on x86_64-linux-gnu: /usr/lib/x86_64-linux-gnu/libvulkan_intel.so pressure-vessel-wrap[42106]: I: Capturing vulkan loadable module #3: /usr/share/vulkan/icd.d/virtio_icd.i686.json pressure-vessel-wrap[42106]: I: Checking for implementation on x86_64-linux-gnu: /usr/lib/i386-linux-gnu/libvulkan_virtio.so pressure-vessel-wrap[42106]: I: Capturing vulkan loadable module #4: /usr/share/vulkan/icd.d/intel_icd.i686.json pressure-vessel-wrap[42106]: I: Checking for implementation on x86_64-linux-gnu: /usr/lib/i386-linux-gnu/libvulkan_intel.so pressure-vessel-wrap[42106]: I: Capturing vulkan loadable module #5: /usr/share/vulkan/icd.d/radeon_icd.i686.json pressure-vessel-wrap[42106]: I: Checking for implementation on x86_64-linux-gnu: /usr/lib/i386-linux-gnu/libvulkan_radeon.so pressure-vessel-wrap[42106]: I: Capturing vulkan loadable module #6: /usr/share/vulkan/icd.d/intel_hasvk_icd.x86_64.json pressure-vessel-wrap[42106]: I: Checking for implementation on x86_64-linux-gnu: /usr/lib/x86_64-linux-gnu/libvulkan_intel_hasvk.soNo errors, that’s good and also not useful :/
As an aside, this is likely not the problem, but a good tip in general, is to use protonup to install GE-Proton (https://github.com/GloriousEggroll/proton-ge-custom). It is a community fork which essentially Proton Experimental + community fixes. The System76 article I linked above has the instructions (TL;DR, install protonup (terminal) or protonup-qt (GUI) and they’ll grab it for you and put it in the right directory, restart Steam and select the new version from the Compatibility menu either globally or per-game).
You essentially always want to be using the latest version of Proton unless something that was working breaks in a newer version.
So, next step, more logs:
You can enable proton logging by setting PROTON_LOG=1 as an environmental variable. You can do this per-game by right clicking a game -> Properties -> General and editing the launch options to say
PROTON_LOG=1 %command%Launch the game and let it crash or whatever. There will be a steam-$APPID.log in your home directory.
Well, back at it again. Tried ProtonGE with the same results. But the vulkan logs are interesting!
cat ~/steam-220200.log | grep errerr: Presenter: Failed to create Vulkan swapchain: VK_ERROR_INITIALIZATION_FAILED err: Presenter: Failed to create Vulkan swapchain: VK_ERROR_INITIALIZATION_FAILED err: Presenter: Failed to create Vulkan swapchain: VK_ERROR_INITIALIZATION_FAILED err: Presenter: Failed to create Vulkan swapchain: VK_ERROR_INITIALIZATION_FAILED err: Presenter: Failed to create Vulkan swapchain: VK_ERROR_INITIALIZATION_FAILED err: Presenter: Failed to create Vulkan swapchain: VK_ERROR_INITIALIZATION_FAILEDEDIT: more context
info: Presenter: Actual swapchain properties: info: Format: VK_FORMAT_B8G8R8A8_SRGB info: Color space: VK_COLOR_SPACE_SRGB_NONLINEAR_KHR info: Present mode: VK_PRESENT_MODE_IMMEDIATE_KHR (dynamic: no) info: Buffer size: 1920x1080 info: Image count: 4 err: Presenter: Failed to create Vulkan swapchain: VK_ERROR_INITIALIZATION_FAILEDIt’s filled with this error. The entire log is massive I cant even upload it to pastebin. If you want me to search for something specific lmk or how I can supply the entire log.
EDIT2: also found:
99664.262:00d4:00d8:err:xrandr:xrandr14_get_adapters Failed to get adapters 99670.682:0180:0184:err:ole:com_get_class_object class {82c5ab54-c92c-4d52-aac5-27e25e22604c} not registered 99670.683:00e8:033c:warn:threadname:NtSetInformationThread Thread renamed to L"wine_rpcrt4_io" 99670.683:0180:0184:err:ole:create_server class {82c5ab54-c92c-4d52-aac5-27e25e22604c} not registered 99670.684:0180:0184:fixme:ole:com_get_class_object CLSCTX_REMOTE_SERVER not supported 99670.684:0180:0184:err:ole:com_get_class_object no class object {82c5ab54-c92c-4d52-aac5-27e25e22604c} could be created for context 0x1599664.262:00d4:00d8:err:xrandr:xrandr14_get_adapters Failed to get adapters
Hmmm, this gets some hits. It seems like it isn’t able to figure out which driver to use.
You can specify the driver that Vulkan should use by adding an environmental variable VK_ICD_FILENAME set the the json file for your card.
Try editing a game and changing the launch options to:
VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/radeon_icd.x86_64.json %command%This removes that “Failed to get adapters” error from the proton log but the behavior remains the same and the VK_ERROR_INITIALIZATION_FAILED still persists
Games launch from steam and seem to work, but I’m getting between 0 and 10 fps on the title screen of Kerbal Space Program.
Something is definitely off on your system. I’ve a 7900 XTX (the slightly-higher-end version of that card), and while I don’t have the box in front of me, it definitely runs at at least reasonable (60fps+) rates at 2560x1440 on KSP. Might do well above that, dunno. It’s definitely not herky-jerky to the level you’re seeing, though.
Are you using Wayland or Xorg?
If you run
radeontop(in Debian trixie, package radeontop) it should tell you various load characteristics. There isn’t a GPU-agnostic utility to do this, unless things have changed since last I’ve looked – Nvidia and AMD both have their own utilities.I kinda regret not going with Nvidia at this point
Unless you’re aiming for AI stuff, where there are some significant benefits, like a large userbase and support for transformers, I’d probably recommend AMD for Linux use.
EDIT:
If you run
glxinfoon either Xorg (or Wayland, since the emulation layer will handle it), package mesa-utils on Debian trixie, it’ll tell you what OpenGL is trying to use. If you’re using hardware-accelerated stuff, you’ll get something like this:Vendor: AMD (0x1002) Device: AMD Radeon Graphics (radeonsi, gfx1103_r1, LLVM 19.1.4, DRM 3.59, 6.12.11-amd64) (0x1900)OpenGL renderer string: AMD Radeon Graphics (radeonsi, gfx1103_r1, LLVM 19.1.4, DRM 3.59, 6.12.11-amd64)That’s been the quick-thumb-in-the-wind test to know whether hardware 3d acceleration is running since just about forever. KSP probably doesn’t actually use OpenGL – I’d guess that it’s probably using DirectX going through some emulation layer in Proton to Vulkan – but if you’ve got something wonky like no usable 3D driver support for your GPU, that’ll show it up.
EDIT2: There’s also
vulkaninfoin (package vulkan-tools in Debian trixie). It’ll give you something like:GPU id : 0 (AMD Radeon Graphics (RADV GFX1103_R1)):EDIT3: If you’re using Xorg and that doesn’t show hardware acceleration in use, then the next thing that I’d probably look at is
/var/log/Xorg.0.logto see what Xorg is saying regarding your GPU. I don’t know much about diagnosing Wayland issues, as I’ve not been using it for all that long. The kernel log may also have interesting messages information (as root,journalctl -kbordmesg) if the problem is at the kernel level.glxinfo | grep Vendor
Vendor: Mesa (0xffffffff)glxinfo | grep Device
Device: llvmpipe (LLVM 17.0.6, 256 bits) (0xffffffff)glxinfo | grep “OpenGL rend”
OpenGL renderer string: llvmpipe (LLVM 17.0.6, 256 bits)Let me know if that’s not right. glxinfo dumps a lot of text but those are the only hits for your comment.
When I launch radeontop it prints this before launching, and then the output suggests it isn’t working:
Unknown Radeon card. <= R500 won’t work, new cards might.
All stats sit at 0.00% except for Memory Clock @ 9%.
EDIT:
xorg, not wayland
llvmpipe
Yeah, so it’s not using hardware acceleration then – your (poor) CPU has been trying to do all this in software emulation. I updated my comment above – take a look in Xorg.0.log if you’re on Xorg. My first guess is that you most-likely need newer drivers.
I know that these are new enough for the 7900 XTX; that’s current for Debian trixie, just to provide a known-good point in terms of driver version.
$ dpkg -l|grep radeon ii libdrm-radeon1:amd64 2.4.123-1 amd64 Userspace interface to radeon-specific kernel DRM services -- runtime ii libdrm-radeon1:i386 2.4.123-1 i386 Userspace interface to radeon-specific kernel DRM services -- runtime ii radeontop 1.4-2 amd64 Utility to show Radeon GPU utilization ii xserver-xorg-video-radeon 1:22.0.0-1 amd64 X.Org X server -- AMD/ATI Radeon display driverEDIT: You don’t say what distro you’re using. If you’re using Debian stable – I think I was when I first got my 7900 XTX, and IIRC they didn’t have driver support in at that point, though that was a while back now – you might check whether you have the backports repository present.
EDIT2: The first results for my search as to minimum supported version, though I wouldn’t take this as authoritative:
https://old.reddit.com/r/debian/comments/1301rph/radeon_7900_support/
Afaik 7900 needs preferably kernel 6.2+ and Mesa 23+.
EDIT3: Sorry, you did say which OS you were using – PopOS.
dpkg -l|grep radeon
ii libdrm-amdgpu-radeon1:amd64 1:2.4.120.60103-1787201.22.04 amd64 Userspace interface to radeon-specific kernel DRM services -- runtime ii libdrm-radeon1:amd64 2.4.120-1pop1~1706792268~22.04~bfb54ee amd64 Userspace interface to radeon-specific kernel DRM services -- runtime ii libdrm-radeon1:i386 2.4.120-1pop1~1706792268~22.04~bfb54ee i386 Userspace interface to radeon-specific kernel DRM services -- runtime ii radeontop 1.4-1 amd64 Utility to show Radeon GPU utilization ii xserver-xorg-video-radeon 1:19.1.0-2ubuntu1 amd64 X.Org X server -- AMD/ATI Radeon display driverI don’t know exactly what i’m looking for in the xorg logs… cat /var/log/Xorg.*.log | grep “EE”
cat /var/log/Xorg.*.log | grep “WW”
[ 5068.047] (WW) Falling back to old probe method for modesetting [ 5068.047] (WW) Falling back to old probe method for fbdevcat /var/log/Xorg.*.log | grep “gpu”
[ 5067.696] (II) Applying OutputClass "AMDgpu" to /dev/dri/card1 [ 5067.696] loading driver: amdgpu [ 5067.696] (==) Matched amdgpu as autoconfigured driver 0 [ 5067.696] (II) LoadModule: "amdgpu" [ 5067.696] (II) Loading /usr/lib/xorg/modules/drivers/amdgpu_drv.so [ 5067.696] (II) Module amdgpu: vendor="X.Org Foundation" All GPUs supported by the amdgpu kernel driversudo journalctl -kb | grep gpu
Feb 15 08:59:51 pop-os kernel: [drm] amdgpu kernel modesetting enabled. Feb 15 08:59:51 pop-os kernel: amdgpu: Virtual CRAT table created for CPU Feb 15 08:59:51 pop-os kernel: amdgpu: Topology: Add CPU node Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: enabling device (0006 -> 0007) Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: amdgpu: Fetched VBIOS from VFCT Feb 15 08:59:51 pop-os kernel: amdgpu: ATOM BIOS: 113-APM7199-002 Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: amdgpu: CP RS64 enable Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: [drm:jpeg_v4_0_early_init [amdgpu]] JPEG decode is enabled in VM mode Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: vgaarb: deactivate vga console Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: amdgpu: Trusted Memory Zone (TMZ) feature not supported Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: amdgpu: MEM ECC is not presented. Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: amdgpu: SRAM ECC is not presented. Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: amdgpu: VRAM: 16368M 0x0000008000000000 - 0x00000083FEFFFFFF (16368M used) Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: amdgpu: GART: 512M 0x00007FFF00000000 - 0x00007FFF1FFFFFFF Feb 15 08:59:51 pop-os kernel: [drm] amdgpu: 16368M of VRAM memory ready Feb 15 08:59:51 pop-os kernel: [drm] amdgpu: 64286M of GTT memory ready. Feb 15 08:59:51 pop-os kernel: [drm] GART: num cpu pages 131072, num gpu pages 131072 Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: amdgpu: Will use PSP to load VCN firmware Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: amdgpu: reserve 0x1300000 from 0x83fc000000 for PSP TMR Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: amdgpu: RAP: optional rap ta ucode is not available Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: amdgpu: SECUREDISPLAY: securedisplay ta ucode is not available Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: amdgpu: smu driver if version = 0x0000003d, smu fw if version = 0x00000040, smu fw program = 0, smu fw version = 0x004e7e00 (78.126.0) Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: amdgpu: SMU driver if version not matched Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: amdgpu: SMU is initialized successfully! Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: [drm:jpeg_v4_0_hw_init [amdgpu]] JPEG decode initialized successfully. Feb 15 08:59:51 pop-os kernel: amdgpu: HMM registered 16368MB device memory Feb 15 08:59:51 pop-os kernel: kfd kfd: amdgpu: Allocated 3969056 bytes on gart Feb 15 08:59:51 pop-os kernel: kfd kfd: amdgpu: Total number of KFD nodes to be created: 1 Feb 15 08:59:51 pop-os kernel: amdgpu: Virtual CRAT table created for GPU Feb 15 08:59:51 pop-os kernel: amdgpu: Topology: Add dGPU node [0x744c:0x1002] Feb 15 08:59:51 pop-os kernel: kfd kfd: amdgpu: added device 1002:744c Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: amdgpu: SE 6, SH per SE 2, CU per SH 8, active_cu_number 80 Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: amdgpu: ring gfx_0.0.0 uses VM inv eng 0 on hub 0 Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 on hub 0 Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 on hub 0 Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 6 on hub 0 Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 7 on hub 0 Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 8 on hub 0 Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 9 on hub 0 Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 10 on hub 0 Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 11 on hub 0 Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: amdgpu: ring sdma0 uses VM inv eng 12 on hub 0 Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: amdgpu: ring sdma1 uses VM inv eng 13 on hub 0 Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: amdgpu: ring vcn_unified_0 uses VM inv eng 0 on hub 8 Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: amdgpu: ring vcn_unified_1 uses VM inv eng 1 on hub 8 Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: amdgpu: ring jpeg_dec uses VM inv eng 4 on hub 8 Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: amdgpu: ring mes_kiq_3.1.0 uses VM inv eng 14 on hub 0 Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: amdgpu: Using BACO for runtime pm Feb 15 08:59:51 pop-os kernel: [drm] Initialized amdgpu 3.57.0 20150101 for 0000:03:00.0 on minor 2 Feb 15 08:59:51 pop-os kernel: fbcon: amdgpudrmfb (fb0) is primary device Feb 15 08:59:51 pop-os kernel: amdgpu 0000:03:00.0: [drm] fb0: amdgpudrmfb frame buffer device Feb 15 08:59:52 pop-os kernel: RAPL PMU: hw unit of domain pp1-gpu 2^-14 Joules Feb 15 08:59:52 pop-os kernel: snd_hda_intel 0000:03:00.1: bound 0000:03:00.0 (ops amdgpu_dm_audio_component_bind_ops [amdgpu]) ...uname -r
6.9.3-76060903-genericI think this is the mesa version?
OpenGL version string: 4.5 (Compatibility Profile) Mesa 24.1.0-develcat /etc/os-release
NAME="Pop!_OS" VERSION="22.04 LTS" ID=pop ID_LIKE="ubuntu debian" PRETTY_NAME="Pop!_OS 22.04 LTS" VERSION_ID="22.04" HOME_URL="https://pop.system76.com/" SUPPORT_URL="https://support.system76.com/" BUG_REPORT_URL="https://github.com/pop-os/pop/issues" PRIVACY_POLICY_URL="https://system76.com/privacy" VERSION_CODENAME=jammy UBUNTU_CODENAME=jammy LOGO=distributor-logo-pop-osThose are the kernel and Mesa versions, and at least assuming that the thing I linked above is correct as to minimum versions, you should be okay as to versions of those.
And if this is the out-of-box preinstalled OS from System76, I’d think that it’d be set up out of box for hardware acceleration. Hmm.
glxinfo | grep Vendor
Vendor: Mesa (0xffffffff)Yep, you’re using software rendering and your extremely fast GPU is sitting there idle. Talk to System76 about enabling the correct driver.
(That was obvious from the initial “0-10 FPS in KSP” symptom, of course – even my 7-year-old AMD GPU, a Vega 56, can run that game just fine, and I’m pretty sure the AMD GPU I had before that could too.)
vulkan-tools | grep “GPU id”:
GPU id = 0 (Radeon RX 7900 GRE (RADV NAVI31)) GPU id = 1 (Intel(R) Graphics (RPL-S)) GPU id = 2 (llvmpipe (LLVM 15.0.7, 256 bits)) GPU id = 0 (Radeon RX 7900 GRE (RADV NAVI31)) GPU id = 1 (Intel(R) Graphics (RPL-S)) GPU id = 2 (llvmpipe (LLVM 15.0.7, 256 bits)) GPU id = 0 (Radeon RX 7900 GRE (RADV NAVI31)) GPU id = 1 (Intel(R) Graphics (RPL-S)) GPU id = 2 (llvmpipe (LLVM 15.0.7, 256 bits)) GPU id = 0 (Radeon RX 7900 GRE (RADV NAVI31)) GPU id = 1 (Intel(R) Graphics (RPL-S)) GPU id = 2 (llvmpipe (LLVM 15.0.7, 256 bits)) GPU id = 0 (Radeon RX 7900 GRE (RADV NAVI31)) GPU id = 1 (Intel(R) Graphics (RPL-S)) GPU id = 2 (llvmpipe (LLVM 15.0.7, 256 bits)) GPU id = 0 (Radeon RX 7900 GRE (RADV NAVI31)) GPU id = 1 (Intel(R) Graphics (RPL-S)) GPU id = 2 (llvmpipe (LLVM 15.0.7, 256 bits)) GPU id = 0 (Radeon RX 7900 GRE (RADV NAVI31)) GPU id = 1 (Intel(R) Graphics (RPL-S)) GPU id = 2 (llvmpipe (LLVM 15.0.7, 256 bits)) GPU id : 0 (Radeon RX 7900 GRE (RADV NAVI31)): GPU id : 1 (Intel(R) Graphics (RPL-S)): GPU id : 2 (llvmpipe (LLVM 15.0.7, 256 bits)):cat /var/log/Xorg.*.log | grep amd
[ 5067.696] (II) LoadModule: "amdgpu" [ 5067.696] (II) Loading /usr/lib/xorg/modules/drivers/amdgpu_drv.so [ 5067.696] (II) Module amdgpu: vendor="X.Org Foundation" All GPUs supported by the amdgpu kernel drivercat /var/log/Xorg.*.log | grep gpu
[ 5067.696] (II) Applying OutputClass "AMDgpu" to /dev/dri/card1 [ 5067.696] loading driver: amdgpu [ 5067.696] (==) Matched amdgpu as autoconfigured driver 0 [ 5067.696] (II) LoadModule: "amdgpu" [ 5067.696] (II) Loading /usr/lib/xorg/modules/drivers/amdgpu_drv.so [ 5067.696] (II) Module amdgpu: vendor="X.Org Foundation" All GPUs supported by the amdgpu kernel driver[ 5067.696] (II) Applying OutputClass “AMDgpu” to /dev/dri/card1
Make sure that you actually have permission to that /dev/dri/card1 device. This may be arranged by udev or “video” group membership.
Regarding AMD vs Nvidia, unless you need CUDA you probably made the right choice. This sounds like a config issue and you’d probably be dealing with the same thing with Nvidia too.
Yeah I’m pleasantly surprised by the unanimous responses that AMD seems to be the way to go in this space. At this point I know it’s not using my GPU at all, so you are right that nvidia wouldn’t be any different
GPU id : 0 (Radeon RX 7900 GRE (RADV NAVI31)):
That may mean that you have accelerated graphics via Vulkan. I’m familiar with
glxinfo’s output, and I’m pretty sure that the fact that it’s not listing your GPU means that OpenGL apps won’t have hardware acceleration, but not sure whatvulkaninfodoes if it has no hardware acceleration available – I’m not certain that having the GPU listed there means that it has 3D acceleration, or whether it can list something running via software emulation.Hmm. This may take a bit of feeling about, as a bit of this is new territory for me too.
When you run
vkcube– which uses Vulkan – it’ll show a spinning cube and print a single line of text about the GPU used. What does it show for you?EDIT: Okay, apparently vkcube doesn’t do what Vulkan apps are supposed to do by default – it tries to pick a discrete GPU, so it’s probably not the best sanity test for “what is a Vulkan-using program trying to render to”.
I’m going to assume that the fact that
vulkaninfocan see the GPU means that it’s accelerated, though. If that’s true:-
You probably have 3D acceleration at the kernel and Xorg levels.
-
Kerbal Space Program has a Linux-native binary (on Steam, this shows up as that SteamOS icon), so it’s probably not going through Proton’s DirectX emulation, and from there to Vulkan, which it would if it only had a Windows binary. It looks like it has both an OpenGL and a DirectX rendering path on Windows. Typically games like this with a Linux-native release use the OpenGL path on Linux. kagis At least as of 2021, it looks like it was indeed using only OpenGL on Linux. So if you don’t have accelerated OpenGL, then it’s presumably not going to be accelerated.
-
I don’t think that
glxinfoshould be showing “llvmpipe”. I’m pretty sure that that means that you don’t have accelerated OpenGL available.
Take this with a grain of salt – I’ve not run into an actual system where Vulkan-using games are accelerated, and OpenGL games are not. This is a guess. But it’d at least vaguely fit my understanding of what you’ve provided. I’m fuzzy on the relationship between Vulkan, OpenGL, and Mesa – I don’t know what exactly it might take to create issues for OpenGL but not Vulkan.
Okay, after some poking around, I did find at least one mechanism that could possibly cause OpenGL to not be accelerated but Vulkan to be accelerated:
https://superuser.com/questions/106056/force-software-based-opengl-rendering-on-ubuntu
Alternately, you can set LIBGL_ALWAYS_SOFTWARE=1, which will only affect programs started with that environment variable, not the entire system.
I also confirmed that it produces the output that you’re seeing on my system – with that set,
glxinforeturns llvmpipe, even thoughvulkaninfohas GPU id 0 being the Radeon card. So if you’ve got that environment variable set somewhere, that could produce the behavior you’re seeing.@zamithal@programming.dev, I don’t know how you could have gotten that set, but in whatever terminal you were running
glxinfoandvulkaninfo, can you runset|strings|grep LIBGLand see if maybe that’s set? If it is, maybeunset LIBGL_ALWAYS_SOFTWAREand then from that terminal startsteamagain and see if Kerbal Space Program runs fine then?It doesn’t appear to be set and additionally I don’t appear to have the
libgl1-mesa-swx11package mentioned in that post.set|strings|grep LIBGL
apt list | grep libgl1-mesa
libgl1-mesa-dev/jammy 24.0.3-1pop1~1711635559~22.04~7a9f319 amd64 libgl1-mesa-dev/jammy 24.0.3-1pop1~1711635559~22.04~7a9f319 i386 libgl1-mesa-dri/jammy,now 24.0.3-1pop1~1711635559~22.04~7a9f319 amd64 [installed,automatic] libgl1-mesa-dri/jammy,now 24.0.3-1pop1~1711635559~22.04~7a9f319 i386 [installed,automatic] libgl1-mesa-glx/jammy-updates 23.0.4-0ubuntu1~22.04.1 amd64 libgl1-mesa-glx/jammy-updates 23.0.4-0ubuntu1~22.04.1 i386This does remind me that while developing a webgl canvas based javascript app the other day I was forced to go into firefox’s about:config and set webgl.force-enabled = true. I should have dug deeper on that.
It doesn’t appear to be set
Ah, okay. Bit of a long shot.
and additionally I don’t appear to have the libgl1-mesa-swx11 package mentioned in that post.
You shouldn’t need it – that’s for software rendering.
You might want libgl1-mesa-glx, but it sounds from that page like that was restructured prior to your distro release.
https://askubuntu.com/questions/1517352/issues-installing-libgl1-mesa-glx
ibgl1-mesa-glx has been a transitional package for a while and is now obsolete from Ubuntu 23.10 and onwards.
Installing libgl1 and libglx-mesa0 instead of libgl1-mesa-glx will result in equivalent behaviour and should work on Ubuntu 18.04 and newer.
Both libgl1:amd64 and libglx-mesa-0:amd64 are installed on my system. Are they installed on yours? If not, if they are available in your apt repo, maybe do so and see if your problems disappear?
-
deleted by creator
nvtopalso works with AMD now and is way nicer thanradeontopIMOAh, neat, thanks.
Curious. Do you have a “run on discrete GPU” option when you right click an app icon?
Iirc that feature is exposed on GNOME. Maybe you couldn’t steam on discrete GPU option as a troubleshooting step?
That said I use both AMD cpu and GPU and it correctly defaults to the discrete GPU so this may not be the case
Even the IGPU should get better performance than that. I played Kerbal Space Program on a 2011 MacBook Air and got at least 30 fps.
I don’t appear to have this.
There’s a program called amdgou_top you can use to see the breakdown of components on the GPU(s) and their utilization, as well as what apps are running on the GPU
which distro is it? there are many that were not made with gaming in mind
This is Pop_Os, which is System76’s ‘ubuntu like’ distro that comes shipped with vendor maintained drivers. It comes preinstalled with steam and is intended to be able to use it right out of the box. I’ve opened a ticket with them to discuss it further
don’t use it. It is totally left without support nowadays. They are developing COSMIC, a new Wayland desktop enviroment and Pop OS is abandoned. System 76 pcs support other distros too. You need something based on Fedora Atomic or Arch
My goal for this system was to eject windows from my life prior to the launch of Windows recall. That and host a bunch of docker containers in an environment more reliable than windows. I got impatient waiting for cosmic to reach full support, but still wanted to go with the distro system76 ships as “theirs” as opposed to putting Ubuntu on their hardware. I haven’t checked if cosmic is officially out yet but will likely switch over when it is. I’m a novice with Linux btw. I can use it to host and run my software but wanted a prepackaged solution for my devbox so that I have a much lower chance of breaking it. Also things like my Wacom tablet just worked out of the box, which is all big plus.
Unless you’ve solved the issue by know, I would recommend to install openSUSE Tumbleweed. It’s an “beginner friendly” “stable” rolling release distribution with rollback support. After the first update, everything should just work.
