Hello, after upgrading from 5.4 source version to 5.6 source version from GitHub our builds no longer run under SteamOS.
TargetPlatform: Win64
We haven’t taken any steps to make our builds compatible with Steam OS and do not aim to support a native Linux application and SteamOS hasn’t been an officially targeted platform for us. However from time to time we checked whether it would run on SteamOS and up until our upgrade to 5.6 there were no issues. Since 5.6 it suddenly crashes on start up.
What we found so far is, that enabling `VulkanTargetedShaderFormats=SF_VULKAN_SM5` in the WindowsTargetSettings and running the build with -vulkan launch parameter seems to help with the crashes.
Is there anything else we can do to trouble shoot the crashes?
Did someting significantly change between 5.4 and 5.6 that suddenly makes it necessary for the vulkan shader models to be present?
If there is any other info I can provide, please let me know.
We regularly test our Win64 DX12 Lyra sku on Steam Deck before the UE releases and the 5.6 version and Main they should work with the latest version of Steam OS.
There are been several significant changes between 5.4 and 5.6 on the DX12 layer but no one that requires you to have the Vulkan shader and RHI enabled as well.
From the fact that the game works with Vulkan but not with DX12 I can deduct the problem might reside on the Proton translation layer that Steam OS is using (DX -> VK) and possibly related to your game setup.
You could try to switch Proton version to see if there is a bug there.
Are you getting any information in the engine log?
To get more debug logging from Proton you can also try to set the launch options to `PROTON_LOG=1 %command%`.
You could also using `DXVK_NVAPI_LOG_LEVEL=trace`.
This will creates log files in /home/deck/ named steam-$NUMBERS.log
If you could replicate the issue on the Deck with just a simple level coming from your setup please send the project my way and I can help identify the issue and enter in contact with Valve if we identify is a OS issue.
Feel free to reach Valve directly if you’ll get information being an issue at their level.
Hi [mention removed] and thanks a lot for the answer!
I am quite new to the Steam Deck, so I didn’t know about those commands, or where to find that log.
What I could learn from the log with PROTON_LOG=1 %command% launch parameter is that the Steam Deck is using Proton 9.0-4f. The last error before the game crashed in the steam*.log is:
err:msvcrt:_wassert(L"idom-succ.size() >= 2", L"../scrvkd3d-proton/subprojects/dxil-spirv/cfg_structurizer.cpp", 4108)The project’s log just stops without any direct information about why the crash occurred. Last error in the project’s log is:
LogNNERuntimeORT: Failed to create DXCore Adapter Factory, DxCoreCreateAdapterFactory error with code :80004002I also got some new information: Because of your answer and the info from the log I tested out the latest Proton Experimental (10.0-20251017) version for our game.
With that one it actually starts up again without forcing it to use vulkan, though it takes a while and goes into background first, I have to click resume, and takes forever to shut down. But as long as it is running it seems to work. There is some hanging that we do not experience on windows in the loading screen when going back to main menu from a scene with several meta humans in though.
The build I am testing this with is a Development Build, but we have the same issue in other configs.
This behavior makes me suspect, it is more of a Proton Issue than an Engine Issue. What do you think? I can provide logs later, but since removing confidental information from them is going to be a hassle, can I attach files as confidental or would the whole question need to be confidental then?
Since we are currently running towards an important deadline I am sadly currently not able test and provide a stripped down project version.
I saw in the past other assert in the cfg_structurizer.cpp, that definitively points to the Proton layer having problem translating a shader, the fact that Proton 10 do not crash there point out that they had similar issues and fixed them already, they will promote the 10 version as main eventually.
The LogNNERuntimeORT should be unrelated, it’s the engine neural layer that tries to find a NPU, likely the shader compilation happens in parallel to that step.
Now with the crash out of the way you are pointing out that the game take a long time to load and there are hanging during loading screen.
Those might be still related to shaders, in the sense that compilation taking a long time to compile them, is the game faster or hang less often if you subsequentially relaunch it ?
(Note: on PC you can try to repro that behavior clearing the shader cache using the cmd line arg -clearPSODriverCache to run with a clean cache on your PC, overall even for your PC sku please configure shader caching to avoid extra stuttering link and link )
To have an idea of what is happening on the Deck you can try using Unreal Insight:
launch Unreal Insight on your host PC
run the game adding on the cmdline: -tracehost=Your.PC.IP.Address -trace=default (you should be able to see your PC IP address in the Connect panel in the Insight UI)
go to the problematic section of the game, you should be able to see the trace in the UI receiving data and then you can analyze the trace in Insight
close the game
If you want to send confidential logs or the trace without having the whole conversation private, please send me an email at daniele.pieroni @ epicgames.com and we can go from there!