Server fatal crashed: Vulkan: qvkQueueSubmit

[SiLenCe-WB]

Hi!

I've tried running quake3e-vulkan.x64.exe on 3 different systems with integrated GPUs (both Intel and AMD) and I always end up crashing with the following error:

----- Client Shutdown (Server fatal crashed: Vulkan: qvkQueueSubmit( vk.queue, 1, &submit_info, vk.cmd->rendering_finished_fence ) returned VK_ERROR_DEVICE_LOST) -----
RE_Shutdown( 3 )
----- Client Shutdown (recursive error after: Vulkan: qvkQueueSubmit( vk.queue, 1, &submit_info, vk.cmd->rendering_finished_fence ) returned VK_ERROR_DEVICE_LOST) -----
WARNING: Recursive CL_Shutdown()
recursive error after: Vulkan: qvkQueueSubmit( vk.queue, 1, &submit_info, vk.cmd->rendering_finished_fence ) returned VK_ERROR_DEVICE_LOST

The performance is flawless and substantially better than on quake3e.x64.exe (opengl) but the gl version never crashes. Am I doing something wrong or is this behaviour to be expected if I don't have a dedicated GPU?

BTW, I've been able to replicate this issue very fast by simply strafe jumping on the bottom part of Q3DM17, around the jumpers. I was using the default graphic settings to make sure it wasn't config related (I did a cvar_restart + vid_restart).

Thanks for the help!

[ec-]

Could you record demo and post it along with q3config.cfg?

[SiLenCe-WB]

I swear I've just posted a video and the q3config file. Let me try again:

• q3config: https://drive.google.com/file/d/1S3S0gc6-SIiNH4G72u6bhsm6tKp1iSTc/view?usp=sharing
• video: https://drive.google.com/file/d/1t1UjQhTZHWxyRSmmS0D1-idf-A5KhEnH/view?usp=sharing

[ensiform]

According to stack overflow at least one person had this happen when there were indices larger than the given vertex vector/array. Could be some out of bounds thing with the map that needs a guard

[SiLenCe-WB]

I have this issue in other maps too. I just realised that it was easy to replicate the issue in that specific area.

[SiLenCe-WB]

I've tested the same thing with an NVIDIA card (4070 Ti Super) and I had no issues whatsoever. So it seems to be a problem with integrated GPUs.

[ec-]

I can't reproduce it on various Intel iGPUs. Also I see you have some modded textures (console, fonts, map etc.) - could you share your full setup somehow?

[SiLenCe-WB]

I can't reproduce it on various Intel iGPUs. Also I see you have some modded textures (console, fonts, map etc.) - could you share your full setup somehow?

Sure thing mate! Here it is: https://drive.google.com/file/d/1G1AhkNuXM_oFaaJwEVKHTcLXuvlwpaMo/view?usp=sharing

I removed the extra packages (which improve visuals) from that build but you can download them here: https://drive.google.com/drive/folders/1HheSapMEsrNVWuAKGKr1e0GmKu-7mGw4?usp=sharing

But bear in mind that I have the same issue without them, so those can't be causing the problem. Although I must say, I feel that with those packages added, the vulkan error pops up faster but it could have been just a coincidence.

[SiLenCe-WB]

I found that just by doing this, I can replicate the error very fast https://streamable.com/a0y226

It usually drops the error in less than 30 seconds.

[ec-]

Now I am able to reproduce this crash with following settings:

• r_fullscreen 1
• r_fbo 1
• r_ext_supersample 1 (effectively forcing 4k+ rendering)
• cg_fov 110

I see zero warnings/issues with all debug info/validation layers enabled but it seems to happen when vkQueueSubmit being called more than once per frame i.e. when some in-game shader image being loaded on the fly. Never happened in windowed mode, this is very odd, investigating... crash3.dm_68.zip

[SiLenCe-WB]

It does happen to me in window mode too. With this procedure I showed before, I manage to crash it very consistently.

I was wondering if it might be related to the lights coming from the roof in that area. I mean these

[SiLenCe-WB]

I've managed to make it crash with these settings:

• Window mode
• Fov 90
• FBO 0
• Supersampling off.

Here is the video:

https://github.com/user-attachments/assets/57ce4f27-cf25-46c1-bc78-d3aedbc0ee6f

[ec-]

Please record demo using in-game \record commad, it will catch last frame right at crash, then replay it to make sure it is 100% reproducible, because even for me - it is not 100% reproducible. Also specify your full setup (OS, resolution, cpu, gfx driver version etc.), look in system event viewer, currently I'm seeing messages Display driver igfxn stopped responding and has successfully recovered. and errors in different part of renderer so it might be a driver issue

[ec-]

Tested with following Intel iGPU driver versions:

• 07/11/2023,31.0.101.4575 - ok
• 09/13/2024,32.0.101.6078 - crash
• 12/26/2024,32.0.101.6449 - crash

There's something were broken between 4575 and 6078, all validation layers are dead silent

[SiLenCe-WB]

Please record demo using in-game \record commad, it will catch last frame right at crash, then replay it to make sure it is 100% reproducible, because even for me - it is not 100% reproducible. Also specify your full setup (OS, resolution, cpu, gfx driver version etc.), look in system event viewer, currently I'm seeing messages Display driver igfxn stopped responding and has successfully recovered. and errors in different part of renderer so it might be a driver issue

I'll get back to you soon. I did not have much time lately.

[ec-]

At this moment I'm not able to figure out reason of crashes, even putting vk_wait_idle() before/after each significant operation doesn't help, it looks like as a driver bug so for now - try to find and stick with stable driver version.

With recent Intel drivers (6078+) I'm also observing some visual artifacts duirng Vulkan rendering with both quake3e and quake3-ke, and OpenGL artifacts when running timedemo even with original quake3.exe, this looks like as broken image/memory brarriers/whatever, I'm very skeptical about driver-side solution condidering my previous experience with filing bugs to GPU vendors (Intel in particular)

[ec-]

More detailed testing on Intel UHD 770:

• 31.0.101.5186 - ok
• 31.0.101.5333 and later - crash/artifacts

At 5333 they added support for MTL (Meteor Lake) iGPU so I guess it is a side-effect of newly added code, consider using <= 5186 for old iGPUs

[ec-]

As of now:

• 32.0.101.6790 and newer - no artifacts/crashes

Thus, versions you should NOT use:

• from 31.0.101.5333 to 32.0.101.6737

[SiLenCe-WB]

Thank you! I will test it out and report back.

[SiLenCe-WB]

Good news! It's no longer crashing for me. I had to install the latest driver/software (gfx_win_101.6881.exe) from this page:

https://www.intel.com/content/www/us/en/download/785597/intel-arc-iris-xe-graphics-windows.html

After installing it, the driver that was showing up was still and older version (don't know why) but I went to de Device Manager and updated the driver manually with the .6881 and it worked!

[ec-]

@SiLenCe-WB Nice, could you perform any tests on AMD iGPU systems?

[SiLenCe-WB]

@SiLenCe-WB Nice, could you perform any tests on AMD iGPU systems?

If I ever get my hands on a computer with an AMD iGPU, I'll let you know. I was repairing a laptop with an AMD iGPU just yesterday but I returned it to its owner this morning :(

[SiLenCe-WB]

Hello again @ec-

I have recently tested the Vulkan binary on an AMD system with a Radeon 680M and it works great 👌