It'll work for a few seconds then this happens.

Hey there. I know this is 4 years old, but I am kinda desperate. I recently bought an index, and had extreme frame drops on wayland, even though it is recommended on plasma. Fixed it with using x11, but Half Life Alyx crashes at the first loading screen after the glove tutorial. Did you ever find a fix for this?

Same, I tried Steam VR Beta and stable both of them crash when going into the new loading screen that the train uses, was looking forward to replaying HL:A :(

• Distribution: Fedora 41
• Drivers: Mesa 24.2.8
• GPU: AMD 6950XT

Same issue, for me causes a complete GPU crash and kills all video output, both to my headset and to my monitors.

Still happening on the latest Steam VR beta 2.13.3 with Mesa 25.1.7, my system does freeze for a bit while amdgpu resets after that the game is still running but of course non-functional due to steam vr dying.

[ 3779.119562] amdgpu 0000:03:00.0: amdgpu: Dumping IP State
[ 3779.121765] amdgpu 0000:03:00.0: amdgpu: Dumping IP State Completed
[ 3779.121774] amdgpu 0000:03:00.0: amdgpu: [drm] AMDGPU device coredump file has been created
[ 3779.121775] amdgpu 0000:03:00.0: amdgpu: [drm] Check your /sys/class/drm/card1/device/devcoredump/data
[ 3779.131780] amdgpu 0000:03:00.0: amdgpu: ring gfx_0.0.0 timeout, signaled seq=2392657, emitted seq=2392659
[ 3779.131783] amdgpu 0000:03:00.0: amdgpu: Process information: process vrcompositor pid 43128 thread RenderThread pid 43180
[ 3779.131785] amdgpu 0000:03:00.0: amdgpu: Starting gfx_0.0.0 ring reset
[ 3779.352436] amdgpu 0000:03:00.0: amdgpu: Ring gfx_0.0.0 reset failed
[ 3779.352442] amdgpu 0000:03:00.0: amdgpu: GPU reset begin!
[ 3779.453900] [drm] failed to wait for GRBM(EA) idle
[ 3779.455015] amdgpu 0000:03:00.0: amdgpu: restore config space...
[ 3779.455085] amdgpu 0000:03:00.0: amdgpu: GPU reset succeeded, trying to resume
[ 3779.455746] [drm] kiq ring mec 2 pipe 1 q 0
[ 3779.466496] amdgpu 0000:03:00.0: amdgpu: GPU reset(3) succeeded!
[ 3779.466509] amdgpu 0000:03:00.0: [drm] device wedged, but recovered through reset

Theres other issues about this which are more than likely the same bug:

• https://github.com/ValveSoftware/SteamVR-for-Linux/issues/784
• https://github.com/ValveSoftware/SteamVR-for-Linux/issues/801

I think I found a way to fix that, I managed to finish the game.
First, use Proton. if the latest version doesn't work, use ProtonGE.
Then, go to the performance menu, click on the gear icon, and scroll down to switch Vulkan to the DirectX API.
Unplug secondary monitors (you might get a full-screen error on steamVR) , and make sure the headset is already connected on steamVR when launching the game, otherwise loading a save will crash.

Some time, loading screens may crash.

I also install amdvlk, it seem to be more stable then RADV on the game (so i switch on the vulkan API in the game)
But the steamoverlay will be glitchy so you need to start the game on the computer.

You can also wait about 6 months, the game should receive a native Linux update when the Steam Frame is released

Hope this helps =)

After lots of frustration with the game not running at all with Proton 10 or newer and crashing when using DirectX or Vulkan both with Proton 9 or native on a level transition I finally found a combination that allowed me to complete the Level:

GE-Proton-10-3 with DirectX 11 on the latest Mesa 25.3.3-1 (because there was a bug in earlier Mesa 25.3 patchlevels preventing SteamVR from starting). I also had my secondary screen disconnected but I’m not sure whether that contributed.

I will try with my secondary screen connected and going for newer versions of Proton / GE-Proton to get a clearer picture but for now a knuckle needs to charge …

//edit 1: Unplugging the second monitor was unnecessary.

