Linux Port – Feedback, Known Issues, and FAQ

/home/username/.local/share/BeamNG/BeamNG.drive/current/temp/

 

So I just... wipe it out?

--- Post updated ---

i'd like to formally apologize for wasting your time.

...it was night when i posted those pictures and i had it set to accurate time so i genuinely couldn't see anything.
0.39 is genuinely beautiful

 

Hi! Wanted to report a startup crash I've been having since forever.
BeamNG.drive pops open for about 6 seconds before closing.
Logs seemingly don't help as they cut off at different points in the bootup process and no errors seem relevant.
It also crashes with vulkan inside proton (so I'm forced to use the DX version in proton to be able to play), although I have not investigated whether it is for the same reason.

I have already tried with SDL_VIDEODRIVER unset and set to x11 and wayland.

The following are my specs

Spoiler: My Specs

Device: ThinkPad E16 Gen 3
CPU: Intel Core Ultra 7 255H
GPU: Intel Graphics (integrated)
RAM: 32GB
Distro: NixOS Unstable (latest as of Aug 14)
Kernel: Linux 6.18.44
Graphics Stack: Mesa 26.2.0
Desktop Environment: GNOME Shell 50.4
Compositor: Mutter 50.4
Display Protocol: Wayland 1.26.0

As this seemed like a game engine bug, I have attempted to get claude code to form a diagnosis by attaching a debugger and tracing the crash. This may or may not be worth something.

Spoiler: Claude's Diagnosis

BeamNG.drive 0.39.4.0, native Linux build (build 20972, linuxbuildbot 07/08/2026 18:16:32), BinLinux/BeamNG.drive.x64, BuildID 5203b3d5de5350907646940bd51fccfa5e2eca4a. Steam Runtime 3 (sniper). Hardware: Intel Arrow Lake-P iGPU [8086:7dd1], Mesa ANV.
The game reliably SIGSEGVs about 6 seconds into startup, before the menu is usable. The fault is a null dereference at address 0x68 on thread 0, inside anv_get_image_subresource_layout ← vk_common_GetImageSubresourceLayout ← BeamNG.drive.x64. The faulting instruction is cmpl $0x3b9d3330,0x68(%rsi) with rsi = 0. The Khronos validation layer reports the cause directly: vkGetImageSubresourceLayout(): image is VK_NULL_HANDLE / VUID-vkGetImageSubresourceLayout-image-parameter, i.e. the engine is calling vkGetImageSubresourceLayout with VK_NULL_HANDLE. A full API trace shows the call happens exactly once per run, and no vkCreateImage precedes it that produces the handle being passed — the image was never created on that path. Immediately before it there is a vkCreateImage(742×612, B8G8R8A8_UNORM, TILING_LINEAR, TRANSFER_SRC|TRANSFER_DST|SAMPLED, PREINITIALIZED) → vkGetImageMemoryRequirements2KHR → vkDestroyImage sequence, but that probe's handle (0x5c3edac4d00) is not the one passed to the layout query (0x0); that create/destroy pair looks like vmaFindMemoryTypeIndexForImageInfo and appears to be unrelated.
The affected resource is the CEF UI texture: 742×612 matches the window size exactly, and launching with -noui runs indefinitely with no crash and no null-handle diagnostic. The likely trigger is an integrated-GPU code path — this device reports 4 memory types in a single heap, all of them DEVICE_LOCAL | HOST_VISIBLE (memoryTypeBits = 3 for the image above), with no host-visible non-device-local type. That's typical UMA, and would select a "write the CEF bitmap straight into a host-visible linear image" upload path rather than the buffer-staging path a discrete GPU takes. On that path the layout is queried to get rowPitch while the image handle is still null. Ruled out during triage: mods (BeamMP removed — identical crash), Wayland vs X11 (identical on both), Mesa version (reproduced on both 26.1.5 and 26.2.0; predates any driver update), and cloud sync (the trailing Copying from local to cloud log line is just the last buffered write). Separately and probably harmlessly, vkCreateDevice enables VK_EXT_debug_marker without the required VK_EXT_debug_report instance extension (VUID-vkCreateDevice-ppEnabledExtensionNames-01387).
Reproducing and locating it should be quick: run on any UMA/integrated GPU with VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation. Since vkGetImageSubresourceLayout is invoked exactly once in a whole session, there is almost certainly a single call site in engine/graphics/backends/vk/ — grepping for it should land directly on the bug, and the fix is to create (and error-check) the image before querying its subresource layout, or to take the staging-buffer path. With symbols for build 20972, the reliable frame-pointer frames are BeamNG.drive.x64 + 0x1c82c86 and + 0x1b27477.

 

Have you tried launching the game executable directly (found in the BinLinux folder in the game files)? Also, if that doesn't work, try launching it in the terminal with the -safemode argument.

 

Unfortunately didn't help. Crashed with and without -safemode but in and outside steam. Although curiously when launching it from outside steam the crash reported DOES pop open instead of immediately and silently closing when launched via steam.

 

Hi,
Since the 0.39 update (where Wayland became default), I’ve been experiencing severe UI stuttering and flickering.

• When opening any menu, the UI stutters, and after about 1 second, it flickers.
• Changing the display refresh rate (e.g., dropping from 240Hz down to 60Hz) does not solve or change the issue.

My Observations:

1. MangoHud: Enabling MangoHud stops the stuttering.
2. XWayland: Launching the game through XWayland eliminates the stutter/flicker as well.

System Environment:

• OS: CachyOS
• DE/WM: Tested on both KDE Plasma and Hyprland (same behavior on both).
• GPU Drivers: 610.57.04

Hardware Specs:

• CPU: AMD Ryzen 7 7800X3D
• GPU: NVIDIA GeForce RTX 4070 Ti Super

Also Heres some more info about my drivers:
Installed From : cachyos-znver4
Name : nvidia-utils
Version : 610.57.04-1
Description : NVIDIA drivers utilities
Architecture : x86_64_v4
URL : http://www.nvidia.com/
Licenses : custom
Groups : None
Provides : vulkan-driver opengl-driver nvidia-libgl
Depends On : libglvnd egl-wayland egl-wayland2 egl-gbm egl-x11
Optional Deps : nvidia-settings: configuration tool [installed]
xorg-server: Xorg support
xorg-server-devel: nvidia-xconfig
opencl-nvidia: OpenCL support [installed]
Required By : lib32-nvidia-utils libglvnd linux-cachyos-lts-nvidia-open linux-cachyos-nvidia-open nvidia-settings steam upscayl-bin
Optional For : cuda ffmpeg libvdpau sdl3 vulkan-icd-loader
Conflicts With : nvidia-libgl
Replaces : nvidia-libgl
Installed Size : 885.66 MiB
Packager : CachyOS <admin@cachyos.org>
Build Date : Mon Aug 3 19:24:33 2026
Install Date : Sun Aug 9 18:55:14 2026
Install Reason : Explicitly installed
Install Script : Yes
Validated By : Signature

https://drive.google.com/file/d/1UXhUVUbsHRKjoS0ZD3vTCkvDQuTbp5rJ/view?usp=drive_link

 

Hey, the new update works wonderfully out of the box so far. The only major issue I encountered so far is that I could not get HDR to work using sway (1.12, which introduced HDR support) as my WM, despite my monitor confirming that it is getting an HDR signal.
I also tried wrapping through gamescope but that didn't work any better.
I found this line that could be related several times in the logs:

Code:

  1.08763|D|vulkan| HDR surface selection: requested=false, osHdrEnabled=true, supported=false, best=LDR, effective=LDR, swapchainColorspaceExt=true, hdrMetadataExt=true, chosenFormat=B8G8R8A8Unorm, chosenColorSpace=SrgbNonlinear, surfaceFormatCount=2

which looks odd as it recognizes that it was enabled in the OS yet deems it not supported. Maybe there's a sway quirk that makes beamng think it cannot do HDR (which I could get working with another game through wine on sway btw)?

WM: sway 1.12
OS: arch linux (latest updates as of posting this message)
BeamNG: 0.39.4.0

 

I am having this particular issue with my game after the 0.39 update - I gave it some time for the hotfixes and see if it was addressed, but it was not. Likely because of the unusual hardware and software combo. Distant light sources flicker a lot, basically the moment an LOD kicks in, pretty much. The game is unplayable at night - I am also suffering with pretty piss poor performance on WCUSA (30 FPS on Downtown Belasco, even before the update)? I am running what I can on ultra except for reflections which I have toned down significantly, but I was hoping my GPU would be more performant given what I see (From others admittedly) in Windows + the VRAM buffer. The performance issues date back to 0.38 either way.

Computer specs as follows - the most important thing is this PC is powered by Intel Arc Graphics - the B580 with 12 GB of VRAM to be precise:


Game Settings are as follows:


Hopefully the video of the graphics issue comes through. I'm more than happy to provide logs if needed given it's very likely the devs don't have an Intel Arc GPU as part of their testing configs

Mesa version is 26.3.0 Dev. This issue existed even with 26.1 and 26.2 releases though.
--- Post updated ---

Might as well attach the logs already.

 

you ever had an issue on GSP where the screen flickered black and the grids started moving at like... 120kph and up?

 

Sorry, don't play in Grid, Small, Pure enough. I'll give it a whirl but AFAIK to me the game is unplayable right now with all this going on.

 

YES! THIS IS THE ISSUE I MENTIONED! THE ONE I'M HAVING ON GSP! THIS, THE SCREEN FLICKERS BLACK AND THE GRIDS START MOVING!

 

Since we're back on the subject and I see someone asking about mango and whatnot, I'll add a question here as well.

I also suffered much from the stuttering until I added SDL_VIDEODRIVER=x11 %command% but my problem then become another one, albeit not gamebraking but still related to the above mangoHUD stuff...
I'm completely unable to make Vksumi working with BeamNG now. It refuses to load properly as the aforementioned commandline takes the spot where "/home/insertusername/.local/share/goverlay/gameconfig/BeamNG.drive/bgmod" %command% was.

I dont need mango per se but this is related to that since Goverlay manages mango, vkbasalt, vksumi and various other stuff.
I just want to adjust the shadow darkness and saturation via Vksumi but no matter how I try to combine both those commands into one at the steam launcher options, the game either crashes, fails to load, or does load but ignores the keyshortcut to toggle Vksumi efects on/off - as in, they dont work at all.
Pre 0.39 of Beam, I never needed the SDL command so the goverlay always worked. Now it seems we have to choose, one or the other.

I even went into the goverlays EnvVar settings for beam specifically and tried to add the SDL there as my own variable but I must admit I absolutely hate "tinkering" and in these cases, I miss the NVidia App that made these things soooo simple in Windows 11 Pro where I came from 2 months ago.

Some background about me:
I love CachyOS so far, but man, I suffer learning difficulties (a form of ADHD), absolutely hate using the Terminal and miss the simplicity of "it just works" that used to be Windows until about a year ago, when it turned into a slopfest and severe bugs delivered with every update - hence why I am now on Linux after some 30 years as a Windows user

 

On my linux system the issues are:
- HDR not functioning properly compared to the proton version

- UI (especially scrolling) being irresponsive and lagging behind a lot

My system specifications are:
CPU: AMD ryzen 7800X3D
GPU: AMD radeon RX 9070 [Discrete]
RAM: 32GB, 6000mhz cl30
(nvme) SSD: Samsung 990 pro 4tb (filesystem ext4)
Monitor: QD-Oled with HDR10 and DisplayHDR 400 certification

 

Hi devs! Sorry to bother you, but I have a very important question! I saw a recent video demonstrating DLSS, FSR 3, and FSR 4 antialiasing and upscaling! Very impressive! But can you tell me if they will work in the native Linux build of the game? I'm particularly interested in AMD technologies, since I have a graphics card from that company! Thanks in advance!

 

Additionally, will fsr4 have the newest version that makes it work on rdna2 and rdna3 cards?

 

Can you (the development team) submit a request to AMD to implement native Linux support for FSR 4? I think a request from a game development team will have more influence on a large company like AMD than a request from an ordinary gamer.

 

Any chance of getting ahold of someone at Intel? They've been trying to enable access to the XMX cores in the Battlemage GPUs via Proton to accelerate XeSS for gaming on Linux via a fork of Proton (At the moment for a proof of concept it seems), Linux is already able to access those cores natively anyhow for other tasks, so there has to be a way to implement XeSS natively and have it accelerated by the hardware on the card and not falling back to DP4a which is the vendor-agnostic fallback.

Disregard my comment if Intel has expressed no interest on Github or something, though.

 

Lots of people and companies have already asked for this and the issue is that AMD is using a specific directx12 thingy/api for FSR 4 and linux doesnt have directx12, why? idk its stupid AMD is the one who made vulkan...

 

But dx12 fsr4 works through vkd3d, so clearly there's a way to make things work