Compatibility Report

I'm one of the developers of this game, so I can add some additional details here:

• We've received multiple reports from users that the game is no longer playable through Proton.
• Users are getting inconsistent results which Proton version allows the game to work, I've seen a report of Proton 9 working but not 10, a report of Proton 10 working but not 9, a report of none of them working at all.
• Earlier versions of the game worked fine.
• The game still works fine on Windows.

These issues began occurring after we deployed a seemingly unrelated security update for the game which:

• Introduced control flow guard (/guard:cf)
• Introduced a randomized allocation layout
• Introduced zeroing out all freed allocations immediately
• Updated the compiler version to Clang 21.1.8 (previously Clang 20.1.8)
• Most notably, made no intentional changes to GPU detection or really anything GPU related at all

After this, Proton users began reporting that the game fails to discover a GPU with error messages similar to this:

[2026.01.29-20.28.15:083][  0]LogRHI: Found D3DRHIPreference PreferredRHI: dx12
[2026.01.29-20.28.15:083][  0]LogRHI: Using Forced RHI: D3D12
[2026.01.29-20.28.15:083][  0]LogRHI: Using Highest Feature Level of D3D12: SM6
[2026.01.29-20.28.15:083][  0]LogRHI: Loading RHI module D3D12RHI
[2026.01.29-20.28.15:083][  0]LogRHI: Checking if RHI D3D12 with Feature Level SM6 is supported by your system.
[2026.01.29-20.28.15:529][  0]LogD3D12RHI: D3D12CreateDevice failed with code 0x80004005
[2026.01.29-20.28.15:529][  0]LogD3D12RHI: DirectX Agility SDK runtime found.
[2026.01.29-20.28.15:529][  0]LogD3D12RHI: Error: Failed to choose a D3D12 Adapter.
[2026.01.29-20.28.15:529][  0]LogD3D12RHI: Adapter was not found

I personally suspect some kind of incompatibility with the new compiler version, however we don't actually have a setup to test the game on Proton internally.

Based on the log, Vulkan device creation just fails somewhere with VK_ERROR_INITIALIZATION_FAILED for unknown reasons.

It looks like the issue here is that Brickadia is allocating over a terabyte of virtual address space before creating an ID3D11Device. Here is the total amount of reserved VA space I can see when device initialization fails. Do note the units of VSZ are in kilobytes.

[esullivan@nvidialinuxtest drivers]$ ps -p 20459 -o pid,vsz,command
    PID    VSZ COMMAND
  20459 1344344188 Z:\home\esullivan.local\share\Steam\steamapps\common\Brickadia\Brickadia\Binaries\Win64\BrickadiaSteam-Win64-Shipping.exe

The reason this only occurs when enabling extensions like VK_NVX_binary_import is because they cause the NVIDIA Vulkan driver to initialize CUDA. One of the requirements of initializing CUDA is that it needs to be able to reserve 4 GB of virtual memory within the lower 40 bits (or 1 TB) of the process address space. This space is reserved to allocate GPU resources that only support 40 bit addresses. Some examples of resources that need to follow this restriction are some GPU semaphores and command buffers.

This generally isn't an issue for APIs like Vulkan because it allocates separate GPU and CPU virtual addresses for memory allocations. CUDA is unique on Linux though because it uses the NVIDIA unified virtual memory (UVM) driver which always allocates the GPU VA to match the CPU VA for each allocation. I can't provide an estimate on when this issue will be fixed, but it is an issue we are working on resolving.

@Zeblote, one possible way to workaround this problem would be to allocate the virtual memory used by the application after Unreal Engine has had the opportunity to initialize the RHI and create an ID3D11Device.

Fascinating, thanks for the info! I am not sure why we are allocating so much virtual memory, it might be related to recent snmalloc config changes. Will investigate if we can avoid this on our side.

Indeed, incorrect snmalloc config made it reserve 1.25TB on startup. This should be fixed with the next game version.