//edit 2: Switch to a more recent version of Proton / GE-Proton re-introduced the issue and now I cannot progress by entering the Northern Star. It stays broken at the moment even with GE-Proton 10-3. Attempts to use -safe_mode, switching to Plasma X11 (which had troubles connecting to the headset, I did not spend much time trying to fix that) or any other version did not fix this.

But one thing I noticed when switching to the Linux native version and Proton 5 is that newer versions of Proton do not show the city map in the loading screen anymore which may be directly related to the transition issue as I recall having issues with the loading screen even in 2020. Which would actually the same issue as #784 from @JulianHeuser I guess.

As @JulianHeuser pointed out in #784 simply renaming/removing Steam/steamapps/common/Half-Life Alyx/game/hlvr/models/ui/dioramas fixed the issue for me.

@kisak-valve Maybe this ticket, #784 and #801 all belong together?

I have this issue too

PC specs are:
AMD Ryzen 7 9700X
Radeon RX 9070 XT 16GB
32GB DDR5 6000MT/s RAM
Arch Linux (kernel 6.18.7-arch1-1)
GNOME 49.3 wayland

There's no throttling due to temps happening

@kivoli What are these diorama's and what makes these non-essential? I'd like to know what the implications are of removing or renaming this folder.

@InFerYes The only thing that removing those files will do is make the loading "screens" a blank void, rather than a 3d model. You can always verify the game cache to get them back, and they won't break anything in-game.

I have just tried renaming this folder and unfortunately the game still crashes at the same spot: loading the train level right after getting the gun.

Made a recording of the issue:
https://www.twitch.tv/videos/2686315588?t=00h05m02s

TL;DR bellow
SOLUTION BELLOW THIS COMMENT

Hi everyone. This issue bothered me a lot so I decided to play around with it more.

The first thing I noticed was that in the folders under Half-Life Alyx/game/hlvr/models/ui/ all just contained a mix of obj models, mat materials, dds textures and text files for layout.

The obj files all load fine into blender in which I was able to build the sets without any problem. Adding the textures was also easy but what confused me was that blender apparently referenced png files. When I replaced them with dds they showed their low quality outlines but I still wanted to figure out if this was a blender bug or actual correct behavior. I took a closer look into the mat files and discovered that they weren't referencing the dds files but instead their png counterparts for some reason? I guess the engine only sees that it has to load textures and runs down an internal list of file endings for whatever reason.

I started with the map hologram folder used file to inspect them to be in the BC7_UNORM_SRGB format. Then I used the tool magick to convert these dds files to the png format, removed the dds files, in case the game looks for them and the level transition ran perfectly fine. All the buildings loaded in and even highlighted where I already was like they should. I don't know if it was from my modification but sometimes the game crashes in the menu and it appears to be basically random (could also be my graphics driver giving up from the frequent crashes and one system hang).

Initially I didn't patch the dioramas, only the hologram map since in my playthrough I was still inside the train before the quarantine zone and it for some weird reason didn't require the fix. The same with a2_pistol, which is the room right after you open the tunnel.

I thought this was the ultimate fix, but for some reason the very next diorama, which is a2_hideout (the box-shaped room right after the headcrab encounter), crashed my game again. The rooms apparently are all Microsoft DirectDraw Surface (DDS): 8192 x 8192, compressed using BC4U with the exception for a3_c17_processing_plant-c1.dds, which is Microsoft DirectDraw Surface (DDS): 8192 x 8192, DXGI format: BC7_UNORM. ffmpeg allowed me to convert all the files to png with the exception of a3_c17_processing_plant-c1.dds for which I was able to use gimp interestingly enough. There I just loaded it without mipmaps and exported it without any further info. magick only really works with BC7_UNORM_SRGB for me.

Can someone else please also try and test this? I feel like I might've stuck gold with this one, but a real fix is also wanted since my and a lot of other people's systems should be able to use those textures just fine. Would also love for someone at Valve to take a look at this finding and maybe allow for a fix later up because as it is right now the game is not playable.

EDIT: Played through act 2 and experienced no further crashes, however all dioramas are now blank. Will investigate this further
EDIT2: HUGE BREAKTHROUGH!!! The pngs MUST be in the format 8-bit gray+alpha, non-interlaced

