SteamOS Unreal Engine 5.8

Summary

SteamOS linux shipping build crashes on SteamDeck native

What Type of Bug are you experiencing?

Rendering (Graphics / Niagara)

Steps to Reproduce

Build project for linux shipping or development 5.8 , install on SteamDeck. Project crashes with missing implementation for store_deref aco_select_nir_intrinsics.cpp:5107

Expected Result

Game shall open without any issues.

Observed Result

steamos-mesa/src/amd./compiler/instruction_selection/aco_select_nir_intrinsic.cpp:5107
unimplemented intrinsic_instruction: @store_deref (wrmask=x, access=none)

Affects Versions

5.8

Platform(s)

Linux

Upload an image

I have exact same problem. No-code-change update from 5.7, which worked fine to 5.8; automation build, both development and shipping games produce the same error. The error happens right at the startup, at that time, there is only basic SlateUI showing the loading screen. The loading screen does not get drawn at all.

Looking at the logs, I see

ACO ERROR:
    In file ../steamos-mesa/src/amd/compiler/instruction_selection/aco_select_nir_intrinsics.cpp:5107
    Unimplemented intrinsic instr: @store_deref (%867, %870) (wrmask=x, access=none)
Signal 6 caught.
Malloc Size=262146 LargeMemoryPoolOffset=262162
CommonUnixCrashHandler: Signal=6
Alignment > 16 is not supported
Malloc Size=262146 LargeMemoryPoolOffset=524338
[2026.07.27-15.03.49:012][  0]LogCore: === Critical error: ===
Unhandled Exception: SIGABRT: abort() called

[2026.07.27-15.03.49:013][  0]LogCore: Fatal error!

0x00007f404ffaf74c libc.so.6!UnknownFunction(0x9774c)
0x00007f404ff55dc0 libc.so.6!gsignal(+0x1f)
0x00007f404ff3d57a libc.so.6!abort(+0x25)
0x00007f3fb75aa304 libvulkan_radeon.so!UnknownFunction(0x5aa303)
0x00007f3fb7523180 libvulkan_radeon.so!UnknownFunction(0x52317f)
0x00007f3fb7523871 libvulkan_radeon.so!UnknownFunction(0x523870)
0x00007f3fb7523851 libvulkan_radeon.so!UnknownFunction(0x523850)
0x00007f3fb7523851 libvulkan_radeon.so!UnknownFunction(0x523850)
0x00007f3fb7524666 libvulkan_radeon.so!UnknownFunction(0x524665)
0x00007f3fb7526989 libvulkan_radeon.so!UnknownFunction(0x526988)
0x00007f3fb7455721 libvulkan_radeon.so!UnknownFunction(0x455720)
0x00007f3fb7124832 libvulkan_radeon.so!UnknownFunction(0x124831)
0x00007f3fb70ff7b1 libvulkan_radeon.so!UnknownFunction(0xff7b0)
0x00007f3fb70ffc25 libvulkan_radeon.so!UnknownFunction(0xffc24)
0x00007f3fb70ffeba libvulkan_radeon.so!UnknownFunction(0xffeb9)
0x00007f3fb71000eb libvulkan_radeon.so!UnknownFunction(0x1000ea)
0x00007f3ff0faaf46 libVkLayer_steam_fossilize.so!UnknownFunction(0x92f45)
0x000000000ca6b8a6 KopiGame!FVulkanPipelineStateCacheManager::CreateComputePipeline(FComputePipelineStateInitializer const&)()
...

I tried looking for the exact line in CreateComputePipeline; which for me is the symbol FVulkanPipelineStateCacheManager::CreateComputePipeline(FComputePipelineStateInitializer const&) + 1318, but that simply is the call to VulkanRHI::vkCreateComputePipelines, so no further details.

...
3113: FScopedPipelineCache PipelineCacheShared =
               GlobalPSOCache.Get(EPipelineCacheAccess::Shared);
3114: Result = VulkanRHI::vkCreateComputePipelines(Device->GetHandle(), 
                   PipelineCacheShared.Get(), 1, &PipelineInfo, 
                   VULKAN_CPU_ALLOCATOR, &Pipeline->Pipeline);

I could not trace it to any particular failing [compute] shader, either.

Have you check 5.8.1? Has it solved the problem?

On 5.8.1 here on Ubuntu, same issue on my end. Packaged build is impossible to run, crashes almost immediately.

A little progress on 5.8.1: the “loading screen” Slate UI works, but the same issue happens once the game gets to open a world.

Could u check this thread It seems to be connected with our problem.

?

26.2.0

There are some intrinsic changes in the latest drivers. Maybe that solves the issue.

Mesa 26.2.0 gives the same exact problem on my end, unfortunately

Hey everyone,

Yeah, if this is what I think, the shader compiler would generate illegal SPIRV. I think this is what you’re hitting. We didn’t notice until late, some drivers handle it / others don’t. RADV doesn’t (it’s not their bug though!). It only shows up in certain shaders which you don’t usually hit using the editor. If you run a package build however, precaching will eventually try to create those pipelines and crash.

