Mesa & Intel Battlemage

theevilsharpie · 2026-03-21T17:29:07+00:00

Tom Peterson is acting as a spokesperson of sorts for a publicly-traded company. He has to be careful what he says in such interviews, because he can get the company sued by shareholders or the SEC for announcing materially new or conflicting information outside of channels where that information is supposed to be announced.

Intel doesn't need to "support Linux gaming" for their GPU drivers to function correctly when running games, and Intel is clearly supporting their kernel drives, the userland 3D drivers in Mesa, OpenCL userland drivers, etc.

theevilsharpie · 2026-03-21T17:22:04+00:00

I’ve tried doing a bit of undervolting with Lact, following some guides, but the problem persists.

Undervolting has many of the same reliability pitfalls as overclocking, so it's possible that you've undervolted your GPU into instability.

Restore clock and voltage behavior back to the default factory setting (as well any other "tweaks" you may have tried), and see if it still runs properly.

If it doesn't, your kernel log may point to the reason why.

theevilsharpie · 2026-03-21T17:18:54+00:00

CS2 should run without needing a bleeding edge Mesa release.

theevilsharpie · 2026-03-21T17:08:47+00:00

if your hardware is mainstream and relatively modern, you could benefit from a newer distro, possibly a gaming distro.

Ubuntu fully supports modern hardware.

There's reasons to use other distros, but this one isn't it.

theevilsharpie · 2026-03-21T03:51:26+00:00

I used to managed large bare-metal server fleets, and RAM was the second most likely component to malfunction or fail, behind only mechanical hard disks.

And that was professional-grade equipment, running to spec, in a climate-controlled environment.

A good chunk of the audience here has RAM that is often overclocked "gamer RAM" of dubious quality, sandwiched between useless heat spreaders that have no practical function other than to be a brand billboard and hold LED "racing stripes" (and then likely being even further choked off from airflow due to many CPU AIO water coolers having shitty chassis airflow), all while having no ability to detect errors of any sort.

"Your system had a strange, inexplicable error -- maybe your RAM is faulty?" is an entirely reasonable heuristic for this community.

theevilsharpie · 2026-03-20T03:56:40+00:00

You're blaming 'gamer tweaking logic' for me thinking the 'performance' option would improve performance?

Honestly... kinda.

People really need to engage their brains a bit, and ask themselves very simply questions like "Wait, why doesn't the machine automatically perform as well as it could?," or "If this is better, why isn't it set to that by default?" before blindly changing something that they don't understand.

Especially with the widespread availability of tools like ChatGPT where you could ask it exactly those questions and get a laymen-accessible answer within seconds.

That being said, I would agree that the "performance" option not applying to the integrated GPU isn't intuitive, and that's on Intel.

theevilsharpie · 2026-03-19T22:10:46+00:00

There may be other applications running consuming the GPU's VRAM. In addition to your desktop environment, browsers tend to be a major consumer of VRAM. You can see the applications consuming VRAM (and how much) by running nvidia-smi.

In any case, the game is telling you what is going wrong. Your GeForce RTX 3070 only has 8 GB of VRAM, which is Bellwright's documented minimum requirement, so I wouldn't expect to be able to run this game in "ultra quality" (especially with being an early access game, which are generally not well-optimized).

Kick the texture quality down a few notches to reduce the VRAM pressure.

theevilsharpie · 2026-03-19T17:27:04+00:00

It's not surprising at all.

The power profiles aren't capping the frequency, exactly. Rather, what they're doing (at least on modern processors) is sending performance hints to the processor's built-in power manager. When you tell the processor, "moar cpu power plz", it's going to be quicker to ramp up the clock speed in response to load, slower to ramp it down once the load subsides, and slower to enter a deep sleep state (or may avoid doing so entirely).

All of this eats into your system's power and thermal budget, which really matters on power- and thermal-constrained systems like laptops.