TL;DR
In Half-Life Alyx/game/hlvr/models/ui/, you can use a combination of magick for BC7_UNORM_SRGB in map_hologram_steamvr, ffmpeg for BC4U and gimp for diorama/a3_c17_processing_plant-c1.dds in dioramas to convert all dds textures to png. Make sure to delete the dds source files after the conversion.

Example script for fish shell

for f in *.dds;
    magick "$f" "$f.png"
end

for f in *.dds;
    ffmpeg -n -i "$f" "$f.png"
end

My Setup is:
SteamVR & HL:A native
Linux 6.19.10-1-cachyos
KDE Plasma 6.6.3 wayland
AMD Radeon RX 9070 XT
Latest and greatest packages

SCRATCH THAT. THIS IS STILL INCREDIBLY INCONSISTENT AND FOR SOME REASON THE GAME CACHES THESE TEXTURES, WHICH MAKES TESTING HARDER

For whatever reason, the cause for these crashes is that the textures inside Half-Life Alyx/game/hlvr/models/ui/diorama and Half-Life Alyx/game/hlvr/models/ui/map_hologram_steamvr fail to load and crash the compositor.

Luckily however you can convert these into pngs with the format 8-bit gray+alpha and it'll work perfectly fine. Most MTL material definitions already reference png images (with a few exceptions), but the engine resolves to their dds counterpart, if it exists so you need to make sure to delete those too after the conversion.

The process is as follows:

1. Try: ffmpeg -y -i "blah_blah.dds" -pix_fmt ya8 "blah_blah.png"
2. If that fails, try: magick "blah_blah.dds" -colorspace gray -define png:color-type=4 -depth 8 "blah_blah.png"
3. If that fails, try manually converting it via gimp. Export it as a png with the pixel format 8bpc GRAYA
4. Use the file command on your shiny new png make sure it says 8-bit gray+alpha
5. Delete the dds file afterwards
6. Patch material files if required. See Exception 2

DEPENDENCIES: ffmpeg, magick

⚠️ THERE ARE EXCEPTIONS ⚠️

1. dioramas/a3_c17_processing_plant-c1.ddg fails and must be manually converted using GIMP. Load the image and export it as a png, but make sure to select the pixel format 8bpc GRAYA
2. Some material files reference dds textures, so just change them to png. These are:
   1. map_hologram_steamvr/a2_drainage.mtl replace map_Kd a2_drainage_wire.dds with map_Kd a2_drainage_wire.png
   2. map_hologram_steamvr/a4_c17_zoo.mtl replace map_Kd a4_c17_zoo_wire.dds with map_Kd a4_c17_zoo_wire.png
   3. dioramas/a1_intro_world_2.mtl replace map_Kd a1_intro_world_2.dds with map_Kd a1_intro_world_2.png
   4. dioramas/a5_vault.mtl replace map_Kd a5_vault.dds with map_Kd a5_vault.png
   5. dioramas/valve_baked.mtl replace map_Kd valve_baked.dds with map_Kd valve_baked.png

With the help of AI I then cobbled together the scripts at the bottom to convert everything in the current folder. Use with caution.

FISH version

#!/bin/fish
for f in *.dds
    set out (string replace -r '\.dds$' '.png' $f)

    echo "--- Processing: $f ---"

    if ffmpeg -y -i "$f" -pix_fmt ya8 "$out" >/dev/null 2>&1
        echo "✅ FFmpeg Success"
        rm "$f"
    
    else 
        echo "⚠️ FFmpeg failed, trying Magick..."
        if magick "$f" -colorspace gray -define png:color-type=4 -depth 8 "$out" >/dev/null 2>&1
            echo "✅ Magick Success"
            rm "$f"
        else
            set_color red
            echo "    ❌ Could not convert $f"
            set_color normal
            continue
        end
    end

    set file_info (file "$out")
    echo "🔍 Verify: $file_info"
    
    if not string match -q "*8-bit gray+alpha*" "$file_info"
        set_color yellow
        echo "    ❌ Warning: Expected output type mismatch."
        set_color normal
    end