Disabling precaching might save you, but result in more hitches on the first run obviously.

…or…

The fix to the shader compiler has been submitted in UE6/Main. If you take the Engine/Binaries/ThirdParty/ShaderConductor folder from UE6/Main and copy it into your 5.8.1 build it should fix the issue (you need to recreate your package and make sure those shaders get rebuilt). Those binaries are pulled when you run the setup script if I’m not mistaken (not just through syncing). If anyone tries this, let me know how it goes!

…or…

Changing SHADER_PRINT_USE_GLOBAL_RESOURCE to always be 1 in ShaderPrint.ush might also solve the issue. You can do that by adding “|| VULKAN_PROFILE” to the #if above.

Cheers,
JN

1 Like

I followed the tutorial/instructions using the ShaderConductor folder from UE6/Main, recreated the package, and rebuilt the shaders as suggested.

It worked here on my Steam Deck! The packaged build now runs without the shader crash.

Thanks for the fix! :folded_hands:

1 Like

UE-393887 is ‘Closed’ as ‘Fixed’. The issue will be addressed in .

I can’t find this number in issues reporter: https://issues.unrealengine.com/issue/search?q=393887&resolution=&project=unreal_engine&component=&sort=

In which version of Unreal Engine will it be delivered 5.8.3? I’m using linux docker image to build my product.

I’ve just tried 5.8.3; no fix so far.

like this? Do I need to rebuild the engine?

#if ES3_1_PROFILE || VULKAN_PROFILE
#define SHADER_PRINT_USE_GLOBAL_RESOURCE 1
#else
#define SHADER_PRINT_USE_GLOBAL_RESOURCE 0
#endif

So, I also tried 5.8.3 with the ShaderConductor fix. This done by

  1. clone the UE source, checkout ue6-main branch.
  2. run ./Setup.sh to download the dependencies
  3. stash away the ShaderConductor directory

Then I checked out the 5.8 branch, and copied in the stashed away ShaderConductor from the ue6-main branch. After that, I made a native engine build of my game; it all worked as usual, producing the final Linux package.

However, when running it, it still failed, now with unaligned memory access at address 0x0000000000000000 (SIMD vectors?).

Signal 11 caught.
Malloc Size=262146 LargeMemoryPoolOffset=262162
CommonUnixCrashHandler: Signal=11
Alignment > 16 is not supported
Malloc Size=196610 LargeMemoryPoolOffset=458802
[2026.10.07-11.55.29:259][  0]LogCore: === Critical error: ===
Unhandled Exception: SIGSEGV: unaligned memory access at address 0x0000000000000000 (SIMD vectors?)

[2026.10.07-11.55.29:259][  0]LogCore: Fatal error!

0x00007f16d51a6b50 libvulkan_radeon.so!UnknownFunction(0x5a6b50)
0x00007f16d51e20b1 libvulkan_radeon.so!UnknownFunction(0x5e20b0)
0x00007f16d5245d11 libvulkan_radeon.so!UnknownFunction(0x645d10)
0x00007f16d51bfc64 libvulkan_radeon.so!UnknownFunction(0x5bfc63)
0x00007f16d51c0c22 libvulkan_radeon.so!UnknownFunction(0x5c0c21)
0x00007f16d51c2557 libvulkan_radeon.so!UnknownFunction(0x5c2556)
0x00007f16d50dd08e libvulkan_radeon.so!UnknownFunction(0x4dd08d)
0x00007f16d4d4b97a libvulkan_radeon.so!UnknownFunction(0x14b979)
0x00007f16d4d2567c libvulkan_radeon.so!UnknownFunction(0x12567b)
0x00007f16d4d25acf libvulkan_radeon.so!UnknownFunction(0x125ace)
0x00007f16d4d25d9a libvulkan_radeon.so!UnknownFunction(0x125d99)
0x00007f16d4d25fcb libvulkan_radeon.so!UnknownFunction(0x125fca)
0x00007f16e80b98c6 libVkLayer_steam_fossilize.so!UnknownFunction(0x938c5)
0x000000000ca9a996 KopiGame!FVulkanPipelineStateCacheManager::CreateComputePipeline(FComputePipelineStateInitializer const&) [/home/janmachacek/Sandbox/UnrealEngine/Engine/Source/./Runtime/VulkanRHI/Private/VulkanPipeline.cpp:3114]

Have I missed anything?

… and it turns out I have missed something; what helped me in the end is to make bump the version UUID in Engine/Shaders/Public/ShaderVersion.ush; in my case, I just incremented it by one to

// was ...9C8320D


#pragma message("UESHADERMETADATA_VERSION DDA9A115-612F-4F64-8206-999DB9C8320E")

After that, a native engine re-build of the game and voila! All works.

Nice it worked for you. But in my opinion cherry-picking from UE6-main to build UE5.8.3 and custom Engine building is not a fix. I rely on official docker images. When official linux image ships correct application then I’d be happy and treat this issue as solved.

I’m wondering the same thing. When can we expect a proper fix?

And if it takes some time, I’d need a workaround without building the engine myself