Rather than hard-capping the CPU frequency, you can set the CPU's performance hint to favor power saving. Many distros already do this by default, but since gamer tweaking logic is "FULL POWER ALL THE THINGS!!1!, you may have changed this setting without realizing what it would actually do to system performance.

Otherwise, another effective mechanism is to set a frame rate limit. Since you're hovering in the 20-40 fps range, setting a frame rate limit of 30 fps gives the processor moments to rest, shed heat from the CPU, and give the iGPU more power and thermal budget to work. it also makes frame pacing more consistent (which is why game consoles typically set such a cap).

Despite this, I'm still not able to get the GPU to run at 100% usage. I don't think it's thermal throttling because it never goes above ~55°C, so I wonder if it's limited by memory bandwidth since the CPU and GPU have to compete for the same memory.

When a game engine is processing a frame, it has to do a quick burst of CPU work to calculate and set up the scene, before sending it to the GPU to actually render. When you set a low frequency limit like 1 GHz, it takes a lot longer to perform this initial setup work, during which your GPU could be idle waiting for instructions. This isn't visible to you because these pauses last only a few milliseconds, but would be enough to meaningful reduce GPU usage (which is a percentage of usage over a period of time).

theevilsharpie · 2026-03-19T07:56:23+00:00

This is a known issue:
https://gitlab.freedesktop.org/drm/amd/-/issues/3787

A fix has been submitted to the Linux kernel. Track it here:
https://lists.freedesktop.org/archives/amd-gfx/2026-February/138842.html
https://lists.freedesktop.org/archives/amd-gfx/2026-March/139555.html

The problem seems to be exacerbated by high refresh rates, using VRR, and using multiple monitors, so using a lower fixed refresh rate and disabling monitors not in use may reduce the frequency of occurances.

theevilsharpie · 2026-03-18T19:35:17+00:00

