Do you have a full hang report or anything else that could help narrow this down?
"hangs every now and then" isn't exactly the most actionable thing in the world.
which I assume means this is now one of the few games utilizing DGC.
Doesn't have to be, trivial cases are still covered by plain DrawIndirect. It does however increase the chances of the game just having sync bugs, pretty much everything lately is broken in one way or another in that regard.
Do you have a full hang report or anything else that could help narrow this down?
Running a game with RADV_DEBUG=hang for hours hoping to catch a hang isn't an option due to the perf hit. But I'm open to suggestions if you have any.
"hangs every now and then" isn't exactly the most actionable thing in the world.
I know, I'm sorry.
It does however increase the chances of the game just having sync bugs, pretty much everything lately is broken in one way or another in that regard.
Do you have some ideas to try to mitigate that?
You can always try adding amdgpu.mcbp=0 to kernel parameter.
You can always try adding amdgpu.mcbp=0 to kernel parameter.
What does any of this have to do with mcbp?
I do not know how it help but kernel used to have random gpu page fault with mcbp enable starting with kernel 6.5. I think it is fixed though
And disabling it on my machine do help with system stability.
I'm on RDNA3 with it may not apply to you.
It does not hurt to try.
According to the logs, the page fault comes from the "vkd3d_queue" thread, so I don't think this has anything to do with mcbp. But sure, I can try disabling it.
0x0000800043b5f000 looks like an error with descriptor heap OOB.
0x0000800043b5f000 looks like an error with descriptor heap OOB.
Do you have a suggestion as to how to diagnose this issue?
Really need some actionable logs to have any chance to debug this.
Is there any way to get any of that without RADV_DEBUG=hang?
Disable GPU recovery and run UMR wave dump on the dead machine (needs SSH).
How do you get breadcrumbs without RADV_DEBUG=hang? Does vkd3d-proton have its own way to get them?
Running with instruction_qa_checks enabled build with expect-assume to catch OOB.
Descriptor_qa_checks could maybe also be used.
I'm not familiar with either of these. Is there an environment variable or do I need a custom built vkd3d-proton for these?
Use bleeding-edge debug branch, then you can do VKD3D_CONFIG=breadcrumbs and it will appear in vkd3d-proton log.
For descriptor_qa_checks you need a custom build. Just try to get a wave dump for now to confirm why it's page faulting.
Just try to get a wave dump for now to confirm why it's page faulting.
Do you mean without the bleeding edge debug branch or any custom build or env vars?
Nothing custom, just umr after GPU is hung. Same as what RADV does automatically when RADV_DEBUG=hang is used.
What umr command should I use to get the info you need?
umr -O bits,halt_waves,full_shader -go 0 -wa gfx_0.0.0 -go 1 >waves.log 2>&1
Will do. The hang is very rare but I'll write here when I managed to reproduce it and got the umr info.
proton hotfixx1 2025-04RADV_DEBUG=hangx1 2025-04VKD3D_CONFIG=breadcrumbsx1 2025-04RADV_DEBUG=hang`?x2 2025-04RADV_DEBUG=hang`x1 2025-04
Software information
I'm running EVE Online from Steam in D3D12 mode, with all graphics settings set to High.
System information
Log files
The issue casues a GPU hang, and I haven't found a good way to grab any Proton logs in a way that survives a hang. Let me know if there is any, or if there is any usefulness.
dmesg log
The
dmesglog indicates some page faults happening for which thevkd3d_queuethread is responsible. I have no clue why the same page fault is repeated several times.You can add an image or a code block, too.