end

echo "--- All files processed ---"

Bash Version

#!/bin/bash

for f in *.dds; do
    out="${f%.dds}.png"

    echo "--- Processing: $f ---"

    if ffmpeg -y -i "$f" -pix_fmt ya8 "$out" >/dev/null 2>&1; then
        echo "✅ FFmpeg Success"
        rm "$f"
    
    else 
        echo -e "⚠️ FFmpeg failed, trying Magick..."
        if magick "$f" -colorspace gray -define png:color-type=4 -depth 8 "$out" >/dev/null 2>&1; then
            echo "✅ Magick Success"
            rm "$f"
        else
            echo -e "    ❌ Could not convert $f"
            continue
        fi
    fi

    file_info=$(file "$out")
    echo "🔍 Verify: $file_info"
    
    if [[ ! "$file_info" == *"8-bit gray+alpha"* ]]; then
        echo -e "    ❌ Warning: Expected output type mismatch."
    fi
done

echo "--- All files processed ---"

Run either one in both Half-Life Alyx/game/hlvr/models/ui/dioramas as well as Half-Life Alyx/game/hlvr/models/ui/map_hologram_steamvr and remember to check the exceptions.

!!! HAVE FUN !!!

@Andreas010 Hi, I'm trying to use your fix but I'm having trouble with conversion. ImageMagick doesn't have the magick on Mint, it seems to use the convert command instead because it's IM6..? And it can't seem to recognise DirectDraw textures. Gimp reads some of the dds images in dioramas, but doesn't like the images in map_hologram_steamvr, apparently that can't read DDS either, nor can ffmpeg.

at the moment, I'm just trying to get something to read the DDS files in map_hologram_steamvr.

Also, would converting to png remove the mipmaps?

Edit: Also, thanks for working on this! Glad to see it's not a dead end.

@Pugnippets Hi there! Sorry I don't have enough info about how magick is packaged on distributions other than mine. Could be the case that it's some sort of licensing issue and that you need to compile it yourself maybe? I personally don't think removing the mips affects anything as the map looks the same and the textures look fine.

The dioramas however are incredibly finicky. I'd try scaling them down to half or quarter resolution before launching the game, because it for some reason struggles loading those and caches that somewhere somehow. Eventually it'll let go of the cached image and load the new one but it seems to be really unpredictable and random

Volvo please fix

@Andreas010 In the end, I renamed the dioramas folder completely, and the other associated loading screen files, and that fixed it. Seemingly. I can now play the game without it crashing.

That said, I don't want to volunteer you for extra work, but would it be worth throwing together a zip folder of modified assets? Just to compare what it should look like?

@Pugnippets Idk if I can do that as that would probably be considered redistributing game files? I hope not, otherwise I'll get rid of these
map_hologram_steamvr.tar.gz dioramas.001.tar.gz dioramas.002.tar.gz dioramas.003.tar.gz

Thank you so much for this! HL:Alyx runs beautifully now on my setup

Thank you so much!

No Problem. @andreasbeh @Pugnippets Do the dioramas show up for you? For me they majorly still appear black and when I replace the texture with a simple 512x512 basic white one, I still only get that to work on a 40% basis

No Problem. @andreasbeh @Pugnippets Do the dioramas show up for you? For me they majorly still appear black and when I replace the texture with a simple 512x512 basic white one, I still only get that to work on a 40% basis

Hi @Andreas010 - first of all - Thank you for coming up with the fix!

As for what I've seen till now (chapter 3) it worked like a charm and all dioramas seem to render seemingly correctly even without scaling them down. Not sure if that'll last for long. Tell me at which point you remember diorama not loading at the earliest, and I'll try to confirm if that's issue for me as well.

Cheers ✌️

@CezaryKierzyk
The last place I used to tinker with the missing dioramas was in the hotel basement, when you do a jump down from a ledge after having defeated the blue headcrab dog thing (https://youtu.be/zSW2pc3kmqk?si=FW-IqjgZVCfK_6WZ&t=9403). It was the most convenient at the time because there's just enough space for me to save there and rapidly test my changes.