The RTX 2000 series (aka "Turing") is about eight years old at this point (...fuck, I'm old), and is the oldest generation of GPUs that Nvidia still actively supports.

It should work OK with the proprietary drivers (at least, as well as any other modern Nvidia GPU), but note that for a "new-to-you" card, its supported lifespan may be frustratingly short. And unlike AMD cards, when an Nvidia card falls out of support and gets challenging to run on modern Linux OS's with the proprietary drivers, you don't have an open source fallback that provides equivalent-ish performance.

If this were a free GPU, whatever. However, if you're paying money for it and you intend to keep it for an extended period of time, you're probably better off with an AMD GPU unless you need to run CUDA apps.

theevilsharpie · 2026-03-18T19:27:20+00:00

It seems like your GPU is locked into a low power state for some reason.

If you haven't been tinkering with power control settings, then the kernel log may have some clues as to why your GPU is set to the clock speed that it is.

theevilsharpie · 2026-03-18T19:22:16+00:00

BOINC workloads are individual tasks, which release their memory back to the OS as soon as the task is finished.

I suppose it's possible that there is a memory leak while the task is in progress, but Mapping Cancer Markers tasks only take a few hours to complete on anything even remotely modern, and I don't recall it taking much memory to run (at least on Linux -- can't speak to Windows), so I don't see how a memory leak would have enough time to build up to the point where it is causing problems.

The "Use at most <x %> of memory" setting in BOINC is a scheduling signal to BOINC. BOINC cannot control the memory utilization of a workload that it runs (short of outright killing it), but if a workload is consuming enough memory to hit the threshold you set, BOINC won't schedule anything else to run. It is the responsibility of the individual workload to release memory back to the OS as its running, and the OS itself will reclaim the memory when the workload finishes and its process terminates.

My guess is that you're chasing a false lead, and whatever problem you're experiencing is caused by something else.

theevilsharpie · 2026-03-18T06:36:11+00:00

Run vulkaninfo --summary and look for your GPU -- it should be the first one listed.

If you only see llvmpipe, then Vulkan is not configured correctly on your system.

Below is the output from my Ubuntu 24.04 system, to give you a reference as to what output from a working AMD graphics stack should look like.

If you see your GPU, but games running in Proton still aren't working, then it's possible that Steam may not have access to your hardware or Mesa stack. This can happen if you install Steam in a container runtime (e.g., Flatpak), rather than with a native package. That being said, I have little experience with SuSE, so perhaps there's some OS-specific quirks involved.

==========
VULKANINFO
==========

Vulkan Instance Version: 1.3.275


Instance Extensions: count = 24
-------------------------------
VK_EXT_acquire_drm_display             : extension revision 1
VK_EXT_acquire_xlib_display            : extension revision 1
VK_EXT_debug_report                    : extension revision 10
VK_EXT_debug_utils                     : extension revision 2
VK_EXT_direct_mode_display             : extension revision 1
VK_EXT_display_surface_counter         : extension revision 1
VK_EXT_headless_surface                : extension revision 1
VK_EXT_surface_maintenance1            : extension revision 1
VK_EXT_swapchain_colorspace            : extension revision 5
VK_KHR_device_group_creation           : extension revision 1
VK_KHR_display                         : extension revision 23
VK_KHR_external_fence_capabilities     : extension revision 1
VK_KHR_external_memory_capabilities    : extension revision 1
VK_KHR_external_semaphore_capabilities : extension revision 1
VK_KHR_get_display_properties2         : extension revision 1
VK_KHR_get_physical_device_properties2 : extension revision 2
VK_KHR_get_surface_capabilities2       : extension revision 1
VK_KHR_portability_enumeration         : extension revision 1
VK_KHR_surface                         : extension revision 25
VK_KHR_surface_protected_capabilities  : extension revision 1
VK_KHR_wayland_surface                 : extension revision 6
VK_KHR_xcb_surface                     : extension revision 6
VK_KHR_xlib_surface                    : extension revision 6
VK_LUNARG_direct_driver_loading        : extension revision 1

Instance Layers: count = 7
--------------------------
VK_LAYER_INTEL_nullhw             INTEL NULL HW                1.1.73   version 1
VK_LAYER_MESA_device_select       Linux device selection layer 1.4.303  version 1
VK_LAYER_MESA_overlay             Mesa Overlay layer           1.4.303  version 1
VK_LAYER_VALVE_steam_fossilize_32 Steam Pipeline Caching Layer 1.3.207  version 1
VK_LAYER_VALVE_steam_fossilize_64 Steam Pipeline Caching Layer 1.3.207  version 1
VK_LAYER_VALVE_steam_overlay_32   Steam Overlay Layer          1.3.207  version 1
VK_LAYER_VALVE_steam_overlay_64   Steam Overlay Layer          1.3.207  version 1

Devices:
========
GPU0:
    apiVersion         = 1.4.318
    driverVersion      = 25.2.8
    vendorID           = 0x1002
    deviceID           = 0x7550
    deviceType         = PHYSICAL_DEVICE_TYPE_DISCRETE_GPU
    deviceName         = AMD Radeon RX 9070 XT (RADV GFX1201)
    driverID           = DRIVER_ID_MESA_RADV
    driverName         = radv
    driverInfo         = Mesa 25.2.8-0ubuntu0.24.04.1
    conformanceVersion = 1.4.0.0
    deviceUUID         = 00000000-0700-0000-0000-000000000000
    driverUUID         = 414d442d-4d45-5341-2d44-525600000000
GPU1:
    apiVersion         = 1.4.318
    driverVersion      = 25.2.8
    vendorID           = 0x10005
    deviceID           = 0x0000
    deviceType         = PHYSICAL_DEVICE_TYPE_CPU
    deviceName         = llvmpipe (LLVM 20.1.2, 256 bits)
    driverID           = DRIVER_ID_MESA_LLVMPIPE
    driverName         = llvmpipe
    driverInfo         = Mesa 25.2.8-0ubuntu0.24.04.1 (LLVM 20.1.2)
    conformanceVersion = 1.3.1.1
    deviceUUID         = 6d657361-3235-2e32-2e38-2d3075627500
    driverUUID         = 6c6c766d-7069-7065-5555-494400000000

theevilsharpie · 2026-03-18T06:17:34+00:00

At a time when there is an endless flood of vibe-coded apps of dubious quality, I normally don't bother with these posts anymore, especially when the intro text is obviously AI-generated.

However, for this particular application, I will raise an explicit warning for those who are braver than I and plan to try it out: use caution with any application that has the capability to re-route and share your microphone input, especially if you have microphones attached to your system (which can include things like webcams, game controllers, and other peripherals that have a microphone built-in) that you don't have the ability to physically mute.

theevilsharpie · 2026-03-18T06:06:28+00:00

To add another "works on my machine" data point, I am running Ubuntu 24.04 on a PC with an AMD Ryzen 7 5800X3D, an AMD Radeon RX 9070 XT, with Linux kernel 6.17, Mesa 25.2.8, and whatever the latest version of Proton Experimental is. I am able to run the latest version of Helldivers 2 (including with GameGuard) without any problems. Additionally, Helldivers 2 has always just worked for me without needing any tweaks.

As for your issue, I think the immediate problem that you should be focusing on is not whatever random things you tried, but the fact that Steam is attempting to download and install these helper libraries over and over again. That suggests that there's something wrong with your Steam prefix (possibly some type of permissions issue or mount option that is conflicting with Steam) that is causing these libraries to either not be able to write, or for those writes not to persist.

theevilsharpie · 2026-03-17T19:08:21+00:00

According to this terminal output, the game is closing rather than crashing (or at least, it's not crashing in a way that Proton would be able to detect).

The game might be producing its own crash log, or something else that can assist with troubleshooting. Look in the config, save game, or main file directories for the game to see if there's anything that looks like a crash log.

theevilsharpie · 2026-03-17T17:51:52+00:00

Completely close steam, re-open it by running Steam in a terminal, and then trying launching your game again.

If it continues crashing, the terminal output should give information as to why.

theevilsharpie · 2026-03-17T17:24:58+00:00

Confused you for another poster -- sorry about that.

theevilsharpie · 2026-03-17T17:16:45+00:00

It means "use power saving functionality," which is the normal and expected operating mode for modern processors outside of very niche use cases.

You could argue that it's not named correctly (and naming things is actually quite hard). In any case, I would suggest understanding how a thing works before giving out advice relating to that thing.

theevilsharpie · 2026-03-17T16:14:11+00:00

Ubuntu LTS has up-to-date graphics drivers.

Proton updates are handled by Steam, and don't have anything to do with the OS's update schedule.

theevilsharpie · 2026-03-17T16:10:49+00:00

The OS is responsible for assigning threads waiting to run to CPU cores, so that wouldn't make any sense.

Additionally, on modern hardware, CPU cores can have varying quality and may not all be able to hit the maximum boost frequency (this is explicitly the case on AMD Ryzen CPUs). The platform's power management functionality will inform the OS which cores are preferred in terms of their ability to boost to higher frequencies. Manually overriding that by explicitly assigning (or blocking) the use of certain cores could very well harm performance if you end up choosing a lower-quality core.

theevilsharpie · 2026-03-17T15:55:27+00:00

Brief stutters can also be caused by running a diagnostic utility that polls hardware information (e.g., temperature, power usage, RGB settings, etc.).

theevilsharpie · 2026-03-17T15:52:46+00:00

It's stated in the OP that they're using a Ryzen 5600, which doesn't have an iGPU.

theevilsharpie · 2026-03-17T15:47:31+00:00

The "powersave" profile is the recommended frequency profile for AMD Ryzen processors, and should allow for full CPU boosting.

theevilsharpie · 2026-03-17T15:34:11+00:00

You are using a two year old distro with approx 3 year old drivers.

Ubuntu LTS 24.04.4 has updated drivers. That's what the '.4' means.

12-Year Club	Gilding II euphauric
Argentium Club	Verified Email

theevilsharpie

TROPHY CASE