Crash observed on Ubuntu 22.04 with AMD Vulkan driver

[lukelmy]

Integrity​

I have verified my game files (on Steam)​

Yes

I have disabled all mods​

Yes

Required​

Summary​

Crash observed on Ubuntu 22.04 with AMD Vulkan driver

Description​

This crash happened after I clicked on new game and loading.

I have dumped API and related spirv shaders.
After investigation, I think the root cause is that the problematic fragment shader uses "layout(set = 1, binding = 168) uniform samplerBuffer ********ProvinceDataBuffer" which is not set in the corresponding pipeline layout (the largest binding count is 167 in the pipeline layout), thus the driver could not identify this descriptor during shader compiling.

The vertex shader and problematic fragment shader and corresponding pipeline layout are attached.
If you would like to confirm it with API dump, I suggest you could dump API with RADV (since it crashes with AMDVLK and the dump info is incomplete) and find the specific pipeline layout with the size of shader module. (size of shader module -> graphics pipeline -> pipeline layout)

This crash issue is not observed earlier this year and is very likely a game regression according to my analysis.

Steps to reproduce​

Click on new game and wait for loading. Then crash happens

Game Version​

1.8.6

OS​

Linux Ubuntu

Additional​

Bug Type​

Crash to Desktop

Save Game​

Attachments​

View attachment pipeline_layout.txtView attachment shaders.zipView attachment victoria3_20250113_112937.zip

Player Pain​

8

 

[lukelmy]

Hi, may I ask if there's any progress?

Thanks!

 

[PDX_Sosanna]

Hi, we couldn't reproduce the issue on our AMD machines and we are not aware of any widespread issues with AMD + VK. As such, I'll have to move the thread to our Technical Support, as it's not something QA can assist with.

 

[AndrewT]

Well, I'm not sure what I can do with this one! OP thinks it's a game bug but QA says not ... !

@lukelmy I take it you are on the latest and greatest AMD driver? How about Mesa?

 

[lukelmy]

Thanks for the reply. I use the latest AMD driver. And this issue only happens when clicking New Game and Start Game (not Continue).
Verified again on Ubuntu 22.04 with Radeon 7900xtx today and game still crashed.
My graphics settings are attached.

Could you please try again with the steps and settings?

For RADV (Mesa), yes, it works. But it also worked for AMD driver previously.
That's why I guessed it's a driver regression first and started to debug it.
And now it seems it's a game bug based on my analysis in the issue description.

 

[AndrewT]

I don't have any way of testing this I'm afraid.

@PDX_Sosanna is it possible to check this again, as described?

I use the latest AMD driver. And this issue only happens when clicking New Game and Start Game (not Continue).
Verified again on Ubuntu 22.04 with Radeon 7900xtx today and game still crashed.
My graphics settings are attached.

 

[PDX_Sosanna]

@AndrewT As I mentioned, we couldn't reproduce it locally. I asked our externals to verify it on their machines and they also did not run into that CTD.
I raised the issue with our Code, Tech Art and Engine departments, but without any reproduction (or more users affected by the issue) we sadly can't do much more at this point.

 

[PDX_Sosanna]

Our engine team has responded with "we recommend to use Mesa+radv for AMD".

 

[lukelmy]

Sorry for the late reply. I think I know why you could not reproduce the issue. If both RADV and amdvlk are installed, this game would choose RADV.
In this situation, we could bypass RADV to expose the crash issue:
Step 1:
Install a AMD Vulkan driver (not RADV). You could get the package from https://github.com/GPUOpen-Drivers/AMDVLK/releases/tag/v-2025.Q1.3.
(i.e., sudo dpkg -iamdvlk_2025.Q1.3_amd64.deb)
Step2:
Open a terminal:
export VK_ICD_FILENAMES=/etc/vulkan/icd.d/amd_icd64.json (or you could uninstall the mesa-vulkan-drivers)
steam (launch in this terminal)
Step3:
Run Victoria3 and click new game.
Then crash would happen.

I really think it's an app issue because not only it's an application regression but also from my analysis above. (missed binding 168 descriptor in pipeline layout)
I don't think "we recommend to use Mesa+radv for AMD" is reasonable enough to omit a application issue.

If you would like to reproduce it again, please let me know if there's any question.
I could share my insights from gpu driver side.

Thank you in advance!

 

[lukelmy]

@PDX_Sosanna I have debugged into RADV to investigate why it could compile this problematic pipeline.

The problematic fragment shader uses "layout(set = 1, binding = 168) uniform samplerBuffer ********ProvinceDataBuffer" which is not set in the corresponding pipeline layout (the binding count is 168 (0 - 167) in the pipeline layout).
In this nir pass, the offset of binding 168 is 149946368 (0x08f00000), which is a dirty value since it's out-of-bounds!!! (It would not crash in this case)
And this dirty value is still used in the final ISA code to load descriptor. I think the reason why gpu hang doesn't happen is that this condition branch is never gone into to use the invalid binding 168.

So it seems RADV is just lucky enough here. (And it lacks the check that binding index must be smaller than binding count)

BTW, this problematic behavior in app violates the Vulkan spec: If a resource variable is declared in a shader, the corresponding descriptor set in layout must match the shader stage (https://docs.vulkan.org/spec/latest...UID-VkGraphicsPipelineCreateInfo-layout-07988)
And the issue here is that binding 168 is missed in the pipeline layout.

From above analysis, it's definitely a application bug and must be fixed.

I would be glad if you could share contact information of vulkan developers in Paradox with me.